Reverse Engineering the OBi200 Google Voice Appliance: Part 2

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.


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:

I hit enter a few times and got a root shell prompt, meaning I had console access — no password needed!


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.

Share this: Facebooktwittergoogle_pluslinkedin
  • Damon Tripodi

    Thank you for doing this. It’s interesting and I’m eager for your findings. I have the obi202.

  • chris clement

    helpful links:
    firmware for avb-sw 88E7251 dev board:
    Chinese site were I found Linux BSP and SDK Package for Marvell 88E7251 Reference Board:
    the Linux BSP and SDK Package for Marvell 88E7251 Reference Board was very helpful building uImage and uboot for obi302. the confidential pdf’s included were invaluable to helping me with trying to build custom firmware for the device. and this was only place I found them for 2 points.
    which I had to buy 100 points for $20 cause that was least I could buy with paypal. but worth it do to no real info available for this chipset/SOC

  • chris clement

    IceChicken-Dev is another board using same SOC site says usinf linux 3.x.
    But I cant find any links to fw on the site. Only flyer that gives some data

    The AVB-SW fw does boot fine over tftp/nfs booting. as does running alt u-boot which provides more features than stock one

  • Jack McGhee

    Hi Randy. I posted this to Part 1 also, but, in the interest of the widest distribution, I re-posted this here: I am not a software engineer, nor a lawyer, nor have I ever
    played either one on TV. However, IMHO, you should take your
    information and write to Obihai asking, neigh, demanding them to release
    the SOURCE code for their Linux based firmware as required by the GPL
    by which Obihai uses the Linux used to base their device firmware. I
    have been thinking about suing Obihai in small claims court for breach
    of contract (the GPL) for refusing to release the source code for the
    Obi100 firmware, but even if I win by default judgement, my
    Massachusetts monetary judgement would be difficult/expensive/impossible
    to enforce against a California company. However, perhaps California
    Obihai device owners could use your information to sue Obihai for breach
    of contract (in small claims?) and get monetary damages from Obihai?
    Remember, Linksys voluntarily released the source code for their WRT54G
    Linux based routers, and the rest is history! (think dd-wrt, openwrt,
    tomato, etc.)