SpookPass - Hack The Box

Table of Contents

Challenge Description

All the coolest ghosts in town are going to a Haunted Houseparty - can you prove you deserve to get in?

Initial Files

Upon accessing the challenge, we were provided with a single compressed archive:

[kali@machine01 ~/htb/spooky-pass]$ ls
SpookyPass.zip

Extracting the contents using the password supplied with the challenge — hackthebox — revealed the following structure:

[kali@machine01 ~/htb/spooky-pass]$ unzip SpookyPass.zip 
Archive:  SpookyPass.zip
   creating: rev_spookypass/
[SpookyPass.zip] rev_spookypass/pass password: 
  inflating: rev_spookypass/pass

After extraction, we obtain a single file named pass inside the rev_spookypass/ directory. At this point, no file extension is provided, so further analysis will be necessary to determine the file type and its intended functionality.

Binary Identification

The next step was to determine the nature of the pass file. We used the file command to inspect its format:

[kali@machine01 ~/htb/spooky-pass/rev_spookypass]$ file pass                   
pass: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=3008217772cc2426c643d69b80a96c715490dd91, for GNU/Linux 4.4.0, not stripped

The output reveals that this is a 64-bit ELF PIE executable for the x86-64 architecture, dynamically linked, and intended to run on GNU/Linux systems (kernel 4.4.0 or later). The binary is not stripped, which means it still contains useful symbol information that can aid in static analysis — especially during disassembly or reverse engineering with tools like Ghidra, IDA, or radare2.

The mention of PIE (Position-Independent Executable) implies that the binary’s code segments can be loaded at random memory addresses, a common security feature that supports ASLR (Address Space Layout Randomization).

Binary Protections

To identify the security mechanisms enabled during compilation, we used the checksec tool against the binary:

[kali@machine01 ~/htb/spooky-pass/rev_spookypass]$ checksec --file=pass 
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified   Fortifiable      FILE
Partial RELRO   Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   31 Symbols        No    0           2pass

The output indicates that the binary was compiled with several common security features:

  • Partial RELRO: Only the GOT (Global Offset Table) is read-only after relocation. This is weaker than full RELRO, as it doesn’t protect against GOT overwrite attacks.

  • Stack Canary: Present. This helps detect and prevent buffer overflows on the stack by checking for a known value before function returns.

  • NX (Non-eXecutable stack): Enabled. This prevents code execution on the stack, which mitigates classic stack-based shellcode injection attacks.

  • PIE (Position Independent Executable): Enabled. The binary can be loaded at a random memory address, supporting ASLR (Address Space Layout Randomization).

  • FORTIFY_SOURCE: Not enabled. This means no additional checks were inserted to detect common unsafe functions like strcpy or sprintf.

  • Symbols: Present. The binary contains 31 symbols, which can aid static analysis tools by exposing function names or global variables.

These mitigations indicate that the binary was compiled with some attention to security. However, the use of Partial RELRO and the lack of FORTIFY optimizations could leave room for certain types of exploitation depending on the vulnerability discovered.

Executing the Binary

Running the binary is straightforward. By executing ./pass, we are greeted with a spooky message and prompted to enter a password in order to gain access to the most terrifying party of the year:

[kali@machine01 ~/htb/spooky-pass/rev_spookypass]$ ./pass             
Welcome to the SPOOKIEST party of the year.
Before we let you in, you'll need to give us the password: admin
You're not a real ghost; clear off!

As seen above, submitting an incorrect password — in this case, admin — results in rejection and no flag or further access is provided.

At this point, it’s clear that the binary is performing a password check internally. Our goal is to analyze how this validation occurs, determine the correct password, and retrieve the flag hidden within the binary.

String Analysis

To begin our static analysis, we used the strings utility to extract all printable characters from the binary. This can often reveal hardcoded data such as debug paths, error messages, or even passwords.

# .. SNIP ..
PTE1
u3UH
Welcome to the 
[1;3mSPOOKIEST
[0m party of the year.
Before we let you in, you'll need to give us the password: 
s3cr3t_p455_f0r_gh05t5_4nd_gh0ul5
Welcome inside!
You're not a real ghost; clear off!
;*3$"
GCC: (GNU) 14.2.1 20240805
GCC: (GNU) 14.2.1 20240910
main.c
_DYNAMIC
__GNU_EH_FRAME_HDR
# .. SNIP ..

Among the various strings found, one immediately stands out:

s3cr3t_p455_f0r_gh05t5_4nd_gh0ul5

This string appears right after the prompt that asks for the password, and before the success message "Welcome inside!". Based on its context and format, it strongly resembles a hardcoded password — most likely the correct one required to pass the binary’s authentication check.

This kind of direct discovery highlights the importance of strings as a first step in binary analysis. It often reveals low-effort implementations where credentials or sensitive values are embedded directly into the executable without obfuscation.

Obtaining the Flag

With the secret password identified during our string analysis, we can rerun the binary and provide the correct input:

[kali@machine01 ~/htb/spooky-pass/rev_spookypass]$ ./pass              
Welcome to the SPOOKIEST party of the year.
Before we let you in, you'll need to give us the password: s3cr3t_p455_f0r_gh05t5_4nd_gh0ul5
Welcome inside!
HTB{redacted}

Upon entering the correct password, access is granted and the flag is revealed — confirming that the hardcoded string we found was indeed the authentication key.

This challenge demonstrates how useful basic static analysis techniques like strings can be, especially when binaries lack obfuscation or symbol stripping. Even a quick inspection may expose critical data, such as credentials or flags, without the need for deeper reverse engineering.

Conclusion

The SpookyPass challenge serves as a great introductory exercise in reverse engineering, emphasizing the value of basic static analysis techniques. Despite the presence of common binary protections such as stack canaries, NX, and PIE, the lack of obfuscation and the inclusion of symbols made the analysis straightforward.

By simply inspecting the strings in the binary, we were able to identify a hardcoded password — demonstrating how insecure it is to embed sensitive data directly in compiled executables. In real-world scenarios, such oversights can lead to serious security breaches.

This challenge reinforces an essential lesson: even without advanced reversing tools, thoughtful use of simple utilities like file, checksec, and strings can lead to quick and effective results.

References

  1. GNU strings Manual
    Essential tool for extracting human-readable strings from binaries — often useful for revealing hidden messages, hardcoded credentials, or debug info.

  2. checksec GitHub Repository
    Utility for analyzing binary-level protections such as stack canaries, NX, RELRO, and PIE — useful for evaluating a binary’s hardening.

  3. Hack The Box – Challenge Platform
    Official platform for solving real-world-inspired CTF challenges in areas like reverse engineering, exploitation, cryptography, and more.

  4. Linux Hint – What is an ELF File?
    Overview of ELF binaries — understanding ELF structure is key when analyzing Linux executables.