The Car Hacker’s Handbook

A Guide for the Penetration Tester

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 228230 © 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.

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.

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.

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.

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

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.

In 2014, Open Garages—a group of people interested in sharing and collaborating on vehicle security—released the first Car Hacker’s Manual as course material for car hacking classes. The original book was designed to fit in a vehicle’s glove box and to cover the basics of car hacking in a one- or two-day class on auto security. Little did we know how much interest there would be in that that first book: we had over 300,000 downloads in the first week. In fact, the book’s popularity shut down our Internet service provider (twice!) and made them a bit unhappy with us. (It’s okay, they forgave us, which is good because I love my small ISP. Hi SpeedSpan.net!)

The feedback from readers was mostly fantastic; most of the criticism had to do with the fact that the manual was too short and didn’t go into enough detail. This book aims to address those complaints. The Car Hacker’s Handbook goes into a lot more detail about car hacking and even covers some things that aren’t directly related to security, like performance tuning and useful tools for understanding and working with vehicles.

If you’re holding this book, you may already know why you’d want to hack cars. But just in case, here’s a handy list detailing the benefits of car hacking:

Understanding How Your Vehicle Works

The automotive industry has churned out some amazing vehicles, with complicated electronics and computer systems, but it has released little information about what makes those systems work. Once you understand how a vehicle’s network works and how it communicates within its own system and outside of it, you’ll be better able to diagnose and troubleshoot problems.

Working on Your Vehicle’s Electrical Systems

As vehicles have evolved, they’ve become less mechanical and more electronic. Unfortunately, automotive electronics systems are typically closed off to all but the dealership mechanics. While dealerships have access to more information than you as an individual can typically get, the auto manufacturers themselves outsource parts and require proprietary tools to diagnose problems. Learning how your vehicle’s electronics work can help you bypass this barrier.

Modifying Your Vehicle

Understanding how vehicles communicate can lead to better modifications, like improved fuel consumption and use of third-party replacement parts. Once you understand the communication system, you can seamlessly integrate other systems into your vehicle, like an additional display to show performance or a third-party component that integrates just as well as the factory default.

Discovering Undocumented Features

Sometimes vehicles are equipped with features that are undocumented or simply disabled. Discovering undocumented or disabled features and utilizing them lets you use your vehicle to its fullest potential. For example, the vehicle may have an undocumented “valet mode” that allows you to put your car in a restricted mode before handing over the keys to a valet.

Validating the Security of Your Vehicle

As of this writing, vehicle safety guidelines don’t address malicious electronic threats. While vehicles are susceptible to the same malware as your desktop, automakers aren’t required to audit the security of a vehicle’s electronics. This situation is simply unacceptable: we drive our families and friends around in these vehicles, and every one of us needs to know that our vehicles are as safe as can be. If you learn how to hack your car, you’ll know where your vehicle is vulnerable so that you can take precautions and be a better advocate for higher safety standards.

Helping the Auto Industry

The auto industry can benefit from the knowledge contained in this book as well. This book presents guidelines for identifying threats as well as modern techniques to circumvent current protections. In addition to helping you design your security practice, this book offers guidance to researchers in how to communicate their findings.

