Robbing the IoT Graveyard: A Foray into Info Gathering and Enumeration with the InternetVue 2100

For the folks who are new here, I’m extremely long winded. You can skip down a bit to see how I got from OSINT to UART enumeration and a remote root terminal if you’d like, but I prefer telling the complete story.

Boring Intro Stuff (Not Hardware Enumeration)

It’s been a while since I’ve posted here. I was doing malware analysis a few years ago, did a bit of embedded device exploitation, used that to get a role at CACI, moved on to government with Sandia…it’s been a busy couple of years. I wanted to post something here sooner, I really did, but to be perfectly honest I had no idea what to write about. I’ve been in a bit of a rut in terms of cyber projects for a while, and I haven’t had the motivation to bring a lot of my old ideas to fruition.

That changed when I attended Defcon for the first time. I won’t bore you all with the details here, but it’s a wonderful place to get inspired, meet new people, and take a look at some of the projects folks in the community are working on. A company at Defcon 29 this year, I believe Rapid7 or F-Secure, had a booth where those new to hardware-based attacks could walk through the IoT attack process from the discovery of a UART device to achieving root access.

This idea has interested me for a while, a in past professional and personal projects, most of my activities related to hardware were easily accomplished without much hardware based enumeration. My targets were generally devices with easily discoverable USB UART interfaces employing known technologies. I wanted to more out of that space into more advanced projects, but I also wanted to do it on my terms.

The Target

A front view of the InternetVue 2100

My love of old hardware has lead me to purchase many odds and ends from the doomed tech companies of yesteryear. One such device is the InternetVue 2100, an ancestor of the Chromecast, meant to be plugged into a monitor and connected to via either WiFi or an ethernet connection in order to mirror a remote monitor. Like many modern IoT devices, it presented an attractive target because it had a wireless access point, multiple possible internet connections, and most important of all, public FCC documents that included detailed schematics. The device also came with a CD containing an updated copy of the firmware, more of a relic than a hallmark of newer IoT devices, but useful nonetheless. I originally bought it to see if I could reverse engineer the WiFi video protocol for use with another project, but I quickly grew frustrated and moved on to FPGA based video. I will not be covering much firmware reverse engineering in this piece, as it was not necessary to my new plan of attack. Instead, I would direct the reader to these peculiar looking pins.

Exploring the Breadboard

A suspicious array of breadboard pins

A more experienced engineer would start looking through the FCC database before they even opened their target, but I’m relatively new to this world and was very excited, so I took the next couple of steps. I mapped out and labelled every chip on the board, determined what chips performed which functions, and quickly located two very suspicious looking pin arrays. I identified an array of 14 pins directly connected to the onboard processor, and another array of 5 pins, a few of which were pulled up to 3.3V power or down to ground. I strongly suspected I had identified a JTAG array, but I was unsure of whether the 5 pins there were UART or another protocol. Logic analysis proved unhelpful due to a mistake I made in calculating data transfer frequency and a behavior of the device I will describe in detail in a later section. I moved on to the FCC ID.

FCC Database Analysis

As a new analyst at one of my previous roles, I was often told to check the FCC database before performing any hardware analysis, and for good reason. Every communications device needs to pass through rigorous FCC testing by an independent auditor, which will often expose things the company does not particularly want to see, including things like detailed schematics and communications protocols. Furthermore, if certain features are hidden or changed version to version, the FCC database may lead you to older versions of the device. Every communications device is required to list it’s FCC database ID on a label for compliance purposes, so I figured I’d take a look and see what I could find.

The InternetVue’s FCC ID

Searching fccid.io (my preferred FCC database search engine) proved fruitful. I found many versions of the device schematics, and information about the embedded processor. I could not find the exact version, but I knew it was in the Quartics QV14XX/15XX family of PC2TV SoC’s. I was able to find more detailed information later. Using the FCC information, I was able to show that the two connections I had identified were likely JTAG and UART.

A block diagram (Cited below, fccid.io)

I was also able to get a pinout of the JTAG port, but unfortunately the UART pinout had changed.

JTAG pinout (cited below, FCCID)

I’m a terrible de-solderer, so I did not wish to re-solder the JTAG connections. I also didn’t know much about the JTAG scheme in use, and I was still learning JTAG enumeration, so I decided to try to enumerate the UART connection instead. This meant I had less information about the pins, but it was balanced by my familiarity with the protocol.

UART Enumeration

