逆向工程 Cookbook

Android 版本安全特性演进与逆向影响

overkazaf@gmail.com (+5) — Wed, 02 Apr 2025 00:00:00 +0000

Android 版本安全特性演进与逆向影响

Android 系统从 5.0 到 15，每一个大版本都引入了大量安全特性。这些安全增强不仅影响了普通开发者的开发方式，更直接改变了逆向工程师的分析策略和工具选择。不了解目标设备的 Android 版本特性，往往是逆向分析受阻的首要原因。

1. 概述

对于逆向工程师来说，理解 Android 各版本安全特性的演进至关重要，原因如下：

工具兼容性：不同 Android 版本对 Frida、Xposed、Magisk 等工具的支持程度不同，选错工具版本会直接导致注入失败
分析策略差异：Android 7.0 之后的证书信任策略变化使得抓包方式截然不同；Android 9.0 的 Hidden API 限制改变了反射调用的方式
绕过方法更新：每个版本的安全增强都需要对应的绕过手段，旧方法可能在新版本上完全失效
Native 层影响：从 Linker namespace 到 XOM 再到 16KB 页面大小，底层变化影响 SO 分析的每一个环节
加密与认证：Hardware Keystore、BiometricPrompt、MTE 等特性不断提高数据保护强度

实用建议

在开始任何逆向分析任务之前，务必先确认目标设备的 Android 版本和安全补丁级别：

adb shell getprop ro.build.version.release # Android 版本号
adb shell getprop ro.build.version.sdk # API Level
adb shell getprop ro.build.version.security_patch # 安全补丁日期

2. 版本安全特性总览表

下表汇总了 Android 5.0 到 15 各版本的关键安全特性及其对逆向工程的影响：

版本号 (代号)	API Level	关键安全特性	对逆向的影响
5.0-5.1 (Lollipop)	21-22	ART 默认运行时、SELinux enforcing、全盘加密 (FDE)	DEX 优化格式变化（OAT 文件），需新 dump 策略
6.0 (Marshmallow)	23	运行时权限、验证启动、硬件 Keystore、指纹 API	权限检查成为 hook 目标，Keystore 提取需新方法
7.0-7.1 (Nougat)	24-25	网络安全配置、用户证书不信任、Linker namespace、APK Sig v2、FBE	抓包需额外配置，注入需处理 namespace，v2 签名影响重打包
8.0-8.1 (Oreo)	26-27	Project Treble、Vendor/System 分离、HIDL、后台限制	SO 分析需关注分区，后台限制影响持久化 hook
9.0 (Pie)	28	Hidden API 限制、TLS 强制、BiometricPrompt、ASLR 改进	反射调用受限需绕过，ASLR 使内存分析更复杂
10 (Q)	29	Scoped Storage、XOM、TLS 1.3、MAC 随机化	XOM 使 .text 不可读，Scoped Storage 影响 dump 路径
11 (R)	30	包可见性限制、APK Sig v4、GWP-ASan	应用枚举受限，需 QUERY_ALL_PACKAGES 权限
12-12L (S)	31-32	隐私面板、ART Mainline 模块化、ASLR 增强	ART 可独立更新，调试限制增强
13 (T)	33	通知权限、Intent filter 验证增强	Intent filter 验证影响 deep link 测试
14 (U)	34	Credential Manager、16KB 页面大小支持、minSdkVersion 限制	SO 段对齐变化，旧工具重打包受限
15 (V)	35	16KB 页面全面支持、MTE 生产可用、Privacy Sandbox	MTE 影响内存分析和 exploit，16KB 页面成硬性要求

3. 详细版本分析

3.1 Android 5.0-5.1 (Lollipop, API 21-22)

Android 5.0 是 Android 安全架构的分水岭，三项核心变化奠定了现代 Android 安全的基础。

3.1.1 ART 取代 Dalvik 成为默认运行时

Android 5.0 将 ART (Android Runtime) 确立为唯一的运行时环境，彻底取代了 Dalvik。ART 使用 AOT (Ahead-Of-Time) 编译，在应用安装时将 DEX 字节码编译为本地机器码。

核心变化：

DEX 字节码不再直接解释执行，而是被编译为 OAT (Optimized Android runtime application) 格式
编译产物路径从 /data/dalvik-cache/ 下的 .dex 文件变为 .odex（实际是 OAT 格式）
运行时方法调用方式发生根本改变

# 查看 OAT 文件
adb shell ls /data/dalvik-cache/arm64/
# 使用 oatdump 分析
oatdump --oat-file=/data/dalvik-cache/arm64/system@app@SomeApp@SomeApp.apk@classes.dex

3.1.2 SELinux Enforcing Mode 全面启用

Android 5.0 将 SELinux 从 Permissive 模式切换到 Enforcing 模式，意味着所有违反安全策略的操作都会被阻止，而不仅仅是记录日志。

# 查看 SELinux 状态
adb shell getenforce
# 输出: Enforcing

# 查看 SELinux 策略
adb shell ls -la /sys/fs/selinux/

3.1.3 全盘加密 (FDE)

Android 5.0 要求新出厂设备默认启用全盘加密 (Full Disk Encryption)，使用 dm-crypt 对 /data 分区进行加密。

对逆向的影响

影响点	具体变化	应对策略
DEX dump	OAT 格式取代直接 DEX 执行	使用 `oatdump`、`baksmali` 适配 OAT 格式
方法 Hook	ART 方法结构与 Dalvik 不同	更新 Hook 框架至 ART 兼容版本
SELinux 阻止	文件操作、ptrace 等被策略限制	需要修改 SELinux 策略或切换到 Permissive
数据获取	全盘加密阻止离线数据读取	需要在设备解锁状态下操作

3.2 Android 6.0 (Marshmallow, API 23)

3.2.1 运行时权限模型

Android 6.0 将敏感权限从安装时授予改为运行时动态申请。应用需要在代码中显式请求危险权限，用户可以拒绝或撤销。

// 运行时权限检查代码（逆向分析中常见的 hook 目标）
if (ContextCompat.checkSelfPermission(this, Manifest.permission.READ_PHONE_STATE)
 != PackageManager.PERMISSION_GRANTED) {
 ActivityCompat.requestPermissions(this,
 new String[]{Manifest.permission.READ_PHONE_STATE}, REQUEST_CODE);
}

逆向关注点：checkSelfPermission 和 requestPermissions 是常见的 hook 目标，可以通过 Frida 直接返回 PERMISSION_GRANTED 绕过权限检查。

// Frida 绕过运行时权限检查
Java.perform(function() {
 var ContextCompat = Java.use('androidx.core.content.ContextCompat');
 ContextCompat.checkSelfPermission.implementation = function(context, permission) {
 console.log('[*] checkSelfPermission: ' + permission);
 return 0; // PERMISSION_GRANTED
 };
});

3.2.2 验证启动 (Verified Boot)

Android 6.0 强化了验证启动机制，确保从引导加载程序到系统分区的完整信任链。修改 system 分区会触发验证失败。

3.2.3 硬件级密钥库 (Hardware Keystore)

Android 6.0 引入了硬件级别的密钥库 API，密钥存储在 TEE (Trusted Execution Environment) 或专用安全芯片中。

对逆向影响：

存储在硬件 Keystore 中的密钥无法通过软件方式提取
加密操作在 TEE 内部完成，无法通过内存 dump 获取密钥材料
需要 hook KeyStore API 调用来拦截加密前/解密后的明文数据

// Frida hook KeyStore 操作
Java.perform(function() {
 var Cipher = Java.use('javax.crypto.Cipher');
 Cipher.doFinal.overload('[B').implementation = function(input) {
 console.log('[*] Cipher.doFinal input: ' + bytesToHex(input));
 var result = this.doFinal(input);
 console.log('[*] Cipher.doFinal output: ' + bytesToHex(result));
 return result;
 };
});

3.2.4 指纹认证 API

Android 6.0 引入 FingerprintManager API，允许应用使用设备指纹传感器进行身份验证。

3.3 Android 7.0-7.1 (Nougat, API 24-25)

Android 7.0 对逆向工程的影响极为深远，尤其是网络安全配置的引入，直接改变了流量拦截的方式。

3.3.1 网络安全配置 (Network Security Config)

这是影响逆向分析最深远的变化之一。Android 7.0 引入了 network_security_config.xml，允许应用以声明式方式配置网络安全策略。

最关键的变化：默认情况下，应用不再信任用户安装的 CA 证书。这意味着在设备上安装 mitmproxy/Burp 等代理的证书后，targetSdkVersion >= 24 的应用会拒绝连接。

<!-- 应用的默认行为 (targetSdkVersion >= 24) -->
<network-security-config>
 <base-config>
 <trust-anchors>
 <certificates src="system"/>
 <!-- 注意：没有 user 证书源 -->
 </trust-anchors>
 </base-config>
</network-security-config>

绕过证书信任限制

方法一：修改 APK 中的网络安全配置

反编译 APK 后，添加或修改 network_security_config.xml，使其信任用户证书：

<!-- network_security_config.xml -->
<network-security-config>
 <base-config>
 <trust-anchors>
 <certificates src="system"/>
 <certificates src="user"/>
 </trust-anchors>
 </base-config>
</network-security-config>

然后在 AndroidManifest.xml 中引用：

<application
 android:networkSecurityConfig="@xml/network_security_config"
 ...>

方法二：Magisk + MoveCert 模块

将用户证书移动到系统证书目录，使其被视为系统证书：

# 1. 安装 Magisk (确保版本 24+)
# 2. 安装 MagiskTrustUserCerts 模块
# 模块地址: https://github.com/NVISOsecurity/MagiskTrustUserCerts

# 安装用户证书后，模块会自动将其复制到 /system/etc/security/cacerts/
# 重启设备生效

# 验证证书是否在系统目录
adb shell ls /system/etc/security/cacerts/ | grep -i "hash"

方法三：Frida SSL Pinning Bypass

使用 Frida 在运行时绕过 SSL 证书验证：

// Frida SSL Pinning Bypass (通用版)
Java.perform(function() {
 // 绕过 TrustManager
 var TrustManagerImpl = Java.use('com.android.org.conscrypt.TrustManagerImpl');
 TrustManagerImpl.verifyChain.implementation = function(untrustedChain,
 trustAnchorChain, host, clientAuth, ocspData, tlsSctData) {
 console.log('[*] SSL Pinning Bypass: ' + host);
 return untrustedChain;
 };

 // 绕过 OkHttp CertificatePinner
 try {
 var CertificatePinner = Java.use('okhttp3.CertificatePinner');
 CertificatePinner.check.overload('java.lang.String', 'java.util.List')
 .implementation = function(hostname, peerCertificates) {
 console.log('[*] OkHttp SSL Pinning Bypass: ' + hostname);
 return;
 };
 } catch (e) {
 console.log('[*] OkHttp not found, skipping...');
 }

 // 绕过 WebView SSL 错误
 var WebViewClient = Java.use('android.webkit.WebViewClient');
 WebViewClient.onReceivedSslError.implementation = function(view, handler, error) {
 console.log('[*] WebView SSL Error Bypass');
 handler.proceed();
 };
});

3.3.2 Linker Namespace 隔离

Android 7.0 引入了 Linker namespace 机制，限制应用只能加载特定路径下的共享库，防止应用访问系统内部的私有 SO 库。

# namespace 隔离示意
┌──────────────────────────────────────────┐
│ Android 7.0+ Linker │
├──────────────────────────────────────────┤
│ │
│ ┌────────────┐ ┌────────────┐ │
│ │ default │ │ classloader│ │
│ │ namespace │ │ namespace │ │
│ ├────────────┤ ├────────────┤ │
│ │ /system/lib│ │ /data/app/ │ │
│ │ /vendor/lib│ │ app的SO │ │
│ └────────────┘ └────────────┘ │
│ ↕ 受限访问 │
└──────────────────────────────────────────┘

对逆向影响：Frida 和 Xposed 注入时需要处理 namespace 隔离，否则可能无法正确加载或 hook 目标 SO。

3.3.3 APK Signature Scheme v2

APK Signature Scheme v2 对整个 APK 文件进行签名验证（而非仅 JAR 签名），修改 APK 任何部分都会导致签名失效。

对逆向影响：重打包后必须使用支持 v2 签名的工具重新签名：

# 使用 apksigner 进行 v2 签名
apksigner sign --ks my-key.jks --ks-key-alias mykey \
 --v1-signing-enabled true --v2-signing-enabled true \
 modified.apk

# 验证签名
apksigner verify --verbose modified.apk

3.3.4 File-Based Encryption (FBE)

Android 7.0 引入基于文件的加密 (FBE) 取代全盘加密 (FDE)，允许不同文件使用不同密钥加密，支持 Direct Boot 模式。

3.3.5 JIT 编译器回归 (Profile-Guided Compilation)

ART 重新引入 JIT 编译器，与 AOT 结合形成混合编译模式：

应用首次安装 → 全部解释执行/JIT
 ↓
 收集运行时 Profile
 ↓
 设备空闲时执行 AOT 编译（仅热点代码）
 ↓
 后续运行: 热点代码 AOT 执行 + 冷代码 JIT/解释执行

对逆向影响：方法可能处于不同的编译状态，hook 时需要考虑方法是 AOT 编译还是解释执行。

3.4 Android 8.0-8.1 (Oreo, API 26-27)

3.4.1 Project Treble (HAL 接口标准化)

Project Treble 是 Android 架构的一次重大重构，将 vendor（硬件相关）实现与 Android 框架分离：

┌──────────────────────────────────────────────┐
│ Android 8.0+ 架构 │
├──────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Framework │ │ Apps │ ← system 分区 │
│ └────┬─────┘ └──────────┘ │
│ │ HIDL │
│ ┌────┴─────┐ │
│ │ Vendor │ ← vendor 分区 │
│ │ HAL │ │
│ └──────────┘ │
│ │
└──────────────────────────────────────────────┘

3.4.2 Vendor/System 分区分离

SO 库被严格按照分区组织：

# System SO 路径
/system/lib64/ # 框架层 SO
/system/lib64/hw/ # System HAL 库

# Vendor SO 路径
/vendor/lib64/ # 厂商 SO
/vendor/lib64/hw/ # Vendor HAL 库

# 查看 SO 所在分区
adb shell ls -la /system/lib64/ | head -20
adb shell ls -la /vendor/lib64/ | head -20

3.4.3 HIDL (HAL Interface Definition Language)

HIDL 定义了 Framework 与 Vendor HAL 之间的稳定接口，使用 Binder IPC 进行跨进程通信。

3.4.4 更严格的后台限制

Android 8.0 对后台服务施加了严格限制：

后台服务在一定时间后被系统终止
隐式广播限制
后台定位更新频率降低

对逆向影响：

需要持久化运行的 hook 框架（如 Frida gadget）可能被后台限制影响
需要将服务声明为前台服务或使用 Work Manager

Treble 架构下的 SO 查找技巧

# 查找特定 SO 在哪个分区
adb shell find /system /vendor /product /apex -name "libtarget.so" 2>/dev/null

# 查看 SO 的链接依赖
adb shell readelf -d /vendor/lib64/libtarget.so | grep NEEDED

# 查看 vendor namespace 中可见的库
adb shell cat /system/etc/ld.config.txt | grep -A 10 "\[vendor\]"

# 列出 HIDL 服务
adb shell lshal

3.5 Android 9.0 (Pie, API 28)

Android 9.0 对逆向工程引入了几项影响深远的限制。

3.5.1 非 SDK 接口限制 (Hidden API Restrictions)

这是对 Java 层逆向影响最大的变化之一。Android 9.0 开始限制应用通过反射、JNI 等方式访问 SDK 中未公开的内部 API（标记为 @hide 的 API）。

限制分级：

列表	说明	限制程度
whitelist	公开 SDK API	无限制
light-greylist	宽松灰名单	可用但有警告
dark-greylist	严格灰名单	targetSdk >= 28 被阻止
blacklist	黑名单	完全阻止

绕过方法一：双重反射

// 通过双重反射绕过 Hidden API 限制
// 原理: 系统检查的是"调用者"的身份, 双重反射让"调用者"变成系统自己
Method forName = Class.class.getDeclaredMethod("forName", String.class);
Method getDeclaredMethod = Class.class.getDeclaredMethod(
 "getDeclaredMethod", String.class, Class[].class);

// 通过双重反射获取 VMRuntime
Class<?> vmRuntime = (Class<?>) forName.invoke(null, "dalvik.system.VMRuntime");
Method setHiddenApiExemptions = (Method) getDeclaredMethod.invoke(
 vmRuntime, "setHiddenApiExemptions", new Class[]{String[].class});

// 获取 VMRuntime 实例并设置豁免
Method getRuntime = (Method) getDeclaredMethod.invoke(
 vmRuntime, "getRuntime", new Class[0]);
Object runtime = getRuntime.invoke(null);

// 豁免所有隐藏 API（传入 "L" 表示所有以 L 开头的签名，即所有类）
setHiddenApiExemptions.invoke(runtime, new Object[]{new String[]{"L"}});

绕过方法二：Frida 运行时绕过

// Frida 绕过 Hidden API 限制
Java.perform(function() {
 var VMRuntime = Java.use('dalvik.system.VMRuntime');
 var runtime = VMRuntime.getRuntime();
 runtime.setHiddenApiExemptions(['L']);
 console.log('[*] Hidden API restrictions bypassed');
});

绕过方法三：通过 adb 设置

# 开发/测试环境下可直接通过 adb 关闭限制
adb shell settings put global hidden_api_policy 1
# 0 = 不检测 (disable)
# 1 = 仅警告 (just warn)
# 2 = 不允许 dark greylist
# 3 = 不允许所有非 SDK API

3.5.2 TLS 默认强制

Android 9.0 默认禁止明文 HTTP 流量 (cleartext traffic)。应用必须使用 HTTPS，除非在网络安全配置中显式允许明文。

<!-- 允许明文流量（逆向测试环境配置） -->
<network-security-config>
 <base-config cleartextTrafficPermitted="true">
 <trust-anchors>
 <certificates src="system"/>
 <certificates src="user"/>
 </trust-anchors>
 </base-config>
</network-security-config>

3.5.3 BiometricPrompt API

Android 9.0 引入统一的生物识别认证 API BiometricPrompt，替代了 Android 6.0 的 FingerprintManager。

3.5.4 DNS over TLS

系统级 DNS over TLS 支持（Private DNS），使得 DNS 查询也被加密，影响 DNS 层面的流量拦截。

3.5.5 ASLR 改进

Android 9.0 改进了地址空间布局随机化 (ASLR)，增加了代码和数据段的随机化程度。

对逆向影响：

每次进程重启后，库的加载基址都会变化
不能依赖固定地址进行 hook，需要动态计算偏移
使用 Frida 的 Module.findBaseAddress() 获取实际加载地址

// Frida 中动态获取 SO 基址
var base = Module.findBaseAddress('libtarget.so');
console.log('[*] libtarget.so base: ' + base);

// 基于偏移 hook
var targetFunc = base.add(0x1234);
Interceptor.attach(targetFunc, {
 onEnter: function(args) {
 console.log('[*] targetFunc called');
 }
});

3.6 Android 10 (Q, API 29)

Android 10 在原生安全层面引入了多项重要变化。

3.6.1 Scoped Storage (分区存储)

应用只能访问自己的私有目录和特定的公共媒体文件，不再能自由访问外部存储。

对逆向影响：

文件 dump 路径受限，不能随意写入 /sdcard/ 目录
Frida 脚本中保存文件需要使用应用的私有目录

// Frida 在 Scoped Storage 环境下保存文件
Java.perform(function() {
 var context = Java.use('android.app.ActivityThread')
 .currentApplication().getApplicationContext();
 var filesDir = context.getFilesDir().getAbsolutePath();
 console.log('[*] 可写目录: ' + filesDir);
 // 文件操作使用 filesDir 作为基础路径
});

3.6.2 Execute-Only Memory (XOM)

Android 10 为 native 代码引入了仅执行内存 (XOM) 机制。.text 段被标记为仅执行，不可读取。

核心影响：传统的内存 dump 技术无法直接读取代码段。

# XOM 内存权限对比
传统 (Android 9 及更早):
 .text 段权限: r-x (可读可执行)
 可以直接通过 /proc/pid/mem 读取代码

Android 10+ (XOM 启用):
 .text 段权限: --x (仅执行)
 通过 /proc/pid/mem 读取 .text 段返回全零

XOM 绕过技术：

# 绕过方法 1: 使用 ptrace (Frida 默认使用此方式)
# ptrace 系统调用不受 XOM 限制
# Frida 通过 ptrace attach 到目标进程后可以正常读取代码段

# 绕过方法 2: 通过 adb 禁用 XOM (需要 root)
# adb shell setprop debug.arm64.xom false
# 部分设备可能不支持此属性

# 绕过方法 3: 修改 ELF phdr 移除 XOM 标志
# 将 PF_X (仅执行) 改为 PF_R|PF_X (可读可执行)
# 需要修改 SO 文件的 Program Header

# 绕过方法 4: 利用 mmap 重新映射
# 在 Frida 脚本中重新映射代码段为可读

// Frida 检查 XOM 状态
function checkXOM(moduleName) {
 var module = Process.findModuleByName(moduleName);
 if (module) {
 Process.enumerateRanges('--x').forEach(function(range) {
 if (range.base.compare(module.base) >= 0 &&
 range.base.compare(module.base.add(module.size)) < 0) {
 console.log('[*] XOM 区域: ' + range.base + ' - '
 + range.base.add(range.size)
 + ' 权限: ' + range.protection);
 }
 });
 }
}

// 通过 Frida 读取 XOM 保护的代码段
function readXOMCode(address, size) {
 // Frida 通过 ptrace 可以绕过 XOM 限制
 try {
 var buf = Memory.readByteArray(address, size);
 console.log('[*] 成功读取 ' + size + ' 字节');
 return buf;
 } catch (e) {
 console.log('[-] 读取失败: ' + e);
 return null;
 }
}

3.6.3 TLS 1.3 默认启用

Android 10 默认启用 TLS 1.3，提供更快的握手速度和更强的安全性。

对逆向影响：TLS 1.3 加密了更多的握手信息（如证书），使被动嗅探更加困难。但使用中间人代理（如 mitmproxy）的主动拦截仍然有效。

3.6.4 MAC 地址随机化

Android 10 对每个 Wi-Fi 网络使用随机 MAC 地址，防止跨网络跟踪设备。

对逆向影响：

基于 MAC 地址的设备指纹识别失效
分析设备指纹时需要关注应用是否使用了其他持久化标识符

3.7 Android 11 (R, API 30)

3.7.1 包可见性限制 (Package Visibility)

Android 11 限制了应用查询其他已安装应用的能力。默认情况下，应用只能看到特定的系统应用和在 <queries> 标签中声明的应用。

<!-- AndroidManifest.xml 中声明需要查询的包 -->
<manifest>
 <queries>
 <package android:name="com.target.app"/>
 </queries>

 <!-- 或者请求完全的包可见性 -->
 <uses-permission android:name="android.permission.QUERY_ALL_PACKAGES"/>
</manifest>

对逆向影响：

编写分析工具时，枚举已安装应用需要 QUERY_ALL_PACKAGES 权限
hook PackageManager.getInstalledPackages() 可能返回不完整的结果

// Frida 绕过包可见性限制
Java.perform(function() {
 var PackageManager = Java.use('android.app.ApplicationPackageManager');
 PackageManager.getInstalledPackages.overload('int').implementation = function(flags) {
 // 通过调用系统服务直接获取完整列表
 console.log('[*] getInstalledPackages called with flags: ' + flags);
 var result = this.getInstalledPackages(flags);
 console.log('[*] Returned ' + result.size() + ' packages');
 return result;
 };
});

3.7.2 APK Signature Scheme v4

APK Signature Scheme v4 主要服务于 ADB 增量安装 (adb install --incremental)，生成一个单独的 .idsig 文件。

对逆向影响：v4 签名不影响传统的 APK 重打包流程，因为 v4 签名是可选的，且仅用于优化安装速度。

3.7.3 Scoped Storage 强制执行

Android 11 强制所有应用使用 Scoped Storage，移除了 requestLegacyExternalStorage 的豁免。

3.7.4 GWP-ASan (内存安全检测)

GWP-ASan 是一个概率性的内存安全检测器，可以检测 use-after-free 和 heap-buffer-overflow。

对逆向影响：

利用内存安全漏洞的 exploit 可能被 GWP-ASan 检测到
分析 crash 时需要区分 GWP-ASan 报告和普通 crash

3.8 Android 12-12L (S, API 31-32)

3.8.1 隐私面板 (Privacy Dashboard)

Android 12 引入隐私面板，显示过去 24 小时内应用对敏感权限（位置、摄像头、麦克风）的访问记录。

3.8.2 ART 模块化 (Mainline)

这是一项对逆向工程有深远影响的变化。ART 运行时成为 Project Mainline 的一部分，可以通过 Google Play 系统更新独立于 Android 版本进行更新。

对逆向影响：

同一个 Android 12 设备，ART 运行时版本可能不同
hook 框架（如 Frida）的兼容性可能在 ART 模块更新后出现问题
分析 ART 内部结构时需要确认具体的 ART 版本

# 查看 ART 模块版本
adb shell pm list packages | grep com.google.android.art
adb shell dumpsys package com.google.android.art | grep version

# 查看 ART apex 信息
adb shell ls -la /apex/com.android.art/

3.8.3 ASLR 增强

Android 12 进一步增强了 ASLR，增大了地址空间随机化范围，特别是对 64 位进程。

3.8.4 Restricted Debugging 增强

Android 12 增强了对非 debuggable 应用的调试限制。

绕过 Restricted Debugging 的方法：

# 方法 1: 使用 Magisk 修改 ro.debuggable 属性
# 在 Magisk 的 post-fs-data.sh 中添加:
resetprop ro.debuggable 1

# 方法 2: 重打包 APK 启用 debuggable
# 在 AndroidManifest.xml 中添加:
# android:debuggable="true"

# 方法 3: 使用 Frida 直接注入（不需要 debuggable）
frida -U -f com.target.app -l hook.js --no-pause

// Frida 绕过 debuggable 检查
Java.perform(function() {
 var ApplicationInfo = Java.use('android.content.pm.ApplicationInfo');
 var GET_META_DATA = 128;

 // 一些应用会检查自身是否为 debuggable
 var PackageManager = Java.use('android.app.ApplicationPackageManager');
 PackageManager.getApplicationInfo.overload('java.lang.String', 'int')
 .implementation = function(packageName, flags) {
 var info = this.getApplicationInfo(packageName, flags);
 // 移除 FLAG_DEBUGGABLE 标志，防止反调试检测
 info.flags.value = info.flags.value & ~2; // FLAG_DEBUGGABLE = 0x2
 return info;
 };
});

3.9 Android 13 (T, API 33)

3.9.1 通知权限 (POST_NOTIFICATIONS)

Android 13 将通知发送权限改为运行时权限，应用需要显式请求 POST_NOTIFICATIONS 权限。

3.9.2 按应用语言设置

允许用户为每个应用单独设置语言，应用可能根据语言配置加载不同的资源或执行不同的逻辑分支。

3.9.3 Intent Filter 验证增强

Android 13 加强了 Intent Filter 的验证，自动验证的 App Link 域名需要通过更严格的 Digital Asset Links 验证。

对逆向影响：

测试 deep link 时需要确保域名验证通过，或使用 adb 命令手动触发
分析应用的路由逻辑时需要关注 Intent Filter 配置

# 测试 deep link（不受 Intent Filter 验证限制）
adb shell am start -a android.intent.action.VIEW \
 -d "https://example.com/deeplink?param=value" \
 com.target.app

# 查看应用的 Intent Filter 验证状态
adb shell pm get-app-links com.target.app

# 手动重置验证状态
adb shell pm set-app-links --package com.target.app 0 all

3.9.4 更细粒度的媒体权限

READ_EXTERNAL_STORAGE 被拆分为 READ_MEDIA_IMAGES、READ_MEDIA_VIDEO 和 READ_MEDIA_AUDIO。

对逆向影响：权限模型继续复杂化，hook 权限检查时需要覆盖更多的权限类型。

3.10 Android 14 (U, API 34)

3.10.1 Credential Manager API

Android 14 引入 Credential Manager 统一管理密码、通行密钥 (Passkeys) 和联合登录凭据。

3.10.2 16KB 页面大小支持（部分设备）

这是对 Native 层逆向影响最大的变化之一。部分 Android 14 设备开始支持 16KB 内存页面大小（传统为 4KB）。

核心影响：

# 4KB 页面 (传统): .text 段对齐到 0x1000 (4096)
# 16KB 页面 (Android 14+): .text 段对齐到 0x4000 (16384)

# 分析工具需要适配新的对齐方式
# 使用 readelf 检查段对齐:
readelf -l libtarget.so | grep LOAD

# 4KB 页面设备的典型输出:
# LOAD 0x000000 0x00000000 0x00000000 0x01234 0x01234 R 0x1000
# LOAD 0x001000 0x00001000 0x00001000 0x05678 0x05678 R E 0x1000

# 16KB 页面设备的典型输出:
# LOAD 0x000000 0x00000000 0x00000000 0x01234 0x01234 R 0x4000
# LOAD 0x004000 0x00004000 0x00004000 0x05678 0x05678 R E 0x4000

对逆向影响详解：

影响方面	4KB 页面	16KB 页面
段对齐	0x1000	0x4000
内存映射粒度	4KB	16KB
ELF 段间距	较小	较大（更多填充）
偏移计算	基于 0x1000	基于 0x4000
工具兼容性	所有工具支持	需要工具更新

# 查看设备页面大小
adb shell getconf PAGE_SIZE
# 输出 4096 或 16384

# 检查 SO 是否兼容 16KB 页面
# 如果 LOAD 段的 p_align 小于 0x4000，可能不兼容
readelf -l libtarget.so | grep -E "LOAD|Align"

3.10.3 更严格的隐式 Intent 限制

Android 14 要求隐式 Intent 必须指定目标组件的导出状态，未导出的组件不能通过隐式 Intent 启动。

3.10.4 minSdkVersion 限制

Android 14 不允许安装 minSdkVersion 低于 23 (Android 6.0) 的 APK。

对逆向影响：

一些旧版逆向工具（如早期的 Xposed Installer）的 APK 无法安装
重打包时需要确保 minSdkVersion >= 23

# 查看 APK 的 minSdkVersion
aapt2 dump badging target.apk | grep sdkVersion
# 或
apktool d target.apk && grep minSdkVersion target/apktool.yml

3.11 Android 15 (V, API 35)

3.11.1 16KB 页面大小全面支持

Android 15 将 16KB 页面大小从可选变为全面支持，所有新发布的设备和 SO 库都需要适配。

必须适配的要点：

所有 Native 库的 ELF 段必须按 16KB 对齐
使用 NDK r27+ 编译以确保兼容
旧的 SO 库可能无法在 16KB 页面设备上加载

