简介面向信息隐藏与图像处理学习者代码包用C演示了BMP、JPEG、GIF三种图片格式中的信息隐藏与提取适合课程设计、毕业设计或安全竞赛备赛。资源共5个文件4个C源文件与1个头文件BMP通过文件头和数据区冗余写信息JPG修改DCT系数GIF利用扩展块与颜色表主程序统一调度压缩包仅5KB便于快速编译。已有6116人学习/下载适合作为隐写分析课程的实验参考。透过源码可掌握三类格式的具体编码手法并学习检查文件头异常、像素统计特性及尾部附加数据的分析方法为开发更隐蔽的算法或检测工具打下基础。 搞过逆向和数据取证练习的同学应该都有印象bmp、jpg、gif这三种图片格式在隐写Steganography里简直三种玩法。BMP适合从头到尾手写LSB隐写JPG一般得靠现成工具在DCT系数里动脑筋GIF则能在调色板、帧延迟、注释块里做文章。我去年复盘一个取证题目时把这三条路线完整走了一遍今天把实测过的流程、脚本和踩坑点整理出来。这篇不只讲原理还会给出能直接跑的Python代码和工具命令适合刚接触隐写、准备CTF比赛或者做图片取证分析的同学。1. 三种格式的底子差异决定了隐写思路能往哪走做图片隐写之前必须先搞清楚载体格式本身的编码逻辑。很多人一上来就拿着BMP的方法去处理JPG结果写完一保存隐藏内容全被压缩过程毁掉白忙一场。所以我先花点篇幅把三种格式的基础差异讲清楚后面再看具体手法就顺了。1.1 BMP无压缩像素直读LSB隐写的天然主场BMP存在的意义就是把像素数据原样存下来文件头之后直接跟BGR三通道像素没有压缩也没有质量损失。正因为不压缩每个像素值改一个两个bit不会影响文件结构人眼也根本看不出差别。LSBLeast Significant Bit最低有效位隐写的思路非常直白把一个字节的最低bit替换成要隐藏的二进制数据。原本像素值从255改成255没有变化从254改成255只差1肉眼完全分辨不出来。用一张1920x1080的真彩色BMP来算像素数据大约6.2MB按每像素3个通道、每通道藏1bit计算理论可藏容量约777KB能装下一部长一点的纯文本。这也是为什么很多隐写教学都喜欢从BMP起步——结构简单容量充足肉眼无感所有环节都能自己控制。BMP文件头里的2字节保留字段以及低位深场景下的调色板区域也可以藏短标识但最经典、最可控的还是像素LSB。1.2 JPG有损压缩之下像素域藏东西必翻车JPG是另一套逻辑。它在保存时会把图像切成8x8的小块做DCT离散余弦变换再根据量化表把高频系数清零最后做霍夫曼编码。这个流程是有损的所以直接在像素域改最低位一保存就可能被压缩过程抹掉等于白写。真正的JPG隐写得往DCT系数上动刀。常见思路是量化后的DCT系数统计规律比较稳定把非0非1的系数LSB替换成消息bit解码时按同样规则取出来。JSteg、F5这些老算法都是这个路数。但自己实现DCT系数层面的嵌入难度明显比BMP高要处理好量化表、熵编码的边界条件一个不留神就会让图片体积异常甚至直接打不开。所以实操里我更推荐用现成工具来做JPG隐写后面3.1会细说。1.3 GIF256色调色板与大把扩展块GIF最大只有256色图像数据存的是调色板索引而不是RGB颜色本身这些索引随后会用LZW算法压缩。问题就来了如果直接改压缩后的数据流LZW解压大概率出错图片直接损坏如果改像素索引又可能把索引指到另一个颜色导致画面出现明显色块。稳妥做法有两条。一条是修改调色板里RGB数值的最低bit位因为颜色最低位变化肉眼难辨而且不影响索引序列LZW压缩数据流完全不用动另一条是往GIF的扩展块里藏数据比如注释扩展块可以塞任意文本应用扩展块也能自定义内容。此外逐帧动画的帧延迟、透明色索引这些字段都可以作为隐蔽载体。2. 手写一套BMP的LSB隐写与提取脚本理论说再多不如直接跑一遍。下面以BMP为例用Python的PIL库写一套完整的LSB隐写和提取脚本。这套代码我在练习里反复用过可以直接抄作业。2.1 编码端把文本改写进像素的最低一位from PIL import Image def bmp_lsb_encode(image_path, message, output_path): img Image.open(image_path).convert(RGB) pixels list(img.getdata()) width, height img.size # 消息转字节结尾加3个0x00作为结束标志 data message.encode(utf-8) b\x00\x00\x00 bits .join(f{byte:08b} for byte in data) if len(bits) len(pixels) * 3: raise ValueError(图片容量不足换一张更大的图) idx 0 new_pixels [] for r, g, b in pixels: if idx len(bits): r (r 0xFE) | int(bits[idx]) idx 1 if idx len(bits): g (g 0xFE) | int(bits[idx]) idx 1 if idx len(bits): b (b 0xFE) | int(bits[idx]) idx 1 new_pixels.append((r, g, b)) out Image.new(RGB, (width, height)) out.putdata(new_pixels) out.save(output_path, BMP)关键点有三个。第一消息必须加结束标志否则提取时不知道哪里是终点。我用3个连续的0x00字节做分隔实际场景也可以自定义魔数比如bEOF但要注意这会在图中留下明显的统计特征。第二逐字节转8位二进制字符串时用的是高位在前的顺序提取端必须保持一致。第三r 0xFE的作用是先把最低位清零再或上目标bit。这样原值无论奇偶都能准确写入新bit。注意如果消息过长脚本会报错。容量上限是像素数 * 3 / 8字节这个公式在选图时就要心里有数。2.2 解码端按相同规则把bit捞回来from PIL import Image def bmp_lsb_decode(image_path): img Image.open(image_path).convert(RGB) pixels list(img.getdata()) bits [] for r, g, b in pixels: bits.append(r 1) bits.append(g 1) bits.append(b 1) # 每8位拼成一个字节 byte_list [] for i in range(0, len(bits) - 7, 8): byte 0 for j in range(8): byte (byte 1) | bits[i j] byte_list.append(byte) message_bytes bytes(byte_list) end message_bytes.find(b\x00\x00\x00) if end ! -1: return message_bytes[:end].decode(utf-8) return message_bytes.decode(utf-8, errorsignore)解码端的核心就是把每个像素RGB三个通道的最低bit全部取出来拼成字节流再找结束标志。这里最容易翻车的点有两个一个是位序方向如果编码端用byte 1解码端却从最低位开始取就全乱了另一个是字节流里可能包含大量无意义的0x00所以结束标志最好选3个以上连续0x00降低误判概率。2.3 写入前后图片差异与容量把控用一张普通照片跑完编码后肉眼看原图和隐写图几乎无法区分。但请记住肉眼无感不代表机器无感。用StagSolve之类的工具逐bit平面观察时最低位平面上如果出现明显成块、成串的规律而不是自然的噪点基本可以判定有人动过手脚。这也是检测LSB隐写的主要突破口之一。这里有个经验如果先把待隐藏内容用zlib压缩或者AES加密再写入像素最低位那么最低位平面的数据会变成近似随机噪声与自然图像的最低bit噪声特性更接近检测难度明显提高。同时压缩还能减少数据量相同容量下能塞进更多内容。我自己的习惯是隐写前先压缩再加密既省空间又能提升隐蔽性。3. JPG和GIF的进阶玩法与可行方案如果说BMP适合自己造轮子那JPG和GIF就是工具党、脚本党更实际的路线。下面这部分是实测过、能落地不翻车的方案。3.1 JPG用工具少踩坑steghide与outguessJPG场景下我常用的工具是steghide和outguess它们内部已经在DCT系数层面做好了嵌入不用自己啃DCT和熵编码的细节。# 嵌入cover.jpg是载体图secret.txt是要隐藏的文件 steghide embed -cf cover.jpg -sf secret.txt -p yourpassword # 提取从隐写图stego.jpg中提取 steghide extract -sf stego.jpg -p yourpassword # 查看图片内是否带有embed信息 steghide info stego.jpgoutguess的用法也类似# 把data.txt藏进cover.jpg生成stego.jpg outguess -k yourpassword -d data.txt -e cover.jpg stego.jpg # 提取 outguess -k yourpassword -r stego.jpg result.txt用这类工具时有几点心得。第一嵌入后图片体积会发生变化如果取证时发现一张JPG的文件大小和内容质量明显不匹配比如色彩简单的图却有5MB就该怀疑里面有隐藏数据。第二JPG隐写的检测难度比BMP高肉眼完全无感但可以通过DCT系数统计异常来发现常用工具是stegdetect它能报出疑似的隐写算法类型。第三如果提取时报密码错误先别慌有可能是嵌入时根本没设密码试试不加-p参数直接提取。3.2 GIF的调色板LSB与索引映射GIF不同于BMP不能简单地在像素数据区做LSB因为索引序列经过LZW压缩改一个bit可能让整个GIF解码失败。安全做法是修改调色板里每个颜色RGB值的最低bit索引序列保持不动。这样数据流完全不用重写同一索引对应的所有像素颜色只变化1肉眼看不出来。from PIL import Image def gif_palette_lsb_encode(gif_path, message, output_path): img Image.open(gif_path).convert(P) palette list(img.getpalette()) data message.encode(utf-8) b\x00\x00\x00 bits .join(f{byte:08b} for byte in data) if len(bits) len(palette): raise ValueError(调色板容量不足) idx 0 for i in range(len(palette)): if idx len(bits): palette[i] (palette[i] 0xFE) | int(bits[idx]) idx 1 img.putpalette(palette) img.save(output_path, GIF)提取时就是倒过来读取GIF的全局调色板把每一个RGB值的最低位取出来拼成字节。这个方法的容量上限是调色板颜色数 * 3 / 8字节。一个标准的256色调色板最多能藏96字节适合藏短消息、密钥或提示语不适合塞长文本。注意某些GIF是局部调色板模式每一帧或每一块都有自己的调色板PIL的getpalette()默认只返回全局调色板。处理动画GIF时要逐帧调用img.seek(frame_index)再去取否则会漏掉帧内隐藏的数据。3.3 扩展块与元数据最省事的GIF隐写还有一种非常省事的GIF隐写就是直接把数据写进GIF的注释扩展块。GIF文件流里0x21表示扩展块引入0xFE表示注释标签后面跟着数据子块每个子块以一个长度字节开头最大255最后以0x00结束。很多看图软件会忽略注释块但用十六进制查看器会一目了然。还有更隐蔽的玩法是修改帧延迟时间。GIF的图形控制扩展块里有2字节的延迟时间字段单位是百分之一秒取值的细微差异人眼也察觉不出来但能稳定编码少量信息。老牌的Ulead GIF Animator就能逐帧打开GIF并修改这些字段有兴趣可以拿来手动分析。网上一些“程序员修水管gif图”之类的搞笑动图经常被拿来当载体练习。拿到GIF动图切记不要只看第一帧用StegSolve的Frame Browser逐帧翻每一帧的注释块、帧延迟、局部调色板都可能藏着信息。4. 隐写检测与反检测的实用方法隐写有藏就有查。这一节专门讲检测思路从最笨的办法到标准工具按顺序来效率最高。4.1 先用笨办法strings、binwalk、十六进制拿到一张可疑图片我的习惯是先做静态检查。第一步看文件类型和大小是否匹配一张颜色平淡的图片却有几MB甚至几十MB立刻标记可疑。第二步跑字符串提取GIF注释块、BMP保留字段里塞的文字会直接暴露。# 提取可打印字符串 strings suspicious.gif | head -50 # 扫描是否嵌入了其他文件 binwalk -e suspicious.jpgbinwalk对嵌入ZIP、RAR这类独立文件的场景非常好用它会按特征把嵌套文件分离出来。但对纯LSB隐写基本无效因为像素数据不会形成独立文件特征这种情况要看bit平面。4.2 逐bit平面浏览StegSolve日常用法StegSolve是图片隐写分析绕不开的工具。打开图片后选择Analyse Data Extract把R、G、B三个通道的0号bit都勾上Bit Order选LSB First再点击Preview如果最低位平面里有文字或图像规律就能直接看到。这个操作很简单但有几个细节必须注意。第一位序选错会导出乱码MSB First和LSB First都试一遍再下结论。第二有些隐写只藏在某个通道里比如只在R通道的bit0这时候要单独勾选R通道去预览。第三提取出来的可能是图片而不是文本如果看到黑白噪点中隐约有图案轮廓要先截图保存再当成图像信息去处理。刚才说的GIF动图逐帧分析也在Analyse Frame Browser里操作。4.3 常见问题速查表现象可能原因解决办法提取出来乱码位序设置反了或编码不是UTF-8切换MSB/LSB First改用UTF-8解码BMP提取到一半数据错乱没有处理行对齐或结束标志缺失按4字节行对齐读取补全结束标志JPG隐写后文件打不开量化表被破坏或熵编码异常换新载体用steghide重新嵌入GIF隐写后动图变色明显改的是索引而不是调色板颜色值改为修改palette最低位不要改索引strings查不到任何线索数据被压缩或加密后再隐藏先考虑是否有密码验证zlib或AES特征拿到的是微信DAT而非标准图片文件被异或加密过用JPEG文件头FFD8FF等已知特征反推异或key还原后再分析微信DAT文件转JPG这一点经常被忽略。取证或练习时拿到的素材不总是标准格式比如微信缓存图片是DAT后缀其实是原始图片字节流做了逐字节异或。思路不复杂取DAT文件前若干字节和JPG/PNG/GIF的标准文件头做逐字节异或能推出同一个异或key再用这个key还原整个文件。还原后按正常图片分析即可。5. 实操总结与避坑清单最后把我自己踩过几次坑后总结的要点列出来直接背下来能少走很多弯路。5.1 我踩过几次坑后总结的要点先确认载体格式再选隐写方案这是最高优先级的一条。把JPG当BMP处理写进去的内容一保存就消失把GIF按BMP思路改像素LZW解压直接报错。每种格式的编码逻辑决定了它能用哪种手法不能混着来。位序要统一。不同工具和脚本对bit顺序没有硬性标准有的用MSB First有的用LSB First。写脚本时固定一种顺序在注释里标明提取时保持一致。我见过很多人在这一步翻车明明藏进去了提取出来全是乱码其实是取位方向反了。隐写前先压缩再加密。直接藏明文只要定位到位置就能读出来压缩后能显著降低最低位平面的规律性同时提升单张图的有效容量。练习时为了直观可以先藏明文但真要追求隐蔽性这个习惯要从一开始就养成。多帧GIF的坑要看清楚。PIL默认只读第一帧分析动画GIF必须手动img.seek(n)逐帧访问或者用StegSolve的Frame Browser逐帧看。有些考点的隐藏信息就藏在你最容易忽略的某一帧的注释块里。遇到大图先用zsteg扫一遍再手动分析。zsteg能自动检测PNG/BMP的LSB、调色板隐写等常见特征一键输出候选结果能省下大量手工预览bit平面的时间。5.2 这个方向还能怎么扩展这套思路不止用在图像上。音频WAV的样本点最低位、视频帧的冗余空间、PDF对象流里本质上都是同一套逻辑找冗余空间做最低位替换处理格式兼容风险。掌握了“载体结构分析 最低位替换 格式转换风险排查”这套方法论迁移成本很低。我自己在练习中最大的体会是图片隐写玩到后面拼的不是某个工具用得多熟而是对文件格式本身的理解有多深。BMP、JPG、GIF每种格式的编码方式决定了它适合用什么隐藏手法。先把底子摸清楚再去套工具和脚本逻辑会顺很多。本文还有配套的精品资源点击获取
