The CSIT Mini CTF 2026 presented us with a 2 stage Windows binary. The first stage downloads an ascii payload from https://minictf2026.s3.us-east-1.amazonaws.com/enc_release-2.txt, performs some decoding where the bits were inverted and reversed, and then loaded into memory and executed. The simpler way to get hold of the decoded binary is to search for where output.exe is referenced, insert a breakpoint there and inspect the memory to get the decoded payload. The rationale is that the payload should already be in plaintext since it is close to where it is written out, hence doing so allow us to skip though the other non-relevant parts.
The second stage payload iterates through random strings, hashes them and checks if it matches 12 pre-specified MD5 hashes. If it matches, the string is encrypted using PKCS1_OAEP and then base64 encoded and sent out over the network. The server probably performs the functions in reverse. It base64 decodes each line, uses the RSA private key to decrypt and verifies that all 12 plaintext strings were sent. When the network traffic for the second stage payload is inspected in wireshark, the observant would notice only 11 base64 encoded strings, and deduce that since there were 12 MD5 hashes in the binary, that could be the missing key. The final MD5 hash, 3bf1114a986ba87ed28fc1b5884fc2f8 pre-image could be trivially cracked since it corresponded to shadow.
Solving the second stage would thus require either patching the binary to include shadow in the plaintext string, or to fully reverse the entire binary and write a python script to RSA encrypt each plaintext string, base64 encode it and send it over the network. The former option would be simpler and is probably the intended solution.