Rockbox Development > New Ports

Creative Zen Vision:M

<< < (71/136) > >>

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page