**No description**

**Files provided**

- [`hackover.png`](https://github.com/EmpireCTF/empirectf/blob/master/writeups/2018-10-05-Hackover-CTF/files/i-am-many.png)

**Solution**

We can open the PNG and check for LSB-hidden text, partial transparency, etc, but it seems innocent enough.


Looking through the file in a Hex Editor, we can see the individual chunks making up the file. There is a `sBIT` chunk, but it seems to have no effect, since it specifies 8 significant bits for each channel anyway, i.e. no different from what the data holds.

Thinking about the title, we can notice *many* `IDAT` chunks, although this is quite normal, since it allows PNGs to be loaded and decoded progressively. The first unusual thing I noticed was that the sizes of the `IDAT` chunks were weird - the first one was 4590 bytes, the next couple 8192 bytes. Usually if a file is encoded with a regular PNG encoder, the chunks all have the same size except for the last one. Then I realised why - all the chunks except for the first actually belonged to a different PNG file.

$ xxd hackover.png | tail -n +289 | head -n 5
0001200: 9cc4 60a6 a929 171a af7c 7f3c 073c 073c ..`..)...|.<.<.<
0001210: 073c 073c 073c 073c 073c 073c 074a 0507 .<.<.<.<.<.<.J..
0001220: fe07 f64e 9dc0 9c82 68bd 0000 0000 4945 ...N....h.....IE
0001230: 4e44 ae42 6082 8950 4e47 0d0a 1a0a 0000 ND.B`..PNG......
0001240: 000d 4948 4452 0000 0320 0000 004c 0806 ..IHDR... ...L..

So extracting everything from offset `4662` onwards into a separate file:

$ dd if=hackover.png of=flag.png bs=1 skip=4662

We get the flag:


`hackover18{different_Fl4g_for_3arly_ch33tahz}`

Original writeup (https://github.com/EmpireCTF/empirectf/blob/master/writeups/2018-10-05-Hackover-CTF/README.md#100-forensics--i-am-many).