I'm trying to create a windows driver that allows a standard TCP/IP socket to be used like a COM Port. I am aware of a number of existing products that do just this, but can find no reference material as to how it's actually done! I understand some of the concepts of windows drivers (bus/function/filter drivers, driver stacks, etc), and have tried reading a book on WDF, but I'm still not 100% sure on where I start if there is no actual backing hardware. If anyone has any links/pointers that will help, it would be much appreciated.
Kazar
Take a look at the com0com project. They also offer an com2tcp driver. As it is open source you can go through the sources and get an idea of how it's done.
Actually this is not a driver, but an app, so it might be less helpful in your task to learn something about driver development, but anyway could be a good starter for some technical insight.
Related
I study on entropy source using the Random number generator.
So I want to see a kernel source code.
However, I don't exactly know this, and i know this is not known.
Would you tell me about this?
Thanks.
Windows Driver Foundation forbids such actions due to obvious malicious stuff that can happen if the source code leaks
If you have access to enough information about the device you're using, you could try writing a skeleton driver. However, some TRNGs have open-source driver code, so if yours is one of them, you could download that. If those aren't options in your case, unfortunately proprietary software companies do not generally share their source code (though Microsoft does share their code with certain CS departments in academia - if you're affiliated with one, you could look into that).
What follows is really a learning exercise and not necessarily a search for a production solution. I've recently done a bunch of reading about Windows driver development and am looking for a first good exercise in practical application before potentially proceeding toward a future win10 mobile device family project.
Just to get my feet wet with win10 driver development, I was thinking it would be interesting to develop (and then publish) a filesystem driver project that implemented a dumb Windows equivalent of /dev/null or /dev/random - really, any virtual device that I can read a stream of data from.
I haven't done much Windows development in the past, but after reading through a couple books on Safari I've landed on MS's driver samples GitHub page, which seems like a good start, but doesn't seem to provide a clear way forward from what I've read so far.
Right now I'm still casting about with web searches and would sure appreciate some guidance in how to proceed toward this goal (references, reading materials, etc) I'll be happy to publish whatever silly project(s) I wind up generating for others to learn from in the future.
One of the best way to start Windows driver development is with toaster sample . It will provide you basic workable understanding of Windows driver development. You will be able to understand basics for writing bus driver, function driver and filter drivers(upper, lower) in Windows.
I know this is sort of a "Help me with my code" kind of website, but I could actually use a little help with just methodology.
I am looking to retrieve data from a USB device, this device is a fingerprint scanner. Because I bought it online and wasn't reading carefully enough, drivers and other installation programs weren't included. Send it back? Nah . . .
I want to see if it is possible to retrieve data from this device. To be honest, I don't even know if it's possible, but I would love to give it a whack.
I looked into making INF files and things Microsoft has put out, but I honestly don't know where to start simply because I have absolutely no experience doing this. I have a lot of a program set up to organize the data and such, just need to find a way to actually get it.
What should I research and look into?
I'd recommend starting my reading USB Complete. The first few chapters will give you a good overview of how USB works. This will give you a basic understanding of the protocol, types of transfers, descriptors and general usage of a device. You need this knowledge and terminology so you can understand the rest of the documentation below.
From there you will probably want to use WinUSB or hidapi to interface with the device. If the device is vendor specific then WinUSB is the best bet. If the device enumerates as an HID device then you won't need a kernel driver but you will need to interface with the hidapi to interface with the device. You can discover this by looking at the descriptors through some tool like UVCView.exe, or looking to see if the HID driver is loaded in Device Manager (if it's not you will probably have an unidentified device).
Are filter drivers intended to extend system drivers?
Is this their main purpose?
Are they basically just an extra layer that sits between the driver and the user?
This seems overly simple an explanation and I am wondering if I am missing something.
Are there good ways to learn more?
The driver topic is a very advanced one.
To get an overview, you can have a closer look on the Windows Driver Kit (WDK) sides.
If you decide to get into this stuff, then you need a lot of time, frustration resistance and fanaticism.
The first thing you should do (befor you touch the WDK!) is, to start reading a good book.
If you want to develop for windows file system, read Rajeev Nagar's book "Windows NT File System Internals : A Developer's Guide". It's published in 1997, but it's something like the "bible" of NTFS.
For common driver developement you can find books like "Developing Drivers with the Windows Driver Foundation", written by Penny Orwick.
These books describes programming kernel mode software, which is done in C language. So, you should have a good base knowlege on C before you start.
Among others there are the OSR side (www.osr.com) and SysInternals on technet (http://technet.microsoft.com/de-DE/sysinternals), which are truely worth to have a closer look on.
More than the halfe time you spend on reading debug outputs and crash dumps, so it's wise to know what these things are meaning and how to get this information, but there are good books for windows debugging too.
I hope, I was able to give a short overview on the question for the ways to learn more.
In a way yes.
For example, if file system filter driver is for file encryption/compression/security, it is enhancing the file system functionality.
The filter driver does not handle talking to actual devices. They rely on lower level drivers to communicate with device. The filter drivers are add-on to the drivers to implement certain functionality. The active drivers which modify data/request are to enhance vanilla drivers while the passive filter drivers are just pass-throughs without any direct enhancements.
So I think your assumptions are correct.
Will like to hear different views though.
I'd like to write a packet sniffer and editor for Windows. I want to able to see the contents of all packets entering and leaving my system and possibly modify them. Any language is fine but I'd like it to run fast enough that it won't burden the system.
I've read a little about WinPcap but the documentation claims that you can't use WinPcap to create a firewall because it can't drop packets. What tools will help me write this software?
Been there, done that :-) Back in 2000 my first Windows program ever was a filter hook driver.
What I did was implementing the filter hook driver and writing a userspace application that prepared a filter table on what to allow and what to disallow. When you get around your initial set of blue screens (see below for my debug tip in kernel mode) the filter mode driver is quite easy to use ... it gives each packet to a function you wrote and depending on the return code drops it or lets it pass.
Unfortunatley packets at that level are QUITE raw, fragments are not reassembled and it looks more like the "network card" end of things (but no ethernet headers anymore). So you'll have quite a bad time decoding the packets to filter with that solution.
There also is the firewall hook driver, as discussed in this codeproject article.
If you are on Vista or Server 2008 you'd better have a look at WFP (Windows Filtering Platform) instead, that seems to be the mandated API of the day for writing firewalls.
I don't know about it other than google turing it up some minutes ago when I googled for the filter hook driver.
Update: Forgot the debug tip:
Sysinternals DbgView shows kernel-mode DbgPrint output, and more important - it can also read them from the dump file your last blue screen produced. So sprinkle your code with dbgprint and if it bluescreens just load the dump into dbgview to see what happened before it died ... VERY useful. Using this I managed without having a kernel debugger.
I'm pretty sure you'd need to write a filter driver. http://en.wikipedia.org/wiki/Filter_driver I don't know much more than that :). It would definitely be a C/C++ Win32 app and you'd likely being doing some kernel side work. Start by downloading the DDK and finding some of the sample filter drivers.
If you just want to monitor what goes in and out of IIS, consider an ISAPI filter. Still C/C++ in Win32, but relatively easier than writing a device driver.
C# code to do this is here
I actually did this, several years ago. I'm hazy on the details at this point, but I had to develop a filter/pass-thru/intermediate driver using the Windows DDK. I got a lot of good information from pcausa. Here's a url which points to their product that does this: http://www.pcausa.com/pcasim/Default.htm
If you're doing this for practical reasons, and not just for fun, then you should take a look at Microsoft Network Monitor. The home page talks about the version 3.3 beta, but you can download version 3.2 from the Downloads page. There is also an SDK for NM, and the ability to write parsers for your own network protocols.
There's a question you need to ask which you don't know you need to ask; do you want to know which applications sockets belong to? or are you happy to be restricted to the IP:port quad for a connection?
If you want to know applications, you need to write a TDI filter driver, but that makes handling the receive almost impossible, since you can't block on the receive path.
If you're happy with IP:port, go in at the NDIS level, and I believe you can block on receive to your hearts content.
A word of warning; if you have no prior kernel experience, writing either of these drivers (although TDI is significantly harder) will take about two years, full time.
this:
TdiFw is a simple TDI-Based Open Source Personal Firewall for Windows NT4/2000/XP/2003
http://tdifw.sourceforge.net/
may help you