Tuxlex

I've been talking with some professionals at work who
test code for vulnerabilities including Microsoft's OS.
They are curently working on handheld code that uses
the same processor as our Denso nav unit. I believe
it is the Hitachi processor.

I remember reading in one of the forums where someone
dissasembled the various boards inside their nav unit.
It had pictures of all the boards and chips. It might have
been the Cadillac forum, I can't remember. In it, the
processor part number was specified. Could someone
point me to that processor number.

Knowing the processor, I could ask them to help me
disasemble the loading.kwi file. They said that they use
IDA Pro Advanced from DataRescue and that it works well.
http://www.datarescue.com/idabase/idaproc.htm
The manufacurer wants $875 for this disassembler with
optional support for another $10,000 per year. Hopefully, our
computer science department at work will be willing to
disassemble this code for us.

ein Tier

It was the Cadillac forums, in the thread Another Nav Diagnostic Code

SonarTech pulled his apart. He said "CPU (IC201): Hitachi SH-3E, HD6417718R"

I'm looking for the photos, he had to rehost them -- his post with photos is here.

For the record, you won't be decompiling the KWI file. You need to use Buffy's tool to extract the binaries inside that file and then decompile that. The KWI file format is a glorified database.

ein Tier

More codes to try. These came out of the SRX loading.kwi file. Best of luck with them.

Hurricane

bryanh

Didn't I read somewhere (perhaps in this thread) that the VSS wire was identified on our unit. Has anyone tried that? Personally the "wide open" NAV is the only thing I am interested in doing and I am at a point where putting a switch on the VSS wire is a viable option.

C6-er

I remember a thead were someone cut the vss wire with no joy.

bryanh

Oh, now that just ruined my day.

abrimberry

Tried all of the codes. No new screens appeared. No new functionality is apparent either. Thanks.

ein Tier

It looks like the leading candidate for the operating system is QNX. This article says:
This makes sense, as QNX is a very lightweight UNIX derivative, which explains the UNIX style file structures we've seen, the POSIX code, along with the X-windows system hooks. Buffy, if you have really extracted the binaries, a standard UNIX c decompiler should be able to decrypt that code, though it could also be written in C++. I don't have a compiler for either one, nor do I have access to a unix system, or I'd do it.

QNX also is often used on the Hitachi SH-3 and SH-4 chips, which is what our nav system uses.

I've been looking at the passwd.osg file, or rather, the reference to it. The osg file format seems to be a format for defining 3D images with markup text -- sort of how html works, but for static 3D images. I don't know what it's doing there, but I think it's safe to say it's not the password file we think it is.

Blu06Z06

webdzynes

Why isnt this post a Sticky?

Blu06Z06

Buffy

QNX is indeed a good candidate, as something with this much function could use more than the simple TRON-derived RTOS. The one hitch is that programs to run on QNX should be recognizable as ELF binaries, and I haven't (so far) been able to find ELF headers.

Regarding the source code, I do find a lot of apparent module names which imply the source code is indeed C:

MasterApp_Entry.c
..
MasterApp_Callbacks.c
ClockApp_Entry.c
ClockApp_Callbacks.c
..
HardSwApp_Callbacks.c
..
DvdxApp_Entry.c
CommonApp_Entry.c
..
CommonApp_Callbacks.c
..
CommonApp_Method.c
CDApp_Entry.c
CD2App_Entry.c
MP3App_Callbacks.c
MP3App_Entry.c
RadioBandApp_Entry.c
RadioBandAppAMTouchsw_Callbacks.c
..
RadioBandAppXM_Callbacks.c
..
RadioBandAppXMTouchsw_Callbacks.c
RadioBandAppXM_Entry.c
DiagSWInfoApp_Entry.c
DiagPartInfoApp_Entry.c
DiagTouchScreenApp_Entry.c
DiagScreenTestApp_Entry.c
DiagHardSWApp_Entry.c
DiagMicrophoneTestApp_Callbacks.c
DiagMicrophoneTestApp_Entry.c
DiagNaviApp_Entry.c
DiagNaviRGBApp_Entry.c
DiagVoiceOutputTestApp_Entry.c
ScreenAdjustApp_Entry.c
AdjustApp_Entry.c
AdjustAppTouchsw_Callbacks.c
..
SoundAdjustApp_Entry.c
StatusApp_Callbacks.c
StatusApp_Entry.c
DebugFunctions.c

ein Tier

Have you tried decompiling the 256k audio update? I think those c files are offloaded onto other memory chips, and we won't be able to get at them unless we either crack the nav open, extract the chips, and put them in a EEPROM programmer, or we get lucky with an update -- like the audio/mp3 capability.

Are you sure you're extracting the binaries properly? Forgive me, I've not had time to look at the code much, but when I played with the files, I was expecting to see a KIWI reader -- being able to see the database as a database and all its structures could be useful.

I now have access to a Ruby server, I may play with those Japanese Ruby KIWI readers. However, I'm currently working 80 hour weeks, so who knows.

Buffy

