Nmap Development mailing list archives
Fwd: Yang's status report - #10 of 16
From: Fyodor <fyodor () nmap org>
Date: Mon, 12 Aug 2013 11:45:28 -0700
We use Google as a first-pass spam-filter for this list, and it keeps blocking Yang's status reports. So here is today's report: ---------- Forwarded message ---------- From: veotax <hsluoyz () qq com> Date: Mon, Aug 12, 2013 at 11:02 AM Subject: Yang's status report - #10 of 16 Hi everyone, Here's my status report for week #10. After many investigations, I have decided to port NPcap again, from NDIS 6 protocol to NDIS 6 filter (also called Light-Weight Filter, LWF). Let me tell you why: Although the current NDIS 6 protocol is adequate for the capturing. It seems that WinPcap group wants it to be better. Initially we have two alternatives to port to. 1) Light-Weight Filter; 2) Windows Filter Platform. After some queries on stackoverflow.com. I personally think LWF is a better choice. Thanks Jeffrey Tippet from MSFT for many patient replies. Well, the previous porting from NDIS 5 protocol to NDIS 6 protocol can't been see as a waste of time. Actually protocols and filters for NDIS 6 share many features, like the data structure of packets: NetBufferList. So the previous porting has cracked many tough nuts towards the NDIS 6 filter driver. Here're some threads I posted on StackOverFlow.com, these may shed light on the LWF v.s. WFP stuff a little: Can a NDIS protocol driver (npf.sys of WinPcap) be ported to LWF or WFP? http://stackoverflow.com/questions/18073119/can-a-ndis-protocol-driver-npf-sys-of-winpcap-be-ported-to-lwf-or-wfp how to call NdisOpenAdapterEx or the alternative outside the ProtocolBindAdapter routine? http://stackoverflow.com/questions/17636148/how-to-call-ndisopenadapterex-or-the-alternative-outside-the-protocolbindadapter To sum up, LWF has two advantages than protocol: 1) An NDIS LWF will easily win on performance, since it doesn't force the slow loopback path for capturing TX packets. 2) LWFs also can see raw 802.11 packets (including probe response, authentication frames, etc, which are impossible for protocols to see So far, I have finished the filter driver prototype. It can capture packets. So Wireshark can work well now. However, there're still some bugs in the sending path, which leads to the failure of Nmap usage. Considering that I have bought the IEEE1394 debugging equipment (PCI cards and the cables), the debugging process will be a lot faster than before. Accomplishments: * Made some investigatons on LWF and WFP. At last LWF is chosen. * Read through the official documents about LWF. Finished the coding of the NDIS 6 LWF driver -- npf6x.sys. * Removed many bugs of the filter driver. Priorities: * Buy the driver signing license. * Finish the debugging work of the filter driver. * Have a meeting with my mentor for the next step. Cheers, Yang Luo http://veotax.com _______________________________________________ Sent through the dev mailing list http://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Fwd: Yang's status report - #10 of 16 Fyodor (Aug 12)