用 REA 解剖 iOS IPA4 步从哈希清单走到 dylib 加载追踪【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea输入是一份 iOS 应用的 .ipa 文件。不执行目标代码的一行REA面向 AI Agent 的逆向工程工具静态走完三步哈希认证清单、bundleApple 应用容器结构图谱、Mach-OApple 平台二进制格式动态库加载追踪最后给出三份可核查的结论——包内容是否被改动、组件归属哪个应用根、每条 dylib 依赖落在哪个文件。IPA 文件树为什么不能直接信先建立哈希证据unzip解包只留下一堆路径。内容是否被动过、条目是否可读、组件归属哪个应用树里都看不见。所以第一步是产出一条inventory_artifact库存证据记录后续所有结论都要能回指到它root_sha256根文件的哈希指纹整条链路的唯一锚点nodes各组件的内容派生格式、架构与可执行位occurrences每条出现的逻辑路径、声明大小和哈希校验状态limitations无法核实的条目写在这里而不是被静默丢弃。iOS IPA 库存步骤生成 inventory_artifact 认证清单每个文件都有名字却没有一个能证明它没被动过。执行库存命令输出落到证据包rea inspect-artifact My.ipa --evidence_output evidence.json --json接受的输入是 IPA、DMG、ZIP、macOS.app目录。输出里的关键事实每个节点只报内容派生格式同一份字节在不同路径拥有独立角色无法读取的加密成员进unavailable_components整体覆盖度降级为partial提供的页面能重建完整库存时覆盖度为complete-within-inventory否则为partialpartial只表示部分未知不表示确实缺失。这条证据记录只登记观察到的事实。它不解释 plist 或签名语义也不声称任何运行时行为。用 project-apple-application-graph 投影 bundle 结构图谱文件树说清了位置说不清归属。哪些组件属于应用哪些只是安装器杂物投影命令一次给出rea project-apple-application-graph {inventory_evidence:[inventory_artifact Evidence]}应用根按输入形态识别输入形态识别出的应用根IPA每个Payload/Name.app各是一个根.app目录被库存的目录本身含应用的目录 / ZIP / DMG每个最外层Name.app后接Contents/DMG 的清单路径形如image.dmg/Volume/Name.appAPK、ASAR 等其他格式会被直接拒为输入错误。布局分三类macos-deep含Contents/可执行文件在Contents/MacOS/、versioned-framework含Versions/按每个真实版本目录分析、shallow两者皆无典型 iOS 形态凭根下Info.plist判定为ios平台。角色按路径约定归类全部自动*.appex→app-extension*.xpc→xpc-service*.framework→framework*.systemextension→system-extensionContents/Library/LoginItems/*.app→login-itemContents/Library/LaunchServices/下的文件计入特权助手。登录项和特权助手是启动项与提权入口的高频藏身处排查应用还悄悄装了什么直接看这份角色列表。实现见 src/application/apple/AppleApplicationService.ts工具契约见 src/contracts/applicationToolContracts.ts。用 trace-dylib-resolution 追踪 Mach-O 动态库加载知道包里有什么之后还要知道每条 dylib 加载最终命中哪个文件。这一步模拟 dyldmacOS 动态链接加载器的解析规则纯 TypeScript 解析 Mach-O / FAT 头不依赖 Apple 工具非 macOS 主机上也能跑rea trace-dylib-resolution MyApp.app --jsonbundle 内每个可执行文件主程序、XPC 服务、扩展、登录项、助手都是独立进程根各自持有executable_path。搜索按executable_path、loader_path、rpath链展开跟随符号链接架构分级兼容x86_64h进程可加载x86_64。每条依赖边列出所有尝试过的候选路径及其结果resolved、absent、architecture-missing、not-loadable、platform-mismatch、outside-target、escapes-target、undetermined。整条边的四级判定如下边状态含义resolved根内有一个镜像成功加载且更早的候选均可定论conditional根内可解析但更早的根外候选可能抢占unresolved根内候选确定缺失或不可用undetermined候选在根外或依赖运行环境无法定论这是静态模型不读取目标设备的 CPU也不证明设备会执行哪个 slicerequired-load-unresolved等 findings 是推导出的推断不是观察到的事实。想核对实际汇编、验证清单预测的加载顺序可配合 Hopper 等反汇编引擎流程见 docs/native-investigation.md。iOS 应用结构结论复核哪些不能直接下结构结论都建立在路径 哈希上。以下表述必须用专门工具复核后再使用CFBundleExecutable、URL Scheme、权限描述投影不读 plist 语义对 bundle 的info_plist_path用inspect_plistentitlement 等签名声明对可执行候选用inspect_signature核查earlier-rpath-candidate-absent只是路径级推断dyld 实际加载哪个镜像要凭签名元数据二次确认AppleDouble 侧车._*、__MACOSX/是清单事实但被排除在 bundle 角色与解剖之外别误计成应用组件。完整语义与状态表见 docs/apple-application-analysis.md。全链路速查表命令、输入与输出步骤命令输入输出库存认证rea inspect-artifact My.ipa --evidence_output evidence.json --jsonIPA / DMG / ZIP /.appinventory_artifact证据哈希、格式、limitations结构投影rea project-apple-application-graph {inventory_evidence:[inventory_artifact Evidence]}库存证据应用根、bundles布局、角色、桥接假设加载追踪rea trace-dylib-resolution MyApp.app --json.app或 Mach-O 可执行文件dyld 候选路径与四级判定、findings语义复核rea inspect-plist path/inspect_signatureinfo_plist_path/ 可执行候选plist 取值、签名声明【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用 REA 解剖 iOS IPA：4 步从哈希清单走到 dylib 加载追踪
用 REA 解剖 iOS IPA4 步从哈希清单走到 dylib 加载追踪【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea输入是一份 iOS 应用的 .ipa 文件。不执行目标代码的一行REA面向 AI Agent 的逆向工程工具静态走完三步哈希认证清单、bundleApple 应用容器结构图谱、Mach-OApple 平台二进制格式动态库加载追踪最后给出三份可核查的结论——包内容是否被改动、组件归属哪个应用根、每条 dylib 依赖落在哪个文件。IPA 文件树为什么不能直接信先建立哈希证据unzip解包只留下一堆路径。内容是否被动过、条目是否可读、组件归属哪个应用树里都看不见。所以第一步是产出一条inventory_artifact库存证据记录后续所有结论都要能回指到它root_sha256根文件的哈希指纹整条链路的唯一锚点nodes各组件的内容派生格式、架构与可执行位occurrences每条出现的逻辑路径、声明大小和哈希校验状态limitations无法核实的条目写在这里而不是被静默丢弃。iOS IPA 库存步骤生成 inventory_artifact 认证清单每个文件都有名字却没有一个能证明它没被动过。执行库存命令输出落到证据包rea inspect-artifact My.ipa --evidence_output evidence.json --json接受的输入是 IPA、DMG、ZIP、macOS.app目录。输出里的关键事实每个节点只报内容派生格式同一份字节在不同路径拥有独立角色无法读取的加密成员进unavailable_components整体覆盖度降级为partial提供的页面能重建完整库存时覆盖度为complete-within-inventory否则为partialpartial只表示部分未知不表示确实缺失。这条证据记录只登记观察到的事实。它不解释 plist 或签名语义也不声称任何运行时行为。用 project-apple-application-graph 投影 bundle 结构图谱文件树说清了位置说不清归属。哪些组件属于应用哪些只是安装器杂物投影命令一次给出rea project-apple-application-graph {inventory_evidence:[inventory_artifact Evidence]}应用根按输入形态识别输入形态识别出的应用根IPA每个Payload/Name.app各是一个根.app目录被库存的目录本身含应用的目录 / ZIP / DMG每个最外层Name.app后接Contents/DMG 的清单路径形如image.dmg/Volume/Name.appAPK、ASAR 等其他格式会被直接拒为输入错误。布局分三类macos-deep含Contents/可执行文件在Contents/MacOS/、versioned-framework含Versions/按每个真实版本目录分析、shallow两者皆无典型 iOS 形态凭根下Info.plist判定为ios平台。角色按路径约定归类全部自动*.appex→app-extension*.xpc→xpc-service*.framework→framework*.systemextension→system-extensionContents/Library/LoginItems/*.app→login-itemContents/Library/LaunchServices/下的文件计入特权助手。登录项和特权助手是启动项与提权入口的高频藏身处排查应用还悄悄装了什么直接看这份角色列表。实现见 src/application/apple/AppleApplicationService.ts工具契约见 src/contracts/applicationToolContracts.ts。用 trace-dylib-resolution 追踪 Mach-O 动态库加载知道包里有什么之后还要知道每条 dylib 加载最终命中哪个文件。这一步模拟 dyldmacOS 动态链接加载器的解析规则纯 TypeScript 解析 Mach-O / FAT 头不依赖 Apple 工具非 macOS 主机上也能跑rea trace-dylib-resolution MyApp.app --jsonbundle 内每个可执行文件主程序、XPC 服务、扩展、登录项、助手都是独立进程根各自持有executable_path。搜索按executable_path、loader_path、rpath链展开跟随符号链接架构分级兼容x86_64h进程可加载x86_64。每条依赖边列出所有尝试过的候选路径及其结果resolved、absent、architecture-missing、not-loadable、platform-mismatch、outside-target、escapes-target、undetermined。整条边的四级判定如下边状态含义resolved根内有一个镜像成功加载且更早的候选均可定论conditional根内可解析但更早的根外候选可能抢占unresolved根内候选确定缺失或不可用undetermined候选在根外或依赖运行环境无法定论这是静态模型不读取目标设备的 CPU也不证明设备会执行哪个 slicerequired-load-unresolved等 findings 是推导出的推断不是观察到的事实。想核对实际汇编、验证清单预测的加载顺序可配合 Hopper 等反汇编引擎流程见 docs/native-investigation.md。iOS 应用结构结论复核哪些不能直接下结构结论都建立在路径 哈希上。以下表述必须用专门工具复核后再使用CFBundleExecutable、URL Scheme、权限描述投影不读 plist 语义对 bundle 的info_plist_path用inspect_plistentitlement 等签名声明对可执行候选用inspect_signature核查earlier-rpath-candidate-absent只是路径级推断dyld 实际加载哪个镜像要凭签名元数据二次确认AppleDouble 侧车._*、__MACOSX/是清单事实但被排除在 bundle 角色与解剖之外别误计成应用组件。完整语义与状态表见 docs/apple-application-analysis.md。全链路速查表命令、输入与输出步骤命令输入输出库存认证rea inspect-artifact My.ipa --evidence_output evidence.json --jsonIPA / DMG / ZIP /.appinventory_artifact证据哈希、格式、limitations结构投影rea project-apple-application-graph {inventory_evidence:[inventory_artifact Evidence]}库存证据应用根、bundles布局、角色、桥接假设加载追踪rea trace-dylib-resolution MyApp.app --json.app或 Mach-O 可执行文件dyld 候选路径与四级判定、findings语义复核rea inspect-plist path/inspect_signatureinfo_plist_path/ 可执行候选plist 取值、签名声明【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考