图片隐写里性价比最高的一类题，就是PNG宽高被人动过手脚的那一种。它不需要你懂密码学、不用爆破、不用啃算法，一张看起来干干净净的图，只要把文件头里某个四字节整数改回正常值，下半截被裁掉的隐藏文字就自己露出来了。这类题在CTF的misc方向出现频率极高，属于入门必刷、老手也常拿它当热身题的典型。我见过不少刚接触图片隐写的朋友，卡在这种题上不是因为不会改字节，而是压根没想到"这张图被截断过"这个方向。下面我按自己实际做题的顺序，把从判断题型、拆文件结构、定位字段、写脚本改值、修校验码到排查各种玄学现象的全过程完整写一遍，中间会给出可以直接抄的Python脚本和几条踩坑经验，照着走基本能独立复现。
1. 这类题到底在考什么
1.1 图片"看起来正常"才是最危险的信号
CTF的misc图片题，入口往往朴素得让人放松警惕：一张图，双击能打开，画质正常，没有花屏没有报错，肉眼扫过去就是一风景照或者一张截图。很多人的第一反应是丢进Stegsolve翻颜色通道、看LSB最低位、试盲水印，翻了一圈没收获就卡住了。这时候真正该怀疑的位置，其实是图片的元数据而不是像素——一张PNG如果被人用十六进制编辑器把高度字段改小，剩下的像素数据依然完整地躺在数据块里，只是解码器读到新的高度值就停止绘制了。你在屏幕上看到的那一截画面，本身完全正常，异常发生在它"没有被画出来"的那部分。
我最早接触这类题的时候，把图拖进好几个工具里轮着试，甚至怀疑过数据被加密了。后来顺手用命令行校验工具扫了一眼，输出里提示数据流的解压长度和文件头声明的高度对不上。这个"对不上"就是整道题唯一的破绽，也是所有后续操作的起点。所以判断题型的第一步不是动手改，而是先验证文件自洽不自洽——一张原生导出的PNG，它的压缩数据解压后长度应该刚好等于"高度 × 每行字节数"，只要这个等式不成立，八成就是宽高被动了。
1.2 被裁掉的那部分，其实一直在文件里
要理解为什么改高度能出字，得先接受一个前提：PNG的像素数据是按行组织、再整体做无损压缩的。宽度决定每一行有多长，高度决定一共画多少行，两者共同描述"这块画布多大"。而压缩后的数据流本身并不知道画布多大，它只是一段连续的字节。解码器的工作方式是：拿到宽度，算出每行字节数；拿到高度，决定循环读多少行；然后从数据流里一行一行往外取。
这里的关键在于，改小高度并不会删掉数据。原本一张高400像素的图，被人把高度改成200，文件体积几乎不变，因为压缩流一个字节都没动，变的只是文件头里那四个字节的整数。解码器老老实实读200行就收工，剩下200行的数据静静躺在文件末尾，谁也不去碰它。反过来，你把高度改回400，解码器继续往后读，被藏起来的下半部分就画出来了——很多时候那里写着一行字、一个flag格式的字符串，或者一个二维码的下半截。
这个机制的巧妙之处在于"隐藏"得非常自然：文件大小正常、能正常打开、不报错，普通的图片查看习惯完全发现不了。所以做这类题，养成一个习惯比什么技巧都重要——拿到PNG先看文件头声明的尺寸，再看压缩数据的实际容量，两者对不上就先怀疑裁剪。
1.3 这类题的典型外在特征
从经验上看，被裁剪过的PNG通常有几个可观察的线索。第一是文件体积与视觉尺寸不匹配：一张显示为800×200的图，文件却有几百KB，按常规压缩率算明显偏大，多出来的数据就有嫌疑。第二是画面内容"收得太突然"，比如一张图底部正好切在文字中间、切在人脸上、切在一个方框的边缘，这种构图在正常图片里很少见。第三是用十六进制编辑器打开时，末尾的数据块长度远超图像本身所需。
也有反过来的变体：出题人把高度改大，让画面下方多出一大片纯黑或者灰色区域，真正的隐藏内容被压在正常画面之上，需要你把高度改小才看得见。这两种方向的本质一样，都是让文件头声明的尺寸和真实数据不匹配，处理手法完全一致，只是改大改小的方向不同。做题时两个方向都试一遍，成本很低。
2. 把PNG拆开看：宽高到底存在哪几个字节
2.1 签名与数据块的通用骨架
PNG的文件结构非常规整，值得花几分钟记牢，因为后面所有操作都建立在这个结构上。文件最开头是固定的8字节签名，十六进制写作89 50 4E 47 0D 0A 1A 0A，其中50 4E 47正好是ASCII的"PNG"。这8字节的作用是让程序快速判断"这是不是PNG"，所有合法的PNG文件都必须以它开头，做文件头修复的题目也经常在这里动手脚。
签名之后是一个接一个的数据块，每个块的结构完全统一：先是4字节的长度字段（大端序，只统计数据部分的字节数，不含长度本身、类型和校验码），接着是4字节的块类型（ASCII字符，比如IHDR、IDAT、IEND、tEXt），然后是长度字段指定字节数的数据，最后是4字节的循环冗余校验码。整个块的开销固定是12字节加上数据长度。第一个块必须是IHDR，最后一个块必须是IEND，中间可以有任意多个其他块。
记住这个骨架的实际价值在于：你打开十六进制编辑器时，能立刻看出每个块的边界在哪，而不会对着满屏数字发懵。比如看到00 00 00 0D后面跟着49 48 44 52，就知道这是IHDR块，长度13字节，数据从第17个字节开始（偏移从0算），到第29字节结束，紧接着4字节校验码。这个定位能力比任何工具都可靠，因为工具可能装不上、可能版本不兼容，但结构是不会变的。
2.2 IHDR那13个字节各自管什么
IHDR是整张图的总说明书，数据部分固定13字节，字段顺序和含义如下表。这张表我建议直接记住偏移量，做题时能省掉大量翻文档的时间。
| 相对IHDR数据起点的偏移 | 长度 | 字段名 | 说明 |
|---|---|---|---|
| 0 | 4 | Width | 图像宽度，大端序无符号整数 |
| 4 | 4 | Height | 图像高度，大端序无符号整数 |
| 8 | 1 | Bit depth | 位深，常见1/2/4/8/16 |
| 9 | 1 | Color type | 颜色类型，0灰度、2真彩、3索引、4灰度加alpha、6真彩加alpha |
| 10 | 1 | Compression | 压缩方法，规范里只有0 |
| 11 | 1 | Filter | 滤波方法，规范里只有0 |
| 12 | 1 | Interlace | 隔行方式，0不隔行、1为Adam7 |
换算成文件的绝对偏移更好用：签名占0到7，IHDR块的长度字段在8到11，类型字段在12到15，所以数据从偏移16开始，宽度占16到19，高度占20到23，位深在24，颜色类型在25，压缩在26，滤波在27，隔行在28，校验码占29到32。整个IHDR块从偏移8到32，共25字节。
做题目时最常动的就是20到23这四个字节。这里有个必须刻进肌肉记忆的点：PNG所有多字节整数都是大端序，也就是高位在前。想把高度从80改成400，400的十六进制是00 00 01 90，就按这个顺序原样写进去，千万别写成90 01 00 00，写反了得到的会是一个荒谬的巨大值，某些查看器会直接崩掉或者卡死。
2.3 行结构：为什么"每行多一个字节"是解题命门
这一节是理解整类题的核心，也是最容易算错的地方。PNG在压缩之前，会把像素按行展开成一维字节流，而每一行的最前面要额外加一个字节，用来标记这一行用了哪种滤波方式（取值0到4）。这个字节不参与显示，纯粹是给解码器还原像素用的。所以每行实际占用的字节数是：
每行字节数 = 1 + 向上取整(宽度 × 位深 × 通道数 ÷ 8)
通道数由颜色类型决定：灰度是1，真彩是3，索引是1，灰度加alpha是2，真彩加alpha是4。举个常见的例子，一张真彩加alpha（颜色类型6）、位深8的图，宽度800，那么通道数是4，每像素4字节，每行就是800×4=3200字节，加上滤波字节共3201字节。如果高度是400，解压后的数据总长应该是 3201×400 = 1280400 字节。
这个公式有两个用处。一是验证：解压数据块后拿总长度除以每行字节数，得到的商就是这张图真实能画多少行。二是反推：如果算出来的行数明显大于文件头声明的高度，差额就是被裁掉的部分。理解了"每行多一个滤波字节"，你也就明白后面为什么强烈建议改高度而不是改宽度——宽度一变，每行的长度跟着变，所有行的滤波字节位置全部错位，画面会撕裂成斜条纹。
3. 实操：两种改法，从手工到脚本
3.1 开改之前先做三件确认
动手之前有三件事必须先确认，否则很容易白忙一场。第一，确认文件真的是PNG。不要相信文件后缀名，用命令行看一眼真实类型，输出里应该明确写着PNG image data 以及它的宽高和位深，这个输出本身就已经把文件头声明的尺寸告诉你了，很多时候一眼就能看出尺寸可疑。
file hidden.png第二，备份原文件。改字节是不可逆操作，尤其是手工改的时候手滑多改一位，整张图就废了，虽然理论上能重下，但比赛环境里往往没有第二次机会。养成cp hidden.png hidden.bak的习惯，成本几秒钟，能救命。
第三，先校验一遍再改。用命令行工具扫一下，看看有没有现成的报错。如果有校验和错误的提示，说明这道题可能不止改了宽高，还顺手把校验码破坏了；如果提示数据流长度异常，那就基本确认是裁剪题。这个前置检查能帮你判断后面需不需要额外修校验码。
pngcheck -v hidden.png3.2 用十六进制编辑器手工改一遍
手工改一遍的意义不在于效率，而在于让你对字节位置形成肌肉记忆，考试环境里没有脚本的时候不至于抓瞎。打开十六进制编辑器，按偏移20跳过去，你会看到四个字节，比如00 00 00 C8，这代表高度200。想改成400，就把这四位改成00 00 01 90，保存。
改完之后有两个选择：一是直接打开看效果，二是先把校验码修好。直接打开通常也能看，因为不少看图软件对校验码并不严格，但为了稳妥，建议顺手把校验码重算一遍。IHDR的校验码在偏移29到32，计算对象是"类型字段加数据字段"共17个字节，也就是偏移12到28的内容，算法是标准的CRC-32。
需要注意的是，别用文本编辑器改。十六进制字节流里存在大量不可打印字符和换行符，文本编辑器会自动做编码转换、补BOM、改行尾，一次保存就能把整个文件搞坏。必须用专门的十六进制工具，或者干脆用脚本以二进制模式读写。
另一个常见的手滑是改错了位置：把偏移16到19的宽度当成了高度，或者把长度字段的00 00 00 0D给改了。改长度字段的后果非常严重，解码器会按错误的长度去读数据，整个块边界全部错位，文件直接打不开。所以改之前先在纸上或者注释里写清楚"偏移20，4字节，高度"，改完再核对一遍。
3.3 脚本化改写并顺手修好校验码
实际做题我更推荐脚本，一次写好，之后遇到同类题直接改参数复用。下面这段用Python标准库就能跑，不需要装任何第三方包。它会解析所有块、打印出每个块的类型、长度、原始校验码和重算校验码，方便你一眼看出哪个块被动过。
import struct import zlib import sys def walk_chunks(path): with open(path, 'rb') as f: data = f.read() if data[:8] != b'\x89PNG\r\n\x1a\n': print('not a png') return off = 8 while off < len(data): length = struct.unpack('>I', data[off:off + 4])[0] ctype = data[off + 4:off + 8] body = data[off + 8:off + 8 + length] old_crc = struct.unpack('>I', data[off + 8 + length:off + 12 + length])[0] new_crc = zlib.crc32(ctype + body) & 0xffffffff flag = 'OK' if old_crc == new_crc else 'BAD' print(ctype.decode('latin1'), 'len=', length, 'crc=', hex(old_crc), flag) off += 12 + length if ctype == b'IEND': break if __name__ == '__main__': walk_chunks(sys.argv[1])改高度并重算校验码的脚本更短，核心就是改四个字节、重算一次CRC、写回四个字节。注意IHDR数据从偏移16开始，共13字节，类型字段在12到15，所以校验对象是data[12:29]。
import struct import zlib import sys def set_size(src, dst, width=None, height=None): with open(src, 'rb') as f: data = bytearray(f.read()) assert data[:8] == b'\x89PNG\r\n\x1a\n', 'not a png' assert data[12:16] == b'IHDR', 'first chunk is not IHDR' old_w, old_h = struct.unpack('>II', data[16:24]) new_w = old_w if width is None else width new_h = old_h if height is None else height data[16:20] = struct.pack('>I', new_w) data[20:24] = struct.pack('>I', new_h) crc = zlib.crc32(bytes(data[12:29])) & 0xffffffff data[29:33] = struct.pack('>I', crc) with open(dst, 'wb') as f: f.write(data) print('size: %dx%d -> %dx%d, new crc=%s' % (old_w, old_h, new_w, new_h, hex(crc))) if __name__ == '__main__': # 用法: python fix.py in.png out.png 400 set_size(sys.argv[1], sys.argv[2], height=int(sys.argv[3]))跑完之后直接打开输出文件。如果隐藏的字出现在下半部分，这道题就结束了。如果下面出现的是大片纯黑或者灰色，说明高度改得超过了数据支撑的范围，需要往下走一步，用数据长度反推真实高度。
4. 高度到底该改成多少：用数据流真实长度反推
4.1 先算清楚每行占多少字节
盲目试高度是最浪费时间的做法。与其从100试到10000，不如直接把每行字节数算出来，一步到位。计算公式前面提过，这里给出可直接运行的版本：从IHDR里读出宽度、位深、颜色类型，查表拿到通道数，然后套公式。
import struct CHANNELS = {0: 1, 2: 3, 3: 1, 4: 2, 6: 4} def row_bytes(width, bit_depth, color_type): ch = CHANNELS[color_type] return 1 + (width * bit_depth * ch + 7) // 8这里的向上取整用的是(a + 7) // 8这个整数技巧，避免浮点误差。为什么要小心？因为位深为1、2、4的图，一行不一定刚好占整数个字节。比如位深1、宽度13的灰度图，13位只占2个字节（补到16位），而不是1.625字节。如果这一步算错，后面反推出来的高度全会偏，你会在错误的方向上试很久。索引色图（颜色类型3）尤其容易被忽略，它每个像素只占1个索引值，位深通常是8或更低，算出每行很小，很容易算出个离谱的大高度。
4.2 解压数据流，数出真实行数
拿到每行字节数之后，把所有IDAT块的数据拼起来，用zlib解压，得到原始扫描线字节流，长度除以每行字节数就是真实行数。一段图可能被切成多个IDAT块，必须全部拼上，漏掉任何一个都会算少。
import struct import zlib import sys CHANNELS = {0: 1, 2: 3, 3: 1, 4: 2, 6: 4} def real_height(path): with open(path, 'rb') as f: data = f.read() off = 8 idat = b'' w = h = bd = ct = 0 while off < len(data): length = struct.unpack('>I', data[off:off + 4])[0] ctype = data[off + 4:off + 8] body = data[off + 8:off + 8 + length] if ctype == b'IHDR': w, h, bd, ct = struct.unpack('>IIBB', body[:10]) elif ctype == b'IDAT': idat += body elif ctype == b'IEND': break off += 12 + length raw = zlib.decompress(idat) rb = 1 + (w * bd * CHANNELS[ct] + 7) // 8 print('declared: %dx%d bit=%d color=%d' % (w, h, bd, ct)) print('raw bytes=%d row bytes=%d' % (len(raw), rb)) print('max rows=%d remainder=%d' % (len(raw) // rb, len(raw) % rb)) return len(raw) // rb if __name__ == '__main__': real_height(sys.argv[1])输出的三个数字信息量很大。max rows是这段数据最多能画出多少行，把它填回高度字段基本就是答案。remainder是除不尽的余数，正常情况下应该是0；如果不是0，说明每行字节数算错了，或者这张图的数据被改过不止一处，也可能是这张图用了隔行方式，需要另作处理。
这里还有个容易被忽略的细节：zlib解压本身可能失败。如果解压直接报错，说明数据流被破坏过，不是单纯的裁剪题，得换个方向排查，比如数据块被截断、被追加了额外字节、或者压缩流中间被塞了东西。解压失败和长度不匹配是两种完全不同的故障，处理路径也不同。
4.3 为什么优先改高度而不是宽度
很多人第一次做这类题，直觉是"宽度也可能被改了"，于是两个都试一遍。我的建议是先只改高度，宽度不要碰，原因在于行结构。前面说过每行开头有一个滤波字节，一行之内的像素还原依赖这个字节。宽度决定了每行多少像素、总共多少字节，一旦你改了宽度，解码器算出的每行长度就变了，它会把原本属于第二行的滤波字节当成像素数据，把原本的像素当成滤波字节，后面所有行全部错位累积。视觉上的结果就是画面被拉成斜向的条纹，颜色一块一块地斜着错开。
这种撕裂画面里，隐藏内容有时候还能勉强辨认，但更多时候完全糊掉，你会误判成"改错了方向"，继续瞎试。而改高度只影响"读多少行"，行的内部结构完全不变，只要不超出行数上限，每一行都能被正确还原，画面下部是干净的、完整的。这个差别在实际做题中非常关键，我见过太多人在宽度上反复折腾，其实只是把简单题做复杂了。
顺带说一个例外：如果这张图用的是Adam7隔行方式（IHDR第12字节为1），改高度的影响会被放大，因为隔行把图像拆成7个不同分辨率的通道，每个通道的行数都和总高度挂钩，改高度会导致各通道行数重新计算，画面错乱得更厉害。遇到隔行图，稳妥做法是先把那个字节改成0，让它变成不隔行，再调整高度。
5. 校验码修复与解码器兼容性
5.1 校验码算错会发生什么
PNG每个块后面那4字节CRC，计算对象是"块类型+块数据"，算法是标准CRC-32，初值和异或输出都是常规配置，Python的zlib直接提供。这个值的作用是让解码器判断数据有没有被破坏。改了宽高却不更新CRC，解码器一读就能发现"说明书"和"校验"对不上。
后果取决于你用哪个软件打开，差异非常大，这也是最容易让人误判的地方。严格遵循规范的库会直接拒绝解码，报一个校验失败的错误，表现就是图片完全打不开，或者只显示一个破图标。宽松的实现则干脆忽略CRC，照常渲染出完整画面，隐藏内容照样看得见。浏览器通常属于后者，所以很多人养成一个很实用的习惯：改完的图先拖进浏览器看，能出东西就先截图，再去修CRC。
所以CRC到底要不要修？我的做法是都修。修的成本很低，一个函数调用的事；不修的代价是你在不同环境里得到不一致的结果，排查起来极其费劲——在A软件里能看，在B软件里报错，你会怀疑是不是自己改错了字节，其实是软件严格程度不同。
5.2 验证与多解码器交叉确认
改完之后的验证环节，建议至少用两个不同来源的工具看一遍。一个用命令行工具校验结构是否合法，一个用图形界面看实际渲染效果。命令行工具输出干净（每个块都标OK）说明文件结构没问题；图形界面能看到隐藏内容说明改的方向对了。两边都过一遍，才算真的改对。
pngcheck -v fixed.png还有个小技巧：如果图形工具打开后显示的内容和预期不一致，换一个渲染引擎再看一次。同一个文件在不同解码器下可能表现出"截断""补灰""报错"三种完全不同的状态，多试两个能帮你快速区分"是我的文件坏了"还是"是这个软件太严格"。
另外提醒一句，某些系统的图片预览有缓存，改完同名文件后打开可能还是旧图。遇到"明明改了却毫无变化"的情况，先改个文件名再打开，能排除掉一大半假故障。
6. 常见问题与排查实录
6.1 现象、原因、处理速查表
下面这张表是我这些年攒下来的，基本覆盖了这类题九成以上的异常表现。遇到问题先对号入座，比盲目重试高效得多。
| 现象 | 最可能的原因 | 处理办法 |
|---|---|---|
| 校验工具提示IHDR校验失败 | 改了宽高没重算CRC | 用脚本重算并写回偏移29到32 |
| 图片打不开、显示损坏 | 误改了长度字段或块类型字段 | 换回备份，只改偏移20到23 |
| 能打开但下半部分全是黑 | 高度改得超过数据支撑范围 | 解压数据流算出真实行数再填 |
| 画面撕裂成斜条纹 | 改了宽度导致行对齐错位 | 宽度改回原值，只调高度 |
| 解压数据流直接报错 | 数据流被破坏或截断 | 换方向，查附加数据、查多块拼接 |
| 换软件才看得见 | 不同解码器对CRC容忍度不同 | 以能看见的为准，随后补修CRC |
| 改了完全没变化 | 图片预览缓存了旧文件 | 重命名后再打开 |
| 下方有内容但残缺 | 隔行方式导致通道行数错位 | 把隔行标志改成0重试 |
6.2 改完还是没看到字，往哪找
如果高度改对了、画面完整了，下半部分却是一片纯色什么都没有，那基本可以判定隐藏内容不在像素里。这时候要及时止损换方向，不要在宽高上继续耗。可以按这个顺序往下排查：先看文件末尾有没有在结束块之后追加数据，很多题会把flag直接贴在文件尾部；再看有没有文本类数据块，有些题把内容写进描述字段里；然后是像素级的最低有效位，这类需要工具辅助；最后才考虑压缩流里手工插入的额外数据。
反过来还有一种情况值得单独说：有些题把高度改小的同时，把多出来的数据并不是简单留着，而是重新压缩了一遍，导致解压长度刚好等于声明高度。这种题光靠长度对不上是发现不了的，得靠视觉线索——画面底部被切得太生硬、图像长宽比不符合常见拍摄比例、某些元素明显只露出了一半。遇到这种，直接把高度往上翻倍试一次，成本极低。
提示：改高度时不要一次加太多。某些解码器对超大尺寸会直接拒绝渲染，或者分配巨量内存导致卡死。建议先按一倍、两倍递增，每次都在备份上操作。
7. 同类变体与顺手扩展
7.1 JPG也存在同样的切入点
虽然这道题的主角是PNG，但同一思路在JPG上同样成立，值得一起记住。JPG没有CRC校验，它的尺寸信息存在帧起始段里，常见的是标记FF C0或FF C2，段内结构是：标记2字节、段长2字节、精度1字节、高度2字节、宽度2字节，然后才是分量信息。注意这里是2字节而非4字节，最大值只能到65535，改的时候别按4字节写。
改JPG高度的难点在于它的压缩方式。JPG不按行独立压缩，而是把整幅图切成8×8的块做变换，改高度后解码器会按新的块行数去解析，数据不够时通常在后半段填充灰色或者直接报错。所以JPG改尺寸的效果远不如PNG干净，经常只能露出部分内容。实践中的做法是把高度改大一点看能不能多解出几行，能看清就用，看不清再想别的办法。
7.2 把"对不上"当成一种通用检查手段
这类题给我的最大启发，是"文件声明的属性"和"文件实际的容量"之间应该存在严格对应关系，任何不匹配都是可疑点。这个思路可以迁移到很多地方：压缩包声明的文件列表和实际解压出的数量不一致、文档声明的页数和实际内容长度不一致、音频声明的时长和数据量不一致。养成"先算账、再验账"的习惯，比记住一百个工具快捷键有用得多。
具体到图片隐写，我现在的固定流程是：看真实文件类型、看声明尺寸、算每行字节、解压数据流、比对行数。这五步跑完，绝大多数裁剪类题目就现原形了，剩下的才是考虑别的隐写手段。流程化的好处是不依赖灵感和运气，即使换了出题人、换了文件格式，这套检查逻辑依然成立。
最后分享一个我自己的小习惯：每做完一道这类题，我会把改尺寸的脚本存一份，参数改成通用形式，文件名带上题目特征。两年下来攒了一个小脚本库，新题进来先跑一遍，能省掉大量重复劳动。这行的经验很多时候不是"知道更多原理"，而是"把验证过的东西留下来复用"。
