Search This Blog

Sunday, September 2, 2018

4-wheel adventures ranging from customer relationship to automotive hacking

1. Context

Since more than a decade ago, automotive technology have captured my interest to some extent. Not so much in the mechanical domain, for which the industry have in most part been over the years conservative and slow in pushing inovation, but mostly in respect to the digital framework that integrates the vehicles. This overlay of digital technology plays a fundamental role in modern cars, ranging from safety, fuel economy, controlling the production cost (by reducing the number of individual parts), emissions control, comfort and entertainment.

The proposition that a new car represents is to a great extent defined by the technology that is behind, which serves to enrich the user experience, to provide unique features, and also to make sure that the vehicle complies with the safety standards that are in place in the geographies where the vehicles are sold.

In spite of an effort to standardize much of the integration that exists between the electronic components of automotive vehicles, there is a broad domain of protocols and data formats which are manufacturer-specific and that are rarely shared with the public. An important part of the standardization that began taking place since the 1990's have been largely driven by the introduction of regulation to enable emissions testing, notably teh suite of OBD (On-board Diagnostics) related standards. These include:
  • SAE J1850
  • SAE J2284
  • ISO 8093
  • ISO 15765-4
  • ISO 14230-4
On top of the standards (which among other aspects define communication transport layer for messages between controllers and/or diagnostics tools) are the vehicle module specific commands and parameters.

Only a small slice of these commands are covered by the standards, as is the case of the OBD-II/xOBD problem code (PID) lookup process. These and a limited set of realtime monitored parameters are well documented and covered by the standards, and in general every car manufacturer must provide the OBD-II port, and implement this common set of commands.

2. Initial experience

The first peek I took into understanding OBD, was to manually build an interface after having enrolled in ELM Electronics beta testing program of one of their firmware releases. They have shipped me (free of charge) a PIC microcontroller flashed with a beta version of their firmware.

I was able to play with the tool, at the time using a Fiat Idea 1.4 as a test platform. You can check my blog post from that time:

What I could capture since then, is that not much went on in the way of this industry becoming more open source. On the contrary, most of this industry remains closed, with niche markets of companies providing expensive tools for professionals, and another tier of companies providing cheap tools to consumers, which appear in most part being developed based on reverse engineering and leaked information from the manufacturers.

The opensource comunity have however received very little contribution from developers and engineers seriosly commited in producing and sharing knowledge in this domain.

3. Recent experience with a VCDS competitor - OBDeleven

Recently, mostly out of curiosity and some practical necessity, I have acquired a device called OBDeleven, which is produced by a company called VoltasIT (based in Lithuania). This is a tool that is specific to the VAG group vehicles, and is designed to be used with their Android app. It is a relatively cheap proposition, compared to equivalent tools such as the Ross Tech VCDS (formerly VAG-com).

The device attaches to the OBD-II diagnostics port, and integrates a bluetooth chip which pairs with the smartphone.

From a quick teardown and looking at the chips it is very similar to the ELM interface I built 10 years ago: one PIC18F25K80 microcontroller:

 a CAN transceiver (in this case a NXP TJA1040):

and a few other bits and bobs (voltage regulator, diodes, etc):

The bluetooth radio is clearly of a very cheap type, given the fact that these share the same dodgy bd_addr (it should be unique per device).

Putting the hardware aside and ignoring the inflated price for a device that is mostly the same as a typical ELM327 clone that can be bought from China for 5 €, the software has a very useful set of features, and apart from some kinks is well put together.

The approach of monetizing the more complicated and risky adaptations (which they call apps - within the app) is also interesting, while still giving the user the basic tools for making the changes (at his own risk) by himself.

At least in the VAG domain, there are three configuration domains which are made available via the OBD interface (this was interpreted and summarized from forums and other sources online):

  • Coding (long or short) - a given byte array which contains an assortment of flags, enumerated types and other types of values. It usually encodes the features that are made available in a particular unit (car) that goes through the assembly line. Unless hardware is added or removed from the vehicle later in its lifetime, the values are not expected to be changed. The coding being considered long or short depends on the size of the byte array. Some control modules do not provide many customizations, and as such the byte array is short;
  • Adaptations - individual settings that are stored in the control modules, which can consist of calibration data or features that can be enabled for a particular market or specific sale. These can be changed by the car dealership as required;
  • User defined settings - these are the changes that the user can perform himself (e.g. via the infotainment menus or instrument cluster). For example tire pressure warnings, tire pressure reset, speed warnings, interior lights, infotainment sound controls, trip distance, etc. Usually the user can change these settings to the factory defaults.
