An Introduction to the CAN Bus: How to Programmatically Control a Car | Hacker News Reader

An Introduction to the CAN Bus: How to Programmatically Control a Car

news.voyage.auto

317 pointsolivercameron104 comments

CAN Bus is great. I highly recommend reading the CAN Open Spec if your going to be implementing new systems using CAN Bus.

https://en.wikipedia.org/wiki/CANopen

Many more things besides auto's use CAN. One of my current projects involves exercise equipment that internally speaks CAN Bus. There is great support in Arduino for interfacing with stuff like this.

At a previous job I interfaced with hospital beds that used CAN Bus internally. Turns out that Ford had laid off a lot of engineers a few years ago and the firm hired some of them to design the next generation bed. They knew CAN Bus, so they used it to control the hydraulics, pneumatics, lift motors, strain gauges, and so on.

Man, that's really cool. I'm really looking forward to all of this CAN Bus stuff being EOL in 10-25 years so I can get my hands on it at tinker with it.

There are used beds that use the bus available on eBay and other auction sites. Be aware that it's only on their high-end beds, If you're looking to bid on one, know that they weigh over 600 lbs and need wide doorways (ask me how I know..) Current prices are $900 and up, and often don't come with the inflatable mattresses (hospital may not want the potential biohazard liability, so disposes of it first).

Thanks for the tips. I would almost definitely just stash it in my garage while I took it apart.

That actually sounds perfect for a project I've been working on. I think changing your environment really helps with thinking, so I added wheels to my desk/workbench at home. I've been trying to find parts that are inexpensive, reliable, and have enough torque to move an entire workbench, but they are near impossible to find.

My first goal is to add automated raising and lowering of the table surface so I can switch from sitting to standing. Then I want to replace the casters with actual motorized wheels. The plan is to run the whole thing on a bunch of 18650s and use that as my UPS for the electronics on my workbench as well.

Plus I think it would be hilarious to build a desk that you can control from afar, since you have to be at one to use it anyways.

> they weigh over 600 lbs and need wide doorways

Spot the Orderly?

We would occasionally get a new model delivered by truck. The one door between the lab and the elevator was a normal (narrow) door. So we'd have to lift the bed onto it's side and maneuver it through. So that's how I know how much they weigh and that they need wide doors. :)

The bizarre story was we had an employee that was diabetic, and she passed out one day. When the paramedics arrived, they found her already sitting in a hospital bed.

Isn't CAN very limited in terms of bandwidth? Seems like this wouldn't be appropriate for most applications of interest? When I worked at an equipment manufacturer, everyone was very concerned about accidentally saturating the bus, and we even had a very compact data representation.

CAN-FD raised the baud rate to 12mbit. Honestly, in my applications where I have idiotic ascii logs transmitted over CAN due to management idiots, I've only managed to saturate reception buffers rather than the bus.

Noone ever talks about the very significant downsides of CAN:

- CAN is very slow despite high baudrates. As used in automotive max 40% of all bits are actual databits. That value is for frames with 8 bytes. For 4 bytes that drops to 25% so people avoid these frames. That means in practice one gets only 1500 frames/s at a typical 250kbps.

- a roundtrip takes 2 frames because the CAN request frame is broken to the point that standards like J1939 do not use it.

- CAN-B error detection mechanism has holes in it due to bit-stuffing. Effectively the CRC is circumvented, so error detection rates are nowhere near the projections made in the design documents.

- CAN-FD increases the payload, stuffing 5x (typical) more databits in the same frame. That means bits are transmitted at only 22% of the datarate, worse for higher datarates, much worse for frames with only 8 bytes. CAN-FD hardly improves latency or the frame-rate, but it does much improve error-detection rates.

So the take-away here is, yes, CAN sucks, quite badly. CAN-FD improvements really only suit niche applications.

It is possible to do much better and achieve roughly 4x the CAN-B performance (on metrics such as throughput, latency and robustness (all of them)), on the same bus.

Some systems do up to 1mbps. MIDI for example is nowhere near this. It's not the right protocol for media or bandwidth intensive applications but for control systems or reading sensors its often enough.

> but for control systems or reading sensors its often enough.

But not for the self-driving car generation, where the sensors are higher-bandwidth.

