Hardware Hacking: Extracting Firmware When the Vendor Won't Help

TLDR: When IoT vendors fail to provide firmware updates, security researchers must turn to physical extraction to build a Software Bill of Materials (SBOM). This post details the process of desoldering NAND flash from a Davolink AX-1800 router to bypass the lack of official update channels. By analyzing the extracted binary, researchers can uncover hardcoded credentials, command injection flaws, and vulnerable third-party components that remain hidden from standard network-based assessments.

Security researchers often encounter IoT devices that appear to be black boxes. You scan the network, you poke at the web interface, and you find nothing but a "Check for Updates" button that returns a 404 or a static "No updates available" message. This is not just a nuisance. It is a deliberate barrier to entry that prevents you from performing a proper Software Bill of Materials (SBOM) analysis. If you cannot get the firmware, you cannot identify the vulnerable components lurking inside the device.

The Physical Extraction Process

When the vendor provides no download path, you have to go to the hardware. In the case of the Davolink AX-1800, the lack of an update mechanism forced a physical approach. The goal is to extract the raw binary from the SPI flash chip.

Standard tools like the Bus Pirate are often the first choice for in-circuit debugging, but they frequently fail when the chip is tied to other components on the board or when the firmware is locked. The most reliable method is to desolder the chip entirely. Once the chip is off the board, you can place it into a dedicated programmer like a DediProg or a simple adapter connected to a Raspberry Pi.

Using a Raspberry Pi for this is a rite of passage. You map the SPI pins to the Pi's GPIO headers and use software like flashrom to read the chip. If the chip is not natively supported by the software, you may need to manually patch the source code to add the specific chip ID. This is where the real work begins. You are not just reading bits; you are reconstructing the file system to find the kernel and the user-space applications.

Analyzing the Binary for Vulnerabilities

Once you have the binary, the focus shifts to Ghidra or similar reverse engineering suites. The Davolink AX-1800, like many IoT devices, relies on a custom web server that often mimics the functionality of BusyBox.

During the analysis, you will likely find hardcoded credentials in the /etc/passwd file or within the web server's configuration scripts. In this specific device, the password for the 'bob' user was found to be static, and the system was configured to update this password on the first boot using a value printed on the device label. This is a classic A07:2021 – Identification and Authentication Failures.

Furthermore, the web interface often contains command injection vulnerabilities. If the web server takes user input to perform a "password reset" or "network diagnostic" function, it is almost certainly passing that input directly to a system shell. You can verify this by searching for calls to system() or popen() within the binary. If you find a string like system("ping " + user_input), you have a trivial path to remote code execution.

Why This Matters for Pentesters

On a standard penetration test, you might only see the web interface. You might try a few default passwords and move on. By performing this level of hardware analysis, you move from "I found a login page" to "I have full control over the device's operating system."

This research is critical because it exposes the A06:2021 – Vulnerable and Outdated Components. Many of these routers run on ancient Linux kernels—often version 4.4 or older—that are riddled with known vulnerabilities. When you have the firmware, you can run an automated analysis to map these components against the NVD database. You will almost always find that the device is running software that has been end-of-life for years.

The Defensive Reality

Defenders are in a tough spot here. If the vendor does not provide a secure, automated update mechanism, the device is essentially a ticking time bomb. The only real defense is to isolate these devices on a separate VLAN and restrict their ability to communicate with the internal network. If you are a security engineer, you should be pushing for vendors to provide signed, verifiable firmware updates. If they cannot provide a way to update the device, they should not be on your network.

Hardware hacking is not about having the most expensive microscope or the best soldering station. It is about the persistence to get the data out of the chip. Once you have the binary, the vulnerabilities are usually sitting there, waiting to be found. Stop relying on what the web interface tells you and start looking at what the hardware is actually running. The next time you see a device with no firmware updates, do not assume it is secure. Assume it is hiding something.