-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Header structure contains unknown values #2
Comments
Good work! :) When you have time, you should join us in #pebble at freenode irc server (if you don't use irc, they have a webclient at www.freenode.net) |
I've been more or less living off of my phone this week so I've only been On Feb 17, 2013, at 4:29 AM, RaYmAn notifications@github.com wrote: Good work! :) When you have time, you should join us in #pebble at freenode irc server — |
Filled in some more of the header: On 17 February 2013 12:33, aleksandyr notifications@github.com wrote:
|
I hope I'm just doing something silly but the CRC field of the application header doesn't appear to correspond to the CRC of the binary or any meaningful subset thereof. How should it be derived? (I'm working on an unpack/repack for apps.) |
Brute forced it. Hopefully more than just a coincidence...confirming results before I report. |
Ok...the CRC is taken with respect from the end of the header (so byte 108) to 8 bytes less than the end of the binary. The last two values of the binary vary but appear to be offsets inside the file and are always 4 apart. Also, there's a secondary header or signature at the end of the app file - it refers to the internal CRC of the PBPack (not the one in the manifest, the one in the PBPack) and the CRC of the app's icon! This struct begins at 0xC18 in pebble-app.bin in the Brains watch. This might be why my attempts to replace the images failed! |
Err, the ending header and the whole 8-bytes-less-than-end thing is a bit more fluid than I thought. First number is the number of bytes in to the binary (so after the 108-byte header) and the second number is the number of bytes at the end of the file. Big Time 12 The second number is, of course, 4x the number of relocs (last value in the header) - the reloc list is therefore not part of the CRC. |
I'm working on adding Chinese character to the font library.Basically it's the same way I did to the video game X3:Reunion in 2006. Stuck in CRC, Any one could tell me how to calculate CRC in the firmware's system_resources.pbpack ? I never make it right |
Since we still have some unknowns I went ahead and pulled all of the current header values in to a spreadsheet to get started:
https://docs.google.com/spreadsheet/ccc?key=0Atak9WHHS8K-dExsUzBobFdQU0xTYklzYlYxempFYnc
Please copy and edit - figure this is easier than working in the wiki.
So far I'm noticing that the 2nd offset in the header is always the same as the size (but that space is 32-bit, not 16-bit.) Unknown7 also appears to have some relationship to the watch - all of the "simple" faces that are just hour+minute have a value of 2. Getting access to the faces built in to the firmware (if they follow the same header) should help confirm/continue this work...but I don't have anything worth mentioning as a disassembler.
The text was updated successfully, but these errors were encountered: