简介：Androidfby反编译工具面向Android开发者与逆向工程学习者，用于解析APK内部结构，查看Java源代码、资源文件与XML配置，便于分析应用工作原理或在修改、优化、调试APK时提供辅助。压缩包共488个文件，约8.84MB，以435个pgt、22个ogg等资源文件为主，另含13个jar库文件、6个xml配置、2个dex、2个exe主程序及2个apk示例，并附带readme说明、日志与图标等辅助内容，目录结构清晰，便于按模块检索。目前已有621人学习下载。工具提供32位与64位两个版本，配合示例APK与说明文档，可帮助读者快速上手反编译流程，直观查看反编译结果并导出分析，同时理解APK内部机制，提升开发与调试效率。使用时需注意版权与隐私安全，遵循合法合规原则。
1. 从一次改包名翻车说起：Androidfby 到底能干什么
上周帮朋友处理一个二手安卓项目，需求很简单——把安装包里的应用名和包名换掉，重新签个名装到测试机上。我心想这活儿十分钟搞定，随手用命令行工具解包、改 XML、回编译，结果回编译直接报错，资源文件里一堆属性对不上。折腾到凌晨两点，最后换了个带图形界面的反编译工具，鼠标点几下就完事了。那个工具就是 Androidfby。
Androidfby 是一个面向安卓安装包的图形化反编译工具，核心能力是把 apk 文件拆成可读的 smali 代码、资源文件和 AndroidManifest.xml，改完之后还能重新打包签名。它把 apktool、dex2jar、jd-gui 这些命令行工具串到一个界面里，省去了记参数和配环境的麻烦。适合谁用？安全测试人员做基础逆向分析、开发者排查第三方 SDK 行为、运维人员给内部应用做简单定制，以及刚接触安卓逆向想找个可视化入口的新手。如果你需要的是深度混淆对抗或大型游戏逆向，它可能不够用，但日常的改包名、换图标、删权限、看资源引用，它完全能扛。
2. 环境搭建与首次反编译：从 apk 到 smali 目录
2.1 运行环境与依赖检查
Androidfby 本身是绿色版工具，解压就能跑，但它依赖 Java 运行环境。我一般用 JDK 8 或 JDK 11，版本太高反而容易出兼容问题。检查 Java 是否就绪：
java -version如果输出类似java version "1.8.0_291"就说明没问题。没有的话去装一个，安装完记得配JAVA_HOME环境变量。Windows 下在系统属性里加，Linux/macOS 在~/.bashrc或~/.zshrc里加：
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 export PATH=$JAVA_HOME/bin:$PATH配完执行source ~/.bashrc生效。这一步看着简单，但我见过太多人卡在这儿——工具闪退、反编译按钮点了没反应，九成是 Java 版本不对或环境变量没配好。
提示：Androidfby 解压路径不要带中文和空格，否则内部调用命令行工具时可能解析失败。
2.2 反编译操作与输出目录解读
打开工具后，界面通常分三块：左上选 apk 文件，右上选输出目录，下方是日志窗口。点“反编译”按钮，等进度条走完，输出目录里会出现这些内容：
| 目录/文件 | 内容说明 |
|---|---|
smali/ | Dalvik 字节码反汇编后的 smali 代码，按包名分目录 |
res/ | 资源文件，包括布局 XML、图片、字符串等 |
AndroidManifest.xml | 解码后的清单文件，可直接编辑 |
apktool.yml | 反编译元信息，回编译时要用 |
assets/ | 原始资源目录，部分应用会放配置或数据库 |
日志窗口会打印每一步调用的命令和耗时。如果中途报错，先看日志最后几行，常见的是Could not decode file或brut.androlib.AndrolibException，多半是 apk 被加固了或者资源混淆过。
反编译完成后，我习惯先打开AndroidManifest.xml看包名、权限和入口 Activity。这个文件是解码后的明文，直接搜package=就能定位包名，搜uses-permission看权限列表。改包名就改package属性的值，但注意——改了包名之后，smali 目录里所有引用旧包名的路径也要同步改，否则回编译必挂。
2.3 回编译与签名：把改完的包装回手机
改完想要的内容后，点“回编译”按钮，工具会调用 apktool 把 smali 和资源重新打包成 apk。这一步常见的坑是资源 ID 冲突或 XML 格式错误，日志里会提示具体行号。
回编译成功后得到的是一个未签名的 apk，直接装是装不上的，必须签名。Androidfby 一般自带签名功能，需要你提供一个 keystore 文件。没有的话用keytool生成一个：
keytool -genkey -v -keystore my-release.keystore -alias mykey -keyalg RSA -keysize 2048 -validity 10000执行后会提示输入密码和姓名等信息，随便填就行。生成完在工具的签名界面选这个 keystore，输入 alias 和密码，点签名。签完的 apk 就能adb install到手机上了。
adb install -r signed_app.apk-r表示覆盖安装，保留数据。如果报INSTALL_FAILED_UPDATE_INCOMPATIBLE，说明设备上已有同包名但签名不同的应用，先卸载再装。
3. 资源修改与 smali 定位：改包名、换图标、删权限
3.1 修改应用名与图标
应用名在res/values/strings.xml里，搜app_name对应的字符串，改掉就行。但有些应用把名字写在AndroidManifest.xml的android:label属性里，直接引用了字符串资源，所以两个地方都要看。
图标替换更直接：在res/mipmap-*或res/drawable-*目录下找到ic_launcher.png，用同名同尺寸的图片覆盖。注意不同分辨率目录（hdpi、xhdpi、xxhdpi 等）都要换，否则在某些机型上会显示模糊或拉伸。我一般用脚本批量替换：
# 假设新图标放在 ~/new_icon/ 下，按分辨率命名 for dir in res/mipmap-*; do cp ~/new_icon/$(basename $dir).png $dir/ic_launcher.png done这段脚本遍历所有 mipmap 目录，把对应分辨率的新图标复制进去。basename $dir取目录名，比如mipmap-hdpi，你事先准备好同名文件即可。
3.2 删除权限与广告 SDK 入口
删权限是逆向里最常见的需求之一。在AndroidManifest.xml里找到对应的<uses-permission>标签，整行删掉。但注意——有些权限是应用运行必需的，删了会直接崩溃。我一般先删广告相关权限，比如INTERNET和ACCESS_NETWORK_STATE要谨慎，很多应用没网就闪退。
更稳妥的做法是保留权限声明，但在 smali 层把广告 SDK 的初始化代码注释掉。搜com/google/ads或com/facebook/ads这类包路径，找到调用初始化的 smali 文件，把对应方法调用改成return-void：
# 原代码 invoke-static {v0}, Lcom/google/ads/AdView;->init(Landroid/content/Context;)V # 改后 # invoke-static {v0}, Lcom/google/ads/AdView;->init(Landroid/content/Context;)V在 smali 里#是注释符。改完回编译，广告就不会加载了。但这个方法有风险——如果广告 SDK 和其他业务逻辑耦合，可能导致功能异常。改之前先备份原始 smali 目录。
3.3 用 jd-gui 辅助阅读 Java 源码
smali 代码读起来费劲，Androidfby 通常集成了 dex2jar 和 jd-gui。操作流程是：先用 dex2jar 把 apk 里的classes.dex转成 jar 包，再用 jd-gui 打开 jar 看 Java 源码。命令行方式：
d2j-dex2jar.sh classes.dex -o app.jar生成的app.jar用 jd-gui 打开，就能像看普通 Java 项目一样浏览类和方法。但注意——如果应用做了混淆，看到的会是a.a.a这种类名，需要结合 smali 里的字符串常量来推断逻辑。我一般先用 jd-gui 定位关键类，再回到 smali 里做精确修改。
注意：dex2jar 对多 dex 应用需要逐个处理，
classes2.dex、classes3.dex都要转，否则会漏掉部分代码。
4. 避坑与排查：那些让我重装系统的血泪经验
4.1 反编译报错 “Could not decode file”
现象：点反编译后日志报Could not decode file，输出目录为空或不完整。
原因：apk 被加固了，或者资源文件用了非常规压缩方式。常见加固方案会修改 dex 头部或加密资源，apktool 解不开。
解决：先用查壳工具确认是否加固。如果是加固的，Androidfby 这类常规工具基本无能为力，需要先脱壳再反编译。脱壳不在本文范围内，但你可以搜“frida-dexdump”了解思路。如果不是加固，尝试更新 apktool 版本，或者手动用apktool d -f input.apk加-f强制覆盖。
4.2 回编译报 “resource not found”
现象：回编译时日志提示某个资源 ID 找不到，比如resource 0x7f0a0001 not found。
原因：你删了某个资源文件，但public.xml或res/values/public.xml里还留着引用；或者改了strings.xml里的条目，但 smali 里还在用旧 ID。
解决：打开res/values/public.xml，搜报错的 ID，把对应行删掉。如果是 smali 引用问题，在 smali 目录里全局搜这个 ID 的十六进制值，把引用改成新的资源 ID。改完记得清理build目录再回编译。
4.3 签名后安装报 “INSTALL_PARSE_FAILED_NO_CERTIFICATES”
现象：apk 签名完，adb install提示没有证书。
原因：签名时选错了 keystore 类型，或者签名工具没正确写入 META-INF 目录。
解决：确认 keystore 是 JKS 或 PKCS12 格式，签名时选对算法（一般用 SHA256withRSA）。如果工具自带签名功能有问题，改用命令行apksigner：
apksigner sign --ks my-release.keystore --out signed.apk unsigned.apk--ks指定 keystore 文件，--out指定输出。执行后会提示输入密码。签完用apksigner verify signed.apk验证一下。
4.4 改完包名后应用闪退
现象：只改了AndroidManifest.xml里的package属性，回编译安装后打开就闪退。
原因：smali 代码里大量引用了旧包名的类路径，比如Lcom/oldpackage/MainActivity;，只改清单文件不改 smali，运行时找不到类。
解决：在 smali 目录里全局替换包名路径。Linux/macOS 下用grep -rl加sed：
grep -rl "com/oldpackage" smali/ | xargs sed -i 's|com/oldpackage|com/newpackage|g'Windows 下用 VS Code 的全局替换功能，范围选 smali 目录。替换完再回编译。注意——有些第三方 SDK 的包名不能改，改了会出问题，所以替换前先确认哪些目录是应用自身的。
4.5 工具界面卡死或无响应
现象：点反编译后界面卡住，进度条不动，日志也不刷新。
原因：apk 文件太大（超过 200MB），或者输出目录所在磁盘空间不足。
解决：先看磁盘剩余空间，至少留 2GB。大文件建议用命令行 apktool 处理，图形界面在大文件上容易内存溢出。命令行方式：
apktool d -f -o output_dir input.apk-f强制覆盖已有目录，-o指定输出路径。处理完再用 Androidfby 打开输出目录做后续修改。
5. 进阶技巧：批量处理与自动化验证
当你需要处理多个 apk 时，一个个点界面效率太低。我一般把 Androidfby 的解压目录加到 PATH，直接调它内部的 apktool 和签名工具写脚本。下面这个脚本批量反编译一个目录下的所有 apk：
#!/bin/bash # 批量反编译脚本，用法：./batch_decode.sh /path/to/apks /path/to/output INPUT_DIR=$1 OUTPUT_DIR=$2 for apk in $INPUT_DIR/*.apk; do name=$(basename $apk .apk) echo "正在处理: $name" apktool d -f -o "$OUTPUT_DIR/$name" "$apk" if [ $? -eq 0 ]; then echo "$name 反编译成功" else echo "$name 反编译失败，跳过" fi done$1和$2是位置参数，分别接收输入目录和输出目录。basename $apk .apk去掉路径和扩展名，得到纯文件名。$?判断上一条命令的退出码，0 表示成功。这个脚本能帮你快速筛出哪些 apk 能正常反编译，哪些需要特殊处理。
验证修改是否生效，我习惯用aapt工具查看 apk 的元信息：
aapt dump badging signed.apk | head -20输出里会显示package: name='com.newpackage'和application-label:'新应用名'，确认包名和标签都改对了。head -20只看前 20 行，避免输出太长。
还有一个技巧——用diff对比修改前后的 smali 目录，快速定位自己改了哪些文件：
diff -r original_smali/ modified_smali/ > changes.diff生成的changes.diff文件里会列出所有差异，方便回滚或审查。我每次改完重要应用都会跑一遍这个命令，确认没有误改无关代码。
从那以后我每次反编译前都强制走一遍流程：先备份原始 apk，再检查 Java 版本，然后确认输出目录空间充足，最后才点反编译按钮。这套习惯帮我省了至少三次重装系统的时间。希望帮到你。
本文还有配套的精品资源，点击获取
