BugKuCTF：又一张图片，还单纯吗；猜

又一张图片，还单纯吗

思路一：

jpg改宽高，FFC0开头是固定的宽高所在段，进入winhex直接查找FF

很奇怪的是没有APP0段，即FF E0

0000-0001：FF D8（文件头）

0002-0013：APP0段（JFIF应用数据块）其中：
　　0002-0003：FF E0（段标记）
　　0004-0005：00 10（段长度＝16字节）
　　0006-000A：4A 46 49 46 00（“JFIF”的ASCII码）
　　000B-000C：01 01（主次版本号＝1.01）
　　000D     ：01（密度单位为 点数/英寸）
　　000E-0011：00 60 00 60（水平和垂直的密度均为每英寸96像素）
　　0012-0013：00 00（没有缩略图）

0014-0058：DQT段，其中：
　　0014-0015：FF DB（段标记）
　　0016-0017：00 43（段长度＝67字节）
　　0018     ：00（QT号＝0，QT精度＝8bit）
　　0019-0058：QT

0059-009D：DQT段，其中：
　　0059-005A：FF DB（段标记）
　　005B-005C：00 43（段长度＝67字节）
　　005D     ：01（QT号＝1，QT精度＝8bit）
　　005E-009D：QT

009E-00B0：SOF0段，其中：
　　009E-009F：FF C0（段标记）
　　00A0-00A1：00 11（段长度＝17字节）
　　00A2     ：08（样本精度＝8bit）
　　00A3-00A6：00 18 00 20（图像高＝24，图像宽＝32）
　　00A7     ：03（组件数量＝3，YCbCr彩色图）
　　00A8     ：01（ID号＝1，这是亮度Y组件）
　　00A9     ：22（化为二进制＝00100010，表明垂直和水平采样系数均＝2）
　　00AA     ：00（使用QT号＝0的量化表）
　　00AB     ：02（ID号＝2，这是色度Cb组件）
　　00AC     ：11（化为二进制＝00010001，表明垂直和水平采样系数均＝1）
　　00AD     ：01（使用QT号＝1的量化表）
　　00AE     ：03（ID号＝3，这是色度Cr组件）
　　00AF     ：11（化为二进制＝00010001，表明垂直和水平采样系数均＝1）
　　00B0     ：01（使用QT号＝1的量化表）

00B1-00D1：DHT段，其中：
　　00B1-00B2：FF C4（段标记）
　　00B3-00B4：00 1F（段长度＝31字节）
　　00B5     ：00（HT号＝0，DC表）
　　00B6-00C5：这16个数字之和＝12，说明下面的HT值表的长度＝12字节）
　　00C6-00D1：HT值表

00D2-0188：DHT段，这是HT号＝0的AC表，参照上面分析
0189-01A9：DHT段，这是HT号＝1的DC表，参照上面分析
01AA-0260：DHT段，这是HT号＝1的AC表，参照上面分析

0261-026E：SOS段，其中：
　　0261-0262：FF DA（段标记）
　　0263-0264：00 0C（段长度＝12字节）
　　0265     ：03（组件数量＝3）
　　0266-0267：01 00（组件ID＝1，Y组件，使用HT表号＝0的AC表）
　　0268-0269：02 11（组件ID＝2，Cb组件，使用HT表号＝1的DC表）
　　026A-026B：03 11（组件ID＝3，Cr组件，使用HT表号＝1的DC表）
　　026C-026E：00 3F 00（几乎每个JPG文件中这３个字节的值都相同，但用途不明）

026F-0282：图像压缩数据

0283-0284：FF D9（文件尾）

 没成功。

思路二

linux下binwalk 之后出现：

图片里面包着3个 图片：切出来

第一张（原图）：

图片内容为：

第二张，第三张操作差不多，但都是缩略图，看不清：

里面有一个rdf，什么鬼？

查了查好像是知识谱图，类似一种xml文件格式，也是用来存储信息的格式

从图片里面切出来之后用vim打开：

显示的是图片的一些格式信息。

猜

看到这个图片我就想到，图片缺了，要改高度才能完全看清脸

扔进winhex，如图，文件头结构（共13个字节，宽，高各4个，之后5个一字节）：

修改高度，不对：下面补全了，上面的头部没有显示出来。

换思路：百度识图，直接出现结果：仙女姐姐--刘亦菲                                        

知识点：

PNG定义了两种类型的数据块，一种是称为关键数据块(criticalchunk)，这是标准的数据块，另一种叫做辅助数据块(ancillarychunks)，这是可选的数据块。关键数据块定义了4个标准数据块，每个PNG文件都必须包含它们，PNG读写软件也都必须要支持这些数据块。

PNG格式关键结构：

http://dev.gameres.com/Program/Visual/Other/PNGFormat.htm

IHDR

文件头数据块IHDR(headerchunk)：它包含有PNG文件中存储的图像数据的基本信息，并要作为第一个数据块出现在PNG数据流中，而且一个PNG数据流中只能有一个文件头数据块。

文件头数据块由13字节组成，它的格式如下表所示。

由于我们研究的是手机上的PNG，因此，首先我们看看MIDP1.0对所使用PNG图片的要求吧：

• 在MIDP1.0中，我们只可以使用1.0版本的PNG图片。并且，所以的PNG关键数据块都有特别要求：
  IHDR
• 文件大小：MIDP支持任意大小的PNG图片，然而，实际上，如果一个图片过大，会由于内存耗尽而无法读取。
• 颜色类型：所有颜色类型都有被支持，虽然这些颜色的显示依赖于实际设备的显示能力。同时，MIDP也能支持alpha通道，但是，所有的alpha通道信息都会被忽略并且当作不透明的颜色对待。
• 色深：所有的色深都能被支持。
• 压缩方法：仅支持压缩方式0（deflate压缩方式），这和jar文件的压缩方式完全相同，所以，PNG图片数据的解压和jar文件的解压可以使用相同的代码。（其实这也就是为什么J2ME能很好的支持PNG图像的原因：））
• 滤波器方法：尽管在PNG的白皮书中仅定义了方法0，然而所有的5种方法都被支持！
• 隔行扫描：虽然MIDP支持0、1两种方式，然而，当使用隔行扫描时，MIDP却不会真正的使用隔行扫描方式来显示。
• PLTE chunk：支持
• IDAT chunk：图像信息必须使用5种过滤方式中的方式0 (None, Sub, Up,Average, Paeth)
• IEND chunk：当IEND数据块被找到时，这个PNG图像才认为是合法的PNG图像。

可选数据块：MIDP可以支持下列辅助数据块（可选，可空）

bKGD cHRM gAMA hIST iCCP iTXt pHYs

sBIT sPLT sRGB tEXt tIME tRNS zTXt

更多的信息参考http://www.w3.org/TR/REC-png.html

PLTE

调色板数据块PLTE(palette chunk)包含有与索引彩色图像(indexed-colorimage)相关的彩色变换数据，它仅与索引彩色图像有关，而且要放在图像数据块(imagedata chunk)之前。

PLTE数据块是定义图像的调色板信息，PLTE可以包含1~256个调色板信息，每一个调色板信息由3个字节组成：

因此，调色板的长度应该是3的倍数，否则，这将是一个非法的调色板。

对于索引图像，调色板信息是必须的，调色板的颜色索引从0开始编号，然后是1、2……，调色板的颜色数不能超过色深中规定的颜色数（如图像色深为4的时候，调色板中的颜色数不可以超过2^4=16），否则，这将导致PNG图像不合法。

真彩色图像和带α通道数据的真彩色图像也可以有调色板数据块，目的是便于非真彩色显示程序用它来量化图像数据，从而显示该图像。

IDAT

图像数据块IDAT(image datachunk)：它存储实际的数据，在数据流中可包含多个连续顺序的图像数据块。

IDAT存放着图像真正的数据信息，因此，如果能够了解IDAT的结构，我们就可以很方便的生成PNG图像。

IEND

图像结束数据IEND(image trailerchunk)：它用来标记PNG文件或者数据流已经结束，并且必须要放在文件的尾部。

如果我们仔细观察PNG文件，我们会发现，文件的结尾12个字符看起来总应该是这样的：

00 00 00 00 49 45 4E 44 AE 42 60 82

不难明白，由于数据块结构的定义，IEND数据块的长度总是0（00 00 0000，除非人为加入信息），数据标识总是IEND（4945 4E 44），因此，CRC码也总是AE 42 60 82。