TheSwedishLord's The Seven Gates of Nullhaven

Author:
TheSwedishLord

Language:
C/C++

Upload:
2026-02-27 23:07

Download

Platform:
Unix/linux etc.

Difficulty:
3.5

Quality:
3.0

Arch:
x86-64

Downloads:
15

Size:
349.42 KB

Writeups:
1

Comments:
1

Description

An original multi-stage crackme with seven progressive gates, each requiring a different reverse-engineering technique to breach. Stages: 1. Stack buffer overflow 2. Chained multi-room buffer overflow 3. Three-layer cipher reversal (Rolling XOR, nibble shuffle, byte rotation) 4. Serial key validation with polynomial constraints 5. XOR-obfuscated dispatch table graph traversal 6. AES-encrypted flag with heavy anti-analysis (ptrace, timing, INT3, integrity checks) 7. Final convergence — all prior tokens combine into one key Anti-patching: Flags are derived from correct input through irreversible computation. Patching branches produces garbage, not valid flags. Anti-analysis: Stages 5-7 employ ptrace detection, rdtsc timing checks, self-integrity CRC32, manual stack canaries, decoy functions, and control-flow flattening. Design: Static binary, stripped, no stack protector, no PIE, no RELRO. Sequential gate progression required.

Comments (1)
Writeups (1)

You must be logged in to post a comment

TheSwedishLord on 2026-03-02 10:30: [Click to reveal]Review — Nullhaven Writeup Good work on the static analysis fundamentals. Your identification of the two input readers (fgetc vs. fgets), the gate entry points, and the CRC-16 CCITT implementation are all spot-on. The Gate 3 inversion chain (Fibonacci XOR, S-box, ROL) is clean and correct, and catching the two decoy constraints in Gate 4 shows careful control-flow analysis rather than just reading comparison instructions at face value. That said, there are three issues that prevent this from being a valid solve. Gates 4 and 5 both suffer from the same analytical gap. You correctly identified the constraint systems and solved them — but solving the constraints is only half the problem. In both gates, the validated input values are also used as key material for token derivation (hash computations, XOR accumulator values, etc.). A solution that satisfies the gate's checks but produces the wrong key material will yield a garbled token. In Gate 4, the constraint system is underdetermined — there are tens of thousands of valid solutions, but only one of them produces a meaningful token when fed through the downstream crypto. Similarly, in Gate 5, reaching the target node is necessary but not sufficient; the specific path taken determines the decryption key. The shortest path is not necessarily the correct one. The telltale sign was right there in your own writeup: you noted that the Gate 4 token "includes non-printable bytes" but didn't investigate further. When a token that should be human-readable comes back as binary garbage, that's a strong signal that the derivation key is wrong — even if the gate's validation logic accepted the input. Gate 7 is described as "The Final Convergence" for a reason. Your observation about the weak validation is technically correct, but exploiting it with a random string sidesteps the intended design. Consider what "convergence" implies in the context of a 7-gate progressive challenge where earlier gates produce artifacts. The brute-force approach also wouldn't have been necessary if the earlier tokens had been correct. On the flags: The challenge description states that "flags are derived from correct input through irreversible computation" and that "patching branches produces garbage, not valid flags." The same principle applies here — passing a gate's validation check is not the same as solving it. The correct input must produce a valid, readable token through the binary's internal derivation pipeline. Gates 1, 2, 3, and 6 produce correct tokens. Gates 4 and 5 pass validation but yield garbled, non-printable output — which are not valid flags. Gate 7 requires all prior tokens to "combine into one key," but with two corrupted tokens upstream, the intended solution was unavailable, and the brute-forced bypass does not produce the intended final flag. Result: 4 of 7 valid flags. The challenge is not solved. General advice for future crackmes at this difficulty level: whenever a gate both validates your input and derives a token from it, trace the full data flow — from input through validation through token generation. Passing the check is step one; verifying that the derived output is well-formed is step two. A quick printability check on the resulting token catches these issues immediately and costs almost nothing to implement in your solver. Solid foundation overall — the core RE skills are clearly there. Closing the loop on token verification would have turned this into a complete solve.

Show all spoilers

You must be logged in to submit a writeup

Solution by djd320 on 2026-03-01 11:09:

Download

crackmes.one

crackmes.one

TheSwedishLord's The Seven Gates of Nullhaven