nezumi-lab
February 8th, 2009, 17:21
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 ("http://nezumi-lab.org/ffh/to_attach_31.zip") the crack-me (with sources) and try to handle it by yourself.
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.
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.
http://nezumi-lab.org/blog/?p=115
there many ways to prevent attaching: self-replicated and self-debugged processes do it very well, but there is another way. please, download ("http://nezumi-lab.org/ffh/to_attach_31.zip") the crack-me (with sources) and try to handle it by yourself.
http://nezumi-lab.org/gif/to_attach.gifOlly is unable to attach to the process
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;
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”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!, “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
}
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.
http://nezumi-lab.org/blog/?p=115