起初在研究對移動網絡傳輸進行功耗優化，在一次意外的監聽網絡傳輸包中截獲了微信小程序的請求包，借此來窺探當下前端代碼安全。

0x01 小程序分析

小程序包結構

SegmentNameLengthRemark

HeaderFirstMark1 byte0xBE 固定值

Edition4 bytes0 ->微信分發到客戶端 1 ->開發者上傳到微信后臺

IndexInfoLength4 bytes索引段的長度

BodyInfoLength4 bytes數據段的長度

LastMark1 byte0xED 固定值

FileCount4 bytes文件數量

IndexNameLength4 bytes文件名長度

NameNameLength bytes文件名，長度為NameLength

FileOffset4 bytes文件在數據段位置

FileSize4 bytes文件大小

LOOP......

DataFiles Package......

包結構非常清晰，分為三個部分：

頭信息，包含一些包的標識，版本定義等，包含了三個冗余字段 --- 索引段和數據段的長度應該是用于做校驗，但實質上沒有用（設計者覺得需要設計一些冗余字段來確保設計的完整性，防止解析的時候溢出，但實際工程實踐中并沒有起到相應的作用），文件數量應該是用于簡化包解析過程，實際上知道了索引段長度或數據段長度中任何一個皆可推算出文件數量。

索引段，包含文件的元信息 --- 文件名以及文件位置（通過FileOffset和FileSize定位數據段中的文件）。如果從精簡包的大小的角度來看，FileOffset和FileSize只需一個存在即可，但是這樣解析包的難度就大大增加了，還是以工程實踐為主。

數據段，將所有的文件羅列在一起。

由此可見，數據完全沒有經過壓縮或者加密，連包的簽名信息也沒有。這導致只能在制品流程上進行嚴格控制，例如在開發者上傳代碼過程中需要授信，必須經過審查，也一定得由授信平臺進行代碼分發等。這些都無關風月，畢竟App Store就是這種模式，但是......

如何拆解這種自定義文件格式呢？

對多個相同格式的文件進行對比，對大體結構有宏觀的感覺，很容易發現一些固定的字段以及一些結構的長度。對于像小程序這種有軟件本體的例子，還可以通過微量修改來觀察文件的變化來找到文件結構和意義。

觀察特殊形式，首先英文的字符串是很明顯的，一般hex編輯器都自帶字符串化窗口，如果發現常見的字符串，就可以繼續去尋找字符串的邊界，字符串在二進制文件里有兩種儲存方式：一種是不記錄字符串的長度，讀取字符串到0x00位置，另一種一定在某一個地方儲存了這個字符串的長度，因此一旦得知了該字符串的內容，搜索該長度字段即可獲取更多的信息。其次一些文件頭也非常顯眼，例如PNG、ZIP等通用標準文件格式都有固定的文件頭，在小程序的自定義格式中很容易發現一些png、jpg等資源的文件頭，因此可以定位數據區的位置。

對特定區域的二進制進行推理猜測，一般來說二進制文件里需要儲存大量的offset和size的數據作為數據段的索引。offset相當于一個指針 - 索引文件在數據段的位置，工程實踐中，大部分儲存了offset的地方也會儲存size字段，畢竟在解析文件的時候會方便很多，也可以防止校驗數據出現指針越界。因此，一旦確認了文件中的數據段，就可以通過它的位置（offset）和大小（size）的實際數據進行搜索，逆向找到指向它的數據位置，并且繼續逆向直到解析完整的文件。另外，如果要考慮設計的完備性，需要在二進制文件中加入一些冗余字段進行校驗或者糾錯，例如CheckSum、CRC32、Alder32、MD5、ECC等，這些通過hex編輯器很容易計算并發現。小程序中FileCount的字段，這完全是為了工程實踐考慮的，在小程序中并沒有出現這類的計算值，這是可能是因為小程序為了簡單設計考慮，一旦發現包體被篡改或損壞就直接丟棄。

其實拆解小程序這種格式并不需要花費特別多的精力，因為其格式比較簡單，而且從下圖流程上來說，后綴為wx的二進制格式很可能與wxapkg格式是同源的。

從開發者工具的代碼中的 pack 很容易發現一些對wx格式封裝的痕跡，只不過其中 unpack 的代碼被隱去了。通過實際的分析發現（wxapkg文件可以通過截獲網絡包請求獲得或者在本地的微信appbrand目錄下可以發現），wxapkg格式就是將wx格式進行了轉化：Wxml -> Html、 Wxml -> JS、Wxss -> Css，其二進制格式跟后綴名為wx二進制格式完全一致。我寫了兩個版本的解析二進制包的代碼（ Java版本傳送門， python版本傳送門），其實非常簡單，根據小程序包結構一步一步解析，基本上沒啥難度。但如果要將Html -> Wxml, JS -> Wxml, Css -> Wxss進行還原，其中JS -> Wxml的過程中需要將if語句轉變成wx-if標簽、for語句轉化成wx-for標簽有點麻煩，需要對解析包后的 page-frame.html 中 JS 代碼進行修改，修改細節太多就不再詳說了，總之微信小程序的代碼沒有經過額外的保護措施，比較容易進行還原。

