SpookyPass (Very Easy)

Here is a detailed, human-written walkthrough for the Spooky Pass challenge based on your CLI history.

---

This challenge is a classic example of why basic static analysis is the first step you should take when dealing with a binary. We don't always need complex decompilers like Ghidra or IDA Pro; sometimes the answer is hiding in plain sight.

Here is how I solved it.

Step 1: Initial Reconnaissance

First things first, I needed to understand what kind of file I was dealing with. I utilized the file command to identify the architecture and file type.

Bash

file pass

The Output:

The output confirmed that pass is an ELF 64-bit LSB pie executable for Linux. Interestingly, the output also told me the binary is not stripped. This usually means debugging symbols are left in, which makes reverse engineering easier, but as it turns out, we wouldn't even need to go that deep.

Step 2: Understanding Program Behavior

Before analyzing the code, I ran the program to see what it actually does.

Bash

./pass

The program greeted me with: "Welcome to the SPOOKIEST party of the year." It then prompted me for a password.

I tried entering a random string of "A"s just to test the validation logic. The program immediately rejected it with: "You're not a real ghost; clear off!" This confirmed that there is a string comparison happening somewhere in the background checking my input against a correct password.

Step 3: Inspecting Strings

Before firing up a debugger, I decided to check for unobfuscated strings inside the binary. This is a standard low-hanging fruit check. Compilers store hardcoded text (like print statements and variables) in the binary, and we can read them using the strings command.

Bash

strings pass

I scrolled through the output. At the top, I saw standard library functions like fgets, puts, and printf. However, towards the bottom, I found the text used for the program's dialogue.

Buried right between the "Before we let you in..." prompt and the "Welcome inside!" success message, I spotted a very suspicious string:

Plaintext

s3cr3t_p455_f0r_gh05t5_4nd_gh0ul5

This looked exactly like a leetspeak password.

Step 4: Verification and Flag Capture

Now that I had a potential password, it was time to verify it. I ran the executable one more time.

Bash

./pass

When prompted, I pasted the string I found:

s3cr3t_p455_f0r_gh05t5_4nd_gh0ul5

Success! The program accepted the password, printed "Welcome inside!" and dispensed the flag.

The Flag:

Plaintext

HTB{un0bfu5c4t3d_5tr1ng5}

Conclusion

The content of the flag itself (un0bfu5c4t3d_5tr1ng5) is a nod to the method used to solve this. The developer hardcoded the password directly into the binary without encrypting or obfuscating it, allowing us to simply read it using the strings utility.

---

Would you like me to show you how you could have found this using a tool like Ghidra or GDB instead?