Economy Size Geek - Who Goes There? Adventures in Amateur Security

“Firewalls are a hardware solution to a software problem.”—Someone at ShmooCon
Who Went There

Knowing someone is in my office is a great improvement. In the event of an actual compromise, it would be better to have some information about who the intruder was. That brings me to the second part of the solution, the Webcam. I had one lying around and figured this would be a good use for it.

The Vera appears to be a rebadged ASSU WL-500gP. It is running OpenWRT with custom modifications to it. This turned out to be a good thing, because it means software compiled for OpenWRT works on the Vera. Mi Casa Verde does not officially support changes at this level, but it gives you full root access, so at least it doesn't get in the way.

The first step to doing this sort of thing is hooking up the Webcam to my normal workstation. I've learned from experience that if you cannot get it to work easily on a full Linux install, you have no shot at getting it to work on an embedded device. The Webcam plugged in, and I installed luvcview, a simple viewer program that lets you see what the Webcam sees. I ran luvcview and immediately was looking at a small picture of myself. This was awesome on two fronts. I'm pretty sure this cam didn't work under Linux the last time I tried it, and now I can move on to the hard stuff.

Getting shell access on the Vera is really easy. Go to Advanced→Net & wifi→Advanced configuration. It will ask you to set a root password. From that point on, you will be able to ssh in as root. The filesystem is a little confusing at first. Using df, the root filesystem appears to be completely full. The way the system is created, that is not actually true. In most cases, you can ignore that and simply untar things on to the root filesystem with no problems.

OpenWRT normally uses ipkg to manage packages, and that is broken on the Vera. The workaround is very straightforward though. You simply follow the same process for all packages. It turns out that the ipk package is just a set of nested tarballs. Here is the process for installing the gphoto2 package:

cd /tmp
wget
http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/
 ↪brcm-2.4/packages/gphoto2_2.4.7-1_brcm-2.4.ipk

tar -xzvf  gphoto2_2.4.7-1_brcm-2.4.ipk
cd /
tar -xzvf /tmp/data.tar.gz

I was really excited, because there are two options for doing the image capture: gphoto2 and motion. gphoto2 is a command-line tool for controlling a normal digital camera. motion is a tool for controlling a Webcam and detecting motion.

What I really, really wanted was motion, which would provide an actual video of the person entering, but I ran into a classic version problem. The Vera/ASUS uses a Broadcom chipset for the onboard wireless. This is apparently flaky under the 2.6 kernel, so it is using a 2.4 kernel. The Webcam drivers for 2.4 are really limited. It turns out the uvc driver that allowed the Webcam to work on my workstation is available only in 2.6. I couldn't find a Webcam around the house that was supported with the drivers at my disposal.

So, that sent me on the hunt to get gphoto2 to work. It requires an actual digital camera. I had three different cameras from which to choose: a Canon SD1100, a Canon SD780 and a Canon EOS 400. You probably are noticing a theme here—they are all Canons. I love the little Powershot cameras. The last one is a DSLR that actually belongs to my wife (she's more serious about photography).

Here is where I learned that Canon has used its own protocol in the past, but apparently it's coming around. As a result, you need a recent version of gphoto2 in order to access the above cameras. In this case, I was incredibly lucky. It turns out the latest, greatest version was available and compiled already for me (downloads.x-wrt.org/xwrt/kamikaze/snapshots/brcm-2.4/packages).

In order to make this work, you need three different packages: gphoto2, libgphoto2 and libgphoto2-drivers. The instructions above work for installing gphoto2. The libs take some extra steps:

cd /tmp
wget
http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/
↪brcm-2.4/packages/libgphoto2-drivers_2.4.7-1_brcm-2.4.ipk
tar -xzvf libghoto2-drivers_2.4.7-1_brcm-2.4.ipk
tar -xzvf data.tar.gz
wget
http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/
↪brcm-2.4/packages/libgphoto2-_2.4.7-1_brcm-2.4.ipk
tar -xzvf libghoto2_2.4.7-1_brcm-2.4.ipk
tar -xzvf data.tar.gz

This gives you the /tmp/usr/lib directory. Then:

cd /tmp/usr/lib/libgphoto2/2.4.7/
rm -f any_drivers_for_cameras_you_dont_have

In my case, I left canon.so, directory.so and ptp2.so. The last two are needed to talk to my camera. If you don't clear out the drivers directory, you will run out of space when you try to copy this on to the Flash portion of the Vera:

cd /usr/lib
cp -R /tmp/usr/lib/* .

Now you can hook up your camera. Typing gphoto2 -a should list all your camera's abilities. The most important ability is capture. The Powershots reported being able to capture images, but I was unsuccessful in actually getting them to do so. They require a special command to open the lens that did not work. I hooked up the EOS and got an IO error. After some research, I found I needed to format the memory card. Once that was done, I could trigger the camera from the command line. Thanks to an idea from wearetherock (snipplr.com/view/19935/post-twitpic-with-curl), I found out that posting a tweet with the picture was super easy. This solved two problems at once. The first is that the Flash memory in the Vera can not keep very many pictures around, and second, the system is more secure if I can store the picture off-site, safe from intruders.

The script is dead simple:

#!/bin/sh                                                                                                                                                   
cd /tmp                                                                                                                                                      
gphoto2 --capture-image-and-download --filename=now.jpg
 ↪--force-overwrite
curl -F "username=USERNAME" -F "password=PASSWORD" 
 ↪-F "message=Intruder Cam" -F
media=@//tmp/now.jpg http://twitpic.com/api/uploadAndPost 

(Replace USERNAME/PASSWORD with valid credentials.)

Now that I had the picture capture happening, I just needed to connect it to the open door event. I found some people were monitoring a logfile (which in recent firmware has changed to /tmp/log/cmh/LuaUPnP.log). That would be fine if I wanted a record of what happened. Instead, I want the camera to trigger on an event.

It turns out Mi Casa Verde has a solution for this. The latest firmware adds in Luup. This is a Lua-based interface to the system. It allows you to do some pretty advanced scripting. In my case, I only need to do some simple scripting.

I put my shell script in /root/upload.sh. The scene I already had created had a button for Luup scene. I don't actually know any Lua, but in this case, Lua expertise wasn't really required. I simply entered:


os.execute("/root/upload.sh >/dev/null 2>&1")

This told Vera to run my little shell script whenever that scene was triggered. So when the door was opened, the camera would take a picture and upload it to Twitter.

Now when I open the door, it takes a picture. If I spend some more time on this, I could add more logic so that the notification and picture happen only at certain times of day or night. This would be useful to cut down on the notifications I was getting every time I left the office to do something else like eat lunch.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Canon firmware alterations

Anonymous's picture

You might be interested in:

http://chdk.wikia.com/wiki/CHDK

Canon firmware alterations (or maybe you already know about it).

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix