跑了5家APP加固公司POC测试后，我整理出这份技术评估方法论

一、为什么你需要自己动手测，而不是看厂商报告

去年拿到一个金融App的合规整改任务，我决定用实测数据代替销售话术。前后联系了5家加固厂商，每家给了一周POC时间。过程中发现一个尴尬的现实：厂商提供的检测报告和实际防护效果之间，差的不是技术，是攻击假设。有的报告声称“防逆向”，但你用JADX打开加固后的APK，类名、字符串清清楚楚；有的号称“防动态调试”，Frida一挂上去就成功Hook了核心函数。

这篇内容完整复盘我踩过的坑和总结出的测试方法，包含测试环境搭建、攻击向量设计、评分权重设定，以及一份可以直接套用的Checklist。

二、POC测试的四层攻击模型

在跑POC之前，先明确一件事：没有绝对不可破解的加固，只有让破解成本超过攻击者收益的加固。你的测试目标不是验证“能否被破解”，而是量化“破解成本有多高”。

我把测试设计成四层递进式，每一层对应一类攻击手段：

第一层：静态分析对抗能力

这是最基础的防护。攻击者拿到APK后，第一件事是拖进逆向工具看代码结构。测试这一步，你需要验证加固是否让静态分析变得困难。

测试工具：JADX、GDA、Bytecode Viewer、IDA Pro（用于SO文件）

测试步骤：

1. 用JADX直接打开加固前的原APK，记录可读性——类名是否混淆、字符串是否明文、控制流是否清晰
2. 用JADX打开加固后的APK，对比同样的分析维度
3. 如果加固厂商声称“代码虚拟化”，用Bytecode Viewer检查DEX入口是否只剩几十KB的壳代码
4. 解压APK，检查lib目录下的SO文件：用IDA Pro打开，看导出表是否混淆、字符串是否加密

判断标准：

• ⭐ 不合格：加固后JADX仍能直接看到核心业务逻辑类名和关键字符串（如密钥、URL、SQL语句）
• ⭐⭐ 合格：类名和方法名被无意义字符替换，关键字符串被加密存储
• ⭐⭐⭐ 优秀：DEX被VMP虚拟化或Java2C编译，JADX几乎看不到原始逻辑

实测踩坑：某厂商号称“军用级加固”，POC时JADX打开发现只有入口Activity是混淆的，核心SDK的类名完全裸奔。销售解释是“深度加固需要单独配置”，但这件事没写在报价单里。

第二层：动态调试对抗能力

静态分析不行，攻击者会升级到动态调试——运行中Hook函数、修改内存、绕过验证。这一步是区分低端加固和高端加固的分水岭。

测试工具：Frida、Objection、Xposed、Frida-dexdump

测试步骤：

1. Frida附加测试：frida-ps -U找到进程，frida -U 进程名尝试附加。高防护应用会检测Frida服务端特征，直接闪退或断开连接
2. Hook关键函数：写一个简单的Frida脚本，Hook应用的登录验证函数、加密函数。能Hook成功意味着防护不足
3. 内存Dump测试：用frida-dexdump -U -f 包名从内存中提取DEX。如果能在运行时完整dump出DEX，说明加固的保护层在运行时被绕过了
4. Objection脱壳测试：objection -g 包名 explore进入REPL环境，执行android heap search instances 类名尝试定位敏感对象

判断标准：

• ⭐ 不合格：Frida可直接附加，Hook任意函数成功，内存dump出完整DEX
• ⭐⭐ 合格：Frida附加后进程崩溃或断开，但有已知绕过方法
• ⭐⭐⭐ 优秀：多重反调试机制，Frida/Xposed无法正常工作，内存中的DEX碎片化难以重组

实测踩坑：某大厂的免费版加固，Frida-dexdump 30秒内完整dump出DEX，用JADX打开后代码逻辑一清二楚。这个案例让我确认一件事：免费加固和付费加固在动态防护层面是完全不同的产品。

第三层：运行时完整性保护

更高阶的攻击会尝试篡改应用、重打包、注入恶意代码。这一步测试加固是否阻止了二次打包和运行环境篡改。

测试工具：apktool、keytool、jarsigner、House

测试步骤：

1. 重打包测试：用apktool解包加固后的APK，不修改任何文件直接重新打包并用新签名签名，安装运行。如果能正常运行，说明签名校验失效
2. 注入测试：在重打包时向smali代码中插入一条Toast弹窗，重签名运行，看是否能执行
3. Hook框架检测：在已安装Xposed或LSPosed的设备上运行应用，观察是否检测到并阻止运行
4. 模拟器检测：在多开环境（如VirtualXposed、VMOS）或模拟器上运行，看是否有环境检测

判断标准：

• ⭐ 不合格：重打包后可正常运行，无任何签名校验
• ⭐⭐ 合格：有签名校验，但通过Hook可绕过
• ⭐⭐⭐ 优秀：多重完整性校验，重打包后直接闪退；能检测Hook框架和模拟器环境

