Hardware & firmware security

Find the failure
before it ships.

Threat modeling, hands-on testing, and mitigation engineering for connected devices, payment hardware, and embedded products.

For engineering and security teams that need to know what holds up when an attacker has the device.

Secure boot · Firmware · Physical attack testing · Mitigation engineering

15 yearsPayment hardware, firmware, secure boot, and low-level security research.

Start with the device

What needs to hold up?

Tell me what you’re building and the security question your team needs answered.

A few sentences is enough. Don’t include credentials, personal customer data, or confidential code.

Your details are used to reply to this inquiry, not to add you to a mailing list. Privacy notice.

Prefer a private chat? Talk on Signal

A scope your team can act on

Attack path.
Mitigation. Retest.

Start with a design review, a focused lab assessment, or implementation support. We agree on authorization, test depth, deliverables, and hardware-handling risks before work begins.

01 / TRUST BOUNDARIES

Map what must hold.

Device access, secrets, boot integrity, updates, and the business consequences of a failure.

02 / FIRMWARE

Follow the boot chain.

Review firmware, secure boot, and update paths for weaknesses in the protections your design relies on.

03 / THE BENCH

Test physical access.

Scoped hands-on testing, including fault injection where appropriate, with reproducible observations and explicit limits.

04 / ENGINEERING

Fix and validate.

Prioritized mitigations, implementation support, and retesting against the agreed attack path.

Relevant hands-on experience

Boot code.
Silicon. Physical access.

Experience spans payment hardware at Square, low-level security at Root Labs, and hardware-wallet fault injection.

Firmware research includes independently finding and fully exploiting a pre-auth U-Boot NFS client overflow. The finding collided with a private report filed one month earlier; patches and the public exploit chain are upstream.

Tests answer specific questions under agreed conditions. They are not a blanket certification that a device is secure.

Direct access to the engineer

One person.
End-to-end delivery.

ByteBack is run by Manizzle, with fifteen years across mobile security, payment hardware, firmware, attestation, and vulnerability research.

The person defining the threat model also works through the implementation and test evidence. You get a clear handoff: what failed, what to fix, and what to test next.

Need mobile integrity instead? Explore Device Trust →

Before we talk.

Can you help before the hardware is finished?

Yes. A threat-model or architecture review can identify trust boundaries and implementation risks before a lab assessment is possible.

Do you implement mitigations, or only report findings?

Both are possible. Implementation support and retesting can be included in the agreed scope, alongside assessment work.

Could testing damage the device?

Some physical tests can damage or destroy hardware. We agree on permitted techniques, samples, custody, and stop conditions before any bench work.

Is this the hardware-wallet recovery service?

No. This page is for product teams assessing or improving their own systems. If you have lost access to a wallet you lawfully own, use the Wallet Recovery page.

What happens after I submit?

ByteBack reviews the inquiry and replies to the email you provide. If the project is a fit, we discuss authorization, scope, and a written proposal. There is no obligation to book.

Bring the device. Start with the question.

Discuss a device