（PS：暴露一下微信小程序未公開的API， openUrl - 在小程序中打開外部網頁； getGroupInfo - 獲得群的名稱，群內成員的昵稱等數據； getOpenidToken - 獲得用戶openid；這些權限微信應該是沒有準備開放的。每次在進入小程序時，客戶端都需要先去請求該小程序的元數據，例如應用名、版本號、一些權限列表、代碼包下載地址等描述信息，修改這些元數據可以獲得相應的權限，小程序的關鍵信息完全由后臺控制進行配置，另外小程序的本地文件存儲采用HASH映射機制進行文件定位，文件存儲在外部存儲，本身通過自定義算法實現完整性校驗 - 首先，小程序最終存儲的文件名是：對稱加密（文件流內容Alder32校驗和 | 原始文件名）生成的，最終文件名和文件內容會通過自校驗判斷完整性；其次，本地緩存是通過HASH映射查找文件。所以即使能破解文件名和文件內容，繞過文件自身簽名校驗，篡改為攻擊者的偽造文件，小程序APP也無法映射到該偽造文件進行使用。）

0x02 前端代碼安全

由上可見，微信并沒有在代碼安全上進行過多的考慮。這導致需要在應用審核過程中花費比較多的功夫，不然作品太容易被復制竄改，以至于會失去渠道先機，這對流量是致命打擊。由于歷史原因，前端的代碼安全技術發展的比較緩慢，相比其他被編譯成二進制的應用，前端這種純文本應用，太容易被辨識與竄改。

對前端代碼進行保護的目的在于讓機器容易識別相關的指令，而使人難以理解代碼的邏輯，但往往在對前端代碼進行保護過程中，很難既兼顧指令效率又能使可讀性降低。因此，常常需要在現有的代碼中增加一些額外的驗證邏輯，例如一些增加無效的代碼進行混淆、采用守護代碼保護業務代碼不能在其他的域名下正常運行、增加一些防止調試跟蹤的斷點等，這些措施都是使得破解代碼時人工成本增加，從而增加代碼的安全性。

下面提供一些能夠增加前端代碼安全性的策略：

1. 精簡(minify)

這是最簡單且無害的方法，精簡代碼能減少代碼體積，從而減小數據傳輸的負荷，同時也能降低代碼的可讀性。在小程序開發者工具中也提供該選項。對Java代碼進行精簡大致可以從以下幾個方面入手：

刪除注釋，刪除無意義或者多余的空白，刪除可以省略的符號

刪除一些沒有調用的代碼（Dead code），對函數進行精簡（三元運算符?:、字符串操作、對象函數、對象繼承、函數引用、無名函數、遞歸函數）

將變量名進行簡化，將零散的變量聲明合并，縮短語句

......

常用的工具有很多： YUI Compressor 、 UglifyJS 、 Google Closure Compiler 、 JS Packer 、 JS Min ...

使用工具對代碼進行精簡時需要注意：1. 最好備份原始代碼，方便調試與后期修改。 2. 用于調試精簡代碼時保存的sourcemap，在線上應該刪除。 3.編寫代碼的時候應該嚴格按照規范，最好使用lint工具對代碼進行檢查，精簡代碼后導致代碼不可用時，調試非常困難。

這種簡單的方法雖然很實用，但是也很容易被還原出源代碼，使用一些代碼格式化工具可以補齊被刪除的空格、換行、符號等，例如 jsbeautifier 。另外2015年就有相關的研究，從大量的代碼中推測出被精簡的代碼，因為人寫代碼總有固定的范式，所寫的代碼相似性都非常的高，如果用統計方式就很容易反推源代碼，蘇黎世聯邦理工大學Martin Vechev教授領帶下開發的工具 JSNice 就是一款運用條件隨機場（Conditional Random Fields）機器學習和程序分析方法來還原Java代碼利器，利用大量的開源代碼，去學習命名和類型的規律。JSNice可以用于以下不同的方面：反精簡的Java代碼、對當前的代碼提供更多的更有意義的變量名、自動化程序的注釋等。相關論文傳送門后臺代碼傳送門

2. 混淆(obfuscation)

混淆可以減低代碼的可讀性，防止被輕易追蹤出程序邏輯。常見的混淆方法有如下幾種：

