"在 CSDN 发过一篇精简版的思路。这次重新整理了底层源码、硬件断点细节以及完整的修复脚本。"

目标 App：某企业级加固 App
加固特征：内存级环境指纹检测 + 硬件级反调试 + SO 强混淆 VMP + Fake Size 指令抽空假象 + 段级加密与苛刻解密时机控制
实战环境：Pixel, Android 10, 自编译定制内核

本文记录了一次完整的底层对抗与逆向分析实录：从物理内存重写工具绕过环境指纹检测，到利用 Linux 内核级硬件断点实现无篡改的 ART 挂钩；分析其Fake Size相关的指令抽取机制。在完成 Java 层分析后，针对 Native 层开发 C 语言的预读轮询提取工具，通过时间冻结与 ELF 离线缝合技术，完成了目标 SO 的内核级脱壳，并分析了其私有 DRM 视频加密机制。

在对 libTargetPlayer.so 实施操作之前，需要先构建一个安全的运行环境。
企业级加固的防御体系会检查系统属性（防篡改）、扫描内存（防调试注入）、校验文件路径（防 Root），以及检测系统源码级的编译特征（防自编译内核）。

我在定制内核中实施了多层级的底层隐匿方案，主要拦截点如下：

该工具通过解析 Android 属性树，定位目标属性在物理内存中的偏移并覆写。

要获取解密后的 Dex，常规在用户态对 libart.so 实施 Inline Hook 易触发防御机制。目标持续扫描代码区完整性，并轮询 TracerPid 与 CPU 调试寄存器。

为规避检测，探针被下沉至 Linux 内核态。基于定制内核的 perf_event 子系统，配置 CPU 硬件调试寄存器设置硬件断点，监控 art::ClassLinker::LoadClass 的执行地址。陷入内核层后，可安全读取保存了 DexFile 结构体指针的寄存器。

在内核驱动模块中，注册 perf_event 拦截特定的虚拟内存执行地址。

初步提取的 Dex 文件静态反编译时出现内存越界异常，代码块显示为空。
结构分析表明，加固层在加载阶段已将 Dalvik 字节码解密并存在物理内存块末端。为阻碍提取，设计了 Fake Size 防御：在解密后篡改传给 ART 的 Dex 头部 file_size 字段。
常规转储通常依赖该声明尺寸，导致隐藏在尾部的真实代码区域被截断遗漏。

针对这种情况，可通过扫描内存文件定位被隐匿的 Dex 头，并验证 Fake Size 的影响。

为应对尺寸伪装，我已在内核驱动模块中设定了超出常规规模的连续物理采集阈值（例如 0x2000000 即 32MB），实施强制越界提取。

原始数据的超量提取会导致导出流包含冗余数据，物理尺寸发生改变也会破坏 Dex 头部的校验链。需按以下流程重建二进制结构：

执行该脚本完成重构后，隐匿的业务方法字节码即可在工具中恢复。

Native 层的安全防护具备更高的分析门槛。关键代码段在装载初期保持加密状态，仅在业务逻辑触发时解密。
由于存在反调试机制，通过常规 ptrace 尝试附加目标进程易引发异常。为此开发了基于外部轮询的 C 语言工具 ghost_dumper。该方案基于 /proc/[pid]/mem 接口实施带外读取，规避了进程注入。

该工具静默提权后，通过解析 /proc/[pid]/maps 定位 libTargetPlayer.so 的基址。静态分析表明，目标 SO 在解密完成时，会在 0x1EA038 动态写入核心函数指针。工具启动高频 pread 轮询该地址，当值变更为合法地址时判定解密完成，随后下发 SIGSTOP 强制冻结进程。

通过上述方案流出的二进制数据，需经由 PC 端脚本进行接收解析，并还原回原 ELF 文件。

通过 receiver.py 接收数据，并通过 patch_so.py 将导出的内存合并回原 ELF 文件。

1. receiver.py (拆分二进制流)

2. patch_so.py (ELF 结构修复)

对重构后的 libTargetPlayer_decrypted.so 静态分析时发现，通过在进程冻结窗口期获取的内存快照，捕获到一个未混淆的初始化函数。

加密逻辑存在于动态加载的 libtargetdrm.so 中。分析确认 TARGET_CDRMC_Decrypt_AES_CBC 执行标准 AES-CBC 解密。

该解密过程采用了原地解密 (In-place Decryption)。可借助动态框架拦截 TARGET_CDRMC_Decrypt_AES_CBC 函数的执行过程提取明文数据流。

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！