Hacker News new | ask | show | jobs
by cdtwoaway 2614 days ago
Not surprised. I built automotive test benches for some time. The moment you have something that can remote-access the CAN-bus, you have a problem.

There are typically only a few busses in a car. In many cases, there is a LIN bus for entertainment / radio / lights etc that is physically separated from the main CAN bus. This one is mostly harmless.

But if you can somehow talk to the main bus... There are like 5 critical ECUs that have to communicate "I'm OK" (engine, breaks etc) - otherwise nothing works. Those communicate with some minor encryption, and that communication is somewhat validated (they send counters to each other etc). But it doesn't matter. First of all, the protocols and databases are similar for different models, and known to A LOT of people who had jobs similar to mine. In order to test or build any ECU, you have to simulate the correct communication, otherwise the ECU won't start up.. Second, just sending nonsense with the right identifier could probably shut down the car or at least make it think there is a major problem. Third, there are messages that simulate power-cycling the bus..

3 comments

Scary stuff. We connected light bulbs to the internet so people could turn them on and off with their phones, and they were hacked and turned into a botnet[1]. Okay, fine, maybe your "smart" bulbs blink or burn out, and you replace them with "dumb" bulbs.

Why, exactly, do people think it's a good idea to connect cars' engines to the internet? If something is exposed to hostile input, it will eventually be hacked, and if there are 100,000 identical things out there, they will all be hacked at once. Unfortunately, I think it will take something like all Teslas accelerating uncontrollably off the road, because some teenager was bored, for people to get it.

[1] https://www.techdirt.com/articles/20161107/09211835982/not-e...

All governments are essentially mandating connected cars effective 2020 model year.

As hybrid and electrics take root, mileage and location based metering/taxation will become a major revenue source.

In the past, requirements for new cars were not retroactively applied to previous year models. Are you saying that is/will be changing?
My guess is that in a decade you’ll be using an OBD device for time and distance based metering, or pay a heavy surcharge for LPR based location only systems.

Transponder systems like EZPass have a business model too expensive to scale.

If the LIN bus can access lights, and is bundled up with IMHO unrelated systems like radio/entertainment then that seems wrong by design. I say this as if somebody can remotely control your lights on a car, that in itself at the wrong time could and would prove dangerous.
Lights for instrumentation (inside the car). At least on the systems I worked with. I'm not much of an expert on that bus.

Well, messing with this bus (audio volume.. blinking displays etc) could be disruptive as well, but not as critical as killing the engine.

I had a read up upon LIN https://en.wikipedia.org/wiki/Local_Interconnect_Network

Was introduced as a cheaper alternative to CAN, and to be used for non-critical aspects of cars (intended). Though seat controls are listed as common use for it. Which with some occupants and cars with the seatbelt - would enable the seat to pull the driver away from the controls. So whilst not directly deemed critical - certainly a vector of concern in some permutations of seat/driver position (thinking large 4x4's driven by small people who end up having the seat fully forward and raised, as an example).

My initial concern was the main lights, though as you cleared that up to just internal lighting - that again could prove a problem as dark roads, a sudden change in internal lighting would from internal glare reduce visibility.

Biggest take away is that the LIN bus has no form of encryption and the only verification would be checksums upon the data packet.

I'm sure we will read more about LIN over the years as the ability for car makers to cut-corners is not unheard of and as LIN is cheaper to implement than CAM, can see how that may well play out.

>Though seat controls are listed as common use for it. Which with some occupants and cars with the seatbelt - would enable the seat to pull the driver away from the controls. So whilst not directly deemed critical - certainly a vector of concern in some permutations of seat/driver position (thinking large 4x4's driven by small people who end up having the seat fully forward and raised, as an example).

Combine seat adjustment with GPS position reporting and you could devise a way to make a targeted person lose control, without taking control of "critical" systems, exactly as they're crossing a bridge.

Suddenly I feel the urge to Faraday-cage my car.

I expect we will see that in a movie/thriller next year
I work in one of the big 3's there is significant push to physically isolate all the CAN buses. The guys that hacked into Jeep were ex-NSA and worked on the hack for more than a year to get it to work. I'm not saying cars are 100% secure, but this sort of attack will take crazy effort and maybe physical access to the car.
Hey that's interesting, most of these devices IIRC work via the OBD port with an additional cutoff wiring. I haven't looked but I'm assuming the OBD port is somewhat restricted?
Really depends on the vehicle. Some will have broadcast traffic that is easier to spoof, and ride on CAN addresses that aren't reserved for OBD. OBD quite often rides on the main CAN network, and without a gateway any ECU can be queried. The secondary CAN network (if the vehicle has one) is also on the OBD plug but on different pins.
Yip. And if you can query any ECU, and know what you are doing/have more information on the system, you can get higher level security access (and that information, is again, not THAT hard to find). This allows you to call functions that modify the parameters and probably restart it as well..
Precisely. It's also interesting to see what you can do with vehicles where the broadcast traffic 'leaks' out the OBD port. A lot of makes use the same ECU across models for common parts.
It would be simple to have hardware that can only use the K-line (which is diagnostic only) or even only uses power from the OBD2 connector.

But you could also design your hardware to be able to write messages on the CAN bus and/or be able to take the bus down.

Literally: I have successfully sent CAN messages that were understandable to ECUs with an Arduino while waiting for a delivery of real hardware. There are Arduino-GSM shields that are super easy to use and would be remote-accessible.

Such a device would be dead easy to build even for someone who has almost no experience in electronics.

You can also buy plenty of development boards with an ESP32 and a CAN transceiver. Small, fully programmable, with Wifi and BLE, for less than $50.