Home page logo
/

nmap-dev logo 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/


  By Date           By Thread  

Current thread:
  • Fwd: Yang's status report - #10 of 16 Fyodor (Aug 12)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]