Colorado / H3 BCM hacking

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

Re: Colorado / H3 BCM hacking

Post by kur4o »

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.
ironduke
Posts: 579
Joined: Thu Feb 13, 2020 11:32 pm
cars: Mainly GM trucks, a Cruze and an Equinox for dailys..

Re: Colorado / H3 BCM hacking

Post by ironduke »

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?
04colyZQ8
Posts: 380
Joined: Thu Jan 16, 2014 12:41 pm
cars: 2004 Colorado 4.8L swap
86/90 Jimmy 6.5L diesel swap
80 Chevrolet Silverado TBI swap
88dodge W100 LPG conversion

Re: Colorado / H3 BCM hacking

Post by 04colyZQ8 »

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
04colyZQ8
Posts: 380
Joined: Thu Jan 16, 2014 12:41 pm
cars: 2004 Colorado 4.8L swap
86/90 Jimmy 6.5L diesel swap
80 Chevrolet Silverado TBI swap
88dodge W100 LPG conversion

Re: Colorado / H3 BCM hacking

Post by 04colyZQ8 »

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?
04colyZQ8
Posts: 380
Joined: Thu Jan 16, 2014 12:41 pm
cars: 2004 Colorado 4.8L swap
86/90 Jimmy 6.5L diesel swap
80 Chevrolet Silverado TBI swap
88dodge W100 LPG conversion

Re: Colorado / H3 BCM hacking

Post by 04colyZQ8 »

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
User avatar
Gatecrasher
Posts: 272
Joined: Sat Apr 25, 2020 6:09 am

Re: Colorado / H3 BCM hacking

Post by Gatecrasher »

I dropped this for a few months, and then I got motivated and picked it up again. About all I've learned is that I really, really, really hate this damn module. All I want to do is disable the tire pressure monitor, and the DRLs. I thought I was on to something with the TPM, but it ended up being a lucky guess. All I managed to do was disable the Class 2 message that sends the error to the cluster. The system is still active, but the faults never make it to the DIC. All I care about is that stupid light is gone. I can turn it back on if I own it long enough to need new tires. I'll get new sensors at that point.

I'm still fighting with the DRL disable. The code in this thing is a clusterfuck of indirect references, logic shifts and booleans against a knot of other inscrutable memory addresses. It's not fun any more. At this point I'm just going to get the export calibrations and do some trial and error until I figure out what shuts those stupid lights off.

How can 128k of code be this convoluted? It really makes me wonder how anyone figures out the engine and trans modules without inside info. I guess I'm just not that smart.

Sorry, I had to vent. Thank you for letting me get that off my chest.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: Colorado / H3 BCM hacking

Post by Tazzi »

Which calibrations are you targeting specifically? As you are pre-global A, its likely best to target the cluster to be honest.

In the Holden VE's, TPMS is 'activated' by our RFA (detects the Key fobs and TPMS sensors) which sends the data to the BCM, then to the cluster I believe. The TPMS is suppose to be turned off at the instrument cluster otherwise turning it off at the BCM means you will still have the TPMS readings on screen (If yours shows pressures).

As for DRLs, which calibration/s are you targeting? I would assume something related to outside lighting?
Reversing the operating system is one method, Better option is to identify a rough region where headlights/foglights/DRLs are being affected then finding the references back from that.

Generally a bit of trial and error on that area is much..much faster then actually reverse engineering the OS.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Gatecrasher
Posts: 272
Joined: Sat Apr 25, 2020 6:09 am

Re: Colorado / H3 BCM hacking

Post by Gatecrasher »

The cluster on these trucks isn't programmable, so that's been a dead end. I at least know what class 2 messages are responsible for the outputs though.

I've been looking at it as one consolidated flash dump. I can dig into the code and then check the cross references to the calibration segments.

Usually I start working backward from the DTC table, which I found pretty easily. It includes references to the DRL circuit and TPMS diags. I captured all the Tech2 output, so I also know which DPIDs and PIDs contain the diagnostic info for those functions.

There's no detailed datasheet for this specific chip. I only document I have shows the start and end address ranges for the various hardware registers. I can infer some of the details from other TMS470 series chips, but it's been slow going. I can't find where it copies data from the GPIO to the PID memory address. None of the subroutines that reference the GPIO range seem to touch the PID RAM. It's probably an offset from some non-obvious starting location. As I said, it's a tortured rats nest of indirect references.

I can't even find the functions that transfer the class 2 messages to and from the physical hardware into RAM. I've got two class 2 message tables defined, but I can't figure out if they're receive or transmit filters because I can't figure out how the data gets to or from the physical hardware. I was going to work backward from the lighting message on the data bus, but that's not happening because I can't figure out which of the couple dozen RAM addresses actually populates the damn message slot because I can't even figure out where the message slots are to begin with.

So anyway, if I get the export calibrations, I can just do a diff on them and combine some guesses with some trial and error.

I really don't need to do any of this. I just thought the challenge would be fun, and it might give me some high level insight into how the later Global A, CAN based stuff worked at a conceptual level. The fun is gone, and the only insight I've gotten on the later stuff is that I should probably just stay away from it. If I'm this frustrated with a little, low option truck BCM, I don't know how I'll ever get anywhere with the monster that is the Global A BCM.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: Colorado / H3 BCM hacking

Post by Tazzi »

Ok, looking up a 2009 Chev Colorado (1GCCS139298122865) and looking at the tis site (https://tis2web.service.gm.com/), there are 5 calibrations to edit excluding the operating system:
-System
-Interior/Exterior Lighting
-Theft Alarm
-Locking
-Accessory

So its safe to say TPMS would not be in the lighting, so thats 4 calibrations.
System "MIGHT" have it, but I would be leaning more towards accessory and locking calibrations.

As you have a method for recovering using BDM, Id suggest just zeroing whole sections in those calibrations and seeing if you get any further. :thumbup:
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: Colorado / H3 BCM hacking

Post by Tazzi »

Had another look today, would have suggested to compare against a Holden colorado, but appears they use a different style BCM. Odd that they didnt use the same around the same era.. infact.. doesnt appear our Holden colorados ever used that style BCM which is odd!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
Post Reply