Rating: 5.0

Disclaimer: Not sure what the intended solution here is, but I found the flag by messing around a bit.

First off, we're given the files "wut" and "cryptor.exe". Reversing cryptor.exe, it seems to open up a file called "demo.exe", then XOR it with the repeating key `7h15157h3n3w8391nn1n9`, and writing the results to a file called `wut`. This process should be reversible, so we should be able to just rename "wut" to "demo.exe" and run cryptor.exe again, or do the XORing ourselves.

The process seemingly goes fine, but there's something messed up in the DOS warning in the MZ header `This program cannot be run in DOS moc9!a`. This is supposed to end with `mode.\r\n`. Further down in the file, where we're supposed to see a lot of nullbytes, there's some patterns - of the same length as our XOR key - repeating over and over. So our XORing efforts are somehow getting misaligned somewhere, and it first happens near the end of the MZ header. Opening up the encrypted file `wut` in a hex editor, there is a `\r\n` in that position. Removing the `\r` and XORing again, and the header is suddenly fine. The repeating patterns below are replaced with nullbytes.

All fine now, or :) ? No. It breaks down again after a few dozen bytes or so. Repeating patterns instead of zerobytes, no binary symbols, etc. What if we try to replace ALL the `\r\n` pairs with just `\n`?

```python
key = b"7h15157h3n3w8391nn1n9"
data = bytearray(open("wut", "rb").read().replace(b"\r\n",b"\n"))

for i in range(len(data)):
data[i] ^= key[i%len(key)]

with open("demo_new.exe", "wb") as fd:
fd.write(data)
```

Briefly looking through the file now, and it's in much better shape! Sections, symbols, lots of padding nullbytes, even some XML at the end. Does it run? No. Luckily, the flag is stored inside the binary, as UTF-32, so we can just extract it without trying to figure out what's still broken.

```
$ strings -e L demo_new.exe
inctf{thisaintframestutter}
```

My guess is that the intention of this challenge is to figure out that the encryptor somehow wrote the wrong types of newlines to the encrypted file, and we need to figure out where that happened and fix each one. But I couldn't spot such a mistake in the binary itself when reversing it.