v8 是一种 JS 引擎的实现，它由Google开发，使用C++编写。

v8 被设计用于提高网页浏览器内部 JavaScript 代码执行的性能。为了提高性能，v8 将会把 JS 代码转换为更高效的机器码，而非传统的使用解释器执行。因此 v8 引入了 JIT (Just-In-Time) 机制，该机制将会在运行时动态编译 JS 代码为机器码，以提高运行速度。

TurboFan是 v8 的优化编译器之一，它使用了 sea of nodes 这个编译器概念。

sea of nodes 不是单纯的指某个图的结点，它是一种特殊中间表示的图。

它的表示形式与一般的CFG/DFG不同，其具体内容请查阅上面的连接。

TurboFan的相关源码位于v8/compiler文件夹下。

这是笔者初次学习v8 turboFan所写下的笔记，内容包括但不限于turboFan运行参数的使用、部分OptimizationPhases的工作机理，以及拿来练手的GoogleCTF 2018(Final) Just-In-Time题题解。

该笔记基于 Introduction to TurboFan 并适当拓宽了一部分内容。如果在阅读文章时发现错误或者存在不足之处，欢迎各位师傅斧正！

这里的环境搭建较为简单，首先搭配一个 v8 环境（必须，没有 v8 环境要怎么研究 v8， 2333）。这里使用的版本号是7.0.276.3。

如何搭配v8环境？请移步 下拉&编译 chromium&v8 代码

这里需要补充一下，v8 的 gn args中必须加一个v8_untrusted_code_mitigations = false的标志，即最后使用的gn args如下：

具体原因将在下面讲解CheckBounds结点优化时提到。

然后安装一下 v8 的turbolizer，turbolizer将用于调试 v8 TurboFan中sea of nodes图的工具。

构建turbolizer时可能会报一些TypeScript的语法错误ERROR，这些ERROR无伤大雅，不影响turbolizer的功能使用。

turbolizer 的使用方式如下：

首先编写一段测试函数

一定要在执行%OptimizeFunctionOnNextCall(opt_me)之前调用一次目标函数，否则生成的graph将会因为没有type feedback而导致完全不一样的结果。

需要注意的是type feedback有点玄学，在执行OptimizeFunctionOnNextCall前，如果目标函数内部存在一些边界操作（例如多次使用超过Number.MAX_SAFE_INTEGER大小的整数等），那么调用目标函数的方式可能会影响turboFan的功能，包括但不限于传入参数的不同、调用目标函数次数的不同等等等等。

因此在执行%OptimizeFunctionOnNextCall前，目标函数的调用方式，必须自己把握，手动确认调用几次，传入什么参数会优化出特定的效果。

若想优化一个函数，除了可以使用%OptimizeFunctionOnNextCall以外，还可以多次执行该函数（次数要大，建议上for循环）来触发优化。

然后使用 d8 执行，不过需要加上--trace-turbo参数。

之后本地就会生成turbo.cfg和turbo-xxx-xx.json文件。

使用浏览器打开127.0.0.1:8000（注意之前在turbolizer文件夹下启动了http服务）

然后点击右上角的3号按钮，在文件选择窗口中选择刚刚生成的turbo-xxx-xx.json文件，之后就会显示以下信息：

不过这里的结点只显示了控制结点，如果需要显示全部结点，则先点击一下上方的2号按钮，将结点全部展开，之后再点击1号按钮，重新排列：

我们可以使用 --trace-opt参数来追踪函数的优化信息。以下是函数opt_me被turboFan优化时所生成的信息。

上面输出中的manually marking即我们在代码中手动设置的%OptimizeFunctionOnNextCall。

我们可以使用 v8 本地语法来查看优化前和优化后的机器码（使用%DisassembleFunction本地语法）

输出信息过长，这里只截取一部分输出。

可以看到，所生成的代码长度从原先的995，优化为212，大幅度优化了代码。

需要注意的是，即便不使用%OptimizeFunctionOnNextCall，将opt_me函数重复执行一定次数，一样可以触发TurboFan的优化。

