Gaining Serial Console Access on the Control4 Mini Touch Screen
I became interested in the Control4 Mini Touch Screen after watching a teardown video on YouTube by Connor Wolf. It’s an embedded computer system with a touch screen which can be mounted into a wall. Its intended use is to interface with a Control4 home automation controller. To me it seemed like an interesting platform to repurpose as a development board.
Since the Mini Touch Screen is a few generations behind it can be found inexpensively on sites like eBay, given enough patience. I purchased a lot of seven with a unit cost of around $12 USD, well below that of the included ARM processor.
The Mini Touch Screens I received are second generation, comprised of a single PCB and LCD assembly. The PCB is universal and only populated with the purchased options. Every PCB is populated with the following components:
The models I have operate using power-over-ethernet. There are other models which run off hard-wired A/C and network using standard 802.11 Wifi. To support power-over-ethernet and ethernet networking the following chips are installed:
If the Mini Touch Screen has the ZigBee option fitted, used to control lighting and other home automation novelties, two additional chips will be populated on the board. This chip pair appears in some of Control4’s other ZigBee enabled hardware:
This device has already been examined from a distance. It is reachable over telnet and this ability is documented by the manufacturer. The root password is also known, documented in OSVDB-73136 and subsequently documented by the manufacturer. I was personally interested in gaining access at the hardware level to monitor the boot process and explore the system in depth. At the same time I wanted to better understand the methods used to reveal passwords on opaque hardware systems.
While poking around inside I was immediately drawn to a four-pin header (J10) which seemed like an ideal candidate for a UART. Between a multimeter and a Jtagulator I determined that it was in fact a standard 3.3V UART running at 56700bps. Pins are numbered right to left: pin 1 is TX, pin 2 is GND, pin 3 is RX, and pin 4 is +3.3VDC.
Capturing the boot process reveals a lot of information about the hardware. The bootstrap environment is Redboot and the device is running a Linux 2.4 kernel. Since this is not a highly custom software stack, further interaction will be much more pleasant. A log of the boot process is availble for download.
I wanted to boot the into Linux’s single user mode in order to gain initial shell access without the need to authenticate myself. During boot it’s possible to drop into Redboot’s own interactive shell environment by interrupting with Ctrl-C during the first few seconds. Redboot can be interrogated to reveal its configuration, which includes the script it follows to bootstrap the system and execute the kernel.
Redboot allows us to pass parameters to the kernel when booting via the exec command. Helpfully, the boot process prints out the kernel parameters normally used. From these I created a new set which would drop me into single user mode.
I now have a BusyBox shell but an incomplete environment. /etc/ lacks passwd, the file in which I was most interested. I surmised that init scripts which execute at higher run levels were responsible for finalizing the environment. Consulting /etc/inittab confirmed my suspicions.
Executing the two sysinit scripts take care of the necessary steps to mount the read-write partition of the flash which holds the rest of the operating environment. Really, only rc.sysinit1 is needed for this. rc.sysinit is entirely concerned with performing a system upgrade if a specially formatted USB drive is plugged in.
I am now able to interrogate /etc/passwd to retrieve the crypted root password. Given what we know about the plain text password it would take an exhausing amount of time to brute-force it. It has enough complexity to be resistant to rule-based dictionary attacks. It’s quite fortunate that someone else has already released it. If someone had not I would look inside upgrade packages released by the manufacturer, examine the binaries on the filesystem, and finally resort to brute-force.
I now have access to the existing operating system. With the level of access achieved so far I can update root’s password to access
the device under normal operation. However, my primary interest lies in flashing an updated kernel and environment to the device via Redboot. I will cover that in detail in another post.