深入理解MachO数据解析规则
????????关注后回复 “进群” ，拉你进程序员交流群????????
作者丨zhangferry
来源丨iOS成长之路
我们知道Apple设备可执行文件的存储格式是MachO，一个二进制文件。通常在做逆向或者静态分析的时候都会用到这个文件，分析MachO的常用工具是MachOView[1]。今天借助于MachOView，主要分析Code Signature的存储规则。
本篇文章同时也是围绕这几个问题展开的：
1、MachOView是如何确认MachO内容的。
2、二进制数据是如何存储的，如何确认位置。
3、字节码含义如何解析。
前置准备
1、二进制文件其实简单理解就是通过二进制形式进行存储内容的文件，它可以原封不动的读到内存中用于完成各种处理。比如数值3.1415927，文本文件需要9个字节进行存储：3 . 1 4 1 5 9 2 7 这 9 个 ASCII 值，而如果是二进制的话4个字节就够了：DB 0F 49 40。
2、二进制文件读到内存中通常是连续存储的，它不需要额外的处理，原本怎样，在内存里就是怎样的。
3、每个进程都会被分配一个虚拟地址空间，进程寻址的范围就是在这个虚拟地址空间进行的，虚拟地址到物理地址之间有一个映射表进行管理。
4、可以简单理解：虚拟地址 = 随机基址（ASLR）+ 逻辑地址（段内偏移）。
后面的内容也会出现很多偏移量（offset）的概念，它的含义很简单就是相对某一位置偏移多少字节。关键是需要确认它是相对哪个位置进行的偏移，在不同的数据段，这个相对的锚点是不一样的。但通常来说偏移量都是相对于当前的数据段来说的。
5、FAT格式的MachO可以理解为多个架构的顺序组合，所以分析某个架构时，还需要加上对应架构的偏移量。
6、uint32_t占4个字节，uint8_t占1个字节，char占一个字节。
Mach-O格式
格式分析
可以简单看下Mach-O的数据结构：
Mach-O文件大致分为三部分：
Header
表示当前的Mach-O文件整体信息，包含CPU架构、子版本、文件类型、加载命令数等内容。数字内容好表示，那CPU架构这样的类别是如何表示的呢？二进制数据说到底也是数字，这些类别信息也只能通过数字表示，但需要一个具有特殊含义的数字，这个数字通常叫magic（魔数）。比如0xCAFEBABE表示FAT，0xFEEDFACF表示ARM64。
Header的定义地址：https://opensource.apple.com/source/xnu/xnu-792/EXTERNAL_HEADERS/mach-o/loader.h.auto.html
Load Commands
记录各个数据段的信息和位置，只是类别和标记的介绍，包含一些信息的偏移地址、文件大小等内容。
Data
记录具体的内容信息。不同类别的信息对应不同的数据含义。注意上图右侧由Load Commands到Data的箭头，Data的位置是由Load Commands指定的。
他们三者的关系如果用一本书表示的话就是：Header是封面，Load Commands是目录，Data是书的内容。
寻找Code Signature
本节的重点是找到Code Signature（代码签名）这部分内容，它没被MachOView解析，还是原始的数据形态，是一个比较好的分析案例。
分析文件是系统的ls，它的路径在/bin/ls，把它放到MachOView里。ls是一个FAT文件，它包含两个架构，Fat Header里记录了各个架构的类别、偏移量、大小等信息。
我们只关注X86_64架构下的内容，展开这个架构下的Load Commands，找到代表代码签名的LC_CODE_SIGNATURE信息：
右侧是真实的数据内容，MachOView已经帮我们对应好了字段描述：
Data Offset：代表数据偏移 53808，换成16进制就是0xD230
Data Size：代表文件大小 5728，换成16进制就是0x1660
这俩16进制值其实就是Data对应的内容，Value是MachOView帮我们做的处理。
这里的偏移跟上面Fat Header的偏移含义已经不一样了，Fat Header说的是总文件偏移，这里的偏移则是针对X86文件的偏移。所以实际的偏移应该是：0xD230 + 0x4000 = 0x11230。
找到Data部分的Code Signature内容：
这里pFile就是相对当前文件的偏移量（也可以理解为逻辑偏移量），它的起始位置正是上面计算得的：0x11230。由大小0x1660，我们还可以计算得出Code Signature最后一个字节所在位置是：0x11230 + 0x1660 - 0x1 = 0x1288F。
解析Code Signature
CS_SuperBlob
我们已经找到了代码签名位置，现在开始解析它吧。解析的第一步就是需要找到数据定义，有了定义才能分析出数据含义。Code Signature相关内容的定义在这里：https://opensource.apple.com/source/xnu/xnu-3789.51.2/bsd/sys/codesign.h.auto.html
整个签名的头部是一个CS_SuperBlob结构体，它的定义如下：
typedef struct __SC_SuperBlob {
uint32_t magic; /* magic number */
uint32_t length; /* total length of SuperBlob */
uint32_t count; /* number of index entries following */
CS_BlobIndex index[]; /* (count) entries */
/* followed by Blobs in no particular order as indicated by offsets in index */
} CS_SuperBlob;
这个结构体第一个参数是magic，它的定义如下：
/*
* Magic numbers used by Code Signing
*/
enum {
CSMAGIC_REQUIREMENT = 0xfade0c00, /* single Requirement blob */
CSMAGIC_REQUIREMENTS = 0xfade0c01, /* Requirements vector (internal requirements) */
CSMAGIC_CODEDIRECTORY = 0xfade0c02, /* CodeDirectory blob */
CSMAGIC_EMBEDDED_SIGNATURE = 0xfade0cc0, /* embedded form of signature data */
CSMAGIC_EMBEDDED_SIGNATURE_OLD = 0xfade0b02, /* XXX */
CSMAGIC_EMBEDDED_ENTITLEMENTS = 0xfade7171, /* embedded entitlements */
CSMAGIC_DETACHED_SIGNATURE = 0xfade0cc1, /* multi-arch collection of embedded signatures */
CSMAGIC_BLOBWRAPPER = 0xfade0b01, /* CMS Signature, among other things */
//...
}
第二个参数是length，表示整个SuperBlob的长度。
第三个参数是count，表示index实体条目的数量。
第四个参数是为CS_BlobIndex的一个结构体。
大端小端
1、这个是64位架构的二进制数据，其实有两种64位架构，他们分别表示为大端64位和小端64位，上面MachOView分析的X86 Header中的魔数是0xFEEDFACF，代表的就是当前二进制文件是小端64位格式。
2、比如0x1234这个数据，在小端情况下，12会存放在低字节处，34会放于高字节处，大端则相反。
数据解析
我们把Code Signature的第一个行数据拿出来分析：
这里注意Data部分，有两个标签：Data LO和Data HI，是用于表示当前的字节序列，前面是低字节，后面是高字节。这样按照小端的规则，我们就可以按自然顺序取数据了，所以可以得出以下内容：
magic
为0xFADE0CC0，对应CSMAGIC_EMBEDDED_SIGNATURE，代表嵌入的代码签名数据。
length
是0x1486，我们可以计算得出最后一个字节位置：0x11230 + 0x1486 - 0x1 = 0x126B5
红色标记的字节就是Code Signature结束的地方，在这之后的内容全部由0x00填充，就非实体内容了。
count
是3，表示接下来有3个实体内容，这个实体对应的是结构体：CS_BlobIndex。
CS_BlobIndex
我们来看下CS_BlobIndex这个结构体：
/*
* Structure of an embedded-signature SuperBlob
*/
typedef struct __BlobIndex {
uint32_t type; /* type of entry */
uint32_t offset; /* offset of entry */
} CS_BlobIndex;
它有两个成员变量，type表示实体类型，offset表示实体偏移量。
一般表示类型的肯定有特殊数字对应的含义，这里的type也是一样的，这个type在上面的magic在一个enum里定义。
CSSLOT_CODEDIRECTORY = 0, /* slot index for CodeDirectory */
CSSLOT_INFOSLOT = 1,
CSSLOT_REQUIREMENTS = 2,
CSSLOT_RESOURCEDIR = 3,
CSSLOT_APPLICATION = 4,
CSSLOT_ENTITLEMENTS = 5,
CSSLOT_ALTERNATE_CODEDIRECTORIES = 0x1000, /* first alternate CodeDirectory, if any */
CSSLOT_ALTERNATE_CODEDIRECTORY_MAX = 5, /* max number of alternate CD slots */
CSSLOT_ALTERNATE_CODEDIRECTORY_LIMIT = CSSLOT_ALTERNATE_CODEDIRECTORIES + CSSLOT_ALTERNATE_CODEDIRECTORY_MAX, /* one past the last */
CSSLOT_SIGNATURESLOT = 0x10000, /* CMS Signature */
数据解析
我们再回到数据部分，根据上面结构体进行分析：
能够解析出三条CS_BlobIndex数据：
| type | type含义 | offset |
|---|---|---|
| 0x00 | CSSLOT_CODEDIRECTORY | 0x24 |
| 0x02 | CSSLOT_REQUIREMENTS | 0x261 |
| 0x10000 | CSSLOT_SIGNATURESLOT | 0x29D |
这里又出现了一个offset，这个offset存在于Code Signature的最外部，所以它表示的就是相对Code Signature的偏移量。
这个表相当于又提供了一个目录，它告诉我们，之后的内容有三部分（三个结构体）组成，各个部分的页码是什么。
CS_CodeDirectory
我们先分析CSSLOT_CODEDIRECTORY，它对应的是CS_CodeDirectory结构体：
/*
* C form of a CodeDirectory.
*/
typedef struct __CodeDirectory {
uint32_t magic; /* magic number (CSMAGIC_CODEDIRECTORY) */
uint32_t length; /* total length of CodeDirectory blob */
uint32_t version; /* compatibility version */
uint32_t flags; /* setup and mode flags */
uint32_t hashOffset; /* offset of hash slot element at index zero */
uint32_t identOffset; /* offset of identifier string */
uint32_t nSpecialSlots; /* number of special hash slots */
uint32_t nCodeSlots; /* number of ordinary (code) hash slots */
uint32_t codeLimit; /* limit to main image signature range */
uint8_t hashSize; /* size of each hash in bytes */
uint8_t hashType; /* type of hash (cdHashType* constants) */
uint8_t platform; /* platform identifier; zero if not platform binary */
uint8_t pageSize; /* log2(page size in bytes); 0 => infinite */
uint32_t spare2; /* unused (must be zero) */
/* Version 0x20100 */
uint32_t scatterOffset; /* offset of optional scatter vector */
/* Version 0x20200 */
uint32_t teamOffset; /* offset of optional team identifier */
/* followed by dynamic content as located by offset fields above */
} CS_CodeDirectory;
数据解析
我们先把这段数据拿出来，然后根据结构体进行分析：
这里仅挑一些重要的内容进行分析。
magic是0xFADE0C02，作为标记存在，代表CodeDirectory
length是0x23D，表示数据段长度
identoffset是0x30，表示identifier字符串的偏移量，这里的identifier对应的就是我们的bundleId
需要提醒的是当前的CodeDirectory是数据SuperBlob的内部结构体，所以这里的offset就变成了结构体内部偏移了，这里的起始位置也即是0xFADE0C02所在的位置是0x11254，所以可以算出indentoffset的文件偏移量是：
identoffset地址为：0x11254 + 0x30 = 0x11284
这里你可能会疑惑，只有偏移量怎么确认从哪结束呢，这里并没有提供数据大小。其实字符串是不需要知道大小也可以确认它到哪结束的，字符里面有结束位\0啊，在ASCII码里结束位就是0x00。
可以解析得出ls的bundleId是com.apple.ls。
这里再补充一点：MachO里字符串的编码不是通过ASCII，而是使用UTF-8进行编码的，只不过UTF-8兼容了ASCII，所以我们当做ASCII也能解析出正确的内容。
CS_GenericBlob
我们现在来看下证书的解析，查上面记录的偏移表，CSSLOT_SIGNATURESLOT对应的结构体是CS_Generic_Blob：
typedef struct __SC_GenericBlob {
uint32_t magic; /* magic number */
uint32_t length; /* total length of blob */
char data[];
} CS_GenericBlob;
上个表格我们记录了它的offset是0x29D位置，所以它的起始位置就是：0x11230 + 0x29D = 0x114CD，找到这个位置，带入结构体进行解析：
magic是0xFADE0B01，对应了CSSLOT_SIGNATURESLOT值。
数据长度是0x11E9（4585字节），这表示的CS_GenericBlob的大小，而在这之后的内容都是data，表示的就是证书部分。
我们可以计算出证书data结束的最后一个字节位置：0x114CD + 0x11E9 - 0x8 - 0x1 = 0x126AD。
说明：根据《iOS应用逆向与安全》一书说明，借助于010 Editor等二进制工具，我们把data部分的数据复制出来（需要借助于Hooper这类工具），保存为cer格式，就能获取到一个证书文件。但对ls的测试并不能成功，推测这里的data可能还有其余内容，需要拆分。
Jtool
只要有了对应数据结构，签名部分的所有信息我们都是可以解析出来的。但每次都逐字节分析，显然很费事，能不能写个程序，用于上述内容解析呢？当然是可以的，已经有这样的工具了，就是Jtool[2]。jtool比otool功能更强大，解析的数据也更详细。可以通过homebrew进行安装：
$ brew install jtool
如果通过jtool查看上面x86_64架构的签名信息，可以这样：
$ jtool -arch x86_64 --sig /bin/ls
输出结果为：
Blob at offset: 53808 (5728 bytes) is an embedded signature
Code Directory (573 bytes)
Version: 20100
Flags: none
Platform Binary
CodeLimit: 0xd230
Identifier: com.apple.ls (0x30)
CDHash: 46cc1da7c874a5853984a286ffecb48daf2f65f023d10258a31118acfc8a3697 (computed)
# of Hashes: 14 code + 2 special
Hashes @125 size: 32 Type: SHA-256
Requirement Set (60 bytes) with 1 requirement:
0: Designated Requirement (@20, 28 bytes): SIZE: 28
Ident: (com.apple.ls) AND Apple Anchor
Blob Wrapper (4585 bytes) (0x10000 is CMS (RFC3852) signature)
CA: Apple Certification Authority CN: Apple Root CA
CA: Apple Certification Authority CN: Apple Code Signing Certification Authority
CA: Apple Certification Authority CN: Apple Root CA
CA: Apple Certification Authority CN: Apple Root CA
CA: Apple Certification Authority CN: Apple Code Signing Certification Authority
CA: Apple Software CN: Software Signing
Time: 201222002625Zi
第一行里的offset 53808 对应16进制是0xD230，就是LC_CODE_SIGNATURE里记录的偏移量。
根据输出信息也能得出code signature由三部分内容组成：Code Diretory、Requeirement Set、Blob Wrapper。证书部分解析出了6个证书，说明这里应该还有别的结构体可以拆分。
回顾
如果你看到这里，可以回顾下开始讲到的三个问题，用于检验你的理解程度。
1、MachOView是如何确认MachO内容的。
2、二进制数据是如何存储的，如何确认位置。
3、字节码含义如何解析。
参考资料
[1]
MachOView: https://github.com/fangshufeng/MachOView
[2]jtool: http://newosxbook.com/tools/jtool.html
-End-
最近有一些小伙伴，让我帮忙找一些 面试题 资料，于是我翻遍了收藏的 5T 资料后，汇总整理出来，可以说是程序员面试必备！所有资料都整理到网盘了，欢迎下载！
点击????卡片，关注后回复【面试题】即可获取
在看点这里
好文分享给更多人↓↓