custom debug host driver

NTDEV
1

Is there any way to write your own host driver for kernel debugging? I
want to provide another communication channel instead of serial, usb, or
firewire. This would be under Xen so a direct communication channel
should be possible with a minimum of overhead.

Ideally such a solution would be using Microsoft blessed apis/hooks, but
given that it’s a debugger and by definition never used in a production
environment I’m not above doing things under the covers…

Thanks

James

2

Officially, no, the KdStubs interface is not documented, but it’s possible.

You might want to take a look at VirtualKD (http://virtualkd.sysprogs.org/)
and VirtualBox (http://www.virtualbox.org/).

In particular, VirtualKD’s KDVM implements a custom kd transport.

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Saturday, October 16, 2010 9:14 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] custom debug host driver

Is there any way to write your own host driver for kernel debugging? I want
to provide another communication channel instead of serial, usb, or
firewire. This would be under Xen so a direct communication channel should
be possible with a minimum of overhead.

Ideally such a solution would be using Microsoft blessed apis/hooks, but
given that it’s a debugger and by definition never used in a production
environment I’m not above doing things under the covers…

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

3

>

Officially, no, the KdStubs interface is not documented, but it’s
possible.

You might want to take a look at VirtualKD
(http://virtualkd.sysprogs.org/)
and VirtualBox (http://www.virtualbox.org/).

In particular, VirtualKD’s KDVM implements a custom kd transport.

Nice. So I can write my own kdxen.dll and then say /debugport=xen - it’s
almost too easy :slight_smile:

Do you know if the kd dll uses interrupts or is it purely polled? I’ve
had a quick look in kdcom.dll and can’t see where an irq would be set,
but by its very nature it would operate as close to the hardware as
possible and so wouldn’t use normal ‘give me an irq’ methods…

Thanks!

James

4

I believe that it uses polling.

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Saturday, October 16, 2010 11:06 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] custom debug host driver

Officially, no, the KdStubs interface is not documented, but it’s
possible.

You might want to take a look at VirtualKD
(http://virtualkd.sysprogs.org/)
and VirtualBox (http://www.virtualbox.org/).

In particular, VirtualKD’s KDVM implements a custom kd transport.

Nice. So I can write my own kdxen.dll and then say /debugport=xen - it’s
almost too easy :slight_smile:

Do you know if the kd dll uses interrupts or is it purely polled? I’ve had a
quick look in kdcom.dll and can’t see where an irq would be set, but by its
very nature it would operate as close to the hardware as possible and so
wouldn’t use normal ‘give me an irq’ methods…

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

5

How does one make a kernel mode dll?

TARGETTYPE=DYNLINK is for a user mode dll and so the build environment
isn’t set up right for kernel mode
TARGETTYPE=EXPORT_DRIVER builds a .sys, and appears to ignore TARGETEXT
TARGETTYPE=GDI_DRIVER appears to want to link with win32k.sys which
maybe I don’t want?

Should I build my EXPORT_DRIVER .sys file and just rename it?

Thanks

James

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-428120-
xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
Sent: Sunday, 17 October 2010 14:08
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] custom debug host driver

I believe that it uses polling.

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Saturday, October 16, 2010 11:06 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] custom debug host driver

>
> Officially, no, the KdStubs interface is not documented, but it’s
possible.
>
> You might want to take a look at VirtualKD
(http://virtualkd.sysprogs.org/)
> and VirtualBox (http://www.virtualbox.org/).
>
> In particular, VirtualKD’s KDVM implements a custom kd transport.
>

Nice. So I can write my own kdxen.dll and then say /debugport=xen -
it’s
almost too easy :slight_smile:

Do you know if the kd dll uses interrupts or is it purely polled? I’ve
had a
quick look in kdcom.dll and can’t see where an irq would be set, but
by its
very nature it would operate as close to the hardware as possible and
so
wouldn’t use normal ‘give me an irq’ methods…

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

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

6

A couple ideas to look into…

Llook into implementing an emulator for a 1394 hardware subset. Kernel
debugging does not use anything close to all the features in the 1394 chips.
I believe it basically enables debug mode, which then allows RDMA to work,
and there is a way to communicate where the RDMA target buffer is located in
memory. Your 1394 emulator just had to ignore many of the register writes
used to initialize debug mode, and then have a way to read/write debug
packets to the debug buffer. Your 1394 emulator returns a PCI VID/PID saying
it’s a 1394 controller to make the 1394 debug support in the guest happy.
Ideally you connect the other end of the emulated 1394 to a network socket
so you can just point windbg at the correct IP address and have the debug
packets show up in the guest. I haven’t personally implemented this, but did
do some research on it for a possible implementation on a management
controller like device.

If you download the Microsoft Singularity source tree, and search for I
believe its kd1394, you will get a good idea of what the 1394 debugger
actually looks like. The target side code is pretty simple, and is probably
not exactly the code used on production Windows OS’s, it is pretty close as
Singularity can be debugged with windbg. There also is info on the web about
the serial debugging protocol, mostly by people doing security research.

You might just add special kernel debugging support to the serial emulator
(like memory read request optimization), which might get most of the
performance gains a 1394 emulator would give.

Running some IRP traces of the debugger end of a 1394 debugging session
would likely also prove educational, unless you happen to have a 1394
hardware protocol debugger handy. Tracing a serial port debug session would
also be useful, as I believe the differences at the debugger end are small.
1394 debugging performance is high because certain debug packet types, like
memory read, and converted by the debugger driver/protocol DLL into RDMA
reads, so instead of sending a request to read to the target debug stub
code, which they copies the data into the debug packet buffer when is then
read by the protocol, it just sends a RDMA read request to the 1394
hardware.

I’ve been told on recent OS’s it’s not possible for third parties to
actually write new debugger protocol kernel DLL’s (the target side), as the
OS checks for a digital signature that only Microsoft can generate.

You should look at the VirtualKD stuff too.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-428116-
xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Saturday, October 16, 2010 6:14 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] custom debug host driver

Is there any way to write your own host driver for kernel debugging? I
want
to provide another communication channel instead of serial, usb, or
firewire.
This would be under Xen so a direct communication channel should be
possible with a minimum of overhead.

Ideally such a solution would be using Microsoft blessed apis/hooks, but
given that it’s a debugger and by definition never used in a production
environment I’m not above doing things under the covers…

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

7

Indeed.

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Sunday, October 17, 2010 12:22 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] custom debug host driver

How does one make a kernel mode dll?

TARGETTYPE=DYNLINK is for a user mode dll and so the build environment isn’t
set up right for kernel mode TARGETTYPE=EXPORT_DRIVER builds a .sys, and
appears to ignore TARGETEXT TARGETTYPE=GDI_DRIVER appears to want to link
with win32k.sys which maybe I don’t want?

Should I build my EXPORT_DRIVER .sys file and just rename it?

Thanks

James

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-428120-
xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
Sent: Sunday, 17 October 2010 14:08
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] custom debug host driver

I believe that it uses polling.

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Saturday, October 16, 2010 11:06 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] custom debug host driver

