From 9ca57baa2fbf608f2ed1d57e6ae33581840d5830 Mon Sep 17 00:00:00 2001 From: Joseph Goydish II Date: Sat, 27 Dec 2025 11:41:59 -0500 Subject: [PATCH] Update README.md --- README.md | 699 +++++++++++++++++++++++++----------------------------- 1 file changed, 318 insertions(+), 381 deletions(-) diff --git a/README.md b/README.md index 1084769..3fdcb58 100644 --- a/README.md +++ b/README.md @@ -1,354 +1,304 @@ -# Industry-Wide Wireless Chipset Architecture: Insecure by Design +# Wireless Chipset Architecture Analysis +## Security Implications of Autonomous Peripheral Subsystems --- -## TL;DR / Executive Summary +## Executive Summary -### The Discovery -Forensic analysis of the Broadcom BCM4387c2 firmware reveals six universal architectural features that enable privileged execution, direct memory access, and independent operation outside Host OS (iOS/Android) control. +### The Research -### The Problem -This is not a vendor-specific bug, but a systemic architectural reality: modern WiFi standards (802.11, PCIe) require chipsets to function as independent "computers within computers." +This repository documents a security architecture analysis of modern wireless chipsets, focusing on the Broadcom BCM4387c2/BCM4388 family. The research examines the architectural characteristics that enable autonomous operation, hardware-level memory access, and persistent configuration storage in devices operating outside direct Host OS control. -### The Impact +### Key Findings -- **Scale:** 15+ billion devices globally (Broadcom, Qualcomm, Intel, MediaTek, Realtek) -- **Persistence:** Operations survive factory resets and host power cycles -- **Access:** Direct Memory Access (DMA) allows the chip to read/write host RAM, bypassing OS security -- **Surveillance:** Built-in proximity detection (WiFi RTT/FTM) and hidden protocol extensions (IE 221) -- **Loss of Control:** All modern smartphones, laptops, and IoT devices contain wireless subsystems that operate outside user or OS visibility, with privileged, persistent, and invisible access to all data. This makes the wireless chipset a universal point of potential **exploitation, surveillance, or abuse—by design** and by international specification. +Modern wireless chipsets implement architectural features that create **visibility and auditability gaps** for Host operating systems: -### The Evidence -ThreadX RTOS, 52 DMA channels, and 7 power states confirmed—chip remains active during host sleep. Findings are 100% reproducible using provided scripts and the source `SoC_RAM.bin`. +- **Autonomous Execution:** Chipsets run dedicated Real-Time Operating Systems (RTOS) that process network traffic during Host CPU sleep states +- **Direct Memory Access:** DMA channels enable hardware-level memory operations constrained by IOMMU policies but occurring outside real-time Host OS monitoring +- **Hardware Persistence:** Firmware and calibration data in non-volatile memory survive Host OS factory reset procedures +- **Power Independence:** Multiple power states allow chipset operation during various Host sleep modes +- **Limited Host Visibility:** Chipset operations occur below the Host OS security stack with limited audit logging -### The Goal -To move beyond "patching" and mandate industry-wide transparency, regulatory oversight of chipset-level data, and hardware-level user controls. +### Important Context ---- -## Overview +**These features are required by wireless industry standards** (IEEE 802.11, Bluetooth, PCIe) for functionality and performance. This research does not allege: +- Active exploitation or surveillance +- Vendor-specific vulnerabilities unique to Broadcom +- Intentional backdoors or malicious design +- That these features should or can be removed -Forensic analysis of Broadcom BCM4387c2 firmware reveals architectural patterns that are standard across all major wireless chipset vendors. These design features, required by industry specifications and performance demands, create systemic surveillance capabilities that cannot be disabled by users or patched conventionally. +**This research documents:** The security implications of necessary architectural trade-offs between wireless functionality and Host OS visibility. -**Finding:** The vulnerability is not a bug—it is the architecture itself. +### Scope and Impact + +- **Analyzed:** Broadcom BCM4387c2 and BCM4388 firmware architecture +- **Applicable:** Similar architectural patterns exist across major vendors (Qualcomm, Intel, MediaTek, Realtek) +- **Devices:** Smartphones, laptops, tablets, IoT devices with modern wireless chipsets +- **Implications:** Security practitioners should understand these architectural limitations when threat modeling and designing security controls --- -## The Risk +## Repository Structure -Modern WiFi chipsets from all major vendors (Broadcom, Qualcomm, Intel, MediaTek, Realtek) share architectural features that enable: +### Main Analysis +- **`README.md`** (this file) - Project overview and architectural analysis +- **`BCM4387c2_Analysis.md`** - Detailed technical analysis of BCM4387c2 firmware +- **`SoC_RAM.bin`** - Firmware RAM dump (MD5: 28d0f2a6eb5ea75eb290b6ef96144e5b) -- Privileged execution outside host OS control -- Direct memory access bypassing OS security -- Independent operation during device sleep -- Hidden data transmission via protocol extensions -- Proximity detection via WiFi ranging -- Persistent storage surviving factory reset +### Project Olympic (BCM4388 Case Study) +- **`Project_Olympic/README.md`** - Detailed analysis of BCM4388 specific behaviors +- **`Project_Olympic/SoC_RAM.bin`** - BCM4388 firmware dump +- **`Project_Olympic/bluetoothd-hci-2025_01_02-12_47_38.pklg`** - HCI packet capture +- **`Project_Olympic/bcm4388_auditability_assessment.md`** - Host OS visibility gap analysis --- -## Why This Is Different +## Technical Background -### This is NOT: -- A software bug that can be patched -- A vendor-specific issue -- An optional feature that can be disabled -- A configuration error +### Why Wireless Chipsets Operate Autonomously -### This IS: -- **Required by wireless standards** (802.11, PCIe, Bluetooth) -- **Present across all vendors** (architectural necessity) -- **Embedded in silicon** (hardware-level implementation) -- **Invisible to end users** (operates below OS level) -- **Necessary for functionality** (removing these features breaks WiFi) +Modern wireless standards impose real-time requirements that necessitate independent chipset operation: + +**IEEE 802.11 Requirements:** +- Beacon reception during Host sleep (Power Save Mode) +- Rapid channel switching (<10ms for fast roaming) +- Real-time QoS packet prioritization +- Autonomous background scanning + +**PCIe/Performance Requirements:** +- Multi-gigabit throughput (WiFi 6/6E: up to 9.6 Gbps) +- DMA for efficient packet transfers +- Low-latency interrupt handling +- Independent buffer management + +**Battery Life Requirements:** +- Host CPU sleep during network idle periods +- Chipset-managed wake-on-wireless +- Power state coordination across subsystems + +### Architectural Components Common to Modern Chipsets + +| Component | Purpose | Security Implication | +|-----------|---------|---------------------| +| **Dedicated RTOS** | Real-time packet processing | Executes code outside Host OS control | +| **DMA Channels** | High-speed memory transfers | Hardware-level memory access (IOMMU-constrained) | +| **Power Management** | Battery life optimization | Operations during Host CPU sleep | +| **NVRAM Storage** | Calibration/configuration | Persists across Host OS reset | +| **Protocol Stack** | 802.11/Bluetooth implementation | Complex code base with potential bugs | --- -## Evidence Summary +## Research Findings: BCM4387c2/BCM4388 -### Primary Analysis: Broadcom BCM4387c2 +### Verified Architectural Features -**Source File:** SoC_RAM.bin -**MD5:** 28d0f2a6eb5ea75eb290b6ef96144e5b -**Size:** 2,068,480 bytes +**Source Files Analyzed:** +- BCM4387c2: `SoC_RAM.bin` (2,068,480 bytes) +- HCI Logs: `Project_Olympic/bluetoothd-hci-2025_01_02-12_47_38.pklg` (1,729,081 bytes) -### Verified Features +**Confirmed Features:** -| Feature | Evidence | Cross-Vendor Risk | -|---------|----------|-------------------| -| **Separate RTOS** | ThreadX v%d.%d initialized | Universal (all vendors) | -| **DMA Operations** | 52 references (H2D/D2H) | Universal (required by PCIe) | -| **Power Independence** | 7 distinct power states | Universal (802.11 spec) | -| **802.11 Protocol** | Full stack implementation | Universal (all WiFi chips) | -| **Bluetooth Integration** | 24 coexistence references | High (combo chips) | -| **Proximity Detection** | proxd (WiFi FTM/RTT) | Universal (802.11mc) | -| **Project Olympic** | Confirmed Exploitation Window: 36.7% correlation between AP Sleep & Critical State | Vendor-specific (BCM4387c2/4388) | -| **1,374 Functions** | ARM Thumb disassembly | Vendor-specific | +| Feature | Evidence | Description | +|---------|----------|-------------| +| **ThreadX RTOS** | String: "ThreadX v%d.%d initialized" | Real-time operating system for wireless operations | +| **DMA Operations** | 52 string references (BCM4387c2), 10 channels (BCM4388) | Direct memory access for packet processing | +| **Power States** | 7 distinct DS_STATE_ strings | Independent power management | +| **CLM Module** | "Oly.Nash 1.70.2", "ClmImport 1.69.0" | Regulatory domain enforcement in NVRAM | +| **Bluetooth Coexistence** | 24 coexistence references | WiFi/Bluetooth coordination | +| **Proximity Detection** | "proxd" references | WiFi Fine Timing Measurement (802.11mc) | ---- -## The Smoking Gun: Project Olympic +### BCM4388 Specific Observations (Project Olympic) -While architectural features are universal, the `Project_Olympic/` folder provides **undeniable proof of active, unmonitored exploitation and state-machine failure** in the BCM4387c2/4388 family. +Analysis of the BCM4388 during operational states revealed: -**Key Evidence Surfaces:** -- **The Temporal Window:** Forensic analysis of `bluetoothd-hci-2025_01_02.pklg` demonstrates that **36.7% of critical hardware warnings occur during host sleep transitions**. -- **State Machine Collapse:** Discovery of `scan core sleep state:10` shows the "Shadow OS" (`Poppy_CLPC_OS`) enters undefined logic branches when the primary iOS/Android kernel is suspended. -- **Privileged Memory Access:** 10 independent DMA channels (`wl0:dma0-9`), mapped from offset `0x1a99c0`, provide direct physical memory access, bypassing the host OS. +**Autonomous Packet Processing:** +- 599 AP Sleep/Wake cycles observed in HCI log +- Up to 90 packets (67 HCI Commands + 23 ACL Data) processed during single extended sleep period +- Chipset maintains Bluetooth connectivity independently during Host CPU sleep +**State Machine Behavior:** +- 1 documented state machine error: "unexpected scan core sleep state:10, cmd:7" +- Error occurred during autonomous operation period (0.17% error rate across 599 cycles) +- Indicates edge case in power state transition logic ---- +**Power Transition Correlation:** +- 79 total "2.4 GHz critical state" warnings observed +- 29 warnings (36.7%) occurred within 500 bytes of AP Sleep events +- Median correlation distance: 89 bytes (suggesting fixed event structure timing) +- Correlation is 3-4x higher than random distribution would predict -## Cross-Vendor Architecture Comparison +**Interpretation:** Power state transitions create timing windows where chipset state machines experience increased instability, consistent with complex asynchronous event handling in firmware. -| Vendor | Chipset Series | RTOS | DMA | Power States | 802.11 Stack | Risk Level | -|--------|---------------|------|-----|--------------|--------------|------------| -| **Broadcom** | BCM43xx (4387, 4388, 4389) | ThreadX | YES | YES | Full | HIGH | -| **Qualcomm** | WCN series (3990, 6855, 7850) | FreeRTOS/Prop | YES | YES | Full | HIGH | -| **Intel** | AX series (200, 210, 411) | Proprietary | YES | YES | Full | HIGH | -| **MediaTek** | MT76xx/79xx | FreeRTOS/Prop | YES | YES | Full | MODERATE | -| **Realtek** | RTL8xxx | Proprietary | YES | YES | Full | MODERATE | - -**Universal features:** 6 of 8 architectural components present in all vendors -**Vendor differences:** Implementation details (secure boot, storage), not capability - ---- - -## Technical Capability Matrix - -### What All Chipsets Can Do - -| Capability | Technical Basis | Industry Standard | -|------------|----------------|-------------------| -| **Separate OS execution** | RTOS required for real-time packet processing | 802.11 QoS requirements | -| **Host memory access** | DMA required for multi-Gbps throughput | PCIe/SDIO specifications | -| **Independent operation** | Power management for battery life | 802.11 Power Save Mode | -| **Vendor-specific data** | Protocol extensions for features | 802.11 IE 221 (vendor-specific) | -| **Background scanning** | Network discovery and roaming | 802.11 standard behavior | -| **Proximity detection** | Distance ranging for positioning | 802.11mc FTM/RTT | - -### What Users Cannot Control - -- Chipset-level operations (no Settings toggle) -- Separate RTOS execution (invisible to host OS) -- DMA memory access (bypasses OS permissions) -- Persistent chipset storage (survives factory reset) -- Proximity detection hardware (always-on capability) -- Vendor-specific 802.11 extensions (undisclosed) - ---- - -## Architectural Risk Factors - -### 1. Privileged Execution -- Chipset runs separate RTOS with DMA access -- No OS-level process isolation -- Invisible to security software and antivirus -- Cannot be monitored or audited by user - -### 2. Memory Access -- 52 DMA operation references in BCM4387c2 -- Direct read/write to host memory -- Bypasses OS memory protection -- Access to decrypted data, passwords, keys - -### 3. Power Independence -- 7 independent power states -- Chipset active during host CPU sleep -- Operations continue when screen is off -- No user visibility or control - -### 4. Protocol Extensions -- 802.11 Information Element 221 (vendor-specific) -- No disclosure requirement for contents -- Can embed arbitrary data in WiFi frames -- Appears as normal traffic to monitoring tools - -### 5. Persistent Storage -- NVRAM within chipset -- Survives power cycles and factory reset -- Not accessible to host OS -- Can store tracking identifiers - -### 6. Proximity Detection -- WiFi Fine Timing Measurement (FTM) -- Round Trip Time (RTT) distance ranging -- Accuracy: approximately 1 meter -- Standard 802.11mc feature - ---- - -## Verification Methodology - -### Quick Verification Commands +### Quick Verification ```bash +# Verify file integrity +md5sum SoC_RAM.bin +# Expected: 28d0f2a6eb5ea75eb290b6ef96144e5b + # Extract chipset ID strings SoC_RAM.bin | grep "chip=" # Output: chip=4387c2 -# Find RTOS +# Find RTOS evidence strings SoC_RAM.bin | grep -i threadx # Output: ThreadX v%d.%d initialized -# Count DMA operations +# Count DMA references strings SoC_RAM.bin | grep -i dma | wc -l # Output: 52 # List power states strings SoC_RAM.bin | grep DS_STATE - -# Find proximity detection -strings SoC_RAM.bin | grep proxd - -# Verify file integrity -md5sum SoC_RAM.bin -# Expected: 28d0f2a6eb5ea75eb290b6ef96144e5b +# Output: DS_STATE_ACTIVE, DS_STATE_HOST_SLEEP, etc. ``` -### How to Analyze Other Chipsets +--- -1. **Identify your chipset:** - - Linux: `lspci | grep -i wireless` - - macOS: `system_profiler SPAirPortDataType` - - Windows: `Get-NetAdapter` (PowerShell) +## Security Implications -2. **Extract firmware:** - - Linux: `/lib/firmware/*.bin` - - Windows: `C:\Windows\System32\drivers\*.sys` - - macOS: `/System/Library/Extensions/*.kext/Contents/Resources/` +### The Auditability Challenge -3. **Analyze binary:** - ```bash - strings firmware.bin | grep -i "threadx\|freertos\|rtos" - strings firmware.bin | grep -i dma - strings firmware.bin | grep -i "sleep\|wake\|power" - ``` +Modern wireless chipsets create a **security-transparency gap** where: -4. **Compare findings** against evidence tables in `BCM4387c2_Analysis.md` +1. **Limited Real-Time Visibility:** Host OS cannot monitor chipset operations during CPU sleep states +2. **Trust Boundary Shift:** Security relies on hardware enforcement (IOMMU) rather than software controls (OS kernel) +3. **Persistent Configuration:** NVRAM-stored settings survive standard device sanitization +4. **Autonomous Decision-Making:** Chipset firmware makes network and memory access decisions independently + +### What This Means for Security Practitioners + +**Threat Modeling Considerations:** + +| Threat Scenario | Traditional OS Malware | Compromised Chipset Firmware | +|----------------|----------------------|----------------------------| +| **Detection** | Antivirus, EDR, kernel monitoring | Limited to post-hoc log analysis | +| **Containment** | Process isolation, sandboxing | IOMMU policy (if properly configured) | +| **Remediation** | Software update, quarantine | Chipset firmware reflash (vendor-specific tools) | +| **Persistence** | Cleared by OS reinstall | Survives factory reset | +| **Memory Access** | Subject to MMU/page tables | Hardware DMA (IOMMU-constrained) | + +**Key Risks if Chipset Firmware is Compromised:** + +1. **Limited Host Detection:** Malicious firmware operates below OS security monitoring +2. **DMA Capabilities:** Direct memory access (constrained by IOMMU configuration) +3. **Operational Persistence:** Chipset continues operating during Host sleep +4. **Configuration Persistence:** Malicious settings could survive device sanitization +5. **Timing Exploitation:** Power transition windows show increased instability (36.7% correlation) + +### Important Clarifications + +**What This Research Does NOT Show:** +- Active exploitation in the wild +- Evidence of intentional surveillance capabilities +- Vendor-specific vulnerabilities that don't exist in competitors' products +- Practical attacks against these architectural features + +**What This Research DOES Show:** +- Architectural characteristics that limit Host OS visibility +- Timing correlations suggesting power transitions create instability windows +- Trust boundaries that depend on hardware (IOMMU) rather than software enforcement +- Areas where compromised firmware would be difficult to detect --- -## Why Conventional Solutions Don't Work +## Cross-Vendor Comparison -| Proposed Solution | Why It Fails | -|------------------|--------------| -| **"Just patch it"** | Removing these features breaks WiFi functionality | -| **"Switch vendors"** | All vendors have identical architectural requirements | -| **"Disable in firmware"** | OEMs don't control chipset firmware source code | -| **"Factory reset"** | Chipset storage persists independently of host OS | -| **"Turn off WiFi"** | Requires airplane mode for true radio silence | -| **"Use VPN"** | Chipset operates below network encryption layer | -| **"Install firewall"** | Chipset has direct memory access, bypasses OS | +### Architectural Similarities Across Vendors + +While implementation details vary, all major wireless chipset vendors share similar architectural requirements: + +| Vendor | Example Chipsets | RTOS | DMA | Independent Power Management | 802.11 Stack | +|--------|-----------------|------|-----|---------------------------|--------------| +| **Broadcom** | BCM43xx (4387, 4388, 4389) | ThreadX | Yes | Yes | Full | +| **Qualcomm** | WCN series (3990, 6855, 7850) | FreeRTOS/Proprietary | Yes | Yes | Full | +| **Intel** | AX series (200, 210, 411) | Proprietary | Yes | Yes | Full | +| **MediaTek** | MT76xx/79xx | FreeRTOS/Proprietary | Yes | Yes | Full | +| **Realtek** | RTL8xxx | Proprietary | Yes | Yes | Full | + +**Common Features:** Separate execution environment, DMA capabilities, power independence, NVRAM storage + +**Vendor Differences:** Secure boot implementation, update mechanisms, specific RTOS choice, debugging interfaces + +### Why This Architecture is Universal + +These features are not vendor choices but requirements imposed by: + +1. **IEEE 802.11 Standard:** Power Save Mode, QoS, fast roaming +2. **PCIe Specification:** DMA for high-throughput data transfers +3. **Bluetooth Core Spec:** Connection maintenance during low-power states +4. **Battery Life Requirements:** CPU sleep with maintained connectivity +5. **Performance Requirements:** Multi-gigabit wireless speeds --- -## What Needs to Change +## Recommendations -### Industry (Immediate Actions Required) +### For Security Researchers -1. **Chipset vendors** must disclose firmware capabilities and data collection -2. **OEMs** must require source code access for security auditing -3. **Standards bodies** (IEEE, Wi-Fi Alliance) must restrict vendor-specific extensions -4. **Security researchers** must analyze and publish findings on other chipsets +1. **Verify Findings:** Use provided verification commands and methodology +2. **Analyze Other Vendors:** Apply techniques to Qualcomm, Intel, MediaTek chipsets +3. **Monitor Network Traffic:** Examine vendor-specific 802.11 Information Elements +4. **Document Variations:** Compare implementation details across vendors +5. **Share Responsibly:** Follow coordinated disclosure practices -### Regulatory (Policy Changes Required) +### For Security Practitioners -1. **Mandate firmware source disclosure** for device certification -2. **Require user controls** for chipset-level features and data collection -3. **Enforce data retention limits** at the silicon level -4. **Standardize opt-out mechanisms** for proximity detection and telemetry -5. **Establish penalties** for undisclosed surveillance capabilities +1. **Understand Trust Boundaries:** Recognize chipset operates outside Host OS security controls +2. **Verify IOMMU Configuration:** Ensure DMA protections are properly configured +3. **Monitor HCI Logs:** Implement continuous monitoring where available +4. **Include in Threat Models:** Account for limited visibility into chipset operations +5. **Consider Persistence:** Plan for firmware that survives factory reset -### Architecture (Long-term Redesign) +### For Industry and Standards Bodies -1. **Open-source wireless firmware** as requirement for certification -2. **Hardware killswitches** for wireless radios (physical RF disconnect) -3. **OS-level enforcement** of chipset memory access permissions -4. **Transparent telemetry** with explicit user consent mechanisms -5. **Isolation boundaries** between chipset and host memory +1. **Firmware Transparency:** Require disclosure of chipset capabilities and data handling +2. **Attestation Mechanisms:** Standardize firmware integrity verification +3. **Audit Logging:** Enhance real-time visibility into chipset operations +4. **User Controls:** Provide mechanisms to audit or limit chipset-level features +5. **Open Source Firmware:** Consider open-source alternatives for security-critical deployments + +### For Users + +**Understanding Your Device:** +- Wireless chipsets operate independently of user settings +- "WiFi Off" in settings may not disable all chipset functions +- Factory reset does not erase chipset firmware or NVRAM +- Airplane mode provides most complete wireless radio disconnect + +**Risk Mitigation:** +- Use airplane mode for maximum wireless radio disconnect +- Keep device firmware updated (includes chipset firmware updates) +- Understand that chipset operates with hardware-level privileges +- Consider threat model when evaluating wireless risks --- -## Affected Devices (Examples) +## Methodology -### Smartphones -- Apple iPhone 12, 13, 14, 15 series (Broadcom BCM43xx) -- Samsung Galaxy S21, S22, S23 series (Qualcomm WCN) -- Google Pixel 6, 7, 8 series (Qualcomm WCN) -- Most Android flagships (Qualcomm WCN, Broadcom BCM43xx) +### Analysis Techniques -### Laptops -- Dell XPS series (Intel AX, Qualcomm) -- HP Spectre, EliteBook (Intel AX, Qualcomm) -- Lenovo ThinkPad, Yoga (Intel AX, Qualcomm) -- MacBook Air, Pro 2021+ (Broadcom BCM43xx) +1. **Binary String Extraction:** Identify RTOS, protocols, error messages +2. **ARM Disassembly:** Reconstruct function structures using Capstone +3. **Pattern Matching:** Cross-reference with wireless standards and vendor documentation +4. **HCI Log Analysis:** Correlate packet activity with power states +5. **Statistical Analysis:** Identify timing patterns and correlations -### IoT and Other Devices -- Smart home devices (MediaTek MT76xx, Realtek RTL8xxx) -- WiFi routers and access points (Broadcom, MediaTek, Realtek) -- Smart TVs (MediaTek, Realtek) -- Wearables (various vendors) +### Tools Used -**Note:** Device configurations vary. Consult teardown reports or manufacturer specifications for chipset confirmation. - ---- - -### Files - -1. **README.md** (this file) - - Architectural analysis - - Cross-vendor risk assessment - - Integrated exploitation evidence (Project Olympic) - -2. **Project_Olympic/** - - **Undeniable Proof of Exploitation:** Correlation between host power states and autonomous chipset errors. - - **DMA Channel Maps:** Physical memory offsets for all 10 verified DMA paths. - - **Shadow OS Logs:** Extraction of `Poppy_CLPC_OS` and persistent modules (`Oly.Nash`). - - Full forensic log files, PoC traces, and state analysis reports. - -3. **BCM4387c2_Analysis.md** - - Technical evidence report (reference) - - Detailed findings and verification commands - -4. **SoC_RAM.bin** - - Firmware dump for architectural analysis - - -### Analysis Tools Required - -- **strings** (GNU binutils) -- **grep** (GNU core utilities) -- **md5sum / sha256sum** (verification) -- **Python 3.8+** (for advanced analysis) -- **Capstone 5.0.1** (ARM disassembly): `pip install capstone` - ---- - -## Technical Details - -### Evidence Extraction Process - -1. Binary analysis via string extraction -2. ARM Thumb disassembly (1,374 functions reconstructed) -3. Pattern matching for RTOS, DMA, power management -4. Cross-reference with wireless standards (802.11, PCIe) -5. Vendor comparison (Qualcomm, Intel, MediaTek, Realtek) - -### Confidence Levels - -- **Chipset identification:** 100% (chip=4387c2 in binary) -- **RTOS presence:** 100% (ThreadX strings verified) -- **DMA operations:** 100% (52 references counted) -- **Power management:** 100% (7 states enumerated) -- **Cross-vendor applicability:** HIGH (architectural analysis) -- **Industry impact estimate:** MODERATE (based on market data) +- **strings** (GNU binutils) - Binary string extraction +- **grep** (GNU core utilities) - Pattern matching +- **Capstone 5.0.1** - ARM Thumb disassembly +- **Python 3.8+** - Statistical analysis and correlation +- **Wireshark** - HCI packet log analysis (for Project Olympic) ### Reproducibility All findings include: -- Exact byte offsets or string matches +- Exact string matches or byte offsets - Verification commands with expected outputs -- File hashes for integrity checking -- Methodology for applying to other chipsets +- File integrity hashes (MD5/SHA256) +- Methodology applicable to other chipset analysis --- @@ -356,153 +306,140 @@ All findings include: ### What This Analysis Covers -- Architectural capabilities present in wireless chipsets -- Evidence from Broadcom BCM4387c2 binary analysis -- Cross-vendor comparison of design patterns -- Industry-standard requirements driving architecture +- Architectural characteristics of Broadcom BCM4387c2/BCM4388 chipsets +- Evidence-based analysis of firmware binary and operational logs +- Security implications of autonomous chipset operation +- Comparison of architectural patterns across vendors ### What This Analysis Does NOT Cover -- Active exploitation or proof-of-concept attacks -- Specific data collection by manufacturers or carriers -- Legal analysis of surveillance or privacy regulations +- Specific exploits or proof-of-concept attacks +- Active surveillance or data collection by manufacturers +- Legal analysis of privacy regulations - Recommendations for individual device hardening -- Analysis of 5G modems or cellular chipsets +- Analysis of cellular/5G modems (different subsystems) +- Reverse engineering of encrypted firmware components ### Additional Research Needed +- Dynamic runtime analysis of DMA transactions - Firmware analysis of Qualcomm WCN series - Firmware analysis of Intel AX series -- Firmware analysis of MediaTek MT series -- Network traffic analysis of vendor-specific 802.11 IEs -- Long-term monitoring of chipset power states -- Reverse engineering of encrypted firmware updates +- Network traffic analysis of vendor-specific protocol extensions +- Long-term monitoring of power state behavior +- IOMMU configuration verification across platforms --- -## Disclosure - -**Date:** December 26, 2025 -**Researcher:** Joseph Goydish II -**Scope:** Industry-wide architectural vulnerability -**Vendors Affected:** All major wireless chipset manufacturers -**Estimated Impact:** 15+ billion devices worldwide -**Disclosure Type:** Public (simultaneous release) - -### Responsible Disclosure Considerations - -This research focuses on architectural design patterns that are: -- Publicly specified in industry standards (802.11, PCIe) -- Necessary for wireless functionality -- Present across all major vendors -- Not patchable through conventional software updates - -Given the industry-wide scope and architectural nature of these findings, simultaneous public disclosure is appropriate to: -- Enable informed public discussion -- Encourage independent verification -- Promote industry-wide reform -- Support regulatory consideration - ---- - -## For Researchers - -### How to Contribute - -1. **Analyze other chipsets** using methodology in `BCM4387c2_Analysis.md` -2. **Verify findings** on different device models and vendors -3. **Document vendor-specific implementations** of architectural features -4. **Monitor network traffic** for vendor-specific 802.11 frames -5. **Share findings** through established security disclosure channels - -### Expected Variations by Vendor - -- **RTOS:** ThreadX (Broadcom) vs FreeRTOS (Qualcomm, MediaTek) vs proprietary (Intel) -- **Secure boot:** Image4 (Apple) vs TrustZone (Qualcomm, MediaTek) vs ME/TPM (Intel) -- **Storage:** Gigalocker (Apple) vs vendor-specific implementations -- **Power management:** Different state machine implementations, same capabilities - -### What to Look For - -1. RTOS signatures: `threadx`, `freertos`, `vxworks`, task/scheduler strings -2. DMA operations: `dma`, `h2d`, `d2h`, channel references -3. Power states: `sleep`, `wake`, `suspend`, state machine strings -4. Proximity: `proxd`, `ftm`, `rtt`, ranging references -5. Project names: Internal codenames, branch paths, version strings - ---- - -## Legal and Ethical Considerations +## Responsible Disclosure ### Research Ethics This research: -- Analyzes publicly available device firmware -- Does not exploit vulnerabilities for unauthorized access -- Does not target specific individuals or organizations -- Aims to inform public policy and industry reform +- Does not develop or demonstrate exploits +- Focuses on architectural analysis, not active vulnerability research +- Aims to improve understanding of wireless chipset security architecture -### User Privacy +### Disclosure Approach -Users should be aware that: -- Wireless chipsets operate independently of user settings -- Factory reset does not clear chipset persistent storage -- "WiFi off" in Settings may not disable all chipset functions -- Airplane mode provides most complete wireless radio disconnect -- Physical hardware killswitches offer highest assurance +Given the architectural nature of these findings: +- Features are required by industry standards +- Present across all major vendors +- Not exploits but design characteristics +- Cannot be "patched" without breaking functionality -### Legal Considerations - -This research is provided for: -- Security research and education -- Informed public discussion -- Policy development and regulatory consideration -- Independent verification by the research community - -Users should consult legal counsel regarding: -- Device privacy expectations in their jurisdiction -- Regulatory requirements for wireless devices -- Data protection and surveillance laws -- Consumer protection and disclosure requirements +Standard coordinated disclosure is not applicable. Instead, this research: +- Documents architectural characteristics that are industry-standard +- Provides educational material for security practitioners +- Encourages discussion of trust boundaries and auditability +- Supports informed policy development --- ## Frequently Asked Questions -**Q: Is this a Broadcom-specific problem?** -A: No. The architectural features analyzed in BCM4387c2 are present across all major vendors due to industry standards and technical requirements. +**Q: Is this a Broadcom-specific vulnerability?** +A: No. The architectural features analyzed are required by wireless standards and present across all major vendors (Qualcomm, Intel, MediaTek, Realtek). -**Q: Can I disable this on my device?** -A: No. These features are required for WiFi functionality and operate at the hardware level below user-accessible controls. - -**Q: Will a software update fix this?** -A: No. This is architectural design, not a software bug. Removing these features would break WiFi functionality. +**Q: Can these features be disabled?** +A: No. They are necessary for WiFi and Bluetooth functionality. Disabling them would break wireless connectivity. **Q: Should I stop using WiFi?** -A: This is a personal decision based on threat model and risk tolerance. Airplane mode provides the most complete wireless disconnect short of physical hardware modification. +A: This is a personal decision based on your threat model. For most users, the benefits of wireless connectivity outweigh the theoretical risks documented here. -**Q: Which vendor is safest?** -A: All major vendors share the same architectural requirements. Differences are in implementation details, not fundamental capabilities. +**Q: Which vendor is most secure?** +A: All major vendors share similar architectural requirements. Security depends more on implementation quality, update mechanisms, and IOMMU configuration than vendor choice. -**Q: How can I verify these claims?** -A: Use the verification commands in this README and detailed analysis in `BCM4387c2_Analysis.md`. All findings are reproducible. +**Q: Is my device being actively surveilled through the wireless chipset?** +A: This research does not provide evidence of active surveillance. It documents architectural capabilities that would be available if chipset firmware were compromised. -**Q: What should happen next?** -A: Industry-wide reform requiring firmware transparency, user controls, and regulatory oversight of chipset-level data collection. +**Q: What should I do to protect myself?** +A: Keep your device updated, use airplane mode when wireless is not needed, understand that chipsets operate with hardware privileges, and consider your personal threat model. + +**Q: Will a software update fix this?** +A: These are architectural characteristics, not bugs. They cannot be "fixed" without redesigning wireless chipset architecture, which would require industry-wide changes to wireless standards. + +**Q: How can I verify these findings?** +A: Use the verification commands provided in this README and the detailed analysis documents. All findings are reproducible using standard binary analysis tools. --- -## Attribution +## About This Research **Researcher:** Joseph Goydish II -**Analysis Date:** December 2025 -**Publication Date:** December 26, 2025 +**Analysis Period:** December 2025 +**Publication Date:** December 27, 2025 -This research is provided in the public interest to enable informed discussion about wireless chipset architecture, user privacy, and the need for industry-wide transparency and reform. +### Research Objectives + +1. Document architectural characteristics of modern wireless chipsets +2. Analyze security implications of autonomous peripheral subsystems +3. Identify visibility and auditability gaps for Host operating systems +4. Provide educational material for security practitioners +5. Encourage industry discussion of trust boundaries and transparency + +### Citation + +When referencing this work, please cite as: -**Citation:** When referencing this work, please cite as: ``` -Goydish II, J. (2025). Industry-Wide Wireless Chipset Architecture: Insecure by Design. -Analysis of Broadcom BCM4387c2 and Cross-Vendor Architectural Comparison. -[https://github.com/JGoyd/Insecure-By-Design] +Goydish II, J. (2025). Wireless Chipset Architecture Analysis: +Security Implications of Autonomous Peripheral Subsystems. +Analysis of Broadcom BCM4387c2 and BCM4388. ``` + +--- + +## Acknowledgments + +This research builds on public knowledge of: +- IEEE 802.11 wireless standards +- PCIe and SDIO specifications +- Bluetooth Core Specification +- ARM architecture and Thumb instruction sets +- Prior work by security researchers analyzing wireless chipsets + +--- + +## License + +This research is provided for educational and security research purposes. + +**Firmware Binary (`SoC_RAM.bin`):** +- Extracted from commercial device for security research +- Provided for verification and educational purposes only + +**Analysis and Documentation:** +- Released for public benefit and security research +- May be freely shared with attribution +- Not warranted for any particular purpose +- Use at your own risk + +--- + +## Contact + +For questions, clarifications, or to share related research: +- Open an issue in this repository + +**Note:** This is security research, not product support. For device issues, contact your device manufacturer.