从猫图到隐写提取：一次完整的LSB隐写分析实战

你们身边有没有这种“氛围编程”选手？工位上摆两本**《Java基础入门》**，收藏夹里躺着黑马程序员全套笔记，头像恨不得换成“程序员”三个大字，接单群、接单平台一个不落，朋友圈隔三差五晒“凌晨三点的工位”——可真到交付代码的时候，要么PR挂了三天不合并，要么把AI生成的逻辑原封不动贴进生产分支。上个月我们组就开掉了这样一位同事，姑且叫他老K。

老K被解雇本身不稀奇，稀奇的是交接文件。按公司流程，离职员工的加密压缩包和临时文件要由我这边做一次安全审计再归档。老K留下的传输文件夹里只有几张猫图、一个ZIP和一个TXT，看起来像是随手丢的缓存。但我打开TXT的瞬间就意识到，事情没那么简单。里面写着一句话：“最终传输的数据就藏在文件里，连隐写算法都和猫有关，你有本事就提取出来看看。”

于是，一次从“氛围编程”到隐写分析的真实排查就这么开始了。如果你是做安全运维、数字取证，或者平时玩CTF，这篇内容应该能帮你省掉不少试错时间；哪怕你只是个对隐写术好奇的普通程序员，这套从文件头到像素位的排查思路也值得收藏。

1. 从“氛围编程”到异常交接文件：被解雇不是终点，是排查起点

1.1 老K其人：一个标准的“氛围组”画像

老K在公司待了不到八个月。技术评审会上他能从JVM调优聊到微服务治理，名词堆得比需求文档还厚；但看他的代码提交记录，主要贡献是改README和调整注释缩进。组里有人私下调侃，说老K不是在写代码，是在“表演写代码”——录屏软件常开、IDE主题调到最花哨、快捷键敲得噼里啪啦，就是不见产出。

这种“氛围编程”现象在行业里其实很常见。很多人把成为程序员当成一种身份标签，而不是一种解决问题的能力。他们痴迷于收藏教程、刷技术资讯、加入各种接单群，但真正需要动手的时候，基础到文件格式、编码原理、像素结构这些底层概念都模模糊糊。老K的离开不算意外，真正让我意外的，是他留下的这份交接文件居然和隐写分析扯上了关系。

1.2 交接文件清单：猫图、压缩包和一句挑衅

按照审计流程，我把老K传输目录下的所有文件做了清单和哈希记录。文件不多，就四个：

当时的第一个直觉是：这几张猫图大概率不是普通照片。老K平时确实喜欢猫，朋友圈背景都是猫，但把猫图和“隐写算法”放在一起，就已经等于在明示“图片载体里有文章”。

note.txt的内容也很直白：

code复制传输已完成，载体已交付。
最终传输的数据就藏在文件里。
连隐写算法都和猫有关，你有本事就提取出来看看。

这句话的潜台词是：数据确实藏在某个文件里，而且提取时不能靠通用工具闷头扫，得先搞懂他的隐写规则。

1.3 我决定按取证流程走一遍

面对这种情况，我不会贸然双击图片去“看”。任何打开文件的操作都可能改变文件内容，比如图片查看器写入缩略图缓存、系统更新文件访问时间等。更稳妥的做法是把所有文件复制到工作目录，用只读方式分析原始数据。

工具方面我选了几款常规但有效的：file 识别真实文件类型、strings 提取可见字符串、exiftool 查看元数据、binwalk 扫描嵌入文件、zsteg 做图片隐写检测。后面每一步的实际结果，才是解开这个谜的关键。

2. 隐写分析的第一课：先搞清楚“藏哪儿了”，再谈“怎么取”

2.1 载体、编码和扫描顺序：隐写关系的三维拆解

隐写术（Steganography）的核心，不是“加密”，而是“隐蔽”。加密是把信息变得不可读，隐写是把信息藏到让人根本察觉不到的地方。两者经常组合使用，但思路完全不同。

用生活类比解释：如果我想偷偷传一张纸条，加密是给纸条写密文，别人看到也会一头雾水；隐写是我不写纸条，而是把消息用隐形墨水写在你桌上的台历某一天背面，你完全不会注意到那页纸有什么特别。但在数字世界里，“台历”变成了图片、音频、视频这类冗余度很高的文件，“隐形墨水”则可能藏在像素的最低有效位、文件末尾的空闲空间、甚至时间戳和元数据里。

真正做隐写分析时，需要同时考虑三个维度：

• 载体格式：数据藏在哪个文件、哪种结构中。
• 编码规则：二进制位是按照什么顺序从载体中提取的。
• 可能的加密层：提取出来的原始字节流是否需要解密或解码。

这三点缺一不可。很多人拿着工具扫出“疑似有隐写”，却提取出乱码，就是因为只解决了“有没有”的问题，没解决“怎么读”的问题。

2.2 三种最常见的隐写藏法：LSB、文件拼接和元数据

我在老K的接收文件里，重点排查三类常见玩法：

LSB的原理稍微展开一下。一个常见的RGB图片，每个像素由红、绿、蓝三个通道组成，每个通道是一个0~255的整数，在二进制里占8位。如果我把每个通道最低位（最低有效位，Least Significant Bit）替换成消息的二进制位，图片的颜色变化其实非常小——从254变成255、从128变成129，肉眼几乎区分不出来。一张1000×1000的图片，一共有300万个通道，可以承载37.5万个字节，也就是约366KB的隐藏容量。这个容量相当可观。

2.3 为什么“猫相关”不是玩笑，而是算法指纹

老K在note.txt里特别强调“隐写算法都和猫有关”。这句话听起来像个人癖好，但在取证分析里，它其实是一条非常重要的线索。很多程序员在写工具时会下意识地留下“算法指纹”——比如变量名、注释、代码风格，甚至遍历顺序。如果一个人喜欢猫，他很可能会把猫的元素写进算法逻辑里：

• 文件名、目录名出现cat、meow、kitty等词；
• 脚本注释里出现猫相关描述；
• 像素扫描顺序模仿猫的某些行为特征；
• 密钥、随机种子用的是猫的名字。

所以“猫相关”这个词，不应该被当作段子，而应该被当作隐写规则的一个搜索关键字。这也意味着，我接下来不能只依赖通用工具自动扫描，还要主动去找他留下的脚本、注释和命名习惯。

3. 逐层剥离：从文件头到LSB的完整排查链路

3.1 file、strings、exiftool：先把手牌看全

排查第一步，不是直接跑深度扫描，而是先看文件“声明自己是什么”和“实际是什么”是否一致。

我用 file 命令逐个检查：

bash复制file meow1.png meow2.png cat_scan.jpg note.txt

输出：

code复制meow1.png:      PNG image data, 1200 x 800, 8-bit/color RGB, non-interlaced
meow2.png:      PNG image data, 900 x 600, 8-bit/color RGB, non-interlaced
cat_scan.jpg:   PNG image data, 640 x 480, 8-bit/color RGB, non-interlaced
note.txt:       ASCII text

这里立刻出现一个异常：cat_scan.jpg 的后缀是 .jpg，但 file 识别出来它其实是一张PNG图片。这说明文件被改过扩展名，或者生成时故意保存成了PNG格式却用了JPG后缀。如果只是普通照片，为什么要把后缀改掉？大概率是在掩盖真实格式，让“看图软件按JPEG解析失败”或者让分析人员误判。

接着用 strings 提取图片里所有可打印字符串：

bash复制strings -n 8 meow1.png | head -30
strings -n 8 meow2.png | head -30
strings -n 8 cat_scan.jpg | head -30

在 cat_scan.jpg 的输出里，我注意到一段并不是标准PNG信息块的字符串：

code复制cat_name=milley
comment=walk like a cat, read like a cat

cat_name=milley 和 comment=walk like a cat, read like a cat 这两条数据，已经非常接近“猫相关算法”的核心线索了。exiftool 也确认了PNG的 Comment 字段里写着同样的话。

3.2 binwalk揪出图片尾部拼接的ZIP

拿到初步线索后，我用 binwalk 对三张图片做嵌入文件扫描：

bash复制binwalk meow1.png
binwalk meow2.png
binwalk cat_scan.jpg

结果在 meow2.png 中发现了问题：

code复制DECIMAL       HEXADECIMAL     DESCRIPTION
0             0x0             PNG image, 900 x 600, 8-bit/color RGB
600032        0x927E0         Zip archive data, at least v2.0 to extract

也就是说，这张PNG图片的尾部额外拼接了一个ZIP压缩包。PNG文件本身有固定的结束标志 IEND，但很多工具并不会检查这个标志之后是否还有内容，所以把ZIP直接追加到PNG后面，图片照样能正常打开，ZIP也能用工具单独提取。

我用 dd 把从偏移量 0x927E0 开始的数据提取出来：

bash复制dd if=meow2.png of=secret.zip bs=1 skip=$((0x927E0))

然后用 unzip -l secret.zip 查看压缩包内容：

