Creative Zen Vision:M

[Transience]

Perhaps I'm not understanding this correctly, but isn't the code that checksums the new firmware file already on the player? Changing the part of the firmware that dictates what happens when the checksums don't match in the firmware being transfered won't help any.
If there's a way to run .bin files (an ARM emulator perhaps?) that might allow the firmware to be debugged, but without knowing the checksum algorithm, the only option is to access the firmware data on the ZVM, and modify it that way.
Do I understand this right, or am I just saying stupid things?

[mcuelenaere]

Perhaps I'm not understanding this correctly, but isn't the code that checksums the new firmware file already on the player?

Yes

Changing the part of the firmware that dictates what happens when the checksums don't match in the firmware being transfered won't help any.

Well, actually it would help. But there are a few problems. : ) At first, we have to know which code this is. And then we have to upload the code back to the ZVM; which atm is only possible by directly editing the HDD.

If there's a way to run .bin files (an ARM emulator perhaps?) that might allow the firmware to be debugged, but without knowing the checksum algorithm, the only option is to access the firmware data on the ZVM, and modify it that way.

I don't really understand this sentence ; ) If we could get the firmware debugged (and disassembled), we would know (in ARM assembler) the checksum algorithm.
"... and modify it that way." => which way are you talking about? ; )

Do I understand this right, or am I just saying stupid things?

I think you understand it right : )

[iSE]

I've been able to get the ARM code for the nk.bin using EMU8086 emultator, but the firmware uploader is too big to load for some reason. If anyone knows of anythin that will disassemble a file n output the ARM code to a txt file to read through, that would be very benificial. Where would the algorithm be tho? Surely it will only be in the bootloader? Because creative will calculate it at their end n only on the player. There would be no need for the nk.bin nor the firmware updater program to calculate the checksum.

Since this is the case, would it be possible to modify some firmware to be uploaded directly to the HDD, which would output the algorithm? Long shot I know but might be worth a hefty effort if it works?

[mcuelenaere]

I've been able to get the ARM code for the nk.bin using EMU8086 emultator, but the firmware uploader is too big to load for some reason. If anyone knows of anythin that will disassemble a file n output the ARM code to a txt file to read through, that would be very benificial. Where would the algorithm be tho? Surely it will only be in the bootloader? Because creative will calculate it at their end n only on the player. There would be no need for the nk.bin nor the firmware updater program to calculate the checksum.

Since this is the case, would it be possible to modify some firmware to be uploaded directly to the HDD, which would output the algorithm? Long shot I know but might be worth a hefty effort if it works?

I think the algorithm is surely used during the update progress and maybe during start-up; but it could be located anywhere... See it as a DLL, it could be loaded anytime (and used anytime), but where it is atm we don't know (flash or HDD or ...).

Isn't the algorithm (based on SHA-1) located in the updater program itself (so X86 code!) worth taking a look at? I have done it myself, but I am not that good at understanding assembler : )

[iSE]

Well sure, if you can post the code for it I'll take a look. But why would the checksum of the firmware ever need to be calculated unless verifying it to be real and when first inserting the checksum into the file?

[mcuelenaere]

Well sure, if you can post the code for it I'll take a look. But why would the checksum of the firmware ever need to be calculated unless verifying it to be real and when first inserting the checksum into the file?

Indeed, it is very odd. But someone found some traces of a SHA-1 calculation and I investigated a (little bit) further and found some kind of SHA-1 (based) routine in the .exe (see some posts back, I've posted some code)

edit: it starts at page 12

[saratoga]

I've been able to get the ARM code for the nk.bin using EMU8086 emultator, but the firmware uploader is too big to load for some reason.

I posted the nkbin directly earlier in the thread.  You don't need to emulate anything, it saves it to the hard disk.

If anyone knows of anythin that will disassemble a file n output the ARM code to a txt file to read through, that would be very benificial.

Sure, use objdump (comes with the rockbox dev tools) or IDA Pro.  Check earlier in this thread, theres a lot of posts on it from around January or so.

Since this is the case, would it be possible to modify some firmware to be uploaded directly to the HDD, which would output the algorithm? Long shot I know but might be worth a hefty effort if it works?

You mean replacing their bootloader?  Without spec sheets, that would be very hard to do.

[iSE]

I used the emulator as its possible to view the ARM code of the nk.bin file itself. I will checkout objdump.

If, say, the firmware updater does indeed calculate the checksum of the nk.bin file and then upload it to the firmware, and the firmware is merely a series of commands designed to upload an inbuilt nk.bin file, can we not change the nk.bin file slightly, put it back into the firmware updater program, and then try that to upload it to the Zen?

[mcuelenaere]

If, say, the firmware updater does indeed calculate the checksum of the nk.bin file and then upload it to the firmware, and the firmware is merely a series of commands designed to upload an inbuilt nk.bin file, can we not change the nk.bin file slightly, put it back into the firmware updater program, and then try that to upload it to the Zen?

You could try, if you know how : )
The firmware is compressed (with a deflate algorithm, don't know out of my head which one; I think ZLIB) in the firmware updater program and can be extracted (there is a little C program bundled with libnjb that does this; I've never tested it with ZVM's firmware updater program though)

[iSE]

I'm still strugglin with the 010 editor template lol. Could you please post the exact template you know to work as lookin at the script I know theres an error, theres 1 { n 2 }'s and a ( without any ). Unfortunately I don't know enough about the scripting language to fix the syntax. I've tried trust me lol.

[saratoga]

If, say, the firmware updater does indeed calculate the checksum of the nk.bin file and then upload it to the firmware, and the firmware is merely a series of commands designed to upload an inbuilt nk.bin file, can we not change the nk.bin file slightly, put it back into the firmware updater program, and then try that to upload it to the Zen?

You could try, if you know how : )

Didn't you try this on the previous page?

[mcuelenaere]

Didn't you try this on the previous page?

You mean extracting nk.bin and putting it back into the .EXE?

[mcuelenaere]

Ok, so I and iSE had a little conversation about the ZVM's firmware; if you want to see the logs:
http://gim.6te.net/ZVM/Chat.htm

[Transience]

I don't know that this will work, but assuming the firmware updater .exe file uses the same checksum algorithm as the firmware itself, wouldn't it be possible to use the updater to generate the checksum we need, without having to know the algortihm?

[mcuelenaere]

I don't know that this will work, but assuming the firmware updater .exe file uses the same checksum algorithm as the firmware itself, wouldn't it be possible to use the updater to generate the checksum we need, without having to know the algortihm?

Yes, I was thinking the same way! But we are not sure that the .exe and the firmware itself contains the same algorithm; it would be kinda dumb of Creative to do so..

On the other hand, if it is true; it should be possible to generate a valid checksum, but don't ask me how