G7 without Dexcom app / Authentication

[SBriere]

Very interesting project! I've made a development setup (so not using TestFlight) in order to test the data retrieval directly from a Dexcom G7 sensor.

I notice that your latest commits seem related to dealing with the authentication process needed to connect directly using BLE to that sensor. Haven't been able to get any data from the device so far - it always disconnect just after the J-PAKE payload being received, but I suppose it's a normal thing in the current development state?

Or maybe am I missing something in the settings (such as "Sensor Code" and "Transmitter Serial" - which is always set to "XXXXkW")?

Also noticing that the "test" mode doesn't include authentication - I suppose it's meant to be used with the Dexcom app running in the background?

[gui-dos]

Yep: the third “Test” mode in the Console is intended for beta testers and those interested in eavesdropping the incoming BLE traffic to the official apps running in parallel, avoiding to send authentication commands that would cause sensors to disconnect.

Even if xDrip4iO5 developers don’t recommend it and make it available only among the Developer Settings, this is a way for example to be able to decrypt the Libre 2 data running in parallel with other apps since only the sensor UID scannable via NFC is required, not the patchInfo at the time of the sensor activation! ;-)

And this is the current way that the Dexcom G7 support works in all the other iOS apps, requiring the official app to run in the background: differently than Abbott, luckily Dexcom is not encrypting the 5-minute realtime values and the backfill stream!

Dexcom wraps the mbedtls framework to implement the J-PAKE authentication protocol (https://github.com/Mbed-TLS/mbedtls/blob/development/tf-psa-crypto/drivers/builtin/include/mbedtls/ecjpake.h) also for the standalone Watch app and, since Android’s xDrip is implementing J-PAKE successfully, perhaps implementing it in iOS might be a reachable goal.

From the decrypted IPA of Tandem’s t-connect app (i.e. https://decrypt.day/app/id1455916023) you can notice that they are implementing J-PAKE in their own way, apparently without using a partner SDK black box but, if you search GitHub for a pure Swift implementation of J-PAKE, you don’t get any result. The clean implementation https://github.com/particle-iot/iOSBLEExample/blob/main/iOSBLEExample/ParticleBLECode/ECJPake.swift for example also leverages on their mbedtls wrapping.

The Dexcom G7 support implemented in https://github.com/LoopKit/G7SensorKit seems really limited and poorly documented, too tied to the past.

In the Dexcom G7, for example, there aren’t separate “Tx” and “Rx” opcodes: the same opcode is used as the header byte marker for both the request commands and the sensor replies. Most commands now don’t even require a final CRC, also, and countless detailed primary and secondary state codes are sent.

Specific commands for requesting backfilling data and further encrypted streams regarding internal calibration and factory data (and even a debugging backdoor) are clearly available.

I am a Libre 3 final user but, having to purchase Dexcoms on eBay on my own, I am equally motivated and intrigued to explore the Dexcom internals anyway: hopefully some more third party apps by the growing number of pump manufacturers partners will leak out crucial details on the cryptographic algorithms…. ;-)

[ianjorgensen]

@gui-dos id be more than happy to ship you G7s to wherever you need them, I would love to be able to connect directly without the official app installed.

I had to resintall the dexcom g7 app when it gave me an error message when trying to pair a new sensor while traveling abroad and dexcom didn't let me login or signup to pair a new device and get readings. I was told to go by dexcom support back home to use the cgm again. This is know issue 🤯

[gui-dos]

@ianjorgensen

Pairing a Dexcom G7 sensor requires going through a multi-stage challenge-response protocol involving certificate exchanges and validations.

Similar to the Libre 3, the authentication commands follow a sequential order (02 03 04 05 06 07 …) therefore you can easily grasp the logic workflow of the activation process:

DiaBLE/DiaBLE/DexcomG7.swift

Lines 78 to 119 in a5b8c52

	// Pairing:
	// enable notifications for 3535 and 3538
	// write 3535 0A 00
	// notify 3538 20 * 6 bytes
	// notify 3535 0A 00
	// notify 3538 20 * 2 bytes
	// write 3538 20 * 8 bytes
	// write 3535 0A 01
	// notify 3538 20 * 6 bytes
	// notify 3535 0A 01
	// notify 3538 20 * 2 bytes
	// write 3538 20 * 8 bytes
	// write 3535 0A 02
	// notify 3538 20 * 6 bytes
	// notify 3535 0A 02
	// notify 3538 20 * 2 bytes
	// write 3538 20 * 8 bytes
	// write 3535 02 + 8 bytes + 02
	// notify 3535 03 + 16 bytes
	// write 3535 04 + 8 bytes
	// notify 3535 05 01 02
	// write 3535 0B00 + 4 bytes
	// notify 3538 20 * 6 bytes
	// notify 3535 0B0000 + 4 bytes
	// notify 3538 20 * 18 + 12 bytes
	// write 3538 20 * 24 + 14 bytes
	// write 3535 0B01 + 4 bytes
	// notify 3538 20 * 6 bytes
	// notify 3535 0B0001 + 4 bytes
	// notify 3538 20 * 16 + 17/18 bytes // *15+7 when repairing
	// write 3538 20 * 23/22 + 6 bytes // *21+14 when repairing
	// write 3538 0B02 0000 0000
	// notify 3535 0B00 0200 0000 00
	// write 3538 0C + 16 bytes
	// notify 3538 20 * 3 + 4 bytes
	// notify 3535 0C00 + 16 bytes
	// write 3538 20 * 3 + 4 bytes
	// write 3535 06 + byte
	// notify 3535 06 00
	// write 3535 07
	// notify 3535 07 00
	// notify 3535 08 01

I am already happy to be able to detect the different BLE characteristics involved and the amount and kind of data sent/received which other DIY open-source projects seem to have no clue about and/or not willing to document… B-)

