原文地址：http://reverse.put.as/2012/02/02/anti-disassembly-obfuscation-1-apple-doesnt-follow-their-own-mach-o-specifications/

当想到这个特性时，我非常高兴！因为我喜欢突破束缚，并且写了一个CrackMe来展示这个有趣的特性。

产生问题的原因是：苹果没有遵循自己的文档与标准（Mach-O方面的），但是逆向工具却要遵循。

当逆向修改过Section信息的Mach-O文件时，IDA可能会崩溃、输出错误的反汇编结果、混乱的字符串，

LLDB输出错误的反汇编结果（不是GDB），class-dump 会失败，逆向工程师看到是无意义的Mach-O文件头。

最后，这是一个有趣的混淆手段。^_^

当你使用IDA加载CrackMe时，程序会报这样的错误：负的Section大小或偏移。

当Sections的信息（偏移或者大小）超过文件大小时，otool也会输出错误的结果。

造成这个问题的具体方法是：修改Mach-O的Section信息。在32位下，Section的结构如下：

struct section { /* for 32-bit architectures */
	char		sectname[16];	/* name of this section */
	char		segname[16];	/* segment this section goes in */
	uint32_t	addr;		/* memory address of this section */
	uint32_t	size;		/* size in bytes of this section */
	uint32_t	offset;		/* file offset of this section */
	uint32_t	align;		/* section alignment (power of 2) */
	uint32_t	reloff;		/* file offset of relocation entries */
	uint32_t	nreloc;		/* number of relocation entries */
	uint32_t	flags;		/* flags (section type and attributes)*/
	uint32_t	reserved1;	/* reserved (for offset or index) */
	uint32_t	reserved2;	/* reserved (for count or sizeof) */
};

让我们从最容易引起问题的offset字段说起。根据标准offset的定义如下：指示当前Section在文件中的偏移值。

我的理解是：这个字段用来指示代码或者数据在文件的位置。这么理解没错吧？

既然是一个偏移值，那么理论上Section是没有必要是按照顺序排列的或者按照指定的循序排列（主要是指：没有必要跟Section在Segment中顺序一致）。这就打开了错误之门。

如果我们将offset指向其他地址？比如：IDA需要根据offset指向的地址来读取相应的数据。

我们来做一个测试，修改cstring setion的偏移值，然后使用IDA加载修改后的文件。

喔，现在程序中的字符串被“混淆”了，因为IDA加载了错误的数据。

很有意思，是吗？如果你修改Section信息（将offset改成一个错误的值），然后运行对应的程序，程序的行为还完全正确！

同样，修改 text section的便宜后，程序的中指令应该都错了，但是程序还是可以正常运行。

为什么程序还可以正确运行？这是非常有趣的。我认为主要的原因是：内核只是将文件线性的加载到内存而忽略了offset。

《Mac OS X Internal》812页中对execve()系统调用的说明可以解释问题原因。

exec_mach_imgact()函数（bsd/kern/kern_exec.c）会调用load_machfile()函数，

后者主要用来加载可执行文件，处理具体的Mach-O加载命令等。代码片段如下：

@bsd/kern/kern_exec.c

/*
         * Actually load the image file we previously decided to load.
         */
        lret = load_machfile(imgp, mach_header, thread, map, &load_result);

在load_machfile()内部会调用parse_machfile()函数来解析文件，

@bsd/kern/mach_loader.c

lret = parse_machfile(vp, map, thread, header, file_offset, macho_size,
                              0, result);

在这里我们可以看到有趣的注释：

/*
 * The file size of a mach-o file is limited to 32 bits; this is because
 * this is the limit on the kalloc() of enough bytes for a mach_header and
 * the contents of its sizeofcmds, which is currently constrained to 32
 * bits in the file format itself.  We read into the kernel buffer the
 * commands section, and then parse it in order to parse the mach-o file
 * format load_command segment(s).  We are only interested in a subset of
 * the total set of possible commands.
 */

在实现的下部，我们可以看到处理所有command的循环，其中section command是在segment（LC_SEGMENT/LC_SEGMENT_64）command下处理的。

因为我们需要看下load_segment()的实现。

在load_segment()内，我们发现对于可执行文件合法性的验证只是做到了segment一层，并没有验证section。

这也造成我们没法混淆segment :-))。

当parse_machfile()函数返回时，所有的解析工作已经完成，链接的库被加载，程序的入口函数被调用。

程序的布局与其在文件系统中一致（这就是我前面所说的线性），并且section信息根本没有被使用。

这是一种隐性的约定：可执行文件的格式是正确的。

这种行为（指内核加载可执行文件）正确吗？我认为是错误的。因为内核并没有遵循Mach-O标准，或者是我对标准理解有错误？

这又是一个信任不可信数据的例子，我们应该显式的校验输入数据。

我们应该继续了解真个加载过程，在CrackMe中还有另一个有趣的特性;-)。

我们还可以改变这些section结构的这些字段：flags，size， section和segment的名字，section 的顺序。

这样可以迷惑工具和逆向工程师。这里需要注意的是跟内核遵循同样的隐式约定，忽略如上的字段。

看起来有点怪异，是吧？

我希望你享受如上的分析过程，并且为你带来阅读xnu与dyld源代码的动力。

Have fun,

fG!

更新 1：

如下是本文观点的PoC。代码是32位的、non-fat mach-o文件、控制台程序。如果在Objective-C目标上应用这个特性，

会引起加载错误，因为并不是所有的 section 都可以被混淆。

manglemacho.c.gz

SHA256(manglemacho.c.gz)= d79a612b72130732d7e47b2925fba7fc0b63824622d05f08e7f33641d522a8b5

更新 2：

实际的情况是上section 的所有字段都可以是0，并不会带来什么不利的影响（除了mod_init_func）。

我这样试过，但是没有做笔记。如果不做更深入的混淆，IDA有时还可以聪明得进行反汇编，

原因是入口地址是合法的。我们可以通过修改 size 和 offset 来对IDA进行更深入的迷惑。

通过设置如下工具的第二个参数可以将 section 的所有字段都设置成0.

manglemacho_v0.3.c.gz
SHA256(manglemacho_v0.3.c.gz)= 4b33dc5f43bbb9114e6a8c18dba8894ca44b991cd69a5e5e54bfdcd03607fc9c

-------------------------------------------------

译注：

文章介绍了如何通过修改Mach-O的Section信息来实现反-反汇编，

我们接下来应该思考下如何还原被修改后的Mach-O文件？！

如果修改后的Mach-O程序又包含：完整性校验，反调试，嵌入了断点异常检测等特性呢。