Log in

View Full Version : Is Win32 A Debugging API? If Not, How Close Is It?


Matasano
December 2nd, 2007, 17:40
Assume a black-box pen-test ("http://www.matasano.com/log/mtso/services/deploysafe/techniques") with a Win32 target that has perfectdebugger detection (disregarding how hard “perfect” is toachieve). Arbitrarily, assume no access to the kernel; in fact, noadministrator privilege at all. We simply run in processes alongsidethe target with the same credentials.

How much control do we have over the target?


We can get a Win32 handle to the process with OpenProcess.
We can read process memory by virtual offset and length withReadProcessMemory
We can enumerate the threads in the target with Toolhelp32
We can suspend or resume individual threads with OpenThread,SuspendThread, and ResumeThread
We can write process memory by virtual offset and length withWriteProcessMemory
We can allocate memory within the target with VirtualAlloc
We can change memory protection with VirtualProtectEx
We can enumerate modules and offsets within the target withToolhelp32.
We can map out memory regions with VirtualQueryEx.
We can excute code in the context of the process withCreateRemoteThread (and RtlRemoteCall ("http://www.alex-ionescu.com/?p=28")).
How much control would a debugger have given us?


We’d be able to suspend and resume threads, which we can do anyways.
We’d be able to read and write memory, which we can do anyways.
We’d be able to set breakpoints.
We’d be able to single-step the program.
We’d be able to read register contents.
We’d be able to call functions, which we can do anyways.
We’d be able to search memory for strings, which we can do anyways.
Without anything more interesting than the MSDN man pages, we comereasonably close to this without invoking the debug interface. Inexchange for not showing up in NtQuerySystemInformation or muckingwith the UEF, we give up easy-to-use breakpoints, single-stepping, andregister access. But:


We can trivially get single-use, nonrecoverable breakpoints; just inject INT 3 into the text with WriteProcessMemory.
We can potentially get access to registers using NtSetThreadContext ("http://www.alex-ionescu.com/?m=200612").
We can hook functions, in all the usual ways ("http://www.matasano.com/log/620/hand-detouring-windows-function-calls-with-ht/").
How close can we get to a fully-functional debugger without Windowsknowing about it? I’ve been playing with this for a couple weeks,using Python and ctypes, turning IDLE into a debugger prompt. And itseems like the answer is “extremely close”. More later, but if this istotally obvious, pointers, links, and comments are welcome.



http://www.matasano.com/log/707/is-win32-a-debugging-api-if-not-how-close-is-it/

dELTA
December 6th, 2007, 05:12
This is a actually a very interesting area, and I remember a good discussion about it here before, including emulating breakpoints, but I can't seem to find it at the moment.

Admiral
December 9th, 2007, 14:47
So has anybody ever attempted to write a debugger that never actually attaches? Clearly, a lot of functionality is available, you just have to work for it. But if somebody took the time to encapsulate this work...

Regarding breakpoints (if this wasn't already suggested in dELTA's phantom thread ). If DLL-injection into the target is allowed, then we could quite feasibly install a VEH - which precedes the SEH - and communicate the exception record back to the debugging process. It's reasonably clean, and it can be made to work with most processes, as VEH-use is rare. Even processes that do use vectored handlers can be dealt with if necessary by hooking AddVectoredExceptionHandler, but that's a little immoral.

Another project for the bottom of the to-do list, then

Admiral

dELTA
December 9th, 2007, 17:02
That would indeed be a very cool project. I'll add it to the bottom of my todo-list as well.

JMI
December 9th, 2007, 18:34
Well then, which one of you is going to actually move it closer to the "top" of the "to do" list and start actually working??

Regards,

Maximus
January 2nd, 2008, 06:58
Actually, the correct name for these tools is 'not-intrusive debuggers', and are based upon the principle of injecting a dll in an application, which hooks SEH and communicate with an external application that is the debugger GUI.
It is commonly used for logging application 'steps' without being forced to deal with, like VM logging and debugging.

mmh... but always wondered if... mmh...

deroko
January 2nd, 2008, 08:10
non intrusive debugging is not the most accurate sometimes, poc - try single steping this code with nonintrusive debugger, and see what happens

Code:

mov [esp-4], 0deadc0deh
mov eax, [esp-4]


context will overwrite content of [esp-4], well there are a few ways that come to my mind on how to solve this problem, but it will require ring0 patching, and we are here limited to r3 by author of the 1st post

Maximus
January 2nd, 2008, 18:07
!

Never thought about that, indeed. Thanks, useful

dELTA
January 5th, 2008, 12:39
Speak of the devil?

http://www.woodmann.com/collaborative/tools/Poke

DeepBlueSea
January 5th, 2008, 12:59

http://www.deneke.biz/obsidian

dELTA
January 5th, 2008, 13:27
Damn that's cool, just what we were talking about, even seems quite serious and advanced, and open source too, thanks!

CRCETL:
http://www.woodmann.com/collaborative/tools/Obsidian

deroko
January 5th, 2008, 14:08
http://www.woodmann.com/collaborative/tools/OepFinder more nonintrusive debuggers