Mitsubishi Forum - Mitsubishi Enthusiast Forums

Disclaimer: I drive an 08 Lancer, but i'm 99.999% sure this applies to the outlander with navi, too.

[Edit: This post describes the procedures we went through to discover the MMCS password. To unlock the drive yourself, which is [b]much easier, see this post]

A friend & I have managed to unlock the Hard Disk Drive in the MMCS over the weekend.

Here is a very brief overview of what we did:

First, we made what we'll call an "Interposer" card -- basically a board that you insert into the hard drive slot in the MMCS to expose the data lines for the hard drive communications with the real hard drive attached to the other end. We did this by measuring the size & depth of the opening and cutting a copper board to size, etching off some traces on the top to connect to some 44-pin headers on each end (one to go in the MMCS, the other to connect the original hard drive to), and connecting jumper pins so we can attach an oscilloscope to the data lines.

Here is the finished Interposer card installed in my MMCS unit with the digital scope probes attached:
Attachment 13720

And here is the oscilloscope sitting on the roof of the car with the wires going through the sunroof (so they don't get in our way):
Attachment 13721

Once everything was connected, we set the scope to trigger when the "SECURITY UNLOCK" command was sent per the ATA specifications (0xF2). At first, we weren't seeing any data -- after a lot of troubleshooting, it turns out it is because the MMCS sends the SECURITY UNLOCK command and rather than polling the status bits (as it technically should) it just has a very long time delay before it starts sending the password bytes. Once we figured that out, we captured the part of the password on the scope:
Attachment 13722
Since our scope only had 16 digital inputs and the data words are 16 bits wide, we had to remove some of the extra signals. Since the MMCS is an embedded system, it is very predictable on startup -- so we simply triggered on the first occurrence of "F2" on the data pins and the 2nd DIOW pulse (indicating the start of the data). Here is a scope screenshot of the HDD unlock password in its entirety:
Attachment 13723

Success!

Effectively, after staring at the waveform for a while, you come up with this as the HDD password:

BAB2 BCB3 DFB0 BEAC BBB1 DFBE ADB1 CDD2 CEC9 B2AA B1DF 899E DF96 8CAA 8D9A DFDF

Before we move on, I realized there are some interesting facts about this password though. The D7 and D15 pins are held high through the entire password sequence. The password is 32 bytes long but transferred at 16 -sixteen-bit words, so the MSB of each byte is high. It turns out that if you invert all of the bits of the password you get this:

454D 434c 204f 4153 444e 2041 524e 322d 3136 4d55 4e20 7661 2069 7355 7265 2020

That looks like ASCII! Decoded it reads "EMCL OASDN ARN2-16MUN va isUre " ... but that doesn't make any sense. After swapping the byte ordering around you get:

4D45 4C43 4F20 5341 4E44 4120 4E52 2D32 3631 554D 204E 6176 6920 5573 6572 2020

which in ASCII is: "MELCO SANDA NR-261UM Navi User " W00t!

Now we know the HDD password and how it is derived. The next step was to install the HDD into my computer and boot linux. It turns out hdparm's --security-unlock command only takes ASCII passwords from the console (remember, our password is the inverted ascii text). So I booted with a linux-based XBOX unlocking CD.

The password I had to give to the 'unlockhd' command was actually byte swapped, so if you try it, use this as your password:

b2bab3bcb0dfacbeb1bbbedfb1add2cdc9ceaab2dfb19e8996 dfaa8c9a8ddfdf

Sucess 2!

The hard drive was now unlocked and security disabled. I rebooted back into "normal" linux and made a disk image for a backup -- and now all the experiments can begin! Also note that I did NOT have to relock the hard drive before reinstalling it in the MMCS, saving a step. I believe the MMCS just relocks it for you.
[/align] [/align] The disk has 6 partitions (3 primary partitions + a logical partition containing 3 more partitions). It appears to be separated into partitions for Map data, unknown, navi software (loading.kwi), screen resources animations images and text, gracenote CDDB, and finally the music server.

Oh, and to answer the question: Only 5.4GB of the disk is used for the Music Server! The music is in a proprietary format (but appear to be similar to an mp3 in a RIFF/WAVE container but with DRM or something and a .sc file extension). All the bootup animations and backgrounds are bitmaps or gifs (animated). All the navigation data appears to be similar to most other OEM navigation units out there and is littered with ".kwi" and ".idx" files. Aside from the "loading.kwi" file I found, which I suspect is only loaded after the system boots up (which may explain why some navigation options are unavailable immediately after power-on for a few seconds), I guess the operating system is entirely stored in flash.