If you're in Amsterdam March 14th stop by Black Hat Europe and check out my 5+ hour Workshop:
Or if you are in San Jose April 23rd, stop by Design West and check out my one hour talk on Vehilce Network Denial of Service.
I will be doing a quick 1 hour presentation at this year’s HOPE (Hackers On Planet Earth) conference at the Hotel Pennsylvania in New York, NY July 13-15 (http://www.hopenumbernine.net). The title will be “Exploited from Detroit.” I plan to talk about how to get started in Reverse Engineering vehicle network data and give some particle examples of this data. Because its only one hour, it will be short and to the point. I will be fielding questions and if anyone wants to volunteer a vehicle we may even be able to find time to connect to a car and have a real world demonstration.
More details to come as they are released.
Just got the time and Date for
“Exploited from Detroit” "How to Communicate with Your Car’s Network"
Day/Time: Friday, July 13, 2012 - 2200
Location: Sassaman (18th floor)
Some services are boring.. like really, really, really, boring.. but others can make the car move gauges or make the car’s warning lights light up. Here is a bit more about these types of services.
Stop Normal Communications (GMLAN and Others):
This service is fun because you can make the Normal Communications (the ECU to ECU communications that occurs normally on the network) stop. Why would such a service exist, mostly to clear the bus for large amounts of data such as when a controller is going to be reflashed over the CAN Bus. On GMLAN this service is 0x28. It does not require any sub-function so an example of this might be: 0x7E0 01 28 00 00 00 00 00 00. This will command the engine controller to stop sending normal communications. Of course you don’t ever want to do this while the car is being driven, but it’s pretty fun to see what happens when you do it!
You will see the Engine Controllers Normal messages virtually disappear. I say virtually because not all messages will go away, some that are mission critical will stay, but a lot of them will not.
This service can also be useful if you want to simulate the messages the ECU would send without removing the power to the controller or cutting the CAN Bus itself.
This service requires that you continually send a Tester Present (0x3E) message periodically (2 seconds is good) in order to maintain this. If you want to return the communications send a Return to Normal message (0x20): 0x7E0 01 20 00 00 00 00 00 00. This will restore communications. Or simply stop sending the Tester Present message and it will automatically restore communications after 3 seconds. Oh what fun you’ll have.
Input/Output Control (ISO 14229 – UDS):
This is pretty much the coolest services ever made. I/O Control is exactly as it sounds, you can command Outputs on the Module to do your bidding. Of course software control will limit your bidding to a safe and secure bidding, but it’s still cool.
I/O Control (Service 0x2F) requires 3 parameters: a DID (Data ID), Control Record, and Control Mask. The DID is a two byte ID for the output (or input) you want to modify. Control Record is what you want the output to do (On/Off, Up/Down, etc.). Control Mask is a bitwise mask of one or more parameters that will be modified. An Example of a I/O Control is something like this: 0x7E0 06 2F 11 22 07 01 00 00 00. Where 0x1122 is the DID, 0x07 is the Control Record, and 0x0100 is the mask. This is not a real function, but you could potentially iterate through all possibilities and wait for the controller to give you a positive response. It would take a while, but it’d be interesting to see what happened…. Right!?
It’s likely that you will get a negative response from the controller 0x7E8 03 7F 2F 13 00 00 00 00, where 0x13 is the Negative Response Code (NRC).
Here are a few possible NRCs you may receive:
• 0x13 – Incorrect Message Length or Invalid Format.
• 0x22 – Condition Not Correct.
• 0x31 – Request Out of Range.
• 0x33 – Security Access Denied.
• 0x80-0xFF – OEM Specific.
Good luck……. .. have fun ..
Because diagnostics is really just a simple way to interact with an ECU, there are a few very common diagnostic services that you’ll find in nearly every permutation of diagnostics.
Definitely the most common service you’ll find, tester present (typically 0x3E) is used to let the controller(s) know that there is a.. wait for it.. Tester present. I know it was a bit obvious, but the idea is that some services keep the controller in an augmented state or a diagnostic state. When this happens there needs to be some way of maintaining that state while the tool that initiated the state is still connected to the diagnostic connector.
So Tester Present is designed to be a heart beet of the diagnostic tool and in the event that the device stops working or is disconnected from the network, the ECU whose state has been altered will stop seeing the tester present message and thus transition out of its altered state.
So if you want to maintain a diagnostic state you should send the tester present message. A typical timeout for Tester Present is 3 Seconds. So as long as you send the message between 1 and 2.5 seconds, you will be able to maintain the diagnostic state of a controller.
Read Data by PID:
Reading data from a controller is pretty much the reason for diagnostics in the first place. So there is no surprise that there are at least two ways to accomplish this task on nearly every new vehicle on the market today. Services 0x01 and 0x22 are used for this purpose.
Service 0x01 is the OBDII Read data by PID (Parameter ID) where the PID is a one byte number representing the data you want to read. Service 0x22 is the Enhanced diagnostic method for reading data. Service 0x22 is typically a two byte PID that represent the parameter you want to read. In some cases this two byte parameter may also be used in conjunction with another Enhanced diagnostic service to write the data as well (however exactly how this is done varies).
Controllers contain data that manufactures do not want just anyone having access to. This is typically to stop strange people such as yourself writing data to the controller to modify how it performs. So in nearly every controller there is a method to “unlock” the data. To perform this, it is done with service 0x27, the security access service.
In order to “unlock” the controller you must first ask it for a Seed. This seed will be used in conjunction with a proprietary algorithm to generate a Key. Then the key will be sent back to the controller. If the calculation that the controller did is the same as the key that you sent, then the controller will send a positive response indicating that the controller is now unlocked.
There may be several levels of Security Access. This is due because they may want certain features available to one group of people such as locksmiths who may need to add a new key to the vehicle while still keeping the other levels secure. So a typically Security Access transaction will have sub-functions that will essentially be the level that you wish to access, these sub-functions operation in Odd/Even Pairs. So sub-function 0x01 will be the seed request and 0x02 will be the key response. Then it’s 0x03/0x04, 0x05/0x06, … 0x21/0x22, etc.
That’s pretty much all that is very similar across all of the diagnostic protocols. Once you’ve learned these three services, you find that they very similar.
In diagnostic messaging, services are the functions. Think of each command as a sentence. The service is the verb. In standard OBDII services are often referred to as Modes. You can also think of them as functions to be performed by the controller(s) that you are commanding.
With diagnostic messages, there is always a command and almost always a response from the controller(s) you are commanding.
When looking at raw CAN Bus data the service is often the second, third, or in very few cases the fourth data byte of the message. In nearly all cases, OEMs will implement ISO 15765-2 (Click Here to read about this protocol). So the service will be the first byte after the Transport Protocol information.
Here is an example of and OBDII message to get Engine Speed using the CAN Bus ($01 is the Service):
$7DF 02 01 0D 00 00 00 00 00
Will hopefully return the following:
$7E8 04 41 0D 01 FE 00 00 00
Here is a simple list of some common Services that you might find:
OBDII Services (a.k.a. Modes):
$01 - Request Current Powertrain Diagnostic Data
$02 - Request Powertrain Freeze Frame Data
$03 - Request Emission-Related Diagnostic Trouble Codes
$04 - Clear/Reset Emission-Related Diagnostic Information
$05 - Request Oxygen Sensor Monitoring Test Results
$06 - Request On-Board Monitoring Test Results for Specific Monitored Systems
$07 - Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving Cycle
$08 - Request Control of On-Board System, Test or Component
$09 - Request Vehicle Information
$0A - Request Emission-Related Diagnostic Trouble Codes with Permanent Status
Services $10 and higher are non-OBDII services also known as Enhanced Diagnostics. This is because, unlike OBDII Diagnostics, these services are not government mandated thus each OEM will use their own specification. For Example GM vehicles use the GMLAN diagnostic protocol. Ford used ISO-14230 but now use ISO-14229 (UDS). Each OEM is can decidedly use their own enhanced diagnostic protocol.
GMLAN Enhanced Services:
$10 - Initiate Diagnostics
$12 - Read Failure Record
$1A - Read Diagnostic ID (DID)
$20 - Return To Normal
$22 - Read Data By Parameter ID (PID)
$23 - Read Memory Address
$27 - Security Access
$28 - Disable Normal Communications
$2C - Define Dynamic Data Packet ID (DPID)
$2D - Define PID by Memory Address
$34 - Request Download
$36 - Transfer Data
$3B - Write DID
$3E - Tester Present
$A2 - Report Programming State
$A5 - Enter Programming Mode
$A9 - Check Codes
$AA - Read DPID
$AE - Device Control
Here is an example of a CAN Bus message to get the Engine Speed using Enhanced Diagnostics (where $22 is the service):
$7E0 03 22 00 0D 00 00 00 00
And this will hopefully return:
$7E8 04 62 00 0D 01 7E 00 00
ISO - 14229:
$10 - Diagnostic Session Control
$11 - ECU Reset
$14 - Clear Diagnostic Information
$19 - Read Diagnostic Trouble Codes (DTC)
$22 - Read Data by ID
$23 - Read Memory by Address
$24 - Read Scaling Data by ID
$27 - Security Access
$28 - Communications Control
$2A - Read Data by Periodic ID
$2C - Dynamically Define Data ID
$2E - Write Data by ID
$2F - Input/Output Control
$31 - Routine Control
$34 - Request Download
$35 - Request Upload
$36 - Transfer Data
$37 - Request Transfer Exit
$3D - Write Memory by Address
$3E - Tester Present
$83 - Access Timing Parameter
$84 - Secured Data Transmission
$85 - Control DTC Setting
$86 - Response on Event
$87 - Link Control
Now that you have a list of Services, hopefully this will make reading the raw can data a bit more manageable. Soon I will post more information about specific services themselves. If any are more interesting to you, please post in the comments below.
This year's Defcon will host yours truely. I will be giving a workshop on CAN BUS Hacking. So if you have some time come out and join us at Defcon August 4~7 @ the Rio Hotel in Las Vegas, NV.
Please check out www.defcon.org for more information about what days the workshops will be held.
Here is a preliminary example of what will be:
* What is Vehicle Network Communications (Demo)
* Compare Vehicle Comms vs. Ethernet
* Compare Vehicle Comms vs. TCP/IP
* Types of Vehicle Network Physical Layers
* J1850 PWM/VPW
* LIN/ISO 9141
* CAN Bus
* LSFT CAN
* DW CAN
* Devices Used to Connect to CAN BUS
* Arduino (Demo)
* neoVI/ValueCAN (Demo)
* Generic ELM Tool
* DW CAN Bus Physical Network (Wires and Resistive Properties)
* CAN BUS Data Frame
* IPC or other Controller (Demo)
* Understanding the data on the Bus: Diagnostic Message vs. Normal Messages
* Reverse Engineering Normal Messages (Demo)
* Diagnostic Protocols
* ISO 14239
* ISO 14229
* Commanding the Vehicle Controllers using CAN BUS
* Understanding Security Systems
* Controller Security Access (Possible Demo)
* Immobilizers (Possible Demo)
* The autoAPIa Project
Workshops schedule has been released go to https://www.defcon.org/html/defcon-19/dc-19-workshops.html#Leale for more information about the workshops. The cost is $200 (Cash only) and it will take place starting at 10:00 AM on Friday, August 5th. I am not sure yet if it is first-come-first-serve or not. I will update when I find out.
Thank everyone for coming out to the DefCon workshop, had many more people that I thought could make it. It was a wonderful success. As promissed here are the links for the workshop's powerpoint: http://www.canbushack.com/defcon19/workshop.pptx
Every CAN message has an Identifier. This is referred to as the Arbitration ID or ArbID. It serves two functions. First, it is to help identify the payload or data of the frame. Second, because no two modules are allowed to send a frame with the same ID, it serves as an arbitration method on which frame gets priority on the bus when two or more messages are sent at the SAME TIME (in other words if a low priority ArbID frame is half-way through sending, a higher priority ArbID will not stop that frame from sending).
So if the ArbID is the identifier of the message, what are Extended IDs? The concept is simple, take the ArbID and add data bytes from the frame as the ID as well. For instance, say you have to messages you want to send: Engine Speed and Engine Coolant Temp. A lot of the time you will see them sent in the same message with the same ID and always in their same respective location in that message. However what if you wanted all of your parameters to occupy byte 5 of every frame, and instead you change out the ID to denote the parameter, but because of application rules you are only allowed to broadcast on a single ID? In this case you would use Extended IDs.
For example your only ID you are allowed to send is ID 0x444 (again this is because of rules imposed by a network design committee not by CAN Bus itself). And you have more data than one frame can possibly hold or you want all of your parameters to be in the 5th byte? In this case you may set byte 1 as your Extended ID and for each parameter you would assign a new ID. So Engine Speed would be 0x0C and Coolant Temp would be 0x05 and Engine Parameter X = 0x06, Y=0x07, etc.
Your Engine Speed Frame would look like this: 0x444 0C 03 00 FF 22 00 00 00 00; where 0x22 Is the engine speed. And for Engine Coolant Temp it may look like this 0x444 05 04 00 FF 10 00 00 00 00; where 0x10 is the Engine Coolant value. So you can see that if you have certain limitations on network IDs, Extended IDs can give you more versatility.
Extended IDs can also be seen in Diagnostics messages as well. For instance Toyota vehicles often use Extended IDs for Diagnostic Requests and Responses. A typical Enhanced Diagnostic Request on Toyota vehicles starts with 0x750 and the first data byte is the Destination Controller Address. Compare this with an OEM that does not use Extended IDs, but rather assigns each ECU Destination address its own Arbitration ID (Ford, GM, Chysler, etc.) The more controllers you have the fewer available Arbitration IDs would be available because they would be taken by Diagnostic Identifiers.
Now you know what some applications are for extended IDs and know that you know, it should be easier for you to identify them when reverse engineering data on the CAN Bus.