Crackme’s Wheredakey

I’m starting this challenge as a complete beginner in reverse engineering. I have solved CTF challenges before and have some experience with cybersecurity, but reverse engineering is still a new area for me. I have mostly learned about it by reading writeups and understanding how other people approach binaries. Now I want to actually spend 30 days solving challenges myself.

Since I am a beginner, I am not going to jump directly into difficult crackmes. I will mainly focus on challenges around difficulty 1–3, and sometimes 4. My approach probably won’t be the best or the most efficient one, especially in the beginning. That’s part of the point.

I want to document the mistakes, confusion, small discoveries, and techniques I learn along the way.

I will also use AI during this journey, but not to simply give me the solution. I want to use it more like a learning assistant — to explain confusing functions, clarify concepts, help me understand what I am looking at, or point me in the right direction when I get stuck.

The actual process of analyzing the binary, connecting the clues, and reaching the answer will be mine.

I will also use AI to help structure these writeups and improve the grammar so that the articles are easier to read. The underlying experience, observations, and problem-solving process will come from my own work.

With that out of the way, let’s start with Day 1.

Challenge: Wheredakey

Difficulty:1.0
Quality:3.5

OBJECTIVE OF CHALLENGE:

The objective of this challenge was straightforward:

Find the correct password by reverse engineering the binary.

The challenge also asks us to comment on how we reached the final answer, which makes it a good challenge for documenting the reverse engineering process.

When I first ran the binary, it displayed:

This crackme is brought to you by GlitchBaby

Enter the Password:

So obviously, the first thing I knew was that somewhere inside the binary there had to be a password validation mechanism.

INITIAL RECONNAISSANCE:

I opened the executable in Binary Ninja.

Since I am still new to reverse engineering, I first changed the view to the higher-level Pseudo C representation. This made the binary easier for me to understand compared with looking directly at assembly.

Because the program asks:

Enter the Password:

I initially searched around that part of the code.

At first, I didn’t find anything particularly interesting.

So I decided to look at the symbols/functions instead.

While going through the functions, I noticed the strcmp function.

I clicked on it and Binary Ninja showed me the code surrounding the password comparison.

One line immediately caught my attention:

if (strcmp(&var_48, strcat(&var_68, &var_73)))

This was one of those moments where I wasn’t completely sure what I was looking at.

But I knew that strcmp() is used to compare strings.

So I started following the variables involved in the comparison.

METHODOLOGY / IDENTIFYING CORE VULNERABILITY:

The first variable I followed was var_48.

When I clicked on it in Binary Ninja, it highlighted:

__isoc99_scanf("%s", &var_48);

This made things much clearer.

The program is taking the user’s input using scanf() and storing it in var_48.

Get Ciphernom@d04’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

So:

var_48 = User Input

That means the final strcmp() is comparing our input against another string constructed somewhere else.

Next, I followed var_68.

Binary Ninja highlighted this line:

__builtin_strncpy(&var_68, "Bash", 0x19);

So initially:

var_68 = "Bash"

Then I noticed another operation involving the same variable:

strcat(&var_68, &var_7a);

I already knew that strcat() is used for string concatenation.

However, this was actually a good reminder for me.

Sometimes when looking at code during a CTF, you can know what a function does but still overlook how important it is in the current context. My brain initially just saw strcat() and moved on.

But this was the actual password construction happening right in front of me.

I followed var_7a and found:

__builtin_strcpy(&var_7a, "Qc3fZ1");

Therefore:

var_68 = "Bash"
var_7a  = "Qc3fZ1"

After:

strcat(&var_68, &var_7a);

we get:

var_68 = "BashQc3fZ1"

There was another string involved:

__builtin_strcpy(&var_73, "6AjD701x0O");

And the final comparison contained:

strcat(&var_68, &var_73)

So the program was effectively doing:

"Bash"
    +
"Qc3fZ1"
    +
"6AjD701x0O"

which results in:

BashQc3fZ16AjD701x0O

Finally, this constructed string is compared against the user’s input:

strcmp(&var_48, &var_68)

Since strcmp() returns 0 when both strings are identical, the correct input needs to match the constructed string exactly.

FLAG / PASSWORD:

BashQc3fZ16AjD701x0O

And that’s my first reverse engineering challenge of the 30-day journey.

What I found interesting about this challenge wasn’t just the password. It was the process of getting there.

I started with something simple: “Where is the password checked?”

Then I followed the functions and variables one by one:

scanf()
   ↓
var_48
   ↓
strcmp()
   ↓
var_68
   ↓
strcat()
   ↓
"Bash" + "Qc3fZ1" + "6AjD701x0O"
   ↓
BashQc3fZ16AjD701x0O

For someone experienced in reverse engineering, this may look extremely simple. For me, as a beginner, it was a useful first exercise in learning how to follow data through a binary.

Day 1 complete.

29 more days to go.