I'm working on a little project and I have encountered a problem that I've never really thought about before. As usual, my lack of technical knowledge is letting me down.

I've spent an hour or so Googling the topic but all I'm finding is dead pages, incoherent scrawlings from game hackers and alluring (yet frustratingly incomplete) comments about the 'Debug Port' and a mysterious EPROCESS structure. I've gathered that the latter two finds aren't accessible from usermode and hence are useless for my purposes. Perhaps I should tell you what I'm looking for:

I'm hoping to write a usermode debugger under WinXP that can seamlessly (and transparently) be 'overriden' by another usermode debugger. The paradigm situation would go something like:

1. Remote process 'notepad' is launched.
2. Debugger1 attaches to notepad and works the debug loop as normal.
3. Debugger2 (also usermode, e.g. OllyDbg) attempts to attach to notepad via DebugActiveProcess.
4. Debugger1 detaches and allows Debugger2 to attach and do its thing.
5. Debugger2 is none-the-wiser.

A few incredibly messy and inefficient solutions jump out at me, mainly stemming from the idea of hooking DebugActiveProcess in every other process running so as to anticipate any such attempt to attach. Of course, this is out of the question.

I've read the MSDN PSAPI documentation through twice and I'm still at a loss for what to do next. Perhaps some of the greater minds on this forum could enlighten me as to the uses of relevant parts of this DebugPort, just so I can rule it out as an idea if not make some use of it.

Regards
Admiral

may be this is another such incoherent scrawling
i was poking around msdn library some days ago to see what
debugging functions have been added to xp and some of these apis caught my fascination

if your debugger is the one that needs to attach to an already attached
application may be try some thing like below

BOOL CheckRemoteDebuggerPresent(
HANDLE hProcess,
PBOOL pbDebuggerPresent
);

if(debuggerpresent)
{
BOOL DebugActiveProcessStop(
DWORD dwProcessId

BOOL DebugActiveProcess(
DWORD dwProcessId
);
}
else
BOOL DebugActiveProcess(
DWORD dwProcessId
);

does that sound ok for your purpose ?


);

Thanks for the quick response, blabberer, but unfortunately I can't use that method.

There are a few ways to deal with unwanted debuggers hogging a process you want access to, but in this case, it is my debugger that is the unwanted one.
I'm not going to have any control over the 'second' debugger on the scene, only the first. In fact, I'm not even going to know if/when another debugger will try to attach.

Thanks anyway
Admiral

Taken a look here? http://www.woodmann.com/forum/showthread.php?t=7586

How to intercept a debugger.

@Admiral:

This is slightly different from your original idea, but i think it's well worth mentioning: non-intrusive debuggers.

The idea here would be to renounce to use the standard APIs provided by microsoft for debugging a process. Instead, what you must do is to inject code into the target process and intercept the exception delivery mechanism, for example hooking some of the ntdll APIs.

Thus, you receive the exceptions in your hooked API, then take profit to send all the information to an external application - in a similar way to normal debuggers - and let the debuggee to continue, inadvertedly of your presence.

Check this link:
http://www.usenix.org/events/usenix-win2000/full_papers/wallach/wallach.pdf

This way you can coexist with debuggers.

Hope this helps,
Havok.

[EDIT: another obvious advantage is not to have to worry about anti-debug]

The paper in really interesting, HAVOK, but it intercepts the exceptions as I supposed, altering the unhandled filter.
It would not bypass the tricks that rely on stepping exception+bp exception, as they are caught by the exception handler itself. It requires anyway to patch the exception handling flow, I think.

Yep, one have to look for a suitable modification of the techniques in the paper. If i'm not mistaken, this paper was never thought with beating anti-debug in mind.

The idea would always be, as you mention, to intercept the notification of the exception and alter the flow so it goes to your built-in hook. It has many advantages with respect to traditional ring-3 debuggers, like Olly.

Detecting a non-intrusive-debugger would be pretty difficult. The only way i can think is checksumming ntdll in search of intruders but, how can you know you are not checksumming fake_ntdll?. Another possibility would be checking the elapsed time, but it's hard to make it work in a variaty of OSes.

Cheers,

