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|
On most late-model cars, there are hundreds of messages with thousands of parameters being transferred between controllers, this leads to the idea that EVERYTHING is being able to be controlled by CAN BUS messages. This simply is not the case. If a controller doesn’t need to send internal data to another controller then it won’t. Simple as that.
So why am I writing this? Because the biggest waste of time in reverse-engineering the CAN BUS is looking for a command or a parameter that simply isn’t there. You need to have the notion that everything is not available and sometimes you won’t find it no matter how much you look.
So how do you determine how long to spend on looking for a parameter or command? Well the answer, I think, depends on the importance of getting the parameter. I take the example of trying to find Engine Speed on a CAN BUS. Engine Speed is nearly universally available on today’s CAN BUS vehicles. It is usually simple to find and scale, so not much time is wasted, but in contrast, Outside Air Temp may not be collected by a module on a car or may not be broadcast by the controller that collects the data. In the first instance where it is not collected there are ways to find this out before hand. You can look at publicly available wiring diagrams that show (or rather do not show) that there is no Outside Air Temp sensor on any controller. This will save you time and frustration.
In the case of commands sent over CAN BUS (i.e. Unlock from a key fob). These can be tested by capturing all of the messages while you pressed the unlock button, then play those messages back to the network one or two times to see if the doors unlock. Why does this work? If the message was sent over the CAN BUS then by playing all of the messages back on the bus you should have the same result as when you pressed the button such as any parking light flashing, horn honking, etc. If you do then you know the message is broadcast over the CAN BUS, if not then you can assume that it is most likely not available. If it is not available, simply move on. You can try the process again one or two more times, but you probably did it right the first time.
So good luck and as always let me know what you’re working on, I’m always interested to help.
For those of you who like to leave there car keys in the ignition while the driver door is open or who don’t where a seat belt, you’ve heard the Chime and have probably cursed it many, many times. Well I can help you defeat it or embrace it.
First you need to gear up. You will need to connect to the GM Single Wire CAN bus. This is on PIN 1 of the DLC (OBD II port). SW CAN runs at 33,333 bps (standard rate). So once you hooked up your device (see earlier posts for info on these), you should be able to communicate with the vehicle over SW CAN.
So now you just need to know the message, but first a crash course in GMLAN 29 bit ID.
The 29 bit ID is broken into three pieces. The Priority, Parameter ID, and Source Address. The priority is the first 3 bits of the ID. Priority allows for more important messages to get greater access to the network in the case of high network congestion. This leaves 26 bits reaming of the 29 bits. These are divided evenly amongst the Parameter ID and the Source Address (i.e. 13 bits each).
The Parameter ID is essentially the ID for what will be sent in the data portion of the frame. The Source Address is the node that sent the message. So messages from the address 040 all come from the same node. Cool huh!?
So let’s get to CHIME already…
Chime has a parameter ID of 0x0F. This means that if you want to send Chime you must put 0x0F starting at the 26th most signifigant bit. For example 0x1001E060 would be a chime command (0xF) with priority 4 (0 is highest priority) and send from node 0x60. Its easier to explain when we see this in binary. 0x0F is #b0:0000 0000:1111. So we put the whole ID together by taking the priority then parameter ID then source address. This will give us #b1:0000 0000:0001 1110:0000 0110:0000 (where the parameter ID is in bold).
Ok now that we’ve finished with the ID, let’s look at the data. The data portion is what is defining all of the characteristics of the Chime. In other words will this be a long chime or a short one, a click sound or a ding sound, a one-time sound or multiple times? There are 5 bytes that define all of these characteristics. So you will see that you can do a lot.
The first four bits of the first byte (the most signifigant nible) defines the speaker that this sound will come out of. For the front left speaker it is the most signifigant bit (or bit 7 of the byte). Next is the passenger (bit 6), then the rear driver side (bit 5), then rear passenger side (bit 4). So if you wanted to make the sound in only the driver speaker then you would send 0x8X in the first byte (where X is irrelivent).
The second nibble of the first byte describes the type of sound it will be. Either a beep or a click. Experiment to find out what these are.
The second byte describes the intonation of the chime. So you can adjust this on your own as well.
The third byte is the amound of repetitions you would like the sound to make. So if you want the chime to happen three times. This should be set to 3.
The fourth byte describes the duty of the chime. Experiment with this on your own.
Last byte is unknown currently. But if you know send me an email, I’ll update this entry.
So if you would like to send chimes to your car, here you go. If you want to cancel a chime, it should be good enough to have your software wait for a chime command and simply send one of its own with a really fast chime and a 0% duty cycle. That should end the last chime command.
Good luck and as always click on the contact link above if you have questions!
Good news you can. Well sort of. The VIN stored in controllers is writable (well maybe). But in some cases its difficult and some impossible. So I am hear to give you some tips to make life a little easier.
First find out if the controller stores the VIN. This can usually be done on OBD II controllers by sending a CAN message formatted like this:
ARBID = 7E0 DATA = 02 09 02 00 00 00 00 00.
This will get the first part of the VIN if it is on the controller. So a typical response might look like this:
ARBID = 7E8 DATA = 10 13 49 02 31 39 48 31.
You could send a Flow Control Message (7E0 30 00 00 00 00 00 00 00) to get the remainder of the data bytes but our goal is only to see if this controller stores the VIN. If we get a negative response (7E8 03 7F 02 12) then we know it does not and we and thus we cannot change something that isn’t there.
So now we know the controller supports VIN, this is where things get OEM specific. So in the interest of brevity I will give an example of setting VIN on a GM CAN BUS vehicle (GMLAN).
GM employs the GMLAN diagnostic protocol for enhanced diagnostics. So you may want to do some reading of the GMW 3110 spec (downloadable from IHS). So we know how to read the VIN, but how do you write it. The VIN is stored in the controller as a Data Identifier (DID). Service 3B is used to write DIDs. However as VIN is considered a protected DID, you will need to “unlock” the controller using Security access first. But of course you don’t have the security access algorithm do you? I didn’t think so. So we must use a Brute Force technique to guess the correct Key to unlock the controller.
To brute force the Key you must send a Seed request to the controller (7E0 02 27 01 00 00 00 00). This request must be done first before you send a key. On GM the Seed is static, it doesn’t change each time that it is requested. So this means we must increment the Key one at a time until the controller responds back with a positive response (7E0 01 67). So let’s get cracking.
First send the Seed Request then send a Key (7E0 04 27 02 00 01; where 00 01 is the two byte key). Most likely the first key you choose will not be the correct key for the seed. So you will see a negative response from the controller indicating that we have an incorrect key (7E8 03 7F 27 35). This will mean we must try again. But we know we have the wrong key so add 1 to the previous Key (00 01 + 1 = 00 02). So send the seed request and another Key request. Now we might get another negative response with saying wrong key, but we might get a message stating that we have exceed the number of attempts (7E8 03 7F 27 36). This would indicate that we cannot send any more seed or key request until we have reset the power on the controller. So manually or automatically, reset the power on the controller. Now we can try again. Send a seed request, but this time check for a negative response from the request (7E8 03 7F 27 37). This means that the required time delay has not passed. Keep sending the seed once or twice a second until the error goes away. This delay is an internal timer that acts as a security method for brute forces the key. There is no simple way around it, so we must endure it. When we get a positive response, then we send the key (7E0 03 27 02 00 02).
That’s it, we just loop through this until we get a positive response from the controller after a key request.
Please not that in the worst case this could take up to 9 days! So you need to be a bit patient. But once you have the Key it will work for this controller every time. Unfortunately just this controller.
But now you have been able to successfully unlock the controller and you can now use Service 3B to write the VIN. So make three messages that look like this:
7E0 10 13 3B 90 31 31 31 31
-- Wait here for flow Control frame (7E8 30 00 00) --
7E0 21 31 31 31 31 31 31 31
7E0 22 31 31 31 31 31 31 31
The 31’s are The VIN digits 1-17, the 90 is the VIN DID (On GM controllers) the 3B is the service, the 013 is the length of the data in hexadecimal, and the 1, 21, and 22 are the ISO 15765 Diagnostic Layers.
If the VIN is written successfully then you should get a positive response:
7E8 02 7B 90
Good luck and let me know if you have any questions!