I'm still researching a way to get into the actual OS part of the Z, and have come across something from the XBox community that may be of use to us here at avic411.

http://forums.afterdawn.com/thread_view.cfm/357863

Seems they've jury-rigged an EEPROM reader, and used a program called LiveInfo to reveal the HDD key. This could potentially be used to unlock our Z drives without having to use a pay service.

I'm making this new thread to be a dumping ground for ideas/links/resources for anyone who wants to participate in this little project I've embarked on.

I don't think the password is stored in the OS. The Xbox EEPROM doesn't contain the OS, I think it only contains the password and possibly other configuration data. The Z probably does have an EEPROM though.

If you just want to get to the OS part, you can already get to the OS files, just download the Z1 or Z2 program updates. The file you're looking for is EU060PLT.PRG. It contains the OS and the OS files can be dumped using PPC2003 extract tools.

Thanks for your input, I'll look into that.

Just as a note, I'm throwing this in here.

Playing around with my drive today (not with the chip, I haven't had a whole lot of free time lately) and I've imaged it to a clean Z3. Burnt two albums and here's some things I've found:

THIRD PARTITION

Genres are stored under /HOLD/MUSIC/GPL01.

Album titles are stored under /HOLD/MUSIC/OPL**.

Your playlists are stored under /HOLD/MUSIC/PLDAT**.

Your favorites and mixes are stored under /HOLD/MUSIC/UPL01.

The album playlists are stored under /HOLD/MUSIC/APL**.

I noticed something interesting in the MUSIC folder on this partition as well... all the song files on the AVIC-Zx are .at3 files. This is the same file format for music on the Sony PSP. Of course, as I'm sure others have, I immediately tried to convert the at3 to mp3 using GoldWave, to see if it would be feasible to do it the other way as well (mp3->at3), but I just got a lot of static. I also tried HIMdRenderer. I don't actually own a PSP, so can someone possibly pull a few of these ATRAC files from their AVIC and attempt to play them on their PSP using something like iR Shell? I'd like to see if maybe these files are encrypted/encoded a little differently than your normal ATRAC, and if so we may be shit out of luck for getting mp3s to our AVICs.

I'm out of time for right now but I'll post more thoughts/findings for anyone who is interested when I work on this again.

I noticed something interesting in the MUSIC folder on this partition as well... all the song files on the AVIC-Zx are .at3 files. This is the same file format for music on the Sony PSP. Of course, as I'm sure others have, I immediately tried to convert the at3 to mp3 using GoldWave, to see if it would be feasible to do it the other way as well (mp3->at3), but I just got a lot of static.

interesting, i wonder if the Z* units do some sort of low-grade DRM. Like, just a simple hash against the unit's serial number or some other value. Then all the files will only play on that unit. (?)

I think I'll poke around too for fun

Music installed on a hard drive can be played in another Z if the HD is moved to another vehicle.

Hi, I'm only a hobby-hacker but I'd be glad to contribute what I can. I've hacked about 30 or so Xboxes, and at least 10 of them with an eeprom reader. It was actually the easiest way to mod them in the end, I just clipped on the reader to the chip, read it with an on board power supply for safety, then pre-fabbed the new HDD with the password I swiped. There were two programs involved - Ponyprog which I believe is shareware - and LiveInfo which I think may have been Xbox specific. You could also flash your eeprom chip this way but I never made it that far in my explorations.

The whole process was almost identical to the Z3 upgrade except that Xbox drives are full size. You unlock the drive, transfer a proprietary drive image, relock the drive, install and voila!

I'm pretty sure you could not access the OS this way but you could definitely crack the EEPROM this way. You would need someone who could translate the data you receive into a workable HDD password though. That's what LiveInfo did. It compared the data received through PonyProg with your Xbox version and used an algorithm to determine your HDD pass. That's all way above my head though. Check out Xboxscene.com for the 411.

Good luck!!

How does the drive relock anyway? Is it on the OS level, or hardware level?

The fact there's an EEPROM makes me wonder if the relocking is a function of the ATA controller. However, if it were in the OS, someone could hack it and modify it to skip the relocking function.

Music installed on a hard drive can be played in another Z if the HD is moved to another vehicle.

You're absolutely right, and that's got me thinking that Pioneer is using a proprietary encryption algorithm on these music files. That's why I was interested to see if anyone could get them to play on a PSP.

To kronyk, thanks for the great input. Did you make your own reader, or did you buy it? If you bought it, which one is it? I've searched for clip-on ones but all I can find are the writers/programmers that you have to insert the chip into. I've got a theory that if you could access the data on that chip, you could of course copy all of it over to a storage medium and begin working with it that way. Then comes the question of whether Pioneer encrypted the OS for this unit or not. I'm really hoping they took the "security through obscurity" route and just figured no one would go through the trouble of hacking the OS and didn't bother protecting it.

My main mission in doing this right now is to see if those damn warning screens/prompts are indeed stored in the registry, and if so, to TURN THEM OFF!! A lot of people have been asking for this and I really want to see if I can get it done.

Oh, and sorry for lack of updates, I've been out of the U.S. for the last month or so.

Hey, do we know how to read the guidance audio files?

My main mission in doing this right now is to see if those damn warning screens/prompts are indeed stored in the registry, and if so, to TURN THEM OFF!! A lot of people have been asking for this and I really want to see if I can get it done.

They're not. I posted the registry awhile back, there's no reference to the warning screens. I think it's hard-coded into the application files. The OS is NOT encrypted, it can be dumped in the same way as Windows Mobile 2003 (with dumprom.exe).

That's funny...

That's how I unlocked my first Z2 drive... I have an original Xbox modded with the Xecuter X3 chip.... Well...it could unlock the drive, but for some reason the disable lock didn't work...

Anyone know assembly language? I found some possibly interesting code in Navi.exe that might be related to that annoying warning message. I don't know assembly at all so none of this makes any sense to me...

---------------------------------------------------------------------------
.text:00108EA2                 .align 4
.text:00108EA4 off_108EA4:     .data.l ?NP_Printf@@YAHPBDZZ ; DATA XREF: .text:00108E90r
.text:00108EA4                                         ; NP_Printf(char const *,...)
.text:00108EA8 off_108EA8:     .data.l aUin_win_safe_1 ; DATA XREF: .text:00108E92r
.text:00108EA8                                         ; "UIN_WIN_SafetyCaution::GetPlCaution() r"...
.text:00108EAC ; ---------------------------------------------------------------------------

.data:00615244 off_615244:     .data.l aUin_win_safety ; DATA XREF: .text:off_9DD08o
.data:00615244                                         ; "UIN_WIN_SafetyCaution"
.data:00615248 aUin_win_safe_0:.sdata "UIN_WIN_SafetyCaution" ; DATA XREF: .text:off_9DE88o
.data:00615248                 .data.b 0
.data:0061525E                 .align h'10

.rdata:0048396C aUin_win_safety:.sdata "UIN_WIN_SafetyCaution" ; DATA XREF: .data:0061520Co
.rdata:0048396C                                         ; .data:off_615244o ...
.rdata:0048396C                 .data.b 0
.rdata:00483982                 .align 4

UIN_WIN_SafetyCaution is the function that caught my interest. Just a guess...

UIN = User Input

WIN = Window

SafetyCaution = The annoying message.

So it seems like this might be the function that pops up the annoying caution message, in a window, requiring user input.

I think you're on to something there.

I've attached my 2 cents for that file.

I'm going to work more on this, give me a few days and I'll check back.

navi.txt

Ok, totally guessing here, but here's where I think it's doing the check.

---------------------------------------------------------------------------
.text:00108E84
.text:00108E84 loc_108E84:                             ; DATA XREF: .rdata:004F850Co
.text:00108E84                 sts.l   pr, @-r15
.text:00108E86                 add     #-h'10, r15
.text:00108E88                 bsr     sub_108DFC
.text:00108E8A                 nop
.text:00108E8C                 tst     r0, r0
.text:00108E8E                 bf      loc_108E9A
.text:00108E90                 mov.l   @(h'10,pc), r3 ; [00108EA4] = ?NP_Printf@@YAHPBDZZ
.text:00108E92                 mov.l   @(h'14,pc), r4 ; [00108EA8] = aUin_win_safe_1
.text:00108E94                 mov.l   @r3, r3
.text:00108E96                 jsr     @r3
.text:00108E98                 nop
.text:00108E9A
.text:00108E9A loc_108E9A:                             ; CODE XREF: .text:00108E8Ej
.text:00108E9A                 add     #h'10, r15
.text:00108E9C                 lds.l   @r15+, pr
.text:00108E9E                 rts
.text:00108EA0                 mov     #1, r0
.text:00108EA0 ; ---------------------------------------------------------------------------
.text:00108EA2                 .align 4
.text:00108EA4 off_108EA4:     .data.l ?NP_Printf@@YAHPBDZZ ; DATA XREF: .text:00108E90r
.text:00108EA4                                         ; NP_Printf(char const *,...)
.text:00108EA8 off_108EA8:     .data.l aUin_win_safe_1 ; DATA XREF: .text:00108E92r
.text:00108EA8                                         ; "UIN_WIN_SafetyCaution::GetPlCaution() r"...
.text:00108EAC ; ---------------------------------------------------------------------------

I think the BSR on 00108E88 is running a subroutine that plugs a memory location into r0, whatever that is... a register?

TST on 00108E8C is comparing r0's current value to r0's past value.

BF loc_108E9A says branch if false, so if the TST above it returns false, it skips a bunch of crap, which I think is calling functions to display the safety message.

I thought maybe replacing BF with a BRA to branch always might do the trick, but BRA is a delayed branch which means it will execute the command after it, so rather than replacing the BF with something, I replaced 00108E8C thru 00108E96 with NOP (No Operation) to skip right down near the end of the subroutine.

I'll try copying my modified NAVI.EXE to my spare hard drive and see what happens. It'll either work, make no difference, crash, or not even try to run it if it does a checksum test! I wouldn't know what a checksum test looks like so I have no idea if it does that or not.

D'OH! Back to square one. Apparently there's no checksum checking, but the modified Navi.exe didn't make one bit of difference.

Hey do you think you could make an image of the Windows install on the AVIC? I'd really like to pick through it if it wouldn't be too much trouble to you.

Also, I looked through the registry file that you posted earlier and I think you're right about NEventWatcher.exe. See this link for details: http://www.informit.com/articles/articl ... 2&seqNum=7

If you can, try removing the following lines from the registry and see if that takes out the nag screen (also, make sure you make a backup first, this may break more stuff than we want):

"Depend90"=hex:1e,00
"Launch90"="NEventWatcher.exe"

So after removing that, the whole section should look like this:

[HKEY_LOCAL_MACHINE\init]
"Depend30"=hex:14,00
"Launch30"="gwes.exe"
"Launch20"="device.exe"

It's a shot in the dark, but it may work.

Not sure what you're wanting, the files extracted from the firmware dump? I can send you those.

Unfortunately, I can't modify the registry. I was able to extract it from the firmware dump and convert it from an .fdf to .txt file, BUT I can't convert it from readable .txt back to .fdf. Even if I could, I don't know how to re-insert it into the firmware dump... and another problem after that, is I think the AVIC probably does check firmware checksum upon flashing. Now assuming I get past all that... flashing a bad/corrupt firmware could brick my AVIC, that makes me a little nervous. It's possible I can recover it by going into the Service Menu and force it to flash a good firmware, but that's assuming the Service Menu still works after a bad flash.

Anyhow, I think there are tools on how to convert .txt to .fdf and build the individual files back into a flashable firmware, but I haven't found those tools yet. They would be the same tools people use to build custom Windows Mobile 2003 ROMs back when that was current, so I know they're out there.

I think NEventWatcher.exe is the main shell program. I believe it catches button press events, screen touch events, that kind of thing. I'm thinking removing it will just result in an AVIC that hangs at the Pioneer splash screen.

I definitely hear you on bricking your AVIC, I don't know what I was thinking there.

In theory it certainly would be possible to flash changes to the OS and the registry within, but I don't want you to potentially ruin your HU. Sorry I made the suggestion. I REALLY freakin need a test box, but my girlfriend's birthday is coming up in August and I don't have the funds to put forward to buy another AVIC right now.

I really WOULD like the files you got from the dump you did, also what reader are you using to access those files? Did you make it yourself or did you buy it? I'd like to get one but all I can find at Fry's are the drop-the-chip-in kind.

I tried getting Platform Builder for you but I can't find it anywhere. I'll keep my eyes open, I'll also ask around at my shop to see if maybe we have it in our software inventory. The Marine Corps is moving over to XP though so I highly doubt we'll have it, but I'm hoping to be pleasantly surprised.

Once you get those files to me, I'm going to see if I can dump NEventWatcher to hex and play around with that. This egg needs to be cracked, you and I are too deep into this to give up now.

Edit: The most frustrating part about this is that the value or procedure call we need is probably right under our noses, and would take about two seconds to edit. The real bitch is finding the damn thing without FUBARing the rest of the OS or firmware.

Here's the link to the dumped files:

http://rapidshare.com/files/133365294/AVIC_Z3_Platform_Dump.rar

I think MAYBE the utility I used to extract the files from the firmware image can insert files as well, but I'm a little afraid to try it.

I didn't need a reader at all to get the firmware... if you go into the hard drive, you will find two identical folders, PRG0 and PRG1. I have no idea why there are 2 copies, I found only PRG0 is used and a binary compare shows they are identical. Anyway, inside those folders is a PLATFORM folder. There you will find the firmware image: EU060PLT.PRG. The AVIC bootloader seems to do a compare of the EU060PLT.PRG to its existing firmware and will flash its firmware if the version on disk is newer. This is why simply copying a Z3 hard drive works to update a Z2 or Z1. You can go into the Service Menu and force the firmware flash to older or newer versions as well. Anyhow, I just took the .PRG file and noticed it's a fairly standard CE 4.2 ROM image so I tried DUMPROM.EXE (for WM2003) on it to extract the files and it worked.

I think there is no bootloader image inside the PRG file. This means you can modify the PRG file and even if you flash a bad/corrupt copy, you can recover by going into the Service Menu and forcing it to flash a good firmware back in. However, I'm not willing to risk my expensive toy to prove that theory! A spare would be great, but they're a bit too expensive to buy a spare. Ideally, we should have someone with an AVIC that's under warranty try it, and if it gets bricked, they can get it fixed under warranty, just say "it just quit working, I don't know why!"

I'm still almost convinced the safety warning is somewhere in Navi.exe. If that's the case, we can pretty much play with that without worrying about permanently disabling the AVIC.

Yeah, I think Platform Builder is the key to having some real fun with the AVIC. I believe Platform Builder can recompile any of the CE OS files as SH4 binaries. Unfortunately, Z-series hacking is limited due to the SH4 being fairly rare for CE devices. The F-series guys are at a huge advantage since the F-series uses an ARM CPU and they even have a full set of CE libraries and Windows CE Explorer built-in too!

My mistake, I was under the impression that you had dumped the OS files off the ROM chip inside the HU itself. I'd like to do that, but I can't find a clip-on EEPROM reader.

Thanks for the info on the firmware, I'll definitely play with that.

I bet there's two PRGs (PRG0 and PRG1) because one is the main and one is a backup. If you messed up PRG0 you could probably just remove it and rename PRG1 to 0. Just a theory though, I haven't even looked at it yet except to play with Navi.exe. I also think you're correct on Navi.exe. Too bad I don't know assembly, although I do have a book on reversing. If you want a PDF copy I'll be more than glad to send it to you.

Yep, you can rename PRG1 to 0 and it will work. I've tried that already just to try to figure out if it keeps a copy to prevent tampering or what. So far, I haven't really found out why it keeps a second copy because it doesn't automatically replace tampered-with files.

I don't know assembly either. I keep wishing if I stared at it long enough, I'd start picking up something. It doesn't seem to be working out that way!

I might have that same book on PDF... is it "Reverse Engineering Code with IDA Pro"?

I'll send you details in a PM.

To kronyk, thanks for the great input. Did you make your own reader, or did you buy it? If you bought it, which one is it? I've searched for clip-on ones but all I can find are the writers/programmers that you have to insert the chip into. I've got a theory that if you could access the data on that chip, you could of course copy all of it over to a storage medium and begin working with it that way.

Sounds like you guys are on to some major stuff.........

I hope my 2 cents can help. The EEPROM reader I used was homemade, the parts cost me about $12 at the local electronics store. Wrapped it all up in a case with a 9v power supply (regulated to 5v at the chip) in case the chip's supply fails during transfer. Credit goes to Unicron1 at the Afterdawn forum, though I'm linking this without permission. It's an old thread:

http://forums.afterdawn.com/thread_view.cfm/357863

I never used a chip clip or aligator's, I opted for the full on solder for my contact points. With the Xbox there was an LPC header that corresponded to all the pin locations so soldering was easy ---- probably not the case for the Z*. Once it was hooked up you can read or flash your eeprom with any software. I used ponyprog, but I've heard there's others out there.

I just bricked my first Xbox with a bad BIOS flash yesterday ----

Had to pull out the old reader to recover the HDD and thought I'd follow up here. Seems like good timing! I found out something else interestingly similar to the Xbox and AVIC in the hard drives too. In the early Xbox days softmodders were having trouble with HDD recognition when upgrading to non-OEM drives. This is due to proprietary drive recognition between the box and HDD, and was finally solved by editing cluster values to match an OEM drive. I had a light bulb go on while I was using Hex Workshop to prepare my new 750G Xbox drive, and I was looking at my Z3 upgrade drive sitting right beside.

Xbox scene tutorial on drive preparation, it's similar to the Z3 upgrade minus the hex editing:

http://www.xbox-scene.com/articles/no-m ... d-swap.php

I've searched the forum for about 3 hours now and haven't found anything similar to this idea, and I know it's off topic in this thread, but I figured you were the guys that might be able to do something with it. So no lashing please, I'm just trying to help!

I wish I knew coding so I could help more, but I'm better at 'search and destroy' missions when I'm modding ---- I do what I need to get the job done. There are just too many similarities in these hacks to not take notice!

You know, I've spent some time looiking over the Avic Z's schematics.... just looking for the opertunity of a Xbox style mod, where you can jump in front of the BIOS, and run your own code via a soldered in chip job...

This would be the ideal OS, being that if others (not me) could write code to take advantage of the Z's hardware and peripherals....It would be kewl to have BT tethering for internet...etc...

http://www.ubuntu.com/products/mobile

Hell.... even cramming a Sony PSP with GPS functionality in the unit would be sweet as apple pie...