[图文]WinRAR 7z压缩包处理溢出分析和利用

   热 荐  ★★★★★

这时候栈的地址是在0x17Dxxxxx的地方，马上重新生成一个压缩包，打开，但出错的地址不在栈中，意味着EIP没有跳转到栈中，如图3：

图3
奇怪,3f是哪来的呢？经过我查资料，Unicode是双字节码，3f表示的是未知字符，文件名的16个字节经过 MultiByteToWideChar函数的转化以后已经变成了下面这个样子\x41\x00\x41\x00\x41\x00\x41\x00\ x12\x00\x45\x00\x3f\x00\x41,看来这个地址是用不了了，poc代码的作者提供的是0x100201BB这个地址，这个地址是在7zxa.dll的.rdata段里，虽然这里面有个0xBB但是由于它处在首尾两端，我们还是可以给它补一个字节，这样就不怕转义了，但是在测试中我发现7z.fmt和7z.dll的加载基址几乎每次都是不一样的，所以这个地址也只能放弃，难道我们真的要放弃?

柳暗花明
我们的跳转地址必须符合三个条件:1.需要能够跳回堆栈 2.四个字节不能出现>0x80的字节 3.或者出现0x80以上的字节不能出现在中间两个位置上。我打开OD的内存，一个个模块搜索过来，黄天不负有心人，在所有加载模块的最高处， Shell32.dll的.text段里面居然让我找到了：0x7D646981，嘿嘿，跳转地址就可以这么构造 0x41000x4100x4100x8A7C 0x69000x64000x7D00,其中是0x8A7C是0x81的Unicode，但这不是完美的解决方案，不是每台机子的0x7D646981都是Jmp esp，但同一个SP下Shell32.dll加载的基址应该是固定的，至于如何实现通用，这个问题还是留给读者吧。Shellcode的定位问题算是暂时告一段落了，紧接着而来的问题就是要有能经得起转换的Shellcode，对了，纯字母数字的Shellcode就是符合这样要求的 Shellcode，经得起MultiByteToWideChar折腾的也就这孩子了。幸亏黑防上期刚刚发表过关于编写纯字母数字的Shellcode 的文章，不然我得多打一个小时的字:)不知大家是否已经有了自己的AlphaNumric的Shellcode了，如果没有的话，我找来了一个生成的模板供大家使用：

这是解码头，根据溢出的时候哪个寄存器指向Shellcode进行选用，生成Shellcode主体的函数配套代码alphashellcode里面有。我们这应该选择TYIIIIIIIIIIIIIIII7QZ这个解码头，Shellcode怪长的我就不贴了，以免有骗稿费之嫌。再次测试，成功，如图 4：

图4

疑云重重
虽然利用是成功了，不过不知道大家有没有发现一些比较奇怪的问题:1.如果是栈溢出，为什么溢出点却在超长字符串的前面，而不是在中间或者后面，不会它的缓冲区只有1个字节吧？ 2.为什么打开的时候不触发漏洞只有解压的时候才触发？ 3.为什么gyzy说这不是严格意义上的栈溢出？（汗..) 带着这一连串的问题，任何言语的猜测都是苍白的，还是让OD去解开我们的疑团。这里顺便发一下牢骚，OD对多线程的处理真是不咋的，经常会莫名其妙的出现假死的现象，先加载WinRAR.exe让OD跑起来，记得先把跳转地址改掉，以免出现没有断下来的尴尬局面，另外还要记得校正CRC值，不然它会郑重的警告你一下，哈哈，祈祷你的机器没有假死吧，阿门，如图5：

图5
我发现原版的OD好像稳定性好一点，所以我用的是原版的，这个时候EIP已经被覆盖了，我在堆栈窗口里往上下都翻了翻，没有翻到正常的返回地址，奇怪了，不可能所有的返回地址都覆盖吧？太狠了，居然一点线索都不给留下，按照常规堆栈回溯下很容易找到出问题的代码，看来事情越发的扑朔迷离了。 Ctrl+F2重新来，F9让他跑起来，然后bp CreateThread,

上一页  [1] [2] [3] 下一页