V8! 兄弟们V8! 真男人就要用V8！

V8字节码反汇编与反编译过程中的实践与经验，涵盖构建 V8、分析 bytecode 格式、尝试绕过校验与反汇编/反编译的一些非官方方法瞄。

博客原地址: 链接

由于开始996了的原因，反编译部分进度会比较慢，所以还是先把反汇编部分发了。

（如有错漏，敬请指正）

反正总之我也不知道，因为Javascript在市面上用的越来越多了，与之相对的，开发者们对js的保护的需求也越来越多了。

但是因为Javascript是一门解释型语言，代码运行依赖与解释器，解释器又需要代码本身直接存在，所以从根源上来说js相比c相比编译型语言就更容易被反编译——至少门槛会高不少。

这叫什么来着——人民日益增长的 JS 代码保护需求，和 JavaScript 作为解释型语言先天裸奔、易反编译的“矛盾”。

举个栗子，你可能有一个非常核心的函数：

core.js

我们可以通过另外一个js来调用这个函数

但是在这种情况下，即便你的 validate 函数再怎么复杂、高级、noble，fancy。如果你把这个文件打包进去随应用一起发布，那么core.js相当于对用户是明文的。

一些“逆向爱好者(比如我)”可能会打开 core.js，然后直接找到你的验证函数，恭喜你，验证逻辑直接暴露了。

更别说如果你是写 Electron 应用、或者做的是类似客户端验证这种场景——那基本是毫无遮掩地把验证逻辑送到了攻击者面前，这样就很不安全。

所以为了保护我们可爱的js代码，最近（并非最近）有一种方式开始慢慢流行起来了，那就是把你的核心js代码编译成字节码，然后通过vm加载，这样子你的核心代码就不容易被反编译啦。

实现这个方式，有一个工具可以用 —— bytenode。

一句话介绍：

Bytenode 是一个可以把 JavaScript 源码编译成 V8 字节码的工具。

它的主要用途就是把你的 .js 编译成 .jsc 文件，然后你用 Node.js 或 Electron 的 vm 模块去加载这个字节码，而不是原始代码。

那么接下来我们就可以尝试把上面那段代码保护起来了

首先我们需要安装一下 bytenode：

然后把那个 core.js 编译成字节码。注意，bytenode 的编译目标是 .jsc 文件，里面包含的就是Js Bytecode。

运行完之后，你会得到一个 core.jsc 文件，但是这个文件不能直接通过require()导入。因为 Node.js 不知道怎么处理 .jsc。

所以我们得写个引导程序，比如说 main.js：

然后再运行，你就会得到如下输出

但这次不一样的是，core.jsc并不包含原始代码。打开core.jsc，看到的也只是一些神必字节流。

不赖，安全感++。

所以, 这个神必字节流到底是什么呢，这其实就是 V8 Bytecode。

所以，什么是 V8 呢？

