文档库 最新最全的文档下载
当前位置:文档库 › PE文件格式示意图及详解

PE文件格式示意图及详解

PE文件格式示意图及详解
PE文件格式示意图及详解

PE文件格式示意图

PE 文件格式启发式学习

问:1.1

我知道程序中最重要的段是text段,请告诉我text 段在哪?

答:1.1

text 段在文件偏移0x400处,大小0x200字节,该区可运行,可读取,包含代码。

该区在内存中RVA 0x1000处,大小0x1000.

问:1.2

我用urtraedit 打开hello.exe 看了,在0x400处-0x600处,大部分都是0,为什么这样呢。答:1.2

pe 格式大部分文件都是这样,这是对齐所要求的,文件对齐为0x200, 内存对齐为0x1000你可以在NT_Option_Header 的Section_Alignment, File_Alignment 域中看到这两个数据。//

// Optional header format.

//

typedef struct _IMAGE_OPTIONAL_HEADER {

//

// Standard fields.

//

WORD Magic;

BYTE MajorLinkerVersion;

BYTE MinorLinkerVersion;

DWORD SizeOfCode;

DWORD SizeOfInitializedData;

DWORD SizeOfUninitializedData;

DWORD AddressOfEntryPoint;

DWORD BaseOfCode;

DWORD BaseOfData;

//

// NT additional fields.

//

DWORD ImageBase;

DWORD SectionAlignment;

DWORD FileAlignment;

WORD MajorOperatingSystemVersion;

WORD MinorOperatingSystemVersion;

WORD MajorImageVersion;

WORD MinorImageVersion;

WORD MajorSubsystemVersion;

WORD MinorSubsystemVersion;

DWORD Win32VersionValue;

DWORD SizeOfImage;

DWORD SizeOfHeaders;

DWORD CheckSum;

WORD Subsystem;

WORD DllCharacteristics;

DWORD SizeOfStackReserve;

DWORD SizeOfStackCommit;

DWORD SizeOfHeapReserve;

DWORD SizeOfHeapCommit;

DWORD LoaderFlags;z

DWORD NumberOfRvaAndSizes;

IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];

} IMAGE_OPTIONAL_HEADER32, *PIMAGE_OPTIONAL_HEADER32;

问:1.3

慢点,别一下子贴那么多东西,我还没有找到 _IMAGE_OPTIONAL_HEADER 的位置呢,

告诉我怎样找

答:1.3

贴上那个_IMAGE_OPTIONAL_HEADER结构好说话,它的位置紧跟在 MAGE_FILE_HEADER 之后

告诉你个小技巧,那个Magic对NT x86来讲总是010B,在头文件找到那个010b,就是

IMAGE_OPTIONAL_HEADER32 结构的地址。

问:1.4

问题越来越多了。

_IMAGE_OPTIONAL_HEADER 还没有说清呢,又出来一个IMAGE_FILE_HEADER。先不管

IMAGE_FILE_HEADER

先按你的小技巧,在头部找到010b, 因为是little endial, 在ultraedit 中要找0b 01.

好,找到了,离那个 50 45 00 00 (ascii PE)相距不远,在偏移D8处,按你所说SectionAlignment和FileAlignment 应该在结构第9个,第10个DWORD 处。

好,找到了,在f8处有00001000, FC处为00 00 02 00 (我已经考虑了endian,以后不用提醒了)。

答:1.4

呀,进步不小吗?这样一下子你就把IMAGE_OPTIONAL_HEADER32 中所有的东西都找出来了。

问:1.5

是的,我可以把Optional header中所有东西都找出来,但我现在除了刚才介绍的第9个DWORD为内存对齐大小,第10个DWORD为文件对齐大小,其它我都不知道是干什么的?

答:1.5

别着急,其实还是很容易理解的,从字面意义就能猜大概。不过我们现在还不是通读Optional header的时候,还是拣我们最关心的问题插手吧。

问:1.6

还是回到text 段上来吧,刚才你对text段大小,位置,属性分析的头头是到

你是从那看出来的?

答:1.6

是从section header 中看出来的,每一个section, 都有一个section header 描述其位置,大小,属性。section header 的结构是这样定义的

#define IMAGE_SIZEOF_SHORT_NAME8

