Offline Data

[maerlyn13]

Does diaBLE read offline data from Libre 3/2 without a librelink connection ? Or does it need to be online to display /pull BG values? Is the official Libre app the only way to receive offline BG values?

[gui-dos]

The algorithms to decrypt the European Libre 2 FRAM data and the BLE traffic were unveiled already three years ago by the FreeAPS team and are shared among all the iOS open source apps. Android’s xDrip+ also started from that original TypeScript code but they are distributing only a binary OOP2 apk.

Although the Android developers thought it was not possiBLE, I discovered that the MAC addresses are not involved and that you can reconnect to a Libre 2 from a different device than the phone on which it was activated, directly, for example, from an Apple Watch, a Mac, an iPad and probably even from an Apple TV (to be woken up by hyper/ipo alarms when falling asleep watching boring series… :-) ) since they all share the same Core Bluetooth framework.

There are several parameters to be encoded in the “unlock payload” which I am allowing to enter manually in the Details view also in the totally independent Apple Watch app (https://github.com/gui-dos/DiaBLE/blob/82e7641/DiaBLE/Libre2.swift#L202):

• the original patchInfo that the sensor had at the time of the BLE streaming activation (its last two of six bytes change at every scan);
• the unlockCode you established when sending the NFC command A1 1E to activate the BLE streaming; our vendor uses the Int32 activation timestamp (enableTime) but it has been discovered than any Int will do and all the current apps use 42 as the Ultimate Answer to Everything ;-)
• an unlockCount that has to be increased at every new connection.

This is the simple reason why you break all other apps’s pairings when activating the BLE streaming of data (Tools -> RePair Streaming in DiaBLE) since the sensor stores that counter internally and refuses to connect when the other apps send their own old one. Luckily the NFC A1 1E command can be sent countless times and the counter is reset each time: when it is uninstalled and reinstalled, also the official LibreLink app does so and can restore its alarms. There is no risk to "break" a sensor or have to wait for the next one as you read on Facebook...

To decrypt the Libre 2 only its sensor NFC UID is required (https://github.com/gui-dos/DiaBLE/blob/82e7641/DiaBLE/Libre2.swift#L254) and in the Test mode you can run DiaBLE side-by-side with other apps and sniff their ingoing data in parallel simply by omitting to send the unlock payload. B-)

The newer Libre 2 US/CA/AU (and the corresponding European Libre Sense “biosensor” by Supersapiens) adopt the enhanced “Gen2” protocols that I am outlining in (https://github.com/gui-dos/DiaBLE/blob/main/DiaBLE/Gen2.swift). The FRAM layout and the kind and size of the BLE packets are the same but the decrypting keys are generated dynamically for each “secure” session and you have to follow a multi-stage challenge-response protocol. AFAIK, the native methods P1() and P2() haven’t been reverse engineered: the @bubbledevteam has been working on an online solution for iOS through their glucose.space server (https://github.com/gui-dos/DiaBLE/blob/main/DiaBLE%20Playground.swiftpm/OOP.swift) but since they haven’t released an iPhone version of DiaBox for over a year, it is not clear if they finally succeeded.

The Libre 3 adopts totally different algorithms, the ECDH key agreement protocol and the AES 128 CCM block cipher: these are industrial standards provided in Trident by whiteCryption/Zimperium and certainly it is possiBLE to replicate them as Loop is doing, for example, to support Medtronic pumps. But there are new native methods, process1() and process2() and even the popular solution currently available on Android, Juggluco, clearly hasn't succeeded in reversing them yet so it has to embed and redistribute the native obfuscated binary liblibre3extension.so, hence the DMCA takedown request.

I don’t know whether it will ever possiBLE to decrypt the Libre 3 data on iOS but I am already sniffing correctly in Test mode all the several kinds of packets and the authentication/authorization ingoing traffic and workflow. You can take a look at the log in (1cf969e#commitcomment-132720183) to have an idea of my ongoing efforts... and success! B-)