Smart rings with nrF chips

Hi everyone,

Has anyone started hacking a smart ring similar to smart watches. They have more or less same hardware like the other smart watches that are running the Espruino software.

https://www.aliexpress.us/item/100500628­2241664.html?spm=a2g0o.productlist.main.­15.438c4590tQY3B7&algo_pvid=990cea21-076­3-43dd-a321-924f8c221ffa&algo_exp_id=990­cea21-0763-43dd-a321-924f8c221ffa-7&pdp_­npi=4%40dis%21EUR%2159.33%2150.43%21%21%­21451.16%21383.49%21%4021032974170854413­38983843ebfb6%2112000036598148172%21sea%­21IE%21913614891%21AC&curPageLogUid=7tKL­Hs6ULpmY&utparam-url=scene%3Asearch%7Cqu­ery_from%3A

interesting but that one is over usd50 for me, here it is possibly same one for half https://www.aliexpress.com/item/10050064­67962445.html
however I am afraid that if it can't be taken apart without damage it quite likely won't be updatable as the firmware updates are typically signed

Wow, those look really cool.

if it can't be taken apart without damage it quite likely won't be updatable as the firmware updates are typically signed

I've wondered about this - I know atc1441 has a 'glitcher' for nRF52 that can allow you to read out the firmware of locked devices: https://github.com/atc1441/ESP32_nRF52_S­WD

The private key won't be in the DFU firmware, but I assume that if you could basically take one apart by destroying it (melt the case off with acetone?), and then read the firmware using the glitcher, you could find the public key - and then maybe you could brute-force it on a PC to ensure that you got an initdata packet that fooled the bootloader? But the hash looks like it's 256 bits (at least) so maybe that's not an option.

Thinking about this, as far as I can tell it's only the initData packet for DFU that has microecc run on it (not the whole firmware?), and that packet just contains the size and CRC of the actual firmware, so actually, if you:

• Found an existing ZIP file for a firmware update
  
• Looked at the 'dat' file to figure out what the CRC of the .bin file was
  
• Crafted a new .bin file with custom firmware but with a CRC that matched the CRC in the dat file
  
  

You should be good?

The CRC computation is pretty simple (crc32_compute function) and there's probably some fancy maths you could do to calculate what bytes you need to add right at the end of the binary to 'fix' it (maybe even a tool out there already?) - but actually I think if you ran crc32_compute on all of the file apart from the last 4 bytes, then just ran through all 4 billion combinations of the last 4 bytes on a modern PC, it probably wouldn't take all that long?