>
> Officially, no, the KdStubs interface is not documented, but it’s
possible.
>
> You might want to take a look at VirtualKD
(http://virtualkd.sysprogs.org/)
> and VirtualBox (http://www.virtualbox.org/).
>
> In particular, VirtualKD’s KDVM implements a custom kd transport.
>

Nice. So I can write my own kdxen.dll and then say /debugport=xen -
it’s
almost too easy :slight_smile:

Do you know if the kd dll uses interrupts or is it purely polled? I’ve
had a
quick look in kdcom.dll and can’t see where an irq would be set, but
by its
very nature it would operate as close to the hardware as possible and
so
wouldn’t use normal ‘give me an irq’ methods…

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

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

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

As I recall, KD transport modules are required to be signed by a Microsoft issued certificate (even on x86) since Vista.

  • S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Saturday, October 16, 2010 6:14 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] custom debug host driver

Is there any way to write your own host driver for kernel debugging? I want to provide another communication channel instead of serial, usb, or firewire. This would be under Xen so a direct communication channel should be possible with a minimum of overhead.

Ideally such a solution would be using Microsoft blessed apis/hooks, but given that it’s a debugger and by definition never used in a production environment I’m not above doing things under the covers…

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

9

Do you know what restrictions there are in what calls I can make at the
time the kd module is initialised? For instance can I call
ExAllocatePoolXxx? I need to allocate a few pages of memory to share
with Xen. Something to test tomorrow.

Thanks

James

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-428120-
xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
Sent: Sunday, 17 October 2010 14:08
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] custom debug host driver

I believe that it uses polling.

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Saturday, October 16, 2010 11:06 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] custom debug host driver

