A dangerous game - anyone out there hack their diabetes devices?

I wonder if anyone out there has tried to reverse engineer/develop/hack the communication protocols (especially the wireless ones) on their diabetes devices? pumps, CGMs, etc. I love the idea of tinkering with a receiver that could generate twitter feeds, light up a light on my bedstand, etc. etc. - of course it opens the door to people trying to make their own closed-loop systems, which would be wicked cool, if probably deadly. :wink:

Hi Jerome,
I wrote a good portion of the Insulet Onipod communication protocol/interface software, but only from the network layer and up. Other people wrote the link layer (bit parsing) and designed the physical layer (HW, antenna, etc). I was also involved in the Guardian RT software, but only had some exposure to the communication part. However, I can’t tell you more than this on that subject as that stuff is intelectual property belonging to Medtronic/MiniMed and Insulet. What I can tell you is that, mainly, you’ll need to know at what frequency the data is transmitted and have a spectrum analyzer to capture it. It’s tricky then to identify the bits in the signal so you can eventually build the bytes and put together the whole messages going back and forth. Another way is, by knowing the frequency, build a similar HW/antenna circuit attached to a microprocessor and write the link layer software to parse out the analog signal and get the bits/bytes/messages. There might be commercially available HW and software to do all this but I’ve never searched for it. Disclaimer: I’m telling you about these methods because it’s common engineering knowledge, but I don’t recommend you doing this unless you have the manufacturer’s (and maybe the FDA’s) approval. Good luck. My email is gdepaula@pancreum.com.

Hi Jerome,



Good luck on your project, I look forward to hearing about your progress! Determining the frequency is the first easy part as that is public knowledge. You can find information about licensed wireless devices on the FCC website here:



https://fjallfoss.fcc.gov/oetcf/eas/reports/GenericSearch.cfm



Searching for Insulet as the Applicant returns 5 devices that all operate at the ISM frequency of 13.56MHz. If you click into these you’ll see pictures of the pods and 1st/2nd gen PDM.



Good luck!

Hey we should chat. I've done some analysis. I now have
several partial transcripts showing the messages flowing
between the PC and the usbstick. I also have analyzed the
java applet and have been able to produce a python library
capable of talking to Lifescan's OneTouchUltralink,
Profile, and the usbstick.


The usbstick functionality is still limited. The usbstick
is a really elegant device: it basically exposes a buffer
with which you interact with the radio and any device that
expects to recieve the messages you send. The messages
written and read from the buffer must be correctly
formatted. There is a set of local "diagnostic" commands
to inspect the USB stick itself, and then some special
commands to manipulate the buffer.


While I've been able to implement the local commands, the
end-to-end operation of successfully executing radio
commands is still incomplete. I'm thinking that the best
bet at this point is to produce a document on the
communication protocol. The traces indicate that to send
and recieve one piece of data, a flow of at least commands
are required, which is too onerous to get right using the
"poke it with a stick" method I've been using.


Is anyone interested in helping to document their
protocol? I've got a full time job, and this stuff is
eating up my time. At the current rate, it'll take at
least another 6 months before I've got fully working
version talking with pumps.

https://bitbucket.org/bewest/carelink-python/src/7d624e5d0fd8/src/insulaudit/devices/


This is purely about auditing current therapy. It's
shameful that Medtronic has a policy preventing us from
gaining access to our own data. Everyone should put a
call in to Medtronic, ask for the "Advanced Software
Group" and request access to the "communication protocol
used by the usbstick." If they respond with "software
codes" tell them you don't know what they are talking
about and you want the protocol.


Personally, I expect to be able to audit the device,
confirm the presence or absence of defects, and
communicate therapy progress with caregivers. In order to
do that I need access to the data on the device, which
Medtronic has a policy against. I don't expect them to
support every possible use case, but I do expect to be
able to audit my own data if they prove unable.


