THE CAR HACKER’S HANDBOOK A Guide for the Penetration Tester Craig Smith San Francisco

THE CAR HACKER’S HANDBOOK. Copyright © 2016 by Craig Smith. All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher. 20 19 18 17 16 1 2 3 4 5 6 7 8 9 ISBN-10: 1-59327-703-2

ISBN-13: 978-1-59327-703-1 Publisher: William Pollock

Production Editor: Laurel Chun

Cover Illustration: Garry Booth

Interior Design: Octopod Studios

Developmental Editors: Liz Chadwick and William Pollock

Technical Reviewer: Eric Evenchick

Copyeditor: Julianne Jigour

Compositor: Laurel Chun

Proofreader: James Fraleigh

Indexer: BIM Indexing & Proofreading Services The following code and images are reproduced with permission: Figures 5-3 and 5-7 © Jan-Niklas Meier; Figures 6-17 and 6-18 © Matt Wallace; Figures 8-6, 8-7, 8-8, and 8-20 © NewAE Technology Inc.; Brute-forcing keypad entry code on pages 228–230 © Peter Boothe; Figures 13-3 and A-6 © Jared Gould and Paul Brunckhorst; Figures A-1 and A-2 © SECONS Ltd., http://www.obdtester.com/pyobd/; Figure A-4 © Collin Kidder and EVTV Motor Werks. For information on distribution, translations, or bulk sales, please contact No Starch Press, Inc. directly:

No Starch Press, Inc.

245 8th Street, San Francisco, CA 94103

phone: 415.863.9900; info@nostarch.com

www.nostarch.com Library of Congress Cataloging-in-Publication Data Names: Smith, Craig (Reverse engineer), author.

Title: The car hacker's handbook: a guide for the penetration tester / by Craig Smith.

Description: San Francisco : No Starch Press, [2016] | Includes index.

Identifiers: LCCN 2015038297| ISBN 9781593277031 | ISBN 1593277032

Subjects: LCSH: Automotive computers--Security measures--Handbooks, manuals,

etc. | Automobiles--Performance--Handbooks, manuals, etc. |

Automobiles--Customizing--Handbooks, manuals, etc. | Penetration testing

(Computer security)--Handbooks, manuals, etc. |

Automobiles--Vandalism--Prevention--Handbooks, manuals, etc.

Classification: LCC TL272.53 .S65 2016 | DDC 629.2/72--dc23

LC record available at http://lccn.loc.gov/2015038297 No Starch Press and the No Starch Press logo are registered trademarks of No Starch Press, Inc. Other product and company names mentioned herein may be the trademarks of their respective owners. Rather than use a trademark symbol with every occurrence of a trademarked name, we are using the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The information in this book is distributed on an “As Is” basis, without warranty. While every precaution has been taken in the preparation of this work, neither the author nor No Starch Press, Inc. shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in it.

About the Author Craig Smith (craig@theialabs.com) runs Theia Labs, a security research firm that focuses on security auditing and building hardware and software prototypes. He is also one of the founders of the Hive13 Hackerspace and Open Garages (@OpenGarages). He has worked for several auto manufacturers, where he provided public research on vehicle security and tools. His specialties are reverse engineering and penetration testing. This book is largely a product of Open Garages and Craig’s desire to get people up to speed on auditing their vehicles.

About the Contributing Author Dave Blundell (accelbydave@gmail.com) works in product development, teaches classes, and provides support for Moates.net, a small company specializing in pre-OBD ECU modification tools. He has worked in the aftermarket engine management sphere for the past few years, doing everything from reverse engineering to dyno tuning cars. He also does aftermarket vehicle calibration on a freelance basis.

About the Technical Reviewer Eric Evenchick is an embedded systems developer with a focus on security and automotive systems. While studying electrical engineering at the University of Waterloo, he worked with the University of Waterloo Alternative Fuels Team to design and build a hydrogen electric vehicle for the EcoCAR Advanced Vehicle Technology Competition. Currently, he is a vehicle security architect for Faraday Future and a contributor to Hackaday. He does not own a car.

FOREWORD The world needs more hackers, and the world definitely needs more car hackers. Vehicle technology is trending toward more complexity and more connectivity. Combined, these trends will require a greater focus on automotive security and more talented individuals to provide this focus. But what is a hacker? The term is widely corrupted by the mainstream media, but correct use of the term hacker refers to someone who creates, who explores, who tinkers—someone who discovers by the art of experimentation and by disassembling systems to understand how they work. In my experience, the best security professionals (and hobbyists) are those who are naturally curious about how things work. These people explore, tinker, experiment, and disassemble, sometimes just for the joy of discovery. These people hack. A car can be a daunting hacking target. Most cars don’t come with a keyboard and login prompt, but they do come with a possibly unfamiliar array of protocols, CPUs, connectors, and operating systems. This book will demystify the common components in cars and introduce you to readily available tools and information to help get you started. By the time you’ve finished reading the book, you’ll understand that a car is a collection of connected computers—there just happen to be wheels attached. Armed with appropriate tooling and information, you’ll have the confidence to get hacking. This book also contains many themes about openness. We’re all safer when the systems we depend upon are inspectable, auditable, and documented—and this definitely includes cars. So I’d encourage you to use the knowledge gained from this book to inspect, audit, and document. I look forward to reading about some of your discoveries! Chris Evans (@scarybeasts) January 2016

ACKNOWLEDGMENTS Thanks to the Open Garages community for contributing time, examples, and information that helped make this book possible. Thanks to the Electronic Frontier Foundation (EFF) for supporting the Right to Tinker and just generally being awesome. Thanks to Dave Blundell for contributing several chapters of this book, and to Colin O’Flynn for making the ChipWhisperer and letting me use his examples and illustrations. Finally, thanks to Eric Evenchick for single-handedly reviewing all of the chapters of this book, and special thanks to No Starch Press for greatly improving the quality of my original ramblings.

1

