CAN Hacking: The In-vehicle Network

Last time, we discussed how in-vehicle networks work over CAN. Now we’ll look into the protocol and how it’s used in the automotive industry.

The Bus

On the hardware side, there’s two types of CAN: differential (or high-speed) and single wire. Differential uses two wires and can operate up to 1 Mbps. Single wire runs on a single wire, and at lower speeds, but is cheaper to implement. Differential is used in more critical applications, such as engine control, and single wire is used for less important things, such as HVAC and window control.

Many controllers can connect to the same bus in a multi-master configuration. All messages are broadcast to every controller on the bus.

An oversimplified in-vehicle network
An oversimplified in-vehicle network

The structure of a CAN message
The structure of a CAN message

From a software perspective CAN message consists of 3 parts: an identifier, a data length code, and up to eight bytes of data.

The identifier (ID) is used to specify what the message means, and who’s sending it. Typically standard IDs are 11 bits, but there are also 29 bit extended type IDs. The ID also defines the priority: the lower the ID, the higher the message’s priority.

The data length code (DLC) is 4 bits, and specifies how many bytes of data will be in the message. In some applications, a DLC of 8 is always used, and unused data bytes are padded with zeros.

Finally, the 8 bytes of data contain the actual information. The meaning of the information is inferred from the message ID, and the length is specified by the DLC.

Decoding & Databases

To make sense of the 8 data bytes, the controller will decode the data into signal such as engine RPM, fuel level, or brake pedal position. Each signal has a start bit and end bit, which are used to select the correct bits out of the 8 bytes. No signal information is transmitted over the bus. Instead all controllers must agree on the layout of messages and signals beforehand. Below is the table of signals, and the graphical layout of a sample message.

A table of CAN signals that make up a message
A table of CAN signals that make up a message
A sample CAN message layout

To help program controllers that agree on messages and signals, a CAN database is used. This database contains definitions of all messages and signals. The most popular format is DBC, which is a proprietary (but ASCII based) format by Vector. The DBC editing tool, CANDB++, is free (as in beer). The databases are used to auto-generate code that can interpret the messages.

With a database file in hand, you can easily sniff the CAN bus and interpret all kinds of data. One example is a hack we featured that sniffed the bus for steering wheel button presses. You can also pretend to be controllers by sending spoofed data onto the bus. For example, you could send a fake engine RPM to the instrument cluster.

No, this car wasn't actually doing 8000 RPM.
No, this car wasn’t actually doing 8000 RPM.

The majority of the communications during normal operation work by decoding a database. However, for diagnostic applications, there are special protocols that are used. Next time, we’ll look at how these protocols work, and what fun can be had with them.

CAN Hacking

