Tag Archives: decompiling

Flex/Flash/Actionscript

Slides from my Flash on the Beach session on decompiling SWFs

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 code that I showed during the session (apart from the very tiny snippets in the slides). I think it’s pretty obvious why I’m not going to post the decompiled Photoshop Express code šŸ™‚

I don’t think there’s any formal feedback survey or anything at FOTB, so if you were at my session I’d love to hear what you thought about it. You can email me at doug@dougmccune.com or leave some comments here. Let me know what you liked and what you didn’t.

Standard
Flex/Flash/Actionscript

If you steal source code, don’t ask for help fixing it

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 how to sort out these issues and correct them. its driving me crazy trying to resolve the problem.”

And then he posts the code. And if you have ever decompiled any ActionScript code, it’s painfully obvious what the guy is doing: he’s ripping off someone else’s code, then complaining in the Adobe forum that he can’t figure out why it won’t compile, and asking people to fix his broken, stolen code.

Here’s a snippet of his code:


public function BEShell()
        {
1  0 39            instance = this;
            Logger.target = new FirebugTarget();
            var _loc_1:* = loaderInfo.loaderURL;
            if (_loc_1.indexOf("env1") != -1 || _loc_1.indexOf("Akqa") != -1 
                        || _loc_1.indexOf("dev.site.com") != -1)
            {
            }
            else
            {
                Logger.mode = Logger.PRODUCTION_MODE;
                stage.addEventListener(KeyboardEvent.KEY_UP, keyHandler);
            }// end else if
            return;
        }// end function

That’s very clearly, without question, decompiled code. It even has some extra line number information included in the dump! And that’s what was tripping the guy up. He couldn’t understand why that beginning line that starts with “1 0 39…” wouldn’t compile!

Sometimes I’m just amazed by people. Like, really? You have the balls to steal someone’s code, then post it in a public forum and ask for help?

And of course maybe I’m totally off base, maybe the guy works for the company that originally wrote the code (seems to be a Flash agency called AKQA) and maybe he just got pulled in to fix some co-workers work and they lost the original source and they need to use decompiled code since that’s all they have… yeah… maybe…

Standard
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.

Standard