MSS60 Research

[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.

[terra]

I guess I have to ask about your memory map/offsets - I have a full KessV2 read from my MSS60 (with 241E software) in which 0x3FEB52 is FF.

But I have a read from an unlocked early MSS60 in which the SK is (I believe) contained in 0x30 bytes at But 0x7950 in a BDM read from the "left" processor. Your XOR operations work perfectly!

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.

[dpaul]

Okay, so I still haven't figured out how to read the EWS4 SK directly, but I found it in RAM! On 241E, if you read the 0x30 bytes from 0x3FEB52, that's your SK.

The first 0x10 bytes are the actual SK. The next 0x10 bytes are the first 0x10 XOR'd with 0xFF. The last 0x10 are the first 0x10 XOR'd with 0xAA

That should be enough to build a true backup. So if we figure out how to get the BDM working (or if the MSS65 is good enough to run an S65), that makes things a lot easier.

I guess I have to ask about your memory map/offsets - I have a full KessV2 read from my MSS60 (with 241E software) in which 0x3FEB52 is FF.

But I have a BDM read from an unlocked early MSS60 in which the SK is (I believe) contained in 0x30 bytes at 0x7950 ("left" processor). Your XOR operations work perfectly!

[terra]

On a quick glance it looks very similar. Only major difference I see is that the MSS60 has the LIN/K-bus tranceiver installed (for EWS4 comms) and is missing the comparator IC that the MSS65 has for receiving the EWS3 message. Might well be feasible to use the MSS65 as an MSS60 in that case.

I suppose it's possible that Xilinks FPGA is programmed differently and such - I don't really know what its function is. Based on positioning, my guess would be coordinating communications between the two CPUs.

Edit: Okay on the back there's a bunch of tiny components missing on the 65 near the bigger connector. Then on the front there's a component and some caps near the same connector - not sure what the function of any of that stuff is. Doesn't look terribly difficult to solder (nothing BGA), but identifying all those components will be a pain.

[Martyn]

I have an MSS60 here so I popped it open and grabbed a few pics for you.

[terra]

Okay, so I still haven't figured out how to read the EWS4 SK directly, but I found it in RAM! On 241E, if you read the 0x30 bytes from 0x3FEB52, that's your SK.

The first 0x10 bytes are the actual SK. The next 0x10 bytes are the first 0x10 XOR'd with 0xFF. The last 0x10 are the first 0x10 XOR'd with 0xAA

That should be enough to build a true backup. So if we figure out how to get the BDM working (or if the MSS65 is good enough to run an S65), that makes things a lot easier.

[terra]

On the topic of BDM, this seems promising to clear the censorship mode for the injection / left processor on the MSS60: https://www.nxp.com/downloads/en/dev...MPC56X_GMD.zip

Seems like you'd need a real BDM interface (rather than the tuning junk) to upload the script, but looks like it would execute from RAM and clear the censorship mode. That will by necessity wipe the data from that CPU, but might not be a big issue, especially if we can figure out how to dump the EWS4 SK (working on it).