Introduction: The Threat of Android Ransomware

The proliferation of Android devices has unfortunately made them a prime target for malicious actors, with ransomware emerging as a particularly insidious threat. Android ransomware typically encrypts user files, locks the device screen, or both, demanding a ransom payment for restoration. Understanding how these threats operate is paramount for developing robust defenses and conducting effective incident response. Static analysis, the examination of software without executing it, provides invaluable insights into malware functionality, and Ghidra, the open-source reverse engineering framework from NSA, is an exceptional tool for this purpose.

This article provides a detailed, expert-level guide on using Ghidra for static analysis of Android ransomware, focusing on identifying key malicious behaviors such as file encryption, device locking, and command-and-control (C2) communication. We will walk through the process, from preparing the sample to extracting crucial indicators of compromise (IoCs).

Setting Up Your Reverse Engineering Environment

Before diving into the analysis, ensure your environment is properly set up. You’ll need:

• Ghidra: Download and install the latest version from the official GitHub repository. Ghidra requires a Java Development Kit (JDK) 11 or newer.
• Android SDK (Optional but Recommended): For tools like `apkanalyzer` to inspect APKs or to set up an emulator for potential dynamic analysis later.
• Malware Sample: Obtain an Android ransomware sample from a trusted malware repository (e.g., MalwareBazaar, VirusTotal’s malware samples). For ethical reasons, never analyze live malware on a production machine or without proper isolation. For this guide, we’ll assume we have a sample named `droid_locker.apk`.

# Verify Java installation
java -version

# Unzip Ghidra (example for Linux/macOS)
unzip ghidra_<version>_PUBLIC_<date>.zip
cd ghidra_<version>_PUBLIC
./ghidraRun

Acquiring and Preparing the Malware Sample

Once you have your `droid_locker.apk` sample, there’s minimal preparation needed for Ghidra. Ghidra’s Android module can directly process APK files, extracting the DEX bytecode within. However, it’s always good practice to perform an initial triage to confirm it’s indeed an Android application and to extract basic information.

# Using apkanalyzer from Android SDK to list components
<path_to_android_sdk>/cmdline-tools/latest/bin/apkanalyzer manifest print droid_locker.apk

# This will show package name, activities, services, receivers, and permissions.

Importing the APK into Ghidra

Follow these steps to import your ransomware sample into Ghidra:

1. Launch Ghidra and create a new project (File > New Project). Choose a Non-Shared Project.
2. Give your project a descriptive name, e.g., “AndroidRansomwareAnalysis”.
3. Once the project is created, go to File > Import File… and select your `droid_locker.apk`.
4. Ghidra will detect it as an Android APK. Confirm the import options. It will then extract the DEX files and prompt you to analyze them. Click “Yes” to perform the initial analysis.
5. In the “Analyze Options” dialog, ensure “Dalvik/ART Decompiler” is selected. You can also select “Android Analysis” to get permissions and manifest details. Click “Analyze”.

Ghidra will now process the DEX bytecode, creating functions, symbols, and performing initial decompilation.

Navigating Ghidra’s Interface for Android Analysis

The Ghidra CodeBrowser is your primary interface. Key windows to focus on are:

• Program Trees: On the left, it shows the various DEX files. You’ll typically find `classes.dex`, `classes2.dex`, etc.
• Symbol Tree: Lists functions, classes, and global variables. Use this to navigate to specific methods or classes.
• Listing Window: Shows the disassembled Dalvik bytecode.
• Decompiler Window: The most powerful tool, displaying a C-like pseudo-code representation of the selected function, making complex logic much easier to understand.
• Defined Strings: Found under the “Data Type Manager” or by searching, useful for finding hardcoded URLs, file paths, or messages.

Start by examining the `AndroidManifest.xml` (visible under “Program Trees” > “<your_apk_name>.apk” > “resources” > “AndroidManifest.xml”). This file reveals crucial permissions requested by the app, entry points (activities, services, receivers), and other metadata. Look for suspicious permissions like WRITE_EXTERNAL_STORAGE, READ_EXTERNAL_STORAGE, BIND_DEVICE_ADMIN, SYSTEM_ALERT_WINDOW, INTERNET, RECEIVE_BOOT_COMPLETED.

Identifying Ransomware Modus Operandi

1. Permissions Analysis

The `AndroidManifest.xml` provides immediate clues. Ransomware often requests extensive permissions:

• `android.permission.INTERNET`: For C2 communication.
• `android.permission.WRITE_EXTERNAL_STORAGE`: To encrypt files on the SD card.
• `android.permission.RECEIVE_BOOT_COMPLETED`: To ensure persistence.
• `android.permission.BIND_DEVICE_ADMIN`: To prevent uninstallation and lock the device.
• `android.permission.SYSTEM_ALERT_WINDOW`: To overlay the screen with a ransom note.

