REA 实战指南静态解剖 iOS 应用结构从 IPA 清单到 Mach-O 加载追踪【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea拿到一个 IPA 包想知道它内部改过什么、装了什么组件、每条动态库最终会加载到哪REAReverse engineer anything with agents提供的是一条全程静态的 iOS 逆向链路IPA/DMG 认证清单、bundle 结构投影、Mach-O 动态库加载模拟整个过程不执行目标应用的一行代码。本文按事实 → 结构 → 行为 → 语义边界四个分析层次拆解这套流程。第一层·事实带哈希指纹的认证清单解包得到的文件树只记录路径不记录完整性——它无法回答内容是否被动过。所以 iOS 逆向的第一步是把裸文件树升级成带指纹的证据记录。对 IPA、DMG、ZIP 或 macOS.app目录执行库存操作后REA 产出一条inventory_artifact证据记录。输入是一个压缩包或目录输出是四组结构化事实root_sha256/root_format根文件的哈希指纹与格式标识ipa、dmg等nodes每个组件的格式、架构、可执行位、内容状态occurrences每次出现的逻辑路径、声明大小与哈希校验状态如verifiedlimitations无法核实的条目显式写入该字段而不是被静默丢弃。这份清单的职责刻意收窄为记录观察到的事实它不解释 plist 或签名语义。这个设计保证了后面每一层结论都能回指到清单中某条具体的哈希审计链完整。第二层·结构文件树到 bundle 图谱的投影投影命令与应用根识别把清单证据交给投影命令文件树就变成一张带精确路径、内容哈希和解剖信息的结构图rea project-apple-application-graph {inventory_evidence:[inventory_artifact Evidence]}实现位于 src/application/apple/AppleApplicationService.ts工具契约定义在 src/contracts/applicationToolContracts.ts。命令对每个 IPA / DMG /.app做无执行投影输出精确路径、内容哈希、检测到的格式、bundle 解剖信息以及基于路径的桥接假设JavaScript ↔ 原生配对。应用根application root的识别规则分三种情况IPA每个Payload/Name.app各自是一个应用根.app目录被库存的目录本身即根含应用的目录 / ZIP / DMG每个最外层Name.app后接Contents/各是一个根。DMG 的清单路径形如image.dmg/Volume/Name.app如果只有 DMG 根身份而缺少子卷清单投影会把结果标记为partial并说明缺失状态未知。APK、ASAR 等其他容器格式会被直接拒为输入错误。bundles部分列出每个应用根及其全部嵌套 bundle逐个报告info_plist_path、executable_candidates可执行候选与signing_paths签名路径。布局判定分三类macos-deep含Contents/可执行文件位于Contents/MacOS/versioned-framework含Versions/按每个真实版本目录分别分析shallow无上述结构是典型 iOS 应用形态凭Info.plist判定为ios平台。嵌套组件的角色自动归类随应用启动的组件和提权入口不需要逐个目录翻——REA 按路径约定自动把嵌套组件归入角色路径惯例角色*.appex应用扩展app-extension*.xpcXPC 服务xpc-service*.frameworkframework*.systemextension系统扩展system-extensionContents/Library/LoginItems/登录项login-itemContents/Library/LaunchServices/特权助手privileged helper归类逻辑实现在 src/domain/apple/appleBundleAnatomy.ts。登录项与特权助手是权限提升的高频落点排查应用还悄悄装了什么时直接看角色列表即可。需要留意的一个细节AppleDouble 侧车文件._*、__MACOSX/会作为清单事实被识别但自动排除在 bundle 角色与解剖组件之外不会污染结构图。第三层·行为dylib 加载命中的静态模拟清单回答有什么每条依赖边最终命中哪个文件则要靠对 dyldmacOS 动态链接加载器解析规则的静态模拟rea trace-dylib-resolution MyApp.app --json这条链路用纯 TypeScript 解析 Mach-O / FAT 头与加载命令不依赖任何 Apple 工具在非 macOS 系统上同样可跑。解析逻辑位于 src/domain/apple/dylibResolution.ts。它模拟的 dyld 行为包括executable_path、loader_path、rpath搜索链展开符号链接跟随以及分级架构兼容例如x86_64h进程可加载x86_64镜像。bundle 内每个可执行文件——主程序、XPC 服务、扩展、登录项、助手——都是独立进程根各自拥有独立的executable_path基准。每条依赖边会列出所有尝试过的候选路径及各自结果resolved、absent、architecture-missing、escapes-target等。dylib 四级判定速查在候选级结果之上每条边给出四级汇总判定状态含义resolved根内有一个镜像成功加载conditional根内可解析但更早的根外候选若存在于运行系统则优先unresolved根内所有候选确定缺失或不可用undetermined有候选落在根外或依赖运行环境无法定论trace_dylib_resolution在原生调查流程中的位置见 docs/native-investigation.md。语义边界哪些结论必须二次核实前三层输出全部基于路径 哈希凡涉及 plist 字段或签名声明的内容必须回到专门工具复核投影不读 plist 语义。CFBundleExecutable、URL Scheme、权限描述等字段需对 bundle 的info_plist_path使用inspect_plist签名声明则用inspect_signature核查可执行候选。候选截断是透明机制桥接假设最多序列化 2 MiB超出时结果携带bridge_candidate_coverage报告省略数量覆盖度相应降级为partial。目录型库存即使命名为.app也按独立根处理DMG 子卷清单依赖原生 macOS 挂载适配器跨平台使用时注意这一限制。这条边界的实际意义任何应用声明了某权限签名包含某 entitlement的表述在拿到inspect_plist/inspect_signature的结果之前都不应写进结论。速查表分析层次命令 / 工具输入输出事实库存操作IPA / DMG / ZIP /.app目录inventory_artifact哈希指纹、格式、可执行位、limitations结构rea project-apple-application-graphinventory_artifact证据应用根识别、bundles解剖、角色归类、桥接假设行为rea trace-dylib-resolution.app或 Mach-O 可执行文件dyld 加载解析图、候选级结果、四级判定语义inspect_plist/inspect_signatureinfo_plist_path/ 可执行候选plist 字段取值与签名声明延伸阅读完整的语义与状态定义docs/apple-application-analysis.md安装与 Provider 配置docs/installation.md原生调查流程全貌docs/native-investigation.mdApple 应用服务实现src/application/apple/【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考