调试UPX压缩的notepad

@date: 2016/11/29

@author: dlive

0x01 运行时压缩

对比upx压缩前后的notepad可以看到如下特点

PE头的大小一样
节区名称改变（.text -> .UPX0, .data -> .UPX1）
第一个节区的SizeOfRawData=0,即第一个节区在磁盘上的大小为0，但是第一个节区的VirtualSize的值被设置为0x10000
notepad_upx.exe的EP位于第二个节区，原notepad.exe的EP在第一个节区
资源节区(.rsrc)的大小几乎无变化

解压缩代码与压缩的源代码都在第二个节区(UPX1)。文件运行时首先执行解压缩代码，把处于压缩状态的源代码解压到第一个节区(UPX0)。解压结束后即运行源文件的EP代码。

0x02 调试UPX压缩的notepad

EP与OEP：

EP(Enter Point): Windows可执行文件的代码入口点，是执行应用程序时最先执行的代码的其实位置

OEP(Original Enter Point): 对于加壳程序，称源文件的EP为OEP

使用OD打开未加壳的notepad.exe

可以看到notepad.exe的EP为0100739D，入口处代码调用了GetModuleHandleA用来获取notepad的ImageBase

下面开始调试notepad_upx.exe，upx的解壳过程可以分为以下几个阶段：

1. 壳入口的初始化操作

用OD打开notepad_upx.exe，程序停在EP处

复习一下前面PE的知识XD : 可以验证EP地址为01015330 == Address of Entry Point + Image Base （IMAGE_OPTIONAL_HEADER32）

notepad_upx.exe在入口点进行了pushad操作(依次将EAX、ECX、EDX、EBX、ESI、EDI压栈)

然后将UPX0，UPX1节区的地址分别保存在EDI,ESI寄存器中。调试时这样同时设置EDI,ESI，就能预见从ESI所指缓冲区到EDI所指缓冲区的内存发生了复制，此时从Source(ESI)读取数据，解压缩后保存到Destination(EDI)。

之后代码通过jmp调到解压缩代码。

我们的目标是跟踪全部UPX EP代码，并最终找到原notepad的EP代码，如第一张图所示

2. 代码还原

在UPX解压缩的过程中一共有4个循环。

前里两个循环完成代码还原的功能，正式的解码循环为第二个循环。

跟踪数量庞大的代码时，请遵循如下法则：遇到循环时，先了解作用再跳出

在OD中Ctrl+F8调试第二个解码循环，同时在memory窗口观察UPX0节区的数据变化（也可以在OD CPU窗口左下方的数据窗口查看UPX0内数据变化），可以看到第二个循环将解码后的数据写入UPX0节区。

3. CALL/JMP修复

第三个循环从0101540A开始，主要用于恢复源代码的CALL/JMP指令（Opcode：E8/E9）的destination地址。

可以在memory窗口中选中UPX0区段，右键设置内存写入断点来判断第三个循环确实有对UPX0进行修改。

4. 恢复IAT

UPX压缩原notepad.exe事，会分析其IAT，提取出程序中调用的API名称列表，形成API名称字符串。

用这些API名称字符串调用GetProcAddress函数，获取API的地址。然后把API地址输入原notepad.exe的IAT区域。

最终恢复原notepad.exe的IAT

5. 将程序的控制返回到程序OEP

在notepad.exe全部解压缩完成后，将程序的控制返回到OEP处。

010154AD地址处的popad指令与notepad_upx.exe的第一条指令pushad对应，用来把寄存器状态恢复。

最终使用010154BB处的jmp指令跳转到OEP，跳转的目标地址(0100739D)就是notepad.exe的EP

可以看到OEP处的代码和源notepad.exe相同

虽然没有详细看懂upx的每条指令的含义，但是对其代码片段的功能有了基本了解

UPX详细分析可参考：

http://www.52pojie.cn/thread-294773-1-1.html

http://www.chinapyg.com/thread-76768-1-1.html

0x03 快速查找UPX OEP&UPX脱壳

1.快速查找OEP

这里用到了OD的硬件断点，关于硬件断点可以参考:

https://www.zhihu.com/question/52625624/answer/131557817

notepad_upx.exe的EP先执行了pushad，在解压完成后又使用popad恢复程序初始运行时的寄存器和堆栈状态。

我们现在知道UPX在解压完成后一定会执行popad（依次pop edi, esi, ebx, edx,ecx, eax），那么就可以在栈地址上设置硬件断点，在程序访问这个地址的数据时就会被断下。

在数据窗口找到执行完pushad后在esp对应地址，然后选择该地址开始的1字节，右键设置硬件断点（或者按书p133那样设置硬件断点均可）。

当程序执行popad时会首先从这个地址上读取数据到edi(pop edi)，此时会触发硬件断点，程序断下。其下方即是跳转到OEP的JMP指令。

不过和软件断点(INT 3)断点不同的是，触发断点的指令执行（popad）完成后程序才会停止运行，即程序会断在popad下一条指令。

OD的硬件断点可以在调试->硬件断点里看到。

2.UPX脱壳

继续运行程序到OEP，然后再OD中右键选择Dump debugged process（52pojie OD中为“用Ollydump脱壳调试进程”）

修改EP为OEP（该功能会自动修改EP为EIP，此时EIP即为OEP，所以无需手动修改），点击脱壳，另存脚本为notepad_dump.exe

对UPX脱壳而言，进行到这一步就可以了，但是如果是另外一些壳，可能还需要对程序的输入表进行修复操作。

脱壳后的程序可以正常运行，并且使用IDA可以正常反编译。

使用PEID查壳可以看到提示“Microsoft Visual C++ 6.0”信息，而非UPX

3.修复IAT

（为什么要修复IAT，IAT是什么原因被破坏这个我还不是很清楚，不过先有个大致概念，以后再深入研究）

打开ImportREC程序，首先在进程列表中选择正在用OD调试的那个notepad_upx.exe进程，然后在OEP中填入739D，然后点击“IAT AutoSearch”按钮，接着点击“GetImports”按钮，就可以看到程序的输入表信息了。

点击右侧的“Show Invalid”按钮，看看是否存在无效的输入表项目。无效的输入表项目前面带有问号（？），如果有可以使用右键菜单删除。这里没有无效的输入表项目，所以选择“Fix Dump”按钮，对我们的notepad_dump.exe进行修复，得到notepad_dumped_.exe程序。

至此脱壳完成。