Navigate to `AndroidManifest.xml` in Ghidra to review these.

2. File System Enumeration and Encryption

To encrypt files, ransomware must first find them. Look for classes and methods related to file operations and encryption:

• Keywords in Symbol Tree / Search: `java.io.File`, `listFiles`, `isDirectory`, `Cipher`, `AES`, `SecretKeySpec`, `IvParameterSpec`, `FileOutputStream`, `FileInputStream`.
• Common Patterns: Recursive functions that traverse directories, checking file extensions, then encrypting.

In the Decompiler, you might find something similar to this:

// Example of an encryption routine in pseudo-C
void encryptFile(File param1File, byte[] param2ArrayOfbyte) {
    // param2ArrayOfbyte is likely the AES key
    Cipher localCipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
    SecretKeySpec localSecretKeySpec = new SecretKeySpec(param2ArrayOfbyte, "AES");
    // Assume IV is hardcoded or derived somewhere else
    IvParameterSpec localIvParameterSpec = new IvParameterSpec(someDerivedIV);
    localCipher.init(1, localSecretKeySpec, localIvParameterSpec); // 1 for ENCRYPT_MODE
    
    FileInputStream localFileInputStream = new FileInputStream(param1File);
    FileOutputStream localFileOutputStream = new FileOutputStream(new File(param1File.getPath() + ".locked"));
    
    // Read, encrypt, write loop
    byte[] arrayOfByte1 = new byte[1024];
    while (true) {
        int i = localFileInputStream.read(arrayOfByte1);
        if (i == -1) break;
        byte[] arrayOfByte2 = localCipher.update(arrayOfByte1, 0, i);
        localFileOutputStream.write(arrayOfByte2);
    }
    byte[] arrayOfByte3 = localCipher.doFinal();
    localFileOutputStream.write(arrayOfByte3);
    
    localFileInputStream.close();
    localFileOutputStream.close();
    // Delete original file
    param1File.delete();
}

Trace back where `param2ArrayOfbyte` (the key) and `someDerivedIV` (the IV) are generated or retrieved. They might be hardcoded strings, derived from device identifiers, or fetched from a C2 server.

3. Lock Screen Functionality

Android ransomware often employs device administration privileges to lock the screen, prevent uninstallation, and reset passwords. Look for:

• `android.app.admin.DevicePolicyManager`
• `android.content.ComponentName`
• `startActivity(new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN))`

The malware typically registers a `DeviceAdminReceiver` in the manifest and then prompts the user to activate it. Once activated, it can enforce policies like screen locking.

4. Command and Control (C2) Communication

Ransomware needs to communicate with its authors to report infection status, send encryption keys, or receive commands. Search for network-related keywords:

• `java.net.URL`, `java.net.HttpURLConnection`, `java.net.Socket`
• `org.apache.http` (older Android versions)
• HTTP methods like `POST`, `GET`
• Hardcoded IP addresses or domain names (use “Defined Strings” or search for string literals)

You might find a function that constructs a URL and sends data:

// Example of C2 communication
void sendDataToC2(String param1String1, String param2String2) {
    // param1String1 = C2 URL, param2String2 = data to send
    try {
        URL localURL = new URL(param1String1);
        HttpURLConnection localHttpURLConnection = (HttpURLConnection)localURL.openConnection();
        localHttpURLConnection.setRequestMethod("POST");
        localHttpURLConnection.setDoOutput(true);
        OutputStream localOutputStream = localHttpURLConnection.getOutputStream();
        localOutputStream.write(param2String2.getBytes());
        localOutputStream.flush();
        localOutputStream.close();
        
        // Read response (optional)
        BufferedReader localBufferedReader = new BufferedReader(new InputStreamReader(localHttpURLConnection.getInputStream()));
        // ... process response ...
    } catch (Exception exception) {
        // Error handling
    }
}

Identifying the `param1String1` (C2 URL) is a critical IoC.

Extracting IoCs (Indicators of Compromise)

Throughout your analysis, diligently record any IoCs:

• Package Name: From `AndroidManifest.xml`.
• Hardcoded Strings: C2 URLs, encryption keys, ransom notes, file extensions for encrypted files.
• API Calls: Specific Android API calls that are indicative of malicious behavior (e.g., `DevicePolicyManager` calls, file I/O, network requests).
• File Hashes: (Though not directly from Ghidra, ensure you have the hash of your sample).

Conclusion: Beyond Static Analysis

Static analysis with Ghidra provides a deep understanding of Android ransomware’s inner workings, helping you uncover its methods, identify key components, and extract critical IoCs without the risk of execution. However, it’s often complemented by dynamic analysis, where the malware is run in a controlled environment (emulator or sandbox) to observe its runtime behavior, network traffic, and file system modifications directly. Combining both static and dynamic approaches offers the most comprehensive view of a threat, enabling robust detection and mitigation strategies.