Announcement

Collapse
No announcement yet.

MSS60 Research

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Originally posted by dpaul View Post

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

    Comment


      #17
      Originally posted by terra View Post

      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!

      Comment


        #18
        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

        Comment


          #19
          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:

          Click image for larger version  Name:	Screen Shot 2020-04-17 at 10.59.03 AM.png Views:	0 Size:	47.4 KB ID:	13020

          And these are the definitions for the censor registers speciically:

          Click image for larger version  Name:	Screen Shot 2020-04-17 at 11.01.37 AM.png Views:	0 Size:	358.3 KB ID:	13021

          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:

          Click image for larger version  Name:	Screen Shot 2020-04-17 at 11.11.56 AM.png Views:	0 Size:	57.5 KB ID:	13022

          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.

          Comment


            #20
            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
            Last edited by dpaul; 04-17-2020, 07:59 AM.

            Comment


              #21
              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.

              Comment


                #22
                Originally posted by terra View Post

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

                This should be fixable.

                .
                Awesome

                Comment


                  #23
                  Originally posted by terra View Post
                  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?

                  Comment


                    #24
                    Yeah seems like there's a lot of misinformation about that. Typical industry guys obfuscating information I guess.

                    It seems to be only early 08 models (really ~2007 builds) that are unlocked. There's also all sorts of claims that BMW introduced the lock through an update and the lock could be cleared by flashing an older update. None of that appears to be true. If the DME was unlocked from the factory it stays unlocked, if the DME was locked from the factory, it stays locked (until we figure out how to send that clear censorship code to it anyway).

                    Comment


                      #25
                      This from a Freescale customer errata sheet:

                      CDR_AR_1057 Customer Erratum C3FARRAY_A.512KCDR3_03_0
                      UC3F: censorship can be overridden in certain cases
                      DESCRIPTION: It is possible that Censorship can be overwritten under certain conditions. These conditions will not be documented.
                      WORKAROUND: Program RCW[IWS] to 0 when censorship is enabled. This will provide an additional layer of protection by preventing access to the array except when executing from the array

                      So there is an undocumented method of clearing censorship without losing the contents of the array! Not that this is so important at this point as the SK is readily obtained. But still....


                      EDIT: something to be concerned about

                      CDR_AR_1011 Customer Erratum C3FBIU.CDR3UBUS_02_0
                      UC3FBIU: CENSOR bits cannot be cleared even if UC3FCFIG[IWS] is 0
                      DESCRIPTION: The UC3FCFIG[IWS] bit may get cleared inadvertently at the deassertion of system reset. This means that only a write to a valid array location will serve as the erase interlock write for clearing CENSOR bits. If the array is already censored then it is not possible to clear the CENSOR bits at all.
                      WORKAROUND: Do not censor the array (CENSOR=11) before production, as it may not be possible to clear the CENSOR bits if the array is censored.

                      Last edited by dpaul; 04-18-2020, 03:17 AM.

                      Comment


                        #26
                        Originally posted by dpaul View Post
                        This from a Freescale customer errata sheet:

                        CDR_AR_1057 Customer Erratum C3FARRAY_A.512KCDR3_03_0
                        UC3F: censorship can be overridden in certain cases
                        DESCRIPTION: It is possible that Censorship can be overwritten under certain conditions. These conditions will not be documented.
                        WORKAROUND: Program RCW[IWS] to 0 when censorship is enabled. This will provide an additional layer of protection by preventing access to the array except when executing from the array

                        So there is an undocumented method of clearing censorship without losing the contents of the array! Not that this is so important at this point as the SK is readily obtained. But still....


                        EDIT: something to be concerned about

                        CDR_AR_1011 Customer Erratum C3FBIU.CDR3UBUS_02_0
                        UC3FBIU: CENSOR bits cannot be cleared even if UC3FCFIG[IWS] is 0
                        DESCRIPTION: The UC3FCFIG[IWS] bit may get cleared inadvertently at the deassertion of system reset. This means that only a write to a valid array location will serve as the erase interlock write for clearing CENSOR bits. If the array is already censored then it is not possible to clear the CENSOR bits at all.
                        WORKAROUND: Do not censor the array (CENSOR=11) before production, as it may not be possible to clear the CENSOR bits if the array is censored.
                        Yeah that second one concerns me. I hope that that erratum was fixed by the time the MSS60 went into production

                        In any case, I bought one of these: https://www.ebay.com/itm/274331062216

                        Older versions of codewarrior seem to have support for a wiggler interface, and some way or another I can probably get it to work with GDB. At ~$32 with shipping, it's not a tremendous loss of money if I can't do anything with it.

                        The one thing we don't have is the actual shadow memory, but if the MSS65 is anything to by, there isn't anything notable in here. First 4 bytes are set to 00, and the rest is blank.

                        Edit: This should be the errata sheet that applies to the MPC563 in our DMEs (revision B): https://www.nxp.com/docs/en/errata/MPC563BCE.pdf

                        That second bug isn't noted.

                        Even newer variants could possibly have revision C, which seems to have fixed the ability to read contents without clearing censorship... but like you said, big deal.

                        Comment


                          #27
                          Good score on the Wiggler!

                          If that doesn't work, the Freescale USB TAP should - a little more money but not much. If my MSS65 wasn't dead, I'd get a USB TAP and see if I could censor and uncensor the DME. Can't find a cheap enough MSS65 tho and almost can't believe you found an MSS60 for $65. Another good score.



                          Plus it's USB and it should be compatible with the current Code Warrior for MPC5xx 8.7

                          Comment


                            #28
                            Originally posted by dpaul View Post
                            Good score on the Wiggler!

                            If that doesn't work, the Freescale USB TAP should - a little more money but not much. If my MSS65 wasn't dead, I'd get a USB TAP and see if I could censor and uncensor the DME. Can't find a cheap enough MSS65 tho and almost can't believe you found an MSS60 for $65. Another good score.



                            Plus it's USB and it should be compatible with the current Code Warrior for MPC5xx 8.7
                            I thought about the USB TAP, but it seems like they sold a few different versions that are compatible with different processors. It might just be a matter of opening it up and using the right cable unlike the PEMicro, but I didn't want to take that risk. The one for the MPC5xx/8xx is apparently the CWH-UTP-PPCD-HE

                            Hi,   Do NXP still selling Codewarrior USB TAP CWH-UTP-PPCC-HE?   If not, what's is the difference between CWH-UTP-PPCC-HE and CWH-CTP-BASE-HE. I will need to use the Flash programmer and Hardware Diagnostics.   Currently I'm facing a probelm using CWH-CTP-BASE-HE. It seems like there's a connection...

                            Comment


                              #29
                              Originally posted by terra View Post

                              I thought about the USB TAP, but it seems like they sold a few different versions that are compatible with different processors. It might just be a matter of opening it up and using the right cable unlike the PEMicro, but I didn't want to take that risk. The one for the MPC5xx/8xx is apparently the CWH-UTP-PPCD-HE

                              https://community.nxp.com/thread/386294
                              You're right and NXP isn't making anything easy. Incredibly annoying that the actual model number is only put on the box - the number on the device itself is something meaningful but not listed in the documentation anywhere. There are a lot of CWH-UTP-PPCC-HEs (900-75115, PQII/III) around but PPCD (900-75094, maybe) is hard to find.
                              Last edited by dpaul; 04-18-2020, 02:17 PM.

                              Comment


                                #30
                                Originally posted by dpaul View Post

                                You're right and NXP isn't making anything easy. Incredibly annoying that the actual model number is only put on the box - the number on the device itself is something meaningful but not listed in the documentation anywhere. There are a lot of CWH-UTP-PPCC-HEs (900-75115, PQII/III) around but PPCD (900-75094, maybe) is hard to find.
                                Yep, exactly what I found as well. You can still buy it direct from NXP... but at $500, what's the point? https://www.nxp.com/part/CWH-UTP-PPCD-HE#/

                                Comment

                                Working...
                                X