久久996热精品xxxx,久久久WWW成人免费精品,人妻无码αv中文字幕久久琪琪布

a.out,coff and elf analysis

chatler — Sat, 05 Dec 2009 15:44:00 GMT

a.out: http://en.wikipedia.org/wiki/A.out
elf:     http://en.wikipedia.org/wiki/Executable_and_Linkable_Format
         http://uw714doc.sco.com/en/man/html.3elf/elf_getarsym.3elf.html
xcoff: http://publib16.boulder.ibm.com/pseries/en_US/files/aixfiles/XCOFF.htm#yaa3i18fjbau
windows:
         http://www.microsoft.com/whdc/winlogo/drvsign/Authenticode_PE.mspx
apple:
http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/
MachORuntime/Reference/reference.html#//apple_ref/doc/uid/20001298-BAJIHABI
for different file formats, you can see in:
http://en.wikipedia.org/wiki/Comparison_of_executable_file_formats

chatler 2009-12-05 23:44 发表评论

a.out文�g格式分析

chatler — Sat, 05 Dec 2009 15:34:00 GMT

a.out 格式在不同的机器�q�_��和不同的 UNIX 操作�pȝ��上有��d��的不同，例如�?MC680x0 �q�_��上有 6 �?section。下面我们讨论的是最"标准"的格式�?/p>

