Medical Security & Forensics / Presentations

The Autopsy of the PHOENIX X36 Hemodialysis System

I have recently received DD images of data contained in the Phoenix Hemodialysis machine. I wanted to be able to create a baseline of the information which is stored on the storage. The reason this is very important is that in DFIR we want to know what is normal to know what is abnormal. You need to be able to map the device down to the manner in which the File System stores the data on the physical media.

The device that I looked at had an MBR or Master Boot Record partitioning schema, this allows for me to be able to establish where the boot loader is located to identify the operating system which is run on it. But first, let us talk about the File System this machine had. It was running a FAT 16 file system. Now you may ask why this is important, it is important to know how the storage is partitioned and it is important to know how the files will be stored and how to manually recover data.

When I examined the boot loader I identified that the device was running VxWorks from Wind River. This is not a huge surprise due to the fact that this is the choice of the operating system on SCADA and Medical Devices. Shockingly these two types of devices follow similar trends. I wanted to understand what I was looking at and decided to read the manual. I always say when in doubt read the manual. In the manual, I found many interesting pieces of information that both thrilled me and scared me. In Hacking one the most important steps are recon. Doing your homework! In the manual, you will find how the devices are connected to Ethernet and how the device’s network capabilities are set up. You will also find the password and hard-coded IP address. As far as I could tell the device also does offer access control. (I am still examining this)

The file system and data on the device were examined. In IR we often rely on logs to give us the answers as to what occurred during a breach or misconfiguration because let us face it it is not always a Hacker. Sometimes it is a simple ID10T error, but logs will tell us this often. When looking at this device I could find data which details how it is connected and to what it was allowed to connect. As you can see during an NMAP scan the device is shown to communicate over various unencrypted and outdated channels. This surely should start moving forward. There are details on how the device is calibrated and data relating to patient protocols.

The research is still ongoing and I plan to delve into a more detailed view of the device. But currently, I do not think there is much of ability or understanding to perform Triage or Forensics on these devices. They are built for usability, they are built to last. I think that the mindset of what we are building these devices should be re-examined.

I presented this work at the local DEF CON Group 2711 to peers within the community. I am not sure if I scared or stunned them. There is good news in all of this, we are making small changes, manufacturers are working with researchers, and the FDA’s team are working hard at it too. I am fortunate to be part of I AM THE CAVALRY, which you can read more about here Thank you to Jay Radcliff for sharing the DD images with me and listening to me raving.

Also a special thank you to the girl who kicks my ass and the Wizards who motivate me to push through the pain and try and make medical devices safer for all but most importantly give us a chance to know what to do when a device is hacked.


Selaelo Ramohlale
20th October 2019 at 8:44 pm

Interesting. Being in the forensic investigation field I find myself encouraged to learn about the influences of technologies in the current world. Both in the commission and solving of crimes and transgressions. Though what I could moslty gather from my first read here is jargon to me. I look forward to more of this readings. Keep it up.

Leave a Reply

Your email address will not be published. Required fields are marked *