# try to attach to me… if you can!

why we might want to attach to active process? there are zillion reasons to do it. for example, the file is packed and stuffed with many adbg tricks. or, maybe, we found a suspicious process in memory and want to analyze it. maybe something else…

there many ways to prevent attaching: self-replicated and self-debugged processes do it very well, but there is another way. please, download the crack-me (with sources) and try to handle it by yourself.

  • 1) run to_attach_31.exe;
  • 2) run OllyDbg or IDA-Pro;
  • 3) try to attach the debugger to the process;
  • 4.1) in Olly: File => Attach => to_attach_31.exe;
  • 4.2) in IDA: Debug => Attach to process => to_attach_31.exe;
  • 5) see “shit happens” messages;
  • 6) the process is still running and the debugger has no control;
Olly is unable to attach to the process

Olly is unable to attach to the process

well, how it worked? when debugger is attaching to process, a new thread is created. NTDLL!DbgBreakPoint function is called and it’s called by not-exported KERNEL32!_BaseAttachComplete@4. the problem is that the thread is created inside the debugged process, so the debugged process can change NTDLL!DbgBreakPoint. for example, intercept it and terminate the system thread preventing attaching. or… abuse the debugger! why not?! we can do almost everything, including creating a faked thread and attaching the debugger to it!
see the source code.

p = (DWORD) GetProcAddress(LoadLibrary(“NTDLL.DLL”), “DbgBreakPoint”);

// nasty dirty trick – we just overwrite the code of DbgBreakPoint
VirtualProtect(p, 1024, PAGE_EXECUTE_READWRITE, &old);
__asm{
jmp inject
x_code: mov eax, offset souriz
jmp eax
inject: mov esi, offset x_code
mov edi, p
mov ecx, 2
REP MOVSD
}

the code above patches NTDLL!DbgBreakPoint, injecting mov eax, offset souriz/jmp eax code over it. not good! but it’s just a POC after all, so feel free to improve it. anyway it woks!

I tested it under: W2K SP4, XP SP3, S2K3 SP1. please, test the crack-me under other systems. a few people reported that MsgBox, called by souriz() function not appears on the screen. it’s strange. I have no idea why – need more info to find out.

the last question is: how to bypass this trick? I think, the best strategy – just to check NTDLL/KERNEL32 before attaching (via ReadProcessMemory) and restore them if it’s necessary, but… it’s possible to prevent attaching, changing only data and the second problem: in real life we want to know what the program changed exactly. will think how to handle it.

P.S. see comments for more details.

 

10 Comments

  1. Yes, this is in my Anti-Unpacker 2 paper, part 2 on my site. :-)
    Also, see there for the TLS anti-attach method. No need to patch DbgBreakPoint at all.

  2. Hi, Peter! thanks for the comment! I very appreciate your feedback! I have not read your article yet, thanks for the link. I’m reading it now. interesting reading! I used the method you describe in the first version of my program. this is only two lines C-program (you can download it here):

    p = (DWORD*) GetProcAddress(LoadLibrary(“NTDLL.DLL”), “DbgBreakPoint”);
    VirtualProtect(p, 1, PAGE_EXECUTE_READWRITE, &old); *p = 0xC3;

    but… with all my respect to you, Peter, this is not anti-debug trick at all. it just does not work. ok, run the program, take Olly and try to attach. looks like Olly fails, right? wrong! press “stop” to pause the program. you will see only one main thread there. unwind the stack to find return address to the main body, go there, set breakpoint and press “start” to resume the process. the breakpoint will be triggered and now you can debug process. so, we have attached to it!!!

    so, my point is: we have to replace DbgBreakPoint by code that terminates the main thread of the app or abuses the debugger or does something else…

  3. Great job.Hoping to see more of such tricks.

  4. Cool piece of info ;> Thanks ;>
    (now I know why olly behaved the way it did in my memory freeing experiment -> http://gynvael.coldwind.pl/?id=93)

  5. My paper says “Turbo Debug32, and possibly other console-mode debuggers, will hang as a result”, so it is anti-debugger.
    Yes, I know that using only a RET is not very aggressive. However, a debugger can gain control before DbgBreakPoint is even executed, so terminating the thread there is no guarantee of success, either.

  6. Old school trick, nice to see it implemented like that. Keep sharing!

  7. Alexander Stankov

    Doesn’t run on Vista SP1 x86

  8. Kris, to attach to your process with IDA Pro, just set “Stop on debugging start” checkbox in the debugger options. This is enough to suspend the process and successfully debug it.

    So your trick does not work against IDA.

  9. wow! I did ever think that you read my blog, it’s an honor for me! well, I recheck it again. IDA-Pro 5.3 fails. I checked “Stop on debugging start” like you said, attached to the process and pressed F9. message “shit happens” appeared and this means that the intercepted function has been executed (see the screenshot). of course, it executes after attaching, so it’s possible to trace this code step-by-step and block the protection. but… if we’re not aware about this trick… who would trace the system code?! nobody! I’m writing a script for IDA-Pro to check integrity of the critical system structures and KERNEL32/NTDLL code to bypass tricks like this (they are quite common, take VM Protector for example).

    btw, could you please check this trick. does IDA-Pro 5.4 freezes? IDA-Pro 5.3 does. thanks in advance!

  10. EliasBierig

    Great idea, but will this work over the long run?

Leave a comment

Comments are closed.