There was a time not too long ago when hacking a car more often than not involved literal hacking. Sheet metal was cut, engine cylinders were bored, and crankshafts were machined to increase piston travel. It was all in the pursuit of milking the last ounce performance out of every drop of gasoline, along with a little personal expression in the form of paint and chrome.
While it’s still possible — and encouraged — to hack cars thus, the inclusion of engine control units and other systems to our rides has created an entirely different universe of car hacking options, which Amith Reddy distilled into his very popular workshop at the 2020 Remoticon. The secret sauce behind all the hacks you can accomplish in today’s drive-by-wire cars is the Controller Area Network (CAN), the network used to connect the array of sensors, actuators, and controllers that lie under the metal and plastic of modern cars.
The bulk of Amith’s workshop centered on how to receive and interpret CAN bus packets. The toolchain included can-utils, a collection of tools for inspecting and manipulating CAN packets, and ICSim, which simulates a generic car instrument cluster graphically. Using these, workshop participants were able to play with the virtual dashboard, open and close virtual doors, and observe the CAN packets responsible for it all as they fly across the network.
With the basics out of the way, the workshop moved on to real-world implementations of CANbus hacking, including tools to tap into the network via a car’s Onboard Diagnostics (OBD) port. There can be significant challenges here, including the dangers inherent when working with any large, powerful machine. The workshop page has all the details of what’s needed to get started, and the video of the workshop will take you the rest of the way safely.
I have a question related to a real car scenario.
CAN communication in cars also utilise the feature of CRC, which provides message integrity.
1. So what happens when we send a message without a CRC, i.e. a raw CAN frame.? Would the receiving ECU just reject the whole CAN frame or still process it?
The background is that once we decode the CAN IDs from the recorded log, we can use a spoof ECU to send raw CAN messages(without CRC). Does this work in a real car?
2. Sniffing the CAN bus, provides us with CAN data, as well the CRC. Now that we have these 2 information, can we reverse engineer to find out the CRC polynomial used? If so, how can we do it? If the CRC polynomial can be found out, we can easily send spoofed messages (with correct CRC) and hijack the whole car.
I’ve been having a play with my car recently ( 2008 Chrysler grand voyager) and have not had an my issue with CRC – it has been quiet similar to using the simulator.
I have been looking at accessories like the radio and Bluetooth connectivity.
You can have a look at my ramblings here
https://hackaday.io/project/175751-bluetooth-for-2008-chrysler-grandvoyager
Your CAN controller will compute the check sum for you…
If you are bit bagging CAN then you will need to compute the check sum per the Bosch CAN standard:
X15 + X14 + X10 + X8 + X7 + X4 + X3 + 1
An improper CAN checksum will cause the receiving device to not-acknowledge, this will cause an automatic retransmission of the CAN message from the sending device.
However, this depends on how the sending / receiving device is set up.
You can chose to have the sending device not compute a check sum.
You can chose to have the receiving device ignore the check sum error and acknowledge the message anyway.
And you can chose to have the sending device not retransmit not-acknowledged packets.
But these modes are typically for the generation of bad CAN messages for network testing purposes.
This man is Not a Legend,
He’s all Reddy Amith…
(big smile!)
(I was thinking along the lines of “A Mith(lisp) Reddy”)
@Wolf,
1. Considering as a hacker, the internal setup of ECUs wil not be known. it is almost like a black box.
Is the polynomial you mentioned above as per Bosch standard valid across all cars? So in case I have reverse engineered some of the CAN IDs and respective data(as mentioned in this blog), and with the standard CRC polynomial the spoofed ECU can send legit messages on the bus. Is this understanding correct?
2. Do the OEMs tweak more the CRC polynomial, or is it worth trying with the standard polynomial that you mentioned above?
3. I also read about CRC routines in Autosar specification, which talks about CRC for communication between ECUs. But it also states that it’s not the CAN CRC. This confuses me a bit.
The CAN protocol has a built in CRC checksum.
The manufacturer can also use some of the CAN data bytes to implement their own CRC check sum, this is mostly used to make sure someone does not tamper with the data in the packets. ;)
But with enough sniffed messages you can reverse engineer the CRC polynomial…
This is how I reverse engineer the CRC polynomials:
https://youtu.be/g8ydgU9fdx4
This example is for the LIN bus, but it would be exactly the same for CAN bus or any other protocol that has a CRC polynomial checksum.
I have worked with some european OEMs on projects with both CAN and LIN communication and can give you some insight.
1. CRC protected frames (CRC data byte – do not confuse with CAN frame checksum) can use any polynom the OEM wants. Usually these frames have a rolling counter that will affect the CRC seed (seed based on counter value). There are different handlings that OEMs prefer, based on the criticality of the data. Usually you discard the frame with incorrect CRC and will set an error when multiple consecutive frames are received. If data is not critical, you may also consider some of it, if CRC is wrong.
2. Sniffing the CAN data is useful but it’s a complicated and long process, since you will need to make physical actions to have a lot of values on the signals in the CAN frame. We managed to control the steering and breaking of a car by fiddling with it and gathering a lot of data, without reverse engineering the CRC. We got whole frames, stored them and just send them as we saw them on the bus (every signal combinations, for every rolling counter value – it was dumb, but we were young and didn’t like math). This is complicated, because the physical node is still there and sending data. that’s why we had to take out the break and steering wheel sensor from the loop and inject our data there, not on the OBD.
And an extra one:
3. OBD port SHOULD NOT access the internal CAN buses. Each can bus should be a closed loop and OBD is managed by a gateway that SHOULD ONLY ACCEPT frames that are used in the UDS protocol. So basically OBD can be used to spy but not inject periodic or sporadic frames.
Good part is that you can always CAN databases on russian websites, since SW developers are hackers (and sometimes dicks). VAG really had it bad when all their internal tools were leaked and now VAG cars are the most hackable.
Grey-box testing.
https://en.wikipedia.org/wiki/Gray_box_testing
“…milking the last ounce performance out of every drop of gasoline”
Are you sure?
As I percieve the “car hackers”, it rather was/is “to increase performance thru the ceiling for quicker reach of refuelling” as in “fuel efficiency is for whimps”.
Some of us (me anyway) view as increased fuel economy AS increased performance.
B^)
Why isn’t there a device that can replace onstar remote lock feature ?
The onboard box must send an unlock command to the door locks right ?
Any references out there on how this is accomplished ? (and how to emulate it using a home brew device)
get a canbus shield and arduino, tap into the canbus from the device of interest, write a small sketch to dump can output to the terminal. adjust the canbus speed etc untill you dont get garbage (same as trying to find an unknown serial port speed) then dump to file and dont carry out the action of interest, then dump to file and DO canrry out the action of interest. compare the difference.
this is how I emulated all the steering and i-drive controls in my bmw (now has a raspi + openauto rather than the I-Drive) the only gotcha is with something like central locking you will need to also be able to wake the bus up from a sleep, this may require more steps.
what BMW model/year do you have?