A good friend of mine is working on encryption technology that let you protect your applications from decompilation.

It is not a typical obfuscation approach that just tries to make your code unreadable. It is encryption on binary level. This means that not only your code is completely encrypted but also the assets that are shipped within your application bundle.

Another interesting aspect of the BIS Guard approach is that the decryption is keyless. This means that it is impossible for tools (decompilers) to break the binary encryption. I also not sure if a skilled hacker may break the protection. My friend sad, he never met one (even for money).

The technology was first implemented in Java and now there is RC1 for Flash/Flex.
Flash Antidecompiler™ is an AIR application which creates a secured swf file from any SWF file you choose.

If you are interested visit the homepage of BIS Guard: http://www.bisguard.com/flash.html

The link to free download of Flash Antidecompiler™ is also provided there.

19 Responses to “Flash Antidecompiler™ 2011”

  1. Not so bad.
    Many thanx.

  2. I don’t get it.
    This is a re-packaging of your SWF inside another SWF,
    Your original SWF is encrypted with a simple AES Cipher,
    The your SWF is processed at runtime when you execute the new launcher. and Loaded as a ordinary swf.
    Breaking this sort of system takes a only few minutes… it’s not even obfuscated. It’s not a real protection.
    Or I just don’t get it… I’ve watched the crypto example. it might be broken.

  3. In theory every thing is breakable.
    In praxis there are tools called decompilers that let a child with 50$ decompile any SWF on the web and export artwork like images and sound.
    Or browse through (obfuscated) code and pickup sensible data like passwords and webservice endpoints.
    The real sensible data can’t be obfuscated by the tool.

    Now you described the process of encryption pretty well, but what is your strategy for breaking this sort of system?
    Let me suggest you decompile the wrapper SWF and extract the original SWF.
    This process is very hard to automate because in the wrapper SWF there could be many assets and you has to decide which of them is the encrypted source SWF.
    But still, let me guess that you found the encrypted SWF, how you would like to break it? Brute force?

    The best part of BisGuard Technology is that it works keyless. The key is created upon the runtime behavior of wrapper SWF, so if you break it, it want generate right key.

    It’s like Schrödinger’s cat experiment.

    You can prove me wrong and break the example SWFs on BisGuard website.

    Or just kill all of my argumentation and write a tool that can do that automatically.

  4. Could you make a simple example with something we should not have acess to?
    It could be fun to try again.
    I did it back then with joshstrike. he was making encryption/encapsulation for SWF for a casino website.
    It was pretty fun.

  5. Cool!

    I will ping my friend to provide a simple example

  6. Total time: 20 min.
    Time repartition:
    2 minute getting the function.
    18 Minute trying to simplify it. LOL

    So the function is : ((((((((((n * n) * n) * n) * n) + ((((32 * n) * n) * n) * n)) – (((77 * n) * n) * n)) – ((13 * n) * n)) + (99 * n)) + 321) / (((((((((n * n) * n) * n) * n) – ((((73 * n) * n) * n) * n)) – (((22 * n) * n) * n)) + ((87 * n) * n)) + (44 * n)) + 546))

    replace “n” by any number and you get the result.

    Does it represent something?

  7. Great.
    What decompiler did you use?

  8. So I forgot to give an exemple:
    (n^5 + 32(n^4) – 77(n^3) – 13(n^2) + 99*n + 321) / (n^5 – 73(n^4) – 22(n^3) + 87(n^2) +44*n + 546) =
    Using n = 0.876
    (0.876^5 + 32(0.876^4) – 77(0.876^3) – 13(0.876^2) + 99*0.876 + 321) / (0.876^5 – 73(0.876^4) – 22(0.876^3) + 87(0.876^2) +44*0.876 + 546) = 0.615014569
    Your App: -> 0.615014569

  9. contact me by mail, we shall discuss more ;)

    giving too much precision in public on how to hack something is never a good thing ;)

  10. what is your mail?
    you can send it to moshe@bisguard.com

  11. The mail you gived me doesn’t work.

  12. @jpauclair @bisguard Do you guys managed to exchange emails or should I mediate?

    @jpauclair I am curious what is your final verdict :)

  13. Broke it too :)

    Probably using the same technique as @jpauclair ;)

    That’s true that BISGuard loader is obfuscated enough (for now) to resist a decompiler like ASV, so that’s not bad. But you know… you still have to *load* the original, unprotected, SWF in memory at some point.

  14. @Philippe:
    > BISGuard loader is obfuscated enough (for now) to resist a decompiler like ASV,

    I will disagree, as I don’t see any obfuscation :) [Please let me know if there is a problem with the decompile - Are you using the latest version?].

    In any case, SWF Revealer Tool for ASV will work and you don’t really need to worry about the loader part.

    But I’ll agree that manual hacking is more fun!


  15. Update: Thanks @Philippe for pointing out the glitch I missed. Will be fixed with next ASV update.

  16. Haha.

    Wow.. I didn’t think this conversation would go that bad!
    Claiming most secure SWF -> break -> making decompiler better.

  17. The “broken” example contained the debugging parts of the code.
    Now they are deleted. Please try again.
    My apologies… and many thanks for help in finding it.
    P.S. Everybody welcome to participate.

Leave a Reply



You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Before you submit form:
Human test by Not Captcha

© 2011 Max Blog Suffusion theme by Sayontan Sinha