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.
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.
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.
- 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 EngagementActivities
- 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
- 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 NotesActivities
- Inspect the board and identify chips
- Locate debug interfaces and test points
- Connect to UART and JTAG
- Reach the console and read memory
- 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 FindingsActivities
- Extract firmware from flash or downloads
- Unpack and analyse the file system
- Hunt for hardcoded secrets and weak crypto
- Identify vulnerable services and binaries
- 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 FindingsActivities
- 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
- 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 AssessmentActivities
- Intercept device-to-cloud traffic
- Test the companion app and its backend
- Show how one device affects the fleet
- Assess combined business impact
- 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 RetestActivities
- 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.
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
- binwalk
- JTAGulator
- Firmadyne
- Saleae logic analyzer
- 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
- OWASP
- OWASP
- PTES
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.
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
Practice Area
More in VAPT
- Web ApplicationManual testing of your web apps against the OWASP WSTG
- Mobile ApplicationAndroid and iOS app testing against the OWASP MASVS
- APIREST, GraphQL and SOAP testing against the OWASP API Top 10
- Thick Client ApplicationDesktop app testing across binary, traffic and backend
- Network InfrastructureExternal and internal network testing with lateral movement
- CloudConfiguration and IAM testing across AWS, Azure and GCP