Flex/Flash/Actionscript

I just decompiled a decompiler so I could use it to decompile itself

Update: Turns out that the code in Nemo 440 is actually just the code from the abcdump.as file in the Tamarin project. It looks like the abcdump.as file was written by Dan Schaffer from Adobe. So it turns out I could have just grabbed that file and not decompiled Nemo 440 at all, oh well :) Shigeru Nakagakai has also used that same abcdump.as file to create his own AIR app that lets you compare SWFs and inspect classes and packages.

My brain almost exploded with meta-geekiness. If you haven’t seen the Nemo 440 AIR app, it’s a SWF decompiler written in AS3 as an AIR application, written by Vadim Melnik. It lets you load SWF files (or SWCs) and it will show you a list of all classes in the SWF, as well as the detailed ABC bytecode for each class. Technically I guess using the word “decompiler” isn’t correct, Nemo 440 is a SWF disassembler that produces ActionScript Byte Code (ABC). This isn’t the same as a true decompiler that produces real ActionScript code (like the Sothink Decompiler).

So if you download and play with Nemo 440 you’ll see what it can do. Basically you can see all the classes in any SWF, and all the methods within those classes. You also get to see some stuff like class-level and static variables. Then if you want to uber geek out you can see the ActionScript Byte Code of the SWF. That means you get shit that looks like this:


    0       getlocal0     	
    1       pushscope     	
    2       getlex        	http://www.adobe.com/2006/flex/mx/internal::layoutObject
    5       getlocal1     	
    6       setproperty   	direction
    9       findpropstrict	invalidateSize

That’s far from being nice beautiful AS3 code that you can actually use, but if you spend enough time understanding ABC code you can start to make some sense of it. But even just seeing the packages, classes used, and the methods of all the classes is pretty awesome.

So after playing with Nemo 440 a bit I encountered the glaringly obvious question. What happens if I use Nemo 440 to decompile the Nemo 440 application itself? Excited in my geekery, I quickly extracted the SWF file from the AIR app and loaded it in, only to be sorely disappointed. When I decompiled the app I could see all the Flex classes and other libraries that were used (even some components from Flexlib!), but I couldn’t see any classes that were used to do the decompiling. Hmm, I thought, how odd.

I figured that it wasn’t technically possible that the dissassembler would work so well on all SWFs except itself, something was fishy. I mean, that just doesn’t make sense. So I decided to load the SWF into the Sothink Decompiler to have a look. Then I came across this little gem within the Nemo 440 source code:


private function _checkName(param1:String) : Boolean
{
   if (param1 != null)
   {
      if (param1.indexOf("docsultant") >= 0)
      {
         return false;
      }
      if (param1.indexOf("nemo440") >= 0)
      {
         return false;
      }
   }
   return true;
}

That code specifically checks if the package name matches one of the packages used in the Nemo 440 source code and excludes it from being processed! Mother fucker!

So I decompiled the code using the Sothink Decompiler, and then decided I wanted to put it back together into a running app. It took me about 6 hours or so of work, and I had to consult the SWF specification document and the AVM 2 spec document a lot during the process, but I got it working.

So then I had my own AIR app that used the code from the Nemo 440 app to load SWFs and disassemble them. The first thing I did, obviously, was load up the Nemo 440 SWF file and give it a whirl, and I was instantly looking at the full class/package structure and the disassembled ABC bytecode of all the classes.

Ahh, sometimes it feels so good to geek out so much.

For those interested in learning more about decompiling, disassembling, ABC bytecode, and all that good stuff, I’ll be talking about this whole thing and a bunch more stuff in my presentation at Flash on the Beach in Brighton, England on October 1st. I won’t be posting the code that I decompiled and put back together, unless I get the original author’s permission (which I’ll be asking for, but haven’t yet done). Who knows, maybe the guy will be cool with open sourcing it :) but maybe not. And if not, that’s cool too, he put a lot of work into it (I have a great appreciation for the amount of work after reading through much of the SWF spec and seeing the kind of code he had to write).

I just thought the concept of decompiling the decompiler to decompile the decompiler was too cool. God, I’m such a geek.

Related Posts
  • I've just posted the title and description of the session I'll be giving at Flash on the Beach, which is happening September 28-Oct 1 in Brighton, England. My session is titled: Decompiling Flex and Flash. Here's the full description (which you can also find on the FOTB site): In this session we'll learn how to…
    Tags: code, decompiling, flash, decompiled, swf, beach
  • Here are the slides from my presentation that I gave today at Flash on the Beach. The presentation covers decompiling Flash and Flex SWFs and includes an overview of the tools available, a few examples of the kind of code you might see, and some security suggestions. I will not be posting any of the…
    Tags: code, flash, beach, decompiling, decompiled
  • While doing some research for my decompiling session at Flash on the Beach, I came across this gem of a post on the Adobe ActionScript 3 message board. Someone posts a block of code and asks "I’m getting 3 compiling errors when I test my flash movie: could you guys give me some advice on…
    Tags: code, flash, decompiled, decompiling
Standard

13 thoughts on “I just decompiled a decompiler so I could use it to decompile itself

  1. hassan says:

    nice work Doug !
    Here is a question from a flex learner: can your version of nemo440 disassemble some of the swcs and swfs in flex4 framework or is that illegal ?

  2. Just a thought, it should be possible to unzip the swf contents, then find the bytecodes where “nemo440″ string is and just change it to something else with hex editor, then zipping swf back up correctly again? This way you could avoid the 6 hours of trying to make decompiled code compile again properly. Or not?

  3. Oh, ha, after taking a look at Shigeru’s post, I saw the link he has to the abcdump.as file in the tamarin project: http://hg.mozilla.org/tamarin-central/file/dddc6a8b13c3/utils/abcdump.as

    Turns out that that file is exactly what was used in Nemo 440, just refactored a bit and split into multiple files (the code is literally the same). SO I guess the Nemo 440 author didn’t actually have that much work cut out for him, he just modified the abcdump.as file to get it working in his own AIR app.

  4. Andrew says:

    This is actually a common practice with compilers. Using a compiler to compile itself is a very good stress and quality test, the MSVC compiler is made this way.

    I would imagine decompilers are tested with a similar method :)

  5. So, I was wondering how hard it would be to create a Flex Builder plugin that could decompile a SWC/SWF. A use case would be that you didn’t have any documentation on a library and wanted to see what the methods were and so you double-click the SWC in Flex Builder and get a listing of the methods in it.

    I suck at Java, so I’m not going to try it, but it could be useful.

  6. Yaison says:

    “That code specifically checks if the package name matches one of the packages used in the Nemo 440 source code and excludes it from being processed! Mother fucker!”

    ROFLCOPTER!!!

  7. Pingback: tec.

Comments are closed.