Rockbox.org home
Downloads
Release release
Dev builds dev builds
Extras extras
themes themes
Documentation
Manual manual
Wiki wiki
Device Status device status
Support
Forums forums
Mailing lists mailing lists
IRC IRC
Development
Bugs bugs
Patches patches
Dev Guide dev guide
Search



Donate

Rockbox Technical Forums


Login with username, password and session length
Home Help Search Staff List Login Register
News:

Welcome to the Rockbox Technical Forums!

+  Rockbox Technical Forums
|-+  Rockbox Development
| |-+  New Ports
| | |-+  Creative Zen Vision:M
« previous next »
  • Print
Pages: 1 ... 9 10 [11] 12 13 ... 46

Author Topic: Creative Zen Vision:M  (Read 617011 times)

Offline Sonic

  • Member
  • *
  • Posts: 10
Re: Creative Zen Vision:M
« Reply #150 on: April 16, 2007, 08:36:28 PM »
Hey, people! I just bought a ZVM, but the one drawback was that it didn't support Rockbox. So I'd be willing to help, if someone could tell me how. I don't know how to program, but I could learn if somebody pointed me to a good tutorial, or something.  :D
Logged

Offline CloudAge

  • Member
  • *
  • Posts: 1
Re: Creative Zen Vision:M
« Reply #151 on: April 16, 2007, 08:49:07 PM »
I would like to help in anyway possible aswell is there any status to some extent on this project as of yet?
Logged

Offline iSE

  • Member
  • *
  • Posts: 37
Re: Creative Zen Vision:M
« Reply #152 on: April 17, 2007, 01:10:57 AM »
Unfortunately reverse engineering the firmware to a player is extremely difficult. It is not a simple case of follow this howto and here you go. We are all still trying to figure out how to get our own version of the firmware onto the player without it being rejected.

The reason it is rejected is because the hash check the player performs on the firmware fails, as in, it knows its not the original and so will not load it because it may be corrupt and/or tampered with. If anyone has any experience cracking cryptographic hashes, I suggest you read through the posts that have come before this and help in anyway you can. If you want to learn, it is through this where you will be able to help.
Logged

Offline Sonic

  • Member
  • *
  • Posts: 10
Re: Creative Zen Vision:M
« Reply #153 on: April 19, 2007, 01:09:52 AM »
So, if it's so hard to decode the hash, why not use the original hash, from the original firmware? Maybe the other parts of the firmware could be identified, and then we could just figure out which part was the hash. Unless that just sounds really stupid.  :o
Logged

Offline iSE

  • Member
  • *
  • Posts: 37
Re: Creative Zen Vision:M
« Reply #154 on: April 19, 2007, 01:23:07 PM »
Well the idea behind a hash is that it calculates it from the contents of the firmware, so if the contents change then when it tries to calculate the hash it will be wrong and so will fail. If we are able to calculate what the hash algorithm is then we could use it to give a fake one back to the player so it thinks it original firmware. Another way would be find what the hash actually is so we could give that back to the player and again fool it.
Logged

Offline jhulst

  • Member
  • *
  • Posts: 21
    • My Homepage
Re: Creative Zen Vision:M
« Reply #155 on: April 19, 2007, 10:25:12 PM »
Quote from: iSE on April 19, 2007, 01:23:07 PM
If we are able to calculate what the hash algorithm is then we could use it to give a fake one back to the player so it thinks it original firmware. Another way would be find what the hash actually is so we could give that back to the player and again fool it.
We don't know how the hashing function and hash verification actually works as of yet, so this statement may not end up being completely true.  Depending on where/when the hash is calculated, the only way to "fool" the player may be to put the computed hash in the correct place of the firmware.

iSE, sorry to contradict you, but I think it's good to make sure the facts are being presented as best we know them so that people don't get confused.
Logged

Offline jhulst

  • Member
  • *
  • Posts: 21
    • My Homepage
Re: Creative Zen Vision:M
« Reply #156 on: April 19, 2007, 10:48:26 PM »
Take the following with a grain of salt as I have not had a lot of time to work through my findings:

It looks like the checksum/hash is being computed in the firmware update software.  It seems that the firmware updater program is divided into two parts, the main part, and a library called by the main part.

In the library, at line 7C93CF82, there are some references to Image Checksum.  From my understanding, one of the functions calls "LdrVerifyImageMatchesChecksum" which is at 7C93CFE4.  This may be where the checksum is calculated. 

