6 min read
Do you own a hubble/blink/monitoreverywhere device and want to view the camera stream bypassing the proprietary software? Point your multimedia player to
Since I got a log of comments saying it does not work any longer ... here is the stream URL for the latest firmware (change the IP to your camera's):
$ mplayer rtsp://user:firstname.lastname@example.org:6667/blinkhd/
Some time ago I bought this little and neat network attached camera baby monitor from Motorola called the FOCUS66-W.
It is advertised as being integrated to the hubbleconnected.com cloud service that allows you to control your cam via smartphone and to watch and record your streams from any internet capable device (Browser + App).
Despite the shitty Android app and the Adobe Flash driven website, it really is a cool device with some nice feature for such a small device and price tag:
- Good infrared night vision
- Motion triggered video snapshots and notification
- Two way audio communication
- Temperature sensors + alarms
- Playing lullabies
But as you might know from other embedded hardware projects, this kind of toys always suffer from security problems. At least that was what I hoped for when I asked myself how to obtain the video stream and directly play it on any device. So I started investigating.
Before I started to investigate I wrote an email to their support asking why they use this securtiy nightmare called Adobe Flash to view the videos on hubbleconnected.com. Their answers was support bullshit - even though it came from the dev department - and so they left me no choice. :)
Having a look around
So, what is our starting point?
- we got a camera connected to the local wifi
- an app used for controlling the camera device and viewing the stream
- a cloudy space somewhere at Motorola as a possible synchronization point
So for 1. you guessed right ... we fire up nmap:
$ nmap 192.168.1.25
Starting Nmap 6.47 ( http://nmap.org ) at 2015-02-20 12:51 CET
Nmap scan report for 192.168.1.25
Host is up (0.058s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
80/tcp open http
6667/tcp open irc
8080/tcp open http-proxy
Nmap done: 1 IP address (1 host up) scanned in 2.20 seconds
Well, I expected to see 80, but what is up with 6667 and 8080. We will - maybe - see in a minute.
Let's step back and think about how the communication between the cam and app is done. There are two possibilities, with or w/o signalling done by the cloud:
- App Cloud Cam
- App Cam
To this point we don't know and we need to investigate a bit further.
There is an pretty easy way to intercept all network traffic produced by your smartphone by creating a monitored wifi using hostapd, a bridge to your LAN and Wireshark. The actual setup depends on your specific settings but you may use this as a good starting point.
After we setup the bridged wifi and connected the smartphone to it, we fire up Wireshark on the interceptor and start the hubble app on our smartphone.
(Next step: pull out the interesting bits from the wireshark log.)
The app startup leads to three interesting communication streams as seen from the log file.
- The app calls some (unencrypted) RPC methods on port 80 on the camera device, such as:
This looks like initialization of the camera stream.
- In parallel it makes some encrypted calls to the hubble API (?) that I have not looked into yet.
- After the initialization is done the app opens up an RTSP Session to port 6667 on the camera device in the local network. If you do not share the same network it will fetch the vids out of the cloud.
And yupp ... that stream is what we are looking for! <:o>
- Not so interesting for our investrigation to obtain the camera stream but it says quite a lot about coding standards at the manufacture: the app also makes a call to
. Yupp right ... nodeapp ... naming things ... hard.
- The app also fetches the camera event history pictures that are shown on the dashboard unencrypted from
Obtaining the video stream
In the last paragraph we found out where the video stream is hosted and that we could access it from the local area network. But the moment you fire up VLC to access the stream you will get prompted with a username and password input.
A second look at the Wireshark log tells us that they implemented a digest authentication, so no simple sniffing possible - as for eg. basic auth. To bad. :(
So what you could try next if you live outside of germany is to get you a copy of John the Ripper with activated hdda plugin and try to crack the username and password right of the data you obtained from your wireshark log.
But that is illegal in germany. What about reverse engineering the app to extract the username and password? Naah, that may be illegal too.
Ok, ok what about brute forcing the shit out of your cam? Nope illegal too and they will never ever have used a trivial password as found in any dictionary!!
And that is the moment when you remember your good old friend strings. Simply apply it to the unzipped APK and look what happens:
$ strings -a -t x classes.dex |grep -C2 rtsp
Oh yes, that's a complex password ... not.
Now point VLC to
and you are ready to go.
After I got all the nfo that I needed to view the camera stream I played a little more with the APK and the wireshark logs.
The camera seems to be Nuvoton N329 as indicated by the RPC repsonses from the camera device.
Although the camera is labeled with the Motorola logo and managed by hubbleconnected.com you find a lot of reference to a second similar service called monitoreverywhere.com.
The app itself is developed by Hong Kong based company called CVISION. They also provide some links to test videos in their app. Say hello to one of their devs (^^):
There are also a lot more commmands that can be triggered by the RPC web interface. Just check classes.dex with the strings command.