Colorado / H3 BCM hacking
- Gatecrasher
- Posts: 278
- Joined: Sat Apr 25, 2020 6:09 am
Re: Colorado / H3 BCM hacking
You need to acknowledge receipt of the data by sending back 76 01 78 before the BCM will agree to send more.
Re: Colorado / H3 BCM hacking
Thank you. That worked perfectly.Gatecrasher wrote:You need to acknowledge receipt of the data by sending back 76 01 78 before the BCM will agree to send more.
Re: Colorado / H3 BCM hacking
04colyZQ8 wrote:So clearly pin 11 data out of the rf receiver goes to the processor.. but I tried to trace it and nothing pinged off the processor pins with the multi meter on the 2009 board.
I really want to find what module this goes to see the way the processor receives the key fob remote I have one with a trunk button. I want to get its signal to lock the tailgate!
How does the OS send a signal to the processor to upload data from the registers? Is it first controlled via a MUX, then the data outputted into a register?
Is that the right part in the picture? I thought they used the TDA5211.
-
- 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
bbmike wrote:04colyZQ8 wrote:So clearly pin 11 data out of the rf receiver goes to the processor.. but I tried to trace it and nothing pinged off the processor pins with the multi meter on the 2009 board.
I really want to find what module this goes to see the way the processor receives the key fob remote I have one with a trunk button. I want to get its signal to lock the tailgate!
How does the OS send a signal to the processor to upload data from the registers? Is it first controlled via a MUX, then the data outputted into a register?
Is that the right part in the picture? I thought they used the TDA5211.
right it was wrong idk.. what happened found correct diagram data out on pin 25, goes to GIOB pin on processor!
Dumped GIO Registres while pressing key fob, no real change, compared to not pressing the button.
How can I dump what the processors seeing for this exact pin? I want to see data stream being sent from the rf chip, to the ,main processor?
I want GIO pin[5], the entire register is 200 h so 200/34 (total GIO pins) = 5.8 so 5x pin 5 is 25, so shouldn't GIO[5] be close to address FFF7_BC25 ?
- Gatecrasher
- Posts: 278
- Joined: Sat Apr 25, 2020 6:09 am
Re: Colorado / H3 BCM hacking
That's not how it works. There's a lot of other registers in there. This is from the TMS470R1x. It doesn't match up to the TMS470P. I'm just showing it so you have an idea of what else is would be in that range.
Direction registers, interrupt registers, etc. It's a lot more than just a bunch of on/off bits. That's why it's so frustrating to not have the full TMS470P user's manual.
Besides that, it's going to be some kind of series of data bytes rather than a simple on/off. And it'll be mixed in with the TPMS data. And it'll use a rolling code to help mitigate relay attacks. And....yeah. It's complicated.
Direction registers, interrupt registers, etc. It's a lot more than just a bunch of on/off bits. That's why it's so frustrating to not have the full TMS470P user's manual.
Besides that, it's going to be some kind of series of data bytes rather than a simple on/off. And it'll be mixed in with the TPMS data. And it'll use a rolling code to help mitigate relay attacks. And....yeah. It's complicated.
-
- 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
I see well, it’s likely not to different than the other tms470, just a different offset.
I need to write a few test programs abs upload to ram for sanity check.
Can I simply send a bin file of the assembly language to the same address in ram, that the first chunk
Of kernel is sent to?
Will the system pointer start there, and if a valid inspection is found, execute my code?
I just want to do this : pseudo code ..
Move 104h to register r1
Move r1 to 0x800010
This should write 104 in hex to the start of ram that has the bcm s/n and I can fix that later, just want to see that I can get something to happen.
Or do I have to contend with mr watch dog?
I need to write a few test programs abs upload to ram for sanity check.
Can I simply send a bin file of the assembly language to the same address in ram, that the first chunk
Of kernel is sent to?
Will the system pointer start there, and if a valid inspection is found, execute my code?
I just want to do this : pseudo code ..
Move 104h to register r1
Move r1 to 0x800010
This should write 104 in hex to the start of ram that has the bcm s/n and I can fix that later, just want to see that I can get something to happen.
Or do I have to contend with mr watch dog?
Re: Colorado / H3 BCM hacking
It will be better to test upload and execute mode first [mode 36 80]. That way you will know for sure the code is executed on demand.
For example the code you have seem good for a start, just add a return at the end. The ultimate test will be to make a code that will do some math and store the result to specific address. Than when you read it, you can confirm the code was actually executed.
For example the code you have seem good for a start, just add a return at the end. The ultimate test will be to make a code that will do some math and store the result to specific address. Than when you read it, you can confirm the code was actually executed.
-
- 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, thankskur4o wrote:It will be better to test upload and execute mode first [mode 36 80]. That way you will know for sure the code is executed on demand.
For example the code you have seem good for a start, just add a return at the end. The ultimate test will be to make a code that will do some math and store the result to specific address. Than when you read it, you can confirm the code was actually executed.
made a huge discovery last night! found the watchdog
void Watchdog_Scratch_loop(void)
{
undefined *Watchdog_DWKEY_PTR;
Watchdog_DWKEY_PTR = PTR_DWKEY_CPU_Location_fffff_....;
*(undefined4 *)PTR_DWKEY_CPU_Location_fffff_.... = Watch_dog_DWD;
*(undefined4 *)Watchdog_DWKEY_PTR = Watch_dog_DW_KEY;
CLS2_MODE_76_msg_wrapper();
return;
}
-
- 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
What do I put as a return address?kur4o wrote:It will be better to test upload and execute mode first [mode 36 80]. That way you will know for sure the code is executed on demand.
For example the code you have seem good for a start, just add a return at the end. The ultimate test will be to make a code that will do some math and store the result to specific address. Than when you read it, you can confirm the code was actually executed.
Ok great what’s a sample 36 80 line of code,
I still don’t understand the entire format ..
6C 40 F0 36 00 01 08 00 00 00 my co de is (16 bit checksum goes here)
So if I send 8 bits or 1 byte, that’s the part right after 36 right? Then the bcm address ram 800000, but how many leading zeros? Then my code, then a block checksum? How to calculate the checksum?
Do you have a 36 80 example?
Re: Colorado / H3 BCM hacking
6C 40 F0 36 00 01 08 00 00 00
6C 40 F0 36 80 01 08 00 00 00 ...data...[block checksum]
If you are unsure how to calculate block checksum. Post the message you want to send and I will fix it for you.
6C 40 F0 36 80 01 08 00 00 00 ...data...[block checksum]
If you are unsure how to calculate block checksum. Post the message you want to send and I will fix it for you.