Score:
Number of crackmes:
Number of writeups:
Comments:
| Name | Author | Language | Arch | Difficulty | Quality | Platform | Date | Downloads | Writeups | Comments |
|---|
| Crackme | Date | Infos | Actions |
|---|
| Crackme | Difficulty | Points | Date |
|---|---|---|---|
| AegisShield | 4.96 | 496 | 2026-10-20 16:16 |
| LvArshu (Flag) | 4.13 | 413 | 2026-10-16 08:44 |
| BabyDotNet | 1.0 | 100 | 2026-10-10 11:15 |
| My Third Crackme (Medium + Flag) | 2.5 | 250 | 2026-10-10 00:11 |
| My Second Crackme (Easy + Flag) | 2.0 | 200 | 2026-10-09 22:45 |
| Orbit Fold | 2.0 | 200 | 2026-09-27 20:31 |
| trust me this is really easy :) | 1.0 | 100 | 2026-09-24 06:16 |
| Crackme | Comment | Date |
|---|---|---|
| VSEC Challenger Num #3 | Just for a point of reference, it wasn't Denuvo (which is my habit), but still fun and interesting challenge. The actual foe here was the funnel, which happens less often than you'd think. Glad I took the plunge. | 2026-10-20 21:12 |
| VSEC Challenger Num #3 | Good challenge, the funnel was so much fun! | 2026-10-20 16:24 |
| VSEC Challenger Num #3 | Heh, so much for my idea of the threat-model. Closed protection. Decode VM, dump bytecode, build the funnel, show non-invertibility of the funnel. Of course, it never actually occurred to me that the bug is the feature and I had the interpreter as adversary (not as a puzzle with a seam). If the intended solve is control-flow patch in bytecode, then the lock was a seam and that's a prettier break. No quibble. However, see the tension I have to point at. Before it was 'don't modify the file, find the key' rules, now 'patch the VM' is the intended path. Yes, it's still a patch. A control-flow patch. It gets the check through without generating the key. Same genus to my native verdict-forge. One higher abstraction level. If that counts as solve. So does mine. Or, if it doesn't then your bug doesn't do "recover the key" either, unless it spills. | 2026-10-19 23:42 |
| VSEC Challenger Num #3 | Sure thing, let's keygen this. It's your 24 chars (192 bits), hashing into three 64-bit chunks, hashing your 3x64 bits into a funnel (the preimage of your key), pounding them through the sponge with 32 rotators on a mix (32 times), 7 stages of a shifter, using that thing 77 times to apply the hash, finally comparing a 64-bit number. Your key? That's the only place it's found. Get it out of there. Fun times ahead. No algebra (too bad), H1 is not affine (in all its arguments), and, oh, you're so nice enough to make the wrapper steps invertible, but not the combines. No replaying the hash (and why would you?), the hash is seeded based on the stack address of your argument slot in the hash. Powered by a callback that pops stuff you can't see. And there's 16K of state. And it doesn't quite reset. You don't get boom, you get "right" wrong things. With confidence. So, you do brute force. 64bit constraint, that's about 2^128 keys could work. 2^64 tries to find. At your measured 6.4 seconds per candidate? That's 3.7trillion years. At (get it out of your head) one millisecond per candidate... 580 million years. About 42 universes old. I'll give you the first try for free. Took an evening for the 19-byte verdict patch. Hows your calendar? | 2026-10-19 02:28 |
| VSEC Challenger Num #3 | Your heart is blessed. Because, the key is never in the binary, not in cleartext, nor obfuscated nor even XOR'd in a corner. It is present in only a single place, the output of a 77-round sponge applying 32 rotating mix-iterations and a 7 stage shift register, and it compares the result with binary, not input. So, go ahead, look it up in the hash, because it's not in clear text and brute-forcing blindly will take you years. And, "analyze virtual machine"? I did. I decoded interpreter, dumped the bytecode, reconstructed and validated 77/77 an entire pipeline of input -> sponge -> compare. That's not the part that I skipped. That's the part that proved your prescribed way is dead. The 19 byte verdict patch is what you provide when the intended method is proven infeasible, and you left a boolean in plaintext memory as your gate. 154 downloads. 5 comments (2 from you, 2 from me, 1 from the poor sucker you shoved into this mess), not a single solution submitted. 0 people found your key. When all 154 attempts end in "This can't be done as specified" the constant in that equation isn't my approach. Fine, rules that require key. You're describing an unfinished challenge. That nobody completed. Including apparently you. | 2026-10-19 01:43 |
| VSEC Challenger Num #3 | So rule out brute-force attacks. | 2026-10-18 01:33 |
| VSEC Challenger Num #3 | Enter the VSEC SECRET PassKey : 1 ACCESS GRANTED (program exited with 0) Simply patched it. Regardless, it is not saved anywhere. I decrypt every string, including the entirety of main, during runtime, and the key is never compared as plain text. The only comparison performed is a single 64-bit equality check between the final output of a 77-step hash chain and 0x487d2ace0cb951fa. The input is compressed from 192 bits to 64 bits through a sponge. The 24 characters become three 64-bit chunk hashes, are folded into V_A/V_B/V_C, and then pass through 32 rotating mix iterations (V2..V63) and a 7-stage shift register before the check. Based on the prior algebraic probes, my script found H1 to be non-affine in every argument, indicating that the sponge is a one-way compression rather than a solvable system. | 2026-10-18 01:10 |
| Tropical | [Click to reveal]serial: 5242b75304439277 LOCKED: True critical grapheigevector5242B75304439277locked | 2026-10-06 02:41 |
| Tropical | [Click to reveal]@memetic0 serial: 5242b75304439277 | 2026-10-06 02:08 |