保护 Node.js 项目的源代码

时间 2019-12-04 标签保护 node.js node 项目源代码

SaaS（Software as a Service，软件即服务），是一种经过互联网提供软件服务的模式。服务提供商会全权负责软件服务的搭建、维护和管理，使得他们的客户从这些繁琐的工做中解放出来。对于许多中小型企业而言，SaaS 是采用先进技术的最好途径。javascript

然而，对于大型企业而言，状况有所不一样。出于产品定制、功能稳定以及掌握自身数据资产等方面的考虑，即便成本增长，他们也更乐意把相关服务部署在企业本身的硬件设备上，也就是常说的私有化部署。java

在私有化部署的过程当中，服务提供商首先要确保本身的源代码不被泄露，不然产品就能够随意复制和更改，得不偿失。传统的后端运行环境，如 Java、.NET，其源代码是通过编译才部署到服务器上运行的，不存在泄露的风险。而对于应用愈来愈普遍的 Node.js 而言，运行的则是源代码。即便通过压缩混淆，也能够很大程度地还原。node

本文介绍一种可用于 Node.js 端的代码保护方案，使得 Node.js 项目也能够放心地进行私有化部署。git

原理

当 V8 编译 JavaScript 代码时，解析器将生成一个抽象语法树，进一步生成字节码。Node.js 有一个叫作 vm 的内置模块，建立 vm.Script 的实例时，只要在构造函数中传入 produceCachedData 属性，并设为 true，就能够获取对应代码的字节码。例如：github

const vm = require('vm');
const CODE = 'console.log("Hello world");'; // 源代码
const script = new vm.Script(CODE, {
  produceCachedData: true
});
const bytecodeBuffer = script.cachedData; // 字节码
复制代码

而且，这段字节码能够脱离源代码运行：数据库

const anotherScript = new vm.Script(' '.repeat(CODE.length), {
  cachedData: bytecodeBuffer
});
anotherScript.runInThisContext(); // 'Hello world'
复制代码

这段代码看起来不那么容易理解，主要体如今建立 vm.Script 实例时传入的第一个参数：npm

既然源代码的字节码已经在 bytecodeBuffer 中，为什么还要传入第一个参数？
为什么传入与源代码长度相同的空格？

首先，建立 vm.Script 实例时，V8 会检查字节码（cachedData）是否与源代码（第一个参数传入的代码）匹配，因此第一个参数不能省略。其次，这个检查很是简单，它只会对比代码长度是否一致，因此只要使用与源代码长度相同的空格，就能够“欺骗”这个检查。后端

细心的读者会发现，这样一来，其实字节码并无彻底脱离源代码运行，由于须要用到源代码长度这项数据。而实际上，还有其余方法能够解决这个问题。试想一下，既然有源代码长度检查，那就说明字节码中也必然保存着源代码的长度信息，不然就没法对比了。经过查阅 V8 的相关代码，能够发现字节码的头部保存着这些信息：数组

// The data header consists of uint32_t-sized entries:
// [0] magic number and (internally provided) external reference count
// [1] version hash
// [2] source hash
// [3] cpu features
// [4] flag hash
复制代码

其中第 [2] 项 source hash 就是源代码长度。但由于 Node.js 的 buffer 是 Uint8Array 类型的数组，因此 uint32 数组中的 [2]，至关于 uint8 数组中的 [8, 9, 10, 11]。服务器

接着把上述位置的数据提取出来：

const lengthBytes = bytecodeBuffer.slice(8, 12);
复制代码

其结果相似于：

<Buffer 1b 00 00 00>

这是一种叫作 Little-Endian 的字节序，低位字节排放在内存的低地址端，高位字节排放在内存的高地址端。

<Buffer 1b 00 00 00> 即为 0x0000001b，也就是十进制的 27。计算方法以下：

firstByte + (secondByte * 256) + (thirdByte * 256**2) + (forthByte * 256**3)

写成代码以下：

const length = lengthBytes.reduce((sum, number, power) => {
  return sum += number * Math.pow(256, power);
}, 0); // 27
复制代码

此外，还有一种更简单的方法：

const length = bytecodeBuffer.readIntLE(8, 4); // 27
复制代码

综上所述，运行字节码的代码能够优化为：

const length = bytecodeBuffer.readIntLE(8, 4);
const anotherScript = new vm.Script(' '.repeat(length), {
  cachedData: bytecodeBuffer
});
anotherScript.runInThisContext();
复制代码

编译文件

讲清楚原理以后，下面就尝试编译一个很简单的项目，目录结构以下：

src/
- lib.js
- index.js
dist/
compile.js

src 目录内的两个文件为源代码，内容分别为：

// lib.js
console.log('I am lib');
exports.add = function(a, b) {
  return a + b;
};
复制代码

// index.js
console.log('I am index');
const lib = require('./lib');
console.log(lib.add(1, 2));
复制代码

dist 目录用于放置编译后的代码。compile.js 即为执行编译操做的文件，其流程也很是简单，读取源文件内容，编译为字节码后保存为文件（dist/*.jsc）：

const path = require('path');
const fs = require('fs');
const vm = require('vm');
const glob = require('glob'); // 第三方依赖包

const srcPath = path.resolve(__dirname, './src');
const destPath = path.resolve(__dirname, './dist');

glob.sync('**/*.js', { cwd: srcPath }).forEach((filePath) => {
  const fullPath = path.join(srcPath, filePath);
  const code = fs.readFileSync(fullPath, 'utf8');
  const script = new vm.Script(code, {
    produceCachedData: true
  });
  fs.writeFileSync(
    path.join(destPath, filePath).replace(/\.js$/, '.jsc'),
    script.cachedData
  );
});
复制代码

