E92 PCM Reverse Engineering

Disassembly, Reassembly, Tools and devleopment. Going deep with Hardware and Software.
User avatar
Gatecrasher
Posts: 272
Joined: Sat Apr 25, 2020 6:09 am

Re: E92 PCM Reverse Engineering

Post by Gatecrasher »

Freescale MPC5674
bubba2533
Posts: 498
Joined: Wed Apr 11, 2018 8:50 am
cars: 03 Chevy S10 Turbo V6

Re: E92 PCM Reverse Engineering

Post by bubba2533 »

So I have tested a couple more times and it seems like my NOP infinite loop (Test 7) does in fact stay alive. The only confirmation I have is that the ECU doesn't respond to commands until a key cycle, which I think is sufficient for now.

With my test 9 I wanted to send a message back out on the bus, so I used a function in the boot block. So perhaps because I jumped out of the code in RAM that caused the watchdog to timeout. That's quite interesting, and I will have to replicate those functions to be able to send and receive messages on the bus if I'm unable to jump outside of the kernel.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: E92 PCM Reverse Engineering

Post by kur4o »

Entering mode 34 can disable watchdog and interrupts, otherwise the infinite loop will expire pretty soon and reset the cpu. It may enter some suspend state too, I don`t think it is hard to figure the cop registers and sequence and start tests with them.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: E92 PCM Reverse Engineering

Post by Tazzi »

bubba2533 wrote: Yeah, reading messages into the kernel would be a pretty big milestone, but it would be very time consuming to do with the manual assembly instructions that I’m using now. I would at least like to find a better method for that. If anyone has notes or suggestions on a compiler let me know.
When writing complex code for PPC, I would write the function in C and compile to PPC using something like codewarrior.
The compiler obviously puts all variables into a RAM location it chooses. I pushed the ram addresses into an empty RAM space for the specific CPU I was working with where the kernels do not run, and then appended the custom function to my kernels.
Also needed to make sure all jumps where dynamic and not fixed otherwise jumps needed to be updated to reflect correct locations. I believe I did have to actually change that to dynamic from memory.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
bubba2533
Posts: 498
Joined: Wed Apr 11, 2018 8:50 am
cars: 03 Chevy S10 Turbo V6

Re: E92 PCM Reverse Engineering

Post by bubba2533 »

I'm surprised you didn't write the entire kernel in C and compile it all at once. Was there any specific reason for that?

Another issue I'm seeing is that in the Ghidra disassembly a handful of times b (unconditional branch) instructions are viewed as the end of a function. This causes the decompiled view of the function to break the function decompiled view into multiple functions even though it should be one function. I'm going to download the latest version to see if that fixes anything.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: E92 PCM Reverse Engineering

Post by Tazzi »

bubba2533 wrote:I'm surprised you didn't write the entire kernel in C and compile it all at once. Was there any specific reason for that?

Another issue I'm seeing is that in the Ghidra disassembly a handful of times b (unconditional branch) instructions are viewed as the end of a function. This causes the decompiled view of the function to break the function decompiled view into multiple functions even though it should be one function. I'm going to download the latest version to see if that fixes anything.
Simple because I was unable to get it to understand that I was trying to run the entire code in RAM. I did ask questions on forums about it, but it doesnt appear it was designed to be like that, or at least I couldn't get it to be setup like that.
I ended up finding I could write in assembly pretty fluently after doing it for a few hours anyways. Debugging my own code is alot easier then trying to debug compiled C code since it uses a variety of complex commands, plus uses so many variables and RAM locations which make it really hard to follow.

Which processor option in Ghidra are you using?
Where ever there is a 'branch', this will typically create a new function, I believe you can force it to lump chunks together, Id have to check my notes... although that might of being with IDAPro.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
bubba2533
Posts: 498
Joined: Wed Apr 11, 2018 8:50 am
cars: 03 Chevy S10 Turbo V6

Re: E92 PCM Reverse Engineering

Post by bubba2533 »

Oh ok, that makes sense. That's pretty much where I was at with my Custom OS. It seems like there is too much overhead to figure out and get it working like you want vs. just writing it in asm.

This is processor I'm using.
Image

Yeah it only seems to happen with the "b" branch instruction. It seems that "blr" is the instruction that is used normally, but perhaps "b" is used for non-return functions, so maybe it has a hard time distinguishing between them.

Either way, if you know of a way to override/correct it in Ghidra please let me know.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: E92 PCM Reverse Engineering

Post by Tazzi »

bubba2533 wrote:Oh ok, that makes sense. That's pretty much where I was at with my Custom OS. It seems like there is too much overhead to figure out and get it working like you want vs. just writing it in asm.

This is processor I'm using.
Image

Yeah it only seems to happen with the "b" branch instruction. It seems that "blr" is the instruction that is used normally, but perhaps "b" is used for non-return functions, so maybe it has a hard time distinguishing between them.

Either way, if you know of a way to override/correct it in Ghidra please let me know.
Hmm, I think I did a graph view and just labelled all the functions to help understand it better.

But that right, branch is usually just done to jump to a piece of code, its not usually used for functions to return as that would get complex to keep track of the address it needs to return to. Its just needed to skip over a piece of code that might be in the way.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
bubba2533
Posts: 498
Joined: Wed Apr 11, 2018 8:50 am
cars: 03 Chevy S10 Turbo V6

Re: E92 PCM Reverse Engineering

Post by bubba2533 »

Tazzi wrote: But that right, branch is usually just done to jump to a piece of code, its not usually used for functions to return as that would get complex to keep track of the address it needs to return to. Its just needed to skip over a piece of code that might be in the way.
Ok, this jogged my brain and I discovered another mistake I made in my Kernel Test 9 that I made. I used a "b" instruction instead of a "bl" instruction so it didn't know the correct location to return to. So hopefully I can update that and test it again.

I've also took some more time looking for the SWT references and I still cannot find a single one.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
bubba2533
Posts: 498
Joined: Wed Apr 11, 2018 8:50 am
cars: 03 Chevy S10 Turbo V6

Re: E92 PCM Reverse Engineering

Post by bubba2533 »

Looks like that fixed it! It sends out my message and stays in the infinite loop.
Kernel Test 10.txt
(726 Bytes) Downloaded 67 times
Working Kernel Response Then Loop.PNG
Working Kernel Response Then Loop.PNG (64.68 KiB) Viewed 980 times
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
Post Reply