typedef struct _IMAGE_SECTION_HEADER {

BYTE Name[IMAGE_SIZEOF_SHORT_NAME];

union {

DWORD PhysicalAddress;

DWORD VirtualSize;

DWORD VirtualAddress;

DWORD SizeOfRawData;

DWORD PointerToRawData;

DWORD PointerToRelocations;

DWORD PointerToLinenumbers;

WORD NumberOfRelocations;

WORD NumberOfLinenumbers;

DWORD Characteristics;

} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;

问:1.7

呦,慢点,怎么又往外甩结构,我很菜!哦,不太多,还行吧。

不过你还是告诉我具体位置在哪吧,我好拿结构和数据对对号。

答:1.7

好,正是这种学习方法。你一定能学会的。

节表头是一个数组,它把所有节的位置,长度,属性放在了一起

紧跟在option header 之后,所以你从文件头部往下找就可以了。

看到IMAGE_SECTION_HEADER结构的第一个成员了吗,它是

BYTE Name【8】

这是节名称,你要找的text 段名字就是 .text, 你看ultraedit

ascii 码区离文件开始不远的地方,有一个.text, 对应的二进制

数据是2E 74 65 78 74, 这就是text 端IMAGE_SECTION_HEADER处

问:1.8

原来玄机在这里呀。我试试看。哦,看见了,在1B8处。前8个

字节是节名称。后面的00 00 00 28 到底是物理地址还是虚拟大小,

(偷偷的,虚拟大小,表示内存中只有0x28个字节有效,其它全是0),在后面00 00 10 00 是虚拟相对地址俗称RVA, 就是在内存中相对与起始地址的偏移。再后面00 00 02 00 为SizeOfRawData,就是文件中大小,再后面 00 00 04 00 是

PointerToRawData,是文件的偏移后面有三个DWORD 全是0,他们

是重定位信息和行号,很好,EXE文件可以不用管这些。最后一个

60 00 00 20 代表属性可读,可写,是代码。好,我终于理解你的第一句话了。

不解释一下,我怎么能一下子听的懂呢!谢谢你。

那么我又有问题了。那程序针真是搜索这个.text字符串找到Text 节表头吗?

答:1.8

不是。前面说过,节表头紧随Optional header 之后。

问:1.9

Optional header 结构变量太多,我数了一下都没数清,到底占多少个字节呢?

答:1.9

正等着你这一问呢?是啊,数都数不清,纵是现在记住了将来也容易忘。

估计微软也想到了这一点,他把OPTION header 的大小放到了 _IMAGE_FILE_HEADER的一个变量中,下面是_IMAGE_FILE_HEADER 的定义

typedef struct _IMAGE_FILE_HEADER {

WORD Machine;

WORD NumberOfSections;

DWORD TimeDateStamp;

DWORD PointerToSymbolTable;

DWORD NumberOfSymbols;

WORD SizeOfOptionalHeader;

WORD Characteristics;

} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;

SizeOfOptionalHeader 一般总是0xE0

我今天已经学了不少东西了,看样子后面还很多的样子。再问最后一个问题。

FILE_HEADER 在文件什么位置呢。

答:1.10

这个简单,就在PE标识符后面。看到了吗,在C0处,ascii 是PE. 二进制是50 45 00 00

代学生:

哦,看到了,今天10个问题已经满了,我还想学,可是有点累了。。。

代老师:

今天就到这里吧,好好休息一下。

接问题1.10后的第11个问题

问:2.11

干脆就把位置问题先问到底吧。PE标识符 54 45 00 00 总是在文件偏移00c0 处吗。

答:2.11

基本上可以这么说,主要是因为前面的部分是dos 头部和dos 体

dos 头部 IMAGE_DOS_HEADER 的结构我就不贴了,因为dos 已经离我们远去,它

已经失掉了意义,dos 体也几乎是固定不变的了。这部分的作用是当你拿这个

PE程序到dos 系统上运行时,dos 执行会在控制台上打印一行提示信息,

"this program cannot be run in DOS mode" 然后停在哪。总比你一运行,DOS

就hang 机强多了。如果拿PE代码在DOS 下直接执行,不用说那肯定hang 机。

微软就是怕这个事情发生才用了这么一个措施。

现在你只需要记住一件事,文件头两个字母是MZ标记,在3c偏移地址,00 00 00 c0

指的是NT header 的文件偏移,如果这个偏移处的标识正好是PE. 可以肯定,这个文件

就是PE 文件了。如果在3c偏移地址处存其它DWORD 地址,那就到所指定的地址去找

如果该处正好ASCII "PE",此处就是NT的header 。

问:2.12

怎么有这么多header, 能否概要总结一下:

答:2.12

好的。在文件开头部分是 _IMAGE_DOS_HEADER ,小名MZ header, 我们已经不用关心它了。只要关心地址偏移0x3c 处,该处存有 _IMAGE_NT_HEADER 的偏移。在dos header 和

NT header 之间是dos 体,我们也不用关心它了。

_IMAGE_NT_HEADER 到底是什么样呢?它实际是PE00标识+

NT_FILE_HEADER+NT_OPTION_HEADER

以下是它的结构声明。

typedef struct _IMAGE_NT_HEADERS {

DWORD Signature;//这里的标记是 PE00

IMAGE_FILE_HEADER FileHeader;//NT header 包含FILE header 和Option header

IMAGE_OPTIONAL_HEADER32 OptionalHeader;

} IMAGE_NT_HEADERS32, *PIMAGE_NT_HEADERS32;

问: 2.13

这样对header有了一个总体认识,它占据着文件开始部分。反正它是死的,而且每个文件只有

一个,有上面各个header 的结构定义,无非是存储这一些数据,指针。估计详细分析一下,

它也跑不了了。我们还是抓主要的,主要的分析清了,可能顺便就把头中的相关结构变量分析了。还是回到节表上来。上次已经找到了节表头,前面说是在OptionalHeader下面,现在也可以

说是在NT header下面。其中以.text 居首,根据节表头结构,从.text 偏移一个节表结构,

我们看到了第二个ascii 字符 “.rdata", 不远的地方还要一个”.data", 正好也偏移一个节表头结构“,还有一个".rsrc",再往后就是全0了,那么这是否是说,这个结构数组含有4个结构元素呢?

答: 2.13

正是如此,在_IMAGE_FILE_HEADER 中有一项定义了该数值

WORD Machine;//x86 的machine代码是 01 4c (hello.exe 中00c4处)

WORD NumberOfSections;// hello.exe 中是 00 04

与你数的完全一致。对照一下问题1.9的_IMAGE_FILE_HEADER 和 hello.exe 的,你会很容易辨别的。问: 2.14

我对照过了,知道了它在文件中的位置。干脆把NT FILE Header结构中的其他数据也分析一下吧。反正也不多。

答: 2.14

好,我再把该结构抄过来:

typedef struct _IMAGE_FILE_HEADER {

WORD Machine;//答2.12已经说了,x86 总是01 4c

WORD NumberOfSections;//hello.exe 是00 04

DWORD TimeDateStamp;//时戳。表示你的文件是何时生成的。不过这个DWORD是用秒数表示的。

DWORD PointerToSymbolTable;//调试信息,hello 中为全0

DWORD NumberOfSymbols;//调试信息,hello 中为全0

WORD SizeOfOptionalHeader;//答1.9已经说了,OptionalHeader 大小总是0xe0

WORD Characteristics;// hello.exe 是010F, 看标志有5个bit 是1,那就是说5个属性为真了。

} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;

NT FileHeader其它项都好理解,没有什么关键的东西,只有这个属性稍微麻烦一点,最多也不超过16个属性。

顺便问一下,你在ultraedit 中看着这个FILE_HEADER 吗?

代学生:哦哦,看着呢,我的光标就停在这个010F 标志处呢。

代老师:

好,继续。16个属性一下都说出来也太多,先学习hello.exe 的这5个吧。

bit0: 文件不包含重定位信息。

bit1: 文件可以运行。

bit2: 文件不包含行号信息

bit3: 文件不包含符号信息。

bit8: 32bit 机器上运行。

怎样,这你个属性很好理解吧,可执行文件不需要重定位,行号及符号信息。在32bit机器上运行。

代学生:

说了半天原来没有一个关键性东西,我还以为有多神秘呢!

代老师:是的,搞懂了它有时也觉得失望,其实,懂了也就这么简单。

问:2.15

再问一个关键性问题,看起来有点菜。我以为,有text段,有data段就可以了,

那么.rdata, .rsrc 是干什么用的呢

答:2.15

这个问题确实很关键,这正是PE 文件与以往文件的差别所在。

其实只有text段,data段,pe文件是不可以运行的,因为PE文件的运行总是要调用

系统文件,而系统文件都是以DLL 文件格式存在的,所以你必须要在文件中有动态链接

信息。

问:2.16

太复杂了,什么是动态连接信息,什么是动态连接库,听说过但没有真正理解。

答:2.16

动态连接是多进程操作系统引进的一个概念。在DOS时代,单任务是没有动态连接的。

在DOS 时代,连接器总是把库文件直接连接到可执行文件中。叫静态连接。这种做法

在单任务时是可以接受的,无非是每个连接的文件都包含一个库文件,造成磁盘空间

的一点浪费。但静态连接在多任务时代不可以接受。例如每个进程都会调用 kernel32.Dll

如果采用静态连接,造成磁盘空间浪费不说,假若系统有20个进程,系统中就将会

有20份kernel32.dll, 内存的浪费将是不可容忍的,动态连接的概念就是保证系统中

只有一份DLL,同时各个进程又都能够很好的运行。好在动态连接是加载器的功能,

我们程序不用刻意去做什么,所以用起来也不是太复杂。

问:2.17

哦!是这样,我原来以为链接程序都把事情处理好了,原来还没有,多进程中还要由

加载器进行动态连接。那我们怎样使用动态连接呢?

答:2.17

当我们用汇编语言或C C++或者其它语言开发是,生成的PE文件对系统库的调用都是

动态连接。我们并没有做什么。

当你想调用自己生成的DLL(第三方DLL),可以采用隐含动态连接或者显示动态连接来

加载DLL. 听起来很炫用起来很简单,隐含链接就跟使用系统dll 一样,你只要在文件

中包含第三方头文件(好引用它的函数啊。)在连接选项里设置第三方的lib,dll位置

链接程序就帮你搞定了。

显示动态连接是在你的程序里用loadlibrary 加载DLL, 用getprocess 获取DLL中函数

地址,然后用函数指针调用第三方函数。

问:2.18

哦. 听你的意思看来使用DLL 也是很简单的。系统DLL使用我们不用管,怎样使用第三方

DLL以后再说吧,我现在的重点是想搞明白PE 的文件格式。那么既然它调用了

kernel32.Dll 中的函数。而这个函数的地址连接程序不知道,只能由加载器在运行时动态加载。那么,加载器是怎么知道要加载那个DLL, 要执行DLL中的那个程序呢?

答: 2.18

这个问题问到点子上去了。搞清了这个问题,PE 格式就可以说入门了。

我们还是结合hello.exe 实例说吧。

有HIEW 软件吗,准备一下。

好:

1. 用hiew 打开hello.exe

2. 按F4, 选Decode.

3. 按F5, 敲入偏移400(我们上面分析过,text 段在400)

干脆我把代码贴过来吧,双// 是我注释的。

00000400: 6A00push000

00000402: 6800304000push000403000 ;" @0 "

00000407: 680C304000push00040300C ;" @0♀"

0000040C: 6A00push000

0000040E: E809000000call00000041C//hiew 分析出,这是MessageBoxA 00000413: 90nop

00000414: 90nop

00000415: 6A00push000

00000417: E806000000call000000422//hiew 分析出,这是ExitProcess 0000041C: FF2508204000jmp d,[00402008]

00000422: FF2500204000jmp d,[00402000]

; ---------------------------------------------------------------------------

我们分析 call Messagebox 吧。

40e 处: call 41c,

41c 处: jmp ds:[00402008]

00402008.

这是虚拟内存地址。我们用hiew 找到它。具体操作如下:

1.按F4, 选hex. 要看数据,选hex 合适

2.按F5, 敲入偏移600.

在hiew 中看到了下一行。

.00402000:76 20 00 00-00 00 00 00-5C 20 00 00-00 00 00 00

问:2.19

喂,慢点,打扰一下,我这个人就喜欢刨根问底。你怎么知道要敲入600呢?

答:2.19

是这样,调用DLL采用动态连接,动态连接信息是放在.rdata 段,叫只读数据段。

你刚才不是问.rdata, .rsrc 是干什么的吗?我现在才讲到了.rdata 段

要想知道.rdata 在哪,你的问.rdata 的节表头。我们已经讲过所有节表头组成一个

数组,紧跟在NT Header(总header)之后。.rdata 是第二项节表头,其名字是ascii码

很明显的。我把它copy 到这啦。

0040206C65 72 33 32 2E 64 6C 6C 00 00 80 00 45 78 69 74er32.dll..€.Exit

0040207C50 72 6F 63 65 73 73 00 6B 65 72 6E 65 6C 33 32Process.kernel32

0040208C2E 64 6C 6C 00 00 00 00 00 00 00 00 00 00 00 00.dll............

它指向一个WORD 数据019D, 后跟MessageBoxA 0字终结字符串,其后再跟USER32.dll。

这个结构有一个学名,叫 IMPORT_BY_NAME,如下定义:

//

// Import Format

//

typedef struct _IMAGE_IMPORT_BY_NAME {

WORD Hint;

BYTE Name[1];

} IMAGE_IMPORT_BY_NAME, *PIMAGE_IMPORT_BY_NAME;

Hint, 就是那个019d 了,BYTE Name[1], 这个变量定义看起来很奇怪,是吗?

代学生:是的,我很少见到这种定义。

通常我们会定义 char buffer[256], BYTE data[8]; 等类型。

BYTE Name[1], 只包含一个元素的数组,它也装不下后面的"MessageBoxA"字符串啊。

代老师:这种定义是一种指针的变通用法。

如果你真要定义成数组来包含后面的字符串,你定义成多大呢?定义成100,短字符串浪费,

长字符串可能就真能碰到一个101个字符的名字,你定义的还是占不下。

所以说,这个Name[1], 不是要你往里面装东西的,C 语言里,你可以借助这个Name 变量访问到它对应的地址。

这种用法通常是很少用的。因为它毛病很多,例如结构后面不能再定义其它变量了,必须是最后一个,定义了

数组又不用它装东西,也不符合数组的初衷. 所以你只有明白这个道理就可以了。

代学生:既然它那么不好用,为什么还那样定义呢。

代老师:还是那句话,是变通。

你看,它简洁,它完成了使命。否则你就要把结构变一变,例如按常规估计应该是这样子。

WORD Hint; BYTE *pName; 然后你要求微软说,Hint 后面不要跟字符串,要跟一个地址。这样C语言好写。

好比说大部分人沿着盘山路往山上走,也有人愿意盘着荆棘往山上爬,后者绕了近路,但风险也大。

代学生:讲了这么多,其实我看一个word 后面跟着一个0字终结符字符串,还是很好理解的吗。

代老师:C 语言以其简洁,高效,使我们受益良多。但在某些特殊的情况下,它也会力不从心。有时刻当你看着一堆堆

结构套结构,一堆堆宏套宏令你头晕时,而看看它最终的list 表或二进制输出反而能令你豁然开朗。

哦,有点扯远了。我还是最喜欢C的。

问: 3.24

找到了这个 IMPORT BY Name 结构, loader 是怎样根据这些信息修改地址的呢?

答:3.24

loader 在加载时,是要先收集信息的,不过这部分还没有讲,收集好后,以MessageBoxA为例

loader询问系统,USER32.dll 加载了吗?没有我要先加载它啦。哦,加载了,告诉我MessageBoxA

函数地址是多少?系统返回一个地址 77d5d58a, loader 就把这个地址覆盖了原来存储的 0x205c 。

这样就把MessageBoxA 的内存地址给拧上了。

注意了,这个 77d5d58a 是我机器上的MessageBoxA 内存地址,到了你的机器上,它就变成别的啦。

这正是DLL 存在的妙处。

意思表达很明确,不是吗?

问:3.25

对,它肯定能表达明确。不过目前我还有很多问题要问,别嫌麻烦呦。我问得可是很细致的。

答:3.25

难得你精神可嘉,咱们也是互相促进的。能走到这里,也可以说是渐入佳境了。

问:3.26

弱弱得问一下,3.23 提到的那个module 地址0x400000, 是固定死的吗?

答:3.26

module 加载地址,是loader 将应用程序加载到内存时的起始地址,loader 是从Option header

结构中的Image Base 项得到这个地址的,由于exe 文件不存在地址冲突问题,所以loader 总能

把程序加载到Option header 中Image Base 指定的位置,这个位置通常都是0x400000.

问:3.27

刚才没顾上问,MessageBoxA 前面那个WORD 019d,就是hint, 是干什么的。

答:3.27

那个东东是loader 向系统询问函数地址的另外一种方式,它可以向系统询问user32.dll 第019d 个

导出函数是多少?系统回答 77d5d58a 。这种导入方式叫ordinal. DLL 中有名称的导出函数都可以

用名称访问,也可以用ordinal 访问,而有的导出函数没有名,只能用ordinal方式导入。

问:3.28

刚才你是用ollydbg 来讲解的,我们不是一直用ultraedit 打开这个文件,直接分析它的二进制

结构的吗。能用ultraedit 再讲一讲linker 向 loader 说了什么吗?

答:3.28

这主要是因为动态链接的数据是一个RVA, 所以用ollydbg 讲的方便。同时由于在ollydbg中已经完

成了动态连接,跟utraedit 静态分析正好有个对照。现在我们再来看从ultraedit 中怎样找到???结构loader 拿到了数据205c,哦,不对,是我们拿到了205A,知道这是一个RVA.需要把它转成文件偏移

好看看它到底对我们说了什么。

从RVA 到 OFFSET, 我们好像还没有讲呢,就在这里补上吧。

从RVA 到 OFFSET 没有一个简单的公式,唯一的办法就是查表。

查什么表,查section header 表。

已hello.exe 为例,我们查表,看到205c 落入.rdata 节,该节的虚拟地址(就是内存地址)0x2000

对应文件偏移0600,那么205c, 则对应文件偏移的065c. 用ultraedit 观看,如下图示。跟ollydbg看到的内容一样。

0000650: 0000 0000 5c20 0000 0000 0000 9d01 4d65....\ ........Me

0000660: 7373 6167 6542 6f78 4100 7573 6572 https://www.wendangku.net/doc/3b16739041.html,er32

0000670: 2e64 6c6c 0000 8000 4578 6974 5072 6f63.dll....ExitProc

0000680: 6573 7300 6b65 726e 656c 3332 2e64 6c6c ess.kernel32.dll

代学生:顺便问一下,那些查虚拟地址到文件偏移转换的工具是这样查的吗?

代老师:是的。

问3.29

.rdata 节中大部分数据都明白了,但从610-65d 那一段数据是干什么的?

答3.29

这段数据,当然也是动态加载用的。

前面讲的link 与 loader 对话,确实如上所说,但那只是问题的一半,还有一半就是,当loader 把程序

加载到内存,它要修改数据,它怎样找到修改数据的地址,也就是说,那个存储着RVA 205c 的地址00402008 loader 是怎样得到的?还有,它怎么知道MessageBoxA在user32.dll 里面?

问3.30

平时都是我问,现在忽然被反问。翻翻前面讲的。。。

啊!是2.18 时提出来的,程序要call 41c, 41c 要向402008 地址所装的内容处跳。

哦,这是我们的读法。loader 是不会这么读的,loader 是死的,loader 是一段程序,它只会干机械的事。它怎么找到402008的,它怎么知道MessageBoxA在user32.dll 里面?还是听你讲吧。

答3.30

讲清这个问题,我们还要再看option header. 坚持住,动态加载导入部分也就差这一点点了。

在1.2中提到option header 的数据结构,在他的底部有一个成员。

IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];

看着眼晕,还不如写简单点,它的数组就是16个元素

IMAGE_DATA_DIRECTORY DataDirectory[16];

前面那个结构叫数据目录,如下定义

//

// Directory format.

//

typedef struct _IMAGE_DATA_DIRECTORY {

DWORD RelativeVirtualAddress;

DWORD Size;

} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;

挺简单的,其实就是8个字节。 16个目录吗,就是16*8 = 108 字节。占8整行

别担心,大部分没有用,微软在这里搞捉迷藏。我们只关心几个就行了。

这里首先介绍的一个叫导入表(import table)。

0000130:0000 0000 0000 0000................

0000140: 1020 0000 3c00 0000 0040 0000 a003 0000. ..<....@......

0000150: 0000 0000 0000 0000 0000 0000 0000 0000................

0000160: 0000 0000 0000 0000 0000 0000 0000 0000................

0000170: 0000 0000 0000 0000 0000 0000 0000 0000................

0000180: 0000 0000 0000 0000 0000 0000 0000 0000................

0000190: 0000 0000 0000 0000 0020 0000 1000 0000......... ......

00001a0: 0000 0000 0000 0000 0000 0000 0000 0000................

00001b0: 0000 0000 0000 0000 2e74 6578 7400 0000.........text...

为什么还留下那个.text, 一看就知道,.text 代表的是section header table 的开始地址

其上的8个整行就是16 个目录了。真要让你像计算机一样从上到下数偏移,我们还真不行,找ascii 字,我们还在行。

第一个目录叫导出表,这里为空

第二个目录叫导入表,这里虚拟地址是0x2010, 大小是3c.

2010 RVA 对应的文件偏移是610 (算法我想你已经掌握了,看3.28)

第三个目录叫资源表。RVA=0x4000, size=0x3a0 (暂时先不讨论)

第十三个目录叫IAT 表,英文全称为:Import Address Table. RVA=0x2000,size=0x10

其它的目录都是空的,没用,不理它们。

代老师:哦,是不是讲的有点多了?

代学生:还行,反正讲得挺清楚的。想不到这个小小的hello.exe 还有这么多事情。

不过再看看hello.exe文件,大部分内容都讲了,我想也不会有太多东西了。

代老师:正是,坚持一下就是胜利。

接问题3.30后的第31个问题

问4.31:

上回谈到目录项,有两个目录项要关心。

1.导入表:RVA=0x2010,size=0x3c

2.导入地址表(俗称IAT):RVA=0x2000,size=0x10

具体什么用途呢?

答4.31:

先看IAT表,loader要做的工作是把RVA=0x2000,size=0x10这么大范围的DWORD

都要重新定址。如果是00000000就不用了。

对hello.exe而言文件偏移是:(今后RVA和OFFSET的转换我就不再提了)

0000600:76200000000000005c20000000000000v......\......

再看导入表RVA=0x2010,offset=610.size=0x3c,内容如下:

0000610:5420000000000000000000006a200000T..........j..

0000620:082000004c2000000000000000000000...L..........

0000630:84200000002000000000000000000000..............

0000640:000000000000000000000000

这里是一个结构数组。该结构叫导入表的描述符

typedef struct_IMAGE_IMPORT_DESCRIPTOR{

union{

DWORD Characteristics;//0for terminating null import descriptor

DWORD OriginalFirstThunk;//RVA to original unbound IAT(PIMAGE_THUNK_DATA) };

DWORD TimeDateStamp;//0if not bound,

DWORD ForwarderChain;

DWORD Name;

DWORD FirstThunk;//RVA to IAT(if bound this IAT has actual addresses)

}IMAGE_IMPORT_DESCRIPTOR;

每个结构包含5个DWORD成员,最后一个结构,成员全是0

结构中第二个TimeDateStamp,第三个成员ForwarderChain不用关心,它们总是0

name变量:

第一个结构中为206A,对应文件偏移66A,"user32.dll"

第二个结构中为2084,对应文件偏移684"kernel32.dll"

FirstThunk地址:

第一个结构中为2008,对应文件偏移608,//我们看到这个就是IAT表的内容了

第二个结构中为2000,对应文件偏移600,//我们看到这个就是IAT表的内容了

OriginalFirstThunk地址:

第一个结构中为2054,对应文件偏移654,//654与608存储的内容是一样的

第二个结构中为204c,对应文件偏移64c,//64c与600存储的内容是一样的

怪不得一个叫first thunk,一个叫OriginalFirstThunk,原来所指地址处包含的内容是一样的.

0000640:00000000000000000000000076200000............v..

0000650:000000005c200000000000009d014d65....\........Me

0000660:https://www.wendangku.net/doc/3b16739041.html,er32

0000670:2e646c6c000080004578697450726f63.dll....ExitProc

0000680:657373006b65726e656c33322e646c6c ess.kernel32.dll

导入描述符有2个,说明它有两个DLL要导入,从Name能看出来,

第一个叫"user32.dll",第二个叫"Kernel32.dll"

描述符的FirstThunk,指向一个导入函数地址数组,就叫thunk data数组吧,该数组最后一项为00000000描述符的OriginalFirstThunk,虽然与FirstThunk所指地址不同,但该地址所包含的内容却一样。

以第一个结构为例:

这个DWORD数组为5c20000000000000,这个数组只有两项,去掉末尾标志项,只有一项,说明

只有一个函数要导入。怎么导入,在这个地方,我们以0x205c为例,把3.23中叙述过的导入过程补充完整。

1.loader从目录第二项得到Import Table(导入表)

2.导入表是一个导入描述符结构数组,以第一个结构为例

从名字项中它知道,这个动态库的名字叫"user32.dll"

3.first thunk指向thunnk data数组,是一个以全0结尾的DWORD数组,

非全0的元素或者是一个RVA(最高位为0),指向一个Import_BY_NAME结构,

或者是一个Ordinal(序号,(其最高位为1,使用时把最高位去掉就成序号啦)。

first thunk指针属于IAT表的地址范围。

hello.exe中import第一个描述符first thunk表偏移是608,608处存205c(RVA)

对应Import_BY_NAME MessageBoxA,下一个DWORD=0数组就结束了

说明user32.dll只导入了一个函数。

从上面分析可以看出。

目录项中的导入地址表:指向一个大的IAT。

目录项中的导入表:指向一个导入描述符数组。每一个描述符,描述一个DLL。而FirstThunk 指向那个大的IAT中的一个部分。我们称它为thunk data数组,数组最后一个元素DWORD为全0.

这样的一个设计结构,导入表和导入地址表的信息是有冗余的。我们不管它,知道就行了。

问:4.32

既然有了FirstThunk,还要OriginalFirstThunk干什么?它们指向的IAT内容都是一样的。

答:4.32

FirstThunk所指向的IAT,会在加载时被loader修改为真实的函数地址。而OriginalFirstThunk所指向的IAT是不会被修改的。其实我也认为,留着这个OriginalFirstThunk没有用途,可能是微软认为那个IAT

已经被修改了,万一你要再用你到拿找哇。其实我看这是多虑了,第一,IAT用完了我不会再用它。第二,万一被我们改了回头又要用,我们可以先把没改之前的备份一下呀。

不过,这都是个人意见,人家这么定义了,我们知道就行了。

问:4.33

从运行的角度来看,好像没有问题了,.text段依靠.rdata段的帮助,由loader修改为可执行代码。代码

执行时读取或存入数据段数据。hello就可以运行了。

那.rsrc段是什么呢?是资源段吗?

答:4.33

是的。本来我是没想加这个资源段的。可是不小心给加上了。这个其实你可以不用关心它的。

解开附件hello.rar,图标是一个笑脸,这就是那个资源段的功能。如果没有那个资源段。默认的图标是一个WINDOWS ICON.

问:4.34

要想显示需要的图标,需要我们做什么呢?

答:4.34

你只要把ICON资源文件连进去就行了,代码并不需要做任何事情。在创建MessageBox窗口时,系统发现你文件里有一个ICON

资源项,就替你把它画出来,如果你没有包含ICON资源,它就把自己手边的那个叫默认ICON,画到MessagBox左上角了。

问:4.35

hello.exe文件都分析完了,只是option header中还有一些项没有提到,它们重要吗?

大:4.35

有些项还是很重要的,例如程序入口点,但它们都已经很好理解了。

这里,我就把option做一个标注,此时再浏览option header的各个项,已经是时候了。

//

//Optional header format.

//

typedef struct_IMAGE_OPTIONAL_HEADER{

//

//Standard fields.

//

WORD Magic;//NT HDR32定义为010b

BYTE MajorLinkerVersion;//link version不重要

BYTE MinorLinkerVersion;

DWORD SizeOfCode;//代码段大小

DWORD SizeOfInitializedData;//初始化数据大小

DWORD SizeOfUninitializedData;//未初始化数据大小

DWORD AddressOfEntryPoint;//程序入口点:重要

DWORD BaseOfCode;//代码基址(RVA)

DWORD BaseOfData;//数据基址(RVA)

//

//NT additional fields.

//

DWORD ImageBase;//模块基址

DWORD SectionAlignment;//内存对齐调整

DWORD FileAlignment;//文件对齐调整

WORD MajorOperatingSystemVersion;//版本信息,不重要

WORD MinorOperatingSystemVersion;

WORD MajorImageVersion;

WORD MinorImageVersion;

WORD MajorSubsystemVersion;

WORD MinorSubsystemVersion;

DWORD Win32VersionValue;

DWORD SizeOfImage;//模块的大小

DWORD SizeOfHeaders;//header的大小

DWORD CheckSum;//未使用

WORD Subsystem;//02为gui,03是console

WORD DllCharacteristics;//dll用

DWORD SizeOfStackReserve;//系统加载堆和栈初始化信息

DWORD SizeOfStackCommit;

DWORD SizeOfHeapReserve;

DWORD SizeOfHeapCommit;

DWORD LoaderFlags;z//不重要

DWORD NumberOfRvaAndSizes;//总是16

IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];//16个目录,重要

}IMAGE_OPTIONAL_HEADER32,*PIMAGE_OPTIONAL_HEADER32;

optionheader重要的项是程序入口点,目录项。

optionheader中标注不重要的就不用关心了。

下面的项重要程度中等,了解一下就可以了。

1.SizeOfHeaders是文件头和节表大小之和。所以其后面紧跟段地址,该数值应与节表中第一节数值匹配。

2.BaseOfCode,SizeOfCode,该数值与节表中代码节的文件大小也是一致的,有多余之嫌。

3.SizeOfInitializedData已初始化的数据组成的块的大小.但我不知道它有什么用。

4.”.bss"段:给loader参考的。

加载器在虚拟内存中申请空间,但在磁盘上的文件中并不占用空间的块的尺寸。

这些块在程序启动时不需要指定初值,因此术语名就是"未初始化的数据"。未初始化的数据通常在一个名叫.bss的块中。

BaseOfData,已载入映像的未初始化数据(“.bss”段)的相对偏移量

SizeOfUninitializedData。申请的".bss"空间的大小。当为0时,表示没有使用".bss"段

问:4.36

能总结一下PE文件的重要项吗?

答:4.36

从运行的角度看,PE文件中重要的是程序入口点,节表,目录项。

代学生:感谢你为我们写了这么多东西。

代老师:大家共同提高。由于时间仓促,水平有限,有些观点未必正确,错误之处在所难免,希望海涵并欢迎指正。

全文完。

pe文件格式

PE文件格式详解(一)――基础知识 什么是PE文件格式: 我们知道所有文件都是一些连续(当然实际存储在磁盘上的时候不一定是连续的)的数据组织起来的,不同类型的文件肯定组织形式也各不相同;PE文件格式便是一种文件组织形式,它是32位Wind ow系统中的可执行文件EXE以及动态连接库文件DLL的组织形式。为什么我们双击一个EXE文件之后它就会被Window运行,而我们双击一个DOC文件就会被Word打开并显示其中的内容;这说明文件中肯定除了存在那些文件的主体内容(比如EXE文件中的代码,数据等,DOC文件中的文件内容等)之外还存在其他一些重要的信息。这些信息是给文件的使用者看的,比如说EXE文件的使用者就是Window,而DOC文件的使用者就是Word。Window可以根据这些信息知道把文件加载到地址空间的那个位置,知道从哪个地址开始执行;加载到内存后如何修正一些指令中的地址等等。那么PE文件中的这些重要信息都是由谁加入的呢?是由编译器和连接器完成的,针对不同的编译器和连接器通常会提供不同的选项让我们在编译和 联结生成PE文件的时候对其中的那些Window需要的信息进行设定;当然也可以按照默认的方式编译连接生成Window中默认的信息。例如:WindowNT默认的程序加载基址是0x40000;你可以在用VC连接生成EXE文件的时候使用选项更改这个地址值。在不同的操作系统中可执行文件的格式是不同的,比如在Linux上就有一种流行的ELF格式;当然它是由在Linux上的编译器和连接器生成的,

所以编译器、连接器是针对不同的CPU架构和不同的操作系统而涉及出来的。在嵌入式领域中我们经常提到交叉编译器一词,它的作用就是在一种平台下编译出能在另一个平台下运行的程序;例如,我们可以使用交叉编译器在跑Linux的X86机器上编译出能在Arm上运行的程序。 程序是如何运行起来的: 一个程序从编写出来到运行一共需要那些工具,他们都对程序作了些什么呢?里面都涉及哪些知识需要学习呢?先说工具:编辑器-》编译器-》连接器-》加载器;首先我们使用编辑器编辑源文件;然后使用编译器编译程目标文件OBJ,这里面涉及到编译原理的知识;连接器把OBJ文件和其他一些库文件和资源文件连接起来生成EXE文件,这里面涉及到不同的连接器的知识,连接器根据OS的需要生成EXE文件保存着磁盘上;当我们运行EXE文件的时候有W indow的加载器负责把EXE文件加载到线性地址空间,加载的时候便是根据上一节中说到的PE文件格式中的哪些重要信息。然后生成一个进程,如果进程中涉及到多个线程还要生成一个主线程;此后进程便开始运行;这里面涉及的东西很多,包括:PE文件格式的内容;内存管理(CPU内存管理的硬件环境以及在此基础上的OS内存管理方式);模块,进程,线程的知识;只有把这些都弄清楚之后才能比较清楚的了解这整个过程。下面就让我们先来学习PE文件格式吧。

广告设计常用图像文件格式

广告设计常用图像文件格式 平面设计中我们会接触到很多图像格式,可是你真正地了解它们吗?下面我们就平面设 计中常见的图像格式为大家分别做简单介绍。 BMP格式 BMP是英文Bitmap(位图)的简写,它是Windows操作系统中的标准图像文件格式,能够被多种Windows应用程序所支持。随着Windows操作系统的流行与丰富的Windows 应用程序的开发,BMP位图格式理所当然地被广泛应用。这种格式的特点是包含的图像信息较丰富,几乎不进行压缩,但由此导致了它与生 俱生来的缺点——占用磁盘空间过大。所以,目前BMP在单机上比较流行。 GIF格式 GIF是英文Graphics Interchange Format(图形交换格式)的缩写。顾名思义,这种格式是用来交换图片的。事实上也是如此,上世纪80年代,美国一家著名的在线信息服务机构CompuServe针对当时网络传输带宽的限制,开发出了这种GIF图像格式。 GIF格式的特点是压缩比高,磁盘空间占用较少,所以这种图像格式迅速得到了广泛的应用。最初的GIF只是简单地用来存储单幅静止图像(称为GIF87a),后来随着技术发展,可以同时存储若干幅静止图象进而形成连续的动画,使之成为当时支持2D动画为数不多的格式之一(称为GIF89a),而在GIF89a图像中可指定透明区域,使图像具有非同一般的显示效果,这更使GIF风光十足。目前Internet上大量采用的彩色动画文件多为这种 格式的文件,也称为GIF89a格式文件。 此外,考虑到网络传输中的实际情况,GIF图像格式还增加了渐显方式,也就是说,在图像传输过程中,用户可以先看到图像的大致轮廓,然后随着传输过程的继续而逐步看清图像中的细节部分,从而适应了用户的"从朦胧到清楚"的观赏心理。目前Internet上大量采 用的彩色动画文件多为这种格式的文件。 GIF格式只能保存最大8位色深的数码图像,所以它最多只能用256色来表现物体,对于色彩复杂的物体它就力不从心了。尽管如此,这种格式仍在网络上大行其道应用,这和GIF图像文件短小、下载速度快、可用许多具有同样大小的图像文件组成动画等优势是分不 开的。 JPEG格式 JPEG也是常见的一种图像格式,它由联合照片专家组(Joint Photographic Experts Group)开发并以命名为"ISO 10918-1",JPEG仅仅是一种俗称而已。JPEG文件的扩展名为。jpg或。jpeg,其压缩技术十分先进,它用有损压缩方式去除冗余的图像和彩色数据,获取得极高的压缩率的同时能展现十分丰富生动的图像,换句话说,就是可以用最少的磁盘

常用图片文件格式

总的来说,有两种截然不同的图像格式类型:即有损压缩和无损压缩。 1.有损压缩 有损压缩可以减少图像在内存和磁盘中占用的空间,在屏幕上观看图像时,不会发现它对图像的外观产生太大的不利影响。因为人的眼睛对光线比较敏感,光线对景物的作用比颜色的作用更为重要,这就是有损压缩技术的基本依据。 有损压缩的特点是保持颜色的逐渐变化,删除图像中颜色的突然变化。生物学中的大量实验证明,人类大脑会利用与附近最接近的颜色来填补所丢失的颜色。例如,对于蓝色天空背景上的一朵白云,有损压缩的方法就是删除图像中景物边缘的某些颜色部分。当在·屏幕上看这幅图时,大脑会利用在景物上看到的颜色填补所丢失的颜色部分。利用有损压缩技术,某些数据被有意地删除了,而被取消的数据也不再恢复。 无可否认,利用有损压缩技术可以大大地压缩文件的数据,但是会影响图像质量。如果使用了有损压缩的图像仅在屏幕上显示,可能对图像质量影响不太大,至少对于人类眼睛的识别程度来说区别不大。可是,如果要把一幅经过有损压缩技术处理的图像用高分辨率打印机打印出来,那么图像质量就会有明显的受损痕迹。 2.无损压缩 无损压缩的基本原理是相同的颜色信息只需保存一次。压缩图像的软件首先会确定图像中哪些区域是相同的,哪些是不同的。包括了重复数据的图像(如蓝天) 就可以被压缩,只有蓝天的起始点和终结点需要被记录下来。但是蓝色可能还会有不同的深浅,天空有时也可能被树木、山峰或其他的对象掩盖,这些就需要另外记录。从本质上看,无损压缩的方法可以删除一些重复数据,大大减少要在磁盘上保存的图像尺寸。但是,无损压缩的方法并不能减少图像的内存占用量,这是因为,当从磁盘上读取图像时,软件又会把丢失的像素用适当的颜色信息填充进来。如果要减少图像占用内存的容量,就必须使用有损压缩方法。 无损压缩方法的优点是能够比较好地保存图像的质量,但是相对来说这种方法的压缩率比较低。但是,如果需要把图像用高分辨率的打印机打印出来,最好还是使用无损压缩几乎所有的图像文件都采用各自简化的格式名作为文件扩展名。从扩展名就可知道这幅图像是按什么格式存储的,应该用什么样的软件去读/写等等。 一、BMP图像文件格式 BMP是一种与硬件设备无关的图像文件格式,使用非常广。它采用位映射存储格式,除了图像深度可选以外,不采用其他任何压缩,因此,BblP文件所占用的空间很大。BMP文件的图像深度可选lbit、4bit、8bit及24bit。BMP文件存储数据时,图像的扫描方式是按从左到右、从下到上的顺序。 由于BMP文件格式是Windows环境中交换与图有关的数据的一种标准,因此在Windows 环境中运行的图形图像软件都支持BMP图像格式。

PE格式基础及程序的装入

DOS MZ header部分是DOS时代遗留的产物,是PE文件的一个遗传基因,一个Win32程序如果在DOS下也是可以执行,只是提示:“This program cannot be run in DOS mode.”然后就结束执行,提示执行者,这个程序要在Win32系统下执行。 DOS stub 部分是DOS插桩代码,是DOS下的16位程序代码,只是为了显示上面的提示数据。这段代码是编译器在程序编译过程中自动添加的。 PE header 是真正的Win32程序的格式头部,其中包括了PE格式的各种信息,指导系统如何装载和执行此程序代码。 Section table部分是PE代码和数据的结构数据,指示装载系统代码段在哪里,数据段在哪里等。对于不同的PE文件,设计者可能要求该文件包括不同的数据的Section。所以有一个Section Table 作为索引。Section多少可以根据实际情况而不同。但至少要有一个Section。如果一个程序连代码都没有,那么他也不能称为可执行代码。在Section Table后,Section数目的多少是不定的。 二、程序的装入 当我们在explorer.exe(资源管理器)中双击某文件,执行一个可执行程序,系统会根据文件扩展名启动一个程序装载器,称之为Loader。Loader会首先检查DOS MZ Header,如果存在,就继续寻找PE header,如果这两项都不存在,就认为是DOS 16位代码,如果只存在DOS MZ Header,而其中又指示了而其中又指示了PE Header 的位置,那么Loader 就判定此文件不一个有效的PE文件,拒绝执行。 如果DOS Header 和PE Header都正常有效,那么Loader就会根据PE Header 及Section Table的指示,将相应的代码和数据映射到内存中,然后根据不同的Section进行数据的初始化,最后开始执行程序段代码。 三、PE格式高级分析 下面我们以一个真实的程序为例详细分析PE格式,分析PE格式最好有PE分析器,常用的软件是Lord PE,也有其它的分析工具和软件如PE Editor 、Stud PE等。 先分析一下磁盘文件的内容,这里我们使用UltraEdit32(UE)工具,这是一个实用的文件编辑器,可以编辑文本和二进制文件。

常见医学图像格式

附录C 图像格式 译者:Synge 发表时间:2012-05-03浏览量:1604评论数:0挑错数:0 翻译:xiaoqiao 在fMRI的早期,由于大多数据都用不同研究脉冲序列采集,然后离线大量重建,而且各研究中心文件格式各不相同、大多数的分析软件也都是各研究单位内部编写运用。如果这些数据不同其他中心交流,数据的格式不影响他们的使用。因此图像格式就像巴别塔似的多式多样。随着fMRI领域的不断发展,几种标准的文件格式逐渐得到了应用,数据分析软件包的使用促进了这些文件格式在不同研究中心和实验室的广泛运用,直到近期仍有多种形式的文件格式存在。这种境况在过去的10年里随着公认的NIfTI格式的发展和广泛认可而优化。该附录就fMRI资料存储的常见问题以及重要的文件格式做一概述, 3.1 数据存储 正如第2章所述,MRI数据的存储常采用二进制数据格式,如8位或16位。因此,磁盘上数据文件的大小就是数据图像的大小和维度,如保存维度128 ×128×96的16位图像需要25,165,824位(3 兆字节)。为了保存图像的更多信息,我们希望保存原始数据,即元数据。元数据包含了图像的各种信息,如图像维度及数据类型等。这点很重要,因为可以获得二进制数据所不知道的信息,例如,图像是128 ×128×96维度的16位图像采集还是128 ×128×192维度的8位图像采集。在这里我们主要讨论不同的图像格式保存不同的数量及种类的元数据。

MRI的结构图像通常保存为三维的资料格式。fMRI数据是一系列的图像采集,可以保存为三维格式,也可以保存为四维文件格式(第4维为时间)。通常,我们尽可能保存为四维数据格式,这样可以减少文件数量,但是有些数据分析软件包不能处理四维数据。 3.2 文件格式 神经影像的发展中出现了很多不同图像格式,常见的格式见表1.在这里我们就DICOM、Analyze和NIfTI最重要的三种格式做一讨论。 表1. 常见医学图像格式 Analyze .img/.hdr Analyze软件, 梅奥临床医学中心 DICOM 无ACR/NEMA协会 NIfTI .nii或.img/.hdr NIH影像学信息工具倡议 MINC .mnc 蒙特利尔神经学研究所(MNI,扩展名NetCDF) 3.2.1 DICOM格式 现今大多MRI仪器采集后的重建数据为DICOM格式。该数据格式源于美国放射学协会(ACR)和国际电子产品制造商协会(NEMA)。DICOM不仅仅是图像的存储格式,而且是不同成像系统的不同形式数据之间转换的模式,MRI图像只是其中一种特殊形式。目前使用的DICOM遵照1993年协议,且目前主要的MRI仪器供应商都支持该格式。 通常,DICOM把每一层图像都作为一个独立的文件,这些文件用数字命名从而反映相对应的图像层数(在不同的系统有一定差异)。文件中包含文件头信息,且必须要特定的软

PE文件头解析大全

PE可选头部 PE可执行文件中接下来的224个字节组成了PE可选头部。虽然它的名字是“可选头部”,但是请确信:这个头部并非“可选”,而是“必需”的。OPTHDROFFSET宏可以获得指向可选头部的指针: PEFILE.H #define OPTHDROFFSET(a) ((LPVOID)((BYTE *)a + \ ((PIMAGE_DOS_HEADER)a)->e_lfanew + \ SIZE_OF_NT_SIGNATURE + \ sizeof(IMAGE_FILE_HEADER))) 可选头部包含了很多关于可执行映像的重要信息,例如初始的堆栈大小、程序入口点的位置、首选基地址、操作系统版本、段对齐的信息等等。IMAGE_OPTIONAL_HEADER结构如下: WINNT.H typedef struct _IMAGE_OPTIONAL_HEADER { // // 标准域 // USHORT Magic; UCHAR MajorLinkerVersion; UCHAR MinorLinkerVersion; ULONG SizeOfCode; ULONG SizeOfInitializedData; ULONG SizeOfUninitializedData; ULONG AddressOfEntryPoint; ULONG BaseOfCode; ULONG BaseOfData; // // NT附加域 // ULONG ImageBase; ULONG SectionAlignment;

ULONG FileAlignment; USHORT MajorOperatingSystemVersion; USHORT MinorOperatingSystemVersion; USHORT MajorImageVersion; USHORT MinorImageVersion; USHORT MajorSubsystemVersion; USHORT MinorSubsystemVersion; ULONG Reserved1; ULONG SizeOfImage; ULONG SizeOfHeaders; ULONG CheckSum; USHORT Subsystem; USHORT DllCharacteristics; ULONG SizeOfStackReserve; ULONG SizeOfStackCommit; ULONG SizeOfHeapReserve; ULONG SizeOfHeapCommit; ULONG LoaderFlags; ULONG NumberOfRvaAndSizes; IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES]; } IMAGE_OPTIONAL_HEADER, *PIMAGE_OPTIONAL_HEADER; 如你所见,这个结构中所列出的域实在是冗长得过分。为了不让你对所有这些域感到厌烦,我会仅仅讨论有用的——就是说,对于探究PE文件格式而言有用的。 标准域 首先,请注意这个结构被划分为“标准域”和“NT附加域”。所谓标准域,就是和UNIX可执行文件的COFF 格式所公共的部分。虽然标准域保留了COFF中定义的名字,但是Windows NT仍然将它们用作了不同的目的——尽管换个名字更好一些。 ·Magic。我不知道这个域是干什么的,对于示例程序EXEVIEW.EXE示例程序而言,这个值是0x010B

