SECURITY AND PRIVACY VULNERABILITIES OF IN-CAR WIRELESS NETWORKS BY CARLES FIGUEROLA Submitted in partial fulfillment of the requirements for the degree of Master Thesis in Electrical Engineering in the Graduate College of the Illinois Institute of Technology Approved Advisor Chicago, Illinois August 2012
ACKNOWLEDGMENT This work would not have been completed without the guidance and help of Dr. Mahesh Krishnamurthy and Dr. Kui Ren. This project wouldn t have got so far without the mutual help of my teammates, Anahita Iselin, Kaoutar Tahiri and Issa-Pierre Loudghiri, with which we ve poured great amounts of work in the lab. I also have to thank Francesc Massanés, Iris Lorente and Oriol Caudevilla for the great support I ve received while in Chicago. And last but not least, I want to thank the people who have helped me get to where I am now, through undergraduate and graduate college back in Spain, the Batuts. iii
TABLE OF CONTENTS Page ACKNOWLEDGEMENT............................. iii LIST OF TABLES................................ vi LIST OF FIGURES................................ vii ABSTRACT................................... viii CHAPTER 1. INTRODUCTION.......................... 1 1.1. Problem Description...................... 1 1.2. Approach............................ 2 2. SUBSYSTEM ANALYSIS...................... 3 2.1. Modules Available....................... 3 2.2. Modules Chosen........................ 4 3. PROTOCOL STUDY........................ 6 3.1. CAN Protocol......................... 6 3.2. OBD-II Standard........................ 11 4. EXPERIMENT DESIGN....................... 13 4.1. Attacks planned........................ 13 5. TEST BENCH............................ 17 5.1. Parts for the test bench..................... 17 5.2. Test Bench Assembly...................... 17 5.3. Test Bench Testing....................... 21 5.4. Attack testing......................... 23 6. CONCLUSIONS........................... 26 6.1. Future work.......................... 26 APPENDIX................................... 28 A. OBD-II PID LIST.......................... 28 B. WIRING DIAGRAMS BOOK.................... 45 C. SELF TESTS REPORTED BY THE 01 01 PID........... 54 iv
D. EXAMPLE APPLICATION FROM ELM329 S DATASHEET..... 57 BIBLIOGRAPHY................................. 60 v
LIST OF TABLES Table Page 3.1 Message distribution of the base frame format.............. 8 3.2 Message distribution of the extended frame format............ 9 3.3 Useful AT commands for the ELM327 integrated circuit......... 12 5.1 Showcase of the different pair of ECU options on the market........ 18 5.2 List of scan tools to be bought for the test bench............. 19 5.3 PCM pins used for the test bench.................... 19 5.4 ABS pins used for the test bench..................... 20 5.5 OBD-II pins used for the test bench................... 20 C.1 b-bit definition of monitoring tests.................... 55 C.2 c and d bit definition for spark ignition engines.............. 55 C.3 c and d bit definition for compression ignition engines.......... 56 vi
LIST OF FIGURES Figure Page 3.1 A standalone OBD-II scan tool..................... 11 3.2 Multiple kinds of OBD-II interfaces: bluetooth on top, Wi-Fi on the left and USB on the right.......................... 11 4.1 Diagram of the attack experiment.................... 13 4.2 Diagram of the direct attack...................... 14 4.3 Diagram of the spoofing attack..................... 15 4.4 Diagram of the CAN bus attack..................... 16 5.1 Wiring done to the PCM for the test bench............... 19 5.2 Wiring done to the ABS for the test bench............... 20 5.3 Wiring done to the scan tool for the test bench............. 20 5.4 The test bench assembled although only one scan tool can be seen here. 21 5.5 Window of the ScanMaster-ELM Car Diagnostic Software........ 22 5.6 Serial information exchange for the Monitor status PID........ 22 5.7 Breadboard with the ELM329-based scan tool implemented....... 24 D.1 Circuit of the ELM329-based scan tool................. 58 D.2 Components used on the circuit on figure D.1.............. 59 vii
ABSTRACT The objective of this work is to analyze and test the wireless integrity of a typical car s network. The motivation for this work comes from the hazard that is to have security intrusions for a tool that a huge per cent of people use and that, upon failing, can produce such great damage. First, the basis of a car s network will be studied and a plan of attack will be put together. Then, a working analogue of a common car will be used to put that plan to test and draw conclusions. This work might become the first step of a larger project to improve and upgrade car network security but at least for now should be able to put in evidence the danger that all car users could be subject when driving. viii
1 CHAPTER 1 INTRODUCTION 1.1 Problem Description Cars nowadays use electronic networks extensively. The main use is for intra-car communications, where all the subsystems use it to share data and decide on actions to take. External communications are also emerging, mostly on the car-to-infrastructure mode, with which some manufacturers are providing to its higher paying customers some level of remote control of their car or real time information of the car s performance [3]. Intra-car networks have evolved little from the first use of the CAN 1 protocol in 1986. More subsystems have been connected to the car s bus, but the protocol has stayed mostly the same. Other protocols were developed and some are used alongside CAN, but it still remains widely used as all US cars since 2008 are required to support it. There s also another instance of intra-car wireless communication, the Tire Pressure Monitor. As the pressure sensor is inside the wheel, for mechanical limitations, the information is transmitted wirelessly. Previous work [6] has shown that intruding in this network cannot change the actual operation of the car, only the information shown on the dashboard concerning the tire pressure. The main security issues of the use of the CAN protocol usage on automobiles are summarized on the list below: No authentication: all the devices trust each other in the network and there s no attempt made to check the source of the message sent. One of the worst examples is that any device on the bus could issue a reflashing sequence and change the firmware of any other device. Poor protocol implementation: the protocol implementation does not properly reflect the protocol standard. For example it should not be possible to put the Engine Control 1 Controller Area Network, extensively explained on Section 3.1
2 Module (ECM) into programming mode while the vehicle is moving. However, in some implementations these failsafe mechanisms are not properly set. These problems are of a greater concern when it is known this bus is populated with dozens of nodes, ranging from braking systems, steering modules or engine control to lock control, HVAC or audio modules. As previously said, car-to-infrastructure communications are starting to be implemented in some car ranges. These communications rely mostly on another of those modules attached to the bus, the Telematics module. As the regulated standard is on the side of the CAN bus, the communications from and to the car vary widely in different car manufacturers. Most use mobile phone networks to relay the information to the manufacturer s servers and then the user s phone internet connection to get that information to the user. These networks have higher level security and with them not being a standard, it would require a different study for each manufacturer. Those are the reasons why this document will target the internal bus and attack its security. 1.2 Approach The frame of this project has to be set first. These are the steps that will be taken to ensure the proper method of study: 1. List the typical subsystems found on most cars and decide which of those are critical for the integrity of the car and thus, its passengers. 2. Study the CAN standard and its use in the car s network. 3. Design an experiment to highlight the fragility of the bus 4. Design and implement a test bench to carry out the experiment.
3 CHAPTER 2 SUBSYSTEM ANALYSIS 2.1 Modules Available Listed below are the modules found on most existing cars [5]. The highlighted modules are the ones that are deemed dangerous and thus, suited to be studied [1]. Airbag Control Module: This module controls and triggers the Airbags in case of an accident. Triggering them without any particular reason could make the driver lose control of the car and crash. Body Control Module: This module controls locks, electric windows mirrors and other miscellaneous elements of the car s body. They don t present an immediate danger for the car occupants. Electronic Brake Control Module: This module actuates the brakes and keeps the tires from slipping. It can be dangerous if overrided not only because the car can lose control on braking but because it could be made to trigger any brake independently and unexpectedly. Engine Control Module: This is the main module in the car. It controls, among others, ignition timing, valve timing, air/fuel ratio and idle speed. This module can have disastrous effects on the car as bad or malicious data can even make irreparable damage to the engine. HVAC Module: This Heating, Ventilation and Air Conditioning module controls the environment of the interior of the car. As the explanation suggests it poses low danger to the car or its occupants. Instrument Panel Cluster: This module controls the information shown to the user through the instrument panel. It doesn t pose an immediate threat to the integrity of the car.
4 Power Steering Control Module: As the name implies, this module assists and controls the power steering. It isn t a particularly critical module as if power steering is deactivated, the car can still be driven by manual steering. Radio Control Module: This module not only controls the radio, but also other chimes and beeps inside the car. It s not particularly dangerous. Remote Control Door Lock Receiver: as its name implies, this module is used to detect the remote controlled key and allow entrance to the car itself. It does pose a security problem but not a personal danger to people directly. Telematics Module: As stated on Section 1.1, this module is used to communicate to the manufacturer s servers. It is also used for the wireless communications in-car, for example the bluetooth connectivity to a mobile phone or the gps antenna. Theft Deterrent Module: It s used to identify the correct key on ignition. It s not a particularly dangerous module for the car s integrity. Transmission Control Module: This module is mainly used on automatic cars to electronically change gears when it s needed. As with others, this module doesn t pose an immediate danger to the car or its occupants. 2.2 Modules Chosen From all these devices the Telematics Module is pretty much non-existent on the aftermarket so it had to be taken off the test list. From the other three, because of their apparent danger, the Engine Control Module and the Electronic Brake Control Module were chosen for the future test bench build. It has to be noted that most cars use not only one bus but two. The first one, usually referred to High Speed Bus groups the highest priority ECUs so that an error from a low priority ECU doesn t interfere with the critical car systems. These two buses are usually bridged (not physically) by one or more ECUs, the Body Control Module or the
5 Telematics Module. All the modules chosen are connected to the hight priority, High Speed Bus.
6 CHAPTER 3 PROTOCOL STUDY This chapter focuses on two main subjects. The CAN bus and the OBD-II 2 standard. The first one is the most widely used protocol for the intra car network. All the ECU must support at least this standard in the USA by law since 2008. The actual name of the standard used is ISO 15765-4, which is a variant of CAN, but it s common use to refer to both with the same name. The OBD-II standard is a conglomerate of protocols (SAE J1850 PWM, SAE J1850 VPW, ISO 9141-2, ISO 14230 KWP2000 and ISO 15765-4) and a physical socket which are used to get information from the car. It s mainly used to get the status of the car s electronic components or the error messages those modules might have stored through usage. 3.1 CAN Protocol The CAN protocol [4] is a distributed, half-duplex, message-based protocol. The priority of the transmissions is set by the ID with which the devices begin the messages, with bit 0 being higher priority or dominant. If two devices start sending data simultaneously, the one with higher priority ID will overwrite the ID of the other device and that second device will back off the transmission. The bus can operate to rates up to 1Mbps for lengths below 40m, but the car industry usually uses the standard at 250 or 500 kbps. them. There are four main kinds of messages with a different frame format for each of Data frame: contains data from a device for transmission Remote frame: used to request data from another device Error frame: used for error reporting among devices 2 On-Board Diagnostics
7 Overload frame: used for delays between certain events 3.1.1 Data Frames. This frames use two message formats, the Base frame format and the Extended frame format. The first one has to be supported by all devices while the second is optional. The main difference is the support for a longer ID field and thus, the support for more devices in the bus simultaneously.
8 3.1.1.1 Base frame format. The bit distribution for the base frame format can be seen on Table 3.1. Table 3.1: Message distribution of the base frame format Field name Length (in bits) Purpose Start-of-frame 1 Denotes the start of frame transmission Identifier 11 A (unique) identifier for the data which also represents the message priority Remote transmission request (RTR) Identifier extension bit (IDE) 1 1 Dominant (0) Must be dominant (0). Optional Reserved bit (r0) 1 Reserved bit (it must be set to dominant (0), but accepted as either dominant or recessive) Data length code (DLC) 4 Number of bytes of data (0-8 bytes) Data field 0-64 Data to be transmitted (length in bytes dictated by DLC field) CRC 15 Cyclic Redundancy Check CRC delimiter 1 Must be recessive (1) ACK slot 1 Transmitter sends recessive (1) and any receiver can assert a dominant(0) ACK delimiter 1 Must be recessive (1) End-of-frame (EOF) 7 Must be recessive (1)
9 3.1.2 Extended frame format. Table 3.2: Message distribution of the extended frame format Field name Length (in bits) Purpose Start-of-frame 1 Identifier A 11 Denotes the start of frame transmission First part of the (unique) identifier for the data which also represents Substitute remote request (SRR) the message priority 1 Must be recessive (1). Optional Identifier extension bit (IDE) 1 Must be recessive (1). Optional Identifier B 18 Second part of the (unique) identifier for the data which also represents the message priority Remote transmission 1 Must be dominant (0) request (RTR) Reserved bits (it must be set dom- Reserved bits (r0,r1) 2 inant (0), but accepted as either dominant or recessive) Data length code (DLC) 4 Number of bytes of data (0-8 bytes) Data field 0-64 Data to be transmitted (length in bytes dictated by DLC field) CRC 15 Cyclic Redundancy Check CRC delimiter 1 Must be recessive (1) Transmitter sends recessive (1) and ACK slot 1 any receiver can assert a dominant(0) ACK delimiter 1 Must be recessive (1) End-of-frame (EOF) 7 Must be recessive (1)
10 The bit distribution for the extended frame format can be seen on Table 3.2. Both protocols can coexist in the system. If a device using the base format receives an extended encoded message, it will discard it when it gets the Identifier Extension Bit as recessive. The devices with support for both protocols will continue listening to the transmission and get the whole message. 3.1.3 Remote Frames. This frames are queries for data sent from one device to another. They are very similar to data frames, the only difference being that the Remote Transmission Request is recessive (1) and the data field is always empty. 3.1.4 Error Frames. There are two types of error frames, active and passive. The active errors use dominant bits and thus, complete arbitration with other messages and are always sent first. Some devices which are not of a very critical nature are set to only use passive error frames, which use recessive bits an don t make the CAN bus unusable by overloading it if they are failing. Error frames have only two fields: Error flag - 12 bits (only 6 are sent from the actual device, the other 6 are only sent when other devices echo an error flag 3 ) Error Delimeter - 8 recessive bits 3.1.5 Overload frames. The overload frame has mainly two uses. The first is to signal that the sender is busy 3 The CAN protocol uses bit stuffing, which means that a bit of opposite polarity is inserted when five consecutive bits of the same polarity are sent because the listening devices could lose synchronization. This is due to the non-return to zero (NRZ) coding used. Six consecutive bits of the same polarity are impossible to be seen in normal operation of the bus
11 and no more messages can be received at the moment. The other is sent when a message s last bit received is dominant and means that the receiver might have lost synchronization. The bit disposition is the same as the error frame. Each device cannot send more than two overload frames consecutively. 3.2 OBD-II Standard Using OBD-II Standard is mandatory for all US sold cars since 1996. This ensures that any repair technician has the same information as the official repair shop. It works in request-reply mode where an external device is attached to the CAN bus through the OBD-II port and can ask for the status of each subsystem directly. This communication uses the SAE J/1979 PIDs 4 and is usually extended by manufacturers with extra PIDs. A list of the standard PIDs can be found on appendix A. 3.2.1 OBD-II Scan Tools. An OBD-II scan tool is the device used to get and send information from the car. They can be either standalone (as the one depicted on Figure 3.1) or used as a gateway to connect to a computer or even a smartphone (as the ones shown on Figure 3.2. Some of those tools can become a big security issue as they open a path for unauthorized wireless devices to have access to the CAN bus on the car, and thus have access to all the car s critical devices. Figure 3.1: tool A standalone OBD-II scan Figure 3.2: Multiple kinds of OBD-II interfaces: bluetooth on top, Wi-Fi on the left and USB on the right 4 Paramter IDs
12 Most of the consumer level scan tool devices are built around the ELM327 integrated circuit. This chip is a multi-protocol interpreter for all the OBD-II protocols available. It has a RS232 5 interface to relay the data captured from the car s side. It encodes all the information received from the serial interface to the autodetected protocol used on the car it is connected to and decodes the response from the targeted ECU and sends it back. To configure and issue commands to the actual ELM327, the data must start with AT (mimicking old modems that also used RS232). The most important commands that should be useful to get the most information possible from the car are listed on Table 3.3. Table 3.3: Useful AT commands for the ELM327 integrated circuit AT Z AT H1 AT MA Soft resets the device. Activates showing the complete headers of the messages. Outputs all the OBD-II messages on the CAN bus until a character is received through the serial interface. AT SP It sets the protocol to one from the OBD-II standards. It can also be set to autodetect automatically the protocol. AT DP Display the current protocol used. 5 RS232 is one of the most widely used serial communications protocol.
13 CHAPTER 4 EXPERIMENT DESIGN The attack proposed in this document attempts to wirelessly compromise a car s security and consequently that of its occupants. As previously said, it is difficult to procure a Telematics unit and the integrated wireless interfaces it uses are intrinsically secure. It was decided that the scope of the wireless attack in this document would be shifted to using a device attached to the OBD-II port (and consequently to the CAN bus) with wireless capabilities. The diagram to test this attacks can be seen on the Figure 4.1 [2]. Figure 4.1: Diagram of the attack experiment This diagram plans for two scan tools present on the experiment. This was planned so that there could always be an uninterrupted monitoring of the data present on the CAN bus. 4.1 Attacks planned bus attack. Three potential attacks are proposed, a direct attack, a spoofing attack and a CAN
14 4.1.1 Direct Attack. This attack is based on the usage of OBD-II PIDs. Orders and requests flow through the CAN bus from and to devices. This attack plans to impersonate one such device and command another one with those commands. A diagram showcasing this attack can be seen on Figure 4.2. Figure 4.2: Diagram of the direct attack 4.1.2 Spoofing Attack. This attack intends to spoof a communication between two devices. The plan is to listen to the bus and when a request is made, reply with erroneous data pretending to be the device firstly queried. The biggest problem with this attack is the timing. Before the response is sent from the real device, the attacking part has to read, process the messages from the bus, prepare an erroneous message, and send it back to the bus. This could be potentially difficult as the RS232 interface on most of the scan tools can t work at speeds above 115.2kbps and the CAN protocol on cars usually operates at 500 or 250kbps. To mitigate most of those delays, a custom scan tool is planned to be built based with an ELM329 6 and a microcontroller directly attached. This microcontroller could then be programmed or controlled wirelessly. The diagram depicting this setup can be found on 6 The ELM329 was chosen over the ELM327 as it has the ability to send an arbitrary CAN message at any time. Other functions are basically the same.
15 Figure 4.3. Figure 4.3: Diagram of the spoofing attack 4.1.3 CAN BUS Attack. As seen on section 3.1, the CAN bus has arbitration through the use of dominant and recessive bits. In the process of arbitration, the device with the lowest ID transmits and the other devices notice that they have sent a recessive (1) bit but a dominant (0) bit is actually on the bus and back off. This can be used as an advantage. If somehow the bus were always on a dominant bit, no devices would be able to communicate. This means that all the ECUs would be isolated and normal operation of the car would not be assured. As with the other attack, a microcontroller would be used to carry out the attack, this time without the ELM device as no OBD-II messages need to be sent. This microcontroller would short the bus either with a timeout or with wireless control as with the spoofing attack. Figure 4.4 show what the setup would be in this case.
Figure 4.4: Diagram of the CAN bus attack 16
17 CHAPTER 5 TEST BENCH 5.1 Parts for the test bench As shown on Figure 4.1, the test bench was designed to have two ECUs (ECM 7 and EBCM 8 ) and at least two scan tools (one wired and one wireless). It was important for compatibility that the two ECUs were from a car of the same brand, model and manufacturing year. The biggest aftermarket for these kind of devices has been found to be ebay 9. Three pairs of these devices were found from three different vehicles and can be seen on Table 5.1. As can be seen on table 5.1, the obvious choice is to get the 2009 Ford Focus ECUs. Not only are they the newest (and newer than 2008, so it means that they will support CAN as per law) but they are also the cheapest pair. All the car parts use proprietary connectors and it will be necessary to also buy the official wiring diagram that manufacturers issue to repair shops. It can also be found in ebay for a price of around $40. The other components to be bought are the scan tools. Table 5.2 lists those items from the Amazon store. 5.2 Test Bench Assembly With the help of the wiring diagrams from the manufacturer (which can be found on appendix B), the pins needed were located. As the wiring diagrams are those of the cable connectors and not those of the connectors on the devices, they are mirrored. Fig- 7 Engine Control Module 8 Electronic Brake Control Module 9 ebay is a widely known bidding site that also allows some users to set up a virtual store and sell products 10 The Powertrain Control Module is an ECU that combines the functions of the Engine Control Module and the Transmission Control Module.
18 Table 5.1: Showcase of the different pair of ECU options on the market. Component Picture Connector Price 09 Ford Focus PCM 10 Propietary $75.00 09 Ford Focus ABS Propietary $79.99 07 Chevrolet Trailblazer ECM Propietary $89.99 07 Chevrolet Trailblazer EBCM Propietary $199.95 01 Dodge Durango ECM Propietary $79.00 01 Dodge Durango ABS Propietary $122.50 ures 5.1, 5.2 and 5.3 show the wiring used to connect the PCM, ABS and scan tool. Figure 5.4 shows the complete test bench with the power supply taking the car s battery function and the oscilloscope showing a random CAN message on the bus.
19 Component Image Connector Price USB scan tool OBD-II $11.19 Bluetooth scan tool OBD-II $13.31 Wi-Fi scan tool OBD-II $49.53 Table 5.2: List of scan tools to be bought for the test bench Table 5.3: PCM pins used for the test bench Pin usage 21 Power (12V) 42 Power (12V) 43 CAN Low 59 CAN High Figure 5.1: Wiring done to the PCM for the test bench 62 Power (12V) 67 Power (12V) 68 Power (12V) 69 Ground 70 Ground
20 Table 5.4: ABS pins used for the test bench Pin usage 1 Power (12V) 14 Power (12V) 20 Power (12V) Figure 5.2: Wiring done to the ABS for the test bench 21 CAN Low 23 CAN High 26 Ground Table 5.5: OBD-II pins used for the test bench Pin usage 4 Ground 5 Ground Figure 5.3: Wiring done to the scan tool for the test bench 6 CAN High 14 CAN Low 16 Power (12V)
21 Figure 5.4: The test bench assembled although only one scan tool can be seen here 5.3 Test Bench Testing After successfully assembling the test bench, it had to be put to initial tests to check that there were no major differences from a car environment. A car diagnostic software was used initially for that purpose. The software used is called ScanMaster-ELM. It can use any ELM327 based scan tool to get the car s information. Upon connecting the scan tool and configuring the software, the pairing was done. It can be seen in Figure 5.5 that the PCM is responding properly to the software. The main log shows that the PCM has been detected properly. In addition, a VIN code can be seen on the status bar at the bottom. This identifies uniquely each car and its presence also means that everything is working as expected. After making sure that the test bench s CAN bus performed the same way as a
22 Figure 5.5: Window of the ScanMaster-ELM Car Diagnostic Software car s, the control of the ELM327 was changed to a serial console. Raw messages can be sent to the bus and the replies are received and can be analyzed. Figure 5.6 shows what the PCM replied when sent the Monitor status PID (01 01). Figure 5.6: Serial information exchange for the Monitor status PID The response from the PCM is explained below: 41 : All responses begin with adding 40 to the request mode.
23 01 : Then, the PID is repeated 84 07 E5 E5 : This is the actual response. As it warrants more attention, it will be properly explained below. The first thing to do is to convert the hexadecimal code to decimal: 8 4 0 7 E 5 E 5 1000 0100 0000 0111 1110 0101 1110 0101 d7 - d4 d3 - d0 c7 - c4 c3 - c0 b7 - b4 b3 - b0 a7 - a4 a3 - a0 From the first byte, the bit a7 indicates if the Check Engine Light should be on (in this case, it should). The bits a0-a6 are the number of confirmed emissions-related DTCs 11 available for display. In this case, the number is 101, understandable because the PCM cannot find any sensor it should normally have attached. The bit b3 indicates if the engine uses spark ignition or compression ignition (gasoline or diesel respectively). The other bits from the byte b and byte c and d work in pairs to mark if a self-test is available and if it has not yet been completed. For example, the bits b0 and b4 mean that the misfire test is available and is not incomplete. The whole list of tests can be found on appendix C 5.4 Attack testing 5.4.1 Direct Attack. The direct attack has not been successful thus far. The reason is that the publicly released CAN information is mainly for getting information and not for setting information. Car manufacturers extend the CAN protocol for these uses but that information is not shared openly. 5.4.2 Spoofing Attack. 11 Diagnostic Trouble Codes
24 The spoofing attack starts with building a custom ELM329-based scan tool. For the test bench, the device will be attached to a computer instead of to a microcontroller. The circuit is based on the example applications from the ELM329 s datasheet, which can be found on appendix D. The final build for the test bench can be seen on Figure 5.7. This device worked as expected with both the CAN and RS232 interfaces communicating properly. Figure 5.7: Breadboard with the ELM329-based scan tool implemented Unfortunately, although the PCM device worked as intended and replied to the OBD-II requests, the ABS device didn t send proper CAN messages. As this test needed to intercept a communication between two devices, it couldn t be carried out. To remedy this problem, the third most critical ECU, as listed on section 2.2, was bought. In this case, the Airbag Control Module remained silent and no CAN messages could be captured. Thus, this test was unsuccessful as well. 5.4.3 CAN Bus Attack. This attack has been the most successful of the three. By shorting the two cables that compose the CAN bus, all the CAN messages from the bus disappear. Neither the oscilloscope or the scan tools show CAN information. Upon disconnecting the short, all the information reappears and the bus returns to its normal operation. However, for security concerns, this couldn t be tested on a full-scale car. It is unknown if permanent damage can
25 be done to the devices attached to the CAN bus with this method, and although it didn t seem to have any visible effect on the test bench ECUs, the possibility cannot be neglected from a security standpoint.
26 CHAPTER 6 CONCLUSIONS This document began with the premise to analyze and attack a car s network wirelessly. Thus, the CAN bus was found to be one of the most insecure links in the car s security. By simulating this bus with a test bench using the most critical modules found in the car, some attacks could be tested. Most of these attacks were unsuccessful thanks to the lack of availability of the protocols used inside the car and lack of proper modules that worked well with each other. However, a prominent theme has been found during this project: the CAN bus is completely subject to major security issues. As stated previously, the protocol used is quite old and it has no security measures by default, they have to be implemented on higher levels of the network stack. Car companies have been extending the usage of the bus for even more devices and communications but have not implemented the security needed to make sure that no tampering is possible. Thus, gaining access to this bus means that all the critical systems of the car are subject to be compromised. This isn t a thing that seems to be changing soon. The protocol that is proposed to replace CAN, FlexRay, doesn t seem to have any inherent security embedded as well. It s still the manufacturer who has to implement this security to its devices, and it seems that it s not the manufacturer s priority yet. 6.1 Future work This project can be expanded with the help of some factors. This project has been subject to major delays when buying the parts off ebay. Even one of the sellers disappeared and the device had to be ordered again. With more time or an agreement with a manufacturer, all these delays can be minimized. Following that idea, with an agreement with a manufacturer, more information could be obtained about the custom extensions that are implemented to the CAN bus and the
27 protocols used. This would accelerate a lot the working process. Finally, as car-to-infrastructure networks grow and become ubiquitous and standardized, it could be easier to find an attack vector that affected most, if not all, the different manufacturers. This would be an even a bigger security issue as these networks have no distance limitation to the targeted car and could be used wide-scale to attack a big number of cars simultaneously.
28 APPENDIX A OBD-II PID LIST
Mode (hex) PID (hex) 01 00 4 01 01 4 Data bytes returned Description PIDs supported [01-20] Monitor status since DTCs cleared. (Includes malfunction indicator lamp (MIL) status and number of DTCs.) 01 02 2 Freeze DTC Min value Max value Units Formula Bit encoded [A7..D0] == [PID 0x01..PID 0x20] See below. Bit encoded. See below. 01 03 2 Fuel system status Bit encoded. See below. 01 04 1 01 05 1 01 06 1 01 07 1 01 08 1 01 09 1 Calculated engine load value Engine coolant temperature Short term fuel % trim Bank 1 Long term fuel % trim Bank 1 Short term fuel % trim Bank 2 Long term fuel % trim Bank 2 0 100 % A*100/255-40 215 C A-40-100 Subtracting Fuel (Rich Condition) -100 Subtracting Fuel (Rich Condition) -100 Subtracting Fuel (Rich Condition) -100 Subtracting Fuel (Rich Condition) 01 0A 1 Fuel pressure 0 765 99.22 Adding Fuel (Lean Condition) 99.22 Adding Fuel (Lean Condition) 99.22 Adding Fuel (Lean Condition) 99.22 Adding Fuel (Lean Condition) 29 01 0B 1 Intake manifold 0 255 % (A-128) * 100/128 % (A-128) * 100/128 % (A-128) * 100/128 % (A-128) * 100/128 kpa (gauge) kpa A*3
01 0B 1 Intake manifold absolute pressure 0 255 (absolute) A 01 0C 2 Engine RPM 0 16,383.75 rpm ((A*256)+B)/4 01 0D 1 Vehicle speed 0 255 km/h A 01 0E 1 Timing advance -64 63.5 relative to #1 cylinder A/2-64 01 0F 1 Intake air temperature -40 215 C A-40 01 10 2 MAF air flow rate 0 655.35 grams/sec ((A*256)+B) / 100 01 11 1 Throttle position 0 100 % A*100/255 01 12 1 01 13 1 01 14 2 01 15 2 01 16 2 01 17 2 01 18 2 01 19 2 Commanded secondary air status Oxygen sensors present Bank 1, Sensor 1: Oxygen sensor voltage, Short term fuel trim Bank 1, Sensor 2: Oxygen sensor voltage, Short term fuel trim Bank 1, Sensor 3: Oxygen sensor voltage, Short term fuel trim Bank 1, Sensor 4: Oxygen sensor voltage, Short term fuel trim Bank 2, Sensor 1: Oxygen sensor voltage, Short term fuel trim Bank 2, Sensor 2: Oxygen sensor voltage, Short term fuel trim 0-100(lean) 0-100(lean) 0-100(lean) 0-100(lean) 0-100(lean) 0-100(lean) 1.275 99.2(rich) 1.275 99.2(rich) 1.275 99.2(rich) 1.275 99.2(rich) 1.275 99.2(rich) 1.275 99.2(rich) Volts % Volts % Volts % Volts % Volts % Volts % Bank 2, Sensor 3: A/200 30 Bit encoded. See below. [A0..A3] == Bank 1, Sensors 1-4. [A4..A7] == Bank 2... A/200 (B-128) * 100/128 (if B==0xFF, sensor is not used in trim calc) A/200 (B-128) * 100/128 (if B==0xFF, sensor is not used in trim calc) A/200 (B-128) * 100/128 (if B==0xFF, sensor is not used in trim calc) A/200 (B-128) * 100/128 (if B==0xFF, sensor is not used in trim calc) A/200 (B-128) * 100/128 (if B==0xFF, sensor is not used in trim calc) A/200 (B-128) * 100/128 (if B==0xFF, sensor is not used in trim calc)
01 1A 2 Oxygen sensor voltage, Short term fuel trim 0-100(lean) 1.275 99.2(rich) Volts % (B-128) * 100/128 (if B==0xFF, sensor is not used in trim calc) 01 1B 2 01 1C 1 Bank 2, Sensor 4: Oxygen sensor voltage, Short term fuel trim OBD standards this vehicle conforms to 0-100(lean) 1.275 99.2(rich) Volts % A/200 (B-128) * 100/128 (if B==0xFF, sensor is not used in trim calc) Bit encoded. See below. 01 1D 1 Oxygen sensors present 01 1E 1 Auxiliary input status 01 1F 2 01 20 4 01 21 2 01 22 2 01 23 2 01 24 4 01 25 4 01 26 4 Run time since engine start PIDs supported [21-40] Distance traveled with malfunction indicator lamp (MIL) on Fuel Rail Pressure (relative to manifold vacuum) Fuel Rail Pressure (diesel, or gasoline direct inject) O2S1_WR_lambda(1): Equivalence Ratio Voltage O2S2_WR_lambda(1): Equivalence Ratio Voltage O2S3_WR_lambda(1): Equivalence Ratio Voltage 0 65,535 seconds (A*256)+B 0 65,535 km (A*256)+B Similar to PID 13, but [A0..A7] == [B1S1, B1S2, B2S1, B2S2, B3S1, B3S2, B4S1, B4S2] A0 == Power Take Off (PTO) status (1 == active) [A1..A7] not used Bit encoded [A7..D0] == [PID 0x21..PID 0x40] See below. 0 5177.265 kpa ((A*256)+B) * 0.079 0 655,350 0 0 0 0 0 0 1.999 7.999 2 8 2 8 31 kpa (gauge) N/A V N/A V N/A V ((A*256)+B) * 10 ((A*256)+B)*2/65535 or ((A*256)+B)/32768 ((C*256)+D)*8/65535 or ((C*256)+D)/8192 ((A*256)+B)*2/65535 ((C*256)+D)*8/65535 ((A*256)+B)*2/65535 ((C*256)+D)*8/65535
01 27 4 01 28 4 01 29 4 01 2A 4 01 2B 4 O2S4_WR_lambda(1): Equivalence Ratio Voltage O2S5_WR_lambda(1): Equivalence Ratio Voltage O2S6_WR_lambda(1): Equivalence Ratio Voltage O2S7_WR_lambda(1): Equivalence Ratio Voltage O2S8_WR_lambda(1): Equivalence Ratio Voltage 0 0 0 0 0 0 0 0 0 0 2 8 2 8 2 8 2 8 2 8 N/A V N/A V N/A V N/A V N/A V 01 2C 1 Commanded EGR 0 100 % 100*A/255 ((A*256)+B)*2/65535 ((C*256)+D)*8/65535 ((A*256)+B)*2/65535 ((C*256)+D)*8/65535 ((A*256)+B)*2/65535 ((C*256)+D)*8/65535 ((A*256)+B)*2/65535 ((C*256)+D)*8/65535 ((A*256)+B)*2/65535 ((C*256)+D)*8/65535 01 2D 1 EGR Error -100 99.22 % (A-128) * 100/128 01 2E 1 Commanded evaporative purge 0 100 % 100*A/255 01 2F 1 Fuel Level Input 0 100 % 100*A/255 01 30 1 01 31 2 01 32 2 # of warm-ups since codes cleared Distance traveled since codes cleared Evap. System Vapor Pressure 0 255 N/A A 0 65,535 km (A*256)+B -8,192 8,192 Pa 01 33 1 Barometric pressure 0 255 01 34 4 01 35 4 01 36 4 01 37 4 O2S1_WR_lambda(1): Equivalence Ratio Current O2S2_WR_lambda(1): Equivalence Ratio Current O2S3_WR_lambda(1): Equivalence Ratio Current O2S4_WR_lambda(1): Equivalence Ratio Current 0-128 0-128 0-128 0-128 1.999 127.99 2 128 2 128 2 128 32 kpa (Absolute) A N/A ma N/A ma N/A ma N/A ma ((A*256)+B)/4 (A is signed) ((A*256)+B)/32,768 ((C*256)+D)/256-128 ((A*256)+B)/32,768 ((C*256)+D)/256-128 ((A*256)+B)/32768 ((C*256)+D)/256-128 ((A*256)+B)/32,768 ((C*256)+D)/256-128
01 38 4 01 39 4 01 3A 4 01 3B 4 01 3C 2 01 3D 2 O2S5_WR_lambda(1): Equivalence Ratio Current O2S6_WR_lambda(1): Equivalence Ratio Current O2S7_WR_lambda(1): Equivalence Ratio Current O2S8_WR_lambda(1): Equivalence Ratio Current Catalyst Temperature Bank 1, Sensor 1 0-128 0-128 0-128 0-128 2 128 2 128 2 128 2 128 N/A ma N/A ma N/A ma N/A ma ((A*256)+B)/32,768 ((C*256)+D)/256-128 ((A*256)+B)/32,768 ((C*256)+D)/256-128 ((A*256)+B)/32,768 ((C*256)+D)/256-128 ((A*256)+B)/32,768 ((C*256)+D)/256-128 -40 6,513.5 C ((A*256)+B)/10-40 Catalyst Temperature Bank 2, Sensor 1-40 6,513.5 C ((A*256)+B)/10-40 01 3E 2 01 3F 2 01 40 4 01 41 4 Catalyst Temperature Bank 1, Sensor 2 Catalyst Temperature Bank 2, Sensor 2 PIDs supported [41-60] Monitor status this drive cycle -40 6,513.5 C ((A*256)+B)/10-40 -40 6,513.5 C ((A*256)+B)/10-40 Bit encoded [A7..D0] == [PID 0x41..PID 0x60] See below. Bit encoded. See below. 01 42 2 Control module voltage 0 65.535 V ((A*256)+B)/1000 01 43 2 Absolute load value 0 25,700 % ((A*256)+B)*100/255 01 44 2 01 45 1 01 46 1 01 47 1 01 48 1 Command equivalence ratio Relative throttle position Ambient air temperature Absolute throttle position B Absolute throttle position C 0 2 N/A ((A*256)+B)/32768 0 100 % A*100/255-40 215 C A-40 0 100 % A*100/255 0 100 % A*100/255 33
01 49 1 Accelerator pedal position D 0 100 % A*100/255 01 4A 1 01 4B 1 01 4C 1 Accelerator pedal position E Accelerator pedal position F Commanded throttle actuator 0 100 % A*100/255 0 100 % A*100/255 0 100 % A*100/255 01 4D 2 Time run with MIL on 0 65,535 minutes (A*256)+B 01 4E 2 01 4F 4 01 50 4 Time since trouble codes cleared 01 51 1 Fuel Type Maximum value for equivalence ratio, oxygen sensor voltage, oxygen sensor current, and intake manifold absolute pressure Maximum value for air flow rate from mass air flow sensor 0 65,535 minutes (A*256)+B 0, 0, 0, 0 255, 255, 255, 2550 0 2550 g/s, V, ma, kpa A, B, C, D*10 A*10, B, C, and D are reserved for future use 01 52 1 Ethanol fuel % 0 100 % A*100/255 01 53 2 01 54 2 01 55 2 01 56 2 01 57 2 01 58 2 Absolute Evap system Vapor Pressure Evap system vapor pressure Short term secondary oxygen sensor trim bank 1 and bank 3 Long term secondary oxygen sensor trim bank 1 and bank 3 Short term secondary oxygen sensor trim bank 2 and bank 4 Long term secondary oxygen sensor trim bank 2 and bank 4 From fuel type table see below 0 327.675 kpa 1/200 per bit -32,767 32,768 Pa A*256+B - 32768-100 99.22 % -100 99.22 % -100 99.22 % -100 99.22 % 34 (A-128)*100/128 (B-128)*100/128 (A-128)*100/128 (B-128)*100/128 (A-128)*100/128 (B-128)*100/128 (A-128)*100/128 (B-128)*100/128
01 59 2 01 5A 1 01 5B 1 Fuel rail pressure (absolute) Relative accelerator pedal position Hybrid battery pack remaining life 0 655,350 kpa ((A*256)+B) * 10 0 100 % A*100/255 0 100 % A*100/255 01 5C 1 Engine oil temperature -40 210 C A - 40 01 5D 2 Fuel injection timing -210.00 301.992 (((A*256)+B)-26,880)/128 01 5E 2 Engine fuel rate 0 3212.75 L/h ((A*256)+B)*0.05 01 5F 1 01 60 4 01 61 1 01 62 1 Emission requirements to which vehicle is designed PIDs supported [61-80] Driver's demand engine - percent torque Actual engine - percent torque Bit Encoded -125 125 % A-125-125 125 % A-125 01 63 2 Engine reference torque 0 65,535 Nm A*256+B 01 64 5 Engine percent torque data -125 125 % Bit encoded [A7..D0] == [PID 0x61..PID 0x80] See below. A-125 Idle B-125 Engine point 1 C-125 Engine point 2 D-125 Engine point 3 E-125 Engine point 4 01 65 2 Auxiliary input / output supported 01 66 5 Mass air flow sensor 01 67 3 01 68 7 01 69 7 01 6A 5 Engine coolant temperature Intake air temperature sensor Commanded EGR and EGR Error Commanded Diesel intake air flow control and relative intake air flow position 35 Bit Encoded
01 6B 5 01 6C 5 01 6D 6 01 6E 5 01 6F 3 Exhaust gas recirculation temperature Commanded throttle actuator control and relative throttle position Fuel pressure control system Injection pressure control system Turbocharger compressor inlet pressure 01 70 9 Boost pressure control 01 71 5 Variable Geometry turbo (VGT) control 01 72 5 Wastegate control 01 73 5 Exhaust pressure 01 74 5 Turbocharger RPM 01 75 7 01 76 7 01 77 5 01 78 9 Turbocharger temperature Turbocharger temperature Charge air cooler temperature (CACT) Exhaust Gas temperature (EGT) Bank 1 Special PID. See below. 01 79 9 01 7A 7 01 7B 7 01 7C 9 Exhaust Gas temperature (EGT) Bank 2 Diesel particulate filter (DPF) Diesel particulate filter (DPF) Diesel Particulate filter (DPF) temperature Special PID. See below. 36
01 7D 1 NOx NTE control area status 01 7E 1 PM NTE control area status 01 7F 13 Engine run time 01 80 4 01 81 21 01 82 21 PIDs supported [81 - A0] Engine run time for AECD Engine run time for AECD 01 83 5 NOx sensor 01 84 Manifold surface temperature 01 85 NOx reagent system 01 86 01 87 01 A0 4 01 C0 4 Particulate matter (PM) sensor Intake manifold absolute pressure PIDs supported [A1 - C0] PIDs supported [C1 - E0] 01 C3????? 01 C4????? 02 02 2 Freeze frame trouble code 03 N/A n*6 Request trouble codes 04 N/A 0 Clear trouble codes / Malfunction indicator lamp (MIL) / Check engine light 37 Bit encoded [A7..D0] == [PID 0x81..PID 0xA0] See below. Bit encoded [A7..D0] == [PID 0xA1..PID 0xC0] See below. Bit encoded [A7..D0] == [PID 0xC1..PID 0xE0] See below. Returns numerous data, including Drive Condition ID and Engine Speed* B5 is Engine Idle Request B6 is Engine Stop Request* BCD encoded, See below. 3 codes per message frame, BCD encoded. See below. Clears all stored trouble codes and turns the MIL off.
05 0100 05 0101 05 0102 05 0103 05 0104 05 0105 05 0106 05 0107 05 0108 05 0109 05 010A 05 010B 05 010C 05 010D 05 010E 05 010F OBD Monitor IDs supported ($01 $20) O2 Sensor Monitor Bank 1 Sensor 1 O2 Sensor Monitor Bank 1 Sensor 2 O2 Sensor Monitor Bank 1 Sensor 3 O2 Sensor Monitor Bank 1 Sensor 4 O2 Sensor Monitor Bank 2 Sensor 1 O2 Sensor Monitor Bank 2 Sensor 2 O2 Sensor Monitor Bank 2 Sensor 3 O2 Sensor Monitor Bank 2 Sensor 4 O2 Sensor Monitor Bank 3 Sensor 1 O2 Sensor Monitor Bank 3 Sensor 2 O2 Sensor Monitor Bank 3 Sensor 3 O2 Sensor Monitor Bank 3 Sensor 4 O2 Sensor Monitor Bank 4 Sensor 1 O2 Sensor Monitor Bank 4 Sensor 2 O2 Sensor Monitor Bank 4 Sensor 3 05 0110 O2 Sensor Monitor Bank 4 Sensor 4 05 0201 05 0202 O2 Sensor Monitor Bank 1 Sensor 1 0.00 1.275 Volts 0.00 1.275 Volts 0.00 1.275 Volts 0.00 1.275 Volts 0.00 1.275 Volts 0.00 1.275 Volts 0.00 1.275 Volts 0.00 1.275 Volts 0.00 1.275 Volts 0.00 1.275 Volts 0.00 1.275 Volts 0.00 1.275 Volts 0.00 1.275 Volts 0.00 1.275 Volts 0.00 1.275 Volts 0.005 Rich to lean sensor threshold voltage 0.005 Rich to lean sensor threshold voltage 0.005 Rich to lean sensor threshold voltage 0.005 Rich to lean sensor threshold voltage 0.005 Rich to lean sensor threshold voltage 0.005 Rich to lean sensor threshold voltage 0.005 Rich to lean sensor threshold voltage 0.005 Rich to lean sensor threshold voltage 0.005 Rich to lean sensor threshold voltage 0.005 Rich to lean sensor threshold voltage 0.005 Rich to lean sensor threshold voltage 0.005 Rich to lean sensor threshold voltage 0.005 Rich to lean sensor threshold voltage 0.005 Rich to lean sensor threshold voltage 0.005 Rich to lean sensor threshold voltage 0.00 1.275 Volts 0.005 Rich to lean sensor threshold voltage 0.00 1.275 Volts O2 Sensor Monitor Bank 1 Sensor 2 0.00 1.275 Volts 38 0.005 Lean to Rich sensor threshold voltage 0.005 Lean to Rich sensor threshold voltage
05 0203 O2 Sensor Monitor Bank 1 Sensor 3 0.00 1.275 Volts 0.005 Lean to Rich sensor threshold voltage 05 0204 O2 Sensor Monitor Bank 1 Sensor 4 0.00 1.275 Volts 0.005 Lean to Rich sensor threshold voltage 05 0205 O2 Sensor Monitor Bank 2 Sensor 1 0.00 1.275 Volts 0.005 Lean to Rich sensor threshold voltage 05 0206 O2 Sensor Monitor Bank 2 Sensor 2 0.00 1.275 Volts 0.005 Lean to Rich sensor threshold voltage 05 0207 O2 Sensor Monitor Bank 2 Sensor 3 0.00 1.275 Volts 0.005 Lean to Rich sensor threshold voltage 05 0208 O2 Sensor Monitor Bank 2 Sensor 4 0.00 1.275 Volts 0.005 Lean to Rich sensor threshold voltage 05 0209 O2 Sensor Monitor Bank 3 Sensor 1 0.00 1.275 Volts 0.005 Lean to Rich sensor threshold voltage 05 020A O2 Sensor Monitor Bank 3 Sensor 2 0.00 1.275 Volts 0.005 Lean to Rich sensor threshold voltage 05 020B O2 Sensor Monitor Bank 3 Sensor 3 0.00 1.275 Volts 0.005 Lean to Rich sensor threshold voltage 05 020C O2 Sensor Monitor Bank 3 Sensor 4 0.00 1.275 Volts 0.005 Lean to Rich sensor threshold voltage 05 020D O2 Sensor Monitor Bank 4 Sensor 1 0.00 1.275 Volts 0.005 Lean to Rich sensor threshold voltage 05 020E O2 Sensor Monitor Bank 4 Sensor 2 0.00 1.275 Volts 0.005 Lean to Rich sensor threshold voltage 05 020F O2 Sensor Monitor Bank 4 Sensor 3 0.00 1.275 Volts 0.005 Lean to Rich sensor threshold voltage 05 0210 O2 Sensor Monitor Bank 4 Sensor 4 0.00 1.275 Volts 0.005 Lean to Rich sensor threshold voltage 09 00 4 mode 9 supported PIDs 01 to 20 Bit encoded 09 01 1x5 VIN Message Count in command 09 02 Returns 1 line/packet (49 01 05 00 00 00 00), where 05 means 05 packets will be returned in VIN digits. 09 02 5x5 Vehicle identification number (VIN) 39 Returns the VIN as a multiframe response using the ISO 15765-2 protocol. This is typically five frames, with the first frame encoding the size and count.
09 04 varies calibration ID 09 06 4 calibration Returns multiple lines, ASCII coded In the formula column, letters A, B, C, etc. represent the decimal equivalent of the first, second, third, etc. bytes of data. Where a (?) appears, contradictory or incomplete information was available. Someone with a copy of the 2006 SAE HS-3000 should fact-check these. Bitwise encoded PIDs Some of the PIDs in the above table cannot be explained with a simple formula. A more elaborate explanation of these data is provided here: Mode 1 PID 00: A request for this PID returns 4 bytes of data. The four bytes are giving information about which of the next 32 PIDs are supported. The response can be decoded like this: If the car response is BE 1F A8 13, then transform that in binary. B E 1 F A 8 1 3 ---- ---- ---- ---- ---- ---- ---- ---------- supported? 1011 1110 0001 1111 1010 1000 0001 0 0 1 1 PID num 1234 5678............... 29 30 31 32 0 = not supported 1 = supported Mode 1 PID 01: A request for this PID returns 4 bytes of data. The first two bytes are identical for both spark ignition (Gasoline) and compression ignition (Diesel) engines. The third and fourth bytes are to be interpreted differently depending on if the engine is spark ignition or compression ignition. In the second (B) byte, bit 3 tells you which way to interpret the C and D bytes, with 0 being spark and 1 (set) being compression. The first byte contains two pieces of information. Bit A7 (the eighth bit of byte A, the first byte) indicates whether or not the MIL (check engine light) is illuminated. Bits A0 through A6 represent the number of diagnostic trouble codes currently flagged in the ECU. The second, third, and fourth bytes give information about the availability and completeness of certain on-board tests. Note that test availability signified by set (1) bit; completeness signified by reset (0) bit: Bit Name Definition A0-A6 DTC_CNT Number of confirmed emissions-related DTCs available for display. A7 MIL Off or On, indicates if the CEL/MIL is on (or should be on) B3 B7 NO NAME 0 = Spark ignition monitors supported 1 = Compression ignition monitors supported RESERVED RESERVED Here are the common bit B definitions, they're test based. 40
Test available Test incomplete Misfire B0 B4 Fuel System B1 B5 Components B2 B6 The byte C and D spark ignition monitors: Test available Test incomplete Catalyst C0 D0 Heated Catalyst C1 D1 Evaporative System C2 D2 Secondary Air System C3 D3 A/C Refrigerant C4 D4 Oxygen Sensor C5 D5 Oxygen Sensor Heater C6 D6 EGR System C7 D7 And the byte C and D compression ignition monitors: Test available Test incomplete NMHC Cat C0 D0 NOx/SCR Monitor C1 D1 Boost Pressure C3 D3 Exhaust Gas Sensor C5 D5 PM filter monitoring C6 D6 EGR and/or VVT System C7 D7 NMHC *may* stand for non-methane hydrocarbons catalyst, but J1979 does not enlighten us. Mode 1 PID 03: A request for this PID returns 2 bytes of data. The first byte describes fuel system #1. Only one bit should ever be set. A0 Open loop due to insufficient engine temperature A1 Closed loop, using oxygen sensor feedback to determine fuel mix A2 Open loop due to engine load OR fuel cut due to deceleration A3 Open loop due to system failure A4 Closed loop, using at least one oxygen sensor but there is a fault in the feedback system A5-A7 Always zero The second byte describes fuel system #2 (if it exists) and is encoded identically to the first byte. Mode 1 PID 12: A request for this PID returns a single byte of data which describes the secondary air status. Only one bit should ever be set. A0 Upstream of catalytic converter A1 Downstream of catalytic converter A2 From the outside atmosphere or off A3-A7 Always zero Mode 1 PID 1C: A request for this PID returns a single byte of data which describes which OBD standards this ECU was designed to comply with. The hexadecimal and binary representations of the data byte are shown below 41 next to what it implies:
0x01 00000001b 0x02 00000010b 0x03 00000011b 0x04 00000100b 0x05 00000101b 0x06 00000110b 0x07 00000111b 0x08 00001000b 0x09 00001001b 0x0A 00001010b 0x0B 00001011b 0x0C 00001100b 0x0D 00001101b OBD-II as defined by the CARB OBD as defined by the EPA OBD and OBD-II OBD-I Not meant to comply with any OBD standard EOBD (Europe) EOBD and OBD-II EOBD and OBD EOBD, OBD and OBD II JOBD (Japan) JOBD and OBD II JOBD and EOBD JOBD, EOBD, and OBD II Mode 1 PID 41: A request for this PID returns 4 bytes of data. The first byte is always zero. The second, third, and fourth bytes give information about the availability and completeness of certain on-board tests. Note that test availability signified by set (1) bit; completeness signified by reset (0) bit: Test enabled Test incomplete Misfire B0 B4 Fuel System B1 B5 Components B2 B6 Reserved B3 B7 Catalyst C0 D0 Heated Catalyst C1 D1 Evaporative System C2 D2 Secondary Air System C3 D3 A/C Refrigerant C4 D4 Oxygen Sensor C5 D5 Oxygen Sensor Heater C6 D6 EGR System C7 D7 Mode 3: (no PID required) A request for this mode returns a list of the DTCs that have been set. The list is encapsulated using the ISO 15765-2 protocol. If there are two or fewer DTC's (4 bytes) they are returned in an ISO-TP Single Frame (SF). Three or more DTCs in the list are reported in multiple frames, with the exact count of frames dependent on the communication type and addressing details. Each trouble code requires 2 bytes to describe. The text description of a trouble code may be decoded as follows. The first character in the trouble code is determined by the first two bits in the first byte: A7 A6 First DTC character -- -- ------------------- 0 0 P - Powertrain 0 1 C - Chassis 1 0 B - Body 1 1 U - Network The four following digits are BCD encoded. The second character in the DTC is a number defined by A5 A4 Second DTC character 42
-- -- -------------------- 0 0 0 0 1 1 1 0 2 1 1 3 The third character in the DTC is a number defined by A3 A2 A1 A0 Third DTC character -- -- -- -- ------------------- 0 0 0 0 0 0 0 0 1 1 0 0 1 0 2 0 0 1 1 3 0 1 0 0 4 0 1 0 1 5 0 1 1 0 6 0 1 1 1 7 1 0 0 0 8 1 0 0 1 9 1 0 1 0 A 1 0 1 1 B 1 1 0 0 C 1 1 0 1 D 1 1 1 0 E 1 1 1 1 F The fourth and fifth characters are defined in the same way as the third, but using bits B7..B4 and B3..B0. The resulting five-character code should look something like "U0158" and can be looked up in a table of OBD-II DTCs. Hexadecimal characters (0-9,A-F), while relatively rare, are allowed in the last 3 positions of the code itself. Fuel Type Coding Mode 1 PID 0x51 returns a value from an enumerated list giving the fuel type of the vehicle. The fuel type is returned as a single byte, and the value is given by 01 Gasoline 02 Methanol 03 Ethanol 04 Diesel 05 LPG 06 CNG 07 Propane 08 Electric 09 Bifuel running Gasoline 0A Bifuel running Methanol 0B Bifuel running Ethanol 0C Bifuel running LPG 0D Bifuel running CNG 0E Bifuel running Prop 0F Bifuel running Electricity 10 Bifuel mixed gas/electric 11 Hybrid gasoline 12 Hybrid Ethanol 13 Hybrid Diesel 14 Hybrid Electric 15 Hybrid Mixed fuel 16 Hybrid Regenerative 43
Special PIDs Some PIDs are to be interpreted specially, and aren't necessarily exactly "bitwise encoded" Mode 1 PID 78 A request for this PID will return 9 bytes of data. The first byte is a bit encoded field indicating which sensors are supported: EGT11 EGT12 EGT13 EGT14 Reserved Reserved Reserved Reserved Sensor Supported A0 A1 A2 A3 A4 A5 A6 A7 The remaining bytes are 16 bit integers indicating the temperature in Degrees celsius in the range -40 to 6513.5 (scale 0.1) using the usual ((A*256)+B)-40 formula. Mode 1 PID 79 A request for this PID will return 9 bytes of data. See Mode 1 PID 78 (above) for a description. 44
45 APPENDIX B WIRING DIAGRAMS BOOK
46
47
48
49
50
51
52
53
54 APPENDIX C SELF TESTS REPORTED BY THE 01 01 PID
55 Test available Test incomplete Misfire b0 b4 Fuel System b1 b5 Components b2 b6 Table C.1: b-bit definition of monitoring tests Test available Test incomplete Catalyst c0 d0 Heated Catalyst c1 d1 Evaporative System c2 d2 Secondary Air System c3 d3 A/C Refrigerant c4 d4 Oxygen Sensor c5 d5 Oxygen Sensor Heater c6 d6 EGR System c7 d7 Table C.2: c and d bit definition for spark ignition engines
56 Test available Test incomplete NMHC Cat c0 d0 NOx/SCR Monitor c1 d1 Boost Pressure c3 d3 Exhaust Gas Sensor c5 d5 PM filter monitoring c6 d6 EGR and/or VVT System c7 d7 Table C.3: c and d bit definition for compression ignition engines
57 APPENDIX D EXAMPLE APPLICATION FROM ELM329 S DATASHEET
Figure D.1: Circuit of the ELM329-based scan tool 58
Figure D.2: Components used on the circuit on figure D.1 59
60 BIBLIOGRAPHY [1] Checkoway, Stephen, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham, Stefan Savage, Karl Koscher, Alexei Czeskis, Franziska Roesner, and Tadayoshi Kohno. Comprehensive experimental analyses of automotive attack surfaces. Proceedings of the 20th USENIX conference on Security, Berkeley, CA, USA. 2011. 6 6. [2] Drolia, U., Zhenyan Wang, S. Vemuri, M. Behl, and R. Mangharam. Demo abstract: AutoPlug - An automotive test-bed for ECU testing, validation and verification. Information Processing in Sensor Networks (IPSN), 2011 10th International Conference on.. april 2011. 131 132. [3] Guo, Huaqun, Lek Heng Ngoh, Yongdong Wu, Lian Hwa Liow, Choon Hwee Kwek, Feng Tao, and Jun Jie Ang. Embedded info-security solutions for vehicular networks. Communications and Networking in China, 2008. ChinaCom 2008. Third International Conference on.. aug. 2008. 29 33. [4] ISO Road vehicles diagnostic communication over controller area network (docan) ISO 15765-4:2011 International Organization for Standardization 2011. [5] Koscher, Karl, Alexei Czeskis, Franziska Roesner, Shwetak Patel, Tadayoshi Kohno, Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham, and Stefan Savage. Experimental Security Analysis of a Modern Automobile. Security and Privacy (SP), 2010 IEEE Symposium on.. may 2010. 447 462. [6] Rouf, I., R. Miller, H. Mustafa, T. Taylor, S. Oh, W. Xu, M. Gruteser, W. Trappe, and I. Seskar. Security and privacy vulnerabilities of in-car wireless networks: A tire pressure monitoring system case study. Proceedings of USENIX Security Symposium (2010).