JS代码安全之路：用JS对JS代码混淆加密 _JS

作者：JShaman.com：w2sft
内容预告：本文将实例讲解以下JS代码混淆加密技术：
方法名转义和转码、成员表达式转IIFE、函数标准化、数值混淆、布尔型常量值混淆、二进制表达式转为调用表达式、字符串转Unicode、局部变量变形、屏蔽输出语句，以及：无限断点、时间差检测等反调试方案。
大纲：理论层面：为什么要对JS代码进行混淆加密？
技术层面：用JS编程实现对JS代码混淆加密。
防逆向措施：检测与对抗。
专业的混淆加密：JShaman 。
彩蛋：字节码加密技术。
理论层面：为什么要对JS代码进行混淆加密？1、问：JS代码需要考虑安全性吗？
答：当然。
2、问：为什么？
答：JS因为应用环境需要，功能设计目的等历史原因，成为了一种代码公开透明的语言。
前端JS代码，直接暴露在浏览器中，任何访问者，都可以随意查看代码。这就导致代码可以被分析、复制、盗用等，进而引发安全问题，如被利用代码bug攻击、揭露功能逻辑、复制出雷同应用等等。
互联网早些年，安全场景如上。而发展到当下，JS的应用范围更加广泛，如NodeJS的兴起，使很多后端服务、产品、项目也应用了JS 。
在后端的角度，如果项目或产品，提交给第三方时，是否要交出源码？显然不妥。
假设服务器被入侵，如果部署的后端服务产品源码也是JS明文，那将导致更严重的安全问题。
更多的应用领域，如小程序开发、H5应用，含ThreeJS引擎类游戏，等，都广泛应用了JS 。
在所有这些场景中，都不应该忽视JS代码的安全问题，都应该且需要对JS代码进行保护。
3、问：如何让JS代码变的安全？
答：对JS代码进行保护：混淆&加密，使代码不可读。即：它人依然可以看到代码，但看到的是加密的代码、无法理解代码，更无法修改。
深入并精准的说：通过混淆加密，使代码变的难以阅读和理解。可能有人说，混淆后机器能执行，人就能理解，只是需要的时间长短问题。这种极端的说法，从理论上来说没错，如果可以投入足够长的时间，程序员甚至可以直接用0101写代码。而从实际角度而言，一段代码如果保护后分析需要的时长，超过开发需要的时长，保护的目的就达到了，就会劝退99.9999%对它有想法的正常人类。
理论已探讨完毕，接下来步入正题，探索如何对JS代码进行混淆加密，可不仅仅是应用层面，而是全面掌握：会用、知其然，知其所在然，还要动手编码，实现：用JS对JS代码混淆加密。
接下来的内容，将在NodeJS环境中，使用JS编程，实现对JS代码的混淆加密。
技术层面：用JS编程实现对JS代码混淆加密。技术理论：如何实现？确定实现方案之前，首先需要排除几种不可用方案：

Eval思路不可用：可以被下断点调试或API HOOK，而轻松还原出原始代码。
可逆加密方式不可用：加密方式可逆，则必然有解密函数，只需定位于解密出口，即可得到原始代码。
异步代码获取并执行不可用：同样可被调试或hook，得到代码。
可取的方式：代码混淆+数据加密。

混淆原理：非replace或regexp方式字符串替换，而是对JS源码进行重编译。从源码，进行词法分析、语法分析、得到AST（抽象语法树），此处是重点，得到AST后，在AST中执行关键混淆加密操作，如：字符算阵列化、字符加密、平展控制流、僵尸代码值入、反调试埋雷、花指令插入等，最后，再将AST重建为JS代码。这样就得到了一份被更改的面目全非的安全JS代码：不可读、不可理解、不可修改、不可还原。
编程现实：用JS对JS代码混淆加密。由以上的理论可知，重点是混淆加密，而入口点及整体流程框架是AST操作。
JS代码&AST 。在JS引擎之下，代码编译执行大体流程是：
JS代码→AST（抽象语法树）→ByteCode（字节码）→机器码→解释器→执行。
AST设计之初并不是用于对JS代码混淆加密，但AST却很适合这个事情。
基于AST的JS代码混淆加密大体流程：
JS代码→AST→（基于AST的混淆加密）→JS代码。
题外话：能在ByteCode阶段进行加密吗？某些情况下可以，比如NodeJS环境中的JS代码，可以编译为ByteCode 。但在前端运行的JS代码，且于DOM有交互的则不理想，小总结而言，有将JS代码进行VM式的加密方法，但通用性较差，使用起来复杂。因为这些弊端，因此，不是普遍性的JS代码保护方案。