True... if they're clever and determined enough to get that far, maybe they deserve to steal the code ;)Quote:
Originally Posted by MadBunnySkills
Printable View
True... if they're clever and determined enough to get that far, maybe they deserve to steal the code ;)Quote:
Originally Posted by MadBunnySkills
Nowadays there is only few ActionScript 3.0 obfuscators that realy work. There is always a way to decompile your swf and reverse protected code... But to do this is much harder then it looks like)) So I think swf obfuscators is a good solution.
I am using this one http://www.dcomsoft.com ... it is called SWF Protector. Pretty reliable.
SWFguru you've just registered and that's your first post. Congrats.
Now i feel obliged to share this link with you all - http://www.swfdecrypt.com/ .
How reliable is exactly the piece of software you're offering?
for those interested in swf obfuscating and security this blog is a must-read.
vitaLee,
hmm interesting blog. I understood the point.Quote:
So which one ActionScript obfuscator is the best? What do you think?
What exactly are you guys creating that somebody needs/wants to steal?
I've got a patent pending on some code right now. I'm worried about someone figuring out how the calculations work. Obviously you should never put passwords or internal server data into an SWF. But there are logic systems that you want to have work on the front end (because it's faster than passing data from the server) that you don't want people to have access to.
My current method involves encrypting my bytecode, doing a flex embed to a holder, decompressing the holder, doing some seriously heavy bytecode editing with a hex editor, recompressing, then uploading to production. Got it down to under two minutes to load a new build. It can be broken; it involves dumping the RAM contents. But it's still obfuscated at that point, and better than anything else out there. It'll keep 99% of potential coders out; and the ones who are smart enough could definitely figure the code out for themselves.
Back when I was exploring this issue, I wrote most of a proof of concept utility which would encrypt a swf and embed that and the corresponding password in unimplemented tags in the swf file. It's security by obscurity (as any solution which does not require the end user's knowledge must be), but it's a technique I haven't seen before. The advantage of embedding key binary data in unimplemented tags as opposed to binary assets such as images or blobs is that they won't even show up in most swf decompilers. At least until they get wind of the technique.
To decrypt, the final swf loaded its own binary data into a bytearray and parsed that, then applied the appropriate decryption.
Obscurity is good.
Other than ripping out the SWF's that are decrypted and held in RAM, virtually any encryption is going to be good enough to prevent the script kids from decompiling. I take it a step further with mine, by generating an encryption key from a math equation that uses about a dozen static constants in another class... those static const's are evaluated from simple math like 1*3+2/4*9. Then when I modify the bytecode, I change the names of the constants to things like 3+4*9=9*32+
so that in reading the bytecode, it's almost impossible to figure out where the var name ends and the other side of the equation begins. No decompiler out there can generate a functional decryptor from the holder's bytecode. The only way to get at the source is to run it and dump the RAM contents.
It's all fun and games as long as everyone knows that no client-side code is EVER to be considered un-decompilable from a security pov.