测试移动应用加固能否被绕过的最佳工具
对比 Apktool、JADX、Ghidra、Frida、Objection 和 LLDB 等手动测试工具，以及 Ostorlab 面向 Android 和 iOS 的自动化移动应用加固与 RASP 评估。
执行摘要（TL;DR）
测试移动应用加固能否被绕过，在不同阶段需要不同的工具。Apktool 用于解码、修改并重新构建 Android 安装包，以进行重打包测试；JADX 和 Ghidra 帮助定位防护逻辑；Frida、Objection 和 LLDB 在运行时对加固和 RASP 控制发起挑战；而 Ostorlab 则在 Android 和 iOS 上自动完成整个评估。
加固可以检测到攻击，却仍然未能保护好应用。在 Ostorlab 对五款银行应用的评估中，有一款应用检测到自己正运行在已 Root 的设备上，却仍然继续进入了登录界面。防护是存在的，问题出在它的响应上。
因此，测试不能只停留在确认是否存在 Root 检测、反调试或证书锁定。团队需要观察应用在这些防护受到挑战时如何响应，以及这种响应能否被绕过。
本指南说明每种工具能验证什么、需要什么专业能力，以及其能力的边界在哪里。它面向在手动工作流与自动化评估之间做选择的移动安全测试人员和 AppSec 团队。
关于本指南： 本指南由 Ostorlab 发布，Ostorlab 本身也被纳入了对比之中。本指南基于官方文档、开源仓库、OWASP 指南和已公开的技术研究。
什么是移动应用加固与 RASP 测试？
移动应用加固是为 Android 或 iOS 应用添加的一组防护措施，用于加大分析、修改和运行时干预的难度。它可以包括代码混淆、防篡改、完整性检查、反调试、反插桩、Root 或越狱检测以及证书锁定。
运行时应用自我保护（RASP）更具体地指在应用运行期间对其进行监控的防护。当 RASP 检测到可疑状况时，它可能会显示警告、限制某项操作或关闭应用。因此，RASP 是更广义的移动应用加固层的一部分。
加固与 RASP 绕过测试检查这些控制是否能检测到预期的攻击状况，以及它们的响应能否被消除或规避。一项防护不能仅仅因为存在或会发出告警就被认定为有效。测试还必须确定应用是否仍然允许该防护本应阻止的行为。
移动应用加固测试工具速览
下列工具均为免费且开源，但没有任何单一工具能覆盖整个评估。每种工具处理流程中的特定环节，从修改应用、定位防护逻辑，到挑战运行时控制并验证结果。
| 工具 | 适用场景 | 移动端覆盖范围 | 所需工作 | 主要限制 |
|---|---|---|---|---|
| Apktool | 为重打包、签名和防篡改测试准备修改后的 APK。 | Android APK | 检查 manifest、资源或 Smali；做一处受控修改；重新构建并重新签名 APK。 | 仅限 Android；重新构建或签名失败必须与应用的加固响应区分开来。 |
| JADX | 在 Android DEX 代码中查找防护检查并追踪其调用者。 | Android DEX 字节码 | 阅读反编译代码，识别需要在运行时测试的判定。 | 反编译可能不完整；原生代码需要另一款分析工具。 |
| Ghidra | 追踪原生防护逻辑，确定 Hook 或补丁的位置。 | Android 原生库；iOS 二进制文件 | 解读反汇编，检查反编译后的函数。 | 加壳或加密的代码可能需要先进行运行时提取才能分析。 |
| Frida | 编写自定义 Hook，以在运行时观察或修改加固和 RASP 检查。 | Android 和 iOS | 建立进程访问、识别函数并调整脚本。 | 反插桩可能在脚本运行前就阻止 Frida。 |
| Objection | 针对常见的 Root、越狱和证书锁定检查，尝试现成的绕过例程。 | Android 和 iOS | 建立 Frida 访问、选择例程并验证响应。 | 依赖 Frida；自定义防护可能需要量身定制的 Hook。 |
| LLDB | 暂停原生执行，以跟踪某项检查或查看变化中的状态。 | Android 和 iOS 原生代码 | 建立调试器访问，解读执行流程、内存和寄存器。 | 操作系统权限和签名限制可能在与加固无关的情况下就阻止附加调试器。 |
开源工具如何融入加固绕过测试
开源加固测试会组合使用多种工具，而不是依赖单一扫描器。Apktool 支持 Android 安装包的检查、修改和重新构建。JADX 和 Ghidra 帮助测试人员定位并理解防护逻辑。Frida、Objection 和 LLDB 则在运行时用于挑战这些防护并观察结果。
这一流程并不总是线性的。一次运行时测试可能揭示出某些线索，促使测试人员回到代码中做进一步分析。
Apktool：为篡改测试重新构建 Android 应用
Apktool 将 Android 应用安装包解码为一种类似项目的结构，其中包含 manifest、资源和 Smali 代码。随后，它可以在做出修改之后重新构建安装包。
在评估中的作用
当加固评估需要修改并重打包 APK 时，Apktool 很有用。测试人员可以对 manifest、资源或 Smali 代码做一处受控修改，重新构建安装包，然后检查完整性、签名或防篡改防护是否能检测到被修改的应用。
这一作用不同于 JADX。JADX 将 DEX 代码呈现为可读的、类似 Java 的代码以供分析，而 Apktool 保留的是一种可供编辑和重新构建的安装包结构。OWASP 将 Apktool 记录为一种解码二进制 manifest、提取资源、将 DEX 文件反汇编为 Smali 并重打包结果的方式。（参见 OWASP 的 Apktool 指南）
测试人员需要具备什么
测试人员必须决定要修改什么，编辑相关的 manifest、资源或 Smali 文件，在安装前重新构建 APK 并为其签名。结果应记录任何失败发生的环节：是在解码、重新构建、签名、安装期间，还是在应用启动之后。
局限性
Apktool 仅限于处理 Android 安装包，本身并不测试运行时防护。它生成的是未签名的 APK，因此签名是一个单独的步骤。重新构建后的应用若无法安装或启动，并不能自动证明加固检测到了修改；原因也可能是构建无效、签名问题或安装包不兼容。Apktool 还说明，某些使用修改过的 OEM 构建工具创建的 APK 无法被解码或重新构建。Apktool 常见问题
当目标是在决定修改什么之前追踪较高层的 Android 防护逻辑时，JADX 提供了更易读的视图。
JADX：调查 Android 防护逻辑
JADX 将 Android DEX 字节码转换为可读的、类似 Java 的代码。测试人员无需运行应用即可搜索 APK、在方法之间跳转并跟踪引用。
在评估中的作用
JADX 有助于定位 Root 检查、反调试逻辑、完整性检查，以及决定应用如何响应的代码。
响应的处理可能发生在原始检查之外的某处。某个方法可能负责检测 Root，而另一个方法则决定是显示警告、关闭应用还是限制某项功能。跟踪这些引用有助于测试人员确定判定点，以便在运行时用 Frida 或调试器进行调查。
测试人员需要具备什么
使用 JADX 需要熟悉 Android 开发和逆向工程，尤其是在类名和控制流经过混淆的情况下。
反编译输出是对字节码的一种解释，而非应用的原始源代码。JADX 可能会重命名或内联类和方法，因此界面中显示的标识符可能与运行时遇到的并不一致。存疑的输出应对照底层的 Smali 代码或控制流图进行核实。JADX 疑难解答指南
局限性
JADX 是一款 Android 分析工具，而非完整的绕过解决方案。它的 Smali 调试器需要一个可调试的应用，或一台已 Root 的设备或模拟器。包含在原生库中、直到启动才解密或在运行时才生成的防护逻辑，同样需要其他工具。
当相关逻辑从 Android 字节码转移到原生库时，Ghidra 可以继续进行调查。
Ghidra：分析原生防护代码
Ghidra 分析编译后的原生代码，包括 Android 的 .so 库以及 iOS 的可执行文件和框架。
在评估中的作用
Ghidra 的反汇编器、反编译器、字符串搜索和函数图，帮助测试人员重建原生防护代码的工作方式。在 Android 上，当 JADX 到达对某个原生库的调用、却无法显示其内部发生了什么时，Ghidra 可以继续进行分析。
即使函数名已被移除，字符串、常量以及函数之间的引用也能揭示出一项可能的防护检查、它的判定分支以及由此产生的应用响应。OWASP 的 Ghidra 指南解释了在审查二进制文件时这些视图如何协同工作。
测试人员需要具备什么
与 JADX 相比，Ghidra 需要更强的原生逆向工程技能。测试人员可能需要修正函数签名、将反编译输出与汇编代码对照，并理解数值如何在寄存器和内存中流动。
通常的目标是确定一项可能的检查或判定点，以便进行运行时测试。在 Ghidra 中找到它，并不能证明它可以被绕过。
局限性
加壳或加密的代码可能在应用运行之前一直处于隐藏状态。Ghidra 的调试器可以将运行中的进程映射回导入的二进制文件并检查运行时内存，但测试人员必须先获得调试访问权限并定位到相关代码。
任何疑似绕过仍需在应用运行期间加以复现。Frida 通常用于评估中的这一环节。
Frida：自定义运行时插桩
Frida 将 JavaScript 注入 Android 和 iOS 进程。它让测试人员能够拦截函数调用、检查其输入和输出，并在应用运行期间改变其行为。
在评估中的作用
Frida 用于挑战防护检查以及对其做出响应的代码。即使最初的检测仍然有效，它也能测试一项防护的行为能否被改变。
在 OWASP 的 Android UnCrackable L1 示例中，应用检测到 Root 并显示警告，然后关闭。一个 Frida Hook 改变了负责关闭应用的函数。Root 检查仍然运行，但应用不再执行其预期的响应。
测试人员需要具备什么
测试人员必须识别相关函数、编写或改写 JavaScript Hook，并验证目标行为是否确实发生了改变。自定义防护可能需要额外的逆向工程，以理解其检查与响应如何关联。
测试环境同样重要。Android 测试通常使用已 Root 的设备，不过 Frida Gadget 也可以嵌入到重打包的应用中。在 iOS 上，已越狱的设备提供更广泛的访问权限，而在未越狱设备上的测试仅限于可调试的应用。
局限性
加固或 RASP 可能在预期的测试开始之前就检测到或阻止 Frida。在 Ostorlab 对五款银行应用的评估中，有一款应用在注入过程中、Frida 脚本输出第一条日志消息之前就终止了。在这种情况下，建立一个可用的插桩会话本身就成了调查中的一个独立环节。
对于常见的绕过技术，Objection 将现成的 Frida 例程打包为开箱即用的命令，提供了一个更快捷的起点。
Objection：现成的绕过功能
Objection 运行在 Frida 之上，将常见的移动测试技术打包进一个交互式控制台。
在评估中的作用
Objection 包含用于尝试绕过已知 Root 和越狱检查、禁用常见证书锁定实现、检查已加载类并监视方法调用的命令。这让测试人员在编写自定义 Frida 脚本之前可以先尝试成熟的技术。
在启动期间运行的检查，可能需要在应用完全启动之前就触达。Objection 支持早期插桩，允许命令或自定义 Frida 脚本在应用恢复运行时加载。
测试人员需要具备什么
测试人员必须确认每条命令改变了什么，以及被评估的防护是否确实被触达。命令成功完成只能说明例程运行了，并不能确立该防护已被绕过。
Objection 还可以用 Frida Gadget 给 Android 应用打补丁。由于这会重新构建并重新签名 APK，测试人员必须判断由此产生的任何失败是来自所尝试的绕过，还是来自完整性或签名检查。
局限性
当 Objection 的现成例程与应用所用的防护相匹配时，它的效果最好。面对自定义防护逻辑，或当应用阻止了底层的 Frida 会话时，它的用处会减弱。
在这些情况下，测试人员通常需要进行代码分析并编写量身定制的 Frida 脚本。如果调查需要逐条指令地跟踪原生执行，LLDB 提供了一种更底层的视图。
LLDB：用调试器检查防护检查
LLDB 让测试人员能够暂停原生代码、逐条指令地单步执行，并检查寄存器、内存和返回值。它是 Xcode 中的默认调试器，也用于 Android 的原生调试。
在评估中的作用
测试人员可以在疑似的防护检查上设置断点，观察它返回的值，并跟踪应用如何响应。LLDB 还可以在受控测试期间改变进程状态。
当测试人员知道某个防护结果存储在何处、但尚不清楚哪个函数会更新它时，它的观察点就很有用。
测试人员需要具备什么
发布版本通常只包含很少有用的符号。测试人员可能需要将 Ghidra 得到的地址和其他发现带过来，然后考虑二进制文件在内存中如何映射。这需要理解汇编、调用约定、寄存器和原生程序流程。OWASP 的 iOS 调试指南涵盖了发布版本中的这些限制。
设备访问权限也会影响 LLDB 能触达的范围。在未 Root 的 Android 设备上，Android Studio 只能附加到可调试的进程。LLDB 处理的是原生层，而非 Java 或 Kotlin 代码。在 iOS 上，发布版应用可能需要一台合适的设备和一个重新签名的、或以其他方式可调试的构建版本。
局限性
未能附加 LLDB 并不自动意味着加固阻止了调试器。操作系统权限、签名要求或应用授权可能在防护被触达之前就阻止附加。
测试人员必须将这些准备阶段的失败，与应用本身明确检测到或阻止调试的情形区分开来。与其他运行时工具一样，成功连接调试器只是开始；最终的证据必须展示目标防护在测试期间的行为表现。
Ostorlab：自动化移动应用加固测试
Ostorlab 的 Mobile Shielding Scan 将防护发现、绕过尝试和验证整合到一次面向 Android 和 iOS 的评估中。它管理测试环境，并使用 AI 智能体来调查应用在其防护受到挑战时如何响应。
Ostorlab 自动完成哪些工作
评估工作流涵盖四个阶段：
- 识别防护。 扫描检查应用是否具备 Root 和越狱检测、完整性检查、反调试、反插桩、证书锁定以及代码或字符串混淆。
- 触达受保护的工作流。 它在真机上运行应用，并浏览各个界面以到达防护被激活的那些点。当某项检查只在登录之后才运行，或在打开某个敏感功能时才触发时，这一点很重要。
- 尝试绕过并跟踪响应。 根据具体防护，尝试可能涉及运行时插桩、重打包、重新签名、隐藏 Root 迹象或修改防护逻辑。智能体检查界面和日志，然后利用警告、崩溃、被阻止的请求和其他响应来指导进一步调查。
- 记录发生了什么。 发现会区分出在攻击尝试中经受住考验的防护，与那些缺失、未生效或被绕过的防护。成功的绕过会附带支撑证据和复现步骤。
您需要提供： 一个 APK、AAB 或 IPA，或通过 Google Play、App Store 或 TestFlight 选定的应用。选择 Mobile Shielding Scan 配置后，您可以选用 Ostorlab 的 Cybermodels，或使用您自己的受支持 AI 提供商密钥。Cybermodels 提供不同的调查投入等级。您还可以提供测试凭据和导航说明，以便扫描能够触达需要身份验证的界面和相关工作流。扫描配置指南
发现是什么样的
结果控制台提供加固概览、类别评级和覆盖信息，以及一项项经过验证的检查。对于正在调查某次绕过的 AppSec 团队来说，有用的细节是解释某一特定防护如何表现的证据。
一个例子来自 Ostorlab 已公开的五款银行应用评估。为调查证书锁定，扫描将应用自身的证书校验器运行了两次。两次运行使用相同的证书、校验器实例和配置的锁定值；其中一次禁用了绕过 Hook，另一次则启用了。
| 观察项 | 禁用 Hook | 启用 Hook |
|---|---|---|
| 两次锁定比较 | 返回 false |
返回 true |
| 证书校验器的判定 | 拒绝证书并抛出异常 | 接受证书且未抛出异常 |
这一受控修改演示了在该测试中对证书校验器的一次绕过。证据来自直接调用校验逻辑：同样的输入在 Hook 生效时，由被拒绝变成了被接受。
这为团队提供了一个具体的失败点以供调查，以及一个在修复后可再次检查的明确条件：当尝试同样的绕过时，校验器是否仍会拒绝该证书。
局限性
Ostorlab 是一个商业平台，因此需要付费访问，主要面向开展可重复评估的安全和工程团队。作为回报，它负责管理测试环境、绕过尝试和证据收集——而这些在手动工作流中需要团队自行搭建和维护。
为测试应用加固绕过选择合适的方法
合适的方法取决于团队是需要发现某项防护、在应用运行期间挑战它，还是自动化更广泛的评估。
- 对于安装包修改和代码分析： 使用 Apktool 解码、修改并重新构建 Android APK，使用 JADX 检查 Android DEX 代码，使用 Ghidra 调查 Android 或 iOS 的原生二进制文件。这些工具支持重打包测试并有助于定位防护检查，但它们本身并不能演示运行时绕过。
- 对于运行时测试： Objection 为常见防护提供现成的例程，而 Frida 通过自定义 Hook 给予测试人员更多控制。当调查需要暂停原生执行并逐条指令地跟踪一项防护判定时，LLDB 很有用。来自 JADX 或 Ghidra 的发现，往往能指导这些运行时测试应聚焦于何处。
- 对于自动化测试： Ostorlab 将防护发现、绕过尝试和证据收集整合进一个自动化工作流。当专家需要更深入地调查某一特定发现时，手动工具仍可与之配合使用。要评估一款受保护的 Android 或 iOS 应用，请了解 Mobile Shielding Scan。
常见问题
哪些工具可以测试 Root 检测、越狱检测和证书锁定能否抵御绕过尝试？
Objection 包含用于常见 Root、越狱和证书锁定检查的例程。当这些例程与应用的实现不匹配时，可以使用 Frida 来创建量身定制的 Hook。Ostorlab Mobile Shielding Scan 在 Android 和 iOS 上自动完成对这些防护领域的测试。在每种情况下，结果都应标明构建版本、设备状态、所触达的工作流以及观察到的行为。
开源工具能否完成一次完整的移动应用加固评估？
当团队具备所需的访问权限和逆向工程专业能力时，它们可以支撑完整的手动工作流。测试人员可以用 Apktool 修改并重新构建 Android 安装包，用 JADX 或 Ghidra 理解某项防护，然后用 Frida、Objection 或 LLDB 挑战它并验证结果。本次对比中没有任何单一开源工具能自动完成每一个阶段，因此团队必须把这些工具串联起来并记录证据。
检测到某项加固功能，是否就证明它能抵御绕过尝试？
不能。找到 Root 检测、反调试或证书锁定代码，只说明存在一项防护。它的有效性要通过挑战该控制、观察应用的响应，并检查受限行为是否仍能被触达来确立。
什么样的证据能证明一次加固绕过成功了？
最有力的证据是将一次受控修改与受保护的判定关联起来。例如，可以在禁用和启用绕过的两种情况下运行同一个校验器和同一份输入，然后比较两种结果。仅仅加载了一个 Hook 或运行着一个插桩会话，并不能证明预期的防护已被绕过。