为什么0x1F段在OSX中是特殊的?

时间:2010-10-01 09:49:42

标签: macos

某些Mach-O可执行文件具有带有以下初始寄存器值的LC_UNIXTHREAD命令:

cmd LC_UNIXTHREAD
    cmdsize 80
     flavor i386_THREAD_STATE
      count i386_THREAD_STATE_COUNT
        eax 0x00000000 ebx    0x00000000 ecx 0x00000000 edx 0x00000000
        edi 0x00000000 esi    0x00000000 ebp 0x00000000 esp 0x00000000
        ss  0x0000001f eflags 0x00000000 eip 0x00002788 cs  0x00000017
        ds  0x0000001f es     0x0000001f fs  0x00000000 gs  0x00000000

eip 设置为应用的入口点,但由于某种原因,其余部分也有一个特殊的初始值。 (如果它们都是零,则应用程序会随机崩溃,因为某些malloc()不会返回干净的内存区域。) 关于神秘的0x1F段的任何想法?

3 个答案:

答案 0 :(得分:1)

它有什么神秘之处?你需要CS,DS,SS的有效选择器:)

selector 0x17: RPL3, LDT, descriptor index 0x10
selector 0x1F: RPL3, LDT, descriptor index 0x18

Windows(至少win7-32​​bit)使用以下两个:

CODE: 0x1B - RPL3, GDT, descriptor index 0x10
DATA: 0x23 - RPL3, GDT, descriptor index 0x20

答案 1 :(得分:0)

经过深入研究后,我终于找到了原因: 根据所选的基本SDK和部署目标,GCC使用不同的系统库和公共运行时库对象(crt1.o)

SDK10.4, Target10.4: /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/crt1.o
SDK10.5, Target10.4: /Developer/SDKs/MacOSX10.5.sdk/usr/lib/crt1.o
SDK10.5, Target10.5: /Developer/SDKs/MacOSX10.5.sdk/usr/lib/crt1.10.5.o
SDK10.6, Target10.4: /Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.o
SDK10.6, Target10.5: /Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.10.5.o
SDK10.6, Target10.6: /Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.10.6.o

这些目标文件包含具有上述寄存器状态的初始UNIX线程加载命令。如果选定的SDK和部署目标都是10.4(第一行),则CS,DS,ES,SS将与0不同。

答案 2 :(得分:0)

需要将CS设置为打开X标志的选择器。 DS,ES是数据段,因此指向不同的选择器。 FS,GS也不同。我不确定Mac OS,但在Windows上,这两个用于非常具体的事情:

Win32:FS用于存储有关进程的信息(FS:[30] = PEB,FS:[0] = SEH Info) Win64:使用GS代替FS,休息或多或少相同。

在Mac OS X中的某些应用程序中,您将看到GS的值为0x0F且FS设置为零,可能是GS:[XXX]包含有关该过程的信息。