JS混淆是不是纸老虎？

关于JS代码混淆，一直有两种观点。

一种观点认为很有用，是JS代码保护的重要手段，这是主流观点。

但也见到少数人称不管用，是纸老虎，混淆后的代码还能读懂，随随便便就能破解。

 

哪种观点才是正确的呢？我们通过实验来证明。

实验使用JShaman平台，这是一个专业的JS代码混淆加密平台。

测试用代码，就使用平台提供的例程，简单的几行：

 

保护选项，去掉默认的“压缩代码”功能，为方便我们查看混淆后的代码。

 

一键完成混淆，得到保护后的代码：

 

跟前面保护前的4行代码相比，很显然复杂了很多，跟原始代码相比差别很大，绝不是随便就看看出代码逻辑和功能的。这还只是使用默认的保护选项，保护等级比较低，因此在代码中还有“hello world”字符串能被看到。

如果使用更多的保护选项，提高混淆强度，又会如何呢？

多勾选两个混淆选项：

 

再次一键完成保护，得到：

 

可以看到，这次得到的保护结果更为复杂。短时间、甚至长时间也不容易读懂并还原回原有的代码逻辑。

实验到这里，显然可以说：JS混淆，不是纸老虎，是真有用。

那么，混淆后的代码，是否可以进行反混淆，还原为原始代码呢？

有的人认为可以。实验继续进行：

对保护后的代码反混淆，通常用esprima、escodegen。

我们准备以下代码实现一个反混淆工具

 

注意在代码中，传入了要进行反混淆的代码，即上面我们混淆的结果。

运行，得到反混淆结果：

 

可以看到，确实条理化了代码，但远远没有还原回原本的代码，还记的原本的代码，对比一下：

 

而且我们可以思考一下：比如有一个变量名：car，它是一个有字面意义的变量。经混淆后，它会被变成随字符串，比如：_0x12345。在反混淆时，反混淆程序、工具，无论如何也不可能知道它原本的名称是car。那么，也就绝对不可能把代码完好还原回去。

实验结果证明：JS混淆，是有效的JS代码保护方式！