Why Do A Medical Device Assessment, Part 5: Cracked Wide Open

Device Assessment

Why Do A Medical Device Assessment, Part 5: Cracked Wide Open


This is final post of a five-part series on the what, why, and how we inspect medical devices.

In the previous installments, I talked about why we inspect devices, the mindset that guides our workflow, started showing you aspects of the user interface, and how the administrative functions could be accessed and used.

In this post, we crack open the box so we can talk nerdy hardware hacking techniques.

The Main Attraction

Alright, after all that, let’s finally see what’s in this thing.

When inspecting a device, we tend to look for any hardware safety features, such as special screws, anti-tamper indicators (say, a sticker, or paint), or even kill switches.

This device uses Torx screws for the case. Some Torx screws have a pin in the center, requiring a special bit, but this one didn’t.

No, I don’t have a collection of lock picks and special security bits. For this device, since I wasn’t at the lab, I picked up a screwdriver with the right bit sizes (like this one bottom right in the image above) at Home Depot.

We removed the battery, undid the case screws, disconnected a few internal cables, and we’re in!

Guts and Glory

Normally, we’d splay open the device, laying out the components in a way we can connect them to our instruments and power supply, and inspect them as they work. As I wasn’t in the lab for this disassembly, and we’re just taking a look, I’m not showing this for this device.

Keep in mind, we talk to the client before deciding how much we will deconstruct the hardware. And if we are destructive, that would occur at the end of the inspection, so that we don’t have to return to the customer for another device to complete the tests.

In the below image we show the back case with the ethernet card (red box on left) and power card (red box on right).

The next image shows the inside of the front panel of the device. Those tubes are for the pressure cuff (upper red box). There’s a small card with the pumps.

That other card (bottom red box) is the pulseox card.

When looking at device boards, we look for any programming ports, what’s communicating with what, and try to understand the chips used.

Pulseox Card and Chip

For example, the next images show close ups of the pulseox card. Front on the left, back on the right.

I must say, to my eye, I couldn’t find any programming port exposed. Indeed, I wasn’t finding any obvious one anywhere in this machine. In this case, to find such a programing port, I’d pull out a logic probe, oscilloscope, or multimeter to look for signals. We could also follow traces, or image the board to look for them in a more rigorous way.

What I did do, was identify the main chip on the pulseox board (that red box on left). Helps that it’s the largest one on the board.

Reading the chip, we can look up the manufacturer page for what it does, what the pins do, and how it’s programmed.

For example, this is an ARM chip from Microchip. The chip’s data sheet tells us the various programming pins and how to put the chip into various modes.

Tapping into the programming pins, we can observe the startup sequence, figure out what the bootloader is doing, and learn which OS is being used.

Knowing the OS, we can figure out how the OS was secured and such, verify the security controls, and understand the known vulnerabilities.

Ideally, we’d like to step in and take control of the device and communications, and perhaps get root access for more analysis. We also want to understand how the chip communicates with the rest of the board.

If we are really diving deep, we could lift the machine code and reverse engineer the software on the chip, butno, not for this series. We didn’t go that deep. Next time, perhaps.

Main Board

On to the main board, here it is with the pressure cuff board and the pulseox board removed.

Front on the left, and back on the right. The flex cable highlighted at top of both images is to connect to the LCD screen.

The big chip to the upper right of the left image is the main processing chip, it seems.

If I’m not mistaken, the machine is already old, I think first released around 2008 (yes, medical devices stick around for a long time). And this chip is from the mid-2000s.

The chip is still available for sale, though. Perhaps one can buy the chip and learn off-machine how to build software and how to exploit?

On the front side of the main board, there is a second chip.

Removing the manufacturer’s label, we can find out that this one likely does all the heavy math for the pulseox and pressure cuff calculations. Could we affect the code so that the calculations are off?

On the back of the main board, under the FPGA are two RAM chips.

Removing the manufacturer’s label, we see that these are volatile, meaning they lose data when powered off. But there are some versions of memories that are more permanent, and data or code can be lifted from them.

With this machine, because it’s so easy to pull data from the UI, futzing with the chips is probably unnecessary.

Time to Report

And that’s it for our investigation of the brain and guts of the device.

So what *did* we learn?

In this series, we brought you along for a tour of a patient monitor, as we inspected the interface and the hardware. Along the way, we showed you how we inspect a medical device, looking for potential routes of compromise, and we began thinking of ways to build alternate controls around such a device. Also, we discussed some design decisions and how they might affect the security profile of such a device.

With this device, on the user interface side, we found places that were weakly or not protected where a malicious actor could disrupt or exploit the device – especially where they could make changes to settings and operations that were not protected by authentication.

On the hardware side, we discussed methods of gaining insight into the hardware and firmware by showing some of the main chips on this machine and how the hardware might be investigated for exploits and reprogramming.

Thank You

That concludes our tour.

Thank you for reading this series. Let me know if you have any questions or comments to share.

If you’re interested in learning more about our device inspection service, feel free to contact us in the chat box below or through the form at the bottom of our healthcare pages.

Charlie Schick Healthcare Consultant

Why Do A Medical Device Assessment, Part 4: Access Granted

In the last post, we got up close and personal with the device, and now it was time to really try to dig into the administrative functions. While the unauthenticated (non-password-protect...
October 29, 2020
Charlie Schick Healthcare Consultant

Why Do A Medical Device Assessment, Part 3: The Device

In the previous two posts in this series, I talked about the reasons cybersecurity analysis on medical devices is necessary and some processes behind device analysis. In the next coupl...
October 21, 2020