IoT Penetration Testing: From Hardware to Firmware

As Internet of Things (IoT) devices continue to permeate every aspect of modern life, homes, offices, factories, vehicles, their attack surfaces have become increasingly attractive to adversaries. The challenge with testing IoT systems lies in their complexity: these devices often combine physical interfaces, embedded firmware, network services, web applications, and companion mobile apps into a single tightly coupled system.

This article presents a structured methodology for IoT penetration testing. It outlines the layered approach needed to identify vulnerabilities across hardware, firmware, and software, using both static and dynamic analysis. While each device presents unique challenges, this methodology provides a practical framework to guide testing in a controlled, ethical, and effective manner.

1. Hardware Analysis

The hardware analysis phase is the foundation of any IoT security assessment. It begins with a careful physical inspection of the device to understand its construction and layout. Opening the enclosure, ideally without damaging the casing, reveals the printed circuit board (PCB), which often includes accessible components such as microcontrollers, memory chips, power regulators, and various communication interfaces. Identifying the main processor and supporting chips helps determine the device’s architecture and capabilities, which is critical for later steps like firmware analysis or emulation.

Common targets include:

• UART or JTAG debug headers
• SPI/I²C flash chips
• Test pads or unpopulated pin headers

Once the board is exposed, the focus shifts to locating debug interfaces and data lines that may allow deeper access to the system. These typically include unpopulated headers or labeled test points for UART, JTAG, SPI, or I²C. A multimeter can be used to trace power and ground, while a logic analyzer can help confirm signal activity and pin function. In many cases, manufacturers leave these interfaces enabled for development and never disable them in production models, making them prime targets for hardware-level access. Identifying and understanding these pathways can often circumvent software-level protections entirely.

Serial Communication Analysis

Serial communication is a simple, low-level method for transmitting data between electronic components, often used for debugging or interacting with embedded systems during development. In IoT devices, it commonly takes the form of UART (Universal Asynchronous Receiver/Transmitter), a protocol that transmits data one bit at a time over a pair of lines, typically labeled TX and RX. Manufacturers use UART interfaces to monitor boot logs, configure low-level parameters, or gain shell access to the operating system during production or testing.

For security researchers, discovering an active UART interface on a device can provide a direct window into the underlying system. Once located, often through visual inspection of test pads, pin headers, or silkscreen labels, the interface can be accessed using USB-to-TTL adapters connected to a terminal emulator such as minicom or screen. Baud rate and other communication settings are usually determined by trial and error. If the UART interface is unprotected, it may expose bootloader messages, kernel logs, or even a fully interactive shell, depending on how the manufacturer has configured access.

Access to these serial interfaces can enable a wide range of attack vectors. In some cases, a UART shell may bypass higher-level authentication mechanisms entirely, allowing root-level control of the system without needing to exploit software vulnerabilities. It can also reveal detailed information about the device’s initialization sequence, filesystem structure, or firmware integrity checks. Even when password-protected, the serial output alone may leak sensitive information useful for further analysis, such as hardcoded credentials, debug flags, or network configuration parameters.

Firmware Extraction and Analysis

vulnerable packages bundled with the system. By correlating file versions and binary hashes with public vulnerability databases, testers can determine whether the device is affected by known CVEs. This type of dependency mapping is especially useful for devices based on embedded Linux distributions, where a single outdated component, such as OpenSSL or BusyBox, can introduce critical vulnerabilities across the entire system.

There are various ways to acquire the firmware from an IoT device, such as:

• Vendor support websites
• Over-the-air (OTA) updates
• Direct dumping from flash memory
• Device backups or companion apps

Once obtained, firmware is typically unpacked using binwalk, which identifies embedded filesystems such as SquashFS, JFFS2, or CramFS. Tools like Firmware-Mod-Kit, binwalk -e, and unsquashfs help extract and analyze contents.

Key analysis steps:

• Locate default credentials and API keys
• Identify vulnerable binaries or initialization scripts
• Map service dependencies
• Search for hardcoded IPs, certificates, or debug flags

Flash Memory Dumping

Extracting data directly from flash memory is often necessary when firmware images are not publicly available or when a more complete image of the system is required. Many IoT devices use SPI-based NOR or NAND flash chips to store bootloaders, kernel images, root filesystems, and user data. These chips are typically surface-mounted on the PCB, requiring careful soldering or the use of test clips to establish a reliable connection for reading. Once connected, tools like flashrom or dedicated programmers such as the CH341A allow for a raw memory dump to be captured for analysis.

