Wifi NIC monitor mode on Android

I want to perform deauth attacks from my rooted android, but I know that in order to use aircrack-ng suite, I need not only root access (which I have) but a way to put my NIC into monitor mode. Problem is, I read that proprietary drivers on mobile NICs are not capable of monitor mode. How do I solve this problem?

some qualcomm chipsets can go into monitor mode, my xiaomi can w a custom kernel but at less is an old nexus you cant deauth since these are the only phones that can do packet injection with their internal wifi chipset. your best is to get a usb adapter, an otg cable and download the firmwares module in magisk manager to get the dongle function right and do packet injection. good luck

>>15991 >old nexus you cant deauth since these are the only phones This. Stop being poor and buy a Google™ smartphone like any sensible hacker would do.

>>15982 I bought a wireless usb that plugs into my phone for this sort of thing. https://www.ebay.com/p/219702385

>>15999 absolutely based trips

>>15991 How would you do it using an old Nexus which I happen to have?

>>15982 >I read that proprietary drivers on mobile NICs are not capable of monitor mode. How do I solve this problem? You can't*. The problem is not the driver it's the wifi chip itself. The USB, PCIe wifi cards you're used to are called SoftMAC, which means that the wifi functions are done by your OS, so you can do monitor mode and inject packets and stuff at will. The problem is that most mobile wifi chips are FullMAC, which means they do all the wifi stuff on the chip itself. Your OS just goes "join this network", "send this data", etc. So there's no way to do anything advanced like inject packets because all that stuff is abstracted. It's like trying to do heel-toe braking in an automatic. The transmission will just go, WTF you doing nigger that's not how this soykaf is supposed to work, and ignore you. * there are one or two projects for hacking the firmware on FullMAC chips to make them do monitor mode and packet injection. If you really need to do this on a mobile device you can look into that. Nexmon is the most famous project.

>>16007 Well, basically this. >>16016 depends on wich nexus is tho, but it's mostly just rooting, install nexmon firmware. I don't know if a custom kernel is required, but your best is just to install kali nethunter and is ready to work.

even more reason to upgrade into wifi ac/6 (for wifi router owners) >>15982 you can literally use busybox and check what your device is capable of

I wouldn't recommend using those devices for personal use. They suffer broadpwn. Might as well just buy a good ol' pi which you can be repurposed later.

>>16022 what does wifi ac/6 protect against deauths? I thought it still used the three way handshake? It's WPA3 that fixes deauth right? >>16034 Sincere thanks for teaching me a new vuln.

>>16055 >what does wifi ac/6 protect against deauths? You're asking wifi advice from the guy who thinks busybox has anything to do with wifi. >I thought it still used the three way handshake? It's WPA3 that fixes deauth right? The deauth problem is caused by not having any authentication on management frames. WPA3 adds authentication but now you have high processing cost to verifying that authentication which can lead to other denials of service attacks.

>>16060 Yeah plus wpa3 is vulnerable to derandomization attacks but you have to actually stay near the access point

Is it possible to attack WPA2 Enterprise with certificate validation in a realistic (meaning, something you can do now on a laptop or rooted device) capacity? As I understand, it is not possible outside of deauth/brute? I have read that if you capture the TLS exchange you can get the certificate that is exchanged and potential fool the device into passing credentials or handshaking from there but I have not tried it...

>>16072 Wait so you're saying WPA2 RADIUS servers use certificate based authentication like HTTPS? Also the easiest way into a Wifi network of any type that I know of is jamming/breaking it and using a rogue AP

>>16073 if anybody else is an expert, keep me honest... but iirc, essentially the AP and the supplicant handshake and then immediately depending on the build the supplicant will expect a certificate (which should be validated for an internal CA), to then authenticate to the radius via TLS... if the certificate is bad it rejects and deauths so ive read that you can in theory capture the certificate challenge since that has to happen in the clear... if the supplicant is authenticating via that and then if insecurely configured ) it will potentially hand over auth creds again i am not an expert but thats why krack/frag are a problem since they jack up that process

>>15982 Adding to this thread, I've recently found out that you may enter monitor mode if you hack you firmware. However, separate drivers (in your kernel cuz it's monolithic) are required in order to do injection (deauth attack). if you check out kimocoder on Github, they have a list of devices whose firmware has been hacked to enter monitor mode.