Profile

Crackme	Date	Infos
CrackMeBaby2	2026-06-09 12:36	Writeup attached as Markdown file.
Hard CME	2026-06-08 13:35
Hard CME 2	2026-06-08 13:21
JavyFlag	2026-06-08 12:50
selfkey	2026-06-08 10:27
FirstCrackMe	2026-06-08 10:04
winkeygenme	2026-06-08 09:56
NiTiNOL CrackMe	2026-06-08 09:45
Jörmungandr	2026-06-08 08:44
ASMe \| ASM CrackMe	2026-05-14 10:53

Crackme	Comment	Date
CrackMe#1	Correct password: crackmes Logic `main` is at `0x140001f90`. Important blocks: - `0x140001fcc` and following: direct PEB checks. If debugger state is visible, the program changes the character seed and appends decoy bytes. - `0x14000205d`: calls `IsDebuggerPresent`. - `0x14000207a`: tests the result. If no debugger is reported, it jumps to an early termination path at `0x14000228c`. - `0x14000213a`: writes the encoded constant bytes: ```text 3e 2f 3c 3e 36 30 38 2e ``` - `0x140002150` to `0x1400021a1`: loops over those bytes and XORs each with the seed byte. - `0x1400021c5` to `0x1400021d0`: compares the generated string length and bytes against the entered password. - `0x1400021d9`: success path prints `Success!`. - `0x1400021e2`: failure path prints `Fail!`. When the direct PEB checks are not tripped, the seed byte is `0x5d`. Decoding is: ```text 3e 2f 3c 3e 36 30 38 2e xor 5d = 63 72 61 63 6b 6d 65 73 = crackmes ``` If the program sees a normal debugger through the PEB checks, it changes the seed to `0x6d` and inserts extra `0x14` bytes. That produces a misleading debugger-only comparison target	2026-05-14 10:40
Find the decryption key \| Custom packer,no virtualization #2	# deo packer test #2 findings Sample: - Archive: `C:\Users\Gebruiker\Downloads\6a00b3533fba64e45dceaa2d.zip` - Extracted PE: `agesa113377.exe` - SHA-256: `3906C49A30719DC4793D5A1B2C1AB49322BA59A1DC916CAD6FAB1FE930319B1B` - PE64, image base `0x140000000`, entry `0x140048000` Answer: - Key: `x9K!7zPq4mNvR2bL` - Flag printed by the program: `FLAG{p3Wq8RnZmK4vYxT7Bc2J}` Verification: ```text stdout: '=== elevenpack crackme ===\nEnter password: [+] FLAG{p3Wq8RnZmK4vYxT7Bc2J}\n' ``` Packer observations: - The on-disk PE has no normal import table and adds custom sections `.elpk`, `.elst`, `.eldat`. - Entry point is in RWX `.elst` at `0x140048000`. - The stub allocates an RWX private region with `VirtualAlloc(NULL, 0x5698, MEM_COMMIT\|MEM_RESERVE, PAGE_EXECUTE_READWRITE)`. - Under x64dbg MCP, the allocation returned `0x7a0000`; that region contained unpacked code and generated syscall/API thunks. - After a dummy password, the original program strings are visible in memory for several seconds, including: - `=== elevenpack crackme ===` - `Enter password: ` - `[+] %.*s` - `[-] internal: flag sentinel mismatch` - `[-] wrong password` - This confirms the stated weakness: a wrong input is enough to expose decrypted validation material in memory before wiping. Validation logic: - Main logic is restored at `0x140001650`. - Input is read into a stack buffer, CR/LF is stripped, and the final key length must be `0x10`. - It builds a ChaCha20 block from exposed static material: - 32-byte key at `0x140018370`: `9f42b71e88c305772ae910d64b336ca1580fe2957144be29cd83166fb007d852` - 12-byte nonce at `0x140018390`: `112233445566778899aabbcc` - counter `0` - It initializes a 16-byte encrypted expected-key buffer: `ceda634e735f802aa9d511adf14f31dd` - It XORs the first 16 ChaCha20 keystream bytes: `ec0e92e25e08aa9647d565d639d0a9dc` - It then XORs a fixed 16-byte mask: `5aedba8d1a2d7acdda6d3a0d9aadfa4d` - Resulting required key: `x9K!7zPq4mNvR2bL` Weaknesses useful for hardening: - The unpacked code and strings are recoverable from memory immediately after any password attempt. - The real validation routine is restored in the original image layout and can be dumped page-by-page. - The key derivation constants and ChaCha20 key/nonce are static and visible after unpacking. - The password check is a direct 16-byte comparison against a derived constant, so once the transient decrypted image is captured, the correct input is recoverable without brute force. - RWX allocation and generated executable private pages make the unpacking boundary easy to identify dynamically.	2026-05-14 10:26
NightMare 2.0	Not possible to solve, - 0x140002B44: reads secret.bin - 0x140002B94: calls 0x140004930 - 0x140004930: reads secret.key - 0x1400049DD: requires key length > 31 - 0x140004A1B: copies exactly 32 bytes from the loaded key buffer - 0x140002BF3: initializes AES-256-GCM with that 32-byte key - 0x140002D28: performs AES-GCM decrypt - 0x140002D2D: if success, plaintext pointer is in RAX, length in RDX - 0x140002DB9: failure path prints Access denied. So with only crackme.exe, run.bat, and this secret.bin, the plaintext is not recoverable. The missing 256-bit random key is not derivable from the available files you need a runtime where the original secret.key is present or already loaded.	2026-05-14 02:26
NeuroVault	Valid serial: NV-4E563031-VAULT The checker requires the format NV-XXXXXXXX-VAULT, where the middle 8 characters are uppercase hex. The protected VM validates the decoded bytes with these constraints: byte0 + byte1 = 0xA4, byte2 xor byte3 = 0x01, rol(byte0, 4) = 0xE4, byte1 * byte2 = 0x20, and byte3 - byte0 = 0xE3. 4E563031 satisfies all of them.	2026-05-14 01:53
KeygenMe_3_SWD	For username NiceCrackMe: Secret code : 0E95-02OZ2-3PT Verification PIN : 1200406703	2026-05-08 17:05
VaultBreaker	Encoded bytes: 15 2a 69 34 09 69 29 3b 37 3f XOR with 0x5a gives: Op3nS3same	2026-05-08 01:10

