Colorado / H3 BCM hacking
-
- 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
Oh and I don’t have the vin anymore I fried the millege chip, and that’s were the vin was
Re: Colorado / H3 BCM hacking
6hours!!!!! Holy fucking!!!!!!04colyZQ8 wrote:Hey Guys many , many thanks to Gatecrasher! check this out took 5-6hrs to read out via elm327 but I got the entire flash out!! Sweet!
I did get lazy in the end and padded the last remaining zeros I figured that wasn't so crucial, I also figured 6 hrs was long enough lol
I thought the mode 23 command took a byte or two at the end for requesting the size of data?? Since reading more then 4bytes at a time would certainly speed it up!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
- Gatecrasher
- Posts: 273
- Joined: Sat Apr 25, 2020 6:09 am
Re: Colorado / H3 BCM hacking
These BCMs are hard coded to a max of 16 bytes per mode 35 request. It doesn't support mode 23 at all.
Someone who actually knows what they're doing could probably speed it up. Calling my Python code amateur would be an upgrade from what it currently is.
Someone who actually knows what they're doing could probably speed it up. Calling my Python code amateur would be an upgrade from what it currently is.
-
- 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
This is definitely the full 2004 bcm flash it should be 128k ? I think this is that saize, and looks like it is lined up better, the boot loader in the OS still doesn't make
sense, unless it goes backwards or something? could be a bottom loader?
sense, unless it goes backwards or something? could be a bottom loader?
- Attachments
-
- 2004_BCM_flash_ful.bin
- (64 KiB) Downloaded 63 times
Re: Colorado / H3 BCM hacking
I checked Os checksum and this time it is a match. But still there is something added, since the sps OS file is slightly different at the end.
this line is used with sps file for end line of OS. It is used as a checksum adder to account for the missing 0-17ff boot block.
When OS is flashed the last line becomes. It is some line with p/n and checksum[42cd] in it and the result is 00 is it doesn`t interfere with main checksum.
Last piece to figure is the segmentation mismatch.
this line is used with sps file for end line of OS. It is used as a checksum adder to account for the missing 0-17ff boot block.
Code: Select all
00 00 5a 5b 00 00 00 00 00 00 00 00 00 00 a5 a5
Code: Select all
00 00 00 00 42 CD 00 E7 D5 5C 41 4B 00 00 A5 A5
-
- 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
Ok I found another 2004 bcm, that the eeprom was still intact, so you can compare the ram of this on with the earlier post and see were the copy of the eeprom is stored, it is not exactly the same as the eeprom, but very close!
I also posted an exact read of the eeprom via chip clip.
posted the flash of this bcm, and it can be compared to the previous 04 dump. They have different segments
also posted what I think is the registers ? Some small random code I read.
I have tried addresses from 0 to 10000000 and these are the only files I can find, so this is all the unprotected data!
I also posted an exact read of the eeprom via chip clip.
posted the flash of this bcm, and it can be compared to the previous 04 dump. They have different segments
also posted what I think is the registers ? Some small random code I read.
I have tried addresses from 0 to 10000000 and these are the only files I can find, so this is all the unprotected data!
- Attachments
-
- 2004_bcm_reghister.bin
- (160 Bytes) Downloaded 57 times
-
- 2004_bcm_eeprom_with_chip_clip.bin
- (512 Bytes) Downloaded 59 times
-
- 2004_bcm_ram.bin
- (3.5 KiB) Downloaded 52 times
-
- 2006_bcm_flash_key_locked_bcm.bin
- (64 KiB) Downloaded 49 times
Re: Colorado / H3 BCM hacking
Found some logic in the segment size that is defined in OS. All match except that size is doubled, so it may specify word count than byte count.
For example segment 2 is defined from 4c00-4c9f size is A0. Segment is 140 bytes long or A0*2=140.
Still no clue for the offset, Only some disassembly can give some insights. The only positive is that almost all bcms use the same OS and structure is the same throughout years and some hardcoding of segments will work good enough.
Eeprom seems copied to ram with some slight changes.
For example segment 2 is defined from 4c00-4c9f size is A0. Segment is 140 bytes long or A0*2=140.
Still no clue for the offset, Only some disassembly can give some insights. The only positive is that almost all bcms use the same OS and structure is the same throughout years and some hardcoding of segments will work good enough.
Eeprom seems copied to ram with some slight changes.
Re: Colorado / H3 BCM hacking
Here are some read script. It will read 0-f00000. Adjusting the loop cycles can be used to read different ranges. Changing initial address can done
here
variable:varread:3:0
a change to
:0
to
:100000
will set the initial address to 100000
The x4 version is set to run in high speed mode, so a device that supports it, will be needed.
The log can be saved to a text file and bin file can be parsed from it. logger->action->parse logfile to bin.
The scripts are supposed to work with both 64kb and 128kb bcms.
here
variable:varread:3:0
a change to
:0
to
:100000
will set the initial address to 100000
The x4 version is set to run in high speed mode, so a device that supports it, will be needed.
The log can be saved to a text file and bin file can be parsed from it. logger->action->parse logfile to bin.
The scripts are supposed to work with both 64kb and 128kb bcms.
- Attachments
-
- bcm_read_scripts.rar
- (518 Bytes) Downloaded 65 times
-
- 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
kur4o wrote:Here are some read script. It will read 0-f00000. Adjusting the loop cycles can be used to read different ranges. Changing initial address can done
here
variable:varread:3:0
a change to
:0
to
:100000
will set the initial address to 100000
The x4 version is set to run in high speed mode, so a device that supports it, will be needed.
The log can be saved to a text file and bin file can be parsed from it. logger->action->parse logfile to bin.
The scripts are supposed to work with both 64kb and 128kb bcms.
You’ve tried it on your bcm? Or in theory it works? What program do you feed these scripts into?
Because I’d have to code each line you sent which I can do but it will take time .
-
- 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
kur4o wrote:I checked Os checksum and this time it is a match. But still there is something added, since the sps OS file is slightly different at the end.
this line is used with sps file for end line of OS. It is used as a checksum adder to account for the missing 0-17ff boot block.When OS is flashed the last line becomes. It is some line with p/n and checksum[42cd] in it and the result is 00 is it doesn`t interfere with main checksum.Code: Select all
00 00 5a 5b 00 00 00 00 00 00 00 00 00 00 a5 a5
Last piece to figure is the segmentation mismatch.Code: Select all
00 00 00 00 42 CD 00 E7 D5 5C 41 4B 00 00 A5 A5
Well the boot loader or fall back segment number when flash fails or when bcm is new is
15193436, which pe E7 D5 5C in hex, then 41 is allways used after a part number
So 42 CD would like be the address of the boot leader kernel and 4B might be a check sum
Or a OP code?