Rockbox Technical Forums
Rockbox Development => New Ports => Topic started by: wafflesomd on October 04, 2006, 08:20:22 PM
-
Any plans for a zune port?
It's a very nice player, and has alot of potential.
-
Any plans for a zune port?
"First, don't ask Rockbox developers when they are going to port Rockbox to your platform. Ports are made by people who want to port, they are not done on request."
This and more is found here: http://www.rockbox.org/twiki/bin/view/Main/NewPort
-
The Zune will available to purchase on November 14th but a guy just got it yesterday from BestBuy.
The news is he uploaded on the internet the Zune's software. You can also find the Zune's firmware in this!
Check for more on this:
Download full Zune Software (48.7 MB rar file) (http://www.zune-online.com/news/zune/zune-software-48.7-mb-rar-file.html)
Oops someone got a Zune yesterday! (http://www.zune-online.com/news/zune/oups-someone-got-a-zune-yesterday.html)
We installed Zune MarkePlace - View Screenshots (http://www.zune-online.com/news/zune/we-installed-zune-marketplace---view-screenshots.html)
-
As you can see here:
Zune photos from the inside (http://www.zune-online.com/news/zune/zune-device-from-the-inside.html)
GearLive has some screenshots on the Zune internal parts. Yes, they opened up a Zune and took photos of it!
I think you should take a look of its chipset.
-
Unfortunately, those photos aren't very good/detailed. We need fine, up-close, sharp photos/scans of the PCBs including all visible mounted circuits.
-
Main CPU Freescale MCIMX3 Arm 11:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX31&nodeId=01J4Fs2973ZrDR
http://www.freescale.com/files/32bit/doc/data_sheet/MCIMX31.pdf
PC To Video Chip Focus  FS456 :
http://www.focussemi.com/products/fs455.html
Audio Chip Wolfram WM8978:
http://www.wolfsonmicro.com/products/WM8978/
http://www.wolfsonmicro.com/uploads/documents/WM8978.pdf
Power Managment Freescale MC13783:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MC13783&nodeId=01J4Fs4881
http://www.freescale.com/files/wireless_comm/doc/fact_sheet/MC13783PMFS.pdf
USB-OTG Philips ISP1504A:
http://www.nxp.com/pip/ISP1504ABS.html
http://www.nxp.com/acrobat_download/datasheets/ISP1504A_ISP1504C_1.pdf
-
Thats a ridiculously powerful CPU for a DAP, even if you want to do 480p video decoding. Maybe MS is thinking forward about HD support?
-
Cool,
I just posted it on:
http://www.zune-online.com/news/zune/we-have-zunes-chipset-info.html
-
Wow, the Zune really is just like a Gigabeat S as I know that at least the i.MX31 and WM8978 are inside the Gigabeat too.
keytotime: do you know which wifi chip is used?
-
Now somebody post decent scans my eyes are killing me.
-
Flash Samsung K4M51323PC:
http://www.samsung.com/products/semiconductor/MobileSDRAM/MobileSDRSDRAM/512Mbit/K4M51323PC/K4M51323PC.htm
-
Aliask made a wiki page for the Gigabeat S. So far the Zune is the same:
http://www.rockbox.org/twiki/bin/view/Main/GigabeatSInfo
-
more places with shots of dissected zunes:
http://www.minivian.com/bbs/view.php?id=zune_forum&page=1&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arrange=headnum&desc=asc&no=14
http://www.hackaday.com/2006/11/14/zune-gutted/
the hackaday one has some hires shots, but the linked site appears to be dead
-
WiFi Module Key Stream Corporation
http://www.keystream.co.jp/en/products/ks3021.php
-
WiFi Module Key Stream Corporation
http://www.keystream.co.jp/en/products/ks3021.php
The link seems to be under construction...
-
Here's two other links about the wi-fi module here (http://techon.nikkeibp.co.jp/english/NEWS_EN/20060829/120563/) and here (http://translate.google.com/translate?hl=en&sl=ja&u=http://www.keystream.co.jp/news/20060206.php&sa=X&oi=translate&resnum=1&ct=result&prev=/search%3Fq%3Dwifi%2Bks3021%2B%26hl%3Den%26hs%3DOq7%26lr%3D%26safe%3Doff%26client%3Dfirefox-a%26rls%3Dorg.mozilla:en-US:official%26sa%3DG) (translated)
and a nice pic:
(http://bunniestudios.com/blog/images/zune_wifi.jpg)
-
Here's the source of the above picture, and more high-res photos of the internals:
http://www.bunniestudios.com/wordpress/?p=131
Nice hardware!
-
http://en.wikipedia.org/wiki/Zune#Hardware
-
A) The link was on my site valid for 2-3 days just before the launch and on launch of Zune. It has been removed since. It just points now to Zune.net where anybody with windows and IE (!!) can download, install and use the software (you don't have to own a Zune player).
B) I write an article about CC and Zune now! (How the hell did you know it :P)
Based on: http://www.wired.com/news/columns/0,72172-0.html
And don't be so sure it is technically unfeasible...
-
I was reading an article on linux.com about one of the editor's trips to Microsoft and how he got a free Zune. His response:
So here's the deal: If you want to either install Linux on a Zune or write a utility to make a Zune Linux-compatible, email editors@ostg.com and tell us why we should give this free Zune to you. The person we deem most likely to put it to good use, based on previous development track record and all-around desire, will get this Zune to have, hold, use as a development platform, and otherwise do with as he or she wishes.
All we ask in return is a reasonable description of the hacking effort -- successful or not -- within a reasonable time. Call it 90 days after you receive it. And to keep the "Who gets it?" question from going on forever, we'll close the entry period on December 22 and announce our decision on December 26, the day after Christmas, then mail it out on or about January 2nd, 2007, after the Christmas shipping (and return) rush has died down.
The only limitations we're imposing are:
* You must be in a country where you can receive postal-mailed packages from the US.
* If there are customs hassles or duties, you must take care of them at your end.
So go ahead and send those emails. We'll be waiting for them!
I realize that Rockbox isn't being developed to be able to install linux nor to ensure linux compatibility, but frankly I can't think of any better open source community which is better suited to improving the Zune. Why don't one of the developer's send in a request?
-
90 days is reasonable? Man, that is pretty ignorant I'd say.
We got several Sansas back in May. We're now >6 months later and we're a whole bunch of people with such targets and still we don't have a working Rockbox on it. But i guess we're just lame... :-)
-
As far as I am aware all work on the Gigabeat S RB port has come to a standstill. The cpu security architecture of the Gigabeat S(and therefore the Zune) prevents any alteration of the bootloader/firmware on the hard drive because these files are hashed using SHA-1 20 bit and signed/certified by a Verisign certificate/key. Tricking the Zune firmware update program to update w/ a custom firmware file that isn't signed will not work, because the firmware isn't signed, and therefore its not authenticated. It seems to me that more than likely the hardware will have to be reverse engineered much like how the digital signature [attempted] to be cracked on the Xbox in order to capture the signature of the bootloader/firmware. Either that or find someway to capture the signature by reverse engineering through the software. With this signature we can then sign a custom bootloader or firmware file. That is unless anyone has any other ideas.....
Edited 12-13-06:
I found out the Xbox digital signature was cracked but never officially released due to legal reasons. Because of this I'm not sure if this method would be legal for the zune/gigabeat s30. Maybe if the digital signature wasn't publicly released? See this page : http://www.xenatera.com/bunnie/proj/anatak/xboxmod.html
Another way could be to possibly search for any buffer overflow exploits in the current firmware to get some custom code working. This is the way that Xbox Linux is installed on the Xbox. A buffer overflow in the MechAssault game saving ( anyone familiar w/ Xbox modding would be familiar w/ this ) allows custom code to work, and Linux to be installed. One final alternative is flashing Flash ROM w/ a custom ROM, but this wouldn't be for the layman, its possibly dangerous, and still might not work because of the cpu security mechanisms.
One last note. The reason why I refer to Xbox hacking is because even though the hardware, and security aren't the same between Zune/Gigabeat S and Xbox, the situations are very similar. The methodologies used in cracking the Xbox could be used in cracking the Zune....
-
90 days is reasonable? Man, that is pretty ignorant I'd say.
We got several Sansas back in May. We're now >6 months later and we're a whole bunch of people with such targets and still we don't have a working Rockbox on it. But i guess we're just lame... :-)
Actually, they ask for "a reasonable description of the hacking effort -- successful or not" within the 90 day period, not an actual working port. I would think that something similar to the descriptions you've provided of your efforts on the Sansa project would easily fulfill that requirement.
-
Actually, they ask for "a reasonable description of the hacking effort -- successful or not" within the 90 day period, not an actual working port. I would think that something similar to the descriptions you've provided of your efforts on the Sansa project would easily fulfill that requirement.
Right, an unsuccessful attempt could easily be described within 90 days! ;-)
I did mail mr Miller (the author of the article) with some comments and he replied saying this about the time frame: "I'd just like some sort of progress report and assurance that someone has looked at the possibilities by then".
But as I'm not even able to hack the Sansa as much as I'd like, I'll pass this chance to someone else.
-
Quotes from the claimed-to-be developer at the Zuneboards Thread (http://www.zuneboards.com/component/option,com_smf/Itemid,28/topic,1438.0)
The way to boot it to the zune right now is very complicated, takes some time, and is risky if you don't know how to do it. I won't be releasing this until there is no risk to Zune users when they use Zune Linux. We are looking for graphics people who are willing to make logos and stuff for Zune Linux
The loader to boot a new OS on to your Zune however will not go open source.
I've been holding this out from the public for about two months, that you can ask people like LPX. Why would I release my code to people before it is even stable enough to change a song?
it might be released on my own website but Zune Boards will have exclusive rights to host it and other files to it. Because guess what? I don't care about all these other boards such as Zune Scene and crap.
It sounds like a hoax. I can't find anywhere something a bit technical or specific on how he managed to bypass/crack or whatever the security features of the i.MX31 CPU. Nothing about the encryption of the firmware, nothing about the signature that is required for the Zune to run code. Instead ha asks people to help him out with the... graphics!
I really hope to be proven wrong but this whole thing seems to me like a nice way for people to visit their forums (the claimed-to-be developer is also administering these forums). Time will tell... I wouldn't hold my breath for it though.
-
Going back to the xbox buffer overflow vs gigabeat s possibility, the xbox overflow exploited a flaw that exists in intel processors. Had Microsoft not changed hardware at the last minute, the flaw would not have existed in the xbox. The xbox, xbox360, and I'm sure the gigabeat s/zune use a trusted computing model, so without cracking the signature, it would be very difficult to otherwise compromise the security put in place. That is not to say that it would be impossible. However, you can't use intel cpu exploits anymore ;)
If it does in fact use a trusted computing model, then simply signing a custom firmware with a valid or specific certificate may not be enough. I don't think we'll see rockbox/linux on the zune/gigabeat s for some time, especially considering I don't even think we've seen linux on the xbox360 yet (don't be fooled by the nifty hacked screensaver someone made...if it's even that much).
As far as extracting and cracking the certificate in order to sign a firmware...this borders on poor ethics. I would be afraid that it would be possible for the "wrong" people to use it for other purposes, as I'm sure it would be particularly useful to exploit the wifi sharing.
-
I broke the linux-zune story on my site, but I really can't tell if there is something real there or not.
How can we check if Zune really has enabled the security features on the freescale processor? For example checking the firmware file for a signature, it could be a first step. The firmware version v1.0 is on the Zune CD. There are also v1.1 and the current v1.2 versions which are harder to get because they are automatically downloaded and installed on Zune.
EDIT: you can download the v1.2 Zune firmware from here:
http://download.xboxlive.com:3074/content/firmware/Zune01020434.cab
-
Going back to the xbox buffer overflow vs gigabeat s possibility, the xbox overflow exploited a flaw that exists in intel processors. Had Microsoft not changed hardware at the last minute, the flaw would not have existed in the xbox. The xbox, xbox360, and I'm sure the gigabeat s/zune use a trusted computing model, so without cracking the signature, it would be very difficult to otherwise compromise the security put in place. That is not to say that it would be impossible. However, you can't use intel cpu exploits anymore
If it does in fact use a trusted computing model, then simply signing a custom firmware with a valid or specific certificate may not be enough. I don't think we'll see rockbox/linux on the zune/gigabeat s for some time, especially considering I don't even think we've seen linux on the xbox360 yet (don't be fooled by the nifty hacked screensaver someone made...if it's even that much).
As far as extracting and cracking the certificate in order to sign a firmware...this borders on poor ethics. I would be afraid that it would be possible for the "wrong" people to use it for other purposes, as I'm sure it would be particularly useful to exploit the wifi sharing.
Hmmm..Thats very interesting about the intel exploit. That I didn't know. Nice to know though ;) . I do also agree about ripping the signature regarding questionable ethics. I don't even know if it is even legal. Good point on both accounts.
How can we check if Zune really has enabled the security features on the freescale processor? For example checking the firmware file for a signature, it could be a first step. The firmware version v1.0 is on the Zune CD. There are also v1.1 and the current v1.2 versions which are harder to get because they are automatically downloaded and installed on Zune.
I'm more than sure that these features are enabled. I've talked to a couple of people who have tried to substitute the firmware files(nk.bin) and only got an error message asking to update the firmware to the original firmware(this happens when recovery.bin is executed i think). This seems to confirm the fact that the i.MX processors verify the firmware images before boot(if enabled). Another point is that if you look at the firmware images(both eboot.bin and nk.bin) in a disassembler or a hex editor you can see the Method names and error messages that are internal when the system verifies the firmware images. Not only that, you can also see a Verisign certificate, supporting the argument that the images are signed. One last point : Security is inherent to the Freescale i.MX processor series. It is literally built into the processor and surrounding architecture. If all these security checks are there for use why wouldn't Microsoft want to use them?
-
Well for all experiments and DIY (Do It Yourself) you can find and buy a Zune dock connector here:
http://www.qables.com/index.php?main_page=product_info&products_id=593
Rgds
-
hmm...I recognize the filename in that Zune firmware package. NK.bin is the name of the output file for a Windows CE build :) If you run it through strings (or look at it in notepad) you see some very interesting text:
W i n d o w s C E K e r n e l f o r A R M ( T h u m b E n a b l e d ) B u i l t o n D e c 6 2 0 0 6 a t 1 6 : 4 2 : 0 1
So it really does run Windows CE :P
Some debugging file names
E:\pyxis\v1.2\platform\pyxis\target\ARMV4I\retail\kern.pdb
E:\pyxis\v1.2\platform\pyxis\target\ARMV4I\retail\ipu_base.pdb
E:\pyxis\v1.2\public\cebase\cesysgen\oak\target\ARMV4I\retail\waveapi.pdb
E:\pyxis\v1.2\public\cebase\cesysgen\oak\target\ARMV4I\retail\mspart.pdb
Some more random interesting strings
O E M I n i t S e c u r e C l o c k S t a t u s _ P h a s e 2 : S e c u r e C l o c k I s V a l i d
O E M I n i t S e c u r e C l o c k S t a t u s _ P h a s e 2: S e c u r e C l o c k I s L o s t
M S - P C M
M i c r o s o f t P C M C o n v e r t e r - C o p y r i g h t ( c ) 1 9 9 2 - 2 0 0 3 M i c r o s o f t C o r p o r a t i o n
C o n v e r t s f r e q u e n c y a n d b i t s p e r s a m p l e o f P C M a u d i o d a t a .
There looks to be some wave files in it:
1996-02-27 RIFF¦ WAVEfmt
A power management DLL:
PMC_PM.dll PmDevicePowerNotify PmGetDevicePower PmGetSystemPowerState PmInit PmNotify PmPowerHandler PmRegisterPowerRelationship PmReleasePowerRelationship PmReleasePowerRequirement PmRequestPowerNotifications PmSetDevicePower PmSetPowerRequirement PmSetSystemPowerState PmStopPowerNotifications
Yay, windows directories:
\ W i n d o w s \ S y s t e m \ % s . w a v \ W i n d o w s \ % s . w a v \ W i n d o w s \ S y s t e m \ % s \ W i n d o w s \ % s % s . w a v
Maybe we can run some code on this thing :P
S Y S T E M \ K E R N E L I n j e c t D L L
What is an XIP...
P a g i n g i n f r o m u n c o m p r e s s e d R / O p a g e f r o m X I P m o d u l e - - s h o u l d ' v e n e v e r h a p p e n e d
L o a d O 3 2 F A I L E D : X I P c o d e s e c t i o n n o t p a g e a l i g n e d , o 3 2 _ d a t a p t r = % 8 . 8 l x , o 3 2 _ r e a l a d d r = % 8 . 8 l x
E R R O R ! X I P r e g i o n s p a n a c c r o s s d i s c o n t i g i o u s m e m o r y ! ! ! S y s t e m H a l t e d !
Does anyone know of a Windows CE device simulator that we might be able to get this device image ("NK.bin") to run in (maybe with a little coaxing)
Hopefully that provides some insight into how the Zune runs internally, too bad that it isn't available in Canada yet.
-Andrew
-
Useful information concerning WinCE (i tink) : http://www.xs4all.nl/~itsme/projects/xda/
Maybe that could be useful : http://wiki.xda-developers.com/index.php?pagename=XdaUtils/pnewbootloader.exe
Oh and XIP= http://www.ucdot.org/article.pl?sid=02/08/28/0434210
XIP is an acronym for ...
* eXecute-In-Place
Standalone Device Emulator 1.0 with Windows Mobile OS Images
http://www.microsoft.com/downloads/details.aspx?FamilyId=C62D54A5-183A-4A1E-A7E2-CC500ED1F19A&displaylang=en
Okay, see GigabeatSinfo for more information (Updated )
http://www.rockbox.org/twiki/bin/view/Main/GigabeatSInfo
-
Yo, I'm not really inclined towards anything that would really help getting rockbox on the zune, so i apologize for that, but i am willing to help in any way i can. I'm willing to provide a free zune to somebody who is serious about trying to get this ported to the unit. Just let me know if anyone is making progress. peace.
-
Just for info for the zune user
the console port of the gigabeat S30 is now connected and I could see the boot sequence
I still have to find the transmit, I can only see and not do any action
As the zune is based on the S30, this could help, there is also the console port on the zune (I think from the picture I saw)
You can see the boot sequence on the wiki of the gigabeatS
-
You can see the boot sequence on the wiki of the gigabeatS
link please ?
-
sorry : http://www.rockbox.org/twiki/bin/view/Main/GigabeatSInfo at the bottom of the page
I am not sure that the boot is complete , I cannot find any entry point for sending data (still checking)
The problem is that I have a broken S30 with no display so I am not really sure.
But this is a beginning
Any help welcome
-
If you having a zune to tinker around with would be a significant help, i could probably get you one. Just let me know. I'll try to help any way i can, but as I have no programming skills whatsoever, I dunno what I could do.
-
Thanks for your help ,
If I had a zune I could perhaps try to look for the same thing I am looking in the gigabeat S
For the moment, we try to get all the information we can.
Somebody give us the link to the firmware update of the gigabeat V30 which run on media player like the S and the zune.
Perhaps we can modify the updater to load a modified firmware on the S or the zune.
Any help is welcome and the more people involved, the faster we go
-
Simular to my sansa resource, starting a Zune resource since I just picked one up.
http://zefie.com/files/PMP/zune/
-
I happen to know a lot about windows CE and the zune has all of the files essential to making CE run. My dad is working on a CE project called Soleus and the files:
*nk.bin
*eboot.bin
Are all part of the picture. nk.bin is where the krenel, nk.exe, is loacted. It also contains the critical system files (just enough to boot). recovery.bin is self-explanitory. and that is all i know. i will try to decompress them on my MAC and see if that can extract all of the good stuff.
if you need any help, contact shadow.h511 (at) gmail (dot) com.
oh, i almost forgot, i am only 14.
-
I've decompressed the Zune firmware before(I forgot which version of it though, there are many different versions out there). Whenever I get off my lazy butt I suppose I can start a Zune wiki and post the contents there :)
-
Here are the extracted contents of one of the versions of the Zune firmware- I forget exactly which one. I got it from Zefie's site (http://zefie.com/files/PMP/zune/firmware/). I believe it was version 1.03, but don't remember which exact one it was.
Here is the extracted eboot.bin :
http://rapidshare.com/files/42258741/Zune-Eboot.bin.rar.html
Nk.bin :
http://rapidshare.com/files/42259244/Zune-NK.bin.rar.html
Recovery.bin:
http://rapidshare.com/files/42259372/Zune-Recovery.bin.rar.html
Unlike what others have stated previously(not in this forum I don't think), these files are not encrypted. They are signed and hashed. The signature is for the hash of the file. This does not encrypt anything, but merely protects against tampering of the firmware files.
Anyways happy hacking....
-
The Guy from http://www.streamcentric.com/zune find JTAG and SERIAL connectors on clean side of PCB (http://www.upsdn.net/images/2006-11/zune_bot.jpg):
Serial:
Rx - 4
Tx - 5
JTAG:
TRST - 8
TDI - 9
TMS - 10
TCK - 11
TDO - 13
Power:
+3.3 - 6
GND - 17,18,19,20
-
You can download the current Zune firmware v1.4 directly from the place the Zune Software gets it:
http://msxb-d1.vo.llnw.net/zune/Zune01040485.cab
-
Do you think a broken Zune(long story) would be of any use in porting rockbox on the Zune?
Or is the security on the firmware causing the main halt on this project?
I am willing to donate my zune to rockbox if it means we could see some action take place on this port!
-
Currently there are not an active port to the Zune that I am aware of. The reason for this is because the security has not been cracked.
-
Basically, the Zune in theory has both some strong points (in regards to porting Rockbox) and very weak ones.
The bad: 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.
The good: Due to its similarities with the Gigabeat S, should the encryption be cracked or bypassed, in theory it will be a less onerous task than an entirely from-scratch port (though obviously, only in theory).
-
Regarding wiki page, you need to register and get write permission and then creating or editing pages is easy.
Since the Zune runs some kind of Win CE, I figure it could be a good idea to scan the net for known buffer overflows in that or in one of the components the Zune uses to see if that could be an entry point to running custom code.
-
I've been seeing a lot of cheap zunes online recently (as low as $80 once). I'm not much of a coder, but would it be helpful to the effort if I bought one and donated it to one of the devs?
-
Yeah, I am hoping that all the cheap zunes on woot will spark some interest from the community.
I'm doing my research now, as I know almost nothing about running unsigned code or breaking encryptions or windows ce.
One thing I noticed, though, is that there is a GigabeatS option for the configure file in subversion. Does this mean that they got past the encryption/signing issue? Or is that just an early start of writing the drivers in case they ever do get that far?
-
One thing I noticed, though, is that there is a GigabeatS option for the configure file in subversion. Does this mean that they got past the encryption/signing issue?
They did. I believe it was done by someone working on the Zune actually, however the trick they used does not work on the Zune.
-
this probably sounds pretty dumb, but have people tried exploiting the way that Zunes are "hard reset?" According to the MS docs (MSKB 927001) during the hard reset the Zune first formats itself and then re-copies the firmware from the host PC to the player. Now, this assumes that the bootloader is smart enough to handle these low level transaction and will probably be looking for properly signed code. But, I thought I'd throw it out there just to stimulate discussion about this.
I picked up a zune for $85 from w00t and I really like the player. But, I'd like to have Rockbox and/or Linux on it to make it work better with my Linux desktops.
-
The Guy from http://www.streamcentric.com/zune find JTAG and SERIAL connectors on clean side of PCB (http://www.upsdn.net/images/2006-11/zune_bot.jpg):
Serial:
Rx - 4
Tx - 5
JTAG:
TRST - 8
TDI - 9
TMS - 10
TCK - 11
TDO - 13
Power:
+3.3 - 6
GND - 17,18,19,20
You may want to be careful here. Give this a read...
http://www.freescale.com/files/32bit/doc/white_paper/IMX31SECURITYWP.pdf
Section 5 (Hardware Security) refers to security faults causing the Red Ram to be zeroed and yer device being pooched. One of those security faults potentially being any JTAG manipulation. The person who posted that on their site said they "sacrificed" their Zune. Soooo... maybe Microsoft uses that security feature.
-
I used Windows and modified the proper registry key to make it show up in My Computer, but that did not allow files to be copied to it. Instead, I had to run the Zune software and end the process while it was converting a movie in order to have read/write/delete access to it.
Long story short, it will read ANY jpeg and ANY wmv video, no matter the size. It will display them without issue (except for being very slow) even if you didn't use the Zune software to send it.
Are there any recent wmv/jpeg exploits that could be tried on the device? It would have to inject ARM code...a long shot but it may work. Any thoughts?
-
Are there any recent wmv/jpeg exploits that could be tried on the device? It would have to inject ARM code...a long shot but it may work. Any thoughts?
I found that zune (v1.1 fw) reboots after playing VLC-encoded files.
Maybe media player inside zune (windows media player mobile) have leak while playing asf files with WMV2+MP3 You can try to encode some file to asf and play it on zune. You will see result.
-
What is now needed is for someone to go through the firmware and find an exploit. The DLL files for the OS are easily extracted and do not appear to be encrypted. Forcing people to downgrade is not really an option until rockbox fully works on the player (especially USB host). The Gigabeat S port is progressing, so most of the base level stuff should work on the Zune.
-
Is anybody interested in the hard drive contents? I could perhaps find the right ZIF <-> ATA adapter and post it. Perhaps someone could then find an exploit of sorts and I could write it to the disk to test it. I also found a bunch of datasheets for this player, but they all say "confidential" (like the FM tuner for example), yet they are available of many sites.
-
Although not strictly related, the contents of a Gigabeat S hard drive were read by dropping the drive into an iPod video and using the iPod's emergency disk mode to read the contents. This was mentioned on the Gigabeat S wiki page.
If you can get a cheap iPod video, you can read the drive that way. Seeing the contents of a Zune 30 (as the old Zunes are called now) would be useful, but it's going to be the encryption on the firmware that we have to worry about.
-
You can also get USB enclosures for 1.8" ZIF drives for pretty cheap at online auction sites these days.
-
Ok, I got a ZIF to IDE adapter and could not get it to show up on 2 different computers. I could hear/feel the disk spin up and down, but it was not identified in the BIOS of either computer. I guess I will order a USB one just in case.
-
It may be like the xbox drives.... they are locked, you read them by booting the xbox and hotswapping the cable from the box to your pc. This may be possible to do IF you can supply voltage to the drive by another means than the zune itself, so you had room to remove the cable after it is unlocked and plug it into whatever interface your trying to use to access it.
-
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
-
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?
-
The file 'zconfig.dat' contains several strings mentioning TFTP which I find interesting. You aware of any functionality in the Zune that uses TFTP?
-
Track sharing over wifi maybe?
-
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 (http://www.xs4all.nl/~itsme/projects/xda/wince-flashfile-formats.html) 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
-
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.
-
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.
-
WEP is unsafe and it should be possible to retrieve the key(s) used, like with airsnort (http://airsnort.shmoo.com/)
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?
-
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...
-
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?
-
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!
-
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.
-
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/
-
Yes, we've seen it - No, no-one's bothered doing it.
-
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.
-
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.
-
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.
-
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.
-
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).
-
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.
-
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.
-
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.
-
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. :D :P
-
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. :D :P
As markun said, the code is signed, so you can't load new firmware.
-
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.
-
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.
-
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.
-
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.
-
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.
-
@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.
-
When I say broke, the zif connector on the daughter board and hard drive are broke (the little bridge that applies pressure against the ribbon) It turns on, but the hard drive isn't spinning up, I din't realize how fragile/weak those little pieces were, so when I opened them from the middle the just broke (gotta lift them from the sides). Any hoot, I have a 1.8" pata to usb adapter and a zif to 1.8 pata adapter, I used dd to dump the first 500mb of the original zune drive (which i still have), I think I ran a scan on the 80gb zif ipod drive I got off ebay and how a bad sector or more. I used dd to write the 500mb image I had from the other drive to the ipod drive, which went well. So I don't know if you want to try out your luck with the jtag or whatever else, you'll be getting an 80Gb Zune that could possivly be fixed with parts from another unit, it boots, but doesn't spin up the drive (pretty sure the cable/connectors are the issue). I am fixin to get a 120gb Zune and would nothing better than to play flac or any other lossless format on it. Hopefully this would help further the cause.
-
I apologize if I am just posting a whole lot of nothing, but I really would like to see something happen with this.
I did some research, and it looks like the window CE base is hackable. This sight seemed to have a lot of info. http://hubpages.com/hub/hackingwindowsce.
The other thing was, you can make programs for the Zune. Would it be possible to run a rockbox emulator on the Zune and use that?
-
nloewen, I don't think that would be practical. It would be like running a virtual environment Linux on your Windows machine. Sure, it works, but there's not much you can do with it since the basic OS is still Windows.
I'm assuming this thing is pretty much never happening. Been discussed for 2 years, no tangible (in the electronic sense) results. Ah well, I've heard that the Zune firmware isn't all that bad.
-
Ok, my offer on the zune has expired since no real motivated individuals want to tackle it;) I have replaced it and have recovered a cab file and other dll files from the dive if anyone would like to take a look at them, they are here http://www.gigasize.com/get.php?d=8ms5wybnmwc
-
We really need to get RB on Zune players!!! any chance of that happening? Need to figure out how to bypass the current 128GB LBA limit.