DesCTF Misc WriteUp：从图片隐写到内存取证的全流程复现

CTF里的Misc，一直是我觉得最考验选手“信息嗅觉”的一个分类。它不考你某个渗透框架用得多熟，也不考某个漏洞利用链背得多全，它考的是你对“数据载体”本身的敏感度——一张照片的像素最低位、一段音频的频谱图、一坨看起来毫无规则的流量包、甚至一个进程的内存快照，里面都可能藏着答案。今年DesCTF的Misc部分一共五道题，从入门级的图片隐写一路做到内存取证，难度梯度拉得很开，很适合用来梳理一套自己的解题范式。赛后我把每道题的复现步骤和踩坑点重新过了一遍，整理成这篇WriteUp，给同样在Misc方向摸爬滚打的兄弟们做个参考。

1. 赛题总览与Misc命题思路

1.1 这次Misc部分的整体风格

先说结论：这五道题没有一道是“为了难而难”的偏题怪题，全部落在Misc最常见的几个方向里——隐写、音频分析、流量分析、编码转换、内存取证。题目解法基本都能用公开工具加一个小脚本搞定，没有依赖某个冷门商业软件，也没有需要逆向某个未知文件格式的变态要求。这种风格对新手比较友好，但对“工具链熟练度”和“信息敏感度”的要求一点没降，大部分丢分都发生在选手不知道该往哪个方向怀疑。

另外有个值得注意的特点，五道题里出现了两道“复合型”题目，一道是LSB隐写配合压缩包密码，另一道是USB流量分析配合HID键位还原。这种把两个考点串起来的出法，其实是近年CTF Misc的一个趋势。单一技能点很难再撑起一道题的分量，命题人更倾向于考选手能不能在一个流程里切换多种思路。如果你只会跑工具、不理解工具背后在做什么，遇到这种题很容易在某一步卡死。

题目设计上还有一个隐性要求，就是“信息可能藏在任何地方”，这句话听起来像废话，但真到了赛场上，很多人会带着固定思维去做题。拿到图片先看EXIF、拿到音频先听完、拿到流量先过滤HTTP，这些都是惯性动作。这次有一道题恰恰是反着来的，音频听起来就是白噪音，结果信息在频谱图里；流量包里全是TCP握手包，结果信息藏在USB中断传输里。所以我自己复盘的时候，最大的收获就是“不要被载体的第一直觉带跑”。

1.2 五道题的技术分布与难度分级

先大概给个题目画像，后面详细展开：

这个难度梯度是我比较认可的一种出题节奏。前两道题保证大多数参赛者能拿分，中间两道题筛选出有一定工具使用经验的选手，最后一道题拉出真正对取证流程有理解的人。从结果看也是这样，100分题目的提交率明显高于300分那道，但300分那道反而是整场比赛里“解题手法最统一”的——所有解出来的队伍基本都走到了Volatility定位进程这一步，区别只在于谁先想到去看历史命令行。

2. 环境与工具准备

2.1 一整套趁手的工具清单

Misc方向对环境的依赖比较重，很多题换个工具可能就看不出结果。我这次反复用到的工具如下，建议直接装齐：

装完之后一定要做一件事：把每个工具的--help或基础文档翻一遍，知道每个参数干什么。赛场上真正卡时间的不是安装，而是“我知道该用这个工具，但不知道参数怎么写”。比如zsteg的-a和-E的区别、tshark的-Y过滤语法、Volatility的--profile指定，这些小参数用熟了，整个流程会顺畅非常多。

2.2 一套可以复用的解题工作流

Misc题目看起来千变万化，但我习惯先走一套标准流程，把“快筛”和“细看”分开。拿到题目文件后的第一轮操作通常是：

1. file命令确认真实文件类型，同时看一眼文件大小，这个数字有时会提示你有没有塞额外数据。
2. strings扫一遍，看看有没有可读字符串，很多题目会在文件的头部或尾部加一句注释性提示。
3. binwalk检测有没有附加文件，如果有，分离出来再重复前两步。
4. 如果是图片，用zsteg扫LSB；如果是音频，用Audacity看频谱图；如果是流量包，先统计协议。
5. 如果前四步都没结果，再往“编码转换”和“取证分析”方向想。

这套流程不能保证解决所有题，但能把一道题的“可疑面”快速压缩到几个方向里。这届DesCTF的101和102题，基本就是这套流程的前四步直接出结果。后三道题需要在流程里额外加一层思考，比如103题要在流量包里意识到“USB协议才是重点”，105题要主动去翻Volatility的cmdline插件而不是一股脑dump内存，这些属于你在标准流程上根据题目提示做的动态调整。

3. 逐题WriteUp详解

3.1 签到题：隐蔽的角落（图片LSB隐写）

题目给了一张草原风景照，名叫meadow.png，拿到手先走标准流程。file确认是PNG，尺寸是3840x2160，文件大小4.2MB，这个大小对于这个分辨率来说略微偏大，但还在合理范围内，并没有立刻引起警觉。strings扫出来一大片PNG的IDAT数据流，没有明显的文字提示。binwalk也没有检测到附加文件，说明东西不在文件尾部，那就是藏在像素数据里了。

接下来用zsteg做LSB检测，命令是zsteg -a meadow.png。输出的末尾几行出现了一段规律性的字符串，仔细看是Base64编码的文本。这里顺便说明一下LSB隐写的原理：PNG图片用的是无损压缩，每个像素的RGB三个通道各有8位，修改最低1位人眼根本看不出来，但这种修改可以被工具检测到。如果某张图片的某个颜色通道最低位出现了非随机分布的数据，那基本就是LSB隐写没跑了。

我把检测到的Base64字符串提取出来，准备用Python解码。这里有个小经验：zsteg输出时可能会把隐写数据和噪声混在一起，不要整段拿去解码，先在视觉上找到规律的起点和终点，截取那一段。用Python的base64模块解码后，得到了一句提示：“密码是你写下的第一个名字”。看到这个提示第一反应是去找图片有没有作者信息或备注，用exiftool查看EXIF，发现图片的“作者”字段是camelia，全小写。试了下直接用camelia当密码去解压，结果是个压缩包，里面就是flag。

复现的核心命令：

zsteg -a meadow.png > result.txt cat result.txt # 人工识别规律字符串

import base64 data = "BASE64字符串" print(base64.b64decode(data).decode())

这道题的关键不在工具，而在识别“那段字符串值得解码”。很多人跑完zsteg看到一堆输出就懵了，实际上隐写数据往往有比较明显的熵特征。我习惯把zsteg -a的输出保存成文本，然后用编辑器看，熵高的区域就是可疑区域。这个习惯在这道题里直接节省了半小时。

3.2 第二题：电波里的秘密（音频频谱图隐写）

第二题给了一个signal.wav，时长30秒，用播放器打开是均匀的白噪音，波形图上看不出明显异常。这种“全频段均匀噪声”的音频，第一直觉就应该是频谱图隐写。Misc圈里有个经典玩法：把一段文字或图像以“视觉图案”的方式画在音频的频谱上，人耳听不到，但打开频谱图一眼就能看到。

我用Audacity打开signal.wav，点击左上角波形图右侧的下拉箭头，切换到“频谱图”视图。默认的频谱图设置可能不够清晰，我把频率范围调到0到8000Hz，对比度稍微拉高了一点，果然在2000Hz到4000Hz之间出现了一行字迹样式的图案，横跨了整个频谱图的时间轴。图案内容是flag{h3r3_y0u_g0}。

直接把flag抄下来提交就完事。不过说实话这道题能丢分的地方基本只有两个，第一是没想到切频谱视图，第二是图案太淡没看清。对于后者，可以在Audacity的“频谱图设置”里把“最大频率”调低，把“增益”调高，让图案更突出。实际操作中我发现把窗口类型调成Hann窗或者Blackman-Harris窗会让文字边缘更锐利，这个细节在图案比较模糊的时候很重要。

我从这道题里得到一个通用经验：凡是题目描述里带“声音”“电波”“音符”这类词，且音频内容本身没有旋律，第一件事就是频谱图，而不是反复听。反过来，如果音频听着有明确旋律，则可能要关注音符序列、DTMF拨号音、SSTV慢扫描电视信号等方向，这些属于音频Misc里的另一个分支。这次只考了频谱图，算是最友好的一个形态。

3.3 第三题：键盘记录者（USB流量分析）

第三题是目前为止第一个真正需要写脚本处理的题。题目给了一个usb.pcapng，描述是“某人的键盘被偷偷录了音”，光看描述容易往“录音”方向想，但打开流量包就清楚了，这不是麦克风录音，而是USB接口层面的监控，录的是键盘发出的USB中断传输报文。

用Wireshark打开usb.pcapng，看到大量USB协议报文。直接在菜单栏统计->协议分级里看一眼，USB协议占了绝大多数。题目说“键盘”，所以重点过滤USB人机交互设备（HID）的报文。USB键盘的数据包通常具备几个特征：传输方向是设备到主机（URB_BULK in或URB_INTERRUPT in）、数据长度8字节、第一个字节是修饰键，第二个字节是保留位，第三个字节开始的六个字节是按键键码。不过市面上的抓包环境里，最常出现的是URB_INTERRUPT in这样的包。

我先用tshark把按键数据提取出来，命令如下：

tshark -r usb.pcapng -Y "usb.transfer_type == 0x03 && usb.direction == 1 && usb.endpoint_number == 0x81" -T fields -e usb.capdata > data.txt

这里usb.transfer_type == 0x03是中断传输，usb.direction == 1是设备到主机方向，usb.endpoint_number == 0x81是常见的键盘端点。如果端点号不同，具体题目需要先看键盘设备的描述符，这里用Wireshark的“端点”统计看了一下，端点0x81是唯一频繁收数据的端点，就选它了。

过滤出来之后，每一行是一个8字节十六进制数据，例如0200000000000000，前两位02是Shift修饰键。我写了一个Python脚本，按USB HID键码映射表把每个包翻译成字符，同时处理修饰键（Shift触发的大小写切换），大致逻辑如下：

# usb_to_text.py 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', 0x28: '\n', 0x2a: '[', 0x2b: ']', 0x2c: '\\', 0x2d: ';', 0x2e: "'", 0x2f: '`', 0x30: ',', 0x31: '.', 0x32: '/', 0x33: ' ', 0x34: 'CAPS', 0x36: ';' } shift_map = { '1': '!', '2': '@', '3': '#', '4': '$', '5': '%', '6': '^', '7': '&', '8': '*', '9': '(', '0': ')', '-': '_', '=': '+', '[': '{', ']': '}', '\\': '|', ';': ':', "'": '"', ',': '<', '.': '>', '/': '?' } def parse_usb_line(line): parts = line.strip().split(':') if len(parts) < 3: return '' modifier = int(parts[0], 16) keycode = int(parts[2], 16) if keycode == 0: return '' ch = hid_map.get(keycode, '') if modifier & 0x02: # Left Shift ch = shift_map.get(ch, ch.upper() if ch.isalpha() else ch) return ch with open('data.txt', 'r') as f: out = [] for line in f: out.append(parse_usb_line(line)) text = ''.join(out) print(text)

需要注意的是，有的抓包里按键事件还分Press和Release，同一个按键会产生两个包。常用的处理方式是只过滤URB_INTERRUPT in里的press包，或者把release包当作去重依据。这次流量包里的release包键码为0，所以脚本里直接忽略键码为0的行，问题不大。如果你的流量包里release包也带键码，那就需要额外判断包头的状态字段，这是USB键盘流量题最常见的坑。

最终跑出来的字符串是一个英文句子，中间直接嵌着flag{...}，没有多余的编码层。这道题的核心难点不在脚本，而在意识到“键盘记录”对应的是USB HID流量，而不是常见的HTTP或DNS流量。如果你全程在Wireshark里翻TCP流，花几个小时也不一定找得到线索。

