浅谈脱壳中的附加数据问题.doc

浅谈脱壳中的附加数据问题（overlay）Author：LenusFrom：E-mail：Lenus_M163.com-1.前言最近，在论坛上看到很多人在弄附加数据overlay的问题，加上上次答应了各位兄弟所以觉得写一些着方面的废话。如果下面的内容对你有帮助那是最好。这篇文章我们将解决以下问题：1.什么是overlay，怎么找到overlay？2.为什么有些壳虽然有overlay但是却不用特别处理？3.为什么有些壳只用粘贴overlay数据就ok了，而有些壳却要定位指针？4.如何修复文件指针？-2.正文一.什么是附加数据（overlay）1.实际当中的overlay其实，overlay虽然大家在脱壳当中觉得很陌生，但是他离我们并不遥远。在我们平时使用的软件当中，有一些软件要处理一些数据流文件，比如winamp。当我们下载了mp3文件（数据文件），没有播放器是不可能播放的，与此相关的还有很多，比如txt文件和notepad的关系也差不多。而这些数据文件被单独的保存在硬盘上，当我们使用notepad的打开功能的时候，就可以去读取数据文件里面的东西了。overlay又是什么意思呢？他其实真正的意思就是取消打开功能，将这些需要读取的数据放到pe文件的后面，让程序自动的运行打开的功能。这样的功能就变成了一个notepad的程序对应只能打开一个文件。最典型的就是一些软件可以把一些数据流文件生成exe文件，比如一些mp3生成器，flash生成器，以及我们用来做动画的S-demo。他们的作用就是将数据对pe进行捆绑。（这样做的结果也就是为什么我们对这些文件用UPX等pe压缩工具却不能压缩他的原因，这是后话了）2.技术上的overlay在我们对pe文件的overlay进行分析之前，我们要普及一下文件映射的知识。在pe里面，有所谓的文件偏移RA，文件偏移大小RS和与其对应的虚拟地址偏移VA，虚拟地址偏移大小VS。我们要深刻的理解以上的概念不是我这篇文章能说清楚的，但又是搞overlay必须得弄清楚的，于是我简单的说明一下。在我们的磁盘上的pe文件里面，排列着的数据在运行的时候将被影射到内存空间。他们将被怎么影射呢？举个例子：例1：一个pe文件中只有两个区段（pehead不算）第一个区段是.textVA=401000VS=1000RA=200RS=100第二个区段是.dataVA=402000VS=1000RA=300RS=100假设我们打开winhex看到在文件偏移300处的情况是这样的：RA=2FF处的数据是12RA=300处的数据是34好了，现在当pe文件装到内存中，那么会出现什么结果呢。1.文件偏移中的200开始的100个字节将被影射到内存的401000开始的100个字节，后面的F000个字节将用0填充。2.文件偏移中的300开始的100个字节将被影射到内存的402000开始的100个字节，后面的F000个字节将用0填充。也就是说，在磁盘是上相邻的两个数据12和34，在内存空间中将分开得老远，12在40102FF处，而34却在402000处。当然这只是我自己随便举的一个极端的例子，实际上由于文件的对齐机制在磁盘上每个段的结束都是填充了大量的0为什么要讲这些呢？因为区段是一般将会被映射到内存的，如果上面的例子中。将.data区段去掉。那么在磁盘上就将会留下从RA=300到RA=400其大小为100的数据，不会被影射到内存中。而这部分数据就将被认为是附加数据-overlay。3.做个实验1.用lordPE的peeditor打开一个notepad2.打开他的senctions看看3.把他的最后一个区段的文件大小RS修改一下（改成F00吧，少影射100的文件）如图此主题相关图片如下：1.要回答这个问题首先就会关系到两个函数CreateFileA和SetFilePointer。对于CreateFileA他是打开文件的函数，当你下断CreateFileA你会发现程序断下的时候，他的第一个参数就是这个pe文件在磁盘上的完全路径，表示他正在对文件打开，将要对他进行文件读写操作。这个函数我就不多说了。下面详细说说SetFilePointerDWORDSetFilePointer(HANDLEhFile,/在用CreateFileA打开后得到的文件句柄LONGlDistanceToMove,/要移动的距离，这个是低32位PLONGlpDistanceToMoveHigh,/要移动的距离，这是高32位，要注意这是一个指向数据的指针DWORDdwMoveMethod/表示指针开始的位置);因为用CreateFileA打开一个文件后，系统会给这个文件维护一个指针，一开始是指向文件的第一个字节的。这个函数的作用是人为的移动这个文件指针。理由很简单，overlay数据不是在文件的第一个字节处。而他的返回值就是移动后的文件的新指针的位置。上面的有两个参数要注意：1.lpDistanceToMoveHigh这个和上面的lDistanceToMove不一样，他是一个指针。指向一个32位的内存地址里面放着高32位的移动距离，他和lDistanceToMove的低32位的距离合起来表示一共要移动的距离（感觉是多此一举，一个32位就可以寻址4G，难道有一个4G的文件！？，而且高32位还设置成指针，难道是怕直接引用还不够？MS真是考虑得长远！）2.dwMoveMethod有3个参数FILE_BEGIN=0表示指针不管当前的位置在什么地方，从第一个字节开始算。FILE_CURRENT=1表示指针继承上面的，最后移动到的位置FILE_END=2表示指针不管当前的位置在什么地方，从最后一个字节开始算。2.为什么dump下来的程序需要定位overlay？dump的意思就是将内存的数据全部存储到磁盘，也就说对于上面的那个例1的例子来说，当我们从磁盘再把他dump下来的时候并不是还是400的大小了，而是3000的大小了！这一点请务必弄清楚。这时在原来文件中在200位置的数据，在dump下来的文件中就在1000处，依次类推可以得到其他的文件位置，这也就是为什么我们在dump下来后需要将RA=VARS=VS的原因，幸亏体贴的lordPE自动的完成了这一个步骤！这时虽然我们把overlay的数据粘贴到脱壳后的程序，但是与原来的文件位置完全变了。导致我们脱壳以后要重新定位文件指针让他读取到正确的数据。3.为什么有些程序粘帖了overlay的数据就ok了？这个东西口说无凭让我们来实战一下吧。就用上次pendan2001兄弟给的做例子吧。:81/files/zmgb2.0.rar在脱完壳以后，修复输入表。发现运行不了。呵呵没有填加附加数据嘛，不然我举这个例子干什么。看他的区段发现他的最后一个区段是8E00开始，大小是1000。所以我们估计他的附加数据是从8E00+1000=9E00开始的地方。用winhex打开未脱壳文件，到9E00处吧。呵呵发现上面有很多0，这就是为什么有些牛人告诉我们找前面是0的原因，其实其本质是因为文件的对齐机制。复制从这里到后面全部的数据到修复好输入表的那个(为什么是要先修复输入表，等下你就知道了)好了，可以运行了。不明白为什么是吗？到程序里面看看吧用od载入，下断bpCreateFileA和bpSetFilePointerF9以后断下了，看堆栈0012FC7000401183/CALL到CreateFileA来自桌面钢笔.0040117D0012FC740012FDA0|FileName=G:downloads桌面钢笔V2.0.exe/开始打开文件了0012FC7880000000|Access=GENERIC_READ0012FC7C00000001|ShareMode=FILE_SHARE_READ0012FC8000000000|pSecurity=NULL0012FC8400000003|Mode=OPEN_EXISTING0012FC8800000080|Attributes=NORMAL0012FC8C00000000hTemplateFile=NULL0012FC900041F2B7桌面钢笔.0041F2B7再运行又断下0012FC7C004011A4/CALL到SetFilePointer来自桌面钢笔.004011A2/移动指针0012FC8000000030|hFile=000000300012FC84FFFFFFF8|OffsetLo=FFFFFFF8(-8.)/负数表示向前移动0012FC8800000000|pOffsetHi=NULL0012FC8C00000002Origin=FILE_END/表示从文件的最后开始算又F9一下0012FC7C00401220/CALL到SetFilePointer来自桌面钢笔.0040121E0012FC8000000030|hFile=000000300012FC84FFF5F738|OffsetLo=FFF5F738(-657608.)0012FC8800000000|pOffsetHi=NULL0012FC8C00000002Origin=FILE_END/又是从文件的最后算起好了，如果你再按一次会发现还是用FILE_END这个参数ok，知道什么了没有？我来解释一下用FILE_END参数表示指针从文件的最后开始移动，而附加数据无论在原来未脱壳的文件中和还是在脱壳的文件中，因为我们复制的是整个overlay区域，他的overlay部分的数据对于最后的一个字节的距离是不变的。他每次都用FILE_END当然我们这样复制就不需要重定位指针了，也就是说即使我们把原来的文件（从0地址开始）全部复制到脱壳后的文件中也是能够运行的，因为他是靠与最后的地址的距离来定位读取数据。换个说法，如果这个时候你把最后一个数据删掉，或者少复制哪怕是一个字节，就不能运行了。这也是我们为什么要先修复输入表的原因。总结：也就是说如果你把附加数据复制到脱壳后的程序发现能够运行，呵呵恭喜你，你碰巧遇到用FILE_END为指针的程序。4.下面我们来看看如果程序不用FILE_END的情况还是以下面这个例子来说说吧/bbs/dispbbs.D=5&ID=1797脱壳我就不说了。打开区段发现这个附加数据的位置在4CA00+13724=60124（一个奇怪的位置）复制以后发现不能运行，看来没这么好命，都是用FILE_END的啊！我们要对比两个程序，所以最好两个都用OD载入，都到停在OEP处。好了下断bpSetFilePointer这个是脱壳以后的程序的，运行以后断下0012FEBC004091AA/CALL到SetFilePointer来自1_.004091A50012FEC000000168|hFile=00000168(window)0012FEC400060124|OffsetLo=60124(393508.)/移动到60124处去0012FEC800000000|pOffsetHi=NULL0012FECC00000000Origin=FILE_BEGIN/从头开始移动再看看未脱壳的，发现是一模一样的。这个60124不就是刚才附加数据开始的地方吗？看来脱壳后的程序不管这么多，还是访问了原来的位置，导致不能运行。好了，知道原因了以后我们就去解决他。关键是参数不对嘛ATL+F9返回看看他是怎么压栈的。004091A0/$51pushecx;/Origin004091A1|.6A00push0;|pOffsetHi=NULL004091A3|.52pushedx;|OffsetLo/这个EDX是关键004091A4|.50pusheax;|hFile004091A5|.E8E2E0FFFFcall;SetFilePointer004091AA.C3retn/到这里F8出来看看是什么地方对EDX赋上60124的。00413780.0FB7C9movzxecx,cx00413783.8B4004moveax,dwordptrds:eax+400413786.E8155AFFFFcall1_.004091A00041378B.C3retn/到这里还是没什么结果，F8继续00493570.A3C87A4A00movdwordptrds:4A7AC8,eax00493575.33C9xorecx,ecx00493577.8B15CC7A4A00movedx,dwordptrds:4A7ACC/哈哈找到你了0049357D.A1C87A4A00moveax,dwordptrds:4A7AC800493582.8B30movesi,dwordptrds:eax00493584.FF560Ccalldwordptrds:esi+C/从这里call进去到SetFilePointer的00493587.E854FEFFFFcall1_.004933E0/到这里原来是4A7ACC这的地址，对他下硬件写入，看看是什么时候写入了这个60124好了hw4a7acc重来，胜利在一步一步接近我们。00493496.A1D07A4A00moveax,dwordptrds:4A7AD0/靠是4A7AD0传给EAX的0049349B.A3CC7A4A00movdwordptrds:4A7ACC,eax/原来是这个EAX传过去的004934A0.EB07jmpshort1_.004934A9/断在这里，望上看再来下HW4A7AD0重来。0049927C|.C705D07A4A0024010movdwordptrds:4A7AD0,60124/小样，还找不到你00499286|.C605B27A4A0001movbyteptrds:4A7AB2,1/断在这里呵呵原来是0049927C这一句好了爆掉就可以了，把他改成你脱壳后的附加数据的开始地址就可以了。总结一下：对于定位指针我们一般是依靠SetFilePointer这个函数来一步一步的寻找定位的问题的突破口，这里各人有个人的方法我就不多说了