细心的小伙伴应该可以在上面环境搭建的图中看到deoptimize反优化。为什么需要反优化？这就涉及到turboFan的优化机制。以下面这个js代码为例（注意：没有使用%OptimizeFunctionOnNextCall）

跟踪一下该代码的opt以及deopt：

以下是获取优化理由的的v8代码。如果该JS函数可被优化，则将在外部的v8函数中，mark该JS函数为待优化的。

但接下来就开始deopt move函数了，原因是Insufficient type feedback for construct，目标代码是move(new Wall())中的new Wall()。

这是因为turboFan的代码优化基于推测，即speculative optimizations。当我们多次执行move(new Player())时，turboFan会猜测move函数的参数总是Player对象，因此将move函数优化为更适合Player对象执行的代码，这样使得Player对象使用move函数时速度将会很快。

这种猜想机制需要一种反馈来动态修改猜想，那么这种反馈就是 type feedback，Ignition instructions将利用 type feedback来帮助TurboFan的speculative optimizations。

v8源码中，JSFunction类中存在一个类型为FeedbackVector的成员变量，该FeedbackVector将在JS函数被编译后启用。

因此一旦传入的参数不再是Player类型，即刚刚所说的Wall类型，那么将会使得猜想不成立，因此立即反优化，即销毁一部分的ignition bytecode并重新生成。

需要注意的是，反优化机制(deoptimization)有着巨大的性能成本，应尽量避免反优化的产生。

下一个deopt的原因为wrong map。这里的map可以暂时理解为类型。与上一条deopt的原因类似，所生成的move优化函数只是针对于Player对象，因此一旦传入一个Wall对象，那么传入的类型就与函数中的类型不匹配，所以只能开始反优化。

如果我们在代码中来回使用Player对象和Wall对象，那么TurboFan也会综合考虑，并相应的再次优化代码。

turboFan的代码优化有多条执行流，其中最常见到的是下面这条：

从Runtime_CompileOptimized_Concurrent函数开始，设置并行编译&优化 特定的JS函数

在Compiler::CompileOptimized函数中，继续执行GetOptimizedCode函数，并将可能生成的优化代码传递给JSFunction对象。

GetOptimizedCode的函数代码如下：

函数代码有点长，这里总结一下所做的操作：

如果之前该函数被mark为待优化的，则取消该mark（回想一下--trace-opt的输出）

如果debugger需要hook该函数，或者在该函数上下了断点，则不优化该函数，直接返回。

如果之前已经优化过该函数（存在OptimizedCodeCache），则直接返回之前优化后的代码。

重置当前函数的profiler ticks，使得该函数不再hot，这样做的目的是使当前函数不被重复优化。

如果设置了一些禁止优化的参数（例如%NeverOptimizeFunction，或者设置了turbo_filter），则取消当前函数的优化。

以上步骤完成后则开始优化代码，优化代码也有两种不同的方式，分别是并行优化和非并行优化。在大多数情况下执行的都是并行优化，因为速度更快。

并行优化会先执行GetOptimizedCodeLater函数，在该函数中判断一些异常条件，例如任务队列已满或者内存占用过高。如果没有异常条件，则执行OptimizedCompilationJob::PrepareJob函数，并继续在更深层次的调用PipelineImpl::CreateGraph来建图。

如果GetOptimizedCodeLater函数工作正常，则将会把优化任务Job放入任务队列中。任务队列将安排另一个线程执行优化操作。

另一个线程的栈帧如下，该线程将执行Job->ExecuteJob并在更深层次调用PipelineImpl::OptimizeGraph来优化之前建立的图结构：

当另一个线程在优化代码时，主线程可以继续执行其他任务：

综上我们可以得知，JIT最终的优化位于PipelineImpl类中，包括建图以及优化图等

与LLVM IR的各种Pass类似，turboFan中使用各类phases进行建图、搜集信息以及简化图。

以下是PipelineImpl::CreateGraph函数源码，其中使用了大量的Phase。这些Phase有些用于建图，有些用于优化（在建图时也会执行一部分简单的优化），还有些为接下来的优化做准备：

PipelineImpl::OptimizeGraph函数代码如下，该函数将会对所建立的图进行优化：

由于上面两个函数涉及到的Phase众多，这里请各位自行阅读源码来了解各个Phase的具体功能。

接下来我们只介绍几个比较重要的Phases：GraphBuilderPhase、TyperPhase和SimplifiedLoweringPhase。

GraphBuilderPhase将遍历字节码，并建一个初始的图，这个图将用于接下来Phase的处理，包括但不限于各种代码优化。

一个简单的例子

TyperPhase将会遍历整个图的所有结点，并给每个结点设置一个Type属性，该操作将在建图完成后被执行

给每个结点设置Type的操作是不是极其类似于编译原理中的语义分析呢？ XD

其中，具体执行的是TyperPhase::Run函数：

在该函数中继续调用Typer::Run函数，并在GraphReducer::ReduceGraph函数中最终调用到Typer::Visitor::Reduce函数：

在Typer::Visitor::Reduce函数中存在一个较大的switch结构，通过该switch结构，当Visitor遍历每个node时，即可最终调用到对应的XXXTyper函数。

例如，对于一个JSCall结点，将在TyperPhase中最终调用到Typer::Visitor::JSCallTyper

这里我们简单看一下JSCallTyper函数源码，该函数中存在一个很大的switch结构，该结构将设置每个Builtin函数结点的Type属性，即函数的返回值类型。

而对于一个常数NumberConstant类型，TyperPhase也会打上一个对应的类型

而在Type::NewConstant函数中，我们会发现一个神奇的设计：

对于JS代码中的一个NumberConstant，实际上设置的Type是一个Range，只不过这个Range的首尾范围均是该数，例如NumberConstant(3) => Range(3, 3, zone)

以下这张图可以证明TyperPhase正如预期那样执行：

与之相应的，v8采用了SSA。因此对于一个Phi结点，它将设置该节点的Type为几个可能值的Range的并集。

请看以下示例：

SimplifiedLoweringPhase会遍历结点做一些处理，同时也会对图做一些优化操作。

这里我们只关注该Phase优化CheckBound的细节，因为CheckBound通常是用于判断 JS数组（例如ArrayBuffer） 是否越界使用 所设置的结点。

首先我们可以通过以下路径来找到优化CheckBound的目标代码：

目标代码如下:

可以看到，在CheckBound的优化判断逻辑中，如果当前索引的最大值小于length的最小值，则表示当前索引的使用没有越界，此时将会移除CheckBound结点以简化IR图。

需要注意NumberConstant结点的Type是一个Range类型，因此才会有最大值Max和最小值Min的概念。

这里需要解释一下环境搭配中所说的，为什么要添加一个编译参数v8_optimized_debug = false，注意看上面判断条件中的这行条件

visitNode时有三个状态，分别是Phase::PROPAGATE（信息收集）、Phase::RETYPE（从类型反馈中获取类型）以及Phase::LOWER（开始优化）。当真正开始优化时，lower()条件自然成立，因此我们无需处理这个。

但对于下一个条件，通过动态调试可以得知，poisoning_level始终不为PoisoningMitigationLevel::kDontPoison。通过追溯lowering->poisoning_level_，我们可以发现它实际上在PipelineCompilationJob::PrepareJobImpl中被设置

而FLAG_branch_load_poisoning始终为false，FLAG_untrusted_code_mitigations始终为true

编译参数v8_untrusted_code_mitigations 默认 true，使得宏DISABLE_UNTRUSTED_CODE_MITIGATIONS没有被定义，因此默认设置FLAG_untrusted_code_mitigations = true

这样就会使得load_poisoning始终为PoisoningMitigationLevel::kPoisonCriticalOnly，因此始终无法执行checkBounds的优化操作。所以我们需要手动设置编译参数v8_untrusted_code_mitigations = false，以启动checkbounds的优化。

