E92 PCM Reverse Engineering

Disassembly, Reassembly, Tools and devleopment. Going deep with Hardware and Software.
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 mapped the FlexCAN memory locations and there are references to both A & B modules. I'm under the assumption that overriding any locations in RAM won't matter as there will be a reset when exiting the kernel.

The SWT memory range (0xFFF38000 - 0xFFF3BFFF) doesn't have any references at all. I even searched in memory for "FF F3" and still couldn't find anything valuable. This doesn't make me very confident that this is the correct reference manual. I was thinking maybe there is some code that wasn't disassembled so that's why I searched for ""FF F3", but I'm lost at the moment so maybe I should take a break and come back to it.

Also I found this online tool which has helped convert back and forth between hex and ASM. https://disasm.pro/

And I found a reference for the instructions that includes instruction encoding. https://wiki.alcf.anl.gov/images/f/fb/P ... nt_2.3.pdf
They could be using a base address minus an offset or something along those lines, so it might not show up directly.
You would do better searching for the sequence keys since they HAVE to be entered exactly like that: 0xA602 followed by 0xB480 or 0xC520 followed by 0xD928
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
Highlander
Posts: 81
Joined: Sun May 11, 2014 6:36 pm
cars: Z06

Re: E92 PCM Reverse Engineering

Post by Highlander »

Tazzi wrote:
bubba2533 wrote:
Tazzi wrote: If you need help understand the canbus, more then happy to break it down.
I think I'm getting it now, but I'm sure there will be more questions I have.
Tazzi wrote: But PPC with VLE is alot harder to follow/decode then Motorola as used with the P01/P59 ecus. I spent quite a few months going through examples, simulators and even uploading commands in a basic custom kernel to work out what specific opcodes were doing. VLE is still new to me, the commands themselves are basic but doesnt seem to decompile nicely sometimes.
This is definingly something I'm struggling with as well. If you have any resources please post them up. I'm relying so much on the decompile window that if it did something incorrect I don't think I would notice it.
Biggest thing for me was understanding common op codes like rlwinm (Rotate Left Word Immediate then AND with Mask), since this was used everywhere and cause massive headache. I did have a great link I use to reference too which broke down the commands nicely, but I cant seem to see it in my bookmarks.
IBM has great examples though: https://www.ibm.com/docs/en/aix/7.1?top ... nstruction

Code: Select all

he following code rotates the contents of GPR 4 to the left by 2 bits and logically ANDs the result with a mask of 29 ones:
# Assume GPR 4 contains 0x9000 3000.
# Assume GPR 6 contains 0xFFFF FFFF.
rlwinm 6,4,2,0,0x1D
# GPR 6 now contains 0x4000 C000.
# Under the same conditions
# rlwinm 6,4,2,0xFFFFFFFC
# will produce the same result.
So it ends up looking like this: GP6 = (GP4<<2) && (0x1D).
Keeping in mind that the registers will wrap around when shifting, so bit 31 (counting from 0) will then move back to bit0 location is shifting by 1.

Next thing thing that blew my mind, is the data is stared in big ed format. This honestly kept breaking my head without examples. If you had the example of say, 0xC7, which in binary is 0x11000111. If you wanted to remove the lowest two bits, you would need to && this with a mask of 0 to 29 (0x3FFF FFFF), as this will have bits 30 and 31 as zero. Thus end result would be 0x11000100= C4.

My E38 thread.. is a chronical of a man slowly going mad working the above bullshit out.
This command has been the most difficult to understand. I think i got the hang of it. I need to run via the bdm setup and single step it to actually be 100% sure.
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: E92 PCM Reverse Engineering

Post by kur4o »

Gatecrasher wrote:
r13 = 40008000
r14 = 40018000
r15 = 40028000
Do you happen to know the r2 = ???
User avatar
Gatecrasher
Posts: 272
Joined: Sat Apr 25, 2020 6:09 am

Re: E92 PCM Reverse Engineering

Post by Gatecrasher »

R2 is dynamic. It's used as a working register and changes depending on whatever the code is doing.
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: They could be using a base address minus an offset or something along those lines, so it might not show up directly.
You would do better searching for the sequence keys since they HAVE to be entered exactly like that: 0xA602 followed by 0xB480 or 0xC520 followed by 0xD928
I haven't been able to find any of these magic numbers in the disassembly, so that's a big roadblock for me. I know it has to be in there somewhere, but it's proven a little difficult to find.

I was thinking of getting SPS and doing a flash while logging with a logic analyzer to see what I can find, but I have never used SPS or any other GM tool for that matter.
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 haven't been able to find any of these magic numbers in the disassembly, so that's a big roadblock for me. I know it has to be in there somewhere, but it's proven a little difficult to find.

I was thinking of getting SPS and doing a flash while logging with a logic analyzer to see what I can find, but I have never used SPS or any other GM tool for that matter.
It could be saving these bytes to a separate location and then just referencing them maybe? Might need to double check I didn't screw up with those values from the reference manual. Those value do show up in the bin when just searching the bin directly with a hex editor, but haven't checked to see where they end up in the decompiled format.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Gatecrasher
Posts: 272
Joined: Sat Apr 25, 2020 6:09 am

Re: E92 PCM Reverse Engineering

Post by Gatecrasher »

I decided to go looking for the watchdog service routine. I couldn't find it either. But I did find this in the reference manual:
Watchdog Service Code.This field is used to service the watchdog and to clear the soft lock bit
(SWT_MCR[SLK]). If the SWT_MCR[KEY] bit is set, two pseudorandom key values are written to service
the watchdog, see section Section 17.4, “Functional Description”, for details. Otherwise, the sequence
0xA602 followed by 0xB480 is written to the WSC field. To clear the soft lock bit (SWT_MCR[SLK]), the value
0xC520 followed by 0xD928 is written to the WSC field.
So maybe this thing is using the pseudorandom key to feed the watchdog, and that's why the static sequences don't seem to show up in the disassembly.

For whatever it's worth, the MPC5644A in the chassis control module I disassembled has the SWT in the same location. I can't find the service routine in that code either.
User avatar
Gatecrasher
Posts: 272
Joined: Sat Apr 25, 2020 6:09 am

Re: E92 PCM Reverse Engineering

Post by Gatecrasher »

rchw.png
rchw.png (24.67 KiB) Viewed 1334 times
If I'm reading this right, both the core watchdog (WTE) and the software watchdog (SWT) are disabled entirely. The first two bytes in the ECM code are 00 5A. Maybe watchdog functionality is left entirely to the slave CPU?

The chassis module is set up the same way. It doesn't have a secondary CPU, but I haven't looked to see if it has some kind of hardware watchdog chip.
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 »

Gatecrasher wrote:
rchw.png
If I'm reading this right, both the core watchdog (WTE) and the software watchdog (SWT) are disabled entirely. The first two bytes in the ECM code are 00 5A. Maybe watchdog functionality is left entirely to the slave CPU?

The chassis module is set up the same way. It doesn't have a secondary CPU, but I haven't looked to see if it has some kind of hardware watchdog chip.
Weird, Iv never seen an OS intentionally disable the watchdog timers!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: E92 PCM Reverse Engineering

Post by antus »

it might restart them after boot. its likely watchdog isnt running in the boot recovery mode (if there is one). logic for that might be that if the boot code fails you have a brick, watchdog isnt going to help, and maybe even watchdog will cause problems due to an external factor like something connected to an interupt line stuck high. The main OS might turn them back on after an initial setup, after the boot code is finished. Just because it turns them off, doesnt mean it stays that way for operation. I have nothing to back any of this up, its just a thought and a reason to keep an open mind.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Post Reply