简介本资源为CTF逆向工程专项练习包面向信息安全竞赛选手及逆向初学者聚焦第24至31关的实战题目覆盖静态分析、动态调试、汇编阅读、字符串混淆、栈帧分析、隐写术与内存取证等核心考点帮助读者在真实赛题环境中打磨程序分析与解密能力。压缩包共352个文件约8.8MB以txt题解与说明、dll动态库、udd调试数据、exe可执行程序、ini配置及少量c源码、idb数据库、pcap抓包文件为主另含chm手册与工具文档便于对照调试与复现。目前已有2490人学习下载适合需要系统刷题、查漏补缺的中级逆向爱好者。读者可借助其中的调试器数据、反汇编数据库与抓包记录完整还原每道题的解题链路理解加密算法识别、字符串还原与隐写数据提取的具体思路并积累IDA Pro、GDB、Stegsolve等工具在真实题目中的使用经验。1. 从几个 CTF 逆向题说起抓包、反编译与 flag 定位的实战路径很多人第一次接触 CTF 逆向都是从一道「看起来很简单」的题目开始的给一个二进制文件或者一段抓包流量让你找出藏在里面的 flag。但真正上手之后才发现静态分析工具打开一片汇编动态调试跑起来又不知道断点往哪下抓包数据翻来覆去看不出规律。这几个 CTF 逆向题覆盖了从静态反编译、动态调试到网络抓包分析的完整链路适合刚入门 CTF 逆向方向、想通过真实题目练手的同学。它不教你从零写逆向工具而是让你在具体题目里理解逆向的基本套路先看什么、再跟什么、最后怎么把 flag 抠出来。如果你已经会一点 Python、能看懂简单的汇编指令、知道 Wireshark 的基本用法这套题就能直接拿来练。下面按「拿到题先干什么 → 静态和动态怎么配合 → 抓包题怎么切 → 坑在哪」的顺序拆开讲。2. 逆向题的起手式文件识别、反编译与关键函数定位2.1 拿到文件先别急着扔 IDACTF 逆向题常见的文件类型就那么几种Linux ELF、Windows PE、Android APK、Python 打包的 pyc、还有各种固件和流量包。不同格式对应不同的分析工具链选错了工具就是白费功夫。我一般拿到文件先跑一遍基础识别确认架构、位数、是否加壳、有没有符号信息。# 基础文件识别三连 file ./challenge # 看文件类型和架构 checksec --file./challenge # 看保护机制PIE/NX/Canary strings -n 8 ./challenge | head -50 # 快速扫可读字符串file命令告诉你这是 64 位 ELF 还是 32 位 PE决定了你后面用 IDA 的哪个版本、调试器怎么配。checksec看的是二进制保护如果 PIE 开着说明基址随机化静态地址不能直接用来下断点如果 NX 开着栈上不能执行 shellcode。strings是最快的情报收集手段很多入门题的 flag 格式串、提示信息、甚至假 flag 都会直接暴露在字符串里。注意-n 8是过滤掉长度小于 8 的字符串避免输出被短字符串淹没。常见做法是先用strings搜flag{、ctf{、key这类关键词如果直接命中题目基本就结束了。但大多数题不会这么直白字符串里可能只有提示真正的逻辑藏在函数里。2.2 用 IDA/Ghidra 定位校验逻辑静态反编译的核心目标是找到「输入经过什么变换后和什么比较」。在 IDA 里我习惯先看main函数的伪代码然后顺着输入函数scanf、fgets、read、std::cin往下追。Ghidra 的反编译质量在近几年提升明显对于没有 IDA 授权的同学完全够用。# 以一道典型异或校验题为例还原后的校验逻辑 def check(input_str): target [0x12, 0x34, 0x56, 0x78] # 从反编译里抄出来的比较数组 if len(input_str) ! len(target): return False for i, ch in enumerate(input_str): # 反编译里看到的是 (ch ^ 0x2a) target[i] if (ord(ch) ^ 0x2a) ! target[i]: return False return True # 逆向求解把异或反过来算 flag .join(chr(t ^ 0x2a) for t in [0x12, 0x34, 0x56, 0x78]) print(flag)这段代码展示的是逆向题里最常见的模式正着算校验反着算求 flag。关键参数是异或密钥0x2a和比较数组target这两个值必须从反编译结果里准确抄出来抄错一个字节结果就全错。实际题目里可能是加减、移位、查表、Base64 混合变换但思路一样——把校验函数翻译成 Python然后写逆函数。注意从 IDA 伪代码抄数组时注意数据类型。int和char的宽度不同大端小端也会影响字节顺序抄完最好用hex打印一遍核对。2.3 动态调试配合静态分析静态分析卡住的时候动态调试就是后悔药。在 Linux 下用gdb配合pwndbg插件在 Windows 下用x64dbgAndroid 上则常用frida做 hook。动态调试的核心操作就三个下断点、看内存、改寄存器。# gdb 动态调试基本流程 gdb ./challenge # 在关键比较指令处下断点 b *0x401234 # 运行并传入测试输入 r test_input # 断下后查看寄存器和栈 info registers x/20x $rsp # 查看某个地址的字符串 x/s 0x402000b *0x401234是在指定地址下断点地址来自 IDA 里看到的比较指令位置。r test_input是把测试输入通过 here-string 传进去。断下来之后info registers看寄存器状态x/20x $rsp看栈内存x/s按字符串格式看内存。动态调试最大的价值是能让你看到运行时才生成的字符串——比如有些题会先解密一段数据再比较静态看不到明文但断在比较指令处就能直接读到解密后的内容。常见坑是断点地址在 PIE 开启时是偏移量而不是绝对地址需要先start让程序加载再用b *$base0x1234的方式下断。另一个坑是输入被scanf截断导致你传的测试数据根本没进到校验函数这时候要在输入函数处也下个断点确认数据流。3. 抓包逆向题从流量里还原协议和 flag3.1 流量包的第一遍筛协议分层与可疑流CTF 里的抓包题通常给一个.pcap或.pcapng文件flag 藏在某个协议的通信内容里。Wireshark 是标准工具但打开之后不要从头到尾翻包先做协议分层统计。# 用 tshark 快速统计协议分布 tshark -r capture.pcap -q -z io,phs # 过滤出所有含 flag 关键词的流 tshark -r capture.pcap -Y frame contains flag -T fields -e frame.number -e _ws.col.Info # 导出特定 TCP 流的原始数据 tshark -r capture.pcap -q -z follow,tcp,raw,0-z io,phs输出协议分层统计让你一眼看出这个包里有 HTTP、DNS、TCP 还是 USB 流量。-Y frame contains flag是显示过滤器直接搜包含 flag 字样的帧。-z follow,tcp,raw,0是跟踪第 0 号 TCP 流并以原始十六进制输出。这三条命令基本能覆盖 80% 的抓包题起手需求。常见做法是先用协议分层确定主协议再用contains搜关键词最后用follow跟踪具体流。如果 flag 被分片传输或者编码过就需要导出原始数据再做进一步处理。3.2 USB 流量与键盘击键还原USB 流量分析是 CTF 抓包题里的一个经典子类尤其是键盘和鼠标流量。键盘流量的原理是USB 协议里键盘发送的 HID 报告包含按键码把按键码按 HID 映射表翻译成字符就能还原输入内容。# USB 键盘流量还原脚本 # HID 键码到字符的映射表部分 hid_map { 0x04: a, 0x05: b, 0x06: c, 0x07: d, 0x08: e, 0x09: f, 0x0a: g, 0x0b: h, 0x0c: i, 0x0d: j, 0x0e: k, 0x0f: l, 0x10: m, 0x11: n, 0x12: o, 0x13: p, 0x14: q, 0x15: r, 0x16: s, 0x17: t, 0x18: u, 0x19: v, 0x1a: w, 0x1b: x, 0x1c: y, 0x1d: z, 0x1e: 1, 0x1f: 2, 0x20: 3, 0x21: 4, 0x22: 5, 0x23: 6, 0x24: 7, 0x25: 8, 0x26: 9, 0x27: 0, 0x2d: -, 0x2e: , 0x2f: [, 0x30: ], } # 从 tshark 导出的 USB 中断数据中提取按键码 # 命令tshark -r usb.pcap -T fields -e usb.capdata keystrokes.txt with open(keystrokes.txt) as f: for line in f: data line.strip().split(:) if len(data) 3: key_code int(data[2], 16) # 第三个字节是按键码 if key_code in hid_map: print(hid_map[key_code], end)这段脚本的关键参数是usb.capdata字段它包含 USB 中断传输的原始数据。键盘 HID 报告通常是 8 字节第三个字节索引 2是按键码。tshark -T fields -e usb.capdata把每个 USB 包的 capdata 导出成一行再用 Python 解析。注意有些包的 capdata 为空或者全零表示没有按键动作需要跳过。提示如果导出的 capdata 是00:00:00:00:00:00:00:00这种全零说明那一帧没有按键直接忽略。另外注意大小写和 Shift 键的处理HID 报告的第一个字节是修饰键表示 Shift/Ctrl/Alt 是否按下。3.3 自定义 TCP 协议逆向有些抓包题不走标准协议而是自定义的 TCP 通信。这时候需要先跟踪一条完整的 TCP 流看客户端和服务端之间的数据格式找出包头、长度字段、命令字和 payload 的边界。# 解析自定义 TCP 协议假设包头 4 字节前 2 字节是 magic后 2 字节是长度 import struct def parse_custom_protocol(raw_data): offset 0 messages [] while offset len(raw_data): if offset 4 len(raw_data): break magic, length struct.unpack(HH, raw_data[offset:offset4]) if magic ! 0xdead: # 假设 magic 是 0xdead offset 1 continue payload raw_data[offset4:offset4length] messages.append(payload) offset 4 length return messages # 从 tshark 导出的原始流数据读取 with open(stream_raw.bin, rb) as f: data f.read() for msg in parse_custom_protocol(data): print(msg)struct.unpack(HH, ...)里的表示大端序H表示无符号短整型2 字节。如果实际协议是小端改成。magic是协议识别码用来在字节流里定位消息起始位置。length字段告诉你 payload 有多长据此切分消息。这段代码的通用套路是先猜包头结构再用实际数据验证如果解析出来的 payload 看起来有规律比如都是可打印字符或者都是递增序列说明包头猜对了。常见坑是 TCP 流里混有重传和乱序包直接用follow,tcp,raw导出的数据可能包含重复内容。这时候要么在 Wireshark 里先过滤tcp.analysis.retransmission要么在脚本里做去重。另一个坑是长度字段包含包头本身导致偏移量算错需要根据实际数据调整offset的增量。4. 避坑与排查逆向抓包题里最容易翻车的五个点4.1 反编译结果和实际运行不一致现象IDA 伪代码里看到的逻辑用 Python 还原后算出的 flag 提交上去是错的。原因反编译器对某些指令的翻译有偏差尤其是涉及浮点运算、位域操作和编译器优化后的代码。解决不要完全信任伪代码关键逻辑要对照汇编指令逐条确认。用动态调试在关键点下断直接读内存里的实际值以运行时数据为准。4.2 抓包文件里有多条流选错了分析对象现象跟踪了一条 TCP 流翻来覆去看不出 flag以为题目有问题。原因pcap 里可能同时存在 HTTP、DNS、TCP 多条流flag 藏在另一条流里。解决先用tshark -q -z io,phs看协议分布再用-Y tcp.stream N逐条流排查。不要一上来就盯第一条流。4.3 USB 键盘流量里 Shift 键没处理现象还原出来的字符串全是小写但 flag 里明明有大写字母。原因HID 报告的第一个字节是修饰键Shift 按下时同一个按键码对应的是大写字符或符号。解决解析时先检查修饰键字节如果data[0] 0x02非零表示 Shift 按下此时按键码要映射到大写或符号表。这个细节在入门资料里经常被略过但实际题目里很常见。4.4 动态调试时断点没生效现象gdb里下了断点程序直接跑完退出断点根本没触发。原因PIE 开启时地址是随机化的静态地址下断无效或者断点下在了没被执行的分支上。解决先start让程序加载用info proc mappings看基址再b *$base偏移下断。或者用b *main0x10这种符号加偏移的方式让 gdb 自己算地址。4.5 字符串编码问题导致 flag 显示乱码现象从内存或流量里读出的数据打印出来是乱码但长度和预期一致。原因数据可能是 UTF-16、GBK 或者经过简单编码如 Base64、ROT13。解决先看字节的十六进制分布如果高位字节有规律比如都是0x00或0x04可能是宽字符。用iconv或 Python 的decode尝试不同编码。如果是 Base64直接丢给base64 -d试一下。5. 进阶技巧用 Python 脚本批量处理逆向题中的重复模式5.1 把常见变换写成可复用的工具函数做多了逆向题会发现很多变换是重复出现的异或、加减、移位、查表、Base64、RC4。与其每次重新写不如攒一个自己的工具库。我一般会把这些函数放在一个ctf_utils.py里遇到新题直接 import。# ctf_utils.py - 逆向题常用变换工具集 import base64 def xor_bytes(data, key): 单字节或多字节循环异或 if isinstance(key, int): key [key] return bytes(b ^ key[i % len(key)] for i, b in enumerate(data)) def caesar_shift(data, shift): 凯撒移位只处理字母 result [] for ch in data: if a ch z: result.append(chr((ord(ch) - ord(a) shift) % 26 ord(a))) elif A ch Z: result.append(chr((ord(ch) - ord(A) shift) % 26 ord(A))) else: result.append(ch) return .join(result) def brute_xor_single(data, prefixbflag{): 爆破单字节异或密钥用已知前缀验证 for key in range(256): decoded xor_bytes(data, key) if decoded.startswith(prefix): return key, decoded return None, None # 使用示例 encrypted bytes([0x1a, 0x0e, 0x1d, 0x1c, 0x7b]) # 假设的密文 key, flag brute_xor_single(encrypted) if key is not None: print(f密钥: {key:#x}, flag: {flag})xor_bytes支持单字节和多字节密钥多字节时循环使用密钥。caesar_shift只对字母做移位保留数字和符号不变这是凯撒密码的标准行为。brute_xor_single是最实用的函数——当你怀疑是单字节异或但不知道密钥时用已知的 flag 前缀通常是flag{或ctf{去爆破256 种可能一秒跑完。参数prefix可以根据题目提示调整比如有些比赛用DASCTF{或NSSCTF{。5.2 用 angr 做符号执行自动求解当逆向题的分支逻辑特别复杂手动分析成本太高时符号执行是值得尝试的方案。angr 是 Python 的二进制符号执行框架能自动探索路径并求解满足条件的输入。import angr import claripy # 加载二进制auto_load_libsFalse 加速加载 proj angr.Project(./challenge, auto_load_libsFalse) # 设置目标地址找到打印 Correct 或 flag 的分支 # 先用 strings 或 IDA 确认成功分支的地址 find_addr 0x401234 # 成功分支地址 avoid_addr 0x401456 # 失败分支地址 # 创建初始状态输入从标准输入读取 state proj.factory.entry_state() simgr proj.factory.simulation_manager(state) # 探索路径找到 find_addr避开 avoid_addr simgr.explore(findfind_addr, avoidavoid_addr) if simgr.found: found simgr.found[0] # 求解标准输入的内容 solution found.posix.dumps(0) print(f求解结果: {solution}) else: print(未找到可行路径检查地址或增加探索深度)proj.factory.entry_state()创建程序入口点的初始状态。simgr.explore(find..., avoid...)让 angr 自动探索所有路径直到找到满足find地址的状态。found.posix.dumps(0)把标准输入的文件描述符内容 dump 出来就是满足条件的输入。关键参数是find_addr和avoid_addr这两个地址必须从静态分析里准确获取——通常find是打印成功信息的分支avoid是打印失败信息的分支。angr 的局限也很明显对复杂加密算法和大量循环的代码状态爆炸会让求解时间不可接受。我一般只在分支多但每个分支逻辑简单的题目上用 angr遇到加密算法还是老老实实手动还原。另外 angr 对 Windows PE 的支持不如 ELF 好PE 题建议用 x64dbg 动态调试。注意angr 安装用pip install angr但依赖较多建议在虚拟环境里装。跑 angr 时如果卡住不动先检查find_addr是否可达可以用simgr.run()先跑一遍看探索了多少状态。从那以后我每次拿到新题都强制先跑一遍filechecksecstrings三连再决定是静态分析还是动态调试是手动还原还是上 angr。这个习惯帮我省下了大量在错误方向上浪费的时间。希望帮到你。本文还有配套的精品资源点击获取
简介本资源为CTF逆向工程专项练习包面向信息安全竞赛选手及逆向初学者聚焦第24至31关的实战题目覆盖静态分析、动态调试、汇编阅读、字符串混淆、栈帧分析、隐写术与内存取证等核心考点帮助读者在真实赛题环境中打磨程序分析与解密能力。压缩包共352个文件约8.8MB以txt题解与说明、dll动态库、udd调试数据、exe可执行程序、ini配置及少量c源码、idb数据库、pcap抓包文件为主另含chm手册与工具文档便于对照调试与复现。目前已有2490人学习下载适合需要系统刷题、查漏补缺的中级逆向爱好者。读者可借助其中的调试器数据、反汇编数据库与抓包记录完整还原每道题的解题链路理解加密算法识别、字符串还原与隐写数据提取的具体思路并积累IDA Pro、GDB、Stegsolve等工具在真实题目中的使用经验。1. 从几个 CTF 逆向题说起抓包、反编译与 flag 定位的实战路径很多人第一次接触 CTF 逆向都是从一道「看起来很简单」的题目开始的给一个二进制文件或者一段抓包流量让你找出藏在里面的 flag。但真正上手之后才发现静态分析工具打开一片汇编动态调试跑起来又不知道断点往哪下抓包数据翻来覆去看不出规律。这几个 CTF 逆向题覆盖了从静态反编译、动态调试到网络抓包分析的完整链路适合刚入门 CTF 逆向方向、想通过真实题目练手的同学。它不教你从零写逆向工具而是让你在具体题目里理解逆向的基本套路先看什么、再跟什么、最后怎么把 flag 抠出来。如果你已经会一点 Python、能看懂简单的汇编指令、知道 Wireshark 的基本用法这套题就能直接拿来练。下面按「拿到题先干什么 → 静态和动态怎么配合 → 抓包题怎么切 → 坑在哪」的顺序拆开讲。2. 逆向题的起手式文件识别、反编译与关键函数定位2.1 拿到文件先别急着扔 IDACTF 逆向题常见的文件类型就那么几种Linux ELF、Windows PE、Android APK、Python 打包的 pyc、还有各种固件和流量包。不同格式对应不同的分析工具链选错了工具就是白费功夫。我一般拿到文件先跑一遍基础识别确认架构、位数、是否加壳、有没有符号信息。# 基础文件识别三连 file ./challenge # 看文件类型和架构 checksec --file./challenge # 看保护机制PIE/NX/Canary strings -n 8 ./challenge | head -50 # 快速扫可读字符串file命令告诉你这是 64 位 ELF 还是 32 位 PE决定了你后面用 IDA 的哪个版本、调试器怎么配。checksec看的是二进制保护如果 PIE 开着说明基址随机化静态地址不能直接用来下断点如果 NX 开着栈上不能执行 shellcode。strings是最快的情报收集手段很多入门题的 flag 格式串、提示信息、甚至假 flag 都会直接暴露在字符串里。注意-n 8是过滤掉长度小于 8 的字符串避免输出被短字符串淹没。常见做法是先用strings搜flag{、ctf{、key这类关键词如果直接命中题目基本就结束了。但大多数题不会这么直白字符串里可能只有提示真正的逻辑藏在函数里。2.2 用 IDA/Ghidra 定位校验逻辑静态反编译的核心目标是找到「输入经过什么变换后和什么比较」。在 IDA 里我习惯先看main函数的伪代码然后顺着输入函数scanf、fgets、read、std::cin往下追。Ghidra 的反编译质量在近几年提升明显对于没有 IDA 授权的同学完全够用。# 以一道典型异或校验题为例还原后的校验逻辑 def check(input_str): target [0x12, 0x34, 0x56, 0x78] # 从反编译里抄出来的比较数组 if len(input_str) ! len(target): return False for i, ch in enumerate(input_str): # 反编译里看到的是 (ch ^ 0x2a) target[i] if (ord(ch) ^ 0x2a) ! target[i]: return False return True # 逆向求解把异或反过来算 flag .join(chr(t ^ 0x2a) for t in [0x12, 0x34, 0x56, 0x78]) print(flag)这段代码展示的是逆向题里最常见的模式正着算校验反着算求 flag。关键参数是异或密钥0x2a和比较数组target这两个值必须从反编译结果里准确抄出来抄错一个字节结果就全错。实际题目里可能是加减、移位、查表、Base64 混合变换但思路一样——把校验函数翻译成 Python然后写逆函数。注意从 IDA 伪代码抄数组时注意数据类型。int和char的宽度不同大端小端也会影响字节顺序抄完最好用hex打印一遍核对。2.3 动态调试配合静态分析静态分析卡住的时候动态调试就是后悔药。在 Linux 下用gdb配合pwndbg插件在 Windows 下用x64dbgAndroid 上则常用frida做 hook。动态调试的核心操作就三个下断点、看内存、改寄存器。# gdb 动态调试基本流程 gdb ./challenge # 在关键比较指令处下断点 b *0x401234 # 运行并传入测试输入 r test_input # 断下后查看寄存器和栈 info registers x/20x $rsp # 查看某个地址的字符串 x/s 0x402000b *0x401234是在指定地址下断点地址来自 IDA 里看到的比较指令位置。r test_input是把测试输入通过 here-string 传进去。断下来之后info registers看寄存器状态x/20x $rsp看栈内存x/s按字符串格式看内存。动态调试最大的价值是能让你看到运行时才生成的字符串——比如有些题会先解密一段数据再比较静态看不到明文但断在比较指令处就能直接读到解密后的内容。常见坑是断点地址在 PIE 开启时是偏移量而不是绝对地址需要先start让程序加载再用b *$base0x1234的方式下断。另一个坑是输入被scanf截断导致你传的测试数据根本没进到校验函数这时候要在输入函数处也下个断点确认数据流。3. 抓包逆向题从流量里还原协议和 flag3.1 流量包的第一遍筛协议分层与可疑流CTF 里的抓包题通常给一个.pcap或.pcapng文件flag 藏在某个协议的通信内容里。Wireshark 是标准工具但打开之后不要从头到尾翻包先做协议分层统计。# 用 tshark 快速统计协议分布 tshark -r capture.pcap -q -z io,phs # 过滤出所有含 flag 关键词的流 tshark -r capture.pcap -Y frame contains flag -T fields -e frame.number -e _ws.col.Info # 导出特定 TCP 流的原始数据 tshark -r capture.pcap -q -z follow,tcp,raw,0-z io,phs输出协议分层统计让你一眼看出这个包里有 HTTP、DNS、TCP 还是 USB 流量。-Y frame contains flag是显示过滤器直接搜包含 flag 字样的帧。-z follow,tcp,raw,0是跟踪第 0 号 TCP 流并以原始十六进制输出。这三条命令基本能覆盖 80% 的抓包题起手需求。常见做法是先用协议分层确定主协议再用contains搜关键词最后用follow跟踪具体流。如果 flag 被分片传输或者编码过就需要导出原始数据再做进一步处理。3.2 USB 流量与键盘击键还原USB 流量分析是 CTF 抓包题里的一个经典子类尤其是键盘和鼠标流量。键盘流量的原理是USB 协议里键盘发送的 HID 报告包含按键码把按键码按 HID 映射表翻译成字符就能还原输入内容。# USB 键盘流量还原脚本 # HID 键码到字符的映射表部分 hid_map { 0x04: a, 0x05: b, 0x06: c, 0x07: d, 0x08: e, 0x09: f, 0x0a: g, 0x0b: h, 0x0c: i, 0x0d: j, 0x0e: k, 0x0f: l, 0x10: m, 0x11: n, 0x12: o, 0x13: p, 0x14: q, 0x15: r, 0x16: s, 0x17: t, 0x18: u, 0x19: v, 0x1a: w, 0x1b: x, 0x1c: y, 0x1d: z, 0x1e: 1, 0x1f: 2, 0x20: 3, 0x21: 4, 0x22: 5, 0x23: 6, 0x24: 7, 0x25: 8, 0x26: 9, 0x27: 0, 0x2d: -, 0x2e: , 0x2f: [, 0x30: ], } # 从 tshark 导出的 USB 中断数据中提取按键码 # 命令tshark -r usb.pcap -T fields -e usb.capdata keystrokes.txt with open(keystrokes.txt) as f: for line in f: data line.strip().split(:) if len(data) 3: key_code int(data[2], 16) # 第三个字节是按键码 if key_code in hid_map: print(hid_map[key_code], end)这段脚本的关键参数是usb.capdata字段它包含 USB 中断传输的原始数据。键盘 HID 报告通常是 8 字节第三个字节索引 2是按键码。tshark -T fields -e usb.capdata把每个 USB 包的 capdata 导出成一行再用 Python 解析。注意有些包的 capdata 为空或者全零表示没有按键动作需要跳过。提示如果导出的 capdata 是00:00:00:00:00:00:00:00这种全零说明那一帧没有按键直接忽略。另外注意大小写和 Shift 键的处理HID 报告的第一个字节是修饰键表示 Shift/Ctrl/Alt 是否按下。3.3 自定义 TCP 协议逆向有些抓包题不走标准协议而是自定义的 TCP 通信。这时候需要先跟踪一条完整的 TCP 流看客户端和服务端之间的数据格式找出包头、长度字段、命令字和 payload 的边界。# 解析自定义 TCP 协议假设包头 4 字节前 2 字节是 magic后 2 字节是长度 import struct def parse_custom_protocol(raw_data): offset 0 messages [] while offset len(raw_data): if offset 4 len(raw_data): break magic, length struct.unpack(HH, raw_data[offset:offset4]) if magic ! 0xdead: # 假设 magic 是 0xdead offset 1 continue payload raw_data[offset4:offset4length] messages.append(payload) offset 4 length return messages # 从 tshark 导出的原始流数据读取 with open(stream_raw.bin, rb) as f: data f.read() for msg in parse_custom_protocol(data): print(msg)struct.unpack(HH, ...)里的表示大端序H表示无符号短整型2 字节。如果实际协议是小端改成。magic是协议识别码用来在字节流里定位消息起始位置。length字段告诉你 payload 有多长据此切分消息。这段代码的通用套路是先猜包头结构再用实际数据验证如果解析出来的 payload 看起来有规律比如都是可打印字符或者都是递增序列说明包头猜对了。常见坑是 TCP 流里混有重传和乱序包直接用follow,tcp,raw导出的数据可能包含重复内容。这时候要么在 Wireshark 里先过滤tcp.analysis.retransmission要么在脚本里做去重。另一个坑是长度字段包含包头本身导致偏移量算错需要根据实际数据调整offset的增量。4. 避坑与排查逆向抓包题里最容易翻车的五个点4.1 反编译结果和实际运行不一致现象IDA 伪代码里看到的逻辑用 Python 还原后算出的 flag 提交上去是错的。原因反编译器对某些指令的翻译有偏差尤其是涉及浮点运算、位域操作和编译器优化后的代码。解决不要完全信任伪代码关键逻辑要对照汇编指令逐条确认。用动态调试在关键点下断直接读内存里的实际值以运行时数据为准。4.2 抓包文件里有多条流选错了分析对象现象跟踪了一条 TCP 流翻来覆去看不出 flag以为题目有问题。原因pcap 里可能同时存在 HTTP、DNS、TCP 多条流flag 藏在另一条流里。解决先用tshark -q -z io,phs看协议分布再用-Y tcp.stream N逐条流排查。不要一上来就盯第一条流。4.3 USB 键盘流量里 Shift 键没处理现象还原出来的字符串全是小写但 flag 里明明有大写字母。原因HID 报告的第一个字节是修饰键Shift 按下时同一个按键码对应的是大写字符或符号。解决解析时先检查修饰键字节如果data[0] 0x02非零表示 Shift 按下此时按键码要映射到大写或符号表。这个细节在入门资料里经常被略过但实际题目里很常见。4.4 动态调试时断点没生效现象gdb里下了断点程序直接跑完退出断点根本没触发。原因PIE 开启时地址是随机化的静态地址下断无效或者断点下在了没被执行的分支上。解决先start让程序加载用info proc mappings看基址再b *$base偏移下断。或者用b *main0x10这种符号加偏移的方式让 gdb 自己算地址。4.5 字符串编码问题导致 flag 显示乱码现象从内存或流量里读出的数据打印出来是乱码但长度和预期一致。原因数据可能是 UTF-16、GBK 或者经过简单编码如 Base64、ROT13。解决先看字节的十六进制分布如果高位字节有规律比如都是0x00或0x04可能是宽字符。用iconv或 Python 的decode尝试不同编码。如果是 Base64直接丢给base64 -d试一下。5. 进阶技巧用 Python 脚本批量处理逆向题中的重复模式5.1 把常见变换写成可复用的工具函数做多了逆向题会发现很多变换是重复出现的异或、加减、移位、查表、Base64、RC4。与其每次重新写不如攒一个自己的工具库。我一般会把这些函数放在一个ctf_utils.py里遇到新题直接 import。# ctf_utils.py - 逆向题常用变换工具集 import base64 def xor_bytes(data, key): 单字节或多字节循环异或 if isinstance(key, int): key [key] return bytes(b ^ key[i % len(key)] for i, b in enumerate(data)) def caesar_shift(data, shift): 凯撒移位只处理字母 result [] for ch in data: if a ch z: result.append(chr((ord(ch) - ord(a) shift) % 26 ord(a))) elif A ch Z: result.append(chr((ord(ch) - ord(A) shift) % 26 ord(A))) else: result.append(ch) return .join(result) def brute_xor_single(data, prefixbflag{): 爆破单字节异或密钥用已知前缀验证 for key in range(256): decoded xor_bytes(data, key) if decoded.startswith(prefix): return key, decoded return None, None # 使用示例 encrypted bytes([0x1a, 0x0e, 0x1d, 0x1c, 0x7b]) # 假设的密文 key, flag brute_xor_single(encrypted) if key is not None: print(f密钥: {key:#x}, flag: {flag})xor_bytes支持单字节和多字节密钥多字节时循环使用密钥。caesar_shift只对字母做移位保留数字和符号不变这是凯撒密码的标准行为。brute_xor_single是最实用的函数——当你怀疑是单字节异或但不知道密钥时用已知的 flag 前缀通常是flag{或ctf{去爆破256 种可能一秒跑完。参数prefix可以根据题目提示调整比如有些比赛用DASCTF{或NSSCTF{。5.2 用 angr 做符号执行自动求解当逆向题的分支逻辑特别复杂手动分析成本太高时符号执行是值得尝试的方案。angr 是 Python 的二进制符号执行框架能自动探索路径并求解满足条件的输入。import angr import claripy # 加载二进制auto_load_libsFalse 加速加载 proj angr.Project(./challenge, auto_load_libsFalse) # 设置目标地址找到打印 Correct 或 flag 的分支 # 先用 strings 或 IDA 确认成功分支的地址 find_addr 0x401234 # 成功分支地址 avoid_addr 0x401456 # 失败分支地址 # 创建初始状态输入从标准输入读取 state proj.factory.entry_state() simgr proj.factory.simulation_manager(state) # 探索路径找到 find_addr避开 avoid_addr simgr.explore(findfind_addr, avoidavoid_addr) if simgr.found: found simgr.found[0] # 求解标准输入的内容 solution found.posix.dumps(0) print(f求解结果: {solution}) else: print(未找到可行路径检查地址或增加探索深度)proj.factory.entry_state()创建程序入口点的初始状态。simgr.explore(find..., avoid...)让 angr 自动探索所有路径直到找到满足find地址的状态。found.posix.dumps(0)把标准输入的文件描述符内容 dump 出来就是满足条件的输入。关键参数是find_addr和avoid_addr这两个地址必须从静态分析里准确获取——通常find是打印成功信息的分支avoid是打印失败信息的分支。angr 的局限也很明显对复杂加密算法和大量循环的代码状态爆炸会让求解时间不可接受。我一般只在分支多但每个分支逻辑简单的题目上用 angr遇到加密算法还是老老实实手动还原。另外 angr 对 Windows PE 的支持不如 ELF 好PE 题建议用 x64dbg 动态调试。注意angr 安装用pip install angr但依赖较多建议在虚拟环境里装。跑 angr 时如果卡住不动先检查find_addr是否可达可以用simgr.run()先跑一遍看探索了多少状态。从那以后我每次拿到新题都强制先跑一遍filechecksecstrings三连再决定是静态分析还是动态调试是手动还原还是上 angr。这个习惯帮我省下了大量在错误方向上浪费的时间。希望帮到你。本文还有配套的精品资源点击获取
