| Easy Crackme For Beginners |
I recovered a VM-accepted key:
'#P*AAAAAAAAAAAAAAAAAAA
But when the program is run normally on my Windows VM, it does not print [+] helal bro.. It crashes first.
The issue is in the custom VM. For any 23-byte input, the doubly decoded VM bytecode begins with:
01 fe xx xx xx xx
That dispatches to the VM “load immediate” handler and executes effectively:
mov dword ptr [vm_state + 0xfe * 4], imm32
In my crash dump, this faulted at:
RIP: 0x422555
Instruction: mov dword ptr [rax+rdx*4], ecx
RAX: 0x006ffd90 ; vm_state
RDX: 0xfe
Target address: 0x00700188
StackBase: 0x00700000
Exception: C0000005_ACCESS_VIOLATION
So the VM writes far outside its intended state/register area. On this environment, that lands just above the thread stack and hits unmapped memory before the success branch can print.
To prove the key path, I did not patch the executable. I launched the original program suspended, reserved the page above the child thread’s stack with VirtualAllocEx, then resumed it. With that page mapped, the same key reaches the VM
halt path and prints:
[+] helal bro.
So the key logic is recoverable, but normal execution is blocked by an out-of-bounds VM state write that appears to depend on stack layout. Unless this is some trap setup and I'm falling for it! |
2026-06-26 01:51 |
| Easy Crackme For Beginners |
Actually, i don't think its right. Disregard!~ I'm unable to delete my previous comment.
|
2026-06-26 01:39 |
| Easy Crackme For Beginners |
'#P*AAAAAAAAAAAAAAAAAAA |
2026-06-26 01:34 |