i have a problem replicating the behaviour of the given c program, which i assume was used to create the ciphertext.
my implementation encodes a block with a windows line ending 0x0d0a00 to 0x2ee630 (with the hardcoded key). applying cmea again correctly yields 0x0d0a00.
when i encrypt the same file with the given program, 0x0d0a00 is encoded to 0x0f1951 and using the program again, i get 0x0d0a0000.
why does this happen? other strings like "abcdef" encode/decode fine and with the same ciphertext in both my implementation and the supplied program.
i suspect the different behaviour can be a problem if the challenge plaintext was created with windows notepad, which always includes cr-lf at the end of a file.
The example program treats files as ascii (with "w" and "r"). Change this to binary ("wb" and "rb") and your ciphertexts will be the same length as your plaintexts. Otherwise certain characters are written on Windows machines with 2 characters and your ciphertext grows a byte here and there, and then if you read it in as "wb" the plain and cipher text are out of alignment.
I got hung up for most of a week debugging a non-issue revolving around this. It's probably fine if your cracking program also use "r" instead of "rb", but I used "rb" in my program and nothing would decrypt.