As you most likely know, there are two methods of application analysis: static and dynamic. The former includes disassembly, decompilation, and app-manifest analysis. The latter assumes the application is launched in a special environment that permits its behavior to be analyzed under “real conditions,” so to speak. In practice, both methods are usually used in parallel. But as we have already reviewed static analysis (“Anatomy with Preparation”, No. 170), in this article, we are going to concentrate on dynamic analysis.

By default, Android has almost no built-in tools for the dynamic analysis of external applications. On the one hand, in desktop OSs, these tools are frequently used for purposes that are exactly the opposite of their intended use (the simplest example is the Windows function CreateRemoteThread() that was successfully utilized by all kinds of malware programs about ten years ago or the API hooks in Windows that we’re now fed up with). On the other hand, it is virtually impossible to analyze malicious applications without such tools.

But here, Android has one huge advantage: its code is open. And this means that all functionality required for effective application analysis can be added to it. This is exactly what the researchers on the TaintDroid project did; their groundwork was later used in developing a DroidBox emulator to study applications directly from a computer.

DroidBox

DroidBox consists of two parts, which can be referred to as the Host and Target. The Target part launched on the emulator is based on Android 4.1.2, with a set of patches, most of which were borrowed from TaintDroid without change. The patches add certain functions for monitoring data at a low level.

The Host part is a set of Python scripts that connects with the emulator and receives all possible information from the Target regarding the application being analyzed, and displays it in text or graphic format.

DroidBox is distributed in both source code and in the form of ready-made binary files (of course, both the AndroidSDK and an appropriately set $PATH variable are required, with additional paths to the tools and platform-tools folders). As it has not been updated for a while, it makes sense not to torture yourself by building from repository, and instead download the ready-made one. First, you will need to install some packages:

$ sudo apt-get install python-numpy python-scipy python-matplotlib subversion

And download DroidBox itself:

$ wget http://droidbox.googlecode.com/files/DroidBox411RC.tar.gz && tar xzvf DroidBox411RC.tar.gz

For some reason unknown to me, the main script DroidBox in the archive does not generate graphics, and the old script that is located in the SVN-repository in the external folder does not work, so I had to change the code of the current script, making some slight corrections and pulling in parts from the old script as necessary. My modified script is available on DVD.

Then create an AVD (Nexus 4 with Android 4.1.2) and launch it using the script located in the newly unpacked folder:

$ ./startemu.sh DroidBox

This script takes the name of the newly created AVD as a parameter, with this ultimately launching the system image that comes with DroidBox rather than the original system image. Then add the application that we want to analyze to the emulator. I chose a few samples of malware as subjects, such as Simplocker, Fakemart, one of the bank Trojan horses, and the infamous Android.OBad.a.

Simplocker

This is a relatively recent virus written as per the winlocker canons. After the launch it will accuse you of necropedozoophilia; encrypt all images, videos, and documents on the memory card; and demand payment for their recovery.

Launch the sample:

$ droidbox.sh /home/rom/android_malware_samples/simplocker/simplocker.apk

The emulator window will show the main screen of the application that will reopen after every attempt to close it. Wait for some time, try to do something, click with the mouse on various parts of the screen, and finally kill the emulator by pressing <Ctrl + C> in the terminal window.

As a result, we obtain three files: A diagram showing the overall distribution of operations, a chart showing the distribution of operations as a function of time, and the trace itself. The names of the first two files consist of a prefix (tree- for the diagram, behaviorgraph- for the time chart, and trace- for the trace), the name of the package, date, and time. In my case, the file trace name for Simplocker looked like trace-org.simplelocker–20141008–1635.png.

Now let’s see. On the time chart (see screenshot) for the first several moments, we see the download of a DEX-file, then a launch of a service and an operation involving cryptAPIAndroid (apparently, a single one), and this is then followed by an almost continuous stream of file operations, in comparison with which the comb of net operations (netread, netopen) seems sparse. The user’s actions do not affect this diagram.

Inline-Box: DroidBox tracing file structure

The DroidBox tracing file is a record of actions in JSON format that has the following sections:

• accessedFiles — a list of files the application received access to;
• apkName — the name of the APK-file being analyzed;
• closenet — socket close operations;
• cryptousage — operations involving cryptAPIAndroid;
• dataleaks — leak of the user’s personal data;
• dexclass — operations with DEX classes;
• enfperm — authorizations added (not used!) by the application;
• fdaccess — operations involving files;
• hashes — MD5-, SHA–1- and SHA–256-hashes of the analyzed APK;
• opennet — socket open operations;
• phonecalls — phone calls;
• recvnet — receive via network;
• recvaction — a list of intents to which the application responds;
• sendnet — transfer operations via network;
• sendsms — message sending;
• servicestart — service launch operations.

Almost all sections have the following format:

"Section name" {
    "Operation time (from start of launch)" {
        "Name of parameter being traced (e.g., for sendnet, this could be desthost, destport, etc.)": "Parameter value"
    }
}