通過編碼混淆代碼，這篇文章《Java常用混淆方法》里面介紹了很多不錯的編碼加密方法。但是這些方法有個明顯缺點，增加代碼體積，而且編碼加密都是可逆的。

將標識符混淆和控制邏輯混淆（分離靜態資源、打亂控制流、增加無義的代碼等），例如 aaencode 和 jjencode 。

標識符混淆的方法有多種，有些與編碼混淆代碼方法有些重疊，常用方法有哈希函數命名、標識符交換和重載歸納等。哈希函數命名是簡單地將原來標識符的字符串替換成該字符串的哈希值，這樣標識符的字符串就與軟件代碼不相關了；標識符交換是指先收集軟件代碼中所有的標識符字符串，然后再隨機地分配給不同的標識符，該方法不易被攻擊者察覺；重載歸納是指利用高級編程語言命名規則中的一些特點，例如在不同的命名空間中變量名可以相同，使代碼中不同的標識符盡量使用相同的字符串，增加攻擊者對軟件源代碼的理解難度。

控制混淆是改變程序的執行流程，從而打斷逆向分析人員的跟蹤思路，達到保護軟件的目的。一般采用的技術有插入指令、偽裝條件語句、斷點等。偽裝條件語句是當程序順序執行從A到B，混淆后在A和B之間加入條件判斷，使A執行完后輸出TRUE或FALSE，但不論怎么輸出，B一定會執行?？刂苹煜捎帽容^多的還有模糊謂詞、內嵌外聯、打破順序等方法。模糊謂詞是利用消息不對稱的原理，在加入模糊謂詞時其值對混淆者是已知的，而對反混淆者卻很難推知。所以加入后將干擾反匯編者對值的分析。模糊謂詞的使用一般是插入一些死的或不相關的代碼（bogus code），或者是插入在循環或分支語句中，打斷程序執行流程。內嵌（in-line）是將一小段程序嵌入到被調用的每一個程序點，外聯（out-line）是將沒有任何邏輯聯系的一段代碼抽象成一段可被多次調用的程序。打破順序是指打破程序的局部相關性。由于程序員往往傾向于把相關代碼放在一起，通過打破順序改變程序空間結構，將加大破解者的思維跳躍。

另外還有些混淆方式是專門針對于反混淆工具設計的，這就需要去仔細分析反混淆工具的原理，在一些特定的地方插入代碼使反混淆器進入死循環或者異常跳出。

一般來說，提供代碼精簡的工具都會提供一些混淆的方法，除此之外，比較知名的商業工具有 jasob 、 jscrambler ，一般越商業的越難被反混淆，然而這些高級的代碼混淆也常會被用于隱藏應用中的惡意代碼。對惡意代碼進行混淆是為了躲避殺毒軟件的檢測，這些代碼在被混淆擴充后會難以被識別為惡意軟件。相應的也有一些反混淆的工具出現，例如上面提到的 JSNice 工具能夠對混淆的代碼進行推理，另外反混淆工具 JSDetox 專門針對一些混淆方法做過專門的支持。反混淆一直是一項體力活，根據不同的混淆策略需要進行反推演算，這就是一場攻與防的游戲罷了。

3. 加密（encryption）

加密的關鍵思想在于將需要執行的代碼進行一次編碼，在執行的時候還原出瀏覽器可執行的合法的腳本，在某個角度也可以認為是一種混淆的形式，看上去和可執行文件的加殼有點類似。Java提供了將字符串當做代碼執行（evaluate）的能力，可以通過  constructor 、 eval 、  、 setInterval 、 Worker 、 DOM event 等將字符串傳遞給JS引擎進行解析執行，由于有些需要用到 eval 函數，會導致代碼性能會減低。以Worker 執行舉例：

var URL = window.URL || window.webkitURL; var Blob = window.Blob || window.webkitBlob; var blobURL = URL.createObjectURL( new Blob(['console.log("Hello World!")'], {type: 'application/java'})

); new Worker(blobURL);

URL.revokeObjectURL(blobURL);

有以下常見的幾種加密方法：

base64編碼，一種簡單的方法就是將代碼轉化成base64編碼，然后通過 atob 以及 eval 進行解碼然后運行，另外一種采用 base62編碼技術更為常見，其最明顯的特征是生成的代碼以(p,a,c,k,e,r)) 開頭。無論代碼如何進行變形，其最終都要調用一次 eval等函數。解密的方法不需要對其算法做任何分析，只需要簡單地找到這個最終的調用，改為 console.log 或者其他方式，將程序解碼后的結果按照字符串輸出即可。

