Rockbox Technical Forums

Rockbox Development => New Ports => Topic started by: ssjmichael on April 04, 2006, 12:51:17 AM

Title: Creative Zen Vision:M
Post by: ssjmichael on April 04, 2006, 12:51:17 AM
Hi, my name is Michael. I'm the admin over at epiZENter.net, a new and very popular Creative fansite. There's been a great deal of interest for rockbox on the Zen Vision:M. I just want to ask directly to all rockbox members whether the Vision:M is really capable of being rockbox'd.

I've read through a few threads and other forums, and the consensus seems to be, that TI doesn't really reveal their documentation, and there are no free compilers available for the TMS320 DSP. Now is this the nail on the coffin, or is there a way around this?

Someone mentioned this and I want to know if it holds any relevance to the free compiler issue:

Quote
The TMS320DM320 is a dual core ARM9/DSP chip. The ARM part of it can be targeted by an ARM compiler. The Cowon A2 also uses the TMS320DM320 chipset and has a GPL Linux firmware. You can download the source code from Cowon's website. They don't mention that you need any commercial compilers to build the firmware from the sources... Maybe the RockBox folks should have a look at that source code...

Now we will be gathering money to get a test player, which will be opened up and scanned. What we lack are people with knowlege. We are willing to send the player to someone who is willing to devote their time to helping us, but only if people here feel the Vision:M has any chance of getting cracked.

If you want to help us, please join us in discussion at epiZENter.net. Thank you.
Title: Re: Creative Zen Vision:M
Post by: LinusN on April 04, 2006, 02:16:18 AM
The problem is not the ARM core, it's the MS320 DSP core, which we will need to program to play audio. If we are lucky, we won't have to write much DSP code, so we may get by writing in assembly language.

Before you waste your money, find out as much as you can about programming this chip.
Title: Re: Creative Zen Vision:M
Post by: Bagder on April 04, 2006, 02:19:18 AM
The DSP part is clearly the trouble in this beast and it takes more research on how exactly that is needed or even if it is needed for this particular player.

I'd guess that investigating Neuros newest players and their source code would indeed be helpful too.

But yes, I firmly believe this player can be reprogrammed and get Rockboxed, but it will take a serious amount of time and effort by skilled people.

And a last advice: if you want help and assistance from Rockbox developers, you should come here and not try to get us to visist yet another random forum somewhere else.
Title: Re: Creative Zen Vision:M
Post by: ssjmichael on April 04, 2006, 02:34:36 AM
Thanks. I will be visitng here quite often. That invitation was for other Vision:M owners to read up on our discussion over at epizenter in order to get as much support as possible for our players. Sorry, should've been more specific.

I do wish I knew more about this stuff, or someone over there knew something, but I will try my best to read info over here and look for the neuros source code, etc...

Title: Re: Creative Zen Vision:M
Post by: saratoga on April 04, 2006, 01:38:48 PM
Do we have any idea what the DSP is used for?  Looking at the doc's on TI's site, it looks to be fairly FPU heavy, something thats not too important for audio.  It may be that they just use it for video, or mostly for video. 

If thats the case, then you could get by with just assembly, since you'd hopefully not need it for anything important. 

I don't suppose anyone has had the courage to try and dissassemble creative's firmware and see what they do?
Title: Re: Creative Zen Vision:M
Post by: Bagder on April 04, 2006, 04:12:24 PM
The ARM core certainly is powerful enough to drive audio-only codecs fine on its own. The DSP is only really necessary to use for video. Possibly it is good to use for audio too to get the power consumption to a lower level.

But in the Neuros case and with their DM320 chip (I don't know if there even exist different versions, but I can't exclude that risk) the DAC is controlled by the DSP core so there cannot be any sound without at least some basic DSP code that gets PCM data from the ARM. But again, I'm  not sure if that is truly a chip limitation or something they opted to go with.

And yes, reverse engineering will reveal lots of stuff but the DSP code will of course require its own challenge of DSP-specific reverse engineering.

To compare with Neuros again, they intend to have a binary blob of DSP code in the ARM side that the ARM will program the DSP with at boot and if the other TMS320 systems are any similar they too have "binary blobs" in there and if so it might be able to extract them from the firmware and use them as black boxes the same way the original firmware does. But of course, then that DSP code cannot be legally reditributed.
Title: Re: Creative Zen Vision:M
Post by: SumWon on April 09, 2006, 06:10:23 PM
Michael,

I don't think you need to buy a Vision:M just so that you can see what chips are inside. Based on the pictures I've seen of a disassembled Vision:M and the Vision I disassembled myself, I can tell you what (off the shelf) chips are inside the Vision:M:

TI TMS320DM320 - Dual Core ARM9/C54xx DSP System On Chip
Spansion S29GL032M - 4Mb flash memory
Infineon HYBL256160AF (x2) - 64Mb RAM
Philips ISP1583 - USB 2.0/ATA (IDE) controller

Unfortunately it appears that there are custom logic chips in the Vision and Vision:M. These will be hard to figure out without Creative's design documents and/or reverse-engineering the current firmware.

As other posters in this thread have indicated, the first step in getting any replacement firmware developed is to reverse-engineer the current firmware to see what it does. I've managed to extract the firmware from the firmware updater and had a quick go at running it through an ARM disassembler. It's going to take a lot of work to figure anything out about how it works...

To get the firmware image, you will need to update the firmware on your player. While the updater is running, it extracts the firmware (a file called NK.BIN) to a folder called C:\CTJbFW. If you're quick, you can copy this file before the updater deletes it (which it does when the update is complete).

HTH
Title: Re: Creative Zen Vision:M
Post by: ssjmichael on April 10, 2006, 02:07:42 AM
Well we'd need some scans too apparently. If you're willing to scan the Vision, that would be helpful. The other reason to have an extra one was for testing purposes so we don't accidently screw up our own players. The plans to buy one have been postponed until we can get some sort of solid footing on whether its even possible to really get this going.
Title: Re: Creative Zen Vision:M
Post by: Bagder on April 10, 2006, 02:23:27 AM
I don't see why it shouldn't be possible.

There are lots of players around using this TMS320 chip, some of them even distribute chunks of source code and there's always reverse engineering you can resort to, should all else fail.

And since we haven't mentioned this so far in this thread, our "guide" to new Rockbox ports:

http://www.rockbox.org/twiki/bin/view/Main/NewPort
Title: Re: Creative Zen Vision:M
Post by: SumWon on April 10, 2006, 05:27:26 AM
Michael,

I'm still not seeing what you're hoping to achieve by 'scanning' the inside of the player. Once you have the existing firmware and an awareness of the hardware used, there is not much more you can learn from 'scans' (although I can provide you with hires digital photos of both sides of the Vision's board if you think it will help).

The Vision(:M) like most other hard disk based players, has two firmwares: a flash based bootloader, which shouldn't even be considered for modification unless you have sophisticated equipment to reprogram it when (and not if) things go wrong. And a disk based OS which is loaded by the bootloader. Most players (including the Visions) are able to (use the flash-based firmware to) reprogram the disk based OS through the USB port even if the disk has been completely replaced/zeroed.

As Daniel indicated, there's no particular reason why the firmware couldn't be rewritten on these players. They use (largely) off the shelf chips for which there are open-source firmwares available. The original Nomad Jukebox (6Gb) had an encrypted disk based OS, which meant that either the encryption had to be broken, or the bootloader reprogrammed. Which made modifying or replacing the firmware (practically) impossible. Looking at the Vision's firmware, it does not appear to be encrypted in any way.

However, there is a lot of very skilled reverse-engineering work needed before the firmware can be replaced. This will be the stumbling block (if any). I certainly wouldn't buy a player or get my hopes up until fair progress has been made on disassembling/reverse-engineering the current firmware. I'm certainly no expert in this area, but off the top of my head, I can tell you that the very least you'd need to find out, is how the (disk based) firmware's checksum is calculated and verified, and how to find the entry point...

HTH
Title: Re: Creative Zen Vision:M
Post by: Bagder on April 10, 2006, 06:06:38 AM
The scans are generally used to identify all chips and circuits, in order to track down exactly what they are and what they are used for.
Title: Re: Creative Zen Vision:M
Post by: ssjmichael on April 10, 2006, 05:17:53 PM
The scans are generally used to identify all chips and circuits, in order to track down exactly what they are and what they are used for.

Yeah, I'm basing my need for scans off of what Daniel and all the information from this site has said. Scans provide a much bettery idea of every circuit, than a digital picture (from a camera) could do. Like I said, there is no plan at this moment to buy one.

If I can recruit some people who know a great deal about reverse engineering and ways around some of these codes (f there are), and also if they have the time to invest in this, then I'll really get this started.
Title: Re: Creative Zen Vision:M
Post by: ego on June 02, 2006, 12:14:50 PM
http://forums.rockbox.org/index.php?topic=3320.0
Title: Re: Creative Zen Vision:M
Post by: JazzBone on June 02, 2006, 02:25:53 PM
If you look for a german speaking forum on rockbox, go here: http://www.rockbox-lounge.com/ (http://www.rockbox-lounge.com/)
Title: Re: Creative Zen Vision:M
Post by: Xenon2434 on June 24, 2006, 01:10:34 AM
Just recently there has been some more discussion about this over at epiZENter.net. Unfortunately, at that website, noone so far has come forth and said they have the skills necessary to make this project happen. However, I believe that if someone with the skills would be willing to do it, that we could get them a player to take apart and work with.


With that said, would anybody with the skills/time like to step up and port Rockbox over to the Zen Vision: M? It would be a free player for you, and would hopefully provide everyone with some amazing firmware. Of course, everyone else would be extremely supportive, but there is only so much some people can do (myself included)

Thank you very much,
Xenon
Title: Re: Creative Zen Vision:M
Post by: itsmeguys on July 04, 2006, 02:20:56 AM
Just recently there has been some more discussion about this over at epiZENter.net. Unfortunately, at that website, noone so far has come forth and said they have the skills necessary to make this project happen. However, I believe that if someone with the skills would be willing to do it, that we could get them a player to take apart and work with.


With that said, would anybody with the skills/time like to step up and port Rockbox over to the Zen Vision: M? It would be a free player for you, and would hopefully provide everyone with some amazing firmware. Of course, everyone else would be extremely supportive, but there is only so much some people can do (myself included)
Yes! There would be many people willing to support whoever steps up! I dont mind donating some money aswell, if it is needed.
Title: Re: Creative Zen Vision:M
Post by: shotofadds on July 11, 2006, 02:29:15 PM
I'll stick my oar in here and say that I've just upgraded from my Rockbox'd iRiver H110 to a Vision:M (simply because I was getting fed up with having to keep opening up the case and soldering the Stop button back on again!).

The retail firmware on the ZVM is truly miles ahead of anything I've seen so far, from any manufacturer. That said, there are still problems: lack of true gapless playback being the main one (though it's much better than the stock iRiver firmware), slightly dodgy sound quality and very occasional crashes needing a reboot.

I'd love to see Rockbox on the ZVM (for better sound quality & adjustment and plugins) but I honestly think the stock firmware is sufficiently good that there won't be the momentum pushing for Rockbox that there was for the iRiver or iPods.

Of course, if Rockbox did make it onto the ZVM there'd be lots of new challenges for the devs if it's to compete with the Creative firmware - DivX playback being a big one  :o
Title: Re: Creative Zen Vision:M
Post by: itsmeguys on July 17, 2006, 09:55:21 PM
is there somewhere where we can donate money for rockbox to be developed for ZV:M (specifically)?
Title: Re: Creative Zen Vision:M
Post by: Bagder on July 18, 2006, 04:27:51 AM
is there somewhere where we can donate money for rockbox to be developed for ZV:M (specifically)?

No. And do note that donating money will not specifically help a porting effort unless you intend to donate a lot .

Besides, it is like the bounty discussion. When Rockbox gets ported to a new device, there's like 95% of existing code that's being used so why should only the authors of the new 5% of the code get the money you donate?
Title: Re: Creative Zen Vision:M
Post by: shotofadds on July 21, 2006, 02:24:40 PM
There are several commercial linux distros built for the TMS320DM320 (google for DSPLinux or Monterey Linux) so a GCC toolchain for these devices must be feasible, if not widely available.

Not that a commercial Linux particularly helps Rockbox...
Title: Re: Creative Zen Vision:M
Post by: Bagder on July 22, 2006, 10:54:37 AM
Quote
a GCC toolchain for these devices must be feasible

Linux for a TMS320 doesn't in any way imply a gcc for its DSP parts.
Title: Re: Creative Zen Vision:M
Post by: shotofadds on July 22, 2006, 04:28:16 PM
Did I say it did?
Title: Re: Creative Zen Vision:M
Post by: Bagder on July 22, 2006, 04:31:01 PM
There have been gcc support for ARM7 and ARM9 for a very long time.
Title: Re: Creative Zen Vision:M
Post by: markun on July 22, 2006, 05:21:00 PM
and the GNU binutils have support for the TI C54x DSPs

http://sourceware.org/binutils/docs-2.17/as/TIC54X_002dDependent.html
Title: Re: Creative Zen Vision:M
Post by: pianoboy3333 on August 25, 2006, 09:01:49 AM
I was thinking about purchasing the Zen Vision:M over the iAudio X5L.... and I would love it if there were rockbox for the Zen Vision:M, if there were, I'd buy that over the X5L.
Title: Re: Creative Zen Vision:M
Post by: Bagder on August 30, 2006, 04:08:52 PM
This is a TMS320-based player.

There is very early work on creating a Gmini402-port and there have been some early steps at an mrobe 500 port (two other TMS320-players).

So all it takes is for a determined Creative Zen Vision:M owner to step forward and joining forces with the Rockbox hackers and perhaps we could get something going in a future...
Title: Re: Creative Zen Vision:M
Post by: RaiderX on September 24, 2006, 09:53:18 AM
it would be nice on vision M. i didnt know about it when I got my ipod, and when i found out about it, i was so mad. but once i got rockbox on my ipod, i didnt want any other DAP! :D
Title: Re: Creative Zen Vision:M
Post by: larryzotter on September 30, 2006, 10:55:33 PM
Hi i'd like to contribute. I've got a Zen Vision M Green 30gb. I've extracted the nk.bin firmware from the updater. What tools are there so that i can make edits to it? I'm willing to help as much as i can.

Larry Zotter
Title: Re: Creative Zen Vision:M
Post by: larryzotter on September 30, 2006, 11:09:49 PM
Opened nk.bin with a hex editor. Only see Creative Zen Vision:M... Attached screenshot

[attachment deleted by admin, too old]
Title: Re: Creative Zen Vision:M
Post by: saratoga on October 04, 2006, 09:15:47 PM
Found this today almost by accident:

http://www.fulton.asu.edu/~karam/eee498/Lectures/TIC55x_Arch.ppt

Tons of info on the DSP core in there.  Its quite impressive for a DAP.  Shame TI doesn't have the sense to release free tools to work with it.
Title: Re: Creative Zen Vision:M
Post by: Bagder on October 05, 2006, 01:11:35 AM
Quote
Shame TI doesn't have the sense to release free tools to work with it.


AFAIK, there is a free assembler for the DSP parts and the CPU part is plain ARM9.

The ArchOpen project has their OS running and playing sound on a TMS320-based player, so a Rockbox port to one of these should indeed be feasable...
Title: Re: Creative Zen Vision:M
Post by: larryzotter on October 16, 2006, 05:53:43 AM
im willing to help, i've got a zen vision m. See my last post.
Title: Re: Creative Zen Vision:M
Post by: markun on October 26, 2006, 02:48:55 AM

im willing to help, i've got a zen vision m. See my last post.


Maybe you can decrypt the nk.bin file with the "NKDecrypt" tool

http://www.takingthingsapart.org/index.php?option=com_content&task=view&id=32&Itemid=38

After inspecting the Toshiba Gigabeat S60 we found out there is a partition with 3 .bin files, also nk.bin. It's a Windows CE 5 image.

Good luck
Title: Re: Creative Zen Vision:M
Post by: Bagder on October 26, 2006, 03:20:22 AM
Allow me to repeat the oft-mentioned wiki page for new ports, but it seems people here haven't looked through it properly:

http://www.rockbox.org/twiki/bin/view/Main/NewPort

Scanning the PCB and figuring out the firmware update file format are two very important steps...

The docs for the DM320 chip are not publicly available, but we know that they have leaked out and they are now possible to find on the internet...
Title: Re: Creative Zen Vision:M
Post by: Otaku on October 26, 2006, 04:59:19 AM


im willing to help, i've got a zen vision m. See my last post.


Maybe you can decrypt the nk.bin file with the "NKDecrypt" tool

http://www.takingthingsapart.org/index.php?option=com_content&task=view&id=32&Itemid=38

After inspecting the Toshiba Gigabeat S60 we found out there is a partition with 3 .bin files, also nk.bin. It's a Windows CE 5 image.

Good luck

Ah, no : NKDecrypt is only for the Gizmondo - they used a proprietary encryption scheme.
atb
O.
Title: Re: Creative Zen Vision:M
Post by: loekf2 on October 29, 2006, 01:10:10 PM

Allow me to repeat the oft-mentioned wiki page for new ports, but it seems people here haven't looked through it properly:

http://www.rockbox.org/twiki/bin/view/Main/NewPort

Scanning the PCB and figuring out the firmware update file format are two very important steps...

The docs for the DM320 chip are not publicly available, but we know that they have leaked out and they are now possible to find on the internet...


One thing that puzzles me. On its big brother's PCB (Zen Vision) there's a Toshiba gate array doing (most likely) an ATA interface, because the DM320's lacks proper DMA support on its Compact Flash interface.

On the screenshots of the Zen Vision:M PCB i've seen so far this IC is not present. Does this mean that the Zen Vision:M accesses its hard drive via PIO mode ?
Title: Re: Creative Zen Vision:M
Post by: keytotime on November 05, 2006, 08:21:58 AM
The Datasheet links are all available on the ArchOpen Wiki:
http://www.archopen.org/tiki-index.php?page=AV3xx_Chipset
Title: Re: Creative Zen Vision:M
Post by: Otaku on November 06, 2006, 07:50:53 AM
Bah.
I've made the offer in pm to a couple of users, now I throw it open to the floor - anyone care to supply an nk.bin I can examine ?
Cheers
O.
Title: Re: Creative Zen Vision:M
Post by: saratoga on November 11, 2006, 03:22:28 AM

Bah.
I've made the offer in pm to a couple of users, now I throw it open to the floor - anyone care to supply an nk.bin I can examine ?
Cheers
O.


How do I get the file?
Title: Re: Creative Zen Vision:M
Post by: saratoga on November 12, 2006, 01:28:49 AM

Bah.
I've made the offer in pm to a couple of users, now I throw it open to the floor - anyone care to supply an nk.bin I can examine ?
Cheers
O.


I helpful user noticed this thread and IMed me this link to his nk.bin file:

http://www.epizenter.net/e107_plugins/forum/forum_viewtopic.php?56222.0

Edit:  And yes, it appears to be unencrypted.  Theres large segments that are not ARM, but I'm guessing thats the DSP code and I just don't know how to dissassemble it.
Title: Re: Creative Zen Vision:M
Post by: dan_a on November 12, 2006, 03:02:47 PM

Theres large segments that are not ARM, but I'm guessing thats the DSP code and I just don't know how to dissassemble it.



I've not looked at the file, but is it possible that it's thumb code?
Title: Re: Creative Zen Vision:M
Post by: saratoga on November 12, 2006, 03:42:31 PM
I'm not sure.  BX is the switch to thumb op right?  I didn't even think to look at it, as I'm still get used to this windows dissassembler I'm (trying) to use.  If I get a chance this week i'll look into it.

In the meantime, are any developers seriously interested in this platform?  Given that its ARM9 and we can dissassemble the firmware, this probably isn't that difficult of a port, except maybe the audio playback drive.  But I know I don't have the time or the technical ability to do it myself.
Title: Re: Creative Zen Vision:M
Post by: Bagder on November 12, 2006, 05:08:00 PM
it is a TMS320DM320 based target and the archopen guys have gotten sounds on such a chip so I would guess we should be able as well! ;-)
Title: Re: Creative Zen Vision:M
Post by: ssjmichael on January 04, 2007, 12:07:37 PM
Someone at epiiZENter.net is making some sort of progress on extracting parts of the firmware. I really don't understand most of the stuff he's mentioning so I'll ask and see if he can post here too.



This is an excerpt from what he last wrote:

Quote
I've made a little bit progress on transferring a new firmware to the ZVM. I wanted to this by replacing the nk.bin file in the C:\CtJbFW\cttemp\ folder with the hacked one, by hooking the CreateFile and the WriteFile API.
However, it seems that the upgrade program uses the NtCreateFile API and I do not really know how to hook this one. I managed to block the WriteFile API calls to the nk.bin file, but as the program starts, it does a NtCreateFile call which overwrites the nk.bin file. Now I want to know how to hook this one, so I can block it too. Then I would place the hacked nk.bin file in the folder and hopefully, the program would transfer it to the ZVM.

I used [link=http://www.osix.net/modules/article/?id=728]this[/link] tutorial to hook the WriteFile API calls, but I haven't tried yet with the NtCreateFile, also because this one is in the NTDLL and not in the KERNEL32.

Now, I doubt that anyone has experience with API hooking, but if this is incorrect, plz let me know so that I can finish this hack and we could transfer some hacked firmwares to the ZVM. I will try to hook the NtCreateFile API in the VERNEL32.dll (the hacked KERNEL32, read the tutorial) but I think it won't work. I don't really know an other way, but we could of course copy the USB transfer commands, but I think the API hooking way is faster.


http://www.epizenter.net/e107_plugins/forum/forum_viewtopic.php?69697.30


If anyone here who knows more about this stuff could assist him on the next step it'd be much appreciated!
Title: Re: Creative Zen Vision:M
Post by: mitch04 on January 18, 2007, 05:02:35 AM
hi there making good progress mcuelenaere is nearly there but he said that he needs help  with passing the checksum or signature validation. if anyone can help it would be great
Title: Re: Creative Zen Vision:M
Post by: mitch04 on January 24, 2007, 09:54:22 PM
hey i emailed Creative about this, and all the guy would say was that he'd "hand over the request to the firmware team. so if someone from rockbox could email them they said they will release you codes
Title: Re: Creative Zen Vision:M
Post by: Bagder on January 25, 2007, 02:38:26 AM

if someone from rockbox could email them they said they will release you codes


I seriously doubt that is what they said, or at least that they truly meant it.

Then, since Rockbox is not a formal company nor group, there is no strict membership nor any strict organization so everyone involved who consider themselves a follower and believer can consider themselves "from Rockbox".

So go ahead and mail them I say.
Title: Re: Creative Zen Vision:M
Post by: Hoffmann on February 28, 2007, 06:43:24 PM
I'd like to participate as well.
Is there a Wiki with information about everything that allready happend (project status), a mailinglist, an irc-channel? Any kind of collected infos or ways of communication?

Hope we will Rock it!
Title: Re: Creative Zen Vision:M
Post by: AlexP on February 28, 2007, 07:04:15 PM

Is there a Wiki with information about everything that allready happend (project status)


http://www.rockbox.org/twiki/bin/view/Main/NonArchos#Zen_Vision_M

Seems to be it for now


a mailinglist


http://www.rockbox.org/mail/


an irc-channel?


http://www.rockbox.org/irc/


Hope we will Rock it!


Good luck
Title: Re: Creative Zen Vision:M
Post by: saratoga on February 28, 2007, 07:07:42 PM

I'd like to participate as well.
Is there a Wiki with information about everything that allready happend (project status), a mailinglist, an irc-channel? Any kind of collected infos or ways of communication?

Hope we will Rock it!


There are rockbox mailing lists and an IRC channel you're welcome to use.  All the info about the Vision:M specifically is in this thread.  There is some info on the CPU here:

http://www.rockbox.org/twiki/bin/view/Main/TexasInstrumentsTMS320

Establishing a Wiki page would be a good idea so that you have some central place to put information.  I believe you can get write access to the Wiki by asking on the IRC channel.  And of course, this is always good to read before you do anything:

http://www.rockbox.org/twiki/bin/view/Main/NewPort
Title: Re: Creative Zen Vision:M
Post by: jhulst on February 28, 2007, 10:02:24 PM
I am working on getting the stuff together.  The biggest thing right now is the scans of the inside of the player.  If I try to take apart my player, I think it's going to break and right now I can't afford to get a new one or donate that much money to a project.  I asked for write access in the IRC Channel but so far have had no luck with any replies.  As soon as I get the access, I will make the initial port page.

jwh
Title: Re: Creative Zen Vision:M
Post by: toxi on March 01, 2007, 12:30:50 AM
Hi guys,
I'm very interested in this rock box port for the zvm.
Are you guys still needing a zvm as a test machine?
If so I have 1 thats in pieces at the moment.
I think I had some dust or something in the buttons as they were not working right, so I took it apart, but kinda screwed up the electronic ribbon for the screen.
The buttons appear to be working fine now but the screen doesn't work.
I'm planning on buying a new one pretty soon but this old one will proberbly just sit there.
I'm thinking this might help the project roll forward.
What do you guys think?
I currently live in Ludington, Michigan, USA and the only thing I would ask for in return is a reimbursement for postage.
Title: Re: Creative Zen Vision:M
Post by: toxi on March 01, 2007, 12:33:15 AM
I had better mention its the Creative Vision: M 30 gig model and everything appears to work......just a dead screen.
Title: Re: Creative Zen Vision:M
Post by: jhulst on March 01, 2007, 10:56:59 AM
That would be great.  I live near Grand Rapids so shipping wouldn't be too bad at all.  Would anyone else rather take it apart and scan it?

jwh
Title: Re: Creative Zen Vision:M
Post by: toffe on March 01, 2007, 11:36:34 AM
Hi,

I don't have a zen , but perhaps I can help you.
I work on the gigabeat F and S.
what I did was to take off the components of the board to trace all the signals.
I am going to buy a special tools to take off the component like cpu or memeory from the board.
If somebody has a broken zen , mother board not working, I can do the job to take off all the main components so
you can trace the signals on the board .

Just let me know
Title: Re: Creative Zen Vision:M
Post by: Hoffmann on March 01, 2007, 12:17:53 PM
As written before, there already have been some scans, if someone really wants to mess around with the hardware stuff, thats fine, but we don't need sending around an zvm just for scanning purposes.

If someone has a new status (what is with the ppl that tryed to understand the firmwareupdate?), please tell me, I will update the wiki-page.
If someone wants to participate, I'm also collecting the contact-data

Please take a look at the wiki-page (http://www.rockbox.org/twiki/bin/view/Main/CreativeZVMPort)

03/01/07 8:00PM EST = 2.03.2007 2:00 (AM) CET (sorry, we know, it's late)
(corrected transcription)
Title: Re: Creative Zen Vision:M
Post by: jhulst on March 01, 2007, 01:05:25 PM
We will be having an informal meeting in the the IRC Channel irc.freenode.net #rockbox at 8 p.m. Eastern Time on 3/1/07. Anybody even remotely interested in the project is encouraged to be there. We will be working on getting a plan together to go forward and see what we are working with.

jwh
Title: Re: Creative Zen Vision:M
Post by: saratoga on March 01, 2007, 10:54:31 PM
The archopen people are hosting the data sheet for the tms320dsc24:

http://www.archopen.org/tiki-list_file_gallery.php?galleryId=3

Here is the TI docs for the DSP core itself:
http://focus.ti.com/lit/ug/spru131g/spru131g.pdf

Since it looks like the device can boot even if you screw up the hard disk, the next step is to figure out how to run stuff on the device.  Based on the comments above, it seems like the firmware is unencrypted, and protected only by a simple checksum.  If someone figured out how the checksum worked, we could run whatever we liked on the device.  Cracking the checksum will probably involve figuring out where it's computed, and stealing their algorithm.  
Title: Re: Creative Zen Vision:M
Post by: nickqueen on March 01, 2007, 11:25:25 PM
Keep in mind I'm by no means a programmer, but I do wish to help if I can. I went on a scavenger hunt looking for any info i thought might be useful. I'll list it below:

Programming Spansion S29GL032M-TA-R2 by a ChipProg+ device programmer
http://www.chipprog.com/spansion/s29gl032m-ta-r2_3tsop.shtml

29GL032M - 256,128,64,32,Megabit 3.0 Volt-only Page Mode Flash Memory featuring 0.23 ¥ìm MirrorBit Process Technology - SPANSION Datasheet
http://www.alldatasheet.com/datasheet-pdf/pdf/164984/SPANSION/S29GL032M.html

Philips ISP1583 Datasheet
http://www.chipcatalog.com/Philips/ISP1583.htm

Finally, this is the most I could find on Infineon datasheets
http://www.datasheetcatalog.com/infineon/1/

Are we sure about that model number?

Hope this helps!

Nick
Title: Re: Creative Zen Vision:M
Post by: AlexP on March 02, 2007, 04:01:46 AM

03/01/07 8:00PM EST = 1.04.2007 2:00 (AM) MEZ (sorry, we know, it's late)


Sorry, I'm a little confused about your date.  I assume by 1.04.2007 you actually mean 02.03.2007, i.e. 2nd March given 03/01/07 is in US speak 1st March?  [off topic] I swear I'll never understand why the USA does month/day/year rather then either day/month/year or year/month/day, both of which are so much more logical  :D[/off topic]

Back on topic, just a point about the 2am CET (I think MEZ is the German abbreviation for Central European Time), but most of the core devs are in Europe, so if you wanted their input to your ideas, you may want to consider moving your gathering earlier to a time when they are likely to not be in bed.
Title: Re: Creative Zen Vision:M
Post by: Hoffmann on March 02, 2007, 09:24:54 AM
Sorry BigBambi, I messed it up, you are right...
Next meeting should be at a date that is easier for europeans and still atendable for americans.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 03, 2007, 08:23:46 AM
Hi there,

I saw that you're looking for some older firmwares of the ZVM (+ extracted nk.bin); well there are some at http://epizenter.net/e107_plugins/forum/forum_viewtopic.php?69697.105#post_74257, even some older ones (but without nk.bin extracted) if you look further into the thread...

I've also extracted the separate data blocks of the newest firmware, so the data is more or less separated from the binaries (there are some FBOOT and FRESC blocks; also an encrypted one), but a quick scan with IDA shows me no useful info (although, I'll have to tell, I'm not an assembler/hex expert, I have no experience whatsoever).

I'll post the .rar file with the blocks somewhat later, first I have to upload it  :)

Edit:

http://rapidshare.com/files/19190349/ZVM.rar.html
Title: Re: Creative Zen Vision:M
Post by: koston on March 05, 2007, 06:43:43 AM
Ive looked through the firmware updater a several times but i can't find any CRC or other Checksum Check and i don't believe that is decrypted. Ive tried to debug the updating process but Olly doesn't brake when i press the update button and i don't know why.
Title: Re: Creative Zen Vision:M
Post by: Otaku on March 05, 2007, 10:39:35 AM
Its entirely possible any crc validation/decryption is done on the unit itself. All the PC software would need to be aware of is the return code.
O.
Title: Re: Creative Zen Vision:M
Post by: saratoga on March 05, 2007, 11:49:55 AM
The check is likely done by the bootloader.  It wouldn't make sense to hand control over to the software unit and then do a checksum.  Though it'd be nice if they did that, since then we wouldn't have to do anything other then delete the original firmware!
Title: Re: Creative Zen Vision:M
Post by: jhulst on March 08, 2007, 07:01:13 PM
So where are we at?  Anybody making any progress or even actively working on this?
Title: Re: Creative Zen Vision:M
Post by: koston on March 09, 2007, 04:48:53 AM
I think we should wait until breihanj gets his tool for the HDD.
Title: Re: Creative Zen Vision:M
Post by: toffe on March 10, 2007, 05:28:43 PM
Hello

If the hard drive has a zif connector, like the zune, the gigabeat S and the ipod, you will not find a cheap interface in the US, the cheapest I found is 120$.
But I found it in France for 60$ delivered in the us, check this site : http://www.pc-look.com/boutik/product_info.php?products_id=7838&referer=PrixMateriel
This interface works for hitachi and toshiba hd, you just have to take care on which way you connect it.

If the hard drive has a standard connector, it is easy to find adaptor in the US but it is different if the hd is a toshiba or a hitachi.

What kind of hd do you have on the zen ? what is the reference ?


Title: Re: Creative Zen Vision:M
Post by: nickqueen on March 11, 2007, 12:35:18 AM

Hello

If the hard drive has a zif connector, like the zune, the gigabeat S and the ipod, you will not find a cheap interface in the US, the cheapest I found is 120$.
But I found it in France for 60$ delivered in the us, check this site : http://www.pc-look.com/boutik/product_info.php?products_id=7838&referer=PrixMateriel
This interface works for hitachi and toshiba hd, you just have to take care on which way you connect it.

If the hard drive has a standard connector, it is easy to find adaptor in the US but it is different if the hd is a toshiba or a hitachi.

What kind of hd do you have on the zen ? what is the reference ?


On Anything But Ipod it shows a picture of the HDD

It is a Toshiba hdd1442 C.
Title: Re: Creative Zen Vision:M
Post by: mitch04 on March 11, 2007, 01:29:56 AM
this is great people Im willing to help you. hope to speak to you on IRC.
heres another site http://www.epizenter.net/e107_plugins/forum/forum_viewtopic.php?69697.165 thats been trying to crack the firmware as well.

Keep the great work up ! ;D
Title: Re: Creative Zen Vision:M
Post by: toffe on March 11, 2007, 12:12:11 PM
I check the picture on the site , the ref hd1442 c is not the real ref of the hd which is hidden on the picture. the real ref should be mk3006gal.

the connector for this hd is a female connector .

you can find the interface for this drive here :
http://www.addonics.com/products/io/aaedt18IDE25.asp

you can also use an external usb case which support toshiba hd like this one :
http://www.coolerexpress.com/noname.html

The external case should be the easiest to use.
Title: Re: Creative Zen Vision:M
Post by: saratoga on March 15, 2007, 06:39:03 PM
Did anyone ever bother to post scans?  If so, could we get them on the Wiki please?
Title: Re: Creative Zen Vision:M
Post by: jhulst on March 15, 2007, 08:24:52 PM
We have a broken player that will be scanned as soon as it is shipped to me, and yes the scans will immediately go on the wiki.

jwh
Title: Re: Creative Zen Vision:M
Post by: saratoga on March 16, 2007, 12:58:52 AM

We have a broken player that will be scanned as soon as it is shipped to me, and yes the scans will immediately go on the wiki.

jwh


Thats good to hear.  

By the way, if no one else figures out a way to get code running on the ZVM, I was going to suggest that someone get a broken player, desolder the flash ROM and then dump it with an EEPROM programmer.  The chip is TSOP with just an 8 bit bus, so it wouldn't be that hard to do.  Hypothetically, would you be willing to do this, or else mail the EEPROM chip to someone with the equipment?
Title: Re: Creative Zen Vision:M
Post by: mitch04 on March 16, 2007, 09:22:59 PM

We have a broken player that will be scanned as soon as it is shipped to me, and yes the scans will immediately go on the wiki.

jwh


hey are you sure his gonna send you it?
Title: Re: Creative Zen Vision:M
Post by: jhulst on March 17, 2007, 01:08:29 PM

Hypothetically, would you be willing to do this, or else mail the EEPROM chip to someone with the equipment?

I don't have the equipment for this, but I would be happy to mail it to somebody who does.


hey are you sure his gonna send you it?

Last I heard he was going to.  This was on Monday or Tuesday, I have not heard back since.

jwh
Title: Re: Creative Zen Vision:M
Post by: mitch04 on March 17, 2007, 06:53:04 PM
oh k i found it, it was toxi that has a creative zen vision m that the screen is broken so toxi
 would you be able to send it to  jhulst ? to help out for rockbox
Title: Re: Creative Zen Vision:M
Post by: MagistrateD on March 19, 2007, 08:02:32 PM
I do not know much (any) C++ or anything about hardware but i have a fully functional zvm that if someone tells me what to try i will (I do not want to give it away, sry, once the firmware is cracked im looking forward to using it).
Title: Re: Creative Zen Vision:M
Post by: saratoga on March 19, 2007, 08:29:45 PM

I do not know much (any) C++ or anything about hardware but i have a fully functional zvm that if someone tells me what to try i will (I do not want to give it away, sry, once the firmware is cracked im looking forward to using it).


Rockbox doesn't use c++, so you won't need to know anything about that.  What would be useful is someone figuring out a way to run code on the Zen, so feel free to look through this thread, and start digging into the Zen's retail firmware.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 20, 2007, 03:55:56 PM
Hi,

I tried to disassemble the FBOOT block of the firmware with IDA, and I think I have some results, the only problem is I don't have any knowledge of ASM! ;)

Could anyone with some IDA experience check if I'm on the right track, or if I'm doing this completely wrong ? (http://www.verzend.be/v/557093/FBOOT.rar.html)

Thx!
Title: Re: Creative Zen Vision:M
Post by: saratoga on March 20, 2007, 05:48:15 PM

Hi,

I tried to disassemble the FBOOT block of the firmware with IDA, and I think I have some results, the only problem is I don't have any knowledge of ASM! ;)



I don't think theres any point in reading the asm if you don't understand it.  What are you trying to do?  If you just want to learn asm, theres easier ways to do that.
Title: Re: Creative Zen Vision:M
Post by: jhulst on March 20, 2007, 08:47:36 PM
We now have some initial scans of the ZVM in the wiki (http://www.rockbox.org/twiki/bin/view/Main/PicturesZVM)  Hopefully more will be coming soon.

jwh
Title: Re: Creative Zen Vision:M
Post by: jhulst on March 20, 2007, 10:47:37 PM
As of now, I have not heard from Toxi in about 8 days. I'm going to assume that he had a change of heart unless I hear otherwise.  Anybody have any ideas on how we could get a different unit to take apart and remove the EEPROM?  Maybe we could get a broken one off of Ebay or some other place.

jwh
Title: Re: Creative Zen Vision:M
Post by: Bagder on March 21, 2007, 02:35:15 AM
We've successfully bought broken players before on ebay for dissecting purposes...
Title: Re: Creative Zen Vision:M
Post by: mitch04 on March 21, 2007, 04:44:53 AM
oh really so mabe we can put some money in to get one
Title: Re: Creative Zen Vision:M
Post by: jhulst on March 21, 2007, 09:46:51 AM
There seem to be a few cheap ones on Ebay ending in a few hours.
Here (http://cgi.ebay.com/BROKEN-Creative-Zen-Vision-mp3-player-30GB-parts-M_W0QQitemZ280091853661QQcategoryZ73839QQssPageNameZWDVWQQrdZ1QQcmdZViewItem) and  here (http://cgi.ebay.com/BROKEN-Creative-Zen-Vision-mp3-player-30GB-parts-M_W0QQitemZ280091854194QQcategoryZ73839QQssPageNameZWDVWQQrdZ1QQcmdZViewItem)
Any thoughts on these?

jwh
Title: Re: Creative Zen Vision:M
Post by: jhulst on March 22, 2007, 09:02:58 PM
Toxi,
I'd be willing to buy your broken ZVM if you decided you don't want to donate it.  You can contact me off the forum if you are interested.

jwh
Title: Re: Creative Zen Vision:M
Post by: bgdwie on March 23, 2007, 06:16:46 AM
hi, i have no experience in programming what so ever, but, i have a unit, some will and a large amount of spare time. i was thinking, can't you just brute force the checksum somehow, once you get a match, do it a few more times then find a pattern or look through for where the player makes/generates the checksum?
Title: Re: Creative Zen Vision:M
Post by: saratoga on March 23, 2007, 09:42:37 AM

hi, i have no experience in programming what so ever, but, i have a unit, some will and a large amount of spare time. i was thinking, can't you just brute force the checksum somehow, once you get a match, do it a few more times then find a pattern or look through for where the player makes/generates the checksum?


If you figure out how to brute force the checksum, or to get the assembly used by the player to generate the checksum, be sure to tell us.  Until then, yes its possible, but someone needs to figure out a way to do it.
Title: Re: Creative Zen Vision:M
Post by: iSE on March 28, 2007, 06:30:48 PM
I am extremely interested in this issue and would very much like to help if I can.
Title: Re: Creative Zen Vision:M
Post by: jhulst on March 28, 2007, 08:29:05 PM

I am extremely interested in this issue and would very much like to help if I can.


Right now our biggest need is figuring out how to load our own firmware.  Any help is appreciated.

On another note, a test player is being sent to me.  Is there someone who could download the EEPROM contents if I sent it to them?

jwh
Title: Re: Creative Zen Vision:M
Post by: iSE on March 29, 2007, 03:27:47 PM
I know exactly what you mean mrsubway, theres a fair few things which just niggle at you and serve to ruin an otherwise excellent machine.

jhulst - im assuming that if we can find the file on the harddrive which is the firmware, it would be fairly simple to transfer something else in its place? I'm wondering if it may be worth comparing the firmware update file for two completely different Creative Zen's. The firmware would then be different and the simularities between the files code (using decompilers) would be how the firmware is transferred to the player?
Title: Re: Creative Zen Vision:M
Post by: saratoga on March 29, 2007, 03:47:05 PM

jhulst - im assuming that if we can find the file on the harddrive which is the firmware, it would be fairly simple to transfer something else in its place?


We've been over this 5 or 6 times in this thread.  I'll summarize it once again, but if you want details, you'll need to read the last 2 pages or so.  We have the firmware already and a way to upload whatever firmware we want to the Vision:M.  Theres a link to it in this thread and info about hows its done.  What we don't have is a way to sign    our own code so that the bootloader on the Vision:M will run it.


I'm wondering if it may be worth comparing the firmware update file for two completely different Creative Zen's.


Yes I've been suggesting this to people.  Its how the Sansa port began.
Title: Re: Creative Zen Vision:M
Post by: iSE on March 30, 2007, 10:06:02 AM
Sorry, I read the first like 4 pages and the last one, i didnt know you already had a way to upload it. So i'm guessing the bootloader runs a CRC check, using the MD5 checksum? Or is it creative's own cryptochecksum lol.
Title: Re: Creative Zen Vision:M
Post by: saratoga on March 30, 2007, 10:31:30 AM

Sorry, I read the first like 4 pages and the last one, i didnt know you already had a way to upload it. So i'm guessing the bootloader runs a CRC check, using the MD5 checksum? Or is it creative's own cryptochecksum lol.


I don't think anyone knows.  The extent of the effort so far has been to try and change strings and then upload them to the device.  Since this fails whatever check there is, it doesn't work.  I don't think anyone has made any serious attempt to figure out why.

Edit:  You could be the first.
Title: Re: Creative Zen Vision:M
Post by: iSE on March 30, 2007, 10:44:39 AM
Well if you can get me the info about the new firmware and how its transferred I will do what I can to figure out a way. And I do have some experience though I can't promise anything lol! You know how it is.
Title: Re: Creative Zen Vision:M
Post by: saratoga on March 30, 2007, 10:53:42 AM
Actually, having reread the epizenter thread, it looks like the checksum is done by the firmware update utility.  Or at least a checksum is.  So I think I was wrong about having a way to update the firmware.  Theres a possible way, once the checksum is calculated, but I don't think anyone has managed it.  

At least from reading that thread, it sounds like the upgrade progress is failing on the PC side, not the device side.  I could be wrong though.

http://www.epizenter.net/e107_plugins/forum/forum_viewtopic.php?69697.0
Title: Re: Creative Zen Vision:M
Post by: iSE on March 30, 2007, 04:15:13 PM
Right, so I was wondering, when jhulst is finally able to hook up the harddrive of one to the computer (I would have a go but I'm still waiting for someone to say how to open the damn thing without using a crowbar). But yes, if its possible to explore the file system, lets hope there is a file sitting there called NK.bin. So unless the bootloader performs a CRC check (which I don't see how thats possible with updating the firmware unless the update program changes the bootloader which would be really over the top) then hopefully it will be a simple matter of replacing that file. Next step would be to find out how to replace the file through a USB cable, once we know where the file is. I am hoping once we can work out what filesystem is used, I may be able to get it to work through just the USB cable. (One of the benefits of Linux and the way it mounts things!)
Title: Re: Creative Zen Vision:M
Post by: saratoga on March 30, 2007, 04:31:54 PM

 So unless the bootloader performs a CRC check (which I don't see how thats possible with updating the firmware unless the update program changes the bootloader which would be really over the top) then hopefully it will be a simple matter of replacing that file.


Most players do a check in order to prevent people from hacking their firmware.  Its actually very easy, they just have the bootloader compute a hash, and compare it to the hash written in the binary itself.  Some even take this a step farther and use the hash to encrypt the entire firmware file.  I'm expecting some sort of hash check in the bootloader, but you never know.
Title: Re: Creative Zen Vision:M
Post by: iSE on March 30, 2007, 04:53:40 PM
A hash by using an algorithm then? I was meaning by using it size and properties to calculate a checksum, by updating the file the checksum would change however. So how to Creative get the firmware to pass then which otherways can't? Would simply replacing the file on the HD cause an abort when switching it on then?
Title: Re: Creative Zen Vision:M
Post by: saratoga on March 30, 2007, 05:06:01 PM

A hash by using an algorithm then?


A hash is just a number produced by an algorithm, so yes.


I was meaning by using it size and properties to calculate a checksum, by updating the file the checksum would change however.


Generally checksums are computed using the contents of a file, not its size (since size is already just a number, which would make creating a checksum from it pointless), but otherwise, this is also what I meant.


 So how to Creative get the firmware to pass then which otherways can't?


The most obvious way is to compute the hash, and then store it in the header of the file.  Then the bootloader or firmware update program can simply read off the expected hash, and then compute the hash over the rest of the file.  If the computed and read hashes match, then you know the file has not been tampered with.  If we knew where the hash was stored, and how it was generated, we could also produce our own firmware updates.  

Now, its not clear to me how this works, but it seems people in the above thread determined that the firmware update utility itself does a hash check.  The bootloader may or may not, but if it does, hopefully its the same one as the update utility.  So one way to proceed would be to look at the update utility and see if theres any clues in it as to how the hash is made.  At least thats my understanding from reading the various stuff posted here ( I don't have a Creative player).


 Would simply replacing the file on the HD cause an abort when switching it on then?


On the Sansa and many other players, this is exactly what happens.
Title: Re: Creative Zen Vision:M
Post by: iSE on March 30, 2007, 05:18:58 PM
So once we have a new firmware we have to convince the player that its legit by getting it to pass the same checksum tests which the legit version would. I don't suppose we could just ring up Creative and ask?
Title: Re: Creative Zen Vision:M
Post by: saratoga on March 30, 2007, 06:17:27 PM

So once we have a new firmware we have to convince the player that its legit by getting it to pass the same checksum tests which the legit version would. I don't suppose we could just ring up Creative and ask?


Check page 4 or 5 of this thread.
Title: Re: Creative Zen Vision:M
Post by: iSE on March 30, 2007, 06:44:03 PM
Ok I've read everything now, there seems to be a lot of things starting and very little finishing. If money is a problem, I will be willing to donate some for this cause as I've already spent a fortune on this player, I'd be willing to pay some more to get it to work well!

I have already tried posting in the creative forums, no one seems to help, I'll try emailing and nagging creative until they give me a response worthwhile. If anyone can tell me how I can safely take apart my Zen to gain direct access to the harddrive I will give it a go. In the meanwhile I'm going to do what I can to dissect the update program and continue to try to force mount the zen. If only I knew what filesystem it supported it would be so much easier to gain access to it.
Title: Re: Creative Zen Vision:M
Post by: jhulst on March 30, 2007, 11:54:00 PM

I have already tried posting in the creative forums, no one seems to help, I'll try emailing and nagging creative until they give me a response worthwhile.


The most worthwhile response I got was where they told me to go buy a different player if I wasn't happy with what I had.

As for the test machine, I got it, took it apart, and am now trying to figure out what kind of an adapter is needed for the harddrive and how it would hook up.  I'll post pictures when I get a chance.  It seems that there are two different hard drives.  A Toshiba and a Hitachi.  The Toshiba seems to have an IDE interface, the Hitachi we think is ZIF but are having a hard time getting the ribbon detached.

jwh
Title: Re: Creative Zen Vision:M
Post by: jhulst on March 31, 2007, 01:33:02 AM

If money is a problem, I will be willing to donate some for this cause as I've already spent a fortune on this player, I'd be willing to pay some more to get it to work well!

Right now I think we are sitting okay with money,  I bought a test player and breihanj is taking care of the hard drive adapter.


Right, so I was wondering, when jhulst is finally able to hook up the harddrive of one to the computer (I would have a go but I'm still waiting for someone to say how to open the damn thing without using a crowbar).

There is a how to on disassembling the player at anythingbutipod.com (http://www.anythingbutipod.com/archives/2006/02/how-to-disassemble-the-creative-zen-vision-m.php).  If you have any specific questions, feel free to ask me, I've been able to get mine taken apart.  I'm not sure what this would get you unless if you had an adapter for the drive.


continue to try to force mount the zen. If only I knew what filesystem it supported it would be so much easier to gain access to it.
 
I've experimented with this as well.  The way I see it, the current firmware controls all communication with the computer.  If you try plugging it in, the player automatically starts up and libmtp seems to be the only way that it is allowing it to talk to the computer.    So I am not sure how we can work around this.

As soon as the hard drive adapter comes, breihanj will get us dumps of the hard drive in as many configurations as possible.
Title: Re: Creative Zen Vision:M
Post by: iSE on March 31, 2007, 08:58:44 AM
Excellent, well I will await for you guys to produce some magic and help where I can. I may try opening up my player and seeing about the hard drive however, if we then have two test players with both of the hard drives that would certainly be an advantage don't you think? I'll update you as I have it, but right now I'm off to my gf's 21st!
Title: Re: Creative Zen Vision:M
Post by: Bagder on March 31, 2007, 10:17:18 AM
Allow me to re-iterate a few facts:

1 - The Neuros OSD is based on what seems to be the same chip, and thus there is public code to check out.

2 - ArchOpen has code that runs and plays audio on at least one other DM320 -based player, so there is more public code to check out.

AFAIK, the ArchOpen guys start their stuff on a buffer overflow mostly so perhaps you could try that too.
Title: Re: Creative Zen Vision:M
Post by: jhulst on March 31, 2007, 12:58:55 PM

1 - The Neuros OSD is based on what seems to be the same chip, and thus there is public code to check out.

2 - ArchOpen has code that runs and plays audio on at least one other DM320 -based player, so there is more public code to check out.


I've been spending some time exploring the code from these other projects.  There is a lot to go through.
Title: Re: Creative Zen Vision:M
Post by: iSE on April 01, 2007, 08:47:43 AM
Quote

I've been spending some time exploring the code from these other projects.  There is a lot to go through.


Need a hand? PM me if you want and I could try taking some that you havent been through off your hands?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on April 01, 2007, 01:46:13 PM

Allow me to re-iterate a few facts:

1 - The Neuros OSD is based on what seems to be the same chip, and thus there is public code to check out.

2 - ArchOpen has code that runs and plays audio on at least one other DM320 -based player, so there is more public code to check out.

AFAIK, the ArchOpen guys start their stuff on a buffer overflow mostly so perhaps you could try that too.


A question about the DSP: is it possible of using the API that Neuros uses ? I know there isn't any open-source alternative, so I thought we could use it or so ? Is this technically possible and, more important, does it comply with the licenses ? I know the DSP * doesn't have to be * implemented, but it would be very nice (especially for the battery-life)...

And another question: what about the compiler ?  Cause I read there isn't a open-source/free C54xx (compatible) compiler, or at least, not a working one... Or isn't this a problem ?
Title: Re: Creative Zen Vision:M
Post by: Bagder on April 01, 2007, 04:31:48 PM

A question about the DSP: is it possible of using the API that Neuros uses ? I know there isn't any open-source alternative, so I thought we could use it or so ? Is this technically possible and, more important, does it comply with the licenses ? I know the DSP * doesn't have to be * implemented, but it would be very nice (especially for the battery-life)...


The Neuros guys have said that you do have to use the DSP since the DSP side is what accesses the DAC so there's no sound otherwise. I guess the ArchOpen guys/source code can either dismiss or confirm this.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on April 02, 2007, 02:59:40 AM

The Neuros guys have said that you do have to use the DSP since the DSP side is what accesses the DAC so there's no sound otherwise. I guess the ArchOpen guys/source code can either dismiss or confirm this.


So actually, this is some very good news. And I understood that the DSP also is used for the MPEG4/Xvid/DivX playback ? And that it also supports other audio codecs than MP3/WMA? Are these implemented in the API of Neuros ? I'll take a look at the source code myself, but as I did this before and didn't came up with anything relevant, I thought it would be better if I asked it here.
Title: Re: Creative Zen Vision:M
Post by: iSE on April 02, 2007, 08:55:07 AM
Ok well I've finally managed to mount the ZEN as a filesystem in linux using mtpfs. It allows me to see what is seen in windows when browsing the drive. I cannot however read the files:

DeviceInfo.xml
DeviceIcon.fil
DeviceLogo.fil

I'm guessin that the latter two are the PNG files which were extracted from the nk.bin which leads me to believe that the bin is not copied to the ZEN but is a collection of files which go all over. My opinion now is also that the firmware is not located on the harddrive and is most probably a flash of one of the chips. I am currently going through the Neuros OSD information to look for help, I will post in their forums and will try and contact one of the devs to ask for advice. If I am wrong and somebody knows better on this, please feel free to correct me.
Title: Re: Creative Zen Vision:M
Post by: jhulst on April 02, 2007, 11:43:40 AM

Ok well I've finally managed to mount the ZEN as a filesystem in linux using mtpfs. It allows me to see what is seen in windows when browsing the drive. I cannot however read the files:

I also got this to work yesterday and I also couldn't read any of the files.


My opinion now is also that the firmware is not located on the harddrive and is most probably a flash of one of the chips.


On mine, I saw a few other files that I thought could be the firmware.  I'm not sure that this is conclusive proof as I still think with mounting it you are still going through the Zen firmware as evidenced by the inability to read any of the files.  My guess is the player is still showing only what it wants to be shown and not actually allowing a "true" disk mount.
Title: Re: Creative Zen Vision:M
Post by: toffe on April 02, 2007, 12:23:34 PM
The zen is running PMC like the toshiba S. (If I am not mistaken)

You see only the partition for data from your computer

It should be another partition with the system files and as it is pmc you should have a file called NK.BIN
You really need to connect the drive direct on a computer to confirm this
The flash should contain only a file called Eboot.bin
These are standard for all wince device.
Title: Re: Creative Zen Vision:M
Post by: iSE on April 02, 2007, 02:34:41 PM
Excellent toffe. I sincerely hope we get evidence to prove this from when the harddrive is connected directly. Would it ever be possible then, once we have confirmed the exact address on the disk of the firmware, to overwrite the existing one without having to take the device apart? (This is assuming we can get the checksum check to pass)
Title: Re: Creative Zen Vision:M
Post by: Llorean on April 02, 2007, 02:38:08 PM
With software controlled USB it only has to show you what it wants seen, even if it did have UMS.
Title: Re: Creative Zen Vision:M
Post by: saratoga on April 02, 2007, 02:52:46 PM
True, but the updater program can clearly overwrite the built in software, so there must be a way to do it.  Since Creative didn't bother to encrypt the firmware in any way, I tend to think they haven't given much thought to obfuscation.   Maybe we'll get lucky.
Title: Re: Creative Zen Vision:M
Post by: Danrarbc on April 02, 2007, 03:34:52 PM

The zen is running PMC like the toshiba S. (If I am not mistaken)

I'm pretty sure it isn't. It's one of the reasons I bought it over the Toshiba cause I've read PMC isn't so hot.
Title: Re: Creative Zen Vision:M
Post by: Bagder on April 02, 2007, 03:40:47 PM


The Neuros guys have said that you do have to use the DSP since the DSP side is what accesses the DAC so there's no sound otherwise. I guess the ArchOpen guys/source code can either dismiss or confirm this.


So actually, this is some very good news. And I understood that the DSP also is used for the MPEG4/Xvid/DivX playback ? And that it also supports other audio codecs than MP3/WMA? Are these implemented in the API of Neuros ? I'll take a look at the source code myself, but as I did this before and didn't came up with anything relevant, I thought it would be better if I asked it here.


The DSP is used for everything DAC-related so that would include videos, yes. And the chip wouldn't have a chance to display full frame-rate video on a TV without using the DSP pretty good.

Lots of the codecs Neuros use are in the DSP parts and they're not provided in source at all.
Title: Re: Creative Zen Vision:M
Post by: toffe on April 02, 2007, 03:48:03 PM
you are right, they have a zen pmc, and the zen m seems to be a creative software, not pmc
my mistake :(
Title: Re: Creative Zen Vision:M
Post by: saratoga on April 02, 2007, 08:00:03 PM
Its definately based on Windows CE (hence the nk.bin and MS dev tools for everything).

PMC is also based on Windows CE, so it may be basically the same thing.

Edit:

Also, heres the nk.bin if anyone else wants a look:

http://www.duke.edu/~mgg6/rockbox/nk.bin

Also, the nk.bin is compressed inside the updater, so don't expect to see ARM in there.  Even zipped its still about 10-12MB, maybe more, so almost the entire updater is just the compressed file with a bit of x86 to decompress it and handle the USB stuff I think.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on April 03, 2007, 02:32:43 AM

Its definately based on Windows CE (hence the nk.bin and MS dev tools for everything).

PMC is also based on Windows CE, so it may be basically the same thing.

Edit:

Also, heres the nk.bin if anyone else wants a look:

http://www.duke.edu/~mgg6/rockbox/nk.bin

Also, the nk.bin is compressed inside the updater, so don't expect to see ARM in there.  Even zipped its still about 10-12MB, maybe more, so almost the entire updater is just the compressed file with a bit of x86 to decompress it and handle the USB stuff I think.


I sincerely doubt it that ZVM is running WinCE. You are right concerning the updater program, but I'm not sure if you read through the epizenter.net thread, cause there has been already some "disassembling" on the nk.bin: it's splitted up in several blocks and those can be extracted.

According to http://libnjb.cvs.sourceforge.net/libnjb/libnjb/HACKING?revision=HEAD(search for 'CIFF'), these files are also (partly) on older Zen's, which means the OS of the ZVM is based on their OS, and (stated in that same file) the OS of a Jukebox is OaSis; I don't know if this is the same on the Zen Xtra or newer Zen's...

Anyway, if you haven't read the epizenter.net thread, plz do it sometime; if you have, srry for bringing this up.
Title: Re: Creative Zen Vision:M
Post by: larryzotter on April 03, 2007, 09:25:15 AM
Anyone tried taking out the ZVM's hdd and plugging it using an adapter to a computer?
Title: Re: Creative Zen Vision:M
Post by: iSE on April 03, 2007, 10:44:47 AM
yeah, I think jhulst is awaiting an adapter for the test player he has
Title: Re: Creative Zen Vision:M
Post by: Febs on April 04, 2007, 07:21:55 AM
Folks, a reminder:  please DO NOT post in this thread merely to ask about updates.  Post in this thread ONLY if you are participating in discussion directly related to development of Rockbox for this platform.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on April 04, 2007, 11:10:56 AM
Hi,

as some of you may know, there's a lot of discussion about the ZVM and firmware hacking on epiZENter.net (http://epizenter.net/e107_plugins/forum/forum_viewtopic.php?69697.last)

In short, I'll make up a list of what we've found out and/or think which is correct:


Oh, and one more thing: I strongly believe that messing around with MTP leads to nothing: the firmware will never allow you to view it's partition data. (The only possible thing you could achieve, is uploading a new firmware)
Title: Re: Creative Zen Vision:M
Post by: kkffiirr on April 04, 2007, 12:36:08 PM
i like the idea about monitoring the usb activity, but it sounds so easy, why no one ever tested it?
i am thinking about monitoring it myself and posting the data here....
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on April 04, 2007, 12:39:09 PM

i like the idea about monitoring the usb activity, but it sounds so easy, why no one ever tested it?
i am thinking about monitoring it myself and posting the data here....


Actually, I did it myself before. I came up with a 90MB(or bigger) file and because my PC hasn't got much RAM and I didn't found any decent program to read it, I didn't do anything with it.
I think it's just some commands, then the raw nk.bin file, then again some commands and it's done.
Title: Re: Creative Zen Vision:M
Post by: aliask on April 04, 2007, 10:16:52 PM

Hi,
  • The last block (the NULL block) is 20 chars long, and contains a hash/checksum. It's no common used one, cause MD4, MD5, SHA1 don't match it. (20 chars should mean 160-bit)



SHA1 is 160 bit.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on April 05, 2007, 05:08:05 AM

SHA1 is 160 bit.


Indeed, but they don't match:

SHA-1 OF 'FFIC' BLOCK: 9A 4F 20 B0 2B F3 91 99 D7 A6 6A FD C7 A6 1C 68 10 AF 82 4A

DATA OF 'NULL' BLOCK: 41 A3 63 2B 2E C2 C6 F7 DF 31 99 D8 61 2E 76 99 77 07 CB 19

BTW, this is the 010 Editor Template I use for parsing the blocks, it works perfectly.
Code: [Select]
//--------------------------------------
//--- 010 Editor v2.0 Binary Template
//
// File: Creative firmware (nk.bin)-Parser
// Author: l_e
// Revision: 0.1
//--------------------------------------

typedef struct {
CHAR BlockID[4];
DWORD Size;
if (BlockID == "FNIC"){
UCHAR Desc[96];
} else if (BlockID == "LLUN" || BlockID == "FFIC"){
UCHAR Data[ Size ];
} else {
UCHAR Desc[32];
UCHAR Data[ Size - sizeof(Desc) ];
}
} BLOCK;
//--------------------------------------------

CHAR[] StrRev( CHAR s[] )
{
local int sz;
local int up;
local CHAR strng[sizeof(s)];

for (sz =sizeof(s)-1,up=0;upstrng[up] = s[sz];
}
return strng;
}


string ReadBLOCK( BLOCK &block )
{
return StrRev( block.BlockID );
}
//--------------------------------------------
local ulong id;
local ulong tmp;
local ulong ofs;

LittleEndian();
id = ReadUInt( FTell() );

if (id == 0x43494646){ // "CIFF"
BLOCK FFIC;
FSeek( 8 ); //Move back to first "real block", since CIFF-block includes most of the stuff
ofs = 8;
while ( !FEof() ){
FSeek( ofs );
BLOCK block;
FSeek( ofs+sizeof(block) );
ofs = FTell();
}
} else {
Warning ("Not valid CIFF-header. Exiting");
return -1;
}

//--------------------------------------
Title: Re: Creative Zen Vision:M
Post by: iSE on April 05, 2007, 09:06:31 AM
I'm no expert on cryptography, but supposed we were to literally try to brute force that encryption, how long would that take? If its a reasonable time frame, say a few months I have an incredibly fast computer not doing anything at the moment.
Title: Re: Creative Zen Vision:M
Post by: larryzotter on April 05, 2007, 09:33:06 AM
But how would u 'verify' that the bruteforced checksum is correct? Try and update the firmware with the checksum to the ZVM and see if it accepts it? That would take a looooooong time...
Title: Re: Creative Zen Vision:M
Post by: Bagder on April 05, 2007, 09:46:33 AM

I'm no expert on cryptography, but supposed we were to literally try to brute force that encryption,


160 bits SHA1 is simply not possible to brute-force within our lifetimes, even if we'd use a hundred thousand modern PCs. Compare with the 72bit RC5 cracking contest.

Edit: contest is not contents ;-)
Title: Re: Creative Zen Vision:M
Post by: bascule on April 06, 2007, 05:21:46 AM
Lots of off-topic posts removed :)
Please, only actual development-related posts here.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on April 06, 2007, 05:59:30 AM
OK, just a quick question: which program do you guys recommend me to capture the USB traffic?

For now, I'm going to use HHD Software's USB Monitor...

I'll post my results here in a minute or so...
Title: Re: Creative Zen Vision:M
Post by: iSE on April 06, 2007, 08:04:05 AM
A kernel debugger such as rr0d will give good results
Title: Re: Creative Zen Vision:M
Post by: HKK on April 12, 2007, 11:38:28 AM
Quote


SHA1 is 160 bit.


There's quite a few 160bit hashes. This site http://whatsmyip.org/hash_generator/ lists sha-1, tiger160, ripemd160 and haval160. I don't know how to work with these but maybe someone here does?
Title: Re: Creative Zen Vision:M
Post by: iSE on April 12, 2007, 12:42:54 PM
if you read mcuelenaere's post above, he's already tried several 160bit hashes and found them NOT to match
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on April 12, 2007, 04:58:26 PM

if you read mcuelenaere's post above, he's already tried several 160bit hashes and found them NOT to match


I've tried SHA-1, TIGER and RIPEMD160. You could try others yourself if you want to, but I'm having the feeling here that not very much people are comprehending what I'm saying. Maybe I'm just wrong, plz correct me if so, but I dunno if someone really understand what I mean if I'm talking about the NULL-block, or other parts of nk.bin's main structure.

Maybe I'll have to take some screens or document everything a bit, so (lazy) people understand what I'm talking about. If I'm totally wrong here, plz say it. Thx
Title: Re: Creative Zen Vision:M
Post by: iSE on April 12, 2007, 11:16:08 PM
Some of us know what you're talking about :P. Though I wouldn't say those who don't are lazy, more have not come across this before and just haven't had any experience with it.
Title: Re: Creative Zen Vision:M
Post by: Bagder on April 13, 2007, 02:17:36 AM

I've tried SHA-1, TIGER and RIPEMD160. You could try others yourself if you want to, but I'm having the feeling here that not very much people are comprehending what I'm saying.


We understand you fine - remember that we have reverse engineered a few other players before this... But I figure there are more than one way to run these hash algorithms on the data (like order of data, range of data, with or without padding etc) so I don't see how any random test-shots can exclude any particular algorithm until more details are discovered.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on April 13, 2007, 04:42:57 AM

We understand you fine - remember that we have reverse engineered a few other players before this... But I figure there are more than one way to run these hash algorithms on the data (like order of data, range of data, with or without padding etc) so I don't see how any random test-shots can exclude any particular algorithm until more details are discovered.


Yes OK, but I wasn't talking about the hash algorithm cracking; I wasn't sure that you(plural) knew what I was talking about when I mention the NULL block and stuff...

And if I insulted anyone, I'm sorry for that; it wasn't my intention to do so... :)
Title: Re: Creative Zen Vision:M
Post by: jhulst on April 13, 2007, 11:57:45 AM

We understand you fine - remember that we have reverse engineered a few other players before this... But I figure there are more than one way to run these hash algorithms on the data (like order of data, range of data, with or without padding etc) so I don't see how any random test-shots can exclude any particular algorithm until more details are discovered.


In the past, how did you figure out more details?  Is it best just to keep trying codes and seeing if the match up?  To me, that sounds like a lot of guessing.
Title: Re: Creative Zen Vision:M
Post by: jhulst on April 13, 2007, 11:58:43 AM

By the way, if no one else figures out a way to get code running on the ZVM, I was going to suggest that someone get a broken player, desolder the flash ROM and then dump it with an EEPROM programmer.  The chip is TSOP with just an 8 bit bus, so it wouldn't be that hard to do.  Hypothetically, would you be willing to do this, or else mail the EEPROM chip to someone with the equipment?


Is there anybody who would be able to dump this for me?  I will mail the flash ROM to you.
jwh
Title: Re: Creative Zen Vision:M
Post by: saratoga on April 13, 2007, 01:08:16 PM


By the way, if no one else figures out a way to get code running on the ZVM, I was going to suggest that someone get a broken player, desolder the flash ROM and then dump it with an EEPROM programmer.  The chip is TSOP with just an 8 bit bus, so it wouldn't be that hard to do.  Hypothetically, would you be willing to do this, or else mail the EEPROM chip to someone with the equipment?


Is there anybody who would be able to dump this for me?  I will mail the flash ROM to you.
jwh


I can ask around, but it sounds to me like looking at the Windows update program would be the best idea now, since it can likely be used to update the firmware, something we'll need to be able to do regardless.  
Title: Re: Creative Zen Vision:M
Post by: Bagder on April 13, 2007, 04:58:35 PM


We understand you fine - remember that we have reverse engineered a few other players before this... But I figure there are more than one way to run these hash algorithms on the data (like order of data, range of data, with or without padding etc) so I don't see how any random test-shots can exclude any particular algorithm until more details are discovered.


In the past, how did you figure out more details?  Is it best just to keep trying codes and seeing if the match up?  To me, that sounds like a lot of guessing.


The early targets had "simple" algorithms so they could be "cracked" differently.

For more recent targets (like the sansa), it has involved lots of dissassembly reading.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on April 14, 2007, 06:24:10 AM
I'll post this link here too (dunno if it's useful, most of it has already been said except maybe the last part): http://gim.6te.net/ZVM/zvm.html
(ignore the ads, it's a free hosting so.. ;) )
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on April 16, 2007, 12:36:36 PM

So what does the coincidence mentioned suggest? I do not really get it. Sorry.

It means I'm pretty sure that the NULL block contains a 160bit hash of the whole CIFF block
Title: Re: Creative Zen Vision:M
Post by: Sonic on April 16, 2007, 07:36:28 PM
Hey, people! I just bought a ZVM, but the one drawback was that it didn't support Rockbox. So I'd be willing to help, if someone could tell me how. I don't know how to program, but I could learn if somebody pointed me to a good tutorial, or something.  :D
Title: Re: Creative Zen Vision:M
Post by: CloudAge on April 16, 2007, 07:49:07 PM
I would like to help in anyway possible aswell is there any status to some extent on this project as of yet?
Title: Re: Creative Zen Vision:M
Post by: iSE on April 17, 2007, 12:10:57 AM
Unfortunately reverse engineering the firmware to a player is extremely difficult. It is not a simple case of follow this howto and here you go. We are all still trying to figure out how to get our own version of the firmware onto the player without it being rejected.

The reason it is rejected is because the hash check the player performs on the firmware fails, as in, it knows its not the original and so will not load it because it may be corrupt and/or tampered with. If anyone has any experience cracking cryptographic hashes, I suggest you read through the posts that have come before this and help in anyway you can. If you want to learn, it is through this where you will be able to help.
Title: Re: Creative Zen Vision:M
Post by: Sonic on April 19, 2007, 12:09:52 AM
So, if it's so hard to decode the hash, why not use the original hash, from the original firmware? Maybe the other parts of the firmware could be identified, and then we could just figure out which part was the hash. Unless that just sounds really stupid.  :o
Title: Re: Creative Zen Vision:M
Post by: iSE on April 19, 2007, 12:23:07 PM
Well the idea behind a hash is that it calculates it from the contents of the firmware, so if the contents change then when it tries to calculate the hash it will be wrong and so will fail. If we are able to calculate what the hash algorithm is then we could use it to give a fake one back to the player so it thinks it original firmware. Another way would be find what the hash actually is so we could give that back to the player and again fool it.
Title: Re: Creative Zen Vision:M
Post by: jhulst on April 19, 2007, 09:25:12 PM
If we are able to calculate what the hash algorithm is then we could use it to give a fake one back to the player so it thinks it original firmware. Another way would be find what the hash actually is so we could give that back to the player and again fool it.

We don't know how the hashing function and hash verification actually works as of yet, so this statement may not end up being completely true.  Depending on where/when the hash is calculated, the only way to "fool" the player may be to put the computed hash in the correct place of the firmware.

iSE, sorry to contradict you, but I think it's good to make sure the facts are being presented as best we know them so that people don't get confused.
Title: Re: Creative Zen Vision:M
Post by: jhulst on April 19, 2007, 09:48:26 PM
Take the following with a grain of salt as I have not had a lot of time to work through my findings:

It looks like the checksum/hash is being computed in the firmware update software.  It seems that the firmware updater program is divided into two parts, the main part, and a library called by the main part.

In the library, at line 7C93CF82, there are some references to Image Checksum.  From my understanding, one of the functions calls "LdrVerifyImageMatchesChecksum" which is at 7C93CFE4.  This may be where the checksum is calculated. 

To look at the code, I used OllyDbg (http://www.ollydbg.de/') and examined 1.61.01 version of the firmware.  I've mirrored the firmware updater (http://hulst.ws/zvm/ZENVisionM_30GB_PCFW_L21_1_61_01.exe)  (15 MB).  My way of getting to the library was to run the updater without a player plugged in.  It will terminate in the library.

Again, these are some very initial thoughts.  I am probably wrong about some, if not all of it, I just wanted to give a starting point that others who may want to help may begin to look at.

My next step will be to hookup a player and step through the code to try and understand what it is doing.

jwh

edit: fixed links
Title: Re: Creative Zen Vision:M
Post by: larryzotter on April 20, 2007, 08:25:09 AM
Do u mean the verifying is done i the updater program instead of the ZVM itself?
Title: Re: Creative Zen Vision:M
Post by: TheBlackCat on April 21, 2007, 12:05:51 PM
It may be done at both.  I am pretty sure the nk.bin file contains a checksum mismatch error message ("header checksum" I think it was called), which would indicate that there might be a checksum detection on the ZVM itself as well as the installer.  This would not matter if they used the same hash algorithm, but could be very annoying if they don't.

I don't know much about checksum, but it would seem to me that the hash algorithm could not include the checksum itself, right?  If that was the case they would have a "chicken and egg" problem where putting in the computed checksum would change the checksum, forcing you to recompute it.  The recomputed checksum would again change the checksum, etc.  If it is the case that the checksum avoids one part of the file, is it possible it might avoid others as well that are not considered important?

Another question: if we know where the checksum is being calculated would it be possible to delete that from the code entirely and replace it with some sort of "if 1=1" test or something trivial like that?  Or perhaps leave the algorithm in but bypass the test for whether there is actually a match or not.  I know nothing about assembly or machine code editing so I don't know if that is possible.  However, I would guess if people are ever able to understand the assembly or machine code well enough to determine the hash algorithm then it would be as easy if not easier to understand it well enough to bypass the test entirely in some way.  It probably wouldn't be a particularly elegant solution but it might save a lot of trouble.
Title: Re: Creative Zen Vision:M
Post by: saratoga on April 21, 2007, 12:29:16 PM


Another question: if we know where the checksum is being calculated would it be possible to delete that from the code entirely and replace it with some sort of "if 1=1" test or something trivial like that?  Or perhaps leave the algorithm in but bypass the test for whether there is actually a match or not.  I know nothing about assembly or machine code editing so I don't know if that is possible.  However, I would guess if people are ever able to understand the assembly or machine code well enough to determine the hash algorithm then it would be as easy if not easier to understand it well enough to bypass the test entirely in some way.  It probably wouldn't be a particularly elegant solution but it might save a lot of trouble.


Yeah, thats the easiest way around these things.  Find the "branch if not equal" instruction and change it to a NoOp.  That way it doesn't notice if the checksum/hash is wrong.  Ideally someone would work out the checksum, so that the software didn't need to be hacked (which would be awkward for rockbox since no one can distribute the hacked program).  But either now would be really interesting and a great start since it would let us know pretty quickly if there was a second check on the player itself.
Title: Re: Creative Zen Vision:M
Post by: larryzotter on April 21, 2007, 06:47:22 PM
What would be a good software to "see" whats in the nk.bin fle? I've tried a hex editor with not much luck.
Title: Re: Creative Zen Vision:M
Post by: jhulst on April 21, 2007, 11:31:58 PM

What would be a good software to "see" whats in the nk.bin fle? I've tried a hex editor with not much luck.


Check out reply #157 (http://forums.rockbox.org/index.php?topic=3320.msg76090#msg76090) for how mcuelenaere does it.
Title: Re: Creative Zen Vision:M
Post by: koston on April 25, 2007, 02:55:12 PM
So watch this:

http://www.bilder-speicher.de/07042521261533.vollbild.html

Seems to be a lot of Cryptoshit inside ;)

Quote
In the library, at line 7C93CF82, there are some references to Image Checksum.  From my understanding, one of the functions calls "LdrVerifyImageMatchesChecksum" which is at 7C93CFE4.  This may be where the checksum is calculated.


This is inside the ntdll.dll. There cant be a checksum calculation, because this is a Windows library. The checksum calculation must be inside the code of ZENVisionM_30GB_PCFW_L21_1_61_01.exe. The Windows DLLs you mostly use for creating Messageboxes (user32.MessageBoxW for example) or something like that.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on April 26, 2007, 03:32:42 PM

So watch this:

http://www.bilder-speicher.de/07042521261533.vollbild.html

Seems to be a lot of Cryptoshit inside ;)

I got this:
Code: [Select]
ADLER32 :: 0001609C :: 0041609C
The reference is above.
Adler32 checksum (unsigned 32-bit integer, BASE value); used by ZLIB compression library
ADLER32 :: 00016171 :: 00416171
The reference is above.
Adler32 checksum (unsigned 32-bit integer, BASE value); used by ZLIB compression library
CRC32 :: 0004F700 :: 0044F700
Referenced at 004162CF
Referenced at 0041631E
Referenced at 00416364
Referenced at 004163A6
Referenced at 004163E6
Referenced at 00416425
Referenced at 0041646A
Referenced at 004164AF
Referenced at 004164EF
Referenced at 00416544
Referenced at 00416570
CRC32 precomputed table for byte transform
DES [long] :: 00051D90 :: 00451D90
The reference is above.
DES: transformation nibbles
ECC: DRM (Microsoft), prime modulus :: 00051AB4 :: 00451AB4
Referenced at 0041972B
Microsoft elliptic curve, prime modulus of DRM curve
MD4 :: 00027663 :: 00427663
The reference is above.
MD4 transform & init constants (also used in SHA, RIPEMD, partly in CAST)
MD5 :: 0002586D :: 0042586D
The reference is above.
MD5 transform (\"compress\") constants
SHA1 [Compress] :: 0002326A :: 0042326A
The reference is above.
SHA1 additive constants (also used in SHA, SEAL, partly in RIPEMD)
SHA1 [Compress] :: 00023DBF :: 00423DBF
The reference is above.
SHA1 additive constants (also used in SHA, SEAL, partly in RIPEMD)
ZLIB deflate [word] :: 0004F600 :: 0044F600
Referenced at 00415D0C
ZLIB deflate compression algorithm - literal code lengths, used to build the trees
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on April 30, 2007, 04:23:41 AM
Some functions I've found in the .exe (named them myself):

FirmwareChk at 00413E10 (big function, has a lot of checks of nk.bin in it)
FORMAT_FIRMWARE at 00417A30 (I suppose here ZVM's firmware is erased)
FIRMWARE_DOWNLOAD at 00417CE0 (and here it is uploaded?)
CheckFormatSupport() at 00417FB0 (name was found in the strings)
ChkSumInit at 004229B0 (has something to do with the CheckSum; I strongly believe it is SHA1 or RIPEMD160) --> this one uses a lot of SHA1 constants (http://www.patentstorm.us/patents/5623545-description.html), so I believe the SHA1 hash is generated here

(SetRegSeed at 00424275)
(CreateRegRNGKey at 004242B8)
-> these are from minor importance
Title: Re: Creative Zen Vision:M
Post by: Couch on May 06, 2007, 08:42:05 PM
After every firmware update the hash of the firmware image must change, correct?.  So how does the firmware on chip inside the player recognize the changed hash?

I'm thinking the firmware updater software may tell the firmware on chip what the new hash is.  [if so we can just patch the update software with the chksum of hacked image?]

This is just a hypothesis without any disassembly so take it with a grain of salt.
Title: Re: Creative Zen Vision:M
Post by: saratoga on May 06, 2007, 08:50:39 PM

After every firmware update the hash of the firmware image must change, correct?.  So how does the firmware on chip inside the player recognize the changed hash?


The hash is stored in firmware update and checked when you do the update.


I'm thinking the firmware updater software may tell the firmware on chip what the new hash is.  [if so we can just patch the update software with the chksum of hacked image?]


"Just" doing that is what the last 8 pages of this thread have discussed.  If you're interested, you might want to read the thread.
Title: Re: Creative Zen Vision:M
Post by: Couch on May 06, 2007, 11:27:47 PM


After every firmware update the hash of the firmware image must change, correct?.  So how does the firmware on chip inside the player recognize the changed hash?


The hash is stored in firmware update and checked when you do the update.


I'm thinking the firmware updater software may tell the firmware on chip what the new hash is.  [if so we can just patch the update software with the chksum of hacked image?]


"Just" doing that is what the last 8 pages of this thread have discussed.  If you're interested, you might want to read the thread.

I apologize for my ignorance.  I only skimmed through a few of the last pages and just felt like presenting my idea.
Title: Re: Creative Zen Vision:M
Post by: saratoga on May 07, 2007, 01:29:08 AM
I understand that this thread has become somewhat bloated and difficult to find information in.  However, i'm somewhat hesitant to edit it too heavily for fear of deleting relevant information.  Unfortunately, that means people are going to have to dig to find stuff.  It also means I'll probably be deleting offtopic posts without warning.
Title: Re: Creative Zen Vision:M
Post by: iSE on May 07, 2007, 10:04:59 AM
What about updating the wiki? Keeping all the discussed ideas there so people can first check that?
Title: Re: Creative Zen Vision:M
Post by: Sonic on May 13, 2007, 04:12:58 PM

What about updating the wiki? Keeping all the discussed ideas there so people can first check that?

I like that idea, 'cause it's a drag to have to sift through the entire thread.
Title: Re: Creative Zen Vision:M
Post by: TheBlackCat on May 19, 2007, 11:02:39 AM

Some functions I've found in the .exe (named them myself):

FirmwareChk at 00413E10 (big function, has a lot of checks of nk.bin in it)
...
ChkSumInit at 004229B0 (has something to do with the CheckSum; I strongly believe it is SHA1 or RIPEMD160) --> this one uses a lot of SHA1 constants (http://www.patentstorm.us/patents/5623545-description.html), so I believe the SHA1 hash is generated here



Can you post the text of these, please?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on May 20, 2007, 07:38:56 AM

Can you post the text of these, please?

If you mean the disassembled versions of them, yes:
http://paste-it.net/pf649f3
http://paste-it.net/z5e1fd0
Title: Re: Creative Zen Vision:M
Post by: jhulst on May 22, 2007, 12:01:04 AM


What about updating the wiki? Keeping all the discussed ideas there so people can first check that?

I like that idea, 'cause it's a drag to have to sift through the entire thread.


Go ahead, it's a wiki, anyone can edit it.
Title: Re: Creative Zen Vision:M
Post by: EXCiD3 on May 25, 2007, 08:30:16 PM
Ok, I just wanted to let you guys know, over at the Nomadness forums, all the work done for the Series 3 devices, such as the Xtra (which i currently own, soon to have a ZVM or ZVW ;) can probably help us work with the ZVM. We have been able to do pretty much about the same as you guys with Series 3 hacking, with the exception of changing text on the firmware. We have gotten a couple of guys to dump the firmware (first 8 megs of the hd) and have modified the text and written it back to the drive. Apparently, the Series 3 devices do NOT have a checksum like the ZVM.

Much of the progress you guys have been making can EASILY be ported to the Series 3 devices. They are using the TMS320 processor also but it is a different variant (DA25x i think). Taken from wikipedia: DA25x is an ARM processor and a C55x core. It has som on-chip peripherals like a USB slave controller and security features. Documentation of this chip is only available after signing a Texas Instruments NDA. These variants are used exclusively in the Creative Zen and Dell Digital Jukebox MP3 players, as the primary CPU and signal processor for all processing of MP3 data streams.

Keep up the good work guys, I am going to begin hacking my Zen Xtra even though much of the progress made was dropped back in 2005 and I still don't quite have the money to shell out for another player.
Title: Re: Creative Zen Vision:M
Post by: jermey on May 28, 2007, 12:24:24 PM
im noob but this is little bit stupid and you should know something like this exists http://imajr.com/198300734_3_78515
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on May 29, 2007, 01:50:52 PM

im noob but this is little bit stupid and you should know something like this exists http://imajr.com/198300734_3_78515

Yes, we know about the recovery mode :)
It's located in the flash memory; and it's upgradeable, as the FRESC file in the firmware is this one. (FRESC=F(?) RESCue mode)
Title: Re: Creative Zen Vision:M
Post by: Llorean on May 29, 2007, 04:16:15 PM
F is probalby "Firmware" (not that it matters too much).
Title: Re: Creative Zen Vision:M
Post by: aaronwi on June 05, 2007, 12:51:34 PM
so has anyone hooked the hard drive up to the computer and read its contents yet?
would it be possible, if the firmware sits on the drive, to just overwrite it with modified firmware, or do one of the chips verify it?
Title: Re: Creative Zen Vision:M
Post by: Couch on June 05, 2007, 07:51:47 PM

so has anyone hooked the hard drive up to the computer and read its contents yet?
would it be possible, if the firmware sits on the drive, to just overwrite it with modified firmware, or do one of the chips verify it?

I believe the bootloader does sha1 checksums on the firmware.
Title: Re: Creative Zen Vision:M
Post by: Sonic on June 06, 2007, 11:08:18 PM
So, could we just install our firmware directly to the 32MB flash memory, so that there is no need to mess with trying to figure out the hash, since this seems to be the only roadblock(or at least the biggest one)? I'm just a noob at this, so it's just a suggestion, but 32 megs sounds like plenty of space to me.
Title: Re: Creative Zen Vision:M
Post by: Sonic on June 07, 2007, 11:54:08 AM
Another question: has the firmware (excluding the hash) actually been programmed, or is everything waiting on figuring out the hash?
Title: Re: Creative Zen Vision:M
Post by: EXCiD3 on June 07, 2007, 01:37:46 PM

So, could we just install our firmware directly to the 32MB flash memory, so that there is no need to mess with trying to figure out the hash, since this seems to be the only roadblock(or at least the biggest one)?


The problem is that we dont currently know how to write code that the processor can understand, we need the firmware reverse engineered or documentation on how to do it for us to be able to port rockbox to it.

BTW

I just email Creative contacting them whether we could get information on the hardware for the Zen Xtra and here is what i received:

Quote

My email:

On behalf of the Rockbox Community, I would like to know if Creative would consider releasing information on older mp3 players such as the Zen Xtra. If you released information to our community and supported our project, Creative would be seen as one of the best open-source friendly companies. No one would complain about functionality as anyone could add their own ideas to the firmware. Any support would be greatly appreciated. Sincerely, Chris Oliver and the Rockbox Community


Creative's Reply:

Dear Customer,
I'll forward the request.

Be aware that in most cases, Creative is under NDA with parts used in the device, and can not release related information .

But I will forward your email request.
If you still require assistance, please reply to this email with any previous correspondence to ensure the quickest and most accurate service.
Best Regards ,
Phillip (Developer Relations)
Technical Support
Creative Labs Americas



Title: Re: Creative Zen Vision:M
Post by: saratoga on June 07, 2007, 02:07:51 PM
I haven't bothered to count, but theres someone emailing Creative asking for info every month or so.  From now on don't bother posting about it unless they give you info.

Also, instead of posting "HOW ABOUT WE DO XXXXX", just try it yourself, and post what the results are.  We don't need another 4 pages of people speculating about a port from people who have no intention of actually contributing to one.
Title: Re: Creative Zen Vision:M
Post by: aaronwi on June 07, 2007, 09:53:37 PM
Tomorrow I'm ordering a 1.8 to 3.5 IDE converter so we can see whats on the hard drive

I attached Microsoft's Visual Studio debugger to the 1.61.01 upgrader
I included the log in this post

It seems odd, it looks like it loaded some Nero and other application dlls.

But what looks important is...
'ZENVisionM_30GB_PCFW_L21_1_61_01.exe': Loaded 'C:\CtJbFW\cttemp\Jboxcrl.crl',
'C:\WINDOWS\system32\xpsp2res.dll',
'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\comctl32.dll',
'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.2600.2180_x-ww_522f9f82\GdiPlus.dll',
'C:\WINDOWS\system32\msscp.dll',
'C:\WINDOWS\system32\winhttp.dll',
'C:\WINDOWS\system32\wininet.dll',
'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.163_x-ww_681e29fb\msvcr80.dll',

hope this helps somehow

[attachment deleted by admin for age]
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on June 10, 2007, 05:35:59 AM

...
'ZENVisionM_30GB_PCFW_L21_1_61_01.exe': Loaded 'C:\CtJbFW\cttemp\Jboxcrl.crl',
...

So could it be that some code is located in Jboxcrl.crl ? Cause I think no-one has looked into it, as it seemed to be non-used..
Title: Re: Creative Zen Vision:M
Post by: saratoga on June 10, 2007, 11:24:30 AM
toffe82 thought that file was some kind of loader, some people on google have various ideas.

I disassembled it, and its win32 dll (freeware of IDA works great).  Theres a lot of utility functions in there, malloc, string.h stuff, etc.  Also a dozen or so functions IDA doesn't recognize.
Title: Re: Creative Zen Vision:M
Post by: aaronwi on June 10, 2007, 11:26:52 AM
Yes code is located in that, It looks like it might check the current Zen firmware, if anything, it contains a bunch of possible error messages, here are really the readable chunks, formatted for easiest read.
I notice hex code that shows up twice, I wonder if its a checksum or encryption key? in between each group of 4 digits was 4 0s

fc 56  0e 57  1c 57  2a 57  3e 57  52 57  68 57  76 57  82 57  8c 57  9c 57  aa 57  ba 57  cc 57  dc 57  ea 57  
fc 57  14 58  2a 58  44 58  5e 58  74 58  8c 58  a6 58  ba 58  d4 58  e4 58  f2 58  00 59  0e 59  1a 59  26 59  42 59  5a 59  72 59  7e 59  8a 59  94 59  a0 59  b0 59  be 59  d0 59  e0 59  ec 59  02 5a  12 5a  22 5a  34 5a   46 5a  5e 5a


[attachment deleted by admin for age]
Title: Re: Creative Zen Vision:M
Post by: wantondstrction on June 16, 2007, 06:13:12 AM
I know it's hardly a useful statement at this point, but if anyone needs a guinea pig I'd be more than happy to help out with that later. I've got a ZenVM 30GB.

I'm not exactly skilled, nor trained for that matter. I fooled around a bit with the MTP porting kit from microsoft. I did a firmware upgrade and an album transfer while running the WPD monitor. I attatched a text readout of what it said.

I'm still figuring out how to use the direct MTP software supplied with the kit  :-\

It does recognize the following in MtpMon:
"Creative Zen Vision:M" "Zen Vision:M" "Flashdrive303B" "Flash Reader"

Again, I'm not particularly skilled, but this seemed like it had some promising pointers to it. Even if it only helps us figure out how to get past the checksum.

[attachment deleted by admin for age]
Title: Re: Creative Zen Vision:M
Post by: wantondstrction on June 16, 2007, 06:58:37 AM
LOL turns out that was the simplified version. (Told ya I wasn't very skilled)

I have two more text files for you all on what exactly went into the firmware upgrade. One is just what happened when I started the upgrade program. The second is what actually happened during, and a little after the reboot. The WPDmon seems useful, then again, I have little clue what I'm doing  :P

I'll post just starting in this comment, and then I'll post the full process in another. (Attatchment size limit)

[attachment deleted by admin for age]
Title: Re: Creative Zen Vision:M
Post by: wantondstrction on June 16, 2007, 07:06:28 AM
here's the full shabang. I had to rar it, it was huge. Well...huge for a text file...when you're only allowed a 128k file

EDIT: Is there any way to possibly use the WinCE emulator to run the nk.bin? I've made a half-assed attempt myself and got the following error

"The internal signature is missing or the section lengths or checksums are incorrect."

Could've been my really half-assed attempt that caused the error, but what are the odds that nk.bin is doing the checksum?

EDIT, again: I answered my question
Title: Re: Creative Zen Vision:M
Post by: justin2net on June 17, 2007, 04:43:36 PM
the gigabeat s30 also has a nk.bin, and its been labeled as its kernel.
RSA signature encoding a SHA1 hash (nk.bin - eboot.bin - recovery.bin), quoted from the s30 wiki.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on June 18, 2007, 04:37:00 AM

here's the full shabang. I had to rar it, it was huge. Well...huge for a text file...when you're only allowed a 128k file

Could you reupload the text file cause WinRAR says it's a corrupt archive (maybe rapidshare.com or verzend.be ?)
Title: Re: Creative Zen Vision:M
Post by: wantondstrction on June 18, 2007, 11:27:50 AM


here's the full shabang. I had to rar it, it was huge. Well...huge for a text file...when you're only allowed a 128k file

Could you reupload the text file cause WinRAR says it's a corrupt archive (maybe rapidshare.com or verzend.be ?)


Sorry about that. Here's the rapidshare link

http://rapidshare.com/files/37954246/FULLfirmwareupgrade.txt.html
Title: Re: Creative Zen Vision:M
Post by: disturbedsaint on June 21, 2007, 11:42:00 AM

Tomorrow I'm ordering a 1.8 to 3.5 IDE converter so we can see whats on the hard drive

Did you already buy a converter and have you already connected it?
Title: Re: Creative Zen Vision:M
Post by: Falafel on June 21, 2007, 04:47:54 PM
Posted by Aaronwi on Epizenter forum:
Quote
Later today, I'm going to try to make another call, the adapter I'm getting was from ebay, but its the wrong kind, it was 1.8" to 3.5" IDE (~$5 USD), where as now after I opened up the zen, it is a ZIF connection, those adapters (ZIF to 2.5" IDE) appear to be ~$40 USD

So...if you do have an IDE connecting hard drive, I could mail you my converter for a reasonable price.


We haven't heard from him yet, but I suppose he doesn't have an adapter he can actually use..
Title: Re: Creative Zen Vision:M
Post by: aaronwi on June 21, 2007, 10:02:38 PM
sorry, thought I stated above, but, I have a zif hard drive, and the connector I got is for IDE, when I have time, I'll try soldering a cable to an ide connector to read the hard drive,
as for contacting Creative, that site I was using for free out-of-country calls limits calls to only 2 or 3 minutes, not even enough time to get forwarded twice
Title: Re: Creative Zen Vision:M
Post by: wesmo on June 23, 2007, 04:02:43 AM
How similiar is the firmware of the Zen Vision: M to the NJB3 series - looking at the recovery mode menu of both (Zen Xtra (MTP) and Vision:M) are the same.  I suspect that the vision m uses a more updated/configurable firmware. More infoe about the NJB3 series is can be found on the wiki http://www.rockbox.org/twiki/bin/view/Main/CreativeZenTouch (Click on the NJB3 firmware)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on June 23, 2007, 08:53:14 AM

How similiar is the firmware of the Zen Vision: M to the NJB3 series - looking at the recovery mode menu of both (Zen Xtra (MTP) and Vision:M) are the same.  I suspect that the vision m uses a more updated/configurable firmware. More infoe about the NJB3 series is can be found on the wiki http://www.rockbox.org/twiki/bin/view/Main/CreativeZenTouch (Click on the NJB3 firmware)

Very similiar, its almost the same; except for the fact that there aren't any dictionaries in ZVM and the font files are TTF instead of NFT.
Both firmwares have a CINF header, an encoded part (CENC named in the NJB3, ©TL named in the ZVM), the same firmware structure, ...
Title: Re: Creative Zen Vision:M
Post by: wesmo on June 24, 2007, 06:05:50 AM
Doesn't that mean njb3 devices would be able to use a derivative of the zen vision m rockbox fw? I'm interested in contacting anyone interested in working on a port to the njb3 - working on both ports at the same time should be easier. I've put more up on the zen touch wiki page related to the ti tms320.

Title: Re: Creative Zen Vision:M
Post by: mitch04 on June 25, 2007, 06:11:31 PM
hey theres a new firmware for creative zen vision m you might be able to crack it i dunno. its version ZENVisionM_30GB_PCFW_L21_1_62_02
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on June 26, 2007, 05:01:50 AM

Sorry about that. Here's the rapidshare link

http://rapidshare.com/files/37954246/FULLfirmwareupgrade.txt.html


Hi,

the beginning of the file is clipped off, do you still have that or did you delete it ? Cause it is kinda important and I wanna try to make a proggie that imitates the WPD requests
Title: Re: Creative Zen Vision:M
Post by: metamorph8 on June 28, 2007, 08:03:01 AM
Sorry guys, but i didn't read through the whole thread. I'll delete this post if it's superfluous.

did anyone want a readout of the DeviceInfo.xml file?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on June 28, 2007, 08:12:25 AM

Sorry guys, but i didn't read through the whole thread. I'll delete this post if it's superfluous.

did anyone want a readout of the DeviceInfo.xml file?

No. You can get this file from your ZVM and it is in the firmware; so we already got this one :)
Title: Re: Creative Zen Vision:M
Post by: wantondstrction on June 29, 2007, 12:23:53 AM


Sorry about that. Here's the rapidshare link

http://rapidshare.com/files/37954246/FULLfirmwareupgrade.txt.html


Hi,

the beginning of the file is clipped off, do you still have that or did you delete it ? Cause it is kinda important and I wanna try to make a proggie that imitates the WPD requests


That's the only copy I have of the firmware upgrade readout, but I can do another one if you like.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on June 29, 2007, 08:02:02 AM

That's the only copy I have of the firmware upgrade readout, but I can do another one if you like.


That would be nice :)
Especially the beginning of the process would be of some importance, but if you could do a full readout (and maybe rar/zip it), that would be great!
Title: Re: Creative Zen Vision:M
Post by: wantondstrction on June 30, 2007, 01:42:27 AM
Well I finally managed to fail a firmware upgrade. It wasn't nearly as devastating as you would think. Interesting enough, after failing the firmware upgrade, it would no longer allow an official upgrade. It would always fail and never give a reason or an error of any sort.

Another interesting point, if you go through the reload firmware process. If you go through windows explorer, it reads the player as a 50mb device with 50mb free. I found this kind of odd.

I managed to figure out how to use the html output function on wpdmon (more like where to find and copy and paste the automatic output into html) Here's a "reload firmware" version of the monitor output.

http://rapidshare.com/files/40174563/WpdMonreloadfirmware.htm.html

PS sorry it's taken me a while to get back to you, I've been having eye problems keeping me from using the computer.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on June 30, 2007, 08:35:10 AM

Well I finally managed to fail a firmware upgrade. It wasn't nearly as devastating as you would think. Interesting enough, after failing the firmware upgrade, it would no longer allow an official upgrade. It would always fail and never give a reason or an error of any sort.

Another interesting point, if you go through the reload firmware process. If you go through windows explorer, it reads the player as a 50mb device with 50mb free. I found this kind of odd.

Interesting...
Quote

PS sorry it's taken me a while to get back to you, I've been having eye problems keeping me from using the computer.

Not a problem. I hope you're back allright :)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 01, 2007, 03:12:32 PM
This is rather interesting:
Code: [Select]
Data (from device, 122 bytes) - StorageInfo:
  Storage type      = Fixed RAM (0x3)
  File system type  = Generic Hierarchical (0x2)
  Access capability = Read-Write (0x0)
  Max capacity      = 52428800
  Free space (byte) = 52428800
  Free space (objs) = 4294967295
  Storage desc      = Storage Media

excerpt from WpdMonreloadfirmware.htm


The max capacity indicates 50MiB(exactly), the storage type is Fixed RAM; what could this mean?
Could there be some special partition on the HDD which is 50MiB which hides the OS?

And maybe if the firmware updater can access it, we could too?

edit: made the page a little bit shorter :)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 01, 2007, 03:32:46 PM
I think I get the update progress:
Code: [Select]
 Manufacturer      = Creative Technology Ltd
  Model             = Creative Zen Vision:M
  Device Version    = 1.61.01_0.00.23

Code: [Select]
 Storage type      = Fixed RAM (0x3)
  File system type  = Generic Hierarchical (0x2)
  Access capability = Read-Write (0x0)
  Max capacity      = 52428800
  Free space (byte) = 52428800
  Free space (objs) = 4294967295
  Storage desc      = Storage Media

Code: [Select]
WPD_PROPERTY_OBJECT_MANAGEMENT_CREATION_PROPERTIES           = [VT_UNKNOWN ] IPortableDeviceValues (10 elements)
WPD_OBJECT_PARENT_ID                                         = [VT_LPWSTR  ] s10001
WPD_OBJECT_NAME                                              = [VT_LPWSTR  ] nk.bin
WPD_OBJECT_ORIGINAL_FILE_NAME                                = [VT_LPWSTR  ] nk.bin
WPD_OBJECT_CONTENT_TYPE                                      = [VT_CLSID   ] WPD_CONTENT_TYPE_UNSPECIFIED
WPD_OBJECT_ISHIDDEN                                          = [VT_BOOL    ] FALSE
WPD_OBJECT_ISSYSTEM                                          = [VT_BOOL    ] FALSE
WPD_OBJECT_CAN_DELETE                                        = [VT_BOOL    ] TRUE
WPD_OBJECT_FORMAT                                            = [VT_CLSID   ] {B8020000-AE6C-4804-98BA-C57B46965FE7}
WPD_OBJECT_SIZE                                              = [VT_UI8     ] 0x14C23D0 (Decimal: 21767120)
WPD_API_OPTION_USE_CLEAR_DATA_STREAM                         = [VT_BOOL    ] TRUE

Code: [Select]
 Format code       = UndefinedFirmware (0xb802)
  Protection status = None (0x0000)
  Compressed size   = 21767120
  File name         = nk.bin

Code: [Select]
 Status Length = 4
  Code          = Device Busy (0x2019)

Code: [Select]
Response: OK (0x2001)
  TransactionId: 7



This is kinda the process of doing a firmware update according to WpdMonreloadfirmware.htm and my interpretation;
could someone verify/criticize this?
What do you guys think?
Title: Re: Creative Zen Vision:M
Post by: wantondstrction on July 01, 2007, 05:31:05 PM
My best guess would be that once it deletes the firmware it allows direct access to the flash storage (or more likely a hidden partition on the HDD) for reloading the firmware. I think there may be a huge opening here for us.

(which in case anyone hasn't actually done the reload firmware process, it does clearly state on the ZVM that the firmware has been deleted before you even dock the device)

Now my question, is this 50mb the flash memory or is it a hidden partition on the HDD? 50mb seems to be a decent amount of storage space for firmware, wouldn't you say?

I wonder if it would be as easy as copying a ported version of the rockbox firmware to this 50mb storage space. Of course, in order to do that we would probably have to turn rockbox itself into x86 code and use copies of the drivers from the OEM firmware. (Which of course OEM firmware dissection has gone slowly)

I'm still learning, but if any of my questions/theories seem far fetched, please lemme know.

BTW Creative released a new firmware version on June 25th

http://us.creative.com/support/downloads/download2.asp?MainCategory=213&Product=16002&dlcentric=10113&Product_Name=ZEN+Vision%3AM+30GB&filetype=4&OSName=Windows+XP
Title: Re: Creative Zen Vision:M
Post by: samsharp99 on July 01, 2007, 07:53:49 PM
Question: is there a way to transfer whatever file I want into the 50mb storage space after deleting the firmware?

What I am trying to do is put my slightly modified nk.bin (changes a character string in the english localisation) into that 50mb space directly instead of using the update.exe to see if that causes it to load my firmware. We already know from mcuelenaere on epizenter that the nk.bin file is copied directly (raw) from the exe to the zen, maybe this is where it puts it, I was hoping If I can find a way to put the nk.bin file there myself I might be able to make some headway?

Hello everyone by the way! I have a Zen 60Gb and am very interested in helping this project wherever possible, read through this thread and the epizenter one, want to help out with my limited knowledge.
Title: Re: Creative Zen Vision:M
Post by: wantondstrction on July 01, 2007, 10:43:48 PM

Question: is there a way to transfer whatever file I want into the 50mb storage space after deleting the firmware?

What I am trying to do is put my slightly modified nk.bin (changes a character string in the english localisation) into that 50mb space directly instead of using the update.exe to see if that causes it to load my firmware. We already know from mcuelenaere on epizenter that the nk.bin file is copied directly (raw) from the exe to the zen, maybe this is where it puts it, I was hoping If I can find a way to put the nk.bin file there myself I might be able to make some headway?

Hello everyone by the way! I have a Zen 60Gb and am very interested in helping this project wherever possible, read through this thread and the epizenter one, want to help out with my limited knowledge.


I personally am not sure yet. It clearly exposes the 50mb in windows explorer. Not sure entirely what this means but it seems like an awful big coincidence that it would show itself as a 50mb storage space during that period. I'm also not sure that this defeats any sort of checksum routine. I'm just thinking that this is an opening. In other words not necessarily an unlocked door, but may have found the door itself.

EDIT: Well I tried to straight up copy the nk.bin file over to the 50mb and it gave me the generic error message of this player does not support this kind of file. I even tried renaming it to another extension to just get it on there and it was still wise to it.

Also, the nk.bin from the new firmware revision is 616 bytes larger than the old one.
Title: Re: Creative Zen Vision:M
Post by: samsharp99 on July 02, 2007, 04:35:27 AM
yeah, that's what I was trying to do. It did also format my player's drive so I dont suggest doing it unless you have everything backed up.

It seems weird that it would show up as a storage volume but to make it impossible to transfer any files.

Does anyone have the zen vision m's own software installed, maybe the creative software for transferring files will allow it?

The only other thought I had was whether or not it is possible to replicate the USB transfer (since that makes it possible to transfer the file to this volume)?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 02, 2007, 09:13:17 AM
Maybe, if you directly copy the file using WinExplorer or whatever; the internal WPD/MTP commands/properties are different as from the ones used during the firmware updating progress.
As you can see in my earlier post, I included some excerpts from the WPDMon HTML file in which there are some details of the creation of the nk.bin file, it could be that this exact command with exactly the same properties has to be executed in order to upload the nk.bin file.
I'll take a look at the WPD SDK (if there exists one) and try to program a little app for uploading the (altered) file.

But still, it appears that the checksum is checked on the ZVM itself, so we aren't any closer as of the beginning..
Title: Re: Creative Zen Vision:M
Post by: samsharp99 on July 02, 2007, 10:52:37 AM
No you can't I tried that but windows explorer (under vista) won't allow it, do we know what the file-system is?

Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 02, 2007, 11:04:45 AM

No you can't I tried that but windows explorer (under vista) won't allow it, do we know what the file-system is?

MTP serves it as Generic Hierarchical (0x2), but what the underlying FS is nobody knows atm (excluding Creative);
we should have a HDD-dump to know this.
Title: Re: Creative Zen Vision:M
Post by: samsharp99 on July 02, 2007, 11:46:26 AM
Surely the vista drivers for it know the file system, as I can copy and paste my music onto the device hard disk with no problem using just windows explorer? Or is this again controlled by the firmware?
Title: Re: Creative Zen Vision:M
Post by: saratoga on July 02, 2007, 01:05:43 PM

Surely the vista drivers for it know the file system, as I can copy and paste my music onto the device hard disk with no problem using just windows explorer? Or is this again controlled by the firmware?


I don't think Vista can see the filesystem of an MTP device.  I think it just asks the device for a list of files, asks it to read a file, etc.  Its more like FTP then mounting a disk AFAIK.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 02, 2007, 02:06:31 PM


Surely the vista drivers for it know the file system, as I can copy and paste my music onto the device hard disk with no problem using just windows explorer? Or is this again controlled by the firmware?


I don't think Vista can see the filesystem of an MTP device.  I think it just asks the device for a list of files, asks it to read a file, etc.  Its more like FTP then mounting a disk AFAIK.


Indeed, saratoga is right. Windows uses MTP/WPD to communicate with the ZVM, and this one accesses his HDD directly so it can decide which it want to be visible to the "outside".
Title: Re: Creative Zen Vision:M
Post by: samsharp99 on July 03, 2007, 04:26:59 AM
I think that's as far as my contribution can go :S

I dont really know if there's anything more I can help with :(
Title: Re: Creative Zen Vision:M
Post by: aaronwi on July 03, 2007, 10:38:15 PM
I did a firmware "update" from 1.61.01 to 1.61.01 on my ZVM while running "Device Monitoring Studio 5.1",  and got this output, I don't believe anyone else used this program before; it gives a lot of info,  files included are the packet view, and the URB data, in basic format. (the program says URB data is the raw usb packets decoded)
Here's the data

http://www.fileden.com/files/2007/7/3/1236670/urb%20basic%20and%20packet%20view.rar
contains the basic output from the URB data window, and the regular packet view data, both RARed..less then a megabyte

http://www.fileden.com/files/2007/7/3/1236670/URB%20view%20html%20format%20%20complete.rar
the full version of the URB data...about 191 MB, and RARed to 30 MB, (contains hex views of each packet)


Title: Re: Creative Zen Vision:M
Post by: aaronwi on July 04, 2007, 11:20:37 AM
more goodies!!!

I couldn't get much from WpdMon, so I decided to try MtpMon, and here is the output
http://www.fileden.com/files/2007/7/3/1236670/verbose%20output%201.61.01%20to%201.61.01.rtf
I labeled each part of the log with #'s



http://www.fileden.com/files/2007/7/3/1236670/WPDmon%201.61.01%20to%201.61.01.rtf
was all I got from WpdMon, anyone know why It wouldn't log the initial upload?

I have XP sp2 and WMP11, by the way


also, in the installer, is the firmware nk.bin compressed/encrypted or anything, or can I directly modify it,
or is it possible to modify nk.bin when its in the temp folder, I tried before, but I believe its just overwritten just before the update process.
Title: Re: Creative Zen Vision:M
Post by: samsharp99 on July 04, 2007, 05:46:07 PM
maybe if you were quick enough?!?! :P
Title: Re: Creative Zen Vision:M
Post by: wantondstrction on July 04, 2007, 11:00:09 PM

more goodies!!!

I couldn't get much from WpdMon, so I decided to try MtpMon, and here is the output
http://www.fileden.com/files/2007/7/3/1236670/verbose%20output%201.61.01%20to%201.61.01.rtf
I labeled each part of the log with #'s



http://www.fileden.com/files/2007/7/3/1236670/WPDmon%201.61.01%20to%201.61.01.rtf
was all I got from WpdMon, anyone know why It wouldn't log the initial upload?

I have XP sp2 and WMP11, by the way


also, in the installer, is the firmware nk.bin compressed/encrypted or anything, or can I directly modify it,
or is it possible to modify nk.bin when its in the temp folder, I tried before, but I believe its just overwritten just before the update process.


Did you make sure to turn on all the monitors in WPDmon? If not, try going to the Monitor tab in wpdmon.exe and turn all of them on. Also, if you delete wpdmon.htm that's in the exe folder, it'll give you an html readout that doesn't do stupid stuff like cut off parts. If you ever wanna clear it out, just delete it and it'll make a new one.
Title: Re: Creative Zen Vision:M
Post by: wantondstrction on July 05, 2007, 05:41:05 AM
I'm starting to get somewhere on transferring firmware.

To sum it up, I managed to use directmtp to transfer OFFICIAL firmware onto the device. I don't have an altered nk.bin. (Nor the skill to create one that is stable.) If someone would upload one they feel is stable I'll attempt to upload it to my player. I managed to get the sendobjectinfo and sendobject commands down fairly well. Once the firmware is transfered onto the ZVM it more or less takes it from there by itself.

If someone can manage to alter nk.bin to where it has some sort of noticeable difference. (maybe a different version number?) I would be greatly appreciative.

If anyone wants directmtp, let me know what OS you're using and windows media player version. It only comes in vista or xp format but is a pretty powerful tool.

Title: Re: Creative Zen Vision:M
Post by: samsharp99 on July 05, 2007, 06:34:15 AM
yes please, im using vista x64 if you wouldn't mind, I have an altered nk.bin for my 60gb zen. on WMP 11.
Title: Re: Creative Zen Vision:M
Post by: wantondstrction on July 05, 2007, 06:31:15 PM

yes please, im using vista x64 if you wouldn't mind, I have an altered nk.bin for my 60gb zen. on WMP 11.


Vista version. Fairly certain this will work with x64 edition. I'm using the vista version on 32 bit and can tell you it works.

http://rapidshare.com/files/41255138/DirectMTP_Vista.zip.html

Here's the Vista directions. XP is a little different...

1. Verify that target MTP device is installed, connected and turned on.

2. Make sure there are no scanners, cameras or web-cams connected to the PC aside from the target MTP device.

3. Replace the WPD MTP driver for the device with the test driver

3a. Access the Device Manager (type “Device Manager” in the Start menu)

3b. Right click on your MTP device in Device Manager and choose “Update Driver Software”

3c. Choose “Browse my computer for driver software”

3d. Enter the path of your DirectMTP directory and click Next.

3e. Please choose “Install this driver software anyway”

3f. Your device should be installed correctly.

4. Run "mtpinfup.exe" from an elevated command line to finish configuration for DirectMTP.

5. Start DirectMTP and click Open Device.

6. If device is opened successfully, you will be able to proceed with execution of MTP commands.  Results of operations are displayed in the right pane.

7. To return the device to normal operation, run "mtpinfup.exe post" from an elevated command line.  This will restore the original WPD MTP driver settings for that device.



Now for transferring firmware. This is what worked for me on the 30 gig, not sure if the commands are exactly the same on the 60, or even on somebody else's player. Anyway.

Open Device

Open Session (I just used Session ID 1)

Send Object Info

  Destination Storage ID = 0x10001 (65537)
  Destination Folder Handle = 0xFFFFFFFF (-1)
 
  Format code       = 0xb802 (UNDEFINEDFIRMWARE)
  Protection status = 0x0000 (No Protection)
  Compressed size   = (use the size of the nk.bin you're transferring)
  Thumbnail format  = 0x3000 (FORMATCODE_UNDEFINED)
  Thumbnail size    = 0
  Thumbnail width   = 0
  Thumbnail height  = 0
  Image width       = 0
  Image height      = 0
  Image bit depth   = 0
  Parent obj handle = 0x00000000
  Association type  = 0x0000 (not association)
  Association desc  = 0x0000 (unused)
  Sequence number   = 0
  File name         = nk.bin
  Capture date      = (leave blank)
  Modification date = (leave blank)
  Keywords          = (leave blank)

Click OK, wait for a positive response from your player

From there hit send object and select your nk.bin.


I would recommend using wpdmon to see what your 60GB zvm is transferring during an official firmware upgrade to see if it's using the same protocol for everything. Particularly, the format code. It SHOULD be fine, however I take no responsibility for your player bricking, burning your house down, or global warming. lol
Title: Re: Creative Zen Vision:M
Post by: saratoga on July 05, 2007, 07:04:47 PM

If someone can manage to alter nk.bin to where it has some sort of noticeable difference. (maybe a different version number?) I would be greatly appreciative.

If anyone wants directmtp, let me know what OS you're using and windows media player version. It only comes in vista or xp format but is a pretty powerful tool.




Can you just open the file, search for a string that you know is displays, and change a letter from lower to upper case or something equally simple?
Title: Re: Creative Zen Vision:M
Post by: samsharp99 on July 06, 2007, 06:44:48 AM
that's what im trying to do. changed some of the english language text :)

Quote
however I take no responsibility for your player bricking, burning your house down, or global warming. lol


hahahaha....we've been having some funny weather here recently *glares*

oh, and in case anyone wants to know how to edit their nk.bin to modify it, when you run the official firmware upgrader it saves the nk.bin to c:\CtJbFW\cttemp so you can copy it to your drive (it deletes it afterwards im pretty sure) you can then open it with a hex editor like 010 Editor, and if you scroll down the lines to about... 34:0A00h (for the 60gb firmware) you get the english language section.

will update this post if i am successful.

UPDATE: can't get wpdmon to log anything. ran the .cmd as administrator, connected my zen, ran wpdmon, started monitoring, nothing. am i missing something?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 06, 2007, 03:46:32 PM
nice nice

I would test it myself, but am having trouble my PC recognizing my ZVM :s

If you just change the checksum, nothing is changed in the firmware itself but you could see if the transfer would succeed with an altered checksum.

Here is such a file:
http://www.verzend.be/v/114342/ZENVisionM_30GB_PCFW_L21_1_62_02_nk_altered.rar.html
Title: Re: Creative Zen Vision:M
Post by: gitrdone300ex on July 06, 2007, 04:31:22 PM
Hey everybody I'm new to the forum but would love to have rockbox on my zen and will help in anyway i can.

Has anyone gotten DirectMTP.exe to run in vista x64? evertime I try it crashes. I got the test driver installed fine but I just get an error everytime I try to run DirectMTP.
Title: Re: Creative Zen Vision:M
Post by: samsharp99 on July 06, 2007, 04:46:23 PM
Not tried it yet as I need the wpdmon output before I try and do it as im using the 60gb zen so need to see if it's different.
Title: Re: Creative Zen Vision:M
Post by: aaronwi on July 06, 2007, 05:43:16 PM

Did you make sure to turn on all the monitors in WPDmon? If not, try going to the Monitor tab in wpdmon.exe and turn all of them on. Also, if you delete wpdmon.htm that's in the exe folder, it'll give you an html readout that doesn't do stupid stuff like cut off parts. If you ever wanna clear it out, just delete it and it'll make a new one.


Yes, I did all of that, and still nothing, only thing logged is the connection and disconnection of the usb to zvm cable





I would test it myself, but am having trouble my PC recognizing my ZVM :s


try http://www.fileden.com/files/2007/7/3/1236670/mtp%20driver%20fix.rar
Found it on another forum, fixed the problem with my zen not showing up/being usable
Title: Re: Creative Zen Vision:M
Post by: aaronwi on July 06, 2007, 10:20:50 PM
just curious, did anyone find my log dumps useful?

also, anyone know whats going on here?...
"  
Item 10 of 60:
    Object handle   = 0x65
    Property code   = PersistentUniqueObjectIdentifier (0xDC41)
    Data type       = UINT128 (0xA)
    Value           = Array (4 elements) = {0x65, 0x0, 0x0, 0x0}
"

I notice 0x65 is in a list of addresses I got from the MTPmon log
Other Items also show up using different addresses
And, an array of 4 elements? What can all of those be for?

"
Data (from device, 52 bytes) - 0x59 Unknown, 0x0 NotUsed, 0x65 Unknown, 0x0 NotUsed, 0x5d Unknown, 0x0 NotUsed, 0x61 Unknown, 0x0 NotUsed, 0x79 Unknown, 0x0 NotUsed, 0x69 Unknown, 0x0 NotUsed
"

Title: Re: Creative Zen Vision:M
Post by: Hitman2k7 on July 07, 2007, 10:04:56 AM

If you just change the checksum, nothing is changed in the firmware itself but you could see if the transfer would succeed with an altered checksum.


Can you tell me how i can change the checksum?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 07, 2007, 10:13:27 AM

Can you tell me how i can change the checksum?

The easy way: download http://www.verzend.be/v/114342/ZENVisionM_30GB_PCFW_L21_1_62_02_nk_altered.rar.html
(its checksum has been changed)

The DIY way: use a hex editor and go to the last 20 bytes: these contain the checksum, change them to whatever you want, it makes the checksum incorrect.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 07, 2007, 10:32:10 AM
Damnit, the player checks the checksum :(

First, I tried upping a modfied file, which gave me:
SendObject: Operation failed, response = MTP_RESPONSECODE_ACCESSDENIED

Then I upped the correct one, which gave me:
SendObject: sent 21767736 bytes, response = MTP_RESPONSECODE_OK

A small comment I noticed, my ZVM gave that responsecode pretty fast; so it must be computing the checksum while it is receiving the firmware, cause computing the SHA-1 checksum even on a 1,0Ghz comp takes 10 to 15sec ...

P.S.: XP users trying to use DirectMTP: http://www.verzend.be/v/6860021/DirectMTP.rar.html
Title: Re: Creative Zen Vision:M
Post by: Hitman2k7 on July 07, 2007, 10:52:39 AM
Right, checksum check is made by the player.
I modified the updater to transfer a different nk.bin than the one which comes with the updater.
It gives an Update failed error after transfering the file  :(
Title: Re: Creative Zen Vision:M
Post by: wantondstrction on July 07, 2007, 11:55:02 AM
Well, alas, I can't get an altered nk.bin onto the player by those means. I can still get the official nk.bins on there that way though. Every time I try I get an Access Denied error. I'm gonna keep plugging along.

I knew it was too good to be true, but it seemed positive when the official one worked.

I even tried formatting my player to limit the amount of objecthandles that popped up, but none of the objecthandles given matched firmware remotely.


At this point, I'll state some of the obvious.

1. The player itself does the checksum

2. The official firmware loader is relatively pointless. (It's more or less just a long command line to interact with the player doing the directMTP functions.)

3. Mcuelenaere, you're right. I tested that theory out by altering different parts of the code on a few different nk.bins and some failed noticeably quicker than others.

Has anyone tried removing the last 20 bytes of an nk.bin altogether?

Edit: Oddly, I managed to get an altered nk.bin onto the player. I had a program crash and it quit watching what file formats were being copied onto the player. It hasn't done anything and hasn't upgraded the firmware or done anything with it. It's just there. All I did was copy and paste during a huge transfer after a program crash. (reloading my music after formatting)

It's chilling next to devlogo.fil and so on. It's not that this means much of anything, but it's further than I've managed to get to date. I'm looking into isolating exactly what happened.

(I realize this doesn't help with the checksum)
Title: Re: Creative Zen Vision:M
Post by: Hitman2k7 on July 08, 2007, 04:03:51 AM
Well I also got an nk.bin on my players hd by changing the Formatcode to undefined. But the player doesn't do anything with it unless changing the formatcode to firmware but that's as far as i know not possible.

Quote
GetObjectInfo: received ObjectInfo:
  Format code       = MTP_FORMATCODE_UNDEFINED
  Protection status = MTP_PROTECTIONSTATUS_NONE
  Compressed size   = 21767736
  Thumbnail format  = MTP_FORMATCODE_NOTUSED
  Thumbnail size    = 0
  Thumbnail width   = 0
  Thumbnail height  = 0
  Image width       = 0
  Image height      = 0
  Image bit depth   = 0
  Parent obj handle = 0x0
  Association type  = MTP_ASSOCIATIONTYPE_UNDEFINED
  Association desc  = 0
  Sequence number   = 0
  File name         = nk.bin
  Capture date      =
  Modification date =
  Keywords          =


The red thing has to be 0xb802 (UNDEFINEDFIRMWARE) for the player recognizing it.
Title: Re: Creative Zen Vision:M
Post by: iSE on July 08, 2007, 04:18:52 AM

A small comment I noticed, my ZVM gave that responsecode pretty fast; so it must be computing the checksum while it is receiving the firmware, cause computing the SHA-1 checksum even on a 1,0Ghz comp takes 10 to 15sec ...


Just to check, are you sure that the player actually calculates the checksum, or just compares it with a static one? try altering the nk.bin but leaving the checksum the same. Does that fail? I know theres a 99.9% chance it will but it mite be worth eliminating as a step to discovering when the checksum is calculated by the player. (start, middle, during, end etc)
Title: Re: Creative Zen Vision:M
Post by: Hitman2k7 on July 08, 2007, 04:45:53 AM

try altering the nk.bin but leaving the checksum the same.

That's impossible. The checksum completely changes even if you change only 1 byte of the file.


But how does the player know if the file is an official one? I mean they all have different checksums and creative has no influence on them...
Title: Re: Creative Zen Vision:M
Post by: aegis on July 08, 2007, 05:13:30 AM


try altering the nk.bin but leaving the checksum the same.

That's impossible. The checksum completely changes even if you change only 1 byte of the file.


I think iSE knows it. :P
What he says is: are you sure the player actually calculates the checksum? Maybe it's only comparing some strings here and there? And if it calculates the checksum - on which stage is it done? Is it calculated for the whole code? etc. etc.


But how does the player know if the file is an official one? I mean they all have different checksums and creative has no influence on them...


Again: are you sure with your assumptions? :)
Certainly, the Creative must have the influence upon them - unless they stuff their code with a large pile of rubbish by design just to fit some arbitrary checksum - however I wouldn't bet it would really work.
So, if altering the code and putting the right checksum (again, are you sure? :) ) in the end does not work, it means for me there must be some duplicate of the checksum in the code. Maybe it's split on two or more strings, maybe it's *very simply* encrypted (like add 1 to a char, or so on), maybe it's something more sophisticated, some version code or whatever - I don't know - but there must be some way for the program to validate the update and say "sorry, it's not ours".
Title: Re: Creative Zen Vision:M
Post by: iSE on July 08, 2007, 05:22:39 AM
Agreed. There are a lot of assumptions flying around and a lot of progress has been made, however, specifics are needed and facts should be seperated from supposition.

What if we just run through what is known, what is assumed to be true, n what there is a vague suspicion of? This could then help to recap where everyone is up to and we can finally update the wiki lol.

mcuelenaere, im trying to make sense of this template for the 010 editor that I_e made on the epizenter forum. However, using the latest firmware: ZENVisionM_60GB_PCFW_L21_1_21_02e, I do not seem to be able to get the same results or locate the checksum in nk.bin. Does it only work with the 30GB version?

What I am hoping to try is to remove the NULL part containing the checksum and then calculate various hashes from the rest of it to determine which checksum the NULL block matches. Since I am assuming the checksum would not be calculated from the checksum itself. What if we get together a list of the different checksums, that mite help to calculate the algorithm?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 08, 2007, 05:46:08 AM

mcuelenaere, im trying to make sense of this template for the 010 editor that I_e made on the epizenter forum. However, using the latest firmware: ZENVisionM_60GB_PCFW_L21_1_21_02e, I do not seem to be able to get the same results or locate the checksum in nk.bin. Does it only work with the 30GB version?

What I am hoping to try is to remove the NULL part containing the checksum and then calculate various hashes from the rest of it to determine which checksum the NULL block matches. Since I am assuming the checksum would not be calculated from the checksum itself. What if we get together a list of the different checksums, that mite help to calculate the algorithm?

Maybe you could upload your nk.bin and I'll then see what I can do :) Normally, the structure applies to all currently known ZVM firmwares. And if you want to remove the NULL part, you can just remove the last 28 bytes('NULL'+size of the block+block itself).
I tried myself calculating the SHA-1 hash & RIPEMD160 of various parts of the firmware, but couldn't find a corresponding hash. Either Creative uses an altered version of SHA-1 or they use a self-made hash (doubt it) or I haven't found the right spot to calculate the hash :)

But what's a fact is that in the firmware update program, there is a SHA-1 (based) hash calculation routine. Maybe if someone who is familiar with X86/Win32 hacking could disassemble the functions? Or if some people who know ARM could disassemble the firmware itself? (although I think this is harder and less people exist who know ARM than people knowing X86 (especially Win32)..)
Title: Re: Creative Zen Vision:M
Post by: iSE on July 08, 2007, 06:24:25 AM
It may well be the case that Im just using 010 Editor incorrectly, I've never used it before but I do have some experience with checksums and assembly (which isnt ALL too dissimilar from ARM) so if I can first understand what you've discovered so far, hopefully i may be able to help.

You mention the update program uses a SHA-1 (based) hash calculation routine? What do you know about this? Wouldnt it be reasonable to test the same routine on the firmware itself?

Ideally, what we are after is the calculation algorithm correct? Hopefully we could try and create a keygen and we'd be sorted! lol

Here is my nk.bin: http://www.verzend.be/v/2461049/nk.bin.html
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 08, 2007, 06:26:07 AM
If you look at the structure of the firmware, you have something like this:
struct BLOCK FFIC,CIFF,0h,21767708
struct BLOCK block[0],CINF,8h,104
struct BLOCK block[1],DATA,70h,52396
struct BLOCK block[2],DATA,CD1Ch,553456
struct BLOCK block[3],©TL ,93F0Ch,2530680
struct BLOCK block[4],DATA,2FDC84h,518298
struct BLOCK block[5],DATA,37C51Eh,1533734
struct BLOCK block[6],DATA,4F2C44h,8234664
struct BLOCK block[7],DATA,CCD2ECh,8131192
struct BLOCK block[8],DATA,148E564h,141792
struct BLOCK block[9],DATA,14B0F44h,52446
struct BLOCK block[10],DATA,14BDC22h,11602
struct BLOCK block[11],DATA,14C0974h,390
struct BLOCK block[12],EXT0,14C0AFAh,6946
struct BLOCK block[13],NULL,14C261Ch,28

The first block (the CIFF block) is EXACTLY the size of the full firmware EXCEPT the NULL block (containing the checksum).
This can't be a coincidence, can it? I mean, this has to got to mean that the NULL block contains the checksum of the whole CIFF block.
The only problem is that nor the SHA-1 hash nor the RIPEMD160 hash is the same...
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 08, 2007, 06:32:04 AM

Here is my nk.bin: http://www.verzend.be/v/2461049/nk.bin.html

This one works perfectly with the template :) Are you using this one?
Code: [Select]
//--------------------------------------
//--- 010 Editor v2.0 Binary Template
//
// File: Creative firmware (nk.bin)-Parser
// Author: l_e
// Revision: 0.1
//--------------------------------------

typedef struct {
CHAR BlockID[4];
DWORD Size;
if (BlockID == "FNIC"){
UCHAR Desc[96];
} else if (BlockID == "LLUN" || BlockID == "FFIC"){
UCHAR Data[ Size ];
} else {
UCHAR Desc[32];
UCHAR Data[ Size - sizeof(Desc) ];
}
} BLOCK;
//--------------------------------------------

CHAR[] StrRev( CHAR s[] )
{
local int sz;
local int up;
local CHAR strng[sizeof(s)];

for (sz =sizeof(s)-1,up=0;upstrng[up] = s[sz];
}
return strng;
}


string ReadBLOCK( BLOCK &block )
{
return StrRev( block.BlockID );
}
//--------------------------------------------
local ulong id;
local ulong tmp;
local ulong ofs;

LittleEndian();
id = ReadUInt( FTell() );

if (id == 0x43494646){ // "CIFF"
BLOCK FFIC;
FSeek( 8 ); //Move back to first "real block", since CIFF-block includes most of the stuff
ofs = 8;
while ( !FEof() ){
FSeek( ofs );
BLOCK block;
FSeek( ofs+sizeof(block) );
ofs = FTell();
}
} else {
Warning ("Not valid CIFF-header. Exiting");
return -1;
}

//--------------------------------------
Title: Re: Creative Zen Vision:M
Post by: iSE on July 08, 2007, 06:38:20 AM
I was using a different version of this i think. In my template results window, i got 21 blocks which are all:

struct MSG1 MSG1Block[X]

X being in increments of 0-20.

trying the template you suggest gives me a syntax error on line 30...

[29] for (sz =sizeof(s)-1,up=0;upstrng[up] = s[sz];
[30] }
[31] return strng;

It is possible that not all of the NULL block is the checksum. I've seen in the past that buffers are included at the start or finish to fill out the checksum making the original unknown. If I can get access to the information you do, I'll try other checksums.

Would collecting all the different checksums from various people not help to narrow down the possible algorithm?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 08, 2007, 06:48:18 AM

I was using a different version of this i think. In my template results window, i got 21 blocks which are all:

struct MSG1 MSG1Block[X]

X being in increments of 0-20.

This one is for Hjukebox2.jrs, which is a block in nk.bin ; )
Quote
trying the template you suggest gives me a syntax error on line 30...

[29] for (sz =sizeof(s)-1,up=0;upstrng[up] = s[sz];
[30] }
[31] return strng;

Normally, this one should work; which version of 010 Editor are you using? Maybe try a fresh start and restart the app or so : )
Quote
It is possible that not all of the NULL block is the checksum. I've seen in the past that buffers are included at the start or finish to fill out the checksum making the original unknown. If I can get access to the information you do, I'll try other checksums.

Could be, I don't have a lot experience with hacking DAP's. But this way looks very believable to me, the structure looks perfect and so; but I could be wrong : )
Quote

Would collecting all the different checksums from various people not help to narrow down the possible algorithm?

I don't know if that could help, but maybe it can. Do you mean collecting all the checksums from the different versions of the firmware?
But I think hacking the firmware update program is going to be more productive ; )
Title: Re: Creative Zen Vision:M
Post by: TheBlackCat on July 08, 2007, 03:50:30 PM
I was wondering, is the MTP requirement built into the hardware or can it be changed if the firmware is replaced?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 08, 2007, 04:05:32 PM

I was wondering, is the MTP requirement built into the hardware or can it be changed if the firmware is replaced?

It is pure software; if the Rockbox USB stack is going to get into SVN & the ZVM target will get ported I don't think MTP will get supported anymore :)
Title: Re: Creative Zen Vision:M
Post by: LambdaCalculus on July 08, 2007, 07:12:56 PM
I was curious about something. If the MTP stack is in software on the ZVM, would this also apply to other Creative NOMAD/ZEN players? I have been trying to gather up info on the Dell Digital Jukebox to help start a port (the thread's at http://forums.rockbox.org/index.php?topic=11368.0).

At the risk of going a bit off topic to the ZVM, would any research done on this platform apply to nearly any NOMAD/ZEN platform? The Dell DJ is OEM'ed from Creative, uses MTP to transfer media, and is TMS320-based. So can this info be spread across the entire line?
Title: Re: Creative Zen Vision:M
Post by: saratoga on July 08, 2007, 07:19:33 PM

I was curious about something. If the MTP stack is in software on the ZVM, would this also apply to other Creative NOMAD/ZEN players? I have been trying to gather up info on the Dell Digital Jukebox to help start a port (the thread's at http://forums.rockbox.org/index.php?topic=11368.0).


I don't think hardware MTP devices exist.  Its just a protocol run on top of USB, theres no sense in making one.
Title: Re: Creative Zen Vision:M
Post by: Transience on July 11, 2007, 01:25:46 AM
Perhaps I'm not understanding this correctly, but isn't the code that checksums the new firmware file already on the player? Changing the part of the firmware that dictates what happens when the checksums don't match in the firmware being transfered won't help any.
If there's a way to run .bin files (an ARM emulator perhaps?) that might allow the firmware to be debugged, but without knowing the checksum algorithm, the only option is to access the firmware data on the ZVM, and modify it that way.
Do I understand this right, or am I just saying stupid things?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 11, 2007, 05:54:58 AM

Perhaps I'm not understanding this correctly, but isn't the code that checksums the new firmware file already on the player?

Yes
Quote
Changing the part of the firmware that dictates what happens when the checksums don't match in the firmware being transfered won't help any.

Well, actually it would help. But there are a few problems. : ) At first, we have to know which code this is. And then we have to upload the code back to the ZVM; which atm is only possible by directly editing the HDD.
Quote
If there's a way to run .bin files (an ARM emulator perhaps?) that might allow the firmware to be debugged, but without knowing the checksum algorithm, the only option is to access the firmware data on the ZVM, and modify it that way.

I don't really understand this sentence ; ) If we could get the firmware debugged (and disassembled), we would know (in ARM assembler) the checksum algorithm.
"... and modify it that way." => which way are you talking about? ; )
Quote
Do I understand this right, or am I just saying stupid things?

I think you understand it right : )
Title: Re: Creative Zen Vision:M
Post by: iSE on July 11, 2007, 09:17:11 AM
I've been able to get the ARM code for the nk.bin using EMU8086 emultator, but the firmware uploader is too big to load for some reason. If anyone knows of anythin that will disassemble a file n output the ARM code to a txt file to read through, that would be very benificial. Where would the algorithm be tho? Surely it will only be in the bootloader? Because creative will calculate it at their end n only on the player. There would be no need for the nk.bin nor the firmware updater program to calculate the checksum.

Since this is the case, would it be possible to modify some firmware to be uploaded directly to the HDD, which would output the algorithm? Long shot I know but might be worth a hefty effort if it works?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 11, 2007, 09:56:17 AM

I've been able to get the ARM code for the nk.bin using EMU8086 emultator, but the firmware uploader is too big to load for some reason. If anyone knows of anythin that will disassemble a file n output the ARM code to a txt file to read through, that would be very benificial. Where would the algorithm be tho? Surely it will only be in the bootloader? Because creative will calculate it at their end n only on the player. There would be no need for the nk.bin nor the firmware updater program to calculate the checksum.

Since this is the case, would it be possible to modify some firmware to be uploaded directly to the HDD, which would output the algorithm? Long shot I know but might be worth a hefty effort if it works?

I think the algorithm is surely used during the update progress and maybe during start-up; but it could be located anywhere... See it as a DLL, it could be loaded anytime (and used anytime), but where it is atm we don't know (flash or HDD or ...).

Isn't the algorithm (based on SHA-1) located in the updater program itself (so X86 code!) worth taking a look at? I have done it myself, but I am not that good at understanding assembler : )
Title: Re: Creative Zen Vision:M
Post by: iSE on July 11, 2007, 10:06:12 AM
Well sure, if you can post the code for it I'll take a look. But why would the checksum of the firmware ever need to be calculated unless verifying it to be real and when first inserting the checksum into the file?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 11, 2007, 10:16:47 AM

Well sure, if you can post the code for it I'll take a look. But why would the checksum of the firmware ever need to be calculated unless verifying it to be real and when first inserting the checksum into the file?

Indeed, it is very odd. But someone found some traces of a SHA-1 calculation and I investigated a (little bit) further and found some kind of SHA-1 (based) routine in the .exe (see some posts back, I've posted some code)

edit: it starts at page 12
Title: Re: Creative Zen Vision:M
Post by: saratoga on July 11, 2007, 10:18:16 AM

I've been able to get the ARM code for the nk.bin using EMU8086 emultator, but the firmware uploader is too big to load for some reason.


I posted the nkbin directly earlier in the thread.  You don't need to emulate anything, it saves it to the hard disk.


If anyone knows of anythin that will disassemble a file n output the ARM code to a txt file to read through, that would be very benificial.


Sure, use objdump (comes with the rockbox dev tools) or IDA Pro.  Check earlier in this thread, theres a lot of posts on it from around January or so.


Since this is the case, would it be possible to modify some firmware to be uploaded directly to the HDD, which would output the algorithm? Long shot I know but might be worth a hefty effort if it works?


You mean replacing their bootloader?  Without spec sheets, that would be very hard to do.
Title: Re: Creative Zen Vision:M
Post by: iSE on July 11, 2007, 10:56:28 AM
I used the emulator as its possible to view the ARM code of the nk.bin file itself. I will checkout objdump.

If, say, the firmware updater does indeed calculate the checksum of the nk.bin file and then upload it to the firmware, and the firmware is merely a series of commands designed to upload an inbuilt nk.bin file, can we not change the nk.bin file slightly, put it back into the firmware updater program, and then try that to upload it to the Zen?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 11, 2007, 11:08:03 AM

If, say, the firmware updater does indeed calculate the checksum of the nk.bin file and then upload it to the firmware, and the firmware is merely a series of commands designed to upload an inbuilt nk.bin file, can we not change the nk.bin file slightly, put it back into the firmware updater program, and then try that to upload it to the Zen?

You could try, if you know how : )
The firmware is compressed (with a deflate algorithm, don't know out of my head which one; I think ZLIB) in the firmware updater program and can be extracted (there is a little C program bundled with libnjb that does this; I've never tested it with ZVM's firmware updater program though)
Title: Re: Creative Zen Vision:M
Post by: iSE on July 11, 2007, 11:10:31 AM
I'm still strugglin with the 010 editor template lol. Could you please post the exact template you know to work as lookin at the script I know theres an error, theres 1 { n 2 }'s and a ( without any ). Unfortunately I don't know enough about the scripting language to fix the syntax. I've tried trust me lol.
Title: Re: Creative Zen Vision:M
Post by: saratoga on July 11, 2007, 11:54:09 AM


If, say, the firmware updater does indeed calculate the checksum of the nk.bin file and then upload it to the firmware, and the firmware is merely a series of commands designed to upload an inbuilt nk.bin file, can we not change the nk.bin file slightly, put it back into the firmware updater program, and then try that to upload it to the Zen?

You could try, if you know how : )


Didn't you try this on the previous page?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 11, 2007, 12:07:34 PM

Didn't you try this on the previous page?

You mean extracting nk.bin and putting it back into the .EXE?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 11, 2007, 01:19:31 PM
Ok, so I and iSE had a little conversation about the ZVM's firmware; if you want to see the logs:
http://gim.6te.net/ZVM/Chat.htm
Title: Re: Creative Zen Vision:M
Post by: Transience on July 12, 2007, 12:32:28 AM
I don't know that this will work, but assuming the firmware updater .exe file uses the same checksum algorithm as the firmware itself, wouldn't it be possible to use the updater to generate the checksum we need, without having to know the algortihm?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 12, 2007, 04:19:08 AM

I don't know that this will work, but assuming the firmware updater .exe file uses the same checksum algorithm as the firmware itself, wouldn't it be possible to use the updater to generate the checksum we need, without having to know the algortihm?

Yes, I was thinking the same way! But we are not sure that the .exe and the firmware itself contains the same algorithm; it would be kinda dumb of Creative to do so..

On the other hand, if it is true; it should be possible to generate a valid checksum, but don't ask me how :)
Title: Re: Creative Zen Vision:M
Post by: Transience on July 12, 2007, 01:32:22 PM
Couldn't you use a memory editor or debugger to search for the checksum while the updater is running? If it turned up, it would seem to indicate that both firmware and updater use the same checksum algorithm.
Title: Re: Creative Zen Vision:M
Post by: iSE on July 12, 2007, 05:20:12 PM
Well the firmware wont have the algorithm in it, it only has the checksum stored on the end of it. The last 20 bytes. If anyone is good at making mathematical scripts there is a task which may help.

We are assuming that the checksum is either, SHA-1 (or one of the 3 variants), or maybe even SHA-0. I cannot find the psuedocode for SHA-0 but if anyone can make a program which calculates the SHA-1 checksum from the psuedocode available at wikipedia: http://en.wikipedia.org/wiki/SHA_hash_functions#SHA-1_algorithm, including the 3 different variations of it, just to confirm if it is or is not one of these. You wouldnt need to worry about doing anything with the checksum, literally just to create a program which calculates 4 different checksums from a file. (nk.bin without the NULL block)
Title: Re: Creative Zen Vision:M
Post by: Bagder on July 12, 2007, 05:28:33 PM
sha1sum has been around for ages and while it presents "just" one sha-1 sum,   I figure it could be a nice start to get the other alternatives tested out too...
Title: Re: Creative Zen Vision:M
Post by: iSE on July 12, 2007, 05:33:31 PM
exactly, all the calculators out there only calculate the main one, so that mite be why its not coming up as a match. Creative may not be able to fund their own algorithm so will use a less known one. Its a good start and something to eliminate. If anyone can find any information on the SHA-0 algorithm aswell, that would be useful.
Title: Re: Creative Zen Vision:M
Post by: Transience on July 12, 2007, 07:22:39 PM

Well the firmware wont have the algorithm in it, it only has the checksum stored on the end of it. The last 20 bytes. If anyone is good at making mathematical scripts there is a task which may help.


If that's true then the player can't checksum the firmware being passed to it, and should accept any firmware that is uploaded to it.
The checksum algorithm may also be skipping parts of the firmware file when calculating the checksum, making the job of finding the right algorithm even harder.
Title: Re: Creative Zen Vision:M
Post by: saratoga on July 12, 2007, 07:26:26 PM

If that's true then the player can't checksum the firmware being passed to it, and should accept any firmware that is uploaded to it.


Why would that be?
Title: Re: Creative Zen Vision:M
Post by: Transience on July 12, 2007, 07:52:16 PM
if the firmware doesn't contain checksum code, then it can't determine if the firmware being passed to it is legitamate or not, and it should accept anything.

I just tried searching for the checksum with a memory editor and debugger while the program was running, and found no trace of it. It seems that whatever checksum validation is done, is done by the player, and not the updater.
Title: Re: Creative Zen Vision:M
Post by: saratoga on July 12, 2007, 07:53:15 PM
Sorry, misread what you wrote.  
Title: Re: Creative Zen Vision:M
Post by: Transience on July 12, 2007, 07:59:31 PM
That's alright.
An update on what i said earlier about the firmware updater:
The updater MAY still be performing a checkusm on the firmware. I noticed that the program won't begin an update while I have any sort of memory editor/viewer or debugger running on it. It may not begin the checksum untill its debugger/memory editor check passes. If someone has a harder to detect debugger perhaps they can try searching for the checksum with that, but I've tried three now, and I can't find one that the updater doesn't detect.
Title: Re: Creative Zen Vision:M
Post by: mamboman on July 13, 2007, 05:31:10 AM
if someone has Winhex from http://www.winhex.com i think it's quite powerful
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 13, 2007, 11:13:58 AM
I found some strings in FBOOT:
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 13, 2007, 12:52:42 PM
OK, the checksum is definitely not SHA-0/SHS-0 nor SHA-1/SHS-1..

I downloaded this (http://www.isthe.com/chongo/src/md5_sha/md5_sha.tar.gz) tarball and compiled it and tested it on a ZVM's firmware v.1.62.02 without the NULL block.

Results:
Code: [Select]
Maurus@Beneden ~/hash
$ ./sha1.exe test.bin
4a73bdc1ce9ed6275475bc9c52cf845aeb1ec29c test.bin

Maurus@Beneden ~/hash
$ ./sha.exe test.bin
81c9ec45a2944442b7d05bf5095280d602aea797 test.bin


The data in the NULL block is:
Code: [Select]
77 A0 03 39 3E 4A 09 B9 E1 BD 2F 14 09 7A 8A 8C 17 8F 38 AA

So it doesn't correspond...

Could it have to do something with the endianness?
Title: Re: Creative Zen Vision:M
Post by: TheBlackCat on July 14, 2007, 11:08:58 AM
As I understand it there are 3 possibilities (please correct me if I am wrong).  

1. The hash algorithm is on the old firmware on the hard drive and it checks the new firmware when it is downloaded or the has algorithm is in the flash memory but the flash memory is replaced with each firmware upgrade.

2. The hash algorithm is on the new firmware and it checks itself when it is downloaded to the hard drive (this seems sort of a silly way to do it).

3. The has algorithm is on the flash memory and it rarely or never changes.

Scenario 1 and 2 have the algorithm on the downloaded firmware, either because it checks itself or because the new firmware will need to have the algorithm when it replaces the old firmware.  This will require getting the algorithm out of the code so checksums can be generated for custom firmware or they require somehow editing files on the device directly (which is difficult if not impossible with MTP).  The security issue with this scenario is that it is maybe possible to erase the firmware entirely from the player using "reload firmware" in the recovery console.

Scenario 3 does not necessarily have the hash algorithm in the firmware.  So has anyone tried accessing the flash memory on a ZVM to check it?

Speaking of which, has anyone tried using the recovery console to force the player to download hacked firmware?
Title: Re: Creative Zen Vision:M
Post by: phcoder on July 14, 2007, 02:05:34 PM
As I understood the updater contains SHA-1 constants. Has somebody tried to modify it and look at the behaviour. I foresee 3 possibilities:
1) nothing change. Than this part of code is likely unused
2) updater complains about checksum even before downloading the firmware into the player
3) the null block gets modified and player complains
Title: Re: Creative Zen Vision:M
Post by: iSE on July 15, 2007, 03:30:37 AM
Why do you all assume that the algorithm is in the firmware? I won't be, the checksum, as in the hash key will be stored in the firmware file and we think its the last 20 bytes of the nk.bin file.

It is certainly possible that the firmware updater program has the algorithm, in which case it may be that the checksum is calculated, appended to nk.bin and then transferred. The bootloader then also performs a check on the firmware, checks it with the key and if its ok, lets it pass.

There is no need for the algorithm itself to be stored inside nk.bin and if it is then Creative are extrememly stupid!


Well the firmware wont have the algorithm in it, it only has the checksum stored on the end of it. The last 20 bytes. If anyone is good at making mathematical scripts there is a task which may help.


If that's true then the player can't checksum the firmware being passed to it, and should accept any firmware that is uploaded to it.
The checksum algorithm may also be skipping parts of the firmware file when calculating the checksum, making the job of finding the right algorithm even harder.


Im not saying the firmware doesnt have the checksum key in it, the 40digit checksum code, im saying the actual algorithm used to generate the checksum will NOT be in the firmware. If someone proves me wrong then I'll stand corrected and I would love it if I am wrong, but there is NO reason for creative to put the actual calculating algorithm inside nk.bin. And sorry but its so hard to make a secure algorithm I also doubt they would ever change it.
Title: Re: Creative Zen Vision:M
Post by: Bagder on July 15, 2007, 03:56:40 AM

Why do you all assume that the algorithm is in the firmware? I won't be, the checksum, as in the hash key will be stored in the firmware file and we think its the last 20 bytes of the nk.bin file.


Indeed. But the update program might have the checksum algorithm to verify the image before trying to upgrade to it (just to be able to "warn early").

Quote

its so hard to make a secure algorithm I also doubt they would ever change it.


People don't just invent their own algorithm (if they are clever), they use one of the already established and proven very reliable algorithms. And out of all players rockbox runs on, very few have the ability to change the algorithm.
Title: Re: Creative Zen Vision:M
Post by: iSE on July 15, 2007, 04:30:58 AM

Indeed. But the update program might have the checksum algorithm to verify the image before trying to upgrade to it (just to be able to "warn early").


I agree, and I indeed said that its possible the calculating algorithm is in the updater program just not in the actual firmware file itself (the nk.bin) which is what is transferred to the player.


People don't just invent their own algorithm (if they are clever), they use one of the already established and proven very reliable algorithms. And out of all players rockbox runs on, very few have the ability to change the algorithm.


Again I agree, but if you modify the algorithm slightly it can create huge security holes which is why modifying the algorithm would be out of the question. And if we assume the 40digits at the end of the nk.bin are the checksum, there aren't that many 160bit encryption algorithms out there so they will probably not use a different one each time. My guess is, they always use the same algorithm, obv not SHA-1 or SHA-0 because mcuelenaere checked. Did you check for the variations on the SHA-1 algorithm? There are 3 alternatives to calculating one of the values which are just as secure. So they may have used one of those as then none of the calculators would give a match as they'll use the main psuedocode.
Title: Re: Creative Zen Vision:M
Post by: phcoder on July 15, 2007, 10:25:04 AM
I changed 67->77 in the first SHA-1 constant. The updater no longer recognizes the player and asks me to connect it even if it's connected. I will do further debugging with softice
Title: Re: Creative Zen Vision:M
Post by: bgdwie on July 15, 2007, 11:12:19 AM
ok, so, this may have already been said, but, why doesn't someone get a usb data logger run it whilst doing a firmware update, it will record all packets sent and received via usb, it should give us an idea of what is going on, it might help, it should turn out some pretty interesting info...
Title: Re: Creative Zen Vision:M
Post by: phcoder on July 15, 2007, 11:19:28 AM
BTW. Has somebody thought about padding? To day or tomorrow I'll reverse engeneer SHA-1 related part of updater (I already have some experience with this kind of things)
Title: Re: Creative Zen Vision:M
Post by: aaronwi on July 15, 2007, 12:16:19 PM

ok, so, this may have already been said, but, why doesn't someone get a usb data logger run it whilst doing a firmware update, it will record all packets sent and received via usb, it should give us an idea of what is going on, it might help, it should turn out some pretty interesting info...


This has been done by a couple people, including me, I had a full log of it, couple hundred megabytes worth, posted a while back
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 15, 2007, 04:53:48 PM


Indeed. But the update program might have the checksum algorithm to verify the image before trying to upgrade to it (just to be able to "warn early").

I agree, and I indeed said that its possible the calculating algorithm is in the updater program just not in the actual firmware file itself (the nk.bin) which is what is transferred to the player.

But if the calculation algorithm is not present in the nk.bin file (so neither on HDD nor in flash) how come the ZVM rejects an altered firmware that's uploaded using just MTP commands (so not using the firmware updater program) and accepts an 'official' firmware uploaded using the same method (only MTP commands)?

I conclude that the algorithm must be present either in flash or on HDD (or even on hardware although there's little chance that's the case).
Title: Re: Creative Zen Vision:M
Post by: Bagder on July 15, 2007, 05:11:54 PM
Because the .bin file is simply the update file and the update code and algorithm is in flash.

(that's at least the theory and host most players work)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 15, 2007, 05:13:00 PM

Because the .bin file is simply the update file and the update code and algorithm is in flash.

(that's at least the theory and host most players work)

Doesn't the .bin file also update flash? (FRESC)
Title: Re: Creative Zen Vision:M
Post by: davidb on July 15, 2007, 05:22:18 PM

I conclude that the algorithm must be present either in flash or on HDD (or even on hardware although there's little chance that's the case).


I agree with you - I would say it's safe to assume that the hashing algorithm and check is in the bootloader and that the bootloader doesn't change when you upgrade the firmware. That said, why would the update program need to have the hashing algorithm in it? Why wouldn't Creative just "ship" the firmware updates with the hash already appended to nk.bin? It seems to me that would be the most likely be what they do, but I may be wrong. This is a potentially vital piece of information. Does the firmware update the Creative ships have the NULL block hash value already stored in it? If not, then it is safe to assume that the updating program has the hashing algorithm in it and we should focus on disassembling it to find the hashing algorithm. If the firmware does come with the hash value already stored, then it would seem we need some way to have a look at the bootloader in order to figure out the algorithm.

Also, keep in mind the algorithm itself doesn't necessarily have to run on the entire block of code/memory. I noticed mcuelanaere mentioned running some checks on that first block of the program (everything but the NULL block). What if it just picks the first x bytes, or x bytes starting from y location, or x bytes every y bytes (point being, there's many different possibilities).

I've read this whole thread a couple times through, but it's still hard to pick up on everything that people have done. mcuelenaere, you seem to have made the most progress out of anyone. Would you (and anyone else for that matter) mind documenting what you have done so far on the wiki page so that it's easier for others to get up to speed?

I don't have a Zen yet, but I think I've convinced myself to buy the 60gb one. I'd like to help get rockbox on it because I really want ogg support. I have experience with c/c++ etc and assembler programming. Can anyone recommend what I should start looking into/tools that I should use?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 15, 2007, 05:27:29 PM

I agree with you - I would say it's safe to assume that the hashing algorithm and check is in the bootloader and that the bootloader doesn't change when you upgrade the firmware. That said, why would the update program need to have the hashing algorithm in it? Why wouldn't Creative just "ship" the firmware updates with the hash already appended to nk.bin? It seems to me that would be the most likely be what they do, but I may be wrong. This is a potentially vital piece of information. Does the firmware update the Creative ships have the NULL block hash value already stored in it? If not, then it is safe to assume that the updating program has the hashing algorithm in it and we should focus on disassembling it to find the hashing algorithm. If the firmware does come with the hash value already stored, then it would seem we need some way to have a look at the bootloader in order to figure out the algorithm.

Also, keep in mind the algorithm itself doesn't necessarily have to run on the entire block of code/memory. I noticed mcuelanaere mentioned running some checks on that first block of the program (everything but the NULL block). What if it just picks the first x bytes, or x bytes starting from y location, or x bytes every y bytes (point being, there's many different possibilities).

I've read this whole thread a couple times through, but it's still hard to pick up on everything that people have done. mcuelenaere, you seem to have made the most progress out of anyone. Would you (and anyone else for that matter) mind documenting what you have done so far on the wiki page so that it's easier for others to get up to speed?

I don't have a Zen yet, but I think I've convinced myself to buy the 60gb one. I'd like to help get rockbox on it because I really want ogg support. I have experience with c/c++ etc and assembler programming. Can anyone recommend what I should start looking into/tools that I should use?

Ok, you convinced me : ) I was wrong.
But you do have an interesting point I've never thought about, what if the bare firmware that is included in the .exe does not have the NULL block, but that it would have been added by the program ?
It would make sense why the app would extract it to a place on your HDD and it could be possible.
The only way to find out, is to extract the firmware from the .exe; which I'm going to investigate tomorrow unless someone is ahead of me ; )
Title: Re: Creative Zen Vision:M
Post by: TheBlackCat on July 15, 2007, 06:27:39 PM
That would be possible, but it defeats one of the main purposes of the checksum in the first place which is to make sure the firmware is intact.  If the download is corrupted then the updater will run the algorithm on the corrupt file and generate the checksum for the corrupt file (assuming the algorithm itself is undamaged).
Title: Re: Creative Zen Vision:M
Post by: davidb on July 15, 2007, 08:16:19 PM

That would be possible, but it defeats one of the main purposes of the checksum in the first place which is to make sure the firmware is intact.  If the download is corrupted then the updater will run the algorithm on the corrupt file and generate the checksum for the corrupt file (assuming the algorithm itself is undamaged).

Interesting idea. If this is true for the Zen, then the hashing algorithm will be in the updater program.
Title: Re: Creative Zen Vision:M
Post by: Transience on July 16, 2007, 12:43:59 AM
Not quite on topic, but I've written up all the progress made so far into an article on my website: http://www.the2200.net/phpBB2/kb.php?mode=article&k=11
If anyone finds that I'm missing anything, or that there are errors, I'll be more than happy to correct them.

---EDIT---
I'm having no luck with directMTP myself, but perhaps someone could try modifying one of the big blocks of 00 in the nk.bin file, and uploading it to the player. There's one that starts at 8e72h. I think these mark the boundaries between the firmware blocks, so perhaps the checksum algorithm ignores these sections? It would make sense to ignore those sections in order to save time on the checksum algorithm, as they don't contain any information (as far as i know).
Title: Re: Creative Zen Vision:M
Post by: bgdwie on July 16, 2007, 06:15:11 AM
from what i have examined and observed, the firmware on all of the creative harddisk based mp3 players from the zen touch PFS (playesforsure) onwards is installed and executed the same way, i have read on a number of other forums that a user has made way in reading the partitions upon the zen touch, which are likely to be in the same format as the ones in the vision: m, so could be helpful for reading from that.. too busy looking for the thread... i can't remember where i was going with this....

EDIT: oh yeah, now i remember, now, if it is possible (which we have pretty much said yes to) to hijack firmware onto this player, that would mean that it would also be very easily possible to do it to other creative players too, since they all (just about) use the same processor and firmware loading system.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 16, 2007, 08:52:45 AM
So I tried extracting nk.bin out of the .exe, but didn't came far..

If you split the .exe into the PE-format (http://en.wikipedia.org/wiki/Portable_Executable) (there's a template for 010 Editor here (http://www.sweetscape.com/010editor/templates/files/EXETemplate2.bt)), you get:

sections. The raw ZLIB compressed data is in the .data section; maybe some of the Huffman trees are in the .rdata section, I couldn't extract them cause I don't really know how they look like.

I ran the data from the .data section through WinRAR, PHP's gzinflate() function ( & others) and some universal unpacker program; but they didn't find anything useful.

Now if anyone has some experience with this, could they take a look at it?
Title: Re: Creative Zen Vision:M
Post by: davidb on July 17, 2007, 12:33:46 AM
This is somewhat unrelated to the Zen Vision M, but you may enjoy reading this. It's a patent from Creative for "controlling distribution of protected content." (see http://www.freepatentsonline.com/20070014403.html) I was looking on google for "creative hash algorithm" and various other searches (who knows, I figured it was worth a try).
Title: Re: Creative Zen Vision:M
Post by: iSE on July 17, 2007, 11:11:53 AM

This is somewhat unrelated to the Zen Vision M, but you may enjoy reading this. It's a patent from Creative for "controlling distribution of protected content." (see http://www.freepatentsonline.com/20070014403.html) I was looking on google for "creative hash algorithm" and various other searches (who knows, I figured it was worth a try).


Oh no :( its encrypted and hashed many times by reading that. Best way now it seems is literally to dig through the code of the firmware updater (as it says its encrypted when transferring to the device), and/or the code of the bootloader.
Title: Re: Creative Zen Vision:M
Post by: Falafel on July 17, 2007, 11:44:39 AM
Here ya go:  http://www.mediafire.com/?93sxbsdgm1r link to first 20MB
And just for good measures:  http://www.mediafire.com/?cv2zd0hcb9n link to First 80mb
Title: Re: Creative Zen Vision:M
Post by: davidb on July 17, 2007, 06:56:54 PM

Oh no :( its encrypted and hashed many times by reading that. Best way now it seems is literally to dig through the code of the firmware updater (as it says its encrypted when transferring to the device), and/or the code of the bootloader.


I don't think that patent has anything to do with the Zen Vision M.
Title: Re: Creative Zen Vision:M
Post by: bgdwie on July 17, 2007, 08:26:01 PM
I think that is in relation to the ability to transfer PFS music to and from the player, not the firmware. Also, from what i have read, you won't be able to get any information from creative or TI without signing an NDA, so there is no way they'd let you put the info in an open source firmware solution...
Title: Re: Creative Zen Vision:M
Post by: aaronwi on July 18, 2007, 01:30:30 PM

Here ya go:  http://www.mediafire.com/?93sxbsdgm1r link to first 20MB
And just for good measures:  http://www.mediafire.com/?cv2zd0hcb9n link to First 80mb



What is that from? Zen Vision, M, or W?
What program did you use to make the image?
And what firmware version do you have on your player?


looks like system file references don't begin untill 0x00144200
I think anything useful wont be past 0x001882C8, where a song index starts

otherwise, I don't see any matches to the latest ZVM nk.bin file, even simple things like languages and menu words, no matches.

Someone should take a drive from another zen with different firmware version, and see if it works, and if so which version gets used.

Title: Re: Creative Zen Vision:M
Post by: Falafel on July 18, 2007, 05:05:57 PM
its from a vision (non m or w) firmware version: "ZENVision_PCFW_L16_1_42_01e"
I kopieed directly from the drive using 010 editor.

I'm going to clean out the drive completely and try to install firmware on it..
after that I will knoow for sure that all the bytes in the drive are in fact firmware. after that'll change some and then we will know if the software is checked after installation.
Title: Re: Creative Zen Vision:M
Post by: Transience on July 23, 2007, 12:05:15 AM
Assuming the vision W and M are the same in terms of firmware upgrades, it seems that any checksumming done by the player is done using code stored on the player's ROM, as the HDD can be changed out on the vision W without any problems. http://onemansblog.com/2007/07/20/tutorial-how-to-upgrade-the-creative-zen-vision-w-hard-drive/
Title: Re: Creative Zen Vision:M
Post by: saratoga on July 23, 2007, 09:42:59 AM

Assuming the vision W and M are the same in terms of firmware upgrades, it seems that any checksumming done by the player is done using code stored on the player's ROM, as the HDD can be changed out on the vision W without any problems. http://onemansblog.com/2007/07/20/tutorial-how-to-upgrade-the-creative-zen-vision-w-hard-drive/


While I agree that the checksum must be calculated by the firmware in ROM (since doing it from the disk would make absolutely no sense at all), theres nothing specifically in that link to suggest its the case.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on July 23, 2007, 12:02:26 PM


Assuming the vision W and M are the same in terms of firmware upgrades, it seems that any checksumming done by the player is done using code stored on the player's ROM, as the HDD can be changed out on the vision W without any problems. http://onemansblog.com/2007/07/20/tutorial-how-to-upgrade-the-creative-zen-vision-w-hard-drive/

While I agree that the checksum must be calculated by the firmware in ROM (since doing it from the disk would make absolutely no sense at all), theres nothing specifically in that link to suggest its the case.

Yes there is: as the firmware has to be installed on the new HDD, the ZVM must upgrade its firmware and because the HDD is empty, the checksum can't be on it.

Anyway, I was thinking last night: there are several F* (FBOOT, FRESC) blocks and several H* (Hjukebox.grs, Hjukebox2.jrs, ...) blocks; if the F refers to flash and the H to HDD, it would mean everytime an upgrade is performed the boot code is flashed.

To prove my theory: if you look at the rescue menu, you'll see a version number. If you upgrade your firmware, this number changes. But if your HDD becomes corrupt or your ZVM won't boot anymore (you come automatically in Rescue mode), this number is the same (so it doesn't depend on a file on HDD).

So in short, a HDD dump wouldn't give us any real useful information, because (boot) code is stored in ROM/flash.

Also, there are 2 other strange blocks in nk.bin (EXT0 and an encrypted one), maybe one of them could contain DSP code and/or are written to a specific place (as none of them has an H or F in front of their name); but this has nothing to do with the above.
Title: Re: Creative Zen Vision:M
Post by: jermey on July 26, 2007, 05:16:51 PM
i tell you something guys: put your zen nearby your ears and then swith it on and try somehow watch lcd and you will see that boot sector is on flash and firmware is on hdd
Title: Re: Creative Zen Vision:M
Post by: Transience on July 27, 2007, 12:09:16 AM
after some searching, i found that the firmware isn't in the first 20-80mb of the HDD. On mine, 010 Editor shows that the firmware images, at least, are located around 2302:2F50h. i was able to modify one of the images on the disk, powercycle the player, and the modification was still there when i opened the drive again in 010. the image i changed was a green check mark, but i'm not sure where that image is used :(. If anyone knows, please let me know.
Title: Re: Creative Zen Vision:M
Post by: Mardoxx on July 27, 2007, 05:30:23 AM
there's a checkmark when you change password protected content password
when you use the Custom EQ
ummm I've seen one somewhere before

I'll have a look :)
Title: Re: Creative Zen Vision:M
Post by: Transience on July 29, 2007, 10:41:08 PM
back to the problem of the checksum, if the bootloader is checksumming the firmware, creative almost certainly used an existing function, rather than code their own. It seems that they may have coded the bootloader to skip parts of the firmware during the checksum, to save time. since the bootloader would have to be able to check future (not yet coded) firmware updates, it probably skips parts based on the block structure of the firmware (that would be the easiest way, anyway). so perhaps the bootloader is only checksumming certain blocks of the firmware, and skipping others?
Title: Re: Creative Zen Vision:M
Post by: davidb on July 30, 2007, 12:30:29 AM

so perhaps the bootloader is only checksumming certain blocks of the firmware, and skipping others?


My post on page 20 says the same thing.


Anyway, I was thinking last night: there are several F* (FBOOT, FRESC) blocks and several H* (Hjukebox.grs, Hjukebox2.jrs, ...) blocks; if the F refers to flash and the H to HDD, it would mean everytime an upgrade is performed the boot code is flashed.

To prove my theory: if you look at the rescue menu, you'll see a version number. If you upgrade your firmware, this number changes. But if your HDD becomes corrupt or your ZVM won't boot anymore (you come automatically in Rescue mode), this number is the same (so it doesn't depend on a file on HDD).

So in short, a HDD dump wouldn't give us any real useful information, because (boot) code is stored in ROM/flash.

Also, there are 2 other strange blocks in nk.bin (EXT0 and an encrypted one), maybe one of them could contain DSP code and/or are written to a specific place (as none of them has an H or F in front of their name); but this has nothing to do with the above.


I believe your right about the F* and H* theory and therefore about the HDD dump not providing anything about the hashing algorithm. I really think what we need to be concentrating on is answering the question I posed earlier - does the firmware come with the checksum value already in the null block, or does the updater put it there.
Title: Re: Creative Zen Vision:M
Post by: mitch04 on July 31, 2007, 03:20:03 AM
hi ok this is something different but i was looking around and i foun this site Creative ZEN Vision M Firmware Mod  talks about all this
Article Name: Creative ZEN Vision M Firmware Mod
Author: Transience
Description: All the information currently known about the ZVM's firmware.

Category: Modification
Type: Programming

the site is http://the2200.net/phpBB2/viewtopic.php?t=34
i asked his what this is but havnt wrote back yet
Title: Re: Creative Zen Vision:M
Post by: iSE on July 31, 2007, 12:42:03 PM
Yeah thats a summary of everything thats been posted here n on epizenter
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 03, 2007, 11:12:50 AM

I believe your right about the F* and H* theory and therefore about the HDD dump not providing anything about the hashing algorithm. I really think what we need to be concentrating on is answering the question I posed earlier - does the firmware come with the checksum value already in the null block, or does the updater put it there.

Indeed, I agree with you.
But to find out, we should extract the firmware from the .exe where it is ZLIB compressed.
I already tried decompressing it, but without any result (see some posts back (http://forums.rockbox.org/index.php?topic=3320.msg87634#msg87634)).
Could someone else try this?
Title: Re: Creative Zen Vision:M
Post by: iSE on August 03, 2007, 11:18:53 AM
could it be that its encrypted aswell?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 05, 2007, 07:17:04 AM

could it be that its encrypted aswell?

It could be, but I don't think so.
There maybe is some MD5 verification, but it would be kinda strange of Creative to do so
(cause then you would have an MD5 "hacker-free" ZLIB compressed binary, which will get an SHA-1 sort-of hash added and get sent to the device).
Title: Re: Creative Zen Vision:M
Post by: MagistrateD on August 15, 2007, 12:11:38 AM


I believe your right about the F* and H* theory and therefore about the HDD dump not providing anything about the hashing algorithm. I really think what we need to be concentrating on is answering the question I posed earlier - does the firmware come with the checksum value already in the null block, or does the updater put it there.

Indeed, I agree with you.
But to find out, we should extract the firmware from the .exe where it is ZLIB compressed.
I already tried decompressing it, but without any result (see some posts back (http://forums.rockbox.org/index.php?topic=3320.msg87634#msg87634)).
Could someone else try this?


im no expert with .exe files but by looking at the latest patch.exe fro the zvm it looks like the fun stuff starts at 0x001000 and ends at 0xF1D140 and is followed by a series of warning strings.  i tried running the all round unidecrypt and all i could learn was that it is coded in C++ 6.0. if anyone has anymore guesses about what format it could be compressed in lemme know please.

EDIT: not sure if someone has pointed this out before but creative has a recovery tool for all mps players (http://www.creative.com/products/mp3/MP3PlayerRecoveryTool/welcome.asp?region=2)
not too sure if its worth taking a look at to manipulate and im too tired to check but this also means that if any little tests brick a zen it can be reverted.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 18, 2007, 09:08:52 AM
Some (useful) links were posted at epiZENter.net:

http://flickr.com/photos/chlazza/946305589/
http://flickr.com/photos/chlazza/946305207/
http://flickr.com/photos/chlazza/946305167/
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 27, 2007, 05:43:23 PM
OK so the last few days I focused myself on trying to extract the compressed nk.bin out of the installer, which I unfortunately didn't succeed in.
But if someone could locate the program called deezee (http://www.matasano.com/log/127/extract-compressed-blobs-from-binaries/) or one which has the same functionality, that could be very helpful.
edit: I already got the program now, but it didn't work; so the data must be available in an altered way and not in the normal ZLIB format.

On the other hand, I analyzed some of the files in nk.bin and I'm pretty sure EXT0 is written for the C54x DSP chip and FBOOT is the boot loader (which could load the encrypted/compressed/obfuscated/... block present in the nk.bin file).

I also checked the SHA-1 variants iSE sent me, but apparently these are just 'other ways' for generating the same SHA-1 checksum; so maybe Creative is using a slightly modified version or they are computing the checksum in a way we don't (yet) know, for example the whole file except for the first 10 bytes.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 28, 2007, 08:37:54 AM
So I extracted some raw data out of the exe, but I think it is 1)XORed with a key and 2)ZLIB compressed.

The size of the file is present at 0x5D0C0 and is a Little Endian UInt. Directly after this number is the raw data present ending in one '0000' block. These numbers are based on ZENVisionM_30GB_PCFW_L21_1_61_01.exe.

The file could be XORed with this key: '34d12D23f6c894B96ff4735153836'

download link: http://www.verzend.be/v/7079781/perfect.bin.html
Title: Re: Creative Zen Vision:M
Post by: zook on September 12, 2007, 12:21:19 PM

I really think what we need to be concentrating on is answering the question I posed earlier - does the firmware come with the checksum value already in the null block, or does the updater put it there.

I'm a bit limited by not owning the player but I've unpacked the firmware image stored in ZENVisionM_30GB_PCFW_L21_1_62_02e.exe.
There is a checksum within the NULL block: 45E2 DCDD 4C07 2B99 5DDB B21A B15A D1EF 55CC 6A3A
But I can't say if it differs from the one sent to the device.


The file could be XORed with this key: '34d12D23f6c894B96ff4735153836'

Close. The key is slightly mutated first.
Decrement each character by one, and OR 0x80 to the result.
Then it's just standard zlib inflate from there on.
The process is the same for the Jboxcrl.crl and unicow.dll.


Has it been established if all segments within the firmware image effect the checksumming? Is the segment headers included in the sum? If the scope was more limited, it would be more feassible to perform crypt analysis on the different versions of the checksums.
I'm mostly inclined to believe that the checksum is a standard algorithm, who's result get's mutated to obscure where it's from. Based on the mutation used in the updater, I'm guessing that it's simple enough to be discovered through basic crypt analysis.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on September 12, 2007, 01:15:42 PM


I really think what we need to be concentrating on is answering the question I posed earlier - does the firmware come with the checksum value already in the null block, or does the updater put it there.

I'm a bit limited by not owning the player but I've unpacked the firmware image stored in ZENVisionM_30GB_PCFW_L21_1_62_02e.exe.
There is a checksum within the NULL block: 45E2 DCDD 4C07 2B99 5DDB B21A B15A D1EF 55CC 6A3A
But I can't say if it differs from the one sent to the device.


The file could be XORed with this key: '34d12D23f6c894B96ff4735153836'

Close. The key is slightly mutated first.
Decrement each character by one, and OR 0x80 to the result.
Then it's just standard zlib inflate from there on.
The process is the same for the Jboxcrl.crl and unicow.dll.

Wow, that's some pretty nice accomplishment you've got there :)
Could you provide me with some more information about dexoring the contents (so each character of the key is decremented by one and then you just OR 0x80 every character of the raw contents incrementing the position in your key-string?) or did you make a little program which does the extracting?

And as you're saying the extracted nk.bin file already got an NULL block, this means that we are back to square 1..

Quote

Has it been established if all segments within the firmware image effect the checksumming? Is the segment headers included in the sum? If the scope was more limited, it would be more feassible to perform crypt analysis on the different versions of the checksums.
I'm mostly inclined to believe that the checksum is a standard algorithm, who's result get's mutated to obscure where it's from. Based on the mutation used in the updater, I'm guessing that it's simple enough to be discovered through basic crypt analysis.


I'll try to do an SHA-1 checksum on only the data (so without the segment headers), but it may be easier deassembling FBOOT or FRESC to check if there is some checksum code present there...

edit:
The checksum value gave me 11E2AE6CC89B212F8FA860730B15327336439E7E while the NULL block contains 77 A0 03 39 3E 4A 09 B9 E1 BD 2F 14 09 7A 8A 8C 17 8F 38 AA
Title: Re: Creative Zen Vision:M
Post by: zook on September 12, 2007, 01:24:27 PM
Here's my hacked together code: http://rafb.net/p/vTdhN853.html

The relevant bit is:
Code: [Select]
   // Mutate the xorkey.
 Â   for (int i = 0; i < keylen; i++)
 Â   {
 Â       key[i] = key[i] - 1;
 Â   }

 Â   // Decipher the chunk.
 Â   for (int i = 0, j = 0; i < dwChunkSize; i++, j = i % keylen)
 Â   {
 Â       lpChunk[i] ^= (key[j] | 0x80);
 Â   }


I'll be working on providing an easy way to produce checksums of the different segments.
EDIT: Once that's done it would be nice with some other versions of the firmware for comparison.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on September 12, 2007, 01:53:34 PM

Here's my hacked together code: http://rafb.net/p/vTdhN853.html


I'm trying to get this thing compiled ;) but atm I only got 1 problem left and this is:
Code: [Select]
Error 4: fatal error LNK1104: cannot open file 'MSVCMRTD.lib' (I'm using VC++ 2005 and I'm getting it both in Release & Debug mode)

Could this mean I should reinstall VC++?
Title: Re: Creative Zen Vision:M
Post by: zook on September 12, 2007, 01:56:42 PM


Here's my hacked together code: http://rafb.net/p/vTdhN853.html


I'm trying to get this thing compiled ;) but atm I only got 1 problem left and this is:
Code: [Select]
Error 4: fatal error LNK1104: cannot open file 'MSVCMRTD.lib' (I'm using VC++ 2005 and I'm getting it both in Release & Debug mode)

Could this mean I should reinstall VC++?


How are you linking to zlib?
With my project I just added a console project to the zlib solution and added a reference.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on September 12, 2007, 01:58:15 PM
I downloaded an precompiled ZLIB dll which included an zlib.h file; and it didn't complain about anything related to ZLIB, so I didn't think it could be that. But I'll try your way.
Title: Re: Creative Zen Vision:M
Post by: zook on September 12, 2007, 02:02:23 PM
When the linker complains about missing libraries or multiple definitions. It's often because you're linking with a library which implicitly links to other libraries, which may be incompatible with your setup.
The library could also come from a pragma statment in one of the headers you're using.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on September 12, 2007, 02:21:07 PM
Ok, I got it going by defining ZLIB_WINAPI, including the zlibwapi.lib and including zlib.h
Only problem now is: it is eating my memory ;)
Currently it is using 1,2GB of RAM, which is definitely due to Zlib; because I got the same problem a while ago.
But now I can't end the process (?? maybe some WinXP bug) and so 1,8GB of 512MB RAM is in use...
Title: Re: Creative Zen Vision:M
Post by: zook on September 12, 2007, 02:26:40 PM
Hmm. I'm also on XP (32-bits), so that shouldn't be it.
Does the two examples that comes with zlib work?
Maybe I should just add command line options and upload the exe...
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on September 12, 2007, 02:35:16 PM

Hmm. I'm also on XP (32-bits), so that shouldn't be it.
Does the two examples that comes with zlib work?
Maybe I should just add command line options and upload the exe...

I think that would be the best, since I had to restart my pc in order to solve the problem ;)
Title: Re: Creative Zen Vision:M
Post by: zook on September 12, 2007, 03:04:30 PM
Okey, here it is: http://www.fileshost.com/en/file/5227/ZvmFirm-rar.html
The cli is as follows:
ZvmFirm [-d updater offset outputfile key] | [-i firmware]
  -d decompresses
  -i displays segment information

  updater - is the executable.
  offset - is the offset of the compressed size in C/C++ hexadecimal notation.
  outputfile - is the file you want it stored in. this file will be overwritten if it already exists.
  key - is the non-mutated ascii key.
  firmware - is the firmware filename.
Title: Re: Creative Zen Vision:M
Post by: zook on September 13, 2007, 08:23:12 AM
I think I know what your problem was. You forgot to update the 'offset' and/or 'xorkey'.
I've been collecting different versions of the firmware and ran into the same problem, when either of those were not correct.
I'll list the offset and key values that I've found and tested here:
Code: [Select]
ZENVisionM_30GB_PCFW_L20_1_51_01.exe    0x5C0D0   34d12CC55497667G239f734499796
ZENVisionM_30GB_PCFW_L21_1_60_01.exe    0x5C0D0   34d12FD8Be716793Fd7df4611544519
ZENVisionM_30GB_PCFW_L21_1_61_01.exe    0x5D0C0   34d12D23f6c894B96ff4735153836
ZENVisionM_30GB_PCFW_L21_1_62_02e.exe   0x5E0C0   34d124E7B849397127d97992522927
ZENVisionM_60GB_PCFW_L20_1_11_04.exe    0x5B0D0   34d1252E3f9874F2B945e447139419
ZENVisionM_60GB_PCFW_L21_1_21_02e.exe   0x5E0C0   34d12DGC76efe694999527119669896
ZENVisionM_PCFW_LF_1_41_01.exe          0x5C0D0   34d125FBBb7c9BEGGf7ce999942972
ZENVisionM_PCFW_LF_1_41_01e.exe         0x5C0D0   34d12BF95f65825D491996213143192


One odd thing that I've discovered is that the FBOOT DATA segment is the exact same size in the majority of these. And the ones I've compared are also mostly identical, except for a block at the end. This block starts with a 32-bit size and then there's a chunk of encrypted/compressed data, which is radically different amongst the different versions. The block size is also the same in the different versions.
Given that the size is the same in each version, I'm guessing that there hasn't been any changes to the content of the block, but rather it's been encrypted with different keys.
I obviously have no clue about this data but it could reveal some important aspects of the crypto used, and anything worth hiding probably has some significance. Supposing that the data is encrypted with a xor key, then we could possibly discover the key used through character frequency analysis. Now, what good is the key? Well, if the key changes between each firmware, then the key should be in the firmware somewhere. Also, it would be somewhat wasteful to have multiple encryption algorithms for different puporposes. For space efficiency they would probably use the same algo and possibly key.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on September 13, 2007, 10:27:17 AM

I think I know what your problem was. You forgot to update the 'offset' and/or 'xorkey'.
I've been collecting different versions of the firmware and ran into the same problem, when either of those were not correct.

Could be
Quote

One odd thing that I've discovered is that the FBOOT DATA segment is the exact same size in the majority of these.

This could mean that FBOOT is just a boot loader loading the code from HDD or it could mean nothing really is changed to the main code (which I doubt if you look at the changes in different firmwares)
Quote
And the ones I've compared are also mostly identical, except for a block at the end. This block starts with a 32-bit size and then there's a chunk of encrypted/compressed data, which is radically different amongst the different versions. The block size is also the same in the different versions.
Given that the size is the same in each version, I'm guessing that there hasn't been any changes to the content of the block, but rather it's been encrypted with different keys.

Are you talking here about EXT0 or about LT© ?
Quote
I obviously have no clue about this data but it could reveal some important aspects of the crypto used, and anything worth hiding probably has some significance. Supposing that the data is encrypted with a xor key, then we could possibly discover the key used through character frequency analysis. Now, what good is the key? Well, if the key changes between each firmware, then the key should be in the firmware somewhere. Also, it would be somewhat wasteful to have multiple encryption algorithms for different puporposes. For space efficiency they would probably use the same algo and possibly key.

Hopefully they did :)

I also took a look at the firmware and I made some little changes to the 010 Editor parsing template:
Code: [Select]
//--------------------------------------
//--- 010 Editor v2.0 Binary Template
//
// File: Creative firmware (nk.bin)-Parser
// Author: l_e
// Edited by: mcuelenaere
// Revision: 0.1
//--------------------------------------

typedef struct {
CHAR BlockID[4];
DWORD Size;
if (BlockID == "FNIC"){
UCHAR Desc[96];
} else if (BlockID == "0TXE"){
UCHAR Desc[24];
UCHAR Data[ Size - sizeof(Desc) ];
} else if (BlockID == "LLUN" || BlockID == "FFIC" || BlockID == " LT©"){
UCHAR Data[ Size ];
} else {
UCHAR Desc[32];
UCHAR Data[ Size - sizeof(Desc) ];
}
} BLOCK;
//--------------------------------------------
The rest stays the same.
Together with the template above I made this one for EXT0:
Code: [Select]
//--------------------------------------
//--- 010 Editor v2.0 Binary Template
//
// File: Creative firmware (EXT0)-Parser
// Author: mcuelenaere
// Revision: 0.1
//--------------------------------------

typedef struct {
CHAR BlockID[4];
DWORD Size;
UCHAR Data[Size+2];
} BLOCK;
//--------------------------------------------
CHAR[] StrRev( CHAR s[] )
{
local int sz;
local int up;
local CHAR strng[sizeof(s)];

for (sz =sizeof(s)-1,up=0;upstrng[up] = s[sz];
}
return strng;
}


string ReadBLOCK( BLOCK &block )
{
return StrRev( block.BlockID );
}
//--------------------------------------------

local ulong id;
local ulong tmp;
local ulong ofs;

BigEndian();
id = ReadUInt( FTell() );

while ( !FEof() ){
FSeek( ofs );
BLOCK block;
FSeek( ofs+sizeof(block) );
ofs = FTell();
}

//--------------------------------------
Title: Re: Creative Zen Vision:M
Post by: zook on September 13, 2007, 12:04:24 PM

This could mean that FBOOT is just a boot loader loading the code from HDD or it could mean nothing really is changed to the main code (which I doubt if you look at the changes in different firmwares)

Yeah, I think FBOOT is the complete boot loader. Based on the segment sizes, my guess would be that ®TL contains the player code and EXT0 is either filesystem or flash data.

Are you talking here about EXT0 or about LT© ?

I was still talking about FBOOT. If you look at offset 0xB000 of that segment, you'll see 80 1C 00 00, which is the size (7296) of the following chunk. It's the exact same location and size in all but two of the ones I've looked at, yet the contents is entirely different. The only explanation that I can think of, is that each version is encrypted with a different key.

I also took a look at the firmware and I made some little changes to the 010 Editor parsing template:

Ahh, I tried using the other template earlier, but the board software displays the code incorrectly.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on September 13, 2007, 01:06:42 PM

Ahh, I tried using the other template earlier, but the board software displays the code incorrectly.

http://rafb.net/p/Y25m3N12.html

http://rafb.net/p/YoH1fj87.html
Title: Re: Creative Zen Vision:M
Post by: zook on September 15, 2007, 07:36:14 AM
I've been checking out various leads.
First I got my code setup to handle different algorithms and combinations of segments. I've used the following algorithms: MD4, MD5, RIPEMD-128, RIPEMD-160, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 & TIGER. And the following combinations of segments:
Full w/ header -- The entire CIFF segment, including it's header.
Full w/o header -- The entire CIFF segment, excluding it's header.
Segmented w/o headers -- All segments within CIFF, excluding their headers.
Segmented w/o headers(!DATA) -- All non-DATA segments within CIFF, excluding their headers.
Segmented w/o headers(DATA) -- All DATA segments within CIFF, excluding their headers.
Segmented w/o headers(DATA.F) -- All F* DATA segments within CIFF, excluding their headers.
Segmented w/o headers(DATA.H) -- All H* DATA segments within CIFF, excluding their headers.
In this setup I've computed the hashes and xored them with the NULL block value. The idea was to test the assumption that the NULL block was obsfuscated by a constant xor key. However, that's not the case for this set of combinations and algorithms. Here's a log of the output: http://rafb.net/p/YQ0Kfr77.html

Second, I've been looking for repeating patterns in the ending block of the FBOOT segment. The idea behind this was again, to determine if a xor cipher was used. For example, with a xor cipher, blocks of zero will leave parts of the key exposed as a repeated pattern. However, I haven't been able to find any such patterns in the block. One explanation could be that the block is encrypted and compressed. Or they could be using a real cipher.

Third, I've looked at the firmware updater itself. There was some crypto algorithms mentioned earlier and I've been looking into their role. The ECC(Elliptic Curve Crypto), DES, RC4 and SHA-1 together form an implementation of MS-DRM v2, or similar, as described here: http://www.spinnaker.com/crypt/drm/freeme/Technical
Most, if not all, of the crypto code comes from MS SDK libraries.
The scheme is used to authenticate the firmware updater application with either the Windows Media Device Manger or Media Transfer Protocol API's. Apparently using some parts of these API's require that you have a certificate issued by MS.

So, in summary, a lot of work but little progress. I'm starting to think that looking at the firmware is the only viable approach. However, I'm not in the least bit familiar with anything besides x86 assembly. I've tried disassembling the FBOOT segment using various different processor modules but none of them yield any intelligible code, that I can tell anyway. If anyone has anything to contribute in the ways of getting a disassembly, then I'd be happy to familiarize myself with the instruction set and architecture.
Title: Re: Creative Zen Vision:M
Post by: Transience on October 01, 2007, 03:19:18 AM
Seeing as it's fairly easy to access/modify the firmware data on the HDD, couldn't we use the creative bootloader to launch rockbox? or is this more trouble than it's worth? The bootloader doesn't check the firmware on the HDD since I was able to modify a GUI image and have the player still boot. Is this a feasable idea?
Title: Re: Creative Zen Vision:M
Post by: GodEater on October 01, 2007, 04:39:33 AM
I would say so - if you can do it. It's the same method currently used on the Gigabeat F/X for example - there's some Toshiba bootstrap code which starts the device, and then jumps into the rockbox bootloader.
Title: Re: Creative Zen Vision:M
Post by: zook on October 01, 2007, 08:20:09 AM
Having looked at elder zen models, it's obvious that the NULL signature is the least of our worries.
Every entry of code within the firmware archive is encrypted and without an understanding of the algorithms used, we can't put any meaningful code on the player.
I've found several elder zen models which employ a lesser protected scheme and in later firmware versions introduce the fully protected one.
This open's up the possibility of understanding the protocol used to get fully protected firmware onto a player.
As such I'm currently looking at the Dell DJ and other zen players using the same scheme.
Title: Re: Creative Zen Vision:M
Post by: fejfighter on October 10, 2007, 12:58:08 AM
I tried for a search through this thread (i have read all of it, but some of it was quite a while ago)

has anyone tried disasembling the actual firmware installer (regardless of what firmware is inside) in order to try and follow how the firmare makes its way to zen vision? it may reveal when and where the checksum is done,

apologies if it has already been tried


keep up th good work too  ;D
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on October 10, 2007, 06:22:22 AM

I tried for a search through this thread (i have read all of it, but some of it was quite a while ago)

has anyone tried disasembling the actual firmware installer (regardless of what firmware is inside) in order to try and follow how the firmare makes its way to zen vision? it may reveal when and where the checksum is done,

apologies if it has already been tried


keep up th good work too  ;D

This is what zook did, some time ago. He found out that the firmware inside the installer already has a checksum, and as we already know how a firmware gets on the ZVM (just using plain MTP commands); it didn't help much so he kept looking (and is still) -> meaning he's disassembling the firmware and decoding the firmware blocks so the encryption/obfuscation can be broken.
Title: Re: Creative Zen Vision:M
Post by: zook on October 11, 2007, 09:25:33 AM
The length of this thread sadly does not reflect the progress made.

The show stopper is that the executable code within the ZVM firmware is encrypted/encoded.
We know that the ©TL block (stored on the hd as Jukebox2.jrm) contains the player software and will ultimately be our method of placing software on the player. The ©TL block is decrypted/decoded and loaded by the FRESC block code, which contains a minimal OS and the resuce mode software. Both of these are encrypted/encoded using an unknown algorithm.

Elder creative players contains FRESC blocks that are unprocessed, which has given us some insight into what the rescue mode software is responsible of. On these same models, firmware updates introducing Play4Sure brings the changes that are seen in the ZVM firmware, ie. encrypted/encoded blocks and ©TL blocks instead of CENC blocks.
This means that the pre-P4S firmware must know something about the new firmware scheme, otherwise the player wouldn't be able to process them.
Now, the million dollar question is: which part of the new firmware is the first to be executed? and how is it processed prior to execution?
When we can answer these questions, we'll most likely have a method of opening up the ZVM firmware.

At any rate, I'd suggest that anyone interested in helping out, checks out the Dell DJ port thread and wiki. I've seen enough similarities in the software in the different elder creative players, to believe that we'll be able apply whatever learn about them to the newer models.
Title: Re: Creative Zen Vision:M
Post by: Transience on October 20, 2007, 07:24:44 PM
Could the firmware be packed using a program like morphine, or some other file packer? As I understand it, these programs allow a file to be compressed/encrypted/obfuscated while leaving their ability to run unchanged. File packing is a common way to get malicious code past virus scanners, so could creative be using the same method to keep their firmware secure?
Title: Re: Creative Zen Vision:M
Post by: zook on October 27, 2007, 05:54:33 PM

Could the firmware be packed using a program like morphine, or some other file packer? As I understand it, these programs allow a file to be compressed/encrypted/obfuscated while leaving their ability to run unchanged. File packing is a common way to get malicious code past virus scanners, so could creative be using the same method to keep their firmware secure?

Speculation is what has inflated this thread. I realize that you're trying to be helpful, but if you'd read the previous pages of this thread, you'd know that we've already looked at the firmware updater and figured out how to extract the firmware archive from it.
So, if you generally don't know enough about something to test it out yourself, then chances are that it isn't useful.
Case in point, it would have been simple to use PEiD or another signature scanning tool to test your theory.

Also, you're slightly confused about what the firmware is. The executable you run is a portable executable which is responsible of sending a file to your player and then asking the player to update itself using this file. This file is what I'm calling the firmware archive, as it's a collection of different items which is "unpacked" to different locations on the player. The firmware is either this collection, or more specifically the software items contained within it.




The show stopper is that the executable code within the ZVM firmware is encrypted/encoded.


I've gotta correct this statement. I don't know how I've previously missed this but FBOOT contains ARM code in the first part, and a fixed size encrypted block at the end.
I have not studied it in detail but there's code checking for the tag value of the FRESC header ('CODE'). The function appears to be loading an FRESC file format, presumably FRESC. There's no references to the function, though, so I can't determine if the data is processed prior to loading.
There's also references to TSIG and TOC0, which I believe are part of the logical flash partitioning. The rescue mode software on the Dell DJ contains a table of names, addresses and sizes, which is used by the flash related code: TSIG, BOOT, CONF, TOC0, PFM1 and RESC.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on October 28, 2007, 09:44:18 AM
I disassembled the (start of the) ARM part of FBOOT and apparently the decrypt/decompress routine is in it.
Problem is: I can't figure out how it works, I tried commenting every instruction but it didn't help me much further.
Could someone look at it ?

In the attachment is the FBOOT binary and an IDB file(IDA database).
http://rapidshare.com/files/65787508/FBOOT.rar

edit:
@zook: did you figure out how the NULL block algorithm works? Because if you did, we could put some assembly in FBOOT (since the first part is pure unencrypted ARM assembly) and try uploading it to the ZVM
Title: Re: Creative Zen Vision:M
Post by: zook on October 28, 2007, 12:42:51 PM
Bah, just lost the message I had typed up in a timeout. I'll make it brief.

Have a look at SPRA763C (Using the TMS320VC5510 Bootloader), it details the different boot modes of the C55x. I believe the configuration used is the EHPI. That would make the ARM (refered to as the host) code responsible of putting the C55x into execution.

I've had a look at your Decrypt function and if you look only at the two stores, you'll see that they merely store data loaded in the previous instruction. So in terms of I/O there's no modification going on.
Try getting hold of an ARM simulator/emulator, that'll make it much easier to explore FBOOT.

The NULL signature only governs upgrade.jrm in the upgrade process, once upgraded it's deleted along with upgrade.jrm. I still don't have access to FRESC or TL, which will contain the signature checking code.
Title: Re: Creative Zen Vision:M
Post by: zook on November 09, 2007, 04:35:44 PM
I've looked at FBOOT some more and thought I'd share my findings.

The file is initially mapped to an address >= 0xFF000000. The first few instructions tests if the program counter is not below 0xFF000000 and if it is it'll execute the initialization code that follows, otherwise it'll branch to address 0x100000.

The initialization code makes two remappings.
Bytes at offset 0x350 till 0x2CDC (0x298C bytes) are copied to address 0.
Bytes at offset 0x2CE0 till 0x9E90 (0x71B0 bytes) are copied to address 0x900000.

The encrypted chunk of data at offset 0xB000+4 till the end is referenced by a set of functions which also references what could be the exponent in a public key encryption system (0x10001).
Datawise, my money is on RSA with a 1024 bit's public key. E appears to be located at address 0x40 and N at 0x80, they're both stored in little endian byte order.
Public key encryption would explain why why the encrypted chunk differs so much between otherwise similar firmware versions.

I'll try decrypting the data under my assumptions and if that fails I'll try getting the code running in an emulator.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on November 09, 2007, 05:12:08 PM
As the start of FBOOT is standard ARM i.e. not-encrypted, it would be possible to overwrite this with other code (for example the Rockbox bootloader)?
I mean, once we got code flashed(by overwriting the FBOOT block & correcting the NULL block) on the Zen and letting it jump to it, we wouldn't have to find a way to get along with the private/public key cryptography? (just to make sure there isn't any need to crack the possible RSA private key)

Am I correct?
Title: Re: Creative Zen Vision:M
Post by: zook on November 09, 2007, 05:36:35 PM
The encrypted chunk contains code that is executed if the decryption is successful.
The keys are stored in FRESC, so if there really is a need to produce our own encrypted chunk, we'll just patch either the exponent or modulus.
However, given that the entire FRESC block is covered by the NULL signature, we've got no way of modifying anything at this point.
At any rate, I'm guessing that the encryption is merely used for hiding the code and/or data from plain view.
Title: Re: Creative Zen Vision:M
Post by: zook on November 10, 2007, 10:54:03 AM
OK, I was right about it being RSA. Here's a program for decrypting the chunk:
http://www.fileshost.com/en/file/14964/fboot-decrypt-rar.html

However, it does look like there's more to the scheme, as I get different results with the various firmware versions.
On some versions the following string appears: "N0MAD iz v~p0wderful!" on others it's fragmented. I'm guessing that the decrypted data needs further parsing, but I'll have to look into it.
The decrypted chunk also contains 'RESC' so it's probably responsible for loading the rescue mode software into memory.

EDIT: I've figured out what was wrong. The decrypted data needs to be written out as blocks of 0x78 bytes, instead of 0x80.
I've just found the blowfish s-box and p-array, in code which references both 'CODE' and 'RESC'... this is getting exciting :)

UPDATE:
Blowfish is used in CBC mode, using the key "Copyright (C) CTL. - zN0MAD iz v~p0wderful!" and an unknown IV.
The IV should be easy to determine in CBC mode, but I'm getting different results between the ARM simulator and my own code. Neither produces the expected output.
The code is definitely used to decrypt FRESC, however I'm not sure if there's any processing to the data prior to decryption.
Title: Re: Creative Zen Vision:M
Post by: zook on November 11, 2007, 10:29:20 AM
I've worked out what the problem was. The key length includes the terminating zero.
The IV is set to the length of FRESC in big-endian, for the first 32-bit word and zero for the second.

Here's the fixed FBOOT and FRESC decrypters: http://www.fileshost.com/en/file/15124/fboot-fresc-decrypt-rar.html

Once you get FRESC decrypted you're in for a bit of suprise. The rescue mode software on the zvm is running on the ARM core and uses the Nucleus RTOS.
I've updated zenldr to support the ARM/little endian architecture: http://www.fileshost.com/en/file/15126/zenldr-rar.html
This is really great. I had been slightly concerned about the absense of a free compiler for the tms320 based chips. But that's pretty much a non-issue now :)

Now, I've been poking around a bit, and I've found that the NULL signature is SHA1 but it's used as a MAC. I haven't worked out what's being fed into it yet, though.
Jukebox2.jrm(TL) is also encrypted using blowfish (with a different key and iv). Once decrypted it's decompressed using cenc_decode, so that at least wasn't a waste of time.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on November 11, 2007, 01:44:58 PM
Great work zook!  :D

If you look at some strings in FRESC, you see that some files (devopen.c, devdraw.c, font_freetype2.c, fblin16.c, ...) are the same as in http://svn.neurostechnology.com/listing.php?repname=Nano-X&path=%2Ftrunk%2F&rev=4&sc=1
So they are using the MicroWindows (Nano-X) engine.

According to 'Copyright MGC 2004 - Nucleus PLUS - ARM925 TI v. 1.14',  'Accelerated Technology Internal Use Only - Serial Number: NP0000' and 'Copyright(c) Founder Corporation.2005'; code from these 3 companies was used.

And then you have these strange strings: 'CTL:N0MAD|PDE0.DPMP.' and '1sN0TM3D az u~may th1nk*Creative Zen Vision:M'.

Could the last one be another encryption key, zook?
Title: Re: Creative Zen Vision:M
Post by: zook on November 11, 2007, 02:03:42 PM

Great work zook!  :D

Thanks :)


If you look at some strings in FRESC, you see that some files (devopen.c, devdraw.c, font_freetype2.c, fblin16.c, ...) are the same as in http://svn.neurostechnology.com/listing.php?repname=Nano-X&path=%2Ftrunk%2F&rev=4&sc=1
So they are using the MicroWindows (Nano-X) engine.

Cool, that'll give us something to compare against once we start digging into the OS structure.


According to 'Copyright MGC 2004 - Nucleus PLUS - ARM925 TI v. 1.14',  'Accelerated Technology Internal Use Only - Serial Number: NP0000' and 'Copyright(c) Founder Corporation.2005'; code from these 3 companies was used.

And then you have these strange strings: 'CTL:N0MAD|PDE0.DPMP.' and '1sN0TM3D az u~may th1nk*Creative Zen Vision:M'.

Could the last one be another encryption key, zook?

Yeah, it is.

There's two area's of interest at the moment.

The functions related to the player software (Jukebox2.jrm) decryption:
0099CD88                         load_jukebox
0099B960                         cenc_decode
0099E4C4                         blowfish_setiv
0099E4D0                         blowfish_encrypt
0099E5A8                         blowfish_setkey
0099E6A4                         blowfish_decrypt

And the functions related to the NULL signature check:
0099C104                         store_ugrade
0091060C                         SHA1_Init
00910530                         SHA1_Update
00910644                         SHA1_Final

There's one thing you should note, the segment starting at 0x1C00000 contains an array of address mappings. It starts with a length, followed by an address followed by 'length' bytes. The bytes should be written to 'address'. The jukebox2.jrm key is stored in one of these mappings, which is why it's not referenced anywhere.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on November 11, 2007, 02:23:01 PM
Just a thought:
you said the NULL signature is SHA-1 but used as MAC. Did you already find out which MAC it is? Because this page (http://www.mentor.com/products/embedded_software/nucleus_rtos/security/index.cfm) (scroll down to 'Nucleus Solutions' and press 4) states that they implement HMAC-SHA-1

edit:

look at http://tools.ietf.org/html/rfc4634#page-77 and look at 0099D2A4 in IDA: do you see any similarity?
Title: Re: Creative Zen Vision:M
Post by: zook on November 11, 2007, 03:13:41 PM
I've got some lost time to catch up on after spending most of the weekend on this :)

I didn't have a particular MAC algorithm in mind. I had only looked briefly at the code.
The source code you pasted does fit the bill: (nice job on finding that)
0099D1B8                         hmacInput
0099D1BC                         hmacReset
0099D2A4                         hmacResult

So all we need now is the key fed into hmacReset.

EDIT: Try "CTL:N0MAD|PDE0.DPMP." if you get a chance.
"CTL:N0MAD|PDE0.DPMP." is the key and HMAC-SHA1 is the algorithm used.

I've been working on the utilities needed to automate firmware modification and upgrading.
I'll add this weekend's results to the package and upload it, when I get time.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on November 11, 2007, 05:52:15 PM
Well, so far the only thing I can upload is modified strings; I can't add data to the firmware.

If I add some data (i.e. I replace HSplash.jbm with some other file) I have to update it's Size in the block, the total size of CIFF and the NULL block. Even if I do so, the ZVM still gives me an 'SendObject: Operation failed, response = MTP_RESPONSECODE_ACCESSDENIED'

Although this has nothing to do with the algorithm, this still is an obstruction in getting code on it.

edit:
I used this (http://www.slavasoft.com/zip/hashcalc.zip) program to calculate the hash.
To calculate a hash: calculate it only of the CIFF block (so excluding the NULL block), use SHA1 and as HMAC: "CTL:N0MAD|PDE0.DPMP."

UPDATE:
You got to add some padding (I added 4 extra bytes and that did the job), then it will accept your firmware.
Title: Re: Creative Zen Vision:M
Post by: wesmo on November 12, 2007, 07:55:36 PM
Awesome work there mcuelenaere and zook :D

Once zooks firmware utilities are up and running whats next?

err if creative has modified nano-x  dramatically we should be able to get their original source http://www.microwindows.org/faq.html
Title: Re: Creative Zen Vision:M
Post by: mitch04 on November 13, 2007, 06:14:10 AM
everytime I open device it says OpenDevice: Operation failed, details: The system cannot find the file specified. (Exception from HRESULT: 0x80070002)

I got Windows vista and im pritty sure I did the device manager right. but when i ran mtpinfup.exe it comes up then goes back down and looks like i can see an error in that 1sec. any help would be great
thanks
Title: Re: Creative Zen Vision:M
Post by: Bagder on November 13, 2007, 06:18:08 AM

err if creative has modified nano-x  dramatically we should be able to get their original source http://www.microwindows.org/faq.html


This thread is about porting Rockbox and Rockbox certainly doesn't use nano-x...
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on November 13, 2007, 12:58:25 PM

everytime I open device it says OpenDevice: Operation failed, details: The system cannot find the file specified. (Exception from HRESULT: 0x80070002)

I got Windows vista and im pritty sure I did the device manager right. but when i ran mtpinfup.exe it comes up then goes back down and looks like i can see an error in that 1sec. any help would be great
thanks

If you have UAC enabled, run the program elevated i.e. run it with administrative rights (as stated in the manual)
Title: Re: Creative Zen Vision:M
Post by: zook on November 13, 2007, 02:40:59 PM

Awesome work there mcuelenaere and zook :D

Once zooks firmware utilities are up and running whats next?

err if creative has modified nano-x  dramatically we should be able to get their original source http://www.microwindows.org/faq.html

The short-term goal is to get a build tool chain up and running.
Once that's ready, the actual porting process can begin.
Which I think entails writing a bootloader, working out (reversing/reading specs) how the various devices work and writing the code to integrate them into the rockbox source.
But I have yet to look into the rockbox source, so I have no idea how much work is generally involved.
I'll have plenty of reading up, on various subjects, ahead of me. This is still new ground to me.
Title: Re: Creative Zen Vision:M
Post by: Bagder on November 13, 2007, 04:22:27 PM

The short-term goal is to get a build tool chain up and running.


If you get the rockbox sources, running the tools/rockboxdev.sh (and select arm) should be enough...

Quote

Once that's ready, the actual porting process can begin.
Which I think entails writing a bootloader, working out (reversing/reading specs) how the various devices work and writing the code to integrate them into the rockbox source.
But I have yet to look into the rockbox source, so I have no idea how much work is generally involved.


There's really no "generally" here since it all depends on the particular hardware, what has been done on this or very similar hardware before and how fluent the people doing it are in these things.

Since the main SoC is the same one the mrobe500 uses, I figure some inspiration can be gotten from there.

BTW, given that you seem to start figuring out the file format for firmware upgrades, do you know if or how you can restore back to a sane environment if you upgrade to a totally broken firmware (like for example your own attempts) ?
Title: Re: Creative Zen Vision:M
Post by: zook on November 13, 2007, 05:08:03 PM

First: Congratulations! Great work zook and mcuelenaere!
I followed this thread for half a year now and am quite happy that you finally made it.
Now i wanted to ask, if there already is some (rather easy) work to do. I'm quite motivated, but my programming knowledge doesn't go far beyond basic delphi skills and even less in C. If there is anything which is possible to learn in a few weeks, i would like to help.

I can't think of anything suitable. A good grasp of C is required at this point.




The short-term goal is to get a build tool chain up and running.


If you get the rockbox sources, running the tools/rockboxdev.sh (and select arm) should be enough...

I should probably have been more clear. Regardless of how rockbox works, we'll need to produce a firmware archive, which contains an executable in the specific file format which creative players use. This is what I mean't by build tools.


Quote

Once that's ready, the actual porting process can begin.
Which I think entails writing a bootloader, working out (reversing/reading specs) how the various devices work and writing the code to integrate them into the rockbox source.
But I have yet to look into the rockbox source, so I have no idea how much work is generally involved.


There's really no "generally" here since it all depends on the particular hardware, what has been done on this or very similar hardware before and how fluent the people doing it are in these things.

OK. I just wanted to address the anticipation that some people might have.


Since the main SoC is the same one the mrobe500 uses, I figure some inspiration can be gotten from there.

Thanks, I didn't know that.


BTW, given that you seem to start figuring out the file format for firmware upgrades, do you know if or how you can restore back to a sane environment if you upgrade to a totally broken firmware (like for example your own attempts) ?

Yes. The bootloading of the player software is split into 3 phases:
1) The built-in boot loading, which loads a limited sized secondary boot loader from a fixed location in flash memory, to a fixed address.
2) The secondary boot loader (named FBOOT in the firmware) which decrypts and loads the Rescue Mode software (FRESC) also from flash memory.
3) The Rescue Mode software decrypts, decompresses and loads the actual player software (CENC/TL) from a file named Jukebox2.jrm on the HDD. If the validation checks fail, it'll load a Resuce Mode menu, which allows you to "reload" the firmware amongst other things.

I've described the file formats, hashing, compression and encryptions algorithms involved in the process. However, the information is a bit scattered around at the moment.

Anyway, you've got a way of recovering as long as you don't corrupt the code in flash.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on November 14, 2007, 02:52:02 PM
http://rapidshare.com/files/69725358/sendfile.c

This file is a modified libmtp example file, which should upload a firmware correctly.
Only problem is I can't compile it (cygwin complains about missing libiconv and when I installed it, it still complains)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on November 18, 2007, 11:39:23 AM
TI releases free c54x compiler!!
http://open.neurostechnology.com/node/1020

P.S.: wiki is updated
Title: Re: Creative Zen Vision:M
Post by: iSE on November 20, 2007, 12:21:33 PM
First off, congrats, its bin a while since I've checked up on this and it seems like I've missed out on a lot!  :D

If the source code were modified, for arguments sake so that rockbox handles the player controls correctly, would the compilation be required to take place onboard the Zen itself, or would an easier way be to compile it using the correct tool chain and then transferring it?

Second, I cannot recall if anyone has managed to dump the flash memory data. If this were altered causing it to brick the player, could this be flashed with the original dump? I ask this as a precaution for testing purposes giving us another avenue.

As I understand, its not a simple matter of uploading the firmware using the correct checksum. If the bootloader calls upon different files on the HDD, each encrypted and compressed in a different way, I am assuming that the bootloader has become the main focus in order to configure it to correctly load the rockbox firmware (once properly modified for the Zen)? Is it also correct that this bootloader (located at FBOOT) is ARM code?

Also, in your opinion, what is the next step?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on November 20, 2007, 12:30:21 PM
First off, congrats, its bin a while since I've checked up on this and it seems like I've missed out on a lot!  :D

If the source code were modified, for arguments sake so that rockbox handles the player controls correctly, would the compilation be required to take place onboard the Zen itself, or would an easier way be to compile it using the correct tool chain and then transferring it?

Are you saying that Rockbox should get compiled on the player itself? Because I don't think this is needed, ARM compilers are available everywhere and just recently Creative released a free-of-charge C54x compiler; so there shouldn't be any toolchain problems.
Quote
Second, I cannot recall if anyone has managed to dump the flash memory data. If this were altered causing it to brick the player, could this be flashed with the original dump? I ask this as a precaution for testing purposes giving us another avenue.

To do this, we should know a way of accessing the flash chip, reading its contents and writing to it. I don't think this is really necessary, but it could be a precaution we could take.
Quote
As I understand, its not a simple matter of uploading the firmware using the correct checksum. If the bootloader calls upon different files on the HDD, each encrypted and compressed in a different way, I am assuming that the bootloader has become the main focus in order to configure it to correctly load the rockbox firmware (once properly modified for the Zen)? Is it also correct that this bootloader (located at FBOOT) is ARM code?

Also, in your opinion, what is the next step?

I think we should decode the CENC block, analyze it (figure out LCD driver code, button driver, etc...) and rebuild the CENC block with our own code so the flash data isn't harmed (and the player couldn't get screwed up). I think this is the best (current) solution for running our own code on the player.
Title: Re: Creative Zen Vision:M
Post by: linuxstb on November 20, 2007, 12:44:48 PM

just recently Creative released an open-source C54x compiler;


Not quite - Texas Instruments released a closed-source C54x compiler which can be used free-of-charge for developing open source software:

http://open.neurostechnology.com/node/1020
Title: Re: Creative Zen Vision:M
Post by: iSE on November 20, 2007, 01:27:08 PM

I think we should decode the CENC block, analyze it (figure out LCD driver code, button driver, etc...) and rebuild the CENC block with our own code so the flash data isn't harmed (and the player couldn't get screwed up). I think this is the best (current) solution for running our own code on the player.


Ok so (i apologise for my lack of understanding if I am incorrect, I am trying to get my head round the whole thing again lol), the CENC block within nk.bin is the actual player software. This is ecrypted and compressed, and is accessible by the rescue mode (FRESC).

Now as I understand it, both FBOOT and FRESC are contained in nk.bin, and so the flash memory is altered at every upgrade? I read a few posts back that Zook said the earlier firmware had less ecryption (my apologies if this is incorrect), and so assuming that to be true, should we not use the FBOOT and FRESC from an earlier firmware model in order to decrypt that archives CENC block?

I understand the need for being able to understand the CENC block, how the components interact etc, however, rebuilding and coding our own is the part I am confused on. It was my understanding that could we properly configure the Rockbox firmware, and get FRESC to load it correctly, that the Jukebox2.jrm file would become obsolete?
Title: Re: Creative Zen Vision:M
Post by: NicolasP on November 22, 2007, 01:13:22 PM
Hello,
I committed a custom firmware update utility for the Gigabeat S, based on the sendfile.c file that mcuelenaere posted earlier. I've only tested it on the Gigabeat and it works fine. However, mcuelenaere told me it has the same update process as the ZVM, so I'm hoping my tool will work on the ZVM too... Could someone confirm? The tool is in the utils/MTP directory of the SVN repository.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on November 22, 2007, 02:54:25 PM

Hello,
I committed a custom firmware update utility for the Gigabeat S, based on the sendfile.c file that mcuelenaere posted earlier. I've only tested it on the Gigabeat and it works fine. However, mcuelenaere told me it has the same update process as the ZVM, so I'm hoping my tool will work on the ZVM too... Could someone confirm? The tool is in the utils/MTP directory of the SVN repository.

I've (finally) got it to compile in cygwin, but libmtp doesn't recognize my ZVM :(
So, maybe whenever I will install linux, I'll test it but I'm pretty sure that it will work (if it works with the Gigabeat, it should also work with the ZVM)

edit:
shouldn't in the Makefile
Code: [Select]
LIBS = -lmtp be
Code: [Select]
LIBS = -llibmtp ?
Because this one worked in cygwin, and I suppose the library is called libmtp and not mtp?
Title: Re: Creative Zen Vision:M
Post by: GodEater on November 23, 2007, 05:55:36 AM

edit:
shouldn't in the Makefile
Code: [Select]
LIBS = -lmtp be
Code: [Select]
LIBS = -llibmtp ?
Because this one worked in cygwin, and I suppose the library is called libmtp and not mtp?


Can't speak for cygwin, but no - that's not what it should be for any other POSIX based system. Nico's is right for Linux certainly.
Title: Re: Creative Zen Vision:M
Post by: bobbaluba on November 24, 2007, 07:18:15 AM
Hi. I'm not very skilled in programming yet, so i don't think I am able to help with rockbox. But I've created a small program, which you might find useful.
It calculates the correct checksum of the CIFF block, and replaces the existing one in the null block.

http://bananweb.mine.nu/filer/nullblockfixerMKII.zip
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on November 28, 2007, 11:27:26 AM
So the LT© block is firstly encrypted using Blowfish in CBC mode with key '1sN0TM3D az u~may th1nk*Creative Zen Vision:M'.
After this, it is decoded using the compression/encoding of CENC (zook documented it in his zenfirm utility source code).

Only problem is: I can't seem to decrypt the block correctly (probably because my first IV isn't set correctly) so I'm kinda stuck right now.

zook, you know the most of the encryptions used in the firmware, did you already decode LT© ?
If not, can you help me decrypting the file?
Title: Re: Creative Zen Vision:M
Post by: zook on December 02, 2007, 01:33:38 PM
I've been a bit busy, however I've just added zenutils (http://www.rockbox.org/twiki/bin/viewfile/Main/CreativeZVMPort?rev=1;filename=zenutils.zip) to the wiki.
The package contains all the utilities needed to produce firmware archives with executable code in them.
I haven't had time to document their usage, so you'll have to read the help screens for instructions.
Title: Re: Creative Zen Vision:M
Post by: sejerpz on December 02, 2007, 08:44:42 PM
Very nice work! Thank you!
This is my first day here and you (all of you) have made a great work.
I've made some experiments based on your code with my Zen 4GB (not the vision).
From what I've seen everything in the firmware is the same (but nk.bin lacks the FBOOT field).
This afternoon I've ported some of your windows versions, and I manage to extract and flash my device reliabily.
Some hour ago I compiled your new zenutils in my linux box, zen_crypt failed just because stricmp in linux is strcasecmp, but everything else worked and even zen_crypt with the correction worked well.

So I've tryed to guess the encription key and I was lucky.

The Zen 4GB keys for the TL record and for the HMAC-SHA1 are:
HMAC: CTL:Z3N07|PDE0.DPMP.
TL: 1sN0TM3D az u~may th1nk*Creative ZEN

I'm sorry, but the most difficult key still remain unknown (FRESC)

Attached a patch to zenutils/zen_crypt

Bye,
Andrea

P.S.
Zook mind the #if since I never use cmake...
Title: Re: Creative Zen Vision:M
Post by: Falafel on December 03, 2007, 02:18:25 AM
Sorry to ask, but could someone add a zenvision playerconstant to zencrypt? I tried to but had trouble compiling it (probably because of my ignorance, but still)
the TL key is: 1sN0TM3D az u~may th1nk*Creative Zen Vision
Title: Re: Creative Zen Vision:M
Post by: bobbbaluba on December 06, 2007, 12:13:22 PM
I know I shouldn't ask about progress all the time, but has anyone looked at the TL block yet?
Does anyone understand what it does, and how it works?

I looked through the file, and i noticed some filenames i don't think anyone has mentioned yet.
One of them was called jukebox.hds, and is not present in any of the firmware archives. Looks like this is some kind of file that just is in the firmware when you get it from the store. Any idea what it does?

Another files are jukebox2.jrm and Creative_L.h

I also have some problems upgrading my player after i have decrypted and encrypted the TL block. If I leave it alone, everything works smooth.
Great tool, zook!
Title: Re: Creative Zen Vision:M
Post by: zook on December 07, 2007, 09:29:53 AM

This afternoon I've ported some of your windows versions, and I manage to extract and flash my device reliabily.
Some hour ago I compiled your new zenutils in my linux box, zen_crypt failed just because stricmp in linux is strcasecmp, but everything else worked and even zen_crypt with the correction worked well.

Ohh, I thought supporting cygwin would implicitly include linux. I've been meaning to install ubuntu for a while, so I'll have a look at it when I get around to it.


I'm sorry, but the most difficult key still remain unknown (FRESC)

FRESC on the Zen player uses a different file format than all the other players I've looked at.
Maybe decryption will work if you offset it by the 0x70 bytes header.



Sorry to ask, but could someone add a zenvision playerconstant to zencrypt? I tried to but had trouble compiling it (probably because of my ignorance, but still)
the TL key is: 1sN0TM3D az u~may th1nk*Creative Zen Vision

I'll add it this weekend, along with a few other fixes.



I know I shouldn't ask about progress all the time, but has anyone looked at the TL block yet?
Does anyone understand what it does, and how it works?

Yes. Most of my time lately has been spent reading and commenting it.

FBOOT contains a bootloader (stored in flash) which get's loaded by the on-chip bootloader.
When FBOOT executes, it decrypts and loads FRESC.
FRESC contains the Rescue Mode software (stored in flash).
When FRESC executes, it does a series of tests to determine if it needs to execute the Rescue Mode menu or decrypt and load Jukebox2.jrm.
TL contains the Player Mode software (stored as Jukebox2.jrm on the HDD).
TL, like FRESC, includes the Nucleus RTOS, making them self-contained. The fileformat used for both is what I've described as the FRESCUE Structure (http://www.rockbox.org/twiki/bin/view/Main/DellDJPort#FRESCUE_Structure) on the DellDJPort wiki.


I looked through the file, and i noticed some filenames i don't think anyone has mentioned yet.
One of them was called jukebox.hds, and is not present in any of the firmware archives. Looks like this is some kind of file that just is in the firmware when you get it from the store. Any idea what it does?

I haven't looked into the meat of the filesystem, however the bit's i've seen does resemble what's described here (http://www.nomadness.net/modules.php?name=Forums&file=viewtopic&t=18515).
At any rate there's dozen's of files which are only created and used internally.
Presumably they're using a meta file system which is layered on top of the underlaying filesystem provided by whatever RTOS they've used (Nucleus on the Vision:M, TI DSP/BIOS on the elder players).


I also have some problems upgrading my player after i have decrypted and encrypted the TL block. If I leave it alone, everything works smooth.

Hmm, did you update the null signature after you created the archive?
I'll be able to test the updater some time next week. So far I've had to rely on testing the tools against each other.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on December 07, 2007, 04:48:14 PM

...

Yes. Most of my time lately has been spent reading and commenting it.
...

I've been doing the same, maybe we could share our findings?
Some of the naming of the functions aren't correct at all, but all the png_*, Gd*, linear16*, freetype2 and memcpy & co are correct (I verified them against the (open) source code)
Code: [Select]
Start         Length     Name                   Class
 0001:00000000 000003510H seg000                 DATA
 0002:00000000 000000068H seg001                 DATA
 0001:00000000 00000B046H seg002                 DATA
 0003:00000000 0001E6BE0H seg003                 DATA
 0004:00000000 000000E10H seg004                 DATA
 0005:00000000 000010054H seg005                 DATA
 0006:00000000 000067FB8H seg006                 DATA
 0007:00000000 00004B464H seg007                 DATA
 
 Address             Publics by Value
 0001:00000000       start
 0001:00000040       boot_2
 0003:00000000       interrupts____
 0003:0000146C       usb_mode
 0003:000024A0       interrupts___
 0003:00016158       minifs_related
 0003:00016794       mass_used_2
 0003:00016BE4       mass_used
 0003:0001704C       poss_fwrite
 0003:00017318       fread
 0003:0001738C       minifs_related_2
 0003:00017570       fopen
 0003:000177A4       fclose
 0003:00017DE4       VFAT_something
 0003:00038D4C       malloc
 0003:000391F8       free
 0003:0003C0D0       system
 0003:0003DF88       kernelobject__
 0003:0003EEF4       special___
 0003:0003EF24       fclose_2___
 0003:0003EFAC       fopen_2___
 0003:0003F124       jukebox_grs_GROUP_parser
 0003:0003F22C       move_4_forward
 0003:0003F238       move_8_forward
 0003:0003F254       mass_used_3
 0003:00040200       HDD_and_VFAT_something
 0003:00040C18       winmgr_object__
 0003:00041948       HW___
 0003:00041958       interrupts
 0003:0004253C       init_all
 0003:00042968       f_____write___2
 0003:000434DC       SYSTEM_H__
 0003:00043C44       load_messages_and_start
 0003:0004420C       loadcopyrightaccelerated
 0003:00044248       loadcopyrightMGC
 0003:000451B8       farfree
 0003:00045200       farmalloc
 0003:0004524C       png_malloc_default
 0003:000454C4       png_free_default
 0003:00048EC8       memcpy
 0003:000496C4       mwdrawing
 0003:00049E00       memset
 0003:0004A438       strncpy
 0003:0004A5BC       memcmp
 0003:0004A708       strcpy
 0003:0004A724       strlen
 0003:0004B06C       FT_MulFix
 0003:0004E8D4       FT_New_Memory_Face
 0003:0004E98C       FT_New_Face
 0003:000C4A28       parsejukebox_opt
 0003:000C5EC4       init_rtc0_and_video0
 0003:000C6A38       system_boot
 0003:000DA264       enc_engine
 0003:000DB498       enc_engine2
 0003:001027B8       used_in_kobjects
 0003:00102850       initjukebox_opt
 0003:00102958       system_boot_caller
 0003:001168C0       init_wallpaper
 0003:00116A70       init_wallpaper_and___
 0003:0011B4F0       j_fread
 0003:0011C26C       png_read_transform_info
 0003:0011F46C       png_do_read_transformations
 0003:0011F8BC       png_do_read_intrapixel
 0003:0011FA60       png_read_start_row
 0003:0011FD38       png_crc_read
 0003:0011FDF8       png_crc_finish
 0003:0011FEC8       png_get_uint_32
 0003:0011FF24       png_read_finish_row
 0003:00120224       png_read_filter_row
 0003:0012044C       png_decompress_chunk
 0003:00120778       png_handle_unknown
 0003:00120B04       png_handle_zTXt
 0003:00120D20       png_handle_tRNS
 0003:00120F34       png_handle_tEXt
 0003:00121164       png_handle_sRGB
 0003:001214AC       png_handle_sPLT
 0003:001217B4       png_handle_sCAL
 0003:001219CC       png_handle_sBIT
 0003:00121B68       png_handle_pHYs
 0003:00121DA0       png_handle_pCAL
 0003:00122034       png_handle_oFFs
 0003:0012219C       png_handle_iCCP
 0003:00122460       png_handle_hIST
 0003:0012260C       png_handle_gAMA
 0003:00122928       png_handle_cHRM
 0003:00122D84       png_handle_bKGD
 0003:0012309C       png_handle_PLTE
 0003:00123284       png_handle_IHDR
 0003:00123410       png_handle_IEND
 0003:0012396C       png_combine_row
 0003:001297B4       linear16_stretchblit
 0003:00129D6C       linear16_readpixel
 0003:0012B01C       linear16_drawarea
 0003:0012B520       linear16_blit
 0003:0012BF10       GdBlit
 0003:0012C2D8       GdStretchBlitEx
 0003:0012C788       GdStretchBlit
 0003:001307E8       j_malloc
 0003:001307F0       j_free_0
 0003:0013E9A4       inflateReset
 0003:0013EE3C       inflateEnd
 0003:0013F060       inflate
 0003:001404EC       png_read_update_info
 0003:0014056C       png_read_row
 0003:00140AD4       png_read_info
 0003:00140FF8       png_read_image
 0003:00141088       png_read_end
 0003:00141524       png_read_png
 0003:001416FC       png_read_init_3
 0003:00141868       png_read_init_2
 0003:001418E0       png_read_init
 0003:0014198C       png_read_destroy
 0003:00141CDC       png_destroy_read_struct
 0003:001423CC       f_____3
 0003:00142F68       create_3_CLASS
 0003:00148B88       freetype2_gettextsize_fast
 0003:00148DAC       freetype2_gettextsize_rotated
 0003:00149018       freetype2_gettextsize
 0003:001490C4       freetype2_getfontinfo
 0003:00149278       freetype2_face_requester
 0003:0014CCB4       png_set_unknown_chunks
 0003:0014CE10       png_set_text_2
 0003:0014D3D0       png_set_sPLT
 0003:00158330       Creative_L_h__
 0003:00158B34       load_wallpaper
 0003:00160A00       png_zfree
 0003:00160A04       png_zalloc
 0003:00160A5C       png_sig_cmp
 0003:00160AB0       pngsignature
 0003:00160AE4       png_reset_crc
 0003:00161000       png_info_destroy
 0003:00161118       png_data_freer
 0003:00161980       initialize_winmgr
 0003:00168170       png_set_interlace_handling
 0003:0016EC80       GdFixCursor
 0003:0016ECB0       GdCheckCursor
 0003:0016F82C       GdClipArea
 0003:00170D88       create_CLASS
 0003:00170DA4       create_2_CLASS
 0003:00172AC0       initmemgc
 0003:001732F4       Creative_L_h
 0003:00173994       png_warning
 0003:00173A24       png_default_error
 0003:00173A34       png_error
 0003:0017407C       png_memcpy_check
 0003:001740B8       png_malloc
 0003:00174114       png_malloc_warn
 0003:00174158       png_free
 0003:001741C4       png_destroy_struct
 0003:00174248       png_create_struct
 0003:0017650C       png_set_read_fn
 0003:00176550       png_read_data
 0003:0017786C       j_mass_mass_used_malloc__
 0003:00177870       j_free
 0003:001A7E64       parsevideofile
 0003:001A8B34       determinefiletype
Title: Re: Creative Zen Vision:M
Post by: zook on December 09, 2007, 11:42:23 AM


...

Yes. Most of my time lately has been spent reading and commenting it.
...

I've been doing the same, maybe we could share our findings?
Some of the naming of the functions aren't correct at all, but all the png_*, Gd*, linear16*, freetype2 and memcpy & co are correct (I verified them against the (open) source code)

Here's a few different scripts I've been using: idc_utils (http://www.mediafire.com/?8sjdnugutzd)
load.idc - maps tms320dm320 peripheral registers, maps the "user data" starting at 0x1C00004, loads names from a txt file.
save.idc - saves non-autogenerated function names to a txt file.
zook.txt - contains the result of running save.idc against my idb.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on December 16, 2007, 07:28:53 AM
@zook:
I'm having trouble decrypting the ZVM 60GB TL block, I'm always getting 'Failed to decrypt the input file'. (I'm using your binaries)

I haven't custom compiled the source so I could see the exception, but I will later maybe; I just thought I should report it.

BTW, the key is "1sN0TM3D az u~may th1nk*Creative ZEN Vision:M (DVP-HD0004)"

edit:
I'm also having trouble extracting the firmware out of the Zen Vision W's executable. The key is '34d12GC61e9ggF2C6dc114596666926' and firmware_extract gives me this:
Code: [Select]
c:\zen\zvw>update_extract -u ZENVisionW_PCFW_P4S_L20_1_10_01.exe -V
[*] Looking for firmware archive key...
[*] Looking for firmware archive offset...
[*] Printing input variables...
    Updater executable:  ZENVisionW_PCFW_P4S_L20_1_10_01.exe
    Firmware archive:    ZENVisionW_PCFW_P4S_L20_1_10_01_rk.bin
      Key:               34d12GC61e9ggF2C6dc114596666926
      Offset:            0x0005d0c0
      Size:              0x00eea7c0
[*] Reading firmware archive...
[*] Decrypting firmware archive...
[*] Decompressing firmware archive...
Failed to decompress the firmware archive.
Title: Re: Creative Zen Vision:M
Post by: sejerpz on December 17, 2007, 12:28:52 PM
Quote

Zook:

FRESC on the Zen player uses a different file format than all the other players I've looked at.
Maybe decryption will work if you offset it by the 0x70 bytes header.


No luck, tried a lot of keys, but nothing.

I don't know if I understand it correctly, but I've first to decrypt the FRESC and *than* decode using CENC?
Will give another try this night.

Bye.
Title: Re: Creative Zen Vision:M
Post by: wesmo on December 19, 2007, 08:38:51 PM
I think we need to clean up the wiki information about all creative ports - there seems to be info scattered on 5 pages:

http://www.rockbox.org/twiki/bin/view/Main/CreativeZenTouch - Zen Xtra/NJB3/Touch info
http://www.rockbox.org/twiki/bin/view/Main/CreativeZVMPort - most current page
http://www.rockbox.org/twiki/bin/view/Main/DellDJPort - based on zen xtra
http://www.rockbox.org/twiki/bin/view/Main/OtherTargets - nano/nano plus info
http://www.rockbox.org/twiki/bin/view/Main/NJB3Firmware - firmware page (outdated)

I might give this a shot today - check over at  http://www.rockbox.org/twiki/bin/view/Main/Creative - ill try and have something semi functional today - my plan is to incorporate all current firmware info on one page and keep the exist port pages for scans and part info - any other opinions?

If anyone has some spare time. did you want to check out the remaining firmwares we haven't looked at - i think we can smart guess most of them? I reckon anything before Creative Zen Vision W -> NJB1 will have keys "1sN0TM3D az u~may th1nk*INSERT NAME HERE"

Product names used are listed here http://www.rockbox.org/twiki/bin/view/Main/CreativeZenTouch#Creative_Series_3_NJB3_Info  , http://en.wikipedia.org/wiki/Creative_Nomad and http://en.wikipedia.org/wiki/Creative_ZEN
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on January 01, 2008, 11:22:29 AM

...

edit:
I'm also having trouble extracting the firmware out of the Zen Vision W's executable. The key is '34d12GC61e9ggF2C6dc114596666926' and firmware_extract gives me this:

...

Next to the Zen Vision W firmware, the Zen V doesn't work either:
Code: [Select]
C:\zen>update_extract -u ZENV_PCFW_L22_1_32_01.exe -V
[*] Looking for firmware archive key...
[*] Looking for firmware archive offset...
[*] Printing input variables...
    Updater executable:  ZENV_PCFW_L22_1_32_01.exe
    Firmware archive:    ZENV_PCFW_L22_1_32_01_rk.bin
      Key:               34d12G399fc29D25669g616119143
      Offset:            0x0006fb70
      Size:              0x0036e18b
[*] Reading firmware archive...
[*] Decrypting firmware archive...
[*] Decompressing firmware archive...
Failed to decompress the firmware archive.
Title: Re: Creative Zen Vision:M
Post by: bobbaluba on January 12, 2008, 06:03:17 AM
I'm having some trouble using the zenutils by zook.
They worked great on my old computer, but on the other computers it doesn't work.

I get the extremely inhelpful error message:

C:\zen\bin>zen_crypt
Systemet kan ikke kjore angitt program.

Which means: System cannot run the specified program.

Any ideas?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on January 12, 2008, 06:17:58 AM

I'm having some trouble using the zenutils by zook.
They worked great on my old computer, but on the other computers it doesn't work.

I get the extremely inhelpful error message:

C:\zen\bin>zen_crypt
Systemet kan ikke kjore angitt program.

Which means: System cannot run the specified program.

Any ideas?

Which OS are you using? What is in your %PATH%? Did you already tried compiling the source yourself?
Title: Re: Creative Zen Vision:M
Post by: shotofadds on January 19, 2008, 03:41:22 PM
According to the Vision:M wiki page, the LCD panel is marked with the letters "V250QV", if that's the case its almost certainly in the same family as the LCD used in the Cowon D2:
 
http://www.neodns.co.kr/specpdf/tft/xLTV250QV-F0B.pdf

The datasheet gives details of the necessary power-up and power-down sequences, which you might be able to locate in the original firmware (locating those was the starting point for the D2 port).

The LTV250QV contains an S6F2002 LCD controller chip, but no information on this has been found yet. On the D2 this wasn't a problem, as the TCC7801 SoC provides its own interface to the LCD controller.

EDIT: Also bear in mind you will need to establish how to control the backlight - this screen isn't visibile at all unless the backlight is turned on.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on January 20, 2008, 05:21:45 AM

According to the Vision:M wiki page, the LCD panel is marked with the letters "V250QV", if that's the case its almost certainly in the same family as the LCD used in the Cowon D2:
 
http://www.neodns.co.kr/specpdf/tft/xLTV250QV-F0B.pdf

The datasheet gives details of the necessary power-up and power-down sequences, which you might be able to locate in the original firmware (locating those was the starting point for the D2 port).

The LTV250QV contains an S6F2002 LCD controller chip, but no information on this has been found yet. On the D2 this wasn't a problem, as the TCC7801 SoC provides its own interface to the LCD controller.

EDIT: Also bear in mind you will need to establish how to control the backlight - this screen isn't visibile at all unless the backlight is turned on.

Fantastic shotofadds! I will look into it...
Title: Re: Creative Zen Vision:M
Post by: scharkalvin on January 22, 2008, 07:51:58 AM
Is this one of the Zen players being worked on?
http://www.geeks.com/details.asp?invtid=DAP-HD0018-N&cat=MP3
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on January 22, 2008, 09:52:49 AM

Is this one of the Zen players being worked on?
http://www.geeks.com/details.asp?invtid=DAP-HD0018-N&cat=MP3

Not really, but as it uses the same firmware format (and the same OS) as the ZVM, it won't be very hard to make a new port to this one.

edit:
wiki is updated; some of the bootup progress of the firmware is documented
Title: Re: Creative Zen Vision:M
Post by: bobbaluba on January 22, 2008, 04:22:55 PM


I'm having some trouble using the zenutils by zook.
They worked great on my old computer, but on the other computers it doesn't work.

I get the extremely inhelpful error message:

C:\zen\bin>zen_crypt
Systemet kan ikke kjore angitt program.

Which means: System cannot run the specified program.

Any ideas?

Which OS are you using? What is in your %PATH%? Did you already tried compiling the source yourself?

Yes, but i can't figure out how to use cmake.
This is my %path%:
C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem

EDIT: I'm running winxp sp2
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on January 22, 2008, 04:30:10 PM



I'm having some trouble using the zenutils by zook.
They worked great on my old computer, but on the other computers it doesn't work.

I get the extremely inhelpful error message:

C:\zen\bin>zen_crypt
Systemet kan ikke kjore angitt program.

Which means: System cannot run the specified program.

Any ideas?

Which OS are you using? What is in your %PATH%? Did you already tried compiling the source yourself?

Yes, but i can't figure out how to use cmake.
This is my %path%:
C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem

EDIT: I'm running winxp sp2

CMake is as simple as installing it, running an Command Shell and running
Code: [Select]
cmake -g "Visual Studio 8 2005" in the right folder.

Then you'd have to open up the zenutils.sln project and press Compile (it will give some warnings , if I remember correctly).

About the zen_crypt problem, are you sure it is in that directory (try 'dir' and see if zen_crypt.exe appears) and do you have the rights to execute it (since you're using WinXP, I suppose you're on an admin account so this couldn't be the problem)?
Title: Re: Creative Zen Vision:M
Post by: GothPanda on January 26, 2008, 06:34:05 PM
I recently discovered my creative to have a cracked screen, and even though the rest of the device is functioning, I can't make any real use out of it.  I was wondering, if I could donate it to the cause.  Will my screenless Zen Vision M help you in the mission of porting over the Rockbox?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on January 27, 2008, 04:49:19 AM

I recently discovered my creative to have a cracked screen, and even though the rest of the device is functioning, I can't make any real use out of it.  I was wondering, if I could donate it to the cause.  Will my screenless Zen Vision M help you in the mission of porting over the Rockbox?


If a Rockbox Developer is willing to accept it and is willing to work on it, it will help porting it over to Rockbox. Although it will be difficult because there's no screen. But I believe you can get replacement screens on the internet, although I haven't found them yet.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 07, 2008, 10:29:36 AM
I was just checking if zook's zenutils correctly encode/encrypt a decrypted TL block and it seems it doesn't. The problem lays in the CENC encoding routine, but as this goes far above my head so I can't do anything about it.

So development has (again) been stalled until another method is known to get code on the ZVM (I'm not going to use the FBOOT method if I'm not entirely sure that my code works).

If anyone who gots some experience with compression wants to take a look, all the files are on the wiki.

edit:
this is for people who want to do 'zen_crypt -e -m CENC':
in zen_crypt/source/main.cpp around line 352:
Code: [Select]
if (!shared::write_file(file, outbuf, sizeof(dword), len))
should be
Code: [Select]
if (!shared::write_file(file, outbuf, false, sizeof(dword), len))

edit2:
OK, so I was (partly) wrong: the CENC encoding used by zook is not the same as used by Creative, but it should be compatible (although at first sight it doesn't seem so on the ZVM).

edit3:
And as it seems, it isn't compatible; or I'm doing something wrong..

edit4:
Yeey! Great news! Apparantly there's a bypass: instead of using the TL block we can use an ordinary DATA block and set the filename to Hjukebox2.jrm and the OF then will skip the decryption and CENC decoding routine!
Title: Re: Creative Zen Vision:M
Post by: Falafel on February 10, 2008, 02:07:34 PM
This sounds like good news.
//But have you just reencoded the TL block?
edit: I should learn to read, but still. good news! Hope to hear more soon :)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 10, 2008, 02:44:19 PM

This sounds like good news.
//But have you just reencoded the TL block?
edit: I should learn to read, but still. good news! Hope to hear more soon :)

The rest is on the wiki (http://www.rockbox.org/twiki/bin/view/Main/CreativeZVMPort#Upload_Code_To_The_Player), but still I'm not there...
The problem now is the TL/FRESCUE structure; I've to find out how that one works. Luckily zook worked on that one a bit, but it isn't complete; so I can use any help I can get ;)
Title: Re: Creative Zen Vision:M
Post by: NicolasP on February 10, 2008, 03:09:09 PM
mcuelenaere: Are you able to run custom code on the ZVM?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 10, 2008, 03:16:17 PM

mcuelenaere: Are you able to run custom code on the ZVM?

No, not yet. I can't seem to find the code in the OF how jukebox2.jrm is parsed.
The structure is more or less described by zook at DellDJPort (http://www.rockbox.org/twiki/bin/view/Main/DellDJPort), but there are some unknown parts needed to get filled in and I can't figure them out atm.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 17, 2008, 07:56:26 AM
Finally I'm able to run code on my ZVM!  ;D

I haven't got a camera laying around here, so I can't proof anything, but I can upload the firmware I'm using (this is for a Creative ZVM 30GB).

After you've uploaded it, the player will hang on the ZEN screen, but it will display a green rectangle.

To delete the firmware, you'll have to boot in Rescue Mode and select Reload Firmware.


More will follow...

edit: question to Rockbox devs:
atm I'm not using the Rockbox source as base, but just my own C file; how is the printf() command implemented in Rockbox?


edit2: I'm trying to compile a bootloader, but I'm getting: 'ERROR: x uses FPA instructions, whereas y does not'
and other linker errors

edit3: found it, apparently -mcpu=arm926ej-s should be -mcpu=arm9 (or at least on my machine)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 17, 2008, 11:03:05 AM
Current diff with Rockbox tree
Title: Re: Creative Zen Vision:M
Post by: crzyboyster on February 17, 2008, 11:20:16 AM
Can we get a picture? And congrats, mcuelenaere! This should pave the way for the entire Creative family of players!
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 17, 2008, 11:57:58 AM
I'll see if I can find a camera somewhere.

Problem is: I can perfectly change anything on the LCD screen, but whenever I try to put a Rockbox binary on the device, it just goes immediately to black screen. Neither the RAM is touched nor the OSD variables, and I can't seem to find what the problem is ???

Does someone have a clue?

(attached is my diff to current SVN)
Title: Re: Creative Zen Vision:M
Post by: crzyboyster on February 17, 2008, 12:50:44 PM
How exactly did you achieve this "phenomenon"? I want to try something similar on my Zen V 2gb just to see how far this has progressed and whether or not the same green rectangle shows up on the Zen V.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 17, 2008, 12:54:08 PM

How exactly did you achieve this "phenomenon"? I want to try something similar on my Zen V 2gb just to see how far this has progressed and whether or not the same green rectangle shows up on the Zen V.

First of all, you certainly need to disassemble the original firmware (try using IDA if you use Windows, it's very helpful)
I don't know if this is totally the same on the Zen V (I think it is), but the OF reads jukebox2.jrm into certain memory parts (as described in its structure) and what I've done is (using the DM320 hardware OSD cursor) compiled a small program and tried getting it on my player; but this is getting a bit off topic ;)
Title: Re: Creative Zen Vision:M
Post by: crzyboyster on February 17, 2008, 01:00:33 PM
I don't think I can do all that as I can't compile or read/write code  :'(
I guess we should just wait for this to progress and then rockbox might get ported to the other Zen players...
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 17, 2008, 01:25:28 PM
I believe i've found the problem, but I can't (yet) solve it:
the OF loads the code at 0x000000, but Rockbox assumes it is somewhere in 0x900000.
It then loads the reset vectors from somewhere in SDRAM to 0x000000 and sets up stacks etc.
Then it jumps to main(), but it thinks this is (also) in 0x900000, so what I've got to do is figure out how to change the memory linking during compiling; I know it has something to do with boot.lds and apps.lds; but I can't figure out how.

Help? :)
Title: Re: Creative Zen Vision:M
Post by: Bagder on February 17, 2008, 02:01:11 PM
If you build the bootloader boot.lds is what tells on what physical addresses it should build the program to work on/with. That's a plain normal gnu ld script that's run through a C preprocessor first, thus the #ifdefs and #defines etc.

In your case it sems the boot.lds sets
#define DRAMORIG 0x00900000

... which I agree looks very weird and unlikely to match reality for any actual target.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 17, 2008, 02:05:56 PM

If you build the bootloader boot.lds is what tells on what physical addresses it should build the program to work on/with. That's a plain normal gnu ld script that's run through a C preprocessor first, thus the #ifdefs and #defines etc.

In your case it sems the boot.lds sets
#define DRAMORIG 0x00900000

... which I agree looks very weird and unlikely to match reality for any actual target.

Funny you post this now, because about 2 min. ago I sort of solved the problem :)
I saw that DRAMORIG was set to 0x900000 and tried setting it to 0x0; but that didn't work.
But since the OF includes some sort of specific loading (i.e. you say: load block x to address y and block a to address b etc; something like ELF format I presume?) I tried loading the Rockbox code to 0x900000 and 0x0 containing a LDR PC, =0x900000 and ... it works!

Although the LCD is giving me garbage (probably due to RGB<->YUV or something with x-bit), it works. (I'll attach the patch later)

edit: patch
Title: Re: Creative Zen Vision:M
Post by: Bagder on February 17, 2008, 04:03:55 PM
Cool!

If you could take a photo of the LCD perhaps someone recognizes the sympthom.

The patch is however incomplete as it refers to several files that aren't included. Like config-creativezvm.h and the ones in target/arm/tms320dm320/creative-zvm/

Update: also, the scramble.c patch adds a be2int() function that isn't used. Why?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 17, 2008, 04:09:00 PM
All LCD problems are solved, I'm currently working on figuring out the buttons (GPIO etc).

A diff will follow (I forgot to do 'svn add' on some files)

edit: added diff
If I forgot adding a file, please reply

edit2: nk.bin (http://www.verzend.be/v/1249170/nk.bin.html)

edit3: currently only LCD driver is working; for compiling: use Bootloader and it will output a rockbox.zvmboot file which you'll have to put in a CIFF structure (use CreativeWizard) with filename Hjukebox2.jrm and type set to DATA.

edit4: about the be2int() in scramble: that was for testing purposes, can be removed now; it is indeed not used anymore
Title: Re: Creative Zen Vision:M
Post by: shotofadds on February 18, 2008, 11:30:31 AM
Congratulations on gettting the LCD code up and running! It's good to see this progressing finally - maybe I'll even get my ZVM out of the cupboard one day when I'm bored with the D2....

One thing though: in your patch it looks like there's a lot of TCC780x code left over from the D2 driver: anything referring to LCDC_* is specific to the 7801 LCD controller and needs to be removed, since writing to those addresses on another target is probably not a good idea and will almost certainly bear no relation to what is needed (the same applies to PORTCFG, BCLKCTR etc).

But I'm sure you knew that already. ;)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 18, 2008, 12:22:56 PM

Congratulations on gettting the LCD code up and running! It's good to see this progressing finally - maybe I'll even get my ZVM out of the cupboard one day when I'm bored with the D2....

One thing though: in your patch it looks like there's a lot of TCC780x code left over from the D2 driver: anything referring to LCDC_* is specific to the 7801 LCD controller and needs to be removed, since writing to those addresses on another target is probably not a good idea and will almost certainly bear no relation to what is needed (the same applies to PORTCFG, BCLKCTR etc).

But I'm sure you knew that already. ;)

Thanks.

Yes I know, the code needs some cleanup. Actually I wasn't sure about the LCD Controller registers; I just left them there as something to base myself on.

About the pictures: I just made some (I know: most of them are bad quality and took with an unsteady hand), they're available here (http://rapidshare.com/files/92918920/100K4800.rar).
Title: Re: Creative Zen Vision:M
Post by: Bagder on February 18, 2008, 02:12:02 PM
I committed a small part of the patch now that seemed clean and not likely to cause troubles for anyone else.

Some parts of the remainder of the patch seems to modify stock dm320 code that isn't clean enough to commit. And then I'm not sure how valid the firmware/target/arm/tms320dm320/creative-zvm parts are.

Comments?

I just want to help getting the core vision:m stuff added so that more people can join in this effort and help easier.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 18, 2008, 02:24:28 PM

I committed a small part of the patch now that seemed clean and not likely to cause troubles for anyone else.

Some parts of the remainder of the patch seems to modify stock dm320 code that isn't clean enough to commit. And then I'm not sure how valid the firmware/target/arm/tms320dm320/creative-zvm parts are.

Comments?

I just want to help getting the core vision:m stuff added so that more people can join in this effort and help easier.

The only DM320 stuff I changed are in system-dm320.c (which I've enabled back since it doesn't cause any trouble) and in spi-dm320.c (which sets M:Robe 500 target specific GIO stuff and disables GIO stuff using spi_disable_all_targets() which isn't present at the ZVM and shouldn't be touched)

The main code at the moment is just for debugging purposes as I only have access to the LCD for now. As for the target/arm/tms320dm320/creative-zvm/ : these are just stubs so that Rockbox can compile (I haven't enabled these during boot in the bootloader).
Title: Re: Creative Zen Vision:M
Post by: Bagder on February 18, 2008, 04:56:32 PM

The only DM320 stuff I changed are in system-dm320.c (which I've enabled back since it doesn't cause any trouble) and in spi-dm320.c (which sets M:Robe 500 target specific GIO stuff and disables GIO stuff using spi_disable_all_targets() which isn't present at the ZVM and shouldn't be touched)


Right, but those changes are unconditional and thus I don't dare to commit them since all I know they make cause trouble in the mrobe 500 camp.

Quote

As for the target/arm/tms320dm320/creative-zvm/ : these are just stubs so that Rockbox can compile (I haven't enabled these during boot in the bootloader).


Well, if they are truly only stubs I would rather see them as stubs only and then I wouldn't mind committing them. Atm it seems like lots of leftovers from other parts that you probably used as basis when you copied these from elsewhere in Rockbox.

I'm not really complaining, I'm just explaining my reasoning why I didn't commit more files (yet).
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 19, 2008, 11:40:47 AM

Right, but those changes are unconditional and thus I don't dare to commit them since all I know they make cause trouble in the mrobe 500 camp.

Ok, you're right about that; that wasn't entirely clean.
Quote

Well, if they are truly only stubs I would rather see them as stubs only and then I wouldn't mind committing them. Atm it seems like lots of leftovers from other parts that you probably used as basis when you copied these from elsewhere in Rockbox.

I'm not really complaining, I'm just explaining my reasoning why I didn't commit more files (yet).

I don't say you're complaining :)

Anyway, here's my current diff (no need to commit this one, it's just for possible other ZVM porters?)

update: added new diff
Title: Re: Creative Zen Vision:M
Post by: Falafel on February 19, 2008, 04:09:50 PM
Hmm, are you using the compiler from TI or uhm, well gcc-arm? Because I want to start taking a look at how I might use the code for my ZV :)

Btw. Awesome work!
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 19, 2008, 04:14:33 PM

Hmm, are you using the compiler from TI or uhm, well gcc-arm? Because I want to start taking a look at how I might use the code for my ZV :)

Btw. Awesome work!

The only thing you should have is a copy of Rockbox SVN patched with my latest diff.
Then configure your build for Creative ZVM and bootloader.
Then you'd have to make a CIFF file (I advise you to use CreativeWizard): choose for the Zen Vision and add a DATA block with the rockbox.zvmboot; upload this to your player and normally this will work (although it will look distorted on your player due to the other screen dimensions I presume)

edit:
if you want some kind of input on the device, the following code will detect if the USB is inserted (other input hasn't been figured out yet atm):
Code: [Select]
inline bool usb_detect(void)
{
    return ( (*((volatile unsigned short*)(0x60FFC018))) & 0x100)>>8;
}
Title: Re: Creative Zen Vision:M
Post by: Falafel on February 19, 2008, 08:59:46 PM

edit2: I'm trying to compile a bootloader, but I'm getting: 'ERROR: x uses FPA instructions, whereas y does not'
and other linker errors

edit3: found it, apparently -mcpu=arm926ej-s should be -mcpu=arm9 (or at least on my machine)


Hmm, I have the same errors here, but if I change arm926ej-s to arm9 in the makefile, it'll only change to even more errors saying ERROR: X uses VPF instructions, where....

And I'm kinda at a loss as to why this is so.

Edit: Ahem, I just gave up trying under Linux and lo and behold: cygwin compiles it instantly.. Now just see if I can get it on my Zen.

edit2: I'm afraid I can't check if it works because the firmware maker gets all sizes wrong...
Title: Re: Creative Zen Vision:M
Post by: Bagder on February 20, 2008, 03:33:35 AM


Quote

edit3: found it, apparently -mcpu=arm926ej-s should be -mcpu=arm9


Hmm, I have the same errors here, but if I change arm926ej-s to arm9 in the makefile, it'll only change to even more errors saying ERROR: X uses VPF instructions, where....


Did you guys build your arm-elf toolchain with the rockboxdev.sh build script?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 20, 2008, 07:22:35 AM

edit2: I'm afraid I can't check if it works because the firmware maker gets all sizes wrong...

What do you mean by 'the firmware maker'? Scramble? CreativeWizard?


Did you guys build your arm-elf toolchain with the rockboxdev.sh build script?

Now I did and the problem is resolved; thanks!
Title: Re: Creative Zen Vision:M
Post by: Falafel on February 20, 2008, 09:28:42 AM
Quote

What do you mean by 'the firmware maker'? Scramble? CreativeWizard?


Oh yeah right, that's kind of ambiguous.. I meant Creative Wizard.

Edit: Here are the files, perhaps you can see what went wrong? The exact steps I took were:
Choose player AKA adding a cinf block,
Add data block, 'use file instead of data',
Then create firmware, but it gave me many errors about blocks not being named. (This could then be remedied by clicking both blocks again)
Followed by the nice messagebox asking me if I want a Nullblock, which is ,of course ;), what I want.
But it doesn't seem to work.

rockbox.zvmboot (http://www.hotlinkfiles.com/files/1007408_glfoa/rockbox.zvmboot)
hacked_093204.bin (http://www.hotlinkfiles.com/files/1007409_lp7rk/hacked_093204.bin)
Ps. I downloaded the latest one from epizenter, but there was no source code so I couldn't look into the problem myself.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 20, 2008, 09:32:28 AM

Oh yeah right, that's kind of ambiguous.. I meant Creative Wizard.

What problem did you get?

The normal procedure is 'Make firmware'->'Select your player'->...->'Add block'->select the newly added block->change data type to 'DATA'->check 'Use file instead of data'->type 'Hjukebox2.jrm' in 'Filename' textarea->choose the file->press 'Create Firmware'->press 'Yes'->press 'OK'->in main window 'Upload Firmware'->choose your firmware and upload it to your player

Maybe you should update CreativeWizard to a newer version?
Title: Re: Creative Zen Vision:M
Post by: Falafel on February 20, 2008, 09:38:42 AM
 :o Forgot to add 'Hjukebox2.jrm'.

It Works!!

The prog only use the upper left corner of my screen but still! :D
Title: Re: Creative Zen Vision:M
Post by: LambdaCalculus on February 20, 2008, 09:43:36 AM
Falafel, can you snap a picture and show us what it does?
Title: Re: Creative Zen Vision:M
Post by: Falafel on February 20, 2008, 09:51:12 AM
Sure,

Bureaublad.rar (http://www.hotlinkfiles.com/files/1007441_ql1p8/Bureaublad.rar)

I think its because ZV uses a different memory address to map the lcd to.. But I haven't checked yet.

Edit:
Where do you set LCD_HEIGHT and _WIDTH?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 20, 2008, 10:03:46 AM

Edit:
Where do you set LCD_HEIGHT and _WIDTH?

firmware/export/config-creativezvm.h

edit:
after seeing the photos, I would say also check lcd_init_device() in firmware/target/tms320dm320/creative-zvm/lcd_creativezvm.h;

more specific IO_OSD_OSDWIN0OFST (the format is (LCD_WIDTH*bpp)/256 )
Title: Re: Creative Zen Vision:M
Post by: Falafel on February 20, 2008, 10:32:11 AM

more specific IO_OSD_OSDWIN0OFST (the format is (LCD_WIDTH*bpp)/256 )


Hmm, but what exactly is it that this does?
I mean, I've changed it a bit and my screen gets garbled.. And if I set Height and width to 480x640 (because of the portrait-mode) it fills the screen almost, but it still misses a piece on the right side if I hold in the ZVM way. (too bad I have to go, because now I don't have time to take pictures)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 20, 2008, 10:50:59 AM

Hmm, but what exactly is it that this does?
I mean, I've changed it a bit and my screen gets garbled.. And if I set Height and width to 480x640 (because of the portrait-mode) it fills the screen almost, but it still misses a piece on the right side if I hold in the ZVM way. (too bad I have to go, because now I don't have time to take pictures)

Never mind that one, as it seems you don't have that problem I've got.

I think your problem is the BASEPX and BASEPY values: these should get adjusted to the Zen Vision ones (they can be found by disassembling the original firmware; they appear in FRESC and in  Â©TL)
Title: Re: Creative Zen Vision:M
Post by: mitch04 on February 21, 2008, 02:41:44 AM
hey mcuelenaere  can you please take a photo of your zen please?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 21, 2008, 02:11:36 PM
Progress is hard as a lot of the internal Nucleus messaging and tasking functions are used instead of just direct calls to the hardware, so I'll first have to figure out where they are stored and what's done on that particular value etc..

My current theory is that all keys, key-backlighting, hold switch (and maybe ON/OFF switch) are controlled by the PIC (http://www.rockbox.org/twiki/bin/view/Main/CreativeZVMPort#Internal_components) which communicates with the CPU through DM320 built-in I2C.
Also the RTC is controlled through I2C. I haven't found anything about power management nor LCD backlighting, although I do know that LCD can be shut off through BITSET2/BITCLR2.

The LCD is driven directly by the DM320 built-in OSD support, so switching between LCD and TV-out shouldn't be that hard.

If anyone wants to join in figuring out the OF, all help is appreciated ;)

@mitch04: there are some pictures at page 29 (http://forums.rockbox.org/index.php?topic=3320.msg115523#msg115523)

@Falafel: if you install CreativeWizard, the source is included in the installation directory (Program Files/CreativeWizard/Source)
Title: Re: Creative Zen Vision:M
Post by: Falafel on February 22, 2008, 09:57:51 PM
Unable to figure out how to find BASEPX and Y in the OF I just randomly picked a number..
And it happened to be right :)

But on a sidenote, I wouldn't mind helping you, but I'm not sure how and where to start.. Your using IDA to look for functions and memory addresses right?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 23, 2008, 07:54:06 AM

Unable to figure out how to find BASEPX and Y in the OF I just randomly picked a number..
And it happened to be right :)

But on a sidenote, I wouldn't mind helping you, but I'm not sure how and where to start.. Your using IDA to look for functions and memory addresses right?

Right, so if you could get a hold on a version of IDA (I use v.5.2, so >5.0 should be good) that'll help a lot.
Then the most important files at the moment are FRESC and (C)TL; they both consist kind of the same (speaking of the internals) but FRESC is a smaller version of (C)TL (i.e. it doesn't have to initialize sound and DRM etc..).

Currently I'm working on FRESC; my IDA database of (C)TL is growing a bit too big (>300MB) ;)

I could upload my current IDA databases, but it won't be easy to understand at first.

What you have to know:

Some info about the devices:
* I presume 'iic' is a driver to the DM320 builtin I²C
* I think 'mcu' controls the PIC and trough this the buttons, button backlighting, hold switch etc
* I don't know what 'tvenc' is; either it is the TV Encoder or something else

A last sidenote: to really understand all of the IO_* regs, you'll have to sign a NDA to be able to view the DM320 documentation.

Oh and BTW, don't open FRESC directly; it is encrypted: zook's zen_crypt is able to decrypt it.

Download link (http://rapidshare.com/files/94219021/fresc.rar)
Title: Re: Creative Zen Vision:M
Post by: Falafel on February 24, 2008, 01:01:54 PM

Right, so if you could get a hold on a version of IDA (I use v.5.2, so >5.0 should be good) that'll help a lot.
.
.
.
.
A last sidenote: to really understand all of the IO_* regs, you'll have to sign a NDA to be able to view the DM320 documentation.

Oh and BTW, don't open FRESC directly; it is encrypted: zook's zen_crypt is able to decrypt it.

Download link (http://rapidshare.com/files/94219021/fresc.rar)


Hmm, I'm having trouble opening your fresc.idb so I thought "use the parser from zook" (zendlr.ldw?) but I do not know how to use it. What I thus mean is this: is it the right file and if so, how do I then use it?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 24, 2008, 01:05:16 PM

Hmm, I'm having trouble opening your fresc.idb so I thought "use the parser from zook" (zendlr.ldw?) but I do not know how to use it. What I thus mean is this: is it the right file and if so, how do I then use it?

You do have IDA installed? If so, you can just open it with it (make sure FRESC.dec is in the same directory).

zenldr.ldw needs to be put in X:\Program Files\IDA\loaders\
Title: Re: Creative Zen Vision:M
Post by: Falafel on February 24, 2008, 01:14:39 PM
Ah now I can at least open fresc nicely :)
I'll take a look at it, see what I can figure out.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 24, 2008, 04:25:24 PM
This is my current I²C implementation; the bootloader tries reading of all available I²C slaves but that won't give me any reliable information (the data changes, but not when I press some buttons)
Title: Re: Creative Zen Vision:M
Post by: THROBiX on February 26, 2008, 11:22:52 AM
How much work is necessary for being able to boot Rockbox on the Zen players, eventually without the correct LCD resolution and key mappings/working sound? Is a new bootloader enough to just boot the system? I'm just wondering, can't really wait to see how this will progress.  :D Go Rockbox!
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 26, 2008, 11:42:27 AM

How much work is necessary for being able to boot Rockbox on the Zen players, eventually without the correct LCD resolution and key mappings/working sound? Is a new bootloader enough to just boot the system? I'm just wondering, can't really wait to see how this will progress.  :D Go Rockbox!

Do you mean the Creative ZEN or the Zen Vision:M ? As for the latter, it should perfectly boot Rockbox (altough without HDD, audio, keys, RTC, power management, etc support).

As for the Creative ZEN, I don't know. I suppose it uses an other LCD and it definitely isn't TMS320DM320 based so the hardware drivers also should get rewritten.
Title: Re: Creative Zen Vision:M
Post by: THROBiX on February 26, 2008, 11:50:44 AM
Yep, I meant the Zen Vision:M. Anyway, sounds pretty cool! Hope someone will take a look at the unfinished parts (audio, hdd, keys and so on) soon.
Title: Re: Creative Zen Vision:M
Post by: shotofadds on February 26, 2008, 11:53:56 AM
..it should perfectly boot Rockbox (altough without HDD, audio, keys, RTC, power management, etc support).

I think booting the Rockbox binary might be a little difficult without HDD support ;)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 26, 2008, 12:23:22 PM

I think booting the Rockbox binary might be a little difficult without HDD support ;)

Well, I suppose if I can run the bootloader on the device (and it doesn't have a size limit on it), why shouldn't it run the whole Rockbox binary?
Of course it would be kinda useless; but it should run (if it only requires LCD and ARM access that is).
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 26, 2008, 04:02:16 PM
No sign of the buttons yet, although I've found the RTC at address 0xD1 in the I²C! :)
So this means my I²C driver works! :)

Attached is my diff...

@Falafel: could you verify that the RTC is also located at 0xD1 in the Zen Vision?
You can recognize it because the value of 0xD1 changes exactly every second.

edit:
I still doubt if my addressing is correct, as the OF accesses the RTC at address 0x51 instead of 0xD1 (differs only 1 bit)

edit2:
@Falafel: if the address isn't 0xD1, put i2c_reading(); after i2c_init(); and give me all addresses you get on the screen
Title: Re: Creative Zen Vision:M
Post by: gitrdone300ex on February 26, 2008, 05:19:14 PM
I have been watching this thread for a long time and I would like to try to start helping out if its not too late. I am new to this stuff, but i have done quite a bit of fw modding on cell phones. I have a lot of free time and would like to try to start helping if someone feels like explaining to me how i need to get started. I have vista 32 bit. What programs would I need and what do i need to have on my zen vision m? I would be glad to help. thanks
Title: Re: Creative Zen Vision:M
Post by: tomaskn on February 27, 2008, 07:43:22 AM
guestion: are there any plans to change the battery indicator system? because the current firmware wont let me use my new battery ,its 3,7V instead 3,2 or something like that;
i can make the battery work but if my player crashes and i have to reset the indacotr go's to "battery drained" mode wich is wrong.and when its working the indicator wont change

it would really be great if you can make these battery's work normally. you get something like 7,5hrs of video and much more audio (didnt test it)

i wish i could do something myself but...
could you make a code wh allows you to manually set battery 0% and let it charge all night (full charge) and then set the 100%

something like this is probably farfar away from today but  thank you all for reading this and all the work you guys have done before ;D

sorry for the horrible english :-\
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 27, 2008, 07:51:58 AM

I have been watching this thread for a long time and I would like to try to start helping out if its not too late. I am new to this stuff, but i have done quite a bit of fw modding on cell phones. I have a lot of free time and would like to try to start helping if someone feels like explaining to me how i need to get started. I have vista 32 bit. What programs would I need and what do i need to have on my zen vision m? I would be glad to help. thanks

Take a look at the wiki page (http://www.rockbox.org/twiki/bin/view/Main/CreativeZVMPort). I also advice you to set up a build system, so you can compile code yourself.
Then start with trying to fetch the current SVN, patch it with my latest diff and compile that and upload it to your ZVM.
If you succeed in that, you can start trying to disassemble the original firmware and try figuring out the hardware.


guestion: are there any plans to change the battery indicator system? because the current firmware wont let me use my new battery ,its 3,7V instead 3,2 or something like that;
i can make the battery work but if my player crashes and i have to reset the indacotr go's to "battery drained" mode wich is wrong.and when its working the indicator wont change

it would really be great if you can make these battery's work normally. you get something like 7,5hrs of video and much more audio (didnt test it)

i wish i could do something myself but...
could you make a code wh allows you to manually set battery 0% and let it charge all night (full charge) and then set the 100%

something like this is probably farfar away from today but  thank you all for reading this and all the work you guys have done before ;D

sorry for the horrible english :-\

Yes, that will be no problems (look at the current Rockbox targets, they all support it). But, as you say, that's for in the far, far future :)
Title: Re: Creative Zen Vision:M
Post by: Falafel on February 27, 2008, 07:58:29 AM
@mceulenaere: It works! Constantly changing value :)

edit: But I messed some stuff and reverted to the originals and appllied your diffs, (which caused some trouble.. So I now have to rediscover the right settings for my screen.. after that I'll be able to give you all the addresses you wanted)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 27, 2008, 07:59:25 AM

@mceulenaere: It works! Constantly changing value :)

Does it change about every second? If so, it is the RTC(Real Time Clock) :)
Title: Re: Creative Zen Vision:M
Post by: Falafel on February 27, 2008, 08:01:38 AM
No, way faster than that, I can hardly read/see the value before it dissapears..
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 27, 2008, 08:04:19 AM

No way faster than that, I can hardly read/see the value before it dissapears..

Did you just compile the diff I put on the forums or did you add i2c_reading(); ?
If not, could you do that anyway and post the addresses (0x??) it reports?
Title: Re: Creative Zen Vision:M
Post by: Falafel on February 27, 2008, 08:10:30 AM
I compiled the diffs.

Here are the addresses:

0xE
0XF
0x10E
0x10F
0x1A2
0x1A3
0x20E
counter is still running but it doesn't seem to add anything new, so I'll post this.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 27, 2008, 08:14:07 AM

I compiled the diffs.

Here are the addresses:

0xE
0XF
0x10E
0x10F
0x1A2
0x1A3
0x20E
counter is still running but it doesn't seem to add anything new, so I'll post this.


Ok, now remove the i2c_reading(); line and replace (l.174)
Code: [Select]
unsigned short arr[2] = {0xD1, 0xC8};
with
Code: [Select]
unsigned short arr[7] = {0xE, 0xF, 0x10E, 0x10F, 0x1A2, 0x1A3, 0x20E};
and replace (l.178)
Code: [Select]
for(i=0;i<2;i++){
with
Code: [Select]
for(i=0;i<7;i++){

and compile that.
Now tell me which address changes about every second.

edit:
I think 0xE, 0x10E and 0x20E are mirrored; the same applies to 0xF and 0x10F

edit2:
the counter is just a hardware counter that just counts up and resets and counts again.
It is just there so that I can identify if the device would have crashed :)
Title: Re: Creative Zen Vision:M
Post by: Falafel on February 27, 2008, 08:23:13 AM
When I compile and run (with finally the right dimensions on screen) I see the 7 hex codes I just added, with long (36 Bytes) never changing codes behind 'em, and the top one (0xE) has a constantly changing 4digit number behind the code.

Edit: the long ones are addresses? because they don't change.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 27, 2008, 08:28:13 AM

When I compile and run (with finally the right dimensions on screen) I see the 7 hex codes I just added, with long (36 Bytes) never changing codes behind 'em, and the top one (0xE) has a constantly changing 4digit number behind the code.

Edit: the long ones are addresses? because they don't change.

Strange.
The format is as this: '0x[ADDRESS]: [READ 20-BYTES OUT ADDRESS]'.
If the long ones are FFFFFFFFFFF... or 00000000000... there isn't a slave device responding to that address.

But I conclude that the Zen Vision does have different hardware in comparison with the Creative Zen Vision:M.

BTW: what are the basepx and basepy values you use?
Title: Re: Creative Zen Vision:M
Post by: Falafel on February 27, 2008, 08:37:34 AM
Basepx = 80;
Basepy =   0;

Well, maybe I could find the different information in the fresc of my zv?

Edit:
also, it was possible to run the Rescue program of the ZVM on the ZV so at least buttons and such should have the same interface I guess.. (Although I do not remember if I tried them..)

Edit2:
output on screen:
0xE: 00...00 FF...FF
0xF: 00...00 FF...FF
0x10E: 00...00 FF7FFBFF7FFBFF7FFBFF
0x10F: 00...00 FF...FF
0x1A2: 00...00 1BFF001841
0x1A3: 00...00 41119858080
ox20E 00...00 F7F7F7F7F7F7F7F7F7F7
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 27, 2008, 04:09:35 PM
Whoow, I just see that I've got some new permissions on the forums  :)
Apparently, I got promoted to Developer? Whoever did that, thanks!  :D

Anyway, I'm getting close to the ATA driver, although I'm having trouble with ATA_CONTROL; I just can't seem to figure out which value it should have :S

As usual, diff is attached.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 28, 2008, 03:53:55 PM
I'm having difficulties with sleep() and more precise sleep_thread() (and maybe switch_thread() ), the device just restarts when some code calls sleep().
Were there any other ports behaving the same at this stage?
It seems like it has got to do with some ARM-specific code, as I don't think the (current used) DM320 code can reboot/crash the device.

As I see in the code, sleep() is replaced with a loop for some ports as they have problems with it at bootloader stage. But my problem is that actually bootloader stage is already passed; so it won't matter if Rockbox or the bootloader get loaded; both will have trouble with sleep()
Title: Re: Creative Zen Vision:M
Post by: Domonoky on February 28, 2008, 04:48:37 PM
hi,

i seam to remember that on some targets the bootloader doesnt have the interrupts enabled, and thats why the replace the sleep with a loop.
Perhaps this also the problem here ?

good luck..
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 29, 2008, 03:48:17 PM

hi,

i seam to remember that on some targets the bootloader doesnt have the interrupts enabled, and thats why the replace the sleep with a loop.
Perhaps this also the problem here ?

good luck..

I looked in it a bit deeper and I don't think the problem lays with the interrupts (standard all of those are disabled, except the ones for the timers).
BTW, what kind of interrupts should be enabled you're talking about?

I think it has something to do with the task switching, although I don't really know what. Maybe it is trying to access some address that it isn't allowed to touch or some address that was set up in the previous bootloader and is still in use...

Also it seems like there's some problem with the timer handling; as it gives me a panicf() for an unhandled TIMER3 interrupt while that interrupt is nowhere in the code enabled (TIMER0 is used for this)...
Title: Re: Creative Zen Vision:M
Post by: Thorondor on February 29, 2008, 04:14:31 PM
Hi,

I've been watching this thread for some time now. And I want to help too. But I cannot get the bootloader to compile. I can compile bootloaders for other targets, but not for the zvm. All I get is this message:
Code: [Select]
In file included from powermgmt.c:45:
export/font.h:30:21: error: sysfont.h: No such file or directory
make[1]: *** [/home/Dennis/rockbox/zvm/firmware/powermgmt.o] Error 1
make: *** [bin] Error 2


I am using Cygwin, the latest SVN patched with the last zvm.diff. I tried compiling with a compiled sysfont.h from another target but that doesn't work to. I also tried compiling it in native linux. Didn't work either
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 29, 2008, 04:18:43 PM

Hi,

I've been watching this thread for some time now. And I want to help too. But I cannot get the bootloader to compile. I can compile bootloaders for other targets, but not for the zvm. All I get is this message:
Code: [Select]
In file included from powermgmt.c:45:
export/font.h:30:21: error: sysfont.h: No such file or directory
make[1]: *** [/home/Dennis/rockbox/zvm/firmware/powermgmt.o] Error 1
make: *** [bin] Error 2


I am using Cygwin, the latest SVN patched with the last zvm.diff. I tried compiling with a compiled sysfont.h from another target but that doesn't work to. I also tried compiling it in native linux. Didn't work either

First, try 'tools/rockboxdev.sh': this will install the latest (needed) compilers and toolchain.

You did run 'tools/configure' correctly and selected BOOTLOADER ?
Title: Re: Creative Zen Vision:M
Post by: Falafel on February 29, 2008, 04:59:06 PM

Hi,

I've been watching this thread for some time now. And I want to help too. But I cannot get the bootloader to compile. I can compile bootloaders for other targets, but not for the zvm. All I get is this message:
Code: [Select]
In file included from powermgmt.c:45:
export/font.h:30:21: error: sysfont.h: No such file or directory
make[1]: *** [/home/Dennis/rockbox/zvm/firmware/powermgmt.o] Error 1
make: *** [bin] Error 2


I am using Cygwin, the latest SVN patched with the last zvm.diff. I tried compiling with a compiled sysfont.h from another target but that doesn't work to. I also tried compiling it in native linux. Didn't work either


I had that problem too.
try this in the folder where you want sysfont.h: "../tools/convbdf -h -o sysfont.h ../fonts/rockbox_default.bdf"
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on February 29, 2008, 05:56:00 PM
Ok, I finally found out what the problem was with TIMER1 who didn't want to accept any values: it just didn't get any clock :)

So now I've got the tick task working (and interrupts), but still the sleep() problem exists so this will need some more looking into...

Diff is attached (I know, it is very dirty and messy; but I don't have any real debugging tools so I just got to printf() everything I can)

edit:
re-added zvm.diff : added some USB stubs
Title: Re: Creative Zen Vision:M
Post by: Falafel on March 01, 2008, 10:36:43 AM
he mcuelenaere, when I update to your new diff, it gives me a lot of warnings (which isn't so bad) but it also give me an error on how 'CLK_MOD2_TMR0' isn't declared.. which is less desirable because now it won't do stuff..
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 01, 2008, 11:00:15 AM

he mcuelenaere, when I update to your new diff, it gives me a lot of warnings (which isn't so bad) but it also give me an error on how 'CLK_MOD2_TMR0' isn't declared.. which is less desirable because now it won't do stuff..

Did the patch apply correctly at firmware/export/dm320.h ?
Because there's the (new) definition.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 02, 2008, 01:07:47 PM
Ok, so now the HDD works (although I'm not sure if ATA_CONTROL is correct; but that doesn't matter that much) *but* it requires some modifications to thread.c which are pretty bad.

Apparently load_context() just doesn't work on the ZVM; for some unknown reason it crashes/restarts when executing this code..

Also code is a bit more cleaned in this diff.
Title: Re: Creative Zen Vision:M
Post by: bughunter2 on March 02, 2008, 10:00:48 PM
Will this port also work on the Creative Zen V Plus? (Or at least, is it likely that there is a high chance?)

Keep up the good work with Rockbox.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 03, 2008, 11:59:10 AM

Will this port also work on the Creative Zen V Plus? (Or at least, is it likely that there is a high chance?)

Keep up the good work with Rockbox.

Not directly, but with some help of Creative Zen V (Plus) owners/hackers they will (hopefully) be able to use it without much effort; but I think the Zen V differs more to the ZVM than for example the Zen Vision or the Zen Vision W..

As for Rockbox, I will be focusing on getting USB up and running so I can set up a serial driver for debugging purposes (I want to thank Frank Gevaerts for doing a lot in this area :); actually I was planning myself to do the logf() thing he did yesterday, but he was faster)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 05, 2008, 10:59:15 AM
Update:

interrupts should now fully work, there remains only one problem with the TIMER1 interrupt: for some unknown reason an CCD_VD0 interrupt is given when TIMER1 interrupt is enabled..

Also it seems as the PIC gives a non-stop interrupt to GIO0 whenever a button is touched, so I presume it is waiting until the ARM starts contacting him and asking him what button has been touched (to be worked on..)

UPDATE:

Buttons work! :)
The button driver fully functions, only current limitation is that pressing 2 buttons at the same time is detected (probably because the PIC doesn't give us that information); this is only possible with the hold switch.

Next up is the RTC, but for this I need (more) (high quality) pictures of the ZVM's internals; I already opened up mine twice, but as I find it a bit too 'scary' detaching the LCD of the main board, I'm asking somebody else to do this (to a non-working player perhaps?)

So could someone upload some pictures (if possible, made with a digital SLR ;))?

Oh yeah, patch is attached..

@Falafel: I think this won't work with the Zen Vision, because the PIC used in the ZVM either isn't used in the Zen Vision or isn't at the same I²C address; if so: please say :)
Title: Re: Creative Zen Vision:M
Post by: NicolasP on March 05, 2008, 02:56:08 PM
mcuelenaere: I see you are doing some great work! Maybe it is time to open a flyspray task and upload your patches there ? You'll get much more visibility from developers there. Also, take a look at docs/CONTRIBUTING (http://svn.rockbox.org/viewvc.cgi/trunk/docs/CONTRIBUTING) for the code formatting guidelines, it will make getting your patch committed much easier :)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 05, 2008, 03:03:23 PM

mcuelenaere: I see you are doing some great work! Maybe it is time to open a flyspray task and upload your patches there ? You'll get much more visibility from developers there. Also, take a look at docs/CONTRIBUTING (http://svn.rockbox.org/viewvc.cgi/trunk/docs/CONTRIBUTING) for the code formatting guidelines, it will make getting your patch committed much easier :)


Ok, done (http://www.rockbox.org/tracker/task/8686).
Title: Re: Creative Zen Vision:M
Post by: bobbaluba on March 08, 2008, 10:27:43 AM
Hi, I'm trying to compile the bootloader, but I get some errors when I'm trying to apply the diff.

I downloaded the diff from the bottom of this page:
http://www.rockbox.org/tracker/task/8686?pagenum=10

I get these errors:

Code: [Select]
$ patch --binary -p0 < zvm.diff

[...]

patching file firmware/target/arm/tms320dm320/uart-dm320.c
Hunk #1 FAILED at 1.
1 out of 8 hunks FAILED -- saving rejects to file firmware/target/arm/tms320dm32
0/uart-dm320.c.rej
patching file firmware/target/arm/tms320dm320/i2c-dm320.c
patching file firmware/target/arm/tms320dm320/timer-dm320.c
Hunk #1 succeeded at 8 with fuzz 1.
patching file firmware/target/arm/tms320dm320/kernel-dm320.c
Hunk #1 FAILED at 1.
1 out of 3 hunks FAILED -- saving rejects to file firmware/target/arm/tms320dm32
0/kernel-dm320.c.rej
patching file firmware/target/arm/tms320dm320/i2c-dm320.h
patching file firmware/target/arm/tms320dm320/system-dm320.c
Hunk #1 succeeded at 8 with fuzz 1.
patching file firmware/target/arm/tms320dm320/debug-dm320.c

[...]


What am I doing wrong?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 08, 2008, 10:30:46 AM

Hi, I'm trying to compile the bootloader, but I get some errors when I'm trying to apply the diff.

I downloaded the diff from the bottom of this page:
http://www.rockbox.org/tracker/task/8686?pagenum=10

I get these errors:

...

What am I doing wrong?


Attached is a fresh one, try it.

Nice that you also come join in the fun bobbaluba :)
Title: Re: Creative Zen Vision:M
Post by: bobbaluba on March 08, 2008, 10:43:03 AM
Nope, I still get the same errors.
Tried running make anyway, and then i first got the same error as Thorondor.
Then I tried: "../tools/convbdf -h -o sysfont.h ../fonts/rockbox_default.bdf" as suggested by falafel, but i still get this error when trying to compile:
Code: [Select]
make[1]: *** No rule to make target `/home/Administrator/rockbox/rockbox/build/f
irmware/target/arm/tms320dm320/creative-zvm/ata-creativezvm.o', needed by `/home
/Administrator/rockbox/rockbox/build/librockbox.a'.  Stop.
make: *** [build] Error 2
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 08, 2008, 10:46:50 AM

Nope, I still get the same errors.
Tried running make anyway, and then i first got the same error as Thorondor.
Then I tried: "../tools/convbdf -h -o sysfont.h ../fonts/rockbox_default.bdf" as suggested by falafel, but i still get this error when trying to compile:
Code: [Select]
make[1]: *** No rule to make target `/home/Administrator/rockbox/rockbox/build/f
irmware/target/arm/tms320dm320/creative-zvm/ata-creativezvm.o', needed by `/home
/Administrator/rockbox/rockbox/build/librockbox.a'.  Stop.
make: *** [build] Error 2


I suppose you're using Cygwin? Try using tools/rockboxdev.sh to fetch and download the latest ARM compilers (you'll need them anyway for compiling as ARM926EJ-S); if it still doesn't work I advice you to use the VMWare method: this will definitely work as I'm using it.

edit:
I misread your post, you're saying you still get the same errors so the patching failed.. I'll upload my firmware/target/tms320dm320/* tree in a zip-file in a minute..

edit2 (http://www.verzend.be/v/2109615/tms320dm320.rar.html)
Title: Re: Creative Zen Vision:M
Post by: bobbaluba on March 08, 2008, 11:43:09 AM

edit:
I misread your post, you're saying you still get the same errors so the patching failed.. I'll upload my firmware/target/tms320dm320/* tree in a zip-file in a minute..

edit2 (http://www.verzend.be/v/2109615/tms320dm320.rar.html)

Yay, it worked. Now my zvm is counting too.
Title: Re: Creative Zen Vision:M
Post by: gnu on March 08, 2008, 01:54:27 PM
I had the sysfont error myself, and I found that a "make clean" and "../configure" solved it.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 10, 2008, 05:09:27 PM
I've taken my player apart and took some photos, if somebody is interested here (http://rapidshare.com/files/98555684/afb.rar)'s the link.
Title: Re: Creative Zen Vision:M
Post by: Falafel on March 11, 2008, 11:55:04 AM
Uhm, I don't know what happened, but the code won't compile anymore! :o
And although it's an error I can vaguely remember: "error: called object '196608' is not a function" I can honestly say that I cannot recal how to solve it..

Ow, and if I can get my hands on a camera I will post some ics of the internals of my zen too, might come in handy.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 11, 2008, 12:01:11 PM

Uhm, I don't know what happened, but the code won't compile anymore! :o
And although it's an error I can vaguely remember: "error: called object '196608' is not a function" I can honestly say that I cannot recal how to solve it..

Ow, and if I can get my hands on a camera I will post some ics of the internals of my zen too, might come in handy.

Mmm, strange.. I think it has something to do with system-dm320.c; can you track down the error by doing 'svn revert system-dm320.c' in target/arm/tms320dm320/ ?
Test if that works, and if it does try re-applying the patch bit by bit (I believe you do understand some C, so I think that won't be a problem?)
Title: Re: Creative Zen Vision:M
Post by: Falafel on March 11, 2008, 12:32:20 PM
Good plan, I'll do that!

Edit:
Problem seems solved now, although to do so I had to revert back all the files you changed and afterwards I had to do some "snoeiwerk" in the files you added because for some reason they had their contents doubled. But this does explain what the problem was: I think I cut off the wrong part last time..

Now I'm gonna look at the new program running...

Edit2: Awesome!
It boots into the bootloader rescue menu and in the right bottom it shows a 4BYTE value that changes whenever I press a key, although I cannot actually move the cursor around.. Or select anything.. but Maybe thats because ZV uses different values there?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 11, 2008, 01:46:16 PM

Good plan, I'll do that!

Edit:
Problem seems solved now, although to do so I had to revert back all the files you changed and afterwards I had to do some "snoeiwerk" in the files you added because for some reason they had their contents doubled. But this does explain what the problem was: I think I cut off the wrong part last time..

Now I'm gonna look at the new program running...

Edit2: Awesome!
It boots into the bootloader rescue menu and in the right bottom it shows a 4BYTE value that changes whenever I press a key, although I cannot actually move the cursor around.. Or select anything.. but Maybe thats because ZV uses different values there?


Hmm, I suppose it boots directly into the 'Rescue Mode' because it falsely detects you're pressing the MENU key.
But can you post all the hex values you're getting when you press buttons (look in buttons-creativezvm.c for some reference)?
Also give the values when you press the buttons for more than 2 seconds (button_x_long value) and normally after you release the button, the button_x value should reappear.
And if you can, please report the values for plugging in headphones, charger, USB, dock, power, ...
Thanks!
Title: Re: Creative Zen Vision:M
Post by: Falafel on March 11, 2008, 02:06:31 PM
First number is just pressing it, second is when you release it or keep it pressed a bit longer
Also, all the value are preceded by FFFF

On/Off    = 0F00 && 0F01
Hold      = 9F06
UnHold    = AF06
Volume Up = 6F00 && 6F01
Vol Down  = 7F00 && 7F01
Up        = DF00 && DF01
Right     = EF00 && EF01
Down      = FF00 && FF01
Left      = CF00 && CF01
Back      = BF00 && BF01
Menu      = 9F00 && Etcetera
Ok        = 1F00
Play      = 2F00
Next      = 4F00
Prev      = 5F00

USB       = 2F06
USB ouot  = 3F06
Headphones= AF06
Hdphns out= BF06
Charger   = 4F06 -> 9F05
Chgrout   = 5F06 -> 8F05
AV in     = 8F06
AV out    = 9F06


There doesn't seem to be a button long value..
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 11, 2008, 02:22:52 PM

First number is just pressing it, second is when you release it or keep it pressed a bit longer
Also, all the value are preceded by FFFF

...

There doesn't seem to be a button long value

Here's an updated diff with your values added: to enable them, uncomment the last line in export/config-creativezvm.h

Please test them and tell me if there's something wrong (I also updated the BASEPX and BASEPY in lcd-creativezvm.c so you won't need to do that).

But I'm thinking in the future, the Creative Zen Vision should be a port on it's own cause it seems it uses some different buttons as the ZVM does (but we could preserve the files used in tms320dm320/creative-zvm/xx-creativezvm.c; we could make separate ones for the zen vision). What do others think?

edit: it seems I added some unwanted test stuff, @Falafel: recomment #define DO_THREAD_TEST
Title: Re: Creative Zen Vision:M
Post by: Falafel on March 11, 2008, 02:28:19 PM
Well, I would say that given the minute differences till now, it would be useless to make it completely seperate.. A few defines for things like BASEPX and such should be enough.. at least, as long as the differences don't grow to big.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 11, 2008, 02:35:33 PM

Well, I would say that given the minute differences till now, it would be useless to make it completely seperate.. A few defines for things like BASEPX and such should be enough.. at least, as long as the differences don't grow to big.

Ok, but if we're going to add the 60GB, the 30GB, the Zen Vision and perhaps the Zen Vision:W won't it be better if files are separated ?
But you're right, as for now this is the best solution.

One thing is bugging me (and which doesn't affect your device apparently) is that I don't get a 'button-release' value..
For now, there's just a built-in check that removes the currently pressed button after 40 ticks; but this isn't a very good solution and I thought maybe some kind of polling method to the PIC could solve problems (and I believe there's one according to OF, but I haven't figured it yet out how); so I'm puzzled why the Zen Vision has this and why the ZVM not...

BTW: what I meant with 'long value' is just what you reported: the 0F01 vs 0F00
Title: Re: Creative Zen Vision:M
Post by: Falafel on March 11, 2008, 02:39:20 PM
Yes, but this value is shown whenever you release a button OR hold it longer.. but well, I suppose it's alright.

Btw. when I load your diff in tortoise, I do not see any changes to button-creativezvm.c?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 11, 2008, 02:42:53 PM

Yes, but this value is shown whenever you release a button OR hold it longer.. but well, I suppose it's alright.

Btw. when I load your diff in tortoise, I do not see any changes to button-creativezvm.c?

Arg, I forgot to do a 'svn add button-creativezvm.c' !
Anyway, here's the correct diff..
Title: Re: Creative Zen Vision:M
Post by: Falafel on March 11, 2008, 02:45:27 PM
I just noticed this now, but it seems unhold and headphone jackin give the same reading :s?

Edit:
It keeps on giving me 'duplicate case' errors..
Edit2: Okay, that's taken care of, let's see if the keys actually work

Edit3:
I can in fact, by pushing menu button, get into the rescue mode screen.. But I cannot move the cursor although it does show the readings correctly.. I haven't got a clue as to why it doesn't respond. Did you use the long buttons as safeguard against stuck keys?

Edit4:
Ahem... I am just dense, UP and DOWN weren't defined.. :P I suppose it should work now ;)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 17, 2008, 06:13:32 PM
I ordered a 1,8" -> 3,5" adapter for analyzing the HDD structure, but in the mean time could someone help me with some dumping of his HDD (Falafel?)

Btw, if someone is wondering: updates are in FS#8686.
Title: Re: Creative Zen Vision:M
Post by: Falafel on March 18, 2008, 12:36:12 PM
Sure, tell me what you want to know, and I'll do it tonight or tomorrow. shouldn't be to much of a problem.
Title: Re: Creative Zen Vision:M
Post by: tjfontaine on March 18, 2008, 05:46:39 PM
I've just purchased a ZIF adapter, when it arrives I'll help out with HDD structure, unless it's all worked out before then
Title: Re: Creative Zen Vision:M
Post by: Falafel on March 18, 2008, 06:09:55 PM
I looked around a bit, and I happened to have a dump of about 80MB laying about :)
First80MBfromZVHD.rar (http://www.hotlinkfiles.com/files/1134682_s1cct/First80MBfromZVHD.rar)

Title: Re: Creative Zen Vision:M
Post by: tjfontaine on March 19, 2008, 09:34:14 AM
Falafel thanks for the dump

mcuelenaere it seems there are some missing files from your latest diff, along the lines of ata-creativezvm.c usb-creativezvm.c and usb-test.c
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 19, 2008, 02:11:02 PM
@Falafel: thanks, link is slow though


Falafel thanks for the dump

mcuelenaere it seems there are some missing files from your latest diff, along the lines of ata-creativezvm.c usb-creativezvm.c and usb-test.c

Thanks for reporting, here (http://www.rockbox.org/tracker/task/8686)'s a more correct diff.
Title: Re: Creative Zen Vision:M
Post by: saratoga on March 19, 2008, 08:04:08 PM
mcuelenaere:

I've been toying with the idea of getting a ZVM to play with the Ti DSP core.  How difficult would it be to use the DSP core given the current state of the port?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 20, 2008, 05:21:05 AM

mcuelenaere:

I've been toying with the idea of getting a ZVM to play with the Ti DSP core.  How difficult would it be to use the DSP core given the current state of the port?

You read my mind :)
I've already installed the C54xx binaries on my linux box, and tried attaching it to the Makefile but didn't got far.
What I find strange is that I can't find any C54xx binaries in the OF...

But as for getting the DSP core running, that shouldn't be any problem; the code is running quite stable atm; but it's still compiled as bootloader (not that it matters a lot, the HDD structure is in a custom format and so the only solutions are either formatting it to FAT or getting Rockbox to read the format(s) ).

So in short: it is possible. But what would you want to run on it at the current state of the port? I was thinking for getting the audio codecs on them and nothing more, but this isn't yet needed since the port isn't that far.
Title: Re: Creative Zen Vision:M
Post by: bgdwie on March 20, 2008, 06:23:59 AM
I think, initially, rockbox and a few audio codecs should be run from the arm9 core, because the core is quite powerful and most audio codecs can be run well enough from it, and only video and some of the more intensive codecs should use the c54x, for how much work is needed reasons, although, depending upon power consumption, it may be more efficient in the end to have all codecs run from the dsp.

Also, i don't think there is much worry about rockbox running from the flash as this is a lot quicker to startup and uses less power, making it easier to test ;)

also, since the origional firmware allows the device to have dual format drives (part in any format for removable storage, part in custom format for music), it may be possible to put the rockbox datamusic on the removable storage partition so you can run both the OF and the rockbox firmware, that is if you arre contemplating keepign the OF.

as you said: there is no real point in using the c54xx at this stage, and even for the next stage the arm9 will be sufficient for basic audio.
Title: Re: Creative Zen Vision:M
Post by: Falafel on March 20, 2008, 09:32:54 AM

also, since the origional firmware allows the device to have dual format drives (part in any format for removable storage, part in custom format for music), it may be possible to put the rockbox datamusic on the removable storage partition so you can run both the OF and the rockbox firmware, that is if you arre contemplating keepign the OF.


Well, what we could do is, repartition the removable storage partition into 2 or more different ones. I tried this out yesterday, and it works like a charm! at least, I was able to divide it up into a fat16 partion of 750M and the rest of the 4G into a Linux partition. (Although I didn't manage to reformat the last one, but that's probably my own ignorance at play ;) )

And I suppose it's accessible then, although the music would still be on the creative-style partition..

Edited to repair my bad English :p
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 20, 2008, 11:01:04 AM


also, since the origional firmware allows the device to have dual format drives (part in any format for removable storage, part in custom format for music), it may be possible to put the rockbox datamusic on the removable storage partition so you can run both the OF and the rockbox firmware, that is if you arre contemplating keepign the OF.


Well, what we could do is, repartition the removable storage partition into 2 or more different ones. I tried this out yesterday, and it works like a charm! at least, I was able to divide it up into a fat16 partion of 750M and the rest of the 4G into a Linux partition. (Although I didn't manage to reformat the last one, but that's probably my own ignorance at play ;) )

And I suppose it's accessible then, although the music would still be on the creative-style partition..

Edited to repair my bad English :p

Of course! How stupid of me that I didn't came up with that myself! I suppose it has been a long ... long time I've used the OF... ;)

You say you divided the removable partition into a FAT and a Linux one, did you try accessing them from the HDD directly? And was the HDD then formatted by the OF itself or by you?
Title: Re: Creative Zen Vision:M
Post by: Bagder on March 20, 2008, 11:18:52 AM

I think, initially, rockbox and a few audio codecs should be run from the arm9 core, because the core is quite powerful and most audio codecs can be run well enough from it, and only video and some of the more intensive codecs should use the c54x, for how much work is needed reasons, although, depending upon power consumption, it may be more efficient in the end to have all codecs run from the dsp.


If I remember the details correctly, the DSP is what controls the DAC in the dm320 so there must be at least some dsp code to get sound. But then I know the mrobe500 hackers and the archopen guys have gotten sound on the dm320 targets so that problem should've been at least partly solved already.
Title: Re: Creative Zen Vision:M
Post by: Falafel on March 20, 2008, 11:21:44 AM

Of course! How stupid of me that I didn't came up with that myself! I suppose it has been a long ... long time I've used the OF... ;)

You say you divided the removable partition into a FAT and a Linux one, did you try accessing them from the HDD directly? And was the HDD then formatted by the OF itself or by you?


First I just used the standard option: partitioning it to 4GB
After that I unmounted it in linux and deleted that partition. (While keeping the ZV in the removable disk-mode)
The I used fdisk to repartition it into a FAT16 partition and a linux partition.
I only accesed through my computer but it is/was possible to read/write to the fat16 one (after of course formatting it correctly :p (which I did myself, although after that it didn't want to change the size of the partition anymore, it complained ;). but when I just deleted the partition I was once again allowed to change the size))
I didn't manage to format the second partition correctly, but haven't found out why that was. but that shouldn't matter anyway, because if I can access the FAT partition it's probably possible to make a fat32 one (which is what rockbox uses?) which is accessible too..

Edit:
Something of note here:
The Zen didn't notice a thing, it just acted as if it was an USB-stick without intelligence. Which is good because this makes it very easy to put newer versions of Rockbox on the player once we have a good functioning bootloader :)



Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 20, 2008, 11:25:42 AM

If I remember the details correctly, the DSP is what controls the DAC in the dm320 so there must be at least some dsp code to get sound.

Indeed, I believe one of the DSP's McBSP's is connected to the I²S interface of the TLV320.
Quote

But then I know the mrobe500 hackers and the archopen guys have gotten sound on the dm320 targets so that problem should've been at least partly solved already.

Yes, it shouldn't be a big problem.

First I just used the standard option: partitioning it to 4GB
After that I unmounted it in linux and deleted that partition. (While keeping the ZV in the removable disk-mode)
The I used fdisk to repartition it into a FAT16 partition and a linux partition.
I only accesed through my computer but it is/was possible to read/write to the fat16 one (after of course formatting it correctly :p (which I did myself, although after that it didn't want to change the size of the partition anymore, it complained ;). but when I just deleted the partition I was once again allowed to change the size))
I didn't manage to format the second partition correctly, but haven't found out why that was. but that shouldn't matter anyway, because if I can access the FAT partition it's probably possible to make a fat32 one (which is what rockbox uses?) which is accessible too..

Ok, but what I was after is if you could access the partition by connecting the HDD directly to your computer (so not through the Zen Vision); but I suppose it doesn't matter because it would be weird if Creative didn't add the raw partition to the HDD.
Title: Re: Creative Zen Vision:M
Post by: bgdwie on March 20, 2008, 11:28:25 AM
say... technically, couldn't you make it so the rockbox software is stored in the flash, as well as the creative format partition as a hard copy (safetys sake) and end that partition,  then format the remainder of the drive as fat 32 for storing your music and data and other related files? this would allow a lot more user accessable space on the drive and amore user friendly method of putting songs on the player?

as for which core does what, yes, the dps does control the dac from what i remember, so to get sound we would need to use it anyway, and since it has better floating point power (i can't rememeber, this is going back through old memories) it would be wise to run codecs from their in the first place as in the longrun it would require less effort then going back and changing it all.
Title: Re: Creative Zen Vision:M
Post by: Falafel on March 20, 2008, 11:29:24 AM
Yeah, I didn't take the drive out, I'm trying to be more careful with my player. Seeing as how I've already lost a bunch of screws and the audio jack seems to have loosened a bit..

But what do you mean with the raw partition? Even if the ZV encapsulated the entire removable-part (At least this is the only thing I can imagine it would be able to do?) then, it would still be readily available to a OS-level driver..
Title: Re: Creative Zen Vision:M
Post by: bgdwie on March 20, 2008, 11:32:05 AM

But what do you mean with the raw partition? Even if the ZV encapsulated the entire removable-part (At least this is the only thing I can imagine it would be able to do?) then, it would still be readily available to a OS-level driver..


yeah, i see where your comming from, the partition would still be written like any other and be formatted as you specified so why would it matter?

edit: although, would the device also emulate a partition table for it, or does it already have one that is readable?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 20, 2008, 11:36:12 AM

say... technically, couldn't you make it so the rockbox software is stored in the flash, as well as the creative format partition as a hard copy (safetys sake) and end that partition,  then format the remainder of the drive as fat 32 for storing your music and data and other related files? this would allow a lot more user accessable space on the drive and amore user friendly method of putting songs on the player?

Yes, that's what I'm trying to accomplish on a long-term base. But since now Rockbox heavily relies on the current flash bootloader, I wouldn't consider it wise to replace that one with a Rockbox-custom one; so for now I would store the Rockbox bootloader as jukebox2.jrm in the minifs partition (and perhaps the OF as some other file) and access all other needed Rockbox files through the removable partition part.
Quote

as for which core does what, yes, the dps does control the dac from what i remember, so to get sound we would need to use it anyway, and since it has better floating point power (i can't rememeber, this is going back through old memories) it would be wise to run codecs from their in the first place as in the longrun it would require less effort then going back and changing it all.

Indeed.


Yeah, I didn't take the drive out, I'm trying to be more careful with my player. Seeing as how I've already lost a bunch of screws and the audio jack seems to have loosened a bit..

But what do you mean with the raw partition? Even if the ZV encapsulated the entire removable-part (At least this is the only thing I can imagine it would be able to do?) then, it would still be readily available to a OS-level driver..

Indeed, they will have encapsulated it in their custom file system stuff, but it could be that they obscured it some way; since they didn't make it very easy to view the firmware (encryption etc.); but I suppose this won't apply to the removable partition part :)



But what do you mean with the raw partition? Even if the ZV encapsulated the entire removable-part (At least this is the only thing I can imagine it would be able to do?) then, it would still be readily available to a OS-level driver..


yeah, i see where your comming from, the partition would still be written like any other and be formatted as you specified so why would it matter?

edit: although, would the device also emulate a partition table for it, or does it already have one that is readable?

I believe so, as Falafel said he could repartition it to FAT and Linux partitions.
Title: Re: Creative Zen Vision:M
Post by: Falafel on March 20, 2008, 11:46:39 AM



But what do you mean with the raw partition? Even if the ZV encapsulated the entire removable-part (At least this is the only thing I can imagine it would be able to do?) then, it would still be readily available to a OS-level driver..


yeah, i see where your comming from, the partition would still be written like any other and be formatted as you specified so why would it matter?

edit: although, would the device also emulate a partition table for it, or does it already have one that is readable?

I believe so, as Falafel said he could repartition it to FAT and Linux partitions.


Yeah, but on the other hand, it could be a strange partition table in which there is space only for 1 partition? because I wasn't able to mount or format the second partition.. I think I'm going to try this again, but then with 2 FAT partitions. I'll report back later

Edit:
Okay it is possible to change the partition into 2 FAT ones. I now have a FAT16 and a W95 style FAT32  partition, which are both read/writeable.
Title: Re: Creative Zen Vision:M
Post by: bgdwie on March 21, 2008, 12:14:18 AM
can you (after formatting and partitioning the disks as a removable drive and makign them 2 fat partitions) can you take the hdd out and plug it in via zif-> ide and do they work on the pc?

edit: adding more info in devices hardware to the wiki, some things are weird, eg both models support fm radio (well, have the hardware for it)

edit2: added a scan of my 60gb one and labled the components on it, might be handly because of labled components
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on March 22, 2008, 01:49:40 PM
@bgdwie: Thanks for the information, I edited some as almost all components are the same as the 30GB.

@all:
This (http://mcuelenaere.pastebin.com/f10c0fc5d) is my current state of port, DSP is working but as said before there hasn't been anything implemented for it. My intention is to port the Neuros' arm-dsp bridge (https://svn.neurostechnology.com/hackers/darchon/arm-dsp_bridge/) to Rockbox, so a more convenient way of compiling will be embedded.

[notice]
As I'm leaving for vacation, I'm not going to be around the following week.
[/notice]
Title: Re: Creative Zen Vision:M
Post by: Falafel on March 22, 2008, 03:58:14 PM
Hmm, I was just planning on opening up my ZV to scan/photograph the internals and to hook up the disc to my computer when I found out a tiny problem.. I have misplaced my tiny screwdriver and now I can't open it up.. So that's not going to work, I'll see if I can buy one somewhere this week, but for now it's gonna have to wait.

@mcuelenaere: have a nice vacation!
Title: Re: Creative Zen Vision:M
Post by: bgdwie on March 23, 2008, 10:45:41 PM
Yeah, there was a few components i found on mine but couldn't identify on the 30gb, i was unsure so i said that i had only found them on the 60gb, but i thank you for changing the chip that i said was lucient tech lol, my bad, also, i noticed that they are pretty much the same, accept for the usb controller and the power regulation ect around the dock, thats probably for powering usb devices. not a bad idea about porting the one from neuros, i'd say it would be some near perfect code there lol. have fun on your vacation, oh, and it looks like you found yourself a zen vision m 60gb mainboard to play with, was way too expensive to fix.

falafel, what kinda ZV do you have? because it may be unessecary to dissassemble.
Title: Re: Creative Zen Vision:M
Post by: Falafel on March 24, 2008, 08:48:38 AM
I have the original Zen Vision, but I just discovered my screwdriver. And I still have to check if the partitions work on my pc, so I'll still open it up somewhere today.
Title: Re: Creative Zen Vision:M
Post by: quitte on March 25, 2008, 08:32:14 PM
Hi. I recently bought a Zen V (Video) and the first thing I did was open it. Unfortunately this thread is _very_ long, and the wiki isn't the newbie friendliest,either. But so far I was able to get the nk.bin from the firmware updater and successfully flashed it with sendfile from svn. Next I tried flashing a few random nk.bins but that didn't work. I hope you can help me flash something else than the creative firmware. Preferably a linux kernel, but seeing it crash after the bootloader would be a great start  ::)
Jonas
Edit: Slowly I'm learning. in creative wizard the 3rd data block with about 1,5M is probably the actual firmware? and that has to be encrypted somehow with zen-utils?
Title: Re: Creative Zen Vision:M
Post by: Falafel on March 27, 2008, 07:50:37 AM
The (TL(C)) block is the actual firmware, mceulenaere has been working on figuring out what it does. but it's way too complex so he turned his attention to FRESCUE which is the rescue screen you get when you mess up your firmware. It contains the same essential functions as TL(c) but it's not quite as bloated, you should be able to find the IDA-database somewhere in the wiki or the thread.

Edited for spelling
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on April 06, 2008, 04:14:04 PM
I posted an update in Flyspray for the ones who are interested.
The biggest change is a (not-functional yet) USB driver.

I also got a FAT partition to mount on the device, but the problem is that it requires (currently) a 1.8" -> 3.5" adapter so you can format the HDD.

To mount the FAT partition on your pc, I recommend this way (on Linux):
Code: [Select]

--------------------------------------------------------------
losetup -o [OFFSET] /dev/loop[X1] /dev/sd[X2]
mount -t vfat [MOUNTPOINT /dev/loop[X1]
--------------------------------------------------------------
with:
[OFFSET] = the offset in bytes to your FAT partition,
for this I replaced the cfs partition (to find out where this is located you'd have to read 0x24->0x28 and multiply this number by 512 (sector size))
[X1] = a number ranging from 0 to ?, mostly this is 0 but if you already have other loop devices,
you'd better pick a higher number
[X2] = the letter assigned to the HDD
[MOUNTPOINT] = pretty obvious :)

(Of course you first need to format it. WARNING: this will erase all your current data from your Zen!)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on April 13, 2008, 02:33:05 PM
So currently, I'm still stuck at the USB driver although I've put a lot of work into it..

That's why I'm requesting for help, if someone with a working development environment and a ZVM or Zen Vision(Falafel?) could test the patch and see what it results to on their devices; maybe it would give me some useful information.

The patch is available at the tracker (http://www.rockbox.org/tracker/task/8686).
Title: Re: Creative Zen Vision:M
Post by: ancalag0n on April 17, 2008, 12:43:22 PM
Hello,

I'm following this forum for a long time and I see that you encounter difficulties. Perhaps that I can help you to do something. I have a Zen Vision M and I use Linux (ubuntu 7.10) very regularly but I am initial in programming. Maybe I could help you to test your work or something like that (if you ensure me that the dangers to my player are tiny).

By hoping that my assistance will be useful for you.  :)
Title: Re: Creative Zen Vision:M
Post by: Sonic on April 17, 2008, 03:02:26 PM
ditto on what the last guy said, except that i use vector linux (a slackware variant), and am planning on learning C++ soon ;)
Title: Re: Creative Zen Vision:M
Post by: mophead740 on April 17, 2008, 05:11:04 PM
I can help too, especially if you need someone using windows xp sp2 or even vista if you need it (I have both).

alternatively i can alwyas crack open my ubuntu 7.10 install.

i dont have much programming skill but if you tell me what to do im pretty good at following instructions. :)
Title: Re: Creative Zen Vision:M
Post by: Chronon on April 17, 2008, 05:21:49 PM
We want to keep the development topics as clean and to the point as possible.  mcuelenaere pointed out a patch that he would like tested.  So that would be a good place to start if you want to jump in.

You can find plenty of documentation on how to apply patches and compile Rockbox here: DocsIndex#For_Developers (http://www.rockbox.org/twiki/bin/view/Main/DocsIndex#For_Developers)

General questions about compiling or setting up a build environment should be posted to the Getting Started and Compiling forum.  Specific problems with applying this patch can still go here.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on April 21, 2008, 04:17:42 PM
I don't want to get people's hopes up, but today I managed to get Rockbox booting on my ZVM although no keys were working.

I'll see if I can post a picture tomorrow..

As usual, the patch is available at the tracker (http://www.rockbox.org/tracker/task/8686).

edit:
video (http://nl.youtube.com/watch?v=q6pTtI-Ib90)
image 1 (http://i25.tinypic.com/20hljf6.jpg)
image 2 (http://i29.tinypic.com/29c6z5x.jpg)
Title: Re: Creative Zen Vision:M
Post by: tjfontaine on April 22, 2008, 01:25:26 PM
great work mcuelenaere! I finally received my zif connectors so will try and replicate your setup especially since your patch applies and compiles without any futzing about.
Title: isp1583?
Post by: Zeroth on April 23, 2008, 02:09:11 PM
I already did a google search, as well as a site-wide search on rockbox.org. However, it appears this is a new problem... So, I applied the latest patch for the ZVM port, it worked. However, when i tried to compile, it gave me a lot, and I repeat, a lot of errors in firmware/drivers/isp1583.c

Upon checking the file... it appears there are about 5 different versions of isp1583! 0.0 I would say that the code got duplicated several times, except each version appears to be slightly different. Is there something wrong with the patch?
Title: Re: isp1583?
Post by: mcuelenaere on April 23, 2008, 03:38:19 PM
To people who want to replicate my case this is what you got to do:
Code: [Select]
losetup -o 52429312 /dev/loop0 /dev/XXX
mkfs.vfat -F 32 /dev/loop0
mount -t vfat /dev/loop0 /mnt/XXX

I already did a google search, as well as a site-wide search on rockbox.org. However, it appears this is a new problem... So, I applied the latest patch for the ZVM port, it worked. However, when i tried to compile, it gave me a lot, and I repeat, a lot of errors in firmware/drivers/isp1583.c

Upon checking the file... it appears there are about 5 different versions of isp1583! 0.0 I would say that the code got duplicated several times, except each version appears to be slightly different. Is there something wrong with the patch?

Try starting with a clean tree and applying the newest patch.
Title: Re: Creative Zen Vision:M
Post by: mitch04 on April 23, 2008, 04:33:50 PM
is there anyway I can do it without taking it apart? Great work mate
Title: Re: Creative Zen Vision:M
Post by: Mardoxx on April 24, 2008, 04:44:18 PM
No, not as of yet.

Great work btw.. amazing to see how far its come on :P
Title: Re: Creative Zen Vision:M
Post by: Transience on May 03, 2008, 10:32:59 PM
I was playing around with my ZVM, and I found something strange:
I booted the player into recovery mode,
Erased the firmware           (Reload Firmware)
Ran disk cleanup                 (Clean Up)
And formatted the player    (Format All)
Now when I connect the player to my PC, it still shows up as a creative zen vision M, but now it shows up as a 50mb partition formatted in "Generic Hierarchial". Which part of the ZVM's HDD am i seeing here?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on May 04, 2008, 03:44:33 AM
I was playing around with my ZVM, and I found something strange:
I booted the player into recovery mode,
Erased the firmware           (Reload Firmware)
Ran disk cleanup                 (Clean Up)
And formatted the player    (Format All)
Now when I connect the player to my PC, it still shows up as a creative zen vision M, but now it shows up as a 50mb partition formatted in "Generic Hierarchial". Which part of the ZVM's HDD am i seeing here?
This is the minifs partition aka the firmware part; it contains the main firmware and some database files. This is also where Rockbox is stored.
Title: Re: Creative Zen Vision:M
Post by: mophead740 on May 04, 2008, 05:05:00 AM
Hey,

I've been thinking lately about ways in which we can reformat the zvm for rb without plugging the drive directly into the computer.

and i thought the only way I know to do it, is through the media explorer (that creative thing that you install but never use lol).

but anyway, you can use that software to reformat the zvm.

is there anyway that we can reverse engineer this app to reformat it for rockbox, or is this beyond the ability of anyone here?

i think development would really speed up here if we could get a software formatting solution available because there would be so many more people willing to help.

so just thought I'd post this.

any ideas??

Ben

edit by mcuelenaere:
fixed some spelling mistakes

laughs, sorry about my spelling, english is actually my first language and im pretty good at speaking and writing it, I just type too fast and am too lazy to get the spelling right all the time (i typed slower on this one). Blame MSN.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on May 04, 2008, 05:14:13 AM
Hey,

I've been thinking lately about ways in which we can reformat the zvm for rb without plugging the drive directly into the computer.

and i thought the only way I know to do it, is through the media explorer (that creative thing that you install but never use lol).

but anyway, you can use that software to reformat the zvm.

is there anyway that we can reverse engineer this app to reformat it for rockbox, or is this beyond the ability of anyone here?

i think development would really speed up here if we could get a software formatting solution available because there would be so many more people willing to help.

so just thought I'd post this.

any ideas??

Ben

edit by mcuelenaere:
fixed some spelling mistakes

Could you specify "reformatting the ZVM" ? (I've never used the Creative Media Explorer)

Even if the HDD were formatted, we would still have to get direct access to it so we can get a FAT partition on it.

And BTW, it is possible to do this purely by software; the only thing that needs to be done is the USB driver, which is currently blocked by the lack of stable working interrupts.

If this would work, we could upload (bootloader) Rockbox through Recovery Mode and enable the USB chip, only giving us the second partition which your OS (Windows/Linux/Mac OS X/...) should format as FAT. Then you would upload the whole .rockbox/ folder and again enter Recovery Mode. Then you should upload "normal" Rockbox which will find the FAT partition and load all the needed files.

The only disadvantage of this method, is that dual booting won't be working (as the original partition (cfs) will be deleted, so even if the OF would be loaded it would give undefined behavior)
Title: Re: Creative Zen Vision:M
Post by: imfloflo on May 04, 2008, 06:18:15 AM
Hey , i'm owner of ZVM 30gb and i want to help and test this firmware on my player.
Is there a description  or a HowTo , to install your Rockbox firmware on the player.
I am a student in a school computer engineer and I'd like to see what it gives.
Thx Flo.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on May 04, 2008, 06:19:48 AM
Hey , i'm owner of ZVM 30gb and i want to help and test this firmware on my player.
Is there a description  or a HowTo , to install your Rockbox firmware on the player.
I am a student in a school computer engineer and I'd like to see what it gives.
Thx Flo.
I'll put the current install method at the wiki; you'll find it a few posts back..

update (http://www.rockbox.org/twiki/bin/view/Main/CreativeZVMPort#Install_method)
Title: Re: Creative Zen Vision:M
Post by: imfloflo on May 04, 2008, 06:57:25 AM
I have 2 PC  ( 1 XP & 1 Vista with cygwin install) and 1 MacbookPro(dualboot vista&cygwin / Leopard) ,can i use my MBP to format my player? and to set up a Rockbox build environment just for this 3 commandes?

Code: [Select]
losetup -o 52429312 /dev/loop0 /dev/XXX
mkfs.vfat -F 32 /dev/loop0
mount -t vfat /dev/loop0 /mnt/XXX
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on May 04, 2008, 07:18:20 AM
I have 2 PC  ( 1 XP & 1 Vista with cygwin install) and 1 MacbookPro(dualboot vista&cygwin / Leopard) ,can i use my MBP to format my player? and to set up a Rockbox build environment just for this 3 commandes?

Code: [Select]
losetup -o 52429312 /dev/loop0 /dev/XXX
mkfs.vfat -F 32 /dev/loop0
mount -t vfat /dev/loop0 /mnt/XXX

Oops, maybe I had to specify it a bit: you'll need an 1,8"->3,5" adapter or external enclosure to connect the HDD to your macbook. Without direct access to the HDD, it won't work.
Title: Re: Creative Zen Vision:M
Post by: imfloflo on May 04, 2008, 07:36:16 AM
ok so i can't sync my ZVM directly by USB and format it. :s i'll wait a new method maybe with the CreativeWizard or with the modifier installer.
Too bad.Thx.
Title: Re: Creative Zen Vision:M
Post by: Falafel on May 04, 2008, 01:32:04 PM
Meh, I wanted to test the nice new rockbox, but it seems I have lost my zifconnector when I moved :'(..

But, How do you acces the FAT partition?
Because there is still the extra->USB disk function of the OF that we could use.. Although I can no longer check if it is accesible on a hardrive level (although I suspect it is, because I could nicely repartition and format it in linux). Could you look into that mceulenaere? (or anyone else with a zif connector?)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on May 04, 2008, 01:37:46 PM
Meh, I wanted to test the nice new rockbox, but it seems I have lost my zifconnector when I moved :'(..

But, How do you acces the FAT partition?
Because there is still the extra->USB disk function of the OF that we could use.. Although I can no longer check if it is accesible on a hardrive level (although I suspect it is, because I could nicely repartition and format it in linux). Could you look into that mcuelenaere? (or anyone else with a zif connector?)

That was what I was originally going for, but as this required a good understanding of the CFS filesystem (which I don't have); I went for plan B and now I ended up at this stage :)

This means the second "partition" is deleted and replaced by a FAT one, which currently works although it requires either a ZIF connector or a working ISP1583 usb driver to access it..
Title: Re: Creative Zen Vision:M
Post by: Falafel on May 04, 2008, 02:00:10 PM
Couldn't you, to find it or something, make a file with a specific pattern in it. put it on the "removable disk"  and then search for that pattern in the connected disk with 010?

Edit:
As I'm obviously overlooking the fact that you can't find the partition when you connect it, consider that a not-so-useful-post ;). Unless I'm mistaken of course..
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on May 04, 2008, 02:18:42 PM
Couldn't you, to find it or something, make a file with a specific pattern in it. put it on the "removable disk"  and then search for that pattern in the connected disk with 010?

Edit:
As I'm obviously overlooking the fact that you can't find the partition when you connect it, consider that a not-so-useful-post ;). Unless I'm mistaken of course..
Even if I did, the place where the file would be stored differ a lot between all the ZVM's off all users, so this wouldn't be an ideal solution.

+ there's the fact that the file is spread across several clusters which are described in the cluster bitmap (if I understand correctly), which makes it even more harder to track down the whole file.
Title: Re: Creative Zen Vision:M
Post by: mitch04 on May 04, 2008, 11:06:45 PM
hey mate good work mcuelenaere there no way yet to put rockbox on without takeing it apart yet? just wondering You have done a great job.
Title: Re: Creative Zen Vision:M
Post by: mophead740 on May 05, 2008, 03:52:41 AM
just what would be required to get rb working on the zvm with a cfs partition?

coding, reformatting of the code, changing of drivers, im not sure i understand what this involves.

im sure if it was anything you could do then you would have done it, but maybe its something i can research.

btw, wen i say reformat the player i mean, plug in your player and go to the media explorer.  then select settings and information, click tools and then there is an option to format the player.

so, anyway to backend this app to format it as fat or not.

i think not because it seems to me as if the software simply sends the instruction to the player to format the drive and the player reboots and does it, in which case its not likey that the players fw would have instructions to format as fat.

but it was just an idea.

edit: would it be smart to try and run the original fw on a fat partition.

i assume it couldnt have any permanent effect (as you could simply plug in the drive and reformat it if it didnt work). What says it couldn't run fine?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on May 05, 2008, 09:48:34 AM
just what would be required to get rb working on the zvm with a cfs partition?
Understanding of the CFS file system (I believe it is based on BFS; quetzalcoatl on nomadness.net found out a lot of interesting stuff and he even made a fully working read-only driver for the first (minifs) partition, but unfortunately the site is now online and most of his information on the forums is lost (except in google cache, archive.org) + there seems to be no way of contacting/finding this person :(

I tried contacting the website owner, but failed. I also contacted a guy who he spoke with on the forums (and who is a main developer at libnjb), but he doesn't have any contacting information.
Quote
coding, reformatting of the code, changing of drivers, im not sure i understand what this involves.

im sure if it was anything you could do then you would have done it, but maybe its something i can research.

btw, wen i say reformat the player i mean, plug in your player and go to the media explorer.  then select settings and information, click tools and then there is an option to format the player.

so, anyway to backend this app to format it as fat or not.

i think not because it seems to me as if the software simply sends the instruction to the player to format the drive and the player reboots and does it, in which case its not likey that the players fw would have instructions to format as fat.
I think you're right on this one.
Quote
but it was just an idea.

edit: would it be smart to try and run the original fw on a fat partition.

i assume it couldnt have any permanent effect (as you could simply plug in the drive and reformat it if it didnt work). What says it couldn't run fine?
I could try it, but I'm pretty certain the OF won't recognize it and will crash or something like that.

hey mate good work mcuelenaere there no way yet to put rockbox on without takeing it apart yet? just wondering You have done a great job.
I'm sorry, but no; not at the moment.
The only thing you could do is compile the bootloader and find out how the USB chip works.
Title: Re: Creative Zen Vision:M
Post by: mophead740 on May 06, 2008, 01:57:34 AM
could someone try running the OF on a fat partition?

just if it isnt too much trouble.

if i'm not mistaken the OF is based on windows CE, which would (in its entirety) support fat. it is somewhat likely though that this component/driver was removed (along with a lot of other things) in order to make the fw smile smaller. but i think its still worth a try.

I would do it myself but I dont have a zif connector.
Title: Re: Creative Zen Vision:M
Post by: JamesL on May 06, 2008, 04:36:35 AM
The firmware OS is NucleasRTOS

http://www.mentor.com/products/embedded_software/nucleus_rtos/index.cfm

Apparently the source code is available but i'm guessing you'd have to go through treacle to get it

Again, I am pretty sure the firmware wouldnt work on a FAT32 partition and if it did, im sure it would have some major issues, and the whole point of keeping the original firmware is to keep its capabilities, in this case for me it would be the video codec support
Title: Re: Creative Zen Vision:M
Post by: mophead740 on May 06, 2008, 04:59:02 AM
its still my opinion that it is worth trying this.

as i pointed out earlier it cant exactly hurt the player.

just for the sake of actually knowing for certain whether it will or will not work, i still think someone should check. as explained i would do it myself but i dont have the right adapter, etc.
Title: Re: Creative Zen Vision:M
Post by: Falafel on May 06, 2008, 12:09:00 PM
Hmm, I was thinking we maybe could use gnomad? it can acces the player, but I don't what more it can do.. I'll look into it, more later.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on May 06, 2008, 12:10:24 PM
Hmm, I was thinking we maybe could use gnomad? it can acces the player, but I don't what more it can do.. I'll look into it, more later.
AFAIK gnomad just uses libmtp, so this won't work.

AFAIK there's no software solution for getting raw hdd access to the ZVM trough the OF.
Title: Re: Creative Zen Vision:M
Post by: Falafel on May 06, 2008, 12:19:46 PM
Yeah, you'r right..
Hmm, too bad.. Ah well, maybe I should learn how to write USB-drivers :s

Edit:
Correcting the fact that some words might sound the same, but look quite different in writing..
Title: Re: Creative Zen Vision:M
Post by: DanielF50 on May 09, 2008, 04:34:00 PM
just what would be required to get rb working on the zvm with a cfs partition?
Understanding of the CFS file system (I believe it is based on BFS; quetzalcoatl on nomadness.net found out a lot of interesting stuff and he even made a fully working read-only driver for the first (minifs) partition, but unfortunately the site is now online and most of his information on the forums is lost (except in google cache, archive.org) + there seems to be no way of contacting/finding this person :(

I tried contacting the website owner, but failed. I also contacted a guy who he spoke with on the forums (and who is a main developer at libnjb), but he doesn't have any contacting information.

http://www.whois.net/whois_new.cgi?d=nomadness&tld=net

Email, Address, Name etc all on there, hopefully he still uses those details.

Daniel
Title: Re: Creative Zen Vision:M
Post by: mophead740 on May 10, 2008, 08:19:21 PM
I'm just wondering, if i wanted to get to work on my own usn driver, how would I go about it?
What kind of programming skill would it take?

Setting up the build environment should be no problem for me its just the coding that I'm wondering about.

EDIT:

I was looking around at the documentation for the usb chip and found this pdf that explains how to program it for windows ce 5.0.


has anyone else read it becauase it seems to me that its exactly what we need.

it even explains the way the chip handles interupts and the commands to use etc so it could be just what we need.

i think its based in c++ though, which could be a problem but most of it I'm sure is modifiable.

you can find it here http://www.nxp.com/acrobat/applicationnotes/AN10052_1.pdf

EDIT 2:

probably the most interesting part goes somewhere along these lines

Code: [Select]
The ISP176x can handle interrupts, such as SOF, ATL, INTL and ISO.
A separate thread, UsbInterruptThreadStub () in Chw.cpp, is run to handle these interrupts.
Whenever there is an interrupt to the ISP176x, interrupt thread UsbInterruptThreadStub () will be called.
This main interrupt handler handles all the ISP176x generated interrupts and routes interrupts to the respective interrupt handlers.
For example, PhISP176XScheduleATLThread () handles ATL interrupts and PhISP176XScheduleINTLThread () handles INTL interrupts.
If, for example, you are working on ATL, you will get an interrupt only when PTDs in the ATL memory are done.
If you are working on INTL, you will get the interrupt only when PTDs in the INTL memory are done.
Remark: The ISP176x Windows CE software stack is tested on the PCI bus for the x86 processor.
© Koninklijke Philips Electronics N.V. 2005. All rights reserved.
Application note Rev. 01 — 27 October 2005 16 of 173
Philips Semiconductors AN10052
ISP176x Windows CE 5.0 Software Programming Reference
The PCI interrupt is routed to the ISP176x interrupt through the PLX9054 bridge.
If porting to other hardware platforms, add interrupt number MemBase and MemLen in P1761HCPDD.reg.
For example:
For interrupt number:
SysIntr = dword: XX /* XX indicates interrupt number */
For memory base address:
MemBase = dword: XX /* XX indicates memory base address */
For memory length:
MemLen = dword: XX /* XX indicates memory access length */
If you are working on other hardware platforms, ignore the PLX bridge initializations in system.c.

edit by mcuelenaere:
made your post a bit smaller
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on May 11, 2008, 03:28:10 AM
http://www.whois.net/whois_new.cgi?d=nomadness&tld=net

Email, Address, Name etc all on there, hopefully he still uses those details.

Daniel

Yes, I already tried contacting this person but he didn't respond.

Yeah, you'r right..
Hmm, too bad.. Ah well, maybe I should learn how to write USB-drivers :s
I'm just wondering, if i wanted to get to work on my own usn driver, how would I go about it?
What kind of programming skill would it take?

Setting up the build environment should be no problem for me its just the coding that I'm wondering about.
The only skill you'd need is C (and perhaps assembly reading, if you want to know how the OF does the USB) + you need to understand a bit how USB works (see url (http://www.beyondlogic.org/usbnutshell/usb1.htm)) + the datasheet (http://www.nxp.com/acrobat/datasheets/ISP1583_6.pdf).

At the moment the only working thing is you can receive a EP0SETUP package but that's it.

Keep in mind the interrupts aren't really working for some reason, so I've created a helper (tick task) which checks the interrupt register of the ISP1583 regularly and calls the interrupt handler if necessary.

The ISP1583 registers are accessed in 16-bit mode, so an int has to be set in 2 clock cycles (see the set_int(...) macro)

That's about it, I recommend using the bootloader build as this gives you the advantage of doing printf's while normal build only supports logf (which means less trial-and-error productivity ;)).

PS: the files you're interested in are

edit:
There is some example source available at NXP (https://download.semiconductors.com/registered/sIndex.php?theArea=usb) (you'll need an my NXP account to log in)
Title: Re: Creative Zen Vision:M
Post by: Falafel on May 11, 2008, 02:03:27 PM
@mceulenaere
Hmm, when I try to compile it gives me an error that probably hinges on: "error: dsp-image.h: no such file or directory"

When I did a quick search I found that the Mrobe500 folks found the same problem, and although you gave a new patch the problem remains..

Edit:
Also, when I merge your diff with my source tree, it complains about audio-creativezvm.c not having an URL and then won't allow me to do anything.. Is this to be expected or should I stop using tortoise-SVN :p
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on May 11, 2008, 05:11:29 PM
@mceulenaere
Hmm, when I try to compile it gives me an error that probably hinges on: "error: dsp-image.h: no such file or directory"

When I did a quick search I found that the Mrobe500 folks found the same problem, and although you gave a new patch the problem remains..

Edit:
Also, when I merge your diff with my source tree, it complains about audio-creativezvm.c not having an URL and then won't allow me to do anything.. Is this to be expected or should I stop using tortoise-SVN :p
The bootloader isn't committed to SVN, but here's a patch for it (apply it to a clean SVN).

P.S.: you'll need to "#define logf printf" in isp1583.c otherwise debug won't show up..
Title: Re: Creative Zen Vision:M
Post by: Falafel on May 12, 2008, 03:06:54 PM
Ah, well it seems ZVM has finally crossed a border where my lowly ZV couldn't follow. As it is, it compiles quite fine, it gets loaded to my player without questions. But when it resets it just complains about firmware error..

So now I'll have to find out what broke compatibility, before I can even start on the USB. (Or I'm forgetting something crucial, since it's been awhile ago that I last tinkered with it.. But I cannot remember an error like this. So I guess not..)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on May 12, 2008, 03:19:09 PM
Ah, well it seems ZVM has finally crossed a border where my lowly ZV couldn't follow. As it is, it compiles quite fine, it gets loaded to my player without questions. But when it resets it just complains about firmware error..

So now I'll have to find out what broke compatibility, before I can even start on the USB. (Or I'm forgetting something crucial, since it's been awhile ago that I last tinkered with it.. But I cannot remember an error like this. So I guess not..)

What exact message does it give you?

The only possible think I can think of, is that the flash bootloader finds an incorrect firmware which did get passed through the firmware upgrade..

Could you send me "rockbox.zvm"/"rockbox.zvmboot" ?
Title: Re: Creative Zen Vision:M
Post by: Falafel on May 12, 2008, 03:33:47 PM
The error it gives is: "firmware problem" AKA it's the rescue system (coming to the rescue?).

O!

You already construct a complete firmware!
Haha, that should solve it.

Edit:
To clearify: I used creative wizard to make a new firmware, while this was (obviously) not neccesary..
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on May 12, 2008, 03:36:34 PM
The error it gives is: "firmware problem" AKA it's the rescue system (coming to the rescue?).

O!

You already construct a complete firmware!
Haha, that should solve it.

Edit:
To clearify: I used creative wizard to make a new firmware, while this was (obviously) not neccesary..
Yes, in current SVN you don't need to do anything more except just sending it to the player :)
Title: Re: Creative Zen Vision:M
Post by: Falafel on May 12, 2008, 06:03:51 PM
here is the diff you need to get the keys working well on a ZV
http://rapidshare.com/files/114474489/zv.diff.html

Also, beware that the bootloader file that is created is still faulty, at least for me it is.. so if anyone wants to test it they should first open it in creative wizard or something and check if the codes and device names are correct.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on May 16, 2008, 03:50:55 PM
As some may've noticed, a simulator for the ZVM (60GB) was submitted some days ago.
If someone feels to it, he/she can compile SVN and try adding keymaps for the plugins and post your patch here or at Flyspray.

If it complies with the Rockbox rules (http://svn.rockbox.org/viewvc.cgi/trunk/docs/CONTRIBUTING) (i.e. use 4 spaces instead of tabbing etc), it will be committed to SVN.
Title: Re: Creative Zen Vision:M
Post by: jermey on May 26, 2008, 02:19:44 AM
I noticed there is flash memory dump in wiki so if you could read flash memory could we also write something to it? I'm asking because i have broken zen that isn't switching on when hdd is plugged in. I see only creative logo then black screen and reset. I have 1,8"->usb adapter so if somebody could help me i will be pleased.
Title: Re: Creative Zen Vision:M
Post by: mophead740 on May 26, 2008, 05:47:47 AM
where did u get that 1.8 to usb adaptor?

i didnt realise you could get it like that.

that sounds good.
Title: Re: Creative Zen Vision:M
Post by: jermey on May 26, 2008, 08:33:07 AM
I just bought hdd 1,8" external case with ZIF connector inside and thats all. If it useful I can help with some Rockbox porting things. I found something interesting. When i plug this adapter to this "zen connecting thing" instead of hdd and plug it to computer and then switch zen on its switching on but nothing happens. Screen is black but led is on (not blinking) and led which is on this adapter is sometimes blinking like zen was trying to write or read something from hdd. Maybe somebody will find it useful.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on May 26, 2008, 10:23:52 AM
I noticed there is flash memory dump in wiki so if you could read flash memory could we also write something to it? I'm asking because i have broken zen that isn't switching on when hdd is plugged in. I see only creative logo then black screen and reset. I have 1,8"->usb adapter so if somebody could help me i will be pleased.

That's correct, you can read and write to it; but the problem is: if you can't get past the Creative load screen there's no easy way to get code on it so you can't access flash memory.

The not so easy way is to attach JTAG to the device or (even harder) to extract the flash memory chip from it and make a flash reader/writer for it.
Title: Re: Creative Zen Vision:M
Post by: jermey on May 27, 2008, 01:13:50 AM
actually I just found out how to run my Zen with hdd working and rockbox bootloader and so. It this help? What is JTAG? It's some hardware to read flash memory or just software?
Title: Re: Creative Zen Vision:M
Post by: spitfire on June 08, 2008, 06:35:50 AM
Is there a website, where progress (what is currently working, and what is not) of getting rockbox working on ZV:M is tracked?
The port page http://www.rockbox.org/twiki/bin/view/Main/CreativeZVMPort is too cryptic, and informations are hard to find...could anyone create and update such informations somewhere(eg. at rockbox epizenter forum)?
Title: Re: Creative Zen Vision:M
Post by: AlexP on June 08, 2008, 07:18:52 AM
Is there a website, where progress (what is currently working, and what is not) of getting rockbox working on ZV:M is tracked?
The port page http://www.rockbox.org/twiki/bin/view/Main/CreativeZVMPort is too cryptic, and informations are hard to find...could anyone create and update such informations somewhere(eg. at rockbox epizenter forum)?

No.  Information about a port effort for Rockbox should stay on the Rockbox site.  I for one am not about to go looking at other random sites.  If you want to do that, that is of course up to you.

As for progress, this thread contains it, but it is for development only.  Please do not post to ask about progress.  When there is some, it will be posted here.
Title: Re: Creative Zen Vision:M
Post by: Transience on June 16, 2008, 10:02:22 PM
Would it be possible to format the ZVM's HDD in windows xp with 010Editor, since 010 treats the ZVM like a removable disk in xp? I'm not 100% certain, but I think that 010 can read the entire disk (both partitions) as raw hex. If this is the case, how would I go about formatting the drive?
Title: Re: Creative Zen Vision:M
Post by: Hoffmann on June 17, 2008, 03:57:11 AM
So I try to repeat the installation method with my own words to find hidden traps. PLEASE CORRECT ME - If I understood s.th. wrong!

1. I mount the HDD of the ZVM (and mouting means realy mounting the HDD and not just using the "usb-extern-harddrive-feature" of the ZVM).
2. I format the 2nd partition as fat
3. I build rockbox using linux OS (using linux virtually or actually)
4. I move all that compiled stuff to /mnt/what-ever/.rockbox/ on the zvm-hdd (except rockbox.zvm)
5. I unmount and unconnect everything and reboot the zvm
6. I copy the "rockbox.zvm"-file like I usualy copy mediafiles to the zvm
7. I reboot the zvm again and rockbox should be working *tada*
(8. I upload my build rockbox binarys to rockbox.org
 9. I tell ppl on this board that everything worked well)

Is it possible to attach a bigger 1.8"-HDD to my zvm?

Anybody has any hints for dissambling the zvm without destroying the hole magic eletronic and maybe even without scratches?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on June 17, 2008, 04:24:42 AM
So I try to repeat the installation method with my own words to find hidden traps. PLEASE CORRECT ME - If I understood s.th. wrong!

1. I mount the HDD of the ZVM (and mouting means realy mounting the HDD and not just using the "usb-extern-harddrive-feature" of the ZVM).
2. I format the 2nd partition as fat
3. I build rockbox using linux OS (using linux virtually or actually)
4. I move all that compiled stuff to /mnt/what-ever/.rockbox/ on the zvm-hdd (except rockbox.zvm)
5. I unmount and unconnect everything and reboot the zvm
6. I copy the "rockbox.zvm"-file like I usualy copy mediafiles to the zvm
7. I reboot the zvm again and rockbox should be working *tada*
(8. I upload my build rockbox binarys to rockbox.org
 9. I tell ppl on this board that everything worked well)

Is it possible to attach a bigger 1.8"-HDD to my zvm?

Anybody has any hints for dissambling the zvm without destroying the hole magic eletronic and maybe even without scratches?
Correct. Don't forget to upload rockbox.zvm using either sendfirm or CreativeWizard. (just uploading it in MTP won't work because a special attribute needs to be set)

Yes, it is possible to attach a bigger HDD in it, but the height has to be maximum 5mm if I remember correctly, meaning only single platter HDD's.

For opening: the abi disassemble (http://www.anythingbutipod.com/archives/2006/02/how-to-disassemble-the-creative-zen-vision-m.php) tutorial is perfect.

Just watch out with the bottom, if you aren't careful there you'll break off some plastic holding the screws (like I did); nothing really bad though.
Would it be possible to format the ZVM's HDD in windows xp with 010Editor, since 010 treats the ZVM like a removable disk in xp? I'm not 100% certain, but I think that 010 can read the entire disk (both partitions) as raw hex. If this is the case, how would I go about formatting the drive?
It is possible with 010Editor, but it will be very tough and require a lot of FAT expertise I presume :)
Perhaps there's a way of doing this on Windows, but as I couldn't mount the HDD correctly under Windows (only in Linux) I haven't searched for it. The main thing you need to do is format a piece of the HDD in FAT. Perhaps what you could do is overwrite the first sector (first make a backup!) with a normal header (use fdisk?) and set 1 partition at the correct place and format it as FAT.
Title: NJB filesystem
Post by: quetzalcoatl on July 30, 2008, 03:01:37 AM
Hi everyone:)

mcuelenaere - I have found the sources on my linux machine, but they are from somewhat early version.. It is only a CFS's inode reader, operating on dumpfiles, so there's almost nothing interesting in it except header files with a few raw structures' definitions. maybe I have some newer/better versions on other machines, i'll check in the evening
Title: Re: NJB filesystem
Post by: mcuelenaere on July 30, 2008, 03:11:12 AM
Hi quetzalcoatl :)

Perhaps this should be discussed in the Creative ZVM Port thread, but for the time being it'll suffice.
Thanks for finding the time posting on the forums.

Perhaps a little bit of info for other people: quetzalcoatl is the one who did a lot of research for the Creative filesystems at nomadness.net and can hopefully help us understand how it works and help writing a read-only driver.

@quetzalcoatl:
What we need is
 a) a very limited read-only cfs driver which can locate a specific file (because the aim is to run a virtual filesystem in cfs which can be mounted through the Original Firmware to ease working on Rockbox and enable dual booting; the file in cfs is called VFSYS)
 b) a read-only minifs driver which could provide dual booting (actually the same thing as above needs to be accomplished, namely 'jukebox2.jrm' needs to be loaded into RAM and started)

For some more info, see the CreativeZVMPort (http://www.rockbox.org/twiki/bin/view/Main/CreativeZVMPort#HDD_partitioning_info) wiki page.

BTW did you get my mails containing the disk dump I gave you?
Title: Re: Creative Zen Vision:M
Post by: AlexP on July 30, 2008, 03:42:08 AM
Hi,

I've merged the new thread about the filesystem with the ZVM thread as suggested by mcuelenaere, as the thread that appeared about filesystems was a little cryptic without context :)
Title: Re: NJB filesystem
Post by: quetzalcoatl on July 30, 2008, 10:01:51 AM
thanks for moving the post, after browsing the forum for a while I really had no idea where to put it.. 'compilation' seemed to be best place:)

BTW did you get my mails containing the disk dump I gave you?
yes, i got the file, it can be removed from the net drive

about the jukebox.jrm - easy task. the MINIFS volume is like FAT and is completely FLAT. one bitmap, one clusterchain list, one directory with filenames, and the rest is for the files. volume is 20mb allways, and all the positions are constant

about the VFSYS - could you be more specific? is it a file that 'factory' puts on the drive? i dont remember such file.. or maybe this will be a file of yours? if so, where and how it will be placed? as a song? as a data file? or manually as a system file*? the first (factory) and latter (system file) makes locating the file trivial, while the 'song/data' options - result in more complex algorithms and higher data access time

*) mind that there is no way to put it there except raw hexediting the drive, or writing proper tool/driver to do the same!
Title: Re: NJB filesystem
Post by: mcuelenaere on July 30, 2008, 10:12:34 AM
...

about the jukebox.jrm - easy task. the MINIFS volume is like FAT and is completely FLAT. one bitmap, one clusterchain list, one directory with filenames, and the rest is for the files. volume is 20mb allways, and all the positions are constant
good, do you have any code for that laying around?
Quote
about the VFSYS - could you be more specific? is it a file that 'factory' puts on the drive? i dont remember such file.. or maybe this will be a file of yours? if so, where and how it will be placed? as a song? as a data file? or manually as a system file*? the first (factory) and latter (system file) makes locating the file trivial, while the 'song/data' options - result in more complex algorithms and higher data access time

*) mind that there is no way to put it there except raw hexediting the drive, or writing proper tool/driver to do the same!
I suppose it isn't available at the older Creative devices (like Nomad etc), but there's a function in Creative Zen devices which allows you to have an external UMS drive on which you can do whatever you want (mind that the standard transfer protocol is MTP which is similar to NJB as it is evenly stupid and hides away the underlying file system).

This is achieved by the OS by creating a file (I don't know which type) named VFSYS on the device itself (beware that this information is based on some disassembling of the Original Firmware and some guessing, but I'm pretty sure it works like this).

So what we need is a way to find where the actual data for this virtual file system is located and if so, Rockbox can access it and have a read/write (virtual) hard drive.
Title: Re: NJB filesystem
Post by: quetzalcoatl on July 31, 2008, 01:59:22 AM
good, do you have any code for that laying around?
No, none at all.

I've looked into the CF dump you have provided - this is the same disk structure as on NJB, but contents are very different. MINIFS is 50mb instead of 20mb (thus, CFS is limited to ~72,25mb) and contains many new files. Special sectors ('/' directory!) offsets has changed and need to be revised or recalculated. Back then, I saw only MINIFS of 20mb so I assumed the offsets be constant, now its clear they are calculable somehow. It should not be a big problem, I still have many samples of old volumes. But, if you could provide a diskdump of a *different* card - ideally smaller - 64mb, 32mb - this would be a great help. Of course, if players with such cards do exist at all :)

I'll prepare some example code by weekend.

BTW1. the CF image seems to use different endianess
BTW2. where did you get the "hdd partitioning info" section from? i mean, on the wiki page. someone did a good job describing the basics, but the structures are incorrect *if* they are describing the NJB drives - including the CF dump you have provided - it matches my knowledge not theirs. Or maybe they are describing much newer drive? ZenVision's? Any dumps available for it? It'd be great if I could compare the dumps the autor was working on with mine
Title: Re: NJB filesystem
Post by: mcuelenaere on July 31, 2008, 05:28:45 AM
...

I've looked into the CF dump you have provided - this is the same disk structure as on NJB, but contents are very different. MINIFS is 50mb instead of 20mb (thus, CFS is limited to ~72,25mb) and contains many new files. Special sectors ('/' directory!) offsets has changed and need to be revised or recalculated. Back then, I saw only MINIFS of 20mb so I assumed the offsets be constant, now its clear they are calculable somehow. It should not be a big problem, I still have many samples of old volumes. But, if you could provide a diskdump of a *different* card - ideally smaller - 64mb, 32mb - this would be a great help. Of course, if players with such cards do exist at all :)

I'll prepare some example code by weekend.
Thanks!

BTW did you take a look at the code I sent you?
Quote

BTW1. the CF image seems to use different endianess
BTW2. where did you get the "hdd partitioning info" section from? i mean, on the wiki page. someone did a good job describing the basics, but the structures are incorrect *if* they are describing the NJB drives - including the CF dump you have provided - it matches my knowledge not theirs. Or maybe they are describing much newer drive? ZenVision's? Any dumps available for it? It'd be great if I could compare the dumps the autor was working on with mine
Almost all the information on the wiki is mine, and most is based on reverse engineering the original firmware or guessing.

I have here a 32MB, 128MB and 2GB CF card (and a 30GB HDD) laying around I can try to use; but as the minifs partition requires 50MB I doubt the 32MB CF card will work (these are all tested on a modded Zen Vision:M, but the structure is similar to the other devices)

I also have another disk dump at the wiki (http://www.rockbox.org/twiki/bin/viewfile/Main/CreativeZVMPort?rev=1;filename=DiskDump.rar) and I believe Falafel also made some (this is of a Creative Zen Vision, not a Creative Zen Vision:M; but they run the same hardware and the same OS)

edit:
the 32MB CF card gave me a hard disk error when I tried to format it in the recovery mode
Title: Re: Creative Zen Vision:M
Post by: quetzalcoatl on August 01, 2008, 05:11:48 AM
@32mb driver error -- not good for the case, but any new knowledge is allways a good thing :)

there were only 2 options:
- either the device accepts the drive and formats it with _smaller_ minifs [50mb is not obligatory, on older devices minifs was 20mb] and we'll have a nice way of generating different samples
- or device rejected the drive - this has happened - and this means, that:
---A) ZenVisionM requires drive at least 50mb + sizeof(minimal empty cfs) :)
---B) the rescue-mode-module of firmware has the minifs size hardcoded to 50mb or calculates the size of MINIFS from the numberof/sizeof the files it wants to put there

The problem is, I dont really recall (nor find in my notes) finding ANY info on how to calculate offsets of special clusters on MINIFS.. the fact of B) means that newer players differ a bit from older ones (njb: 20mb vs zenvision=50mb, other models - ???), what means that position of special clusters is also different and I need a way to find it. Or create a list of known devices configurations'. The calculations I have made back then for NJB are not applicable here, I'll have to reverse it again. No big deal, just a matter of one-two weekends.

If you could generate an image for different drive 64mb, 256mb, whatever, just different from that one you've sent me - it'd be a great help - i'll compare the two volumes and if positions are equal, i'll just make quick-dirty-hardcoded filefinder working only on zenvision:m so you have something to start on
--

uhm.. code? what code? I didnt notice any.. when did you sent it?
Title: Re: Creative Zen Vision:M
Post by: Stu L Tissimus on August 05, 2008, 02:58:06 PM
Sorry to get off topic, but something I noticed on the Wiki page for this port is that the original Nucleus OS makes use of Nano-X, which is licensed under both the GPL and MPL. I'm no lawyer, but I think that means that they're obligated to supply the public with the source code if the source code was modified, right? (I'd be amazed if they got Nano-X running on a new platform without some modification.)

So what I'm getting at is: couldn't we legally force Nucleus (or even better, Creative) to show us their source code? I'm sure that'd offer some clues about getting Rockbox running on the ZV:M.

Just my $0.02.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 05, 2008, 03:32:16 PM
Sorry to get off topic, but something I noticed on the Wiki page for this port is that the original Nucleus OS makes use of Nano-X, which is licensed under both the GPL and MPL. I'm no lawyer, but I think that means that they're obligated to supply the public with the source code if the source code was modified, right? (I'd be amazed if they got Nano-X running on a new platform without some modification.)

So what I'm getting at is: couldn't we legally force Nucleus (or even better, Creative) to show us their source code? I'm sure that'd offer some clues about getting Rockbox running on the ZV:M.

Just my $0.02.
I thought about that myself (that's why I put that information in the wiki ;)); but I'm pretty sure a) it wouldn't yield much interesting information (they won't provide any hardware docs) and b) you'll first need to succeed in sueing them which isn't that easy AFAIK.

BTW this isn't off-topic :)
Title: Re: Creative Zen Vision:M
Post by: mophead740 on August 08, 2008, 01:57:49 AM
Has anyone sent them an email asking for the source code, or are we just assuming that we'd have to sue them?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 08, 2008, 06:17:57 AM
Has anyone sent them an email asking for the source code, or are we just assuming that we'd have to sue them?
I have sent them once (and I believe others have done too), but they aren't willing to do anything; so just asking for something will lead to nothing.

And like I said sueing them won't give much either I think as Nano-X is just a little part of their code and it isn't really hardware related so even if they would provide their changes it won't do much good to the port. Although I want to say this is just my opinion, I'm not saying it's a lost cause; if someone wants to sue them I do support it and hope he/she will succeed.
Title: Re: Creative Zen Vision:M
Post by: JQuilty on August 10, 2008, 01:41:51 AM
If Nano-X is indeed under the GPL, perhaps the Free Software Foundation would be interested in forcing them to release the source code. They've gone after companies for doing so in the past, and won. And since this is giving freedom to DAP's, I'm sure they'd find it very interesting.

They even have an email address set up for this. compliance@fsf.org.
Title: Re: Creative Zen Vision:M
Post by: quetzalcoatl on August 18, 2008, 03:08:26 AM
heh, now this gets interesting even more :)
You see, just before going on holiday I've started a opensource project on SourceForge to keep the drive-reader sources easily available, but I wasn't quite sure whever would it be accepted because it might conflict with Creative's rights to the drive structure etc.
Now, if the Creative's OS is based on GPL, so is the HDD driver, so ... may still be a conflict in publishing the Rev-Eng work? uh.. too complicated for me

Fortunatelly the project was accepted and now I'm proud to announce that current sources are available :)
SourceForge: https://sourceforge.net/projects/nomadrawexplore
CIA: http://cia.vc/stats/project/nomadrawexplore

Currently:
- detects 2 types of minifs (20mb, 50mb)
- only Win32, MFC due to the GUI

The 'core' of the reader:
- is in C++ with Boost 1.35
- has drive:volume(0) hardcoded as minifs
- can list the files contained
- can read a file or its part
- performs all the checks and integrity tests I could think of

-- edit --
I've enhanced GUI a little bit and fixed file-reading to respect the file size as indicated in directory entries. Current svn rev.5 seems stable.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 18, 2008, 02:08:32 PM
heh, now this gets interesting even more :)
You see, just before going on holiday I've started a opensource project on SourceForge to keep the drive-reader sources easily available, but I wasn't quite sure whever would it be accepted because it might conflict with Creative's rights to the drive structure etc.
Now, if the Creative's OS is based on GPL, so is the HDD driver, so ... may still be a conflict in publishing the Rev-Eng work? uh.. too complicated for me

Fortunatelly the project was accepted and now I'm proud to announce that current sources are available :)
SourceForge: https://sourceforge.net/projects/nomadrawexplore
CIA: http://cia.vc/stats/project/nomadrawexplore

Currently:
- detects 2 types of minifs (20mb, 50mb)
- only Win32, MFC due to the GUI

The 'core' of the reader:
- is in C++ with Boost 1.35
- has drive:volume(0) hardcoded as minifs
- can list the files contained
- can read a file or its part
- performs all the checks and integrity tests I could think of

-- edit --
I've enhanced GUI a little bit and fixed file-reading to respect the file size as indicated in directory entries. Current svn rev.5 seems stable.

Thanks!

I finally got the code to compile under VS2005 (do File->New->Project From Existing Code; enable Unicode, set include dir to ./;../;"C:\Program Files\boost\boost_1_35_0" and set 'Create precompiled header') and it seems to be working pretty good :)
Nice job!

I haven't found the time to actually look into the code and start making a C version/Rockbox adjusted version for it, but I will in a few days.

edit:
@quetzalcoatl: could you also please publish your notes? Could help in porting the code..
Title: Re: Creative Zen Vision:M
Post by: quetzalcoatl on August 18, 2008, 02:50:21 PM
The only things you should need are in the NJB folder, the rest is GUI. Oh, and two 'common' .h files in the root directory.

There's plenty of room for simplification/optimization - for single 'jukebox.jrm' file there's no need for cacheing direntries, nor whole bitmaps

Let me know if you need any help in moving to C or in understanding how all things work. I tried to keep everything self-descripting, but while it surely is for me, it might not be for others:)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 22, 2008, 10:55:38 AM
...

Let me know if you need any help in moving to C or in understanding how all things work. I tried to keep everything self-descripting, but while it surely is for me, it might not be for others:)

This (http://mcuelenaere.pastebin.com/mf391003) is as far as I get now, but I'm stuck at the cluster chain's stuff.

I can't figure out what the structure of the cluster chain is, where it's located and how I need to find the data that belongs to the file attached to the cluster..
Title: Re: Creative Zen Vision:M
Post by: GuybrushThreepwood on August 22, 2008, 05:26:35 PM
Hello to everyone! :) I'm new and I'm writing here because I'm having some serious problems with the update_extract tool included in the Zenutils package. While on many ZVM 30Gb firmware packages (like 1.50.01 and 1.61.01) it works very well, on many other (like the last 1.62.02) it gives the following error:
Code: [Select]
>update_extract.exe -u ZENVisionM_30GB_PCFW_1_62_02.exe -V
[*] Looking for firmware archive offset...
[*] Printing input variables...
    Updater executable:  ZENVisionM_30GB_PCFW_1_62_02.exe
    Firmware archive:    ZENVisionM_30GB_PCFW_1_62_02_rk.bin
      Key:               34d122FD84fc7CD9143584962572593
      Offset:            0x0005e0c0
      Size:              0x00e91cec
[*] Reading firmware archive...
[*] Decrypting firmware archive...
[*] Decompressing firmware archive...
Failed to decompress the firmware archive.
I've checked the key (it's enough to open the package executable with an hex editor and search for the string 'PAVCString': the key is stored there repeated three times; I think that update_extract checks the key in this way too) and it's correct. I've also tried to specify it by the -k switch but it didn't help. Is this a common problem? I'm using update_extract v0.1, perhaps a newer version exists that solves this issue but I couldn't find either the sources for it (I've instead found the sources for the main libraries it's based on: zlib 1.2.3 for the compression and beecrypt 4.1.2 for cryptography). 
Thanks in advance to everyone for the help! :)

p.s. Is there a manual way alternative to using update extract to extract the firmware from the package executable?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 22, 2008, 05:33:19 PM
Hello to everyone! :) I'm new and I'm writing here because I'm having some serious problems with the update_extract tool included in the Zenutils package. While on many ZVM 30Gb firmware packages (like 1.50.01 and 1.61.01) it works very well, on many other (like the last 1.62.02) it gives the following error:
Code: [Select]
>update_extract.exe -u ZENVisionM_30GB_PCFW_1_62_02.exe -V
[*] Looking for firmware archive offset...
[*] Printing input variables...
    Updater executable:  ZENVisionM_30GB_PCFW_1_62_02.exe
    Firmware archive:    ZENVisionM_30GB_PCFW_1_62_02_rk.bin
      Key:               34d122FD84fc7CD9143584962572593
      Offset:            0x0005e0c0
      Size:              0x00e91cec
[*] Reading firmware archive...
[*] Decrypting firmware archive...
[*] Decompressing firmware archive...
Failed to decompress the firmware archive.
I've checked the key (it's enough to open the package executable with an hex editor and search for the string 'PAVCString': the key is stored there repeated three times; I think that update_extract checks the key in this way too) and it's correct. I've also tried to specify it by the -k switch but it didn't help. Is this a common problem? I'm using update_extract v0.1, perhaps a newer version exists that solves this issue but I couldn't find either the sources for it (I've instead found the sources for the main libraries it's based on: zlib 1.2.3 for the compression and beecrypt 4.1.2 for cryptography). 
Thanks in advance to everyone for the help! :)

p.s. Is there a manual way alternative to using update extract to extract the firmware from the package executable?
Hi!

Did you use the ZenUtils from current Rockbox SVN or the ones attached in the wiki?

AFAIK I fixed this problem in SVN..
Title: Re: Creative Zen Vision:M
Post by: GuybrushThreepwood on August 22, 2008, 05:42:35 PM
Did you use the ZenUtils from current Rockbox SVN or the ones attached in the wiki?

AFAIK I fixed this problem in SVN..

Thank you very much for your fast reply! :) I've used a precompiled version found here:

http://www.pimpmyzen.com/download.php?list.15

If you can tell me where to get the revised version (even its sources if not precompiled), it would be great! Thank you! :)
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 22, 2008, 07:54:36 PM
Thank you very much for your fast reply! :) I've used a precompiled version found here:

http://www.pimpmyzen.com/download.php?list.15

If you can tell me where to get the revised version (even its sources if not precompiled), it would be great! Thank you! :)
Yes, those are outdated currently.

The current ones are in utils/zenutils/ (http://svn.rockbox.org/viewvc.cgi/trunk/utils/zenutils/).
Instructions how to work with SVN are on the wiki; compiling zenutils will need CMake and even more info is in notes.txt (http://svn.rockbox.org/viewvc.cgi/trunk/utils/zenutils/notes.txt?revision=18012&view=markup).
Title: Re: Creative Zen Vision:M
Post by: GuybrushThreepwood on August 23, 2008, 11:52:00 AM
Thanks for your advices! Unfortunately, I couldn't use the SVN (it asks for a username and a password and I don't have them). I've tried to use cmake too but it gives me a ton of errors though it's correctly configured. I've manually downloaded update_extract and all of its libraries sources and tried to compile the update extract main.cpp but, even there, I receive another ton of errors though all the includes are where they should be. I'm starting to consider giving up... I'd like to know where I'm wrong...
Title: Re: Creative Zen Vision:M
Post by: AlexP on August 23, 2008, 11:57:46 AM
You only need to svn username and password to commit.  To check out source you don't need anything.

http://www.rockbox.org/twiki/bin/view/Main/UsingSVN
Title: Re: Creative Zen Vision:M
Post by: GuybrushThreepwood on August 23, 2008, 12:06:10 PM
You only need to svn username and password to commit.  To check out source you don't need anything.

http://www.rockbox.org/twiki/bin/view/Main/UsingSVN

Thanks for your reply. I've downloaded the sources: it was my mistake; to download no username or password is required. Now that I have all the right files, I would try to use cmake again then let you know. Excuse me for the dumb questions but I'm quite new to these things...  :-[
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 23, 2008, 02:13:09 PM
Thanks for your reply. I've downloaded the sources: it was my mistake; to download no username or password is required. Now that I have all the right files, I would try to use cmake again then let you know. Excuse me for the dumb questions but I'm quite new to these things...  :-[
Instead of directly downloading through SVN, you could've also downloaded the most recent source tarball (http://build.rockbox.org/dist/build-source/rockbox.7z)..

Also it is possible you'll have problems with update_extract recognizing the correct offset; I've got a fix for it ready but as I'm not at home I can't commit it now (though this doesn't affect ZVM v.1.62.02 AFAIK).

For help compiling, don't forget to read utils/zenutils/notes.txt.

Quote from: GuybrushThreepwood
p.s. Is there a manual way alternative to using update extract to extract the firmware from the package executable?
Yes there is. While upgrading your ZVM, copy C:\CtJbFW\cttemp\nk.bin to a safe place.
Title: Re: Creative Zen Vision:M
Post by: GuybrushThreepwood on August 23, 2008, 03:24:28 PM
Instead of directly downloading through SVN, you could've also downloaded the most recent source tarball (http://build.rockbox.org/dist/build-source/rockbox.7z)..

Yes, you're right: I've realized this reading the guide on the wiki but this isn't the problem because now I have no problems using the SVN.

For help compiling, don't forget to read utils/zenutils/notes.txt.

Thanks. I've read it and followed the instructions.

Quote from: GuybrushThreepwood
p.s. Is there a manual way alternative to using update extract to extract the firmware from the package executable?
Yes there is. While upgrading your ZVM, copy C:\CtJbFW\cttemp\nk.bin to a safe place.

I already know this trick: it's described on many forums and I've already used it to extract the 1.62.02 nk.bin. The problem is that I've a faulty Zen and on some forums I've read that flashing back to 1.30.02 could help. Though I don't believe this, I'd like to make a try but the 1.30.02 updater doesn't even recognize my player (this isn't the problem with the player which is instead recognized by the other updaters, the problem is another) and because of this doesn't extract the firmware and I can't use that trick.
Updater 1.30.02 is among those that don't work with update_extract and I can't succeed in compiling the revised version. Here's what I did:
- downloaded the sources from the SVN
- set up the build environment for Watcom (I use open-watcom-c-win32-1.7a) by cmake
but, when I try to launch wmake, I get a lot of errors and can't go on any further...
I certainly miss something (as said, I'm quite new to these things) though it seems to me that everything is fine (obviously the situation is different: my environment has certainly some kind of issue)...
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 23, 2008, 03:35:33 PM
...

I already know this trick: it's described on many forums and I've already used it to extract the 1.62.02 nk.bin. The problem is that I've a faulty Zen and on some forums I've read that flashing back to 1.30.02 could help. Though I don't believe this, I'd like to make a try but the 1.30.02 updater doesn't even recognize my player and because of this doesn't extract the firmware and I can't use that trick.
fw 1.30.02 is among those firmwares that don't work with update_extract and I can't succeed in compiling the revised version. Here's what I did:
- downloaded the sources from the SVN
- set up the build environment for Watcom (I use open-watcom-c-win32-1.7a) by cmake
but, when I try to launch wmake, I get a lot of errors and can't go on any further...
I certainly miss something (as said, I'm quite new to these things) though it seems to me that everything is fine (obviously the situation is different: my environment has certainly some kind of issue)...
I'm sorry, but this forum (and this thread) is dedicated to porting Rockbox to the Zen Vision (:M), not helping people fix their player.

And I've never tested Watcom, but as I heard MingW on Windows requires some patches to the source I can imagine open-watcom won't compile zenutils magically without changes...
Title: Re: Creative Zen Vision:M
Post by: GuybrushThreepwood on August 23, 2008, 03:46:44 PM
I'm sorry, but this forum (and this thread) is dedicated to porting Rockbox to the Zen Vision (:M), not helping people fix their player.

And I've never tested Watcom, but as I heard MingW on Windows requires some patches to the source I can imagine open-watcom won't compile zenutils magically without changes...

I understand, in fact I've written about update_extract (I see that many other people did this in this thread) and not about the issue with my player: I don't think I have done something wrong or at least I hope and I think that many other people would like to learn how to compile Rockbox and the tools related to it. At least, this is what I'd like to do. Thank you anyway.

p.s. If the code has to be modified to be compiled under Windows, how was the version on pimpmyzen compiled? Was it cross-compiled?

p.p.s What I meant by "manual way to extract the firmware" was asking what's the updater file structure and how to manually extract the firmware from it.
Title: Re: Creative Zen Vision:M
Post by: quetzalcoatl on August 24, 2008, 07:11:54 AM
This (http://mcuelenaere.pastebin.com/mf391003) is as far as I get now, but I'm stuck at the cluster chain's stuff.

I can't figure out what the structure of the cluster chain is, where it's located and how I need to find the data that belongs to the file attached to the cluster..
i've just put all the current notes into the root/notes on the SF

what you need most now is notes/minifs/fs.txt:
- remember that 'sector' = 512bytes for the whole drive
- remember that 'cluster' = 8 sectors for the whole drive

line 13: the layout of the volume. the cluster IDs in second column are for yours drive. those are clusters of the VOLUME, not drive. minifs volume tends to start at drive's sector number one, as its seen in the volume table in MBLK

line 24, 26: structure of the "cluster chain". a single cluster chain is a structure consisting of some data and the 'chainlist' (a list of _logical_ clusterids that describe the file's contents' location). the cluster chain looks like:
- uint32 unknown
- "chainlist", the list of uint16, constant-length, 0xFFFF-terminated, padded with 0x0000 to the end
- uint32 unknown2
- uint32 number of entries on the 'chainlist'

warning: the whole 'cluster chains' part of the volume is a sequential list of consecutive clusterchains. placed one by one, from the first to the last, so finding the right clusterchain is relatively easy. BUT the size of the clusterCHAIN is not chosen well by the designers, it doesnt multiplicate to the size of cluster. the easiest way to find the right chain is to calculate its address in terms of BYTES on the drive (not secotrs, not clusters) and then translate the address to clusters/sectors.

a "logical clusterid" is a cluster ID offsetted by the beginning of the volume's dataspace. if the file's clusterchain says that a logicalclusterid is 0x0123 and the minifs's dataspace starts at cluster 0x4321, then the REAL in-volume clusterid is 0x4321+0x0123 = 0x4444, and there you should look for the file's contents

[ and the in-volume clusterid = 0x4444 of course points to the drive's physical sector = 0x4444 * clustersize + minifsstart  = 0x4444 * 8 + 1]

line 39: the structure of the directory/direntry
blahblah, please se the notes..
the most important is that, there are 2 identical numbers - and those are the file's clusterchain's numbers. i don;t know why two of them, they're always the same, so whatever.

mind that that all names are in char on yours volumes, not wchar_t as the notes may state!
Title: Re: Creative Zen Vision:M
Post by: GuybrushThreepwood on August 24, 2008, 08:54:44 AM
Hi! :) I've succeeded in building the zenutils sorces under Linux (it was very easy and I haven't found any problem): it's clear that something is wrong with my Windows build environment. I would do my best to find a solution to this and, if I would succeed, I would  report the results here. I hope it could be useful to someone else who could want to do the work under Windows.
By now, I've to report a problem: even the newer version of update_extract fails to extract the firmware from the updater package; perhaps the problem causing this issue isn't still resolved, the strange thing is that, as said, it works on some updater packages and doesn't work on others.
If there is something more I could do, I'm free to help! :)

p.s. As said in my last post, I hope that I haven't done anything wrong writing again here on this thread, instead I hope that sharing the results of my tests could be useful.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 24, 2008, 04:05:08 PM
@quetzalcoatl:
Thanks for the notes! I'll look into it sometime this week..

...

p.s. If the code has to be modified to be compiled under Windows, how was the version on pimpmyzen compiled? Was it cross-compiled?
No, it was compiled using VS2005.

Quote
p.p.s What I meant by "manual way to extract the firmware" was asking what's the updater file structure and how to manually extract the firmware from it.
The structure of it isn't really described somewhere as it's more a binary Win32 program containing two binary scrambled & compressed binary blobs placed at a changeable spot.

But if you would like to really know it:
  * the nk.bin data starts at the first DWORD in the .data section; the DWORD is the size of the compressed/scrambled blob and is preceded with some other data (you can recognize it because after the DWORD there won't be any 0x00 anymore)
  * the key will need to be found in the other sections and is recognizable by the prefix 34d
  * the descrambling algorithm is fixed and documented in zenutils
  * the descrambled blob can be decompressed using standard Zlib

...
If there is something more I could do, I'm free to help! :)
You could always help porting Rockbox ;)

Quote
p.s. As said in my last post, I hope that I haven't done anything wrong writing again here on this thread, instead I hope that sharing the results of my tests could be useful.
No, it was just a little warning in order to not convert this thread into some kind of 'Fix my ZVM!' help thread :)

edit:
I just committed some fixes for ZenUtils, try recompiling and see what it gives..
Title: Re: Creative Zen Vision:M
Post by: GuybrushThreepwood on August 24, 2008, 05:38:07 PM
@mcuelenaere

I've updated my copy of the SVN: tomorrow I would build again the sources and see what happens then let you know. Tomorrow I would try to set up a better Windows environment too...
I've opened the updater executable with a PE Editor and the .rdata section is only 60Kb worth while the .data section is a lot bigger (a little less than the entire package dimension): isn't the firmware (scrambled and compressed as you've said and I've expected) supposed to be in the .data section? BTW I have to go deeper into this...
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 25, 2008, 05:03:45 AM
@mcuelenaere

I've updated my copy of the SVN: tomorrow I would build again the sources and see what happens then let you know. Tomorrow I would try to set up a better Windows environment too...
I've opened the updater executable with a PE Editor and the .rdata section is only 60Kb worth while the .data section is a lot bigger (a little less than the entire package dimension): isn't the firmware (scrambled and compressed as you've said and I've expected) supposed to be in the .data section? BTW I have to go deeper into this...
Sorry, I was wrong. You're right :) It is the .data section; the info I gave you wasn't double checked.

For example: ZENVPlus_PCFW_L22_1_32_01.exe :
   * the data is in .data; starting exactly at 0x5F0C4; while it's length is at 0x5F0C0 (or relatively to start of .data: 0x0C4 & 0x0C0)
   * the key (34d12E9276d9bB6796efe6457749886) is also in .data
Title: Re: Creative Zen Vision:M
Post by: GuybrushThreepwood on August 25, 2008, 01:25:22 PM
@mcuelenaere

Hi! I've built the revised version of zenutils: everything is fine now and it extracts the updater packages v1.62.02 and v1.30.02 too. Great work! Where was the problem?
Unfortunately, I haven't still succeeded in setting up a working environment under Windows: I've tried with MinGW but, though the build process with cmake succeeds, when I try to make the executables I still get many errors... As soon as I would have some spare time, I would try with Microsoft Visual Studio 2008 Express... Have a good day! :)

---EDIT---

I've tried to flash the v1.62.02 and v1.30.02 firmwares extracted by the newer update_extract version to my ZVM: both CreativeWizard and the hacked firmware updater succeed in flashing the 1.62.02 version but not the 1.30.02 (exactly the one I was interested in :( ).
This means that update_extract correctly extracts the firmware file (otherwise the firmware v1.60.02 shouldn't be flashed too) but I don't understand what's wrong with the firmware v1.30.02. I've noticed that the file size is the greatest (21,4Mb) among all the firmwares I've seen: perhaps the problem is there and CW nor the hacked updater can handle such a big firmware file (maybe they truncate the firmware file...).
I've tried also the older versions of CW but they don't even recognize my player (though CW v0.8.4.0, Windows and Creative Media Explorer do).
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 25, 2008, 07:14:04 PM
@mcuelenaere

Hi! I've built the revised version of zenutils: everything is fine now and it extracts the updater packages v1.62.02 and v1.30.02 too. Great work! Where was the problem?
Unfortunately, I haven't still succeeded in setting up a working environment under Windows: I've tried with MinGW but, though the build process with cmake succeeds, when I try to make the executables I still get many errors... As soon as I would have some spare time, I would try with Microsoft Visual Studio 2008 Express... Have a good day! :)

---EDIT---

I've tried to flash the v1.62.02 and v1.30.02 firmwares extracted by the newer update_extract version to my ZVM: both CreativeWizard and the hacked firmware updater succeed in flashing the 1.62.02 version but not the 1.30.02 (exactly the one I was interested in :( ).
This means that update_extract correctly extracts the firmware file (otherwise the firmware v1.60.02 shouldn't be flashed too) but I don't understand what's wrong with the firmware v1.30.02. I've noticed that the file size is the greatest (21,4Mb) among all the firmwares I've seen: perhaps the problem is there and CW nor the hacked updater can handle such a big firmware file (maybe they truncate the firmware file...).
I've tried also the older versions of CW but they don't even recognize my player (though CW v0.8.4.0, Windows and Creative Media Explorer do).
Try opening it with CreativeWizard and see if it can recognize the format...

Then try calculating the checksum and see if it's correct with the one in the NULL block

BTW why can't you just use the original fw updater which contains v1.30.02 ?
Title: Re: Creative Zen Vision:M
Post by: GuybrushThreepwood on August 26, 2008, 03:24:56 AM
Try opening it with CreativeWizard and see if it can recognize the format...

It recognizes and opens the firmware.

Then try calculating the checksum and see if it's correct with the one in the NULL block

I don't know if I've calculated the checksum well (I've used CW with the default key 'CTL:N0MAD|PDE0.DPMP.') but the checksum doesn't correspond to that in the null block while it corresponds for the other firmwares I've tested. What's wrong??? I've thoroughly tested update_extract and I'm almost sure that now it works as expected so where is the problem?

BTW why can't you just use the original fw updater which contains v1.30.02 ?

Because, as said, my ZVM is faulty and, among the other issues I'm working on, it doesn't correctly reports the battery charge level and the v1.30.02 updater package hangs up on the low battery warning (it's impossible to ignore it like with the newer versions also when the player is connected to the AC adapter).

p.s. You haven't told me what was wrong with the older update_extract version. I'd like to know it if you want. Have a good day!
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 26, 2008, 08:27:59 AM
It recognizes and opens the firmware.
I get the same result..
Quote
I don't know if I've calculated the checksum well (I've used CW with the default key 'CTL:N0MAD|PDE0.DPMP.') but the checksum doesn't correspond to that in the null block while it corresponds for the other firmwares I've tested. What's wrong??? I've thoroughly tested update_extract and I'm almost sure that now it works as expected so where is the problem?
I also get the same result with CreativeWizard, but if you try zen_crypt it reports the checksum is correct.. (keep in mind CreativeWizard is my code & ZenUtils is zook's; so there could be some mistakes in mine)

I also decrypted FRESC (v.1.30.02) and checked for the checksum key and it's exactly the same; so that can't be the problem either.
Quote
Because, as said, my ZVM is faulty and, among the other issues I'm working on, it doesn't correctly reports the battery charge level and the v1.30.02 updater package hangs up on the low battery warning (it's impossible to ignore it like with the newer versions also when the player is connected to the AC adapter).
Try using other/older versions? I found this site (http://dapjukebox.altervista.org/modules.php?name=Downloads&d_op=viewdownload&cid=102&min=10&orderby=dateD&show=10).
Quote
p.s. You haven't told me what was wrong with the older update_extract version. I'd like to know it if you want. Have a good day!
The problem was the find_firmware_offset() routine, like I explained previously.
Title: Re: Creative Zen Vision:M
Post by: GuybrushThreepwood on August 26, 2008, 10:15:32 AM
I also decrypted FRESC (v.1.30.02) and checked for the checksum key and it's exactly the same; so that can't be the problem either.

What do you mean by "FRESC"? Excuse me for the dumb question! :-[ I'm wondering if CW checks the correspondence between the checksum and the checksum stored in the NULL block and, if the check fails, doesn't go on with uploading the firmware... I think it could be a useful check but I don't know if you've included it: that's why I'm just guessing.
Maybe even the hacked updater makes that check... I don't know.

Try using other/older versions? I found this site (http://dapjukebox.altervista.org/modules.php?name=Downloads&d_op=viewdownload&cid=102&min=10&orderby=dateD&show=10).

It's exactly the place I get older firmwares from! ;) All the older firmwares have that check on the battery level which isn't possible to ignore... :(

The problem was the find_firmware_offset() routine, like I explained previously.

Thanks for letting me know!
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 26, 2008, 10:19:04 AM
What's FRESC? Excuse me for the dumb question! :-[ I'm wondering if CW checks the correspondence between the checksum and the checksum stored in the NULL block and, if the check fails, doesn't go on with uploading the firmware... I think it could be a useful check but I don't know if you've included it: that's why I'm just guessing.
Maybe even the hacked updater makes that check... I don't know.
FRESC is the code which contains Rescue Mode (this is all documented on the wiki page (http://rockbox.org/wiki/CreativeZVMPort)).

CreativeWizard doesn't do any checksum verification whilst uploading; nor does the original/hacked firmware updater.
Title: Re: Creative Zen Vision:M
Post by: GuybrushThreepwood on August 26, 2008, 10:23:07 AM
FRESC is the code which contains Rescue Mode (this is all documented on the wiki page (http://rockbox.org/wiki/CreativeZVMPort)).

Thanks for telling me!

CreativeWizard doesn't do any checksum verification whilst uploading; nor does the original/hacked firmware updater.

If so, I don't know why I can't upload the 1.30.02 firmware...
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 26, 2008, 10:24:37 AM
CreativeWizard doesn't do any checksum verification whilst uploading; nor does the original/hacked firmware updater.

If so, I don't know why I can't upload the 1.30.02 firmware...
Well, the player itself does...

Have you tried updating the checksum to what CW reports it should be?
Title: Re: Creative Zen Vision:M
Post by: GuybrushThreepwood on August 26, 2008, 10:32:53 AM
Have you tried updating the checksum to what CW reports it should be?

It was my first tought but CW doesn't let me modify the checksum value in the NULL block...

---EDIT---

I've extracted the firmware files from the updater packages v1.30.02, v1.41.01 and v1.51.01 downloadable at the address that you also know.
The extraction process went fine but the checksum check between the one calculated by CW and the one in the NULL block fails for all of them and I can't upload them by CW nor the hacked updater. All the other firmwares (which passed the checksum check) can be uploaded with no issues.
It seems to me that there is some kind of connection between the checksum issue and the upload issue...
Title: Re: Creative Zen Vision:M
Post by: Transience on August 26, 2008, 11:53:53 PM
010 editor will open the device if i put it into removable disk mode, but it will only show the removable disk partition. The device is capable of formatting itself into FAT32. Perhaps the creative firmware could be modified to begin formatting at the root of the drive instead of the default location? just a thought...
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 27, 2008, 03:53:20 AM
Have you tried updating the checksum to what CW reports it should be?

It was my first tought but CW doesn't let me modify the checksum value in the NULL block...

---EDIT---

I've extracted the firmware files from the updater packages v1.30.02, v1.41.01 and v1.51.01 downloadable at the address that you also know.
The extraction process went fine but the checksum check between the one calculated by CW and the one in the NULL block fails for all of them and I can't upload them by CW nor the hacked updater. All the other firmwares (which passed the checksum check) can be uploaded with no issues.
It seems to me that there is some kind of connection between the checksum issue and the upload issue...
Try using the ZenUtils (zen_crypt has the ability to (re-)sign a firmware and other stuff).

010 editor will open the device if i put it into removable disk mode, but it will only show the removable disk partition. The device is capable of formatting itself into FAT32. Perhaps the creative firmware could be modified to begin formatting at the root of the drive instead of the default location? just a thought...
Even if we would do that, what's the benefit? The OF and recovery mode won't be able to read it so the device will just give a HDD HW error..

And 'The device is capable of formatting itself into FAT32' statement is correct; but that's all there is.
Only formatting, so no read/write/... FAT32 capabilities.

The current idea is to use the Virtual File System image (=Removable Disk Mode) and to get Rockbox to locate and read from this.

This would mean dual-boot capability and access to Rockbox's files without taking your HDD out.
Title: Re: Creative Zen Vision:M
Post by: GuybrushThreepwood on August 27, 2008, 09:27:06 AM
Try using the ZenUtils (zen_crypt has the ability to (re-)sign a firmware and other stuff).

The only zen_crypt function I can take advantage of seems to be the signature function. I've used the -s switch and tried to resign the firmwares but it didn't help. The checksum stored in the null block is still the same and is wrong. Perhaps the -s switch affects other informations stored in the file...
I've noticed another thing (perhaps it could be interesting): all the firmwares with the right checksum are below the 21Mb barrier (they all are 20,7Mb worth) while the ones with the bad checksum are above that barrier (the file size is, respectively, 21,4Mb, 21,5Mb, 21,8Mb for fw v1.30.02, v1.41.01, v1.51.01).

p.s. I've forgotten to report that, when making the binaries, I get some warnings about, if I remember well, characters. Now I'm on a Windows machine and can't check what's the precise error... I don't think it's a problem but I've reported it for the sake of completeness.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 27, 2008, 03:54:39 PM
I just committed the beginning of dual-boot capability to SVN and now you're able to run Rockbox (well not exactly) *without* taking your hard drive out :)

I've updated the installation instructions on the wiki (http://www.rockbox.org/twiki/bin/view/Main/CreativeZVMPort#Install_method).

Currently, the only thing the bootloader does is loading the original firmware. But whenever quetzalcoatl figures out the CFS file system, we should be able to run a FAT file system as a file on the CFS file system.

The only zen_crypt function I can take advantage of seems to be the signature function. I've used the -s switch and tried to resign the firmwares but it didn't help. The checksum stored in the null block is still the same and is wrong. Perhaps the -s switch affects other informations stored in the file...
I've noticed another thing (perhaps it could be interesting): all the firmwares with the right checksum are below the 21Mb barrier (they all are 20,7Mb worth) while the ones with the bad checksum are above that barrier (the file size is, respectively, 21,4Mb, 21,5Mb, 21,8Mb for fw v1.30.02, v1.41.01, v1.51.01).

p.s. I've forgotten to report that, when making the binaries, I get some warnings about, if I remember well, characters. Now I'm on a Windows machine and can't check what's the precise error... I don't think it's a problem but I've reported it for the sake of completeness.
Weird. But I'm pretty sure the file size increase doesn't really matter.

edit:
@quetzalcoatl:
For some reason, all numbers were little endian instead of big endian in my disk dumps and on the real device. Are you sure they should be big endian?

Solved
Title: Re: Creative Zen Vision:M
Post by: GuybrushThreepwood on August 27, 2008, 04:30:17 PM
I've tried with nullblockfixer too: it reads the checksum in the Null block and leaves it there (perhaps it finds it correct).
Title: Re: Creative Zen Vision:M
Post by: grooveharder on August 27, 2008, 06:38:17 PM
well, i've just tried the install instructions on the wiki, and it works like a charm... (well, after some playing with gentoo's cross-compile system!) it boots without a hitch. the sendfirm utility even works well with "font firmwares" created by creativewizard.

congratulations - this seems like a big milestone, no? i'd say being able to install some sort of Rockbox code on the Zen "*without* taking your hard drive out" is good progress!

thanks for everyone's work on the project. surely we are not far away from full Rockbox on the Zen now.
Title: Re: Creative Zen Vision:M
Post by: quetzalcoatl on August 28, 2008, 08:25:16 AM
@quetzalcoatl:
For some reason, all numbers were little endian instead of big endian in my disk dumps and on the real device. Are you sure they should be big endian?

Solved
i still wonder how i mistook them, i'll fix the notes asap, thanks for pointing it out.
taking current reallife thing into calculations, CFS will take at least next 2 weeks. i'm sorry, i just literally have no free time now. i'll post as soon as start comparing new and old volumes' images
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 28, 2008, 07:18:16 PM
Windows builds are now available for mkzenboot & sendfirm on the wiki page (http://www.rockbox.org/twiki/bin/view/Main/CreativeZVMPort#Install_method)... (+ instructions on Windows)

+ now it's possible to use mkzenboot on the ZVM60GB & ZV
Title: Re: Creative Zen Vision:M
Post by: saratoga on August 28, 2008, 07:55:54 PM
Not sure if anyone has noticed this already, but theres a little bit about the TI TLV320AIC23BZ in the patch for the linux modifications used in the SansaConnect here:

http://www.rockbox.org/twiki/pub/Main/SansaConnect/sansaconnect-2.6.4.patch.bz2

Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 29, 2008, 07:10:24 AM
@quetzalcoatl:
I made this (http://mcuelenaere.pastebin.com/f40c28c59) small CFS parser..

Not sure if anyone has noticed this already, but theres a little bit about the TI TLV320AIC23BZ in the patch for the linux modifications used in the SansaConnect here:

http://www.rockbox.org/twiki/pub/Main/SansaConnect/sansaconnect-2.6.4.patch.bz2


I've seen it and it also contains TMS320DM320 info but I haven't had the time yet to look through it thoroughly..
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 29, 2008, 06:26:56 PM
I am very, very close to getting the VFAT thing to work.

Good news is that all the data is in sectors of 0x8000 (=64*512) and almost all sectors are next to each other so performance won't be that bad (I'll be using an array anyway to be safe though).

This (http://mcuelenaere.pastebin.com/f4a835c10) is what I currently have (it's capable of extracting the VFAT files out of a disk dump, but not in the right order and/or with other problems.

This (http://mcuelenaere.pastebin.com/f4e336207) is a little description (for nomadrawexplore\notes\cfs) of the new structures not already described publicly.
Title: Re: Creative Zen Vision:M
Post by: quetzalcoatl on August 30, 2008, 11:06:26 AM
prior to line246 you are esentially obtaining the inode number of 'vfat' entry in the root directory -- thats lines 241-242.

having it, you read the inode (line254-255) and then fseek on its firstclasschain[0] and then, from this position you fread into structure CFS_DIRENTRY.

is it right? if you have obtained the virtualvolume file's inode, the very file should lie in this cluster, not an another cfs directory.
otherwise, if it is a directory for example for virtualvolumes, then why arent you searching for the right one?

instead of searching, what you do next, is scanning through the 'vfat files' and collect theirs inodes' numbers into array 'vfat_inodes', skipping the first - why doing so? the direntry#1 should be nothing special, just an entry like any other

okay, assuming that all above was correct, you now essentially have a 'vfat_inodes' array that holds all inodes of all files under /VFAT directory in the CFS volume

then, foreach file, you gather its dataclusters' numbers from the first/second/thirdclass chains correctly

(i've now noticed that my notes aren't the _latest_.. i must have lost the latest ones, because on those i have found and published there's a:
  uint32 first_class_chain
  uint32 second_class_chain_first_cluster
  uint32 second_class_chain_second_cluster
what you probably noticed thats to Tobia's site is not true. the diagram:
  inode
   \_ up to 12 data clusters (some of which might be set to -1)
   \_ second class chain cluster (seems to always be allocated)
  (......)
is taken almost directly from an email i sent him once..
its' really
  uint32 first_class_chain
  uint32 second_class_chain_clusterid
  uint32 third_class_chain_clusterid
and you took it right)


and finally, you copy all the dataclusters from all files in VFAT into a single huge file.. i suppose thats for debugging only? this surely does not produce a valid content

oh, and you're not using any bitmaps at all [and there's a lot of them everywhere!]. i think you should.. the files you are analyzing supposedly are rarely moved anywhere, but yo unever know which entry in directory/inodes/blah would be disabled via the bitmap

i'll have probably few hours today, so i'll look in that vfat direcotry-to-be and its contents. littlebit strange that they put such directory and files inside. does the ZenVisionM support multiple virtualvolumes on it? or does the directory contain a single file only?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on August 30, 2008, 12:29:45 PM
prior to line246 you are esentially obtaining the inode number of 'vfat' entry in the root directory -- thats lines 241-242.

having it, you read the inode (line254-255) and then fseek on its firstclasschain[0] and then, from this position you fread into structure CFS_DIRENTRY.

is it right? if you have obtained the virtualvolume file's inode, the very file should lie in this cluster, not an another cfs directory.
I have to admit, I haven't commented the file really.
The structure is like this:
root inode -> VFAT dir -> * VFSYS
                                        * vfile_00
                                        * vfile_01

The VFSYS file contains another (unknown) structure with inode references to vfile_00 & vfile_01 + some kind of partitioning info how the total file is divided (see struct cfs_vfat)
Quote
otherwise, if it is a directory for example for virtualvolumes, then why arent you searching for the right one?
I am, but there are several files containing the volume
Quote
instead of searching, what you do next, is scanning through the 'vfat files' and collect theirs inodes' numbers into array 'vfat_inodes', skipping the first - why doing so? the direntry#1 should be nothing special, just an entry like any other
Ok, perhaps I'm wrong here (I haven't looked into what filesystem bitmaps are), but these two inodes (vfile_00 & vfile_01) contain inode numbers (which contain the data of the virtual volume).
Quote
okay, assuming that all above was correct, you now essentially have a 'vfat_inodes' array that holds all inodes of all files under /VFAT directory in the CFS volume
Correct.
Quote
then, foreach file, you gather its dataclusters' numbers from the first/second/thirdclass chains correctly

(i've now noticed that my notes aren't the _latest_.. i must have lost the latest ones, because on those i have found and published there's a:
  uint32 first_class_chain
  uint32 second_class_chain_first_cluster
  uint32 second_class_chain_second_cluster
what you probably noticed thats to Tobia's site is not true. the diagram:
  inode
   \_ up to 12 data clusters (some of which might be set to -1)
   \_ second class chain cluster (seems to always be allocated)
  (......)
is taken almost directly from an email i sent him once..
its' really
  uint32 first_class_chain
  uint32 second_class_chain_clusterid
  uint32 third_class_chain_clusterid
and you took it right)


and finally, you copy all the dataclusters from all files in VFAT into a single huge file.. i suppose thats for debugging only? this surely does not produce a valid content
No that's not for debugging, I *thought* that all these dataclusters together merged to the virtual volume..
Quote
oh, and you're not using any bitmaps at all [and there's a lot of them everywhere!]. i think you should.. the files you are analyzing supposedly are rarely moved anywhere, but yo unever know which entry in directory/inodes/blah would be disabled via the bitmap
As I'm not familiar with this, I haven't used them nor found them (all this file system is stuff is completely new to me).
Quote
i'll have probably few hours today, so i'll look in that vfat direcotry-to-be and its contents. littlebit strange that they put such directory and files inside. does the ZenVisionM support multiple virtualvolumes on it? or does the directory contain a single file only?
Thanks.
No, the ZenVisionM doesn't support multiple virtualvolumes but AFAI understand the virtual volume is divided into vfile_0x files.
Title: Re: Creative Zen Vision:M
Post by: quetzalcoatl on August 30, 2008, 03:01:52 PM
divided? it seems.. pointless. i didn't got there today, but i updated the notes with information on the cfs's "header".

new interesting things on CFS
- cluster on NJB is 0x10 sectors, on ZVM - 0x40 sectors
- CFS's adresation is actually overlapping with MINIFS: CFS's physical sector 0x000000 is seen by CFS as a *second* sector of its very first physical cluster, and the last sector of MINIFS is seen as that first sector.. This is why the first cluster is never-ever used, and logical ID of -1/0xFFFFFFFF and filled with 0x00s or 0xFFs
- cluster 0x02 contain volume-specific information, and cluster 0x03 probably too. for now, i'll call them volumeinformation1 (VI1) and volumeinformation2 (VI2) respectively

the VI1 contains very important information. currently known are:
- cluster size
- volumesize
- signature 'BFS1' :)
- root directory inode number! no more hardcoding!
- timestamp. what did you do on 2005-08-01 01:51:07 ?:) that probably was the time when the drive was formatted and volume created

----------
and the bitmaps [notes/minifs/bitmaps.txt]
all, or almost all of the lists that must be traversed does have a special 'bitmap' that tells which entries are used and which are free. there are for example:
- drive:cluster bitmap <-> all clusterchains
- a directory:direntry bitmap<-> that directory's list of entries
and may be others, i dont recall right now.

each entry on the list has a zero-based position. so does the bits on the bitmap. each bit tells if the entry is used. bit=0 indicates that it is free, bit=1 that it is used, for example:

having a dir entries' list:
0 empty
1 empty
2 somefilename
3 empty
4 somefilename
5 somefilename
6 empty
7 empty
8 SoMeFiLeNaMe
9 empty
A somefilename
B somefilename
C somefilename
D somefilename
E empty
F somefilename
the bitmap would contain: 0 0 1 0 1 1 0 0 1 0 1 1 1 1 0 1, that is b1011110100110100, that is 0xBD34

BUT, would the bitmap actually contain 0xBC34, that would mean, that the SoMeFiLeNaMe entry if free - despite having well-looking contents! - for example, the file could have been deleted long time ago and its unlinked data could have already be overwritten with new content

the same follows with cluster bitmap. the cluster bitmap is a bitmap that indexes whole volume's clusterspace. each cluster does have a corresponding bit in the bitmap and is subject to be checked against it. if a clusterchain contains an clusterid which is marked as free (bit=0), this clearly indicates that the chain and/or the bitmap has been corrupted. this is serious, because when new files are written/added to the volume, the system searches for free space using the *bitmap*. actually, this is the main reason for its existence: looking for holes that may be reused. traversing a list of 0/1 bits is waaay faster than scanning clusterchains and looking which clusterids are unused

---------
i have started looking into CFS directory structure. the whole volume format matches the old one, with respect to changed clustersize. the inodes' and directories' structure is the same, too. the directories take 1632 entries in total of 0x80 sectors which translates to 8clusters in NJB and 2 clusters in ZVM.

on yours (mcuelenaere) drive image, in the root directory, I have found several new entries:
    inode=0x00000009, fnlen = 0x0008, unk = 0x0002, {archives\0,}    [old]
    inode=0x0000000E, fnlen = 0x0003, unk = 0x0002, {pim\0,}            [new!]
    inode=0x00000013, fnlen = 0x0009, unk = 0x0002, {playlists\0,}     [old]
    inode=0x00000018, fnlen = 0x000A, unk = 0x0002, {recordings\0,} [old]
    inode=0x0000001D, fnlen = 0x0005, unk = 0x0002, {songs\0,}        [old]
    inode=0x00000022, fnlen = 0x0006, unk = 0x0002, {system\0,}     [old]
    inode=0x00000027, fnlen = 0x0006, unk = 0x0002, {photos\0,}     [new]
    inode=0x0000002C, fnlen = 0x0006, unk = 0x0002, {videos\0,}     [new]
    inode=0x00000031, fnlen = 0x0004, unk = 0x0002, {vdir\0,}       [new]
    inode=0x00000036, fnlen = 0x0005, unk = 0x0002, {vrefs\0,}    [new]
    inode=0x0000003B, fnlen = 0x0004, unk = 0x0002, {VFAT\0,}     [new]
    inode=0x00000044, fnlen = 0x0006, unk = 0x0002, {albums\0,}     [new]
    inode=0x00000000,

please note the vdir, vrefs, VFAT:

vdir is a directory, with 9 valid entries, but the entries' filenames are "damaged" (instead of the name, 0xE59FF018 is repeated)

vrefs - unknown. inode looks like a inode of a directory. contents - are almost totally zeroed. if it is a directory, it is empty

vfat - a directory, with ONE entry named VFSYS [bingo]. so.. you might have something wrong in your reader - as it was told, your reader reports several files here. maybe you misplaced the directory for vdir somewhere?

--------
to speedup your searches - on the CF122,25mb image you have sent me:
- the contents of VFAT directory are on drive's physical sector
- the direntry for VFSYS file is:  {inode=0x00000040, fnlen = 0x0005, unk = 0x0001, {VFSYS\0,} }
- the VFSYS file's inode is on sector
- the VFSYS file's clusters are ... , 100% consecutively :)

on the image the VFSYS file has is 0x30 bytes, as follows:
Code: [Select]
Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00000000   03 00 B0 00 54 41 46 56  00 00 00 00 00 00 00 00   ..°.TAFV........
00000010   00 00 00 00 00 00 00 00  00 00 00 00 FF FF FF FF   ............˙˙˙˙
00000020   00 00 00 00 00 00 00 00  00 00 00 00 FF FF FF FF   ............˙˙˙˙

...small, eh? had construction of the virtualvolume on CF card failed?

-----
to get to the VFSYS file's inode:
- determine raw position of the CFS
- read root directory inode (1 cluster, 64sectors)
- read the two clusters firstclasschain[0] and firstclasschain[1] (2*64 sectors) that contain the root directory
- find VFAT entry
- store te inode numer from that entry
- read that inode
- read the two clusters firstclasschain[0] and firstclasschain[1] (2*64 sectors) that contain the vfat directory
- find VFSYS entry
- store te inode numer from that entry
- read that inode
hurray, you have the file(s)
Title: Re: Creative Zen Vision:M
Post by: megaman2000 on September 04, 2008, 02:13:10 PM
excuse me i am new to all of this so i am a noob sorry but i have a issue with building the rockbox.zvmboot file for the 60gb creative xen vision m. i made a 30gb rockbox.zvmboot no problem but the 60gb wont work. this is my first time using linux so just to let you know. if there is any way to post files here i have nk.bin ready for a 30gb zen vision m whoever wants it here is my error if someone can help me i sure would greatly appreciate it.

LD bootloader.elf
/home/user/rockbox/build_creative/firmware/target/arm/tms320dm320/crt0.o: In function 'start_loc':
target/arm/tms320dm320/crt0.S:(.init.text+0x70): undefined reference to 'main'
collect2: ld returned 1 exit status
make[1]: *** [home/user/rockbox/build_creative/bootloader/bootloader.elf] Error 1
make: *** [build] Error 2
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on September 04, 2008, 02:53:36 PM
excuse me i am new to all of this so i am a noob sorry but i have a issue with building the rockbox.zvmboot file for the 60gb creative xen vision m. i made a 30gb rockbox.zvmboot no problem but the 60gb wont work. this is my first time using linux so just to let you know. if there is any way to post files here i have nk.bin ready for a 30gb zen vision m whoever wants it here is my error if someone can help me i sure would greatly appreciate it.

LD bootloader.elf
/home/user/rockbox/build_creative/firmware/target/arm/tms320dm320/crt0.o: In function 'start_loc':
target/arm/tms320dm320/crt0.S:(.init.text+0x70): undefined reference to 'main'
collect2: ld returned 1 exit status
make[1]: *** [home/user/rockbox/build_creative/bootloader/bootloader.elf] Error 1
make: *** [build] Error 2

Sorry about that, I just fixed this in SVN. (do 'svn up')
Title: Re: Creative Zen Vision:M
Post by: megaman2000 on September 04, 2008, 02:57:12 PM
due u are the man i super appreciate it ill let u know if it works
Title: Re: Creative Zen Vision:M
Post by: AlexP on September 04, 2008, 03:16:25 PM
As per the forum guidelines, please use real words here - not things like "u".

It would also make your posts much easier to read if you used capitals and punctuation.

Thankyou! :)
Title: Re: Creative Zen Vision:M
Post by: megaman2000 on September 04, 2008, 07:20:23 PM
Well I was able to build the rockbox.zvm60boot. but mkzenboot cannot decrypt it any suggestions.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on September 04, 2008, 07:28:40 PM
Well I was able to build the rockbox.zvm60boot. but mkzenboot cannot decrypt it any suggestions.

You did try doing
Code: [Select]
./mkzenboot ZENVisionM_60GB_PCFW_Lxx_x_xx_xx.exe ../build/rockbox.zvm60boot nk.bin "Zen Vision:M 60GB"instead of
Code: [Select]
./mkzenboot ZENVisionM_30GB_PCFW_L21_1_62_02.exe ../build/rockbox.zvmboot nk.bin "Zen Vision:M", right?
Title: Re: Creative Zen Vision:M
Post by: megaman2000 on September 04, 2008, 07:29:47 PM
Yes I did. Also I tried the windows version.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on September 04, 2008, 07:47:13 PM
Yes I did. Also I tried the windows version.
I have the same problem...
The problems seems to be caused by the key which is used ('1sN0TM3D az u~may th1nk*Creative Zen Vision:M (DVP-HD0004') who's too long (maximum length=56) for Blowfish in CBC mode..

This should be solved by finding another Blowfish implementation (which correctly allows bigger keys), but that's something for tomorrow!
Title: Re: Creative Zen Vision:M
Post by: megaman2000 on September 04, 2008, 07:51:35 PM
OK well I will be waiting thanks a million
Title: Re: Creative Zen Vision:M
Post by: jonsey on September 05, 2008, 05:39:32 AM
if i want to install the rockbox i need the rockbox.zvmboot...where i can find it?!

C:\Zen>mkzenboot ZENVisionM_30GB_PCFW ecc ecc
[INFO] .data section is at 0x5e000 wi
[INFO] Firmware offset is at 0x5e0c0
[INFO] Firmware key is 34d122FD84fc7C
[INFO] Descrambling firmware... Done!
[INFO] Decompressing firmware... Done
[ERR]  Could not open rockbox.zvmboot

Please help!I use WIN XP PRO...

Thanks :)
Title: Re: Creative Zen Vision:M
Post by: GodEater on September 05, 2008, 05:45:12 AM
I suspect you'll need a build environment, and roll your own.
Title: Re: Creative Zen Vision:M
Post by: megaman2000 on September 07, 2008, 03:24:43 AM
So has the decryption error for the zen vision m 60gb rockbox.zvm60boot been fixed?
Title: Re: Creative Zen Vision:M
Post by: jonsey on September 07, 2008, 04:46:07 AM
Problem!
After the uploading,and after the reboot i can see something on the screen...it says...
RockBox boot loader...
version r18405-080904
loading creative firmware


and after always the same original firmware  ??? ??? :-[
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on September 07, 2008, 05:48:02 AM
So has the decryption error for the zen vision m 60gb rockbox.zvm60boot been fixed?
No(t yet).

As I'm not really into cryptography, this could be rather hard.
AFAICS, Blowfish in CBC mode only supports keys up to 56-bit (and this key is a bit larger).

@all:

Currently Rockbox is not yet available to users! All what the Rockbox bootloader does, is loading the _Original Firmware_!

Because of technical limitations (blame Creative!), we can't put Rockbox on the device (yet) without taking your hard drive out...
Title: Re: Creative Zen Vision:M
Post by: jermey on November 22, 2008, 03:39:13 PM
but im curious is this zvm port already functional i mean playing music. i dont care about glitchy buttons driver
Title: Re: Creative Zen Vision:M
Post by: karashata on November 22, 2008, 03:43:36 PM
Currently Rockbox is not yet available to users! All what the Rockbox bootloader does, is loading the _Original Firmware_!

I'd say that's a "No, it's not functional yet" if I've ever seen one.
Title: Re: Creative Zen Vision:M
Post by: jermey on November 23, 2008, 06:03:15 AM
I am just asking because long time ago i had rockbox running on my ZVM but there was no sound etc... just menus and very glitchy button driver which stopped my further testing (plugins etc.), so yes rockbox is not officially relased but there are experimental dev builds and my question is that builds are functional. I could check it by my self but its a lot of work to open my Zen connect hdd via ZIF<->USB connector, backup all data and then compile and put rockbox on it. So I would be glad if some developer (preferably mcuelenaere) said what the newest build can do.
Title: Re: Creative Zen Vision:M
Post by: Llorean on November 23, 2008, 06:07:35 AM
Frankly, if you're not going to be developing, you don't need to be posting in this thread. When there's a build that works, it'll move into "supported" and be on the front page of this site.
Title: Re: Creative Zen Vision:M
Post by: clippey on November 23, 2008, 11:48:27 AM
I can try to look into the blowfish decrypt problem, I have starting learning about cryptology, hopefully I can finally put it to some good use.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on November 23, 2008, 04:27:23 PM
@all:
The status of the project hasn't changed since my last post (07-09-2008):

Rockbox is not available to end-users, but if you're really interested you can always try to install it; though it lacks all major DAP features (including no music playback).

The lack of understanding CFS is blocking an 'easy' installation of Rockbox, the lack of developers/developing efforts(including myself) is blocking the other parts of the port.

I'm not saying I'm not interested anymore, it's just that I'm not as motivated and having less Rockbox time available as I used to..

About the CFS problem: last time I talked to quetzalcoatl, he said he was close to fixing it; but as I haven't talked to him anymore I haven't looked into the issue anymore.

(More technical): AFAIK, the problem was that reconstructing files to clusters; so we could use the 'Virtual File System' (aka external disk drive/UMS mode) as a place to store our Rockbox FAT file system.
I believe all code is in SVN, or at least posted 'somewhere' online at the Rockbox site, and it's very close to working perfectly. (pointers: linky (http://svn.rockbox.org/viewvc.cgi/trunk/firmware/target/arm/tms320dm320/creative-zvm/ata-creativezvm.c?view=markup) and linky (http://nomadrawexplore.svn.sourceforge.net/viewvc/nomadrawexplore/))

Actually, we almost have all the pieces to fit the puzzle, just one or two are still missing to get the ZVM to at least boot Rockbox and possibly manouvre in it.
Title: Re: Creative Zen Vision:M
Post by: Aurix Lexico on December 03, 2008, 05:39:10 PM
Hello,

I know a bit of C I learned myself, mostly as a hobby. I just checked out the latest SVN, compiled the UI Simulator, and noticed that there are no plugins for the ZVM 30GB. Mcuelenaere asked for someone to try to add keymaps to the plugins back on page 38. Is the lack of plugins for the ZVM due to someone not spending some time adding keymaps for the plugins or some deeper problem? If it's the former, I wouldn't mind spending some time attempting to add the keymaps myself, I just need someone to point me in the right direction.

Thanks for all your work on porting rockbox to the ZVM.
Title: Re: Creative Zen Vision:M
Post by: funman on December 03, 2008, 06:16:54 PM
Hi

In most plugins you just have to define a keymap, and in some others you will need to set up screen sizes, perhaps edit some bitmaps, so you can definitely help by defining keymaps and testing plugins in the simulator.

Just enable plugins in the build (see tools/configure) and run make, edit the first plugin that breaks, run make again, etc ..

Hope that clears a bit
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on December 03, 2008, 06:28:15 PM
(Keep in mind that the keys currently aren't working on the device itself, so you won't be able to test the plugins (if you would get Rockbox installed that is))
Title: Re: Creative Zen Vision:M
Post by: Aurix Lexico on December 03, 2008, 09:40:44 PM
Whew, that took longer than I expected. All the plugins compile, and I was playing with a couple in the UI Simulator. Everything I tried worked ok. The keys are a bit inconsistent, I'll try to fix that when I have more time.

Link to my diff: http://www.mediafire.com/download.php?mio1mtczzxm
Title: Re: Creative Zen Vision:M
Post by: LambdaCalculus on December 03, 2008, 10:36:21 PM
Your patch is now on Flyspray, where it'll be safer. :)

See FS#9605 (http://www.rockbox.org/tracker/task/9605).

(EDIT) Committed!
Title: Re: Creative Zen Vision:M
Post by: Aurix Lexico on December 07, 2008, 06:20:18 PM
(Keep in mind that the keys currently aren't working on the device itself, so you won't be able to test the plugins (if you would get Rockbox installed that is))

Just curious, but what would be required to get the buttons working?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on December 07, 2008, 06:25:07 PM
(Keep in mind that the keys currently aren't working on the device itself, so you won't be able to test the plugins (if you would get Rockbox installed that is))

Just curious, but what would be required to get the buttons working?
Figuring out how the ZVM communicates with the PIC microcontroller (see the wiki for some information).

The buttons (and other stuff) is connected to a separate microcontroller, which 'talks' with the ZVM's main CPU over I²C. The problem is that we need to figure out what 'language' they're speaking..

I can receive button events from the PIC (ie when I press up, I get for example 0x20 as response), but the problem is these values can change when the OF has communicated with it; meaning the OF probably sets some kind of values in the PIC, which changes the responses that the PIC sents.
Title: Re: Creative Zen Vision:M
Post by: Aurix Lexico on December 12, 2008, 05:40:18 PM
Have you tried writing to the PIC over i2c? Instead of figuring out what the OF does to the PIC, can you try sending something (a single zero perhaps?) to the PIC in hopes of reseting the numbers it returns for a button press? I would try it myself, but I won't be able to install rockbox on my zen till after christmas, when I will buy a CF card and adapter.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on December 12, 2008, 07:57:18 PM
Have you tried writing to the PIC over i2c? Instead of figuring out what the OF does to the PIC, can you try sending something (a single zero perhaps?) to the PIC in hopes of reseting the numbers it returns for a button press? I would try it myself, but I won't be able to install rockbox on my zen till after christmas, when I will buy a CF card and adapter.
I *think* I tried writing stuff to it, but never got anything really useful out it.

BTW, you can try the Rockbox bootloader without breaking anything on your device (the bootloader has capabilities of booting the OF, and as the bootloader is 'our' code you can use it to write to the PIC).

If you need any help in this, ask me :)
Title: Re: Creative Zen Vision:M
Post by: Aurix Lexico on December 13, 2008, 07:43:55 PM
The rockbox bootloader is now on my zen. Before I start editing the bootloader, is there a way to recover from me messing up the bootloader? And can you point to a source file that is a good example for reading/writing with I2C.
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on December 13, 2008, 08:18:47 PM
The rockbox bootloader is now on my zen. Before I start editing the bootloader, is there a way to recover from me messing up the bootloader?
Yes, just boot into the recovery mode and replace the firmware with either the Rockbox bootloader again or the OF.

Quote
And can you point to a source file that is a good example for reading/writing with I2C.
pic-creativezvm.c (http://svn.rockbox.org/viewvc.cgi/trunk/firmware/target/arm/tms320dm320/creative-zvm/pic-creativezvm.c?view=markup) contains the code which communicates with the PIC.

Using i2c_read(0x07, unsigned char* data, int length) and i2c_write(0x07, unsigned char* data, int length) you can communicate with it directly.

GIO0 is triggered by the PIC when it's about to send a message, so GIO0() is the message handler (in pic-creativezvm.c).

You probably want to enable BUTTON_DEBUG so you can see what messages the PIC sends to the ZVM.

I think send_command_to_pic() is meant to mimic the OF for sending a message to the PIC, so you could try using that.
Title: Re: Creative Zen Vision:M
Post by: imfloflo on December 14, 2008, 06:55:37 AM
So we can change the bootloader without opening tje device :)?

And change the firmware to the alternative rockbox?
Title: Re: Creative Zen Vision:M
Post by: fejfighter on December 14, 2008, 07:24:05 AM
no, not yet.
only the boot loader can be changed right now. which then loads the creative firmware

@mcuelenaere
other ideas to get around the cfs problem i had thought of:
instead of finding a method to read it
-getting the usb driver to work then format the drive on a computer
-or write a formatter system into a bootloader for installation purposes.
i think i will lean to try and get the the first one done, if a method of communicating is found.
every attempt i had last night i couldnt get a consistant response from components, at one stage i had scroll up recognised as the hold switch...

keep up the good work,
hopefully i can find something of use!
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on December 14, 2008, 09:07:34 AM
no, not yet.
only the boot loader can be changed right now. which then loads the creative firmware

@mcuelenaere
other ideas to get around the cfs problem i had thought of:
instead of finding a method to read it
-getting the usb driver to work then format the drive on a computer
I tried that approach for quite some time, but got stuck. I think the USB driver gets as far as sending some control messages on endpoint 0 and that's it (see this (http://www.beyondlogic.org/usbnutshell/usb1.htm) site for more info about USB)
Quote
-or write a formatter system into a bootloader for installation purposes.
What's the point about having a FAT filesystem if you don't have USB working to put files on it (either through Rockbox or through the OF)?

The OF will get erased by this, and even if you would put the FAT partition at some unused space inside the CFS partition; the OF still wouldn't 1) expose it over MTP because 2) it can't read it and doesn't know about its existence.
Quote
i think i will lean to try and get the the first one done, if a method of communicating is found.
every attempt i had last night i couldnt get a consistant response from components, at one stage i had scroll up recognised as the hold switch...

keep up the good work,
hopefully i can find something of use!
You can find the driver here (http://svn.rockbox.org/viewvc.cgi/trunk/firmware/drivers/isp1583.c?view=markup) and the datasheet here (http://www.rockbox.org/twiki/bin/view/Main/CreativeZVMPort#Internal_components) (ISP1583).
Title: Re: Creative Zen Vision:M
Post by: fejfighter on December 15, 2008, 05:25:55 AM
no, not yet.
only the boot loader can be changed right now. which then loads the creative firmware

@mcuelenaere
other ideas to get around the cfs problem i had thought of:
instead of finding a method to read it
-getting the usb driver to work then format the drive on a computer
I tried that approach for quite some time, but got stuck. I think the USB driver gets as far as sending some control messages on endpoint 0 and that's it (see this (http://www.beyondlogic.org/usbnutshell/usb1.htm) site for more info about USB)
Quote
-or write a formatter system into a bootloader for installation purposes.
What's the point about having FAT filesystem if you don't have USB working to put files on it (either through Rockbox or through the OF)?

The OF will get erased by this, and even if you would put the FAT partition at some unused space inside the CFS partition; the OF still wouldn't 1) expose it over MTP because 2) it can't read it and doesn't know about its existence.
i completely over looked that..
i never considered the file transfer that will be required :-[

Quote

You can find the driver here (http://svn.rockbox.org/viewvc.cgi/trunk/firmware/drivers/isp1583.c?view=markup) and the datasheet here (http://www.rockbox.org/twiki/bin/view/Main/CreativeZVMPort#Internal_components) (ISP1583).

i think i have been looking at the wrong files and datasheets, using the pic instead, i will try the other approach now
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on December 15, 2008, 06:14:21 AM
I think currently the main thing we should focus on is the CFS file system, as we almost have all pieces of the puzzle, but we just need to fit them correctly.

And whenever we have access to the VFSYS file, we can put a FAT partition on it and use it to boot Rockbox (+ we have the advantage of accessing it over USB through the OF using the Removable Disk Drive option).

Last time I checked, the code was working reliably (I even think I committed (non-working) code to SVN) but there's a problem with getting the different CFS sectors together and to 'merge' them to the FAT file system (at about p.42-43 at this thread you can read a bit more about it).
Title: Re: Creative Zen Vision:M
Post by: Aurix Lexico on December 18, 2008, 06:52:11 PM
Using send_command_to_pic, I've tried writing everything between 0x0000 and 0xFFFF to the PIC. I then tried just changing the third byte (aka between 0x00 << 16 and 0xFF << 16) and then tried just changing the fourth byte (aka between 0x00 << 24 and 0xFF << 24). It didn't appear to do anything. The keycodes never changed. Most of the time the function gave me back 0xFF0F0000, but every once in a while (once in every 30ish calls to send_command...), with absolutely no pattern that I can find, it will return a different code. Well, actually, if you move your finger over the touchpad very fast it will start returning 0xFFFFFFFF. All I can think about is, what is the point of the PIC? It has to have a point, it has to serve a purpose otherwise why even bother with it in the first place? Why change the keycodes at random?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on December 18, 2008, 06:57:13 PM
Using send_command_to_pic, I've tried writing everything between 0x0000 and 0xFFFF to the PIC. I then tried just changing the third byte (aka between 0x00 << 16 and 0xFF << 16) and then tried just changing the fourth byte (aka between 0x00 << 24 and 0xFF << 24). It didn't appear to do anything. The keycodes never changed. Most of the time the function gave me back 0xFF0F0000, but every once in a while (once in every 30ish calls to send_command...), with absolutely no pattern that I can find, it will return a different code. Well, actually, if you move your finger over the touchpad very fast it will start returning 0xFFFFFFFF. All I can think about is, what is the point of the PIC? It has to have a point, it has to serve a purpose otherwise why even bother with it in the first place? Why change the keycodes at random?
I know it is used to disable the touchpad.
It is also used to give information about various input (i.e. keys, TV-out, headphones, USB inserted, charger inserted, ...)
But because the protocol is completely proprietary (and custom-designed, like we're used of Creative..), I think the only way to figure out how it works is reverse engineering the OF...

Why change the keycodes at random?
I don't know, perhaps we just don't understand the protocol completely? Perhaps there's something wrong with the I²C implementation? (although I doubt that)
Title: Re: Creative Zen Vision:M
Post by: Aurix Lexico on December 18, 2008, 07:13:30 PM
Well, is there a way for me to extract and disassemble the OF? I'm not great with assembly, but I still want to try  :-\
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on December 19, 2008, 06:39:28 AM
Well, is there a way for me to extract and disassemble the OF? I'm not great with assembly, but I still want to try  :-\
Yes, have you already downloaded ZenUtils?

If so, with it you're able to extract the OF from the Creative firmware updater software and decrypt it.

The next step is disassembling, and if you have access to IDA there are some tools on the wiki which help IDA understand the firmware format.

I think I already helped somebody else explaining how the OF's firmware structure basically works, I'll look for that info and I'll post it here if I find it.
Title: Re: Creative Zen Vision:M
Post by: Aurix Lexico on December 23, 2008, 12:38:53 AM
I've been looking at the disassembled code for the PIC the last couple of days. The function that handles the i2c communication is conveniently labeled "i2c_handler" and I've been tracing through the 550ish lines of assembler that make it up. Unfortunately, "i2c_handler" is the only actual name in the entire 55k line file, all the other function and variable names are just numbers based on where it is in the file. Even so, the actual code is fairly easy to understand since PIC 18 has very few instructions. I still haven't found anything useful yet, though
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on December 23, 2008, 06:53:50 AM
I've been looking at the disassembled code for the PIC the last couple of days. The function that handles the i2c communication is conveniently labeled "i2c_handler" and I've been tracing through the 550ish lines of assembler that make it up. Unfortunately, "i2c_handler" is the only actual name in the entire 55k line file, all the other function and variable names are just numbers based on where it is in the file. Even so, the actual code is fairly easy to understand since PIC 18 has very few instructions. I still haven't found anything useful yet, though
I remember myself RE that same piece of code (lost all the files though...), and I think at the time I got some documentation about how the PIC handles I²C (probably source code or so)..

You have seen the datasheet (http://ww1.microchip.com/downloads/en/DeviceDoc/39599g.pdf) I suppose?

You could also try looking at the Microchip.com site if they provide code/a framework for handling I²C, if they did Creative probably used it and you can abstract away at least one layer then.
Title: Re: Creative Zen Vision:M
Post by: moritzk on December 24, 2008, 04:00:35 PM
Hey,

I am reading this thread for a long long time now and have to say that you did a great job already!!
I read the source code for the cfs and it seems reasonable to understand but now I need a test file to look further into the structure of the vfat system. I downloaded the one on the wiki but that does not seem to contain the vfat directory?
quetzalcoatl said something about a 122,5 mb file but I can't find that file anywhere. Is it available?

Greets
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on December 24, 2008, 04:21:33 PM
Hey,

I am reading this thread for a long long time now and have to say that you did a great job already!!
Thanks!
Quote
I read the source code for the cfs
Have you read only the code in the Rockbox sources or also the standalone programs I made (which are usable on a PC)?
Quote
and it seems reasonable to understand but now I need a test file to look further into the structure of the vfat system. I downloaded the one on the wiki but that does not seem to contain the vfat directory?
quetzalcoatl said something about a 122,5 mb file but I can't find that file anywhere. Is it available?

Greets

I can provide 2 GZIP'ed 30GB filesystems (raw copies of my ZVM HDD, it compresses to about 40MB). Of course you'll need quite some space to unpack them, unless you use sparse files (a feature that exists on some Linux file systems and also in NTFS, but I've only tested it on Linux).

Links:
  * http://www.mediafire.com/?uua5q3r5nec (http://www.mediafire.com/?uua5q3r5nec)
  * http://www.mediafire.com/?3hgjqirupl9 (http://www.mediafire.com/?3hgjqirupl9)

Notes for file 1:
 - I filled the 'virtual' disk with 0x11
 - when the Creative OS formatted the 'virtual' disk, it added a standard FAT header in it; so the OS knows how to 'format' drives as FAT
 - the file unpacks as a 30GB disk dump
 - as mediafire detected a virus (?), I encrypted the file; to decrypt it you'll need openssl:
Code: [Select]
openssl enc -in disk_dump.enc -out disk_dump.dec.gz -k quetzalcoatl -d -blowfish
Notes for file 2:
 - I filled the 'virtual' disk filled with 0x0 and  then I formatted it as FAT
 - same notes as other file (30GB HDD & encrypted with same key)

Hint:
this link (http://www.thelinuxsociety.org.uk/content/gnunzip-to-a-sparse-file) illustrates how to unzip the files to a sparse file on Linux (meaning the file will appear to be 30GB big, but will only take in about 40MB of space)
Title: Re: Creative Zen Vision:M
Post by: moritzk on December 24, 2008, 05:28:10 PM
Wow thank you for your fast reply, I am currently downloading the files. I just read the code in the rockbox svn, not the one of the standalone tools (link?).
I use windows, but I know how to cross compile files. And I got a new 500gig HDD which will host the file image.

A question to the images. How did you fill them? Did you just copy one file on them, or write manually with dd?
Title: Re: Creative Zen Vision:M
Post by: mcuelenaere on December 24, 2008, 07:32:10 PM
Wow thank you for your fast reply, I am currently downloading the files. I just read the code in the rockbox svn, not the one of the standalone tools (link?).
I believe this is all I have: http://www.mediafire.com/download.php?fgydmajigje (http://www.mediafire.com/download.php?fgydmajigje)

They should be compilable in Windows (MingW) and Linux (GCC).
Quote
I use windows, but I know how to cross compile files. And I got a new 500gig HDD which will host the file image.

A question to the images. How did you fill them? Did you just copy one file on them, or write manually with dd?
I formatted the ZVM's HDD using dd if=/dev/zero at all times before I installed the OF.

In the first image, I created a virtual disk in the OF using the Removable Disk Drive option of (I think) 1GB.
I mounted it and filled every byte with 0x11.

Same procedure for the second image, except I filled it with 0 (== dd if=/dev/zero) and after that I formatted it as FAT and placed some test files on it.