Android Malware Analysis - Static Analysis of HolyF******Bible

You can get the Trojan on Contagion Malware Dump site
http://contagiodump.blogspot.com/2011/03/take-sample-leave-sample-mobile-malware.html
Direct Link
http://www.mediafire.com/?z4296jczsx4jc3d

Begin by renaming the .apk file to a zip file. This gives access to the contents of the .apk file.

We can see the classes.dex file. 

Let’s use Dex2Jar on the Classes.dex file to get access to the application code.

Don’t start exploring the code as yet. It is always better to have the AndroidManifest.xml file handy when exploring the code. So let’s get it using AXMLPrinter.

Its always better to have a look at the AndroidMannifest.xml file to start with. It gives an idea what kind of permissions the app is asking from the user. 

The manifest file for the current app indicates a few interesting things.

The app has requested permissions for the following 

Read and send Sms

Access Contact information

Understand when the device boots

Set wallpaper 

Its always good to have an eye open for components or modules mentined in the manifest file and check the workings of that module in the class files

For instance, receiver android:name="com.YahwehOrNoWay.PostingServiceReceiver" which we see in the manifest file can also be seen in the code obtained from the .dex file. 

If we inspect the code closely we can see that the app keeps a check on when the device boots itself. Perhaps it triggers something when the app boots?

Looking at the manifest file gives a feeling that the component ‘YahwehOrNoWay’ will have a lot of juicy stuff. Let’s explore it more in the code.

The app is creating a service named ‘theword’. This would keep running in the background and probably monitor the device for trigger events.

If we inspect the code below, it gives an indication that the app runs its operations at fixed time intervals.

Close inspection of another piece of code gives an indication  of another trigger point.

localStringBuilder1.toString().matches("05212011"))

This indicates that the date 21/05/2011 is a trigger event for this particular app. If you have been following the news this date has been prophesized to be **drum rolls** The day the world ends (again). It was stated by radio host Harold Camping that this day marks the Rapture and Judgement Day. This is another indication of how much the malware writers use Social Engineering.

Another trigger point is specific messages sent to the app. There are four such cases

Case I : String "formula401"

This commands instructs the trojan to send contact information to a file hosting site 'turbobit'.

Case II: String "pacem"

This command instructs the trojan to send a download recommendation to all contacts on the phone.

Case III: Date is 05/21/2011

The trojan creates a database mydb.db when it detects that the date is 21 May 2011.
It adds some values to the database and sends these values as a reply whenever an SMS is sent to the device

I wanted to show this behavior in real time on two simulators but sadly this behavior was not being replicated. I will surely try again and update.
Also, the wallpaper is changed as shown in the code below

Case IV: Date is 05/22/2011

The trojan replies a message 'Looks like Jebus is a no show, maybe Judaism was on to something' to any SMS received by the device.

Also, the wallpaper of the device is changed as shown in the following code.

As you can see the trojan is fairly capable of many things, most prominent includes sending vital information about the contacts present in the phone to the author thereby stealing sensitive information. Also the trojan spreads by enticing people present in the contact list to download the same app thereby spreading even more.

Reverse Engineering Tutorial #1

Here we will try to remove a nag screen. The term nag screen essentially refers to a screen or banner which is displayed when a particular tool/ program runs. This usually comes at the start of the program with some message. In this tutorial I will show one such example.

The application we are looking at is a third party Calculator.

When we open the application we see a Nag screen for a brief period. Our aim would be to remove this nag screen for appearing when we run the program

The nag screen is sort of a dialog box, so it makes sense if we say that its part or a component of the program. So it makes sense if we think that somewhere in the code the author would be instruction the program to display this dialog box, or in other words, "Push" this dialog box on the screen. This is a important thing to remember regarding this program.

Now there are tools which show different parts or components of a program, to help us understand the program in a better way. One such tool which we will be using is ResourceHacker.

Open the executable in Resource Hacker and we can see different parts of the program.

 

The component of our interest here is the 'Dialog'. Expand it and we can see Dialog Boxes which make the program.

As you can see, clicking on each Dialog entry shows the corresponding code and the output which enables us to see how the dialog looks in the program. Now where is that pesky nag screen ....