UNDERSTANDING THREAT MODELS If you come from the software penetrationtesting world, you’re probably already familiar with attack surfaces. For the rest of us, attack surface refers to all the possible ways to attack a target, from vulnerabilities in individual components to those that affect the entire vehicle. When discussing the attack surface, we’re not considering how to exploit a target; we’re concerned only with the entry points into it. You might think of the attack surface like the surface area versus the volume of an object. Two objects can have the same volume but radically different surface areas. The greater the surface area, the higher the exposure to risk. If you consider an object’s volume its value, our goal in hardening security is to create a low ratio of risk to value. Finding Attack Surfaces When evaluating a vehicle’s attack surface, think of yourself as an evil spy who’s trying to do bad things to a vehicle. To find weaknesses in the vehicle’s security, evaluate the vehicle’s perimeter, and document the vehicle’s environment. Be sure to consider all the ways that data can get into a vehicle, which are all the ways that a vehicle communicates with the outside world. As you examine the exterior of the vehicle, ask yourself these questions: • What signals are received? Radio waves? Key fobs? Distance sensors? • Is there physical keypad access? • Are there touch or motion sensors? • If the vehicle is electric, how does it charge? As you examine the interior, consider the following: • What are the audio input options: CD? USB? Bluetooth? • Are there diagnostic ports? • What are the capabilities of the dashboard? Is there a GPS? Bluetooth? Internet? As you can see, there are many ways data can enter the vehicle. If any of this data is malformed or intentionally malicious, what happens? This is where threat modeling comes in. Threat Modeling Entire books have been written about threat modeling, but I’m going to give you just a quick tour so you can build your own threat models. (If you have further questions or if this section excites you, by all means, grab another book on the subject!) When threat modeling a car, you collect information about the architecture of your target and create a diagram to illustrate how parts of the car communicate. You then use these maps to identify higher-risk inputs and to keep a checklist of things to audit; this will help you prioritize entry points that could yield the most return. Threat models are typically made during the product development and design process. If the company producing a particular product has a good development life cycle, it creates the threat model when product development begins and continuously updates the model as the product moves through the development life cycle. Threat models are living documents that change as the target changes and as you learn more about a target, so you should update your threat model often. Your threat model can consist of different levels; if a process in your model is complicated, you should consider breaking it down further by adding more levels to your diagrams. In the beginning, however, Level 2 is about as far as you’ll be able to go. We’ll discuss the various levels in the following sections, beginning with Threat Level 0. Level 0: Bird’s-Eye View At this level, we use the checklist we built when considering attack surfaces. Think about how data can enter the vehicle. Draw the vehicle in the center, and then label the external and internal spaces. Figure 1-1 illustrates a possible Level 0 diagram. The rectangular boxes are the inputs, and the circle in the center represents the entire vehicle. On their way to the vehicle, the inputs cross two dotted lines, which represent external and internal threats. The vehicle circle doesn’t represent an input but rather a complex process—that is, a series of tasks that could be broken down further. Processes are numbered, and as you can see, this one is number 1.0. If you had more than one complex piece in your threat model, you would number those in succession. For instance, you would label a second process 2.0; a third, 3.0; and so on. As you learn about your vehicle’s features, you update the diagram. It’s okay if you don’t recognize all of the acronyms in the diagram yet; you will soon. Figure 1-1: Level 0 inputs Level 1: Receivers To move on to the Level 1 diagram, pick a process to explore. Because we have only the one process in our diagram, let’s dig in to the vehicle process and focus on what each input talks to. The Level 1 map shown in Figure 1-2 is almost identical to that in Level 0. The only difference is that here we specify the vehicle connections that receive the Level 0 input. We won’t look at the receivers in depth just yet; we’re looking only at the basic device or area that the input talks to. Figure 1-2: Level 1 map of inputs and vehicle connections Notice in Figure 1-2 that we number each receiver. The first digit represents the process label from the Level 0 diagram in Figure 1-1, and the second digit is the number of the receiver. Because the infotainment unit is both a complex process and an input, we’ve given it a process circle. We now have three other processes: immobilizer, ECU, and TPMS Receiver. The dotted lines in the Level 1 map represent divisions between trust boundaries. The inputs at the top of the diagram are the least trusted, and the ones at the bottom are the most trusted. The more trust boundaries that a communication channel crosses, the more risky that channel becomes. Level 2: Receiver Breakdown At Level 2, we examine the communication taking place inside the vehicle. Our sample diagram (Figure 1-3) focuses on a Linux-based infotainment console, receiver 1.1. This is one of the more complicated receivers, and it’s often directly connected to the vehicle’s internal network. In Figure 1-3, we group the communications channels into boxes with dashed lines to once again represent trust boundaries. Now there’s a new trust boundary inside the infotainment console called kernel space. Systems that talk directly to the kernel hold higher risk than ones that talk to system applications because they may bypass any access control mechanisms on the infotainment unit. Therefore, the cellular channel is higher risk than the Wi-Fi channel because it crosses a trust boundary into kernel space; the Wi-Fi channel, on the other hand, communicates with the WPA supplicant process in user space. Figure 1-3: Level 2 map of the infotainment console This system is a Linux-based in-vehicle infotainment (IVI) system, and it uses parts common to a Linux environment. In the kernel space, you see references to the kernel modules udev, HSI, and Kvaser, which receive input from our threat model. The udev module loads USB devices, HSI is a serial driver that handles cellular communication, and Kvaser is the vehicle’s network driver. The numbering pattern for Level 2 is now X.X.X, and the identification system is the same as before. At Level 0, we took the vehicle process that was 1.0 and dove deeper into it. We then marked all processes within Level 1 as 1.1, 1.2, and so on. Next, we selected the infotainment process marked 1.1 and broke it down further for the Level 2 diagram. At Level 2, therefore, we labeled all complex processes as 1.1.1, 1.1.2, and so on. (You can continue the same numbering scheme as you dive even deeper into the processes. The numbering scheme is for documentation purposes; it allows you to reference the exact process at the appropriate level.) NOTE Ideally at this stage, you’d map out which processes handle which inputs, but we’ll have to guess for now. In the real world, you’d need to reverse engineer the infotainment system to find this information. When building or designing an automotive system, you should continue to drill down into as many complex processes as possible. Bring in the development team, and start discussing the methods and libraries used by each application so you can incorporate them into their own threat diagrams. You’ll likely find that the trust boundaries at the application level will usually be between the application and the kernel, between the application and the libraries, between the application and other applications, and even between functions. When exploring these connections, mark methods that have higher privileges or that handle more sensitive information. Threat Identification Now that we’ve gone two levels deep into our threat modeling maps, we can begin to identify potential threats. Threat identification is often more fun to do with a group of people and a whiteboard, but you can do it on your own as a thought exercise. Let’s try this exercise together. Start at Level 0—the bird’s-eye view—and consider potential high-level problems with inputs, receivers, and threat boundaries. Now let’s list all potential threats with our threat models. Level 0: Bird’s-Eye View When determining potential threats at Level 0, try to stay high level. Some of these threats may seem unrealistic because you’re aware of additional hurdles or protections, but it’s important to include all possible threats in this list, even if some have already been addressed. The point here is to brainstorm all the risks of each process and input. The high-level threats at Level 0 are that an attacker could: • Remotely take over a vehicle • Shut down a vehicle • Spy on vehicle occupants • Unlock a vehicle • Steal a vehicle • Track a vehicle • Thwart safety systems • Install malware on the vehicle At first, it may be difficult to come up with a bunch of attack scenarios. It’s often good to have people who are not engineers also participate at this stage because as a developer or an engineer, you tend to be so involved in the inner workings that it’s natural to discredit ideas without even meaning to. Be creative; try to come up with the most James Bond–villain attack you can think of. Maybe think of other attack scenarios and whether they could also apply to vehicles. For example, consider ransomware, a malicious software that can encrypt or lock you out of your computer or phone until you pay money to someone controlling the software remotely. Could this be used on vehicles? The answer is yes. Write ransomware down. Level 1: Receivers Threat identification at Level 1 focuses more on the connections of each piece rather than connections that might be made directly to an input. The vulnerabilities that we posit at this level relate to vulnerabilities that affect what connects to the devices in a vehicle. We’ll break these down into threat groupings that relate to cellular, Wi-Fi, key fob (KES), tire pressure monitor sensor (TPMS), infotainment console, USB, Bluetooth, and controller area network (CAN) bus connections. As you can see in the following lists, there are many potential ways into a vehicle. Cellular An attacker could exploit the cellular connection in a vehicle to: • Access the internal vehicle network from anywhere • Exploit the application in the infotainment unit that handles incoming calls • Access the subscriber identity module (SIM) through the infotainment unit • Use a cellular network to connect to the remote diagnostic system (OnStar) • Eavesdrop on cellular communications • Jam distress calls • Track the vehicle’s movements • Set up a fake Global System for Mobile Communications (GSM) base station Wi-Fi An attacker could exploit the Wi-Fi connection to: • Access the vehicle network from up to 300 yards away or more • Find an exploit for the software that handles incoming connections • Install malicious code on the infotainment unit • Break the Wi-Fi password • Set up a fake dealer access point to trick the vehicle into thinking it’s being serviced • Intercept communications passing through the Wi-Fi network • Track the vehicle Key Fob An attacker could exploit the key fob connection to: • Send malformed key fob requests that put the vehicle’s immobilizer in an unknown state. (The immobilizer is supposed to keep the vehicle locked so it can’t be hotwired. We need to ensure that it maintains proper functionality.) • Actively probe an immobilizer to drain the car battery • Lock out a key • Capture cryptographic information leaked from the immobilizer during the handshake process • Brute-force the key fob algorithm • Clone the key fob • Jam the key fob signal • Drain the power from the key fob Tire Pressure Monitor Sensor An attacker could exploit the TPMS connection to: • Send an impossible condition to the engine control unit (ECU), causing a fault that could then be exploited • Trick the ECU into overcorrecting for spoofed road conditions • Put the TPMS receiver or the ECU into an unrecoverable state that might cause a driver to pull over to check for a reported flat or that might even shut down the vehicle • Track a vehicle based on the TPMS unique IDs • Spoof the TPMS signal to set off internal alarms Infotainment Console An attacker could exploit the infotainment console connection to: • Put the console into debug mode • Alter diagnostic settings • Find an input bug that causes unexpected results • Install malware to the console • Use a malicious application to access the internal CAN bus network • Use a malicious application to eavesdrop on actions taken by vehicle occupants • Use a malicious application to spoof data displayed to the user, such as the vehicle location USB An attacker could use a USB port connection to: • Install malware on the infotainment unit • Exploit a flaw in the USB stack of the infotainment unit • Attach a malicious USB device with specially crafted files designed to break importers on the infotainment unit, such as the address book and MP3 decoders • Install modified update software on the vehicle • Short the USB port, thus damaging the infotainment system Bluetooth An attacker could use a Bluetooth connection to: • Execute code on the infotainment unit • Exploit a flaw in the Bluetooth stack of the infotainment unit • Upload malformed information, such as a corrupted address book designed to execute code • Access the vehicle from close ranges (less than 300 feet) • Jam the Bluetooth device Controller Area Network An attacker could exploit the CAN bus connection to: • Install a malicious diagnostic device to send packets to the CAN bus • Plug directly in to a CAN bus to attempt to start a vehicle without a key • Plug directly in to a CAN bus to upload malware • Install a malicious diagnostic device to track the vehicle • Install a malicious diagnostic device to enable remote communications directly to the CAN bus, making a normally internal attack now an external threat Level 2: Receiver Breakdown At Level 2, we can talk more about identifying specific threats. As we look at exactly which application handles which connection, we can start to perform validation based on possible threats. We’ll break up threats into five groups: Bluez (the Bluetooth daemon), the wpa_supplicant (the Wi-Fi daemon), HSI (high-speed synchronous interface cellular kernel module), udev (kernel device manager), and the Kvaser driver (CAN transceiver driver). In the following lists, I’ve specified threats to each program. Bluez Older or unpatched versions of the Bluez daemon: • May be exploitable • May be unable to handle corrupt address books • May not be configured to ensure proper encryption • May not be configured to handle secure handshaking • May use default passkeys wpa_supplicant • Older versions may be exploitable • May not enforce proper WPA2 style wireless encryption • May connect to malicious access points • May leak information on the driver via BSSID (network interface) HSI • Older versions may be exploitable • May be susceptible to injectable serial communication (man-in-the-middle attacks in which the attacker inserts serial commands into the data stream) udev • Older, unpatched versions may be susceptible to attack • May not have a maintained whitelist of devices, allowing an attacker to load additional drivers or USB devices that were not tested or intended for use • May allow an attacker to load foreign devices, such as a keyboard to access the infotainment system Kvaser Driver • Older, unpatched versions may be exploitable • May allow an attacker to upload malicious firmware to the Kvaser device These lists of potential vulnerabilities are by no means exhaustive, but they should give you an idea of how this brainstorming session works. If you were to go to a Level 3 map of potential threats to your vehicle, you would pick one of the processes, like HSI, and start to look at its kernel source to identify sensitive methods and dependencies that might be vulnerable to attack. Threat Rating Systems Having documented many of our threats, we can now rate them with a risk level. Common rating systems include DREAD, ASIL, and MIL-STD-882E. DREAD is commonly used in web testing, while the automotive industry and government use ISO 26262 ASIL and MIL-STD-882E, respectively, for threat rating. Unfortunately, ISO 26262 ASIL and MIL-STD-882E are focused on safety failures and are not adequate to handle malicious threats. More details on these standards can be found at http://opengarages.org/index.php/Policies_and_Guidelines. The DREAD Rating System DREAD stands for the following: Damage potential How great is the damage? Reproducibility How easy is it to reproduce? Exploitability How easy is it to attack? Affected users How many users are affected? Discoverabilty How easy is it to find the vulnerability? Table 1-1 lists the risk levels from 1 to 3 for each rating category. Table 1-1: DREAD Rating System Rating category High (3) Medium (2) Low (1) D Damage potential Could subvert the security system and gain full trust, ultimately taking over the environment Could leak sensitive information Could leak trivial information R Reproducibility Is always reproducible Can be reproduced only during a specific condition or window of time Is very difficult to reproduce, even given specific information about the vulnerability E Exploitability Allows a novice attacker to execute the exploit Allows a skilled attacker to create an attack that could be used repeatedly Allows only a skilled attacker with in-depth knowledge to perform the attack A Affected users Affects all users, including the default setup user and key customers Affects some users or specific setups Affects a very small percentage of users; typically affects an obscure feature D Discoverability Can be easily found in a published explanation of the attack Affects a seldom-used part, meaning an attacker would need to be very creative to discover a malicious use for it Is obscure, meaning it’s unlikely attackers would find a way to exploit it Now we can apply each DREAD category from Table 1-1 to an identified threat from earlier in the chapter and score the threat from low to high (1–3). For instance, if we take the Level 2 HSI threats discussed in “Level 2: Receiver Breakdown” on page 10, we can come up with threat ratings like the ones shown in Table 1-2. Table 1-2: HSI Level 2 Threats with DREAD Scores HSI threats D R E A D Total An older, unpatched version of HSI that may be exploitable 3 3 2 3 3 14 An HSI that may be susceptible to injectable serial communication 2 2 2 3 3 12 You can identify the overall rating by using the values in the Total column, as shown in Table 1-3. Table 1-3: DREAD Risk Scoring Chart Total Risk level 5–7 Low 8–11 Medium 12–15 High When performing a risk assessment, it’s good practice to leave the scoring results visible so that the person reading the results can better understand the risks. In the case of the HSI threats, we can assign high risk to each of these threats, as shown in Table 1-4. Table 1-4: HSI Level 2 Threats with DREAD Risk Levels Applied HSI threats D R E A D Total Risk An older, unpatched version of HSI that may be exploitable 3 3 2 3 3 14 High An HSI that may be susceptible to injectable serial communication 2 2 2 3 3 12 High Although both risks are marked as high, we can see that the older version of the HSI model poses a slightly higher risk than do the injectable serial attacks, so we can make it a priority to address this risk first. We can also see that the reason why the injectable serial communication risk is lower is that the damage is less severe and the exploit is harder to reproduce than that of an old version of HSI. CVSS: An Alternative to DREAD If DREAD isn’t detailed enough for you, consider the more detailed risk methodology known as the common vulnerability scoring system (CVSS). CVSS offers many more categories and details than DREAD in three groups: base, temporal, and environmental. Each group is subdivided into sub areas—six for base, three for temporal, and five for environmental—for a total of 14 scoring areas! (For detailed information on how CVSS works, see http://www.first.org/cvss/cvss-guide.) NOTE While we could use ISO 26262 ASIL or MIL-STD-882E when rating threats, we want more detail than just Risk = Probability × Severity. If you have to pick between these two systems for a security review, go with MIL-STD-882E from the Department of Defense (DoD). The Automotive Safety Integrity Level (ASIL) system will too often have a risk fall into the QM ranking, which basically translates to “meh.” The DoD’s system tends to result in a higher ranking, which equates to a higher value for the cost of a life. Also, MIL-STD-882E is designed to be applied throughout the life cycle of a system, including disposal, which is a nice fit with a secure development life cycle. Working with Threat Model Results At this point, we have a layout of many of the potential threats to our vehicle, and we have them ranked by risk. Now what? Well, that depends on what team you’re on. To use military jargon, the attacker side is the “red team,” and the defender side is the “blue team.” If you’re on the red team, your next step is to start attacking the highest risk areas that are likely to have the best chance of success. If you’re on the blue team, go back to your risk chart and modify each threat with a countermeasure. For example, if we were to take the two risks in “The DREAD Rating System” on page 11, we could add a countermeasure section to each. Table 1-5 includes the countermeasure for the HSI code execution risk, and Table 1-6 includes the countermeasure for the risk of HSI interception. Table 1-5: HSI Code Execution Risk Threat Executes code in the kernel space Risk High Attack technique Exploit vulnerability in older versions of HSI Countermeasures Kernel and kernel modules should be updated with the latest kernel releases Table 1-6: Intercepting HSI Commands Threat Intercepts and injects commands from the cellular network Risk High Attack technique Intercept serial communications over HSI Countermeasures All commands sent over cellular are cryptographically signed Now you have a documented list of high-risk vulnerabilities with solutions. You can prioritize any solutions not currently implemented based on the risk of not implementing that solution. Summary In this chapter you learned the importance of using threat models to identify and document your security posture, and of getting both technical and nontechnical people to brainstorm possible scenarios. We then drilled down into these scenarios to identify all potential risks. Using a scoring system, we ranked and categorized each potential risk. After assessing threats in this way, we ended up with a document that defined our current product security posture, any countermeasure currently in place, and a task list of high-priority items that still need to be addressed.

2

BUS PROTOCOLS In this chapter, we’ll discuss the different bus protocols common in vehicle communications. Your vehicle may have only one of these, or if it was built earlier than 2000, it may have none. Bus protocols govern the transfer of packets through the network of your vehicle. Several networks and hundreds of sensors communicate on these bus systems, sending messages that control how the vehicle behaves and what information the network knows at any given time. Each manufacturer decides which bus and which protocols make the most sense for its vehicle. One protocol, the CAN bus, exists in a standard location on all vehicles: on the OBD-II connector. That said, the packets themselves that travel over a vehicle’s CAN bus aren’t standardized. Vehicle-critical communication, such as RPM management and braking, happens on high-speed bus lines, while noncritical communication, such as door lock and A/C control, happens on mid- to low-speed bus lines. We’ll detail the different buses and protocols you may run across on your vehicle. To determine the bus lines for your specific vehicle, check its OBD-II pinout online. The CAN Bus CAN is a simple protocol used in manufacturing and in the automobile industry. Modern vehicles are full of little embedded systems and electronic control units (ECUs) that can communicate using the CAN protocol. CAN has been a standard on US cars and light trucks since 1996, but it wasn’t made mandatory until 2008 (2001 for European vehicles). If your car is older than 1996, it still may have CAN, but you’ll need to check. CAN runs on two wires: CAN high (CANH) and CAN low (CANL). CAN uses differential signaling (with the exception of low-speed CAN, discussed in “The GMLAN Bus” on page 20), which means that when a signal comes in, CAN raises the voltage on one line and drops the other line an equal amount (see Figure 2-1). Differential signaling is used in environments that must be fault tolerant to noise, such as in automotive systems and manufacturing. Figure 2-1: CAN differential signaling Figure 2-1 shows a signal captured using a PicoScope, which listens to both CANH (darker lines at the top of the graph) and CANL (lighter lines at the bottom of the graph). Notice that when a bit is transmitted on the CAN bus, the signal will simultaneously broadcast both 1V higher and lower. The sensors and ECUs have a transceiver that checks to ensure both signals are triggered; if they are not, the transceiver rejects the packet as noise. The two twisted-pair wires make up the bus and require the bus to be terminated on each end. There’s a 120-ohm resistor across both wires on the termination ends. If the module isn’t on the end of the bus, it doesn’t have to worry about termination. As someone who may tap into the lines, the only time you’ll need to worry about termination is if you remove a terminating device in order to sniff the wires. The OBD-II Connector Many vehicles come equipped with an OBD-II connector, also known as the diagnostic link connector (DLC), which communicates with the vehicle’s internal network. You’ll usually find this connector under the steering column or hidden elsewhere on the dash in a relatively accessible place. You may have to hunt around for it, but its outline looks similar to that in Figure 2-2. Figure 2-2: Possible locations of the OBD-II connector In some vehicles, you’ll find these connectors behind small access panels. They’ll typically be either black or white. Some are easy to access, and others are tucked up under the plastic. Search and you shall find! Finding CAN Connections CAN is easy to find when hunting through cables because its resting voltage is 2.5V. When a signal comes in, it’ll add or subtract 1V (3.5V or 1.5V). CAN wires run through the vehicle and connect between the ECUs and other sensors, and they’re always in dual-wire pairs. If you hook up a multimeter and check the voltage of wires in your vehicle, you’ll find that they’ll be at rest at 2.5V or fluctuating by 1V. If you find a wire transmitting at 2.5V, it’s almost certainly CAN. You should find the CANH and CANL connections on pins 6 and 14 of your OBD-II connector, as shown in Figure 2-3. Figure 2-3: CAN pins cable view on the OBD-II connector In the figure, pins 6 and 14 are for standard high-speed CAN lines (HS-CAN). Mid-speed and low-speed communications happen on other pins. Some cars use CAN for the mid-speed (MS-CAN) and low-speed (LS-CAN), but many vehicles use different protocols for these communications. You’ll find that not all buses are exposed via the OBD-II connector. You can use wiring diagrams to help locate additional “internal” bus lines. CAN Bus Packet Layout There are two types of CAN packets: standard and extended. Extended packets are like standard ones but with a larger space to hold IDs. Standard Packets Each CAN bus packet contains four key elements: Arbitration ID The arbitration ID is a broadcast message that identifies the ID of the device trying to communicate, though any one device can send multiple arbitration IDs. If two CAN packets are sent along the bus at the same time, the one with the lower arbitration ID wins. Identifier extension (IDE) This bit is always 0 for standard CAN. Data length code (DLC) This is the size of the data, which ranges from 0 to 8 bytes. Data This is the data itself. The maximum size of the data carried by a standard CAN bus packet can be up to 8 bytes, but some systems force 8 bytes by padding out the packet. Figure 2-4 shows the format of standard CAN packets. Figure 2-4: Format of standard CAN packets Because CAN bus packets are broadcast, all controllers on the same network see every packet, kind of like UDP on Ethernet networks. The packets don’t carry information about which controller (or attacker) sent what. Because any device can see and transmit packets, it’s trivial for any device on the bus to simulate any other device. Extended Packets Extended packets are like standard ones, except that they can be chained together to create longer IDs. Extended packets are designed to fit inside standard CAN formatting in order to maintain backward compatibility. So if a sensor doesn’t have support for extended packets, it won’t break if another packet transmits extended CAN packets on the same network. Standard packets also differ from extended ones in their use of flags. When looking at extended packets in a network dump, you’ll see that unlike standard packets, extended packets use substitute remote request (SRR) in place of the remote transmission request (RTR) with SSR set to 1. They’ll also have the IDE set to 1, and their packets will have an 18-bit identifier, which is the second part of the standard 11-bit identifier. There are additional CAN-style protocols that are specific to some manufacturers, and they’re also backward compatible with standard CAN in much the same way as extended CAN. The ISO-TP Protocol ISO 15765-2, also known as ISO-TP, is a standard for sending packets over the CAN bus that extends the 8-byte CAN limit to support up to 4095 bytes by chaining CAN packets together. The most common use of ISO-TP is for diagnostics (see “Unified Diagnostic Services” on page 54) and KWP messages (an alternative protocol to CAN), but it can also be used any time large amounts of data need to be transferred over CAN. The can-utils program includes isotptun, a proof-of-concept tunneling tool for SocketCAN that allows two devices to tunnel IP over CAN. (For a detailed explanation of how to install and use can-utils, see “Setting Up can-utils to Connect to CAN Devices” on page 36.) In order to encapsulate ISO-TP into CAN, the first byte is used for extended addressing, leaving only 7 bytes for data per packet. Sending lots of information over ISO-TP can easily flood the bus, so be careful when using this standard for large transfers on an active bus. The CANopen Protocol Another example of extending the CAN protocol is the CANopen protocol. CANopen breaks down the 11-bit identifier to a 4-bit function code and 7-bit node ID—a combination known as a communication object identifier (COB-ID). A broadcast message on this system has 0x for both the function code and the node ID. CANopen is seen more in industrial settings than it is in automotive ones. If you see a bunch of arbitration IDs of 0x0, you’ve found a good indicator that the system is using CANopen for communications. CANopen is very similar to normal CAN but has a defined structure around the arbitration IDs. For example, heartbeat messages are in the format of 0x700 + node ID. CANopen networks are slightly easier to reverse and document than standard CAN bus. The GMLAN Bus GMLAN is a CAN bus implementation by General Motors. It’s based on ISO 15765-2 ISO-TP, just like UDS (see “Unified Diagnostic Services” on page 54). The GMLAN bus consists of a single-wire low-speed and a dual-wire high-speed bus. The low-speed bus, a single-wire CAN bus that operates at 33.33Kbps with a maximum of 32 nodes, was adopted in an attempt to lower the cost of communication and wiring. It’s used to transport noncritical information for things like the infotainment center, HVAC controls, door locks, immobilizers, and so on. In contrast, the high-speed bus runs at 500Kbps with a maximum of 16 nodes. Nodes in a GMLAN network relate to the sensors on that bus. The SAE J1850 Protocol The SAE J1850 protocol was originally adopted in 1994 and can still be found in some of today’s vehicles, for example some General Motors and Chrysler vehicles. These bus systems are older and slower than CAN but cheaper to implement. There are two types of J1850 protocols: pulse width modulation (PWM) and variable pulse width (VPW). Figure 2-5 shows where to find PWM pins on the OBD-II connector. VPW uses only pin 2. Figure 2-5: PWM pins cable view The speed is grouped into three classes: A, B, and C. The 10.4Kbps speeds of PWM and VPW are considered class A, which means they’re devices marketed exclusively for use in business, industrial, and commercial environments. (The 10.4Kbps J1850 VPW bus meets the automotive industry’s requirements for low-radiating emissions.) Class B devices are marketed for use anywhere, including residential environments and have a second SAE standard implementation that can communicate at 100Kbps, but it’s slightly more expensive. The final implementation can operate at up to 1Mbps, and it’s used in class C devices. As you might expect, this third implementation is the most expensive, and it’s used primarily in real-time critical systems and media networks. The PWM Protocol PWM uses differential signaling on pins 2 and 10 and is mainly used by Ford. It operates with a high voltage of 5V and at 41.6Kbps, and it uses dual-wire differential signaling, like CAN. PMW has a fixed-bit signal, so a 1 is always a high signal and a 0 is always a low signal. Other than that, the communication protocol is identical to that of VPW. The differences are the speed, voltage, and number of wires used to make up the bus. The VPW Protocol VPW, a single-wire bus system, uses only pin 2 and is typically used by General Motors and Chrysler. VPW has a high voltage of 7V and a speed of 10.4Kbps. When compared with CAN, there are some key differences in the way VPW interprets data. For one, because VPW uses time-dependent signaling, receiving 1 bit isn’t determined by just a high potential on the bus. The bit must remain either high or low for a set amount of time in order to be considered a single 1 bit or a 0 bit. Pulling the bus to a high position will put it at around 7V, while sending a low signal will put it to ground or near-ground levels. This bus also is at a resting, or nontransmission, stage at a near-ground level (up to 3V). VPW packets use the format in Figure 2-6. Figure 2-6: VPW Format The data section is a set size—always 11 bits followed by a 1-bit CRC validity check. Table 2-1 shows the meaning of the header bits. Table 2-1: Meaning of Header Bits Header bits Meaning Notes PPP Message priority 000 = Highest, 111 = Lowest H Header size 0 = 3 bytes, 1 = single byte K In-frame response 0 = Required, 1 = Not allowed Y Addressing mode 0 = Functional, 1 = Physical ZZ Message type Will vary based on how K and Y are set In-frame response (IFR) data may follow immediately after this message. Normally, an end-of-data (EOD) signal consisting of 200μs-long low-potential signal would occur just after the CRC, and if IFR data is included, it’ll start immediately after the EOD. If IFR isn’t being used, the EOD will extend to 280μs, causing an end-of-frame (EOF) signal. The Keyword Protocol and ISO 9141-2 The Keyword Protocol 2000 (ISO 14230), also known as KWP2000, uses pin 7 and is common in US vehicles made after 2003. Messages sent using KWP2000 may contain up to 255 bytes. The KWP2000 protocol has two variations that differ mainly in baud initialization. The variations are: • ISO 14230-4 KWP (5-baud init, 10.4 Kbaud) • ISO 14230-4 KWP (fast init, 10.4 Kbaud) ISO 9141-2, or K-Line, is a variation of KWP2000 seen most often in European vehicles. K-Line uses pin 7 and, optionally, pin 15, as shown in Figure 2-7. K-Line is a UART protocol similar to serial. UARTs use start bits and may include a parity bit and a stop bit. (If you’ve ever set up a modem, you should recognize this terminology.) Figure 2-7: KWP K-Line pins cable view Figure 2-8 shows the protocol’s packet layout. Unlike CAN packets, K-Line packets have a source (transmitter) and a destination (receiver) address. K-Line can use the same or a similar parameter ID (PID) request structure as CAN. (For more on PIDs, see “Unified Diagnostic Services” on page 54.) Figure 2-8: KWP K-Line packet layout The Local Interconnect Network Protocol The Local Interconnect Network (LIN) is the cheapest of the vehicle protocols. It was designed to complement CAN. It has no arbitration or priority code; instead, a single master node does all the transmission. LIN can support up to 16 slave nodes that primarily just listen to the master node. They do need to respond on occasion, but that’s not their main function. Often the LIN master node is connected to a CAN bus. The maximum speed of LIN is 20Kbps. LIN is a single-wire bus that operates at 12V. You won’t see LIN broken out to the OBD connector, but it’s often used instead of direct CAN packets to handle controls to simple devices, so be aware of its existence. A LIN message frame includes a header, which is always sent by the master, and a response section, which may be sent by master or slave (see Figure 2-9). Figure 2-9: LIN format The SYNC field is used for clock synchroniziation. The ID represents the message contents—that is, the type of data being transmitted. The ID can contain up to 64 possibilities. ID 60 and 61 are used to carry diagnostic information. When reading diagnostic information, the master sends with ID 60 and the slave responds with ID 61. All 8 bytes are used in diagnostics. The first byte is called the node address for diagnostics (NAD). The first half of the byte range (that is, 1–127) is defined for ISO-compliant diagnostics, while 128–255 can be specific to that device. The MOST Protocol The Media Oriented Systems Transport (MOST) protocol is designed for multimedia devices. Typically, MOST is laid out in a ring topology, or virtual star, that supports a maximum of 64 MOST devices. One MOST device acts as the timing master, which continuously feeds frames into the ring. MOST runs at approximately 23 Mbaud and supports up to 15 uncompressed CD quality audio or MPEG1 audio/video channels. A separate control channel runs at 768 Kbaud and sends configuration messages to the MOST devices. MOST comes in three speeds: MOST25, MOST50, and MOST150. Standard MOST, or MOST25, runs on plastic optical fiber (POF). Transmission is done through the red light wavelength at 650 nm using an LED. A similar protocol, MOST50, doubles the bandwidth and increases the frame length to 1025 bits. MOST50 traffic is usually transported on unshielded twisted-pair (UTP) cables instead of optical fiber. Finally, MOST150 implements Ethernet and increases the frame rate to 3072 bits or 150Mbps—approximately six times the bandwidth of MOST25. Each MOST frame has three channels: Synchronous Streamed data (audio/video) Asynchronous Packet distributed data (TCP/IP) Control Control and low-speed data (HMI) In addition to a timing master, a MOST network master automatically assigns addresses to devices, which allows for a kind of plug-and-play structure. Another unique feature of MOST is that, unlike other buses, it routes packets through separate inport and outport ports. MOST Network Layers Unless your goal is to hack a car’s video or audio stream, the MOST protocol may not be all that interesting to you. That said, MOST does allow access to the in-vehicle microphone or cell system, as well as traffic information that’s likely to be of interest to malware authors. Figure 2-10 shows how MOST is divided up amongst the seven layers of the Open Systems Interconnection (OSI) model that standardizes communication over networks. If you’re familiar with other media-based networking protocols, then MOST may look familiar. Figure 2-10: MOST divided into the seven layers of the OSI model. The OSI layers are in the right column. MOST Control Blocks In MOST25, a block consists of 16 frames. A frame is 512 bits and looks like the illustration in Figure 2-11. Figure 2-11: MOST25 frame Synchronous data contains 6 to 15 quadlets (each quadlet is 4 bytes), and asynchronous data contains 0 to 9 quadlets. A control frame is 2 bytes, but after combining a full block, or 16 frames, you end up with 32 bytes of control data. An assembled control block is laid out as shown in Figure 2-12. Figure 2-12: Assembled control block layout The data area contains the FblockID, InstID, FktID, OP Type, Tel ID, Tel Len, and 12 bytes of data. FblockIDs are the core component IDs, or function blocks. For example, an FblockID of 0x52 might be the navigation system. InstID is the instance of the function block. There can be more than one core function, such as having two CD changes. InstID differentiates which core to talk to. FktID is used to query higher-level function blocks. For instance, a FktID of 0x0 queries a list of function IDs supported by the function block. OP Type is the type of operation to perform, get, set, increment, decrement, and so forth. The Tel ID and Len are the type of telegram and length, respectively. Telegram types represent a single transfer or a multipacket transfer and the length of the telegram itself. MOST50 has a similar layout to MOST25 but with a larger data section. MOST150 provides two additional channels: Ethernet and Isochronous. Ethernet works like normal TCP/IP and Appletalk setups. Isochronous has three mechanisms: burst mode, constant rate, and packet streaming. Hacking MOST MOST can be hacked from a device that already supports it, such as through a vehicle’s infotainment unit or via an onboard MOST controller. The Linux-based project most4linux provides a kernel driver for MOST PCI devices and, as of this writing, supports Siemens CT SE 2 and OASIS Silicon Systems or SMSC PCI cards. The most4linux driver allows for user-space communication over the MOST network and links to the Advanced Linux Sound Architecture (ALSA) framework to read and write audio data. At the moment, most4linux should be considered alpha quality, but it includes some example utilities that you may be able to build upon, namely: most_aplay Plays a .wav file ctrl_tx Sends a broadcast control message and checks status sync_tx Constantly transmits sync_rx Constantly receives The current most4linux driver was written for 2.6 Linux kernels, so you may have your work cut out for you if you want to make a generic sniffer. MOST is rather expensive to implement, so a generic sniffer won’t be cheap. The FlexRay Bus FlexRay is a high-speed bus that can communicate at speeds of up to 10Mbps. It’s geared for time-sensitive communication, such as drive-by-wire, steer-by-wire, brake-by-wire, and so on. FlexRay is more expensive to implement than CAN, so most implementations use FlexRay for high-end systems, CAN for midrange, and LIN for low-cost devices. Hardware FlexRay uses twisted-pair wiring but can also support a dual-channel setup, which can increase fault tolerance and bandwidth. However, most FlexRay implementations use only a single pair of wiring similar to CAN bus implementations. Network Topology FlexRay supports a standard bus topology, like CAN bus, where many ECUs run off a twisted-pair bus. It also supports star topology, like Ethernet, that can run longer segments. When implemented in the star topology, a FlexRay hub is a central, active FlexRay device that talks to the other nodes. In a bus layout, FlexRay requires proper resistor termination, as in a standard CAN bus. The bus and star topologies can be combined to create a hybrid layout if desired. Implementation When creating a FlexRay network, the manufacturer must tell the devices about the network setup. Recall that in a CAN network each device just needs to know the baud rate and which IDs it cares about (if any). In a bus layout, only one device can talk on the bus at a time. In the case of the CAN bus, the order of who talks first on a collision is determined by the arbitration ID. In contrast, when FlexRay is configured to talk on a bus, it uses something called a time division multiple access (TDMA) scheme to guarantee determinism: the rate is always the same (deterministic), and the system relies on the transmitters to fill in the data as the packets pass down the wire, similar to the way cellular networks like GSM operate. FlexRay devices don’t automatically detect the network or addresses on the network, so they must have that information programed in at manufacturing time. While this static addressing approach cuts down on cost during manufacturing, it can be tricky for a testing device to participate on the bus without knowing how the network is configured, as a device added to your FlexRay network won’t know what data is designed to go into which slots. To address this problem, specific data exchange formats, such as the Field Bus Exchange Format (FIBEX), were designed during the development of FlexRay. FIBEX is an XML format used to describe FlexRay, as well as CAN, LIN, and MOST network setups. FIBEX topology maps record the ECUs and how they are connected via channels, and they can implement gateways to determine the routing behavior between buses. These maps can also include all the signals and how they’re meant to be interpreted. FIBEX data is used during firmware compile time and allows developers to reference the known network signals in their code; the compiler handles all the placement and configuration. To view a FIBEX, download FIBEX Explorer from http://sourceforge.net/projects/fibexplorer/. FlexRay Cycles A FlexRay cycle can be viewed as a packet. The length of each cycle is determined at design time and should consist of four parts, as shown in Figure 2-13. Figure 2-13: Four parts of a FlexRay cycle The static segment contains reserved slots for data that always represent the same meaning. The dynamic segment slots contain data that can have different representations. The symbol window is used by the network for signaling, and the idle segment (quiet time) is used for synchronization. The smallest unit of time on FlexRay is called a macrotick, which is typically one millisecond. All nodes are time synced, and they trigger their macrotick data at the same time. The static section of a FlexRay cycle contains a set amount of slots to store data, kind of like empty train cars. When an ECU needs to update a static data unit, it fills in its defined slot or car; every ECU knows which car is defined for it. This system works because all of the participants on a FlexRay bus are time synchronized. The dynamic section is split up into minislots, typically one macrotick long. The dynamic section is usually used for less important, intermittent data, such as internal air temperature. As a minislot passes, an ECU may choose to fill the minislots with data. If all the minislots are full, the ECU must wait for the next cycle. In Figure 2-14, the FlexRay cycles are represented as train cars. Transmitters responsible for filling in information for static slots do so when the cycle passes, but dynamic slots are filled in on a first-come, first-served basis. All train cars are the same size and represent the time deterministic properties of FlexRay. Figure 2-14: FlexRay train representing cycles The symbol window isn’t normally used directly by most FlexRay devices, which means that when thinking like a hacker, you should definitely mess with this section. FlexRay clusters work in states that are controlled by the FlexRay state manager. According to AUTOSAR 4.2.1 Standard, these states are as follows: ready, wake-up, start-up, halt-req, online, online-passive, keyslot-only, and low-number-of-coldstarters. While most states are obvious, some need further explanation. Specifically, online is the normal communication state, while online-passive should only occur when there are synchronization errors. In online-passive mode, no data is sent or received. Keyslot-only means that data can be transmitted only in the key slots. Low-number-of-coldstarters means that the bus is still operating in full communication mode but is relying on the sync frames only. There are additional operational states, too, such as config, sleep, receive only, and standby. Packet Layout The actual packet that FlexRay uses contains several fields and fits into the cycle in the static or dynamic slot (see Figure 2-15). Figure 2-15: FlexRay packet layout The status bits are: • Reserved bit • Payload preamble indicator • NULL frame indicator • Sync frame indicator • Startup frame indicator The frame ID is the slot the packet should be transmitted in when used for static slots. When the packet is destined for a dynamic slot (1–2047), the frame ID represents the priority of this packet. If two packets have the same signal, then the one with the highest priority wins. Payload length is the number in words (2 bytes), and it can be up to 127 words in length, which means that a FlexRay packet can carry 254 bytes of data—more than 30 times that of a CAN packet. Header CRC should be obvious, and the cycle count is used as a communication counter that increments each time a communication cycle starts. One really neat thing about static slots is that an ECU can read earlier static slots and output a value based on those inputs in the same cycle. For instance, say you have a component that needs to know the position of each wheel before it can output any needed adjustments. If the first four slots in a static cycle contain each wheel position, the calibration ECU can read them and still have time to fill in a later slot with any adjustments. Sniffing a FlexRay Network As of this writing, Linux doesn’t have official support for FlexRay, but there are some patches from various manufacturers that add support to certain kernels and architectures. (Linux has FlexCAN support, but FlexCAN is a CAN bus network inspired by FlexRay.) At this time, there are no standard open source tools for sniffing a FlexRay network. If you need a generic tool to sniff FlexRay traffic, you currently have to go with a proprietary product that’ll cost a lot. If you want to monitor a FlexRay network without a FIBEX file, you’ll at least need to know the baud rate of the bus. Ideally, you’ll also know the cycle length (in milliseconds) and, if possible, the size of the cluster partitioning (static-to-dynamic ratio). Technically, a FlexRay cluster can have up to 1048 configurations with 74 parameters. You’ll find the approach to identifying these parameters detailed in the paper “Automatic Parameter Identification in FlexRay based Automotive Communication Networks” (IEEE, 2006) by Eric Armengaud, Andreas Steininger, and Martin Horauer. When spoofing packets on a FlexRay network with two channels, you need to simultaneously spoof both. Also, you’ll encounter FlexRay implementations called Bus Guardian that are designed to prevent flooding or monopolization of the bus by any one device. Bus Guardian works at the hardware level via a pin on the FlexRay chip typically called Bus Guardian Enable (BGE). This pin is often marked as optional, but the Bus Guardian can drive this pin too high to disable a misbehaving device. Automotive Ethernet Because MOST and FlexRay are expensive and losing support (the FlexRay consortium appears to have disbanded), most newer vehicles are moving to Ethernet. Ethernet implementations vary, but they’re basically the same as what you’d find in a standard computer network. Often, CAN packets are encapsulated as UDP, and audio is transported as voice over IP (VoIP). Ethernet can transmit data at speeds up to 10Gbps, using nonproprietary protocols and any chosen topology. While there’s no common standard for CAN traffic, manufacturers are starting to use the IEEE 802.1AS Audio Video Bridging (AVB) standard. This standard supports quality of service (QoS) and traffic shaping, and it uses time-synchronized UDP packets. In order to achieve this synchronization, the nodes follow a best master clock algorithm to determine which node is to be the timing master. The master node will normally sync with an outside timing source, such as GPS or (worst case) an on-board oscillator. The master syncs with the other nodes by sending timed packets (10 milliseconds), the slave responds with a delay request, and the time offset is calculated from that exchange. From a researcher’s perspective, the only challenge with vehicle Ethernet lies in figuring out how to talk to the Ethernet. You may need to make or buy a custom cable to communicate with vehicle Ethernet cables because they won’t look like the standard twisted-pair cables that you’d find in a networking closet. Typically, a connector will just be wires like the ones you find connected to an ECU. Don’t expect the connectors to have their own plug, but if they do, it won’t look like an RJ-45 connector. Some exposed connectors are actually round, as shown in Figure 2-16. Figure 2-16: Round Ethernet connectors OBD-II Connector Pinout Maps The remaining pins in the OBD-II pinout are manufacturer specific. Mappings vary by manufacturer, and these are just guidelines. Your pinout could differ depending on your make and model. For example, Figure 2-17 shows a General Motors pinout. Figure 2-17: Complete OBD pinout cable view for a General Motors vehicle Notice that the OBD connector can have more than one CAN line, such as a low-speed line (LS-CAN) or a mid-speed one (MS-CAN). Low-speed operates around 33Kbps, mid-speed is around 128Kbps, and high-speed (HS-CAN) is around 500Kbps. Often you’ll use a DB9-to-OBDII connector when connecting your sniffer to your vehicle’s OBD-II connector. Figure 2-18 shows the plug view, not that of the cable. Figure 2-18: Typical DB9 connector plug view. An asterisk (*) means that the pin is optional. A DB9 adapter can have as few as three pins connected. This pinout is a common pinout in the United Kingdom, and if you’re making a cable yourself, this one will be the easiest to use. However, some sniffers, such as many Arduino shields, expect the US-style DB9 connector (see Figure 2-19). Figure 2-19: US-style DB9 connector, plug view The US version has more features and gives you more access to other OBD connectors besides just CAN. Luckily, power is pin 9 on both style connectors, so you shouldn’t fry your sniffer if you happen to grab the wrong cable. Some sniffers, such as CANtact, have jumpers that you can set depending on which style cable you’re using. The OBD-III Standard OBD-III is a rather controversial evolution of the OBD-II standard. OBD-II was originally designed to be compliant with emissions testing (at least from the regulators’ perspective), but now that the powertrain control module (PCM) knows whether a vehicle is within guidelines, we’re still left with the inconvenience of the vehicle owner having to go for testing every other year. The OBD-III standard allows the PCM to communicate its status remotely without the owner’s interaction. This communication is typically accomplished through a roadside transponder, but cell phones and satellite communications work as well. The California Air Resources Board (CARB) began testing roadside readers for OBD-III in 1994 and is capable of reading vehicle data from eight lanes of traffic traveling at 100 miles per hour. If a fault is detected in the system, it’ll transmit the diagnostic trouble codes (DTC) and vehicle identification numbers (VIN) to a nearby transponder (see “Diagnostic Trouble Codes” on page 52). The idea is to have the system report that pollutants are entering the atmosphere without having to wait up to two years for an emissions check. Most implementations of OBD-III are manufacturer specific. The vehicle phones home to the manufacturer with faults and then contacts the owner to inform them of the need for repairs. As you might imagine, this system has some obvious legal questions that still need to be answered, including the risk of mass surveillance of private property. Certainly, there’s lots of room for abuses by law enforcement, including speed traps, tracking, immobilization, and so on. Some submitted request for proposals to integrate OBD-III into vehicles claim to use transponders to store the following information: • Date and time of current query • Date and time of last query • VIN • Status, such as “OK,” “Trouble,” or “No response” • Stored codes (DTCs) • Receiver station number It’s important to note that even if OBD-III sends only DTC and VIN, it’s trivial to add additional metadata, such as location, time, and history of the vehicle passing the transponder. For the most part, OBD-III is the bogeyman under the bed. As of this writing, it has yet to be deployed with a transponder approach, although phone-home systems such as OnStar are being deployed to notify the car dealer of various security or safety issues. Summary When working on your target vehicle, you may run into a number of different buses and protocols. When you do, examine the pins that your OBD-II connector uses for your particular vehicle to help you determine what tools you’ll need and what to expect when reversing your vehicle’s network. I’ve focused in this chapter on easily accessible buses via the OBD-II connector, but you should also look at your vehicle wiring diagrams to determine where to find other bus lines between sensors. Not all bus lines are exposed via the OBD-II connector, and when looking for a certain packet, it may be easier to locate the module and bus lines leaving a specific module in order to reverse a particular packet. (See Chapter 7 for details on how to read wiring diagrams.)