# 检查 SO 是否兼容 16KB 页面
# 需要所有 LOAD 段的 p_align >= 0x4000
check_16kb_compat() {
 local so_file=$1
 readelf -l "$so_file" 2>/dev/null | grep "LOAD" | while read line; do
 align=$(echo "$line" | awk '{print $NF}')
 if [ "$align" != "0x4000" ] && [ "$align" != "0x10000" ]; then
 echo "[-] $so_file: 不兼容 16KB 页面 (align=$align)"
 return 1
 fi
 done
 echo "[+] $so_file: 兼容 16KB 页面"
}

# 批量检查应用中的所有 SO
for so in $(unzip -l target.apk | grep "\.so$" | awk '{print $4}'); do
 unzip -o target.apk "$so" -d /tmp/check_so/
 check_16kb_compat "/tmp/check_so/$so"
done

3.11.2 MTE (Memory Tagging Extension) 生产可用

MTE 是 ARMv8.5-A 引入的硬件级内存安全特性，Android 15 将其推向生产可用状态。MTE 在指针的高位（Top Byte）存储一个 4-bit 的标签 (tag)，并在内存分配时为每个 16 字节的内存 granule 分配一个对应的标签。访问内存时，硬件自动检查指针标签与内存标签是否匹配。

# MTE 指针格式
指针值: 0x0B00007F12345678
 ^^
 ||-- 4-bit memory tag (值: 0x0B)
 |
 高位字节中的标签

# 内存布局:
地址: 0x7F12345670 0x7F12345680 0x7F12345690
标签: [0B] [0B] [03]
 ↑ 匹配 ↑ 匹配 ↑ 不匹配 → 触发异常

# 影响所有基于指针的分析:
# 1. 读取指针值时需要 mask 掉 tag bits
# 2. 构造指针时需要设置正确的 tag
# 3. 内存扫描需要考虑 tagged pointer

MTE 对逆向工程的影响：

影响方面	详细说明
指针分析	所有指针高位包含 tag，直接使用会导致地址错误
内存 dump	dump 的指针值包含 tag，需要 mask 后才能使用
Exploit 开发	UAF 和堆溢出被硬件检测，利用难度大幅增加
Hook 框架	需要正确处理 tagged pointer，否则 hook 可能失败
调试工具	GDB/LLDB 需要支持 MTE 才能正确显示地址

// Frida 中处理 MTE tagged pointer
function untagPointer(ptr) {
 // 移除高字节中的 MTE tag
 // ARM64 的 TBI (Top Byte Ignore) 允许高字节存储 tag
 var mask = ptr_size === 8
 ? ptr('0x00FFFFFFFFFFFFFF')
 : ptr('0xFFFFFFFF');
 return ptr.and(mask);
}

// 使用示例
Interceptor.attach(targetAddr, {
 onEnter: function(args) {
 var rawPtr = args[0];
 var cleanPtr = untagPointer(rawPtr);
 console.log('[*] Raw pointer: ' + rawPtr);
 console.log('[*] Clean pointer: ' + cleanPtr);
 console.log('[*] MTE tag: 0x' +
 rawPtr.shr(56).and(0xF).toString(16));
 }
});

3.11.3 Privacy Sandbox

Privacy Sandbox 旨在替代广告追踪标识符（如 GAID），引入 Topics API、Attribution Reporting 等新机制。

对逆向影响：分析广告 SDK 和用户追踪机制时需要了解新的 Privacy Sandbox API。

3.11.4 截屏检测 API

Android 15 引入了 Activity.ScreenCaptureCallback，允许应用检测用户截屏行为。

4. 逆向工具兼容性矩阵

下表展示了主流逆向工具在不同 Android 版本范围内的兼容性情况：

工具	Android 7-9	Android 10-12	Android 13-15	关键适配点
Frida	✅	✅	✅ (需适配)	XOM 绕过、SELinux 策略、MTE 兼容
Xposed (原版)	✅	❌	❌	仅支持 ART 5.0-8.1，已停止维护
LSPosed	❌	✅	✅	基于 Riru/Zygisk，需要 Magisk
Magisk	✅	✅	✅ (需最新版)	版本 24+ 改用 Zygisk 架构
objection	✅	✅	✅	基于 Frida，兼容性取决于 Frida
apktool	✅	✅	✅ (v2.9+)	需适配新资源格式和签名方案
jadx	✅	✅	✅	Java/Kotlin 反编译无版本差异
IDA Pro	✅	✅	✅	Native 层静态分析无版本差异
Ghidra	✅	✅	✅	同上，但需关注 16KB 页面对齐
r2/radare2	✅	✅	✅	同上

工具版本建议：

# 推荐的工具最低版本（截至 2025 年）
Frida: >= 16.x # 支持 Android 14/15 新特性
Magisk: >= 26.x # Zygisk 架构稳定版
LSPosed: >= 1.9.x # 最新 Zygisk 模块版本
apktool: >= 2.9.x # 支持新资源格式
objection: >= 1.11.x # 基于最新 Frida

5. APK 签名方案演进

APK 签名方案从 v1 到 v4 经历了四代演进，每一代都增强了安全性。

5.1 签名方案对比

方案	引入版本	签名范围	防篡改能力	重打包难度
v1 (JAR Signing)	所有版本	仅 ZIP 条目	弱：可修改未签名条目	低
v2 (APK Sig Scheme)	Android 7.0+	整个 APK 文件	强：文件级完整性	中
v3 (Key Rotation)	Android 9.0+	整个 APK + 密钥轮换	强：支持证书链	中
v4 (Incremental)	Android 11+	增量安装验证	补充：仅用于安装优化	不影响

5.2 各方案详解

v1: JAR Signing

APK (ZIP 格式)
├── classes.dex ← 签名覆盖
├── resources.arsc ← 签名覆盖
├── res/ ← 签名覆盖
├── lib/ ← 签名覆盖
├── META-INF/
│ ├── MANIFEST.MF ← 各文件 SHA 摘要
│ ├── CERT.SF ← MANIFEST.MF 的签名
│ └── CERT.RSA ← 证书 + 签名
└── assets/ ← 签名覆盖

弱点：

仅对 ZIP 条目进行独立签名
可以在不破坏签名的情况下在 ZIP 文件的注释区域添加数据
可以利用 ZIP 格式的特性绕过部分检查

v2: APK Signature Scheme v2

APK 文件结构 (v2 签名):
┌──────────────────────┐
│ ZIP 内容区 │ ← 签名保护区域 1
├──────────────────────┤
│ APK Signing Block │ ← 包含 v2 签名数据
├──────────────────────┤
│ 中央目录 │ ← 签名保护区域 2
├──────────────────────┤
│ 中央目录结尾 │ ← 签名保护区域 3
└──────────────────────┘

v2 对 APK Signing Block 以外的所有区域计算摘要并签名，任何修改都会导致验证失败。

v3: Key Rotation

v3 在 v2 的基础上增加了密钥轮换支持，允许使用新证书签名同时保持与旧证书的信任链：

Signing Block 中的证书链:
 旧证书 A → 新证书 B → 当前证书 C

v4: Incremental Install

v4 签名主要用于 ADB 增量安装，生成独立的 .idsig 文件。

5.3 重打包工具和方法

# 1. 反编译
apktool d -r target.apk -o target_dir/ # -r 不解码资源（加速）

# 2. 修改代码/资源
# ... 修改 smali 代码 ...

# 3. 重新打包
apktool b target_dir/ -o modified_unsigned.apk

# 4. 对齐
zipalign -v 4 modified_unsigned.apk modified_aligned.apk

# 5. 签名（支持 v1+v2+v3）
apksigner sign \
 --ks my-release-key.jks \
 --ks-key-alias my-alias \
 --v1-signing-enabled true \
 --v2-signing-enabled true \
 --v3-signing-enabled true \
 modified_aligned.apk

# 6. 验证签名
apksigner verify --verbose --print-certs modified_aligned.apk

签名验证绕过注意事项：

// 部分应用会在运行时校验签名，需要 hook 绕过
Java.perform(function() {
 // 方法 1: Hook PackageManager.getPackageInfo 替换签名
 var PackageManager = Java.use('android.app.ApplicationPackageManager');
 PackageManager.getPackageInfo.overload('java.lang.String', 'int')
 .implementation = function(packageName, flags) {
 // GET_SIGNATURES = 64, GET_SIGNING_CERTIFICATES = 0x08000000
 if ((flags & 64) !== 0 || (flags & 0x08000000) !== 0) {
 console.log('[*] Signature check intercepted for: ' + packageName);
 }
 return this.getPackageInfo(packageName, flags);
 };

 // 方法 2: 直接修改签名数据
 // 在内存中替换为原始签名的 byte array
});

6. ART 运行时演进

ART 运行时的演进直接影响了 DEX dump、方法 Hook 和代码追踪的技术路径。

6.1 演进时间线

Android 4.4 Android 5.0 Android 7.0 Android 12 Android 14+
 │ │ │ │ │
 ▼ ▼ ▼ ▼ ▼
 Dalvik ART (AOT) ART (AOT+JIT) ART Mainline ART + 16KB
 JIT 编译 纯 AOT 编译 混合编译 模块化更新 页面适配
 dex2oat Profile-Guided 独立 APEX
 Compilation

6.2 编译模式演进

Dalvik JIT (Android 4.4 及更早)

DEX 字节码 → Dalvik VM 解释执行 → 热点代码 JIT 编译 → 缓存本地代码

每次启动重新解释
JIT 编译结果不持久化

ART 纯 AOT (Android 5.0-6.0)

安装时: DEX → dex2oat → OAT 文件（完整 AOT 编译）
运行时: 直接执行 OAT 中的本地机器码

安装时间长（全量编译）
占用大量存储空间
运行性能好

ART 混合编译 (Android 7.0+)

安装时: DEX → 仅验证（不编译或仅编译关键路径）
首次运行: 解释执行 + JIT 编译热点代码
 → 生成 Profile 文件（.prof）
设备空闲: Profile-Guided AOT 编译
 → 仅编译 Profile 中标记的热点方法
后续运行: 热点代码 AOT 执行 + 冷代码解释/JIT

# 查看应用的 Profile 文件
adb shell ls -la /data/misc/profiles/cur/0/com.target.app/

# 查看编译状态
adb shell cmd package compile -m speed -f com.target.app # 强制 AOT 编译
adb shell cmd package compile -m verify com.target.app # 仅验证
adb shell cmd package compile --reset com.target.app # 重置编译

Baseline Profiles (Android 12+)

开发者可以在 APK 中打包 Baseline Profile，指导 ART 在安装时预编译关键路径代码：

APK 中的 assets/dexopt/baseline.prof
 → 安装时 ART 读取 Profile
 → AOT 编译 Profile 中标记的方法
 → 首次启动即有优化代码可用

6.3 对逆向工程的影响

DEX Dump 策略

// Frida DEX Dump (适用于所有 ART 版本)
// 原理: 从 ClassLoader 中获取 DexFile 对象，读取其内存中的 DEX 数据
Java.perform(function() {
 Java.enumerateClassLoaders({
 onMatch: function(loader) {
 try {
 var dexFiles = loader.findClass('java.lang.Object')
 .getClassLoader().getClass()
 .getSuperclass().getDeclaredField('pathList');
 dexFiles.setAccessible(true);
 // ... 遍历 DexPathList 获取 DEX 数据
 } catch(e) {}
 },
 onComplete: function() {}
 });
});

方法 Hook 注意事项

// Hook 时需要考虑方法的编译状态
// AOT 编译的方法: entry_point 指向 OAT 中的本地代码
// JIT 编译的方法: entry_point 指向 JIT 代码缓存
// 解释执行的方法: entry_point 指向解释器入口

// Frida 通过替换 ArtMethod 的 entry_point 实现 hook
// 这在所有编译状态下都有效
Java.perform(function() {
 var targetClass = Java.use('com.target.app.Crypto');
 targetClass.encrypt.implementation = function(data) {
 console.log('[*] encrypt called: ' + data);
 var result = this.encrypt(data);
 console.log('[*] encrypt result: ' + result);
 return result;
 };
});

6.4 ART 内部结构关键偏移

不同 Android 版本的 ART 内部结构（如 ArtMethod）偏移可能不同。编写底层 hook 工具时需要适配：

// ArtMethod 结构 (简化版, 偏移因版本而异)
struct ArtMethod {
 uint32_t declaring_class_; // GcRoot<Class>
 uint32_t access_flags_;
 uint32_t dex_code_item_offset_;
 uint32_t dex_method_index_;
 // ...
 void* entry_point_from_quick_compiled_code_; // hook 目标
 void* data_;
};

# 使用 Frida 获取 ArtMethod 偏移信息
# 参考 frida-java-bridge 源码中的 art.js

7. Linker 演进与 SO 加载

Android 的动态链接器 (linker/linker64) 在各版本中经历了重大变化，直接影响 SO 注入和 hook 技术。

7.1 演进时间线

版本	变化	影响
Android 6.0 及更早	全局 namespace，应用可加载任何 SO	注入和 hook 无限制
Android 7.0	Linker namespace 引入	应用不能直接 `dlopen` 系统私有 SO
Android 8.0	Treble vendor namespace	vendor SO 与 system SO 严格隔离
Android 10	BionicLinker 改进	namespace 检查更严格
Android 12	Linkerconfig 动态生成	namespace 配置从静态文件变为动态生成
Android 14+	16KB 页面支持	SO 加载需要适配新的页面对齐

7.2 Linker Namespace 详解