图片常用文件几种格式

图片文件格式简介 一、格式 是英文(位图)地简写,它是操作系统中地标准图像文件格式,能够被多种应用程序所支持.随着操作系统地流行与丰富地应用程序地开发,位图格式理所当然地被广泛应用.这种格式地特点是包含地图像信息较丰富,几乎不进行压缩,但由此导致了它与生俱生来地缺点占用磁盘空间过大.所以,目前在单机上比较流行. 二、格式 是英文(图形交换格式)地缩写.顾名思义,这种格式是用来交换图片地.事实上也是如此,上世纪年代,美国一家著名地在线信息服务机构针对当时网络传输带宽地限制,开发出了这种图像格式. 格式地特点是压缩比高,磁盘空间占用较少,所以这种图像格式迅速得到了广泛地应用. 最初地只是简单地用来存储单幅静止图像(称为),后来随着技术发展,可以同时存储若干幅静止图象进而形成连续地动画,使之成为当时支持动画为数不多地格式之一(称为),而在图像中可指定透明区域,使图像具有非同一般地显示效果,这更使风光十足.目前上大量采用地彩色动画文件多为这种格式地文件,也称为格式文件. 此外,考虑到网络传输中地实际情况,图像格式还增加了渐显方式,也就是说,在图像传输过程中,用户可以先看到图像地大致轮廓,然后随着传输过程地继续而逐步看清图像中地细节部分,从而适应了用户地"从朦胧到清楚"地观赏心理.目前上大量采用地彩色动画文件多为这种格式地文件. 但有个小小地缺点,即不能存储超过色地图像.尽管如此,这种格式仍在网络上大行其道应用,这和图像文件短小、下载速度快、可用许多具有同样大小地图像文件组成动画等优势是分不开地. 三、格式 也是常见地一种图像格式,它由联合照片专家组()开发并以命名为" ",仅仅是一种俗称而已.文件地扩展名为或,其压缩技术十分先进,它用有损压缩方式去除冗余地图像和彩色数据,获取得极高地压缩率地同时能展现十分丰富生动地图像,换句话说,就是可以用最少地磁盘空间得到较好地图像质量. 同时还是一种很灵活地格式,具有调节图像质量地功能,允许你用不同地压缩比例对这种文件压缩,比如我们最高可以把地位图文件压缩至.当然我们完全可以在图像质量和文件尺寸之间找到平衡点. 由于优异地品质和杰出地表现,它地应用也非常广泛,特别是在网络和光盘读物上,肯定都能找到它地影子.目前各类浏览器均支持这种图像格式,因为格式地文件尺寸较小,下载速度快,使得页有可能以较短地下载时间提供大量美观地图像,同时也就顺理成章地成为网络上最受欢迎地图像格式. 四、格式 同样是由组织负责制定地,它有一个正式名称叫做" ",与相比,它具备更高压缩率以及更多新功能地新一代静态影像压缩技术. 作为地升级版,其压缩率比高约左右.与不同地是,同时支持有损和无损压缩,而只能

