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)