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 🙂

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 🙂

 

 

Dynamic analysis of a Java malware – OpenConnection

January 11, 2011

The general trend of malware implemented in Java programming language is increasing. Thanks to Java’s platform independent bytecode technology and the wonderful VirtualMachine.

Analysis of Java bytecodes is relatively simple task (unless it is obfuscated). There has been some very nice tools to decompile the bytecode back to source with great accuracy.

For a change, in this blog post, I have chosen to write about the dynamic analysis of a Java Applet. The entire analysis is carried out inside a controlled (simulated) networking environment using Zelster’s Remnux VMImage as the internet server.

Payload of OpenConnection:

  • As the name suggests, the Applet accepts a parameter named “URL”.
  • It opens a URL connection with the URL (typically an executable file).
  • It reads the binary data from the Socket’s input stream and writes it to a File object’s OutputStream (in %temp% folder).
  • Once, the file is successfully downloaded, it spawns the downloaded executable.

Ok, the payload is very familiar one and nothing exciting about it. Lets see the dynamic analysis steps:

Step 1: Decompile the class file. There has been many decompilers available. [I personally use jad or jd-gui]

Step 2: Include some debug statements (some System.out.println statements here and there to print value of the variables )

Step 3: Compile the file to create the class file and pack it as a jar archive.

Step 4: Now, to satisfy the Java security model, an Applet has to be signed to access local file system and do process related activities. We use JDK’s keytool and jarsigner for this step.

Signing the jar file

Signing the jar file

Step 5: now the jar file is signed, we will host this jar file along and a companion html file to the Remnux server.

Step 6: Now start the FakeDNS.exe in the test machine and resolve all the domain queries to the Remnux server.

fakedns in action

fakedns in action

Step 6: To create a perfect ecosystem for the malware to flourish without any obstacle, we need to lower the Java’s default sandboxing security policy. This can be done by JDK’s policytool.exe

Changing default policy to grant all permissions

Changing default policy to grant all permissions

Step 7: With everything set, access the html file hosted in the remnux server that embeds applet into it.

Step 8: The user is presented with a warning about the active content about to be executed and asks your approval to trust the self signed certificate.

Certificate prompt

Certificate prompt

Step 9:Now, the init() method of the applet is called, which inturn invokes the method that opens a connection to an executable (again hosted in remnux server. in this example, i have hosted winmine.exe)

Step 10: The debug messages can be seen in Java Console.

Debug messages in jconsole

Debug messages in jconsole

Step 11: Once the sample is downloaded, it spawns the executable. (in this case winmine.exe). The Parent-child relationship can be seen through process explorer.

Process Explorer to verify the the IE -> Java -> winmine

Process Explorer to verify the the IE -> Java -> winmine

This stresses the importance of paying attention to the security popups even during a casual browsing session.

Cheers 🙂

 

 

Hardware Breakpoint is now supported by VirtualBox (Bug:477)

December 5, 2010

Just a good news for VirtualBox users (especially Reverse Engineers). The earlier versions of virtualbox VMM/RAW module was not supporting hardware execution breakpoint in Ollydebugger. I just gave it a try with 3.2.12 and it has got fixed. Strange that this does not got mentioned in the release notes.

screenshot.

Hardware BP in action

Hardware BP in action

Cheers 🙂

Using Appcall and DPC for analyzing hash resolution

October 17, 2010

