iOS 应用包里到底藏了什么不越狱、不运行给 IPA 做三道静态体检【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea拿到一份来路不明的 IPA装不上机也越不了狱。用 REA面向 AI Agent 的逆向工程工具做 iOS 逆向工程的静态部分只读包、不执行任何代码把 IPA 解析、应用结构分析、Mach-OApple 平台的原生二进制格式动态库加载链一次看全。 拿到一份装不了的 IPA先问什么渠道存疑、没开发签名跑起来又怕带毒——先问三个问题包有没有被人改过启动时到底会拉起哪些组件每个动态库最终落到哪个文件 越狱和动态调试都用不上时答案只能从完全不动它的静态检查里找。 把整份 IPA 当成一次体检先出整包底账再核启动阵容最后追每条动态库的去向。 三道检查全程只读做完你手里有一份可回溯的书面结论。 它可信吗给 IPA 做一份完整性认证清单结论先行第一道体检是整包认证——对 IPA、DMG、ZIP 或 macOS.app目录执行库存操作产出一条inventory_artifact带哈希指纹的整包库存证据记录后面每句结论都能回到这张底账上核对。字段记录什么体检意义nodes每个文件的格式、架构、可执行位、内容状态分出谁是真二进制、谁只是资源occurrences每个逻辑路径的声明大小与哈希校验状态verified等同一份内容出现在几个位置逐个有数root_sha256/root_format根文件的哈希指纹与格式ipa、dmg等拿它和官方渠道的包对指纹先确认是不是同一个包limitations无法核实的项目如实列出查不到的地方不装懂静默忽略等于造假清单只记观察事实不解析 plist不判签名语义。 这是刻意划出的边界——底账管包里有什么语义问题留给下一节和专门的工具。 它启动时会带谁上场一条命令画出 bundle 结构图谱结论把上一节的 inventory_artifact 交给一条命令整包里每个应用根和它名下的嵌套bundleApple 平台上独立成组的容器目录全部摆出来还按路径习惯自动分好了角色。rea project-apple-application-graph {inventory_evidence:[inventory_artifact Evidence]}应用根不是猜的按库存根的类型定库存根长什么样应用根落在哪备注IPA每个Payload/Name.app标准 iOS 安装包布局.app目录目录本身目录型库存一律当独立根哪怕缺Contents/含应用的目录 / ZIP / DMG每个最外层Name.app带Contents/DMG 形如image.dmg/Volume/Name.app只有 DMG 根身份、缺子清单时覆盖度如实标记为partial缺失即未知而不是没有APK、ASAR 这类库存直接按输入错误拒绝避免张冠李戴。三种 bundle 布局对应三种读法bundles 列表给出每个应用根及其全部嵌套 bundleinfo_plist_path、executable_candidates可执行候选、signing_paths签名路径。布局分三类macos-deep含Contents/可执行文件位于Contents/MacOS/versioned-framework含Versions/逐个真实版本目录分析shallow两者皆无带Info.plist就判为ios平台典型 iOS 应用形态角色按路径惯例自动归类先看高危位置Contents/Library/LoginItems/下的登录项、Contents/Library/LaunchServices/下的特权助手单列再按惯例归类*.appex应用扩展、*.xpc、*.framework、*.systemextension各归其位。 这批角色正是隐藏启动项和提权点的高发位置审查时优先过一遍。 AppleDouble 侧车文件._*、__MACOSX/算进清单事实但排除在 bundle 角色与解剖组件之外。 实现见 AppleApplicationService.ts工具契约定义在同目录的 applicationToolContracts.ts 中。 它的动态库到底加载到哪Mach-O 加载链静态解析结论前两道回答包里有什么、谁会上场这一道回答每条 dylib 声明最终命中哪个文件——纯头文件级解析一个字节都不执行。rea trace-dylib-resolution MyApp.app --json解析用纯 TypeScript 完成 Mach-O / FAT 头与加载命令不依赖 Apple 工具非 macOS 机器上也能跑。 它按 dyld 的规则展开搜索链executable_path指向进程根可执行文件所在目录loader_path指向持有该加载命令的镜像目录rpath先试加载方自己的LC_RPATH再沿加载链逐级上溯到进程根符号链接在根内跟随x86_64h进程还能兼容加载x86_64切片。每条依赖边都列出试过的候选及结果resolved、absent、architecture-missing、escapes-target等整条边再汇总成四级判定判定什么情况出现审查时怎么读resolved根内的镜像能加载且没有更靠前的候选悬而未决加载去向确定conditional根内能解析但根外的更早候选如/usr/lib/swift在真实系统上存在时会抢先按可能换镜像复核unresolved所有候选在根内明确缺失或不可用该依赖加载会失败undetermined无根内命中且存在根外或依赖环境的候选取决于运行环境如实标注想核对实际汇编可以把清单预测的加载顺序交给 Hopper 等反汇编引擎做交叉验证它在原生调查流程中的位置见 native-investigation.md。 边界与换工具时机体检单故意不写的两件事结论这套体检刻意停在包内事实语义和声明类问题要换工具补位别在底账上找不存在的答案。不解析 plist 语义要看CFBundleExecutable、URL Scheme、权限描述对 bundle 的info_plist_path用inspect_plist不核查签名对可执行候选用inspect_signature查签名声明桥接假设JavaScript ↔ 原生配对最多序列化 2 MiB超出时结果携带bridge_candidate_coverage报告省略数量整体覆盖度降为partial目录型.app一律视为独立根DMG 子卷清单依赖原生 macOS 挂载适配器缺适配器时只能拿到根身份换工具的时机只有一个标准你问的问题当前工具明说不归我管。静态体检的分工是照实记录不是全知全能。字段语义与状态表的完整版见 apple-application-analysis.md第一次用 REA 先按 installation.md 完成安装与 Provider 配置。三道检查做完一份 IPA 的完整性、启动阵容、动态库去向全部有据可查——这就是不越狱、不运行也能看清 iOS 应用包的全部底牌。【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考