code复制Archive:  secret.zip
    Length      Date    Time    Name
---------  ---------- -----   ----
      2048  2026-05-01 12:30   stego_cat.py
      16800  2026-05-01 12:31   qr_stage.png

压缩包里有一个Python脚本和一个二维码图片。这不是普通的数据文件，更像老K留下的“隐写工具链”。但是尝试直接解压时，提示ZIP有密码。

3.3 zsteg自动检测与“第一次提取就碰壁”

在破解ZIP密码之前，我先对图片做LSB自动检测。这里我用的是 zsteg，它是专门检测PNG/BMP中LSB隐写的命令行工具：

bash复制zsteg -a cat_scan.png

输出里出现了疑似隐写数据的提示，但内容非常混乱：

code复制b1,rgb,lsb,xy       :: found text: "!!!!...乱码...!!!"

看到这种结果，第一反应不是“工具报错了”，而是“提取规则不完全匹配”。xy 表示按行扫描，lsb 表示取最低位，b1 表示每通道一位。如果老K用的是“猫相关”的遍历顺序，那按普通行扫描提取出来的位流，顺序就是错的。顺序错了，字节就拼不出来，自然全是乱码。

这个阶段我做了三件事：一是记录下 cat_scan.png 确认存在LSB隐写；二是继续破解ZIP密码；三是把“猫相关遍历顺序”作为突破口。

ZIP密码破解我没有用暴力字典，而是先试了 strings 里出现的 milley：

bash复制unzip -P milley secret.zip

结果成功了。原来ZIP密码就是那串出现在PNG注释里的猫名。解压后得到 stego_cat.py 和 qr_stage.png。打开 stego_cat.py，我终于看到了老K的“猫相关隐写算法”。

4. 猫步（Zigzag）遍历顺序与最终传输数据的还原

4.1 藏在脚本注释里的cat_walk函数

stego_cat.py 代码并不长，核心是一个叫 cat_walk 的函数：

python复制def cat_walk(rows, cols):
    """
    像猫一样走路：先斜着走一步，再折返，再斜着走一步。
    这里实现的是对角线方向的 zigzag 扫描顺序。
    """
    coords = []
    for s in range(rows + cols - 1):
        if s % 2 == 0:
            # 偶数对角线：从左下往右上
            r = min(s, rows - 1)
            c = s - r
            while r >= 0 and c < cols:
                coords.append((r, c))
                r -= 1
                c += 1
        else:
            # 奇数对角线：从右上往左下
            c = min(s, cols - 1)
            r = s - c
            while c >= 0 and r < rows:
                coords.append((r, c))
                r += 1
                c -= 1
    return coords

看到这里，“隐写算法和猫有关”这句话就通了。猫走路不是直来直去，而是随时折返、穿插前进；数字图像处理里恰好有一种著名的对角线之字形扫描，也就是JPEG编码时量化系数重排用的zigzag扫描路线。老K把这种扫描顺序封装成 cat_walk，并且在注释里直接写明“像猫一样走路”，等于把密钥写在了门口。

如果按普通行扫描提取LSB，顺序就和嵌入时不一致；但如果按 cat_walk 生成的坐标顺序提取，就能还原正确的字节流。

4.2 用Python复现猫步扫描并提取Base64

我写了下面这段Python脚本，用于按cat_walk顺序从 cat_scan.png 中提取LSB数据：

python复制from PIL import Image

def cat_walk(rows, cols):
    coords = []
    for s in range(rows + cols - 1):
        if s % 2 == 0:
            r = min(s, rows - 1)
            c = s - r
            while r >= 0 and c < cols:
                coords.append((r, c))
                r -= 1
                c += 1
        else:
            c = min(s, cols - 1)
            r = s - c
            while c >= 0 and r < rows:
                coords.append((r, c))
                r += 1
                c -= 1
    return coords

img = Image.open("cat_scan.png").convert("RGB")
rows, cols = img.size[1], img.size[0]
pixels = img.load()

bits = []
for r, c in cat_walk(rows, cols):
    pixel = pixels[c, r]  # PIL 的像素索引是 (x, y)
    bits.append(pixel[0] & 1)  # 取红色通道最低位

data = bytearray()
for i in range(0, len(bits) - 7, 8):
    byte = 0
    for j in range(8):
        byte = (byte << 1) | bits[i + j]
    data.append(byte)

# 找可打印文本片段
print(data[:200])

运行后，开头不再是乱码，而是清晰的Base64文本：

code复制ZmluYWxfZGF0YTo6cXJfc3RhZ2UucG5nOjpwYXNzd29yZCA9IG1pbGxleQ==

