Enhancing Android App Security by Packing Native Libraries (SO) – Loading Process Analysis and Protection Techniques

1. Analysis of the SO Loading Process

The article begins by describing how Android loads native shared libraries (SO files) at runtime, emphasizing the importance of understanding this process for security hardening.

2. Principles of System SO Loading

2.1 Mapping the SO file into memory with mmap

Android uses the mmap system call to map the binary contents of an SO file into the process address space.

2.2 Mapping the memory base address

After mapping, the loader determines the base address where the library will reside.

2.3 Loading the SO code into memory

The executable sections of the SO are loaded into the allocated memory region.

2.4 Mapping the soinfo structure and redirection

The loader creates a soinfo structure that holds metadata about the library and sets up symbol redirection.

2.5 Redirecting system functions

Critical system functions are intercepted and redirected to custom implementations for protection.

2.6 Invoking initialization functions and function arrays

The loader calls the library’s initialization routines and processes any function tables.

2.7 Restoring system permissions

After initialization, the loader restores the original permission state to avoid privilege escalation.

2.8 Encrypting individual functions

Each function can be individually encrypted to make static analysis more difficult.

3. Difficulty Analysis

The article outlines several challenges that arise on different Android versions: after Android 7.0, dlopen no longer returns a soinfo structure, requiring address extraction from /proc/maps ; from Android 5.1 onward, the read operation is replaced by pread64 ; page size variations across Android 4.1.2, 5.0, 7.0 affect memory layout; and from Android 4.4 onward, C++ considerations push the implementation toward pure C for security.

4. Before‑After Protection Comparison

Visual comparisons (illustrated in the original figures) show the impact of the packing technique on the binary size, memory layout, and resistance to reverse‑engineering tools.

The source code for the custom linker and packing method is available at https://github.com/liumengdeqq/CustomLinker.git .