In part 1 of this post, I wrote about analyzing the firmware of the OBi200 and getting a root shell leveraging an existing RCE vuln. In this post, I’ll cover the process of identifying the serial port pins and connecting them to get console access to the device.
Protocol
Recall the serial interface listening at /dev/ttyS0 from the previous post:
This is a good head start as it discloses two important details: first, it confirms the serial interface is an 8250 UART which helps narrow down the search for headers (UART is typically four pins at minimum); second, it provides the baud rate. This is all the information needed to connect to the console from a software protocol perspective.
Identifying Pinout
Though there isn’t an industry standard UART layout, identifying potential headers wasn’t difficult on the OBi200:
As you can see, most test points are well-labeled and the only four-pin header on the board is J17. Also note its right most pin pad is square, designating it as pin 1.
Now that the port headers were narrowed down, the next step was to identify the individual UART pins of J17 — see the labeled USB UART adapter below:
I started by looking for the ground pin. Using a multimeter, I tested continuity between each pin and the RJ45 casing. I quickly found a match on pin 4:
With one pin down, I moved on to identify the remaining three — this is where things got slightly more difficult. In order to identify the rest of the pins, I measured VDC on each during bootup of the device (see this post for more on this process). The results:
- Pin 1 jumped around, ranging from ~2.2V to ~3.2V during the boot process
- Pin 2 held solid at just under 3.20V
- Pin 3 held solid at 3.3V
Pin 1’s activity was unique from the others — its fluctuations in voltage were likely signal data transmissions from the console port (the Tx pin).
The voltage measurements of pins 2 and 3 were quite close, but there was enough of a difference to identify them: pin 3, measuring at a full 3.3V, was indicative of VCC; pin 2, hovering just under VCC, represented Rx (the only remaining choice). It’s important to note that while pin 3 (VCC) won’t be used when connecting the USB UART adapter pictured above, identifying it helped eliminate it as a possible candidate for Tx or Rx.
Console Connection
With the pins for J17 identified, I connected the USB UART adapter. Note that the port header’s Rx is connected to Tx on the adapter (and vice versa) as shown below:
Next, I opened up a terminal and started a screen session — note the baud rate included from the first screenshot above:
screen /dev/ttyUSB0 115200 8N1
I hit enter a few times and got a root shell prompt, meaning I had console access — no password needed!
Bootloader
After successfully connecting to the console port, I decided to reboot the device and checkout the bootloader. The OBi200 runs U-Boot:
Interacting with U-Boot, we can learn more about the board and memory layout:
With lower-level access, we can also see more info during the boot process, e.g. messages to the system console and stdout:
Note the telnet daemon is launched during boot up — it’s killed during the launch of the OBi Daemon which I learned while researching the startup scripts in the previous post.
Next Steps
Now that I had root console access to the appliance, I wanted to dive deeper into its running services and the obiapp binary. In part 3 of this post, I’ll cover cross compiling gdbserver (and other tools) for the board as well as debugging crashes of the OBi binaries.
