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