CSAW CTF 2013 – Miscellaneous 200

This entry was posted on Sep 29 2013

For this challenge the first thing I did was as most would do, open the image in an image viewer program (specifically the Windows default image viewer, nothing fancy.) I didn’t see anything eye-catching, and when viewing the file in a hex editor I didn’t see anything immediately out of the ordinary either, there was nothing packed in with the PNG, it looked as a normal PNG would look, with lots of arbitrary junk data, and apparently indicating the image was taken from an IPhone 5. I didn’t realise how important this would be for me to notice at that point in time, but it definitely helped.

Next, I used a program that utilizes ‘libpng’, a very reputable and extensible PNG reference library that has existed and been tested for some years now, to analyze the more technical data for the PNG.

I got a notification that read something about the CRC in the IHDR chunk (the first few bytes of the PNG): “Incorrect crc for IHDR chunk (is c1d0b3e4, should be fcc410a8)”

I then tried changing this integer value with a hex editor at offset 0x1D to the following 4 bytes {0xFC 0xC4 0×10 0xA8}, and in doing so actually gave me more errors, including CRC errors for IDAT chunks, and there were a lot of them. Coincidentally, I decided to make sure that I was heading in the right direction and making sure that the CRC expected was actually the original, and perhaps it was changed deliberately for this challenge. So I checked the data that was currently there in the image header:

- 8 bits/sample (normal)
- truecolor+alpha
- non-interlaced

The one other thing that didn’t seem right, judging by the fact that the tEXt chunk points to an IPhone 5 running IOS 6.1.4, was that the image size was 3264×1681. This does not match any of the standard aspect ratios: 16:10, 16:9, 4:3 etc… And I also figured that editing this image in most image editors to crop it down to a portion of that full image would have possibly removed some of the remains of what the IPhone embedded within that image as a ‘mark’, upon resaving. (Everybody loves to advertise their copyright in there, you know how it goes.)

Through more research an IPhone 5′s camera roll aspect ratio is 4:3. The calculation gave me the idea that the image had somehow been chopped down height-wise.

3264*3/4 = 2448
2448 != 1681

Now, obviously there is no way to get that pixel data back once the image is chopped data-wise, so I tried changing the image size in the header from 3264×1681 to 3264×2448, and by opening the image again in some image viewer, voila! The key was written on the whiteboard the entire time. :)

Revisiting that hint they gave for this challenge part-way through my investigation also backed up this theory, but it wasn’t until I edited the header to match a 4:3 aspect ratio that it was apparent for what that down arrow really meant. All I knew was that this had nothing to do with width or anything horizontal.

There were exactly 2 bytes that needed changing in order to solve this challenge in the end, starting at offset 0×16, that indicate the height of the image. The values, originally, {0×06 0×91}, that needed to be changed to any sufficiently large value big enough to view that ‘hidden’ key on the whiteboard. I just matched it up to a 4:3 aspect ratio and changed those bytes to {0×09 0×90}.

Post a Comment