1

I am debugging some quiz program called "abex crackme 1"

When I execute this program without debugging, it shows a simple message box, which reads "Make me think your HD is a CD-Rom"

After I click OK button, it smoothly works without any problem.

But when I debug this program, I am getting into endless loop.

The program code is like this: First, it calls some function from dll to initialize something. But I think it doesn't matter now.

And, It pushes some parameters and calls WinAPI function "MessageBox A" (see below) 5th line is what i am referring to When I tries to step over this Call instruction in ollydbg, a message box pops up. When I click OK button like i did, i can't escape some block of code(picture 2) Endless loop

I don't know why this is happening only when i am debugging.

Improve this question

1 Answer 1

Reset to default
3

Look closely at the code you're looping within: it uses the FS register in several places. Now, googling for "windows FS register" tells you that this holds the segment of the TIB for Thread Information Block. And the first entry in that block, at byte offset 0, has the address of the current SEH, Structured Exception Handler.

Your code above is writing to that SEH, so it's reasonable to assume (as this is within ntdll.dll) that this is the part of the kernel that processes (possibly nested) exceptions. Seems that your application somehow detects the presence of a debugger, and sets up a bogus exception handler in that case. Probably this happens way before your MessageBoxA call.

I'd check the assembly code if there is any call to IsDebuggerPresent. Or, maybe, it gets the address of the current PEB (Process Environment Block) at [fs:0x30], and reads the second byte of it, which is a BeingDebugged flag. Probably your code uses some of these to check for a debugger, and does something to the exception handler in that case.

Also, your sample may just set up an exception handler, then execute an 'illegal' instruction, like sti, or access an unmapped memory location. This will raise the exception; but if you just single step your program, Olly won't know the exception is going to happen, so it places its temporary single-step-breakpoint at the wrong location. Try to remember the address where an exception happens when single stepping, and be careful to add a breakpoint on the exception handler the next time.

Improve this answer
2
  • Oh! then would it work correctly without debugging check?? I assumed that it's some unknown nature of WinAPI haha. Your answer is really helpful to me ! thank you
    – Lee Young joo
    Commented Jun 29, 2015 at 14:54
  • @LeeYoungjoo: What i provided were possibilities. I can't say for sure what this particular malware does, without analyzing it myself, which i didn't. However, checking for debuggers, as well as playing with exception handlers, are some of the very basic anti-debugging techniques, so i'd expect an "abex crackme 1 " to use on of those instead of something much more advanced.
    – Guntram Blohm
    Commented Jun 29, 2015 at 15:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.