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.
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.
We’re introducing a new series on CAN and automotive hacking. First, we’ll introduce CAN and discuss how in-vehicle networks work.
In 1986, Bosch introduced the Controller Area Network protocol. It was designed specifically for in-vehicle networks between automotive controllers. CAN became a popular option for networking controllers in automotive, industrial, and robotics applications. Starting in 2008, all vehicles sold in the US must use CAN.
Modern vehicles are distributed control systems, with controllers designed to handle specific tasks. For example, a door control module would take care of locks and windows. CAN allows these controllers to communicate. It also allows for external systems to perform diagnostic tasks by connecting to the in-vehicle network.
Some examples of CAN communication in a vehicle include:
The engine control module sending the current engine speed to the instrument cluster, where it is displayed on a tachometer.
The driver’s door controller sending a message to another door controller to actuate the window.
A firmware upgrade for a controller, sent from a diagnostics tool.
CAN is usually used with little or no security, except for the obscurity of the communications. We can use CAN to USB interfaces to listen to the traffic, and then decode it. We can also use these tools to send forged messages, or to perform diagnostic actions. Unfortunately, most of the tools for dealing with CAN are proprietary, and very expensive. The diagnostics protocols are standards, but not open ones. They must be purchased from the International Organization for Standardization.
Next time, we’ll get into the structure of CAN frames, and how traffic is encoded on the bus.
Originally he wanted to use a Raspberry Pi board for the project, but the incredible backorder situation with that hardware led him to grab an old router. After loading OpenWRT he started working out how to connect a couple of ICs (MCP2515 and MCP2551) that will take care of the CAN bus communications. The hardware connections end up being pretty simple, with five data lines (and their pull-up resistors) connecting to the router’s serial header. From there it was a matter of mapping the device in software so that the hardware can be controlled over the network.
We like this example since CAN is used is a lot of other applications.
The can used in this project was actually sardines in tomato sauce, but the former contents are moot. The can serves as a steam chamber for the sterling engine. A cam rod, piston, and valve are all fashioned from paperclips, along with the support structure that holds them in place. Inside the can is a damp sponge. When an alcohol lamp is placed beneath the can it heats the water air inside, which creates pressure on the piston, pushing it up until the cam opens the valve, relieving pressure just in time for the cycle to start over again. Momentum is a necessary part of the mechanism and that’s where the CD fly-wheel comes in. See it chugging along in the clip after the break.
Update: Corrected spelling thanks to [Chris Muncy] and removed references to water/steam thanks to this comment from [Khordas].
This is not a Roomba hack, but a ground-up vacuum cleaner robot build. It’s the result of a class project from six students at the Royal Institute of Technology in Sweden. There’s a slew of information available in their paper, but fair warning that it’s an 8.6 MB PDF file that we couldn’t get Google to translate. We were able to skim the PDF and cut and paste to translate the interesting bits we found.
Unlike a Roomba, which just uses a little sweeper to pick up debris, this robot actually includes a vacuum. The image above shows that the cylindrical body is wrapped in an LED matrix, with an ultrasonic sensor on the front for obstacle avoidance. The robot uses a CAN bus to control the various modules inside. We don’t think there’s any autonomous function, but that’s made up for by the remote control. It communicates via a ZigBee module, and includes a d-pad, touch screen, and accelerometer.We’re a little bit hazy on how the games are played, but there are at least two interactive version: one called ball, and another modeled after the classic game of missile command.
You can make those buttons on your steering wheel much more functional if you have a way of monitoring them. Don’t even think of cracking open the factory finish to get to the solder points, just tap into the CAN bus and monitor the data traffic.
The small board seen above is the result of a project [Peter Shabino] calls the CAN sniffer. The connector on the left will plug into the Control Area Network system on your car, giving the chips on board something to do. There’s an MCP2551 CAN transceiver (hidden under that linear regulator) and an SPI controlled MCP2515 CAN controller which take care of the particulars of the CAN protocol. The big chip in the middle is a PIC 16F876, responsible for making sense out of the data. From there a MAX232 chip is used to provide a serial interface to connect the device to a computer.
This really isn’t tied down to one particular function. Once you have access to the bus for a microcontroller you’ll only be limited by your firmware writing skills. [Peter] has posted an archive with all of the open source files, as well as an illustrated step-by-step board assembly. We’ve embedded the schematic from that archive after the break. Continue reading “CAN sniffing for steering wheel button presses”→
Tomorrow a team of researchers will present their paper on Experimental Security Analysis of a Modern Automobile (PDF) at the IEEE Symposium on Security & Privacy. Much like the racing simulators we’ve seen they’re exploiting the ODB-II port to get at the vehicle’s Controller-area network, or CAN-bus. We’re not surprised at all that they can display custom text on the dashboard display or read sensor data from the car. What does surprise us is their exposé on how truly unsecured the system is. It seems that access to any device on the CAN-bus gives them unobstructed control of the car’s systems. Any device can send commands to any other device. They’ve even found a way to write malicious code to the car’s computer which can be programmed to erase itself in the event of a crash.
Much like RFID the security risks here are basically nill for the vast majority of consumers. We just find it a bit surprising that there’s apparently been little thought put into fortifying the communications between the safety systems such as the brakes on the vehicle. For instance, team experimented with sending random packets over the CAN-bus and stumbled across a way to lock the brake on just one wheel. To us it’s conceivable that a malfunctioning device on the network could start sending out damaged packets and cause a dangerous malfunction like this one.
The 14-page PDF linked above is a page-turner, check it out on your hacked ereader during lunch.