photoshop常用图像文件格式

常用图像文件格式 1.PSD格式 PSD格式是Photoshop的专用格式,能保存图像数据的每一个细小部分,包括像素信息、图层信息、通道信息、蒙版信息、色彩模式信息,所以PSD格式的文件较大。而其中的一些内容在转存为其他格式时将会丢失,并且在储存为其他格式的文件时,有时会合并图像中的各图层及附加的蒙版信息,当再次编辑时会产生不少麻烦。因此,最好再备份一个PSD 格式的文件后再进行格式转换。 2.TIFF格式 TIFF格式是一种通用的图像文件格式,是除PSD格式外唯一能存储多个通道的文件格式。几乎所有的扫描仪和多数图像软件都支持该格式。该种格式支持RGB、CMYK、Lab 和灰度等色彩模式,它包含有非压缩方式和LZW压缩方式两种。 3.JPEG格式 JPEG格式也是比较常用的图像格式,压缩比例可大可小,被大多数的图形处理软件所支持。JPEG格式的图像还被广泛应用于网页的制作。该格式还支持CMYK、RGB和灰度色彩模式,但不支持Alpha通道。 4.BMP格式 BMP格式是标准的Windows及OS/2的图像文件格式,是Photoshop中最常用的位图格式。此种格式在保存文件时几乎不经过压缩,因此它的文件体积较大,占用的磁盘空间也较大。此种存储格式支持RGB、灰度、索引、位图等色彩模式,但不支持Alpha通道。它是Windows环境下最不容易出错的文件保存格式。 5.GIF格式 GIF格式是由CompuServe公司制定的,能保存背景透明化的图像形式,但只能处理256种色彩,常用于网络传输,其传输速度要比其他格式的文件快很多,并且可以将多张图像存储为一个文件形成动画效果。 6.PNG格式 PNG格式是CompuServe公司开发出来的格式,广泛应用于网络图像的编辑。它不同于GIF格式图像,除了能保存256色,还可以保存24位的真彩色图像,具有支持透明背景和消除锯齿边缘的功能,可在不失真的情况下进行压缩保存图像。在不久将来,PNG格式将会是未来网页中使用的一种标准图像格式。 PNG格式文件在RGB和灰度模式下支持Alpha通道,但是在索引颜色和位图模式下,不支持Alpha通道。 7.EPS格式 EPS格式为压缩的PostScript格式,可用于绘图或者排版,它最大的优点是可以在排版软件中以低分辨率预览,打印或者出胶片时以高分辨率输出,可以达到效果和图像输出质量两不耽误。EPS格式支持Photoshop里所有的颜色模式,其中在位图模式下还可以支持透明,并可以用来存储点阵图和向量图形。但不支持Alpha通道。 8.PDF格式 PDF格式是Adobe公司开发的Windows,MAC OS,UNIX和DOS系统的一种电子出版软件的文档格式。该格式源于PostScript Level2语言,因此可以覆盖矢量式图像和点阵式图像,且支持超链接。此文件是由Adobe Acrobat软件生成的文件格式,该格式文件可以存储多页信息,包含图形,文档的查找和导航功能。因此在使用该软件时不需要排版就可以获得图文混排的版面。由于该格式支持超文本链接,所以是网络下载经常使用的文件。

PE文件结构

检验PE文件的有效性 <1>首先检验文件头部第一个字的值是否等于IMAGE_DOS_SIGNATURE,是则表示DOS MZ header有效 <2>一旦证明文件的Dos header 有效后,就可用e_lfanew来定位PE header <3>比较PE header 的第一个字的值是否等于IMAGE_NT_HEADER,如果前后两个值都匹配. PS.WinHex使用方法 1.Alt+G跳到指定位置 2.Ctrl+Shift+N放入新文件 3.大文件扩容,新建一个扩容大小+1的文件,把这个文件的数据复制后写入整个文件的尾地址. 4.文本搜索ctrl+F 5.十六进制搜索ctrl+alt+x 6.文本显示F7 7.打开内存alt+F9 8.进制转换器F8 9.分析选块F2 10.计算HASH ctrl+F2 11.收集文本信息ctrl+F10 12.编辑模式F6 一.IMAGE_DOS_HEADER <1>位置00H,WORD(2个字节)的e_magic为4D5A,即MZ <2>位置3CH,60,LONG(4个节节)的e_lfanew为64+112=176即B0H, 二.IMAGE_NT_HEADERS <1>位置B0H,DWORD(4个字节),PE开始标记,写入50450000,即PE <2>位置B4H,WORD,PE所要求的CPU,对于Intel平台,为4C01 <2>位置B6,WORD,PE中段总数,计划有3个段,.text代码段,.rdata只读数据段,.data全局变量数据段,所以值为0300, <3>位置C4,WORD,表示后面的PE文件可选头的占空间大小,即224字节(E0),值为E000 <4>位置C6,WORD,表示文件是EXE还是DLL,如果是可执行文件写0200,如果是dll,写0020, <5>位置C8,WORD,表示文件格式,如果是0B01表示.exe,如果是0701表示ROM映像

