Closed Xpltr closed 3 years ago
morrownr
commented
3 years ago I'll check this out and report back. This is likely something that can be cleaned up without breaking anything.
Side note: Could you give me a report on the performance of monitor mode and injection. Is injection working on both bands or just 2.4?
Xpltr
commented
3 years ago This part covers the injection you asked for. So far, all of the 2.4ghz injection is working. Now the 5ghz injections work but with some caveats. This was tested with "networkManager" switched off per airmon-ng check kill, then checked ps fax|grep networking*. Used tcpdump to check for deauth pkts. Injection 5G: It works when you target the AP frequency or channel, using iwconfig, then target the AP using Aireplay-ng -a BSSID. Injection didn't work when I set the AP channel, then just ran "aireplay-ng --test wlan1".
This is the module set up per lsmod.
8814au 2752512 0 iwlmvm 339968 0 mac80211 983040 1 iwlmvm libarc4 16384 1 mac80211 iwlwifi 294912 1 iwlmvm cfg80211 970752 4 8814au,iwlmvm,iwlwifi,mac80211 usbcore 323584 5 8814au,xhci_hcd,usbhid,btusb,xhci_pci
2.4 Results:
Trying broadcast probe requests... Injection is working! Found 6 APs 0x:0x:0x:0x:0x:0x - channel: 10 - 'proxnet' Ping (min/avg/max): 4.054ms/36.223ms/148.537ms Power: -77.93 30/30: 100%
5ghz Results //Test without targeting AP bssid mac
Trying broadcast probe requests... No Answer... Found 0 APs
//Test with target AP bssid mac
Waiting for beacon frame (BSSID: 0x:0x:0x:0x:0x:0x) on channel 153 NB: this attack is more effective when targeting a connected wireless client (-c <client's mac>).
Sending DeAuth (code 7) to broadcast -- BSSID: [0x:0x:0x:0x:0x:0x]
Sending DeAuth (code 7) to broadcast -- BSSID: [0x:0x:0x:0x:0x:0x]6.0 Mb/s 5785 MHz 11a -86dBm signal antenna 0 1.0 Mb/s [bit 15] DeAuthentication (0x:0x:0x:0x:0x:0x (oui Unknown)): Class 3 frame received from nonassociated STA 1.0 Mb/s [bit 15] DeAuthentication (0x:0x:0x:0x:0x:0x (oui Unknown)): Class 3 frame received from nonassociated STA 40074 packets captured 40076 packets received by filter 0 packets dropped by kernel
Xpltr
commented
3 years ago Also, about the errors issue I posted, a post stated the file in /lib/udev/rules.d/69-libmtp.rules may be trying to mount the Alfa card as a MTP device, since it says "mtp-probe" in the /var/log/user.log file. I annexed the 69-libmtp.rules file. The "mtp-probe" messages stopped but the Alfa card with driver in managed mode the same :
183.429238] start_addr=(0x30000), end_addr=(0x40000), buffer_size=(0x10000), smp_number_max=(8192) [ 226.441230] start_addr=(0x30000), end_addr=(0x40000), buffer_size=(0x10000), smp_number_max=(8192)
...messages appear in "dmesg". Other suggestion was to kill the "MTP Automount" features of "Lightdm". That may be the functions thats calling the Alfa wifi card. Below, the driver is listed in the "usbcore".
Bus 002 Device 003: ID 0bda:8813 Realtek Semiconductor Corp. RTL8814AU 802.11a/b/g/n/ac Wireless Adapter
btusb 61440 0 btrtl 24576 1 btusb btbcm 20480 1 btusb btintel 32768 1 btusb bluetooth 737280 5 btrtl,btintel,btbcm,btusb usbhid 65536 0 hid 147456 2 usbhid,hid_generic usbcore 323584 5 8814au,xhci_hcd,usbhid,btusb,xhci_pci usb_common 16384 2 xhci_hcd,usbcore
exploiter mtp-probe: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-6" exploiter mtp-probe: bus: 1, device: 6 was not an MTP device exploiter upowerd[1059]: treating change event as add on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-6
morrownr
commented
3 years ago Regarding "start_addr=(0x30000), end_addr=(0x40000), buffer_size=(0x10000), smp_number_max=(8192)"
I investigated this earlier this evening. It appears to me that the coding to output this line is related to debugging and nothing more. It is not done in a manner that is consistent with other debug related code which may indicate a coder that added something when working a problem but then forgot to clean up the mess. I could see no good reason for the code to be active at this point so I commented it out and committed the patch. If something comes up later, we can reactivate it.
To test, you can run the ./remove-driver.sh script and then delete the 8814au folder. Then you can start the installation from the beginning. Let me know what you think.
Thanks for the injection report. I am going to do some testing myself as soon as I get time to see if there is something we can do to clean up monitor mode support. I started an Issue just for Monitor Mode so if you want to follow along, please do.
Xpltr
commented
3 years ago Thanks for the patch, the messages are gone, awesome. And Injection is working on both 2.4ghz & 5ghz!! I'm using Kali 5.10.0-kali4-amd64 kernel. I just set the channel first for the card to the channel the AP is using, then "aireplay-ng --test wlan1" or aireplay-ng --test -a 0x:0x:0x:0x:0x:0x wlan1 "aireplay-ng -0 100 -a 0x:0x:0x:0x:0x:0x wlan1 All 3 show injection working on 5ghz. Thanks!
Trying broadcast probe requests...
Injection is working!
Found 11 APs
Trying directed probe requests...
0x:0x:0x:0x:0x:0x - channel: 149 - 'testnet'
Ping (min/avg/max): 2.320ms/7.344ms/13.269ms Power: -79.90
30/30: 100%Waiting for beacon frame (BSSID: 0x:0x:0x:0x:0x:0x) on channel 161
Trying broadcast probe requests...
Injection is working!
Found 1 AP
Trying directed probe requests...
0x:0x:0x:0x:0x:0x - channel: 161 - 'proxyNet'
Ping (min/avg/max): 1.911ms/6.370ms/8.560ms Power: -47.83
30/30: 100%I have now tested and can also confirm that injection and deauth are working.
Thanks for the information.
I have the Alfa AWUS1900 wifi card. I previously used those wifi drivers from Kali repos, then switched to Aircrack-NG driver but no injection from that driver. I uninstalled all those, then installed Morrownr/8814au driver. Injection works, but I noticed these repeat messages in 'dmesg' output:
183.429238] start_addr=(0x30000), end_addr=(0x40000), buffer_size=(0x10000), smp_number_max=(8192) [ 226.441230] start_addr=(0x30000), end_addr=(0x40000), buffer_size=(0x10000), smp_number_max=(8192)
Maybe someone already knows what these are but it does pertain to the driver, because when I remove the driver per the installation scripts, these messages disappear. But with the driver installed, these messages fill up the dmesg output, and I want to get rid of them. Also, when the wifi card is in monitor mode, per airmon-ng, these messages don't show up. These messages show up when the awus1900 is in 'managed mode'. I'm running two cards, one with Alfa driver, other card with 'iwlwifi' driver. Could this be the issue of both cards in 'managed mode'? Willing to post more info if needed.