Libre 2 Protocol

[DreadRoberts]

I have a Libre 2 and would like to get the data from it. Did you have the chance to look at the protocol of such a device?

[Flameeyes]

I don't have a Libre2 myself to reverse, as it is not available in the UK where I live, which is why there are no specs here for it yet.
If you want to try your luck at taking a look at the protocol and see if it uses the usual FreeStyle base, it might be possible to get it documented still.

[pascalfribi]

Just as some info. I was trying to get data from a Libre 2. I do not have one myself but had to remotely debug.

The libre 2 seems to respond to the commands of the original Libre. Especially reading serial number and stuff works.

But $history? or $arresult? return Garbage. This will return a lot of data, but the content is always the same thing which does not make any sense.

As I do not have a device myself it is hard to debug this any further.

[Flameeyes]

I've added a file with the list of known commands from the previous FreeStyle devices in Flameeyes/glucometerutils@beecba3

You can run it with

./reversing_tools/abbott/freestyle_hid_console.py /dev/hidraw2 < reversing_tools/abbott/known-commands.txt

to generate a log of responses to those. Maybe they use some of the other answers this time around.

[steve8x8]

Using strings -n 4 $file | LANG=C grep '^\$[a-z][a-z0-9]*[a-z][,?]*$' | LANG=C sort > commands with the firmware file extracted from the MacOSX app, I have built a new list of possible commands.
Since it will take several days (or longer) for me to get hold of the reader device again, perhaps someone else can make some sophisticated use of the list?

[DreadRoberts]

I think the Libre 2 is encrypting the data some how with the serial number

[deival1980]

Hello DreadRoberts,
how do you come to the conclusion that the data might be encrypted?
Can you share some data with us?

[deival1980]

Is it possible that it is the same on Libre1 reader with the most actual firmware 2.4.8 installed?
I now see in Wireshark what you are meaning I think.
With the Libre1 and firmware 2.4.8 I see also at beginning of USB transfer a message saying "ECDHE-RSA-AES256-GCM-SHA384" afterwards the only message is ASCII readable is the message with the serial number of the reader. The rest seems to be encrypted maybe really with the serial number...

[deival1980]

My previous paoting is not completely correct, the plain text command "$patch" at the end of the transfer of the original software (Libre1 FW v2.4.8)also seems to report unencrypted data.

[DreadRoberts]

Is the firmware automatically updated when the Libre 1 device is connected to the Libre Software?
My current understanding of the process is the following:

1. Software: request the Serialnumber with the command 0x05
2. Device: answer to request with 0x06
3. Software: sending challenge based on the serial number with 0x14
4. Device: answer to challenge with 0x33

I also wrote a small python script to communicate with the device to test various commands (pywinusb is required):

import pywinusb.hid as hid
import time
import datetime

all_devices = hid.HidDeviceFilter(vendor_id = 0x1a61).get_devices()
target_usage= hid.get_full_usage_id(0xFF00, 0x01)
data_buffer_ascii = []

def response_handler(data):
    global data_buffer
    global data_buffer_ascii
    data_buffer = data[1:]
    data_buffer_ascii = []
    data_buffer_ascii.append("".join(chr(d) for d in data[3:data[2]+2])) # data[2] defines the length of the response

device = all_devices[0]
device.open()
device.set_raw_data_handler(response_handler)

data_sn = [0] * 65
data_sn[1] = 0x05 # serial number
# data[1] = 0x15 software version

device.send_output_report(data_sn)
time.sleep(0.5)
print(data_buffer_ascii)

[steve8x8]

For a reason that isn't completely clear to me (I'm a Python absolute beginner), the freestyle_hid_console.py script by Flameeyes does not work, as reported in https://github.com/Flameeyes/glucometerutils/issues/68 - but I do have a spare device and am willing to run some more tests if guided appropriately.

[Flameeyes]

@DreadRoberts which (country) site did you manage to find desktop software for the Libre 2? I was provided with a device to test with, but on the German website there's no desktop software at all.

[Flameeyes]

Okay I've spent a few hours looking at this and I have some updates:

• I'm not entirely convinced this is ECDHE encrypted at least for the Libre2 — I see too many repeated messages in the trace, so my gut feeling is that this is xor-encrypted or something simple like that, but I have no proof to match this.
• The URBs (USB data) that are sent to the device during handshake are not sent from zeroed memory (not sure if this is a Windows API thing, or app thing), which means that there can be a lot of red herrings there. In my trace, I see references to oftware\Microsoft\Cryptography (which appears to me like a truncated registry key name), and :\Windows\system32\rsaenh.dll, but AFAICT the software uses neither. Following the shared HID protocol definition, that part of the message is ignored anyway.
• I added an extraction script to help analyze usbmon pcapng traces. With the latest software on Windows and my old Libre device it never seem to throw errors (unlike the Libre2), and it does not seem to be encrypted at all. It may look like it's encrypted because it's using the binary protocol, which is the same as I described at the beginning of my FreeStyle Libre work.

I'll provide updates as I find them.

[Flameeyes]

End of day updates:

I have updated the shared HID protocol with more details, as it looks like the initialisation is much shorter than I thought, for most other devices.

The extraction script is a bit smarter about ignoring the keepalive messages.

It appears to me that the way the software talks with the device is pretty much the same (beside encryption) between Libre 1 and Libre 2, so we have a high likeliness of being able to reuse most code once the encryption is defeated. In particular, while the software is using the binary mode (that I never finished reversing on the Libre 1), it also sends a couple of text commands towards the end of the connection establishment, which it does on the Libre 1 too — on that, they are $sn? and $swver?.

So what about that encryption challenge/response?

Command type 0x14 is not known on any previous devices, nor is, as far as I know, the 0x33 answer it receives. The first byte in both commands appears to be a sub-command. 0x11 appears to be some sort of request to the device, and afaict the device responds with exactly the same bytearray every time, starting with 0x16.

The software then sends a 0x14/0x17 command, which is composed of eight bytes that don't appear to change, and another 17 of them that do. The device responds with 0x33/0x18, eight bytes that change, then 15 that don't, eight that change, and two that are \x00\x20.

I don't seem to be able to get this to replay, but that may be me doing something wrong for now.

The fact that there are a couple of places where there's an eight bytes exchange makes me wonder if it's just AES256.