Hi ,
I have hooked NtDeviceIOCOntrol for a specific control code. My hook function is hit when call is made from User layer to the underlying kernel.
In my hook function I call the NtDll’s original NtDeviceIoControl.
Now I want to access the buffer that has been modified by original call. My hook function doesn’t get a hit when DeviceIOControl call is from kernel to user mode.
Please if some one can share some suggestion.
Thanks
Anshul Makkar
www.justkernel.com
— On Mon, 16/5/11, xxxxx@mcmaster.ca wrote:
> From: xxxxx@mcmaster.ca
> Subject: [ntdev] Questions about NDIS
> To: “Windows System Software Devs Interest List”
> Date: Monday, 16 May, 2011, 9:51 PM
> Hello all,
>
> I’m a student currently looking into Windows Drivers, and
> I’m having trouble understanding the concepts behind the
> various types of NDIS drivers.? There’s a lot of
> information out there, but I couldn’t find a good summary to
> start with.? Here’s how I understand it right now - I’m
> not entirely sure of this, so please correct me if I’m
> wrong.
>
> NDIS 5.1
> ====================
> Definitions
> --------------------
> Miniport Driver: A driver that talks directly to a network
> device (i.e. NIC)
>
> Protocol Driver: A driver that implements an interface to a
> protocol.? For example, TCP/IP.? This driver
> forwards packets to an intermediate or miniport driver.
>
> Intermediate Driver: A driver that pretends to be a
> miniport to all drivers “above” it, and pretends to be a
> protocol driver to all drivers “below” it.? Receives
> packets from a protocol or intermediate driver above, and
> then forwards them below to another intermediate or the
> miniport driver.
>
> Filter-Hook Driver: Filters packets.? I’m not sure
> exactly where this comes in.? Can someone elaborate?
>
> Miscellaneous Info
> --------------------
> A “protocol driver” implements a network protocol - for
> example, tcpip.sys implements the TCP/IP protocol.
>
> Firewall drivers can be a filter-hook driver, or an
> intermediate driver.
>
> The documentation for NDIS 5.X is really sparse…
>
>
>
> NDIS 6
> ====================
> Definitions
> --------------------
> Miniport Driver: Same as above.
>
> Protocol Driver: Same as above.
>
> Intermediate Driver: As above - they export a miniport
> interface to all protocol/intermediate drivers above, and a
> protocol interface to all intermediate/miniport drivers
> below.
>
> Filter Driver: Drivers that are attached to the miniport
> driver.? I’m not sure where this fits in to the
> architecture - are they layered above the intermediate
> drivers?? Below?? In parallel with?? I’d
> appreciate it if someone could clarify.
>
> Miscellaneous Info
> --------------------
> Firewall drivers should be an intermediate or filter
> driver, or use the Windows Filtering Platform.? (Can
> someone please list the pros and cons of each of these?)
>
> What’s the difference between versions of NDIS 6.X??
> I.e. 6.0 vs. 6.1 vs. 6.20?
>
>
> If you have any other information to provide, it would be
> much appreciated 
>
> Best Regards.
>
> —
> 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
>
Go look at the archives, hooking is beyond discouraged. I doubt you
will get any help here.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“anshul makkar” wrote in message
news:xxxxx@ntdev:
> Hi ,
>
> I have hooked NtDeviceIOCOntrol for a specific control code. My hook function is hit when call is made from User layer to the underlying kernel.
>
> In my hook function I call the NtDll’s original NtDeviceIoControl.
>
> Now I want to access the buffer that has been modified by original call. My hook function doesn’t get a hit when DeviceIOControl call is from kernel to user mode.
>
> Please if some one can share some suggestion.
>
> Thanks
> Anshul Makkar
> www.justkernel.com
>
> — On Mon, 16/5/11, xxxxx@mcmaster.ca wrote:
>
> > From: xxxxx@mcmaster.ca
> > Subject: [ntdev] Questions about NDIS
> > To: “Windows System Software Devs Interest List”
> > Date: Monday, 16 May, 2011, 9:51 PM
> > Hello all,
> >
> > I’m a student currently looking into Windows Drivers, and
> > I’m having trouble understanding the concepts behind the
> > various types of NDIS drivers. There’s a lot of
> > information out there, but I couldn’t find a good summary to
> > start with. Here’s how I understand it right now - I’m
> > not entirely sure of this, so please correct me if I’m
> > wrong.
> >
> > NDIS 5.1
> > ====================
> > Definitions
> > --------------------
> > Miniport Driver: A driver that talks directly to a network
> > device (i.e. NIC)
> >
> > Protocol Driver: A driver that implements an interface to a
> > protocol. For example, TCP/IP. This driver
> > forwards packets to an intermediate or miniport driver.
> >
> > Intermediate Driver: A driver that pretends to be a
> > miniport to all drivers “above” it, and pretends to be a
> > protocol driver to all drivers “below” it. Receives
> > packets from a protocol or intermediate driver above, and
> > then forwards them below to another intermediate or the
> > miniport driver.
> >
> > Filter-Hook Driver: Filters packets. I’m not sure
> > exactly where this comes in. Can someone elaborate?
> >
> > Miscellaneous Info
> > --------------------
> > A “protocol driver” implements a network protocol - for
> > example, tcpip.sys implements the TCP/IP protocol.
> >
> > Firewall drivers can be a filter-hook driver, or an
> > intermediate driver.
> >
> > The documentation for NDIS 5.X is really sparse…
> >
> >
> >
> > NDIS 6
> > ====================
> > Definitions
> > --------------------
> > Miniport Driver: Same as above.
> >
> > Protocol Driver: Same as above.
> >
> > Intermediate Driver: As above - they export a miniport
> > interface to all protocol/intermediate drivers above, and a
> > protocol interface to all intermediate/miniport drivers
> > below.
> >
> > Filter Driver: Drivers that are attached to the miniport
> > driver. I’m not sure where this fits in to the
> > architecture - are they layered above the intermediate
> > drivers? Below? In parallel with? I’d
> > appreciate it if someone could clarify.
> >
> > Miscellaneous Info
> > --------------------
> > Firewall drivers should be an intermediate or filter
> > driver, or use the Windows Filtering Platform. (Can
> > someone please list the pros and cons of each of these?)
> >
> > What’s the difference between versions of NDIS 6.X?
> > I.e. 6.0 vs. 6.1 vs. 6.20?
> >
> >
> > If you have any other information to provide, it would be
> > much appreciated
> >
> > Best Regards.
> >
> > —
> > 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
> >
Forget hooking and produce a filter.
Gary G. Little
Certified Contest Administrator
C 952-454-4629
H 952-223-1349
On May 16, 2011, at 12:22, “Don Burn” wrote:
> Go look at the archives, hooking is beyond discouraged. I doubt you will get any help here.
>
>
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
>
> “anshul makkar” wrote in message news:xxxxx@ntdev:
>
>> Hi ,
>>
>> I have hooked NtDeviceIOCOntrol for a specific control code. My hook function is hit when call is made from User layer to the underlying kernel.
>>
>> In my hook function I call the NtDll’s original NtDeviceIoControl.
>>
>> Now I want to access the buffer that has been modified by original call. My hook function doesn’t get a hit when DeviceIOControl call is from kernel to user mode.
>>
>> Please if some one can share some suggestion.
>>
>> Thanks
>> Anshul Makkar
>> www.justkernel.com
>>
>> — On Mon, 16/5/11, xxxxx@mcmaster.ca wrote:
>>
>> > From: xxxxx@mcmaster.ca
>> > Subject: [ntdev] Questions about NDIS
>> > To: “Windows System Software Devs Interest List”
>> > Date: Monday, 16 May, 2011, 9:51 PM
>> > Hello all,
>> >
>> > I’m a student currently looking into Windows Drivers, and
>> > I’m having trouble understanding the concepts behind the
>> > various types of NDIS drivers. There’s a lot of
>> > information out there, but I couldn’t find a good summary to
>> > start with. Here’s how I understand it right now - I’m
>> > not entirely sure of this, so please correct me if I’m
>> > wrong.
>> >
>> > NDIS 5.1
>> > ====================
>> > Definitions
>> > --------------------
>> > Miniport Driver: A driver that talks directly to a network
>> > device (i.e. NIC)
>> >
>> > Protocol Driver: A driver that implements an interface to a
>> > protocol. For example, TCP/IP. This driver
>> > forwards packets to an intermediate or miniport driver.
>> >
>> > Intermediate Driver: A driver that pretends to be a
>> > miniport to all drivers “above” it, and pretends to be a
>> > protocol driver to all drivers “below” it. Receives
>> > packets from a protocol or intermediate driver above, and
>> > then forwards them below to another intermediate or the
>> > miniport driver.
>> >
>> > Filter-Hook Driver: Filters packets. I’m not sure
>> > exactly where this comes in. Can someone elaborate?
>> >
>> > Miscellaneous Info
>> > --------------------
>> > A “protocol driver” implements a network protocol - for
>> > example, tcpip.sys implements the TCP/IP protocol.
>> >
>> > Firewall drivers can be a filter-hook driver, or an
>> > intermediate driver.
>> >
>> > The documentation for NDIS 5.X is really sparse…
>> >
>> >
>> >
>> > NDIS 6
>> > ====================
>> > Definitions
>> > --------------------
>> > Miniport Driver: Same as above.
>> >
>> > Protocol Driver: Same as above.
>> >
>> > Intermediate Driver: As above - they export a miniport
>> > interface to all protocol/intermediate drivers above, and a
>> > protocol interface to all intermediate/miniport drivers
>> > below.
>> >
>> > Filter Driver: Drivers that are attached to the miniport
>> > driver. I’m not sure where this fits in to the
>> > architecture - are they layered above the intermediate
>> > drivers? Below? In parallel with? I’d
>> > appreciate it if someone could clarify.
>> >
>> > Miscellaneous Info
>> > --------------------
>> > Firewall drivers should be an intermediate or filter
>> > driver, or use the Windows Filtering Platform. (Can
>> > someone please list the pros and cons of each of these?)
>> >
>> > What’s the difference between versions of NDIS 6.X?
>> > I.e. 6.0 vs. 6.1 vs. 6.20?
>> >
>> >
>> > If you have any other information to provide, it would be
>> > much appreciated
>> >
>> > Best Regards.
>> >
>> > —
>> > 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
anshul makkar wrote:
I have hooked NtDeviceIOCOntrol for a specific control code. My hook function is hit when call is made from User layer to the underlying kernel.
In my hook function I call the NtDll’s original NtDeviceIoControl.
Now I want to access the buffer that has been modified by original call. My hook function doesn’t get a hit when DeviceIOControl call is from kernel to user mode.
DeviceIoControl is never called from kernel to user mode. The buffer is
modified when the request is completed. If the request is synchronous,
that will be when NtDeviceIoControl returns. If the request is
asynchronous (meaning there is an overlapped structure), then your
hooking is not enough. You’d have to wait until the overlapped event
fires, which is usually done in user move by calling GetOverlappedResult.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
On Mon, May 16, 2011 at 6:18 PM, anshul makkar
wrote:
> I have hooked NtDeviceIOCOntrol for a specific control code. My hook function is hit when call is made from User layer to the underlying kernel.
> In my hook function I call the NtDll’s original NtDeviceIoControl.
> Now I want to access the buffer that has been modified by original call. My hook function doesn’t get a hit when DeviceIOControl call is from kernel to user mode.
This discussion is like boomerang and the answer is always the same:
do not hook (as Don and Garry already pointed out). And hooking just
DeviceIoControl is not gonna work for asynchronous I/O (device access
in overlapped mode in user mode).
I think that you need to understand some fundamentals about how I/O
subsystem works (IRPs, pending, completing, etc.).
Kris