E92 PCM Reverse Engineering

Disassembly, Reassembly, Tools and devleopment. Going deep with Hardware and Software.
User avatar
Posts: 2974
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: E92 PCM Reverse Engineering

Postby Tazzi » Mon Sep 12, 2022 9:44 am

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
Site:www.envyouscustoms.com
Mob:+61406 140 726
Image

Posts: 74
Joined: Sun May 11, 2014 6:36 pm

Re: E92 PCM Reverse Engineering

Postby Highlander » Tue Sep 13, 2022 10:28 am

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.

Posts: 567
Joined: Sun Apr 10, 2016 9:20 pm

Re: E92 PCM Reverse Engineering

Postby kur4o » Mon Sep 19, 2022 6:31 pm

Gatecrasher wrote:
r13 = 40008000
r14 = 40018000
r15 = 40028000



Do you happen to know the r2 = ???

Online
Posts: 110
Joined: Sat Apr 25, 2020 6:09 am

Re: E92 PCM Reverse Engineering

Postby Gatecrasher » Tue Sep 20, 2022 12:01 am

R2 is dynamic. It's used as a working register and changes depending on whatever the code is doing.

Posts: 352
Joined: Wed Apr 11, 2018 8:50 am

Re: E92 PCM Reverse Engineering

Postby bubba2533 » Thu Sep 22, 2022 3:07 am

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: If you have Questions about the current release post Here. If you have feature suggestions post in the Development Thread

User avatar
Posts: 2974
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: E92 PCM Reverse Engineering

Postby Tazzi » Thu Sep 22, 2022 5:29 pm

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
Site:www.envyouscustoms.com
Mob:+61406 140 726
Image

Online
Posts: 110
Joined: Sat Apr 25, 2020 6:09 am

Re: E92 PCM Reverse Engineering

Postby Gatecrasher » Wed Sep 28, 2022 1:52 pm

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.

Online
Posts: 110
Joined: Sat Apr 25, 2020 6:09 am

Re: E92 PCM Reverse Engineering

Postby Gatecrasher » Sat Oct 01, 2022 10:23 am

rchw.png
rchw.png (24.67 KiB) Viewed 25 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.

Previous

Return to Engineering and Reverse Engineering

Who is online

Users browsing this forum: No registered users and 1 guest