CrackMe#1

Correct password: crackmes Logic `main` is at `0x140001f90`. Important blocks: - `0x140001fcc` and following: direct PEB checks. If debugger state is visible, the program changes the character seed and appends decoy bytes. - `0x14000205d`: calls `IsDebuggerPresent`. - `0x14000207a`: tests the result. If no debugger is reported, it jumps to an early termination path at `0x14000228c`. - `0x14000213a`: writes the encoded constant bytes: ```text 3e 2f 3c 3e 36 30 38 2e ``` - `0x140002150` to `0x1400021a1`: loops over those bytes and XORs each with the seed byte. - `0x1400021c5` to `0x1400021d0`: compares the generated string length and bytes against the entered password. - `0x1400021d9`: success path prints `Success!`. - `0x1400021e2`: failure path prints `Fail!`. When the direct PEB checks are not tripped, the seed byte is `0x5d`. Decoding is: ```text 3e 2f 3c 3e 36 30 38 2e xor 5d = 63 72 61 63 6b 6d 65 73 = crackmes ``` If the program sees a normal debugger through the PEB checks, it changes the seed to `0x6d` and inserts extra `0x14` bytes. That produces a misleading debugger-only comparison target

2026-05-14 10:40

Find the decryption key | Custom packer,no virtualization #2

