Security testing
Hands-on tests. Proof you can reproduce.
All security testingHow we workWhat happens after the first call.See the processBuild
We break software for a living. This is what we build.
All build servicesProof of workOur own apps, built the same way.See themWe take the firmware apart, test the hardware interfaces and network services, and check how updates are built, signed and delivered, following the OWASP FSTM.
One open debug port or one unsigned update can hand over the whole device.
Out of scope stays out. We ask first.
File system contents, hardcoded secrets, outdated components and debug leftovers.
Signing, verification, rollback protection and delivery.
UART, JTAG, SWD and any debug port left open.
Web interfaces, local APIs and the cloud connections the device holds open.
Secure boot, bootloader settings and storage encryption.
The mobile app and back end that control the device.
Datasheets, public regulatory filings and the parts on the board.
From the vendor, the update server, or straight off the flash chip.
Binwalk to extract, Ghidra to read binaries, then the file system for secrets and stale components.
Services in emulation where we can, on the real device where we can’t.
Debug ports, and how updates are signed and verified.
Device, app and cloud findings in one report, then a free retest.
How a finding reads
Muneeb went through Arm’s Trusted Firmware, the secure-world code under the operating system. Arm accepted and rewarded what he found. Your firmware gets the same reading.
| Findings mapped to |
|
|---|---|
| Tools we use |
|
Two if you can. One stays working, and one we may open, probe or reflash. Hardware testing can damage a unit.
No. A firmware image or a device is enough. Source, schematics and build notes speed things up.
If they’re in scope, yes. A lot of device weaknesses live there.
The findings are yours. If one sits in a supplier’s component, we agree with you how and when it goes to that supplier.
Send the scope and your deadline, and we’ll set up a call.