To look at the code, I used OllyDbg and examined 1.61.01 version of the firmware.  I've mirrored the firmware updater  (15 MB).  My way of getting to the library was to run the updater without a player plugged in.  It will terminate in the library.

Again, these are some very initial thoughts.  I am probably wrong about some, if not all of it, I just wanted to give a starting point that others who may want to help may begin to look at.

My next step will be to hookup a player and step through the code to try and understand what it is doing.

jwh

edit: fixed links
« Last Edit: April 19, 2007, 10:58:17 PM by jhulst »
Logged

Offline larryzotter

  • Member
  • *
  • Posts: 7
Re: Creative Zen Vision:M
« Reply #157 on: April 20, 2007, 09:25:09 AM »
Do u mean the verifying is done i the updater program instead of the ZVM itself?
Logged

Offline TheBlackCat

  • Member
  • *
  • Posts: 9
Re: Creative Zen Vision:M
« Reply #158 on: April 21, 2007, 01:05:51 PM »
It may be done at both.  I am pretty sure the nk.bin file contains a checksum mismatch error message ("header checksum" I think it was called), which would indicate that there might be a checksum detection on the ZVM itself as well as the installer.  This would not matter if they used the same hash algorithm, but could be very annoying if they don't.

I don't know much about checksum, but it would seem to me that the hash algorithm could not include the checksum itself, right?  If that was the case they would have a "chicken and egg" problem where putting in the computed checksum would change the checksum, forcing you to recompute it.  The recomputed checksum would again change the checksum, etc.  If it is the case that the checksum avoids one part of the file, is it possible it might avoid others as well that are not considered important?

Another question: if we know where the checksum is being calculated would it be possible to delete that from the code entirely and replace it with some sort of "if 1=1" test or something trivial like that?  Or perhaps leave the algorithm in but bypass the test for whether there is actually a match or not.  I know nothing about assembly or machine code editing so I don't know if that is possible.  However, I would guess if people are ever able to understand the assembly or machine code well enough to determine the hash algorithm then it would be as easy if not easier to understand it well enough to bypass the test entirely in some way.  It probably wouldn't be a particularly elegant solution but it might save a lot of trouble.
« Last Edit: April 21, 2007, 01:14:25 PM by TheBlackCat »
Logged

Offline saratoga

  • Developer
  • Member
  • *
  • Posts: 8963
Re: Creative Zen Vision:M
« Reply #159 on: April 21, 2007, 01:29:16 PM »
Quote from: TheBlackCat on April 21, 2007, 01:05:51 PM

Another question: if we know where the checksum is being calculated would it be possible to delete that from the code entirely and replace it with some sort of "if 1=1" test or something trivial like that?  Or perhaps leave the algorithm in but bypass the test for whether there is actually a match or not.  I know nothing about assembly or machine code editing so I don't know if that is possible.  However, I would guess if people are ever able to understand the assembly or machine code well enough to determine the hash algorithm then it would be as easy if not easier to understand it well enough to bypass the test entirely in some way.  It probably wouldn't be a particularly elegant solution but it might save a lot of trouble.

Yeah, thats the easiest way around these things.  Find the "branch if not equal" instruction and change it to a NoOp.  That way it doesn't notice if the checksum/hash is wrong.  Ideally someone would work out the checksum, so that the software didn't need to be hacked (which would be awkward for rockbox since no one can distribute the hacked program).  But either now would be really interesting and a great start since it would let us know pretty quickly if there was a second check on the player itself.
Logged

Offline larryzotter

  • Member
  • *
  • Posts: 7
Re: Creative Zen Vision:M
« Reply #160 on: April 21, 2007, 07:47:22 PM »
What would be a good software to "see" whats in the nk.bin fle? I've tried a hex editor with not much luck.
Logged

Offline jhulst

  • Member
  • *
  • Posts: 21
    • My Homepage
Re: Creative Zen Vision:M
« Reply #161 on: April 22, 2007, 12:31:58 AM »
Quote from: larryzotter on April 21, 2007, 07:47:22 PM
What would be a good software to "see" whats in the nk.bin fle? I've tried a hex editor with not much luck.

Check out reply #157 for how mcuelenaere does it.
Logged

Offline koston

  • Member
  • *
  • Posts: 3
Re: Creative Zen Vision:M
« Reply #162 on: April 25, 2007, 03:55:12 PM »
So watch this:

http://www.bilder-speicher.de/07042521261533.vollbild.html

Seems to be a lot of Cryptoshit inside ;)

Quote
In the library, at line 7C93CF82, there are some references to Image Checksum.  From my understanding, one of the functions calls "LdrVerifyImageMatchesChecksum" which is at 7C93CFE4.  This may be where the checksum is calculated.

This is inside the ntdll.dll. There cant be a checksum calculation, because this is a Windows library. The checksum calculation must be inside the code of ZENVisionM_30GB_PCFW_L21_1_61_01.exe. The Windows DLLs you mostly use for creating Messageboxes (user32.MessageBoxW for example) or something like that.
« Last Edit: April 25, 2007, 04:04:33 PM by koston »
Logged

Offline mcuelenaere

  • Developer
  • Member
  • *
  • Posts: 392
Re: Creative Zen Vision:M
« Reply #163 on: April 26, 2007, 04:32:42 PM »
Quote from: koston on April 25, 2007, 03:55:12 PM
So watch this:

http://www.bilder-speicher.de/07042521261533.vollbild.html

Seems to be a lot of Cryptoshit inside ;)
I got this:
Code: [Select]
ADLER32 :: 0001609C :: 0041609C
The reference is above.
Adler32 checksum (unsigned 32-bit integer, BASE value); used by ZLIB compression library
ADLER32 :: 00016171 :: 00416171
The reference is above.
Adler32 checksum (unsigned 32-bit integer, BASE value); used by ZLIB compression library
CRC32 :: 0004F700 :: 0044F700
Referenced at 004162CF
Referenced at 0041631E
Referenced at 00416364
Referenced at 004163A6
Referenced at 004163E6
Referenced at 00416425
Referenced at 0041646A
Referenced at 004164AF
Referenced at 004164EF
Referenced at 00416544
Referenced at 00416570
CRC32 precomputed table for byte transform
DES [long] :: 00051D90 :: 00451D90
The reference is above.
DES: transformation nibbles
ECC: DRM (Microsoft), prime modulus :: 00051AB4 :: 00451AB4
Referenced at 0041972B
Microsoft elliptic curve, prime modulus of DRM curve
MD4 :: 00027663 :: 00427663
The reference is above.
MD4 transform & init constants (also used in SHA, RIPEMD, partly in CAST)
MD5 :: 0002586D :: 0042586D
The reference is above.
MD5 transform (\"compress\") constants
SHA1 [Compress] :: 0002326A :: 0042326A
The reference is above.
SHA1 additive constants (also used in SHA, SEAL, partly in RIPEMD)
SHA1 [Compress] :: 00023DBF :: 00423DBF
The reference is above.
SHA1 additive constants (also used in SHA, SEAL, partly in RIPEMD)
ZLIB deflate [word] :: 0004F600 :: 0044F600
Referenced at 00415D0C
ZLIB deflate compression algorithm - literal code lengths, used to build the trees
Logged

Offline mcuelenaere

  • Developer
  • Member
  • *
  • Posts: 392
Re: Creative Zen Vision:M
« Reply #164 on: April 30, 2007, 05:23:41 AM »
Some functions I've found in the .exe (named them myself):

FirmwareChk at 00413E10 (big function, has a lot of checks of nk.bin in it)
FORMAT_FIRMWARE at 00417A30 (I suppose here ZVM's firmware is erased)
FIRMWARE_DOWNLOAD at 00417CE0 (and here it is uploaded?)
CheckFormatSupport() at 00417FB0 (name was found in the strings)
ChkSumInit at 004229B0 (has something to do with the CheckSum; I strongly believe it is SHA1 or RIPEMD160) --> this one uses a lot of SHA1 constants, so I believe the SHA1 hash is generated here

(SetRegSeed at 00424275)
(CreateRegRNGKey at 004242B8)
-> these are from minor importance
« Last Edit: April 30, 2007, 05:35:10 AM by mcuelenaere »
Logged

  • Print
Pages: 1 ... 9 10 [11] 12 13 ... 46
« previous next »
+  Rockbox Technical Forums
|-+  Rockbox Development
| |-+  New Ports
| | |-+  Creative Zen Vision:M
 

  • SMF 2.0.17 | SMF © 2019, Simple Machines
  • Rockbox Privacy Policy
  • XHTML
  • RSS
  • WAP2

Page created in 0.173 seconds with 21 queries.