Archive for February, 2011

IDA Pro plugin for parsing Java class files constant pool table

February 20, 2011

I am working on a IDAPython plugin to parse the ConstantPool table of a Java class. Here is the snapshot of the output of the beta grade plugin.

Java Constant Pool parser output

Java Constant Pool parser output

I am just having few plans to enhance this to annotate the IDA Pro’s disassembly of Java Bytecode and to improve the readability.  I am not sure whether it is too simple otherwise thinking to submit it for Plugin contest.

Cheers 🙂

Advertisements

Application of Appcall in quick debugging

February 19, 2011

In my earlier blog posts, I have already mentioned how much desirable the IDA Pro’s Appcall and Pedram’s DPC feature is for a reverse engineer.

Today, I found another usecase for applying them in a quick analysis session. So many times, while debugging a malware sample, a reverser would have faced a scenario where the sample invokes a library API call and fails in subsequent steps. There could be several reasons for this behavior. One such reason could the API itself is failed. In these scenarios, it would be very useful to know what is the last error code.

Windows provides “GetLastError()” API for exactly this reason so that the developers can develop a robust code. If the same has to be used in Reverse Code Engineering ( in this scenario ), a reverser should invoke the “GetLastError()” API from the context of the process (the malware sample that is being debugged). This is a perfect usecase to apply the Appcall / DPC.

In this snapshot, it is actually a debugging session of a simple downloader trojan. The screenshot is taken after the sample calls “URLDownloadToFileA()” and I issue the Appcall.GetLastError() and it returns the error code 0x6 which indicates “ERROR_INVALID_HANDLE”

Invoking appcall to get the Error code

Invoking appcall to get the Error code

I am just getting excited to utilize this feature more towards automated analysis.

Cheers 🙂

Android/ADRD trojan analysis

February 17, 2011

It seems the Android trojan created some noise last week. So decided to have a quick look at it.Here is a very preliminary analysis of this sample.

This malware is not backward compatible. It is not installling in Android 2.0 platform. While I tried to install it in an emulator that runs on 2.0, it simply refused to install

Compatibility test

Compatibility test

A quick look at the manifest file shows the receivers and the intent filters

Receivers and intent filters

Receivers and intent filters

You can see that the sample runs in background silently.

Remote command output

Remote command output

Also, a quick look at the app-state dump shows all the receivers in action. Also, the another variant was using a custom implementation of Base64 encoding to obfuscate the URLS.

Decoding the obfuscated URLS

Decoding the obfuscated URLS

Creating a simple script to reuse the decoding function used by the malware reveals the obfuscated urls:

instrumented output of the decoded URLs

instrumented output of the decoded URLs

Looks like the the mobile platform is becoming a hot target for the malware community. We could only see the trend going upwards in the forthcoming months.

cheers 🙂

 

Win32/SpyEye analysis inside IDA Bochs

February 11, 2011

While analyzing a  SpyEye variant inside IDA Pro Bochs, I observed this interesting point. SpyEye, as part of it’s start routine, loads the pieces of the encrypted content in the resource section using “FindResourceA()” and “LoadResource()” APIs. Here is quick snapshot of the data.

Resources of the SpyEye

Resources of the SpyEye

Subsequently after processing the loaded resources, SpyEye injects a thread into Explorer.exe and carries on the payload.

The interesting point here about the analysis is, When I tried to debug the sample using IDA Bochs plugin, the sample immediately terminated during the startup itself. Digging into the reason why it terminates, I just understood that “FindResource()” API is not implemented in the default Bochs config.

Just jumping to the code reveals this:

Code of FindResourceA inside Bochs

Code of FindResourceA inside Bochs

Bochs implementation of FindResourceA

Bochs implementation of FindResourceA

and spyeye specifically checks the loaded resource length to proceed further.

It sometime feels nice to know about whats going on behind the screens.

Cheers 🙂