从一份 IPA 到可验证的证据链：REA 的 iOS 应用结构解剖流水线

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

REA 是面向 AI Agent 的逆向工程工具，iOS 应用结构解剖链路基于单个 IPA 文件即可完成 IPA 逆向取证：先生成带哈希指纹的认证清单，再投影 bundle 结构图谱，最后做 Mach-O 动态库加载的静态追踪，全程不运行目标应用的一行代码。

工具定位：静态 IPA 逆向的四级流水线

REA（Reverse engineer anything with agents）的 iOS 应用结构解剖采用"每一级输出作为下一级输入"的四级流水线，全部环节均为静态分析：

1. 库存（Inventory）——遍历 IPA 内部全部文件，记录哈希指纹与格式，产出inventory_artifact证据；
2. 投影（Projection）——把文件树投影为 bundle 结构图谱，给出每个嵌套组件的布局、角色与解剖信息；
3. 追踪（Tracking）——模拟 dyld（Apple 动态链接器）解析规则，算出每条动态库加载实际命中的文件；
4. 核实（Verify）——用专门工具复核 plist 字段与签名声明。

整条流水线不执行目标应用，动态库追踪基于纯 TypeScript 解析 Mach-O 头，因此可在 Linux 与 CI 环境运行。

生成哈希认证清单

解包后的 IPA 文件树只有路径信息：哪些文件被改动过、各自属于哪个应用容器，单靠目录结构回答不了。所以 IPA 逆向的第一步，是生成一份带哈希指纹的 IPA 认证清单。

对 IPA、DMG、ZIP 或.app目录执行库存操作后，REA 产出一条inventory_artifact证据记录，关键字段如下：

• root_sha256/root_format：根文件的哈希指纹与格式（ipa、dmg等）；
• nodes：各组件的格式、架构、可执行位与内容状态；
• occurrences：每条出现的逻辑路径、声明大小与哈希校验状态（如verified）；
• limitations：无法核实的条目写入该字段，而不是被悄悄丢掉。

这份清单只记录观察到的事实，不解释 plist 或签名语义——后续每个结构结论都能回指到其中某条具体的哈希。

投影 bundle 结构图谱

这一环节即 bundle 结构投影（bundle 是 Apple 平台上把可执行文件、资源与配置打包在一起的应用容器）：把清单交给投影命令，文件树变为带精确路径、内容哈希、检测格式、bundle 解剖信息以及基于路径的桥接假设（JavaScript ↔ 原生配对）的应用结构图。

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

实现位于 src/application/apple/AppleApplicationService.ts，工具契约见 src/contracts/applicationToolContracts.ts。投影过程无执行，每个 bundle 均报告info_plist_path、executable_candidates、signing_paths等字段。APK、ASAR 等其他格式会被直接拒为输入错误。

应用根识别规则分三类：

• IPA：每个Payload/<Name>.app各是一个应用根；
• .app目录：被库存的目录本身即应用根；
• 含应用的目录 / ZIP / DMG：每个最外层<Name>.app（后接Contents/）。DMG 的清单路径形如<image>.dmg/<Volume>/<Name>.app；若只有 DMG 根身份、没有子卷清单，投影标记为partial并注明缺失状态未知。

布局分三种：含Contents/的根归为macos-deep（可执行文件在Contents/MacOS/）；含Versions/的归为versioned-framework（按每个真实Versions/<version>/目录分析）；两者皆无的归为shallow（典型 iOS 应用形态，凭Info.plist判定为ios平台）。

🔍 角色归类：找出隐藏启动项与提权入口

随应用启动的组件与提权点无需逐目录翻查：REA 按路径惯例自动把嵌套组件归类为角色列表，app-extension 与登录项排查直接查表即可。

登录项与特权助手是权限提升点的高频藏身处：排查"这个应用还悄悄装了什么"时优先核对这两类角色；应用扩展、XPC 服务与系统扩展三类角色则用于枚举包内随应用启动的全部原生组件。

追踪 dylib 加载命中路径

清单回答"有什么"，而每条 dylib 加载最终命中哪个文件，靠模拟 dyld 解析规则完成，即 dylib 加载分析：

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

该环节用纯 TypeScript 解析 Mach-O / FAT 头与加载命令，不依赖 Apple 工具，非 macOS 系统也能运行。模拟的搜索链覆盖@executable_path、@loader_path、@rpath，跟随符号链接，并做分级架构兼容（x86_64h进程可加载x86_64）。bundle 内每个可执行文件（主程序、XPC 服务、扩展、登录项、助手）都是独立进程根，各拥有自己的@executable_path。

每条依赖边会列出全部尝试过的候选路径及结果（resolved/absent/architecture-missing/escapes-target等），并给出四级判定：

对 IPA 内的原生二进制，可进一步用 Hopper 等反汇编引擎查看实际汇编，核对清单预测的加载顺序；trace_dylib_resolution在原生调查流程中的位置见 docs/native-investigation.md。

证据边界：涉及 plist 与签名的结论要二次核实

上文结构结论全部基于"路径 + 哈希"，凡涉及 plist 字段或签名声明，须用专门工具复核：

• 投影不读 plist 语义。CFBundleExecutable、URL Scheme、权限描述要对 bundle 的info_plist_path使用inspect_plist读取；签名声明用inspect_signature核查可执行候选。
• AppleDouble 侧车文件（._*、__MACOSX/）会被识别为清单事实，但自动排除在 bundle 角色与解剖组件之外。
• 候选截断是透明的：桥接假设最多序列化 2 MiB，超出时结果携带bridge_candidate_coverage报告省略数量，覆盖度降级为partial。
• 目录型库存即使名为.app也视为独立根；DMG 子卷清单依赖原生 macOS 挂载适配器。

这条链路输出的是观察事实，不是语义解释——"应用声明了某权限""签名包含某 entitlement"这类表述，必须回到inspect_plist/inspect_signature的结果上复核。

🧭 命令速查

完整的语义与状态表见 docs/apple-application-analysis.md；首次使用前的安装与 Provider 配置见 docs/installation.md。

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