企业官网建设流程全解析

• 文档
• 教程
• 网络安全

导读

iOS UnCrackable L2 是 OWASP MASTG（移动应用安全测试指南）官方 Crackmes 系列中的第二关 iOS 逆向挑战，由 Bernhard Mueller 编写。与第一关（L1，纯隐藏字符串提取）不同，L2 的设定是"应用内部藏有秘密，而且这次它不会被篡改"（"This app holds a secret inside - and this time it won't be tampered with!"），即它比 L1 多了一层完整性校验/防篡改防护。本文以该挑战题为核心，完整梳理它的挑战目标、在仓库中的获取方式（Crackmes/iOS/Level_02/UnCrackable-Level2.ipa），并借助仓库内 MASTG-TECH 系列技术文档（IPA 注入、签名、调试、越狱检测绕过、二进制补丁等）与 MASVS-RESILIENCE 测试用例，给出从环境搭建、静态分析、动态插桩到绕过防篡改与反调试的完整实战方案。读完本文，你将掌握针对"带有完整性校验和反调试逻辑"的 iOS 应用进行系统性逆向与绕过测试的完整方法论。

挑战题背景与目标

挑战题定义

仓库中该挑战题的元数据定义见 apps/ios/MASTG-APP-0026.md：

• 标题：iOS UnCrackable L2
• 平台：iOS
• 官方来源：OWASP MAS Crackmes 的 iOS 板块（mas.owasp.org/crackmes/iOS）
• 作者：Bernhard Mueller
• 核心设定：应用内部藏有一个秘密（secret string），并且这次它不会被篡改——暗示与 L1 相比增加了防篡改（anti-tampering）防护机制

与 Android 版 apps/android/MASTG-APP-0004.md（Android UnCrackable L2，"May include traces of native code"，即可能包含原生代码痕迹）相呼应，iOS UnCrackable L2 同样属于"升级版"挑战：测试者不仅要提取隐藏字符串，还要先突破应用自身的完整性校验，否则即使修改了应用也无法正常运行。

挑战题在整个 MASTG 中的定位

这些 UnCrackable 应用是 MASTG 全书反复使用的"活教材"。Crackmes/README.md 明确说明：它们是一组 Android/iOS 移动逆向挑战（collection of mobile reverse engineering challenges），被用作整个 MASTG 的示例，读者也可以纯粹出于兴趣去攻克它们。

从 MASTG 目录结构看，L2 所处的对抗维度属于MASVS-RESILIENCE（抗逆向工程与篡改韧性）类目，与之对应的测试用例是 tests/ios/MASVS-RESILIENCE/MASTG-TEST-0089.md（Testing Anti-Debugging Detection）与 Android 侧的 tests/android/MASVS-RESILIENCE/MASTG-TEST-0046.md。也就是说，攻克 L2 的过程本质上就是一次完整的"防篡改 + 反调试韧性评估"演练。

获取挑战题与初始检查

从仓库获取 IPA

挑战题的 IPA 包存放在仓库中：Crackmes/iOS/Level_02/UnCrackable-Level2.ipa（同目录还配套了 L1 的 UnCrackable-Level1.ipa）。

在开始分析之前，先对 IPA 做基础检查。IPA 本质是 ZIP 压缩包，可以像 techniques/ios/MASTG-TECH-0091.md 中演示的那样解包：

unzip UnCrackable-Level2.ipa

解包后得到Payload/UnCrackable Level 2.app/目录，其中包含主二进制、Info.plist等资源。分析前建议确认主二进制是否被 FairPlay DRM 加密：若从 App Store 获取的二进制通常带有LC_ENCRYPTION_INFO且cryptid为 1，需要先在越狱设备上用 frida-ios-dump 等工具脱壳（详见 techniques/ios/MASTG-TECH-0054.md 的 "Decrypting the App Binary" 一节）；本仓库中的 IPA 为原始发布包，可直接解包分析。

静态侦察：class-dump 与符号枚举

对主二进制进行静态侦察，第一步是用 class-dump 类工具还原 Objective-C 类结构。tools/ios/MASTG-TOOL-0105.md 介绍的ipsw工具可以直接输出 Mach-O 中的 ObjC 类信息，对 universal（fat）二进制可用--arch指定架构：

ipsw class-dump --arch arm64 "UnCrackable Level 2"

输出会呈现AppDelegate、ViewController等类以及它们的方法、属性列表。对于 L2 这种"带防篡改"的应用，可以推断其ViewController中除了buttonClick:（校验输入按钮）之外，还会出现与完整性校验相关的逻辑入口。随后可用rabin2 -I（radare2 家族，见 techniques/ios/MASTG-TECH-0054.md）查看二进制架构与加密标志，用otool -l ... | grep -i LC_ENCRYPTION确认加密状态。