It would be interesting to use a JVM language to drive the
java classes and replace that crappy Jungo/SerialIO stuff.
I'm not sure why anything fancy is needed; the usbstick
will load as an ordinary serial port under Linux. While
driving their java classes would be useful to test parts
of the communication model, I'm not sure if it would put
me on the bad side of their ToS. Has anyone considered
using jython or javascript to drive some of the classes
implementing the protocols?


To the glucosurfer guys: I tried looking for a way to
upload data to you but failed to find anything. What
format are you expecting? Can I request an ATOMPUBSUB
interface to the data so that other "cloud controllers"
can interoperate with you?



As you uncover the data formats used by different devices, I’d appreciate it if you’d share them with me.

I know many device makers won’t share the protocols, or will but won’t allow you to share them. I’m not interested in those. I’ve been trying to maintain a catalog of diabetes device data formats on a wiki, hoping that it will enable folks to develop better visualization and analysis software. If you can share info with me, I’d be happy to host it on that wiki. You can email me directly at bernard.farrell@gmail.com. Thanks.

I heard a talk by David Kotz recently where he was talking about this. Seems there is a lot that needs to be done to make these things secure. He mentioned some work where researchers demonstrated ability to cause a heart attack by hacking the wireless protocol of a pacemaker. Maybe you do want that tinfoil hat…

Yep. I can see that happening and that’s why I’m against this game. I know that sometimes I sound a little apocalyptical, but if someone breaks the receive/transmit protocol of an insulin pump maker, and that knowledge ends up in the wrong hands, could the knowledge be used by someone to randomly send bolus commands at an ADA conference? Ok, maybe it sounds like a bad sci fi book/movie, but just never say never.

The communication protocol has redundancy and identity
checks that insure intent. In fact, in order to use the
protocol, you also need to know the code printed on my
pump. As a pump user, I’m satisfied by this level of
security. If someone intends to do harm to me, on a
practical level this is a rather difficult way do so. Are
there really groups of people out to do me harm using a
tiny radio to give me too much insulin? How much TV have
you been watching? The device should insure that whoever
meant to administer a drug really meant to, and at some
point had physical access to the device. I’m not sure how
much more is really reasonable. It might be nice to
change the IDs so that you can revoke someone’s access
later, but this doesn’t seem like an effective argument
for keeping the protocol proprietary.

When I walk into any given doctor’s office, their first
question is “is the pump working?”. The more experienced
the doctor, the faster they ask this question. Their
definition of “working” is quite wide, ranging from site
problems to pump software malfunctions. They generally
don’t trust the device, partially because it’s operation
is so opaque.

Obscuring the protocol from those looking to verify the
absence or presence of defects in the device, or from
effectively auditing the therapy the device provides is
dangerous. It prevents the peer review process from
building trust in this otherwise elegant technology and
puts people in the position of having to experiment
without sufficient technical details.

When I dose insulin giving the pump, it performs
calculations according to a model with many factors that
influence how much insulin is given. Anytime I take
insulin, whether or not a pump is used, I’m essentially
making a prediction about what will happen over the
subsequent hours. How much of a drug to administer is
ultimately my decision. Unfortunately, access to the logs
shaping and recording those decisions are secret, actually
hampering my ability to make better decisions, or even
communicate what happened effectively to caregivers.

Every day the protocol is kept proprietary is a day that
no one can verify that the device works without
the manufacturer’s help. For many people, despite the
software that manufacturer’s provide, this involves
spending hours reading a tiny screen over the phone, or
transcribing into another computer. In addition, it puts
users in a lurch when the company is unable to devote
enough resources to solve problems. EG, for a while it
was impossible to buy a new computer (Windows 7/Vista?)
that worked with Medtronic’s software. If the
communication protocol were open this never would have
happened.

The risk that someone might die by accidentally mis-using
the protocol is not a problem of security, it’s a problem
of adequate peer review, exaggerated by a failure to share
critical information. A user of a medical device should
never be prevented from accessing his or her own medical
data. Programming errors are solved by peer review and
test suites, not by obscurity masquerading as security.