As I recall, Mobileye worked around this by just putting the detection intelligence with the camera and sending back synthetic data.

Next stop after can/flexray is EtherCat!

It varies with length of the connection, if it's short fire it up to 1 mbps or higher. Your speed gets lower as distance gets further

500kbps is typical. That's not super-slow, IMO.

It can also operate at 1Mbps.

There's a relatively recent extension called CAN FD that can go faster, as can the FlexRay protocol, which is sometimes used instead of CAN.

CAN frames are not standardized. You cannot have a single command to do operations on any car. Each manufacturer has different bit patterns and also it varies between car models. Atleast with Chrylsers I know its true. There should be a lookup based on the car's model with a unified API which I think will happen soon based on the pace of car tech progress. Also note that once the frame is on the bus, it get executed and an ACK will be sent. There is no authentication mechanism in place. So once you put a frame into the CAN bus, there is no way to stop it. This will be the top pain points for car techs to fix.

Ya know Ford supports all this in the open right

http://openxcplatform.com/

Does that work only on US cars or internationally?

http://openxcplatform.com/hardware/vehicles.html says: "All Vehicles Sold in the U.S. Since 2008 (OBD-II on CAN)"

Ford runs a "World car" strategy so I'd expect the same thing to work internationally. OBD-II is a worldwide standard AFAIK too.

https://en.wikipedia.org/wiki/World_car

So this not that thrilling but my BMW r1200gs has this bus. I dropped the bike recently and killed one of the turn signals. Canbus lit up saying you have a light out. I fixed the turn signal and it still lit up. I thought I needed to reset it or something.

Turns out I killed the headlight in the drop as well. Without the canbus it would have been months before I would have caught that. I thought it was a BMW over-the-top thing but it actually helped me, it was the daylight running headlight that went out. Good to have that one.

Like I said, not thrilling, not programming, but an upvote for the Canbus.

My riding school was big on checklisting the bike before every ride: indicators front and back, low beam, high beam, brake light by the lever and the footbrake, horn. Not thrilling either but it's how I found out about my busted horn and busted brake light switch promptly instead of the hard way. In most places riding in traffic is risky enough that it's worth knowing all the bits are working every time.

If you want to see what's possible with a BMW r1200gs CAN Bus hacking have a look here: https://www.youtube.com/watch?v=FJ6LvHBWGio http://www.pouet.net/prod.php?which=69676

CAN is just the communication protocol. The diagnostics just ride on top of it.

Good talk from pycon 2017 on hacking the CAN:

https://www.youtube.com/watch?v=3bZNhMcv4Y8

Can you imagine the havok when terrorists figure out they can program cars to hunt and kill pedestrians in crowded spaces? Currently the terrorist needs to drive the vehicle, which makes it a suicide mission. How much more deadly would it be if it was reduced to just the cost of the car and a low chance of getting caught? How can we defend against this?

You can't. It's not that hard to make a controller that lets you physically turn the wheel using an RC remote, it's just a matter of attaching a servo to some cords pulling it (there's a guide on Instructables).

The reason terrorists don't do that has nothing to do with being hard.

> It's not that hard to make a controller that lets you physically turn the wheel using an RC remote

> The reason terrorists don't do that has nothing to do with being hard.

This is false. Remote-controlled VBIEDs are absolutely a thing

Um.... reread that comment. He's saying that VBIEDs are totally possible, and that this example of CAN Bus control isn't going to cause a new era of terrorist actions, because it's just as easy to do it with servos and/or ropes and cables.

What he's saying is not false.

What he's saying is that terrorists are doing it. Not that it's a potential thing, but that there are war zones where it is happening.

There was a problem in Edmonton ~10 years ago, where criminals would steal a car to get part way home in the winter. Then, they would convert it to a land missile, and launching it across a parking lot, into a mall, in the middle of the night.

Their solution was much simpler: secure the wheel using the seatbelts, jam a big snowball on the accelerator, and use a stick to nudge the transmission from neutral to drive.

You can already do that. How do you think stunt cars work?

just throw in a off the shelf servo to control the steering wheel and two more to run the brakes and gas. Throw in a off the shelf RC controller and you got yourself a giant RC car.

Probably faster than trying to hack a car when you got a perfectly good no authentication interface.

