REA 实战指南：用静态分析把一份 iOS 应用解剖到底

REA 实战指南：用静态分析把一份 iOS 应用解剖到底

【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea

手里只有一个 IPA 文件，要回答三个问题：内容被改过没有？应用还悄悄装了什么？它运行时会去加载哪些库？这套活可以完全交给 REA——一款面向 AI Agent 的逆向工程工具，它对 IPA 做 iOS 逆向分析时全程静态，一行目标代码都不执行，交付物却是一整套可复核的证据链。

第一份交付物：带哈希指纹的证据清单

对 IPA 执行库存操作后，你拿到的不是解压出来的散文件，而是一条inventory_artifact证据记录。它像一张开箱验货清单：树上有几件货、每件货的 SHA-256 指纹、所在路径、声明大小，全部在册。关键字段如下：

• root_sha256/root_format：根文件的指纹与格式（ipa、dmg等）；
• nodes：每个组件的格式、架构、可执行位与内容状态；
• occurrences：每条出现的位置、声明大小、哈希校验状态（如verified）；
• limitations：核不了的条目写进这个字段，而不是被静默丢弃。

这张清单刻意只记账、不释义：它不解析 Info.plist，不解释签名声明，也不声称观察到任何运行时调用。清单上的每个后续结论，都能回指到某条具体哈希。做完这一步，你手里多了一份"改动检测"的基线：将来任何一次比对，都是哈希对哈希。

第二份交付物：bundle 结构图谱

把清单喂给投影命令，文件树就变成一张应用结构图：

rea project-apple-application-graph '{"inventory_evidence":[<inventory_artifact Evidence>]}'

这条命令对每个 IPA / DMG /.app做无执行投影，产出精确路径、内容哈希、检测到的格式、bundle 解剖信息和基于路径的桥接假设。实现位于 src/application/apple/AppleApplicationService.ts，工具契约在 src/contracts/applicationToolContracts.ts。

应用根的识别规则按库存类型分三种情况：

DMG 的清单路径形如<image>.dmg/<Volume>/<Name>.app；若只有 DMG 根身份、没有子卷清单，投影会标记为partial，并说明缺失状态未知。APK、ASAR 等其他格式会被直接拒为输入错误。

bundles部分逐个列出应用根与全部嵌套 bundle，报告parent_path、info_plist_path、executable_candidates（可执行候选）、signing_paths（签名路径）。布局分三类：

• macos-deep：含Contents/，可执行文件位于Contents/MacOS/；
• versioned-framework：含Versions/，按每个真实版本目录分析，不依赖Versions/Current软链；
• shallow：无上述结构，根上有Info.plist即判定为ios平台——典型的 iOS 应用形态。

图上还有一层桥接假设：把每个应用根内的 JavaScript 与原生组件按路径两两配对，作为"这对脚本可能绑定那套原生代码"的候选线索。它是路径推断，不是绑定证明；序列化上限 2 MiB，超出时结果里的bridge_candidate_coverage会报出省略数量，覆盖度降为partial。投影同时会给出运行时族提示（匹配ReactNative.framework、Flutter.framework、UnityFramework.framework、hermes.framework这类完整路径段），但同样只是库存推导，不是加载观测。做完这一步，你手里多了一张带解剖信息的结构图，能直接回答"里面装了什么、分别在哪"。

第三份交付物：嵌套组件角色清单

结构图里的嵌套组件，REA 按路径惯例自动归入角色，不用你逐个目录翻。iOS 应用逆向里最值得盯的两类在这里一览无余：

登录项和特权助手是提权点的高频藏身处：前者决定"开机自动运行什么"，后者对应 SMJobBless 这类以更高权限驻留的服务。排查"这个应用还悄悄装了什么"，直接看角色列表即可。做完这一步，你手里多了一份可读的启动项与驻留组件清单，每个条目都能落回结构图上的精确路径。

第四份交付物：动态库加载完整地图

清单回答"有什么"，加载地图回答"每条 dylib 加载最终命中哪个文件"：

rea trace-dylib-resolution MyApp.app --json

对 bundle 里每个可执行文件做完整的 Mach-O 动态库追踪。解析用纯 TypeScript 实现，直接读 Mach-O / FAT 头与加载命令，不依赖 Apple 工具，非 macOS 系统上也能跑。它按 dyld（macOS 的动态链接加载器）的规则模拟解析：@executable_path、@loader_path、@rpath搜索链，软链跟随，分级架构兼容（x86_64h进程可加载x86_64）。bundle 内每个可执行文件——主程序、XPC 服务、扩展、登录项、助手——都是独立的进程根，各持一个@executable_path。

每条依赖边会列出所有尝试过的候选路径及其结果（resolved、absent、architecture-missing、escapes-target等），再落到四级判定：

想要更硬的核对，把产物交给 Hopper 等反汇编引擎看实际汇编，对照静态预测的加载顺序：

trace_dylib_resolution在原生调查流程中的位置，见 docs/native-investigation.md。做完这一步，你手里多了一张带判定等级的加载解析图，外加一批可直接跟进的未决发现。

收尾：核实边界与二次核实

以上所有结论都建立在"路径 + 哈希"之上。凡涉及 plist 字段或签名声明的内容，必须回到专门工具上二次核实：

• 投影不读 plist 语义。CFBundleExecutable、URL Scheme、权限描述，对 bundle 的info_plist_path用inspect_plist核查；签名声明则用inspect_signature检查可执行候选。
• AppleDouble 侧车文件（._*、__MACOSX/）是清单事实，但自动排除在 bundle 角色与解剖组件之外。
• 目录型库存即使名为.app也视为独立根；DMG 子卷清单依赖原生 macOS 挂载适配器。

边界提醒：这套链路输出的是观察事实，不是语义解释。任何"应用声明了某权限""签名包含某 entitlement（签名中携带的权限声明）"的表述，都必须回到inspect_plist/inspect_signature的结果上复核。

速查表：

完整的语义与状态定义在 docs/apple-application-analysis.md；首次使用前按 docs/installation.md 完成安装与 Provider 配置即可开工。

【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea