Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><em>DISCLAIMER: I work for Kindisoft.</em></p> <p>secureSWF is the best ActionScript obfuscator out there. I believe there is absolutely no doubt about that: <a href="https://www.mochiads.com/community/forum/topic/which-obfuscator-should-i-use-as3" rel="nofollow noreferrer">https://www.mochiads.com/community/forum/topic/which-obfuscator-should-i-use-as3</a></p> <p><a href="http://asgamer.com/2009/why-how-to-encrypt-your-flash-swf" rel="nofollow noreferrer">http://asgamer.com/2009/why-how-to-encrypt-your-flash-swf</a></p> <p>Code obfuscators should make it impossible for reverse-engineers to use an automated tool that can retrieve readable source code (i.e. a decompiler). And within that, secureSWF is very successful. Since automating the process is no longer possible, the time and effort to reverse-engineer the obfuscated application depends on its size. The larger the application is, the more complex and time consuming reverse-engineering becomes. Re-writing the code from scratch is usually simpler.</p> <p>Obfuscation is not encryption. It should be a one-way process. When you rename identifiers, the original names no longer exist. The only way to get them back is by guessing. The same thing applies to control flow obfuscation. Mangling the instruction and changing how the code executes in bytecode does not follow the same rules of ActionScript. Consider the following:</p> <pre><code> // swapping the values of a and b var t = a; a = b; b = t; // will be compiled to something similar to: get a set t; get b; set a; get t; set b; // and will be obfuscated to something similar to: get a get b set a set b // then it can become: goto l1: l2: set a set b goto l3 l1: get b get a swap goto l2 l3:... // after that it becomes: goto l1: l2: set a set b goto l3 get b dup add l1: get b get a swap goto l2 l3:... // and finally (? denotes an unprinted char) goto l1: l2: set ? set ? goto l3 get ? dup add l1: get ? get ? swap goto l2 l3:... </code></pre> <p>Now imagine that applied to all your code. Every time in a different way. I would go further than claiming reverse-engineering SWF files becomes as hard as native code. I say it becomes even harder.</p> <p><strong>But is it possible?</strong> Of course it is. If you have something so important, that attackers will go into all this trouble for, then it definitely shouldn't be executed in a possibly hostile environment (the client). Although it helps, obfuscation shouldn't be mainly thought of as a security measure. More information can be found here: <a href="http://en.wikipedia.org/wiki/Security_through_obscurity" rel="nofollow noreferrer">http://en.wikipedia.org/wiki/Security_through_obscurity</a></p> <p><strong>Other alternatives</strong> include keeping sensitive code running on the server and encryption. Server-side coding is not always possible. In many cases, you really need your code to run on the client. Encryption is even worse, decryption has to happen on the client and you will have to send the decryption code and key to the client leaving nothing to prevent the attacker from decrypting the code himself.</p> <p>I hope I provided enough technical content to support my views. Now back to shameless marketing :). Download the demo version and test it yourself. It's not time limited and is fully functional except for a watermark we leave on processed files. Since we go after people on forums and stackoverflow.com to help out, our technical support service definitely exceed expectations ;)</p> <p>More information can be found here: <a href="http://www.kindisoft.com/secureSWF/faq.php" rel="nofollow noreferrer">http://www.kindisoft.com/secureSWF/faq.php</a></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload