Introduction to Android Malware Static Analysis with Ghidra

The Android ecosystem, with its vast user base, remains a prime target for malicious actors. Android malware often leverages legitimate but powerful API calls to perform nefarious activities, such as data exfiltration, sending premium SMS messages, or deploying ransomware. Static analysis, particularly with robust tools like Ghidra, provides a critical first line of defense, allowing security researchers to dissect APKs without executing them, thereby identifying suspicious behaviors and malicious API usage.

This tutorial will guide you through the process of setting up Ghidra for Android reverse engineering and demonstrate practical techniques for identifying malicious API calls within an Android application’s bytecode. We will focus on key API categories frequently abused by malware and walk through a typical analysis workflow.

Setting Up Your Ghidra Environment for Android

Prerequisites

Before diving into Ghidra, ensure you have the following installed:

• Java Development Kit (JDK) 11 or newer: Ghidra requires a modern JDK.
• Ghidra: Download the latest stable version from the official GitHub repository (ghidra-sre.org).
• Android SDK (Optional but recommended): For reference and understanding Android APIs, though not strictly required for Ghidra itself.
• APKTool (Optional): Useful for unpacking APKs into Smali code and resources, which can sometimes aid in analysis or provide context if Ghidra struggles with direct DEX import.

Importing an Android APK into Ghidra

Ghidra doesn’t directly support APK files out-of-the-box in the same way it does native executables. An APK is essentially a ZIP archive containing various components, including the compiled Java bytecode in one or more classes.dex files. To analyze an APK:

1. Extract the DEX file: Rename your .apk file to .zip and extract its contents. Locate the classes.dex (and potentially classes2.dex, etc.) files.
2. Launch Ghidra: Open the Ghidra desktop application.
3. Create a New Project: Go to File > New Project..., select Non-Shared Project, and give it a descriptive name.
4. Import the DEX File: From the new project window, go to File > Import File.... Navigate to your extracted classes.dex file and select it. Ghidra will prompt you to configure import options. Confirm the language (likely Dalvik:LE:32:default) and proceed.
5. Analyze the DEX File: Once imported, right-click the classes.dex entry in the project explorer and select Analyze. Ensure Dalvik Analyzer and Decompiler Parameter ID are enabled for optimal results. Click Analyze. This step can take a while depending on the DEX file’s size.

Understanding Key API Categories Abused by Malware

Identifying malicious behavior often involves looking for specific patterns of API calls. Here are some critical categories to monitor:

1. SMS and Telephony Interactions

Malware often sends premium SMS messages or steals SMS content. Look for APIs related to:

• android.telephony.SmsManager: Methods like sendTextMessage, sendMultipartTextMessage.
• android.telephony.TelephonyManager: Accessing device identifiers (IMEI, IMSI), call state.

2. Network Communication and Data Exfiltration

Almost all malware communicates with C2 servers to exfiltrate data or receive commands.

• java.net.HttpURLConnection, java.net.Socket: Direct network communication.
• android.net.ConnectivityManager, android.net.wifi.WifiManager: Checking network state, manipulating Wi-Fi.

3. File System Access and Data Manipulation

Malware may read sensitive files, download additional payloads, or encrypt user data.

• java.io.File, java.io.FileOutputStream, java.io.FileInputStream: Basic file operations.
• android.os.Environment.getExternalStorageDirectory(): Accessing external storage.

4. Dynamic Code Loading

Advanced malware often downloads and executes additional code at runtime to evade static detection or update its capabilities.

• dalvik.system.DexClassLoader, dalvik.system.PathClassLoader, java.lang.reflect.Method.invoke(): Reflective or dynamic code loading.

5. Device Administration and Accessibility Services

These powerful APIs can grant malware extensive control over the device, making it difficult to uninstall or enabling sophisticated keylogging and screen content capture.

• android.app.admin.DevicePolicyManager: Methods like lockNow, wipeData, setPasswordQuality, setComponentEnabledSetting.
• android.accessibilityservice.AccessibilityService: For simulating user input, capturing screen content.

