Question Are Mi Band 5 firmwares signed?

[Tunas]

I've been trying to make a custom firmware for the Mi Band 5 (or at least understand its inner workings) by disassembling the firmware image and seeing how it works.
However, any modifications make the firmware image unable to be flashed (it gets to 100%, and then says "Update failed", going back to the old firmware).
Is the firmware image signed and unable to be changed without failing verification, or is there some checksum embedded in it that I need to modify as well?

 

[ChhayankSharma]

I've been trying to make a custom firmware for the Mi Band 5 (or at least understand its inner workings) by disassembling the firmware image and seeing how it works.
However, any modifications make the firmware image unable to be flashed (it gets to 100%, and then says "Update failed", going back to the old firmware).
Is the firmware image signed and unable to be changed without failing verification, or is there some checksum embedded in it that I need to modify as well?

yes, mi band 5 uses same microprocessor as mi band 4 and its firmware is also signed in same way as mi band 4. if we are able to find way to modify mi band 4 firmware, we will be able to modify mi band 5 firmware also using same method.

 

[Tunas]

It would be really easy (well, relatively easy) to make custom firmwares if one firmware version (e.g. initial beta) was signed but didn't verify signatures yet; you flash that one and then flash whatever unsigned one (which also doesn't check signatures) you want.
Given that's sadly not the case (I checked the very first beta that was made available) maybe looking into the firmware itself to find the update verification code could shed some light on:

• what type of signature is it (which cryptographic algorithm) - my guess is RSA or something related;
• if we're lucky, the signing key (though I think Huami isn't this stupid )
• how the signature is checked (i.e. looking for ways to make it always return true, or something related).

I'm open to discuss or look into any observations that people have made about this, because I've only done a preliminary decompilation using Ghidra (and I'm not very good with ARMv8-M assembly code) which revealed some update-related functions (but nothing I can make sense of, or make a coherent relation with).
@ChhayankSharma, do you have any more threads or information about attempts to reverse engineer / make a custom firmware for the Mi Band 4 I can read?

 

[ChhayankSharma]

It would be really easy (well, relatively easy) to make custom firmwares if one firmware version (e.g. initial beta) was signed but didn't verify signatures yet; you flash that one and then flash whatever unsigned one (which also doesn't check signatures) you want.
Given that's sadly not the case (I checked the very first beta that was made available) maybe looking into the firmware itself to find the update verification code could shed some light on:

• what type of signature is it (which cryptographic algorithm) - my guess is RSA or something related;
• if we're lucky, the signing key (though I think Huami isn't this stupid )
• how the signature is checked (i.e. looking for ways to make it always return true, or something related).

