夜雨聆风DexH*lper.so Anti-Frida 检测机制深度分析
概述
libDexH*lper.so 实现了多层安全检测机制，其中 5 个关键 patch 点分别对应不同的检测逻辑。只有 0x5f388 (sub_5ED80) 被 patch 后 Frida 才不会退出，因为它是唯一一个通过 TracerPid 精准识别 Frida 进程并执行 kill + _exit 的函数。本文全是Claude code 分析得来，后边继续发剩余部分。
关键结论
0x5f388 | TracerPid + Frida cmdline 匹配 | YES - 核心检测点 | |
0x57278 | |||
0x53d30 | |||
0x5f8c4 | |||
0x60ffc |
0x5f388 — sub_5ED80: TracerPid Frida 检测 (核心杀死点)
为什么 patch 这个函数 Frida 就不退出
Frida 默认模式使用 ptrace(PTRACE_ATTACH) 附加到目标进程，这会在 /proc/<pid>/status 中设置 TracerPid 字段为 Frida-server 的 PID。sub_5ED80 是唯一一个持续监控 TracerPid 并匹配 Frida 特征然后执行 kill 的函数。
线程创建入口 — sub_5EC84 (0x5EC84)
// sub_5EC84: 创建检测线程
__int64 sub_5EC84(_BYTE *a1, int a2){
// 分配参数结构体 (16 bytes)
v5 = malloc(16);
*(int*)(v5 + 4) = a2; // 存储目标 PID
*(char**)(v5 + 8) = strdup(a1); // 存储匹配模式(解密后的 Frida 特征串)
// 创建 pthread，入口为 sub_5ED80
// 失败则重试最多 30 次，每次 sleep(1)
result = pthread_create(&tid, NULL, sub_5ED80, v5);
if (result) {
retry_count = -29;
do {
sleep(1);
result = pthread_create(&tid, NULL, sub_5ED80, v5);
} while (result && ++retry_count);
}
}
核心检测逻辑 — sub_5ED80 (0x5ED80)
// sub_5ED80: Frida TracerPid 检测主循环
__int64 sub_5ED80(__int64 a1){
int target_pid = *(int*)(a1 + 4); // 目标进程 PID
char *frida_pattern = *(char**)(a1 + 8); // Frida 特征串(已解密)
// [1] 初始化 Frida 特征缓冲区
char frida_sig[512];
memset(frida_sig, 0, sizeof(frida_sig));
sub_2F5B0(frida_sig); // 解密/构造 Frida 特征字符串到 frida_sig
// frida_sig 中包含解密后的 Frida 进程特征 (如 "frida-server", "frida-agent" 等)
free(*(char**)(a1 + 8));
free(a1);
// [2] 栈上构造 /proc 路径 (避免静态字符串被搜索到)
char proc_paths[48];
// proc_paths[0..15] = "/proc/self/status" (v47[0])
// proc_paths[16..31] = "/proc/%ld/cmdline" (v47[1])
// proc_paths[32..47] = "/proc/%ld/status" (v47[2])
qmemcpy(proc_paths, "/proc/self/statu/proc/%ld/cmdlin/proc/%ld/status", 48);
// ==================== 无限检测循环 ====================
while (1) {
// [3] 构造 /proc/<pid>/status 路径并打开
char status_path[256];
snprintf(status_path, 256, "/proc/%ld/status", target_pid);
FILE *fp = fopen(status_path, "r");
if (!fp) {
// 回退到 /proc/self/status
fp = fopen("/proc/self/status", "r");
if (!fp) goto sleep_and_retry;
}
// [4] 逐行读取，查找 "State:" 行
char line[1024];
char state_key[] = "State:";
while (fgets(line, 1024, fp)) {
if (strstr(line, state_key)) break; // 找到 State: 行
}
// [5] 继续查找 "TracerPid:" 行
char tracer_key[] = "TracerPid:";
unsignedint tracer_pid = 0;
while (fgets(line, 1024, fp)) {
if (strstr(line, tracer_key)) {
// [6] 提取 TracerPid 数值
sscanf(line, "%s %d", dummy, &tracer_pid);
break;
}
}
// [7] 判断是否被 ptrace
// TracerPid == 0: 没有被追踪
// TracerPid == getpid(): 自己追踪自己(正常的反调试占坑)
if (tracer_pid == 0 || tracer_pid == getpid()) {
fclose(fp);
goto sleep_and_retry; // 无威胁，继续循环
}
// ========== 发现 Tracer！开始验证是否为 Frida ==========
// [8] 打开 /proc/<TracerPid>/cmdline (用 openat 系统调用，避免 libc hook)
char cmdline_path[256];
snprintf(cmdline_path, 256, "/proc/%ld/cmdline", tracer_pid);
int cmd_fd = syscall(__NR_openat, AT_FDCWD, cmdline_path, O_RDONLY);
if (cmd_fd < 0) {
detected = 1; // 打不开 = 可疑
goto handle_detection;
}
// [9] 打开 /proc/<TracerPid>/status (用 openat 系统调用)
char tracer_status_path[256];
snprintf(tracer_status_path, 256, "/proc/%ld/status", tracer_pid);
int status_fd = syscall(__NR_openat, AT_FDCWD, tracer_status_path, O_RDONLY);
if (status_fd < 0) {
detected = 1;
goto handle_detection;
}
// [10] 读取 tracer 的 cmdline
char cmdline_buf[1024];
memset(cmdline_buf, 0, 1024);
FILE *cmd_fp = fdopen(status_fd, "r");
if (cmd_fp && fscanf(cmd_fp, "%s", cmdline_buf)) {
// [11] 在 cmdline 中搜索 Frida 特征
// frida_sig 包含解密后的 "frida" 相关特征字符串
// 使用手动子串匹配 (非 strstr，避免被 hook)
char *match = manual_strstr(cmdline_buf, frida_sig);
detected = (match == NULL); // NULL = 未匹配 = 不是 Frida
// 注意: detected == 0 表示匹配到了 Frida 特征
}
fclose(cmd_fp);
close(status_fd);
handle_detection:
fclose(fp);
if (!detected) {
goto sleep_and_retry; // 不是 Frida，继续监控
}
// ==================== 检测到 Frida，执行终杀 ====================
// [12] 检查全局标志位 (是否启用杀进程)
if (((*global_config)[89] & 0x20) == 0 && !(*global_config)[84]) {
// [13] 直接用系统调用 kill，绕过 libc hook
syscall(__NR_kill, target_pid, SIGKILL); // 杀死目标进程
}
// [14] 反调试 hash 校验
sub_32CF0(32, 0xB6A104AF, 4095);
// [15] fork 子进程执行清理，然后退出
pid_t pid = getpid();
sub_44450(pid); // 可能是进程状态清理
_exit(3); // 直接退出，不经过 atexit handlers
sleep_and_retry:
sleep(1); // 每秒检测一次
}
}
检测流程图
pthread_create(sub_5ED80)
|
v
[无限循环 sleep(1)]
|
v
打开 /proc/<pid>/status
|
v
解析 "TracerPid:" 字段
|
+----+----+
| |
== 0 != 0 且 != getpid()
(安全) (被 ptrace!)
| |
v v
继续循环 syscall(openat, "/proc/<TracerPid>/cmdline")
|
v
读取 tracer cmdline
|
v
手动子串匹配 Frida 特征
|
+----+----+
| |
不匹配 匹配到 Frida!
(继续) |
v
syscall(kill, pid, SIGKILL) ← 杀死目标进程
|
v
_exit(3) ← 终止自身
反检测技巧
| 栈上构造字符串 | qmemcpy(proc_paths, "/proc/self/statu/proc/%ld/cmdlin...", 48) | |
| syscall 直调 | linux_eabi_syscall(__NR_openat, ...) | open() 的 Frida hook |
| syscall kill | linux_eabi_syscall(__NR_kill, pid, 9) | kill() 的 Frida hook |
| 手动字符串匹配 | strstr() | strstr 的 Frida hook |
| 解密特征串 | sub_2F5B0(frida_sig) | |
| 持续轮询 | while(1) { ... sleep(1); } | |
| pthread 重试 |
0x57278 — sub_57278: /proc/self/maps 内存映射扫描
功能
扫描进程内存映射，查找 Frida 注入的动态库。
线程创建入口 — sub_53FE4 (0x53FE4)
// 在全局标志检查后创建线程
if (!(*global_config)[83]) {
buf = malloc(128);
memset(buf, 0, 128);
memcpy(buf, param, 128);
pthread_create(&tid, NULL, sub_57278, buf); // 启动 maps 扫描线程
}
检测代码
// sub_57278: maps 扫描检测
voidsub_57278(void *arg){
char decoded_buf[128];
memcpy(decoded_buf, arg, 128);
free(arg);
sleep(2); // 延迟 2 秒等待进程稳定
// [1] 加载混淆的库名 "buvfvv0kqgq1z" (解密后可能是 Frida agent 库名)
char obfuscated_name[] = "buvfvv0kqgq1z";
uint64_t xor_key = qword_D64F8; // 解密密钥
// [2] 构造文件名 "nf.oy" (混淆: 可能解密为 "re.frida.server" 类似模式)
// w8 = 0x666E = "nf"
// w8 |= (0x2E6F << 16) = ".o"
// w9 = 0x79 = "y"
// 组合: "nf.oy" → 解密后为 Frida 相关文件名
// [3] 清空大缓冲区用于存放 maps 内容
char maps_buf[512];
memset(maps_buf, 0, sizeof(maps_buf));
// [4] 读取并扫描 /proc/self/maps
// 搜索解密后的 Frida 库特征
// 比如: "frida-agent", "frida-gadget", "linjector" 等
// [5] 设置检测标志，不直接 kill
}
为什么 patch 后不影响 Frida
此函数仅扫描 maps 并设置标志位，不直接执行 kill/_exit 即使检测到 Frida 库在 maps 中，真正的杀进程动作仍由 sub_5ED80 (0x5f388) 的 TracerPid 检测触发 Frida attach 时设置的 TracerPid 是最快被发现的信号，maps 扫描相对更慢
0x53d30 — sub_53A8C: ELF 代码段完整性校验
功能
验证 .text 段代码是否被运行时修改 (检测 inline hook)。
检测代码
// sub_53A8C: 代码完整性校验
__int64 sub_53A8C(int version, __int64 path_param, __int64 section_param){
// [1] 解析参数，获取 ELF section 信息
if (!sub_41CDC(path_param, &elf_info)) return0;
// [2] 构造 section 路径
char section_path[520];
int section_size = sub_2F220(section_param);
char *section_buf = malloc(section_size + 1);
strcpy(section_buf, section_param);
// [3] 用 syscall 打开文件 (绕过 libc hook)
int fd = syscall(__NR_openat, AT_FDCWD, section_path, O_RDONLY);
if (fd < 0) return-3;
// [4] 对版本 >= 29 (Android 10+) 进行额外的内存保护检查
if (version >= 29) {
// 获取 ELF 段的内存地址
if (sub_338A0(path_param, addr, &mem_region, 0)) {
// 确保代码段权限为 r-x (不可写)
mprotect(mem_region.start, mem_region.size, PROT_READ | PROT_EXEC);
}
}
// [5] mmap 文件到内存
void *file_map = mmap(NULL, file_size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
// [6] 使用 process_vm_readv 读取运行时内存
// syscall 270 = __NR_process_vm_readv
structioveclocal = { .iov_base = &result_buf, .iov_len = 16 };
structiovecremote = { .iov_base = runtime_addr, .iov_len = 16 };
pid_t pid = getpid();
ssize_t nread = syscall(__NR_process_vm_readv, pid, &local, 1, &remote, 1, 0);
// [7] 比较文件中的代码与运行时内存中的代码
if (nread == 16) {
if (memcmp(file_map + offset, result_buf, 16) != 0) {
// 代码被修改! (检测到 inline hook)
return1; // tampered
}
}
munmap(file_map, file_size);
return0; // clean
}
为什么 patch 后不影响 Frida
此函数检测的是代码段是否被修改 (inline hook) Frida 的 ptraceattach 不会修改 .text 段代码只有使用 Interceptor.replace()/Interceptor.attach()修改指令时才会触发Frida 刚 attach 时还没来得及 hook 任何函数，而 0x5f388 的 TracerPid 检测已经先触发了 kill
反检测技巧
syscall(__NR_openat) | open 的 hook |
syscall(__NR_process_vm_readv) | read/memcpy 的 hook |
mprotect(PROT_READ|PROT_EXEC) |
0x5f8c4 — sub_5F8C4: 线程/进程枚举检测
功能
枚举进程的线程和相关进程信息，检查是否存在 Frida 注入的线程。
调用路径
从 sub_37DA8 (主检测调度器) 直接调用 — 作为独立检测模块 从 sub_5F694 的栈保护触发 — 作为反篡改响应
sub_5F694 (调用者): /proc/self/maps 重映射保护
// sub_5F694: maps 自修复 + 线程检测触发
__int64 sub_5F694(){
unsignedint base_addr = sub_2F0F0(); // 获取 SO 基址
// [1] 获取 SO 文件路径
char so_path[256];
sub_5DEE4(1, so_path);
// [2] 打开 /proc/self/maps
FILE *fp = fopen("/proc/self/maps", "r");
char *line = malloc(2048);
// [3] 解析 maps 查找当前 SO 的内存映射范围
while (fgets(line, 2048, fp)) {
unsignedlong start, end;
sscanf(line, "%lx-%lx", &start, &end);
// 找到 SO 的映射区域
if (start == so_base_in_maps) {
remap_offset = so_base_in_maps - base_addr;
}
}
free(line);
fclose(fp);
// [4] 如果发现映射偏移，重新映射 SO 的代码段
if (remap_offset) {
int fd = open(so_path, O_RDONLY);
if (fd >= 1) {
// mmap 原始 SO 文件覆盖当前内存映射
void *new_map = mmap(remap_offset, base_addr,
PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
*new_map = 0; // 清空首字节
// 恢复为只读+可执行
mprotect(remap_offset, base_addr, PROT_READ|PROT_EXEC);
close(fd);
}
}
}
sub_5F8C4 检测代码 (简化)
// sub_5F8C4: 线程枚举检测
__int64 sub_5F8C4(__int64 a1){
int target_pid = *(int*)(a1 + 8);
int scan_mode = *(int*)(a1);
// [1] 初始化检测缓冲区
char thread_info[512];
memset(thread_info, 0, sizeof(thread_info));
// [2] 打开 /proc/<pid>/task/ 目录 (使用 opendir/readdir)
// 枚举所有线程 TID
// [3] 对每个 TID:
// - 读取 /proc/<pid>/task/<tid>/status
// - 读取 /proc/<pid>/task/<tid>/comm
// - 检查线程名是否包含 Frida 特征:
// "gmain", "gdbus", "gum-js-loop", "frida-*" 等
// [4] 读取文件内容
int fd = open(proc_path, O_RDONLY);
char buf[16];
ssize_t n = read(fd, buf, 16);
if (n >= 1) {
int tid = atoi(buf);
if (tid > 0 && tid != getpid()) {
// 检查该线程的详细信息
// 比对线程名与已知 Frida 线程特征
}
}
// [5] 字符串匹配检测
// 使用 memcmp 对比线程名
char s1[256]; // 读取到的线程名
// 与解密后的 Frida 线程名特征比较
// [6] 检测到则设置标志
// 可能触发 kill/exit (在后续检测循环中)
}
为什么 patch 后不影响 Frida
线程枚举需要遍历 /proc/<pid>/task/下所有 TID，速度较慢0x5f388 的 TracerPid 检测是 O(1) 复杂度 (直接读一个字段)，执行速度远快于线程枚举 Frida attach 的瞬间 TracerPid 就会被设置，0x5f388 在下一次 sleep(1) 循环就能捕获 线程枚举此时可能还在初始化阶段，尚未完成扫描
0x60ffc — sub_60B70: APK Signing Block 签名校验
功能
验证 APK 签名块完整性，防止重打包。与 Frida 检测无关。
调用链
sub_605D8 (APK 文件解析)
→ sub_60B70 (签名块数据处理)
sub_60894 (文件路径白名单校验)
→ sub_60B70 (签名数据验证)
sub_605D8: APK Signing Block 解析
// sub_605D8: 解析 APK 签名块
__int64 sub_605D8(unsignedint fd, _OWORD *v2_sig, _OWORD *v3_sig, _OWORD *v4_sig){
structstatst;
fstat(fd, &st);
size_t file_size = st.st_size;
// [1] mmap APK 文件
void *file_map = mmap(NULL, file_size, PROT_READ, MAP_PRIVATE, fd, 0);
// [2] 定位 End of Central Directory (ZIP 尾部)
// 检查魔数: 0x06054B50 (PK\x05\x06)
if (*(uint32_t*)(file_map + file_size - 22) != 0x06054B50)
goto fail;
// [3] 定位 APK Signing Block
// 检查魔数: "APK Sig Block 42"
uint64_t sig_block_offset = ...;
if (memcmp(sig_block_ptr - 16, "APK Sig Block 42", 16) != 0)
goto fail;
// [4] 解析签名块中的条目
while (entry < sig_block_end) {
uint32_t id = entry->id;
switch (id) {
case0xF05368C0: // (-262969152) V2 签名
sub_60B70(entry->data, v3_sig); // 处理 V2 签名数据
break;
case0x1B93AD61: // (462663009) V3 签名
sub_60B70(entry->data, v4_sig); // 处理 V3 签名数据
break;
case0x7109871A: // (1896449818) V1 签名
sub_60B70(entry->data, v2_sig); // 处理 V1 签名数据
break;
}
}
munmap(file_map, file_size);
}
sub_60894: 文件路径安全校验
// sub_60894: 检查文件路径是否在白名单内
__int64 sub_60894(constchar *path, int fd){
// 白名单路径前缀:
char whitelist_1[] = "/data/data/";
char whitelist_2[] = "/data/user/";
char whitelist_3[] = "/storage/";
char whitelist_4[] = "/sdcard";
// 逐一匹配路径前缀
if (starts_with(path, whitelist_1)) return0; // 安全
if (starts_with(path, whitelist_2)) return0; // 安全
if (starts_with(path, whitelist_3)) return0; // 安全
if (starts_with(path, whitelist_4)) return0; // 安全
// 非白名单路径，检查文件 UID
structstatst;
fstat(fd, &st);
int expected_uid = get_app_uid();
// UID 2000 = shell (adb)，expected_uid = app UID
if (st.st_uid != 2000 && st.st_uid != expected_uid) {
return1; // 可疑文件！
}
return0;
}
sub_60B70: NEON 加速签名数据处理
// sub_60B70: 使用 ARM NEON 指令处理签名块数据
// 大量 NEON 向量运算 (uint16x4_t, int8x16_t, int32x4_t)
// 用于高效的数据解析和 hash 计算
// 这是纯数据处理函数，不涉及任何安全检测逻辑
为什么 patch 后不影响 Frida
完全不涉及 Frida 检测，这是 APK 完整性校验 防止的是 APK 被重签名/重打包，不是运行时注入 即使 APK 签名校验失败，也不会触发 kill(pid, SIGKILL)
整体安全架构
libDexH*lper.so 安全检测架构
================================
┌─────────────────────────────────────────────────────┐
│ 主检测调度器 sub_37DA8 │
│ (0x37DA8, size: 0x9CB8) │
└──────┬──────────┬──────────┬──────────┬──────────┬───┘
│ │ │ │ │
v v v v v
┌──────────┐┌──────────┐┌──────────┐┌──────────┐┌──────────┐
│ 0x5f388 ││ 0x57278 ││ 0x53d30 ││ 0x5f8c4 ││ 0x60ffc │
│ TracerPid││ Maps ││ 代码 ││ 线程 ││ APK │
│ + Frida ││ 扫描 ││ 完整性 ││ 枚举 ││ 签名 │
│ cmdline ││ ││ 校验 ││ 检测 ││ 校验 │
│ 匹配 ││ ││ ││ ││ │
├──────────┤├──────────┤├──────────┤├──────────┤├──────────┤
│ pthread ││ pthread ││ 直接调用 ││ pthread/ ││ 直接调用 │
│ 无限循环 ││ 一次扫描 ││ ││ callback ││ │
├──────────┤├──────────┤├──────────┤├──────────┤├──────────┤
│kill+exit ││ 设置标志 ││ 返回结果 ││ 设置标志 ││ 返回结果 │
│(直接终杀)││ (间接) ││ (间接) ││ (间接) ││ (间接) │
└──────────┘└──────────┘└──────────┘└──────────┘└──────────┘
↑
│
唯一直接导致
Frida 进程退出
的检测点！！！
通用反检测技巧汇总
| 字符串栈上构造 | /proc, TracerPid, frida) 都在栈上构造，不存在于 .rodata | |
| 字符串加密/混淆 | ||
| 直接系统调用 | linux_eabi_syscall(__NR_openat/kill/...) | |
| 函数名混淆 | p5lS05SSlS5SISl5l5$5I5I5I5lSISIS5SISI5l5IS$... | |
| 多线程并行检测 | ||
| 线程创建重试 | ||
| 栈保护 (canary) | _ReadStatusReg(TPIDR_EL0) | |
| NEON 向量运算 | ||
| 手动字符串匹配 | strstr/strcmp，手动逐字节比较 | |
| process_vm_readv |
Frida 绕过建议 (安全研究用途)
仅 patch 0x5f388 (sub_5ED80) 即可阻止 Frida 被检测杀死 原因: 其他检测点要么不直接 kill，要么速度慢于 TracerPid 检测 如需完整绕过所有检测，还需处理: 0x57278: Maps 中的 Frida 库名 (可用 frida-server -l 0.0.0.0:1234改名)0x5f8c4: Frida 线程名 (可重命名 frida 线程) 0x53d30: 代码完整性 (避免 patch .text 段或使用 Stalker 代替 Interceptor)