Well, I'm fairly confident as to the extraction. The Kiwi documentation is fairly complete if a bit hard to read; I find legible names where I expect them, the lengths add up, etc. So as far as the two files extracted from LOADING.KWI I'm pretty confident that they're what's there.

There's no sign that the stuff is encrypted or compressed, not that there's much point in compressing 25MB of stuff to put it on a CD-ROM! But if it were it wouldn't have the legible text strings we've found.

Most such devices use flash to store the code and fixed data but load it into RAM at boot time and run from there as flash is usually too slow to run from and requires a special write sequence.

Typically, fairly simple devices will have either a straight "core" image or some sort of relocatable binary code with fixups to link to ROM libraries or relocate the code to the target processor's address range. If it was just a core image it would almost certainly start with a branch to the beginning of the startup code. If it had relocation segments or whatnot it would have some sort of header and directory near the beginning, and most everybody uses ELF format binaries these days so I'd expect an ELF header (0x7F 'E' 'L' 'F').

More complex devices often treat the flash as a filesystem, often FAT or CRAMFS, in which case I'd expect a header and directory. I haven't found any recognizable signatures for that either!

What I've got is:

The first 2K block starts with 0x00 0x02 'X' 0x00 0x00 .. "GE141312" and is filled out with 0x00s. The "GE141312" makes sense, as it's the module name and version.

The second 2K block has a table of 256 8-byte entries. The first two bytes of each entry are a sequence number (0, 1, 2 .. 255). The remainder has bytes with equal nybbles, e.g. 0x11, 0x22 .. 0xFF. Doesn't look like addresses or displacements, maybe some sort of type codes or flags.

The third 2K block starts with "rGpaihDc BV 5046" .. "91990--4511 :000" followed by a bunch of 4-byte somethings with a definite pattern, typically starting with 0x2b, 0x2c or 0x2d and ending with 0x01. This could be some sort of interrupt vector table, I suppose, which is the sort of thing you'd expect to find in low memory.

Mostly, I've been hoping to find recognizable code in there and guess the offsets, etc. from that. Alas, the Super-H uses most of the bits, so looking for sequences of valid instructions doesn't work too well. I'll probably have to start looking for logical sequences - e.g. we'd expect compare instructions to be followed by conditional branch instructions. Or branches followed by no-ops, if it uses delayed branching.

As far as the audio file from disc 2, I haven't made a lot of sense of it either. After 16 0xFFs it has a table somewhat like that found in the other code, with four-byte entries ending in 0xFC 0x00. That would (possibly) put code starting at 0x000090, where we have:

00000090 1d21 MOV.L R2,@(01,R13)
00000092 5218 MOV.L @(01,R8,R2)
00000094 394a SUBC R4,R9
00000096 571a MOV.L @(01,R10,R7)
00000098 2834 MOV.B R3,@-R8
0000009A 6235 MOV.W @R3+,R2
0000009C 060c MOV.B @(R0,R0,R6)
0000009E 1524 MOV.L R2,@(04,R5)
000000A0 2016 MOV.L R1,@-R0
000000A2 2202 MOV.L R0,@R2

Which doesn't make a lot of sense.

Of course, I'm not all that confident of my disassembler - easy enough to get some things messed up in there.

As far as taking the Kiwi files apart and getting at the nav data, it shouldn't be too hard, but would take some time and wouldn't be that much use unless we wanted to write our own nav system. So far I've only done the stuff related to the LOADING.KWI file.

Hope things ease up on you soon - on me too, I've got a project due this month so I won't be able to fiddle too much. Unless I get lucky and things go better than expected or I find some free time!

ein Tier

well, someone managed to write a perl reader/browser for the KWI files. I have not played with it yet, as I have to install Perl on this machine first (and all these UNIX languages I'm rather rusty in), but I'll let you know if I have any success.

http://ian.blenke.com/projects/densonav/alldata.pl

Buffy

That reads and displays the ALLDATA.KWI file - the one on the update disc 2 is empty, so it doesn't say much. There's one on the actual data disc, I'll read it tonight and post what it says. Mostly, this is general info. Unfortunately, the Kiwi format is different for each of the many file types, frame types, etc. so it'll take a bit of doing to get it all decoded.

Hurricane

crosborne

Tuxlex, All,

I'm also a Lexus owner; an 2004 RX330 with 3rd gen nav, version 3.1; and on the lexusownersclub.com forums (I go by Coz there). I've learned more from this and the Cadillac forum than anywhere else. I'm also very interested in hacking the nav. I have been able to make back up copies of my OEM 3.1 version disk and a version 4.2, I copied a friends OEM 4.2 thinking it would work in mine. It doesn't, we have different generation NAVs, but the copy does work in his. I was wondering if I could take the more current info from his disk, replace the data from my version 3.1 diskand make a hybrid 3.1/4.2 disk That is how I wound up here, researching which files I would need to combine to make this work.

Also, Tuxlex. is your version 5.1 OEM or upgrade and what generation Nav do you have? You can look here to figure what generation you have.

06corvette

Interesting

I think we might find some stuff that let us have more control to the nav system