Colorado / H3 BCM hacking

[kur4o]

Can`t we just borrow some code from disassembly that copy data from location x to location y and exits, I am sure there will be some examples in it, unless all the variables are stacked to hell.

Some sps session log will be very good for a start.

[antus]

It's ARM7TDMI, big endian.

I absolutely hate it. The disassembled code is a clusterfuck.

Are you talking ghidra or hexrays? Hexrays is a much more advanced decompiler. Ghidra really just represents the flow of the code in C structures. Hexrays goes further and can see and represent more complicated code in a more simple flows. You need at least an ida home license to get arm support and decompiler, though.

[Gatecrasher]

I was talking about Ghidra. I know the decompiler has significant limits, but even the regular disassembly is a mess. It's an endless pile of nested references to RAM addresses, and bit shifts on top of bit shifts.

I can't even get a straight answer on the fog light function. You'd think that would be as simple as can be. Monitor the GPIO bit for the switch input, see if the option is enabled in the calibration, check for faults, and if everything is good, flip the GPIO bit for the relay. But it's just a giant pile of spaghetti.

[04colyZQ8]

It's ARM7TDMI, big endian.

I absolutely hate it. The disassembled code is a clusterfuck.

I agree!!

Can't get the older one to disassemble not sure what it is I think it's little endian though?

The newer one does disassemble nicely but, it is as you say a cluster bleep lol

[04colyZQ8]

So on the 2011 bcm This is of interest, FFF7D000h is the base address up to FFF7D0FFh for the (class 2 module), this must be where the vpw commands to and from are handled, because there is not an external DLC chip, the function bellow is likely linked to an array or matrix of outgoing vpw messages, and the incoming messages will come in another function. So there are only the pins for class 2, and likely only one that is used, so how come we have a large range from 0 to FF? that's 255 different addresses right? For just one chip? Or does it act as a single 8 bit register and each byte, can be individually accessed? I hace a C - code to arm7 TMS470 compiler, I can write a program upload to ram, and change the bas pointer to my program in ram.. in theory.. Ideally I would find a way to dump the class 2 registers to see what is sent to it when a vpw msg is sent.

In order to disassemble the gm kernel, we need to see it as it would be uploaded in ram, because the kernel is slit up, not in order, and has the address in ram that it is to be uploaded to, etc. mixed into it. So when you try a disassembly of the utility files you just get garbage.

Who thinks this might work.. change a bit to have an incorrect checksum on segment 06, program with sps, should fail at 98% or so. leave key on, run a script using mode 35 and dump the ram? In theory the gm kernel would still be in the ram? Or does it clear the ram when the gm program sends it's closing msg?


LAB_0000cd20 XREF[1]: 000040a4 (j)
0000cd20 e9 2d 5f ff stmdb sp!,{r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12
0000cd24 e5 9f 44 30 ldr r4,[DAT_0000d15c ] = 0800070Ch
0000cd28 e3 a0 80 00 mov r8,#0x0
0000cd2c e5 c4 80 09 strb r8,[r4,#0x9 ]=>DAT_08000715
0000cd30 e5 9f c4 28 ldr r12 ,[DAT_0000d160 ] = 08000BC5h
0000cd34 e5 dc c0 00 ldrb r12 ,[r12 ,#0x0 ]=>DAT_08000bc5
0000cd38 e5 9f 54 18 ldr r5,[DAT_0000d158 ] = FFF7D000h // this is the class 2 register base address
0000cd3c e3 5c 00 01 cmp r12 ,#0x1
0000cd40 1a 00 00 08 bne LAB_0000cd68
0000cd44 e5 d5 c0 06 ldrb r12 ,[r5,#offset DAT_fff7d006 ]
0000cd48 e2 0c c0 fe and r12 ,r12 ,#0xfe
0000cd4c e5 c5 c0 06 strb r12 ,[r5,#offset DAT_fff7d006 ]
0000cd50 e5 d5 c0 12 ldrb r12 ,[r5,#offset DAT_fff7d012 ]
0000cd54 e1 b0 cf 8c movs r12 ,r12 , lsl #0x1f
0000cd58 13 a0 00 01 movne r0,#0x1
0000cd5c 15 9f c4 00 ldrne r12 ,[DAT_0000d164 ] = 08001F0Bh
0000cd60 15 cc 00 00 strbne r0,[r12 ,#0x0 ]
0000cd64 1b 00 1f 69 blne FUN_00014b10 undefined FUN_00014b10()
LAB_0000cd68 XREF[1]: 0000cd40 (j)
0000cd68 e3 a0 a0 01 mov r10 ,#0x1
0000cd6c e5 d4 c0 02 ldrb r12 ,[r4,#0x2 ]=>DAT_0800070e
0000cd70 e3 5c 00 00 cmp r12 ,#0x0
0000cd74 05 c4 a0 02 strbeq r10 ,[r4,#0x2 ]
0000cd78 e1 d5 c1 b2 ldrh r12 ,[r5,#offset DAT_fff7d012 ]
0000cd7c e1 d5 00 be ldrh r0,[r5,#offset DAT_fff7d00e ]
0000cd80 e0 00 90 0c and r9,r0,r12
0000cd84 e5 9f 63 dc ldr r6,[DAT_0000d168 ] = 0800070Bh
0000cd88 e5 d6 c0 00 ldrb r12 ,[r6,#0x0 ]=>DAT_0800070b
0000cd8c e3 19 00 04 tst r9,#0x4
0000cd90 0a 00 00 1b beq LAB_0000ce04
0000cd94 e5 95 00 18 ldr r0,[r5,#offset DAT_fff7d018 ]
0000cd98 e3 5c 00 00 cmp r12 ,#0x0
0000cd9c 12 4c c0 01 subne r12 ,r12 ,#0x1
0000cda0 12 0c c0 ff andne r12 ,r12 ,#0xff
0000cda4 e3 d0 1c 01 bics r1,r0,#0x100
0000cda8 1a 00 00 13 bne LAB_0000cdfc
0000cdac e3 5c 00 04 cmp r12 ,#0x4
0000cdb0 ba 00 00 11 blt LAB_0000cdfc
0000cdb4 e5 d4 10 04 ldrb r1,[r4,#0x4 ]=>DAT_08000710
0000cdb8 e1 a0 22 01 mov r2,r1, lsl #0x4
0000cdbc e0 82 11 01 add r1,r2,r1, lsl #0x2
0000cdc0 e0 81 10 04 add r1,r1,r4
0000cdc4 e5 c1 c0 10 strb r12 ,[r1,#0x10 ]
0000cdc8 e5 d4 c0 04 ldrb r12 ,[r4,#0x4 ]=>DAT_08000710
0000cdcc e1 a0 12 0c mov r1,r12 , lsl #0x4
0000cdd0 e0 81 c1 0c add r12 ,r1,r12 , lsl #0x2
0000cdd4 e0 8c c0 04 add r12 ,r12 ,r4
0000cdd8 e5 8c 00 14 str r0,[r12 ,#0x14 ]
0000cddc e5 d4 c0 04 ldrb r12 ,[r4,#0x4 ]=>DAT_08000710
0000cde0 e2 8c c0 01 add r12 ,r12 ,#0x1
0000cde4 e2 0c c0 ff and r12 ,r12 ,#0xff
0000cde8 e3 5c 00 05 cmp r12 ,#0x5
0000cdec a1 a0 c0 08 cpyge r12 ,r8
0000cdf0 e5 d4 00 08 ldrb r0,[r4,#0x8 ]=>DAT_08000714
0000cdf4 e1 5c 00 00 cmp r12 ,r0
0000cdf8 15 c4 c0 04 strbne r12 ,[r4,#0x4 ]
LAB_0000cdfc XREF[2]: 0000cda8 (j) , 0000cdb0 (j)
0000cdfc e5 c6 80 00 strb r8,[r6,#0x0 ]=>DAT_0800070b
0000ce00 e1 a0 c0 08 cpy r12 ,r8
LAB_0000ce04 XREF[1]: 0000cd90 (j)
0000ce04 e5 9f 02 84 ldr r0,[DAT_0000d090 ] = 08000838h
0000ce08 e5 d0 00 00 ldrb r0,[r0,#0x0 ]=>DAT_08000838
0000ce0c e1 a0 03 a0 mov r0,r0, lsr #0x7
0000ce10 e5 9f 72 58 ldr r7,[DAT_0000d070 ] = 08000850h
0000ce14 e3 19 00 80 tst r9,#0x80
0000ce18 0a 00 00 0c beq LAB_0000ce50
0000ce1c e3 a0 10 80 mov r1,#0x80
0000ce20 e1 c5 11 b2 strh r1,[r5,#offset DAT_fff7d012 ]
0000ce24 e3 50 00 00 cmp r0,#0x0
0000ce28 0a 00 00 08 beq LAB_0000ce50
0000ce2c e5 c4 a0 00 strb r10 ,[r4,#0x0 ]=>DAT_0800070c
0000ce30 e5 d7 c0 09 ldrb r12 ,[r7,#0x9 ]=>DAT_08000859
0000ce34 e5 c4 c0 0c strb r12 ,[r4,#0xc ]=>DAT_08000718
0000ce38 e5 d7 c0 0b ldrb r12 ,[r7,#0xb ]=>DAT_0800085b
0000ce3c e5 c4 c0 0d strb r12 ,[r4,#0xd ]=>DAT_08000719
0000ce40 e5 d7 c0 0c ldrb r12 ,[r7,#0xc ]=>DAT_0800085c
0000ce44 e5 c4 c0 0e strb r12 ,[r4,#0xe ]=>DAT_0800071a
0000ce48 eb 00 1f a1 bl thunk_FUN_0000ccdc undefined thunk_FUN_0000ccdc()
0000ce4c e5 d6 c0 00 ldrb r12 ,[r6,#0x0 ]=>DAT_0800070b

[antus]

Typically a VPW DLC has a few registers, and they are used for IO and control, not as memory. eg 08001F0B comes up a lot in your code, thats probably one of the registers. None of the ecus ive seen so far have an external vpw chip, they have an MC68HC58 baked on the same silicon as the cpu (as well as other harware). This is a later system than what I know, but still being vpw its somewhat likely that they used the MC57HC58 again, but the registers are mapped at different locations.

[Gatecrasher]

I don't know if the older chip is even ARM architecture. The only thing I know for sure is it's made by TI. I found an old product change notice that had the part number included in a long list. The notice only referred to how they mark the chip housings (they changed from ink to laser marking), so there's nothing that helps us ID what it actually is. I went back into the wayback machine and looked at TI product lists from the early 2000s, and they were only selling MSP430 and TMS320 at the time. The code doesn't disassemble properly under either of those models. It's something custom for GM, but I've hit a dead end trying to identify the architecture.

The register space for class 2 and everything else includes a lot of control registers. The Rx/Tx registers are a very small part of it. That's where my frustration comes from. TI doesn't have the TMS470 Platform Architecture reference manual any more, and the registers don't line up with the TMS470 R1 Architecture. So all you can do is make educated guesses.

I've found two big class 2 message tables, but there's a ton of extra data in them. I can't figure out what all the extra bytes do because I can't figure out what all the RAM addresses refer to. Even something as simple as building the VIN packets or reading out a part number is a complicated mess.

[kur4o]

The easiest way is to log a sps session with another tool hooked on the line. Universal patcher have a nice feature to auto switch to x4 mode wjile logging bus.

Did you trace the class2 pin to processor. It is possible dlc is built in the processor. It is very unlikely it is cpu driven, because of timing and interrupts. Do you have the sps files, I can try to make a full version of data that is uploaded and at what address.

[Gatecrasher]

At a glance, the SPS files don't have address information for the calibration segments. It's all handled in the kernel somehow. And there's no way to disassemble that without knowing what language the old chip uses.

Speaking of the old chip, I'm almost convinced it's some kind of 16 bit architecture. I got really lucky and stumbled on the pointers for the class 2 handlers. This is how it's represented on the 32 bit Arm7 TMS470:

Code: Select all

22 00 00 00 //Mode 22
00 00 6d 17 //Routine
25 00 00 00 //Mode 25
00 00 6c f5 //Routine
27 00 00 00 //Mode 27
00 00 6b f1 //Routine

And this is how it's represented on the older F16E.

Code: Select all

00 22 //Mode 22
a3 3a //Routine
00 25 //Mode 25
af c3 //Routine
00 27 //Mode 27
93 e8 //Routine

Also, the data at 0x0 on the F16E looks like 16 bit vector addresses instead of 32-bit addresses or 32-bit jump instructions like the TMS470 has.

Code: Select all

0x00 44 03 
0x02 44 07 
0x04 44 09 
0x06 44 0d 
0x08 44 13 
0x0A 44 17 

It's really weird that they hit on odd-numbered addresses, and those addresses don't fall neatly into the range of the 'full' dump Coly posted, which makes me think there's some kind of memory mapping going on. This onion has a whole lot of layers. And some of them stink.

[04colyZQ8]

At a glance, the SPS files don't have address information for the calibration segments. It's all handled in the kernel somehow. And there's no way to disassemble that without knowing what language the old chip uses.

Speaking of the old chip, I'm almost convinced it's some kind of 16 bit architecture. I got really lucky and stumbled on the pointers for the class 2 handlers. This is how it's represented on the 32 bit Arm7 TMS470:

Code: Select all

22 00 00 00 //Mode 22
00 00 6d 17 //Routine
25 00 00 00 //Mode 25
00 00 6c f5 //Routine
27 00 00 00 //Mode 27
00 00 6b f1 //Routine

And this is how it's represented on the older F16E.

Code: Select all

00 22 //Mode 22
a3 3a //Routine
00 25 //Mode 25
af c3 //Routine
00 27 //Mode 27
93 e8 //Routine

Also, the data at 0x0 on the F16E looks like 16 bit vector addresses instead of 32-bit addresses or 32-bit jump instructions like the TMS470 has.

Code: Select all

0x00 44 03 
0x02 44 07 
0x04 44 09 
0x06 44 0d 
0x08 44 13 
0x0A 44 17 

It's really weird that they hit on odd-numbered addresses, and those addresses don't fall neatly into the range of the 'full' dump Coly posted, which makes me think there's some kind of memory mapping going on. This onion has a whole lot of layers. And some of them stink.

That’s pretty interesting!

I attempted a corrupt flash and it crashed at 99%, then I tried to read the ram but it wouldn’t give security access!! 27 02 C6 59 22
Was the response from sending the correct key
At step 27 02 C6 59

Anyway than I sent in just the utility file using dps, and read the ram,

But do not see the gm kernel so it cleared out of of ram already.

The address for loading the kernel in the 2011 bcm is:

B0 82 i think?