LEARN BRUCE FIRMWARE DEEP DIVE

Learn Bruce Firmware: From Zero to Offensive Security Tool Builder

Goal: Deeply understand Bruce firmware—why it exists, what problems it solves, the underlying technologies (ESP32, 802.11, SubGHz, RFID, BadUSB), and how to use and extend it for authorized security research.

What is Bruce Firmware?

Bruce is a powerful open-source ESP32 firmware designed for offensive security and Red Team operations. It transforms affordable ESP32-based devices (like the M5Stack Cardputer, LilyGo T-Deck, or custom hardware) into versatile security research tools.

Think of it as an affordable, open-source alternative to the Flipper Zero (~$200), built on the ESP32 ecosystem where hardware costs $20-60.

Why Does Bruce Exist?

Bruce stems from a keen observation within the security community: while devices like Flipper Zero offered a glimpse into offensive security, something more could be achieved without being overpriced, particularly with the robust and modular hardware ecosystem provided by ESP32 devices, LilyGo, and M5Stack products.

Key motivations:

Cost: Flipper Zero costs $200+. An M5Stack Cardputer is ~$50.
Openness: Fully open-source (AGPL), hackable, and extensible.
WiFi Native: ESP32 has built-in WiFi (Flipper Zero requires an add-on module).
Community-Driven: Regular updates, app store, and active development.
Hardware Flexibility: Works on many ESP32 devices, including DIY builds.

What is Bruce Used For?

⚠️ IMPORTANT LEGAL DISCLAIMER: Bruce is intended for authorized security testing, education, and research only. Using these tools against networks, devices, or systems without explicit permission is illegal.

Legitimate Use Cases

Penetration Testing: Security professionals testing client networks
Red Team Operations: Simulating real-world attacks for defense improvement
Security Research: Understanding vulnerabilities in wireless protocols
Education: Learning how WiFi, RFID, and radio protocols work
CTF Competitions: Capture The Flag security challenges
IoT Security Auditing: Testing smart home and embedded devices
Physical Security Assessment: Testing access control systems (with authorization)

Main Capabilities

Category	Features
WiFi	Evil Portal, Deauth attacks, Beacon spam, Wardriving, EAPOL capture, Packet sniffing
Bluetooth	BLE scanning, Device spam (iOS/Android/Windows), Bluetooth keyboard
SubGHz RF	Signal capture/replay, Spectrum analysis, Jamming (requires CC1101 module)
RFID/NFC	Read/write/clone tags, MIFARE, EM4100, NFC emulation (requires PN532)
BadUSB	HID keyboard emulation, Ducky script execution, Automated payloads
Infrared	TV-B-Gone, IR learning/replay, Custom protocols
Other	JavaScript scripting, Brucegotchi (Pwnagotchi friend), Web UI

Core Concept Analysis

The Hardware Ecosystem

┌─────────────────────────────────────────────────────────────────────┐
│                         BRUCE HARDWARE ECOSYSTEM                    │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  ┌───────────────────┐  ┌───────────────────┐  ┌─────────────────┐  │
│  │   M5Stack Family  │  │   LilyGo Family   │  │  Custom/DIY     │  │
│  ├───────────────────┤  ├───────────────────┤  ├─────────────────┤  │
│  │ • Cardputer ($50) │  │ • T-Deck ($65)    │  │ • ESP32-S3 +    │  │
│  │ • StickC Plus ($20)│  │ • T-Embed ($45)   │  │   Display +     │  │
│  │ • Core/Core2      │  │ • T-Display-S3    │  │   Keyboard      │  │
│  │ • M5Stack Fire    │  │ • T-Watch-S3      │  │ • Smoochiee V2  │  │
│  └───────────────────┘  └───────────────────┘  └─────────────────┘  │
│                                                                     │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │                     OPTIONAL MODULES                         │   │
│  ├──────────────────────────────────────────────────────────────┤   │
│  │  CC1101 (SubGHz)  │  PN532 (NFC/RFID)  │  GPS  │  SD Card    │   │
│  │  315/433/868/915MHz│  13.56MHz + 125kHz │  Wardriving │ Storage│   │
│  └──────────────────────────────────────────────────────────────┘   │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

The ESP32 Advantage

The ESP32 is a low-cost, low-power microcontroller with integrated WiFi and Bluetooth:

ESP32/ESP32-S3 Specifications:
├── CPU: Dual-core Xtensa LX6/LX7 @ 240MHz
├── RAM: 520KB SRAM (+ 8MB PSRAM on S3)
├── Flash: 4-16MB
├── WiFi: 802.11 b/g/n (2.4GHz)
├── Bluetooth: Classic + BLE 5.0
├── USB: OTG support (S3) for BadUSB
├── GPIO: 30+ programmable pins
└── Price: $3-10 for the chip alone

WiFi 802.11 Attack Surface

Understanding why WiFi attacks work:

802.11 Frame Types:
├── Management Frames (vulnerable!)
│   ├── Beacon: "I'm here, connect to me"
│   ├── Probe Request/Response: "Who's there?"
│   ├── Authentication: "Verify identity"
│   ├── Association: "Join network"
│   ├── Deauthentication: "Leave now!" ← ATTACKABLE
│   └── Disassociation: "Connection ended"
│
├── Control Frames
│   ├── RTS/CTS: Request/Clear to send
│   └── ACK: Acknowledgment
│
└── Data Frames
    └── Encrypted payload (WPA2/WPA3)

Why Deauth Works:
────────────────
1. Management frames are NOT encrypted (legacy design)
2. No verification of sender (spoofable MAC address)
3. Client MUST obey deauth frames (protocol spec)
4. Protected Management Frames (PMF) can prevent this
   but is not widely enabled

SubGHz RF Fundamentals

SubGHz Frequency Bands (CC1101):
├── 315 MHz: US garage doors, car remotes
├── 433.92 MHz: EU/worldwide, IoT devices, weather stations
├── 868 MHz: EU, smart home devices
└── 915 MHz: US, LoRa, industrial

Why SubGHz is Interesting:
────────────────────────────
1. Many devices use simple OOK/ASK modulation
2. Some use static codes (no rolling codes)
3. Long range (hundreds of meters)
4. Low power consumption
5. Less crowded than 2.4GHz

Attack Types:
├── Replay Attack: Record signal, play it back
├── Jamming: Flood frequency with noise
├── Brute Force: Try all codes (static only)
└── Rolljam: Jam + capture rolling codes

RFID/NFC Fundamentals

RFID Frequencies:
├── 125 kHz (LF): EM4100, HID Prox, T5577
│   └── Simple, long range, often no encryption
│
└── 13.56 MHz (HF): MIFARE, NFC, iClass
    ├── MIFARE Classic: Broken crypto (Darkside attack)
    ├── MIFARE DESFire: Strong encryption
    └── NFC: Payment cards, phones

