Wednesday, May 20, 2015

Decompiling an illegal 'patch' application - does it secretly install or run malware? - Part 2

Recently I looked inside an illegal application patch, that 'unlocks' an application by messing with the license code checks of the application. I was convinced that the patch would do not only that, but also install some form of malware on the computer. As it turns out: that particular patch didn't.

So I decided to take a look into another one. As opposed to the previous patch application, this one wasn't written in .NET, so not only the decompilation will not be as easy, also the decomiled sources will probably not be as meaningful.

For decompilation, there is of course Boomerang, which is free and open source, but I decided to see if there is an online 'decompilation as a service'. Turns out there is at

OK - let's run the patch through this decompiler:

OK - you can inspect a whole bunch of things here, but you can also just download everything. That's what I did. In the downloaded zip, there is the decompiled machine code, the call graphs and decompiled C code.

Looking a the callgraph, I didn't see anything that got my alarm bells going or anything. Again, an attempt was made to mess with the applications .dll files.

So let's see if I can make anything from the C code:

At the bottom of the file - the external function calls are listed. Turns out the application calls into the Windows API, seems to be messing with some files and things, but nothing really surprising. OK, let's see what this looks like in code:

I found code that I didn't really grasp and had to start Googling. The code tries to get a handle for the running process and then starts looking for dlls. That's remarkable since the patch application is just one .exe file. There are no dlls with the application - let alone something called 'dup2dispatcher.dll'.

... or are there? That brought me to this post: which talks about packers - and how it is often used to disguise malware. Although I haven't seen any malicious code yet, I'm a bit more suspicious of course.

Inspecting the application with the ExeInfo tool, reveals the dup2patcher.dll, which is packed inside the EXE:

So - the patch logic or malicous code could be in there. It seems like that .rsrc section holds the actual dll source and you can save it off to your disk. Insepecting the bytecode revealed this XML section at the bottom, which is an assembly manfiest:

I can read this, which makes me think that none of the obfuscation techniques were applied as suggested in the mentioned blogpost. However, I'm not able to inspect this code with DotPeek.

So ... I'm afraid this is how far I could come. As you can see - the only dependent assembly is Windows.Common.Controls. Since the patch probably has some kind of windows form - that all makes sense. I would have expected system.web in case the assembly went out to connect to some remote box or download some kind of executable.

However - I haven't been able to look inside this dll, so this is where it ends for me. If you have any tips - please drop me a line or suggestion.

1 comment: