如何识别APP加固公司的虚假效果报告？技术负责人要会看这6个数据

我是某互联网金融公司的安全负责人，过去两年对接过7家加固厂商，见过的效果报告少说也有二十几份。坦白说，大部分报告都在玩数字游戏——展示的攻击工具是五年前的版本，声称的防护能力从未经受过真实对抗，所谓的“行业客户”可能只是对方参加过某次线上沙龙。

下面我把加固厂商最常见的5种造假手法、6个必须核验的数据维度，以及一套可自主执行的验证流程完整拆解出来。

一、加固公司不会告诉你的5种造假手法

手法1：用未加固版本当“对照组”

这是最基础也是最高频的伎俩。报告里放两张jadx反编译截图，左边是“友商A加固后”一片乱码，右边是“我们加固后”结构清晰——但你永远不知道右边那张图用的是不是根本没加固的包。

真实案例：某厂商给我们演示时，声称“核心支付逻辑已VMP化”。我们提出要现场测试，结果用GDA（国产反编译器）不到10分钟就把所谓的VMP函数还原成了可读的smali代码。后来发现，他们只是在入口Activity加了一层简单混淆。

手法2：选择已被淘汰的攻击工具做测试

一个行业潜规则：报告里列的攻击工具越老，说明这家厂商越心虚。

常见套路是拿Android 4.4时代的dex2jar、apktool 2.0来证明“无法反编译”。但你问一句“测试过Frida 16.x吗？”“能抗住objection的内存dump吗？”对面就开始顾左右而言他。

手法3：隐藏测试环境的关键细节

厂商会告诉你“我们通过了XX测试”，但不会告诉你：测试时关闭了SELinux、root检测被手动绕过、Xposed框架根本没装。一个真实的加固效果测试应该包含设备型号、系统版本、Root状态、Hook框架版本、脱壳工具版本这五项元信息，缺失任意一项，结论都不可信。

手法4：用“服务XX头部客户”偷换概念

“我们服务了某国有大行”不等于“该行核心交易系统用了我们的加固”。更常见的情况是：该行某个边缘活动的宣传页App用过他们的免费版，或者是某次POC测试中的一次尝试。要求对方提供授权书或合同关键页（脱敏后），能拿出真凭实据的厂商不到30%。

手法5：把开源项目包装成自研核心

这是最恶劣的。前面提到的“易固”事件就是个典型——所谓的VMP防护实际来自开源项目nmmp，作者甚至连修改代码的能力都没有，加固后的App100%闪退，还以“未购买授权”为由诱导付费。

验真方法：要求对方展示专利证书或软著，并核对技术描述是否与实测一致。

二、6个必须核验的独立数据点

下面这6个数据点，能过滤掉市面上80%的虚标厂商。缺任何一个，报告可直接判定为无效。

数据点1：脱壳工具的具体版本号 × 脱壳成功率

为什么必须看版本号：FRIDA-DEXDump v1.x只能脱一代壳，v3.x已支持部分二代壳的脱壳。厂商如果拿v1.x测试结果宣称“抗脱壳”，纯属欺骗。

实操建议：用自己的测试机（已Root、已安装Magisk+FRIDA 16.x），运行frida-dexdump -d -f 你的包名，观察是否能完整输出dex文件。

数据点2：攻击耗时的原始日志

行业内有句话：“不谈攻击成本的防护都是耍流氓。”

一份真实的渗透测试报告，必须包含：

• 从开始到成功脱壳/绕过的实际耗时（分钟/小时/天）
• 使用的攻击工具链清单及版本
• 失败的尝试次数和绕过路径

警惕话术：“经测试无法破解”是无效结论。“经过3人团队连续5天攻击，在修改了XX框架源码后实现部分绕过，预估完整逆向需要XX小时”才是可信的专业结论。

数据点3：测试设备型号与系统版本的完整列表

兼容性是加固的隐形杀手。一份合格的测试报告必须包含：

注意：低端机（4GB以下内存）和老系统（Android 8及以下）必须单独列出来，这两类是兼容性问题的重灾区。

