[Link to original writeup](https://wrecktheline.com/writeups/imaginary-2021/#Chimaera_Forensics)
# Chimaera (8 solves, 300 points)by adragos
We are given a PDF file named chimaera.pdf, when we open it in a normal PDF viewer we only get a red flag.
Trying the file command on the file shows us that:
```$ file chimaera.pdfchimaera.pdf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped```
So the file is a ELF 64-bit binary, let's try to run it:
```$ ./chimaera.pdfictf{thr33_```
Looks like we got the first part of the flag
Next, we can use pdf2txt to find out if there are any characters hidden inside the pdf:
```$ pdf2txt chimaera.pdfjctf{red_flags_are_fake_flags}
h34ds_l
```
And it looks like we got the 2nd part of the flag, we now have `ictf{thr33_h34ds_l}`
Running binwalk on the file:
```$ binwalk chimaera.pdf
DECIMAL       HEXADECIMAL     DESCRIPTION--------------------------------------------------------------------------------0             0x0             ELF, 64-bit LSB executable, AMD x86-64, version 1 (SYSV)600           0x258           Zip archive data, at least v1.0 to extract, compressed size: 5139, uncompressed size: 5139, name: chimaera.pdf
```
So there's a zip file, if we unzip it with 7-zip we get only a pdf file and a fake flag.
Let's look closely:
```00001490: 5f66 6c61 6773 7d50 4b03 040a 0000 000d  _flags}PK.......000014a0: 0000 0000 000d c613 9321 0000 000d 0000  .........!......000014b0: 0000 0000 0009 0405 005d 0000 8000 0018  .........]......000014c0: 9ac2 6601 8f45 607e c89c e051 6589 87dc  ..f..E`~...Qe...000014d0: ffff 072c 0000 504b 0102 0a00 0000 0000  ...,..PK........```
Seems like there is another piece of data which appears to be corrupted, let's isolate it
```00000000: 504b 0304 0a00 0000 0d00 0000 0000 0dc6  PK..............00000010: 1393 2100 0000 0d00 0000 0000 0000 0904  ..!.............00000020: 0500 5d00 0080 0000 189a c266 018f 4560  ..]........f..E`00000030: 7ec8 9ce0 5165 8987 dcff ff07 2c00 00    ~...Qe......,..```
Notice that the compression method is 0x0d = 13, which per this table:
```   4.4.5 compression method: (2 bytes)
        0 - The file is stored (no compression)        1 - The file is Shrunk        2 - The file is Reduced with compression factor 1        3 - The file is Reduced with compression factor 2        4 - The file is Reduced with compression factor 3        5 - The file is Reduced with compression factor 4        6 - The file is Imploded        7 - Reserved for Tokenizing compression algorithm        8 - The file is Deflated        9 - Enhanced Deflating using Deflate64(tm)       10 - PKWARE Data Compression Library Imploding (old IBM TERSE)       11 - Reserved by PKWARE       12 - File is compressed using BZIP2 algorithm       13 - Reserved by PKWARE       14 - LZMA       15 - Reserved by PKWARE       16 - IBM z/OS CMPSC Compression       17 - Reserved by PKWARE       18 - File is compressed using IBM TERSE (new)       19 - IBM LZ77 z Architecture        20 - deprecated (use method 93 for zstd)       93 - Zstandard (zstd) Compression        94 - MP3 Compression        95 - XZ Compression        96 - JPEG variant       97 - WavPack compressed data       98 - PPMd version I, Rev 1       99 - AE-x encryption marker (see APPENDIX E)```
Is not really a valid compression method. I changed the compression method to LZMA because it was closer to it and when decompressing with 7-zip we get the last piece of the flag:
The "good" zip file:
```00000000: 504b 0304 0a00 0000 0e00 0000 0000 0dc6  PK..............00000010: 1393 2100 0000 0d00 0000 0000 0000 0904  ..!.............00000020: 0500 5d00 0080 0000 189a c266 018f 4560  ..]........f..E`00000030: 7ec8 9ce0 5165 8987 dcff ff07 2c00 00    ~...Qe......,..```
The third piece of the flag: `1k3_kerber0s}`
The final flag: `ictf{thr33_h34ds_l1k3_kerber0s}`