MSS60 Research

[terra]

Want to kick of discussion since we have / will have a flashing app. More to come

[terra]

Bravo! Much faster than KessV2! Love to try it but my MSS60 (from MY 2011) is not BDM accessible so I'll have to restrain myself..

I wanted to ask whether the MSS65 flashed with MSS60 code will run the S65 engine? I know this has been discussed before but I do not recall if anyone actually went the distance and tried it.

No idea. I don't have an MSS60 to compare the board to, though a friend said he'll try to get me good pictures tonight.

I know MSS60 uses EWS4 and MSS65 uses EWS3, and there are some component changes due to that (EWS3 uses unidirectional communication while EWS4 uses bidirectional). EWS4 is supposed to be able to fall back to the CAN-bus though so that in itself might not be a big issue

What I don't know is if there are hardware differences for things like the ionic module or if it's just purely software.

Really wish we could do something about the BDM access short of replacing the whole CPU.

Edit: In the interest of open information sharing, added some highish resolution images of both sides of the MSS65 board. Can zoom in on any relevant bits once when I see some MSS60 bits to compare

Edit2: Of course the forum resized the pictures.

Edit 3: Here's a BMW press photo of the MSS60. Clearly has more components, but it's also clearly a dev board based on the populated BDM/JTAG headers. So it's hard to say how much is necessary without seeing a production board.

Edit 4: Attached the differences I could spot with the chips identified. I think it's safe to say the ethernet is not needed on a production board. Hopefully all that extra RAM was primarily for debugging as well. The other stuff could go either way. Extra CAN tranceivers could be for debugging or could be for some E9x specific equipment. For the LIN tranceivers, at least one of them should be for EWS4 comms. Not sure about the other. Oddly they used 2 different brands on the same board. Don't know about the OP AMP.

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

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

[Martyn]

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

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

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

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]

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]

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.

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

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

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.

[Martyn]

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

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