IoT / Consumer
Smart locks, cameras, hubs, speakers — proximity + onboarding are critical.
Surfaces we focus
Boot & Update ChainRadio & ProximityLocal Services & APIsCloud, Mobile & Identity +2 more
Device Testing
Holistic testing, driven by threat modeling
Device security presents unique challenges like limited processing power, complex technology stacks, and attacks against physical interfaces. Our team has years of experience and has developed a holistic testing methodology informed by accurate threat modeling.
Offensive Security
Turn device risk into prioritized, fixable work.
- Threat Modeling
- Firmware Analysis
- Reverse Engineering
How we run device tests
A practical flow that starts with threat modeling and ends with verified fixes.
01
Information gathering & threat modeling
Decompose the device stack, enumerate attack surfaces, and frame attacker incentives. We build a live surface map to focus effort where impact is highest.
You get
- Surface map (power / debug / storage / radio / network / cloud)
- Threat model with prioritized abuse paths
- Assumptions & trust-boundary log
02
Artifact analysis
Firmware extraction, static/dynamic triage, protocol/file-format targets, and emulation prep. We light up code paths and capture traces.
You get
- Partition & symbol maps; candidate parsers
- Trace/capture sets and initial harnesses
- Shortlist of attack ideas per surface
03
Vulnerability exploitation
Turn ideas into proof. We craft PoCs for update chain, radios, local services, and privilege boundaries to demonstrate real-world impact.
You get
- Exploit PoCs with notes (video/logs)
- Crash triage & minimized corpora
- Risk-ranked finding list (impact × difficulty)
04
Collect & report
Concise reporting with actionable fixes. We keep it operational and device-focused, ready for engineering sprints.
You get
- Redacted finding write-ups with reproduction steps
- Mitigation guidance mapped to affected surfaces
- Verification checklist to re-run post-fix
05
Fix verification (Optional)
We re-run relevant PoCs/harnesses to confirm mitigations and close the loop, so the same class of bug does not return.
You get
- Re-run notes (pass/fail) on patched firmware
- Updated corpora/harnesses for regression safety
- Green-gate signal for CI or bench script
A closer look at
threat modeling
Every engagement begins with an architectural deconstruction. We map the device's ecosystem, starting at the physical and wireless edges to identify every potential entry point. From there, we trace the internal data flows and trust boundaries between critical components like the OS, secure elements, and application logic.
This foundational model, illustrated here with an Android PoS terminal, is the output of the first stage of our testing process. It serves as a strategic map, allowing us to focus our analysis and exploitation efforts on the most critical and likely points of failure to find impactful vulnerabilities faster.
External Surface Area
WI-FI
Bluetooth
NFC
USB
Internal Surface Area
PoS Application
RAM Scraping / Malware Target
Android OS
Root / Privilege Escalation
Secure Element / TEE
Key Extraction
Peripherals & Backend
Card Reader
Payment Gateway
Cloud Backend
Devices we test
From consumer IoT to mobility and industrial — if it ships firmware and talks to the world, we can test it.
Routers & Gateways
WAN/LAN boundaries, updaters, and service exposure decide safety at home & edge.
Surfaces we focus
Boot & Update ChainLocal Services & APIsStorage & SecretsDebug & Test Interfaces +1 more
Smartphones & Tablets
Update chain, key material, local services and app/device trust.
Surfaces we focus
Boot & Update ChainStorage & SecretsRadio & ProximityLocal Services & APIs +1 more
Wearables & Health
BLE, OTA safety, and sensor trust with tight power constraints.
Surfaces we focus
Boot & Update ChainRadio & ProximitySensors & ActuatorsStorage & Secrets +1 more
Automotive / Mobility
Update chain, sensors/actuators, and device↔cloud policy under safety constraints.
Surfaces we focus
Boot & Update ChainSensors & ActuatorsLocal Services & APIsDebug & Test Interfaces +1 more
Industrial / Medical
Safety interlocks, identity, OTA and secrets under regulated environments.
Surfaces we focus
Sensors & ActuatorsBoot & Update ChainStorage & SecretsLocal Services & APIs +1 more
Engagement options
Pick the access level that fits your stage. We can also mix modes per surface when that’s the fastest path to impact.
Black-box
Realism over context. We handle the device like an unknown adversary would.
When to pick
- Launch readiness
- Third-party assurance
- Label/market claims
What we do
- Full-stack recon without hints
- Exercise radios & onboarding
- Hunt for high-impact abuse paths
Grey-box
Pragmatic access. Limited artifacts accelerate depth while preserving attacker perspective.
When to pick
- Tight timelines
- Complex stacks
- NDA allows limited share
What we do
- Probe guided by firmware/build notes
- Focus high-risk paths first
- Root-cause & quick-win mitigations
White-box
Depth with access. Internals (firmware/docs/debug) enable the most thorough coverage.
When to pick
- Complex OTA / boot chains
- CI/regression setup
- Broad hardening mandate
What we do
- Firmware/code triage & harnesses
- Minimized corpora for regressions
- Harden update/identity flows
Informed by research
Some ideas generated while testing one device prove interesting when looking towards a larger group of devices. Our ability to apply technical findings at scale has led to us writing state-of-the-art tooling and creating cutting-edge research, such as BadUSB and our Android patch analysis tool.
Teardown Atlas
For a granular look at our methodology, explore the interactive atlas below. Filter by device type to see which attack surfaces we prioritize for different products.
Boot & Update Chain
Secure bootOTA signingRollback protectionFirmware integrity
Why this surface matters
Compromise here survives reboots and scales fleet-wide. We verify trust from immutable boot ROM through loader and kernel, then stress the update mechanism that changes the device in the field.
How we test
- Map boot trust chain & fuses, then exercise recovery and safe-mode transitions.
- Parse and fuzz update manifests (A/B, delta) to probe downgrade and signature checks.
- Induce failure states to observe fail-open vs fail-closed behaviors.
Common pitfalls we look for
- Unsigned or weakly signed updates allow arbitrary firmware replacement.
- Recovery consoles with permissive commands bypass secure-boot enforcement.
- Manifest parsing errors (length/CRC/schema) flip validation into acceptance.
Signals we capture
Boot/fuse mapManifest corpus & harnessDowngrade/unsigned PoC
Debug & Test Interfaces
JTAGSWDUART consoleBoundary scan
Why this surface matters
Factory conveniences often ship to production. If debug survives, attackers get privileged shells and flash access.
How we test
- Probe JTAG/SWD lifecycle (RDP/CSR/PMP) and bootloader command surfaces.
- Instrument UART to enumerate hidden menus, boot args, and env controls.
- Locate undocumented pads/headers; evaluate boundary-scan exposure.
Common pitfalls we look for
- Production units with debug unlocked or lock bits misconfigured.
- Password gates with sniffable or reversible challenge–response.
- Bootloader commands permitting flash write or root shell without auth.
Signals we capture
Unlock sequence notesUART transcriptsMinimal debug→root escalation
Storage & Secrets
eMMCNANDkey storageSecrets at rest
Why this surface matters
Secrets in the wrong place leak control: API keys, tokens, device identities. We validate how keys are created, stored, rotated, and consumed.
How we test
- Extract partition maps; analyze file permissions and binary config for embedded tokens.
- Assess key derivation and sealing; verify use of secure elements/TPM where present.
- Model access from realistic attackers (lost/stolen device, supply-chain handler).
Common pitfalls we look for
- Hardcoded credentials and plaintext tokens inside binaries or env files.
- World-readable private material; weak KDFs enabling offline recovery.
- Secure element present but unused or fed with exportable keys.
Signals we capture
Partition diff & indexSecret exposure matrixKey-handling recommendations
Radio & Proximity
BLE pairingWi-Fi onboardingNFCReplay
Why this surface matters
Short-range interfaces are often treated as “safe enough.” We test pairing, onboarding, and replay to prevent drive-by abuse.
How we test
- Capture and analyze BLE pairing flows; attempt Just-Works downgrade.
- Exercise Wi-Fi onboarding and captive portals for unauthenticated actions.
- Record and replay provisioning tokens over BLE/NFC to test reuse windows.
Common pitfalls we look for
- Pairing downgrades enabling unauthorized control or data access.
- Onboarding endpoints write credentials or policy with no authz.
- Provisioning tokens reusable beyond intended lifetime or scope.
Signals we capture
RF capture setReplay scriptsPairing bypass notes
Local Services & APIs
Device APIsIPC boundariesTLS pinningAuthorization
Why this surface matters
Hidden endpoints and weak authorization turn convenience into compromise. We treat the device like a local attacker would.
How we test
- Enumerate HTTP/gRPC/custom services; model privilege transitions across IPC.
- Probe authn/authz, token lifetimes, CSRF/SSRFlike flows and device role changes.
- Inspect TLS use, pinning, and cert update/rollback behavior.
Common pitfalls we look for
- Privileged actions reachable via undocumented endpoints.
- Token reuse or elevation via poorly scoped claims.
- TLS disabled or pinning trivially bypassed via update rollback.
Signals we capture
Endpoint inventoryProtocol harnessPinning/store notes
Sensors & Actuators
Sensor spoofingTrust boundariesSafety
Why this surface matters
If the device trusts spoofed inputs, attackers steer actuators. We validate bounds, plausibility checks, and fail-safe behavior.
How we test
- Model sensor trust; induce edge values and drift to test plausibility logic.
- Exercise actuator commands and interlocks under fault states.
- Observe control loops under timing jitter and partial failure.
Common pitfalls we look for
- Blind trust in raw sensor values with no rate/consistency checks.
- Actuators accept commands without policy or rate limiting.
- No safe state when sensor stream degrades or stops.
Signals we capture
Spoof scenariosInterlock validation notesFault response traces
Cloud, Mobile & Identity
Device identityPolicyOTA backendApp linkage
Why this surface matters
The cloud side decides who controls devices. We test registration, identity strength, and cross-channel trust with the companion app.
How we test
- Review device registration, per-device credentials, and rotation processes.
- Abuse cloud APIs for role escalation and fleet-wide changes.
- Test app→device trust (QR/provisioning) for replay and binding issues.
Common pitfalls we look for
- Shared IDs or predictable credentials across the fleet.
- Policy updates that over-grant privileges to arbitrary devices.
- Companion app trusts screenshots/QRs without anti-replay.
Signals we capture
Identity/rotation planCloud→device abuse demo notesApp-link hardening checklist