views:

40

answers:

2

Hi,

The question is pretty self-explanatory, I require the ability to open and control a socket from a kernel mode driver in windows xp. I know that vista and after provides a kernel mode winsock equivalent, but no such thing for XP.

Cheers

Edit I've had a recommendation to have a user-mode service doing the socket work, and one to use TDI. Which is best?

+1  A: 

Use TDI interface, it's avaliable on XP and Vista.

http://msdn.microsoft.com/en-us/library/ff565112.aspx

blaze
Worth noting perhaps that it is deprecated, and may be removed. It seems to remain available in Windows 7 though.
Jan
You may want to take a look at the book 'Rootkits' http://www.amazon.com/Rootkits-Subverting-Windows-Greg-Hoglund/dp/0321294319, which describes this problem in detail.
Justin
+1  A: 

TDI is not an easy interface to use. It is designed to abstract network transport drivers (TCP, NetBEUI, AppleTalk, etc) from applications. You will have to fully understand the API to be able to use it for socket work - this is certainly a lot more work than writing a user-mode service and communicating with that. You can issue a reverse IRP from the service to the driver, so the driver can trigger comms when it needs to.

Also, the more complexity you remove from your driver (here, into user-mode), the better.

However, using a user-mode service will require a context switch per data transfer to the driver, which for you might be on a per-packet basis. This is an overhead best avoided.

I'm curious as to why a driver needs to perform network I/O. This superficially at least seems to indicate a design issue.

Blank Xavier
I'm going to accept this, because yes, a brief look at TDI revealed tremendous complexity. I implemented a user mode service which had pending IRPs for notification from the driver, and passed data from the driver up to a socket, and from a socket down to the driver. In an attempt to reduce the number of context switches required, I chunked the data, so, for example, I would get all the available data on the socket before sending it to the driver. Finally, the reason I needed a driver to do network I/O is that it was a virtual serial port.
Kazar