Skip to content
ISO 27001, SOC 2, the DPDP Act and manual VAPT.
Part of VAPT7 services in this practice area

Firmware, Hardware, Radio

IoT and Embedded Penetration Testing

Connected devices hide their weaknesses in firmware, on the board and in the traffic they broadcast. We go after all three, from extracting the firmware to probing the debug ports the manufacturer forgot to lock.

See the engagement path, 6 phasesSee the full VAPT service index

Overview

An IoT and embedded VAPT looks at everything around the device: the hardware, the firmware, the radio and the cloud and mobile apps it talks to. We extract and analyse firmware, probe hardware interfaces like UART and JTAG, and inspect the communication between the device and its backend. The goal is to show what an attacker with the device on a bench, or within radio range, can actually do to it and to the fleet behind it.

Methodology

How the Engagement Runs

Every phase has a named output, so you always know what is being worked on and what lands on your side of the table.

The Engagement, End to End

6 Phases, 6 Named Handovers

Flow

Flow chart of the IoT and Embedded engagement, 6 phases in order, each one selectable. Phase 1, Scoping and Rules of Engagement. We agree the device models, firmware versions, and companion apps and cloud services in scope, and confirm which units we can open. Activities: Confirm device models and firmware versions; Agree companion apps and cloud services in scope; Confirm which units we can open and modify; Set handling rules and testing windows. Hands over Signed Rules of Engagement. Phase 2, Reconnaissance and Hardware Analysis. We inspect the board, identify chips and debug interfaces, and connect to UART and JTAG to reach the console and memory. Activities: Inspect the board and identify chips; Locate debug interfaces and test points; Connect to UART and JTAG; Reach the console and read memory. Hands over Hardware Analysis Notes. Phase 3, Firmware Extraction and Analysis. We pull the firmware from flash or downloads, unpack it and search for hardcoded secrets, weak crypto and vulnerable services. Activities: Extract firmware from flash or downloads; Unpack and analyse the file system; Hunt for hardcoded secrets and weak crypto; Identify vulnerable services and binaries. Hands over Firmware Analysis Findings. Phase 4, Manual Exploitation. We exploit findings on the device, from insecure boot and update mechanisms to services reachable over the network or radio. Activities: Attack insecure boot and update mechanisms; Exploit services reachable over network or radio; Bypass authentication on the device; Confirm impact and rule out false positives. Hands over Proven Device Findings. Phase 5, Communication and Cloud Impact. We test the device-to-cloud and companion-app traffic and show how one compromised device can affect the wider fleet. Activities: Intercept device-to-cloud traffic; Test the companion app and its backend; Show how one device affects the fleet; Assess combined business impact. Hands over Impact and Fleet Risk Assessment. Phase 6, Reporting and Verified Retest. You get a report with proof of concept across hardware and firmware and clear fixes, and we retest once you remediate. Activities: Document findings across hardware and firmware; Produce an executive summary; Walk your team through the results; Retest fixes and confirm closure. Hands over Final Report and Verified Retest. Each phase begins from the artefact the phase before it produced.

Phase 01 Scoping and Rules of Engagement

We agree the device models, firmware versions, and companion apps and cloud services in scope, and confirm which units we can open.

What Happens In This Phase

  • Confirm device models and firmware versions
  • Agree companion apps and cloud services in scope
  • Confirm which units we can open and modify
  • Set handling rules and testing windows

The Handover

Signed Rules of Engagement

The next phase starts from this.

