Humon Hex Bluetooth Protocol

AKA Reverse Engineering the Humon Hex Muscle Oxygenation Sensor’s Bluetooth Protocol

Athletes (or I suppose more generally mammals) have muscles. Muscles consume oxygen when they do work and output carbon dioxide into the host system’s blood. If insufficient oxygen is present, the muscle starts consuming glycogen, which is a somewhat finite resource and results in lactate as a byproduct of the consumption. Work done through the consumption of oxygen is aerobic work and work done with reduced oxygen is anaerobic work.

The transition between these two states is caused by a balance between a muscle’s ability to consume oxygen and the host system’s ability to supply oxygen to that muscle. Generally heart rate is the most-easily acquired indicator of whether or not the host system is struggling to supply enough oxygen to its peripherals, but heart rate has high hysteresis and varies per person, amongst other issues. As a result, Muscle Oxygenation “moxy” sensors are useful because they’re precise, provide absolute readings and they’re fast. They are analogous to reading a car’s engine RPM directly vs trying to figure out the RPM by looking at the water temperature.

Unfortunately, moxy sensors have historically been very pricey with units like the Moxy and BSX Insight in the range of several hundred dollars. A coach told me recently that athletes generally go to a lab to be measured (?!). A new company on the block, called Humon, has released a product called the Hex and the Hex does moxy. The Hex is less than half the price of its competitors. It’s also small and modern, with wireless charging. It’s generally a very very cool device.

A Humon Hex
The underside of a Humon Hex

The Hex transmits data on both ANT+ and Bluetooth Low Energy (BLE/Smart). The ANT+ variant of the data is standardised and easy to acquire if you have the correct radio to do it. The BLE variant of the data unfortunately is not standardised and Humon declined my request for the protocol specification… this guide is both to help others and a reminder to myself how the device works and more generally how to access BLE sensors on Linux.

I want a small logging device for my bicycle 😉 but I don’t want something that has a display because I don’t want to be distracted. I just want the data for later review, so the logging device should ideally be small enough to be tucked away in or under the bicycle’s seat. In order to achieve this I figured I’d build a logging device out of THE AMAZING Raspberry Pi Zero W. The Zero W has a built-in wifi and bluetooth radio but said radio doesn’t support ANT+ and adding ANT+ would increase the size of the device, look crap and use more battery power. Bluetooth Low Energy is therefore the best option.

Everything that follows should work on any device running Linux with BLE support and running a recent version of Bluez (5.40 up).

Start by putting the Hex on you, press the power button once to start it up. The LED will rapidly fly through some colours and then go red. Double-push the button, the LED will go blue and after a while, it’ll go green. Green seems to mean the device is both calibrated and transmitting.

Get yourself a screen/byobu session : screen
Run bluetoothctl
In the interactive console :
power on – this powers on the BLE radio
scan on – this begins scanning for hardware
Wait for the device to show up as a detected device.

The hex will show up as “Hex XXXX”. This next step may not entirely be necessary :
In the terminal enter :
scan off – to stop the scan, we know what devices are present now
agent on – this is to enable pairing authentication
default-agent – this exchanges some keys but doesn’t ask for input
pair 00:00:00:00:00 – replace the zeroes with the mac address of your Hex

The device should now be paired.
connect 00:00:00:00:00 – connects to the device
info – if you want some cool info:
Name: Hex A2C6 Alias: Hex A2C6 Paired: yes Trusted: no Blocked: no Connected: yes LegacyPairing: no UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb) UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb) UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb) UUID: Battery Service (0000180f-0000-1000-8000-00805f9b34fb) UUID: Vendor specific (0000f00d-1212-efde-1523-785fef13d123)

This next part requires a “characteristc”. I’m going to demonstrate the 0000deef-1212-efde-1523-785fef13d123 characteristic, but the others I’ve looked at are listed at the bottom of this page. the deef characteristic is listed in the Humon Hex APK source code as HUMON_CALCULATED_DATA_CHARACTERISTIC.

