I have a habit of buying used hardware whenever I see something interesting where I might think: “Let’s open it up and see how it works”. Therefore, I have a bin full of scrap electronics that wait their turn to be analyzed by me.
As the title suggests, I recently picked a router from that pile, the T-Home Speedport W700V. This router is pretty old (from around 2008) so it makes a good target as I won’t be sad when I brick it by accident. The goal is to check if it has any debugging ports we can connect to and potentially dump the firmware.
Connecting to the Device
Looking at the router, we can identify four screws holding the back plate of the device. After removing them with a Phillips screwdriver, we can pry open the plastic case. Be careful with the external antenna, which is attached by a wire. We are greeted by a beautiful 15-year-old circuit board.
Right off the bat we can see a few different chips on the board. The CPU, RAM and Flash chips are marked in green, blue and red respectively.
We can also see an unmarked area on the board with a few pins sticking out (marked in magenta). This immediately indicates that this is an exposed debug port, which conveniently has header pins already attached for us. So let’s find out what these pins do.
Since I suspect that this is a serial port, let us check if the board uses the Universal Asynchronous Receiver-Transmitter (UART) protocol as this is quite common for these debug ports. Let’s investigate: To identify the TX, RX, GND, and VCC pins, we can use a multimeter to analyze the behavior of each pin using both voltage readings and signal patterns. We begin by powering up the board, setting our multimeter to continuity mode, and locate the GND pin by probing all pins against a known ground (such as the metal shield we see on the PCB). Similarly, we can locate VCC by checking the pins for a stable 3.3V voltage (relative to GND). With GND and VCC identified, we can focus on the TX (transmit) and RX (receive) pins. TX, which is responsible for transmitting data, will naturally show voltage fluctuations as data is transmitted. This is the usual rising and falling edge pattern of the protocol. RX usually stays low when it’s not receiving data. To make sure we have the right pin, we can try different ones or use specialized hardware like the BusPirate. The BusPirate checks different PIN configurations and automatically determines the correct one.
With the pinout configured, we can set up our connection to the computer. We saw that our VCC is 3.3V, therefore we change the pullup resistor on our serial adapter accordingly. Make sure you check your voltages as well to avoid bricking your target. Afterwards, we can connect the adapter’s GND to the GND on the board, TX to the board’s RX, and vice-versa. We alternate TX and RX as our adapter reads from the board’s transmit pin, and vice-versa.
Now, we can attach to the serial interface via picocom, screen or another tool that can read from serial.
We choose screen for its simplicity today and connect to the device via screen /dev/ttyUSB0 115200, where 115200 represents the Baudrate of the device.
After we are connected, and boot the device, we can see the boot log of the machine.
This confirms our assumption that the header pins are a debugging port!
Examining the log, we see a lot of interesting information, for example, right after booting it waits for a certain key sequence to enter the bootloader’s menu. After rebooting again and hitting space three times we are greeted with the following prompt:
Press the Space Bar 3 times to enter command mode ...123
Yes, Enter command mode ...
[AMAZON Boot]:?
======================
[U] Upload to Flash
[E] Erase Flash
[G] Run Runtime Code
[A] Set MAC Address
[#] Set Serial Number
[V] Set Board Version
[H] Set Options
[P] Print Boot Params
[0] Primary = Image 0
[1] Primary = Image 1
======================
While uploading data to the flash seems interesting, we are particularly interested in extracting it to analyze it further.
After playing around with the interface and some googling, we discovered that we could unlock an administrative interface in an old German forum post.
This mode can be triggered when we enter an exclamation mark (!) in the boot prompt and unlocks more interesting features like reading and writing to the flash chip:
[AMAZON Boot]:!
Enter Administrator Mode !
======================
[U] Upload to Flash
[E] Erase Flash
[G] Run Runtime Code
[M] Upload to Memory
[R] Read from Memory
[W] Write to Memory
[T] Memory Test
[Y] Go to Memory
[A] Set MAC Address
[#] Set Serial Number
[V] Set Board Version
[H] Set Options
[P] Print Boot Params
[0] Primary = Image 0
[1] Primary = Image 1
======================
With these options, we can read from memory directly:
[AMAZON Boot]:r
Enter the Start Address to Read....0x
[we enter 0x30000000]
Enter the Start Address to Read....0x30000000
Data Length is (1) 4 Bytes (2) 2 Bytes (3) 1 Byte...
Enter the Count to Read....(Maximun 10000)100
----------------------------------------------------------
Address 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
----------------------------------------------------------
0x30000000
0x30000010
[...]
0x30000180
We see that this (arbitrarily chosen) memory region is empty, so how do we know where our memory lies?
When we google some more we discover that OpenWRT tells us what mapped memory looks like.
However, what would we do if this was an unknown target? After poking around in the bootloader we can try the [U] Upload to Flash function and are greeted with:
[AMAZON Boot]:u
UPLOAD Flash
---------------------------------------
Area Address Length
---------------------------------------
[0] Boot 0xB3000000 128K
[1] Configuration 0xB3020000 192K
[2] Image 0 0xB3050000 1856K
[3] Image 1 0xB3220000 1856K
[4] Boot Params 0xB33F0000 64K
[5] Flash Image 0xB3000000 4096K
---------------------------------------
Enter area to UPLOAD:
Firmware Extraction and Analysis
Now that we have the memory layout and can read memory from the bootloader, we are equipped with the tools to extract the firmware directly via UART. To do so, we can utilize a bit of scripting:
Here, we connect to the tty (on /dev/ttyUSB0), enter space three times, and follow with an exclamation point.
This gets us into the administrative menu we want.
Afterward, we want to (r)ead and read as much data as the bootloader lets us.
While it reports that we can read at most 10000 bytes in a single read, I found that it does not perform a bounds check.
Therefore, we try to read the entire 4 MiB of memory in one go (0x400000) from the start of the flash memory (0xB3000000).
We parse this output with a regular expression and write it to our dump.bin file.
After running the program, and a few minutes of time, the script finishes and we have exactly 4MBs of raw binary data.
$ du dump.bin
4096 dump.bin
Now what? We have a blob of binary data that consists of different memory areas.
We could carve out each block of memory via dd and the given offsets from the memory layouts.
However, we can also utilize binwalk which can identify and even extract data of a given file by looking for familiar file signatures.
After running it on the initial dump.bin we see that it identifies a number of LZMA compressed archives.
Of course, we want to look inside these as well, however, we do not want to extract each step manually.
Therefore, we run:
$ binwalk -Me dump.bin
This runs binwalk recursively on every extracted artifact until it cannot match anything it knows anymore. Looking through the extracted files we see that we were successful in extracting the PFS file system on the router:
> xxd 0.pfs | head
00000000: 5046 532f 302e 3900 0000 0000 4000 5201 PFS/0.9.....@.R.
00000010: 7777 775c 6976 725c 316b 2e37 3131 0000 www\ivr\1k.711..
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000050: bb3c 0bac 0000 0000 6c38 0100 7777 775c .<......l8..www\
00000060: 696d 6167 6573 5c70 6963 5f61 735f 6c69 images\pic_as_li
00000070: 6e69 652e 6769 6600 0000 0000 0000 0000 nie.gif.........
00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 1516 64ac ..............d.
As binwalk also extracted the filesystem we get:
.
└── pfs-root
└── www
├── cgi-bin
├── cpe
├── doc
├── images
└── ivr
7 directories
Now we can look into the files on the router and search for bugs! We could also edit the files on the system, re-compress them, and flash them onto the router!
Bonus
As we only knew about the administrative interface via Googling, the question may arise of how we can gain access to the firmware via another method? The easiest answer is downloading it from the manufacturer: Online Archive Download Link. This is the same version of the firmware as the one we extracted from the device via our UART script. However, this is also not applicable to every target, so what is another possibility to acquire it?
Here further hardware comes into play, namely a flash programmer. We identified the flash chip on the board and could use a tool like the CH341A programmer to extract the firmware directly from the chip. By connecting the clamp to the flash chip we can read the contents directly from it and analyze it later on.
Lastly, when examining the acquired firmware we find the following section in one of the extracted image files:
[...]
000081d0: 6572 2041 646d 696e 6973 7472 6174 6f72 er Administrator
000081e0: 204d 6f64 6520 210a 0000 0000 0a20 2020 Mode !......
[...]
This hints towards an administrative interface in the bootloader. However, keep in mind that finding this and identifying its meaning would take considerably more time.
Conclusion
In summary, examining hardware such as the T-Home Speedport W700V router provides insight into how our devices work at a deeper level.
By identifying debug ports and connecting via UART, we were able to access the device’s firmware and extract it for analysis.
Tools like binwalk helped us dissect the router’s file system and reveal its configuration.
This demonstrated process highlights the value of exposing hardware products to security analysis. By thoroughly examining these devices, manufacturers can identify potential vulnerabilities early and strengthen their security posture. So the next time you come across an old piece of hardware, take a peek inside—you never know what you might discover!