in Reviews

FlashInCrypt

A very cool tool was found recently and it went away with a thumbs up on all tested counts. Even ASV and Flasm were left bewildered and they cannot open the file obfuscated with FlashInCrypt. No obfuscater was able to escape ASV or Flasm before but this one is proving to be a must-have, real obfuscater.

But then, there was one worry before we embark on the test, “What if it could not read and interact with the external configuration xml file” that usually happen on all projects here. Fortunately, the swfs obfuscated with FlashInCrypt was able to work very well with the external config xml. So, it proved successful in this scenario too where the internal ActionScript interact with the external raw config data (settings, defaults).

In our lab tests, we were unable to see the source code in any format, probably once ASV comes out with a patch/fix to account for this obfuscation then things might be different (Burak should stand up a bit and take notice of this!). Flasm was confused by this obfuscater, so there isn’t any means of see the DMM (Dynamic Memory Modification) in action. Well, the best bet here is that, it might be doing some code wrapping to confuse ASV.

A minor hiccup with the app was their English on the Dialogs, Confirmations, etcetera. On the overall, this is a real cool tool at such cheap rate.

16 Comments

  1. Hi,

    As I've stated in the comments at my blog at http://www.asvguy.com/2004/01/the_swf_flash_d.html we will not be jumping on bypassing this one - in line with our policy change.

    Nevertheless, we will bypass it as much as we can once another decompiler does this - or in case we find it necessary.

    Removing an action or changing variable function names is not reversible. But anything that crashes ASV (this one doesn't), or makes ASV not show the correct bytecode (p-code), can be reversed, and quite easily.

    So, nobody should think this kind of a protection will last forever (They state this on their site as well).

    Also, there might be problems with future Flash players.

    And yes, introducing itself as 'a professional grogram' (with a 'g') doesn't make a very good first impression. (There's no clue on where these guys are from on the site).

    In any case, we will continue supporting our customers promptly, on case by case basis, with their SWF files whether protected or not.

    Best regards,
    Burak

  2. Hi,

    As I've stated in the comments at my blog at http://www.asvguy.com/2004/01/the_swf_flash_d.html we will not be jumping on bypassing this one - in line with our policy change.

    Nevertheless, we will bypass it as much as we can once another decompiler does this - or in case we find it necessary.

    Removing an action or changing variable function names is not reversible. But anything that crashes ASV (this one doesn't), or makes ASV not show the correct bytecode (p-code), can be reversed, and quite easily.

    So, nobody should think this kind of a protection will last forever (They state this on their site as well).

    Also, there might be problems with future Flash players.

    And yes, introducing itself as 'a professional grogram' (with a 'g') doesn't make a very good first impression. (There's no clue on where these guys are from on the site).

    In any case, we will continue supporting our customers promptly, on case by case basis, with their SWF files whether protected or not.

    Best regards,
    Burak

  3. Hi there,

    I've looked at the example file provided by the firma. I'm not sure what their actual protection is supposed to be, but the trick they use to disable disassembly isn't a very good one. They simply jump into the middle of the swf action, which happens to work in the Flash Player right now. However, there is no guarantee it will continue to work.

    The topic was discussed often enough:
    security through obscurity. It would take half a day to teach Flasm this particular trick. And even without that, it took me 10 minutes wiath a hex editor to reveal the code. The function in question (decompiled with Flare):

    bc[as]. _root.onEnterFrame = function () {
    myDate = new Date();
    hourHand._rotation = myDate.getHours() * 30 + myDate.getMinutes() / 2;
    hourHandShadow._rotation = myDate.getHours() * 30 + myDate.getMinutes() / 2;
    minuteHand._rotation = myDate.getMinutes() * 6 + myDate.getSeconds() / 10;
    minuteHandShadow._rotation = myDate.getMinutes() * 6 + myDate.getSeconds() / 10;
    secondHand._rotation = myDate.getSeconds() * 6;
    secondHandShadow._rotation = myDate.getSeconds() * 6;
    };

    Igor
    P.S. Don't know how to preserve the formatting in your comments, sorry.

  4. Hi there,

    I've looked at the example file provided by the firma. I'm not sure what their actual protection is supposed to be, but the trick they use to disable disassembly isn't a very good one. They simply jump into the middle of the swf action, which happens to work in the Flash Player right now. However, there is no guarantee it will continue to work.

    The topic was discussed often enough:
    security through obscurity. It would take half a day to teach Flasm this particular trick. And even without that, it took me 10 minutes wiath a hex editor to reveal the code. The function in question (decompiled with Flare):

    bc[as]. _root.onEnterFrame = function () {
    myDate = new Date();
    hourHand._rotation = myDate.getHours() * 30 + myDate.getMinutes() / 2;
    hourHandShadow._rotation = myDate.getHours() * 30 + myDate.getMinutes() / 2;
    minuteHand._rotation = myDate.getMinutes() * 6 + myDate.getSeconds() / 10;
    minuteHandShadow._rotation = myDate.getMinutes() * 6 + myDate.getSeconds() / 10;
    secondHand._rotation = myDate.getSeconds() * 6;
    secondHandShadow._rotation = myDate.getSeconds() * 6;
    };

    Igor
    P.S. Don't know how to preserve the formatting in your comments, sorry.

  5. I agree with Burak and Igor that injecting unaligned code into swf may not work with future Flash players. And it's extremely easy to remove. It took me about 20 minutes to write a small program "FINI" that automatically strips non-standard bytecode and tags off an "incrypted" swf file.

    Here is the link:
    http://genable.com/aso/fini.html

  6. I agree with Burak and Igor that injecting unaligned code into swf may not work with future Flash players. And it's extremely easy to remove. It took me about 20 minutes to write a small program "FINI" that automatically strips non-standard bytecode and tags off an "incrypted" swf file.

    Here is the link:
    http://genable.com/aso/fini.html

  7. The Fini was published by Wang Zhen, he posted the thread here. I do not know what the relationship between ASO and ASV is. Burak said that "we will bypass it as much as we can once another decompiler does this ". ASO help Burak to carry his point. It is so interesting thing.
    I do not know what Flashincrypt will do. And I do not know what the as-protect will do. Maybe the winter of protection tools comes.

  8. The Fini was published by Wang Zhen, he posted the thread here. I do not know what the relationship between ASO and ASV is. Burak said that "we will bypass it as much as we can once another decompiler does this ". ASO help Burak to carry his point. It is so interesting thing.
    I do not know what Flashincrypt will do. And I do not know what the as-protect will do. Maybe the winter of protection tools comes.

  9. Genable released the new version of ASO. They updated it four times in one day. But the result seems the same as the original version.

    I try to reveal the code with a hex editor, it cost me less than 3 minutes. The current version is too simple. Maybe the next version will be stronger than old one.

    How about ASV?

    Best regards.

  10. Genable released the new version of ASO. They updated it four times in one day. But the result seems the same as the original version.

    I try to reveal the code with a hex editor, it cost me less than 3 minutes. The current version is too simple. Maybe the next version will be stronger than old one.

    How about ASV?

    Best regards.

Comments are closed.