Tuesday, October 27, 2015

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.

22 comments:

  1. I am a bit annoyed with myself, I thought I had this figured out. I don't have linux so I figured I used a DD-WRT Netgear router and insert the # ifdown eth0....ETC...ETC command and Voila I would start to get the packets. But no, all I got was gibberish like binary code.

    I understand that this is not for the faint of heart nor amateurs, I just hate the fact that TWC/Comcast get away with this crap. I just want to be able to utilize all my cameras without the need of asking the provider questions I both know they are not aware of and the dreaded No answer. So I ask you humbly, would you mind assisting me?

    ReplyDelete
  2. Hi Rafael, I'm not sure what to say here. If it helps, I used tshark to capture the packets, then wireshark's GUI to decode them and read the contents. Maybe that's the problem with your setup? I'm also not sure that your Netgear would have multiple ethernet interfaces (I'd guess that it has one ethernet interface hardwired internally to some sort of switch hardware for the multiple ethernet ports). If that's the case, you shouldn't need to bridge it (and you'd have nothing to bridge, really).

    I don't know about the TWC setup, but if they have the same ability for an end-user to provision (and re-provision) the camera, then sniffing the packets ought to work as long as they don't move to SSL for configuring the camera.

    If you want to post a log or something somewhere showing what you've done and what results you got, I'd be happy to look at it but of course I can't guarantee anything. :)

    ReplyDelete
  3. Rock on brother,Thanks. I took it apart and haven't setup up again, this weekend I'll redo it and post the results here. Again, thank you!

    ReplyDelete
  4. Have you by chance sniffed any traffic to the camera's http_trigger.cgi script? If so I'm curious what it expects as parameters.

    ReplyDelete
  5. FYI, the link that the camera downloads the new firmware from is a working link. With a little poking around I was able to download some other firmware versions.

    iCamera1000 Firmware Files

    http://edge.xfinity-home.top.comcast.net/firmware/DYW9HZ-105-1002R08.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DYW9HZ-308-1002R17.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DYW9HZ-308-1002R19.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DYW9HZ-308-1002R22.bin

    iCamera2 Firmware Files

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-104-300114.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-105-300124.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-105-300126.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-106-300128.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-106-300129.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-108-300132.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-110-300229.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-110-300230.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-111-300239.bin

    ReplyDelete
  6. iCamera1000 Firmware Files

    http://edge.xfinity-home.top.comcast.net/firmware/DYW9HZ-105-1002R08.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DYW9HZ-308-1002R17.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DYW9HZ-308-1002R19.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DYW9HZ-308-1002R22.bin

    iCamera2 Firmware Files

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-104-300114.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-105-300124.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-105-300126.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-106-300128.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-106-300129.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-108-300132.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-110-300229.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-110-300230.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-111-300235.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-111-300238.bin

    http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-111-300239.bin

    ReplyDelete


  7. You can actually just tell the camera to install whatever firmware you want. Just use the API command below and substitute the firmware version you want to install.

    /adm/auto_upgrade.cgi?new_fw_url=http://edge.xfinity-home.top.comcast.net/firmware/DAXNHZ-106-300129.bin

    ReplyDelete
  8. iCamera1000 Firmware Files

    DYW9HZ-105-1002R08.bin

    DYW9HZ-308-1002R17.bin

    DYW9HZ-308-1002R19.bin

    DYW9HZ-308-1002R22.bin

    iCamera2 Firmware Files

    DAXNHZ-104-300114.bin

    DAXNHZ-105-300124.bin

    DAXNHZ-105-300126.bin

    DAXNHZ-106-300128.bin

    DAXNHZ-106-300129.bin

    DAXNHZ-108-300132.bin

    DAXNHZ-110-300229.bin

    DAXNHZ-110-300230.bin

    DAXNHZ-111-300235.bin

    DAXNHZ-111-300238.bin

    DAXNHZ-111-300239.bin

    ReplyDelete
  9. Seriously thankful I found this page. TWC's cameras use the same firmware as Xfinity. I had some iCamera-1000-ADT that I ordered, but their firmware rendered them useless with my TWC touchscreen. I used the URL from your info above to download the Xfinity firmware, flash the ADT cameras, and now I have two more working cameras! Thank you!

    ReplyDelete
  10. Alright Troy,
    it took me some months to get some time to mess with the System. I was able to get the user and pw of the security router after the setup but I am not getting anything for the camera and the smartvue cloud dvr. Need your help brother.

    ReplyDelete
    Replies
    1. Unfortunately, I'm not on Comcast anymore and don't have the home security package from Cox either. When I left, though, the "security router" had been merged into the "cable modem" so that one device did both functions. Thus, there's no user/pw of the security router (that I'm aware of). If you have a security router, it should be possible to connect a sniffer to the inbuilt switch and (using an ARP spoofing attack) get it into non-switched operation, at which point you should be able to sniff the access passwords to the cameras. That is what I did originally -- but you can't modify their settings or anything else in this manner.

      If you have the integrated router, you can remove the cameras from the system (touchscreen) and then add them back in, sniffing the ethernet while they are added to the system. This is what I did in this post.

      But I have no idea what a "smartvue cloud dvr" is -- I'm guessing that is a new Comcast feature that was never available to me.

      Delete
  11. Thanks for the reply Troy, the "smartvue" is a company that Legacy TWC contracts with to handle the recordings to a cloud base account. They give you this small android tv box but with android stripped and a linux os that seems locked down. I was able to get the new username and password from the security router after it was secured by the Icontrol tca2013a touchscreen. But once the tca203 change the surity settings, everything from there was encrypted to https and the packets were garble. Mind you, I am on a windows system using cain & abel and also wireshark. Cain and abel for some reason stopped giving me packets from the security router after the system changed to it's own settings. The security router is a netgear wnr1000 V1, it's locked down but as I mentioned. I got the Username and password form the packets and I able to log into this router now. I can see the new ssid and password and I tried those credentials on the camera but It was a failed attempt. What I am trying to do is get the new password and username of that camera and the security dvr. Hopefully by doing this I want to get into that cloud account and take my damn recordings shit, if I can even activate the stupid hdmi they disabled would be sweet and would allow me to utilize an outside dvr source.

    Anyways, I hope you can assist with some direction in the methods to get this going. I can't stand the fact that TWC and now Spectrum refuse to allow consumers to control the system but that's a whole different argument that's for another type of thread.

    ReplyDelete
  12. This is Chad Sturgill. Glad I was of some help. I found the SSID, Wireless Password, Account Name, and Account Password in the PCAP when the camera was provisioned. Some of it was passed in the URL post that was sent to the camera. Hope that helps. I am looking to see if there is updated firmware beyond the R22 release. Anyone know? I am trying to integrate these with Monocle Gateway and my FireTV and I think the RTSP settings are not sending the right rendered video to the gateway. Curious if a FW update would help.

    ReplyDelete
  13. Has anyone else's cameras stopped working since flash player was murdered?

    ReplyDelete
  14. Hi all cams have more Streams for cideos, mjpeg and so on... rts, rtsp with audio and so on.or a format thats name is .sav. So you must not have any flashplayer to view the cams.

    ReplyDelete
  15. This comment has been removed by the author.

    ReplyDelete
  16. Has anyone found the correct API to turn off the IR system on these? I have to have my cam behind glass and it just doesnt work doing that way. Glass and IR do NOT mix.

    ReplyDelete
    Replies
    1. jwmars, are you able to access the administration area? The setting is under Video & Audio. Day/Night Switch. You'll want day mode (manual)

      Delete
    2. Mine is listed under VIDEO as night_mode=0, I have changed it to 1 and seen no differences

      Delete
    3. Apparently its a combination of stuff in mine under video, there are several dn_ items i had to change to get the IR to go off. Guess we will see tonight what happens!

      Delete
  17. Can't figure out what's the user name and password for the xw4 xcam2 reset the camera and all tryed all of the default codes and usernames I could find even administrator and leaving the passcode blank

    ReplyDelete

Search This Blog