Quote:
Originally posted by AYB
Programs are able to check for debuggers such as SI by checking for INT3 (interrupt 3) which is a breakpoint. i.e. stops program execution so you can examine registers, memory etc. Kazaa is one of those which will not run if it detects it. I will read up more on this to see if there is a way around it.
|
Actually, Kazaa does something a little more tricky than this. Specifically it does something along the lines of (in C-like pseudo-code):
Code:
try {
INT3
ExitProcess();
} catch (...) {
}
//rest of code here
When not under a debugger, the breakpoint exception caused by the INT3 is caught by the program before ExitProcess is called. Under a debugger, the debugger catches the breakpoint exception. When execution is resumed, it continues at the next statement which causes the program to terminate.
You can get around this by patching changing four bytes in the latest executable begining at offset DD052h to 31-C9-F7-F1. This causes a divide by zero exeception to be thrown rather than a breakpoint exception. A debugger shouldn't catch divide by zero exceptions without first giving the program a chance to handle them.
Of course, that'll only let you debugger the loader section of the executable. You'll still have to get around the compression/encryption being used. Good luck with that.