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.
With thousands of data parameters flowing continuously along one or more CAN Buses in any particular vehicle, there is no doubt that finding out what these parameters mean can be very benificial, but, in having the data, you can also use it to simulate what is there.
So why would you want to simulate what is ALREADY there? One, because you want to get rid of what is there and add something of your own. Removing the engine and engine controller? No problem just simulate it, the other modules probably wont care. Removing the driver or passenger seat, no problem just simulate it, the other modules probably wont care.
Or two, you want to enhance the functionality of existing controllers. Want the doors to auto-lock at 2mph not 5mph? No problem simulate the lock message, the doors won't mind. Want to have the vehicle chime all the time while the seat belts aren't buckled, no problem simulate the chime.
So how does simulation work? Typically, you will need to look at the message(s) that you want to simulate. What is there Arbitration ID? What is there data length? Is the data static or dynamic? Is it sent periodically, on event, or both? If you send the message and do not remove the original controller that is sending the message are the desired results nullified by the original controller (i.e. if you are sending head lights ON and the original controller is sending head lights OFF, do the headlight turn ON, OFF or flicker?) ?
Once you've answered these questions, then you are ready to begin. So what was the Arbitration ID? Let's say it was 0x555. Ok now what's the data length? 8 bytes with static data, sent periodically at 100ms update rate.
Let's assume this message is a command that moves the driver mirror up when we change the first byte from 0x00 to 0x01. So the message on the Bus looks something like this: 0x555 00 00 00 00 00 00 00 00. But if we send our simulated message of 0x555 01 00 00 00 00 00 00 00 the mirror will move up just a smidge and if we send it at 100ms it will continue to move up until we stop sending or we change the first data byte from 0x01 back to 0x00. However we may notice that the upward movement of the mirror is not as smooth as when I press the up button of the mirror control switch. This is because you are simulating a message that is already present on the CAN Bus. This means that the receiving controller is receiving your message 0x01 and the original controller's message 0x00 and interpreting an Up command when your message arrives and a Stop command when the original controller's message arrives. Depending on how well or bad the software for the mirror control module is written, this may cause havoc on the system you plan to implement, and will most definitely be the source of many CAN Bus Error frames (don't worry there not too bad, in general it is almost impossible to cause any issue when simulating an existing CAN Arbitration ID).
So, in this instants, if we want to make the control as smooth as the original switch, we must stop the existing controller from sending the message. There are a couple of ways to do this, the first is obvious, disconnect or power-down the original controller. Remove a fuse, disconnect the CAN Bus or power from the controller. Now of course this will most definitely have other symptoms, but if your application can tolerate this, then its the easiest and simplest solution.
Next to physically disconnecting the module is using diagnostic messaging to ask the module the stop sending. Often called Disable Normal Communications. If supported, this service will make the module stop sending its data. The problem is that the message format and rules are typically quite different from vehicle manufacture to manufacture, so unless you know what this message is, it is difficult to make this work. Plus this method suffers similar draw-backs as the power-down method mentioned above.
Last, you can gateway the message. Gatewaying the message is done by disconnecting the sending OR receiving module (typically easier when it is the receiver). Once disconnected, you can gateway all of the message to the receiving module EXECPT the one that you want to simulate. This allows you to have complete control over the data in that message while maintaining the messages and data from other modules. As you can imagine this solution requires the most work because you must have a device that is fast, support at least two identical CAN Bus channels, and is quickly programmable. But if you can get these three things together, you will can simulate nearly any message with nearly zero issues.
Well this has been some simulating conversation...
Let me start out with this statement: my OSEK skills are decent, but I’m not the foremost expert here. I will tell you what I know and leave it up to you to belittle me in the comment section. Thank you.
The OSEK standard is a large section of documents that cover many, many aspects of CAN BUS communication, Network Management is a small section of this entire cadre. The entire document can be purchased publicly, I just don’t remember how. The Network Management section (2.5.3; available for free download here) is 130+ pages and is a riveting tale of bits and bytes. So let me tell you about some of the highlights…
OSEK Network Management (NM) primarily works by passing a ‘token’ around a logical ‘ring’. This token is simply like passing a one byte message to your neighbor and then your neighbor passes it to his neighbor and so on until it comes back to you and you start the process all over again. The key here is what does the message token mean? At first the message token just broadcasts your network management ID. For example if your CAN BUS Arbitration ID is 0x420 your NM ID would be 0x20 (the lower byte of your Arb. ID). Each node on the bus would have its own NM message. So if you have five nodes you would have five NM messages all of them within a particular range (this range is specified by the OEM not OSEK).
Once the node has sent out its ID, it starts listening for other NM messages (it knows of other NM messages because these messages will be in a particular range of Arbitration IDs). Once a certain time has elapsed it will send a token to its neighbor. This might look like this: 0x420 21 12 00 00 00 00 00 00 00 00. Where the 0x21 is its neighbor’s ID and 0x12 is the token. Once the neighbor has received his message, he will in turn send his own NM message with his own token: 0x421 26 32 00 00 00 00 00 00. Where 0x26 is the next node ID in the ring and 0x32 is the token. And then the cycle would continue, where each node passed their token to the next node and so on.
The token is encoded data that indicates the node’s desired state for the network. For instant if the network should go to sleep, nodes that wish for sleep will turn on an “enable sleep” bit in the token. If all of the nodes enable this bit, then the final node to elect for sleep will then send the “sleep network” bit and the network will go to sleep. This sleep is only temporary until another message is sent, this will initial a network wakeup and NM messages will start broadcasting with a token that indicates this message is an Initialization message.
So the key to a NM message is how the token is decoded and this is not specified by the OSEK layer but rather by the OEMs themselves.
A legal requirement in most countries, including the U.S., odometer is the measure of the distance your vehicle has traveled. Possibly, this is to aid sellers of the car in appraising the true market value of the vehicle.
Many people have requested if there was a way to modify this value so that they could increase the value of their vehicle correct their miscalculated Odometer and as you can imagine, this is a very difficult task. Similarly I have had request on how to simply read this parameter from the CAN Bus.
First off let me just note that changing or rolling back your odometer is technically not illegal. If you wish you can modify this number without penalty (Don’t listen to me I’m not a lawyer). However when it comes time to sell the vehicle you must properly report the true odometer reading by placing a tag on the inside driver’s door along the side. This is because device that displays the odometer could go bad and could need to be replaced. In some cases, this means that the odometer value is reset back to zero. When this happens the installer will typically add this tag with the old odometer value and legitimize the install.
So how do you modify an existing odometer? The answer depends firmly on the vehicle that you are attempting to use. This means that some vehicles are moderately difficult and others unbelievably impossible. There are a handful of tools available for technician. If your engine is replaced, in some cases you may be able to reset the odometer. So for this event a technician will have a specialized tool designed to connect to the controller or controllers that may store the odometer’s value. This tool, through some secure method, will modify the odometer data that is stored on the controller(s). Of course these tools are difficult to find, cost upwards of $2,000 for one unit, and typically only work for one manufacturer. So they are not very accessible.
So what if you only want to read the odometer from the network? There are a handful of applications that could use the odometer’s value as an input. For instance, automotive insurance companies around the globe would like to create a more equitable method for charging rates. In some cases they can install a data logging device into your vehicle and measure the distance that you typically travel. Like your electrical bill, these devices would allow you to pay for only what you use. In the case if you drive a shorter distance you will pay less than another person who drives more than you. This pay-per-mile or pay-per-kilometer idea could give a particular auto insurance agency a competitive advantage for those who commute less and could prove it.
Sadly odometer is not an OBDII legislated PID. This means the federal government does not require OEMs to have this information available to the general public via vehicle diagnostics. So you if you wanted odometer you would have to find it. Like other similar data, odometer may or may not be available via an enhanced diagnostic command and if it is available its ID and request method is not required to be publicly available. So if you want to find it you’re going to have to roll up your sleeves, get out your CAN Bus Hacking tool and start reverse engineering.
So what are you looking for? If it is available, odometer could be obtained in one or two different ways: Enhanced Diagnostics or Normal Messages (data that is sent without a request). This means we have two vectors (cool buzz word I learned at defcon) (I’m probably using it wrong) that we need to explore.
Getting Odo via Diagnostics:
As stated in some of my previous blog entries, Enhanced Diagnostics is a Command/Response protocol that allows you to “ask” the controllers for data. This is the preferred method as we can control when the data is broadcast on the network simply by asking. So let’s assume we know nothing about how this request is going to look, Enhanced Diagnostics must follow a very specific format for it to be effective. This message format is based on the ISO 15765-2 specification (CANBUSHACK.com: ISO-15765 ). We must also have made a list of command Request IDs (a.k.a. Node IDs) and Response IDs (CANBUSHACK.com: Scan for Diagnostic Data). Once we have the IDs for each node we must now find a list of valid PIDs (Parameter IDs). PIDs are typically a representation of a single parameter for example PID 0x0C in OBDII diagnostics is the Engine Speed data request. So we are looking for the PID that belongs to Odometer…
So let’s take a big step back and narrow down the list of possible Services that may be used to request a parameter like odometer. This list is essentially vehicle specific and is not necessarily published anywhere so you will have to have some experience with this to narrow the list. If you don’t then your effort will take a bit more time, but it isn’t impossible. Typically PIDs are requested using the following services: 0x1A, 0x22, and 0x21. Now it’s important to know one thing before we continue: what is the PID size (in bytes) that the controller is expecting. This is typically one or two bytes. For example service 0x1A on GMLAN requires the PID (actually they call it a DID) to be 1 byte in length whereas, the service 0x22 on GMLAN requires two byte PIDs.
Now that we have a small list of possible services, let’s start with them (Tip: Services are essentially functions that you are requesting the controller to perform). Let’s assume that we have a controller that has a Diagnostic Request ID of 0x734 and a response ID of 0x744, I want to send 0x734 03 1A 01 00 00 00 00 00 to the controller. Translation: Function 0x1A, PID 0x01. Now we are hoping for the following positive response from the controller: 0x744 06 5A 01 00 02 03 04 00 where the 0x5A is the positive response to our 0x1A request (Recall: Service ID plus 0x40 = positive response) and 0x06 lets us know that the data coming back is going to be 4 bytes (why not 6? Because 0x06 includes the service ID response and the PID Echo). 4 bytes is very promising when looking for odometer because chances are we will need this size to be large enough to store all potential values of odometer including possibly scaling it to the 10ths or 100ths of a Mile or Kilometer. 0x01 is the PID that we requested and 0x00020304 is the four byte response data we received.
Odds are that odometer will likely be stored in a large number of bytes because typically the odometer will need to be an overly large number just in case. 4 bytes = 8 bits * 4 = 32 bits; Upper Limit is 2^32 = 4,294,967,296. Why so big? I don’t know, maybe it’s scaled so the upper limit will be smaller.. But in this case if we rescaled 4,294,967,296 to X/100, this would allow us more granularity of the odometer value itself. Now let’s look at our vehicle’s odometer value on the dash display. We’ll assume it reads 824 Miles. The first thing we that must do is change this value to Kilometers. The metric system is an absolute when dealing with data on the CAN Bus (mostly :). So this is approximately 1,318.4 KM. Now let’s convert the data we got back from our controller from hexadecimal to decimal. 0x00020304 = 131,844. So now we simply take the observed data from the CAN Bus and see if there is some correlation to what we saw on the dash and of course we can see this one is quite easily: 131,844/100 = 1,318.4 KM. Now we must hope this isn’t some strange, strange coincidence and we’ll mark this one down in our book as solved. If we have a chance to validate this on another vehicle this may be ideal.
But what would happen if the controller didn’t send a positive response? Nearly 90% of the time the controller is going to say that you have requested a non-existent PID these responses can take many forms but they will always have 0x7F in the second data byte. A typical negative response would look like this 0x744 03 7F 1A 30 00 00 00 00. This follows the ISO 15765 protocol for negative responses and in this example 0x30 is the NRC (negative response code). This code is a clue as to why the data was rejected. Be careful, because sometimes the NRC may be telling to send another message before you request a PID and NOT that you have a bad PID. So pay close attention to the NRC and again take a look at my ISO 15765 post to view a list of NRCs.
Now that we have the Odometer we should be able to read it any time we want. This allows us full control of when we get the data, but there is a possibility that we won’t be able to find it using this method. We may want to find a factory scan tool (not an easy task at all!) and see if it can request odometer from the vehicle. If it can, then we need only monitor the request and simulated it by connecting our CAN Bus tool at the same time as the scan tool (OBDII Y-splitter is recommended, obdiicables.com).
Getting Odo via Normal Messages:
Like in our previous example, we are going to be looking for a parameter; the difference is we are essentially looking for a needle in a needle stack. The needle is the odometer and the stack is a lot of other data parameters that are being broadcast by a handful of controllers.
So let’s take a second to figure out how we might narrow the list of possible candidates. First, since we are probably in a stationary car, the data should not be changing. So filter out any changing data. Second, the data should be a non-zero value about two to four bytes in length. Third, the data will have to have some type of correlation with odometer value that we see on the dash. The smaller the width (in bytes) of the odometer parameter that we find the more likely that there is some type of scalar associated with it. These scalars may be something like: x/10 or even x*10 or more likely x*2^y (where y could is typically between -4 and 4) or simply x*1. Try to run each possible hit through each possible scalar; this should yield the best results.
In short, odometer is an elusive parameter to find, but with some perseverance you can find it… but then again who cares right?
----------------- ------------- ---------------- --------------
On a side note, if you do find odometer on a vehicle, please post.