56 thoughts on “CAN Hacking: The In-vehicle Network

    1. There is no “legal chance” to get the DBC files from a car manufactor and the manufactores does not exchange DBCs between each other. There is no standard, because you can make conclusions about the build in sensors or other hardware.
      It is also not allowed to drive cars with direct CAN access from outside the cars closed system on public streeds, but what you do on private ground depends on you. Only cars with special licenses can drive in public. But If you have CAN access, it is very easy to verify the CAN messages, by switching, pushing or whatever. You can push a button and look on the messages, what values changes. For example, the linux kernel have the VW/Audi SocketCan in it, til version 3.6.0. With the SocketCAN utils on:
      you have open source cansniffer, candump and canplayer utilities. It is very easy to analyse CAN messages.

          1. That’s not really a citation, and to the best of my knowledge, not true. I know there are statutes that dictate one cannot view the data in realtime (much like anti-texting and driving laws), but even for safety critical systems, while ill-advised, it’s not illegal so long as you don’t impact federally mandated systems (e.g. emissions, in the US).

    2. Databases are used by OEM and those close enough to the OEM to get access. Top level aftermarket ECU’s will sometimes include.dbc files again depending on who you are. I don’t know of any free tools what will use .dbc files, the most accessible I can think of Matlab/Simulink, again you need a few hundred dollars of hardware plus the software to get started.

      1. I was hoping someone who say there is a community effort out there to document the CAN bus for various cars, especially since there is so much parts commonality between either model years, of various models of the same manufacturer.

        1. GM and other actively sue groups like that into the ground. I was very active in a GM ECM reverse engineering group and GM not only threatened major lawsuits, but threatened that we would be in federal export violation of military equipment if we did not stop publishing our data and findings.

          If you do create a nice document, publish it anonymously so the lawyers can not find you and do so on multiple sites so they cant squash it.

        1. Does that 10 dollar adapter integrate with Matlab/Simulink? Or does that android app support .dbc files? I’m talking about using putting .dbc files to use, not getting on the CAN bus for cheap, I realize that there are cheap CAN adapters out there. I have a cheap USB one connected right beside my Kvaser interface.

          The cheap unit works great for monitoring the bus, however when you want to do anything more like isolating a node and filtering it’s data the professional interface is a must.

          1. You can put together a simple serial model that would interface with serial to CAN dongle, however to use .dbc files and VNT CAN blocks you need a supported device. Simulink is more than likely overkill for all but the top level guys that are doing real deep CAN bus work, like integrating aftermarket ECU’s into OEM applications. If you want to sniff the bus to roll up your windows with an Arduino there is no need to go down this rabbit hole.

          2. The Arduino is not fast enough for all CAN buses, I struggled with the 16Mhz AT90CAN til i rewrote a lot of the atmel CAN routines. I found when i was logging i’d loose a lot of messages and not be able to reply fast enough. But saying that i am one of the “like integrating aftermarket ECU’s into OEM applications” guys, now it keeps up with all my ‘pro’ tools. There are a lot of decent ARM’s with CAN the STM32s spring to mind.

            But logging is still logging, IMHO its better to go that little bit above to be sure you’re logging all the data, and replying fast enough.

            But if you’re only sending out CAN messages or reading OBD II PID’s the arduinoish ones are fine, so use those for the final devices.

  1. wouldnt mind more info on these databases too, when i sniffed out the steerignwheel and i-drive controlls on my car i just bashed the buttons and parsed the logs untill i found something plausable, took a few days, and that was just for basic user inputs never mind interesting stuff like wheel speeds and central locking status and what have you.

  2. In addition to single-wire CAN and high speed CAN some people may also be interested in learning about CAN-FD. CAN-FD uses the same physical layer as highspeed CAN but the CAN controller allows a higher bitrate during data transmission allowing CAN-FD to be backwards compatible with highspeed CAN with higher datarates(currently around 8MB/s) or to transmit longer messages of up to 64 bytes.

    For some more details on CAN-FD see:

  3. Suppliers won’t give you there dbc files or CANdB Files. But it is common to just listen for some changes on the bus. Since every can node has a own Id you can just connect to the bus (most common is Baudrate 500k (then 250k and 125k)) so grab the steering wheel e.g. and turn it. With a small tool like PCAN VIEW, Vehicle Spy you can see the data changes. If there is a field which might have the data you want to see inside, try some filters like datasize 32bit or 8 bit and use different formats try two’s complement and tada we got the value of a Hyundai sedan in less then 5minutes. That is what companys do for testing parts of vehicles.

    Also note, data size is not fixed to 8Byte, that was years ago, look into the framed messages and there is also CAN-FD.

    For diagnostics things get more difficult since the ECUs wait for commands to send there data and there is a exhaustive use of protocols, like XCP, CCP…

  4. Most car manufacturers use the ASAM ODX standard for databases and there are multiple implementations of it…vector being one of the implementors. These databases contain everything from communication parameters to ecu variant identification templates to compute-methods for data sent on the bus. Most of the generic auto-shops out there use simple software provided by ECU manufacturers(eg. bosch, siemens) and grant access to simple DTC info and error memory info. Flash sessions or variant coding for instance require elevating the diagnostic session through a key and also much deeper manufacturer-specific knowledge.

    1. There are multiple things that happen over the automotive networks.. there is the normal communication between ECUs (how fast am I going? are the doors open? what is the steering wheel angle?). The standard format for documenting the format of these messages is a DBC.

      ODX or CDD (Vector CANdela) describe the diagnostic databases, i.e. what you can query using an external tool. These would be extremely helpful if they were released because they contain all of the diagnostic services (not just the legislated ones), and define all of the DTCs.

  5. Someone gave me a joystick off of an electric forklift. It uses the CANbus, now if I can only figure out the proper wiring so I don’t let out the magic smoke when I go to test it….

      1. I’d definitely like a post on wiring/connectors.
        I’ve only worked with it briefly, but for the machines I was working on, we used these god-awful Deutsch connectors.
        Bulky (for the number of wires), expensive, and only attached to the delicate wires, not the tough outer plastic/rubber sheath of the cable (wire bundle).
        I’d like to see the other stuff that gets used, what’s common, what’s standard, what’s not, etc.

  6. This comment isn’t about the content, but more on the way it was presented. On the homepage of HaD, it looks like there is a double post of sorts. The bold green in the actual article is almost the same as the post name itself. Thought it was a bug at first lol. Maybe make the article section headers a darker green or something. Anyway, haven’t made a post since the new overloards. I like the direction and what is being done. I see more and quality things here and am welcomed to the changes.

  7. The note i’d add to this is to take away the focus on 8 bytes, that’s just what the underlying CAN protocol is using

    From a diagnostic/reprogramming software point of view, ie where we’re looking at it from, the actual message from the cars systems can be considerably longer, usually it is ISO 15765-2/ISO-TP the message is broken up into 8 byte packets, carrying 7 bytes of information, then typically reassembled inside the j2534 software and presented to the host software. look up CAN multi-frame message on wikipedia for details.

    Nearly all reflash tools use multiframe messaging for instance, but if its via J2534 then it takes care of it, you can send long messages into J2534 and it’ll just split it up into multiple CAN frames, and reverses the procedure for incoming.

  8. This is a subject very near and dear to our hearts here at @CarKnowLLC. We create CAN/GSM bridges (we call them “CARduinos”), but even with access to CAN — you really need an understanding of what exactly is on the network to accomplish anything.

    On our company website (I don’t want to linkspam, so Google us), we have a link to a Wiki we’ve created in the hopes of building a user community for sharing reverse engineered CAN parameters. While it’s rather sparse now, we have more data that we’ve collected internally and hope to publish soon. We hope you join us in doing the same, so that we can all access the information transmitted within the vehicles we own and operate. There’s a lot of great potential here, and who knows — if we get enough user interest, we might be able to sway an OEM or two to the dark side.

    Happy to opine, discuss, etc. if anyone has questions our company can help with. The hardware should be available for preorder shortly, either directly on our site or as part of a crowdfunding campaign.

  9. With all the various gadgets that can be added to a car these days by home brew enthusiasts, I think a most useful CAN bus hack would to make use of a car central information display. It would guess a limitation would be that every manufacturer, or even model of car would need unique addressing.

  10. I’ve been playing around with my 1 series BMW for a while now (I wanted to use the steering wheel buttons to control my carpc), and there’s a couple of things I learned.
    easiest way to find the messages you want: record everything while on a drive to get a rather detailed list. then record everything again while in this case pressing buttons. then make use of the fugly mess of data you produced.
    lists with IDs for specific cars may or may not be available.
    the hardware i used for this is a custom design atmega32u4 / mcp2515 / mcp2551 board that runs in listen only mode and blasts all the data to the pc via a virtual com port. speed might be an issue, but the kcan on this car runs at a mere 100kbit.

  11. On the 2010 Ford Fusion SE model, it has a narrow LED display for radio and time display. I wanted to try and use my arduino and program my own display data there. Would a device like this Sanyo Automedia product, 9E5T-19C116-AE, (
    be communicated with via CAN protocol (does the LED itself interpret CAN signal?), and could I wire directly to it from my arduino UNO and with software/libraries be able to display text on screen?
    Or at this level does talking to the LED display have nothing to do with CAN and would be more like talking to the display driver, like an LCD Hitachi HD44780 driver?

  12. hi,I would like to ask how can we find out the engine torque?since there are many torques in the CAN, such as driver torque, torque without request, ect, to find the them and give them a ‘correct’ convert formula is always a headache to me..

  13. That is the reason why CAN Protocol was currently switching to Ethernet protocol. Now it is 2015, the Autosar architecture is implemented, built and burned as a program binary on chip as every client specify what modules from it want, to allow a boot loader to start this program in ECU’s without using CAN communication module activated, instead using Ethernet packets what are encrypted using SHA-128 cypher. Hard wire debugging will be harder, and harder like you try to intercept a raw decrypted GSM traffic using a 0.1 – 1 Mhz range antenna. Another implemented stage is signal norming which is a module what redirect a direct ECU -> Sensor[N] to a more complex route to make this game more fun. Have fun to play with cars above 2015.

    1. I forgot to mention that I use a professional debugger hard (CANextender) and soft (CANoe) available from Vector, and a JTAG Debugger from Lauterbach that makes me able to media convert packets and switch between CAN/Ethernet protocol with help of a Cisco router to monitor the packets using Wireshark.

      1. there’s nothing really special about them, as long as it can sniff can, handling timing and stuff they’re all pretty much the same, unless you rely on their software. i see people spend a fortune on whats often a can transceiver + mcu.

        same for lauterbach, i have their trace32/+ BDM/jtag debuggers and simulators, they’re gathering dust since the software is subpar. better off saving the money and using a cheaper jtag (even pe micro) and spending the money on more tools or software dev. sure if you’re doing flash emulation they’re good upto a point. rolling your own tools, and spend money on idapro/winols etc.

        cars have already been encrypted with RSA 512/1024 and never matters, i hear people decry all the time how hard its gonna get, cept they never factor in the human factor, people leak the keys, get bribed , take the software to their new gig and then it gets out, or just give it away. social engineering will always plug the gaps RE can’t. spend 5 minutes on any of the tuning boards and you’ll find docs/software and source for pretty much every ecu out there.

        remember professional just means you paid for it

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s