MSS60 Research

[tdott]

Locked MSS60 came in.

BTW this DME was built in April 2008.

if its an 08, I thought they weren't locked until later years?

[dpaul]

So that confirms it, the BDM lock is indeed exerted through censored mode.

This should be fixable.

.

Awesome

[terra]

Locked MSS60 came in. Flashed my RSA delete to it along with the patch to read registers.

Injection UC3FMCR is: 43 FF 00 FF (01000011 11111111 00000000 11111111)
Ignition UC3FMCR is: 41 FF 00 FF (same as both CPUs on MSS65 and equivalent to factory state)

That Injection register translates to
ACCESS = 0
FIC = 0
CENSOR[0:1] = 11

So that confirms it, the BDM lock is indeed exerted through censored mode.

This should be fixable.

BTW this DME was built in April 2008, part number is 7841981 / 5WK9588 My unlocked dump was from a 7841364 / 5WK9586. 7841102 / 5WK9584 is likely also unlocked.

7840872 is unknown. I assume that's 5WK9587, though I can't actually find a pic of a DME with that part number.

Everything else will almost certainly be locked.

[dpaul]

Excuse this likely stupid question but are you sure you are reading shadow memory, where this register is supposed to be? I thought that normal array is accessed when the SIE register bit in the UC3FMCR = 0. To read the shadow memory, SIE is supposed to be set to =1.

EDIT: I see, you read from the MSS65, not the MSS60. Sorry!

EDIT 2: OK, I guess this is a very confusing issue for me - how to actually read shadow memory

[terra]

Okay so I figured out how to modify the DME program to allow me to dump all the CPU registers (rather than the select few BMW allowed). That might be useful in the event that we unlock the CPU and have to rewrite registers (minus the censor values).

In any case, on my MSS65, this is the UC3FMCR register:

41 FF 00 FF
or in binary:

01000001 11111111 00000000 11111111)

Here's the bit definitions:



And these are the definitions for the censor registers speciically:



So going back to the registers I dumped (01000001 11111111 00000000 11111111)

So according to that, the MSS65 is set to
ACCESS = 0
FIC = 0
CENSOR[0:1] = 01

Put together that's no censorship, which is consistent with behavior that we see.

So when my (probably locked) MSS60 arrives, I will do the same mod to it and read the registers. If that shows the censor bits as being set, then that tells us that is most likely what the issue is and should be fixable with the right debugger

Per that NXP GM driver document:



So while it sounds like we'd have to go to 00 and then to 01/10 (if it's not already 00), it sounds like it is indeed possible.

[terra]

Yeah I can't say I have a huge amount of experience there nor do I have the hardware on hand (unless they are relatively common things that can be salvaged from other ancient electronics).

Last time I messed with anything similar was for the parallel port BDM interface for the MSS54. Which looks similar on the surface, but seems to be fairly different. For that, I ended up getting a PCI-expresses parallel port card and then using Windows 95 in a virtual machine to do what I needed to do. I imagine I could do a similar thing with Linux... but setting up Linux crap in 2002 was even more painful than the modern iterations

[dpaul]

So I started going down a rabbit hole of archived internet pages and now-dead projects, and this seems interesting:
https://web.archive.org/web/20110914...ftware/mpcbdm/

That project is built for the MPC8xx, but given the 5xx uses the same protocol, that might be fine. Might just have to edit the source a bit to look for the 5xx PVRs and whatnot.
And they have this diagram for a parallel port interface, which I think I could build without too much difficulty:
https://web.archive.org/web/20051025...pcbdm/VDB2.gif

Might be sufficient to run that uncensor s19 file..

That was a deep dive!

I think the MPC5xx is a direct descendent of the MPC8xx so this approach seems promising. The hardware seems pretty simple. So it probably comes down to the software these guys wrote. I wish I could help but I don't have a pile of components to draw on for the hardware and have neither a linux installation nor much experience so getting set up would be a big learning project..

I hope you are able to go forward with this!

[terra]

Can't find much in the way of documentation for the ESL/Windriver products.

And it's not clear that BDI2000 supports MPC5xx although it looks like BDI3000 does However, Abatron is out of business, their hardware probably needs the Abatron software, and those devices are not exactly cheap on Ebay.
Sigh.....

Maybe it's worth trying to achieve a higher level of authorization for full read/write access via OBDII, even if it hasn't been that useful for you with other DMEs? Either bypassing authentication or factoring the public keys, which as you've pointed out, is computationally feasible.
.

