Rockbox Development > New Ports

Creative Zen Vision:M

<< < (69/136) > >>

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

Transience:
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?

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

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

fejfighter:
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

Navigation

[0] Message Index

[#] Next page

[*] Previous page