Hacking Xfinity's Home Security Cameras, part 2

(Note to the evil among us: I have, of course, changed the authorization and authentication details below. So don't bother. Or do, waste your time, see if I care. :) )

We recently moved about a mile down the road, which meant we needed a new Xfinity setup, and of course they've revamped their hardware. This time, we got a new Xfinity Gateway with 802.11ac support.  In fact, the latest gateway we just got apparently has something called beamforming, which is totally worth reading about because it's a really awesome hack.

Unfortunately, we discovered that Xfinity Home Security no longer uses a discrete "security router" for the wireless touchscreen and cameras. They appear to have integrated this functionality directly into the Xfinity internet gateway, so my camera recording solution couldn't be set up with the new installation.  While this is no doubt cheaper and better for them, I wasn't happy losing access to the cameras for no good reason.

Thanks to Chad Sturgill, however, I'd been thinking about sniffing the packets of a camera provisioning to determine the hidden wifi network and other details.  Now I had a reason.  So after the Xfinity tech left, I went to work.  Chad was right, and this is probably not for the faint of heart, and it took me a few tries to get something useful.  I set up my Linux firewall with 3 NICs to treat two of them in a bridged configuration, connected one to the camera, one to port 4 of the Xfinity gateway, and then ran tshark to capture the traffic.  I did have to run dhclient on the bridged interface to get it online, and then ran tshark thusly:

# ifdown eth0
# brctl addbr br0
# brctl addif br0 eth0
# brctl addif br0 eth1
# dhclient br0
# tshark -i br0 -w capture.tcp src net 172.16.12.0/24 and dst net 172.16.12.0/24

(My firewall was getting traffic on non-bridged interfaces and trying to route it out the bridged interface, so I used the filter expression above to limit the captured traffic to only the "security" network.)
And voila, I see packets:

GET /device.xml HTTP/1.1
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130:6789
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
CONTENT-TYPE: text/xml
CONTENT-LENGTH: 998
LAST_MODIFIED: Tue, 27 Oct 2015 10:04:34 GMT
DATE: Tue, 27 Oct 2015 10:04:38 GMT
SERVER: Linux/2.6.18_SC-DM365 UPNP/1.0 Intel UPnP
CONNECTION: close

<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
    <major>1</major>
    <minor>0</minor>
</specVersion>
<URLBase>http://172.16.12.130:6789</URLBase>
<device>
<deviceType>urn:schemas-upnp-org:device:Wireless Network Camera:1</deviceType>
<friendlyName>iCamera-iCameraDFCD9E</friendlyName>
<manufacturer>iControl</manufacturer>
<manufacturerURL>http://www.icontrol.com</manufacturerURL>
<modelDescription>Wireless Network Camera </modelDescription>
<modelName>Wireless Network Camera</modelName>
<modelNumber>iCamera</modelNumber>
<UDN>uuid:4d751d74-694d-6564-6961-000e8fdfcd9e</UDN>
<serviceList><service>    <serviceType>urn:upnp:service:BasicService:1</serviceType>    <serviceId>urn:upnp:serviceId:BasicServiceId</serviceId>        <controlURL>/upnp/control/BasicServiceId</controlURL>        <eventSubURL>/upnp/control/BasicServiceId</eventSubURL>        <SCPDURL>/scpd_basic.xml</SCPDURL>    </service>
</serviceList>
<presentationURL>http://172.16.12.130</presentationURL></device>
</root>

There is some SSL traffic that I can't decrypt, but then things switch back to HTTP:

GET /adm/sysinfo.cgi HTTP/1.1
Authorization: Basic YWRtaW5pc3RyYXRvcjo=
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Pragma: no-cache
Expires: Mon, 06 Jan 1990 00:00:01 GMT
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 10:04:38 GMT
Server: ip-camera

Firmware Version: V1.0.02R19
Serial Number:1307ZZ9063892

Note that the Authorization header here decodes to a username of "administrator" with an empty password. This seems like it's just getting the firmware version of the camera, checking to see if a firmware upgrade is required.

GET /adm/set_group.cgi?group=NETWORK&dns_server1=172.16.12.1&dns_type=1 HTTP/1.1
Authorization: Basic YWRtaW5pc3RyYXRvcjo=
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 10:04:43 GMT
Server: ip-camera

OK

Using the same Authorization header, this appears to set the DNS (probably so that the next step can use DNS).

GET /adm/auto_upgrade.cgi?new_fw_url=http://edge.xfinity-home.top.comcast.net/firmware/DYW9HZ-308-1002R22.bin HTTP/1.1
Authorization: Basic YWRtaW5pc3RyYXRvcjo=
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Status: 200
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 10:04:43 GMT
Server: ip-camera

OK

So it looks like this camera had firmware version 1.0.02R19, and the touchscreen wants it to get version 1.0.02R22. The request to perform the upgrade was sent 10 seconds in, and the touchscreen looks like it just waits 2 minutes. Then, at 129 seconds in, it tries to connect to the camera again. This fails, and the touchscreen starts periodically ARPing the camera.

At 383 seconds in, the camera appears to have finished whatever it was doing as it requests a DHCP from the Gateway router, does a bunch of IGD/UPNP negotiation with the Gateway router. Finally, at 402 seconds in, the touchscreen reconnects to the camera.

GET /adm/sysinfo.cgi HTTP/1.1
Authorization: Basic YWRtaW5pc3RyYXRvcjo=
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Pragma: no-cache
Expires: Mon, 06 Jan 1990 00:00:01 GMT
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 10:11:17 GMT
Server: ip-camera

Firmware Version: V1.0.02R22
Serial Number:1307ZZ9063892

And it appears the upgrade succeeded, since the camera reports v1.0.02R22 now. The touchscreen then makes the same request again. That's weird.

GET /adm/sysinfo.cgi HTTP/1.1
Authorization: Basic YWRtaW5pc3RyYXRvcjo=
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Pragma: no-cache
Expires: Mon, 06 Jan 1990 00:00:01 GMT
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 10:11:17 GMT
Server: ip-camera

Firmware Version: V1.0.02R22
Serial Number:1307ZZ9063892

And just for good measure, it checks a third time ("How many times did you do it?" "Three, you told me to always do it three times.")

GET /adm/sysinfo.cgi HTTP/1.1
Authorization: Basic YWRtaW5pc3RyYXRvcjo=
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Pragma: no-cache
Expires: Mon, 06 Jan 1990 00:00:01 GMT
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 10:11:17 GMT
Server: ip-camera

Firmware Version: V1.0.02R22
Serial Number:1307ZZ9063892

And then things get interesting. Note that I'm breaking these requests up for clarity but they are actually being sent over a single HTTP connection in some cases. The first thing that happens is that the touchscreen tries to set the http and https mode. This fails because now authentication is required (is the username/password in the firmware that was just updated? or does it come from somewhere else?).

GET /adm/set_group.cgi?group=HTTP&https_mode=1&http_mode=1 HTTP/1.1
Host: 172.16.12.130
Connection: Keep-Alive

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Authorization"
Content-Type: text/html
Content-Length: 351
Date: Tue, 27 Oct 2015 10:11:17 GMT
Server: ip-camera

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
  <title>401 - Unauthorized</title>
 </head>
 <body>
  <h1>401 - Unauthorized</h1>
 </body>
</html>

Denied! But then the touchscreen immediately tries again with username administrator and an empty password:

GET /adm/set_group.cgi?group=HTTP&https_mode=1&http_mode=1 HTTP/1.1
Host: 172.16.12.130
Connection: Keep-Alive
Authorization: Basic YWRtaW5pc3RyYXRvcjo=

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 4
Date: Tue, 27 Oct 2015 10:11:21 GMT
Server: ip-camera

OK

And this succeeds. I'm not sure whether this enables both an http and https server, or sets some other kind of mode. The touchscreen proceeds to get the firmware version again (but I'm not going to show that yet again). And then, at last, things get interesting!

