pcmhacking.net

80gus wrote:Yeah it will do e38 ls1 t42 and ford ECUs now I have another for other ECUs

Did you make it yourself?

Yeah mate

I wish I could say mine was that neat... I tend to have whole cars hooked up
Brace yourself...

80gus wrote:VIN Checksum
So i managed to change a vin successfully with HPT and find where the VIN checksum is located it looks the same location for every ecu i've checked so far. located at x0 10130 OC-OD
If you write a vin with HPT (Only ever allowed me to do this on BA Territory ecu for the rest it corrects checksum on all but FG ECU's so far)
It corrects those 2 bits of data I'm trying to reverse engineer it and find the actual sector location for that checksum. Slow process as its pretty much guess work the way i'm doing it. and all manual using HXD Editor checksum Analysis.
Would you know the size of the area, or what type of checksum its looking for it would have to be one of the following i,m assuming
Checksum-16
CRC-16
CRC-16 CCITT

It isn't a CRC it is a 16 bit checksum. The VID block is 0x100C0 -> 0x1013B not inclusive of 0x1013B

Simply sum them as small endian uint16s and voila you have your checksum which is stored at 1013B.

This is true for a BF, haven't checked BA.

I haven't actually implemented the above yet, so there may be more 16 bit checksums, I've located that there are 3 32 bit ones though which I posted near the start of this thread. These change per calibration.

Biggvl wrote:

rolls wrote: It isn't a CRC it is a 16 bit checksum. The VID block is 0x100C0 -> 0x1013B not inclusive of 0x1013B

Simply sum them as small endian uint16s and voila you have your checksum which is stored at 1013B.

This is true for a BF, haven't checked BA.

I haven't actually implemented the above yet, so there may be more 16 bit checksums, I've located that there are 3 32 bit ones though which I posted near the start of this thread. These change per calibration.

Thats nice and simple... guess the devs assumed if you got to that point... nothings gonna stop you!

Tazzi wrote:

Biggvl wrote:

rolls wrote: It isn't a CRC it is a 16 bit checksum. The VID block is 0x100C0 -> 0x1013B not inclusive of 0x1013B

Simply sum them as small endian uint16s and voila you have your checksum which is stored at 1013B.

This is true for a BF, haven't checked BA.

I haven't actually implemented the above yet, so there may be more 16 bit checksums, I've located that there are 3 32 bit ones though which I posted near the start of this thread. These change per calibration.

Thats nice and simple... guess the devs assumed if you got to that point... nothings gonna stop you!

I think it is more just an integrity check opposed to protection. They probably assumed no one would crack the security exchange and hence would not be able to view the binary in the first place.

Still once you physically crack an ECU open nothing stopping you from reading the flash chip directly.

If I was going to protect an ECU I would get a PIC or something that has a non readable ROM section, eg you can only write to it and store an encryption key in there. Then I would internally decrypt the program code at runtime every single time it boots up so even if you read the flash it is useless. You would need to dump the RAM from the PIC to get the key but without the program code good luck figuring out what is what in the RAM.

Fairly sure this is how sentinel hasp etc work with their dongles. Basically uncrackable.

Yeah similar to what consoles do to protect against mod chips that patch the OS. Need to interupt the boot process somewhere and get some unsigned code in there. Bosch are playing at these sorts of games, eg: http://www.swisschip.com.au/ecu-tuning- ... hiptuning/

Haltech have an interesting algo, the decryption key is protected in the computer and the tables in the tune are encrypted. They generate an MD5 hash of the password and then modify that with their own algo. Brute force is the only way from that point and so a strong/long password helps if your trying to protect against this. Short passwords can be cracked pretty quick on a GTX 970 once you've written a software implementation of the algorithm that can run on a GPU.

antus wrote:Yeah similar to what consoles do to protect against mod chips that patch the OS. Need to interupt the boot process somewhere and get some unsigned code in there. Bosch are playing at these sorts of games, eg: http://www.swisschip.com.au/ecu-tuning- ... hiptuning/

Haltech have an interesting algo, the decryption key is protected in the computer and the tables in the tune are encrypted. They generate an MD5 hash of the password and then modify that with their own algo. Brute force is the only way from that point and so a strong/long password helps if your trying to protect against this. Short passwords can be cracked pretty quick on a GTX 970 once you've written a software implementation of the algorithm that can run on a GPU.

I read about this some time ago, I wonder if that will happen more and more. Personally I think it will be rare though as imagine if you worked at these companies, you'd most likely be an enthusiast of some form who probably "chips" their own car. I know I'd push against it being uncrackable.

The protection is optional, but a lot of tuners think they need to protect their tunes. some because they are worried about people copying the tune, some because they are rubbish tunes and dont want to be caught out.