# key checker
Category: Reversing
Key checker starts off with a \`key\_checker.exe\` binary. Because it's a windows binary, we'll run it in WSL first:
Whenever any character is correct and in the correct location, it'll show. So we'll just need to loop over all alphanumerical characters, mark when the character gets accepted, and output the final result.
```python
import subprocess
import string
import re
import sys
# Configuration
EXE_PATH = "./key_checker.exe"
CHARSET = string.ascii_uppercase + string.digits + string.ascii_lowercase + string.punctuation
def solve():
print(f"[*] Starting attack on {EXE_PATH}...")
found_chars = [None] * 10
# Iterate through every possible character (A, B, C...)
for char in CHARSET:
guess = char * 10
try:
result = subprocess.run(
[EXE_PATH],
input=f"{guess}\n",
text=True,
capture_output=True,
encoding='utf-8'
)
except FileNotFoundError:
print(f"Error: {EXE_PATH} not found.")
return
# Parse output
match = re.search(r"Key pattern:\s+([✗✓]+)", result.stdout)
if not match:
continue
pattern = match.group(1)
print(f"Testing '{char}': {guess} | Pattern: {pattern}")
# Mark found characters
for i, mark in enumerate(pattern):
if mark == '✓':
found_chars[i] = guess[i]
if None not in found_chars:
print(f"\n[+] KEY FOUND: {''.join(found_chars)}")
break
if __name__ == "__main__":
solve()
```
And it finds the key:
When we enter it into the input of the "key\_checker.exe", the output changes:
"Request sent successfully!" and no other output. Initially I got stuck here trying to reverse engineer the binary using Ghidra, but after looking at the output again, it's talking about a request. Probably network traffic then.
There's one tool that fits this job; [Microsoft Network Monitor](https://www.microsoft.com/en-us/download/details.aspx?id=4865).
After going through the standard installation process, it should be ready to run as administrator:
Click on "New capture" for the capture view:
In the display filter, enter
```
ProcessName.Contains("key_checker")
```
Then, start the capture, re-run "key\_checker.exe", and enter the password.
Finally, click "Apply" at the top left corner of the Display Filter. Now the screen should look like this:
Now the traffic from key\_checker.exe is filtered out. Next, press ctrl-S and select "Displayed frames" to save to a .cap file.
Now, open the .cap file in Wireshark:
There's a lot of HTTPS requests being made. select one of the TLS requests, and follow the TCP stream.
Now flip through the streams, and we'll find a POST request with some information and the same credentials we sent earlier:
The "givemetheflag" header contains "false". If we create a request with the same parameters and switch "givemetheflag" to true, it returns a lot of information:
```
curl -X POST "http://185.213.240.231:6060/" \
-H "authorization: TU_Delft_CTF_Team" \
-H 'x-api-key: H05SyBO$$Y' \
-H "givemetheflag: true" \
-H "accept: */*"
```
{% hint style="info" %}
Note that there's single quotes around the x-api-key. This is because BASH will try to interpret dollar signs in strings with double quotes as variables, and the server will get the wrong password.
{% endhint %}
If we pay close attention, we'll see the flag in the text:
Flag:
```
TUDCTF{0ead11bab6d2f10e7dfca9d861ac755b37aef6ca04ef93d9939c66d63c8ae48a}
```
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://eduw.gitbook.io/writeups/tud-ctf-2025/key-checker.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.