Colorado / H3 BCM hacking

[Tazzi]

Didnt you get this to work?

6D 40 F0 36 80 00 1E 00 0B 82

This is saying to execute code at location 0x001E000B

Well if code 76 is a positive ack? I was not sure?

And it is? Isn’t it length 1e execute at location 0b82 pcm adds 3 byte 80 to make it 0x8000b82 that’s were my code should be

Sorry my response was wrong there as I was assuming you were stating the VPW checksum at the end (Which you see when logging data).

Would have to check against something like pcmhammer to verify.

But I know on the canbus based ecus, is structured like:
ID, 0x80, memory offset, databytes.

So for example on an engine computer:
0x7E0, (length bytes), 0x36, 0x80, 08,00,30,00, 11,22,33,44,55,66,77,88,99,AA,BB,CC

Where:
7E0 = ID
0x36 = upload command
0x80 = execute this after upload
0x08003000 = memory offset
0x112233445566778899AABBCC = data uploaded to memory offset location.

Its been a while since looking at the P series ECUs, but I assume it setup in a similar manner for them.
I do recall that the 0x36 stuff on P series ECUs required a 2byte checksum at the end.

[04colyZQ8]

I’m calculating the checksum with my script tested and calculated the 16 bit sum at the end. Should be structured as such at least 36 00 is.. no sample for 36 80

6c, 40, f0, 36, 00, aa, aa, bb, bb, bb, data.. , checksum

Where;
00 is optional 80 execute
Aa, aa is length of bytes to write to ram
Bb, bb, bb is 3 byte address in ram to write to

[antus]

For VPW 80 or 00 execute bit is part of the sum. It doesnt require any special treatment. Put it there, or not, and calculate the 16bit sum. Generally speaking your interface puts the VPW CRC on the end as well. So if you look at a raw log, you see both. But above I think the VPW CRC is hidden.

See the code that builds the block in pcmhammer here: https://github.com/LegacyNsfw/PcmHacks/ ... ite.cs#L19

Note that for multipart payloads you start with the highest block and work down, then on the last packet which contains the start of the payload you send the execute bit, so the pcm jumps to the first byte of code and the kernel image has been built in contiguous memory.

It sounds like the payload is the same between VPW and CAN?

[kur4o]

To execute only at specific address you need this message

6c 40 f0 36 80 [xx xx=lenght-should be zero ] [ yy yy yy =3byte address] [ block chks]

[04colyZQ8]

Ok thanks

[04colyZQ8]

6D 40 F0 36 80 00 00 00 01 B0 [01 31] checksum 16 bit
6C F0 40 7F 36 80 00 00 00 01 12 // not happy

[04colyZQ8]

What’s the positive ack for mode 36 80 look like?

This is so frustrating I don’t know what’s wrong I wish I could see the ram after my attempt but it seems to reset before I can capture ram via bdm! I can see other things but not this

[kur4o]

Code $12 - Sub-Function Not Supported or Invalid format

Might need unlock, mode 34 and mode ae before you can use it.

[kur4o]

I just noticed there is block checksum added in script

You can test since I have no idea if it works.
Add blchk at end of message and it should calculate the block checksum for you on the fly.

example

6d 10 f0 ......4E 75 blchk:1:1000

[04colyZQ8]

I have it unlocked correctly:( yet no dice
I know I have been using blchk 2:100 i think seems to work fine