@blueinc: Thanks for the info.
I had the chance to try the demo of secureSWF and compare it to the sothink decompiler. I did so in a virtual machine and would encourage anyone else wanting to perform similar tests to do so as well. After running an obfuscated SWF through the sothink decompiler demo, it either crashed or produced uncompilable output. That said, I did find a piece of software that purports to be able to remove all the protections added by secureSWF, called swf reader. It would also be possible to manually go through the code and remove all the protections added - the extra instructions added are clearly nonsensical to anyone with a passing knowledge of AS3, and secureSWF does not add any plausible looking instructions alongside your actual code, even at maximum settings. Thus, it is relatively easy to pick out the real code from an obfuscated block. In theory, with a language such as AS3 there is no way to prevent effective decompilation, so this is not surprising. I would argue that it is also not a good ROI to spend time troubleshooting the problems that may appear when using control flow obfuscation and dynamic code wrapping and also not good practice to harm your legitimate users by the performance reduction that these obfuscations may cause on more complex applications.
It is a shame that a program is so readily available for reversing these protections. I do find it rather amusing, though, that the author of swf reader charges for his program, neglecting the fact that those who want to use his program to steal someone elses code will likely seek to do the same to him. No honor among theives and all that.
Not to mention the fact that no matter how locked down your SWF, all your UI assets can be replaced easily and your application redistributed without even touching the code. Code obfuscation does nothing to make this harder. That said, secureSWF still holds some value (but not $199+ worth, if you ask me), as it does rename identifiers and make the task of understanding and modifying the actual functionality of your application more difficult. I would encourage anyone seeking such functionality to investigate alternatives - I found an open source python script that obfuscates as3 source by removing comments, identifiers and hex encoding strings on github (https://github.com/shapedbyregret/actionscript-3-obfuscator). Such irreversible obfuscation could make it unprofitible for someone to improve your code and release it as a competitior to your original application. That said, I would imagine someone with the inclination and ability to make a truly competitive and polished product would not be likely to steal code to do so. I would argue rebranding and redistribution is the far likelier threat, and one which unfortunately we have little protection from except relying on RIMs review process to prevent any such incidents.
Even Apple has had an incident where a counterfit app was accepted onto the Mac App Store (http://thenextweb.com/apple/2011/02/03/counterfeit-app-lugaru-appears-on-the-mac-app-store/). In this case, the source for the app but not the assets were released under the GPL by the developer. Considering the nature of actionscript, we should all consider our source (and assets) equally as exposed. That app was eventually removed from sale, but not before being available for a week and presumably stealing a substantial amount of sales and revenue from the legitimate developer. I would hope RIM is paying particular attention to this and taking steps to ensure this does not become an issue.
I know I will be moving to the native sdk as soon as it is available. Not only because the above will become a non issue, but also because the lack of multithreading in flex is a serious detriment to the user experience.