Aha!!! here it is. Note that this Dialog has a number 105. This is the decimal representation for this dialog box. The Hex equivalent would be 69. So essentially we are looking for something like "PUSH 69" in the code for the program. So lets find it.

Open the program in our favorite Disassembler, Olly Debug



Right click and search for 'Command' and enter PUSH 69

Once you see where the nag screen is being pushed onto the screen, we can simply out NOP statements there. NOP essentially means No Operation so the processor is idle at these instructions. So no push, no nag screen.



Now save the changes made

Once saved, try running the executable. Much to our joy, we don't see any nag screen now.


So there you have it, a nag free Calculator program =).

So the key learnings from this tutorial would be:

• Examining a program and identifying a particular part or component which we want to remove
• Calculating and locating the probable code responsible for the nag
• Finally removing it so that it is not a nag anymore

Crack Me, You learn

Reverse Engineering applications is a very daunting task. We have to go through a huge labyrinth of numbers and letters, just to make little sense of what is actually going on.

Even if we know most of the theory which supports the field, its never enough until we practice on actual running executables. To help us out of this jeopardy we have nifty executables called CrackMe's.

Crackme is a small executable which is generally made for the purpose of learning Reverse Engineering. The goal of the authors is to create an executable small enough and simple enough to teach a thing or two about Reversing executables and yet be simple and small enough that students/ practitioners don't get overwhelmed by data.
Think of it as a sort of assignment/ challenge for a student of this field.

There are a number of sources where these CrackMes can be found. I will list just few of them and keep adding as and when I find more.

Along the same lines you will find a number of 'Reverse Engineering Tutorials'. These are not so different than CrackMes. Main difference here is that the authors of these tutorials use small programs and executables which are very old so that there is little or no issue of the makers of those programs complaining. Again these are an excellent source to learn and improve your Reverse Engineering skills

CaptureBat - Dynamic Malware Analysis Tool

As I mentioned in one of my previous posts about tools for Dynamic Malware Analysis, CaptureBat is a very essential tool for this purpose. This tool shows us verbose output of the things happening at the registry, file and processes level.

Starting off with Capture Bat
One of the easiest ways to go through the information captured by this tool is to copy the output in a text file for easy reference

But this limits the overall efficiency as it can geta little cumbersome to go through the captured data of a malware which was running for about 5 minutes or so. Its always good to have a way in which we can categorize, search and filter the contents to our liking. Guess what, we already have a way...Excel.

Efficiency through Excel
We can export the captured data into an excel sheet and take benefit of the excellent filtering capabilities. T start off, simply capture the data in a normal CaptureBat file and import it into excel.

When Importing into Excel choose file type as 'Delimited'.






As of now I have observed that choosing the options 'Tab', 'Space' and ':' in 'Other' works best for me.



Once done, we get the output in an Excel as shown below.



We can use filters to narrow down on the type of operation we want to check. For instance we can choose to only see the 'write' operations performed.

Dynamic Malware Analysis Tools

It would not be wrong to say that every malware has its personality. Not that we want to start treating malwares like living things but the comparison is justified based on the different ways a malware behaves. To study a part of this dynamic behavior we will be using some tools

Autorun
This tool is used to check what is running at system. This helps in understanding if a malware has set itself to run at startup

Process Explorer
This tool can be used as an alternative to Task Manager as well as checking the processes, threads as well as DLLs curently loaded on the system


Process Monitor
This tool can be used to keep an eye on the events happening on the system. This tool monitors Registry, file level, network processes, thread changes happening on the system

ListDLL
Used to display DLLs loaded on the system

TCPView
Lists active TCP/UDP endpoints

WinObj
Shows windows object namespace

BinText
Can be used to extract text present ina a particular executable

RegShot
Allows us to take two snapshots of the system recording registry level changes between the two. These can then be compared with each other to understand the changes which were introduced once the malware ran

CaptureBat
Captures events happening on the system at the file, registry, processes and network level

HandleDiff
Detects changes to handle tables of processes

WireShark
Capture incoming as well as outgoing traffic from a particular machine