你说的对，但是《V8》是由 Google 自主研发的一款高性能 JavaScript 引擎。它运行在一个被称作「堆（Heap）」的内存世界，在这里，被即时编译器（JIT）选中的函数将被授予「优化编译」的加护，导引处理器的力量。你将扮演一位名为「脚本（Script）」的神秘角色，在解释执行与优化编译之间来回穿梭，邂逅性格各异、职责独特的伙伴们 (Ignition、TurboFan、Orinoco、等）。和他们一起击败延迟与瓶颈，找回丢失的性能——同时，逐步发掘V8的真相。

而所谓的v8 bytecode就是一种Ignition解释器能够读得懂的代码，V8 bytecode 本质上就是 V8 自己序列化出来的一段数据。

我们关心它的原因很简单：bytenode 生成的 .jsc 其实就是 V8 的字节码格式。

所以在我们更加深入v8之前，我们首先要能够拿到v8的代码，并且能够编译，毕竟如果不能编译运行，那么一切对字节码的分析、调试就会非常困难。

构建流程本身不复杂，具体可以参照官方文档，Building V8 from source

简单来说，编译一个适合node的v8可以这么做

首先要注意到的是V8 bytecode的内部结构不是固定的。

不同版本的V8，在很多底层实现细节上都可能完全不一样，尤其是字节码层面：

这就意味着，不同版本编译出来的字节码结构也不一样。甚至有时候只升级一个小版本，字节码也会有很大的不同。

如果你需要切换 V8 版本，可以这样做：

常用的 tag 长这样（例）：

然后重新走一遍 gn gen ... + ninja -C out/... 的构建流程。

如果你想知道你现在使用的 Node.js 用的是哪一版 V8，可以直接执行node -p process.versions.v8：

如果你想查询其他 Node.js 版本对应的 V8 版本，也可以去
Node.js 旧版本列表 页面，点击对应版本后面的 details，就能看到它内置的 V8 版本号。

还有一个非常容易被忽略的点：V8 bytecode的内部结构不仅不同版本不一样，在不同编译编译参数（build args）下，也就是前面--args=里面的内容，v8 bytecode的内部结构也不一样。

简单来说就是，如果你build v8时所用的build args和实际生成bytecode时所用的v8不一致，那你得到的字节码结构和真实环境里的结构可能会完全对不上，从而导致反编译、反汇编失败。

几个需要注意的点：

但是node.js和electron和原版的v8还是有一些区别的，因为这两个都因为自身的需要对v8做了patch。

electron用了node，electron也对node做了一定的patch。

如果环境不匹配就有可能导致反编译失败，因为内部的结果会不一样。

所以如果想要一比一复刻node.js环境的话，需要根据nodejs/node自己修改

相对应的如果想要一比一符合electron环境，需要根据electron patches，先打好对应的补丁。

注意：为了方便，使用的node版本为v24.7.0, 对应v8版本13.6.233.10-node.26，不同版本bytecode结构可能不同

我们注意到，v8 bytecode实际上是在编译 JavaScript 脚本时，由 CodeSerializer::Serialize 生成的。

所以我们想分析v8字节码，最好也是最直接的方式就是去翻源码看看它是怎么“打包”的。

在 src/snapshot/code-serializer.cc 中可以找到 CodeSerializer::Serialize 的实现：

CodeSerializer::Serialize 会把一段 JavaScript 函数编译出的字节码（BytecodeArray）以及它依赖的各种上下文（常量池、对象字面量、跳转表、源信息等）打包进一段连续的二进制流中。

src/snapshot/code-serializer.cc

这段序列化出来的二进制流，会被包裹在一个 AlignedCachedData 对象里，来生成最终的字节码，并作为CachedData 返回。

而AlignedCachedData 又使用了SerializedCodeData来生成字节码。

所以，查看SerializedCodeData的实现和header文件我们可以大致知道字节码的格式。

SerializedCodeData 是整个字节码的最外层数据结构，位于 src/snapshot/code-serializer.h 中。

从实现可以看到，它的整体结构分为两部分：

头部大致长这样：

这些字段是在 SerializedCodeData::SerializedCodeData 构造函数中被依次写入的。

最后，还会将 payload 拷贝到 header 后面，并计算 checksum。

在前文中提到，知道v8版本对于反编译v8字节码至关重要。

但如果我们手上只有一个 .jsc 文件，又不知道它是用哪个版本编译的，该怎么办？

答案藏在 Header 里的 VersionHash 字段。

注意到，在 SerializedCodeData 的构造流程中，会把当前 V8 的版本信息写入 Header。

这个版本号不是直接存文本，而是经过哈希函数压缩成一个 uint32_t：

这四个整数会被 Version::Hash() 计算成一个 32 位整数，写入 Header 的 kVersionHashOffset 位置。

Version::Hash() 的实现可以在 src/utils/hash.h 里找到，它调用了 base::hash_combine()，而 hash_combine 的底层实现在 src/base/hashing.h 中。

Version Hash的生成方式: src/utils/hash.h

Hash的具体实现: src/base/hashing.h

知道了算法，就可以反推版本号。

思路也很简单：对一堆可能的 (major, minor, build, patch) 组合做哈希，看看有没有等于我们提取到的那个 hash 值的。

由于V8的版本号有限，且范围并不大（major/minor 一般 0~20，build 也就几百），所以穷举搜索完全可行，跑一会儿就能出来。

代码如下

当然我们也可以手动实现hash函数

到了这里我们就可以通过hash暴力破解版本号，比如

可以看到暴力破解出来的版本号为13.4.114.21

这样一来，即便我们拿到的是一份完全未知的 .jsc 文件，也能先定位它是哪个V8版本生成的，然后再去寻找对应源码版本进行反汇编分析。

注意：这里使用的node版本为v24.7.0, 对应v8版本13.6.233.10-node.26，不同版本的api可能不同

在前面我们已经成功解析出了v8字节码的整体格式，现在要做的就是让V8帮我们把这堆 bytecode 重新“读”出来。

好消息是：V8 本身就内置了反汇编功能。

如果你曾经尝试过在Node.js中使用 --print-bytecode 参数运行任意js文件，你就会发现在运行之前，程序会输出一大段的文本，而这正是反汇编的结果。

也就是说，V8 其实已经自带了一个完整的字节码反汇编器，我们要做的就是想办法“绕过源码编译阶段”，让它直接把v8字节码打印出来

跟踪 --print-bytecode 的执行流程，可以发现它最终会调用 BytecodeArray::Disassemble 来输出字节码。
进一步跟进去，这个函数内部又会调用 Print，而 Print 则是定义在 src/diagnostics/objects-printer.cc 里的。

这个文件可以说是 V8 所有对象（Object）调试输出的总控制中心，几乎所有类型对象的打印逻辑都定义在这里。
换句话说，只要你手上拿到了任意一个 V8 对象实例（Object），就可以直接调用它的 Print() 方法，然后 V8 就会自动打印出它的字节码、寄存器、常量池等调试信息。

问题来了：我们手上只有v8字节码，这些字节码要怎么才能变成一个Object呢？

答案还是在 CodeSerializer中，它有一个非常关键的函数：CodeSerializer::Deserialize。

这个函数接收一段 AlignedCachedData，会尝试把其中的字节码反序列化回一个 SharedFunctionInfo 对象。

而这个 SharedFunctionInfo，就是一个实实在在的 V8 Object，拿到它之后我们就可以直接 Print() 输出它的字节码。

当然，CodeSerializer::Deserialize也有一些限制。

CodeSerializer::Deserialize 内部会调用 SerializedCodeData来初始化v8字节码数据， SerializedCodeData内部会调用 SerializedCodeData::SanityCheck、SanityCheckJustSource 和 SanityCheckWithoutSource，对传入的
v8字节码做关于版本、快照、hash 等一堆东西的验证。

如果任何一项没通过，它会直接 reject 掉这份缓存，返回空对象。

为了反汇编，我们可以选择最简单粗暴的方法：

把这些检查全删掉。

做法也很简单，把这三个 SanityCheck* 函数的返回值硬改为 kSuccess，让它无条件通过即可。

全~都 删掉！

一旦v8字节码成功被反序列化成 SharedFunctionInfo，剩下的事情就很简单了

遍历整个对象图，把字节码内所有还原出来的对象都按内存地址顺序 Print() 一遍就ok了。

我们主要参照View8，来实现我们的反编译功能

todo

好吧，实际上最开始我只是想破解一下typora，因为最新的typora是通过bytecode加载核心代码的。所以最开始就是想反编译这个，但是目前还是没有成功的反编译出来。感觉可能是electron的vanilla v8的区别有点大吧。

虽然我尝试了使用node中的v8，但是node中的v8也不能反编译typora的jsc文件。

总的来说就是为了一碗醋包了个饺子，虽然到最后也没能沾上醋。。。

但是至少吃上饺子了，不是么。

anyway，这里是项目代码aynakeya/v8asm，喜欢的可以点个star。

node build args

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！