Gadgetbridge: Support Withings Steel HR

[merlinschumacher]

Before opening an issue please confirm the following:

• [X] I have read the wiki, and I didn't find a solution to my problem / an answer to my question.
• [X] I have searched the issues, and I didn't find a solution to my problem / an answer to my question.
• [X] If you upload an image or other content, please make sure you have read and understood the github policies and terms of services

Your issue is:

Support Withings Steel HR

I'd like support for the Withings Steel HR. I own the smartwatch, but have issues connecting to it from my pc. It refuses the connection. I've attaced bluetooth hci logs from my Android phone, made when I synchronized the device with Nokias Health Mate app, when an SMS (from myself) was received and a calendar notification was send to the watch. The logs are readable by wireshark.

I've tried to connect to the watch in Linux using gatttool and bluepy. Neither worked.

Your wearable device is:

Withings Steel HR F4 Firmware 2421

Your android version is:

Android 7.0

Your Gadgetbridge version is:

0.21.6

New issues about already solved/documented topics could be closed without further comments. Same for too generic or incomplete reports.

btsnoop_hci.log
btsnoop_hci (Kopie).log

[aleho]

I've tried to dive deeper into the Bluetooth communication with this watch.

It seems to be primarily based on a challenge/response-protocol, at least for most of the "get current settings" / "change setting" implementation.

Reading a full HCI dump the first step looks like a request to transmit device data (the response includes the MAC address) which HealthMate answers with a longer message that might be some kind of hashed or otherwise obfuscated secret.

I also found a column in their device database table named "klSecret", which seems to support that assumption.

After authentication HealthMate e.g. queries the list of supported notifications (or probably also enabled ones) as soon as you open the device settings activity. Supported / enabled notification types seem to be 0301 (incoming call), 0501 (SMS message) and 0701 (calendar event) which then get submitted as event notification, as can be seen in one of your logs.

If you're interested, I started a small project on notifications (which still depends on HealthMate).

[vincegre]

@aleho Have you been able to make some progress since ? as I have a Withings Pulse that I'd like to get working with GadgetBridge and so all details you find on Steel HR might be interesting for the Pulse ;)

[aleho]

Actually, as you can't read an Android app's settings, retrieving the secret can't be done in a reliable way. So I stopped poking around.

The only way I could think of would be to reverse-engineer the initial app-to-watch pairing (where IMHO the secret will be generated) and then implement that. Or ask Withings for an API (which I'm pretty sure they won't do).

[vincegre]

The only way I could think of would be to reverse-engineer the initial app-to-watch pairing (where IMHO the secret will be generated) and then implement that. Or ask Withings for an API (which I'm pretty sure they won't do).

Well I'm trying to capture the pairing process but have difficulties to do it on my OnePlus 3 :( Might have to try on my tablet...
No hope on Withings side for an API, considering already all difficulties they have to keep Android app working from time to time...

[ragcsalo]

Here is the authentication process with the Withings Activité Pop:

1) the app sends a fixed command with a secret key: 010101000a012a00060101003d7fc1
2) the watch responds with a longer code, which contains the serial number, and also a random generated 16 byte code at the end:
0101280027012200231130303a32343a65343a32373a32643a326410dbe3e1c9abaf3f0335498b1051c81eca
3) the app encrypts the random key with the fixed key (method unknown), and sends back an even longer response, consisting of 4 parts (I copy each in separate row):

cda7bdfadedda2e1d99d2eaa0d2b057add802431
012200231130303a32343a65343a32373a32643a326410
262ab7697aedec774a760b8098de47ca

In this response the 1st and 3rd part is always the same... the 2nd and 4th part is always different.

Some more data coming from the watch:

0101280027012200231130303a32343a65343a32373a32643a326410c7e2a43760c738538bffc1ddbc1f7185

0101280027012200231130303a32343a65343a32373a32643a3264101a5db459514bd514e473a57700763ba5

0101280027012200231130303a32343a65343a32373a32643a326410e61065f6c78ea33adb16ae008b37b6b4

...and the corresponding responses by the app:

