在上一篇文章 《微信小程序“反編譯”實戰（一）：解包》 中，我們詳細介紹了如何獲取某一個小程序的 .wxapkg 包，以及分析了 .wxapkg 包的結構，最后通過腳本解壓獲取包中的文件：小程序“編譯”后的代碼文件和資源文件，但是由于這些文件大部分被混淆了，可讀性很差，所以本文將進一步分析，盡可能地把 .wxapkg 包的內容還原為“編譯”前的內容。

注：本文包含一部分源碼分析，由于手機屏幕較小，閱讀體驗可能不佳，建議在電腦上瀏覽。

特別感謝：下文使用的還原工具來自于 GitHub 上的開源項目 wxappUnpacker ，在此特別感謝原作者的無私貢獻。

概覽

我們知道，前端 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 這樣的工具進行美化，但仍很難還原一些原始變量名，不過基本不影響正常閱讀和使用。