作者原文:https://security.tencent.com/index.php/blog/msg/15
这个是漏洞战争里面的例子,搜了一下没人写,自己实践过程中没能像作者那样开启htc,开启hpa后一步到达相应位置,而我开启后没能预期那样,所以写下此文
首先exploitdb搜了一下,poc在下面,软件也给了
https://www.exploit-db.com/exploits/21991/
poc也贴上
1 | l = 3315716 * "A" |
环境及工具
xp sp3
quartz.dll 版本:6.5.2600.5596
windbg
调试过程
注:其实调试过程中遇到过很多奇葩的异常,没有一一列出
首先对qq播放器开启堆尾检查
1 | C:\Program Files\Debugging Tools for Windows (x86)>gflags.exe -i qqplayer.exe +htc |
windbg附加运行,打开文件没异常,应该是quartz.dll版本过高了6.5.2600.6333,换个虚拟机
作者是6.5.2600.5596,发现吾爱破解的虚拟机刚好是这个版本
首先再次确认一下gflag
1 | 0:003> !gflag |
what???怎么跟作者的不一样,查看堆栈也没啥,那我尝试关掉htc看看结果如何,gflag为0,发现异常位置也是不一样
1 | (4c4.684): Access violation - code c0000005 (first chance) |
还有一个,那我们只开hpa情况又会怎么样呢,怎么跟作者什么都没开一样
1 | (590.dc4): Access violation - code c0000005 (first chance) |
那时的我有那么几秒钟是崩溃的,很多时候就是那么几秒钟决定了你是继续下去,还是放弃
那我用最原始的办法,看看汇编下面的eax怎么来的,针对开了
1 | 7cf9409c ff5024 call dword ptr [eax+24h] ds:0023:41414165=???????? |
在前面的eax赋值地方下个断点
1 | Breakpoint 0 hit |
可以看到这里esi指向的堆的大小等字段被覆盖成4141了,那是什么时候覆盖的呢
我们在前面esi赋值的地方下断点
1 | .text:7CF94061 lea esi, [edi-0Ch] |
我们发现此时还没被覆盖
1 | Breakpoint 0 hit |
我们此时可以将003f8610 这个地址放到memory窗口,单步查看什么时候被改变了,你会发现是这里是003f8610 那一片变成了4141…..,跟着f11重新跟入使用同样的方法就行了
1 | 7cf9407e ff5020 call dword ptr [eax+20h] ds:0023:7cf78b24={quartz!CTransformInputPin::CheckMediaType (7cf9de49)} |
后来发现这办法太那个了,直接下写入断点就行了,就可以直达了,上面就换乘了
1 | 0:002> ba w1 003f8610 |
我们看看此时的源地址和目的地址,目的堆块的size已经被覆盖成4141了
1 | 0:002> !heap -p -a esi |
我们看看edi的前一个堆的位置(随便找个小于003f8608 ,被4141覆盖的就行了),可以看到本来是003f82a8堆块的数据,最后确实是覆盖到了下一个堆003f8608了,htc也没有检查出来
1 | 0:002> !heap -p -a 003f8570 |
最后说说
之后回到家用自己的电脑又可以了,无语~(但htc还是不行),可能一个细微的差别都会导致调试结果不尽相同,软件版本,系统,还有虚拟机毕竟是虚拟出来的。
1 | (7c0.1a4): Access violation - code c0000005 (first chance) |