Hacking vehicle CAN bus is a fancy name for reverse engineering the vehicle ECU (engine control unit) to find which signals change when you do stuff with your car (like pressing accelerator pedal, brake, turning the steering wheel etc). This is very useful skill set to acquire because then it opens limitless possibilities of what you can learn from the vehicle.
In this post, Ill briefly go over the technique to decode accelerator pedal, brake and engine RPM signals from a vehicle engine control unit.
Here is a brief video on the CAN bus for the basics
CAN is the communication protocol used by all the vehicles these days. This is a two way communication protocol where a node can receive or transmit certain set of data. This node can be your engine, your transmission or even other smaller modules in your car that control the ABS (antilock braking system) or Traction control system or interior lighting and door locks. Every node has to specify certain parameters for transmitting or receiving any data. These parameters are
- Data Length
- Data Identifier (unique for every message)
- Direction: Whether it is “Receive” or “Transmit” type of data
- Periodicity: How frequently this data signal should be transmitted or received
- Actual data bits. (start bit, and length)
Here is a small snippet of data that I reverse engineered from one of the vehicle platforms
There are several things to learn here:
This is a message where there are two signals a) brake signal and b) engine rpm signal. The message and signal name can be anything you like (human readable). Other features of this data snippet are as follows
- PID: This is a unique ID which the vehicle ECU uses to communicate the what the engine rpm is and whether the brake is pressed or not. Other module listen to incoming data from this ID and make relevant (Like e.g reducing the speed when brake is pressed, increasing the fuel rate when rpm increases etc)
- ID Type: This is a standard type of message. The other type is “Extended”. More information can be fitted into the extended type of message. But for most of the OEMs standard data type is sufficient. Standard and extended data type varies in the bit length of the entire CAN frame. Wikipedia has a good article on this. As you can see below, there are 18 bits more to the identifier. An example of an extended CAN identifier would be 0x18FFF001 (vs 0x115 is standard PID as explained above). Here every byte in this ID has a specific meaning and relate to which modules can “listen” to this data message. Please read more about J1939 protocol to understand the structure about extended CAN frames
- DLC: DLC means how long the data message is. Here 8 means the message is 8 bytes (5=64 bits) long. In the above example I have reverse engineered only 2 bits for the brake and 13 bits for rpm.
- RX:15 is the periodicity and direction of the message. That is how often the message is sent and whether it is a “receive” type of message or “transmit” type of message (wrt the vehicle ECU). This particular message is sent every 15ms and is received by the ECU (Rx)
- The table below the message snippet shows two signals I found on this message. One is a brake signal and other is engine RPM. Every signal has a few characteristics.
- Start Bit: At what location (in the 8 bytes of data) does the signal begin. Here Brake signal starts at bit number 60
- Length: How long is the signal. Here brake signal is 2 bits long.
- Factor and Offset: These are used to convert raw data transmitted by the node to physical values. Physical Value = Scale*RawData+Offset
- Max, Min and Unit are the characteristics of every signal (Usually this is for information only)
- Type: Every signal has a type. It can be a Boolean (can take only 1 or 0 values) or an unsigned/signed integer or a decimal (float) number. Here Brake is an unsigned 32 bit integer (uint32) which can take values 0, 1 and 2 (generally 0 is brake not pressed, 1 is brake pressed and 2 is invalid signal).
- Format: This is usually for software purpose. It helps in how to interprete which is the start bit. Format can be Motorola or Intel. If the type is Motorola then bit zero is the forst bit in bottom right corner of the grid shown above, otherwise it is on the top right of the grid. If the format of the brake signal was Intel, then the start bit would not have been 60, but it would be 4.
- DBC Files: All this data can be arrange in tabular formats as shown above. Such a file is called DBC file. Without DBC file, you will have to convert the raw data everytime you see a new value.
- Baud Rate: How fast the data is broadcasted. Usually the OEMs implement a speed for 500kbps. This is called the baud rate. You would have to specify this in the tool that you are using to read the data. Otherwise you won’t be able to see the broadcasted data on your computer.
Alright, Now as we know the basics of CAN, lets see what tools are handy for reverse engineering CAN bus.
- First and foremost, you need some software to read the data from the vehicle ECU. I have used tools like Vehicle Spy, PCAN Express and Kvaser. The Vspy is a bit expensive tool but it lets you to import a DBC file so that you can look at the love data not only in raw hex numbers but also in human readable phycial quantities as defined in the DBC. Kvaser does not have that facility so it is more time consuming to find data bits which change when you carry out your tests.
Reading Data with CAN tools Video
- Harness: You would need some kind of basic harness to connect your computer to the dongle you are using and the dongle to the OBD port of the vehicle. OBD stands for on board diagnostics and this is the place where all the data is available for you.
- Kvaser Database Editor: Useful to create DBC files.
- A paper, pencil and Lot of Patience!
And that’s it… with these three things, you can create wonders, build diagnostic tools, apps and what not. It’s pretty cool.
Here is a basic strategy to find signals you need. The video shows the process of actually how to decode the signals in the vehicle.
- Usually signals are broadcasted by modules like engine control unit (ECM), transmission control unit (TCM), ABS, RCM (Restraint control module) etc. Connect your dongle and set the desired baud rate to start receiving the data from the OBD port. Now disconnect one module (say TCM) and see which IDs stop. These IDs are coming from the TCM. Similarly you can disconnect other modules and jot down which IDs are coming from which modules.
- This is useful because then you shortlist your list of IDs for finding a specific signal. A little bit of experience would tell you that say engine RPM is transmitted by the ECM. So now you can focus on only those IDs that are broadcasted by the ECM. You just reduced your list to a few messages!!
- Similar for the brake signal. A bit of experience would tell you that brake signal might have just two values (0 and 1). Press the brake and see which bit changes. Release the brake and again monitor the same bit.
- If there are more than one bits, you can do the same test with and without the engine on. If in case one of such bits do not change values when the engine is off (but ignition is on) then you can rule that out. Usually brake value changes whenever you press the brake (irrespective of whether the engine is on or off).
- Measure what is the start bit (pick your format and assign the start bit accordingly) and add this to your DBC file. That’s it.. you got your brake signal.
- Similarly you can decode many other signals. I have shown a few signals in the videos below.
Decoding Brake Signal
Decoding Pedal Signal
Key things to keep in mind:
- Short list your IDs
- Carry out the test to see which bits change
- Test for extremes (idle rpm-redline rpm, brake pressed-released etc)
- Get the start bit and length of the data
- Convert raw data into physical units by guessing the scale and offset.
- Enter it into a DBC file
- Test for other points to see if your scale and offset it correct or not