Okay, before this starts a freaking flame war, ive successfully reverse-engineered mp3 player firmware and found exploits which allow unsigned code before, and i know alot about this stuff. So if you dont want to help, or dont believe this is possible, please dont post
The zune has pissed us all off enough, so lets hack this thing.
People Ill Need:
1) Somebody(s) who can take apart there zune and do some dumps of the harddrive and can put it back into the zune.
2)Anybody who has advance technical knowledge, or experience in programming, and wants to help, or is willing to help.
What i need YOU to do:
1) Start messing with files, see if you can find a way to get the zune to crash. PM me if you find anyway. This is very open, anyway you can get the zune to crash, just tell me.
Dumps of the hard drive pretty much just have a system partition with the firmware's nk.bin, eboot.bin, and recovery.bin, as well as a few databases and configuration files. In addition, there is another partition for things such as media files and games.
The firmware itself can be dumped. If you have experience reverse-engineering firmware, you should know how to do it.
What do you expect to accomplish by getting the Zune to crash?
__________________
"Against logic there is no armor like ignorance." - Laurence J. Peter
buffer overflow would be my guess. finding ways to do that allows for injection of unsigned code.
Right, I know that it is used for buffer overflowing, but the Zune closes anything that does a buffer overrun, so I do not see how that would really help.
What probability is there that the code would even be able to be executed via a buffer overflow, anyways?
__________________
"Against logic there is no armor like ignorance." - Laurence J. Peter
Well, I don't know about the zune, but that's how the xbox was hacked and the ps3 was able to get homebrew, until firmware updates closed that down tight. I know the zune has that whole defensive level, but I'm pretty sure you can pretty much do whatever you want if you can get a device to overflow.
Yes a buffer overflow, i wasnt aware the zune closes any bugger overfill. When a overflow occurs because of a file, such as an mp3 or a jpeg, you can run any code you want, and do whatever you want from there.
A harddrive dumped with dd helps because i can scan that file for any kind of code that can be modified, if there is any unsigned code anywhere on the zune, its a possible hole.
Well, I don't know about the zune, but that's how the xbox was hacked and the ps3 was able to get homebrew, until firmware updates closed that down tight. I know the zune has that whole defensive level, but I'm pretty sure you can pretty much do whatever you want if you can get a device to overflow.
Sony allows people to install Linux on the PS3. They have an option that says "Install other OS". Sony even created a version of the Linux kernel specifically to work on the PS3. I have no clue where you get your information. PS3™ | Install Other OS
Quote:
Originally Posted by Xqtftqx
Yes a buffer overflow, i wasnt aware the zune closes any bugger overfill. When a overflow occurs because of a file, such as an mp3 or a jpeg, you can run any code you want, and do whatever you want from there.
A harddrive dumped with dd helps because i can scan that file for any kind of code that can be modified, if there is any unsigned code anywhere on the zune, its a possible hole.
I suppose you can try, but I doubt it would work, since the security on the Zune makes sure that any "risk" is stopped immediately.
All executable code on the Zune is signed, but all of the Zune's modules are in the ROM, so even if they were not signed, they can not be replaced.
Thanks for that link. Sadly on the partions there isnt much there. But one thing sorta interesting is, the playlist format:
HTML Code:
/store_00010001/Music/Green Day/21st Century Breakdown/01 Know Your Enemy.mp3
But the real harddrive isnt in that format. So there is a database that must look something like this (In Theory, this isnt what it looks like):
HTML Code:
Content 100 0 b.mp3=Music/Green Day/21st Century Breakdown/01 Know Your Enemy.mp3
Just something im thinking about,
Also, not even one byte of any of the .bin files can be changed, otherwise the Zune will require the (official) firmware to be reinstalled, so modifying the firmware itself is not a possibility.
__________________
"Against logic there is no armor like ignorance." - Laurence J. Peter
There was a recent thread on the board, about this. The Rockbox team has been trying to accomplish this, but no luck as of yet. Here's the thread, for your reference:
Sony allows people to install Linux on the PS3. They have an option that says "Install other OS". Sony even created a version of the Linux kernel specifically to work on the PS3. I have no clue where you get your information.
I'm not refering to linux. I'm refering to homebrew based games using blueray/java. You'd have to look it up, it got closed down months ago.
There was a recent thread on the board, about this. The Rockbox team has been trying to accomplish this, but no luck as of yet. Here's the thread, for your reference:
I was very involved with the gigabeat s port. The gigabeat was also signed, but a tool was developted to bypass the signature: [rockbox] View of /trunk/tools/mknkboot.c
Also, can somebody verify this: But i looked threw recovery.bin and couldnt find a signature anywhere, and what is recovery.bin used for?
I am pretty sure the Zune internally makes sure that everything is signed. Any file that is replacable will fail the signature checking if it is replaced by a non-signed file, or modified. So that means if nk.bin or eboot.bin are modified, the Zune will probably prompt you to install the real Zune firmware.
Has anyone tried to use that method on the Zune?
recovery.bin contains bit of information (in case the Zune needs to be recovered, I suppose).
It contains these three files:
Quote:
ceconfig.h
default.fdf
initobj.dat
ceconfig.h contains a list of defines for the modules and features that the Zune supports.
default.fdf contains the default registry entries.
initobj.dat just contains useless copyright notices (Microsoft Corporation, and Freescale Semiconductor, Inc.)
__________________
"Against logic there is no armor like ignorance." - Laurence J. Peter
Here's my solution: open the Zune, give it a new blank hard drive (The Toshiba ones), give it the new Firmware-BAM!Get it to be recognized as mass storage!
My serious opinion(The above was a joke, a bad one at best)
It seems like the only way is buffer overflow.
__________________
Formally SmileDog.
Note: I prefer to have conversations over Skype, not over PM.
You will be bottom priority if I happen to be talking to a friend/relative.
thx Jorvette!
Okay, Ive Talked to some people and heres what i was able to figure out:
In the cab file, recovery.bin and eboot.bin are not needed! Not saying it wont update without this,
Nk.bin
Recovery.bin
Eboot.bin
those are all stored on the Second Partion of the harddrive, but if you would remove eboot.bin and recovery.bin, the zune would still work fine. Those two files are copied to the zunes flash rom when updated. Therefore, its near impossible to put these two files on the flash rom without faking the signature. And also, both of those files DO have a signature.
A small layout of what eboot.bin does is:
Check nk.bin > If Pass > Load nk.bin from harddrive
If Nk.bin cannot load > Load Recovery.bin from rom
It also does some other checks, but its irrelevant.
Inside eboot.bin, there is one file: nk.exe which is the bootloader. Ill run this file thru Ida Pro when i return home.
Our only other options are finding out that signature, or a exploit of somesort.
Also, the person i talked to, and he is a trusted source, said there is no such thing as the zune auto closing buffer overflows. It does NOT close buffer overflows.
Okay, Ive Talked to some people and heres what i was able to figure out:
In the cab file, recovery.bin and eboot.bin are not needed! Not saying it wont update without this,
Nk.bin
Recovery.bin
Eboot.bin
those are all stored on the Second Partion of the harddrive, but if you would remove eboot.bin and recovery.bin, the zune would still work fine. Those two files are copied to the zunes flash rom when updated. Therefore, its near impossible to put these two files on the flash rom without faking the signature. And also, both of those files DO have a signature.
A small layout of what eboot.bin does is:
Check nk.bin > If Pass > Load nk.bin from harddrive
If Nk.bin cannot load > Load Recovery.bin from rom
It also does some other checks, but its irrelevant.
Inside eboot.bin, there is one file: nk.exe which is the bootloader. Ill run this file thru Ida Pro when i return home.
Our only other options are finding out that signature, or a exploit of somesort.
Also, the person i talked to, and he is a trusted source, said there is no such thing as the zune auto closing buffer overflows. It does NOT close buffer overflows.
All three of those files are in the first partition, which is the system partition. None of those three files are put into the Zune's ROM, however the files inside nk.bin are put into the Zune's ROM.
As for the buffer overflows, it has at least some protection, but I suppose if it was that easy to stop all buffer overflows, buffer overflow exploits would be nearly nonexistent. See here: http://www.zuneboards.com/forums/h-m...ertection.html
__________________
"Against logic there is no armor like ignorance." - Laurence J. Peter
No, that is wrong. Recovery.bin and Eboot.bin are put onto the flash rom if they have a valid sig and and have a newer timestamp then the current ones. If Eboot.bin and recovery.bin were removed from the system partion, the device would continue to operate. No files from nk.bin are stored on the flash rom, they are to large.
Also, as for running the bootloader threw ida pro, turns out Ida Pro doesnt have freescale support, so sorry.
No, that is wrong. Recovery.bin and Eboot.bin are put onto the flash rom if they have a valid sig and and have a newer timestamp then the current ones. If Eboot.bin and recovery.bin were removed from the system partion, the device would continue to operate. No files from nk.bin are stored on the flash rom, they are to large.
Also, as for running the bootloader threw ida pro, turns out Ida Pro doesnt have freescale support, so sorry.
Maybe whoever told you that Recovery.bin and Eboot.bin are put into the ROM meant a hidden part of the ROM or something. As with all other Windows CE based devices, the Zune puts the files that are in nk.bin into a folder called "Windows", which is in its ROM. How else would it be able to use its modules?
__________________
"Against logic there is no armor like ignorance." - Laurence J. Peter
RECOVERY.BIN is used for recovering the NK.BIN after the hard drive is wiped out.
The built in Flash ROM contains EBOOT.BIN and RECOVERY.BIN (the much larger NK.BIN won't fit and comes off the hard drive)
If you replace or wipe the hard drive (there are special buttons you can push), then the Zune goes into Recovery mode.
It loads EBOOT.BIN and RECOVERY.BIN from the flash ROM. RECOVERY.BIN lets you connect to your PC, and the NK.BIN file is copied to the Zune's hard drive.
When it boots normally, EBOOT.BIN ignores RECOVERY.BIN and instead loads NK.BIN from the hard drive.
Quote:
There is a spare copy of the EBOOT.BIN and RECOVERY.BIN on the Zune's hard drive, but that's for updating purposes.
The Zune runs perfectly without them (since it has copies in Flash ROM)
When doing a version update, all 3 .BINs will be copied to the Zune hard drive (from the CAB)
When Zune reboots, it checks the time stamp of the EBOOT.BIN and RECOVERY.BIN on the hard drive.
If they are newer (AND THEY HAVE A VALID SIGNATURE!!!), they will be copied to Flash ROM.
I've done this to revert to old versions of the firmware (including the original firmware version of EBOOT.BIN).
Even so, all parts are signed, and since the firmware that does the loading and updating requires any new firmware to also be signed, you are locked out.
All right, then. A copy of Recovery.bin and Eboot.bin are put into a hidden part of the Zune's ROM as well. That still does not change anything, since everything still needs to be signed.
__________________
"Against logic there is no armor like ignorance." - Laurence J. Peter
Hacking the zune. I need, you!
