| Crackmes.one RE CTF 2026 - FlipVM |
Good crackme. password:
$?$__LeT_Th#_h@ck!ng_b3g1n__$?$ |
2026-03-12 21:56 |
| my first simple crack me by whekkees |
0x6b656877 + 0x7365656b -> whekkees
0x72657771 + 0x74 -> qwert
login: whekkees
password: qwert |
2026-03-12 05:32 |
| Boring |
Nice one. The binary is a Rust ELF with several fake flags in .rodata, so `strings` is a trap exactly as advertised.
The solve path for me was static analysis plus controlled emulation of the real validation routine. The program reads 38 bytes, then builds the expected flag through multiple stages: there is an anti-debug/anti-analysis layer first, and after that a chain of transformations that includes TEA-style rounds, an RC4-like stage, a ChaCha/Salsa-like mixing stage, and an AES-based final step. The important trick is that the anti-debug logic flips a global sabotage byte; once that happens, the generated buffer is intentionally corrupted and you always end up at “Access denied”, even if you are tracing.
So the practical solve was:
1. Locate the real `main` and the final byte-by-byte comparison.
2. Identify the anti-debug checks (`cpuid`/hypervisor, timing with `rdtsc`, `ptrace`-style logic, `/proc` checks).
3. Emulate the clean path with those checks neutralized.
4. Dump the expected 38-byte buffer right before the final compare.
No brute force needed, just untangling the anti-analysis and letting the crypto pipeline reconstruct the flag.
FLAG{d34d_c0d3_w4lk5_4m0ng_u5_1n_rust}
|
2026-03-11 17:45 |
| Nebula |
Nice crackme. I solved it by locating the real validation routine after the anti-debug checks (IsDebuggerPresent / CheckRemoteDebuggerPresent). The strings were only XOR-obfuscated with 0x5A, so decrypting them quickly revealed the prompt and success/fail paths. From there, the key check was straightforward: exact length 14, dashes at positions 4 and 9, a per-character transform whose total must be 0x539, plus a few direct relations between characters. I just rewrote that logic in a small script and generated a valid key without brute force.
KEY: ADBC-PLZR-6YZR |
2026-03-11 17:17 |
| Simple Crackme 3 |
The key point is that there is no single static password: the program generates a new 12-character password on each run from a custom charset, keeps it in memory XOR-obfuscated, and only checks the FNV-1a hash of the user input. The easiest solve path was to attach to the running process, recover the stack-resident std::string, decrypt it with the stored XOR byte, and use that value as the password for that execution. |
2026-03-07 05:41 |
| Fatmike's Crackme #9 (crackmes.one CTF 2026) |
Serial: D3FE-A7ED-BAAD-C0D3
Flag: CMO{byp4ss3d_f4tm1k3_2o26} |
2026-03-07 05:38 |
| Chamber of Reflections |
FLAG-JSVM-1337 |
2026-03-07 05:10 |
| Silent Lock |
AaaA0Zpl |
2026-03-07 05:03 |
| Pwn Flick |
The arithmetic obfuscation in Func 0 looked complex, but black-box analysis revealed it collapsed to a simple linear equation: 3 - input = target. Key found: 18446438094414070465 |
2026-01-09 02:00 |
| Modified Bessel |
The crackme tries to load a DLL named mandel.dll that exports a function named
function
. The key detail is that the executable is 32-bit, so the DLL must also be compiled for x86 (32-bit) architecture. Once the DLL is placed in the same directory, the program loads it and displays the success message. |
2026-01-09 01:13 |
| ZEXOR-v0.1 |
AEXORRBSHA36325S33 |
2025-12-31 05:15 |