- Freestyle insulinx app for mac how to#
- Freestyle insulinx app for mac serial number#
- Freestyle insulinx app for mac driver#
- Freestyle insulinx app for mac plus#
Freestyle insulinx app for mac plus#
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. 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? 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. The encryption used is either a streaming cipher or a 64-bit block cipher. The session keys’ seeds include a pair of 8-bytes values as provided by the device after the authorization completes.
Freestyle insulinx app for mac serial number#
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. Each set includes an Encryption and a MAC key. 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.
It also likely explains why the encryption is not using the QtCryptography framework at all.
Freestyle insulinx app for mac driver#
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. To build the challenge response, another eight bytes are filled with random returned by CryptGenRandom, which is a fairly low level, and deprecated, API. 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. There’s 15 bytes sent from the Libre 2 reader to the software. 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.
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.
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.
Freestyle insulinx app for mac how to#
Unfortunately, I don’t think I’m any closer to figuring out how to speak to Libre 2 readers. 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. You may remember I have been working on the FreeStyle Libre 2 encrypted communication protocol for a few months. 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.
0 kommentar(er)
