安卓加固POC测试完整checklist，这12项验证缺一不可

选加固方案最怕什么？不是价格贵，是POC没测透，上线后发现防护形同虚设。我见过太多团队被厂商的“金融级防护”话术忽悠，结果一上真机测试，Frida三秒挂上、核心代码一分钟dump下来。本文把这一年多实测总结的12项验证指标全摊开，每项附具体工具和通过标准，照着测就行。

测试准备：统一的基线环境

测试设备要求：

• 低中高三档机型各一台（推荐Redmi Note系列、小米数字系列、Google Pixel）
• Android版本覆盖8.0到14.0
• 已root设备（Magisk）必备，很多防护在未root环境看不出深浅
• 安装主流逆向工具：jadx、GDA、IDA Pro、Frida、Objection、Xposed

测试包要求：

• 同一份未加固APK包做基线
• 记录加固前的包体积、启动耗时、各功能页面加载时间
• 核心业务逻辑要能被逆向工具正常分析（做对比用）

第一类：静态防护验证（共4项）

1.1 DEX反编译抵抗

测试工具：jadx-gui、GDA、JEB

测试步骤：

1. 将加固后的APK拖入jadx-gui
2. 检查是否能直接看到业务代码
3. 搜索核心类名（如PaymentActivity、EncryptUtils）

通过标准：

• jadx打开后无法直接定位到业务代码
• 核心类的方法体为空（仅保留native声明）或被虚拟化指令替代
• 使用FART脱壳机尝试dump，无法获取完整的原始DEX

常见坑：部分厂商只用ProGuard做基础混淆，类名变成a/b/c但方法体完整可读——这不算有效防护，不到一小时就能还原逻辑。

1.2 SO库逆向抵抗

测试工具：IDA Pro、Ghidra、readelf

测试步骤：

1. 从APK中提取lib/arm64-v8a/下的核心SO文件
2. 拖入IDA Pro，等待分析完成
3. 尝试定位关键函数（如JNI_OnLoad、签名校验函数）

通过标准：

• IDA打开后函数表被剥离，无法通过导出符号定位核心逻辑
• 关键代码段经过控制流平坦化或虚假控制流混淆，无法线性阅读
• 存在VMP虚拟化保护的函数——这类函数在IDA中无法反汇编，只能看到字节码
• 使用readelf -s查看动态符号表，核心函数符号已被strip或混淆

实测经验：某头部厂商的SO加固只做了加壳，用FRIDA-DEXDump在内存中直接dump出解密后的SO，IDA能完整反编译。内存不落地才是真防护。

1.3 资源文件加密

测试工具：Android Studio的APK Analyzer、解压软件

测试步骤：

1. 将APK后缀改为.zip并解压
2. 查看assets/和res/目录下的核心资源文件
3. 尝试直接用文本编辑器打开JSON/HTML等配置文件

通过标准：

• HTML/JS核心业务页面内容为空或已加密
• 硬编码的URL、密钥在资源文件中搜索不到
• 图片资源可被查看（这个通常不加密，加密会影响性能），但配置文件必须加密

1.4 字符串加密强度

测试工具：strings命令、IDA Pro

测试步骤：

1. 对加固后的APK执行strings classes.dex | grep -i "http\|api\|key\|secret"
2. 用IDA打开SO，同样搜索敏感字符串

通过标准：

• API地址、加密密钥、签名公钥等敏感字符串全部加密
• 运行时才解密，静态分析无法直接提取
• 字符串解密函数的调用位置分散，不集中在单一入口

反面教材：某厂商的加固方案把密钥明文存在strings.xml里，用Android Studio的APK Analyzer一搜就出来了，完全裸奔。

第二类：动态防护验证（共4项）

2.1 反调试能力

测试工具：IDA Pro远程调试、GDB、Frida、Xposed

测试步骤：

1. JDWP调试：Android Studio尝试attach应用进程
2. Native调试：IDA Pro通过android_server附加进程
3. ptrace检测绕过：尝试使用Frida的--disable-jit参数

通过标准：

• Android Studio直接attach时，应用闪退或拒绝连接
• IDA附加后应用立即退出
• Frida的Spawn模式和Attach模式均无法正常工作
• 即使使用frida-server的端口重定向/隐藏方案，仍能被检测

进阶测试：尝试使用定制版Frida（改特征、重编译so），看能否绕过。能绕过常规检测算及格，能对抗定制版才算优秀。

2.2 内存防Dump能力

测试工具：FRIDA-DEXDump、MikRom的DexDump、memwatch

测试步骤：

1. 运行加固后的APP，确保核心页面已加载
2. 使用FRIDA-DEXDump尝试dump内存中的DEX
3. 使用Frida -D [pid] -f手动dump内存段

通过标准：

• FRIDA-DEXDump无法dump出完整的原始DEX
• 即使拿到内存中的DEX，核心函数体为空（函数抽取+指令级加密）
• 敏感数据（密码、token）在内存中加密存储，无法通过memwatch直接读取明文

核心原理：DEX在ART虚拟机中以DexFile结构体存在，如果加固方案只在DEX文件层加壳但运行时全量解密，FRIDA-DEXDump就能直接拿下。真正的防dump方案是函数级按需解密，用完立即擦除。

2.3 Hook框架检测

测试工具：Xposed、EdXposed、LSPosed、Frida、Objection

测试步骤：

1. 在已安装Xposed的环境下运行APP，尝试用标准模块Hook核心函数
2. 使用Objection尝试绕过SSL Pinning和Hook关键方法
3. 尝试注入自定义SO

