Some quick searching found that this same chipset is used in countless other IP cameras. However this model differs from most in that it does not try to connect to a remote server where video would be stored and viewed. Instead this device displays its video stream directly to its companion app on a smartphone connected to the WiFi network it creates. I found Alex Porto's blog posts about reverse engineering another camera based on the same chipset and used them as a guide on how to get started reverse engineering the iNite. Wireshark showed traffic between my computer and the camera, but didn't provide any meaningful information other than that the camera's IP address was 192.168.39.1. A scan with nmap showed 4 ports available:

  • telnet on port 23 (!)
  • a lighttpd server on port 80
  • an irc server/ backdoor? on port 6666
  • something else on port 8000

Let's try that telnet port. Will it be as easy as logging in as Root?

Easy as Root? Yup.

Success! That was easy. The camera has serial port pads labeled on the board, but since we have telnet working we don't need them. What can we learn about this camera?

That's not very helpful.
That's better.

So we know this camera is running on Linux 3.10. In Alex Porto's case, all camera functions were controlled by one process named ipc. What about on the iNite?

Top shows plenty of promising candidates for further research. rtspd looks particularly promising for finding a video stream, and lighttpd might be the server on port 80 from before. Lets look at the config file rtspd uses:

That's very promising. Let's try it out. Opening up Mplayer and pointing it to rtsp://192.168.39.1:43794 results in success! 

Some glitching, and a grainy image, but success!

Let's go back and look at that lighttpd server. Opening 192.168.39.1 in a web browser opens a login prompt. Unfortunately the normal guesses don't bring any success. Looking around in /etc/lighttpd/lighttpd.conf gives us a few places to look. Peeking around /usr/conf gives us multiple promising files to look at. After some quick googling, its clear that htdigest_admin.txt and hrdigest_user.txt contain the username, realm, and digest of a md5 hashed user/password combination. The wikipedia page on Digest access authentication was very helpful as a primer on password hashes and how md5 works. Another quick google search yielded the following linux command to test passwords and compare their hash to the correct hash of lighttpd's.

echo -n "username:realm:password" | md5sum

 In this case the command is 

echo -n "admin:realsil:passwordguess" | md5sum

Looking up a list of the 25 most common passwords and testing them manually finds that the password is 123456. That wasn't too hard. Logging into 192.168.39.1 with username: admin and password: 123456 brings us to a management GUI with plenty of options to tinker with.

 I'll experiment with this more in the future. 

Conclusions:

  • Root shell access and management GUI access on this device are trivial to achieve.
  • Out of the box, the camera video stream is grainy with obvious compression artifacts and ~250ms of latency. Hopefully this can be improved with modifications to the default configuration.
  • I would not trust this camera on a network with an internet connection, which seems to be an option through bridging in the management GUI. The default configuration is an ad-hoc connection between the camera and whatever devices connect to its WiFi, so the camera's glaring security problems should not pose a real threat out of the box.
  • Night vision mode gives the video a paranormal hunter look. This, combined with the stuttering the video stream has, could be used to recreate this effect on a low budget.
  • This Github and other sites suggest that the toolchain used to build linux for this SoC is mips-linux-uclibc-gcc-4.8.5_rts3903 and lists Realtek rsdk-6.5.0 as another possible toolchain. I haven't found a source for either of these toolchains yet.
  • The device times out and turns off after...
Read more »