So I started going down a rabbit hole of archived internet pages and now-dead projects, and this seems interesting:
https://web.archive.org/web/20110914...ftware/mpcbdm/

That project is built for the MPC8xx, but given the 5xx uses the same protocol, that might be fine. Might just have to edit the source a bit to look for the 5xx PVRs and whatnot.
And they have this diagram for a parallel port interface, which I think I could build without too much difficulty:
https://web.archive.org/web/20051025...pcbdm/VDB2.gif

Might be sufficient to run that uncensor s19 file..

[terra]

Would a BDM read from an early non locked car be any use?

I already have one. I flashed that to my MSS65 and have been using that to do the MSS60 testing.

I also got a full read from a locked MSS60 that was never updated past 80E (so the rumor of the lock being implemented around 140E is false). The boot sector is identical to the full dump from the unlocked DME. So it's nothing in the flash memory itself enforcing the lock. It's a register, shadow memory, or something along those lines.

[Martyn]

Would a BDM read from an early non locked car be any use?

[terra]

Can't find much in the way of documentation for the ESL/Windriver products.

And it's not clear that BDI2000 supports MPC5xx although it looks like BDI3000 does However, Abatron is out of business, their hardware probably needs the Abatron software, and those devices are not exactly cheap on Ebay.
Sigh.....

Maybe it's worth trying to achieve a higher level of authorization for full read/write access via OBDII, even if it hasn't been that useful for you with other DMEs? Either bypassing authentication or factoring the public keys, which as you've pointed out, is computationally feasible.
.

Yeah the PEMicro might be the safest option. I wish I had a better understanding of the BDM protocol. It's probably not *that* hard to just upload an s19 with consumer grade hardware. We don't really need the full debugging support that all these fancy tools provide.

I'll look into the higher level of authorization. Following the disassembly on these MSS6x DMEs is a bit of a pain compared to others.

[dpaul]

Needs a parallel port, but maybe this could work? https://www.artisantg.com/info/ATGmmnka.pdf

Seems like there's quite a few pretty cheap on eBay. Just gotta figure out what the software situation is

Edit: Now that I look closer, only one is specifically listed for the 5xx/8xx

BDI2000 also seems to be an option if CodeWarrior can interface directly with it.

Can't find much in the way of documentation for the ESL/Windriver products.

And it's not clear that BDI2000 supports MPC5xx although it looks like BDI3000 does However, Abatron is out of business, their hardware probably needs the Abatron software, and those devices are not exactly cheap on Ebay.
Sigh.....

Maybe it's worth trying to achieve a higher level of authorization for full read/write access via OBDII, even if it hasn't been that useful for you with other DMEs? Either bypassing authentication or factoring the public keys, which as you've pointed out, is computationally feasible.
.

[terra]

Could not make Tool32 RAM_LESEN behave but read it with INPA "Speicher Lesen". WOW - hiding in plain sight! That's fantastic. Now, if I could get my hands on a multilink FX, I'm ready to try blowing up my DME.

Also, now I am ready to try running my engine on an MSS65 with MSS60 code. That will take a day or two.

Needs a parallel port, but maybe this could work? https://www.artisantg.com/info/ATGmmnka.pdf

Seems like there's quite a few pretty cheap on eBay. Just gotta figure out what the software situation is

Edit: Now that I look closer, only one is specifically listed for the 5xx/8xx

BDI2000 also seems to be an option if CodeWarrior can interface directly with it.

[terra]

Could not make Tool32 RAM_LESEN behave but read it with INPA "Speicher Lesen". WOW - hiding in plain sight! That's fantastic. Now, if I could get my hands on a multilink FX, I'm ready to try blowing up my DME.

I wish I could know for sure if it'd work. Spending $600 ($400 for the tool, $200 for the software) on a maybe is a bit much.

[dpaul]

Read it with tool32, not a full dump - most tools don't do RAM dumps.

Job would be RAM_LESEN. First argument (address) should be 0x3FEB52, second argument (length) should be 0x30. And FWIW, for some reason on the MSS6x, you can only read 0x64 bytes at a time on the injection side, and 0x63 bytes at a time on the ignition side.

Could not make Tool32 RAM_LESEN behave but read it with INPA "Speicher Lesen". WOW - hiding in plain sight! That's fantastic. Now, if I could get my hands on a multilink FX, I'm ready to try blowing up my DME.

Also, now I am ready to try running my engine on an MSS65 with MSS60 code. That will take a day or two.