Chinavasion Pico Projector
The projector supports quite a number of media formats, and I was able to play the movies I had ripped to AVI files. The only real problem I encountered was that some of the videos had somewhat low volume, so the fan did drown out the sound a bit, but that will vary depending on the video. The nice thing is that you can have it play media stored on either an SD card or a regular USB hard drive or even the ~400MB of free space it has on-board. Since it has support for USB hard drives, you essentially have unlimited storage choices, but it would have been nice if they had taken advantage of the wireless card to allow for network storage. The device does have a streaming app, but your choices are limited to YouTube and a few presumably Chinese streaming sites. YouTube streaming worked okay, although the interface is clunky and somewhat difficult to use. The other apps seemed to work as advertised but offered just basic functionality.
You might have noticed I didn't mention any sort of presentation app, and that's because there isn't one! This projector is strictly for media playback, so for now, you'll have to run your presentations from something else. The device has a port to connect an RCA cable, but that's for video out, not video in.
The wireless network can be configured from a settings page, and although the interface was simple, it did work fine and detect and connect to my wireless network. When you get to that menu, you'll get excited like I did when you notice that it lists not only wireless but also wired, GPRS/WCDMA and TD-SDCMA configuration; however, none of those are actual valid options, which makes me wonder why they were added to that menu.
I'll be honest. Although it's cool that they were able to fit all these features in a small device, if it weren't for the fact that there is a computer running Linux under the hood, I don't know how excited I would be about it. It does okay with media playback, but the interface just feels incomplete. At $235, it's a neat toy, but I don't know if I'd give it a recommendation to those of you who are reading this article if we stopped the review right here. Fortunately, this is only the beginning.
Before the projector arrived, one of the first things I asked Chinavasion was how I could access the Linux OS behind the interface. They checked with the manufacturer who said it wasn't possible to access the OS as it was “hard-wired into the unit”. Well, that sounded like a challenge to me, so my follow-up question was whether I could hack on the device. As I mentioned earlier but want to reiterate, if you do any of the things I mention below, you will void your warranty, and Chinavasion will not accept a return if you brick your projector. Now that I've said that, let's have some fun.
When the projector arrived, I poked at the regular interface for a second and then decided I couldn't wait—I had to get root on this device. The way the system boots, there didn't appear to be a way to change to a different virtual terminal (VT), so I figured my main route to a shell was through the network. After I connected the device to my wireless network, I ran a port scan, and wouldn't you know it, port 21 was open. “Hmmm”, I thought, “they couldn't possibly have telnet running on this.” Yet when I connected to the port, I got a nice ASCII art splash screen and a login prompt. I prepared myself for a day of brute-force attacks, but I was pleasantly surprised to find I could log in with root and no password. Jackpot.
Before I go into details on the user space for the projector, this a good place to list another way I discovered you could root this device, in case future versions no longer ship with telnet enabled. As I poked around on the filesystem, I noticed a script that is loaded at boot and easily could be exploited named /etc/init.d/S98z_auto_upgrade. This script is part of the init process and contains the following code:
#!/bin/sh if [ -e /mnt/mmc/autorun.sh ] then chmod 777 /mnt/mmc/autorun.sh sh /mnt/mmc/autorun.sh rm -rf /mnt/mmc/autorun.sh sync reboot fi
It appears this script is set up so that the manufacturer easily can upgrade the software on the device. A previous init script will scan for and automatically mount any SD or USB drive under /mnt/mmc. This script automatically will execute any autorun.sh file it finds in the root of that device, so if telnet were disabled (or root were given a password), all you would have to do is create a shell script to run the commands you wanted.
So here's what I found in the user space. The system runs a 2.6.10 kernel and a unique ARM processor I hadn't seen before. Here are some selected lines from /proc/cpuinfo:
Processor : ARM926EJ-Sid(wt) rev 5 (v5l) BogoMIPS : 124.51 Features : swp half thumb fastmult edsp java CPU implementer : 0x41 CPU architecture: 5TEJ Hardware : VIA-VT8430
The device itself has 256MB of RAM and 512MB of Flash split up into two partitions: a smaller one for / and a larger, mostly empty one for /mnt/mtd. You can navigate the file structure inside a standard BusyBox shell, and you'll see the standard root-level directories you might expect, although there is a very limited number of applications installed with the custom software found under /usr/dpf. I did notice it included a version of MPlayer that outputs to the framebuffer and uses hardware acceleration for video decoding, which I thought was interesting.
My simple goal was to find some way to display a shell on the projector. I figured at the very least, with a shell, I could ssh in to another machine and run other applications. This turned out to be far more challenging than I thought. The first challenge was the fact that there wasn't a virtual terminal set up for a console, and when I looked at /etc/inittab, I noticed that the only getty process that was running was for ttyS0, which I assumed was for some internal serial port I couldn't see from the outside:
ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100
Although you might think you could just run another instance of getty, it turns out that the version of getty included with this device doesn't support framebuffer output nor was another getty, such as fbgetty, included. Now at this point some of you might be thinking, “What about the kernel framebuffer?” Although it's certainly possible the kernel supported a hardware framebuffer, it wasn't enabled at boot. In fact, here's the complete kernel command line:
mem=244M root=/dev/mtdblock1 rootfstype=yaffs2 rw ↪noinitrd console=ttyS0,115200n8 init=/linuxrc ↪lcdbpp=16 lcdpath=GOV display=TV tvsys=NTSC loadtime=0
Because I found no evidence of a normal distribution bootloader, I'm assuming this system uses Uboot, so without serial access to the device possibly via a JTAG header, I wasn't going to be able to change the boot arguments. This meant I had to find a framebuffer getty compiled for ARM. At first, this seemed like an easy task. After all, Debian has been shipping ARM packages for quite some time, and all I had to do was find the right package and extract the binaries I needed. Simple, right?
Kyle Rankin is a director of engineering operations in the San Francisco Bay Area, the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal.
Free DevOps eBooks, Videos, and more!
Regardless of where you are in your DevOps process, Linux Journal can help!
We offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, and advice & help from the expert sources like:
- Linux Journal
- Be a Mechanic...with Android and Linux!
- New Products
- Users, Permissions and Multitenant Sites
- Flexible Access Control with Squid Proxy
- Security in Three Ds: Detect, Decide and Deny
- High-Availability Storage with HA-LVM
- Tighten Up SSH
- DevOps: Everything You Need to Know
- Non-Linux FOSS: MenuMeters
- Solving ODEs on Linux