From my perspective, the risk of reduced health outcomes
because I lack access to sufficient data is much larger
than accidentally dosing myself with buggy software. IE:
accidentally giving too much insulin because the software
I was using failed to provide enough of or the right
information to me is much more real than some hypothetical
software accidentally giving me too much insulin because
of a programming error. The risk that doctors will make a
decision because they don’t trust the device is more real
than the risk of a hypothetical programming error.

What’s really shameful is that it’s easier to download
data from my meter, which has much fewer responsibilities.
It’s easier to download data from my iphone, which has no
responsibility for my health, than it is my pump, which I
depend on every day. If I don’t trust the meter, or if
the company fails to provide a windows update, I can
download it’s diagnostic data and verify it myself.

-bewest

You’re not apocalyptic, you’re accurate! However, whether or not this information is publicly released doesn’t mean that the information isn’t being acquired in private. “Breaking” a protocol that doesn’t have some cryptographic security and authentication in place is unlikely to be very difficult. I highly doubt that some engaging discussion is going to influence that outcome.



Since the perceived risk today is low there is no regulation by the FDA or FCC on the amount of security required on wireless medical device communication. But as scrain777 mentioned, there is already industry awareness of the lack of security in many new wireless medical devices on the market. That should also be apparent by the number of people simply discussing it on this forum. In the future, the risk will rise and I’m sure the industry will eventually respond.



As far as it sounding like a bad sci-fi book/movie, imagine how easy it will be to do this once software-defined radios become commonplace. At that point you wouldn’t even have to build a radio to communicate with the device, you’d just have to load in the right software to your mobile phone to do it all. Of course, by that stage, I hope there will be no technological reasons (like lack of battery power or excessive cost) to forgo adding crypto to all devices.



Hopefully the standardization of WBAN protocols will provide vendors with some enticing options for power-efficient, secure communications.

After figuring out the protocol, if you first “listen to/sniff” a message/response exchange between the hand-held controller and the wearable insulin delivery device, then you will know the delivery device’s ID and the current messaging sequence number, as they are part of the messages. After that, on your PC/transmitter, you would build a bolus message with that pod’s ID and the correct sequence number, and send it to the delivery device.



I agree that the risk of of software bug is MUCH larger than that of a security breach, of course. But it’s still EXTREMELY small because of the MANY passes/tests/safety features that are in place in such devices.



Do you also take your car’s braking system apart and verify it before driving the car? No.
Come on, confess. You’re just a techie geek (like me) and you just have this uncontrollable urge to figure these things out. :slight_smile: Just keep the info well protected once you figure it out, which I’m sure you will.

Doctors routinely make decisions throughout therapy that
are driven by how reliable they feel the device is. They
aren’t being provided with sufficient information to make
the best decisions. The risk of making poor therapy
decisions due to a failure of a manufacturer to provide
for every possible use case (an impossible expectation) is
very real. The question is not how many people might be
harmed by hypothetical security breaches or software bugs,
but how many people have been harmed because the
manufacturer’s software doesn’t satisfy their use case or
simply failed to communicate therapy details, ie, the
known logs, effectively? If the protocol were open,
someone could at least have a chance at providing the
auditing the data that better regulates therapy. In situ,
FDA and manufacturer testing mean nothing. FWIW, at my
work we face the same question from our customers: “how do
we know it does what you say it does?”

When a patient develops problem, and the doctor spends 6
months trying to figure out what kind of problem the pump
is having, isn’t that more dangerous than a hypothetical
security breach or a hypothetical programming error?

This is an issue of ethics, not some desire to poke
around. The pancreas does an amazing job at regulating
insulin. Insulin is a powerful and dangerous drug that we
are terrible at administering. It’s amazing insulin
therapy works at all, and the amount of information I’m
given to actually drive dosing decisions vs the amount of
information available is shocking. It forces me and many
other pump users to model the interactions in our heads,
or on scratches of paper, or in spreadsheets. All of
these methods introduce opportunities for all kinds of
errors.