How RFID Works:
───────────────
1. Reader emits electromagnetic field
2. Tag harvests energy from field (passive)
3. Tag modulates field to send data back
4. Reader decodes modulation

Attack Types:
├── Cloning: Copy UID and data to blank tag
├── Sniffing: Intercept reader-tag communication
├── Emulation: Pretend to be a tag
├── Brute Force: Try default keys
└── Relay Attack: Extend range with two devices

BadUSB / HID Attacks

How BadUSB Works:
─────────────────
1. Device appears as USB keyboard to computer
2. Operating systems trust keyboards implicitly
3. Device "types" commands at superhuman speed
4. Commands execute with user's privileges

Ducky Script Example:
────────────────────
DELAY 1000           // Wait for OS to recognize
GUI r                // Open Run dialog (Win+R)
DELAY 500
STRING powershell    // Type "powershell"
ENTER
DELAY 1000
STRING whoami        // Type command
ENTER

Defense:
├── USB device whitelisting
├── Disable USB ports
├── USBGuard (Linux)
└── User awareness

Project List

Projects are ordered from understanding fundamentals to building advanced security tools.

Project 1: ESP32 Hardware Exploration Lab

File: LEARN_BRUCE_FIRMWARE_DEEP_DIVE.md
Main Programming Language: C/C++ (Arduino/ESP-IDF)
Alternative Programming Languages: MicroPython, Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 1. The “Resume Gold”
Difficulty: Level 1: Beginner
Knowledge Area: Embedded Systems / Microcontrollers
Software or Tool: Arduino IDE, PlatformIO, ESP-IDF
Main Book: “Making Embedded Systems” by Elecia White

What you’ll build: A hardware exploration toolkit that blinks LEDs, reads buttons, displays text on screen, connects to WiFi, scans for networks, and outputs to serial—essentially learning the ESP32 before touching Bruce.

Why it teaches Bruce: Before you can understand Bruce, you need to understand the ESP32 it runs on. This project demystifies the hardware: GPIO, displays, WiFi stack, and the development environment.

Core challenges you’ll face:

Setting up the toolchain → maps to understanding ESP-IDF vs Arduino
Controlling GPIO pins → maps to hardware interaction basics
Using the WiFi stack → maps to networking foundations
Managing power and sleep modes → maps to embedded constraints

Key Concepts:

ESP32 Architecture: ESP-IDF Documentation
Arduino Core for ESP32: GitHub - espressif/arduino-esp32
WiFi Scanning: ESP-IDF WiFi documentation
GPIO Basics: “Making Embedded Systems” Chapter 5 - Elecia White

Difficulty: Beginner Time estimate: Weekend Prerequisites: Basic programming knowledge, soldering helpful

Real world outcome:

ESP32 Hardware Lab v1.0
========================
[Boot] Initializing...
[GPIO] LED on pin 2: READY
[Display] TFT 240x135: INITIALIZED
[WiFi] Scanning networks...

Found 12 networks:
  1. HomeNetwork_5G     -45 dBm  WPA2   CH 6
  2. CoffeeShop_Guest   -52 dBm  OPEN   CH 1
  3. OfficeWiFi         -67 dBm  WPA3   CH 11
  4. IoT_Devices        -71 dBm  WPA2   CH 3
  ...

[Button] Press A to scan again
[Button] Press B to connect to strongest
[Serial] Type network number to inspect

> 1
Inspecting: HomeNetwork_5G
  BSSID: AA:BB:CC:DD:EE:FF
  Signal: -45 dBm (Excellent)
  Security: WPA2-PSK
  Channel: 6
  Frequency: 2437 MHz

Implementation Hints:

Development environment setup:

Option 1: Arduino IDE (Beginner-friendly)
  - Install ESP32 board package
  - Select your board (e.g., M5Stack-Cardputer)
  - Use familiar Arduino functions

Option 2: PlatformIO (Professional)
  - VS Code extension
  - Better dependency management
  - Faster compilation

Option 3: ESP-IDF (Advanced)
  - Full access to all ESP32 features
  - FreeRTOS-based
  - Required for low-level WiFi hacking

Key ESP32 APIs to explore:

WiFi scanning:
  WiFi.mode(WIFI_STA);
  int n = WiFi.scanNetworks();
  WiFi.SSID(i), WiFi.RSSI(i), WiFi.encryptionType(i)

GPIO:
  pinMode(pin, OUTPUT/INPUT);
  digitalWrite(pin, HIGH/LOW);
  digitalRead(pin);

Display (TFT_eSPI or LovyanGFX):
  tft.init();
  tft.fillScreen(TFT_BLACK);
  tft.drawString("Hello", x, y);

Questions to explore:

What’s the difference between ESP32, ESP32-S2, ESP32-S3?
Why does the S3 have native USB while others need a USB-UART chip?
How much RAM/Flash does your device have?
What’s FreeRTOS and why does ESP32 use it?

Learning milestones:

LED blinks → You can control GPIO
WiFi scans complete → You understand the WiFi stack basics
Display shows networks → You can use peripherals
Serial responds to commands → You understand UART communication

Project 2: WiFi Deauthentication Deep Dive

File: LEARN_BRUCE_FIRMWARE_DEEP_DIVE.md
Main Programming Language: C (ESP-IDF)
Alternative Programming Languages: C++ (Arduino)
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 1. The “Resume Gold”
Difficulty: Level 3: Advanced
Knowledge Area: Wireless Security / 802.11 Protocol
Software or Tool: Wireshark, ESP-IDF, ESP32
Main Book: “802.11 Wireless Networks: The Definitive Guide” by Matthew Gast

What you’ll build: A WiFi analyzer that captures 802.11 management frames in promiscuous mode, displays them in real-time, and explains what each frame type does—then demonstrates how deauthentication attacks work (on your own test network).

Why it teaches Bruce: The WiFi deauth attack is one of Bruce’s most well-known features. By building your own, you’ll understand the 802.11 protocol, why the attack works, and why Protected Management Frames (PMF) prevent it.

Core challenges you’ll face:

Enabling promiscuous mode → maps to raw frame capture
Parsing 802.11 frame headers → maps to protocol understanding
Sending raw frames → maps to bypassing ESP-IDF restrictions
Understanding the legal/ethical implications → maps to responsible disclosure

Key Concepts:

802.11 Frame Format: “802.11 Wireless Networks” Chapter 4 - Gast
Deauth Attack Mechanics: Lab401 Academy - Deauthentication
ESP32 Promiscuous Mode: ESP-IDF WiFi Sniffer Example
Management Frame Protection: IEEE 802.11w standard

Difficulty: Advanced Time estimate: 1-2 weeks Prerequisites: Project 1, understanding of networking basics

Real world outcome:

802.11 Frame Analyzer v1.0
===========================
[Promiscuous Mode] ENABLED on channel 6
[Capture] Listening for management frames...

