Friday, December 12, 2014

Freestyle Libre: software to meter communications and sensor expiration.

Abbott Freestyle Libre local communications

In a recent post I wondered if SSL was required to protect local communications between the Freestyle Libre software and its meter. It would be a nice touch if it was used but, of course it is not (objectively, it doesn't matter - if your PC is compromised, there is no need to eavesdrop on your meter).

The Freestyle Libre software is interesting, in the sense that it somewhat breaks the mold of the typical diabetes tracking software that is either borderline patronizing or a bit hardcore for the average user, contributing to the "downloading of results" ceremony during the quarterly endocrinologist visit.

It's also very unusual in the sense that it requires the reader to be connected to the PC (and therefore, in most cases, that an upload to Abbott occurs) to access reports. The software doesn't even bother to store results locally but fortunately offers a decent export functionality...

Server and Client

That peculiar philosophy and the SSL upload mystery prompted me to have a deeper look a couple of days ago. How does this work?

It's fairly simple. When the reader is connected, it starts a server to which the local software connects. the parameters are in a config file in the installation directory (the default log path, loglevel and flages may have been changed here)


The license information and the upload server are also specified in a config file, in the hidden "C:\ProgramData\Abbott Diabetes Care" folder. Please note that when I say "hidden", I mean that it is usually not visible to the non-technical user, not that it is intentionally hidden by Abbott.

app_license_path_string=C:/Program Files (x86)/FreeStyle Libre/license_en_GB.pdf
installDir=C:\Program Files (x86)\FreeStyle Libre

There is no need to use any fancy USB monitor to have a look at what is going on as all communications between the software client and the hardware server happen through sockets over that USB connection. Note: on the current Windows operating systems, traffic sniffers such as wireshark won't see the locahost to localhost connection and you will need to use a raw socket sniffer such as rawcap to catch the transactions.

Easy stuff

At that point, things become quite easy - you simply connect the reader and capture the transfer, then interpret the capture file with wireshark.

After an initial handshake and some setup exchanges, the reader delivers all the available data to the software client which then uses that data to generate the report. The 612 bytes records, which include some header and can be considered as 572 bytes records are transferred to the client. Just as it is the case with the sensor itself, the Libre operates on a circular Last In Last Overwritten buffer and that is why you can only keep and interpret a limited amount of data in that software.

There are several types of records, for immediate spot checks glucose values, historical glucose values, insulin, meal and exercise data, notes, error conditions, etc... The bad news is that the data delivered to the PC software is already processed (among other things by the active copy of the calibration data) and, in that sense, not helpful to interpret the raw sensor data collected by NFC.

The good news is that it is quite easy to interpret, This could be useful, for example, for someone developing an import module for a more generic diabetes tracking software. Since it is not my goal and I am perfectly happy with the official data export Abbott makes available, I will just go over the basics very quickly.

For an export record that reads like this

The data packet contains (important info highlighted)

There are a few peculiarities and different types of records. I will not go through all of them as I don't really use the insulin/food/exercise/note logging features or the internal glucose meter. Once you have a general idea on how to capture the data and a few test cases in your reader, unlocking the code is trivial.

One interesting side effect of that circular buffer architecture is that you can actually lose spot checks if you do too many of them and the table overflows. It is also unclear why Abbot would duplicate some information, such as the date in the above example but they may have their reasons.

The life of a servant is to follow orders.

That is also true for the server in the Abbott meter. You can send commands to it and retrieve explicit info or flash a new firmware if needed. Again, my goal here is not to explain how to patch your Libre receiver and I will simply show the simplest command that you can send to the reader to change its date - time.

In typical socket fashion, your post a raw packet containing your command and its parameters.

000c : 12
000b : 11
07de : 2014
0001 : 01 H
0012 : 18 min
001A: 26 sec

Again, it is easy to experiment with the local software and interpret the packets sent with each command if you are interested. This is left as an exercise for the reader, as they used to say...

Extending the sensor?

Some potentially bad news: while my sensor kept delivering data for a while after it had officially expired (20042 measures - Running Time : 13 days 22 hours 2 minutes - the clock of the device drifts a bit), it did stop a day later (21449 measures). The battery could deliver a 42 miliamp peak current at 1.59 V, an apparently higher load than the first one. That seems to mean that the sensor either expires by itself (or is actively stopped by the meter) but that also means that the battery does not seem to be the limiting factor (with the usual caveat that measuring the remaining capacity of a battery is tricky and that we now only have a sample of 2)

Running Time : 14 days 21 hours 29 minutes

Immediate Values

0 : 91c3ecb45800 -8 min
1 : a083ed845800 -7 min
2 : 9fc3ed685800 -6 min
3 : 9c03ee509800 -5 min
4 : 9b43ee389800 -4 min
5 : 9b83ee209800 -3 min
6 : 9c03ef089800 -2 min
7 : 9e03eff09700 -1 min
8 : 8d83e7701a80 <<now>>
9 : 9643e8305a00 -15 min
10 : 9743e9ec5900 -14 min
11 : 9903eaac5900 -13 min
12 : 96c3ea745900 -12 min
13 : 9383eb3c5900 -11 min
14 : 9243ec0c5900 -10 min
15 : 8f83ece09800 -9 min

Historical Values

0 : 84c3eafc5800 -75 min
1 : 85c3e97c5900 -60 min
2 : 7003e9e85900 -45 min
3 : 7683e8205a00 -30 min
4 : 9543e9ec5900 -15 min
5 : 1b44e7201b80 <<last>>
6 : 7a04e7241b80 -465 min
7 : 7104e7341b80 -450 min
8 : 2204e73c1b80 -435 min
9 : f1c3e62c1b80 -420 min
10 : e7c3e9485a00 -405 min
11 : df83e8985a00 -390 min
12 : d403e8bc5a00 -375 min
13 : c143e6741b80 -360 min
14 : 5503e8ec5a00 -345 min
15 : 2c43e6ac1b80 -330 min
16 : 2703e95c5a00 -315 min
17 : 43c3e8385a00 -300 min
18 : 7cc3ec009900 -285 min
19 : 8683ee389800 -270 min
20 : a3c3efc89700 -255 min
21 : b6c3f0449700 -240 min
22 : ca03f2b4d600 -225 min
23 : f983f330d600 -210 min
24 : 1704f4fcd500 -195 min
25 : be43f4c4d500 -180 min
26 : 99c3f49cd500 -165 min
27 : e003f580d500 -150 min
28 : d283ed789700 -135 min
29 : c803ec505800 -120 min
30 : 9083eb805800 -105 min
31 : 9a03ebcc5800 -90 min

This being said, extending the sensor never was my goal and I definitely can't complain about its stickiness or performance during those 14 days.

No comments:

Post a Comment