3

VEHICLE COMMUNICATION WITH SOCKETCAN When you begin using a CAN for vehicle communications, you may well find it to be a hodgepodge of different drivers and software utilities. The ideal would be to unify the CAN tools and their different interfaces into a common interface so we could easily share information between tools. Luckily, there’s a set of tools with a common interface, and it’s free! If you have Linux or install Linux on a virtual machine (VM), you already have this interface. The interface, called SocketCAN, was created on the Open Source development site BerliOS in 2006. Today, the term SocketCAN is used to refer to the implementation of CAN drivers as network devices, like Ethernet cards, and to describe application access to the CAN bus via the network socket–programming interface. In this chapter we’ll set up SocketCAN so that we’re more easily able to communicate with the vehicle. Volkswagen Group Research contributed the original SocketCAN implementation, which supports built-in CAN chips and card drivers, external USB and serial CAN devices, and virtual CAN devices. The can-utils package provides several applications and tools to interact with the CAN network devices, CAN-specific protocols, and the ability to set up a virtual CAN environment. In order to test many of the examples in this book, install a recent version in a Linux VM on your system. The newest versions of Ubuntu have can-utils in their standard repositories. SocketCAN ties into the Linux networking stack, which makes it very easy to create tools to support CAN. SocketCAN applications can use standard C socket calls with a custom network protocol family, PF_CAN. This functionality allows the kernel to handle CAN device drivers and to interface with existing networking hardware to provide a common interface and user-space utilities. Figure 3-1 compares the implementation of traditional CAN software with that of a unified SocketCAN. Figure 3-1: SocketCAN layout (left) and traditional CAN software (right) With traditional CAN software, the application has its own protocol that typically talks to a character device, like a serial driver, and then the actual hardware driver. On the left of the figure, SocketCAN is implemented in the Linux kernel. By creating its own CAN protocol family, SocketCAN can integrate with the existing network device drivers, thus enabling applications to treat a CAN bus interface as if it’s a generic network interface. Setting Up can-utils to Connect to CAN Devices In order to install can-utils, you must be running a Linux distribution from 2008 or later or one running the 2.6.25 Linux kernel or higher. First we’ll install can-utils, then cover how to configure it for your particular setup. Installing can-utils You should be able to use your package manager to install can-utils. Here’s a Debian/Ubuntu example: $ sudo apt-get install can-utils If you don’t have can-utils in your package manager, install it from source with the git command: $ git clone https://github.com/linux-can/can-utils As of this writing, can-utils has configure, make, and make install files, but in older versions, you’d just enter make to install from source. Configuring Built-In Chipsets The next step depends on your hardware. If you’re looking for a CAN sniffer, you should check the list of supported Linux drivers to ensure your device is compatible. As of this writing, the Linux built-in CAN drivers support the following chipsets: • Atmel AT91SAM SoCs • Bosch CC770 • ESD CAN-PCI/331 cards • Freescale FlexCAN • Freescale MPC52xx SoCs (MSCAN) • Intel AN82527 • Microchip MCP251x • NXP (Philips) SJA1000 • TI’s SoCs CAN controllers, like the SJA1000, are usually built into ISA, PCI, and PCMCIA cards or other embedded hardware. For example, the EMS PCMCIA card driver implements access to its SJA1000 chip. When you insert the EMS PCMCIA card into a laptop, the ems_pcmcia module loads into the kernel, which then requires the sja1000 module and the can_dev module to be loaded. The can_dev module provides standard configuration interfaces—for example, for setting bit rates for the CAN controllers. The Linux kernel’s modular concept also applies to CAN hardware drivers that attach CAN controllers via bus hardware, such as the kvaser_pci, peak_pci, and so on. When you plug in a supported device, these modules should automatically load, and you should see them when you enter the lsmod command. USB drivers, like usb8dev, usually implement a proprietary USB communication protocol and, therefore, do not load a CAN controller driver. For example, when you plug in a PEAK-System PCAN-USB adapter, the can_dev module loads and the peak_usb module finalizes its initialization. Using the display message command dmesg, you should see output similar to this: $ dmesg

