Libre 3

[mathieufitzgerald]

Ok. I've been following Juggluco for a while now trying to port the encryption over to iOS and recently came across DiaBLE. I have a few questions about the Libre 3 and how it handles BLE communication.

• Confirming from Juggluco Source, I believe the sensor does not give its "blePIN" if it's unactivated, unless the accountID from the user's Libre Account is present ? (I could be wrong, but from your code, it looks liek exactly that)
• r1, r2 and nonce are all to be encrypted, from what I understand, in the challenge. Will need AES128CCM for that, and ECHD keys. If I understand well, the blePIN is also required to be encrypted in the challenge, if not the sensor responds and disconnects ?

So in theory, without the blePIN, no stable connection is possible, which we know. Now the question is being able to use AES128CCM and ECHD for the actual glucose measurements if i'm not mistaken ?

Now my question is, for the actual glucose data to be sent to the sensor via BLE, i'm assuing all of it arrives encrypted and needs to be decrypted, and I think that's the part where everyone is stuck in getting this working on iOS.

I could be wrong in all of this, I too am trying to figure out how to port the encryption from Juggluco into Swift language. I find this project fascinating. I've always wanted to develop my own stand-alone app to get readings from my sensor, as the Libre 3 app on iOS is really a horrible experience.

[gui-dos]

I think there is a special receiverId not tied to a user’s LibreView account id which is used by the readers, so very probably you can activate a sensor and generate a valid blePIN starting from it, anyway.

You can retrieve and verify the current blePIN from the internal Realm database, as well as the 149-byte exportedKAuth to initialize the crypto library which is wrapped by using the proprietary Zimperium methods and therefore further secured: notice that the PIN is used when encoding also the outgoing “patch control commands” to request the backfilling data and this is what makes the Libre 3 innovative as it lets you recover at least the latest 120 1-minute “clinical” data and the entire 5-minute “historical” data directly from the sensor memory.

Juggluco has to use the native generateEphemeralKeys() method (65 bytes) and this is the stopping point inhibiting porting its code to iOS, along the unknown use of eight “packet descriptors” to encode differently the eight distinct data streams kinds (https://github.com/gui-dos/DiaBLE/blob/c28ee52/DiaBLE/Libre3.swift#L262-L271): the clear distinction between the realtime 1-minute data and the historical ones updated with the noticeable latency of 17 minutes is what make the current workaround to scrape the latest value from the libreview.io servers a technical nonsense.

Yep: I know what I am doing wrong and my limitations to do it the right way... ;-)

Currently I am not investigating directly on rooted/jailbroken phones but just trying to make sense of the cryptic Juggluco code and the different nomenclatures used in the decrypted iOS and Android enums and struct definitions which match elegantly instead.

[mathieufitzgerald]

Hello!
Hope all is well. Noticed a while ago that the project had been taken down from Github for a bit, happy to see it back up and running :)
What is the current update on Libre 3's progress? I saw one of your comments where you said you:

"identified the enums and struct member definitions in the decompiled Swift executables but, unfortunately, Juggluco’s developer lacks experience in iOS reverse-engineering and nobody else appears interested in documenting the underlying protocols openly on GitHub anymore."

Would it be possible for you to give like a list of things that need to be worked on or what is currently the main issue / what the big things that need to be ported over to iOS are? Like I had previously mentioned, I'm currently working on an iOS app that aims to work fully standalone by directly connecting the Libre 3 to the iPhone via BLE, like this project aims to do. Porting to iOS from Juggluco's code seems to be the biggest issues, especially with the cryptic code used by Juggluco.

This project is super interesting, and if done well, could be so beneficial to DIY loop systems so people can use the Libre 3 on iOS with DIY loop systems like "Loop" . I have been working on Android / iOS apps over the last 12 years and so have some experience of them. Please let me know if there is anything that I (or the community) could help you with, and we will gladly do so :) The Libre eco-system is a pain in the ass, especially their app, so finding a way to get glucose data in real-time directly would be amazing. Had a friend of mine do a full NFC dump of one of his old Libre 3's btu haven't had the chance to see the dump for myself and whether or not it may come in useful for said project.

