|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CreativeCurrent statusWatch the ZVM Port Thread for current progress "The short-term goal is to get a build tool chain up and running." - tools/rockboxdev.sh (and select arm) "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." "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." zook from the forum threadInformation:Original FirmwareFirmware Info
Modifying the firmwareModifying the firmware is as easy as deleting a block/block data, inserting the new data, adjusting the Size attribute of the block and the CIFF block and computing the NULL checksum of the CIFF block (so without the NULL block). You don't have to fill the entire firmware with all the blocks, if you for example just want to replace Hdeviceinfo.xml with another one, you only have to make a CIFF, CINF, DATA and NULL block (so you do not have to include all the others).Uploading a firmwareYou can either compile the program located in utils/MTP/ in SVN or you can get the hacked version of the official firmware updater.Firmware Boot
Firmware FormatDescriptionThe firmware is Little Endian. A firmware always starts with the string FFIC (=CIFF). Followed by the total size of the file minus the last (NULL) block and possible some padding bytes. After this header comes a block structure, always started with a 4-byte string header (e.g. FNIC, ATAD, LLUN, CNEC, 0TXE or LTŠ). Then comes (again) the size of this block. Then you have, based on the type of block: a) a data block with size of Size b) a 32-byte Unicode name(=filename) and the data block of (Size-32).Overview table
Normal files to be found in an official firmware
CINF blockThe CINF block is the identifier of the firmware i.e. it says if the firmware belongs to a Creative ZVM 30/60GB, Creative ZEN, etc.. The 30GB ZVM contains the Unicode string 'Creative Zen Vision:M'. The 60GB contains 'Creative Zen Vision:M Go!' (also Unicode).NULL blockThe NULL block in the current Creative ZVM's is a HMAC-SHA1 computed checksum of the CIFF block using the key 'CTL:N0MAD|PDE0.DPMP.'ŠTL blockThe ŠTL block gets written to the ZVM's HDD as jukebox2.jrm It is encrypted using Blowfish in CBC mode with key '1sN0TM3D az u~may th1nk*Creative Zen Vision:M' and after that you have to decompress/decode it using the CENC algorithm (described on DellDJPort).FRESCUE StructureThe FRESCUE file starts off with a header consisting of two 32-bits words, a tag and a size, followed by the data:
struct R_HEADER {
DWORD Tag;
DWORD Length;
BYTE Data[Length];
};
The Tag is always CODE. The Data starts off with one 32-bit word whose purpose is unknown at this point. Following is an array of section objects, which specifies where in memory to read the contained section data:
struct R_SECTION {
DWORD Address;
DWORD Length;
DWORD Unknown;
BYTE Data[Length];
};
The Address specifies the physical address which the data will be written to. This array continues till the end of the file.I've attached zenldr.rar, an IDA loader plugin which handles the FRESCUE format. The pre-compiled file zenldr.ldw is compiled for IDA 5.0. Once mapped into memory, address 0x200 will contain an array of 32 8-byte ISR entries. The ISR entry format is as follows:
struct TMS320C55x_ISR {
BYTE Flags;
DWORD ISR : 24;
BYTE Filler[4];
};
The Flags controls the operating behaviour when performing an interrupt. The ISR is a 24-bit address of the ISR handler.The first ISR entry is the RESET vector, which points to a function named _c_int00, in the TI RTOS/BIOS source code. Other Creative players' firmware informationSince these information about the firmware applies to (almost?) the whole Creative Zen line, you'll find here some info for other players (like NULL block key, CINF header, ŠTL block key, ...) Remark: Because the TWiki markup sees '|' as a table marker, all '|' are replaced by '$'
Miscellaneous Links
r1 - 20 Dec 2007 - 02:09:48 - WessamBaghdadi
Copyright Š by the contributing authors.
|