以下是一个简单checkbounds优化的例子

优化前发现存在一个checkBounds：

执行完SimplifiedLoweringPhase后，CheckBounds被优化了:

基础概念介绍到这里，接下来我们学习一道CTF题来练练手。

Google CTF 2018(final) Just-In-Time 是 v8 的一道基础题，适合用于v8即时编译的入门，其目标是执行/usr/bin/gnome-calculator以弹出计算器。在这里我们通过这道题目来学习一下v8的相关概念。

这道题的题解在安全客上有很多，但由于这是笔者初次接触 v8 的题，因此这次我们就详细讲一下其中的细节。

题目给的附件（ctftime中的附件，不是github上的附件）内含一个已编译好的chromium和两个patch文件。

不过由于笔者已经搭了v8的环境，因此决定采用源码编译的方式来编译出一个v8，这样的好处是可以更方便的进行调试。该题的v8版本为7.0.276.3，可以通过chrome://version来获取，或者去OmahaProxy CSV Viewer中查询。

为什么要设置v8_untrusted_code_mitigations = false，请查看上面关于SimplifiedLoweringPhase中checkbounds优化的简单讲解。

这里可能是因为出题者忘记给出v8的编译参数了，否则默认的编译参数将无法利用漏洞。

新打的patch将在turboFan中的TypedLoweringPhase中添加了一种优化方式。

该优化方式将优化诸如x + 1 + 2这类的表达式为x + 3，即以下的Case4：

但是，还记得我们之前所提到的，NumberConstant的内部实现使用的是double类型。这就意味着这样的优化可能存在精度丢失。举个例子：

即，x + 1 + 1不一定会等于x + 2！所以这种优化是存在问题的。

这是为什么呢？原因是浮点数的IEEE764标准。当一个浮点数越来越大时，有限的空间只能保留高位的数据，因此一旦浮点数的值超过某个界限时，低位数值将被舍弃，此时数值不能全部表示，存在精度丢失。

而这个界限正是 $2^{53}-1 = 9007199254740991$，即上图中的MAX_sAFE_INTEGER。

由于x + 1 + 1 Range(5, 5) let t = (x == 1 ? 9007199254740992 : 9007199254740989); // 此时 t => 解释/编译 Range(9007199254740989, 9007199254740992) t = t + 1 + 1; /* 此时 t => 解释：Range(9007199254740991, 9007199254740992) 编译：Range(9007199254740991, 9007199254740994) */ t -= 9007199254740989; /* 此时 t => 解释：Range(2, 3) 编译：Range(2, 5) */ return arr[t];}console.log(f(1));%OptimizeFunctionOnNextCall(f);console.log(f(1));

Type后的结果如下，可以看到checkbounds的检查可以通过：

因此该checkbounds将在SimplifiedLoweringPhase中被优化：

输出的结果如下：

注：输出结果中的DuplicateAdditionReducer::ReduceAddition Called/Success，是打patch后的输出内容，在原v8中没有该输出。

可以看到，成功将两个+1操作优化为+2，并在最末尾处成功越界读取到一个数组外的元素。

这里需要说一下构建poc可能存在的问题：

POC1：无 if 分支

问题点：由于函数中常数与常数相加减，因此在执行TypedLoweringPhase中的ConstantFoldingReducer时，三个算数表达式会直接优化为一个常数，这样就没办法执行DuplicateAdditionReducer。

解决方法：使用一个if分支，这样就可以通过phi结点来间接设置Range。

以下是一些玄学问题。

POC2：使用Number.MAX_SAFE_INTEGER

问题点：在GraphBuilderPhase中，type feedback推测目标函数的参数只会为1，因此turboFan推测函数中的条件判断式 “恒”成立 ，故在InliningPhase中优化merge结点，使得变量t始终为一个常数。

之后就执行TypedLoweringPhase中的ConstantFoldingReducer再次将其优化为一个常数，以至于无法执行DuplicateAdditionReducer优化。

