figure out firmware flashing protocol

[khusmann]

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)

[Ylianst]

@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!

[khusmann]

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...

[Ylianst]

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?

[khusmann]

@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???

[khusmann]

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/

[cqjjjzr]

The VR-N76 uses CSR8670 as suggested by a disassemble video here: https://www.bilibili.com/video/av114738759471028/ . I failed to find detailed information about this chipset. You can extract the firmware DFU file using https://gist.github.com/dogtopus/b2aa1e90bdc66aeeb36c0b88f7ce8a88 and https://github.com/ramikg/csr-dfu-parser , but I'm unable to make further progress. The instruction set is Qualcomm CSR's (very weird. e.g. bytes are 16-bit) process architecture. Some Chinese forums contain leaked documentations about CSR86xx, but they have paywalls so I will try to look further later.

The gRPC interface, as also mentioned in #13 , includes an EchoLink/DMR/WIREX-like Internet-based walkie-talkie feature and firmware upgrade / device registeration. The firmware update method is available without any user identification, so one can scrape firmwares directly using a gRPC client.

As for the clipboard issue, I only found the clipboard used for import/export of channel and settings in my decompiled/deobfuscated version of HT app, so I wouldn't consider it malicious.

[cqjjjzr]

According to https://studylib.net/doc/18798350/audio-sink-application-dfu-user-guide and firmwares I scraped, the firmware DFU file is signed and have to be verified when updating. Therefore, I doubt if it is possible to use custom-built firmwares with DFU and OTAU. Maybe flashing directly through SPI can workaround this?

Edit: I just gave up on custom FWs since the format and virtual machine ISA is so under-documented. I can't even find a working parser for the executable file format, and the disassemblers also don't work (because of the absence of parser, of course - the segment information is unknown), not alone decompilers.

[khusmann]

Wow, thanks for all your work on this @cqjjjzr , this is fantastic progress!

Sorry to hear about giving up on custom FWs, that's a bummer there's no tooling available for this arch. Any chance you found any firmware downloaders in your research? (So we wouldn't need to rely on the app for stock firmware updates). I made a bunch of progress figuring out the protocol manually from bluetooth dumps, but it was tedious and I got pulled into other projects. If there's existing code out there that'd allow us to do our own OTA updates that would be really nice...

[khusmann]

@cqjjjzr You probably already saw this, but here's a project for an SPI flasher that potentially supports the CSR8670 -- I wonder if it'd work around the signing issue, as you said https://github.com/lorf/csr-spi-ftdi

Also there's this mysterious github project: https://github.com/stephen-kun/csr8670 . Note the src/gcc folder has csr-gcc-3.3.3-xap-patch.tar.gz ... is that a patch to add csr support to gcc...? It looks like there's example apps in there too... what do you think?

edit: Ok, more encouragement in this thread: https://www.diyaudio.com/community/threads/csr8675-programming-guide-w-software-and-tons-of-csr-info.349336/

Looks like there's a bunch of people flashing firmware via SPI -- I don't see any mention of signing so that's a good sign.

Also the stephen-kun repo includes unsigned firmwares... https://github.com/stephen-kun/csr8670/tree/master/firmware/assisted/unified/gordon

[cqjjjzr]

Hello, and thanks for your reply!

For stock dfu updates, I suggest a look into the csr provided test api (not very public available, maybe available through the post on diyaudio). The fw flashing process is pretty similar to the one used in the app, but I do not have my D9000App with me recently, so unfortuately I cannot test flashing directly using Gaia App yet. You could first try to scrap the stock image from the gRPC endpoint and try to use the app to flash maybe.

For the SPI flash part, I'm pretty convinced that no signature check is performed during a SPI flash. I remembered using a cheap CH341 to flash RN42 firmware into a HC-05. Although they are using different chip than csr series, they are all csr branded and share the same BlueSuite toolset. From another blog post I read (translated from Chinese) 'if you flashed the wrong ps key... you will be unable to flash via (either cable or OTA) DFU and you will have to flash the loader using SPI'. So I believe this is the way to do that. You will at least need a flash clip or try to solder a few thin lines onto the module onboard. For my HC-05 I managed to solder 9 years ago, so it should not be impossible.

The gcc patch is correct (the same in the leaked ADK I installed), but I did not contains the code for ld.exe, which I believe is the key to understand the executable file format. (reverse eng that would require a LOT of skills and time) There are already complete documentations and tools for building CSR BlueCore VM apps from scratch, but reverse engineering is another story...

I have managed to make a bit further process on rev-enging the Android app, for more op codes and OTA fw updating. I will try to post my findings later so someone can test it out since I would not gain access to my rig until March. Let me know if you are interested (IDK if it is risky... technically it wouldn't brick your rig, but who knows...)

edit: the furthest progress I have made is unpacking the dfu file so the filesystem is obtained, with a vm.app file as the core. Other files like pcm files for voice prompts are also found. No tools to yank vm.app open yet, which is the real key IMHO.

[khusmann]

The gcc patch is correct (the same in the leaked ADK I installed), but I did not contains the code for ld.exe, which I believe is the key to understand the executable file format. (reverse eng that would require a LOT of skills and time) There are already complete documentations and tools for building CSR BlueCore VM apps from scratch, but reverse engineering is another story...

Ah gotcha -- darn!

I have managed to make a bit further process on rev-enging the Android app, for more op codes and OTA fw updating. I will try to post my findings later so someone can test it out since I would not gain access to my rig until March. Let me know if you are interested (IDK if it is risky... technically it wouldn't brick your rig, but who knows...)

Definitely interested! Here's where I left off in my work on the OTA fw updating, if you want to compare notes: https://github.com/khusmann/benlink/blob/firmware_updates/src/benlink/protocol/command/vm.py

[Ylianst]

By the way, even without looking into the firmware binary, if I have a binary file and want to do a update using the file over Bluetooth and you have the protocol for this, I would consider adding it to HTCommander. I imagine I have to send the firmware down by chunks.

[khusmann]

@Ylianst Yes it goes by chunks -- here's as far as I got before I left off, unfortunately won't have time to pick it up again for a while: https://github.com/khusmann/benlink/blob/firmware_updates/src/benlink/protocol/command/vm.py