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?
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.
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.
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.
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
may help you