>
> Officially, no, the KdStubs interface is not documented, but it’s
possible.
>
> You might want to take a look at VirtualKD
(http://virtualkd.sysprogs.org/)
> and VirtualBox (http://www.virtualbox.org/).
>
> In particular, VirtualKD’s KDVM implements a custom kd transport.
>

Nice. So I can write my own kdxen.dll and then say /debugport=xen -
it’s
almost too easy :slight_smile:

Do you know if the kd dll uses interrupts or is it purely polled? I’ve
had a
quick look in kdcom.dll and can’t see where an irq would be set, but
by its
very nature it would operate as close to the hardware as possible and
so
wouldn’t use normal ‘give me an irq’ methods…

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

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

10

As the OS loader can interface with the debugger too (via the bootdebug BCD
option), I’d think debugger protocol libraries are VERY restricted in what
API’s they can call.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-428149-
xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Sunday, October 17, 2010 5:57 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] custom debug host driver

Do you know what restrictions there are in what calls I can make at the
time
the kd module is initialised? For instance can I call ExAllocatePoolXxx? I
need
to allocate a few pages of memory to share with Xen. Something to test
tomorrow.

Thanks

James

11

James, these interfaces are considered internal and we don’t support them.
See the disclaimer at the bottom of my post.

With that said, I (with a couple of other people at various times) created
that interface. If you’re trying to get something working during early
init, you’ve got essentially nothing to work with except your stack and a
few pointers in the HAL’s private dispatch table which allow PCI config
access. Finding those pointers in a robust way without the headers would be
tricky. Mm and Ex haven’t come up yet. Nor has any Zw function.

If you dump the imports on kd1394.dll, you’ll see that it imports some of
the things that I said are unavailable. It uses them to save and restore
during sleep transitions.

Jake Oshins
Hyper-V I/O Architect (former HAL guy)
Windows Kernel Group

This post implies no warranties and confers no rights.

“James Harper” wrote in message news:xxxxx@ntdev…

Do you know what restrictions there are in what calls I can make at the
time the kd module is initialised? For instance can I call
ExAllocatePoolXxx? I need to allocate a few pages of memory to share
with Xen. Something to test tomorrow.

Thanks

James

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-428120-
xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
Sent: Sunday, 17 October 2010 14:08
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] custom debug host driver

I believe that it uses polling.

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Saturday, October 16, 2010 11:06 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] custom debug host driver

>
> Officially, no, the KdStubs interface is not documented, but it’s
possible.
>
> You might want to take a look at VirtualKD
(http://virtualkd.sysprogs.org/)
> and VirtualBox (http://www.virtualbox.org/).
>
> In particular, VirtualKD’s KDVM implements a custom kd transport.
>

Nice. So I can write my own kdxen.dll and then say /debugport=xen -
it’s
almost too easy :slight_smile:

Do you know if the kd dll uses interrupts or is it purely polled? I’ve
had a
quick look in kdcom.dll and can’t see where an irq would be set, but
by its
very nature it would operate as close to the hardware as possible and
so
wouldn’t use normal ‘give me an irq’ methods…

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

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

12

>Nice. So I can write my own kdxen.dll and then say /debugport=xen - it’s

almost too easy :slight_smile:

For such a purpose, I would reverse-engineer KDCOM.DLL.

Also note that you will also need to provide the debug transport channel DLL to KD/WinDbg from the host side, which can be even more painful.

Do you know if the kd dll uses interrupts or is it purely polled?

Purely polled. At some moments of the OS’s lifetime (releasing the dispatcher lock or such), the kernel itself calls KdPollBreakIn in the debugger transport module.

This is enough to react to break-in command from WinDbg.

And, after break-in, the OS is stalled and the busy loop is executed inside the KD’s transport to get more bytes over the KD channel.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

13

>I’ve been told on recent OS’s it’s not possible for third parties to
actually write new debugger protocol kernel DLL’s (the target side), as the
OS checks for a digital signature that only Microsoft can generate.

I remember hearing/reading that a well, but it’s either apparently not the
case (my guess), or some people have worked around it. In particular, the
x86_64 build of kdvm.dll (of virtualdkd) isn’t signed by msft.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Sunday, October 17, 2010 1:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] custom debug host driver

A couple ideas to look into…

Llook into implementing an emulator for a 1394 hardware subset. Kernel
debugging does not use anything close to all the features in the 1394 chips.
I believe it basically enables debug mode, which then allows RDMA to work,
and there is a way to communicate where the RDMA target buffer is located in
memory. Your 1394 emulator just had to ignore many of the register writes
used to initialize debug mode, and then have a way to read/write debug
packets to the debug buffer. Your 1394 emulator returns a PCI VID/PID saying
it’s a 1394 controller to make the 1394 debug support in the guest happy.
Ideally you connect the other end of the emulated 1394 to a network socket
so you can just point windbg at the correct IP address and have the debug
packets show up in the guest. I haven’t personally implemented this, but did
do some research on it for a possible implementation on a management
controller like device.

If you download the Microsoft Singularity source tree, and search for I
believe its kd1394, you will get a good idea of what the 1394 debugger
actually looks like. The target side code is pretty simple, and is probably
not exactly the code used on production Windows OS’s, it is pretty close as
Singularity can be debugged with windbg. There also is info on the web about
the serial debugging protocol, mostly by people doing security research.

You might just add special kernel debugging support to the serial emulator
(like memory read request optimization), which might get most of the
performance gains a 1394 emulator would give.

Running some IRP traces of the debugger end of a 1394 debugging session
would likely also prove educational, unless you happen to have a 1394
hardware protocol debugger handy. Tracing a serial port debug session would
also be useful, as I believe the differences at the debugger end are small.
1394 debugging performance is high because certain debug packet types, like
memory read, and converted by the debugger driver/protocol DLL into RDMA
reads, so instead of sending a request to read to the target debug stub
code, which they copies the data into the debug packet buffer when is then
read by the protocol, it just sends a RDMA read request to the 1394
hardware.

I’ve been told on recent OS’s it’s not possible for third parties to
actually write new debugger protocol kernel DLL’s (the target side), as the
OS checks for a digital signature that only Microsoft can generate.

You should look at the VirtualKD stuff too.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-428116-
xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Saturday, October 16, 2010 6:14 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] custom debug host driver

