xs650

GM parts direct has it for $209.65, but I still agree with your assesment.

ein Tier

I've been looking for that DVD in the usual "black market" pirate channels, but I've been unable to source it.

However, I'm starting to think that LOADING.KWI may hold the secret. I've been going over the ISO discs that were used to update the navigation system.

I have several reasons for this. One, they're MUCH smaller, and sifting through 10MB of data is an order of magnitude easier than 8GB. Two, the 'inside guy' over at Cadillac forums said a lot of different things, but he really seemed to suggest that it might be found on the discs, and that different versions of the firmware might have different codes. That seems at odds with each other -- is the code firmware or software -- but what if the map disc does some firmware loading of its own (checks to see if the firmware or it has the latest codes), and also, the updates appear to have mostly re-written the code in the firmware. That means if the codes are in the firmware, they should be on the disc.

Interestingly enough, I've found the database of language in the loading.kwi file. It looks something like this:
Well, you get the general idea. I'm also finding parts of the legal message in there as well: "Drivers: Do not operate the screen of the"

Now, I'm not using "proper" tools to look at this, so it's probable that I'm not seeing everything and that pieces may be scattered. Still, I'm intrigued.

[edit]
This appears to be compiled C code. I'm finding references to .c files all over the place. Of course, I haven't even looked at C code in almost 10 years and I don't have a C decompiler, but maybe someone else.....

I can't be the only software engineer here.

[edit edit]Weird. There are references to Saab in here. No other GM makes though. Did find a reference to "RDIAG" by searching for "cor" (it was right next to it).

[edit edit edit]
Here's something really interesting. I found the following:
EVTMNG | CMDCOM | CDDA |||| CDDB |||| MP3U |||| DVDV |||| ODBC ....

Now, evtmng is probably "event manager", and cmdcom "command com", which are programs to monitor and run events. Then there's CDDA and CDDB, which is way to read audio CDs, and then mp3u, which I'm sure we can all guess what that does. And then there's dvdv. Could this be "DVD Video"? Why would it be stuck there with all the other codecs? I've not seen video anywhere on the map disc.

Can anyone verify if the diag keypad that can be brought up when inserting a DVD video disc into a nav system that has NOT recieved the firmware updates?

Zymurgy

ein Tier, I don't know if this will work for you, but Boomerang is an open-source decompiler.

ein Tier

No codes yet, but I'm starting to feel I'm on the right track. I would recommend that anyone that's kind of interested in this kind of thing, open up LOADING.KWI in a text editor (it renders better in textpad, but cutting and pasting is tedious, wordpad garbles more of it, and it's too big for notepad to open). I don't even know what to talk about, it seems like every time I look, I find something more interesting.

So, without further ado:
Then there's lots of menu items like UPPER RIGHT, DOWN, ZOOM OUT, etc. Then a lot of stuff for each particular item, like " REMOTE CONTROL TEST | Please push the remote control buttons." There does not seem to be anything here for "Enter Diag Pin...."

But, that should give us some ideas of what the diag menus actually do. In regards to connections, I've seen things here and there about com ports and TCP_IP and email. For those wondering about the TMC GPS traffic monitoring system, there are references to it in here. I wonder what our nav is actually capable of doing. This would also verify what GM has been telling us, that there is nothing in the diag menus that will allow bypassing of the nag screen, watching DVDs, or allow input while in motion. It may also be the case that some of this code was written for other systems, and ours does not have any way to access certain features, like bluetooth or remote control, and GM would rather we didn't ask questions about where they are. And some of these functions may be outright dangerous, it is not uncommon to enter the service menus on television sets and cause detrimental changes that cannot be undone. Not that it will deter me, but sometimes this stuff is locked up for a reason.

Also, just because "input in motion" and "no nag screen" and "dvd video" are not in the diag menus, it does not nessessarily mean they do not exist or are unavailable. It seems to be the case on the other systems that the code is entered, but no confirmation happens -- you're just suddenly able to do it. It's likely the same holds true here.

For those hoping for video (like me), I found this: DVD Player Ver | X |

ein Tier

