CrackNotMe's MCM 6.0 - Project Mayhem

Author:
CrackNotMe

Language:
C/C++

Upload:
2026-03-05 09:46

Download

Platform:
Windows

Difficulty:
5.8

Quality:
4.3

Arch:
x86-64

Downloads:
155

Size:
3.23 MB

Writeups:
0

Comments:
40

Description

⚠️ Note for Reviewer/Admin: This CrackMe uses a multi-process architecture where the main executable creates a child process under a disguised system-like name (e.g., placed in AppData with a name resembling a legitimate Windows service). This is part of the challenge's anti-analysis design and is the reason VirusTotal may flag Sigma rules such as "System File Execution Location Anomaly" and "Files With System Process Name In Unsuspected Locations". This behavior is intentional and purely local - the binary performs no network activity, does not access user data, and does not install persistence. Hello everyone, this is my (6)six CrackMe project. Goal: Find the original valid password. Writing a Keygen is highly encouraged. Patching is NOT the intended solution, as integrity checks and advanced protections are active. Note on Patching: You can patch it if you want, but keep in mind that a simple JNZ/JZ flip won't work here. You will need to spend a significant amount of time to make a working patch. Description: - No fancy protections, just basic anti-debugging methods ;) - There is a minor anti-patching protection (can be bypassed in 5 minutes). - A small custom packer is also implemented. - Trolling decoys are present to keep you entertained! - !!! NO commercial protectors (Themida/VMP/etc.) were used !!! Compatibility: - Tested and confirmed working on official Windows 10/11 (Builds 21H1, 24H2, and 25H2). - WARNING: The application might crash on custom/stripped Windows distributions (e.g., "Lite" or "Gaming" editions) due to missing or modified system components. This is not a bug in the CrackMe, but a limitation of non-standard OS builds.

Comments (40)
Writeups (0)

You must be logged in to post a comment

dumspirospera on 2026-03-05 15:44: i am new to crackmes sry i am strugling to solve this crack me i can;t bypass the anti debug any hint or help pls

CrackNotMe on 2026-03-05 15:47: @dumspirospera try to solve something easier, I think It's to hard for beginners yk

dumspirospera on 2026-03-05 16:38: [Click to reveal]

dumspirospera on 2026-03-05 16:39: i will try something else now and will try this one later

CrackNotMe on 2026-03-05 19:34: @dumspirospera sry I dont wanna hit your ego. Because It's real not "Easy" for "Beginners"

djd320 on 2026-03-05 21:41: 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

clutchy on 2026-03-06 14:47: i might have done it right ill try and post a solution

CrackNotMe on 2026-03-06 15:31: @clutchy make a writeup ;)

clutchy on 2026-03-06 15:44: i already did @CrackNotMe im just waiting now

CrackNotMe on 2026-03-06 15:56: @clutchy Oh okay, do you wanna contact discord with me? It's really interesting how you did that

clutchy on 2026-03-07 02:23: @CrackNotMe sure Clutchdig808339.

clutchy on 2026-03-07 03:50: @CrackNotMe its a lower case c mb

clutchy on 2026-03-07 12:57: @CrackNotMe whats your discord?

CrackNotMe on 2026-03-07 13:27: @clutchy my discord is pwn.by

dumspirospera on 2026-03-07 19:07: @clutchy pls bro send me the solution the curiosity got to my bones mk_show discord

CrackNotMe on 2026-03-07 19:37: @dumspirospera he did't cracked It. Im contacted with him

AI on 2026-03-07 22:13: [Click to reveal]

CrackNotMe on 2026-03-07 22:31: @AI Nice try, but your theory is 100% wrong. 😂 Both of those "tokens" are absolutely incorrect. There are no intermediate or resolved tokens here. The "runtime-dependent logic" you noticed is just the program intentionally feeding you randomized troll responses, fake flags, and fake delays whenever you enter a wrong password. You completely fell for the traps! Good luck finding the real path.

CrackNotMe on 2026-03-08 20:50: have progress guys ?

a.v.e.r on 2026-03-09 07:07: [Click to reveal]

CrackNotMe on 2026-03-09 09:44: [Click to reveal]

a.v.e.r on 2026-03-09 11:07: [Click to reveal]

CrackNotMe on 2026-03-09 11:38: [Click to reveal]

CrackNotMe on 2026-03-10 18:04: 10.03.2026 still not cracked

arasreal on 2026-03-10 23:22: 0xCC010558193FUNC1337 xD

arasreal on 2026-03-10 23:24: and "S4CaqeCret20MCM6"

arasreal on 2026-03-10 23:25: im cracked

arasreal on 2026-03-10 23:39: Try the password "aaaaaaaaaadsssssa" in the decrypted exe I sent.

