Log in

View Full Version : CRC_DRx crackme


evaluator
August 31st, 2008, 11:09
ROSASM burnt yet another cr0ckme mit SRC!

kill yO-self now! ~ = D

edit:
who will BRUTE, will LEAST PENsIL..

pnluck
September 11th, 2008, 16:26
Avira reports it as a generic virus.

evaluator
September 12th, 2008, 08:34
you should be banned for that Avira!

andrewl
November 29th, 2008, 03:35
Nice crackme! You made so much trouble in such a small exe!

evaluator
November 29th, 2008, 07:57
you kill me ((:

but remember! if you did brutus, then you killed yourself! (read first post)
so i'm waiting for your paper on solution.. how you guess/find/logic/

PS:
should this solution treated as 2 man works!? (you + JoKa)

andrewl
November 29th, 2008, 14:13
No, you killed my time.

There were other techniques tried also. To overwrite SEH. To make
GetExitCodeThread() fail. To overwrite stack so that arg to
WaitForSingleObject() and GetExitCode() causes return value of 0.
Your comment of "here i kill Z-flag, which was from XOR EDX EDX..
U'r move!" made me look at onBP for a long time, since it zeroes
EDX. The onTRAP cleared ECX, so I was distracted for a long time
to somehow control "add ecx, esi" at 4030C5. The fact that both
onBP and onTRAP increment EIP by one made me try to find a
vulnerable 1-byte instruction. It was frustrating that elast
clears all DRx before calculating ECX for main thread.

Finally I gave up with HW BP in exception handler (some values
can crash crackme very well). This leaves actually only four
possible instructions to target:

Code:

UD2 <-- onUD2 sets DRx
UDpl: L2:
add D$edx ebp
loop L2
mov ebp D$edx <-- elast clears DRx
Correct location is "mov ebp D$edx".

Code:

004030bf 012a add dword ptr [edx],ebp
004030c1 e2fc loop image00400000+0x30bf (004030bf)
004030c3 8b2a mov ebp,dword ptr [edx] <--- HW BP here
004030c5 03ce add ecx,esi invokes onTRAP
004030c7 648b22 mov esp,dword ptr fs:[edx]
004030ca 648f02 pop dword ptr fs:[edx]
004030cd 740c je image00400000+0x30db (004030db)
onTRAP does ECX=0, ZF=1, EIP++

Code:

004030c4 2a03 sub al,byte ptr [ebx]
004030c6 ce into <--- invokes onTRAP
004030c7 648b22 mov esp,dword ptr fs:[edx]
004030ca 648f02 pop dword ptr fs:[edx]
004030cd 740c je image00400000+0x30db (004030db)
onTRAP entered with EIP=4030C7 does ECX=0, ZF=1, EIP++

this skips the "64" prefix for fs:[edx] (no AV) and makes it
[edx] (AV with edx=0)

Code:

004030c8 8b22 mov esp,dword ptr [edx] <--- invokes elast
004030ca 648f02 pop dword ptr fs:[edx]
004030cd 740c je image00400000+0x30db (004030db)
elast does EIP+=2 and execution continues at 4030ca. ZF=1 so je taken.

evaluator
November 30th, 2008, 15:02
>>The fact that both onBP and onTRAP increment EIP by one made me try to
>>find a vulnerable 1-byte instruction.

OK, accepted your finding.

IMHO logic must look so:
1) if calculation happens in DRx, so HW_BP occurence can be guess;
2) SEH_handler code has not strong check for ERR-code!
3) +1 reg.EIP (you guess)