010128004001230015148239f43536c224e29206ca6e047f4fa61c0fced8012200231130303a32343a65343a32373a32643a326410972fc6316be88c5bb86cd3c26d44c02a

010128004001230015149352e469435b3103748a2c6dd45b1198b1d32397012200231130303a32343a65343a32373a32643a32641067d48c4208240a21cb158cd4ddd41754

0101280040012300151490376695af744060cb440d74726d6fe288444a94012200231130303a32343a65343a32373a32643a326410658e2a9866ab6af6f874f744f3f1b7ac

Maybe some of you can do something with these codes.... :-)

[SZenglein]

I also analyzed the pairing process on an actual Steel HR. It looks similar to the results from @ragcsalo, but not exactly the same. Please note that this is only one part that looked relevant to me, it could be missing important information, but I tried to leave out generic bluetooth communication, which I don't know much about.

1. Phone sends:
   0101010010012a00060101003d7e9609280002001c (this stayed the same for me over several pairing processes)
   @merlinschumacher's snoop:
   0101010010012a00060101002e3c56092800020018
   As opposed to the Activite Pop:
   010101000a012a00060101003d7fc1
   Maybe there is some part missing here?

2. The Steel HR responds: (I've kept the individual bluetooth packets split up)
   010101004d010100490000000008537465656c20 -> 010101004d010100490000000008 + "Steel "
   48521130303a30303a30303a30303a30303a3030 -> "HR 00:00:00:00:00:00" (address replaced)
   103163323535633336316461303638343600ffff -> ".1c255c361da06846..."
   ff08303031323030453000000012000014d300ff -> "..001200E0.........."
   ffff (these stayed the same for me over several pairing processes)
   @merlinschumacher's snoop:
   010101004d010100490000000008537465656c20 -> always the same
   48521130303a32343a65343a35393a64613a6634 -> "HR 00:00:00:00:00:00" (address replaced)
   103134333164626161363064366239356300ffff -> ".1431dbaa60d6b95c..."
   ff0830303132303042300000000f0000097500ff -> "..001200B0.........."
   ffff

There's some more stuff going happening afterwards which I haven't looked at in detail, but have some guesses:

1. Some back and forth:
   
   
   
   • Phone random write static value: '0101110000'
   
   
   • Phone Attribute Errors
   
   
2. SMP Pairing
3. More ATT
   
   
   
   • Request and receive "Steel HR E5" Device Name
   
   
   • some (useless?) back and forth
   
   
   • often "Sent Write Command" with same Value, probably calibrating
   
   
   • Phone sends Username and Secret (with some additional numbers)
   
   
   • Phone sends Activities ("Laufen", "Schwimmen", "Radfahren" in German) (with additional numbers)
   
   

@ragcsalo
Additionally, I want to note that the sequence 012200231130303a32343a65343a32373a32643a326410 seems to be an identification for your watch. It contains the serial number as you said. Searching for this number in your text, you can see that it appears multiple times. This would also explain the one static message you observed.

[ragcsalo]

We have already cracked the authorization process (Withings Activité Pop and Withings Move), I will write another comment later... :-)

[SZenglein]

Cool! Do you have working code for the pairing? I'd be interested in testing it on the steel hr.

[DezMakes]

I have a Steel HR Sport. I suspect that it is just a rebranded version that works the same but I could provide logs if needed.
I would also be down to contribute to implementing support in GadgetBridge, hope you guys can share more details about the authorization process.

[SZenglein]

@ragcsalo Any news on that?

[sunrez]

Hi @ragcsalo,

I too would love to see any code / updates!

[SZenglein]

I have a Steel HR Sport. I suspect that it is just a rebranded version that works the same but I could provide logs if needed.
I would also be down to contribute to implementing support in GadgetBridge, hope you guys can share more details about the authorization process.

@DezMakes I've started looking into it again. If you want we could collaborate on deciphering the protocol. Maybe together we can crack it.

[ragcsalo]

Sorry guys I've been busy with other stuff. I will try to post the code soon. :-)

[SZenglein]

Please do. Remember it does not have to be complete. Even if you only tell how the device secret is used and how the pairing works, others could work from that.

[MOE-JOE2]

@ragcsalo +1. Would be great if you could share some code! 👍