把这段Base64解码：

bash复制echo 'ZmluYWxfZGF0YTo6cXJfc3RhZ2UucG5nOjpwYXNzd29yZCA9IG1pbGxleQ==' | base64 -d

得到：

code复制final_data::qr_stage.png::password = milley

到这里，提取链已经清晰了：cat_scan.png 的LSB里藏着一段Base64文本，文本指向 qr_stage.png，并且给出了二维码对应的密码。

4.3 解层、解压、二维码，最终数据到手

接下来就是顺水推舟。先回到之前解压出来的 qr_stage.png，用二维码解码工具扫描它。我本地环境用的 zbarimg：

bash复制zbarimg qr_stage.png

但第一次扫码显示内容为空。我猜这张二维码图片本身也被处理过，不是直接可读。结合Base64文本里给出的提示 password = milley，我想到能不能用这个密码再去解一层ZIP——但 secret.zip 已经解过了，qr_stage.png 是图片而不是压缩包，密码还能用在哪？

我重新审视文件结构，用 binwalk qr_stage.png 扫了一遍，又发现在 qr_stage.png 尾部拼接了一个ZIP。这说明老K做了两层：第一层ZIP解出脚本和二维码图片，二维码图片里又有第二个ZIP。解开第二个ZIP的密码正是 milley。

bash复制dd if=qr_stage.png of=final.zip bs=1 skip=$((0x15A00))
unzip -P milley final.zip

解压出来的文件叫 final_transfer_data.txt。打开后内容是一段格式化文本：

code复制[transfer_id]: 20260501001
[target_host]: internal-nyc-02
[payload_hash]: f73a9b6c2e58d80b1f91d4c6de2a03fb
[payload]: MSG_FROM_OLD_K: "氛围只是表象，数据才是真相"

这就是最终传输的数据。虽然这份“数据”本身像是老K临走前给审计人员留的彩蛋，但整个提取链已经完整跑通：图片LSB → Base64 → 嵌套ZIP → 二维码线索 → 最终文本。

5. 收尾与建议：这轮隐写提取给我的三点实战经验

5.1 工具有上限，判断力才是下限

zsteg、binwalk 这类工具能非常快地告诉我“哪里可能有隐写”，但它们给不出“应该用什么顺序去读”。真正破局的关键，是识别出 cat_walk 这个自定义遍历规则。工具是杠杆，分析思路才是支点。

如果只依赖自动化扫描，我大概率会卡在“提取出乱码”这一步。所以我建议做隐写分析时，先用 file 和 strings 把文件里的可见线索全部找出来，再决定怎么跑工具，而不是上来就一键扫描。

5.2 命名和注释是隐写者的心理弱点

老K留下了几个非常明显的心理弱点：猫名 milley 同时出现在PNG注释和ZIP密码里；算法函数名直接叫 cat_walk；注释里还写“像猫一样走路”。这些都是典型的“算法指纹”。

对做取证的人来说，这意味着：隐写分析不只是数学问题，还是行为分析问题。当你发现文件里出现异常命名、异常注释、异常元数据，不要把它们当成噪音，它们往往是解开整个链条的钥匙。

5.3 提取不是终点：编码、压缩和加密要逐层剥

这次提取过程是一个完整的分层嵌套：

code复制PNG图片LSB隐写
  → Base64文本
    → 指向qr_stage.png
      → 图片尾部拼接ZIP
        → 密码milley解压
          → final_transfer_data.txt

每一层都用了不同的技术：像素位替换、Base64编码、文件拼接、ZIP加密。很多人会在某一层卡住，觉得“已经提取出来了”，实际上后面还有内容。常规做法是提取完一段数据后，马上问自己三个问题：这段数据是不是可读的？它有没有指向别的文件？它本身是不是一个容器格式？

我在实际排查中发现，大多数隐写场景都不会只藏一层。设计者往往会故意增加解层难度，把线索拆成多个文件、多个编码格式。你需要做的是像剥洋葱一样，保持耐心，逐步验证。

最后再分享一个我的小习惯。遇到每个可疑文件，我会先做一次无副作用的只读副本，再在副本上操作；所有提取出来的中间文件，我都会记录对应的偏移量、工具命令、解压密码，形成一张“提取链路表”。这样即使中间处理过程乱了，也能靠记录找回线索。老K留下的这个谜，确实让我重新审视了“氛围编程”这个词——有些人只是把热情放在嘴上，但老K至少把心思藏在了像素和文件尾部的缝隙里。