简介一份面向CTF安卓逆向方向的入门级PDF笔记适合刚接触Android应用逆向、希望在CTF赛题中快速上手APKToolBOX与jadx的读者。内容以实际赛题为例演示如何用APKToolBOX解包APK、用jadx定位MainActivity与FlagActivity再结合Java代码逐行分析核心校验逻辑例如将用户输入与固定字节数组按23异或比较的常见加密方式并给出对应Python脚本还原flag帮助读者建立“逆向定位-反编译阅读-脚本求解”的完整思路。资源为单个PDF文件体积仅18KB便于随时查阅已由473人学习适合作为安卓逆向入门的第一份压缩型资料。文档还覆盖Android应用安全测试的基础视角能引导初学者从漏洞检测角度理解APK结构、组件入口与敏感逻辑是一份小而精的速查型笔记。1. CTF 逆向安卓篇到底在解决什么一道 APK 题的完整攻击面CTF 逆向里安卓题和传统 Windows PE 题最大差别是样本形态。一道「ctf逆向安卓篇」的题目通常给你一个 APK看起来是个 App实际是一个反调试、加密、混淆都可能的黑匣子。你的目标是从这个盒子里找到校验输入的函数还原出正确输入或者让校验恒真。它能解决的问题很具体面对一个 APK你应该先看哪个文件、用什么工具把 dex 和 so 变成可读代码、为什么动态 hook 比反复安装签名包更快。适合刚进 CTF 想找方向的入门选手也适合想做移动安全或「java 逆向解密」的 Android 开发。2. 先把样本变成可读代码安卓逆向的入口文件与最小工具链2.1 APK 解包后你会看到什么dex、so、assets 与 AndroidManifestAPK 本质是一个 zip 包。不要一上来就用手机安装先解开看里面有什么。常见做法是unzip -q challenge.apk -d apk_out tree -L 2 apk_out解包后最值得关注的对象按优先级排是这样AndroidManifest.xml 决定入口classes.dex 是 Java 层全部代码lib/arm64-v8a 或 lib/armeabi-v7a 下的 .so 是 Native 层算法assets 和 res 里可能藏着加密数据或 flag。部分样本会把 flag 直接放在资源文件的尾部这类题目其实更接近杂项。AndroidManifest.xml 在 APK 里是二进制格式直接用 unzip 打开只能看到乱码。这一步要交给 apktoolapktool d challenge.apk -o apk_srcapktool 会把二进制清单转成可读 XML把 classes.dex 转成 smali还会把资源按原始结构铺开。当你需要改逻辑重新打包时apktool 是绕不开的。如果只是看 Java 层我更习惯直接拖进 jadx它给出的是还原后的 Java 代码不是 smali阅读效率高很多。静态分析入口就这么定下来jadx 看 Javaapktool 管解包重打包IDA 留到 so。2.2 选一个不拖后腿的运行环境模拟器、adb 与联网问题这里绕不开「安卓模拟器哪个最好」的问题。我的答案是没有最好只有能不能满足两个硬条件——能 root网络稳定。CTF 样本不一定都能在主流娱乐模拟器上跑因为部分题会检测 ro.kernel.qemu、Build.FINGERPRINT 这些特征。优先用 Android Studio 自带 AVDAPI 选 2830 的 x86_64 镜像兼容性和可调试性比较平衡太新的 API 反调试更主动太老的镜像又跑不动依赖高版本 SDK 的样本。AVD 默认的 NAT 联网一般不需要动。如果你用第三方模拟器遇到「安卓虚拟机怎么联网」的问题先别急着改配置用 adb 进去看网络状态adb shell ip addr show wlan0 adb shell ping -c 3 223.5.5.5 adb shell getprop net.dns1这段命令先看网卡是否拿到地址再测真实连通性。223.5.5.5 只是公共 DNS 地址用来确认网络通路getprop net.dns1 看系统 DNS 是否为空。常见坑是之前改过 DNS 或者桥接异常导致 App 的联网请求一直卡住。切回 DHCP 或在系统设置里补一个可用的 DNS 地址就能解决。至于 App 内部能不能联网先确认 targetSDK 是否允许明文流量低版本默认允许高版本需要 usesCleartextTraffic 或网络安全配置。如果样本检测模拟器换真机或 Frida hook 检测点是后面章节的内容。2.3 最小工具链组合jadx 静态看、Frida 动态验、IDA 补 native工具不需要贪多。我一般固定用四样jadx 看 Java 层apktool 负责解包和重打包Frida 做运行期 hookIDA 或 Ghidra 看 so。选型理由很简单按照「先静态后动态、先 Java 后 Native」的顺序这套组合覆盖 CTF 安卓逆向 90% 的样本。其中 Frida 和 IDA 的配合尤其重要Frida 适合验证调用关系IDA 适合还原算法细节。jadx 命令行可以直接把 dex 还原并输出搜索目录jadx -d java_src challenge.apk grep -rn flag java_src | head -30这里的-d指定输出目录grep 是早期定位手段。更精确的搜索我一般用 jadx 图形界面里的全局搜索能直接跳到调用链。Frida 不用急着装一堆插件一个 frida-server 推到模拟器本机装 frida-tools 就够了。Frida 强在不用重新签名在运行时替换类方法后面会反复用到。so 分析工具选 IDA 还是 Ghidra 取决于习惯。IDA 的 F5 反编译更适合快速读伪代码Ghidra 免费且批量分析方便。遇到动态注册的 JNI 函数时IDA 能更直观地看到 RegisterNatives 的调用参数所以我个人会把 IDA 排在前面。工具链的边界要心里有数jadx 只能还原 Java 层Frida 只能看到运行期行为真正进入算法还要靠 IDA。2.4 最小闭环演示安装、启动、hook 一个函数工具齐了以后第一次练手不要碰难样本。用一个自定义的测试 APK 或者 ctfshow 等平台上的入门题跑通这个最小动作adb install -r challenge.apk frida -U -f com.example.ctf -l hook.js --no-pause-f表示冷启动会先拉起进程再注入进程起来后可以在 hook.js 里只打印一个日志确认注入成功。成功标准是控制台输出你的打印内容而不是 App 闪退。先把这条路跑通再进后续章节。如果这个闭环失败优先排查 frida-server 和本机 frida-tools 的版本是否对应以及 adb 设备名是否被正确识别。3. Java 层逆向实战用 jadx 定位关键函数再用 Frida 改掉校验3.1 从反编译代码里快速定位入口搜索 flag、check、encrypt 与调用链绝大多数 CTF 安卓题的 Java 层不会写得很复杂。入口就是 MainActivity 的按钮点击校验函数通常叫 check、verify、getFlag、encrypt 之类。先用 jadx 打开 APK在左侧目录里找到包名对应的目录展开看 MainActivity 和 Application。如果关键逻辑在 Application 的 attachBaseContext 或 onCreate 里那么即使不点按钮代码也会被执行这类题通常和反调试绑定。接下来用关键词做全局搜索。最优先搜 flag然后搜 ctf、check、encrypt、key。在 jadx 图形界面里按文件名搜索或按代码搜索都行用命令行的做法是grep -rn flag java_src/com/example/ctf/ grep -rn checkFlag\|verify\|encrypt java_src/com/example/ctf/搜索到候选函数后不要急着分析加密算法。先看它的调用者是按钮点击回调还是 Activity 的 onCreate传入参数是输入框的字符串还是固定字符串。如果是固定字符串说明题目可能不是让你输入 flag而是让你计算某个加密结果这种题型经常和 ctf 密码学混在一起需要先确定是「校验输入」还是「生成数据」。定位到关键函数后还要看方法签名。如果方法声明带着 native那么函数体在 so 里Java 层只剩一个壳本章后半段的 hook 方法仍然适用但真正的算法要去第 4 章看。如果方法只是一个普通私有函数先用打印堆栈的方式确认调用链再判断要不要改返回值。3.2 最小 Frida 脚本打印参数、修改返回值、主动调用加密函数定位到 Java 层函数后最快验证思路是否正确的方法是 Frida。把脚本保存为 hook.jsJava.perform(function () { var Activity Java.use(com.example.ctf.MainActivity); Activity.checkFlag.implementation function (input) { console.log(input input); var result this.checkFlag(input); console.log(result result); return true; }; });脚本逻辑分成三步先用 Java.perform 把回调放进 Java 运行时线程再用 Java.use 拿到目标类最后用 implementation 替换原方法。里面的 this.checkFlag(input) 是调用原逻辑这样你可以先看原始返回值再决定是强制返回 true 还是继续分析算法。强制返回 true 只是打点不改变输入很多题能直接出结果但如果是 native 比较Java 层返回 true 可能不被采纳原因在 native 章节。运行脚本的命令frida -U -f com.example.ctf -l hook.js --no-pause-U 表示通过 adb 连接设备-f 冷启动目标应用--no-pause 让脚本注入后立刻继续运行避免等进程暂停时被样本检测出异常。如果设备名不是常规 emulator-5554先用 adb devices 看序列号再用 frida -D 序列号指定设备。如果只想看参数不想改逻辑把 implementation 换成Activity.checkFlag.implementation function (input) { console.log(new Error().stack); return this.checkFlag(input); };打印堆栈能帮你快速确定是谁调用了 checkFlag这比人肉追代码快得多。遇到复杂的多层调用时先打堆栈再决定 hook 哪一层是效率最高的做法。3.3 容易被忽视的参数规则类名、重载、native 方法Frida 报错通常有两个原因类名写错和重载方法选错。Java.use 必须传完整类名不能只写 MainActivity内部类用 com.example.ctf.MainActivity$Inner 这种格式。如果目标类有多个同名方法Frida 会要求你用 overload 指定参数类型例如Java.perform(function () { var Util Java.use(com.example.ctf.EncryptUtil); Util.encode.overload(java.lang.String, int) .implementation function (str, mode) { console.log(str str mode mode); return this.encode(str, mode); }; });overload 的参数写的是 JNI 类型描述java.lang.String 对应字符串int 对应整数。不写 overload 时 Frida 会直接抛异常提示你选择哪个重载。另一个高频问题是返回值类型Java 方法返回 int 时你 return 一个 true 会类型不匹配返回 0 且打印原结果才是安全的。还有一个容易忽略的点native 修饰的方法。jadx 里显示成public native String encrypt(String input)说明方法实现不在 Java 层。Frida 依然可以 hook 这个声明但 this.encrypt(input) 调用的是 native 实现。如果你想看算法需要去 so 里找符号。常见误区是看到 jadx 里只有一个方法头就以为题目是「java 逆向解密」其实真正算法早被塞进 so 了。判断标准很简单方法有没有 native 关键字以及 jadx 里是否出现 System.loadLibrary。4. Native 层逆向实战IDA 加载 so 后从哪读起4.1 先判断 Java 层是不是空壳哪些场景必须进 soFrida 打印堆栈并不能帮你看到 native 内部。当你发现以下三个信号时基本可以确定要进 so第一Java 层函数用 native 声明第二字符串全被拆成字节数组内存里拼出来第三onCreate 里调用 System.loadLibrary(native-lib)。另一个信号是反调试调不出来jdb 附加后进程退出说明 anti-debug 大概率在 native 初始化阶段。CTF 样本里 native 层承担两种职责实现算法或者做完整性校验。算法类的典型做法是把 flag 的校验放在 C/C 里Java 层只接收布尔结果完整性校验类会在 JNI_OnLoad 里拿到 Java 层方法指针用动态注册方式替换或补充校验逻辑。这两种场景都需要你先拿到 so 的加载方向。一个最典型的 native 校验题长这样extern C JNIEXPORT jboolean JNICALL Java_com_example_ctf_MainActivity_check(JNIEnv *env, jobject, jstring input) { const char *str env-GetStringUTFChars(input, nullptr); for (int i 0; i 16; i) { if ((str[i] ^ key[i]) ! enc[i]) return false; } return true; }这种代码你在 IDA 里看到的就是 xor 指令加一处 memcmp。还原 flag 时只需要把 enc 和 key 取出来顺序反过来不用真正去跑 ARM 指令。很多新手看到一堆指令就慌了其实这类题比 Java 层的 HashMap 比较更直接。4.2 在 IDA 里找 JNI 入口从导出函数到动态注册表拿到 so 后先确认架构。解包 APK 时的 lib 目录通常会同时出现 arm64-v8a 和 armeabi-v7aIDA 加载 arm64 版本就用 ARM64 格式加载 32 位版本用 ARM模拟器上跑 x86 样本时加载 x86 版本。架构选错会导致反编译结果乱成一团。加载后用 IDA 的 Exports 窗口搜索 Java_ 前缀。直接导出函数长这样JNIEXPORT jstring JNICALL Java_com_example_ctf_MainActivity_getFlag(JNIEnv *env, jobject thiz) { // 逐字节拼接字符串 return env-NewStringUTF(result); }这类函数直接用 F5 就能读伪代码。如果 Exports 里没有 Java_ 开头的符号说明是动态注册函数通过 JNI_OnLoad 里的 RegisterNatives 绑定 Java 层方法名和 native 函数指针。你需要在 IDA 里打开 JNI_OnLoad 的反编译视图找到类似 RegisterNatives(env, clazz, gMethods, 3) 的调用其中 gMethods 是方法表前几个字段分别是方法名、签名、函数指针。跟着第三个字段跳转就能定位到真正的实现函数。这里的关键是不要从 Java 层函数名猜测 so 里的名字。动态注册后导出符号和一个随机生成的字符串一模一样IDA 里看不出业务含义只能靠 gMethods 和 JNI 名称建立映射。如果样本还用了混淆的 so用 Frida 的 Module.enumerateExports 列出所有导出函数然后逐个比对参数特征也是一个办法。4.3 识别常见加密算法常量、循环结构和 Frida 验证进了 so 实现后算法识别的第一手段是常量。IDA 反编译的伪代码里出现 0x9E3779B9基本就是 TEA 系出现长串 256 字节 S 盒优先考虑 AES出现同样长度的 S 盒且伴随 swap 循环多半是 RC4。CTF 题目不会强求你用库而是把算法简化后让你手动还原所以你可以先看有没有大表。用一段 TEA 循环做例子反编译出来的 C 伪代码常长这样uint32_t v0 input[0], v1 input[1]; uint32_t sum 0; uint32_t delta 0x9E3779B9; for (int i 0; i 32; i) { sum delta; v0 ((v1 4) k[0]) ^ (v1 sum) ^ ((v1 5) k[1]); v1 ((v0 4) k[2]) ^ (v0 sum) ^ ((v0 5) k[3]); }看到 4 和 5 同时出现、循环 32 次、delta 固定这基本就是 TEA/XTEA 家族。还原算法时建议先固定 key再把输入改成你控制的一个字符串用 Frida 把 native 函数的输入输出打出来验证你的反编译结果是否匹配真实运行。Frida hook native 方法的方式是var ptr Module.findExportByName(libnative-lib.so, Java_com_example_ctf_MainActivity_checkWithNative); if (ptr) { Interceptor.attach(ptr, { onEnter: function (args) { var env Java.vm.getEnv(); var inputStr env.getStringUtfChars(args[3], null).readCString(); console.log(input inputStr); }, onLeave: function (retval) { var env Java.vm.getEnv(); var resultStr env.getStringUtfChars(retval, null).readCString(); console.log(result resultStr); } }); }这段代码有两条常见出错点一是 JNI 函数的前两个参数永远是 JNIEnv* 和 jobject业务参数从 args[2] 开始具体取决于方法签名二是 getStringUtfChars 返回的是指针后面必须跟 readCString() 才有内容。任何一套 native 题先用这个脚本把输入输出打出来再对照 IDA 伪代码能少走很多弯路。5. 安卓逆向高频避坑现场模拟器、签名校验、反调试与混淆5.1 模拟器联网失败或应用安装不上现象、原因与解决现象模拟器能打开但目标 App 一直提示无网络或者安装时直接 INSTALL_FAILED_NO_MATCHING_ABIS。这类问题在 CTF 环境里最常见也最容易被当成系统坏了。原因有两个层面网络层面通常是模拟器的 DNS 或网络桥接配置异常App 的请求目标域名解析失败安装失败则基本都是 so 架构不匹配——APK 只带了 arm64-v8a 的 so而你的模拟器是 x86_64 的。CTF 样本也经常故意只放 arm so 阻止模拟器直接运行。解决先确认 ABIadb shell getprop ro.product.cpu.abi如果是 x86_64 就找一个支持 arm 翻译的镜像或者直接上真机。网络问题先做adb shell ping -c 3 223.5.5.5确认基础连通再用adb shell getprop net.dns1看 DNS 地址为空就切回 DHCP。如果 App 能联网但请求失败检查 targetSdk 和 usesCleartextTraffic高版本默认禁明文需要临时加一条网络安全配置。注意这里调整的是模拟器系统不是应用逻辑。5.2 Frida 注入后闪退签名校验和 root 检测的绕过顺序现象执行frida -U -f com.example.ctf -l hook.js --no-pause后App 启动图标闪一下就没了控制台没有任何打印。原因样本在 Application 阶段做了签名校验对比 PackageManager 拿到的签名和内置签名。Frida 注入本身不改 APK所以签名一致但 Frida 需要 frida-server 运行在 root 环境root 检测被触发也会提前退出。解决先判断是签名还是 root 检测。用 jadx 搜索 signatures、getPackageInfo、su、isRooted看检测函数里的返回点用 Frida 把它 hook 掉。一个通用做法是在 attachBaseContext 之后用 Java.use(java.lang.Runtime) 清掉 exec 调用但更干净的是找到检测函数并固定返回值。另外一个经验是先跑 objection explore 的 root disable 命令处理 root 检测签名校验再单独 hook。若检测点很多直接用 apktool 改 smali 删除调用再重打包往往比一个个 hook 快。重打包后签名变化所以要在改完逻辑后重新做一次签名校验绕过或者直接安装到未启用签名校验的环境。5.3 IDA 附加 so 调试总被打断反调试先处理还是后处理现象把 android_server 推到设备并附加进程后静态看代码没问题但一开始调试会话App 就崩溃或自动退出。查看 /proc/pid/status 时发现 TracerPid 不为 0 后又被检测到。原因so 在 JNI_OnLoad 阶段创建了反调试线程循环读取 /proc/self/status 监测 TracerPid一旦发现被 ptrace 就 kill(getpid())。这类检测常见于 native 样本静态看时不会被触发一旦调试器附加就发作。解决能静态分析就尽量静态分析。用 IDA 加载 so 后先定位 JNI_OnLoad把反调试线程的创建函数上下文读懂手动跳过。如果必须动态观察数据先用 Frida 试一轮因为很多只针对调试器附加流程的检测Frida 不一定命中不行就改 smali在 System.loadLibrary 后延迟调用或直接 patch 掉反调试线程。注意改了逻辑要重打包又要面对签名检测所以我的习惯是先用 Frida 试一轮再考虑 patch。5.4 混淆、加壳、代码抽取让 jadx 失效用内存里真实函数救场现象jadx 打开后所有类名都是 a.a.a方法体全是空壳字符串全部变成单字符拼接。这不是你漏了什么而是样本做了加固或代码抽取。原因加固会在运行时把真实 dex 解密并动态加载静态 APK 里的 dex 只是一个加载器抽取壳则只留下空方法真实代码由 so 在调用时填回内存。jadx 分析的原 dex 里根本没有业务逻辑。解决先用 Frida 在应用运行后枚举已经加载的类确认真实类名。常见做法是用 frida-dexdump 从内存里 dump 出 dex再用 jadx 分析 dump 文件。这个方向比较吃经验但有一个不需要脱壳的判断方法在 Frida 里 Java.enumerateLoadedClasses 过滤样本包名如果能看到 jadx 里不存在的类说明真实逻辑已经被运行期加载。锁定类名后直接 hook 对应方法依然能在不拿完整 dex 的情况下还原算法。5.5 伪加密和资源隐写容易浪费时间的两个岔路口现象解 APK 时 unzip 报错说某个文件 CRC 不对apktool 却可能正常解包。或者整个逻辑分析完发现 flag 藏在 assets/logo.png 尾部。原因zip 伪加密把条目标记成加密但数据实际没有加密这是 CTF 杂项题的惯用手法资源隐写则是把字符串或二维码直接追加到图片或音频后面静态分析时不会注意。解决遇到 unzip 报错不要急着修系统先用 010 Editor 打开 APK定位中央目录里的对应条目把通用标记位从 09 00 改成 00 00再重新解压。apktool 大多数情况下能正常处理这种伪加密。分析完 Java 和 native 还没有 flag 时回头看一下 assets 和 res/raw用 file 命令识别真实类型用 binwalk 扫边界。这一条经常和逆向题混在一起不少新手在算法里绕几个小时最后发现答案是张二维码。6. 出 flag 前的最后一轮验证我会固定走的检查顺序无论前面分析多顺我拿到 APK 后都会按同一套顺序验证避免在错误方向浪费时间先看包名和主入口再全局搜字符串然后用 Frida 打堆栈定位调用链发现 native 声明就切到 IDA最终算法一定用独立脚本跑一遍。下表是我常用的检查顺序检查项常用命令/工具通过条件主入口aapt dump badging challenge.apk确认 launchable-activityJava 层代码jadx -d java_src challenge.apk能看到 MainActivity 全貌动态调用链frida -U -f com.example.ctf -l stack.js --no-pause打印堆栈定位关键函数native 符号Module.enumerateExports(libnative-lib.so)确认导出或动态注册算法验证独立 Python 脚本复现加密输出与 Frida 打印一致最后一步验证我很少在手机上做而是把算法抄到本机脚本里。比如 TEA 就写一个 30 行的 Python输入随机字符串把加密结果和 Frida 打印的返回值对一遍。对得上基本可以确定算法没理解错对不上优先怀疑 key 或初始向量问题再去 IDA 里核对常量。我翻车最多的一次是 Java 层 hook 返回 true 后界面弹了「正确」但 flag 是加密后的密文需要解密才能提交。后来养成的习惯是不管界面回显如何都要把真实计算结果单独跑出来校验。还有一个经验是遇到反调试和签名校验别一上来就 patch先跑一遍 Frida 的调用栈很多针对 ptrace 的检测对 Frida 并不生效如果必须要 patch记得把重打包造成的签名变化一起处理否则你会在第 5.2 的坑里重复跌倒好几次。希望帮到你。本文还有配套的精品资源点击获取