GET /adm/set_group.cgi?group=USER&admin_name=root&admin_password=dvRxPrwv&login_check=1&user1=icn0Pnl2%2CV53xEm4 HTTP/1.1
Authorization: Basic YWRtaW5pc3RyYXRvcjo=
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 10:11:32 GMT
Server: ip-camera

OK

Looks like it wants to set a username of root and a password of dvRxPrwv, and a set of "viewer" credentials of username icn0Pnl2 and a password of tV53xEm4 (the %2C there is of course the URL-encoded value for the colon ":", which is used in the HTTP authentication scheme to separate the username from the password).

GET /adm/set_group.cgi?group=SYSTEM&led_mode=1&daylight_saving=1&pir_mode=0 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 4
Date: Tue, 27 Oct 2015 10:11:32 GMT
Server: ip-camera

OK

This is probably not really important, blinking lights and time zones, etc.

GET /adm/set_group.cgi?group=WIRELESS&wlan_type=1&wlan_essid=XHS-8C1EB62D&wlan_security=2&wlan_domain=12&wpa_ascii=D765494564A6621854 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 10:11:36 GMT
Server: ip-camera

OK

More meat! The wireless network settings we should use! The rest, frankly, seems like administrivia.

GET /adm/set_group.cgi?group=AUDIO&audio_in=0&in_audio_type=1 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 11:11:41 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=HTTP_EVENT&http_post_url=&http_event_en=1 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 4
Date: Tue, 27 Oct 2015 11:11:43 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=VIDEO&contrast=4&sharpness=2&exposure=4&text_overlay=0&default_channel=1&saturation=4&color=0&hue=4&dn_sch=0&time_stamp=0 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 11:11:49 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=MOTION&md_mode=0 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 4
Date: Tue, 27 Oct 2015 11:11:49 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=UPNP&upnp_mode=0 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 11:11:50 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=MPEG4&gov_length=20&quality_type=0&mode3=0&quality_level=3&resolution=3&mode2=0&frame_rate=15&bit_rate=6&mode=1 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 11:11:54 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=H264&mode3=0&quality_level2=3&gov_length2=10&resolution=3&resolution2=3&mode=1&gov_length=15&quality_type=0&quality_type2=0&bit_rate2=512&frame_rate2=5&mode2=1&frame_rate=15&bit_rate=768&profile=77 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 11:11:57 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=JPEG&frame_rate3=10&mode2=0&resolution3=3&mode3=1&quality_level3=5&mode=0 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 4
Date: Tue, 27 Oct 2015 11:12:02 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=EVENT&event_trigger=1&event_interval=0&event_attach=mp4%2C1%2C5%2C10&event_httpc=email%3A0%3Bftpu%3A0%3Bhttpn%3A0%3Bhttppost%3A1&event_pir=email%3A0%3Bftpu%3A0%3Bhttpn%3A0%3Bhttppost%3A0 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 11:12:06 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=NETWORK&dns_type=1&dhcp=0&ip_addr=172.16.12.163&dns_server1=172.16.12.1&gateway=172.16.12.1 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 4
Date: Tue, 27 Oct 2015 11:12:09 GMT
Server: ip-camera

