I plan on writing regular posts in the DIY series with the goal of not only understanding malware, vulnerabilities and exploits but also to share with our readers some techniques and tools they can use themselves to “know the enemy”. I am also looking forward to hearing about your experiences in analyzing similar threats with similar or more efficient tools & techniques.
Alright, so let’s get right into it, OBAD has been agreed upon to be one of the most sophisticated piece of android malware and you can find various analysis on the web. In this series we will take it apart together and learn about its functionality and various techniques that it uses to gain more power, avoid removal and making analysis harder. In part 1 we will see how to use dynamic code analysis, debugging using jdb, smali (dalvik disassembly source) level debugging, using jdb commands to learn about reflection code being invoked and see through string decryption, using IDA to understand and visualize control and data flow, modifying AOSP code and building a custom system image to bypass anti emulator tricks used by OBAD.
Where to get it from
We will using the sample with md5: e1064bfd836e4c895b569b2de4700284 (VirusTotal analysis) . You can download it from Contagio Mobile
Viewing the contents of the APK files
The apk files can be simply uncompressed just like zip files to obtain their contents, which include the manifest file this is usually in the binary format and can be converted into a readable file by downloading AXMLPrinter2.jar and running
Upon unzipping the apk file you will also get a classes.dex file which is a dex file that contains the application code.
First encounter – let it go wild in a safe environment
To speed things up I would recommend using Mobisec distribution, although it needs a lot of upgrades, but seems to be a good choice to get things started quickly. It comes with a lot of tools pre installed. Once you have it on running on a virtual machine (virtualbox is a pretty neat and robust free virtualization solution). Another advantage of doing this in a virtual machine is that you can take snapshots at desired intervals, revert machine to it during your analysis and try out other routes of analysis.
I have created a short text file showing the steps I took on mobisec VM to upgrade android sdk, download python 2.7 and install drozer – a very powerful framework to test and analyze android apps. You can get it from Upgrading_SDK_in_mobisec_and_installing_drozer
One of the very first things you can do is submit to some of the online analysis services and get an overview of what the sample does (esp. if you are not concerned that this could be a targeted attack and by submitting to online services you may caution the attackers). Here are a few:
- Pretty powerful dynamic analysis tool is the sandbox and analysis technology by JoeSecurity and they offer a free analysis service at APK Analyzer
- A good online tool for static analysis and visuals is Dexter
So you can go ahead and try the OBAD sample with these tools now, or do that later and lets see what we can discover for ourselves.
If you are not already familiar with Android SDK, I would recommend you take some time to review these:
I started with an AVD that comes with the sdk for Android 4.0.3 running api android-15 revision 3 and launched the emulator as:
Once the emulator is up you can install the sample as:
After that if you go and check out the apps installed you do not see any new launcher icon. Let’s take a look at some log entries we can use logcat and see the following relevant messages by running “adb logcat” (for more details you can run it as “adb logcat -d -v long”:
How did we know what is the package name that this apk installs? You can figure this out by static analysis tools, or just looking at recent entries from logcat or by looking at the difference in list of packages installed before and after installing the apk under analysis ( “adb shell pm list packages” will come in handy, or the drozer’s app.package.list)
So let us try to get some info about the package we just installed, a lot of information can be extracted by the commands that can be launched via the adb tool in sdk, I also like to use the drozer tool to get info about any package.
Once you are in the drozer console you can try these to get some info about the package as:
Debugging the application
I will now describe how I went about debugging this application. You can read about the debugging infrastructure and available options here. I used jdb command line debugging and here is how I did my setup. Note, we already have the emulator running and the apk installed. So I started the monitor tool, which has the DDMS tool.
In the emulator, go to applications view, click on devtools and then choose “Development Settings”, click on the app name (usually none by default) under “Debug app” and then from the application list scroll down and select com.android.system.admin. Also select “wait for debugger”.
Now you can launch the app using drozer or the sdk tools as
The application then will wait for a debugger to attach. This will also result in application’s debug port being forwarded to the default port 8700.
I used the command line debugging tool jdb. Note that once a debugger attaches to the app, waitForDebugger method checks to see when the last activity occurred in debugger, and if nothing has happened in a certain time period then it resumes the app so it is important to set any breakpoints etc in .jdbrc file in the home directory that jdb reads upon startup.
jdb can be attached to the application waiting for debugger by:
Just before attaching the debugger it will be a good point to create a VM snapshot, so we can return to it when trying different debugging breakpoints during subsequent runs of the app.
I tried debugging this app by setting a breakpoint on onCreate for the launcher activity CCOIoll but it never got hit in the debugger. So I tried the following:
Getting list of all method that the app enters and exits:
This can be done by having the following line in the .jdbrc file in the user’s home directory.
trace go methods
But this did not work, as it caused too much debugger activity and the app was not able to come out of android.os.Debug.waitForDebugger() which depends on the time period elapsed since lastDebuggerActivity() and only exits it it exceeds a set duration. So then I realized let’s try to break on application entry point i.e. for our case I added the following in the .jdbrc file
When this breakpoint hits then you can run
This gives us an idea of what parts of the code were executed, by comparing the entry and exit lists we also see that we enter com.android.system.admin.COcCccl.onCreate() but do not exit it, so somewhere in there we exit the application. We do not see any method entry that shows us that some anti VM checks are happening nor do we see any java methods that cause application shutdown. One of the reason for these is
So we do not see methods being entered / exited from these packages, when we run trace go methods.
Let us then try to explicitly set a breakpoint at java.lang.System.exit, we already have a VM snapshot we can revert to, edit our .jdbrc file (put in “stop in java.lang.System.exit(int)”), run the app again, attach jdb to it and we see:
So it is now time to dive into source code.
Source code for the Android application and smali code debugging
Remember earlier we talked about getting a dex file from the apk file. Android code is typically written in Java, the Java class files are then converted into .dex (i.e. Dalvik Executable) file which run on the Dalvikvirtual machine that is used in Android.
What can you do with these .dex files?
I like the following options (and there may be others):
No comments:
Post a Comment