Case Study — Product Security & Ethical Hacking

One product. Every attack surface. Tested end to end.

Acme Corporation makes connected battery chargers and jump starters — from pocket units to fleet depot chargers, with a mobile app, a cloud back-office, and the firmware that moves real current into a battery. They asked Xari to attack the whole system the way a real adversary would: the radio link, the firmware, the cryptographic protocol, the apps, and the API. Authorized, ethical hacking — black-box first, then a consensual deep dive.

Get in touch See the surfaces ↓

Representative engagement. The client and product names are fictionalized to protect confidentiality; the methodology, tooling and coverage are exactly what Xari runs. Findings are never published — this page describes what we test, not any client's results.

attack surfaces, one platform

phases — black-box → gray-box

50+

mapped test cases

standards & bodies of knowledge

The Approach

Ethical hacking, in two consensual phases.

A retail attack tells you what anyone can do. A deep dive tells you what a determined insider can do. We run both and weight the findings accordingly — a break that needs no privileged access counts for more.

PHASE 1 · BLACK-BOX

What a real attacker can do

No privileged access. We work from a retail unit, the public app builds, published docs, and whatever is in RF and Wi-Fi range — the same starting point as an adversary who buys the product off the shelf.

External radio & Wi-Fi observation
Public APK / IPA analysis
Cloud API probing with test accounts
Answers: "what can someone pull off against retail product?"

PHASE 2 · GRAY / WHITE-BOX

What a motivated insider can do

Consensual, authorized access: debug-unlocked test units, signed development builds, firmware images or source, and protocol documentation. Every artifact stored on encrypted, air-gapped media.

Firmware extraction & source review
Instrumented apps for runtime hooking
Cryptographic protocol verification
Answers: "what can a motivated insider with full access exploit?"

The Attack Surface

Every trust boundary the product depends on.

This is a cyber-physical product: a software decision moves real current — a charge, or a jump-start surge. So we test every path an attacker could take to that outcome — wireless, hardware, apps, and cloud — not just the web tier.

Wireless & RF

The radios the product exposes. BLE for the owner app and pairing — LE Secure Connections, not Just Works or downgradable Legacy pairing, and resistance to KNOB and to MITM via a cloned advertising address. Wi-Fi backhaul that can't be harvested by a rogue access point. And the NFC tap-to-pair and RFID operator cards on the fleet units — verified they can't be cloned, downgraded or replayed to run a unit on someone else's account.

Sniffle / nRF52840Wiresharkaircrack-nghcxdumptoolProxmark3SDR

Cryptographic protocol

Custom app-layer crypto is the highest-yield surface in connected products. We check for AEAD done right (AES-GCM / ChaCha20-Poly1305, not a home-grown encrypt-then-MAC), nonce discipline that survives power loss, bounded replay windows, key separation via a KDF, and a per-device key lifecycle so one cracked unit never compromises the fleet.

source reviewTamarin / Cryptolcustom replay harnessAEAD analysis

Firmware & hardware

Debug ports (JTAG / SWD) removed or locked in production, no privileged serial console, tamper evidence on teardown, verified secure boot, and firmware you can't simply dump and mine for secrets. Opportunistic side-channel observation where the hardware invites it.

Ghidra / IDAbinwalkSegger J-Linklogic analyzerChipWhisperer

Mobile apps — iOS & Android

MASVS-aligned. We decompile the shipped owner-app APK / IPA, hunt hardcoded secrets and endpoints, verify session tokens and device-pairing secrets land in the Keychain / Keystore, confirm certificate pinning has no silent fallback, and test runtime-hooking and anti-tamper defenses against a real attacker with a copy of the binary.

jadx / apktoolHopper / GhidraFrida / ObjectionMobSFmitmproxy

Desktop application

The operator back-office console decompiled and reverse-engineered: secrets and cloud endpoints baked into the binary, update and signature integrity, tampering resistance, and whether the local privilege boundary actually holds when an operator's machine is hostile.

decompilersbinary diffingupdate-integrity reviewRE

Cloud API & database

The OWASP API Security Top 10, distilled to what matters here: broken object-level authorization (BOLA / IDOR) so one owner can't read another's devices or usage, broken authentication and account-takeover paths, injection (SQL / NoSQL), mass assignment, real rate limiting, and encryption at rest for account data. Account-takeover and remote device-hijack paths matter most here.

Burp Suite ProOWASP ZAPsqlmapcustom enum tooling

OTA & updates