14:32:01.234 BEACON     AP: HomeNetwork     BSSID: AA:BB:CC:DD:EE:FF
14:32:01.456 PROBE_REQ  Client: 11:22:33:44:55:66  SSID: *broadcast*
14:32:01.567 PROBE_RESP AP: HomeNetwork -> 11:22:33:44:55:66
14:32:02.123 AUTH       11:22:33:44:55:66 -> AP (Open System)
14:32:02.234 AUTH       AP -> 11:22:33:44:55:66 (Success)
14:32:02.345 ASSOC_REQ  11:22:33:44:55:66 -> AP
14:32:02.456 ASSOC_RESP AP -> 11:22:33:44:55:66 (Success, AID=1)

[Connection Complete] Client joined HomeNetwork

--- DEAUTH SIMULATION (YOUR OWN NETWORK ONLY) ---
[!] Target AP: HomeNetwork (your test network)
[!] Sending 10 deauth frames...
[!] Frame 1: Deauth (Reason 7: Class 3 frame from non-associated STA)
...
[!] Client 11:22:33:44:55:66 disconnected from AP

[Analysis]
  - Reason Code 7 used (most effective)
  - Client will attempt to reconnect
  - No PMF protection detected on this network

Implementation Hints:

802.11 Management Frame Structure:

MAC Header (24 bytes):
├── Frame Control (2 bytes)
│   ├── Protocol Version (2 bits)
│   ├── Type (2 bits): 00=Mgmt, 01=Control, 10=Data
│   ├── Subtype (4 bits): Beacon=1000, Deauth=1100
│   └── Flags (8 bits)
├── Duration (2 bytes)
├── Address 1: Destination (6 bytes)
├── Address 2: Source (6 bytes)
├── Address 3: BSSID (6 bytes)
└── Sequence Control (2 bytes)

Deauth Frame Body:
└── Reason Code (2 bytes)
    Common codes:
    1: Unspecified
    2: Previous auth not valid
    3: Deauth leaving BSS
    7: Class 3 frame from non-associated station

ESP32 promiscuous mode:

// Enable promiscuous mode
esp_wifi_set_promiscuous(true);
esp_wifi_set_promiscuous_rx_cb(&sniffer_callback);

// In callback, parse the frame
void sniffer_callback(void* buf, wifi_promiscuous_pkt_type_t type) {
    wifi_promiscuous_pkt_t *pkt = (wifi_promiscuous_pkt_t*)buf;
    // pkt->payload contains the raw 802.11 frame
}

Sending raw frames (the tricky part):

ESP-IDF normally blocks sending arbitrary management frames.
Projects like esp32-deauther use patched libraries or
assembly-level bypasses to overcome this restriction.

See: github.com/risinek/esp32-wifi-penetration-tool

PMF (802.11w) check:

If MFPC (Management Frame Protection Capable) or
MFPR (Management Frame Protection Required) bits are set
in AP's beacon, deauth attacks won't work.

Modern WPA3 networks require PMF.

Learning milestones:

You capture beacon frames → You understand promiscuous mode
You decode frame headers → You understand 802.11 structure
You see why deauth works → You understand the vulnerability
You identify PMF networks → You understand the defense

Project 3: Evil Portal Captive Portal

File: LEARN_BRUCE_FIRMWARE_DEEP_DIVE.md
Main Programming Language: C++ (Arduino)
Alternative Programming Languages: MicroPython
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 2. The “Micro-SaaS / Pro Tool”
Difficulty: Level 2: Intermediate
Knowledge Area: Web Security / Social Engineering / Networking
Software or Tool: ESP32, ESPAsyncWebServer
Main Book: “The Web Application Hacker’s Handbook” by Dafydd Stuttard

What you’ll build: A captive portal system that creates a fake WiFi access point, serves a convincing login page (hotel, coffee shop, airline), captures entered credentials, and stores them—demonstrating phishing attacks on WiFi.

Why it teaches Bruce: Evil Portal is one of Bruce’s signature features. Building your own teaches you DNS hijacking, web server hosting on embedded devices, and why users should never enter credentials on public WiFi.

Core challenges you’ll face:

Creating an open access point → maps to AP mode configuration
Implementing DNS hijacking → maps to captive portal mechanics
Serving a convincing phishing page → maps to social engineering principles
Storing credentials securely → maps to embedded storage

Key Concepts:

Captive Portal Mechanics: RFC 7710 - Captive Portal Identification
DNS Spoofing: How DNS redirection works
ESP32 Web Server: ESPAsyncWebServer library
Social Engineering: “The Art of Deception” by Kevin Mitnick

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Projects 1-2, basic HTML/CSS

Real world outcome:

Evil Portal Started
====================
[AP] SSID: "Starbucks_Free_WiFi"
[AP] IP: 192.168.4.1
[DNS] Hijacking all domains → 192.168.4.1
[HTTP] Serving portal on port 80

Waiting for victims...

[14:32:01] New client connected: 192.168.4.2
[14:32:03] DNS query: www.google.com → 192.168.4.1
[14:32:05] HTTP GET / → Serving login page
[14:32:15] ⚠️ CREDENTIALS CAPTURED:
           Email: victim@example.com
           Password: MyS3cr3tP@ss

[Credentials saved to /creds/captured.csv]

View at: http://192.168.4.1/creds (authenticated)

─────────────────────────────────────
DEMONSTRATION PURPOSES ONLY
Never use on networks without authorization!
─────────────────────────────────────

Implementation Hints:

Captive portal flow:

1. Device connects to open WiFi
2. OS detects captive portal:
   - iOS: Requests captive.apple.com
   - Android: Requests connectivitycheck.gstatic.com
   - Windows: Requests msftconnecttest.com
3. If response isn't expected, shows portal
4. Our DNS server redirects ALL queries to ESP32 IP
5. ESP32 web server serves phishing page
6. User enters credentials, we capture them

Key components:

// 1. Access Point Mode
WiFi.softAP("Starbucks_Free_WiFi", NULL);  // Open network

// 2. DNS Server (redirect all)
dnsServer.start(53, "*", WiFi.softAPIP());

// 3. Web Server
server.on("/", HTTP_GET, serveLandingPage);
server.on("/login", HTTP_POST, captureCredentials);
server.on("/creds", HTTP_GET, showCapturedCreds);

// 4. Handle OS detection endpoints
server.on("/generate_204", HTTP_GET, servePortal);       // Android
server.on("/hotspot-detect.html", HTTP_GET, servePortal); // iOS

Phishing page design tips:

- Match the look of common portals (hotels, airlines, coffee shops)
- Use HTTPS lock icons (fake, but convincing)
- Include terms of service to look legitimate
- Redirect to real site after capture to reduce suspicion
- Store timestamp, IP, and user-agent with credentials

Ethical considerations:

