Hardware Analysis Process for IoT Hacking

4️⃣ JTAG (Joint Test Action Group)

The JTAG interface is a widely used standard for hardware debugging, programming, and testing. Essentially, JTAG enables direct memory access at the chip or board level, allowing developers and engineers to access deep system components.

Moreover, the JTAG interface facilitates diagnostics and testing of complex electronic systems. This includes diagnosing hardware bugs, firmware and software debugging, system initialization and configuration, and loading programs into non-volatile memory. Through JTAG, developers can halt system operation, read and write memory, and inspect processor registers.

4.1. TAP (Test Access Port)

The JTAG interface typically consists of at least four pins: TDI (Test Data In), TDO (Test Data Out), TCK (Test Clock), and TMS (Test Mode Select). Sometimes, the TRST (Test Reset) pin is also added. These pins are connected to JTAG-enabled devices to transmit test and programming commands.

TDI (Test Data In): Transmits test commands or data to the device.
TDO (Test Data Out): Transmits responses or data from the device.
TCK (Test Clock): Synchronizes the timing of JTAG commands.
TMS (Test Mode Select): Switches between various test modes of the device.
TRST (Test Reset): Optionally provided, resets the JTAG interface.

4.2. Firmware Extraction via JTAG

Firmware extraction is possible through the JTAG interface by directly reading the firmware image from the device's memory. This enables identification of vulnerabilities in the device and understanding of its operation through reverse engineering. Additionally, using JTAG, modified firmware can be reloaded onto the device to enhance functionality or add new features.

While the JTAG interface is a powerful tool, it also poses security risks. If a device's JTAG port is accessible without authorization, malicious users can manipulate the system or extract sensitive information. Therefore, it is important to disable or protect JTAG access before product release.

5️⃣ Firmware Acquisition

There are various methods to obtain firmware for equipment analysis.

Firmware can be downloaded from manufacturer websites or other provided sources. However, firmware may not be available for all types or versions of target devices.

If there is an automatic firmware update feature, firmware can be intercepted via ARP Spoofing if it is transmitted in plaintext. If communication occurs over SSL, interception can be achieved through port forwarding. If SSL Pinning is applied, bypassing is required for port forwarding.

Firmware extraction is also possible through UART (covered in Part 1), JTAG (described above), and other methods. The unpacking process for extracted firmware typically involves separating the bootloader, kernel image, and file system.

5.1. Firmware Unpacking

The obtained firmware needs to be unpacked to separate the bootloader, kernel image, and file system. Tools such as binwalk and firmware-mod-kit can be used for unpacking.

Confirm firmware file using the file command.

Dump with hexdump → Confirm signature header with grep command.

Separate file system signature headers by bytes.

Mount separated file system.

Alternatively, use binwalk to extract all at once.

It can be extracted with the -e option.

Explore the CramFS file system.

5.2. Firmware Virtualization

Extracted firmware can be analyzed in a virtual environment. Firmware virtualization is a technique to run firmware for analysis without the need for actual hardware, which is useful for finding security vulnerabilities or testing new features. By running firmware in a virtualized environment, developers and analysts can monitor and validate the system's behavior in a safe environment.

For this purpose, virtualization tools like QEMU (Quick Emulator) are extremely useful. Firmware virtualization using QEMU provides a way to run and test firmware without actual devices, offering a means to execute and evaluate firmware securely.

5.2.1. What is QEMU?

QEMU is an open-source virtualization and emulator software for various platforms. It allows developers to emulate not only operating systems like Linux, Windows, and macOS but also diverse architectures such as ARM, x86, and MIPS. Using QEMU for firmware development enables developers to execute firmware, debug, and conduct testing in various scenarios from the early stages of development.

5.2.2. Firmware Virtualization Process with QEMU

Firmware Acquisition and Extraction
Before running firmware in QEMU, it needs to be obtained either by extracting it from the device or acquiring it from official sources. Firmware can be extracted using methods like SPI communication to read it directly from memory chips.
Setting Up the Virtual Environment
Setting up QEMU involves configuring an emulation environment tailored to a specific architecture and system. This includes defining parameters such as memory size, CPU type, and network settings through command-line options.
Loading the Firmware
Load the firmware image into QEMU and start the virtualized environment, optionally including additional filesystems or kernel images as needed.
Debugging and Testing
QEMU can be integrated with GDB (GNU Debugger), allowing firmware to be executed step by step, inspecting variables, and identifying issues.
Performance Analysis and Optimization
Running firmware in a virtual environment enables monitoring system performance and optimizing it if necessary.

5.2.3. Example of Running QEMU

Selecting the Required Virtual Images
Choose between 32-bit and 64-bit options and install the kernel image and hda accordingly. For example, if you want to install 32-bit mips, select vmlinux-3.2.0-4-4kc-malta and debian_wheezy_mips_standard.qcow2.

Run the Virtual Environment with the Appropriate Command for the Installed Files (root / root)
Execute the following command to start QEMU
qemu-system-mips -M malta -kernel vmlinux-3.2.0-4-4kc-malta -hda debian_wheezy_mips_standard.qcow2 -append "root=/dev/sda1 console=tty0"

Log in as root/root.

Transfer the Extracted File System from Firmware (fmk, binwalk, etc.) (Local → QEMU)
```
# From local to virtual
scp -r squashfs-root root@192.168.5.12:/root/
```

Mount the File System in the Virtual Environment and Start the Web Server

# On the virtual machine
mkdir squashfs-root/var/run
touch squashfs-root/var/run/lighttpd.pid
mount -o bind /dev ./squashfs-root/dev
mount -t proc /proc ./squashfs-root/proc
mount -o bind /sys ./squashfs-root/sys
chroot ./squashfs-root/ /bin/sh

# Boot after chroot
lighttpd -f /lighttp/lighttpd.conf -m /lighttp/lib/

5.2.4. Differences Between Squeeze and Wheezy

"Squeeze" and "Wheezy" are release code names of the Debian Linux distribution. Debian is one of the popular Linux distributions that focuses on stability and free software. Its name is a combination of the names of its initial developer, Ian Murdock, and his wife, Debra. Each release includes specific development stages, updated software packages, security patches, and system improvements.

Squeeze (Debian 6.0)

Squeeze is the 6th stable release of Debian, released in 2011.
It provides long-term stable service in Debian, widely used on servers and desktops.
One of the key features at that time was the improvement of the Debian installer, providing better hardware support and automated installation options.

Wheezy (Debian 7.0)

Wheezy is the successor to Squeeze, the 7th stable release of Debian, released in 2013.
Wheezy introduced multi-architecture support, allowing users to manage packages from multiple architectures on a single system.
It introduced systemd options to reduce system boot time and included more software and updated program packages.

Differences

Each Debian release typically builds upon the previous one, incorporating security updates, bug fixes, and improvements to software packages. Developers and users consider upgrading to a new release to achieve a more stable and feature-enhanced system.

Hardware Analysis Process for IoT Hacking - 2