Researchers from the Argus Research Team found a way to hack into the Bosch Drivelog ODB-II dongle and inject any kind of malicious packets into the CAN bus. This allowed them to, among other things, stop the engine of a moving vehicle by connecting to the dongle via Bluetooth.
Drivelog is Bosch’s smart device for collecting and managing your vehicle’s operating data. It allows a user to connect via Bluetooth to track fuel consumption and to be alerted when service is necessary. It was compromised in a two stage attack. The first vulnerability, an information leak in the authentication process, between the dongle and the smart phone application allowed them to quickly brute-force the secret PIN offline and connect to the dongle via Bluetooth. After being connected, security holes in the message filter of the dongle allowed them to inject malicious messages into the CAN bus.
The Bluetooth pairing mechanism, called “Just Works”, has been fixed by Bosh by activating a two-step verification for additional users to be registered to a device. The second issue, the ability for a maliciously modified mobile application to possibly send unwanted CAN messages, will be mitigated with an update to the dongle firmware to further limit the allowed commands that the dongle is able to place on the CAN bus.
Bosch downplays the issue a bit in their statement:
It is important to note that scalability of a potential malicious attack is limited by the fact that such an attack requires physical proximity to the dongle. This means that the attacking device needs to be within Bluetooth range of the vehicle.
The problem is that physical proximity does not equal Bluetooth range. Standard Bluetooth range is about 10m, which is very arguable physical proximity, but it is pretty easy to buy or even modify a Bluetooth dongle with 10x and 100x more range. When adding a wireless connection to the CAN bus of an automobile, the manufacturer has an obligation to ensure the data system is not compromised. This near-proximity example is still technically a remote hack, and it’s an example of the worst kind of vulnerability.
Automotive diagnostics have come a long way since the “idiot lights” of the 1980s. The current version of the on-board diagnostics (OBD) protocol provides real time data as well as fault diagnostics, thanks to the numerous sensors connected to the data network in the modern vehicle. While the hardware interface is fairly standardized now, manufacturers use one of several different standards to encode the data. [Alex Sidorenko] has built an open source OBD-II Adapter which provides a serial interface using the ELM327 command set and supports all OBD-II standards.
The hardware is built around the LPC1517 Cortex-M3 microprocessor and can accept a couple of different versions. Here’s the PDF schematic, and a set of Gerber files (ZIP archive) for the PCB layout, if you’d like to dig in to it’s internals. The MC33660 ISO K Line Serial Link Interface device is used to provide bi-directional half-duplex communication interface with the micro-controller. Also included is the TJF1051, a high-speed CAN transceiver that provides an interface between the micro controller and the physical two-wire CAN lines on the ODB-II connector. The serial output from the adapter board is connected to a computer using a serial to USB adapter.
The software is written in C++ for the LPCXpresso IDE – a GNU tool chain for ARM Cortex-M processors, but can also be compiled using a couple of other toolchains. He’s got instructions if you’d like to build the firmware from source, or if you’d like to program the adapter via Flash Magic.
We featured [Alex]’s inexpensive PIC based ODB-II interface way back in 2007, so he’s been working on this for a while and has a good grip on what he’s doing.
[Bruce Land] sent in this cool final project for ECE 4760 at Cornell University. Dubbed TrckrX, it is an OBD-II tracking and data logging system built into a BMW E36 M3. The car in question is being used in some auotocross competitions. The driver wanted instant access to some data as well as a log of everything for later analysis. The unit gives a real time display of vehicle speed, coolant temp, and RPM. G-force and timestamps are stored on the SD card.
We think this is a very cool idea, and could be quite useful in some instances. The real time display of speed and RPM seem a bit peculiar as the car’s speedometer and tachometer are more appropriately placed for real time information. However, we completely understand that this was a class project and this person may not have wanted to replace their dash cluster with a new readout.
[Steve] let us know about his MultiDisplay car monitoring system. Unlike traditional systems that rely on interfacing with the OBD-II protocol and existing car computer, the MultiDisplay uses an Arduino and custom shield with a combination of sensors; including temperatures, pressures, throttle, Boost, and etc. The data collected can then be displayed on a 20×4 LCD or streamed to a PC with visualization and event recording.
It’s nice to see half a years worth of work finally be complete and presented in such a clean and professional manner, keep up the good work [Steve]
[Avi Aisenberg] sent us his final project for ece 4760. His team built and OBD-II data interface. Even though OBD-II is an industry standard, each manufacturer has implemented it differently. This is where this project shines. They have built it to be capable of talking to any of them. Not only that, but it has a nice backlit LCD screen for diagnosing issues without having to go back to your computer and downloading the data. If you really don’t need all the bells and whistles, you can make one for roughly $15. They even have an OBD-II app for the iPhone.
Rev by DevToaster is an application for the iPhone and iPod Touch that allows real-time monitoring of vehicle ECU data from the OBD-II port. Rev interfaces with a WiFi OBD-II dongle.
If your check engine light is on or flashing, REV is able to check the engine code, list all of the engine codes stored in the vehicle, and reset the stored codes or check engine light.
Rev is able to monitor real-time; vehicle speed, RPM, fuel consumption, engine coolant temp, fuel pressure, calculated engine load, throttle position, intake manifold pressure, air intake temp, timing advance, mass air flow, fuel level, barometric pressure, EVAP system vapor pressure, and fuel trim.
A brief video of REV in action is after the break.
Continue reading “iPhone OBD-II app”
Writing code for embedded applications can be difficult. There are all sorts of problems you can run into – race conditions, conflicting peripherals, unexpected program flow – any of these can cause havoc with your project. One thing that can really mess things up is if your microcontroller is getting stuck on a routine – without the right debugging hardware and software, this can be a tricky one to spot. [Terry] developed a microcontroller load meter just for this purpose.
It’s a simple setup – a routine named loadmeter-task on the microcontroller sends a train of pulses to a mechanical ammeter. The ammeter is then adjusted with a trimpot to read “0” when the chip is unloaded. As other tasks steal CPU time, there’s less time for loadmeter-task to send its pulses, so the meter falls to the left.
Overall it’s a quick and easy bit of code you could add to any project with a spare GPIO pin, that might help you debug. Plus it’s cool to know how hard your project is pushing the silicon.
If you’d like to know more about what your chip is doing, check out this post about the usefulness of in-circuit debugging, or read about Bil Herd’s experiments with ICE and OBD-II.