Creative Zen Vision:M

Rockbox Development > New Ports

<< < (72/136) > >>

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! :D

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:

--- Quote from: mcuelenaere on November 11, 2007, 01:44:58 PM ---Great work zook! Â :D

--- End quote ---
Thanks :)

--- Quote from: mcuelenaere on November 11, 2007, 01:44:58 PM ---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.

--- End quote ---
Cool, that'll give us something to compare against once we start digging into the OS structure.

--- Quote from: mcuelenaere on November 11, 2007, 01:44:58 PM ---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?

--- End quote ---
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version