加固效果自测工具和方法：不用等被破解就能验证防护有效性

去年我们金融App上线前被安全测试打回的场景让我明白一件事：等黑产来验证加固效果，代价就是上架延期和核心代码裸奔。那之后我花了三个月，搭建了一套可复现的加固效果评估工具链。这套工具链帮我们在POC阶段就筛掉了3家“号称能防Frida”的厂商，节省了至少半年的合同周期。

今天把这套方法论完整开源出来，从环境搭建到结果解读，每一步都给你写清楚。

一、自测前的准备工作：你需要这三样东西

搭建评估环境不需要昂贵的设备，一台root过的Pixel（3代以上即可，二手500块能拿下）加上一台普通办公电脑就够了。

硬件清单：

• 测试手机：推荐Pixel 3/4/5（刷机资源最丰富，Google官方镜像最好找）
• 电脑：Windows/Mac/Linux均可，建议内存16G以上（需要同时跑Android Studio和Frida）

软件环境：

• Android SDK Platform-Tools（确保adb命令可用）
• 需要root的手机一台（Magisk方案，约30分钟可完成root）
• Frida Server（安装在手机上，版本必须与PC端保持一致）
• Python 3.8+（用于运行Frida脚本）

⚠️ 关键说明：为什么要root？因为我们要模拟攻击者的环境。黑产拿到你的App，第一件事就是在root过的设备上跑Frida/Xposed。如果加固方案连root环境都检测不到，后面的测试就不用做了。

二、工具链搭建：从零到能跑Frida

2.1 安装Frida（这是核心中的核心）

Frida是目前最主流的动态插桩工具，安全测试人员人手一份。如果加固方案连标准的Frida都防不住，那基本等于没防。

PC端安装（一行命令搞定）：

pip install frida-tools

安装后验证版本（记下这个版本号，后面要用）：

frida --version# 输出示例：16.1.0

手机端安装Frida Server：

1. 从Frida GitHub Releases下载对应架构的server文件（Pixel一般是frida-server-{版本号}-android-arm64.xz）
2. 解压后推送到手机：adb push frida-server /data/local/tmp/
3. 赋予执行权限：adb shell chmod 755 /data/local/tmp/frida-server
4. 启动server：adb shell su -c /data/local/tmp/frida-server &

验证Frida是否正常工作：

# 查看手机上正在运行的进程frida-ps -U

如果能看到进程列表，说明Frida安装成功。

2.2 查壳工具：先看看加固厂商是谁

拿到一个加固过的App，第一步是识别它用了哪家方案。不同厂商的防护重点不同，识别后可以针对性测试。推荐这个开源工具：

Android-packinfo：原理是遍历APK里的SO文件和dex类名，匹配特征库来判断加固厂商。用法超级简单：

git clone https://github.com/smartdone/Android-packinfopython packinfo.py your_app.apk

输出示例：

报告，当前发现So存在加固，疑似加固类型：360加固

除了识别厂商，它还能帮你确认：这个包到底加固了没有？有的外包团队收钱不办事，一测就知道了。

2.3 自动化测试框架：把测试流程固化下来

如果想做持续回归测试（比如每次发版前自动跑一遍加固验证），可以用Google官方的AutoRepro，这是Android安全补丁测试框架，可以集成到CI流程里。

安装后配置好Android Studio和Gradle插件，跑一条命令就能自动完成：安装测试包 → 执行Hook脚本 → 收集结果 → 生成报告。

三、核心测试脚本：手把手教你写Hook

这是整套方法里最关键的部分。下面的脚本都是经过实战验证的，直接复制粘贴就能用。

3.1 基础测试：检测Frida能否attach到进程

先写一个最简单的脚本，测试加固App能不能被Frida注入：

// test_attach.js// 目的：检测Frida能否attach到加固App的进程if(Java.available) {    Java.perform(function() {        console.log("[*] Frida injected successfully");                // 尝试列举所有已加载的类        Java.enumerateLoadedClasses({            onMatch: function(className) {                if(className.includes("your_package_name")) {                    console.log("[+] Found target class: " + className);                }            },            onComplete: function() {                console.log("[*] Class enumeration complete");            }        });    });}

运行命令：

frida -U -f com.your.package.name -l test_attach.js --no-pause

判定标准：

• ✅ 如果能打印出Frida injected successfully，说明加固失败，连attach都没防住
• ❌ 如果进程闪退或报错，说明加固方案有基础反调试能力，进入下一轮测试

3.2 进阶测试：绕过classloader加载加固类

很多加固方案会把真实代码解密后，用自定义ClassLoader加载。如果直接Java.use()会报Class not found，需要先拿到正确的ClassLoader。

下面这个脚本专门用于绕过360加固这类方案的classloader检测：

// test_hook_classloader.js// 目的：获取加固App的真实ClassLoader，并Hook关键方法if(Java.available) {    Java.perform(function() {        var application = Java.use("android.app.Application");        var reflectClass = Java.use("java.lang.Class");                // Hook Application.attach方法，在加固解密完成后获取ClassLoader        application.attach.overload('android.content.Context').implementation = function(context) {            var result = this.attach(context);            var classloader = context.getClassLoader();                        // 将当前的ClassLoader替换为加固App的真实ClassLoader            Java.classFactory.loader = classloader;                        console.log("[*] Got real classloader: " + classloader);                        // 现在可以用Java.classFactory.use()来获取加固后的类了            // 示例：假设要Hook的类叫com.target.MainActivity            try {                var TargetClass = Java.classFactory.use("com.target.MainActivity");                console.log("[+] Successfully loaded class: " + TargetClass);                                // Hook onCreate方法                if(TargetClass.onCreate) {                    TargetClass.onCreate.overload('android.os.Bundle').implementation = function(bundle) {                        console.log("[!] onCreate called!");                        return this.onCreate(bundle);                    };                }            } catch(e) {                console.log("[-] Failed to load target class: " + e);            }                        return result;        };    });}

