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