Colorado / H3 BCM hacking

Disassembly, Reassembly, Tools and devleopment. Going deep with Hardware and Software.
04colyZQ8
Posts: 469
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 »

If someone has a script file sample for 36 with 4x that might help me get this to work
User avatar
antus
Site Admin
Posts: 8996
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: Colorado / H3 BCM hacking

Post by antus »

4x and 1x is not relevant. The operating system has already initialised the DLC, and timing is controlled in hardware. The same kernel comms will operate at whatever speed the DLC was running at when it executed without any special DLC code for the speeds. In PCMHammer, the bus speed is set early in the process, there is nothing at all in the kernel different or configured on speed.

You may need more hardware configuration. This is PC memory controller mindset on my part, I don't know about the BCM, but because the addresses are so different the CPU might be configured to block execution from flash before it hands off to the kernel. If thats the case you'll have to figure out where and how to jump to the main flash. Certainly in some PCMs but not others, the output port mask needs to be changed in order to turn on VPP. And for BDM the init code in the cfg files sets up hardware by pokeing in to registers to configure its state to enable flash access. Just one idea, there is a lot of different things that could come in to play here. Getting running the first time is the hardest bit as unless you have a realtime debugger on the hardware you are flying blind until you get a response back and the hardware is unforgiving and with only limited public documentation. It took me years of trying to my first flash kernel to respond, after that it was not so hard.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
04colyZQ8
Posts: 469
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 »

I'm confused why the factory only sends 6C 40 F0 34, but other programs send 6C 10 F0 34 00 10 00 FF 80 00
I tried 6C 40 F0 34 00 10 00 00 0B 82 and got 6C F0 40 7F 34 00 10 00 00 0B 12 NEG RESPONSE

Otherwise sending the bellow msg after tweaking the script to include a switch to vpw 4x*, I get a good positive 78 and 73 response!!
6D 40 F0 36 00 00 1E 00 0B 82...
*Universal patcher master script code to switch to vpw 4x (had to read the source code to find this!! Will suggest adding this to .txt sample script file:) )

Code: Select all

setspeed: 4x
Now if I change to bit 80. than I get a different ack: Is this bad?? Or good?
6D 40 F0 36 80 00 1E 00 0B 82......
RESPONSE

Code: Select all

6C F0 40 76 80 76
04colyZQ8
Posts: 469
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 »

antus wrote: Tue Jul 09, 2024 11:45 am 4x and 1x is not relevant. The operating system has already initialised the DLC, and timing is controlled in hardware. The same kernel comms will operate at whatever speed the DLC was running at when it executed without any special DLC code for the speeds. In PCMHammer, the bus speed is set early in the process, there is nothing at all in the kernel different or configured on speed.

You may need more hardware configuration. This is PC memory controller mindset on my part, I don't know about the BCM, but because the addresses are so different the CPU might be configured to block execution from flash before it hands off to the kernel. If thats the case you'll have to figure out where and how to jump to the main flash. Certainly in some PCMs but not others, the output port mask needs to be changed in order to turn on VPP. And for BDM the init code in the cfg files sets up hardware by pokeing in to registers to configure its state to enable flash access. Just one idea, there is a lot of different things that could come in to play here. Getting running the first time is the hardest bit as unless you have a realtime debugger on the hardware you are flying blind until you get a response back and the hardware is unforgiving and with only limited public documentation. It took me years of trying to my first flash kernel to respond, after that it was not so hard.
True I guess I can do a forever loop? To see if my code is being executed? I'd need to feed the watch dog, which I do know how to do. In theory I should not see any class 2 messages until key off/on
04colyZQ8
Posts: 469
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 »

I give up nothing will allow code execution and pretty sure I am getting neg response when ever I try 36 80, maybe it is not defined the factory never sends that who knows how it knows when to jump to ram or not?
kur4o
Posts: 1044
Joined: Sun Apr 10, 2016 9:20 pm

Re: Colorado / H3 BCM hacking

Post by kur4o »

You can use this as a template, fix ids and clean not needed stuff.

bcm may not allow execute, it may allow but needs specific address to allow execute, This bcm contains flash logic, so nothing is uploaded during flash, only mode ae to enter programming state.

There should be something left on table, but can be figured through a full disassembly.

With script you can use vpw console with avt and mdi tools. It is good to monitor actual bus communication.

When you execute sometimes module doesn`t send anything, sometimes it sends a confirmation and than jumps to code.
You can execute some branch to self infinite loop and watch for bcm crash and reset with some idle data flowing.
Attachments
P10_read_1000_x4_v1.txt
(5.62 KiB) Downloaded 401 times
04colyZQ8
Posts: 469
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: Wed Jul 10, 2024 4:09 am You can use this as a template, fix ids and clean not needed stuff.

bcm may not allow execute, it may allow but needs specific address to allow execute, This bcm contains flash logic, so nothing is uploaded during flash, only mode ae to enter programming state.

There should be something left on table, but can be figured through a full disassembly.

With script you can use vpw console with avt and mdi tools. It is good to monitor actual bus communication.

When you execute sometimes module doesn`t send anything, sometimes it sends a confirmation and than jumps to code.
You can execute some branch to self infinite loop and watch for bcm crash and reset with some idle data flowing.
Ok great do I need to branch to my forever loop? I think I tried a 32 bit pointer instead of of my direct loop. I’m also feeding the watch dog each iteration maybe that’s causing the fast reset? I’m getting a reset after I send the 36 80.

Also I thought you can send the code in 36 00 then send an empty data 36 80 after that doesn’t like that at all!
I did:
6d 40 f0 36 80 00 1e 00 00 00 padded for 1e length
Also did :

6d 40 f0 36 80 00 10… padded zeros
And

6d 40 f0 36 80 00 All zeros

Nothing works, these three at give dreaded general reject code 12

I tried 8000ob2 factory pointer to kernel, and 8001b60 comman factory ram location as well nothing works:(
04colyZQ8
Posts: 469
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 »

If I don’t scratch watch dog then I doubt I’ll get more then 2sec before reset on forever loop?
User avatar
Tazzi
Posts: 3546
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: Colorado / H3 BCM hacking

Post by 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
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
04colyZQ8
Posts: 469
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 »

Tazzi wrote: Wed Jul 10, 2024 10:25 am 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
Post Reply