一、工具及壳介绍
- 使用工具：Ollydbg、PEID、ImportREC、LoadPE、010 Editor
- 查看待脱壳程序
- 查看AsPack壳特有的区段信息
- 小结：根据链接器版本推断待脱壳程序应该是VS 2013编写
二、脱壳
1、ESP定律脱壳
- 使用OD加载程序，发现pushad指令，判断程序已加壳，这里可以采用ESP定律脱壳
- 单步过pushad处指令后，在esp处下硬件断点
- 让程序运行起来，程序中断的地方即为popad的地方，单步几次之后，一般就能找到原始OEP
- 单步几次后发现CALL和JMP组合
- 使用回车进入CALL后发现VS 2013 程序特有的几个函数，确认到达OEP处
-
查看此时模块基址（exe的基址）
注意：本次为11000000（每次重启系统有可能不相同）
-
在原始OEP处dump文件，使用OD插件OllyDump
修改起始地址为基址，入口地址为原始OEP地址并取消重建输入表选项
- 转储文件后，使用导入表修复工具（ImportREC）对导入表进行修复
-
转储文件后运行脱壳程序
发现程序无法运行，并且导入表修复没有问题，那基本可以确定是随机基址的问题
- 使用010 Editor找到特征（40 81）修改随即机制的标记位，在运行程序
2、单步跟踪脱壳
- AsPack加壳之后的OEP处就存在花指令
- 1117007处的代码第一个字节永远不会执行的指令，将其填充成nop指令可去除干扰
- 重新加载待脱壳程序，当我们单步跟踪时，遇到的函数时GetModuleHandleA，而且我们发现参数是kernel32.dll，调用此函数获取的信息时kernel32.dll的基地址
- 有了kernel32的基地址之后就可以获取这个模块的其他任意函数，接下来调用的应该是GetProcAddress
- 继续单步跟踪，发现第三个函数调用
- 在这里VirtualAlloc函数的出现，一般与解压解密代码有一定的关联，继续跟踪
- 发现又有一个VirtualAlloc函数的调用，继续跟踪分析。发现一个函数调用，查看内部调用发现很繁琐，只能分析一下参数，分析之后发现这个函数大有文章。
- 分析参数发现4个参数与我们想要找的解压代码函数很相似，有申请的内存地址，有代码段的大小（代码段大小的识别第一看数值大小，第二看调用完之后的情况，由于之前已经分析过，所以代码段大小非常容易确定），单步不过这个函数，分析缓冲区，发现190000中果然是解压的代码
- 这个函数暂时不需要往里面跟踪，继续单步往下分析。能够看到有一段代码在寻找E8或E9，然后修复E8或E9后面的值，也就是说整个代码段CALL和JMP都将会被修复
- 观察修复后的值和未修复的值，发现修复后的值是原先的代码，而未修复的值是经过转换的，这个值看起来是为了迎合压缩算法而进行的转换，分析到这，不需要在深入进行分析，总结一下，到目前为止我们分析的代码中最有价值的就是代码进行了解压，对代码进行了修正
- 经过修正代码的循环，继续往下跟踪，可以发现将解压的代码拷贝到原始代码段的代码。
- 拷贝完之后，申请的内存就没有用了，所以单步跟踪发现释放内存的函数
- 继续单步跟踪，发现一个向上的跳转
- 单步一下这段代码发现原来是在循环解压代码、数据等各区段
- 继续跟踪，代码访问了重定位的区段，分析之后发现是在重定位代码
- 其中有一行代码时清除重定位信息的，正是有了这行代码，我们脱壳之后，随机基址才无法支持，所以在脱壳时，应该将这行代码nop掉。
- 重定位代码之后，继续单步跟踪分析，发现有这样的一组调用。
- 修复IAT的时候才会有这样一组操作，继续往下分析
- 找到了填充IAT的地方，到此为止shell部分的代码基本上分析的差不多了，我们可以查看一下代码段及数据段。
- 代码段已经恢复
- IAT函数调用也都恢复
- 接着继续跟踪，最后就是修改各区段的内存属性，填充原始OEP地址，跳转到原始OEP
- 最终跳转到原始OEP处，然后进行dump，修改等操作就可以了
3、基址重定位的修复
- 在单步跟踪时我们注意到了有重定位相关的代码，并发现有对重定位表清除的操作
- 我们能识别出内存中重定位表的信息，只要大片以3开头的word数据，一般都是基址重定位信息，基址的RVA是16000
- 在清除重定位信息的地方下断点，观察寄存器的值和寄存器指向的内容
- 可以看出是在清除重定位表中的数据，确定之后可以将其nop掉
- 之后需要分析出基址重定位的总大小，查看内存之后发现最大应该是0xC72
- 总结一下，基址重定位表的RVA是16000，大小是0xC72，将dump出的程序，使用LoadPE对数据目录表中基址重定位项进行修改
- 完成修改，进行测试运行，程序完美支持随机基址
6450
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
