A few months ago we got a dog and like most dog owners we were interested in what our little pooch gets up to when we’re not around so ended up buying a camera to keep an eye on it.

After having a quick scan of the internet I ended up buying the camera below. It looks pretty cool, can pan and tilt and has a nice little app for on my phone.

Figure 1 – Webcam Picture on Amazon

The device itself if pretty easy to configure with a handy QR code on the underneath and the accompanying app which is in the app store called ‘iSmartView’ is pretty straight forward too. It just works… which often makes me suspicious.

Now fancying a little Xmas project I thought i’d take it to bits and see if it looked interesting inside.

Disassembly was easy with only a few screws holding it together.

Figure 2- Webcam in bits

Now looking at the board it looked like there was a good chance that we’d be able to access it via UART, see bottom right hand side highlighted in red.

Figure 3 – Camera board and UART ports

In order to be able to continue with this project I was going to need a soldering iron, multi-meter, UART to USB converter and a couple of other bits and bobs.

At this point I already had a blog post in mind so thought I’d make it as accessible as possible and pick up some bits off Amazon on the cheap.

I bought the kit below which contains a multi-meter and soldering iron

Figure 4 – Soldering Kit

And also picked up a UART to USB converter.

Figure 5 – UART to Serial Converter

Now that we have the kit the next thing we need to do is start to figure out which pins are which. Finding GND is first and the easiest to do.

On the multi-meter set it to test for continuity which looks like below

Figure 6 – Multi-meter set to test continuity

With the black lead find something which should be grounded, I decided to use the SD card slot cover and with the red lead touch each of the four pins one by one.

Figure 7 – Testing Pins

When you find ground the multi-meter should emit a beep and the LED under the light button should light up.

From the picture above the second pin down should be GND. Now we have found GND we need to change the setting on the multi-meter to find out the voltage of the other pins. Move the wheel so that it’s pointing to 20 as below.

Figure 8 – Multi-meter set to test volts

Now rinse and repeat as above with the other pins to get a read. Also reboot the device and take readings whilst it is rebooting.

The first pin fluctuated when booting but was stable at 3.1v once the device had been running a while, the second pin is GND, the third and fourth pins read 3.2v.

All the pins are live so looks like a connection via UART should be possible. Time to break out the soldering iron.

I have no tips for soldering…. as my pictures indicate… I need more practice

Figure 9 – Wires soldered to pins

I decided to only wire the first three pins on a hunch as we only need RX, TX and GND.

Now time to connect to our UART converter.

Figure 10 – Connected to the UART module

Our UART device is clearly marked as to which pins are which, the first to connect is GND. The second is RX (READ). Now given the first pin on the board fluctuated on boot my hunch was that that might be RX so I connected the first pin on the board to RX on the UART converter.

The device properties of the UART converter said that it was on COM3

Figure 11 – UART Device Settings

so with Putty, that’s what I connected to; I changed the speed to 115200 as that’s a common speed setting.

Figure 12 – Putty Configuration

I clicked on Open and turned on the device and was in luck, it worked I could read UART.

Figure 13 – Working UART Connection

When testing for RX if you get garbage to the screen, change the speed setting and that should hopefully sort it out.

I connected the third connector to TX (WRITE) and rebooted, and again as luck would have it, it allowed me to type data.

I waited for the device to finished booting and it eventually went to a prompt.

Typing in ‘whoami’ revealed that the device was running as ‘root’ – w00tw00t we’ve got control of the device.

Figure 14 – W00tW00t

Time to poke around a bit more.

A large number of embedded devices run BusyBox, so let’s see. Typing busybox gives us a number of commands which can work with, one of which is telnet.

Figure 15 – Linux Version Information

A useful busybox trick is to start telnet as below which will enable us to establish a connection without the need for authentication on port 9999.

Figure 16 – Starting Telnet

As expected we now have telnet access to the device – Success!

Figure 16 – Establishing a telnet connection on port 9999

Now that we have telnet access to the device we can explore a bit more.

Figure 17 – Nmap scan of Webcam

Running an all ports nmap scan of the device reveals that there are a few ports open including http (which wasn’t mentioned in the little manual which accompanied the camera).

Navigating to gives us nothing so via the established telnet connection I did a find -name *.html to get some help.

Figure 18 – find output of html pages

I decided main.html would be a good candidate, however was then presented with a login box. Once again the established telnet connection was useful and under /etc/webserver were the credentials needed to login.

Figure 19 – webserver auth file

I could have guessed admin:123456 also as these are the device default creds.

Access to the admin web interface has now been granted; time to fire up Burp and start having a look around the interface.

Figure 20 – Web interface

After navigating manually around the web application and clicking on most options, Burp started to look quite interesting.

Figure 21 – Burp Target Information

On the Target tab we can observe that the application is making a number of GET requests to a number of CGI functions and is passing a cmd parameter each time.

E.g. –

Now rather than Fuzz the application via Burp I thought it’d be interesting as we have access to the file system to see if the CGI files gave anything interesting away.

So again over to the Putty screen, let’s do a find for *.cgi

Figure 22 – CGI files on the webcam

Checked each one of those files for strings to see if there was anything interesting. The most telling was hyipc.cgi.

Strings on its own gave a lot of information, to to try and narrow things down I then grepped the strings data for *.cgi

Figure 23 – CGI Strings information

I also grepped for get

Figure 24 – get Strings information

and to make things complete set also

Figure 25 – set Strings information

Now the eagle eyed amongst you may have noticed that about half way down both the get and set commands there is a gettelnetstatus and settelnetstatus.

Is there a hidden factory feature to turn on telnet? and how to test all the other get commands in a methodical manner quickly?

I saved the names of the CGI functions to a file, the set commands to a file and the get commands to another.

Back to Burp – Time to ClusterBomb the camera.

I sent a previously captured GET request to Burp Intruder and set the positions which I wanted to manipulate.

Figure 26 – Burp Cluster Bomb

I then configured the lists for each position

In Payload set 1 I added the list of cgi file names which we pulled from the strings.

Figure 27 – Burp Payload Set 1

And in Payload set 2 I added the get commands

Figure 28 – Burp Payload Set 2

I then launched the attack.

From the results gettelnetstatus works with the factory_param.cgi function and has a variable of enabled which was set to 0 (disabled)

Figure 29 – Burp ClusterBomb results

It would be fair to say we could take an educated guess as to how settelnetstatus is going to work.

Figure 30 – settelnetstatus enable success

From the Success message we can imagine that telnet should now be available on port 23.

netstat on the device show that we now are listening on both 9999 and 23

Figure 31 – netstat output from camera

Connecting to telnet on port 23 is a success however we are required to authenticate using the default credentials.

Figure 32 – connection to telnet via port 23

Restarting the device also confirms that telnet will survive a reboot.

The focus of this post was to discuss the hardware hacking side of this device, which hopefully it has and hopefully will be found useful.

We’ve looked at how we can determine which ports are which and also find hidden functionality.

Figure 33 – Final Pin Output

There are a number of other security issues with this device which go beyond the scope of this post. Needless to say there’s a fair amount of changes needed to make it anywhere near secure.

Because this camera requires quite low power 5v it can also be connected to a battery pack which also gives some interesting options as a covert camera

Figure 34 – Covert Cam

Please leave a comment or Tweet me if you found this useful.

2 Replies to “Where UART thou?”

Leave a Reply

Your email address will not be published. Required fields are marked *