I thought I’d take a step back after releasing tools and presenting on CAN to do a quick intro into what communications are going on inside a vehicle anyway. What is CANBus? What is OBDII? Is there a difference?
We’re going to skip all the electrical fun parts, the packet formats, and the theory and move right into using some tools to look at CAN traffic. This means my language is simplified for example purposes. For this exercise I’m going to be analyzing traffic from my 2013 Toyota Tundra.
This is CANBus (image courtesy Wikipedia):
As you can see, it is a bus. We have a bunch of systems on a 2 wire bus. Each system has a particular job. In the case of a vehicle that might be the Engine controller, instrument display, or the tire pressure sensor. CAN is also used in industrial control as well.
This is what CAN traffic looks like:
630 [8] 17 00 00 00 00 00 00 00
638 [8] 13 00 1E 00 00 00 00 00
440 [8] 42 02 00 00 00 00 00 00
The first number is the ID or address of the device sending the message (e.g. 0x630, 0x638). This is not unlike an ethernet MAC address or an IP address. The following numbers are the data bytes (up to 8 per message).
ANY device on the CAN is able to view and send a message to ANY ID. Therein lies the entire problem with vehicle security. There is zero authentication, verification, non-repudiation, or any other accountability whatsoever. Anything on the bus can pretend to be anything else per the spec. Further, you only have 8 bytes of data so adding in something like encryption or cryptoverification is particularly challenging. Basically in order to not suck we have to ditch the whole thing (sound familiar ICS people?).
Ok so that’s CAN in a nutshell. What is OBDII? OBDII is a standard SUBPROTOCOL to CANBus. It’s a set of ID’s that all the vehicle manufacturers must support.
Every manufacturer builds their cars differently. In a vehicle, for example, the RPM may show up on the CANBus on ID 0x2C4 as a 16-bit integer on bytes 1 and 2. Another manufacturer may decide to put the RPM on CAN at ID 0x310 bytes 7-8. OBDII is an attempt to create a standard method of finding out that information. Rather than standardize on IDs, however, a query/response system was created.
The method for obtaining the engine RPM via OBDII is:
- Diagnostic tool sends a message on ID 0x7DF, the standard OBDII query ID. The message contains the number of additional data bytes, the “Mode”, and the “PID” of the requested information.
For querying the RPM the Mode is 1 and the PID is 0x0C. The message would look like:
0x7DF [8] 02 01 0C 00 00 00 00 00 - The modules in a vehicle respond to these diagnostics messages. The ID for the response depends on the module but the IDs start at 0x8 higher than the standard query ID. Thus, the ECU responding to an RPM request will respond on ID 0x7E8. The message contains the number of data bytes, the mode + 0x40, the PID, and the value.
For responding to RPM the Mode is 0x41, the PID is 0x0C. That message may look like:
0x7E8 [8] 03 41 0C 09 C4 00 00 00
In summary, OBDII is simply a sub-protocol that runs on top of CAN. It uses standardized CAN IDs and message formats to request vehicle information. The problem with plugging in third party dongles to the OBDII port is that that port still gives you direct CAN access. The OBDII port can be used to write arbitrary CAN IDs to the bus. In practice, this is used to do things like provide vehicle software updates (e.g. flashing new firmware to the ECU).
An attacker is not interested in the OBDII spec or most of the information it provides. An attacker is not interested in querying a vehicle for diagnostic information. Instead, an attacker wants to see what kind of control over vehicle operations is possible by writing to the CAN.
In part two of this series, we’ll do some CANBus reverse engineering to figure out what CAN messages we have an interest in if we want to cause the vehicle to behave erratically.