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.
Ask an “expert.” No seriously, an expert. If you have a CAN Bus Hack related question and you want to share your incompetence to the rest of my readers, please feel free to post your questions. If you don’t want anyone to know that you don’t know what you think you would like to know. Then give shoot me an email by clicking on the “Contact” link on the title bar of canbushack.com.
Most vehicles employ some sort of network management. This is typically for the Low Speed or Body Network. The High Speed or Powertrain network will come alive when the key is in the start position. But if you need to send an unlock command using your key fob and this is done via a CAN Bus, then there will need to be a network management system to wakeup nodes and allow them to go back to sleep.
The problem is that there are sooooo many ways of accomplishing this task. There is GMLAN, OSEK, and many others. In general they may have nothing to do with each other, you will just have to learn them all! So here is a start:
GMLAN Network Management:
GM uses network management on their Single Wire or Low Speed network in order to wake up nodes that are in a low-current or sleep mode. There are essentially two events that must take place to communicate with a sleeping node.
First you must wake it up by sending a High Voltage Wake-Up. On single wire CAN the physical layer is typically an active high, 0-5V line. This means that if you were to watch normal traffic on an oscilloscope, you would see 0 Volts for low values and 5 Volts for high values; but when a node is sending a high voltage wake-up now the high values will be at 12 volts (rather Vbatt which may be as low as 9 Volts or as High as 16 Volts). Although it doesn’t matter what format this message is, it is typically the message with Arbitration ID 0x100 and has NO data. This lets the sleeping nodes know that they need to wake-up. An awake node may or may not be listening to command information just yet. Most nodes require another “Wake-Up” to send data to them.
Second you must send the Virtual Network Management Frame (VNMF). This message is designed to wake-up particular virtual networks or groups of nodes that are associated through common systems such as lighting control or entry systems (i.e. doors). So if I wanted to talk to door module to unlock the doors I would wake up the virtual network for doors. The problem is of course, I have no way of knowing the networks without a proprietary list which I don’t have. So instead of worrying about which virtual network to wake-up I will show you how to wake them ALL up. To wake up ALL virtual network it’s as simple as sending the following message: 0x621 01 FF FF FF FF 00 00 00.
So why does this work? ALL VNMFs have a range of 11 bit IDs (even on 29-bit networks). 0x620-0x63F are reserved IDs for VNMFs. So you can use ANY ID within that range and it will be interpreted as a VNMF by all nodes. The ID is the source node. In this case $621 is from the Body Control Module. The First byte of a VNMF is either 0x00 or 0x01. 0x01 means Initiate the following Virtual Network(s) (VN) and 0x00 means Continue the following VNs. The next three or four data bytes contain a bit encoded list of each VN where 1 means wake-up and 0 means nothing. So if you send 0xFF this is essentially saying wake-up to the eight VNs that are encoded in that byte.
This method is like using a blow horn to wake-up the nodes. Each node will hear it and wake-up. If you want to be more subtle and only wake-up the VN your are interested in, then you can go bit-by-bit and find your VN it should take too much time either as there may only be around 20 VNs at most on any particular vehicle.
A VN will stay awake for up to 3 seconds after the first message was called. So if you want to keep the network awake you must constantly send the Continue frame $621 00 FF FF FF FF 00 00 00.
To summaryize here is the VNMF format:
Format: ArbID, B1, B2, B3, B4, B5, B6, B7, B8
As Seen: $620-$63F, 01 or 00, XX, XX, XX, XX, 00, 00, 00 (Where XX = Some bit-encoded value where each bit represents a single VN).
oh and ALL VNMFs MUST BE 8 BYTES IN LEGTH!
If you do what I do, you like it when the networks you are working with are terminated to a standard connector. The OBDII connector typically contains all of the vehicle’s networks so that engineers working on the vehicle can easily access the data. Of course after it is released, the networks are still there, lonely, waiting for companionship.
However in the case of FiatChrysler Cars, a gateway device blocks us hackers from accessing all the data from one location (the OBDII connector). So if you wanted to access the powertrain or body CAN busses, you had to find them someone in the vehicle and tap into the wires. Annoying!
Well I have good news, this practice is slowly being phased out. Now you can find the body networks located on pins 3 and 11 on the new 2011 Town and Country. All of the data that you’ve come to know and love is now available to you to devour.
As for the new Fiat 500 that will be sold in the US, this also has the body network on the OBDII connector on pins 1 and 9. However to find the connector is a bit difficult (unless they change it for the US edition). Look in the upper left area by the steering wheel. It will be located behind a panel.
Not quite sure what is wrong with me, but I decided to turn on comments as a trial. I’d like to see what your thoughts are of the horrible manure in which I write my blog; how bad my spelling/grammar can be; and how absolutely incompetent I am.
Please keep the language to a minimum and be aware that if you post any good ideas that I will steal them and not give you any credit whatsoever.
Because diagnostic data is built on top of a standard Transport Protocol (ISO 15765-2), you can use this knowledge to see which diagnostic service a particular vehicle supports and which parameters or sub-functions it may support.
Step 1. Finding Nodes’ Diagnostic IDs.
We must first have all of the nodes enumerated with Physical IDs and their respective response IDs (Note: sometimes there may be an ID that is a Functional ID. That means more than one node will respond to request sent on this ID). To do this I usually send the Tester Present Request (Service 0x3E) to each CAN BUS ID. If you are working with a 29bit system this may be daunting simply because of how many possible IDs there are; you may have to find a shortcut instead of request each ID. However on 11bit systems this is quite easy.
Start by sending tester present to ARB ID 0x001. This message would typically look like this:
0x001 01 3E 00 00 00 00 00 00 OR 0x001 02 3E 01 00 00 00 00 00. Try them both and see which works. Next simply increment your arbitration ID by one: 0x001, 0x002, 0x003, … 0x7FF. You will know that a node has diagnostics on it because you will see a response from the node after you send your request. You would typically see this: 0x7E8 01 7E 00 00 00 00 00 00. The 0x7E is the positive response to your 0x3E request (tester present). Write down (or log) the request ID AND the response ID and save them for later. Essentially the request ID is how you query the controller and the response ID is data you will get back from that specific controller. Keep in mind that you may get some CAN BUS errors. This is to be expected, but should not cause concern. You may also have some strange affects on the car such as a windshield wiper move or blinker kick in. This is because you are sending data on the bus that is interpreted by other controllers and you may have inadvertently activated another command. Cool, huh?
Step 2. Finding Supported Services.
This can be a bit tricky only because some services may require a certain message length (i.e. you may have to have 0x04 in the first data byte in order to get a positive response from the controller), but this is usually not the case. In order to do this you must remember that the service ID for a diagnostic command is found in the second byte (ARBID, B1, B2, B3, etc). So your first request might look like this: 0x7E0 01 01 00 00 00 00 00 00, where byte 2 contains the service. In this case we are not sending any protocol data. Diagnostic services are broken into ranges. This is because the request IDs and positive response IDs don’t over-lap, and since we are not interested sending the responses, we can remove the positive response IDs from the services we will request. Service request IDs are as follows: 0x01-0x3E, 0x80-0xBE. (0x3F is reserved, 0x7F is for negative responses and 0x40-0x7E and 0xC0-0xFE are reserved for positive responses coming back from the ECU).
Now that we know what our range is, we can simply send a request and based on its response we will know if this is a service that is supported. We send 0x7E0 01 01 00 00 00 00 00 00 and we get back 0x7E8 03 7F 01 12 00 00 00 00. The response is a negative response because there is a 0x7F in the second data byte. This tells us that there was a problem with our request, but does NOT mean that the service is not supported. We have to look at byte 4 to see why our request failed. In this case we got a 0x12 Negative Response Code (NRC). 0x12 means Sub-Function not supported (please see list below for other NRCs). So it’s telling that the service IS support but the sub-function (which we didn’t send one in this case) is not supported. In fact we can ignore all NRCs except 0x11 and 0x78. NRC 0x11 means that the Service is Not Supported. This gives us a definitive NO that we cannot use this service on this controller. NRC 0x78 doesn’t tell us anything, yet. In fact it means Response Pending. It may response later with another NRC or with a positive response. Other than a NRC 0x11, a simple No-Response will tell you that the controller does not support your service. Simply waiting around 100 milliseconds (ms) will be sufficient proof that the particular service is not supported on your controller.
Step 3. Finding Parameters.
This is the most dynamic of steps. It requires some understanding of the service that you are working with. For example, you may be using a service that has a sub-function or a service that has a parameter and this parameter may be 1 byte, two bytes, three, etc. So you will have to prepare yourself for a lot of negative responses (I hope you don’t fear rejection).
So here is what we do now, send our request but increment the bytes,
0x7E0 02 01 00 00 00 00 00 00,
0x7E0 02 01 01 00 00 00 00 00,
0x7E0 02 01 02 00 00 00 00 00, etc..
If you are getting positive responses back from the controller, then you have won. However if the controller is sending back negative responses then you’ll have to adapt. For instance you may get a NRC 0x22, this means “Conditions Not Correct, Sequence Error”. This NRC is particularly vague. It typically means that you must send a Start Diagnostic command first or that the key must be in the ignition, or that Venus and Mars must be in alignments. So you will just have to work with what you have. But if you get a NRC 0x12, you will know right away that this sub-function or this parameter ID is not supported by this controller and you can move on to the next one.
As you can see the trick is to automate this process. To write each message and handle each repsonse can be difficult.
|$11||Service Not Supported|
|$12||Sub Function Not Supported - Invalid Format|
|$22||Conditions Not Correct Or Request Sequence Error|
|$31||Request Out Of Range|
|$36||Exceed Number Of Attempts|
|$37||Required Time Delay Not Expired|
|$78||Request Correctly Received-Response Pending|