Introduction

Android application reverse engineering is a critical skill for security researchers, penetration testers, and developers alike. It allows us to understand how an application works internally, identify vulnerabilities, and even modify its behavior for various purposes, including security bypasses. While static analysis of APKs provides valuable insights, many modern Android applications employ advanced runtime security mechanisms like root detection, SSL pinning, and anti-tampering checks that make static modification or simple debugging insufficient. This is where Magisk, a systemless root solution, becomes an indispensable tool. Magisk’s unique architecture allows for deep system modification without altering the /system partition, making it ideal for injecting custom logic directly into running applications without triggering integrity checks. This article will guide you through developing Magisk modules to inject custom code, focusing on bypassing common security controls.

Prerequisites

Before diving into Magisk module development for reverse engineering, ensure you have the following:

• A rooted Android device with Magisk installed.
• Basic understanding of Android architecture and application components.
• Familiarity with shell scripting (Bash).
• Basic knowledge of Java/Kotlin and smali for understanding Android app logic.
• ADB (Android Debug Bridge) installed and configured on your computer.
• A text editor or IDE for writing scripts and module files.
• APKPure or similar tool to download target APKs for analysis.

Understanding Magisk and Module Development

Magisk operates on the principle of a “systemless interface.” Instead of directly modifying the /system partition, Magisk intercepts calls to system files and serves modified versions from its own Magisk image. This allows system updates to proceed without issues and prevents detection by many integrity checks. Magisk modules leverage this systemless approach to introduce custom functionality, ranging from simple themes to complex runtime modifications.

A typical Magisk module consists of:

• module.prop: Metadata about the module (ID, name, author, etc.).
• customize.sh: An installer script executed during module flashing. It can create directories, extract files, and perform initial setup.
• post-fs-data.sh: Executed after /data is mounted, before modules are loaded. Ideal for setting up early mount points or patching device trees.
• service.sh: Executed late in the boot process, after all modules are loaded. This is where most runtime patching, process monitoring, and custom service initiation occurs.

For injecting custom logic into user applications, customize.sh and service.sh are our primary tools.

The Challenge: Bypassing Security Mechanisms

Modern Android applications employ various security measures:

• Root Detection

  Checks for the presence of root binaries (su), Magisk-related files, or writable system partitions. Bypassing often involves hooking methods that perform these checks and forcing them to return a ‘not rooted’ status.

• SSL Pinning

  Ensures that the application only trusts specific server certificates, preventing man-in-the-middle attacks. Bypassing requires hooking network libraries to disable certificate validation or replace the trusted certificate store.

• Anti-Tampering/Integrity Checks

  Verifies the application’s integrity by checking its signature, package name, or file hashes. Magisk’s systemless nature helps avoid some of these, but direct code injection still requires careful execution.

Directly modifying an APK and resigning it can be detected by anti-tampering checks. Magisk offers a more stealthy approach by injecting code at runtime into the app’s process memory.

The Magisk Approach: Runtime Hooking and Code Injection

Our strategy involves using a Magisk module to:

1. Prepare the environment (e.g., placing necessary tools or libraries).
2. Inject a dynamic library (like Frida Gadget) into the target application’s process.
3. Use the injected library to hook methods, modify variables, or execute custom logic.

Frida is an excellent framework for dynamic instrumentation. While Frida offers a `frida-server` for remote instrumentation, embedding `frida-gadget` directly into a Magisk module allows us to automatically inject it into target processes on boot or app launch, without needing a running `frida-server` or modifying the application itself.

Step-by-Step Guide: Creating a Magisk Module for Code Injection

Step 1: Module Structure and Metadata

Create a directory for your module (e.g., MyInjectModule) and populate it:

MyInjectModule/├── module.prop├── customize.sh├── post-fs-data.sh├── service.sh└── system/└── lib64/└── frida-gadget.so

module.prop example:

id=myinjectmodulename=My Custom Injectorauthor=YourNamemagisk=24000version=v1.0.0versionCode=1description=Injects custom logic into target apps using Frida Gadget.

Step 2: Place Frida Gadget

Download the appropriate `frida-gadget.so` for your device’s architecture (e.g., arm64) from Frida’s releases page. Place it in MyInjectModule/system/lib64/frida-gadget.so (or lib for arm/x86).

Step 3: Customizing the Environment with customize.sh

This script runs when the module is flashed. We’ll use it to ensure our Gadget is placed correctly.

# MyInjectModule/customize.sh#!/system/bin/shui_print "- Installing MyInjectModule..."# The Gadget is already in system/lib64, Magisk will handle symlinking it.# We might use this script for more complex setup if needed.# For now, let's just make sure directories exist if we were to copy files dynamically.# Example: Creating a directory for Frida scriptsif [ ! -d "$MODPATH/scripts" ]; then    mkdir -p "$MODPATH/scripts"fiui_print "- Module installation complete."

Step 4: Injecting Logic at Runtime with service.sh

This is the core of our injection strategy. service.sh runs after boot and module loading. We’ll use it to set up environment variables that force specific applications to load our `frida-gadget.so`.

First, identify the target application’s package name (e.g., com.example.targetapp). Then, modify service.sh:

# MyInjectModule/service.sh#!/system/bin/sh# Wait until boot completeswhile [ "$(getprop sys.boot_completed)" != "1" ]; do    sleep 1doneui_print "- MyInjectModule: Boot complete, starting service."TARGET_PKG="com.example.targetapp"# Path to our embedded Frida GadgetLIB_GADGET_PATH="$MODPATH/system/lib64/frida-gadget.so"# Path to a Frida script we want to load (optional, can be passed directly)FRIDA_SCRIPT_PATH="$MODPATH/scripts/bypass_root.js"# Check if Gadget existsif [ ! -f "$LIB_GADGET_PATH" ]; then    ui_print "! ERROR: Frida Gadget not found at $LIB_GADGET_PATH"    exit 1fiui_print "- Injecting Frida Gadget into $TARGET_PKG..."# Set environment variables for the target app to load frida-gadget# This needs to be done *before* the app process starts or is restarted.resetprop "wrap.$TARGET_PKG" "LD_PRELOAD=$LIB_GADGET_PATH frida-gadget -l $FRIDA_SCRIPT_PATH"# Note: The 'wrap' property only takes effect when the app is launched. # You might need to force-stop and restart the app for changes to take effect.# For a persistent solution, ensure the app process restarts or use a more advanced hooking method# like Zygote injection or a custom Xposed/LSPosed module.ui_print "- Frida Gadget injection configured for $TARGET_PKG."ui_print "- Please restart the target app ($TARGET_PKG) for changes to take effect."

The `wrap.$TARGET_PKG` property tells Android’s Zygote process to start the specified application with the `frida-gadget` preloaded and optionally execute a script (`-l`).

Step 5: Create a Frida Script (e.g., for Root Detection Bypass)

Let’s create a simple Frida script (bypass_root.js) that spoofs a root detection method. Assume the target app has a simple root check function like isDeviceRooted().

// MyInjectModule/scripts/bypass_root.jsconsole.log("Frida Gadget: Starting root bypass script.");Java.perform(function () {    var RootChecker = Java.use('com.example.targetapp.security.RootChecker');    if (RootChecker) {        RootChecker.isDeviceRooted.implementation = function () {            console.log("Frida Gadget: RootChecker.isDeviceRooted() called, returning false.");            return false;        };        console.log("Frida Gadget: Hooked RootChecker.isDeviceRooted().");    } else {        console.log("Frida Gadget: RootChecker class not found.");    }    // Example for SSL Pinning Bypass (conceptual)    // var TrustManagerImpl = Java.use('com.android.org.conscrypt.TrustManagerImpl');    // if (TrustManagerImpl) {    //     TrustManagerImpl.checkTrustedRecursive.implementation = function (a, b, c, d) {    //         console.log("Frida Gadget: Bypassing SSL pinning check.");    //         return; // Just return, effectively allowing any certificate    //     };    //     console.log("Frida Gadget: Hooked TrustManagerImpl.checkTrustedRecursive for SSL bypass.");    // }});console.log("Frida Gadget: Root bypass script loaded.");

Place this script in MyInjectModule/scripts/bypass_root.js.

Step 6: Package and Flash the Module

Compress the MyInjectModule directory into a ZIP file. Then, transfer the ZIP to your Android device and flash it via Magisk Manager. After flashing, restart your device. Once restarted, force-stop and reopen the target application (com.example.targetapp). The Frida script will execute, and if successful, the root detection should be bypassed.

Advanced Considerations

• Persistence and Stealth

  The `wrap` property is effective but might not be completely stealthy or persistent if the app is launched directly without Zygote involvement (rare for user apps). For deeper integration, consider using a custom `magisk_zygisk` module or a robust Xposed/LSPosed module that offers fine-grained hooking.

• Dynamic Script Loading

  Instead of embedding the script, you could have the Magisk module fetch scripts dynamically from a network location, allowing for updates without reflashing.

• Error Handling and Logging

  Enhance your service.sh with robust error handling and logging to `/data/adb/magisk_modules/myinjectmodule/log.txt` to debug issues on the device.

• Targeting Multiple Apps

  You can modify service.sh to target multiple applications by iterating through a list of package names and setting `wrap.$PKG` for each.

Conclusion

Magisk provides an incredibly powerful and flexible platform for Android application reverse engineering and security research. By leveraging its systemless nature and combining it with dynamic instrumentation frameworks like Frida, we can overcome complex runtime security mechanisms with relative ease. The ability to inject custom logic directly into application processes opens up a world of possibilities for bypassing root detection, SSL pinning, and other anti-tampering measures, empowering researchers to delve deeper into application internals and uncover critical insights. This guide serves as a foundation; the true power lies in creatively adapting these techniques to specific application challenges.