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

Comments

  1. matt says:

    So where exactly do you get the DBC databases? I assume the manufacturers dont supply them.

    • Reset says:

      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:

      https://gitorious.org/linux-can/can-utils/source/16c970d40e6c19dde705bad4751bab1a3a4f3a0d:

      you have open source cansniffer, candump and canplayer utilities. It is very easy to analyse CAN messages.

      • Nate B says:

        Do you have a cite for it not being legal to drive a car with direct CAN access on public roads? What country does that pertain to?

        • Reset says:

          I know that Europe and the USA does not allow direct CAN access.

          • 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).

      • fartface says:

        So scangauge violates the law then. Because mine access the canbus and they claim it’s legal. and yes it CAN change things like reset the SES light as well as other functions.

    • KWest says:

      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.

      • galah says:

        Few hundred dollars? A ODBII bluetooth adaptor off ebay is more like 10. Works well with android apps.

        • KWest says:

          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.

          • You actually can interface those adapters to MATLAB and other programs. The bigger issue is that accessing non-OBD CAN data is tricky and requires direct manipulation of the AT commands (e.g. in an ELM327). Both devices have their place.

          • KWest says:

            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.

          • charliex says:

            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.

      • I once wrote a DBC parser in Python. It wasn’t too bad, since the format is ASCII based. Unfortunately, I lost it in a drive failure… this is before I learned that Git is a good thing.

      • matt says:

        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.

        • fartface says:

          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.

      • smiler says:

        Check out Busmaster if you want a free CAN tool that can handle .dbc files. You need a pro hardware interface to use it though.

    • Depending on the OEM, canbushack.org (not affiliated with these guys) has some good tips. Madox.net has Mazda info, Swedespeed for Volvo, …

  2. nickpl says:

    Your (link) is missing the link:
    “Last time (link), we discussed…”

  3. Chris says:

    Really looking forward to the rest of this! Cant wait to have a play with CAN

  4. denis says:

    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.

  5. elwarpismo says:

    Also forgot to add the break. Although to be honest, I kinda like the idea of first article always being fully displayed…hmmmm

  6. 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:

    http://can-newsletter.org/assets/files/ttmedia/raw/30e0cfdc05de5f831221487388087eb8.pdf

    http://www.vector.com/portal/medien/cmc/events/commercial_events/VectorCongress_2012/VeCo12_8_NewBusSystems_3_Lindenkreuz_Lecture.pdf

  7. Pascal K says:

    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…

  8. Maokai says:

    Looking forward for more of this stuff. Thumbs up.
    Also, why on earth is there an emergency stop on top of his dashboard?

  9. Anybodysguess says:

    Why is there no break?

  10. Vic says:

    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.

    • flndr says:

      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.

  11. Trav says:

    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….

    • Oh, you’ve just reminded me that I should talk about how CAN is wired in a future post. Usually the DB9 connectors use pin 7 for CAN+ and pin 2 for CAN-.

      • Joel says:

        HSCAN is also standardized in pins 6 and 14 on vehicles with an OBDII connector (and that have an HSCAN network of course!)

      • ET says:

        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.

  12. rogier21 says:

    How did you plugin the CANbus on the car? I assume it’s all well protected?

  13. techb says:

    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.

  14. Squirrel says:

    Next up, MIL-STD-1553?

  15. rich says:

    There is basic info on the standardised OBD diagnostics parameters here.

    http://en.m.wikipedia.org/wiki/OBD-II_PIDs

    If your looking to play around it is a good place to start.

  16. charliex says:

    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.

  17. 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.

  18. rfdude says:

    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.

  19. luke says:

    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.

  20. denizcan says:

    Isn’t the single wire one LINBUS? If it is, they are totally different kind of toys..

  21. run_oh says:

    EcoCAR!

  22. Riccar says:

    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, (http://www.ebay.com/itm/09-10-Ford-Fusion-Infomation-Screen-Monitor-9E5T-19C116-AE-Bulk-4018-/360840349186?_trksid=p2054897.l4276)
    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?

  23. Sven says:

    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..

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

Follow

Get every new post delivered to your Inbox.

Join 94,095 other followers