Today’s vehicles are more electronic than ever. In a report in IEEE Spectrum titled “This Car Runs on Code,” author Robert N. Charette notes that as of 2009 vehicles have typically been built with over 100 microprocessors, 50 electronic control units, 5 miles of wiring, and 100 million lines of code (http://spectrum.ieee.org/transportation/systems/this-car-runs-on-code). Engineers at Toyota joke that the only reason they put wheels on a vehicle is to keep the computer from scraping the ground. As computer systems become more integral to vehicles, performing security reviews becomes more important and complex.

WARNING

Car hacking should not be taken casually. Playing with your vehicle’s network, wireless connections, onboard computers, or other electronics can damage or disable it. Be very careful when experimenting with any of the techniques in this book and keep safety as an overriding concern. As you might imagine, neither the author nor the publisher of this book will be held accountable for any damage to your vehicle.

The Car Hacker’s Handbook walks you through what it takes to hack a vehicle. We begin with an overview of the policies surrounding vehicle security and then delve in to how to check whether your vehicle is secure and how to find vulnerabilities in more sophisticated hardware systems.

Here’s a breakdown of what you’ll find in each chapter:

Chapter 1: Understanding Threat Models teaches you how to assess a vehicle. You’ll learn how to identify areas with the highest risk components. If you work for the auto industry, this will serve as a useful guide for building your own threat model systems.

Chapter 2: Bus Protocols details the various bus networks you may run into when auditing a vehicle and explores the wiring, voltages, and protocols that each bus uses.

Chapter 3: Vehicle Communication with SocketCAN shows how to use the SocketCAN interface on Linux to integrate numerous CAN hardware tools so that you can write or use one tool regardless of your equipment.

Chapter 4: Diagnostics and Logging covers how to read engine codes, the Unified Diagnostic Services, and the ISO-TP protocol. You’ll learn how different module services work, what their common weaknesses are, and what information is logged about you and where that information is stored.

Chapter 5: Reverse Engineering the CAN Bus details how to analyze the CAN network, including how to set up virtual testing environments and how to use CAN security–related tools and fuzzers.

Chapter 6: ECU Hacking focuses on the firmware that runs on the ECU. You’ll discover how to access the firmware, how to modify it, and how to analyze the firmware’s binary data.

Chapter 7: Building and Using ECU Test Benches explains how to remove parts from a vehicle to set up a safe testing environment. It also discusses how to read wiring diagrams and simulate components of the engine to the ECU, such as temperature sensors and the crank shaft.

Chapter 8: Attacking ECUs and Other Embedded Systems covers integrated circuit debugging pins and methodologies. We also look at side channel analysis attacks, such as differential power analysis and clock glitching, with step-by-step examples.

Chapter 9: In-Vehicle Infotainment Systems details how infotainment systems work. Because the in-vehicle infotainment system probably has the largest attack surface, we’ll focus on different ways to get to its firmware and execute on the system. This chapter also discusses some open source in-vehicle infotainment systems that can be used for testing.

Chapter 10: Vehicle-to-Vehicle Communication explains how the proposed vehicle-to-vehicle network is designed to work. This chapter covers cryptography as well as the different protocol proposals from multiple countries. We’ll also discuss some potential weaknesses with vehicle-to-vehicle systems.

Chapter 11: Weaponizing CAN Findings details how to turn your research into a working exploit. You’ll learn how to convert proof-of-concept code to assembly code, and ultimately shellcode, and you’ll examine ways of exploiting only the targeted vehicle, including ways to probe a vehicle undetected.

Chapter 12: Attacking Wireless Systems with SDR covers how to use software-defined radio to analyze wireless communications, such as TPMS, key fobs, and immobilizer systems. We review the encryption schemes you may run into when dealing with immobilizers as well as any known weaknesses.

Chapter 13: Performance Tuning discusses techniques used to enhance and modify a vehicle’s performance. We’ll cover chip tuning as well as common tools and techniques used to tweak an engine so it works the way you want it to.

Appendix A: Tools of the Trade provides a list of software and hardware tools that will be useful when building your automotive security lab.

Appendix B: Diagnostic Code Modes and PIDs lists some common modes and handy PIDS.

Appendix C: Creating Your Own Open Garage explains how to get involved in the car hacking community and start your own Open Garage.

By the end of the book, you should have a much deeper understanding of how your vehicle’s computer systems work, where they’re most vulnerable, and how those vulnerabilities might be exploited.

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.

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.

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.

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.

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

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

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

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

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.

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

Table 1-6: Intercepting HSI Commands

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.

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.

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.

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

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 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 (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 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.

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.

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

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.

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.

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.)

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.

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)

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

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.

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.

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.

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 (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:

  1. Create a new project with CTRL-N and give it a name.

  2. 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

  3. 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

  4. 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

  5. Right-click the bus and choose Open RAW view.

  6. 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.

  7. 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.

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.

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.

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

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.

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

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 supported (SNS).

To send or receive something with more than the 8 bytes of data in a standard CAN packet, use SocketCAN’s ISO-TP tools. Run istotpsend in one terminal, and then run isotpsniffer (or isotprecv) in another terminal to see the response to your istotpsend commands. (Don’t forget to insmod your can-isotp.ko module, as described in Chapter 3.)

For example, in one terminal, set up a sniffer like this:

$ isotpsniffer -s 7df -d 7e8 can0

Then, in another terminal, send the request packet via the command line:

$ echo "09 02" | isotpsend -s 7DF -d 7E8 can0

When using ISO-TP, you need to specify a source and destination address (ID). In the case of UDS, the source is 0x7df, and the destination (response) is 0x7e8. (When using ISO-TP tools, the starting 0x in the addresses isn’t specified.)

In this example, we’re sending a packet containing PID 0x02 with mode 0x09 in order to request the vehicle’s VIN. The response in the sniffer should display the vehicle’s VIN, as shown here in the last line of output:

$ isotpsniffer -s 7df -d 7e8 can0 can0 7DF [2] 09 02 - '..' can0 7E8 [20] 49➊ 02➋ 01➌ 31 47 31 5A 54 35 33 38 32 36 46 31 30 39 31 34 39 - 'I..1G1ZT53826F109149'

The first 3 bytes make up the UDS response. 0x49 ➊ is service 0x09 + 0x40, which signifies a positive response for PID 0x02 ➋, the next byte. The third byte, 0x01 ➌, indicates the number of data items that are being returned (one VIN in this case). The VIN returned is 1G1ZT53826F109149. Enter this VIN into Google, and you should see detailed information about this vehicle, which was taken from an ECU pulled from a wrecked car found in a junkyard. Table 4-4 shows the information you should see.

Table 4-4: VIN Information

If you were watching this UDS query via a normal CAN sniffer, you’d have seen several response packets on 0x7e8. You could re-assemble an ISO-TP packet by hand or with a simple script, but the ISO-TP tools make things much easier.

NOTE

If you have difficulty running the ISO-TP tools, make sure you have the proper kernel module compiled and installed (see “Installing Additional Kernel Modules” on page 42).

Understanding Modes and PIDs

The first byte of the data section in a diagnostic code is the mode. In automotive manuals, modes start with a $, as in $1. The $ is used to state that the number is in hex. The mode $1 is the same as 0x01, $0A is the same as 0x0A, and so on. I’ve listed a few examples here, and there are more in Appendix B for reference.

0x01: Shows current data

Shows data streams of a given PID. Sending a PID of 0x00 returns 4 bytes of bit-encoded available PIDs (0x01 through 0x20).

0x02: Shows freeze frame data

Has the same PID values as 0x01, except that the data returned is from the freeze frame state.

0x03: Shows stored “confirmed” diagnostic trouble codes

Matches the DTCs mentioned in “DTC Format” on page 52.

0x04: Erases DTCs and clears diagnostic history

Clears the DTC and freeze frame data.

0x07: Shows “pending” diagnostic codes

Displays codes that have shown up once but that haven’t been confirmed; status pending.

0x08: Controls operations of onboard component/system

Allows a technician to activate and deactivate the system actuators manually. System actuators allow drive-by-wire operations and physically control different devices. These codes aren’t standard, so a common scan tool won’t be able to do much with this mode. Dealership scan tools have a lot more access to vehicle internals and are an interesting target for hackers to reverse engineer.

0x09: Requests vehicle information

Several pieces of data can be pulled with mode 0x09.

0x0a: Permanent diagnostic codes

This mode pulls DTCs that have been erased via mode 0x04. These DTCs are cleared only once the PCM has verified the fault condition is no longer present (see “Erasing DTCs” on page 54).

Brute-Forcing Diagnostic Modes

Each manufacturer has its own proprietary modes and PIDs, which you can usually get by digging through “acquired” dealer software or by using tools or brute force. The easiest way to do brute force is to use an open source tool called the CaringCaribou (CC), available at https://github.com/CaringCaribou/caringcaribou.

CaringCaribou consists of a collection of Python modules designed to work with SocketCAN. One such module is a DCM module that deals specifically with discovering diagnostic services.

To get started with CaringCaribou, create an RC file in your home directory, ~/.canrc.

[default] interface = socketcan_ctypes channel = can0

Set your channel to that of your SocketCAN device. Now, to discover what diagnostics your vehicle supports, run the following:

$ ./cc.py dcm discovery

This will send the tester-present code to every arbitration ID. Once the tool sees a valid response (0x40+service) or an error (0x7f), it’ll print the arbitration ID and the reply ID. Here is an example discovery session using CaringCaribou:

------------------- CARING CARIBOU v0.1 -------------------

Loaded module 'dcm'

Starting diagnostics service discovery Sending diagnostics Tester Present to 0x0244 Found diagnostics at arbitration ID 0x0244, reply at 0x0644

We see that there’s a diagnostic service responding to 0x0244. Great! Next, we probe the different services on 0x0244:

$ ./cc.py dcm services 0x0244 0x0644

------------------- CARING CARIBOU v0.1 -------------------

Loaded module 'dcm'

Starting DCM service discovery Probing service 0xff (16 found) Done!

Supported service 0x00: Unknown service Supported service 0x10: DIAGNOSTIC_SESSION_CONTROL Supported service 0x1a: Unknown service Supported service 0x00: Unknown service Supported service 0x23: READ_MEMORY_BY_ADDRESS Supported service 0x27: SECURITY_ACCESS Supported service 0x00: Unknown service Supported service 0x34: REQUEST_DOWNLOAD Supported service 0x3b: Unknown service Supported service 0x00: Unknown service Supported service 0x00: Unknown service Supported service 0x00: Unknown service Supported service 0xa5: Unknown service Supported service 0xa9: Unknown service Supported service 0xaa: Unknown service Supported service 0xae: Unknown service

Notice that the output lists several duplicate services for service 0x00. This is often caused by an error response for something that’s not a UDS service. For instance, the requests below 0x0A are legacy modes that don’t respond to the official UDS protocol.

NOTE

As of this writing, CaringCaribou is in its early stages of development, and your results may vary. The current version available doesn’t account for older modes and parses the response incorrectly, which is why you see several services with ID 0x00. For now, just ignore those services; they’re false positives. CaringCaribou’s discovery option stops at the first arbitration ID that responds to a diagnostic session control (DSC) request. Restart the scan from where it left off using the -min option, as follows:

$ ./cc.py dcm discovery -min 0x245

In our example, the scan will also stop scanning a bit later at this more common diagnostic ID:

Found diagnostics at arbitration ID 0x07df, reply at 0x07e8

Keeping a Vehicle in a Diagnostic State

When doing certain types of diagnostic operations, it’s important to keep the vehicle in a diagnostic state because it’ll be less likely to be interrupted, thereby allowing you to perform actions that can take several minutes. In order to keep the vehicle in this state, you need to continuously send a packet to let the vehicle know that a diagnostic technician is present.

These simple scripts will keep the car in a diagnostic state that’ll prove useful for flashing ROMs or brute-forcing. The tester present packet keeps the car in a diagnostic state. It works as a heartbeat, so you’ll need to transmit it every one to two seconds, as shown here:

#!/bin/sh while : do cansend can0 7df#013e sleep 1 done

You can do the same things with cangen:

$ cangen -g 1000 -I 7DF -D 013E -L 2 can0

NOTE

As of this writing, cangen doesn’t always work on serial-line CAN devices. One possible workaround is to tell slcand to use canX style names instead of slcanX.

Use the ReadDataByID command to read data by ID and to query devices for information. 0x01 is the standard query. The enhanced version, 0x22, can return information not available with standard OBD tools.

Use the SecurityAccess command (0x27) to access protected information. This can be a rolling key, meaning that the password or key changes each time, but the important thing is that the controller responds if successful. For example, if you send the key 0x1, and it’s the correct access code, then you should receive an 0x2 in return. Some actions, such as flashing ROMs, will require you to send a SecurityAccess request. If you don’t have the algorithm to generate the necessary challenge response, then you’ll need to brute-force the key.

You likely know that airplanes have black boxes that record information about flights as well as conversations in the cockpit and over radio transmissions. All 2015 and newer vehicles are also required to have a type of black box, known as an event data recorder (EDR), but EDRs record only a portion of the information that a black box on an airplane would. The information stored on the EDR includes the following (you’ll find a more complete list in SAE J1698-2):

• Airbag deployment

• Brake status

• Delta-v (longitudinal change in velocity)

• Ignition cycles

• Seat belt status

• Steering angles

• Throttle position

• Vehicle speed

While this data is very similar to freeze frame data, its purpose is to collect and store information during a crash. The EDR constantly stores information, typically only about 20 seconds worth at any one time. This information was originally stored in a vehicle’s airbag control module (ACM), but today’s vehicles distribute this data among the vehicle’s ECUs. These boxes collect data from other ECUs and sensors and store them for recovery after a crash. Figure 4-1 shows a typical EDR.

Figure 4-1: A typical event data recorder

Reading Data from the EDR

The official way to read data from an EDR is with a crash data retrieval (CDR) tool kit. A basic CDR tool will connect to the OBD connector and pull data (or image the vehicle) from the main ECU. CDR tools can also access data in other modules, such as the ACM or the rollover sensor (ROS) module, but they’ll normally need to be plugged in directly to those devices instead of using the OBD port. (You’ll find a comprehensive list of which vehicles have black box data that can be retrieved here: http://www.crashdatagroup.com/research/vehiclecoverage.html.)

CDR kits include both proprietary hardware and software. The hardware usually costs about $2,000, and the cost of the software will vary depending on how many vehicle types you want to support. The format of vehicle crash data is often considered proprietary as well, and many manufacturers license the communication protocol to tool providers that make CDRs. Obviously, this is not in the best interest of the consumer. The National Highway Traffic Safety Administration (NHTSA) has proposed the adoption of a standard OBD communication method to access this data.

The SAE J1698 Standard

The SAE J1698 standard lists recommended practices for event data collection and defines event records by sample rate: high, low, and static. High samples are data recorded at the crash event, low samples are pre-crash data, and static samples are data that doesn’t change. Many vehicles are influenced by the SAE J1698 but don’t necessarily conform to its rules for all data retrieved from a vehicle.

Some recorded elements are:

• Cruise control status

• Driver controls: parking brake, headlight, front wiper, gear selection, passenger airbag disabled switch

• Foremost seat track position

• Hours in operation

• Indicator status lights: VEDI, SRS, PAD, TPMS, ENG, DOOR, IOD

• Latitude and longitude

• Seating position

• SRS deployment status/time

• Temperature air/cabin

• Vehicle mileage

• VIN

While the SAE J1698 states latitude and longitude recordings, many manufacturers claim not to record this information for privacy reasons. Your research may vary.

Other Data Retrieval Practices

Not all manufacturers conform the to SAE J1698 standard. For example, since the 1990s, General Motors has collected a small amount of EDR data in the sensing and diagnostic module (SDM) of its vehicles. The SDM stores the vehicle’s Delta-v, which is the longitudinal change in the vehicle’s velocity. The SDM does not record any post-crash information.

Another example is Ford’s EDR, known as the restraint control module (RCM). Ford stores a vehicle’s longitudinal and lateral acceleration data rather than Delta-v. If the vehicle has electronic throttle control, the PCM stores additional EDR data, including whether the passenger was an adult or not, the percent the accelerator/brake pedal was depressed, and whether a diagnostic code was active when the crash occurred.

Automated crash notification (ACN) systems are the phone-home systems that contact a vehicle’s manufacturer or a third party with event information. These coincide with other crash recovery systems and extend the functionality by contacting the manufacturer or third party. One major difference is that there aren’t rules or standards that determine what data is collected and sent to an ACN. ACNs are specific to each manufacturer, and each system will send different information. For example, the Veridian automated collision notification system (released in 2001) reports this information:

• Crash type (frontal, side, rear)

• Date and time

• Delta-v

• Longitude and latitude

• Make, model, and year of vehicle

• Principal direction of force

• Probable number of occupants

• Rollover (yes or no)

• Seat belt use

• Vehicle’s final resting position (normal, left side, right side, roof)

Attackers may target a vehicle’s DTCs and freeze frame data to hide malicious activity. For example, if an exploit needs to take advantage of only a brief, temporary condition in order to succeed, a vehicle’s freeze frame data will most likely miss the event due to delays in recording. Captured freeze frame snapshots rarely contain information that would help determine whether the DTC was triggered by malicious intent. (Because black box EDR systems typically trigger only during a crash, it’s unlikely that an attacker would target them because they’re not likely to contain useful data.)

An attacker fuzzing a vehicle’s system might check for fired DTCs and use the information contained in a DTC to determine which component was affected. This type of attack would most likely occur during the research phase of an attack (when an attacker is trying to determine what components the randomly generated packets were affecting), not during an active exploit.

Accessing and fuzzing manufacturer-specific PIDs—by flashing firmware or using mode 0x08—can lead to interesting results. Because each manufacturer interface is kept secret, it’s difficult to assess the actual risk of the network. Unfortunately, security professionals will need to reverse or fuzz these proprietary interfaces to determine what is exposed before work can be done to determine whether there are vulnerabilities. Malicious actors will need to do the same thing, although they won’t be motivated to share their findings. If they can keep undocumented entry points and weaknesses a secret, then their exploit will last longer without being detected. Having secret interfaces into the vehicle doesn’t increase security; the vulnerabilities are there regardless of whether people are allowed to discuss them. Because there’s money in selling these codes (sometimes upward of $50,000), the industry has little incentive to embrace the community.

In this chapter, you have gone beyond traditional CAN packets to understand more complex protocols such as ISO-TP. You have learned how CAN packets can be linked together to write larger messages or to create two-directional communications over CAN. You also learned how to read and clear any DTCs. You looked at how to find undocumented diagnostic services and saw what types of data are recorded about you and your driving habits. You also explored some ways in which diagnostic services can be used by malicious parties.

In order to reverse engineer the CAN bus, we first have to be able to read the CAN packets and identify which packets control what. That said, we don’t need to be able to access the official diagnostic CAN packets because they’re primarily a read-only window. Instead, we’re interested in accessing all the other packets that flood the CAN bus. The rest of the nondiagnostic packets are the ones that the car actually uses to perform actions. It can take a long time to grasp the information contained in these packets, but that knowledge can be critical to understanding the car’s behavior.

Of course, before we can reverse the CAN bus, we need to locate the CAN. If you have access to the OBD-II connector, your vehicle’s connector pinout map should show you where the CAN is. (See Chapter 2 for common locations of the OBD connectors and their pinouts.) If you don’t have access to the OBD-II connector or you’re looking for hidden CAN signals, try one of these methods:

• Look for paired and twisted wires. CAN wires are typically two wires twisted together.

• Use a multimeter to check for a 2.5V baseline voltage. (This can be difficult to identify because the bus is often noisy.)

• Use a multimeter to check for ohm resistance. The CAN bus uses a 120-ohm terminator on each end of the bus, so there should be 60 ohms between the two twisted-pair wires you suspect are CAN.

• Use a two-channel oscilloscope and subtract the difference between the two suspected CAN wires. You should get a constant signal because the differential signals should cancel each other out. (Differential signaling is discussed in “The CAN Bus” on page 16.)

NOTE

If the car is turned off, the CAN bus is usually silent, but something as simple as inserting the car key or pulling up on the door handle will usually wake the vehicle and generate signals.

Once you’ve identified a CAN network, the next step is to start monitoring the traffic.

First, you need to determine the type of communication running on the bus. You’ll often want to identify a certain signal or the way a certain component talks—for example, how the car unlocks or how the drivetrain works. In order to do so, locate the bus those target components use, and then reverse engineer the packets traveling on that bus to identify their purpose.

To monitor the activity on your CAN, you need a device that can monitor and generate CAN packets, such as the ones discussed in Appendix A. There are a ton of these devices on the market. The cheap OBD-II devices that sell for under $20 technically work, but their sniffers are slow and will miss a lot of packets. It’s always best to have a device that’s as open as possible because it’ll work with the majority of software tools—open source hardware and software is ideal. However, a proprietary device specifically designed to sniff CAN should still work. We’ll look at using candump, from the can-utils suite, and Wireshark to capture and filter the packets.

Generic packet analysis won’t work for CAN because CAN packets are unique to each vehicle’s make and model. Also, because there’s so much noise on CAN, it’s too cumbersome to sort through every packet as it flows by in sequence.

Using Wireshark

Wireshark (https://www.wireshark.org/) is a common network monitoring tool. If your background is in networking, your first instinct may be to use Wireshark to look at CAN packets. This technically works, but we will soon see why Wireshark is not the best tool for the job.

If you want to use Wireshark to capture CAN packets, you can do so together with SocketCAN. Wireshark can listen on both canX and vcanX devices, but not on slcanX because serial-link devices are not true netlink devices and they need a translation daemon in order for them to work. If you need to use a slcanX device with Wireshark, try changing the name from slcanX to canX. (I discuss CAN interfaces in detail Chapter 2.)

If renaming the interface doesn’t work or you simply need to move CAN packets from an interface that Wireshark can’t read to one it can, you can bridge the two interfaces. You’ll need to use candump from the can-utils package in bridge mode to send packets from slcan0 to vcan0.

$ candump -b vcan0 slcan0

Notice in Figure 5-1 that the data section isn’t decoded and is just showing raw hex bytes. This is because Wireshark’s decoder handles only the basic CAN header and doesn’t know how to deal with ISO-TP or UDS packets. The highlighted packet is a UDS request for VIN. (I’ve sorted the packets in the screen by identifier, rather than by time, to make it easier to read.)

Figure 5-1: Wireshark on the CAN bus

Using candump

As with Wireshark, candump doesn’t decode the data for you; that job is left up to you, as the reverse engineer. Listing 5-1 uses slcan0 as the sniffer device.

$ candump slcan0 slcan0➊ 388➋ [2]➌ 01 10➍ slcan0 110 [8] 00 00 00 00 00 00 00 00 slcan0 120 [8] F2 89 63 20 03 20 03 20 slcan0 320 [8] 20 04 00 00 00 00 00 00 slcan0 128 [3] A1 00 02 slcan0 7DF [3] 02 09 02 slcan0 7E8 [8] 10 14 49 02 01 31 47 31 slcan0 110 [8] 00 00 00 00 00 00 00 00 slcan0 120 [8] F2 89 63 20 03 20 03 20 slcan0 410 [8] 20 00 00 00 00 00 00 00 slcan0 128 [3] A2 00 01 slcan0 380 [8] 02 02 00 00 E0 00 7E 0E slcan0 388 [2] 01 10 slcan0 128 [3] A3 00 00 slcan0 110 [8] 00 00 00 00 00 00 00 00 slcan0 120 [8] F2 89 63 20 03 20 03 20 slcan0 520 [8] 00 00 04 00 00 00 00 00 slcan0 128 [3] A0 00 03 slcan0 380 [8] 02 02 00 00 E0 00 7F 0D slcan0 388 [2] 01 10 slcan0 110 [8] 00 00 00 00 00 00 00 00 slcan0 120 [8] F2 89 63 20 03 20 03 20 slcan0 128 [3] A1 00 02 slcan0 110 [8] 00 00 00 00 00 00 00 00 slcan0 120 [8] F2 89 63 20 03 20 03 20 slcan0 128 [3] A2 00 01 slcan0 380 [8] 02 02 00 00 E0 00 7C 00

Listing 5-1: candump of traffic streaming through a CAN bus

The columns are broken down to show the sniffer device ➊, the arbitration ID ➋, the size of the CAN packet ➌, and the CAN data itself ➍. Now you have some captured packets, but they aren’t the easiest to read. We’ll use filters to help identify the packets we want to analyze in more detail.

Grouping Streamed Data from the CAN Bus

Devices on a CAN network are noisy, often pulsing at set intervals or when triggered by an event, such as a door unlocking. This noise can make it futile to stream data from a CAN network without a filter. Good CAN sniffer software will group changes to packets in a data stream based on their arbitration ID, highlighting only the portions of data that have changed since the last time the packet was seen. Grouping packets in this way makes it easier to spot changes that result directly from vehicle manipulation, allowing you to actively monitor the tool’s sniffing section and watch for color changes that correlate to physical changes. For example, if each time you unlock a door you see the same byte change in the data stream, you know that you’ve probably identified at least the byte that controls the door-unlocking functions.

Grouping Packets with cansniffer

The cansniffer command line tool groups the packets by arbitration ID and highlights the bytes that have changed since the last time the sniffer looked at that ID. For example, Figure 5-2 shows the result of running cansniffer on the device slcan0.

Figure 5-2: cansniffer example output

You can add the -c flag to colorize any changing bytes.

$ cansniffer -c slcan0

The cansniffer tool can also remove repeating CAN traffic that isn’t changing, thereby reducing the number of packets you need to watch.

Filtering the Packets Display

One advantage of cansniffer is that you can send it keyboard input to filter results as they’re displayed in the terminal. (Note that you won’t see the commands you enter while cansniffer is outputting results.) For example, to see only IDs 301 and 308 as cansniffer collects packets, enter this:

-000000 +301 +308

Entering -000000 turns off all packets, and entering +301 and +308 filters out all except IDs 301 and 308.

The -000000 command uses a bitmask, which does a bit-level comparison against the arbitration ID. Any binary value of 1 used in a mask is a bit that has to be true, while a binary value of 0 is a wildcard that can match anything. A bitmask of all 0s tells cansniffer to match any arbitration ID. The minus sign (-) in front of the bitmask removes all matching bits, which is every packet.

You can also use a filter and a bitmask with cansniffer to grab a range of IDs. For example, the following command adds the IDs from 500 through 5FF to the display, where 500 is the ID applied to the bitmask of 700 to define the range we’re interested in.

+500700

To display all IDs of 5_XX_, you’d use the following binary representation:

ID Binary Representation 500 101 0000 0000 700 111 0000 0000 ------------------ 101 XXXX XXXX 5 X X

You could specify F00 instead of 700, but because the arbitration ID is made up of only 3 bits, a 7 is all that’s required.

Using 7FF as a mask is the same as not specifying a bitmask for an ID. For example

+3017FF

is the same as

+301

This mask uses binary math and performs an AND operation on the two numbers, 0x301 and 0x7FF:

ID Binary Representation 301 011 0000 0001 7FF 111 1111 1111 ______________________________ 011 0000 0001 3 0 1

For those not familiar with AND operations, each binary bit is compared, and if both are a 1 then the output is a 1. For instance, 1 AND 1 = 1, while 1 AND 0 = 0.

If you prefer to have a GUI interface, Kayak, which we discussed in “Kayak” on page 46, is a CAN bus–monitoring application that also uses socketcand and will colorize its display of capture packets. Kayak won’t remove repeating packets the way cansniffer does, but it offers a few unique capabilities that you can’t easily get on the command line, such as documenting the identified packets in XML (.kcd files), which can be used by Kayak to display virtual instrument clusters and map data (see Figure 5-3).

Figure 5-3: Kayak GUI interface

Using Record and Playback

Once you’ve used cansniffer or a similar tool to identify certain packets to focus on, the next step is to record and play back packets so you can analyze them. We’ll look at two different tools to do this: can-utils and Kayak. They have similar functionality, and your choice of tool will depend on what you’re working on and your interface preferences.

The can-utils suite records CAN packets using a simple ASCII format, which you can view with a simple text editor, and most of its tools support this format for both recording and playback. For example, you can record with candump, redirect standard output or use the command line options to record to a file, and then use canplayer to play back recordings.

Figure 5-4 shows a view of the layout of Kayak’s equivalent to cansniffer.

Figure 5-4: Kayak recording to a logfile

To record CAN packets with Kayak, first click the Play button in the Log files tab ➊. Then drag one or more buses from the Projects pane to the Busses field of the LogOutput Window tab ➋. Press the Record and Stop buttons at the bottom of the LogOutput window ➌ to start or stop recording. Once your packet capture is complete, the logging should show in the Log Directory drop-down menu (see Figure 5-5).

If you open a Kayak logfile, you’ll see something like the code snippet in Listing 5-2. The values in this example won’t directly correlate to those in Figure 5-4 because the GUI groups by ID, as in cansniffer, but the log is sequential, as in candump.

PLATFORM NO_PLATFORM DESCRIPTION "No description" DEVICE_ALIAS OBD Port slcan0 (1094.141850)➊ slcan0➋ 128#a20001➌ (1094.141863) slcan0 380#02020000e0007e0e (1094.141865) slcan0 388#0110 (1094.144851) slcan0 110#0000000000000000 (1094.144857) slcan0 120#f289632003200320

Listing 5-2: Contents of Kayak’s logfile

Figure 5-5: Right pane of Log files tab settings

Other than some metadata (PLATFORM, DESCRIPTION, and DEVICE_ALIAS), the log is pretty much the same as the one captured by the can-utils package: ➊ is the timestamp, ➋ is your bus, and ➌ is your arbitration ID and data separated by a # symbol. To play back the capture, right-click the Log Description in the right panel, and open the recording (see Figure 5-5).

Listing 5-3 shows the logfile created by candump using the -l command line option:

(1442245115.027238) slcan0 166#D0320018 (1442245115.028348) slcan0 158#0000000000000019 (1442245115.028370) slcan0 161#000005500108001C (1442245115.028377) slcan0 191#010010A141000B

Listing 5-3: candump logfile

Notice in Listing 5-3 that the candump logfiles are almost identical to those displayed by Kayak in Figure 5-4. (For more details on different can-utils programs, see “The CAN Utilities Suite” on page 41.)

Creative Packet Analysis

Now that we’ve captured packets, it’s time to determine what each packet does so we can use it to unlock things or exploit the CAN bus. Let’s start with a simple action that’ll most likely toggle only a single bit—the code to unlock the doors—and see whether we can find the packet that controls that behavior.

Using Kayak to Find the Door-Unlock Control

There’s a ton of noise on the CAN bus, so finding a single-bit change can be very difficult, even with a good sniffer. But here’s a universal way to identify the function of a single CAN packet:

  1. Press Record.

  2. Perform the physical action, such as unlocking a door.

  3. Stop Record.

  4. Press Playback.

  5. See whether the action was repeated. For example, did the door unlock?

If pressing Playback didn’t unlock the door, a couple of things may have gone wrong. First, you may have missed the action in the recording, so try recording and performing the action again. If you still can’t seem to record and replay the action, the message is probably hardwired to the physical lock button, as is often the case with the driver’s-side door lock. Try unlocking the passenger door instead while recording. If that still doesn’t work, the message for the unlock action is either on a CAN bus other than the one you’re monitoring—you’ll need to find the correct one—or the playback may have caused a collision, resulting in the packet being stomped on. Try to replay the recording a few times to make sure the playback is working.

Once you have a recording that performs the desired action, use the method shown in Figure 5-6 to filter out the noise and locate the exact packet and bits that are used to unlock the door via the CAN bus.

Now, keep halving the size of the packet capture until you’re down to only one packet, at which point you should be able figure out which bit or bits are used to unlock the door. The quickest way to do this is to open your sniffer and filter on the arbitration ID you singled out. Unlock the door, and the bit or byte that changed should highlight. Now, try to unlock the car’s back doors, and see how the bytes change. You should be able to tell exactly which bit must be changed in order to unlock each door.

Figure 5-6: Sample unlock reversing flow

Using can-utils to Find the Door-Unlock Control

To identify packets via can-utils, you’d use candump to record and canplayer to play back the logfile, as noted earlier. Then, you’d use a text editor to whittle down the file before playback. Once you’re down to one packet, you can then determine which byte or bits control the targeted operation with the help of cansend. For instance, by removing different halves of a logfile, you can identify the one ID that triggers the door to unlock:

slcan0 300 [8] 00 00 84 00 00 0F 00 00

Now, you could edit each byte and play back the line, or you could use cansniffer with a filter of +300 to single out just the 300 arbitration ID and monitor which byte changes when you unlock the door. For example, if the byte that controls the door unlock is the sixth byte—0x0F in the preceding example—we know that when the sixth byte is 0x00, the doors unlock, and when it’s 0x0F, the doors lock.

NOTE

This is a hypothetical example that assumes we’ve performed all the steps listed earlier in this chapter to identify this particular byte. The specifics will vary for each vehicle.

We can verify our findings with cansend:

$ cansend slcan0 300#00008400000F0000

If, after sending this, all the doors lock, we’ve successfully identified which packets control the door unlock.

Now, what happens when you change the 0x0F? To find out, unlock the car and this time send a 0x01:

$ cansend slcan0 300#0000840000010000

Observe that only the driver’s-side door locks and the rest stay open. If you repeat this process with a 0x02, only the front passenger’s-side door locks. When you repeat again with a 0x03, both the driver’s-side door and the front passenger’s-side door lock. But why did 0x03 control two doors and not a different third door? The answer may make more sense when you look at the binary representation:

0x00 = 00000000 0x01 = 00000001 0x02 = 00000010 0x03 = 00000011

The first bit represents the driver’s-side door, and the second represents the front passenger’s-side door. When the bit is a 1, the door locks, and when it’s a 0, it unlocks. When you send an 0x0F, you’re setting all bits that could affect the door lock to a binary 1, thereby locking all doors:

0x0F = 00001111

What about the remaining four bits? The best way to find out what they do is to simply set them to 1 and monitor the vehicle for changes. We already know that at least some of the 0x300 signal relates to doors, so it’s fairly safe to assume the other four bits will, too. If not, they might control different door-like behavior, such as unlatching the trunk.

NOTE

If you don’t get a response when you toggle a bit, it may not be used at all and may simply be reserved.

Getting the Tachometer Reading

Obtaining information on the tachometer (the vehicle’s speed) can be achieved in the same way as unlocking the doors. The diagnostic codes report the speed of a vehicle, but they can’t be used to set how the speed displays (and what fun is that?), so we need to find out what the vehicle is using to control the readings on the instrument cluster (IC).

To save space, the RPM values won’t display as a hex equivalent of the reading; instead, the value is shifted such that 1000 RPM may look like 0xFA0. This value is often referred to as “shifted” because in the code, the developers use bit shifting to perform the equivalent of multiplying or dividing. For the UDS protocol, this value is actually as follows:

To make matters worse, you can’t monitor CAN traffic and query the diagnostic RPM to look for changing values at the same time. This is because vehicles often compress the RPM value using a proprietary method. Although the diagnostic values are set, they aren’t the actual packets and values that the vehicle is using, so we need to find the real value by reversing the raw CAN packets. (Be sure to put the car in park before you do this, and even lift the vehicle off the ground or put it on rollers first to avoid it starting suddenly and crushing you.)

Follow the same steps that you used to find the door unlock control:

  1. Press Record.

  2. Press the gas pedal.

  3. Stop Record.

  4. Press Playback.

  5. See whether the tachometer gauge has moved.

You’ll probably find that a lot of engine lights flash and go crazy during this test because this packet is doing a lot more than just unlocking the car door. Ignore all the blinking warning lights, and follow the flowchart shown in Figure 5-6 to find the arbitration ID that causes the tachometer to change. You’ll have a much higher chance of collisions this time than when trying to find the bit to unlock the doors because there’s a lot more going on. Consequently, you may have to play and record more traffic than before. (Remember the value conversions mentioned earlier, and keep in mind that more than one byte in this arbitration ID will probably control the reported speed.)

Putting Kayak to Work

To make things a bit easier, we’ll use Kayak’s GUI instead of can-utils to find the arbitration IDs that control the tachometer. Again, make sure that the car is immobilized in an open area, with the emergency brake on, and maybe even up on blocks or rollers. Start recording and give the engine a good rev. Then, stop recording and play back the data. The RPM gauge should move; if it doesn’t, you may be on the wrong bus and will need to locate the correct bus, as described earlier in this chapter.

Once you have the reaction you expect from the vehicle, repeat the halving process used to find the door unlock, with some additional Kayak options.

Kayak’s playback interface lets you set the playback to loop infinitely and, more importantly, set the “in” and “out” packets (see Figure 5-7). The slider represents the number of packets captured. Use the slider to pick which packet you start and stop with during playback. You can quickly jump to the middle or other sections of the recording using the slider, which makes playing back half of a section very easy.

Figure 5-7: Kayak playback interface

As for testing, you won’t be able to send only a single packet as you did when you tried to unlock the car because the vehicle is constantly reporting its current speed. To override this noise, you need to talk even faster than the normal communication to avoid colliding all the time. For instance, if you play your packets right after the real packet plays, then the last seen update will be the modified one. Reducing noise on the bus results in fewer collisions and cleaner demos. If you can send your fake packet immediately after the real packet, you often get better results than you would by simply flooding the bus.

To send packets continuously with can-utils, you can use a while loop with cansend or cangen. (When using Kayak’s Send Frame dialog to transmit packets, make sure to check the Interval box.)

The instrument cluster simulator (ICSim) is one of the most useful tools to come out of Open Garages, a group that fosters open collaboration between mechanics, performance tuners, and security researchers (see Appendix A). ICSim is a software utility designed to produce a few key CAN signals in order to provide a lot of seemingly “normal” background CAN noise—essentially, it’s designed to let you practice CAN bus reversing without having to tinker around with your car. (ICSim is Linux only because it relies on the virtual CAN devices.) The methods you’ll learn playing with ICSim will directly translate to your target vehicles. ICSim was designed as a safe way to familiarize yourself with CAN reversing so that the transition to an actual vehicle is as seamless as possible.

Setting Up the ICSim

Grab the source code for the ICSim from https://github.com/zombieCraig/ICSim and follow the README file supplied with the download to compile the software. Before you run ICSim, you should find a sample script in the README called setup_vcan.sh that you can run to set up a vcan0 interface for the ICSim to use.

ICSim comes with two components, icsim and controls, which talk to each other over a CAN bus. To use ICSim, first load the instrument cluster to the vcan device like this:

$ ./icsim vcan0

In response, you should see the ICSim instrument cluster with turn signals, a speedometer, and a picture of a car, which will be used to show the car doors locking and unlocking (see Figure 5-8).

Figure 5-8: ICSim instrument cluster

The icsim application listens only for CAN signals, so when the ICSim first loads, you shouldn’t see any activity. In order to control the simulator, load the CANBus Control Panel like this:

$ ./controls vcan0

The CANBus Control Panel shown in Figure 5-9 should appear.

Figure 5-9: ICSim control interface

The screen looks like a game controller; in fact, you can plug in a USB game controller, and it should be supported by ICSim. (As of this writing, you can use sixad tools to connect a PS3 controller over Bluetooth as well.) You can use the controller to operate the ICSim in a method similar to driving a car using a gaming console, or you can control it by pressing the corresponding keys on your keyboard (see Figure 5-9).

NOTE

Once the control panel is loaded, you should see the speedometer idle just above 0 mph. If the needle is jiggling a bit, you know it’s working. The control application writes only to the CAN bus and has no other way to communicate with the icsim. The only way to control the virtual car is through the CAN.

The main controls on the CANBus Control Panel are as follows:

Accelerate (up arrow) Press this to make the speedometer go faster. The longer you hold the key down, the faster the virtual vehicle goes.

Turn (left/right arrows) Hold down a turn direction to blink the turn signals.

Lock (left SHIFT), Unlock (right SHIFT) This one requires you to press two buttons at once. Hold down the left SHIFT and press a button (A, B, X, or Y) to lock a corresponding door. Hold down the right SHIFT and press one of the buttons to unlock a door. If you hold down left SHIFT and then press right SHIFT, it will unlock all the doors. If you hold down right SHIFT and press left SHIFT, you’ll lock all the doors.

Make sure you can fit both the ICSim and the CANBus Control Panel on the same screen so that you can see how they influence each other. Then, select the control panel so that it’s ready to receive input. Play around with the controls to make sure that the ICSim is responding properly. If you don’t see a response to your controls, ensure that the ICSim control window is selected and active.

Reading CAN Bus Traffic on the ICSim

When you’re sure everything is working, fire up your sniffer of choice and take a look at the CAN bus traffic, as shown in Figure 5-10. Try to identify which packets control the vehicle, and create scripts to control ICSim without using the control panel.

Most of the changing data you see in Figure 5-10 is caused by a replay file of a real CAN bus. You’ll have to sort through the messages to determine the proper packets. All methods of replay and packet sending will work with ICSim, so you can validate your findings.

Figure 5-10: Screen layout for using ICSim

Changing the Difficulty of ICSim

One of the great things about ICSim is that you can challenge yourself by making it harder to find the target CAN traffic. ICSim supports four difficulty levels—0 through 3, with level 1 as the default. Level 0 is a super simple CAN packet that does the intended operation without any background noise, while level 3 randomizes all the bytes in the packet as well. To have the simulator choose different IDs and target byte positions, use ICSim’s randomize option:

$ ./icsim -r vcan0 Using CAN interface vcan0 Seed: 1419525427

This option prints a randomized seed value to the console screen.

Pass this value into the CANBus Control Panel along with your choice of difficulty level:

$ ./controls -s 1419525427 -l 3 vcan0

You can replay or share a specific seed value as well. If you find one you like or if you want to race your friends to see who can decipher the packets first, launch ICSim with a set seed value like this:

$ ./icsim -s 1419525427 vcan0

Next, launch the CANBus Control Panel using the same seed value to sync up the randomized control panel to the ICSim. If the seed values aren’t the same, they won’t be able to communicate.

It may take you a while to locate the proper packets the first time using ICSim, but after a few passes, you should be able to quickly identify which packets are your targets.

Try to complete the following challenges in ICSim:

  1. Create “hazard lights.” Make both turn signals blink at the same time.

  2. Create a command that locks only the back two doors.

  3. Set the speedometer as close as possible to 220 mph.

Depending on your vehicle, one solution to reverse engineering the CAN bus is OpenXC, an open hardware and software standard that translates proprietary CAN protocols into an easy-to-read format. The OpenXC initiative was spearheaded by the Ford Motor Company—and as I write this, OpenXC is supported only by Ford—but it could work with any auto manufacturer that supports it. (Visit http://openxcplatform.com/ for information on how to acquire a pre-made dongle.)

Ideally, open standards for CAN data such as OpenXC will remove the need for many applications to reverse engineer CAN traffic. If the rest of the automotive industry were to agree on a standard that defines how their vehicles work, it would greatly improve a car owner’s ability to tinker and build on new innovative tools.

Translating CAN Bus Messages

If a vehicle supports OpenXC, you can plug a vehicle interface (VI) in to the CAN bus, and the VI should translate the proprietary CAN messages and send them to your PC so you can read the supported packets without having to reverse them. In theory, OpenXC should allow access to any CAN packet via a standard API. This access could be read-only or allow you to transmit packets. If more auto manufacturers eventually support OpenXC, it could provide third-party tools with more raw access to a vehicle than they would have with standard UDS diagnostic commands.

NOTE

OpenXC supports Python and Android and includes tools such as openxc-dump to display CAN activity.

The fields from OpenXC’s default API are as follows:

• accelerator_pedal_position

• brake_pedal_status

• button_event (typically steering wheel buttons)

• door_status

• engine_speed

• fuel_consumed_since_last_restart

• fuel_level

• headlamp_status

• high_beam_status

• ignition_status

• latitude

• longitude

• odometer

• parking_brake_status

• steering_wheel_angle

• torque_at_transmission

• transmission_gear_position

• vehicle_speed

• windshield_wiper_status

Different vehicles may support different signals than the ones listed here or no signals at all.

OpenXC also supports JSON trace output for recording vehicle journey. JSON provides a common data format that’s easy for most other modern languages to consume, as shown in Listing 5-4.

{"metadata": { "version": "v3.0", "vehicle_interface_id": "7ABF", "vehicle": { "make": "Ford", "model": "Mustang", "trim": "V6 Premium", "year": 2013 }, "description": "highway drive to work", "driver_name": "TJ Giuli", "vehicle_id": "17N1039247929" }

Listing 5-4: Simple JSON file output

Notice how the metadata definitions in JSON make it fairly easy for both humans and a programming language to read and interpret. The above JSON listing is a definition file, so an API request would be even smaller. For example, when requesting the field steering_wheel_angle, the translated CAN packets would look like this:

{"timestamp": 1385133351.285525, "name": "steering_wheel_angle", "value": 45}

You can interface with the OpenXC with OBD like this:

$ openxc-diag –message-id 0x7df –mode 0x3

Writing to the CAN Bus

If you want to write back to the bus, you might be able to use something like the following line, which writes the steering wheel angle back to the vehicle, but you’ll find that the device will resend only a few messages to the CAN bus.

$ openxc-control write –name steering_wheel_angle –value 42.0

Technically, OpenXC supports raw CAN writes, too, like this:

$ openxc-control write –bus 1 –id 42 –data 0x1234

This brings us back from translated JSON to raw CAN hacking, as described earlier in this chapter. However, if you want to write an app or embedded graphical interface to only read and react to your vehicle and you own a new Ford, then this may be the quickest route to those goals.

Hacking OpenXC

If you’ve done the work to reverse the CAN signals, you can even make your own VI OpenXC firmware. Compiling your own firmware means you don’t have any limitations, so you can read and write whatever you want and even create “unsupported” signals. For example, you could create a signal for remote_engine_start and add it to your own firmware in order to provide a simple interface to start your car. Hooray, open source!

Consider a signal that represents engine_speed. Listing 5-5 will set a basic configuration to output the engine_speed signal. We’ll send RPM data with a 2-byte-long message ID 0x110 starting at the second byte.

{ "name" : "Test Bench", "buses": { "hs": { "controller": 1, "speed": 500000 } }, "messages": { "0x110": { "name": "Acceleration", "bus", "hs", "signals": { "engine_speed_signal": { "generic_name": "engine_speed", "bit_position": 8, "bit_size": 16 } } } } }

Listing 5-5: Simple OpenXC config file to define engine_speed

The OpenXC config files that you want to modify are stored in JSON. First, we define the bus by creating a JSON file with a text editor. In the example, we create a JSON config for a signal on the high-speed bus running at 500Kbps.

Once you have the JSON config defined, use the following code to compile it into a CPP file that can be compiled into the firmware:

$ openxc-generate-firmware-code –message-set ./test-bench.json > signals.cpp

Then, recompile the VI firmware with these commands:

$ fab reference build

If all goes well, you should have a .bin file that can be uploaded to your OpenXC-compatible device. The default bus is set up in raw read/write mode that sets the firmware to a cautionary read-only mode by default, unless signals or a whole bus is set up to support writing. To set those up, when defining the bus, you can add raw_can_mode or raw_writable and set them to true.

By making your own config files for OpenXC, you can bypass the restrictions set up in prereleased firmware and support other vehicles besides Ford. Ideally, other manufacturers will begin to support OpenXC, but adoption has been slow, and the bus restrictions are so strict you’ll probably want to use custom firmware anyhow.

Fuzzing the CAN bus can be a good way to find undocumented diagnostic methods or functions. Fuzzing takes a random, shotgun-like approach to reversing. When fuzzing, you send random-ish data to an input and look for unexpected behavior, which in the case of a vehicle could be physical changes, such as IC messages, or component crashes, such as shutdowns or reboots.

The good news is that it’s easy to make a CAN fuzzer. The bad news is that it’s rarely useful. Useful packets are often part of a collection of packets used to cause a particular change, such as a diagnostic service that is active only after a successful security token has been passed to it, so it’s difficult to tell which packet to focus on when fuzzing. Also, some CAN packets are visible only from within a moving vehicle, which would be very dangerous. Nevertheless, don’t rule out fuzzing as a potential method of attack because you can sometimes use it to locate undocumented services or crashes to a target component you want to spoof.

Some sniffers support fuzzing directly—a feature usually found in the transmission section and represented by the tool’s ability to transmit packets with incrementing bytes in the data section. For example, in the case of SocketCAN, you can use cangen to generate random CAN traffic. Several other open source CAN sniffing solutions allow for easy scripting or programming with languages such as Python.

A good starting point for fuzzing is to look at the UDS commands, specifically the “undocumented” manufacturer commands. When fuzzing undocumented UDS modes, we typically look for any type of response from an unknown mode. For instance, when targeting the UDS diagnostics of the ECU, you might send random data to ID 0x7DF and get an error packet from an unexpected mode. If you use brute-forcing tools such as CaringCaribou, however, there are often cleaner ways of accomplishing the same thing, such as monitoring or reversing the diagnostic tools themselves.

The CAN bus and its components are fault-tolerant, which limits the damage you can do when reversing the CAN bus. However, if you’re fuzzing the CAN bus or replaying a large amount of CAN data back on a live CAN bus network, things can go wrong. Here are a few common problems and solutions.

Flashing IC Lights

It’s common for the IC lights to flash when sending packets to the CAN bus, and you can usually reset them by restarting the vehicle. If restarting the vehicle still doesn’t fix the lights, try disconnecting and reconnecting the battery. If that still doesn’t fix the problem, make sure that your battery is properly charged since a low battery can also make the IC lights flash.

Car Not Turning On

If your car shuts off and won’t turn back on, it’s usually because you’ve drained the battery by working with the CAN bus while the car is not fully running. This can drain a battery much faster than you might think. To restart it, jump the vehicle with a spare battery.

If you’ve tried jumping the vehicle and it still won’t turn on, you may need to pull a fuse and plug it back in to restart the car. Locate the engine fuses in the car’s manual and begin by pulling the ones you most suspect are the culprits. The fuse probably isn’t blown, so just pull it out and put it back in to force the problem device to restart. The fuses you choose to pull will depend on your type of vehicle, but if your engine isn’t starting, you will want to locate major components to disconnect and check. Look for main fuses around major electronics. The fuses that control the headlamps probably are not the culprits. Use a process of elimination to determine the device that is causing the issue.

Car Not Turning Off

You might find that you’re unable to shut the car down. This is a bad, but fortunately rare, situation. First, check that you aren’t flooding the CAN bus with traffic; if you are, stop and disconnect from the CAN bus. If you’re already disconnected from the CAN bus and your car still won’t turn off, you’ll need to start pulling fuses until it does.

Vehicle Responding Recklessly

This will only occur if you’re injecting packets in a moving vehicle, which is a terrible idea and should never be done! If you must audit a vehicle while it’s wheels are moving, raise it off the ground or on rollers.

Bricking

Reverse engineering the CAN bus should never result in bricking—that is, breaking the vehicle so completely that it can do nothing. To brick a vehicle, you would need to mess around with the firmware, which would put the vehicle or component out of warranty and is done at your own risk.

In this chapter, you learned how to identify CAN wires from the jumble of wires under the dash, and how to use tools like cansniffer and Kayak to sniff traffic and identify what the different packets were doing. You also learned how to group CAN traffic to make changes easier to identify than they would be when using more traditional packet-sniffing tools, such as Wireshark.

You should now be able to look at CAN traffic and identify changing packets. Once you identify these packets, you can write programs to transmit them, create files for Kayak to define them, or create translators for OpenXC to make it easy to use dongles to interact with your vehicle. You now have all the tools you need to identify and control the components of your vehicle that run on CAN.

by Dave Blundell

A vehicle typically has as many as a dozen or more electronic controllers, many of which are networked to communicate with each other. These computerized devices go by many different names, including electronic control unit or engine control unit (ECU), transmission control unit (TCU), or transmission control module (TCM).

While these terms may have specific meanings in a formal setting, similar terms are often used interchangeably in practice. What may be a TCU to one manufacturer is a TCM to another, yet both electronic controllers perform the same or extremely similar functions.

Most automotive control modules have measures in place to prevent you from altering their code and operation; these range from very strong to laughably weak. You won’t know what you’re dealing with until you investigate a particular system. In this chapter, we’ll take a closer look at particular security mechanisms, but first we’ll examine strategies for gaining access to these systems. Then in Chapter 8 we’ll look at some more specific ECU hacks, like glitch attacks and debugging. The attack vectors for ECUs fall into three different classes:

Front door attacks Commandeering the access mechanism of the original equipment manufacturer (OEM)

Backdoor attacks Applying more traditional hardware-hacking approaches

Exploits Discovering unintentional access mechanisms

We’ll look at an overview of these attack classes, and then analyze the data you find. It’s worth remembering that while the goal for ECU and other control module hacking is often the same—to gain access in order to reprogram and change behavior—it’s unlikely there’ll be a “master key” for all controllers. However, OEMs are generally not very creative and seldom change their ways, so insight into one controller likely applies to similar models from the same manufacturer. Also, few of today’s auto manufacturers develop their own automotive computers from scratch, instead licensing prefabricated solutions from third parties like Denso, Bosch, Continental, and others. Because of this design methodology, it’s relatively common to see vehicles from different auto manufacturers using very similar computer systems sourced from the same vendors.

The OBD-II standard mandates that you be able to reprogram vehicles through the OBD-II connector, and reverse engineering the original method for programming is a guaranteed attack vector. We’ll examine J2534 and KWP2000 as examples of common protocols for programming.

J2534: The Standardized Vehicle Communication API

The SAE J2534-1 standard, or simply J2534, was developed to promote interoperability among digital tool vendors through the use of the J2534 API, which outlines the recommended way for Microsoft Windows to communicate with a vehicle. (You can purchase the J2534 API from the SAE at http://standards.sae.org/j2534/1_200412/.) Prior to the adoption of the J2534 standard, each software vendor created its own proprietary hardware and drivers for communicating with a vehicle in order to perform computerized repairs. Because these proprietary tools weren’t always available to smaller shops, the EPA mandated the adoption of the J2534 standard in 2004 to allow independent shops access to the same specialized computer tools used by dealerships. J2534 introduced a series of DLLs that map standard API calls to instructions necessary to communicate with a vehicle, thereby allowing multiple manufacturers to release software designed to work with J2534-compatible hardware.

Using J2534 Tools

J2534 tools provide a convenient way to observe OEM tools interacting with vehicle computers. Manufacturers often leverage J2534 to update computer firmware and sometimes to provide powerful diagnostic software. By observing and capturing information exchanged with a vehicle using J2534, you can see how OEMs perform certain tasks, which may provide you with information that you need to unlock the “front door.”

When using J2534 tools to attack vehicle systems, the basic idea is to observe, record, analyze, and extend functionality. Of course, the first step is to obtain and configure a J2534 application and its corresponding interface hardware in order to perform a task you want to observe. Once you have your setup, the next step is to observe and record communications with the target while using the J2534 tools to perform an action on the target, like updating a configuration parameter.

There are two primary ways to observe J2534 transactions: by watching J2534 API calls on a PC using J2534 shim DLLs or by watching actual bus traffic using a separate sniffer tool to capture data.

J2534 tools are key to eavesdropping on the protocols built into the factory embedded vehicle systems, and they’re one of the primary ways to attack the front door. Successful analysis of this communication will give you the knowledge you need to access vehicle systems the way the OEMs do. It’ll also allow you to write applications with full access to read and reprogram systems, which will in turn enable you to communicate directly with a vehicle without having to use the J2534 interface or the OEM’s J2534 software.

J2534 Shim DLLs

The J2534 shim is a software J2534 interface that connects to a physical J2534 interface and then passes along and logs all commands that it receives. This dummy interface is a kind of man-in-the-middle attack that allows you to record all API calls between the J2534 application and the target. You can then examine the log of commands to determine the actual data exchanged between the J2534 interface and the device.

To find an open source J2534 shim, search code.google.com for J2534-logger. You should also be able to find precompiled binaries.

J2534 with a Sniffer

You can also use J2534 to generate interesting traffic that you can then observe and record with a third party sniffer. There’s no magic here: this is just an excellent example of how to generate juicy packets that might otherwise be difficult to capture. (See Chapter 5 for more information on monitoring network traffic.)

KWP2000 and Other Earlier Protocols

Before J2534, there were many flash-programmable ECUs and other control units, such as the Keyword Protocol 2000 (KWP2000 or ISO14230). From an OSI networking perspective, it’s primarily an application protocol. It can be used on top of CAN or ISO9141 as the physical layer. You’ll find a huge number of KWP2000 flasher tools that interface with a PC using a serial/ USB-serial interface and that support diagnostics and flashing using this protocol just by searching online. (For more on the Keyword Protocol 2000, see Chapter 2.)

Capitalizing on Front Door Approaches: Seed-Key Algorithms

Now that we’ve discussed how legitimate tools use the front door, it’s time to capitalize on this attack vector by learning how to operate the figurative “lock on the gate.” To do this, we must understand the algorithm that the embedded controller uses to authenticate valid users; this is almost always a seed-key algorithm. Seed-key algorithms usually generate a pseudorandom seed and expect a particular response, or key, for each seed before allowing access. A typical valid exchange could look something like this:

ECU seed: 01 C3 45 22 84 Tool key: 02 3C 54 22 48

or this:

ECU seed: 04 57 Tool key: 05 58

Unfortunately, there’s no standard seed-key algorithm. You might have a 16-bit seed and 16-bit key, a 32-bit seed and 16-bit key, or a 32-bit seed and 32-bit key. The algorithm that generates a key from a given seed also varies from platform to platform. Most algorithms are a combination of simple arithmetic operations and one or more values used as part of the computation. There are several techniques for figuring out these algorithms in order to give you access to the ECU:

• Obtain the firmware for the device in question through other means. Disassemble it and analyze the embedded code to find the code responsible for generating seed-key pairs.

• Obtain a legitimate software tool—for example, J2534 reflash software—that’s capable of generating legitimate seed-key pairs, and analyze the PC application code with a disassembler to determine the algorithm used.

• Observe a legitimate tool exchanging keys, and analyze the pairs for patterns.

• Create a device to spoof a legitimate tool into providing responses repeatedly. The main advantage of this method over purely passive observation is that it allows you to pick seeds for which you can reproduce the keys.

You can find more information about reverse engineering the seed-key algorithms used by General Motors at http://pcmhacking.net/forums/viewtopic.php?f=4&t=1566&start=10, and those used by VAG MED9.1 at http://nefariousmotorsports.com/forum/index.php?topic=4983.0.

Sometimes front door attacks are too tricky; you may not have the right tools or the lock might be too hard to figure out. Don’t despair—remember that automotive control modules are embedded systems, so you can use all the usual hardware-hacking approaches. In fact, using more direct-to-hardware backdoor approaches often makes more sense than trying to reverse engineer the front door lock placed by the factory, especially when trying to reprogram engine modules. If you can obtain a dump of the module, you can often disassemble and analyze it to figure out how the keys to the front door work. The first step in a hardware backdoor attack is analyzing the circuit board.

When reversing a circuit board of any system, you should start with the largest chips first. These larger processor and memory chips are likely to be the most complex. It’s a good idea to make a list of part numbers to feed to Google, datasheet.com, or something similar, to obtain a copy of the data sheet. You’ll sometimes encounter custom application-specific integrated circuits (ASICs) and one-off chips, especially with older ECUs, which will prove more difficult than off-the-shelf parts. In many cases, you’ll have to infer the function of these parts based on how they’re connected to identifiable parts.

It’s critical to look out for memory chips—SRAM, EEPROM, FlashROM, one-time-programmable ROM, serial EEPROM, serial flash, NVSRAM, and so on. The type of memory used varies immensely from one platform to another; every single variety listed here has been found in the wild. Newer designs are less likely to have parallel memories and more likely to have serial chips. Newer microcontrollers are less likely to have any external memories at all, as their internal flash capacities have dramatically increased. Any nonvolatile memory chip present can be removed from the circuit board, read, and then replaced. Chapter 8 goes into much more detail on reverse engineering the circuit board.

Although arguably just another example of a backdoor approach, exploits deserve special attention. Rather than taking apart a computer, exploits involve feeding a system carefully crafted inputs to make it do things outside normal operation. Typically, exploits build on a bug or problem. This bug might cause a system to crash, reboot, or perform some undesirable behavior from the perspective of the vehicle user. Some of these bugs present the opportunity for buffer overflow attacks, which open the door for commandeering the vulnerable device merely by feeding it unexpected inputs. A cleverly crafted set of inputs triggers the bug, which then makes the device execute arbitrary code provided by the attacker instead of triggering the usual fault condition.

Not all bugs can be turned into exploits, however—some bugs only cause problems or shut down core systems. And while bugs are usually discovered by accident, most exploits require careful craft. It is unlikely that you’d be able to turn a known bug into an exploit without also having prior knowledge of the system, usually gained from firmware analysis. At a bare minimum, you’d need basic knowledge of the architecture in order to write the necessary code. Most of the time, this knowledge needs to be gathered through research prior to writing an exploit.

It’s hard to find bugs that make suitable attack vectors and it’s often just as difficult to write exploits for them, so exploits that build on bugs are fairly uncommon. While it is foolish to discount the relevance of exploits, the other methods presented here and in Chapter 8 are much more practical paths to understanding and reprogramming automotive systems in most cases.

Hacking into an automotive control module far enough to retrieve its current firmware and configuration is really just the beginning of the adventure. At this point, you probably have anywhere from 4KB to 4MB of raw machine-ready code, with a mixture of various parameters and actual code that forms the program the processor will run. Let’s say you have a binary blob in the firmware from one of the hacks in this chapter or the chapters later in this book. Next you need to disassemble the binary.

First, you must know which chip this binary is for. There are several free decompilers for different chips out on the Internet. Otherwise you can drop some cash and buy IDA Pro, which supports a large variety of chips. These tools will convert the hex values in the binary into assembler instructions. The next stage is to figure out what exactly you are looking at.

When you’re starting to analyze raw data, a high-level understanding of the function of the devices you’re reverse engineering will be key to knowing what to look for. You can follow a number of breadcrumbs, or clues, for starters; these breadcrumbs are almost guaranteed to lead you to interesting and useful material. Next, we’ll look at a few specific examples of how to use common automotive controller functions to gain insight into their operation, which will hopefully allow us to change their behavior.

Self-Diagnostic System

Every engine controller has some type of self-diagnostic system that typically monitors most critical engine functions, and analyzing this is an excellent route to understanding firmware. A good first step in investigative disassembly is to identify the location of these procedures. This will provide you with insight into the memory locations involved in all of the sensors and functions that are checked for errors. Any modern vehicle should support OBD-II packets, which standardize the diagnostic data reported. Even controllers created prior to OBD-II standards have a way to report faults. Some have a system where an analog input is shorted to ground and either an internal LED or the “check engine” light flashes out the code. For example, knowing that code 10 refers to a failed intake air temperature sensor means you can find the piece of code that sets error code 10 to help you identify the internal variables associated with the air temperature sensor.

For more detailed information on using diagnostics, see Chapter 4.

Library Procedures

Being able to change the behavior of a control unit is often one of the primary goals of reverse engineering ECU firmware, and identifying data used by a controller is an important step in the process. Most ECUs have a set of library functions used for routine tasks throughout the code. Library functions used for table lookups are worth identifying early on in the reverse engineering process, as these can lead straight to the parameters you’re interested in. Each time a table is used, a function is called to fetch a result. Calls to this type of function are among the most frequent, making them easy to spot.

Usually each type of data stored within the ECU—one-dimensional array of bytes; two-dimensional array of words; three-dimensional array of unsigned, signed, and float shorts; and so on—has a unique reference function. When called, each table lookup routine needs to be passed, at a minimum, the table index (or start address) and the axis variables. Often, table lookup routines can be reused to pass information about the structure of the table, such as how many rows and columns are present.

Calibration data is usually stored in program memory, along with the routines accessing them. Microcontrollers typically have special instructions to access program memory, which provide a unique signature to search for and make table lookup routines particularly easy to spot. A secondary characteristic of these lookup routines is that they tend to have lots of interpolation math. In addition, table lookup routines are often grouped closely together in program memory, making it even easier to find others after you’ve found one. After identifying reference routines, searching for all calls to them can provide a key to identifying the vast majority of data used by the controller to make decisions. The arguments passed to these functions typically include the start address of a table, its structure or shape, and which variables index elements of the table. Armed with this information, you’re much closer to being able to change the behavior of the controller.

Finding Known Tables

One way to identify tables is to leverage the specific physical and electrical characteristics of vehicle sensors, which will display identifiable characteristics within ECU firmware. For example, an ECU with a MAF sensor will have a table that translates raw readings of voltage or frequency from the MAF into airflow into the engine, providing an internal representation.

Fortunately for us, the signal output from an MAF is determined by physics—that is, King’s Law—so the curve will always have a characteristic shape, though it’ll be slightly different for each sensor. This will result in the tables having a characteristic set of values that can be observed in the ROM. Armed with the knowledge that there will be universal data to identify, let’s take a closer look at how calibration data is displayed in different programs.

Figures 6-1 and 6-2 show similarly shaped Ford and Nissan sensor curves; the similarity they illustrate extends to multiple manufacturers.

Figure 6-1: Ford MAF transfer graph

Figure 6-2: Nissan MAF VQ graph

Figures 6-2 through 6-6 show five different views of the same data. Figure 6-3 shows how the VQ curve pictured in Figure 6-2 would look in a hex editor.

Figure 6-3: VQ table in HxD hex editor: 128 bytes or 64- to 16-bit words

Figures 6-4 and 6-5 show the VQ table in analyze.exe available from https://github.com/blundar/analyze.exe/. A simple visualization tool, analyze.exe colors cells based on their numeric value. You can select the precision of the data—for example, 1 = 8-bit byte, 2 = 16-bit word, and 4 = 32-bit long—and how many rows and columns you want present. This simple visual arrangement often makes it easier to identify what is code and what is data than it is when you’re using a hex editor, as in Figure 6-3.

Figure 6-4: VQ table in analyze.exe: values from 48 to 65535 in first four rows of 16×16-bit values

Figure 6-5: First four rows of 16x16-bit values

Look again at the first four rows of 16×16-bit values in Figures 6-4 and 6-5 shaded in analyze.exe. Notice how the smooth nonlinear curve in Figures 6-1 and 6-2 mimics the smooth nonlinear progression of values. Figure 6-6 shows the same values in a 64-column layout, so you can see the full gradient of the first four rows from Figure 6-5. No matter what type of vehicle you’re looking at, the overall data structures will be similar.

Figure 6-6: 64- to 16-bit words per row

Data visualization tools like hex editors or analyze.exe can also be useful when you don’t know the exact shape or pattern you are looking for. No matter what type of vehicle you’re looking at, data structures will have orders and patterns that are not typically seen in executable code. Figure 6-7 shows an example of the clear visual pattern of data in analyze.exe—gradually changing values and repetition should stand out.

Figure 6-7: Patterns and gradual changes in table data appear in a 2002 Chevrolet Camaro ROM visualized with analyze.exe

On the other hand, when you look at code like that in Figure 6-8, there is a more random, chaotic appearance. (In Figures 6-7 and 6-8, precision is set to 2 because the microcontroller unit used is a 16-bit processor and it’s reasonable to assume that a good chunk of the data items will be 16-bit as well.)

Figure 6-8: This random code doesn’t have the neat, orderly patterns that are present in most tables.

More to Learn from the MCU

Hopefully, these examples help connect knowledge of the table data you expect to find with their representation within a binary blob. Learning the capabilities of the microcontroller unit (MCU) used in a target system can shed light on the types of data to expect when looking over the binary data.

Generally, data representation formats are dictated by the hardware present. Knowing the size of registers on the MCU running the show can be a big help for identifying parameters. Most parameters tend to be the same size as or smaller than the registers of a given MCU. An 8-bit MCU, like a 68HC11, is likely to have lots of 8-bit data. It’s unusual to see mostly 4-byte, or 32-bit, unsigned long integers on an 8-bit MCU. While 16-bit data becomes more common on MCUs like the 68332, 32-bit data becomes the norm with MPC5xx Power Architecture MCUs and so on. It’s unusual to find floating-point data on an MCU that lacks a floating-point processor.

Comparing Bytes to Identify Parameters

It’s often possible to get multiple bins that’ll run on the same physical ECU. The more the better! Doing a simple compare in a hex editor will show which bytes differ between the files. It’s common—but not guaranteed—for code to remain unchanged while parameters change. If less than 5 percent of the files differ, it’s generally safe to assume that the differences are parameters. If you know what’s been changed functionally between the two bins and you know which bytes have changed, you have further clues to help correlate changes in the ROM with changes in parameters.

Figures 6-9 and 6-10 compare a 1996 V8 Mustang and a 1997 V6 Thunderbird, showing 6,667 differences out of 114,688 bytes. This is an extreme example of having the same code with different parameters, but there’s still only about a 5.8 percent difference compared to overall file size.

Most processors use an interrupt vector table defined by the processor being used. Referencing the processor’s data sheet will define the structure of interrupt routines, allowing you to quickly identify the interrupt handlers. Tracing interrupt pins on the processor to circuitry within the ECU to pins you can reference in a vehicle wiring diagram can help you identify code blocks used to service such hardware functions as fuel and spark control, crank and cam signal processing, and idle functions.

Figure 6-9: Comparison of a 1996 V8 Mustang (DXE2.bin) and a 1997 V6 Thunderbird (SPP3.bin)

Figure 6-10: File compare function of the HxD hex editor

Identifying ROM Data with WinOLS

WinOLS is a popular commercial program for modifying bins. It combines a series of tools for calculating and updating checksums within a ROM with a set of tools for identifying tables. Figures 6-11 and 6-12 illustrate WinOLS in use.

If the ROM type is known, it has many templates that automatically identify configuration parameters. Most of the known built-in ROM types are geared toward Bosch Motronic ECUs. Templates and configurations can be saved, shared, and sold to enable users to make modifications to specific files with greater ease. WinOLS is arguably the most common software used for identifying interesting data within a ROM that doesn’t involve code analysis. It’s designed to facilitate rapid tuning changes to a controller.

Figure 6-11: WinOLS supports 2D and 3D table views, as shown in these alternate views.

Figure 6-12: WinOLS being used on a 2006 Volkswagen 2.0Tsi ECU

Code analysis can be a long, complicated task. If you’re starting from scratch, with no experience, it will likely take hundreds of hours to analyze a complex piece of code. Modern control units often have upward of a megabyte or two of code, which is a huge amount of code when you’re looking at it in assembly. An ECU from 1995 with 32 kilobytes (not megabytes) of code will have upward of 10,000 assembly instructions to sort out. Bottom line: do not underestimate how much work this approach will take. I’ll briefly introduce a few tools, but I don’t have the space to address the topic in sufficient depth for someone unfamiliar with the process. (After all, entire books have been written solely on code analysis.) Here, I’ll just talk through specific tools and methods particularly applicable to automotive embedded systems.

When analyzing a new target, first identify the architecture you’re working with. Knowing what processor executed the blob of binary will help you choose an appropriate software tool to further assist. If you can’t identify a processor based on the markings on the chip itself, search online for data sheets to identify it.

To analyze code, you might need to find a disassembler. A quick Google search reveals that there are lots of them out there. Some target a single architecture—for example, Dis51—and some are custom-written for automotive reverse engineering—for example, Dis66k. Others, like CATS dasm, IDA Pro, Hopper, dasmx, and objdump from the GNU Binary Utilities (binutils), target multiple processors. IDA Pro supports more embedded targets than just about any other program, but it’s also one of the most expensive disassemblers. GNU binutils also supports a pretty wide range of architectures, but the version included on most systems will be built only for the “native” architecture. Rebuilding binutils with all architectures enabled will open a few doors. Your budget and supported processors will determine which disassemblers are an option.

Bust out the disassembly tools and start trying to make sense of the mess, but as I warned earlier, this might take hundreds of hours. A divide-and-conquer mentality works best—focus on the smaller tasks rather than the project as a whole. If you obtained the binary by backdoor methods, you probably already took the ECU apart to identify the processor. If you cracked the J2534 programming routines, you might not have a clue what processor is running the show. In this case, you’re going to need to keep running it through a disassembler over and over using different settings until you get something that makes sense.

You’re looking for assembly code that disassembles cleanly, meaning that it looks like it makes logical sense. If you disassemble a binary for the wrong architecture or using the wrong settings, you’ll still see assembly instructions, but the assembler actions won’t make sense. Disassembly is a bit of an art, and it may take a little practice at seeing a “clean” assembler to get the hang of identifying when a dissassembler is providing the correct response, especially when nonexecutable tables and data are scattered among the code.

Here are some hints for making sense of disassembled code:

• OEMs love to patent stuff. If you can find the patents relevant to your system, you may end up with a guided tour of the code being disassembled. This is probably the most consistently available high-level procedural guide to help you understand the logic in an automotive computer. Patents usually lead production by at least one to two years, if not more.

• Look at any available software for manipulating the ECU at hand for insight into the structure and purpose of code segments. You can often infer a model of behavior from tables available to be modified in aftermarket software.

• Otherwise, start with a wiring diagram for the vehicle, and trace connections back through ECU circuitry to particular pins on the MCU. This should tell you which piece of MCU hardware handles which function. Cross reference the interrupt tables, or look for calls to service particular pieces of hardware in order to identify which piece(s) of code service that hardware function.

A plain, or old-style, disassembler will output very verbose text. Each individual instruction is parsed. Some disassemblers will attempt to mark areas referenced as data and void disassembling them. Other disassemblers need to be specifically told which areas are code and which areas are data.

A Plain Disassembler at Work

To see disassembly in action, we’ll look at a plain disassembly of a 1990 Nissan 300ZX Twin Turbo ROM. This ECU has a 28-pin external 27C256 EPROM, so it’s relatively easy to obtain its contents. This particular platform uses a HD6303 MCU, a derivative of the Motorola 6800 8-bit MCU that appears to be supported by the free disassembler DASMx (see http://www.16paws.com/ECU/DASMxx/DASMx.htm). DASMx comes with minimal instructions: to disassemble foo.bin, create a file, foo.sym, that describes which platform is in use, and then create an entry point in memory to place the image, symbols you know about, and so on. Time for a crash course in the architecture!

A critical point about the memory structure is that the MCU can address 65535 bytes (64KB). This information tells you what to expect when looking at the addresses in your binary blob. Further reading suggests that the interrupt vector table lies at the end of addressable memory, with the reset vector—where every processor starts after a reset—at 0xFFFE/0xFFFF. Assuming that the 32KB (0x7FFF hex) binary blob we have from reading the EPROM contains the interrupt vector table, we can figure out that the binary image needs to start at memory address 0x8000 for it to end at 0xFFFF (0xFFFF – 0x7FFF = 0x8000). It also helps to search online to see whether others are trying to do something similar. For example, the post at http://forum.nistune.com/viewtopic.php?f=2&t=417 is for a smaller 16KB binary based on settings for a 0xC000 entry point. The more legwork and research you do prior to actually invoking a disassembler, the more likely you are to get reasonable results.

Figure 6-13 shows the symbol table for the 300ZX binary. Next to each symbol is the memory address used by the firmware. These memory addresses can hold values such as incoming data from different physical pins on the chip or internal information, like timing.

Figure 6-13: Symbol file for 32KB 300ZX binary disassembly with DASMx

We’ll use DASMx to disassemble the binary. As shown in Figure 6-14, DASMx reports a Hitachi 6303 MCU with a source file length, or size, of 32KB, which is 32768 bytes.

Figure 6-14: Running DASMx to disassemble 32KB 300ZX binary

Now cross your fingers and hope for a meaningful result!

The result is the vector table shown in Figure 6-15, which looks sane enough: all addresses are above the 0x8000 entry point specified. Notice that the reset vector (0xFFFE, RES-vector) has a pointer to the RESET_entry at 0xBE6D.

Figure 6-15: Disassembled vector table

We can disassemble the code at 0xBE6D for the reset vector, which is also the entry point for code. In Figure 6-16, we see a routine, RESET_entry, that looks like it wipes a chunk of RAM. This is a plausible part of the initial reset sequence because often when booting, firmware will initialize the data region to all 0s.

Figure 6-16: Reset vector disassembly

We’ve taken this example as far as obtaining a disassembled binary image and looking for basic sanity. Now, for the hard part: following the code, breaking it into routines, and trying to figure out how it works.

Interactive Disassemblers

As of this writing, IDA Pro is the most popular interactive disassembler available. It performs the same tasks as the simple disassembler just discussed, and more. Specifically, IDA Pro names registers and variables; once IDA Pro identifies and names a variable, or memory address—for instance, $FC50–RPM—it gives all references to that variable within the code a descriptive name rather than a less-recognizable plain hex address. IDA Pro also graphs code to visualize program flow.

One of the advantages of IDA Pro is that it’s programmable to allow additional opcodes for customizing automotive processors and plugins for further processing disassembled code (for example, decompiling assembly into higher language code); it also lets you use structs, unions, classes, and other user-defined data types.

Lastly, IDA Pro supports more embedded platforms out of the box than just about any other disassembler currently available.

You don’t necessarily need these functions to successfully analyze code, but they make things substantially easier. Figures 6-17 and 6-18 are screenshots from real code analysis with IDA Pro. Thanks to Matt Wallace for graciously posting these examples in a public forum.

The user in Figure 6-18 obtained Acura NSX ECU firmware through a combination of hardware-hacking approaches, took the code apart, analyzed it using IDA Pro, and rewrote it. Next, the user determined the necessary functions to log data from the ECU and alter its operation. The result allowed the user to use forced induction—that is, turbochargers and superchargers—with a factory computer; this would have been impossible without ECU modification.

Figure 6-17: IDA diagram showing a custom-written routine for NVRAM real-time programming

Figure 6-18: IDA diagram of code for checking fuel injectors on NSX ECU

Because hacking on the ECU often involves processors that are smaller than those used in more powerful modern devices, such as cell phones, the tools used for reversing the firmware differ for each target. By using a combination of techniques, such as data visualization to locate tables, and by reversing the firmware directly, you can identify the areas you’re interested in modifying. The methods discussed in this chapter are techniques commonly used by performance tuners to adjust how a vehicle handles fuel efficiency. All can be used to unlock features hidden in the code of your vehicle. We’ll look at performance tuning in more detail in Chapter 13.

An ECU test bench, like the one shown in Figure 7-1, consists of an ECU, a power supply, an optional power switch, and an OBD-II connector. You can also add an IC or other CAN-related systems for testing, but just building a basic ECU test bench is a great way to learn the CAN bus and how to create custom tools. In this chapter, we’ll walk step by step through the process of building a test bench for development and testing.

The most basic test bench is the device that you want to target and a power supply. When you give an ECU the proper amount of power, you can start performing tests on its inputs and communications. For example, Figure 7-1 shows a basic test bench containing a PC power supply and an ECU.

Figure 7-1: A simple ECU test bench

However, you’ll often want to at least add some components or ports to make the test bench easier to use and operate. To make it easier to turn the device on and off, you can add a switch to the power supply. An OBD port allows for specialized mechanics tools to communicate with the vehicle’s network. In order for that OBD port to fully function, we need to expose the vehicle’s network wires from the ECU to the OBD port.

Finding an ECU

One place to find an ECU is, of course, at the junkyard. You’ll typically find the ECU behind a car’s radio in the center console or behind the glove box. If you’re having trouble finding it, try using the massive wiring harness to trace back to the ECU. When pulling one out yourself (it should cost only about $150), be sure to pull it from a vehicle that supports CAN. You can use a reference website such as http://www.auterraweb.com/aboutcan.html to help you identify a target vehicle. Also, make sure you leave at least a pigtail’s worth of wiring when you remove the ECU; this will make it easier to wire up later.

If you’re not comfortable pulling devices out of junked cars, you can order an ECU online at a site like car-part.com. The cost will be a bit higher because you’re paying for someone else to get the part and ship it to you. Be sure that the ECU you buy includes the wire bundles.

NOTE

One downside to buying an ECU online is that it may be difficult to acquire parts from the same car if you need multiple parts. For instance, you may need both the body control module (BCM) and the ECU because you want to include keys and the immobilizer is in the BCM. In this case, if you mix and match from two different vehicles, the vehicle won’t “start” properly.

Instead of harvesting or buying a used ECU, you could also use a prebuilt simulator, like the ECUsim 2000 by ScanTool (see Figure 7-2). A simulator like ECUsim will cost around $200 per protocol and will support only OBD/UDS communications. Simulators can generate faults and MIL lights, and they include fault knobs for changing common vehicle parameters, such as speed. Unless you’re building an application that uses only UDS packets, however, a simulator probably isn’t the way to go.

Figure 7-2: ECUsim OBD simulator

Dissecting the ECU Wiring

Once you have all of the parts, you’ll need to find the ECU’s wiring diagram to determine which wires you need to connect in order to get it to work. Visit a website such as ALLDATA (http://www.alldata.com/) or Mitchell 1 (http://mitchell1.com/main/) to get a complete wiring diagram. You’ll find that off-the-shelf service manuals will sometimes have wiring diagrams, but they’re often incomplete and contain only common repair areas.

Wiring diagrams aren’t always easy to read, mainly because some combine numerous small components (see Figure 7-3). Try to mentally break down each component to get a better idea of which wires to focus on.

Figure 7-3: Example of an ECU wiring diagram

Pinouts

You can get pinouts for the ECUs on several different vehicles from http://www.innovatemotorsports.com/resources/ecu_pinout.php and from commercial resources like ALLDATA and Mitchell 1. Books like the Chilton auto repair manuals include block diagrams, but you’ll find that they typically cover only the most common repair components, not the entire ECU.

Block Diagrams

Block diagrams are often easier to read than wiring diagrams that show all components on the same sheet. Block diagrams usually show the wiring for only one component and offer a higher-level overview of the main components, whereas schematics show all the circuitry details. Some block diagrams also include a legend showing which connector block the diagram refers to and the connectors on that module; you’ll typically find these in the corner of the block diagram (see Table 7-1).

Table 7-1: Example Connector Legend

The legend should give the connector number, its number pin count, and the color. For instance, the line C1 = 68 WH in Table 7-1 means that the C1 connector has 68 pins and is white. L-GY probably means light gray, and so on. A connector number like C2-55 refers to connector 2, pin 55. The connectors usually have a number on the first and last pin in the row.

Wiring Things Up

Once you have information on the connector’s wiring, it’s time to wire it up. Wire the CAN to the proper ports on the connector, as discussed in “OBD-II Connector Pinout Maps” on page 31. When you provide power—a power supply from an old PC should suffice—and add a CAN sniffer, you should see packets. You can use just a simple OBD-II scan tool that you can pick up at any automotive store. If you have everything wired correctly, the scan tool should be able to identify the vehicle, assuming that your test bench includes the main ECU.

NOTE

Your MIL, or engine light, will most likely be reported as on by the scan tool/ECU.

If you’ve wired everything but you still don’t see packets on your CAN bus, you may be missing termination. To address this problem, start by adding a 120-ohm resistor, as a CAN bus has 120-ohm resistors at each end of the bus. If that doesn’t work, add a second resistor. The maximum missing resistance should be 240 ohms. If the bus still isn’t working, then recheck your wires and try again.

NOTE

A lot of components communicate with the ECU in a simple manner, either via set digital signals or through analog signals. Analog signals are easy to simulate with a potentiometer and you can often tie a 1 kilohm potentiometer to the engine temp and fuel lines to control them.

If you’re ready to take your car hacking research further, consider building a more advanced ECU test bench, like the one shown in Figure 7-4.

This unit combines an ECU with a BCM because it also has the original keys to start the vehicle. Notice that the optional IC has two 1 kilohm potentiometers, or variable resistors, on the lower left side, both of which are tied to the engine temperature and fuel lines. We use these potentiometers to generate sensor signals, as discussed in the following section. This particular test bench also includes a small MCU that allows you to simulate sending crankshaft and camshaft signals to the ECU.

Figure 7-4: More complex test bench

A more complex unit like the one in Figure 7-4 makes it trivial to determine CAN traffic: just load a sniffer, adjust the knob, and watch for the packets to change. If you know which wires you’re targeting and the type of input they take, you can easily fake signals from most components.

Simulating Sensor Signals

As I mentioned, you can use the potentiometers in this setup to simulate various vehicle sensors, including the following:

• Coolant temperature sensor

• Fuel sensor

• Oxygen sensors, which detect post-combustion oxygen in the exhaust

• Throttle position, which is probably already a potentiometer in the actual vehicle

• Pressure sensors

If your goal is to generate more complex or digital signals, use a small microcontroller, such as an Arduino, or a Raspberry Pi.

For our test bench, we also want to control the RPMs and/or speedometer needle. In order to do this, we need a little background on how the ECU measures speed.

Hall Effect Sensors

Hall effect sensors are often used to sense engine speed and crankshaft position (CKP) and to generate digital signals. In Figure 7-5, the Hall effect sensor uses a shutter wheel, or a wheel with gaps in it, to measure the rotation speed. The gallium arsenate crystal changes its conductivity when exposed to a magnetic field. As the shutter wheel spins, the crystal detects the magnet and sends a pulse when not blocked by the wheel. By measuring the frequency of pulses, you can derive the vehicle speed.

Figure 7-5: Shutter wheel diagram for Hall effect sensor

You can also use the camshaft timing sprocket to measure speed. When you look at the camshaft timing sprocket, the magnet is on the side of the wheel (see Figure 7-6).

Figure 7-6: Camshaft timing sprocket

Using a scope on the signal wire shows that the Hall effect sensor produces a square wave. Typically, there are three wires on the camshaft sensor: power, ground, and sensor. Power is usually 12V, but the signal wire typically operates at 5V back to the ECM. Camshaft sensors also come as optical sensors, which work in a similar fashion except an LED is on one side and a photocell is on the other.

You can gauge full rotation timing with a missing tooth called a trigger wheel or with a timing mark. It’s important to know when the camshaft has made a full rotation. An inductive camshaft sensor produces a sine wave and will often have a missing tooth to detect full rotation.

Figure 7-7 shows the camshaft sensor repeating approximately every 2 milliseconds. The jump or a gap you see in the wave at around the 40-millisecond mark occurs when the missing tooth is reached. The location of that gap marks the point at which the camshaft has completed a full rotation. In order to fake these camshaft signals into the ECU test bench, you’d need to write a small sketch for your microcontroller. When writing microcontroller code to mimic these sensors, it’s important to know what type of sensor your vehicle uses so that you’ll know whether to use a digital or analog output when faking the teeth.

Figure 7-7: Camshaft sensor signals under a scope

Now, we’ll build a test bench to simulate vehicle speed. We’ll use this test bench together with the IC shown in Figure 7-4 to pull a vehicle’s VIN via the OBD-II connector. This will give us the exact year, make, model, and engine type of the vehicle. (We looked at how to do this manually in “Unified Diagnostic Services” on page 54.) Table 7-2 shows the results.

Table 7-2: Vehicle Information

Once we know a vehicle’s year of manufacture and engine type, we can fetch the wiring diagram to determine which of the ECU wires control the engine speed (see Figure 7-8). Then, we can send simulated speed data to the ECU in order to measure effects. Using wiring diagrams to simulate real engine behavior can make it easy to identify target signals on the CAN bus.

Figure 7-8: Wiring diagram showing the engine speed pin

The wiring diagram in Figure 7-8 shows how you can trace the wire from the CKP sensor so that connector C2, pin 27 receives the engine speed from the crankshaft sensor. Having identified this pin in the wiring diagram, we locate the corresponding wire on the ECU. We can connect this wire to any digital IO pin on an Arduino. In this example, we’ll use pin 2 and then add a potentiometer to A0 to control the speed of the CKP sensor’s “teeth” going to the ECM. Pin 2 will send output to C2, pin 27.

In order to simulate engine speed sent from the CKP sensor, we code up an Arduino sketch to send high and low pulses with a delay interval mapped to the potentiometer position (see Listing 7-1).

int ENG_SPD_PIN = 2; long interval = 500; long previousMicros = 0; int state = LOW;

// the setup routine runs once when you press reset void setup() { pinMode(ENG_SPD_PIN, OUTPUT); }

// the loop routine repeats forever void loop() { unsigned long currentMicros = micros();

// read the input on analog pin 0 int sensorValue = analogRead(A0); interval = map(sensorValue, 0, 1023, 0, 3000);

if(currentMicros - previousMicros > interval) { previousMicros = currentMicros;

if (state == LOW) state = HIGH; else state = LOW;

if (interval == 0) state = LOW; // turning the pot all the way down turns it "off"

digitalWrite(ENG_SPD_PIN, state); } }

Listing 7-1: Arduino sketch designed to simulate engine speed

Now, we upload this sketch to the Arduino, power up the test bench, and when we turn the knob on the potentiometer, the RPM dial moves on the IC. In Figure 7-9, the second line of the cansniffer traffic shows bytes 2 and 3—0x0B and 0x89—changing as we rotate the potentiometer knob for Arbitration ID 0x110 (the column labeled ID).

Figure 7-9: cansniffer identifying RPMs

NOTE

0x0B and 0x89 don’t directly translate into the RPMs; rather, they’re shorthand. In other words, if you’re going to 1000 RPMs, you won’t see the hex for 1000. When you query an engine for RPMs, the algorithm to convert these two bytes into RPMs is commonly the following:

A is the first byte and B is the second byte. If you apply that algorithm to what’s shown in Figure 7-9 (converted from hex to decimal), you get this:

You can simplify this method to taking 0xB89, which is 2953 in decimal form. When you divide this by 4, you get 738.25 RPMs.

When this screenshot was taken, the needle was idling a bit below the 1 on the RPM gauge, so that’s probably the same algorithm. (Sometimes you’ll find that the values in the true CAN packets don’t always match the algorithms used by off-the-shelf diagnostic tools using the UDS service, but it’s nice when they do.)

To verify that arbitration ID 0x110 with bytes 2 and 3 controls the RPM, we’ll send our own custom packet. By flooding the bus with a loop that sends the following, we’ll peg the needle at max RPMs.

$ cansend slcan0 110#00ffff3500380000

While this method works and, once connected, takes only a few seconds to identify the CAN packet responsible for RPMs, there are still some visible issues. Every so often a CAN signal shows up that resets the values to 00 00 and stops the speedometer from moving. So while the ECM is fairly certain the crankshaft is spinning, it’s detecting a problem and attempting to reset.

You can use the ISO-TP tools discussed in Chapter 3 to pull data. In two different terminals, we can check whether there was a diagnostic code. (You can also use a scan tool.)

In one terminal, enter the following:

$ isotpsniffer -s 7df -d 7e8 slcan0

And in another terminal, send this command:

$ echo "03" | isotpsend -s 7DF -d 7E8 slcan0

You should see this output in the first terminal:

slcan0 7DF [1] 03 - '.' slcan0 7E8 [6] 43 02 00 68 C1 07 - 'C..h..'

Looks like we have a DTC set. Querying PID 0x03 returned a 4-byte DTC (0x0068C107). The first two bytes make up the standard DTC (0x00 0x68). This converts to P0068, which the Chilton manual refers to as “throttle body airflow performance.” A quick Google search will let you know that this is just a generic error code that results from a discrepancy between what the PCM thinks is going on and what data it’s getting from the intake manifold. If we wanted to spoof that data as well, we’d need to spoof three additional sensors: the MAF sensor, the throttle position, and the manifold air pressure (MAP). Fixing these may not actually fix our problem, though. The PCM may continue to think the vehicle is running smoothly, but unless you really care about fudging all the data, you may be able to find other ways to trick the signals you want out of the PCM without having to be immune to triggering DTC faults.

If you don’t want to use an Arduino to send signals, you can also buy a signal generator. A professional one will cost at least $150, but you can also get one from SparkFun for around $50 (http://www.sparkfun.com/products/11394/). Another great alternative is the JimStim for Megasquirt. This can be purchased as a kit or fully assembled for $90 from DIYAutoTune (http://www.diyautotune.com/catalog/jimstim-15-megasquirt-stimulator-wheel-simulator-assembled-p-178.html).

In this chapter you learned how to build an ECU test bench as an affordable solution to safe vehicle security testing. We went over where you can get parts for building a test bench and how to read wiring diagrams so you know how to hook those parts up. You also learned how to build a more advanced test bench that can simulate engine signals, in order to trick components into thinking the vehicle is present.

Building a test bench can be a time-consuming process during your initial research, but it will pay off in the end. Not only is it safer to do your testing on a test bench, but these units are also great for training and can be transported to where you need them.

The ECU is a common target of reverse engineering, sometimes referred to as chip tuning. As mentioned in Chapter 7, the most popular ECU hack is modifying the fuel map to alter the balance of fuel efficiency and performance in order to give you a higher-performance vehicle. There’s a large community involved with these types of modifications, and we’ll go into more detail on firmware modifications like this in Chapter 13.

This chapter will focus on generic embedded-system methods of attack as well as side-channel attacks. These methodologies can be applied to any embedded system, not just to the ECU, and they may even be used to modify a vehicle with the help of aftermarket tools. Here, we’ll focus on debugging interfaces for hardware as well as performing side-channel analysis attacks and glitching attacks.

NOTE

To get the most out of this chapter, you should have a good understanding of basic electronics, but I’ve done my best to explain things within reason.

The first step in attacking the ECU or any embedded system in a vehicle is to analyze the target circuit board. I touched upon circuit board analysis in Chapter 7, but in this chapter, I’ll go into more detail about how electronics and chips work. I’ll introduce you to techniques that can be applied to any embedded system in the vehicle.

Identifying Model Numbers

When reversing a circuit board, first look at the model numbers of the microcontroller chips on the board. These model numbers can help you track down valuable information that can be key to your analysis. Most of the chips you’ll find on vehicle circuit boards are generic—companies rarely make custom ones—so an Internet search of a chip’s model number can provide you with the complete data sheet for that chip.

As mentioned in Chapter 7, you’ll sometimes run into custom ASIC processors with custom opcodes, especially in older systems, which will be harder to reprogram. When you encounter older chips like these, remove them from the board and plug them in to an EPROM programmer in order to read their firmware. You should be able to reprogram modern systems directly via debugging software, like JTAG.

Once you locate a data sheet, try to identify the microcontrollers and memory locations on each chip to determine how things are wired together and where to find diagnostic pins—a potential way in.

Dissecting and Identifying a Chip

If you can’t find a model number, sometimes all you’ll have to go on is the chip’s logo (after a while, you’ll find that you start to recognize chip logos) and a few of its product codes. The logo shown in Figure 8-1 is for STMicroelectronics. At the top of the chip is the model number—in this case, STM32F407—which may be hard to read because it’s engraved. Often, a light-up magnifier or a cheap USB microscope can prove very handy in reading these markings. Go to http://www.st.com/ to find the data sheet for the STM32F series chips, specifically the 407 variety. Much like VIN numbers, model numbers are often broken down into sections representing model number and different variations. There’s no standard for how to break down these numbers, however, and every manufacturer will represent their data differently.

Figure 8-1: STM32 chipset identification

Below the chip’s model number is the code—in this case, VGT6—which tells you the specific features, such as USB support, available on the chip. If you look up the model number in conjunction with the ST code, you’ll learn that the STM32F407Vx series is an ARM Cortext M4 chip with support for Ethernet, USB, two CANs, and LIN as well as JTAG and Serial Wire Debug.

To determine the function of the various pins, scan the data sheet to find the package pinout diagrams, and look for the package that matches yours for pin count. For example, as you can see in Figure 8-1, each side of the chip has 25 pins for a total of 100, which matches the LQFP100 pinout in the data sheet shown in Figure 8-2.

Each chip will usually have a dot or dimple at pin 1 (see Figure 8-1), and once you identify pin 1, you can follow the pinout to determine each pin’s function. Sometimes you’ll find two dimples, but one should be slightly more pronounced.

Sometimes pin 1 on a chip is indicated by a cut-off corner. If you find nothing on a chip that allows you to identify pin 1, look for things you can identify. For example, if another chip on the board is a common CAN transceiver, you could use a multitool to trace the lines to figure out which pins it connects to. You could then reference the data sheet to see which side of the chip contains these CAN pins. To do this, put your multimeter in continuity mode. Once in continuity mode, it will beep if you touch both pins to the same trace, indicating that they’re connected. Once you’re able to identify just one pin, you can use that information together with the pinout to deduce the pin layout.

Figure 8-2: STM32F4 data sheet pinout

You can use a variety of debugging protocols to debug chips just as you do software. To determine which protocol your target chip supports, you’ll need to use the chip’s data sheet. You should be able to use a chip’s debugging port to intercept its processing and download and upload modifications to the chip’s firmware.

JTAG

JTAG is a protocol that allows for chip-level debugging and downloading and uploading firmware to a chip. You can locate the JTAG connections on a chip using its data sheet.

JTAGulator

You’ll often find pads on a chip’s circuit board that are broken out from the chip itself and that may give you access to the JTAG pins. To test the exposed pads for JTAG connections, use a tool like JTAGulator, shown in Figure 8-3. Plug all of the chip’s exposed pins in to the JTAGulator, and set the voltage to match the chip. JTAGulator should then find any JTAG pins and even walk the JTAG chain—a method of linking chips over JTAG—to see whether any other chips are attached.

Figure 8-3: JTAGulator with a Bus Pirate cable

JTAGulator supports either screw terminals or the use of a Bus Pirate cable (as in Figure 8-3) for probing. Both the JTAGulator and the Bus Pirate cable use a serial interface to configure and interact with a chip.

Debugging with JTAG

You can debug a chip with JTAG using just two wires, but it’s more common to use four or five pin connections. Of course, finding the JTAG connection is only the first step; usually, you’ll need to overcome additional protections that prevent you from just downloading the chip’s firmware in order to do anything interesting.

Developers will disable JTAG firmware via either software or hardware. When disabling JTAG in software, the programmer sets the JTD bit, which is usually enabled twice via software during runtime. If the bit it isn’t called twice within a short time, it’s not set. It’s possible to defeat a software protection like this by using a clock or power-glitching attack to skip at least one of these instructions. (We’ll discuss glitching attacks later in “Fault Injection” on page 148.)

The other way to disable JTAG on a chip is to attempt to permanently disable programming by setting the JTAG fuse—OCDEN and JTAGEN—and thereby disabling both registers. This is harder to bypass with glitch attacks, though voltage glitching or the more invasive optical glitches may succeed. (Optical glitches entail decapping the chip and using a microscope and a laser, so they’re very costly. We won’t be covering them in this book.)

Serial Wire Debug

Although JTAG is the most commonly used hardware debugging protocol, some microcontrollers—such as the STM32F4 series, which is commonly used in automotive applications because it has onboard CAN support—primarily use Serial Wire Debug (SWD). While the ST32F4 series of ICs can support JTAG, they’re often wired to support only SWD because SWD requires only two pins instead of the five used for JTAG. SWD also allows overlapping of the JTAG pins, so these chips may support both JTAG and SWD by using the pins labeled TCK and TMS. (These pins are labeled SWCLK and SWIO in the data sheet.) When debugging ST chips, you can use a tool like ST-Link to connect, debug, and reflash the processor. ST-Link is cheap (about $20) compared to some of its JTAG counterparts. You can also use a STM32 Discovery board.

The STM32F4DISCOVERY Kit

The STM32F4DISCOVERY kit (sold by STM) is another tool you can use to debug and program these chips. These are actually developer boards with their own programmer. They cost about $15 and should be in your car hacking tool set. The benefit of using the Discovery kit is that it’s both a cheap programmer and a development board that you can use to to test modifications to the chip’s firmware.

In order to use the Discovery kit as a generic programmer, remove the jumpers from the pins labeled ST-Link, and then connect the six pins on the opposite side labeled SWD (see Figure 8-4). Pin 1 starts next to the white dot on the SWD connector.

Table 8-1 shows the pinout.

Table 8-1: Pinout for the STM32F4DISCOVERY kit

Figure 8-4: Programming a STM32 chip via the STM32F4DISCOVERY kit

You’ll most likely need to provide power to the target device, but instead of using pin 1 on the SWD connector, use the 3V pin from the Discovery portion of the board, as shown in Figure 8-4. (Notice in the pinout that the Discovery kit doesn’t use all six pins for SWD; pins nRESET and SWO are optional.)

Once you’re connected, you’ll most likely want to read and write to the firmware. If you’re running Linux, you can get the ST-Link from GitHub at https://github.com/texane/stlink/. Once you have those utilities installed, you’ll not only be able to read and write to the chip’s flash memory, but you can also start a gdbserver to work as a real-time debugger.

The Advanced User Debugger

Renesas is a popular automotive chipset used in ECUs (see Figure 8-5). It has its own implementation over JTAG called the Advanced User Debugger (AUD). AUD provides the same functionality as JTAG but with its own proprietary interface. As with SWD, AUD requires an interface specific to it in order to communicate with Renesas chipsets.

Figure 8-5: 2005 Acura TL ECU with Renesas SH MCU and AUD port

Nexus

Nexus from Freescale/Power Architecture (now NXP) is another proprietary JTAG interface. Like AUD and SWD, this in-circuit debugger requires its own device in order to interface with it. When dealing with Freescale chips, such as the MCP5xxx series, keep in mind that the debugger may be Nexus.

The Nexus interface uses a dedicated set of pins that should be defined in the chipset’s data sheet. Look for the EVTI/O pins in the auxiliary port section of the data sheet.

Side-channel analysis is another hardware attack used to bypass ECU and other microcontroller protections and to crack built-in cryptography. This type of attack takes advantage of various characteristics of embedded electronic systems instead of directly targeting specific hardware or software. Side-channel attacks take many forms, and some can cost anywhere from $30,000 to $100,000 to perform because they require specialized equipment like electron microscopes. Expensive side-channel attacks like these are often invasive, meaning they’ll permanently alter the target.

We’ll focus on simpler and cheaper side-channel attacks with the help of the ChipWhisperer, a noninvasive tool from NewAE Technologies (http://newae.com/chipwhisperer/). The ChipWhisperer is an open source side-channel analysis tool and framework that costs just over $1,000—considerably less than its non–open source counterparts, which typically start around $30,000.

NOTE

It’s possible to accomplish the attacks I’ll discuss at less of a cost by building a specialized device, but the ChipWhisperer is the cheapest tool that covers all the main bases. Also, ChipWhisperer tutorials target open source designs, which makes them ideal for this book, since we can’t use examples from specific manufacturers due to copyright. I’ll integrate the NewAE tutorials throughout this chapter when demonstrating each attack.

The ChipWhisperer has an optional package that includes a target development board called the MultiTarget Victim Board (see Figure 8-6). This board is mainly used for demonstration and training, and we’ll use it as the target of our demos as well.

Figure 8-6: MultiTarget Victim Board

The MultiTarget Victim Board is basically three separate systems: an ATmega328, a XMEGA, and a smart card reader. (The ChipWhisperer can perform man-in-the-middle attacks on smart cards, but because cars don’t really use smart cards, we won’t cover that feature here.)

By changing jumpers on the board, you can pass power to enable or disable different systems, but be careful to enable only one section at a time, or you may short the board. Pay attention to the jumper settings before testing.

Installing the Software

First install the ChipWhisperer software. The following instructions are for Linux, but you can find detailed setup instructions for Windows at http://www.newae.com/sidechannel/cwdocs/.

The ChipWhisperer software requires Python 2.7 and some additional Python libraries to run. First, enter the following code:

$ sudo apt-get install python2.7 python2.7-dev python2.7-libs python-numpy python-scipy python-pyside python-configobj python-setuptools python-pip git $ sudo pip install pyusb-1.0.0b1

To get the ChipWhisperer software, you can either download a stable version as a ZIP file from the NewAE site or grab a copy from the GitHub repository, as shown here:

$ git clone git://git.assembla.com/chipwhisperer.git $ cd chipwhisperer $ git clone git://git.assembla.com/openadc.git

The second git command downloads OpenADC. The OpenADC board of the ChipWhisperer is the oscilloscope part, which measures voltage signals and is basically the heart of the ChipWhisperer system. Use the following commands to set up the software (you should be root in the ChipWhisperer directory):

$ cd openadc/controlsw/python $ sudo python setup.py develop $ cd software $ sudo python setup.py develop

The hardware is already natively supported by Linux, but you should add a group for the normal user that you’ll test so that the user can have access to the device without needing root privileges. To allow non-root users to use the equipment, create a udev file, such as /etc/udev/rules.d/99 -ztex.rules, and add the following to that file:

SUBSYSTEM=="usb", ATTRS{idVendor}=="04b4", ATTRS{idProduct}=="8613", MODE="0664", GROUP="plugdev" SUBSYSTEM=="usb", ATTRS{idVendor}=="221a", ATTRS{idProduct}=="0100", MODE="0664", GROUP="plugdev"

Also, create a file for the AVR programmer called /etc/udev/rules.d/ 99-avrisp.rules:

SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2104", MODE="0664", GROUP="plugdev"

Now add yourself (you’ll need to log out and back in for these new permissions to take effect):

$ sudo usermod -a -G plugdev <YourUsername> $ sudo udevadm control –reload-rules

Connect the ChipWhisperer to your machine by plugging a mini-USB cable in to the side of the ChipWhisperer box. The green System Status light on the top should light up, and your ChipWhisperer should now be set up or at least in its unconfigured core.

Prepping the Victim Board

To prep the Victim Board—or device under test (DUT), as it’s referred to in the ChipWhisperer documentation—download the AVR Crypto library (the library isn’t included with the ChipWhisperer framework by default due to export laws) by entering the following:

$ cd hardware/victims/firmware $ sh get_crypto.sh

We’ll use the AVRDUDESS GUI to program our Victim Board. You can get AVRDUDESS from its GitHub repository at https://github.com/zkemble/avrdudess/ or grab binaries from sites such as http://blog.zakkemble.co.uk/avrdudess-a-gui-for-avrdude/. You’ll need to install mono for this to work:

$ sudo apt-get install libmono-winforms2.0-cil

Next, make sure the Victim Board is set up to use the ATmega328 portion by changing the jumper settings to match the layout in Figure 8-7.

Figure 8-7: Jumper settings for the MultiTarget Victim Board

Your ChipWhisperer should have come with a 20-pin ribbon cable. Plug this cable in to the back of the ChipWhisperer and the USB A/B cable in to the side, as shown in Figure 8-8. Dmesg should report seeing an AVRISP mkII plugged in, which is the programmer that we’ll use to program the target board. This will allow us to perform testing without disconnecting the device.

Figure 8-8: Wiring up the MultiTarget Victim Board

Finally, attach the SMA cable from the VOUT on the target board to the LNA connector in CH-A on the front of the ChipWhisperer. Table 8-2 shows the pinout. We’ll use this setup for our demos unless otherwise specified.

Table 8-2: Pinout for the MultiTarget Victim Board

Now you have your Victim Board set up, we’ll look at using a power-analysis attack to brute-force a password. Power-analysis attacks involve looking at the power consumption of different chipsets to identify unique power signatures. By monitoring the power consumption for each instruction, it’s possible to determine the type of instruction being executed. For instance, a no-operation (NOP) instruction will use less power than a multiply (MUL) instruction. These differences can reveal how a system is configured or even whether a password is correct because a correct password character may use more power than an incorrect one.

In the following example, we’ll explore TinySafeBoot (http://jtxp.org/tech/tinysafeboot_en.htm), a small, open source bootloader designed for AVR systems. The bootloader requires a password in order to make modifications. We’ll use the ChipWhisperer to exploit a vulnerability in its password-checking method and derive the password from the chip. This vulnerability has been fixed in newer versions of TinySafeBoot, but for practice, the old version is included in the victims folder of the ChipWhisperer framework. This tutorial is based on NewAE’s “Timing Analysis with Power for Attacking TSB” (http://www.newae.com/sidechannel/cwdocs/tutorialtimingpasswd.html).

Prepping Your Test with AVRDUDESS

To begin, open AVRDUDESS and select AVR ISP mkII from the Programmer drop-down menu. Make sure you have ATmega328P selected in the MCU field, and then click Detect to verify that you’re connected to the ATmega328p (see Figure 8-9). Select the flash file hardware/victims/firmware/ tinysafeboot-20140331 in the Flash field.

Figure 8-9: Programming TinySafeBoot in AVRDUDESS

Click Program! and AVRDUDESS should write the TinySafeBoot program to the ATmega.

Setting Up the ChipWhisperer for Serial Communications

Now we’re ready for testing! We’ll use the ChipWhisperer to set and monitor the power usage when the bootloader checks for the password. Then, we’ll use this information to build a tool to crack the password much faster than a traditional brute-force method would. To begin, set up the ChipWhisperer to communicate with the bootloader over the bootloader’s serial interface, like this:

$ cd software/chipwhisperer/capture $ python ChipWhispererCapture.py

The ChipWhisperer has lots of options, so we’ll go step by step through each setting you’ll need to change.

  1. In ChipWhispererCapture, go to the General Settings tab and set the Scope Module to ChipWhisperer/OpenADC and the Target Module to Simple Serial, as shown in Figure 8-10.

    Figure 8-10: Setting the Scope and Target types

    Figure 8-11: Setting Connection and Baud

  2. Switch to the Target Settings tab (at the bottom of the window), and change the Connection setting to ChipWhisperer. Then under Serial Port Settings, set both TX Baud and RX Baud to 9600, as shown in Figure 8-11.

  3. At the top of the screen, click the red circle next to Scope with DIS in it. The circle should become green and display CON.

  4. The ChipWhisperer comes with a simple serial terminal interface. Choose Tools ▸ Open Terminal to open it. You should see a terminal like the one shown in Figure 8-12.

    Figure 8-12: ChipWhisperer serial terminal

  5. Set TX on Enter at the bottom of the terminal to None, and check the box that says RX: Show non-ASCII as hex (see Figure 8-12). Now click Connect to enable your text areas.

  6. Enter @@@ (TinySafeBoot’s start-up password) in the text field to the left of the Send button, and click Send. The bootloader should start with TSB and mainly contain information about the firmware version and AVR settings. TSB is just an identifier used by TinySafeBoot, most likely its initials. The output should match that in Figure 8-12.

Setting a Custom Password

Now we need to set a custom password so that we can monitor the power levels when a password is entered.

First, close the serial terminal. Then enter the following lines in the Python console window, which is at the bottom center of the ChipWhisperer main window.

>>> self.target.driver.ser.write("@@@") >>> self.target.driver.ser.read(255)

We use the serial command self.target.driver.ser.write("@@@") to send the current password for the bootloader. Next, we enter the serial command self.target.driver.ser.read(255) to read up to the next 255 bytes from the bootloader to see its response to our sending the password (see Figure 8-13).

Figure 8-13: Sending @@@ via ChipWhisperer’s Python console

For convenience, first assign the read and write commands to their own variables so you don’t have to enter such a long command (the following examples assume you’ve completed this step):

>>> read = self.target.driver.ser.read >>> write = self.target.driver.ser.write

The password is stored in the last page of the device’s flash memory. We’ll grab that page, remove the confirmation ! character from the response, and write a new password—og—to the firmware.

Return to the Python console, and enter Listing 8-1.

>>> write('c') >>> lastpage = read(255) >>> lastpage = lastpage[:-1] >>> lastpage = bytearray(lastpage, 'latin-1') >>> lastpage[3] = ord('o') >>> lastpage[4] = ord('g') >>> lastpage[5] = 255 >>> write('C') >>> write('!') >>> write(lastpage.decode('latin-1'))

Listing 8-1: Modifying the last page of memory to set the password to og

If the login times out, resend @@@ like so:

>>> write("@@@")

Once you’ve written the new characters to memory, verify that og is the new password with write("og"), followed by a read(255) in the Python console. Notice in Figure 8-14 that we first try sending @@@ but that we don’t get a TinySafeBoot response until we send the og password.

Figure 8-14: Setting the password to og

Resetting the AVR

Having changed the password, we can start reading power signals. First, we need to be able to get out of the infinite loop that the system goes into when we enter an incorrect password. Write a small script to reset the AVR when this happens. While still in the Python console, enter the following commands to create a resetAVR helper function:

>>> from subprocess import call >>> def resetAVR: call(["/usr/bin/avrdude", "-c", "avrispmkII", "-p", "m328p"])

Setting Up the ChipWhisperer ADC

Now, set up the ChipWhisperer ADC so that it knows how to record the power trace. Return to the ChipWhisperer main window, click the Scope tab, and set the values as shown in Table 8-3 and Figure 8-15.

Table 8-3: Scope Tab Settings to Set Up the OpenADC for the Victim Board

Figure 8-15: ADC values to trigger on Serial TX

Monitoring Power Usage on Password Entry

Now we’ll monitor the power usage when entering a password to see whether we can spot a difference in power between a valid and an invalid password. We’ll look at what happens when we enter the now invalid password of @@@. Recall from earlier that when the bootloader detects that you’ve entered a wrong password, it’ll go into an infinite loop, so we can monitor what the power usage looks like at that point. Of course, you’ll need to exit that infinite loop, so once you’ve tried the incorrect password and are sent into a loop, reset the device and try to enter another password. To do this, navigate to the password prompt in the Python console as follows:

>>> resetAVR() >>> write("@@@")

Now, issue the next command with the correct password, but do not click Enter yet:

>>> write("og")

Click 1 in the green play icon in the toolbar to record one power trace. Immediately after you do so, click Enter in the Python console. A Capture Waveform window should open and show you the power trace recording of the valid password (see Figure 8-16).

Figure 8-16: Power trace of a valid password

The details of Figure 8-16 aren’t that important; the point is to give you a feel for what a “good” signal looks like. The thick lines you see are normal processing, and there’s a dip around the 8,000 sample range when the processing instructions changed. (This could be something in the password check, but let’s not get hung up on details at this stage.)

Now, enter an invalid password—ff:

>>> resetAVR() >>> write("@@@") >>> write("ff")

Figure 8-17 shows the power trace for this password.

Figure 8-17: Power trace for a password with no valid characters

You can see that the program hangs in its infinite loop when the power reading shifts from normal to a near consistent 0 power usage.

Now, let’s try a password with a valid first character to see whether we notice a difference:

>>> resetAVR() >>> write("@@@") >>> write("of")

In Figure 8-18, one additional chunk is active before the device enters the infinite loop. We see normal power usage, followed by the dip at 8,000 that we saw in the first valid reading, and then some more normal usage before the device enters the infinite loop of 0 usage.

Figure 8-18: Power trace of a password with a valid first character

NOTE

You can determine the size of samples used for one valid character by measuring the length between the dip at 8,000 and the infinite loop that starts around 16,000. In this case, we can roughly approximate that the sample size to check one character is about 8,000 traces (16,000 – 8,000).

Scripting the ChipWhisperer with Python

Because the ChipWhisperer is written in Python, it’s highly scriptable, so you can script these power traces to create a brute-forcer that can get the password for the bootloader very quickly. By setting a script to check whether the data points of the power trace exceed a set threshold, your brute-forcer can immediately tell whether the target character is correct. By looking at the data values on the y-axis in Figure 8-18, we can see that when we have activity, data reaches 0.1, but when we’re in the infinite loop, it hovers around the 0 mark. If the target character is correct, the threshold for our script can be set to 0.1, and if no data in the sample range of a byte reaches 0.1, then we can conclude that we’re in the infinite loop and the password character was incorrect.

For example, if the password is made up of 255 different characters with a maximum length of 3, the password will be one of 2553, or 16,581,375, possibilities. However, because we can instantly detect when we have a correct character, in a worst-case scenario, the brute-forcer will have to try only 255 × 3, or 765, possibilities. If the character doesn’t match the set password, the bootloader jumps into the infinite loop. On the other hand, if the password check routine waited until the entire password was checked regardless of its correctness, this type of timing analysis couldn’t be done. The fact that the small code on embedded systems is often designed to be as efficient as possible can open it up to devastating timing attacks.

NOTE

For details on how to write your own brute-forcer for the ChipWhisperer, see the NewAE tutorials. A sample brute-forcer is included at http://www.nostarch.com/carhacking/.

Secure bootloaders and any embedded system that checks for a valid code can be susceptible to this type of attack. Some automotive systems require a challenge response or a valid access code to access lower-level functions. Guessing or brute-forcing these passwords can be very time consuming and would make traditional brute-forcing methods unrealistic. By using power analysis to monitor how these passwords or codes are being checked, you can derive the password, making something that would’ve been too time consuming to crack completely doable.

Fault injection, also known as glitching, involves attacking a chip by disrupting its normal operations and potentially causing it to skip running certain instructions, such as ones used to enable security. When reading a chip’s data sheet, you’ll see that attached to the range for clock speeds and power levels is a warning that failing to stick to these ranges will have unpredictable results—and that’s exactly what you’ll take advantage of when glitching. In this section, you’ll learn how to introduce faults by injecting faults into clock speeds and power levels.

Clock Glitching

Any ECU or chip will rely on an internal clock to time its instructions. Each time the microcontroller receives a pulse from the clock, it loads an instruction, and while that instruction is being decoded and executed, the next instruction is being loaded. This means that a steady rhythm of pulses is needed for the instructions to have time to load and execute correctly. But what happens if there’s a hiccup during one of these clock pulses? Consider the clock glitch in Figure 8-19.

Figure 8-19: Normal clock cycle (top) and glitched clock cycle (bottom)

Because the Program Counter has time to increment but not enough time to decode and execute the instruction before the next instruction is loaded, the microcontroller will usually skip that instruction. In the bottom cycle of Figure 8-19, instruction 3 is skipped because it does not have enough time to execute before another instruction is issued. This can be useful for bypassing security methods, breaking out of loops, or re-enabling JTAG.

To perform a clock glitch, you need to use a system faster than your target’s system. A field-programmable gate array (FPGA) board is ideal, but you can accomplish this trick with other microcontrollers, too. To perform the glitch, you need to sync with the target’s clock, and when the instruction you want to skip is issued, drive the clock to ground for a partial cycle.

We’ll demonstrate a clock-glitching attack using the ChipWhisperer and some demo software made for this kind of attack. The Victim Board setup is almost the same as for the power attack, except that you’ll need to change the jumpers for the Clock pin (in the middle of the board), which should be set only for FPGAOUT by jumping the pins (see Figure 8-20).

Figure 8-20: MultiTarget Victim Board set for glitching

We’ll set up the ChipWhisperer to control the clock of the ATmega328. Both the general settings and the target settings are the same as in the power attack discussed in “Setting Up the ChipWhisperer for Serial Communications” on page 140; the only exception is that we’ll set the baud rate to 38400 for both TX and RX. Enable both the Scope and Target by switching from DIS to CON in the toolbar, as discussed earlier. Figure 8-21 and Table 8-4 show the complete settings.

Figure 8-21: Scope settings for glitching

Table 8-4: ChipWhisperer Main Window Settings for a Clock-Glitch Attack

These settings give the ChipWhisperer full control of the target board’s clock and allow you to upload the glitch demo firmware. You’ll find the firmware for the target in the ChipWhisperer framework in this directory: hardware/victims/firmware/avr-glitch-examples. Open glitchexample.c in your favorite editor and then go to the main() method at the bottom of the code. Change glitch1() to glitch3() in order to follow along with this demo, and then recompile the glitchexample firmware for the ATmega328p:

$ make MCU=atmega328p

Now, upload the glitchexample.hex file via AVRDUDESS, as we did in “Prepping Your Test with AVRDUDESS” on page 139. Once the firmware is loaded, switch to the main ChipWhisperer window and open a serial terminal. Click Connect, and then switch to AVRDUDESS and click Detect. This should reset the chip so that you see hello appear in the capture terminal. Enter a password, and click Send. Assuming you enter the wrong password, the capture terminal should display FOff and hang, as shown in Figure 8-22.

Figure 8-22: A bad password example

Now return to your editor and look at the glitchexample source code. As shown in Listing 8-2, this is a simple password check.

for(cnt = 0; cnt < 5; cnt++){ if (inp[cnt] != passwd[cnt]){ passok = 0; } }

if (!passok){ output_ch_0('F'); output_ch_0('O'); output_ch_0('f'); output_ch_0('f'); output_ch_0('\n'); } else { output_ch_0('W'); output_ch_0('e'); output_ch_0('l'); output_ch_0('c'); output_ch_0('o'); output_ch_0('m'); output_ch_0('e'); output_ch_0('\n'); }

Listing 8-2: Password check method for glitch3()

If an invalid password is entered, passok is set to 0, and the message Foff is printed to the screen; otherwise, Welcome is printed to the screen. Our goal is to introduce a clock glitch that bypasses the password verification either by skipping over the instruction that sets passok to 0 (so that it’s never set to 0) or by jumping straight to the welcome message. We’ll do the latter by manipulating the width and offset percentages in the glitch settings.

Figure 8-23 shows some possible places to locate the glitch. Different chips and different instructions react differently depending on where your glitch is placed, so experiment to determine which location works best for your situation. Figure 8-23 also shows what a normal clock cycle looks like under a scope. If we use a positive offset in the ChipWhisperer settings, it’ll cause a brief drop in the middle of the clock cycle. If we use a negative offset, it’ll cause a brief spike before the clock cycle.

We’ll set the following glitch options in the ChipWhisperer to cause a brief spike before the clock cycle by using a –10 percent offset:

Glitch width %: 7 Glitch Offset %: -10 Glitch Trigger: Ext Trigger: Continuous Repeat: 1

Figure 8-23: Example glitch placements

Now return to the ChipWhisperer main window to set up the CW Extras, as shown in Figure 8-24. This will configure the ChipWhisperer to cause the clock glitch only when it gets a signal from the trigger line.

Figure 8-24: Glitch setup in the CW Extra Settings

NOTE

Glitching is an inexact science. Different chips will respond to settings differently, and you’ll need to play around with settings a lot to get the timing right. Even if you fail to exploit the clock glitch consistently, often you’ll need to get it right only once to exploit a device.

Setting a Trigger Line

Now that we have the ChipWhisperer set up to listen for a signal on the trigger line, we need to modify the code to use the trigger line. The trigger line is pin 16 on the ChipWhisperer connector. When the trigger line receives a signal (voltage peaks), it triggers the ChipWhisperer software to spring into action.

The trigger line is a generic input method used by ChipWhisperer. The goal is to get the trigger line to receive a signal just before the point we want to attack. If we were looking at a piece of hardware and noticed a light come on just before the area we wanted to attack, we could solder the LED to the trigger line in order to make the ChipWhisperer wait until just the right moment.

For this demo, we’ll modify the firmware to make the trigger line go off in the area we want to glitch. First we’ll add some code to the default glitch 3 example shown in Listing 8-2. Use your favorite editor to add the defines in Listing 8-3, toward the top of the glitchexample.c.

#define trigger_setup() DDRC |= 0x01 #define trigger_high() PORTC |= 0x01 #define trigger_low() PORTC &= ~(0x01)

Listing 8-3: Setting up trigger defines in glitchexample.c

Place a trigger_setup() inside the main() method just before it prints hello, and then wrap your target with the trigger, as shown in Listing 8-4.

for(cnt = 0; cnt < 5; cnt++){ if (inp[cnt] != passwd[cnt]){ trigger_high(); passok = 0; trigger_low(); } }

Listing 8-4: Adding trigger_high and trigger_low around passok to trigger a glitch

Now, recompile make MCU=atmega328p, and reupload the firmware to the Victim Board. (Make sure to set the Glitch Trigger option to Manual in the ChipWhisperer settings before you upload the firmware or you may accidentally glitch the firmware upload.) Once the firmware is uploaded, switch the Glitch Trigger option back to Ext Trigger:Continous. Now, enter any password. If you get a Welcome message, you’ve successfully glitched the device, as shown in Figure 8-25.

Figure 8-25: Successfully glitching password check

Unfortunately, in the real world, you probably won’t be able to use a trigger line in the same way because you won’t have access to the target source or a trigger event won’t be close enough to where you want to glitch. In such cases, you’ll need to play with other settings and the Ext trigger offset. Open the Glitch Monitor under Tools to experiment with different settings.

Power Glitching

Power glitching is triggered like clock glitching: you feed the target board the proper power at a steady rate, and when you want to trigger unexpected results at particular instructions, you either drop or raise the voltage to interrupt that instruction. Dropping the voltage is often safer than raising it, so try that first. Each microcontroller reacts differently to power glitching, so play around at different points and power levels to build a glitch profile and see what types of behavior can be controlled. (When instructions are skipped via power glitching, it’s often because the opcode instruction has become corrupted and done something other than the intended instruction or because one of the registers has become corrupted.)

NOTE

Some microcontrollers aren’t vulnerable at all to power glitching, so test with your target chipset before trying it on a vehicle.

Power glitching can also affect memory reads and writes. Depending on which instruction is running during the power fault, you can cause the controller to read the wrong data or forget to write a value.

Invasive Fault Injection

Because invasive fault injection attacks are more time-consuming and expensive than glitch attacks, we’ll examine them only briefly here. However, if you need to do the job and you have the resources, invasive fault injection is often the best way. The catch is that it doesn’t preserve the target and can even destroy it.

Invasive fault injection involves physically unpacking the chip, typically with acid (nitric acid and acetone) and using an electron microscope to image the chip. You can work on just the top or bottom layer of the chip or map out each layer and decipher the logic gates and internals. You can also use microprobes and a microprobe station to inject the exact signal you want into your target. By the same token, you could use targeted lasers or even directed heat to cause optical faults to slow down processes in that region. For instance, if a move instruction is supposed to take two clock cycles, you can slow the registry retrieval to make it late for the next instruction.

In this chapter, you’ve learned several advanced techniques for attacking embedded systems; these techniques will become only more valuable as automotive security improves. You learned how to identify chips and monitor power usage to create a profile of good operations. We tested whether password checks could be attacked by monitoring the power output of bad characters in passwords, ultimately to create a brute-forcing application using power analysis to cut the password brute-force time down to seconds. We also saw how clock and power glitching can make instructions skip at key points in the firmware’s execution, such as during validation security checks or when setting JTAG security.

In-vehicle infotainment (IVI) system is the name often given to the touchscreen interface in a car’s center console. These consoles often run an operating system such as Windows CE, Linux, QNX, or Green Hills and may even run Android in a VM as well. They can support numerous features with varying levels of integration with the vehicle.

The IVI system offers more remote attack surfaces than any other vehicle component. In this chapter, you’ll learn how to analyze and identify an IVI unit, how to determine how it works, and how to overcome potential hurdles. Once you understand your IVI system, you’ll have gained a great deal of insight into how your target vehicle works. Gaining access to the IVI system will not only allow you to modify the IVI itself but also will open a door to additional information about how your vehicle works, such as how it routes CAN bus packets and updates the ECU. Understanding the IVI system can also provide insight into whether the system phones home to the manufacturer; if it does, you can use access to the IVI to see what data is being collected and potentially transmitted back to the manufacturer.

IVI systems typically have one or more of these physical inputs that you can use to communicate with a vehicle:

Auxiliary jack

• CD-ROM

• DVD

• Touchscreen, knobs or buttons, and other physical input methods

• USB ports

One or more wireless inputs

• Bluetooth

• Cellular connection

• Digital radio (such as Digital Audio Broadcasting)

• GPS

• Wi-Fi

• XM Radio

Internal network controls

• Bus networks (CAN, LIN, KWP, K-Line, and so on)

• Ethernet

• High-speed media bus

Vehicles often use CAN to communicate with their components, such as modules, ECUs, IVI systems, and telematic units. Some IVI systems use Ethernet to communicate between high-speed devices, whether to send normal IP traffic or CAN packets using Electronic System Design’s NTCAN or the Ethernet low-level socket interface (ELLSI). (For more on vehicle protocols, see Chapter 2.)

One way to attack the IVI system is to go after its software. If your skill set primarily lies in the realm of software-related services, you may feel most comfortable with this method, and if you’ve ever researched embedded devices, such as home Wi-Fi routers, some of the methods discussed in the following should look familiar to you.

We’ll focus on using system updates to gain access to the system. It may be possible to access the system through other software means, such as a debug screen, an undocumented backdoor, or a published vulnerability, but we’ll focus on gaining access through software updates because that method is the most generic across IVI systems and is the primary one used to identify and access a target system via software.

Identifying Your System

In order to fully understand your target IVI system, you must first determine what kind of software it’s running. Next, you need to figure out how to access this software, which often involves looking for the methods the IVI uses to update or load its operating system. Once you understand how the system updates, you’ll have the knowledge you need to identify vulnerabilities and modify the system.

Before you can begin making modifications, you need to know what operating system the IVI is running. The easiest way to do so is to search for the brand of the IVI—first, by looking for a label on the outside of the IVI unit or frame. If you don’t see a label, look for a display option on the interface that displays software version numbers and often the device name. Also, check online to see whether anyone has already researched your target system and, if the system is manufactured by a third party, whether it has a website and firmware updates. Download any firmware or tools you can find for later use. Find out how the system is updated. Is there a map update service available? What other update methods are available? Even if you find that system updates are sent over the air, it’s usually possible to find USB drives or a DVD containing map updates, like the one from a Honda Civic shown in Figure 9-1.

Figure 9-1: NavTeq infotainment unit in an open state

This IVI has a normal CD tray for music at the top plus a hidden plastic door at the bottom that folds down to reveal a DVD tray holding the map software.

Determining the Update File Type

System updates are often delivered as compressed files with .zip or .cab file extensions, but sometimes they have nonstandard extensions, like .bin or .dat. If the update files have .exe or .dll extensions, you’re probably looking at a Microsoft Windows–based system.

To determine how the files are compressed and their target architecture, view their headers with a hex editor or use a tool such as file available on *nix-based systems. The file command will report a file’s architecture, such as ARM or, as with the Honda Civic IVI shown in Figure 9-1, a Hitachi SuperH SH-4 Processor. This information is useful if you want to compile new code for a device or if you plan on writing or using an exploit against it.

If the file command hasn’t identified the type of file, you may be looking at a packed image. To analyze a firmware bundle, you can use a tool such as binwalk, which is a Python tool that uses signatures to carve out files from a collected binary. For instance, you can simply run binwalk on your firmware image to see a list of identified file types:

Using the -e flag would extract each of these files for further analysis and review. In this example, you can see a SquashFS filesystem was detected.

This filesystem could be extracted with the -e flag and then “unsquashed” using the unsquashfs tool to view the filesystem, as I’ve done here:

$ binwalk -e firmware.bin $ cd _firmware.bin.extracted $ unsquashfs -f -d firmware.unsquashed 140090.squashfs

The binewalk -e commands will extract all known files from firmware.bin to the folder _firmware.bin.extracted. Inside that folder, you’ll see files named after their hex address with an extension that matches the detected file type. In this example, the squashfs file is called 140090.squashfs because that was the location in firmware.bin.

Modifying the System

Once you know your system’s OS, architecture, and update method, the next thing to do is to see whether you can use this information to modify it. Some updates are “protected” by a digital signature, and these can be tricky to update. But often there’s no protection or the update process will simply use an MD5 hash check. The best way to find these protections is to modify the existing update software and trigger an update.

A good starting point for system modification is something with a visible result, like a splash screen or icon because once you successfully change it, you’ll know immediately (see Figure 9-2).

Figure 9-2: Example modification: NavTeq unit with a modified splash screen

Figure 9-2 shows how I modified the splash screen of an IVI system by replacing the normal background image with a Jolly Roger flag and the vehicle’s emblem with a character from Street Fighter. Replacing images in your splash screen is a safe way to ensure you can modify the IVI system without much risk of breaking the system.

Find an image in your update file, modify it, then reburn the update DVD and force a system update. (Find out how in the IVI’s manual.) If the update files were compressed in a single archive, be sure to recompress the modified version so that it appears in the same format as before you modified it.

If you run into a checksum issue and your update fails, look for a file in the update that might be a hash, such as a text file containing strings like 4cb1b61d0ef0ef683ddbed607c74f2bf. You’ll need to update this file with the hash of your new modified image. You may be able to guess the hashing algorithm by looking at the size of the hash and performing some trial and error. For instance, an 8-character hash, such as d579793f, may be CRC32; a 32-character hash, such as c46c4c478a4b6c32934ef6559d25002f, may be an MD5 hash; and a 40-character hash, such as 0aaedee31976f-350a9ef821d6e7571116e848180, may be SHA-1. These are the three most common hash algorithms, but there are others you might come across, and a quick Google search or reference to the tables at https://en.wikipedia.org/wiki/List_of_hash_functions should give you a clue as to which algorithm was used.

The Linux tools crc32, md5sum, and sha1sum will let you quickly calculate the hash of an existing file and compare it to the contents of the original text file. If you can generate a hash that matches that of the existing file, then you’ve found the correct algorithm.

For example, say you find a single file on an update DVD called Validation.dat that lists the contents of the files on the DVD, as shown in Listing 9-1. This listing includes the names of three files on the DVD and their associated hashes.

09AVN.bin b46489c11cc0cf01e2f987c0237263f9 PROG_INFO.MNG 629757e00950898e680a61df41eac192 UPDATE_APL.EXE 7e1321b3c8423b30c1cb077a2e3ac4f0

Listing 9-1: Sample Validation.dat file found on an update DVD

The length of the hash listed for each file—32 characters—suggests that this might be an MD5 hash. To confirm, use the Linux md5sum tool to generate an MD5 hash for each file. Listing 9-2 shows what that would look like for the 09AVN.bin file.

$ md5sum 09AVN.bin b46489c11cc0cf01e2f987c0237263f9 09AVN.bin

Listing 9-2: Using md5sum to see the hash of the 09AVN.bin file

Compare the hash for 09AVN.bin in Listing 9-1 with the results of running md5sum in Listing 9-2, and you’ll see that the hashes match; we’re indeed looking at an MD5 hash. This result tells us that in order to modify 09AVN.bin, we’d need to recalculate the MD5 hash and update the Validation.dat file that contains all the hashes with the new hash.

Another way to determine the algorithm used to create the hash is to run the strings command on some of the binaries or DLLs in your update package to search for strings in the file, like MD5 or SHA. If the hash is small, like d579793f, and CRC32 doesn’t seem to work, you’re probably looking at a custom hash.

In order to create a custom hash, you need to understand the algorithm used to create that hash, which will require digging in with a disassembler, such as IDA Pro, Hopper, or radare2, which is free. For instance, Listing 9-3 shows sample output from a custom CRC algorithm viewed in radare2:

| .------> 0x00400733 488b9568fff. mov rdx, [rbp-0x98] |- fcn.0040077c 107 | ||| | 0x0040073a 488d855ffff. lea rax, [rbp-0xa1] | ||| | 0x00400741 4889d1 mov rcx, rdx | ||| | 0x00400744 ba01000000 mov edx, 0x1 | ||| | 0x00400749 be01000000 mov esi, 0x1 | ||| | 0x0040074e 4889c7 mov rdi, rax | ||| | 0x00400751 e8dafdffff call sym.imp.fread | ||| | sym.imp.fread() | ||| | 0x00400756 8b9560ffffff mov edx, [rbp-0xa0] | ||| | 0x0040075c 89d0 mov eax, edx ➊ | ||| | 0x0040075e c1e005 shl eax, 0x5 ➋ | ||| | 0x00400761 01c2 add edx, eax ➌ | ||| | 0x00400763 0fb6855ffff. movzx eax, byte [rbp-0xa1] | ||| | 0x0040076a 0fbec0 movsx eax, al | ||| | 0x0040076d 01d0 add eax, edx | ||| | 0x0040076f 898560ffffff mov [rbp-0xa0], eax | ||| | 0x00400775 838564fffff. add dword [rbp-0x9c], 0x1 | || ; CODE (CALL) XREF from 0x00400731 (fcn.0040066c) | |`-----> 0x0040077c 8b8564ffffff mov eax, [rbp-0x9c] | | | | 0x00400782 4863d0 movsxd rdx, eax | | | | 0x00400785 488b45a0 mov rax, [rbp-0x60] | | | | 0x00400789 4839c2 cmp rdx, rax | `======< 0x0040078c 7ca5 jl 0x400733

Listing 9-3: Disassembly of a CRC checksum function in radare2

Unless you’re good at reading low-level assembler, this may be a bit much to start with, but here we go. The algorithm in Listing 9-3 reads in a byte at ➊, multiplies it by 5 at ➋, and then, at ➌, adds it to the hash to calculate the final sum. The rest of the assembly is mainly used by the read loop to process the binary file.

Apps and Plugins

Whether your goal is to perform firmware updates, create custom splash screens, or achieve other exploitation, you’ll often find that you can get the information you need to exploit or modify a vehicle by going after IVI applications rather than the IVI operating system itself. Some systems allow third-party applications to be installed on the IVI, often through an app store or a dealer-customized interface. For example, you’ll notice there’s usually a way for developers to sideload apps for testing. Modifying an existing plugin or creating your own can be a great way to execute code to further unlock a system. Because standards are still being written to define how applications should interface with the vehicle, every manufacturer is free to implement its own API and security models. These APIs are often ripe for abuse.

Identifying Vulnerabilities

Once you’ve found out how to update your system—whether by modifying the splash screen, company logo, warranty message, or other item—you’re ready to look for vulnerabilities in the system. Your choice of how to proceed will depend on your ultimate goal.

If you’re looking for existing vulnerabilities in the infotainment unit, the next step is to pull all the binaries off the IVI so you can analyze them. (This research is already covered in great detail in several books about reverse engineering, so I won’t go into detail here.) Check the versions of binaries and libraries on the system. Often, even in the case of map updates, the core OS is rarely updated, and there’s a good chance that an already identified vulnerability exists on the system. You may even find an existing Metasploit exploit for the system!

If your goal is, for example, to create a malicious update that wiretaps a vehicle’s Bluetooth driver, you have almost everything you need at this stage to do so. The only piece you may still need is the software development kit (SDK), which you use to compile the target system. Getting your hands on one will make your task much easier, although it’s still possible to create or modify a binary using a hex editor instead. Often the infotainment OS is built with a standard SDK, such as the Microsoft Auto Platform.

For example, consider a navigation system with certain protections designed to prevent a customer from using a DVD-R in the system. The manufacturer’s original idea was to charge owners $250 to purchase updated mapping DVDs, and they wanted to prevent people from simply copying someone else’s DVD.

In its attempt to prevent this type of sharing, the manufacturer added several DVD checks to the navigation system, as shown in the IDA display sample code in Figure 9-3. But say as a consumer you want to use a backup copy of your purchased DVD in your system rather than the original because your car gets really hot during the day and you don’t want the DVD to warp.

While an ordinary consumer isn’t likely to be able to bypass these DVD checks, it would be possible to locate the DVD checks and replace them with no-operation instructions (NOPs), which would make the checks literally do nothing. Then you could upload this modified version of the DVD check to your IVI and use your backup DVD for navigation.

NOTE

All the hacks mentioned so far can be done without removing the unit. However, you could dig even deeper by taking the unit out and going after the chips and memory directly, as discussed in Chapter 6.

Figure 9-3: IDA view of DVD checks

If you’re more comfortable attacking hardware than software and you’re able to remove the IVI from the target vehicle, you can go after the IVI system hardware instead. For that matter, if you’ve had no luck accessing the IVI system software, a hardware attack might provide additional insight that’ll help you find a way in. You’ll sometimes find that you can access system security keys by attacking the hardware when something like the update method mentioned earlier fails.

Dissecting the IVI Unit’s Connections

If you’re unable to gain access to a vehicle’s system through the update method discussed in the previous section, you can attack the IVI’s wiring and bus lines. Your first step will be to remove the IVI unit and then trace the wires back to the circuit board in order to identify its components and connections, like the ones shown in Figure 9-4.

Figure 9-4: Connector view of a double DIN IVI unit

When you take your IVI unit out, you’ll see a lot of wires because, unlike aftermarket radios, OEM units are heavily connected to the vehicle. The back metal panel on the IVI usually doubles as a heat sink, and each connector is often separated by its functionality. (Some vehicles keep the Bluetooth and cellular piece in another module, so if you’re looking to research a wireless exploit and the IVI unit doesn’t have this wireless module, continue looking for the telematics module.)

By tracing the actual wires or looking at a wiring diagram like the one shown in Figure 9-5, you can see that the Bluetooth module is actually a separate piece from the navigation unit (IVI). Notice in the diagram that the Bluetooth unit uses CAN (B-CAN) on pin 18. If you look at the navigation unit’s wiring diagram, you can see that instead of CAN, K-Line (pin 3) is directly attached to the IVI unit. (We discussed these protocols in Chapter 2.)

Figure 9-5: Hands-free wiring diagram

If you can determine whether your target is connected to a network bus, you’ll know just how much your exploit can control. At the very least, the bus directly connected to the target can be influenced by any code you put on the target system. For instance, in the wiring examples shown in Figure 9-5, a vulnerability in the Bluetooth module would give us direct CAN access; however, if we exploited the IVI’s navigation system, we’d need to use K-Line instead (see Figure 9-6). You can tell which network you have access to by looking at the wiring diagram in Figure 9-5 and seeing whether K-Line or CAN are connected to your target device. Which bus you’re on will affect your payload and what networked systems you’ll be able to influence directly.

Figure 9-6: K-Line specified in the wiring diagram for the navigation unit

Disassembling the IVI Unit

If your goal is to directly attack the system hardware or if you don’t have a wiring diagram showing the connections to the entertainment unit, you’ll need to start taking the unit apart. Because IVI units are really compact and they bundle a lot of functionality into a small area, taking them apart means removing lots of screws and several layers of connected circuit boards. The disassembly task is time consuming and complicated and should probably be your last resort.

To begin disassembly, start by removing the case. Each unit comes apart differently, but typically you can remove the front and back plate screws and then work your way down from the top. Once inside, you’ll most likely find a circuit board like the one shown in Figure 9-7.

Although the print on the circuit board is a little hard to read, you’ll probably find that many of the pins are labeled. Pay close attention to any connectors that are attached to the circuit board but not connected or that are covered by the heat sink. You’ll often find that certain connectors used during the manufacturing process are left behind, disconnected on the circuit board. These can be a great way in to the IVI unit. For example, Figure 9-8 shows a hidden connector revealed once the back panel was removed on the target IVI.

Hidden connectors are a great place to start when going after a device’s firmware. These connectors often have methods to load and debug the firmware running on the systems, and they can also provide serial-style debugging interfaces that you can use to see what’s happening with the system. In particular, you should look for JTAG and UART interfaces.

Figure 9-7: Many pins and connectors are labeled directly on the PCB.

Figure 9-8: Nonexposed hidden connector

At this stage, you should start tracing the pins and looking at data sheets for the onboard chips. After a bit of sleuthing as to where these pins connect, you should have a better idea of what you’re dealing with and the intended purpose of this hidden connector. (See Chapter 8 for more on analyzing circuit boards and reverse engineering hardware.)

Instead of tampering with your own factory-installed entertainment unit and risking damage, you can experiment with a test bench system, whether that’s one from a junkyard or an open source development platform. (Aftermarket radios aren’t a good choice because they don’t usually tie into the CAN bus network.) In this section, we’ll look at two open source entertainment systems that you can run in a VM on a PC, the GENIVI demo platform, and Automotive Grade, which requires an IVI.

GENIVI Meta-IVI

The GENIVI Alliance (http://www.genivi.org/) is an organization whose main objective is to drive the adoption of open source IVI software. Membership is paid, but you can download and participate in the GENIVI software projects for free. Membership, especially board-level membership, in GENIVI is very costly, but you can join the mailing list to participate in some of the development and discussions. The GENIVI system can be run directly on Linux with no need for an IVI. It’s basically a collection of components that you can use to build your own IVI.

In Figure 9-9, a high-level block diagram of the GENIVI system shows how the pieces fit together.

The GENIVI demo platform has some basic human–machine interface (HMI) functionality: the FSA PoC stands for fuel stop advisor proof-of-concept (proof of concept because certain of these apps aren’t used in production). The FSA is part of the navigation system and is designed to alert drivers if they are going to run out of fuel before reaching their destination. The Web browser and audio manager PoCs should be self-explanatory. Another component not shown in the figure is the navigation app. This app is powered by the open source Navit project (http://www.navit-project.org/) and uses a plugin for the freely licensed OpenStreetMap mapping software (https://www.openstreetmap.org/).

The GENIVI’s middleware components make up the core GENIVI operating system, and they’re discussed here in the order in which they appear in Figure 9-9 (persistency is excluded since there isn’t currently any documentation on this module):

Diagnostic log and trace (DLT) An AUTOSAR 4.0–compatible logging and tracing module. (Autosar is simply an automotive standards group; see https://www.autosar.org/.) Some features of the DLT can use TCP/IP, serial communications, or standard syslog.

Node state manager (NSM) Keeps track of the vehicle’s running state and is responsible for shutdown and for monitoring system health.

Node startup controller (NSC) Part of the NSM persistence. Handles all data stored on a hard drive or flash drive.

Audio manager daemon The audio hardware/software abstraction layer.

Audio manager plugins Part of the audio manager daemon.

Webkit Web browser engine.

Automotive message broker (AMB) Allows an application to access vehicle information from the CAN bus without having to know the specific CAN bus packet layouts. (The system you’re talking to must support OBD or AMB directly in order for this to work.)

Figure 9-9: GENIVI software layout

Building the Environment

The easiest way to build the GENIVI system on Linux is to use a Docker image. First, grab the easy build like this:

$ git clone https://github.com/gmacario/easy-build

NOTE

This Docker image won’t work on the eCryptfs filesystem that Ubuntu uses on home directories, so make sure to download and follow these instructions outside your default home directory.

You’ll need Docker installed if you don’t already have it. On Ubuntu, this command is:

$ sudo apt-get install docker.io

Then, cd into the easy-build/build-yocto-genivi folder in your Home directory and run this:

$ sudo docker pull gmacario/build-yocto-genivi $ sudo ./run.sh

Docker builds a little VM for you to work in, and running run.sh should put you in a root terminal environment in the Docker instance.

Now, finish the install by getting the rest of the GENIVI build and creating an image that you can use in the QEMU VM. Run the following commands:

# chmod a+w /dev/shm # chown build.build ~build/shared # su - build $ export GENIVI=~/genivi-baseline $ source $GENIVI/poky/oe-init-build-env ~/shared/my-genivi-build $ export TOPDIR=$PWD $ sh ~/configure_build.sh $ cd $TOPDIR $ bitbake -k intrepid-image

The output of the final bitbake command should look something like this:

Build Configuration: BB_VERSION = "1.24.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-14.04" TARGET_SYS = "i586-poky-linux" MACHINE = "qemux86" DISTRO = "poky-ivi-systemd" DISTRO_VERSION = "7.0.2" TUNE_FEATURES = "m32 i586" TARGET_FPU = "" meta meta-yocto meta-yocto-bsp = "(detachedfromdf87cb2):df87cb27efeaea1455f20692f9f1397c6fcab254" meta-ivi meta-ivi-bsp = "(detachedfrom7.0.2):54000a206e4df4d5a94db253d3cb8a9f79e4a0ae" meta-oe = "(detachedfrom9efaed9):9efaed99125b1c4324663d9a1b2d3319c74e7278"

As of this writing, the build process errors out on fetching the Bluez package.

Remove the following file, and try bitbake again:

$ rm /home/build/genivi-baseline/meta-ivi/meta-ivi/recipes-connectivity/bluez5/bluez5_%.bbappend

Once everything is finished, you should have images in your tmp/deploy/ images/qemux86/ folder.

Now you’re ready to run your image in an emulator. For ARM emulation, run this:

$ $GENIVI/meta-ivi/scripts/runqemu horizon-image vexpressa9

For x86, use this command:

$ $GENIVI/poky/scripts/runqemu horizon-image qemux86

And this command is for x86-64:

$ $GENIVI/poky/scripts/runqemu horizon-image qemux86-x64

You should now be ready to research a GENIVI-based IVI system. As you’ve seen, the steps can be a bit daunting. The most difficult part of working on GENIVI is getting it up and running. Once you have a system to look at, you can pick any executable to begin your security audit.

Automotive Grade Linux

Automotive Grade Linux (AGL) is an IVI system that you can run on a physical IVI unit. Unlike GENIVI, AGL doesn’t have a costly board structure. AGL’s goals are similar to those of GENIVI: it’s trying to build an open source IVI unit as well as other related parts, such as telematics and instrument clusters.

As of this writing, you should be able to find a demo image of AGL for VMware (last released in 2013), installation instructions, and a bootable USB version for x86 at the AGL website (http://automotivelinux.org/). These images are designed to run on in-vehicle computer hardware, like the Nexcom VTC-1000, a headless Linux device that comes with CAN and touchscreens. Unlike the GENIVI project, the AGL demonstration images are mainly designed and tested to run on hardware, although it may be possible to run some development images in a VM.

As you can see in Figure 9-10, the AGL demonstration image has a very pretty interface, but don’t expect all applications to run smoothly, as many are simply placeholders that are actively being built. Because AGL is normally tested on physical hardware, you’ll have to spend around $1,000 to get the hardware necessary to install AGL smoothly. It’s also possible to get an image to run on a QEMU VM as well. (One nice thing about buying a development IVI is that you can program it to work with any vehicle.)

Figure 9-10: Automotive Grade Linux sample screens

If you decide to run a physical IVI unit for testing, you’ll have to either pull a factory (OEM) IVI system from an existing vehicle or buy a development IVI, such as the Nexcom VTC-1000 or a model like those referenced in the Tizen hardware compatibility list (https://wiki.tizen.org/wiki/IVI/IVI_Platforms).

If you choose to go the OEM factory-installed route, you can buy one from the dealership or pull one from a junkyard. Development and OEM IVI units purchased directly from a dealership will typically run from $800 to $2,000, so it’s much more cost-effective to pull one from a junkyard, though it may be difficult to find your target high-end IVI system. You can also buy non-OEM aftermarket units, such as Kenwood or Pioneer, which—while often cheaper—typically won’t tie into a vehicle’s CAN system.

Unfortunately, pulling a radio out of a modern vehicle without destroying it isn’t an easy task. You’ll often need to remove the plastic around the gauge cluster on the dashboard and the plastic around the radio before you can remove the radio from its harness. If you run into an antitheft security code for the radio, check the owner’s manual for the code, if you’re lucky enough to find that. If you can’t find the code, be sure to grab the VIN from the donor vehicle because you might need it to get or reset the antitheft PIN. (If you grabbed the ECU from the vehicle, remember you can query that to get the VIN as well.)

You’ll need to refer to the wiring diagram for your IVI system in order to get it to start on its own, but you can leave out most of the wires that you’re not testing. If you’re building an OEM-based unit, it may be worth your while to completely disassemble the unit and to connect any test connectors so that you’ll not only have the normal IVI system running but also be able to access any of the hidden connectors.

You should now be comfortable analyzing your existing radio system. We’ve covered how to safely work in a VM or test environment to find vulnerabilities in IVI systems. These systems hold a lot of code and are the most powerful electronic systems in a vehicle. Mastery of the IVI units will give you full control of your target, and there’s no part of a vehicle with a greater concentration of attack surface than the IVI system. When performing security research, an IVI and telematics system will provide you with the most valuable vulnerabilities, and you’ll find that the vulnerabilities found in these systems will often be remote or wireless and directly connected to the vehicle’s bus lines.

The latest trend in vehicle technology is vehicle-to-vehicle (V2V) communication—or in the case of vehicles communicating with roadside devices, vehicle-to-infrastructure (V2I) communication. V2V communication is primarily designed to communicate safety and traffic warnings to vehicles through a dynamic mesh network between vehicles and roadside devices called the intelligent transportation system. This mesh connects various nodes—vehicles or devices—in the network and relays information between them.

The promise of V2V is so great that in February 2014 the US Department of Transportation announced its desire to implement a mandate requiring that V2V-based communication be included in all new light vehicles, though as of this writing nothing has been finalized.

V2V is the first automotive protocol to consider cybersecurity threats at the design stage, rather than after the fact. The details of V2V implementation and interoperation between countries are still being determined, so many processes and security measures are still undecided. Nevertheless, in this chapter, we’ll review the current design considerations in an attempt to offer guidelines for what to expect. We’ll detail the thinking behind different approaches and discuss the types of technologies likely to be deployed in the V2V space. We’ll also discuss several protocols used in V2V communications and the types of data they’ll transmit, and we’ll review V2V’s security considerations as well as areas for security researchers to focus on.

NOTE

Because this chapter focuses on a technology yet to be implemented, we won’t cover the reasons behind various features, nor will we discuss the ways that manufacturers can implement each feature because all of that detail is subject to change.

In the world of V2V communication, vehicles and roadside devices interact in one of three ways: via existing cellular networks; using dedicated short-range communication (DSRC), which is a short-range communication protocol; or via a combination of communication methods. In this chapter we’ll focus on DSRC, as it’s the most common method of V2V communication.

Cellular Networks

Cellular communication doesn’t require roadside sensors, and existing cellular networks already have a security system in place, so communication can rely on security methods provided by the cellular carriers. The security provided by cellular networks is at the wireless level (GSM), not the protocol level. If the connected device is using IP traffic, then standard IP security, such as an encryption and reduction of attack surfaces, still needs to be applied.

DSRC

DSRC requires the installation of specialized equipment in modern vehicles and new roadside equipment. Because DSRC is designed specifically for V2V communication, security measures can be implemented prior to widespread adoption. DSRC is also more reliable than cellular communication, with lower latency. (See “The DSRC Protocol” on page 179 for more on DSRC.)

Hybrid

The hybrid approach combines cellular networks with DSRC, Wi-Fi, satellite, and any other communication that makes sense, such as future wireless communication protocols.

In this chapter, we’ll focus on DSRC because it’s unique to the V2V infrastructure. The DSRC protocol will be the main protocol deployed by V2V, and you may see it mixed with other communication methods.

NOTE

You can use traditional methods to analyze communication, such as cellular, Wi-Fi, satellite, and so on. Evidence of these signals communicating doesn’t necessarily mean the vehicle is using V2V communication. However, if you see DSRC being transmitted, you’ll know that V2V has been implemented in that vehicle.

FUN WITH V2V ACRONYMS

The auto industry loves acronyms as much as any government does, and V2V is no exception. In fact, the lack of any universal V2V standard between countries means that the world of V2V acronyms can be especially messy because there’s little consistency and a good dose of confusion. To help you out, here are some acronyms that you’ll run into when researching V2V-related topics:

ASD Aftermarket safety device

DSRC Dedicated short-range communication

OBE Onboard equipment

RSE Roadside equipment

SCMS Security Credentials Management System

V2I, C2I Vehicle-to-infrastructure, or car-to-infrastructure (Europe)

V2V, C2C Vehicle-to-vehicle, or car-to-car (Europe)

V2X, C2X Vehicle-to-anything, or car-to-anything (Europe)

VAD Vehicle awareness device

VII, ITS Vehicle infrastructure integration, intelligent transportation system

WAVE Wireless access for vehicle environments

WSMP WAVE short-message protocol

DRSC is a one- or two-way short-range wireless communication system specifically built for vehicle communications between vehicles and roadside devices, or from vehicle to vehicle.

DSRC operates in the 5.85 to 5.925 GHz band reserved for V2V and V2I. The transmit power used by a DSRC device will dictate its range. Roadside equipment can transmit at higher-power ranges, allowing up to a 1,000 m specification, while vehicles can broadcast only at a power level that provides closer to 300 m ranges.

DSRC is based on the wireless 802.11p and 1609.x protocols. DSRC-and Wi-Fi-based systems, such as wireless access for vehicle environments (WAVE), use IEEE 1609.3 specification or the WAVE short-message protocol (WSMP). These messages are single packets with no more than 1,500 bytes and typically less than 500 bytes. (Network sniffers such as Wireshark can decode WAVE packets, which allows for easy sniffing of traffic.)

DSRC data rates depend on the number of users accessing the local system at the same time. A single user on the system would typically see data rates of 6 to 12Mbps, while users in a high-traffic area—say, an eight-lane freeway—would likely see 100 to 500Kbps. A typical DSRC system can handle almost 100 users in high-traffic conditions, but if the vehicles are traveling around 60 km/h, or 37 mph, it’ll usually support around only 32 users. (These data rates are estimated from the Department of Transportation’s paper “Communications Data Delivery System Analysis for Connected Vehicles.”1)

The number of channels dedicated to the 5.9 GHz range of the DSRC system varies between countries. For example, the US system is designed to support seven channels with one channel that acts as a dedicated control channel reserved for sending short high-priority management packets. The European design supports three channels with no dedicated control channel. This disparity is largely due to the fact that each country has different drivers for the technology: Europe’s system is market driven, while the US system has a strong vehicle safety initiative behind it. Therefore, while the protocols will interoperate, the types of messages supported and sent will differ significantly. (In Japan, DSRC is currently being used for toll collection, but the Japanese are also planning to use a 760 MHz band for crash avoidance. The Japanese 5.8 GHz channels don’t use 802.11p, but they should still support the 1609.2 V2V security framework.)

NOTE

While both Europe and the United States use 802.11p with ECDSA-256 encryption, the two systems are not 100 percent compatible. As of this writing, they incorporate various technical differences, such as where the signing stack is placed in the packet. There’s no good technical reason for this lack of standardization, so this will hopefully be fixed before widespread adoption.

Features and Uses

All DSRC implementations offer convenience and safety features, but their features differ. For example, the European DSRC system will use DSRC for the following:

Car sharing Would work like today’s vehicle sharing, such as car2go, except that instead of using a third-party vehicle dongle attached to the OBD-II connector to control the vehicle, it would use the V2I protocols

Connections to points of interest Similar to the points of interest, such as restaurants or gas stations, in a traditional navigation system but would be broadcast to passing vehicles

Diagnostics and maintenance Would report the reason why a vehicle’s engine light is on via DSRC instead of having to read codes from an OBD connector

Driving profiles for insurance purposes Would replace insurance-style dongles that record driving behavior

Electronic toll notification Would allow for automated payments at toll booths (already being tested in Japan)

Fleet management Would allow for the monitoring of fleets of vehicles, such as those used for trucking and transportation services

Parking information Would record duration of parking and could displace traditional parking meters

Security-driven areas like the United States are more concerned with communicating warnings about things like the following:

Emergency vehicles approaching Would notify vehicles of an approaching emergency vehicle

Hazardous locations Would warn drivers of hazards, such as an icy bridge or road surface, or falling rocks

Motorcycle approaches Would signal the approach of a passing motorcycle

Road works Would notify drivers of upcoming construction

Slow vehicles Would provide early notification of traffic congestion or traffic slowdowns due to slow-moving farm or oversized vehicles

Stationary (crash) vehicles Would warn of vehicles that have broken down or were in a recent collision

Stolen vehicle recovery Might work similarly to a LoJack-like service in that it would allow law enforcement to locate a stolen vehicle based on a radio beacon

Additional types of communication categories that could be implemented via DSRC include traffic management; law enforcement, such as communicating speeds or tracking vehicles; driver assistance, such as parking assistance or lane guidance; and highway automation projects, such as self-driving vehicles that use V2I roadways to assist in guidance.

Roadside DSRC Systems

Roadside DSRC systems are also used to pass standardized messages and updates to vehicles with information such as traffic data and hazard or road works warnings. The European Telecommunications Standards Institute (ETSI) has designed two formats for continuous traffic data, both of which use 802.11p: the cooperative awareness message (CAM) and the decentralized environmental notification message (DENM).

CAMs for Periodic Vehicle Status Exchanges

CAMs are broadcast periodically through the V2X network. ETSI defines the packet size of a CAM as 800 bytes and the reporting rate at 2 Hz. This protocol is still in its preliminary stages. If you encounter CAMs in the future, they may vary from the proposal, but we’re including the current proposed characteristics to give you a sense of what you can expect from the CAM protocol in the future.

CAM packets consist of an ITS PDU header and station ID as well as one or more station characteristics and vehicle common parameters.

Station characteristics may include the following:

• Mobile ITS station

• Physical relevant ITS station

• Private ITS station

• Profile parameters

• Reference position

Vehicle common parameters may consist of the following:

• Acceleration

• Acceleration confidence

• Acceleration controllability

• Confidence ellipse

• Crash status (optional)

• Curvature

• Curvature change (optional)

• Curvature confidence

• Dangerous goods (optional)

• Distance-to-stop line (optional)

• Door open (optional)

• Exterior lights

• Heading confidence

• Occupancy (optional)

• Station length

• Station-length confidence (optional)

• Station width

• Station-width confidence (optional)

• Turn advice (optional)

• Vehicle speed

• Vehicle-speed confidence

• Vehicle type

• Yaw rate

• Yaw rate confidence

Although some of these parameters are marked as optional, they’re actually mandatory in certain situations. For example, a basic vehicle profile—station ID of 111 in binary—must report crash status and whether the vehicle is carrying dangerous goods, if known. An emergency vehicle—station ID of 101 in binary—must report whether its lights and sirens are in use. Public transportation vehicles—station ID also 101—are required to report when their entry door is open or closed and may also report schedule deviation and occupancy count.

DENMs for Event-Triggered Safety Notifications

DENMs are event-driven messages. While CAMs are periodically sent so that they’re regularly updated, DENMs are triggered by safety and road hazard warnings. Messages might be sent in cases of:

• Collision risks (determined by roadside devices)

• Entering hazardous locations

• Hard braking

• High wind levels

• Poor visibility

• Precipitation

• Road adhesion

• Road work

• Signal violations

• Traffic jams

• Vehicles involved in an accident

• Wrong-way driving

These messages stop either when the condition that triggered them is gone or after a set expiry period.

DENMs can also be sent to cancel or negate an event. For instance, if roadside equipment identified that a vehicle was going the wrong way down a street, it could send an event to notify nearby drivers. Once that driver had moved the vehicle into the proper lane, the equipment could send a cancel event to signal that the risk had passed.

Table 10-1 shows the packet structure and byte position of a DENM packet.

Table 10-1: Packet Structure and Byte Position of a DENM Packet

There are optional messages as well. For example, the situation container could include TrafficFlowEffect, LinkedCause, EventCharacteristics, VehicleCommonParameters, and ProfileParameters, just as in the CAN structure.

WAVE Standard

The WAVE standard is a DSRC-based system used in the United States for vehicle packet communication. The WAVE standard incorporates the 802.11p standard as well as the range of 1609.x standards across the OSI model. The purposes of these standards are as follows:

802.11p Defines the 5.9 GHz WAVE protocol (a modification of the Wi-Fi standard); also has random local MAC addressing

1609.2 Security services

1609.3 UDP/TCP IPv6 and LLC support

1609.4 Defines channel usage

1609.5 Communication manager

1609.11 Over-the-air electronic payment and data exchange protocol

1609.12 WAVE identifier

NOTE

To explore the WAVE standard in more detail, you can use the OSI numbers in the preceding list to pull up the relevant reference documentation online.

WSMP is used in both service and control channels. WAVE uses IPv6, the most recent Internet protocol, for service channels only. IPv6 is configured by the WAVE management entity (WME) and also handles channel assignments and monitors service announcements. (The WME is unique to WAVE and handles the overhead and maintenance of the protocol.) Control channels are used for service announcements and short messages from safety appli