Hate the VIN, Wanna Change It?

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!

转载自:www.canbushack.com/blog/index.php?title=change-the-vin&more=1&c=1&tb=1&pb=1

在车辆网络中,IP地址的自动分配是实现网络集成的关键步骤之一。ISO 13400-2标准中,这一过程通常涉及到车辆网关和车辆内部网络,它允许车辆网关通过动态主机配置协议(DHCP)或者预配置的静态地址来为车辆内部的网络设备分配IP地址。这一过程确保了每个设备都有一个独一无二的IP地址,从而使得数据包可以准确无误地送达目的地。 参考资源链接:[ISO13400-2: 车辆诊断通信的互联网协议与DoIP要求](https://wenku.youkuaiyun.com/doc/7a36kziiv3?spm=1055.2569.3001.10343) 对于车辆识别号(VIN)的应用,它在车辆网络中起到了标识车辆身份的作用。VIN是车辆的唯一标识符,它被用于多种场合,包括但不限于设备发现、诊断信息检索和车辆状态报告。在IP地址分配的过程中,VIN可以作为识别车辆的依据,确保车辆的网络配置和诊断信息正确地关联到特定的车辆。 根据ISO 13400-2标准,车辆网关会使用特定的协议来与外部测试设备通信,例如通过DoIP协议。车辆网关在接收到外部设备发送的包含VIN的诊断请求时,会解析该请求,并将相应的请求转发到正确的车辆内部网络设备。同时,车辆网关会处理车辆返回的数据,并将其转发回外部设备,从而完成一次完整的诊断通信过程。 在错误处理方面,车辆网关需要实现多接入与碰撞检测机制,以确保在多设备同时进行通信时,数据不会丢失或错乱。此外,网络集成还需要考虑数据路由和错误处理策略,确保在发生网络中断或其他异常情况时,能够及时响应并采取相应措施。 为了深入理解这些概念和技术细节,建议参考《ISO13400-2: 车辆诊断通信的互联网协议与DoIP要求》一书。该书详细解读了标准中的技术要求和实现方法,为技术人员提供了实际操作的指导和参考,帮助他们更好地应用这些技术解决车辆网络集成和诊断通信中的问题。 参考资源链接:[ISO13400-2: 车辆诊断通信的互联网协议与DoIP要求](https://wenku.youkuaiyun.com/doc/7a36kziiv3?spm=1055.2569.3001.10343)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值