Another question. I recently switched over to the Libre 3 Plus since my pharmacy now only sells them, and was wondering if you have seen any differences between the 3 and 3 Plus in terms of NFC / BLE code compatibility ? Or if quite literally the changes are only hardware and not software ? With the Libre 3 Plus now advertising as "ready to use with automatic systems", I'm assuming its measuring algorithm must have changed slightly, but not sure code-wise.

I still find it insane that Abbott and other pharmaceutical companies lock their products down and stop us from using them in a (for us, better) way. Sad that we have to spend months reverse-engineering a product to be able to use it with a different app, and be able to use it to its full capacity. The Libre 3 / 3 Plus can be such a great piece of hardware if it was more "unlocked" (like the Libre 2), since that would allow for small things like custom alarms, but also for major improvements like custom algorithms to use (like the xDrip one).

[gui-dos]

@mathieufitzgerald:

Recently I tried the new unified Libre 2 / 3 app “Libre by Abbott” which is currently available only on the US App Store (https://apps.apple.com/us/app/libre-by-abbott/id6670330506) by using the decrypted IPAs I got from https://decrypt.day/app/id6670330506 and https://armconverter.com/decryptedappstore/us/app/libre-by-abbott/id6670330506?bundleId=com.abbott.adc.freestyle.libre.us .

The setup doesn’t complete because you cannot skip allowing the Critical Alerts

but after resigning the app with the product id of DiaBLE for which I got this special permission, the setup completes:

There aren't new substantial features (no widgets, nor the support for HealthKit or the Apple Watch) but they are now allowing to snooze the alarms in Silent Mode. At last!!!!

As happened with the current US Libre 3 app, unfortunately my Libre 3 (non-Plus) is reported as incompatible: very probably they are detecting that it is an European model:

When you scan a Libre 3 via NFC you can in fact recognize its region (1: Europe, 2: USA) and whether it is a Plus model (generation 0 <-> 1) by analyzing its patchInfo(

DiaBLE/DiaBLE/Libre3.swift

Lines 109 to 120 in e225e4d

	struct PatchInfo {
	let NFC_Key: Int
	let localization: Int // 1: Europe, 2: US
	let generation: Int // 0: Libre 3, 1: Libre 3+
	let wearDuration: Int
	let warmupTime: Int
	let productType: ProductType
	let state: State
	let fwVersion: Data
	let compressedSN: Data
	let securityVersion: Int
	}

).

Unfortunately Hopper cannot spot the crucial Swift definitions like before and if you search i.e. for "PatchInfo" only the logged strings are found.

For the new app they are using in fact React Native I think also for the Android version which is not yet available for example on https://apkpure.com/libre-by-abbott/com.abbott.adc.freestyle.libre.us .

Very probably they dropped the support to Realm (which is being dismissed by MongoDB this year, anyway) and won't allow third-party access to libreview.io anymore but I couldn't verify because not even the recent forks of Python tools like https://github.com/bongtrop/hbctool that I tried recognize the signature of the encrypted main.jsbundle Hermes bytecode as valid.

I think all the other DIY projects are all dead now even because they don't differentiate between the 1-minute real-time "clinical" data and the 5-minute "historical" data which are updated with a latency of 17 minutes and which can be restored for the whole sensor lifetime by sending a specific BLE command for backfilling the data.

My codebase is six years old and I should rewrite its foundations especially to migrate to Swift 6 new concurrency model. I am more than happy to be contacted by new developers like you with fresh projects and ideas!

[gui-dos]

I found that the online APK downloader https://apkdownloader.pages.dev/ works when submitting com.abbott.adc.freestyle.libre.us ;-)

Frontend: https://apkpremier.com/com-abbott-adc-freestyle-libre-us/libre-by-abbott/