Recently, my partner and I bought a double pack of the Motorola FOCUS66 cameras, see here: We made this purchase because we had our Siberian Husky bred and wanted to keep an eye on her during the pregnancy while we were not home. As well as at night we can keep an eye on her from bed. Upon the purchase I setup the cameras, downloaded and installed the app on my phone and got things going within 10 minutes of unboxing. The setup is very simple and the cameras worked immediately. However they do have a downside. There is no Windows client offered for your computer. They only offer a remote website to view the panel while logged into your account that the cameras are registered to.

• Motorola Vip1216 Owners Manual

So obviously the cameras are streaming the data to their website while someone is connected for viewing. (This is a bit creepy knowing that these cameras stream to their website on request after it is registered to an account. But that is a different debate/post.) So I wanted to figure out a way to get the camera working locally on my PC without needing some emulation for Android/iOS etc. Searching the net I couldn't find any info on these cameras, such as how they connect to the net, how they broadcast data, etc. So I was on my own figuring things out.

Granted this isn't really rocket science to do. Analyzing The Device Already from the start, we know that this thing connects to our router wirelessly. And the setup method it used to get them working kind of hints towards some 'black magic' going on in the camera. So I looked at our DHCP table for the two cameras and grabbed the IPs of both. First, I decided to test for any known services running on the devices, to see if the OS type was exposed. So I hit the cameras with telnet requests for basic stuff like FTP, SSH, etc. And got nothing.

Then I checked for a webservice running, bingo. Both cameras are hosting a web server locally on the device.

However hitting the device we are greeted with the following. Code: 404: Not Found! File not found! Not useful at all. So I loaded up a web-crawler app to try and crawl out some directories and files from the device.

For this I snagged: w3af I used the default dictionaries that come with the app for the scanning and landed up finding only: - Found Directories: /cgi-bin/ - Found Files: test.html But the test.html file was more then enough to get some information from the device. Test.html Information / Functions The test.html file shows a fairly crappy panel of basic test functions. I assume this file is used in the factory for basic testing before the device is packaged and shipped.

Reading through the source of this file, it shows us that the web server is actually hosting the required files for the device to be communicated with. The main handling engine takes input commands like this: From this file alone, we can find a collection of possible commands: - getbrightness - valuetemperature - valueresolution - panplus / panminus just to name a few. Scrolling all the way down in the source we can see the file is trying to include a web object (vlc plugin) directed at the page: So now we see a local address for the video (which is incorrect) and a new path /blinkhd. So I tried going to the /blinkhd sub page and got nothing, so this file has to be accessed via the rtsp protocol.

Accessing The Video Stream Knowing now that the stream is broadcasted via the RTSP protocol, I know that VLC media player can use those as one of its viewing options. Popping open VLC player and entering the proper path to the feed, I was greeted with a username and password prompt on one of the devices, and not the other. (More info on that later, heh.) I took about 15-20 guesses to get the combo correct, sadly. The stream uses a default username and password combo of: - Username: user - Password: pass Not exactly the best security measures put in place. This would be nice to be configurable by the user to prevent unwanted access watching the stream but hey. It was a cheap set of cameras so what do you expect?

So at this point I am able to watch both cameras. But I wanted to know more about the cameras firmware and why one camera wanted a login and the other didn't. Digging Deeper. Digging deeper into the camera information, I started Google'ing some key words from the test pages I found on the devices. blinkhd - Various allowed commands shown in the html of the test page. I came across a site with similar intentions for another camera. Sadly the information was not shown in my original searches since the cameras are different in some ways so my previous searches weren't close enough to get me to this persons site.

His site revealed some other pages that are on the devices web server that also worked on mine. One of which helped reveal some more information on the device which was: This is another landing page to the camera showing off more features you can tinker with command wise, as well as two variations of the stream viewer. However, again, the pages have hard-coded IP addresses and do not work properly. The other fun-fact with this specific camera we have is that it seems like the firmware was rushed and not meant for this camera as files are missing. Links, Files, and Overall Information At the end of the day after tinkering with the camera I came up with the following information for our specific set of cameras: - Main Test Page: - Second Test Page: - Java Viewing Page: (Does not work because required Java applet is not on the device.) - Java Applet (Missing from devices): - Stream URL: rtsp://192.168.2.37:6667/blinkhd (May require username/pass.) - The username / password combo to the stream, if required, is: user / pass - Commands are sent via: - Firmware upgrades are done via: One Stream But Not The Other! As I mentioned above, one of the streams requested a password while the other did not.

