關於代碼壓縮混淆加密整理；

我這里說的前端加密，是對瀏覽器端的js文件加密，不是傳輸過程中的加密，不涉及hash摘要等

1. 降低可讀性

1.1 壓縮（compression）

很好理解，就是去掉注釋、多於的空格、簡化標識符等等。工具很多，YUI Compressor、UglifyJS、Google Closure Compiler等等。

1.2 混淆（obfuscation）

保證不破壞代碼執行結果的情況下，讓代碼變得難以閱讀。常用混淆規則：拆分字符串、拆分數組、增加廢代碼、，壓縮其實也有一定混淆功能。本質就是改變輸入代碼字符串的抽象語法樹（AST）的結構。其他工具：v8就是一個，還有mozilla的SpiderMonkey, 知名的esprima，還有uglify；商業混淆服務有：jscramble。

1.3 加密（encryption）

這里的加密指文本可逆編碼，是狹義的加密，也就是我們常說的加密啦。這個部分依然是借助一些工具，如： Packer 、bcrypt等等。

2. 代碼不放置在JS文件中

將代碼放在非js文件中，增加定位難度。這里常用的方式有兩種：放置到png中，通過HTML Canvas 2D Context獲取二進制數據的特性，可以用圖片來存儲腳本資源；放置到css文件中，利用content樣式可以存放字符串的特性，同樣可以。

2.1 png

用png保存js代碼，首先需要對png進行編碼，然后使用的時候進行解碼。借助canvas及base64和二進制編碼。

編碼

1、字符串轉換成ascii碼； 
2、創建足夠存儲空間的canvas； 
3、將字符填入到像素中（忽略alpha值）； 
4、獲取data url； 
canvas.toDataURL(“image/png”); 
5、存為png圖片。

