Hunter libc 内存检测 - 动态库被动过怎么发现
这项在查什么
libc 内存检测扫的是当前进程内存里的 C 标准库（libc）等关键动态库有没有被修改。libc 是几乎所有 Android 进程都会加载的底层库，负责字符串操作、内存分配、文件 I/O 等基础功能。如果有人在内存里对 libc 的函数进行替换或 inline hook，Hunter 能通过对比内存里的 libc 二进制与磁盘上的原始版本来发现差异。
为什么扫 libc
libc 是进程最早加载的一批库之一，也是逆向注入和 hook 最常选择的目标。常见的修改手段：
- GOT 表 hook：修改全局偏移表里的函数地址，劫持调用
- Inline hook：直接改写 libc 函数开头的机器码，插入跳转
- 库替换：把系统 libc 换成带后门的自定义版本
libc 内存检测就是用来扫这些痕迹的。
和 inline hook / GOT 表检测的关系
libc 内存检测是「总」，inline hook / GOT 表检测是「分」——三者联合解读：
- libc 内存检测：整体扫一遍内存里的关键库有没有被动过
- inline hook 检测：专门检查关键函数的机器码开头有没有被改
- GOT 表检测：专门检查全局偏移表的函数指针有没有被劫持
libc 内存检测报红了，后面的 inline hook / GOT 表检测大概率也会报红——两者互相印证。
谁会被触发
| 场景 | 触发概率 | 说明 |
|---|---|---|
| Magisk / LSPosed 的 Zygote 注入 | 可能触发 | 框架会对 Zygote 进程做注入操作 |
| 用 Frida 做 hook | 大概率触发 | Frida 通过修改内存实现 hook |
| 完全没做过注入类操作 | 正常不触发 | 报红要认真排查 |
这项报红要不要紧
取决于你知不知道为什么会报红：
- 知道自己在用 Magisk / LSPosed —— 这是框架注入的正常痕迹，可以忽略
- 知道自己用 Frida 调过 —— 也是正常的 hook 痕迹
- 完全不知道为什么 —— 需要排查是不是某些你没意识到的应用在注入进程