┌─────────────────────────────────────────────────────┐
│ Linker Namespace 架构 │
├─────────────────────────────────────────────────────┤
│ │
│ ┌────────────────┐ ┌────────────────┐ │
│ │ default (系统) │ │ classloader- │ │
│ │ namespace │ │ namespace │ │
│ ├────────────────┤ ├────────────────┤ │
│ │ libandroid.so │ │ app 的 JNI SO │ │
│ │ libc.so │ │ (lib/*.so) │ │
│ │ libm.so │ └───────┬────────┘ │
│ │ liblog.so │ │ │
│ │ ... │←──── 只能 dlopen ──────── │
│ └────────────────┘ 公开的 NDK 库 │
│ │
│ ┌────────────────┐ ┌────────────────┐ │
│ │ vendor │ │ vndk │ │
│ │ namespace │ │ namespace │ │
│ ├────────────────┤ ├────────────────┤ │
│ │ vendor HAL SO │ │ VNDK 共享库 │ │
│ │ /vendor/lib64/ │ │ /apex/vndk/ │ │
│ └────────────────┘ └────────────────┘ │
│ │
└─────────────────────────────────────────────────────┘

7.3 查看 Namespace 配置

# Android 7.0-11: 静态配置文件
adb shell cat /system/etc/ld.config.txt

# Android 12+: 动态生成的配置
adb shell cat /linkerconfig/ld.config.txt

# 查看配置中的 namespace 定义
adb shell cat /linkerconfig/ld.config.txt | grep -E "^\[|^namespace\."

# 典型输出示例:
# [system]
# namespace.default.isolated = true
# namespace.default.search.paths = /system/lib64:/apex/com.android.art/lib64
# namespace.default.permitted.paths = /system/lib64:/apex/...
# namespace.default.asan.search.paths = ...
#
# [vendor]
# namespace.default.isolated = true
# namespace.default.search.paths = /vendor/lib64

7.4 绕过 Namespace 限制

// Frida 中绕过 namespace 限制加载系统私有 SO
// 方法 1: 使用 Process.dlopen (Frida 内部实现绕过)
var handle = Module.load('/system/lib64/libinput.so');
console.log('[*] Loaded: ' + handle);

// 方法 2: 使用 android_dlopen_ext 指定 namespace
var android_dlopen_ext = new NativeFunction(
 Module.findExportByName('libdl.so', 'android_dlopen_ext'),
 'pointer', ['pointer', 'int', 'pointer']
);

// 方法 3: 通过 linker 内部函数直接操作 namespace
// 需要找到 linker 中的 do_dlopen 函数并 hook

7.5 Android 14+ 的 16KB 页面与 SO 加载

# 在 16KB 页面设备上，linker 对段对齐有严格要求
# SO 的 LOAD 段必须按 max(p_align, page_size) 对齐

# 如果 SO 的 p_align = 0x1000 但设备 page_size = 0x4000:
# linker 会尝试 compat 模式加载（可能失败）
# 或者直接拒绝加载

# 使用 NDK r27+ 重新编译 SO 以确保兼容:
# CMakeLists.txt 中添加:
# set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,-z,max-page-size=16384")

8. 实战建议：根据目标 Android 版本制定分析策略

💡 思路一句话: 拿到目标 App 后，第一步看 minSdkVersion 和 targetSdkVersion 确定版本范围 → 根据版本选择对应的工具链和绕过方案 → 版本越高限制越多，但核心逆向方法论不变。

8.1 版本识别与环境评估

在开始分析前，首先收集目标设备的完整信息：

# 1. 基础信息收集
echo "=== Android 版本 ==="
adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.sdk

echo "=== 安全补丁 ==="
adb shell getprop ro.build.version.security_patch

echo "=== 设备架构 ==="
adb shell getprop ro.product.cpu.abi

echo "=== SELinux 状态 ==="
adb shell getenforce

echo "=== Root 状态 ==="
adb shell su -c "id" 2>/dev/null || echo "未 root"

echo "=== 页面大小 ==="
adb shell getconf PAGE_SIZE

echo "=== Magisk 版本 ==="
adb shell su -c "magisk -v" 2>/dev/null || echo "无 Magisk"

echo "=== Kernel 版本 ==="
adb shell uname -r

8.2 分析策略决策流程

 ┌─────────────────┐
 │ 确认 Android 版本 │
 └────────┬────────┘
 │
 ┌──────────────┼──────────────┐
 ▼ ▼ ▼
 Android 5-6 Android 7-9 Android 10+
 │ │ │
 ▼ ▼ ▼
 传统方案即可 需要处理: 需要处理:
 ・直接抓包 ・证书信任 ・XOM 绕过
 ・原版 Xposed ・namespace ・Scoped Storage
 ・简单重打包 ・Hidden API ・16KB 页面 (14+)
 ・v2 签名 ・MTE (15)
 │ │
 ▼ ▼
 工具选择: 工具选择:
 ・Frida ・Frida (最新版)
 ・LSPosed ・LSPosed + Zygisk
 ・Magisk ・Magisk 26+
 ・apktool ・apktool 2.9+

8.3 各版本范围的推荐方案

Android 5.0-6.0 (API 21-23)

# 抓包: 直接安装证书即可
# 安装代理证书
adb push burp-cert.pem /sdcard/
# 设备上: 设置 → 安全 → 从存储安装证书

# Hook: Xposed 或 Frida 均可
# 安装 Xposed Framework (5.0-6.0 最后的稳定版)
# 或使用 Frida
frida -U -f com.target.app -l hook.js

Android 7.0-9.0 (API 24-28)

# 抓包: 需要处理证书信任
# 方案 A: 重打包添加网络安全配置
apktool d target.apk -o target_dir/
# 编辑 network_security_config.xml (信任用户证书)
apktool b target_dir/ -o modified.apk
apksigner sign --ks key.jks modified.apk

# 方案 B: Magisk + MoveCert 模块 (推荐)
# 安装 Magisk → 安装 MagiskTrustUserCerts 模块 → 重启

# Hook: 使用 Frida + LSPosed
# Hidden API 绕过 (Android 9.0):
adb shell settings put global hidden_api_policy 1

Android 10-12 (API 29-32)

# 抓包: Magisk + MoveCert (必须)
# + Frida SSL Pinning Bypass (如果应用使用 Certificate Pinning)

# Hook: Frida (最新版) + Magisk (24+)
# 注意 XOM: Frida 默认通过 ptrace 绕过，通常无需额外处理
# 注意 Scoped Storage: dump 文件使用应用私有目录

# 调试: 使用 Frida 而非 JDWP
# Android 12 的调试限制使 JDWP 更难用
frida -U -f com.target.app -l hook.js --no-pause

Android 13-15 (API 33-35)

# 抓包: Magisk + MoveCert + Frida SSL Bypass (完整方案)

# Hook: Frida 16.x + Magisk 26.x + LSPosed (Zygisk)
# 确认设备页面大小
adb shell getconf PAGE_SIZE

# 如果是 16KB 页面设备，注意:
# - 自定义 SO 注入可能因对齐问题失败
# - 使用 NDK r27+ 编译注入用的 SO

# MTE 检查 (Android 15):
adb shell cat /proc/cpuinfo | grep -i mte
# 如果设备支持 MTE，分析内存时需要 mask 指针 tag

8.4 常见问题排查

问题现象	可能原因	解决方案
Frida 注入后 app 闪退	Frida 检测/SELinux	使用 Frida 检测绕过脚本/关闭 SELinux
抓不到 HTTPS 流量	证书不信任 (7.0+)	MoveCert 模块 + SSL Pinning Bypass
反射调用抛异常	Hidden API 限制 (9.0+)	双重反射绕过或 adb 设置
SO 无法 dlopen	Namespace 限制 (7.0+)	使用 Frida 的 Module.load 或修改 namespace
内存 dump 全零	XOM 保护 (10+)	使用 Frida (ptrace) 读取
SO 加载崩溃	16KB 页面对齐 (14+)	重新编译 SO 适配新对齐
指针地址异常	MTE tagged pointer (15)	mask 掉高字节的 tag bits
app 检测到 root	SafetyNet/Play Integrity	MagiskHide/Shamiko 模块

9. 相关链接

本站相关文档：

Android 运行时 (ART) 深度解析 - ART 运行时内部机制详解
SELinux 安全机制 - SELinux 策略分析与绕过
Android .so 文件详解 (ELF Format) - ELF 格式与 SO 分析基础
DEX 文件格式 - DEX 字节码格式详解
APK 结构详解 - APK 文件组成与解析
Smali 语法参考 - Smali 汇编语法
Binder IPC 机制 - Android 进程间通信机制
ARM 汇编基础 - ARM/ARM64 汇编指令参考
Magisk 与 LSPosed 原理 - Root 框架内部实现
SO 反调试与混淆 - Native 层保护机制分析

外部资源：

Android 安全公告 - 官方安全更新信息
Android 版本发行说明 - 各版本新特性官方文档
Frida 官方文档 - Frida 使用和 API 参考
Magisk 官方仓库 - Magisk 源码与发布
LSPosed 官方仓库 - LSPosed 框架

eBPF 脚本集

overkazaf@gmail.com (+5) — Sat, 27 Dec 2025 00:00:00 +0000

eBPF 脚本集

本文提供可直接使用的 eBPF/bpftrace 脚本，覆盖 Android 逆向工程的常见场景。

系统调用追踪

追踪所有系统调用

#!/usr/bin/env bpftrace
// 文件: syscall_all.bt
// 用途: 统计目标应用的系统调用

tracepoint:raw_syscalls:sys_enter
/comm == "com.target.app"/
{
 @syscalls[args->id] = count();
}

END
{
 printf("\n=== 系统调用统计 ===\n");
 print(@syscalls);
}

追踪文件操作

#!/usr/bin/env bpftrace
// 文件: file_ops.bt
// 用途: 追踪文件打开、读写、关闭

tracepoint:syscalls:sys_enter_openat
/comm == "com.target.app"/
{
 @open_files[str(args->filename)] = count();
 printf("[OPEN] %s flags=%d\n", str(args->filename), args->flags);
}

tracepoint:syscalls:sys_enter_read
/comm == "com.target.app"/
{
 @read_count = count();
 @read_bytes = sum(args->count);
}

tracepoint:syscalls:sys_enter_write
/comm == "com.target.app"/
{
 @write_count = count();
 @write_bytes = sum(args->count);
}

tracepoint:syscalls:sys_enter_close
/comm == "com.target.app"/
{
 @close_count = count();
}

END
{
 printf("\n=== 文件操作统计 ===\n");
 printf("打开的文件:\n");
 print(@open_files);
 printf("\n读取: %d 次, %d 字节\n", @read_count, @read_bytes);
 printf("写入: %d 次, %d 字节\n", @write_count, @write_bytes);
 printf("关闭: %d 次\n", @close_count);
}

追踪敏感文件访问

#!/usr/bin/env bpftrace
// 文件: sensitive_files.bt
// 用途: 监控敏感文件的访问

tracepoint:syscalls:sys_enter_openat
{
 $filename = str(args->filename);

 // 检查敏感路径
 if (strcontains($filename, "/proc/") ||
 strcontains($filename, "/sys/") ||
 strcontains($filename, "/data/data/") ||
 strcontains($filename, "passwd") ||
 strcontains($filename, "shadow") ||
 strcontains($filename, ".key") ||
 strcontains($filename, ".pem")) {

 printf("[SENSITIVE] %s (PID:%d) opened: %s\n",
 comm, pid, $filename);
 }
}

网络追踪

追踪网络连接

#!/usr/bin/env bpftrace
// 文件: network_connect.bt
// 用途: 追踪 TCP/UDP 连接

#include <linux/socket.h>
#include <linux/in.h>

tracepoint:syscalls:sys_enter_connect
/comm == "com.target.app"/
{
 $sa = (struct sockaddr *)args->uservaddr;

 if ($sa->sa_family == AF_INET) {
 $sin = (struct sockaddr_in *)$sa;
 $port = ($sin->sin_port >> 8) | (($sin->sin_port & 0xff) << 8);
 $addr = $sin->sin_addr.s_addr;

 printf("[CONNECT] %d.%d.%d.%d:%d\n",
 $addr & 0xff,
 ($addr >> 8) & 0xff,
 ($addr >> 16) & 0xff,
 ($addr >> 24) & 0xff,
 $port);
 }
}

tracepoint:syscalls:sys_exit_connect
/comm == "com.target.app"/
{
 printf(" -> result: %d\n", args->ret);
}

追踪 DNS 查询

#!/usr/bin/env bpftrace
// 文件: dns_query.bt
// 用途: 追踪 DNS 解析

uprobe:/system/lib64/libc.so:getaddrinfo
/comm == "com.target.app"/
{
 printf("[DNS] Resolving: %s\n", str(arg0));
 @dns_queries[str(arg0)] = count();
}

uretprobe:/system/lib64/libc.so:getaddrinfo
/comm == "com.target.app"/
{
 printf(" -> result: %d\n", retval);
}

追踪 Socket 数据

#!/usr/bin/env bpftrace
// 文件: socket_data.bt
// 用途: 追踪 socket 发送接收的数据

tracepoint:syscalls:sys_enter_sendto
/comm == "com.target.app"/
{
 printf("[SEND] fd=%d len=%d\n", args->fd, args->len);
 @send_bytes = sum(args->len);
}

tracepoint:syscalls:sys_enter_recvfrom
/comm == "com.target.app"/
{
 @recv_pending[tid] = args->size;
}

tracepoint:syscalls:sys_exit_recvfrom
/comm == "com.target.app" && @recv_pending[tid]/
{
 $received = args->ret;
 if ($received > 0) {
 printf("[RECV] %d bytes\n", $received);
 @recv_bytes = sum($received);
 }
 delete(@recv_pending[tid]);
}

END
{
 printf("\n=== 网络统计 ===\n");
 printf("发送: %d 字节\n", @send_bytes);
 printf("接收: %d 字节\n", @recv_bytes);
}

加密函数追踪

OpenSSL 追踪

#!/usr/bin/env bpftrace
// 文件: openssl_trace.bt
// 用途: 追踪 OpenSSL 加密操作

// EVP 加密初始化
uprobe:/system/lib64/libcrypto.so:EVP_EncryptInit_ex
/comm == "com.target.app"/
{
 printf("[CRYPTO] EVP_EncryptInit_ex\n");
 printf(" ctx: %p, cipher: %p\n", arg0, arg1);
 @encrypt_init = count();
}

// EVP 加密更新
uprobe:/system/lib64/libcrypto.so:EVP_EncryptUpdate
/comm == "com.target.app"/
{
 printf("[CRYPTO] EVP_EncryptUpdate len=%d\n", arg3);
 @encrypt_bytes = sum(arg3);
}

// EVP 解密初始化
uprobe:/system/lib64/libcrypto.so:EVP_DecryptInit_ex
/comm == "com.target.app"/
{
 printf("[CRYPTO] EVP_DecryptInit_ex\n");
 @decrypt_init = count();
}

// EVP 解密更新
uprobe:/system/lib64/libcrypto.so:EVP_DecryptUpdate
/comm == "com.target.app"/
{
 printf("[CRYPTO] EVP_DecryptUpdate len=%d\n", arg3);
 @decrypt_bytes = sum(arg3);
}

// HMAC
uprobe:/system/lib64/libcrypto.so:HMAC
/comm == "com.target.app"/
{
 printf("[CRYPTO] HMAC data_len=%d\n", arg3);
 @hmac_count = count();
}

// SHA256
uprobe:/system/lib64/libcrypto.so:SHA256
/comm == "com.target.app"/
{
 printf("[CRYPTO] SHA256 len=%d\n", arg1);
 @sha256_count = count();
}

END
{
 printf("\n=== 加密统计 ===\n");
 printf("加密初始化: %d 次, 处理: %d 字节\n", @encrypt_init, @encrypt_bytes);
 printf("解密初始化: %d 次, 处理: %d 字节\n", @decrypt_init, @decrypt_bytes);
 printf("HMAC: %d 次\n", @hmac_count);
 printf("SHA256: %d 次\n", @sha256_count);
}

AES 密钥捕获

#!/usr/bin/env bpftrace
// 文件: aes_key_capture.bt
// 用途: 捕获 AES 密钥 (仅用于安全研究)

uprobe:/system/lib64/libcrypto.so:AES_set_encrypt_key
/comm == "com.target.app"/
{
 printf("[AES] Setting encrypt key, bits=%d\n", arg1);

 // 打印密钥的前几个字节 (仅示例)
 $key = (uint8 *)arg0;
 printf(" Key prefix: %02x %02x %02x %02x ...\n",
 $key[0], $key[1], $key[2], $key[3]);
}

uprobe:/system/lib64/libcrypto.so:AES_set_decrypt_key
/comm == "com.target.app"/
{
 printf("[AES] Setting decrypt key, bits=%d\n", arg1);
}

反调试检测

检测反调试行为

#!/usr/bin/env bpftrace
// 文件: anti_debug_detect.bt
// 用途: 检测应用的反调试行为

// ptrace 检测
tracepoint:syscalls:sys_enter_ptrace
{
 printf("[ANTI-DEBUG] ptrace by %s (PID:%d)\n", comm, pid);
 printf(" request: %d, pid: %d\n", args->request, args->pid);

 if (args->request == 0) { // PTRACE_TRACEME
 printf(" !!! PTRACE_TRACEME detected !!!\n");
 }
}

// /proc/self/status 读取 (检测 TracerPid)
tracepoint:syscalls:sys_enter_openat
/strcontains(str(args->filename), "/proc/") &&
 strcontains(str(args->filename), "/status")/
{
 printf("[ANTI-DEBUG] %s reading %s\n", comm, str(args->filename));
}

// /proc/self/maps 读取 (检测 Frida)
tracepoint:syscalls:sys_enter_openat
/strcontains(str(args->filename), "/proc/") &&
 strcontains(str(args->filename), "/maps")/
{
 printf("[ANTI-DEBUG] %s reading %s\n", comm, str(args->filename));
}

// inotify 监控 (检测文件修改)
tracepoint:syscalls:sys_enter_inotify_add_watch
{
 printf("[ANTI-DEBUG] %s adding inotify watch: %s\n",
 comm, str(args->pathname));
}

// prctl 调用 (可能用于 PR_SET_DUMPABLE)
tracepoint:syscalls:sys_enter_prctl
{
 printf("[ANTI-DEBUG] prctl by %s option=%d\n", comm, args->option);
}

Frida 检测监控

#!/usr/bin/env bpftrace
// 文件: frida_detect.bt
// 用途: 监控应用检测 Frida 的行为

// 检测 Frida 端口扫描
tracepoint:syscalls:sys_enter_connect
/comm == "com.target.app"/
{
 $sa = (struct sockaddr *)args->uservaddr;
 if ($sa->sa_family == 2) {
 $sin = (struct sockaddr_in *)$sa;
 $port = ($sin->sin_port >> 8) | (($sin->sin_port & 0xff) << 8);

 // Frida 默认端口
 if ($port == 27042 || $port == 27043) {
 printf("[FRIDA-DETECT] Connecting to Frida port %d\n", $port);
 }
 }
}

// 检测 Frida 相关文件访问
tracepoint:syscalls:sys_enter_openat
/comm == "com.target.app"/
{
 $f = str(args->filename);
 if (strcontains($f, "frida") ||
 strcontains($f, "gadget") ||
 strcontains($f, "agent")) {
 printf("[FRIDA-DETECT] Checking file: %s\n", $f);
 }
}

// 检测 /proc/self/maps 中的 Frida
kprobe:proc_pid_maps
{
 printf("[FRIDA-DETECT] %s reading /proc/maps\n", comm);
}

进程和线程

进程创建追踪

#!/usr/bin/env bpftrace
// 文件: process_trace.bt
// 用途: 追踪进程创建和执行

tracepoint:syscalls:sys_enter_clone
/comm == "com.target.app"/
{
 printf("[CLONE] %s creating child, flags=%x\n", comm, args->clone_flags);
}

tracepoint:syscalls:sys_enter_execve
{
 printf("[EXEC] %s -> %s\n", comm, str(args->filename));
}

tracepoint:sched:sched_process_fork
/comm == "com.target.app"/
{
 printf("[FORK] %s (PID:%d) forked child PID:%d\n",
 comm, args->parent_pid, args->child_pid);
}

tracepoint:sched:sched_process_exit
/comm == "com.target.app"/
{
 printf("[EXIT] %s (PID:%d)\n", comm, pid);
}

线程活动监控

#!/usr/bin/env bpftrace
// 文件: thread_trace.bt
// 用途: 追踪线程创建和调度

tracepoint:syscalls:sys_enter_clone
/comm == "com.target.app" && (args->clone_flags & 0x10000)/ // CLONE_THREAD
{
 printf("[THREAD] Creating new thread\n");
 @thread_create = count();
}

tracepoint:sched:sched_switch
/prev_comm == "com.target.app" || next_comm == "com.target.app"/
{
 printf("[SWITCH] %s -> %s\n", prev_comm, next_comm);
}

// 追踪互斥锁
uprobe:/apex/com.android.runtime/lib64/bionic/libc.so:pthread_mutex_lock
/comm == "com.target.app"/
{
 @mutex_lock[arg0] = nsecs;
}

uretprobe:/apex/com.android.runtime/lib64/bionic/libc.so:pthread_mutex_lock
/comm == "com.target.app" && @mutex_lock[arg0]/
{
 $wait = nsecs - @mutex_lock[arg0];
 @mutex_wait = hist($wait);
 delete(@mutex_lock[arg0]);
}

END
{
 printf("\n=== 线程统计 ===\n");
 printf("线程创建: %d\n", @thread_create);
 printf("互斥锁等待时间分布:\n");
 print(@mutex_wait);
}

JNI 和 ART

JNI 调用追踪

#!/usr/bin/env bpftrace
// 文件: jni_trace.bt
// 用途: 追踪 JNI 函数调用

// FindClass
uprobe:/apex/com.android.art/lib64/libart.so:*FindClass*
/comm == "com.target.app"/
{
 printf("[JNI] FindClass\n");
 @jni_findclass = count();
}

// GetMethodID
uprobe:/apex/com.android.art/lib64/libart.so:*GetMethodID*
/comm == "com.target.app"/
{
 printf("[JNI] GetMethodID\n");
 @jni_getmethod = count();
}

// CallObjectMethod
uprobe:/apex/com.android.art/lib64/libart.so:*CallObjectMethod*
/comm == "com.target.app"/
{
 printf("[JNI] CallObjectMethod\n");
 @jni_call = count();
}

// RegisterNatives
uprobe:/apex/com.android.art/lib64/libart.so:*RegisterNatives*
/comm == "com.target.app"/
{
 printf("[JNI] RegisterNatives\n");
 @jni_register = count();
}

END
{
 printf("\n=== JNI 统计 ===\n");
 printf("FindClass: %d\n", @jni_findclass);
 printf("GetMethodID: %d\n", @jni_getmethod);
 printf("CallObjectMethod: %d\n", @jni_call);
 printf("RegisterNatives: %d\n", @jni_register);
}

ART 方法编译追踪

#!/usr/bin/env bpftrace
// 文件: art_compile.bt
// 用途: 追踪 ART JIT 编译

uprobe:/apex/com.android.art/lib64/libart.so:*JitCompile*
/comm == "com.target.app"/
{
 printf("[JIT] Method compiled\n");
 @jit_compile = count();
}

uprobe:/apex/com.android.art/lib64/libart.so:*CompileMethod*
/comm == "com.target.app"/
{
 @compile_method = count();
}

END
{
 printf("\n=== ART JIT 统计 ===\n");
 printf("JIT 编译: %d\n", @jit_compile);
 printf("方法编译: %d\n", @compile_method);
}

内存追踪

内存分配追踪

#!/usr/bin/env bpftrace
// 文件: memory_alloc.bt
// 用途: 追踪内存分配

uprobe:/apex/com.android.runtime/lib64/bionic/libc.so:malloc
/comm == "com.target.app"/
{
 @malloc_size = hist(arg0);
 @malloc_total = sum(arg0);
 @malloc_count = count();
}

uretprobe:/apex/com.android.runtime/lib64/bionic/libc.so:malloc
/comm == "com.target.app"/
{
 @malloc_ptrs[retval] = nsecs;
}

uprobe:/apex/com.android.runtime/lib64/bionic/libc.so:free
/comm == "com.target.app" && @malloc_ptrs[arg0]/
{
 $lifetime = nsecs - @malloc_ptrs[arg0];
 @mem_lifetime = hist($lifetime);
 delete(@malloc_ptrs[arg0]);
 @free_count = count();
}

uprobe:/apex/com.android.runtime/lib64/bionic/libc.so:realloc
/comm == "com.target.app"/
{
 printf("[REALLOC] ptr=%p new_size=%zu\n", arg0, arg1);
 @realloc_count = count();
}

END
{
 printf("\n=== 内存分配统计 ===\n");
 printf("malloc 次数: %d, 总量: %d 字节\n", @malloc_count, @malloc_total);
 printf("free 次数: %d\n", @free_count);
 printf("realloc 次数: %d\n", @realloc_count);
 printf("\nmalloc 大小分布:\n");
 print(@malloc_size);
 printf("\n内存生命周期分布 (ns):\n");
 print(@mem_lifetime);
}

mmap 追踪

#!/usr/bin/env bpftrace
// 文件: mmap_trace.bt
// 用途: 追踪内存映射

tracepoint:syscalls:sys_enter_mmap
/comm == "com.target.app"/
{
 printf("[MMAP] addr=%p len=%zu prot=%x flags=%x fd=%d offset=%lu\n",
 args->addr, args->len, args->prot, args->flags,
 args->fd, args->off);

 @mmap_total = sum(args->len);
 @mmap_count = count();

 // 记录可执行映射
 if (args->prot & 4) { // PROT_EXEC
 @exec_mmap = count();
 printf(" !!! EXECUTABLE MAPPING !!!\n");
 }
}

tracepoint:syscalls:sys_enter_munmap
/comm == "com.target.app"/
{
 printf("[MUNMAP] addr=%p len=%zu\n", args->addr, args->len);
 @munmap_count = count();
}

tracepoint:syscalls:sys_enter_mprotect
/comm == "com.target.app"/
{
 printf("[MPROTECT] addr=%p len=%zu prot=%x\n",
 args->start, args->len, args->prot);

 if (args->prot & 4) { // PROT_EXEC
 printf(" !!! MAKING EXECUTABLE !!!\n");
 }
}

END
{
 printf("\n=== mmap 统计 ===\n");
 printf("mmap: %d 次, 总量: %d 字节\n", @mmap_count, @mmap_total);
 printf("munmap: %d 次\n", @munmap_count);
 printf("可执行映射: %d 次\n", @exec_mmap);
}

性能分析

函数耗时统计

#!/usr/bin/env bpftrace
// 文件: func_latency.bt
// 用途: 统计关键函数耗时
// 使用: 修改目标函数路径

uprobe:/data/app/com.target.app-*/lib/arm64/libnative.so:target_function
{
 @start[tid] = nsecs;
}

uretprobe:/data/app/com.target.app-*/lib/arm64/libnative.so:target_function
/@start[tid]/
{
 $latency = nsecs - @start[tid];
 @latency_ns = hist($latency);
 @total_time = sum($latency);
 @call_count = count();
 delete(@start[tid]);
}

END
{
 printf("\n=== 函数耗时统计 ===\n");
 printf("调用次数: %d\n", @call_count);
 printf("总耗时: %d ns\n", @total_time);
 printf("耗时分布:\n");
 print(@latency_ns);
}

CPU 采样

#!/usr/bin/env bpftrace
// 文件: cpu_profile.bt
// 用途: CPU 热点采样

profile:hz:99
/comm == "com.target.app"/
{
 @cpu_samples[ustack] = count();
}

END
{
 printf("\n=== CPU 热点 (Top 10) ===\n");
 print(@cpu_samples, 10);
}

实用工具函数

进程过滤模板

#!/usr/bin/env bpftrace
// 文件: filter_template.bt
// 用途: 进程过滤模板

// 方法1: 按进程名过滤
/comm == "com.target.app"/

// 方法2: 按 PID 过滤
/pid == $1/ // bpftrace script.bt 12345

// 方法3: 按 UID 过滤
/uid == 10123/

// 方法4: 按 cgroup 过滤 (容器)
/cgroup == "docker/xxx"/

// 方法5: 排除特定进程
/comm != "logd" && comm != "servicemanager"/

输出格式化

#!/usr/bin/env bpftrace
// 文件: output_format.bt
// 用途: 输出格式化示例

BEGIN
{
 printf("%-20s %-10s %-10s %s\n",
 "TIME", "PID", "COMM", "ACTION");
 printf("%-20s %-10s %-10s %s\n",
 "----", "---", "----", "------");
}

tracepoint:syscalls:sys_enter_openat
/comm == "com.target.app"/
{
 $ts = nsecs / 1000000000;
 printf("%-20llu %-10d %-10s OPEN: %s\n",
 $ts, pid, comm, str(args->filename));
}

运行说明

基本用法

# 运行脚本
adb shell /data/local/tmp/bpftrace /path/to/script.bt

# 带参数运行
adb shell /data/local/tmp/bpftrace /path/to/script.bt 12345

# 单行命令
adb shell /data/local/tmp/bpftrace -e 'tracepoint:syscalls:sys_enter_* { @[probe] = count(); }'

# 输出到文件
adb shell /data/local/tmp/bpftrace /path/to/script.bt > output.txt 2>&1

权限设置

# 确保 root 权限
adb root

# 禁用 SELinux (临时)
adb shell setenforce 0

# 检查 bpf 文件系统
adb shell mount | grep bpf

常见问题

“Failed to attach”: 检查函数名是否正确，使用 nm 或 readelf 确认
“Permission denied”: 需要 root 权限和 SELinux 设置
“不支持的内核版本”: 需要 4.14+ 内核

参考资料

eBPF 使用指南

overkazaf@gmail.com (+5) — Sat, 27 Dec 2025 00:00:00 +0000

eBPF 使用指南

eBPF (extended Berkeley Packet Filter) 是 Linux 内核中的一项革命性技术，允许在内核空间运行沙盒程序而无需修改内核代码。在 Android 逆向工程中，eBPF 提供了比 Frida 更底层、更隐蔽的追踪能力。

为什么选择 eBPF

与其他工具对比

特性	eBPF	Frida	Xposed
检测难度	极难	中等	容易
内核级追踪	原生支持	不支持	不支持
性能开销	极低	中等	中等
系统调用追踪	原生支持	需要额外实现	不支持
网络包捕获	原生支持	不支持	不支持
Root 需求	是	是	是
Android 支持	4.14+ 内核	广泛	广泛

eBPF 的优势

隐蔽性: 运行在内核空间，应用层检测极其困难
性能: JIT 编译，接近原生性能
安全性: 内核验证器确保程序安全
全面性: 可追踪系统调用、网络、文件系统等各个层面

环境准备

检查内核支持

# 检查内核版本（需要 4.14+）
adb shell uname -r

# 检查 eBPF 支持
adb shell ls /sys/fs/bpf/

# 检查 CONFIG_BPF 相关配置
adb shell zcat /proc/config.gz | grep -i bpf

需要确认以下内核配置启用:

CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
CONFIG_BPF_JIT=y
CONFIG_HAVE_EBPF_JIT=y
CONFIG_BPF_EVENTS=y

安装 bpftrace (推荐)

bpftrace 是 eBPF 的高级追踪语言，类似于 awk 和 DTrace。

在 Android 上安装:

# 下载预编译的 bpftrace (需要 root)
# https://github.com/aspect-build/bpftrace-android

# 推送到设备
adb push bpftrace /data/local/tmp/
adb shell chmod +x /data/local/tmp/bpftrace

# 测试运行
adb shell /data/local/tmp/bpftrace -e 'BEGIN { printf("eBPF works!\n"); }'

安装 BCC 工具集

BCC (BPF Compiler Collection) 提供了丰富的预置追踪工具。

# 交叉编译 BCC for Android
# 或使用预编译版本

# 常用工具
# - opensnoop: 追踪文件打开
# - execsnoop: 追踪进程执行
# - tcpconnect: 追踪 TCP 连接
# - trace: 通用函数追踪

快速入门

Hello World

# 最简单的 bpftrace 脚本
adb shell /data/local/tmp/bpftrace -e '
BEGIN {
 printf("开始追踪...\n");
}

END {
 printf("追踪结束\n");
}'

追踪系统调用

# 追踪特定应用的所有系统调用
adb shell /data/local/tmp/bpftrace -e '
tracepoint:raw_syscalls:sys_enter
/comm == "com.target.app"/
{
 @syscalls[args->id] = count();
}

END {
 print(@syscalls);
}'

追踪文件操作

# 追踪文件打开操作
adb shell /data/local/tmp/bpftrace -e '
tracepoint:syscalls:sys_enter_openat
/comm == "com.target.app"/
{
 printf("%s opened: %s\n", comm, str(args->filename));
}'

核心概念

程序类型

eBPF 支持多种程序类型:

类型	用途	Android 逆向场景
kprobe/kretprobe	内核函数追踪	追踪内核行为
uprobe/uretprobe	用户态函数追踪	追踪应用函数
tracepoint	内核静态追踪点	系统调用追踪
socket_filter	网络包过滤	网络流量分析
xdp	高性能网络处理	网络数据包分析

Maps 数据结构

eBPF Maps 用于在内核和用户空间之间共享数据:

// 常用 Map 类型
BPF_HASH(counts, u32); // 哈希表
BPF_ARRAY(data, u64, 256); // 数组
BPF_PERF_OUTPUT(events); // 性能事件输出
BPF_STACK_TRACE(stacks, 128); // 调用栈追踪

辅助函数

// 常用 eBPF 辅助函数
bpf_get_current_pid_tgid() // 获取进程/线程 ID
bpf_get_current_comm() // 获取进程名
bpf_probe_read() // 安全读取内存
bpf_ktime_get_ns() // 获取时间戳
bpf_trace_printk() // 调试输出

实战场景

💡 思路一句话: eBPF 的核心优势是「内核级无感知监控」— 在内核中插入探针，应用层完全无法检测到，适合对抗强反调试/反 hook 的场景。

场景1: 追踪加密函数调用

追踪应用调用的 OpenSSL 加密函数:

adb shell /data/local/tmp/bpftrace -e '
uprobe:/system/lib64/libcrypto.so:EVP_EncryptInit_ex
/comm == "com.target.app"/
{
 printf("[%d] EVP_EncryptInit_ex called\n", pid);
 printf(" ctx: %p\n", arg0);
 printf(" type: %p\n", arg1);
}

uprobe:/system/lib64/libcrypto.so:EVP_EncryptUpdate
/comm == "com.target.app"/
{
 printf("[%d] EVP_EncryptUpdate\n", pid);
 printf(" input len: %d\n", arg3);
}
'

场景2: 监控网络连接

adb shell /data/local/tmp/bpftrace -e '
tracepoint:syscalls:sys_enter_connect
/comm == "com.target.app"/
{
 $sa = (struct sockaddr *)args->uservaddr;
 if ($sa->sa_family == 2) { // AF_INET
 $sin = (struct sockaddr_in *)$sa;
 printf("Connect to %s:%d\n",
 ntop(AF_INET, $sin->sin_addr.s_addr),
 ntohs($sin->sin_port));
 }
}'

场景3: 文件访问监控

adb shell /data/local/tmp/bpftrace -e '
tracepoint:syscalls:sys_enter_openat
/comm == "com.target.app"/
{
 @files[str(args->filename)] = count();
}

tracepoint:syscalls:sys_enter_read
/comm == "com.target.app"/
{
 @read_bytes = sum(args->count);
}

tracepoint:syscalls:sys_enter_write
/comm == "com.target.app"/
{
 @write_bytes = sum(args->count);
}

END {
 printf("\n=== 文件访问统计 ===\n");
 print(@files);
 printf("\n读取字节: %d\n", @read_bytes);
 printf("写入字节: %d\n", @write_bytes);
}'

场景4: JNI 调用追踪

# 追踪 JNI 函数调用
adb shell /data/local/tmp/bpftrace -e '
uprobe:/system/lib64/libart.so:*JNI*
/comm == "com.target.app"/
{
 printf("[JNI] %s\n", probe);
}'

场景5: 检测反调试行为

# 监控常见的反调试系统调用
adb shell /data/local/tmp/bpftrace -e '
tracepoint:syscalls:sys_enter_ptrace
{
 printf("[Anti-Debug] ptrace called by %s (PID: %d)\n", comm, pid);
 printf(" request: %d\n", args->request);
}

tracepoint:syscalls:sys_enter_prctl
{
 printf("[Anti-Debug] prctl called by %s\n", comm);
 printf(" option: %d\n", args->option);
}

kprobe:proc_pid_status
{
 printf("[Anti-Debug] /proc/pid/status read by %s\n", comm);
}'

高级技巧

1. 条件过滤

# 只追踪特定 UID 的进程
adb shell /data/local/tmp/bpftrace -e '
tracepoint:syscalls:sys_enter_*
/uid == 10123/ // 目标应用的 UID
{
 @syscalls[probe] = count();
}'

2. 调用栈追踪

# 获取完整调用栈
adb shell /data/local/tmp/bpftrace -e '
uprobe:/data/app/com.target.app-*/lib/arm64/libnative.so:suspicious_function
{
 printf("Function called!\n");
 printf("User stack:\n%s\n", ustack);
 printf("Kernel stack:\n%s\n", kstack);
}'

3. 时间统计

# 统计函数执行时间
adb shell /data/local/tmp/bpftrace -e '
uprobe:/data/app/com.target.app-*/lib/arm64/libnative.so:target_function
{
 @start[tid] = nsecs;
}

uretprobe:/data/app/com.target.app-*/lib/arm64/libnative.so:target_function
/@start[tid]/
{
 $duration = nsecs - @start[tid];
 @time = hist($duration);
 delete(@start[tid]);
}'

4. 内存访问追踪

# 追踪内存分配
adb shell /data/local/tmp/bpftrace -e '
uprobe:/apex/com.android.runtime/lib64/bionic/libc.so:malloc
/comm == "com.target.app"/
{
 @malloc_size = hist(arg0);
 @total_alloc = sum(arg0);
}

uretprobe:/apex/com.android.runtime/lib64/bionic/libc.so:malloc
/comm == "com.target.app"/
{
 printf("malloc returned: %p\n", retval);
}'

BCC Python 脚本

对于更复杂的追踪需求，可以使用 BCC Python API:

#!/usr/bin/env python3
from bcc import BPF

# eBPF 程序
prog = """
#include <uapi/linux/ptrace.h>
#include <linux/sched.h>

struct data_t {
 u32 pid;
 u64 ts;
 char comm[TASK_COMM_LEN];
 char filename[256];
};

BPF_PERF_OUTPUT(events);

int trace_openat(struct pt_regs *ctx, int dfd, const char __user *filename) {
 struct data_t data = {};

 data.pid = bpf_get_current_pid_tgid() >> 32;
 data.ts = bpf_ktime_get_ns();
 bpf_get_current_comm(&data.comm, sizeof(data.comm));
 bpf_probe_read_user_str(&data.filename, sizeof(data.filename), filename);

 events.perf_submit(ctx, &data, sizeof(data));
 return 0;
}
"""

# 加载 BPF 程序
b = BPF(text=prog)
b.attach_kprobe(event="do_sys_openat2", fn_name="trace_openat")

# 处理事件
def print_event(cpu, data, size):
 event = b["events"].event(data)
 print(f"[{event.pid}] {event.comm.decode()}: {event.filename.decode()}")

b["events"].open_perf_buffer(print_event)

print("Tracing file opens... Ctrl+C to exit")
while True:
 try:
 b.perf_buffer_poll()
 except KeyboardInterrupt:
 break

常见问题

Q: Android 设备不支持 eBPF？

检查内核版本和配置:

# 内核版本需要 >= 4.14
adb shell uname -r

# 部分厂商可能禁用了 BPF
adb shell zcat /proc/config.gz | grep BPF

解决方案:

使用自定义内核 (如 LineageOS)
使用 Android 模拟器 (支持更好)
使用特定的 Root 方案

Q: bpftrace 报错 “Failed to attach”？

# 检查 SELinux 状态
adb shell getenforce

# 临时禁用 (需要 root)
adb shell setenforce 0

# 检查内核符号
adb shell cat /proc/kallsyms | head

Q: 如何追踪特定应用？

# 方法1: 使用进程名
/comm == "com.target.app"/

# 方法2: 使用 PID
/pid == 12345/

# 方法3: 使用 UID
/uid == 10123/

# 获取应用 UID
adb shell dumpsys package com.target.app | grep userId

工具推荐

1. bpftrace

官网: https://github.com/iovisor/bpftrace
Android 版: https://github.com/aspect-build/bpftrace-android

2. BCC

官网: https://github.com/iovisor/bcc
文档: https://github.com/iovisor/bcc/blob/master/docs/reference_guide.md

3. libbpf

官网: https://github.com/libbpf/libbpf
CO-RE (一次编译，到处运行)

4. eCapture

官网: https://github.com/gojue/ecapture
无需 CA 证书的 HTTPS 抓包工具

5. Tracee

官网: https://github.com/aquasecurity/tracee
安全事件追踪工具

参考资料

eBPF.io - eBPF 官方网站
Linux Kernel BPF Documentation
BPF Performance Tools - Brendan Gregg 的经典书籍
Android eBPF - Android 官方 eBPF 文档

eBPF Android 逆向实战

overkazaf@gmail.com (+5) — Sat, 27 Dec 2025 00:00:00 +0000

eBPF Android 逆向实战

本文通过实战案例展示如何使用 eBPF 进行 Android 应用逆向分析。eBPF 的优势在于运行在内核层，极难被应用检测到。

实战环境准备

设备要求

# 1. 检查内核版本 (需要 >= 4.14)
adb shell uname -r
# 期望输出: 4.14.x 或更高

# 2. 检查 eBPF 支持
adb shell ls /sys/fs/bpf/
# 应该存在此目录

# 3. 检查必要的内核配置
adb shell zcat /proc/config.gz | grep -E "CONFIG_BPF|CONFIG_KPROBE"

工具安装

# 下载 bpftrace for Android
# 选项1: 使用预编译版本
wget https://github.com/aspect-build/bpftrace-android/releases/latest/bpftrace-arm64

# 选项2: 自行编译 (需要 NDK)

# 推送到设备
adb push bpftrace-arm64 /data/local/tmp/bpftrace
adb shell chmod +x /data/local/tmp/bpftrace

# 验证安装
adb shell /data/local/tmp/bpftrace --version

SELinux 配置

# 获取 root 权限
adb root

# 临时禁用 SELinux (必需)
adb shell setenforce 0

# 验证
adb shell getenforce
# 输出: Permissive

实战案例 1: 隐蔽追踪加密通信

💡 思路一句话: 用 eBPF 在内核层拦截 send/recv 系统调用，在加密前/解密后捕获明文数据，完全绕过应用层的反 hook 检测。

背景

目标应用使用自定义加密，需要在不被检测的情况下捕获明文数据。

步骤 1: 识别加密库

# 列出应用加载的共享库
adb shell cat /proc/$(pidof com.target.app)/maps | grep "\.so"

# 常见加密库位置
# /system/lib64/libcrypto.so (OpenSSL)
# /system/lib64/libssl.so (SSL/TLS)
# /data/app/xxx/lib/arm64/lib*.so (应用私有库)

步骤 2: 追踪 OpenSSL 加密

#!/usr/bin/env bpftrace
// 文件: ssl_intercept.bt

// 追踪 SSL_write - 捕获发送的明文
uprobe:/system/lib64/libssl.so:SSL_write
/comm == "com.target.app"/
{
 @ssl_write_buf[tid] = arg1;
 @ssl_write_len[tid] = arg2;
 printf("\n[SSL_write] len=%d\n", arg2);
}

uretprobe:/system/lib64/libssl.so:SSL_write
/comm == "com.target.app" && @ssl_write_buf[tid]/
{
 $buf = @ssl_write_buf[tid];
 $len = @ssl_write_len[tid];

 // 打印前64字节
 $print_len = $len < 64 ? $len : 64;
 printf("Data (first %d bytes):\n", $print_len);

 // 使用循环打印数据
 $i = 0;
 while ($i < $print_len && $i < 64) {
 $byte = *(uint8 *)($buf + $i);
 printf("%02x ", $byte);
 if (($i + 1) % 16 == 0) {
 printf("\n");
 }
 $i++;
 }
 printf("\n");

 delete(@ssl_write_buf[tid]);
 delete(@ssl_write_len[tid]);
}

// 追踪 SSL_read - 捕获接收的明文
uprobe:/system/lib64/libssl.so:SSL_read
/comm == "com.target.app"/
{
 @ssl_read_buf[tid] = arg1;
}

uretprobe:/system/lib64/libssl.so:SSL_read
/comm == "com.target.app" && retval > 0/
{
 $buf = @ssl_read_buf[tid];
 $len = retval;

 printf("\n[SSL_read] len=%d\n", $len);

 $print_len = $len < 64 ? $len : 64;
 printf("Data (first %d bytes):\n", $print_len);

 $i = 0;
 while ($i < $print_len && $i < 64) {
 $byte = *(uint8 *)($buf + $i);
 printf("%02x ", $byte);
 if (($i + 1) % 16 == 0) {
 printf("\n");
 }
 $i++;
 }
 printf("\n");

 delete(@ssl_read_buf[tid]);
}

步骤 3: 捕获加密密钥

#!/usr/bin/env bpftrace
// 文件: crypto_key_capture.bt

// AES 密钥设置
uprobe:/system/lib64/libcrypto.so:AES_set_encrypt_key
/comm == "com.target.app"/
{
 $key = (uint8 *)arg0;
 $bits = arg1;

 printf("\n[AES_set_encrypt_key] bits=%d\n", $bits);
 printf("Key: ");

 $len = $bits / 8;
 $i = 0;
 while ($i < $len) {
 printf("%02x", $key[$i]);
 $i++;
 }
 printf("\n");
}

// EVP 加密初始化 - 获取 IV
uprobe:/system/lib64/libcrypto.so:EVP_EncryptInit_ex
/comm == "com.target.app"/
{
 printf("\n[EVP_EncryptInit_ex]\n");
 printf(" ctx=%p cipher=%p key=%p iv=%p\n", arg0, arg1, arg3, arg4);

 if (arg4 != 0) {
 $iv = (uint8 *)arg4;
 printf(" IV: ");
 $i = 0;
 while ($i < 16) {
 printf("%02x", $iv[$i]);
 $i++;
 }
 printf("\n");
 }
}

实战案例 2: 绕过反调试检测

💡 思路一句话: 用 eBPF hook ptrace/open 等系统调用，在内核层篡改返回值，让反调试检测函数永远得到"安全"的结果。

背景

目标应用有多重反调试保护，需要在不触发检测的情况下分析。

检测点分析

#!/usr/bin/env bpftrace
// 文件: anti_debug_analysis.bt
// 首先运行此脚本，观察应用的反调试行为

// 1. ptrace 检测
tracepoint:syscalls:sys_enter_ptrace
{
 printf("[PTRACE] %s (PID:%d) request=%d target_pid=%d\n",
 comm, pid, args->request, args->pid);

 @ptrace_requests[args->request] = count();
}

// 2. /proc 文件系统访问
tracepoint:syscalls:sys_enter_openat
/strcontains(str(args->filename), "/proc/")/
{
 $f = str(args->filename);

 if (strcontains($f, "status") ||
 strcontains($f, "stat") ||
 strcontains($f, "maps") ||
 strcontains($f, "cmdline")) {
 printf("[PROC] %s opening %s\n", comm, $f);
 @proc_access[$f] = count();
 }
}

// 3. 时间检测 (调试会导致执行变慢)
tracepoint:syscalls:sys_enter_clock_gettime
/comm == "com.target.app"/
{
 @clock_gettime = count();
}

tracepoint:syscalls:sys_enter_gettimeofday
/comm == "com.target.app"/
{
 @gettimeofday = count();
}

// 4. 信号处理
tracepoint:signal:signal_deliver
/comm == "com.target.app"/
{
 printf("[SIGNAL] %s received signal %d\n", comm, args->sig);
}

END
{
 printf("\n=== 反调试行为统计 ===\n");
 printf("\nptrace 请求:\n");
 print(@ptrace_requests);
 printf("\n/proc 访问:\n");
 print(@proc_access);
 printf("\n时间获取: clock_gettime=%d, gettimeofday=%d\n",
 @clock_gettime, @gettimeofday);
}

隐蔽监控方案

使用 eBPF 监控而非 Frida，避免被检测:

#!/usr/bin/env bpftrace
// 文件: stealth_monitor.bt
// eBPF 运行在内核空间，应用层无法检测

// 追踪所有关键行为，但不干预
tracepoint:syscalls:sys_enter_openat
/comm == "com.target.app"/
{
 @files[str(args->filename)] = count();
}

tracepoint:syscalls:sys_enter_connect
/comm == "com.target.app"/
{
 @connects = count();
}

tracepoint:syscalls:sys_enter_sendto
/comm == "com.target.app"/
{
 @send_bytes = sum(args->len);
}

tracepoint:syscalls:sys_enter_recvfrom
/comm == "com.target.app"/
{
 @recv_attempts = count();
}

// JNI 调用追踪
uprobe:/apex/com.android.art/lib64/libart.so:*RegisterNatives*
/comm == "com.target.app"/
{
 printf("[JNI] RegisterNatives called\n");
 @jni_register = count();
}

interval:s:10
{
 printf("\n--- 10秒统计 ---\n");
 printf("文件访问: ");
 print(@files);
 printf("网络连接: %d, 发送: %d 字节\n", @connects, @send_bytes);
 clear(@files);
 clear(@connects);
 clear(@send_bytes);
 clear(@recv_attempts);
}

实战案例 3: 分析应用启动流程

💡 思路一句话: 用 eBPF 追踪 fork/exec/mmap/open 系统调用序列，还原应用从 Zygote fork 到加载 DEX/SO 的完整启动链路。

追踪启动过程

#!/usr/bin/env bpftrace
// 文件: app_startup.bt
// 用途: 分析应用从启动到完成初始化的全过程

BEGIN
{
 printf("等待应用启动...\n");
 printf("请执行: adb shell am start com.target.app/.MainActivity\n\n");
}

// Zygote fork 新进程
tracepoint:sched:sched_process_fork
/comm == "zygote64" || comm == "zygote"/
{
 printf("[%llu] FORK: %s -> child_pid=%d\n",
 nsecs, comm, args->child_pid);
 @app_pid = args->child_pid;
}

// 进程执行
tracepoint:sched:sched_process_exec
/@app_pid == pid/
{
 printf("[%llu] EXEC: %s\n", nsecs, comm);
}

// 库加载追踪
tracepoint:syscalls:sys_enter_openat
/pid == @app_pid && strcontains(str(args->filename), ".so")/
{
 printf("[%llu] LOAD: %s\n", nsecs, str(args->filename));
 @loaded_libs[str(args->filename)] = 1;
}

// DEX 文件访问
tracepoint:syscalls:sys_enter_openat
/pid == @app_pid &&
 (strcontains(str(args->filename), ".dex") ||
 strcontains(str(args->filename), ".apk") ||
 strcontains(str(args->filename), ".vdex") ||
 strcontains(str(args->filename), ".odex"))/
{
 printf("[%llu] DEX: %s\n", nsecs, str(args->filename));
}

// mmap 可执行区域 (代码加载)
tracepoint:syscalls:sys_enter_mmap
/pid == @app_pid && (args->prot & 4)/ // PROT_EXEC
{
 printf("[%llu] MMAP_EXEC: addr=%p len=%zu\n",
 nsecs, args->addr, args->len);
 @exec_maps = count();
}

// 网络连接 (首次通信)
tracepoint:syscalls:sys_enter_connect
/pid == @app_pid/
{
 printf("[%llu] FIRST_CONNECT\n", nsecs);
}

// 10 秒后输出统计
interval:s:10
{
 printf("\n=== 启动分析完成 ===\n");
 printf("加载的库:\n");
 print(@loaded_libs);
 printf("可执行映射数: %d\n", @exec_maps);
 exit();
}

追踪 Native 库初始化

#!/usr/bin/env bpftrace
// 文件: native_init.bt
// 追踪 .so 库的 init 函数

// dlopen 调用
uprobe:/apex/com.android.runtime/lib64/bionic/libdl.so:dlopen
/comm == "com.target.app"/
{
 printf("[DLOPEN] Loading: %s\n", str(arg0));
 @dlopen_start[str(arg0)] = nsecs;
}

uretprobe:/apex/com.android.runtime/lib64/bionic/libdl.so:dlopen
/comm == "com.target.app"/
{
 printf("[DLOPEN] Returned: %p\n", retval);
}

// 追踪 JNI_OnLoad
uprobe:/data/app/com.target.app-*/lib/arm64/*.so:JNI_OnLoad
/comm == "com.target.app"/
{
 printf("[JNI_OnLoad] %s\n", probe);
 @jni_onload = count();
}

// 追踪 .init_array 执行 (constructor 函数)
// 这需要知道具体函数地址，或使用通配符

实战案例 4: 协议逆向分析

💡 思路一句话: 用 eBPF 在 socket 层拦截收发数据，配合 uprobe hook 应用层加解密函数，同时获取加密前明文和网络层密文，快速理解协议结构。

追踪自定义协议

#!/usr/bin/env bpftrace
// 文件: protocol_analysis.bt
// 分析应用自定义协议

// Socket 创建
tracepoint:syscalls:sys_enter_socket
/comm == "com.target.app"/
{
 printf("[SOCKET] domain=%d type=%d protocol=%d\n",
 args->family, args->type, args->protocol);
}

// 数据发送
tracepoint:syscalls:sys_enter_sendto
/comm == "com.target.app"/
{
 $buf = (uint8 *)args->buff;
 $len = args->len;

 printf("\n[SEND] len=%d\n", $len);

 // 打印协议头 (假设前16字节是头部)
 printf("Header: ");
 $i = 0;
 while ($i < 16 && $i < $len) {
 printf("%02x ", $buf[$i]);
 $i++;
 }
 printf("\n");

 // 分析魔数
 $magic = ($buf[0] << 24) | ($buf[1] << 16) | ($buf[2] << 8) | $buf[3];
 printf("Magic: 0x%08x\n", $magic);

 @send_sizes = hist($len);
}

// 数据接收
tracepoint:syscalls:sys_exit_recvfrom
/comm == "com.target.app" && args->ret > 0/
{
 printf("\n[RECV] len=%d\n", args->ret);
 @recv_sizes = hist(args->ret);
}

END
{
 printf("\n=== 协议统计 ===\n");
 printf("发送包大小分布:\n");
 print(@send_sizes);
 printf("接收包大小分布:\n");
 print(@recv_sizes);
}

追踪 Protobuf 序列化

#!/usr/bin/env bpftrace
// 文件: protobuf_trace.bt
// 追踪 Protobuf 编解码

// Google Protobuf 库函数
uprobe:/data/app/com.target.app-*/lib/arm64/lib*.so:*SerializeToString*
/comm == "com.target.app"/
{
 printf("[PROTOBUF] SerializeToString\n");
 @serialize = count();
}

uprobe:/data/app/com.target.app-*/lib/arm64/lib*.so:*ParseFromString*
/comm == "com.target.app"/
{
 printf("[PROTOBUF] ParseFromString\n");
 @parse = count();
}

// 追踪更底层的编码函数
uprobe:/data/app/com.target.app-*/lib/arm64/lib*.so:*WriteVarint*
/comm == "com.target.app"/
{
 @varint_writes = count();
}

实战案例 5: Root 检测分析

💡 思路一句话: 用 eBPF 监控应用的 open/access/stat 系统调用，观察它检测哪些路径（/system/xbin/su, /sbin/magisk 等），从而精准定位并绕过 root 检测。

监控 Root 检测行为

#!/usr/bin/env bpftrace
// 文件: root_detect.bt
// 分析应用的 Root 检测机制

// 检测 su 二进制文件
tracepoint:syscalls:sys_enter_openat
/comm == "com.target.app"/
{
 $f = str(args->filename);

 if (strcontains($f, "/su") ||
 strcontains($f, "supersu") ||
 strcontains($f, "superuser") ||
 strcontains($f, "magisk") ||
 strcontains($f, "busybox")) {
 printf("[ROOT-CHECK] Checking: %s\n", $f);
 @root_checks[$f] = count();
 }
}

// 检测 stat/access 调用
tracepoint:syscalls:sys_enter_faccessat
/comm == "com.target.app"/
{
 $f = str(args->filename);

 if (strcontains($f, "/su") ||
 strcontains($f, "/system/xbin/") ||
 strcontains($f, "/system/bin/")) {
 printf("[ROOT-CHECK] Access check: %s\n", $f);
 }
}

// 检测 which 命令
tracepoint:syscalls:sys_enter_execve
/strcontains(str(args->filename), "which")/
{
 printf("[ROOT-CHECK] Exec: %s\n", str(args->filename));
}

// 检测系统属性读取
uprobe:/system/lib64/libc.so:__system_property_get
/comm == "com.target.app"/
{
 $name = str(arg0);

 if (strcontains($name, "ro.build") ||
 strcontains($name, "ro.debuggable") ||
 strcontains($name, "ro.secure")) {
 printf("[ROOT-CHECK] Property: %s\n", $name);
 @prop_checks[$name] = count();
 }
}

END
{
 printf("\n=== Root 检测统计 ===\n");
 printf("文件检查:\n");
 print(@root_checks);
 printf("\n属性检查:\n");
 print(@prop_checks);
}

性能分析工具

热点函数分析

#!/usr/bin/env bpftrace
// 文件: hotspot.bt
// CPU 热点分析

profile:hz:99
/comm == "com.target.app"/
{
 @user_stacks[ustack(10)] = count();
 @kernel_stacks[kstack(10)] = count();
}

END
{
 printf("\n=== 用户态热点 (Top 5) ===\n");
 print(@user_stacks, 5);
 printf("\n=== 内核态热点 (Top 5) ===\n");
 print(@kernel_stacks, 5);
}

锁竞争分析

#!/usr/bin/env bpftrace
// 文件: lock_contention.bt

uprobe:/apex/com.android.runtime/lib64/bionic/libc.so:pthread_mutex_lock
/comm == "com.target.app"/
{
 @lock_start[tid, arg0] = nsecs;
}

uretprobe:/apex/com.android.runtime/lib64/bionic/libc.so:pthread_mutex_lock
/comm == "com.target.app" && @lock_start[tid, arg0]/
{
 $wait = nsecs - @lock_start[tid, arg0];
 @lock_wait = hist($wait);

 if ($wait > 1000000) { // > 1ms
 printf("[LOCK] tid=%d waited %d ns for mutex %p\n",
 tid, $wait, arg0);
 }

 delete(@lock_start[tid, arg0]);
}

END
{
 printf("\n=== 锁等待时间分布 (ns) ===\n");
 print(@lock_wait);
}

与 Frida 配合使用

场景: eBPF 监控 + Frida 修改

# 终端1: eBPF 监控 (不被检测)
adb shell /data/local/tmp/bpftrace -e '
tracepoint:syscalls:sys_enter_openat
/comm == "com.target.app"/
{
 printf("OPEN: %s\n", str(args->filename));
}'

# 终端2: 等待检测通过后，使用 Frida 注入
# 可以利用 eBPF 的信息决定 Hook 点
frida -U -f com.target.app -l script.js

使用 eBPF 辅助 Frida 分析

// Frida 脚本: 基于 eBPF 发现的地址进行 Hook
// eBPF 可以发现动态加载的库地址

// 假设 eBPF 发现加密函数在 0x12345678
var encrypt_addr = ptr("0x12345678");

Interceptor.attach(encrypt_addr, {
 onEnter: function(args) {
 console.log("Encrypt called");
 }
});

常见问题解决

Q: bpftrace 找不到符号

# 检查符号表
adb shell readelf -s /system/lib64/libcrypto.so | grep EVP

# 使用地址而非符号名
uprobe:/system/lib64/libcrypto.so:0x12345

Q: 追踪导致应用崩溃

# 减少追踪频率
interval:ms:100 # 而不是每次调用

# 避免追踪高频函数
# 使用 profile 采样而非 uprobe

Q: 内存限制

# 增加 map 大小
sudo sysctl kernel.perf_event_max_stack=127
sudo sysctl kernel.perf_event_max_contexts_per_stack=8

总结

eBPF 在 Android 逆向中的核心优势:

隐蔽性: 内核态运行，无法被应用检测
全面性: 可追踪系统调用、网络、文件、内存等所有层面
高性能: JIT 编译，开销极低
安全性: 不影响目标应用稳定性

建议工作流:

先用 eBPF 隐蔽监控，了解应用行为
分析反调试机制
确定关键函数和地址
必要时配合 Frida 进行深入分析

参考资料

eBPF 内部原理

overkazaf@gmail.com (+5) — Sat, 27 Dec 2025 00:00:00 +0000

eBPF 内部原理

本文深入剖析 eBPF 的内部工作机制，帮助你理解这项技术的底层原理，从而更好地应用于 Android 逆向工程。

架构概览

┌─────────────────────────────────────────────────────────────┐
│ 用户空间 │
│ ┌─────────────┐ ┌──────────────┐ ┌─────────────────┐ │
│ │ bpftrace │ │ BCC/Python │ │ libbpf/C │ │
│ └──────┬──────┘ └──────┬───────┘ └────────┬────────┘ │
│ │ │ │ │
│ └────────────────┼────────────────────┘ │
│ │ bpf() 系统调用 │
├──────────────────────────┼──────────────────────────────────┤
│ 内核空间 │
│ ▼ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ BPF 验证器 │ │
│ │ - 安全检查 - 边界验证 - 死循环检测 │ │
│ └───────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ JIT 编译器 │ │
│ │ 将 BPF 字节码编译为原生机器码 │ │
│ └───────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────┼────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────────┐ │
│ │ kprobes │ │tracepoint│ │ socket/XDP │ │
│ └─────────┘ └─────────┘ └─────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ BPF Maps │ │
│ │ 内核与用户空间共享的数据结构 │ │
│ └───────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘

BPF 虚拟机

寄存器模型

eBPF 使用 11 个 64 位寄存器:

寄存器	用途
R0	返回值，辅助函数返回值
R1-R5	函数参数
R6-R9	被调用者保存寄存器
R10	只读栈帧指针

// 寄存器使用示例
// R1 = ctx (上下文指针)
// R0 = 返回值

int bpf_prog(struct pt_regs *ctx) {
 // R1 = ctx
 u64 pid = bpf_get_current_pid_tgid(); // 结果在 R0
 return 0; // R0 = 0
}

指令集

eBPF 指令格式 (64 位):

┌───────┬───────┬───────┬───────────────┬───────────────────┐
│ 8 bit │ 4 bit │ 4 bit │ 16 bit │ 32 bit │
│ op │ dst │ src │ offset │ imm │
└───────┴───────┴───────┴───────────────┴───────────────────┘

指令类别:

// 算术指令
BPF_ADD | BPF_X | BPF_ALU64 // dst += src (64位)
BPF_SUB | BPF_K | BPF_ALU // dst -= imm (32位)

// 跳转指令
BPF_JEQ | BPF_K | BPF_JMP // if dst == imm goto pc+off
BPF_JGT | BPF_X | BPF_JMP // if dst > src goto pc+off

// 内存访问
BPF_LDX | BPF_MEM | BPF_DW // dst = *(u64 *)(src + off)
BPF_STX | BPF_MEM | BPF_W // *(u32 *)(dst + off) = src

// 函数调用
BPF_CALL // 调用辅助函数
BPF_EXIT // 退出程序

示例程序字节码

// 简单的 eBPF 程序
int hello(void *ctx) {
 char msg[] = "Hello";
 bpf_trace_printk(msg, sizeof(msg));
 return 0;
}

// 编译后的字节码 (简化)
/*
0: r1 = 0x6f6c6c6548 // "Hello" 低位
1: *(u64 *)(r10 - 8) = r1 // 存储到栈
2: r1 = r10 - 8 // msg 地址
3: r2 = 6 // sizeof(msg)
4: call bpf_trace_printk // 调用辅助函数
5: r0 = 0 // 返回值
6: exit // 退出
*/

验证器 (Verifier)

验证器是 eBPF 安全性的核心，确保程序不会破坏内核。

验证流程

┌─────────────────────────────────────────────────────────────┐
│ BPF 验证器流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. CFG 检查 (Control Flow Graph) │
│ ├─ 检测不可达代码 │
│ ├─ 验证所有路径都有 exit │
│ └─ 检测循环 (默认禁止无界循环) │
│ │
│ 2. 模拟执行 │
│ ├─ 追踪每个寄存器状态 │
│ ├─ 验证内存访问边界 │
│ └─ 检查指针类型安全 │
│ │
│ 3. 辅助函数调用验证 │
│ ├─ 检查参数类型 │
│ ├─ 验证调用权限 │
│ └─ 追踪返回值类型 │
│ │
│ 4. Map 访问验证 │
│ ├─ 检查 Map 类型兼容性 │
│ ├─ 验证键/值大小 │
│ └─ 检查并发安全性 │
│ │
└─────────────────────────────────────────────────────────────┘

寄存器状态追踪

// 验证器追踪的寄存器状态
enum bpf_reg_type {
 NOT_INIT, // 未初始化
 SCALAR_VALUE, // 标量值
 PTR_TO_CTX, // 上下文指针
 PTR_TO_MAP_VALUE, // Map 值指针
 PTR_TO_STACK, // 栈指针
 PTR_TO_PACKET, // 网络包指针
 // ...
};

// 验证示例
int bpf_prog(struct __sk_buff *skb) {
 // R1 = PTR_TO_CTX (skb)

 u8 *data = (void *)(long)skb->data;
 // data 类型: PTR_TO_PACKET

 u8 *end = (void *)(long)skb->data_end;
 // end 类型: PTR_TO_PACKET_END

 // 必须进行边界检查
 if (data + 14 > end) {
 return 0; // 验证器要求的边界检查
 }

 // 现在可以安全访问 data[0..13]
 return data[0];
}

常见验证错误

# 错误1: 无界循环
"back-edge from insn X to Y"

# 错误2: 越界访问
"invalid access to map value, off=X size=Y"

# 错误3: 未初始化寄存器
"R3 !read_ok"

# 错误4: 指针泄露
"cannot write pointer to map value"

# 错误5: 无效的辅助函数调用
"unknown func bpf_xxx"

JIT 编译器

编译流程

BPF 字节码 → JIT 编译器 → 原生机器码
 │ │ │
 │ │ ├─ x86_64
 │ │ ├─ ARM64
 │ │ ├─ ARM32
 │ │ └─ ...

ARM64 JIT 示例

// BPF 指令
BPF_ALU64 | BPF_ADD | BPF_X // R0 += R1

// 编译为 ARM64
ADD X0, X0, X1

// BPF 指令
BPF_JEQ | BPF_K | BPF_JMP // if R0 == 42 goto +5

// 编译为 ARM64
CMP X0, #42
B.EQ .+5*4

JIT 优化

// 常量折叠
r1 = 10
r2 = 20
r3 = r1 + r2 // 编译时计算为 30

// 死代码消除
if (false) {
 // 这段代码会被移除
}

// 寄存器分配
// BPF 寄存器直接映射到物理寄存器
// R0-R9 → X0-X9 (ARM64)

BPF Maps

Map 类型详解

// 1. 哈希表 - 任意键值对
BPF_MAP_TYPE_HASH
// 用途: 存储 PID 到计数的映射
struct {
 __uint(type, BPF_MAP_TYPE_HASH);
 __uint(max_entries, 10240);
 __type(key, u32); // PID
 __type(value, u64); // 计数
} pid_counts SEC(".maps");

// 2. 数组 - 快速索引访问
BPF_MAP_TYPE_ARRAY
// 用途: 预分配的固定大小数组
struct {
 __uint(type, BPF_MAP_TYPE_ARRAY);
 __uint(max_entries, 256);
 __type(key, u32);
 __type(value, struct stats);
} syscall_stats SEC(".maps");

// 3. 性能缓冲区 - 高效事件传输
BPF_MAP_TYPE_PERF_EVENT_ARRAY
// 用途: 向用户空间发送事件
struct {
 __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY);
 __uint(key_size, sizeof(int));
 __uint(value_size, sizeof(int));
} events SEC(".maps");