This technique is used by:
1. Pentesters (with authorization) - Test employee awareness
2. Red Teams - Simulate real attacks
3. Researchers - Study user behavior
4. Malicious actors - Steal credentials (ILLEGAL)

Only use on networks you own or have written authorization to test!

Learning milestones:

AP broadcasts and clients connect → You understand AP mode
DNS redirects all traffic → You understand DNS hijacking
Portal captures credentials → You understand phishing mechanics
You recognize the defense → Always verify HTTPS and certificates

Project 4: RFID/NFC Reader & Cloner

File: LEARN_BRUCE_FIRMWARE_DEEP_DIVE.md
Main Programming Language: C++ (Arduino)
Alternative Programming Languages: Python (libnfc)
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 2. The “Micro-SaaS / Pro Tool”
Difficulty: Level 3: Advanced
Knowledge Area: RFID Security / Access Control
Software or Tool: PN532 module, ESP32, Proxmark3 (optional)
Main Book: “RFID Handbook” by Klaus Finkenzeller

What you’ll build: An RFID/NFC tool that reads various tag types (MIFARE Classic, EM4100, NFC), displays the UID and data, and can clone compatible tags to writable cards like T5577 or Magic MIFARE.

Why it teaches Bruce: RFID cloning is a core Bruce feature for physical security testing. Building your own teaches you how access control systems work, their weaknesses, and why “security by obscurity” fails.

Core challenges you’ll face:

Interfacing PN532 over SPI/I2C → maps to hardware communication
Reading different tag types → maps to protocol understanding
Implementing MIFARE authentication → maps to crypto weaknesses
Writing to cloneable tags → maps to card emulation

Key Concepts:

RFID Fundamentals: “RFID Handbook” Chapters 1-5 - Finkenzeller
MIFARE Classic Vulnerabilities: Darkside and Nested attacks
PN532 Library: Adafruit PN532 library documentation
T5577 Programming: Low-frequency writable tag protocol

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Projects 1-2, basic electronics (SPI/I2C)

Real world outcome:

RFID/NFC Multi-Tool v1.0
========================
[PN532] Initialized on SPI
[Mode] High Frequency (13.56 MHz)

[Scan] Place card on reader...

=== TAG DETECTED ===
Type: MIFARE Classic 1K
UID: 04:A2:B3:C4 (4 bytes)
ATQA: 0x0004
SAK: 0x08

[Key Attack] Testing default keys...
  Key A (FFFFFFFFFFFF): ✓ Sector 0
  Key A (FFFFFFFFFFFF): ✓ Sector 1
  ...all sectors use default keys!

[Dump] Reading all sectors...
Sector 0: 04 A2 B3 C4 00 00 00 00 00 00 00 00 00 00 00 00
Sector 1: 00 00 00 00 00 00 FF 07 80 69 FF FF FF FF FF FF
...

[Clone] Options:
  1. Write to Magic MIFARE (UID changeable)
  2. Write to regular MIFARE (UID preserved)
  3. Save dump to SD card

> 3
[Saved] /dumps/mifare_04A2B3C4.bin

=== LOW FREQUENCY MODE ===
[LF] Switching to 125 kHz...
[Scan] Place card on reader...

Type: EM4100
ID: 12:34:56:78:9A (40 bits)
Facility Code: 123
Card Number: 45678

[Clone] Write to T5577 blank?
> y
[Writing] T5577 programming...
[Success] Clone complete. Verify by scanning.

Implementation Hints:

Hardware setup:

PN532 Module Wiring (SPI mode):
  VCC → 3.3V
  GND → GND
  SCK → GPIO18
  MISO → GPIO19
  MOSI → GPIO23
  SS → GPIO5
  IRQ → GPIO4 (optional)

Note: PN532 supports both 13.56MHz (NFC/MIFARE)
      For 125kHz (EM4100/HID), use RFID-RC522 or separate module

MIFARE Classic structure:

1K Card = 16 sectors × 4 blocks × 16 bytes = 1024 bytes

Each sector:
  Block 0-2: Data blocks
  Block 3: Sector trailer (Key A + Access bits + Key B)

Sector 0, Block 0: Manufacturer block (UID + manufacturer data)
  - Read-only on genuine cards
  - Writable on "Magic" cards (UID changeable)

Default keys to try:

uint8_t default_keys[][6] = {
    {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF},  // Factory default
    {0xA0, 0xA1, 0xA2, 0xA3, 0xA4, 0xA5},  // MAD key
    {0xD3, 0xF7, 0xD3, 0xF7, 0xD3, 0xF7},  // NDEF key
    {0x00, 0x00, 0x00, 0x00, 0x00, 0x00},  // All zeros
    // Add more based on target system
};

T5577 cloning (125kHz):

T5577 is a writable LF tag that can emulate:
  - EM4100 (most common)
  - HID Prox
  - Indala
  - And others

Write process:
  1. Send password (if set) or default 00000000
  2. Write configuration block (block 0)
  3. Write data blocks (blocks 1-7)
  4. Verify by reading back

Learning milestones:

You read a MIFARE UID → You understand card communication
You authenticate with keys → You understand MIFARE security
You dump card contents → You can extract access control data
You clone to a blank → You understand why physical security matters

Project 5: SubGHz Signal Analyzer & Replay

File: LEARN_BRUCE_FIRMWARE_DEEP_DIVE.md
Main Programming Language: C++ (Arduino)
Alternative Programming Languages: Python (with SDR)
Coolness Level: Level 5: Pure Magic
Business Potential: 2. The “Micro-SaaS / Pro Tool”
Difficulty: Level 4: Expert
Knowledge Area: Radio Frequency / Signal Processing
Software or Tool: CC1101 module, Universal Radio Hacker, ESP32
Main Book: “Software Defined Radio for Engineers” by Travis Collins

What you’ll build: A SubGHz tool using the CC1101 transceiver that scans frequencies, captures signals from devices like garage doors and car remotes, analyzes them with spectrum display, and can replay captured signals.

Why it teaches Bruce: SubGHz is one of Bruce’s most powerful features (with hardware addon). Understanding RF capture and replay teaches you why many IoT devices are insecure and how rolling codes attempt to prevent replay attacks.

Core challenges you’ll face:

Configuring CC1101 for different frequencies → maps to RF transceiver programming
Capturing and storing RF signals → maps to signal sampling
Analyzing modulation (OOK, FSK) → maps to signal processing basics
Understanding rolling codes → maps to why simple replay fails

Key Concepts:

CC1101 Datasheet: Texas Instruments CC1101
OOK/ASK Modulation: On-Off Keying basics
Rolling Codes: KeeLoq and similar systems
RadioLib: ESP32 radio library

Difficulty: Expert Time estimate: 3-4 weeks Prerequisites: Projects 1-4, basic understanding of radio concepts

Real world outcome:

SubGHz Analyzer v1.0 (CC1101)
=============================
[RF] CC1101 initialized
[Freq] 433.92 MHz (EU ISM band)
[Mode] RX - Listening...