I'm more concerned about the concurrent trends for (a) remotely accessible systems in vehicles, for communication or otherwise, and (b) critical vehicle systems being connected via relatively insecure internal networking to each other and to something remotely accessible.

Put another way, it's not a hostile actor remotely controlling their own vehicle that worries me the most, it's the potential for a hostile actor to identify a vulnerability that lets them remotely control many other people's vehicles simultaneously.

It's also the lack of any way for even a relatively discerning customer looking for a new car to determine how likely any potential purchase is to be vulnerable to such an attack and how likely the manufacturer would be to anticipate and/or respond to such a vulnerability.

Given the generally awful attitude of the auto industry to safety and generally poor processes for handling even recalls for widespread and acknowledged mechanical failures, buying a new car is not looking like a happy experience any time soon.

There are an infinite number of ways that "terrorists can kill people". Remote control cars is only one of them and probably nowhere near the top of the list.

We defend against killer-remote-control-cars like we defend against all forms of terrorism: plain old police and intelligence work to snatch the perps before they have a chance to strike.

I'd argue that a lot of terrorists don't care. They want to do it themselves, die in the process and be glorified by their own. Otherwise they would probably just hide bombs somewhere to detonate them instead of strapping them onto themselves.

Well, humans are capable of improvising better than something automated or pre-positioned. That's the biggest reason. Second, for the terrorist organization itself, people are probably close to free assets (you just brainwash a few more), whereas spending a lot of R&D on developing an automated explosive delivery system and then continuing to patch vulnerabilities in it that governments would use to neutralize it would cost exponentially more.

tl;dr: If you don't care about the sanctity of life, humans are cheap.

Ransomeware devs on the other hand...

I have a hard time imagining self-driving cars merely negotiating the traffic I drive in each day much less deal with the myriad foreign policy and security issues that have led us to this point in time. Imagine the lawsuits if it can ever be proved that a murder was committed by someone hacking an automobile--and I do suspect it has already happened. The drive-by-wire gas pedal and shifter in my car cause me concern. We need better low-tech kill switches and backup mechanisms and way less reliance on fancy tech.

Also, there is no connection between "hacking" the CAN bus in today's cars and doing anything like providing access to adjust the A/C blower level in some future self-driving livery mobile. Why anyone would think there would be even the remotest connection between how CAN bus works today and how some future consumer-oriented interface would work demonstrates dangerous naviete.

The self driving car doesn't need to be perfect, it needs to be better than humans. That is a much lower bar. Self driving cars have already demonstrated their ability to handle traffic better than humans, but there are other situations where they are much worse.

The issue is not even with self-driving, this concerns any "connected" car. Remember the chrome box? (a device from the ancient era of phreaking, allowing to control traffic lights - some of them had an external input only protected by obfuscation, intended for prioritizing emergency vehicles) Is it so hard to imagine an external controller for all the other networked cars out there? (Remember, there are many ways a modern car is networked, some of them wireless - the FM radio is plugged into a CAN, and has digital data band; how does that sound?) Full control not necessary - just annoy the driver sufficiently to make them get out of the road (e.g. full throttle AC plus force hazard lights on).

Yeah, that's the problem. It's easier to be better than humans 95% of the time, but really hard for the next 4% and close to impossible for the last 1.

The way we always defend a network--authentication and encryption.

If your CAN nodes are all authenticated to one another, it's a lot harder to hack.

The downside is that they're a lot harder to hack, in the good sense of the term.

>If your CAN nodes are all authenticated to one another, it's a lot harder to hack.

The problem with that is now how do you do the legitimate good things you want to do? Of course, these kinds of locks usually have their own problems and usually only keep "honest folks" out.

John Deere would love it though.

https://copyright.gov/1201/2015/comments-032715/class%2021/J...

A car could be self-driven while not connecting to any external networks. It still can get fresh traffic or weather data, but with those, you can't take over a car to make it a weapon.

As long as there's no parsing bugs in the traffic data module or the weather display that can be leveraged into an exploit, ala CVE-2012-1457 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1457

Think Reflected XSS: weaponized string hidden in map data (road name even) in advance, is unwittingly integrated into offline map, triggers when a self-driving car tries to parse the data for that road segment, using a vulnerable library. Antyhing that uses network-contributed data is network-connected, even if the link is currently inactive (Case in point: Stuxnet).

