Firmware Security Testing for Medical Devices: What We Look For

Firmware is the software that runs directly on your device's hardware. It controls everything — from processing sensor data and managing wireless communications to enforcing access controls and applying dosage calculations. If an attacker compromises the firmware, they control the device.

This makes firmware testing one of the most critical — and most technically demanding — parts of a medical device penetration test. Here's what we look for and how we do it.

Step 1: Firmware Acquisition

Before we can analyze the firmware, we need to get it. There are several ways, and we try them all:

From the Manufacturer

The fastest path. If you provide us the firmware binary and source code as part of the engagement, we can start analysis immediately. This is the approach we recommend — it saves time and produces better results because we can do both static analysis on source and dynamic testing on the device.

From the Device's Update Mechanism

Many devices download firmware updates from a cloud server or accept updates via USB, SD card, or a companion app. We intercept or download these updates and analyze the delivery mechanism:

• Is the update file encrypted?
• Is it signed? Can we verify or bypass the signature?
• Is there a rollback protection mechanism?
• Can we create a modified update package that the device will accept?

If we can craft a malicious firmware update that the device installs without complaint, that's a critical finding.

From Flash Memory

If we can't get the firmware any other way, we extract it directly from the hardware. This involves:

• Identifying the flash memory chip on the PCB (SPI NOR, NAND, eMMC)
• Reading the chip contents using a programmer (clip-on for in-circuit reading, or desoldering the chip)
• Reassembling the firmware image from the raw dump

This approach always works, but it's time-consuming and requires physical access to the device.

Step 2: Static Analysis

Once we have the firmware binary, we analyze it without running it. This is where the bulk of vulnerability discovery happens.

Binary Reverse Engineering

We load the firmware into reverse engineering tools (Ghidra, IDA Pro, Binary Ninja) and reconstruct the program logic. We're looking for:

• Hardcoded credentials: Default passwords, API keys, encryption keys, and PINs embedded in the binary. These are more common than you'd expect, even in devices from major manufacturers.
• Insecure cryptographic implementations: Weak algorithms (DES, MD5, SHA-1), hardcoded IVs, ECB mode usage, or custom crypto that doesn't follow established standards.
• Dangerous function usage: Use of strcpy, sprintf, gets, and other functions known to cause buffer overflows. In C/C++ firmware, these are the building blocks of remote code execution vulnerabilities.
• Authentication bypass paths: Code paths that skip authentication under certain conditions — debug modes, factory reset sequences, or maintenance backdoors.

String Analysis

Simple but effective. We extract all readable strings from the firmware and look for:

• URLs and IP addresses (where does the device phone home?)
• Error messages that reveal internal architecture
• Credential fragments or default values
• Debug messages that shouldn't be in production builds
• Certificate and key material

Library and Dependency Analysis

We identify which libraries and SDKs the firmware uses and check them against known vulnerability databases. An outdated OpenSSL version, a vulnerable BLE stack, or an unpatched RTOS can be an easy entry point.

Step 3: Dynamic Analysis

Static analysis tells us what the firmware could do. Dynamic analysis tells us what it actually does when running on the device.

Runtime Debugging

If we can attach a debugger (via JTAG, SWD, or a debug stub in the firmware), we can:

• Set breakpoints on authentication functions and step through the logic
• Inspect memory at runtime to find decrypted credentials or session tokens
• Modify variables to bypass checks (e.g., setting an is_authenticated flag to true)
• Monitor function calls to understand the device's behavior under different conditions

Fuzzing

We send malformed, unexpected, or random data to the device's input interfaces and monitor for crashes, hangs, or unexpected behavior. Firmware that doesn't properly validate input is vulnerable to buffer overflows, format string attacks, and denial-of-service conditions.

We fuzz:

• Network protocol parsers (BLE GATT writes, TCP/UDP handlers, HTTP API endpoints)
• File format parsers (firmware update packages, configuration files)
• Serial protocol handlers (UART commands, SPI/I2C data)

A crash during fuzzing usually indicates a memory corruption vulnerability — which in firmware often leads to code execution.

Protocol Analysis

We capture and analyze the communication between the device and its backend, companion app, or other devices:

• Are commands sent in plaintext?
• Are commands authenticated? Can they be replayed?
• Is there a sequence number or nonce to prevent replay attacks?
• What happens if we send commands out of order?

What We Find Most Often

Hardcoded Credentials

Still the most common firmware finding across all device types. Default Wi-Fi credentials, hardcoded API tokens, and debug passwords that were supposed to be removed before production but weren't.

Missing Secure Boot

The device boots whatever firmware is on the flash chip without verifying its authenticity. An attacker who can modify the flash (via physical access or a compromised update mechanism) can make the device run arbitrary code.

Insecure Update Mechanisms

Firmware updates that aren't signed, or signed with a key that's stored in the firmware itself. Updates delivered over HTTP instead of HTTPS. No rollback protection, allowing an attacker to downgrade to a version with known vulnerabilities.

Debug Code in Production

Logging functions that write sensitive data to serial output. Debug commands that bypass authentication. Test modes that disable security features. Manufacturing test interfaces that were never removed.

Memory Safety Issues

Buffer overflows, use-after-free, and integer overflow vulnerabilities in C/C++ code that handles external input. In firmware running without memory protection (no ASLR, no DEP, no stack canaries), these vulnerabilities are often directly exploitable.

Why Firmware Testing Matters for FDA Submission

The FDA's premarket cybersecurity guidance explicitly expects manufacturers to address firmware security. Specifically:

• Evidence that firmware integrity is protected (secure boot, code signing)
• Documentation of how firmware updates are authenticated and delivered securely
• Penetration testing results that cover the firmware attack surface
• A plan for addressing firmware vulnerabilities discovered post-market

If your penetration test doesn't include firmware analysis, your submission has a gap that FDA reviewers will likely catch.

Source Code vs. Binary-Only Testing

We can test firmware with or without source code, but source code access produces significantly better results:

With source code: We can identify vulnerabilities faster, provide exact file and line number references in our remediation guidance, and catch subtle logic errors that are difficult to find through binary analysis alone.

Without source code: We rely on reverse engineering, which is slower and may miss vulnerabilities that are only apparent in the source. Our findings will reference memory addresses and disassembly rather than source code locations.

We always recommend providing source code. It's covered under the confidentiality terms of our engagement and results in a more thorough assessment with more actionable remediation guidance.