We break the device before someone else does.

What we test

Four practice areas, taken on individually or as a full assessment across the whole product.

• Black Box Hardware Penetration Testing

  Physical attacks on the board and the silicon, with no source and no documentation, starting from the same production unit an attacker would buy.

  • Physical bypasses on microcontrollers. Voltage and clock glitching, electromagnetic fault injection, and side-channel analysis to skip security checks or recover keys from power traces.
  • Debug port exposure. JTAG, SWD, and UART interfaces left unlocked on production boards, along with test pads, factory menus, and bootloader commands that never got disabled.
  • Insecure storage. Unencrypted secrets, credentials, and proprietary algorithms written straight to external flash, eMMC, or EEPROM, where a chip reader is enough to extract them.
  • Lack of hardware isolation. Safety-critical systems sharing an MCU, a bus, or a power domain with connected infotainment and internet-facing components, with no MPU partitioning or gateway filtering between them.
  • Secure boot architecture. Verifying, and where needed designing, the cryptographic pipeline that ensures a device only executes authenticated, unaltered code, including the root of trust and anti-rollback protection.
  • Interface enumeration. Mapping every exposed surface on the board: SPI, I2C, CAN, USB, and radio, then testing what each one accepts before authentication.

• Black Box Firmware Reverse Engineering

  Deconstructing the compiled binary itself, whether pulled off the flash chip, captured from an update, or downloaded from your support page.

  • Architecture mapping. Reconstructing memory layout, task structure, peripheral use, and trust boundaries from a stripped binary to find flaws the design documents never mention.
  • Exposed data and keys. Hunting for credentials, API tokens, private keys, and certificates left in the decompiled binary, including the ones hidden behind trivial obfuscation.
  • Hidden functionality. Undocumented commands, engineering backdoors, and debug paths that survived into the shipping build.
  • Update and OTA analysis. Firmware image encryption, signature verification, and downgrade handling, tested by building the malicious update ourselves.
  • Protocol reverse engineering. Proprietary wire and radio protocols, checked for authentication, replay resistance, and parser robustness.
  • Binary hardening review. Stack protection, memory permissions, and MPU configuration as they actually ended up in the shipped image, not as configured in the project file.

• Source Vulnerability Assessment

  White box review with the source in hand, where we can reach the bugs that black box testing only hints at.

  • Code analysis. Scanning and reviewing firmware code for buffer overflows, hardcoded credentials, memory leaks, integer overflows, unchecked input parsing, and concurrency bugs in RTOS tasks and interrupt handlers.
  • Secure boot architecture. Designing cryptographic verification pipelines so devices only execute authenticated, unaltered code, from the immutable boot ROM through every stage that follows.
  • Cryptographic implementation. Embedding secure storage for API keys, digital certificates, and encryption keys within hardware roots of trust: secure elements, TrustZone, OTP fuses, and on-chip key stores.
  • Provisioning and lifecycle. How keys get onto the device in the factory, how they are rotated, and what happens to them on decommissioning or resale.

• Supply Chain Vulnerability Assessment

  Evaluation of supply chain risk across everything your firmware pulls in that you did not write.

  • Dependency compromise risk. Per-dependency evaluation of how exposed you are to a supply chain attack: who can publish, how releases are signed, and what that code reaches once it is on the device.
  • Orphan dependency risk. Evaluation of the likelihood a dependency becomes unmaintained, measured on maintainer count, release cadence, and open security backlog, so you learn about it before the product is in the field.
  • Inventory and exposure. A concrete SBOM for the shipped image, mapped against known CVEs and against the parts of the codebase that actually execute.
  • Vendor code and blobs. Third-party SDKs, BSPs, and binary-only drivers, reviewed for what they add to your attack surface and what they send off the device.
  • Toolchain and build integrity. Compilers, CI pipelines, signing key handling, and build reproducibility, because a clean source tree does not guarantee a clean binary.

How we work

Experienced human testing, amplified by frontier and open-weight AI models, with the sensitive work kept in house.