bugkuCTF|杂项（又一张图片，还单纯吗）

2024-01-20 10:14:47

又一张图片，还单纯吗
思路一：
jpg改宽高，FFC0开头是固定的宽高所在段，进入winhex直接查找FF

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

 1 0000-0001：FF D8（文件头）
 2 
 3 0002-0013：APP0段（JFIF应用数据块）其中：
 4 　　0002-0003：FF E0（段标记）
 5 　　0004-0005：00 10（段长度＝16字节）
 6 　　0006-000A：4A 46 49 46 00（“JFIF”的ASCII码）
 7 　　000B-000C：01 01（主次版本号＝1.01）
 8 　　000D ：01（密度单位为 点数/英寸）
 9 　　000E-0011：00 60 00 60（水平和垂直的密度均为每英寸96像素）
10 　　0012-0013：00 00（没有缩略图）
11 
12 0014-0058：DQT段，其中：
13 　　0014-0015：FF DB（段标记）
14 　　0016-0017：00 43（段长度＝67字节）
15 　　0018 ：00（QT号＝0，QT精度＝8bit）
16 　　0019-0058：QT
17 
18 0059-009D：DQT段，其中：
19 　　0059-005A：FF DB（段标记）
20 　　005B-005C：00 43（段长度＝67字节）
21 　　005D ：01（QT号＝1，QT精度＝8bit）
22 　　005E-009D：QT
23 
24 009E-00B0：SOF0段，其中：
25 　　009E-009F：FF C0（段标记）
26 　　00A0-00A1：00 11（段长度＝17字节）
27 　　00A2 ：08（样本精度＝8bit）
28 　　00A3-00A6：00 18 00 20（图像高＝24，图像宽＝32）
29 　　00A7 ：03（组件数量＝3，YCbCr彩色图）
30 　　00A8 ：01（ID号＝1，这是亮度Y组件）
31 　　00A9 ：22（化为二进制＝00100010，表明垂直和水平采样系数均＝2）
32 　　00AA ：00（使用QT号＝0的量化表）
33 　　00AB ：02（ID号＝2，这是色度Cb组件）
34 　　00AC ：11（化为二进制＝00010001，表明垂直和水平采样系数均＝1）
35 　　00AD ：01（使用QT号＝1的量化表）
36 　　00AE ：03（ID号＝3，这是色度Cr组件）
37 　　00AF ：11（化为二进制＝00010001，表明垂直和水平采样系数均＝1）
38 　　00B0 ：01（使用QT号＝1的量化表）
39 
40 00B1-00D1：DHT段，其中：
41 　　00B1-00B2：FF C4（段标记）
42 　　00B3-00B4：00 1F（段长度＝31字节）
43 　　00B5 ：00（HT号＝0，DC表）
44 　　00B6-00C5：这16个数字之和＝12，说明下面的HT值表的长度＝12字节）
45 　　00C6-00D1：HT值表
46 
47 00D2-0188：DHT段，这是HT号＝0的AC表，参照上面分析
48 0189-01A9：DHT段，这是HT号＝1的DC表，参照上面分析
49 01AA-0260：DHT段，这是HT号＝1的AC表，参照上面分析
50 
51 0261-026E：SOS段，其中：
52 　　0261-0262：FF DA（段标记）
53 　　0263-0264：00 0C（段长度＝12字节）
54 　　0265 ：03（组件数量＝3）
55 　　0266-0267：01 00（组件ID＝1，Y组件，使用HT表号＝0的AC表）
56 　　0268-0269：02 11（组件ID＝2，Cb组件，使用HT表号＝1的DC表）
57 　　026A-026B：03 11（组件ID＝3，Cr组件，使用HT表号＝1的DC表）
58 　　026C-026E：00 3F 00（几乎每个JPG文件中这３个字节的值都相同，但用途不明）
59 
60 026F-0282：图像压缩数据
61 
62 0283-0284：FF D9（文件尾）

没成功。

思路二
linux下binwalk 之后出现：