Hi,
How can I investigate driver’s dispatch table? I have a device object and a driver object (KMDF) and I would like to print out the dispatch table.
Regards,
Lukasz
!drvobj
In this case you want flags = 0x2
http://msdn.microsoft.com/en-us/library/windows/hardware/ff562408(v=vs.85).aspx
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, October 8, 2014 12:24 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Investigate the dispatch table
Hi,
How can I investigate driver’s dispatch table? I have a device object and a driver object (KMDF) and I would like to print out the dispatch table.
Regards,
Lukasz
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
And how can I do that in KMDF code. Is there a routine that returns it from device object?
WdfDeviceWdmGetDeviceObject
Peter
OSR
@OSRDrivers
A kmdf driver’s dispatch table is uninteresting, it will be all wdf functions which thunk to the dispatch routines in the WDFDEVICE. The path to the wdm driver object is
!wdfkd.wdfdevice (wdfdevice) to get the wdm device object
!devobj (wdm dev obj) will give you the driver object
BUT !wdfkd.wdfdevice will give you the wdfdevice dispatch table which is really what you want
d
Bent from my phone
From: xxxxx@osr.commailto:xxxxx
Sent: ?10/?8/?2014 1:59 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Investigate the dispatch table
WdfDeviceWdmGetDeviceObject
Peter
OSR
@OSRDrivers
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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</mailto:xxxxx></mailto:xxxxx>
On Oct 8, 2014, at 1:56 PM, xxxxx@gmail.com wrote:
And how can I do that in KMDF code. Is there a routine that returns it from device object?
What are you hoping to find? If I told you that the IRP_MJ_READ dispatch is FFFFF880_12996FC0, what do you know that you didn?t know before?
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I’m trying to get some information from IoCallDriver called between USB3 root hub and controller. I’m writing a tool to debug the communication flow between usb device->usb3 root hub->usb3 controller->user mode. I already have access to the IOCTLs going to the user mode, but I don’t know how can I capture communication between root hub and the controller without a filter driver.
I thought that with access to the controller’s driver dispatch table I could override a routine responsible for the communication (the same I did with NtDeviceIoControlFile from SSDT, but it gives me only IOCTL communication from driver to the application)
Root hub _> controller is not through iocalldriver, you can’t hook it
d
Bent from my phone
From: xxxxx@gmail.commailto:xxxxx
Sent: ?10/?9/?2014 2:09 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Investigate the dispatch table
I’m trying to get some information from IoCallDriver called between USB3 root hub and controller. I’m writing a tool to debug the communication flow between usb device->usb3 root hub->usb3 controller->user mode. I already have access to the IOCTLs going to the user mode, but I don’t know how can I capture communication between root hub and the controller without a filter driver.
I thought that with access to the controller’s driver dispatch table I could override a routine responsible for the communication (the same I did with NtDeviceIoControlFile from SSDT, but it gives me only IOCTL communication from driver to the application)
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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</mailto:xxxxx></mailto:xxxxx>
Is there any possible way to get the same traffic (or part of it) as UsbTrace tool, without using a filter driver?
You can capture a usb log and view it in message analyzer
d
Bent from my phone
From: xxxxx@gmail.commailto:xxxxx
Sent: ?10/?9/?2014 1:58 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Investigate the dispatch table
Is there any possible way to get the same traffic (or part of it) as UsbTrace tool, without using a filter driver?
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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</mailto:xxxxx></mailto:xxxxx>
Yes, but…
It is my master diploma project “Monitoring of communication between drivers” with a focus on USB3 drv. I can mention there capturing logs as one of the methods of viewing the traffic, but the main idea was to compare method using a filter driver and a method using a separate driver hooking a routine responsible for communication (I already did it on NtDeviceIoControlFile but it gives me only IOCTLs going to the user mode). So I have to implement the solution I want to compare. I just want to know if it is possible to capture communication between two kernel drivers using third - separate driver (even if disabling WP in CR0 is necessary for a while)
It will be pretty difficult to create any kind of generic facility to monitor communication between drivers.
Many drivers exchange direct call interfaces (often using the QueryInterface mechanism) and ONLY the communicating drivers actually know the layout of the interface structure. It can have function pointers, going both directions, and other tidbits of data for the drivers to get to know each other. All you might be abel to do is notice the QueryInterface ioctl and what it?s header said, which often is in a standard format and uses a guid to identify the interface. These guids are often only understood by the communicating drivers.
Once the interface has been exchanged, the drivers are free to directly call each other via function pointers directly or indirectly contained in the interface. Private call interfaces are pretty common in some areas, like most kinds of NDIS network drivers are not using irps to communicate.
Driver can also communicate via PnP interface notifications, or can register callback objects, or make WMI calls to each other.
An example of a really less than obvious inter driver communication method would be something like hardware that exposed multiple devices (or example SRIOV child devices). I?ve seen examples where the drivers for child devices could send messages to/from the parent via registers in the firmware/hardware, implementing inter VM/driver communication. Unless you understood what the firmware/hardware command interface was, it would be very difficult to figure out that writing a message to offset 0x128 on some memory bar for a device projected into a VM could then be received by some driver in a different VM by reading address 0x124. SRIOV is designed with the idea that a hypervisor doesn?t want to give full control of the hardware to guest VMs, so guest VM drivers may need to make service requests to the parent driver, and one way to implement this is via firmware/hardware service request tunnels.
There are lots and lots of alternatives ways for drivers to communicate with each other.
Jan
On Oct 9, 2014, at 11:49 PM, xxxxx@gmail.com wrote:
Yes, but…
It is my master diploma project “Monitoring of communication between drivers” with a focus on USB3 drv. I can mention there capturing logs as one of the methods of viewing the traffic, but the main idea was to compare method using a filter driver and a method using a separate driver hooking a routine responsible for communication (I already did it on NtDeviceIoControlFile but it gives me only IOCTLs going to the user mode). So I have to implement the solution I want to compare. I just want to know if it is possible to capture communication between two kernel drivers using third - separate driver (even if disabling WP in CR0 is necessary for a while)
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
xxxxx@gmail.com wrote:
It is my master diploma project “Monitoring of communication between drivers” with a focus on USB3 drv.
Well, what do you mean by that? It’s certainly possible to monitor the
communication between USB client drivers and the host stack
(hub/controller) using a filter driver. But the communication between
members of the host stack is internal.
Is your project specifically Windows-only?
…(I already did it on NtDeviceIoControlFile but it gives me only IOCTLs going to the user mode).
Ioctls don’t go to user mode. Do you mean ioctls coming from user mode?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
@Tim Roberts,
Yes, my project is for Windows 7/8 only.
“Ioctls don’t go to user mode. Do you mean ioctls coming from user mode?”
Yes, I mean that I have the input and the output buffer of IOCTLs from user mode
I think that a filter driver capturing communication between Root Hub and Controller will do.
I hoped that I could hook a routine responsible for communication between root hub and controller. I just need some communication captured by a driver implemented by myself, and do some experiments how different devices plugged in USB port affect the communication.