If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
More tiny steps along the path... Lots of trials to see how the boot loader works - ie trying to convince the MMCS to load a modified LOADING.KWI file. Tonight was the first successful load of a modified file. Still not sure if there is a checksum on the file.
The boot loader seems to work in two or possibly three stages:
Stage 1: Loading the LOADING.KWI file into memory. This seems to perform some basic check of the file when loading - it can detect small problems with the file, and will attempt to restart the loading process if there is a problem.
Stage 2/3: Once the file has been loaded, I suspect control is handed over to the PROG NAVI MAIN (PNM) section in LOADING.KWI. At this point I suspect the PNM goes through and loads each section of LOADING.KWI into memory. This is based on PNM containing references to all the MIUT sections, and some others we do not have.
I almost have the Toyota v5.1 code working - however trying to figure out where to patch things together is a challenge.
I am having trouble making a banana sandwich. Do you peel them first? Do they go in the middle or on top. So you can see my difficulty... I am Buggered if I know what you guys are doing. ;P
2010 Platinum LE. Cool Silver, Auto, DiD, MM Rear Difflock. HD MM Tow bar and Lift Kit. Buzz Racks.
lol... The reason I post the information in the forum here is _loads_ of people have tried to break open the Eclipse units and come up with software solutions. This thread provides information for others who might be able to help. So here is a summary in reasonably plain English...
Lots of cars contain Eclipse units. Some of the earlier Mitsu's contain a unit which has a hard drive built in - this is the only unit where someone has found a software override. It turns out that unit is completely different from all other units on the market (it is based on a different CPU).
So... the unit in the Aussie MMCS is similar to that found in the Toyota's as far back as 2005, and a whole bunch of other vehicles. In fact they are _remarkably_ similar. Lets say you are looking at genetics. The 2010 Aussie MMCS shares about 50% of its genes with the 2005 Toyota v5.1 system.
You might say SO WHAT?
Well it turns out the Toyota v5.1 actually had an override option built in. What the Toyota owners do now is take the older v5.1 software and mix it with 2009/2010 maps, and thus can maintain the "override" option. This is a very simple solution for them. What I am trying right now is akin to splicing the genes from the Toyota v5.1 system into our MMCS version.
Unfortunately this is not going very well, so I may resort to another more brutal method. This involves effectively deleting chunks of the code and see what stops working. Over time I should be able to narrow it down to a certain block of code (a gene) that for instance displays the nag screen, or displays the video playback warning. Once I have that block of code, I can put something neutral in place, and thus provide an override. It takes about 30mins each time round to delete a chunk of code, burn the new disk, and upload it to the MMCS... at 2-3 runs a weekend, that means a few weeks (assuming there is no checksum).
While most of the thread is "Latin", I am sure there are plenty of things you folks could talk about where I would have no idea what you are smoking...
Good to hear Nathan
If you need any blank dvds im happy to send some your way.
This is awesome that you are able to do what your doing.
Can i ask where you get the loading file from and how you upload it back to the unit.. as maybe I could try to do the same.
I actually do follow what you are doing. Years ago in another life and in a galaxy far far away I used to hex edit some RTS game records to remove shadow in the replay so that we could catch cheaters.
Some of the old software locks used to be bypassable by changing a False to a Positive. But alas now I am old and tired with no concentration or patience and just trying to get my Banana Sandwich Franchise Chain off the ground.
Best of Luck Nathan.
2010 Platinum LE. Cool Silver, Auto, DiD, MM Rear Difflock. HD MM Tow bar and Lift Kit. Buzz Racks.
Well, I have been contacted by a group in Russia who are also trying to figure this thing out. They have helped out with a few small pieces of the puzzle:
1. As I was suspecting the BPE MIUT section has no connection to the maps (the BPE section is loaded at a different section of memory). So, somewhere between the BPE MIUT and the menu data must be some other type of segment that is loaded at a different memory offset. (If I recall BPE is Byte Pair Encoding), and as our Russian friends point out - not used on Aussie systems.
2. The Loading.KWI file does not have an overall CRC (checksum). Our Russian friends have pointed out the CRC for the Program Blocks found in each Loading.KWI file (four bytes at the end of the block).
I have conducted some other trials today and last night, and there is some form of checksum in place - and our Russian friends are also right in thinking it is somewhere in the MIUT blocks themselves. There is definitely nothing in the header, so it must be one of two things:
* The sum of all values in each MIUT block must equal a certain value - but this raises a question - how does the boot loader know where the end of a block is?
* Somewhere else in the Loading.KWI is a list of each MIUT block, length and a checksum - which in itself cannot contain a checksum.
So back to figuring out how we can actually modify the file and getting it to load correctly...
(For our Russian friends - sorry, no skype, but I will endeavour to send a PM via the forums).
Post Script...
I have managed to get a modified LOADING.KWI file to actually load. The programmers were lazy and went for a simple checksum, so I tried a trick from years ago... example:
Lets say you have a set of numbers:
0 2 4 6 8 10 12 14 16
A simple way to checksum these would be to add them all up... = 72. However with such a simple checksum, we could SWAP any of the bytes and still match the checksum.
So taking a guess the checksum was 4 bytes long, I did the following: The date 97/04/09 is long enough for a test... so I changed this to 87/05/09... which is subtract one from byte zero, and add one to byte 0+4.
Chuck the disk in, load it up, and hey presto, it works!!!
I also found an interesting side effect. When I stuck the original disk back in, it started re-loading the original file... then realised it had detected a newer date. Which means each time you stick a disk in, if the DATE has increased on any of the MIUT blocks, the new disk will load.
I think that is it for this weekend. Not sure if the checksum is XOR or ADD. Hopefully it is an XOR, cause that is simple to bypass. So the next test will be to check exactly which type of checksum we have. We can also sacrifice the date if we have a 4-byte XOR.
(Of course the other alternative is modifying the header of the MIUT block makes no difference as it is not involved in the checksum).
Not sure if this helps or not but a member over on the CJ Lancer forums stuck a Subaru whereis v16 map dvd in his MMCS and it worked. So in terms of splicing stuff, maybe the Subaru disc will be more friendly to work with? Just a thought anyway, keep up the good work.
Don't know if this helps. I'm chasing the same target...... the only difference is that my car is Toyota/Lexus one.
1. From what I remembered, the Naviem can be either Big Endian or Little Endian.
2. Actually, the LOADING.KWI can contain several module codes to be running on different model of NAV unit. I wrote a PERL script to extract all the modules. If you need it, let me know please.
3. The offset of each module in defined in the LOADING.KWI header, for the AISIN (and others) module (Toyota NAV unit for Europe) it uses Big Endian to store the offset. For DENSO (for US, AU.....etc), it uses Little Endian to store the offset.
4. The offset is split into sector address and logical sector address, here's how to calculate:
You can see that all the code block start at address with multiple of 2048 (0x800). I'll guess that if we find a value represents the start address of a code block, we need to multiply it by 2048 to get the actual offset of the start address.
6. I verified the checksum of the 4 Program blocks is located in the end of each Program block. The checksum algorithm is 4-bytes summary. By modifying the Module Name in the Program block and update the checksum, I can load the US DENSO module code on my DENSO of NAV unit (TW version).
The most direct link to info is here (not sure if you have to be a member of Club CJ though; if so I think the same info is in a couple of places in the second thread):
I have an Outlander and have been really ticked off with the lack of functionality that the MMCS has when in motion. I have read these posts and have been amazed at all your efforts. Well done. It has been at times like reading Gobbledy Gook, but I have reached this final post from 3 weeks ago and have been left hanging.
NathanNT have you made any more progress? Sorry to putthe pressure on but you doing so well.
Comment