=== SPECTRUM ANALYZER ===
430 MHz |
431 MHz |
432 MHz |    ▂
433 MHz |    █ ▄
434 MHz |  ▂ █ █ ▂     ▂ ▄
435 MHz |

[SIGNAL DETECTED]
Frequency: 433.92 MHz
Modulation: OOK (On-Off Keying)
Bit Rate: ~1000 bps
Duration: 450ms

[CAPTURE] Recording to buffer...
[DECODE] Attempting protocol decode...

Protocol: Generic garage door (no rolling code)
Bits: 24
Code: 0xAB12CD
Pattern: 101010110001001011001101

[WARNING] Static code detected - vulnerable to replay!

Options:
  1. Save raw signal
  2. Replay signal (YOUR DEVICES ONLY)
  3. Analyze further
  4. Continue scanning

> 2
[TX] Transmitting captured signal...
[TX] Complete (450ms)

=== ROLLING CODE DETECTION ===
[Capture 1] Code: 0x1234ABCD5678
[Capture 2] Code: 0x1234ABCD9ABC
[Analysis] Codes differ - rolling code system detected
[Warning] Simple replay will NOT work
[Info] Research: Rolljam attack (capture + jam)

Implementation Hints:

CC1101 wiring:

CC1101 → ESP32
  VCC  → 3.3V (NOT 5V!)
  GND  → GND
  SCK  → GPIO18
  MISO → GPIO19
  MOSI → GPIO23
  CSN  → GPIO5
  GDO0 → GPIO4 (signal detect)
  GDO2 → GPIO2 (optional)

Common frequency bands:

00 MHz - US garage doors, car remotes
92 MHz - EU/worldwide, weather stations, cheap remotes
35 MHz - EU smart home (Z-Wave, some Zigbee)
00 MHz - US LoRa, industrial

Signal capture approach:

Set CC1101 to target frequency
Configure for OOK receive (most common)
Monitor GDO0 for signal detection
When detected, sample at high rate
Store timing intervals (mark/space)
Analyze for protocol patterns

Why rolling codes work:

Static code: Same code every time → Easy replay

Rolling code (e.g., KeeLoq):
  - Transmitter and receiver share a secret key
  - Each press increments a counter
  - Code = Encrypt(counter, secret_key)
  - Receiver accepts only if counter > last_seen

