Number of crackmes:
Number of writeups:
Comments:
| Name | Author | Language | Arch | Difficulty | Quality | Platform | Date | Downloads | Writeups | Comments |
|---|
| Crackme | Date | Infos |
|---|---|---|
| The Barista's Secret | 2026-03-17 19:39 | |
| Password (Obfusacted) | 2026-03-13 23:53 | |
| Mirror Vault | 2026-03-13 23:00 | |
| Not to simple KeyGen V2 | 2026-03-01 21:02 | |
| The Seven Gates of Nullhaven | 2026-03-01 11:09 | |
| MCM 5.0 | 2026-02-28 14:28 | CCCCCChCCCCiCM&CCCCCCCGCCCCCCX#CCKCCC9CCCCCCCCCCCCCCCCCCCCmVC*CC |
| SirCrackaLot v2 | 2026-02-27 19:15 | |
| BobxReal You Can't do it V2 ;) | 2026-02-21 12:28 | |
| Monster CrackMe 1.0 (MCM) | 2026-02-10 09:45 | nice crackme, you could split one key constant between parent and child and randomize small vm constants per run to make it harder. |
| Continental | 2026-02-09 19:12 | the main weakness is the hash compression step caused by left shift then byte truncation. if uniqueness is desired, avoid lossy truncation in the core check path. |
| Gadget | 2026-02-09 18:58 | |
| Find the serial key 2 | 2026-02-01 16:42 | |
| Prometheus 12 Levels of Madness | 2026-02-01 03:03 | !!wow |
| Custom Packer 2.0 | 2026-01-31 15:34 | keygen + writeup. cool |
| CrackMePlease | 2026-01-31 12:10 | |
| TryHard crackme with password | 2026-01-31 08:05 | |
| here no str? | 2026-01-29 21:58 | y0u_50lved_this_pr0blem |
| weird but easy | 2026-01-29 09:02 | cool |
| Religious entrance | 2026-01-01 14:11 | very fun ngl. |
| Last of 25 | 2026-01-01 12:37 | |
| Santa's Network Admin Portal (S.N.A.P.) | 2026-01-01 12:14 | |
| Insane Crackme - The Chaos VM | 2025-12-31 15:16 |
| Crackme | Comment | Date |
|---|---|---|
| The First iOS Crackme | very nice | 2026-03-21 10:25 |
| SirCrackaLot v2 | @chikom35t sure, drop your username here. you can also find me on the discord server and dm me from there | 2026-03-20 19:30 |
| Ternary Trap | cool | 2026-03-17 19:41 |
| The Seven Gates of Nullhaven | method v2 writeup: the routine at 0x402096 is an msb-first crc16-ccitt style update with polynomial 0x1021 and initial eax 0xffffffff. with the structure bytes fixed, only bytes 30 and 31 remained unknown, so solving was a 65536-case search unique solution for the chosen fixed layout: byte 30 --> 0x86 byte 31 --> 0x67 41-byte core payload hex: 0000000000000000000000000000000000000000000000000000000000008667455441470fb0000001 flag 1: NULLHAVEN{OVERFLOW_THE_ABYSS_8A3F} gate 2 this gate is two chained fixed-size reads. the two room payloads must be back to back in the stream, with no extra newline room 1 constraints: dword at offset 32 --> 0xdecade42 dword at offset 36 --> 0x50484153 room 2 constraints: dword at offset 32 --> 0x4f50454e dword at offset 36 --> room1_dword32 xor 0xcafebabe --> 0x143464fc once those values are in place, the token is clean flag 2: NULLHAVEN{CHAINED_CORRUPTION_B7E2} gate 3 this gate is a clean reversible transform and is the first one where the intended solve is already clear from the validation pipeline pipeline: input --> xor with fibonacci byte stream --> nibble substitution --> per-byte rol --> compare with target the fibonacci stream generated by the loop is: 01 01 02 03 05 08 0d 15 22 37 59 90 e9 79 62 db 3d 18 55 6d c2 2f f1 20 11 31 42 73 b5 28 dd 05 the nibble table at 0x49ce40 is a permutation, so it is invertible. the rotate schedule is 1..7 repeating, so that is invertible as well. reversing the pipeline gives the exact 32-byte incantation SOLVETHEPUZZLEOFNULLHAVEN12345XX flag 3: NULLHAVEN{UNRAVEL_THE_CIPHER_C9D1} gate 4 the visible validation constraints are: c xor a --> 0x2ef3 (d + b) mod 0x10000 --> 0x425e (a * b) mod 0x10000 --> 0xc033 with groups parsed as 16-bit words a-b-c-d, this system is underdetermined. because 0xc033 is odd, any odd a is invertible mod 2^16, so there are 32768 arithmetic-valid serials that means a serial satisfying the visible checks is only half of the solve after validation, gate 4 builds the token from the actual serial bytes: serial bytes are packed as: a_lo a_hi b_lo b_hi c_lo c_hi d_lo d_hi those 8 bytes are hashed by helper 0x402907: init eax = 0x811c9dc5 for each byte: edx = byte xor eax edx = edx * 0x1000193 mod 2^32 eax = rol(edx, 13) eax = eax xor (edx >> 7) then gate 4 makes a 12-byte repeating xor key: 4 bytes of that hash in little endian followed by the 8 serial bytes that key is xor-repeated over the 21-byte static blob at 0x49ce50. after searching all valid serials: 45AF-12BD-6B5C-2FA1 for that serial: serial bytes --> af 45 bd 12 5c 6b a1 2f hash --> e8 74 80 e5 repeating key --> e8 74 80 e5 af 45 bd 12 5c 6b a1 2f xor against the static blob yields: KEYGEN_UNCHAINED_44FA flag 4: NULLHAVEN{KEYGEN_UNCHAINED_44FA} gate 5 the graph uses the obfuscated transition table at 0x49cea0. state starts at 0. each move chooses one of four transitions: r --> column 0 u --> column 1 l --> column 2 d --> column 3 success requires the final raw transition value to be 0xdeadbee2, which means the deobfuscated final state is 13. the important extra step is the accumulator in ecx: initial ecx --> 0x13371337 after each valid transition to next state s' --> ecx xor= dword[0x49cfa0 + 4*s'] after the last move, ecx is serialized as 4 little-endian bytes and xor-repeated over the 21-byte blob at 0x49ce80. path: RULDLRD state sequence: 0 --> 3 --> 7 --> 11 --> 14 --> 9 --> 5 --> 13 accumulator evolution: initial --> 0x13371337 xor state 3 value 0xa1b2c3d4 --> 0xb285d0e3 xor state 7 value 0xd4c3b2a1 --> 0x66466242 xor state 11 value 0x12345678 --> 0x7472343a xor state 14 value 0x9abcdef0 --> 0xeeceeaca xor state 9 value 0xfedcba98 --> 0x10125052 xor state 5 value 0x76543210 --> 0x66466242 xor state 13 value 0x0f1e2d3c --> 0x69584f7e 7e 4f 58 69 xor against the static bytes at 0x49ce80 yields: LABYRINTH_ROUTED_E5B0 flag 5: NULLHAVEN{LABYRINTH_ROUTED_E5B0} gate 6 the line must be length 11. the actual comparison value embedded in the handler is VEIL_LIFTED after that, the input is sha256-hashed, the first 16 bytes are used as an aes-128 key, and the static ciphertext at 0x49cfe0 is decrypted with the correct key, the decrypted plaintext is valid and printable flag 6: NULLHAVEN{THROUGH_THE_STATIC_71AC} gate 7 with the gate 4 and gate 5 tokens recovered, the convergence key is the concatenation of the six token payloads, in order, without the NULLHAVEN{} wrapper: OVERFLOW_THE_ABYSS_8A3F CHAINED_CORRUPTION_B7E2 UNRAVEL_THE_CIPHER_C9D1 KEYGEN_UNCHAINED_44FA LABYRINTH_ROUTED_E5B0 THROUGH_THE_STATIC_71AC concatenated key: OVERFLOW_THE_ABYSS_8A3FCHAINED_CORRUPTION_B7E2UNRAVEL_THE_CIPHER_C9D1KEYGEN_UNCHAINED_44FALABYRINTH_ROUTED_E5B0THROUGH_THE_STATIC_71AC feeding that exact string to gate 7 produces the final flag: NULLHAVEN{ALL_GATES_BREACHED_FF00} final solved set gate 1 --> raw 41-byte payload 0000000000000000000000000000000000000000000000000000000000008667455441470fb0000001 gate 2 room 1 --> 64-byte raw payload with: offset 32 --> 0xdecade42 offset 36 --> 0x50484153 gate 2 room 2 --> 64-byte raw payload with: offset 32 --> 0x4f50454e offset 36 --> 0x143464fc gate 3 --> SOLVETHEPUZZLEOFNULLHAVEN12345XX gate 4 --> 45AF-12BD-6B5C-2FA1 gate 5 --> RULDLRD gate 6 --> VEIL_LIFTED gate 7 --> OVERFLOW_THE_ABYSS_8A3FCHAINED_CORRUPTION_B7E2UNRAVEL_THE_CIPHER_C9D1KEYGEN_UNCHAINED_44FALABYRINTH_ROUTED_E5B0THROUGH_THE_STATIC_71AC | 2026-03-05 22:33 |
| The Seven Gates of Nullhaven | that may not be the solution you wanted, but it is a real property of the binary you shipped | 2026-03-05 21:58 |
| The Seven Gates of Nullhaven | ... you are describing a difference between the intended solution and the implemented solution, not between solved and unsolved. i could agree that my Gate 4, 5, 7 path was not the canonical route you designed. but the shipped binary accepted those inputs, advanced the gates, and emitted outputs in the program's own flag pipeline without patching or binary modification on my ends If readability, uniqueness, or exact token convergence were required properties, they needed to be encoded and enforced by the binary or the rules. They were not. in Gates 4 and 5, the acceptance logic was underconstrained relative to the downstream token derivation. in Gate 7, the final convergence check was weak enough to accept unrelated inputs based on decrypted output shape. you can call them whatever you want but remain implementation flaws, and exploiting implementation flaws is normally considered a valid result. if you didn't want to consider something like this as valid, you should have stated it in the rules or made the binary respect those cases. | 2026-03-05 21:56 |
| MCM 6.0 - Project Mayhem | i would never choose this as a beginner crackme lol. and the 3/6 rating is not right imo. more like a 5 but i have to decide as i make progress with my crack | 2026-03-05 21:41 |
| Not to simple KeyGen V2 | Please insert your full name: djd Please insert your best email: djd@email.gov Please insert your serial: AAAAAAdAAAAAAAAA | 2026-03-01 20:22 |
| SirCrackaLot v2 | the writeup has been submitted right after i commented. ;) - waiting for approval | 2026-02-27 22:42 |
| SirCrackaLot v2 | Enter thy name, Aspirant: djd Present thy sacred key: EA49-AD2D-7AB3-8828 Hail, worthy Knight! The Order welcomes thee! | 2026-02-27 19:16 |
| Impossible PatchingMe V2 | *char | 2026-02-13 21:21 |
| Impossible PatchingMe V2 | @miarey what about a 52 chat payload? | 2026-02-13 21:21 |
| Impossible PatchingMe V2 | @karabatik | 2026-02-13 07:30 |
| Impossible PatchingMe V2 | dm me on discord @djd320 | 2026-02-13 07:30 |
| Lugosi's CrackMe II | back to my original theory... | 2026-02-12 07:41 |
| Lugosi's CrackMe II | i am going to ask again if you can provide a valid name/serial pair. | 2026-02-11 21:19 |
| Impossible PatchingMe V2 | key: asd status: ok PAYLOAD: Q1ZNMQEAAACIl5al8OHSwwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHx+crcxMhU9pQjMy28xnumyj4kkbAbZJWXkIYec2tMkdjI7xE+PF+U78tves0+3ykGVwJokRo1gFr5Y33JU/DTYX5E0ZaiMSXsKdRqPSbKsHsAqHS/IvoWYozmMtlV9J6clR2dg9w0O5JCbgbWsK LEMAAAA892AW0RjL6FklaZsRAAAAOumlh+LIaY5becwYz0jFdLKs8C0a1Ygki87JdxIVSzWhC2paysREdtsqcBpNaUx+gmITBGQy4gJ5FZr5RfEh0OfCV1DGAAAAAD/QJjtdgd3ZYIMAAAA2x8Bgnbo194AILnVIQAAAPgL9S0Cnlw5V8xkXSiYE9pFeq/H/6UMY3MnwuFQiFBqeAEAzM XYigGiIY0MAAAASWxIUzGZAohjoveYEgAAAI8+76wBT1dOSDLQqQV2B52wTwIAloxPg3pEI6oMAAAAxP81JdTx6vzFhcPSEgAAAIAQsESCNdmLNxRQIghmLI+VHwMB7ezXwDwWLqkMAAAAEdMQdG0GL9xNg8VCEgAAAIXLx8qzrobBerHcaFlCLzORTwQDkLBndIOre3kMAAAAeLsyx8e 6DNsCye5REgAAALJU9oIvfNtqyrn2x87316Zi+wUETQwPA8yqwt4MAAAAX89h1XAzhH9FLTzaEgAAAHkLPXoxI1z3G4IFL009JEvfqAYFMGv0Y4OViy4MAAAAaQ5oT1hPDV4QYb6tEgAAAJFjcmvOazWOc+ea9viF3gkehgcG3MzybsKXOUsMAAAAnJI5jHvsZhcJgPg1EgAAANzBrUFd 6Oc2ML4P22G7u6KdZwgHK3UgfmwvUdgMAAAAJJUVoZGoykN+2dejEgAAABaCx/22Q0KHI0WSPlfGD675ygkI8cucf4OWGjEMAAAAtYyMUIbDIrbfDcw8EgAAAJtH8qoZ3WGX5UHVMPEqRH7o2QoJyxrVvvHGp5EMAAAAjnxdkp6Fe9eYyStgEgAAAHSoMIrnPwA4i/TEPljG1QhjIgsK1 GCQKTz4h5wMAAAApr+f0IDt9EHMFAtaEgAAAMT6oKnauwwSXAj4iurN+c+KlQwLrlsrEKVNEscMAAAAoPmAawk6P+ytbL/lEgAAAG7M98uIQPndvPuucic+GGRw1Q0MOye62O0UIl8MAAAABMo9hMlMyLVVpbc7EgAAAIBDQTOsRVfOcSo1A4kog3t0Rw4NgATaFGgEQssMAAAABrkOqh oj8/Fh/zwUEgAAAKRWCvWOfAY1YHqcv4bT6vNFXA8OYpcR6aGZXrIMAAAAou0bHXYCcP1Oda6zEgAAAMEbmEJHrbkBc6RROOms3yfn/BAPPHp+uD0Fj/UMAAAAfh9ozq+d0WAU3NIqEgAAAIOsF+BevptAjC/KJ6bAqULqzxEQm97lECSQ1KkMAAAAwXRrowTsCkvIw2c+EgAAALPoV4P U3Na23wYJ0Vi4+cHlLBIRQ3Fe07B1GgMMAAAAi+/vmvAilXSN9YfwEgAAAGomoZF0Rovja0NSpqj1HB3O3BcSMw8SUEn/glYMAAAAsj3t2hdkhW5+Q7aMEQAAAO/HChNy9yxhIMUmXa+dnjDMEwIEy8d5MPQrhQwAAABVPJEJJb0v0CAK9RQSAAAAz7Vu77foUJQe+cVM8xU2RZ0bFBPB A3zMkmtDdQwAAAAQ2V83qXnS+fkngOMSAAAAMTqvgWoF1Sso4Ii4GWE+t/k3FRQTo5MILTMLmAwAAAAe3iFgr40QOc5nNIcSAAAAG7DPdGB3zXTi22tFa4ye2DNLFhV1G3LSX6MeGQwAAAAX9cYcormGhDTMrx0RAAAAtOBs7e+XQS4gHmNwV43c+gU= | 2026-02-11 20:59 |
| Impossible PatchingMe V2 | patch 1 va 0x1400022cb old bytes --> 84 c0 new bytes --> b0 01 this makes status always ok for any input after that patch, the program reaches success path. but payload can appear blank so we patch the payload pointer patch 2 va 0x140002372 old rel32 --> d6 84 05 00 new rel32 --> 3a 85 05 00 this changes lea rdx, [rip + disp32] to point at the long payload blob at 0x14005a8b0 | 2026-02-11 20:56 |
| Impossible PatchingMe V2 | i dont understand... getting the software to print status ok is a matter of doing 2 patches | 2026-02-11 20:54 |
| Lugosi's CrackMe II | nevermind... i can kinda force "OK" but my method needs still some serious work | 2026-02-10 10:46 |
| Lugosi's CrackMe II | can you provide a valid name/serial pair? this crack me appears mathematically unsatisfiable/impossible to solve. | 2026-02-10 09:20 |
| Continental | dm me on discord if you want some help (@djd320) | 2026-02-10 06:22 |
| Find the correct key! | after some static analysis im now even more confident its legit | 2026-02-02 20:46 |
| Find the correct key! | I am pretty sure it is not malware. check-keys.exe is UPX packed and likely triggered the detection. | 2026-02-02 20:37 |
| Froggy CracMe | Name / Handle: djd320 Serial: 6579BE7D-A0DBF5E5-4C6D8825-426C0AAE | 2026-02-02 19:13 |
| TryHard crackme with password | there's a fundamental flaw cause the password is embedded in .rdata (ascii+utf32) and the character checks read it directly, so the vm/hash layers are mostly decorative. writeup coming soon. | 2026-01-31 08:01 |
| weird but easy | this is probably a 3.5-4.5 id say. for sure not a 2 | 2026-01-31 07:08 |