FAQ
When you assess an OBD-II dongle, what's in scope — the dongle, the cellular path, or the vehicle network behind it?
By default, all three. An OBD-II dongle creates a security boundary that touches three attack surfaces: the dongle's firmware and local interfaces (Bluetooth, USB), the cellular or wireless path to the dongle's backend (LTE, 5G, Wi-Fi, manufacturer cloud), and the vehicle network behind the OBD-II connector. We typically scope all three because exploitation of any single surface usually leverages the others, and the client's security posture depends on the complete chain.
Short answer
By default, all three. An OBD-II dongle creates a security boundary that touches three attack surfaces: the dongle's firmware and local interfaces (Bluetooth, USB), the cellular or wireless path to the dongle's backend (LTE, 5G, Wi-Fi, manufacturer cloud), and the vehicle network behind the OBD-II connector. We typically scope all three because exploitation of any single surface usually leverages the others, and the client's security posture depends on the complete chain.
Long answer
The OBD-II dongle category is broad: aftermarket diagnostics, insurance telematics, fleet-management trackers, consumer-grade engine performance monitors, after-sales infotainment add-ons. They share a common architecture — a small ARM or microcontroller-based device that connects to the OBD-II port, optionally bridges to a wireless network (Bluetooth to phone, Wi-Fi, cellular), optionally connects to a backend cloud service, and exposes some user-facing functionality.
The dongle itself: firmware extraction (debug interfaces, eMMC sniff, chip-off where required), reverse engineering of the firmware to identify CAN-bus interaction logic, authentication-secrets handling, and update-mechanism integrity. For Bluetooth-equipped dongles we also cover BLE-pairing security, BLE-GATT enumeration, and the pairing-key provisioning model.
The cellular or wireless backend path