Creative Zen Vision:M

[mcuelenaere]

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 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.

[wesmo]

Awesome work there mcuelenaere and zook

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

[mitch04]

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

[Bagder]

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...

[mcuelenaere]

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)

[zook]

Awesome work there mcuelenaere and zook

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.

[Bagder]

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...

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) ?

[zook]

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.

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.

[mcuelenaere]

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)

[mcuelenaere]

TI releases free c54x compiler!!
http://open.neurostechnology.com/node/1020

P.S.: wiki is updated

[iSE]

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!  

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?

[mcuelenaere]

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!  

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.

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.

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.

[linuxstb]

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

[iSE]

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?

[NicolasP]

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.