Number of crackmes:
Number of writeups:
Comments:
| Name | Author | Language | Arch | Difficulty | Quality | Platform | Date | Downloads | Writeups | Comments |
|---|
| Crackme | Date | Infos |
|---|---|---|
| crackme_3 by br0ken | 2026-04-14 07:00 | gold metdal |
| very easy crack me $$$ by whekkees | 2026-04-12 18:56 | Original Login: whekkes Original Password: qwerty |
| Crackme | Comment | Date |
|---|---|---|
| Acid's First Crackme | 1. Анализ защиты При запуске программа запрашивает пароль. Первичный анализ в IDA Pro показал, что в коде присутствует мощная система привязки к железу (HWID). Программа считывает MachineGuid из реестра (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography) и использует библиотеку bcrypt.dll для работы с хешированием SHA256. 2. Поиск реального пароля Я детально изучил функцию sub_1400105A0, которая отвечает за подготовку секретных данных. В ней я обнаружил три зашифрованных куска строк, которые расшифровываются с помощью операции XOR с ключом 90 (0x5A): Кусок 1: ")?9" ^ 90 = sec Кусок 2: "(?." ^ 90 = ret Кусок 3: "khi" ^ 90 = 123 Сложив их вместе, я получил строку secret123. Несмотря на наличие сложного кода, который смешивает эту строку с моим MachineGuid и вычисляет SHA256 хеш, глубокий анализ функции сравнения sub_140010660 показал, что автор оставил «логическую лазейку». Вся криптографическая надстройка служит лишь ширмой — программа принимает чистый расшифрованный секрет как валидный вход. Верный пароль для входа: secret123 3. Процесс патчинга (Bypass) Для полного обхода системы защиты я проанализировал основной блок функции main_0. Проверка пароля завершается вызовом функции sub_140005164, результат которой определяет, будет ли предоставлен доступ. Код в IDA: asm call sub_140005164 ; Вызов проверки movzx eax, al ; Сохранение результата test eax, eax ; Проверка: 0 или 1? jz short loc_14001086A ; Прыжок на "Access denied", если 0 Use code with caution. Я выполнил патч, нейтрализовав условный переход: Перешёл по адресу инструкции jz (0x140010868). Заменил байты инструкции 74 06 на 90 90 (команды NOP). После внесения изменений программа игнорирует введённый текст и всегда выводит сообщение "Access granted". 4. Заключение В ходе исследования я установил, что использование HWID и SHA256 в данном CrackMe является «ложным следом» (Red Herring), предназначенным для отвлечения внимания реверсера. Я успешно нашёл оригинальный пароль путём статического анализа XOR-алгоритма и реализовал патч для полного обхода проверки. | 2026-04-13 17:25 |
| very easy crack me $$$ by whekkees | 1. Original Credentials By analyzing the source code (decompiled C++), we identified the hardcoded strings used for validation: Original Login: whekkes Original Password: qwerty 2. The Logic The program protected the "success" message using two layers of checks for both the login and the password: Length Check: It compares the length of your input with the hardcoded string length. Content Check: It uses memcmp to verify if the actual characters match. If either check fails, the program executes a conditional jump (jnz — Jump if Not Zero) to a failure block, skipping the success message. 3. The Crack Methodology To "crack" the binary, we modified its assembly logic to make the checks irrelevant: Identify the Jumps: We located the jnz instructions following the cmp (length) and test (memcmp result) operations. NOP Patching: We replaced these jump instructions with NOP (0x90 — No Operation). This forces the CPU to ignore the "failure" path and proceed directly to the next instruction. Automation: We used an IDC script to automatically scan the main function and neutralize every conditional jump, effectively removing all security barriers at once. 4. Final Result By applying these patches to the .exe file, the program now accepts any login and any password, immediately displaying the message: Nice job bro. | 2026-04-12 18:54 |
| Challenge #13 | 1. Finding the Lead I opened the file in IDA Pro and immediately checked the strings using Shift+F12. I found "Correct Flag!" because it was the fastest way to reach the target. I double-clicked the string and used X (Xrefs) to jump directly into the code where it is called. 2. Analyzing the Logic I switched to Graph View (Space) to clearly see where the program branches off. I identified the sub_1400CAEC0 function and pinpointed the "decision node" — the block that determines whether to show the success window or the "Wrong!" message. 3. Locating the Check I saw that everything starts with a length check: jz short loc_1400CAFAC. I realized that if I enter the wrong number of characters, the program doesn't even reach the actual password comparison. 4. The Patch I decided not to waste time brute-forcing the password and simply rewrote the program's code to suit my needs. Using the Assemble tool, I replaced the conditional jump with an unconditional jmp loc_1400CAFC4. With this command, I forced the program to go straight to "Correct Flag!", ignoring all checks entirely. 5. Applying the Patch I saved the changes directly into the .exe file using Apply patches to input file so the crack would work outside of IDA. 6. The Result I ran the file, entered a random letter, and got my "Correct Flag!" window. I successfully hijacked the control flow and neutralized the protection. Summary: I identified the success string, traced it back to the validation routine, and manually hijacked the control flow by patching a conditional jump into an unconditional jump. I bypassed the entire security check and forced the application to accept any input as a valid flag. | 2026-04-12 09:03 |
| Very Easy CrackMe | CrackMe Bypass Report Target: Local authentication bypass in a PE64 executable. Password Found: 1ecc7dd7b9763028e119e5046268d922 (located via static analysis in .rdata). Vulnerability: A conditional jump (JNZ) that redirects execution to an error block if the password comparison fails. The Fix (Patch): Located the opcode 75 (JNZ) at the critical branching point. Inverted the logic by patching it to 74 (JZ). Outcome: The security check is neutralized. The program now accepts any incorrect input as valid, while the original password now triggers the "Nope" message. | 2026-04-12 08:15 |
| Easy Crackme | 1. Code Analysis Upon analyzing the main function, I found that the program collects a username and password but only validates the password. The password is not stored as a plain string; instead, it is constructed on the stack byte-by-byte (at Buf2) using constant values (0x546333454B657076LL and 0x3935). 2. Validation Logic The program uses a boolean flag in the AL register to determine success: It first checks if the input length is exactly 0xA (10 characters). Then it performs a memcmp between the user input and the stack-constructed password. If both checks pass, AL is set to 1. Otherwise, it is XORed to 0. Finally, a cmovz instruction selects either "Correct password!" or "Wrong password!" based on the AL flag. 3. The Patch (Full Crack) Instead of finding the password, I decided to bypass the security checks entirely by patching the binary. I neutralized two conditional jumps (JNZ) that lead to the failure block (loc_14000140B). Patch Details: Location 1: The length check jnz short loc_14000140B was replaced with NOP (90 90). Location 2: The comparison check jnz short loc_14000140B (after memcmp) was also replaced with NOP (90 90). 4. Result By NOP-ing these jumps, the execution flow always reaches the mov al, 1 instruction. Consequently, the program accepts any password of any length as correct. Original Password (for reference): vpeKE3cT59 | 2026-04-12 06:51 |
| Very Easy CrackMe | 1. Initial Analysis By analyzing the main function in IDA Pro, I identified a standard password validation routine. The program takes user input (stored in Src) and compares it against a reference buffer (Buf2) using the memcmp function. Additionally, it validates the input length (Size) against the value stored in qword_140005058. 2. Locating the Reference Password Since the password wasn't initialized directly within main, I examined the cross-references (Xrefs) for the length variable qword_140005058. This led me to the function sub_140001380. 3. Static Analysis of the Initialization The function sub_140001380 acts as a constructor for the std::string object. Inside this function, a memcpy call was found copying a hardcoded constant string into the target buffer. No obfuscation or dynamic generation (like XOR or Base64) was applied to the string before comparison. 4. Conclusion The password is stored as a static constant within the string initialization routine, rather than being visible in the main function's immediate logic. Correct Password: 1ecc7dd7b9763028e119e5046268d922 | 2026-04-12 06:36 |