MalcodeAnalysisPack
Package which contains applications which have been proven useful for analysis purposes

Remnux
Lightweight Linux distro for assisting malware analysts in reverse engineering malicious software

This is not an exhaustive list, but these are some of the tools which would be used most frequently for the purpose of malware analysis. I will provide examples and detailed use for some of these tools shortly

Virtual Machine for Android reverse Engineering A.R.E. Released

The Honeynet Project has released Android Reverse Engineering (A.R.E.) Virtual Machine. The Android Reverse Engineering (A.R.E.) Virtual Machine, put together by Anthony Desnos can be used for reverse engineering Android Apps. A.R.E. combines the latest Android malware analysis tools in a readily accessible toolbox.
Tools currently found on A.R.E. are:

• Androguard
• Android sdk/ndk
• APKInspector
• Apktool
• Axmlprinter
• Ded
• Dex2jar
• DroidBox
• Jad
• Smali/Baksmali

Download Here

I will shortly put up a tutorial for analysis of Android App using the same VM.

Android Malware Analysis - Part I - Static Analysis

Android is a very lucrative and popular domain for malwares currently. We see a number of attacks and threats happening very frequently.

In order to analyze malwares for Android platform we need a controlled setup with a number of tools which have a specific purpose and role in the analysis. We mainly distinguish the analysis into two sections, the static analysis and dynamic analysis.

In this part I will be highlighting tools for static analysis.

Dex2Jar

We can use this on the classes.dex file. Classes.dex contains the application code compiled and converted into Dalvik Executable format. This tool converts classes.dex back into a jar file with regular Java classes inside, the jar file can then be decompiled using any good Java decompiler.

1.       Download Here
      
2.     Go into the directory where dex2jar.bat is present

3.     Dex2jar.bat **location where the classes.dex file is present**

4.    This gives us a Classes_dex2jar.jar file

JD GUI

We can use this to view the contents of the now converted .dex file. Contents are visible in a crisp GUI which is easy to understand.

Usage:

1.       Download Here
     
2.       Simply open the .jar file in JD GUI

AXMLPrinter

This can be used to convert the AndroidManifest.xml file into a readable text file.

Usage:

1. Download Here
2. Java –jar AXMLPrinter.jar **location of AndroidManifest.xml**

Notable mentions (I will try to cover these soon)
APKInspector - http://www.honeynet.org/node/761
Understand Static Analysis Tool  - http://www.scitools.com/download/index.php
Androguard - http://code.google.com/p/androguard/
Droidguard - http://code.google.com/p/droidguard/

Win32 API - Part II

Creating the Window

HWND hwnd;

hwnd = CreateWindowEx(
     WS_EX_CLIENTEDGE,
     g_szClassName,
     "The title of my window",
     WS_OVERLAPPEDWINDOW,
     CW_USEDEFAULT, CW_USEDEFAULT, 240, 120,
     NULL, NULL, hInstance, NULL); 

 WS_EX_CLIENTEDGE - extended windows style

g_szClassName - tells the system what kind of window to create. We want to create window from the class we just registered. 

CW_USEDEFAULT, CW_USEDEFAULT, 240, 120, - X, Y co-ordinates and width and height of window

In windows, the windows on your screen are arranged in a heirarchy of parent and child
windows.  When you see a button on a window, the button is the Child and it is contained

within. the window that is it's Parent.

The Message Loop

Pretty much everything that your program does passes through this point of control 

while(GetMessage(&Msg, NULL, 0, 0) > 0)
{
    TranslateMessage(&Msg);
    DispatchMessage(&Msg);
}
return Msg.wParam; 

GetMessage() gets a message from your application's message queue. 

Any time the user moves the mouse, types on the keyboard, clicks on your window's menu, 

or does any number of other things, messages are generated by the system and entered into your 
program's message queue 

By calling GetMessage() you are requesting the next available message to be removed from the queue 

and returned to you for processing.

Window Procedure

This is where all the messages that are sent to our window get processed.

LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
    switch(msg)
    {
        case WM_CLOSE:
            DestroyWindow(hwnd);
        break;
        case WM_DESTROY:
            PostQuitMessage(0);
        break;
        default:
            return DefWindowProc(hwnd, msg, wParam, lParam);
    }
    return 0;
} 

Window procedure is called for each message. HWND parameter is the handle of your window.

HWND will be different for each window depending on which window it is.

WM_CLOSE is sent when the user presses the Close Button, but its good to handle this event, since this 

is the perfect spot to do cleanup checks.

DestroyWindow() the system sends the WM_DESTROY message to the window getting destroyed 

Since we want the program to exit, we call PostQuitMessage()

Win32 API - Part I

This post will have the basics about Win32 API. I am following the tutorials on http://www.winprog.org.

 Make sure you have specified Win32 GUI and not console.

First Example 

#include <windows.h>

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, 
    LPSTR lpCmdLine, int nCmdShow)
{
    MessageBox(NULL, "Goodbye, cruel world!", "Note", MB_OK);
    return 0;
}

WinMain()                         - windows equivalent of Main(). This is where our program starts execution.

HINSTANCE hInstance        - handle to the programs executable module

HINSTANCE hPrevInstance  - Always NULL for Win32 programs

LPSTR lpCmdLine               - Command line arguments as a single string

int nCmdShow                    - An integer value that may be passed to ShowWindow() 

Second Example

#include <windows.h>

const char g_szClassName[] = "myWindowClass";

// Step 4: the Window Procedure
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
    switch(msg)
    {
        case WM_CLOSE:
            DestroyWindow(hwnd);
        break;
        case WM_DESTROY:
            PostQuitMessage(0);
        break;
        default:
            return DefWindowProc(hwnd, msg, wParam, lParam);
    }
    return 0;
}

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
    LPSTR lpCmdLine, int nCmdShow)
{
    WNDCLASSEX wc;
    HWND hwnd;
    MSG Msg;

    //Step 1: Registering the Window Class
    wc.cbSize        = sizeof(WNDCLASSEX);
    wc.style         = 0;
    wc.lpfnWndProc   = WndProc;
    wc.cbClsExtra    = 0;
    wc.cbWndExtra    = 0;
    wc.hInstance     = hInstance;
    wc.hIcon         = LoadIcon(NULL, IDI_APPLICATION);
    wc.hCursor       = LoadCursor(NULL, IDC_ARROW);
    wc.hbrBackground = (HBRUSH)(COLOR_WINDOW+1);
    wc.lpszMenuName  = NULL;
    wc.lpszClassName = g_szClassName;
    wc.hIconSm       = LoadIcon(NULL, IDI_APPLICATION);

    if(!RegisterClassEx(&wc))
    {
        MessageBox(NULL, "Window Registration Failed!", "Error!",
            MB_ICONEXCLAMATION | MB_OK);
        return 0;
    }

    // Step 2: Creating the Window
    hwnd = CreateWindowEx(
        WS_EX_CLIENTEDGE,
        g_szClassName,
        "The title of my window",
        WS_OVERLAPPEDWINDOW,
        CW_USEDEFAULT, CW_USEDEFAULT, 240, 120,
        NULL, NULL, hInstance, NULL);

    if(hwnd == NULL)
    {
        MessageBox(NULL, "Window Creation Failed!", "Error!",
            MB_ICONEXCLAMATION | MB_OK);
        return 0;
    }

    ShowWindow(hwnd, nCmdShow);
    UpdateWindow(hwnd);

    // Step 3: The Message Loop
    while(GetMessage(&Msg, NULL, 0, 0) > 0)
    {
        TranslateMessage(&Msg);
        DispatchMessage(&Msg);
    }
    return Msg.wParam;
}

Window Class - stores information about type of a window, this includes the window procedure which controls the window, small and large icons 

for the window and the background color.

The important points will be explained later, do not try to memorize the above parameters.

Huge Contagion Malware Collection

Contagio has released a huge bunch of malwares as part of their Version 4 April 2011 archive

1) COLLECTION 1 - 240   251 files (70 MB) - Email attachments from targeted attacks

2) COLLECTION 2 - 7 10 files (3 MB) - Zero day files