In the terminal : select-attribute /org/bluez/hci0/dev_F5_63_A2_C6_8D_8D/service001a/char0024
and then read. The result will look like this :

And yes, I gave some thought to whether or now I should leave the MAC addresses in… it’s a moxy sensor 😀

The resulting values count as 16 bytes in total, which seems like… a float maybe ? I couldn’t figure it out easily, so I grabbed a copy of the Humon Hex Android APK and decompiled it. It took a lot of digging as the app is a React Native application with most of the logic minified into a horrible blob of Javascript… BUT grep exists, so yay. After much grep’ping I came across this :

apk/assets/shell-app.bundle:__d(function(E,R,_,A,T){Object.defineProperty(A,"__esModule",{value:!0});var C='0000-1000-8000-00805f9b34fb';A.BleUuid={DFU_SERVICE:"0000FE59-"+C,HUMON_DEVICE_INFORMATION_SERVICE:"0000180a-"+C,HUMON_MODEL_CHARACTERISTIC:"00002a24-"+C,HUMON_SERIAL_CHARACTERISTIC:"00002a25-"+C,HUMON_FIRMWARE_VERSION_CHARACTERISTIC:"00002a26-"+C,HUMON_HARDWARE_VERSION_CHARACTERISTIC:"00002a27-"+C,HUMON_SOFTWARE_VERSION_CHARACTERISTIC:"00002a28-"+C,HUMON_MANUFACTURER_CHARACTERISTIC:"00002a29-"+C,HUMON_DATA_SERVICE:"0000f00d-1212-efde-1523-785fef13d123",HUMON_RAW_DATA_CHARACTERISTIC:"0000beef-1212-efde-1523-785fef13d123",HUMON_CALCULATED_DATA_CHARACTERISTIC:"0000deef-1212-efde-1523-785fef13d123",HUMON_COMMAND_CHARACTERISTIC:"0000abcd-1212-efde-1523-785fef13d123",HUMON_STATE_CHARACTERISTIC:"0000abc0-1212-efde-1523-785fef13d123",HUMON_BATTERY_SERVICE:"0000180f-"+C,HUMON_BATTERY_CHARACTERISTIC:"00002a19-"+C,HEART_RATE_SERVICE:"0000180d-

This told me what the characteristics on the device do. EVEN MOARRRRRR grep’ping later I found some of the code the app uses to reconstruct the data from the device. This is the cleaned up version :

groupNBytes = function(bytesArray, sizeOfGroup) { var n = Object.keys(bytesArray).map(function(sizeOfGroup) { return bytesArray[sizeOfGroup] }); return n.reduce(function(bytesArray, t, a) { return a % sizeOfGroup == 0 && bytesArray.push(n.slice(a, a + sizeOfGroup)), bytesArray }, []) }

byteArrayToFloat = function(r) { var e = r[3] << 24 | r[2] << 16 | r[1] << 8 | r[0], n = new ArrayBuffer(4); return new Int32Array(n)[0] = e, new Float32Array(n)[0] }

Take the values from the terminal, build an array with them and then curry them together to get something cool :
[0] 37.44892501831055
[1] 68.58602905273438
[2] 0.6468204259872437
[3] 3

In this case [2] very closely matches the value my Wahoo ElMENT Bolt showed when I executed the read command in the terminal (multiplied by 100x).

You can stream these values by entering notify on once the attribute has been selected.

That’s about it for now, the next step is building a logger.

P.S. The battery level can be found on this characteristic :
select-attribute /org/bluez/hci0/dev_F5_63_A2_C6_8D_8D/service000b/char000c
0002a19-0000-1000-8000-00805f9b34fb

Reverse Engineering the Ubbey Box

Some time ago I came across an ICO (distressed choir wails in the background as if welcoming lucifer to a dark cathedral) and said ICO was aiming to build a decentralised storage system. “Cool”, I thought, eager to experiment with a small amount of Ethereum on a diverse set of ICOs. I gave them some ETH… but before doing so I discovered that decentralised storage isn’t a new thing. Several projects have tried (and somewhat succeeded) in building dencentralised storage networks already; big examples being BitTorrent and IPFS being (neither offer in-band remuneration). In addition, cryptocurrency-supported examples include SiaCoin and StorJ – both of which have serious issues. After contributing to the Ubbey/Universal Labs ICO I decided to give Sia hosting a try… but that’s another story.

Ubbey’s 2000 Ethereum ICO was ultimately successful and I got some tokens. Shortly thereafter Ubbey allowed ICO participants to use some of their tokens to order their “Ubbey Box” at discounted rates. By this stage I had acquired additional Ubbey tokens at a fraction of the ICO price on decentralised exchanges (I love DEXs). Yesterday, the Ubbey box I ordered arrived. I only recently got a chance to play with it.

As with most boxes I don’t control, the Ubbey box has gone onto a DMZ network, which means it can’t access my home security cameras, storage machines, geyser controller, irrigation controllers… you get the idea.

First things first, unpacking :

Very nice Ubbey… the packaging looks good, even after being bashed around by DHL.

An Ubbey Box, by Universal Labs

This box is very obviously a general purpose media player that’s been rebranded to fit Ubbey’s needs. There’s nothing wrong with that, it’s sensible. They inadvertently hint at it being a general purpose media box with their specs, which quote the device as having an ARM CPU in it with 2 GBs of RAM, a VERY common configuration for ARM dev boards from around 2 years ago. This is begging to be disassembled…

So, onto the DMZ it goes. I installed the Ubbey app from the Google Play Store and soon enough it found the box (through what looked like an IP scan of the local subnet). The scan was followed by a login prompt and then a firmware update (forced) :

Unfortunately, it’s been about 2 hours now and it’s still updating…

While we wait for it to update, let’s see what’s inside :

This is how the device looks inside with the lower cover removed (it’s upside down in this shot).
The Ubbey logo is illuminated by an over-spec’ed 7-segment LED display.
The top-side of the main board of the Ubbey Box.

The top side of the main board of the Ubbey Box is -very- interesting. The device is equipped with a dual-chain/MIMO wifi module and the box has antennas for it installed. The top cover of the box has a large metal mass, which is squeezed against the top of that shielded cage/case with a thermal pad sandwiched inbetween. The board is clearly designed to have multiple display outputs with one set of traces unpopulated. The FORESEE module is probably flash “ROM” storage for the OS, which is OpenWRT. Also present are traces/holes for a TTL UART, an SD Card module and two USB ports (one of which appears to be USB 3).

It should be noted that the Ubbey Box runs an SSH daemon by default – attempts to log in to it using root/root, root/password, root/etc. proved fruitless.

The top side of the Ubbey Box PCB with the CPU/RAM shield/case and thermal pad removed.

A quick Google search for SEA Beelink SEA I found me this Amazon page :

Wireshark packet sniffing indicates that the device spends a lot of time communicating with 47.100.119.151, which seems to reverse-resolve to api.yqtc.co. Visiting the server with https indicates that the server’s HTTP certificate expired in May… so I thought the client device may be less than strict with it’s certificate acceptance. Some DNAT rules on my router and mitmproxy later and I got this :

mitmproxy is very cool software. Unfortunately the Ubbey Box’s Go client, although permissive, isn’t that permission 😉

It would appear that the best way of gaining access to this device is via the TTL UART.

Update 22 September 2018 : Serial Debug Console

Not my neatest work, but I now have access to the device’s debug console…
Part of the Ubbey Box’s boot process and the OpenWrt failsafe mode entry point.
The Ubbey Box’s labeled partitions.
The contents of description.xml inside what looks like an overlay filesystem called “nasetec”

More to follow…