Difference between revisions of "Medtronic CGMs and Insulin Pumps"

From RECESSIM, A Reverse Engineering Community
Jump to navigation Jump to search
(Added first version)
 
m (Wording and small typos)
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
Medtronic has been developing Continuous Glucose Monitor devices and Insulin Pumps for people with diabetes. The devices work with their respective applications which have not so great user experience and also lack some features. The apps are locked down, they use Google's Play Integrity checks to disallow rooted phones and also contain custom white & black lists for specific mobile phones and Android versions (possibly due to tests for medical reasons?). These make the product almost a pain to use, so that's why I started reversing the applications and the communication between the glucose sensor and the insulin pump (or mobile phone). They use BLE with their own crypto library called SAKE. You have to perform a handshake to be able to do anything useful with the device, but the key comes from their servers, effectively enabling you to lose access to your device (which you very much depend on because of the disease).  
+
[https://github.com/palmarci/OpenGuardian4/ GitHub project]
 +
 
 +
 
 +
'''Why?'''
 +
 
 +
Medtronic has been developing Continuous Glucose Monitor devices and Insulin Pumps for people with diabetes. The devices work with their respective applications which have not so great user experience and also lack some features. The apps are locked down, they use Google's Play Integrity checks to disallow rooted phones and also contain custom white & black lists for specific mobile phones and Android versions (possibly due to tests for medical reasons?). These make the product a pain to use, so that's why I started reversing the applications and the communication between the glucose sensor and the insulin pump (or mobile phone). They use BLE with their own crypto library called [https://github.com/palmarci/OpenGuardian4/blob/main/sake_whitepaper.pdf SAKE]. You have to perform a handshake to be able to do anything useful with the device, but the key comes from their servers, effectively enabling you to lose access to your device (which you very much depend on because of the disease). Currently the work is in its early stage and sadly I had to get off of the project for a little while to focus on my studies, but I assure you, the development will continue :))   
 +
 
 +
'''Current progress:'''
 +
 
 +
- Managed to extract a few "master keys" which seems to be the static (at least for my devices), which will enable us to work on this project without ever needing to contact Medtronic's servers.
 +
 
 +
- Made hooks to sniff and extract raw and also decrypted packets from the running application
 +
 
 +
- Identified the BLE UUIDs and the commonly used packet formats
 +
 
 +
- Made a very basic Java project to decode and also encode a few basic packets
 +
 
 +
- Got sidetracked with the API because it's key to receiving FW update packages to disassemble
 +
 
 +
- This API knowledge enabled different open source projects which retrieve sensor data from the Medtronic cloud ([https://github.com/ondrej1024/carelink-python-client carelink-python-client], [https://github.com/benceszasz/xDripCareLinkFollower/ xDripCareLinkFollower])   
 +
 
 +
'''Future work:'''
 +
 
 +
- Find a way to interface with the original SAKE crypto library
 +
 
 +
- Explore the communication protocol, create our own version to send and receive messages
 +
 
 +
- Document everything properly
  
Currently the work is in its early stage, I had to get off of the project for a little time to focus on my studies, but I assure you it will continue :))
+
- Reverse engineer the crypto library, re-implement it in C
  
Current state:
+
- Integrate this functionality into an open-source diabetic app
- Managed to extract a few "master keys" which seems to be the static (at least for my devices), which will enable us to work on this project without ever needing to contact Medtronic's servers.
 
- Made hooks to sniff and extract raw and also decrypted packets from the running application
 
- Identified the BLE UUIDs and the commonly used packet formats
 
- Made a very basic Java project to decode and also encode a few basic packets
 
- Got sidetracked with the API because it's key to receiving FW update packages to disassemble
 
- This API knowledge enabled different open source projects which retrieves sensor data from the Medtronic cloud ([https://github.com/ondrej1024/carelink-python-client carelink-python-client], [https://github.com/benceszasz/xDripCareLinkFollower/ xDripCareLinkFollower])
 
  
Future work:
+
- Maybe even run all this on a small microcontroller hardware (with a display or MQTT stuff)
- Find a way to interface with the original SAKE crypto library
 
- Explore the communication protocol, create our own version to send and receive messages
 
- Document everything properly
 
- Reverse engineer the crypto library, re-implement it in C
 
- Integrate this functionality into an open-source diabetic app
 
- Maybe even run all this on a small microcontroller hardware (with a display or MQTT stuff)  
 
  
[https://github.com/palmarci/OpenGuardian4/ GitHub project]
 
  
If you are interested, please text me in the Recessim Discord. We also have a different Discord server where development is happening, just ask for the link ;)
+
Any help is very much appreciated if you are diabetic yourself or have access to these devices! If interested, please text me in the Recessim Discord. We also have a different Discord server where the development is happening, just ask for the link ;)

Latest revision as of 19:00, 26 May 2024

GitHub project


Why?

Medtronic has been developing Continuous Glucose Monitor devices and Insulin Pumps for people with diabetes. The devices work with their respective applications which have not so great user experience and also lack some features. The apps are locked down, they use Google's Play Integrity checks to disallow rooted phones and also contain custom white & black lists for specific mobile phones and Android versions (possibly due to tests for medical reasons?). These make the product a pain to use, so that's why I started reversing the applications and the communication between the glucose sensor and the insulin pump (or mobile phone). They use BLE with their own crypto library called SAKE. You have to perform a handshake to be able to do anything useful with the device, but the key comes from their servers, effectively enabling you to lose access to your device (which you very much depend on because of the disease). Currently the work is in its early stage and sadly I had to get off of the project for a little while to focus on my studies, but I assure you, the development will continue :))

Current progress:

- Managed to extract a few "master keys" which seems to be the static (at least for my devices), which will enable us to work on this project without ever needing to contact Medtronic's servers.

- Made hooks to sniff and extract raw and also decrypted packets from the running application

- Identified the BLE UUIDs and the commonly used packet formats

- Made a very basic Java project to decode and also encode a few basic packets

- Got sidetracked with the API because it's key to receiving FW update packages to disassemble

- This API knowledge enabled different open source projects which retrieve sensor data from the Medtronic cloud (carelink-python-client, xDripCareLinkFollower)

Future work:

- Find a way to interface with the original SAKE crypto library

- Explore the communication protocol, create our own version to send and receive messages

- Document everything properly

- Reverse engineer the crypto library, re-implement it in C

- Integrate this functionality into an open-source diabetic app

- Maybe even run all this on a small microcontroller hardware (with a display or MQTT stuff)


Any help is very much appreciated if you are diabetic yourself or have access to these devices! If interested, please text me in the Recessim Discord. We also have a different Discord server where the development is happening, just ask for the link ;)