Just to be clear, is anyone denying that there are serious
problems with getting the right kind of information at the
right time when dosing insulin? Communicating pump
therapy data with caregivers? The forums are filled with
horror stories using all kinds of software, and the hours
of effort people go through to put together spreadsheets.
For users of Linux of Mac there are even fewer options,
and even more effort required. Even if you manage to get
everything working, you might buy a new version of Windows
that locks you out of your own data again. Meanwhile we
blindly trust the device to do the right thing, even as we
fail to fully understand the control we have over the
pump. For these people, there is a health toll paid
every day via sub-optimal or incorrect therapy decisions
made due to the lack of information and the opacity of the
device’s activity.

To this day, each time I dose insulin, the pump treats it
as a one time event, and fails to show a comprehensive
model of what might be happening. Which is more
dangerous: a hypothetical security breach, software bug, or
incorrect dosing because the device failed to communicate
the right details to me?

Since I happen to be a software engineer, I happen to have
many of the skills necessary to solve some of these
problems and unfortunately there is a real need. The idea
that the method to retrieve diagnostic information is secret
from me, the user, becomes a moral issue under this lense.
I don’t particularly want to write software formatting
bytes on a wire, I’d much rather be writing software for
my work: far more lucrative. But if there is no
software that is even capable of maintaining a simple
ascii record of therapy details, then I am left with no
choice but to provide it myself. Because I believe it’s
immoral to bar users from access to their own medical
data, it’ll be published open source once it’s working. I
just don’t view the risk of accidental or malicious harm
as seriously as the risk or poor health from poor
or misguided software.

It would be arrogant for a single company to think that it
can provide one piece of software that will work for
everyone, especially when medical devices are their core
competency. They generally acknowledge this by publishing
software requirements. The issue is that a patient should
always have access to their data; via proprietary software
or not. The idea here is that it’s dangerous to keep this
stuff secret from patients.

-bewest

PS
I’m so grateful to Gil for providing his perspective. The
devices themselves are quite elegant and so far have been
a pleasure to work with.

I don’t mean to criticize the efforts manufacturers have
put into their products, but despite being a software
engineer and having access to many computers, I’ve never
actually seen Carelink run successfully (eg, it cannot
download both my OneTouch Ultra and my pump data).
Someone recently pointed out that it might be good for
type 2 diabetics who don’t have a need for near-real-time
information. Does anyone involved in building/designing
this software actually have type 1 diabetes? Last time I
forgot my password and the password they generated for me
failed. I generated new passwords every hour for four
hours before they let me log in. Software is hard to get
right. Optimizing for slightly different use cases can
get you very different results. I also generally only use
Ubuntu inside a VM on mac, partly for security reasons,
but mostly because I love xmonad, so it’s quite an ordeal
just to get their software to run at all.

Speaking of software security and fantasies, the greatest
risk is not from some group of terrorists or saboteurs
high jacking the wireless protocol, but from internet
bandits taking over via the combination of MSIE+JAVA
holes. A bot-net is far more likely than saboteur. The
irony is that there’s more focus on IE security that
pump security. Really now, let us return to core
principles. Obscurity is not security.

I think we are working on the same concepts, but in a different format. I am looking to intercept the wireless transmissions between the different devices (In my case Dexcom, Minimed 722, Guardian RT, OneTouch Ultralink). Dexcom provides some of the details (402.142mHz, OOK modulation, Chip is a AMIS-52100M). Of course I need to determine the format that the data is being exchanged. Minimed is a 916.5mHz with OOK modulation using the TR1000 chip). I am using an Arduino board with the RFM22B module.

Jerome,

Interesting. Can you build a usb stick to talk to all of them? I’d love to help out with the format. I’ve got Minimed’s system almost figured. I believe I’m getting sequence errors, so I’m at least on the right track.

It would also be nice to build a small adapter that could fit into a meter’s data port and broadcast test results over the air.

