Hardware & Kernel Security
Low-level vulnerabilities can bypass OS security. We test hardware interfaces and kernel drivers.
Who this is for
Product, firmware and operations teams shipping physical or connected systems, where a security problem has consequences you cannot patch remotely.
Methodology
What We Test
- Secure Boot chain of trust and TEE (Trusted Execution Environment)
- Kernel drivers, modules, and privilege levels
- Memory protections (ASLR, DEP/NX, SMEP/SMAP)
- Side-channel leakage (Power analysis, Timing attacks)
- Hardware debug ports and fuse configurations
- DMA (Direct Memory Access) attacks
How We Test
We use fault injection (glitching) to bypass security checks. We fuzz kernel drivers to find corruption primitives. We develop custom shellcode to demonstrate ring-0 execution. We analyze power traces to extract cryptographic keys.
What You Receive
- Proof-of-Concept (PoC) exploits for local escalation
- Driver hardening patches and recommendations
- Hardware design changes to mitigate side-channels
- Secure boot configuration fixes
How an engagement runs
-
Scope, authorisation & safety constraints
We agree the target hardware or environment, the tests permitted on it, and the safety and operational limits before anything is powered on. Nothing starts without written authorisation from someone able to give it.
-
Samples, access & environment
We confirm what you supply — devices or samples, firmware and hardware revisions, bench or lab access, interfaces and credentials — and agree in writing whether work may be invasive or destructive, and how samples are returned or disposed of.
-
Passive analysis first
We start with observation, documentation review and passive analysis so we understand the system before touching anything that could affect it. On operational technology this stage carries the most weight.
-
Controlled active testing
Active testing happens on a bench, a replica or an agreed non-operational window — never against live production or safety-critical operations without explicit written approval and your engineers present.
-
Report & walkthrough
You get an executive summary and technical detail covering what we proved, what held, what could not be tested safely, and why. We walk your team through it.
-
Retest
Fixes are retested against the same samples or environment where that is practical. Retest scope is agreed in your scope document before the engagement begins.
Toolkit
- ChipWhisperer
- Oscilloscope
- Logic Analyzer
- Syzkaller