function encodeUTF8(str) { return String(str).replace( /[\u0080-\u07ff]/g, function(c) { let cc = c.charCodeAt(0); return String.fromCharCode(0xc0 | cc >> 6, 0x80 | cc & 0x3f); } ).replace( /[\u0800-\uffff]/g, function(c) { let cc = c.charCodeAt(0); return String.fromCharCode(0xe0 | cc >> 12, 0x80 | cc >> 6 & 0x3f, 0x80 | cc & 0x3f); } ); } function request(url, loaded) { let xmlhttp = new XMLHttpRequest(); xmlhttp.onreadystatechange = function() { if (xmlhttp.readyState == 4) if (xmlhttp.status == 200) loaded(xmlhttp); } xmlhttp.open("GET", url, true); xmlhttp.send(); } void function(){ let source = '../image/test.js'; request(source, function(xmlhttp){ let text = encodeUTF8(xmlhttp.responseText); let pixel = Math.ceil((text.length + 2) / 3); // 1一個像素存3個字節, let size = Math.ceil(Math.sqrt(pixel)); //console.log([text.length, pixel, size, size * size * 3]); let canvas = document.createElement('canvas'); canvas.width = canvas.height = size; let context = canvas.getContext("2d"), imageData = context.getImageData(0, 0, canvas.width, canvas.height), pixels = imageData.data; for(let i = 0, j = 0, l = pixels.length; i < l; i++){ if (i % 4 == 3) { // alpha會影響png還原 pixels[i] = 255; continue; } let code = text.charCodeAt(j++); if (isNaN(code)) break; pixels[i] = code; } context.putImageData(imageData, 0, 0); document.getElementById('base64').src = canvas.toDataURL("image/png"); }); }();

編碼后的圖片： 

解碼

1、加載png； 
2、將png原尺寸繪制到canvas中； 
3、讀取像素中的字符串； 
4、生成相應協議的data url使用。

void function(){ let source = '../image/test.png'; let img = document.createElement('img'); img.onload = function(){ let canvas = document.createElement('canvas'); canvas.width = img.width; canvas.height = img.height; let context = canvas.getContext("2d"); context.drawImage(img, 0, 0); let imageData = context.getImageData(0, 0, canvas.width, canvas.height), pixels = imageData.data; let script = document.createElement('script'); let buffer = []; for (let i = 0, l = pixels.length; i < l; i++) { if (i % 4 == 3) continue; // alpha會影響png還原 if (!pixels[i]) break; buffer.push(String.fromCharCode(pixels[i])); } script.src = 'data:text/javascript;charset=utf-8,' + encodeURIComponent(buffer.join('')); document.body.appendChild(script); script.onload = function(){ console.log('script is loaded!'); } img = null; } img.src = source; }();

這里需要手動下載編碼后的圖片，我沒有寫自動下載的函數，這又是另一個可以深入探討的問題了，所以不過多擴展。

2.2 css

使用content就簡單多啦。

let div = document.getElementById('content'); let content = window.getComputedStyle(div, ':before').content;

只需要和上面代碼一樣，新建一個srcript標簽，利用data協議，就可以執行content內保存的js代碼啦。

3. 防止代碼執行被截獲

• 截獲 eval() / new Function() 的示例代碼

eval = function() { console.log('eval', JSON.stringify(arguments)); }; eval('console.log("Hello world!")'); Function = function() { console.log('Function', JSON.stringify(arguments)); return function() {}; }; new Function('console.log("Hello world!")')();

但是可能不是全局使用：

(function(){}).constructor('console.log("Hello world!")')()

• 截獲 constructor 的示例代碼

Function.prototype.__defineGetter__('constructor', function () { return function () { console.log('constructor', JSON.stringify(arguments)); }; }); (function() {}).constructor('console.log("Hello world!")');

目前能想到的是判斷 eval 是否被重定向

示例，如果 eval 被重定向 z 變量不會被泄露

(function(x){ var z = 'console.log("Hello world!")'; eval('function x(){eval(z)}'); x(); })(function() { /* ... */ });

uglify介紹

概述：

• 案例：Cesium打包流程，相關技術點和大概流程

• 原理：代碼優化的意義：壓縮 優化 混淆

• 優化：如何完善Cesium打包流程

關鍵字：Cesium gulp uglifyjs

字數：2330 | 閱讀時間：7min+

 

1 Cesium打包流程

       如果沒有記錯，Cesium從2016年初對代碼構建工具做了一次調整，從grunt改為gulp。作為一名業余選手，就不揣測兩者的差別了。個人而言，gulp和Ant的思路很相似，通過管道連接，都是基於流的構建風格，而且gulp更像是JS的編碼風格，自帶一種親切感。

gulp.task('task1',['task0'], function() {

    return fun_task1();

});

       Task語句是gulp中最常見的，懂了這句話，就等於你看懂腳本了。這句話的意思是，要執行task1，需要先執行task0，而task1的具體工作都在fun_task1方法中。這就是之前說的基於流的構建風格。有了這句話，在命令行中鍵入：gulp task1，回車執行該指令即可。

       先安裝Node，環境變量等，並安裝npm包后，即可使用gulp打包工具，這里推薦cnpm。環境搭建好后，命令行中鍵入gulp minify開始打包。完整的過程是build->generateStubs->minify。

Cesium打包流程

       build：准備工作，創建Build文件夾；將glsl文件轉為js形式；最主要的是createCesiumJs方法，遍歷Source中所有js腳本，將所有Object記錄到Source/Cesium.js；其他的是范例，單元測試相關模塊。

       generateStubs：用於單元測試，略。

       minify; 首先combineJavaScript主要做了兩件事情，打包Cesium和Workers腳本，這是打包的最終結果。Gulp根據指令的不同，比如minify下采用uglify2優化，而combine對應的參數為none，生成路徑為CesiumUnminified。

       另外，細心的人會發現，combineCesium的實現中有這樣一句話path.relative('Source',require.resolve('almond'))，這是一個小優化，almond是requirejs的精簡包，因此，最終的Cesium.js中包含'almond腳本，內置了requirejs的主要方法。

       如上是Cesium打包的主要流程，簡單說主要有3+1類個指令：

• Clean

  • 清空文件

• minify

  • 打包&壓縮

• combine

  • 只打包，不壓縮

• JScoverage

  • 單元測試覆蓋率，不了解

2 代碼優化

       對流程有了一個大概了解，下面，我們詳細了解一下uglify2過程都做了哪些代碼優化，一言以蔽之，壓縮，優化，混淆。

       uglify2主要有三個參數：-o，-c，-m，-o參數必選，指定輸出文件，-c壓縮，-m混淆變量名。如下分別為combine、(uglifyjs -o)、(uglifyjs –c -m -o)的文件對比，單位是k：

uglify2的壓縮對比

       都在一個屋檐下，差距怎么就這么大呢？我們簡單說一下從1~2，2~3之間青取之於藍而勝於藍的過程。

       1~2的過程其實很簡單，就是干了三件事，去掉注釋， 去掉多余的空格(換行符)，去掉不必要的分號(;)。就這三件事情，文件一下子小了一半多，換句話就是平時你寫的代碼有一大半都是廢話，此時你旁邊的AI程序員可能會喃喃道來“你們人類好愚蠢~”。

       2~3則是很多小細節的綜合應用：

• 去掉一些實際沒有調用的函數（Dead code）；

• 將零散的變量聲明合並，比如 var a; var b;變為var a,b;

• 邏輯函數的精簡，比如if(a) b(); else c()變為a ? b() : c();

• 變量名的簡化，比如var strObject;變為var s;

• ……

       這些小技巧有很多，具體要看不同的壓縮工具的考慮優劣，但有些壓縮高效的工具並不穩定，可能會破壞語法規范或語意，所以沒必要為了幾個kb承擔過多的風險，目前比較成熟的工具主要有三個uglify2，google closure以及yuicompressor，具體優劣得自己來體會了，我是按照自己的理解給出的先后順序。最終的效果如下：

Cesium腳本效果

       這樣的代碼只能用單位“坨”來形容了，人類是無法直接讀懂的，那瀏覽器能讀懂嗎？這是一個好問題！如下是V8引擎對JS語法解析的大概流程：

V8引擎解析JS腳本

       下面是在我本機Chrome解析Cesium.js腳本花費時間（腳本從下載完到瀏覽器解析完的時間差），單位毫秒，因為只測試了一次，可能會有誤差，但基本吻合期望值：

 

JS腳本解析時間對比

       首先因為是本機測試，腳本無論是最大的8M還是最小的2.4M，下載速度都很快，因此我們不討論（但實際應用中要考慮）腳本下載所需時間。

其次，如上圖，多了一個source，這是源碼情況下，這個時間水分比較大，因為是零散的文件，可以做到按需下載，但因為文件比較瑣碎，性能也不高。

       結論是，這種JS腳本優化策略對瀏覽器的影響不大，瀏覽器看到優化后的代碼，可能會愣一會神，但很快就克服了。

3實戰

       知道了代碼優化的大概原理，回顧一下代碼優化的目的（壓縮，優化，混淆），匹配一下結果是否符合期望值。嗯，其一，腳本的大小小了，其二，代碼效率也優化了，其三，別人也看不懂了。似乎該做的都已經做了，這個腳本已經很完美了。

 

Format后的效果

       毛爺爺說，與人斗其樂無窮。確實，前兩點的目的達到了，但第三點，還差很多。如上，和剛才的腳本是同一個文件，我只是用Chrome的調試工具format而已。這就是理想和現實之間的差距。

       可見，Cesium默認打包工具在壓縮和優化上都沒有問題，但在混淆上並不充分，當然Cesium本身是開源的，也沒必要搞這些。客觀說，JS腳本是明碼的，所以反編譯只是時間和能力的問題，所以不妨換個態度來看待這個問題，增加反編譯的成本，當該成本大於購買成本即可