微信反编译（二）源码还原
概覽
我們知道，前端 Web 網頁編程采用的是?HTML + CSS + JS?這樣的組合，其中?HTML?是用來描頁面的結構，CSS?用來描述頁面的樣子，JS?通常用來處理頁面邏輯和用戶的交互。類似地，在小程序中也有同樣的角色，一個小程序工程主要包括如下幾類文件：
- .json?后綴的 JSON 配置文件
- .wxml?后綴的 WXML 模板文件
- .wxss?后綴的 WXSS 樣式文件
- .js?后綴的 JavaScript 腳本邏輯文件
例如“知識小集”的小程序源碼工程結構如下：
然而，根據上一篇文章介紹，對“知識小集”小程序的?.wxapkg?解包后得到如下文件：
主要包括?app-config.json,?app-service.js,?page-frame.html,?*.html,?資源文件?等，但這些文件已經被“編譯混淆”并重新整合壓縮，微信開發者工具并不能識別它們，我們無法直接對它們進行調試/編譯運行。
所以，我們先嘗試分析一下從?.wxapkg?提取出來的各個文件內容的結構及其用途，然后介紹如何用腳本工具把它們一鍵還原為“編譯”前的源碼，并在微信開發者工具中跑起來。
文件分析
本節主要以“知識小集”小程序的?.wxapkg?解包后的源碼文件為例，進行分析。
你也可以跳過本節的分析，直接看下一節介紹用腳本“反編譯”還原源碼。
app-config.json
小程序工程主要包括工具配置?project.config.json，全局配置?app.json?以及頁面配置?page.json?三類 JSON 配置文件。其中：
project.config.json?主要用于對開發者工具進行個性化配置以及包括小程序項目工程的一些基礎配置，所以它不會被“編譯”到?.wxapkg?包中；
app.json?是對當前小程序的全局配置，包括了小程序的所有頁面路徑、界面表現、網絡超時時間、底部 tab 等；
page.json?用于對每一個頁面的窗口表現進行配置，頁面中配置項會覆蓋?app.json?的?window?中相同的配置項。
因此“編譯”后的文件?app-config.json?其實就是?app.json?和各個頁面的配置文件的匯總，它的內容大致如下：
{
"page": {?// 各頁面配置
"pages/index/index.html": {?// 某一頁面地址
"window": {?// 某一頁面具體配置
"navigationBarTitleText":?"知識小集",
"enablePullDownRefresh":?true
}
},
// 此處省略...
},
"entryPagePath":?"pages/index/index.html",?// 小程序入口地址
"pages": ["pages/index/index",?"pages/detail/detail",?"pages/search/search"],?// 頁面列表
"global": {?// 全局頁面配置
"window": {
"navigationBarTextStyle":?"black",
"navigationBarTitleText":?"知識小集",
"navigationBarBackgroundColor":?"#F8F8F8",
"backgroundColor":?"#F8F8F8"
}
}
}
通過與原工程?app.json?和各頁面配置?page.json?內容的對比，我們可以得出?app-config.json?匯總文件的簡單整合規律，很容易把它拆分成“編譯”前對應的各?json?文件。
app-service.js
在小程序項目中?JS?文件負責交互邏輯，主要包括?app.js，每個頁面的?page.js，開發者自定義的?JS?文件和引入的第三方?JS?文件，在“編譯”后所有這些?JS?文件都會被匯總到?app-service.js?文件中，它的結構如下：
// 一些全局變量的聲明
var __wxAppData = {};
var __wxRoute;
var __wxRouteBegin;
var __wxAppCode__ = {};
var global = {};
var __wxAppCurrentFile__;
var Component = Component ||?function(){};
var definePlugin = definePlugin ||?function(){};
var requirePlugin = requirePlugin ||?function(){};
var Behavior = Behavior ||?function(){};
// 小程序編譯基礎庫版本
/*v0.6vv_20180125_fbi*/
global.__wcc_version__='v0.6vv_20180125_fbi';
global.__wcc_version_info__={"customComponents":true,"fixZeroRpx":true,"propValueDeepCopy":false};
// 工程中第三方或者自定義的一些 JS 源碼
define("utils/util.js",?function(require, module, exports, window,document,frames,self,location,navigator,localStorage,history,Caches,screen,alert,confirm,prompt,XMLHttpRequest,WebSocket,Reporter,webkit,WeixinJSCore) {
"use strict";
// ... 具體源碼內容
});
// ...
// app.js 源碼定義
define("app.js",?function(...) {
"use strict";
// ... app.js 源碼內容
});
require("app.js");
// 每個頁面對應的 JS 源碼定義
__wxRoute =?'pages/index/index';?// 頁面路由地址
__wxRouteBegin =?true;
define("pages/index/index.js",?function(...){
"use strict";
// ... page.js 源碼內容
});
require("pages/index/index.js");
在這個文件中，原有小程序工程中的每個?JS?文件都被?define?方法定義聲明，定義中包含?JS?文件的路徑和內容，如下：
define("path/to/xxx.js",?function(...){
"use strict";
// ... xxx.js 源碼內容
});
因此，我們同樣很容易提取這些?JS?文件源碼，并恢復至相應的路徑位置中。當然，這些?JS?文件中的內容經過混淆壓縮，我們可以使用?UglifyJS?這樣的工具進行美化，但仍很難還原一些原始變量名，不過基本不影響正常閱讀和使用。
page-frame.html
在小程序中使用?WXML?文件描述頁面的結構，WXSS?文件描述頁面的樣式。工程中有一個?app.wxss?文件用于定義一些全局的樣式，會自動被?import?到各個頁面中；另外每個頁面也都分別包含?page.wxml?和?page.wxss?用于描述其頁面的結構和樣式；同時，我們也會自定義一些公共的?xxxCommon.wxss?樣式文件和公共的?xxxTemplate.wxml?模板文件供一些頁面復用，一般在各自頁面的?page.wxss?和?page.wxml?中去?import。
當“編譯”小程序后，所有的?.wxml?文件和?app.wxss?及公共?xxxCommon.wxss?樣式文件的將被整合到?page-frame.html?文件中，而每個頁面的?page.wxss?樣式文件，將分別單獨在各自的路徑下生成一個?page.html?文件。
page-frame.html?文件的內容結構如下：
<!DOCTYPE html>
<html?lang="zh-CN">
<head>
<meta?charset="UTF-8"?/>
<meta?name="viewport"?content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0"?/>
<meta?http-equiv="Content-Security-Policy"?content="script-src 'self' 'unsafe-inline'">
<link?rel="icon"?href="data:image/ico;base64,aWNv">
<script>
// 一些全局變量的聲明
var?__pageFrameStartTime__ =?Date.now();
var?__webviewId__;
var?__wxAppCode__ = {};
var?__WXML_GLOBAL__ = {
entrys: {},
defines: {},
modules: {},
ops: [],
wxs_nf_init:?undefined,
total_ops:?0
};
// 小程序編譯基礎庫版本
/*v0.6vv_20180125_fbi*/
window.__wcc_version__ =?'v0.6vv_20180125_fbi';
window.__wcc_version_info__ = {
"customComponents":?true,
"fixZeroRpx":?true,
"propValueDeepCopy":?false
};
var?$gwxc
var?$gaic = {}
$gwx =?function(path, global)?{
// $gwx 方法定義（最核心）
}
var?BASE_DEVICE_WIDTH =?750;
var?isIOS = navigator.userAgent.match("iPhone");
var?deviceWidth =?window.screen.width ||?375;
var?deviceDPR =?window.devicePixelRatio ||?2;
function?checkDeviceWidth()?{
// checkDeviceWidth 方法定義
}
checkDeviceWidth()
var?eps =?1e-4;
function?transformRPX(number, newDeviceWidth)?{
// transformRPX 方法定義
}
var?setCssToHead =?function(file, _xcInvalid)?{
// setCssToHead 方法定義
}
setCssToHead([])();?// 先清空 Head 中的 CSS
setCssToHead([...]);?// 設置 app.wxss 的內容到 Head 中，其中 ... 為小程序工程中 app.wxss 的內容
var?__pageFrameEndTime__ =?Date.now()
</script>
</head>
<body>
<div></div>
</body>
</html>
相比其他文件，page-frame.html?比較復雜，微信把?.wxml?和部分?.wxss?直接“編譯”并混淆成?JS?代碼放入上述文件中，然后通過調用這些?JS?代碼來構造?Virtual-Dom，進而渲染頁面。
其中最核心的是?$gwx?和?setCssToHead?這兩個方法。
$gwx?用于通過?JS?代碼生成所有?.wxml?文件，其中每個?.wxml?文件的內容結構都在?$gwx?方法中被定義好并混淆了，我們只要傳給它頁面的?.wxml?路徑參數，即可獲取到每個?.wxml?的內容，再簡單加工一下即可還原成“編譯”前的內容。
在?$gwx?中有一個?x?數組用于存儲當前小程序都有哪些?.wxml?文件，例如，“知識小集”小程序的?x?值如下：
var x = ['./pages/detail/detail.wxml', '/towxml/entry.wxml', './pages/index/index.wxml', './pages/search/search.wxml', './towxml/entry.wxml', '/towxml/renderTemplate.wxml', './towxml/renderTemplate.wxml'];此時我們可以在?Chrome?中打開?page-frame.html?文件，然后在?Console?中輸入如下命令，即可得到?index.wxml?的內容（輸出一個?JS?對象，通過遍歷這個對象即可還原出?.wxml?的內容）
$gwx("./pages/index/index.wxml")setCssToHead?方法用于根據幾段被拆分的樣式字符串數組生成?.wxss?代碼并設置到?HTML?的?Head?中，同時，它還將所有被?import?引用的?.wxss?文件（公共?xxxCommon.wxss樣式文件）所對應的樣式數組內嵌在該方法中的?_C?變量中，并標記哪些文件引用了?_C?中數據。另外在?page-frame.html?文件的末尾，調用了該方法生成全局?app.wxss?的內容設置到?Head中。
因此，我們可以在每個調用?setCssToHead?方法的地方提取相應?.wxss?的內容并還原。
對于?page-frame.html?文件中?$gwx?和?setCssToHead?這兩個方法更詳細的分析，可以參考這篇文章。
此外，checkDeviceWidth?方法顧明思議，用于檢測屏幕的寬度，其檢測結果將用于?transformRPX?方法中將?rpx?單位轉換為?px?像素。
rpx?的全稱是?responsive pixel，它是小程序自己定義的一個尺寸單位，可以根據當前設備屏幕寬度進行自適應。小程序中規定，所有的設備屏幕寬度都為?750rpx，根據設備屏幕實際寬度的不同，1rpx所代表的實際像素值也不一樣。
*.html
上面提到，每個頁面的?page.wxss?樣式文件，“編譯”后將分別在各自的所在路徑下生成一個?page.html?文件，每個?page.html?的結構如下：
<style></style>
<page></page>
<script>
var?__setCssStartTime__ =?Date.now();
setCssToHead([...])()?// 設置 search.wxss 的內容
var?__setCssEndTime__ =?Date.now();
document.dispatchEvent(new?CustomEvent("generateFuncReady", {
detail: {
generateFunc: $gwx('./pages/search/search.wxml')
}
}))
</script>
在該文件中通過調用?setCssToHead?方法將?.wxss?樣式內容設置到?Head?中，所以同樣地，我們可以根據?setCssToHead?的調用參數提取每個頁面的?page.wxss。
資源文件
小程序工程中的圖片、音頻等資源文件在“編譯”后將直接被拷貝到?.wxapkg?包中，其原始的路徑也保留不變，因此我們可以直接使用。
“反編譯”
在上一節，我們完成了?.wxapkg?包幾乎所有文件內容的簡要分析。現在我們介紹一下如何通過?node.js?腳本幫我們還原出小程序的源碼。
在這里需要再次感謝?wxappUnpacker?作者提供的還原工具，讓我們可以“站在巨人的肩膀上”輕松地去完成“反編譯”。它的使用如下：
-
node wuConfig.js <path/to/app-config.json>?: 將?app-config.json?中的內容拆分成各個頁面所對應的?page.json和?app.json；
-
node wuJs.js <path/to/app-service.js>?: 將?app-service.js?拆分成一系列原先獨立的?JS?文件，并使用?Uglify-ES美化工具盡可能將代碼還原為“編譯”前的內容；
-
node wuWxml.js [-m] <path/to/page-frame.html>?: 從?page-frame.html?中提取并還原各頁面的?.wxml?和?app.wxss及公共?.wxss?樣式文件；
-
node wuWxss.js <path/to/unpack_dir>?: 該命令參數為?.wxapkg?解包后目錄，它將分析并從各個?page.html?中提取還原各頁面的?page.wxss?樣式文件；
同時，作者還提供了一鍵解包并還原的腳本，你只需要提供一個小程序的?.wxapkg?文件，然后執行如下命令：
node wuWxapkg.js [-d] <path/to/.wxapkg>此腳本就會自動將?.wxapkg?文件解包，并將包中相關的已被“編譯/混淆”的文件自動地恢復原狀（包括目錄結構）。
PS: 此工具依賴?uglify-es,?vm2,?esprima,?cssbeautify,?css-tree?等?node.js?包，所以你可能需要?npm install xxx?安裝這些依賴包才能正確執行。
更詳細的用法及相關問題請查閱該開源項目的 GitHub repo。
最后，我們在?微信開發者工具?中新建一個空小程序工程，并將上述還原后的相關目錄文件導入工程，即可編譯運行起來，如下圖為“知識小集”小程序的?.wxapkg?包還原后的代碼工程：
以上，大功告成！
總結
本文詳細分析了?.wxapkg?解包后的各文件結構，并介紹了如何通過腳本“一鍵還原”得到任意小程序的源碼。
對于一些簡單的，且使用微信官方介紹的原生開發方式開發的小程序，用上述工具基本可以直接還原得到可運行的源碼，但是對于一些邏輯復雜，或者使用?WePY、Vue?等一些框架開發的小程序，還原后的源碼可能會有一些小問題，需要我們人肉去分析解決。
后續
本文對小程序源碼“編譯”后的各文件內容結構及用途的分析相對比較零散，而且沒有對各文件的依賴關系及加載邏輯進行研究，后續我們再寫一些文章講解微信客戶端是如何解析加載小程序?.wxapkg?包并運行起來。
總結
以上是生活随笔為你收集整理的微信反编译（二）源码还原的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 程序员的日常生活
- 下一篇： 恒源智GPU云服务器