figure out firmware flashing protocol
Right now the only way to flash the radio's firmware is via the HT app.
- This is concerning for the long-term health / use of the radios, because as soon as the HT app goes out of date we lose our ability to update the firmware.
- If we can flash our own firmwares, we get the freedom to downgrade firmware versions, as well as install whatever firmware flavor we want (e.g. potentially install BTech firmware on a N76, etc... it remains to be seen how compatible they are)
- It gets the community one step closer to building / modding their own firmware
I have a number of btsnoop logs of firmware downloads I've created, but haven't yet had a chance to sit down and figure out what's going on. It doesn't look trivial -- there's some checksumming / verifying going on in the process that we'll need to figure out. (I've been focusing on audio support recently)
@khusmann Oh wow. Yes, this is super important. Once there is no more firmware updates, there is no way to get these logs anymore. Thank you so much for capturing these!
Made quite a bit of progress on this over the weekend. Here's the updates:
I have figured out the endpoints for firmware updates, which has allowed me to download a little over 30 firmware images. They're only for UV-Pro and N76 though... for other models I'd either need to buy one or figure out how to intercept their RPC protocol. DM me if you want the endpoint url, I don't want to publish at the risk of them changing it. Otherwise, there are a few firmwares posted in the FB group that folks have pulled directly pulled from their rooted phones.
Side note... in the decompiled HT app it looks like there's an "advanced" gui for firmware flashing that gives you some extra commands like UPDATE_COMMIT and UPDATE_ERASE_SQIF. @na7q have you found anything like this in your experiments?
Firmware updates come in two parts: a base image upgrade_base.bin, and a patch image. For N76, the patch image is named patch_base_to_vr_n76.bin, for UV-Pro it is patch_base_to_vr_n76_m.bin. The patch files are in BSDIFF40 format.
I've figured out the basic flashing commands and flow (including how they are aborted), and have gotten as far as creating the protocol messages in a branch of benlink.
Next step is to put it all together into a command-line flasher...
Ohh wow. This is an area I never looked into. If there is value in me adding firmware upload to HT Commander, let me know. I am SUPER thankful that you are working on this and that you likely have an archive of past firmware, this is SO very good. Do you have an idea what chip/instruction set is being used? Is it a RISC-V?
@Ylianst here's what I get when I binwalk the file:
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
58 0x3A CSR (XAP2) DFU firmware update header
116707 0x1C7E3 MySQL ISAM index file Version 6
So looks like it's CSR Bluetooth chipset firmware image, so not RISC-V. I guess it's a common arch in BT speakers. ChatGPT suggests CSR8670 or CSR8811. When is someone gonna do a hardware teardown lol???
Here's a great forum thread on CSR firmware stuff: https://www.diyaudio.com/community/threads/csr8675-programming-guide-w-software-and-tons-of-csr-info.349336/