IPA 结构分析实战用 REA 静态分析四步看清启动项与 dylib 加载链【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea拆开一个 IPAApple 分发应用用的封装格式会得到一棵完整的文件树但树本身回答不了几个关键问题内容是否被动过、某个文件属于哪个 bundle、哪些嵌套组件会随应用一起启动。REA 是一款面向 AI Agent 的逆向工程工具它的 Apple 应用分析链路走完了「认证清单 → 结构投影 → 动态库加载追踪」全程静态分析不运行目标应用的一行代码。读完本文你可以在 IPA 或 .app 上独立跑通整条链路并清楚知道哪些结论还需要二次核实。动手前先划清这条静态链路的边界这条链路给出的全部是观察事实。清单记录的是路径、哈希和权限位投影给出的是结构与角色归类加载追踪给出的是按 dyldmacOS 的动态链接加载器规则做的模拟解析。过程不执行目标代码也不依赖 Apple 工具链Linux 上一样能跑。边界同样明确链路不读取 plist 语义、不解析签名声明、不声称任何运行时行为。凡是应用声明了某权限签名包含某 entitlement这类表述都不属于这条链路的结论范围需要专门工具二次核实见第三节。候选文件字节读不出来时条目会写进limitations字段而不是被悄悄丢掉。这条边界也是整套流程的承诺后面每个结论都能回指到清单里某条具体哈希。那就从建立清单开始。四步主线从清单到加载链第一步建一份带哈希指纹的库存清单清单要回答有什么、是否完整。这是整条链路的信任基础。怎么跑对 IPA、DMG、ZIP 或 macOS.app目录执行库存操作rea inspect-artifact MyApp.ipa --json跑完这一步你会多拿到一条inventory_artifact证据记录相当于给这箱文件附上了带指纹的装箱单。盯这几个字段root_sha256/root_format是根文件的哈希指纹与格式ipa、dmg等nodes记录每个组件的格式、架构、可执行位、内容状态occurrences记录每条出现的逻辑路径、声明大小和哈希校验状态如verifiedlimitations收走所有无法核实的条目。容易踩的坑清单只记录观察到的事实不解释 plist 与签名语义别拿它直接下语义结论。第二步把文件树压成应用结构图投影命令把清单的文件树变成一张带精确路径、内容哈希和解剖信息的结构图。怎么跑把上一步的证据交给投影命令rea project-apple-application-graph {inventory_evidence:[inventory_artifact Evidence]}实现见 AppleApplicationService.ts工具契约见 applicationToolContracts.ts。盯这几个字段应用根识别规则是——IPA 里每个Payload/Name.app各是一个应用根.app目录以被库存的目录本身为根目录 / ZIP / DMG 取每个最外层Name.app后接Contents/。bundles部分逐个列出应用根及其嵌套 bundle报告info_plist_path、executable_candidates可执行候选、signing_paths签名路径。布局分三类macos-deep含Contents/可执行文件在Contents/MacOS/、versioned-framework含Versions/按每个真实版本目录分析、shallow无上述结构典型 iOS 形态凭Info.plist判定为ios平台。容易踩的坑DMG 只有根身份、没有子卷清单时投影会标记partial并说明缺失状态未知APK、ASAR 等其他格式会被直接拒为输入错误。第三步按路径惯例筛出启动项与提权点REA 按路径惯例把嵌套组件自动归类这个应用还悄悄装了什么不用逐个目录翻。怎么跑不需要额外命令直接在第二步输出的bundles组件里按角色筛选即可。盯这张角色对照角色路径惯例通常是什么app-extension*.appex应用扩展xpc-service*.xpcXPC 服务framework*.frameworkframeworksystem-extension*.systemextension系统扩展login-itemContents/Library/LoginItems/登录项privileged helperContents/Library/LaunchServices/特权助手容易踩的坑登录项和特权助手是权限提升点的高频藏身处排查时优先看这两类。第四步查每条 dylib 的加载落点加载追踪回答每条 dylib 加载最终命中哪个文件——REA 用纯 TypeScript 解析 Mach-O / FAT 头与加载命令来模拟 dyld 解析规则在非 macOS 系统上也能跑依旧不执行一行目标代码。怎么跑rea trace-dylib-resolution MyApp.app --json跑完这一步你会多拿到一张 dyld 解析图每条依赖边尝试过的全部候选路径与结果外加四级判定。盯这几个字段bundle 内每个可执行文件主程序、XPC 服务、扩展、登录项、助手都是独立进程根拥有各自的executable_path解析模拟覆盖executable_path、loader_path、rpath搜索链、符号链接跟随以及分级架构兼容x86_64h进程可加载x86_64。每条边的候选结果会标resolved/absent/architecture-missing/escapes-target等边级判定则按下表处理看到该状态你该做什么resolved根内有一个镜像成功加载该依赖已定无需再查conditional根内可解析但更早的根外候选若存在于运行系统则优先——确认运行系统上是否存在同名库unresolved根内所有候选确定缺失或不可用——核对包内是否漏装依赖文件undetermined候选在根外或依赖运行环境——留待设备或目标环境二次验证想核对清单预测的加载顺序还可以用 Hopper 等反汇编引擎查看 IPA 内原生二进制的实际汇编trace_dylib_resolution在原生调查流程中的位置见 docs/native-investigation.md。容易踩的坑conditional与undetermined的结论依赖运行环境别直接写成一定会加载 X。加载链路到此结束但它全是模拟结论涉及 plist 与签名的内容该去哪里核实下一节讲清。二次核实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 挂载适配器。核实边界划完最后用一张速查表收口。速查一张表看懂命令、输入与坑步骤命令输入产出易踩坑库存清单rea inspect-artifact MyApp.ipa --jsonIPA / DMG / ZIP /.app目录inventory_artifact证据root_sha256、nodes、occurrences、limitations清单只记事实不解释语义结构投影rea project-apple-application-graph {inventory_evidence:[inventory_artifact Evidence]}inventory_artifact证据应用根识别、bundles解剖、桥接假设DMG 缺子卷清单时标记partial角色归类随投影输出按角色筛选同上启动项与提权点清单AppleDouble 侧车不参与角色归类加载追踪rea trace-dylib-resolution MyApp.app --json.app或 Mach-O 可执行文件dyld 加载解析图与未决发现conditional/undetermined依赖运行环境二次核实inspect_plist/inspect_signatureinfo_plist_path/ 可执行候选plist 字段取值与签名声明声明权限 / entitlement表述必须复核完整静态分析链路到此走了一遍清单建立信任、投影给出结构、角色定位启动项、加载追踪回答落点、核实工具补上语义。首次使用前请先阅读 安装文档 完成安装与 Provider 配置更完整的语义与状态表见 Apple 应用分析文档。【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考