Skip to main content

🚩TryHackme Room Walkthrough: The Game

TryHackMe room banner for The Game reverse engineering challenge

🎯 Objective​

The goal of the room is to get the flag from the game provided in this room.

⚔️ Exploitation Steps​

📥Step 1: Download and Inspect the File​

  • Download the task files from the room and unzip the archive. Inside you'll find Tetrix.exe - a Windows game executable that supposedly contains our flag somewhere inside it. TryHackMe room interface showing downloadable task files for The Game room Windows file explorer displaying extracted Tetrix.exe game executable file
  • Since exe is a binary file and binaries aren't pure machine code - they also contain data, error messages, UI text, hardcoded strings, encoded data, and sometimes things developers forgot to remove.

🔍Step 2: Extract the flag​

  • Since Tetrix.exe is a binary file, we need to reverse engineer or decompile it to extract the flag buried inside our binary file.
  • However, There might be chances that our flag could be sitting in the binary as a plain readable text without any encryption.
  • Therefore, Before decompiling the binary lets try printing all the strings present inside the file using strings and pipe it through grep to filter for the flag format.
    info

    strings works by scanning a binary file and printing any sequence of printable characters above a minimum length (4 by default). It doesn't care about the file format or language - it just reads what's there. grep THM{ then filters the output down to only lines matching our flag format, cutting through all the noise.

    Terminal output showing strings and grep command extracting THM flag from Tetrix.exe binary
  • And💥Boom!, We got the flag sitting just as a plain readable text.

⚠️ Vulnerability​

  • The flag was stored as a hardcoded plaintext string inside the game executable. The developer likely assumed that distributing a compiled .exe was enough to hide its contents - but compilation is not encryption. It just converts source code into machine instructions; it does nothing to protect static data embedded in the binary.
  • Any plaintext string in the source code - a password, a flag, an API key - will survive compilation and remain readable to anyone with strings or a hex editor. No reverse engineering skill required. This is a form of information disclosure: sensitive data exposed because it was stored somewhere it was assumed to be safe, but isn't.

🛡️ Mitigation​

  • The flag should never be in the binary in the first place.
  • The right approach for something like this is server-side validation. The game sends a completion signal to a server, the server verifies it and responds with the flag. The client never holds the secret at any point, so there's nothing to extract.
  • We could also go with encryption — store the flag encrypted and only decrypt it after server-side verification. But purely client-side decryption doesn't help here because the decryption key would also be in the binary, and we're back to the same problem.
  • Obfuscation — splitting the string, encoding it, XORing it — would've made strings | grep fail in this specific case. But it's not real protection. A debugger catches the value at runtime the moment it gets used. It raises the bar just enough to stop the laziest attempts, nothing more.
  • The only real fix is to keep the secrets off the client entirely.

📚 Lessons Learned​

  • Anything in a client-side binary should be treated as already public.
  • And the habit to build from this room: whenever you're looking at a binary in a CTF, run strings | grep for the flag format before doing anything else. It won't always work, but when it does it just takes ten seconds. Start simple, escalate only when you need to.