# deo packer test #2 findings Sample: - Archive: `C:\Users\Gebruiker\Downloads\6a00b3533fba64e45dceaa2d.zip` - Extracted PE: `agesa113377.exe` - SHA-256: `3906C49A30719DC4793D5A1B2C1AB49322BA59A1DC916CAD6FAB1FE930319B1B` - PE64, image base `0x140000000`, entry `0x140048000` Answer: - Key: `x9K!7zPq4mNvR2bL` - Flag printed by the program: `FLAG{p3Wq8RnZmK4vYxT7Bc2J}` Verification: ```text stdout: '=== elevenpack crackme ===\nEnter password: [+] FLAG{p3Wq8RnZmK4vYxT7Bc2J}\n' ``` Packer observations: - The on-disk PE has no normal import table and adds custom sections `.elpk`, `.elst`, `.eldat`. - Entry point is in RWX `.elst` at `0x140048000`. - The stub allocates an RWX private region with `VirtualAlloc(NULL, 0x5698, MEM_COMMIT|MEM_RESERVE, PAGE_EXECUTE_READWRITE)`. - Under x64dbg MCP, the allocation returned `0x7a0000`; that region contained unpacked code and generated syscall/API thunks. - After a dummy password, the original program strings are visible in memory for several seconds, including: - `=== elevenpack crackme ===` - `Enter password: ` - `[+] %.*s` - `[-] internal: flag sentinel mismatch` - `[-] wrong password` - This confirms the stated weakness: a wrong input is enough to expose decrypted validation material in memory before wiping. Validation logic: - Main logic is restored at `0x140001650`. - Input is read into a stack buffer, CR/LF is stripped, and the final key length must be `0x10`. - It builds a ChaCha20 block from exposed static material: - 32-byte key at `0x140018370`: `9f42b71e88c305772ae910d64b336ca1580fe2957144be29cd83166fb007d852` - 12-byte nonce at `0x140018390`: `112233445566778899aabbcc` - counter `0` - It initializes a 16-byte encrypted expected-key buffer: `ceda634e735f802aa9d511adf14f31dd` - It XORs the first 16 ChaCha20 keystream bytes: `ec0e92e25e08aa9647d565d639d0a9dc` - It then XORs a fixed 16-byte mask: `5aedba8d1a2d7acdda6d3a0d9aadfa4d` - Resulting required key: `x9K!7zPq4mNvR2bL` Weaknesses useful for hardening: - The unpacked code and strings are recoverable from memory immediately after any password attempt. - The real validation routine is restored in the original image layout and can be dumped page-by-page. - The key derivation constants and ChaCha20 key/nonce are static and visible after unpacking. - The password check is a direct 16-byte comparison against a derived constant, so once the transient decrypted image is captured, the correct input is recoverable without brute force. - RWX allocation and generated executable private pages make the unpacking boundary easy to identify dynamically.

2026-05-14 10:26

NightMare 2.0

Not possible to solve, - 0x140002B44: reads secret.bin - 0x140002B94: calls 0x140004930 - 0x140004930: reads secret.key - 0x1400049DD: requires key length > 31 - 0x140004A1B: copies exactly 32 bytes from the loaded key buffer - 0x140002BF3: initializes AES-256-GCM with that 32-byte key - 0x140002D28: performs AES-GCM decrypt - 0x140002D2D: if success, plaintext pointer is in RAX, length in RDX - 0x140002DB9: failure path prints Access denied. So with only crackme.exe, run.bat, and this secret.bin, the plaintext is not recoverable. The missing 256-bit random key is not derivable from the available files you need a runtime where the original secret.key is present or already loaded.

2026-05-14 02:26

NeuroVault

Valid serial: NV-4E563031-VAULT The checker requires the format NV-XXXXXXXX-VAULT, where the middle 8 characters are uppercase hex. The protected VM validates the decoded bytes with these constraints: byte0 + byte1 = 0xA4, byte2 xor byte3 = 0x01, rol(byte0, 4) = 0xE4, byte1 * byte2 = 0x20, and byte3 - byte0 = 0xE3. 4E563031 satisfies all of them.

2026-05-14 01:53

KeygenMe_3_SWD

For username NiceCrackMe: Secret code : 0E95-02OZ2-3PT Verification PIN : 1200406703

2026-05-08 17:05

VaultBreaker

Encoded bytes: 15 2a 69 34 09 69 29 3b 37 3f XOR with 0x5a gives: Op3nS3same

2026-05-08 01:10

crackmes.one

crackmes.one

SingleJingle11's profile

0

10

6

Crackmes

Writeups

Comments