Well...
I'm not sure if this is really new, but I think that this deserves a look:

http://win.asmcommunity.net/board/?topic=22417.0;topicseen

Regards,
Opcode

Thank you Opcode. For me is new, and if it were not, it is always nice to bring this links, because no mather how old the dog, you can always teach him(us) new tricks.

Now, an open question to the experts in the board: How would you detect and deactivate this trick, lets say with an Olly Plug-in?

It suggests that it only apllies to attaching to already running processes - there is at least one olly plug-in that may render this protection moot - I ran into an interesting modification to the old protection SoftSentry - this one learned when it was being debugged - you could run it via an external process only once - clearing the registry keys and a file in the system32 directory allowed it to be run again, pain in the ass, but not insurmountable, BTW I found a debuggerless way to dunp that one - if anyone is interested, I'll supply the details.

SiGiNT

Nice, but I don't think it works on Win2K as reported. I haven't tested in on XP, but since it's based on ntdll!DbgUiRemoteBreakin and that isn't actually exported by Win2K Ntdll...


A little explanation of how Win2K handles various debug messages which I've seen from examining the use of LPC's in Windows. Win2K at least made use of Local Procedure Calls (LPC's) to handle certain API's a debugger would use. This included DebugActiveProcess, BaseDebugAttachThread, ContinueDebugEvent and WaitForDebugEvent.

When an active process is being attached in Win2K, DebugActiveProcess uses an LPC call through the CSR subsystem to connect through what is effectively a 'remote' port, DbgUiApiPort. The path goes something like:

DebugActiveProcess -> CsrClientCallServer -> ZwRequestWaitReplyPort
-> DbgUiConnectToDbg ->DbgUiApiPort -> ZwConnectPort

The handle of this port after it is connected to is actually stored in the debuggers TEB:

DbgUiApiPort = *(ULONG*)((ULONG)((PETHREAD)PsGetCurrentThread())->Tcb.Teb + 0xF24);


There was also a secondary (temporary blocking) thread used by the system during the attachment process that could also be detected through LPC messages:

BaseDebugAttachThread -> CsrClientCallServer -> ZwRequestWaitReplyPort


The 3rd use of LPC's was with the debugger workhorse API's:

ContinueDebugEvent -> DbgUiContinue - > NtRequestWaitReplyPort
WaitForDebugEvent -> DbgUiWaitStateChange -> NtRequestWaitReplyPort



The LPC_MESSAGE structure used with each of these calls can be defined and each is slightly different. While I can't point to the exact differences, the XP versions of these debugger kernel API's don't use the same procedure or use of LPC calls as does Win2K.


The point is simply that this AntiAttach method using DbgUiRemoteBreakin doesn't appear suitable for Win2K as is mentioned.
http://www.kakeeware.com/i_antiattach.php


Cheers,
Kayaker

This antidebug method is only effective against attaching to an already-running process and only against usermode debuggers, as well only on WinXP, so I don't see any "protection" being offered by this scheme.

I'm a SoftIce and Win98SE user myself, so it's essentially ineffective on my system.

BTW: anyone taken a "crack" at the other (registerable) softwares on that site?

This link might be of some interest to you guys:

AttachAnyway plugin
http://www.openrce.org/downloads/details/177/AttachAnyway

Regards 5aLIVE.

Hi.
How would you detect and deactivate this trick, lets say with an Olly Plug-in?From the .c file:
This is a simple plugin made just for fun. It's not a sort of professional plugin (maybe you'll find bugs, you surely won't find checks on function's return values and so on...); it was born in order to give you an idea on how to fool the DbgUiRemoteBreakin anti attach trick. The trick is explained here:
http://www.kakeeware.com/i_antiattach.php
The plugin has 2 voices:
- Save bytes: save part of the original DbgUiRemoteBreakin routine
- antiAttach DbgUiRemoteBreakin: restore part of the original DbgUiRemoteBreakin routine
Obviously you have to save the bytes and then use the other voice

This is the olly plug-in that I was referring to.

SiGiNT

But.......... Hasn't worked for me with Arma.

of course it doesn't work for copymem because debugger is already attached...