3.5  数据结构字段详解 3.5.1  PE头IMAGE_NT_HEADER的字段 1.IMAGE_NT_HEADER.Signature +0000h,双字.PE文件标识,被定义为00004550h.也就是"P""E"加上两个0,这也是PE这个称呼的由来.如果更改其中任何一个字节,操作系统就无法把该文件识别为正确的PE文件.通过修改这个字段,会导致PE文件在32位系统中加载失败,但由于这个文件的其他部分(特别是DOS头)还没有被破坏,系统还是可以识别出其为DOS

C语言结构体对齐也是老生常谈的话题了.基本上是面试题的必考题.内容虽然很基础,但一不小心就会弄错.写出一个struct,然后sizeof,你会不会经常对结果感到奇怪?sizeof的结果往往都比你声明的变量总长度要大,这是怎么回事呢? 开始学的时候,也被此类问题困扰很久.其实相关的文章很多,感觉说清楚的不多.结构体到底怎样对齐? 有人给对齐原则做过总结,具体在哪里看到现在已记不起来,这里引用一下前人的经验(在没有#pragma pack宏的情况下): 原则1.数据成员对齐规则:结构(struct或

之前理论性的太多,下面就是代码及理论结合了 1.sizeof()是一个独立运算符,并不是函数,可以让我们知道任何变量字节数,可以顺带学一下struct,union,内存对齐 内存对齐:为了机器指令快速指向地址值,编译器内部实际上会内存对齐,怎么理解了,以struct为例 先讲一下各个变量类型内存大小 所以struct理论上是:1+2+4+4+4+8+8 = 31,但是实际是 实际大小是32(1+2+1+4)+(4+4)+8+8 然后再把int和short位置调换 实际大小是40   (1+3)+

这篇文章写得非常深入浅出.推荐.图需要到原博看. http://songlee24.github.io/2014/09/20/memory-alignment/ 下面是网易的一道笔试题:struct { uint32_t m1; char m2; } varray[2];以下哪些判断一定成立?(多选) sizeof(varray[0]) == 5 sizeof(varray[0]) == 8 (void*)&(varray[0].m1) < (void*)&(varray[0].m2

深入理解 Win32 PE 文件格式 Matt Pietrek 这篇文章假定你熟悉C++和Win32. 概述 理解可移植可执行文件格式(PE)可以更好地了解操作系统.如果你知道DLL和EXE中都有些什么东西,那么你就是一个知识渊博的程序员.这一系列文章的第一部分,讨论最近这几年PE格式所发生的变化. 这次更新后,作者讨论了PE格式如何适应于用.NET开发的应用程序,包括PE节,RVA,数据目录,以及导入函数.附录中包含了相关的映像头结构以及它们的描述. 很早以前,我为微软系统期刊(现在叫做MSD

PE文件是Win32的原生文件格式.每一个Win32可执行文件都遵循PE文件格式.对PE文件格式的了解可以加深你对Win32系统的深入理解. 一. 基本结构. 上图便是PE文件的基本结构.(注意:DOS MZ Header和部分PE header的大小是不变的:DOS stub部分的大小是可变的.) 一个PE文件至少需要两个Section,一个是存放代码,一个存放数据.NT上的PE文件基本上有9个预定义的Section.分别是:.text, .bss, .rdata, .data, .rsrc,

不赖猴的笔记,转载请注明出处. 深入剖析PE文件 PE文件是Win32的原生文件格式.每一个Win32可执行文件都遵循PE文件格式.对PE文件格式的了解可以加深你对Win32系统的深入理解. 一.        基本结构. 上图便是PE文件的基本结构.(注意:DOS MZ Header和部分PE header的大小是不变的:DOS stub部分的大小是可变的.) 一个PE文件至少需要两个Section,一个是存放代码,一个存放数据.NT上的PE文件基本上有9个预定义的Section.分别是:.t

这篇文章假定你熟悉C++和Win32. 概述 理解可移植可执行文件格式(PE)可以更好地了解操作系统.如果你知道DLL和EXE中都有些什么东西,那么你就是一个知识渊博的程序员.这一系列文章的第一部分,讨论最近这几年PE格式所发生的变化. 这次更新后,作者讨论了PE格式如何适应于用.NET开发的应用程序,包括PE节,RVA,数据目录,以及导入函数.附录中包含了相关的映像头结构以及它们的描述. 很早以前,我为微软系统期刊(现在叫做MSDN)写了一篇文章.那篇文章“Peering Inside the

DOS Header(IMAGE_DOS_HEADER)->64 Byte DOS头部 DOS Stub 112字节 "PE"00(Signature) 4个字节 IMAGE_FILE_HEADER  20个字节 PE文件头       IMAGE_OPTIONAL_HEADER32  96个字节 数据目录表         16*8=128个字节 IMAGE_SECTION_HEADER    40个字节 块表              IMAGE_SECTION_HEADER

一.PE文件基本结构 上图便是PE文件的基本结构.(注意:DOS MZ Header和部分PE header的大小是不变的:DOS stub部分的大小是可变的.) 二.Section 详解 一个PE文件至少需要两个Section,一个是存放代码,一个存放数据.NT上的PE文件基本上有9个预定义的Section.分别 是:.text, .bss, .rdata, .data, .rsrc, .edata, .idata, .pdata, 和 .debug.一些PE文件中只需要其中的一部分Secti

在前面几节中经常提到相对虚拟地址RVA,在这篇博客中主要说明这个概念.本来是想接着转载小甲鱼的,但是我自己根据这篇文章和他的视频来学习的时候,发现在RVA与文件的相对偏移地址进行转化的时候,那块我看不懂,不知道为什么要这样转化,而且前面很多东西都反复讲了好多遍,比如对齐的问题,所以,这篇我就自己根据自己掌握的情况来写,还是在此处放上原文的连接: 原文(上)传送门 原文(下)传送门 什么是RVA 某个位置的RVA是该位置在内存中的地址相对于整个文件在内存中首地址的偏移值,举个例子,当PE文件中某个

本文转自小甲鱼的PE文件详解系列传送门 PE文件到内存的映射 在执行一个PE文件的时候,windows 并不在一开始就将整个文件读入内存的,二十采用与内存映射文件类似的机制. 也就是说,windows 装载器在装载的时候仅仅建立好虚拟地址和PE文件之间的映射关系. 当且仅当真正执行到某个内存页中的指令或者访问某一页中的数据时,这个页面才会被从磁盘提交到物理内存,这种机制使文件装入的速度和文件大小没有太大的关系. 但是要注意的是,系统装载可执行文件的方法又不完全等同于内存映射文件. 当使用内存映射

① PE (Portable Executable):微软参考COFF(Common Object File Format)规范,在Windows NT系统上制定的一种标准, 用于exe可执行文件.obj目标文件和dll动态链接库等文件格式.PE32+是PE的64位扩展,其并未添加额外结构,只是把原来32位的字段变成了64位. 与COFF一样,PE也是基于段(Segment,注:有时也被叫节Section)的结构, 按照不同属性将信息分段存放,常见的段有:代码段(.text).数据段(.data

这篇文章转载自小甲鱼的PE文件详解系列原文传送门 之前简单提了一下节表和数据目录表,那么他们有什么区别? 其实这些东西都是人为规定的,一个数据在文件中或者在内存中的位置基本是固定的,通过数据目录表进行索引和通过节表进行索引都是可以找到的,也可以这么说,同一个数据在节表和数据目录表中都有一份索引值,那么这两个表有什么区别?一般将具有相同属性的值放到同一个节区中,这也就是说同一个节区的值只是保护属性相同,但是他们的用途不一定是一样的,但是在同一数据目录表中的数据的作用是相同的,比如输入函数表中只会保

PE文件就是我们常说的EXE可执行文件,针对文件特征的识别可以清晰的知道该程序是使用何种编程语言实现的,前提是要有特征库,PE特征识别有多种形式,第一种是静态识别,此方法就是只针对磁盘中文件的特征码字段进行检测来判断编译器版本,此种方式优点是快,缺点是识别不准确,第二种则是动态识别,当程序被装入内存解码后在尝试对其进行识别,此方法最为准确,我们经常使用的PEID查壳工具是基于静态检测的方法. 打开PE文件映射: 在读取PE结构之前,首先要做的就是打开PE文件到内存,这里打开文件我们使用了Crea

分配粒度和内存页面大小 x86处理器平台的分配粒度是64K,32位CPU的内存页面大小是4K,64位是8K,保留内存地址空间总是要和分配粒度对齐.一个分配粒度里包含16个内存页面. 这是个概念,具体不用自己操心,比如用VirtualAllocEx等函数,给lpAddress参数NULL系统就会自动找一个地方分配你要的内存空间.如果需要自己管理这个就累了...... 一个分配粒度是64K,这就是为什么Null指针区域和64K进入区域都是 64K的原因,刚好就是一个分配粒度.一个内存页是4K,这就是

转自:http://www.cnblogs.com/qwcbeyond/archive/2012/05/08/2490897.html 32位机一般默认4字节对齐(32位机机器字长4字节),64位机一般默认8字节对齐(64位机机器字长8字节) 1．先看下面的例子:struct A{   char c1;   int i;   short s;   int j;}a; struct B{   int i;   int j;     short s;   char c1;}b; 结构A没有遵守字节对

struct内存对齐:gcc与VC的差别 内存对齐是编译器为了便于CPU快速访问而采用的一项技术,对于不同的编译器有不同的处理方法. Win32平台下的微软VC编译器在默认情况下采用如下的对齐规则: 任何基本数据类型T的对齐模数就是T的大小,即sizeof(T).比如对于double类型(8字节),就要求该类型数据的地址总是8的倍数,而char类型数据(1字节)则可以从任何一个地址开始.Linux下的GCC奉行的是另外一套规则:任何2字节大小的数据类型(比如short)的对齐模数是2,而其它所有

同样的代码,在vs下运行正常,在android ndk下却崩溃: signal 7(SIGBUS),code 1 (BUS_ADRALN),fault addr 0xe6b82793 Func(short *pVY[]) { short *dstY[2] = {pVY[0],pVY[1]};//使用backtrace定位,crash在这一句 } pVY[0],pVY[1]是从一个统一分配的buffer偏移得来的. 1.考虑内存对齐的原因 pVY[0],pVY[1]:0xee25ffe0,0xee

zipalign:android中SDK下tools文件夹 用来对资源文件的内存进行对齐优化 手工命令: 优化:zipalign -v 4 source.apk destination.apk 4: 应该是4字节对齐            在android中,资源文件通过内存映射对齐到4字节边界时,访问资源文件的代码才是有效率的 验证是否已经优化对齐: zipalign -c -v 4 app.apk ADT: 使用向导,右击工程属性,选择“Android Tools” > “Export Si

一.字节对齐基本概念 现代计算机中内存空间都是按照byte划分的,从理论上讲似乎对任何类型的变量的访问可以从任何地址开始,但实际情况是在访问特定类型变量的时候经常在特定的内存地址访问,这就需要各种类型数据按照一定的规则在空间上排列,而不是顺序的一个接一个的排放,这就是对齐. 对齐的作用和原因:各个硬件平台对存储空间的处理上有很大的不同.一些平台对某些特定类型的数据只能从某些特定地址开始存取.比如有些架构的CPU在访问一个没有进行对齐的变量的时候会发生错误,那么在这种架构下编程必须保证字节对齐.其