KHP Protocol Challenge Scenario — HackTheBox

Summary

This challenge was a custom threaded TCP service implementing its own text protocol. The important commands were REKE, DEKE, RLDB, AUTH, and EXEC.

Initial reversing suggested several possible issues, including globally shared authentication state across threads and weak profile handling. The confirmed remote solution, however, was the empty-database heap-overflow route: groom the in-memory key list, delete one entry, overflow a heap chunk in RegisterNewKey, forge an admin profile, authenticate it, then open a second connection and use EXEC to read the flag.

Reconnaissance / Reversing

The binary was a TCP server that accepted line-based protocol commands from each client. Local notes also showed a number of suspicious design choices:

• REKE registered a new user:role key entry.
• DEKE deleted an entry by id.
• RLDB reloaded keys from the on-disk database.
• AUTH authenticated using an in-memory profile id.
• EXEC spawned /bin/sh when the current role was admin.

An early hypothesis was that the challenge might be solvable purely through shared global state, because several variables were process-global and reused across threads. That idea was relevant, but it was not the full exploit on the real service.

The key confirmed bug was in RegisterNewKey: it allocated only 0x54 bytes for a heap object, then built the resulting profile string with sprintf using attacker-controlled fields. Because both the user:role part and the key were under our control, the formatted string could exceed the allocation and overflow into adjacent heap data.

This mattered especially when the in-memory database was groomed into a predictable layout. By creating several small entries, reloading from disk, deleting one slot, and then inserting a crafted oversized record, the overflow could corrupt neighboring state in a way that made AUTH 1 succeed as an admin profile.

...