I have answers to the inner workings of TIFF and other junk
i have seen alot of questions regrading the new found TIFF exploit, and alot of idiots asking for source code for it. anywho, i thought i would dissect the hw.tiff for you all to attempt to explain what it is doing. now i do not know mips assembly so i wont be able to explicitly say what instructions are being executed but i believe it will be insightful for some nonetheless.
here we go:
this is the TIFF header in the hw.tiff file. tiff headers are 8 bytes long
49 49 2A 00 1C 27 00 00 -end of tiff header- FF FF FF FF <--- after the header the tiff is filled filled 270F bytes of 1's (presumably for padding or a buffer for later, i'll talk about that later). Here is the ascii representation of the above header and padding II . the II means the file is encoded using little endian byte ordering. (im on a powerPC (big endian) so forgive any mistakes in my interpretations in case i forget that i have to flip my bytes). I don't know what the next 2 bytes represent but they have the same value in all tiffs i looked at, perhapps they simply id the file as a tiff.
The remaining 4 bytes of the header is an offset from the first byte of the header to the first byte of the first Image File Directory in this case the offset is byte 271C. The FF padding/relevance-yet-to-be-determined-by-me continues to offset 2717 (hex) that is 5 bytes before the IFD.
IFDs are 18 bytes min, 2 bytes for the number of entries, 12 for each entry and a 4 byte trailer for the offset of the next IFD if there is one.
image file directory for hw.tiff. (102 bytes or 2 bytes + 8 entries of 12 bytes + 4 byte trailer)
coments are inserted directly into the hex
0800 <- number of entries in ifd 0001 0300 0100 0000 0800 0000 <-width 0101 0300 0100 0000 0800 0000 <- height 0301 0300 0100 0000 0100 0000 <- compression 0601 0300 0100
0000 0100 0000 <- photometric interpretation 1101 0400 0100 0000 0800 0000 <- strip offsets 1701 0400
0100 0000 1427 0000 <- strip byte count 1C01 0300 0100 0000 0100 0000 <- planar config (1= single image plane) 5001
0300 0080 0000 8227 0000 <- ? end of entries. (0 = no more ifds) -> 0000 0000
*EDIT* yes i did it i forgot i am looking at this in big endian but im too lazy to change it so if anything seems backward simply reverse it ;-)
interesting to note here that the next several bytes following the ifd read ms0:/l.bin ;-) mean anything to anyone? thought so.
1st 2 bytes are tag type -> 00 01 i dont know the diffrent tag types but trust me that this represents width of the image
next 2 are field type -> 03 00 -> once again dont ask cuz its beyond the scope of what im trying to get across but this means it is of type short int
nex 4 are the # of values -> 01 00 00 00, so we have one value
the next 4 represent either an offset to the value itself or the actual value.
-> 08 00 00 00, this is the actual value of 8.
so in sumary all that means is our image is 8 pixels wide ;-)
decoding the rest is up to you but their meaning is commented into the above hex for you.
i will pick up the rest of this during the weekend. bed time for me now. but eventually i will finish explaining how the exploit works unless nobdy expresses an interest by the time i come back tomorrow or saturday