Hello, everyone, and welcome to my talk, Breathless, A Tall Tale of a CPAP Machine.
For those that don't know me, I am Vee, but a little bit more about myself.
I'm an assistant professor in Norway, specifically in digital forensics and incident response.
I'm a very proud cyborg with a long-standing implant since 19.
I did digital forensics and incident response for a long time, still doing it.
I do cyber threat intelligence.
I also like to do some OSINT and find information specifically about medical devices that I'm looking at.
There is a wealth of information out there.
I'm also very passionate about patient rights, specifically being a patient myself, advocating for those that don't have a voice or feel they don't have a voice.
That's currently what I'm doing a lot of in Norway is physician education.
Now, I'm also a proud mom of two little girls, albeit not that little girl, no, that little anymore, but they are absolutely kick-ass, and they will soon be presenting one day similar work that mom does.
Now, what exactly are we going to be talking about today?
Well, the foundation of how I look at medical devices is looking at it by using my scientific process, which is medical device forensics.
This is made up and visualized in a triangle.
A triangle is one of the strongest engineering shapes there is.
I realized that looking at a medical device, I couldn't just look with one lens.
I had to look through multiple lenses to get a holistic picture of what was happening on the device.
Firstly, I wanted to know how it worked mechanically, how it functioned, and that I had to go through a process of debugging.
I had to understand and learn how it works, and that kind of falls into the components of medical device engineering, which every manufacturer will be very familiar with.
Now, also, digital forensic scientific process is one that I've used, and that is kind of, I preserve the information on there.
I examine it.
I analyze it.
I reconstruct a sequence of events.
But I also match that up with, you know, knowing how the device works.
If I know how the device works, and what underlying file systems it has, and how the data is organized, I can anticipate where I will find my forensic evidence.
Now, I also look at the clinical data.
Can I visualize the clinical data as the physician or the doctor would see it?
How does that correlate with the timeline that I had?
How does it correlate with the functioning of the device?
So, kind of bringing it all together to have that whole holistic view of what exactly took place on the device.
Now, I, you know, when I teach this to my students, and when we do the whole medical device forensic class, they're like, but why a CPAP machine?
Now, I'll tell you shortly, but it comes down to the fact that there's about 50 to 70 million people around the world that's been diagnosed with obstructive sleep apnea, or otherwise OSA.
So, it's quite a lot of people that have potentially got a device like a CPAP or a BiPAP that they use every night, every time they go lie down to have a nap.
Now, the sleep economy is 432 million US dollars the last time I looked.
The global market share is 81 billion US dollars.
But those things aside is not the most important thing for me.
My dad has been using his device for a few years now.
And I wanted to know when he initially got the device, how was it functioning?
What was it recording?
You know, how do I know it's working?
How do I trust implicitly in this device?
And he kindly let me look at his device in a non-destructive manner.
So, this whole analysis was done using digital forensic mechanisms that doesn't need to open the device at all.
Now, once you have preserved the evidence or looked at the evidence on the CPAP machine, you'll see that it makes use of a standard EDF file.
Now, EDF files are generally used to record medical signals.
So, they are used in sleep studies largely to see, you know, to record brain signals and how was the patient sleeping?
Was his eyes open?
Was it closed?
Was there any, you know, events where he stopped breathing?
So, this is quite a very standard medical format.
And it's also very well documented.
But the best thing about EDF files is that it's actually in printable US ASCII.
So, you can actually read some of the data with just something like a hex editor, plain and simple.
Now, a signal in an EDF data record is a series of two-byte samples.
These subsequent samples represent integer values of the signals which have been sampled with an equal time interval.
So, these signals are kind of what helps us visualize was the patient breathing?
Was the machine responding?
Was there any events?
But I'll get into the kind of signals and annotations you find on these files a little later.
An EDF file is also super flexible.
It allows for exchange and storage.
It's very simple to use and simple to write to.
Some fun trivia about the EDF file is it was developed at a sleep congress in 1987.
So, it is as old as I am.
EDF+, which was slightly better, was developed in 2002.
Now, let's look at some of the specifications.
And this is not all of them.
This is just the highlight of some of the interesting ones.
Now, the start date and start time fields in the header will only contain characters from 0 to 9 separated by a period value.
So, you could use regex to actually search through the files to find these relevant samples or relevant values.
There's also a local patient identification.
However, this is not always there because this is set up by the technician.
So, it depends on how the machine has been set up.
Now, I know it depends is pretty much a forensic term that we use because there's so many variables.
It's not guaranteed that you'll have all the information that I present today in an EDF file on your machine.
Now, it also includes the birth date of the patient in a day, day, month, month, year, year format.
This machine was a South African machine.
So, quite possibly this could change depending on your region the machine was bought from.
I'm thinking specifically in the US.
So, these are kinds of very important because this is how we correlate evidence and timelines is using these specific values.
Now, if we look at this, this is an ASCII translation table to give you an idea of how you can actually parse out the header file.
As you can see, there is a start date.
There's a local recording identification.
This table is freely available.
There are resources to it.
But this was just to give you an idea of actually, you know, how looking into data-driven analytics processes, because this is how I came to this information, allowed me to actually look at the files in the raw format and identify quite quickly if there was any,
you know, sequences that were out according to the local recording times because those are supposed to flow.
Now, if a patient didn't use it for one evening, there would be a gap in the date and time.
Now, I looked at two devices because my dad had one device and then ultimately upgraded.
This is not a reflection on the manufacturer at all.
This, it wasn't looking at vulnerabilities.
I was simply looking at can I do forensics on the device?
Can I actually learn from the data?
Can I marry the engineering with the forensics with the clinical side of things?
Now, more about the device.
The ResMed AirSense 10 machine collects quite a lot of statistics and quite a lot of interesting statistics.
It has an AHI index, pressure and leak usage.
Now, the machine allows a patient to sleep more comfortably because it keeps the airways open, positive airway, by actually high pressure air that goes in.
Now, how they monitor whether a patient is using the device is that they actually record specific statistics that get sent away to the doctor.
So, this device has the capabilities to actually send data out and be connected to a network.
It depends on the geographical location.
In South Africa, this is not very much used where the data doesn't get sent to the doctor.
Now, let's look a little bit at the different kind of signals or the different kinds of things that the CPAP machine records.
Now, the first one we're going to look at is AHI signals.
Now, these are recordings of the number of hypopneas or times you stopped breathing has been recorded.
And these are done by an hour-by-hour basis.
Now, the AHI index is one of those that I quite frequently used in the CPAP scenarios to actually determine the overall sleeping health of the patient.
This is a severity rating of how bad the patient's sleep is, how many events they have, how well treatment is working.
It's also an indication whether there is more clinical need for an adjustment to the machine.
Now, the AHI signals has got forensic clinical value because it indicates the overall sleep health of the person, specifically looking at hour-by-hour basis, how many times the patient stopped breathing, overall using the mathematical equation to determine what the index is about how bad your overall sleep health is.
So this is quite an important signal that I looked at to determine whether or not my dad was actually improving or not improving.
Now, the CPAP pressure setting, this is a fixed pressure setting.
Now, it's also very important to know that there is a maximum pressure that a human being can take.
So there are recommendations for the devices not to go over that.
Now, if you go look at the machine itself, you will see that it's a very patient-specific setting.
There will be a high and there will be a low setting, meaning that they may be different from day to night.
You might have a higher requirement for pressure in the night versus during the day.
Now, this is recorded in a file that's called a .brp file.
This is also known as the high-resolution graph data.
And this value will change as the device is used because it basically is alternated.
Now, for example, if we look at this, this is from my dad.
And yes, I have permission to show you this data.
Also, this is very old data.
It's not his latest one.
If we looked at these two kind of things, we have the statistics on the left and we have the device settings.
Now, the minimum pressure rate is 6.4 versus the maximum that is 14.
Now, that is well within the range of what a human being can safely use.
However, if you look at on the left-hand side, you see the values fluctuate a little bit.
And this is how the device is responding to his different needs.
So, the one value, the statistics, is how the device has been used.
And then you have the device settings.
Now, why does this match to us in forensics?
Well, if we know what the clinical setting is supposed to be, we can correlate that the device is set to that.
Any deviation from that would need to be further investigated as to why it was changed.
Also, with the statistics, you can correlate that the device is responding within those parameters and not exceeding them.
If you look at the FDA's database about where a patient complains specifically about medical devices, where physicians also can complain, there were other manufacturers that had problems with pressure being far exceeding what was safe.
And patients had adverse reactions.
So, adverse reactions do occur in these devices.
I'm not aware of any in this specific one.
And I could correlate with my dad's data that he was receiving what was programmed and what was appropriate for his needs.
Now, it also has a leak.
Now, everyone will say, well, it's not supposed to be leaking.
But there is some normal leak, you know, air leak expected with these devices.
Now, the ResMed AirSense 10 has a built-in leak differential within the mask.
It also has the ability to actually indicate whether, you know, the mask is properly used or not.
Now, if this value is exceedingly high, there could be two potential issues.
One could be there is a device fault, that there is such a big leak, or it's just an improper mask fitting.
And these are things that you would investigate if a patient came to you and said, well, you know, I'm not getting adequate treatment.
If you looked at a CPAP leak and you see that it's far exceeding what the manufacturer states in their manuals, you would firstly look into how the mask is fitted, and see if the patient's got it right, if the mask needs to be replaced, or whether it's actually a device fault.
Now, as I said, some leak is normal, and every device on the market has their own threshold, and this is contained in their manuals.
Now, this is also used to calculate by, you know, how long the mask was worn, and normally measured in litres per minute.
And this you will also find in the clinical representation a little bit later.
Now, this is also how they use it, they use measurements for compliance purposes, to send it away to the physician to see whether or not the device is used adequately, properly, and correctly.
So this is kind of how they monitor patients' usage of the device.
Now, once we have done understanding around what the device records, what the data is like, I like to look at the partitioning schema and file system, because this is actually where it becomes known to us, this is where we recognize things a little bit more.
A little secret that I've learned is medical devices are nothing weirder than what we are used to in digital forensics and incident response.
They are slightly different, but at a fundamental level, there are similarities between systems we know versus medical devices.
Now, this specific one had a master boot record with a single partition on, which was a FAB32.
There was no volume label set for this specific one, but there was a serial number.
The recordings of the data was in Big Endian, so I can already anticipate kind of what kind of hardware it is, because there's specific hardware that works with, and systems that work with Big Endian.
But it's important to know that, you know, the Big Endian is what is used, because that, when it comes to your date and time formats, it depends on how you will read the hexadecimal values.
Little Endian versus Big Endian.
So this was kind of an important thing, because I didn't fully anticipate that it would be Big Endian.
I kind of thought it would be little, but this was quite a surprise for me.
And now, if we looked at the folder structure, and like I said, this was a non-destructive way of looking at the data recorded on the SD card of the machine.
I haven't opened the machine yet, because at that time, it was under warranty, and it was actively used by my dad, so I didn't really want to go mess with things to a large extent.
Now, if we looked at, logically, at the SD card after we've imaged and mounted it, to understand what was on it, there was some files and folders, and these are kind of uniform across the ResMed range.
Now we have a data log folder, we have an identification.crc, identification.tgt, journal.dat, sdr.crc, sdr.edf.
Now, the crc values are that of its associated file.
I'm not going to go into all of them.
I'm only going to highlight the most important.
If you want to know more about the in-depth analysis of each of these components, feel free to reach out to me, and we can have a discussion about it.
But I'm a little bit short on time.
Now, the data log folder contains high-resolution graph data records, and it's information about the airflow of the device.
It also contains annotations and notes, whether or not events have taken place.
Now, if an event has taken place, it is recorded in a .eve file, which is the events file.
Now, this is an annotation that is used to determine whether the patient suffered any attacks like hypopnea, apnea, obstructive apnea, or central apnea.
So it kind of is about, you know, is there any adverse events that was noted and that the machine responded to.
Each session is split across four .edf files, and these are different files that contain different annotations.
The file names are generated by date, type, and type of recording, and then followed by the .edf extension.
So you would have .eve files, you will have .bpd files, because they contain different information.
There is also a CRC checksum generated for each of the files.
Now, this is an example of a high-resolution graph data, and it tells us more about the airflow, as well as events that have taken place.
But this doesn't tell us much in terms of just looking at it like this, but I will show you how to visualize it better.
Now, str.edf was another one that was very interesting.
This is the file that contains the values for the HI index.
And as I said earlier, this is a very important thing, because we want to know what the overall sleep health of a patient potentially is.
And the way that we know that is by looking at the str.edf file.
It's updated at the end of every session, but most records only contain one entry per day, because it's at the end of the session.
And theoretically, most patients generally use this during the night, because they're not sleeping during the day.
This file can also be used as a summary of the recorded sessions for the day.
But it's important to know that there will only be mostly one, and it would be an overall HI index of how the patient is at the end of the sessions.
Now, another interesting thing that I wanted to look at is, well, what happens if I actually factory reset the device?
What happens, you know, how's the data retained?
And the SN10 has multiple processes that it goes through to erase all data, and it has some data retention policies or things in place.
It kind of looks like it is just a high level format.
So what I did was actually, you know, backup my dad's data, factory reset the device, and then look at whether or not I can actually retain, you know, recover some data.
But the overall data retention rules are your BRP data is continuously erased every seven days.
And this is important in digital forensics to understand what data is erased.
And when I say erased, I mean that it is made unallocated so that the file system can overwrite that value.
So there is still the potential to recover files if it hasn't been overwritten yet.
So the quicker you do a forensic acquisition of a potential device, the better off you are to recover data.
Obviously, the longer time goes past, the more difficult it gets.
Now, PLD data is continuously deleted every 30 minutes.
So this will be much harder to recover versus that of seven days.
Now, SAD and EVE files are retained for 365 days.
Now, these are your events and airflow files.
So these are, in my opinion, the most important ones to look at.
And luckily for us, they don't get deleted.
Obviously, this is on an SD card, so it runs the risk of actually filling up.
But it takes quite long because these files are quite small.
Now, when I looked at the manual for the Essence 10 device about how to factory reset it, it is simply a quick format.
It formats the SD card.
And if you've done digital forensics, you know that there's a large chance on FAT32 that you'll be able to recover the files.
When examining the unallocated space for one thing, you can actually look for EDA file signatures, which you can see below.
And you can go search and recover for those files.
Now, because this is a FAT32 file system, it allows for us to use normal digital forensic techniques we would have used to retrain a FAT or to go look for files that have been marked with hexadecimal 0XE5, which is how directory entries are marked as deleted.
Now, those can be reversed if the data is intact.
So you can do data recovery on these devices just because of the file system that's on there.
And I think this is one of the things people don't expect with medical devices is that it actually follows rules of data storage of file systems we know.
Now, I did note that there were some inconsistencies.
The deleted file directory entries, when I examined them to determine the information that could be, you know, distinguished or I could understand, there were some inconsistencies with regards to dates and times which were recorded in the directory entries.
This was anticipated just because of it being a medical device.
Sometimes it throws in a loop or it throws in a surprise.
Now, the creation date for the deleted files is no longer reflected, but it is rather overwritten with a set value of hexadecimal 0X00, 0X32.
And this is recorded at the offset hexadecimal 0X10 in the directory entry.
However, the timestamp remains intact.
So the creation date is overwritten.
Now, the last access date in the offset hexadecimal 0X12 is overwritten with the value 0X00, 0X31.
But the timestamp remains intact.
And so it carries on.
It seems that the dates are rather overwritten versus the timestamps that are still in the files.
Now, the creation date and time corresponds to the file name, as the file name is made up of year, year, month, month, date, date, and so forth.
So you can still identify the creation time, but it becomes a little bit harder with the last date access, which could be a very crucial piece of information to see whether something has been tampered with or not.
However, just looking at the file name, you can find the creation date and time again.
I am not entirely sure yet why it overrides the information in directory entries, or whether this is an accidental override, or whether this is intentional.
This could be potentially an undocumented side effect of the methods that are used to delete data from the SD card.
I am still investigating this and trying to examine different hypotheses as to why this is happening.
The modified date and times are noted and accurate based upon the last time the machine recorded and accessed that file during therapy.
So it's very hard at this point to understand why that has happened, but it is something that I'm currently testing further.
Now, EDF files you can look with Hex Editor, or you can actually use some Python.
Now, the way that I found this was quite accidental because I found EDF files in big, large data analytic studies, specifically about sleep studies.
And I found that they were using Python to actually parse this information.
So I thought, well, surely I can use this to look at the EDF files of my dad.
And one of the libraries that I used was pyedflib, which allowed me to actually read or actually write to files if I wanted to.
And it gave me information about who the patient was, the start date, time of the file, and what signal labels was recorded.
So not quite a lot in terms of what I wanted to have.
So I further researched and I found EDF-RD, which was the one that we used in my course.
And this is something that was designed in 2000, that was specifically to read and write EDF files.
It's a very low-level library and it's very easy to use.
I mean, after all, I used it and so did others.
It's very easy to extract the information.
I could get the patient name, the start date, start time, and number of data records that was recorded, which allowed me to anticipate, you know, what kind of files was on the SD card.
These are some examples just of the code.
As you can see, it's very simple and it allowed me to get quick and dirty information about the EDF files recorded on the ResNet machine.
But I wanted to find out how do I visualize the technical aspect.
I've now looked at the engineering side of things, how the device functions.
I have looked at what's contained in the EDF files.
I've looked at the file system, but I wanted to visualize the sleep data.
Now, in comes OSCQR, which is an open source CPAP program that is used by this, you know, the community that does have CPAP.
And it's quite amazing what you find in the information that they're willing to share.
Now, OSCQR stands for the Open Source CPAP Analysis Reporting.
Now, I had a forensic image, a DD file containing all the information from the SD card, but how this device functions is that you need to plug in the SD card and then it will automatically import the files.
So how I got around this little thing is I actually mounted the forensic image as a removable drive and then import the information into OSCQR to determine whether what I found in the raw data and the digital forensic side of things was actually matching up visually with what was happening.
Now, if you look at this on the left-hand side, we see an AHI index of 0.26.
We see more about the kind of events that were suffered.
We see statistics and we see the machine settings.
Now, on the right-hand side, these are visualized in a graph .
But at this point, you know, it doesn't make quite a lot of sense, but you can actually correlate data.
Now, if we look at where the orange square is, you will see that there was an event that was noted.
The flow rate was increased for the device.
The pressure was constant, but the leak rate was quite high, which could indicate the therapy was applied, as well as the flow limit.
So you can actually correlate across whether the device, whether one, events taken place, whether the machine appropriately responded, and whether the patient received treatment.
Now, you'll also see that if we look at this, there was an obstructive event where my dad struggled to breathe.
And we can see that it's recorded and that he received constant treatment or positive airway.
So you can correlate the information.
Now, we see that there was large leaks here that was happening.
This is not due to machine failure.
This was due to him not having his mask on correctly.
But knowing that this was occurring, we were actually able to get the mask fitted properly.
We have some obstructive events that have taken place.
So this quite tells you when something has happened, whether the machine has responded appropriately.
And you can correlate these things around the device.
So it's a very nice way of visualizing the information.
And as a patient, understanding your treatment and understanding whether or not you are improving and taking, you know, and being clinically supported as you should.
Now, the statistics on the device contains quite a lot of information.
It contains machine information when it was last used, when it was first used.
And this is kind of important information to just understand the overall view of the device.
Now, future work.
My dad has obtained a secondhand CPAP machine for me because he's amazing and awesome.
He doesn't think that I'm completely weird.
I will be taking apart this machine to forensically acquire the machine as well and then correlate the final piece of the puzzle.
My first attempt was just to look at the data from a non-destructive way.
So stay tuned for future talks on looking at the device versus just the information that's recorded.
A special thanks specifically to the Biohack Village, my home away from home.
I am missing you all dearly this year.
Nina, looking at you for all the support you've given me through the years.
You've been amazing.
Jay Radcliffe that actually piqued my interest into CPAP machines by giving me a image a few years ago that has led me down this path to want to look at this more.
And then my dad for not, you know, thinking that I'm completely crazy and weird and supporting the research.
I hope you enjoyed it.
If you have any questions, feel free to reach out to me and I will happily have a conversation with you and point you in the right direction.
If you want to know more about the resources, you can look here and find them.
Thank you again for having me and I hope you enjoyed it.