| The Seven Gates of Nullhaven |
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. |
2026-03-02 10:30 |
| HellGates |
Thanks but not yet, I respect the time you took so no hints just yet ;) |
2026-02-28 11:12 |
| SirCrackaLot v2 |
I’m looking forward to seeing how you solved it. I’ve been a member here for quite a while, but until now I’ve only taken on challenges occasionally and never written any myself. I also have a new one currently waiting for approval.
Once again, thank you for playing. |
2026-02-28 09:44 |
| HellGates |
I can confirm that my findings were garbage, so there’s no need to walk you through the steps—you’d probably end up even more confused than I was when I found this key. Sometimes, when you dig into a binary, you end up getting caught by traps.
That said, I do have a new lead that looks far more promising. I’ve changed tactics completely this time. If you spent a full year creating it, it obviously wasn’t meant to be easy. I’ve already learned a lot from it—especially how not to get dragged down the wrong path. |
2026-02-28 09:40 |
| HellGates |
I can when I have time to sort my findings ;)
Thanks so far... |
2026-02-27 23:20 |
| HellGates |
I'm pretty sure the key is: ekrsvx |
2026-02-27 21:08 |
| SirCrackaLot v2 |
Nice — if you have a keygen or a write-up, that would be appreciated. As we all know, these challenges can sometimes be solved in ways others did not anticipate, so feel free to post one.
Thanks for playing. This was my first crackme. |
2026-02-27 20:14 |
| Prometheora |
I wasn’t really prepared for how difficult it would be. I started working on it to tire myself out so I could sleep, but the damn crackme kept giving me just enough progress to keep me hooked — and I ended up writing a write-up instead 😉
And if I had actually read the instructions properly, I probably would have saved myself a few choice swear words :P
So, thank you very much for the workout with Binary Ninja and all the other tools. |
2026-02-26 13:31 |