Practical Introduction to BLE GATT Reverse Engineering: Hacking the Domyos EL500 (2023)(jcjc-dev.com)
jcjc-dev.com
Practical Introduction to BLE GATT Reverse Engineering: Hacking the Domyos EL500 (2023)
https://jcjc-dev.com/2023/03/19/reversing-domyos-el500-elliptical/
9 comments
Now that I think about it, it's pretty shocking if a trainer doesn't support FTMS - did you check if it does? Possibly they are programming the Microchip BLE gateway to implement the necessary FTMS characteristics and using the UART bit for talking to the app.
@blutack, I can confirm this - I recently purchased a treadmill homeTro 3.0HP and it has a third-party Bluetooth Module UART module from https://www.fitshow.com/. It seems fitshow developed this module and white-label apps to add smart features to the treadmill and other fitness devices.
I cannot confirm if it's microchip UART to BLE because since I would have to desolder it, I successfully connected UART at 4800 baud: https://pastebin.com/NCiQwr8T
If anyone knows how to decode FitShow UART protocol or has some ideas, please share your thoughts :)
If anyone knows how to decode FitShow UART protocol or has some ideas, please share your thoughts :)
If you generated that UART log with an ESP32, then ignore me! Otherwise, it looks like you found the debug port for an ESP IDF project. In that case it's not likely to use the BLE to UART Microchip unfortunately. Therefore there's no guarantee that the UART matches anything to do with the bluetooth (the ESP32 is a separate processor which could be doing a whole bunch of smart stuff).
Also, those Microchip modules are an expensive way to add bluetooth to something (trading dev time for BOM) - I would be surprised to see them in any mass produced or cost optimised design.
Generally, best bet is probably to run jadx over the android app and go from there.
That said, it looks like the FitShow module supports FTMS (standard Bluetooth fitness profile). In that case, fantastic, you should be able to use any off the shelf FTMS bluetooth library to pull data from it. No UART required.
Also, those Microchip modules are an expensive way to add bluetooth to something (trading dev time for BOM) - I would be surprised to see them in any mass produced or cost optimised design.
Generally, best bet is probably to run jadx over the android app and go from there.
That said, it looks like the FitShow module supports FTMS (standard Bluetooth fitness profile). In that case, fantastic, you should be able to use any off the shelf FTMS bluetooth library to pull data from it. No UART required.
My apologies, I captured the logs through EPS32 :) since it's not Microchip, the UART protocol is probably a custom FitShow one.
I've tried to use FTMS from the Kinomap app, but it seems the FitShow module I have doesn't support it. I'm yet to look into the BLE GATT part to confirm.
Will keep digging. Thanks for the reply!
I've had a lot of fun with this reverse engineering my Napoleon gas fireplace BLE controller for the purposes of integration with Home Assisstant.
In the process discovered the UART protocol it speaks with the very common SIT ProFlame 2 fireplace controller. So you could now build a very cheap controller for ProFlame 2 based fireplaces.
I went the Android Bluetooth HCI snoop log + Wireshark route.
I wrote a Wireshark protocol dissector for that specific BLE protocol which you can use with the Android BT logs: https://github.com/kaechele/bonaparte/blob/main/contrib/wire... I found this extremely valuable when debugging, because it allows me to visualize both the packets the OEM app sends and compare this with what my library sends over the air.
I ended up documenting my findings here: https://bonaparte.readthedocs.io/
BLE hacking is pretty fun.
I went the Android Bluetooth HCI snoop log + Wireshark route.
I wrote a Wireshark protocol dissector for that specific BLE protocol which you can use with the Android BT logs: https://github.com/kaechele/bonaparte/blob/main/contrib/wire... I found this extremely valuable when debugging, because it allows me to visualize both the packets the OEM app sends and compare this with what my library sends over the air.
I ended up documenting my findings here: https://bonaparte.readthedocs.io/
BLE hacking is pretty fun.
I like piggy backing off the target app using Frida -- https://frida.re/
I've done something similar for a rowing machine. There is actually a bluetooth standard for fitness machines which was applicable in my situation.
https://www.bluetooth.com/specifications/specs/fitness-machi...
https://www.bluetooth.com/specifications/specs/fitness-machi...
[deleted]
https://developerhelp.microchip.com/xwiki/bin/view/applicati...
It's what happens when a product developer already has a design for a previous gen and needs to add "smart" with minimum effort, so they throw a Microchip UART to BLE gateway chip in. The chip basically just does single byte UART over BLE over a pair of characteristics, which is very much an impedance mismatch with how BLE is designed to work. That's why some of the things seem to not align with the spec and why the protocol seems so stateful.
On the plus side, it means de-compiling the android app is very helpful as there will be a parser for the binary protocol. It's also easier to work with for RE in some senses as the actual bluetooth code required is minimal (set up a notification and read the RX characteristic, write another). If you are ok with opening things, you can also use a USB serial adapter to trace the UART traffic between the gateway chip & the control IC (there's an AT style protocol that's all well documented).
Fundamentally, it's probably either some basic hardcoded request/reply, or there's a "send me x datavalue every x seconds" command packet. Once you've got both sides of the UART, it will hopefully be fairly clear. Might even be plain ASCII...
There's various bits and pieces on github that might be helpful, and Microchip have some developer tooling.