Introduction

The Android Runtime (ART) is the backbone of application execution on modern Android devices, transforming Dalvik bytecode into native machine code. While ART brings performance improvements, its native execution environment also presents a fertile ground for sophisticated malware. Attackers often bypass Java-level security by injecting and hooking native code, enabling deeper control over the device and evading standard detection mechanisms. This article delves into the intricacies of ART and provides expert-level techniques for detecting native code injection and hooking, crucial for robust Android security analysis.

Android Runtime (ART) Fundamentals

ART replaced the Dalvik virtual machine starting with Android 5.0 (Lollipop). Its primary distinction is the adoption of Ahead-Of-Time (AOT) compilation, which compiles DEX bytecode into native machine code during app installation or system updates using the dex2oat tool. This pre-compilation leads to faster app startup times and improved runtime performance compared to Dalvik’s Just-In-Time (JIT) compilation. Modern ART versions also incorporate JIT compilation alongside AOT, allowing for dynamic optimization of frequently executed code paths.

When an Android application launches, ART loads its pre-compiled native code (or compiles it on the fly if AOT is not complete) into the process memory. This native code then interacts with the Android framework, system libraries, and the Linux kernel. Understanding how ART manages this native execution is paramount to identifying deviations introduced by malicious actors.

The Threat: Native Code Injection and Hooking

Malware often targets the native layer for several reasons:

• Stealth: Native code operations are harder to monitor from the Java layer.
• Persistence: Hooking core system functions allows malware to maintain control.
• Privilege Escalation: Interacting directly with the kernel or privileged services.
• Anti-Analysis: Obfuscation and anti-debugging techniques are often implemented natively.

Common Native Injection Vectors

1. dlopen/dlsym Abuse: Malicious actors can use dlopen to load arbitrary shared libraries (e.g., .so files) into a target process at runtime. Once loaded, dlsym can be used to resolve and call functions within these libraries or even replace legitimate function pointers.
2. Zygote Injection: The Zygote process is a core Android component that forks to create new application processes. Injecting code into Zygote affects all subsequently launched applications, making it a powerful and persistent attack vector.
3. Process Hollowing/Mapping: Malware might unmap legitimate sections of a process and map its own malicious code, or simply inject code into existing writable/executable regions.

Native Hooking Techniques

Once injected, native code commonly employs hooking to intercept or modify legitimate function calls:

• PLT/GOT Hooking: The Procedure Linkage Table (PLT) and Global Offset Table (GOT) are used by dynamically linked executables to resolve external function calls. By modifying entries in the GOT, an attacker can redirect calls to legitimate library functions (e.g., read, write, recv) to their own malicious functions.
• Inline Hooking: This technique involves overwriting the initial bytes of a target function’s machine code with a jump instruction to the attacker’s hook function. After the hook executes, it can optionally jump back to the original function (or its restored prologue) to allow the original logic to proceed.
• JNI Native Method Table Replacement: Java Native Interface (JNI) methods registered by an application can be replaced. Malware can locate the JNINativeMethod array and alter the function pointer (fnPtr) to its own native implementation.

Detecting Native Code Injection and Hooking

Memory Map Analysis with /proc//maps

The /proc//maps file provides a snapshot of a process’s virtual memory regions, including loaded libraries, heap, stack, and code segments. Suspicious entries can indicate injected code.

Identifying Suspicious Executable Regions

Analyze the memory maps for regions that are executable (x flag) but do not correspond to known system libraries (e.g., /system/lib, /vendor/lib), the application’s own binary, or standard ART regions. Look for regions that are both writable and executable (rwxp), which is highly unusual and often indicative of malicious activity.

adb shellsu -c 'cat /proc/$(pidof your.app.package)/maps'

Example Output Interpretation:

00100000-00101000 r-xp 00000000 00:00 0 [anon:libc_alloc_zero_init] <-- Suspicious! Not mapped to a file.00200000-00201000 rwxp 00000000 00:00 0 [anon:.data] <-- Highly suspicious if it contains unexpected code.70000000-70001000 r-xp 00000000 00:00 0 anon_inode:dmabuf <-- Potentially suspicious if it's not a legitimate buffer.b0000000-b0001000 r-xp 00000000 00:00 0 /data/data/your.app.package/cache/malware.so <-- Clear injection!

Pay close attention to regions marked [anon] or with unusual paths that have execute permissions. Legitimate anonymous regions rarely have execute permissions unless they are JIT-compiled code areas managed by the runtime itself, but their sizes and locations should be consistent.

Analyzing Loaded Libraries and Symbols

Malware often loads its own shared libraries. While /proc//maps shows loaded shared objects, you can programmatically inspect them.

dl_iterate_phdr for Runtime Library Enumeration

In native code, you can use dl_iterate_phdr to iterate through all loaded shared objects and inspect their program headers. This allows you to check for unexpected libraries loaded by the process.