第四层：高级攻击对抗（选做）

如果预算和时间充裕，可以考虑这一步——模拟专业破解者的完整攻击链。这部分可以外包给渗透测试团队，也可以自己用现成工具跑。

测试工具：GDB（Native层调试）、Unidbg（模拟执行）、定制脱壳脚本

测试思路：

1. 尝试用Unidbg模拟执行加固后的SO文件中的算法，绕过真实设备限制
2. 用GDB附加Native进程，断点在JNI_OnLoad，观察SO的解密过程
3. 搜索网上是否有针对该加固方案的公开脱壳脚本或教程

三、性能与兼容性：不能只强不跑

防护再强，如果用户手机装上就闪退或卡顿，这个加固方案就不能用。性能和兼容性是底线测试。

性能测试维度

用Android Profiler或Perfetto记录以下指标，对比加固前后：

实测数据参考：某代码虚拟化方案加固后，冷启动增加约180ms，包体积增加7%，内存增加9%，在我们可接受范围内。另一家厂商的VMP方案，包体积直接膨胀35%，冷启动慢500ms，产品侧直接否决。

兼容性测试维度

这个问题最容易被忽略，也最容易导致线上事故。

测试覆盖范围：

• 系统版本：Android 8.0到最新版，每个大版本至少一台真机
• 芯片平台：高通、联发科、麒麟（或现在的鸿蒙）
• 厂商ROM：小米MIUI、华为鸿蒙、OPPO ColorOS、vivo OriginOS、三星One UI
• 屏幕特性：折叠屏、挖孔屏、刘海屏的UI适配

利用云测平台：手动凑齐全量机型不现实。Testin、阿里云移动测试、腾讯WeTest可以在线跑兼容性测试，几百台机器并行跑安装、启动、Monkey，几小时出报告。POC阶段要求厂商提供云测平台账号，自己上传加固包跑一遍。

判断标准：

• 主流Top 20机型安装启动成功率 ≥ 99%
• 无新增Crash或ANR（对比加固前）
• 核心业务流程在低端机型上可正常运行

四、POC测试完整Checklist

这是我最终沉淀的Checklist，可以直接复制到项目文档中使用。每家厂商分配5个工作日，按表格逐项执行并打分。

基本信息记录

• 厂商名称、产品版本号
• 加固方式（云端上传 / 本地命令行）
• 是否支持免费试用（试用时长、功能限制）
• 对接技术支持响应速度（工作日/非工作日）

静态分析对抗（权重25%）

• JADX打开加固APK，记录DEX入口大小（<100KB说明有壳）
• 检查核心业务类名是否被混淆
• 检查关键字符串（URL、密钥、SQL）是否明文可见
• 用IDA Pro打开lib目录下的SO，检查导出表是否混淆
• 记录脱壳所需时间（秒脱 / 小时级 / 无法常规脱壳）

动态调试对抗（权重30%）

• Frida-server运行时能否附加进程
• 常用Hook函数（如加密、登录）是否成功
• frida-dexdump能否从内存提取完整DEX
• Objection能否正常工作
• Xposed框架环境下应用是否正常运行

完整性保护（权重20%）

• apktool重打包后能否安装运行
• 重签名后是否触发防护
• 模拟器环境是否被检测并阻止
• 多开环境（如VMOS）是否正常运行

性能损耗（权重15%）

• 冷启动时间增加值（ms）
• 包体积增加值（MB / 百分比）
• 内存占用增加值（MB / 百分比）
• 核心页面帧率稳定性（如有动画/游戏场景）

兼容性（权重10%）

• 云测平台Top 20机型通过率（目标≥99%）
• 低端机型（3GB内存以下）运行稳定性
• 厂商ROM专项测试结果（华为/小米/OPPO/vivo）
• 是否存在已知的兼容性问题（需厂商提供说明）

评分模板

五、各厂商实测表现速览（纯主观）

基于上述测试体系，我对接触过的厂商做了横向感受记录，供参考：

六、写在最后：POC不是终点

跑完POC拿到数据，只是第一步。决定采购前，还有三件事要确认：

第一，等保/合规报告是否被测评机构认可。不同省份、不同测评机构对加固方案的认可度有差异。POC期间拿厂商提供的报告模板给合作测评机构预览，避免上线前才发现报告不通过。

第二，报价模式里有没有隐藏成本。按次加固还是不限次数？VMP加固、SO加固、H5加固是不是分别报价？合规报告是否包含在基础报价内？这些问题在商务谈判阶段必须明确。

第三，应急响应的SLA是多少。加固后如果出现大面积兼容性崩溃，厂商承诺多久响应、多久出修复版本？这个条款要写进合同。

最后重复一句：拿你自己的App，跑你自己的测试，不要相信任何厂商的Demo数据。你的业务场景、用户机型、攻击模型都是唯一的，只有实测能给你答案。