Is there any way to write your own host driver for kernel debugging? I
want
to provide another communication channel instead of serial, usb, or
firewire.
This would be under Xen so a direct communication channel should be
possible with a minimum of overhead.

Ideally such a solution would be using Microsoft blessed apis/hooks,
but given that it’s a debugger and by definition never used in a
production environment I’m not above doing things under the covers…

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

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

14

>

>I’ve been told on recent OS’s it’s not possible for third parties to
actually write new debugger protocol kernel DLL’s (the target side),
as the
OS checks for a digital signature that only Microsoft can generate.

I remember hearing/reading that a well, but it’s either apparently not
the
case (my guess), or some people have worked around it. In
particular, the
x86_64 build of kdvm.dll (of virtualdkd) isn’t signed by msft.

kdvm.dll has 2 modes of operation. The first is where you say
‘/debugport=vm’ and windows loads kdvm.dll directly. The second is where
you say ‘/debugport=com1’ and debugging starts on com1 but then a driver
loads later and hooks into kdcom.dll (or somewhere in the debug call
path) and diverts to the kdvm.dll driver. I believe this definitely
works on x64 systems because patchguard is turned off when the debugger
is enabled. I had wondered why you’d bother loading a driver and hooking
the debugger when you could just load kdvm.dll directly, but maybe
that’s why? I have my stub kdxen.dll driver loading on windows 2003 x32
(it doesn’t do anything yet except signal xen that it’s loaded and then
tell windows that init failed) and will try on x64 at some point soon to
see if signing is required or not.

James

15

As best as I can tell (not that I’ve looked at it all that closely),
kdvm.dll is getting directly loaded on x86_64-win7-fre.

I think that the transport dll gets loaded before PatchGuard is active; I
think that if signing is required that it would be more of a winloader
thing, at least first.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Sunday, October 17, 2010 10:17 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] custom debug host driver

>I’ve been told on recent OS’s it’s not possible for third parties to
actually write new debugger protocol kernel DLL’s (the target side),
as the
OS checks for a digital signature that only Microsoft can generate.

I remember hearing/reading that a well, but it’s either apparently not
the
case (my guess), or some people have worked around it. In
particular, the
x86_64 build of kdvm.dll (of virtualdkd) isn’t signed by msft.

kdvm.dll has 2 modes of operation. The first is where you say
‘/debugport=vm’ and windows loads kdvm.dll directly. The second is where you
say ‘/debugport=com1’ and debugging starts on com1 but then a driver loads
later and hooks into kdcom.dll (or somewhere in the debug call
path) and diverts to the kdvm.dll driver. I believe this definitely works on
x64 systems because patchguard is turned off when the debugger is enabled. I
had wondered why you’d bother loading a driver and hooking the debugger when
you could just load kdvm.dll directly, but maybe that’s why? I have my stub
kdxen.dll driver loading on windows 2003 x32 (it doesn’t do anything yet
except signal xen that it’s loaded and then tell windows that init failed)
and will try on x64 at some point soon to see if signing is required or not.

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

16

> A couple ideas to look into…

