Scheme-Catcher
- Challenge: beacon.bin (First Stage)
- Category: Binary Exploitation / Reverse Engineering
- Difficulty: Insane
- URL of the room:
Summary
The actual functionality of the program is concealed by a custom encrypted .easter section found in the beacon.bin binary. We found a self-decrypting stub that XORs the encrypted code with key 0x0D using dynamic analysis with GDB. The payload_load() function uncovered a hardcoded HTTP path /7ln6Z1X9EF built from hex immediates after decryption. This path resulted in a directory listing with the next stage binary and foothold.txt (Second flag).
Finding the first binary.
Scanning using nmap
After the scan we used gobuster to list hidden directory on port 80
On this directory we found a zip file which is carying our first binary beacon.bin
Initial Reconnaissance
File Analysis
Key Observations
- 64-bit Linux executable
- No stack canary (vulnerable to buffer overflows)
- NX enabled (no shellcode on stack)
- No PIE (static addresses)
Static Analysis
String Enumeration
Found:
THM{Welcom3_to_th3_eastmass_pwnland}- First flag placeholderlocalhost- HTTP connection targetGET %s HTTP/1.1- HTTP request format/tmp/b68vC103RH- Temporary file path
Interesting Functions:
setup()- Initializationpayload_load()- Suspicious - loads somethingcmd()- Command executiondelete_cmd()- Cleanupstart_socket_server()- Network functionality
XOR Encryption
Note: The disassembly revealed a brief loop that iterated over a memory range from
0x401370to0x401bc4when examining the early code in the.eastersection. Each byte in this loop was read, XORed with the constant0x0D, and then written back to the original location. Execution was then redirected to that area. This pattern is typical of a self-decrypting XOR stub, which means that the actual program logic is encrypted and only decrypted during runtime, just prior to execution.
GDB Investigation
Decryption Stub Found at 0x804000:
The Algorithm: XOR each byte from 0x401370 to 0x401bc4 with key 0x0D
Breaking After Decryption:
Functions are now visible!
Analyzing payload_load()
Key Instructions Found:
Decoding the Suspicious hex:
Got the hidden path as /7ln6Z1X9EF
Analysis of Reverse Data Flow:
The format
"GET %s HTTP/1.1"is used bysnprintf()at0x401674.The source of the
%sparameter isrbp-0x11c.Looking for writes to
rbp-0x11cin reverse, themovabsinstruction was located at0x401648.
Accessing the Hidden Directory
Directory Listing Revealed:
Second Flag
Tools Used
- file - Binary identification
- checksec - Security feature enumeration
- readelf - ELF structure analysis
- strings - Static string extraction
- GDB - Dynamic debugging
- objdump - Disassembly