簡介在游戲開發和運維中腳本加密與反編譯是常見需求。對于基于cocos2d-js和cocos2d-lua引擎的游戲發布包中的腳本常被編譯為字節碼或經XXTEA加密導致崩潰定位、資源復用和MOD開發困難。理解JSC/Lua字節碼結構及XXTEA加密原理是還原可讀代碼的關鍵。通過解包、文件頭識別、批量解密和反編譯工具鏈可高效處理此類產物。本文提供一套完整的解密套件實踐涵蓋工具選型、自動化流程及常見陷阱幫助開發者合法地分析自有或授權產品提升問題排查效率。 如果你做過 cocos2d-js 或者 cocos2d-lua 游戲大概率遇到過這種場景線上版本出了崩潰你打開打包機上的 release 包發現所有業務代碼都變成了一堆壓縮或加密過的腳本之前在源碼里能直接搜到的關鍵詞現在一個都搜不到。又或者你想給一個已經停止維護的老項目做 mod、做漢化卻發現資源和腳本包根本打不開。我自己就是在這種場景里反復折騰慢慢整理出一套針對 cocos2d-js/lua 游戲產物的“解密套件”。它不是一個單點工具而是由解包、文件識別、xxtea 解密、字節碼反編譯幾層組成的工作流用來把發布產物還原成能讀、能分析、能改的狀態輔助崩潰定位、mod 開發、漢化和資源復用。提前說清楚邊界這套東西的使用對象應當是你自己公司的產品、你合法擁有的軟件包或者經過授權允許做二次開發的 mod/漢化項目。不要去碰還在運營中的商業游戲更不要拿來做外掛、灰產或者盜版分發。解密是一種工程能力用在哪、怎么用底線自己心里有數。下面我把套件的整體思路、關鍵腳本和踩過的坑完整記錄下來希望對正在跟 cocos2d 系產品死磕的同學有幫助。1. 別急著解密先認清 js 和 lua 兩套產物的目錄結構很多人拿到一個游戲包就急著上工具結果解出來的東西要么是亂碼要么是空殼。原因很簡單你沒搞清楚這個版本到底是 cocos2d-js 還是 cocos2d-lua是 debug 包還是 release 包腳本是編譯過還是只是加密過。方向錯了后面所有操作都是白費。1.1 cocos2d-js 常見產物形態cocos2d-js 打包后Android APK 里通常能看到assets/目錄下邊再分src/和res/。src/放腳本res/放圖片、音頻、plist 等資源。開發階段你看到的是一堆.js源文件比如main.js、project.js、app.js。到了 release 階段如果構建配置里開了字節碼選項這些.js就會變成.jsc本質上是 JavaScriptCore 引擎的字節碼快照。還有一種常見情況項目開了 xxtea 加密但只對src/里的腳本加密res/下的資源還是明文。這時候你把res/里的圖片直接拖出來能看但src/里的腳本全都是亂碼。反過來也有團隊只加密資源不加密腳本所以第一步不是猜而是打開目錄結構挨個看。iOS 平臺的 cocos2d-js 略有不同解密后的包在Payload/xxx.app里資源通常被塞進Resources子目錄也可能整個被打成assets.pkg或類似的自定義包需要先在啟動流程里看引擎到底從哪個路徑讀取文件。1.2 cocos2d-lua 常見產物形態cocos2d-lua 的情況更復雜一點因為涉及 Lua 版本。老項目一般用 Lua 5.1新一些用的是 LuaJIT 2.0 或 2.1。打包后腳本目錄通常叫src/入口是main.lua其余業務腳本分布在src/app、src/scripts之類的地方。release 模式下lua 源文件會被編譯成.luac或者直接編譯為.lua后綴的二進制文件但文件頭已經變了。如果你在包里看到一個src/main.lua用編輯器打開是明文但同目錄下的app/里所有.lua都是亂碼別慌這很常見。有些團隊只把核心邏輯加密入口文件保留明文方便引擎啟動時拼接路徑和讀取初始化配置。另外cocos2d-lua 也經常把所有資源壓成一個 zip 文件比如assets.zip或data.zip引擎在首次啟動時自動解壓到可寫目錄。這種情況下你直接看 APK 里可能只有壓縮包真正的明文資源要到運行后才會出現得用模擬器、真機或直接解析 zip 的方式把那一層也解開。1.3 通過文件頭識別加密策略這一步是整個套件的地基。我會先在十六進制工具里過一遍可疑文件確認前幾個字節文件頭說明文本、window、var等明文 JS直接可讀1b 4c 75 61\x1bLuaLua 5.1/5.2 編譯產物1b 4c 4a\x1bLJLuaJIT 編譯產物58 58 54 45 41XXTEA帶 xxtea 簽名的加密文件純隨機字節無規律可能是 xxtea也可能是自定義加密這個識別表看起來簡單但非常關鍵。它能幫你判斷該走哪個分支明文 JS 直接美化Lua 字節碼走反編譯帶簽名或亂碼走 xxtea 解密。版本不同、加密有無都會讓同一個套件走完全不一樣的路徑。2. 加密層到底套了幾層jsc、luac 和 xxtea 的原理拆解解密最大的誤區是認為只要破解一層就完事了。實際上一個 release 包往往在文件層面做了多次處理腳本先被編譯成字節碼然后整個文件再被 xxtea 加密最后還可能有自定義魔數頭。所以你得學會區分“哪層是字節碼哪層是加密哪層只是容器格式”。2.1 JSC 字節碼不是普通壓縮而是引擎級編譯cocos2d-js 的.jsc是 JavaScriptCore 引擎的字節碼快照。它和 JS 源碼最大的區別在于變量名、函數名、注釋、空行全部消失只剩下字節碼指令和常量表。理論上一個.jsc可以通過 JSC 直接執行但不能像源碼一樣直接閱讀。JSC 字節碼還和 JavaScriptCore 版本強相關不同 iOS 系統或不同版本 Android WebView 的字節碼可能不通用。這也是為什么很多 cocos2d-js 游戲在做熱更新時需要區分平臺和引擎版本去生成.jsc。反編譯.jsc的難點就在這社區工具要么只支持某個特定版本要么還原結果非常殘缺。我遇到過的另一個情況是很多團隊的 “jsc” 其實只是把 JS 源碼用 xxtea 加密后的文件后綴還叫.jsc。你解密后拿到的不是字節碼而是明文源碼。這種情況下所謂“反編譯”根本不存在只要走完 xxtea 解密再用格式美化工具一整理代碼就回來了。2.2 Lua/LuaJIT 字節碼版本錯一個就寸步難行Lua 字節碼比 JS 字節碼要“規矩”很多因為它有一套相對穩定的指令集格式。\x1bLua開頭的文件是標準 Lua 編譯器產物后面跟著版本號、格式版本、字節序、int 類型大小等 header 信息。\x1bLJ開頭的則是 LuaJIT 的字節碼LuaJIT 的指令集設計更底層跟標準 Lua 差異很大。反編譯這些字節碼時工具必須和編譯時的 Lua 版本精確匹配。Lua 5.1 的字節碼你用面向 5.2 的工具去解基本是一堆垃圾LuaJIT 2.0 和 2.1 的字節碼格式也完全不同。所以套件里一定要保留“按版本分類的工具鏈”而不是一個 unluac 通吃所有文件。實際操作中最好先讀取文件頭里的版本號再自動路由到對應工具這樣才不會被大量報錯淹沒。2.3 xxtea 加密層如何區分“文件加密”和“代碼編譯”xxtea 是 cocos2d-x 體系里最常用的對稱加密算法使用方式在引擎的FileUtils中配置。典型代碼是這樣的FileUtils::getInstance()-setXXTEAKeyAndSign(2dxLua, 6, XXTEA, 5);2dxLua是密鑰XXTEA是簽名。引擎在處理文件時若檢測到簽名就會用密鑰解密加密數據。默認密鑰在大量老項目里都沒有改過所以很多人打包后以為自己做了加密保護實際上密鑰還是社區公開的默認值等于只穿了件透明外套。文件加密和代碼編譯是兩條獨立軸線一個文件可以既被編譯成字節碼又被 xxtea 加密也可以只是被 xxtea 加密但內部還是明文 JS/Lua。遇到.jsc或.luac文件時先判斷它是否帶有 xxtea 簽名或亂碼特征有的話先解密再判斷解密后是文本源碼還是字節碼。這個順序不能搞反。3. 套件的具體構成解包工具、xxtea 腳本和反編譯器的選型我整理套件時沒有追求一個“全自動一鍵逆向”的工具因為根本沒有這種東西。我的做法是把每一步拆開用最趁手的小工具拼成流水線每種工具只解決一個問題然后靠腳本把它們串起來。3.1 先把安裝包拆開我常用的幾個解包手段拿到 APK 或 IPA 后解包是第一步。Linux 和 macOS 上直接用unzip就能處理大多數安裝包Windows 下可以選 Bandizip 或 7-Zip。APK 本質是一個 zip 容器直接改擴展名也能看到內容但如果包含了 APK 簽名校驗打開時會提示文件被破壞這時可以用apktool先解資源、再解代碼。解出原始資源后很多 cocos2d 游戲并不是直接把資源放在assets/而是打成一個自定義包這時需要進一步解析。最簡單的辦法是在模擬器里把游戲跑起來等引擎首次啟動自動解壓完再進入應用沙箱目錄把解密后的資源復制出來。模擬器的文件系統經常可以直接瀏覽比如/data/data/包名/files下就是引擎運行時的可寫目錄。這個方式比純靜態解包省力得多因為引擎自己已經把 xxtea 解密和 zip 解壓都做完了。3.2 一個能直接用的 xxtea 解密腳本如果只能靜態處理文件就需要自己寫 xxtea 解密腳本。我用的是 Python 加xxtea庫接口不復雜。下面這段是核心邏輯實際使用時按你安裝的庫微調接口即可import xxtea import sys # 密鑰和簽名從引擎配置或二進制中定位得到 key b2dxLua sign bXXTEA def decrypt_file(input_path, output_path): with open(input_path, rb) as f: data f.read() # 剝離引擎自定義簽名如果沒有簽名就直接解密 if sign and data.startswith(sign): data data[len(sign):] # 有些構建會在簽名后附帶4字節長度或版本號按需跳過 # if data[:4] b\x01\x00\x00\x00: # data data[4:] try: # 這里參數取決于 xxtea 庫的封裝常見是 padding 可選 plain xxtea.decrypt(data, key, paddingFalse) except Exception as e: print(f[-] {input_path}: {e}) return with open(output_path, wb) as f: f.write(plain) print(f[] {input_path} - {output_path}) if __name__ __main__: if len(sys.argv) 3: print(fUsage: {sys.argv[0]} input output) sys.exit(1) decrypt_file(sys.argv[1], sys.argv[2])注意xxtea庫的 API 不同版本差異很大有的庫不提供padding參數有的庫支持sign參數。所以這段代碼更多是思路參考你實際裝好庫之后用兩條已知明文和密文對照調一下即可。密鑰定位是另一個核心問題。如果游戲沒有改默認密鑰那就直接用2dxLua。如果改了可以在 APK 的 so 文件或 iOS 二進制里搜索可讀字符串常能找到xxtea或相關配置。再不行就在反編譯出來的 Java/Kotlin 代碼里搜setXXTEAKeyAndSign的調用鏈。這一步涉及到具體包結構沒法給一個通殺方案得按項目來。3.3 luac/LuaJIT 反編譯器怎么選Lua 字節碼的反編譯工具相對成熟但仍遠談不上完美。我常用的工具列表工具適用目標優點缺點unluac標準 Lua 5.1/5.2/5.3/5.4 字節碼還原度較高支持 LuaJIT 2.0 部分版本對異常字節碼容易直接崩掉ljdLuaJIT 2.0/2.1 字節碼專門針對 LuaJIT還原后的偽代碼可讀性一般luadecLua 5.1/5.2 字節碼對函數定義還原較好項目活躍度一般版本兼容有限luajit-decompLuaJIT 字節碼輕量很多場景下只輸出反匯編不還原成偽代碼實際使用中lua 5.1 的unluac是我遇到最多能成功還原出接近源碼結構的工具。LuaJIT 的反編譯要難得多尤其 2.1 的字節碼許多情況下只能得到可讀性較差的反匯編或者直接還原失敗。所以如果你確認目標是 LuaJIT 2.1我建議提前調整預期能還原出“可讀的偽代碼”就已經算成功了。3.4 jsc 和混淆 JS 的還原思路JS 這邊的情況比較簡單如果能拿到解密后的 JS 明文交給 Prettier 或 js-beautify 就能恢復縮進和換行閱讀性提升很大。如果代碼還被做了混淆比如變量名縮短、字符串拼接、控制流扁平化那就需要借助 AST 工具慢慢還原。對于真正的.jsc字節碼社區可用的反編譯工具有限且基本要跟 JSC 版本精確對應。我通常的路線是先確認它確實不是 xxtea 加密文件然后去對應版本的 JSC 反編譯項目里找可執行文件如果工具不支持就退回字節碼反匯編級別看常量表和指令。另一種更務實的方法是在運行時用引擎日志或 hook 機制從內存中導出已經被 JSC 解析過的字符串這比硬啃字節碼高效得多。4. 零到一搭一套自動化解密工作流單點工具有了接下來要把它們串成一套流程。目標很簡單輸入一個目錄自動識別文件類型自動解密/反編譯輸出結構清晰的結果。4.1 入口文件定位先看啟動腳本和引擎配置遇到一個陌生包我習慣先看根目錄下有沒有main.lua、main.js或project.json這類入口文件。入口文件里通常寫明了腳本目錄、資源目錄和初始場景。這一步能幫你快速了解項目的代碼組織方式也能判斷它用的是哪套加密邏輯。比如 cocos2d-lua 的main.lua里常會有對src/和res/的路徑拼接還可能在config.lua里加載全局配置。cocos2d-js 的project.json會聲明jsList、engine、resourceRoot等關鍵字段。把這些信息抓出來你就知道該把解析重點放在哪個目錄。4.2 寫一個批量解密腳本單文件處理顯然不夠用。我的套件里有一個批量腳本遍歷目標目錄根據文件頭自動決定處理方式最終輸出到decrypted/目錄#!/bin/bash find $1 -type f \( -name *.jsc -o -name *.luac -o -name *.lua -o -name *.js -o -name *.bytes \) | while read f; do python3 tools/decrypt_one.py $f decrypted/${f#*/} donedecrypt_one.py的核心邏輯是讀取文件頭分類到不同分支明文 JS 直接復制帶XXTEA簽名的先解密\x1bLua調 unluac\x1bLJ調 ljd。這樣一條命令就能把整個包處理完。當然批量腳本也有副作用比如有些資源文件其實是二進制數據但不是腳本誤判會導致無意義的報錯。所以我會在腳本里加白名單和黑名單只處理我關心的目錄。4.3 重打包不只是替換文件那么簡單如果你把解密工具鏈用于 mod 或漢化那最后往往會面臨重打包。APK 重打包后必須重新簽名否則 Android 不會安裝。iOS 這邊更麻煩要重簽名、重打 IPA還要處理描述文件和設備信任問題。對于還在運營的游戲修改過的包很可能觸發服務器的完整性校驗所以我的建議是重打包只用于單機、測試或已授權項目千萬別拿它去碰在線游戲。另一個思路是不重打包而是利用引擎的 search path 機制。很多 cocos2d 游戲運行時允許從外部可寫目錄讀取同名文件覆蓋內置資源這意味著模擬器或 root 設備上你只要把解密后的文件放到正確位置游戲就會優先加載免去了重簽名和過校驗的麻煩。5. 實操中最容易踩的五個坑這些坑是我自己在反復解包中積累的不是看文檔能看出來的。每一條都對應過一次至少半小時的排錯過程。5.1 字節碼版本和引擎版本錯位解包一個 cocos2d-lua 老游戲發現unluac怎么跑都報錯檢查文件頭是\x1bLua沒錯版本號也匹配 Lua 5.1但依然失敗。后來發現引擎編譯字節碼時可能開啟了 “去掉調試信息” 或 “strip” 選項導致工具解析不了。這不是工具壞了而是字節碼里沒有足夠的調試符號很多反編譯器在缺乏upvalue或局部變量表時就會放棄。解決思路是換一種能容忍缺失信息的工具或者直接理解它反匯編出來的指令。遇到這種項目我會先看指令流里能不能還原函數調用關系再手動標出關鍵分支。5.2 密鑰是動態拼接的不是一串靜態字符串很多項目不會傻到把密鑰一次性寫死而是拆成幾段在初始化時拼接。這樣你在二進制里直接搜2dxLua搜不到搜XXTEA也找不到完整簽名。我遇到過一個項目密鑰是1234 abcd 版本號版本號正好來自配置文件所以得先讀配置再拼出完整 key才能解開腳本。這類動態密鑰在分析時要多留一個心眼不要只搜字符串還要看setXXTEAKeyAndSign的調用位置去追 key 的來源。如果反編譯后的 Java/Kotlin 代碼可讀直接在調用鏈上搜索字符串拼接邏輯通常很快。5.3 LuaJIT 反編譯結果的“偽可讀”陷阱LuaJIT 反編譯出來的偽代碼很多情況下語法上是可讀的但語義可能變化很大。比如局部變量數量對不上、循環結構被展開、函數調用順序被調換。這會讓新手誤以為自己拿到的是可信源碼于是照著改結果一跑就崩。我的經驗是反編譯結果只能作為理解和參考不能作為直接修改的基礎。真要修改盡量在同一份字節碼上做小范圍改動或者干脆用基于字節碼的 patch而不要試圖重寫整段偽代碼。5.4 jsc 還原后的變量名全部丟失JavaScriptCore 字節碼反編譯回來的 JS變量名大概率是a、b、c這類占位符甚至可能只是一堆臨時寄存器名。你很難從這些變量名里猜出業務含義。所以我一般不會糾結于還原完整變量名而是先靠字符串常量定位業務邏輯比如搜索報錯提示、服務器接口路徑、本地存儲 key 等。字符串在字節碼常量表里通常保留得很完整這比代碼結構還原容易得多。5.5 解密工具處理大文件的性能問題一鍵批處理可能會遇到性能問題尤其是 unluac 和 ljd 這類基于指令級解析的工具對超大 Lua 函數非常吃力。某個項目的一個副本模塊文件有幾十 MB單文件處理花了好幾分鐘而且內存占用極高。后來我把腳本改成按文件頭做預過濾跳過明顯的資源文件并且對超過閾值的大文件單獨分線程處理才算能跑完整個包。日常使用中我還會給批量腳本加一個日志輸出記錄每個文件的處理時長和結果狀態。這樣一旦某個文件卡住我能立刻定位而不是看著終端窗口一直滾動到失控。6. 這套套件的使用邊界和長期維護建議最后這部分我想聊一些更根本的東西。工具寫出來容易但怎么用、怎么長期維護才是真正決定它能陪你走多遠的關鍵。6.1 搞清楚你手中“解密權”的范圍我會反復強調這一點只有當你對目標包體擁有合法授權時解密和反編譯才是正當的工程行為。自己公司的產品、已經獲得源碼或資源使用權的項目、公開的、明確授權可二創的 mod 社區項目這些都沒問題。但如果是別人正在運營的商業游戲你去解包、扒腳本、試圖改收費邏輯或繞過安全驗證那就越界了。從技術角度講今天的加密手段也在不斷升級單純靠解密套件去對抗商業級安全方案不僅效率低而且風險完全不成比例。作為從業者我更建議把時間花在真正能創造價值的地方比如用這套工具去理解引擎內部機制、優化自研項目性能、或者做有意思的 mod 創作。6.2 維護套件的經驗解密套件本質上是一個長期積累的過程不是寫完就一勞永逸。我的習慣是把所有工具腳本放到獨立倉庫按照引擎版本和 Lua 版本分目錄每個目錄里記錄測試過的樣本和對應結果。這樣當我下一次拿到類似版本的項目直接查找歷史記錄不用重新踩一遍坑。另外我會把每次遇到的加密變體都補充進識別規則里。比如某次發現文件頭不是 xxtea 簽名而是一個 4 字節長度前綴加 xxtea 數據我就會在decrypt_one.py里加一個分支。這個更新迭代的過程其實就是套件真正有價值的地方。最后一個小建議別追求“一套腳本通吃所有游戲”。每個項目都有自己的怪癖與其寫一個充滿各種條件分支的重型框架不如保持核心功能簡單、插件化遇到新類型時單獨加一個模塊。我自己吃過過度設計的虧把腳本抽象得面目全非結果遇到新項目反而改不動了。工具是拿來用的不是拿來表演架構藝術的。本文還有配套的精品資源點擊獲取 cocos2d-js/lua游戲腳本解密套件：從解包到反編譯的完整實踐
簡介在游戲開發和運維中腳本加密與反編譯是常見需求。對于基于cocos2d-js和cocos2d-lua引擎的游戲發布包中的腳本常被編譯為字節碼或經XXTEA加密導致崩潰定位、資源復用和MOD開發困難。理解JSC/Lua字節碼結構及XXTEA加密原理是還原可讀代碼的關鍵。通過解包、文件頭識別、批量解密和反編譯工具鏈可高效處理此類產物。本文提供一套完整的解密套件實踐涵蓋工具選型、自動化流程及常見陷阱幫助開發者合法地分析自有或授權產品提升問題排查效率。 如果你做過 cocos2d-js 或者 cocos2d-lua 游戲大概率遇到過這種場景線上版本出了崩潰你打開打包機上的 release 包發現所有業務代碼都變成了一堆壓縮或加密過的腳本之前在源碼里能直接搜到的關鍵詞現在一個都搜不到。又或者你想給一個已經停止維護的老項目做 mod、做漢化卻發現資源和腳本包根本打不開。我自己就是在這種場景里反復折騰慢慢整理出一套針對 cocos2d-js/lua 游戲產物的“解密套件”。它不是一個單點工具而是由解包、文件識別、xxtea 解密、字節碼反編譯幾層組成的工作流用來把發布產物還原成能讀、能分析、能改的狀態輔助崩潰定位、mod 開發、漢化和資源復用。提前說清楚邊界這套東西的使用對象應當是你自己公司的產品、你合法擁有的軟件包或者經過授權允許做二次開發的 mod/漢化項目。不要去碰還在運營中的商業游戲更不要拿來做外掛、灰產或者盜版分發。解密是一種工程能力用在哪、怎么用底線自己心里有數。下面我把套件的整體思路、關鍵腳本和踩過的坑完整記錄下來希望對正在跟 cocos2d 系產品死磕的同學有幫助。1. 別急著解密先認清 js 和 lua 兩套產物的目錄結構很多人拿到一個游戲包就急著上工具結果解出來的東西要么是亂碼要么是空殼。原因很簡單你沒搞清楚這個版本到底是 cocos2d-js 還是 cocos2d-lua是 debug 包還是 release 包腳本是編譯過還是只是加密過。方向錯了后面所有操作都是白費。1.1 cocos2d-js 常見產物形態cocos2d-js 打包后Android APK 里通常能看到assets/目錄下邊再分src/和res/。src/放腳本res/放圖片、音頻、plist 等資源。開發階段你看到的是一堆.js源文件比如main.js、project.js、app.js。到了 release 階段如果構建配置里開了字節碼選項這些.js就會變成.jsc本質上是 JavaScriptCore 引擎的字節碼快照。還有一種常見情況項目開了 xxtea 加密但只對src/里的腳本加密res/下的資源還是明文。這時候你把res/里的圖片直接拖出來能看但src/里的腳本全都是亂碼。反過來也有團隊只加密資源不加密腳本所以第一步不是猜而是打開目錄結構挨個看。iOS 平臺的 cocos2d-js 略有不同解密后的包在Payload/xxx.app里資源通常被塞進Resources子目錄也可能整個被打成assets.pkg或類似的自定義包需要先在啟動流程里看引擎到底從哪個路徑讀取文件。1.2 cocos2d-lua 常見產物形態cocos2d-lua 的情況更復雜一點因為涉及 Lua 版本。老項目一般用 Lua 5.1新一些用的是 LuaJIT 2.0 或 2.1。打包后腳本目錄通常叫src/入口是main.lua其余業務腳本分布在src/app、src/scripts之類的地方。release 模式下lua 源文件會被編譯成.luac或者直接編譯為.lua后綴的二進制文件但文件頭已經變了。如果你在包里看到一個src/main.lua用編輯器打開是明文但同目錄下的app/里所有.lua都是亂碼別慌這很常見。有些團隊只把核心邏輯加密入口文件保留明文方便引擎啟動時拼接路徑和讀取初始化配置。另外cocos2d-lua 也經常把所有資源壓成一個 zip 文件比如assets.zip或data.zip引擎在首次啟動時自動解壓到可寫目錄。這種情況下你直接看 APK 里可能只有壓縮包真正的明文資源要到運行后才會出現得用模擬器、真機或直接解析 zip 的方式把那一層也解開。1.3 通過文件頭識別加密策略這一步是整個套件的地基。我會先在十六進制工具里過一遍可疑文件確認前幾個字節文件頭說明文本、window、var等明文 JS直接可讀1b 4c 75 61\x1bLuaLua 5.1/5.2 編譯產物1b 4c 4a\x1bLJLuaJIT 編譯產物58 58 54 45 41XXTEA帶 xxtea 簽名的加密文件純隨機字節無規律可能是 xxtea也可能是自定義加密這個識別表看起來簡單但非常關鍵。它能幫你判斷該走哪個分支明文 JS 直接美化Lua 字節碼走反編譯帶簽名或亂碼走 xxtea 解密。版本不同、加密有無都會讓同一個套件走完全不一樣的路徑。2. 加密層到底套了幾層jsc、luac 和 xxtea 的原理拆解解密最大的誤區是認為只要破解一層就完事了。實際上一個 release 包往往在文件層面做了多次處理腳本先被編譯成字節碼然后整個文件再被 xxtea 加密最后還可能有自定義魔數頭。所以你得學會區分“哪層是字節碼哪層是加密哪層只是容器格式”。2.1 JSC 字節碼不是普通壓縮而是引擎級編譯cocos2d-js 的.jsc是 JavaScriptCore 引擎的字節碼快照。它和 JS 源碼最大的區別在于變量名、函數名、注釋、空行全部消失只剩下字節碼指令和常量表。理論上一個.jsc可以通過 JSC 直接執行但不能像源碼一樣直接閱讀。JSC 字節碼還和 JavaScriptCore 版本強相關不同 iOS 系統或不同版本 Android WebView 的字節碼可能不通用。這也是為什么很多 cocos2d-js 游戲在做熱更新時需要區分平臺和引擎版本去生成.jsc。反編譯.jsc的難點就在這社區工具要么只支持某個特定版本要么還原結果非常殘缺。我遇到過的另一個情況是很多團隊的 “jsc” 其實只是把 JS 源碼用 xxtea 加密后的文件后綴還叫.jsc。你解密后拿到的不是字節碼而是明文源碼。這種情況下所謂“反編譯”根本不存在只要走完 xxtea 解密再用格式美化工具一整理代碼就回來了。2.2 Lua/LuaJIT 字節碼版本錯一個就寸步難行Lua 字節碼比 JS 字節碼要“規矩”很多因為它有一套相對穩定的指令集格式。\x1bLua開頭的文件是標準 Lua 編譯器產物后面跟著版本號、格式版本、字節序、int 類型大小等 header 信息。\x1bLJ開頭的則是 LuaJIT 的字節碼LuaJIT 的指令集設計更底層跟標準 Lua 差異很大。反編譯這些字節碼時工具必須和編譯時的 Lua 版本精確匹配。Lua 5.1 的字節碼你用面向 5.2 的工具去解基本是一堆垃圾LuaJIT 2.0 和 2.1 的字節碼格式也完全不同。所以套件里一定要保留“按版本分類的工具鏈”而不是一個 unluac 通吃所有文件。實際操作中最好先讀取文件頭里的版本號再自動路由到對應工具這樣才不會被大量報錯淹沒。2.3 xxtea 加密層如何區分“文件加密”和“代碼編譯”xxtea 是 cocos2d-x 體系里最常用的對稱加密算法使用方式在引擎的FileUtils中配置。典型代碼是這樣的FileUtils::getInstance()-setXXTEAKeyAndSign(2dxLua, 6, XXTEA, 5);2dxLua是密鑰XXTEA是簽名。引擎在處理文件時若檢測到簽名就會用密鑰解密加密數據。默認密鑰在大量老項目里都沒有改過所以很多人打包后以為自己做了加密保護實際上密鑰還是社區公開的默認值等于只穿了件透明外套。文件加密和代碼編譯是兩條獨立軸線一個文件可以既被編譯成字節碼又被 xxtea 加密也可以只是被 xxtea 加密但內部還是明文 JS/Lua。遇到.jsc或.luac文件時先判斷它是否帶有 xxtea 簽名或亂碼特征有的話先解密再判斷解密后是文本源碼還是字節碼。這個順序不能搞反。3. 套件的具體構成解包工具、xxtea 腳本和反編譯器的選型我整理套件時沒有追求一個“全自動一鍵逆向”的工具因為根本沒有這種東西。我的做法是把每一步拆開用最趁手的小工具拼成流水線每種工具只解決一個問題然后靠腳本把它們串起來。3.1 先把安裝包拆開我常用的幾個解包手段拿到 APK 或 IPA 后解包是第一步。Linux 和 macOS 上直接用unzip就能處理大多數安裝包Windows 下可以選 Bandizip 或 7-Zip。APK 本質是一個 zip 容器直接改擴展名也能看到內容但如果包含了 APK 簽名校驗打開時會提示文件被破壞這時可以用apktool先解資源、再解代碼。解出原始資源后很多 cocos2d 游戲并不是直接把資源放在assets/而是打成一個自定義包這時需要進一步解析。最簡單的辦法是在模擬器里把游戲跑起來等引擎首次啟動自動解壓完再進入應用沙箱目錄把解密后的資源復制出來。模擬器的文件系統經常可以直接瀏覽比如/data/data/包名/files下就是引擎運行時的可寫目錄。這個方式比純靜態解包省力得多因為引擎自己已經把 xxtea 解密和 zip 解壓都做完了。3.2 一個能直接用的 xxtea 解密腳本如果只能靜態處理文件就需要自己寫 xxtea 解密腳本。我用的是 Python 加xxtea庫接口不復雜。下面這段是核心邏輯實際使用時按你安裝的庫微調接口即可import xxtea import sys # 密鑰和簽名從引擎配置或二進制中定位得到 key b2dxLua sign bXXTEA def decrypt_file(input_path, output_path): with open(input_path, rb) as f: data f.read() # 剝離引擎自定義簽名如果沒有簽名就直接解密 if sign and data.startswith(sign): data data[len(sign):] # 有些構建會在簽名后附帶4字節長度或版本號按需跳過 # if data[:4] b\x01\x00\x00\x00: # data data[4:] try: # 這里參數取決于 xxtea 庫的封裝常見是 padding 可選 plain xxtea.decrypt(data, key, paddingFalse) except Exception as e: print(f[-] {input_path}: {e}) return with open(output_path, wb) as f: f.write(plain) print(f[] {input_path} - {output_path}) if __name__ __main__: if len(sys.argv) 3: print(fUsage: {sys.argv[0]} input output) sys.exit(1) decrypt_file(sys.argv[1], sys.argv[2])注意xxtea庫的 API 不同版本差異很大有的庫不提供padding參數有的庫支持sign參數。所以這段代碼更多是思路參考你實際裝好庫之后用兩條已知明文和密文對照調一下即可。密鑰定位是另一個核心問題。如果游戲沒有改默認密鑰那就直接用2dxLua。如果改了可以在 APK 的 so 文件或 iOS 二進制里搜索可讀字符串常能找到xxtea或相關配置。再不行就在反編譯出來的 Java/Kotlin 代碼里搜setXXTEAKeyAndSign的調用鏈。這一步涉及到具體包結構沒法給一個通殺方案得按項目來。3.3 luac/LuaJIT 反編譯器怎么選Lua 字節碼的反編譯工具相對成熟但仍遠談不上完美。我常用的工具列表工具適用目標優點缺點unluac標準 Lua 5.1/5.2/5.3/5.4 字節碼還原度較高支持 LuaJIT 2.0 部分版本對異常字節碼容易直接崩掉ljdLuaJIT 2.0/2.1 字節碼專門針對 LuaJIT還原后的偽代碼可讀性一般luadecLua 5.1/5.2 字節碼對函數定義還原較好項目活躍度一般版本兼容有限luajit-decompLuaJIT 字節碼輕量很多場景下只輸出反匯編不還原成偽代碼實際使用中lua 5.1 的unluac是我遇到最多能成功還原出接近源碼結構的工具。LuaJIT 的反編譯要難得多尤其 2.1 的字節碼許多情況下只能得到可讀性較差的反匯編或者直接還原失敗。所以如果你確認目標是 LuaJIT 2.1我建議提前調整預期能還原出“可讀的偽代碼”就已經算成功了。3.4 jsc 和混淆 JS 的還原思路JS 這邊的情況比較簡單如果能拿到解密后的 JS 明文交給 Prettier 或 js-beautify 就能恢復縮進和換行閱讀性提升很大。如果代碼還被做了混淆比如變量名縮短、字符串拼接、控制流扁平化那就需要借助 AST 工具慢慢還原。對于真正的.jsc字節碼社區可用的反編譯工具有限且基本要跟 JSC 版本精確對應。我通常的路線是先確認它確實不是 xxtea 加密文件然后去對應版本的 JSC 反編譯項目里找可執行文件如果工具不支持就退回字節碼反匯編級別看常量表和指令。另一種更務實的方法是在運行時用引擎日志或 hook 機制從內存中導出已經被 JSC 解析過的字符串這比硬啃字節碼高效得多。4. 零到一搭一套自動化解密工作流單點工具有了接下來要把它們串成一套流程。目標很簡單輸入一個目錄自動識別文件類型自動解密/反編譯輸出結構清晰的結果。4.1 入口文件定位先看啟動腳本和引擎配置遇到一個陌生包我習慣先看根目錄下有沒有main.lua、main.js或project.json這類入口文件。入口文件里通常寫明了腳本目錄、資源目錄和初始場景。這一步能幫你快速了解項目的代碼組織方式也能判斷它用的是哪套加密邏輯。比如 cocos2d-lua 的main.lua里常會有對src/和res/的路徑拼接還可能在config.lua里加載全局配置。cocos2d-js 的project.json會聲明jsList、engine、resourceRoot等關鍵字段。把這些信息抓出來你就知道該把解析重點放在哪個目錄。4.2 寫一個批量解密腳本單文件處理顯然不夠用。我的套件里有一個批量腳本遍歷目標目錄根據文件頭自動決定處理方式最終輸出到decrypted/目錄#!/bin/bash find $1 -type f \( -name *.jsc -o -name *.luac -o -name *.lua -o -name *.js -o -name *.bytes \) | while read f; do python3 tools/decrypt_one.py $f decrypted/${f#*/} donedecrypt_one.py的核心邏輯是讀取文件頭分類到不同分支明文 JS 直接復制帶XXTEA簽名的先解密\x1bLua調 unluac\x1bLJ調 ljd。這樣一條命令就能把整個包處理完。當然批量腳本也有副作用比如有些資源文件其實是二進制數據但不是腳本誤判會導致無意義的報錯。所以我會在腳本里加白名單和黑名單只處理我關心的目錄。4.3 重打包不只是替換文件那么簡單如果你把解密工具鏈用于 mod 或漢化那最后往往會面臨重打包。APK 重打包后必須重新簽名否則 Android 不會安裝。iOS 這邊更麻煩要重簽名、重打 IPA還要處理描述文件和設備信任問題。對于還在運營的游戲修改過的包很可能觸發服務器的完整性校驗所以我的建議是重打包只用于單機、測試或已授權項目千萬別拿它去碰在線游戲。另一個思路是不重打包而是利用引擎的 search path 機制。很多 cocos2d 游戲運行時允許從外部可寫目錄讀取同名文件覆蓋內置資源這意味著模擬器或 root 設備上你只要把解密后的文件放到正確位置游戲就會優先加載免去了重簽名和過校驗的麻煩。5. 實操中最容易踩的五個坑這些坑是我自己在反復解包中積累的不是看文檔能看出來的。每一條都對應過一次至少半小時的排錯過程。5.1 字節碼版本和引擎版本錯位解包一個 cocos2d-lua 老游戲發現unluac怎么跑都報錯檢查文件頭是\x1bLua沒錯版本號也匹配 Lua 5.1但依然失敗。后來發現引擎編譯字節碼時可能開啟了 “去掉調試信息” 或 “strip” 選項導致工具解析不了。這不是工具壞了而是字節碼里沒有足夠的調試符號很多反編譯器在缺乏upvalue或局部變量表時就會放棄。解決思路是換一種能容忍缺失信息的工具或者直接理解它反匯編出來的指令。遇到這種項目我會先看指令流里能不能還原函數調用關系再手動標出關鍵分支。5.2 密鑰是動態拼接的不是一串靜態字符串很多項目不會傻到把密鑰一次性寫死而是拆成幾段在初始化時拼接。這樣你在二進制里直接搜2dxLua搜不到搜XXTEA也找不到完整簽名。我遇到過一個項目密鑰是1234 abcd 版本號版本號正好來自配置文件所以得先讀配置再拼出完整 key才能解開腳本。這類動態密鑰在分析時要多留一個心眼不要只搜字符串還要看setXXTEAKeyAndSign的調用位置去追 key 的來源。如果反編譯后的 Java/Kotlin 代碼可讀直接在調用鏈上搜索字符串拼接邏輯通常很快。5.3 LuaJIT 反編譯結果的“偽可讀”陷阱LuaJIT 反編譯出來的偽代碼很多情況下語法上是可讀的但語義可能變化很大。比如局部變量數量對不上、循環結構被展開、函數調用順序被調換。這會讓新手誤以為自己拿到的是可信源碼于是照著改結果一跑就崩。我的經驗是反編譯結果只能作為理解和參考不能作為直接修改的基礎。真要修改盡量在同一份字節碼上做小范圍改動或者干脆用基于字節碼的 patch而不要試圖重寫整段偽代碼。5.4 jsc 還原后的變量名全部丟失JavaScriptCore 字節碼反編譯回來的 JS變量名大概率是a、b、c這類占位符甚至可能只是一堆臨時寄存器名。你很難從這些變量名里猜出業務含義。所以我一般不會糾結于還原完整變量名而是先靠字符串常量定位業務邏輯比如搜索報錯提示、服務器接口路徑、本地存儲 key 等。字符串在字節碼常量表里通常保留得很完整這比代碼結構還原容易得多。5.5 解密工具處理大文件的性能問題一鍵批處理可能會遇到性能問題尤其是 unluac 和 ljd 這類基于指令級解析的工具對超大 Lua 函數非常吃力。某個項目的一個副本模塊文件有幾十 MB單文件處理花了好幾分鐘而且內存占用極高。后來我把腳本改成按文件頭做預過濾跳過明顯的資源文件并且對超過閾值的大文件單獨分線程處理才算能跑完整個包。日常使用中我還會給批量腳本加一個日志輸出記錄每個文件的處理時長和結果狀態。這樣一旦某個文件卡住我能立刻定位而不是看著終端窗口一直滾動到失控。6. 這套套件的使用邊界和長期維護建議最后這部分我想聊一些更根本的東西。工具寫出來容易但怎么用、怎么長期維護才是真正決定它能陪你走多遠的關鍵。6.1 搞清楚你手中“解密權”的范圍我會反復強調這一點只有當你對目標包體擁有合法授權時解密和反編譯才是正當的工程行為。自己公司的產品、已經獲得源碼或資源使用權的項目、公開的、明確授權可二創的 mod 社區項目這些都沒問題。但如果是別人正在運營的商業游戲你去解包、扒腳本、試圖改收費邏輯或繞過安全驗證那就越界了。從技術角度講今天的加密手段也在不斷升級單純靠解密套件去對抗商業級安全方案不僅效率低而且風險完全不成比例。作為從業者我更建議把時間花在真正能創造價值的地方比如用這套工具去理解引擎內部機制、優化自研項目性能、或者做有意思的 mod 創作。6.2 維護套件的經驗解密套件本質上是一個長期積累的過程不是寫完就一勞永逸。我的習慣是把所有工具腳本放到獨立倉庫按照引擎版本和 Lua 版本分目錄每個目錄里記錄測試過的樣本和對應結果。這樣當我下一次拿到類似版本的項目直接查找歷史記錄不用重新踩一遍坑。另外我會把每次遇到的加密變體都補充進識別規則里。比如某次發現文件頭不是 xxtea 簽名而是一個 4 字節長度前綴加 xxtea 數據我就會在decrypt_one.py里加一個分支。這個更新迭代的過程其實就是套件真正有價值的地方。最后一個小建議別追求“一套腳本通吃所有游戲”。每個項目都有自己的怪癖與其寫一個充滿各種條件分支的重型框架不如保持核心功能簡單、插件化遇到新類型時單獨加一個模塊。我自己吃過過度設計的虧把腳本抽象得面目全非結果遇到新項目反而改不動了。工具是拿來用的不是拿來表演架構藝術的。本文還有配套的精品資源點擊獲取