在IE漏洞中，UAF是广为存在的，所以这一次想调试学习一下这类型的漏洞，也熟悉了解一些IE的机制。如有错误或意见，还请斧正和提出，感激不尽。

在Windbg单步执行完该函数，查看CCollectionCache对象

第一次断在tan语句时，查看CCollectionCache对象（05b7dfd0即为上文中esi的值）

可以看到其保留的数组大小为0x0d,先来查看Index 0

接着需要重点关注Index 8中对应元素CElementAryCacheItem中的内容：

可以看到其ArraySize为4，

对应着我们在PoC中定义的对象。

接着我们在开始提到的，在第一次执行crash函数时，会创建一个具有"test"id属性的对象所组成的数组，数组会保存在Index e处。在执行之前，我们先来看看那里现在的情况。(在两个tan语句中间获取input对象时，CCollectionCache结构体中Item数组大小及首地址均变化，因重复打开后地址随机化，故此处0720dfd对应着之前CCollectionCache对象的地址)

（当执行getElementsByTagName语句且在CImplPtrAry::Copy断下时，可以自己试试找找准备拷贝的id为input的对象数组，此处略）

在执行tan与sin之间的crash函数时，代码在BuildNamedArray函数之后断在CImplPtrAry::Copy处，在Index e处新建了一个CElementAryCacheItem待赋值。

sin与cos之间，语句testfailed.innnerHTML=testfailed.innnerHTML会使得当前页面中所有标签在内存中的对象被销毁，并依次重新创建相关类型的对象。所以当执行过该语句后，CollectionsCacheItem数组Index E位置上的NewCacheItem中保存的已经是被释放了的对象的内存地址。

当PoC中第二次调用crash函数时，会使用GetDispID查询对应的元素是否需要重建。在IDA中可以得到GetDispID的堆栈调用：

CCollectionCache::GetDispID

    CCollectionCache::EnsureAry

    CCollectionCache::GetIntoAry

        CCollectionCache::GetAtomFromName

http://zenhumany.blog.163.com/blog/static/1718066332013926101149471/中提到“在CCollectionCache::EnsureAry中会对查询的CatchItem是否有效进行验证，验证的方法是（见下图）：

其当前的版本lCurrentVersion和它引用的原始的CacheItem的版本是否一致，如果不一致，需要根据原始版本重新构建给定的CacheItem。”

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)