Is there a way to make the AVIC-D2 skip that initial warning screen you get when you first power on the unit? It's not a huge deal, but annoying to have to reach over and hit the 'okay' button every time I start up the car. I'm guessing there probably isn't an easy way to do it, since this is most likely a software issue.

I have an Alpine nav unit in my other car with the same sort of warning screen and was never able to bypass that, either. One thing I've always liked about my Garmin Streetpilot III portable unit is that there is (believe it or not) an option in the settings to disable the boot-up warning screen. Handy.

Search is your friend. This has been discussed over and over again.

No there is no way to disable the screen.

Some people on the Acura forum managed to hack their factory nav to bypass the warning screen, but the Pioneer system has a different CPU and architecture so we can't hack ours the same way. It basically involved disassembling and reverse-engineering the code.

I want to hack ours very badly, but the software image is compressed somehow. At least, when I try to disassemble it with a disassembler, the listings don't make sense. I got stuck there because I'm not smart enough to get past that point and I seem to be the only person interested in doing this.

I have the voice command kit on my n3, and the voice commands automatically activate so I just have to say "OK" when turning on the car.

...I seem to be the only person interested in doing this.

nope.

The OS loader starts around 0x1000. I can disassemble there no problem. Another chunk starts at 0x1200. It's using the NEC RX OS. I'll attach some of the documentation I've found so far and the disassembler I'm using.

I'm also stuck without a memory map of where the code is loading. There is a memory dump feature in the service menu, but I don't have enough time to search through it. Once we get a good memory map, we can start mapping the functions....shouldn't be too hard from there.

Another interesting idea would be if we could get into the memory dump while the interface is running, then we could look for the location of the global that stores the flag.

necdocs.zip

Jefbarn,

Good to see someone else working on this, sounds like you've found more info than I have! Looks like you found the same Nintendo Virtual Boy disassembler that I was using too. I recompiled it with VS.NET 2005 so it has the ability to disassemble larger chunks (or the whole file if you want) and also adds some V830 opcodes so there are fewer invalid opcodes. I've attached it in case it's useful.

For some reason, when I start disassembly at 0x1000, there are "Invalid opcodes" at 0x1030. Is that in your listing too?

V830_dis.zip

Thanks for the updated disassembler, it should help eventually. I'll try to take a look at the code, but I'm going to be pretty busy this week.

Search is your friend. This has been discussed over and over again.

I apologize. I am actually a big user of the search function (and have often told people the same thing), but for some reason I was unable to come up with anything useful. Sorry about that.

-joe

...I seem to be the only person interested in doing this.

 

nope.

 

The OS loader starts around 0x1000. I can disassemble there no problem. Another chunk starts at 0x1200. It's using the NEC RX OS. I'll attach some of the documentation I've found so far and the disassembler I'm using.

Thanks for posting the instruction set documentation -- I'm going to try to write a V830 processor module plugin for IDA Pro, and will be happy to share my results. (There was talk on a thread on another board (http://cl.acurazine.com/forums/showthread.php?t=169301) that mentioned using IDA Pro, but as far as I can tell it was in error -- the latest version does NOT have support for this chip.)

FWIW, the service manual for the D1 breaks the files out as follows:

UC050BOT.USA: Bootloader

UC050SYS.USA: System Software / OS

UC050GPS.PRG: GPS firmware

EU050APL.PRG: Application code (loaded into SDRAM)

UC050DAT.USA: Language data

Any one know where we can find that bootloader, and does anyone know where the nag message is stored? (as a bitmap, as text?)

-b

Thanks for looking into this, bushing. I'd definitely like to hear about your results if you can figure something out.

Nothing too crazy yet -- but I did find the text for the warning message in UC050DAT.USA.

String 1424 (offset=4a88): 'CAUTION: This Navi product is intended solely as a driving aid.  Review instruction manual and select route before driving.  Navi is not a substitute for your attentiveness, judgment, and care while driving or moving your vehicle.  Always observe safe driving rules and driving laws, and follow road signs even if they contradict Navi's instructions.  By pressing OK key, you accept the license agreement in the instruction manual.'

I'm attaching a parsed list of the strings from that file, and the simple C program I wrote to make it.

Assuming we do eventually figure out what needs to be patched, what's the easiest way to test it? Please don't tell me we'll have to burn a new DL DVD-R each time!

uc050dat-strings.zip

Assuming we do eventually figure out what needs to be patched, what's the easiest way to test it? Please don't tell me we'll have to burn a new DL DVD-R each time!