Practical Ghidra Workflow: Identifying Malicious API Calls

After the analysis is complete, you’ll be presented with Ghidra’s CodeBrowser. The key to static analysis is efficient searching and understanding the context of API calls.

Step 1: Navigate and Explore

In the Symbol Tree (left panel), expand the classes.dex entry. You’ll see packages, classes, and methods. Ghidra’s decompiler (right panel, ‘Decompile’ window) will attempt to translate the Dalvik bytecode into readable Java-like pseudocode.

Step 2: Searching for Specific API Calls

The most effective way to identify API calls is by searching for their fully qualified names or specific method names. Android API calls often follow the format Lpackage/subpackage/ClassName;->methodName in Smali, which translates to package.subpackage.ClassName.methodName in Java.

Method 1: Searching for String References

Many API calls are referenced as strings, especially when reflection is used, or their package/class names appear in string literals.

• Go to Search > Program Text > String.
• In the dialog, enter a partial or full API class/method name. For example, to find SMS sending, search for sendTextMessage or Landroid/telephony/SmsManager;.
• Click Search All.

Results will appear in the ‘Search Results’ window. Double-clicking an entry will take you to the location where the string is referenced.

Method 2: Searching for Symbols (Function Names)

If Ghidra has correctly identified an API call as an imported function, you can search the symbol table directly.

• Go to Search > For Symbols....
• Enter a function name, e.g., sendTextMessage.
• Select Functions as the symbol type.
• Click Search.

This is often faster if the function name is unique and directly resolved by Ghidra.

Step 3: Analyzing Cross-References (X-Refs)

Once you’ve found a suspicious API call, understanding where and how it’s called is crucial. Ghidra’s cross-reference feature is invaluable:

• In the Decompile window, highlight the suspicious API call (e.g., SmsManager.sendTextMessage(...)).
• Right-click and select References > Find References To > Call.
• The ‘References’ window will show all locations in the code that call this function.

Example Workflow: Detecting SMS Sending

1. Search: In the CodeBrowser, press Ctrl+Shift+F (or Search > Program Text > String) and search for sendTextMessage.
2. Examine Results: Suppose you find a reference like this in the decompiled code:

   public void someMaliciousMethod(String param1, String param2, String param3) { SmsManager smsManager = SmsManager.getDefault(); smsManager.sendTextMessage(param1, null, param2, null, null); Log.d("SMS_SENDER", "SMS sent to: " + param1); }

3. Trace X-Refs: Right-click on sendTextMessage and find its references. You might see it called from a method like com.malware.app.ServiceWorker.onStartCommand().
4. Analyze Calling Context: Trace back further. What triggers ServiceWorker.onStartCommand()? Does it receive sensitive data? This helps determine if the SMS sending is part of legitimate app functionality (e.g., a messaging app) or a malicious exfiltration attempt. Pay close attention to the parameters passed to sendTextMessage; are they hardcoded numbers, or are they variables derived from user data or device information?

Step 4: Distinguishing Malicious from Legitimate

The presence of an API call itself doesn’t automatically mean malware. Context is everything:

• Permissions: Does the AndroidManifest.xml declare necessary permissions (e.g., SEND_SMS, READ_SMS, INTERNET)? Malware often requests broad permissions.
• Obfuscation: Malicious apps often employ obfuscation (e.g., ProGuard, custom packers) to hide API calls. You might see reflective calls (Class.forName().getMethod().invoke()) or dynamically loaded DEX files.
• Behavioral Patterns: Is the API call part of a larger suspicious sequence? E.g., reading contacts, then iterating through them and sending SMS messages to each.

Conclusion

Ghidra is an indispensable tool for static analysis of Android applications. By systematically searching for, analyzing cross-references to, and understanding the context of key API calls, security researchers can effectively identify and dissect malicious functionalities within Android malware. While static analysis has its limitations, especially against advanced obfuscation, it provides a powerful foundation for understanding an application’s potential threats before engaging in more complex dynamic analysis or reverse engineering.