atom0s

atom0s

Self-taught game hacker, game modder, reverse engineer. He/Him #gay :rainbow:

“Hacking” The Motorola FOCUS66 Camera

6 minute read

Recently, my partner and I bought a double pack of the Motorola FOCUS66 cameras, see here: https://www.walmart.com/ip/Motorola-FOCUS66-B2-WiFi-HD-Home-Monitoring-Camera-2pk-Black/39173367

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. 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:

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:

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:

http://192.168.2.37/action?command&command=<command_here>

From this file alone, we can find a collection of possible commands:

  • get_brightness
  • value_temperature
  • value_resolution
  • pan_plus / pan_minus

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:

<param name="MRL" id="mrlVideo" value="rtsp://192.168.193.1:6667/blinkhd" />

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:

http://192.168.2.37/blinkhome.html

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.

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: http://192.168.2.37/test.html
  • Second Test Page: http://192.168.2.37/blinkhome.html
  • Java Viewing Page: http://192.168.2.37/java.html (Does not work because required Java applet is not on the device.)
  • Java Applet (Missing from devices): http://192.168.2.37/cambozola.jar
  • 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: http://192.168.2.37/?action=command&command=<command_here>
  • Firmware upgrades are done via: http://192.168.2.37:8080

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”.

Comments