The WinpkFilter development kit no longer includes VB6 samples. Version 3.2.3 has added support for IPv6, resulting in a number of changes to the data formats. I have taken the liberty to update the older samples to support the newer formats, and with permission, I am posting them here.
Unfortunately I still have not got the low level filter table to load, but I will post the results upon completion.
The problem with the low level filter turned out to be 2 fold. The first problem was that when I upgraded from NDISRD V3.0.7 to V3.2.3, the library file that acts as a buffer between the application and the driver (NDISapi.dll) did not get upgraded. Part of the job of that library file is to check the size of the filter table before passing it on to the driver. The filter table is composed of a variety of individual static filters, each one 181 bytes in length. The older helper file was based on a static filter size of 116 bytes. Library files can be located in the application directory, or as I have done in the System32 (SysWow64 for 64 bit systems) directory. This why it did not get upgraded.
The second problem is also related to filter size. The original Static Filter used 3 byte padding when a single byte was allocated to a variable. That meant that each filter size was always divisible by 4. In this newer version, the Static Filter (181 bytes) is not divisible by 4. Visual Basic appears to assign memory to variables based on a word (4 byte) boundary. Even though the individual filters were the correct length, there were 3 extra bytes between the first and second filters. This anomaly has been corrected by copying the filters to a single byte array, and then copying it back to the table. It's a kludge, but it works.
The filter example is basically the PassThru example, but with only the DNS packets being processed. Unlike the original samples, this sample combines the 3 ".bas" modules into a single module, and adds the filter definitions.
Thank you! You don't have a VB6 Firewall ready, do you?
If memory serves me correctly (which it doesn't always these days), this work was designed to address attempts to flood our DNS server with DNS requests. DNS requests use UDP packets, which unlike TCP packets are not source verifiable. The attacks were not targeting our network directly, but when combined with many other DNS servers were being used to flood a specific network target by forwarding those requests.
Since we no longer operate a DNS server, the need for a filter is no longer required, and the software has not been maintained. For my own purposes, the MS Firewall is quite adequate.
Reply With Quote
Originally Posted by tmighty2
