简介Android逆向助手是一份面向移动安全研究、应用分析与逆向调试场景的集成工具包将apktool、dex2jar、jd-gui、autosign等常用组件整合为一体可完成APK资源反编译、DEX字节码转JAR、Java源码浏览、重打包与自动签名等关键操作适合有一定Android开发基础、希望深入分析他人应用实现思路的开发者使用。压缩包共69个文件整体大小约15.21MB包含jar工具库、bat与sh自动化脚本、exe可执行程序以及签名和配置类文件不同扩展名对应不同阶段的任务能够覆盖从解包到回签的完整流程。目前已有144人学习/下载适合缺乏现成集成环境的中高级开发者直接使用工具链分类清晰且开箱即用。借助这套资源使用者无需逐一搜索和配置多个独立组件即可快速搭建本地逆向环境进而开展应用逻辑还原、安全漏洞排查、权限滥用检测和性能优化实践同时也可作为学习apktool、dex2jar、jd-gui工具链的配套素材帮助理解Android应用打包与反编译的底层机制。1. Android逆向助手不只是一个工具而是一套工作流拿到一个注册流程被重度混淆的APK静态看不到请求参数动态又带反调试想在三天内定位校验算法入口稍有不慎就走死胡同。这种场景里真正拖慢进度的往往不是破解算法本身而是重复的“拆包—反编译—搜索—打包—签名—再安装”循环。Android逆向助手这个名字听起来像某个集成的图形化软件但更现实、更可控的做法是一套能把重复动作收敛成一条命令的工作流用 androguard 做静态体检用 apktool/jadx 看代码和资源用 frida 处理运行时逻辑再用统一的脚本参数把每次分析结果落盘。它回答的是“拿到 APK 之后头一小时该做什么”也帮你把分析产物留成可复查的现场。适合做 App 合规审查、恶意行为分析以及想在安全方向上入门的开发者。2. 逆向助手背后的拆法静态、资源、动态三层各干什么2.1 静态分析层dex、so、Manifest 三根柱子缺一不可一个正常的 APK 本质是 Zip 包但真正决定逻辑的是三类东西classes.dex、原生库 .so、以及 AndroidManifest.xml。dex 是 Java/Kotlin 编译后的字节码反编译之后基本能还原出类、方法和字符串.so 是 native 层实现很多关键算法不放在 Java 层而是通过 JNI 调到 C/C 里Manifest 则给了你应用的包名、入口 Activity、权限、导出组件这些“社会关系”。我见过不少刚接触逆向的人拿到 APK 第一件事就是打开 jadx 扫 dex扫完发现全是a.a.a这种混淆类接着就不知道往哪走了。这里的问题不是工具不行而是静态层的顺序没理清楚。一个靠谱的 android逆向助手第一步不是急着 hook而是先把“三根柱子”列出来Manifest 里的application节点决定入口exported属性决定哪些组件能被外部调用对一个 App 做合规审查时导出组件往往是比代码混淆更优先暴露风险的地方。dex 里的包名、字符串、调用关系决定业务逻辑的位置关键方法往往集中在与网络、存储、加密相关的包路径下。.so 文件的存在本身就是一个信号如果某个模块强依赖 so想跳过 native 层直接改 Java 返回值大概率会翻车。静态分析工具有很多但我习惯把 androguard 放在第一梯队。它是 Python 库可以直接在脚本里调用批量化比图形工具舒服得多。apktool 和 jadx 虽然也能看 Manifest但它们的目标是“解码给人看”androguard 的目标是“把 APK 拆成可操作的数据结构”后者更适合做自动化。还有一个容易被忽略的点加壳应用会在onCreate里先加载壳的 so再由壳把真实的 dex 从 assets 或网络拉出来、解密后动态加载。这时候 jadx 看到的不是业务代码而是壳的代码。所以静态层必须包含一个“加固识别”步骤否则后面对着假 dex 分析半天等于在沙子上盖楼。2.2 资源与重打包层改逻辑先改 smali别指望 jadx 一键回写jadx 能把 dex 转成近乎可读的 Java 代码适合阅读、定位逻辑但如果你要改行为后重新打包直接用 jadx 输出是不现实的因为 Java 源码缺少原始编译时的结构信息转回去容易丢东西。真正的“改写层”是 smali。smali 是 dex 的汇编形式apktool 解包后得到的smali/目录里每个方法的寄存器操作一目了然许多工具和补丁也是在 smali 这一层完成。一个很容易理解错的点是混淆和混淆分析。ProGuard/R8 会改类名和方法名但 smali 里的调用关系是完整的你在 jadx 里看到一个a.a(Helper.b)的调用切到 smali 里能找到对应的虚函数操作和真实寄存器流转。所以把 smali 作为改造对象能最大程度保留语义又不会像反编译 Java 那样遇到goto和异常表的时候打脑壳。资源层也一样。resources.arsc保存了资源映射表字符串、布局、图标都在里面。apktool 的d操作能把 arsc 解成明文 XMLb操作再装回去。这个来回不是没有损耗的arsc 里的二进制格式对结构化数据很敏感apktool 在版本不一致时可能改出名篇所以我们通常把原包备份重命名成origin.apk放在同一个目录再对解包目录做改动。这个备份习惯比任何脚本都可靠。重打包后的签名也是这一层的一环。Android 7 以上默认自动校验 v2 签名老设备只看 v1如果直接在META-INF里手工改文件或用了只签 v1 的旧工具在新设备上就会被INSTALL_PARSE_FAILED_NO_CERTIFICATES拦住。后面避坑章节我会专门展开。2.3 动态层hook 框架不等于只需要 root边界要先划清楚静态分析能看“有什么”动态分析能看“跑起来做了什么”。这里最常见的两个框架是 Xposed 和 Frida。Xposed 偏底层、改系统生效修改后重启 App 就行适合做长期插件Frida 是后起之秀通过ptrace注入进程用 JS 代码执行 hook不需要修改系统镜像配合 Python 脚本很快能起一个临时监督环境。在 android逆向助手的架构里我一般把 Frida 作为默认动态方案原因很实际上手成本低命令行就能做而且临时 hook 结束后进程恢复不容易污染现场。Xposed 也不是不用但它要求 root 且需要重启目标进程大部分一次性分析场景反而显得笨重。Frida 的边界在于“能不能注入”。系统分区锁死的设备上frida-server 起不来只能在模拟器或已 root 的测试机里跑反调试能力强的 App还会检测ptrace状态给自己设置陷阱这时候 Frida 也会失效。动态层更关键的其实是“参数设计”而不是“框架选择”。比如 Frida 里常见Java.perform包一层回调是为了等 ART 虚拟机稳定启动后 1 秒内去 hook 很容易空手而归--no-pause是为了让App不处于暂停状态-f com.xxx.app表示冷启动。这些参数组合起来就是一个“启动模板”真正的逆向助手应该把这些模板固化下来而不是每次现查。3. 动手搭建把静态体检变成一条命令3.1 先搭环境JDK、Python、apktool、frida 的版本组合以 Ubuntu 机器为例下面的命令会装一套最基础的逆向环境。注意安装时把开源的包管理器源保持默认这里不涉及额外代理主要是版本兼容问题。apt update apt install -y openjdk-17-jdk python3 python3-pip unzip pip3 install androguard frida-tools wget https://github.com/iBotPeaches/Apktool/releases/download/v2.9.0/apktool_2.9.0.jar -O apktool.jar chmod x apktool.jar装完检查java -version python3 -c import androguard; print(androguard.__version__) frida --version这段里的关键参数是 Java 版本。apktool 2.9 对 Java 11 和 Java 17 都比较友好但如果你同时还要跑老项目里的 Gradle 插件JDK 8 可能更省事。“逆向助手的版本组合”比工具数量重要我吃过一次亏frida-server 和 python 侧的 frida 小版本不一致时客户端不会主动报错只会一直在waiting for device上打转所以建议把frida --version的输出记录到笔记里。3.2 第一条体检命令用 androguard 读包名、权限和组件先用最简单的方式把 APK 的“身份证”读出来。创建一个inspect.pyimport sys from androguard.core.bytecodes.apk import APK apk APK(sys.argv[1]) print(包名:, apk.get_package()) print(版本名:, apk.get_androidversion_name()) print(版本号:, apk.get_androidversion_code()) for permission in apk.get_permissions(): print(权限:, permission) for activity in apk.get_activities(): print(Activity:, activity)逻辑说明APK对象直接解析 APK 的中央目录和二进制 XML不需要启动任何模拟器。get_permissions()返回的是应用申请的所有权限字符串get_activities()列出组件。注意这段代码假定输入的 APK 格式正常如果遇到畸形文件会抛出ResParserException更健壮的写法是加一层 try/except 后跳过。运行方式python3 inspect.py test.apk apk_info.txt这段代码的意义在于让“体检”成为后续所有分析的入口。你可以在拿到任何陌生 APK 后先跑一遍确认包名和申请权限是否匹配再决定要不要继续深挖。很多看起来复杂的 App第一步权限列表就对不上之后的所有定向分析都基于这一张清单。3.3 输出一份可归档的分析报告光打印到终端不够逆向分析通常要反复回看而且报告最好能落在工作目录形成“一个 APK 一个目录”的现场。我会在脚本里把输出写成结构化文件import sys, json, os from androguard.core.bytecodes.apk import APK apk APK(sys.argv[1]) out_dir analysis_ apk.get_package() os.makedirs(out_dir, exist_okTrue) report { package: apk.get_package(), version_name: apk.get_androidversion_name(), permissions: apk.get_permissions(), activities: apk.get_activities(), services: apk.get_services(), providers: apk.get_providers(), } with open(os.path.join(out_dir, manifest.json), w, encodingutf-8) as f: json.dump(report, f, indent2, ensure_asciiFalse) strings apk.get_strings() with open(os.path.join(out_dir, strings.txt), w, encodingutf-8) as f: for s in strings: f.write(s \n)这里的apk.get_strings()会从 dex 里捞出字符串常量对查找 URL 和硬编码密钥非常有用。manifet.json 作为结构化结果之后可以被 Python 脚本直接读取用来做一个高亮搜索。你不需要把strings和json分开理解它们是同一份静态信息的不同视角。参数说明ensure_asciiFalse是为了让中文字符串能正常显示indent2则是为了把 json 写成人能读的格式。常见误用是把get_strings()对 APK 对象调用但 androguard 在解析 dex 时会把字符串池合并进来所以这里得到的字符串池更贴近 DEX 的数据比直接解 Zip 重新统计要准确。3.4 一键拆包、重打包、签名把重复劳动收进脚本静态分析只是第一段真正耗时间的是“拆包—改—打包—签名”这条流水线。我一般会给“逆向助手”再加一个rebuild.sh#!/usr/bin/env bash set -euo pipefail TARGET$1 WORK_DIR$2 java -jar apktool.jar d -f $TARGET -o $WORK_DIR # 在这里修改 smali 或资源略过具体补丁逻辑 java -jar apktool.jar b $WORK_DIR -o ${WORK_DIR}_repacked.apk zipalign -f 4 ${WORK_DIR}_repacked.apk ${WORK_DIR}_aligned.apk KEYSTORE${3:-~/.android/debug.keystore} apksigner sign \ --ks $KEYSTORE \ --ks-key-alias androiddebugkey \ --ks-pass pass:android \ --v1-signing-enabled true \ --v2-signing-enabled true \ --out ${WORK_DIR}_signed.apk \ ${WORK_DIR}_aligned.apk参数说明set -euo pipefail保证任意一步失败就立刻中止避免打包出半成品。-f表示解包时强制覆盖旧的WORK_DIR不然第二次运行会提示目录已存在。zipalign -f 4的4表示 4 字节对齐这是 Google 官方推荐的存储对齐方式不对齐可能导致系统在读取资源时多占内存。apksigner的--v1-signing-enabled和--v2-signing-enabled两个开关需要显式打开因为新版 apksigner 默认可能只开 v2遇到老系统只能干瞪眼。这段脚本最大的价值不是“一条命令做完”而是把原来容易漏掉的zipalign和签名开关固定在脚本里。手动操作时我三次里有两次忘开 v1装上后设备报签名错误然后回炉重打。脚本化之后这类低级错误不再占用分析时间。4. 给助手装上动态能力Frida Hook 的三种常用姿势4.1 先验证连接再从列表找到目标 Class动态层的第一步永远是“能不能连通”。把 frida-server 推到设备上后先跑frida-ps -U-U表示 USB 设备。如果你用模拟器可能还要加-e指定模拟器。看到进程列表后再针对目标包名创建 hook。先用objection或者 Frida 的Java.perform列出类和当前 Activityfrida -U -f com.example.target --no-pause -l list_classes.jslist_classes.js内容Java.perform(function () { Java.enumerateLoadedClasses({ onMatch: function (name) { if (name.indexOf(login) ! -1) { console.log(name); } }, onComplete: function () {} }); });逻辑说明enumerateLoadedClasses会把当前进程中已加载的类全部过一遍onMatch里做过滤。这里最常用的场景不是直接搜类名而是搜包名前缀。混淆后的类名往往没有语义但开发者不会把所有包路径都混淆所以按com.xx.前缀能快速锁定业务包。onComplete必须留一个函数否则 Frida 会报空指针这是我调试时踩过的细节。参数要点-f表示启动时注入--no-pause表示注入完成后直接恢复运行。如果你不带--no-pauseApp 会停在第一行代码处等 Frida 的 JS 回调执行完才继续。对大多数分析场景这个暂停没有意义反而会让网络超时所以我会固定加上。4.2 绕过证书校验的通用 hook与 objection 的快捷开关静态分析发现了 HTTPS 请求但抓包的时候发现证书校验过不去。最常见的原因是 App 在 OkHttp 上设置了CertificatePinner或自定义TrustManager。一个很直接的 Frida 脚本Java.perform(function () { var CertificatePinner Java.use(okhttp3.CertificatePinner); CertificatePinner.check.overload(java.lang.String, java.util.List).implementation function (hostname, peerCerts) { console.log(Bypass pinning: hostname); return; }; });这段代码把check方法的实现清空相当于对任意 host 都放行。overload必须写清楚参数类型因为同名方法在 Java 里可能有多个不指定类型 Frida 会报无法选择重载。如果你看不准方法签名可以用Class.getDeclaredMethods()先列一下。实际上android逆向助手里我不太想每次手写这段脚本所以更推荐先用 objection 快速试objection -g com.example.target explore然后在 objection 交互里输入android sslpinning disableobjection 本质是 Frida 的封装sslpinning disable会尝试 patch 常见 SSL pinning 库。它不能百分之百成功因为部分 App 用的是私有 TLS 实现或 native 层证书校验这时就要回到手写 hook。作为助手入口命令是“先 objection、后 handwrite”这样能覆盖八成场景。4.3 把 hook 参数和日志收进统一的入口脚本动态分析不可能只 hook 一个类每次在命令行写-l指向不同 JS 文件很散。我的习惯是让frida调用一个统一入口agent.js它按环境变量切换 hook 模板HOOK_TYPEnetwork frida -U -f com.example.target --no-pause -l agent.jsagent.js里可以做一个 switchconst type process.env.HOOK_TYPE || default; Java.perform(function () { if (type network) { console.log([*] enable network hook); // 这里放网络相关 hook } else if (type login) { console.log([*] enable login hook); // 这里放登录流程相关 hook } });参数说明process.env在 Frida 的 JS 环境里可以直接读取进程环境变量这是很多教程没提的点。用HOOK_TYPE切模板比维护多个 JS 文件更清晰。日志方面我会在命令行加上--runtimev8或者直接重定向输出到文件frida -U -f com.example.target --no-pause -l agent.js frida_log.txt 21 加让 Frida 在后台跑然后继续用logcat看系统日志两边对照。这样可以避免开一堆终端的混乱也是把“动态助手”真正命令化的关键一步。5. 避开逆向助手的 5 个坑从拆包到上机5.1 加固壳怎么识别先看 classes.dex 大小再查 assets现象apktool 解包后smali/classes*里几乎找不到业务类只剩下壳的入口jadx 打开也是一堆空壳这时候如果直接分析会觉得自己找错了目标。原因应用用了 Dex 加固真实 dex 被加密存放在 assets 或 so 中运行时才动态加载。解决先用 androguard 脚本看AndroidManifest.xml中Application类指向哪如果指向的是壳包名里的代理类就可以确认加固。接着再找assets下有没有.dat、.bin这类加密文件或者lib/下有没有壳的 so。对这种目标静态层先放一边改为运行时 dump 内存里的 dex常见做法是用 Frida 遍历ClassLoader的pathList和dexElements把DexFile输出到本地再用 jadx 分析拿到的新 dex。这个过程偶有损坏需要做 dex 修复但至少不会对着空壳瞎忙。5.2 重打包后安装失败签名方案和 minSdk 必须对齐现象重打包后 adb install 报INSTALL_PARSE_FAILED_NO_CERTIFICATES或INSTALL_FAILED_UPDATE_INCOMPATIBLE。原因签名方案与新老设备的 API 不匹配或者重打包时把原签名抹掉但没有重新签全。解决按上一章的apksigner命令执行显式打开--v1-signing-enabled和--v2-signing-enabled。安装前先验证apksigner verify -v --print-certs ${WORK_DIR}_signed.apk返回值里能看到Verified using v1 scheme: true和Verified using v2 scheme: true这两行都出现再安装。另一个容易翻车的点如果你改了AndroidManifest.xml里的minSdkVersion恰好把某个隐藏 API 的调用暴露给老系统那即使签名正确也会闪退。这种问题只能靠回归安装到低版本模拟器上测不能只看签名。5.3 Frida 连不上设备版本不匹配和端口占用是最大玄学现象frida-ps -U能列出进程但frida -U -f com.xxx启动后一直显示waiting for device或直接报unable to connect to remote frida-server。这种现象我在真实项目里遇到太多次多数不是 root 环境的问题而是客户端的frida-tools与设备里的frida-server版本差一位。我通常会先对比版本把设备上的 frida-server 换成和本机frida --version完全一致的版本。其次检查设备端口 27042 是否被占用adb shell netstat -tlnp | grep 27042如果端口被占杀进程后重新启动 frida-server。最后再看 frida-server 有没有带-D参数有些设备需要指定具名进程命名空间frida-server -D能避免多用户场景下的连接串线。这三步做完90% 的“玄学”连接问题都能解决。5.4 Java 层 hook 成功但算法结果还是错误真正逻辑在 native现象Frida 的console.log已经确认 hook 到目标 Java 方法参数也打出来了但继续往下走发现输出结果不符或者某些关键返回值在 native 调用后就被修正。原因JNI 层方法替换了 Java 层的返回值或者重点算法在.so里Java 层只是把输入传进去输出从 native 返回。解决先看System.loadLibrary加载了哪个库再用frida-trace跟踪 native 导出函数frida-trace -U -f com.xxx --no-pause -i Java_*-i后面跟 native 函数的通配符能把 JNI 导出的函数全部打出来观察输入输出。如果确认某个Java_com_example_xxx_encrypt是核心就可以对该函数单独 hook先看参数和返回值再决定要不要 patch native 层。这里的坑在于只改 Java 不看成 native前期的分析结论会被整体推翻所以在动态分析里-i通配符应该比-l更早跑一次。5.5 androguard 分析大 APK 卡成假死内存超限和重复解析现象一个 150 MB 的 APK直接调用AnalyzeAPK后进程内存冲到 2 GB像死了一样。原因AnalyzeAPK会一次性把所有 dex 都解析并构建 cross-reference 图资源多、DEX 数量多的包最终会占用大量内存。解决不要一上来就AnalyzeAPK先用轻量APK对象读 Manifest做初步判断。如果确实需要全量分析只分析单一 DEXimport sys from androguard.core.bytecodes.apk import APK from androguard.core.dex import DEX apk APK(sys.argv[1]) for dex_name in apk.get_dex_names(): with apk.get_dex(dex_name) as f: dex DEX(f.read()) # 按需处理及时释放引用这段代码里我用get_dex_names拿到 dex 列表再逐个get_dex读取避免所有 DEX 同时驻留内存。如果你的脚本需要做类搜索也可以只在当前 DEX 上查结果保守但能保证不把机器跑爆。更极端的做法是全部走命令行工具让 jadx 用 GUI 模式打开把大内存压力留给图形界面。一个小经验扫描strings.txt可以替代部分 DEX 解析许多指标在字符串层就能判断。6. 把助手变成自己的命令习惯从手动到半自动我最早用“Android逆向助手”的思路其实不是在某个固定工程里而是在自己的~/bin目录堆了一串小脚本apk-info、apk-decompile、apk-hook。后来学聪明了把三个脚本统一成analyze.sh每次给一个 APK 跑一遍就会生成完整的现场目录。这个习惯后来救过我好几次三个月后客户问”这个包当时为什么判定有问题”我能从analysis_com.xxx/下翻到当时的 manifest.json 和 frida 日志直接复现结论而不需要重新逆向一遍。进阶的第一步是批量。把命令写成一个循环对指定目录下所有 APK 执行同一套体检for apk in apks/*.apk; do python3 inspect.py $apk reports/$(basename $apk).txt done配合find和xargs还能只在文件大小超过 100 MB 的包上加密分析或者跳过test目录里的固定 APK。这层半自动化虽然简单但每天处理几十个样本时节省的时间非常可观。第二步是给每个样本建缓存。strings.txt、manifest.json、frida_log.txt都属于可复用产物只要原始 APK 没变就不用重复扫。我把这些文件统一放在analysis_包名/下下次修改 smali 前先看有没有历史decompiled_src/有就直接进人目录不再apktool。这样节省的重复解包时间几乎是“渐进式省力”。最后如果愿意折腾还可以把apksigner verify的验证结果也写进报告。但我的建议是不要一次性把自动化做得很重。逆向分析不是流水线很多 dep 依赖临时判断这条 so 值得 hook那段 string 需要上下文才能理解来源。脚本化负责把枯燥的体力活带走真正判断和决策还是要靠人。我现在的工作习惯是每次拿到新 APK先跑三条命令第一条inspect.py看全貌第二条apktool d解资源第三条frida-trace看启动阶段的 JNI 嗅觉。如果这三条指令没有产生“接下来该看哪”的直觉我会回到报告目录重新读一遍 manifest.json 和 strings.txt而不是盲目换工具再扫一遍。希望这个思路能帮到你少走我当时走过的那几条弯路。本文还有配套的精品资源点击获取