• What is code obfuscation?
• Why use code obfuscation?
• What are the differences between the Professional and Personal Editions of secureSWF?
• Can I get an evaluation copy?
• Does secureSWF change the source code of my application?
• How does secureSWF protect SWF files?
• What is Statement-level Randomization?
• What is Control Flow obfuscation?
• What is Dynamic Code Wrapping?
• What is Literal Strings Encryption?
• Why would I use obfuscation to hide security vulnerabilities? Wouldn't it be better to ensure that I have no vulnerabilities?
• What happens when I try to use a decompiler on an application protected by secureSWF?
• What kind of code optimization techniques does secureSWF provide?
• What versions of Flash does secureSWF support?
• When will secureSWF support ActionScript v3.0?
• Is there a way to declare in my source code which identifiers I want to exclude from obfuscation?
• Can I use regular expressions to exclude or include certain identifiers?
• How do I integrate secureSWF into my automated build process?
• What about tools that convert SWF files into executable form such as .EXE files?
• Is the use of eval in ActionScript always OK?
• Is Flash Remoting a problem for secureSWF?
• My application uses Flash components. Can I still use secureSWF?
• How can secureSWF break decompilers without affecting the Flash player?
• What does renaming to "unprintable and illegal characters" mean?
• Does secureSWF produce unverifiable code?

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.

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.

The Professional edition provides superior protection to break decompilation, size reduction to conserve memory and improve load times, literal strings encryption, build process integration and other features to help you protect your SWF files from downloading and copying.

The Personal edition is an entry level obfuscator. It is targeted at freelancers and freeware authors. You can find a detailed comparison table here.

Of course! You can download the Demo version directly from here or you can request a fully-functional evaluation copy of secureSWF Professional edition from here.

Also, secureSWF Personal and Professional Editions that are purchased over the web come with a 30-day money back guarantee.

No. secureSWF works solely on compiled SWF files. Your source code is not needed (or affected).

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!

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.

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 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.

Dynamically wraps ActionScript byte code blocks in your SWF files to make it much harder for decompilers to even find your code.

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.

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."

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.

Other than renaming, secureSWF optimizes tags headers, removes duplicate not-statements, eliminates dead code blocks and optimizes control-flow statements by reducing the number of GOTOs in the code.

secureSWF currently supports Flash versions from 4 to 8. Very soon, ActionScript v3.0 will be supported for Flash CS3, Flex 2 and Flex 3 as well.

The official release is planned to be before May 2008. Alpha and Beta prereleases will be available earlier for all secureSWF Professional edition users.

Unfortunately, there is no direct way to include information in your ActionScript v1.0 or v2.0 to exclude identifiers from obfuscation. But you can add a unique prefix or postfix to identifier names and then use regular expressions to exclude them from within secureSWF.

We are currently working on providing this option with ActionScript v3.0 support.

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.

secureSWF Professional has a command line interface, suitable for integrating into scripting environments. In addition to that, secureSWF configuration project files are written in XML format which makes them easy to read and modify.

Flash projectors will have absolutely no problem working on your SWF files obfuscated by secureSWF.

Most of the time. secureSWF can figure out when eval (or set) is used and how to handle it in most cases, such as:

for(i = 0; i < 10; i++)
    trace(eval("myArray" + i));

But in other cases that we've seen, handling eval and set were a problem for secureSWF as well as for us:

vars = "abc";

...

set(vars.substring(0,1), 5);

...

trace(a);

The rule is, you can use eval and set to concatenate strings together to make up a variable name. But if you have something like the above example, then you don't need secureSWF to handle that code, it's already obfuscated :-)

Absolutely not. In some cases, you might need to go an extra steps to manually exclude identifiers used in remoting. But in most cases, it just works right out of the box.

Yes. You can even obfuscate the components' code!

Decompilers and the Flash player differ in one very important area. The Flash player executes code - if the code says "GOTO", the 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.

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 "?"). Furthermor, 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 can not be used directly for the Flash compiler.

Only if your input code is not verifiable. Unlike some other obfuscators, secureSWF's transformations do not make verifiable code unverifiable.