写在前面
CVE-2010-2553是wmpalyer的一个堆溢出漏洞，通过对此漏洞的调试，加深对windows下漏洞的理解和熟练调试技巧。遂将调试分析过程记录如下。
一. 调试环境
xp_sp3简体中文版 , windbg ，Windows media player 10.00.00.4063
二. 调试过程
分析崩溃原因
崩溃现场。在一次循环赋值中，抛出了异常
查看rdi和rdi-0x1000地址的属性。异常的原因是非法往不可写地址写入数据
到达崩溃现场
定位发现当前指令在iccvid.dll中。因此接下来的分析就是针对于该dll进行
查看崩溃现场栈回溯，可知出问题函数最终返回地址是0x73b7cbf3，调用问题函数的指令是：0x73b7cbee
问题来了，如果一开始就在0x73b7cbee下断，因为iccvid.dll还未加载，所以这个地址根本没有指令，下不了断点。解决方法：在刚刚附加上进程时，通过”sxe ld:iccvid”命令，设置在iccvid.dll模块首次加载时断下
探究漏洞原理
因为该漏洞是堆溢出，在分析堆溢出漏洞时，肯定是hpa+ust大法好。通过windbg子目录下的gflag.exe对wmplay.exe开启hpa和ust
- hpa：启用页堆，在堆块后增加专门用于检测溢出的栅栏页，若发生溢出会立刻触发异常
- ust：用户态堆回溯，即将每次调用对函数的函数调用信息记录到一个数据库中
用windbg加载wmplayer后，可以用命令”! gflag”查看、增加、删除开启的关于堆调试的选项
在此，我先关闭了hpa。也不知道为什么，开启了hpa后，在iccvid加载时就不能断下，所以我先关闭了hpa，等iccvid模块加载成功断下后，我再打开hpa
通过命令”sxe ld:iccvid”设置模块iccvid.dll一加载就断下
断下后，在0x73b7cbee下断，‘g’
通过IDA分析，该函数有7个参数。此时观察一下该函数参数的值
进入该函数，首先比较该函数的第3个参数0x68和0x20的大小
将函数的第2个参数赋值给esi，然后在把esi指向的地址内容放到各个寄存器
来看一下此时esi指向地址的内容，这是指向poc.avi中cinepak_codec_data1的数据
继续跟，着眼于什么时候崩溃指令0x73b722cc会被执行。发现在崩溃指令前面不远处，有一处很诡异的比较，即拿al中的内容和0x11比较，当al中内容是0x11时，则会执行崩溃指令；当al中内容不是0x11时，就不会执行崩溃指令。因此估计，这是一个判断是否进行memcpy函数的判断条件。
当第一次运行到奔溃指令时，往0a37f000写入数据，而这个地址位于0a37d000—（0a37d000+0x6000）的范围内，此时不会造成崩溃
再一次来到此崩溃指令时，edi的值已经相比上次多了0x2000，因此可以估算当第三次执行此命令时，edi的值就已经到达了堆块的边界，再写入数据就会非法了
那么为什么会一直执行memcpy操作呢？原因就是第7步中的判断条件一直为真，所有会一直执行memcpy函数。对应IDA中的地方看一看，果然如此
我们到poc.avi中去看看对应的结构，正是这几个0x11，能使每次循环判断条件为真，不断对只有0x6000的堆进行每次0x2000的复制，最终导致堆溢出
三. 问题解决
使用IDA查看iccvid.dll文件，找到函数73b7cbee，发现ida并不能识别出函数为CVDecompress函数，纳尼？？这一定是在逗我
这是因为IDA没有找到pdb文件，但是我们windbg却找到了pdb文件，我们将windbg的pdb文件拷贝出来，在windbg中查看pdb文件路径
使用ida file — load file —pdb file选择pdb文件路径，就可以在ida中看到函数名称了