Let’s move on to the trace file. Its structure is shown in the box, where we are going to review the actions recorded in this file. Over the entire duration of the trace, the application accessed the same files a minimum of several hundred times. Immediately after accessing each file, the same file was accessed again, but this time, with an enc extension (apparently, the virus reads the files, encrypts them and records the result to the new files).

“accessedFiles”: {
 “100012523”: “/mnt/sdcard/Download/original.jpg”,
 “1000285190”: “/mnt/sdcard/Download/images–26825–27541-hd-wallpapers.jpg”,
 “1000303735”: “/mnt/sdcard/Download/original.jpg”,
 “1000425910”: “/mnt/sdcard/Download/images–26825–27541-hd-wallpapers.jpg.enc”,
 <…>
 },

At 0.9 seconds, something in cryptoAPI was used, most likely related to the key generation as indicated by the CryptoUsage section. It also specifies the algorithm (AES) and the key itself (ta-dah!).

“cryptousage”: {
 “0.9651350975036621”: {
 “algorithm”: “AES”,
 “key”: “95, –81, 109, <…>”,
 “operation”: “keyalgo”,
 “type”: “crypto”
 }
 <…>
 },

The dataleaks section is empty, which means that most likely there were no leaks of sensitive data (IMEI):

"dataleaks": {},

In the fdaccess section, we see that the application continuously opens, reads, and writes files while performing the encryption… But we also see a write to the file /data/data/org.simplelocker/app_bin/torrctether.

“fdaccess”: {
 “1.334583044052124”: {
 “data”: “<…>”,
 “id”: “1456730989”,
 “operation”: “write”,
 “path”: “/data/data/org.simplelocker/app_bin/torrctether”,
 “type”: “filewrite”
 },
 <…>
 }

Convert the line with hexadecimal data (the listing shows “<…>” in place of this data) to ASCII, and we see a piece of Tor configuration. A little lower, at 1.41 seconds, we see a write to the file /data/data/org.simplelocker/app_bin/privoxy.config. We again convert the line… this is the beginning of Privoxy configuration. There will be nothing of interest to us beyond this point, so we move on to the network operations (since the phonecalls section is empty).

The application is waiting for data from Port 9051 that is the Tor controlling port. (The developer was clearly concerned about his own confidentiality.) The data is text, by the way, so the whole line can once again be converted into ASCII. It also sends the data to the same port and sets the parameters of the Tor connection.

“recvnet”: {
 “16.08561396598816”: {
 “data”: “<…>”,
 “host”: “127.0.0.1”,
 “port”: “9051”,
 “type”: “net read”
 },
 <…>
 },
 “sendnet”: {
 “8.150573968887329”: {
 “data”: “<…>”,
 “desthost”: “127.0.0.1”,
 “destport”: “9051”,
 “fd”: “148”,
 “operation”: “send”,
 “type”: “net write”
 },
 <…>
 },

The malware only responds to two intents (“ACTION_EXTERNAL_APPLICATIONS_AVAILABLE” and “BOOT_COMPLETED”) and launches the service — but this is quite easy to find out without using DroidBox via ordinary static analysis.

"recvsaction": {
    ".SDCardServiceStarter": "android.intent.action.ACTION_EXTERNAL_APPLICATIONS_AVAILABLE", 
    ".ServiceStarter": "android.intent.action.BOOT_COMPLETED"
}, 

Conclusions: After several minutes of analysis, we found out exactly what was being encrypted by our locker, learned that commands can be received through the Tor network, and obtained the key to recover the files. If we were to catch this malware on our device, we could easily recover our data by simply transferring them to the computer and decrypting with OpenSSL and the key obtained here.

Fakemart

The next virus will be Fakemart: an application that disguises as an app store and sends out paid SMS text messages. Start it and pretend to be an ordinary user that waits for something to download — possibly “a repository.” Naturally, the “download” does not complete, probably for purposes of initiating another launch. After several attempts (and we are just ordinary users, aren’t we?) we stop the trace and look at the results.

The time chart shows that an SMS message was sent at the very start, followed by a file write and several network operations, and then again multiple writes to a file.

The distribution diagram confirms that most of the operations are file writes, followed by network operations, and then a quite fat (compared to the class download operation DEXLOAD) column of sent SMS text messages.

Okay, let’s take a look at the trace. This time, the list of files accessed by the application is quite small, so going through it won’t take a lot of time. We verify that there were no cryptoAPI calls, no data leaks were recorded, and with a safe conscience, move on to the file writes.

For some reason, a number has been written to the file /data/data/com.android.blackmarket/shared_prefs/XMBPSP.xml; later, we will learn that an SMS text message is sent to this number. This application does not write to any other files.

"fdaccess": {
 "2.016759157180786": {
 "data": "<...>", 
 "id": "312838054", 
 "operation": "write", 
 "path": "/data/data/com.android.blackmarket/shared_prefs/XMBPSP.xml", 
 "type": "filewrite"
 },
 <...>
}

The network operations are an attempt to open a connection with a certain address via Port 80, followed by an attempt to receive and send data. However, the server responds Forbidden, which is not surprising.

