|Pajero 4WD Club of Victoria Public Forum||
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.
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).
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 in the header of each MIUT, you find something like:
0004e000 4d 49 55 54 00 00 00 00 45 56 54 49 4d 45 52 00 |MIUT....EVTIMER.|
0004e010 00 00 00 00 4f 53 00 00 45 56 54 49 4d 45 52 00 |....OS..EVTIMER.|
0004e020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0004e030 00 00 00 00 00 00 00 00 56 65 72 31 2e 33 31 00 |........Ver1.31.|
0004e040 39 37 2f 30 34 2f 30 39 00 00 00 00 00 00 00 00 |97/04/09........|
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).
Last edited by NathanNT; 22-05-10 at 09:32 PM.
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:
$code_start_pos = ( $sec_addr * 2048 ) + ( $logsec_addr * 2048 * 65536 );
5. The following is a list of code "blocks" in one of the DENSO module (it is for Taiwan version RAV4 NAV head unit):
[DEBUG] Source Filename = SYS1-DENSO-MOD2-TE03-07A0.KWI
[DEBUG] File End At: 0x19327ff
0x4c000 Program Block TE03000007A00000 00/09/18
0x4c400 Program Block TE03000007A00000 00/09/18
0x4c800 Program Block TE03000007A00000 00/09/18
0x4cc00 Program Block TE03000007A00000 00/09/18
0x4d800 MIUT EVTIMER Ver1.31 97/04/09
0x4e800 MIUT MEMORY Ver2.30 99/02/01
0x53800 MIUT LIBRARY Ver1.30 97/04/09
0x55800 MIUT SLIB Ver2.22 05/06/08
0xa7800 MIUT HL Ver1.56 98/10/23
0xb4800 MIUT FILE Ver2.16 2005/01/12
0xbb800 MIUT IO_PORT Ver3.10 2005/05/12
0xbc800 MIUT PF Ver2.15 2002/02/05
0xc3800 MIUT TGAVC Ver2.56 2002/09/11
0xc6800 MIUT ACC Ver009 2004/07/09
0xca800 MIUT AVC_LAN Ver6.54 2003/05/09
0xda800 MIUT VS Ver1.87 2001/08/20
0xdd800 MIUT SD Ver3.50 98/12/22
0xeb800 MIUT CC vi001 04/12/20
0xf3800 MIUT BIOS Ver1.10 01/08/31
0x137800 MIUT CHN Ver0.02 2004/08/04
0x155800 MIUT GPS Ver010d 06/11/27
0x18c800 MIUT CL Ver0.00 2004/02/18
0x18d800 MIUT MOM v00-0251 2005/11/02
0x1b5800 MIUT TAB2 Ver0.05 2005/05/31
0x1b9800 MIUT DRL Ver0.03 2005/03/25
0x1c3800 MIUT DFW Ver803 2005/02/08
0x1c7800 MIUT STC Ver0.28 2005/09/27
0x1d2800 MIUT VSI Ver0.00 2004/06/02
0x599800 MIUT DEVICE Ver2.02 2004/10/01
0x59c800 MIUT CDFILE Ver1.38 2004/10/13
0x5a8800 MIUT ATAPI Ver429 03/11/21
0x5af800 MIUT GiOS v227_4_1 05/11/07
0x634800 MIUT BLK Ver0.00 2005/04/19
0x635800 MIUT CAN Ver1.00 2004/01/30
0x639800 MIUT SRDB ver01c 01/10/26
0x63d800 MIUT GiEL Ver0.09 98/10/20
0x648800 MIUT TAB2SW Ver1.39 2004/02/19
0x64c800 MIUT MstrApp Ver0.00 99/09/17
0x75b800 MIUT IS Ver1.00 02/06/14
0x75f800 MIUT RPALIB Ver04c3 05/11/16
0x771800 MIUT SWGW v001 2004/02/05
0x784800 MIUT DLCD Ver0.00 2003/08/25
0x78b800 MIUT USBD Ver0.00 2003/12/04
0x7a6800 MIUT KSLLIB Ver0.00 2003/12/04
0x7ad800 MIUT UDL Ver0.00 2004/2/13
0x7b1800 MIUT IEEE1394 Ver0.15 2005/04/21
0x7b6800 MIUT INF Ver0.16 2005/07/05
0x7bb800 MIUT DSC Ver100 2004/03/25
0x7c1800 MIUT FSCARD1 Ver3.45 2005/07/19
0x7cf800 MIUT HDDST Ver0.10 2004/10/01
0x7d4800 MIUT BGM Ver0.01 2003/06/20
0x7db800 MIUT CS Ver0.01 2004/06/01
0x7eb800 MIUT VCM Ver1.00 2004/05/07
0x7f0800 MIUT VCC v430 06/06/15
0x7f4800 MIUT GDC Ver1.00 04/05/31
0x82b800 MIUT VST v100 04/08/07
0x82d800 MIUT APILIB Ver0.00 04/09/09
0xa21800 MIUT VI ver002 04/09/07
0xa33800 MIUT VROGW Ver1.00 2004/12/23
0xa39800 MIUT TR_LIB Ver1.00 98/08/26
0xa56800 MIUT IME Ver0.043 02/06/??
0xa7e800 MIUT MEC 0277 2005/08/02
0xa9d800 MIUT MEA v138 05/04/22
0xaac800 MIUT TU Ver0711 06/04/10
0xaea800 MIUT COM011 Ver0.05 2004/10/19
0xaed800 MIUT COM012 Ver0.05 2004/10/19
0xaf0800 MIUT COM013 Ver0.05 2004/10/19
0xaf7800 MIUT BTC Ver0.24 2006/01/11
0xb07800 MIUT BTD Ver0.25 2005/05/23
0xb13800 MIUT LT Ver001 2004/03/17
0xb14800 MIUT TELMEM ver300 2006/04/18
0xb25800 MIUT BTMC 0050 2005/08/01
0xb38800 MIUT COM009 Ver0.05 2004/10/19
0x18f3000 PROG NAVI MAIN
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.
Hope to hear from you soon.