In this article we will get an introduction into mobile malware on Android. The main goal is to give you an overview of the tools used and provide you with a starting point for next work.We will use some webservices that provide a good overview of the malware and later specialized tools to understand the details.

This sample is a example malware(syssecApp.apk) written for Reverse Engineering Summer School 2013 (Organized by Ruhr University-Bochum). It provides an overview of what Android malware is able to do. It is not linked to a control server, so the data it steals will never leave our phone. However some personal data will be visible in the logs and during our analysis, so we should use an emulator anyway.

Basically;

1 – Basics of Android Applications

Android is an open-source mobile operation system. It is now being developed by Google and is based on a Linux kernel. The applications are written in Java and are transformed into a slightly different format known as Dalvik. The apps are then run in the Dalvik virtual machine which provides a layer of abstraction over the real hardware. This way most applications can be run on any Hardware as long as the API of the Operating system meets the requirements of the app. Besides the Java part native code can be used. This needs to be provided along with the application and must be compiled for all target platforms. The native code should mainly be used for computation intensive tasks like graphic rendering. Below the Dalvik VM lies the Linux kernel, which provides hardware abstraction and rights management. The permissions requested by the Application are enforced by using Linux users and groups, so so far every malware known had to acquire needed access rights the official way.

Android applications are packed in the format apk, which is a ZIP archive containing the AndroidManifest.xml, resources like media files, the actual code as classes.dex and some other optional files. The XML provides the Android system with important information like which class to use when starting the app and what permissions are needed. Only permissions listed in this file will be provided to the application, if it tries to use any other the call will either fail or return an empty result. When installing an application these permissions are shown to the user, who must make sure that he reviews them to prevent malicious apps from accessing important data or being installed in the first place. The code is contained in classes.dex, which is a collection of all compiled classes. Instead of the regular format used in .jars all classes are packed into one file which saves some space on the mobile device.

2 – Analysis Tools

In this part we will use some of the popular Android analysis tools. There are far more available than discussed here, but we will focus on the ones that provide you with good results for the our sample.

2.1 Dexter

Dexter is a webservice that allows the upload of Android applications which will then be statically analysed. It provides a quick overview of the metadata of the application and the included packages. The package dependency graph shows all packages and its interconnections with the ability to quickly open the method list of each one. The method list shows all classes and its functions. When looking at a function all API calls will be listed which allows a basic understanding of the purpose of the function. By clicking on BBL graph the Smali representation of the code will open. Smali is a Disassembly format for Dalvik code which lists the commands executed by the virtual machine.

2.2 Anubis

Anubis is a webservice that allows the execution of Windows and Android binaries in a sandbox. Each sample is run independently of each other. The resulting report lists any activities of the application including file system and network activity. Also some static analysis results are provided including the permissions with the distinction between permissions specified in the XML and the ones used via API-calls during the execution. Usually a screenshot and, if applicable, a tcpdump of the traffic is provided.

2.3 APKInspector

APKInspector is a collection of many tools in one user interface. After the .apk has been loaded you can load the Smali representation of functions by selecting the function in the Methods tab in the sideview. APKInspector comes with Jad , a Java decompiler. It should be able to decompile most classes, but regularly creates mistakes that either prevent a recompilation or sometimes make the class very hard to understand. Also it might fail completely in some cases, then the Smali representation must be used.

2.4 Dex2Jar

Dex2Jar provides a way to transform the classes.dex of an Android application into the jar format which can be read by other Java reversing tools. For example Dex2Jar is used by APKInspector to transform the given jar into a format understood by Jad before the decompilation is started. If you are experienced with Java Reverse Engineering and have some favourite tools you can still use them after running Dex2Jar, even though specialized tools might provide more information on the used APIs. My suggestion is APK to Java RC2: http://forum.xda-developers.com/showthread.php?t=1910873

3 – Analysis of the Sample Malware

In this part the sample malware will be analysed. The main goal is the introduction into the tools used for analysing it. The process given here is just an example, you can and should try other ways to understand the malware.

3.1 Analysis with Anubis

The first notable thing in the report is the big list of permissions required by the application:

android.permission.READ_SMS

android.permission.RECEIVE_SMS

android.permission.READ_USER_DICTIONARY

android.permission.INTERNET

android.permission.READ_CONTACTS

android.permission.ACCESS_FINE_LOCATION

android.permission.READ_CALENDER

com.android.browser.permission.READ_HISTORY_BOOKMARKS

android.permission.WAKE_LOCK

android.permission.RECEIVE_BOOT_COMPLETED

android.permission.READ_PHONE_STATE

android.permission.ACCESS_NETWORK_STATE

android.permission.READ_CALL_LOG

android.permission.WRITE_CALL_LOG

Together with the screenshot of the application we can justify some of these, but by far not all. The internet permission is common for games as many of them feature some kind of online statistics tracking, sharing functionality or advertisements. Some also query the phone state to pause the game during a call or acquire a wake lock to prevent the device from entering sleep mode while the game is running. However permissions like reading contacts and bookmarks are a clear indication of an app that does more than just what it advertises. The connections to 127.0.0.1:53471 also seem quite strange for a game. If your are using APK to Java ;

3.2 Analysis with Dexter

The package dependency graph shows that there are four packages in total. We can ignore “de.rub.syssec” as it only contains empty classes with default constructors. This can be confirmed by looking at the method list of this package and the disassembly of the functions.

The package “de.rub.syssec.amazed” contains the game “Amazed” which can be found in the Play Store. The only interesting part here is the onCreate Method of AmazedActiviy, which sets a recurring alarm every 15 seconds.

The third class contains multiple event handlers. There exists an onBoot handler that sets the Alarm on boot, a SmsReceiver and an alarmReceiver which runs the actual malware. The SmsReceiver is called everytime a SMS is received by the device. It checks if the message starts with “bank”, if yes the message is dropped using abortBroadcast().

This means no notification is shown and the SMS is not visible in the log. The package “de.rub.syssec.neu” has six classes in total. The most important one is “Runner” which is the actual malicious code. Its method “work()” is called by the alarmReceiver and checks if the device is connected to the internet.

If yes the method “steal()” is called which collects the information and adds it to an XML with the help of the class XMLFoo.

The information collected, based on the API calls in the method list, are the following:

IMSI

SIM serial number

Carrier name

Device ID

User dictionary (used for auto-completion)

Contacts

Call log

Calender and appointments

Searches in the browser

Bookmarks in the browser

Send and received SMS

Location, acquired by querying GPS, network location and most accurate position available

3.3 Analysis using Android Emulator

The emulator confirms that it is indeed a game. The goal is to guide a marble through a maze using the sensors of the device. Apart from that the output of logcat reveals that the malware actually is quite verbose about what it does. It prints out what it is currently doing and the complete XML it tries to the send: