簡介本資源是面向Android開發(fā)者、安全研究人員與逆向工程師的實(shí)用型反編譯工具集合聚焦APK結(jié)構(gòu)解析、代碼還原與動態(tài)行為分析等核心需求覆蓋從靜態(tài)解包到動態(tài)插樁的完整逆向工作流。壓縮包共42個文件包含15個核心jar工具如dex2jar、baksmali、jadx-core、10個Windows批處理腳本bat與10個Linux Shell腳本sh用于一鍵調(diào)用各工具鏈另有apk示例文件、簽名密鑰pk8/pem、許可證及README說明文檔總大小13.49MB開箱即用且目錄組織清晰。目前已有175人學(xué)習(xí)下載資源提供經(jīng)實(shí)測可用的全版本工具組合含jd-gui-windows-1.4.0、baksmali-2.1.3、dex2jar-2.0等并內(nèi)置HelloWorld.apk測試樣例與標(biāo)準(zhǔn)化簽名工具鏈顯著降低環(huán)境配置門檻助力快速開展代碼審計、漏洞分析或開發(fā)技巧學(xué)習(xí)。1. Android反編譯工具包不是“一鍵破解”而是逆向工程的最小可行工作臺你手頭有個APK想看它怎么調(diào)用攝像頭、為什么啟動就崩潰、第三方SDK埋了哪些權(quán)限、或者驗證自己寫的混淆規(guī)則是否生效——這時候打開網(wǎng)上搜到的“Android反編譯神器.exe”雙擊運(yùn)行彈出個帶紅藍(lán)按鈕的GUI拖進(jìn)去APK三秒后生成一堆亂碼Java文件……然后你就卡住了MainActivity$1.smali是啥R$layout.class里全是0x7f0c004a資源根本對不上AndroidManifest.xml顯示的權(quán)限比你代碼里聲明的多兩條但來源查不到。這不是反編譯失敗是缺少工具鏈上下文。Android反編譯工具包本質(zhì)是一套分層協(xié)作的命令行工具組合底層靠dex2jar把.dex拆成可讀Java字節(jié)碼非源碼中間用jadx做語義還原變量名、控制流、字符串解密頂層靠apktool拆資源、重建AndroidManifest.xml、保留原始資源ID映射。三者不互替缺一不可。新手常誤以為“jadx能看Java就不用apktool”結(jié)果改完代碼重新打包時資源找不到、R.java編譯報錯老手則會把baksmali單獨(dú)拎出來修smali里的跳轉(zhuǎn)邏輯因為某些加固殼會篡改if-eqz指令但放過字符串解密邏輯。這個工具包適合三類人安全審計員查隱私合規(guī)、App開發(fā)者分析競品熱更新機(jī)制、測試工程師定位閃退前最后調(diào)用棧。它不承諾“還原100%源碼”但能確保你拿到可調(diào)試、可修改、可重打包的最小可用中間態(tài)——這才是真實(shí)產(chǎn)線里每天在做的事。2. 搭建可復(fù)現(xiàn)的本地反編譯環(huán)境從JDK到j(luò)adx-gui的6步閉環(huán)反編譯不是裝個軟件點(diǎn)幾下而是構(gòu)建一條輸入APK → 輸出可編輯源碼資源清單 → 修改后能重新簽名安裝的完整流水線。我堅持用命令行輕量GUI組合因為所有步驟都可寫進(jìn)CI腳本且避免GUI隱藏參數(shù)導(dǎo)致的環(huán)境差異。以下是我當(dāng)前2024年穩(wěn)定版在Ubuntu 22.04 / Windows WSL2 / macOS Sonoma上統(tǒng)一驗證過的流程所有工具均開源、無依賴沖突、不需管理員權(quán)限。2.1 安裝JDK 17并驗證字節(jié)碼兼容性Android 12編譯的APK默認(rèn)使用targetSdkVersion31其.dex文件采用DEXv39格式要求反編譯工具運(yùn)行在JDK 17非JDK 8。若用舊JDKjadx會靜默跳過部分方法apktool解包時提示Unsupported major.minor version。# Ubuntu/WSL2推薦用sdkman管理多版本JDK curl -s https://get.sdkman.io | bash source $HOME/.sdkman/bin/sdkman-init.sh sdk install java 17.0.10-tem sdk use java 17.0.10-tem # 驗證關(guān)鍵指標(biāo)必須同時滿足兩項 java -version # 輸出應(yīng)含 17.0.10 和 Temurin javac -version # 同樣為17否則jadx編譯插件會失敗提示不要用系統(tǒng)自帶OpenJDK如Ubuntu的openjdk-17-jdk其javap工具對invoke-custom指令解析有bug會導(dǎo)致jadx反編譯Lambda表達(dá)式時生成空方法體。Temurin或Zulu是經(jīng)過Android工具鏈實(shí)測的發(fā)行版。2.2 下載并校驗核心工具三件套所有工具必須從官方GitHub Release下載非第三方鏡像用SHA256校驗防篡改。注意apktool需配套apktool.jar和aapt2二進(jìn)制jadx需區(qū)分jadx-cli命令行和jadx-gui圖形界面dex2jar已基本被jadx取代僅在處理超大APK100MB時作為備選。工具下載地址截至2024-06校驗命令關(guān)鍵用途apktool_2.9.3.jarhttps://github.com/iBotPeaches/Apktool/releases/download/v2.9.3/apktool_2.9.3.jarsha256sum apktool_2.9.3.jar | grep 8a1e7b2c反編譯資源、重建AndroidManifest、保留資源ID映射aapt2-8.4.0-11317113-linuxhttps://github.com/android/platform_frameworks_base/releases/download/android-14.0.0_r20/aapt2-8.4.0-11317113-linuxsha256sum aapt2-8.4.0-11317113-linux | grep f3d9a1e替換apktool內(nèi)置aapt解決Android 14資源編譯失敗jadx-1.4.7.ziphttps://github.com/skylot/jadx/releases/download/v1.4.7/jadx-1.4.7.zipsha256sum jadx-1.4.7.zip | grep 5c2b8a1主力Java反編譯器支持D8/R8混淆還原、字符串解密# Linux/macOS一鍵下載校驗Windows請用PowerShell對應(yīng)命令 wget https://github.com/iBotPeaches/Apktool/releases/download/v2.9.3/apktool_2.9.3.jar echo 8a1e7b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1 apktool_2.9.3.jar | sha256sum -c # 將aapt2放入PATH關(guān)鍵否則apktool rebuild失敗 chmod x aapt2-8.4.0-11317113-linux sudo mv aapt2-8.4.0-11317113-linux /usr/local/bin/aapt22.3 構(gòu)建標(biāo)準(zhǔn)反編譯工作流一個命令拆出全部可用資產(chǎn)不要用jadx-gui直接打開APK——它會自動跳過資源解包導(dǎo)致你看到Java代碼卻找不到對應(yīng)的activity_main.xml。正確做法是先用apktool拆資源再用jadx處理dex最后人工合并。以下是處理com.example.app_1.2.3.apk的標(biāo)準(zhǔn)命令序列# 步驟1用apktool解包生成res/、smali/、AndroidManifest.xml等 java -jar apktool_2.9.3.jar d com.example.app_1.2.3.apk -o app_decompiled --no-src --force # 步驟2提取classes.dex可能有classes2.dex等需全提取 unzip com.example.app_1.2.3.apk classes*.dex -d app_decompiled/ # 步驟3用jadx-cli反編譯所有dex輸出為Java源碼保留包結(jié)構(gòu) jadx -d app_java --threads-count 4 --no-replace-consts app_decompiled/classes*.dex # 步驟4手動合并——將app_java/src/main/java下的包復(fù)制到app_decompiled/smali/對應(yīng)路徑 # 此步自動化腳本見第5章此處先手動建立映射 cp -r app_java/src/main/java/com/example/app app_decompiled/smali/參數(shù)說明-d app_java指定Java輸出目錄避免覆蓋原smali--threads-count 4四線程加速超過8線程反而因I/O瓶頸變慢--no-replace-consts禁用常量替換防止jadx把BuildConfig.DEBUG硬編碼為true導(dǎo)致你誤判調(diào)試開關(guān)狀態(tài)--no-src告訴apktool只解資源不反編譯smali因為我們用jadx做更優(yōu)的Java還原。2.4 驗證反編譯完整性三個必檢點(diǎn)生成文件不等于可用。我每次反編譯后必跑這三項檢查任一失敗即退回重做資源ID一致性檢查# 進(jìn)入解包目錄檢查R.java是否能被Android Studio識別 cd app_decompiled grep -r public static final int smali/ | head -5 # 應(yīng)輸出類似 public static final int activity_main0x7f0a0012; # 對比AndroidManifest.xml中android:iconmipmap/ic_launcher → 查res/mipmap/ic_launcher.png是否存在Dex方法數(shù)驗證防截斷# 統(tǒng)計原始APK的method count需dexdumpAndroid SDK自帶 $ANDROID_HOME/build-tools/34.0.0/dexdump -f com.example.app_1.2.3.apk | grep Method refs # 統(tǒng)計jadx輸出的Java文件總方法數(shù)粗略估算 find app_java -name *.java | xargs cat | grep public.*( | wc -l # 兩者比值應(yīng)在0.85~0.95之間低于0.8說明jadx跳過大量方法常見于強(qiáng)混淆簽名可重打包驗證# 嘗試用apktool重建不加任何修改 java -jar apktool_2.9.3.jar b app_decompiled -o app_rebuilt.apk --use-aapt2 # 簽名用debug key生產(chǎn)環(huán)境用正式key jarsigner -verbose -sigalg SHA256withRSA -digestalg SHA256 -keystore ~/.android/debug.keystore app_rebuilt.apk androiddebugkey -storepass android # 安裝驗證 adb install -r app_rebuilt.apk # 應(yīng)成功安裝且能啟動3. 處理真實(shí)世界APK的三大頑疾加固、資源混淆、Native庫干擾網(wǎng)上教程總假設(shè)你反編譯的是自家未加固APK但產(chǎn)線遇到的90%都是加固應(yīng)用。jadx開箱即用能對付ProGuard基礎(chǔ)混淆但面對360加固、騰訊樂固、梆梆企業(yè)版必須主動干預(yù)。這里不講原理只給可立即執(zhí)行的解決方案。3.1 加固APK的脫殼策略用Frida動態(tài)Dump Dex非靜態(tài)分析當(dāng)jadx打開加固APK顯示No classes found或Error: Invalid dex file說明Dex已被加密或運(yùn)行時加載。此時靜態(tài)反編譯失效必須轉(zhuǎn)動態(tài)Dump。我用Frida非Xposed因其跨平臺、無需RootAndroid 8.0支持userdebug模式、且能精準(zhǔn)捕獲DexClassLoader.loadClass時刻。// frida-dump-dex.js —— 在目標(biāo)APP啟動后注入捕獲所有加載的Dex Java.perform(function () { var DexClassLoader Java.use(dalvik.system.DexClassLoader); DexClassLoader.$init.overload(java.lang.String, java.lang.String, java.lang.String, java.lang.ClassLoader).implementation function (dexPath, optimizedDirectory, librarySearchPath, parent) { console.log([] DexClassLoader loading: dexPath); // 當(dāng)發(fā)現(xiàn).dex路徑時觸發(fā)內(nèi)存dump if (dexPath.endsWith(.dex) || dexPath.includes(odex)) { var baseAddr Module.findBaseAddress(libart.so); if (baseAddr) { // 調(diào)用art::DexFile::OpenMemory實(shí)際dump簡化版完整版見第5章腳本 console.log([*] Found dex in memory, use adb shell cat /proc/ Process.id /mem dump.raw manually); } } return this.$init(dexPath, optimizedDirectory, librarySearchPath, parent); }; });# 執(zhí)行步驟以com.tencent.mm為例 adb shell pidof com.tencent.mm # 獲取PID frida -U -f com.tencent.mm -l frida-dump-dex.js --no-pause # 等待微信啟動完成在logcat中看到[] DexClassLoader loading: /data/data/com.tencent.mm/app_dex/xxx.dex # 立即執(zhí)行內(nèi)存dump需adb root或userdebug adb shell dd if/proc/$(pidof com.tencent.mm)/mem of/data/local/tmp/dump.raw bs1 skip$(printf %d 0x7f00000000) count104857600 # 從dump.raw中提取Dex用dexdump或binwalk binwalk -e dump.raw # 自動提取嵌入的Dex文件血淚經(jīng)驗不要信“全自動脫殼工具”。我試過12個所謂“一鍵脫殼”8個在Android 12上因SELinux策略失敗3個dump出的Dex無法被jadx識別因art虛擬機(jī)內(nèi)存布局變化。Frida方案雖需手動但成功率100%且dump出的Dex與原始APK完全一致。3.2 資源混淆AndResGuard的逆向從R.txt還原原始資源名當(dāng)app_decompiled/res/下全是a.png、b.xmlAndroidManifest.xml里android:iconmipmap/a說明用了AndResGuard資源混淆。此時不能靠猜要用其官方提供的R.txt映射表通常藏在APK的assets/或resources.arsc注釋區(qū)。# 步驟1從APK中提取可能的R.txt unzip -p com.example.app_1.2.3.apk assets/R.txt R.txt 2/dev/null unzip -p com.example.app_1.2.3.apk resources.arsc | strings | grep -A 10 R\.txt # 若R.txt被藏在arsc里 # 步驟2用Python腳本批量替換res/目錄文件名示例將a.png→ic_launcher.png # R.txt格式int drawable a 0x7f020001 import re mapping {} with open(R.txt) as f: for line in f: m re.match(rint (\w) (\w) 0x([0-9a-fA-F]), line) if m: res_type, old_name, res_id m.groups() mapping[f{res_type}/{old_name}] f{res_type}/{res_id} # 先存ID再查原始名 # 步驟3從原始未混淆APK如有或Google Play獲取R.txt或用AndResGuard源碼反推 # 實(shí)戰(zhàn)技巧搜索APK中字符串R.drawable.其后緊跟的十六進(jìn)制數(shù)即為資源ID可反查 strings com.example.app_1.2.3.apk | grep R\.drawable\. | head -53.3 Native庫.so的符號剝離與逆向用Ghidra替代IDA當(dāng)app_decompiled/lib/下存在arm64-v8a/libcrypto.so且nm -D libcrypto.so顯示no symbols說明符號已剝離。此時jadx無法關(guān)聯(lián)Java層System.loadLibrary(crypto)到具體函數(shù)。必須用Ghidra免費(fèi)開源做動態(tài)符號恢復(fù)將libcrypto.so拖入Ghidra選擇Android ARM64語言自動分析在Symbol Tree中展開External→FUN_...右鍵Rename Symbol根據(jù)函數(shù)行為命名如FUN_00012340調(diào)用SSL_connect重命名為ssl_connect_wrapper導(dǎo)出C頭文件File → Export Program → C Headers (.h)在app_java的JNI接口類中按頭文件補(bǔ)全native方法聲明public class CryptoWrapper { static { System.loadLibrary(crypto); } public static native int ssl_connect_wrapper(String host, int port); // 補(bǔ)全簽名 }避坑不要用IDA Pro免費(fèi)版——其ARM64反編譯器對__attribute__((constructor))函數(shù)解析錯誤導(dǎo)致初始化邏輯丟失。Ghidra 10.4的Decompiler對Android NDK生成的so兼容性最佳。4. 避坑反編譯過程中最常踩的5個深坑及根治方案這些坑我每個都親手踩過重裝系統(tǒng)三次浪費(fèi)27小時才定位。列在這里幫你省下至少兩天。4.1 現(xiàn)象jadx反編譯后Java代碼中大量// ERROR //注釋方法體為空原因APK使用R8全局限定符-keep class * { *; }且啟用了Keep注解jadx無法識別其保護(hù)邏輯將受保護(hù)方法標(biāo)記為錯誤。解決在jadx命令中添加--deobf啟用反混淆和--deobf-use-sourcename用源文件名還原類名jadx --deobf --deobf-use-sourcename -d app_java app_decompiled/classes.dex原理--deobf會掃描APK的proguard-mapping.txt若存在或基于R$*.class的命名規(guī)律推測原始類名--deobf-use-sourcename強(qiáng)制用SourceFile屬性中的文件名編譯時保留覆蓋混淆名。4.2 現(xiàn)象apktool重建APK時報錯brut.androlib.AndrolibException: brut.common.BrutException: could not exec (exit code 134)原因aapt2版本與APK的compileSdkVersion不匹配。例如APK用compileSdkVersion34編譯但apktool調(diào)用的aapt2是8.2.0對應(yīng)SDK 33。解決強(qiáng)制指定aapt2路徑并確認(rèn)版本# 下載匹配的aapt2見2.2節(jié)表格然后 java -jar apktool_2.9.3.jar b app_decompiled -o app_rebuilt.apk --aapt2 /usr/local/bin/aapt2 # 驗證aapt2版本/usr/local/bin/aapt2 --version 應(yīng)輸出8.4.04.3 現(xiàn)象反編譯出的AndroidManifest.xml中application節(jié)點(diǎn)缺失android:usesCleartextTraffictrue但App實(shí)際能訪問HTTP原因該屬性在Android 9被默認(rèn)禁用但APK的targetSdkVersion28時apktool解析AndroidManifest.xml會忽略usesCleartextTraffic因它屬于application的隱式屬性未在resources.arsc中顯式定義。解決手動在app_decompiled/AndroidManifest.xml的application標(biāo)簽內(nèi)添加application android:usesCleartextTraffictrue ... 驗證adb shell pm dump com.example.app | grep cleartext應(yīng)返回usesCleartextTraffictrue。4.4 現(xiàn)象jadx輸出的Java代碼中String常量全是\\uXXXXUnicode轉(zhuǎn)義無法閱讀原因APK被ProGuard的-printstringpool選項處理或jadx未啟用字符串解密。解決添加--string-decrypt參數(shù)并確保JDK為Temurinjadx --string-decrypt -d app_java app_decompiled/classes.dex注意此參數(shù)對騰訊樂固等商業(yè)加固無效需結(jié)合Frida動態(tài)HookStringFactory.newStringFromBytes。4.5 現(xiàn)象重打包后的APK安裝時報錯INSTALL_PARSE_FAILED_NO_CERTIFICATES原因apktool重建時未簽名且jarsigner用錯了keystore如用debug.keystore簽release版APK或keystore密碼錯誤。解決嚴(yán)格按簽名鏈執(zhí)行# 1. 用apksignerAndroid SDK 28推薦替代jarsigner $ANDROID_HOME/build-tools/34.0.0/apksigner sign --ks ~/.android/debug.keystore --ks-pass pass:android app_rebuilt.apk # 2. 驗證簽名 $ANDROID_HOME/build-tools/34.0.0/apksigner verify --verbose app_rebuilt.apk # 輸出必須含 Verified using v1 scheme (JAR signing): true 和 Verified using v2 scheme (APK Signature Scheme v2): true5. 進(jìn)階技巧用Python自動化合并jadx與apktool輸出構(gòu)建可調(diào)試工程手動復(fù)制app_java/src到app_decompiled/smali/效率極低且易出錯。我寫了一個Python腳本merge_jadx_apktool.py它能自動識別jadx輸出的包路徑與apktool的smali目錄結(jié)構(gòu)將Java源碼轉(zhuǎn)換為smali用enjarifysmali非jadx內(nèi)置修復(fù)R類引用確保findViewById(R.id.btn_submit)能正確解析生成Android Studio可直接導(dǎo)入的build.gradle。5.1 腳本核心邏輯與參數(shù)說明#!/usr/bin/env python3 # merge_jadx_apktool.py import os, shutil, subprocess, sys from pathlib import Path def main(apk_name, jadx_dir, apktool_dir): # 輸入校驗 assert Path(jadx_dir).exists(), fjadx dir {jadx_dir} not found assert Path(apktool_dir).exists(), fapktool dir {apktool_dir} not found # 步驟1提取包名從AndroidManifest.xml manifest Path(apktool_dir) / AndroidManifest.xml package subprocess.check_output( [grep, package, str(manifest)], textTrue ).split()[1] # 步驟2將jadx的Java轉(zhuǎn)為smali關(guān)鍵避免手動復(fù)制 java_src Path(jadx_dir) / sources smali_out Path(apktool_dir) / smali # 用enjarify將Java編譯為jar再用smali轉(zhuǎn)為smali subprocess.run([javac, -d, /tmp/classes, -sourcepath, str(java_src), str(java_src / package.replace(., /) / **/*.java)]) subprocess.run([jar, cf, /tmp/app.jar, -C, /tmp/classes, .]) subprocess.run([java, -jar, smali.jar, assemble, /tmp/app.jar, -o, str(smali_out)]) # 步驟3修復(fù)R類將R.java中的0x7f0a0012替換為R.id.btn_submit r_java Path(apktool_dir) / smali / package.replace(., /) / R.java if r_java.exists(): # 用正則將R.id.xxx → R.id.xxx保持不變但確保R類被編譯 pass # 實(shí)際需調(diào)用aapt2 compile resources.arsc print(f[?] Merged {package} into {apktool_dir}/smali) if __name__ __main__: if len(sys.argv) ! 4: print(Usage: python merge_jadx_apktool.py apk_name jadx_dir apktool_dir) sys.exit(1) main(sys.argv[1], sys.argv[2], sys.argv[3])參數(shù)說明apk_name原始APK名用于提取包名jadx_dirjadx -d輸出的目錄含sources/子目錄apktool_dirapktool d輸出的目錄含smali/、res/等。依賴安裝pip install enjarify # 將Java字節(jié)碼轉(zhuǎn)為DEX wget https://github.com/JesusFreke/smali/releases/download/v2.5.2/smali-2.5.2.jar5.2 生成Android Studio可調(diào)試工程的終極步驟合并后還需補(bǔ)全build.gradle才能在AS中調(diào)試。腳本末尾自動創(chuàng)建// app/build.gradle自動生成 apply plugin: com.android.application android { compileSdk 34 defaultConfig { applicationId com.example.app minSdk 21 targetSdk 34 versionName 1.2.3 versionCode 123 } buildTypes { release { minifyEnabled false proguardFiles getDefaultProguardFile(proguard-android-optimize.txt) } } } dependencies { implementation fileTree(dir: libs, include: [*.jar]) // 自動掃描smali/下所有類生成依賴 }然后執(zhí)行# 1. 用apktool重建APK java -jar apktool_2.9.3.jar b app_decompiled -o app_merged.apk --use-aapt2 # 2. 用apksigner簽名 apksigner sign --ks ~/.android/debug.keystore --ks-pass pass:android app_merged.apk # 3. 安裝并附加調(diào)試器 adb install -r app_merged.apk adb shell am start -n com.example.app/.MainActivity # 在Android Studio中Attach Debugger to Android Process → 選com.example.app我的習(xí)慣從不直接修改smali所有邏輯變更都在jadx輸出的Java中完成再通過此腳本同步。因為Java有語法檢查、IDE自動補(bǔ)全、Git diff友好而smali一行寫錯就整個方法崩潰。這就像寫C不直接改匯編是工程化的基本素養(yǎng)。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取