按照吴石的说法，维护团队的更替导致近期IE漏洞汹涌流出。以往一个IE漏洞提交给Microsoft以后，其维护团队会构造类似的模板对所有类fuzzing一遍，试图挖掘所有此模式的漏洞并修复。由于人员变动，fuzzing工作被搁置了，民间个体抓住机会，依据一个漏洞构造模板找到大量同类漏洞。

手头拿到几个IE 0day要分析，看看是不是有利用的可能。虽然接触听闻很多年，真正深入的分析UAF还算是初出茅庐。调试工具方面，Immunity Debugger还是歇歇吧，微软主场必须Windbg，何况mona也支持它。为了简化配置，以及酷炫背景的需求，下载一个主题是非常有必要的。当然Windbg本身并不支持主题的导入，只能导入注册表文件来达到酷炫黑的目的，详情可参考这里。

堆出现的问题，无论是Heap Overflow 还是 Use After Free，开启hpa和ust总是好的：

gflags -i iexplore.exe +hpa +ust

其次，IE的多进程和ASLR也很麻烦，关闭之：

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory Management]
"MoveImages"=dword:00000000

[HKEY_CURRENT_USERSoftwareMicrosoftInternet ExplorerMain]
"TabProcGrowth"=dword:00000000

崩溃时（由于分页堆的作用，指针会指向未分配的内存，或者说是已经释放的内存），此时

!heap -p -a address

可以查看该内存对应的堆释放或申请的记录。假设，该内存释放由exeCommand导致，且释放前调用了MSHTML!CTreeNode::Release。为了清晰记录内存的变化，可以增加如下断点：

bu MSHTML!CDocument::execCommand ".printf "execCommand: %mu",poi(esp+8);.echo;g"
bu MSHTML!CTreeNode::Release ".printf "CTreeNode::Release";.echo; bu kernel32!HeapFree ".printf \"Freeblock: 0x%08x\",poi(esp+c);.echo;bc 2;g" ;g"

这样根据输出信息，可以判断目标内存是由哪个execCommand导致的释放，在我手头的几个例子导致了释放和使用都是同一句话，无法利用