Phonetendo

I came across one of these in a local thrift store for $8:

Thrift stores are dangerous places to go; my powers of self-discipline can only be tested so far. Unlike the cabinet stereos that have troubled my past, this was fortunately small, cheap and clearly awesome. It begged to be adopted.


What is it?

This is about to get a little heavy on the detail, so feel free to skip to the last section to see what I did with this. But anyway:

This is an Iris 3000 videophone, manufactured by UMEC and distributed by ACN, launched in 2007 on The Apprentice. It's apparently a standard SIP phone with various quirks and flaws, though I've got no particular interest in using it that way.

Cracking it open reveals the motherboard:

On the back are composite video and audio outputs, a POTS jack, two ethernet jacks, a USB jack, a power jack, and a power switch. There are several unpopulated pads on the board, but nothing I've bothered investigating yet.

This board was manufactured in 2009 and also goes by the name CU776. Googling this leads to the manufacturer's specifications.

Here is the Freescale i.MX27 brain that runs the unit. This is an ARM chip with additional multimedia brawn, intended for the telecommunications market.

Looking around the board for a few other clues about its features, we find a FS453LF chip:

This is the TV encoder that feeds the video output at the back of the unit.

There is also a WM8731S chip:

This is a CODEC that handles the audio duties -- the speakerphone and handset. (And as you can see, the photo also contains another another of those useful-looking unpopulated headers.)

The only other feature worth mentioning is the SD card slot on the side; we'll get back to that.

Software

As mentioned on the Wikipedia page, this phone runs Linux. That's helpful to someone who wants to hack the device in some ways but there still needs to be a way to break into it. Luckily, hackers love a challenge. I found this very useful thread, which included instructions on gaining a root shell:

$ telnet 192.168.3.2
Trying 192.168.3.2...
Connected to 192.168.3.2.
Escape character is '^]'.


        Welcome to Freescale Semiconductor Embedded Linux Environment


freescale login: root
Password:
mx27#

Bingo! Some exploration turned up a pretty standard embedded systems setup:

• Busybox for the system tools,
• A great big monolithic QT application for the UI, and
• A mixture of additional tools and programs for the details.

A Better Operating System

Luckily most of this is standard fare: V4L for the camera, /dev/fb0 for the LCD, ALSA for the audio, and /dev/input/event0 for the keypad. These are the normal ways of accessing the hardware on a Linux system, if occasionally a little musty.

So it'll do fine with Linux. However, a logical next question is: will it run Debian? Busybox is a little like skim milk -- fine for other people who want to lose weight, but to be kept strictly out of my coffee. I started with QEMU, an ARM emulator, and built a Debian disk image using steps similar to these. I wrote that disk image to a 2GB SD card, popped it in the side of the phone (which was even kind enough to auto-mount it for me), and used pivot_root to flip over to it. This isn't strictly the same as booting into Debian -- I'm still running busybox's init, for example, and need to manually start any services I want to run -- but it does get me a full libc and all the apt-get I want.

I did investigate the built-in bootloader and the chances of flashing the internal 128MB with a new boot image -- but decided against it; it's unnecessary for my purposes and risks bricking the phone. The other problem with that is that the kernel that ships with this phone is customized in at least a couple of ways: it has a very useful recovery mode which I've used twice to cover for my own stupid mistakes (ignore at your own risk the note in bold on the manpage for switch_root), and it has at least one custom kernel module, for which the source appears to closed. I am not a lawyer, but it sure looks to me like UMEC is violating the terms of the GPL. So I'm stuck with that kernel and any warts it has or I will lose the functionality those modifications provide.

Reverse Engineering

So a little bit of exploration left me with a few unknowns. I was especially interested in the following: how was the device sending audio to the handset and not just the speakerphone? How did it know the handset was on hook or off?

There are a number of tools to help answer this kind of question, starting with a very basic examination with strings, then moving to move advanced tools like strace and gdb.

The strings tool looks in any file for content that looks like it's human-readable and dumps it out. Using strings on a program tends to grab things like text that it displays on the screen, copyright notices, etc., but also reveals some internal details -- what hard-coded programs and files it interacts with. In this case it turned up several device files, including /dev/umec_device, and the names of some standard system tools like ifconfig, route, iptables, and amixer.

The /dev/umec_device file was an immediate suspect for specialized interaction between software and hardware, but there was no information online about it, so I had to get a sharper chisel.

The strace and gdb tools are generally for programmers trying to figure out why their program is going astray, but they can also be used to reverse-engineer 3rd-party programs. In particular, they can display information about interactions a program has with the system, which is exactly what interested me.

The first problem I encountered was that I was running the device with a split personality. The phone software and boot scripts were running using the busybox environment, and all my debugging tools and their respective libraries were running from the Debian-based SD card. This caused a minor amount of schizophrenia as gdb tried to reconcile the two. I resolved this by killing off the phone's UI, neutering the tools it tries to reach in order to configure the network (e.g. moving /sbin/ifconfig to /sbin/ifconfig-real), and starting it again from within the chroot environment. Luckily this worked.

This allowed me to look at a dump of what was happening when I took the handset off-hook or returned it to its cradle:

