Hacking Xfinity's Home Security Cameras

I have a series of webcams running, one of which is monitored by Motion, a motion detection system. When Motion sees activity on the camera, it starts recording it to a flash video file with a snapshot, and I have hacked together a dirty webpage that allows navigating the recorded archives. A cron job handles cleanup by deleting everything older than 3 days.

Recently, we got an Xfinity Home Security system installed. I've done some research and determined that the sensors work on the ZigBee protocol (which is pretty common for home security sensors) and a second (locked down) Wifi network. The Wifi network appears to be used to connect the touchscreen (Android based, pretty sure it's a rebranded iControl device) to the wireless cameras (iCamera-1000), and to allow remote access to the touchscreen for settings, monitoring, and alerts sent by the touchscreen.

So my wife wants to put one of the cameras pointing at our front door, and record people who come to the door. The Xfinity system would actually support this, but only in a limited sense and only by combining the camera with a motion sensor -- the system can be configured to record a video clip when the motion sensor triggers. But I don't want to waste a motion sensor (nor am I sure that the IR sensor would function properly outdoors in the cold). Given that I already have a system capable of detecting motion and recording it, I wanted to integrate the new camera(s) into that system.

But Xfinity doesn't want me in that "security router". The don't give you the admin credentials to access the router, nor do they even give you the WPA2 key for the Wifi network. But it turns out that I can add a NIC to my firewall/router running Linux and just plug that into the back of the security router. It happily obtains a DHCP address from the security router, and is able to communicate with the cameras! I needed to run tcpdump and access the cameras from the remote Xfinity app to sniff the HTTP (Basic Authentication) username and password, but was able to access the camera from Motion after that.

Based on the web page that the camera serves up, it's capable of streaming H.264 and MJPEG, but Motion only supports MJPEG, I think. I might experiment with H.264 at some point to see if I can get it working, but for now I'm happy with what I've got.

I'm hoping that I'll be able to eventually set up some sort of monitoring for sensor status and/or alarm status. One of the detractions of the Xfinity system is that the touchscreen is the only device with "speakers" and if it's situated in a remote part of the house (ours is usually upstairs in the master bedroom) it can't be heard throughout the house. Our is barely audible in the living room but impossible to hear from the basement (where I spend most of my time). I'd like to be able to have my PC "chime" when the sensors get tripped so I'll know if one of the kids is opening doors. But so far, I haven't been able to see any network activity between the control box and the world at large...

Web Cams, woot

I have set up a webcam page, mostly for fun, although my wife likes it because she can see if I'm working or watching TV or whatever.  I thought it might be fun to go over the technology involved, or at least the pieces that I've chosen for myself over the years.

Motion is a motion-detection and recording camera application for Linux.  This makes a great basis for a webcam.  You can have it generate recordings of activity on your camera that can be reviewed later with a simple PHP script.  MJPG-Streamer is another great tool for Linux.  It's a bit "raw" in that it's not packaged into system packages (that I know of) but it's actually a pretty slick lightweight program for having a live streaming camera.

On Windows, there's no shortage of webcam applications, but a simple free one that gets the job done is Yawcam (Yet Another Web CAM).  This is Java, but works reasonably well even on lower-powered systems (but definitely not as lightweight as mjpg-streamer).

I've tried all sorts of chat widgets for my webcam page, but none (for me) has ended up being better than CGI::IRC, which is a Perl-based IRC server in a web page.  I use this to allow people to join my private IRC server where I idle just in case anyone ever shows up.  They never do, but that's not the point. ;)

On my page, there are three cameras, each hosted on a separate computer.  A linux box (10.10.100.2) running motion records on the "main" camera with the widest angle.  Then, I have two laptops with integrated webcams that provide live streams from "side angles".  One of the laptops (10.10.100.19) runs mjpg-streamer, the other (10.10.100.201) runs Yawcam on Windows.

I've set it up so that the IP address (cam.akropolys.com) resolves to my firewall, both on internal DNS (as 10.10.100.1) and on external DNS.  I use Shorewall's DNAT rules to redirect external clients to the live camera streams:

DNAT net lan:10.10.100.2        tcp 8081     # webcam streaming
DNAT net lan:10.10.100.19:8082  tcp 8082     # webcam streaming
DNAT net lan:10.10.100.201:8081 tcp 8083     # webcam steraming

To allow internal clients to access the live streams, I use the rinetd utility to redirect request to the live video streams:

0.0.0.0         8081    10.10.100.2     8081 # cam
0.0.0.0         8082    10.10.100.19    8082 # cam 0.0.0.0         8083    10.10.100.201   8081 # cam 3

Of course, I use my reverse-proxy trick to redirect requests to the actual website.  This works for both internal and external clients:

RewriteCond %{HTTP_HOST} ^cam\.akropolys\.com$ [NC]
RewriteRule /(.*) http://10.10.100.2/~troy/$1 [P]

I also installed an ErrorHandler for error 503.  This error is thrown if Apache can't proxy requests to the camera page.  The error handler script checks the value of the $SERVER_NAME environment variable and if it's the camera server, it returns the camera down page.  This doesn't help if the webpage requests (on port 80) can be fulfilled but the live camera streams are down.  At some point I'm thinking I can use Javascript on the page itself to display an error image, but I haven't tried this yet.


Finally, I restrict access to the recordings to internal clients by checking the PHP $_SERVER['HTTP_X_FORWARDED_FOR'] variable and ensuring that the requesting client is on the 10.10.100.0/24 network.  This gives me a way to sort of secure parts of the page from prying eyes if I need to.