Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.voyage.auto

Post reply on HN
Print view View original

81–90 of 110 posts

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

#81

Post by Silhouette »

eloff wrote: post #10

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?

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.

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

#82

Post by Silhouette »

muro wrote: post #6
camtarn wrote: post #2

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.

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.

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

#83

Post by mabcat »

luckydude wrote: post #51

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…

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.

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

#84

Post by Braxton_Hicks »

tylero wrote: post #78

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.

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

#85

Post by AceJohnny2 »

spotman wrote: post #66
weberc2 wrote: post #50

Earlier quoted context omitted.

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.

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.

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

#86

Post by diydsp »

weberc2 wrote: post #50
spotman wrote: post #37

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.

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.

Next stop after can/flexray is EtherCat!

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

#87

Post by Mtntk »

weberc2 wrote: post #50
spotman wrote: post #37

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.

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.

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

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

#88

Post by Matheus28 »

ocdtrekkie wrote: post #63
Matheus28 wrote: post #53

Earlier quoted context omitted.

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.

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

#89

Post by kevin_thibedeau »

Matthias247 wrote: post #68
pj_mukh wrote: post #39

"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_…

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

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.

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

#90

Post by delfinom »

weberc2 wrote: post #50
spotman wrote: post #37

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.

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.
Post reply on HN