Blog: How Tos

Hacking the IP camera (part 1)

David Lodge 10 Apr 2015


In recent months my family’s shopping habits have changed, no longer do we mostly go to the big supermarkets, instead we go to the discount dealers.

My better half assumes that this is to economise on the basics but in reality it’s because I’m addicted to browsing through the piles of tat that they sell.

Most of this tat is indeed utter rubbish and ends up getting binned, but occasionally there’s something worth hacking about with.

In this case I was in the local Aldi, and while trying to prevent my kids eating each other due to boredom I came across a Maginon Vision “security” camera.

It boasts outdoor design, wireless connectivity, infra-red mode, cloud access, and mobile app control. All of this functionality comes at a semi-decent price too.

What could I do, other than buy it, and rip it apart?

The camera unit

The unit uses Power over Ethernet (PoE) to provide power and access to the Ethernet front end. It has a wireless connection too. Later testing showed that only one of these interfaces can be used at a time, and that the wireless interface takes priority. Strangely enough if you disable the wireless interface it will copy that IP address to the Ethernet one.

The Ethernet address assigns itself a static IP of which we can portscan:

C:\Users\dave>nmap -p1-65535

Starting Nmap 6.40 ( ) at 2015-04-08 10:10 GMT Daylight Time
Nmap scan report for
Host is up (0.013s latency).
Not shown: 65532 closed ports
23/tcp   open  telnet
80/tcp   open  http
8600/tcp open  asterix
MAC Address: 00:6E:07:87:10:AE (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 41.36 seconds

Interesting titbits; telnet, http and what is that on port 8600/tcp? As it’s a camera it’s likely that the errant port is some flavour of video stream.

The http port leads us to the management front end. Nothing exciting there. Interestingly enough it uses basic HTTP authentication (i.e. the base 64 encoded username and password are passed with each request) to authenticate the user. This isn’t very secure, but it does make it easy to handle. There is also no SSL option to encrypt the management traffic.

The telnet port gives a prompt for credentials, but the default credentials (admin and no password) don’t work so it’s likely that the user isn’t meant to use telnet.

Getting into the camera

Right, so we’re in a situation where we have the camera, some dodgy ports and a default administrator password on a web interface. A quick web search on “8600/tcp camera” brings up a couple of interesting results for similar cameras:

These are substantially different cameras from other manufacturers, but all show a similar profile to the one I bought. There’s one way to check this; they all found out the root password for the device as “123456”. Now let’s try it out. Note: This is now running on my wireless network to make it more convenient for me, hence the IP address change:

[dave@jotunheim ~]$ telnet
Connected to
Escape character is ‘^]’.(none) login: root

BusyBox v1.12.1 (2012-11-21 22:17:05 CST) built-in shell (ash)
Enter ‘help’ for a list of built-in commands.


Well, that was easier than expected! So I’m going to back track and work this out from first principles, by going for the firmware.

The firmware

Searching the various sites referenced in the camera’s documentation gave up nothing about the firmware for this specific device, although I did find firmware for similar models. While abusing “similar” firmware can give you hints about what utilities are installed it’s best to get the specific firmware.

In the end I found the firmware in a most unusual place: In the app that came on a CD with the camera. Yep, physical media, how quaint!:


There appear to be two separate areas:

  1. sys_supra – the system firmware itself, which contains the operating system
  2. web_supra – the files for the web front end. These have probably been separated out to allow easy customisation and branding of the interface

So, let’s throw one of these into a hex editor. The format is kind of familiar to me, but I’ve colour coded some of it for clarity:


The value highlighted in green (0x50, 0x46, 0x03, 0x04; i.e. “PK”) is the pattern for a zip file. The rest of the following structure adheres to this pattern (e.g. the filename highlighted in orange).

The 32 bit value in blue, taken as a little endian integer is 0x0009bc8e, is 638094. This is close enough to the file size to be a pointer for the files content:

