VMP

读完本文，你将获得： 分清 R8、代码混淆、DEX 加壳、函数抽取、DEX2C、VMP、SO 保护与 RASP 到底解决什么问题 看懂一个加固 APK 从 CI 构建、后处理、对齐、重签名，到壳启动、完整性校验和业务代码加载的完整链路 了解 360、阿里 mPaaS、爱加密、梆梆、腾讯乐固，以及 DexGuard、Promon、Appdome、AppSealing、Google Play 方案的公开能力与证据边界 理解为什么加固必须与 APK 签名、Play Integrity、设备注册、账号图谱和服务端风控组合，而不能独自承担“客户端可信” 获得一套可执行的 release 参数、性能基线、兼容性矩阵和加固验收方法 〇、摘要：壳不是保险柜，它是一套成本控制系统 Android APK 对逆向工程天然友好。 classes.dex 不是源码，却保留了大量类、方法、调用和数据流语义；resources.arsc、Manifest、Assets、字符串和 native SO 又把接口、功能开关、协议常量、JNI 边界与第三方 SDK 关系一并交给了终端用户。一个正常用户看到的是登录、支付和播放页面，分析者拿到的却是一份可以离线拆解、反复运行和任意修改的程序副本。 APK 加固由此产生。它要处理的不是一个问题，而是四类问题： 代码理解。 降低 Java/Kotlin、C/C++、Flutter、Unity 或脚本逻辑被快速恢复和复用的概率。 运行时观测。 增加调试、Hook、注入、内存读取和自动化批量控制的成本。 篡改与重打包。 发现签名、代码、资源、调用顺序或运行环境发生了不符合预期的变化。 业务滥用。 把客户端风险信号传给服务端，让登录、领券、支付、游戏结算、内容授权等动作得到分级处置。 但有一条物理事实绕不过去：代码要在用户控制的设备上执行，处理器最终就必须获得明文指令、解码后的类，或与原算法等价的 VM 语义。 加固可以缩短稳定观测窗口、打散结构、改变执行形态、提高自动化规模成本，却无法把白盒客户端变成服务端 HSM。 所以本文的主线不是“哪家的壳最硬”，而是： 1 2 资产分级 -> 构建期变换 -> 包与运行时保护 -> 平台可信证明 -> 设备/安装身份连续 -> 绑定业务动作 -> 风险处置与反馈 这条链也把前两篇文章接了起来：Chrome VMP讨论如何让关键语义难以稳定观测，设备指纹与设备注册讨论如何把端上证据放进服务端身份和业务图谱。APK 加固位于两者之间：它保护”客户端如何执行”，但不能独立回答”服务端为什么应该相信这次请求”。 ...

读完本文，你将获得： 明确区分 Chrome 沙箱、V8 字节码、商业 VMProtect 壳与本文讨论的 VM-based Protection 理解 Chrome 原生媒体模块中 VMP 的核心目标：不是让代码不可执行，而是让关键语义不可稳定观测 掌握一套分析 VMP 保护的工程框架：入口边界、调度器、编码状态、完整性校验、明文输出边界 经历从"grep AES S-box"到"差分边界建模"的认知转变过程——以及中间踩过的每一个坑 看清 VMP 的真实安全边界：它能显著提高密钥提取成本，但无法让合法播放后的明文数据凭空消失 〇、摘要 本文讨论的 VMP 指 VM-based Protection / 虚拟机化保护，不是 Chrome 浏览器自身的沙箱机制，也不特指商业产品 VMProtect。它是一类代码保护方法：将原始算法提升为自定义字节码、解释器调度、编码状态和完整性校验的组合，使攻击者很难从静态反编译、内存扫描或常规断点中恢复关键语义。 Chrome 生态里，最适合观察这类保护的位置不是普通网页 JavaScript，而是高价值原生模块，例如桌面端 Widevine CDM 这类承载 DRM 密钥处理和媒体解密的组件。它们处在 Chrome 的 EME/Mojo/CDM 调用链上，既要在用户可控机器上运行，又要尽可能保护 license、content key、白盒表和解密状态。 本文的核心结论是： VMP 的核心不是“藏代码”，而是“抹除可观测性”：标准 AES 表、key schedule、硬件 AES 指令、稳定函数边界都会被替换成 VM 调度、动态表、编码状态和热路径变换。 Chrome 场景下的 VMP 是多边界协同：浏览器进程模型、Mojo IPC、CDM utility 进程、沙箱、完整性校验和白盒数据路径共同构成防护面。 密钥保护和明文保护不是一回事：VMP 可以让 content key 难以提取，但合法播放路径最终仍会产生解码后的明文帧，这是 DRM 工程无法回避的语义边界。 正确的分析方法不是一上来硬反 VM：更有效的路线是先刻画输入/输出边界，再用 perf、堆快照、IPC 观察、完整性安全的断点和差分实验定位“语义转移点”。 换句话说，现代 VMP 的价值在于把攻击者从”搜一个表、hook 一个函数、dump 一个 key”的线性流程，拖入”恢复 VM 指令集、还原状态编码、绕过完整性校验、证明数据流语义”的系统工程。 ...