数据点4：客户授权书的可验证性

对方说“服务于某银行”，你要看的是：

1. 授权书：明确写明授权该厂商进行安全测试或使用其产品
2. 合同关键页（脱敏后）：证明是付费采购而非POC
3. 可验证的联系人：找得到该客户的技术负责人（哪怕通过行业圈子间接求证）

如果对方以“保密协议”为由拒绝提供任何证明，基本可以判定为“蹭案例”。

数据点5：第三方审计报告的验真路径

索要第三方安全审计报告时，必须确认：

• 出具机构是否具备资质：CNAS、CMA认证的实验室，或知名安全公司（奇安信、绿盟、青藤云等）
• 报告编号是否可官网验真：正规机构的报告都有唯一编号，可在线查询
• 测试范围是否包含你的业务场景：一份针对游戏App的测试报告，不能证明对金融App同样有效

最稳妥的方式：由你自己联系第三方安全团队，指定测试范围和标准，费用可要求厂商承担或双方分摊。

数据点6：可复现的测试脚本/技术文档

这是最高标准，也是对自身技术能力的要求。

厂商应能提供：

• POC测试环境：一个可本地部署的测试包，包含未加固和加固两个版本
• 验证脚本：如check_hook.py、memory_dump.sh，用于自助验证防护效果
• 技术白皮书：详细说明虚拟化指令集设计、Java2C转换规则等（核心细节可脱敏）

能提供以上材料的厂商，说明技术底气足；给不出的，大概率是壳公司。

三、一套可自主执行的3步验证法

第1步：静态逆向测试（耗时：1-2小时）

工具链：

• jadx-gui 最新版：反编译查看Java代码
• GDA 4.0+：国产神器，对抗混淆能力更强
• apktool：解包资源文件
• strings命令+grep：检索敏感字符串

验证项：

1. 用jadx打开加固后APK，看包结构是否清晰可读
2. 搜索核心关键词（如pay、sign、token、api_key）
3. 检查AndroidManifest.xml中的Application类是否被替换为壳入口
4. 用strings lib/armeabi-v7a/*.so | grep -i "openssl\|aes\|encrypt"检测SO中是否暴露密钥

通过标准：核心逻辑类无法被直接阅读，关键字符串被加密或混淆。

第2步：动态运行时测试（耗时：2-4小时）

工具链：

• FRIDA 16.x + frida-dexdump：脱壳尝试
• objection：内存dump和Hook测试
• Xposed（可选）：模块注入测试

验证项：

1. 运行frida-dexdump -d -f 包名，观察是否能完整脱出dex
2. 使用objection的memory dump all尝试dump内存
3. Hook关键加解密函数（如AES.init、Cipher.doFinal），观察是否能获取明文
4. 检测反调试机制：用gdb或lldb附加进程，看是否会被kill或闪退

通过标准：无法通过Hook获取关键参数，内存dump无法提取明文密钥。

第3步：二次打包测试（耗时：30分钟）

工具链：

• apktool：解包
• keytool + jarsigner：重新签名
• ApkSignerV2：V2签名

验证项：

1. 用apktool解压加固后APK，修改AndroidManifest.xml中的版本号
2. 用apktool回编
3. 用自己的证书重新签名（注意：必须V1+V2签名）
4. 安装运行

通过标准：二次打包后的App无法正常运行，或在启动时检测到签名变更并闪退。

四、快速排雷清单

签约前，把下面这个清单发给对方，要求书面回复：

1. 【版本透明】请提供测试用的脱壳工具名称及完整版本号
2. 【日志可查】请提供攻击测试的完整原始日志（非二次编辑）
3. 【设备列表】请提供覆盖的测试设备型号、系统版本、SoC型号
4. 【客户可验】请提供行业客户的授权书或合同关键页（敏感信息可脱敏）
5. 【报告可查】请提供第三方审计报告编号及验真方式
6. 【流程可复现】请提供POC测试包及验证脚本

能完整回应的，进入POC测试；回避或含糊其辞的，建议直接Pass。