FakeAV Serial Fishing


I am going to analyze a FakeAV (thanks to MDL) md5: 5493bb325f4b3a1cc6efab226d1c4600. This analysis will be focused on how to spot the serial checking algorithm and retrieve a valid serial.

So we have to locate the routine that checks the serial provided and figure out how to craft a valid serial. Since the sample is packed with a custom packer, we have two ways. The first one is to get rid of the packer (maybe I will write about it in the near future) and then work on the unpacked sample. The second way is to get infected (use a Virtual Machine!) and then attach the debugger to the process in memory :]

Once you have chosen your way, we have to find out how to locate the serial checking function. We know that we have to put a string that will be used by the serial checking routine, so what about setting a breakpoint to trap the access to the serial string ?

Once you have set your breakpoint (@0×507288), we can resume the process and then press the “Activate Now” button, after few msec you will reach the following code:

As we can see from the code above, we have a function that takes two parameters: EAX and ESI, in which EAX is pointing to the serial provided, and ESI instead points to a hardcoded string. If we take a closer look at the location pointed by ESI, we can get the “hardcoded serial” which we are looking for:

So in order to activate the FakeAV, we have to provide a serial which matches the hardcoded one, so our serial must be: 1145-17884799-7733. Finally here is the proof that our serial works:

That’s all. Let me know your comments, so I can decide if I take a look at other samples ;]

I hope you have enjoyed the reading.
See you soon!


Botnet attack report

Hello dear readers,

the last night we have been under an heavy DDoS attack (so lame!), caused by a botnet that has targeted our blog.

Some Details.

The following is a graphical analysis of the botnet that has conducted this attack:

Question/Answer time.

Are we scared? No :]
Will we stop our research? No no :]
Will we stop reversing malwares? No, instead we are going to boost our performace ;]

Final words.

We want to thank our service provider for the help about this issue. Thanks!

Stay tuned!
– the InReverse Crew

JAVA Malware evading decompilation


some days ago Param (thanks!) one of our blog readers sent me a couple of undetected JAVA malwares, which I’m going to analyze, the md5 are:

(Sample 1) 2138bfc0c92b726a13ff5095bd2f2b72
(Sample 2) a0585edf638f5d1c556239d3bfaf08db

At this time, both of this malware have a low detection, the first one 1/42 and the second one 0/42 from VirusTotal.

One of the interesting things is that if you try to decompile these samples by using jD you will get the following notice:

So after a little investigation I figured out the reason. The reason is that jD is unable to handle methods with a large body.

Is it a problem ? No. To proceed with the analysis we can summon JAD. In fact by using JAD we can obtain the full code. Here are some snippets taken from the two samples.

(I will go fast on the analysis, at the end of the post you can find a couple of links with more details about these malwares.)

Sample 1:

Imports reveal a lot of information about what the malware is trying to “use”…

A lot of strings and a known pattern…

Here is the shellcode…

And the exploitation…

Sample 2:
([CVE-2008-5353] )

Again the imports are telling us that the malware will try to load “untrusted” class..

Here the malware gets data and cc fields…

This is the strategy used to run the malware on the victim system:

As we can see we have a long obfuscation that uses string replacements, scrambled names and base64 encoding.

In conclusion, both these malwares are using well known vulnerabilities being exploited since a while. These malwares still have no generic detections at all.

If you are interested you can read more in detail about these vulnerabilities in two of my previous posts here and here.

See ya!

PDF CVE-2010-0188

While analyzing a recent pdf sample exploiting the TIFF vuln it used a known technique to obfuscate it’s content: it appends a pdf to the first one after a bunch of of “garbage” (that contains the dropped executables)


I tried to run my extractor on the sample to retrieve all the streams decompressed but i didn’t found the one containing the famous exploit

The reason why i wasn’t able to recover the exploit is that the second pdf redefined an object (0 1) and so the first dumped stream was overwritten by the last one thus hiding the exploit.

I just did a little modification to preserve all the streams extracted even if there is a id collision, you can download it


JAVA Malware Family

Hello guys,

do you remember one of my last post about a JAVA malware exploiting a vulnerability related to the deserialization? If not, you can read it here.

In the last days I have found a lot of variants of this malware. I picked for this post the following:

sample 1: 3af7627af6348a76d1bf3b7bf31514e0
sample 2: a022524cb52223a939ba50043d90ff94
sample 3: d45a156c76f3c34bac0cf22cb586fdd1

In this post we will try to discover a quick way to detect this “family” of malware.

Each jar comes with 3 classes as for the original sample that I analyzed. The class names are changed into AdgredY, DyesyasZ, LoaderX, for one of these samples.

First thing to note is about the class names. We can note the following relations:

C1. AppletX is AdgredY;
C2. PayloadX is DyesyasZ;
C3. LoaderX is LoaderX.

The class name length is the same as the original one, also the position of the capital letters is preserved.

Let’s proceed.

Here is some snippet of code taken from the Applet subclass of each sample above.

Sample 1.

Sample 2.

Sample 3.

As we can see, the malware authors are trying to conceal their dirty applet by using some obfuscation :]

How we can get rid of this obfuscation? If we pay attention we can quickly extract the following common “flow”:

A similiar analysis can be done for the other two classes: PayloadX and LoaderX.

So the first way to detect this family is by looking at the flow of the program. Flow that in these samples is quite trivial.

Another way to detect this family (a really fast way) is by looking at the ClassLoader subclass. Why? Let’s see. Try to guess, if you want ;]

Sample 1.

Sample 2.

Sample 3.

Well, it seems that the malware authors are customizing the code by using different values for variables and some obfuscation.

But they have one thing that destroys their “obfuscated” castle: the serialVersionUID. As we can see each sample has the same value for this field.

It’s all. I hope you have enjoyed this post.

See you soon :]

JAVA Sound Malware

Hello guys,

I’m sorry for the few posts in the last weeks, but I was quite busy. Today I am going to analyze another interesting JAVA malware.

Our target is a jar, md5: 38f083169319d0141532db992d295448. The jar contains one class: AppletX.  After using a java decompiler on our target, we will get the AppletX class code.

I will report only the relevant parts. Let’s go..

Firstly, the malware tries to discover the operating system in use by using System.getProperty(“os.name”), then it fills str1 according to the O.S. in use.

At this point the malware proceeds by exploiting a vulnerability located into getSoundBank method [CVE-2009-3867] to execute malicious code on the victim system. It retrieves the parameters: sc and np (meaningful names) and then it uses the following spray method in order to place the shellcode:

As we can see, this function simply converts the parameters into hex and then it calls the real spray method:

This method is the heart or engine(if you prefer) of the malware. I have underlined the value of the variable i, since I have found another variant of this malware md5: 52586e8a85188a0ada59294650c91362, that only changes the value of i to an higher value.

This malware is another good reason to turn off all java* contents while browsing the web. As always feedbacks and comments are welcome.

I hope you have enjoyed this post.
See you soon ;]

WoW Infostealer

Just a quick analysis of a WoW infostealer (md5: D214BD51E47DFD3DEA97B5A2ED28CBF5 / ThreatExpert).

The program is a simple dropper, there are no antidebug tricks nor it uses complex obfuscation techniques, it just extracts the DLL (md5: 7DEFE341246BB1DE68A7AFB233FB8CAF) that contains the core of the virus. The dll itself is sprayed on multiple (scrambled) resources inside the dropper:

The resoures are extracted and concatenated to form the dll in: C:\Windows\System32\msnjkwfb.dll, and after that the dropper invokes a function in the dll responsible for the installation and deletes itself.

The installer registers the dll for autorun, retrieves the WoW path, and copies inside it the dll under the name msvcr70.dll, after, it injects code into the WoW exacutable (wow.exe): adds a section (.ngaut) and changes the program entrypoint to its code. The injected code just loads msvcr70 and gives control back to the original entrypoint.

When the dll is loaded by wow.exe it starts searching for the main window, and then does some checks on the window’s title “World of Warcraft” and class “GxWindowClassD3d” if both checks succeeded it acquires the SeDebugPrivilege and spawns a thread that collects the information using static offsets into the program. Once all the information is gathered it sends a HTTP request to:

with the following request:


the site is still up at this time, so be careful WoW gamers 😛

p.s. for those interested here the py script to descramble and merge the extracted resources