Also, I'm not sure if it's relevant but microecc had a security flaw in it (https://nvd.nist.gov/vuln/detail/CVE-202­0-27209) and the one in the ring's firmware almost certainly got that flaw.

Just to add to this:

It looks like the whole firmware is checked with microecc (in nrf_dfu_postvalidate) at the end so right after writing the firmware, it will fail unless we can match the hash (which may be very tricky given its size - although I believe there are some tools out there that can help?).

However, and @fanoush maybe you have some thoughts here because I think you've looked into this in more detail, but an nRF52832 band almost certainly only has 1 flash bank so it has to overwrite the existing app even before that ECC check. So when you do a firmware update, this should happen?

• Init packet is sent (with CRC, size, ECC hash, etc)
  
• Init packet is correct (it's from an official FW update) so it passes
  
• App area is erased, and the supplied firmware is written without any real checks
  
• Right at the end, it validates the firmware and will fail the ECC check - but all the firmware from the zip file is now actually on the device in the right place
  
  

So really it depends whether nrf_dfu_settings_write is ever called to invalidate the bank - because if not then it's possible that it could reboot, check the CRC of the data in flash (which would have been crafted to match what was on the device) and then passes and executes it?

Yes had same ideas but found out it is about finding SHA256 collision = different binary having same hash that is signed in init packet. this currently takes more time than the universe exists, or you get lucky and win a lottery.

init packet is signed so it must stay as it is and part of it is sha256 hash of whole binary - at least that is the core idea behind it, looks solid

Yes you can write modified data there as the sha256 hash is checked after it is all written, but then it will mark it invalid and won't execute it. So either you have bricked device sitting in DFU waiting for correct package or with dual banked update (when there is enough space) the new invalid code is sitting in empty space above the real application waiting for you to jump into it via some clever exploit of original application over BLE
EDIT: or softdevice, I think there is a reason why S132 2.0.0 and S132 3.0.0 are no longer available from downloads here https://www.nordicsemi.com/Products/Deve­lopment-software/s132/download

Thanks for sharing your thoughts. How about reaching to the manufacturers and ask for a custom firmware with Espruino? Like bagngle.js may be several people will be interested in this.

How about reaching to the manufacturers and ask for a custom firmware with Espruino?

I think that so far there are exactly zero cases out of many tries where it worked like this before (including both bangle.js watches). But maybe next time.

But still, if you can spare the money, get it and take it apart than that is still something that could be interesting. At least we would know there is indeed nrf52 chip inside.

but then it will mark it invalid and won't execute it

Ahh, thanks - that's a shame then. I was hopeful that maybe by not actually sending the 'finish' command and disconnecting we could skip the validation step at the end - but I'd imagine that it almost certainly invalidates flash as soon as it gets to the point where it's erasing flash pages.

How about reaching to the manufacturers

I have had virtually no success with this with watches so far - maybe it's a language barrier thing, but the only way Bangle.js 2 works is because it's got the programming pins on the rear so we can program it here. I don't even have the schematics for the device - everything has had to be reverse engineered.

It's not to say you shouldn't try though! You might get lucky.

There's also a miniscule possibility that the SWD programming pins are actually available on the device somewhere - either on the outside, or on test pads that you could get to by drilling small holes in the case and filling them after (but I guess you'd only find that out by dismantling/destroying one first).

Cool. I am willing to sacrifice one. I will try to order them this week. So, if I understand correctly, if the SWD pins are available, we can reprogram it right. My main interest is the heart rate sensor and getting raw values. The link I shared in the OP has HX3605 (I hope it has the drivers), I am not sure about the optical sensor in the second link. I will search for devices with HX3605 and try to place order.

Cool, let us know when you get it and what is its bluetooth name. We may already have its firmware and could tell if it is nrf52 inside. Some aliexpress listings even allow to return for free, not this cheap one though. I think hx3605 is used in Magic3/Rock/C6/C17/QY03 watches(?), getting raw data should not be big problem.

btw in this listing https://www.aliexpress.com/item/10050065­27342041.html which is not nrf chip it can be seen that some of them are actually transparent so you can really see where the chips are. This one is said to be FR8016HA

That's cool! If you can find a transparent one you might even be able to see the test points for SWD.

Hi guys.
I bought that ring about 3 months ago and it was supposed to be waterproof but the charging connector started to rust on my finger so I more or less stopped wearing it (the Aliexpress seller never refunded me anything despite his promises...).
Since then I have been desperate to hack into it.

After analyzing the Bluetooth requests, I've developed an ESP32 code as well as a Python code that reads the accelerometer values (they are sent over BLE only ~1/sec unfortunately, so nothing really usable for actions).
My Python code also triggers requests for HR readings.
(Let me know if anyone is interested, it would be a good excuse to start publishing on GitHub).

Besides that, I couldn't do much more. I can't update the firmware as the seller never gave it to me and it is nowhere to be found on the Internet.
Using the app NRF Connect on Android, I have access to the DFU, but I can't extract the firmware that way.

So yesterday after reading this post, I thought **** it, let's crack it open.
It put it in a vice, and I slightly deformed it, very gently.
I heard a "crack" and I saw that the outer metal ring cracked in a neat straight line (not sure if it was there from the factory and just glued before? or if I made that crack).
From there on, it was very easy to open the ring delicately.

I'm attaching detailed pictures.
As I've only started learning about electronics/ESP32 programming a few months ago, could someone indicate how to extract the firmware (for backup) and create my own from here onwards?

Also, it seems that by slightly unbending the flex PCB, I created a bad contact of some sort as my ring was turning on and off, and now not even on.. working on it 🤞

Any help would be much appreciated 😁
Arny.

3 Attachments

That's really cool! So looking at that, I'd say that most likely the pads on the pack marked D and C are SWDIO and SWDCLK respectively - so if you have an SWD adaptor that works with NRF52 chips you could connect those two, plus GND and you can flash it.

Some info at:

• https://forum.espruino.com/comments/1728­0505/ (I did this recently)
  
• https://forum.espruino.com/conversations­/335722/#14800444 (older post)
  
  

However it's super likely that the chip itself has had the software protection bits flashed, which means you can't read the code out. Although ATC1441 did have a hack for that using an ESP32 which you could give a try: https://github.com/atc1441/ESP32_nRF52_S­WD

But if that fails you'll just have to do the recovery over SWD (which wipes everything) and start from scratch. I'm not sure if @fanoush has written anything up on it, but you can flash a minimal Espruino firmware and then start messing with various wires (D0..D31) and see if you can figure out what's connected to what (but if you could get the firmware off it you could start to disassemble it and figure out which pins go where and what all the sensors are)

The good news about it I guess is that if you had a 'new' ring, it looks like you could cut a small section out of the cover and get to the GND/D/C pins quite easily, then could just fill it in with glue after.

could someone indicate how to extract the firmware (for backup) and create my own from here onwards?

What is bluetooth name of that device and what is the name of android mobile app for it? If it is that VWAR ring and the name is R1 or R2 then maybe we have matching DFU zip. Also is there some firmware version info in the mobile app?

EDIT: attached is some random nrf52 ring firmware, if the name is matching you may try DFU, either it will be refused or it will brick your device or it will still work. If it will still work then it can be later restored to it (over swd pins). Also the binary can be reverse engineered to get more info about the hardware.

2 Attachments

• R2-APP-DFU-V0.49.zip
• R1-APP-DFU-V0.03.zip

@Gordon thanks for all the advice and information. I'll try to make some time and try with my ST-LINK and/or the ESP32 method whenever possible. Great idea for drilling holes through the cover for new rings.
I've had a look at what ESPDruino is and it seems like a genius idea (I learned development with JS more than 20 years ago so will have to give it a try as well eventually).
Also, if you are the Gordon of the Kickstarter campaigns, I have to say well done to you, great projects, and good on you to deliver where most projects fail 💪

@fanoush where did you find those firmwares?
My ring appears as "R8 B837" but it seems identical to the R2 models I see online. The app is Smart Health and if I remember the firmware version was 0.3 (I still struggle to keep the ring on, not sure where the bad connection is now).

@user157679 thanks! I appreciate it!

where did you find those firmwares?

Well, it is from Smart Health app - firmware update functionality available from their servers, sadly there is no firmware file named R8, btw is b8:37 part of your device mac address? I'll search other binaries for R8 maybe the file has different name.

EDIT: searched all binaries and sadly don't see any with "R8" inside. for R1 and R2 the name is probably done in same way as there is this in the binary R2..%s %02X%02X so R2 gets formatted with two hex numbers (possibly from MAC address)
Here are device names with nrf52 firmware update available from SmartHealth BNR860,DEFIRO,E04S,E10PROA,E20E10A,E20E1­0I,E20E10J,E66C,E67,E68,E80A,E80C,E80DL,­E80DLA,E80DLF,E86,E86DL,ES09,F81,FW46,H0­1,H28,H6,H6B,M18PLUS,M8,P50C,R01,R02,R1,­R2,R2C,S2,S2D1,S6,S6Glu,TYFE80A,U32,V6,Y­B,YC,YC024,YC030,YC31,YC66
most of them are probably smartwatches (their firmware is much bigger, over 300KB vs <200KB for rings)