印前常用图像文件格式

印前常用图像文件格式 EPS DCS 是EPS格式的一种,会将档案储存为五个档案,分别是CMYK各版及预视的影像档案 特性:全名是Desktop Color Separation,是EPS格式的一种,在PhotoShop内可以储存这格式。档案储存DCS后,会共有5个档案出现,包括有CMYK各版以及预视的72dpi影像档案;即所谓“Master file”,这样便合成5个档案格式。 用途:EPS DCS最大的优点是输出比较快,因为档案已分成四色的档案,在输出分色菲林计算机时,影像传送时间可最高缩短75%,所以适合于大档案分色输出。 另一个优点是制作速度亦较快,其实DCS格式是OPI(Open Prepress Interface)工作流程概念的一个重要部份,OPI是指制作时会置入低解像度的图像,到输出时才连接高解度图像,这样便可令制作速度加快,这种工作流程概念尤其是适合一些多图像的书刊或大盒制作,所以DCS 格式亦只是与OPI概念相似,将低像度图像置入文档,至输出时,输出机便会连接高解像度图像。 所有的常用软件都能支援DCS格式。由于五个档案才是合成一个图像,所以要注意五个档案的名称一定要一致,只是多了C、M、Y、K在原本名称之后,不能改动任何一个的名称。 TIFF 是Aldus公司开发,不仅是Mac,连IBM PC相容电脑排版软版也广泛采用 特性:全名是Tagged Image File Format,是由Aldus公司开发,是一个压缩图像格式。不仅是Mac,连IBM PC相容电脑排版软件也广泛采用,所以在PhotoShop内储存TIFF时可以选择IBM或Mac。主要是描述图像的资料,包括黑白、彩色及灰度的图像。 用途:大部分的软件都支援TIFF格式,只有Illustrator5.5及5.0C不可以置入此格式,但较新的版本6.0及7.0已经可以,而且7.0更可以把档案储存成RGB或CMYK的TIFF格式,以便其他软件所使用。 在桌面排版上,TIFF及EPS都是最受欢迎的档案格式,笔者建议正常情况下可以选择TIFF格式,因为档案较细,传送时间会较快。正如上述所说,如果有clipping path的PhotoShop档案置入其它软件,应该要储存为EPS。但其实PhotoShop可以将有clipping path的相片储存为TI FF,不过并非所有软件支援,只有PageMaker6.0及6.0C能够支援有clipping path的TIFF格式,所以如果需要退出的话,可能需要考虑用EPS 格式。 当你选择TIFF的格式时,可选用IBM PC或Macintosh,而且更可选用LZW Compression,这是TIFF档案格式的压缩方式,LZW压缩后的档案品质不会劣化的,但并非所有软件及输出设备能够支援这个压缩档案,因此选用的时候必须要小心。 JPEG 是Apple公司发明,是一种高度压缩的格式,但压缩后的图像的颜色质素会较低,一个20MB的TIFF可存成4.5MB的JPEG 特性:全名是Join PhotoGraphic Experts Group,乃Apple公司其中一项重要发明,JPEG是一种高度压缩格式。在PhotoShop4.0中,当你选JPEG时,可以选择压缩后档案的质素,有高中低及最高(high、medium、low及maximum)四种选项,选最高即是颜色质素最好,但MB数会最多,如果选低颜色质素,压缩得最大,MB数会最少,例如一个20MB的TIFF压缩成最低质素后只是814Kilobytes,如果压缩成最高质素例便成为4.5MB。 用途:最初推出的JPEG格式主要地用作压缩在QuickTime上所用的图相,而后来亦备受排版及设计所使用,因为压缩后的档案传送速度较快。虽然档案传送速度快,但压缩后的图像颜色质素较低,所以一般设计师未必使用此格式。因一般的报纸所用的印刷精度较低,而压缩后的图像颜色质素亦较低,因此这格式会较多报纸商使用。 较新版本的软件能够置入JPEG格式的档案,另外亦只是采用PostScript Level II的输出设备才可支援此格式,而较特别的就是lllustrator 6. 0、7.0及Freehand7.0均可输出JPEG格式,但只是RGB模式。在PhotoShop内除了可以存JPEG压缩,只要在Emcoding上选JPEG,更可以同时使用clipping path。另外JPEG也是Internet上常用的档案格式,但观看者的电脑要有QuickTime。 PICT 主要是描述灰阶及黑白的图像 特性:主要是描述灰阶Gray Scale及黑白的图像的档案格式。储存成可以选择不同的解像度和压缩档案与否。 用途:全部软件都能够支援此格式,但是置入lllustrator 5.0 C就只能将PICT档案格式当作为模板(Template),即只是一个底板做绘图,令用者容易绘画图像而已。几个版本的Freehand都可储存成PICT的格式。 Scitex CT 是专为Scitex的产品与影像资料能直接互通的档案格式 特性:Scitex是一间以色列公司,主要产品包括一系列的高档印前系统,如输出机、扫描机及高解像度彩印机等。Scitex CT是专为Scitex 的产品与影像资料能直接互通的档案格式,通常使用于灰阶或CMYK模式的影像。 用途:在常见的软件当中,排版软件如QuarkXPress及PageMaker、图像修描软件像PhotoShop及Live Picture都能支援此格式。另外需注意,输出设备是否支援此格式,当然Scitex的输出设备是支援。

格式大全

1.常用的文件格式及其特点 补充:.txt(软件:记事本).html(网页).rtf(写字板,简化的word).wps(软件:金山公司).pdf(电子文档) . jpg(数码相机照片通常的格式).exe可执行文件.zip压缩文件 .rar压缩文件.xls电子表格.ppt纪灯片.frm窗体文件.vbp工程文件

常用的视频、音频、图像文件格式及其特点一、视频文件格式 (1)、AVI格式: AVI它于1992年被Microsoft公司推出,AVI是非编中最常用的视音文件格式,可以被称为影音格式的鼻祖。它的英文全称为Audio Video Interleaved,即音频视频交错格式,所谓“音频视频交错”,就是可以将视频和音频交织在一起进行同步播放。这种视频格式的优点是图像质量好,可以跨越多平台使用,其缺点是体积过于庞大,而且更糟糕的是压缩标准不统一,最普遍的现象就是高版本Windows媒体播放器播放不了采用早期编码编辑的AVI格式视频,而低版本Windows媒体播放器又播放不了采用最新编码编辑的AVI 格式视频。在我们的非编中,不论早期的DVStorm还是现如今的EDIUS所使用的视频文件都是AVI格式,因为它兼容性好,调用方便,图像质量好。 另外还有DV-AVI格式(摄像机采集常用),DV的英文全称是Digital Video Format,是由索尼、松下、JVC等多家厂商联合提出的一种家用数字视频格式。目前非常流行的数码摄像机就是使用这种格式记录视频数据的。它可以通过电脑的IEEE 1394端口传输视频数据到电脑,也可以将电脑中编辑好的的视频数据回录到数码摄像机中。这种视频格式的文件扩展名一般是.avi,所以也叫DV-AVI格式。

文件的常见储存格式

各种储存格式 文字: 、txt 纯文本文件,不携带字体,字形,颜色等文字修饰控制格式,一般文字处理软件都能打开它。 、doc 使用Microsoft Word创建的格式化文件,用于一般的图文排版。 、html 用超文本标记语言编写生成的文件格式,用于网页制作。 、pdf便携式文档格式,就是由Adobe系统公司开发的一种文件格式,主要应用于电子文档,出版等方面。 图形图像: 、jpg JPEG文件格式就是静态图像压缩的国际标准,就是应用广泛的图像压缩格式,多用于网络与光盘读物上。 、gif 支持透明背景图像,文件很小,色彩限定在256色以内,主要应用在网络上。 .bmp Microsoftpaaint的固定格式,文件几乎不压缩,占用磁盘空间大,普遍应用于Windows中。 动画: 、gif通过同时存储若干幅图像,进而形成连续的动画。主要用于网页。

、swf应用Macromedia公司的Flash制作的动画。具有缩放不失真、文件体积小等特点,它采用了流媒体技术,可以一边下载一边播放,目前被广泛应用于网络上。 音频: 、wav 该格式记录声音的波形,声音文件能够与原声基本一致,质量非常高,主要应用于许忠实记录原生的地方。 .mp3 一种压缩储存声音的文件格式,就是音频压缩的国际标准。特点就是声音失真小,文件小,目前网络上下载歌曲多为此格式。 、midiMIDI就是数字音乐/电子合成乐器的统一标准。MIDI文件储存的就是一系列指令、不就是波形,就是因为它需要的磁盘空间非常小,目前主要用于音乐制作。 视频: 、avi Microsft公司开发的一种数字音频与视频文件格式,主要应用在多媒体光盘上,用来保存电影、电视等各种影像信息。

pe文件结构 入门 教程

三年前,我曾经写了一个手工打造可执行程序的文章,可是因为时间关系,我的那篇文章还是有很多模糊的地方,我一直惦记着什么时候再写一篇完美的,没想到一等就等了三年。因为各种原因直到三年后的今天我终于完成了它。现在把它分享给大家,希望大家批评指正。 我们这里将不依赖任何编译器,仅仅使用一个十六进制编辑器逐个字节的手工编写一个可执行程序。以这种方式讲解PE结构,通过这个过程读者可以学习PE结构中的PE头、节表以及导入表相关方面的知识。为了简单而又令所有学习程序开发的人感到亲切,我们将完成一个Hello World! 程序。功能仅仅是运行后弹出一个消息框,消息框的内容是Hello World!。 首先了解一下Win32可执行程序的大体结构,就是通常所说的PE结构。 如图1所示PE结构示意图: 图1 标准PE结构图 由图中可以看出PE结构分为几个部分: MS-DOS MZ 头部:所有PE文件必须以一个简单的DOS MZ 头开始。有了它,一旦程序在DOS下执行,DOS就能识别出这是有效的执行体,然后运行紧随MZ header 之后的DOS程序。以此达到对Dos系统的兼容。(通常情况DOS MZ header总共占用64byte)。 MS-DOS 实模式残余程序:实际上是个有效的EXE,在不支持PE文件格式的操作系统中,它将简单显

