Rockbox Development > New Ports
Creative Zen Vision:M
mcuelenaere:
--- Quote from: fejfighter on October 10, 2007, 01: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
--- End quote ---
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.
zook:
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.
Transience:
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?
zook:
--- Quote from: Transience on October 20, 2007, 08: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?
--- End quote ---
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.
--- Quote from: zook on October 11, 2007, 10:25:33 AM ---
The show stopper is that the executable code within the ZVM firmware is encrypted/encoded.
--- End quote ---
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.
mcuelenaere:
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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version