通过标准：

• 检测到Xposed/Frida环境时，应用可正常运行但拒绝核心业务（如支付入口灰掉）
• 或直接闪退/弹窗提示“检测到风险环境”
• Hook关键函数时，返回值被二次校验篡改，绕过失败
• SO注入被检测并阻止，禁止未授权代码加载

区分点：直接闪退是粗暴方案，好的防护是在风险环境下禁用敏感操作但保留基本功能，用户体验和安全性兼具。

2.4 模拟器检测

测试工具：各类模拟器（雷电、夜神、MuMu、BlueStacks）

测试步骤：

1. 在模拟器中安装加固后的APP
2. 尝试正常启动和登录
3. 检查是否有模拟器环境检测逻辑

通过标准：

• 模拟器中APP拒绝启动或提示“不支持该设备”
• 能识别常用模拟器的特征（build.prop、CPU信息、传感器数量）
• 即使使用Magisk Hide和模拟器防检测模块，仍可识别

业务场景适配：纯工具类APP没必要强检测模拟器，但涉及支付、金融交易的应用必须防。

第三类：完整性保护验证（共2项）

3.1 防二次打包

测试工具：apktool、MT管理器、NP管理器、ApkToolBox

测试步骤：

1. 使用apktool d test.apk解包
2. 修改smali/下的任意代码（改一个跳转条件）
3. 使用apktool b重打包
4. 用新签名签名后安装运行

通过标准：

• 重打包后的APP启动时闪退或提示“应用已被篡改”
• 即使重签名后仍无法运行
• 校验必须放在Native层或服务端——仅Java层的签名校验用Frida Hook就能绕过
• 修改任一DEX/SO/配置文件都会触发校验失败

进阶测试：Hook Java层的签名校验函数，看是否能绕过。能过Native层校验才算及格。

3.2 完整性自校验深度

测试工具：UEBA（检测篡改后的行为差异）

测试步骤：

1. 分别修改DEX、SO、配置文件、资源图片
2. 测试哪些修改会触发防护
3. 使用Frida Hook校验函数，尝试绕过校验

通过标准：

• 对DEX和SO的代码段修改必然触发防护
• 校验机制不在单一位置，而是分散在多处
• 即使校验逻辑返回到上层应用，底层仍有二次校验
• 服务端参与校验（本地校验被Hook后，服务端还能兜底）

第四类：兼容性与性能验证（共2项）

4.1 兼容性矩阵

测试覆盖：

• Android 5.0–14.0的全版本（重点测5.x和13+）
• 华为、小米、OPPO、vivo、荣耀、三星的旗舰机+千元机
• 折叠屏（展开态和折叠态）、平板设备
• 覆盖arm64-v8a、armeabi-v7a两种架构

测试场景：

• 安装、首次启动、冷热启动、各页面跳转
• 后台切换、锁屏唤醒、低内存杀进程后恢复
• 边下边玩（APK大于100MB场景）
• 64位设备回退32位兼容模式

通过标准：

• 零闪退、零ANR、零功能异常
• 与加固前行为完全一致
• 各Android版本和机型覆盖率不低于95%

常见兼容性问题：Android 12以上的AndroidManifest.xml的exported属性、Target SDK 31+的PackageManager查询限制、华为鸿蒙的ArkCompiler运行时差异。

4.2 性能损耗基准

测试工具：Android Studio Profiler、PerfDog、Systrace

测试指标与阈值：

测试方法：

• 在测试机上对同一个APK，对比加固前后的Profile数据
• 重点测首次启动（多家固解、类加载、IO操作最密集）
• 运行30分钟后复测，排查内存泄漏
• 反复启动20次，排查资源未释放问题

经验值：正常加固方案启动耗时增加应在5%-10%之间，超过15%用户就会有感知。

第五类：业务数据安全验证（贯穿测试）

5.1 硬编码敏感信息检测

工具：strings、grep、对加固前后包做全局文本搜索通过标准：加固后包中不存在明文密钥、API密钥、后台地址、硬编码token

5.2 本地存储加密

工具：adb shell查看/data/data/[package]/下的SharedPreferences、数据库文件通过标准：本地配置、用户数据、缓存文件已加密，无法直接读取明文

5.3 网络通信防护

工具：Charles、Frida的okhttp3 Hook脚本通过标准：

• 开启了SSL Pinning，Charles无法通过安装证书方式抓包（除非Hook绕过）
• 对核心接口做了应用层二次加密（防中间人）
• 敏感接口返回值加密，无法通过抓包直接看懂

5.4 截屏/录屏防护

工具：系统自带录屏、第三方录屏APP通过标准：在支付、密码输入、敏感信息展示页面，录屏时显示黑屏/界面隐藏

POC测试流程速查表

最终决策清单：12项全过→直接入围；静态或动态任一项被攻破→一票否决；性能超标→按业务容忍度权衡。

测试报告必须包含的信息

1. 测试环境清单：机型、系统版本、root状态、工具版本号
2. 原始包与加固包对比数据：大小、启动耗时、内存占用的AB对比表格
3. 每个测试项的具体操作步骤和截图：证明你确实测过
4. 脱壳尝试的完整记录：跑了哪些工具、是否拿到核心代码
5. 兼容性问题的详细列表和厂商技术支持的回复
6. 是否建议采购、存在哪些风险

照着这份checklist测完，没有哪家加固厂商能糊弄你。记住：不要信厂商的“我们客户有XX银行”，信你自己的测试结果。 如果这12项都能稳稳通过，可以放心签合同。