Read the handover cards on their own and you have the paper trail. Select a phase to see what happens inside it.
  1. 01

    Scoping and Rules of Engagement

    We agree the device models, firmware versions, and companion apps and cloud services in scope, and confirm which units we can open.

    OutputSigned Rules of Engagement

    Activities

    • Confirm device models and firmware versions
    • Agree companion apps and cloud services in scope
    • Confirm which units we can open and modify
    • Set handling rules and testing windows
  2. 02

    Reconnaissance and Hardware Analysis

    We inspect the board, identify chips and debug interfaces, and connect to UART and JTAG to reach the console and memory.

    OutputHardware Analysis Notes

    Activities

    • Inspect the board and identify chips
    • Locate debug interfaces and test points
    • Connect to UART and JTAG
    • Reach the console and read memory
  3. 03

    Firmware Extraction and Analysis

    We pull the firmware from flash or downloads, unpack it and search for hardcoded secrets, weak crypto and vulnerable services.

    OutputFirmware Analysis Findings

    Activities

    • Extract firmware from flash or downloads
    • Unpack and analyse the file system
    • Hunt for hardcoded secrets and weak crypto
    • Identify vulnerable services and binaries
  4. 04

    Manual Exploitation

    We exploit findings on the device, from insecure boot and update mechanisms to services reachable over the network or radio.

    OutputProven Device Findings

    Activities

    • Attack insecure boot and update mechanisms
    • Exploit services reachable over network or radio
    • Bypass authentication on the device
    • Confirm impact and rule out false positives
  5. 05

    Communication and Cloud Impact

    We test the device-to-cloud and companion-app traffic and show how one compromised device can affect the wider fleet.

    OutputImpact and Fleet Risk Assessment

    Activities

    • Intercept device-to-cloud traffic
    • Test the companion app and its backend
    • Show how one device affects the fleet
    • Assess combined business impact
  6. 06

    Reporting and Verified Retest

    You get a report with proof of concept across hardware and firmware and clear fixes, and we retest once you remediate.

    OutputFinal Report and Verified Retest

    Activities

    • Document findings across hardware and firmware
    • Produce an executive summary
    • Walk your team through the results
    • Retest fixes and confirm closure

Specification

What We Run, and What We Measure You Against

The tooling our engineers use on this work, and the published standards the findings and evidence are mapped to.

Scope

What Is Examined, and What it Is Measured Against

Map

Map of the IoT and Embedded scope, running left to right in three stages. Stage one, what we run, 8 tools and techniques: Ghidra, binwalk, JTAGulator, Firmadyne, Saleae logic analyzer, Wireshark, Bus Pirate, flashrom. Stage two, findings from all of it are proven by hand and written up once. Stage three, measured against 5 published standards: OWASP IoT Top 10, OWASP Firmware Security Testing Methodology (FSTM), PTES, NIST SP 800-115, CVSS v4.0.

What We Run

8 tools

  • Ghidra
  • binwalk
  • JTAGulator
  • Firmadyne
  • Saleae logic analyzer
  • Wireshark
  • Bus Pirate
  • flashrom

Converges On

One Set of Proven Findings

Every issue is reproduced by hand before it is written down, and it is written down once.

Measured Against

5 standards

  • OWASPIoT Top 10
  • OWASPFSTM
  • PTES
  • NIST SP 800-115
  • CVSS v4.0
One pass of testing and analysis, one set of findings, then that single set is graded against every standard on the right. You are not paying for the same work once per framework.

Deliverables

What You Receive

  • Findings report with proof of concept
  • Firmware and hardware analysis notes
  • Executive summary
  • Remediation guidance
  • Verified retest report

Scope This Engagement

Tell us about your environment, your timelines and any audit dates you are working to. We come back with scope, effort and a start date.

Questions

What Clients Ask Us

Something here not covered? Ask Us Directly.

Do we need to send you physical devices?

For hardware and firmware work, yes. We need units we can open, connect to and, if needed, modify. We agree how many and handle them under the rules we set together in scoping.

Do you test the cloud and mobile side of the product?

We test the device's communication with them and can extend into the cloud and companion apps as separate surfaces. Most device compromises only matter once you see the fleet impact behind them.

What if the firmware is encrypted or the ports are locked?

That is part of the test. We attempt extraction through flash reads, update files and debug interfaces, and we report honestly on what protections held and what we got past.

Keep Moving Through VAPT

Service 6 of 7 in this practice area