Any reverse engineers have experience with secureSWF?

Question

I'm writing a flash application and am afraid that it will be decompiled. In order to minimize this chance, I want to obfuscate the file.

I have heard of secureSWF (http://www.kindisoft.com/), and they do list some "user comments". These are however so optimistic that they are hard to trust. There's not a single pessimistic comment (not even about eg. the user interface or support), so something tells me that they might not post them all. From my experience, even the best companies have some kind of critic every now and then.

So, any reverse engineers here, could tell me how experienced you are in the job - and whether you managed to reverse engineer a secureSWF obfuscated file? If so, how long did it take you approximately? Would you recommend this software?

Thanks a lot in advance.

Answer 1

Rule 1:

Anyone with intelligence and determination will always obtain your code/keys/source/files/data
Anything you do simply increases the potential time/effort required to compromise

With or without SecureSWF, will people go to the trouble?

A quick Google suggest that not many attempts have been made to decompile SWF files created with secureSWF ... but they must still meet the specification of compiled bytecode ... so it just amounts to obfuscation. The lack of testing suggests:

1. No one really has independently tested it, and therefore no value in its security can be made
2. People have tested it, it is very effective and people didn't post the results

I think the former is more likely. If you said what the Flash app does, then these points might be more specific.

I would look for sources of data relating to how long after release these things have been reversed rather than the security of the system itself (which is irrelevant).

Also ensure that making your source secure-ish (rather than cooperating with the community) is the best strategy considering that at some point, a determined mind will be able to access your logic.

From a business point of view, your strategic position should not be in keeping your logic scrambled ... as this is futile. You can be as proprietary as you want ... but people will get around it (just ask the games industry). And heavy-handed security causes backlash (see DRM).

If you are convinced your application is so amazing that people will go to the effort of reversing it, look for another value proposition.

Flash is one of those things, like JavaScript, where there is only so much you can do and does it really matter? What good is the apps logic without the other links in the chain?

Anyway, look for the required effort to reverse the encoding rather than the perceived strength of the software's clients.

Anyway, Good Luck!

Answer 2

Take a look at open source compilers, like SWFMill and Haxe http://haxe.org/ they generated different byte-code in their final swf an can crash many of popular decompilers. Is obvious that the code can be obtained just like the ordinary adobe compiled swf, but many decompilers will just not work with it, so if you want to increase the 'amount of effort needed' I would suggest you to take a look at this solution and maybe create something mixing all of it.

Answer 3

DISCLAIMER: I work for Kindisoft.

secureSWF is the best ActionScript obfuscator out there. I believe there is absolutely no doubt about that: https://www.mochiads.com/community/forum/topic/which-obfuscator-should-i-use-as3

http://asgamer.com/2009/why-how-to-encrypt-your-flash-swf

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.

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:

// 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:...

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.

But is it possible? 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: http://en.wikipedia.org/wiki/Security_through_obscurity

Other alternatives 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.

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 ;)

More information can be found here: http://www.kindisoft.com/secureSWF/faq.php

Answer 4

I don't have extensive experience with obsfuscators, but some months ago I was asked to try a couple of them for a specific project (it was actually a --rather simple-- multiplayer game). I tried SecureSWf and Amayeta SWFEncript (both trial versions, which were fully functional, if I recall right).

Both had some problems with the more "advanced" features. If I'd choose just to rename identifiers, things would work smoothly. But even with the default settings (a minimum of control flow obfuscation), one of the obfuscators produced illegal bytecode, i.e. it would be rejected by the player's verifier. This produces an exception and that's about it. I really can't recall which one, but it failed as soon as you run the swf.

I didn't test much further, but it made me see this is something you have to take into account as well. There's an extra cost in using this tools. It could be acceptable or not for your purposes, but you should account for it. Once you change and twist you swf, it's not the same swf you've debugged and tested anymore. So, now you'll have twice as work testing, cause there's a chance the obfuscator has introduced bugs. The one I saw was pretty evident and blew the player right away, but there could be subtler, harder ones. And if you happen to have a bug that only shows in your "secure" version (or worse, it looks like it only happens in your secure version, but you're not positive), debugging it will not be fun.

Of course, this is not a proper review, just my limited experience. Most obfuscators have free trials so you can try them yourself. And I should also say that the decompiled and disassembled code was well, really obfuscated, and making sense out of it would be a daunting task.

Yet, I thought I would add a different perspective, which is not often mentioned.