Zune

[GodEater]

No, I think you've missed the point. The cold boot hack might work - but you don't obviously do it to the ram in your PC - you do it to the ram in the Zune. The problem is that this requires :

a) a lot of clues
b) skill with a soldering iron
c) access to a lot of liquid nitrogen

No-one with the above list has bothered to try this. Or even shown up.

[bipton]

I realize that the system has full access to the zune and if there are many other ways of reading the ram why haven't they been tried? The cold boot hack gives you access to all the ram, I would say it bypasses any checks or locks that would otherwise be implemented to protect where the key for the zune is stored. Any hoot I will give it a few different attempts and let you know what I find.....If I find anything, also I will post the memory dump so someone alot brighter than me can try to find anything useful.

[bipton]

I pulled the drive out of my zune and dumped the first 500Mb using dd, if anyone wants to look at it I will bzip and upload it to gigasize or somewhere for you. My Zune isn't working anymore so I may have some hardware to donate later if I can't track down what happened, I think the zif cable may have got damaged.

[zivan56]

There's not much there except a standard FAT filesystem.  It simply stores the firmware as a regular file and reads it into memory (if it is properly signed).

[JonathanHull]

Okay. I had an idea. But I do want to state that I am no where near a good programmer, nor do I know the inner workings of DAPs, but something did come to mind. This may be way off the wall and infeasible, so just shoot me down if this is the case.

It seems that most of the attempts to load code into the Zune have been in the firmware loading or other things after the firmware has already loaded. What if someone were to try a few steps before, well before the firmware is loaded. If my understanding of how this works is even halfway correct it needs to read the partition table of the disk, mount it, then find the firmware file. Would it be at all possible to muck with the partition table to do a buffer overflow there? Somehow inject some code into the partition table that exploits the step that reads it, and then inject code before the firmware file is even loaded?

Just a thought here. Again, I know jack about this stuff so I could be way off, but it was an idea that came to me. Disregard if it sounds stupid.

[markun]

If my understanding of how this works is even halfway correct it needs to read the partition table of the disk, mount it, then find the firmware file. Would it be at all possible to muck with the partition table to do a buffer overflow there? Somehow inject some code into the partition table that exploits the step that reads it, and then inject code before the firmware file is even loaded?

Unfortunately the code is signed, so if we make any changes it will not be loaded anymore. The chance of getting our hands on the key to sign the code after the changes are made is extremely small.

[GodEater]

partition table of the disk, mount it, then find the firmware file. Would it be at all possible to muck with the partition table to do a buffer overflow there? Somehow inject some code into the partition table that exploits the step that reads it, and then inject code before the firmware file is even loaded?

Overly simplified explanation
Buffer overflows work by loading something which is bigger than the amount of memory set aside to contain it. For example, the code you're trying to exploit says something like "Load this bit of disk until you read character 'x'. The memory this is being read into is 256 characters long. So you can exploit this by having the data be over 256 characters long before it encounters the character 'x'. Partition tables however, have a known fixed size. This doesn't ever change, so the memory is always the right size for the partition table to sit in. This means it wouldn't be possible to overrun the memory allocated for it.

[theman4455245]

Ok, another idea that you may laugh at and I'm sure has been thought of but to put my 2c will make me happy.

What if the Zune drive was formatted from the Zune and then we try to load new firmware that way in Linux? Or does the drive lock up still? 

I'm betting I just didn't read enough and this has already been said. 

[saratoga]

Ok, another idea that you may laugh at and I'm sure has been thought of but to put my 2c will make me happy.

What if the Zune drive was formatted from the Zune and then we try to load new firmware that way in Linux? Or does the drive lock up still? 

I'm betting I just didn't read enough and this has already been said. 

As markun said, the code is signed, so you can't load new firmware.

[zivan56]

Out of curiosity, has anybody looked at the zconfig.dat file I uploaded among others?  It appears to have code in there, and I did not see any signature in the file.  The database files could be a potential weakness, especially if they can be used to trigger a buffer overflow (i.e char(x) field with a value >x ).
I think the lack of availability of this device worldwide is really hampering efforts, as Microsoft is not really known for it's security record.
Wireless sync also enables a UPnP on the Zune for a short period of time, which may be exploitable as well.

[ptw419]

Regardless if there was some type of exploit available such as a buffer overflow, or anything similar, you'd have to be able to get the exploit code to run. If you wanted the exploit code to run natively it would have to be signed with the Zune private key, or it wouldn't be able to run at all. It is a catch-22. How to run non-native unsigned code to exploit the native signed code. An unsigned exploit could come in the form of a file format exploit, maybe even as suggested previously exploiting the uPNP. These are extremely unlikely though, but not irrelevant. Interesting points of study would be WinCE 5 and 6 exploits. Similar concepts would be the Xbox 360 hypervisor hack :
http://www.xbox-scene.com/xbox1data/sep/EEZkykVkkFmojzapEq.php

For a better idea of signed and unsigned code, please read up on private/public rsa keys,document hashes, and certificate authorities. Here is a good site : http://msdn.microsoft.com/en-us/library/ms537361.aspx. 

