Simultaneous AP0 (ap), WLAN0 (client), MON0 (monitor mode) all at once?

[brybalicious]

Hi there,

I've been searching around for the ability to put a pi zero w into simultaneous client/ap mode by default (e.g.
https://albeec13.github.io/2017/09/26/raspberry-pi-zero-w-simultaneous-ap-and-managed-mode-wifi/), but then bring up an interface in monitor mode in order to do packet injection/pentesting, etc... Your sweet project is the closest I've found!

Not exactly an issue, but I thought you might be interested and have a better idea of the feasibility. This would enable a truly amazing little platform which can test networks using mon0 interface, then ostensibly connect to them afterwards on wlan0, forwarding packets through a bridged connection to ap0, which can then host a number of connected devices through a tunnel, behind e.g. a spoofed MAC.

I've managed to set up a simultaneous client/ap, and then after installing nexmon firmware and driver, bring up monitor mode, but it killed the ap, and after restart I was unable to SSH into either the wlan or ap interfaces while using the new driver, and had to rollback the driver via an init.d script.

You thoughts would be appreciated! Thanks for this cool project.

[mame82]

Hi, I thought about the same. To be more precise I thought about an eviltwin setup with a single physical wlan interface (STA + AP simultaneously).

In order to get MON + AP/STA running, I patched the brcmfmac driver to add an second virtual interface (changes are pulled into the original nexmon repo, meanwhile).

It is hard to explain the problem in short: Basically, the modified driver calls back to the firmware, in order to make it "aware" of the secin virtual interface. Under normal circumstances, this firmware callback is only used in AP mode (creates an additional bsscfg in firmware).

Up till now, I wasn't able to add a third virtual interface to run AP+STA+MON.

For some (not yet investigated) reason, AP+STA isn't working, either.

I still believe AP+STA+MON is possible, but a bunch of R&D and adfitional firmware reversing is needed. Right now, I haven't got the time to do this.

Please note, that the driver already is patched in a way to report AP+STA+MON as a valid configuration (iw list). Anyway, in practice such a setup isn't working yet

[mame82]

Btw. I requested community support for exactly this in the last lines of the readme, due to the lack of time

[whackyhack]

I entered this realm with the exact thought following Mubix. (I believe that we had some exchange somewhere when P4wnP1 began.) Then I did some interesting PoC attacks on a now defunct low-cost platform that had AP+STA firmware. It was shockingly low-cost, low-profile, and high impact. I may be able to ticker more when my pi0w comes.

BTW, I read your LockPiker writeup for the first time. (Though I had sunken quite some time into the project, I hadn't been well versed in Githubland. This, and the fact that I was laggard in conversing with others.) I was amazed how Microsoft could think that Mubix requires physical contact. With my limited skills, a full-time job outside the domain, and a friction-filled platform, I was able to complete Mubix contactlessly in June 2017. That would be two months before you had that discussion with Microsoft and four months before KB4041691. (I also don't see why you have to feel bad about releasing the payload nearly a year after; Mubix's blog is easy enough to follow by anyone, and there are plenty of additional instructions, including on Pi Zero. In fact, I was drawn to Mubix thanks to a guy named Chandra Majumdar who posted his Pi Zero implementation on the same day. I even promised him that I'd post my port to the cheaper platform, but I never finished my writeup and lost contact due to G+ shutdown.)

It is unfortunate that MS does not comment on how KB4041691 addresses the issue, because Mubix's original blog indicated success with OSX El Capitan/Mavericks. When I first succeeded the USB attack using my cheaper-than-pi0 matchbox in late-March/early April of 2017, I specifically included OSX and Ubuntu (because Mubix' initial test did not include Linux). My experience is that as long as automatic WPAD is allowed, I don't even need NTLM, hence not limited to Windows. (That NTML can be forced to downgrade is a bonus.) Is this still correct? (My interest was soon drawn to non-Mubix subjects and didn't follow KB4041691.) Or maybe people consider WPAD credential less valuable. (In the real world, though, there is no telling how many "passwords" are used repeatedly.)