parameters to int 0x2d

NTDEV
1

For the purposes of hooking DbgPrint for systems where
DbgSetDebugPrintCallback does not exist, it looks like interrupt 0x2d is
the most correct place to hook things.

Tracing DbgPrint the last thing that happens is a routine called
‘DebugService’ which more-or-less does the following:

mov eax,dword ptr [ebp+8]
mov ecx,dword ptr [ebp+0Ch]
mov edx,dword ptr [ebp+10h]
mov ebx,dword ptr [ebp+14h]
mov edi,dword ptr [ebp+18h]
int 2Dh

is there any documentation on what the 5 parameters are? I might have
these backwards (I’m dyslexic when it comes to stack based parameter
passing :slight_smile: but eax appears to be 1 for a DbgPrint buffer, edx appears to
contain the length of the buffer, and ecx appears to be the address of
the buffer. Other two are 0 or -1.

Thanks

James

2

I think you have it correct; I don’t believe that the other two are used for DbgPrint().

mm

3

>

I think you have it correct; I don’t believe that the other two are
used for
DbgPrint().

Thanks. Hooking 0x2D works great under 2003 x32, but gives the expected
bug check 0x109 (,3) error under 2003 x64. There must be a way to do
it though, or dbgview wouldn’t work.

James

4

See the post by Mark Roddy on a similar thread in the past two days (sorry, don’t remember which one; maybe the ‘x64’ one?) about the DbgKdXXX() function that allows replacement DebugPrint().

mm

5

>

See the post by Mark Roddy on a similar thread in the past two days
(sorry,
don’t remember which one; maybe the ‘x64’ one?) about the DbgKdXXX()
function
that allows replacement DebugPrint().

Mark Roddy’s suggestion was to use DbgSetDebugPrintCallback, but that is
only available for Vista and beyond (unless it is implemented via a
library in a newer ddk?).

So for XP and 2003x32 I can hook 0x2d, and for Vista and beyond I can
use DbgSetDebugPrintCallback, but there is a ‘hole’ in the middle
containing 2003 x64 (and XP x64 too I guess) for which I know of no
solution.

Thanks

James

6

My bad; forgot about that part.

mm

7

Right - so there is no good answer for XP64 and W2K364. Luckily
neither of these are actually mainstream releases, so I would suggest
the following for them: punt. Either that or go to blackhat rootkit
school and learn how to work around the 64bit restrictions.

Mark Roddy

On Tue, Nov 24, 2009 at 3:05 AM, James Harper
wrote:
>>
>> See the post by Mark Roddy on a similar thread in the past two days
> (sorry,
>> don’t remember which one; maybe the ‘x64’ one?) about the DbgKdXXX()
> function
>> that allows replacement DebugPrint().
>>
>
> Mark Roddy’s suggestion was to use DbgSetDebugPrintCallback, but that is
> only available for Vista and beyond (unless it is implemented via a
> library in a newer ddk?).
>
> So for XP and 2003x32 I can hook 0x2d, and for Vista and beyond I can
> use DbgSetDebugPrintCallback, but there is a ‘hole’ in the middle
> containing 2003 x64 (and XP x64 too I guess) for which I know of no
> solution.
>
> Thanks
>
> James
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

8

>

Right - so there is no good answer for XP64 and W2K364. Luckily
neither of these are actually mainstream releases,

Windows 2003 x64 is not a ‘mainstream release’? We sold a bunch of
servers a few years ago with HP branded Windows 2003 x64, so I’m not
sure you can claim that it isn’t ‘mainstream’…

XP x64 I can understand though.

so I would suggest
the following for them: punt.

The existing method I use is to redefine the KdPrint and ASSERT macros
but obviously that only works within the context of my drivers. I guess
I can retain that for x64 <= 2003, use int 0x2d redirection for x32 <=
2003, and the api for >= Vista. Messy, but less messy than a BSod :slight_smile:

Either that or go to blackhat rootkit
school and learn how to work around the 64bit restrictions.

Sounds like too much work :slight_smile:

Sysinternals know how to do it obviously, but given that their product
is a diagnostic tool and not part of a driver in the critical driver
database I guess they can take a few liberties :slight_smile:

James