New LLU API 5.0.0 -- the end of all uploading?

[poml88]

It seems Abbott has finally released their new LibreLinkUp API 5.0.0 that seems totally different from the API 4.x we know and use. Seems the server response is encrypted now.
I wonder if a) this new API can be used by third party applications and b) for how long the old API 4.x will be kept alive...

[gui-dos]

[timoschlueter]

The party might actually be over: The response payload which contains the glucose values is encrypted in version 5.0.0 :(
I will take a closer look but over the next day but right now it seems like we are out of luck.

[poml88]

Yes, totally encrypted. I already spent a few hours with Ghidra and there are three keys embedded in the app.
In any case, maybe it is now easier to talk to the Libre 3(+) directly...
Question is, how long will they keep version 4 alive...

[gui-dos]

[poml88]

Yes, the first login step is still plain JSON. Then even the next request is encrypted. Probably with the keys embedded in the app. I am trying to find those. But later there might be some augmentation of encryption with some device parameters.

[timoschlueter]

@poml88: I also found the keys in the app but had no chance of using them.
Here we run into another problem anyway: At least here in the EU its not legal to circumvent this kind of security measures. Abbott went out of their way to implement a whitebox crypto architecture in order to prevent "us" from reading the data. This is, from my point of view, very sophisticated and tells me that Abbott will not be messing arround when we decrypt their keys and - even worse - distribute them in this plugin.

Those are my thoughts right now. It will be interesting to see what other OSS apps and plugins will do about this. For now, its game over :(

[timoschlueter]

Man, seems like all developers (and also AIs) are coming to the same conclusion. I was hoping I was just missing something.

Especially the part that describes per device and per user keys makes it impossible to offer a solution that works for everyone like we have now.

We will keep v4 alive as long as we can but as soon as Abbott shuts down the endpoints, we are our of luck.

[poml88]

Indeed, there are legal issues here as well. It seems that RE for "interoperability research" is covered by EU law, but it does not mean that we can publish code or keys or circumvent security measures. So we can find out how it works legally, but not use it... Maybe it would be better if the community approached Abbott to get legal API access. No chance I guess, but that would be the best. In any case, "interoperability research" can be done.

Indeed, if the private key is per device, per user, and also rotated, then it might just not be worth the pain...

[PhilaBurger]

On 2026-04-23 03:48, Timo Schlueter wrote: Man, seems like all developers (and also AIs) are coming to the same conclusion. I was hoping I was just missing something. Especially the part that describes per device and per user keys makes it impossible to offer a Solution that works for everyone like we have now. We will keep v4 alive as long as we can but as soon as Abbott shuts down the endpoints, we are our of luck.Message ID: ***@***.***>

Is it possible to revamp the process to utilize the LibreView APIs instead of the LibreLinkUp APIs?

…

-- [1] "It's always suicide-mission this, save-the-planet that. No one ever just stops by to say 'hi' anymore." --Colonel Jack O'Neill, SG1 Links: ------ [1] https://poplme.co/hash/lqQkxj0F/1/es

[poml88]

Not sure. The "Libre 3" app is uploading it's glucose data to the LibreView API encrypted. Not sure there is a download path.
And if, I would reckon that Abbott is working on encrypting that API as well. The new "Libre by Abbott" app that will come to EU one day too might already use a new API, I don't know. Maybe @gui-dos does.

[ThomasQuant]

Any updates / more info? Worst case, what are your reccomended alternatives (like for example Zukka app + Nightscout app)?

[mstry9]

I suspect if Abbott blocks LibreLinkUp from third parties then Zukka/xdrip4ios will also not be able to follow. For me in the US on iPhone I'll probably have to switch to the 15 day G7. Gonna miss the one minute readings

[poml88]

All 3rd Party apps will stop working. Options I see:

• use Juggluco on Android. It can communicate via BT directly with the Libre 3. And upload to Nightscout I suppose.
• on iOS use the Libre 2 with some app like Zukka to communicate via BT directly.
• use another sensor: Dexcom, Eversense, ...
• wait for new ideas or solutions
• write to or call Abbott Hotline to stress how important 3rd party access to the APIs is for diabetes patients.

[tsimmons]

I just spent 30 minutes on the Abbot Libre Hotline phone (855-632-8658) and expressed my concerns to the operator that answered the call. They put me on hold for several minutes and came back and said they didn't have any idea what to do with my request and they had no one to contact. I have also sent emails to a handful of Abbot support accounts, but none have replied. Not really sure where to voice my concerns at this point?

[poml88]

Putting back the link to this analysis report.
https://www.perplexity.ai/computer/a/llu-v5-investigation-report-jgxtdKsOS5.9.aqmVmgzYw

[poml88]

It is extremely complicated. Abbott spends a lot of time and money making their apps bullet proof.
the Libre 3 app uses a white-box cryptography secure key bag (Chow et al) from Zimperium. There is no key in the app. Only a virtual machine with lots of obfuscated tables. You can extract the whole VM and port that, but it is super difficult. And it was yesterday. Already old stuff.
the LLU 5 and Libre by Abbott are next generation protected. We have no information yet about the details. But if Libre 3 is difficult than we can expect this to be close to impossible.
this time they will not allow unauthorised use of their API

[pachi81]

Ok, thought just too simple/optimistic:
creating privat/public key, send public key to server and use them for en- and decryption...
Just a simple secure API communication...

Ok, my problem, as I do not really expect high level development from Abbott, as the app seems to be created by a trainee 🤣 (at least the old one).

But if they have paid a lot of money for, this is another situation... 🫣

[poml88]

You know, I am wearing both a Libre 3 and a G7 right now. It really seems the dev at Abbott loves his crypto and works very hard to put more crypto in the app. No progress on UI / UX since ages.
The Dexcom dev, it seems, can build a proper UI with UX. the Dexcom G7 app has almost everything.
It’s ridiculous.

[pachi81]

Yes, it would help, if Abbott spends the same energy and money for their app and not only for crypto.... 😤

[poml88]

For your curiosity:
https://github.com/poml88/libre3-auth-ios-sample-app

[pachi81]

Hi, the LLU 5.0.0 app is also available for Android, now.
I had a look into, but only find some information in the string.xml. Also some tokens are included, but as I´m not an expert for such topics, hard to say...

[poml88]

With the release of the Android LLU 5 we are one step closer to LLU 4 being stopped. I might be wrong, but I think they have made LLU 5 really bullet proof. But I found a new solution to talk to the Libre 3+ directly in BLE and I heard there are some other solutions on the way as well. So I think there is hope. :-)

[pachi81]

Hi,
I tried to analyze the Android apk v5.0.1 with Claude Code and this is the result:

What the APK analysis shows

Good news:

• No Play Integrity / SafetyNet — not found in any Smali class. The server does not perform device attestation.
• No native .so libraries — this is a React Native / NativeScript app with Java/Kotlin code. The cryptography component uses Google Tink (a standard Java library), not a mysterious Go binary. The entire cryptographic layer is reproducible.

The keys are present, but obfuscated:

• APP_WRAP_KEY, APP_PUBLIC_KEY, and APP_PRIVATE_KEY are embedded in BuildConfig
• They are decoded at runtime via an XOR routine a(CII[Object)
• The encrypted string pool is the ~3,700-character-long Unicode sequence in accessartificialFrame()
• The obfuscation is deterministic — the arguments come from Android framework calls that always return constant values (e.g. Color.alpha(0) = 0, Color.blue(0) = 0, MeasureSpec.getMode(0) = 0)

This means: the keys can be extracted by simulating the deobfuscation routine in Python — no running Android device is required.

Unfortunately, this consumes so many tokens that I had to stop the analysis. I also stopped it because, even if it were possible, it would still be illegal and cannot be used in an "official" app. :-(