Open TDiffff opened 6 years ago
TL;TR bring up a monitor interface BEFORE starting hostapd
Hi, I modified the nexmon driver for bcm43430a1 to allow an additional monitor interface instead of bringing the existing one into monitor mode. This functionality has been merged into the nexmon upstream repo and is used in the kali image.
Hostapd knows two operation modes:
1) legacy: hostapd opens a monitor interface to manage wifi clients 2) fmac chip: hostapd lets the wifi chip manage the wifi clients.
Now the unmodified broadcom driver forces hostapd to let the wifi chip manage the clients (as it doesn't allow adding a monitor interface). The modified driver allows adding a monitor interface, thus hostapd tries to manage the clients via its own monitor interface. This works for beaconing and probe responses (a client could see the network). But as soon as a wifi client tries to connect/asdociate, the wifi chip jumps back in and sends a deauth (because it hasn't seen the client/station before, as it was handled in software by hostapd).
This misbehavior could easily be circumvented, if a monitor interface is brought up before starting hostapd. The driver is written in a way, to decline monitor capabilities in case hostapd tries to add a second monitor interface. Ultimately hostapd will failover to legacy mode (let the chip manage clients) and everything works as intended.
Additional note: as far as I could tell, the kali build script uses an unmodified nexmon repo, which means P4wnP1 additions for Karma attacks and WiFi covert channel are missing. I'm currently working on a proper patch for the re4son kernel used by the Kali inage
TL;TR bring up a monitor interface BEFORE starting hostapd
Hi, thanks for the response! I tried using WIFI_NEXMON=true, it didn't work. Do I have to bring up a monitor interface with a bash command rather than using the setup.cfg?
Oh, it looks like my init_wifi.sh doesn't contain any sign of WIFI_NEXMON, and I don't have $wdir/boot/init_wifi_nexmon.sh etc. I assume it has been added after the Kali released their build, or what?
I'm confused right now.
This is because the Kali built comes with an own nexmon driver+firmware and uses different scripts. Legacy P4wnP1 uses a modified nexmon firmware, other scripts to interface with modifications (karma + firmware based wifi covert channel) and scripts to exchange nexmon with unmodified firmware if needed. Most of this seems to be missing in the Kali version, so please understand that I can't support in this till I moved from Raspbian to Kali myself. This will happen with release of P4wnP1 successor if no issues arise
Ok, so what do you suggest me to do until you release P4wnP1 sucessor? Installing Kali image and from there installing P4wnP1?
Use the release image from this repo and post install additional tools needed
If you want to bring up a monitor interface on the kali image, there should be a monstart
command available which does the job
If you want to bring up a monitor interface on the kali image, there should be a
monstart
command available which does the job
MANY THANKS! It works. You can close the issue. Now I can play with payloads using access point until you release your next gem 🥇 Again, thanks!
Hey guys, I opened an issue here : https://github.com/offensive-security/kali-arm-build-scripts/issues/137
Basically the problem is : The AP is seen from other devices, but they can't connect to it, no matter how I change the config of hostapd in the ~/P4wnP1/boot/init_wifi.sh script.
If you guys have / had the same issue and could help me get that sorted out, It'd be appreciated. Many thanks