Foreword: I know that I said I wouldn’t put reverse engineering projects as part of the Monday schedule, but I find myself having an unbalance between the two set of posts, and I wanted to get this out sooner rather than later, in the hope someone else can make progress.
You may remember I have been working on the FreeStyle Libre 2 encrypted communication protocol for a few months. I have actually taken a break from my Ghidra deep dive while I tried sorting my future out – and failing, thanks to the lockdown – but I got back to this a couple of weeks ago, since my art project completed, and I wanted to see if sleeping it over a bit meant getting a clearer view of it.
Unfortunately, I don’t think I’m any closer to figuring out how to speak to Libre 2 readers. I did manage to find some more information about the protocol, including renaming one of the commands to match the debug logs in the application. I do have some more information about the encoding though, which I thought I would share with the world, hoping it will help the next person trying to get more details on this — and hoping that they would share it with the world as well.
While I don’t have a final answer on what encryption they use on the Libre 2, I do have at least some visualization of what’s going on in the exchange sequence.
There’s 15 bytes sent from the Libre 2 reader to the software. The first eight are the challenge, while the other seven look like a nonce of some kind, possibly an initialization vector, which is used in the encryption phase only.
To build the challenge response, another eight bytes are filled with random returned by CryptGenRandom, which is a fairly low level, and deprecated, API. This is curious, given that the software itself is using Qt for the UI, but makes more sense when you realise that they use the same exact code in the driver used for uploading to the LibreView service, which is not Qt based. It also likely explains why the encryption is not using the QtCryptography framework at all.
This challenge response is then encrypted with a key — there are two sets of keys: Authorization keys are used only for this challenge phase, and Session keys are used to handle the rest of the communication. Each set includes an Encryption and a MAC key. The Authorization keys are both seeded with just the serial number of the device in ASCII form, and two literal strings, as pictured above: AuthrEnc and AuthrMAC. The session keys’ seeds include a pair of 8-bytes values as provided by the device after the authorization completes.
The encryption used is either a streaming cipher or a 64-bit block cipher. I know that, because I have multiple captures from the same device in which the challenge started with the same 8 bytes (probably because it lacked enough entropy to be properly random at initialization time), and they encrypted to exactly the same output bytes. Since the cleartext adds a random component, if it was a 128-bit block cipher, you would expect different ciphertext in the output — which kind of defeats the purpose of those 8 random bytes I guess?
The encrypted challenge response is then embedded in the response message, which includes four constant bytes (they define the message type, the length, and the subcommand, plus an extra constant byte thrown in), and then processed by the MAC algorithm (with the Authorization MAC key) to produce a 64-bit MAC, that is tackled at the end of the message. Then the whole thing is sent to the device, which will finally start answering.
As far as I can tell, the encryption algorithm is the same for Authorization and Session — with the exception of the different seed to the key generation. It also includes a different way to pass a nonce — the session encryption includes a sequence number, on both the device and the software, which is sent in clear text and fed into the encryption (shifted left by 18 bits, don’t ask me!) In addition to the sequence number, the encrypted packets have an unencrypted MAC. This is 4 bytes, but it’s actually done with the same algorithm as the authorization. The remaining 4 bytes are just dropped on the floor.
There’s a lot more that I need to figure out in the code, because not knowing anything about cryptography (and also not being that good with Ghidra). I know that the key generation and the encryption/decryption functions are parameterized with an algorithm value, which likely corresponds to an enum from the library they used. And that the parameterized functions dispatch via 21 objects (but likely not C++ objects, as they don’t seem to use vtables!), which can either point at a common function that returns an error (pretty much “not implemented”) or to an actual, implemented function — the functions check something: the enum in the case of key creation (which is, by the way, always 9), or some attribute of the object passed in for encryption and decryption.
These are clearly coming from a library linked in statically — I can tell because the code style for these is totally different from any other part of Abbott’s code, and makes otherwise no sense. It also is possibly meant to be obfuscated, or at least made it difficult — it’s not the same object out of the 21 that can answer the encrypt/decrypt function for the object, which makes it difficult to find which code is actually being executed.
I think at this point, the thing that is protecting their Libre 2 protocol the most is just the sheer amount of different styles of code in the binary: Qt, C++ with STL, C++ with C-style arrays, Windows APIs, this strange library, …
By the way, one thing thatmost likely would help with figuring this out would be if we could feed selected command streams into the software. While devices such as the Facedancer can help, given that most of this work is done in virtual machines, I would rather have my old idea implemented. I might look for time to work on this if I can’t find anyone interested, but if you find that this is an useful idea, I would much prefer being involved but not leading its implementation. Honestly, if I had more resources available, I would probably just pay someone to implement it, rather than buy a hardware Facedancer.
You may remember I complained about cloud-based solutions before. I have had harsh words about what are to me irresponsible self-hosting suggestions, and I’m not particularly impressed by how every other glucometer manufacturer appears to want their tools to be used, uploading to their cloud solutions what I would expect is a trove of real-world blood sugar reports from diabetics.
But as it happens, since I’m using the FreeStyle LibreLink app on my phone, I get the data uploaded to Abbott’s LibreView anyway. The LibreView service is geo-restricted, so it might not be available in all the countries where FreeStyle Libre is present, which probably is why the standalone Windows app still exists, and why the Libre 2 does not appear to be supported by it.
I haven’t used the service at all until this past month, when I visited the diabetic nurse at the local hospital (I had some blood sugar control issues), and she asked me to connect with their clinic. Turns out that (with the correct authorization), the staff at the clinic can access the real-time monitoring that I get from the phone. Given that this is useful to me, I find this neat, rather than creepy. Also it seems to require authorization on both sides, and it includes an email notification, so possibly they didn’t do that bad of a job with it.
The site is also a good replacement for the desktop app, when using the app with the phone, rather than the reader. It provides the same level of details in the reports, including the “pattern insights”, and a full view of the day-to-day aligned on weeks. Generally, those reports are very useful. And they are available on the site even for yourself, not just for the clinics, which is nice.
Also it turns out that the app tracks how many phones you’ve been using to scan the sensor — in my case, six. Although it’s over 1⅓ years since I have used a different one. I couldn’t see a way to remove the old phones, but at the same time, they are not reporting anything in and they don’t seem to have a limit on how many you can have.
Overall it’s effectively just a web app version of the information that was already available on the phone (but hard to extract and share) or on the reader (if you are still using that). I like the interface and it seems fairly friendly.
Also, you may remember (or notice, if you read the links above) that I had taken an aside pointing out how Diabetes Ireland misunderstood the graphs shown in the report when the Libre reached Ireland. I guess they were not alone, because in this version of the report Abbott explicitly labels the 10th-90th percentile highlight, the 25th-75th percentile highlight, and the median line. Of course this assumes that whoever is reading the graph is aware of “percentile” and “median” stand for — but that’s at least a huge step in the right direction.
A few people today messaged and mentioned me on twitter regarding the news that Abbott has requested the takedown of something related to their Libre 2. I gave a quick hot take on this on Twitter, but I guess it’s worth having something in long form to be referenced, since I’m sure this will be talked about a lot more, not least because of the ominous permalink chosen by Boing Boing (“they-literally-own-you”) and the fact that, game of telephone style, the news went from the original takedown, to Reddit phrasing it as “Abbott asserts copyright on your data”, which is both silly and untrue.
So let’s start with a bit of background, that most of the re-posters of this story probably don’t know much about. The Libre 2 is an upgrade on the FreeStyle Libre system that I wrote a lot about and that I use daily. It comes with both a reader device and with support in the LibreLink app for both Android and (on more recent iPhones) iOS. The main difference with the Libre system is that the sensors provide both NFC and BLE capabilities, with the ability to proactively notify of high- or low-blood sugar conditions, that the old NFC-only sensors cannot provide, which is more similar to CGM solutions like Dexcom‘s.
In both the Libre and Libre 2 systems, the sensors don’t report blood sugar values, like in most classic glucometers. Instead they report a number of “raw” values, including from a number of temperature sensors. There’s a great explanation of these from Pierre Vandevenne, here and here. To get a real blood sugar measurement, you need to apply some algorithm, that Abbott still refines. The algorithm is what I usually refer to as “secret sauce”, and is implemented in both the reader’s firmware and the LibreLink app itself.
Above I used the word “something” to refer to what was taken down. The reason why I say that is that Boing Boing in the title straight up calls this a “tool” — but when you read the linked post from the affected person, it is described as “details of how to patch the LibreLink app”. Since I have not seen what the repository was before it was taken down, I have no idea which one to believe exactly. In either case, it looks like Abbott does not like someone to effectively leverage their “secret sauce” to use in a different application, but in particular, it does not look like we’re talking about something like glucometerutils, that implemented the protocol “clean”, without derivation off the original software.
Indeed, Boing Boing seems to make a case that this is equivalent of implementing a file format: «[…] just because Apple’s Pages can read Word docs, it doesn’t mean that Pages is a derivative of MS Office.» Except that it’s not as clear cut. If you implemented support for one format by copying the implementation code into your software, that actually would make it a derivative work, quite obviously. In this case, if I am to believe the original report instead, the taken down content were instructions to modify Abbott’s app — and not a redistribution of it. Since I’m not a lawyer, I have no idea where that stands, but it’s clearly not as black-and-white as Boing Boing appears to make it.
As I said on twitter, this does not affect either of my projects, since neither is relying on the original software, and are rather descriptions of the protocols. They also don’t include any information or support for the Libre 2, since the protocol appears to have changed. There’s an open issue with discussion, but it also appears that this time Abbott is using some encryption on the protocol. And that might be an interesting problem, as someone might have to get up close and personal with the code to figure that part out — but if that’s the case, we’re back at needing a clean-room design for implementing it.
I also want to quote Pierre explicitly from the posts I linked above:
[…] in the Libre FRAM, what we are seeing is a real “raw” signal. While the measure of the glucose signal itself is fairly reliable, it is heavily post-processed by the Libre firmware. Specifically – and in no particular order – temperature compensation, delay compensation, de-noising… all play a role. That understanding and, to some extent, my MD training, led me to extreme caution and prevented me from releasing my “solution”, which I knew to be both incomplete and unable to handle some error conditions.
The main driver behind my decision was the well known “first do no harm” (primum non nocere) motto, an essential part of the Hippocratic Oath which I symbolically took. I still stick by it today. […]
[…]
Today, there are a lot of add-on devices that aim to transform the Libre into a full CGM. To be honest, in general, I do not like either the results they provide or their (in)convenience. None of those I have tried delivered results that would lead to an approval by a regulatory agency, none of them were stable for long periods of time. But, apparently, patients still feel they are helpful and there is now a thriving community that aims at improving them.
While I have not sworn a Hippocratic Oath myself, I have similar concerns to Pierre, and I have explicitly avoided documenting the sensors’ protocol, and I won’t be merging code that tries to read them directly, even if provided.
And when it comes to copyright issues, I do weigh them fairly heavily: they are the fundamental way that Free Software even works, by respecting licenses. So I will prefer someone to provide me with the description of Abbott’s encryption protocol, rather than an implementation of it where I may be afraid of a “poisonous tree.”
The last time I wrote anything interesting about Abbott’s flash glucose monitor (don’t call it a CGM) was when I compared it with the underwhelming Dexcom G6. I thought it would be a good time to provide an update, what with Abbott sending a number of email reminding you to update their FreeStyle LibreLink app in the past couple of weeks.
First of all, there’s the matter of supplies. Back in January, I decided to test Dexcom’s CGM because Abbott’s supply issues bit me in the backside, as I could not get new sensors to keep up with my usage — particularly as the more active life in London with my girlfriend meant losing a couple more sensors to mistakes, such as bumping into the doorframe. For a while, you could only buy three sensors every 25 days, and even then, sometimes the lead time to fulfill the order would be over a week; nowadays this appears to be much better, and the time limit for the orders was removed recently.
Since I was not particularly thrilled to switch to the Dexcom G6, I had to find a way around these limits, beside counting on the two extra sensors I “gained” by not using the Libre for a month. Luck was that a friend of my girlfriend found the Libre sensors on sale in a brick-and-mortar store in Sharjah, and managed to send me six of them. The store had no limits on how many sensors you could buy, despite the FreeStyle UK website only allowing orders of three at most, and only to already-established customers.
The UAE-bought sensors are effectively the same as the British ones, with the same manufacturing information printed on them, and even similar enough lot numbers. The most visible difference is that the two alcohol-soaked tissues, provided for cleaning the insertion point, are missing.
The other difference is not visible in the packaging, or indeed on the hardware itself: the sensors are region-locked. Or maybe we should say that the app is. As it is, my (UK) FreeStyle LibreLink install did not want to set up the UAE-bought sensors. The reader device had no such concern and both initialised and read them just fine. I was originally a bit concerned and spot-checked the values with fingersticks, but it looked like there was no issue with the sensors at all.
I’ve been wondering just how much the supply problem connects with the region locking. Or just how fine-grained the region locking is: my Irish sensors worked perfectly fine with the UK app, although by that point, the app was not available in Ireland at all. But possibly all of these problems are gone.
Now, to go back to Abbott’s email messages to update their LibreLink app. The reason for this update is not much about the UI of the app itself – although that did change a bit, in subtle and annoying ways – but rather a change in their algorithm for turning the sensors’ readings into a human-understandable blood glucose reading. The “curve”, as it’s sometimes referred to. It’s important to note that what the sensors communicate with either the app or the reader device are not “fully cooked” blood sugar readings, but rather a set of different sensors reading, and that the app and reader will then apply some formulas to provide an equivalent reading to a fingerstick.
Much more interesting to me, in the announcement of the new curve, is that they also suggest users to update the firmware of reader devices to make use of the new fine-tuned algorithm. This is interesting because it makes the FreeStyle Libre the first glucometer with an upgradeable firmware. I have not actually run the update myself, yet. It needs to be done just before changing the sensor, as the reader will forget about its last sensor at that point, and I’m a bit worried that it might not work with UAE-bought sensors anymore after that. So I’m instead waiting to finish the supply of those sensors, and maybe get another one later to test after the update.
I also want to try to get a usbmon trace of the whole procedure for the firmware update. I’m not sure when Abbott will ever publish another update for the reader, but at least starting collecting the protocol would be interesting. Once I do that, you can expect another blog post on the topic.
And as a final note, glucomterutils is being updated as I type this to support reading and setting patient names. While I would not suggest people to use that field for their own personal glucometer, I thought it would be nice to provide the building block for more doctor-focused apps to be built out of it. As a reminder, the code is released under the MIT license, because using it to build something else is a primary focus of it — we need better tooling for glucometers, and not just in the Free Software world, but in the world in general!
During my December trip to the United States, I did what I almost always do when I go there: I went to a pharmacy and looked through the current models of glucometers that are for sale there. Part of the reason is that I just got to the point I enjoy a challenge of figuring out what difference in the protocol the various manufacturers put version after version, and part of it is that I think it is a kind of a public service that we provide tools not only for the nice and fancy meters but also for those that most people would end up buying in store. I have one more device that I got during one of my various trips that I have not written about, too, but let’s not go there.
This time around the device I got is an Abbott FreeStyle Precision Neo device. The factors I used to choose, as usual, were price (I didn’t want to spend much, this one was on sale for less than $10), and the ability to download the data over direct USB connection (the device I have noted above requires a custom cradle which I have not managed to acquire yet). In addition, while the device did not come with any strip at all, I (mistakenly) thought it was a US brand for the Optium Neo, which looks very similar and is sold in Europe and Canada. That meter I knew used the same strips that I use for the FreeStyle Libre, which means I wouldn’t have to pay extra for it at all. As I said I was wrong, but it still accepted the same strips, more on that later.
The device itself is fairly nice: at first it may appear to share a similar shape as the Libre, but it really seems to share nothing with it. It’s significantly flatter, although a bit wider. The display is not LCD at all, but rather appears to be e-ink and reminded me of the Motorola FONE. The display is technically a “touchscreen” but rather than having a resistive or capacitive display on the device, it appears to just have switches hidden behind the screen.
Given the minimal size of the device, there is not much space for a battery and charging circuitry, like there is in the Libre, instead the device is powered by a single CR2032 battery which is very nice as they are cheap enough, and easy to carry around, although you’re not meant to leave them in checked-in luggage.
Overall, the device is flatter than my current smartphones, and extremely light, and that gives it a significant advantage over a number of other meters I tried in the past few years. The e-ink display ha very big and easily readable numbers, so it’s ideal for the elderly or those who need to take the test even without their glasses.
Putting aside the physical size factor, the package I bought contained a small case for the meter, a new lancing device, and some lancets. No strips, and I guess that explains the very low price point. I would say that it’s the perfect package for the users of previous generations’ FreeStyle devices that need an upgrade.
As I said at the start, the main reason why I buy these devices is that I want to reverse engineer their protocol, so of course I decided to find the original software from Abbott to download the data out of it. Unfortunately it didn’t quite work the way I was expecting. I expected the device to be a rebranded version of the Optium Neo, but it isn’t. So the software from the Irish Abbott website (Auto-Assist Neo, v1.22) tried connecting to the meter but reported a failure. So did the same software downloaded from the Canadian website (v1.32).
Given that this is a US device, I went to the US website (again, thank you to TunnelBear as Abbott keeps insisting with the GeoIP-locking). The US version does not offer a download of the simple desktop software I was looking for, instead pointing you to the client for their online diabetes management software. What is it with online systems for health data access? I decided not to try that one, particularly as I would be afraid of its interaction with the FreeStyle Libre software. I really should just set up a number of virtual machines, particularly given that the computer I’m using for this appears to be dying.
On the bright side it appears that, even though the software declares the device is not compatible with it, the USB capture shows that all the commands are all being sent and responded to, so I have a clear trace for at least the data download. The protocol is almost identical to the Insulinx that Xavier already reverse engineered in parts, and both seem to match the basic format that Pascal found how to dump from the Libre so it was easy to implement. I’ll write more about that separately.
So what about the strips? Since the device came with no strips, I assumed I would just use the strips I had at home, which were bought for my Libre device and were of the Optimus series, and they worked fine. But when I looked into completing the reverse engineering of the protocol by figuring out which marking is used for the β-ketone readings, the device reported E-2 on the screen. So I looked into it and I found out that the Precision Neo device is meant to be used with Precision series strips. Somehow the Optimus blood glucose strips are compatible (I would guess they are effectively the same strips) while the β-ketone strips are not. So I still don’t have data of how those readings are reported. But this put a final nail in the coffin to the idea that this is the same device as the one sold outside of the USA.
Having this device was very useful to understand and document better the shared HID protocol that is used by Abbott FreeStyle devices, which made it very easy to implement the basic info and data dump from the Libre, as well as an untested InsuLinux driver, in my glucometerutils project. So I would say it was $10 spent well.
In the comments to my review of the Android LibreLink app, I pointed out to Daniel that (much as I don’t particularly like the “blogger” label), I’m not a diabetes blogger, I’m a tech blogger who suffer from diabetes, and for that reason most of the stuff I posted about it has to do with the technical sides (after all the original set of posts were titled “Diabetes control and its tech”.)
I have, though, to excuse myself for once and write a little bit about lifestyle, but probably not from the same point of view that other bloggers might take in their writing, mostly due to style and interest. But I did say I would talk a little more to how the FreeStyle Libre changed my behaviour since I started using it in January this year (some ten months and something sooner than it was available in the country I live in.)
The Libre, unlike other CGM solutions, is not a real-time solution: it uses interstitial fluids for measurement, and because of that they provide warnings about time-delay, and quick changes in blood sugar; they don’t provide that much specifics, but I noticed something along the lines of 20 minutes delay after eating for the blood sugar to push back up, and what to me looks like “smoothing” of the graph, so that sudden changes in blood sugar are not noticeable. This is also due to the sampling rate (one reading once 15 minutes.)
So while it is not a perfect solution, particularly if you’re relying on it for taking fast insulin, it makes for a good learning experience. By looking at a graph after the fact, while the damage is already done, you can at least know what to repeat and what to avoid. If you want to be buzzword-y you can define it as human deep learning.
What I found is nothing particularly new or exciting, particularly for experts of diabetes, but it did help me understanding to what extend blood sugar can sway based on activity. I wanted to at least talk about some of the experiences I had over the past few months, just for sharing. It might or might not be of help to others, but at least I can show what kind of useful lessons can be learnt with solutions like the Libre.
Some months ago I went to IKEA to buy some furniture for my apartment in Dublin, namely a cupboard, and a new sofa (the one I had before turned out to be moldy from before I moved in, so I asked my landlords to please allow me to change it.) I received them on a Saturday very early (for me) morning: 8am. I had to wake up at 7.25am and have breakfast, I had a significant breakfast, which as usual involves lots of coffee. The delivery men brought the boxes inside and took the old sofa out, but the rest was up to me. I started with the sofa, and by 11am I had it done. I had to stop midway through to eat a packet of chocolate biscuits because I felt a bit dizzy and I found that I was going low on sugar quite quickly, even though it did go over the 10 mmol/l limit after breakfast. I had another “heavy” lunch (as in, more than double my usual amount of pasta) because I was still on the lower-side of the range, and I had one more piece of furniture to build. I had to stop by 2pm again to eat some ice-cream because I was below the 4mmol/l already. Over the course of the next two days, no matter how much I’d eat: pasta, ice-cream and biscuits, I didn’t go over 9 mmol/l at all.
What does that tell me? It’s clearly not bollocks when they say that physical activity helps a lot with diabetes; assembling IKEA furniture is clearly not a sport, but it worked effectively the same way. I’m still a lazy bum and have not done any sports, part of it because I feel horribly out of place in a gym, though I did enjoy bouldering with colleagues before, I should try that again. To be honest, this was not entirely new to me either; not only I did notice that even the WiiFit exercises used to help me lower my blood sugar much quicker, back in Italy when I was not on insulin nor under a solution like the Libre, but when a couple of years ago I ended up taking the 23andMe test, one of their reports had interesting information that was actually relevant to me:
Insulin sensitivity response to exercise: Exercise is associated with a 2% improvement in insulin sensitivity, on average.
Teran-Garcia M et al. (2005) . “Hepatic lipase gene variant -514C>T is associated with lipoprotein and insulin sensitivity response to regular exercise: the HERITAGE Family Study.” Diabetes 54(7):2251-5.
Improvement in glucose tolerance with regular exercise: Glucose tolerance improved with regular exercise.
Ruchat SM et al. (2010) . “Improvements in glucose homeostasis in response to regular exercise are influenced by the PPARG Pro12Ala variant: results from the HERITAGE Family Study.” Diabetologia 53(4):679-89.
Correlation does not imply causation, but these information correlate with my personal anecdotes, take it with as much salt as you want.
Speaking of correlation, and (as you’ll see) of 23andMe. I’m sure we all have wondered at some point if the drugs prescribed by our doctors actually help, or if they rely almost exclusively on placebo effect. Well, I unwittingly went through that experiment, by forgetting my meds a couple of times — anybody who’s on any kind of daily meds would tell you that even though it’s bad, it’s not always easy or obvious to keep your meds routine straight and never forget any, I can tell you that while travelling across timezones, it’s even harder. Since I’m on both insulin detemir and gliclazide I have at some point forgot one, the other, or (much more rarely) both. And I did find something interesting: I can much more easily notice by the graph the days in which I forgot the gliclazide than those in which I missed insulin. Missing insulin looks a lot like eating too much, particularly for breakfast. Missing gliclazide looks like the Y axis got transposed so the values read at least +3 overall, if not more. You can imagine that after I did make a mental note of that I paid much more attention to the pills than the injection, in the morning (it’s easy to do the opposite, since the injection requires more minding.)
Sulfonylurea Metabolism: Somewhat reduced ability to clear sulfonylurea drugs from the body.
(This one has way too many references to easily cite them all, but it looks legit, my doctor was also interested to learn more about 23andMe after I sent him the printed report about this one.)
Staying with the list of don’ts, let me tell you about dessert. It would be easy to just say that diabetics should stay away from desserts at all time, but that is not true, as anybody with a bit of direct or indirect experience on the matter would know. Among other things, even though my friend the dietician gets upset when I do that, I have explicitly limited to a light lunch to be able to get a tasty and sugary dessert. This is not good of course and so I really do that rarely.
On the other hand, even with a normal lunch or dinner, I have started finding which configurations of meal could allow me to have a dessert and which does not. Turns out, what you ear is far from the only variable either. When you eat is also a factor, so for the same dessert I can have it for lunch, as long as I do my half hour walk home, but if I have it for dinner, even though I walk home, it spikes my blood sugar so high that I was seriously worried about my life.
All in all, the lessons I can learn from this device are still plenty, but it also means I am learning to look after myself a lot more than I was doing before, with significant less effort. It makes me happy, so I’ll be happy to continue paying for this if HSE is not to cover them (which is still unclear to me.)
This was not a surprise to everybody; indeed I was pointed at a website (which I refuse to link) of Nightscouters (self-proclaimed people who “are not waiting”), which in turn pointed to an unofficial Android app that is able to read that data. The app is unsafe though (thus the lack of links), as it does not wait the first hour to get a reading, and allows to keep reading the sensor after the two weeks provided by the manufacturer. Their excuse is that you should be able to get the data and judge by yourself; I don’t like that answer, particularly as the raw readings need to be normalized by the Abbott reading device for it to have a valid reading.
Indeed, the various groups I see proclaiming “they are not waiting”, are vastly interested in the idea of quantified self, rather than having an actual health need for this data. They would be harmless, if they didn’t suggest using similarly risky methods to gain information that could be used to make medical decision. But this is a topic for another time.
Instead, a few months ago, Abbott themselves sent out an email to the register users that they made an official Android app available. Called LibreLink, and developed by a company identified as AirStrip Technologies based in San Antonio, Texas, this app is able to initialize and read a FreeStyle Libre sensor from an NFC-capable Android phone. It can be used to either replace the original Abbott reader device, or in addition to it.
I have tried it as soon as I could, which meant not right as I received the mail: the app is only able to read a sensor that it either initialize by itself, or one that was scanned during the one hour window in which the readings are not available. I suppose this has something to do with the pseudo-calibration that the FreeStyle Libre system provides.
Having the ability to take my readings from the phone turned out to be a good thing. While I would still try to keep the readings on the official device, which allows downloading them to a computer, and provides a full PDF I can send my doctor with the history, it allowed me to forget my reader at home for a day, and not having to worry, or being able to take a reading during a meeting in which I did not think to take the reader with me. It also provides more information than the reader itself, including what Abbott calls the Ambulatory Glucose Profile (AGP), which ends up being a graph of 10-90 percentiles, 25-75 percentiles, and median.
Aside: turns out that getting used to read percentile graphs, which is something my dayjob trained me to do, made it much more obvious to me what the AGP graphs were; I had to correct the Diabetes Ireland website, that listed it as a set of superimposed graphs. It took me a good half-hour to realize that it was just obvious to me due to my work, which is totally unrelated to health-care, but it would not be so to a doctor who has not seen that kind of monitoring before. Cross-discipline information exchange is good.
Unfortunately, it seems like the app likes to share data with its developers. This makes sense to a point: science is progressing, and they want to know how exactly it makes your life different, does it make it easier to keep your sugar within limits? Does it make it more likely to get sugar-lows, rather than highs? These are all good questions. I have not tried investigating (yet) whether the app shares this data over a properly encrypted channel or if it’s an actual privacy risk. I might better not know, since it does scare me a bit, but I guess I should do that at some point.
Again as an aside, I did get myself an Android phone capable of NFC, for the sole reason of being able to use that app while inspecting its traffic. The phone I used previously for that is my corporate phone, so I would not be able to fiddle with the traffic dumping on it. But I guess I’ll have to find more time for that, nowadays.
While I have been happy that the app was around, it was not perfect either. In particular I have a bad feeling that it might have something to do with two sensors failing on me with an error I did not see in the eight months before the app was introduced. I have made the mistake of not contacting Abbott right away about them, which meant I thrown them out without sending them for inspection, I have since realized my mistake but could not risk causing more failures until about this month, since I’ve been traveling a bit, and it takes me about a week or two to get new sensors in Dublin.
The reason why I suspect this is related to the app is not just that I didn’t get those kind of errors before I started using it, but also because I had read of similar failures happening when using the unofficial app suggested by Nightscouters, though in that case it’s said to be dependent on the NFC chip used by the cellphone. The two things together made me suspicious.
I’m actually told (by both my doctor and Diabetes Ireland) that Abbott is meant to start selling the device (and sensors) in Ireland before next month. Right now they do have an Irish website, which is more than they had when I started looking into it. I do not know as of yet, whether my long-term illness coverage includes these sensors or if I’ll have to keep paying for them myself (at least the falling Sterling is helping), but either way it’s going to be simpler to procure them if one of them fails.
As a final note, I should probably write down my own impressions when the sensor failed, compared to the article Daniel pointed me at back when I posted about my experimentation with this CGM (pardon, flash glucose monitoring system.) Although the first time this happened, it was not due to the mobile app; instead the application packet for the sensor failed, and I “primed” a sensor without a needle.
This happened when I was in Lisbon on vacation, and I only noticed after the hour passed, and I was queuing up for a train ticket to Cascais. I’ll admit it: I started panicking. I did not plan for it and I did not want to be out and about alone without the sensor. Part of the problem was to be found in me not having the normal glucometer with me, so having absolutely no way to make sure I was okay. The panic probably would have limited itself had I managed to get a ticket in less than twenty minutes. At the end I gave up when I got to the machine and it refused to accept either my cash (too wrinkly) or my card (too foreign.) So I turned around, went back to the hotel and put a new sensor (yes I traveled with a spare.)
Would I have panicked like in the linked article? Maybe, but I would like to think not. When the sensor actually failed me at home, this time indeed possibly due to the app, I didn’t have a spare sensor at home, and that made me angry. But at the same time, I knew it was not that important, I lived without it before, and I can live without it now, it’s just more inconvenient. What I did was putting a new cassette into the Accu-Chek which is significantly nicer to bring around than the kit for the Libre-as-glucometer, and ordered more sensors. I ended up staying a week without the Libre; it bothered me but I didn’t change much of my habits: the Libre trained me on how to relate my sensory experience with blood sugar, and what I can and cannot eat when, so I felt fairly safe overall.
If you’re here looking for information on the FreeStyle Libre 2, please see this other series of posts, and this issue on GitHub. Reverse engineering is proceeding slowly, and collaboration is key.
I have already reviewed the Abbott FreeStyle Libre continuous glucose monitor, and I have hinted that I already started reverse engineering the protocol it uses to communicate with the (Windows) software. I should also point out that for once the software does provide significant value, as they seem to have spent more effort in the data analysis than any other part of it.
Please note that this is just a first part for this device. Unlike the previous blog posts, I have not managed yet to get even partial information downloaded with my script as I write and post this. Indeed, if you, as you read this, have any suggestion of things I have not tried yet, please do let me know.
Since at this point it’s getting common, I’ve started up the sniffer, and sniffed starting from the first transaction. As it is to be expected, the amount of data in these transactions is significantly higher than that of the other glucometers. Even if you were taking seven blood samples a day for months with one of the other glucometers, it’s going to take a much longer time to get the same amount of readings as this sensor, which takes 96 readings a day by itself, plus the spot-checks and added notes and information to comment them.
The device itself presents itself as a standard HID device, which is a welcome change from the craziness of SCSI-based hidden message protocols. The messages within are of course not defined in any standard of course, so inspecting them become interesting.
It took me a while to figure out what the data that the software was already decoding for me meant. At first I thought I would have to use magic constant and libusb to speak raw USB to the device — indeed, a quick glance around Xavier’s work showed me that there were plenty of similarities, and he’s including quite a few magical constants in that code. Luckily for me, after managing to query the device with python-libusb1, which was quite awkward as I also had to fix it to work, I realized that I was essentially reimplementing hidraw access.
After rewriting the code to use /dev/hidraw1 (which makes it significantly simpler), I also managed to understand that the device uses exactly the same initialization procedure as the FreeStyle InsuLinx that Xavier already implemented, and similar but not identical command handling (some of the commands match, and some even match the Optium, at least in format.)
Indeed the device seem to respond to two general classes of commands: text-commands and binary commands, the first device I reverse engineer with such a hybrid protocol. Text commands also have the same checksumming as both the Optium and Neo protocols.
The messages are always transferred in 64-bytes packets, even though the second byte of the message declares the actual significant length, which can be even zero. Neither the software nor the device zero out their buffers before writing the new command/response packets, so there is lots of noise in those packets.
I’ve decided that the custom message framing and its usage of HID is significant enough to warrant being documented by itself so I did that for now, although I have not managed to complete the reverse engineering of the protocol.
The remaining of the protocol kept baffling me. Some of the commands appear to include a checksum, and are ignored if they are not sent correctly. Others actually seem to append to an error buffer that you can somehow access (but probably more by mistake than design) and in at least one case I managed to “crash” the device, which asked me to turn it off and on again. I have thus decided to stop trying to send random messages to it for a while.
I have not been pouring time on this as much as I was considering doing before, what with falling for a bad flu, being oncall, and having visitors in town, so I have only been looking at traces from time to time, particularly recording all of them as I downloaded more data out of it. What still confuses me is that the commands sent from the software are not constant across different calls, but I couldn’t really make much heads or tails of it.
Then yesterday I caught a break — I really wanted to figure out at least if it was encoding or compressing the data, so I started looking for at least a sequence of numbers, by transcribing the device’s logbook into hexadecimal and looking in the traces for them.
This is not as easy as it might sound, because I have a British device — in UK, Ireland and Australia the measure of blood sugar is given in mmol/l rather than the much more common mg/dl. There is a stable conversion between the two units (you multiply the former by 18 to get the latter), but this conversion usually happens on display. All the devices I have used up to now have been storing and sending over the wire values in mg/dl and only converted when the data is shown, usually by providing some value within the protocol to specify that the device is set to use a given unit measure. Because of this conversion issue, and the fact that I only had access to the values mmol/l, I usually had two different options for each of the readings, as I wasn’t sure how the rounding happened.
The break happened when I was going through the software’s interface, trying to get the latest report data to at least match the reading timing difference, so that I could look for what might appear like a timestamp in the transcript. Instead, I found the “Export” function. The exported file is a comma-separated values file, which includes all readings, including those by the sensor, rather than just the spot-checks I could see from the device interface and in the export report. Not only that, but it includes a “reading ID”, which was interesting because it started from a value a bit over 32000, and is not always sequential. This was lucky.
I imported the CSV to Google Sheets, then added columns next to the ID and glucose readings. The latter were multiplied by 18 to get the value in mg/dl (yes the export feature still uses mmol/l, I think it might be some certification requirement), and then convert the whole lot to hexadecimal (hint: Google Sheets and LibreOffice have a DEC2HEX function that do that for you.) Now I had something interesting to search for: the IDs.
Now, I have to point out that the output I have from USBlyzer is a CSV file that includes the hexdump of the USB packets that are being exchanged. I already started writing a set of utilities (too rough to be published though) to convert those into a set of binary files (easier to bgrep or binwalk them) or hexdump-like transcripts (easier to recognize strings.) I wrote both a general “full USB transcript” script as well as a “Verio-specific USB transcript” while I was working on my OneTouch meter, so I wrote one for the Abbott protocol, too.
Because of the way that works, of course, it is not completely obvious if any value which is not a single byte is present, by looking at the text transcript, as it might be found on the message boundary. One would think they wouldn’t, since that means there are odd-sized records, but indeed that is the case for this device at least. Indeed it took me a few tries of IDs found in the CSV file to find one in the USB transcript.
And even after finding one the question was to figure out the record format. What I have done in the past when doing binary format reverse engineering was to print on a piece of paper a dump of the binary I’m looking at, and start doodling on it trying to mark similar parts of the message. I don’t have a printer in Dublin, so I decided to do a paperless version of the same, by taking a screenshot of a fragment of transcript, and loading it into a drawing app on my tablet. It’s not quite as easy, but it does making sharing results easier and thanks to layers it’s even easier to try and fail.
I made a mistake with the screenshot by not keeping the command this was a reply to in the picture — this will become more relevant later. Because of the size limit in the HID-based framing protocol Abbott uses, many commands reply with more than one message – although I have not understood yet how it signals a continuation – so in this case the three messages (separated by a white line) are in response to a single command (which by the way is neither the first or the last in a long series.)
The first thing I wanted to identify in the response was all the reading IDs, the one I searched for is marked in black in the screenshot, the others are marked in the same green tone. As you can see they are not (all) sequential; the values are written down as little-endian by the way. The next step was to figure out the reading values, which are marked in pink in the image. While the image itself has no value that is higher than 255, thus using more than bytes to represent them, not only it “looked fair” to assume little endian. It was also easy to confirm as (as noted in my review) I did have a flu while wearing the sensor, so by filtering for readings over 14 mmol/L I was able to find an example of a 16-bit reading.
The next thing I noted was the “constant” 0C 80 which might include some flags for the reading, I have not decoded it yet, but it’s an easy way to find most of the other IDs anyway. Following from that, I needed to find an important value, as it could allow decoding many other record types just by being present: the timestamp of the reading. The good thing with timestamps is that they tend to stay similar for a relative long time: the two highest bytes are the same for most of a day, and the highest of those is usually the same for a long while. Unfortunately looking for the hex representation of the Unix timestamp at the time yield nothing, but that was not so surprising, given how I found usage of a “newer” epoch in the Verio device I looked at earlier.
Now, since I have the exported data I know not only the reading ID but also the timestamp it reports it at, which does not include seconds. I also know that since the readings are (usually) taken at 15 minutes intervals, if they are using seconds since a given epoch the numbers should be incrementing by 900 between readings. Knowing this and doing some mental pattern matching it became easy to see where the timestamps have been hiding, they are marked in blue in the image above. I’ll get back to the epoch.
At this point, I still have not figured out where the record starts and ends — from the image it might appear that it starts with the record ID, but remember I took this piece of transcript mid-stream. What I can tell is that the length of the record is not only not a multiple of eight (the bytes in hexdump are grouped by eight) but it is odd, which, by itself, is fairly odd (pun intended.) This can be told by noticing how the colouring crosses the mid-row spacing, for 0c 80, for reading values and timestamps alike.
Even more interesting, not only the records can cross the message boundaries (see record 0x8fe0 for which the 0x004b value is the next message over), but even do the fields. Indeed you can see on the third message the timestamp ends abruptly at the end of the message. This wouldn’t be much of an issue if it wasn’t that it provides us with one more piece of information to decode the stream.
As I said earlier, timestamps change progressively, and in particular reading records shouldn’t usually be more than 900 seconds apart, which means only the lower two bytes change that often. Since the device uses little-endian to encode the numbers, the higher bytes are at the end of the encoded sequence, which means 4B B5 DE needs to terminate with 05, just like CC B8 DE 05 before it. But the next time we encounter 05 is in position nine of the following message, what gives?
The first two bytes of the message, if you checked the protocol description linked earlier, describe the message type (0B) and the number of significant bytes following (out of the usb packet), in this case 3E means the whole rest of the packet is significant. Following that there are six bytes (highlighted turquoise in the image), and here is where things get to be a bit more confusing.
You can actually see how discarding those six bytes from each message now gives us a stream of records that are at least fixed length (except the last one that is truncated, which means the commands are requesting continuous sequences, rather than blocks of records.) Those six bytes now become interesting, together with the inbound command.
The command that was sent just before receiving this response was 0D 04 A5 13 00 00. Once again the first two bytes are only partially relevant (message type 0D, followed by four significant bytes.) But A5 13 is interesting, since the first message of the reply starts with 13 A6, and the next three message increment the second byte each. Indeed, the software follows these with 0D 04 A9 13 00 00, which matches the 13 A9 at the start of the last response message.
What the other four bytes mean is still quite the mystery. My assumption right now is that they are some form of checksum. The reason is to be found in a different set of messages:
In this set of replies, there are two significant differences compared to the ones with record earlier. The first is that while the command lists 5F 13 the replies start with 10 5F, so that not only 13 becomes 10, but 5F is not incremented until the next message, making it unlikely for the two bytes to form a single 16-bit word. The second is that there are at least four messages with identical payload (fifty-six bytes of value zero). And despite the fourth byte of the message changing progressively, the following four bytes are staying the same. This makes me think it’s a checksum we’re talking about, although I can’t for the life of me figure out which at first sight. It’s not CRC32, CRC32c nor Adler32.
By the way, the data in the last message relates to the list of sensors the devices has seen — 9ep.Q.0M00007RK54 is the serial number, and A0 9F DE 05 is the timestamp of it initializing.
Going back to the epoch, which is essentially the last thing I can talk about for now. The numbers above clearly shower in a different range than the UNIX timestamp, which would start with 56 rather than 05. So I used the same method I used for the Verio, and used a fixed, known point in time, got the timestamp from the device and compared with its UNIX timestamp. The answer was 1455392700 — which is 2012-12-31T00:17:00+00:00. It would make perfect sense, if it wasn’t 23 hours and 43 minutes away from a new year…
I guess that is all for now, I’m still trying to figure out how the data is passed around. I’m afraid that what I’m seeing from the software looks like it’s sending whole “preferences” structures that change things at once, which makes it significantly more complicated to understand. It’s also not so easy to tell how the device and software decide the measure unit as I don’t have access to logs of a mg/dl device.
While working on reverse engineering glucometers I decided to give a try to a CGM solution. As far as I know the only solution available in Ireland is Dexcom. A friend of mine already has this, and I’ve seen it, but it felt a bit too bulky for my taste.
Instead, I found out on Twitter about a new solution from Abbott – the same company I wrote plenty before while reverse engineering devices – called FreeStyle Libre. When I first got to their website, though, I found out that the description videos themselves were “not available in my country”. When I went back to check on it, the whole website was not available at all, and instead redirected me to a general website telling me the device is not available in my country.
I won’t spend time here to describe how to work around the geolocking, I’m sure you can figure it out or find the instructions on other websites. Once you work around accessing the website, ordering is also limited to UK addresses for both billing and shipping — these are also fairly easy to work around, particularly when you live in Éire. I can’t blame Abbott for not selling the device in this country (they are not allowed by law) but it would be nice if they didn’t hide the whole website though!
Anyway, I have in some ways (which I won’t specify) worked around the website geolocking and order one of the starter kits back in February. The kit comes with two sensors (each valid for 14 days) and with a reader device which doubles as a normal glucometer.
The sensors come with an applicator that primes them and attaches them to the arm. The applicator is not too difficult to use even with your weak hand, which is a nice feature given that you should be alternating the arm you attach it to. Once you put the sensor on you do feel quite a bit of discomfort but you “get used to it” relatively quickly. I would suggest avoiding the outer-side of the arm though, particularly if you’re clumsy like me and tend to run into walls fairly often — I ended up discarding my second sensor after only a week because I just took it out by virtue of falling.
One of the concerns that I’ve been warned about by a friend, on CGM sensors, is that while the sensor has no problem reading for the specified amount of time, the adhesive does not last that long. This was referred to another make and model (the Dexcom G4) and does not match my experience with the Libre. It might be because the Libre has a wider adhesive surface area, or because it’s smaller and lighter, but I haven’t had much problem with it trying to come away before the 14 days, even with showers and sweat. I would still suggest keeping at hand a roll of bandage tape though, just in case.
The reader device, as I said earlier, doubles as a normal glucometer, as it accepts the usual FreeStyle testing strips, both for blood and for ketone reading, although it does not come with sample strips. I did manage to try blood readings by using one of the sample strips I had from the FreeStyle Optium but I guess I should procure a few more just for the sake of it.
The design of the reading device is inspired by the FreeStyle InsuLinx, with a standard micro-USB port for both data access and charging – I was afraid the time would come that they would put non-replaceable batteries on glucometers! – and a strip-port to be used only for testing (I tried putting the serial port cable but the reader errors out.) It comes with a colourful capacitive touch-screen, from which you can change most (But not all) settings. A couple of things, such as the patient name, can only be changed from the software (available for Windows and OSX.)
The sensor takes a measurement every 15 minutes to draw the historical graph, which is stored for up to eight hours. Plus it takes a separate, instantaneous reading when you scan it. I really wish they put a little more memory in it to keep, say, 12 hours on the device, though. Eight hours is okay during the day if you’re home, but it does mean you shouldn’t forget the device home, when you go to the office (unless you work part-time), and that you might lose some of the data from just after going to sleep if you manage to sleep more than eight hours at a time — lucky you, by the way! I can’t seem to be able to sleep more than six hours.
The scan is at least partially performed over NFC, as my phone can “see” the sensor as a tag, although it doesn’t know what to do with it, of course. I’m not sure if the whole data dumping is done over NFC, but it would make it theoretically possible to get rid of the reader in favour of just using a smartphone then… but that’s a topic for a different time.
The obvious problem with CGM solutions is their accuracy. Since they don’t actually measure blood samples (they do use a needle, but it’s a very small one) but rather interstitial fluid, it is often an open question on whether their readings can be trusted, and the suggestion is to keep measuring normal blood sugar once or twice a day. Which is part of the reason why the reader also doubles as a normal glucometer.
Your mileage here may vary widely, among other things because it varies for me as well! Indeed, I’ve had days in which the Libre sensor and the Accu-Chek Mobile matched perfectly, while the last couple of days (as I’m writing this) the Libre gave a slightly lower reading, between 1 and 2 mmol/l (yes this is the measure used in UK, Ireland and Australia) lower than the Accu-Chek blood sample reading. In the opinion of my doctor, hearing from his colleagues across the water (remember, this device is not available in my country), it is quite accurate and trustworthy. I’ll run with his opinion — particularly because while trying to cross-check different meters I have here, they all seem to have a quite wider error range you’d expect, even when working on a blood sample from the same finger (from different fingers it gets complicated even for the same reader.)
I’m not thrilled by the idea of using rechargeable batteries for a glucometer. If I need to take a measurement and my Accu-Chek Mobile doesn’t turn on, it takes me just a moment to pick up another pair of AAA from my supply and put them in — not so on a USB-charged device. But on the other hand, it does make for a relatively small size, given the amount of extra components the device need, as you can see from the picture. The battery also lasts more than a couple of weeks without charging, and it does charge with the same microUSB standard as most of my other devices (excluding the iPod Touch and the Nexus 5X), so it’s not too cumbersome while traveling.
A note on the picture: while the Accu-Chek Mobile has a much smaller and monochromatic non-touch screen, lots of its bulk is taken by the cassette with the tests (as it does not use strips at all), and it includes the lancing devices on its side, making it still quite reasonably sized. See also my review of it.
While the sensors store up to 8 hours of readings, the reader stores then up to three months of that data, including additional notes you can add to it like insulin dosage (similar to InsuLinx), meals and so on. The way it shows you that data is interesting too: any spot-check (when you scan the sensor yourself) is stored in a logbook, together with the blood sample tests — the logbooks also include a quick evaluation on whether the blood sugar is rising, falling (and greatly so) or staying constant. The automatic sensor readings are kept visible only as a “daily graph” (for midnight to midnight), or through “daily patterns” that graph (for 7, 14, 30 and 90 days) the median glucose within a band of high and low percentiles (the device does not tell you which ones they are, more to that later.)
I find the ability to see these information, particularly after recording notes on the meals, for instance, very useful. It is making me change my approach for many things, in particular I have stopped eating bagels in the morning (but I still eat them in the evenings) since I get hypers if I do — according to my doctor it’s not unheard of for insulinoresistance to be stronger as you wake up.
I also discovered that other health issues you’d expect not to be related do make a mess of diabetes treatment (and thus why my doctors both insisted I take the flu shot every year). A “simple” flu (well, one that got me to 38.7⁰C, but that’s unrelated, no?) brought my blood sugar to raise quite high (over 20 mmol/l), even though I was not eating as much as usual either. I could have noticed with the usual blood checking, but that’s not something you look forward to when you’re already feverish and unwell. For next time, I should increase insulin in those cases, but it also made me wary of colds and in general gave me a good data point that caring even for small things is important.
A more sour point is, not unusually, the software. Now, to be fair, as my doctor pointed out, all diabetes management software sucks because none of it can have a full picture of things, so the data is not as useful, particularly not to the patients. I have of course interest in the software because of my work on reverse engineering, so I installed the Windows software right away (for once, they also provide an OSX software, but since the only Mac I have access to nowadays is a work device, I have not tried it.)
Unlike the previous terrible experience with Abbott software, this time I managed to download it without a glitch, except for the already-noted geolocking of their website. It also installed fine on Windows 10 and works out of the box, among other things because it requires no kernel drivers whatsoever (I’ll talk about that later when I go into the reverse engineering bits.)
Another difference between this software and anything else I’ve seen up to now, is that it’s completely stateless. It does not download the data off the glucometer to store it locally, it downloads it and run the reports. But if you don’t have the reader with you, there’s no data. And since the reader stores up to 90 days worth of data before discarding, there are no reports that cross that horizon!
On the other hand, the software does seem to do a good job at generating a vast number of information. Not only it generates all the daily graphs, and documents the data more properly regarding which percentiles the “patterns” refer to (they also include two more percentile levels just to give a better idea of the actual pattern), but it provides info such as the “expected A1C” which is quite interesting.
At first, I mistakenly thought that the report functionality only worked by printing, similarly to the OneTouch software, but it turns out you can “Save” the report as PDF and that actually works quite well. It also allows you to “Export” the data, which provides you with a comma-separated values file with most of the raw data coming from the device (again, this will become useful in a separate post.)
That does not mean the software is not free from bugs, though. First of all, it does not close. Instead, if you click on the window’s X button, it’ll be minimized. There’s an “Exit” option in the “File” menu, but more often than not it seems to cause the software to get stuck and either terminated by Windows, or requiring termination through the Task Manager. It also keeps “prodding” for the device, which ends up using 25% of one core, just for the sake of being open.
The funniest bit, though, was when I tried to “print” the report to PDF — which as I said above is not really needed, you can export it from the software just fine, but I didn’t notice. In this situation, after the print dialog is shown, the software decides to hide any other window for its process behind its main window. I can only assume that this hide some Windows printing dialog that they don’t want to distract the user with, but it also hides the “Save As” dialog that pops up. You can type the name blindly, assuming you can confirm you’re in the right window through Alt-Tab, but you’ll also have to deal with the software using its installation directory as work directory. Luckily Windows 10 is smart enough, and will warn about not having write access to the directory, and if you “OK” the invisible dialog, it’ll save the file on your user’s home directory instead.
As for final words, I’m sure hoping the device becomes available in Republic of Ireland, and I would really like for it to be covered by the HSE’s Long Term Illness program, as the sensors are not cheap at £58 every two weeks (unless you’re clumsy as me and have to replace it sooner.) I originally bought the starter kit to try this out and evaluate it, but I think it’s making enough of good impact that (since I can afford it) I’ll keep buying the supplies with my current method until it is actually available here (or until they make it too miserable.) I am not going to stop using the Accu-Chek Mobile for blood testing, though. While it would be nice to use a single device, the cassette system used by the Roche meter is just too handy, particularly when out in a restaurant.
I’ll provide more information on my effort of reverse engineering the protocol in a follow-up post, so stay tuned if you’re interested in it.
As I said in previous posts, I have decided to spend some time reverse engineering the remaining two glucometers I had at home for which the protocol is not known. The OneTouch Verio is proving a complex problem, but the FreeStyle Optium proved itself much easier to deal with, if nothing else because it is clearly a serial protocol. Let’s see all the ducks to get to the final (mostly) working state.
Alexander Schrijver already reverse engineered the previous Freestyle protocol, but that does not work with this model at all. As I’ll say later, it’s still a good thing to keep this at hand.
The “strip-port” cable that Abbott sent me uses a Texas Instrument USB-to-Serial converter chip, namely the TIUSB3410; it’s supported by the Linux kernel just fine by itself, although I had to fix the kernel to recognize this particular VID/PID pair; anything after v3.12 will do fine. As I found later on, having the datasheet at hand is a good idea.
To reverse engineer an USB device, you generally start with snooping a session on Windows, to figure out what the drivers and the software tell the device and what they get back. Unfortunately usbsnoop – the open source windows USB snooper of choice – has not been updated in a few years and does not support Windows 10 at all. So I had to search harder for one.
Windows 7 and later support USB event logging through ETW natively, and thankfully more recently Microsoft understood that those instructions are way too convoluted and they actually provide an updated guide based on Microsoft Message Analyzer, which appears to be their WireShark solution. Try as I might, I have not been able to get MMA to provide me useful information: it shows me fine the responses from the device, but it does not show me the commands as sent by the software, making it totally useless for the purpose of reverse engineering, not sure if that’s by design or me not understanding how it works and forgetting some settings.
A quick look around pointed me at USBlyzer, which is commercial software, but both has a free complete trial and has an affordable price ($200), at least now that I’m fully employed, that is. So I decided to try it out, and while the UI is not as advanced as MMA’s, it does the right thing and shows me all the information I need.
Now that I have a working tool to trace the USB inputs and outputs, I recorded a log while opening the software – actually, it auto-starts – downloading the data, checking the settings and change the time. Now it’s time to start making heads and tails of it.
First problem: TI3410 requires firmware to be uploaded when it’s connected, which means a lot of the trace is gibberish that you shouldn’t really spend time staring at. On the other hand, the serial data is transferred over raw URB (USB Request Block), so once the firmware is set up, the I/O log is just what I need. So, scroll away until something that looks like ASCII data comes up (not all serial protocols are ASCII of course, the Ultra Mini uses a binary protocol, so identifying that would have been trickier, but it was my first guess.
Now with a bit of backtracking I can identify the actual commands: $xmem, $colq and $tim (the latest with parameters to set the time.) From here it would all be simple, right? Well, not really. The next problem to figure out is the right parameters to open the serial port. At first I tried the two “obvious” positions: 9600 baud and 115200 baud, but neither worked.
I had to dig up a bit more. I went to the Linux driver and started fishing around for how the serial port is set up on the 3410 — given the serial interface is not encapsulated in the URBs, I assumed there had to be a control packet, and indeed there is. Scrollback to find it in the log gives me good results.
While the kernel has code to set up the config buffer, it obviously doesn’t have a parser, so it’s a matter of reading it correctly. The bRequest = 05h in the Setup Packet correspond to the TI_SET_CONFIG command in the kernel, so that’s the packet I need. The raw data is the content of the configuration structure, which declares it being a standard 8N1 serial format, although 0x0030 value set for the baudrate is unexpected…
Indeed the kernel has a (complicated) formula to figure the right value for that element, based on the actual baudrate requested, but reversing it is complicated. Luckily, checking the datasheet of the USB to serial conveted I linked earlier, I can find in Section 5.5.7.11 a description of that configuration structure value, and a table that provides the expected values for the most common baudrates; 0x0030 sets a rate close to 19200 (within 0.16% error), which is what we need to know.
It might be a curious number to choose for an USB to serial adapter, but a quick chat with colleagues tells me that in the early ‘90s this was actually the safest, fastest speed you could set for many serial ports providers in many operating systems. Why this is still the case for a device that clearly uses USB is a different story.
So now I have some commands to send to the device, and I get some answers back, which is probably a good starting point, from there on, it’s a matter of writing the code to send the commands and parse the output… almost.
One thing that I’m still fighting with is that sometimes it takes a lot of tries for the device to answer me, whereas the software seems to identify it in a matter of seconds. As far as I can tell, this happens because the Windows driver keeps sending the same exchange over the serial port, to see if a device is actually connected — since there is no hotplugging notifications to wake it up, and, as far as I can see, it’s the physical insertion of the device that does wake it up. Surprisingly though, sometimes I read back from the serial device the same string I just sent. I’m not sure what to do of that.
One tidbit of interesting information is that there are at least three different formats for dates as provided by the device. One is provided in response to the $colq command (that provides the full information of the device), one at the start of the response for the $xmem command, and another one in the actual readings. With exception of the first, they match the formats described by Alexander, including the quirk of using three letter abbreviation for months… except June and July. I’m still wondering what was in their coffee when they decided on this date format. It doesn’t seem to make sense to me.
Anyway, I have added support to glucometerutils and wrote a specification for it. If you happen to have a similar device but for a non-UK or Irish market, please let me know what the right strings should be to identify the mg/dL values.
And of course, if you feel like contributing another specification to my repository of protocols I’d be very happy!