Rolljam attack (advanced):
  1. Jam the first transmission (receiver doesn't get it)
  2. Capture the code
  3. When user presses again, jam and capture second code
  4. Send first code (receiver accepts it)
  5. Attacker keeps second code for later use

This is why modern cars use more sophisticated systems!

Learning milestones:

You capture a garage door signal → You understand RF basics
You successfully replay it → You understand static code vulnerability
You identify rolling codes → You understand modern protections
You build a spectrum analyzer → You understand frequency domains

Project 6: BadUSB Payload Delivery System

File: LEARN_BRUCE_FIRMWARE_DEEP_DIVE.md
Main Programming Language: C++ (Arduino)
Alternative Programming Languages: CircuitPython
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 2. The “Micro-SaaS / Pro Tool”
Difficulty: Level 2: Intermediate
Knowledge Area: USB Security / HID Attacks
Software or Tool: ESP32-S3, Ducky Script, Rubber Ducky payloads
Main Book: “USB Complete” by Jan Axelson

What you’ll build: A BadUSB device using ESP32-S3’s native USB that executes Ducky Script payloads, appearing as a keyboard to inject keystrokes, download and execute payloads, and exfiltrate data.

Why it teaches Bruce: BadUSB is a powerful attack vector in Bruce. Understanding USB HID exploits teaches you why you should never plug in unknown USB devices and how attackers can compromise systems in seconds.

Core challenges you’ll face:

USB HID enumeration → maps to USB device classes
Parsing Ducky Script → maps to attack payload syntax
Timing attacks correctly → maps to keystroke injection speed
Evading defenses → maps to EDR and USB blocking

Key Concepts:

USB HID Protocol: “USB Complete” Chapters 10-11 - Axelson
Ducky Script: Hak5 Ducky Script Documentation
ESP32-S3 USB: TinyUSB library
Attack Payloads: USB Rubber Ducky Payloads

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Project 1, understanding of OS command lines

Real world outcome:

BadUSB Payload Executor v1.0
============================
[USB] Initializing as HID Keyboard...
[USB] VID:PID = 0x1234:0x5678
[USB] Manufacturer: "Generic Keyboard"
[USB] Enumerated successfully

[Payloads Available]
  1. windows_info.txt - Gather system info
  2. rickroll.txt - Open YouTube (harmless demo)
  3. reverse_shell.txt - ⚠️ Dangerous - test only
  4. wifi_dump.txt - Extract saved WiFi passwords
  5. custom.txt - Your payload

Select payload: 2

[Executing] rickroll.txt
DELAY 2000
  [Waiting 2000ms for OS to recognize device]
GUI r
  [Sending Win+R] Opening Run dialog
DELAY 500
STRING https://youtu.be/dQw4w9WgXcQ
  [Typing URL at 100 chars/sec]
ENTER
  [Pressing Enter]

[Complete] Payload executed in 3.2 seconds

─────────────────────────────────
TEST ON YOUR OWN SYSTEMS ONLY!
─────────────────────────────────

Implementation Hints:

Why ESP32-S3?:

ESP32-S3 has native USB OTG support:
  - Can act as USB device (keyboard, mouse, storage)
  - No USB-UART chip needed
  - Full control over USB descriptors

ESP32 (original) does NOT have native USB!
  - Uses CP2102/CH340 USB-UART bridge
  - Cannot do HID attacks

Ducky Script syntax:

DELAY <ms>        - Wait milliseconds
STRING <text>     - Type text
ENTER            - Press Enter
GUI <key>        - Windows/Command key combo
ALT <key>        - Alt combo
CTRL <key>       - Control combo
SHIFT            - Shift modifier
REM <comment>    - Comment (ignored)

Example: Open PowerShell as admin on Windows
──────────────────────────────────────────────
DELAY 2000
GUI x
DELAY 200
STRING a
DELAY 1000
ALT y
DELAY 1000
STRING whoami
ENTER

USB HID report format:

Keyboard HID Report (8 bytes):
  Byte 0: Modifier keys (Ctrl, Shift, Alt, GUI)
  Byte 1: Reserved (0x00)
  Bytes 2-7: Key codes (up to 6 simultaneous keys)

Modifier bits:
  0x01: Left Ctrl
  0x02: Left Shift
  0x04: Left Alt
  0x08: Left GUI (Windows key)
  0x10: Right Ctrl
  ...

Defense evasion techniques:

Randomize typing speed (avoid perfect timing detection)
Add small delays between keystrokes
Use alternative key combos (CTRL+SHIFT+ESC vs GUI+X)
Check for VM/sandbox indicators first
Split payload into multiple stages

Learning milestones:

Device enumerates as keyboard → You understand USB HID
Simple payload executes → You understand keystroke injection
Complex payload works → You understand OS automation
You recognize the threat → Never plug in unknown USB devices

Project 7: Bluetooth/BLE Security Scanner

File: LEARN_BRUCE_FIRMWARE_DEEP_DIVE.md
Main Programming Language: C++ (Arduino/ESP-IDF)
Alternative Programming Languages: Python (bleak library)
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 2. The “Micro-SaaS / Pro Tool”
Difficulty: Level 3: Advanced
Knowledge Area: Bluetooth Security / BLE
Software or Tool: ESP32, nRF Connect (reference)
Main Book: “Getting Started with Bluetooth Low Energy” by Kevin Townsend

What you’ll build: A Bluetooth/BLE scanner that discovers nearby devices, identifies device types, detects vulnerabilities, and can perform BLE spam attacks (popup notifications on iOS/Android).

Why it teaches Bruce: Bruce’s BLE features include device scanning and spam attacks. Understanding Bluetooth teaches you about another wireless attack surface and why Bluetooth should be disabled when not in use.

Core challenges you’ll face:

BLE scanning and service discovery → maps to GATT protocol
Identifying device types from advertisements → maps to device fingerprinting
Crafting BLE advertisements → maps to popup spam mechanics
Understanding BLE security modes → maps to pairing vulnerabilities

Key Concepts:

BLE Fundamentals: “Getting Started with BLE” Chapters 1-4 - Townsend
GATT Services: Bluetooth SIG assigned numbers
Apple Continuity Protocol: Researches on AirDrop, Handoff
BLE Security: Pairing, bonding, MITM protection

Difficulty: Advanced Time estimate: 2 weeks Prerequisites: Projects 1-2, basic understanding of Bluetooth

Real world outcome:

BLE Security Scanner v1.0
=========================
[BLE] Initialized
[Scan] Discovering devices...

Found 15 BLE devices:

 # | Name              | MAC Address       | RSSI  | Type
───┼───────────────────┼───────────────────┼───────┼──────────────
 1 | iPhone (John)     | AA:BB:CC:DD:EE:01 | -45   | Apple iOS
 2 | Galaxy S23        | AA:BB:CC:DD:EE:02 | -52   | Samsung
 3 | AirPods Pro       | AA:BB:CC:DD:EE:03 | -48   | Apple Audio
 4 | Tile Tracker      | AA:BB:CC:DD:EE:04 | -67   | Tracker
 5 | Fitbit Charge 5   | AA:BB:CC:DD:EE:05 | -71   | Fitness
 6 | Unknown           | AA:BB:CC:DD:EE:06 | -80   | Generic
...

[Analysis] iPhone (John):
  Manufacturer: Apple Inc.
  Services: Continuity, AirDrop, Handoff
  Nearby: Sharing contact card? YES
  Vulnerability: Contact info leak possible

[Demo] BLE Spam Attack Options:
  1. iOS Popup Spam (AirPods pairing request)
  2. Android Fast Pair Spam
  3. Windows Swift Pair Spam
  4. Samsung SmartTag Spam

> 1
[TX] Broadcasting fake AirPods advertisement...
[TX] iOS devices in range will see pairing popup

⚠️ This is annoying but harmless - demonstration only!
Press any key to stop...

[Stopped] Broadcast ended.

Implementation Hints:

BLE advertising packet structure:

BLE Advertisement (max 31 bytes):
├── Length (1 byte)
├── AD Type (1 byte)
└── AD Data (variable)

Common AD Types:
  0x01: Flags
  0x09: Complete Local Name
  0xFF: Manufacturer Specific Data

Apple device detection:

// Apple Continuity protocol detection
// Manufacturer ID: 0x004C (Apple)
if (manufacturer_data[0] == 0x4C && manufacturer_data[1] == 0x00) {
    // Parse Continuity message type
    uint8_t msg_type = manufacturer_data[2];
    switch(msg_type) {
        case 0x07: return "AirPods";
        case 0x10: return "Nearby";
        case 0x0F: return "AirDrop";
    }
}

BLE spam concept:

iOS responds to specific BLE advertisements as if
they were Apple devices wanting to pair.

Fake AirPods advertisement:
  - Manufacturer: Apple (0x004C)
  - Type: Proximity Pairing (0x07)
  - Status: Available for pairing

Result: iOS shows "AirPods nearby" popup

This is annoying but not harmful - used for
awareness demonstrations.

BLE security considerations:

BLE Security Modes:
  Mode 1, Level 1: No security
  Mode 1, Level 2: Unauthenticated pairing (vulnerable to MITM)
  Mode 1, Level 3: Authenticated pairing (PIN)
  Mode 1, Level 4: Secure Connections (ECDH)

Many IoT devices use Level 1 or 2!

Learning milestones:

You discover all nearby BLE devices → You understand scanning
You identify Apple devices → You understand advertisement parsing
You trigger popup on iOS → You understand BLE broadcast
You recognize the tracking risk → BLE is always broadcasting

Project 8: Bruce Firmware Contribution

File: LEARN_BRUCE_FIRMWARE_DEEP_DIVE.md
Main Programming Language: C++ (PlatformIO)
Alternative Programming Languages: N/A (Bruce is C++)
Coolness Level: Level 5: Pure Magic
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 4: Expert
Knowledge Area: Open Source / Embedded Development
Software or Tool: PlatformIO, Git, GitHub
Main Book: “Working Effectively with Legacy Code” by Michael Feathers

What you’ll build: Contribute a new feature or fix to the actual Bruce firmware: understand the codebase architecture, set up the build environment, implement a feature (new protocol, UI improvement, or bug fix), and submit a pull request.

Why it teaches Bruce: The ultimate way to learn Bruce is to contribute to it. You’ll understand the architecture, coding patterns, and how all the pieces fit together. Plus, you’ll be giving back to the community.

Core challenges you’ll face:

Understanding the codebase architecture → maps to reading legacy code
Setting up the multi-target build → maps to PlatformIO expertise
Following project conventions → maps to open source contribution
Testing across hardware variants → maps to embedded testing challenges

Key Concepts:

Bruce Source Code: GitHub - pr3y/Bruce
PlatformIO: PlatformIO Documentation
ESP-IDF Internals: Understanding the underlying framework
Open Source Contribution: “Producing Open Source Software” by Karl Fogel (free online)

Difficulty: Expert Time estimate: 2-4 weeks Prerequisites: All previous projects, strong C++ skills, Git proficiency

Real world outcome:

Bruce Contribution Journey
==========================

1. [Fork] Created fork: github.com/yourname/Bruce
2. [Clone] git clone --recursive https://github.com/yourname/Bruce
3. [Build] pio run -e m5stack-cardputer
   ✓ Build successful (234 seconds)

4. [Feature] Implementing: "WiFi Client Info Display"
   - Shows connected clients on Evil Portal
   - Displays MAC, IP, and hostname
   - Real-time updates

5. [Files Modified]
   src/modules/wifi/evil_portal.cpp
   src/modules/wifi/evil_portal.h
   src/core/display/display.cpp

6. [Test] Flashed to M5Stack Cardputer
   ✓ Feature works as expected
   ✓ No regressions in existing features

7. [PR] Pull Request #XXX opened
   Title: "Add connected clients display to Evil Portal"

   Description:
   - Shows MAC address of connected devices
   - Updates in real-time as clients connect/disconnect
   - Added to Evil Portal submenu

   Testing:
   - Tested on Cardputer and StickC Plus
   - Verified memory usage doesn't increase significantly

8. [Review] Maintainer feedback received
   - Suggested code style improvements
   - Requested additional null checks

9. [Merged] 🎉 PR merged into main branch!

Implementation Hints:

Bruce project structure:

Bruce/
├── src/
│   ├── core/           # Core functionality
│   │   ├── display/    # Display drivers
│   │   ├── mykeyboard/ # Keyboard handling
│   │   └── sd_functions.cpp
│   ├── modules/        # Feature modules
│   │   ├── wifi/       # WiFi attacks
│   │   ├── ble/        # Bluetooth features
│   │   ├── rf/         # SubGHz (CC1101)
│   │   ├── rfid/       # RFID/NFC
│   │   ├── ir/         # Infrared
│   │   └── others/     # Misc features
│   └── main.cpp
├── platformio.ini      # Build configuration
└── boards/             # Board-specific configs

Build commands:

# Install PlatformIO
pip install platformio

# Build for specific board
pio run -e m5stack-cardputer
pio run -e lilygo-t-deck

# Upload to device
pio run -e m5stack-cardputer -t upload

# Monitor serial output
pio device monitor

Contribution guidelines:

Check existing issues/PRs for similar features
Open an issue to discuss before major changes
Follow existing code style
Test on at least one physical device
Update documentation if needed
Keep PRs focused (one feature/fix per PR)

Good first contributions:

- Fix typos in UI text
- Add new Ducky Script commands
- Improve display layouts
- Add new IR remote codes
- Write documentation
- Test and report bugs

Learning milestones:

You build Bruce from source → You understand the toolchain
You navigate the codebase → You understand the architecture
You implement a feature → You can extend Bruce
Your PR is merged → You’re a Bruce contributor!

Project 9: Custom Security Hardware Design

File: LEARN_BRUCE_FIRMWARE_DEEP_DIVE.md
Main Programming Language: C++ (firmware) + KiCad (hardware)
Alternative Programming Languages: N/A
Coolness Level: Level 5: Pure Magic
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 5: Master
Knowledge Area: Hardware Design / PCB / RF
Software or Tool: KiCad, ESP32-S3, CC1101, PN532
Main Book: “Designing Electronics That Work” by Hunter Scott

What you’ll build: Design and fabricate your own Bruce-compatible security device from scratch: PCB design with ESP32-S3, display, keyboard/buttons, CC1101 SubGHz, PN532 RFID, and battery management.

Why it teaches Bruce: The ultimate project—designing your own hardware. You’ll understand every component, make trade-offs, and create a device tailored to your needs. This is how the Smoochiee V2 and other community hardware came to be.

Core challenges you’ll face:

Schematic capture → maps to electronic circuit design
PCB layout with RF considerations → maps to signal integrity
Component selection → maps to supply chain/BOM management
Firmware adaptation → maps to board support packages

Key Concepts:

ESP32-S3 Design Guide: Espressif Hardware Design Guidelines
RF PCB Design: CC1101 reference designs
KiCad: KiCad Documentation
PCB Fabrication: JLCPCB, PCBWay guides

Difficulty: Master Time estimate: 2-3 months Prerequisites: All previous projects, electronics fundamentals, KiCad basics

Real world outcome:

Custom Security Device: "NightOwl"
==================================

Specifications:
  ├── MCU: ESP32-S3-WROOM-1 (8MB Flash, 8MB PSRAM)
  ├── Display: 2.4" IPS TFT (320x240)
  ├── Input: 5-way joystick + 4 buttons
  ├── Power: 2000mAh LiPo + USB-C charging
  ├── WiFi: Built-in 2.4GHz
  ├── SubGHz: CC1101 (300-928MHz)
  ├── RFID: PN532 (13.56MHz + 125kHz)
  ├── Storage: MicroSD slot
  └── Size: 80mm x 50mm x 15mm

Design Files:
  ├── schematic.kicad_sch
  ├── pcb.kicad_pcb
  ├── gerbers/
  ├── bom.csv
  └── firmware/

Manufacturing:
  ├── PCB: JLCPCB (5 boards, $15)
  ├── Components: LCSC + DigiKey ($45)
  └── Assembly: Hand soldered

Testing:
  ✓ Power supply: 3.3V rail stable
  ✓ ESP32-S3: Boots and runs Bruce
  ✓ Display: All pixels working
  ✓ CC1101: Receives 433MHz signals
  ✓ PN532: Reads MIFARE cards
  ✓ Battery: 8+ hours runtime

Shared on GitHub: github.com/yourname/nightowl-hardware
Featured in Bruce wiki as community hardware!

Implementation Hints:

Core components:

ESP32-S3-WROOM-1:
  - Native USB for BadUSB
  - WiFi + BLE built-in
  - Enough GPIO for everything

CC1101 Module:
  - SPI interface
  - External antenna recommended for range
  - Keep analog sections away from digital noise

PN532:
  - SPI or I2C (SPI recommended for speed)
  - External antenna for better read range
  - Shield from CC1101 interference

Power:
  - TP4056 or IP5306 for battery management
  - 3.3V LDO for stable supply
  - Consider power gating for modules

PCB design tips:

1. Layer stackup: 4 layers recommended
   - Top: Components + signals
   - Inner 1: Ground plane (solid!)
   - Inner 2: Power plane
   - Bottom: Components + signals

2. RF considerations:
   - Keep CC1101 antenna trace impedance matched (50Ω)
   - Ground pour around RF section
   - Separate analog and digital grounds, meet at one point

3. USB considerations:
   - 90Ω differential impedance for USB D+/D-
   - Keep traces short and equal length

4. EMI:
   - Ferrite beads on power inputs
   - Decoupling caps near every IC
   - Avoid long parallel traces

Firmware adaptation:

Create new board definition in platformio.ini
Define GPIO mappings in hardware config
Test each peripheral individually
Submit to Bruce as new hardware target

Learning milestones:

Schematic captures all features → You understand system architecture
PCB passes DRC → You understand layout constraints
Fabricated board powers on → Your design works!
Bruce runs on your hardware → You’ve created a new platform

Project Comparison Table

Project	Difficulty	Time	Depth of Understanding	Fun Factor
1. ESP32 Hardware Lab	Beginner	Weekend	⭐⭐	⭐⭐⭐
2. WiFi Deauth Deep Dive	Advanced	1-2 weeks	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
3. Evil Portal	Intermediate	1-2 weeks	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
4. RFID Reader & Cloner	Advanced	2-3 weeks	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
5. SubGHz Analyzer	Expert	3-4 weeks	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
6. BadUSB Payload System	Intermediate	1-2 weeks	⭐⭐⭐	⭐⭐⭐⭐
7. BLE Security Scanner	Advanced	2 weeks	⭐⭐⭐⭐	⭐⭐⭐⭐
8. Bruce Contribution	Expert	2-4 weeks	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
9. Custom Hardware Design	Master	2-3 months	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐

Recommended Learning Path

If you’re new to embedded/security:

Start with: Project 1 → 3 → 6 → 2

This path starts with hardware basics, then builds a visually impressive Evil Portal, learns BadUSB (simpler than WiFi), and finally dives into WiFi internals.

If you’re a pentester wanting to understand the tools:

Start with: Project 2 → 3 → 4 → 5

Focus on the attack techniques: WiFi deauth, phishing portals, RFID cloning, and SubGHz—the core offensive capabilities.

If you want to contribute to open source:

Start with: Project 1 → 8 (jump in!)

Get the basics, then dive into the codebase. The best way to learn is to read and modify real code.

If you’re a hardware enthusiast:

Full path: Projects 1-7, then Project 9

Build all the software projects to understand requirements, then design your dream hardware.

Final Capstone Project: Complete Security Assessment Platform

File: LEARN_BRUCE_FIRMWARE_DEEP_DIVE.md
Main Programming Language: C++ (ESP32) + Python (companion app)
Alternative Programming Languages: N/A
Coolness Level: Level 5: Pure Magic
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 5: Master
Knowledge Area: Full-stack Security Tooling
Software or Tool: ESP32-S3, CC1101, PN532, custom PCB
Main Book: All previous + “The Hacker Playbook 3” by Peter Kim

What you’ll build: A complete security assessment platform combining all previous projects: custom hardware running enhanced Bruce, companion smartphone app for control and logging, automated attack workflows, and comprehensive reporting.

Why this is the capstone: This integrates everything: hardware design, firmware development, wireless attacks, physical security testing, and professional reporting. It’s what a commercial product would look like.

Real world outcome:

┌─────────────────────────────────────────────────────────────────┐
│              SECURITY ASSESSMENT PLATFORM                       │
│                     "Project Owl"                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │                    CUSTOM HARDWARE                        │  │
│  │  ESP32-S3 │ CC1101 │ PN532 │ 2.4" Display │ 2000mAh      │  │
│  └───────────────────────────────────────────────────────────┘  │
│                            │                                    │
│                       BLE/WiFi                                  │
│                            │                                    │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │                   COMPANION APP                           │  │
│  │  Live Control │ GPS Logging │ Report Generation           │  │
│  └───────────────────────────────────────────────────────────┘  │
│                                                                 │
│  CAPABILITIES:                                                  │
│  ├── WiFi: Scan, Deauth, Evil Portal, Wardriving              │
│  ├── SubGHz: Capture, Replay, Analyze                         │
│  ├── RFID: Read, Clone, Emulate                               │
│  ├── BLE: Scan, Fingerprint, Spam                             │
│  ├── BadUSB: Payload Delivery                                 │
│  └── IR: Learn, Replay                                        │
│                                                                 │
│  ASSESSMENT MODE:                                              │
│  [Start Assessment] → GPS-tagged findings                     │
│  [Generate Report] → PDF with all captured data               │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Summary

#	Project	Main Language
1	ESP32 Hardware Exploration Lab	C/C++ (Arduino)
2	WiFi Deauthentication Deep Dive	C (ESP-IDF)
3	Evil Portal Captive Portal	C++ (Arduino)
4	RFID/NFC Reader & Cloner	C++ (Arduino)
5	SubGHz Signal Analyzer & Replay	C++ (Arduino)
6	BadUSB Payload Delivery System	C++ (Arduino)
7	Bluetooth/BLE Security Scanner	C++ (Arduino)
8	Bruce Firmware Contribution	C++ (PlatformIO)
9	Custom Security Hardware Design	C++ + KiCad
Capstone	Complete Security Assessment Platform	C++ + Python

Additional Resources

Official Bruce Resources

Bruce Website - Official site
Bruce GitHub - Source code
Bruce Wiki - Documentation
Bruce Discord - Community

Hardware

M5Stack Store - Cardputer, StickC Plus
LilyGo Store - T-Deck, T-Embed
Smoochiee V2 - Community hardware

Flipper Zero - The inspiration
ESP32-Deauther - WiFi deauth focused
Evil-M5Project - Another M5Stack security firmware
CapibaraZero - Flipper Zero alternative

Books

“802.11 Wireless Networks” by Matthew Gast - WiFi deep dive
“RFID Handbook” by Klaus Finkenzeller - RFID fundamentals
“Getting Started with BLE” by Kevin Townsend - Bluetooth basics
“Making Embedded Systems” by Elecia White - Embedded development

Legal & Ethical

Always get written authorization before testing
Understand your local laws regarding RF transmission
Never use these tools maliciously
Report vulnerabilities responsibly
Bruce is for education and authorized testing only

Generated for your Bruce firmware learning journey. Remember: with great power comes great responsibility. Use these skills ethically and legally.

Learn Bruce Firmware: From Zero to Offensive Security Tool Builder

What is Bruce Firmware?

Why Does Bruce Exist?

What is Bruce Used For?

Legitimate Use Cases

Main Capabilities

Core Concept Analysis

The Hardware Ecosystem

The ESP32 Advantage

WiFi 802.11 Attack Surface

SubGHz RF Fundamentals

RFID/NFC Fundamentals

BadUSB / HID Attacks

Project List

Project 1: ESP32 Hardware Exploration Lab

Project 2: WiFi Deauthentication Deep Dive

Project 3: Evil Portal Captive Portal

Project 4: RFID/NFC Reader & Cloner

Project 5: SubGHz Signal Analyzer & Replay

Project 6: BadUSB Payload Delivery System

Project 7: Bluetooth/BLE Security Scanner

Project 8: Bruce Firmware Contribution

Project 9: Custom Security Hardware Design

Project Comparison Table

Recommended Learning Path

If you’re new to embedded/security:

If you’re a pentester wanting to understand the tools:

If you want to contribute to open source:

If you’re a hardware enthusiast:

Final Capstone Project: Complete Security Assessment Platform

Summary

Additional Resources

Official Bruce Resources

Hardware

Related Projects

Books

Legal & Ethical