broadcom-wps combines YARA firmware rules and a monitor-mode fingerprinting script so authorized auditors can identify routers running Broadcom's vulnerable 802.11 wps_monitor implementation.
| Tool | qkaiser/broadcom-wps — toolkit for fingerprinting WiFi access points running the Broadcom 802.11 SDK and tracking known-affected devices |
| Category | Wireless fingerprinting and firmware triage (YARA, Python, scapy) |
| Primary Use | Determining whether a router runs Broadcom's wps_monitor — statically via YARA rules on extracted firmware, or dynamically via a monitor-mode scapy fingerprinter against WPS-advertising APs |
| Safe Use | Inventory and vulnerability assessment on networks and devices you own or are explicitly authorized to test; also used for defensive asset triage and ISP fleet audits |
| Telemetry Note | The dynamic probe sends a zero-length fragmented EAP frame and distinguishes implementations purely by the ACK/NACK response — passive sweeps plus a single malformed frame; every run writes a full PCAP and result.json under /tmp, leaving a local evidence trail for defenders |
The Broadcom 802.11 SDK detection toolkit published as qkaiser/broadcom-wps addresses a scoping problem that has quietly haunted consumer and ISP-grade routers for years: identifying which devices actually run Broadcom's proprietary wps_monitor userspace daemon instead of the hardened hostapd most Linux distributions ship. The repository offers two complementary detection paths — a static one built on YARA rules that run against extracted firmware images, and a dynamic one where a Python script using scapy interrogates a live access point over the air. The framing is deliberately triage-oriented: the README repeatedly warns that the shipped device list is not exhaustive, and the authors expect the real number of affected makes and models to reach into the thousands.
The static path lives in broadcom_wps_monitor.yar, which contains three candidate detectors targeting ELF32 ARM and MIPS binaries. The first, BRCM_WPS_Monitor_Generic_ELF, identifies a generic Broadcom WPS Monitor binary from independent vendor and protocol strings. The second, BRCM_WPS_Monitor_HAL_Config_ELF, narrows the match to the HAL configuration event variant. The third and most interesting, VULN_BRCM_WPS_EAP_Fragment_Reassembly_ELF, requires the generic component evidence plus an ARM or MIPS opcode shape associated with the vulnerable fragment-reassembly path — the code region where EAP fragment length validation feeds a copy sink. That layering of string evidence and opcode shape is a sensible way to reduce false positives across heterogeneous vendor builds.
The README is unusually candid about the limits of signature-based firmware triage. Compiler changes can evade opcode patterns, and a patched binary can still retain the strings or code bytes a candidate detector keys on. The authors explicitly position these rules as triage aids and recommend confirming findings against integrated source or by manual review of the fragment-length validation logic and copy sink. That honesty matters for anyone planning to build detection into a larger firmware-audit pipeline: a hit from the vulnerability-specific rule is a lead, not a verdict.
The dynamic path is broadcom_fingerprint.py, a scapy-based script run through uv that requires a wireless interface in monitor mode. The methodology is well documented in the README and relies on two independent signals. The first is the presence of Broadcom proprietary information elements in beacon traffic — a useful but insufficient indicator, because the Broadcom Linux kernel module sometimes injects those IEs even when the userspace implementation is not from the SDK. The second signal is an implementation quirk: the script sends a zero-length fragmented frame and differentiates by the response, where hostapd sends an ACK while Broadcom's wps_monitor sends a NACK. Only when both signals align does the tool report a high-confidence LIKELY_VULNERABLE assessment, which is a more disciplined inference chain than most wireless fingerprinters offer.
The output vocabulary is worth internalizing because it encodes confidence levels rather than binary verdicts. A vulnerable device yields LIKELY_VULNERABLE along with vendor, model, BSSID, channel, and a timestamped output directory containing result.json and a full traffic.pcap. A Broadcom-based device running patched hostapd yields PATCHED_HOSTAPD. An AP that does not advertise WPS at all returns INCONCLUSIVE with a warning, which correctly declines to overclaim on out-of-scope targets. Every run produces packet captures, which makes the tool well suited to evidentiary workflows where an auditor needs to justify an assessment after the fact.
Hardware compatibility gets an unusually detailed treatment, and it is the kind of operational detail that saves hours of frustration. The author reports that an Intel Dual Band Wireless-AC 7265 on iwlwifi accepted type monitor but captured zero frames — not even beacons — so the fingerprinter never locked onto a target. A USB adapter with the MediaTek MT7921AU chipset, USB id 0e8d:7961 on the mt7921u driver, worked immediately. The README lists known-good chipsets for this class of work: MediaTek mt76, Atheros ath9k_htc, and Realtek rtl8812au. The practical takeaway is that if the script keeps sweeping channels without finding your SSID, you should suspect the adapter before the target.
The device inventory in the README is the most sobering part of the project. Confirmed affected hardware spans Cisco small-business lines like the RV110W, RV130W, RV340W, and the entire WAP1xx/WAP5xx series, ARRIS SURFboard gateways, Arcadyan VRV9517 units deployed by KPN as the Experia Box V10A, Askey TCG3000 and RTF3505VW CPE used by Orange Belgium, VOO, and Movistar, extensive NetComm ranges common across Australian ISPs, Netgear CG3100 and CG3700B, Nokia G-240W family ONTs scattered across dozens of carriers worldwide, ZTE F680 and 368N, Zyxel VMG3312 variants, and multiple TP-Link Archer models. The ISP column makes clear this is largely carrier-supplied CPE, meaning the exposure is fleet-scale and mostly invisible to the end users who own these boxes.
Just as useful for defenders is the counter-evidence table: Sagemcom F5598T and F380B were tested dynamically, returned PATCHED_HOSTAPD, and are explicitly documented as not vulnerable. Publishing negative results so others don't re-test the same models is a small but valuable piece of community hygiene that more detection projects should adopt. The repository also has a contribution protocol — pull requests should include vendor, product, version, optionally the deploying ISP, and either a firmware link for static findings or the generated PCAP for dynamic ones — which keeps the inventory evidence-backed rather than anecdotal.
Within an authorized workflow, this toolkit slots cleanly into two phases. During pre-engagement scoping or asset inventory, the YARA rules let you triage firmware dumps you already hold for router fleets you manage, and a single invocation like yara -w -r broadcom_wps_monitor.yar extracted_firmware_dir recursively scans an unpacked image tree. During an authorized wireless assessment of your own infrastructure, the fingerprinter gives you a documented, minimal-footprint way to prioritize which APs need firmware attention, complete with captures for the report.
From a defensive perspective, the tool is equally informative for what it reveals about detectability. The dynamic probe is nearly indistinguishable from an ordinary station sweep until its single zero-length fragmented frame goes out, and the behavioral difference it exploits — ACK versus NACK on malformed EAP fragments — is itself a signature a savvy SOC could monitor on enterprise wireless controllers. The fact that patched hostapd and vulnerable wps_monitor diverge on this edge case gives defenders a cheap continuous-validation primitive: if your fleet is supposed to be patched, an internal sweep should return PATCHED_HOSTAPD everywhere, and anything else becomes a ticket.
The project is written in Python, MIT-licensed, carries 115 stars, and is tagged across broadcom, ecos, embedded, linux, routers, wifi, wireless, and wps — a topical footprint that matches its dual static/dynamic nature. What it deliberately is not, and the README's structure reinforces this, is an exploitation tool. It is a detection and inventory instrument: no payload delivery, no credential recovery, no post-fingerprint actions. Its value is in turning a vague supply-chain question — which of thousands of router models run a specific proprietary daemon — into an answerable, evidence-producing checklist, and in aggregating that answer across a community-maintained dataset that already spans vendors on five continents.
For anyone responsible for embedded device security, ISP CPE auditing, or firmware supply-chain research, broadcom-wps is a model of how to publish vulnerability-scoping tooling responsibly: transparent methodology, calibrated confidence labels, honest limitations, reproducible evidence artifacts, and a curated negative-results table. Clone it, run the YARA rules over your firmware archive, and check your fleet's APs against the inventory before assuming you're in the clear — because as the README shouts in capital letters, the list is not exhaustive, and you may be affected even if your device is not on it.
qkaiser/broadcom-wps.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.