拿到一张看起来毫无破绽的 PNG扔进各种提取工具跑了十几分钟一无所获最后把它拖进 Stegsolve.jar按了几下键盘上的方向键flag 就明晃晃地躺在某个位平面里——这种经历在图片隐写方向待久了的人基本都遇到过。Stegsolve 就是这么一个有点年头、界面朴素、功能却极其对味的 Java 小工具它是图片隐写分析的常用工具核心能力是把像素级的位平面一块一块剥开给你看顺带把 LSB 数据提取、多帧浏览、图像合成这些操作收进一个窗口里。这篇内容面向刚接触图片隐写的新手也面向那些下载了 jar 包却卡在双击没反应或者Data Extract 提取出来全是乱码的同行。我不打算写成一份冷冰冰的功能说明书而是按实际分析的顺序把 Java 环境怎么配、每个视图背后在算什么、参数组合怎么枚举、哪些坑我亲手踩过一条一条讲清楚。1. 这个 jar 包在图片隐写链条里的真实位置1.1 它本质上是一台像素级放大镜加位运算器很多人对 Stegsolve 有个误解以为它是个一键出 flag的解题机装上就能自动扫出隐藏内容结果打开一看界面朴素得像个九十年代的看图软件顿时觉得上当。实际上它的定位完全不同它不做盲检测也不内置任何自动化解码逻辑它提供的是把图像数据摊开到比特级别的能力剩下的事情需要你自己判断。一张 PNG 图片在内存里展开后是一串按行排列的像素数组每个像素通常由 R、G、B、A 四个通道组成每个通道占 8 个比特取值范围 0 到 255。这 8 个比特从高位到低位代表的视觉重要性差别极大——把最低位第 0 位改掉颜色从 200 变成 201肉眼根本分辨不出来但把最高位第 7 位改掉颜色就从 200 变成 72画面会立刻发黑。Stegsolve 干的事情就是把这 8 个比特一层一层单独抽出来每一层还原成一张完整大小的黑白图像显示给你。如果某一层里藏着文字、二维码、图案轮廓你会立刻看到它从噪声里浮出来。这个思路在隐写分析里叫位平面分析是所有 LSB 类题目的第一道筛查工序。同时它还提供数据提取功能把多个通道的指定位按你指定的顺序拼成字节流导出成文本或二进制文件——这一步才是真正把隐藏内容取出来的动作。1.2 它擅长的和它压根不管的用熟了之后我对它的能力边界有个比较清晰的划分。它擅长处理的是无损格式的图像隐写特别是 PNG 和 BMP因为这两类格式的像素值就是文件里存的原值改哪一位就是哪一位不会在保存时被重新计算。它也适合处理调色板类图片PNG-8、多帧 GIF、以及需要两图对比的场景。它的 File Format 分析窗口能看到文件头、尺寸、位深、颜色类型、以及 PNG 的各种数据块对于判断一张图有没有被二次加工过很有帮助。它不管的事情同样要说清楚。第一它对 JPG 基本无能为力因为有损压缩会把 LSB 信息彻底抹平你在 JPG 上做位平面分析看到的永远是压缩噪声不是隐藏数据。第二它不做音频分析APE、WAV 里的隐写跟它无关。第三它不自动判断这张图里有没有藏东西它只是把可能性摆在台面上判断权在你手里。第四它不理解压缩包、不理解编码提取出来一串以PK开头的字节流还需要你自己去用别的手段展开。把这四条记牢你就能省下大量为什么我扫不出东西的困惑时间。1.3 为什么今天还值得装一个有朋友问我现在各种脚本、各种在线工具这么多为什么还要折腾一个老 jar 包。我的回答很直接可视化。命令行工具输出的是十六进制文本你需要在大脑里把它翻译成图像Stegsolve 直接把那张图给你看。当你左右按方向键看着第 0 位平面是纯噪声、第 1 位平面还是噪声、第 2 位平面突然浮现出一排淡淡的文字轮廓——那一瞬间你不需要任何推理答案自己跳出来了。这种所见即所得的反馈速度是任何脚本都给不了的。另外一个实际原因它是个单文件 jar绿色免安装拷到 U 盘里带到任何一台装了 Java 的机器上都能直接跑。在临时环境里做分析这一点非常关键。2. 让这个 jar 真正跑起来的关键细节2.1 Java 版本的选择比你想的重要Stegsolve 是用 Java 写的所以机器上必须有 Java 运行环境JRE。这一步听起来简单实际上新手卡在这里的比例相当高。先确认环境打开终端或命令行java -version如果提示不是内部或外部命令或者 command not found说明 Java 没装或者没进 PATH需要先补上。装完之后再执行一次能看到版本号输出才算过关。版本选择上我实测下来Java 8 是最稳的。这个工具的核心代码成型年代较早在 Java 8 环境下启动、渲染、读取各种图像格式的表现都最接近作者当年的预期。Java 11 和 Java 17 大多数情况下也能正常启动但有两个地方会跟你闹别扭一是高分屏缩放界面可能变得极小或者糊成一片二是某些图像格式的解码行为存在细微差异比如带透明度信息的 PNG 在合成预览时的底色处理。如果你手上有多个 Java 版本建议优先切到 8 来跑它。2.2 启动命令和那些必须知道的启动参数最标准的启动方式就是在 jar 所在目录下执行java -jar stegsolve.jarWindows 上如果双击没反应大概率是 jar 的文件关联被别的软件抢走了常见是各种压缩软件把 .jar 关联成了自己的解压目标这时候不要怀疑文件坏了直接用命令行启动。macOS 和 Linux 上同理双击通常不管用终端才是正途。界面缩放是个高频问题。在 4K 屏或者系统设置了 150% 缩放的机器上Stegsolve 的窗口可能小得像邮票按钮都点不准。解决办法是启动时锁死缩放比例java -Dsun.java2d.uiScale1 -jar stegsolve.jar反过来如果界面过大溢出屏幕把1换成0.8或1.5试。这个参数只影响 Java 的界面渲染不会改变图像本身的像素数据可以放心调。内存方面一般情况下默认堆大小够用但如果你要打开尺寸非常大的图比如上万像素的合成图可能会抛OutOfMemoryError。这时候加一个堆上限参数java -Xmx2g -jar stegsolve.jar2.3 从哪拿文件以及怎么确认拿到的文件是干净的jar 包本身是个 ZIP 容器来历不明的东西不要直接跑。建议只从项目的官方发布渠道获取避开各种绿色版加速下载站——这类站点重新打包后加料的情况并不罕见而这个工具的运行权限跟你自己的权限是一样的。拿到文件后可以先做个基本校验看看它是不是一个结构正常的 jarunzip -l stegsolve.jar | head -20正常的话会列出一堆.class文件和META-INF目录。如果列不出来、提示格式错误说明文件损坏或者根本不是 jar。再看看清单文件里声明的启动主类unzip -p stegsolve.jar META-INF/MANIFEST.MF能读到Main-Class那一行就基本可以确认结构完整了。想要更严谨一点比对一下官方公布的哈希值sha256sum stegsolve.jar2.4 常见启动故障对照表下面这张表是我和自己带过的同学一起攒出来的覆盖了九成以上的启动失败场景。现象大概率原因处理办法双击无任何反应.jar 文件关联被压缩软件占用改用java -jar命令行启动提示找不到主清单属性jar 结构损坏或被改包重新从官方渠道获取窗口弹出但空白显卡渲染兼容问题尝试加-Dsun.java2d.openglfalse界面字体极小/极大高分屏 DPI 缩放加-Dsun.java2d.uiScale1打开图片直接报错图片格式不被支持先用工具转换格式再打开终端里抛出堆内存异常图像尺寸过大加-Xmx2g提高上限Linux 下完全没窗口无图形界面环境需要带桌面环境的会话注意如果启动时终端里刷出一大段异常堆栈但窗口还是出来了先别急着关。多数异常发生在某个菜单项的初始化阶段不影响主图像浏览功能记下异常里的类名按功能逐个试往往能找到是哪块不可用。3. 主界面上的每一个视图在实际算什么3.1 底部状态栏被严重低估的信息源打开一张图之后先别急着按方向键把鼠标在图像上慢慢移动一遍看窗口底部。那里会实时显示当前鼠标位置的横纵坐标和该像素的 RGB 值。这个功能在分析特定位置的隐藏信息时非常有用比如你怀疑某一行像素被单独动过手脚把光标停上去看数值波动就能确认。有些版本还会在状态栏附近显示当前视图的名称比如Red plane 0、Green plane 3、XOR之类。养成先看状态栏、再解读图像的习惯能避免很多我明明看到了图案但说不清是在哪个位平面的返工。3.2 通道切换方向键扫过的二十多个视图分别是什么主窗口的左右方向键或者菜单里的上一视图/下一视图会循环切换分析视图。这个循环大概二十多项可以分成几类来理解单通道彩色平面只保留红、绿、蓝某一个通道其余通道置零。用来判断某个通道是不是整体偏色、有没有被塞入额外信息。单通道位平面把 R、G、B 各自拆成 0 到 7 共 8 个位平面。这是最核心的一组视图LSB 类题目九成在这 24 张图里有痕迹。灰度位平面先把像素转成灰度再拆成 8 个位平面。适用于灰度图和单通道思路。Alpha 通道视图单独显示透明度通道。有些题目会把数据藏在 Alpha 里因为肉眼完全看不见普通看图的软件也不会提示。颜色反转把每个像素取反。用来对付藏的内容是浅色文字、在白底上看不清的情况。XOR 视图把当前像素跟某个固定颜色做异或。当你怀疑整张图被异或掩码处理过时可以用。随机颜色映射按索引给不同灰度值分配高对比度颜色用于让微小的灰度差异变得肉眼可辨。实战中真正高频使用的其实就那几张R/G/B 的第 0、1、2 位平面加上 Alpha 视图。剩下的作为备用手段卡住的时候再回来扫一遍。3.3 位平面为什么能暴露隐藏数据讲透这一点后面所有操作你就都能自己想明白了。假设一张纯色背景的图所有像素的 R 通道都是 128二进制是10000000。现在有人在最低位里藏了一串比特改完之后像素值在 128 和 129 之间来回跳肉眼看起来毫无差别。但是在第 0 位平面这张视图里128 的最低位是 0黑129 的最低位是 1白于是整张图就变成了纯黑底上的白色图案——隐藏的数据自己显形了。同样的道理如果数据藏在第 1 位那就在第 1 位平面视图里会出现图案而第 0 位平面依然是噪声。这就是为什么分析时要逐位扫而不是只看第 0 位。我就遇到过把数据放在第 3 位的题目前三位都是干干净净的噪声很多人扫到第 1 位就放弃了。反过来判断也很重要如果某个位平面看起来是均匀的随机噪点没有结构、没有边缘、没有重复纹理那这一位里大概率没有东西。隐藏数据几乎总会在位平面上留下某种规律性——文字有笔画边缘二维码有方块结构图像有轮廓线。纯粹的高斯噪声说明这一位是随机填充或者被加密过了。3.4 Analyse 菜单下的五个工具各自解决什么问题File Format是最先该点的。它会解析出图片的容器格式、尺寸、位深、颜色类型对 PNG 还会列出所有数据块的类型、长度、偏移。这一步的价值在于你可以看出这张图有没有多出奇怪的数据块比如末尾挂着一个tEXt块里面塞了内容或者文件的实际长度超出图片数据应有的长度说明后面追加了东西。尺寸不匹配也是一个强信号——图片显示是 1024x768但文件头里写的是 2048x768那说明高度被改过图片底部有一段像素被裁掉了。Data Extract是核心中的核心下一节单独展开。Frame Browser专门对付多帧图像比如 GIF。它把所有帧平铺出来让你逐帧看很多 GIF 隐写题的关键就藏在某一帧的角落或者藏在相邻两帧的差异里。Steregram Solver和Image Combiner都是处理两张图关系的。前者对两张图做逐像素运算异或、加减、与或等后者把两张图按不同模式合成。经典用法是出题人给了两张看起来几乎一样的图把它们一异或差异区域就变成了明显的白色斑块隐藏内容往往就在那里。Palette用来查看调色板图片的颜色表。PNG-8 类型的图像素值存的是调色板索引而不是真实颜色如果索引被人按特定顺序排列过调色板列表本身就可能编码了信息。4. Data Extract 的参数空间与枚举策略4.1 界面上那几个控件到底在控制什么Data Extract 窗口的布局是左侧一堆复选框右侧是预览区和按钮。复选框按 R、G、B 三组排列每组 8 个对应 8 个位平面勾哪个就意味着把这个通道的这一位取出来。下面还有几个下拉框Bit orderMSB First 还是 LSB First。决定从取出的比特序列里拼字节时是先取高位还是先取低位。Bit plane orderRGB、RBG、GRB、GBR、BRG、BGR 六种排列。决定多个通道同时被勾选时比特的拼接顺序。Extract byRow 或 Column。决定是按行遍历像素还是按列遍历。Invert部分版本带把取出的比特取反。右侧的Preview按钮会按当前参数提取一段数据并显示成文本Save Text存成文本文件Save Bin存成二进制文件。4.2 默认组合为什么是 LSB MSB First RGB Row这个组合对应的是最常见的一种藏法用工具把一段文本的每个字节拆成 8 个比特按行优先、从左到右、从上到下的顺序依次写进每个像素 R、G、B 三个通道的最低位。读完一个像素的三个通道就是 3 个比特读三个像素凑齐 8 个比特就是一个字节。按这个规则反推提取时自然要用第 0 位、按 RGB 顺序、按行遍历、字节内部按高位在前。所以第一次提取就从这个组合开始命中率最高。但千万别把它当成唯一答案。我在实际中遇到过把数据只藏在 R 通道的、按 BGR 顺序排的、字节内低位在前的、按列写入的全都有。所以正确的心态是把参数当成一个有限的搜索空间按可能性从高到低依次枚举。4.3 参数枚举的推荐顺序下面这个顺序是我自己用的兼顾效率和覆盖面顺序Bit planesBit orderPlane orderExtract by适用场景1R0 G0 B0MSB FirstRGBRow最常见 LSB2R0 G0 B0LSB FirstRGBRow字节内位序反过来3R0 G0 B0MSB FirstBGRRow通道顺序反了4R0 G0 B0MSB FirstRGBColumn按列写入5R1 G1 B1MSB FirstRGBRow藏在次低位6R0 单独MSB First—Row只在红通道藏7R2 G2 B2MSB FirstRGBRow藏在第三位前四组能覆盖绝大多数题。如果四组都出来乱码再往第 5 组之后走。每换一组参数先点 Preview 看一眼开头几十个字符——如果开头就是一堆不可打印字符基本可以立刻换下一组不用浪费时间看完整结果。真正的数据开头往往有可识别的特征比如可读文本、PK、flag、http、{之类。4.4 提取结果怎么判断有没有价值提取出来的东西大概有几种形态各自的处理路径完全不同。第一种直接是可读文本。最理想的情况。但也别高兴太早文本末尾常常混着一堆不可见字符或者乱码真正的信息可能在中间某一段。建议存成文本文件后用编辑器打开打开显示不可见字符功能再读一遍有时候答案就藏在零宽字符或者退格符里。第二种以PK开头。这是 ZIP 压缩包的魔数。判断方法很简单把提取结果存成.bin文件然后用文件类型识别命令看一眼或者直接用file命令。确认是 ZIP 之后直接解压注意有些包是加密的密码可能就在图片的其他位置。第三种以\x89PNG开头。说明图里套了一张图改后缀就能打开。第四种一串 Base64 或者十六进制字符。拿去解码。注意 Base64 的字符集和长度特征如果长度不是 4 的倍数可能需要补等号或者中间有截断。第五种看起来像乱码但字符分布有规律。这种情况要么是参数选错了要么是数据本身被加密或者压缩过。先换参数换完还是这样就往加密方向想。4.5 一个容易忽略的细节预览不完整Data Extract 的预览窗口只显示前面一小段数据图的尺寸越大、勾选的位越多实际数据量就越惊人。很多人看到预览窗口显示的内容不完整就以为提取失败了其实完整数据都在只是没显示。正确做法是永远点 Save Text 或 Save Bin 把完整结果落盘再在本地文件里找。我早期就因为只看预览窗口漏掉过一次答案在文件的后半段白折腾了半小时。5. 从拿到一张图到取出内容完整分析链路5.1 第一步先别开 Stegsolve做外围体检很多人拿到图第一反应就是拖进 Stegsolve这个顺序其实可以优化。先做几步成本极低的外围检查往往能直接排除掉一大半方向。看文件大小和尺寸是否匹配。一张 1024x1024 的纯色 PNG 可能只有几 KB但如果大小莫名其妙到了几 MB说明里面塞了东西。反过来尺寸明明很大、文件却小得离谱说明图片被高度压缩过像素信息可能已经有损。用命令行看基础信息file target.png输出里如果写的是PNG image data, 1024 x 768, 8-bit/color RGBA, non-interlaced就拿到了尺寸、位深、色彩类型这三个关键参数。RGBA说明带 Alpha 通道后面要专门查interlaced说明是隔行扫描Stegsolve 打开时可能有渲染差异。再看文件末尾有没有追加数据tail -c 100 target.png | xxd正常 PNG 以IEND块结尾IEND后面跟着 4 个字节的 CRC 就结束了。如果IEND后面还有大段内容那基本可以确定是追加隐藏文件。5.2 第二步在 Stegsolve 里做位平面速扫打开图片从第 0 位平面开始用方向键逐张看。这一步要快每张图停留不超过三秒只看有没有结构。判断标准就一条这张图里有没有能被眼睛识别出形状的东西。我通常会重点关注几个位置图像的左上角和右下角藏数据常从开头或末尾写起、图像的中央区域如果藏的是二维码或文字、以及整张图是否存在统一方向的对角线或条纹纹理。扫的时候有个小技巧如果某个位平面几乎全黑或者几乎全白说明这一位取值高度集中可能是有意置位的结果值得多看两眼。正常的自然图像每一位的分布应该都接近五五开。5.3 第三步定位可疑视图后转数据提取一旦某张位平面图出现了文字或图案轮廓立刻回到 Data Extract用对应位平面的参数组合提取。比如图案出现在第 0 位、三个通道都有就用 R0 G0 B0 走一遍。这里有个经验看到图案不等于能直接提取出干净数据。有时候位平面上的图案本身就是最终答案比如它就是一行 flag 文字你直接截图读出来就行有时候图案只是提示告诉你数据藏在哪一位真正的数据还得靠提取。两种情况都要试。5.4 第四步交叉验证与二次处理提取出来的东西如果形态不明确就需要交叉验证。我常做的几步用xxd看二进制开头xxd -l 64 extracted.bin对照常见魔数表判断是什么格式。50 4B是 ZIP89 50 4E 47是 PNGFF D8 FF是 JPEG1F 8B是 GZIP42 4D是 BMP。用字符串扫描找可读内容strings -n 6 extracted.bin | head -40如果确认是压缩包直接解压如果是一段编码文本扔进解码工具里试常见编码如果是图片改后缀打开。5.5 一个完整的模拟案例假设拿到一张名为challenge.png的图尺寸 800x600文件大小 1.2 MB。file命令显示是 RGBA 8-bit。先做外围检查文件大小对于这个尺寸的 PNG 来说偏大正常应该在 300 KB 以内有塞东西的嫌疑。tail看末尾IEND后面干干净净说明不是尾部追加。进 Stegsolve 扫位平面。第 0 位全是噪声第 1 位也是噪声第 2 位的右上角出现一个模糊的方块状阴影。切到 Alpha 视图整张图是全白完全不透明排除 Alpha 藏数据。回到 Data Extract试默认组合 R0 G0 B0 MSB First RGB Row。Preview 显示开头是可读的英文句子但内容明显不是最终答案而是一句提示look at bit 2。换到 R2 G2 B2同样的顺序Save Bin 存下来用xxd一看开头是50 4B 03 04——是个 ZIP。改后缀解压里面是一个文本文件内容就是最终答案。这个流程里最关键的一步不是在哪个位平面找到了图像而是读懂了第 0 位提取出来的那句提示。很多题就是这么设计的低位埋一条线索指向真正的位置。所以提取出来的所有内容都要老老实实读别因为长得不像答案就丢掉。6. 和同类工具的分工别死磕一把锤子6.1 各家工具的能力对照工具主要能力适合场景短板Stegsolve位平面可视化、数据提取、图像运算肉眼筛查、LSB 提取无批量处理、无自动化判断zsteg自动枚举 LSB 组合PNG 的快速穷举只支持 PNG/BMP输出偏长binwalk文件内嵌结构识别找追加的文件、压缩包对像素级隐写无能为力pngcheckPNG 结构合法性校验判断文件头是否被改不做内容提取十六进制编辑器逐字节查看与修改修文件头、看数据块没有图像可视化通用解码平台编码转换、加解密提取结果二次处理不做图像分析这张表的意思是不要指望一个工具解决所有问题。我的习惯是先用 binwalk 和 pngcheck 做结构层面的判断结构没问题再进 Stegsolve 做像素层面的分析提取出来的结果交给解码工具处理。每一步用的工具都是最适合那一步的串联起来效率最高。6.2 什么时候该果断换工具有几个信号出现时继续在 Stegsolve 里磨是浪费时间第一所有位平面都是均匀噪声没有任何结构。这说明数据可能是加密的或者根本不是 LSB 类隐写需要往频域、调色板、文件结构方向想。第二所有参数组合都试过提取结果全是乱码且乱码的字符分布很均匀。这时候该考虑数据在提取之前被加密过或者你需要先做某种预处理比如取反、异或某个掩码。第三图片根本打不开提示格式错误。这已经不是隐写问题了是文件结构问题得先修文件头。这时候十六进制编辑器和结构校验工具才是主力。第四题目明确说是音频隐写或者文档隐写。那跟 Stegsolve 没关系趁早换方向。6.3 值得写进肌肉记忆的几条经验先看文件再看像素。结构层面的异常大小不符、尾部追加、数据块异常往往比像素层面的线索更直白而且检查成本低得多。位平面扫描要从 0 扫到 7。别默认数据一定在最低位。我见过藏在第 4 位的题扫到第 2 位就放弃的人不少。每次提取都落盘。预览窗口会骗人完整数据只在文件里。提取结果无论多离谱都要读一遍。提示、坐标、下一层的入口经常就藏在你以为的乱码里。记录下来。试过哪些参数组合、结果是什么样简单记个表避免来回重复劳动。题目稍微复杂一点参数组合就有几十种靠脑子记必乱。7. 那些年踩过的坑和对应的排查动作7.1 用 JPG 做位平面分析从第一步就错了这是新手最常见的失误也是我早期犯过的。拿到一张.jpg兴冲冲拖进 Stegsolve 扫位平面发现每一层都像电视雪花扫了二十遍什么也没有然后开始怀疑工具坏了。问题出在格式本身。JPG 用的是有损压缩编码时会做离散余弦变换和量化解码回来的像素值跟原始像素值存在误差最低几位完全不可控。就算出题人真的在 JPG 里写了 LSB 数据经过一次保存-读取的循环那些数据也已经被破坏得七零八落。排查动作先看图片的扩展名和file命令输出确认是无损格式。如果是 JPG直接放弃 LSB 方向转去看 EXIF 信息、文件尾部追加、或者图像内容本身。真要验证可以试试把 JPG 另存为 PNG 再扫一遍——如果扫出来的东西跟之前不一样说明之前的都是压缩噪声。7.2 图片宽高被改过Stegsolve 直接打不开有些题目会把 PNG 文件头里记录的高度改小这样图片底部的一段像素就被裁掉了但数据其实还在文件里。这种图在 Stegsolve 里打开会报错或者显示异常。排查动作用结构校验工具检查文件头。PNG 的 IHDR 块里存着宽和高如果高度被改过数据块的长度和实际像素数据量会对不上校验就会报错。确认之后用十六进制编辑器把高度改回去记得同时修正 CRC图片底部被隐藏的部分就露出来了。这个操作有一定门槛改之前务必备份原文件。7.3 提取出来一串看着像答案的字符但是解不开排查动作先确认字符集。如果提取结果里混着大量非 ASCII 字符说明参数选错了换组合重试。如果全是可打印的 Base64 字符但解出来是乱码可能是被压缩过先做一次解压再解码。如果字符之间有明显规律的分隔比如固定间隔出现特殊符号那可能是每个字符的最高位被污染了试试对每个字节做 0x7F处理。还有个隐蔽情况提取结果里混入了零宽字符。这类字符在编辑器里完全看不见但确实占据字节。把提取的文本复制到能显示不可见字符的工具里一眼就能发现。7.4 Data Extract 预览有内容保存下来却是空的这个坑我踩过一次折腾了很久。原因通常是预览是按当前参数实时生成的但保存按钮的行为依赖窗口状态如果提取过程中切换过参数但没重新点 Preview保存的可能是一次空结果。排查动作每次改完参数先点一次 Preview 确认有内容再点 Save。保存后立刻去看文件大小0 字节就是没成功别等后面分析半天才发现源头是空的。7.5 Alpha 通道藏数据肉眼和普通工具都发现不了带 Alpha 通道的 PNG透明度信息存在第四个通道里。绝大多数看图软件不会显示这个通道把它当噪音忽略掉。但隐写完全可以只用 Alpha 通道的最低位来藏数据。排查动作在 Stegsolve 里专门切到 Alpha 相关视图看一遍。如果整张图是全白完全不透明或者全黑说明没有利用 Alpha 藏东西如果 Alpha 视图里有结构立刻针对 Alpha 通道做数据提取。7.6 多帧 GIF 只看第一帧漏掉全部信息GIF 是多帧格式默认打开只显示第一帧。有些题把关键内容放在第 30 帧、第 100 帧你盯着第一帧看一辈子也找不到。排查动作用 Frame Browser 把所有帧拉一遍看有没有画面突变、有没有某一帧里出现了文字、有没有两帧之间做差分后出现图案。也可以用工具把 GIF 拆成一堆独立的帧文件再做批量分析。7.7 单看一张图没结果其实要两张图一起看有些题给了两张图大部分人只分析其中一张另一张当成干扰项扔在一边。实际上两张图的关系才是关键——它们可能是同一张图的不同通道拆分也可能其中一张是掩码。排查动作用 Steregram Solver 或 Image Combiner 把两张图做逐像素运算重点看异或结果和差值结果。如果运算后出现明显的白色区域或者清晰的图案说明找对方向了。同时确认两张图的尺寸是否一致不一致的话需要先裁剪或缩放对齐。7.8 参数组合穷举太慢用脚本辅助Stegsolve 的图形界面适合交互式探索但如果你已经确定了大概的位平面范围只是要吃遍所有通道顺序和位序组合手工点几十次效率太低。这种情况下我会转用命令行工具做批量枚举把候选结果全部导出再用脚本统一扫描里面有没有可识别特征。Stegsolve 的定位始终是看的工具不是跑批的工具把这两类工作分开整体效率会高得多。最后分享一个我自己用着很顺的小习惯分析任何一张图之前先复制一份原始文件到独立的目录里所有操作都在副本上做。图片隐写分析过程中经常需要改文件头、改扩展名、反复保存提取结果一旦在原文件上动了手后面想回头验证都没机会。这个习惯看起来笨但救过我至少三次。