--snip --

[ 8603.743057] CAN device driver interface

[ 8603.748745] peak_usb 3-2:1.0: PEAK-System PCAN-USB adapter hwrev 28 serial

FFFFFFFF (1 channel)

[ 8603.749554] peak_usb 3-2:1.0 can0: attached to PCAN-USB channel 0 (device

255)

[ 8603.749664] usbcore: registered new interface driver peak_usb You can verify the interface loaded properly with ifconfig and ensure a can0 interface is now present: $ ifconfig can0

can0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

UP RUNNING NOARP MTU:16 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:10

RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Now set the CAN bus speed. (You’ll find more information on bus speeds in Chapter 5.) The key component you need to set is the bit rate. This is the speed of the bus. A typical value for high-speed CAN (HS-CAN) is 500Kbps. Values of 250Kbps or 125Kbps are typical for lower-speed CAN buses. $ sudo ip link set can0 type can bitrate 500000

$ sudo ip link set up can0 Once you bring up the can0 device, you should be able to use the tools from can-utils on this interface. Linux uses netlink to communicate between the kernel and user-space tools. You can access netlink with the ip link command. To see all the netlink options, enter the following: $ ip link set can0 type can help If you begin to see odd behavior, such as a lack of packet captures and packet errors, the interface may have stopped. If you’re working with an external device, just unplug or reset. If the device is internal, run these commands to reset it: $ sudo ip link set canX type can restart-ms 100