However, the process doesn’t end with obtaining the raw image. Flash memory is usually partitioned into multiple regions, bootloader, kernel, filesystem, configuration data, and identifying these boundaries is essential. This can involve manually inspecting the image for known filesystem headers or using utilities like binwalk with custom signatures to parse the layout. In some cases, configuration data such as Wi-Fi credentials, cloud tokens, or even plaintext user passwords are stored in dedicated partitions or unprotected regions. Moreover, by analyzing the full image, it’s often possible to recover deleted files, system logs, or previous configurations that were not properly erased, providing a richer and more accurate view of the device’s operational history and potential security flaws.

Network Services Enumeration

Once the IoT device is connected to a test network, analyzing its exposed network services provides crucial insight into potential attack vectors. Many devices run outdated or insecure services, often enabled by default and bound to all interfaces. Services such as Telnet, FTP, or custom TCP daemons may be accessible with default credentials or no authentication at all, exposing the device to immediate compromise. Even when secure services like SSH or HTTPS are present, misconfigurations such as weak cipher suites, expired certificates, or lack of rate limiting can degrade their security posture.

An effective enumeration process goes beyond identifying open ports. It also involves analyzing how the device communicates over time. By capturing traffic during boot or during normal user interaction, patterns can emerge, such as undocumented APIs, use of broadcast protocols, or connections to third-party cloud services. Passive network monitoring can reveal DNS queries to hardcoded domains, periodic data exfiltration, or insecure firmware update checks. These behaviors are particularly important for detecting privacy violations or embedded backdoors that may not be evident through static analysis alone. Network services often act as the first point of contact between the device and the outside world, making their security a critical part of the overall assessment.

Standard recon tools include:

• nmap for port scanning and service detection
• nikto for initial vulnerability scanning
• masscan for large-scale port sweeps
• tcpdump or Wireshark for packet inspection
• dirb or dirrbuster for enumerating web directories
• burpsuite for analyzing web requests and responses

The goal is to map the device’s communication behavior and assess externally accessible attack surfaces.

Web Application Security

Web interfaces are a common feature of IoT devices, especially those designed for home or small office environments. These interfaces typically provide configuration dashboards, device status pages, user management, and firmware update functionality. Unfortunately, many of them are developed with minimal security considerations and contain vulnerabilities that mirror those found in early-stage web applications, including improper input validation, poor session management, and inadequate access control.

Many IoT devices expose web interfaces used for administration. These are frequently prone to classic web vulnerabilities, including:

• Cross-site scripting (XSS)
• Command injection/Remote Code Execution
• Authentication bypass
• Insecure file uploads
• Local file inclusion (LFI)
• Remote file inclusion (RFI)

A significant aspect of assessing web application security in IoT devices involves understanding how the interface behaves under different authentication states and privilege levels. It is not uncommon to find administrative endpoints exposed to unauthenticated users, or debug pages hidden behind predictable URLs. Because these applications often rely on lightweight or outdated web servers, such as httpd or uhttpd, they may also lack modern protections like CSRF tokens, secure cookie flags, or input sanitization routines. Furthermore, since many IoT web apps are written in CGI scripts, shell commands may be constructed dynamically, making them particularly susceptible to injection vulnerabilities. Observing the logic and flow of these interfaces can reveal serious flaws that allow full system compromise from a remote perspective.

Mobile Application Interaction

Many IoT devices rely heavily on mobile applications to provide user-friendly interfaces for configuration, monitoring, and control. These apps act as intermediaries between users and the underlying hardware, often exposing significant portions of the device’s functionality through APIs. By analyzing the mobile application, testers can gain visibility into how the app communicates with the device or its cloud backend, which is often more revealing than probing the device directly.

A common first step with Android apps involves decompiling the Android application package (APK) using tools like JADX or apktool to inspect the app’s internal logic, hardcoded values, and references to external services. Static analysis frequently uncovers sensitive data such as API keys, access tokens, debug logs, or embedded firmware update URLs. These artifacts can lead to privilege escalation, bypass of device authentication mechanisms, or replay of critical commands over insecure channels.

Beyond static analysis, dynamic testing of the app in a controlled environment can yield further insight. Running the app within an emulator or on a rooted device while intercepting network traffic allows for inspection and manipulation of requests sent to the IoT device or associated cloud services. This reveals whether encryption is properly enforced, whether sessions are securely maintained, and whether user inputs are validated before being relayed to the hardware. Additionally, the use of dynamic instrumentation tools such as Frida or Xposed Framework makes it possible to hook into app functions at runtime, bypass root detection, alter behavior, or observe the flow of sensitive data, all of which contribute to a more thorough security assessment of the device ecosystem.