// Conceptual C/C++ code for dl_iterate_phdrstatic int callback(struct dl_phdr_info *info, size_t size, void *data) {    ALOGI("Loaded library: %s base: %p", info->dlpi_name, (void *)info->dlpi_addr);    // Perform checks on info->dlpi_name or other fields    return 0;}// In your analysis code:dl_iterate_phdr(callback, NULL);

Comparing the list of loaded libraries with a known good baseline can highlight injected modules.

Inspecting Symbol Tables (PLT/GOT)

Detecting PLT/GOT hooking is more complex at runtime without external tools. The attacker modifies entries in the GOT to redirect function calls. Static analysis using tools like readelf can show the original GOT entries, but runtime modifications are harder to spot without comparing the in-memory GOT to the on-disk binary.

readelf -r /system/lib64/libc.so | grep 'recv@GOT'

This command would show the relocation entries for recv in libc.so. At runtime, a debugger or memory inspection tool would be needed to compare the address stored at the GOT entry for recv with its expected address in libc.so. If they differ, it indicates a hook.

Detecting Inline Function Hooking

Inline hooking works by overwriting the first few instructions of a target function with a jump to the hook function. Detection involves comparing the current in-memory bytes of a function’s prologue with its original, legitimate bytes.

Method: Runtime Byte Comparison

1. Obtain the address of the target function (e.g., using dlsym for exported functions).
2. Read the first few bytes (e.g., 4-16 bytes, depending on architecture and instruction size) from that memory address.
3. Compare these bytes with the expected original prologue. The original prologue can be obtained from:

• A known good copy of the binary on disk.
• Dynamically mapping the original binary into memory and reading from there.

// Conceptual C/C++ code for inline hook detection#include <stdio.h>#include <stdlib.h>#include <string.h>#include <dlfcn.h>#define PROLOGUE_SIZE 8 // Example size for ARM64void detect_hook(const char* lib_name, const char* func_name, unsigned char* original_prologue) {    void* handle = dlopen(lib_name, RTLD_LAZY);    if (!handle) {        fprintf(stderr, "Error opening library %s: %sn", lib_name, dlerror());        return;    }    void* func_addr = dlsym(handle, func_name);    if (!func_addr) {        fprintf(stderr, "Error finding function %s in %s: %sn", func_name, lib_name, dlerror());        dlclose(handle);        return;    }    unsigned char current_prologue[PROLOGUE_SIZE];    memcpy(current_prologue, func_addr, PROLOGUE_SIZE);    if (memcmp(current_prologue, original_prologue, PROLOGUE_SIZE) != 0) {        fprintf(stderr, "WARNING: Function %s in %s appears to be hooked!n", func_name, lib_name);    } else {        fprintf(stderr, "Function %s in %s is clean.n", func_name, lib_name);    }    dlclose(handle);}// Example usage (original_prologue must be known/calculated)unsigned char original_read_prologue[] = {0xF0, 0x0F, 0x0C, 0xE1, ...}; // Placeholder bytesdetect_hook("libc.so", "read", original_read_prologue);

This requires careful handling of memory permissions and can be challenging to implement robustly across different Android versions and architectures.

JNI Native Method Table Hooking

Malware can intercept or replace native methods registered by an application. During JNI registration, an array of JNINativeMethod structs is passed to RegisterNatives. Each struct contains the Java method name, signature, and a function pointer (fnPtr) to the native implementation.

typedef struct {    const char* name;    const char* signature;    void*       fnPtr;} JNINativeMethod;

Detection involves:

1. Monitoring RegisterNatives: Hooking the RegisterNatives function itself can allow inspection of the JNINativeMethod array being registered.
2. Post-Registration Inspection: After registration, it’s possible to iterate through an application’s declared native methods and use JNI functions like GetMethodID and GetStaticMethodID to obtain method IDs. Then, using internal ART structures (which are not public API and vary by Android version), one could potentially resolve the underlying native function pointer and compare it to an expected value. This is highly intrusive and often requires a custom ART build or significant runtime introspection.

Advanced Dynamic Analysis Tools

Tools like Frida and Xposed/ART Hooking Frameworks simplify the process of dynamic analysis and hook detection. Frida, in particular, allows for dynamic instrumentation of arbitrary native functions, memory dumping, and inspection of ART’s internal structures, making it invaluable for advanced malware analysis and anti-hooking research.

Conclusion

Detecting native code injection and hooking within the Android ART runtime is a complex but essential task for modern mobile security. By understanding ART’s compilation and execution model, and by employing techniques such as memory map analysis, loaded library inspection, and function prologue comparison, security analysts can uncover sophisticated threats. While no single technique is foolproof, a multi-layered approach combining static analysis, runtime introspection, and dynamic instrumentation tools provides the best defense against advanced native malware on Android.