Zune

[zivan56]

Here is an xml file from the hard disk (devcert.dat):

[EDIT: file moved to attachment]

Does this give any clues or keys?  I guess these are known already...
I have also zipped the filesystem and you can get it here:
http://rapidshare.com/files/112343487/tfat.zip

[zivan56]

I guess I forgot to mention that the filesystem appears to have unsigned files with executable binary code (relating to booting/memory/disk checks).  Maybe someone could have a look at that?

[Bagder]

The file 'zconfig.dat' contains several strings mentioning TFTP which I find interesting. You aware of any functionality in the Zune that uses TFTP?

[NicolasP]

Track sharing over wifi maybe?

[Bagder]

TFTP is often used for booting stuff why I'm curious. There are also others strings hinting about this possibility, like:

"SendBootme()::Error on SendUDP() call"

Further research on the "recovery.bin" file shows that it starts with B000FF \n which according to
this page is a file "generated by microsofts romtools". And the description there seems to match the initial bytes in that file. It mentions a 32 bit start address and length following that seven byte marker and there we see 80080000 and 00121C60 (little endian). Another funny thing is that if we run 'strings -el' on that image we get to see "0x80080000" and "0x00121C60" stored...

It is worth noticing that 0x00121C60 is significantly bigger than the recovery.bin file. 45873 bytes bigger to be exact.

Update: zivan56's 53MB fat dump is now also available here => http://daniel.haxx.se/rockbox/zune-tfat.zip

[saratoga]

Track sharing over wifi maybe?

TFTP is UDP based with almost no error resilience, I would not expect it to be used over any sort of wireless link.  Its mostly used over things like serial ports where you have 100% control over the line at all times and only send small files.

[zivan56]

Perhaps it uses UDP broadcasts when sending the name of the currently playing song over wireless?  I don't know of anything relating to TFTP...it is perhaps just for testing.  It could use TFTP and send the songs in sections...then just doing a hash check and re-requesting it if the chunk is incorrect.
I did grab some wireless packets before, and it does encrypt some things with WEP (or it just send a wrong 802.11 header out?).  Currently playing songs are broadcast unencrypted and in plain text (with a custom binary header).

recovery.bin might be modifiable, as it doesn't appear to have a signature.  I don't believe it is distributed with the firmware, so it may have not been tried at all.

[Bagder]

WEP is unsafe and it should be possible to retrieve the key(s) used, like with airsnort

I would rather expect the TFTP/UDP things to be used for a magic upgrade case or some special service mode or something and not something used in the ordinary system. Is it possible to upgrade this thing over the network?

[zivan56]

I would gladly crack the WEP key, but I have no other Zune.  It uses some sort of application layer encryption for wireless syncing, so that would probably need to be figured out as well; not to mention MTPZ encryption.
I don't know about firmware updates over wireless, but they are done over MTPZ.
Overall, they got it locked down pretty tight.  However, those files on the drive seem like good candidates to start off...

[Romanian]

Until someone figures out a way to bypass the encryption so unsigned code can be run, there's really nothing much that can be done.

It's a long shot, but has anybody tried asking Microsoft, or some representatives, or even ex-employees, if this is achievable? Or have we passed this stage already?

[Bagder]

It's a long shot, but has anybody tried asking Microsoft, or some representatives, or even ex-employees, if this is achievable? Or have we passed this stage already?

I don't think we ever will pass that phase as we can always use more info. Personally I have no contacts at all to approach to even start getting this info, but by all means contact your friends and ask!

[zivan56]

With the latest firmware and XNA studio, you can deploy your own games that have been written using the XNA framework in C#.
I didn't have much time to mess around with it, but standard I/O and filesystem API works.  However, it will not let you browse the filesystem using that.  Apparently, each game gets 16MB of runtime memory and has a theoretical 2GB max file size.  My guess is that there is a small .NET framework on there which seem to be locked pretty tightly.  I will try to extract a game from the HDD when I get the chance to see if it has any sort of digital signature.

[bipton]

Has anyone seen the article for cold boot hacking yet? Basically when you shut down your machine data is still in your ram for a small time, these fellas wrote an application that boots off a usb drive or pxe and immediately makes an image of the ram, they also provide a coupe tools for retrieving aes and rsa keys from that image. They tested it to retrieve keys for various hard drive encryption solutions and were successful. I'm curious if you could boot up xp, launch zune, connect the device, and kill the power abruptly after the device connected. Reboot from the usb drive, dump the ram, then search for the key. Here's the site from the fellas that did it, they have video, documentation, and source code. http://citp.princeton.edu/memory/

[GodEater]

Yes, we've seen it - No, no-one's bothered doing it.

[JonathanHull]

And I honestly don't think it's necessary. The cold-hack method is for reading the ram on a system that you have physical access to, but not login access. What you are suggesting is doing this to a machine that the zune is connected to, which you already have full login access to, so there are many other ways to read the ram without having to do the cold hack.