隆重推出 Ostorlab Mobile Shielding Scan

移动应用加固很容易被绕过。意志坚定的攻击者无论如何都能突破，所以测试它毫无意义。

这种观点要求加固兑现一个它从未打算做出的承诺。

加固的目的并不是让应用无法被逆向工程，而是让篡改、插桩、流量拦截和代码分析变得困难得多。

真正的问题在于它能形成多大的阻力，尤其是在 AI 驱动的逆向与插桩时代。

Root 检测可能存在，却无法抵御现代的隐藏技术。证书锁定可能保护了一条网络路径，却让另一条路径暴露在外。完整性检查可能检测到了修改，却仍允许应用继续运行。

知道某项防护存在是有用的。知道有人攻击它时会发生什么，才能真正让团队心里有底。同时也能知道，您花大价钱购买的加固方案是否物有所值。

这正是 Ostorlab 全新的 Mobile Shielding Scan 所要展示的内容。

扫描会攻击它发现的防护

Mobile Shielding Scan 评估 Android 和 iOS 应用如何抵御逆向工程和篡改。

它首先分析应用，识别 Root 和越狱检测、防篡改和完整性控制、反调试、反插桩、证书锁定，以及代码或字符串混淆。

随后，它在真机上运行应用，并在其各个工作流程中导航，以到达这些防护措施被激活的位置。有些控制措施只在身份验证之后、支付过程中或打开敏感功能时才会运行。如果防护在实际使用中从未被触发，那么仅仅找到底层代码是不够的。

一旦到达某项控制措施，扫描就会尝试攻破它。

它可以对应用重新打包和重新签名，使用 Frida 等工具附加运行时插桩，隐藏设备已 Root 的痕迹，拦截网络流量，修补应用或库代码，以及操纵完整性检查。

AI 智能体驱动整个调查过程。它们观察界面、读取日志，并解读应用的响应方式。崩溃、警告对话框、被阻止的请求、静默退出，或悄然停止运行的工作流程，都可能揭示防御机制是否做出了反应。

智能体利用这些证据选择下一种技术并再次尝试。这一过程遵循与人工逆向工程评估相同的基本循环：观察、攻击、解读、调整。

扫描既可以针对上传的构建版本运行，也可以直接从应用商店页面运行。

三项防护，直接在设备上被修补

以下示例基于一次真实扫描，已删除可识别的细节。

一款银行应用在其原生库 libsecurity.so 和 DEX 代码中实现了三项客户端防护：

• JNI_OnLoad 中的检查会扫描 /proc/self/maps 以查找 Frida 痕迹，并搜索 su 二进制文件和测试密钥。如果发现任何可疑内容，就会调用 _exit(1)。
• 一项原生完整性检查会对库自身的字节计算 CRC32 校验和，并将其与存储在某个标记字符串旁边的值进行比较。
• Java 方法 HookDetector.isHooked() 会搜索进程内存映射、线程名称以及 Frida 的默认端口 27042 和 27043。

从纸面上看，该应用具备反插桩、Root 检测和完整性保护。其弱点在于，每一项控制措施所依赖的文件和判定逻辑都完全存储在设备上。

该应用使用了 extractNativeLibs=false，这使得原生库以未压缩的形式保留在已安装的 APK 中，并直接从那里加载。其 DEX 代码从设备的 VDEX 文件中执行。在已 Root 的设备上，两者都可以被就地修改。

扫描修补了 JNI_OnLoad 中的终止分支，使其走正常的返回路径，而不是调用 _exit(1)。由于修改库会改变其校验和，扫描重新计算了 CRC32 值，并将新结果写入存储字段。完整性检查仍在继续运行——但它现在认为被修补的库是有效的。

随后，它修改了 VDEX 文件中的 HookDetector.isHooked()，使其始终返回 false。修改完成后，扫描修复了代码正确加载所需的 DEX Adler-32 和 SHA-1 校验和。

这些修改都不需要重新构建、重新打包或重新签名应用。

应用的签名检查并未阻止这次攻击，因为 Android 在安装期间已缓存了原始签名证书，并且不会重新验证磁盘上被修改的文件。

在应用了全部三个补丁之后——并且 /proc/self/maps 中仍然可见 Frida 痕迹——该应用维持了超过一分钟的已认证会话，在多个界面之间切换，并通过了多次后台完整性检查，没有做出任何反应。

这三项防护在原始构建版本中确实存在且处于启用状态。但由于每一项都依赖客户端代码，没有独立的服务器端确认，因此这三项防护都可以在它们本应保护的设备上被修改。

检查清单会报告反插桩、Root 检测和完整性保护均已存在。而主动测试则准确展示了如何将每一项防护修补掉。

有证据支撑的结论

每项防护在做出反应并坚守住时被标记为 Secure，在缺失、未启用或被绕过时被标记为 Hardening。如果应用继续正常运行，仅有检测是不够的。

失效的防御会附带可复现的绕过步骤。成功的防御则在攻击下得到确认。发现在报告前都经过验证，并且可以提出质疑，或根据新的指导重新运行。

每一个版本都可能改变结果

一次构建变更或 SDK 升级就可能削弱加固，却不会导致应用出错，也不会触发交付流水线的告警。

重复扫描可以显示在当前发布的应用和构建版本中哪些防护依然有效。

了解您的加固能够抵御什么

Mobile Shielding Scan 会显示哪些防御守住了，哪些失效了，以及结果是如何得到证明的。

加固并不需要让应用无法被攻击。它需要形成阻力——并证明它确实做到了。

测试您的移动应用加固能够抵御什么。