a.out 文�g包含 7 �?section�Q�格式如下：exec header�Q�执行头部，也可理解为文件头部）
text segment�Q�文本段�Q?br>data segment(数据�D?
text relocations(文本重定位段)
data relocations�Q�数据重定位�D�）
symbol table�Q�符可��Q?br>string table�Q�字�W�串表）

执行头部的数据结构：struct exec {
                      unsigned long     a_midmag;      /* ��数和其它信�?*/
                      unsigned long     a_text;        /* 文本�D늚�长度 */
                      unsigned long     a_data;        /* 数据�D늚�长度 */
                      unsigned long     a_bss;         /* BSS�D늚�长度 */
                      unsigned long     a_syms;        /* �W�号表的长度 */
                      unsigned long     a_entry;       /* �E�序�q�入�?*/
                      unsigned long     a_trsize;      /* 文本重定位表的长�?*/
                      unsigned long     a_drsize;      /* 数据重定位表的长�?*/
            };

文�g头部主要描述了各�?section 的长度，比较重要的字�D�|�� a_entry�Q�程序进入点�Q�，代表了系�l�在加蝲�E�序�q�初试化各种环境后开始执行程序代码的入口。这个字�D�在后面讨论�?ELF 文�g头部中也有出现。由 a.out 格式和头部数据结构我们可以看出，a.out 的格式非常紧凑，只包含了�E�序�q�行所必须的信息（文本、数据、BSS�Q�，而且每个 section 的顺序是固定的。这�U�结构缺乏扩展性，如不能包�?��C��"可执行文件中常见的调试信息，最初的 UNIX 黑客�?a.out 文�g调试使用的工��h�� adb�Q��?adb 是一�U�机器语�a�调试器！

a.out 文�g中包含符可��和两个重定位表，�q�三个表的内容在�q�接目标文�g以生成可执行文�g时�v作用。在最�l�可执行�?a.out 文�g中，�q�三个表的长度都�?0。a.out 文�g在连接时��把所有外部定义包含在可执行程序中�Q�如果从�E�序设计的角度来看，�q�是一�U�硬�~�码方式�Q�或者可�U�Cؓ模块之间是强藕和的。在后面的讨��Z��Q�我们将会具体看到ELF格式和动态连接机制是如何�Ҏ��q�行改进的�?/p>

a.out 是早期UNIX�pȝ��使用的可执行文�g格式�Q�由 AT&T 设计�Q�现在基本上已被 ELF 文�g格式代替。a.out 的设计比较简单，但其设计思想明显的被后箋的可执行文�g格式所�l�承和发扬。可以参�?参考资�?16 和阅�?参考资�?15 源代码加深对 a.out 格式的理解�?参考资�?12 讨论了如何在"��C��"的红帽LINUX�q�行 a.out 格式文�g�?/p>

COFF 文�g格式分析

COFF 格式�?a.out 格式要复杂一些，最重要的是包含一个节�D�表(section table)�Q�因此除�?.text�Q?data�Q�和 .bss 区段以外�Q�还可以包含其它的区�D�c��另外也多了一个可选的头部�Q�不同的操作�pȝ��可一�Ҏ��头部做特定的定义�?/p>

COFF 文�g格式如下�Q�File Header(文�g头部)
Optional Header(可选文件头�?
Section 1 Header(节头�?
………
Section n Header(节头�?
Raw Data for Section 1(节数�?
Raw Data for Section n(节数�?
Relocation Info for Sect. 1(节重定位数据)
Relocation Info for Sect. n(节重定位数据)
Line Numbers for Sect. 1(节行��h��?
Line Numbers for Sect. n(节行��h��?
Symbol table(�W�号�?
String table(字符串表)

文�g头部的数据结构：struct filehdr
                 {
                   unsigned short    f_magic;      /* ��数 */
                     unsigned short    f_nscns;      /* 节个�?*/
                     long              f_timdat;     /* 文�g建立旉�� */
                     long              f_symptr;     /* �W�号表相�Ҏ��件的偏移�?*/
                     long              f_nsyms;      /* �W�号表条目个�?*/
                     unsigned short    f_opthdr;     /* 可选头部长�?*/
                     unsigned short    f_flags;      /* 标志 */
                 };

COFF 文�g头部中魔��C��其它两种格式的意义不太一��P��它是表示针对的机器类型，例如 0x014c 相对�?I386 �q�_��Q��?0x268 相对�?Motorola 68000�p�d��{�。当 COFF 文�g为可执行文�g�Ӟ��字段 f_flags 的��gؓ F_EXEC�Q?X00002�Q�，同时也表�C�此文�g没有未解析的�W�号�Q�换句话��_��也就是重定位在连接时��已�l�完成。由此也可以看出�Q�原始的 COFF 格式不支持动态连接。�ؓ了解册��个问题以及增加一些新的特性，一些操作系�l�对 COFF 格式�q�行了扩展。Microsoft 设计了名�?PE�Q�Portable Executable�Q�的文�g格式�Q�主要扩展是�?COFF 文�g头部之上增加了一些专用头部，具体�l�节请参�?参考资�?18�Q�某�?UNIX �pȝ��也对 COFF 格式�q�行了扩展，�?XCOFF�Q�extended common object file format�Q�格式，支持动态连接，请参�?参考资�?5�?/p>

紧接文�g头部的是可选头部，COFF 文�g格式规范中规定可选头部的长度可以�?0�Q�但�?LINUX �pȝ��下可选头部是必须存在的。下面是 LINUX 下可选头部的数据�l�构�Q�typedef struct
            {
                  char     magic[2];    /* ��数 */
                  char     vstamp[2];    /* 版本�?*/
                  char     tsize[4];    /* 文本�D�长�?*/
                  char     dsize[4];    /* 已初始化数据�D�长�?*/
                  char     bsize[4];    /* 未初始化数据�D�长�?*/
                  char     entry[4];    /* �E�序�q�入�?*/
                  char     text_start[4];         /* 文本�D�基地址 */
                  char     data_start[4];         /* 数据�D�基地址 */
            }
            COFF_AOUTHDR;

字段 magic �?0413 时表�C?COFF 文�g是可执行的，注意到可选头部中昑ּ�定义了程序进入点�Q�标准的 COFF 文�g没有明确的定义程序进入点的��|��通常是从 .text 节开始执行，但这�U�设计�ƈ不好�?/p>

前面我们提到�Q�COFF 格式�?a.out 格式多了一个节�D�表�Q�一个节头条目描�q�C��个节数据的细节，因此 COFF 格式能包含更多的节，或者说可以�Ҏ��实际需要，增加特定的节�Q�具体表现在 COFF 格式本��n的定义以及稍早提及的 COFF 格式扩展。我个�h认�ؓ�Q�节�D�表的出现可能是 COFF 格式相对 a.out 格式最大的�q�步。下面我们将��单描�q?COFF 文�g中节的数据结构，因�ؓ节的意义更多体现在程序的�~�译和连接上�Q�所以本文不对其做更多的描述。此外，ELF 格式�?COFF格式对节的定义非常相��|��在随后的 ELF 格式分析中，我们��省略相兌��论。struct COFF_scnhdr
            {
                  char s_name[8];       /* 节名�U?*/
                  char s_paddr[4];      /* 物理地址 */
                  char s_vaddr[4];      /* 虚拟地址 */
                  char s_size[4];         /* 节长�?*/
                  char s_scnptr[4];    /* 节数据相�Ҏ��件的偏移�?*/
                  char s_relptr[4];      /* 节重定位信息偏移�?*/
                  char s_lnnoptr[4];    /* 节行信息偏移�?*/
                  char s_nreloc[2];     /* 节重定位条目�?*/
                  char s_nlnno[2];      /* 节行信息条目�?*/
                  char s_flags[4];       /* �D�|��?*/
            };

有一炚w��要注意：LINUX�pȝ��中头文�gcoff.h中对字段s_paddr的注释是"physical address"�Q�但��g��应该理解�?节被加蝲到内存中所占用的空间长�?。字�D�s_flags标记该节的类型，如文本段、数据段、BSS�D늭�。在COFF的节中也出现了行信息�Q�行信息描述了二�q�制代码与源代码的行号之间的�Ҏ��关系�Q�在调试时很有用�?br>转自�Q?br>http://www.360doc.com/content/080313/18/59039_1115300.html

chatler 2009-12-05 23:34 发表评论

chatler — Sat, 21 Nov 2009 10:52:00 GMT

1. 概述

Executable and linking format(ELF)文�g是x86 Linux�pȝ��下的一�U�常用目标文�?object file)格式�Q�有三种主要�c�d��:

(1)适于�q�接的可重定位文�?relocatable file)�Q�可与其它目标文件一起创建可执行文�g和共享目标文件�?/p>

(2)适于执行的可执行文�g(executable file)�Q�用于提供程序的�q�程映像�Q�加载的内存执行�?/p>

(3)�׃�n目标文�g(shared object file),�q�接器可��它与其它可重定位文件和�׃�n目标文�g�q�接成其它的目标文�g�Q�动态连接器又可��它与可执行文�g和其它共享目标文件结合�v来创��Z��个进�E�映像�?/p>

ELF文�g格式比较复杂�Q�本文只是简要介�l�它的结构，希望能给想了解ELF文�g�l�构的读者以帮助。具体详��的资料请参阅专门的ELF文档�?/p>

2. 文�g格式

��Z��方便和高效，ELF文�g内容有两个��^行的视角:一个是�E�序�q�接角度�Q�另一个是�E�序�q�行角度�Q�如�?所�C��?/p>

ELF header在文件开始处描述了整个文件的�l�织�Q�Section提供了目标文件的各项信息�Q�如指��o、数据、符可��、重定位信息�{�）�Q�Program header table指出怎样创徏�q�程映像�Q�含有每个program header的入口，Section header table包含每一个section的入口，�l�出名字、大��等信息�?/p>

�?

3. 数据表示

ELF数据�~�码��序与机器相养I��数据�c�d��有六�U�，见表1�?/p>

4. ELF文�g�?/p>

象bmp、exe�{�文件一��P��ELF的文件头包含整个文�g的控制结构。它的定义如下：

#define EI_NIDENT 16
typedef struct{
unsigned char e_ident[EI_NIDENT];
Elf32_Half e_type;
Elf32_Half e_machine;
Elf32_Word e_version;
Elf32_Addr e_entry;
Elf32_Off e_phoff;
Elf32_Off e_shoff;
Elf32_Word e_flags;
Elf32_Half e_ehsize;
Elf32_Half e_phentsize;
Elf32_Half e_phnum;
Elf32_Half e_shentsize;
Elf32_Half e_shnum;
Elf32_Half e_shstrndx;
}Elf32_Ehdr;

其中E_ident�?6个字节标明是个ELF文�g�Q?F+'E'+'L'+'F'+class +data+version+pad�Q�。E_type表示文�g�c�d��Q?表示可执行文件。E_machine说明机器�c�d��Q?表示386机器�Q?表示MIPS机器。E_entry�l�出�q�程开始的虚地址�Q�即�pȝ��控制�{�Uȝ��位置。E_phoff指出program header table的文件偏�U�，e_phentsize表示一个program header表中的入口的长度�Q�字节数表示�Q�，e_phnum�l�出program header表中的入口数目。类似的�Q�e_shoff�Q�e_shentsize�Q�e_shnum 分别表示section header表的文�g偏移�Q�表中每个入口的的字节数和入口数目。E_flags�l�出与处理器相关的标志，e_ehsize�l�出ELF文�g头的长度�Q�字节数表示�Q�。E_shstrndx表示section名表的位�|�，指出在section header表中的烦引�?/p>

下面有个elf文�g头的例子�Q�可以对照理解，见图2�?/p>

�?

5. section header

目标文�g的section header table可以定位所有的section�Q�它是一个Elf32_Shdr�l�构的数�l�，Section头表的烦引是�q�个数组的下标。有些烦引号是保留的�Q�目标文件不能��用这些特�D�的索引�?/p>

Section包含目标文�g除了ELF文�g头、程序头表、section头表的所有信息，而且目标文�gsection满��几个条�g:

(1)目标文�g中的每个section都只有一个section头项描述�Q�可以存在不指示��M��section的section头项�?/p>

(2)每个section在文件中占据一块连�l�的�I�间�?/p>

(3)Section之间不可重叠�?/p>

(4)目标文�g可以有非�z�d��I�间�Q�各�U�headers和sections没有覆盖目标文�g的每一个字节，�q�些非活动空间是没有定义的�?/p>

Section header�l�构定义如下�Q?/p>

typedef struct{
Elf32_Word sh_name;
Elf32_Word sh_type;
Elf32_Word sh_flags;
Elf32_Addr sh_addr;
Elf32_Off sh_offset;
Elf32_Word sh_size;
Elf32_Word sh_link;
Elf32_Word sh_info;
Elf32_Word sh_addralign;
Elf32_Word sh_entsize;
}Elf32_Shdr;

其中sh_name指出section的名字，它的值是后面��会讲到的section header string table中的索引�Q�指��Z��个以null�l�尾的字�W�串。Sh_type是类别，sh_flags指示该section在进�E�执行时的特性。Sh_addr指出若此section在进�E�的内存映像中出玎ͼ�则给出开始的虚地址。Sh_offset�l�出此section在文件中的偏�U�R��其它字�D늚�意义不太常用�Q�在此不�l�述�?/p>

文�g的section含有�E�序和控制信息，�pȝ��使用一些特定的section�Q��ƈ有其固定的类型和属性（由sh_type和sh_info指出�Q�。下面介�l�几个常用到的section:“.bss”�D�含有占据程序内存映像的未初始化数据�Q�当�E�序开始运行时�pȝ��对这�D�|��据初始�ؓ�Ӟ��但这个section�q�不占文件空间�?#8220;.data.”�?#8220;data1”�D�包含占据内存映像的初始化数据�?#8220;.rodata”�?#8220;.rodata1”�D�含�E�序映像中的只读数据�?#8220;.shstrtab”�D�含有每个section的名字，由section入口�l�构中的sh_name索引�?#8220;.strtab”�D�含有表�C�符可��(symbol table)名字的字�W�串�?#8220;.symtab”�D�含有文件的�W�号表，在后文专门介�l��?#8220;.text”�D�包含程序的可执行指令�?/p>

6. symbol table

目标文�g的符可��包含定位或重定位�E�序�W�号定义和引用时所需要的信息。符可��入口�l�构定义如下:

typedef struct{
Elf32_Word st_name;
Elf32_Addr st_value;
Elf32_Word st_size;
Unsigned char st_info;
Unsigned char st_other;
Elf32_Half st_shndx;
}Elf32_Sym;

其中st_name包含指向�W�号表字�W�串�?strtab)中的索引�Q�从而可以获得符号名。St_value指出�W�号的��|��可能是一个绝对倹{��地址�{�。St_size指出�W�号相关的内存大��，比如一个数据结构包含的字节数等。St_info规定了符��L��c�d��和绑定属性，指出�q�个�W�号是一个数据名、函数名、section名还是源文�g名；�q�且指出该符��L��l�定属性是local、global�q�是weak�?/p>

转自�Q?/p>

http://tech.ccidnet.com/art/305/20020126/9179_1.html

chatler 2009-11-21 18:52 发表评论

chatler — Sun, 15 Nov 2009 13:51:00 GMT

本文讨论�?UNIX/LINUX �q�_��下三�U�主要的可执行文件格式：a.out(assembler and link editor output 汇编器和链接�~�辑器的输出)、COFF(Common Object File Format 通用对象文�g格式)、ELF(Executable and Linking Format 可执行和链接格式)。首先是对可执行文�g格式的一个综�q�ͼ��q��过描述 ELF 文�g加蝲�q�程以揭�C�可执行文�g内容与加载运行操作之间的关系。随后依此讨��Z��此三�U�文件格式，�q�着重讨�?ELF 文�g的动态连接机�Ӟ��光��也穿插了对各�U�文件格式优�~�点的评仗��最后对三种可执行文件格式有一个简单�ȝ��Q��ƈ提出作者对可文件格式评��L��一些感惟�?

　　可执行文件格式综�q?/p>

　　相对于其它文件类型，可执行文件可能是一个操作系�l�中最重要的文件类型，因�ؓ它们是完成操作的真正执行者。可执行文�g的大��、运行速度、资源占用情况以及可扩展性、可�U�L��性等与文件格式的定义和文件加载过�E�紧密相兟뀂研�I�可执行文�g的格式对�~�写高性能�E�序和一些黑客技术的�q�用都是非常有意义的�?/p>

　　不管何种可执行文件格式，一些基本的要素是必��ȝ��Q�显而易见的�Q�文件中应包含代码和数据。因为文件可能引用外部文件定义的�W�号(变量和函�?�Q�因此重定位信息和符号信息也是需要的。一些辅助信息是可选的�Q�如调试信息、硬件信息等。基本上��L��一�U�可执行文�g格式都是按区间保存上�q�C��息，�U�Cؓ�D?Segment)或节(Section)。不同的文�g格式中段和节的含义可能有�l�微区别�Q�但�Ҏ��上下文关�p�d��以很清楚的理解，�q�不是关键问题。最后，可执行文仉��常都有一个文件头部以描述本文件的��M��l�构�?/p>

　　相对可执行文件有三个重要的概念：�~�译(compile)、连�?link�Q�也可称为链接、联�?、加�?load)。源�E�序文�g被编译成目标文�g�Q�多个目标文件被�q�接成一个最�l�的可执行文�Ӟ��可执行文件被加蝲到内存中�q�行。因为本文重�Ҏ��讨论可执行文件格式，因此加蝲�q�程也相寚w��点讨论。下面是LINUX�q�_��下ELF文�g加蝲�q�程的一个简单描�q��?/p>

　　1�Q�内栔R��先读ELF文�g的头部，然后�Ҏ��头部的数据指�C�分别读入各�U�数据结构，扑ֈ�标记为可加蝲(loadable)的段�Q��ƈ调用函数 mmap()把段内容加蝲到内存中。在加蝲之前�Q�内核把�D늚�标记直接传递给 mmap()�Q�段的标记指�C��D�在内存中是否可诅R��可写，可执行。显�Ӟ��文本�D�|��只读可执行，而数据段是可��d��写。这�U�方式是利用了现代操作系�l�和处理器对内存的保护功能。著名的Shellcode(参考资�?17)的编写技巧则是突破此保护功能的一个实际例子�?/p> 2�Q�内核分析出ELF文�g标记�?PT_INTERP 的段中所对应的动态连接器名称�Q��ƈ加蝲动态连接器。现�?LINUX �pȝ��的动态连接器通常�?/lib/ld-linux.so.2�Q�相关细节在后面有详�l�描�q��?

　　3�Q�内核在新进�E�的堆栈中设�|�一些标�?值对�Q�以指示动态连接器的相��x��作�?/p>

　　4�Q�内核把控制传递给动态连接器�?/p>

　　5�Q�动态连接器��查程序对外部文�g(�׃�n�?的依赖性，�q�在需要时对其�q�行加蝲�?/p>

　　6�Q�动态连接器对程序的外部引用�q�行重定位，通俗的讲�Q�就是告诉程序其引用的外部变�?函数的地址�Q�此地址位于�׃�n库被加蝲在内存的区间内。动态连接还有一个�g�q?Lazy)定位的特性，卛_��?真正"需要引用符��h��才重定位�Q�这�Ҏ��高程序运行效率有极大帮助�?/p>

　　7�Q�动态连接器执行在ELF文�g中标��Cؓ .init 的节的代码，�q�行�E�序�q�行的初始化。在早期�pȝ��中，初始化代码对应函�?_init(void)(函数名强制固�?�Q�在��C��pȝ��中，则对应�Ş式�ؓ

　　void

　　__attribute((constructor))

　　init_function(void)

　　{

　　……

　　}

　　其中函数名�ؓ��L��?br>

8�Q�动态连接器把控制传递给�E�序�Q�从 ELF 文�g头部中定义的�E�序�q�入点开始执行。在 a.out 格式和ELF格式中，�E�序�q�入点的值是昑ּ�存在的，�?COFF 格式中则是由规范隐含定义�?/p>

　　从上面的描述可以看出�Q�加载文件最重要的是完成两�g事情�Q�加载程序段和数据段到内�?�q�行外部定义�W�号的重定位。重定位是程序连接中一个重要概��c��我们知道，一个可执行�E�序通常是由一个含�?main() 的主�E�序文�g、若�q�目标文件、若�q�共享库(Shared Libraries)�l�成�?注：采用一些特别的技巧，也可�~�写没有 main 函数的程序，请参阅参考资�?2)一�?C �E�序可能引用�׃�n库定义的变量或函敎ͼ�换句话说��是�E�序�q�行时必��ȝ��道这些变�?函数的地址。在静态连接中�Q�程序所有需要��用的外部定义都完全包含在可执行程序中�Q�而动态连接则只在可执行文件中讄��相关外部定义的一些引用信息，真正的重定位是在�E�序�q�行之时。静态连接方式有两个大问题：如果库中变量或函数有��M��变化都必��重新编译连接程�?如果多个�E�序引用同样的变�?函数�Q�则此变�?函数会在文�g/内存中出现多�ơ，��费��盘/内存�I�间。比较两�U�连接方式生成的可执行文件的大小�Q�可以看出有明显的区别�?/p> a.out 文�g格式分析

　　a.out 文�g包含 7 �?section�Q�格式如下：

　　exec header(执行头部�Q�也可理解�ؓ文�g头部)

　　text segment(文本�D?

　　data segment(数据�D?

　　text relocations(文本重定位段)

　　data relocations(数据重定位段)

　　symbol table(�W�号�?

　　string table(字符串表)

　　执行头部的数据结构：

　　struct exec {

　　unsigned long a_midmag; /* ��数和其它信�?*/

　　unsigned long a_text; /* 文本�D늚�长度 */

　　unsigned long a_data; /* 数据�D늚�长度 */

　　unsigned long a_bss; /* BSS�D늚�长度 */

　　unsigned long a_syms; /* �W�号表的长度 */

　　unsigned long a_entry; /* �E�序�q�入�?*/

　　unsigned long a_trsize; /* 文本重定位表的长�?*/

　　unsigned long a_drsize; /* 数据重定位表的长�?*/

　　};

文�g头部主要描述了各�?section 的长度，比较重要的字�D�|�� a_entry(�E�序�q�入�?�Q�代表了�pȝ��在加载程序�ƈ初试化各�U�环境后开始执行程序代码的入口。这个字�D�在后面讨论�?ELF 文�g头部中也有出现。由 a.out 格式和头部数据结构我们可以看出，a.out 的格式非常紧凑，只包含了�E�序�q�行所必须的信�?文本、数据、BSS)�Q�而且每个 section 的顺序是固定的。这�U�结构缺乏扩展性，如不能包�?��C��"可执行文件中常见的调试信息，最初的 UNIX 黑客�?a.out 文�g调试使用的工��h�� adb�Q��?adb 是一�U�机器语�a�调试�?

　　a.out 是早期UNIX�pȝ��使用的可执行文�g格式�Q�由 AT&T 设计�Q�现在基本上已被 ELF 文�g格式代替。a.out 的设计比较简单，但其设计思想明显的被后箋的可执行文�g格式所�l�承和发扬。可以参阅参考资�?16 和阅��d��考资�?15 源代码加深对 a.out 格式的理解。参考资�?12 讨论了如何在"��C��"的红帽LINUX�q�行 a.out 格式文�g�?/p> COFF 文�g格式分析

　　COFF 文�g格式如下�Q?/p>

　　File Header(文�g头部)

　　Optional Header(可选文件头�?

　　Section 1 Header(节头�?

　　………

　　Section n Header(节头�?

　　Raw Data for Section 1(节数�?

　　Raw Data for Section n(节数�?

　　Relocation Info for Sect. 1(节重定位数据)

　　Relocation Info for Sect. n(节重定位数据)

　　Line Numbers for Sect. 1(节行��h��?

　　Line Numbers for Sect. n(节行��h��?

　　Symbol table(�W�号�?

　　String table(字符串表)

　　文�g头部的数据结构：

　　struct filehdr

　　{

　　unsigned short f_magic; /* ��数 */

　　unsigned short f_nscns; /* 节个�?*/

　　long f_timdat; /* 文�g建立旉�� */

　　long f_symptr; /* �W�号表相�Ҏ��件的偏移�?*/

　　long f_nsyms; /* �W�号表条目个�?*/

　　unsigned short f_opthdr; /* 可选头部长�?*/

　　unsigned short f_flags; /* 标志 */

　　};

COFF 文�g头部中魔��C��其它两种格式的意义不太一��P��它是表示针对的机器类型，例如 0x014c 相对�?I386 �q�_��Q��?0x268 相对�?Motorola 68000�p�d��{�。当 COFF 文�g为可执行文�g�Ӟ��字段 f_flags 的��gؓ F_EXEC(0X00002)�Q�同时也表示此文件没有未解析的符��P��换句话说�Q�也��是重定位在�q�接时就已经完成。由此也可以看出�Q�原始的 COFF 格式不支持动态连接。�ؓ了解册��个问题以及增加一些新的特性，一些操作系�l�对 COFF 格式�q�行了扩展。Microsoft 设计了名�?PE(Portable Executable)的文件格式，主要扩展是在 COFF 文�g头部之上增加了一些专用头部，具体�l�节请参阅参考资�?18�Q�某�?UNIX �pȝ��也对 COFF 格式�q�行了扩展，�?XCOFF(extended common object file format)格式�Q�支持动态连接，请参阅参考资�?5�?/p>

　　紧接文�g头部的是可选头部，COFF 文�g格式规范中规定可选头部的长度可以�?0�Q�但�?LINUX �pȝ��下可选头部是必须存在的。下面是 LINUX 下可选头部的数据�l�构�Q?/p> typedef struct

　　{

　　char magic[2]; /* ��数 */

　　char vstamp[2]; /* 版本�?*/

　　char tsize[4]; /* 文本�D�长�?*/

　　char dsize[4]; /* 已初始化数据�D�长�?*/

　　char bsize[4]; /* 未初始化数据�D�长�?*/

　　char entry[4]; /* �E�序�q�入�?*/

　　char text_start[4]; /* 文本�D�基地址 */

　　char data_start[4]; /* 数据�D�基地址 */

　　}

　　COFF_AOUTHDR;

　　struct COFF_scnhdr

　　{

　　char s_name[8]; /* 节名�U?*/

　　char s_paddr[4]; /* 物理地址 */

　　char s_vaddr[4]; /* 虚拟地址 */

　　char s_size[4]; /* 节长�?*/

　　char s_scnptr[4]; /* 节数据相�Ҏ��件的偏移�?*/

　　char s_relptr[4]; /* 节重定位信息偏移�?*/

　　char s_lnnoptr[4]; /* 节行信息偏移�?*/

　　char s_nreloc[2]; /* 节重定位条目�?*/

　　char s_nlnno[2]; /* 节行信息条目�?*/

　　char s_flags[4]; /* �D�|��?*/

　　};

　　有一炚w��要注意：LINUX�pȝ��中头文�gcoff.h中对字段s_paddr的注释是"physical address"�Q�但��g��应该理解�?节被加蝲到内存中所占用的空间长�?。字�D�s_flags标记该节的类型，如文本段、数据段、BSS�D늭�。在 COFF的节中也出现了行信息�Q�行信息描述了二�q�制代码与源代码的行号之间的�Ҏ��关系�Q�在调试时很有用�?/p> ELF文�g格式分析

　　ELF 文�g有三�U�类型：可重定位文�g�Q�也��是通常�U�的目标文�g�Q�后�~��?o。共享文�Ӟ��也就是通常�U�的库文�Ӟ��后缀�?so。可执行文�g�Q�本文主要讨论的文�g格式�Q��ȝ��来说�Q�可执行文�g的格式与上述两种文�g的格式之间的区别主要在于观察的角度不同：一�U�称��接视�?Linking View)�Q�一�U�称为执行视�?Execution View)�?/p>

　　首先看看ELF文�g的��M��布局�Q?/p>

　　ELF header(ELF头部)

　　Program header table(�E�序头表)

　　Segment1(�D?)

　　Segment2(�D?)

　　………

　　Sengmentn(�D�n)

　　Setion header table(节头表，可�?

　　�D는�若干个节(Section)构成,节头表对每一个节的信息有相关描述。对可执行程序而言�Q�节头表是可选的。参考资�?1中作者谈到把节头表的所有数据全部设�|��ؓ0�Q�程序也能正��运�?ELF头部是一个关于本文�g的�\�U�图(road map)�Q�从��M��上描�q�文件的�l�构。下面是ELF头部的数据结构：

　　typedef struct

　　{

　　unsigned char e_ident[EI_NIDENT]; /* ��数和相关信�?*/

　　Elf32_Half e_type; /* 目标文�g�c�d�� */

　　Elf32_Half e_machine; /* ��g体系 */

　　Elf32_Word e_version; /* 目标文�g版本 */

　　Elf32_Addr e_entry; /* �E�序�q�入�?*/

　　Elf32_Off e_phoff; /* �E�序头部偏移�?*/

　　Elf32_Off e_shoff; /* 节头部偏�U�量 */

　　Elf32_Word e_flags; /* 处理器特定标�?*/

　　Elf32_Half e_ehsize; /* ELF头部长度 */

　　Elf32_Half e_phentsize; /* �E�序头部中一个条目的长度 */

　　Elf32_Half e_phnum; /* �E�序头部条目个数 */

　　Elf32_Half e_shentsize; /* 节头部中一个条目的长度 */

　　Elf32_Half e_shnum; /* 节头部条目个�?*/

　　Elf32_Half e_shstrndx; /* 节头部字�W�表索引 */

　　} Elf32_Ehdr;

e_ident [0]-e_ident[3]包含了ELF文�g的魔敎ͼ�依次�?x7f�?E'�?L'�?F'。注意，��M��一个ELF 文�g必须包含此魔数。参考资�?3中讨��Z��利用�E�序、工兗��?Proc文�g�pȝ��{�多�U�查看ELF��数的方法。e_ident[4]表示��g�pȝ��的位敎ͼ�1代表32位，2代表64位�?e_ident[5] 表示数据�~�码方式�Q?代表��印�W�安排序(最大有意义的字节占有最低的地址)�Q?代表大印�W�安排序(最大有意义的字节占有最高的地址)。e_ident [6]指定ELF头部的版本，当前必须�?。e_ident[7]到e_ident[14]是填充符�Q�通常�?。ELF格式规范中定义这几个字节是被忽略的，但实际上是这几个字节完全可以可被利用。如病毒Lin/Glaurung.676/666(参考资�?1)讄�� e_ident[7]�?x21,表示本文件已被感�?或者存攑֏�执行代码(参考资�?2)。ELF头部中大多数字段都是对子头部数据的描�q�ͼ�其意义相�Ҏ��较简单。值得注意的是某些病毒可能修改字段e_entry(�E�序�q�入�?的��|��以指向病毒代码，例如上面提到的病毒Lin/Glaurung.676/666�?/p> 一个实际可执行文�g的文件头部�Ş式如下：(利用命��oreadelf)

　　ELF Header:

　　Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00

　　Class: ELF32

　　Data: 2's complement, little endian

　　Version: 1 (current)

　　OS/ABI: UNIX - System V

　　ABI Version: 0

　　Type: EXEC (Executable file)

　　Machine: Intel 80386

　　Version: 0x1

　　Entry point address: 0x80483cc

　　Start of program headers: 52 (bytes into file)

　　Start of section headers: 14936 (bytes into file)

　　Flags: 0x0

　　Size of this header: 52 (bytes)

　　Size of program headers: 32 (bytes)

　　Number of program headers: 6

　　Size of section headers: 40 (bytes)

　　Number of section headers: 34

　　Section header string table index: 31

　　紧接ELF头部的是�E�序头表�Q�它是一个结构数�l�，包含了ELF头表中字�D�e_phnum定义的条目，�l�构描述一个段或其他系�l�准备执行该�E�序所需要的信息�?/p>

　　typedef struct {

　　Elf32_Word p_type; /* �D늱��?*/

　　Elf32_Off p_offset; /* �D�位�|�相对于文�g开始处的偏�U�量 */

　　Elf32_Addr p_vaddr; /* �D�在内存中的地址 */

　　Elf32_Addr p_paddr; /* �D늚�物理地址 */

　　Elf32_Word p_filesz; /* �D�在文�g中的长度 */

　　Elf32_Word p_memsz; /* �D�在内存中的长度 */

　　Elf32_Word p_flags; /* �D늚�标记 */

　　Elf32_Word p_align; /* �D�在内存中对齐标�?*/

　　} Elf32_Phdr;

在详�l�讨论可执行文�g�E�序头表之前�Q�首先查看一个实际文件的输出�Q?/p>

　　Program Headers:

　　Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align

　　PHDR 0x000034 0x08048034 0x08048034 0x000c0 0x000c0 R E 0x4

　　INTERP 0x0000f4 0x080480f4 0x080480f4 0x00013 0x00013 R 0x1

　　[Requesting program interpreter: /lib/ld-linux.so.2]

　　LOAD 0x000000 0x08048000 0x08048000 0x00684 0x00684 R E 0x1000

　　LOAD 0x000684 0x08049684 0x08049684 0x00118 0x00130 RW 0x1000

　　DYNAMIC 0x000690 0x08049690 0x08049690 0x000c8 0x000c8 RW 0x4

　　NOTE 0x000108 0x08048108 0x08048108 0x00020 0x00020 R 0x4

Section to Segment mapping:

　　Segment Sections...

　　01 .interp

　　02 .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame

　　03 .data .dynamic .ctors .dtors .jcr .got .bss

　　04 .dynamic

　　05 .note.ABI-tag

　　Section Headers:

　　[Nr] Name Type Addr Off Size ES Flg Lk Inf Al

　　[ 0] NULL 00000000 000000 000000 00 0 0 0

　　[ 1] .interp PROGBITS 080480f4 0000f4 000013 00 A 0 0 1

　　[ 2] .note.ABI-tag NOTE 08048108 000108 000020 00 A 0 0 4

　　[ 3] .hash HASH 08048128 000128 000040 04 A 4 0 4

　　[ 4] .dynsym DYNSYM 08048168 000168 0000b0 10 A 5 1 4

　　[ 5] .dynstr STRTAB 08048218 000218 00007b 00 A 0 0 1

　　[ 6] .gnu.version VERSYM 08048294 000294 000016 02 A 4 0 2

　　[ 7] .gnu.version_r VERNEED 080482ac 0002ac 000030 00 A 5 1 4

　　[ 8] .rel.dyn REL 080482dc 0002dc 000008 08 A 4 0 4

　　[ 9] .rel.plt REL 080482e4 0002e4 000040 08 A 4 b 4

　　[10] .init PROGBITS 08048324 000324 000017 00 AX 0 0 4

　　[11] .plt PROGBITS 0804833c 00033c 000090 04 AX 0 0 4

　　[12] .text PROGBITS 080483cc 0003cc 0001f8 00 AX 0 0 4

　　[13] .fini PROGBITS 080485c4 0005c4 00001b 00 AX 0 0 4

　　[14] .rodata PROGBITS 080485e0 0005e0 00009f 00 A 0 0 32

　　[15] .eh_frame PROGBITS 08048680 000680 000004 00 A 0 0 4

　　[16] .data PROGBITS 08049684 000684 00000c 00 WA 0 0 4

　　[17] .dynamic DYNAMIC 08049690 000690 0000c8 08 WA 5 0 4

　　[18] .ctors PROGBITS 08049758 000758 000008 00 WA 0 0 4

　　[19] .dtors PROGBITS 08049760 000760 000008 00 WA 0 0 4

　　[20] .jcr PROGBITS 08049768 000768 000004 00 WA 0 0 4

　　[21] .got PROGBITS 0804976c 00076c 000030 04 WA 0 0 4

　　[22] .bss NOBITS 0804979c 00079c 000018 00 WA 0 0 4

　　[23] .comment PROGBITS 00000000 00079c 000132 00 0 0 1

　　[24] .debug_aranges PROGBITS 00000000 0008d0 000098 00 0 0 8

　　[25] .debug_pubnames PROGBITS 00000000 000968 000040 00 0 0 1

　　[26] .debug_info PROGBITS 00000000 0009a8 001cc6 00 0 0 1

　　[27] .debug_abbrev PROGBITS 00000000 00266e 0002cc 00 0 0 1

　　[28] .debug_line PROGBITS 00000000 00293a 0003dc 00 0 0 1

[29] .debug_frame PROGBITS 00000000 002d18 000048 00 0 0 4

　　[30] .debug_str PROGBITS 00000000 002d60 000bcd 01 MS 0 0 1

　　[31] .shstrtab STRTAB 00000000 00392d 00012b 00 0 0 1

　　[32] .symtab SYMTAB 00000000 003fa8 000740 10 33 56 4

　　[33] .strtab STRTAB 00000000 0046e8 000467 00 0 0 1

对一个ELF可执行程序而言�Q�一个基本的�D�|��标记p_type为PT_INTERP的段�Q�它表明了运行此�E�序所需要的�E�序解释�?/lib/ld- linux.so.2)�Q�实际上也就是动态连接器(dynamic linker)。最重要的段是标记p_type为PT_LOAD的段�Q�它表明了�ؓ�q�行�E�序而需要加载到内存的数据。查看上面实际输入，可以看见有两个可 LOAD�D�，�W�一个�ؓ只读可执�?FLg为R E),�W�二个�ؓ可读可写(Flg为RW)。段1包含了文本节.text�Q�注意到ELF文�g头部中程序进入点的��gؓ0x80483cc�Q�正好是指向�? text在内存中的地址。段二包含了数据�?data�Q�此数据节中数据是可��d��写的�Q�相对的只读数据�?rodata包含在段1中。ELF格式可以�?COFF格式包含更多的调试信息，如上面所列出的�Ş式�ؓ.debug_xxx的节。在I386�q�_��LINUX�pȝ��下，用命令file查看一个ELF可执行程序的可能输出是：a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped�?/p>

　　ELF文�g中包含了动态连接器的全路径�Q�内核定�?正确"的动态连接器在内存中的地址�?正确"�q�行可执行文件的保证�Q�参考资�?13讨论了如何通过查找动态连接器在内存中的地址以达到颠�?Subversiver)动态连接机制的�Ҏ��?/p>

　　最后我们讨论ELF文�g的动态连接机制。每一个外部定义的�W�号在全局偏移�?Global Offset Table GOT)中有相应的条�?如果�W�号是函数则在过�E�连接表(Procedure Linkage Table PLT)中也有相应的条目�Q�且一个PLT条目对应一个GOT条目。对外部定义函数解析可能是整个ELF文�g规范中最复杂的，下面是函数符可��析过�E�的一个描�q��?/p>

　　1�Q�代码中调用外部函数func,语句形式为call 0xaabbccdd,地址0xaabbccdd实际上就是符号func在PLT表中对应的条目地址(假设地址为标�?PLT2)�?/p>

　　2�Q�PLT表的形式如下

　　.PLT0: pushl 4(

转自�Q?br>http://www.linux521.com/2009/system/200908/7856_1.html

chatler 2009-11-15 21:51 发表评论