What is the difference between the Professional, Standard, and Personal-Lite editions of secureSWF?
The Personal edition provides basic features to prevent Flash decompilers from generating anything useful. The Standard edition builds on that and provides identifiers renaming. And the Professional edition has all the features you need to fully protect your Flash applications from decompilers, reverse-engineering, and illegal redistribution. You can find a detailed comparison table here.
What's the upgrade policy from previous versions to secureSWF v4
Purchases placed after the 1st of June 2011 can upgrade for free. All other purchases are be able to upgrade at a 50% discounted price. You can upgrade here
Can I get an evaluation copy?
Of course! You can download the Demo version from here!
Also, secureSWF Personal, Standard, and Professional Editions that are purchased over the web come with a 30-day money back guarantee.
What is code obfuscation?
Obfuscation is the concealment of the code's meaning, making it confusing and harder to understand. It's not encryption, but in the context of code, it might be better. Although encryption can make your code completely unreadable, it suffers from a classic encryption flaw, it needs to keep the decryption-key with the encrypted data. So, an automated tool could be created to decrypt the code. Once that happens the fully unencrypted, unobfuscated code is in plain view.
Without argument, obfuscation (or even encryption) is not 100 percent protection. If a hacker is persistent enough, he/she can find the meaning of your code. The goal of obfuscation is to make the process of reverse engineering extremely time consuming and painful so that it is not worth the effort. The goal is to stop all casual hackers and as many serious hackers as possible.
Obfuscation removes context from compiled code that humans (and decompilers) would use to decipher the code's meaning. The trick is to remove this context from evil intentions while retaining complete execution integrity with the original program. Kindisoft's products have accomplished this completely - your program will produce the same results as it did before obfuscation but the code is far more difficult to reverse-engineer.
Why use code obfuscation?
Flash applications are easy to reverse engineer. This is not in any way a fault in the design; it is simply a reality of interpreted, intermediate-compiled languages. Java and .NET applications suffer from the same exact problem. Being much higher-level than binary machine code, the intermediate files are laden with identifiers and algorithms that are easy to understand. After all, it is obviously difficult to make something easy to understand and flexible while hiding its crucial details.
So anyone with a copy of a Flash ActionScript decompiler such as ASV or Sothink Decompiler can look at your code and reverse engineer your application. Suddenly, your licensing code, copy protection mechanisms, and proprietary logic are much more available for all to see - whether it's legal or not. Anyone can use the details of your software for whatever reason they like. They can search for security flaws to exploit, steal unique ideas, crack programs, etc.
With all of that said, this should not be a showstopper. Developers concerned with their intellectual property on Flash need to understand that there is a solution to help stop decompilation and reverse engineering. Obfuscation provides seamless renaming of identifiers in SWF files as well as other techniques to foil decompilers. Properly applied obfuscation can increase the protection against decompilation by many orders of magnitude, while leaving the application's behaviour and output intact.
My Flash app is no longer running after using secureSWF. What should I do?
Does secureSWF change the source code of my application?
No. secureSWF works solely on compiled SWF files. Your source code is not needed (or affected).
How does secureSWF protect SWF files?
secureSWF renames all possible methods, fields, classes and symbol instances and removes frame labels. It will automatically detect which identifiers are safe to rename and is highly configurable so you can manually choose the identifiers to rename and those to skip.
secureSWF also includes several advanced obfuscation techniques such as Control Flow obfuscation, Statement-level Randomization, Dynamic Code Wrapping and Literal Strings Encryption. No obfuscator can prevent decompilation in all cases; however, secureSWF makes the decompiled output extremely difficult to read. It makes decompilers work more like disassemblers!
What is Statement-level Randomization?
Statement-level Randomization is our proprietary obfuscation methodology that randomly restructures the sequence of the SWF byte-code instructions that decompilers use to perform a complete ActionScript statement. It removes all the possible links between the compiled byte-code and the ActionScript source code making decompiling a virtually impossible process. Unlike traditional control flow obfuscation, Statement-level Randomization could actually decrease the code size and enhance performance.
What is Control Flow obfuscation?
Control flow obfuscation is a traditional but effective obfuscation technique. Reverse-engineering tools and the Flash player differ in one very important area. The Flash player executes code - if the code says "GOTO", the Flash player does. Reverse-engineering tools attempt to view sections of code at once and identify those pieces of code as for-loops or if-blocks or whatever structures were present in the source code. The Flash player does not particularly care and certainly does not need those structures. Loops are simply a commonly followed GOTO.
Control flow obfuscation destroys the common perception of a compiled control structures. The Flash player doesn't care if one set of GOTOs has been replaced by another. But reverse engineering tools now are left with spaghetti code. Since ActionScript has no actual GOTO command (compiled byte code does) this often poses a significant reverse-engineering problem.
What is Dynamic Code Wrapping?
Dynamically wraps ActionScript byte code blocks in your SWF files to make it much harder for decompilers to even find your code.
What is Literal Strings Encryption?
secureSWF Professional implements runtime String encryption/decryption. As mentioned before, any encryption done at runtime is inherently insecure. That is, a smart hacker can eventually break it, but for strings present in client code, we found it worthwhile. Effectively, we allow you to apply a secure encryption algorithm (with a twist to thwart decompilers) to any strings in your application. These strings will be only decrypted at runtime when needed.
If a hacker wants to get into your code, he wouldn't blindly start searching renamed types. He probably would search for strings that point him right to the code that is of interest to him. Searching for strings is incredibly easy. String Encryption raises the bar for the casual hacker and deters that many more non-serious hackers. You will want to make sure that you apply string encryption to hide sensitive information such as URLs, hardcoded usernames and passwords, or your game cheats, etc. This algorithm incurs a very tiny performance penalty at runtime but as with pretty much everything else in secureSWF, this option is fully configurable.
Why would I use obfuscation to hide security vulnerabilities? Wouldn't it be better to ensure that I have no vulnerabilities?
Fixing security vulnerabilities is the best. However, no one can guarantee zero vulnerabilities. If we could, we would not see the continuous stream of patches from every software vendor. These issues persist even with "vulnerability-free code."
What happens when I try to use a decompiler on an application run through secureSWF?
Many of the secureSWF code transforms features tend to break or crash decompilers. Even if secureSWF does not outright crash the decompiler, it will stop it from generating useful output. For example, the decompiler may generate an empty or incorrect function because it had control flow obfuscation applied to it. And additional transforms such as statement-level randomization will make it almost impossible to figure out what is going on anyway.
What versions of Flash does secureSWF support?
secureSWF supports all Flash versions from v6 to CS6 including ActionScript v3 and Flex v2, v3, and v4. It also supports SWC, AIR, and APK files as well.
Can I use regular expressions to exclude or include certain identifiers?
Yes, you can use regular expressions to exclude or include certain identifiers. You can do this by click on the "Advanced" button right under the identifiers renaming tree/list. There, you can define the selection criteria by selecting the types of the identifiers and a string pattern to match the identifiers names with. The string pattern can be optionally treated as a regular expression.
How do I integrate secureSWF into my automated build process?
secureSWF Standard and Professional editions come with an Ant Script task and a command line interface suitable for integrating into scripting environments. In addition to that, secureSWF configuration project files are written in JSON format which makes them easy to read and modify.
What about tools that convert SWF files into executable form such as .EXE files?
Flash projectors will have absolutely no problem working on your SWF files obfuscated by secureSWF.
Is Flash Remoting a problem for secureSWF?
Absolutely not. In some cases, you might need to go an extra step to manually exclude identifiers used in remoting. But in most cases, it just works right out of the box.
My application uses Flash components. Can I still use secureSWF?
Yes. You can even obfuscate the components' code!
How can secureSWF break decompilers without affecting the Flash player?
Decompilers and the Flash player differ in one very important area. The Flash player executes code - if the code says "GOTO", the Flash player does. Reverse-engineering tools attempt to view sections of code at once and identify those pieces of code as for-loops or if-blocks or whatever structures were present in the source code. The Flash player does not particularly care and certainly does not need those structures. Loops and if-statements are simply a commonly followed GOTO.
secureSWF's code transforms destroys the common perception of a compiled control structures. The Flash player doesn't care if one set of GOTOs has been replaced by another. But decompilers are left with spaghetti code. Since ActionScript has no actual GOTO command (compiled byte code does) this often poses a significant reverse-engineering problem.
What does renaming to "unprintable and illegal characters" mean?
secureSWF will rename your variables, methods and classes using new names that always start with characters that identifiers in ActionScript are not allowed to start with (such as "?"). Furthermore, secureSWF uses unprintable characters with low ASCII codes such as the linefeed character. Using these characters are fine with the Flash player but will highly confuse the decompiler. Most importantly, you can be sure that the decompiler output cannot be used directly for the Flash compiler.