Colorado / H3 BCM hacking

Disassembly, Reassembly, Tools and devleopment. Going deep with Hardware and Software.
Posts: 90
Joined: Thu Jan 16, 2014 12:41 pm

Re: Colorado / H3 BCM hacking

Postby 04colyZQ8 » Sat May 08, 2021 12:25 pm

Yeah sure look at the difference between this, and yours, quite different! The other segments are quite similar. But the OS is very different
Attachments
21997789.bin
2004 BCM OS
(56 KiB) Downloaded 95 times

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

Re: Colorado / H3 BCM hacking

Postby 04colyZQ8 » Sat May 08, 2021 12:32 pm

Gatecrasher wrote:I think the older chip is still a TI chip. Some of the sketchy Chinese suppliers list the manufacturer as TI. It's just something there was never public documentation for. Have you get an OS you can post? It'd be worth seeing if the code is similar to the gen 2.

The gen 2 BCM uses algo $12. Might be worth seeing if the gen 1 BCM uses the same algo. The JTAG pinout for the gen 2 unit is attached. I really need to get a proper JTAG adapter. The BusPirate is just too glitchy.


Bless you!!!
That is sick:) What do I need to buy to read this out? Hope to fix my other 09-12 bcms.

I can try the same protocol to read the older bcms.. but I need some kind of processor diagram. I might try the model I posted earlier and see that the pins make sense or not? The older bcm board is very similar to the TMS470, so they must both use a internal class 2 built in chip. That should narrow the older chip down, as it also needs to have that same chip.

When you bdm the 09-12 BCM can you access the millage chip? 25c40 or something like that? I really want to be able to change that with out disordering it

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

Re: Colorado / H3 BCM hacking

Postby 04colyZQ8 » Sat May 08, 2021 12:35 pm

Just thought I'd post up the 09 os as well as just the OS, for comparing
Attachments
22812903.bin
2009 OS
(128 KiB) Downloaded 92 times

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

Re: Colorado / H3 BCM hacking

Postby 04colyZQ8 » Sat May 08, 2021 1:16 pm

How does the file look disabled by ida? I only have the freeware version and it doesn’t have arm7. So it doesn’t disassemble it very well!

Technically if I no a Boolean in a segment I should be to trace it back to the 0S. With a proper full bin. File but I haven’t been able to do so. In the 09 file you posted the boot loader shoes the adresses of each segment and I can easily split it up or build it.

I’m unable to build a 04-08 as the boot loader in the os doesn’t seem to list the adresses. At least not in anyway that makes sense

Posts: 77
Joined: Sat Apr 25, 2020 6:09 am

Re: Colorado / H3 BCM hacking

Postby Gatecrasher » Sat May 08, 2021 2:37 pm

I've been using a BusPirate, but as I said, it's buggy. I can't consistently control the processor. I almost feel like the one time I got it to stop and read out was a fluke.

RADustin recommended this in his EBCM checksum thread: https://www.digikey.com/en/products/det ... RgQAvD_BwE

That's the one I'll pick up if I decide to get one.

You can't read the EEPROM directly through JTAG since it isn't a JTAG device. But you might be able to feed some code into the CPU to read the EEPROM indirectly. There might also be some code in the OS that'll let you write the odo through the class 2 bus.

I'll try to look at your code later this weekend. I've got a cracked drain pipe I need to fix before I can sink too much time into hobby stuff.

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

Re: Colorado / H3 BCM hacking

Postby 04colyZQ8 » Sun May 09, 2021 2:44 am

Gatecrasher wrote:I've been using a BusPirate, but as I said, it's buggy. I can't consistently control the processor. I almost feel like the one time I got it to stop and read out was a fluke.

RADustin recommended this in his EBCM checksum thread: https://www.digikey.com/en/products/det ... RgQAvD_BwE

That's the one I'll pick up if I decide to get one.

You can't read the EEPROM directly through JTAG since it isn't a JTAG device. But you might be able to feed some code into the CPU to read the EEPROM indirectly. There might also be some code in the OS that'll let you write the odo through the class 2 bus.

I'll try to look at your code later this weekend. I've got a cracked drain pipe I need to fix before I can sink too much time into hobby stuff.