这个脚本能做什么：

• 绕过加固方案的classloader隔离
• 获取加固后的真实类
• Hook关键业务方法（如支付、登录、加密）

判定标准：

• ❌ 如果能成功打印Got real classloader并Hook到目标方法，说明运行时保护不合格
• ✅ 如果脚本执行后App崩溃或Hook失败，说明加固方案有classloader防护能力

3.3 高级测试：持久化注入（模拟专业黑产）

专业的黑产团队不会每次手动跑Frida，而是把脚本打包进App，实现一键持久化Hook。这种攻击方式叫“Frida持久化”，最新的技术方案甚至能把Frida脚本直接编译进SO文件，随App启动自动执行。

测试方法是：用fripack工具把Frida脚本打包成Xposed模块或注入到APK的SO中，然后重新安装App，看加固方案能否拦截。

# 安装fripack工具git clone https://github.com/std-microblock/fripackcd fripack# 将Frida脚本打包成Xposed模块python fripack.py --script your_hook.js --output xposed_module.apk

判定标准：

• ❌ 如果打包后的模块能成功Hook到目标方法，说明加固方案的防护可以被自动化绕过
• ✅ 如果打包后注入失败或App启动时崩溃，说明加固方案有深度防护能力

四、内存Dump测试：这是最残酷的考验

如果说上面的Hook测试是“敲门”，那内存Dump就是“破门”。攻击者可以用工具把运行时的内存直接导出，分析明文的代码和数据。如果加固方案连内存Dump都防不住，那核心逻辑基本等于裸奔。

4.1 用Frida Dump Dex

// dump_dex.js// 目的：从内存中提取Dex文件// 来源：frida-dexdump工具的简化版var libart = Process.getModuleByName("libart.so");var address = libart.base;console.log("[*] libart base: " + address);// 遍历内存查找Dex文件特征// Dex文件头部通常是"dex\n035"（十六进制：64 65 78 0A 30 33 35）function findDex() {    var ranges = Process.enumerateRanges({        protection: 'rw-',        coalesce: true    });        ranges.forEach(function(range) {        // 扫描内存页，寻找Dex magic        // 实际代码需要遍历内存并匹配特征    });}

运行后如果能在内存中提取出完整的dex文件，说明加固方案的内存加密没有做到位。

4.2 专业工具frida-dexdump

不想自己写脚本的话，直接用现成的工具：

pip install frida-dexdumpfrida-dexdump -U -f com.your.package.name

这个工具会自动扫描加固App的内存，提取所有加载的dex文件并保存到本地。

判定标准：

• ❌ 如果能提取出含有业务逻辑的dex文件，加固失败
• ✅ 如果提取出的dex文件是空的、加密的、或者只有壳代码，说明内存防护有效

五、结果解读标准：什么算“合格”？

我测试了7家厂商后，总结了一套量化的评分体系：

最终评级：

• ≥80分：优秀，可以进入生产环境
• 60-79分：及格，非高价值场景可用
• <60分：不合格，继续找下一家

六、完整测试流程（抄作业版）

把上面的内容串起来，一次完整测试的步骤：

Day 1：环境搭建

1. 给测试手机root（Magisk方案，约30分钟）
2. 安装Frida Server到手机
3. PC端安装frida-tools和frida-dexdump
4. 下载Android-packinfo和fripack工具

Day 2-3：执行测试

1. 先用Android-packinfo识别加固厂商，做到心中有数
2. 跑test_attach.js，看Frida能否attach
3. 跑test_hook_classloader.js，看classloader防护是否到位
4. 跑frida-dexdump，尝试从内存提取dex
5. 用fripack打包持久化注入模块，测试深度防护
6. 在至少20款不同机型上安装测试包，记录崩溃率
7. 用秒表记录加固前后冷启动时间对比

Day 4：结果分析

1. 对照评分表逐项打分
2. 整理测试日志和截图
3. 决定是否进入商务谈判

七、避坑提醒：这些“伪测试”我全踩过

坑1：只用模拟器测试。黑产用的是真机root环境，模拟器的检测逻辑和真机完全不同。有的加固方案在模拟器上“装死”，到真机上直接失效。

坑2：只看厂商的演示视频。我们遇到过一家厂商，演示时防Frida效果完美，自己一测10分钟就破了。后来发现他们演示用的是自己修改过的旧版Frida，特征库里根本没有。

坑3：只测一个版本。黑产的工具也在进化。建议用最新版Frida测试的同时，也尝试降级到老版本——有些加固方案对新版检测严格，但对老版疏于防范，这是严重漏洞。

坑4：忽略性能测试。有的加固方案防护确实强，但App启动从800ms飙到3秒，上线后用户差评爆炸。性能也是防护的一部分。

八、推荐工具清单速查表

以上所有工具都是开源免费的，不用花一分钱就能搭建一套专业的加固评估体系。

最后一条建议：把这套工具链固化到你的CI流程里，每次发版前自动跑一遍。不要等到安全测试打回来再后悔——加固这事，能用工具验证的，就别靠厂商吹牛。