// 4. 栈追踪 - 存储调用栈
BPF_MAP_TYPE_STACK_TRACE
// 用途: 捕获内核/用户态调用栈

// 5. LRU 哈希表 - 自动淘汰
BPF_MAP_TYPE_LRU_HASH
// 用途: 有限空间下的缓存

Map 操作

// 内核态操作
void *bpf_map_lookup_elem(map, key);
long bpf_map_update_elem(map, key, value, flags);
long bpf_map_delete_elem(map, key);

// 用户态操作 (通过 bpf 系统调用)
int bpf_map_lookup_elem(int fd, const void *key, void *value);
int bpf_map_update_elem(int fd, const void *key, const void *value, __u64 flags);
int bpf_map_delete_elem(int fd, const void *key);

Map 并发安全

// 原子操作
__sync_fetch_and_add(&value, 1);

// Per-CPU Map - 无锁并发
BPF_MAP_TYPE_PERCPU_HASH
BPF_MAP_TYPE_PERCPU_ARRAY

// 自旋锁 (较新内核)
struct bpf_spin_lock lock;
bpf_spin_lock(&lock);
// 临界区
bpf_spin_unlock(&lock);

程序类型深入

Kprobe/Kretprobe

// 在内核函数入口处触发
SEC("kprobe/do_sys_openat2")
int kprobe_openat(struct pt_regs *ctx) {
 // ctx 包含寄存器状态
 // ARM64: x0-x7 = 参数
 char *filename = (char *)PT_REGS_PARM2(ctx);
 return 0;
}

// 在内核函数返回时触发
SEC("kretprobe/do_sys_openat2")
int kretprobe_openat(struct pt_regs *ctx) {
 // PT_REGS_RC(ctx) = 返回值
 int fd = PT_REGS_RC(ctx);
 return 0;
}

Uprobe/Uretprobe

// 在用户态函数入口处触发
SEC("uprobe/libc.so.6:malloc")
int uprobe_malloc(struct pt_regs *ctx) {
 size_t size = PT_REGS_PARM1(ctx);
 bpf_printk("malloc(%zu)\n", size);
 return 0;
}

// 在用户态函数返回时触发
SEC("uretprobe/libc.so.6:malloc")
int uretprobe_malloc(struct pt_regs *ctx) {
 void *ptr = (void *)PT_REGS_RC(ctx);
 bpf_printk("malloc returned %p\n", ptr);
 return 0;
}

Tracepoint

// 内核静态追踪点 - 稳定的 ABI
SEC("tracepoint/syscalls/sys_enter_openat")
int trace_openat(struct trace_event_raw_sys_enter *ctx) {
 // 参数通过 args 访问
 char *filename = (char *)ctx->args[1];
 int flags = ctx->args[2];
 return 0;
}

Socket/XDP

// Socket 过滤器
SEC("socket")
int socket_filter(struct __sk_buff *skb) {
 // 返回 0 = 丢弃, 返回正数 = 接受
 return skb->len;
}

// XDP - 高性能网络处理
SEC("xdp")
int xdp_filter(struct xdp_md *ctx) {
 void *data = (void *)(long)ctx->data;
 void *data_end = (void *)(long)ctx->data_end;

 struct ethhdr *eth = data;
 if ((void *)(eth + 1) > data_end)
 return XDP_DROP;

 return XDP_PASS;
}

辅助函数

内存访问

// 安全读取内核内存
long bpf_probe_read(void *dst, u32 size, const void *src);

// 安全读取用户内存
long bpf_probe_read_user(void *dst, u32 size, const void *src);

// 安全读取字符串
long bpf_probe_read_str(void *dst, u32 size, const void *src);
long bpf_probe_read_user_str(void *dst, u32 size, const void *src);

进程信息

// 获取 PID/TID
u64 bpf_get_current_pid_tgid(void);
// 返回: (PID << 32) | TID

// 获取 UID/GID
u64 bpf_get_current_uid_gid(void);
// 返回: (GID << 32) | UID

// 获取进程名
long bpf_get_current_comm(void *buf, u32 size);

// 获取 cgroup ID
u64 bpf_get_current_cgroup_id(void);

时间和随机

// 获取纳秒级时间戳
u64 bpf_ktime_get_ns(void);

// 获取启动时间
u64 bpf_ktime_get_boot_ns(void);

// 获取随机数
u32 bpf_get_prandom_u32(void);

Map 操作

void *bpf_map_lookup_elem(struct bpf_map *map, const void *key);
long bpf_map_update_elem(struct bpf_map *map, const void *key,
 const void *value, u64 flags);
long bpf_map_delete_elem(struct bpf_map *map, const void *key);

输出和调试

// 性能事件输出
long bpf_perf_event_output(void *ctx, struct bpf_map *map,
 u64 flags, void *data, u64 size);

// 环形缓冲区输出 (推荐)
void *bpf_ringbuf_reserve(struct bpf_map *ringbuf, u64 size, u64 flags);
void bpf_ringbuf_submit(void *data, u64 flags);
void bpf_ringbuf_discard(void *data, u64 flags);

// 调试输出
long bpf_trace_printk(const char *fmt, u32 fmt_size, ...);
// 输出到 /sys/kernel/debug/tracing/trace_pipe

CO-RE (Compile Once – Run Everywhere)

BTF (BPF Type Format)

BTF 提供了内核类型信息，使 eBPF 程序可以跨内核版本运行。

// 传统方式 - 硬编码偏移
u32 pid = *(u32 *)(task + 0x4c0); // 不同内核偏移不同

// CO-RE 方式 - 使用 BTF
u32 pid;
bpf_core_read(&pid, sizeof(pid), &task->pid);
// 或使用 BPF_CORE_READ 宏
u32 pid = BPF_CORE_READ(task, pid);

字段重定位

// 自动处理结构体字段偏移变化
struct task_struct___old {
 int pid;
 // ... 旧版本布局
};

struct task_struct___new {
 int __pad;
 int pid;
 // ... 新版本布局
};

// CO-RE 会在加载时自动重定位
int pid = BPF_CORE_READ(task, pid);

内核版本检测

// 检查字段是否存在
if (bpf_core_field_exists(task->loginuid)) {
 // 使用 loginuid
}

// 检查枚举值
if (bpf_core_enum_value_exists(enum bpf_func_id, BPF_FUNC_xyz)) {
 // 使用新功能
}

Android 特定考虑

Android eBPF 限制

SELinux 限制

# 检查 SELinux 域
adb shell cat /proc/self/attr/current

# 可能需要的 SELinux 策略
allow domain bpf:bpf { map_create prog_load };

内核配置差异

# 检查可用的 eBPF 特性
adb shell cat /proc/sys/kernel/unprivileged_bpf_disabled

库路径差异

# Android 系统库位置
/system/lib64/libc.so
/apex/com.android.runtime/lib64/bionic/libc.so
/system/lib64/libcrypto.so

Android 专用追踪

// 追踪 Binder 调用
SEC("tracepoint/binder/binder_transaction")
int trace_binder(struct trace_event_raw_binder_transaction *ctx) {
 // 追踪进程间通信
 return 0;
}

// 追踪 ART 虚拟机
SEC("uprobe/libart.so:_ZN3art...")
int trace_art(struct pt_regs *ctx) {
 // 追踪 Java 方法调用
 return 0;
}

性能优化

减少 Map 查找

// 不好 - 多次查找
void *val1 = bpf_map_lookup_elem(&map, &key);
void *val2 = bpf_map_lookup_elem(&map, &key);

// 好 - 缓存结果
void *val = bpf_map_lookup_elem(&map, &key);
if (val) {
 // 使用 val 两次
}

使用 Per-CPU Map

// 避免锁竞争
struct {
 __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
 __uint(max_entries, 1);
 __type(key, u32);
 __type(value, struct stats);
} stats SEC(".maps");

减少栈使用

// eBPF 栈大小限制为 512 字节

// 不好 - 大数组在栈上
char buf[256];

// 好 - 使用 Per-CPU 数组
struct {
 __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
 __uint(max_entries, 1);
 __type(key, u32);
 __type(value, char[256]);
} heap SEC(".maps");

调试技巧

查看验证器日志

# 增加日志级别
echo 2 > /proc/sys/kernel/bpf_stats_enabled

# 查看加载失败的详细信息
bpftool prog load xxx.o /sys/fs/bpf/xxx verbose

追踪 BPF 事件

# 使用 bpftrace 追踪 bpf 系统调用
bpftrace -e 'tracepoint:syscalls:sys_enter_bpf {
 printf("bpf cmd=%d\n", args->cmd);
}'

检查已加载的程序

# 列出所有 BPF 程序
bpftool prog list

# 查看程序详情
bpftool prog show id 123

# 查看字节码
bpftool prog dump xlated id 123

# 查看 JIT 编译后的代码
bpftool prog dump jited id 123

参考资料

Boot Image、Ramdisk 与 GKI 详解

overkazaf@gmail.com (+5) — Fri, 26 Dec 2025 00:00:00 +0000

Boot Image、Ramdisk 与 GKI 详解

深入理解 Android 启动镜像的结构、ramdisk 的作用以及 GKI (Generic Kernel Image) 架构，这些知识是理解 Root 方案（如 Magisk、KernelSU）工作原理的基础。

1. Android 启动流程概述

1.1 启动阶段

┌─────────────────────────────────────────────────────────────────────────────┐
│ Android 启动流程 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ ROM │ │ Boot- │ │ Kernel │ │ Init │ │
│ │ (固件) │───►│ loader │───►│ 启动 │───►│ 进程 │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │ │ │ │ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 硬件初始 │ │ 加载 │ │ 挂载 │ │ 启动 │ │
│ │ 化 │ │ boot.img │ │ ramdisk │ │ Zygote │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ System │ │
│ │ Server │ │
│ └──────────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ Launcher│ │
│ │ (桌面) │ │
│ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘

1.2 各阶段说明

阶段	说明	关键文件
BootROM	固化在芯片中的代码，初始化硬件	-
Bootloader	引导加载程序，加载内核	aboot, ABL
Kernel	Linux 内核启动	zImage, Image
Ramdisk	临时根文件系统	ramdisk.cpio
Init	第一个用户空间进程	/init
Zygote	Android 进程孵化器	app_process

2. Boot Image 结构

2.1 Boot Image 组成

Boot Image (boot.img) 是 Android 设备启动的核心镜像：

┌─────────────────────────────────────────────────────────────────────────────┐
│ boot.img 结构 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 偏移量 大小 内容 │
│ ───────────────────────────────────────────────────────────────────── │
│ 0x0000 2KB Boot Header (启动头) │
│ - magic: "ANDROID!" │
│ - kernel_size │
│ - ramdisk_size │
│ - cmdline │
│ - ... │
│ ───────────────────────────────────────────────────────────────────── │
│ 对齐后 kernel_size Kernel (内核镜像) │
│ - 压缩的 Linux 内核 │
│ - 通常为 gzip 压缩 │
│ ───────────────────────────────────────────────────────────────────── │
│ 对齐后 ramdisk_size Ramdisk (初始内存盘) │
│ - CPIO 格式的文件系统 │
│ - gzip 压缩 │
│ ───────────────────────────────────────────────────────────────────── │
│ 对齐后 second_size Second Stage (可选) │
│ - 第二阶段引导程序 │
│ ───────────────────────────────────────────────────────────────────── │
│ 对齐后 dtb_size DTB (设备树, v2+) │
│ - Device Tree Blob │
│ │
└─────────────────────────────────────────────────────────────────────────────┘

2.2 Boot Header 版本

Android 不同版本使用不同的 boot header 格式：

版本	Android 版本	特点
v0-v2	Android 9 及更早	传统格式
v3	Android 11	引入 vendor_boot
v4	Android 12+	支持 vendor_ramdisk

