Hardware Penetration Testing

We open the device, identify every chip from its markings and datasheets, and map the board: the main processor, the flash and EEPROM, any secure element or TPM, and the debug and test pads the manufacturer left behind. A logic analyser and an oscilloscope tell us what the buses are doing at power-on, which usually points straight at the interesting targets.

We probe JTAG, SWD and UART to see whether debug access was disabled in production or merely hidden. Where the flash is reachable, we dump it over SPI or I2C, or lift the chip and read it directly, then pull the firmware and any secrets out of the image. Plenty of devices we test hand over their entire firmware and hardcoded keys through a header the vendor forgot to lock.

We test whether secure boot genuinely enforces signatures, whether an older vulnerable firmware can be rolled back, and whether a modified image runs. Where the device relies on a check to protect its secrets, we attempt voltage and clock glitching to skip that check at the exact moment it runs, a technique that has broken many devices whose software looked airtight.

If cryptography is a target, we look for power and timing side channels that leak key material. We sniff and probe any BLE or proprietary RF interface for pairing and command weaknesses. Then you get a written report within days, with photos, captured traffic and the exact bench setup for every finding, plus a live walkthrough and a free retest after you respin.

JTAG, SWD or a UART console left enabled in shipped product gives an attacker a direct route to memory, firmware and often a root shell. Disabling or authenticating these in production is one of the highest-value fixes we recommend, and one of the most commonly missed.

Unencrypted external flash is an open book. We routinely recover full firmware, API keys, Wi-Fi credentials, private certificates and update-signing keys straight from an SPI chip. When one device’s key opens the whole fleet, a five-euro flash dump becomes a product-wide compromise.

A boot chain that does not verify signatures, or verifies them but allows rollback to a vulnerable version, lets an attacker run their own firmware. We test the full chain from ROM to application and prove whether a modified image survives a reboot.

Many security decisions come down to a single comparison in code. A well-timed glitch can make the processor skip it, turning a locked device into an open one. Devices without glitch detection or redundant checks are especially exposed, and this is a class of attack that pure software review never surfaces.

Sensitive data crossing an SPI or I2C bus in the clear can be sniffed with cheap equipment. BLE and proprietary radios frequently use weak pairing, static keys or unauthenticated commands, letting an attacker within range control or impersonate the device.

When firmware and provisioning secrets are recoverable, a competitor can clone your product or a counterfeiter can flood your channel with copies that carry your name and your liability. We assess how hard it would be to duplicate the device from an extracted image, and whether per-unit keying, secure provisioning and an unclonable identity would actually hold up against someone motivated to copy you.

Enclosures that pop open without a trace, test points that stay live in production, and boards with no tamper response make every other attack easier. We check whether opening or probing the device leaves evidence, and whether critical components are shielded or potted, because physical hardening is often the cheapest control to add before the next production run.

ETSI EN 303 645 sets the baseline for consumer connected products, covering no default passwords, secure storage of sensitive parameters, and protection of software integrity. The EU Radio Equipment Directive (RED) delegated act and the incoming Cyber Resilience Act make much of this mandatory for products sold in Europe. Our testing and report map directly to these controls.

For industrial and control-system hardware, IEC 62443 (particularly 4-1 and 4-2) defines security requirements for components and their development. We assess against the relevant component requirements and provide evidence suitable for a certification effort or a customer security review.

Where the device performs cryptography we reference established key-management and side-channel expectations, and for any companion firmware or app we bring in the relevant OWASP guidance. The report gives your hardware and firmware teams a shared, standards-based reference for each fix.