[dave@jotunheim ipcam]$ ls -l sys_supra_ipc20c_81.2.1.152.bin
-rwxrw-rw- 1 dave dave 638162 Sep 29 2014 sys_supra_ipc20c_81.2.1.152.bin

The means the stuff in red is most likely just a header. The “wifi-camera-sys-get” is obvious, but the rest of it is unknown.

But what does this really mean? It means we can extract the firmware by simply chopping off the red and blue bits from the front of the file. I used dd for this to skip the first 36 bytes:

[dave@jotunheim ipcam]$ dd if=sys_supra_ipc20c_81.2.1.152.bin bs=1 skip=36
638126+0 records in
638126+0 records out
638126 bytes (638 kB) copied, 1.28828 s, 495 kB/s
[dave@jotunheim ipcam]$ unzip -l
Length     Date    Time  Name
——— ———- —– —-
0 09-23-2014 20:17 system/
0 09-23-2014 20:17 system/init/
203 09-23-2014 20:17 system/init/

…and now we have a decompressed version of the firmware! We can’t find an obvious /etc/passwd file, but if we grep for the word passwd, then we can find it in the binary file system/bin/daemon.v5.7:

[dave@jotunheim system]$ grep -ir passwd *
Binary file system/bin/ftp matches
Binary file system/bin/encoder matches
Binary file system/bin/daemon.v5.7 matches

It’s possible that it creates the file on initialisation, so let’s just strings that file to dump all things that look sort of stringy:

[dave@jotunheim system]$ strings system/bin/daemon.v5.7
ps > /tmp/gps.txt
fopen failed
/system/system/bin/encoder &
this isn’t system file

Oh look, that’s exactly what it does. It creates the passwd file on the fly. This has a side effect that it may not be possible to change the root password. This means that it’s always vulnerable to exploitation to anybody on the same network. Fail.

For completeness, let’s just throw the passwd file into John the Ripper (as I don’t have hashcat installed on that VM):

[dave@jotunheim ipcam]$ echo “root:LSiuY7pOmZG2s:0:0:Adminstrator:/:/bin/sh” >passwd
[dave@jotunheim ipcam]$ john passwd
Loaded 1 password hash (descrypt, traditional crypt(3) [DES 64/64 MMX])
Press ‘q’ or Ctrl-C to abort, almost any other key for status
123456 (root)
1g 0:00:00:00 100% 2/3 3.030g/s 6809p/s 6809c/s 6809C/s 123456..magic
Use the “–show” option to display all of the cracked passwords reliably
Session completed

The web firmware

Now we’ve cracked open the system firmware, the next step is the web firmware. Chopping off the header gives us a valid zip file, but it appears to be password protected:

[dave@jotunheim ipcam]$ unzip
[] www/appversion.txt password:

Of course if it is protected then the password will be stored somewhere so that it can be extracted in the first place. The best place to look for this is in the system firmware, passed as a parameter to the unzip command. Time to break out grep once more:

[dave@jotunheim system]$ grep -ir unzip *
Binary file system/bin/encoder matches
Binary file system/bin/unzip1 matches
Binary file system/bin/daemon.v5.7 matches

Oh look, system/bin/daemon.v5.7 again. Let’s strings it and grep for unzip:

[dave@jotunheim system]$ strings system/bin/daemon.v5.7 | grep unzip
unzip1 -o -P vstarcam!@#$% /tmp/ -d /system
unzip -o /tmp/ -x system/system/bin/daemon* -d /.
unzip -o /tmp/ system/system/bin/daemon* -d /.

That looks quite passwordy to me so let’s unzip it:

[dave@jotunheim ipcam]$ unzip -P ‘vstarcam!@#$%’
inflating: www/appversion.txt
inflating: www/crossdomain.xml
inflating: www/index.htm
inflating: www/branding/branding.js

There. We now have the decompressed web files, the system files and root access to the device! In my next post I’ll turn my attention to the cloud features of the device.