Creative Zen Vision:M

[mcuelenaere]

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  

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]

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.

[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

[zook]

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.

[zook]

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.

[mcuelenaere]

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?

[zook]

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.

[zook]

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.

[zook]

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.

[mcuelenaere]

Great work zook!  

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?

[zook]

Great work zook!  

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.

[mcuelenaere]

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

[zook]

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.