This tool enables the access to the first two, and also has convenience features like having a list of access codes which are common for having write access to the adaptation or coding changes.

Also the tool can read a myriad of realtime data (well beyond the OBD standard), the can range from the current temperature of the infotainment CPU, to the calculated amount (in grams) of sooth in the Diesel Particulate Filter, plot charts and export the data to CSV.

4. Dealership episode and outcome

Recently I had an episode of taking the car to the dealership for a rear bumper fix because I was rear-ended in the highway, and by mistake I left the OBDeleven dongle in the socket or stored in the glove compartment (I am not sure). The fact is that I noticed the dongle disappearance right after leaving the dealership.

Upon talking to them and complaining about the disappearance of the adapter, they were unable to find it and proposed to compensate me with one of their official dongles, the VW DataPlug:

At time I found that pursuing proper compensation would be a hassle, and this would be better than nothing.

Later I read online that at least in some markets the VW dealerships were giving away these dongles for free during 2017.

5. Reverse engineering

Anyway this could be an interesting dongle to analyse, and later I could consider reselling it in order to at least recover part of the value of the OBDeleven.

The first impression of the physical dongle (the DataPlug) was that of a product made according to automotive standards (high temperature plastics and precision made rugged casing):

It is produced by Texa, an italian manufacturer with a comprehensive portfolio in automotive tools (

The OBD connector even has a metal locking plate:

Very different from the OBDeleven, with its cheap plastics and conventional PCB materials and assembly.

Regarding the chipset, it was physically undecypherable, but judging by the package aspect and pin count these would be more sophisticated devices than in the OBDeleven:

There are 3 main devices. A larger one marked with 52102A 115U7231A:

 a smaller BGA package next to it, with the references F4150G6 A500GVQ TWN7332:

And the bluetooth chip, which is the only identifiable of these 3 chips, a Cypress CYW20713 Single-Chip Bluetooth Transceiver:

Given that the dongle has an FCC ID  - T8RDP15, I was able to lookup online in the official FCC site:

From there I could find in the user manual that the device has the following specifications:

ARM Cortex M4 CPU (168MHz)
Total Flash: 1024 Kbytes FLASH 
Total RAM: 196 Kbytes RAM

And it conforms to the following directives and regulations:


R&TTE 1999/05/EC
RoHS 2011/65/EU

Product regulations:

EN 301 489-1V1.9.2:2011
EN 301 489-17V1.6.1:2013
EN 300 328-2V1.8.1:2012
EN 60950-1:2006/A11+A1+A12+AC:2011
ISO 7637-1:2002
ISO 7637-2:2011



In sum is a much superior device to the OBDeleven.

The design and architecture details of the software and dongle were requested to be made confidential by Texa to the FCC, and as such are not published.

During the analysis I have attempted to grasp more details by looking at the disassembled APK from the Volkswagen Connect app, but given the obfuscation and lack of time I did not went deep into taking conclusions. I was able see that their communications library uses Java bindings that are created from protobuf. As expected the original protobuf grammar files could not be found in the package.

I also enabled Bluetooth HCI sniffing on the handset, and inspected some of the communication between Android device and the dongle while I was using it in the car.

Again it was difficult to take conclusions, but it appeared that no encryption was taking place on top of Bluetooth own security, as some expected plaintext such as the car odometer Km could apparently be found in the payloads. I could not decypher the VIN number, but it is possible that it would be encoded differently. Certain headers such as 17 03 03 00 seem to repeat across different responses from the dongle, and the payload 0B FF 01 06 86 apears to repeat in many of the requests:

It does not seem to have any known protocol on top of RFCOMM (such as SPP). Also the pairing normally fails when attempted directly from an Android device or some other system such as Windows or Linux running bluez.

In spite of the challenges that may represent, this could be an interesting alternate device for building applications on top of. For example something with the potential of OBDeleven but without the constraints and reliability issues, such as the risk of battery draining that occur in the later, due to poor power management capabilities and/or bad implementation (it is not because of the device itself, but from the control modules that the dongle prevents from switching to sleep mode). The VW DataPlug does not appear to have this problem.