-bewest

Yes, I believe I could build one stick to talk to them all, eventually. I am working on a presentation for a hacking conference to show the…evil things that are possible. :slight_smile: feel free to email me jay.radcliffe@gmail.com and we can compare notes.

I am interested in creating a program that graphically presents possible current BG based on insulin level, food eaten, exorcise contribution. A character/animal simulation avatar in real time would be very cool.

https://www.blackhat.com/html/bh-us-11/bh-us-11-briefings.html#Radcliffe

I’ll be speaking on this topic at Blackhat this year.

Hi Jerome,
The AADE Expo (American Association of Diabetes Educators) is during the same weekend (Aug 3 -5) in the same city (Las Vegas). http://www.diabeteseducator.org/annualmeeting/2011/index.html

By the way, Pancreum will allow for users/developers to wirelessly (or via USB) retrieve their history (glucose levels, insulin delivery, carb intake, exercise, etc) to use it in a spreadsheet, graph, etc. We’ll publish the method and API so that may be achieved. We hope that this approach will allow for multiple companies to develop and provide software solution packages in the mobile/PC/Mac that are capable to interface with the Pancreum products. The data will transmitted in an encrypted format, using a password chosen by the user.

Cheers,
Gil

Hi Jerome (Jay),

I see that you were able to hack your own diabetes management devices. Your work is all over the internet now:
“Insulin Pumps, Monitors Vulnerable to Hacking”

http://www.pharmpro.com/news/2011/08/newsletter-Insulin-Pumps-Monitors-Vulnerable-to-Hacking/

That’s why I always supported encryption, but never won those discussions at the companies I’ve previously worked for. At Pancreum I’m the decision maker, so as I mentioned on my previous post, all programming/reporting messages are encrypted.

I firmly believe in one exception: The data download/retrieval message and response will be open/public so multiple companies can create an array of graphing and analyzing software packages, for the patients’ benefit. However, that message exchange will still be encrypted, but the encryption key will be a password selected by the patient.

By the way, on the article you didn’t mention which pump and glucose meter/monitor you use, but you did here: “Dexcom, Minimed pump/GuardianRT and OneTouch Ultralink”. I’m glad you will notify them about this potential vulnerability. That’s important.

Good job at proving that point.

Cheers,
Gil

I've been searching for a group like this for years now and I'm grateful to have found it. I'm an active runner, sys admin, web developer, graphic designer, and of the past year app developer for Windows Phone 7. Since my diagnosis in 7th grade my father and I initially were controlling my diabetes regime from technology derived on a patent he owns with specific application in the oil industry and has the fantastic side effect of benefiting me as a new diabetic at the time.

For several years I averaged a 5.8-6.1 hA1c only only two injections a day (log/NPH) and at the mimimum four finger checks a day. This tech provided me a means of quite literally forecasting and predicting my dose for the upcoming day, as well as with a few test runs of the giant CGMs at the time demonstrating that blood sugar predictions 20 minutes out were possible.

I don't want to get people's hopes up, but I do want to ingrain myself in a culture that I've otherwise been searching for years now. With the recent Defcon announcement made by Radcliffe, I've been eager to construct a similar hack but closing the loop with said patent tech.

This article is a bit old, but if anyone is curious or would like to talk...well, let's do that! That's why I'm here!
http://www1.eere.energy.gov/industry/newsandevents/news_detail.html?news_id=7673

Additionally, I had my genome sequenced earlier this year to discover my chances of contracting diabetes were less than 1%

That's all for now, and I look forward to talking.
adam

Hi Adam,

If there's already a patent, and you can demonstrate this "closed-loop" algorithm working, I suggest you approach one of the insulin pump makers in the market: MiniMed (MedtronicDiabetes), Animas (Johnson & Johnson), Disetronic (Roche Diabetes), Insulet, etc.

If it's a great algorithm they may be willing to work with you, license it, etc.

Cheers,
Gil