**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.
![](https://github.com/EmpireCTF/empirectf/raw/master/writeups/2018-10-05-Hackover-CTF/files/i-am-many.png)
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:
![](https://github.com/EmpireCTF/empirectf/raw/master/writeups/2018-10-05-Hackover-CTF/files/i-am-many2.png)
`hackover18{different_Fl4g_for_3arly_ch33tahz}`