Mach-O 二进制检查器

使用方法

1. 把二进制拖进方框：没有扩展名的命令行工具、.dylib、.bundle、.o、dSYM 里的 DWARF 文件，或 .app 内部的可执行文件都可以。
2. 如果是通用文件，先看架构表——这就是“有没有 arm64”的答案——然后点击某个架构，查看它的头部、段和依赖库。
3. 查看加固标记：现代二进制的 PIE 应为“是”，而栈可执行在分发前值得给出解释。
4. 在“链接的库”里看运行时需要什么，在“运行时搜索路径”里看 @rpath 会展开到哪些目录，在“安装名称”里看库为自己声明的路径。
5. 追查体积时展开节列表：__TEXT 是代码，__DATA 是可写数据，__LINKEDIT 存放符号表与签名，而 dSYM 的 __DWARF 节通常是磁盘上最大的部分。

常见问题

怎么确认某个 App 是否包含 arm64（Apple 芯片）切片？

打开 .app 内的 Contents/MacOS/<名称>，查看架构表。通用文件以大端 fat 头开始，列出每个架构、它在文件中的偏移，以及该切片所对齐的边界；没有列出的架构就不在文件里，所以只有 x86_64 的应用会通过 Rosetta 运行而非原生运行。每个切片都是拥有自己头部和加载命令的完整 Mach-O 映像，因此通用二进制的体积大致等于各部分之和，而 lipo 可以只取出一个切片来瘦身。

有代码签名就说明这个二进制可信吗？

不是，这个工具刻意区分这一点。LC_CODE_SIGNATURE 只说明 __LINKEDIT 里的某个偏移处存在签名数据；它不说明哈希是否仍与所覆盖的页面吻合、证书是否能链到 Apple、证书是否被吊销，也不说明是否已公证。要验证这些需要完整的证书链，公证还需要 Apple 的服务器，也就是要在 Mac 上运行 codesign --verify --deep --strict 和 spctl --assess。强化运行时（hardened runtime）也不在头部，而在签名的授权与标志里，所以仅凭头部无法判断它是否开启。

为什么二进制比里面的代码大得多？

把段表的两列大小放在一起看。__TEXT 是代码和只读数据，通常按读取加执行映射；__DATA 与 __DATA_CONST 是可写数据；__LINKEDIT 存放符号表、function starts、dyld 修正信息和代码签名，在发布版二进制里常常是最大的一块。内存大小与文件大小不同是有意为之：__bss 这类零填充节只占地址空间，不占磁盘字节；__PAGEZERO 保留的 4 GB 永远不会从文件映射。如果是通用文件，还要记得你同时携带了所有架构。

什么是安装名称，为什么到处都是 @rpath？

动态库在 LC_ID_DYLIB 里记录自己期望被找到的路径，链接它的程序会把这串字符原样复制到自己的 LC_LOAD_DYLIB。如果是绝对路径，那么每台机器上都必须恰好存在那个位置。现代框架改用 @rpath/Something.framework/Something，把解析交给程序：这里列出的 LC_RPATH 就是 dyld 依次用来替换 @rpath 的目录，通常用 @executable_path 或 @loader_path 写成相对于二进制的形式，这样应用包可以随意移动。启动时报“image not found”，最常见的原因就是缺少 rpath。

iOS 二进制上的“已加密”标记是什么意思？

App Store 分发的 iOS 二进制带有 cryptid 为 1 的 LC_ENCRYPTION_INFO（或其 64 位形式），标记一段字节范围——通常是 __TEXT 的大部分——已用商店施加的密钥加密。内核在加载时解密该范围，因此磁盘上的这段区域不可读：strings 找不到有用内容，反汇编器只能看到噪声。自己编译的二进制，或在商店重新签名前从 IPA 取出的二进制，cryptid 为 0，是明文。很多文件里这条命令存在但取值为零，所以这里报告的是 cryptid 而不仅仅是命令是否存在。

二进制会被上传到什么地方吗？

不会。文件通过浏览器的 File API 读取，由页面内的 JavaScript 解析。没有任何内容被发送到服务器，也不存在可发送的服务器端组件。这一点在这里比在多数工具中更重要：尚未发布的构建或客户的应用，你不会想交给一个网站。页面加载完成后断网，所有功能依然可用。

相关工具