Number of crackmes:
Number of writeups:
Comments:
| Name | Author | Language | Arch | Difficulty | Quality | Platform | Date | Downloads | Writeups | Comments |
|---|
| Crackme | Date | Infos | Actions |
|---|---|---|---|
| TryBypassMe Kernel Edition | 2026-04-30 20:25 | View | |
| MCM 6.0 - Project Mayhem | 2026-04-19 21:02 | You can study the internal crackme algorithm in detail by referring to the attached PATCH.py script | View |
| ASCII_CRACK | 2026-03-06 07:41 | View |
| Crackme | Comment | Date |
|---|---|---|
| TryBypassMe Kernel Edition | @crackthiscrackthat I patched the section of the existing driver responsible for handle stripping. | 2026-05-01 06:03 |
| TryBypassMe Kernel Edition | @0xGroot, @crackthiscrackthat. I think the problem is with the handle stripping performed by the driver. In my solution, I disabled handle stripping, and this might help you. Use my version of the driver included with writeup. | 2026-04-30 20:29 |
| TryBypassMe Kernel Edition | writeup uploaded | 2026-04-30 20:26 |
| MCM 6.0 - Project Mayhem | @CrackNotMe Thanks, bro! That was exciting!) | 2026-04-20 14:27 |
| MCM 6.0 - Project Mayhem | @CrackNotMe Hello. Sure. But I don't know yet if I'll have free time for that)) | 2026-04-20 10:59 |
| MCM 6.0 - Project Mayhem | writeup uploaded | 2026-04-19 21:03 |
| MCM 6.0 - Project Mayhem | [Click to reveal]@CrackNotMe It turns out I shouldn't have neglected the part of the code containing the emulator lol. It is now implemented in my script as well. I need to brute-force it again. Could you give me a hint? Am I correct in assuming that the key should be in the format `MCM6{%08X}`? From MCM6{00000000} to MCM6{FFFFFFFF}. Otherwise, the brute-force process would take forever. | 2026-04-15 00:32 |
| MCM 6.0 - Project Mayhem | [Click to reveal]I've completely restored the password verification algorithm. Wrote a brute-force utility, but so far all I've gotten is warm air from processor. Figuring out code optimizations.))) | 2026-03-31 01:03 |
| MCM 6.0 - Project Mayhem | @CrackNotMe I hope I will have enough time for this) | 2026-03-18 00:43 |
| MCM 6.0 - Project Mayhem | [Click to reveal]color (6-1)*2 | 2026-03-17 18:39 |
| MCM 6.0 - Project Mayhem | [Click to reveal]Okay. I will look into the memory watchers, hashes, tsc's, and ud's. But there's so much going on there((( | 2026-03-14 22:20 |
| MCM 6.0 - Project Mayhem | The message was green. There were also some unprintable characters at the bottom. Apparently some kind of bug ((( | 2026-03-14 21:34 |
| MCM 6.0 - Project Mayhem | [Click to reveal]Looks like I'll have to deal with the HASH | 2026-03-14 21:19 |
| MCM 6.0 - Project Mayhem | It's strange. The first time this key accepted. And then he writes "ACCES DENIET" | 2026-03-14 21:11 |
| MCM 6.0 - Project Mayhem | [Click to reveal]KEY IS MCM6_LWE_V2 | 2026-03-14 21:00 |
| MCM 6.0 - Project Mayhem | [Click to reveal]The word OtsosiPenis doesn't seem like a possible solution )). | 2026-03-11 07:49 |
| MCM 6.0 - Project Mayhem | [Click to reveal]SMC_T | 2026-03-09 11:07 |
| MCM 6.0 - Project Mayhem | [Click to reveal]@CrackNotMe A little. I got a dump. I see some work with environment variables and reading and writing the debugged process's memory. But the functions are heavily obfuscated, and it's hard to find the relevant section of code. More time needed | 2026-03-09 07:07 |