3.4 第四题：嵌套的迷宫（多层编码转换）

第四题给了一个名为message.txt的文本文件，打开之后是一长串十六进制字符，长度大约4000个字符。直觉告诉我这是一个多层编码嵌套题，因为内容既不是人类语言，也不是图片或音频的头部结构。我用xxd -r -p把十六进制转成二进制，得到的数据用file查看，结果是gzip compressed data。

这一步是个重要信号：编码嵌套题的第一步通常是“识别数据格式”，而非“解码”。我把二进制数据用gzip -d解压，得到一段Base64文本。说实话看到Base64字符串的时候，我直接本能地解码了一次，得到的却还是乱码。后来把解码后的字节再丢给file，发现是URL编码格式的字符串：一堆%E4%BD%A0%E7%9C%9F%E7%9A%84%E5%BE%88%E6%A3%92。

URL解码之后是中文“你真的很棒，但还差一步”。看到这个提示，我心里就有数了，最后一步大概率是某种移位密码。中文提示本身不是flag，那就把前面每一层解出来的“中间产物”再翻一遍，看有没有遗漏。最后我在第一轮十六进制转二进制的数据末尾，发现了被00字节填充掩盖的一小段密文，把它单独提取出来，做凯撒移位，枚举25个偏移量之后在某个偏移下读出了可读的flag。

整理一下完整的解码链路：

# 第一层：hex -> binary xxd -r -p message.txt > step1.bin # 第二层：gzip解压 gzip -d < step1.bin > step2.txt # 第三层：Base64解码 base64 -d step2.txt > step3.bin # 第四层：URL解码（Python urllib） # 第五层：凯撒移位枚举

这道题其实不难，但它的“坑”很有代表性。很多人解完第三层就以为结束了，看到中文提示就去找“藏在文本里”的flag，结果找不到。我当时是带着一个观念在做题：“多层编码题可能在任何一层藏额外的尾巴”。十六进制转二进制后那个文件末尾连续几百个00其实很显眼，但如果你不回头去看这一步的产物，很容易漏掉。建议大家在处理编码嵌套题时，每一步的输出都保留成独立文件，不要直接管道式地一路解到底，留一份中间产物是回头检查的关键。

3.5 第五题：隐藏的进程（内存取证）

最后一题给了一个内存镜像文件memory.raw，没有多余提示。这种题几乎就是Volatility的主场，但Volatility对Python环境和版本兼容性上有不少小毛病，我用的是在Linux虚拟环境里跑的标准版本。第一步是确认镜像的基本信息：

volatility -f memory.raw imageinfo

这一步会输出推荐的Profile，比如Win7SP1x64之类的。拿到Profile之后，后续所有命令都要带上--profile=Win7SP1x64。接下来我按取证标准流程走：先列进程、再看网络连接、再扫文件。pslist列出来一系列常规进程，但有两个点引起了我的注意，一个是notepad.exe，另一个是cmd.exe。CTF内存取证题里，记事本和命令行同时出现几乎等同于“明示”，答案大概率就和这两个进程相关。

我先把cmd.exe的历史命令行拉出来看看，用了cmdline插件。惊讶地发现里面有一条命令是echo ZmxhZ3tjbWRf... | base64 -d，很明显，这列Base64字符串解出来就是flag。可能有人会问，为什么不让选手去dump记事本内存，而是藏在命令行历史里？我猜命题人的本意可能是想考cmdline插件，因为很多新手玩Volatility只会pslist和memdump，不太会主动去翻进程的命令行参数。这个设计其实挺巧的，它告诉你“取证分析”不光是导内存、扫字符串，还包括对进程行为的理解。

不过为了保险，我还是顺手验证了一下notepad.exe的内存。用memdump插件把进程内存导出来：

volatility -f memory.raw --profile=Win7SP1x64 memdump -p 1234 --dump-dir=./dump