(PS: 從算法上看， packer 是一種base64編碼字典壓縮策略，packer的base64編碼的壓縮率很高，精簡后代碼依然可以減少50%體積以上，因為帶有解壓器和字符表，越長的代碼理論上壓縮率更高，想要了解詳情可以看看這篇文章《Packer，你對我的JS做了什么！》 )

使用復雜化表達式，在Java中可以把原本簡單的字面量（Literal）、成員訪問（Member）、函數調用（Call）等代碼片段變得難以閱讀。例如這個方法僅用+!等符號就足以實現幾乎任意Java代碼。在 JS 代碼中可以找到許多這樣互逆的運算，通過使用隨機生成的方式將其組合使用，可以把簡單的表達式無限復雜化。

隱寫術，將 JS 代碼隱藏到了特定的介質當中。如通過最低有效位（LSB）算法嵌入到圖片的 RGB 通道、隱藏在圖片 EXIF 元數據、隱藏在 HTML 空白字符、放到css文件中（利用content樣式能存放字符串的特性）等。比如一張圖片黑掉你：在圖片中嵌入惡意程序，這個正是使用了最低有效位平面算法，結合HTML5的canvas或者處理二進制數據的TypeArray，抽取出載體中隱藏的數據（如代碼）。隱寫的方式同樣需要解碼程序和動態執行，所以破解的方式和前者相同，在瀏覽器上下文中劫持替換關鍵函數調用的行為，改為文本輸出即可得到載體中隱藏的代碼。

混合加密，單個方法容易被破解，但組合起來就不會那么容易了，破解成本也會指數增長，例如 jdists 采用組合加密和嵌套加密的方式。

這些加密的方式都很容易通過對源代碼進行詞法分析、語法分析進行還原，首先將代碼的字符串轉換為抽象語法樹（Abstract Syntax Tree, AST）的數據形式，然后從語法樹的根節點開始，使用深度優先遍歷整棵樹的所有節點，根據節點上分析出來的指令逐個執行，直到腳本結束返回結果。這種方法大多數用于對代碼進行優化，例如最近Facebook開源了代碼優化工具 Prepack，可以自動消除冗余代碼，降低打包體積和執行時間，基本上就可以用來將這些加密的字符串進行還原，畢竟編碼這些字符串都是可以通過詞法語法推測出來的。

4. 編譯(compile)

Github上有一份清單記錄了所有Java擴展語言，這些語言都可以通過編譯器轉化為Java語言，這也是前端發展的一個趨勢，原來寫的html，css，Java已經開始變成了一個“中間語言”，而且越來越多的團隊也有了自己的一套前端編譯系統。Java越來越像Web中的匯編語言，特別是近些年Node的普及，讓前端變得越來越復雜，大量前端框架的出現，使得Java代碼可以通過手工編寫，也可以從另一種語言編譯而來，詳情參考幾年前Brendan Eich（Java之父）、Douglas Crockford（JSON之父），還有Mike Shaver（Mozilla技術副總裁）的郵件。通過編譯后的Java代碼越方便機器的理解，降低可讀性，在某一定角度上講，這也不愧為一種代碼保護措施。據說幾大科技巨頭正在醞釀給瀏覽器應用設計一款通用的字節碼標準——WebAssembly ，一旦這個設想得以實現，代碼保護將可以引入真正意義上的“加殼”或者虛擬機保護，對抗技術又將提升到一個新的臺階。目前在桌面端，使用 NW 框架可以Java應用程序的源代碼可以被編譯為本地代碼，在運行時通過NW動態還原出源代碼，但是這種方法目前會比正常的JS代碼慢30%左右。

5. 防止被調試

對代碼進行破解分析無非分為靜態分析和動態分析，如果對代碼進行混淆加密等形式操作，那么靜態分析就很麻煩了，對代碼調試跟蹤分析可以對代碼整體邏輯有一個宏觀的把控。例如首先判斷瀏覽器是否開啟了開發者工具控制臺（目前最完美的解決方案傳送門），如果檢測出控制臺開啟則堵塞Java執行或讓代碼異常跳出。另外Android 4.4及以上和iOS是支持webkit remote debug的，因此應該在debug模式下，設置代碼可以被debug，release模式下，禁止debug以保護數據安全。

6. 前后端協作

首先得強調的事情是不要在前端放敏感數據，前端容易破解，因此需要配合后端進行安全防護，例如微信小程序的登錄，必須利用授信的后端配合才能完成此項功能，另外在小程序的網絡請求中的referer是不可以設置的，其中 {appid} 為小程序的appid，通過驗證appid字段可以抵御一些直接的山寨，其次就是加快迭代速度更改代碼保護策略，這樣可以讓之前的分析失效，增加破解的成本。

以上就是對當前前端代碼安全進行的探索。

　　更多關于微信小程序開發內容，可以多關注hi小程序。