Creative Zen Vision:M

[Transience]

Couldn't you use a memory editor or debugger to search for the checksum while the updater is running? If it turned up, it would seem to indicate that both firmware and updater use the same checksum algorithm.

[iSE]

Well the firmware wont have the algorithm in it, it only has the checksum stored on the end of it. The last 20 bytes. If anyone is good at making mathematical scripts there is a task which may help.

We are assuming that the checksum is either, SHA-1 (or one of the 3 variants), or maybe even SHA-0. I cannot find the psuedocode for SHA-0 but if anyone can make a program which calculates the SHA-1 checksum from the psuedocode available at wikipedia: http://en.wikipedia.org/wiki/SHA_hash_functions#SHA-1_algorithm, including the 3 different variations of it, just to confirm if it is or is not one of these. You wouldnt need to worry about doing anything with the checksum, literally just to create a program which calculates 4 different checksums from a file. (nk.bin without the NULL block)

[Bagder]

sha1sum has been around for ages and while it presents "just" one sha-1 sum,   I figure it could be a nice start to get the other alternatives tested out too...

[iSE]

exactly, all the calculators out there only calculate the main one, so that mite be why its not coming up as a match. Creative may not be able to fund their own algorithm so will use a less known one. Its a good start and something to eliminate. If anyone can find any information on the SHA-0 algorithm aswell, that would be useful.

[Transience]

Well the firmware wont have the algorithm in it, it only has the checksum stored on the end of it. The last 20 bytes. If anyone is good at making mathematical scripts there is a task which may help.

If that's true then the player can't checksum the firmware being passed to it, and should accept any firmware that is uploaded to it.
The checksum algorithm may also be skipping parts of the firmware file when calculating the checksum, making the job of finding the right algorithm even harder.

[saratoga]

If that's true then the player can't checksum the firmware being passed to it, and should accept any firmware that is uploaded to it.

Why would that be?

[Transience]

if the firmware doesn't contain checksum code, then it can't determine if the firmware being passed to it is legitamate or not, and it should accept anything.

I just tried searching for the checksum with a memory editor and debugger while the program was running, and found no trace of it. It seems that whatever checksum validation is done, is done by the player, and not the updater.

[saratoga]

Sorry, misread what you wrote.  

[Transience]

That's alright.
An update on what i said earlier about the firmware updater:
The updater MAY still be performing a checkusm on the firmware. I noticed that the program won't begin an update while I have any sort of memory editor/viewer or debugger running on it. It may not begin the checksum untill its debugger/memory editor check passes. If someone has a harder to detect debugger perhaps they can try searching for the checksum with that, but I've tried three now, and I can't find one that the updater doesn't detect.

[mamboman]

if someone has Winhex from http://www.winhex.com i think it's quite powerful

[mcuelenaere]

I found some strings in FBOOT:

• Creative Technology
• flash
• 1MBJ (JBM1 ??)
• devm
• lcd
• iic
• EDOC (CODE)

[mcuelenaere]

OK, the checksum is definitely not SHA-0/SHS-0 nor SHA-1/SHS-1..

I downloaded this tarball and compiled it and tested it on a ZVM's firmware v.1.62.02 without the NULL block.

Results:

Code: [Select]

Maurus@Beneden ~/hash
$ ./sha1.exe test.bin
4a73bdc1ce9ed6275475bc9c52cf845aeb1ec29c test.bin

Maurus@Beneden ~/hash
$ ./sha.exe test.bin
81c9ec45a2944442b7d05bf5095280d602aea797 test.bin
The data in the NULL block is:

Code: [Select]

77 A0 03 39 3E 4A 09 B9 E1 BD 2F 14 09 7A 8A 8C 17 8F 38 AA
So it doesn't correspond...

Could it have to do something with the endianness?

[TheBlackCat]

As I understand it there are 3 possibilities (please correct me if I am wrong).  

1. The hash algorithm is on the old firmware on the hard drive and it checks the new firmware when it is downloaded or the has algorithm is in the flash memory but the flash memory is replaced with each firmware upgrade.

2. The hash algorithm is on the new firmware and it checks itself when it is downloaded to the hard drive (this seems sort of a silly way to do it).

3. The has algorithm is on the flash memory and it rarely or never changes.

Scenario 1 and 2 have the algorithm on the downloaded firmware, either because it checks itself or because the new firmware will need to have the algorithm when it replaces the old firmware.  This will require getting the algorithm out of the code so checksums can be generated for custom firmware or they require somehow editing files on the device directly (which is difficult if not impossible with MTP).  The security issue with this scenario is that it is maybe possible to erase the firmware entirely from the player using "reload firmware" in the recovery console.

Scenario 3 does not necessarily have the hash algorithm in the firmware.  So has anyone tried accessing the flash memory on a ZVM to check it?

Speaking of which, has anyone tried using the recovery console to force the player to download hacked firmware?

[phcoder]

As I understood the updater contains SHA-1 constants. Has somebody tried to modify it and look at the behaviour. I foresee 3 possibilities:
1) nothing change. Than this part of code is likely unused
2) updater complains about checksum even before downloading the firmware into the player
3) the null block gets modified and player complains

[iSE]

Why do you all assume that the algorithm is in the firmware? I won't be, the checksum, as in the hash key will be stored in the firmware file and we think its the last 20 bytes of the nk.bin file.

It is certainly possible that the firmware updater program has the algorithm, in which case it may be that the checksum is calculated, appended to nk.bin and then transferred. The bootloader then also performs a check on the firmware, checks it with the key and if its ok, lets it pass.

There is no need for the algorithm itself to be stored inside nk.bin and if it is then Creative are extrememly stupid!

Well the firmware wont have the algorithm in it, it only has the checksum stored on the end of it. The last 20 bytes. If anyone is good at making mathematical scripts there is a task which may help.

If that's true then the player can't checksum the firmware being passed to it, and should accept any firmware that is uploaded to it.
The checksum algorithm may also be skipping parts of the firmware file when calculating the checksum, making the job of finding the right algorithm even harder.

Im not saying the firmware doesnt have the checksum key in it, the 40digit checksum code, im saying the actual algorithm used to generate the checksum will NOT be in the firmware. If someone proves me wrong then I'll stand corrected and I would love it if I am wrong, but there is NO reason for creative to put the actual calculating algorithm inside nk.bin. And sorry but its so hard to make a secure algorithm I also doubt they would ever change it.