3) COLLECTION 3 (from Stephan Chenette) - 118 Files (5MB) - Web exploit pdf files +

4) COLLECTION 4 (from Stephan Chenette) - 10,980 Files (243 MB) - Web exploit pdf (I think they all are pdf) files

5) COLLECTION 5 Non-Malicious PDF Collection (from Stephan Chenette) - 6,052 clean files (1.4GB) 

6) COLLECTION 6

 Happy hunting  

 

 

 

 

Malware Sample Sources

So where do we get the Malware samples from... except the infected machines in a Cyber Cafe of course

(The sources are listed in no particular order)

Malware Domain List
Malware Bytes (newest malware threats )
Tuts4You

Malware Analysis tools chest: ClamAV

ClamAV is not a tool for analyzing malwares per se, it is more of a tool for organizing and is mainly useful in the pre-analysis stages.

Many malwares are analyzed and studied on a daily basis by researchers, companies, hackers and the curious  kids of the present age after they finish their homework, sigh!  Its always challenging, fruitful, satisfying to analyze a new malware which has not been touched and studied by others. That gives a rush ! So before analysis, why not make sure that its not analyzed before ? Enter ClamAV ...

ClamAV is used for classification of malwares by many malware analysts. Its always advisable to put the executable through ClamAV to understand if someone has analyzed it. We can refer to the analysis to gain knowledge about the malware, compare our analysis with the other and thereby understand how potent our methods of analysis are.

Virtual Machines for Malware Analysis

An ideal setup for Malware Analysis would be to have a machine where we can readily install and execute malicious programs. But given the nature of malicious programs, they may cause permanent and irreversible damage to the machine. To protect a machine from such damage Virtual Machines are used.
A Virtual Machine is a OS running within an OS. Softwares like VMWare and VirtualBox allow emulation of multiple Operating Systems on a single physical system.

Advantages of using a Virtual System:

• Safe environment to infect: We can safely infect a virtual machine without harming the base system to some extent (more will be explained about this later). This allows us to boldly analyze dangerous malwares which we would otherwise hesitate to analyze.   
• Snapshots: A snapshot taken in a Virtual Machine saves the state of the virtual OS 'at that point of time'. In the event of a system crash due to the malware, we can travel back to the state when the snapshot was taken.
• Host-Only Networking:  This is convenient for interconnecting virtual systems using a simulated network without additional hardware. The host-only network allows any virtual system to see all traffic on the simulated network when listening in promiscuous mode.This makes monitoring the specimen's network interactions easy.
• Multiple environments: Using virtual machines for different OS allows us to perform analysis on different Operating Systems. It is more feasible for people to have multiple systems with different OS  rather than buying different systems with multiple OS. Malwares usually behave differently on different OS and different versions of the same OS. Having multiple OS allows us to analyze malware behavior on different systems and thus get a better understanding of the malware.

So just how do I analyze Malware ?

There are two main ways in which Malwares are analyzed
1. Behavioral Analysis
2. Static Analysis

In Behavioral Analysis we observe the behavior of the Malware. We observe and record what changes the Malware is doing to the system it is infecting, how it is trying to stay under the hood undetected by the user of the machine.
This includes the use of tools like RegShot which shows us exactly what keys/files the malware is trying to modify, also a basic observation of system behavior is needed

In Static Analysis we try to analyze the Malware by observing the code of the program in question. Generally we go through the Assembly level code of the program and try to observe peculiar actions performed by it. There are certain actions which are peculiar to Malware behavior, if the same actions are found in the program, it is highly likely that the program is malicious in nature. We use Disassemblers like IDA Pro and Debuggers like OllyDBG for this purpose.

Both the methods have their Pros and Cons but both are very instrumental for a deeper, much thorough analysis.
Think of it like two sides of a coin.

I will shortly cover in depth about both the techniques mentioned in the post.

First Post

Let me set the context in the 'First Post'.
My aim in this blog is to analyze different types of Malwares. I would be analyzing both past as well as latest malwares.
I would try to explain a bit about the different Packers which are used in Malwares.
I will also shed some light on different techniques used in Malwares to make the life of a malware analyst difficult.