Android Malware Analysis Overview

The smartphone world is huge and this carries a lot of benefits but also vulnerabilities and risks. To achieve effective testing, we can perform static, dynamic, and forensic analysis. This is mostly done with the help of virtualization technologies.

The whole testing preparation requires a lot. First, you need to understand the application functionality, the workflow, and the supporting structure just for interaction purposes. This is very important, mostly when the evaluated app can affect the business back-end system.

A standard setup for analysis requires the app itself, a proxy for traffic monitoring, testing, and demonstrating flaws.

The static analysis

This is the first phase, and it’s done from the app source code. Basically, at this point, you need to perform reverse engineering of the app, regardless of the source.

This reverse engineering should be done in the most exact duplicate environment that will be your working test information.

The first thing to do when reversing is to check all network interfaces working on the directory, cellular, wifi, Bluetooth, NFC, and whatever other network protocol is available. This is the most common way to leak information to a C2 server.

Of course, this all depends on the nature of the app. But actually, you shouldn’t disregard any form of component interaction, data access, application interactions, server-side environments, development environments, permissions, hard-coded secrets, and more.

This is all from the binary perspective. However, other key aspects can be present inside the environment, which complements the whole functionality. The xap or apk file is not enough, you should consider reviewing security models and third-party access, how the session management is made, the handling of sensitive data, encryption, and even pinning.

The dynamic analysis

In a few words, this represents the effect of running the application, the whole behavior between starting and closing the application, and what kind of changes are produced in the device storage and the data.

In my understanding, this all prevails in the information transmitted, evaluating unexpected connections and sensitive application data being visible during execution. This must include credential entry, and how the malware can bypass controls or how the Object itself access controls, malicious code inserted, session management, session fixation, scalations, and more.

Malware analysis requires good knowledge of the application, sophisticated low-level testing, application hooking, and disassembling techniques.

Moving on to Android now.

The Android stuff

Android apps are deployed as an APK package. Internally, it uses a .dex file as the main executable, this is sort of transformed into a classes.dex file (Dalvik execution format), and it contains the executable and source code.

Also, we have the AndroidManifest.xml, a very useful file that contains information about the application characteristics, libraries used, permissions, and more. Android apps can be found with GUI or as a Service (background). It also contains Helpers routines such as broadcast receivers and content providers for events and storage purposes respectively.

The security mode

This has a different perspective than the Linux environment and can be summarized in four premises

1. The trust boundary is the application instead of the user.
2. The Application should run in its sandbox
3. Interactions are explicit (Hardware — Software: User relations)
4. Applications are signed, this provides a trusted providence (Signed and distributed from official secure marketplaces)

How to sandbox applications?

The application has a unique identifier once it is installed. The sandbox by definition cannot interfere with other applications.

Of course, there can be files stored there, but the content provided, the IO permissions on the sandbox, and more are given but not exported.

Android permissions

In simple words, this is all explicitly requested by permissions that involve hardware interaction. They are isolated. A sign of a good application is the number of permissions asked, for that reason, developers should consider minimizing the permissions requested.

Standard permissions are defined but applications can define their own.

Android environment testing and some tools

I’ll be pretty direct with this section. Let’s start with the Android elementals.

The Android prerequisites for development and environment purposes are Java 8 and Android Studio, especially the CLI tools that come with the SDK.

A crucial file for analysis is the AndroidManifest.xml file, this describes the functionality and requirements for an Android Application, so, many labors are focused on extracting this file and checking the content of the file.

From a general perspective.

1. You will need an APK downloader for downloading the target APK, I tend to use this or the APKPure
2. The apktool is used for disassembling the application into its directory, which basically will perform a source code file listing. At this point, we can evaluate the Manifest directly. Check the official site here

Run: apktool [your_file.apk]

1. For extracting and reading source code I use dex2jar. There’s an alternative called JD-GUI, which is a standalone graphical tool that displays the Java source code in-class elements. This last tool is used the browse the source code when to reconstruct using dex2jar

Running dex2jar for decompiling the application: d2j-dex2jar [your_file.apk]. This will output a .jar file