[ps2]

@gui-dos sent you a note on Loop zulip, if you have a moment.

[gui-dos]

@ps2

I am using PacketLogger included in the Xcode Additional Tools to sniff the Libre/Dexcom BLE traffic.

I posted, for example, in the comments to 7d4deeb, beside the zipped logs captured during the initial J-PAKE pairing and the later backfilling traffic, even a screenshot of my standalone watchOS implementation eavesdropping the official app running in parallel, but I got no feedback. Frustrated, I unsubscribed and rejoined the Zulip chat, but I was happy with my lonely world-exclusive scoop anyway ;-)

I am not rooting/jailbreaking my daily Pixels/iPhones, but I have a licensed copy of Hopper, and I am fond of comparing the decompiled Android bytecode by jadx-gui with the Swift struct descriptors where the enum constants’ definitions are not sorted alphabetically but in the correct camelCase order! B-)

I met a very responsive Chinese bot who provides decrypted IPAs (with https://github.com/ChiChou/bagbak) for using with PlayCover on Silicon Macs. I am probably the guy who is populating the medical category https://decrypt.day/apps/medical the most: B-) (the Stelo app has been uncategorized on https://decrypt.day/app/id6475610406).

In the past, I succeeded in importing the US IPA and using the ONE/G7s I bought on eBay before they were available in Italy, but, you know, regulations and distribution channels can vary a lot from country to country, and I’m not sure if the Stelo would be available here anytime soon... :-(

I just bought a couple of ONE+s which are sold here quite cheaply for 42€ not by Dexcom but by Roche/AccuCheck (https://shop.dexcomone.info/eShop/monitoraggioincontinuo): upon looking at the IPA, the support for Direct-To-Watch looks like it is already available behind geofencing... ;-)

[MechaSteve]

Very cool work here.

I have a working implementation of a standalone G6 receiver implemented on an ESP32-S3 based system.

I am working on extending the system to support the G7 sensors, and would welcome any insight you can give.

If I understand your explanation, there is significantly more security encryption and handshakes involved with the G7 to complete pairing, compared to the G6. Is that correct, or is the additional security limited to the more advanced functions?

[MechaSteve]

https://github.com/MechaSteve/Flying-CGM

[gui-dos]

I noticed in https://github.com/j-kaltes/Juggluco/blob/f9aad1a3080e92c42e253b96ed511cb7ba5ac5b2/Common/src/dex/java/tk/glucodata/DexGattCallback.java#L774-L779 that Juggluco is using the same certificate data that xDrip+ is requiring to QR-scan manually (https://navid200.github.io/xDrip/docs/Dexcom/G7.html) but unfortunately these days I am not experimenting actively with Dexcoms since their Direct-To-Watch implementation is already optimal to try to tweak and improve it…

Yep: the J-PAKE authentication protocol is now required to generate the ephemeral keys. I am seeing that all the other iOS partners' apps are wrapping the mbedtls framework but I am desisting to try to port it since my project got little feedback from the community about the much richer set of opcodes commands availlaBLE with the G7… :-(