I understand I’m in the middle of moving, and cleaning up 20 years of collecting car parts! Hard to find time for my hobby, but it keeps me going thinking about truck stuff:)

Ok the issue I found with trying to read the e67 bdm was the watch dog/ and or second processor chip causing a reset. It was very tough to keep the processor halted. I could read the bin, but couldn’t write to it or erase it. I think I just needed a better kernel. Then what pw micro offered.

So if I get this device instead of the bus pirate. Can I use the same kernel you used to disable watch dogs, and read the flash? I think that same kernel could be modified to be uploaded via obd 2 port to the processor ram, if we know the correct address. But I need to first fix my bricked bcm first., via j tag

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

Re: Colorado / H3 BCM hacking

Postby 04colyZQ8 » Sun May 09, 2021 7:03 am

So for example I think that this is likely the location that enables or disables Fog lights, I don't think the file you posted has fog lights enabled? If it did this would likely be F0, instead its 80. Location 21722. What I want to know, is, in an disassembly does this address show up in the OS? It should somehow be linked to it? And would it show other options that work? Because I'd like to enable fogs to stay on with low beams and high beams on. So maybe we can say type E0, or something to make that happen, but its an complete guess without seeing what is implemented in the OS.
Attachments
possible_2009_BCM_fog_location.png
2009 BCM full dump fog light enabled option

Posts: 77
Joined: Sat Apr 25, 2020 6:09 am

Re: Colorado / H3 BCM hacking

Postby Gatecrasher » Wed May 12, 2021 2:54 am

JTAG doesn't use a kernel. It directly controls the hardware at a very, very low level. So when you send it a halt instruction, it stops. CPU, memory bus, watchdogs....everything just stops cold. You can read out the contents of memory and registers as they were frozen at that moment in time. The command I used to read the flash just went through and read every byte of memory between the start and end points I specified. You can use the same technique to write to flash, assuming you know how to set up the different control registers to enable flash writes in the first place. I don't know how to do that just yet. Having an unreliable interface didn't really help my motivation with that.

Sometimes different calibration fields are copied from flash or EPROM into RAM. You could potentially test calibration changes by editing the values in RAM instead of flash, assuming they're set up that way and not updated after the CPU finishes booting.

Finding other valid values in disassembly can be a real challenge. Take your fog light example. When you press the fog light button, it might check a couple flags in RAM that show whether or not fog lights are enabled, and whether they're allowed to be turned on right now. IE, are the headlights on. So then you'd need to backtrack that 'fog lights allowed' flag to see where it gets set up, and whether it's tied to a calibration value. If it's not, then you might need to modify the OS itself to allow headlights and fog lights at the same time. None of this can happen until you find the subroutine that maps to the fog switch input and output pins, which is a challenge in itself.

Keep in mind this is all just theoretical. I haven't dove very far into this OS at all.

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

Re: Colorado / H3 BCM hacking

Postby 04colyZQ8 » Fri May 28, 2021 12:20 am

Yeah people keep trying to tell me to use the ram to watch for changes and trace it back. Never could get that to happen on the E67, as it wouldn't stay in halt, and kept resting. I think because of its separate ECU chip with some kind of watch dog. Ok It seemed like PE micro had some sort of code to disable watch dogs on the main CPU for the E67, that's why I thought it would also be required for this project.

So in the disassembly it doesn't show where the Fog Lamp enable bit goes to in the OS? Isn't the Os laid out like a bunch of addresses? As the code executes in it's order it would reach address xxxxxxx and jump there to check what the Value is? If xxxxxxx = = 90 then Fog lamps are enabled .... etc.. I just wnat to find that point because there should be a table of values listed in the OS, that are excepted for that address. Then I can try each one and see what it does? Right now I don't really know which values are valid?

Posts: 77
Joined: Sat Apr 25, 2020 6:09 am

Re: Colorado / H3 BCM hacking

Postby Gatecrasher » Thu Jun 03, 2021 2:13 pm

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.

PreviousNext

Return to Engineering and Reverse Engineering

Who is online

Users browsing this forum: No registered users and 2 guests