Lan*_*ard 13 c macos executable
过去几天我一直在试验装配,现在了解装配和机器代码之间的关系(在OSX上通过NASM使用x86,阅读英特尔文档).
现在我试图了解链接器如何工作的细节,特别是想要了解Mach-O目标文件的结构,从Mach-O头开始.
我的问题是,你能否将下面的Mach-O标头映射到otool命令输出(显示标题,但它们的格式不同)?
这个问题的一些原因包括:
下面我展示了我尝试从真实对象文件解码Mach-O头的示例和过程.在下面的描述中,我试图显示出现的所有小/微妙问题的提示.希望这将提供一种对新手如此混淆的感觉.
从一个名为的基本C文件开始example.c:
#include <stdio.h>
int
main() {
printf("hello world");
return 0;
}
Run Code Online (Sandbox Code Playgroud)
用gcc example.c -o example.out它编译,它给出:
cffa edfe 0700 0001 0300 0080 0200 0000
1000 0000 1005 0000 8500 2000 0000 0000
1900 0000 4800 0000 5f5f 5041 4745 5a45
524f 0000 0000 0000 0000 0000 0000 0000
0000 0000 0100 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 1900 0000 2802 0000
5f5f 5445 5854 0000 0000 0000 0000 0000
0000 0000 0100 0000 0010 0000 0000 0000
0000 0000 0000 0000 0010 0000 0000 0000
0700 0000 0500 0000 0600 0000 0000 0000
5f5f 7465 7874 0000 0000 0000 0000 0000
5f5f 5445 5854 0000 0000 0000 0000 0000
400f 0000 0100 0000 2d00 0000 0000 0000
400f 0000 0400 0000 0000 0000 0000 0000
0004 0080 0000 0000 0000 0000 0000 0000
5f5f 7374 7562 7300 0000 0000 0000 0000
5f5f 5445 5854 0000 0000 0000 0000 0000
6e0f 0000 0100 0000 0600 0000 0000 0000
6e0f 0000 0100 0000 0000 0000 0000 0000
0804 0080 0000 0000 0600 0000 0000 0000
5f5f 7374 7562 5f68 656c 7065 7200 0000
... 531 total lines of this
Run Code Online (Sandbox Code Playgroud)
运行otool -h example.out,打印:
example.out:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
0xfeedfacf 16777223 3 0x80 2 16 1296 0x00200085
Run Code Online (Sandbox Code Playgroud)
为了理解Mach-O文件格式,我发现这些资源很有帮助:
来自opensource.apple.com的最后3个包含所有常量,例如:
#define MH_MAGIC_64 0xfeedfacf /* the 64-bit mach magic number */
#define MH_CIGAM_64 0xcffaedfe /* NXSwapInt(MH_MAGIC_64) */
...
#define CPU_TYPE_MC680x0 ((cpu_type_t) 6)
#define CPU_TYPE_X86 ((cpu_type_t) 7)
#define CPU_TYPE_I386 CPU_TYPE_X86 /* compatibility */
#define CPU_TYPE_X86_64 (CPU_TYPE_X86 | CPU_ARCH_ABI64)
Run Code Online (Sandbox Code Playgroud)
Mach-O头的结构如下所示:
struct mach_header_64 {
uint32_t magic; /* mach magic number identifier */
cpu_type_t cputype; /* cpu specifier */
cpu_subtype_t cpusubtype; /* machine specifier */
uint32_t filetype; /* type of file */
uint32_t ncmds; /* number of load commands */
uint32_t sizeofcmds; /* the size of all the load commands */
uint32_t flags; /* flags */
uint32_t reserved; /* reserved */
};
Run Code Online (Sandbox Code Playgroud)
鉴于此信息,目标是在目标文件中找到Mach-O标头的每个部分example.out.
鉴于这个例子和研究,我能够识别出Mach-O标题的第一部分,即"神奇数字".那很酷.
但这不是一个简单的过程.以下是为了弄清楚这一点而必须收集的信息.
otool输出的第一列显示"魔术" 0xfeedfacf.MH_MAGIC或MH_CIGAM(反向"神奇").所以通过google在mach-o/loader.h中找到了那些.由于我使用的是64位架构而不是32位,因此使用了MH_MAGIC_64(0xfeedfacf)和MH_CIGAM_64(0xcffaedfe).example.out文件,前8个十六进制代码cffa edfe匹配MH_CIGAM_64!它有一种不同的格式会让你失望,但是它们是两种不同的十六进制格式,足以看到连接.它们也是相反的.这里有3个数字,足以弄清楚幻数是多少:
0xcffaedfe // value from MH_CIGAM_64
0xfeedfacf // value from otool
cffa edfe // value in example.out
Run Code Online (Sandbox Code Playgroud)
所以这很令人兴奋!仍然不能完全确定我是否能就这些数字得出正确的结论,但希望如此.
现在它开始变得混乱.以下是需要将它们组合在一起以便几乎理解它的部分,但这是我到目前为止所处的位置:
otool节目16777223.这个苹果堆栈交换问题提供了一些如何理解这一点的提示.CPU_TYPE_X86_64在mach/machine.h中找到,并且必须进行多次计算才能找出它的价值.以下是要计算以下值的相关常量CPU_TYPE_X86_64:
#define CPU_ARCH_ABI64 0x01000000 /* 64 bit ABI */
#define CPU_TYPE_X86 ((cpu_type_t) 7)
#define CPU_TYPE_I386 CPU_TYPE_X86 /* compatibility */
#define CPU_TYPE_X86_64 (CPU_TYPE_X86 | CPU_ARCH_ABI64)
Run Code Online (Sandbox Code Playgroud)
所以基本上:
CPU_TYPE_X86_64 = 7 BITWISEOR 0x01000000 // 16777223
Run Code Online (Sandbox Code Playgroud)
这个数字16777223与所显示的相匹配otool,很好!
接下来,试图找到该号码example.out,但它不存在,因为这是一个十进制数字.我刚刚在JavaScript中将其转换为十六进制,其中
> (16777223).toString(16)
'1000007'
Run Code Online (Sandbox Code Playgroud)
因此,不确定这是否是生成十六进制数的正确方法,尤其是与Mach-O对象文件中的十六进制数匹配的十六进制数.1000007也只有7个数字,所以不知道你是否应该"填充"它或什么的.
无论如何,你看到这个数字example.out,就在幻数之后:
0700 0001
Run Code Online (Sandbox Code Playgroud)
嗯,他们似乎有点相关:
0700 0001
1000007
Run Code Online (Sandbox Code Playgroud)
看起来有一个0添加到最后1000007,并且它被颠倒了.
此时我想问这个问题,已经花了几个小时来达到这一点.Mach-O头的结构如何映射到实际的Mach-O目标文件?您能否在example.out上面的文件中显示标题的每个部分,并简要说明原因?
令你困惑的部分原因是字节序.在这种情况下,标头以平台的本机格式存储.与Intel兼容的平台是little-endian系统,这意味着多字节值的最低有效字节首先在字节序列中.
因此,字节序列07 00 00 01在被解释为小端32位值时对应于0x01000007.
解释结构需要知道的另一件事是每个字段的大小.所有uint32_t领域都非常简单.它们是32位无符号整数.
在cpu_type_t和cpu_subtype_t你链接的machine.h中定义的两者都是等价的integer_t.integer_t被定义为等同int于/usr/include/mach/i386/vm_types.h.OS X是一个LP64平台,这意味着longs和指针对架构敏感(32-与64位),但int不是.它总是32位.
因此,所有字段的大小都是32位或4字节.由于有8个字段,因此总共32个字节.
从原始的hexdump,这里是与标题对应的部分:
cffa edfe 0700 0001 0300 0080 0200 0000
1000 0000 1005 0000 8500 2000 0000 0000
Run Code Online (Sandbox Code Playgroud)
按字段划分:
struct mach_header_64 {
uint32_t magic; cf fa ed fe -> 0xfeedfacf
cpu_type_t cputype; 07 00 00 01 -> 0x01000007
cpu_subtype_t cpusubtype; 03 00 00 80 -> 0x80000003
uint32_t filetype; 02 00 00 00 -> 0x00000002
uint32_t ncmds; 10 00 00 00 -> 0x00000010
uint32_t sizeofcmds; 10 05 00 00 -> 0x00000510
uint32_t flags; 85 00 20 00 -> 0x00200085
uint32_t reserved; 00 00 00 00 -> 0x00000000
};
Run Code Online (Sandbox Code Playgroud)