I'll return to the Zune posts in ~2 weeks with some info on the ROM files, and changes between versions. Eventually, I hope to have a profile of every chunk of code on that system available for reference. I'm also working on a little thing for my car, may put details of that up, to.
Some random thoughts before then:
Zune-linux.com died again - very strange, and now the zune hack scene appears even more dead than before.
This crackdown on console mod chips is revolting. The car analogy is appropriate here: this is akin to raiding the garage that installs aftermarket parts in your car.
Friday, August 3, 2007
Wednesday, June 13, 2007
Corrupting pmcstore
Using the same procedure as before, I changed the first byte of the pmcstore.edb file. Upon reboot, the zune works, and I browsed the system settings. Shut it off, look at the db file again - we have the first 4 bytes changed. No verification? I don't know, and want to find how badly I can break this file (and in what ways) before it stops working. It would be easier if I knew the format for this db. EDB is a common extension - exchange uses it, as do several 3rd party vendors.
Side note: I'm trying to keep up with the various zune forums, rockbox, libmtp, and of course, http://zune-linux.com/ (I post as 'cross' there). Other handy reading material on msdn, and xda developers forum.
Side note: I'm trying to keep up with the various zune forums, rockbox, libmtp, and of course, http://zune-linux.com/ (I post as 'cross' there). Other handy reading material on msdn, and xda developers forum.
Wednesday, May 9, 2007
Zune hard drive and boot-up details
None of what follows is new, this is just my 'lab notebook', posted here for my own benefit, and maybe other zune modders.
I've taken apart my zune, per the guide at rapidrepair.com. With some adapters, I can mount the zune hard drive in my choice of OS. The device has two FAT32 partitions, one for media, and the other a 'system' partition of ~150 Mb. The sys partition (shows up with label 'TFAT' in Explorer) contains:
nk.bin, eboot.bin, recovery.bin, pmcver.dat. and pmcstore.edb, which is a database of the user settings (radio presets, theme, etc.)
The media partition contains: drmstore.dat, MediaLibrary.edb, MediaLibrary_thumbs.edb, devcert.dat, and a directory for your content.
With direct access to the system files, I tried the following. First, power on zune with no hard drive connected. The Zune logo appears, and then a graphic of a zune, a yellow circle with the number 5 (a status code, I assume), and "Contact Support" printed in three languages. Using the XVI32 hex editor, I changed a single bit in eboot.bin. Put the hard drive back in. The results: Zune logo, progress bar with status code 3 and "Please Wait". The device appears to restart (screen blanks briefly) and we see status code 1, "Connect Zune to your PC".
I shut it off, and put the hard drive back in my pc. The system partition was blank. So I copied the original files back over to it. Now it works like new. I did the same procedure three times with each bin file, and with the same results. The second trial, I switched the zune off the moment I saw the "Please wait" screen. It had already wiped the partition. The last time, I left nk.bin broken and changed recovery. Why I did this is explained below.
My assumption of how things go:
1. The CPU loads a copy of eboot from the flash ROM, checks it for errors, and runs it. (This is probably when the zune logo first appears)
2. Eboot checks the system partition for errors. If everything's fine, it loads nk.bin from the hard drive and boot proceeds normally. (I'm guessing this is the progress bar)
3. If Eboot finds a problem (signatures don't match), it wipes the system partition and reboots Recovery.bin from flash ROM. I'm not sure how this happens, but the Recovery file on the hard drive is not loaded at reboot (or it wouldn't have rebooted in experiment 3)
4. Recovery looks for zune pc software and reloads the OS (I haven't tried the 'approved' way of doing this, copying the files back seems to work fine)
Further directions:
I know a little bit more about the boot process now, but there are still lots of questions. My next attempts will be at corrupting the edb databases - I'm not sure if anything beyond the bin files is checked or not.
I've taken apart my zune, per the guide at rapidrepair.com. With some adapters, I can mount the zune hard drive in my choice of OS. The device has two FAT32 partitions, one for media, and the other a 'system' partition of ~150 Mb. The sys partition (shows up with label 'TFAT' in Explorer) contains:
nk.bin, eboot.bin, recovery.bin, pmcver.dat. and pmcstore.edb, which is a database of the user settings (radio presets, theme, etc.)
The media partition contains: drmstore.dat, MediaLibrary.edb, MediaLibrary_thumbs.edb, devcert.dat, and a directory for your content.
With direct access to the system files, I tried the following. First, power on zune with no hard drive connected. The Zune logo appears, and then a graphic of a zune, a yellow circle with the number 5 (a status code, I assume), and "Contact Support" printed in three languages. Using the XVI32 hex editor, I changed a single bit in eboot.bin. Put the hard drive back in. The results: Zune logo, progress bar with status code 3 and "Please Wait". The device appears to restart (screen blanks briefly) and we see status code 1, "Connect Zune to your PC".
I shut it off, and put the hard drive back in my pc. The system partition was blank. So I copied the original files back over to it. Now it works like new. I did the same procedure three times with each bin file, and with the same results. The second trial, I switched the zune off the moment I saw the "Please wait" screen. It had already wiped the partition. The last time, I left nk.bin broken and changed recovery. Why I did this is explained below.
My assumption of how things go:
1. The CPU loads a copy of eboot from the flash ROM, checks it for errors, and runs it. (This is probably when the zune logo first appears)
2. Eboot checks the system partition for errors. If everything's fine, it loads nk.bin from the hard drive and boot proceeds normally. (I'm guessing this is the progress bar)
3. If Eboot finds a problem (signatures don't match), it wipes the system partition and reboots Recovery.bin from flash ROM. I'm not sure how this happens, but the Recovery file on the hard drive is not loaded at reboot (or it wouldn't have rebooted in experiment 3)
4. Recovery looks for zune pc software and reloads the OS (I haven't tried the 'approved' way of doing this, copying the files back seems to work fine)
Further directions:
I know a little bit more about the boot process now, but there are still lots of questions. My next attempts will be at corrupting the edb databases - I'm not sure if anything beyond the bin files is checked or not.
Saturday, April 14, 2007
Zune Hacking
What I know:
Zune boot process:
imx31L loads Eboot.bin from ROM to protected on-cpu memory
Strips Verisign certificate, decrypts SHA-1 hash of image with on-cpu public key
computes SHA-1 of loaded image, compares to above.
If equal, Eboot loads NK.bin from system partition of HD
If not, Load Recovery.bin*1, whose only functionality is to connect (sync?) to pc, and
reload valid firmware.
Update Process:
I'm not clear if any verification happens when updating or not. Does the pc side check? The device? Both? Does the device verify before writing updates, or let the boot-time check catch
unauthenticated code?
Notes:
*1: I'm not clear on what gets loaded from where. Eboot is on the flash ROM. But where is Recovery.bin? One reference has it in ROM, the other says hard drive.
References:
Hardware info from
http://www.bunniestudios.com/wordpress/?p=131
http://forums.rockbox.org/index.php?topic=6848.0
Info on the imx31L ( the security features pdf is specially recommended)
http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=02XPgQ821729733642&tid=WMSG200506VANITYIMX31
Info on boot process and hard drive
http://zunerama.com/forum/index.php?&topic=1273.0
http://www.zuney.net/zune-hacks-mods/258-bad-news-firmware-hacking.html
Zune boot process:
imx31L loads Eboot.bin from ROM to protected on-cpu memory
Strips Verisign certificate, decrypts SHA-1 hash of image with on-cpu public key
computes SHA-1 of loaded image, compares to above.
If equal, Eboot loads NK.bin from system partition of HD
If not, Load Recovery.bin*1, whose only functionality is to connect (sync?) to pc, and
reload valid firmware.
Update Process:
I'm not clear if any verification happens when updating or not. Does the pc side check? The device? Both? Does the device verify before writing updates, or let the boot-time check catch
unauthenticated code?
Notes:
*1: I'm not clear on what gets loaded from where. Eboot is on the flash ROM. But where is Recovery.bin? One reference has it in ROM, the other says hard drive.
References:
Hardware info from
http://www.bunniestudios.com/wordpress/?p=131
http://forums.rockbox.org/index.php?topic=6848.0
Info on the imx31L ( the security features pdf is specially recommended)
http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=02XPgQ821729733642&tid=WMSG200506VANITYIMX31
Info on boot process and hard drive
http://zunerama.com/forum/index.php?&topic=1273.0
http://www.zuney.net/zune-hacks-mods/258-bad-news-firmware-hacking.html
Subscribe to:
Posts (Atom)