This is because the two devices, packaged and shipped together, (completely same model etc) had two different firmware versions. That's right, two separate firmwares rather then both having the same. I'm not quiet sure how that happens but it did lol. The older firmware did not care for a username and password while the newer one did. The firmware information for the devices are: - MBP2000W (01.16.46) - This camera wanted the username and password. MBP2000W (01.15.04) - This camera did not want the username and password.

Quite strange that two cameras in the same package are running two separate, but both equally incomplete, firmwares. The firmware used definitely does not look like it was made for these cameras specifically and was rather half-ass ported to them just enough to 'work'. Hey buddy, I found your forum searching for info on this camera. As per your discovery, I managed to get the RTSP stream working, so cheers for that.

VLC commandline on my Mabook is:./VLC 'rtsp://user:pass@192.168.1/blinkhd:rtsp-caching=0:udp-caching:0:tcp-caching=0:network-caching:0' I don't think any of the caching commands are working to be honest, still a fair bit of latency- I think it's just VLC on OSX though, I had a similar issue with a HTTP stream coming from a remote control tank, wasn't a thing when you viewed the stream in Chrome. Of interest, however, I briefly had access to a Telnet server on the device while in pairing mode which showed a fairly Linux filesystem using BusyBox, like you'd find on any embedded device. Seemed to be superuser privileges. So, maybe an option to exploit things there.

I think I'll open the case up later and see if there's a serial or TTL header that ties into one of the TTY lines without any need for authentication. Telnet server disconnects me the minute I connect now. Found this while looking to do the same thing to the Motorola MBP85 that I bought. I wanted to add some things that I discovered to your list: Since they don't make an app for windows phone and the webpage is flash based, hubbleconnect is useless to me. I really wanted to be able to use third party apps such as ip cam controller (on my phone) or blue iris on my server, or at the very least, it would be nice to be able to log into its IP address directly. The summer infant cam works the same way unfortunately. When I access the webpage on my PC and use wireshark, I can see it receiving the stream from an IP address that take me to a page that shows 'Wowza Streaming Engine 4 for Amazon EC2 4.1.0 build12602' I believe this is an Amazon server that allows embedded devices to upload data.

I did a bit of snooping with nmap and found that port 80, 6667, 8080, and 464 was open. It also shows the OS of the camera to be Linux 2.6.16 - 2.6.35 (embedded). Using blue iris, I tried multiple camera configurations and actually got video using the A-Link IPC1 JPEG settings, which use the URL. That gives me basic functions in blue iris but I still don't have PTZ control, two way audio or any way of changing camera settings via blue Iris. The pages you found definitely help though.

Also, putting URL into my browser will show a still image. Is another page I came across. Hi, Has anyone gotten any further with this? It is a great little device with Camera, Mic, Speaker, Thermister, Wifi and possibly USB at a good price. All Pro's But the main con for me is lack of security and the fact it just seems to be happily streaming everything to a 3rd party server. Things I would like to know: - Is that a fully working USB port on the back?

- Are there any ports inside available for digital I/O or some other comms I2C, etc (could be handy for adding buttons and sensors). How to get root - How to block streaming to 3rd party server - How to block remote updates (which might override any hacks) - How to build and upload a custom/modded firmware.oddllama.: For those of use new to hacking, could you explain how your extracted your information. I have a later firmware version and some of the information in the original post has changed. I'll update if I get a response.

Motorola Vip1216 Owners Manual

This helpful, if disclaimer-rich, is uncharacteristically open about the option to hack your Motorola DVR and get the video from it to a PC.but some people on their own have devised a way to access digital recordings on the DCT6208 or DCT6412 and offload them to a PC hard drive or Digital High Def VCR. Here's how to transfer non-copy protected recordings via IEEE1394/Firewire. I wish all manufacturers were so open an honest about the hackability of their products. The DCT6412 (or is it the 6408?), by the way, is the DVR that Eastlink offers here in Prince Edward Island for $14.95/month.