2.3 Boot Header v3/v4 结构

// Android 12+ boot header v4
struct boot_img_hdr_v4 {
 uint8_t magic[BOOT_MAGIC_SIZE]; // "ANDROID!"
 uint32_t kernel_size; // 内核大小
 uint32_t ramdisk_size; // ramdisk 大小
 uint32_t os_version; // 系统版本
 uint32_t header_size; // header 大小
 uint32_t reserved[4]; // 保留字段
 uint32_t header_version; // header 版本 (4)
 uint8_t cmdline[BOOT_ARGS_SIZE]; // 内核命令行
 uint32_t signature_size; // 签名大小 (v4 新增)
};

3. Ramdisk 详解

3.1 什么是 Ramdisk

Ramdisk 是一个临时的内存文件系统，在内核启动早期加载到内存中：

格式: CPIO 归档，通常使用 gzip 压缩
作用: 提供启动初期所需的文件和程序
生命周期: 系统启动后可能被卸载或保留

3.2 Ramdisk 内容

ramdisk/
├── init # 第一个用户空间进程
├── init.rc # init 配置脚本
├── init.*.rc # 设备特定配置
├── default.prop # 默认属性
├── fstab.* # 文件系统挂载表
├── ueventd.rc # 设备节点配置
├── sbin/ # 系统二进制文件
│ ├── adbd # ADB 守护进程
│ └── ...
├── system/ # 指向 /system 的挂载点
├── vendor/ # 指向 /vendor 的挂载点
├── dev/ # 设备文件
├── proc/ # 进程文件系统
└── sys/ # sysfs 文件系统

3.3 First Stage Init vs Second Stage Init

Android 使用两阶段 init：

┌─────────────────────────────────────────────────────────────────────────────┐
│ Init 两阶段启动 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────────────────────┐ │
│ │ First Stage Init │ │
│ │ │ │
│ │ 来源: boot.img 中的 ramdisk │ │
│ │ 任务: │ │
│ │ 1. 设置基本环境 (/dev, /proc, /sys) │ │
│ │ 2. 加载 SELinux 策略 │ │
│ │ 3. 挂载 /system, /vendor 等分区 │ │
│ │ 4. 切换到 Second Stage Init │ │
│ │ │ │
│ └────────────────────────────┬──────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────────────────────────────────────────────────────┐ │
│ │ Second Stage Init │ │
│ │ │ │
│ │ 来源: /system/bin/init │ │
│ │ 任务: │ │
│ │ 1. 解析 init.rc 脚本 │ │
│ │ 2. 启动各类服务 (servicemanager, surfaceflinger...) │ │
│ │ 3. 启动 Zygote │ │
│ │ 4. 属性服务 │ │
│ │ │ │
│ └───────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘

3.4 不同类型的 Ramdisk

Android 11+ 引入了多种 ramdisk：

类型	位置	内容	用途
Generic Ramdisk	boot.img	通用 init 文件	First stage init
Vendor Ramdisk	vendor_boot.img	厂商特定文件	硬件初始化
Recovery Ramdisk	recovery.img	Recovery 环境	系统恢复

4. GKI (Generic Kernel Image)

4.1 GKI 概述

GKI 是 Google 在 Android 11 引入的通用内核镜像架构：

┌─────────────────────────────────────────────────────────────────────────────┐
│ 传统架构 vs GKI 架构 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 传统架构 (Android 10 及更早) │
│ ───────────────────────────────────────── │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ boot.img (设备特定) │ │
│ │ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ │
│ │ │ Kernel │ │ Ramdisk │ │ DTB │ │ │
│ │ │ (设备特定) │ │ (设备特定) │ │ (设备特定) │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ - 厂商驱动 │ │ - init │ │ - 设备树 │ │ │
│ │ │ - 定制修改 │ │ - 配置文件 │ │ │ │ │
│ │ └──────────────────┘ └──────────────────┘ └──────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ │
│ GKI 架构 (Android 11+) │
│ ───────────────────────────────────────── │
│ │
│ ┌──────────────────────────────────┐ ┌──────────────────────────────┐ │
│ │ boot.img (通用) │ │ vendor_boot.img │ │
│ │ ┌──────────────────────────┐ │ │ ┌──────────────────────┐ │ │
│ │ │ GKI Kernel │ │ │ │ Vendor Ramdisk │ │ │
│ │ │ (Google 提供) │ │ │ │ (厂商提供) │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ - 标准化接口 │ │ │ │ - 硬件初始化 │ │ │
│ │ │ - 稳定 ABI │ │ │ │ - 厂商配置 │ │ │
│ │ └──────────────────────────┘ │ │ └──────────────────────┘ │ │
│ │ ┌──────────────────────────┐ │ │ ┌──────────────────────┐ │ │
│ │ │ Generic Ramdisk │ │ │ │ DTB │ │ │
│ │ │ (Google 提供) │ │ │ │ (厂商提供) │ │ │
│ │ └──────────────────────────┘ │ │ └──────────────────────┘ │ │
│ └──────────────────────────────────┘ └──────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ vendor_dlkm (动态加载内核模块) │ │
│ │ 厂商驱动以 LKM 形式加载，不修改 GKI 内核 │ │
│ └──────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘

4.2 GKI 版本

GKI 版本	Android 版本	内核版本	特点
GKI 1.0	Android 11	5.4	初始版本
GKI 2.0	Android 12	5.10	完整模块化
GKI 2.0	Android 13	5.15	增强稳定性
GKI 2.0	Android 14	6.1	最新内核支持

4.3 GKI 的优势

┌─────────────────────────────────────────────────────────────────────────────┐
│ GKI 优势 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. 更快的安全更新 │
│ - Google 可以直接推送内核安全补丁 │
│ - 无需等待厂商适配 │
│ │
│ 2. 标准化接口 (KMI - Kernel Module Interface) │
│ - 厂商驱动与内核解耦 │
│ - 驱动以模块形式加载 │
│ │
│ 3. 更小的 boot.img │
│ - 厂商特定内容移至 vendor_boot │
│ - 便于 OTA 更新 │
│ │
│ 4. 利于 Root 方案 │
│ - KernelSU 可以作为 LKM 加载 │
│ - 无需编译完整内核 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘

4.4 检查设备是否使用 GKI

# 检查内核版本
adb shell uname -r
# GKI 内核通常显示: 5.10.x-android13-x-xxxxx

# 检查是否存在 vendor_boot 分区
adb shell ls -la /dev/block/by-name/ | grep vendor_boot

# 检查内核配置
adb shell zcat /proc/config.gz | grep CONFIG_GKI

5. 分区与镜像类型

5.1 启动相关分区

分区	用途	备注
boot	内核 + 通用 ramdisk	必需
vendor_boot	厂商 ramdisk + DTB	GKI 设备
init_boot	通用 ramdisk	Android 13+
recovery	Recovery 环境	部分设备
dtbo	设备树覆盖	独立分区

5.2 Android 13+ 分区变化

Android 12:
boot.img = kernel + generic_ramdisk

Android 13+:
boot.img = kernel only
init_boot.img = generic_ramdisk

5.3 A/B 分区

现代 Android 设备使用 A/B 分区方案：

boot_a boot_b
vendor_boot_a vendor_boot_b
system_a system_b
...

查看当前槽位：

adb shell getprop ro.boot.slot_suffix
# 输出: _a 或 _b

6. Root 方案与启动镜像

6.1 Magisk 修改方式

┌─────────────────────────────────────────────────────────────────────────────┐
│ Magisk 修改 Boot Image │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 原始 boot.img 修改后 boot.img │
│ ───────────────── ───────────────── │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Kernel │ │ Kernel │ (保持不变) │
│ └─────────────────┘ └─────────────────┘ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Ramdisk │ ───► │ Magisk Ramdisk │ │
│ │ │ │ │ │
│ │ - init │ │ - magiskinit │ ← 替换 init │
│ │ - init.rc │ │ - init.rc │ │
│ │ - ... │ │ - overlay.d/ │ ← Magisk 覆盖 │
│ │ │ │ - ... │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ Magisk 注入流程: │
│ 1. magiskinit 作为 init 启动 │
│ 2. 执行 Magisk 初始化 │
│ 3. 挂载 Magisk 文件系统 │
│ 4. 启动 magiskd 守护进程 │
│ 5. 调用原始 init 继续启动 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘

6.2 KernelSU 修改方式

┌─────────────────────────────────────────────────────────────────────────────┐
│ KernelSU 修改 Boot Image │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 方式一: 修改内核 (编译时集成) │
│ ───────────────────────────────── │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 原始 Kernel │ ───► │ KernelSU Kernel │ ← 编译时集成 │
│ └─────────────────┘ └─────────────────┘ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Ramdisk │ │ Ramdisk │ (保持不变) │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ │
│ 方式二: LKM 加载 (GKI 设备) │
│ ───────────────────────────────── │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ GKI Kernel │ │ GKI Kernel │ (保持不变) │
│ └─────────────────┘ └─────────────────┘ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Ramdisk │ ───► │ Ramdisk │ │
│ │ │ │ + kernelsu.ko │ ← 添加内核模块 │
│ │ │ │ + 加载脚本 │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ 启动时加载 kernelsu.ko 模块，无需修改内核本身 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘

7. 实用工具与操作

7.1 提取 Boot Image

# 方法一: 从设备提取
adb shell su -c "dd if=/dev/block/by-name/boot of=/sdcard/boot.img"
adb pull /sdcard/boot.img

# 方法二: 从 OTA 包提取
unzip ota.zip boot.img
# 或使用 payload-dumper
python payload_dumper.py payload.bin --out ./extracted/

7.2 解包 Boot Image

使用 magiskboot (推荐):

# 解包
./magiskboot unpack boot.img

# 生成的文件:
# - kernel 内核
# - ramdisk.cpio ramdisk (压缩的)
# - dtb 设备树 (如果有)

# 解包 ramdisk
./magiskboot cpio ramdisk.cpio extract

使用 AIK (Android Image Kitchen):

./unpackimg.sh boot.img
# 输出到 split_img/ 和 ramdisk/

使用 mkbootimg 工具链:

# 解包
unpack_bootimg --boot_img boot.img --out boot_unpacked/

# 查看 boot.img 信息
unpack_bootimg --boot_img boot.img --format mkbootimg

7.3 打包 Boot Image

# 使用 magiskboot
./magiskboot repack boot.img new_boot.img

# 使用 mkbootimg
mkbootimg \
 --kernel kernel \
 --ramdisk ramdisk.cpio.gz \
 --cmdline "..." \
 --os_version 13.0.0 \
 --os_patch_level 2024-01 \
 --header_version 4 \
 -o new_boot.img

7.4 刷入 Boot Image

# 进入 fastboot 模式
adb reboot bootloader

# 刷入 boot 分区
fastboot flash boot new_boot.img

# 对于 A/B 设备，可能需要指定槽位
fastboot flash boot_a new_boot.img

# 重启
fastboot reboot

7.5 修改 Ramdisk

# 1. 解包 ramdisk
mkdir ramdisk_dir
cd ramdisk_dir
gzip -dc ../ramdisk.cpio.gz | cpio -idmv

# 2. 修改文件
# 例如修改 init.rc, default.prop 等

# 3. 重新打包
find . | cpio -o -H newc | gzip > ../ramdisk.cpio.gz

7.6 验证 Boot Image

# 使用 avbtool 验证签名 (如果使用 AVB)
avbtool verify_image --image boot.img

# 查看 vbmeta 信息
avbtool info_image --image vbmeta.img

KernelSU 内部原理

overkazaf@gmail.com (+5) — Fri, 26 Dec 2025 00:00:00 +0000

KernelSU 内部原理

深入分析 KernelSU 的内核级 root 实现机制，包括内核模块架构、权限提升原理、检测规避技术等核心内容。

1. 架构总览

1.1 整体架构图

┌─────────────────────────────────────────────────────────────────────────────┐
│ KernelSU 技术架构 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ 用户空间 (User Space) │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ KernelSU │ │ Root │ │ 普通 │ │ │
│ │ │ Manager │ │ 应用 │ │ 应用 │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ └──────┬──────┘ └──────┬──────┘ └─────────────┘ │ │
│ │ │ │ │ │
│ │ │ Binder/ │ prctl() │ │
│ │ │ ioctl │ syscall │ │
│ │ ↓ ↓ │ │
│ └──────────┼──────────────────┼────────────────────────────────────────┘ │
│ │ │ │
│ ═══════════╪══════════════════╪═════════════════════════════════════════ │
│ │ System Call │ Interface │
│ ═══════════╪══════════════════╪═════════════════════════════════════════ │
│ │ │ │
│ ┌──────────┼──────────────────┼────────────────────────────────────────┐ │
│ │ ↓ ↓ 内核空间 (Kernel Space) │ │
│ │ ┌─────────────────────────────────────────────────────────────┐ │ │
│ │ │ KernelSU 内核模块 │ │
│ │ │ │ │
│ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ │ ksu_hook │ │ allowlist │ │ sucompat │ │ │
│ │ │ │ │ │ │ │ │ │ │
│ │ │ │ - syscall │ │ - uid 管理 │ │ - su 二进制 │ │ │
│ │ │ │ hooking │ │ - 授权检查 │ │ 兼容层 │ │ │
│ │ │ │ - prctl │ │ - profile │ │ - Magisk │ │ │
│ │ │ │ handler │ │ 管理 │ │ API 兼容 │ │ │
│ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ │ │ │ │
│ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ │ module_fs │ │ selinux │ │ ksud │ │ │
│ │ │ │ │ │ patch │ │ daemon │ │ │
│ │ │ │ - overlayfs │ │ │ │ │ │ │
│ │ │ │ - mount │ │ - 策略修改 │ │ - 模块管理 │ │ │
│ │ │ │ 管理 │ │ - 权限控制 │ │ - 状态监控 │ │ │
│ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ │ │ │ │
│ │ └──────────────────────────────────────────────────────────────┘ │
│ │ │ │
│ │ ┌───────────────────────────────────────────────────────────────┐ │ │
│ │ │ Linux Kernel │ │
│ │ │ - task_struct 修改 │ │
│ │ │ - cred 结构体操作 │ │
│ │ │ - namespace 管理 │ │
│ │ └───────────────────────────────────────────────────────────────┘ │
│ └──────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘

1.2 核心组件

组件	功能	实现方式
ksu_hook	系统调用拦截	kprobe/ftrace
allowlist	权限管理	内核数据结构
sucompat	su 兼容层	进程伪装
module_fs	模块文件系统	overlayfs
ksud	用户空间守护进程	native daemon

2. 内核模块实现

2.1 模块加载机制

KernelSU 可以通过两种方式集成到内核：

方式一：编译时集成

// kernel/ksu/core.c
static int __init ksu_init(void)
{
 int ret;

 pr_info("KernelSU version %d\n", KSU_VERSION);

 // 初始化 allowlist
 ret = ksu_allowlist_init();
 if (ret)
 return ret;

 // 安装系统调用 hook
 ret = ksu_hook_init();
 if (ret)
 goto err_hook;

 // 初始化 SELinux 补丁
 ret = ksu_selinux_init();
 if (ret)
 goto err_selinux;

 // 启动 ksud 通信
 ret = ksu_ksud_init();
 if (ret)
 goto err_ksud;

 pr_info("KernelSU initialized successfully\n");
 return 0;

err_ksud:
 ksu_selinux_exit();
err_selinux:
 ksu_hook_exit();
err_hook:
 ksu_allowlist_exit();
 return ret;
}
core_initcall(ksu_init);

方式二：LKM 动态加载 (GKI 2.0+)

// 作为可加载内核模块
static int __init ksu_module_init(void)
{
 // 检查内核版本兼容性
 if (!ksu_check_kernel_compat())
 return -ENODEV;

 return ksu_init();
}

static void __exit ksu_module_exit(void)
{
 ksu_exit();
}

module_init(ksu_module_init);
module_exit(ksu_module_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("tiann");
MODULE_DESCRIPTION("KernelSU - Kernel-based root solution");

2.2 系统调用 Hook

KernelSU 使用 kprobe 或 ftrace 来 hook 关键系统调用：

// hook prctl 系统调用处理 root 请求
static int ksu_handle_prctl(int option, unsigned long arg2,
 unsigned long arg3, unsigned long arg4,
 unsigned long arg5)
{
 // KernelSU 魔数检查
 if (option == KSU_PRCTL_MAGIC) {
 switch (arg2) {
 case CMD_GET_VERSION:
 return KSU_VERSION;

 case CMD_BECOME_ROOT:
 return ksu_become_root(current);

 case CMD_CHECK_ROOT:
 return ksu_is_allowed_uid(current_uid().val);

 case CMD_GET_ALLOW_LIST:
 return ksu_get_allowlist((void __user *)arg3, arg4);

 case CMD_SET_ALLOW_LIST:
 return ksu_set_allowlist((void __user *)arg3, arg4);
 }
 }

 return -ENOSYS; // 传递给原始 handler
}

// 使用 kprobe 安装 hook
static struct kprobe kp_prctl = {
 .symbol_name = "__arm64_sys_prctl",
 .pre_handler = ksu_prctl_handler,
};

2.3 凭证修改 (Credential Modification)

KernelSU 通过直接修改进程的 cred 结构体来提升权限：

// kernel/ksu/core.c
int ksu_become_root(struct task_struct *task)
{
 struct cred *new_cred;
 struct ksu_profile *profile;

 // 检查是否在允许列表
 if (!ksu_is_allowed(task))
 return -EPERM;

 // 获取应用 profile
 profile = ksu_get_profile(task);

 // 准备新的凭证
 new_cred = prepare_creds();
 if (!new_cred)
 return -ENOMEM;

 // 设置 UID/GID 为 root
 new_cred->uid = new_cred->euid = new_cred->suid = new_cred->fsuid = GLOBAL_ROOT_UID;
 new_cred->gid = new_cred->egid = new_cred->sgid = new_cred->fsgid = GLOBAL_ROOT_GID;

 // 设置 capabilities
 if (profile && profile->capabilities) {
 new_cred->cap_effective = profile->cap_effective;
 new_cred->cap_permitted = profile->cap_permitted;
 new_cred->cap_inheritable = profile->cap_inheritable;
 } else {
 // 默认给予所有 capabilities
 cap_set_full(new_cred->cap_effective);
 cap_set_full(new_cred->cap_permitted);
 cap_set_full(new_cred->cap_inheritable);
 }

 // 修改 SELinux 上下文 (如果配置了)
 if (profile && profile->selinux_context) {
 ksu_set_selinux_context(new_cred, profile->selinux_context);
 }

 // 提交凭证修改
 return commit_creds(new_cred);
}

2.4 内核数据结构

// KernelSU 内部数据结构

// 允许列表条目
struct ksu_allow_entry {
 uid_t uid; // 应用 UID
 char package_name[256]; // 包名
 struct ksu_profile *profile; // 应用配置
 struct list_head list; // 链表节点
};

// 应用配置文件
struct ksu_profile {
 uid_t uid;
 gid_t gid;
 gid_t groups[32];
 int groups_count;

 kernel_cap_t cap_effective;
 kernel_cap_t cap_permitted;
 kernel_cap_t cap_inheritable;

 char selinux_context[128];

 struct {
 bool mount_namespace;
 bool pid_namespace;
 bool net_namespace;
 } namespace_flags;
};

// 全局状态
struct ksu_state {
 bool initialized;
 int version;

 spinlock_t allowlist_lock;
 struct list_head allowlist;

 struct proc_dir_entry *proc_entry;
 struct dentry *debug_root;
};

3. Root 授权机制

3.1 授权流程

┌─────────────────────────────────────────────────────────────────────────┐
│ KernelSU Root 授权流程 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 应用进程 KernelSU 内核模块 │
│ │ │ │
│ │ 1. prctl(KSU_MAGIC, │ │
│ │ CMD_BECOME_ROOT) │ │
│ │ ────────────────────────────>│ │
│ │ │ │
│ │ │ 2. 获取 current task │
│ │ │ 检查 uid/package │
│ │ │ │
│ │ │ 3. 查询 allowlist │
│ │ │ ┌─────────────────────┐ │
│ │ │ │ uid: 10086 │ │
│ │ │ │ pkg: com.example │ │
│ │ │ │ profile: {...} │ │
│ │ │ └─────────────────────┘ │
│ │ │ │
│ │ │ 4. 验证通过? │
│ │ │ ├─ Yes: prepare_creds() │
│ │ │ │ commit_creds() │
│ │ │ │ │
│ │ │ └─ No: return -EPERM │
│ │ │ │
│ │ 5. 返回结果 │ │
│ │ <────────────────────────────│ │
│ │ │ │
│ │ [成功后 uid=0, caps=full] │ │
│ ▼ ▼ │
│ │
└─────────────────────────────────────────────────────────────────────────┘

3.2 su 兼容实现

KernelSU 提供了与传统 su 命令兼容的接口：

// kernel/ksu/sucompat.c

// 当执行 /system/bin/su 时，内核会拦截并处理
static int ksu_su_handler(struct linux_binprm *bprm)
{
 const char *filename = bprm->filename;

 // 检查是否是 su 调用
 if (!ksu_is_su_path(filename))
 return 0; // 不处理

 // 检查调用者权限
 if (!ksu_is_allowed(current)) {
 // 未授权，返回原始的 "su: not found" 行为
 return -ENOENT;
 }

 // 提升权限
 int ret = ksu_become_root(current);
 if (ret)
 return ret;

 // 执行请求的 shell
 const char *shell = ksu_get_shell(bprm);
 return ksu_exec_shell(shell, bprm);
}

3.3 用户空间 API

应用程序可以通过以下方式与 KernelSU 交互：

// 用户空间代码示例
#include <sys/prctl.h>

#define KSU_PRCTL_MAGIC 0x4B535500 // "KSU\0"
#define CMD_GET_VERSION 0
#define CMD_BECOME_ROOT 1
#define CMD_CHECK_ROOT 2

// 检查 KernelSU 是否存在
int ksu_get_version(void) {
 return prctl(KSU_PRCTL_MAGIC, CMD_GET_VERSION, 0, 0, 0);
}

// 请求 root 权限
int ksu_become_root(void) {
 return prctl(KSU_PRCTL_MAGIC, CMD_BECOME_ROOT, 0, 0, 0);
}

// 检查是否有 root 权限
int ksu_check_root(void) {
 return prctl(KSU_PRCTL_MAGIC, CMD_CHECK_ROOT, 0, 0, 0);
}

4. OverlayFS 模块系统

4.1 模块存储结构

/data/adb/
├── ksu/
│ ├── bin/ # KernelSU 工具
│ │ └── ksud # 守护进程
│ ├── profile/ # 应用配置文件
│ │ ├── com.example.json
│ │ └── ...
│ └── log/ # 日志文件
│ └── ksud.log
├── modules/ # 已安装模块
│ ├── module_id_1/
│ │ ├── module.prop
│ │ ├── system/ # 要覆盖的系统文件
│ │ └── ...
│ └── module_id_2/
└── modules_update/ # 待更新模块

4.2 OverlayFS 实现

// kernel/ksu/module_fs.c

static int ksu_mount_overlayfs(const char *module_path)
{
 struct path lower, upper, work;
 struct ovl_fs_context ctx = {
 .redirect_mode = OVL_REDIRECT_ON,
 .index = true,
 };

 // 设置 lower (只读层): 原始系统分区
 kern_path("/system", LOOKUP_DIRECTORY, &lower);

 // 设置 upper (读写层): 模块修改
 char upper_path[PATH_MAX];
 snprintf(upper_path, sizeof(upper_path), "%s/system", module_path);
 kern_path(upper_path, LOOKUP_DIRECTORY, &upper);

 // 设置 work 目录
 char work_path[PATH_MAX];
 snprintf(work_path, sizeof(work_path), "%s/.work", module_path);
 kern_path(work_path, LOOKUP_DIRECTORY, &work);

 // 挂载 overlayfs
 return ovl_mount(&ctx, "/system", &lower, &upper, &work);
}

// 模块加载流程
int ksu_load_modules(void)
{
 struct dir_context ctx;
 struct file *modules_dir;

 modules_dir = filp_open("/data/adb/modules", O_RDONLY | O_DIRECTORY, 0);
 if (IS_ERR(modules_dir))
 return PTR_ERR(modules_dir);

 // 遍历模块目录
 iterate_dir(modules_dir, &ctx);

 // 对每个模块应用 overlayfs
 list_for_each_entry(module, &ksu_modules, list) {
 if (module->enabled) {
 ksu_mount_overlayfs(module->path);
 }
 }

 filp_close(modules_dir, NULL);
 return 0;
}

4.3 Magisk 模块兼容

KernelSU 实现了对 Magisk 模块格式的兼容：

// 解析 module.prop
static int ksu_parse_module_prop(const char *path, struct ksu_module *module)
{
 char buf[4096];
 struct file *f;

 f = filp_open(path, O_RDONLY, 0);
 if (IS_ERR(f))
 return PTR_ERR(f);

 kernel_read(f, buf, sizeof(buf), &f->f_pos);
 filp_close(f, NULL);

 // 解析字段
 ksu_parse_prop_field(buf, "id", module->id, sizeof(module->id));
 ksu_parse_prop_field(buf, "name", module->name, sizeof(module->name));
 ksu_parse_prop_field(buf, "version", module->version, sizeof(module->version));
 ksu_parse_prop_field(buf, "author", module->author, sizeof(module->author));

 return 0;
}

5. 隐蔽性设计

5.1 内核级隐藏优势

KernelSU 相比 Magisk 具有天然的隐蔽性优势：

┌─────────────────────────────────────────────────────────────────────────┐
│ 检测点对比 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 检测方法 Magisk KernelSU │
│ ───────────────────────────────────────────────────────────────── │
│ │
│ /system/bin/su 存在伪装文件 不存在 (内核直接处理) │
│ magiskd 进程 存在 不存在 │
│ /data/adb/magisk 存在 不存在 │
│ boot.img 修改 ramdisk 修改 内核修改 │
│ 属性检测 ro.boot.vbmeta.* 无明显特征 │
│ SELinux 上下文 需要额外处理 内核直接设置 │
│ 挂载点检测 存在 magisk 挂载 仅 overlayfs │
│ 内存特征 用户空间可检测 难以从用户空间检测 │
│ │
└─────────────────────────────────────────────────────────────────────────┘

5.2 隐藏策略实现

// kernel/ksu/hide.c

// 对未授权进程隐藏 KernelSU 存在
static bool ksu_should_hide(struct task_struct *task)
{
 // 1. 系统应用始终隐藏
 if (ksu_is_system_uid(task_uid(task).val))
 return true;

 // 2. 黑名单应用隐藏
 if (ksu_is_blacklisted(task))
 return true;

 // 3. 非授权应用隐藏
 if (!ksu_is_allowed(task))
 return true;

 return false;
}

// Hook open 系统调用，隐藏敏感文件
static int ksu_hide_open(struct file *file, const char __user *filename)
{
 char path[PATH_MAX];

 if (ksu_should_hide(current)) {
 if (strncpy_from_user(path, filename, PATH_MAX) > 0) {
 // 隐藏 /data/adb/ksu 目录
 if (strstr(path, "/data/adb/ksu"))
 return -ENOENT;

 // 隐藏 /proc/ksu 接口
 if (strstr(path, "/proc/ksu"))
 return -ENOENT;
 }
 }

 return 0; // 允许正常访问
}

// Hook stat 系统调用
static int ksu_hide_stat(const char __user *filename, struct stat *statbuf)
{
 if (ksu_should_hide(current)) {
 // 对敏感路径返回 ENOENT
 if (ksu_is_sensitive_path(filename))
 return -ENOENT;
 }
 return 0;
}

5.3 进程隐藏

// 从 /proc 隐藏 ksud 进程
static int ksu_hide_proc_pid(struct task_struct *task, struct task_struct *target)
{
 // 对黑名单应用隐藏 ksud
 if (ksu_should_hide(task)) {
 if (strcmp(target->comm, "ksud") == 0)
 return -ENOENT;
 }
 return 0;
}

// Hook proc_pid_readdir
static int ksu_proc_readdir_hook(struct file *file, struct dir_context *ctx)
{
 // 过滤掉 ksud 的 PID
 // ...
}

6. 与 Magisk 技术对比

6.1 Root 实现对比

方面	KernelSU	Magisk
su 实现位置	内核空间	用户空间 (magiskd)
权限提升	直接修改 cred	IPC 请求 magiskd
进程数量	无额外守护进程	magiskd 常驻
系统调用	hook prctl	正常 execve su

6.2 代码对比

Magisk su 请求流程:

// 用户空间: su 进程
int main(int argc, char **argv) {
 // 连接到 magiskd
 int fd = connect_magiskd();

 // 发送 root 请求
 write(fd, &request, sizeof(request));

 // 等待授权结果
 read(fd, &response, sizeof(response));

 if (response.granted) {
 // magiskd 会 fork 一个 root shell
 // 通过 PTY 转发
 }
}

KernelSU su 请求流程:

// 用户空间: 直接 syscall
int become_root(void) {
 // 一次 prctl 调用，内核直接处理
 return prctl(KSU_MAGIC, CMD_BECOME_ROOT, 0, 0, 0);
 // 返回后当前进程已经是 root
}

6.3 检测难度对比

// Magisk 检测方法 (相对容易)
bool detect_magisk() {
 // 检查文件
 if (access("/data/adb/magisk", F_OK) == 0) return true;
 if (access("/sbin/su", F_OK) == 0) return true;

 // 检查进程
 if (find_process("magiskd")) return true;

 // 检查属性
 char value[PROP_VALUE_MAX];
 if (__system_property_get("ro.boot.vbmeta.device_state", value) > 0) {
 if (strcmp(value, "unlocked") == 0) return true;
 }

 return false;
}

// KernelSU 检测方法 (非常困难)
bool detect_kernelsu() {
 // 尝试 prctl 探测 (KernelSU 可以针对性隐藏)
 int ret = prctl(0x4B535500, 0, 0, 0, 0);
 if (ret > 0) return true; // 但 KernelSU 可以对黑名单应用返回 -1

 // 检查内核模块 (需要 root 权限)
 // 用户空间几乎无法检测

 return false;
}

7. 安全性分析

7.1 攻击面

┌─────────────────────────────────────────────────────────────────────────┐
│ KernelSU 攻击面分析 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 攻击向量 风险等级 缓解措施 │
│ ───────────────────────────────────────────────────────────────── │
│ │
│ prctl 接口滥用 中 仅授权应用可调用 │
│ allowlist 篡改 高 内核空间存储，SELinux 保护 │
│ 内核模块漏洞 高 代码审计，安全开发 │
│ 提权漏洞利用 中 capability 最小化 │
│ Profile 注入 中 签名验证 │
│ │
└─────────────────────────────────────────────────────────────────────────┘

7.2 安全设计

// 安全检查示例

// 1. 调用者验证
static bool ksu_verify_caller(struct task_struct *task)
{
 // 检查 UID 是否在允许列表
 if (!ksu_is_allowed_uid(task_uid(task).val))
 return false;

 // 检查包签名 (通过 ksud 验证)
 if (!ksu_verify_package_signature(task))
 return false;

 // 检查 SELinux 上下文
 if (!ksu_check_selinux_context(task))
 return false;

 return true;
}

// 2. Capability 限制
static int ksu_apply_profile_caps(struct cred *cred, struct ksu_profile *profile)
{
 // 只授予 profile 中声明的 capabilities
 // 而不是默认给全部
 if (profile->capabilities) {
 cred->cap_effective = profile->cap_effective;
 cred->cap_permitted = profile->cap_permitted;
 }
 return 0;
}

// 3. 命名空间隔离
static int ksu_setup_namespace(struct ksu_profile *profile)
{
 if (profile->namespace_flags.mount_namespace)
 unshare(CLONE_NEWNS);

 if (profile->namespace_flags.pid_namespace)
 unshare(CLONE_NEWPID);

 return 0;
}

7.3 与 SELinux 集成

// SELinux 策略修改
static int ksu_patch_selinux_policy(void)
{
 // 添加 KernelSU 相关的 SELinux 规则
 // 允许授权进程执行特定操作

 const char *rules[] = {
 "allow ksu_client ksu_server:binder { call transfer }",
 "allow ksu_client shell_data_file:file { read write }",
 "allow ksu_client su:process { transition }",
 NULL
 };

 for (int i = 0; rules[i]; i++) {
 ksu_add_selinux_rule(rules[i]);
 }

 return 0;
}

KernelSU 使用指南

overkazaf@gmail.com (+5) — Fri, 26 Dec 2025 00:00:00 +0000

KernelSU 使用指南

KernelSU 是一个基于内核的 Android Root 解决方案，通过修改内核来提供 root 权限，相比 Magisk 具有更强的隐蔽性和更底层的控制能力。

1. KernelSU 简介

KernelSU 是一个运行在内核空间的 root 解决方案，它的核心理念是：

内核级 Root: 直接在内核中实现 su，而非用户空间守护进程
按需授权: 应用程序需要主动声明 root 需求，而非被动授予
高度隐蔽: 对未授权应用完全透明，检测难度极大
GKI 兼容: 支持 Android 12+ 的 Generic Kernel Image

核心特性

特性	说明
内核模块	以 LKM (Loadable Kernel Module) 形式加载
UID 0 授权	直接在内核层面提升进程权限
App Profile	细粒度的应用权限控制
模块系统	兼容 Magisk 模块 (systemless)
OverlayFS	使用 overlayfs 实现系统文件修改

2. KernelSU vs Magisk

架构对比

┌─────────────────────────────────────────────────────────────────┐
│ Magisk 架构 │
├─────────────────────────────────────────────────────────────────┤
│ App 请求 root → magiskd (守护进程) → 授权/拒绝 │
│ ↓ │
│ 用户空间实现 su │
│ ↓ │
│ 修改 boot.img/ramdisk │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│ KernelSU 架构 │
├─────────────────────────────────────────────────────────────────┤
│ App 请求 root → 内核模块直接处理 → 授权/拒绝 │
│ ↓ │
│ 内核空间实现 su │
│ ↓ │
│ 修改内核或加载内核模块 │
└─────────────────────────────────────────────────────────────────┘

详细对比

特性	KernelSU	Magisk
实现层级	内核空间	用户空间
Root 机制	内核直接授权	magiskd 守护进程
安装方式	刷入修改的内核	修改 boot.img
隐蔽性	极高 (内核级隐藏)	高 (DenyList)
检测难度	非常难	较难
模块兼容	兼容大部分 Magisk 模块	原生支持
系统要求	Android 12+ GKI	Android 5.0+
设备支持	需要对应内核	几乎所有设备

选择建议

选择 KernelSU:
- 需要更强的隐蔽性（银行/支付应用）
- 设备支持 GKI 内核
- 想要更底层的系统控制
选择 Magisk:
- 设备较旧，不支持 GKI
- 需要更广泛的模块生态
- 追求稳定和成熟的解决方案

3. 安装 KernelSU

3.1 检查设备兼容性

# 检查内核版本
adb shell uname -r
# 输出示例: 5.10.101-android13-4-00001-g123456

# 检查是否为 GKI 内核
adb shell cat /proc/version
# GKI 内核通常包含 "android" 字样

# 检查架构
adb shell getprop ro.product.cpu.abi
# 常见: arm64-v8a

3.2 安装方法

方法一：官方支持的设备（推荐）

访问 KernelSU 官方发布页
下载适合你设备的 boot.img
使用 fastboot 刷入：

# 进入 fastboot 模式
adb reboot bootloader

# 刷入 KernelSU boot 镜像
fastboot flash boot kernelsu_boot.img

# 重启设备
fastboot reboot

方法二：GKI 设备通用安装

# 1. 下载 AnyKernel3 格式的 KernelSU
# 从 GitHub Releases 下载 AnyKernel3-*.zip

# 2. 使用 TWRP 或其他 Recovery 刷入
adb reboot recovery
# 在 Recovery 中选择刷入 zip

# 或使用 fastboot boot 临时启动
fastboot boot twrp.img

方法三：自行编译内核

对于没有官方支持的设备，需要自行编译带 KernelSU 补丁的内核：

# 1. 获取设备内核源码
git clone <your-device-kernel-source>

# 2. 集成 KernelSU
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -

# 3. 编译内核
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc)

