Structure of TLV Type 0x02bd (Binary Region 0E - fw_all.bin) #25
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I used gcdstruct.py to extract the various sections of a GUPDATE.GCD file for my watch (Forerunner 245 Music). The binary for TLV Type 0x02bd is between 7MB and 8MB. Looking at the file a bit, it seems that the first 0x1fd000 bytes (including padding) are a binary that would sit in flash, which makes sense as the internal flash is 2MB. However, that leaves a question of what the structure of the rest of the file is. Running binsum.py finds a valid sha1sum near the end of the file, but that is only one small portion of what remains.
Do you know anything else about the structure of the rest of TLV Type 0x02bd? Or would I be better off following up with the Alex W. mentioned in binsum.py (I assume this is them?)
I don't know how you get to the assumption that it only has 2 MB internal flash. The "Music" model has ~3.5GB internal storage according to this DC Rainmaker review.
The SHA1 is calculated over the whole file until shortly before the actual sum is written. So this means the
fw_allis written completely into some storage area.However, this being
fw_allmeans it may e.g. also include the SensorHub firmware which can also be updated separately. So what you're seeing might be that. Or that padding is a storage area that's not to be overwritten, e.g. the "NV" area where e.g. the device's serial number is kept or the user preferences. I don't know. You could probably find out by walking through the firmware in Ghidra. But I don't have time for this.Also we can't ask Alex as he sadly passed away in mid-2019.
I obtained a broken fr245m and cracked it open to look at chip numbers and find datasheets. I plan on documenting more details about what I found on an iFixit teardown page (similar to this one for the fr735xt), but the tl;dr is that the internals are very similar internals for the Fenix series and the main CPU is a Freescale MK28FN2M0ACAU15. The 2MB of internal (to the microcontroller) flash comes from the datasheet and noticing that the vector table present at the start of the
fw_allsection has pointers to the flash region of the memory map which also correspond to functions in thefw_allsection assuming a load address of 0x0 (the start of flash).In regards to the 3.5GB of internal (to the watch) storage, that is provided by a Samsung KLM4G1FETE-B041. And for the SensorHub firmware, the binary sections in GUP3079.GCD files already seem to cover that, so I don't expect it to be present here.
My suspicion is that the rest of the data in the
fw_allbinary is somehow parsed and written to the eMMC filesystem, but I will attempt to confirm that by reversing the binary that makes up the first 0x1fd000 bytes.Also, I'm sorry to hear the news about Alex. Even in my short time working on this I have benefited from his contributions to the community.
The similar innards are easily explained: Garmin doesn't want to please their users anymore by developing single models to perfection over a few years. Instead, they now make minor hardware improvements every year and sell the same base hardware in different housings as various different models for vastly different prices. Year after year. And now that they encrypt their firmwares (and it seems every model gets its own decryption key), there's currently no way to change these between models.
It might be that the 2MB are for the main watch kernel while other things like graphics for the watch hands, menu icons, etc. are written to the Samsung.
Thanks for your quick responses. For now I'll mark this issue as closed, spend some more time with Ghidra and xxd, and hopefully come back with some more answers :)