环境搭建：把"不可篡改"的应用装到测试设备上

签名、重打包与安装的选择

L2 的"不会被篡改"意味着直接修改后的 IPA 无法通过代码签名校验。要把它装到测试设备上，需要遵循 techniques/ios/MASTG-TECH-0092.md（Signing IPA files）的完整签名流程：

• 非越狱设备：必须用开发者证书 + provisioning profile 重新签名。标准 Apple 账号只能用修改过的（唯一化）Bundle Identifier；开发者账号可用原始 Bundle ID。
• 越狱设备：可安装 [MASTG-TOOL-0127 等越狱签名禁用工具]（见 techniques/ios/MASTG-TECH-0056.md 的说明）后免签名安装，但如果应用本身带有完整性校验，仅绕过系统签名校验还不够，应用自身的防篡改检查仍会在运行时发现二进制被修改。

常用安装途径（见 techniques/ios/MASTG-TECH-0056.md）：

• Sideloadly（GUI，tools/ios/MASTG-TOOL-0118.md）：自动完成签名与安装，使用标准 Apple 账号时会把 Team ID 追加进包名（如sg.vp.UnCrackable1变为sg.vp.UnCrackable1.QH868V5764）。
• libimobiledevice / ideviceinstaller（tools/ios/MASTG-TOOL-0126.md）：Linux/macOS 命令行安装：

ideviceinstaller -i UnCrackable-Level2.ipa

• ios-deploy（tools/ios/MASTG-TOOL-0054.md）与xcrun devicectl（tools/ios/MASTG-TOOL-0072.md）：macOS 上的命令行方案。

为动态调试打基础：让应用可调试

App Store 的 release 包默认没有get-task-allow权限（无法被调试器附加）。techniques/ios/MASTG-TECH-0147.md（Patching）给出完整流程：用开发 provisioning profile 重新签名（profile 自带get-task-allow = true），即可附加 LLDB。若需注入 Frida Gadget 做动态插桩，可参照 techniques/ios/MASTG-TECH-0091.md：

1. 解包 IPA，创建Payload/UnCrackable Level 2.app/Frameworks/目录；
2. 复制FridaGadget.dylib进去；
3. 用optool install -c load -p "@executable_path/Frameworks/FridaGadget.dylib" -t ...向 Mach-O 注入LC_LOAD_DYLIB加载命令；
4. 重新打包zip -r patched.ipa Payload并签名安装。

安装后需以调试模式启动，否则应用通过 SpringBoard 正常启动会因缺少调试环境而崩溃。techniques/ios/MASTG-TECH-0055.md 给出两种方式：

• iOS 17+：xcrun devicectl device process launch --device <UDID> --start-stopped <BundleID>，然后用 LLDBdevice process attach --pid <PID>附加；
• iOS 16 及更早：idevicedebug -d run <BundleID>或ios-deploy --bundle 'Payload/UnCrackable Level 2.app' -W -d -v。

启动后frida-ps -Ua能看到名为Gadget的进程，frida -U -n Gadget即可连入。

深入应用内部：定位"秘密"与防篡改逻辑

从界面行为反推代码路径

L2 的交互与 L1 相似：界面上有一个输入框、一个 Verify 按钮和提示标签。点击 Verify 后，ViewController buttonClick:会调用某个校验类的方法，比较用户输入与内部 secret。与 L1 不同的是，L2 中校验逻辑很可能被藏进原生代码（native library），或者校验前会先做完整性自检——这正是"it won't be tampered with"的兑现方式。这一点与 Android 版 L2 的架构高度一致：tests/android/MASVS-RESILIENCE/MASTG-TEST-0046.md 指出，处理混淆应用时经常发现开发者把数据和功能"藏"进 native 库，并以 Android L2 的CodeCheck类为例——a(String)方法调用native boolean bar(byte[])，校验实际发生在原生层：

public class CodeCheck { public boolean a(String arg2) { return this.bar(arg2.getBytes()); } private native boolean bar(byte[] arg1); static { System.loadLibrary("foo"); } }

可以推断 iOS L2 也采用了类似"入口在 ObjC 层、核心校验在 C/C++ 原生层"的结构，因此不能只盯着 Swift/ObjC 符号，还要把主二进制中的 native 代码段纳入静态与动态分析范围（techniques/ios/MASTG-TECH-0087.md 专门讨论了 iOS native code tracing）。

静态分析工具链

• ipsw class-dump / swift-dump（tools/ios/MASTG-TOOL-0105.md）：还原 ObjC 类接口与 Swift 类型结构（ipsw swift-dump --arch arm64 ... -V可带地址输出）。
• 反汇编器（如 Ghidra）：定位校验函数与 secret 所在偏移。techniques/ios/MASTG-TECH-0084.md 以 L1 为例演示了完整的地址计算法：在 Ghidra 中得到断点偏移（例如0x100004520），再用 LLDBimage list -o -f得到ASLR 偏移（例如0x70000），最终断点地址 = 偏移和（0x100074520），b 0x100074520后可用po $x0直接打印寄存器里的隐藏字符串。L2 的 secret 读取可以照搬这套流程，但要先绕过它的防篡改与反调试。
• radare2 / rabin2：符号列表与加密标志检查（rabin2 -I ... | grep crypto）。

对抗防篡改：让"不会被篡改"变成"可以被篡改"

防篡改的常见实现与检测点

L2 声称"不会被篡改"，其防篡改机制常见形态包括：

1. 二进制哈希自检：启动时（或校验按钮点击时）计算自身 Mach-O 关键段的哈希，与内置基准比较，不一致则直接退出或显示失败提示；
2. 代码签名校验：调用SecStaticCodeCheckValidity/SecCodeCopySelf等 API 验证自身签名是否被破坏；
3. 与越狱检测联动：越狱设备上CydiaSubstrate、MobileSubstrate等路径的存在也会触发"环境被篡改"的判断。

对抗策略

Document/0x04c-Tampering-and-Reverse-Engineering.md 开宗明义：黑盒测试越来越需要"反编译、打补丁、篡改二进制或活动进程"，而应用也普遍实现防篡改防御；Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md 则给出关键判断："防止调试几乎是不可能的——只要应用公开发布，就可能在攻击者完全控制的不受信任设备上运行，坚决的攻击者终将通过修补二进制或运行时动态修改行为（如 Frida）绕过全部反调试控制"。因此 L2 的防篡改并不是不可战胜的，而是"提高韧性"而非"绝对防护"。

针对 L2 的实操路线：

• 不修改二进制、纯运行时绕过：这是破坏性最小、也最贴合"挑战"精神的方式。直接在内存中对校验结果做 hook，让应用"以为自己没有被篡改"，详见下一节的 Frida 方案。
• 若必须静态修补：先定位自检函数并 NOP 掉比较分支，再整体重签名。注意修补后的哈希值本身会改变，若自检是基于固定基准哈希，必须同时打掉自检逻辑（这正是 techniques/ios/MASTG-TECH-0147.md 强调的"高风险应用在默认代码签名之外还有额外完整性检查，必须连这些额外检查一起修补"的原因）。

动态插桩实战：Frida 绕过防篡改与提取秘密

用 Frida 定位校验函数

注入 Frida Gadget 并启动（见上文"为动态调试打基础"）后，可以用 objection（tools/ios/MASTG-TOOL-0074.md）快速枚举类与方法：

ios hooking list classes ios hooking list class_methods <ClassName>

重点搜索名字含Check、Verify、Tamper、Integrity、Jailbreak的类与方法。

挂钩校验方法的返回值

如果 secret 校验发生在 ObjC 方法里，用frida-trace挂钩即可（参照 techniques/ios/MASTG-TECH-0152.md 的 jailbreak 绕过手法，把"篡改检测"当作"越狱检测"一样处理）：

frida-trace -U -f "Payload/UnCrackable Level 2.app/UnCrackable Level 2" -m "*[ViewController* *Check*]"

生成的 handler 中，用onLeave改写返回值：

onLeave: function (log, retval, state) { console.log("Original return value:" + retval); retval.replace(0); // 强制返回"未篡改/校验通过" console.log("Forced return value:" + retval); }

挂钩原生层函数

若校验逻辑在 C/C++ 原生层（L2 的高概率设计），改用frida-trace的 native 追踪（techniques/ios/MASTG-TECH-0087.md）：

frida-trace -U -i "open" sg.vp.UnCrackable2 # 示例：追踪 open 系统调用

或直接编写 Frida JS 脚本，Module.findExportByName/Interceptor.replace挂钩目标 native 函数，打印参数、返回值，甚至直接调用内部函数把 secret 计算出来。

提取 secret 的三种落地手段

1. 内存断点法：用 Ghidra 找到存放 secret 的指令偏移，LLDB 算好 ASLR 偏移后下断点，命中时po打印寄存器/字符串（完整流程见 techniques/ios/MASTG-TECH-0084.md 的 "Debugging Release Apps" 一节）。
2. Frida 主动调用法：定位校验类后，直接调用其内部方法（如-[ViewController someMethod:]）并读取返回值或内存中的字符串。
3. native tracing 法：追踪strcmp/memcmp等比较函数，观察传入的参数——两个比较参数中通常就有一个是 secret（Android 侧 tests/android/MASVS-RESILIENCE/MASTG-TEST-0046.md 对 native 校验的思路完全适用于 iOS）。

纵深对抗：反调试与越狱检测的绕过

反调试（Anti-Debugging）

L2 的"不可篡改"往往还叠加反调试检测：应用会检测自己是否被ptrace/LLDB 附加，一旦发现就退出或进入异常分支。iOS 上调试器通过task_for_pid获取 Mach task port 后再用 Mach IPC 接口操作进程（详见 techniques/ios/MASTG-TECH-0084.md 对 ptrace/Mach 机制的讲解），因此检测手段也常常围绕ptrace、sysctl（P_TRACED标志）或task_info展开。

针对性的测试与绕过方法，tests/ios/MASVS-RESILIENCE/MASTG-TEST-0089.md（Testing Anti-Debugging Detection）给出了评估框架：尝试附加调试器观察应用反应（弹窗警示、优雅退出、擦除敏感数据、上报后端等），然后评估"能否通过 hook 单个 API 函数就轻松绕过"、"静态/动态定位检测代码的难度"、"是否需要编写自定义代码"以及"绕过的主观难度"。实操中常用 Frida 挂钩：

• ptrace/sysctl：返回伪造值，隐藏P_TRACED标志；
• task_for_pid/mach_vm_read相关检测点：hook 返回值或直接 NOP 掉检测分支。

越狱检测（Jailbreak Detection）

越狱检测常与防篡改一起出现。自动绕过首选 objection 的 jailbreak bypass 模块；手动方案（techniques/ios/MASTG-TECH-0152.md）：

1. 用 radare2 在二进制里 grep 已知字符串（is~+jail），定位isJailbroken之类的方法符号；
2. 用frida-trace -m "-[XxxViewController isJailbroken]"挂钩，在onLeave中retval.replace(0)强制返回"未越狱"。

$ frida-trace -U -f /Applications/... -m "-[JailbreakDetectionVC isJailbroken]" Function [JailbreakDetectionVC isJailbroken] originally returned:0x1 Changing the return value to:0x0

L2 中若存在越狱检测，可采用完全相同的模式处理。

通关后的韧性评估：对照 MASVS-RESILIENCE 检验

完成 secret 提取后，一个合格的测试者还应对 L2 的防护强度做系统性评估（评估维度来自 tests/ios/MASVS-RESILIENCE/MASTG-TEST-0089.md 与 tests/android/MASVS-RESILIENCE/MASTG-TEST-0046.md）：

• 防篡改是否可被轻易绕过：是否 hook 一个 API 就失效？检测逻辑是否分散在多处？是否跨 ObjC 与 native 多层实现？
• 反调试是否有效：附加调试器时应用是否终止或功能异常？检测点是否唯一？是否在 native 层也有自检？
• 检测机制是否有原创性：是否只是从公开资料抄来的标准检查（容易被 objection/Frida 的通用绕过脚本一击击穿）？
• 绕过成本：是否需要编写定制代码？耗时多少？主观难度评分？

如果发现 L2 的防护"太容易被绕过"，可以按照韧性评估标准提出加固建议：增加更多检测手段、将检测逻辑散布到应用各处、与后端联动上报、对检测逻辑做混淆（参照 Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md 中"商业方案通常组合多种技术：未公开的检测技术、多场景触发、每构建独特的检测组合、后端协同验证与 HTTP payload 加密"的思路）。

总结

iOS UnCrackable L2 是一道浓缩了 iOS 应用"韧性对抗"核心要点的挑战题：隐藏的秘密只是表面，真正要过的是防篡改与反调试两道关。本文沿"挑战定义 → 获取与安装 → 静态侦察 → 防篡改对抗 → Frida 动态插桩 → 反调试/越狱绕过 → 韧性评估"的完整链路，给出了可复现的实战方案，并将每一步都锚定到 MASTG 仓库中的对应技术文档（MASTG-TECH-0084、MASTG-TECH-0091、MASTG-TECH-0092、MASTG-TECH-0147、MASTG-TECH-0152）与测试用例（MASTG-TEST-0089）。这套方法论不只适用于刷题——把它迁移到真实 App 的韧性评估中，就是一次标准的 MASVS-RESILIENCE 验证流程。

• 文档
• 教程
• 网络安全