简介本资源是一套面向Android安全研究者、逆向工程师与中高级开发者的专业APK分析工具集聚焦脱壳、反编译与源码还原三大核心需求助力应用安全审计、漏洞分析与逻辑理解。压缩包含43个文件涵盖14个jar如apktool.jar、dex2jar核心库、11个bat/sh脚本提供Windows/Linux一键调用支持、5个exe含JD-GUI图形界面工具、10个shell/batch封装脚本及配置文件总大小40.51MB结构清晰、开箱即用。已有295人学习下载适用于实战型技术提升场景。用户可直接获得blackdex脱壳、apktool解包Smali反编译、dex2jar转Java字节码、GD-GUI深度二进制分析、smali2java源码还原等完整链路工具及配套执行脚本避免环境搭建与版本兼容问题显著提升APK逆向分析效率与准确性。1. APK脱壳、反编译、查看源码工具集不是“一键还原Java源码”而是对抗加固与混淆的工程化拆解链你拿到一个APK双击JD-GUI打不开——报错“Invalid jar file”用jadx-gui加载后全是a.a.b.c这种命名的类onCreate()方法里嵌套了7层if (b ! null b.get() ! null)再加一堆String.valueOf(System.currentTimeMillis())拼接strings.xml被加密成二进制资源AndroidManifest.xml里application标签被动态注册甚至classes.dex根本不存在只有一堆.so和assets/xxx.dat。这不是反编译失败是你正面对一个经过ProGuardAndResGuard自研壳比如某太极软件库.apk用的定制壳加固的真实APK。APK脱壳、反编译、查看源码工具集本质是一条分阶段、有先后、强依赖的逆向流水线先识别壳类型→再动态/静态脱壳获取原始Dex→然后解密资源→最后用多引擎协同反编译并人工交叉验证。它不服务于“扒小程序”或“免费python源码大全”这类泛需求而是给Android安全研究员、第三方SDK审计员、合规检测工程师、以及需要做竞品逻辑分析的App开发负责人提供一套可复现、可调试、能落地的本地化逆向工作流。本文不讲理论玄学只拆解2024年真实环境中从apk pure下载的加固APK到最终看到可读Java源码的完整路径——每一步命令为什么这么写、参数怎么调、失败时看哪几行日志、哪些工具必须配合使用以及为什么单靠jadx或dex2jar永远卡在第一步。2. 脱壳从识别壳类型到获取原始Dex文件的三阶实操脱壳不是魔法是信息收集→环境构造→行为捕获的闭环。市面上95%的加固方案包括新版太极软件库.apk、cocos creator打包的商用游戏APK、多数金融类App都基于“运行时解密Dex内存加载”模型这意味着静态分析只能看到壳代码真逻辑藏在运行时内存中。因此脱壳必须分三步走先静态识别壳指纹再选对动态调试环境最后用内存dump或IO拦截拿到原始Dex。跳过任一环节后续反编译必然失败。2.1 壳类型识别用apksigneraapt2strings三件套快速定位不要一上来就开frida。先用最轻量级命令确认加固类型避免误判浪费时间# 1. 检查签名完整性判断是否被二次签名篡改 apksigner verify --verbose your_app.apk # 2. 提取AndroidManifest.xml结构看是否有可疑Application类 aapt2 dump manifest your_app.apk | grep -E (application|name) # 3. 扫描关键字符串壳厂商特征码 strings -n 8 your_app.apk | grep -i -E (360|tencent|ali|baidu|qihoo|taiji|cocos|unity|upx|vmprotect)提示aapt2 dump manifest输出中若出现android:name.ShellApplication或com.stub.StubApp基本锁定360加固或腾讯乐固若看到com.example.xxx.Application但AndroidManifest.xml里没定义该类则大概率是动态注册需进一步查assets/目录strings结果中若含UPX!且file your_app.apk显示ELF头说明用了UPX 5.10脱壳——但注意UPX对Android DEX无效它只压缩.so别被误导。2.2 动态脱壳实战Frida脚本注入内存dump适配Android 12Android 12起ptrace权限收紧传统adb shell su -c cat /proc/*/maps找Dex地址已失效。必须用Frida hookDexFile::openDexFileNative或ClassLoader::loadClass。以下脚本经实测兼容Android 12~14需提前安装Frida-server// frida-dump-dex.js Java.perform(function () { console.log([*] Hooking DexFile.openDexFileNative...); const DexFile Java.use(dalvik.system.DexFile); DexFile.openDexFileNative.implementation function (sourceName, odexOutputPath, flags) { console.log([] Found DEX: sourceName); // 触发dump需提前在/data/local/tmp/创建目录 const DexDump Java.use(dalvik.system.DexFile); const dexBytes this.openDexFileNative(sourceName, odexOutputPath, flags); if (dexBytes dexBytes.length 0) { const fs Java.use(java.io.FileOutputStream); const file Java.use(java.io.File).$new(/data/local/tmp/original.dex); const fos fs.$new(file); fos.write(dexBytes); fos.close(); console.log([] Dumped to /data/local/tmp/original.dex); } return dexBytes; }; });执行命令# 推送脚本并启动App adb push frida-dump-dex.js /data/local/tmp/ adb shell chmod 755 /data/local/tmp/frida-dump-dex.js frida -U -f com.your.target.app -l /data/local/tmp/frida-dump-dex.js --no-pause参数说明--no-pause确保App启动后立即注入-l指定脚本路径/data/local/tmp/是Android系统允许写入的通用路径无需root部分厂商ROM需关闭SELinux。若App启动后无日志输出检查Frida-server版本是否匹配推荐v16.1.12并确认App未启用debuggablefalse。2.3 静态脱壳备选针对UPX压缩.so与Cocos Creator资源解包当动态调试失败如App检测Frida转向静态补救。重点处理两类常见情况UPX 5.10压缩的.so文件UPX本身不压缩DEX但常用于压缩lib/armeabi-v7a/libxxx.so。用官方UPX工具解压upx -d libxxx.so -o libxxx_dec.so # 解压后用readelf -d libxxx_dec.so检查DT_NEEDED确认是否含JNI入口函数Cocos Creator打包的APK资源其assets/src/下为.jsc字节码需用Cocos官方jsc-decrypt工具非公开但GitHub有逆向版# 先提取assets目录 unzip your_app.apk assets/src/*.jsc -d ./tmp/ # 使用jsc-decrypt需Python 3.8 python jsc-decrypt.py ./tmp/assets/src/game.jsc ./output/ # 输出为JavaScript源码非Java但逻辑等价注意Cocos Creator的.jsc解密需密钥密钥通常硬编码在libxxx.so中需用Ghidra反汇编.so定位AES_set_encrypt_key调用点——这是典型“脱壳链”中静态与动态的衔接点。3. 反编译JADX为主力但必须用JADCFR交叉验证混淆逻辑拿到original.dex后别急着丢进JADX。2024年主流加固方案如阿里聚安全、腾讯御安全已默认开启obfuscationstring encryptioncontrol flow flatteningJADX单引擎会漏掉大量关键逻辑。必须构建“JADX基础反编译 → JAD补全语法 → CFR验证控制流”的三重校验链。3.1 JADX最小化配置禁用自动修复保留原始结构JADX默认开启--deobfuscate和--extract-annotations这会导致变量名被强行重命名如param1→a反而掩盖混淆意图。生产环境应关闭jadx -d ./output/ \ --no-replace-consts \ --no-inline-methods \ --no-replace-enum \ --threads-count 8 \ original.dex参数说明--no-replace-consts防止将const-string v0, api/v1/login替换为api/v1/login字面量保留字符串加密线索--no-inline-methods避免内联导致控制流扁平化失效--threads-count 8适配多核CPU但超过8核收益递减。输出目录./output/下sources/即Java源码resources/为解密后的资源。3.2 JAD补全修复JADX无法解析的Lambda与Method ReferenceJADX对Java 8特性支持弱遇到stream().map(User::getName)或() - doSomething()会报错UnsupportedOperationException。此时用JAD经典但稳定补位# 将dex转jar必须用最新dx/d8旧版dx已弃用 d8 --min-api 21 --output ./tmp/classes.jar original.dex # 用JAD反编译jarJAD官网已停更用GitHub维护版jadclipse-standalone jad -o -r -sjava -lnc ./tmp/classes.jar注意d8是Android官方推荐的DEX生成器替代旧dx-lnc参数禁用注释避免JAD因注释格式错误崩溃生成的.java文件需手动合并到JADX输出目录重点覆盖lambda$开头的匿名类。3.3 CFR验证揪出JADX/JAD都漏掉的控制流扁平化控制流扁平化Control Flow Flattening会让if-else变成switch(state){case 1: ... state2; break;}死循环JADX常将其误判为无限循环而截断。CFR专为此设计# 下载CFRcfr-0.202.jar用以下命令反编译单个类 java -jar cfr-0.202.jar \ --caseinsensitivefs true \ --removebadgenerics true \ --decodelambdas true \ --hidebridgemethods false \ ./output/sources/com/example/MainActivity.java关键参数--decodelambdas true强制解码Lambda--hidebridgemethods false暴露桥接方法Bridge Method这是泛型擦除后的真实调用链输出中若看到while (true) { switch (state) { ... } }说明存在扁平化需人工还原状态机——这是逆向中最耗时的环节没有工具能全自动。4. 查看源码资源解密、Manifest还原与跨平台源码关联反编译出Java代码只是开始。真正的业务逻辑往往藏在资源、Manifest动态注册、甚至跨平台代码中。查看源码必须打通“代码-资源-配置”三维视图否则看到的只是碎片。4.1 资源解密AndResGuard与AAPT2解包的对抗策略AndResGuard通过arsc加密和资源ID重映射实现加固aapt2 dump resources your_app.apk会显示乱码ID如0x7f0a0001→0x01010001。解密需两步提取resources.arsc并定位加密表# 用androguard解包 androguard apk -i your_app.apk -o ./andres/ # 查看resources.arsc结构 androaxml ./andres/resources.arsc | head -20若输出含string namekeyaes_key_123/string说明密钥明文存储直接用AndResGuard官方解密脚本。无密钥时暴力还原ID映射当密钥被抹除用apktool d -r your_app.apk强制解包-r跳过资源解码再对比public.xml与resources.arsc中的ID偏移量# 获取原始ID列表 aapt2 dump resources your_app.apk | grep resource ID | awk {print $3} | sort -u id_list.txt # 用Python脚本匹配映射关系需已知1-2个明文资源名 python3 match_id.py id_list.txt known_strings.txt提示match_id.py核心逻辑是遍历id_list.txt对每个ID执行aapt2 dump resources your_app.apk --resource-id 0x7f0a0001匹配known_strings.txt中的明文建立映射表。这是逆向中“以点破面”的典型技巧。4.2 Manifest还原动态注册Application与Activity的逆向定位加固APK常将application和activity从AndroidManifest.xml移除改用PackageManager.setComponentEnabledSetting()动态注册。需从代码中定位# 在JADX输出中全局搜索 grep -r setComponentEnabledSetting\|getPackageManager\|getPackageInfo ./output/sources/ # 重点检查Application子类的attachBaseContext()和onCreate() # 示例找到com.stub.StubApp.onCreate() → 调用StubApplication.init() → 加载真实Application避坑不要只看AndroidManifest.xml动态注册的Activity在adb shell dumpsys activity activities中可见但源码需回溯到StubApplication的loadRealApplication()方法该方法通常通过反射加载assets/real_app.jar——这才是真正的业务入口。4.3 跨平台源码关联Cocos/Unity/WebView的代码溯源当APK来自Cocos Creator或UnityJava层只是壳核心逻辑在JS或C#中Cocos Creatorassets/src/下的.jsc解密后为JS用VS Code打开搜索cc.loader.loadRes定位资源加载点cc.director.on(game_start, ...)定位主逻辑入口。Unitylib/arm64-v8a/libunity.so含IL2CPP字节码用il2cppdumper提取C#代码il2cppdumper ./libunity.so ./global-metadata.dat ./output/ # 输出为C#源码需用Visual Studio调试重点关注Assembly-CSharp.dllWebView混合应用assets/www/或/data/data/com.xxx/app_webview/下为HTML/JS用adb backup -f webview.ab com.xxx导出再用android-backup-extractor解包java -jar abe.jar unpack webview.ab webview.tar tar -xf webview.tar注意WebView JS常被混淆如eval(atob(...))需用Chrome DevTools的Pretty Print功能格式化再搜索fetch(或XMLHttpRequest定位API调用。5. 避坑指南脱壳与反编译中5个血泪经验换来的致命陷阱逆向不是线性流程90%的时间花在排查失败原因。以下是我在200个APK实操中踩过的坑按发生频率排序每条附带现象、根因和可执行解决方案。5.1 现象JADX加载后报错java.lang.OutOfMemoryError: Java heap space原因JADX默认堆内存仅2GB而加固APK的Dex常含数万方法AST构建耗尽内存。解决启动JADX时显式指定堆大小并关闭GUI加速渲染jadx -d ./output/ -Xmx8g --threads-count 4 original.dex # 或修改jadx-gui.vmoptions文件-Xmx8g -XX:MaxMetaspaceSize1g5.2 现象Frida注入后App闪退logcat显示FATAL EXCEPTION: main Process: com.xxx PID: 12345 java.lang.SecurityException: Permission denied原因App调用android.os.Debug.isDebuggerConnected()或Build.FINGERPRINT.contains(generic)检测调试环境触发自杀逻辑。解决用Frida绕过检测非通用需针对性hookJava.perform(function () { const Debug Java.use(android.os.Debug); Debug.isDebuggerConnected.implementation function () { return false; // 强制返回false }; const Build Java.use(android.os.Build); Build.FINGERPRINT.value google/sdk_gphone64_arm64/gphone64_arm64:14/UP1A.231005.007/9485228:userdebug/test-keys; });5.3 现象aapt2 dump resources输出ERROR: Resource table is empty原因AndResGuard 2.0采用resources.arsc全加密且密钥动态生成如用设备IMEI时间戳静态解密失效。解决放弃静态解密改用动态dump# 启动App后用adb抓取内存中解密后的resources.arsc adb shell su -c cp /data/data/com.xxx/files/resources.arsc /sdcard/ adb pull /sdcard/resources.arsc ./decrypted/ aapt2 dump resources decrypted/resources.arsc5.4 现象JADX反编译出的代码含大量throw new RuntimeException(Stub!)原因APK引用了Android SDK的android.jarstub而JADX未正确链接SDK源码将所有系统API标记为存根。解决配置JADX关联Android SDK源码# 下载对应API Level的sources如android-33-sources.jar # 在JADX GUI中Settings → General → Android SDK Path → 指向sdk/sources/android-33/ # 或命令行添加--android-sdk /path/to/android-sdk5.5 现象CFR反编译后出现goto label1;且无label定义编译失败原因CFR对某些控制流扁平化处理不完整goto指向的label被优化删除。解决降级CFR版本或切换引擎# 优先尝试CFR 0.199对goto支持更稳 java -jar cfr-0.199.jar --removebadgenerics true ./class.class # 若仍失败用Procyon虽慢但goto处理可靠 java -jar procyon.jar --output-dir ./procyon_out/ ./class.class6. 进阶技巧用Ghidra插件自动化脱壳链与源码可信度验证当面对批量APK如审计100个竞品App手动执行前述步骤效率低下。我自建了一套基于Ghidra的自动化流水线核心是用Ghidra插件替代FridaJADX组合实现“一次加载全程可视”。6.1 Ghidra插件DexLoader与AndroidAnalyzer协同工作流Ghidra 10.4原生支持Dex解析但需安装两个关键插件DexLoader直接加载.dex文件跳过dex2jar转换保留原始字节码结构。AndroidAnalyzer自动识别AndroidManifest.xml、resources.arsc、lib/目录并标记加固特征如UPX签名、壳类名。安装后操作流程# 1. 在Ghidra中File → Import File → 选择your_app.apk # 2. 导入时勾选DexLoader和AndroidAnalyzer # 3. 分析完成后Script Manager → Run Script → FindAllDexFiles.java # 4. 输出窗口显示所有Dex路径右键Decompile即得Java源码优势Ghidra的Decompiler对控制流扁平化处理优于JADX且支持跨函数追踪如点击findViewById()自动跳转到布局XML定义其Symbol Table可导出为CSV便于批量比对类名混淆程度。6.2 源码可信度验证用Diff工具量化反编译质量反编译结果是否可信不能只靠肉眼。我用diffradiff2做三重验证验证维度工具与命令判定标准Dex一致性radiff2 -s original.dex jadx_output/classes.dex相似度95%视为成功脱壳Java语法javac -source 8 -target 8 ./jadx_output/**/*.java 21 | wc -l编译错误行数10行即语法可用逻辑完整性grep -r login|pay|encrypt ./jadx_output/ | wc -lvsstrings your_app.apk | grep -c login关键词召回率80%实操示例对某金融Appradiff2显示相似度92%但javac报错127行。追查发现JADX将try-with-resources误译为finally{close()}手动替换try (FileInputStream fis new FileInputStream(...))即可修复——这就是“可信度验证”带来的精准修复点。6.3 终极习惯建立个人APK逆向知识库SQLiteMarkdown我维护一个本地SQLite数据库记录每个APK的脱壳方案、失败原因、关键密钥位置CREATE TABLE apks ( id INTEGER PRIMARY KEY, package_name TEXT, shell_type TEXT, -- tencent, ali, custom dex_path TEXT, -- /data/local/tmp/original.dex resource_key BLOB, -- AES密钥加密存储 notes TEXT -- Markdown格式笔记含截图URL );每次成功逆向后执行# 生成笔记模板 echo | Package | Shell | Key | Notes |\n|---|---|---|---|\n| $PKG | $SHELL | \$KEY\ | [View Log](log/$PKG.md) | knowledge.md # 插入数据库 sqlite3 apk.db INSERT INTO apks VALUES (NULL, $PKG, $SHELL, $DEX_PATH, $KEY_ENC, $NOTES);这个习惯让我在遇到新APK时30秒内检索出同类壳的脱壳脚本——比如看到com.qihoo.util.StubApplication立刻调出360加固的Frida脚本模板把com.xxx.xxx替换成当前包名即可复用。没有这个库我至少多花2小时重复造轮子。希望帮到你。本文还有配套的精品资源点击获取