# 4. 打包并刷入

3.3 安装 KernelSU Manager

# 从 GitHub 下载最新版 Manager APK
# https://github.com/tiann/KernelSU/releases

# 安装到设备
adb install KernelSU_*.apk

4. KernelSU Manager 使用

4.1 主界面

打开 KernelSU Manager 后，主界面显示：

状态: 显示 KernelSU 是否正常工作
版本: 内核模块版本和 Manager 版本
超级用户: 管理 root 授权的应用

4.2 授权管理

KernelSU 采用主动声明模式，应用需要在 AndroidManifest.xml 中声明：

<!-- 应用声明需要 root 权限 -->
<uses-permission android:name="com.topjohnwu.magisk.permission.ROOT" />

或者使用 KernelSU 特有的声明方式：

<meta-data
 android:name="com.topjohnwu.superuser.REQUESTER"
 android:value="true" />

4.3 App Profile（应用配置文件）

KernelSU 的独特功能，允许为每个应用定义详细的权限：

{
 "name": "frida-server",
 "uid": 0,
 "gid": 0,
 "groups": [0, 1000, 1001],
 "capabilities": ["CAP_SYS_PTRACE", "CAP_DAC_OVERRIDE"],
 "context": "u:r:su:s0",
 "namespace": {
 "mnt": true,
 "pid": false
 }
}

Profile 配置项说明

字段	说明
`uid/gid`	进程的用户/组 ID
`groups`	附加组 ID 列表
`capabilities`	Linux capabilities 列表
`context`	SELinux 上下文
`namespace`	命名空间隔离设置

5. 模块系统

5.1 模块兼容性

KernelSU 兼容大部分 Magisk 模块，但有一些注意事项：

✅ 纯 systemless 修改模块
✅ 使用 OverlayFS 的模块
⚠️ 依赖 Magisk 特定 API 的模块可能不兼容
❌ 需要 Zygisk 的模块（需要额外配置）

5.2 安装模块

# 方法一：通过 Manager 安装
# 在 KernelSU Manager 中点击 "模块" → "从本地安装"

# 方法二：命令行安装
adb push module.zip /data/local/tmp/
adb shell su -c "ksud module install /data/local/tmp/module.zip"

5.3 Zygisk 支持

KernelSU 通过 ZygiskNext 提供 Zygisk 兼容：

# 1. 下载 ZygiskNext
# https://github.com/Dr-TSNG/ZygiskNext/releases

# 2. 作为 KernelSU 模块安装
adb push ZygiskNext-*.zip /data/local/tmp/
adb shell su -c "ksud module install /data/local/tmp/ZygiskNext-*.zip"

# 3. 重启设备
adb reboot

6. 与逆向工具配合使用

6.1 配合 Frida 使用

KernelSU 提供了优秀的 Frida 运行环境：

# 1. 下载 frida-server
# https://github.com/frida/frida/releases
# 选择 frida-server-*-android-arm64.xz

# 2. 推送到设备
adb push frida-server /data/local/tmp/
adb shell chmod 755 /data/local/tmp/frida-server

# 3. 使用 KernelSU 运行 (通过 su)
adb shell
su
/data/local/tmp/frida-server &

# 4. 验证运行
frida-ps -U

使用 App Profile 优化 Frida

创建专门的 Frida Profile 以获得必要权限：

# 在 /data/adb/ksu/profile/ 创建配置
cat > /data/adb/ksu/profile/frida-server.json << 'EOF'
{
 "uid": 0,
 "gid": 0,
 "groups": [0, 1000, 1001, 1002, 3001, 3002, 3003],
 "capabilities": [
 "CAP_SYS_PTRACE",
 "CAP_DAC_OVERRIDE",
 "CAP_DAC_READ_SEARCH",
 "CAP_SYS_ADMIN"
 ],
 "context": "u:r:su:s0"
}
EOF

6.2 配合 LSPosed 使用

KernelSU 可以与 LSPosed 配合使用：

# 1. 安装 ZygiskNext (如果还没安装)
ksud module install ZygiskNext.zip

# 2. 安装 LSPosed Zygisk 版本
# 从 https://github.com/LSPosed/LSPosed/releases 下载
ksud module install LSPosed-*.zip

# 3. 重启设备
reboot

6.3 隐藏 Root 检测

KernelSU 天生具有很强的隐蔽性，但某些应用仍可能检测到。配合以下模块可以增强隐藏效果：

# Shamiko - 隐藏 root 和 Zygisk
ksud module install Shamiko-*.zip

# 在 KernelSU Manager 中配置:
# 1. 启用 "隐藏超级用户授权"
# 2. 将目标应用加入黑名单

6.4 配合 eBPF 使用

KernelSU 提供了良好的内核访问能力，适合 eBPF 逆向：

# 检查 eBPF 支持
adb shell su -c "ls /sys/fs/bpf"

# 运行 bpftrace (需要 root)
adb shell su -c "bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf(\"%s %s\\n\", comm, str(args->filename)); }'"

7. 常见问题与排查

7.1 安装后无法启动

# 进入 fastboot 模式
# 长按 电源 + 音量下

# 刷回原版 boot
fastboot flash boot stock_boot.img
fastboot reboot

7.2 KernelSU 状态显示异常

# 检查内核模块是否加载
adb shell su -c "lsmod | grep kernelsu"

# 检查 ksudb 进程
adb shell su -c "ps -A | grep ksu"

# 查看内核日志
adb shell su -c "dmesg | grep -i ksu"

7.3 应用无法获得 root

# 检查应用是否在授权列表
# KernelSU Manager → 超级用户 → 检查目标应用

# 检查 SELinux 状态
adb shell getenforce
# 如果是 Enforcing，某些操作可能被阻止

# 检查应用的 Profile 设置
cat /data/adb/ksu/profile/<package_name>.json

7.4 模块安装失败

# 查看模块安装日志
adb shell su -c "cat /data/adb/ksu/log/module_install.log"

# 手动安装模块进行调试
adb shell su -c "unzip -o /path/to/module.zip -d /data/adb/modules/<module_id>"

7.5 与其他 Root 方案冲突

# KernelSU 与 Magisk 不能同时使用
# 如果之前安装了 Magisk，需要先卸载

# 检查是否存在 Magisk
adb shell ls /data/adb/magisk

# 卸载 Magisk (如果存在)
# 在 Magisk Manager 中选择 "卸载" → "完全卸载"

构建最小化 Android 系统 (RootFS) 指南

overkazaf@gmail.com (+5) — Thu, 02 Oct 2025 00:00:00 +0000

构建最小化 Android 系统 (RootFS) 指南

构建一个完整的 AOSP (Android Open Source Project) 耗时巨大且对硬件要求苛刻。而构建一个最小化的 Android RootFS (Root File System) 是一个能让我们深刻理解 Android 启动流程和核心组件的绝佳实践。其目标是创建一个仅包含最基本组件、能够引导 Linux 内核并最终启动一个交互式 Shell 的系统。

本文将指导你完成这一过程，主要使用 QEMU 作为目标平台。

最小 Android 根文件系统概述

最小 Android 根文件系统（Minimal Android RootFS）是一个被精简到最低限度的 Android 用户空间环境，仅保留运行 Native 二进制文件所必需的核心组件。与完整的 Android 系统（通常包含数 GB 的框架、应用和服务）不同，一个最小 RootFS 通常只有几十 MB：

组件	大小（约）	用途
`linker64`	~1 MB	动态链接器
`libc.so`	~1 MB	C 标准库
`libm.so` / `libdl.so`	~200 KB	数学库 / 动态加载接口
`sh` / `toybox`	~500 KB	Shell 和基础命令
`init`	~300 KB	初始化进程

为什么逆向工程师需要它

隔离的执行环境：不启动完整 Android 框架即可运行目标 SO，排除框架层干扰
可控的测试条件：精确控制环境中存在哪些库和文件，方便绕过环境检测
快速迭代：无需刷机或重启设备，修改环境后立即测试
反检测规避：APP 的反调试逻辑依赖完整环境中的特定文件和进程，在最小 RootFS 中这些检查点天然缺失
底层学习：深入理解 linker 如何加载 SO、依赖如何解析、JNI 如何初始化

典型使用场景

场景 1：分析某 APP 的加密 SO
 完整设备 → 反调试检测 → 被杀进程
 最小 RootFS → 无检测 → 自由调试

场景 2：批量调用签名函数
 Frida Hook → 依赖设备、慢
 最小 RootFS + dlopen → 脱离设备、快

核心概念与启动流程

Bootloader: 设备上电后执行的第一段代码，负责初始化硬件并加载 Linux 内核到内存。
Kernel: 内核被加载后，开始初始化各种驱动、内存管理等，然后挂载一个临时的根文件系统 (ramdisk)。
init 进程: 内核在用户空间启动的第一个进程，其 PID 为 1。它是所有其他用户空间进程的祖先。
init.rc: init 进程会解析这个配置文件，根据其中的指令执行动作，如挂载文件系统、设置系统属性、启动服务等。

我们的目标就是创建一个极简的 RootFS，其中包含 init 程序和一个能被它启动的 Shell。

最小系统的核心组件

一个能启动到 Shell 的最小 Android 系统，必须包含以下组件：

Linux Kernel: 操作系统的核心。
init: 用户空间的守护神，来自 AOSP 源码 system/core/init。
C 库: libc.so (C 标准库), libm.so (数学库)。所有原生程序都依赖它。
动态链接器: linker 或 linker64，用于加载 .so 动态库。
Shell: sh，我们的交互界面，通常由 toybox 或 toolbox 提供。
init.rc: 一个最简单的配置文件。
基本目录结构: /dev, /proc, /sys, /system/bin。

构建方法

除了后续详细讲解的"从 AOSP 源码交叉编译"方式外，还有几种常见策略：

方法一：从 AOSP 编译产物中提取

从完整 AOSP 编译后的 out/target/product/<device>/ 目录中提取所需文件：

PRODUCT_DIR=/aosp/out/target/product/generic_arm64
ROOTFS=./my_rootfs

mkdir -p $ROOTFS/{system/bin,system/lib64,dev,proc,sys,data}

# 提取核心二进制和库
cp $PRODUCT_DIR/system/bin/{linker64,toybox,sh} $ROOTFS/system/bin/
cp $PRODUCT_DIR/system/lib64/{libc.so,libm.so,libdl.so,liblog.so} $ROOTFS/system/lib64/

方法二：从现有设备提取

如果有已 Root 的设备，通过 adb 直接拉取：

ROOTFS=./my_rootfs
mkdir -p $ROOTFS/{system/bin,system/lib64}

adb pull /system/bin/linker64 $ROOTFS/system/bin/
adb pull /system/bin/toybox $ROOTFS/system/bin/
adb pull /system/lib64/libc.so $ROOTFS/system/lib64/
adb pull /system/lib64/libm.so $ROOTFS/system/lib64/
adb pull /system/lib64/libdl.so $ROOTFS/system/lib64/

方法三：从 Factory Image 解包

适用于没有设备也没有编译环境的情况。从 Google 官方下载 Factory Image，解包 system.img 后提取：

unzip image-xxx.zip
simg2img system.img system.raw.img
mkdir /mnt/android_system
sudo mount -o ro system.raw.img /mnt/android_system
cp /mnt/android_system/bin/linker64 ./my_rootfs/system/bin/
# ... 提取其他所需文件
sudo umount /mnt/android_system

关键目录结构

/ (根目录)
├── system/ # 系统分区（只读）
│ ├── bin/ # 系统二进制 (linker64, sh, toybox)
│ ├── lib64/ # 64位系统共享库
│ └── lib/ # 32位系统共享库
├── vendor/ # 厂商分区（硬件相关库）
│ ├── lib64/ # 厂商64位库
│ └── lib/ # 厂商32位库
├── data/ # 用户数据分区（可读写）
│ ├── app/ # 已安装应用
│ └── local/tmp/ # 临时文件（逆向常用）
├── proc/ # 进程信息（虚拟文件系统）
├── sys/ # 内核参数（虚拟文件系统）
├── dev/ # 设备节点 (null, zero, urandom, pts/)
└── init.rc # 初始化配置

各目录在最小 RootFS 中的优先级：

目录	优先级	说明
`/system/bin/`	必需	必须包含 `linker64` 和 `sh`
`/system/lib64/`	必需	必须包含 `libc.so`、`libm.so`、`libdl.so`
`/proc/`	必需	需挂载 procfs，很多程序读取 `/proc/self/maps`
`/dev/`	必需	需挂载 tmpfs 并创建基础设备节点
`/sys/`	推荐	部分程序检测 sysfs
`/data/local/tmp/`	推荐	常用的工作目录
`/vendor/`	可选	仅当目标 SO 依赖厂商库时需要

构建步骤详解

Step 1: 准备环境与工具链

你需要一个 Linux 环境（如 Ubuntu）和用于交叉编译的工具链。最简单的方法是从 AOSP 预编译库中获取。

# Download AOSP prebuilt aarch64 (ARM64) Toolchain
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9

# Add Toolchain Path to Environment variables
export PATH=$(pwd)/aarch64-linux-android-4.9/bin:$PATH
export CROSS_COMPILE=aarch64-linux-android-

Step 2: 获取并编译 Linux 内核

git clone https://android.googlesource.com/kernel/common.git
cd common

# Switch to a Stable branch
git checkout android-xxxx

# 配置内核
export ARCH=arm64
make defconfig

# 编译内核
make -j$(nproc)

# Compile Success. After this, Image.gz will be generated in arch/arm64/boot/ directory

Step 3: 构建最小化 RootFS

mkdir -p my_rootfs/{dev,proc,sys,system/bin,system/lib64}
cd my_rootfs

这一步比较复杂，因为需要从完整的 AOSP 源码中单独编译。一个简化的方法是直接从一个现有的 Android 系统或 AOSP 编译产物中提取这些预编译好的二进制文件。

从 AOSP 编译产物 out/target/product/<device>/system/ 中找到以下文件：
- bin/linker64 -> 复制到 my_rootfs/system/bin/
- bin/init -> 复制到 my_rootfs/
- bin/toybox -> 复制到 my_rootfs/system/bin/
- lib64/libc.so, lib64/libm.so -> 复制到 my_rootfs/system/lib64/
为 toybox 创建各种命令的软链接：

cd my_rootfs/system/bin
for cmd in $(./toybox); do
 ln -s toybox $cmd
done
cd ../../

在 my_rootfs/ 目录下创建一个 init.rc 文件，内容如下：

# init.rc for minimal android

on early-init
 mount tmpfs tmpfs /dev
 mkdir /dev/pts
 mount devpts devpts /dev/pts
 mount proc proc /proc
 mount sysfs sysfs /sys

on init
 export PATH /system/bin
 export LD_LIBRARY_PATH /system/lib64

on post-fs
 # In a real system, we would mount /data, /cache, etc.
 # Here we just start the shell.

service shell /system/bin/sh
 class core
 console
 disabled
 user shell
 group shell
 seclabel u:r:shell:s0

on property:sys.boot_completed=1
 start shell

Step 4: 打包并运行

打包 RootFS: 我们需要将 my_rootfs 目录打包成一个 cpio 归档，并用 gzip 压缩，作为内核的 initramfs。
```
cd my_rootfs
find . | cpio -o -H newc | gzip > ../rootfs.cpio.gz
cd ..
```

运行 QEMU: 确保 common/arch/arm64/boot/Image.gz 和 rootfs.cpio.gz 在当前目录下。

qemu-system-aarch64 -M virt -cpu cortex-a57 -m 2048 -kernel common/arch/arm64/boot/Image.gz -initrd rootfs.cpio.gz -nographic -append "console=ttyAMA0"

Linker 与动态库

Android 的动态链接机制是理解和运用最小 RootFS 的核心。与标准 Linux 使用 ld-linux.so 不同，Android 使用自己的 linker（32位）或 linker64（64位）。

linker 的工作流程

Kernel 加载 ELF → 读取 PT_INTERP → 找到 /system/bin/linker64
 ↓
linker64: 解析 PT_LOAD 段 → 映射到内存
 ↓
解析 DT_NEEDED → 递归加载所有依赖库
 ↓
处理重定位（GOT/PLT 表） → 调用 .init_array → 跳转入口点

LD_LIBRARY_PATH 与库搜索

# linker 搜索 SO 的顺序：
# 1. DT_RUNPATH (编译时嵌入 ELF)
# 2. LD_LIBRARY_PATH 环境变量
# 3. 默认路径 (/system/lib64 等)

export LD_LIBRARY_PATH=/system/lib64:/vendor/lib64:/data/local/tmp

# 查看 SO 的依赖
readelf -d target.so | grep NEEDED

在最小环境中手动加载 SO

// loader.c - 通用 SO 加载器
#include <stdio.h>
#include <dlfcn.h>

int main(int argc, char *argv[]) {
 if (argc < 3) {
 printf("Usage: %s <so_path> <func_name>\n", argv[0]);
 return 1;
 }
 void *handle = dlopen(argv[1], RTLD_NOW);
 if (!handle) { printf("dlopen: %s\n", dlerror()); return 1; }

 void *func = dlsym(handle, argv[2]);
 if (!func) { printf("dlsym: %s\n", dlerror()); dlclose(handle); return 1; }

 printf("[+] %s @ %p\n", argv[2], func);
 int (*f)(void) = (int (*)(void))func;
 printf("[+] Result: %d\n", f());
 dlclose(handle);
 return 0;
}

# 使用 NDK 交叉编译
$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android30-clang \
 -o loader loader.c -ldl
cp loader my_rootfs/system/bin/

常见 linker 错误

错误信息	原因	解决方法
`CANNOT FIND library "libxxx.so"`	依赖库不在搜索路径中	复制到 `/system/lib64/` 或设置 `LD_LIBRARY_PATH`
`has text relocations`	文本重定位（6.0+ 禁止）	用 `-fPIC` 重编译或用旧版 linker
`cannot locate symbol "xxx"`	缺少符号定义	检查依赖库或提供 stub 实现

在 chroot 环境中运行

在已 Root 的 Android 设备上，chroot 是使用最小 RootFS 最直接的方式。

设置与进入

adb push my_rootfs /data/local/tmp/rootfs
adb shell
su

ROOTFS=/data/local/tmp/rootfs

# 挂载虚拟文件系统
mount -t proc proc $ROOTFS/proc
mount -t sysfs sysfs $ROOTFS/sys
mount -t tmpfs tmpfs $ROOTFS/dev
mknod $ROOTFS/dev/null c 1 3
mknod $ROOTFS/dev/zero c 1 5
mknod $ROOTFS/dev/urandom c 1 9
mkdir -p $ROOTFS/dev/pts
mount -o bind /dev/pts $ROOTFS/dev/pts

# 进入 chroot
chroot $ROOTFS /system/bin/sh

Bind Mount 映射目标文件

通过 bind mount 将设备上的目录映射到 chroot 环境中，无需复制文件：

# 映射目标 APP 的库目录
mkdir -p $ROOTFS/data/app_libs
mount -o bind /data/app/com.target.app/lib/arm64 $ROOTFS/data/app_libs

# 映射 vendor 库（如果目标 SO 依赖厂商库）
mkdir -p $ROOTFS/vendor/lib64
mount -o bind /vendor/lib64 $ROOTFS/vendor/lib64

# 进入后设置路径
chroot $ROOTFS /system/bin/sh
export LD_LIBRARY_PATH=/system/lib64:/vendor/lib64:/data/app_libs
/system/bin/loader /data/app_libs/libtarget.so targetFunction

退出和清理

exit
# 按反序卸载
umount $ROOTFS/dev/pts
umount $ROOTFS/dev
umount $ROOTFS/proc
umount $ROOTFS/sys
umount $ROOTFS/vendor/lib64 2>/dev/null
umount $ROOTFS/data/app_libs 2>/dev/null

Docker Android 环境

Docker 提供了在 PC 上运行最小 Android 环境的便捷方式，配合 QEMU 用户态模拟可在 x86 上运行 ARM 二进制。

Dockerfile 示例

FROM ubuntu:22.04

RUN apt-get update && apt-get install -y \
 qemu-user-static binfmt-support \
 && rm -rf /var/lib/apt/lists/*

RUN update-binfmts --enable qemu-aarch64
RUN mkdir -p /android/{system/bin,system/lib64,data/local/tmp}

COPY rootfs/system/bin/ /android/system/bin/
COPY rootfs/system/lib64/ /android/system/lib64/

ENV LD_LIBRARY_PATH=/android/system/lib64
ENV PATH=/android/system/bin:$PATH
WORKDIR /android/data/local/tmp

构建和使用

docker build -t android-rootfs .

# 运行容器，挂载目标库目录
docker run -it --rm \
 -v $(pwd)/target_libs:/android/data/local/tmp/libs \
 android-rootfs \
 qemu-aarch64-static -L /android /android/system/bin/sh

# 在容器中加载目标 SO
export LD_LIBRARY_PATH=/android/system/lib64:/android/data/local/tmp/libs
qemu-aarch64-static -L /android /android/system/bin/loader \
 /android/data/local/tmp/libs/libtarget.so targetFunction

方面	说明
可复现性	环境封装在镜像中，团队共享一致的分析环境
无需设备	在 x86 PC 上即可运行 ARM64 二进制
性能	QEMU 用户态模拟比硬件慢 5-10 倍
JNI 限制	无法提供真实的 JNI 环境（没有 ART）

proot 方案

proot 是无需 root 权限的 chroot 替代方案，通过 ptrace 拦截和重写文件路径相关的系统调用来模拟根目录切换。

基本使用

# 推送 proot 和 RootFS 到设备（无需 root）
adb push proot-aarch64 /data/local/tmp/proot
adb push my_rootfs /data/local/tmp/rootfs
adb shell chmod +x /data/local/tmp/proot

adb shell
cd /data/local/tmp

# 进入环境（绑定必要的虚拟文件系统）
./proot -r ./rootfs -b /proc -b /dev -b /sys /system/bin/sh

# 绑定目标 APP 的 SO 目录
./proot -r ./rootfs \
 -b /proc -b /dev \
 -b /data/app/com.target.app/lib/arm64:/data/libs \
 /system/bin/sh

proot 的局限性

限制	说明
性能开销	`ptrace` 拦截每个系统调用，性能损失约 10-30%
兼容性	部分系统调用无法完美拦截
SELinux	在 enforcing 模式下可能受限
Android 限制	Android 10+ 限制了 `ptrace` 的使用范围

提示：设备已 Root 时优先使用 chroot；只在无法获得 Root 权限时使用 proot。

实战：在最小环境中运行 SO

💡 思路一句话: 当你需要脱离 Android 设备运行 SO（如 CI/CD 中自动化调用签名函数）— 用 Docker 搭建最小 Android 根文件系统 + linker + libc，就能在服务器上直接执行 SO 中的函数。

以下是完整的端到端示例：在最小 RootFS 中加载并调用目标 SO 的 Native 函数。

提取目标 SO 及其依赖

# 获取目标 SO 并查看依赖
adb pull /data/app/com.example.target/lib/arm64/libtarget.so ./
readelf -d libtarget.so | grep NEEDED
# (NEEDED) Shared library: [libc.so]
# (NEEDED) Shared library: [libm.so]
# (NEEDED) Shared library: [liblog.so]
# (NEEDED) Shared library: [libz.so]

# 拉取所有依赖库
for lib in libc.so libm.so liblog.so libz.so libdl.so; do
 adb pull /system/lib64/$lib ./rootfs/system/lib64/
done

编写调用程序并部署

// call_target.c
#include <stdio.h>
#include <string.h>
#include <dlfcn.h>

int main() {
 void *handle = dlopen("/data/local/tmp/libtarget.so", RTLD_NOW);
 if (!handle) { fprintf(stderr, "[-] %s\n", dlerror()); return 1; }

 typedef int (*sign_func_t)(const char *, int);
 sign_func_t do_sign = (sign_func_t)dlsym(handle, "do_sign");
 if (!do_sign) { fprintf(stderr, "[-] %s\n", dlerror()); return 1; }

 const char *input = "hello_reverse";
 int result = do_sign(input, strlen(input));
 printf("[+] do_sign(\"%s\") = 0x%x\n", input, result);

 dlclose(handle);
 return 0;
}

# 编译并部署
NDK_CC=$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android30-clang
$NDK_CC -o call_target call_target.c -ldl -pie

adb push call_target /data/local/tmp/rootfs/system/bin/
adb push libtarget.so /data/local/tmp/rootfs/data/local/tmp/

在 chroot 中执行

adb shell
su
ROOTFS=/data/local/tmp/rootfs
mount -t proc proc $ROOTFS/proc
mount -t tmpfs tmpfs $ROOTFS/dev
mknod $ROOTFS/dev/null c 1 3
mknod $ROOTFS/dev/urandom c 1 9

chroot $ROOTFS /system/bin/sh -c '
 export LD_LIBRARY_PATH=/system/lib64
 /system/bin/call_target
'
# [+] do_sign("hello_reverse") = 0xa3f2b1c0

常见问题排查

# 缺少依赖库 → 从设备拉取
adb pull /system/lib64/libxxx.so $ROOTFS/system/lib64/

# .init_array 崩溃 → 开启调试日志
export LD_DEBUG=all
/system/bin/call_target 2>&1 | head -100

# JNI_OnLoad 需要 JNIEnv → 构造 fake JNIEnv 或 patch 掉 JNI_OnLoad

与 unidbg 对比

最小 RootFS 和 unidbg 都能脱离完整 Android 环境运行 SO 函数，但原理和适用场景有显著差异。

特性	最小 RootFS	unidbg
运行方式	真实 ARM 硬件 / QEMU 全系统模拟	Unicorn 指令级模拟
linker	Android 原生 linker	自行实现的 ELF 加载器
系统调用	真实内核处理	手动 Mock
JNI 支持	需自行构造	内置完整 JNI 模拟
运行平台	ARM 设备 / QEMU	任意 PC（Java/Python）
性能	接近原生（设备）/ 中等（QEMU）	较慢（指令模拟）
调试	GDB、strace 等标准工具	内置 Trace、寄存器查看
环境复杂度	需要准备文件系统	开箱即用

选择建议

纯 Native 函数 + 有 ARM 设备 → 最小 RootFS + chroot（性能最优）
需要 JNI 环境或复杂 Java 回调 → unidbg（JNI Mock 更成熟）
批量自动化调用 → unidbg（Java/Python 集成方便）
无 ARM 设备 → unidbg 或 Docker + QEMU

互补使用策略

在实际逆向项目中，两者往往配合使用：

初始分析：unidbg 快速验证函数调用，确认入参和返回值格式
深度调试：最小 RootFS 中使用 GDB 调试崩溃和逻辑问题
自动化：将可用的调用封装到 unidbg，批量生成签名或解密数据
对抗升级：当 unidbg 的 Mock 无法满足需求时，切换到最小 RootFS 获得更真实的环境

从 Shell 到 Zygote：下一步是什么？

我们已经有了一个最小的 Linux 环境，但它还不是"Android"。要让它成为 Android，还需要以下关键步骤：

启动 servicemanager: 编译并运行它，它是 Android Binder IPC 机制的核心。
启动 Zygote: 编译 app_process 并通过 init.rc 启动它。Zygote 会预加载 Android 框架的核心类 (framework.jar) 并监听一个 socket，等待孵化新的 App 进程。
启动 system_server: Zygote 启动的第一个 Java 进程，它会创建所有的 Android 系统服务 (AMS, WMS, PMS 等)。

完成这些后，系统才能真正地运行 Android 应用。但这已经超出了"最小化 RootFS"的范畴，进入了完整的系统移植和开发领域。

开源实现：mini_rootfs

基于本文介绍的构建技术，我实现了一个精简的开源项目：mini_rootfs

该项目演示了最小化rootfs环境下的动态库加载机制，提供两种实现方式：

Android方式: 使用系统内置 dlopen/dlsym API 进行动态库加载
Linux方式: 从头实现自定义ELF加载器，模拟Android linker架构
ELF解析: 包含完整的ELF文件解析、内存映射、符号解析、重定位处理
教育导向: 深入理解操作系统如何加载和执行动态链接的二进制文件

如果你对最小化 RootFS 环境下的动态链接机制感兴趣，欢迎参考该项目的实现，也欢迎贡献代码。

Magisk 与 LSPosed 技术原理

overkazaf@gmail.com (+5) — Thu, 25 Sep 2025 00:00:00 +0000

Magisk 与 LSPosed 技术原理

Magisk 和 LSPosed 是 Android 平台上最流行的 Root 和 Hook 解决方案。本文深入分析其技术实现原理，帮助理解现代 Android 系统修改技术的核心机制。

1. 技术架构总览

┌─────────────────────────────────────────────────────────────────────────┐
│ Android 系统修改技术栈 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ 用户层 (User Space) │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ LSPosed │ │ 模块 App │ │ 目标 App │ │ │
│ │ │ Manager │ │ (Xposed │ │ (被 Hook) │ │ │
│ │ │ │ │ Module) │ │ │ │ │
│ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │
│ │ │ │ │ │ │
│ │ └────────────────┼────────────────┘ │ │
│ │ │ │ │
│ │ ┌───────────┴───────────┐ │ │
│ │ │ LSPosed Core │ │ │
│ │ │ (libxposed_art.so) │ │ │
│ │ │ - ART Hook │ │ │
│ │ │ - 方法替换 │ │ │
│ │ └───────────┬───────────┘ │ │
│ │ │ │ │
│ └──────────────────────────┼────────────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────┼────────────────────────────────────┐ │
│ │ ┌───────────┴───────────┐ │ │
│ │ │ Zygisk │ │ │
│ │ │ (Magisk 注入机制) │ │ │
│ │ │ - 注入 Zygote │ │ │
│ │ │ - 加载模块 │ │ │
│ │ └───────────┬───────────┘ │ │
│ │ │ │ │
│ │ ┌───────────┴───────────┐ │ │
│ │ │ Magisk │ │ │
│ │ │ - Systemless Root │ │ │
│ │ │ - MagiskSU │ │ │
│ │ │ - MagiskHide/ │ │ │
│ │ │ DenyList │ │ │
│ │ └───────────┬───────────┘ │ │
│ │ │ │ │
│ │ 内核层 (Kernel) │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ Boot 阶段 │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Boot.img │ │ Magisk 补丁 │ │ ramdisk │ │ │
│ │ │ (原始) │──►│ 处理 │──►│ (修改后) │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ └───────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘

2. 框架演进历史

理解 LSPosed，需要先理清 Xposed 框架的演进历史：

Xposed (元祖) ──► EdXposed (过渡) ──► LSPosed (现代标准)
 │ │ │
 │ │ │
 ▼ ▼ ▼
替换 app_process Riru 注入 Zygote Zygisk/Riru 注入
 (修改 /system) (Systemless) (Magisk 生态)

2.1 Xposed 原版 (2012-2018)

Xposed 是由 rovo89 开发的 Android Hook 框架，开创了 Java 层方法 Hook 的先河。

核心特点：

特性	说明
实现方式	替换 `/system/bin/app_process`
Root 方式	需要传统 Root (修改 /system)
支持版本	Android 4.0 - 8.x (Dalvik/ART)
注入范围	全局注入所有进程
维护状态	2018 年停止更新

技术原理：

/**
 * Xposed 原版通过替换 app_process 实现全局注入
 *
 * 原始启动流程:
 * init → zygote (app_process) → fork → App
 *
 * Xposed 修改后:
 * init → zygote (app_process_xposed) → XposedBridge 加载 → fork → App
 */