$ sudo ip link set canX type can restart Configuring Serial CAN Devices External CAN devices usually communicate via serial. In fact, even USB devices on a vehicle often communicate through a serial interface—typically an FTDI chip from Future Technology Devices International, Ltd. The following devices are known to work with SocketCAN: • Any device that supports the LAWICEL protocol • CAN232/CANUSB serial adapters (http://www.can232.com/) • VSCOM USB-to-serial adapter (http://www.vscom.de/usb-to-can.htm) • CANtact (http://cantact.io) NOTE If you’re using an Arduino or building your own sniffer, you must implement the LAWICEL protocol—also known as the SLCAN protocol—in your firmware in order for your device to work. For details, see http://www.can232.com/docs/canusb_manual.pdf and https://github.com/linux-can/can-misc/blob/master/docs/SLCAN-API.pdf. In order to use one of the USB-to-serial adapters, you must first initialize both the serial hardware and the baud rate on the CAN bus: $ slcand -o -s6 -t hw -S 3000000 /dev/ttyUSB0

$ ip link set up slcan0 The slcand daemon provides the interface needed to translate serial communication to the network driver, slcan0. The following options can be passed to slcand: -o Opens the device -s6 Sets the CAN bus baud rate and speed (see Table 3-1) -t hw Specifies the serial flow control, either HW (hardware) or SW (software) -S 3000000 Sets the serial baud, or bit rate, speed /dev/ttyUSB0 Your USB FTDI device Table 3-1 lists the numbers passed to -s and the corresponding baud rates. Table 3-1: Numbers and Corresponding Baud Rates Number Baud 0 10Kbps 1 20Kbps 2 50Kbps 3 100Kbps 4 125Kbps 5 250Kbps 6 500Kbps 7 800Kbps 8 1Mbps As you can see, entering -s6 prepares the device to communicate with a 500Kbps CAN bus network. With these options set, you should now have an slcan0 device. To confirm, enter the following: $ ifconfig slcan0

slcan0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

NOARP MTU:16 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:10

RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Most of the information returned by ifconfig is set to generic default values, which may be all 0s. This is normal. We’re simply making sure that we can see the device with ifconfig. If we see an slcan0 device, we know that we should be able to use our tools to communicate over serial with the CAN controller. NOTE At this point, it may be good to see whether your physical sniffer device has additional lights. Often a CAN sniffer will have green and red lights to signify that it can communicate correctly with the CAN bus. Your CAN device must be plugged in to your computer and the vehicle in order for these lights to function properly. Not all devices have these lights. (Check your device’s manual.) Setting Up a Virtual CAN Network If you don’t have CAN hardware to play with, fear not. You can set up a virtual CAN network for testing. To do so, simply load the vcan module. $ modprobe vcan If you check dmesg, you shouldn’t see much more than a message like this: $ dmesg

[604882.283392] vcan: Virtual CAN interface driver Now you just set up the interface as discussed in “Configuring Built-In Chipsets” on page 37 but without specifying a baud rate for the virtual interface. $ ip link add dev vcan0 type vcan

$ ip link set up vcan0 To verify your setup, enter the following: $ ifconfig vcan0

vcan0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

UP RUNNING NOARP MTU:16 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) As long as you see a vcan0 in the output, you’re ready to go. The CAN Utilities Suite With our CAN device up and running, let’s take a high-level look at the can-utils. They’re listed and described briefly here; we’ll use them throughout the book, and we’ll explore them in greater detail as we use them. asc2log This tool parses ASCII CAN dumps in the following form into a standard SocketCAN logfile format: 0.002367 1 390x Rx d 8 17 00 14 00 C0 00 08 00 bcmserver Jan-Niklas Meier’s proof-of-concept (PoC) broadcast manager server takes commands like the following: vcan1 A 1 0 123 8 11 22 33 44 55 66 77 88 By default, it listens on port 28600. It can be used to handle some busy work when dealing with repetitive CAN messages. canbusload This tool determines which ID is most responsible for putting the most traffic on the bus and takes the following arguments: interface@bitrate You can specify as many interfaces as you like and have canbusload display a bar graph of the worst bandwidth offenders. can-calc-bit-timing This command calculates the bit rate and the appropriate register values for each CAN chipset supported by the kernel. candump This utility dumps CAN packets. It can also take filters and log packets. canfdtest This tool performs send and receive tests over two CAN buses. cangen This command generates CAN packets and can transmit them at set intervals. It can also generate random packets. cangw This tool manages gateways between different CAN buses and can also filter and modify packets before forwarding them on to the next bus. canlogserver This utility listens on port 28700 (by default) for CAN packets and logs them in standard format to stdout. canplayer This command replays packets saved in the standard SocketCAN “compact” format. cansend This tool sends a single CAN frame to the network. cansniffer This interactive sniffer groups packets by ID and highlights changed bytes. isotpdump This tool dumps ISO-TP CAN packets, which are explained in “Sending Data with ISO-TP and CAN” on page 55. isotprecv This utility receives ISO-TP CAN packets and outputs to stdout. isotpsend This command sends ISO-TP CAN packets that are piped in from stdin. isotpserver This tool implements TCP/IP bridging to ISO-TP and accepts data packets in the format 1122334455667788. isotpsniffer This interactive sniffer is like cansniffer but designed for ISO-TP packets. isotptun This utility creates a network tunnel over the CAN network. log2asc This tool converts from standard compact format to the following ASCII format: 0.002367 1 390x Rx d 8 17 00 14 00 C0 00 08 00 log2long This command converts from standard compact format to a user readable format. slcan_attach This is a command line tool for serial-line CAN devices. slcand This daemon handles serial-line CAN devices. slcanpty This tool creates a Linux psuedoterminal interface (PTY) to communicate with a serial-based CAN interface. Installing Additional Kernel Modules Some of the more advanced and experimental commands, such as the ISO-TP–based ones, require you to install additional kernel modules, such as can-isotp, before they can be used. As of this writing, these additional modules haven’t been included with the standard Linux kernels, and you’ll likely have to compile them separately. You can grab the additional CAN kernel modules like this: $ git clone https://gitorious.org/linux-can/can-modules.git

