：Cocos2d-x腳本還原與批量解密)
簡介針對開發(fā)與逆向調(diào)試中常見的新版 JSC 加密腳本這份小巧工具包提供了現(xiàn)成的 Windows 解密方案適合前端工程師、爬蟲研究與軟件安全分析人員快速處理 JSC 變種免去手工搭建解密環(huán)境的麻煩。解壓后可直接運行主程序動態(tài)庫負責壓縮、網(wǎng)絡(luò)請求與核心解密邏輯配置文件和說明文檔則覆蓋參數(shù)調(diào)整與常見報錯排查用戶無需逐個補齊依賴適合不愿在環(huán)境搭建上浪費時間的使用者。資源共 112 個文件以 103 個 dll 為主另含 5 個 xml、2 個 txt、1 個 config、1 個 exe整包僅 1.57MB攜帶方便也便于保存到工作環(huán)境或內(nèi)網(wǎng)機器。已有 982 人學習下載尤其適合負責 JSC 解密與逆向分析的前端開發(fā)者、爬蟲工程師和安全測試人員收藏備用對需要反復驗證解密結(jié)果、離線處理 JSC 文件的場景這個小工具包能明顯縮短準備時間。1. 新版JSC解密工具到底在解什么先搞懂.jsc是怎么來的拿到一份名叫“新版JSC解密工具.rar”的資源先別急著雙擊解壓也別急著相信它一打開就能一鍵解密。JSC在 Cocos2d-x 項目里是 js 腳本被 V8 或 JavaScriptCore 編譯后的二進制產(chǎn)物很多游戲把熱更腳本、核心玩法邏輯都塞在 .jsc 文件里。JSC 解密工具的價值就是把這些編譯或加密過的文件還原成能讀、能改、能排查問題的 JS 源碼。新版工具通常解決了老版本不識別 Cocos 3.x 文件頭、密鑰搜索不全的問題。適合做游戲維護、資源恢復、熱更問題定位的開發(fā)者。需要提前說明所有解密操作請只針對你擁有或已獲授權(quán)的項目。2. 解密前的三分鐘鑒定把JSC版本和封裝方式認清楚我把 .jsc 文件拿到手第一件事不是找工具而是先看十六進制。社區(qū)里流傳的“新版JSC解密工具”大多只處理一種封裝方式搞不清版本直接用翻車概率超過一半。下面這套鑒定流程全程不需要依賴某個具體工具用 Hex 編輯器或者一條命令就能完成。2.1 用十六進制先驗明正身從文件頭識別Cocos版本先找一個最小的 jsc 文件執(zhí)行xxd -l 64 assets/main.jsc注意前 16 字節(jié)。如果能看到可讀的 ASCII 字符比如JSC、jsb、V8這種三個字母的 magic說明這個文件是引擎直接生成的 jsc 字節(jié)碼沒有套常見的 XXTEA 殼。這類文件嚴格說不是“加密過的”而是“編譯過的”很多通用解密工具會把它原樣復制出來或者只做字符串提取。如果前 16 字節(jié)完全沒有任何可讀 ASCII看起來像隨機字節(jié)就要懷疑外面套了自定義殼。絕大多數(shù)游戲資源包里出現(xiàn)的 jsc并不是純 V8 字節(jié)碼而是先用 XXTEA 把明文 JS 加密后再存成 .jsc 后綴。判斷依據(jù)很簡單直接打開是亂碼但長度和明文 JS 差距不大且文件大小基本都是 8 字節(jié)對齊。Cocos 版本差異在文件頭也很明顯。Cocos 2.x 多用 JavaScriptCoreCocos 3.x 在 Android 上默認走 V8。有些定制引擎還會改掉默認魔數(shù)所以我一般不會只看三個字符而是同時看第 4 到第 8 字節(jié)的版本區(qū)。新版 JSC 解密工具的一個重要改進就是能識別 Cocos 3.x 的頭部結(jié)構(gòu)而不像老工具那樣一上來就按 2.x 的格式剝偏移。想快速批量判斷目錄里所有 jsc 的類型可以用一段 Pythonimport pathlib import binascii for p in pathlib.Path(assets).rglob(*.jsc): head p.read_bytes()[:32] ascii_view .join(chr(b) if 32 b 127 else . for b in head) print(f{p}\t{binascii.hexlify(head[:16]).decode()}\t{ascii_view[:16]})這段代碼把每個 jsc 的前 32 字節(jié)打印成十六進制和可讀字符方便一眼篩出哪些是帶魔數(shù)的標準 jsc、哪些是看不出結(jié)構(gòu)的加密殼。binascii.hexlify負責把字節(jié)轉(zhuǎn)成十六進制字符串:16只取前 16 個字節(jié)防止輸出太長。這一步的目的不是解密而是給后面選擇工具參數(shù)提供依據(jù)。2.2 判斷是否套了XXTEA殼看熵和字符串密度標準明文 JS 是文本代碼中有大量function、var、this這類可讀字符串。引擎生成的 jsc 字節(jié)碼至少還能看到函數(shù)名片段。而 XXTEA 加密后的數(shù)據(jù)會把這些信息全部打散用strings掃不出幾個有意義的詞。用strings快速檢查strings assets/main.jsc | head -20如果輸出里只有零星幾個路徑或版本號說明文件很可能被加密過。如果想更精確一點可以計算文件的熵值原理是加密后的字節(jié)分布更均勻熵值徘徊在 7.9 左右明文 JS 的熵一般 4 到 6 之間。注意這不是絕對標準但作為快速篩查足夠了。import math import collections def entropy(data: bytes) - float: if not data: return 0.0 total len(data) counter collections.Counter(data) return -sum((count / total) * math.log2(count / total) for count in counter.values()) sample open(assets/main.jsc, rb).read() print(fentropy: {entropy(sample):.2f} bits/byte)這段代碼統(tǒng)計每個字節(jié)的出現(xiàn)頻率再按信息熵公式計算。熵越接近 8說明數(shù)據(jù)越像隨機密文如果加密殼還做了 ECB 模式的分組對齊熵值會非常高。新版 JSC 解密工具內(nèi)部通常也有一層類似判斷用來決定“這個文件是直接抄出來還是進 XXTEA 解密流程”。所以你自己先跑一遍能提前知道工具會走哪條分支避免解密后對著亂碼發(fā)呆。2.3 去找密鑰配置文件里的xxteaKey如果判斷結(jié)果是 XXTEA 殼下一步就是找 key。很多 Cocos 熱更項目會在配置里顯式寫出密鑰常見位置包括project.json、game.js、src/settings.js或者直接寫死在 Android 的libcocos2dlua.so的字符串常量里。先用文本搜索在資源包內(nèi)找一遍grep -r xxtea --include*.json --include*.js .能找到xxteaKey或key字段最好。找不到也別急著放棄很多游戲用的就是引擎源碼里帶的默認 XXTEA 密鑰只是換了個格式。新版工具做得比較省事的地方就是內(nèi)置了一份常見默認 key 列表你只需要在命令行里指定-k參數(shù)覆蓋它。如果沒有可用的 key后面所有解密動作都白搭這一點請先記牢。3. 把新版JSC解密工具跑起來從RAR解壓到批量還原的完整步驟搞清楚封裝類型之后才輪到工具本身。實際操作里第一道門檻往往不是解密而是怎么把這套從 RAR 里解出來的工具跑起來。很多人卡在解壓報錯連工具還沒見到就結(jié)束了。3.1 處理RAR分發(fā)包偽加密與解壓環(huán)境RAR 是個很常見的分發(fā)格式但拿到的“新版JSC解密工具.rar”未必都很規(guī)矩。分享者可能給壓縮包加了偽加密所謂偽加密只是在 RAR 頭部的加密標志位做了標記數(shù)據(jù)區(qū)本身沒加密。表現(xiàn)是雙擊提示需要密碼7-Zip 打開卻能看到完整文件列表拖出來時又報錯。遇到這種情況先不要急著猜密碼先用 7-Zip 的命令行測試一下7z t 新版JSC解密工具.rar如果提示文件列表正常只是某個文件校驗失敗多半是偽加密或下載不完整。我再強調(diào)一句如果是真密碼保護請找發(fā)布者要授權(quán)不要用暴力破解工具去撞既浪費時間也容易踩到帶木馬的偽破解包。合法場景下偽加密一般可以直接用 7-Zip 解出來。確認 RAR 完整后解壓到工作目錄mkdir -p work 7z x -y 新版JSC解密工具.rar -owork/tool解壓后先看內(nèi)容優(yōu)先找 Python 腳本而不是 exe。因為 exe 常被加殼、被殺毒軟件誤報而且你沒法知道它除了解密還做了什么。Python 版腳本可以一條條讀確認沒有危險操作再用。3.2 準備運行環(huán)境venv和xxtea依賴很多 jsc 解密工具都依賴 Python 的xxtea庫它是 XXTEA 算法的標準實現(xiàn)。我習慣單獨建一個虛擬環(huán)境防止污染系統(tǒng) Pythoncd work python -m venv .venv source .venv/bin/activate pip install xxtea在 Windows 上激活虛擬環(huán)境的命令是.venv\Scripts\activate。裝好后寫一個簡單的命令行入口腳本jsc_batch_decrypt.py放在工具目錄下。這樣以后換機器只要重新裝一遍 xxtea 就能跑不用依賴某個 GUI 工具。3.3 最小批量解密腳本遞歸處理整個資源目錄下面這段腳本是我常用做法的精簡版能處理兩類情況沒有殼的標準 jsc 直接復制套了 XXTEA 殼的嘗試解密。保留相對路徑方便解密后對照原文件位置。#!/usr/bin/env python3 # jsc_batch_decrypt.py # 批量還原 Cocos2d-x 的 .jsc 文件支持無殼原樣復制與 XXTEA 解密 import argparse import pathlib import sys try: import xxtea except ImportError: sys.exit(缺少 xxtea 依賴請先執(zhí)行: pip install xxtea) # 常見默認密鑰實際項目請用 -k 傳入自己的 key DEFAULT_KEYS [ b2dxLua, bcocos2d-x, ] def looks_like_raw_jsc(data: bytes) - bool: 通過頭部 magic 判斷是否為引擎直接生成的 jsc for magic in (bJSC, bjsb, bV8): if data.startswith(magic): return True return False def decrypt_one(src: pathlib.Path, dst: pathlib.Path, key: bytes, offset: int) - str: data src.read_bytes() if offset: data data[offset:] if looks_like_raw_jsc(data): dst.write_bytes(data) return raw-copy key_list [key] if key else DEFAULT_KEYS for candidate in key_list: try: plain xxtea.decrypt(data, candidate) except Exception: continue # 解密成功且像 JS 文本就寫入輸出文件 if plain and plain[:3] in (bvar, blet, bcon, bfun, b!, b\xef\xbb\xbf): dst.write_bytes(plain) return decrypted return failed def main(): ap argparse.ArgumentParser(description批量還原 JSC 文件僅限授權(quán)資源) ap.add_argument(input, typepathlib.Path, help輸入目錄例如 assets) ap.add_argument(-o, --output, typepathlib.Path, defaultpathlib.Path(out)) ap.add_argument(-k, --key, default, helpXXTEA 密鑰留空則嘗試默認列表) ap.add_argument(--offset, typeint, default0, help自定義頭字節(jié)數(shù)默認0) args ap.parse_args() key args.key.encode(utf-8) if args.key else b files list(args.input.rglob(*.jsc)) if not files: sys.exit(fno .jsc files found under {args.input}) for src in files: rel src.relative_to(args.input) dst args.output / rel.with_suffix(.js) dst.parent.mkdir(parentsTrue, exist_okTrue) status decrypt_one(src, dst, key, args.offset) print(f{status}\t{rel}) print(fdone: {len(files)} files) if __name__ __main__: main()腳本的邏輯很直接rglob(*.jsc)遞歸拿全目錄下所有 .jsc 文件looks_like_raw_jsc先識別前幾個字節(jié)符合魔數(shù)就直接復制因為這種文件本質(zhì)是字節(jié)碼剝不剝殼都不會變成文本不符合魔數(shù)再走 XXTEA 解密。xxtea.decrypt用的 key 是 bytes所以命令行傳來的字符串必須encode(utf-8)。解密成功的判斷是看開頭三個字節(jié)是不是var、let、fun這類 JS 文本特征如果 key 不對解密結(jié)果通常是隨機亂碼也不會被寫入。--offset參數(shù)針對的是自定義頭有些游戲在 jsc 前面追加了自己的版本號、時間戳正式數(shù)據(jù)被整體往后推。需要先用十六進制工具確認自定義頭長度比如看到前 8 字節(jié)是某個結(jié)構(gòu)體后面才是JSC魔數(shù)那 offset 就設(shè)置為 8。3.4 參數(shù)詳解版本、密鑰、偏移和輸出路徑實際執(zhí)行時我一般這樣跑python jsc_batch_decrypt.py assets -o output -k 你的key --offset 8如果拿不準 key先留空讓腳本嘗試默認列表python jsc_batch_decrypt.py assets -o output輸出里每一行會顯示狀態(tài)decrypted表示成功raw-copy表示原始 jscfailed表示 key 不對或封裝類型不在工具能力范圍內(nèi)。看到failed不要慌后面避坑章節(jié)有專門排查流程。下面這幾個參數(shù)是最常調(diào)的參數(shù)作用調(diào)錯會怎樣input資源根目錄腳本遞歸找 .jsc路徑不存在會直接報錯-o輸出目錄不寫默認生成out輸出和輸入混一起覆蓋原文件-kXXTEA 密鑰key 錯誤時解密結(jié)果全是亂碼--offset跳過自定義頭字節(jié)數(shù)偏移不對magic 識別失敗可能被強行解密后壞掉之前我吃過一次虧以為所有 jsc 都是無殼的把帶殼文件直接扔給引擎加載結(jié)果 Cocos 報了一堆SyntaxError。后來才養(yǎng)成先跑鑒定、再選參數(shù)的習慣。新版 JSC 解密工具雖然號稱通用但通用不等于自動它仍然需要你告訴它文件的真實封裝方式。4. 解密結(jié)果的驗證還原出的JS能不能直接跑解密腳本跑完只算完成一半。更關(guān)鍵的是驗證解密出來的 JS 是否可讀、可執(zhí)行。很多時候工具輸出了一堆 .js 文件但里面一半是亂碼另一半是套娃解出來的標準 jsc這種情況直接交給 Node.js 跑必然報錯。4.1 解密后先看文件頭是明文JS還是另一個jsc批量解密完成后先抽樣看幾個輸出文件file output/main.js head -c 200 output/main.js如果file顯示是ASCII text或Unicode text并且開頭是var、function、class說明這一步成功了。如果顯示data或者MS Windows這類奇怪結(jié)果說明解密產(chǎn)物不是文本需要進一步判斷。再用xxd看前 32 字節(jié)xxd -l 32 output/main.js如果開頭出現(xiàn)了JSC、jsb這類魔數(shù)說明原來文件是先編譯成 jsc、再套的 XXTEA。你的工具剝掉的是外層殼里面還是引擎字節(jié)碼。這種情況不要指望改成 .js 就能讀后面要換思路處理。新版 JSC 解密工具能準確識別這個狀態(tài)會提示你“已解密但結(jié)果不是 JS 源碼”。這屬于工具邊界不是 bug。4.2 用Node.js做語法冒煙和關(guān)鍵函數(shù)比對輸出文件疑似是明文 JS 后最直接的驗證辦法是用 Node.js 做語法檢查不執(zhí)行代碼node --check output/main.js--check只解析不執(zhí)行適合快速確認解密結(jié)果有沒有語法錯。Cocos 工程里的 JS 經(jīng)常用到cc、require這類運行時對象直接執(zhí)行會因為找不到上下文而報錯但語法檢查沒有這個煩惱。如果語法檢查通過再核對幾個關(guān)鍵函數(shù)名是否還在grep -n login\|init\|update\|onLoad output/main.js | head -20這一步是在驗證核心邏輯有沒有在解密過程中被截斷或破壞。XXTEA 解密如果 key 正確理論上恢復的是完整明文函數(shù)名、字符串都會原樣回來。如果你能搜到onLoad卻搜不到login可能是文件被拆分打包過或者這個 jsc 本身只是某個模塊還需要和其他文件拼接。也可以和備份的源碼做 diff。手里有舊版 JS 的話用diff -u old.js output/main.js看差異能直觀看出解密還原的準確度。沒有舊版也沒關(guān)系至少確認語法和關(guān)鍵函數(shù)都正常再考慮放回 Cocos 工程里跑。4.3 解密后亂碼的排查順序看到亂碼不要馬上怪工具按下面順序排查九成能定位先看failed狀態(tài)的文件是不是集中在某個子目錄。如果是說明這批 jsc 和主目錄的封裝方式不同可能來自不同渠道包或者個別文件被二次加密過。再嘗試用不同的 offset 重新跑從 0 開始然后 2、4、8、16 逐個試觀察輸出文件頭部是否出現(xiàn)魔數(shù)或 JS 文本。最后檢查 key 是否有隱藏字符比如從網(wǎng)頁復制密鑰時帶了個換行符肉眼看不到但 bytes 對比全部錯位。還有一種情況是解密后開頭有\(zhòng)xef\xbb\xbf也就是 UTF-8 BOM。腳本里我特意把\xef\xbb\xbf作為成功特征之一因為很多 Windows 下打包的 JS 都有 BOM它不影響 Node.js 執(zhí)行但會影響某些文本對比工具。5. 避坑與常見問題JSC解密工具翻車的五個現(xiàn)場這一章寫的是我見過、踩過最多的問題。每一條都按現(xiàn)象、原因、解決展開方便你遇到時直接對號入座。5.1 RAR偽加密解壓報錯但能看到文件列表現(xiàn)象雙擊“新版JSC解密工具.rar”提示需要密碼用 7-Zip 打開又能看到完整文件列表拖動解壓時卻報錯。原因RAR 頭部加密標志位為 1但數(shù)據(jù)區(qū)并沒有真實加密。這是發(fā)布者故意設(shè)置的偽加密主要防止網(wǎng)頁端直接預覽下載內(nèi)容資源本身沒有保護。解決先用7z t檢查完整性再用7z x嘗試解壓。如果最后還是報錯檢查壓縮包是不是通過網(wǎng)頁在線傳輸工具下載的文件大小是否為 0 或偏小。偽加密可以用修改 rar 頭標志位的方式修復但我更建議直接找發(fā)布者要一個沒加密的版本。不要隨便用網(wǎng)上流傳的“rar密碼移除”工具這類工具經(jīng)常打包木馬。5.2 工具版本與Cocos版本不匹配前半段正常后半段亂碼現(xiàn)象解密后文件能用編輯器打開開頭能看到var和部分函數(shù)名但讀到中后部全是亂碼函數(shù)不完整。原因這是老版 JSC 解密工具最典型的缺陷。Cocos 3.x 對 XXTEA 的 padding 規(guī)則做了調(diào)整或者自定義頭從 8 字節(jié)變成 16 字節(jié)。老工具固定按 2.x 的偏移截斷數(shù)據(jù)導致起始位置錯位前半段碰巧可讀后半段全部錯亂。解決換到新版工具或者在腳本里把--offset從 0 開始逐級嘗試。注意觀察每次解密后文件頭的變化如果從亂碼變成了以JSC或jsb開頭說明 offset 對了剝到了原始 jsc 層如果直接變成可讀 JS說明一層就解到了底。5.3 密鑰給錯所有文件都解密失敗或輸出亂碼現(xiàn)象批量腳本跑完80% 以上狀態(tài)是failed少量輸出文件打開后是無規(guī)律的二進制。原因項目用的不是默認 XXTEA 密鑰。引擎示例里的2dxLua只是默認值很多游戲會在構(gòu)建時改成隨機字符串。工具內(nèi)置的 key 字典覆蓋不到。解決去資源包配置里搜xxteaKey、key、code等字段。搜不到就把 Android 版 apk 解包在 so 文件里搜字符串。新版 JSC 解密工具一般會提供一個--key-file參數(shù)作用是傳入一個文本文件里面按行放候選 key腳本逐個嘗試。這個方法很笨但確實能解決大量實際項目。5.4 二次封裝解密一次后仍然是二進制字節(jié)碼現(xiàn)象腳本輸出decrypted但打開文件發(fā)現(xiàn)不是 JS 文本而是以JSC魔數(shù)開頭的字節(jié)碼。原因游戲團隊為了保證性能先把明文 js 編譯成引擎字節(jié)碼再對字節(jié)碼做 XXTEA 加密。工具剝掉 XXTEA 后得到的是標準 jsc。這是很多“通用解密工具”不處理的部分因為反編譯 V8 字節(jié)碼是另一個技術(shù)方向。解決先確認輸出文件頭如果是標準 jsc那就把它當作無殼字節(jié)碼。用支持 V8 bytecode 的逆向工具提取字符串、函數(shù)簽名和常量。這個方案不能完整恢復源碼但能恢復大部分業(yè)務(wù)邏輯閱讀價值。如果你真的只需要看可讀 JS只能去客戶端包里找是否有未加密的 js 熱更包或者找項目的原始發(fā)布包。5.5 工具本身被殺毒軟件查殺或exe跑不起來現(xiàn)象解壓后 exe 被殺毒軟件隔離雙擊提示缺少 DLL命令行窗口一閃而過。原因這類分發(fā)工具為了減小體積常用 UPX 或易語言加殼殺軟誤報率高。舊版工具依賴老版本 VC 運行庫新系統(tǒng)上缺 DLL 很常見。解決優(yōu)先選擇 Python 腳本版像前面寫的那段腳本就能完成大部分場景。exe 版只在虛擬機或隔離環(huán)境里跑跑之前先用7-Zip而不是 Windows 自帶解壓器打開某些系統(tǒng)自帶工具會攔截可執(zhí)行文件。如果你只是要解密自己項目里的 jsc強烈建議直接用 Python 腳本不要依賴來路不明的 exe畢竟這類工具本質(zhì)上是要讀取你工程里的核心文件安全性怎么強調(diào)都不過分。6. 把解密邏輯做成自己的工作流批量處理與最小改動驗證上面這些步驟每次手動跑一遍很累我現(xiàn)在的習慣是把它固化成一個固定流程先備份、再鑒定、再批量解密、最后做差異對比。值得投入做的一件事是在解密腳本里增加一個--dry-run模式。這個模式下腳本不解密只打印每個 jsc 的封裝類型、文件大小、建議參數(shù)。這樣拿到新資源包后先跑一遍 dry-run確認所有文件都在能力范圍內(nèi)再真正解密。加一個參數(shù)并不復雜核心邏輯是在decrypt_one之前提前做頭部判斷python jsc_batch_decrypt.py assets --dry-run輸出會像這樣xxtea assets/main.jsc offset0 keydefault raw assets/panel.jsc copy directly unknown assets/local.jsc need manual check我用這個習慣之后省了很多來回試錯的時間。以前經(jīng)常是批量解密完才發(fā)現(xiàn)有一半文件不在這套工具支持范圍內(nèi)白白浪費十幾分鐘?，F(xiàn)在 dry-run 先掃一遍哪些能解、哪些要換方案一目了然。另一個建議是每次解密前先對原始 .jsc 目錄生成一份 MD5 清單解密后再生成輸出目錄的 MD5。兩份清單比對能精確知道哪些文件被改動過哪些是原樣復制。尤其在工作需要交給別人復核時這個清單比口頭說明可靠得多。我自己吃過一次虧某次為了趕時間手動指定了一個從論壇里抄的 key結(jié)果那 key 是某個演示項目的不是線上項目解密出來的文件全部“成功”但全部不能跑。當時沒有做 dry-run也沒有做解密前后比對等發(fā)現(xiàn)問題時已經(jīng)改動了十幾個文件。后來我把 key 校驗寫成了硬性步驟如果解密后文件中可讀 ASCII 比例低于 5%直接判定為 key 錯誤不再向后處理。這個閾值你們可以根據(jù)項目實際情況調(diào)整。做 JSC 解密核心不是找到一把萬能的工具而是建立一套“識別——選擇參數(shù)——驗證——記錄”的流程。新版工具能幫你省掉一部分重復勞動但判斷和處理邊界還得自己盯。希望這套流程和踩坑記錄能幫到你。本文還有配套的精品資源點擊獲取 新版JSC解密工具實戰(zhàn)：Cocos2d-x腳本還原與批量解密
簡介針對開發(fā)與逆向調(diào)試中常見的新版 JSC 加密腳本這份小巧工具包提供了現(xiàn)成的 Windows 解密方案適合前端工程師、爬蟲研究與軟件安全分析人員快速處理 JSC 變種免去手工搭建解密環(huán)境的麻煩。解壓后可直接運行主程序動態(tài)庫負責壓縮、網(wǎng)絡(luò)請求與核心解密邏輯配置文件和說明文檔則覆蓋參數(shù)調(diào)整與常見報錯排查用戶無需逐個補齊依賴適合不愿在環(huán)境搭建上浪費時間的使用者。資源共 112 個文件以 103 個 dll 為主另含 5 個 xml、2 個 txt、1 個 config、1 個 exe整包僅 1.57MB攜帶方便也便于保存到工作環(huán)境或內(nèi)網(wǎng)機器。已有 982 人學習下載尤其適合負責 JSC 解密與逆向分析的前端開發(fā)者、爬蟲工程師和安全測試人員收藏備用對需要反復驗證解密結(jié)果、離線處理 JSC 文件的場景這個小工具包能明顯縮短準備時間。1. 新版JSC解密工具到底在解什么先搞懂.jsc是怎么來的拿到一份名叫“新版JSC解密工具.rar”的資源先別急著雙擊解壓也別急著相信它一打開就能一鍵解密。JSC在 Cocos2d-x 項目里是 js 腳本被 V8 或 JavaScriptCore 編譯后的二進制產(chǎn)物很多游戲把熱更腳本、核心玩法邏輯都塞在 .jsc 文件里。JSC 解密工具的價值就是把這些編譯或加密過的文件還原成能讀、能改、能排查問題的 JS 源碼。新版工具通常解決了老版本不識別 Cocos 3.x 文件頭、密鑰搜索不全的問題。適合做游戲維護、資源恢復、熱更問題定位的開發(fā)者。需要提前說明所有解密操作請只針對你擁有或已獲授權(quán)的項目。2. 解密前的三分鐘鑒定把JSC版本和封裝方式認清楚我把 .jsc 文件拿到手第一件事不是找工具而是先看十六進制。社區(qū)里流傳的“新版JSC解密工具”大多只處理一種封裝方式搞不清版本直接用翻車概率超過一半。下面這套鑒定流程全程不需要依賴某個具體工具用 Hex 編輯器或者一條命令就能完成。2.1 用十六進制先驗明正身從文件頭識別Cocos版本先找一個最小的 jsc 文件執(zhí)行xxd -l 64 assets/main.jsc注意前 16 字節(jié)。如果能看到可讀的 ASCII 字符比如JSC、jsb、V8這種三個字母的 magic說明這個文件是引擎直接生成的 jsc 字節(jié)碼沒有套常見的 XXTEA 殼。這類文件嚴格說不是“加密過的”而是“編譯過的”很多通用解密工具會把它原樣復制出來或者只做字符串提取。如果前 16 字節(jié)完全沒有任何可讀 ASCII看起來像隨機字節(jié)就要懷疑外面套了自定義殼。絕大多數(shù)游戲資源包里出現(xiàn)的 jsc并不是純 V8 字節(jié)碼而是先用 XXTEA 把明文 JS 加密后再存成 .jsc 后綴。判斷依據(jù)很簡單直接打開是亂碼但長度和明文 JS 差距不大且文件大小基本都是 8 字節(jié)對齊。Cocos 版本差異在文件頭也很明顯。Cocos 2.x 多用 JavaScriptCoreCocos 3.x 在 Android 上默認走 V8。有些定制引擎還會改掉默認魔數(shù)所以我一般不會只看三個字符而是同時看第 4 到第 8 字節(jié)的版本區(qū)。新版 JSC 解密工具的一個重要改進就是能識別 Cocos 3.x 的頭部結(jié)構(gòu)而不像老工具那樣一上來就按 2.x 的格式剝偏移。想快速批量判斷目錄里所有 jsc 的類型可以用一段 Pythonimport pathlib import binascii for p in pathlib.Path(assets).rglob(*.jsc): head p.read_bytes()[:32] ascii_view .join(chr(b) if 32 b 127 else . for b in head) print(f{p}\t{binascii.hexlify(head[:16]).decode()}\t{ascii_view[:16]})這段代碼把每個 jsc 的前 32 字節(jié)打印成十六進制和可讀字符方便一眼篩出哪些是帶魔數(shù)的標準 jsc、哪些是看不出結(jié)構(gòu)的加密殼。binascii.hexlify負責把字節(jié)轉(zhuǎn)成十六進制字符串:16只取前 16 個字節(jié)防止輸出太長。這一步的目的不是解密而是給后面選擇工具參數(shù)提供依據(jù)。2.2 判斷是否套了XXTEA殼看熵和字符串密度標準明文 JS 是文本代碼中有大量function、var、this這類可讀字符串。引擎生成的 jsc 字節(jié)碼至少還能看到函數(shù)名片段。而 XXTEA 加密后的數(shù)據(jù)會把這些信息全部打散用strings掃不出幾個有意義的詞。用strings快速檢查strings assets/main.jsc | head -20如果輸出里只有零星幾個路徑或版本號說明文件很可能被加密過。如果想更精確一點可以計算文件的熵值原理是加密后的字節(jié)分布更均勻熵值徘徊在 7.9 左右明文 JS 的熵一般 4 到 6 之間。注意這不是絕對標準但作為快速篩查足夠了。import math import collections def entropy(data: bytes) - float: if not data: return 0.0 total len(data) counter collections.Counter(data) return -sum((count / total) * math.log2(count / total) for count in counter.values()) sample open(assets/main.jsc, rb).read() print(fentropy: {entropy(sample):.2f} bits/byte)這段代碼統(tǒng)計每個字節(jié)的出現(xiàn)頻率再按信息熵公式計算。熵越接近 8說明數(shù)據(jù)越像隨機密文如果加密殼還做了 ECB 模式的分組對齊熵值會非常高。新版 JSC 解密工具內(nèi)部通常也有一層類似判斷用來決定“這個文件是直接抄出來還是進 XXTEA 解密流程”。所以你自己先跑一遍能提前知道工具會走哪條分支避免解密后對著亂碼發(fā)呆。2.3 去找密鑰配置文件里的xxteaKey如果判斷結(jié)果是 XXTEA 殼下一步就是找 key。很多 Cocos 熱更項目會在配置里顯式寫出密鑰常見位置包括project.json、game.js、src/settings.js或者直接寫死在 Android 的libcocos2dlua.so的字符串常量里。先用文本搜索在資源包內(nèi)找一遍grep -r xxtea --include*.json --include*.js .能找到xxteaKey或key字段最好。找不到也別急著放棄很多游戲用的就是引擎源碼里帶的默認 XXTEA 密鑰只是換了個格式。新版工具做得比較省事的地方就是內(nèi)置了一份常見默認 key 列表你只需要在命令行里指定-k參數(shù)覆蓋它。如果沒有可用的 key后面所有解密動作都白搭這一點請先記牢。3. 把新版JSC解密工具跑起來從RAR解壓到批量還原的完整步驟搞清楚封裝類型之后才輪到工具本身。實際操作里第一道門檻往往不是解密而是怎么把這套從 RAR 里解出來的工具跑起來。很多人卡在解壓報錯連工具還沒見到就結(jié)束了。3.1 處理RAR分發(fā)包偽加密與解壓環(huán)境RAR 是個很常見的分發(fā)格式但拿到的“新版JSC解密工具.rar”未必都很規(guī)矩。分享者可能給壓縮包加了偽加密所謂偽加密只是在 RAR 頭部的加密標志位做了標記數(shù)據(jù)區(qū)本身沒加密。表現(xiàn)是雙擊提示需要密碼7-Zip 打開卻能看到完整文件列表拖出來時又報錯。遇到這種情況先不要急著猜密碼先用 7-Zip 的命令行測試一下7z t 新版JSC解密工具.rar如果提示文件列表正常只是某個文件校驗失敗多半是偽加密或下載不完整。我再強調(diào)一句如果是真密碼保護請找發(fā)布者要授權(quán)不要用暴力破解工具去撞既浪費時間也容易踩到帶木馬的偽破解包。合法場景下偽加密一般可以直接用 7-Zip 解出來。確認 RAR 完整后解壓到工作目錄mkdir -p work 7z x -y 新版JSC解密工具.rar -owork/tool解壓后先看內(nèi)容優(yōu)先找 Python 腳本而不是 exe。因為 exe 常被加殼、被殺毒軟件誤報而且你沒法知道它除了解密還做了什么。Python 版腳本可以一條條讀確認沒有危險操作再用。3.2 準備運行環(huán)境venv和xxtea依賴很多 jsc 解密工具都依賴 Python 的xxtea庫它是 XXTEA 算法的標準實現(xiàn)。我習慣單獨建一個虛擬環(huán)境防止污染系統(tǒng) Pythoncd work python -m venv .venv source .venv/bin/activate pip install xxtea在 Windows 上激活虛擬環(huán)境的命令是.venv\Scripts\activate。裝好后寫一個簡單的命令行入口腳本jsc_batch_decrypt.py放在工具目錄下。這樣以后換機器只要重新裝一遍 xxtea 就能跑不用依賴某個 GUI 工具。3.3 最小批量解密腳本遞歸處理整個資源目錄下面這段腳本是我常用做法的精簡版能處理兩類情況沒有殼的標準 jsc 直接復制套了 XXTEA 殼的嘗試解密。保留相對路徑方便解密后對照原文件位置。#!/usr/bin/env python3 # jsc_batch_decrypt.py # 批量還原 Cocos2d-x 的 .jsc 文件支持無殼原樣復制與 XXTEA 解密 import argparse import pathlib import sys try: import xxtea except ImportError: sys.exit(缺少 xxtea 依賴請先執(zhí)行: pip install xxtea) # 常見默認密鑰實際項目請用 -k 傳入自己的 key DEFAULT_KEYS [ b2dxLua, bcocos2d-x, ] def looks_like_raw_jsc(data: bytes) - bool: 通過頭部 magic 判斷是否為引擎直接生成的 jsc for magic in (bJSC, bjsb, bV8): if data.startswith(magic): return True return False def decrypt_one(src: pathlib.Path, dst: pathlib.Path, key: bytes, offset: int) - str: data src.read_bytes() if offset: data data[offset:] if looks_like_raw_jsc(data): dst.write_bytes(data) return raw-copy key_list [key] if key else DEFAULT_KEYS for candidate in key_list: try: plain xxtea.decrypt(data, candidate) except Exception: continue # 解密成功且像 JS 文本就寫入輸出文件 if plain and plain[:3] in (bvar, blet, bcon, bfun, b!, b\xef\xbb\xbf): dst.write_bytes(plain) return decrypted return failed def main(): ap argparse.ArgumentParser(description批量還原 JSC 文件僅限授權(quán)資源) ap.add_argument(input, typepathlib.Path, help輸入目錄例如 assets) ap.add_argument(-o, --output, typepathlib.Path, defaultpathlib.Path(out)) ap.add_argument(-k, --key, default, helpXXTEA 密鑰留空則嘗試默認列表) ap.add_argument(--offset, typeint, default0, help自定義頭字節(jié)數(shù)默認0) args ap.parse_args() key args.key.encode(utf-8) if args.key else b files list(args.input.rglob(*.jsc)) if not files: sys.exit(fno .jsc files found under {args.input}) for src in files: rel src.relative_to(args.input) dst args.output / rel.with_suffix(.js) dst.parent.mkdir(parentsTrue, exist_okTrue) status decrypt_one(src, dst, key, args.offset) print(f{status}\t{rel}) print(fdone: {len(files)} files) if __name__ __main__: main()腳本的邏輯很直接rglob(*.jsc)遞歸拿全目錄下所有 .jsc 文件looks_like_raw_jsc先識別前幾個字節(jié)符合魔數(shù)就直接復制因為這種文件本質(zhì)是字節(jié)碼剝不剝殼都不會變成文本不符合魔數(shù)再走 XXTEA 解密。xxtea.decrypt用的 key 是 bytes所以命令行傳來的字符串必須encode(utf-8)。解密成功的判斷是看開頭三個字節(jié)是不是var、let、fun這類 JS 文本特征如果 key 不對解密結(jié)果通常是隨機亂碼也不會被寫入。--offset參數(shù)針對的是自定義頭有些游戲在 jsc 前面追加了自己的版本號、時間戳正式數(shù)據(jù)被整體往后推。需要先用十六進制工具確認自定義頭長度比如看到前 8 字節(jié)是某個結(jié)構(gòu)體后面才是JSC魔數(shù)那 offset 就設(shè)置為 8。3.4 參數(shù)詳解版本、密鑰、偏移和輸出路徑實際執(zhí)行時我一般這樣跑python jsc_batch_decrypt.py assets -o output -k 你的key --offset 8如果拿不準 key先留空讓腳本嘗試默認列表python jsc_batch_decrypt.py assets -o output輸出里每一行會顯示狀態(tài)decrypted表示成功raw-copy表示原始 jscfailed表示 key 不對或封裝類型不在工具能力范圍內(nèi)。看到failed不要慌后面避坑章節(jié)有專門排查流程。下面這幾個參數(shù)是最常調(diào)的參數(shù)作用調(diào)錯會怎樣input資源根目錄腳本遞歸找 .jsc路徑不存在會直接報錯-o輸出目錄不寫默認生成out輸出和輸入混一起覆蓋原文件-kXXTEA 密鑰key 錯誤時解密結(jié)果全是亂碼--offset跳過自定義頭字節(jié)數(shù)偏移不對magic 識別失敗可能被強行解密后壞掉之前我吃過一次虧以為所有 jsc 都是無殼的把帶殼文件直接扔給引擎加載結(jié)果 Cocos 報了一堆SyntaxError。后來才養(yǎng)成先跑鑒定、再選參數(shù)的習慣。新版 JSC 解密工具雖然號稱通用但通用不等于自動它仍然需要你告訴它文件的真實封裝方式。4. 解密結(jié)果的驗證還原出的JS能不能直接跑解密腳本跑完只算完成一半。更關(guān)鍵的是驗證解密出來的 JS 是否可讀、可執(zhí)行。很多時候工具輸出了一堆 .js 文件但里面一半是亂碼另一半是套娃解出來的標準 jsc這種情況直接交給 Node.js 跑必然報錯。4.1 解密后先看文件頭是明文JS還是另一個jsc批量解密完成后先抽樣看幾個輸出文件file output/main.js head -c 200 output/main.js如果file顯示是ASCII text或Unicode text并且開頭是var、function、class說明這一步成功了。如果顯示data或者MS Windows這類奇怪結(jié)果說明解密產(chǎn)物不是文本需要進一步判斷。再用xxd看前 32 字節(jié)xxd -l 32 output/main.js如果開頭出現(xiàn)了JSC、jsb這類魔數(shù)說明原來文件是先編譯成 jsc、再套的 XXTEA。你的工具剝掉的是外層殼里面還是引擎字節(jié)碼。這種情況不要指望改成 .js 就能讀后面要換思路處理。新版 JSC 解密工具能準確識別這個狀態(tài)會提示你“已解密但結(jié)果不是 JS 源碼”。這屬于工具邊界不是 bug。4.2 用Node.js做語法冒煙和關(guān)鍵函數(shù)比對輸出文件疑似是明文 JS 后最直接的驗證辦法是用 Node.js 做語法檢查不執(zhí)行代碼node --check output/main.js--check只解析不執(zhí)行適合快速確認解密結(jié)果有沒有語法錯。Cocos 工程里的 JS 經(jīng)常用到cc、require這類運行時對象直接執(zhí)行會因為找不到上下文而報錯但語法檢查沒有這個煩惱。如果語法檢查通過再核對幾個關(guān)鍵函數(shù)名是否還在grep -n login\|init\|update\|onLoad output/main.js | head -20這一步是在驗證核心邏輯有沒有在解密過程中被截斷或破壞。XXTEA 解密如果 key 正確理論上恢復的是完整明文函數(shù)名、字符串都會原樣回來。如果你能搜到onLoad卻搜不到login可能是文件被拆分打包過或者這個 jsc 本身只是某個模塊還需要和其他文件拼接。也可以和備份的源碼做 diff。手里有舊版 JS 的話用diff -u old.js output/main.js看差異能直觀看出解密還原的準確度。沒有舊版也沒關(guān)系至少確認語法和關(guān)鍵函數(shù)都正常再考慮放回 Cocos 工程里跑。4.3 解密后亂碼的排查順序看到亂碼不要馬上怪工具按下面順序排查九成能定位先看failed狀態(tài)的文件是不是集中在某個子目錄。如果是說明這批 jsc 和主目錄的封裝方式不同可能來自不同渠道包或者個別文件被二次加密過。再嘗試用不同的 offset 重新跑從 0 開始然后 2、4、8、16 逐個試觀察輸出文件頭部是否出現(xiàn)魔數(shù)或 JS 文本。最后檢查 key 是否有隱藏字符比如從網(wǎng)頁復制密鑰時帶了個換行符肉眼看不到但 bytes 對比全部錯位。還有一種情況是解密后開頭有\(zhòng)xef\xbb\xbf也就是 UTF-8 BOM。腳本里我特意把\xef\xbb\xbf作為成功特征之一因為很多 Windows 下打包的 JS 都有 BOM它不影響 Node.js 執(zhí)行但會影響某些文本對比工具。5. 避坑與常見問題JSC解密工具翻車的五個現(xiàn)場這一章寫的是我見過、踩過最多的問題。每一條都按現(xiàn)象、原因、解決展開方便你遇到時直接對號入座。5.1 RAR偽加密解壓報錯但能看到文件列表現(xiàn)象雙擊“新版JSC解密工具.rar”提示需要密碼用 7-Zip 打開又能看到完整文件列表拖動解壓時卻報錯。原因RAR 頭部加密標志位為 1但數(shù)據(jù)區(qū)并沒有真實加密。這是發(fā)布者故意設(shè)置的偽加密主要防止網(wǎng)頁端直接預覽下載內(nèi)容資源本身沒有保護。解決先用7z t檢查完整性再用7z x嘗試解壓。如果最后還是報錯檢查壓縮包是不是通過網(wǎng)頁在線傳輸工具下載的文件大小是否為 0 或偏小。偽加密可以用修改 rar 頭標志位的方式修復但我更建議直接找發(fā)布者要一個沒加密的版本。不要隨便用網(wǎng)上流傳的“rar密碼移除”工具這類工具經(jīng)常打包木馬。5.2 工具版本與Cocos版本不匹配前半段正常后半段亂碼現(xiàn)象解密后文件能用編輯器打開開頭能看到var和部分函數(shù)名但讀到中后部全是亂碼函數(shù)不完整。原因這是老版 JSC 解密工具最典型的缺陷。Cocos 3.x 對 XXTEA 的 padding 規(guī)則做了調(diào)整或者自定義頭從 8 字節(jié)變成 16 字節(jié)。老工具固定按 2.x 的偏移截斷數(shù)據(jù)導致起始位置錯位前半段碰巧可讀后半段全部錯亂。解決換到新版工具或者在腳本里把--offset從 0 開始逐級嘗試。注意觀察每次解密后文件頭的變化如果從亂碼變成了以JSC或jsb開頭說明 offset 對了剝到了原始 jsc 層如果直接變成可讀 JS說明一層就解到了底。5.3 密鑰給錯所有文件都解密失敗或輸出亂碼現(xiàn)象批量腳本跑完80% 以上狀態(tài)是failed少量輸出文件打開后是無規(guī)律的二進制。原因項目用的不是默認 XXTEA 密鑰。引擎示例里的2dxLua只是默認值很多游戲會在構(gòu)建時改成隨機字符串。工具內(nèi)置的 key 字典覆蓋不到。解決去資源包配置里搜xxteaKey、key、code等字段。搜不到就把 Android 版 apk 解包在 so 文件里搜字符串。新版 JSC 解密工具一般會提供一個--key-file參數(shù)作用是傳入一個文本文件里面按行放候選 key腳本逐個嘗試。這個方法很笨但確實能解決大量實際項目。5.4 二次封裝解密一次后仍然是二進制字節(jié)碼現(xiàn)象腳本輸出decrypted但打開文件發(fā)現(xiàn)不是 JS 文本而是以JSC魔數(shù)開頭的字節(jié)碼。原因游戲團隊為了保證性能先把明文 js 編譯成引擎字節(jié)碼再對字節(jié)碼做 XXTEA 加密。工具剝掉 XXTEA 后得到的是標準 jsc。這是很多“通用解密工具”不處理的部分因為反編譯 V8 字節(jié)碼是另一個技術(shù)方向。解決先確認輸出文件頭如果是標準 jsc那就把它當作無殼字節(jié)碼。用支持 V8 bytecode 的逆向工具提取字符串、函數(shù)簽名和常量。這個方案不能完整恢復源碼但能恢復大部分業(yè)務(wù)邏輯閱讀價值。如果你真的只需要看可讀 JS只能去客戶端包里找是否有未加密的 js 熱更包或者找項目的原始發(fā)布包。5.5 工具本身被殺毒軟件查殺或exe跑不起來現(xiàn)象解壓后 exe 被殺毒軟件隔離雙擊提示缺少 DLL命令行窗口一閃而過。原因這類分發(fā)工具為了減小體積常用 UPX 或易語言加殼殺軟誤報率高。舊版工具依賴老版本 VC 運行庫新系統(tǒng)上缺 DLL 很常見。解決優(yōu)先選擇 Python 腳本版像前面寫的那段腳本就能完成大部分場景。exe 版只在虛擬機或隔離環(huán)境里跑跑之前先用7-Zip而不是 Windows 自帶解壓器打開某些系統(tǒng)自帶工具會攔截可執(zhí)行文件。如果你只是要解密自己項目里的 jsc強烈建議直接用 Python 腳本不要依賴來路不明的 exe畢竟這類工具本質(zhì)上是要讀取你工程里的核心文件安全性怎么強調(diào)都不過分。6. 把解密邏輯做成自己的工作流批量處理與最小改動驗證上面這些步驟每次手動跑一遍很累我現(xiàn)在的習慣是把它固化成一個固定流程先備份、再鑒定、再批量解密、最后做差異對比。值得投入做的一件事是在解密腳本里增加一個--dry-run模式。這個模式下腳本不解密只打印每個 jsc 的封裝類型、文件大小、建議參數(shù)。這樣拿到新資源包后先跑一遍 dry-run確認所有文件都在能力范圍內(nèi)再真正解密。加一個參數(shù)并不復雜核心邏輯是在decrypt_one之前提前做頭部判斷python jsc_batch_decrypt.py assets --dry-run輸出會像這樣xxtea assets/main.jsc offset0 keydefault raw assets/panel.jsc copy directly unknown assets/local.jsc need manual check我用這個習慣之后省了很多來回試錯的時間。以前經(jīng)常是批量解密完才發(fā)現(xiàn)有一半文件不在這套工具支持范圍內(nèi)白白浪費十幾分鐘?，F(xiàn)在 dry-run 先掃一遍哪些能解、哪些要換方案一目了然。另一個建議是每次解密前先對原始 .jsc 目錄生成一份 MD5 清單解密后再生成輸出目錄的 MD5。兩份清單比對能精確知道哪些文件被改動過哪些是原樣復制。尤其在工作需要交給別人復核時這個清單比口頭說明可靠得多。我自己吃過一次虧某次為了趕時間手動指定了一個從論壇里抄的 key結(jié)果那 key 是某個演示項目的不是線上項目解密出來的文件全部“成功”但全部不能跑。當時沒有做 dry-run也沒有做解密前后比對等發(fā)現(xiàn)問題時已經(jīng)改動了十幾個文件。后來我把 key 校驗寫成了硬性步驟如果解密后文件中可讀 ASCII 比例低于 5%直接判定為 key 錯誤不再向后處理。這個閾值你們可以根據(jù)項目實際情況調(diào)整。做 JSC 解密核心不是找到一把萬能的工具而是建立一套“識別——選擇參數(shù)——驗證——記錄”的流程。新版工具能幫你省掉一部分重復勞動但判斷和處理邊界還得自己盯。希望這套流程和踩坑記錄能幫到你。本文還有配套的精品資源點擊獲取