"opennet": {
 "2.080552101135254": {
 "desthost": "83.XXX.XXX.XXX", 
 "destport": "80", 
 "fd": "21", 
 "type": "net open"
 }, 
}, 
"recvnet": {
 "2.3735501766204834": {
 <...>
 }
 <...>
 "sendnet": {
 "2.1825380325317383": {
 <...>
 }

A text message was sent three times, and each time, an attempt was made to launch the application.

"sendsms": {
 "2.0525059700012207": {
 "message": "AP", 
 "number": "XXXXX", 
 "type": "sms"
 }, 
 <...>
}

Conclusion: the “sendsms” section clearly shows what we have encountered. No shopping cart would send an SMS text message to short numbers, especially several times. DroidBox revealed an SMS-Trojan. It is interesting, by the way, that the developers clearly created protection against the blocking of paid numbers: the operations involving data exchange with the server and file writes are obviously an attempt to update the paid number.

iBanking

And this is a banking Trojan horse. One version of this we are going to review disguises itself as an antivirus. Following installation, it requests administrator rights on the device.

The time chart revealed that an SMS message was sent within the first seconds, and this was followed by a dense series of network operations. The distribution diagram showed that the network operations were extremely rapid; compared to them, the sending of an SMS message is practically invisible on the diagram.

The trace reveals an ICCID leak. It also indicated the method by which the leak occurred — an SMS text message. Continuous attempts to send a POST request were made via the network.

"dataleaks": {
 "1.6918201446533203": {
 "message": "iam (89014103211118510720 + UnknownFullAndroidonEmulator)", 
 "number": "+XXXXXXXXXXXXXX", 
 "sink": "SMS", 
 "tag": [
 "TAINT_ICCID"
 ], 
 "type": "sms"
 }
}

And that is it. Despite the fact that iBanking is one of the most functional Trojans for Android, DroidBox could tell us almost nothing about it. The reason is simple: The virus waits for commands from the server and simply sleeps until it receives them. Investigation of such software will require static analysis, with kilometer-long smali listings, deobfuscation, and other pleasures.

[efspanel style=”” type=””]
[efspanel-header]

Alternatives: DroidScope and Android Hooker

[/efspanel-header]
[efspanel-content]

DroidScope is based on DECAF (Dynamic Executable Code Analysis Framework). Unlike DroidBox, which implements its code in Android, DECAF (and, therefore, DroidScope) observes the flow of emulator execution as a whole. On the one hand, this helps to gain visibility into some low-level operations; on the other hand, without plug-ins to separate out useful information, it is very difficult to use.

The following can be done with plug-ins in DroidScope:

• API tracing — including the exchange between the native code and Java code that occurs with the help of JNI;
• tracing of both native instructions and DalvikVM instructions;
• monitoring of sensitive data to determine when they have been leaked.

Unfortunately, only the Dalvik instruction tracing plug-in is available for public access, and the official environment available on the site includes a highly outdated version of Android Gingerbread. So in order to be used in practice, DroidScope needs to be improved.

Android Hooker uses the Substrate framework to monitor applications behavior and call the API. As per the author, it is intended for behavior analysis of entire shopping carts (for which all actions can be recorded into an elasticsearch DB), and not just specific applications. However, just as in the case with DroidBox, there is no capability for monitoring native calls, which automatically makes one doubt that the application is intended to perform its stated purpose. Additionally, Substrate works on a higher level than DroidBox, — therefore, the risk of detection by Android Hooker is increased.
[/efspanel-content]
[/efspanel]

Conclusion

In general, DroidBox is quite convenient, but looks unfinished. It works only with a specific Android version (even more restrictively — only in an emulator) and supports JavaAPI exclusively, so it makes no sense to try to feed it mixed code. As soon as an application calls any libraries, or even makes any system calls through JNI, it immediately disappears from view.

Additionally, DroidBox is not capable of catching all possible actions and cannot deal with all viruses. For instance, the application refused to analyze the infamous Android.OBad.a, displaying the “Failed to analyze the APK. Terminate the analysis” error. DroidBox does not change the emulator itself, so the application is quite able to determine that it is under surveillance. There are plenty of methods for that — from the commonplace ICCID and a phone number to craftily deployed ARM assembler instructions.

[efspanel style=”” type=””]
[efspanel-header]

Web services for Android apps analysis

[/efspanel-header]
[efspanel-content]

• Andrubis is an addition to a web service anubis.iseclab.org that is widely known in private groups; it emulates Android 2.3.4, and apparently (judging by the report format) is an improved version of DroidBox. For some reason, it could not launch APKSimplocker; however, it was able to handle Android.OBad.a with no problem.
• CopperDroid (copperdroid.isg.rhul.ac.uk) is another tool based on DroidBox. This is obvious from the report format, which matches the report format generated by the aforementioned tool. However, unlike DroidBox, CopperDroid can trace system calls. For unknown reasons, it did not want to analyze some of my samples.
• ApkScan (apkscan.nviso.be) is a Belgian project; it emulates Android 4.1. It is also based on DroidBox, and among other things, it provides a log file generated by logcat. It has no special distinguishing features. It was not able to deal with two of my samples. Apparently, they request administrator rights to the device after the fact.

[/efspanel-content]
[/efspanel]