Then, you can use jd-gui to open the .jar file generated from the previous step and list the class files in a good fashion GUI way.

1. An alternative for recreating the source code is jad, which is used for recovering source code from CLI (.class files). In a few words, we a getting the .java file from .class files.

Here’s how it’s done: jad -d [source_folder] -s [new_folder] (the new_folder will have a bunch of .java files.

1. You can also browse applications with jadx, basically with this you are converting .dex files to Java files. Use jadx-gui to find an APK file and transform it to see all the source files such as Resources, Java files, assets, and more. This is a complete tool, way more direct, rather than using dex2jar and jd-gui simultaneously.

Basic setup and analysis

A great utility tool from the Android SDK, it's adb, which stands for Android Debug Bridge, this allows us to perform USB debugging connections simply. It comes with the Android SDK, which you can find adb in Linux or adb.exe Windows installations.

Execution commands:

> ./adb kill-server (kill the server)
> ./adb start-server (start the server)
> ./adb devices (find the devices connected)
> ./adb push [file] (inserting files into a device)
> ./adb pull [file] (extracting files)
> ./adb shell (creates an interactive shell)

With an open shell, you can list the device directories, extract files, and more.

> ./adb shell
> ./adb pull /path/to/your/app.apk

Inside the interactive shell, you will see some directories. Is it worth mentioning two or them

1. The /data is for the user-loaded applications (testing directories such as /app, /priv-app, etc. This is not available for regular uses, a root privilege is required or replicates the app installation inside a VM or any emulator.
2. The /system directory is for the system applications.

With the extracted file you can then open it with jadx and check the files.

Another key component is an Emulator. You can use a variety of programs like BlueStacks, Genymotion, etc, but Android has an official tool for it, it’s called AVD or Android Virtual Machine. You can create an emulator fast from the Android Studio GUI or in a CLI way. Please check the /tools/emulator program for details.

Dynamic analysis

With the adb started and with a running emulator. You can perform some sort of analysis easily.

> cd platform-tools
> ./adb install your_app.apk
> ./adb shell
> pm list packages
> pm path com.[your_company].[your_app]
> ls /data/data/com.[your_company].[your_app]

The pm command is used for listing information about the apps installed.

The pm list packages command will show you the number of packages installed on your device, while the pm path command will show you the installation directory of it.

Then you can execute adb logcat > your_log.txt to place the activities into a log file when the app is executed.

After the logcat is set up, run your application, interact with it, and wait for some data collection.

Let’s check the data.

> ./adb shell
> cd /data/data/[your_app_directory]
> ls -all cache 
> ls databases

There’s a lot to explain here, the ls -all cache command list what's on the cache directory, the ls databases does the same for databases, here, you can find -wal files which are temporary write-ahead logging files, this is a standard method for ensuring data integrity, and also the -shm that is the index of that index.

Let’s extract the database files: adb pull /data/data/[your_app_directory]/databases/*

With the extracted files, you can investigate databases (mostly on SQLite) with the .db format, and check the logs for any interesting unexpected behavior.

Drozer framework

This whole process explained above, is kinda verbose and very manual. Fortunately, we can use Drozer, this is a full testing framework that acts like a normal app but uses a custom bridge for testing purposes. It includes a device agent that should be placed inside the device.

> ./adb install agent.apk (from Dozer)
> ./adb tcp:31415 tcp:31415

This requires forwarding TCP connections to enable connections back and forth with the device. Next, you should be able to find devices with Drozer on the host machine, of course, Drozer needs to be running into so.

Once you are connected you can run the dz command

dz> list 
dz> run app.package.list 
dz> run app.package.list info -a [your_app_package_id]
dz> run app.package.attacksurface [your_app_package_id]
dz> run app.package.attacksurface [your_app_package_id]
dz> run app.activity.info -a [your_app_package_id]
dz> run app.activity.start --component [your_app_package_id] com.[your_app].DeepLinkActivity

The last command can help you start activities from CLI, the idea behind Drozer is to understand what can be executed and detect logic and programmatic flaws in the device.