前端核心代码保护技术面面观

感谢 @赵洋的投稿。

1、 前言

Web的开放与便捷带来了极高速的发展，但同时也带来了相当多的隐患，特别是针对于核心代码保护上，自作者从事Web前端相关开发的相关工作以来，并未听闻到太多相关于此的方案，『前端代码无秘密』这句话好似一个业界共识一般在前端领域传播。但在日常的开发过程中，我们又会涉及以及需要相当强度的前端核心代码的加密，特别是在于与后端的数据通信上面（包括HTTP、HTTPS请求以及WebSocket的数据交换）。

考虑一个场景，在视频相关的产品中，我们通常需要增加相关的安全逻辑防止被直接盗流或是盗播。特别是对于直播来说，我们的直播视频流文件通常会被划分为分片然后通过协商的算法生成对应的URL参数并逐次请求。分片通常以5至10秒一个间隔，如果将分片URL的获取作为接口完全放置于后端，那么不仅会给后端带来极大的压力外还会带来直播播放请求的延迟，因此我们通常会将部分实现放置于前端以此来减少后端压力并增强体验。对于iOS或是Android来说，我们可以将相关的算法通过C/C++进行编写，然后编译为dylib或是so并进行混淆以此来增加破解的复杂度，但是对于前端来说，并没有类似的技术可以使用。当然，自从asm.js及WebAssembly的全面推进后，我们可以使用其进一步增强我们核心代码的安全性，但由于asm.js以及WebAssembly标准的开放，其安全强度也并非想象中的那么美好。

本文首先适当回顾目前流行的前端核心代码保护的相关技术思路及简要的实现，后具体讲述一种更为安全可靠的前端核心代码保护的思路（SecurityWorker）供大家借鉴以及改进。当然，作者并非专业的前端安全从业者，对部分技术安全性的理解可能稍显片面及不足，欢迎留言一起探讨。

2、 使用Javascript的混淆器

在我们的日常开发过程中，对于Javascript的混淆器我们是不陌生的，我们常常使用其进行代码的压缩以及混淆以此来减少代码体积并增加人为阅读代码的复杂度。常使用的项目包括：

• UglifyJS

• Google Closure Compiler

• YUI Compressor

• ...

Javascript混淆器的原理并不复杂，其核心是对目标代码进行AST Transformation（抽象语法树改写），我们依靠现有的Javascript的AST Parser库，能比较容易的实现自己的Javascript混淆器。以下我们借助 acorn 来实现一个if语句片段的改写。

假设我们存在这么一个代码片段：

for(var i = 0; i < 100; i++){
    if(i % 2 == 0){
        console.log("foo");
    }else{
        console.log("bar");
    }
}

我们通过使用UglifyJS进行代码的混淆，我们能够得到如下的结果：

for(var i=0




    
;i<100;i++)i%2==0?console.log("foo"):console.log("bar");

现在让我们尝试编写一个自己的混淆器对代码片段进行混淆达到UglifyJS的效果：

const {Parser} = require("acorn")
const MyUglify = Parser.extend();

const codeStr = `
for(var i = 0; i < 100; i++){
    if(i % 2 == 0){
        console.log("foo");
    }




    
else{
        console.log("bar");
    }
}
`;

function transform(node){
    const { type } = node;
    switch(type){
        case 'Program': 
        case 'BlockStatement':{
            const { body } = node;
            return body.map(transform).join('');
        }
        




    
case 'ForStatement':{
            const results = ['for', '('];
            const { init, test, update, body } = node;
            results.push(transform(init), ';');
            results.push(transform(test), ';');
            results.push(transform(update), ')');
            results.push(transform(body));
            return results.join('');
        }
        




    
case 'VariableDeclaration': {
            const results = [];
            const { kind, declarations } = node;
            results.push(kind, ' ', declarations.map(transform));
            return results.join('');
        }
        case 'VariableDeclarator':{
            const {id, init} = node;
            return id.name + '=' + init.raw;
        




    
}
        case 'UpdateExpression': {
            const {argument, operator} = node;
            return argument.name + operator;
        }
        case 'BinaryExpression': {
            const {left, operator, right} = node;
            return transform(left) + operator + transform(right);
        }
        case 'IfStatement': {
            




    
const results = [];
            const { test, consequent, alternate } = node;
            results.push(transform(test), '?');
            results.push(transform(consequent), ":");
            results.push(transform(alternate));
            return results.join('');
        }
        case 'MemberExpression':{
            const {object, property} = node;
            return object.name 




    
+ '.' + property.name;
        }
        case 'CallExpression': {
            const results = [];
            const { callee, arguments } = node;
            results.push(transform(callee), '(');
            results.push(arguments.map(transform).join(','), ')');
            return results.join('');
        }
        case 'ExpressionStatement':{
            




    
return transform(node.expression);
        }
        case 'Literal':
            return node.raw;
        case 'Identifier':
            return node.name;
        default:
            throw new Error('unimplemented operations');
    }
}

const ast = MyUglify.parse(codeStr);
console.log(transform(ast)); // 与UglifyJS输出一致

当然，我们上面的实现只是一个简单的举例，实际上的混淆器实现会比当前的实现复杂得多，需要考虑非常多的语法上的细节，此处仅抛砖引玉供大家参考学习。

从上面的实现我们可以看出，Javascript混淆器只是将Javascript代码变化为另一种更不可读的形式，以此来增加人为分析的难度从而达到增强安全的目的。这种方式在很久以前具有很不错的效果，但是随着开发者工具越来越强大，实际上通过单步调试可以很容易逆向出原始的Javascript的核心算法。当然，后续也有相当多的库做了较多的改进，JavaScript Obfuscator Tool是其中的代表项目，其增加了诸如反调试、变量前缀、变量混淆等功能增强安全性。但万变不离其宗，由于混淆后的代码仍然是明文的，如果有足够的耐心并借助开发者工具我们仍然可以尝试还原，因此安全性仍然大打折扣。

3、 使用Flash的C/C++扩展方式

在Flash还大行其道的时期，为了更好的方便引擎开发者使用C/C++来提升Flash游戏相关引擎的性能，Adobe开源了 CrossBridge 这个技术。在这种过程中，原有的C/C++代码经过LLVM IR变为Flash运行时所需要的目标代码，不管是从效率提升上还是从安全性上都有了非常大的提升。对于目前的开源的反编译器来说，很难反编译由CorssBridge编译的C/C++代码，并且由于Flash运行时生产环境中禁用调试，因此也很难进行对应的单步调试。

使用Flash的C/C++扩展方式来保护我们的前端核心代码看起来是比较理想的方法，但Flash的移动端上已经没有任何可被使用的空间，同时Adobe已经宣布2020年不再对Flash进行维护，因此我们完全没有理由再使用这种方法来保护我们前端的核心代码。