Colorado / H3 BCM hacking

Disassembly, Reassembly, Tools and devleopment. Going deep with Hardware and Software.
Posts: 359
Joined: Sun Apr 10, 2016 9:20 pm

Re: Colorado / H3 BCM hacking

Postby kur4o » Thu Jun 03, 2021 4:14 pm

Looks like the options are bit encoded in the byte. You can split the option byte in 8 bits and test each for on/off.

For example F0=11110000, bits 10,20,40,80 are on bits 1,2,4,8 are off.

Some option might use 2 bits, first enable the feature and second turning on/off the feature.

Posts: 274
Joined: Thu Feb 13, 2020 11:32 pm

Re: Colorado / H3 BCM hacking

Postby ironduke » Fri Jun 04, 2021 3:47 am

kur4o wrote:Looks like the options are bit encoded in the byte. You can split the option byte in 8 bits and test each for on/off.

For example F0=11110000, bits 10,20,40,80 are on bits 1,2,4,8 are off.

Some option might use 2 bits, first enable the feature and second turning on/off the feature.


I don't know if this helps, or if it makes it any easier/harder but for a 2008 G6 remote start is enabled by a 3b write command, I can try and dig up my notes but it was a couple of bytes written with that one command and I kind of had it narrowed down to the options that were in the tech2 when setting it up.. You could turn on remote start when setting it up but if it wasn't enabled in the BCM it didn't work.. I wonder if the colorado/H3 bcm is the same way.. might be able to send some 1a requests and note them down, hack foglamps or whatever you want and then do another 1a request set and compare them?

Posts: 57
Joined: Thu Jan 16, 2014 12:41 pm

Re: Colorado / H3 BCM hacking

Postby 04colyZQ8 » Thu Jun 10, 2021 1:31 pm

ironduke wrote:
kur4o wrote:Looks like the options are bit encoded in the byte. You can split the option byte in 8 bits and test each for on/off.

For example F0=11110000, bits 10,20,40,80 are on bits 1,2,4,8 are off.

Some option might use 2 bits, first enable the feature and second turning on/off the feature.


I don't know if this helps, or if it makes it any easier/harder but for a 2008 G6 remote start is enabled by a 3b write command, I can try and dig up my notes but it was a couple of bytes written with that one command and I kind of had it narrowed down to the options that were in the tech2 when setting it up.. You could turn on remote start when setting it up but if it wasn't enabled in the BCM it didn't work.. I wonder if the colorado/H3 bcm is the same way.. might be able to send some 1a requests and note them down, hack foglamps or whatever you want and then do another 1a request set and compare them?


That’s cool! Yeah I noted Tpms pressure setup but idk how to use that info to say find low and high tire pressure limits

Posts: 57
Joined: Thu Jan 16, 2014 12:41 pm

Re: Colorado / H3 BCM hacking

Postby 04colyZQ8 » Thu Jun 10, 2021 1:32 pm

kur4o wrote:Looks like the options are bit encoded in the byte. You can split the option byte in 8 bits and test each for on/off.

For example F0=11110000, bits 10,20,40,80 are on bits 1,2,4,8 are off.

Some option might use 2 bits, first enable the feature and second turning on/off the feature.

This is really cool I don’t understand it but neat.

So I have seen both 80 or 90 used for on, but don’t see what difference it makes?

Posts: 57
Joined: Thu Jan 16, 2014 12:41 pm

Re: Colorado / H3 BCM hacking

Postby 04colyZQ8 » Thu Jun 10, 2021 1:34 pm

Gatecrasher wrote:Here's why this is challenging.

Address 0x2172 isn't directly referenced anywhere in the disassembly. All of this code uses indirect references and offsets. I went digging for that reference, and I found where it makes a call to 0x216C, along with addresses from four other calibration segments. I've only glanced at this, so I don't have a full understanding of it. But this is the gist of it.

It loads a pointer to a starting point RAM, and then it loads these starting points from five different calibration regions. It loads a byte from each location, manipulates it, and then stores it in RAM. It increments all the addresses, and then does it all again another 11 times. It actually looks like it's packing different configuration options into various memory locations. So at some point it processes your byte at 0x2172, and I think it writes it to 0x8000C5A in RAM.

That RAM address isn't referenced directly in the code either. So we're right back where we started. We have to find the base pointer, find the code that offsets from that base address to the address we want, and then figure out what it does and what values are and are not valid. This gets even trickier if it's actually packing multiple values into a single RAM address. It also likely references a half dozen other RAM values along the way, so now we need to go find out what those do, before we can find out the valid ranges for your fog light calibration byte. So maybe 0xF0 is a valid fog light combo....but only if specific values in other unknown RAM addresses are in a given state.

It's this giant Gordian knot of ones and zeroes.



This is far Over my head of understanding...lol but it makes some sense to me

Previous

Return to Engineering and Reverse Engineering

Who is online

Users browsing this forum: No registered users and 1 guest