The Foscam FI9816P is a wireless Internet Protocol (IP) camera commonly employed for surveillance and it can send and receive data via a computer network and the Internet. This particular model costs around $70 USD and can help you, according to Foscam, keep an eye on what matters most (a lalalala long).
There are numerous Foscam models out there with critical security vulnerabilities; so, Tasos had the idea to order the new FI19816P model and check if this is the case. The goals of this side project is to undestand how IP cameras work, find bugs and exploit them to get internal access, and dump and backdoor the firmware. In order to achieve all these, the first step is to teardown the camera and look for a serial port. Serial ports are typically used by the embedded system developers for debugging and various other technical support purposes. Access to the serial port interface can allow us to observe the booting process, access the bootloader, check debug messages, and ultimately interact via a shell with the system.
Identifying the serial headers
Most serial port headers have between 4-6 pins (typically 4):
- Vcc (3.3 V)
- Ground (GND)
- Transmit (TXD)
- Receive (RXD)
Since the UART port is not designed to be utilized by the end users it almost never has pins or connectors attached. After taking a quick look at the board of FI9816P, 3 sets of unused pads call our attention.
Time to get out the multimeter.
Pad 2 (J6) is unlikely to be the UART console. All 4 pins indicate 0 V (metal shielding is a convenient ground point to use for testing). Pad 3 has half of its pins to ground, and half to 5 V. It is also unlikely to be the serial port: the 5 V pins are not steady to 5 V indicating that none of them is Vcc (also, most Foscam models have 3.3 V as the Vcc pin). On the other hand, pad 1 (J5) has a grounded pin and the other pins around 3.3 V (time for a short celebration).
In order to verify that pad 1 is the UART port, JTAGulator can help us identify the pinout. JTAGulator is a hardware tool that can assist in identifying on-chip debug interfaces like JTAG and UART. A logic analyzer, an oscilloscope, or even the variations of the multimeter can also help identify the pins.
Once we have connect the JTAGulator to pad 1 (GND to GND, and the other 3 pins to channels 8-10 of JTAGulator), we set the target system voltage to 3.3 V and issue the :u command to identify the UART pinout.
The JTAgulator permutation results reveal that channel 9 of JTAGulator is connected to TXD and channel 8 to RXD. Among these results, only the 115200 bits per second baudrate returns the 0D hexadecimal ASCII representation of Carriage Return (CR).
The 115200 b/s baudrate is also verified with baudrate.py, a python script that attempts to auto detect the baud rate of an actively transmitting serial port.
Connecting to serial port
Once we have both the pinout and baudrate, we are ready to start communicating with the device. In contrast with pad 2 and 3, we cannot attach headers to the serial port – pad 1 (J5). Therefore, we need to solder the J5 pinout connection.
To verify the correctness of the soldering we use JTAGulator one more time.
Now that we’ve got the hardware setup ready, it’s time to talk to the device. To achieve that, any UART to USB bridge would do the job. We used the 3.3 V C232HD USB – UART cable. In this part, it is important to connect the TXD and RXD pins of the device to RXD and TXD of the UART – USB bridge respectively.
We are ready to open a serial terminal in our computer and communicate with the IP camera (any serial communication program would do, e.g. screen, minicom, putty, etc.). The video below presents how UART spits out information during the booting of the device.
Hitting any key during the booting process it allows to interrupt the bootloading and get (presumably) a shell after typing the correct password.
Getting the password
A way to get the password is to disassemble the firmware of the FI9816P camera and check if it resides over there. Unfortunately, the firmware of this particular camera model is openssl-encrypted.
In order to decrypt the file, both the cipher and the password must be known. So, it seems that the firmware path is a dead end.
If anybody has any ideas how to get the password and thus shell access on the device, it would be greatly appreciated. If not, I am sure we will find a way with Tasos.