prog

frontpage - thread list - new thread - preferences - ?

What are you working on?

121 2020-07-06 14:16

An Anon posted a PNG image with a curious chunk.
https://dis.tinychan.net/read/prog/1593862693#reply_20
https://i.imgur.com/iQSyNAQ.png
The chunk structure is:

 0 0x00000008     13 b'IHDR' 0x8BC30833
 1 0x00000021      1 b'sRGB' 0xAECE1CE9
 2 0x0000002E     28 b'iDOT' 0x4DCC06DA
 3 0x00000056  16384 b'IDAT' 0x9078EF33
 4 0x00004062  16384 b'IDAT' 0xC442CD36
 5 0x0000806E  16384 b'IDAT' 0x3BD3D232
 6 0x0000C07A  10912 b'IDAT' 0x8CE51B02
 7 0x0000EB26  16384 b'IDAT' 0xA963DB86
 8 0x00012B32  16384 b'IDAT' 0xF1406B57
 9 0x00016B3E   6782 b'IDAT' 0x623FA54E
10 0x000185C8      0 b'IEND' 0xAE426082

Search engines can't seem to provide a spec for the iDOT chunk, even though it's marked ancillary, public, unsafe-to-copy by "3.3. Chunk naming conventions" of the PNG spec RFC2083.
https://tools.ietf.org/html/rfc2083
I could only find questions about "ImageIO: PNG invalid PNG file: iDOT doesn't point to valid IDAT chunk" and an old DoS attack with a crafted iDOT, but other Anons could easily have better search skills. So I took a look at the chunk myself.

00000000  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52  |.PNG........IHDR|
00000010  00 00 06 4c 00 00 04 de  08 06 00 00 00 8b c3 08  |...L............|
00000020  33 00 00 00 01 73 52 47  42 00 ae ce 1c e9 00 00  |3....sRGB.......|
00000030  00 1c 69 44 4f 54 00 00  00 02 00 00 00 00 00 00  |..iDOT..........|
00000040  02 6f 00 00 00 28 00 00  02 6f 00 00 02 6f 00 00  |.o...(...o...o..|
00000050  ea f8 4d cc 06 da 00 00  40 00 49 44 41 54 78 01  |..M.....@.IDATx.|
00000060  ec dd 07 9c 14 e5 f9 c0  f1 e7 1a e5 8e de 7b 53  |..............{S|

The 0x0000026f that keeps appearing is 623 and the image dimensions are 1612x1246, so that's half the height. The IDAT size stream can be seen to have a discontinuity at 10912 before returning to this encoder's preferred chunk size of 16384. The number of IDAT size runs is 2. The starting offsets of the run leaders are 0x00000056 and 0x0000EB26. The iDOT offset is 0x0000002E, and the remaining values from iDOT are 0x00000028 and 0x00eaf8. So the iDOT structure is clear:

# 4 + 12*k bytes
u32 number of IDAT runs (k)
# k run descriptors of 12 bytes each
k * (
  u32 starting row index of run
  u32 row count in run
  u32 run leader IDAT offset relative to iDOT offset
)

One caveat is that the run count can be obtained from the iDOT chunk size as (size - 4) div 12 after a 4 mod 12 check, so that initial 0x00000002 could possibly encode something else, but I am yet to see an iDOT that didn't start with 2 with a size of 28. With that said, I don't see how this structure could have been a mystery for several years, so I assume my search skills are just that poor. Also, if someone has access to a mac and is willing to experiment, we could see what other failures we could induce in the iDOT parser with crafted chunks, and whether they are simple error messages or crashes. The error messages would already be useful in labeling the various fields.

199