printf("bard dbg: g_speaker_status=%d ev"..., 0) = 37
memcpy(0xbe84cbdf, "/dev/umec_device", 17)       = 0xbe84cbdf
open("/dev/umec_device", 2, 00)                  = 18
ioctl(18, -1073458425, 0xbe84cbd4)               = 0
close(18)                                        = 0
memcpy(0xbe84cbdf, "/dev/umec_device", 17)       = 0xbe84cbdf
open("/dev/umec_device", 2, 00)                  = 18
ioctl(18, -1073458427, 0xbe84cbd4)               = 0
close(18)                                        = 0
memcpy(0xbe84cbdf, "/dev/umec_device", 17)       = 0xbe84cbdf
open("/dev/umec_device", 2, 00)                  = 18
ioctl(18, -1073458424, 0xbe84cbd4)               = 0
close(18)                                        = 0
memcpy(0xbe84cbdf, "/dev/umec_device", 17)       = 0xbe84cbdf
open("/dev/umec_device", 2, 00)                  = 18
ioctl(18, -1073458426, 0xbe84cbd4)               = 0
close(18)                                        = 0
printf("bard dbg: new g_speaker_status=%"..., 0) = 33

Great! Except that this isn't enough. The ioctl call is what interacts with the /dev/umec_device, and it can be called in a number of different ways. In many cases you don't pass it the actual instructions for what you want it to do; instead, you pass it the location in memory where it can find the instructions. That 0xbe84cbd4 looks suspiciously like just such a pointer, since it's passed into ioctl four times in a row.

So how to figure out what's being put in that location in memory before it's given to ioctl? Googling around for such a thing, I found this. It's basically a trojan horse: when you run a program, you first instruct Linux's library load code as follows: "By the way, before you load any external code, check here for it first." And you give it a special piece of code that defers to the same old library call that would've been made anyway, but logs what's happening first. Looking at the ioctl calls above, I wrote this wrapper:

#define _GNU_SOURCE

#include <stdio.h>
#include <dlfcn.h>
#include <stdlib.h>
#include <malloc.h>

FILE *preloadhackfp;

static int (*next_ioctl)(int fd, int request, void *data) = NULL;
int ioctl(int fd, int request, void *data) {
        char *msg;

        if (next_ioctl == NULL) {
                fprintf(stderr, "Wrapping ioctl.\n");
                fflush(stderr);
                next_ioctl = (int (*)(int, int, void*)) dlsym(RTLD_NEXT, "ioctl");
                if ((msg = dlerror()) != NULL) {
                        fprintf(stderr, "ioctl: dlopen failed : %s\n", msg);
                        fflush(stderr);
                        exit(1);
                }
                preloadhackfp = fopen("/tmp/preloadhack.log", "a");
                fprintf(preloadhackfp, "Opened log.\n");
                fflush(preloadhackfp);
        }
        if (request == -1073458425 || request == -1073458427 || request == -1073458424 || request == -1073458426) {
                long int i = *((int *) data);
                fprintf(preloadhackfp, "Logged %i: %li\n", request, i);
                fflush(preloadhackfp);
        }
        return next_ioctl(fd, request, data);
} 

Running the phone binary with LD_PRELOAD set to load this poison pill got me a log containing exactly what I needed to know. Of course, all this would've been unnecessary if UMEC wasn't violating the GPL. On the plus side, I learned some new skills here.

A New Purpose

Some unknowns remain about this hardware, but this was enough for my purposes.

My goals here were twofold:

1. Make a video game that uses the phone as an interface. Well, to be honest, this isn't actually a game -- it's a close fake. It looks like a game and acts like a game, but actually it's an office assistant simulator. You are required to suffer an unpleasant environment and given menial tasks to perform.
 

2. Turn the video phone into a gaming platform. By setting up the SD card in a particular way -- specifically, to provide a script called "sltp", which the phone for some reason is hard-coded to look for -- you can trick the phone into running the game instead of performing its usual startup. That means the SD card is effectively a into a game cartridge and the phone into a weird-looking Nintendo.

This is a work in progress, but currently it's an isometric game set in a cubicle maze. (Thanks to Clint Bellanger for the tiles.) You wander around amidst your coworkers and greet them. (Thanks to "Intimidated" at freesound.org for the samples.) You're all zombies, thanks again to art borrowed from Clint's open-source Flare RPG. (I had intended to use the zombie sprites only until I could scare up some suitable [so to speak] alternatives, but over time the zombies have grown charming.) Occasionally you'll receive robocalls. You can dial out but the line is always busy. Coworkers may ask you to find a lost stapler. The music is repetitive (thanks and, um, sorry, Antionio Fiorucci) and you can't turn it off.

The code is all new, written in C using SDL. There were a bunch of new algorithms and tools to learn en route -- pathfinding for the NPC behavior, drawing isometric maps, etc. -- and problem-solving varied from fun to frustrating.

In the coming weeks I hope to add more "missions" (deliver this file to so-and-so, maybe navigating phone maze hell, and the like) but for now it proves its point and hopefully shows the potential for reuse for this device.

The source code for this is posted on github.com. More to come, including a HOWTO describing how to build the SD card.

(I'll be showing this alongside many other bits of oddness at the Vancouver East Side Culture Crawl, Nov. 16-18 here in Vancouver. Come say hi.)