// app_process 被替换为 Xposed 修改版
// 在 ZygoteInit 阶段加载 XposedBridge.jar
// 所有 fork 出的 App 都继承了 Xposed 的 Hook 能力

致命缺陷：

修改 /system 分区，无法通过 SafetyNet/Play Integrity
全局注入导致系统卡顿、耗电
兼容性差，不支持新版 Android

2.2 EdXposed 过渡期 (2018-2020)

EdXposed (Elder Xposed) 是 Xposed 的社区接力项目，解决了原版 Xposed 的一些问题。

核心改进：

特性	Xposed 原版	EdXposed
Root 方式	修改 /system	基于 Magisk
注入方式	替换 app_process	Riru 注入
支持版本	≤ Android 8	Android 8-11
作用域	全局	部分支持白名单

EdXposed 架构：

┌─────────────────────────────────────────────────────────────┐
│ EdXposed 架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ │
│ │ EdXposed Manager│ ←── 管理模块、配置 │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ EdXposed Core │ ←── libxposed_art.so (ART Hook) │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ Riru │ ←── Zygote 注入框架 │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ Magisk │ ←── Systemless Root 基础 │
│ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘

2.3 Riru 注入框架

Riru 是一个通用的 Zygote 注入框架，允许模块在 Zygote 进程中运行代码。

核心原理：利用 Android 的 native bridge 机制注入 Zygote。

/**
 * Riru 注入原理
 *
 * Android 的 native bridge 用于运行非原生架构的代码
 * (例如在 ARM64 设备上运行 x86 应用)
 *
 * Riru 劫持了这个机制:
 */

// 1. Magisk 模块将 libriru.so 放入指定位置
// /system/lib64/libriruloader.so

// 2. 修改系统属性
// ro.dalvik.vm.native.bridge=libriruloader.so

// 3. Zygote 启动时加载 native bridge
// 实际上加载的是 Riru

// 4. Riru 加载所有 Riru 模块
void riru_init() {
 // 读取 /data/adb/riru/modules/ 目录
 // 加载每个模块的 .so 文件
 for (auto& module : riru_modules) {
 dlopen(module.path, RTLD_NOW);
 }
}

// 5. 模块可以 Hook Zygote 的关键函数
// 如 nativeForkAndSpecialize, nativeSpecializeAppProcess

Riru 模块结构：

/data/adb/riru/modules/
└── edxposed/
 ├── lib/
 │ ├── arm64-v8a/
 │ │ └── libriru_edxposed.so
 │ └── armeabi-v7a/
 │ └── libriru_edxposed.so
 └── module.prop

Riru API (模块开发)：

// Riru 模块入口
extern "C" void* init(void* handle) {
 // 注册回调
 return riruInit(handle, riruApiVersion, &riruModuleInfo);
}

// nativeForkAndSpecialize 前回调
extern "C" void nativeForkAndSpecializePre(
 JNIEnv *env, jclass clazz, jint uid, jint gid,
 jintArray gids, jint runtimeFlags, ...
) {
 // 在 fork 前执行
 // 可以修改参数
}

// nativeForkAndSpecialize 后回调
extern "C" void nativeForkAndSpecializePost(
 JNIEnv *env, jclass clazz, jint result
) {
 if (result == 0) {
 // 子进程 (新 App)
 // 执行 Hook 逻辑
 }
}

2.4 Zygisk 注入框架

Zygisk 是 Magisk v24+ 引入的官方 Zygote 注入机制，作为 Riru 的替代方案。

Zygisk vs Riru：

特性	Riru	Zygisk
维护者	第三方	Magisk 官方
注入方式	Native Bridge 劫持	直接修补 app_process
隐藏能力	依赖额外模块	内置 DenyList
稳定性	良好	更好
模块兼容	Riru 模块格式	Zygisk 模块格式
当前状态	停止维护	活跃开发

Zygisk 核心原理：

/**
 * Zygisk 直接修补 app_process (在内存中)
 * 比 Riru 的 native bridge 劫持更优雅
 */

// 1. Magisk 在 post-fs-data 阶段
// 将 app_process32/64 替换为修改版

// 2. 修改版 app_process 在 main() 开始时
// 加载 libzygisk.so

// 3. libzygisk.so Hook Zygote 的 fork 函数
void* zygisk_loader(void*) {
 // 加载 Zygisk 核心
 void* handle = dlopen("/data/adb/magisk/zygisk/libzygisk.so", RTLD_NOW);

 // 初始化
 auto entry = dlsym(handle, "zygisk_init");
 ((void(*)())entry)();

 return nullptr;
}

// 4. Zygisk 模块 API
struct ZygiskModule {
 // 在 App fork 前调用
 void (*preAppSpecialize)(void* args);

 // 在 App fork 后调用
 void (*postAppSpecialize)(const char* process_name);

 // 在系统服务 fork 前调用
 void (*preServerSpecialize)(void* args);

 // 在系统服务 fork 后调用
 void (*postServerSpecialize)();
};

Zygisk 模块结构：

/data/adb/modules/lsposed/
├── module.prop
├── post-fs-data.sh
├── service.sh
└── zygisk/
 ├── arm64-v8a.so # 64位模块
 ├── armeabi-v7a.so # 32位模块
 └── unloaded # 控制卸载行为的标记

Zygisk 模块开发：

// Zygisk 模块示例
#include <zygisk.hpp>

class MyModule : public zygisk::ModuleBase {
public:
 void onLoad(zygisk::Api* api, JNIEnv* env) override {
 this->api = api;
 this->env = env;
 }

 void preAppSpecialize(zygisk::AppSpecializeArgs* args) override {
 // 获取包名
 const char* process = env->GetStringUTFChars(args->nice_name, nullptr);

 // 判断是否需要 Hook
 if (strcmp(process, "com.target.app") == 0) {
 // 请求在 fork 后继续运行
 api->setOption(zygisk::DLCLOSE_MODULE_LIBRARY, false);
 }

 env->ReleaseStringUTFChars(args->nice_name, process);
 }

 void postAppSpecialize(const zygisk::AppSpecializeArgs* args) override {
 // fork 完成后，在目标 App 中执行 Hook
 initHooks();
 }

private:
 zygisk::Api* api;
 JNIEnv* env;
};

// 注册模块
REGISTER_ZYGISK_MODULE(MyModule)

2.5 LSPosed 现代标准 (2020-至今)

LSPosed 是目前最主流的 Xposed 实现，采用 Zygisk (或 Riru) 作为注入基础。

核心定位：

Magisk 负责 Root 权限和文件系统修改
Zygisk/Riru 负责 Zygote 注入
LSPosed 负责 Java 方法 Hook

简单说：Magisk 帮你开了门，LSPosed 帮你进去改代码。

LSPosed 关键创新：

按需注入 (Scope)：只注入勾选的目标 App
随机包名：LSPosed Manager 使用随机包名避免检测
寄生模式：可将管理器寄生到其他 App 中
Binder 通信：Manager 与 Core 通过 Binder 通信

LSPosed 启动流程：

系统启动
 │
 ▼
Magisk 启动 ──► 加载 Zygisk/Riru
 │
 ▼
Zygisk 注入 Zygote ──► 加载 LSPosed Core
 │
 ▼
App 启动请求 (fork from Zygote)
 │
 ▼
LSPosed 检查: 这个 App 在哪些模块的作用域中?
 │
 ├── 在 "微信防撤回" 作用域中 ──► 加载该模块
 │
 ├── 不在任何作用域中 ──► 不加载任何模块
 │
 ▼
App 正常运行 (仅加载必要模块)

3. Magisk 原理详解

3.1 Systemless Root 概念

Magisk 的核心创新是 Systemless Root - 在不修改 /system 分区的情况下获取 Root 权限。

┌─────────────────────────────────────────────────────────────────────────┐
│ 传统 Root vs Systemless Root │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 【传统 Root】 │
│ │
│ /system/ │
│ ├── bin/ │
│ │ └── su ◄── 直接修改 /system 分区 │
│ ├── xbin/ │
│ │ └── su │
│ └── app/ │
│ └── Superuser/ ◄── Root 管理 App │
│ │
│ 问题: │
│ - 无法通过 OTA 升级 │
│ - 无法通过 SafetyNet │
│ - 修改系统分区可能变砖 │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 【Systemless Root (Magisk)】 │
│ │
│ /system/ ◄── 完全不修改 │
│ │
│ /data/adb/magisk/ │
│ ├── magisk ◄── Magisk 二进制 │
│ ├── magiskinit │
│ ├── magiskpolicy │
│ └── busybox │
│ │
│ Boot Image 修改: │
│ boot.img │
│ └── ramdisk/ │
│ └── init ──► magiskinit ◄── 替换 init 进程 │
│ │
│ 优势: │
│ - 系统分区完整，可正常 OTA │
│ - 可绕过部分检测 │
│ - 恢复简单，刷入原始 boot.img 即可 │
│ │
└─────────────────────────────────────────────────────────────────────────┘

2.2 Magisk 启动流程

┌─────────────────────────────────────────────────────────────────────────┐
│ Magisk 启动流程 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. Bootloader 加载修补后的 boot.img │
│ │ │
│ ▼ │
│ 2. Kernel 启动，执行 ramdisk 中的 init │
│ │ (实际是 magiskinit) │
│ │ │
│ ▼ │
│ 3. magiskinit 执行初始化 │
│ ├── 解析 /system, /vendor 等分区 │
│ ├── 注入 Magisk 到 /sbin │
│ ├── 修补 sepolicy (SELinux 策略) │
│ └── 启动原始 init │
│ │ │
│ ▼ │
│ 4. 原始 init 执行系统初始化 │
│ │ │
│ ▼ │
│ 5. post-fs-data 阶段 │
│ ├── Magisk 挂载模块 │
│ ├── 执行 post-fs-data.d 脚本 │
│ └── 设置 MagiskSU 守护进程 │
│ │ │
│ ▼ │
│ 6. late_start 阶段 │
│ ├── 执行 service.d 脚本 │
│ └── Zygisk 初始化 (如果启用) │
│ │ │
│ ▼ │
│ 7. 系统完全启动，Magisk 功能就绪 │
│ │
└─────────────────────────────────────────────────────────────────────────┘

2.3 MagiskSU 实现原理

/**
 * MagiskSU 核心实现原理 (简化版)
 *
 * Magisk 的 su 实现不是传统的 SUID 二进制，
 * 而是通过 Unix Domain Socket 与守护进程通信
 */

// ==================== su 客户端 ====================

/**
 * su_client.c - su 命令的客户端实现
 */

#include <sys/socket.h>
#include <sys/un.h>

#define MAGISK_SOCKET "/dev/socket/magisk"

// su 请求结构
struct su_request {
 int uid; // 请求的 UID
 int login; // 是否使用 login shell
 int keepenv; // 是否保留环境变量
 char *shell; // 指定 shell
 char *command; // 要执行的命令
};

// su 响应
struct su_response {
 int allow; // 是否允许
 int uid; // 授权的 UID
 int gid; // 授权的 GID
};

int su_client_main(int argc, char **argv) {
 // 1. 解析命令行参数
 struct su_request req = parse_args(argc, argv);

 // 2. 连接到 Magisk 守护进程
 int sockfd = socket(AF_UNIX, SOCK_STREAM, 0);

 struct sockaddr_un addr;
 addr.sun_family = AF_UNIX;
 strcpy(addr.sun_path, MAGISK_SOCKET);

 if (connect(sockfd, (struct sockaddr*)&addr, sizeof(addr)) < 0) {
 fprintf(stderr, "Cannot connect to Magisk daemon\n");
 return 1;
 }

 // 3. 发送 su 请求
 // 包含调用者 PID、UID、请求的权限等
 send_su_request(sockfd, &req);

 // 4. 等待守护进程响应
 struct su_response resp;
 recv_su_response(sockfd, &resp);

 if (!resp.allow) {
 fprintf(stderr, "Permission denied\n");
 return 1;
 }

 // 5. 守护进程通过 socket 传递 pts (伪终端)
 int pts_fd = recv_fd(sockfd);

 // 6. 使用新的 pts 执行 shell
 // 此时已经在守护进程创建的 Root 环境中
 dup2(pts_fd, STDIN_FILENO);
 dup2(pts_fd, STDOUT_FILENO);
 dup2(pts_fd, STDERR_FILENO);

 execvp(req.shell ?: "/system/bin/sh", argv);

 return 0;
}

// ==================== su 守护进程 ====================

/**
 * su_daemon.c - Magisk 守护进程中处理 su 请求
 */

void handle_su_request(int client_fd) {
 // 1. 接收客户端信息
 struct su_request req;
 recv_su_request(client_fd, &req);

 // 2. 获取调用者信息
 struct ucred cred;
 socklen_t len = sizeof(cred);
 getsockopt(client_fd, SOL_SOCKET, SO_PEERCRED, &cred, &len);

 int caller_uid = cred.uid;
 int caller_pid = cred.pid;

 // 3. 查找调用者的应用信息
 char *pkg_name = get_package_name(caller_uid);
 char *app_name = get_app_name(caller_pid);

 // 4. 检查数据库中的授权状态
 int policy = check_su_policy(pkg_name);

 struct su_response resp;

 switch (policy) {
 case POLICY_ALLOW:
 // 已授权，直接允许
 resp.allow = 1;
 break;

 case POLICY_DENY:
 // 已拒绝
 resp.allow = 0;
 break;

 case POLICY_QUERY:
 default:
 // 需要询问用户
 resp.allow = prompt_user_for_su(pkg_name, app_name, caller_uid);

 // 记录用户选择
 save_su_policy(pkg_name, resp.allow);
 break;
 }

 // 5. 发送响应
 send_su_response(client_fd, &resp);

 if (!resp.allow) {
 close(client_fd);
 return;
 }

 // 6. 创建 Root 环境
 // fork 一个子进程，设置其权限

 int pts_master, pts_slave;
 openpty(&pts_master, &pts_slave, NULL, NULL, NULL);

 pid_t pid = fork();

 if (pid == 0) {
 // 子进程 - 将成为 Root shell

 close(pts_master);
 setsid();

 // 设置 UID/GID 为 root
 setuid(0);
 setgid(0);

 // 设置 SELinux context
 setcon("u:r:su:s0");

 // 设置环境变量
 setenv("HOME", "/data", 1);
 setenv("SHELL", "/system/bin/sh", 1);
 setenv("PATH", "/sbin:/system/bin:/system/xbin", 1);

 // 重定向 stdio 到 pts
 dup2(pts_slave, STDIN_FILENO);
 dup2(pts_slave, STDOUT_FILENO);
 dup2(pts_slave, STDERR_FILENO);

 // 执行 shell
 execlp("/system/bin/sh", "sh", NULL);

 } else {
 // 父进程 - 守护进程

 close(pts_slave);

 // 将 pts_master fd 发送给客户端
 send_fd(client_fd, pts_master);

 // 等待子进程结束
 waitpid(pid, NULL, 0);
 }
}

2.4 MagiskHide / DenyList 原理

/**
 * MagiskHide/DenyList 实现原理
 *
 * 目标: 对特定应用隐藏 Magisk 的存在
 */

// ==================== 进程隐藏 ====================

/**
 * hide_daemon.c - 隐藏守护进程
 */

#include <sys/ptrace.h>
#include <sys/mount.h>

// 需要隐藏的应用列表
struct hide_list {
 char *package_name;
 int uid;
};

// 监听 Zygote fork
void monitor_zygote() {
 // 使用 ptrace 或 inotify 监控 /proc/[zygote_pid]/task

 while (1) {
 // 检测新 fork 的进程
 pid_t new_pid = detect_new_fork();

 if (new_pid > 0) {
 // 获取进程信息
 char *cmdline = read_proc_cmdline(new_pid);
 int uid = get_process_uid(new_pid);

 // 检查是否在隐藏列表中
 if (should_hide(cmdline, uid)) {
 // 对该进程执行隐藏操作
 do_hide_process(new_pid);
 }
 }
 }
}

/**
 * 对目标进程执行隐藏
 */
void do_hide_process(pid_t pid) {
 // 1. 等待进程完成初始化
 // 使用 ptrace 或等待特定事件
 wait_for_process_init(pid);

 // 2. 卸载 Magisk 挂载的文件系统
 // 在目标进程的 mount namespace 中操作

 char ns_path[64];
 snprintf(ns_path, sizeof(ns_path), "/proc/%d/ns/mnt", pid);

 int ns_fd = open(ns_path, O_RDONLY);
 setns(ns_fd, CLONE_NEWNS);

 // 卸载 Magisk 模块挂载点
 unmount_magisk_mounts();

 // 3. 清理 /proc 中的痕迹
 // (这部分比较复杂，需要内核支持)

 // 4. 恢复原始的系统属性
 // 某些属性会暴露 Root 状态

 // 5. 让进程继续执行
 ptrace(PTRACE_DETACH, pid, NULL, NULL);
}

/**
 * 卸载 Magisk 挂载点
 */
void unmount_magisk_mounts() {
 // 读取 /proc/self/mounts
 FILE *fp = fopen("/proc/self/mounts", "r");

 char line[1024];
 while (fgets(line, sizeof(line), fp)) {
 // 查找 Magisk 相关挂载
 if (strstr(line, "magisk") ||
 strstr(line, "/sbin/.magisk") ||
 strstr(line, "/data/adb")) {

 // 提取挂载点
 char *mountpoint = parse_mountpoint(line);

 // 卸载
 umount2(mountpoint, MNT_DETACH);
 }
 }

 fclose(fp);

 // 卸载模块的 overlay 挂载
 unmount_module_overlays();
}

// ==================== Zygisk 实现 ====================

/**
 * Zygisk - Magisk 在 Zygote 中的代码注入
 *
 * Zygisk 允许模块在 App 进程启动前注入代码，
 * 是 LSPosed 等框架的基础
 */

// zygisk_loader.cpp

#include <android/dlext.h>

/**
 * Zygote 进程启动时的钩子
 * 通过修改 LD_PRELOAD 实现
 */
__attribute__((constructor))
void zygisk_init() {
 // 检测当前是否是 Zygote 进程
 if (!is_zygote_process()) {
 return;
 }

 // Hook Zygote 的关键函数
 hook_zygote_functions();

 // 加载 Zygisk 模块
 load_zygisk_modules();
}

/**
 * Hook app_process 中的 fork 函数
 */
void hook_zygote_functions() {
 // 使用 PLT Hook 或 inline hook

 // Hook nativeForkAndSpecialize
 // 这是 Zygote fork 新应用进程的入口
 void *art_handle = dlopen("libart.so", RTLD_NOW);

 void *original_fork = dlsym(art_handle, "_ZN3art..."
 "nativeForkAndSpecializeEi...");

 // 替换为我们的函数
 hook_function(original_fork, my_fork_and_specialize);
}

/**
 * 我们的 fork 处理函数
 */
int my_fork_and_specialize(
 JNIEnv *env,
 jclass clazz,
 jint uid,
 jint gid,
 jintArray gids,
 jint runtime_flags,
 jobjectArray rlimits,
 jint mount_external,
 jstring se_info,
 jstring nice_name, // 包名
 jintArray fds_to_close,
 jintArray fds_to_ignore,
 jboolean is_child_zygote,
 jstring instruction_set,
 jstring app_data_dir,
 jboolean is_top_app
) {
 // 获取包名
 const char *pkg_name = env->GetStringUTFChars(nice_name, NULL);

 // 检查是否需要对这个 App 执行操作
 bool should_hook = check_module_target(pkg_name);
 bool should_hide = check_hide_list(pkg_name);

 // 调用原始 fork
 int pid = original_fork_and_specialize(
 env, clazz, uid, gid, gids, runtime_flags,
 rlimits, mount_external, se_info, nice_name,
 fds_to_close, fds_to_ignore, is_child_zygote,
 instruction_set, app_data_dir, is_top_app
 );

 if (pid == 0) {
 // 子进程 (新 App)

 if (should_hide) {
 // 在子进程中执行隐藏
 do_unmount_in_child();
 }

 if (should_hook) {
 // 通知模块进行 Hook
 notify_modules_app_forked(pkg_name, uid);
 }
 }

 env->ReleaseStringUTFChars(nice_name, pkg_name);
 return pid;
}

3. LSPosed / Xposed 原理详解

3.1 Xposed 框架架构

┌─────────────────────────────────────────────────────────────────────────┐
│ LSPosed/Xposed 架构 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Xposed Module (APK) │ │
│ │ ┌─────────────────┐ ┌─────────────────┐ │ │
│ │ │ IXposedHookLoad │ │ XposedBridge │ │ │
│ │ │ InitPackageRes │ │ - findAndHook │ │ │
│ │ │ ZygoteInit │ │ Method │ │ │
│ │ └────────┬────────┘ └────────┬────────┘ │ │
│ │ │ │ │ │
│ └───────────┼────────────────────┼─────────────────────────────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ XposedBridge.jar │ │
│ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ │
│ │ │ XposedHelpers │ │ XC_MethodHook │ │ XC_MethodRepl │ │ │
│ │ │ - findClass │ │ - beforeHooked │ │ acement │ │ │
│ │ │ - findMethod │ │ Method │ │ │ │ │
│ │ │ - getField │ │ - afterHooked │ │ │ │ │
│ │ │ │ │ Method │ │ │ │ │
│ │ └────────┬────────┘ └────────┬────────┘ └────────┬────────┘ │ │
│ │ │ │ │ │ │
│ └───────────┼────────────────────┼────────────────────┼──────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ libxposed_art.so (Native) │ │
│ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ │
│ │ │ ART Hook │ │ Method Entry │ │ Backup/Restore │ │ │
│ │ │ - entry_point │ │ Trampoline │ │ Original │ │ │
│ │ │ replacement │ │ │ │ Method │ │ │
│ │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ ART Runtime (libart.so) │ │
│ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ │
│ │ │ ArtMethod │ │ JIT Compiler │ │ Class Linker │ │ │
│ │ │ - entry_point_ │ │ │ │ │ │ │
│ │ │ - code_item_ │ │ │ │ │ │ │
│ │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘

3.2 ART Hook 核心实现

/**
 * LSPosed ART Hook 实现原理
 *
 * 核心思想: 修改 ArtMethod 的 entry_point_from_quick_compiled_code_
 * 使方法调用跳转到我们的 trampoline 代码
 */

// ==================== ArtMethod 结构 ====================

/**
 * ART 虚拟机中的方法表示
 * (简化版，实际结构更复杂)
 */
struct ArtMethod {
 // GC 相关
 uint32_t gc_root_;

 // 声明此方法的类
 uint32_t declaring_class_;

 // 访问标志 (public, private, static 等)
 uint32_t access_flags_;

 // 方法在 DEX 文件中的索引
 uint32_t dex_method_index_;

 // 方法在 vtable 中的索引
 uint16_t method_index_;

 // 热度计数 (用于 JIT)
 uint16_t hotness_count_;

 // ========== 关键字段 ==========

 // 解释执行时使用的 DEX 字节码指针
 void *dex_code_item_offset_;

 // 快速编译代码的入口点
 // 这是 Hook 的核心目标!
 void *entry_point_from_quick_compiled_code_;

 // JNI 入口点 (native 方法)
 void *entry_point_from_jni_;
};

// ==================== Hook 实现 ====================

/**
 * art_hook.cpp - ART 方法 Hook
 */

#include <sys/mman.h>

// Trampoline 代码 (ARM64 示例)
// 这段代码会在被 Hook 的方法调用时执行
const uint8_t trampoline_template[] = {
 // 保存寄存器
 0xFD, 0x7B, 0xBF, 0xA9, // stp x29, x30, [sp, #-16]!

 // 加载 hook_info 地址到 x16
 0x50, 0x00, 0x00, 0x58, // ldr x16, #8

 // 跳转到 hook_handler
 0x00, 0x02, 0x1F, 0xD6, // br x16

 // hook_info 地址 (占位符，运行时填充)
 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};

/**
 * Hook 信息结构
 */
struct HookInfo {
 void *original_entry; // 原始入口点
 void *hook_handler; // Hook 处理函数
 void *backup_method; // 备份的原方法
 void *callback_before; // before 回调
 void *callback_after; // after 回调
 void *additional_info; // 额外信息
};

/**
 * Hook 一个 Java 方法
 */
bool hook_method(
 JNIEnv *env,
 jclass clazz,
 const char *method_name,
 const char *method_sig,
 void *before_callback,
 void *after_callback
) {
 // 1. 获取 ArtMethod 指针
 jmethodID method_id = env->GetMethodID(clazz, method_name, method_sig);
 ArtMethod *art_method = (ArtMethod *)method_id;

 // 2. 备份原始方法
 // 创建一个新的 ArtMethod 作为备份
 ArtMethod *backup = create_backup_method(art_method);

 // 3. 分配 trampoline 代码内存
 // 需要可执行权限
 void *trampoline = mmap(
 NULL,
 PAGE_SIZE,
 PROT_READ | PROT_WRITE | PROT_EXEC,
 MAP_PRIVATE | MAP_ANONYMOUS,
 -1,
 0
 );

 // 4. 创建 HookInfo
 HookInfo *hook_info = new HookInfo();
 hook_info->original_entry = art_method->entry_point_from_quick_compiled_code_;
 hook_info->hook_handler = &hook_bridge;
 hook_info->backup_method = backup;
 hook_info->callback_before = before_callback;
 hook_info->callback_after = after_callback;

 // 5. 填充 trampoline 代码
 memcpy(trampoline, trampoline_template, sizeof(trampoline_template));

 // 将 hook_info 地址写入 trampoline
 *(void **)((uint8_t *)trampoline + 16) = hook_info;

 // 6. 修改原方法的入口点
 // 指向我们的 trampoline
 art_method->entry_point_from_quick_compiled_code_ = trampoline;

 // 7. 清除可能存在的 JIT 编译缓存
 invalidate_jit_code(art_method);

 return true;
}