I think it's possible to slim down the map disc to fit a single layer disc by omitting some POI's and such. Then you can burn it to a DVD-RW.

Does that mean we can edit the text at least? If so that could be kinda funny.

Does that mean we can edit the text at least? If so that could be kinda funny.

Probably not until someone figures out the checksum.

Ahh it was worth a shot.

Hmmm, that could be funny, especially if we can custom tailor the warning for different customers.

Does that mean we can edit the text at least? If so that could be kinda funny.

 

Probably not until someone figures out the checksum.

Is there a checksum? (It looks like the last 16 bits of the file *could* be one.)

Does that mean we can edit the text at least? If so that could be kinda funny.

I'd much rather just not have the screen pop up at all.

Does that mean we can edit the text at least? If so that could be kinda funny.

 

I'd much rather just not have the screen pop up at all.

That would be nice too. I'm more interested in playing a prank on a couple buddies of mine who have avics.

Does that mean we can edit the text at least? If so that could be kinda funny.

 

Probably not until someone figures out the checksum.

Ok, you're right -- there is a checksum. I tried editing UC050DAT.USA and reburning it, then used the service mode menu to force-update the application flash. It worked, but when the unit restarted, it said "beginning program update", tried to reflash (again) off the same DVD, said that the update was corrupt, and then rebooted -- I had to eject the DVD to get it out of a loop.

(Maybe this isn't news, but) I think the checksum is the last 16 bits of the file. Here's what I make of the header:

0000000: a55a 5aa5 7300 0002 5543 3035 3044 4154  .ZZ.s...UC050DAT
0000010: 0000 0000 5553 4100 2ead 0000 4000 0000  ....USA.....@...
0000020: b074 0000 aaaa aaaa aaaa aaaa aaaa aaaa  .t..............
0000030: aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa  ................

a55a 5aa5 = magic number

7300 0002 = version number (2.00.0073)

5543 3035 3044 4154 = filename 'UC050DAT'

0000 0000 = padding?

5554 4100 = extension 'USA'

2ead 0000 = 0x0000dae2 = 44334 (filesize)

4000 0000 ? (same for all three languages)

b074 0000 = 0x74b0 ?? this is 0x7ee8 for .ESP and 0x7dec

aaa... padding out to 64 bytes

End of file:

000ad20: 2201 ffff 0000 0000 0000 0000 700c       "...........p.

I think the 700c is the checksum.

Unfortunately, the program files look similar:

0000000: a55a 5aa5 5000 0102 4555 3035 3041 504c  .ZZ.P...EU050APL
0000010: 0000 0000 5052 4700 0000 4400 0100 0000  ....PRG...D.....
0000020: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000030: ffff ffff ffff ffff ffff ffff ffff ffff  ................

a55a 5aa5 = magic number

5000 0102 = version number (2.01.0050?)

4555 3035 3041 504c = filename 'EU050APL'

0000 0000 = padding?

5052 4170 = extension 'PRG'

0000 4400 = 0x00440000 = 4,456,448 (filesize)

0100 0000 ? attributes or flags, maybe?

ffff... padding out to 64 bytes.

End of the file:

043fff0: ffff ffff ffff ffff ffff ffff ffff d8c8  ................

checksum = d8c8?

Any guesses as to how they're calculating that value?

The OS loader starts around 0x1000. I can disassemble there no problem. Another chunk starts at 0x1200. It's using the NEC RX OS. I'll attach some of the documentation I've found so far and the disassembler I'm using.

All I get is garbage at 0x1000 -- 0x1200 looks more promising. (we're talking about UC050SYS.USA, right?)

BTW, I'm not sure if there's a difference in the instruction sets, but the chip in the AVIC-D1 is a "UPD705103GM-180S1". I can't find a datasheet for that anywhere, but I did find one for the UPD705102GM (aka NEC V832), which at least has an identical pinout to the one in the unit.

http://www.necel.com/cgi-bin/nesdis/o006_e.cgi?article=UPD705102

I've still been working on this, off and on for the past few months. I wrote a V830 disassembler plugin for IDA Pro. While it's not perfect, it works well enough to disassemble most of UC050SYS. I believe the code that verifies the checksums is in there, but I haven't been able to figure out where.

Does anyone here read assembly? I'd be happy to email my partial disassembly...

Nice so how do you change the text?

Excellent work! Did you have to decompress anything within the files? When I loaded it with a hex editor, I didn't find any obvious ASCII for that message.