A malicious firmware update pushed to a charger or jump starter is a permanent backdoor, so this is one of the highest-impact surfaces. We verify signed payloads (Ed25519 / ECDSA), downgrade and rollback protection so a known-vulnerable build can't be re-flashed, and clean power-loss recovery. No patch path at all is itself a finding.

signature reviewrollback testsA/B partition review

IoT & OT integration

Per-device identity binding so a stolen unit can't clone another's identity, fleet key isolation, and the boundary where commercial units tie into depot charging management and battery-management systems (BMS) — warehouse forklift fleets, telecom and backup-power sites (OT). Anchored to OWASP ISVS and NIST SP 800-213A for IoT devices.

ISVSNIST 800-213ABMSfleet isolation

The Model

Every privileged action is an authenticated, encrypted command.

Start or stop a charge, kick off a jump-start, change the charge profile or config, push firmware — each one flows through one encrypted channel. That channel is the spine of the audit: if it holds, a captured command can't be replayed and a rogue device can't forge one. Everything else is defense in depth around it.

Credential / command → device Telemetry & state → cloud and clients

Methodology & Standards

Grounded in the field's bodies of knowledge — not an ad-hoc checklist.

Every test maps to a recognized standard, so the coverage is auditable and the report speaks the language your engineers and your customers already trust.

CyBOK v1.1NIST SP 800-115NIST SP 800-121 R2 · BluetoothNIST SP 800-213A · IoTOWASP MASVS v2OWASP ISVS v1OWASP API Security Top 10OWASP PTESCWE

Threat model — who we test against

Severity is judged by who can actually pull an attack off. A finding is Critical only if a T1–T3 attacker can exploit it. Higher tiers are scoped or referred to a separate engagement.

T1 · Opportunistic thief in scopeHas the hardware for hours or days. Physical access, common tools, no special RF gear.

T2 · Adjacent RF attacker in scopeWithin Bluetooth / Wi-Fi range. Off-the-shelf SDR and radio gear, modest software skills.

T3 · Motivated insider in scopeLegitimately owns a unit. Wants to extract keys, clone identity, or pivot to another user.

T4 · Targeted attacker limitedA specific target; combines physical, RF, network and social attacks. Findings note where T4 is required.

T5 · Nation-state outCustom silicon, supply-chain interdiction, fault-injection labs, 0-day budget. Separate engagement.

T6 · Vendor insider outCode-signing, factory-injection and cloud-root access. Covered by internal personnel security.

Deliverables

Evidence your team can act on — and hand to a customer.

Penetration test reportOne entry per finding: severity and a CVSS-style vector, affected component, the threat tier required to exploit it, reproduction steps, remediation, and CWE / CyBOK references.

Executive summaryA short, non-technical read on overall risk posture and headline findings — suitable for leadership and prospective customers or investors.

Raw evidence archiveAll captures, code and artifacts on encrypted media with a SHA-256 manifest, so every claim in the report is independently verifiable.

Findings exportCSV + JSON for direct ingestion into your issue tracker — no re-keying between the report and your backlog.

Remediation roadmapA prioritized list with rough engineering-effort estimates and a dependency graph, so fixes land in the right order.

Debrief & data handlingA working session with your engineers. Client artifacts destroyed to NIST SP 800-88 within 30 days of report acceptance, or returned.

“

When a software decision moves real power, it deserves the same scrutiny as the power it moves.

— The Xari security team

How we think about these surfaces.

The same ground, in depth, from our engineering blog.

Wireless attack surfaces: Wi-Fi, Bluetooth and RF Designing safer BLE pairing Reliable Wi-Fi provisioning for IoT products Turning the OWASP Top 10 into engineering practice Eliminating SQL injection in modern applications When API keys leak: hardcoded secrets and blast radius Where SAST, DAST and IAST belong in AppSec Reducing npm and PyPI supply-chain risk Security gates that fit real DevSecOps pipelines Building reliable BLE mobile applications

What Xari Does

We build connected products — so we know how to break them.

Security assessments & ethical hacking Firmware & embedded IoT & OT solutions Mobile — iOS & Android Desktop applications Backend, cloud & API

Because we ship connected products end to end, our security work isn't a checklist run from the outside — it's review by people who have built the same layers they're attacking.

Let's talk

Shipping a connected product? Find out what an attacker sees.

Wireless, firmware, mobile, desktop, cloud — Xari audits the whole system the way a real adversary would, and hands you a roadmap to close what we find.

Get in touch

Representative engagement. Client and product names are fictionalized to protect confidentiality; the methodology, tooling and coverage shown are what Xari runs on real assessments. This page describes what an audit covers — no client's findings are ever published. Standards are the property of their respective bodies.

This page is under review.