Archive for February 13th, 2009

# anti-attach: BaseThreadStartThunk => NO_ACCESS

another anti-attach trick. during attaching to the process, operation system creates a thread inside it and as far as we know, every thread has the start address. the address of the system thread is BaseThreadStartThunk. it calls BaseAttachComplete, who calls DbgBreakPoint in order to raise the breakpoint exception to pass control back to debugger. so, if we block BaseThreadStartThunk somehow, DbgBreakPoint will be never called and a debugger will never get control. theoretically…

…practically, operation system notifies a debugger when a new thread is about to be created, thus a debugger does not need in DbgBreakPoint at all!!! just set Option\Debugger option\Events\Break on new thread in Olly or Debug\Debugger options\Stop on thread start/exit in IDA-Pro and enjoy!!!

but, there is something else. first of all - these options are not set by default. second of all - if the system thread issues an exception - we can’t just continue execution! we need to kill the system thread to suppress the exception - not every hacker knows it and not every debugger allows us to do it (IDA-Pro does not).

well, guess, “Break on new thread” is set. this means our debugger stops _before_ executing the first command of BaseThreadStartThunk. how we’re going to generate an exception?! it’s easy! page of BaseThreadStartThunk => NO_ACCESS! of course, operation system will send exception notification to the debugger, allowing us to kill the system thread and continue executing/tracing the main one, but as it was said above not every hacker are ready to handle this situation.

ok, lets play with this trick. be warned: it’s not safe. we can’t set no access only for BaseThreadStartThunk, it affects the whole memory page where might be essential functions, but… for W2K/XP/S2K3 it works well. just… BaseThreadStartThunk is not an exported function. so, how we’re going to find where it’s located in memory? guess, the most universal way is to create a child process, attach to it, get CREATE_THREAD_DEBUG_EVENT notification and memorize u.CreateThread.lpStartAddress.

download the sources and binary of the POC to play with.

Olly fails to attach and the only way to continue debugging is to kill the system thread

Olly fails to attach and the only way to continue debugging is to kill the system thread

 

# zombie slam

back in the old days (UNIX, big iron) zombies were a real headache. what’s a zombie? it’s an orphan child - process without parents. how it might happen? well, guess, a mother process creates a children process and dies leaving the child alone in the dark. does it make a problem? for GUI apps - no problem, but console apps - are very different.

in general console apps share the same console. if we run cmd.exe from Explorer it creates a new console, but when we run format.com from cmd.exe - format.com uses the same console. it’s oblivious. oh, really?! NT is not MS-DOS!!! creating a new process (format.com) does not suspend the parent (cmd.exe). so, cmd.exe is still running. it would make a mess, if cmd.exe did not wait for finishing of format.com.

if you guys developed console shell you probably know that CreateProcess follows by WaitForSingleObject(hHandle,,) where hHandle - is handle of the created process. now, guess, the child process creates a sub-child and dies. WaitForSingleObject() returns control, but the sub-child is running and shares the same console!!!

consider the following code or download sources and binary:

// if it’s child process - output message to the console
if (c > 1) while(1) printf(”\rI’m a zombie [%c]$”, x[++c % sizeof(x) - 1]), Sleep(69);

// creating a child and terminating itself
memset(&pi, 0, sizeof(pi)); memset(&si, 0, sizeof(si)); si.cb = sizeof(si);
if (!CreateProcess(v[0], “Im zombie”, 0, 0, 0, 0, 0, 0, &si, &pi)) return printf(”-ERR:create_proc\n”);

run cmd.exe and type “zombie_bug.exe” (with extension!). wow!!! a very modern command prompt with a rotating fan! you can type cmd’ commands and they will be executed, but the rotating fan is working!!! now, start FAR manager and run zombie_bug.exe. ops! FAR has the same bug and our zombie is working again!!!

what’s it good for? fist of all we can create “resident” programs living in foreign consoles (use console API to output text into desired positions). another idea - zombie can intercept all input and if zombie output nothing to the console - nobody notices it!!! a good stealth spy.

what we’re going to do? does anybody want to send a bug report to Microsoft and FAR manager team?

zombie - alone in the dark

zombie - alone in the dark