Ways around Zune security would include :

  -Circumventing the digital signature verification process via software manipulation(probably  won't happen at this point since it hasn't happened already).

 -Hardware manipulation(not realistic for the typical layman including myself, and also unrealistic given the architectural layout of Zune hardware).

 -Obtaining the private key(probably illegal,if not very very difficult. More than likely ties in with the hardware manipulation)
 
 -Finding any unsigned code that is run and can be manipulated(Again if it hasn't happened already, it probably won't. Also I think the nk.bin image as a whole is signed, but might be wrong).

I'm not saying that these are the only ways and that there is not away, just giving an informed response to inform others....One other thing, availability of the device has nothing to do with it. The gigabeat S was far less popular than the Zune, and was based off the same hardware/software concepts and was cracked. Microsoft just had the sense to patch up the holes that were exposed by Toshiba.

[ptw419]

If by clear you mean if you were able to wipe the original firmware and put in a custom firmware image, then that is correct. The custom firmware would have to be signed. So it is either sign custom code, or exploit code that is already signed, or manipulate the hardware.

[GodEater]

I don't really think speculation belongs in this thread. If someone's got something concrete to add - then do - otherwise, please keep the thread clean.

[bipton]

I used strings to dump anything from the first 500mb of the drive I dumped into a text file, here is a link for the file if you want to look over it http://www.gigasize.com/get.php?d=54kcldjgf3f. Also I still have my zune, it is an 80Gb that isn't working, I think the cable got damaged along with the zif socket on the daughter board, I have an ipod drive in it now (which I believe has 1+ bad sactors). I want to donate to someone that can actually use it to MAYBE get a little further with it for the sake of RB.

[luinfana]

@bipton:

Thanks for that file upload...I'm giving it a look-over right now.

Can you tell me a little more about your broken 80GB? When you say broken, do you mean so far as it won't power on at all, that it powers on but fails to boot, or some other problem? Is the problem fixed with the iPod drive you have in it now?

I might be interested in accepting your donation, depending on what condition it's actually in - that would determine how much hacking I might be able to do with it. If someone with more experience or success than I've had is interested in this as well, then by all means send it to the most versed of us - I'd much rather see someone else with a lot of technical knowledge but no Zune try this out.

That said, I've tried the following with my own Zune (30GB, firmware 3.0):

* libmtp (everyone's done this, I guess) - file listings, dumping the device cert, listing compatible filetypes, etc. Looks nice in Amarok as well as on the terminal, but not yet useful due to the infamous MTPZ extensions and the encrypted USB control handshake, unless you want to delete songs.

* USB control packet-sniffing in Windows (using a combination of HHD Software USB Monitor 2.37 and USBSnoopy), and subsequent replay of the raw packets in Linux using a small app called usb-robot. Theoretically a correct replay of the relevant control data could open up connectivity to any MTP-capable application, and thus to platforms other than Windows. So far, however, all I've managed with this approach is to get the screen to light up (usually occurs in Windows as the software opens, before connectivity is established). This by far seems our best shot at getting the Zune un-tethered from Windows and its native software - this may seemingly have little to do with getting a RB port going, but if more cross-platform users get involved, the size of our "hackforce" could be increased significantly.

* I myself have not opened my Zune (and I don't really plan to), or messed with firmware images. I was very interested in mknkboot, the utility used for patching the nk.bin file on the Gigabeat S, but alas, the Zune's nk.bin is digitally signed and checksummed (?) at boot, eliminating any possibility of direct firmware patching. Unless of course one knows Microsoft's digital signature key. Which one does not.

* Not very important, but I should mention it anyway: the XNA game framework. We've discussed the possibility of building a player shell in C#, but as it turns out XNA is FAR too restrictive to build a player from. There's some tantalizing ports and wraps of ffmpeg and Tremor into C#, but apparently none of it will work on XNA, even with completely overhauled code. Even if something like an OGG decoder deployed successfully, where would it be playing files from? XNA won't allow access to anything other than the player's existing library, which makes this a dead issue. Buffer overflows and things like that, however, might not be out of the question - I have no idea, though. XNA seems pretty failsafed - the Zune just shuts off if anything screwy happens.

As far as materials to work with, I have:

* 1 Zune
* 2 iPods (both 4th-gen Grayscales, one driveless, the other with a 20GB drive)
* A 1.8" HDD to CF adapter (allows use of a CompactFlash card as a stand-in for a 1.8" hard drive - I'm not sure if that would work with the Zune's connectors or not...)
* Soldering iron, solder
* Ubuntu, Windows XP, Windows Vista
* Patience


...And that's about it. I don't think I've got any further than a lot of other people I'm seeing on sites like Zune Boards or on this thread, but I'm willing to give some more things a try. In my opinion, Zune would be an incredible platform for Rockbox - the device has excellent audio hardware, and it would be extremely liberating to be able to play FLAC and OGG instead of WMA and MP3. There's ample screen size, the processor is very fast for a portable media device (~500MHz Freescale) and 64 MiB of RAM to boot. The wireless functionality, although much-improved through firmware updates (wireless sync, Marketplace on-device, Channels) could be put to much, much better use with considerable effort (I'm thinking internet radio, RSS readers, podcast downloading - maybe even a minimalistic web browser). All dreams, of course, but I'm sure it's eventually possible if we can defeat these first roadblocks. If there's any group capable of unshackling the Zune, my money's on the Rockbox team.