Smartwares C723IP Camera, 0-Day Vulnerabilities



This is a writeup for some vulnerabilities that I found in the Smartwares C723IP Camera.
I’ve contacted the seller of this camera regarding my findings, but they didn’t respond. Enough time has passed where I feel it is appropriate to post this writeup.

Required Hardware:

Required Software:

  • screen
  • JohnTheRipper

For this writeup, I’m going to be using the Attify badge. All the steps will be the same no matter which device you are using. In addition, I’m running all of the tools on a Ubuntu based distribution.

Before taking the camera apart, I connected it to a test network and ran a nmap scan against it:

  • 23/tcp open telnet security DVR telnetd (many brands)
  • 80/tcp open http mini_httpd 1.21 18oct2014
  • 554/tcp open rtsp
  • 8081/tcp open blackice-icecap?

Looking up that version of mini_httpd shows that there are two buffer overflow vulnerabilities:

Fantastic start. But I want to keep looking.

There is also a telnet service running, which isn’t a documented feature. We’ll keep this in mind for later.

Casing removed, the camera looks like this:

To the left to the lens, right below the screw, there are a row of headers.
I’m interested in the top three of them. Labelled RX,TX, and GND.
TX = Transmitting
RX = Receiving
GND = Ground

The first step would normally be using a multimeter to determine which header is which, but thankfully the manufacturer of this camera labelled them for us. There’s also a hole, so soldering the jumper cables to the board isn’t really required here.

Make sure that the camera is unplugged from its power source before continuing.
Connect the TX on the camera to the RX on your adapter of choice from the above list. Repeat this for the camera’s RX to the adapter’s TX. Finally connect GND to GND.

You can now connect the adapter to the computer.
Confirm that the computer can see it by running “ls /dev/” and looking for “ttyUSB0”.
If you have multiple ttyUSB’s, unplug the adapter and run the command again, taking note of which one is removed.

Download the script and make it executable with “chmod +x”.
Running the script will automatically check for “/dev/ttyUSB0”. You can supply a different path with the -p argument if yours isn’t USB0.

With the script running, plug the camera into a power supply and within seconds you should be able to see output. If the text isn’t displaying properly, you can use the up and down arrows to change the baud rate.
In the case of this camera, a baud rate of 115200 worked for me.

During the boot, I noticed two more issues.
Both the WiFi’s PSK, and the user-set credentials for the web panel are being shown in plain text.

  • get user0:admin:password123:0

  • user0:name:admin,passed:password123,leave:0

  • ssid=testnetwork

  • pass=supersecurepassword

Let’s see what else we can find.

Once you have the baud rate you can close out of the script and execute screen, supplying the path and the baud rate. Make sure to run this as root as well.

sudo screen /dev/ttyUSB0 115200

And boom, unauthenticated root shell on the camera!


If we check out /etc/passwd, we can see the root password stored as a salted MD5 hash.

Let’s try to crack it using JohnTheRipper:

and it took an entire 32 seconds to brute force on my laptop…

Such a secure password.

We can now telnet into the device as root with the new found creds of root:apix:


When checking to see if these vulnerabilities were already disclosed, I found this post regarding a different vulnerability found in some WiFi cameras back in 2017:
It seems that Smartwares is one of many companies purchasing re-branded generic IP cameras from a manufacturer in China.
This post claims that over 1250 different camera models were vulnerable in 20, due to the same software running on all of them.
Since I only have this one camera, I am not able to confirm it, but it seems likely that these found credentials would allow an attacker to telnet into a decent portion of cameras from this manufacturer.

I also plan on taking a look at the web interface and the app, but that will be for later.

If you have any questions or feel that I missed any helpful details, feel free to let me know!


Great to see some love for hardware hacking!
Overall Nice post and breakdown on how one would attempt to start hacking hardware especially IoT stuff, since in my experience most if not all device can be viewed from a similar angle shown here:

  • Often the installed services are way out of date
    • if(CVE and popular service): likelihood of a usable metasploit module ++
  • attempts to “hide” admin accounts were either not made (plaintext creds or publicly known creds) or are so poor that good old John knows what’s up
  • IoT re-branding as new model/different vendor with same old hardware inside

