logo资料库

PNG图片详解与加密解密方法.doc

第1页 / 共4页
第2页 / 共4页
第3页 / 共4页
第4页 / 共4页
资料共4页,全文预览结束
PNG图片详解与加密解密方法
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 区块了,不过就算得到该区块的数 据,也应该是一张黑白图。
分享到:
收藏