$ cd can-modules/net/can

$ sudo ./make_isotp.sh Once make finishes, it should create a can-isotp.ko file. If you run make in the root folder of the repository, it’ll try to compile some out-of-sync modules, so it’s best to compile only the module that you need in the current directory. To load the newly compiled can-isotp.ko module, run insmod: # sudo insmod ./can-isotp.ko dmesg should show that it loaded properly: $ dmesg

[830053.381705] can: isotp protocol (rev 20141116 alpha) NOTE Once the ISO-TP driver has proven to be stable, it should be moved into the stable kernel branch in Linux. Depending on when you’re reading this, it may already have been moved, so be sure to check whether it’s already installed before compiling your own. The can-isotp.ko Module The can-isotp.ko module is a CAN protocol implementation inside the Linux network layer that requires the system to load the can.ko core module. The can.ko module provides the network layer infrastructure for all in-kernel CAN protocol implementations, like can_raw.ko, can_bcm.ko, and can-gw.ko. If it’s working correctly, you should see this output in response to the following command: # sudo insmod ./can-isotp.ko

[830053.374734] can: controller area network core (rev 20120528 abi 9)

[830053.374746] NET: Registered protocol family 29

[830053.376897] can: netlink gateway (rev 20130117) max_hops=1 When can.ko is not loaded, you get the following: # sudo insmod ./can-isotp.ko

insmod: ERROR: could not insert module ./can-isotp.ko: Unknown symbol in

module If you’ve forgotten to attach your CAN device or load the CAN kernel module, this is the strange error message you’ll see. If you were to enter dmesg for more information, you’d see a series of missing symbols referenced in the error messages. $ dmesg

[830760.460054] can_isotp: Unknown symbol can_rx_unregister (err 0)

[830760.460134] can_isotp: Unknown symbol can_proto_register (err 0)

[830760.460186] can_isotp: Unknown symbol can_send (err 0)

[830760.460220] can_isotp: Unknown symbol can_ioctl (err 0)

[830760.460311] can_isotp: Unknown symbol can_proto_unregister (err 0)

[830760.460345] can_isotp: Unknown symbol can_rx_register (err 0) The dmesg output shows a lot of Unknown symbol messages, especially around can_x methods. (Ignore the (err 0) messages.) These messages tell us that the _isotop module can’t find methods related to standard CAN functions. These messages indicate that you need to load the can.ko module. Once loaded, everything should work fine. Coding SocketCAN Applications While can-utils is very robust, you’ll find that you want to write custom tools to perform specific actions. (If you’re not a developer, you may want to skip this section.) Connecting to the CAN Socket In order to write your own utilities, you first need to connect to the CAN socket. Connecting to a CAN socket on Linux is the same as connecting to any networking socket that you might know from TCP/IP network programming. The following shows C code that’s specific to CAN as well as the minimum required code to connect to a CAN socket. This code snippet will bind to can0 as a raw CAN socket. int s;

struct sockaddr_can addr;

struct ifreq ifr;



s = socket(PF_CAN, SOCK_RAW, CAN_RAW);



strcpy(ifr.ifr_name, "can0");

ioctl(s, SIOCGIFINDEX, &ifr);



addr.can_family = AF_CAN;

addr.can_ifindex = ifr.ifr_ifindex;



bind(s, (struct sockaddr *)&addr, sizeof(addr)); Let’s dissect the sections that are specific to CAN: s = socket(PF_CAN, SOCK_RAW, CAN_RAW); This line specifies the protocol family, PF_CAN, and defines the socket as CAN_RAW. You can also use CAN_BCM if you plan on making a broadcast manager (BCM) service. A BCM service is a more complex structure that can monitor for byte changes and the queue of cyclic CAN packet transmissions. These two lines name the interface: strcpy(ifr.ifr_name, "can0");

ioctl(s, SIOCGIFINDEX, &ifr); These lines set up the CAN family for sockaddr and then bind to the socket, allowing you to read packets off the network: addr.can_family = AF_CAN;

addr.can_ifindex = ifr.ifr_ifindex; Setting Up the CAN Frame Next we want to setup the CAN frame and read the bytes off the CAN network into our newly defined structure: struct can_frame frame;

nbytes = read(s, &frame, sizeof(struct can_frame)); The can_frame is defined in linux/can.h as: struct can_frame {

canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */

__u8 can_dlc; /* frame payload length in byte (0 .. 8) */

__u8 data[8] __attribute__((aligned(8)));

}; Writing to the CAN network is just like the read command but in reverse. Simple, eh? The Procfs Interface The SocketCAN network-layer modules implement a procfs interface as well. Having access to information in proc can make bash scripting easier and also provide a quick way to see what the kernel is doing. You’ll find the provided network-layer information in /proc/net/can/ and /proc/net/can-bcm/. You can see a list of hooks into the CAN receiver by searching the rcvlist_all file with cat: $ cat /proc/net/can/rcvlist_all

receive list 'rx_all':

(vcan3: no entry)

(vcan2: no entry)

(vcan1: no entry)

device can_id can_mask function userdata matches ident

vcan0 000 00000000 f88e6370 f6c6f400 0 raw