I'm open to discuss or look into any observations that people have made about this, because I've only done a preliminary decompilation using Ghidra (and I'm not very good with ARMv8-M assembly code) which revealed some update-related functions (but nothing I can make sense of, or make a coherent relation with).
@ChhayankSharma, do you have any more threads or information about attempts to reverse engineer / make a custom firmware for the Mi Band 4 I can read?

I really didnt understand anything you said maybe you could explain it to me? No i did not try to reverse engineer the firmware(I dont know how to. i tried looking for a tutorial but could not find. I just know programming in java, python, C# for unity, arduino, and am learning cpp and am NOT trying to make a game engine with Chernos game engine series. I need more experience with cpp I have less than a week of experience in cpp. it is too advance. I will learn game engine development later) . I have found people on this thread saying that the firmware is signed.

 

[rendal]

Huami uses ready-made solutions from Dialog and also specifically FreeRTOS, emWin, libraries from SEGER and the like. By this I mean that the firmware signing technology is determined by the routine of the development environment and the SDK and the pre-prepared libraries from Dialog. The principle is therefore known and cannot be circumvented unless someone finds a bug in the routine and uses it to update non-genuine firmware.
I would look for a solution in the possibility of inserting parts of Resources, Fonts, etc., which is all in Flash, from where the complete firmware is loaded, where the modified ARM code contained in Resources, Fonts, etc. would be used to control the application.
For example, with Amzfit Bip it is already possible to run ARM code (mini applications) that has been inserted into Resources. However, in order to support this, you must use the modified base firmware in advance.

 

[Tunas]

Huami uses ready-made solutions from Dialog and also specifically FreeRTOS, emWin, libraries from SEGER and the like. By this I mean that the firmware signing technology is determined by the routine of the development environment and the SDK and the pre-prepared libraries from Dialog. The principle is therefore known and cannot be circumvented unless someone finds a bug in the routine and uses it to update non-genuine firmware.

I see, that's a valid point.

I would look for a solution in the possibility of inserting parts of Resources, Fonts, etc., which is all in Flash, from where the complete firmware is loaded, where the modified ARM code contained in Resources, Fonts, etc. would be used to control the application.
For example, with Amzfit Bip it is already possible to run ARM code (mini applications) that has been inserted into Resources. However, in order to support this, you must use the modified base firmware in advance.

Other than trying to execute code from other portions which are unsigned, do you have some ideas on firmware modification which don't involve physically opening the Mi Band and soldering wires to the SPI flash memory?
Also, is it possible to make an invalid font file, which has parameters in its header in such a way that it would extend beyond the memory where the actual font data is, thus placing arbitrarily controlled data in the executable code portion?
I'm not too educated on how the ARM Cortex-M33 does memory protection, and how the firmware flashing routine is programmed (but information about both should be available; one by reading online documentation and the other by disassembling the firmware flashing code)
I would love to see this device (and the Mi Band 4, for that matter) get custom, more powerful firmware in the future; so, I'm interested in any new developments about it. Sadly, other than some Russian forums and the info you gave me now, I couldn't find anything more about the topic :/

EDIT: Another question I'd love to know the answer to. If Huami introduced a bug in some firmware revision (most likely a beta version) which allowed for arbitrary code execution, how would one find it without trying out every single firmware to see the bugs?
I've been thinking about taking every firmware revision, disassembling it and then doing a Program Diff to see what code has changed, focusing mostly on the firmware update function and whichever functions it calls. However, I haven't been able to find which function this is and I need someone more skilled in reverse engineering to annotate the ASM code to make it easier to find what depends on what, and such.

 

[ChhayankSharma]

I see, that's a valid point.

Other than trying to execute code from other portions which are unsigned, do you have some ideas on firmware modification which don't involve physically opening the Mi Band and soldering wires to the SPI flash memory?
Also, is it possible to make an invalid font file, which has parameters in its header in such a way that it would extend beyond the memory where the actual font data is, thus placing arbitrarily controlled data in the executable code portion?
I'm not too educated on how the ARM Cortex-M33 does memory protection, and how the firmware flashing routine is programmed (but information about both should be available; one by reading online documentation and the other by disassembling the firmware flashing code)
I would love to see this device (and the Mi Band 4, for that matter) get custom, more powerful firmware in the future; so, I'm interested in any new developments about it. Sadly, other than some Russian forums and the info you gave me now, I couldn't find anything more about the topic :/

EDIT: Another question I'd love to know the answer to. If Huami introduced a bug in some firmware revision (most likely a beta version) which allowed for arbitrary code execution, how would one find it without trying out every single firmware to see the bugs?
I've been thinking about taking every firmware revision, disassembling it and then doing a Program Diff to see what code has changed, focusing mostly on the firmware update function and whichever functions it calls. However, I haven't been able to find which function this is and I need someone more skilled in reverse engineering to annotate the ASM code to make it easier to find what depends on what, and such.

Why do you need to edit the firmware??

 

[Tunas]

Why do you need to edit the firmware??

To be honest, I'm just curious how it works, and would like to (one day) develop extra functionality for it.
An idea I had in mind was TOTP token storage, because all it would have to do is calculate the current one-time password and display it on screen. It's one of those things that would be cool to have, but that Huami wouldn't want to implement.

 

[rendal]

I see, that's a valid point.

Other than trying to execute code from other portions which are unsigned, do you have some ideas on firmware modification which don't involve physically opening the Mi Band and soldering wires to the SPI flash memory?
Also, is it possible to make an invalid font file, which has parameters in its header in such a way that it would extend beyond the memory where the actual font data is, thus placing arbitrarily controlled data in the executable code portion?
I'm not too educated on how the ARM Cortex-M33 does memory protection, and how the firmware flashing routine is programmed (but information about both should be available; one by reading online documentation and the other by disassembling the firmware flashing code)
I would love to see this device (and the Mi Band 4, for that matter) get custom, more powerful firmware in the future; so, I'm interested in any new developments about it. Sadly, other than some Russian forums and the info you gave me now, I couldn't find anything more about the topic :/

EDIT: Another question I'd love to know the answer to. If Huami introduced a bug in some firmware revision (most likely a beta version) which allowed for arbitrary code execution, how would one find it without trying out every single firmware to see the bugs?
I've been thinking about taking every firmware revision, disassembling it and then doing a Program Diff to see what code has changed, focusing mostly on the firmware update function and whichever functions it calls. However, I haven't been able to find which function this is and I need someone more skilled in reverse engineering to annotate the ASM code to make it easier to find what depends on what, and such.

The firmware update function is not included in the .fw file. The Firmware (* .fw), Resources (* .res), Fonts (* .ft) files, are only updatable parts of the Main Firmware, ie blocks of Flash memory. Of course, the firmware update function can also update other parts such as the bootloader and others.
I recommend decoding the full Firmware to understand all the features. So read all the Flash content, with the ability to write Flash, which will also allow you to manipulate Fimrwar as part of developing your own solution.

 

[Tunas]

The firmware update function is not included in the .fw file. The Firmware (* .fw), Resources (* .res), Fonts (* .ft) files, are only updatable parts of the Main Firmware, ie blocks of Flash memory. Of course, the firmware update function can also update other parts such as the bootloader and others.
I recommend decoding the full Firmware to understand all the features. So read all the Flash content, with the ability to write Flash, which will also allow you to manipulate Fimrwar as part of developing your own solution.

If I ever manage to open up the Mi Band without destroying it, and find a suitable flash reader, I will

 

[He5am2099]

Please share how you decoded and edited the firmware if it worked? ? ?

 

[rendal]

If I ever manage to open up the Mi Band without destroying it, and find a suitable flash reader, I will

Here is ( [UNBRICK] Mi Band 3 (with | without NFC) | GeekDoing ) the user procedure. With Mi Band 5 it is not tested (whether the given flash is supported), but the principle is the same. Opening the cover is also different, using a hot air gun.

 

[Johnson070]

Here is ( [UNBRICK] Mi Band 3 (with | without NFC) | GeekDoing ) the user procedure. With Mi Band 5 it is not tested (whether the given flash is supported), but the principle is the same. Opening the cover is also different, using a hot air gun.

Hello, I want to use a programmer to download the firmware from the watch. Can you help me decipher the firmware?

 

[rendal]

Hello, I want to use a programmer to download the firmware from the watch. Can you help me decipher the firmware?

If you use an SPI programmer to download the firmware, there is no need to decrypt it. Firmware in Flash memory should not be encrypted. Signature Firmware is used to verify, if the signature is invalid, the firmware cannot be uploaded via bluetooth.

 

[Johnson070]

If you use an SPI programmer to download the firmware, there is no need to decrypt it. Firmware in Flash memory should not be encrypted. Signature Firmware is used to verify, if the signature is invalid, the firmware cannot be uploaded via bluetooth.

Thanks very much.
When I download the firmware from the bracelet I will post it here. I will also try to unload from the processor and memory

 

[ldicdican]

Thanks very much.
When I download the firmware from the bracelet I will post it here. I will also try to unload from the processor and memory

Waiting for your success on this firmware "hacking" ?

Good luck brother ?

 

[rendal]

Waiting for your success on this firmware "hacking" ?

Good luck brother ?

Unfortunately, this method is not generally applicable. You need to have an SPI / JTAG programmer and hacking only your device.

Modified firmware cannot be uploaded via bluetooth, firmware must be signed with correct key.