在这上面下断，因为很明显解压文件的时候需要新开线程，会发现0049CDFC这个地址是新开线程的起始地址，然后一部部往下跟（省略N多步骤，要是都写出来有点感觉自己像是写长篇小说了），跟进到这个地方：
0045BD63 |. E8 7466FBFF |CALL WinRAR.004123DC
0045BD68 |. 84C0 |TEST AL,AL
0045BD6A |. 74 04 |JE SHORT WinRAR.0045BD70
0045BD6C |. B0 01 |MOV AL,1
0045BD6E |. EB 0F |JMP SHORT WinRAR.0045BD7F
0045BD70 |> 43 |INC EBX
0045BD71 |> 3B9F 04040000 CMP EBX,DWORD PTR DS:[EDI+404]
0045BD77 |.^0F8C 41FFFFFF \JL WinRAR.0045BCBE
0045BD7D |. 33C0 XOR EAX,EAX
0045BD7F |> 5F POP EDI
0045BD80 |. 5E POP ESI
0045BD81 |. 5B POP EBX
0045BD82 |. 8BE5 MOV ESP,EBP
0045BD84 |. 5D POP EBP
0045BD85 \. C2 0800 RETN 8
返回的时候EIP被覆盖了，RETN 8指令说明在返回地址后面要有8个字节的保留空间，再跟Shellcode，我们在0045BD80下断，如图6：
图6
霍然开朗
但这时的ESP却还是01DCF80C，怎么后来就跳到了017D6578了呢，答案就在下面0045B082的 MOV ESP,EBP而EBP恰恰是017D6578，这就解释了刚才的种种疑问，为什么异常发生的时候栈里回溯不到调用信息，为什么溢出点会出现在字符串的前几个字节了。答案就是EBP的值被污染了。重复上面的若干步骤，在01DCF8E8上下写入硬断，里面保存着被覆盖前的的EBP，下面这段代码覆盖了栈里的正确EBP值：
00494AD8 |. 57 PUSH EDI
00494AD9 |. 8B7D 08 MOV EDI,DWORD PTR SS:[EBP+8]
00494ADC |. 8BC7 MOV EAX,EDI
00494ADE |. 8B75 0C MOV ESI,DWORD PTR SS:[EBP+C]
00494AE1 |. 8B4D 10 MOV ECX,DWORD PTR SS:[EBP+10]
00494AE4 |. 8BD1 MOV EDX,ECX
00494AE6 |. D1E9 SHR ECX,1
00494AE8 |. D1E9 SHR ECX,1
00494AEA |. FC CLD ecx 203
00494AEB |. F3:A5 REP MOVS DWORD PTR ES:[EDI],DWORD PTR DS:[ESI]
00494AED |. 8BCA MOV ECX,EDX
00494AEF |. 83E1 03 AND ECX,3 2
00494AF2 |. F3:A4 REP MOVS BYTE PTR ES:[EDI],BYTE PTR DS:[ESI]
00494AF4 |. 5F POP EDI
省略N多步骤，最后发现是00412562这里的指令将EBP值污染了，然后返回到0045BD82的时候间接覆盖了ESP。
00412562 |. 5D POP EBP
跟踪到这的时候也觉得有点意思，很难说这是个标准的覆盖返回地址或者SEH链的栈溢出，但是这儿确实间接的覆盖了返回地址。最近一年来，各种第三方软件的文件处理漏洞逐渐多了起来，个人觉得像这一类的漏洞基本只能靠黑盒测试发现，代码审计也许都很难发现。这次那个作者能发现也算运气，也许短一点的文件名根本就触发不了这么隐秘的Bug了。而且确实不太好利用，溢出点靠后点还能伪装一个诱人点的文件名呢，唉....但是供大家练练手还是不错的，牵涉到很多方面的东西。
上一页 [1] [2] [3]
[图文]WinRAR 7z压缩包处理溢出分析和利用
您现在的位置：