The UART interface contains two essential pins, the receive (RX) and transmit (TX) pins. I was able to identify what I assumed was the RX pin through logic analysis, but I discovered that on boot it sent out a stream of information that quickly finished. I was not able to decode this information initially due to some logic analyzer mistakes on my part, so I moved on to fuzzing.

The view from my logic analyzer

My UART attack method involved an Ardunino Due and modified versions of two programs, RS232Enum and UartFuzz (both linked below). The Arduino Due was a bit of a frivolous purchase, but I prefer it to the Teensy and ESP32 due to it’s abundance of 3.3V communications pins and lack of odd USART programming issues.

The Arduino Due

The Due pairs well with RS232Enum, a tool written by the team behind JTAGEnum, which allows the user to test 32 pins at once for possible serial connections. Although UartFuzz offers the ability to enumerate pins as well, I prefer to use it for baud rate fuzzing as it is a less extensible solution in the pin discovery sense. A bit of a warning to those who use RS232Enum, it is made exclusively for AVR devices, and as such the ram calculation function must be modified for each ARM based Arduino it’s used with.

Due ram modification in RS232Enum

Using the “apin” test, a test that sends data to a suspected TX pin in order to get a response from the RX pin, I was able to locate my RX and TX pins.

RX and TX identification

This feature proved particularly important for my target, as it eliminated the need to continuously restart the device during UART enumeration to capture the active connection.

I then modified UartFuzz to use the Due’s hardware serial and remove pin enumeration. I was eventually able to find a baud rate that was consistently able to pick up whole words from the UART startup output.

Note that UartFuzz can be easily modified to send data before it receives data by adding a Serial.write() command to the fuzzBaud() function

Baud rate shown to be 38400

I didn’t even bother identifying a ground pin, I hooked up my Bus Pirate right away.

Note that a Bus Pirate was in no way necessary for this particular task. One might even call it overkill. However, all of my cheaper CP2102 bridges happened to be broken, and my FTDI dongles were still in boxes for Defcon that I didn’t want to unpack, so I went with it.

Bus Pirate with the InternetVue

Linux Enumeration

I restarted the device and used the UART monitor to receive the following transmission at 38400 baud:

A portion of the startup string

There’s about a minute worth of data in the device startup, so I’ll give the highlights:

• The UART findings were correct

Baud rate capture

• There was a bit of segmentation going on in the rom between the boot code and the user code

Rom layout

• We’re running something called NET4.0 for Linux 2.4
• Drivers appear to be started for audio and video peripherals connected to the QV1403, so the processor version in the FCC documents for other versions was different but still within the range expected
• A file called /app/wp_demo.txt appeared to be run at startup

A cool shell and evidence of a startup script

• Some discouraging news, at least part of the filesystem appeared to be read only

Read only filesystem

I didn’t want to give up yet, however, because when I pressed a key I was greeted with something that looked suspiciously like a root shell. I decided to start poking around and enumerating binaries.

Basic built in commands were present, but a few caught my eye. Busybox, utelnetd, cat, vi, and the wireless tools meant that we had the ability to do a lot of work locally to learn more about the system and create a remote shell.

The first thing I did was confirm my access level.

Root!!!!

Nice and simple, we have a root shell.

Next, I wanted to do some program and remote connection enumeration. Netstat was not present, but I was able to get a list of the running processes:

Running processes

We can see the wireless access point running, as well as the http server containing device information. Ifconfig showed the access point’s gateway to be 10.0.0.1.

I decided to use NMAP on the Wireless AP to enumerate running ports.

Running ports

Only the expected ports were running. 5050 and 5080 were both associated with the PC2TV video transmission and configuration protocols, according to a bit of firmware analysis I had done earlier. There were no remote shells. I also found that telnet_utility , which I had initially suspected started custom utelnetd settings, was actually a configuration shell program that failed to run correctly, taking down a lot of the wireless infrastructure with it.

telnet_utility

I decided to move back to the hardware space and another essential test, seeing if I could create files within the app folder.

I was able to confirm that the entire filesystem was not read only, and that I could hopefully modify wp_demo.txt to gain a persistent remote connection later. I expanded my testing, and was able to write a new folder to root an a new file to /bin, leading me to believe that I had read/write access to the majority of the filesystem.

Loading Files to the Device

The next step, now that I confirmed access and had a better picture of remote settings, was getting files onto the device. I first decided to gather some information about the system’s binary compatibility. One of my eventual ideas was to write programs that utilized the video driver, and I wanted to see if I could write some test binaries in the short term.

The device had a robust proc filesystem, allowing me to gain information about the processor, the kernel, and the GCC toolchain.