arasreal on 2026-03-10 23:45: I started by listing all the functions in IDA and immediately noticed that the binary had zero imports, which told me everything was resolved dynamically. The function list showed a huge "start" function at 0x140007C70 spanning about 2 megabytes, along with around 40 smaller helper functions. I also noticed section names like .vmp0, .vmp1, .themida, .enigma1 which were clearly fake, put there to scare off beginners into thinking multiple protectors were applied. My first move was to search for readable strings in the binary. The regex search only returned "CrackMeByPwn.pdb" and "rMKey", nothing useful like "password" or "correct". So I shifted to decompiling the smaller functions one by one. I quickly identified the function at 0x140007BD0 as an FNV-1a hash function because of the characteristic constants 0x811C9DC5 (initial value) and 0x01000193 (prime multiplier), with a case-insensitive comparison that converts lowercase letters to uppercase before hashing. Another function at 0x140007900 turned out to be a PEB-walking API resolver that uses the FNV-1a hash to find exports by name hash instead of by string. I then computed FNV-1a hashes for common Windows API names using a Python script inside IDA. This let me map each helper function to the API it resolves. For example, I found that 0x4FF7FB75 is GetTickCount, 0x6D3D9A28 is Sleep, 0xD1AFE3BC is GetComputerNameA, 0xAC392D5A is ExitProcess, 0x38E87001 is VirtualAlloc, and so on. Some functions didn't have a hardcoded hash in their cmp instructions, so I had to look deeper into their code to find the actual comparison value. With the API map in hand, I went back to the start function and disassembled it from the beginning. The first hundred instructions showed it reading bytes from fake sections, storing the initial key 0x64FA4D94, and calling the anti-debug memory scanner. I traced the key variable through each check. After the anti-debug call, if it returns 0 (clean), no XOR happens. Then GetTickCount is called, Sleep(50) executes, GetTickCount is called again, and the delta is checked against 30ms and 5000ms bounds. In a normal run, the delta is around 50-60ms, so no XOR. GetComputerNameA succeeds on any real machine, and the function table lookup always picks index 1 which returns 0. So the key stays at 0x64FA4D94 throughout. The breakthrough came when I looked for cross-references to the HMAC-SHA256 function (0x1400068A0). I found it was called from 0x1401B3A85 inside the start function. I disassembled backwards from that address and found the decryption loop starting at 0x1401B3313. The code was straightforward despite the CFF obfuscation around it because the decryption itself wasn't flattened, it was inline. I could read the three decryption stages directly from the disassembly: first a subtract-and-XOR pass, then a Fisher-Yates shuffle seeded with the key via MSVC's LCG, and finally a 4-byte repeating XOR. To actually decrypt the embedded PE, I wrote a Python script inside IDA's scripting console. It read all 0x69600 bytes from 0x1402C7000, applied the three decryption stages using the key 0x64FA4D94, and checked if the result started with "MZ". It did. The first 16 bytes came out as 4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00, a perfectly valid DOS header. I saved the decrypted PE to disk and then extracted all ASCII strings from it. The string dump revealed everything. Among the standard C++ runtime strings and Windows API names, I found the crackme-specific strings: anti-debug taunts like "MCM v5.0 | Your breakpoints are cute", a fake flag format "[+] SUCCESS BUT NOT! Flag: MCM6{%08X}", and most importantly the password candidates "S4CaqeCret20MCM6" and "PwEedPasswordOtsosiPenis" sitting right next to each other in the .rdata section. The decrypted PE also imports ws2_32.dll and wininet.dll, confirming it does network-based validation. The whole process from opening the binary to finding the passwords took about 30 minutes of guided analysis using IDA's MCP tools.

CrackNotMe on 2026-03-11 06:49: @arasreal Hi arasreal! Nice try with unpacking the loader, but you didn't actually crack the CrackMe. Everything you described in your write-up (the 2MB Control Flow Flattening, FNV-1a hashing, anti-debug, Fisher-Yates + XOR decryption) is just the auto-generated unpacking process of my custom packer. You successfully bypassed the packer, but you completely missed the actual challenge. After dumping the internal executable, you just ran a strings search over the `.rdata` section. The "passwords" you found (`PwEedPasswordOtsosiPenis`, `S4CaqeCret20MCM6`, `0xCC010558193FUNC1337`, etc.) are blatant honeypots (decoys) that I deliberately put there to bait people who just search for plaintext strings without analyzing the core logic. The real core logic is entirely different, much more complex, and untouched in your analysis. Since the challenge remains 100% unsolved and the provided solution is just a list of decoy strings, I have contacted the Review Team to request the removal of this invalid write-up. Better luck next time!

a.v.e.r on 2026-03-11 07:49: [Click to reveal]

arasreal on 2026-03-11 16:15: at least i tried xD

a.v.e.r on 2026-03-14 21:00: [Click to reveal]

a.v.e.r on 2026-03-14 21:11: It's strange. The first time this key accepted. And then he writes "ACCES DENIET"

a.v.e.r on 2026-03-14 21:19: [Click to reveal]

CrackNotMe on 2026-03-14 21:32: @a.v.e.r nah, key is wrong..

a.v.e.r on 2026-03-14 21:34: The message was green. There were also some unprintable characters at the bottom. Apparently some kind of bug (((

CrackNotMe on 2026-03-14 21:46: @a.v.e.r The decryption keys likely broke early on. That "Success" output was just a decoy, but since the keys were already corrupted, the text ended up garbled. Basically, the app flagged you and corrupted the keys early. There's a 95% chance this is the case. To be 100% sure and give you a better answer, I'd need to check the code, as the architecture is pretty complex with tons of protections. But yeah, it's most likely exactly what I wrote above.

CrackNotMe on 2026-03-14 22:14: @a.v.e.r I checked the code and confirmed my words 100%. The string you found isn't the key. That "Success" output was just a decoy trap; because you were flagged and the keys were already corrupted, the text ended up garbled. Everything happened exactly as I thought.

a.v.e.r on 2026-03-14 22:20: [Click to reveal]

Show all spoilers

You must be logged in to submit a writeup

crackmes.one

crackmes.one

CrackNotMe's MCM 6.0 - Project Mayhem