07-2013 GM BCM

[Tazzi]

gmtech825, what processor are you selecting in Ghidra? When I tried using one of the RSIC options (For fujitsu), it wasnt disassembling nicely. Well that was on irondukes file he uploaded with all cals implemented.

[ironduke]

So is this possible some sort of scaler that was mentioned earlier??

Btw, loving this discussion, showing me how much I am lacking... lol..

yeah exactly. I found one value that looks very interesting. It is 0x0A in the calibration, then is multiplied by 0x14, then divided by 0x14...so essentially it is still 0x0A = 10.

that value (10) gets moved to a ram location, then compared to see if it is <= to another ram value which is incremented by 1 (engine run timer maybe) and seems to trace back to my original function that checks the remote start enable byte.

it requires way more investigation...or maybe I'll change that value and see what happens when I finally get some time.

I'll probably have a little time this weekend, I didn't end up with a brick yet so I'll volunteer to try 01 if you can tell me which one to try? or where? or which calibration, lol...

[gmtech825]

I'll probably have a little time this weekend, I didn't end up with a brick yet so I'll volunteer to try 01 if you can tell me which one to try? or where? or which calibration, lol...

that byte was in the system segment. I gave it shot last night but no luck...I feel like I'm getting close though. I'm only writing the cal segments not the OS so hopefully that reduces the risk of bricking.

gmtech825, what processor are you selecting in Ghidra? When I tried using one of the RSIC options (For fujitsu), it wasnt disassembling nicely. Well that was on irondukes file he uploaded with all cals implemented.

someone created a fujitsu processor module that I found. it does have some errors so that might be part of my problem. My file is set up basically the same as irondukes. I have 0xff in the empty areas where ironduke has 0x00.
here is an error thrown related to the function that calls the remote start enable byte in the system segment.

Code: Select all

void UndefinedFunction_000c49be(void)

{
  int in_r13;
  
                    /* WARNING: Could not recover jumptable at 0x000c49c6. Too many branches */
                    /* WARNING: Treating indirect jump as call */
  (*(code *)(&switchD_000c49c6::switchdataD_000fa390)[in_r13])();
  return;
}

[Tazzi]

Oh odd, looks like it was running into a switch statement based on that text.

Maybe do a screen shot of the assembly view in graph mode. It could just be the C code representation is unable to interpret.

[gmtech825]

heres the screenshot

[Tazzi]

Ahhh I see, it’s pull the value from ah address, so ghidra can’t determine where exactly it might jump for the case statement.

Would need to see what’s being saved at that address and follow from there.

[gmtech825]

at 000fa390? that value is 000c49c8...sorry I'm still lost

[gmtech825]

here is how it shows up in IDA

[Tazzi]

Ill need to read the opcode definitions to understand better.

But it looks like it loads the value FA390 into r12, shifts r13 left by 2 (we do not know the value of r13) then loads data from address (r13+r12) into r12
Then it jumps to the address saved at location r12.

Its a bit of a roundabout way of doing it all. Im pretty sure the '@' sign is being used as a pointer. Meaning you need to look at the address that is saved in that register.

[gmtech825]

Ill need to read the opcode definitions to understand better.

But it looks like it loads the value FA390 into r12, shifts r13 left by 2 (we do not know the value of r13) then loads data from address (r13+r12) into r12
Then it jumps to the address saved at location r12.

Its a bit of a roundabout way of doing it all. Im pretty sure the '@' sign is being used as a pointer. Meaning you need to look at the address that is saved in that register.

oof...there's a whole lot of jumping around for sure.