New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Npcap: Monitor mode capture dies after malformed packet delivered #1001

Closed
SapientGuardian opened this Issue Sep 4, 2017 · 18 comments

Comments

Projects
None yet
3 participants
@SapientGuardian

SapientGuardian commented Sep 4, 2017

Hello,

I am experiencing an issue capturing 802.11 traffic in monitor mode using Npcap: After a seemingly arbitrary number of packets have been captured successfully (I've observed anywhere from 200 to 20000), a malformed packet will be delivered, and then no more packets will be seen until the capture is restarted.

The malformed packet appears to contain a valid radiotap header with legitimate data, but it is prefixed with other data (possibly suggesting some sort of buffer overflow). You can see in "bad.png" that there's a broadcast frame very similar to the one in "good.png", but it's 8 bytes in.

I have reproduced this problem with an Alfa AWUS036H and a Linksys WUSB600N USB adapter, on a custom built desktop and on a Surface Pro 4. On both systems, I have observed the problem using Wireshark and using a custom application that utilizes SharpPcap. Both systems are running Windows 10 with all mainline (not insider) updates applied. Both systems are running Npcap 0.94 in non-winpcap-compatible mode.

I have attached the DiagReport, install.log, and NPFInstall.log files from the desktop.

NpcapIssue.zip

@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Sep 18, 2017

It looks like it might be an alignment problem. The bad packet starts with 7 bytes: 43 5f 55 55 10 3c 00. The good packet ends with a similar 7 bytes: 43 5e 00 62 32 2f 00. Do you know if those ending bytes are expected? In other words, are they valid data for the good packet, or did they leak from memory somewhere, ending up at the end of the packet instead of the beginning as in the bad case?

dmiller-nmap commented Sep 18, 2017

It looks like it might be an alignment problem. The bad packet starts with 7 bytes: 43 5f 55 55 10 3c 00. The good packet ends with a similar 7 bytes: 43 5e 00 62 32 2f 00. Do you know if those ending bytes are expected? In other words, are they valid data for the good packet, or did they leak from memory somewhere, ending up at the end of the packet instead of the beginning as in the bad case?

@SapientGuardian

This comment has been minimized.

Show comment
Hide comment
@SapientGuardian

SapientGuardian Sep 18, 2017

Thanks for the reply. I'm not seeing a whole lot of similarity between those two sets of 7 bytes, and I wasn't able to find them in a similar beacon frame from the same AP. I've attached another capture, which contains three packets:

  1. A good beacon frame from the Zoom5019 AP (doesn't look like there's overlap with the bad packet for those "misplaced" bytes)
  2. A good beacon frame from another AP, which was the packet immediately preceeding the malformed packet (thought this might be useful, as proof that the last 7 bytes of this one aren't the first 7 bytes of the malformed one)
  3. The malformed packet containing a beacon from Zoom5019, which killed this capture.

Samples.zip

SapientGuardian commented Sep 18, 2017

Thanks for the reply. I'm not seeing a whole lot of similarity between those two sets of 7 bytes, and I wasn't able to find them in a similar beacon frame from the same AP. I've attached another capture, which contains three packets:

  1. A good beacon frame from the Zoom5019 AP (doesn't look like there's overlap with the bad packet for those "misplaced" bytes)
  2. A good beacon frame from another AP, which was the packet immediately preceeding the malformed packet (thought this might be useful, as proof that the last 7 bytes of this one aren't the first 7 bytes of the malformed one)
  3. The malformed packet containing a beacon from Zoom5019, which killed this capture.

Samples.zip

@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Oct 18, 2017

In an effort to get better diagnostics, I have left detailed directions on #1036 to run Windows Driver Verifier, which may produce a crash dump that we can debug. Please follow the directions and let us know how it works: #1036 (comment)

dmiller-nmap commented Oct 18, 2017

In an effort to get better diagnostics, I have left detailed directions on #1036 to run Windows Driver Verifier, which may produce a crash dump that we can debug. Please follow the directions and let us know how it works: #1036 (comment)

@SapientGuardian

This comment has been minimized.

Show comment
Hide comment
@SapientGuardian

SapientGuardian Oct 19, 2017

Followed the instructions, didn't get a BSOD when the malformed packet came through. Tried it a couple times just to make sure.

SapientGuardian commented Oct 19, 2017

Followed the instructions, didn't get a BSOD when the malformed packet came through. Tried it a couple times just to make sure.

dmiller-nmap pushed a commit to nmap/npcap that referenced this issue Oct 23, 2017

Fix some issues with Radiotap headers.
Only the BPF header must be contiguous. By treating Radiotap header
specially, we ended up with uninitialized bytes at the beginning of
802.11 frames, and an equivalent amount truncated from the end.

Also, we were not considering the length of the Radiotap header in
checking if there was enough free space in the circular buffer. This
could lead to overlapping/overwriting frames that should be dropped
instead.

Possibly related issues:
* nmap/nmap#1001
* nmap/nmap#1028
* nmap/nmap#1036
@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Oct 23, 2017

Unfortunately, I didn't find the (possible/untested) fix for this until after Npcap 0.95 was released, so you'll have to wait a bit until I can get it tested and packaged. Npcap 0.95 still has this bug.

dmiller-nmap commented Oct 23, 2017

Unfortunately, I didn't find the (possible/untested) fix for this until after Npcap 0.95 was released, so you'll have to wait a bit until I can get it tested and packaged. Npcap 0.95 still has this bug.

@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Nov 1, 2017

Npcap 0.96 has been released, which ought to solve this issue. Please let us know so we can close this issue. https://nmap.org/npcap/

dmiller-nmap commented Nov 1, 2017

Npcap 0.96 has been released, which ought to solve this issue. Please let us know so we can close this issue. https://nmap.org/npcap/

@SapientGuardian

This comment has been minimized.

Show comment
Hide comment
@SapientGuardian

SapientGuardian Nov 1, 2017

I'm afraid this has not fixed the issue. The behavior is the same as initially reported. I can attach fresh copies of the diag/install logs if you like, but I didn't see anything too interesting in them (and they do report that the version is 0.96).

SapientGuardian commented Nov 1, 2017

I'm afraid this has not fixed the issue. The behavior is the same as initially reported. I can attach fresh copies of the diag/install logs if you like, but I didn't see anything too interesting in them (and they do report that the version is 0.96).

@SapientGuardian

This comment has been minimized.

Show comment
Hide comment
@SapientGuardian

SapientGuardian Nov 11, 2017

Good news: I'm no longer able to reproduce this problem. I'm not sure what's changed in the last 10 days - maybe somehow my system was holding onto Npcap 0.95. Thanks for the fix!

SapientGuardian commented Nov 11, 2017

Good news: I'm no longer able to reproduce this problem. I'm not sure what's changed in the last 10 days - maybe somehow my system was holding onto Npcap 0.95. Thanks for the fix!

@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Nov 13, 2017

@SapientGuardian Thanks for confirming this. Since WiFi capture works without crashing, could you do us a huge favor and report your network card, OS, and level of support on the WiFi Adapters page at SecWiki.org? If you'd rather reply here or via email, that's fine, too, and we can handle the formatting:

  • Adapter name/model number
  • Firmware or Driver version
  • Windows version
  • Monitor mode box available in Wireshark?
  • Capture works in monitor mode?
  • No Frame Check (FCS) errors reported by Wireshark?
  • Channel/frequency reported for each frame in Wireshark?
  • RSSI reported for each frame in Wireshark?
  • Npcap version tested
  • Any extra notes or observations you have.

Thanks so much!
 

dmiller-nmap commented Nov 13, 2017

@SapientGuardian Thanks for confirming this. Since WiFi capture works without crashing, could you do us a huge favor and report your network card, OS, and level of support on the WiFi Adapters page at SecWiki.org? If you'd rather reply here or via email, that's fine, too, and we can handle the formatting:

  • Adapter name/model number
  • Firmware or Driver version
  • Windows version
  • Monitor mode box available in Wireshark?
  • Capture works in monitor mode?
  • No Frame Check (FCS) errors reported by Wireshark?
  • Channel/frequency reported for each frame in Wireshark?
  • RSSI reported for each frame in Wireshark?
  • Npcap version tested
  • Any extra notes or observations you have.

Thanks so much!
 

@SapientGuardian

This comment has been minimized.

Show comment
Hide comment
@SapientGuardian

SapientGuardian Nov 13, 2017

Certainly. Just waiting for my account to get approved.

SapientGuardian commented Nov 13, 2017

Certainly. Just waiting for my account to get approved.

@SapientGuardian

This comment has been minimized.

Show comment
Hide comment
@SapientGuardian

SapientGuardian Nov 16, 2017

@dmiller-nmap I never got account approval, so here's the data requested:

Adapter: Alfa AWUS036H
Driver: Realtek RTL8187 Wireless 802.11b/g 54Mbps USB 2.0 Network Adapter, version 6.1316.1209.2009
Windows version: Windows 10 Pro 1709 build 16299.64
Monitor mode in Wireshark: Yes
Capture works in monitor mode: Yes
No FCS errors reported: Yes (no errors)
Channel/frequency reported: No (always 0)
RSSI reported: Yes (e.g. -69dBm)
Npcap version tested: 0.96

SapientGuardian commented Nov 16, 2017

@dmiller-nmap I never got account approval, so here's the data requested:

Adapter: Alfa AWUS036H
Driver: Realtek RTL8187 Wireless 802.11b/g 54Mbps USB 2.0 Network Adapter, version 6.1316.1209.2009
Windows version: Windows 10 Pro 1709 build 16299.64
Monitor mode in Wireshark: Yes
Capture works in monitor mode: Yes
No FCS errors reported: Yes (no errors)
Channel/frequency reported: No (always 0)
RSSI reported: Yes (e.g. -69dBm)
Npcap version tested: 0.96

@natiya

This comment has been minimized.

Show comment
Hide comment
@natiya

natiya Nov 16, 2017

@SapientGuardian I'd like to check if the adapter you used is this one? Thanks!

natiya commented Nov 16, 2017

@SapientGuardian I'd like to check if the adapter you used is this one? Thanks!

@SapientGuardian

This comment has been minimized.

Show comment
Hide comment
@SapientGuardian

SapientGuardian Nov 16, 2017

@natiya I don't see a version number on mine, but it looks like the picture.

SapientGuardian commented Nov 16, 2017

@natiya I don't see a version number on mine, but it looks like the picture.

@natiya

This comment has been minimized.

Show comment
Hide comment
@natiya

natiya Nov 17, 2017

@SapientGuardian ok, thanks! Anyway, when you plug it in, doesn't have a GUI? Maybe there it says something

natiya commented Nov 17, 2017

@SapientGuardian ok, thanks! Anyway, when you plug it in, doesn't have a GUI? Maybe there it says something

@SapientGuardian

This comment has been minimized.

Show comment
Hide comment
@SapientGuardian

SapientGuardian Nov 17, 2017

No GUI, sorry.

SapientGuardian commented Nov 17, 2017

No GUI, sorry.

@natiya

This comment has been minimized.

Show comment
Hide comment
@natiya

natiya Nov 18, 2017

@SapientGuardian so how do you configure it in order to receive WiFi?

natiya commented Nov 18, 2017

@SapientGuardian so how do you configure it in order to receive WiFi?

@SapientGuardian

This comment has been minimized.

Show comment
Hide comment
@SapientGuardian

SapientGuardian Nov 18, 2017

Just the built-in Windows wifi interface that isn't specific to any adapter.

SapientGuardian commented Nov 18, 2017

Just the built-in Windows wifi interface that isn't specific to any adapter.

@natiya

This comment has been minimized.

Show comment
Hide comment
@natiya

natiya Jan 5, 2018

@SapientGuardian I've tried the adapter you've got and there is Monitor Mode in Wireshark but all the packets are malformed. Are yours correctly captured? Is there anything that you installed/uninstalled such as WinPcap or something else?

natiya commented Jan 5, 2018

@SapientGuardian I've tried the adapter you've got and there is Monitor Mode in Wireshark but all the packets are malformed. Are yours correctly captured? Is there anything that you installed/uninstalled such as WinPcap or something else?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment