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!
So you found a CAN BUS to reverse engineer, but you don't know it's buad rate. There are a couple to find it out.
One. Go one-by-one through a possible list. CAN BUS baud rates tend to be of only certain baud rates. I am not positive, but this most likely has to do with the common crystal speeds used in microprocessors. The slower the crystal, the slower the bus speed. So baud rates tend to be one of the following: 33,333 bps, 50 Kbps, 83,333 bps, 100 Kbps, 125 Kbps, 250 Kbps, 500 Kbps (Most common), 800 Kpbs, and 1,000 Kbps. The last two being the least common as they suffer from reduce network length issues. You will not find a baud rate that exceeds 1,000 Kbps as this violates the CAN BUS specification.
If I do not know the baud rate of the network that I wish to connect to, I will typically go through this list and hope one works. In some cases you may effectively decapitate the network by having the wrong baud rate set in your tool. So make sure you are not switching baud rates while the vehicle is in motion! This could cause undesired effects.
Two. Use an osciliscope or logic analyzer. The foolproof way of measuring any serial data network such as CAN BUS is to use tool that can measure the one bit time. Baud rate is simply the inverse of one bit time. So if you can measure this, you simply take 1/(one bit time) in seconds and you have your baud rate.
The best location to find a single bit on CAN BUS is to look at the last transition. This is typically the ACK bit (acknowledge). This is where receiving nodes send back a single bit to say that they properly received the frame. This is always a bit by itself as the bit to the left is recessive as well as the bit to the right whereas it is dominate. So it will stand out and you should have little trouble finding it. So look to that last transition and mesure from on transition to the next and you should get something like 0.000002 seconds. In this case you will simply take 1/0.000002 and you will get 500,000. Thus the baud rate will be 500,000 Kbps. Done!
So you want to get data from the vehicle? Good news, its there you just have to know how get it.
You have a couple of options: Buy the data or Reverse the Data from an Existing Scantool.
So you want to buy the data, here's how that works. You have to be a member of Equipment and Tools Institute (ETI). An ETI membership will allow you to get access to most OEMs (Honda, Toyota, Ford). In some cases you have to get an extra license with the OEM (GM and Chrysler). An ETI tool membership will set you back around $5,000 plus $2,500 to get the data. You are required to use the data in a commercially available tool within one year of joining. And of course you cannot sell the data.
ETI data is not a slam dunk. You'll have to organize the data yourself. Sometimes it in Excel files sometimes its in PDF's and sometimes Access Databases. So you'll have to massage the data to fit your application.
The other method is to get the data from a scantool that already has the data. To do this you will need to connect your scantool to a device such as a neoVI or ValueCAN and Vehicle Spy software. These devices will allow you to simulate the vehicle's network. By connecting the scantool to these devices you can send a properly formatted diagnostic response to the scantools request. This will allow you to change the data portion of the message. By changing this data you can derive parameter identifier, the data position and scaling.
For example, if you want to find Enhanced ID for Engine Speed you would setup the scantool to request Engine Speed, it will send a message with Engine Speed parameter ID (0x000D) and by changing the data in the response message from 0x00000000 to 0xff000000 to 0x00ff00000 to 0x0000ff00 to 0x000000ff you will find that the Engine Speed is located in the first and second bytes of the response message. Now you can set the response data to 0x0001 and you will find the scaling for the message will equal the signal value (0.25).
You can do this for each of the parameters you are looking for. Once set up, you'll find that it will take about 30 seconds per parameter.
Again if you need help, just let send me some me some questions under the contact section listed above.
So you want to Unlock and Lock the doors using the CAN BUS? Well I've got good news for you, you can. Well sort of...
Because most modern vehicles have distributive electronic systems, unlock/lock type functionality is often done via a CAN BUS message by the OEM themselves. Typically if the RFA module (controller that receives commands from the key fob) is separate from the controller(s) that actuate the door locks themselves, then this command will occur over the CAN BUS.
So how do you know if this RFA is separate? You will most likely have to consult a wiring manual such as the Mitchell Guide.
So if the modules are separate, you will have to connect to the vehicle's body CAN BUS (this is often separate from the Powertrain bus or OBDII CAN BUS). Once you've found this network, you will have to monitor the network for the Unlock or Lock commands by using the factory key fob and watching for a new message that shows up or data that changes at the same instant that you press the key fob lock/unlock buttons. Do this about 3 to 4 times and you'll find the message that controls the Unlock and Lock commands. If you don't find it, try a little bit more, but remember it might not be there.
So once you have the message, you can test it. To do this, simply send a message with the same Arbitration ID and Data as the one that you discovered. Then see if the doors lock/unlock. If they do, you've found it. If not, try again, perhaps you found a message related to a door unlock/lock procedure such as disarm or dome light status.
Again, if you need help, let me know..
When I speak to most people about the vehicle network or CAN BUS there is a common misconception that there is only Diagnostic Messages or OBD II Messages. So what's the difference between Diagnostic Messages (such as OBD II) and Normal Messages on a typical CAN BUS?
Simply put Diagnostic Messages are Command/Response Messages. So if you want to get data from a controller, you have to send it a request. It will then respond to that request (hopefully). This is done using a common diagnostic protocol. There are only a handful that are used and they are typically specific to the OEM, however there is not much difference between OEMs on how they have implemented their flavor of Diagnostic Messages. That said all OEMs that sell vehicles in North America support the common OBD II protocol, those in Europe support the EOBD and in China, the new China OBD (Based on EOBD).
Normal Messages are the Messages that are transmitted between controllers. This data varies depending on the electronics systems and like the OEMs Diagnostic Protocol, this data is also proprietary. This data does not need to be requested (is nearly 100% of cases). This data is typically sent at a periodic rate by a controller as fast as it needs to be sent so that listening controllers get the most recent value. If you are doing data acquisition, this is the data you want.
The goal of the this site is to help users who wish to extract both Diagnostic and Normal Messages and thier data from the vehicle's network.
One common misunderstanding about the vehicle network data is that it is limitless. The truth is that the only data on the network is the data that is required to be there. Nothing more, nothing less. What is required is different from vehicle to vehicle. For example some vehicles might have adaptive cruise control and this system might require vehicle dynamic information that is not required on vehicles that do not posses this system.
More and more data is being added to already heavily loaded networks, so automotive OEMs are adding more networks to accommodate more data. Good news for us, now we can get more info at higher data rates.
CAN (Controller Area Network) BUS is not a new network, but unlike more popular network names, CAN BUS is geared more for Embedded Controllers such as the ones found in modern automobile. So when I speak of CAN BUS 'Hacking', I am refering to automotive network reverse engineering.
The CAN BUS is now a required network on vehicles manufactured in the U.S. from 2008 and beyond. It's popularity amoung automotive OEMs is nearly universal. But unlike most open protocols such as TCP/IP and HTTP, CAN BUS is almost entirely implemented as a proprietary protocol. Thus if we want to understand it, we must 'hack' it.
I will be posting more about what exactly the CAN BUS is, but you can get more infomation on it from Wikipedia by clicking here.
|<< <||> >>|