Last week I went through a very nice blog of Elias Bachaalany (http://www.hexblog.com/?p=193). It was an extremely nice read to demonstrate the power of Appcall feature of IDA Pro and how it helps to explore the analysis of malware interesting and easy.

In the same time, I was also thinking about the legendary Pedram’s PAIMEI and decided to play with the same malware using PAIMEI and cameron’s Debugee Procedure Call.

Just a short recap of EB’s blog: The incident is about a malware that uses hash of the library code as the key to resolve the API at runtime and the idea is to use DPC to invoke the function of the malware (the function responsible for resolving the APIs through hash) at our will to explore the behavior.

 

DPC in action

DPC in action

 

It worked like charm.

Now, what remains a mystery is why the great pydbg and all of the scripts stresses that it has to be attached to a malware instead of “loading” it from the scratch despite In many cases loading a malware would be ideal.

Cheers 🙂

VirusTotal plugin for IDA Pro and Immunity Debugger

August 1, 2010

While analyzing virut’s anti-AV tricks, I felt the need of VirusTotal plugin for IDA Pro or Immdbg. Here is a simple plugin and operational screenshots.

IDA Pro virustoal plugin

IDA Pro virustoal plugin

and

Immunity Debugger Virustotal plugin

Immunity Debugger Virustotal plugin

Currently, the code is not very neat. Just waiting for the new VT interface that has support for python JSON request and response.

cheers 🙂

Graph theory for Malware Analysis

July 1, 2010

Thanks to Ero Carrera.

Last few days, I have been practicing applying Graph Theory for malware classification and analysis. The basic idea is to convert the disassembly of the sample into a directed graph and calculate the following four metrices.

  1. Cyclomatic Complexity
  2. Indegree of the procedures
  3. Outdegree of the procedures
  4. Histogram of the significant instructions

I have built a simple utility on top of IDA Python that can query the IDB file and create a easy navigatable HTML file with interactive javascripts to load the procedures.

Disassembly of the malware

Disassembly of the malware

Once the auto-analysis is completed, run the utility.

Once the utility completes its execution it produces a DHTML file which will look like this while starting.

Output DHTML file

Output DHTML file

Then, selecting the core payload procedure and loading it results in displaying the plotted graph for that function.

And processing different variants (probably created by some Trojan Development Kits) yield the same metrics regardless of their different structure and size.

I am further studying this approach to come up with some more solid results.

Cheers 🙂

Analysis of a backdoor trojan for Linux platform

June 5, 2010

For the past few days, there has been so many debates and opinions about the idea to switch to non-PE platform following the “Aurora” incident.

Hence, I thought it might be timely to look for some ELF binaries in the honeypot. The target is a very simple, reverser friendly backdoor trojan “Linux/Smalldoor.A”.

Dynamic Analysis:

I executed the sample in a Xubunu 9.04 image along with the strace utility.

Upon execution, the backdoor is kind enough to greet with the port details and some friendly mesage.

Starting the backdoor trojan

Starting the backdoor trojan

Knowing that the trojan is listening on port 1144, I decided to interact with it. Hence opened a telnet session.

Interacting with the binary

Interacting with the binary

As expected, the backdoor communication prompts for a password to start the communication. The authentication part is simple we shall see the password retrieval and the list of valid commands details in the static analysis part.

Static Analysis:

Static analysis was needed to know the password and the valid commands accepted by the malware.

Using IDA pro, I disassembled and reduced the visualization graph to reduce to basic flow. Here is the overview:

Overview of control flow

Overview of control flow

and here are the disassembly of the important functionalities.

Starting backdoor port.

starting_Backdoor_listing

starting_Backdoor_listing

Login module of the backdoor (password authentication):

Login module listing

Login module listing

and finaly the core payload (multi-process application)

core_payload

core_payload

and here is the Strace output (filtered to reflect only interesting aspects):

[b809b430] write(1, “Starting backdoor daemon…\n”…, 28) = 28
[b809b430] socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
[b809b430] setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [0], 4) = 0
[b809b430] bind(3, {sa_family=AF_INET, sin_port=htons(1144), sin_addr=inet_addr(“0.0.0.0”)}, 16) = 0
[b809b430] listen(3, 5)           = 0
[b809b430] getsockname(3, {sa_family=AF_INET, sin_port=htons(1144), sin_addr=inet_addr(“0.0.0.0”)}, [16]) = 0
[b809b430] write(1, “Listening to port 1144\n”…, 23) = 23
[b809b430] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7f29708) =

Such a binary could well be considered as a clean utility designed for an organization specific needs. However, one could sense malware with anti debugging tricks and heavy obfuscations sooner if the trend continues.

Feedbacks and suggestions are welcome:

Cheers 🙂