简介这是一份面向CTF竞赛选手与移动安全初学者的Android逆向实战资料聚焦APK反编译与安全测试场景适合具备一定Java与Android基础、希望入门移动逆向的技能进阶者。压缩包内仅含1个PDF文档体积约18KB轻量便携便于随时查阅与对照练习。内容围绕APKToolBOX与jadx两款工具展开讲解如何将APK反编译为Java源码、定位MainActivity与FlagActivity等关键类并通过异或运算还原校验逻辑、推导出flag同时涉及应用漏洞检测与修复思路。文档以真实赛题为例完整呈现从工具使用到脚本编写的分析链路读者可借此掌握反编译流程、代码审计方法与常见加密校验的破解技巧积累可复用的逆向排错经验。目前已有473人学习下载适合作为CTF安卓逆向方向的入门参考与实战补充。1. 从一份 ctf逆向安卓篇.pdf 说起安卓逆向到底在逆什么你拿到一个安卓 APK装进模拟器点开是个登录框。你想知道它把密码发去了哪、校验逻辑写在哪、能不能绕过。这就是安卓逆向最朴素的起点。ctf逆向安卓篇.pdf这类资料之所以被反复搜是因为它把 CTF 比赛里安卓方向的题型、工具链和解题套路压缩成了一条可复现的路径。它解决的不是“怎么破解某个 App”而是“面对一个陌生 APK我该按什么顺序拆开它”。适合两类人打 CTF 想拿安卓题分的选手以及做 App 安全评估、需要快速定位校验逻辑的工程师。核心工具绕不开 jadx、APKToolBOX、Frida 这几样后面逐层展开。2. 拆包之前先想清楚安卓逆向的工具链与选型逻辑2.1 为什么是 jadx 和 APKToolBOX 打头阵安卓 APK 本质是个 zip里面装着classes.dexDalvik 字节码、resources.arsc资源索引、AndroidManifest.xml二进制格式和lib/下的 so 库。逆向的第一步永远是“把 dex 变回人能读的 Java”。jadx 干的就是这件事它把 dex 反编译成近似 Java 的代码还带 GUI 和命令行两种模式。APKToolBOX 则更像一个集成入口把 apktool、jadx、dex2jar 这些零散工具串起来省去你手动配环境的时间。选型上有个常见误区新手一上来就装一堆工具结果每个都只会点“打开”。我的建议是先吃透 jadx 一个因为 80% 的 CTF 安卓题反编译出来看 Java 层逻辑就够了。只有遇到加固、so 加密、动态加载才需要往下走。2.2 最小可复现环境三条命令跑通反编译先装 JDK 11 或 17jadx 对高版本 JDK 兼容性更好。然后下载 jadx 的 release 包解压后把bin目录加进 PATH。验证# 检查 jadx 是否可用输出帮助信息 jadx --version # 反编译一个 APK 到指定目录-d 指定输出路径 jadx -d ./output ./target.apk # 只反编译 dex跳过资源加快速度 jadx --no-res -d ./output ./target.apk-d是输出目录--no-res在只关心代码逻辑时能省不少时间。反编译完成后output/sources/下就是 Java 源码output/resources/是资源文件。如果 jadx 报错说某个方法反编译失败别慌那是混淆或复杂控制流导致的换 dex2jar JD-GUI 再看一遍往往能补上。APKToolBOX 的用法更偏图形化但它的命令行模式也值得记# 用 apktool 解包得到 smali 和资源 apktool d ./target.apk -o ./apktool_out # 重新打包改完 smali 后回编 apktool b ./apktool_out -o ./patched.apksmali 是 Dalvik 的汇编表示改逻辑比改 Java 更底层但胜在精确。CTF 里常见的“改一个判断条件就能过验证”用 smali 改一行if-eqz成if-nez就完事。2.3 静态分析的边界什么时候必须上动态静态分析能告诉你“代码长什么样”但告诉不了你“运行时这个变量到底等于几”。遇到字符串加密、反射调用、so 层校验静态就力不从心了。这时候需要动态调试Frida 是最常用的钩子框架。它的逻辑是把一段 JS 注入到目标进程在方法执行前后插桩打印参数和返回值。// Frida 脚本钩住某个类的 check 方法打印入参和返回值 Java.perform(function () { var TargetClass Java.use(com.example.app.MainActivity); TargetClass.check.implementation function (input) { console.log(输入参数: input); var result this.check(input); // 调用原方法 console.log(返回值: result); return result; }; });Java.perform确保在 JVM 加载完成后执行Java.use拿到类引用implementation重写方法体。this.check(input)是调用原始实现不写这句就会递归死循环。跑起来用frida -U -f com.example.app -l hook.js-U连 USB 设备-f启动应用并注入。提示Frida 需要 root 环境或可调试的 APK。CTF 题通常会给你一个可调试的包或者模拟器本身有 root。真机上没 root 的话可以考虑用 objection 的 patch 模式重打包。3. 从 CTF 题面到 flag一条完整的解题链路3.1 拿到 APK 先做三件事看清单、搜字符串、定位入口别急着反编译全部代码。先用aapt dump badging看包名和入口 Activity再用unzip -l列出文件结构确认有没有 so 库、有没有多个 dex。# 查看 APK 的包名、版本、入口 Activity aapt dump badging ./target.apk | grep -E package|launchable-activity # 列出 APK 内文件重点看 lib/ 和 assets/ unzip -l ./target.apk入口 Activity 决定了你从哪个类开始读。CTF 题的校验逻辑通常就写在入口 Activity 的onCreate或某个按钮的onClick里。用 jadx 打开后直接搜关键词flag、check、verify、password、correct。字符串搜索是最高效的入口因为出题人总得把提示或比较结果写在某处。3.2 静态分析实战读懂一段校验逻辑假设搜到这样一个方法// 从 jadx 反编译结果中摘出的典型校验逻辑 public boolean verify(String input) { String encoded Base64.encodeToString(input.getBytes(), Base64.DEFAULT); String reversed new StringBuilder(encoded).reverse().toString(); return reversed.equals(ZmxhZ3t...); }这段逻辑是输入先 Base64 编码再反转字符串最后和硬编码的密文比较。解题就是反过来把密文反转再 Base64 解码。用 Python 三行搞定import base64 cipher ZmxhZ3t... # 从代码里抄出来的密文 reversed_str cipher[::-1] # 反转 flag base64.b64decode(reversed_str).decode() # Base64 解码 print(flag)[::-1]是 Python 切片反转base64.b64decode处理标准 Base64。如果代码里用的是 URL-safe 的 Base64记得把-和_换回和/。这类题在 CTF 里叫“签到题”考的就是你能不能快速定位并逆向一个简单变换。3.3 动态钩子补刀当静态看不到运行时值有些题会把关键字符串加密存在 so 里Java 层只负责调用 native 方法。这时候 jadx 看到的只是native String getFlag();具体逻辑在libnative.so。用 IDA 或 Ghidra 反汇编 so 是正路但如果只是想知道运行时返回值Frida 钩 native 方法更快// 钩 native 方法直接打印返回值 Java.perform(function () { var TargetClass Java.use(com.example.app.NativeLib); TargetClass.getFlag.implementation function () { var ret this.getFlag(); console.log(native 返回: ret); return ret; }; });如果 native 方法不是 staticthis.getFlag()能正常调用。如果是 static用TargetClass.getFlag()直接调。钩上之后运行 App 触发调用控制台就会打出真实返回值。这招在 CTF 里对付“so 加密但 Java 层有调用”的题特别管用。4. 避坑与排查安卓逆向里最容易翻车的五个点4.1 jadx 反编译出来全是乱码或空方法现象打开 jadx某个类的方法体显示// 反编译失败或直接空白。原因通常是代码被混淆ProGuard/R8或用了 jadx 不支持的字节码特性。解决换 jadx 的最新版本或者用 dex2jar 把 dex 转成 jar再用 JD-GUI 打开。如果还是不行直接看 smali虽然可读性差但逻辑是完整的。4.2 Frida 注入报 “unable to find process”现象frida -U -f com.example.app提示找不到进程。原因可能是设备没连上、frida-server 没跑、或者 App 有反调试检测。解决先frida-ps -U确认设备可见再检查 frida-server 是否以 root 权限运行。如果 App 有反调试用frida -U -f com.example.app --no-pause让它在启动时暂停争取注入时间。4.3 改完 smali 回编后安装失败现象apktool b成功但adb install报INSTALL_PARSE_FAILED。原因通常是签名问题。回编后的 APK 没有签名或者签名和原包不一致。解决用keytool生成一个临时签名再用apksigner签上。# 生成签名密钥 keytool -genkey -v -keystore my.keystore -alias mykey -keyalg RSA -keysize 2048 -validity 10000 # 给 APK 签名 apksigner sign --ks my.keystore --ks-key-alias mykey ./patched.apk-validity 10000是天数CTF 临时用足够了。签完再adb install -r覆盖安装。4.4 搜不到关键字符串现象明明知道 flag 格式是flag{...}但 jadx 里搜不到。原因可能是字符串被拆分了、加密了或者存在 so 里。解决先搜flag的一部分比如fla看有没有拼接逻辑。如果完全没有去assets/和res/raw/里翻出题人有时会把密文藏在资源文件里。再不行就上 Frida 钩String.equals看运行时到底在比较什么。4.5 模拟器检测导致 App 闪退现象APK 在真机能跑在模拟器上打开就退。原因App 检测了模拟器特征如ro.kernel.qemu、传感器数量。解决用 Frida 钩掉检测方法或者换一个带 Magisk 的模拟器镜像用 Magisk 隐藏 root 和模拟器特征。CTF 题一般不会加这么强的检测但真实 App 评估时会遇到。5. 进阶技巧用 Frida 批量钩 Java 层方法定位关键逻辑当你面对一个没有明显关键词、逻辑分散在几十个类里的 APK 时逐个读代码效率太低。我的习惯是写一个通用 Frida 脚本批量钩住所有可疑方法让 App 自己“招供”。// 批量钩住指定包下所有类的方法打印调用链 Java.perform(function () { var targetPackage com.example.app; Java.enumerateLoadedClasses({ onMatch: function (className) { if (className.indexOf(targetPackage) 0) { try { var clazz Java.use(className); var methods clazz.class.getDeclaredMethods(); methods.forEach(function (method) { var methodName method.getName(); // 跳过 getter/setter 和构造方法减少噪音 if (methodName.indexOf(get) 0 || methodName.indexOf(set) 0) return; try { clazz[methodName].overloads.forEach(function (overload) { overload.implementation function () { console.log([调用] className . methodName); return overload.apply(this, arguments); }; }); } catch (e) {} }); } catch (e) {} } }, onComplete: function () {} }); });Java.enumerateLoadedClasses遍历已加载的类indexOf(targetPackage) 0过滤出目标包。getDeclaredMethods拿到所有声明的方法跳过 getter/setter 减少日志量。overload.implementation重写方法体打印调用信息后apply原方法。跑起来后操作 App控制台会刷出调用链你就能顺着调用顺序找到关键逻辑。这个脚本的坑在于方法太多时日志会爆炸建议先用--no-res反编译人工筛选出几个可疑类把targetPackage缩到具体类名。另外overload.apply在某些重载方法上会丢参数如果发现返回值不对改用overload.call(this, ...arguments)。验证钩子是否生效可以故意在 App 里触发一个已知方法看控制台有没有输出。如果没有任何日志检查Java.perform是否执行、包名是否写对、类是否在启动时就加载了。有些类是用到才加载这时候需要Java.enumerateClassLoaders配合loader.loadClass动态加载。我自己的习惯是每拿到一个新 APK先跑一遍批量钩子把调用链摸清楚再决定是静态读代码还是继续动态跟踪。这样比一上来就埋头读 jadx 快得多也不容易漏掉藏在深处的校验逻辑。希望帮到你。本文还有配套的精品资源点击获取
简介这是一份面向CTF竞赛选手与移动安全初学者的Android逆向实战资料聚焦APK反编译与安全测试场景适合具备一定Java与Android基础、希望入门移动逆向的技能进阶者。压缩包内仅含1个PDF文档体积约18KB轻量便携便于随时查阅与对照练习。内容围绕APKToolBOX与jadx两款工具展开讲解如何将APK反编译为Java源码、定位MainActivity与FlagActivity等关键类并通过异或运算还原校验逻辑、推导出flag同时涉及应用漏洞检测与修复思路。文档以真实赛题为例完整呈现从工具使用到脚本编写的分析链路读者可借此掌握反编译流程、代码审计方法与常见加密校验的破解技巧积累可复用的逆向排错经验。目前已有473人学习下载适合作为CTF安卓逆向方向的入门参考与实战补充。1. 从一份 ctf逆向安卓篇.pdf 说起安卓逆向到底在逆什么你拿到一个安卓 APK装进模拟器点开是个登录框。你想知道它把密码发去了哪、校验逻辑写在哪、能不能绕过。这就是安卓逆向最朴素的起点。ctf逆向安卓篇.pdf这类资料之所以被反复搜是因为它把 CTF 比赛里安卓方向的题型、工具链和解题套路压缩成了一条可复现的路径。它解决的不是“怎么破解某个 App”而是“面对一个陌生 APK我该按什么顺序拆开它”。适合两类人打 CTF 想拿安卓题分的选手以及做 App 安全评估、需要快速定位校验逻辑的工程师。核心工具绕不开 jadx、APKToolBOX、Frida 这几样后面逐层展开。2. 拆包之前先想清楚安卓逆向的工具链与选型逻辑2.1 为什么是 jadx 和 APKToolBOX 打头阵安卓 APK 本质是个 zip里面装着classes.dexDalvik 字节码、resources.arsc资源索引、AndroidManifest.xml二进制格式和lib/下的 so 库。逆向的第一步永远是“把 dex 变回人能读的 Java”。jadx 干的就是这件事它把 dex 反编译成近似 Java 的代码还带 GUI 和命令行两种模式。APKToolBOX 则更像一个集成入口把 apktool、jadx、dex2jar 这些零散工具串起来省去你手动配环境的时间。选型上有个常见误区新手一上来就装一堆工具结果每个都只会点“打开”。我的建议是先吃透 jadx 一个因为 80% 的 CTF 安卓题反编译出来看 Java 层逻辑就够了。只有遇到加固、so 加密、动态加载才需要往下走。2.2 最小可复现环境三条命令跑通反编译先装 JDK 11 或 17jadx 对高版本 JDK 兼容性更好。然后下载 jadx 的 release 包解压后把bin目录加进 PATH。验证# 检查 jadx 是否可用输出帮助信息 jadx --version # 反编译一个 APK 到指定目录-d 指定输出路径 jadx -d ./output ./target.apk # 只反编译 dex跳过资源加快速度 jadx --no-res -d ./output ./target.apk-d是输出目录--no-res在只关心代码逻辑时能省不少时间。反编译完成后output/sources/下就是 Java 源码output/resources/是资源文件。如果 jadx 报错说某个方法反编译失败别慌那是混淆或复杂控制流导致的换 dex2jar JD-GUI 再看一遍往往能补上。APKToolBOX 的用法更偏图形化但它的命令行模式也值得记# 用 apktool 解包得到 smali 和资源 apktool d ./target.apk -o ./apktool_out # 重新打包改完 smali 后回编 apktool b ./apktool_out -o ./patched.apksmali 是 Dalvik 的汇编表示改逻辑比改 Java 更底层但胜在精确。CTF 里常见的“改一个判断条件就能过验证”用 smali 改一行if-eqz成if-nez就完事。2.3 静态分析的边界什么时候必须上动态静态分析能告诉你“代码长什么样”但告诉不了你“运行时这个变量到底等于几”。遇到字符串加密、反射调用、so 层校验静态就力不从心了。这时候需要动态调试Frida 是最常用的钩子框架。它的逻辑是把一段 JS 注入到目标进程在方法执行前后插桩打印参数和返回值。// Frida 脚本钩住某个类的 check 方法打印入参和返回值 Java.perform(function () { var TargetClass Java.use(com.example.app.MainActivity); TargetClass.check.implementation function (input) { console.log(输入参数: input); var result this.check(input); // 调用原方法 console.log(返回值: result); return result; }; });Java.perform确保在 JVM 加载完成后执行Java.use拿到类引用implementation重写方法体。this.check(input)是调用原始实现不写这句就会递归死循环。跑起来用frida -U -f com.example.app -l hook.js-U连 USB 设备-f启动应用并注入。提示Frida 需要 root 环境或可调试的 APK。CTF 题通常会给你一个可调试的包或者模拟器本身有 root。真机上没 root 的话可以考虑用 objection 的 patch 模式重打包。3. 从 CTF 题面到 flag一条完整的解题链路3.1 拿到 APK 先做三件事看清单、搜字符串、定位入口别急着反编译全部代码。先用aapt dump badging看包名和入口 Activity再用unzip -l列出文件结构确认有没有 so 库、有没有多个 dex。# 查看 APK 的包名、版本、入口 Activity aapt dump badging ./target.apk | grep -E package|launchable-activity # 列出 APK 内文件重点看 lib/ 和 assets/ unzip -l ./target.apk入口 Activity 决定了你从哪个类开始读。CTF 题的校验逻辑通常就写在入口 Activity 的onCreate或某个按钮的onClick里。用 jadx 打开后直接搜关键词flag、check、verify、password、correct。字符串搜索是最高效的入口因为出题人总得把提示或比较结果写在某处。3.2 静态分析实战读懂一段校验逻辑假设搜到这样一个方法// 从 jadx 反编译结果中摘出的典型校验逻辑 public boolean verify(String input) { String encoded Base64.encodeToString(input.getBytes(), Base64.DEFAULT); String reversed new StringBuilder(encoded).reverse().toString(); return reversed.equals(ZmxhZ3t...); }这段逻辑是输入先 Base64 编码再反转字符串最后和硬编码的密文比较。解题就是反过来把密文反转再 Base64 解码。用 Python 三行搞定import base64 cipher ZmxhZ3t... # 从代码里抄出来的密文 reversed_str cipher[::-1] # 反转 flag base64.b64decode(reversed_str).decode() # Base64 解码 print(flag)[::-1]是 Python 切片反转base64.b64decode处理标准 Base64。如果代码里用的是 URL-safe 的 Base64记得把-和_换回和/。这类题在 CTF 里叫“签到题”考的就是你能不能快速定位并逆向一个简单变换。3.3 动态钩子补刀当静态看不到运行时值有些题会把关键字符串加密存在 so 里Java 层只负责调用 native 方法。这时候 jadx 看到的只是native String getFlag();具体逻辑在libnative.so。用 IDA 或 Ghidra 反汇编 so 是正路但如果只是想知道运行时返回值Frida 钩 native 方法更快// 钩 native 方法直接打印返回值 Java.perform(function () { var TargetClass Java.use(com.example.app.NativeLib); TargetClass.getFlag.implementation function () { var ret this.getFlag(); console.log(native 返回: ret); return ret; }; });如果 native 方法不是 staticthis.getFlag()能正常调用。如果是 static用TargetClass.getFlag()直接调。钩上之后运行 App 触发调用控制台就会打出真实返回值。这招在 CTF 里对付“so 加密但 Java 层有调用”的题特别管用。4. 避坑与排查安卓逆向里最容易翻车的五个点4.1 jadx 反编译出来全是乱码或空方法现象打开 jadx某个类的方法体显示// 反编译失败或直接空白。原因通常是代码被混淆ProGuard/R8或用了 jadx 不支持的字节码特性。解决换 jadx 的最新版本或者用 dex2jar 把 dex 转成 jar再用 JD-GUI 打开。如果还是不行直接看 smali虽然可读性差但逻辑是完整的。4.2 Frida 注入报 “unable to find process”现象frida -U -f com.example.app提示找不到进程。原因可能是设备没连上、frida-server 没跑、或者 App 有反调试检测。解决先frida-ps -U确认设备可见再检查 frida-server 是否以 root 权限运行。如果 App 有反调试用frida -U -f com.example.app --no-pause让它在启动时暂停争取注入时间。4.3 改完 smali 回编后安装失败现象apktool b成功但adb install报INSTALL_PARSE_FAILED。原因通常是签名问题。回编后的 APK 没有签名或者签名和原包不一致。解决用keytool生成一个临时签名再用apksigner签上。# 生成签名密钥 keytool -genkey -v -keystore my.keystore -alias mykey -keyalg RSA -keysize 2048 -validity 10000 # 给 APK 签名 apksigner sign --ks my.keystore --ks-key-alias mykey ./patched.apk-validity 10000是天数CTF 临时用足够了。签完再adb install -r覆盖安装。4.4 搜不到关键字符串现象明明知道 flag 格式是flag{...}但 jadx 里搜不到。原因可能是字符串被拆分了、加密了或者存在 so 里。解决先搜flag的一部分比如fla看有没有拼接逻辑。如果完全没有去assets/和res/raw/里翻出题人有时会把密文藏在资源文件里。再不行就上 Frida 钩String.equals看运行时到底在比较什么。4.5 模拟器检测导致 App 闪退现象APK 在真机能跑在模拟器上打开就退。原因App 检测了模拟器特征如ro.kernel.qemu、传感器数量。解决用 Frida 钩掉检测方法或者换一个带 Magisk 的模拟器镜像用 Magisk 隐藏 root 和模拟器特征。CTF 题一般不会加这么强的检测但真实 App 评估时会遇到。5. 进阶技巧用 Frida 批量钩 Java 层方法定位关键逻辑当你面对一个没有明显关键词、逻辑分散在几十个类里的 APK 时逐个读代码效率太低。我的习惯是写一个通用 Frida 脚本批量钩住所有可疑方法让 App 自己“招供”。// 批量钩住指定包下所有类的方法打印调用链 Java.perform(function () { var targetPackage com.example.app; Java.enumerateLoadedClasses({ onMatch: function (className) { if (className.indexOf(targetPackage) 0) { try { var clazz Java.use(className); var methods clazz.class.getDeclaredMethods(); methods.forEach(function (method) { var methodName method.getName(); // 跳过 getter/setter 和构造方法减少噪音 if (methodName.indexOf(get) 0 || methodName.indexOf(set) 0) return; try { clazz[methodName].overloads.forEach(function (overload) { overload.implementation function () { console.log([调用] className . methodName); return overload.apply(this, arguments); }; }); } catch (e) {} }); } catch (e) {} } }, onComplete: function () {} }); });Java.enumerateLoadedClasses遍历已加载的类indexOf(targetPackage) 0过滤出目标包。getDeclaredMethods拿到所有声明的方法跳过 getter/setter 减少日志量。overload.implementation重写方法体打印调用信息后apply原方法。跑起来后操作 App控制台会刷出调用链你就能顺着调用顺序找到关键逻辑。这个脚本的坑在于方法太多时日志会爆炸建议先用--no-res反编译人工筛选出几个可疑类把targetPackage缩到具体类名。另外overload.apply在某些重载方法上会丢参数如果发现返回值不对改用overload.call(this, ...arguments)。验证钩子是否生效可以故意在 App 里触发一个已知方法看控制台有没有输出。如果没有任何日志检查Java.perform是否执行、包名是否写对、类是否在启动时就加载了。有些类是用到才加载这时候需要Java.enumerateClassLoaders配合loader.loadClass动态加载。我自己的习惯是每拿到一个新 APK先跑一遍批量钩子把调用链摸清楚再决定是静态读代码还是继续动态跟踪。这样比一上来就埋头读 jadx 快得多也不容易漏掉藏在深处的校验逻辑。希望帮到你。本文还有配套的精品资源点击获取
