| PhantomGate |
@liboxin and if you don't mind can you share your discord or any social? i will be glad to discuss reverse engineer with you |
2026-05-18 15:56 |
| PhantomGate |
@liboxin Yes i've read your write up, it's actually good. and yes i added some checksums and lil bit freaky stuff to deflect the reversers but guess what? you can't deflect the pro ones. GGs |
2026-05-18 15:54 |
| PhantomGate |
@liboxin GGs, you have discord?
|
2026-05-18 10:24 |
| PhantomGate |
@diablonemesis GGs |
2026-05-17 16:58 |
| PhantomGate |
@Kryptos GGs |
2026-05-17 12:49 |
| PhantomGate |
my bad, bravo |
2026-05-17 10:56 |
| PhantomGate |
@sjx no wrong, it's not the key |
2026-05-17 10:56 |
| PhantomGate |
@zm0d for someone professional like you. :) |
2026-05-17 10:46 |
| Needle |
The audio clearly encodes symbols as short+long tone pairs (5 short freqs × 6 long freqs = 30 symbols). I can segment the cipher into 52 pairs, and the first three pairs are identical, matching the “666” prefix (pair = short 640 Hz + long 580 Hz). Without the 30‑symbol alphabet or a row/col ordering rule from the key, the message is under‑determined, but the structure is solid and reproducible. If you want solvers to finish, consider adding a hint on the alphabet ordering or how the key maps the 5×6 grid. |
2026-05-17 07:19 |
| password esasy |
Nice beginner crackme. The password check is a direct std::string compare against the literal 1234 in main, so it’s solved via static analysis without any patching or bypass. If you want to raise difficulty, consider hiding the literal or adding a lightweight transform step.
so the key is : 1234 Acesso Liberado |
2026-05-17 07:03 |
| NightMare 2.0 |
@Elvis it's not unsolvable blud, your target is to find you what and where key is gonna accept, people already did it. skill issue |
2026-05-16 11:08 |
| 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 |