# Hardware, IoT, firmware and embedded systems

Treat hardware research as a **versioned product and attacker-access investigation**. A firmware image, a physical device, its radio interface and its cloud service can have different owners and different bounty eligibility. A weakness visible after dismantling a device may fall outside a program that only accepts remote or closed-chassis attacks.

## Roadmap and entry criteria

| Stage | Work product | Exit criterion |
|---|---|---|
| Firmware literacy | Architecture map, image inventory and recovered filesystem where present | Explain boot, update, persistence and service startup without executing unknown binaries on the workstation |
| Device observation | Own-device baseline, controlled network capture and interface inventory | Distinguish provisioning, normal operation and recovery behavior |
| Boundary research | One reachable parser, authorization or update-trust hypothesis | Demonstrate a security consequence in a recoverable local setup |
| Specialist research | Versioned hardware/firmware findings with reproducible evidence | Match the program’s physical-access model and show affected production configuration |

Build confidence using intentionally vulnerable images or owned development hardware before using expensive production equipment. Buying a device is not itself evidence that its vendor rewards firmware findings or permits testing related infrastructure. Intel’s current program illustrates the distinction: it explicitly excludes open-chassis physical attacks from bounty rewards. [Intel program terms](https://app.intigriti.com/programs/intel/intel/detail)

## Scope and laboratory gate

Create a target card with vendor, exact product/SKU, board revision, SoC revision, bootloader, firmware version and image hash, region/carrier variant, enabled features, lifecycle state and acquisition source. Record whether the device is retail, engineering/debug, previously rooted or already modified. Compare results with an unmodified baseline; a debug unit cannot establish behavior on locked retail hardware.

Document the required access: remote internet, same network/proximity, physical access without opening, or access to internal components. Record digital privileges independently: unauthenticated, ordinary user, administrator or manufacturer. OWASP ISTG distinguishes physical and authorization access, including non-invasive and invasive access. These distinctions determine applicable tests and prevent overstating a bench-only result as a remote vulnerability. [ISTG attacker model](https://github.com/OWASP/owasp-istg/blob/main/src/02_framework/attacker_model.md)

Use a segregated lab network with synthetic accounts and no route to ordinary home/work devices. Observe expected destinations before selectively allowing connectivity. Keep a power and recovery plan, original firmware, configuration backup and known-good device state. A local firmware emulator still needs containment: embedded startup scripts can contact vendor services or alter the host environment if executed carelessly. Treat extraction tools and package parsers as attack surfaces too.

For UART/JTAG and other probes, establish pinout, voltage levels, ground reference and power ownership from reliable device documentation and measurement. Begin with passive observation. Do not make fuse changes, overwrite bootloaders, desolder components, glitch power or permanently unlock production hardware as a generic first step. Such operations require an explicitly suitable device, recovery capability and scope; their omission should be recorded as a test limitation.

## Operational playbook

**1. Acquire authentic inputs.** Prefer vendor downloads, authorized source releases, program-provided images or read-only acquisition from owned in-scope devices. Preserve the original bytes and hash before unpacking. Record how the image relates to the installed version; a downloaded update container may omit the bootloader, calibration data or secrets stored on the device. Do not assume an image found on an unrelated sharing service is authentic or covered.

**2. Inventory the image and startup paths.** Identify format, compression, partitions, architecture, endianness, executable ABI, filesystem and init mechanism. Bare-metal or RTOS images may not contain a Linux filesystem at all. Map network listeners, CGI/web handlers, configuration import/export, update agents, privileged helpers and inter-process messaging. Firmware methodology separates acquisition, unpacking, static review and dynamic validation; extraction alone is not an audit result. [OWASP FSTM](https://github.com/scriptingxss/owasp-fstm)

**3. Establish the normal trust model.** Trace provisioning to first ownership, adding a second user, local/cloud control, account removal, ownership transfer and reset. Mark which operations require physical presence and which are authenticated remotely. Build at least two owned test identities where the product supports them. A report about cross-owner access should demonstrate a boundary using those identities rather than a third party’s device.

**4. Follow external input into privileged behavior.** Prioritize reachable parsers: HTTP, binary control messages, configuration archives, media/file imports and update metadata. Map decoding, length checks, integer arithmetic and privilege changes. For native code, distinguish a controlled parser crash, memory corruption and demonstrated execution; they have different evidentiary strength. A missing stack canary or an outdated library version is a lead until reachability and applicable impact are shown.

**5. Validate with the least invasive faithful environment.** Extracted-process emulation can isolate a parser; full-system emulation can recover service interactions; the owned device confirms hardware-dependent behavior. Record divergences such as mocked peripherals, absent secure elements or different kernel versions. Use bounded inputs and synthetic data. Stop at a reproducible boundary violation rather than escalating to persistence, uncontrolled radio traffic or damage.

**6. Reproduce after reset and prepare disclosure.** Verify the issue survives a clean supported configuration, document exact preconditions, and capture evidence of the protected action or data access. Preserve recovery steps and device health. Report confirmed versions separately from suspected related products; matching strings or reused libraries do not prove a shared exploitable condition.

## Technical investigation checklist

| Area | Investigation | Evidence that advances a report |
|---|---|---|
| Firmware identity | Model, revision, update package, installed build, hashes | Exact affected product and reproducible baseline |
| Provisioning | Initial ownership, pairing, reset, reassignment and local presence | An unauthorized identity obtains a protected role or capability |
| Update trust | Signature verification, trusted keys, authenticated metadata, target compatibility | A harmless unauthorized artifact crosses the actual acceptance boundary |
| Rollback | Version counters, signed old images and recovery paths | An allowed attacker can restore a vulnerable security state |
| Boot chain | ROM-to-bootloader-to-application verification and recovery trust | A gap in the claimed chain under the eligible access model |
| Secrets | Per-device versus shared keys, credentials, debug logs and persistent storage | Protected capability established without publishing usable secrets |
| Debug interfaces | UART console, JTAG/SWD, test modes and privilege separation | Unexpected access on the production configuration |
| Local services | Authentication, authorization, command construction and configuration import | Reachable low-privilege input causes a protected operation |
| Memory safety | Length fields, parsers, allocation/free patterns and signedness | Minimized input, crash location, reachability and bounded consequence |
| Wireless | Pairing/bonding, identity, replay, sequencing and encrypted transport | Own-device controlled capture shows an authentication or integrity failure |
| Cloud/app coupling | Device claims, token scoping, ownership transfer and command routing | Reproduction only against separately authorized API/app assets |
| Recovery | Reboot, factory reset, watchdog and supported restore procedures | Device restored and test limitations documented |

Update transport encryption, update authentication and secure boot are separate checks. HTTPS can protect download transport while leaving a local update path insufficiently authenticated. A signed image may still be unsuitable for the model or permit a security downgrade. Examine what bytes and metadata are verified and what executes afterward. [ISTG firmware update mechanism](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/firmware_update_mechanism.md)

Vendor details matter. On ESP32, Secure Boot v2 support depends on chip revision, and Espressif documents interactions with JTAG and flash encryption. Its security guidance separately describes anti-rollback controls. Do not infer the presence or absence of a production control from a generic SoC feature list; inspect the target configuration and matching vendor documentation. [Espressif Secure Boot v2](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/secure-boot-v2.html), [Security overview](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/security.html)

Classify discovered secrets before testing them: public certificate, local password hash, per-device private key, shared fleet credential or build-time sample. Demonstrating a secret’s role on an owned lab device is stronger than indiscriminate credential trials against cloud endpoints. For storage, distinguish attacker-accessible contents from intended administrator/debug access; note encryption-key placement, deletion behavior and residual data after reset. [ISTG installed firmware](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/installed_firmware.md), [ISTG memory](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/memory/README.md)

Internal interfaces deserve their own boundary assessment. A UART that prints boot diagnostics differs from an unauthenticated privileged console; accessible JTAG differs from a demonstrated ability to extract protected secrets. Record physical effort and whether opening the case is required. Radio observations likewise differ from active tests: perform replay or malformed-message experiments only between owned devices in a controlled setup, and evaluate pairing and message authentication in the relevant protocol. [ISTG internal interfaces](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/internal_interfaces/README.md), [ISTG wireless interfaces](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/wireless_interfaces/README.md)

## Command cheat sheet

Use an offline copy of a vendor image in an isolated non-root analysis environment. These commands inspect local files; they do not acquire firmware from an unknown device or authorize testing any embedded endpoint.

```bash
mkdir -p evidence
sha256sum firmware.bin > evidence/firmware.sha256
file firmware.bin > evidence/firmware-type.txt
binwalk firmware.bin > evidence/firmware-layout.txt
strings -a -n 8 firmware.bin > evidence/firmware-strings.txt

# After an appropriate extractor has produced an owned local filesystem:
rg --files extracted-rootfs > evidence/file-inventory.txt
rg -n -i 'password|token|private.key|update|signature' \
  extracted-rootfs > evidence/review-leads.txt

# For an identified ELF binary, not for every firmware format:
readelf -hW extracted-rootfs/usr/sbin/example-daemon
readelf -lW extracted-rootfs/usr/sbin/example-daemon
```

Select the extractor for the detected format, verify its current syntax and inspect archive contents before extraction. Keep unknown images away from host mounts and privileged analysis processes. Binwalk identifies embedded content and can support extraction workflows; high entropy alone does not distinguish encryption from compression. The `rg` matches above are review leads, not confirmed credentials or findings. [Binwalk](https://github.com/ReFirmLabs/binwalk), [OWASP FSTM](https://github.com/scriptingxss/owasp-fstm)

**Evidence bundle:** product/revision photo with unnecessary identifiers redacted; firmware and extracted-file hashes; access model; wiring/interface notes where applicable; synthetic account roles; minimal input; serial or packet logs; observed versus expected behavior; reproducibility count; device recovery status; and exact affected versions. Include proof that emulation assumptions also hold on the claimed product, or clearly limit the claim to the emulated component.

## Specialist boundaries

Vehicles, industrial equipment, medical devices, energy systems and safety-related controls require a dedicated bench or simulator, disconnected actuators and a product-specific safety plan. Do not run generic active probes on deployed equipment or moving vehicles. Fault injection, invasive chip extraction, RF transmission and physical access are separate research capabilities with separate permissions and operational requirements. Tesla’s product-security page and each vendor’s actual program terms should be checked before planning vehicle work; device ownership alone does not settle every condition. [Tesla product security](https://www.tesla.com/legal/security)

**Submission gate:** eligible model and access level; supported configuration; a demonstrated security boundary; secrets minimized; no unrelated cloud assets tested; no physical damage required for the proof; clean reproduction; limitations explicit. Prefer one reproducible issue with measured impact over a long inventory of absent hardening flags.

## Sources

All sources accessed 2026-09-11. Undated pages are live references. OWASP citations point to the guide’s official maintained source files.

1. Intel / Intigriti. [Intel Bug Bounty Program](https://app.intigriti.com/programs/intel/intel/detail). Undated, current program terms.
2. OWASP. [ISTG: Attacker Model](https://github.com/OWASP/owasp-istg/blob/main/src/02_framework/attacker_model.md). Undated.
3. OWASP / Aaron Guzman. [Firmware Security Testing Methodology](https://github.com/scriptingxss/owasp-fstm). Undated, maintained repository.
4. OWASP. [ISTG: Firmware Update Mechanism](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/firmware_update_mechanism.md). Undated.
5. Espressif. [Secure Boot v2](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/secure-boot-v2.html). ESP-IDF stable, ESP32; undated.
6. Espressif. [Security Overview](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/security.html). ESP-IDF stable, ESP32; undated.
7. OWASP. [ISTG: Installed Firmware](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/installed_firmware.md). Undated.
8. OWASP. [ISTG: Memory](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/memory/README.md). Undated.
9. OWASP. [ISTG: Internal Interfaces](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/internal_interfaces/README.md). Undated.
10. OWASP. [ISTG: Wireless Interfaces](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/wireless_interfaces/README.md). Undated.
11. ReFirm Labs. [Binwalk](https://github.com/ReFirmLabs/binwalk). Undated, maintained repository.
12. Tesla. [Product Security](https://www.tesla.com/legal/security). Undated, current policy.


## Shared investigation procedures

- [Libraries and parsers: bounded fuzzing to a minimal reproducer](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/modules/parser-fuzzing.html) — Build a realistic local harness, instrument the target, bound fuzzing resources, and turn unique faults into defensible library or consumer reports.
- [Firmware update and boot trust: signed bytes, product binding and rollback](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/modules/firmware-update.html) — Separate download trust, update authorization, image verification, rollback policy and boot enforcement using local artifacts.
- [Hardware interfaces: production debug access and protected data](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/modules/hardware-interfaces.html) — Distinguish diagnostic output from privileged UART, JTAG/SWD and firmware-secret boundary failures on an owned lab unit.

## Vulnerability reference

- [Out-of-bounds memory read](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities/out-of-bounds-read.html)
- [Out-of-bounds memory write](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities/out-of-bounds-write.html)
- [Use after free in a public API or parser lifecycle](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities/use-after-free.html)
- [Integer overflow affecting allocation or bounds](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities/integer-overflow.html)
- [Predictable temporary files and unsafe creation](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities/insecure-temporary-files.html)
- [Untrusted executable, library, or module search path](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities/untrusted-search-path.html)
- [Updater accepts an artifact outside its publisher trust policy](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities/update-untrusted-artifact.html)
- [Firmware verifier accepts unauthenticated protected bytes](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities/firmware-signature-validation.html)
- [Firmware security-version state can be lowered](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities/firmware-security-version-rollback.html)
- [Firmware verification fails to enforce required product binding](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities/firmware-product-binding.html)
- [Boot or recovery path executes an unverified component](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities/firmware-boot-chain-gap.html)
- [Production UART exposes an unauthenticated privileged console](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities/hardware-unauthenticated-console.html)
- [On-chip debug interface exposes protected memory or control](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities/hardware-debug-authorization.html)
- [Firmware contains a reusable shared authentication credential](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities/firmware-shared-credentials.html)
- [Encrypted data accepted without integrity authentication](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities/crypto-authentication-missing.html)