(any: no entry) Some other useful procfs files include the following: stats CAN network-layer stats reset_stats Resets the stats (for example, for measurements) version SocketCAN version You can limit the maximum length of transmitted packets in proc: $ echo 1000 > /sys/class/net/can0/tx_queue_len Set this value to whatever you feel will be the maximum packet length for your application. You typically won’t need to change this value, but if you find that you’re having throttling issues, you may want to fiddle with it. The Socketcand Daemon Socketcand (https://github.com/dschanoeh/socketcand) provides a network interface into a CAN network. Although it doesn’t include can-utils, it can still be very useful, especially when developing an application in a programming language like Go that can’t set the CAN low-level socket options described in this chapter. Socketcand includes a full protocol to control its interaction with the CAN bus. For example, you can send the following line to socketcand to open a loopback interface: < can0 C listen_only loopback three_samples > The protocol for socketcand is essentially the same as that of Jan-Niklas Meier’s BCM server mentioned earlier; it’s actually a fork of the BCM server. (Socketcand, however, is a bit more robust than the BCM server.) Kayak Kayak (http://kayak.2codeornot2code.org/), a Java-based GUI for CAN diagnostics and monitoring (see Figure 3-2), is one of the best tools for use with socketcand. Kayak links with OpenStreetMaps for mapping and can handle CAN definitions. As a Java-based application, it’s platform independent, so it leans on socketcand to handle communication to the CAN transceivers. You can download a binary package for Kayak or compile from source. In order to compile Kayak, install the latest version of Apache Maven, and clone the Kayak git repository (git://github.com/dschanoeh/Kayak). Once the clone is complete, run the following: $ mvn clean package You should find your binary in the Kayak/application/target/kayak/bin folder. Figure 3-2: The Kayak GUI Before you launch Kayak, start socketcand: $ socketcand -i can0 NOTE You can attach as many CAN devices as you want to socketcand, separated by commas. Next, start Kayak and take the following steps: Create a new project with CTRL -N and give it a name. Right-click the project and choose Newbus; then, give your bus a name (see Figure 3-3). Figure 3-3: Creating a name for the CAN bus Click the Connections tab at the right; your socketcand should show up under Auto Discovery (see Figure 3-4). Figure 3-4: Finding Auto Discovery under the Connections tab Drag the socketcand connection to the bus connection. (The bus connection should say Connection: None before it’s set up.) To see the bus, you may have to expand it by clicking the drop-down arrow next to the bus name, as shown in Figure 3-5. Figure 3-5: Setting up the bus connection Right-click the bus and choose Open RAW view. Press the play button (circled in Figure 3-6); you should start to see packets from the CAN bus. Figure 3-6: Open RAW view and press the play button to see packets from the CAN bus. Choose Colorize from the toolbar to make it easier to see and read the changing packets. Kayak can easily record and play back packet capture sessions, and it supports CAN definitions (stored in an open KDC format). As of this writing, the GUI doesn’t support creating definitions, but I’ll show how to create definitions later. Kayak is a great open source tool that can work on any platform. In addition, it has a friendly GUI with advanced features that allow you to define the CAN packets you see and view them graphically. Summary In this chapter, you learned how to use SocketCAN as a unified interface for CAN devices and how to set up your device and apply the appropriate bit rate for your CAN bus. I reviewed all of the default CAN utilities in the can-utils package that come with SocketCAN support, and I showed you how to write low-level C code to directly interface with the CAN sockets. Finally, you learned how to use socketcand to allow remote interaction with your CAN devices and set up Kayak to work with socketcand. Now that you’ve set up communication with your vehicle, you’re just about ready to try out some attacks.

4

DIAGNOSTICS AND LOGGING The OBD-II connector is primarily used by mechanics to quickly analyze and troubleshoot problems with a vehicle. (See “The OBD-II Connector” on page 17 for help locating the OBD connector.) When a vehicle experiences a fault, it saves information related to that fault and triggers the engine warning light, also known as the malfunction indicator lamp (MIL). These routine diagnostic checks are handled by the vehicle’s primary ECU, the powertrain control module (PCM), which can be made up of several ECUs (but to keep the discussion simple, we’ll refer to it only as the PCM). If you trigger faults while experimenting with the bus on a vehicle, you’ll need to able to read and write to the PCM in order to clear them. In this chapter, we’ll learn how to fetch and clear diagnostic codes as well as query the diagnostic services of the ECU. We’ll also learn how to access a vehicle’s crash data recordings and how to brute-force hidden diagnostic codes. Diagnostic Trouble Codes The PCM stores fault codes as diagnostic trouble codes (DTCs). DTCs are stored in different places. For instance, memory-based DTCs are stored in the PCM’s RAM, which means they’re erased when power from the battery is lost (as is true for all DTCs stored in RAM). More serious DTCs are stored in areas that will survive a power failure. Faults are usually classified as either hard or soft. Soft faults map to intermittent issues, whereas hard faults are ones that won’t go away without some sort of intervention. Often to determine whether a fault is hard or soft, a mechanic clears the DTCs and drives the vehicle to see whether the fault reappears. If it reappears, the fault is a hard fault. A soft fault could be due to a problem such as a loose gas cap. Not all faults trigger the MIL light right away. Specifically, class A faults, which signal a gross emissions failure, light the MIL right away, while class B faults, which don’t affect the vehicle’s emissions system, are stored the first time they’re triggered as a pending fault. The PCM waits to record several of the same faults before triggering the MIL. Class C faults often won’t turn on the MIL light but instead trigger a “service engine soon” type of message. Class D faults don’t trigger the MIL light at all. When storing the DTCs, the PCM snapshots all the relevant engine components in what is known as freeze frame data, which typically includes information such as the following: • DTC involved • Engine load • Engine revolutions per minute (RPM) • Engine temperature • Fuel trim • Manifold air pressure/mass air flow (MAP/MAF) values • Operating mode (open/close loop) • Throttle position • Vehicle speed Some systems store only one freeze frame, usually for the first DTC triggered or the highest-priority DTC, while others record multiple ones. In an ideal world, these snapshots would happen as soon the DTC occurs, but the freeze frames are typically recorded about five seconds after a DTC is triggered. DTC Format A DTC is a five-character alphanumeric code. For example, you’ll see codes like P0477 (exhaust pressure control valve low) and U0151 (lost communication with restraint control module). The code in the first byte position represents the basic function of the component that set the code, as shown in Table 4-1. Table 4-1: Diagnostic Code Layouts Byte position Description 1 P (0x0) = powertrain, B (0x1) = body,

C (0x2) = chassis, U (0x3) = network 2 0,2,3 (SAE standard) 1,3 (manufacturer specific) 3 Subgroup of position 1 4 Specific fault area 5 Specific fault area NOTE When set to 3, byte 2 is both an SAE-defined standard and a manufacturer-specific code. Originally, 3 was used exclusively for manufacturers, but pressure is mounting to standardize 3 to mean a standard code instead. In modern cars, if you see a 3 in the second position, it’s probably an SAE standard code. The five characters in a DTC are represented by just two raw bytes on the network. Table 4-2 shows how to break down the 2 DTC bytes into a full DTC code. Table 4-2: Diagnostic Code Binary Breakdown Except for the first two, the characters have a one-to-one relationship. Refer to Table 4-1 to see how the first two bits are assigned. You should be able to look up the meaning of any codes that follow the SAE standard online. Here are some example ranges for common powertrain DTCs: • P0001–P0099: Fuel and air metering, auxiliary emissions controls • P0100–P0199: Fuel and air metering • P0200–P0299: Fuel and air metering (injector circuit) • P0300–P0399: Ignition system or misfire • P0400–P0499: Auxiliary emissions controls • P0500–P0599: Vehicle speed controls, and idle control systems • P0600–P0699: Computer output circuit • P0700–P0799: Transmission To learn the meaning of a particular code, pick up a repair book in the Chilton series at your local auto shop. There, you’ll find a list of all OBD-II diagnostic codes for your vehicle. Reading DTCs with Scan Tools Mechanics check fault codes with scan tools. Scan tools are nice to have but not necessary for vehicle hacking. You should be able to pick one up at any vehicle supply store or on the Internet for anywhere between $100 and $3,000. For the cheapest possible solution, you can get an ELM327 device on eBay for around $10. These are typically dongles that need additional software, such as a mobile app, in order for them to function fully as scan tools. The software is usually free or under $5. A basic scan tool should be able to probe the vehicle’s fault system and report on the common, nonmanufacturer-specific DTC codes. Higher-end ones should have manufacturer-specific databases that allow you to perform much more detailed testing. Erasing DTCs DTCs usually erase themselves once the fault no longer appears during conditions similar to when the fault was first found. For this purpose, similar is defined as the following: • Engine speed within 375 RPM of the flagged condition • Engine load within 10 percent of the flagged condition • Engine temp is similar Under normal conditions, once the PCM no longer sees a fault after three checks, the MIL light turns off and the DTCs get erased. There are other ways to clear these codes: you can clear soft DTCs with a scan tool (discussed in the previous section) or by disconnecting the vehicle’s battery. Permanent or hard DTCs, however, are stored in NVRAM and are cleared only when the PCM no longer sees the fault condition. The reason for this is simple enough: to prevent mechanics from manually turning off the MIL and clearing the DTCs when the problem still exists. Permanent DTCs give mechanics a history of faults so that they’re in a better position to repair them. Unified Diagnostic Services The Unified Diagnostic Services (UDS) is designed to provide a uniform way to show mechanics what’s going on with a vehicle without their having to pay huge license fees for the auto manufacturer’s proprietary CAN bus packet layouts. Unfortunately, although UDS was designed to make vehicle information accessible to even the mom-and-pop mechanic, the reality is a bit different: CAN packets are sent the same way but the contents vary for each make, model, and even year. Auto manufacturers sell dealers licenses to the details of the packet contents. In practice, UDS just works as a gateway to make some but not all of this vehicle information available. The UDS system does not affect how a vehicle operates; it’s basically just a read-only view into what’s going on. However, it’s possible to use UDS to perform more advanced operations, such as diagnostic tests or firmware modifications (tests that are only a feature of higher-end scan tools). Diagnostic tests like these send the system a request to perform an action, and that request generates signals, such as other CAN packets, that are used to perform the work. For instance, a diagnostic tool may make a request to unlock the car doors, which results in the component sending a separate CAN signal that actually does the work of unlocking the doors. Sending Data with ISO-TP and CAN Because CAN frames are limited to 8 bytes of data, UDS uses the ISO-TP protocol to send larger outputs over the CAN bus. You can still use regular CAN to read or send data, but the response won’t be complete because ISO-TP allows chaining of multiple CAN packets. To test ISO-TP, connect to a CAN network that has diagnostic-capable modules such as an ECU. Then send a packet designed for ISO-TP over normal CAN using SocketCAN’s cansend application: $ cansend can0 7df#02010d

Replies similar to 7e8 03 41 0d 00 In this listing, 7df is the OBD diagnostic code, 02 is the size of the packet, 01 is the mode (show current data; see Appendix B for a list of common modes and PIDs), and 0d is the service (a vehicle speed of 0 because the vehicle was stationary). The response adds 0x8 to the ID (7e8); the next byte is the size of the response. Responses then add 0x40 to the type of request, which is 0x41 in this case. Then, the service is repeated and followed by the data for the service. ISO-TP dictates how to respond to a CAN packet. Normal CAN packets use a “fire-and-forget” structure, meaning they simply send data and don’t wait for a return packet. ISO-TP specifies a method to receive response data. Because this response data can’t be sent back using the same arbitration ID, the receiver returns the response by adding 0x8 to the ID and noting that the response is a positive one by adding 0x40 to the request. (If the response fails, you should see a 0x7F instead of the positive + 0x40 response.) Table 4-3 lists the most common error responses. Table 4-3: Common UDS Error Responses Hex (4th byte) Abbreviation Description 10 GR General reject 11 SNS Service not supported 12 SFNS Subfunction not supported 13 IMLOIF Incorrect message length or invalid format 14 RTL Response too long 21 BRR Busy repeat request 22 CNC Condition not correct 24 RSE Request sequence error 25 NRFSC No response from subnet component 26 FPEORA Failure prevents execution of requested action 31 ROOR Request out of range 33 SAD Security access denied 35 IK Invalid key 36 ENOA Exceeded number of attempts 37 RTDNE Required time delay not expired 38-4F RBEDLSD Reserved by extended data link security document 70 UDNA Upload/download not accepted 71 TDS Transfer data suspended 72 GPF General programming failure 73 WBSC Wrong block sequence counter 78 RCRRP Request correctly received but response is pending 7E SFNSIAS Subfunction not supported in active session 7F SNSIAS Service not supported in active session For example, if you use service 0x11 to reset the ECU and the ECU doesn’t support remote resets, you may see traffic like this: $ cansend can0 7df#021101

Replies similar to 7e8 03 7F 11 11 In this response, we can see that after 0x7e8, the next byte is 0x03, which represents the size of the response. The next byte, 0x7F, represents an error for service 0x11, the third byte. The final byte, 0x11, represents the error returned—in this case, service not su