Rockbox Ports are now being developed for various digital audio players!
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.
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.
What would be a good software to "see" whats in the nk.bin fle? I've tried a hex editor with not much luck.
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.
So watch this:http://www.bilder-speicher.de/07042521261533.vollbild.htmlSeems to be a lot of Cryptoshit inside
ADLER32 :: 0001609C :: 0041609C The reference is above. Adler32 checksum (unsigned 32-bit integer, BASE value); used by ZLIB compression libraryADLER32 :: 00016171 :: 00416171 The reference is above. Adler32 checksum (unsigned 32-bit integer, BASE value); used by ZLIB compression libraryCRC32 :: 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 transformDES [long] :: 00051D90 :: 00451D90 The reference is above. DES: transformation nibblesECC: DRM (Microsoft), prime modulus :: 00051AB4 :: 00451AB4 Referenced at 0041972B Microsoft elliptic curve, prime modulus of DRM curveMD4 :: 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\") constantsSHA1 [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
Page created in 0.08 seconds with 22 queries.