Hardware, embedded and firmware

A physical device upends the assumptions software security relies on: that the attacker is remote and cannot touch memory. When they can hold the device in hand, they open it, read the flash chip directly, sniff the internal buses and, with fault-injection techniques, force it to skip signature verification or expose protected memory. Hardware testing means applying exactly these pressures, in a lab, to find out which protections held and which gave way — before someone else does it with a device bought off the shelf.

How we work

We structure the assessment around the OWASP FSTM (Firmware Security Testing Methodology) and the OWASP IoT guide (ISTG):

• Firmware — extraction via download, OTA capture or direct chip read (SPI flash with a programmer and SOIC clip, NAND/eMMC), then analysis: file systems (SquashFS, JFFS2, UBIFS), hardcoded keys and certificates, hidden accounts, legacy components with known CVEs
• Debug interfaces — UART (often a console or even a root shell left active), JTAG/SWD (memory and CPU access), discovered and exercised with dedicated tools
• Bus sniffing — SPI, I2C, UART, with logic analysers, to intercept secrets in transit between chips
• Fault injection and side-channel — voltage and clock glitching, plus power analysis (SPA/DPA), to bypass authentication checks or extract keys
• Secure boot — we verify whether the signature is actually enforced, rollback protection and how keys are stored; we test acceptance of unsigned or downgraded firmware

What you get

• Firmware findings (secrets, vulnerable components, missing signature), with the extraction method documented
• Hardware attack results: which debug ports were open, what glitching achieved, whether secure boot held
• Mapping to ETSI EN 303 645 (the baseline for consumer IoT) and IEC 62443 (industrial), with prioritised hardening: disabling debug in production, signing and encrypting firmware, protecting key storage, enabling readout protection