Love CAN, beautifully simple. Of course the "arbitration id" needs to be unique to an ECU, but each can send multiple different ones - the purpose of the ID is to always send the one with the lowest number. When designing the system, this ID defines the priority of each message - e.g. brake lights are more important than radio volume up :)

Hmm, I hope they're not planning on using ROS for the final product... using a non-hard-realtime OS to fully control a car is a spectacularly bad idea.

A bit of a nitpick, but ROS is not an OS, it is a middleware. Who knows, maybe somebody makes a ROS adaptation for a hard-realtime POSIX OS, would be totally possible.

Though I agree, ROS is nowhere near the stability level needed by industrial and automotive products. It's great for prototyping, but one has to keep in mind the inevitable refactoring of the communication layer, and keep the core functionality ROS-independent.

Nvidia drive PX2 uses QNX, I think for an open source solution someone should try to figure out a solution with sel4 running on RISC-V so there could be a full proof that the system supports hard realtime.

So is making a car so hard to work on that it has to go back to the dealership just to change out a dead bulb.

Definitely on the roadmap. See ghs.com.

One of the reasons I pulled my OnStar module from my GM Vehicle... Lack of authentication in the GMLAN CAN network. Not a big deal for an isolated system (well, almost isolated, there's still the FM radio) but "isolated enough" to mitigate casual attacks.

"we flipped the problem (and the OBD-II port) inside out and found naked access to HS1, HS2, HS3 and MS. The solution was on the back of the OBD-II port where all those buses arrive to a device called the Gateway Module."

This seems like a critical hack. Is this normal of all (non-ford) cars as well?

I'm gonna guess Car mfg's are going to start encrypting the CAN bus [1].

[1]: http://www.eetimes.com/document.asp?doc_id=1328081

Unfortunately it's pretty much industry standard that once you have physical access to the relevant CAN bus you can read (and write) everything. The normal protection which is mostly deployed is that the end-user only has access to the CAN bus on the ODB2 interface, which is behind a gateway and should not expose safety critical things. Some car manufacturers however might also only use a single CAN bus for everything, just to save the cost for the gateway.

I'm pretty sure we will see encryption in the future. But currently I'm only aware of efforts for authenticating CAN (and other signal based) communication. If anybody is interested, look for Autosar SecOC module. I'm not too deeply into it, but if it prevents tempering around with the system (like shown in the linked article) it's already a way forward.

"Unfortunately"? I get what you're saying, but encryption will just mean that hobbyists will be completely locked out of everything. It's not like the manufacturers will go through the trouble of making it possible for a car owner to decrypt the bus traffic in their own car.

You can always DoS a node by forcing it into the bus off state with an error flag whenever it transmits. Allows plenty of mayhem without needing to break any authentication.

> This seems like a critical hack. Is this normal of all (non-ford) cars as well?

There is naked access to CAN all over the vehicle, it only firewalls the OBDII port because it's function is primarily to observe the vehicle (error codes, states, etc) with small exceptions such as clearing codes.

CANbus is also on boats and in industrial automation! The physical connectors follow the DeviceNet spec.

Marine applications use a subset of CANbus (with mainly DeviceNet micro connectors) named NMEA 2000. The best repo to get started is probably https://github.com/ttlappalainen/NMEA2000

Interesting - never realized there would be multiple CAN buses in a car. That probably makes it a lot easier to not screw things up - if you know that the medium speed bus is only connected to non-safety-critical systems, then it's easier to trust that when you send out your hand-crafted CAN packets, you're not going to cause anything too drastic to happen.

Indeed. Especially important when you remember that most of the (many!) devices in a car sitting on CAN buses come from outside suppliers, and black-box testing of these modules can only go so far to verify the CAN implementation and stability.

AFAIK, Ford actually mandates that their suppliers use a standard CAN stack provided/licensed by Ford (FNOS, the Ford Network Operating System) to try and ensure a level of quality in implementations. It's a good idea, one I haven't heard of other automakers doing (although I'm not in the industry any more)

My inner five year old hopes that FNOS was developed by the Ford Network Operating Research Division.

Yes, we need property testing of this stuff to become the norm.

https://erlangcentral.org/videos/testing-automotive-software... http://www.cs.tufts.edu/~nr/cs257/archive/john-hughes/quviq-...

Security (or safety) is one reason for multiple CAN buses. Another is saturation of the bus (too many messages).

You want to keep "unimportant" (think radio) away from "important" (drive train). Also, there are only so many IDs you can use.

Unfortunately, the lines are increasingly blurred. The days when you could separate basic driving mechanics like steering, acceleration and braking from other controls, sensors and remote inputs are fast disappearing into history.

Not all automakers do this. There are vehicles where the obd-ii port has access to the main CAN bus.

CANBus is also used on spacecraft to communicate between payloads and the on-board computer. Sometimes it is used in concert with MilBus 1553 as the payloads and sensors are acquired from various sources. I believe that work is being done to standardise to one solution, but in the meantime we end up programming for both!

Reversing this stuff is a big pain in the back. I'm doing Ford (Mercury) dash display controller as my free time pet project and it's only by reverse engineering the protocol. I'm mimicking stock headunit and collect data from MS CAN. But need to admit, that there's lots of logic in the protocol, so can be reverse engineered with brains.

Some pics and text (sorry, Russian only for now)

https://www.drive2.ru/l/474473078441641818/

https://www.drive2.ru/l/473379614127816994/

This controller operates when stock headunit is removed and can print out on the stock dash display (FDIM) the following info:

- clock (can be taken from 2010+ GPSM module or from external RTC clock - DS3231 based) - tire pressure (from broadcasts 2010+ or from Ford TPMS protocol 2008+) - tire temp (from TPMS protocol) - RPM - engine temp - current speed

units are configurable (12/24h clock, psi/kpa pressure, C/F temperature)

Probably will share code and PCBs on github soon, now this thingy is under heavy test in my car and other cars of some enthusiastic guys

There are plans to extend the device with CAN proxy to allow it to work together with stock headunit and also sit on both HS and MS can buses to get more data do display

In the last picture in the blog post, does he really run a script for Celsius? Because at 67 degrees you are certainly dead! :D

I was using F, good catch :)

Why would you be dead at 67 celsius..? I go in to a room near 100 Celsius every weekend (also known as sauna)

Huh, this made me curious about saunas and how they're survivable if they're that hot, since I've never been in one myself. Apparently the air inside saunas is very dry (making sweating very effective), even though they're traditionally pictured as being steamy? Would I be right in saying there's very little air movement in one, as well? I'm guessing there's a lot of boundary layer type effects going on.

Edit: The Wikipedia entry's description makes no sense. The hottest saunas have low humidity levels produced by pouring water on hot stones? And the people in the sauna are below the dew point and so have condensation forming on them rather than evaporating? How then do they shed the heat?

If you bring a glass of water with you, does it boil?

Are there more books or sites about car hacking except "The Car Hacker’s Handbook"? This is very interesting topic.

Sure.

https://www.youtube.com/watch?v=MEYCU62yeYk and the mentioned paper i assume is https://ioactive.com/pdfs/IOActive_Remote_Car_Hacking.pdf

Q: What is a good simulator for car hacking?

I expected to find some vehicle simulator that allows me to load several car specs, similar to a flight simulator. Plus integration of some advanced racing / driving software - I could not find any of these, but I am not an expert in this field.

Where to find these? THANKS!

There are some great tools here to get you started:

https://github.com/zombieCraig

Craig Smith also released a book-length treatment of the subject online for free, the Car Hacker's Handbook, available here:

http://opengarages.org/handbook/

Yep, the post author calls it his favorite book and links to it in the article, specifically discussing the topic of Chapter 2 on Bus protocols.

Ok, just to clarify... the CAN bus protocol can not be used to control throttle, brakes or steering. Critical stuff like that must be feedback driven.

Most manufacturers have their own communication protocol (some on top of the CAN bus). Probably the most researched and hacked bus out there is BMW's I-BUS (Used in MINI, BMW and Range Rover) [1].

You can however flash the ECU through most CAN buses (not in the protocol, but info about it can be found for most cars). And from there, one can interfere with the throttle.

[1] https://groups.yahoo.com/neo/groups/HackTheIBus

Wrong, on certain cars it can be used to control all three.

https://github.com/commaai/openpilot

Okay, cool! Do you know of any more than Honda and Tesla?

I wonder - did you try to ask Ford for a .dbc-file containing the desired IDs to query? It's worth a shot plus those files save a ton of time.

IIRC, US Law mandates a bunch of CAN IDs for general engine diagnostics like fuel flow, o2 sensors, etc.

The rest of the CAN IDs are unique to every manufacturer. GM (for instance) Tech Scan tool knows these CAN IDs. Independent 3rd parties can develop a simliar tool and license the CAN IDs from GM for a hefty fee. I imagine Ford has the same service available.

Would it be possible to feed CAN IDs to Tech Scan tool sequentially and thus decode their meaning? Would it be legal?

Easier to bribe some intern or entry-level engineer who has the excel file mapping all the signals from every module on the bus. These used to be passed around pretty openly at the suppliers I worked for, and interns started out making something like $11.50/hr with no benefits.

Might be easier to dump the scan tools firmware. Both are probably about the same legality! :D

I have been trying to find one for the Ford Fusion but no luck. So I put together a github project where each can code is a github issue. https://github.com/autti/abraham/issues/45.

Is that really the kind of file Ford would just hand out? Seems like it could really up their liability if there was a CAN related vuln found via that handout

Ford is more open about vehicle info than any other carmaker I can think of (see http://openxcplatform.com), but that's not saying much, and I don't think they would give out dbc files without a lot of lawyers being involved.

Does anybody know where the trend is going? Do electric cars have standard buses or are they moving to proprietary (and not published) buses?

CAN will stay for quite a while, as will LIN. However, higher speed buses (esp. FlexRay and MOST) are very, very slowly being replaced by Automotive Ethernet (which uses a proprietary physical layer, called BroadR-Reach). Where CAN used checksums (additional, application layer checksum in addition to the protocol layer) to prevent tampering (modifying live data), the Ethernet based protocols will use what AUTOSAR calls Secure On-Board communication, which features ECU-to-ECU end to end protection.

That's all true. Just two few to add:

While CAN and LIN are used everywhere Flexray and MOST are used in different domains: Flexray for driving/safety related functions and MOST for infotainment.

CAN will have a speed improved version CAN FD, which might see a lot of use in the more driving related ECUs - some say it might replace FlexRay uses there.

Afaik SecOC can and will be used for all kinds of PDU based communication (Ethernet and CAN). The amount of PDUs which will be transmitted over Ethernet vs. classical bus systems will very heavily from OEM to OEM. Some are more invested in Ethernet, others not.

Oh interesting. I left the car industry when flexray was the newest bus available and MOST wast only used by Audi (for their backseat screens or some such entertainment systems). The problem with flexray was that it was supposed to be reliable with redundant cabling, but manufacturers immediately turned around to use redundancy to double the bandwidth.

Yes, Tesla still uses CAN buses. It has 6 buses if I remember correctly.

True, but bear in mind, the dashboard CAN bus port itself provides almost no access at all, and Tesla actually monitors their cars so they can call and threaten anyone who tries to connect to the actual diagnostics ports, which require a bit more work to get into.

http://jalopnik.com/the-tesla-model-s-is-basically-a-good-lo...

You're thinking of the ODB II port, which has basically nothing in the Tesla. The CAN bus located under the cid actually has everything that goes through the car, it simply has a proprietary connector. There's also an ethernet port with a proprietary 4 pin connector, which is locked down by default.

They haven't pulled that shit of calling people in a while.

Yeah, although it is wrong, I've been known to refer to the OBD2 port as a CAN port.

They may not be calling people, but you'd better believe they're still monitoring them.

I am wondering whether is there a truck that have drive by wire? That would be interesting. Monster Self Driving Truck.

All the big John Deere tractors are drive by wire. The steering wheel has no mechanical connection to the wheels. We (I'm an employee of Deere, though of course I don't speak for them) do some things I cannot talk about to verify that only authorized devices can steer the tractors. How to do this has been given to at least one university interested in self driving tractors - after verifying they will take care of that knowledge (exactly what this means I don't know)

For quite some time, trucks have been where ADAS systems were first deployed in production (ACC, lane departure detection).

Reply on news.ycombinator.com