通过turbolizer我们可以看出，若判断条件为真，则将优化好的结果输出；若判断条件为假，则说明type feedback出现错误，需要执行deopt。

至于为什么先前的poc不会优化merge结点，而当前这个poc会优化merge结点，

这个问题仍然需要进一步探索。

解决方法：

不同时在 if 语句的两个分支处使用Number.MAX_SAFE_INTEGER

在执行%OptimizeFunctionOnNextCall前，使函数调用传入的参数不单一:

POC3：不使用let/var/const修饰词

问题点：经过gdb动态调试可知，若数组前没有修饰词，则CheckBounds的上一个结点LoadField结点将不会被LoadEliminationPhase优化，这样使得数组length结点的范围最大值为134217726，最后导致无法成功优化CheckBounds结点：

同时，若变量t前没有修饰词，则越界的add操作将被check出，进而设置值为inf/NaN，之后的减法就无法计算出我们所期望的Range值：

解决方法：添加修饰词。

因为没有修饰词 let / var 的变量都是全局变量，而 Load Elimination 的优化对作用域有一定的要求，因此全局变量的 LoadField 结点将不会被优化。

POC4：使用整数数组

问题点：执行console.log时崩溃：

解决方法：更改数组类型。经过一番测试，发现貌似只能改成浮点数数组，改成其他类型的输出都会崩溃。

小结：构造POC需要重复多次 修改代码 => 观察输出 => 从turbolizer中查看结点图 => 分析错误原因 这个过程，有时还需要给源码打patch和上gdb调试，需要耐心。

构造POC时，只需要关注两个重点：

能否成功执行DuplicateAdditionReducer优化

能否成功优化CheckBounds结点。

如果这两个条件都满足，那基本上构建出的POC可以OOB了。

POC有了，那我们试着看一下越界读取到的内存位置，

不出以外的话应该是最后一个元素5.5的下一个8位数据：

启动GDB，可以看到 d8 自动暂停执行：

之后我们可以找到DebugPrint出的数组内存地址：

每个Object内部都有一个map，该map用于描述对应结构的相关属性。其中包括了当前Object的实例大小，以及一些供GC使用的信息。通过上面的输出，我们可以得到，当前JSArray的实例大小只有32字节。

map的具体信息请查阅源码 src/objects/map.h 中的注释。

因此，数组中的其他元素肯定存放于另一个数组，而这个数组的类型为FixedDoubleArray，其地址存放于JSArray中。

需要注意的是：v8 中的指针值大多被打上了tag，以便于区分某个值是pointer还是smi。

因此在gdb使用某个地址时，最低位需要手动置0。

以下是某个 JSArray 的内存布局：

注意到 JSArray中，第四个8字节数据（即上图中的0x0000000500000000）存放的是当前数组的length（5），即便数组元素并没有存放在当前这块内存上。

回到刚刚的话题，数组的值被存放在FixedDoubleArray中，因此我们输出一下内存布局看看：

可以看到，它越界读取到的数据与先前猜测的一致，即最后一个元素的下一个8字节数据。

同时我们还可以从 gdb 的输出中注意到，一个 JSArray的length 即在 JSArray 中保存，又在 FixedDoubleArray 中存放着，这个也可以在源码中直接定位到操作：

但实际上， FixedDoubleArray 中的 length 只用于提供有关固定数组分配的信息，而越界检查只会检查 JSArray 的length，这意味着我们必须修改 JSArray 的 length 才可以进行任意地址读写。

以下是检测数组访问是否越界的代码：

为了验证上述内容的正确性，笔者手动用gdb修改了 JSArray 的 length，发现在 release 版本的v8下可以越界读取。但在 debug 版本下，会触发FixedArray中的DCHECK检查导致崩溃：

因此在编译 debug 版本的 v8 时，需要手动注释掉src/objects/fixed-array-inl.h 中越界检查的DCHECK

请勿直接编译 release 版本的v8来关闭DCHECK，这会大大提高调试难度。

