Category: Binary

Team Name : Windows 9/11
Author: Nayanesh

CTF Writeup: MasterChef Sanji Binary Challenge

Challenge Description

The so called "Gourmet Knight" has challenged Sanji to a battle of wits after being embarrassed on the Whole Cake Island in front of all his sous-chefs. Little does he know Sanji is no brute. Here is the challenge presented to Sanji, solve it and let Streusen know who's the best COOK. He got this binary and a torn leaflet of 15 letters which when rearranged said something which Sanji thought was "action ski whoops". Maybe he isn’t as smart as he thought, but he has a lot of PASSION.

Provided Information/Files:

nc cyberstorm 16000
A binary file named local

Initial Clues & Analysis

Upon receiving the challenge, I was provided with a netcat (nc) command and a binary file named local. Running the file on my Kali machine resulted in:

Server listening on port 16000

This suggested that the binary was setting up a local server. To understand its functionality, I analyzed the binary using IDA Pro. Reverse engineering the main function revealed that the server listens on port 16000, accepts incoming connections, and reads user input before passing it to the function bbhtParse().

Investigation Path

Step 1: Reverse Engineering the Binary

After inspecting main(), the key function of interest was bbhtParse(), which performs the following operations:

It tokenizes the input using & as a delimiter.
It checks for input length restrictions (strlen(src) > 0x4A → "Input size is too large!").
It verifies if the input contains prohibited characters (gxlwCheck(src) → "Input contains prohibited characters!").
It calls rfgkDecode(src) and cleanString(dest).
If the processed input contains "BLABLA", it XOR-decrypts a stored value and sends it as the flag.

Step 2: Testing the Server

Initially, I connected to the remote server using:

nc ctf.cyberstorm 16000

I tested sending "BLABLA" but received the response:

Input contains prohibited characters!

I then decided to run the binary locally, and upon starting local, it displayed:

Server listening on port 16000

Connecting to the local instance using:

nc localhost 16000

allowed me to further experiment with inputs.

Step 3: Encoding the Input

The most obvious thing to try is to obfuscate the input and send it as it may bypass the check.
I attempted encoding it in hexadecimal URL format:

echo -n "BLABLA" | xxd -p | sed 's/\(..\)/%\1/g'

This produced %42%4c%41%42%4c%41.

Step 4: Sending Encoded Input

When I sent this encoded version to the server:

nc localhost 16000
%42%4c%41%42%4c%41

I received the flag:

Congratulations! Here's your flag: REDFOX{STreuSen_4In7_4_C0oK_L1ke_M3!}

Finding the Flag

The key steps in obtaining the flag were:

Identifying that the input "BLABLA" was required to trigger the flag.
Noticing that direct input was blocked due to prohibited character checks.
Encoding the input as hexadecimal URL encoding to bypass gxlwCheck().
Sending the encoded input to the server.
Successfully receiving the flag.

Flag: REDFOX{STreuSen_4In7_4_C0oK_L1ke_M3!}

Tools & Resources Used

Reverse Engineering: IDA Pro
Networking: Netcat (nc)
Hex Encoding: xxd, sed
Command Line Utilities: echo

Lessons Learned / Takeaways

Binary Exploitation Basics: Understanding how server-side input parsing works helped in crafting the right input.
Encoding Tricks: When facing input validation, encoding can help bypass restrictions.
Reverse Engineering Insight: Analyzing the binary with IDA Pro helped locate key functions and logic flow.
Testing Different Inputs: Experimenting with various inputs led to discovering the encoding workaround.

Rabbit Holes / Dead Ends

Initially, I tried different variations of "BLABLA" (e.g., lowercase, spaced out) without encoding, which failed.
Attempting to directly modify the binary for debugging didn't yield useful results.

Cyberstorm 2025 Writeup: MasterChef Sanji [By Windows 9/11]