此漏洞是由于 Ministream 处理文件时，对文件内容没有进行严格的检查，在 MiniStream 主程序中读取程序，之后进入 MSRMfilter03.dll 这个动态链接库中调用 Playlist_FindNextItem 函数处理文件内容，导致了畸形字符串覆盖缓冲区，在函数结束返回时，由于 esp 被覆盖，导致程序可控。是一个典型的缓冲区溢出漏洞，下面对此漏洞进行详细分析。
首先，在样本构造时，filepath 变量需要注意一下。
这个变量地址不能变，这是程序既定读取内容，需要根据文件路径来规定这个路径，如果想复现这个漏洞的话，这个地址如果系统里没有，可以在 C 盘下创建一个目录。
样本根据这个路径生成完毕后，用 MiniStream 打开，程序崩溃，到达漏洞触发位置。
这里我们通过 kb 回溯堆栈调用，发现堆栈已经被破坏了，好像大多数栈溢出都会碰到这样的情况。
这种情况下我们采用 od 的方法，加载所有模块间调用，根据文件打开操作，寻找一些敏感调用下全局断点来找到漏洞触发前的一个点，根据这种情况，在 od 中找到了一个 fopen 函数调用。
重新加载程序，打开样本，程序中断。
可以看到此时却是是对样本文件的打开操作，再次运行样本，直接到达漏洞现场，那么此处调用应该是漏洞触发前的唯一一次调用，我们就由此入手来分析漏洞形成的原因。
漏洞分析 首先在 fopen 之后，有一处 fread 操作，我们通过 ida pro 来看看 fread 附近的代码。
可以看到，ecx 寄存器作为 DstBuf，地址中用于保存读取到的文件内容。接下来用 windbg 跟踪一下这处 call 调用。
主要看一下 ecx 的值，在 call 调用时，ecx 的值为 000ff748，这处地址是 DstBuf，用于保存文件内容，执行后，我们来看一下这个地址中的值。
可以看到，已经读取到了畸形字符串，接下来还有几处 fseek 和 ftell 操作，大概就是获取文件长度之类的，接下来继续单步跟踪。
在 0041d52b 地址处的 call 调用后，程序到达漏洞现场，那么 sub_41fae0 这个函数很有可能是漏洞出发的关键函数，我们要详细分析一下这个函数的内容。
进入函数之后，继续单步步过，发现这个函数直接可以运行到返回位置，在返回位置，发现了问题。
在返回位置，esp 的地址出现了问题，我们来看一下。
果然，此时 esp 的值被 41414141 覆盖了，也就是说，当 ret 4 执行时，程序会跳转到 esp 地址存放的值的地址，也就是 41414141，也就是我们可控的位置了。
那么也就是说，在这个函数执行的过程中，某处会导致 esp 的值被覆盖，要注意一下 ret 4 执行前，会执行 add esp,8918h ，esp 的值会加上 8918，那么我们在函数入口观察一下这个值。
可以看到，入口处 esp+8918 的值还是正常值，也就是说函数中的某处会将这个值覆盖，接下来我们继续单步跟踪，要找到覆盖的位置。
在 0041fc20 地址，执行了一处 call 操作，这处 call 操作后，esp+8918 的值改变了，关注一下这处 call 调用。 这是调用了程序的一个动态链接库 MSRMfilter03.dll 中的 PlayList_FindNextItem 函数。
注意观察 v1 变量，v1 变量赋值后，会进行一次 if 判断，之后会进入 if 条件判断中，执行一次strcpy 操作，将 v1 的值交给变量 a1，这里非常关键，也是漏洞触发的关键位置。 首先我们先观察 v1 变量调用 sub_10006850 函数。
这个函数的两个参数分别是 eax 和 1，所以进入前，我们观察一下 eax 寄存器。
果然这个 eax 寄存器此时已经是畸形字符串了，而这处执行完之后，会进入一处条件判断跳转，判断的内容正是执行完 call 函数后 eax 的值。 也就是说之前伪代码中的 v1，此时会是 eax 中存放的值。而我们来看一下 eax 之后的去处。
10008D6C 处，eax 值会交给 edi，之后 edi 会减去 ecx，之后 edi 值交给 esi，之后再10008D93 会执行一处 esi 地址存放的值交给 edi 的操作，其实这就是 strcpy，那么我们来看一下这里。
可以看到 strcpy 之后，esp 的值被覆盖了，当函数返回，即可到达用户可控的地址，执行恶意代码。
本文为网络安全技术研究记录，文中技术研究环境为本地搭建或经过目标主体授权测试研究，内容已去除关键敏感信息和代码，以防止被恶意利用。文章内提及的漏洞均已修复，在挖掘、提交相关漏洞的过程中，应严格遵守相关法律法规。