读完本文，你将获得： 理解 Android Native VMP 保护的三代架构演进：从固定 opcode 到状态依赖调度 掌握一套识别 dispatcher、枚举 handler、恢复 opcode 语义的工程方法 经历一个 VMP 保护签名函数的完整分析过程，包括五次失败和三次策略转向 看清 VMP 保护的真实安全边界：它提高了静态分析成本，但 unidbg/Unicorn 黑盒调用可以完全绕过 区分 VMP 与 OLLVM 的适用场景，理解"VMP 了就安全了"为什么是危险的误解 获得一组面向防御者的改进提案，从 P0 到 P3 〇、摘要 Android 生态里，VMP（Virtual Machine Protection / 代码虚拟化保护）是国内加固厂商和头部 App 保护关键 Native 逻辑的主要手段之一。它把原始 ARM/ARM64 指令编译为自定义字节码，由嵌入 SO 的解释器在运行时调度执行，使 IDA Pro 的反编译结果从"可读的 C 伪代码"退化为"两万行 switch-case 状态机"。 笔者在过去两年中分析过多个使用 VMP 保护签名算法的 Android App，积累了以下观察： VMP 的核心价值不是"防逆向"，而是"防低成本逆向"：它把分析门槛从"F5 一下就能读"提高到"需要恢复 VM 指令集才能理解语义"，但不能阻止 unidbg/Unicorn 级别的黑盒调用。 三代 VMP 的区分不在"有没有 VM"，而在 dispatcher 的状态依赖程度：一代用固定 handler table，二代用编码 opcode + 动态 dispatch，三代把 dispatch 本身变成状态机输出。 实战中击穿 VMP 保护签名函数的关键转向，往往不发生在 VM 内部：笔者多次在 I/O 边界、JNI 桥接层或 memory pattern 上找到突破口，而不是靠完整还原 VM 指令集。 VMP 与 OLLVM 是互补而非替代关系：OLLVM 保护控制流，VMP 保护指令语义，两者组合才能同时抵御 symbolic execution 和静态反编译。 “VMP 了就安全了"是当前最危险的工程误解：侧信道、I/O 边界、timing pattern 和黑盒模拟器四条路径都不需要理解 VM 内部语义。 本文是一篇原创逆向研究文章（Type A），记录笔者分析 Android Native VMP 的实战过程、失败路径和方法论积累。与本博客的 Chrome VMP 文章 不同，那篇讨论的是 DRM/Widevine 场景下的白盒密码学保护；本文聚焦 Android App 保护厂商（360加固、梆梆、爱加密等）和自研 VMP 实现，目标对象是签名算法、加密模块和反作弊逻辑，分析工具链以 IDA Pro + Frida + unidbg/Unicorn 为主。 ...