示一个错误提示,大多数情况下它是由汇编编译器自动生成。通常,它简单调用中断21h,服务9来显示字符串"This program cannot run in DOS mode"。(在我们写的程序中,他不是必须的,可以不予以实现,但是要保留其大小,大小为112byte,为了简洁,可以使用00来填充。) PE文件标志:是PE文件结构的起始标志。(长度4byte, Windows程序此值必须为0x50450000) PE文件头:是PE相关结构 IMAGE_NT_HEADERS 的简称,其中包含了许多PE装载器用到的重要域。执行体在支持PE文件结构的操作系统中执行时,PE装载器将从DOS MZ header中找到PE header的起始偏移量,跳过了MS-DOS 实模式残余程序,直接定位到真正的文件头PE header,长度20byte。 PE文件可选头:虽然它的名字是“可选头部”,但是请确信:这个头部并非“可选”,而是“必需”的。(长度 224byte )。 各段头部:又称节头部,一个Windows NT的应用程序典型地拥有9个预定义段(节),它们是“.text”、“.bss”、“.rdata”、“.data”、“.rsrc”、“.edata”、“.idata”、“.pdata”和“.debug”。一些应用程序不需要所有的这些段,同样还有些应用程序为了自己特殊的需要而定义了更多的段。(每个段头部占40byte,我们这里也不需要所有的段,仅需3个段。) 通常我们是将PE整个结构分成四个部分,把MS-DOS MZ 头部和MS-DOS 实模式残余程序作为第一部分,可以称他为DOS部分,而PE文件标志、PE文件头、PE文件可选头三个部分作为第二部分,称之为PE头部分,因为这部分才是Windows下真正需要的部分,所以从PE文件标志开始才是真正的PE部分。各段头部是第三部分,称之为节表。它详细描述了PE文件中各个节的详细信息。最后就是各个节的实体部分了,称为节数据。 以上仅仅是对PE结构各部分的大体讲解。接下来再手写这个Hello World!程序过程中,我将详细介绍每个部分的含义。 首先准备一下工具,一个十六进制编辑器足以。我们这里使用VC++ 6.0所携带的十六进制编辑器,您也可以使用如WinHex等十六进制编辑工具。 打开VC,选择文件,新建菜单项,然后选择一个二进制文件,单击确定。一切就绪了,下面就开始手写可执行程序,如图2所示:

PE结构4——区段与代码类型

甲壳虫免杀VIP教程 https://www.wendangku.net/doc/3b16739041.html, 专业的免杀技术培训基地 我们的口号:绝对不一样的免杀教程!绝对不一样的实战体验!清晰的思路!细致全面的讲解!让你感到免杀原来可以这么简单! 动画教程只是起到技术交流作用.请大家不用利用此方法对国内的网络做破坏. 国人应该团结起来一致对外才是我们的责任.由此动画造成的任何后果和本站 无关. -------------------------------------------------------------------- 【免杀PE结构班】制作:Just41(carrieyz) 第四节【PE文件常见区段及其代码类型】 一、区段表的结构 PE文件格式中,所有的区段信息位于可选PE头之后。每个区段信息为40个字节长,并且没有任何填充信息。区段信息被定义为以下的结构: 学名:免杀技术说明大小LOADPE Name:区段名称,如".text" [8h] SizeOfRawData:RV A偏移大小[4h] VSize VirtualAddress:区段RV A起始地址[4h] VOffset PointerToRawData:区段物理偏移大小(偏移量)[4h] RSize PhysicalAddress:区段物理起始地址[4h] ROffset VirtualSize:真实长度[4h] PointerToRelocations:重定位的偏移[4h] PointerToLinenumbers:行号表的偏移[4h] NumberOfRelocations:重定位项数目[2h] NumberOfLinenumbers:行号表的数目[2h] Characteristics:区段属性[4h] 标志 计算方式: 区段表的文件偏移地址=PE头的文件偏移地址+14h+可选PE头大小+1 首先从0X3Ch处得到PE头的文件偏移地址,然后由PE头的文件偏移地址+14h得到可选PE头大小,再将上面三个数据相加再+1就得到区段表的文件偏移地址了。 VSize的大小只是效验下是否跨越下一个节了,或者是否超出了SizeOfImage,如果出现越界问题,提示非法32位应用程序,否则的话,它的值没有意义,节的大小不是由它决定的......对非最后一个节,按节间VOffset之差,最后一节用SizeOfImage-VOffset。

pe文件格式

pe文件格式:PE文件格式(1) 疯狂代码 https://www.wendangku.net/doc/3b16739041.html,/ ?:http:/https://www.wendangku.net/doc/3b16739041.html,/Waigua/Article60255.html 介绍说明:希望本文能够对初级入门CRACKER有定帮助翻译存在疏漏或者不准确希望来信指出感谢您指导!感谢看雪为我们提供这个交流平台让我们技术和时俱进!! 前言: PE("portableexecutable")文件格式是针对MSwindowsNT,windows95and win32s可执行 2进制代码(DLLsandprograms)在windowsNT内,驱动也是这个格式也可以用于对象文件和库 这个格式是Microsoft设计并在1993经过TIS(toolerfacestandard)委员会 (Microsoft,Intel,Borland,Watcom,IBM等)标准化了它基于在UNIX和VMS上运行对象文件和可执行文件COFF"commonobjectfileformat"格式 win32SDK包括个头文件包括对PE格式定义我将提及成员名和定义你也可能发现DLL文件"imagehelp.dll"非常有用它是NT部分但文档很少它些在"DeveloperNetwork"被描述 总览: 在PE文件开始我们可以发现MSDOS执行部分("stub");这使得任何个PE文件是有效DOS执行文件在DOS-stub的后是32位魔数0x00004550(IMAGE_NT_SIGNATURE).然后是个COFF格式文件头指明在何种机器上运行多少个节在里面连接时间是否是可执行文件或者DLL等DLL和可执行文件区别:DLL不能够启动只可以被其他可执行文件使用个可执行文件不能够连接到另个可执行文件 接着我们看到个可选文件头optionalheader(虽然叫“可选”它实际上直存在) COFF把可选文件头用于库不用于目标文件这里告诉我们文件如何被调入:起始地址预留堆栈数数据段尺寸 个有趣部分是尾巴上数据目录datadirectories这些目录包含指向节内数据指针例如如果文件有输出目录可以在成员IMAGE_DIRECTORY_ENTRY_EXPORT内发现个指针指向那个目录(目录描述结构->THUNKDATA结构->BYNAME结构)他将指向个节 在头后面是节头实际上节内容就是真正需要运行个所需要东西所有头和目录成员就是帮你找到它每个节有几个标志:对齐包含数据类型(化数据等)是否可以共享等及数据自身多数节含有个或多个通过“可选头”内数据目录项引用目录没有目录类型内容是化数据或者可执行代码(节是物理意义上内容组织目录是逻辑意义上内容

常用图形、图像文件格式及特点

1.JPEG格式 简称JPG,是比较流行的文件格式,适用于压缩照片类的畏途图像,可支持不同的文件压缩比,由于压缩技术先进,对图像质量影响不大,因此可用最少的磁盘空间得到最好的最好的图像质量,是目前最好的摄影图像的压缩格式。由于JPG格式一直在不断的发展演化,及其标准中有可选项,所以会存在不兼容的现象。 色彩信息比较丰富的图像适用于JPG压缩格式。 2.GIF格式 GIF格式是一种流行的彩色图形格式,常见应用于网络。GIF是一种8位彩色文件格式,它支持的颜色信息只有256种,但是它同时支持透明和动画,而且文件量较小,所以广泛用于网络动画。 3.BMP格式 BMP格式的文件名后缀是:.bmp,它的色彩深度有1位、4位、8位及24位几种格式。BMP格式是应用比较广泛的一种格式,由于采用非压缩格式,所以图像质量较高,但缺点是这种格式的文件占空间比较大,通常只能应用于单机上,不适于网络传输,一般情况下不推荐使用。 4.TIFF格式 简称TIF格式,适用于不同的应用程序及平台,用于存储和图形媒体之间的交换效率很高,并且与硬件无关,是应用最广泛的点阵图格式,是最佳的无损压缩选择之一。TIF格式具有图形格式复杂、存储信息多的特点,它最大的色彩深度为48bit,这种格式适合从

Photoshop中导出图像到其他排版制作软件中。 5.PSD格式 PSD是Photoshop的默认格式,在Photoshop中这种格式的存取速度比其他格式都要快,功能也叫强大。扩展后缀名为.psd,支持Photoshop的所有图像模式,可以存放图层、通道、遮罩等数据,便于使用者反复修改,但是此格式不适用于输出(打印、与其它软件的交换) 7.PNG格式 PNG是新兴的一种网络图像格式,结合了GIF和JPG的优点,具有存储形式丰富的特点,PNG最大的色深为48bit,采用无损压缩方式存储,是Fireworks的默认格式。 二、常用图形文件格式及特点 1.EPS格式 EPS格式是专门为存储矢量图设计的特殊的文件格式,输出的质量很高,能够描述32位色深,分为Photoshop EPS和标准EPS格式两种,主要是用于将图形导入到文档中。这种格式与分辨率没有关系,几乎所有的图像、排版软件都支持EPS格式。 在将EPS图性质入导桌面出版程序后,可能只显示一个灰色的方框或瞻为辅,这部是图形导入不正确,而是DTP程序不能显示而已,正常打印此图形会正常输出。如相在布局中显示出图片,掏出使,选择“位图预览”选项。这时画面中可生成一个低分辨率的预览图,DTP 程序可正常的将其显示出来。

相关文档