Llook into implementing an emulator for a 1394 hardware subset. Kernel
debugging does not use anything close to all the features in the 1394
chips.
I believe it basically enables debug mode, which then allows RDMA to
work,
and there is a way to communicate where the RDMA target buffer is
located in
memory. Your 1394 emulator just had to ignore many of the register
writes
used to initialize debug mode, and then have a way to read/write debug
packets to the debug buffer. Your 1394 emulator returns a PCI VID/PID
saying
it’s a 1394 controller to make the 1394 debug support in the guest
happy.
Ideally you connect the other end of the emulated 1394 to a network
socket
so you can just point windbg at the correct IP address and have the
debug
packets show up in the guest. I haven’t personally implemented this,
but did
do some research on it for a possible implementation on a management
controller like device.

I’d initially dismissed the 1394 suggestion, for no other reason that I
didn’t know anything about it. My main objective is to be able to debug
over Ethernet… do you know if the 1394 debug protocol is compatible
with the serial port protocol? Eg can I reduce it to the simple sending
and receiving of packets?

If you download the Microsoft Singularity source tree, and search for
I
believe its kd1394, you will get a good idea of what the 1394 debugger
actually looks like. The target side code is pretty simple, and is
probably
not exactly the code used on production Windows OS’s, it is pretty
close as
Singularity can be debugged with windbg. There also is info on the web
about
the serial debugging protocol, mostly by people doing security
research.

Not sure I should do that… I might infect my GPL project with a
Microsoft license simply by looking at the code :wink:

You might just add special kernel debugging support to the serial
emulator
(like memory read request optimization), which might get most of the
performance gains a 1394 emulator would give.

Running some IRP traces of the debugger end of a 1394 debugging
session
would likely also prove educational, unless you happen to have a 1394
hardware protocol debugger handy. Tracing a serial port debug session
would
also be useful, as I believe the differences at the debugger end are
small.
1394 debugging performance is high because certain debug packet types,
like
memory read, and converted by the debugger driver/protocol DLL into
RDMA
reads, so instead of sending a request to read to the target debug
stub
code, which they copies the data into the debug packet buffer when is
then
read by the protocol, it just sends a RDMA read request to the 1394
hardware.

I guess that answers my question above… that makes it a bit harder as
I’d need to have a deeper knowledge of the debug packets.

I’ve been told on recent OS’s it’s not possible for third parties to
actually write new debugger protocol kernel DLL’s (the target side),
as the
OS checks for a digital signature that only Microsoft can generate.

Yes there has been some discussion on that. I should have an answer as
soon as I configure a Windows 2008 R2 virtual machine to test it on.
It’s almost ironic as enabling the debugger disables patchguard!

You should look at the VirtualKD stuff too.

Have done :slight_smile:

Thanks

James

17

James Harper wrote:

How does one make a kernel mode dll?

TARGETTYPE=DYNLINK is for a user mode dll and so the build environment
isn’t set up right for kernel mode
TARGETTYPE=EXPORT_DRIVER builds a .sys, and appears to ignore TARGETEXT
TARGETTYPE=GDI_DRIVER appears to want to link with win32k.sys which
maybe I don’t want?

Should I build my EXPORT_DRIVER .sys file and just rename it?

Use EXPORT_DRIVER and just leave its name as .sys. There’s no reason to
change it. In my mind, .dll implies a user-mode DLL.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

18

Wouldn’t we still need a “Virtual 1394” application on the debugger side? Something that presents itself as a 1394 port for WinDBG to connect to, but has a lower edge that reads the TCP packets?

19

Something like that, yes, I think.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@oracle.com
Sent: Monday, October 18, 2010 2:00 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] custom debug host driver

Wouldn’t we still need a “Virtual 1394” application on the debugger side?
Something that presents itself as a 1394 port for WinDBG to connect to, but
has a lower edge that reads the TCP packets?

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

20

Martin,

A real pleasure meeting you. I enjoyed having an excuse to visit the “V”.

Hope you get adjusted to your new job and can enjoy it.

This URL may be of interest to the folks working with wireless:

http://pcausa.com/WlanExplorer/default.htm

Have a safe trip home!

Thos

From: “M. M. O’Brien”
Sent: Monday, October 18, 2010 3:36 PM
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] custom debug host driver

> Something like that, yes, I think.
>
>
> mm
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@oracle.com
> Sent: Monday, October 18, 2010 2:00 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] custom debug host driver
>
> Wouldn’t we still need a “Virtual 1394” application on the debugger side?
> Something that presents itself as a 1394 port for WinDBG to connect to,
> but
> has a lower edge that reads the TCP packets?
>
> —
> 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
>
>
> —
> 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