Android Malware Analysis: Reverse Engineering APK to Understand Attacks

How I reverse-engineered the APK to understand what was really happening.

inspired by medium design

Understanding What’s Inside an APK

Think of an APK file like a packaged lunch box. It contains everything an app needs to run. When you unpack it, you find:

• Code files (like recipes)
• Resources (images, text)
• Configuration files (instructions)
• Native libraries (C/C++ code)

Here’s how to unpack an APK using APKTool:

The most important file is AndroidManifest.xml. It's like the app's ID card - showing what permissions it needs and what it can do.

Reading the App’s Mind: Static Analysis

Static analysis means examining the code without running it. I use Jadx for this — it converts the compiled code back to readable Java.

# Using Jadx to decompile
jadx suspicious_app.apk

When I decompiled the weather app, I found these suspicious permissions:

• READ_SMS (why does a weather app need to read texts?)
• ACCESS_FINE_LOCATION (okay for weather, but…)
• READ_PHONE_STATE (can read your phone number and IMEI)

The code also had hidden functions that:

• Read your contact list
• Monitored your SMS messages
• Tracked your exact location every 5 minutes

All this data was being encrypted and sent to an external server.

Watching the App in Action: Dynamic Analysis

Static analysis shows what the app could do. Dynamic analysis shows what it actually does when running.

I use Frida to watch the app while it’s running:

// Hook the SMS reading function
Java.perform(function() {
    var telephony = Java.use("android.telephony.SmsManager");
    
    telephony.sendTextMessage.overload('java.lang.String', 'java.lang.String', 'java.lang.String', 'android.app.PendingIntent', 'android.app.PendingIntent').implementation = function(destination, source, text, sentIntent, deliveryIntent) {
        console.log("[*] SMS being sent to: " + destination);
        console.log("[*] Message: " + text);
        return this.sendTextMessage(destination, source, text, sentIntent, deliveryIntent);
    };
});

When I ran the weather app with this hook, I saw it reading my verification codes and sending them to the attacker’s server.

Analyzing Native Code (SO Files)

Many advanced malware hide their real functionality in native C/C++ code. These are the .so files in the lib folder.

To analyze these, I use tools like IDA Pro or Ghidra:

In the weather app, the native code contained:

• Encryption routines to hide stolen data
• Code to detect if it was running in an emulator (to avoid analysis)
• Communication with command and control servers

Spotting Tricks and Evasion

Malware authors use many tricks to avoid detection:

Get Muhammad Haider Tallal’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Obfuscation: They rename classes and methods to hide what they do.

• Original: sendStolenData()
• Obfuscated: a.a()

Anti-analysis: Code that checks if it’s being analyzed:

Network Traffic Analysis

I intercepted the app’s network traffic using Burp Suite:

# Set up proxy for Android emulator
emulator -avd MyAvd -http-proxy http://127.0.0.1:8080

The weather app was using HTTPS, but I could still see:

• Frequent connections to unknown domains
• Large amounts of data are being uploaded
• Encrypted payloads that matched when I received SMS messages

Creating Detection Rules

Once I understood the malware, I created YARA rules to detect similar apps:

Real Malware Family: Joker

The weather app turned out to be part of the Joker malware family. Joker apps:

• Subscribe users to premium services without consent
• Steal SMS messages and contact lists
• Hide in seemingly legitimate apps
• Frequently change their code to avoid detection

My Analysis Toolkit

Here’s what I keep in my Android malware analysis toolkit:

Static Analysis:

• Jadx (decompiling)
• APKTool (unpacking)
• Androguard (automated analysis)

Dynamic Analysis:

• Frida (runtime hooking)
• Xposed Framework (modification)
• Burp Suite (network monitoring)

Reverse Engineering:

• Ghidra (native code analysis)
• IDA Pro (advanced reverse engineering)
• Radare2 (open-source alternative)

How to Start Your Own Analysis

1. Set up a safe environment — Use an emulator or dedicated test device
2. Start with simple apps — Don’t jump into advanced malware immediately
3. Look for obvious signs — Too many permissions, unknown developers
4. Check network behavior — What servers is it talking to?
5. Search for known patterns — Many malware families have signatures

What I Learned From the Weather App

• Even popular apps can be malicious
• Users don’t always check permissions
• Malware authors are getting better at hiding
• Continuous monitoring is essential

Protecting Your Organization

• Train employees about app risks
• Use mobile device management (MDM)
• Monitor network traffic for suspicious connections
• Regularly audit installed apps
• Consider enterprise app stores