IP Cameras and Internet of Things in this day and age mostly have serial ports available on their PCB that will allow you to gain root access. They nearly all run embedded Linux and so, with some electronics and Linux knowledge, we can have a look around in the OS.
Note, this isn’t for the faint hearted. If you can’t afford to end up with a paper weight, don’t attempt this. Suppling wrong voltages or connecting the wrong way is a fast way to see blue smoke.
While this might work for some devices, it might not for others. The process is the similar regardless.
Tools you’ll need
- Bread Board jumper leads:
- 3.3V UART/TTL Serial to USB Converter:
- Multi Meter or Digital Oscilloscope
- Linux – but easily do-able with Windows or Mac
Crack it open like an egg!
We’ll be looking at this IP Camera that is sold under different brands but is essentially the same innards. It has an interface available on port 80 and other features you’d expect from an IP camera - SMTP, remote viewing etc.
First step is to disassemble the outer housing. Once it’s out of the housing, the lower half simply twists off. Don’t forget to hold the cable stationary as you unscrew, otherwise it will twist the wire ends in the camera and possibly snap them.
Looking for the Serial UART port
Now we need to go ahead find our interface port. Typically with these types of devices it will be using a Serial UART port. It’s important to have an idea how it works, I suggest reading the page over at SparkFun’s website.
We’re looking for a 3-4 pins, exposed on the board. This one looks like a likely candidate:
Inspecting it further, we can see one pin (P4) is ground. The other 3 will be transmit (Tx), Receive (Rx) and Vcc. It’s always good to confirm the ground pin is in indeed connected by using a multi meter and testing between another known ground source. This is done using the continuity setting. I suggest using a close ground point.
This could be the end if it isn’t a serial port. There’s no guarantee it is until we try it. There’s nothing else that resembles what we need on the PCB.
Probe that port!
When dealing with Serial TTL/UART, it commonly operates on a logic level of 3.3V. There is also 5V and 1.8V - albeit not as common. We need to establish what level this operates on so we can select an appropriate Serial-to-USB converter. This step is extremely important because putting 5V on a 3.3V logic bus will likely do damage.
We have a few choices on how we determine the voltage used. I’ll show you one way to do it using a multi meter. You can also use an Oscilloscope which will also be handy to determine the baud rate later on. But it isn’t completely needed as you can get the same result with trial and error.
Turn the device on and using your multi meter, negative lead on the known ground pin and use positive to probe the other pins while the device is powering up. It’s best to test just as you power the device up since the serial traffic might stop once it has booted. In this case, it’s most likely a 3.3V logic level.
While we’re here, we can try to determine which pin could be Tx and Rx. Reboot if necessary each time since the boot period is when the transmit pin will be doing most of the work. Using the probe on ground and selecting a candidate pin, observe the voltage level. It is normally pulled high to rough 3.3V and will drop to 0V as the bits are being transmitted. You’ll need to have a fairly good multi meter for this as they can be slow at reading rapid changes in voltage and since they measure an average, you wont see much if any change.
Power off for now.
Bring out the converter
To communicate with the serial port of the camera, we need to use a UART/TTL Serial to USB converter. These can be found from Amazon, eBay or Adafruit (linked above). There are a few different manufacturers, picking the right one is tricky. There’s a plethora out there and you do yourself a disservice not looking into the specifics of them.
The key features I suggest: 5V and 3.3V selectable - This saves you buying multiple converters. A DTR lead - Useful for Arduino tinkering and allows you upload to it without manually resetting.
If you’ve found or are using an FTDI converter, there has been some issues using it on Windows (since 2016). FTDI in an effort to stop clones, made the Windows driver inject random data while using it. Hackaday have some more info: FTDI Gate. I suggest either not using an FTDI with Windows or using it on Linux to be safe.
Now that we know where the port is and that it’s 3.3V logic, we need to rig up a way to connect it to our converter. I used some bread board jumper leads since they’re the easiest to manipulate. Be careful you don’t short them together pushing them too far on the underside.
Figuring out which pin is Rx and Tx is just trial and error at this point. You’ll find most often that, Vcc is on the furthest pin from GND, with Tx and Rx in the middle. Focus on the two middle pins first. In this case, it is:
P1:Vcc - P2:Tx – P3:Rx – P4:GND
It’s vitally important NOT to connect the positive lead from the serial converter to the device. Since we’re powering up the camera via its power supply, we don’t need the converters power. If you forget and connect it, expect to see blue smoke. You’ve been warned.
Remember, Tx and Rx need to go on the opposite end for both, so that Tx transmits into the Rx receiver.
Time for the console
With the ends connected to your serial converter, plug it in to your PC. We’ll be using Linux for this but you can do it using Windows or Mac.
There’s a range of different serial emulators to pick from, we’ll be using minicom since I’ve had the most luck with it on lots of other applications. It should be available in your distros repository.
Start up # minicom. We’ll need to adjust it to the baud rate of the camera to be able to communicate with it. More info on baud rates here. Since this time we’re not using an oscilloscope, we’ll have to use trial and error to get it right.
Bring up the setup menu with Ctrl + Z then o (the letter). Select: Serial port setup then press E. A good guess would be to start with 115200 baud rate and go down from there. You’ll most likely need to select your parity, data and stop bits too. The normal standard is 8N1 - I suggest trying Q and R preset first and then adjusting it from there. Read up on those different settings in the previous link.
Enter to exit, optionally save or exit back to the main window in minicom. It will now be waiting to receive data through /dev/ttyUSB0. Power on the camera and take a look:
If you get random junk all over the terminal, you haven’t got the right baud rate and/or bits. You’ll know you’re close to the correct rate when you start seeing legible or semi-legible words. You’ll need to probably reboot your device each time you try since it might not be writing anything to serial once it has fully booted.
We’re in like Flynn! – Sorry Dave, I’m pinching your saying!
Once you’ve got the right rate, in my case it was 115200 8N1, you should be able to see what is going on in the serial terminal. This particular camera is using U-Boot as its bootloader. I also noticed at the start it said to hit any button to interrupt – noted for later.
After it boots, we are presented with a login prompt. The easy default passwords and login names don’t work. A possible dead end! But we can go around it. We essentially now want to change the bootloader’s kernel line so that it drops us into single user mode.
Reboot and hit space to interrupt the boot up sequence and get into U-Boot’s bootloader prompt.
Going with help to start off will give you an idea what you can do. Looking over U-Boot’s documentation, using printenv will give us what we need
A lot of good information can be seen here. In particular we’re interested in the boot arguments line. As with any nix operating system, inserting single or 1 at the end should do the trick for single user mode – we need a root shell.
This is one of those spots where it’s easy to misconfigure the boot parameters and end up with a non-booting device. ALWAYS make a copy of what was there before – by now this should be usual practice.
Copy the existing bootargs and then:
setenv bootargs 'exisiting stuff with single at the end'
Make note of the single quotes!!
Once you check it’s worked with printenv again, go ahead and saveenv then reset.
Mine is cutoff on the right side, though. But it’s there
I am root
If all went well, you should be dropped into a root shell. Check with id.
From here we can check the passwd file and pinch the passwords for cracking them later on with John The Ripper.
Since we’re in single user mode, the normal functions of the camera won’t be operational, while we can have a poke around now, it’s a little better to do so when the system is running in its normal mode.
Add ourselves to the local users, but with a twist. We’re going to change our UID to that of root. Now that when we login, we’ll be using a root account, but not the existing one. Good idea to leave everything untouched. I like to go with audit as a username:
Time to audit
Reboot and login with the username you picked and password. Now that we’re in, we can have a look around. Just as something simple to leave you with, running netstat –tulpn reveals that there is a telnet daemon running on port 28 (Telnet usual runs on port 23). Why have telent open? Nothing about it in the normal GUI. Another reason why we need to be weary of these devices. Could be innocent, a mistake or not.
Conclusion
This is just one step in an audit process. Finding the open telnet would have been possible with an nmap scan of course and that’s where I start from. But then we wouldn’t have any login details. I’ll cover nmap scanning as a method of gaining access in a future post where we do have login details. There’s also using tcpdump to log everything that the camera tries to send on the network, another future post.
Hopefully this has sparked that spark in you to be interested in opening up IoT type devices and checking them yourself.