运行 node compile 后，就能够在 dist 目录内生成源代码对应的字节码文件，接下来就是运行字节码文件。然而，直接执行 node index.jsc 是没法运行的，由于 Node.js 在默认状况下会把目标文件当作 JavaScript 源代码来执行。

此时，就须要对 jsc 文件使用特殊的加载逻辑。在 dist 目录内新建文件 main.js，内容以下：

const Module = require('module');
const path = require('path');
const fs = require('fs');
const vm = require('vm');

// 加载 jsc 文件的扩展
Module._extensions['.jsc'] = function(module, filename) {
  const bytecodeBuffer = fs.readFileSync(filename);
  const length = bytecodeBuffer.readIntLE(8, 4);
  const script = new vm.Script(' '.repeat(length), {
    cachedData: bytecodeBuffer
  });
  script.runInThisContext();
};

// 调用字节码文件
require('./index');
复制代码

执行 node dist/main，虽然 jsc 文件能够加载进来了，可是就出现了另外一段异常信息：

ReferenceError: require is not defined

这是个奇怪的问题，在 Node.js 中，require 是个很基础的函数，怎么会未定义呢？原来，Node.js 在编译 js 文件的过程当中会对其内容进行包装。以 index.js 为例，包装后的代码以下：

(function (exports, require, module, __filename, __dirname) {
  console.log('I am index');
  const lib = require('./lib');
  console.log(lib.add(1, 2));
});
复制代码

包装这个操做并不在编译字节码这个步骤里面，而是在以前执行。因此，要在 compile.js 补上包装（Module.wrap）操做：

const script = new vm.Script(Module.wrap(code), {
  produceCachedData: true
});
复制代码

加上包装以后，script.runInThisContext 就会返回一个函数，执行这个函数才能运行模块，修改代码以下：

Module._extensions['.jsc'] = function(module, filename) {
  // 省略 N 行代码

  const compiledWrapper = script.runInThisContext();
  return compiledWrapper.apply(module.exports, [
    module.exports,
    id => module.require(id),
    module,
    filename,
    path.dirname(filename),
    process,
    global
  ]);
};
复制代码

再次执行 node dist/main.js，出现了另外一条错误信息：

SyntaxError: Unexpected end of input

这是一个让人一脸懵逼，不知道从何查起的错误。可是，仔细观察控制台又能够发现，在错误信息以前，两条日志已经打印出来了：

I am index
I am lib

因而可知，错误信息是执行 lib.add 时产生的。因此，结论就是，函数之外的逻辑能够正常执行，函数内部的逻辑执行失败。

回想 V8 编译的流程。它解析 JavaScript 代码的过程当中，Toplevel 部分会被解释器彻底解析，生成抽象语法树以及字节码。Non Toplevel 部分仅仅被预解析（语法检查），不会生成语法树，更不会生成字节码。Non Toplevel 部分，即函数体部分，只有在函数被调用的时候才会被编译。

因此问题也就一目了然了：函数体没有编译成字节码。幸亏，这种行为也是能够更改的：

const v8 = require('v8');
v8.setFlagsFromString('--no-lazy');
复制代码

设置了 no-lazy 标志后再执行 node compile 进行编译，函数体也能够被彻底解析了。最终 compile.js 代码以下：

const path = require('path');
const fs = require('fs');
const vm = require('vm');
const Module = require('module');
const glob = require('glob');
const v8 = require('v8');
v8.setFlagsFromString('--no-lazy');

const srcPath = path.resolve(__dirname, './src');
const destPath = path.resolve(__dirname, './dist');

glob.sync('**/*.js', { cwd: srcPath }).forEach((filePath) => {
  const fullPath = path.join(srcPath, filePath);
  const code = fs.readFileSync(fullPath, 'utf8');
  const script = new vm.Script(Module.wrap(code), {
    produceCachedData: true
  });
  fs.writeFileSync(
    path.join(destPath, filePath).replace(/\.js$/, '.jsc'),
    script.cachedData
  );
});
复制代码

dist/main.js 代码以下：

const Module = require('module');
const path = require('path');
const fs = require('fs');
const vm = require('vm');
const v8 = require('v8');
v8.setFlagsFromString('--no-lazy');

Module._extensions['.jsc'] = function(module, filename) {
  const bytecodeBuffer = fs.readFileSync(filename);
  const length = bytecodeBuffer.readIntLE(8, 4);
  const script = new vm.Script(' '.repeat(length), {
    cachedData: bytecodeBuffer
  });

  const compiledWrapper = script.runInThisContext();
  return compiledWrapper.apply(module.exports, [
    module.exports,
    id => module.require(id),
    module,
    filename,
    path.dirname(filename),
    process,
    global
  ]);
};

require('./index');
复制代码

bytenode

实际上，若是你真的须要把 JavaScript 源代码编译成字节码，并不须要本身去编写这么多的代码。npm 平台上已经有一个叫作 bytenode 的包能够完成这些事情，而且它在细节和兼容性上作得更好。

字节码的问题

虽然编译成字节码后能够保护源代码，但字节码也会存在一些问题：

JavaScript 源代码能够在任何平台的 Node.js 环境中运行，但字节码是平台相关的，在何种平台下编译，就只能在何种平台下运行（好比在 Windows 下编译的字节码不能在 macOS 下运行）。
修改源代码后要再次编译为字节码，较为繁琐。对于一些如数据库服务器地址、端口号等配置信息，建议不要编译成字节码，仍使用源文件运行，方便随时修改。

后记

做为一名聪明的读者，你一定能猜到，本文是以倒叙的方式写的。笔者是先使用 bytenode 完成了需求，再研究其原理。

本文同时发表于做者我的博客：《保护 Node.js 项目的源代码》