Thanks to your continuous feedback, we have no shortage of new features to add to secureSWF. Today, we are thrilled to present secureSWF v3.5. As all minor point releases, this is a free upgrade to existing licensees.
The new release builds on 22 months of secureSWF v3 updates (we can’t believe it has been that long) and adds for the first time the following new features:
Integration with Powerflasher FDT
Wouldn’t it be great to run secureSWF inside the most advanced Flash development platform? You will find a 5th download option when you download secureSWF v3.5; an FDT plugin! Copy the file into FDT plugins folder and a new secureSWF button will appear in FDT toolbar. That’s all what it takes to start running secureSWF within FDT.
Kindisoft and Powerflasher are also announcing today a new partnership to empower you to make the best out of the Flash platform. secureSWF v3.5 is just a beginning of a much closer integration along the way. We’ll be working closely with the FDT team to bring you the ability to declare obfuscation settings within your code, debug obfuscated files, export a complete auto build script with a click of a button, and much more.
Remove Debugging Information
Keeping debugging information in released Flash applications can be useful for error reporting because source code line numbers and files names where an exception has been thrown can be found in the call stack. Unfortunately, this information is also available to attackers trying to reverse-engineer your code and it also costs a lot of file size.
New options in secureSWF v3.5 will enable you to remove all debug information that you will no longer need outside a debugger, but will keep the source code line numbers. Error messages will show the obfuscated call stack trace (which you can de-obfuscate using the mapping table) with the line numbers.
Local Variables Renaming for ActionScript 3
Variables declared within the function scope in ActionScript 3 are usually compiled as registers without their specified names. But when they are not, for a number of reasons, the identifiers names are passed along the compiled code giving decompilers the ability to regenerate a very closer version on the original source code. With secureSWF v3.5, you can enable the ability to rename local variables in the few cases were they are still in the compiled code.
Control Over Randomization
Randomization is one of the most important protection mechanism for secureSWF. Proper randomization what makes it impossible to create another tool to reverse secureSWF protection. The downside is that a completely different SWF file will be generated every time you run secureSWF, which might not be favorable for testing or verification.
To solve the dilemma, we added a new checkbox in the “Protection Options” tab labeled “Randomize Results” checked by default. When unchecked, secureSWF will generate exactly the same protected SWF file. This will guarantee a consistent output for the identical files and identical configurations.
Detailed File Save Options
Ok. We get it. You want to specify a new name for each file and you want that saved in the project configuration file. secureSWF v3.5 will save the selected output option and adds a new save option that enables you to specify the new name for each file if you want to.
Official support for Adobe Flash CS5
With secureSWF v3.5 we officially support Adobe Flash CS5. You can now switch to CS5 with confidence that you can still rely on us to protect your work.
Want to know what others think of secureSWF, check the following very detailed reviews done recently:
Please download the new version of secureSWF and let us know what you think. We’d love to hear from you.