Processor and memory info

We can see a MIPS 4kc processor, and a rather old kernel compiled with GCC 3.2.2.

I initially planned to upload some binaries, but the GCC 3.2.2 MIPS cross compiler I got from UC Berkeley (link below) was unable to compile on any system I tried, and the assembler wasn’t playing nice with the linker. I tried using a modern version of the GCC MIPS cross compiler, but despite my best efforts to make sure all compiler optimizations were turned off and the correct MIPS version was used, I got a sad response to my hello world program.

Hello World?

It’s likely that changes to the ELF format and linker differences lead to these issues, and I didn’t want to spend too much time on side projects, so I moved on to file upload.

I noticed a tftp client on the device, and was able to use tftpd64 on my computer to host files to send to the device.

Sending files

This capability could easily be used to send scripts to the device. I was also able to remove the QV1403 driver from the device for further analysis later. I moved on to my final goal, starting a remote shell over wifi.

Starting a Remote Shell

The final portion of my plan proved pretty simple. I was able to start a remote telnetd server using utelnetd and connect to it from my host machine.

Utelnetd server

I then moved on to persistence. I suspected that /app/wp_demo.txt would be able to start utelnetd, as it appeared to be run at the end of the boot process to load the kernel module for the SoC and start the AP. I decided to write to it and see what happened.

Modifying wp_demo.txt

I rebooted manually, and was greeted by a new telnet shell!

Telnet running

I was able to connect remotely once again over the wireless AP, completing my objective. I now have a remote telnet shell that starts whenever the target boots, and no longer need physical access.

A telnet shell from the host

Conclusions

The InternetVue 2100 was a fun target to practice some UART skills, but it didn’t have much to offer in terms of security and prevention measures. I may not be done with the InternetVue. My original goal was to use either a wireless connection or the local program to create a custom video terminal, and I may still do some more analysis of the QV1403 driver and video DAC to see if I can do anything there. If I feel like it, I’ll put out a short piece on my prior experience reverse engineering firmware and wireless protocol, but it’s possible I don’t write on the InternetVue again anytime soon.

I want to push into the world of embedded encryption and industrial device security. I’m going to try to mix in some older targets like my Sun thin clients with newer ones like a few of the RISC-V devices I’ve collected over the pandemic, and explore topics like chip glitching, power analysis, and JTAG enumeration. Outside of the cyber realm, I hope to do a bit of analog computing with the Cypress PSoC and Anadigm FPAA devices, and finish up a SPARC-based CPU design I’m working on. I hope you all enjoyed this installment of my hardware journey, it’s great to be back.

Sources

SoC Info

[embed]Quartics, Inc. Launches PC2TV Brand and PC2TV Chip to Revolutionize Viewing of Digital Content IRVINE, Calif., Oct. 25, 2006 (PRIMEZONE) -- Quartics, Inc., a fabless semiconductor company focused on the development…www.globenewswire.com

FCC Filing

https://fccid.io/UXNIV2120

RS232Enum

[embed]GitHub - cyphunk/RS232enum: When you are presented with pins that you suspect provide Serial but… When you are presented with pins that you suspect provide Serial but you do not have access to the documentation…github.com

Modification resource for RS232Enum

[embed]How to get free RAM size on the Due? It seems that the "usual" way to get the amount of free RAM that I have always used, i.e.: (int) &v - (__brkval == 0 …forum.arduino.cc

UartFuzz

[embed]Hacking Hardware with an Arduino - MDSec Sometimes on embedded systems (such as routers or webcams), the manufacturer has left debugging ports on the board…www.mdsec.co.uk

Arduino Due serial info

[embed]Arduino - Serial Serial communication on pins TX/RX uses TTL logic levels (5V or 3.3V depending on the board). Don't connect these pins…www.arduino.cc

Bus Pirate UART info

[embed]How to connect a "Bus Pirate", as a UART, to an Arduino Pro Mini, to program it. - Page 1 If you were unaware that you needed a USB to serial board to connect to the Arduino Pro Mini, as I was, and didn't…www.eevblog.com

GCC 3.2.2 MIPS C Compiler, Assembler, and Linker

[embed]Index of /~ejrogers/gcc-mips Edit descriptioninst.eecs.berkeley.edu

TFTPd64 Windows TFTP Client

[embed]Tftpd32: an opensource free firewall friendly dhcp, syslog sntp and tftp server/service for… The industry standardTFTP server Tftpd64 is a free, lightweight, opensource IPv6 ready application which includes DHCP…pjo2.github.io