简介这份压缩包是华中科技大学网络空间安全学院逆向工程分析技术课程的实验存档面向网络安全专业学生、逆向入门开发者以及需要完成同类课程设计的读者能够作为课程实验与自主练习的完整参考。包内共57个文件、约6.11MB包含实验源码、说明书/README、IDA数据库i64、Python脚本、Windows可执行程序以及安卓样本APK对应的dex/arsc/so等文件覆盖Windows端静态分析与安卓端逆向破解两类常见场景。资料中包含两个实验模块分别针对可执行程序的IDA分析与安卓应用破解并配有过程截图、操作说明和结果验证记录读者可以一边对照文档复现实验一边修改源码做二次练习。资源目录保留了清晰的说明性结构与分层方便快速定位源码、文档、样本和输出结果。目前已有165人学习对于希望快速上手逆向分析、理解IDA工具链与APK逆向流程并在此基础上输出课程报告或准备答辩的人来说是一份实用的参考素材。1. 拆开一份高校逆向工程实验资源里面到底有什么如果你做过网络空间安全相关的课程设计一定遇到过这种情况老师丢一个 CrackMe、一个 APK说要逆向出 flag然后给一份写得极其简略的实验指导书。这份来自华中科技大学网络空间安全学院的逆向工程分析技术实验资源正是这类课程里最典型的存档——一个 PE 格式的 Windows 可执行程序 Experient-1.exe配好了一份已经分析完的 IDA 数据库 Experient-1.i64外加一个 1.py 脚本和一份答案文件 ans.txt另一边是一个 AliCrackme.apk 安卓样本连 APK 的解析产物 classes.dex、AndroidManifest.xml、resources.arsc、lib 目录都帮你拆好了。适合谁适合正在做课程实验、需要一份能跑通全流程且能自己修改的参考实现的同学。它不教你理论而是把「静态分析 → 动态调试 → 脚本化验证」这条完整链路直接摆在你面前。2. 从 .exe 到 flagIDA 静态分析与 Python 脚本验证2.1 先把资源清单读明白别上来就跑解压之后你会看到两个一级目录各带一份 README.md。第一次打开建议先别碰 exe把 README 通读一遍它会告诉你这个实验的预期输出是什么、ans.txt 里存的是什么格式的答案。这个习惯很重要——我见过太多同学把 flag 找出来了却因为格式不对被判定错。Experient-1 这个实验的输入是一张截图一份 IDA 数据库 .i64、一个可执行文件 .exe、一个 1.py 脚本。这里的关键不是 .exe 本身有多难而是 .i64 已经帮你完成了初步分析。用 IDA 打开 .i64你会发现函数名、字符串引用、交叉引用都已经标好了一部分这是老师或者前人留下的分析痕迹。正确做法是先看 .i64 里被命名过的函数再看 main 函数的调用关系最后用交叉引用去找关键比较指令。# 在 IDA 中打开 .i64 的快捷方式 # 命令行方式ida64 Experient-1.i64 # 但通常我们会通过 IDA GUI 直接 File - Open - 选择 .i64为什么 .i64 比 .idb 重要因为 .i64 是 IDA 7.0 之后默认的 64 位数据库格式如果你用的是老版本 IDA可能打不开这个在避坑章节会细说。打开后的第一件事不是看反汇编而是看 Functions 窗口里有没有名字包含check、verify、main的函数。用CtrlF搜索这些关键词十有八九能直接定位到核心校验函数。2.2 静态分析找到比较指令就找到了一半答案拿到 .i64 后我一般会先按ShiftF12打开 Strings 窗口。为什么先看字符串因为大多数课程实验的 CrackMe 会把提示信息硬编码在程序里比如Wrong!、Correct!这种。双击进入字符串所在的代码段往上看几条指令就能看到cmp、jnz、jz这类关键跳转。以这个实验常见的流程来说main 函数里会有一个输入读取操作然后调用一个校验函数校验函数里把用户的输入和一个硬编码在数据段的字节数组逐位比较。在 IDA 里你大概率会看到这样的伪代码// IDA F5 生成的伪代码注意这是常见形态 int __cdecl sub_401000(char *input) { char *v1; // esi int v2; // edi char v3; // al v1 byte_403000; // 硬编码的关键数据 v2 0; while ( *v1 ) { v3 *v1 ^ 0x2A; // 常见异或解密 if ( input[v2] ! v3 ) return 0; v1; v2; } return 1; }这段伪代码展示的是最常见的「异或加密字符串比对」模式。byte_403000是一段看起来像乱码的字节但如果它跟0x2A异或就会变成一串可读字符——那通常就是 flag。在做这类实验时不要急着上动态调试先把这种异或操作在纸上算一遍或者用脚本算往往答案就出来了。1.py脚本在这个实验里的作用大概率就是干这件事把 IDA 里提取出来的密文做异或解密或者把答案写入 ans.txt。打开脚本看一下它的输入参数和数据来源如果是把密文写死在了脚本里那直接运行就能得到结果如果是从 IDA 的某个导出文件读取那就要先保证导出格式正确。# 1.py 常见形态从 IDA 导出的字节数组解密 flag # 假设我们从 IDA 的 Export Data 功能导出了密文数组 cipher.bin with open(cipher.bin, rb) as f: cipher f.read() key 0x2A # 与 IDA 伪代码中的异或值一致 flag .join(chr(b ^ key) for b in cipher) print(flag) # 写入 ans.txt注意结尾不要有多余换行 with open(ans.txt, w) as f: f.write(flag.strip())参数说明cipher.bin是 IDA 中选中所要导出的字节数据后用File - Export Data导出的二进制文件key值必须和反汇编里的异或立即数一致如果实际是0x33那就改成0x33。这里最容易犯的错误是把 key 看成十进制 42实际上0x2A是十六进制。运行后如果输出乱码先怀疑 key 不对再怀疑字节序反了。2.3 动态调试兜底OD 或 x64dbg 验证静态结论静态分析偶尔会翻车尤其是遇到代码混淆或者反调试。这种情况就需要上动态调试工具常见选择是 OllyDbg 或者 x64dbg。这个实验的 exe 目前看不出加壳迹象如果有壳第一步应该是用 Exeinfo PE 查壳工具扫一下根据壳的类型用对应的脱壳工具或手动 ESP 定律脱壳。x64dbg 里有一个很实用的功能就是对GetWindowTextA、ReadFile这类 API 下断点。因为 CrackMe 无论如何都需要读取用户输入在输入 API 的返回处下断点然后单步跟就能看到用户输入的缓冲区地址进而看到后续在哪条指令对缓冲区做了比较。# x64dbg 下断点命令在命令行窗口执行 bp GetWindowTextA bp ReadFile bp scanf为什么推荐动态验证因为静态分析看到的伪代码有时候会误导特别是开启优化后的程序变量名和结构会被打乱F5 出来的代码和实际行为有出入。用 x64dbg 单步跟一遍看着寄存器里的值和内存窗口的变化能快速确认静态分析得出的 key 和 flag 是否正确。不过课程实验一般不会在这个层面卡人动态调试属于兜底手段不用一上来就开。3. 拆解 AliCrackme.apk从 DEX 到 so 层的逆向路径3.1 拆包搞清楚 APK 里每个文件的用途第二个实验是 Android 方向的 AliCrackme。资源里已经把 APK 拆好了一层classes.dex是 Java/Kotlin 层代码编译后的字节码AndroidManifest.xml是应用配置resources.arsc是资源索引表lib目录下是 native 层 so 文件。还有一份AliCrackme.zip这个名字值得注意——它可能就是原始 APK 改名压缩也可能是伪加密的陷阱这个我们放到避坑章节说。拿到一个 APK 逆向任务我的标准操作顺序是先用jadx打开 APK或者直接打开 classes.dex浏览包结构找到 MainActivity再看 AndroidManifest.xml 确认哪个 activity 是入口最后搜索字符串 flag、key、password 这类关键词。AliCrackme 是 Android 逆向圈子里的经典样本网上流传的解法有很多种但作为课程实验它考察的往往是最基础的一条路径Java 层校验。# 用 jadx 反编译 APK输出到 java_src 目录 jadx -d java_src AliCrackme.apk # 如果只想看某一个 dex可以直接拖进 jadx-gui jadx-gui classes.dex命令行参数说明-d指定输出目录--no-res可以跳过资源文件只反编译代码-j指定并发线程数。课程实验的 APK 一般不大直接全量反编译就行。反编译完成后在输出目录里搜check、verify、encrypt这些关键词十有八九能命中核心逻辑。3.2 Java 层与 so 层AliCrackme 的校验路径分析AliCrackme 这个样本的特点在于它往往在 Java 层做一层校验如果失败就直接返回但如果通过 Java 层还会进入 native 层做二次校验。课程实验的 README 里如果有说明那就按说明来如果没有就默认 Java 层 native 层都看。先在 jadx 里定位 MainActivity 的onClick或者onCreate找到输入框的内容获取方式。常见写法是把输入传给一个String类型的变量再交给一个checkFlag方法。这个方法可能在 Java 层也可能通过System.loadLibrary(crackme)加载 so 之后调用 native 方法。// jadx 反编译出的典型 Java 层校验代码 public class MainActivity extends Activity { static { System.loadLibrary(crackme); // 加载 libcrackme.so } private native String getFlag(String input); // native 方法声明 public void onClick(View view) { String input editText.getText().toString(); String result getFlag(input); // 进入 so 层校验 if (result.equals(success)) { textView.setText(Correct!); } else { textView.setText(Wrong!); } } }这段代码反映了一个非常典型的 native 层校验结构。如果 classes.dex 里搜不到checkFlag这类方法那就是 Java 层只是壳真正的逻辑在lib/armeabi-v7a或lib/arm64-v8a下的 so 文件里。对 so 文件用 IDA 打开选择 ARM 或 ARM64 架构搜索导出函数看有没有Java_com_example_..._getFlag这种命名——JNI 函数的命名规则是固定的Java_加包名加类名加方法名按这个规律能直接定位到 native 实现。3.3 修改与重打包smali 补丁的实操方法课程实验允许「自行修改」这意味着除了静态分析出 flag你还可以通过修改 smali 指令来让校验永远通过。这个思路在真实渗透里叫 patch 二进制在逆向实验里是一个非常加分的操作。先把 APK 里的 classes.dex 用baksmali反汇编成 smali 文件找到校验逻辑所在的方法把末尾的return v0改成固定返回成功值。以 AliCrackme 为例如果校验成功返回true失败返回false那找到判断分支后把if-nez改成if-eqz逻辑就反过来了。# baksmali 反汇编 dex baksmali d classes.dex -o smali_out # 修改完 smali 后重新打包成 dex smali a smali_out -o classes.dex修改时要注意指令语义。在 smali 里if-nez v0, :cond_0表示 v0 不为零就跳转到 cond_0如果你想让校验逻辑恒真把if-eqz改成if-nez是最快的办法。改完后把新的 classes.dex 放回 APK 原位置用apktool重打包再用jarsigner或apksigner重新签名。这里有个坑Android 7.0 以上默认启用 V2 签名jarsigner只签 V1 会导致安装失败要手动指定 V2 签名方案。# apktool 重打包 apktool b apk_dir -o patched.apk # 生成签名密钥仅第一次需要 keytool -genkey -alias cybersec -keyalg RSA -validity 3650 -keystore key.jks # V1 V2 双签名 apksigner sign --ks key.jks --v1-signing-enabled true --v2-signing-enabled true --out final.apk patched.apk参数说明--v1-signing-enabled true开启 V1 签名--v2-signing-enabled true开启 V2 签名。课程实验的 APK 一般都支持到 Android 8.0 以下V1 就够用但如果你的测试机是 Android 9 以上必须开 V2否则PackageManager会直接拒绝安装。签名完成后最好用apksigner verify --print-certs final.apk验证一下签名信息。重打包后的 APK 装到模拟器上随便输入什么都会提示 Correct这就完成了实验的「修改」环节。不过要注意这种做法只能证明你理解了执行流老师如果追问 flag 的值你还是得从 so 文件里把真正的字符串挖出来。4. 避坑指南逆向实验里最容易翻车的四个环节4.1 zip 伪加密AliCrackme.zip 解压报错不一定是文件坏了现象解压AliCrackme.zip时提示「文件损坏」或「密码错误」但文件明明是从网盘正常下载的。原因压缩包里可能设置了伪加密。伪加密的原理是 ZIP 文件格式中每个文件头有个general purpose bit flag字段把第 0 位加密标志位置 1 就会被识别为加密但实际上数据并没有被真正加密数据区完全是明文。解决用十六进制编辑器打开 zip定位到文件头50 4B 01 02中央目录文件头找到第 9 个字节即通用位标志的低字节把01 00改成00 00保存后重新打开文件就能正常解压了。也可以用 Linux 下的zipinfo -v查看加密标志来确认是否伪加密。# 查看 zip 文件里的加密标志如果显示 encryption: none 却是伪加密 zipinfo -v AliCrackme.zip | grep -i encryption这个坑在逆向资源里非常常见资源发布者故意设置伪加密来验证你是否了解 zip 文件格式。遇到解压失败先别删文件用上面这个方法检查一遍。4.2 IDA 版本不匹配.i64 打不开或显示损坏现象双击打开.i64文件IDA 提示 The file is not a valid IDA database 或者直接闪退。原因.i64是 IDA 7.0 之后引入的 64 位数据库格式而且不同大版本之间如 7.5 和 8.3数据库格式不兼容。如果是 IDA 6.x 或者早期的 7.0打不开新版创建的数据库。解决两个办法。一是安装与创建者版本一致的 IDAREADME 里如果写了 IDA 版本就按那个来没写就试 IDA 7.5 或 8.3二是放弃.i64直接用 IDA 打开Experient-1.exe重新做一次自动化分析。打开 exe 时记得选择正确的架构一般是 x86 或 x64 的 PE 格式如果提示 packer 检测到加壳先脱壳再分析。4.3 模拟器上安装重打包后的 APK 失败现象用adb install安装patched.apk时提示INSTALL_PARSE_FAILED_NO_CERTIFICATES或INSTALL_FAILED_UPDATE_INCOMPATIBLE。原因前者是签名没签好或者只签了 V1 但测试机要求 V2后者是原包已经装在设备上签名不一致导致覆盖安装失败需要先卸载原包。解决先adb uninstall 包名卸载干净再重新安装。签名方案上用apksigner同时开启 V1 和 V2不要用老旧的jarsigner——它对 V2 方案无能为力。确认签名apksigner verify --verbose final.apk看到Verified using v1 scheme: true和v2 scheme: true再安装。4.4 ans.txt 格式对不上flag 找对了却判定错误现象明明从程序里解出了正确的字符串写入 ans.txt 提交给实验系统却提示答案错误。原因大概率是格式问题。有些实验要求答案带特定前缀如flag{...}有些要求纯字符串不带换行有些要求小写。另外 Windows 下用记事本保存 txt 会带上\r\n而判定程序期望的是\n。解决查看 README 里的答案格式说明如果没有说明对比实验截图里的输出样式。写入时用 Python 脚本控制格式不要用记事本手敲——写完后用xxd ans.txt查看十六进制确认末尾没有多余的回车换行。5. 把实验做成生产线一键复现与改造自己的逆向目标5.1 一键复现让每次实验都在同一状态下启动做逆向实验最烦的就是环境不一致IDA 的数据库状态、输出文件的格式、依赖脚本的路径任何一个变动都可能导致结果不可复现。我的习惯是写一个 shell 脚本把整个流程串起来从解压、脱壳、导出数据到运行解密脚本全部自动化。#!/bin/bash # 一键逆向复现脚本Windows Git Bash 或 Linux 环境 set -e # 步骤 1清理旧产物 rm -rf workdir mkdir workdir cd workdir # 步骤 2解开 APK 并反编译 unzip ../AliCrackme.apk -d apk_extracted jadx -d jadx_out ../AliCrackme.apk # 步骤 3解出伪加密的 zip python3 ../fix_fake_zip.py ../AliCrackme.zip fixed.zip unzip fixed.zip -d fakezip_out # 步骤 4提取 dex 中的字符串并匹配 flag 模式 strings apk_extracted/classes.dex | grep -i flag\|key\|pass echo 完成检查 jadx_out 目录下的反编译结果这个脚本的意义不只是省事而是保证你在修改过资源之后随时能回到一个干净的基线状态。课程实验里老师可能会问「你改了哪些文件」有了这个脚本每一次改动都有日志可追溯。5.2 把实验目标换成你自己的程序「可自行修改」这四个字是这个资源价值最大的地方。Experient-1 的1.py脚本完全可以改造成一个通用工具输入是 IDA 导出的字节数组输出是解密后的字符串。你只需要替换密文数据和异或 key就能把它用在新的逆向挑战上。#!/usr/bin/env python3 # 通用异或解密脚本输入密文文件和 key输出解密结果 import sys def xor_decrypt(data: bytes, key: int) - bytes: return bytes(b ^ key for b in data) if __name__ __main__: if len(sys.argv) ! 4: print(用法: python3 xor_decrypt.py 密文文件 key: 十六进制 输出文件) sys.exit(1) with open(sys.argv[1], rb) as f: ciphertext f.read() key int(sys.argv[2], 16) plaintext xor_decrypt(ciphertext, key) with open(sys.argv[3], wb) as f: f.write(plaintext) print(f解密完成共 {len(plaintext)} 字节输出到 {sys.argv[3]})脚本里int(sys.argv[2], 16)把十六进制字符串转成整数这样在 IDA 里看到xor eax, 0x2A传参时写2A就行不用自己做进制换算。输出文件用wb二进制模式避免字符串里的特殊字符被转义。5.3 验证的最后一公里交叉检查答案拿到 flag 之后别急着提交用两个独立路径交叉验证一下静态分析一个结果动态调试一个结果两个对比一致再提交。如果只有静态分析的结果那就用 IDA 的脚本扩展IDAPython重新算一遍而不是靠肉眼比对十六进制。# IDAPython 脚本在 IDA 中直接提取并验证密码 import idautils import idc # 找到异或比较的地址按实验实际地址修改 cmp_address 0x40102A value idc.get_wide_byte(cmp_address) print(fkey {hex(value)}) # 从数据段读取密文字节 cipher_addr 0x403000 cipher [] for i in range(0x20): # 假设密文长度 0x20 cipher.append(idc.get_wide_byte(cipher_addr i)) flag .join(chr(b ^ value) for b in cipher) print(fflag {flag})这段 IDAPython 的好处是不需要手动从 IDA 复制数据直接在 IDA 里执行File - Script File就能拿到结果减少中间环节出错的可能。从那以后我每次做逆向实验都强制自己走一遍「静态定位 → 脚本解密 → 动态验证」三步流程哪怕目标再简单也不跳步。这个习惯帮我避免过太多次「自以为对了结果提交失败」的尴尬。希望这份资源的拆解能帮到你——按这套流程把两个实验各跑一遍再动手改一改脚本和样本你才算真正吃透了它。本文还有配套的精品资源点击获取 高校逆向实验资源全解析：从IDA静态分析到APK动态调试
简介这份压缩包是华中科技大学网络空间安全学院逆向工程分析技术课程的实验存档面向网络安全专业学生、逆向入门开发者以及需要完成同类课程设计的读者能够作为课程实验与自主练习的完整参考。包内共57个文件、约6.11MB包含实验源码、说明书/README、IDA数据库i64、Python脚本、Windows可执行程序以及安卓样本APK对应的dex/arsc/so等文件覆盖Windows端静态分析与安卓端逆向破解两类常见场景。资料中包含两个实验模块分别针对可执行程序的IDA分析与安卓应用破解并配有过程截图、操作说明和结果验证记录读者可以一边对照文档复现实验一边修改源码做二次练习。资源目录保留了清晰的说明性结构与分层方便快速定位源码、文档、样本和输出结果。目前已有165人学习对于希望快速上手逆向分析、理解IDA工具链与APK逆向流程并在此基础上输出课程报告或准备答辩的人来说是一份实用的参考素材。1. 拆开一份高校逆向工程实验资源里面到底有什么如果你做过网络空间安全相关的课程设计一定遇到过这种情况老师丢一个 CrackMe、一个 APK说要逆向出 flag然后给一份写得极其简略的实验指导书。这份来自华中科技大学网络空间安全学院的逆向工程分析技术实验资源正是这类课程里最典型的存档——一个 PE 格式的 Windows 可执行程序 Experient-1.exe配好了一份已经分析完的 IDA 数据库 Experient-1.i64外加一个 1.py 脚本和一份答案文件 ans.txt另一边是一个 AliCrackme.apk 安卓样本连 APK 的解析产物 classes.dex、AndroidManifest.xml、resources.arsc、lib 目录都帮你拆好了。适合谁适合正在做课程实验、需要一份能跑通全流程且能自己修改的参考实现的同学。它不教你理论而是把「静态分析 → 动态调试 → 脚本化验证」这条完整链路直接摆在你面前。2. 从 .exe 到 flagIDA 静态分析与 Python 脚本验证2.1 先把资源清单读明白别上来就跑解压之后你会看到两个一级目录各带一份 README.md。第一次打开建议先别碰 exe把 README 通读一遍它会告诉你这个实验的预期输出是什么、ans.txt 里存的是什么格式的答案。这个习惯很重要——我见过太多同学把 flag 找出来了却因为格式不对被判定错。Experient-1 这个实验的输入是一张截图一份 IDA 数据库 .i64、一个可执行文件 .exe、一个 1.py 脚本。这里的关键不是 .exe 本身有多难而是 .i64 已经帮你完成了初步分析。用 IDA 打开 .i64你会发现函数名、字符串引用、交叉引用都已经标好了一部分这是老师或者前人留下的分析痕迹。正确做法是先看 .i64 里被命名过的函数再看 main 函数的调用关系最后用交叉引用去找关键比较指令。# 在 IDA 中打开 .i64 的快捷方式 # 命令行方式ida64 Experient-1.i64 # 但通常我们会通过 IDA GUI 直接 File - Open - 选择 .i64为什么 .i64 比 .idb 重要因为 .i64 是 IDA 7.0 之后默认的 64 位数据库格式如果你用的是老版本 IDA可能打不开这个在避坑章节会细说。打开后的第一件事不是看反汇编而是看 Functions 窗口里有没有名字包含check、verify、main的函数。用CtrlF搜索这些关键词十有八九能直接定位到核心校验函数。2.2 静态分析找到比较指令就找到了一半答案拿到 .i64 后我一般会先按ShiftF12打开 Strings 窗口。为什么先看字符串因为大多数课程实验的 CrackMe 会把提示信息硬编码在程序里比如Wrong!、Correct!这种。双击进入字符串所在的代码段往上看几条指令就能看到cmp、jnz、jz这类关键跳转。以这个实验常见的流程来说main 函数里会有一个输入读取操作然后调用一个校验函数校验函数里把用户的输入和一个硬编码在数据段的字节数组逐位比较。在 IDA 里你大概率会看到这样的伪代码// IDA F5 生成的伪代码注意这是常见形态 int __cdecl sub_401000(char *input) { char *v1; // esi int v2; // edi char v3; // al v1 byte_403000; // 硬编码的关键数据 v2 0; while ( *v1 ) { v3 *v1 ^ 0x2A; // 常见异或解密 if ( input[v2] ! v3 ) return 0; v1; v2; } return 1; }这段伪代码展示的是最常见的「异或加密字符串比对」模式。byte_403000是一段看起来像乱码的字节但如果它跟0x2A异或就会变成一串可读字符——那通常就是 flag。在做这类实验时不要急着上动态调试先把这种异或操作在纸上算一遍或者用脚本算往往答案就出来了。1.py脚本在这个实验里的作用大概率就是干这件事把 IDA 里提取出来的密文做异或解密或者把答案写入 ans.txt。打开脚本看一下它的输入参数和数据来源如果是把密文写死在了脚本里那直接运行就能得到结果如果是从 IDA 的某个导出文件读取那就要先保证导出格式正确。# 1.py 常见形态从 IDA 导出的字节数组解密 flag # 假设我们从 IDA 的 Export Data 功能导出了密文数组 cipher.bin with open(cipher.bin, rb) as f: cipher f.read() key 0x2A # 与 IDA 伪代码中的异或值一致 flag .join(chr(b ^ key) for b in cipher) print(flag) # 写入 ans.txt注意结尾不要有多余换行 with open(ans.txt, w) as f: f.write(flag.strip())参数说明cipher.bin是 IDA 中选中所要导出的字节数据后用File - Export Data导出的二进制文件key值必须和反汇编里的异或立即数一致如果实际是0x33那就改成0x33。这里最容易犯的错误是把 key 看成十进制 42实际上0x2A是十六进制。运行后如果输出乱码先怀疑 key 不对再怀疑字节序反了。2.3 动态调试兜底OD 或 x64dbg 验证静态结论静态分析偶尔会翻车尤其是遇到代码混淆或者反调试。这种情况就需要上动态调试工具常见选择是 OllyDbg 或者 x64dbg。这个实验的 exe 目前看不出加壳迹象如果有壳第一步应该是用 Exeinfo PE 查壳工具扫一下根据壳的类型用对应的脱壳工具或手动 ESP 定律脱壳。x64dbg 里有一个很实用的功能就是对GetWindowTextA、ReadFile这类 API 下断点。因为 CrackMe 无论如何都需要读取用户输入在输入 API 的返回处下断点然后单步跟就能看到用户输入的缓冲区地址进而看到后续在哪条指令对缓冲区做了比较。# x64dbg 下断点命令在命令行窗口执行 bp GetWindowTextA bp ReadFile bp scanf为什么推荐动态验证因为静态分析看到的伪代码有时候会误导特别是开启优化后的程序变量名和结构会被打乱F5 出来的代码和实际行为有出入。用 x64dbg 单步跟一遍看着寄存器里的值和内存窗口的变化能快速确认静态分析得出的 key 和 flag 是否正确。不过课程实验一般不会在这个层面卡人动态调试属于兜底手段不用一上来就开。3. 拆解 AliCrackme.apk从 DEX 到 so 层的逆向路径3.1 拆包搞清楚 APK 里每个文件的用途第二个实验是 Android 方向的 AliCrackme。资源里已经把 APK 拆好了一层classes.dex是 Java/Kotlin 层代码编译后的字节码AndroidManifest.xml是应用配置resources.arsc是资源索引表lib目录下是 native 层 so 文件。还有一份AliCrackme.zip这个名字值得注意——它可能就是原始 APK 改名压缩也可能是伪加密的陷阱这个我们放到避坑章节说。拿到一个 APK 逆向任务我的标准操作顺序是先用jadx打开 APK或者直接打开 classes.dex浏览包结构找到 MainActivity再看 AndroidManifest.xml 确认哪个 activity 是入口最后搜索字符串 flag、key、password 这类关键词。AliCrackme 是 Android 逆向圈子里的经典样本网上流传的解法有很多种但作为课程实验它考察的往往是最基础的一条路径Java 层校验。# 用 jadx 反编译 APK输出到 java_src 目录 jadx -d java_src AliCrackme.apk # 如果只想看某一个 dex可以直接拖进 jadx-gui jadx-gui classes.dex命令行参数说明-d指定输出目录--no-res可以跳过资源文件只反编译代码-j指定并发线程数。课程实验的 APK 一般不大直接全量反编译就行。反编译完成后在输出目录里搜check、verify、encrypt这些关键词十有八九能命中核心逻辑。3.2 Java 层与 so 层AliCrackme 的校验路径分析AliCrackme 这个样本的特点在于它往往在 Java 层做一层校验如果失败就直接返回但如果通过 Java 层还会进入 native 层做二次校验。课程实验的 README 里如果有说明那就按说明来如果没有就默认 Java 层 native 层都看。先在 jadx 里定位 MainActivity 的onClick或者onCreate找到输入框的内容获取方式。常见写法是把输入传给一个String类型的变量再交给一个checkFlag方法。这个方法可能在 Java 层也可能通过System.loadLibrary(crackme)加载 so 之后调用 native 方法。// jadx 反编译出的典型 Java 层校验代码 public class MainActivity extends Activity { static { System.loadLibrary(crackme); // 加载 libcrackme.so } private native String getFlag(String input); // native 方法声明 public void onClick(View view) { String input editText.getText().toString(); String result getFlag(input); // 进入 so 层校验 if (result.equals(success)) { textView.setText(Correct!); } else { textView.setText(Wrong!); } } }这段代码反映了一个非常典型的 native 层校验结构。如果 classes.dex 里搜不到checkFlag这类方法那就是 Java 层只是壳真正的逻辑在lib/armeabi-v7a或lib/arm64-v8a下的 so 文件里。对 so 文件用 IDA 打开选择 ARM 或 ARM64 架构搜索导出函数看有没有Java_com_example_..._getFlag这种命名——JNI 函数的命名规则是固定的Java_加包名加类名加方法名按这个规律能直接定位到 native 实现。3.3 修改与重打包smali 补丁的实操方法课程实验允许「自行修改」这意味着除了静态分析出 flag你还可以通过修改 smali 指令来让校验永远通过。这个思路在真实渗透里叫 patch 二进制在逆向实验里是一个非常加分的操作。先把 APK 里的 classes.dex 用baksmali反汇编成 smali 文件找到校验逻辑所在的方法把末尾的return v0改成固定返回成功值。以 AliCrackme 为例如果校验成功返回true失败返回false那找到判断分支后把if-nez改成if-eqz逻辑就反过来了。# baksmali 反汇编 dex baksmali d classes.dex -o smali_out # 修改完 smali 后重新打包成 dex smali a smali_out -o classes.dex修改时要注意指令语义。在 smali 里if-nez v0, :cond_0表示 v0 不为零就跳转到 cond_0如果你想让校验逻辑恒真把if-eqz改成if-nez是最快的办法。改完后把新的 classes.dex 放回 APK 原位置用apktool重打包再用jarsigner或apksigner重新签名。这里有个坑Android 7.0 以上默认启用 V2 签名jarsigner只签 V1 会导致安装失败要手动指定 V2 签名方案。# apktool 重打包 apktool b apk_dir -o patched.apk # 生成签名密钥仅第一次需要 keytool -genkey -alias cybersec -keyalg RSA -validity 3650 -keystore key.jks # V1 V2 双签名 apksigner sign --ks key.jks --v1-signing-enabled true --v2-signing-enabled true --out final.apk patched.apk参数说明--v1-signing-enabled true开启 V1 签名--v2-signing-enabled true开启 V2 签名。课程实验的 APK 一般都支持到 Android 8.0 以下V1 就够用但如果你的测试机是 Android 9 以上必须开 V2否则PackageManager会直接拒绝安装。签名完成后最好用apksigner verify --print-certs final.apk验证一下签名信息。重打包后的 APK 装到模拟器上随便输入什么都会提示 Correct这就完成了实验的「修改」环节。不过要注意这种做法只能证明你理解了执行流老师如果追问 flag 的值你还是得从 so 文件里把真正的字符串挖出来。4. 避坑指南逆向实验里最容易翻车的四个环节4.1 zip 伪加密AliCrackme.zip 解压报错不一定是文件坏了现象解压AliCrackme.zip时提示「文件损坏」或「密码错误」但文件明明是从网盘正常下载的。原因压缩包里可能设置了伪加密。伪加密的原理是 ZIP 文件格式中每个文件头有个general purpose bit flag字段把第 0 位加密标志位置 1 就会被识别为加密但实际上数据并没有被真正加密数据区完全是明文。解决用十六进制编辑器打开 zip定位到文件头50 4B 01 02中央目录文件头找到第 9 个字节即通用位标志的低字节把01 00改成00 00保存后重新打开文件就能正常解压了。也可以用 Linux 下的zipinfo -v查看加密标志来确认是否伪加密。# 查看 zip 文件里的加密标志如果显示 encryption: none 却是伪加密 zipinfo -v AliCrackme.zip | grep -i encryption这个坑在逆向资源里非常常见资源发布者故意设置伪加密来验证你是否了解 zip 文件格式。遇到解压失败先别删文件用上面这个方法检查一遍。4.2 IDA 版本不匹配.i64 打不开或显示损坏现象双击打开.i64文件IDA 提示 The file is not a valid IDA database 或者直接闪退。原因.i64是 IDA 7.0 之后引入的 64 位数据库格式而且不同大版本之间如 7.5 和 8.3数据库格式不兼容。如果是 IDA 6.x 或者早期的 7.0打不开新版创建的数据库。解决两个办法。一是安装与创建者版本一致的 IDAREADME 里如果写了 IDA 版本就按那个来没写就试 IDA 7.5 或 8.3二是放弃.i64直接用 IDA 打开Experient-1.exe重新做一次自动化分析。打开 exe 时记得选择正确的架构一般是 x86 或 x64 的 PE 格式如果提示 packer 检测到加壳先脱壳再分析。4.3 模拟器上安装重打包后的 APK 失败现象用adb install安装patched.apk时提示INSTALL_PARSE_FAILED_NO_CERTIFICATES或INSTALL_FAILED_UPDATE_INCOMPATIBLE。原因前者是签名没签好或者只签了 V1 但测试机要求 V2后者是原包已经装在设备上签名不一致导致覆盖安装失败需要先卸载原包。解决先adb uninstall 包名卸载干净再重新安装。签名方案上用apksigner同时开启 V1 和 V2不要用老旧的jarsigner——它对 V2 方案无能为力。确认签名apksigner verify --verbose final.apk看到Verified using v1 scheme: true和v2 scheme: true再安装。4.4 ans.txt 格式对不上flag 找对了却判定错误现象明明从程序里解出了正确的字符串写入 ans.txt 提交给实验系统却提示答案错误。原因大概率是格式问题。有些实验要求答案带特定前缀如flag{...}有些要求纯字符串不带换行有些要求小写。另外 Windows 下用记事本保存 txt 会带上\r\n而判定程序期望的是\n。解决查看 README 里的答案格式说明如果没有说明对比实验截图里的输出样式。写入时用 Python 脚本控制格式不要用记事本手敲——写完后用xxd ans.txt查看十六进制确认末尾没有多余的回车换行。5. 把实验做成生产线一键复现与改造自己的逆向目标5.1 一键复现让每次实验都在同一状态下启动做逆向实验最烦的就是环境不一致IDA 的数据库状态、输出文件的格式、依赖脚本的路径任何一个变动都可能导致结果不可复现。我的习惯是写一个 shell 脚本把整个流程串起来从解压、脱壳、导出数据到运行解密脚本全部自动化。#!/bin/bash # 一键逆向复现脚本Windows Git Bash 或 Linux 环境 set -e # 步骤 1清理旧产物 rm -rf workdir mkdir workdir cd workdir # 步骤 2解开 APK 并反编译 unzip ../AliCrackme.apk -d apk_extracted jadx -d jadx_out ../AliCrackme.apk # 步骤 3解出伪加密的 zip python3 ../fix_fake_zip.py ../AliCrackme.zip fixed.zip unzip fixed.zip -d fakezip_out # 步骤 4提取 dex 中的字符串并匹配 flag 模式 strings apk_extracted/classes.dex | grep -i flag\|key\|pass echo 完成检查 jadx_out 目录下的反编译结果这个脚本的意义不只是省事而是保证你在修改过资源之后随时能回到一个干净的基线状态。课程实验里老师可能会问「你改了哪些文件」有了这个脚本每一次改动都有日志可追溯。5.2 把实验目标换成你自己的程序「可自行修改」这四个字是这个资源价值最大的地方。Experient-1 的1.py脚本完全可以改造成一个通用工具输入是 IDA 导出的字节数组输出是解密后的字符串。你只需要替换密文数据和异或 key就能把它用在新的逆向挑战上。#!/usr/bin/env python3 # 通用异或解密脚本输入密文文件和 key输出解密结果 import sys def xor_decrypt(data: bytes, key: int) - bytes: return bytes(b ^ key for b in data) if __name__ __main__: if len(sys.argv) ! 4: print(用法: python3 xor_decrypt.py 密文文件 key: 十六进制 输出文件) sys.exit(1) with open(sys.argv[1], rb) as f: ciphertext f.read() key int(sys.argv[2], 16) plaintext xor_decrypt(ciphertext, key) with open(sys.argv[3], wb) as f: f.write(plaintext) print(f解密完成共 {len(plaintext)} 字节输出到 {sys.argv[3]})脚本里int(sys.argv[2], 16)把十六进制字符串转成整数这样在 IDA 里看到xor eax, 0x2A传参时写2A就行不用自己做进制换算。输出文件用wb二进制模式避免字符串里的特殊字符被转义。5.3 验证的最后一公里交叉检查答案拿到 flag 之后别急着提交用两个独立路径交叉验证一下静态分析一个结果动态调试一个结果两个对比一致再提交。如果只有静态分析的结果那就用 IDA 的脚本扩展IDAPython重新算一遍而不是靠肉眼比对十六进制。# IDAPython 脚本在 IDA 中直接提取并验证密码 import idautils import idc # 找到异或比较的地址按实验实际地址修改 cmp_address 0x40102A value idc.get_wide_byte(cmp_address) print(fkey {hex(value)}) # 从数据段读取密文字节 cipher_addr 0x403000 cipher [] for i in range(0x20): # 假设密文长度 0x20 cipher.append(idc.get_wide_byte(cipher_addr i)) flag .join(chr(b ^ value) for b in cipher) print(fflag {flag})这段 IDAPython 的好处是不需要手动从 IDA 复制数据直接在 IDA 里执行File - Script File就能拿到结果减少中间环节出错的可能。从那以后我每次做逆向实验都强制自己走一遍「静态定位 → 脚本解密 → 动态验证」三步流程哪怕目标再简单也不跳步。这个习惯帮我避免过太多次「自以为对了结果提交失败」的尴尬。希望这份资源的拆解能帮到你——按这套流程把两个实验各跑一遍再动手改一改脚本和样本你才算真正吃透了它。本文还有配套的精品资源点击获取