我们将 FixedArray 的内存布局输出，可以发现 JSArray 和 FixedArray 的数据是紧紧相邻的，且 FixedArray 位于低地址处，这为我们修改 JSArray 的 length 提供了一个非常好的条件：

现在我们可以试着越界修改一下 JSArray 的 length。需要注意我们必须越界四格才能修改到length，因此需要稍微修改一下POC越界的范围：

最后输出了1.4853970537e-313，用gdb转换成int类型，刚好为7，这就意味着我们现在可以修改 JSArray 的 length 了。

试一试：

可以发现，越界读写成功！

在附件chromium中试试发现也是可以正常工作的：

但我们发现 v8 和 chromium 输出的值不一样，所以调试 d8 编写 JS 后还需要到 chromium 这边验证一下。

这里有个注意点，在被turboFan优化过的函数中读写数组，其越界判断不会通过我们所熟知的Runtime_KeyedLoadIC_Miss函数，因此越界操作最好在被优化的函数外部执行。

现在我们已经成功让 JSArray 实现大范围向后越界读取，但这明显不够，因为 JSArray 只能向后越界读写 0x40000000字节，有范围限制。

看样子我们可以再次声明一个 JSArray ，然后越界修改其 elements 地址以达到任意地址读写的目的？实际上是不行的，因为每一个 element 都有其对应的 map 指针，如果我们要通过修改 elements 地址来进行任意读的话，我们还必须在目标地址手动伪造一个 fake map，但通常我们是没有办法来伪造的。

因此接下来我们将引入漏洞利用中比较常用的类型：ArrayBuffer。

ArrayBuffer是漏洞利用中比较常见的一个对象，这个对象用于表示通用的、固定长度的原始二进制数据缓冲区。通常我们不能直接操作ArrayBuffer的内容，而是要通过类型数组对象（JSTypedArray）或者DataView对象来操作，它们会将缓冲区中的数据表示为特定的格式，并且通过这些格式来读写缓冲区的内容。

而 ArrayBuffer中的缓冲区内存，就是 v8 中 JSArrayBuffer 对象中的 backing_store 。

需要注意的是，ArrayBuffer 自身也有 element。这个 element 和 backing_store 不是同一个东西：element 是一个 JSObject，而 backing_store 只是单单一块堆内存。 因此，单单修改 element 或 backing_store 里的数据都不会影响到另一个位置的数据。

以下是一个简单的 JS 测试代码：

浏览器中输出的结果：

gdb中输出的地址信息：

我们可以很容易的推测出，那些 JSTypedArray 读写的都是 ArrayBuffer 的 backing_store，因此如果我们可以任意修改 ArrayBuffer 的 backing_store，那么就可以通过 JSTypedArray 进行任意地址读写。

JSTypedArray 包括但不限于 DataView、Int32Array、Int64Array、Float32Array、Float64Array 等等。

笔者将在下面使用DataView对象来对 ArrayBuffer 的 backing_store 进行读写。为了证明 DataView 修改的确实是 ArrayBuffer 中 backing_store 指向的那块堆内存，笔者找到其对应的代码：

注：以下代码来自v8/src/builtins/data-view.tq，代码语言为V8 Torque。该语言的语法类似于TypeScript，其设计目的在于更方便的表示高级的、语义丰富的V8实现。Torque编译器使用CodeStubAssembler将这些片断转换为高效的汇编代码。

更多关于该语言的信息请查阅 V8 Torque user manual。

因此，现在我们可以试着构建任意地址读写原语

根据上面的分析，我们可以梳理一条这样的过程来构造任意地址读写原语：

需要注意的是，在确定 FixedDoubleArray 与 backing_store 之前的相对偏移时，最好不要使用硬编码。因为如果需要在当前内存段上再新建立一个对象时，原先的相对偏移很有可能会失效；而且不使用硬编码也可以更好的将 exp 从 v8 移植到 chromium上。

但不使用硬编码时，使用 for循环结果语句 来循环越界读取数组将会触发一个CSA_ASSERT：