So if firmware is not yet publicly available on the web (e.g. vendor page, (hidden) vendor ftp, somewhere else) one can usually find multiple ways of dumping it for further analysis

(Co-Founder and Part-time Fool ) #3

This is a really nice write-up @y1n, many write-ups take for granted that you know what hardware to use to connect, as well as the procedure.

Really enjoyed this! Keep up the good work :slight_smile:

(Occupi) #4

I really enjoyed reading this and I’m not even that enthusiastic about hardware most of the time! Well done!


Very interesting and well made write-up! You just made me want to buy a similar little (and insecure) device to start experimenting with IoT hacking, it’s something I always wanted to get into.

Have you already tried to write Shodan search queries to find more of these online? It would be interesting to see how many there are out there, because they look like very easy targets for IoT botnets and worms.


Thanks for the info @ricksanchez!
I had a quick look around for publicly available firmware for this device, but I wasn’t able to find anything. The web panel has an option for upgrading firmware, but it asks me to supply the file.
However, this camera has an SD slot, so I was able to copy the entire file system onto a card through that.

This camera was in use for a while before I started tinkering with it, so I have some personal data on here. But I could factory reset it and re download the file system if anyone wants to have a look at it!


Thank you @Baud! I’m still new to the world of IoT hacking, but I’m happy to help if you have any questions once you start experimenting!

I haven’t looked into Shodan search queries for these yet, although I did just get a membership during their Black Friday sale so this would be the perfect opportunity to start looking. I don’t have much experience with Shodan yet; do you have any tips or suggestions for creating queries?

I really appreciate the positive feedback @pry0cc!

(Co-Founder and Part-time Fool ) #8

Shodan queries are something that I struggle with sometimes, but I am trying to make one for this camera, things I usually keep in mind are unique strings in the header/banner, as well as the software versions and ports.

Those things identify them away from other pieces of hardware.

Infact @y1n, do you have the banners? Could you run a banner grab and pull the exact banners from each service? As well as the title and page-source of the http service?


Absolutely! I’ll just need a few minutes to get the camera powered up and connected.

(Co-Founder and Part-time Fool ) #10

You should join IRC so we can do this in a more async environment, will get you there, or


Why thank you, I was thinking about going for a cheap Chinese IP camera from Wish as my very first target, that should be easy enough to start with and then I will work my way up from there, it’s a good occasion to put some old electronics knowledge back to use!

As for the search queries, a simple banner grab with netcat should do the job. These cameras have a web interface so look at the HTTP response you get from them if you connect to one of these through port 80, if you’re lucky you could find the camera’s name in the response and you will be able to use that string as your query. Shodan saves information about devices in a format like this:

    "data": "Moxa Nport Device
            Status: Authentication disabled
            Name: NP5232I_4728
            MAC: 00:90:e8:47:10:2d",
    "ip_str": "",
    "port": 4800,
    "org": "Starhub Mobile",
        "country_code": "SG"

When you use the search engine Shodan will start looking for the data contained in the “data” field, that’s the main part of the response given to you by the device when a connection is received. All the other fields such as “port”, “location”, and “countr_code” can be used as filters like this:

Moxa Nport Device port:80


That’s very helpful, thanks for the advice! I’ll keep you posted if I manage to find anything with the query.

A camera from wish sounds like a great start!
If you decide that really enjoy this kind of stuff, I would suggest checking out Bluetooth devices as a later project. They are a lot of fun, but they definitely require more of an investment to get started with. (An ubertooth costs about $120USD)


Ahh some good old fashioned hardware hacking!! :smiley:


Nice! Always wanted to read a writeup like this, so that i can learn a little bit about hardware hacking. I might as well give it a try on a similar product!

(fxbg) #15

Great one.

Did you solder headers on? I remember using UART on some old games when I worked at an amusement park. The first time I saw someone doing this was on a claw machine where the display died and we had to change the claw strength (according to payout of course lol) before the new display came in.

Excellent guide. You would be surprised how many routers (and everything) has no login when you hook into the UART, sometimes it drops right to a shell :wink:

(system) #16

This topic was automatically closed after 30 days. New replies are no longer allowed.