Litana:

At first I thought this would solve my problem but after a little investigation it turns out that no new thread is created and none of those functions trigger if the process is already running under a debugger. So it's back to the drawing board

HAVOK, that's a really interesting idea, and it might just be workable. It'd take a lot more effort, but it would also give me a lot more power. In this way, one could create two mutually-debugging processes. Oh, the humanity .

This may belong in a different thread, so I apologize if it is off-topic of your thread and idea Admiral.
There is one Debugger concept I have been thinking about and doing some Google on. Perhaps because my lack of sophistication I have not found anything illuminating, but you guys may have some information about it. Goes like this:

A kernel (or user) debugger that works as a virtual machine, Lets say VMware, which emulates ALL the functionality of the CPU, but feeds all the internal state information of the guest machine to a process in the host machine. It could place "hardware" breakpoints without using any of the intrinsic virtual CPU debug registers because it has its own private unlimited stash of debug registers that are not visible to the guest system. No need to use OS debug APIs, no hooking, no way to detect the debugger. The debugger would have seamless access to all memory of all processes. Even the passage of time could be stopped by this GOD-like debugger in the host system, if you emulate the CMOS clock and stop it when a breakpoint occurs.

I am sure something like this indeed exists, but I have not seen an implementation of it.

@naides:

In the book "the art of computer virus research", P.Szor mentions there is a private user-level implementation of an emulator, which they use to analyze viruses. Such a tool is able to emulate all syscalls, set bpx, etc,... all in the line you mention, all undetectable by the target.

Coding it for ring0 should be possible, as well as much harder. Part of this work is already available (disassemblers, partial emulators) and, in theory, a group of crackers could join to code it, but you know how individualist we all are ...

Unfortunately, even if this ring-0 emulator was coded it would be totally useless againgst the virtual machines of protections like StarForce. You would end up with an infinite log of meaningless instructions to study. May be crackers finally decide to work together to beat VM, if possible, but i don't want to hijack this very interesting thread with the VM problem.

Regards,
Havok.

Hi,
It's too bad you think a kernel mode hook doesn't suit your purposes, because it would be the way to do it. I traced through DebugActiveProcess today and really feel a hook of DbgUiConnectToDbg -> NtCreateDebugObject would be the best bet. The critical compare as to why a second debugger can't attach (STATUS_PORT_ALREADY_SET), does boil down to a check of EPROCESS.DebugPort of the debugged process.

If the DebugPort is free, DebugActiveProcess eventually grabs a FastMutex of a special system mutex (Dbg_something_mutex, uses KeStackAttachProcess to attach to the process and sets the PEB.IsBeingDebugged flag.

The check on DebugPort actually occurs during DbgUiDebugActiveProcess *after* NtCreateDebugObject is called, but it's probably the most convenient hook. You could probably hook a communication with the DbgUiApiPort itself (stored in Debugger.Teb + 0xF24) but that would be overly complex. A basic SSDT hook would suffice and notifying your own debugger for 'dis-attachment' at this point should be fairly straightforward with the use of events.

This probably isn't what you want to hear, but think of it as a good excuse to develop a ring0 hooking framework for further reversing exploits..

Cheers,
Kayaker

That would certainly be the *ultimate* debugger. Something of this kind certainly exists, but not publically, for the x86 architecture. For the z80 and other small processors and architectures, they do exist, and are called Emulators or Advanced Emulation Environments.

However, it is after all an emulated processor, and thus runs at an extremely slow speed even when implemented in highly optimised Asm. The guest running at 1/100th of the host's speed is quite typical. This makes it impractical for protections which employ large amounts of useless executed code, at least until we have faster processors.

Kayaker,

I hadn't ruled out kernel mode hooking as such but because my experience in this area is 'within an epsilon' of 0, I kind of assumed it would be impossible. With hindsight that sounds a little stupid.

So I'm (at the time of writing) pretty clueless about how to start coding, but of course nobody gets a free lunch so I guess I'll head off and do some reading. The fact that you say it's possible and (I won't use the word 'simple') not too difficult is all I need to know.

I'm sure I'll be back here in a day or two

Thanks
Admiral