PNG 图片详解与加密解密方法
PNG 文件格式分为 PNG-24 和 PNG-8,其最大的区别是 PNG-24 是用 24 位来保存一个像素值,
是真彩色,而 PNG-8 是用 8 位索引值来在调色盘中索引一个颜色,因为一个索引值的最大上
限为 2 的 8 次方既 128,故调色盘中颜色数最多为 128 种,所以该文件格式又被叫做 PNG-8 128
仿色。PNG-24 因为其图片容量过大,而且在 Nokia 和 Moto 等某些机型上创建图片失败和显
示不正确等异常时有发生,有时还会严重拖慢显示速度,故并不常用,CoCoMo 认为这些异
常和平台底层的图像解压不无关系。不过该格式最大的优点是可以保存 Alpha 通道,同事也
曾有过利用该图片格式实现 Alpha 混合的先例,想来随着技术的发展,手机硬件平台的提
升,Alpha 混合一定会被广泛的应用,到那时该格式的最大优势才会真正发挥。
PNG-8 文件是目前广泛应用的 PNG 图像格式,其主要有六大块组成:
1.PNG 文件标志,
为固定的 64 个字节:0x89504e47 0x0d0a1a0a
2.文件头数据块 IHDR(header chunk) 3.
调色板数据块 PLTE(palette chunk) 4.sBIT,tRNS 块
等。。。 5.图像数据块 IDAT(image
data chunk) 6.图像结束数据 IEND(image trailer chunk),固定的 96 个字节:0x00000000
0x49454e44 0xae426082
这六大块按顺序排列,也就是说 IDAT 块永远是在 PLTE 块之后,
期间也会有许多其他的区块用来描述信息,例如图像的最后修改时间是多少,图像的创建者
是谁等…
数据块 1-4:
除了 PNG 文件标志,其中四大数据块和文件尾都是由统一的数据块文件结构描述的:
Chunk Length: 4byte
Chunk Type: 4byte
Chunk Data: Chunk Length 的长度
Chunk CRC: 4byte
例如 IHDR 块的数据长度为 13,即
Chunk Length = 13
Chunk Type ="IHDR"
IHDR 块:
用来描述图像的基本信息,其格式为:
图像宽: 4byte
图像高: 4byte
图像色深: 4byte
颜色类型: 1byte
压缩方法: 1byte
滤波方法: 1byte
扫描方法: 1byte
PLTE 块:
这个就是传说中放置调色盘数据的地方啦,其格式为:
循环
RED: 1byte
GREEN:1byte
BLUE: 1byte
END
循环长度嘛,不就是 Chunk Length / 3 的长度嘛,而且 Chunk Length 一定为 3 的倍数。
tRNS 块:
这个块时有时无,主要是看你是否使用了透明色。该区块的格式为:
循环
if(对应调色盘颜色非透明)
0xFF: 1byte
else
0x00: 1byte
END
循环长度为调色盘的颜色数,相当于调色盘颜色表的一个对应表,标识该颜色是否透明,0xFF
不透明,0x00 透明。故如果用 UltraEdit 查看 PNG 文件的二进制编码,如果看到一大片 FF,
一般就是 tRNS 区块啦,因为一个 PNG 文件一般只有一个透明色。
IDAT 块:
这个就是存放图像数据的地方啦,这里要注意的是一个 PNG 文件可能有多个 IDAT 区块,
而其他三大区块只可能有一个。
IDAT 区块是经过压缩的,所以数据不可读,压缩算法一般为 LZ77 滑动窗口算法,如果
硬要看里面的数据的话,用 zlib 库也可以看
IEND 块:
该区块虽然也按照数据块的结构,但 Chunk Data 是没有的,所以是固定的 96 个字节:
0x00000000
0x49454e44
0xae426082
IEND 数据块的长度总是 0(00 00 00 00,除非人为加入信息),数据标识总是 IEND(49 45
4E 44),因此,CRC 码也总是 AE 42 60 82。
PNG 图像压缩:
了解了 PNG 的文件结构,压缩就有的放矢了。压缩有 6 个级别,可以根据需要选择。
Level1:读取 PNG 文件,将除六大块之外的所有区块都过滤掉
Level2:文件头是固定的 0x89504e47 0x0d0a1a0a,文件尾是固定的 0x00000000 0x49454e44
0xae426082,去掉!
Level3:每个区块的 Chunk Type 我们是否需要呢?很明显,我们自己写的压缩格式自己应
该清楚是按照什么样的顺序,去掉!
Level4:每个区块的 Chunk Length 我们是否需要呢?
IHDR 块:定长 13 个字节,明显不需要,去掉。
PLTE 块:最多 128 个颜色,为撒要用 4byte 来记录区块长度而不是用 1byte 来记录颜色数
呢?
tRNS 块:既然有颜色数,tRNS 又是调色盘颜色表的对应表,既数量与颜色数相同,为什么
还需要呢?
IDAT 块:我想这个是唯一需要 4byte 来记录长度的区块。 Level5:每个区块的 Chunk CRC
是否需要呢?
因为计算 CRC 需要一些时间,但对于字节较少的区块一般可以忽略不计,所以对于这个问题
还是由程序员自己决定吧。对于 CRC 的计算可以参看 CoCoMo 的另一篇 Blog“PNG 文件的 CRC
码计算”
Level6:每个区块我们是否要原封不动的保存期数据呢?
IHDR 块:除了宽、高、色深是需要的,后面那 4byte 的信息是固定的 0x03000000 PLTE 块:
为撒要用 3byte 来表示 RGB 而不是 2byte 的 565 格式?压缩方法可以参看 CoCoMo 的另一篇
Blog“关于 PNG 图像压缩的一点感悟” tRNS 块:我想 tRNS 块是冗余最多的区块了吧,大
段大段的 0xFF 明显没有必要,一般的 PNG 文件只有一个透明色,为撒要用对应表的方法而
不是一个索引来记录到底哪个是透明色呢?由于颜色数最多 128,所以只需 1byte 就可以代
替 tRNS 那么多 0xFF 啦。
PNG 图像加解密:
很多人都担心自己辛苦创作的漂亮的美术图片很 easy 就被别人拿到了,究其原因是由于 PNG
文件格式是固定的,稍微了解的人用 UltraEdit 很容易就能找到 IHDR,PLTE 等标识了。CoCoMo
就经常看 GameLoft 的图像文件,一般是 2byte 的 Length,然后紧接着图片数据,都放在一
个文件里,直接拷贝 2 进制然后粘贴到一个新文件里就是一幅图。后来的加密技术会把 PNG
分块,例如前 100 个字节一块,紧接着 1K 一块,最后剩余字节一块,然后把块顺序打乱,
用 2byte 来记录总长度,1byte 记录顺序,但是这并没有从根本上消除 IHDR,IEND 这些显
眼的定位标识,好像在对破解者说:嘿,看,我就在这里!
现在了解了之前的压缩和解压技术,这个问题也就迎刃而解了,因为 Chunk Length,Chunk
Type 和 Chunk CRC 这些东西都消失了,甚至连数据块本身的数据都修改了,我可以按照
ImageWidth、ImageHeight、ImageDepth 的顺序写数据,也可以倒过来写。我想再牛的 PNG
分析器也是无能为力的吧,唯一可以定位的就只有 IDAT 区块了,不过就算得到该区块的数
据,也应该是一张黑白图。