Reverse Engineering Firmware

Reverse engineering plays a pivotal role in understanding the inner workings of proprietary IoT firmware, especially when no source code is available. Once binaries are extracted from a firmware image, they can be analyzed to uncover how various services operate, how authentication is handled, and whether unsafe or outdated libraries are being used.

Tools like Ghidra, IDA Pro, or Radare2 are used to analyze compiled binaries. Key goals include:

• Identifying unsafe function calls (system, strcpy, etc.)
• Discovering hardcoded credentials or API secrets
• Reverse engineering custom protocols or authentication schemes

The process typically begins by loading ELF binaries or stripped executables into disassembly tools such as Ghidra, IDA Pro, or Radare2. These platforms allow security researchers to explore functions, inspect memory references, and analyze control flow. Even in the absence of symbols or debugging information, patterns like string references, syscall usage, or recognizable function prologues can provide valuable insight into the binary’s purpose and behavior.

Through careful inspection, it’s often possible to identify vulnerable function calls, such as unsafe memory operations or command execution routines. Embedded credentials, encryption keys, and undocumented administrative functions may also surface during analysis. In some cases, the binary reveals internal API endpoints or communication protocols used by mobile apps or the web interface. This knowledge can then inform targeted dynamic testing or fuzzing.

Another important aspect of reverse engineering involves examining how binaries interact with the underlying operating system. By observing file access, socket creation, or environment variables, researchers can infer configuration structures and privilege boundaries. For IoT devices running custom services or daemons, reverse engineering may uncover poorly implemented authentication checks, hardcoded logic flaws, or exploitable buffer conditions.

This process is time-intensive and requires a strong foundation in assembly, calling conventions, and embedded Linux internals. However, when combined with emulation and debugging, it becomes an indispensable technique for validating and extending findings discovered through static firmware analysis. In many assessments, reverse engineering is the only way to fully understand the proprietary logic and trust boundaries within an IoT system.

This static analysis step is critical when source code is not available and behavior must be inferred from compiled binaries.

Dynamic Testing (Emulation & Debugging)

In many cases, it is desirable to run the firmware in a virtual environment for further testing and debugging functions. Using QEMU, FirmAE, or Firmadyne, the extracted firmware can be emulated to observe runtime behavior and interact with services.

QEMU is widely used to emulate Linux-based IoT firmware. Tools such as FirmAE, Firmadyne, and PANDA help automate this process by identifying architecture (ARM, MIPS, etc.), extracting root filesystems, and configuring appropriate emulation parameters. Once successfully emulated, testers can:

• Run the firmware as a userland system
• Interact with exposed services (HTTP, SSH)
• Attach debuggers (e.g., gdbserver) for dynamic analysis
• Inject inputs and monitor memory or stack behavior

While emulation has limitations (e.g., hardware drivers may fail), it allows for rapid vulnerability discovery in services that otherwise require physical interaction.

For deeper analysis, GDB (GNU Debugger) can be attached to running processes inside QEMU using gdbserver. This enables instruction-level inspection of binaries, function tracing, and memory manipulation.

• Tracing vulnerable code paths
• Watching stack behavior during buffer overflows
• Setting breakpoints on authentication functions
• Detecting heap corruption or logic flaws in custom daemons

Dynamic debugging is especially valuable when reverse engineering proprietary binaries, as it complements static analysis by showing real runtime behavior and side effects.

Final Notes on Responsible Disclosure

Any vulnerabilities discovered during this process must be handled ethically. Disclosure should follow industry standards:

• Report findings directly to the vendor with clear documentation
• Provide proof of concept (PoC) and mitigation advice
• If no response is received, coordinate with CERT teams or public disclosure platforms under responsible timelines

Ethical testing strengthens the overall ecosystem. The objective is not exploitation but risk reduction.

Conclusion

IoT security testing requires a methodical, layered approach that spans physical hardware, embedded software, and external communications. By combining techniques from hardware analysis to reverse engineering and emulation, testers can gain a comprehensive understanding of the device’s security posture.

This methodology is not only useful for offensive testing but also for manufacturers and defenders aiming to secure their products. As IoT adoption continues to accelerate, rigorous and ethical testing remains essential.