/**
 * Hook 桥接函数
 * 当被 Hook 的方法被调用时，这个函数会被执行
 */
extern "C" void hook_bridge(HookInfo *info, ...) {
 // 1. 获取调用参数
 // 参数通过寄存器和栈传递
 va_list args;
 va_start(args, info);

 // 2. 调用 before 回调
 if (info->callback_before) {
 ((BeforeCallback)info->callback_before)(info, args);
 }

 // 3. 调用原始方法
 // 通过备份的 ArtMethod
 void *result = call_original_method(info->backup_method, args);

 // 4. 调用 after 回调
 if (info->callback_after) {
 result = ((AfterCallback)info->callback_after)(info, args, result);
 }

 va_end(args);

 // 5. 返回结果
 return result;
}

/**
 * 调用原始方法
 */
void *call_original_method(ArtMethod *backup, va_list args) {
 // 使用备份的 ArtMethod 调用原方法

 // 获取原始入口点
 void *entry = backup->entry_point_from_quick_compiled_code_;

 // 通过函数指针调用
 // 实际实现需要处理各种调用约定
 typedef void *(*MethodEntry)(ArtMethod *, ...);
 return ((MethodEntry)entry)(backup, args);
}

3.3 XposedBridge Java 层实现

/**
 * XposedBridge.java - Xposed 框架的 Java 层核心
 */
public final class XposedBridge {

 private static final String TAG = "XposedBridge";

 // 存储所有已注册的 Hook
 private static final ConcurrentHashMap<Member, TreeSet<XC_MethodHook>>
 sHookedMethodCallbacks = new ConcurrentHashMap<>();

 /**
 * Hook 一个方法
 *
 * @param hookMethod 要 Hook 的方法
 * @param callback Hook 回调
 * @return 用于取消 Hook 的 unhook 对象
 */
 public static XC_MethodHook.Unhook hookMethod(
 Member hookMethod,
 XC_MethodHook callback
 ) {
 if (!(hookMethod instanceof Method) && !(hookMethod instanceof Constructor)) {
 throw new IllegalArgumentException("Only methods and constructors can be hooked");
 }

 // 获取或创建该方法的回调集合
 TreeSet<XC_MethodHook> callbacks = sHookedMethodCallbacks.get(hookMethod);
 if (callbacks == null) {
 callbacks = new TreeSet<>();
 sHookedMethodCallbacks.put(hookMethod, callbacks);

 // 第一次 Hook 这个方法，进行 native Hook
 hookMethodNative(hookMethod);
 }

 // 添加回调
 callbacks.add(callback);

 return callback.new Unhook(hookMethod);
 }

 /**
 * Native Hook 方法
 * 由 libxposed_art.so 实现
 */
 private static native void hookMethodNative(Member method);

 /**
 * 当被 Hook 的方法被调用时，由 native 层调用此方法
 */
 private static Object handleHookedMethod(
 Member method,
 Object thisObject,
 Object[] args
 ) throws Throwable {

 // 获取该方法的所有回调
 TreeSet<XC_MethodHook> callbacks = sHookedMethodCallbacks.get(method);
 if (callbacks == null || callbacks.isEmpty()) {
 // 没有回调，直接调用原方法
 return invokeOriginalMethod(method, thisObject, args);
 }

 // 创建方法调用参数封装
 XC_MethodHook.MethodHookParam param = new XC_MethodHook.MethodHookParam();
 param.method = method;
 param.thisObject = thisObject;
 param.args = args;

 // ========== 调用 beforeHookedMethod ==========
 for (XC_MethodHook callback : callbacks) {
 try {
 callback.beforeHookedMethod(param);
 } catch (Throwable t) {
 XposedBridge.log(t);
 }

 // 如果回调设置了返回值，跳过后续处理
 if (param.returnEarly) {
 return param.getResult();
 }
 }

 // ========== 调用原始方法 ==========
 try {
 param.setResult(invokeOriginalMethod(method, param.thisObject, param.args));
 } catch (Throwable t) {
 param.setThrowable(t);
 }

 // ========== 调用 afterHookedMethod ==========
 // 注意: 逆序调用
 for (XC_MethodHook callback : callbacks.descendingSet()) {
 try {
 callback.afterHookedMethod(param);
 } catch (Throwable t) {
 XposedBridge.log(t);
 }
 }

 // 返回结果或抛出异常
 if (param.hasThrowable()) {
 throw param.getThrowable();
 }
 return param.getResult();
 }

 /**
 * 调用原始方法
 * 由 native 层实现
 */
 private static native Object invokeOriginalMethod(
 Member method,
 Object thisObject,
 Object[] args
 ) throws Throwable;
}

/**
 * XC_MethodHook.java - 方法 Hook 回调基类
 */
public abstract class XC_MethodHook implements Comparable<XC_MethodHook> {

 // Hook 优先级
 public final int priority;

 public XC_MethodHook() {
 this.priority = PRIORITY_DEFAULT;
 }

 public XC_MethodHook(int priority) {
 this.priority = priority;
 }

 /**
 * 方法调用前的回调
 */
 protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
 // 默认空实现
 }

 /**
 * 方法调用后的回调
 */
 protected void afterHookedMethod(MethodHookParam param) throws Throwable {
 // 默认空实现
 }

 /**
 * 方法调用参数封装
 */
 public static class MethodHookParam {
 public Member method;
 public Object thisObject;
 public Object[] args;

 private Object result;
 private Throwable throwable;
 boolean returnEarly = false;

 public Object getResult() {
 return result;
 }

 public void setResult(Object result) {
 this.result = result;
 this.throwable = null;
 this.returnEarly = true;
 }

 public Throwable getThrowable() {
 return throwable;
 }

 public void setThrowable(Throwable throwable) {
 this.throwable = throwable;
 this.result = null;
 this.returnEarly = true;
 }

 public boolean hasThrowable() {
 return throwable != null;
 }

 public Object getResultOrThrowable() throws Throwable {
 if (throwable != null) throw throwable;
 return result;
 }
 }

 /**
 * 取消 Hook 的辅助类
 */
 public class Unhook {
 private final Member hookMethod;

 public Unhook(Member hookMethod) {
 this.hookMethod = hookMethod;
 }

 public void unhook() {
 TreeSet<XC_MethodHook> callbacks = sHookedMethodCallbacks.get(hookMethod);
 if (callbacks != null) {
 callbacks.remove(XC_MethodHook.this);
 }
 }
 }

 @Override
 public int compareTo(XC_MethodHook other) {
 // 按优先级排序
 return Integer.compare(this.priority, other.priority);
 }

 // 优先级常量
 public static final int PRIORITY_DEFAULT = 50;
 public static final int PRIORITY_LOWEST = -10000;
 public static final int PRIORITY_HIGHEST = 10000;
}

/**
 * XposedHelpers.java - 常用辅助方法
 */
public class XposedHelpers {

 /**
 * 查找并 Hook 方法
 */
 public static XC_MethodHook.Unhook findAndHookMethod(
 String className,
 ClassLoader classLoader,
 String methodName,
 Object... parameterTypesAndCallback
 ) {
 // 解析参数
 int paramCount = parameterTypesAndCallback.length - 1;
 Class<?>[] parameterTypes = new Class<?>[paramCount];
 for (int i = 0; i < paramCount; i++) {
 Object param = parameterTypesAndCallback[i];
 if (param instanceof Class) {
 parameterTypes[i] = (Class<?>) param;
 } else if (param instanceof String) {
 parameterTypes[i] = findClass((String) param, classLoader);
 }
 }

 XC_MethodHook callback = (XC_MethodHook) parameterTypesAndCallback[paramCount];

 // 查找类
 Class<?> clazz = findClass(className, classLoader);

 // 查找方法
 Method method = findMethodExact(clazz, methodName, parameterTypes);

 // Hook
 return XposedBridge.hookMethod(method, callback);
 }

 /**
 * 查找类
 */
 public static Class<?> findClass(String className, ClassLoader classLoader) {
 try {
 return classLoader.loadClass(className);
 } catch (ClassNotFoundException e) {
 throw new XposedHelpers.ClassNotFoundError(e);
 }
 }

 /**
 * 查找方法
 */
 public static Method findMethodExact(
 Class<?> clazz,
 String methodName,
 Class<?>... parameterTypes
 ) {
 try {
 Method method = clazz.getDeclaredMethod(methodName, parameterTypes);
 method.setAccessible(true);
 return method;
 } catch (NoSuchMethodException e) {
 throw new XposedHelpers.MethodNotFoundError(e);
 }
 }

 /**
 * 获取对象字段值
 */
 public static Object getObjectField(Object obj, String fieldName) {
 try {
 Field field = findField(obj.getClass(), fieldName);
 return field.get(obj);
 } catch (IllegalAccessException e) {
 throw new IllegalAccessError(e.getMessage());
 }
 }

 /**
 * 设置对象字段值
 */
 public static void setObjectField(Object obj, String fieldName, Object value) {
 try {
 Field field = findField(obj.getClass(), fieldName);
 field.set(obj, value);
 } catch (IllegalAccessException e) {
 throw new IllegalAccessError(e.getMessage());
 }
 }

 /**
 * 调用方法
 */
 public static Object callMethod(Object obj, String methodName, Object... args) {
 try {
 // 根据参数类型查找方法
 Class<?>[] paramTypes = new Class<?>[args.length];
 for (int i = 0; i < args.length; i++) {
 paramTypes[i] = args[i].getClass();
 }

 Method method = findMethodBestMatch(obj.getClass(), methodName, paramTypes);
 return method.invoke(obj, args);
 } catch (Exception e) {
 throw new RuntimeException(e);
 }
 }
}

3.4 Xposed 模块示例

/**
 * 一个完整的 Xposed 模块示例
 * 功能: Hook 微信发送消息，记录聊天内容
 */
package com.example.xposed.wechat;

import de.robv.android.xposed.IXposedHookLoadPackage;
import de.robv.android.xposed.XC_MethodHook;
import de.robv.android.xposed.XposedBridge;
import de.robv.android.xposed.XposedHelpers;
import de.robv.android.xposed.callbacks.XC_LoadPackage;

public class WeChatHook implements IXposedHookLoadPackage {

 private static final String TAG = "WeChatHook";
 private static final String WECHAT_PACKAGE = "com.tencent.mm";

 @Override
 public void handleLoadPackage(XC_LoadPackage.LoadPackageParam lpparam) throws Throwable {
 // 只处理微信
 if (!lpparam.packageName.equals(WECHAT_PACKAGE)) {
 return;
 }

 XposedBridge.log(TAG + ": Hooking WeChat");

 // Hook 发送消息的方法
 hookSendMessage(lpparam.classLoader);

 // Hook 接收消息的方法
 hookReceiveMessage(lpparam.classLoader);

 // Hook 登录流程
 hookLogin(lpparam.classLoader);
 }

 /**
 * Hook 发送消息
 */
 private void hookSendMessage(ClassLoader classLoader) {
 try {
 // 查找消息管理类
 // 注意: 实际类名可能被混淆，需要分析
 Class<?> msgManagerClass = XposedHelpers.findClass(
 "com.tencent.mm.modelmulti.MMSessionProcessor",
 classLoader
 );

 // Hook sendMessage 方法
 XposedHelpers.findAndHookMethod(
 msgManagerClass,
 "sendMessage",
 String.class, // 接收者
 String.class, // 消息内容
 int.class, // 消息类型
 new XC_MethodHook() {
 @Override
 protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
 String receiver = (String) param.args[0];
 String content = (String) param.args[1];
 int msgType = (int) param.args[2];

 XposedBridge.log(TAG + ": Sending message");
 XposedBridge.log(TAG + ": To: " + receiver);
 XposedBridge.log(TAG + ": Content: " + content);
 XposedBridge.log(TAG + ": Type: " + msgType);

 // 可以在这里修改消息内容
 // param.args[1] = content + " [Modified]";

 // 或者阻止发送
 // param.setResult(null);
 }

 @Override
 protected void afterHookedMethod(MethodHookParam param) throws Throwable {
 // 消息发送后的处理
 Object result = param.getResult();
 XposedBridge.log(TAG + ": Message sent, result: " + result);
 }
 }
 );

 XposedBridge.log(TAG + ": sendMessage hooked");

 } catch (Throwable t) {
 XposedBridge.log(TAG + ": Failed to hook sendMessage");
 XposedBridge.log(t);
 }
 }

 /**
 * Hook 接收消息
 */
 private void hookReceiveMessage(ClassLoader classLoader) {
 try {
 // Hook 消息数据库插入
 Class<?> sqliteClass = XposedHelpers.findClass(
 "com.tencent.mm.storage.SqliteDB",
 classLoader
 );

 XposedHelpers.findAndHookMethod(
 sqliteClass,
 "insert",
 String.class, // 表名
 String.class, // nullColumnHack
 "android.content.ContentValues",
 new XC_MethodHook() {
 @Override
 protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
 String tableName = (String) param.args[0];

 // 只关心消息表
 if (!"message".equals(tableName)) {
 return;
 }

 Object contentValues = param.args[2];

 // 提取消息内容
 String content = (String) XposedHelpers.callMethod(
 contentValues, "getAsString", "content"
 );
 String talker = (String) XposedHelpers.callMethod(
 contentValues, "getAsString", "talker"
 );

 XposedBridge.log(TAG + ": Received message");
 XposedBridge.log(TAG + ": From: " + talker);
 XposedBridge.log(TAG + ": Content: " + content);
 }
 }
 );

 XposedBridge.log(TAG + ": receiveMessage hooked");

 } catch (Throwable t) {
 XposedBridge.log(TAG + ": Failed to hook receiveMessage");
 XposedBridge.log(t);
 }
 }

 /**
 * Hook 登录流程
 */
 private void hookLogin(ClassLoader classLoader) {
 try {
 // Hook 网络请求类
 Class<?> networkClass = XposedHelpers.findClass(
 "com.tencent.mm.network.MMHttpClient",
 classLoader
 );

 XposedHelpers.findAndHookMethod(
 networkClass,
 "execute",
 "com.tencent.mm.network.MMHttpRequest",
 new XC_MethodHook() {
 @Override
 protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
 Object request = param.args[0];

 // 获取请求 URL
 String url = (String) XposedHelpers.getObjectField(request, "url");

 // 获取请求体
 byte[] body = (byte[]) XposedHelpers.getObjectField(request, "body");

 XposedBridge.log(TAG + ": HTTP Request");
 XposedBridge.log(TAG + ": URL: " + url);
 if (body != null) {
 XposedBridge.log(TAG + ": Body length: " + body.length);
 }
 }

 @Override
 protected void afterHookedMethod(MethodHookParam param) throws Throwable {
 Object response = param.getResult();

 if (response != null) {
 int statusCode = (int) XposedHelpers.getObjectField(
 response, "statusCode"
 );
 XposedBridge.log(TAG + ": HTTP Response: " + statusCode);
 }
 }
 }
 );

 XposedBridge.log(TAG + ": network hooked");

 } catch (Throwable t) {
 XposedBridge.log(TAG + ": Failed to hook network");
 XposedBridge.log(t);
 }
 }
}

4. LSPosed 与原版 Xposed 的区别

4.1 架构对比

特性	原版 Xposed	LSPosed
Root 方式	修改 /system	基于 Magisk (Systemless)
注入方式	替换 app_process	Zygisk 模块
作用范围	全局	可选择性启用
检测规避	无	支持白名单模式
Android 支持	最高 8.x	8.0 - 14+
维护状态	停止更新	活跃开发

4.2 LSPosed 作用域控制

/**
 * LSPosed 允许为每个模块指定作用域
 * 只有在作用域内的 App 才会被 Hook
 */

// LSPosed Manager 中的配置存储
// /data/adb/lspd/config/<module_package>/scope.list

// 作用域列表格式:
// com.tencent.mm # 微信
// com.tencent.mobileqq # QQ
// system # 系统框架

/**
 * LSPosed 加载模块时会检查作用域
 */
public class ModuleLoader {

 public boolean shouldLoadModule(String modulePkg, String targetPkg) {
 // 读取作用域配置
 Set<String> scope = readModuleScope(modulePkg);

 // 检查目标 App 是否在作用域内
 return scope.contains(targetPkg) || scope.contains("*");
 }

 private Set<String> readModuleScope(String modulePkg) {
 File scopeFile = new File(
 "/data/adb/lspd/config/" + modulePkg + "/scope.list"
 );

 Set<String> scope = new HashSet<>();
 try (BufferedReader reader = new BufferedReader(new FileReader(scopeFile))) {
 String line;
 while ((line = reader.readLine()) != null) {
 line = line.trim();
 if (!line.isEmpty() && !line.startsWith("#")) {
 scope.add(line);
 }
 }
 } catch (IOException e) {
 // 默认空作用域
 }

 return scope;
 }
}

5.3 按需注入机制

老版 Xposed 的致命缺点是全局注入：安装一个微信模块，Xposed 会把这个模块强行塞进系统里每一个进程（包括支付宝、系统设置、计算器）。

问题后果：

系统变慢、耗电
极易崩溃（不兼容就崩）
检测点多，容易被发现

LSPosed 的革新 - 按需注入：

/**
 * LSPosed 按需注入实现
 *
 * 流程:
 * 1. 新 App 启动 (从 Zygote fork)
 * 2. LSPosed 桩代码检查: 这个 App 是谁?
 * 3. 查询配置: 哪些模块勾选了这个 App?
 * 4. 只加载相关模块
 */
public class LSPosedModuleManager {

 // 模块作用域配置
 // /data/adb/lspd/config/<module>/scope.list
 private Map<String, Set<String>> moduleScopes = new HashMap<>();

 /**
 * 当 App fork 后调用
 */
 public void onAppForked(String packageName, int uid) {
 // 遍历所有已启用的模块
 for (ModuleInfo module : getEnabledModules()) {
 // 检查该 App 是否在模块作用域中
 if (isInScope(module.packageName, packageName)) {
 // 加载该模块
 loadModule(module, packageName);
 Log.d("LSPosed", "Loaded " + module.name + " for " + packageName);
 }
 }
 }

 private boolean isInScope(String modulePkg, String targetPkg) {
 Set<String> scope = moduleScopes.get(modulePkg);
 if (scope == null) return false;

 // 检查是否在作用域中
 // 支持通配符 "*" 表示全局
 return scope.contains(targetPkg) ||
 scope.contains("*") ||
 (targetPkg.equals("system") && scope.contains("system"));
 }
}

优势对比：

特性	原版 Xposed	LSPosed
注入范围	所有进程	仅勾选的 App
系统性能	明显下降	几乎无影响
稳定性	容易崩溃	稳定
检测难度	容易检测	更难检测

5.4 Binder 跨进程通信

LSPosed 分为两部分：

LSPosed Manager：用户看到的管理 App，负责配置模块
LSPosed Core：寄生在 Zygote 和各个 App 里的核心代码

由于它们在不同的进程，LSPosed 高度依赖 Android 的 Binder 机制进行通讯。

/**
 * LSPosed Binder 通信架构
 */

// ==================== LSPosed Manager 侧 ====================

/**
 * Manager App 通过 Binder 与 Core 通信
 */
public class LSPosedManagerService extends ILSPosedManager.Stub {

 /**
 * 获取模块列表
 */
 @Override
 public List<ModuleInfo> getModuleList() {
 // 通过 Binder 调用 Core 的服务
 return getRemoteService().getModuleList();
 }

 /**
 * 更新模块作用域
 */
 @Override
 public void updateModuleScope(String modulePkg, List<String> scope) {
 // 写入配置
 writeScope(modulePkg, scope);

 // 通知 Core 重新加载配置
 getRemoteService().reloadConfig();
 }

 /**
 * 启用/禁用模块
 */
 @Override
 public void setModuleEnabled(String modulePkg, boolean enabled) {
 // 更新模块状态
 updateModuleStatus(modulePkg, enabled);

 // 重启相关 App 才能生效
 // (或等待下次 App 启动)
 }
}

// ==================== LSPosed Core 侧 ====================

/**
 * Core 运行在 system_server 中
 * 通过隐藏的 Binder 服务与 Manager 通信
 */
public class LSPosedService extends ILSPosedService.Stub {

 /**
 * 获取激活的模块列表
 */
 @Override
 public List<ModuleInfo> getActiveModules(String targetPackage) {
 List<ModuleInfo> result = new ArrayList<>();

 for (ModuleInfo module : allModules) {
 if (module.enabled && isInScope(module, targetPackage)) {
 result.add(module);
 }
 }

 return result;
 }

 /**
 * 重新加载配置
 * Manager 修改配置后调用
 */
 @Override
 public void reloadConfig() {
 // 重新读取配置文件
 loadModuleConfigs();

 // 通知正在运行的 Hook 更新
 notifyConfigChanged();
 }
}

Binder 服务发现：

// LSPosed 使用隐藏的方式注册 Binder 服务
// 避免被其他 App 发现

// 1. Core 在 system_server 中注册服务
ServiceManager.addService("org.lsposed.daemon", mService, true, DUMP_FLAG_PRIORITY_NORMAL);

// 2. Manager 通过特殊方式获取服务
// 而不是普通的 ServiceManager.getService()
IBinder binder = new ShizukuBinderProxy().getService("org.lsposed.daemon");

6. Hook 技术选型对比

在 Android 逆向中，常用的 Hook 技术有三类：LSPosed (Xposed)、Frida、Inline Hook 框架。以下是详细对比和选型建议。

6.1 技术对比

维度	LSPosed/Xposed	Frida	Inline Hook 框架
Hook 层级	Java 方法	Java + Native	Native 函数
注入时机	App 启动时	运行时动态注入	编译时 / 运行时
持久性	永久生效	临时 (进程重启失效)	取决于实现
开发语言	Java/Kotlin	JavaScript/Python	C/C++
上手难度	简单	中等	较难
Root 需求	需要 (Magisk)	需要	取决于实现
检测难度	中等	较易检测	较难检测
适用场景	长期使用的功能模块	快速分析、动态调试	高性能、低侵入 Hook

6.2 详细对比

LSPosed/Xposed 模块

优势：

开发简单，Java API 友好
持久生效，重启后仍有效
社区生态丰富，模块众多
与 Magisk 生态集成良好

劣势：

只能 Hook Java 层方法
需要编译 APK，迭代较慢
修改后需要重启 App

适用场景：

✅ 微信防撤回、去广告等长期使用的功能
✅ 系统级功能修改
✅ 发布给其他用户使用的模块
✅ 不需要频繁修改的稳定 Hook

Frida

优势：

动态注入，即时生效
支持 Java + Native 层
脚本语言开发，迭代极快
强大的内存操作能力
适合快速分析和调试

劣势：

进程重启后需要重新注入
容易被检测 (frida-server 特征明显)
性能开销较大
部署需要 frida-server

适用场景：

✅ 逆向分析、快速验证想法
✅ 动态调试、参数监控
✅ 加密算法分析、数据抓取
✅ 一次性的分析任务

Inline Hook 框架 (Dobby/ShadowHook/bhook)

优势：

高性能，开销极小
难以检测 (无明显特征)
支持 Hook 任意函数地址
可嵌入目标 App 中

劣势：

开发难度大，需要 C/C++
调试困难
需要处理 ABI、指令集等细节

适用场景：

✅ 风控 SDK 开发
✅ 高性能监控
✅ 需要隐蔽的 Hook
✅ 嵌入式 Hook (集成到 App 中)

6.3 选型决策流程

你的需求是什么?
 │
 ├── 快速分析 App 行为
 │ └── 选择 Frida ✅
 │
 ├── 开发给自己/他人长期使用的功能
 │ └── Java 层 Hook 够用吗?
 │ ├── 是 → 选择 LSPosed ✅
 │ └── 否 → 结合 LSPosed + Native Hook
 │
 ├── 开发风控/安全 SDK
 │ └── 选择 Inline Hook (Dobby/ShadowHook) ✅
 │
 └── 需要隐蔽的 Hook
 └── 选择 Inline Hook ✅

6.4 组合使用方案

实际项目中，往往需要组合使用多种技术：

方案一：LSPosed + Frida

开发流程:
1. 用 Frida 快速分析、定位关键函数
2. 确认 Hook 点后，用 LSPosed 模块实现持久化

适用: 大多数逆向项目

方案二：LSPosed + Inline Hook

/**
 * LSPosed 模块中调用 Native Inline Hook
 */
public class MyXposedModule implements IXposedHookLoadPackage {

 @Override
 public void handleLoadPackage(XC_LoadPackage.LoadPackageParam lpparam) {
 // Java 层 Hook
 XposedHelpers.findAndHookMethod(...);

 // 加载 Native 库进行 Inline Hook
 System.loadLibrary("myhook");
 nativeInit(); // 执行 Dobby Hook
 }

 private native void nativeInit();
}

方案三：Frida + Inline Hook 定位

// 用 Frida 定位函数后，获取地址
var targetFunc = Module.findExportByName("libtarget.so", "encrypt");
console.log("encrypt address: " + targetFunc);

// 然后用 Inline Hook 框架做持久化 Hook
// Frida 脚本输出:
// encrypt address: 0x7a3b4c5d00
// 将此地址用于 Dobby Hook

6.5 性能对比

技术	Hook 安装开销	每次调用开销	内存占用
LSPosed	中	中	较大
Frida	高	高	很大
PLT Hook	低	极低	小
Inline Hook	中	低	小

性能敏感场景推荐：

高频函数 (如加密函数) → PLT Hook (bhook/xHook)
任意地址 Hook → Inline Hook (Dobby/ShadowHook)
分析调试阶段 → Frida (不在意性能)

7. 检测与对抗

7.1 常见检测方法

/**
 * App 检测 Root/Xposed 的常用方法
 */
public class RootDetection {

 /**
 * 检测 su 二进制
 */
 public boolean checkSuBinary() {
 String[] paths = {
 "/system/bin/su",
 "/system/xbin/su",
 "/sbin/su",
 "/data/local/xbin/su",
 "/data/local/bin/su",
 "/data/local/su"
 };

 for (String path : paths) {
 if (new File(path).exists()) {
 return true; // 检测到 Root
 }
 }
 return false;
 }

 /**
 * 检测 Magisk 特征
 */
 public boolean checkMagisk() {
 // 检查 Magisk 相关路径
 if (new File("/sbin/.magisk").exists()) return true;
 if (new File("/data/adb/magisk").exists()) return true;

 // 检查 Magisk 属性
 String magiskVersion = getSystemProperty("magisk.version");
 if (magiskVersion != null && !magiskVersion.isEmpty()) {
 return true;
 }

 return false;
 }

 /**
 * 检测 Xposed 框架
 */
 public boolean checkXposed() {
 // 方法1: 检查堆栈
 try {
 throw new Exception("detect");
 } catch (Exception e) {
 for (StackTraceElement element : e.getStackTrace()) {
 if (element.getClassName().contains("xposed")) {
 return true;
 }
 }
 }

 // 方法2: 检查类加载器
 try {
 ClassLoader.getSystemClassLoader().loadClass(
 "de.robv.android.xposed.XposedBridge"
 );
 return true;
 } catch (ClassNotFoundException e) {
 // 没有找到
 }

 // 方法3: 检查 native 方法特征
 // Xposed 会修改某些 native 方法的实现

 return false;
 }

 /**
 * 检测 Hook 框架 (通用)
 */
 public boolean checkHookFramework() {
 // 检查常见 Hook 框架的特征文件
 String[] hookIndicators = {
 "/data/data/de.robv.android.xposed.installer",
 "/data/data/org.lsposed.manager",
 "/data/data/com.saurik.substrate",
 "/data/local/tmp/frida-server"
 };

 for (String path : hookIndicators) {
 if (new File(path).exists()) {
 return true;
 }
 }

 // 检查内存中的 Hook 特征
 return checkNativeHooks();
 }

 /**
 * 检测 native 层 Hook
 */
 private native boolean checkNativeHooks();
}

7.2 绕过检测

/**
 * LSPosed 模块: 绕过 Root 检测
 */
public class RootHider implements IXposedHookLoadPackage {

 @Override
 public void handleLoadPackage(XC_LoadPackage.LoadPackageParam lpparam) throws Throwable {
 // Hook File.exists()
 XposedHelpers.findAndHookMethod(
 File.class,
 "exists",
 new XC_MethodHook() {
 @Override
 protected void afterHookedMethod(MethodHookParam param) throws Throwable {
 String path = ((File) param.thisObject).getAbsolutePath();

 // 隐藏 Root 相关文件
 if (isRootRelatedPath(path)) {
 param.setResult(false);
 }
 }
 }
 );

 // Hook Runtime.exec()
 XposedHelpers.findAndHookMethod(
 Runtime.class,
 "exec",
 String.class,
 new XC_MethodHook() {
 @Override
 protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
 String cmd = (String) param.args[0];

 // 阻止执行 which su, su 等命令
 if (cmd.contains("su") || cmd.contains("magisk")) {
 param.setThrowable(new IOException("Command not found"));
 }
 }
 }
 );

 // Hook System.getProperty() / Build 类
 // 修改设备指纹等

 // Hook PackageManager
 // 隐藏 Magisk/Xposed 应用
 }

 private boolean isRootRelatedPath(String path) {
 String[] patterns = {
 "su", "magisk", "supersu", "xposed", "lsposed",
 "/sbin/", "/data/adb/"
 };

 path = path.toLowerCase();
 for (String pattern : patterns) {
 if (path.contains(pattern)) {
 return true;
 }
 }
 return false;
 }
}

8. 总结

8.1 技术栈总览

技术	核心原理	主要用途
Magisk	修补 boot.img, Systemless Root	Root 权限管理、模块加载
MagiskSU	Unix Socket + 守护进程	Root 权限请求处理
Riru	Native Bridge 劫持注入 Zygote	老版 Zygote 注入框架
Zygisk	修补 app_process 注入 Zygote	官方 Zygote 注入框架
EdXposed	Riru + ART Hook	过渡期 Xposed 实现
LSPosed	Zygisk/Riru + ART Method Hook	现代 Xposed 实现
DenyList	Mount namespace 隔离	对特定 App 隐藏 Root

8.2 框架演进总结

时间线:
2012 ─── Xposed 诞生 (替换 app_process)
 │
2016 ─── Magisk 诞生 (Systemless Root)
 │
2018 ─── Xposed 停止更新
 │ EdXposed 接力 (基于 Riru)
 │
2020 ─── LSPosed 发布 (性能优化、按需注入)
 │
2021 ─── Magisk v24 引入 Zygisk
 │ Riru 逐渐被 Zygisk 取代
 │
2023 ─── Riru 官宣停止维护
 LSPosed Zygisk 版成为主流

8.3 最佳实践

逆向分析阶段：使用 Frida 快速分析、定位目标
持久化 Hook：使用 LSPosed 模块实现长期生效的功能
高性能需求：使用 Inline Hook 框架 (Dobby/ShadowHook)
隐蔽性需求：使用 Inline Hook + 代码混淆

这些技术共同构成了现代 Android 系统修改的核心基础设施，广泛应用于安全研究、应用开发调试和逆向工程领域。

推荐下一步：