由于CSA_ASSERT只会在Debug版本下的 v8 生效，因此我们同样可以注释掉该语句再重新编译，不影响 chromium 中 exp 的编写。

综上所述，最后构造出的任意地址读写原语如下：

测试结果如下：

注：单次只能测试任意读或任意写，不能同时测试。

可以将目标数据写入目标地址：

可以从目标地址中读出数据

由于 v8 已经取消将 JIT 编码的 JSFunction 放入 RWX 内存中 ，因此我们必须另找它法。根据所搜索到的利用方式，有以下两种：

将 Array 的 JSFunction 写入内存并泄露，之后就可以进一步泄露 JSFunction 中的 code 指针。由于这个Code指针指向 chromium 二进制文件内部，因此我们可以将二进制文件拖入 IDA 中计算相对位移，获取 代码基地址 => GOT表条目 => libc基地址 => enviroment指针，这样就可以获取到可写的栈地址以及mprotect地址。

然后将 shellcode 写入栈里并 ROP 调用 mprotect 修改执行权限，最后跳转执行，这样就可以成功执行 shellcode。

此方法来自 Sakura 师傅，第四条参考链接。

v8 除了编译 JS 以外还编译 WebAssembly （wasm）代码，而 wasm 模块至今仍然使用 RWX 内存，因此我们可以试着将 shellcode 写入这块内存中并执行，不过这个方法有点折腾。

此方法来自 doar-e，第一条参考链接。

第一种利用方式非常的直接，利用起来应该没有太大的难度。因此出于学习的目的，我们选择第二种方式，学习一下 WebAssembly 的利用方式。

通过查阅这片文章 浅谈如何逆向分析WebAssembly二进制文件 - 安全客，我们可以获取到wasm的简易使用方式，并通过这个方式获取到 Wasm 的 JSFunction：

而对于一个 Wasm 的 JSFunction，我们可以通过以下路径来获取 RWX 段地址：

这条路径稍微有点长：JSFunction -> SharedFunctionInfo -> WasmExportedFunctionData -> WasmInstanceObject -> JumpTableStart。

从 JSFunction 出发，获取其 SharedFunctionInfo（相对偏移为 0x18）

之后从 SharedFunctionInfo 获取其 WasmExportedFunctionData（相对偏移为 0x8）

再从 WasmExportedFunctionData 中获取 WasmInstanceObject（相对偏移为 0x10）

最后从 WasmInstanceObject 中获取 JumpTableStart（相对偏移为 0xe8）

查看获取到的 JumpTableStart 位置处的数据，我们可以发现这里是一串汇编代码。给该位置下断，并在 JS 中执行一下 Wasm 的 JSFunction ，我们可以发现控制流被断点成功捕获：

以下是测试用的 JS 代码：

现在情况已经非常明了了，通过之前构建的任意地址读取原语，一步步读取 Wasm JSFunction 的各个属性并最终获取 RWX 内存地址：

需要注意的是，在读取WasmExportedFunctionDataAddr时会触发 debug 的越界检查：

注释掉再重新编译即可。

最后我们只要将 shellcode 写入该 RWX 地址处并调用 Wasm JSFunction 即可成功执行 shellcode。

使用 msfvenom 生成满足以下条件的 shellcode:

payload为 linux x64

格式为 C语言

命令为DISPLAY=:0 gnome-calculator

输出如下：

结合上面的内容，release 版本 v8 的 exp 如下：

最终在 release 版下的 v8 可以成功调用 calculator：

但我们做题实际用到附件是一个带漏洞 v8 的 chromium。为了将 exploit 从 v8 移植到 chromium，其中做了一点点微调，因此最终的 exploit 如下：

这里主要调整了两个地方：

使用如下命令以执行exp:

尽管给出的附件打了no-sandbox的patch，但实际exp仍然无法执行，必须附加参数--no-sandbox才能成功触发，玄学问题XD。

效果如下：

![img](v8-turboFan/exp.gif %}