Interesting tidbit. Our Nav systems seem to be running a variant of the UNIX/Linux/*nix operating system.

I found a reference to the loading of the ALLDATA.KWI file. Interestingly enough, the update CDs have this file, but it is a 0k file. It appears that the system needs to be able to see that file to operate, even if there's no info in it.

Anyway, the path is /dev/cd/cd2/slot0/ALLDATA.KWI . There's a path the mp3 decoder: /dev/mp3dec, so that appears to be firmware stored somewhere in the system.

I have found the following numbers lurking around the infamous "1791" code number. I am in Seattle and the Corvette is in Austin, so I have no way to test. Anyone want to try them? Most of these numbers occur only when near the others.

These are in the blocks they were in. I wonder if the 0,1,2,3,4,5 segment means those must be entered in order?
The '753' entry code that works for Range Rover diagnostics does not exist in this file. 02468 shows up often, sometimes repeating, sometimes by itself, sometimes with 1237 and 0127.

There are also dates in here, in yy/mm/dd format, they seem to be tied to when the program was written. Program Block GE1200001312000005/07/07, 2001/08/20, Ver1.10 | 01/08/31, MP3U | ver001 | 01/01/08, 98/08/26

Funny that the MP3U program appears to have been written way back in 2001, but we didn't get the capability until 2005.

VamPY

ein Tier you're da man and I would like to thank you for the effort you're putting into this, as well as everyone who's trying. As I said, I don't have a corvette so therefore I have no access to the files on the NAV DvD. If the individual files aren't very big, you can send them to me and I will have a look too.

freakuency@gmail.com

Hurricane

I am fascinated reading your posts, ein Tier! Great stuff!

ein Tier

So, we ran the compiled files through a unix tool that finds any plaintext string in a compiled class. Most of what we got was pretty useless, mainly relating to XM Radio station names. But, we did get the following numbers:

0000
615
635
8900
97531
840

which appear no where in the human readable stuff. If it was unencrypted and on the update discs, it has to be one of the numbers here or in the previous post. I can't believe that everyone wants to get their popcorn out and wait for the answers, but no one will walk out to their car and actually try any of these.

[edit]
Final thoughts before going to bed after reading over everything.

I don't think this FIDGAF guy really knows what he's talking about. He seems to have a clue, and probably does work for who he says he does, and probably knows enough to be dangerous and probably even knows some codes. But his assessment of the loader file is all wrong from what I can tell. He's right about the KIWI file system being a glorified database, but that's about it. He says the loader file "is probably either the compression algorithm, a schema file or loads the various zones stored.", but I don't buy it.

It is most definately NOT the compression algorithm. It's too much like a database to be that. The data isn't compressed that well either -- evidenced by the over 50% shrinkage when zipped. If it was really compressed, then not only would it be unreadable, winzip couldn't compress it much more.

Loads the various zones? No, that appears to be the job of the IDX files.

A schema file? Perhaps he could better explain that, because 'schema' is a pretty loose definition. The strict definition is that a schema file tells the database how to build certain files. That can't be it, because the tables are already built, and it doesn't appear to be relevant to the data contained elsewhere on the disc -- but does appear to be relevant to the navigation software itself. Now, it could be a schema file in that it tells the nav system how to build its menus, but I'm pretty sure it's not a database schema file. The majority of stuff in there has nothing to do with defining a schema.

But here's the kicker. Our factory nav DVD's don't even have a loader.kwi file. At all. I went crawling through the factory original disc, and it's not there. So, whatever it is, it's not something the system needs to use all the time, like it would if it were any of the three things the guy mentioned.

And the more I think about it, loader.kwi has to be the key. Let's start with it's absence. Why is it missing from our DVDs? Could it be because GM | Denso | whomever is worried that people have figured out where the keys are? Maybe the original discs not only contained the maps, but they updated the firmware if it needed it. Now, they changed it, and only the firmware update CDs have the loader file -- and remember, we weren't supposed to have copies of those.

Now, let's also consider what happened when we put the DVDs in. The first disc (which is the one with loader.kwi only) went in to update the navigation software. The following phrase appeared: "System software is loading. Do not turn ignition switch off." You can find this phrase in the loading.kwi file. The second disc updates the audio software and is fantastically small -- 256k. It is likely a patch file or judging by the fact that it's exactly 256k, it's probably a complete memory load to a chip. This is probably what enabled the "mp3" button and menus on our stereo. The audio portion of the unit is likely a seperate piece that the navigation system runs.

So, let's go back to the navigation. The loading file is pretty small on the disc, but it's still a big file. It's 23.4MB. How much RAM is a navigation system like ours going to have? Keep in mind that just a few years ago, a 32MB "thumb drive" was still a hundred dollar device. Is it a stretch to think that the navigation unit only has 32MB to work with and 23.4MB is taken up by the navigation program itself? (the OS is likely embedded on another chip).

When you do updates like these, for instance, flashing the BIOS on your motherboard, you typically wipe the whole thing clean and then rewrite the whole thing from scratch. It's easier and safer than applying a patch when you're dealing that close to the hardware, and you only get one shot at it. Plus, it's not like you're having to copy a 10GB file over. If that's the case, then all of the navigation code should be contained in loader.kwi. And to be fair, there's a lot in there. There's a lot of plaintext, but I'd say a majority of it isn't human readable.

If that's the case, the pin codes should be in there -- how else would the nav system be able to check them? Of course, Denso could have been crafty and smart and offloaded all the codes to another chip in the motherboard. That's smart, but really, you don't need that kind of security -- you won't lose money if someone hacks the system, you just need to keep idiots from harming themselves. Plus, having an extra chip means more space and more money. Hmm, not likely. Ok, but Denso could have encrypted it. This is possible, and maybe even likely. I don't know enough about encryption to say anything definitively. Again, I doubt it though, because what would be the point? The "gate" doesn't need to be a fortress, it simply has to be good enough to keep the curious out and let the techs in. If there's one thing I know about software programmers, if we don't have to do it, we're not going to. Especially with something as "fun" to deal with as encryption. I've often used plaintext passwords and access points in programs, only changing it when it was about to go live, and only because it was the kind of thing that could cost the company money. It's just one more thing that breaks and makes testing and development hell.

Where else could it hide? It could be hidden in the code itself. In fact, I might be tempted to put it there myself, especially if it isn't going to change often. If that's the case, it's likely plaintext in the code and is one of the numbers I pulled out from the non-human readable part. However, that's not good design practice. You have a massive database already. Put the codes in there, because that way someone who's not a programmer can change them easily and at a moment's notice.

I think you're beginning to see why I think what we want is in this file, but I've got one more reason. It would make sense to be able to update the codes easily, in case they are compromised and represent a liability for the company (lawsuit for using the nav while driving, anyone?). The easiest way to do this is to have it part of that database, and update it when you update the firmware. Our guy FIGDAF alludes to this when he mentions the different firmwares -- and it does appear that later versions of the Cadillac navs have different codes.

Oh, one more thing. Remember what he said about the "universal disc"? He specifically said there's NO loader.kwi file, only a bunch of bin files. Could it be that there is no loader.kwi file because it would be difficult to update all lines from one disc? Think about it, our software is different in significant ways from that in the Cadillac system, and even the codes are different from one make to the next. Again, I think he knows some stuff, but I think he's making completely wrong assumptions on how things work. In fact, I think we have the generic disc. There's no loader.kwi file, and there's nothing on it or the packaging to tie it to any one model -- just a generic "GM".

mark1107

I just tried all of those codes and none of them worked. Please let me know what else I can do to help you.

ein Tier

I wasn't optimistic that those numbers were the codes, they were just pulled from the code -- they could be anything.

I have to ask, does your nav have the mp3 updates? I don't know that any of these codes will work on a non-upgraded system since they came off the upgrade disc.

Also, the only number I think we're going to "see" do anything is the one that gets us beyond the screen. All the others may not give a visual confirmation. This is why I think brute forcing the codes at this point is futile -- you could get the right code and never know it -- and it turns the testing of a number from a five second operation into one that could take a full minute.

Buffy

LOADING.KWI is code or related material. Checking the Kiwi spec I find that it's a set of loadable module groups, arranged in such a way that there are tagged for the device, which loads whatever module(s) fit. The LOADING.KWI file on the upgrade disc contains two modules, named DENSO.GE12 and DENSO.GE14 of around 12 MB each. These modules contain a header starting with strings like "GE121312" and "GE141312"; I assume the "1312" is a version number. Then there's a of table of contents followed by a bunch of "program blocks" - I haven't separated those out yet, and am not exactly sure about the format of those. Probably relocable? There should be some code in there, probably for some variant of the Hitachi Super-H CPU. I haven't managed to dissasemble any coherent code yet. But the strings of interest (nav text in several languages) are in there.

Regarding the PIN, as it's numeric I'd expect it not to be stored in the file in ASCII or Unicode, but rather as an integer. Very likely there's some code that just checks it against a constant, simple enough.

I'll see if I can pull out the program blocks and find out more about them.

ein Tier

A very good point. I'm a software engineer, but I focus more on higher level languages like C# and Java, and even then, I've moved into a consultant/management role and write very little code of my own these days.

I took a compilers class in college, but that was over 10 years ago, I don't remember any of it. Ditto for the regular C. I have no decompilers for this stuff.

However, the more I think about the problem, the more I honestly believe that the codes we want are buried somewhere in that file and it's just a matter of pulling them out.

If it helps you, there's some good evidence in this thread that the nav is running VxWorks on a Hitachi SH-3E, HD6417718R chip. Here's a photo of the chip.

Huge doc on how to read/use the KIWI-W datasystem: http://kiwi-w.mapmaster.co.jp/format...mat_kihon.html

I'm still sorting through it, hoping it reveals something.

ein Tier

I hate back to back replies like this, but I'm trying to jot down everything I find out, both for my benefit and for the benefit of others. It's nice being able to look back over what I've found and how I got there, plus, I'm hoping there are other software engineers lurking around.

Newest updates. The KIWI system is a pretty common system for storing map data. Many systems use it, including several not made by Denso. Of particular note, Audi uses the KIWI system for its map data. On the NavPlus (Audi's navigation system) forums, I found this very interesting thread: Modified Map Disks (hints, tips, quirks). TeddyBGame there says that Dan Gold cracked the system, but was forced by Audi to take the instructions down off of his site. Teddy claims that he still has the html "somewhere". I've contacted both via email looking for the pages. Meanwhile, I'm going to read the thread and see if I find anything else of interest.

You'll also find mention of LOADING.KWI all over (well, 29 threads, anyway) that site. It is what we think it is -- a complete code update for the navigation software. They are modifying it mostly to run the US code on their Euro systems, but they are also adding points of interest and all kinds of fun stuff. I must get those documents!

wewing

My 2005 coupe came with a Nav that plays MP3's, in fact I was listening to an MP3 CD while I tried the codes you provided, but no luck getting into the diag page.

The audi stuff sounds promising, heck, all I want is to get rid of that annoying legal screen that pops up every time I get in the car, and to allow my wife to input destinations while we're moving. It looks like they were actually able to alter the program much more profoundly.

Oh well, I am a programmer, but since I don't have an upgrade disk, I don't have the loading.kwi file. Please let me know if you find anything out.

ein Tier

If you'd like to look at the loading.kwi file, you can grab it here.

Hopefully, you're a ruby expert. It appears that a Japanese person may have written a KIWI decoder in Ruby. The files are kiwivce.rb and run_decode.rb.

Unfortunately, I don't know the first thing about Ruby. I don't have a machine running it that's accessable to me, and I have never even looked at Ruby code until today.

mark1107

Ein Tier,
My nav does has the MP3 updates. As an fyi, if you can crack this and allow my gf to enter a destination while driving, ad/or watch dvd's I will pay you $200.00.

THANK YOU for your help.

Mark

Hurricane

What do you have to press to get to the diagnostics screen? I still haven't figured that out...

Thanks again for your informative posts! Very interesting!!!

Buffy

I got the Kiwi documents, and wrote a (Java) program to decompose the LOADING.KWI file. Here's what it contains:

Number Of Accomodated Systems = 1

Manufacturer Identifier = DENSO
Number Of Accomodated Modules = 2

module 0
Module Category = program
Module Name = GE14
Module Version = #0#1!%#8

module 1
Module Category = program
Module Name = GE12
Module Version = #0#1!%#8

module 0
valid Date = 0
invalid Date = 0
module Title =
manufacturer Information =
address Of Module Code = 1
size Of Module Code = 5776

module 1
valid Date = 0
invalid Date = 0
module Title =
manufacturer Information =
address Of Module Code = 5777
size Of Module Code = 6226

And I can separate out two module files, GE12 and GE14. They're about 12MB each. The GE14 file does contain the string "Enter Diag PIN..." at 0x18B9A4, and the rather fascinating sequence at 0x46FD40 "HardWsApp_Callbacks.c CB_PressGMBlackFormButton". Sort of implys that the black or hidden button is a GM thing.

This is definitely some sort of program file, the source was written in C, it's probably for a big-endian machine, and is in some sort of loadable or semi-relocable form. Not an Elf, though. I'll try running chunks of it through a Super-H dissasembler and see what I get.

As to it being VxWorks, I'm not too sure - looks like there's a Japanese OS that's another candidate, and there's a Toyota / Denso / Sony OS called ITRON which is probably based on this - mainly for the Toshi TX49 CPUs - not sure yet if they're Super-H architecture or not.

Anyone wants the docs, files, code, etc. e-mail or PM me.

Rapnrev

Resolution is not the issue you can send the head unit to
tvandnav2go.com in Long Island, NY and they will fix it to play DVD movies and from what I've seen on the site it looks alright. $450 for them to make the adjustment not including cost to pull it out and re-install it.

ein Tier

Hell yeah! Now we're getting somewhere.

Please, send me the files and docs, I sent you a PM with my email. I don't code much Java today, but it paid my bills for about seven years.

We found some more numbers in the binary code today:
Also, I've been passing emails back and forth with SonarTech, who did most of the heavy lifting over at CadillacForums. I think it might be worthwhile to run this KIWI analyser on the LOADING.KWI file that's on his disc as well. I'm wondering if all LOADING.KWI files are essentially the same, or if they've changed over time or even from car to car. Since we only have this one, any others we can source would be welcome.