CTF图片隐写全攻略：从PNG结构到LSB提取的实战思路

CTF 打得久了你会发现，图片隐写题在 Misc 里属于那种"会者不难、难者不会"的题型。你说它简单吧，确实有选手五分钟不到就交 flag 离场；你说它难吧，卡住的时候你盯着那张图看半小时也看不出任何异常。我打 CTF 这几年，最深的感受就是：隐写题考察的不是天赋，而是对文件格式底层细节的熟悉程度，以及一套稳定可靠的排查流程。只要你对 PNG、JPEG 这类常见图片格式的结构了如指掌，再配上几个顺手工具，大部分隐写题都能在可控时间内解出来。这篇文章我就把图片隐写从入门到实战的完整思路拆开讲，从文件格式原理到工具链搭配，再到一道多步骤综合题的完整破题流程，一次性说明白。

文章适合两类人：一类是刚接触 CTF、准备在 Misc 方向拿分的入门选手，另一类是已经会一些基础操作但做题总卡在某一层、想系统梳理排查思路的进阶玩家。我会尽量把每一步的"为什么"也讲清楚——很多人只会用工具，却不明白工具在干什么，遇到新题型就直接抓瞎，这是最可惜的。

1. 隐写题为什么是 CTF 的"必争之地"

1.1 从一道签到题说起：隐写题的真实形态

我记得第一次参加校内的 CTF 选拔赛时，Misc 方向第一题就是一张风景图。题目描述只有一句话：flag 就在这张图里。当时我用的方法极其原始——把图片拉到最大，一格一格地用眼睛找有没有异常像素。现在想想相当滑稽，但在那个没有工具、不懂原理的阶段，这是我唯一能想到的办法。

后来我才知道，那张图其实就是最经典的 LSB 隐写。把每个像素 RGB 通道的最低位提取出来，重新组成一张图片，flag 就清清楚楚地印在上面。整道题从入场到解出，熟练选手用 Stegsolve 点几下鼠标，不到一分钟就能搞定。

这个经历给了我一个很重要的启发：CTF 隐写题并不是在考"眼力"，而是在考"知识面"。出题人把信息藏在某个你知道但没深入过的角落——可能是图片的元数据，可能是像素的最低位，可能是文件尾部的附加数据，也可能是一个被改坏的 CRC 校验值。你知不知道这个角落的存在，决定了你能不能解出这道题。

1.2 隐写题的考察逻辑与备赛定位

从出题人的视角看，一道合格的隐写题通常遵循"隐藏 - 线索 - 提取"三段式结构。信息必须被隐藏，但隐藏方式不能太冷门，否则没人解得出来；过程中要留线索，让选手有迹可循；最终要能可靠提取，保证 flag 的完整性。

这也解释了为什么隐写题在 CTF 中非常适合做入门训练：它不要求你掌握复杂的利用链，也不要求深厚的编程功底，考察的核心就是对二进制数据和文件结构的敏感度。你只要会看十六进制、懂文件签名、能跑几个分析工具，就能覆盖相当大比例的题目。

从备赛策略上说，我建议每个 CTF 新手都优先把 Misc 里的图片隐写当成主要得分点之一。原因很简单：它性价比极高。Web 和 Pwn 方向的入门曲线陡峭，需要积累大量漏洞利用知识；逆向需要扎实的汇编基础和耐心；而图片隐写的基础知识可以在一个周末之内全部过一遍，剩下的就是靠刷题培养手感。对于想要在比赛中快速拿到保底分数的队伍来说，有一个能稳定解隐写题的队员，是非常大的定心丸。

2. PNG 和 JPEG 的文件结构：一切隐写手法的地基

2.1 PNG 的块结构：IHDR、IDAT、IEND 与附加数据的藏身之处

做图片隐写绕不开 PNG，因为它使用无损压缩，而且在 CTF 题目中的出现频率远高于其他格式。PNG 的全称是 Portable Network Graphics，它的一个关键设计是"块"（chunk）结构。整个 PNG 文件由一个固定的签名头和若干个数据块拼接而成。

文件头签名是固定的 8 个字节：89 50 4E 47 0D 0A 1A 0A。在十六进制编辑器里看到这串字节，就能确定这是一个 PNG 文件。签名之后就是各种块，每个块的结构完全一致：4 字节的长度字段、4 字节的类型字段、数据段、4 字节的 CRC 校验。

其中三个块是必须出现的：IHDR（图像头）、IDAT（图像数据）、IEND（图像结束）。IHDR 里存的是宽、高、位深、颜色类型这些关键参数；IDAT 里是经过 zlib 压缩的实际图像数据；IEND 是文件的结束标记。但除了这三种关键块，PNG 还允许大量辅助块存在，比如 tEXt、zTXt、iTXt，它们在设计上就是用来存文字信息的。

这里就是第一个藏东西的地方。出题人完全可以在 tEXt 这种文本块里塞一段 Base64 编码的字符串，或者直接把密码写在注释字段里。很多新手做题时只盯着图像本身看，完全忽略了这些注释内容。我通常的做法是拿到图片先跑一遍 strings 命令，把里面的可打印字符串全部列出来，这一步能过滤掉大量低级但常见的隐藏方式。

另外说一个隐蔽但高频的知识点：IHDR 里的宽高字段。PNG 的宽和高分别存在 IHDR 数据的第 8~11 字节和第 12~15 字节，每个是 4 字节的大端整数。如果你的十六进制编辑器足够熟练，可以直接把高度改大，让图片显示出一部分原本被裁掉的区域。很多题目会把真正的关键信息藏在图片的下方区域，但显示高度被人为调小，这种情况下图片在普通看图软件里看起来是完整的，只是底部被截断了。用 pngcheck 或 Python 的 struct 模块检查一下宽高值是否合理，往往能发现猫腻。

2.2 JPEG 的片段结构：从 SOI 到 EOI 的每个字节都可能做文章

JPEG 的结构和 PNG 完全不同。PNG 是块式组织，JPEG 是段式结构。每个段都以 FF 开头，后面跟一个字节的段标记。文件以 FF D8（SOI，图像开始）起始，以 FF D9（EOI，图像结束）结尾。

常见的段包括：FF E0（APP0，JFIF 信息）、FF E1（APP1，通常存 EXIF 信息）、FF FE（COM，注释段）、FF DB（DQT，量化表）、FF C0（SOF，帧开始）、FF C4（DHT，哈夫曼表）、FF DA（SOS，扫描开始，后面跟实际的压缩数据）。

JPEG 在隐写题里最常见的考点有两个。第一是在注释段或 APP1 段塞文字信息。这个用 strings 基本就能扫出来。但有一种情况容易忽略：文字不是明文存储，而是经过编码或者隐藏在十六进制里，直接 strings 扫不到，必须对着十六进制慢慢看。第二是把附加文件整个追加在 JPEG 文件末尾，因为 EOI 标记之后的数据不会被图片解码器读取，但文件本身是合法的。这种情况下你会拿到一个"图片 + 压缩包"的复合文件，Windows 下面直接打开还是显示图片，但如果用压缩软件直接打开，或者用 binwalk 扫描，就能发现隐藏在里面的第二个文件。

JPEG 还有一种比较进阶的隐写方式叫做"零系数隐写"或 DCT 域隐写。它利用的是 JPEG 压缩过程中离散余弦变换产生的 DCT 系数——修改某些特定位置的系数不会明显影响画面质量，但可以编码信息。像 steghide 这个工具的原理就和这类手法有关。这种题目会比 LSB 难一个档次，因为它要求你理解 JPEG 的压缩管线。好消息是遇到这种题不需要你真的从零实现编码器，steghide 这类工具已经封装好了提取逻辑，你要做的是能识别出"这张图可能用了 DCT 域隐写"。

3. 两类核心手法拆解：LSB 隐写与文件结构隐写

3.1 LSB 隐写原理与 Stegsolve 的像素级排查

LSB 全称是 Least Significant Bit，最低有效位。它的原理非常朴素：图像每个像素的颜色值由 RGB 三个通道组成，每个通道是一个 0~255 的整数，在二进制下就是 8 位。把 8 位数字的最低一位改掉，最多只让颜色值变化 1。人的眼睛对 1/255 的色差几乎没有感知，但对于计算机来说，每一位都是可以被利用的存储空间。

如果一张 1000x800 的图片，每个像素有 3 个通道，那就意味着有 240 万个最低位可以存数据。换算下来大约能存 300KB 的隐藏信息，足够放一段相当长的文本或者一张小尺寸的二维码。这正是 LSB 隐写在 CTF 里如此流行的原因：容量大、隐蔽性高、实现简单。

在实际做题时，我最常用的工具是 Stegsolve。它是一个 Java 小程序，专门用来做图片的像素级分析。打开图片后，有几个功能值得重点说。

第一个是 Analyse - Data Extract。这个功能允许你选择从哪个通道、哪一位来提取数据，提取结果可以显示为二进制文本、ASCII 文本或重新渲染成图片。做题时的操作思路通常是：先把 Bit Order 设成 LSB，把 R、G、B 三个通道都勾上，然后预览提取结果。如果文本区域显示出一段可读的文字，或者看起来像是某种编码，那就说明找对位置了。

第二个是 Analyse - Separate Channels。它可以把 RGB 各通道分离出来单独显示，有时候还能把每个通道的某一位单独可视化。如果题目把信息藏在绿色通道的第 0 位，而你的 Data Extract 设置了从红色通道提取，就会得到一堆乱码。这时候要做的就是逐个通道、逐位去试。

还有一个常见变体是"LSB 表"提取。有些题目不是按正常的行扫描顺序存取数据的，而是把信息逐行嵌入。我在做题时会用 Python 写脚本，按行读取像素的 RGB 值，对取出来的每一位做判断，再拼接成字符串。这种做法的优势是灵活，劣势是如果出题人不按套路出牌，脚本得跟着调整。

关于 LSB 隐写，有一个非常容易踩的坑：很多选手看到图片是 PNG 就直接用 Stegsolve 提取，结果发现拉出来的全是乱码，于是认定这道题不是 LSB。但实际上，出题人可能只把信息藏在了某一个通道里，或者提取顺序是"从左到右、从下到上"而不是默认的"从左到右、从上到下"。所以新手在做 LSB 题时，一定要多切换通道和位平面的组合，不要试一两次就放弃。

3.2 附加文件与文件头分析：binwalk、strings 和 hexdump 的快速识别

第二种高频考点是文件结构层面的隐藏，最常见的就是"文件里套文件"。一张正常的 JPG 图片，在 EOI 标记后追加一个 ZIP 压缩包，图片查看器不会报错，但 binwalk 一扫描就能发现端倪。binwalk 是一个固件分析工具，但它在 CTF 隐写题中的地位几乎成了标配，因为它能根据文件签名快速扫描出目标文件里嵌入了哪些其他文件。

使用 binwalk 的标准流程是：先执行 binwalk 图片文件 看扫描结果，如果发现某个偏移量处有 ZIP 或 RAR 签名，就用 -e 参数尝试提取。当前版本还会自动重命名提取出来的文件。但这里有一个很多人不知道的细节：binwalk 在提取 ZIP 时，有时不能正确处理部分文件，因为它本质上是按签名切割文件，而不是完整解析压缩包结构。遇到这种情况，我会手动记下偏移量，然后用 dd 命令把对应区域的文件切出来，再用 unzip 或者 7-Zip 去解压。

strings 命令也是一种极其重要的初筛手段。它会把文件中的可打印字符串提取出来。在 CTF 中，strings 最常见的用途是在图片里找 URL、邮箱、flag 片段或者压缩包密码。但这道命令也不是万能的，默认情况下它只扫 ASCII 字符串，对 UTF-16 编码的中文内容会直接忽略。如果你怀疑图片里有中文明文，记得加 -el 参数指定 little-endian 的宽字符编码。

说到十六进制分析，hexdump -C 或者 xxd 是必须熟练使用的工具。hexdump -C 的输出格式是"偏移量 + 十六进制字节 + ASCII 字符"，在分析文件头、检查文件签名、定位附加数据时都离不开它。我见过不少选手会用 strings 找线索，但到了需要精确查看某个偏移量处字节内容的时候就懵了，这就是因为平时没养成直接看十六进制的习惯。实际上，CTF 隐写题里很多线索的发现完全依赖人眼扫十六进制——可能是文件末尾一行不起眼的 Base64，可能是一段被隐藏的文本的字节序差异，这些都是 strings 扫不出来但肉眼能看出来的东西。

4. 完整实战：一道多步骤隐写题的破题全程

4.1 拿到图片后的第一轮排查：file、strings、binwalk 三连

纸上谈兵再多，不如实际拆一道题。下面这道题是从某次线上赛 Misc 方向抽出来的综合题，它的完整链路几乎涵盖了图片隐写的主流知识点。我先给出题面：你拿到一个压缩包，解压后发现里面只有一张 start.png。

我的第一轮排查永远是从 file 命令开始的。它在任何 Linux 发行版上都自带，作用是识别文件类型。file start.png 返回的是 PNG 格式，但注意看后面的详细信息，比如尺寸是 800x600、位深是 8 位。这些信息是后面的分析基础。

紧接着我跑 strings start.png，把可打印字符全部列出来。输出里有 IHDR、IDAT、IEND 这些正常块类型，还有一段看起来像 URL 的字符串。这个 URL 指向一个短链接地址，看起来像是出题人的引导线索。注意到 strings 的输出里还有 password: 7Z1pQ2 这样的字符——虽然这个字段看起来有点突兀，但在 strings 的输出里出现这种文本实在太常见了，很多选手会以为它是旗标，其实可能只是陷阱或半成品线索。

第二轮是 binwalk start.png。扫描结果里有一个明显的 ZIP 压缩包签名，偏移量在 0xA2B00 附近。这说明图片尾部确实被追加了一个 ZIP 文件。执行 binwalk -e，成功提取出一个名为 hidden.zip 的压缩包。用 unzip 解开时提示需要密码。我尝试了 strings 里看到的 7Z1pQ2，结果解压成功，里面是一个 flag.txt。

到这里，如果你以为题目已经结束，那就上当了。打开 flag.txt 发现里面是一段 Base64 字符串，解码后是一大段无意义的二进制数据，转换成图片则是一张模糊不清的低分辨率 BMP。这个 BMP 的大小是 400x400，颜色非常暗，肉眼几乎看不到任何信息。到了这一步，很多选手会卡住——这明显不是一个直接的答案，而是一个更隐晦的提示。

4.2 第二层线索：EXIF 信息与图片宽高的异常

回到 start.png，我重新检查了它的元数据。用 exiftool 查看 EXIF 信息时，发现 Comment 字段里有一句看似无关的话："The real answer is not in the pixels, but in the dark corner." 这句话暗示"答案不在像素里，而在黑暗的角落"。我第一反应是图像右下角可能藏了一段文字，但放大图片右下角后什么也没有。

这时候我想到另一种可能：这句话里的"dark corner"可能不是指画面的角落，而是指通道的暗部。在 RGB 模型中，暗部意味着数值较低的区域，例如像素值在 10 以下的区域。出题人可能在极低亮度区域用接近黑色的字写了信息，肉眼很难分辨，但把亮度和对比度拉高就能看到。

我打开 Stegsolve，用 Colour Inversion 功能对图片做反相处理，同时在 Gray Bits 中查看每个通道的最低位平面。在蓝色通道的第 0 位平面上，果然出现了一串白色文字。这个位置正好是图片的右下角区域——并不是它藏在右下角，而是这个区域的像素亮度非常低，LSB 位上的信息被压制在了暗部。把这一串字符记下来，得到一段十六进制字符串：66 6C 61 67 7B 70 6E 67 5F 6C 73 62 5F 69 73 5F 66 75 6E 7D。

4.3 收网：从 Hex 到 Flag 的转化与验证

看到这一串十六进制，我基本确定这就是最终答案了。把连续两个十六进制数字对应一个 ASCII 码：66 是 f，6C 是 l，61 是 a，67 是 g——开头是 flag{png_lsb_is_fun}。整个 flag 用 {} 包裹，符合题目格式要求。

直接把十六进制转 ASCII 就能得到 flag，都不需要写 Python 脚本。echo '66 6C ...' | xxd -r -p 一条命令搞定。

这道题最值得复盘的地方在于：如果第一轮在 strings 里发现 password，就回去直接解压拿到 Base64，然后顺着 Base64 解码、转 BMP、再 LSB 提取，也是一条通路。但如果你只停在"解压拿到一段 Base64"就以为完成了，就会错过最终 flag——因为 Base64 解码出来的是图片数据文件，不是明文答案。真正的 flag 藏在处理后的 BMP 里，而在第一步执行 binwalk -e 时其实已经可以看出这个逻辑：start.png 里藏的 ZIP 是表面上的答案，真正的内容在 ZIP 内部的 BMP 的 LSB 通道中。

这就是高频的综合套路：一层伪装 + 二层隐藏。表面隐藏给你一个"看起来像答案"的东西，诱使你在错误方向浪费大量时间，真正的 flag 藏在另一层更隐蔽的位置。做题的时候脑子里要始终有一根弦：你拿到的每一条线索，都可能只是下一层线索的入口。

5. 隐写实战中的工具清单与高频坑位

5.1 我常用的工具组合和调用逻辑

工欲善其事，必先利其器。做图片隐写题，下面这几个工具我几乎每次比赛都会用到，建议全部提前装好，不要等到比赛时再去下载：

这些工具的使用顺序通常遵循"从外到内、从粗到细"的原则。file 和 strings 先摸清文件的类型和可见字符串；binwalk 检查是否嵌入了其他文件；exiftool 查看元数据中是否有出题人留下的注释；如果以上都没有结果，再进入像素层面用 Stegsolve 和 zsteg 进行分析。

这里特别说一下 zsteg。它是一个 Ruby 写的命令行工具，专门用来检测 PNG 和 BMP 中的 LSB 隐写，可以自动尝试各种通道和位平面的组合。它的优点是一次性输出大量候选结果，省去手动在 Stegsolve 里来回切换的麻烦；缺点是无法处理某些特殊顺序的隐写方式，且输出可能包含大量误报。我的习惯是先用 zsteg -a 扫一遍，如果发现了疑似 flag 的片段就直接验证，如果没有再回到 Stegsolve 手动检查。

5.2 新手最容易踩的几个坑

第一个坑是忽略图片尺寸异常。Pngcheck 报出 CRC 错误，或者图片显示尺寸和实际像素不合理，都说明图片可能被动过手脚。最常见的是通过修改 PNG 的 IHDR 高度字段来隐藏内容。这时候用十六进制编辑器把高度值改大，保存后打开，就能看到原本被裁掉的画面。一个快速判断方法：用 python3 -c "import struct; print(struct.unpack('>II', open('a.png','rb').read()[16:24]))" 直接读出宽高，如果高度明显小于实际数据所对应的像素数，那基本可以确定被修改过。

第二个坑是不检查文件尾部。很多人看到一张图用看图软件能正常打开，就默认它是正常图片，完全不看文件尾部是否有多余数据。实际上在 CTF 里，图片尾部追加文本、追加压缩包是极其常见的操作。养成拿到文件就用 tail -c 200 图片文件 | xxd 看一眼尾部的习惯，能救回不少看似无解的题。

第三个坑是看到 Base64 就急着解码。Base64 在 CTF 中实在太常见了，它掩盖的内容可能是明文 flag，也可能是另一张图片、另一段二进制数据、一个压缩包，甚至是一段加密后的密文。解码之后要先把输出类型看清楚，是纯文本、可读字符串，还是乱码的二进制数据，再决定下一步怎么做。如果是二进制数据，考虑用 xxd 转回文件，再用 file 看类型，而不是盯着乱码发呆。

第四个坑是忽略 LSB 提取的通道和位序多样性。不同题目对 LSB 的使用方式千奇百怪：有的只使用一个通道，有的从第 1 位而不是第 0 位开始，有的按行反转的方式嵌入。所以做 LSB 题时要有意识地穷举通道、位平面和 bit order 的组合。Stegsolve 的 Preview 功能可以非常方便地让你快速预览几十种组合的结果，不要嫌麻烦。

最后补充一个经验性认知：CTF 隐写题本质上是在考你对"信息可以藏在哪里"的想象力。文件头、文件尾、元数据、像素通道、压缩流内部、甚至是文件名的 Unicode 编码，都有可能是藏身之处。当你熟练掌握上述工具链和排查顺序后，做题的路径会变得非常清晰——先扫描、再定位、后提取，每一步都有明确的依据，而不是靠瞎猜。这种"按流程走"的稳定输出能力，恰恰是 CTF 赛场上最稀缺的素质。