ChangeLog:

• 1/10/2024 - Build 119

  • Scan Lingo's patchInfo via NFC:
    
    
     
    
    
    
  • Detect Stelo's device name starting with DX01xx
  • Display warning when LibreLinkUp needs to re-accept Terms of Use:
    
    
     
    
    
    
  • Detail when a Libre is a Plus
  • Clear Dexcom G7 backfill minutes in BLE Setup:
    
    
     
    
    
    

• 20/1/2024 - Build 88

  • Shell: import and dump LibreView CSV files by using TabularData:

Builds

To build the project, you have to duplicate the file DiaBLE.xcconfig, rename the copy to DiaBLEOverride.xcconfig (the missing reference displayed by Xcode in red should then point to it) and edit it by commenting out the trailing lines after // Comment out the following... and replacing ##TEAM_ID## with your Apple Team ID, so that the first line should read, for example, DEVELOPMENT_TEAM = Z25SC9UDC8.

The NFC capabilities require a paid Apple Developer Program annual membership. If you won't request a Critical Alert Notifications Entitlement, you have to edit out the lines <key>com.apple.developer.usernotifications.critical-alerts</key> <true/> from the .entitlements files in the folders DiaBLE and DiaBLE Watch.

A public beta of DiaBLE is availaBLE at TestFlight: I'll periodically expunge anonymous users I didn't invite or who didn't sponsor me through PayPal $-). If you own an iPad you can download the zipped archive of this repository and just tap DiaBLE Playground.swiftpm to test the corresponding features and even more past legacy ones.

Currently I am targeting only the latest betas of Xcode and iOS and focusing on the new Libre 3 and Dexcom G7. Please consider my personal project still just a prototype (I am not even managing correcty the execution in the background yet), even though most open-source apps (and even commercial ones) make use of my naive NFC and BLE classes which unveil technical details not found elsewhere... ;-)

Warnings

• the temperature-based calibration algorithm has been derived from the old LibreLink 2.3: it is known that the Vendor improves its algorithms at every new release, smoothing the historical values and projecting the trend ones into the future to compensate the interstitial delay but these further stages aren't understood yet; I never was convinced by the simple linear regression models that others apply on finger pricks;
• activating the BLE streaming of data on a Libre 2 will break other apps' pairings and you will have to reinstall them to get their alarms back again; in Test mode it is possiBLE however to eavesdrop the incoming data of multiple apps running side-by-side by just activating the notifications on the known BLE characteristics: the same technique is used to analyze the Libre 3 incoming traffic since the Core Bluetooth connections are reference-counted;
• connecting directly to a Libre 2/3 and a Dexcom G7 from an Apple Watch is currently just a proof of concept that it is technically possiBLE: keeping the connection in the background will require additional work and AFAIK nobody else is capaBLE of doing the job... :-P

The Shell in the Console allows opening both encrypted and decrypted trident.realm files from a backup of the Libre 3 app data (the Container folder extracted for example by using iMazing): see the nice technical post (mentioning me 😎) "Liberating glucose data from the Freestyle Libre 3" (a rooted Android Virtual Machine like Waydroid or the default Google APIs System Image in Android Studio is required to unwrap the Realm encryption key).

TODOs

• Libre 3:
  • tackle AES 128 CCM, ECDH key agreement, Zimperium zShield anti-tampering... (see Juggluco)
• Dexcom G7:
  • J-PAKE authentication protocol (see xDrip+'s keks)
• Apple Watch app:
  • workout and extended runtime background sessions, complications
  • "Get timely alerts from Bluetooth devices in watchOS" - WWDC 2022
• migrate to Swift 6 concurrency
• scrollable graph, offline trend arrow, landscape mode
• smooth the historic values and project the trend ones (see LibreTransmitter)
• log: limit to a number of readings, prepend time, Share menu, record to a file
• new iOS Widgets and App Intents (see OpenGlück)
• SwiftData and/or TabularData as persistence layers (see Glupreview for CoreML use)

Contributions

Please submit your PRs on the dev branch. DiaBLE's conceptual model is quite straightforward: main is the application MainDelegate while app is the observable environmental AppState viewmodel; they retain each other to allow simple expressions globally, such as main.log() and app.device to access the properties of the connected BLE periperal or the current app.sensor.

---

Credits: @bubbledevteam, @captainbeeheart, @cryptax, CryptoSwift, @dabear, @DecentWoodpecker67, FLwatch, Glucosy, @ivalkou, Jaap Korthals Altes, @keencave, LibreMonitor, Loop, Marek Macner, @monder, Nightguard, Nightscout LibreLink Up Uploader, @travisgoodspeed, WoofWoof, xDrip, xDrip+, xDrip4iO5.

Disclaimer: the decrypting keys I am publishing are not related to user accounts and can be dumped from the sensor memory by using DiaBLE itself. The online servers I am using probably are tracking your personal data but all the traffic sent/received by DiaBLE is clearly shown in its logs. The reverse-engineered code I am copying&pasting has been retrieved from other GitHub repos or reproduced simply by using open-source tools like Ghidra and jadx-gui.