然后在dump目录里对1234.dmp跑strings，查找flag关键字，也能找到一段包含flag的文本。所以这道题其实有两条路都能通：一条走cmdline看命令历史，一条走memdump扫进程内存。两条路都指向同一段信息，只是前者更快。这种“冗余路径”设计我认为是加分项，对取证新手更友好，不至于死磕某一个插件。

第五题值得单独说一个经验：拿到内存镜像后不要一上来就memdump大进程，先花两分钟看pslist和cmdline，很多CTF内存题就藏在这两个基础插件里。大进程的内存转储动辄几百MB，strings扫起来又慢又费时间，在没有明确目标的情况下属于低效操作。

4. 常见问题与排查思路实录

4.1 一张拿来就能用的排查速查表

这次比赛从我自己和周围选手的反馈来看，丢分点大多集中在几个固定环节，整理成速查表放在下面，遇到问题可以对照着看：

这份表的核心逻辑是“先怀疑载体，再怀疑方向”。Misc题如果在一个方向里查了十分钟没有结果，不要恋战，大概率是开始的方向就错了。这次很多队伍在第三题上耗了一个多小时，一直在翻TCP流，就是因为没有及时跳出“流量包就等于HTTP/DNS”的惯性思维。

4.2 几条我反复踩过的实战经验

先说工具层面的。zsteg检测LSB时，如果输出特别长，不要直接在终端里看，保存成文件后人工扫一遍。隐写数据往往会在视觉上形成“一行行规律文本”的效果，终端滚动太快容易错过。Audacity的频谱图颜色方案也可以手动调，默认的配色在部分屏幕上对比度不足，改成果汁色或者暖色系，文字图案会清晰很多。

再说操作层面的。分析USB流量时一定要先确认键盘的端点和接口，不要拿所有USB包直接当成键盘数据。有的鼠标流量包也是8字节，但HID键码映射完全不同，混在一起解析出来的文本会非常迷惑。确认端点的方法很简单，在Wireshark里看设备描述符，或者统计一下各个端点收到的数据长度分布，键盘的数据长度固定是8个字节。

针对编码嵌套题，我的习惯是每次解码前先保存原始中间文件，然后只对副本操作。这个习惯在此次第四题里直接帮了大忙，因为回头检查“十六进制转二进制”这一步的产物时，发现了藏在尾部00字节后面的密文。如果当时图省事用管道一路解下去，这个线索就永久丢了。

Volatility方面，环境兼容性其实是大坑。不同版本的Volatility对同一镜像的解析结果可能略有差异，比赛时不要在一个版本上死磕。如果imageinfo给出的推荐Profile不够准确，可以多试几个相近的，比如Win7SP1x64和Win7SP0x64都可能工作。实在不行还可以用KDBG地址来辅助指定Profile，这是进阶技巧，但关键时刻真能救命。

还有一条关于时间分配的经验：Misc部分通常分值不高，不必在第一道题上磨太久。我自己有一个时间红线，每道题最多投入45到50分钟，超过这个时间就果断先放下，去做其他题目或者重新审题。这次第三题的USB流量包，我一开始方向错了，翻了近四十分钟的TCP流，后来重新读题才反应过来是USB流量，差点被带进死胡同。冷静下来重新审题往往是打破僵局最快的方式。

回看这届DesCTF的Misc部分，五道题的技术含量不算高深，但胜在覆盖了Misc的主流题型，而且每一道题都设置了一个“思维拐点”。这些拐点不是靠刷题量能直接跨越的，更多靠平时积累的“信息有多可疑”的判断力。我个人体会最深的一点是：Misc不是比谁知道的多，而是比谁更愿意对每一个细微异常保持好奇。工具再全，人没有怀疑精神，照样会从flag面前走过去。所以建议新入坑的朋友，别只盯着WriteUp里的命令和脚本，多问问“为什么作者会想到这里、为什么这一步要这么处理”，这种思路层面的积累，才是Misc水平真正提升的地方。