| NeuroVault |
@zm0d glad you like it :) |
2026-05-15 05:49 |
| NightMare 2.0 |
@SingleJingle11 if you wanna take it to next level of reverse engineering then try doing runtime memory dump at the exact right moment. The binary has to load secret.key into memory before it can use it. For a split second, those 32 bytes sit in RAM. |
2026-05-14 05:07 |
| NightMare 2.0 |
@SingleJingle11 The key was generated randomly at setup time and only ever existed on my machine. So yes, you're right: not solvable without it. That was the design. The challenge was never about reversing a keygen or serial check, it was about whether AES-256-GCM with a truly random external key is breakable given only the ciphertext. The answer is no. Solid analysis though, you got further than most. |
2026-05-14 05:04 |
| basic crackme |
can you share you discord? @angridfbirds |
2026-05-13 18:50 |
| NightMare 2.0 |
@angridfbirds exactly secret.key is never given to you. The challenge is to decrypt secret.bin without it. The key is 256-bit random, generated at setup and never embedded in the binary. So your options are: dump it from memory at runtime, or reverse the key derivation. Good luck 🙂 |
2026-05-13 18:48 |
| NeuroVault |
@angridfbirds bravo man, now try my other NightMare 2.0, if you find this one easy. |
2026-05-13 11:30 |
| CrackMe#1 |
Solved I confirmed the check only succeeds under a debugger and the real key changes then the xor of the eight byte constant yields the correct password.
Hint: look at the peb debug flags and the key flip the obvious password appears only when not debugging |
2026-05-12 03:47 |