| 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 |