OK

But note this -- interestingly, it's moving the camera to a new IP address. Not sure why but okay. There's a little bit of ARPing before the next connection can be made, since the camera switches IP addresses immediately.

GET /adm/set_group.cgi?group=JPEG&frame_rate3=15&mode2=0&resolution3=2&mode3=1&quality_level3=3&mode=0 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.163
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 4
Date: Tue, 27 Oct 2015 11:13:04 GMT
Server: ip-camera

OK

And that's it, all done.

Apparently, not news to anyone, this camera is an OEMed camera made by an overseas company called Sercomm, and many models exist (branded for each vendor). But they all (mostly) share (mostly) the same API. I found a pretty good reference at github, but there are others. IMHO the one at github does the best job listing all of the options available over the API.

A few interesting notes, thanks to the others who have investigated this:

• The camera has a microphone, and if you turn it on you can hear it on the RTSP stream, at least. But it's a very bad microphone and you can barely hear it.
• The camera might have a speaker. I can't tell about mine, but apparently some of them do. Maybe I'll try to do something with this at some point.
• There is some kind of built-in motion detection that can be used to issue alerts to an HTTP server, and possibly other functionality. I haven't tried this either, but it seems like maybe having each camera notify a recording system of events rather than having the recorder streaming video from all of the cameras all of the time could be a much more efficient system.
• There is a dynamic DNS update client. Not that these aren't a dime a dozen, and as the API reference notes that many of the DDNS providers are no longer working, this isn't a big deal, but it could be useful.
• There is a Windows software package for managing the cameras. I haven't found it yet, but I haven't really looked either.

A few other notes:

• The admin credentials for this camera are NOT the same as for the other cameras on my network, so there are apparently different credentials for each camera. Good Job, Comcast.
• There are functions in the camera that seems like they could be abused -- the ability to do a wifi site survey and retrieve information about all of the wireless networks that the camera sees. I'm just not sure what purpose this could serve, and I worry (just a little bit) about that information leaking on such a massive scale since these cameras are quite popular.
• In the same vein, you can do an SMB survey of the local network (which given it's an isolated hidden wifi network won't include your own machines). This could also potentially be abused, but I think the risk is mitigated by the network topology that Comcast enforces.

In conclusion, my thanks to Chad for pioneering this, and hopefully the protocol captures I've shown above might help someone figure out something about their camera.

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.