I’ve started some months ago with a post about Androguard and how to use it for reversing of Android apps. Androguard is still one of the most common tools for malware analysis and pentesting of Android apps, but there is a new tool on the horizon that I really want to show you. This tool combines a lot of the tasks that an analyst is facing during his day-to-day work routine in just one UI. The Tool is called Codeinspect and is developed at the Fraunhofer SIT.
In general, there are a few simple steps every Android reverser follows:
- Analyzing the Android-Manifest for permissions and activities
- Unpacking of the Android application (apk file) to get all files and especially the classes.dex
- Translating the Dalvik-Bytecode to Java-Bytecode (or similar)
- Analyzing the generated code
- Runtime-Analysis and manipulation of the application in question (OPTIONAL)
With the help of Codeinspect you can perform all those steps – including the optional runtime-analysis and manipulation – with one single interactive tool. Especially step 5 is very important if you deal with malware that is waiting for specific commands from a remote server or that is checking if the infected device is a sandbox as we have seen it in the case of some of the described Cryptolockers.
Using Codeinspect for our first App-Analysis
First of all you need to download the most current Codeinspect release candidate and apply for a demo license. Afterwards you can start the analysis by starting the Codeinspect UI and importing an apk-file of your choice (File -> Import -> Codeinspect Import -> Import APK). Within this example we are using Jimple (Java but simple) as the decompiler of our choice.
As soon as Codeinspect is done with decompiling and importing the application, you should see all components of the app in question on the left side of the Codeinspect window. This view is very similar to Eclipse with some very important differences:
- Permission Usage: In the lower part of the UI you can see a section called “permission usage”. This section shows all used permissions of the app and which lines of code are responsible for requesting the permission. This section can be really helpful if the app is requesting very sensitive permissions and you would like to get more information about why the app is requesting those permissions. In our example the app is requesting a larger amount of permissions, but as you can see, it is only using the SEND_SMS permission.
- Decompiled Source-Code: The main part of the Codeinspect UI is the decompiled source-code of the imported app. In our case it is decompiled to Jimple and we have opened the MagicSMSActivity which is the main method of the app.
- Project Explorer: This is what you know from Eclipse and other IDEs. Here you can find all components of the app as well as the decompiled Java and Jimple source-code.
Static Analysis
When looking at the decompiled source-code you can see that the app is displaying an error message to the user directly after the start telling that the device has a wrong Android version even without checking the version before (see lines 25 to 27). This is the first sign of a suspicious app, because normally, you are not able to install an app that is not compatible to your device’s version.
Afterwards the app is calling the TelephonyManager and trying to get the SimCountryISO which is the 2-letter-county-code of the inserted SIM card. This is a nice version of emulator- or sandbox-detection as those devices normally don’t have a SIM card. But as you can see later, the malware author is not aware of this.
Within the following lines the app is comparing those 2-letter-county-codes against ones, the author has registered premium services for. As soon as one of those comparisons is TRUE, the app jumps to line 36 and sends out 4 SMS messages.
Debugging the App
Until this point we have done a classical static analysis of a suspicious app. This was pretty easy because the analyzed app is not using any kind of obfuscation or code-encryption. When dealing with state-of-the-art malware, this wouldn’t be as easy as shown above. Therefore, Codeinspect is also able to run the app within the debugger.
In our case we already know that the most interesting things happen within line 30 (here the retrieved SimCountryISO is assigned to $String) and line 38 (the first SMS message is sent). To see what the app is retrieving from the device and how the sent SMS messages look like, we will set Breakpoints at line 31 and 39 (we always use the line after the interesting one, so that we can see the assigned values of all variables). Setting breakpoints can be done by right-clicking on the specific line.
Now we can run the Debugger by clicking the small bug icon in the upper part of the UI and choose a device or emulator to run the app on.
After the chosen emulator has finished booting the app is executed. As soon as the execution of the app reaches our first breakpoint we are able to see the assigned variables and there we can see that the app is retrieving “us” as 2-letter-county-code of the inserted SIM card (which is default since Android 4.0 when executing an app within the emulator).
As we have seen in the code, the malware author has not registered a premium service in this country. Thus, we would suggest that the app is not sending a SMS message and just displaying the error message (this would also be the case if the app is trying to evade the emulator by detecting it). But as we can see as soon as the app is reaching the second breakpoint it is trying to send a SMS message to the number “00000” with the text “WUUT”.
Runtime Manipulation
As soon as we are facing an app that has been developed by a malware author that is aware of how to evade detection by an emulator or common sandbox, we would not have seen an SMS message or any other suspicious action after the app has reached the first breakpoint. Here another feature of the debugger comes into play. If using Codeinspect we have a very fancy way of manipulating variables during runtime. We just need to right-click on an assigned value to change it to something we want to have assigned to that variable. In our case, we want to see what the app is doing if we are using a German SIM card. Thus, we are changing the value “us” to “de” during runtime.
Codeinspect is automatically converting the entered value to the format or encoding the variable is using. Afterwards, the app uses our manipulated value and as soon as the app reaches the second breakpoint we now see that the app is sending out an SMS message to another number with different text.
Manipulating the runtime behavior of an app like shown above can be useful if you would like to see if the app is targeted to a specific group of people, country or even to a very specific individual or device.
Résumé
When dealing with app- or malware analysis of Android apps, Codeinspect is one of my favorite tools as it combines a lot of tools within one UI I would normally use separately and Codeinspect is capable of many more features that can be very helpful during such an analysis that we have not demonstrated within this post (e.g., patching the app with own Jimple code that will be executed during runtime or displaying control-flow-graphs of an app using FlowDroid). Thus, it is really a great tool for pentesters and malware analysts.