“miSafes” Offline Camera Hack

I’ve never been a big IoT (internet of things) fan, but there was a time when I actively used one of these “miSafes” pet / baby camera doodads to keep an eye on my pets while I was overseas.

It was convenient, cheap(er than other offerings), and did the job.
That was in 2016.

The other day my wife dug the old camera out again, hoping to use it to monitor a newly set up playpen for our pet rabbits, only to find out that “miSafes” (the company), shut down their pet / baby camera monitor webserver, essentially rendering all of their camera offerings fully defunct given the fact they refuse to operate without an active server connection.

Most of you will probably know by now that I am a tinkerer of sorts and it really didn’t sit well with me knowing that my wife and I essentially blew 40€ on a camera we could no longer use for its intended purpose.

Long story short, I got my trusty soldering iron out, soldered a few pins to the UART serial port of the device, and started investigating.

“miSafes” camera with soldered UART pins hooked up to a USB serial converter

It didn’t expect a whole lot in terms of security coming from a cheap chinese camera and wearable company, but what I found then really underwhelmed me.

The serial port quickly prompted me for a username and password to log into the operating system with, for laughs I typed in “root” and “1234” as the password, only to find I had hit the nail on the head right there and then.

I was in… as “root”… with nothing but “1234” as its password.
Nice job “miSafes”, you are doing your name proud.

“1234” should be strong enough of a password to keep people out.

Come to think of it, why not just leave the whole UART port on the PCB too… we can save 1¥ that way in PCB design costs!

– Random Chinese Factory Worker

The “SD-Card” backdoor

I was freshly christened as “root” and started looking into how the OS worked, what tools it came with out-of-box and what other potential security flaws might be hidden within.

The first thing I wanted to look into was getting rid of the horrible “SD card mounted” voice message the camera played (in broken chinese-english) every time you plugged a MicroSD card into the device.

It didn’t take me long to find as it was part of the “/etc/hotplug/sdcard” mount script. But what I found in there was even better than what I had bargained for in the first place.

Well, that’s nice. They left a full blown MicroSD card script backdoor in there for me.

I quote a simplified version of the MicroSD card mounting code:

mkdir -p /media/$MDEV
mount -t vfat -o rw /dev/$MDEV /media/$MDEV
if [ -f /media/$MDEV/snx_autorun.sh ]; then
/media/$MDEV/snx_autorun.sh
fi

For those that aren’t fluent in bash, what this piece of code does is mount the MicroSD card at /media/$MDEV ($MDEV being the MicroSD’s first partition device identifier, usually “mmcblk0p1”) and, if a file named “snx_autorun.sh” exists, execute it as “root” user, essentially giving this script and its content, no matter what it is, full administrative rights over the camera and its whole Linux operating system.

At this point I knew there was no reason to continue hacking this device any further, as all I needed to do was write up a small little bash script, name it “snx_autorun.sh” and put it onto the MicroSD card and I would be golden.

I spent another hour trying to familiarize myself with the environment and went on to program my little “snx_autorun.sh” script.

How I made the camera work again

There were a handful of things to consider when writing the final “snx_autorun.sh” hack script for the camera.

First of all, the camera WLAN configuration used to be something that one did with the companion app “miSafes” provided for iOS and Android, which, again, relied on their webserver, which no longer exists.

As such, I needed a way to easily connect the camera to a WLAN network of my choice, this had to be a part of my “snx_autorun.sh” script to ensure the camera would remain accessible on the local network.

Furthermore, I needed a way to administrate / log into the camera that didn’t involve me being soldered to the PCB, luckily enough the camera’s operating system came with a telnetd service which only needed enabling.

This would replace my wired serial port on the long run, making further modifications and tweaks so much easier.

And finally… I needed to rip out the now defunct china spyware / botnet code they previously used to allow you to access your camera, and find an alternate route for recording video offline, fully independent from the infrastructure that “miSafes” used to provide.

The final script I came up with was this:

!/bin/sh

# Kill china spyware (the server's are offline anyway, let's not waste RAM)
killall apsta
killall updatefw
killall upload2yum
killall wpa_supplicant
killall udhcpc

# Connect to a 2.4GHz WPA network of choice
wpa_supplicant -Dwext -iwlan0 -c /media/mmcblk0p1/wpa_supplicant.conf &

# Wait for the wlan0 interface to pop up
sleep 5

# Acquire an IP address via DHCP
udhcpc -i wlan0

# Activate telnetd (so we can remote-control the camera if needed)
# User: root
# Password: 1234
# Port: 23
telnetd &

# Prepare the offline recorder RAMFS
mkdir -p /tmp/record
mount -t tmpfs tmpfs /tmp/record -o size=4m
dd if=/dev/zero of=/tmp/record/record_fs bs=1024 count=4608
losetup /dev/loop0 /tmp/record/record_fs
mkfs.ext2 -q /dev/loop0
mount -t ext2 /dev/loop0 /tmp/record

# Start the recorder (in motion detection mode)
record_motion &

# Start the recorder (in continuous recording mode)
# record &

# We are done (and will notify the owner that we are)
gpio_ms1 -n 7 -m 1 -v 1
pcm_play /media/mmcblk0p1/clever.pcm
gpio_ms1 -n 7 -m 1 -v 0

The script is pretty self-explanatory, but for those that need a more in-depth explanation here it is:

  1. We kill the processes that used to connect the camera to the “miSafes” webserver (which no longer exists, making these processes “dead-weight”).
  2. We then connect the camera to a 2.4GHz WPA WLAN of choice using a custom “wpa_supplicant.conf” file on our MicroSD card (telling it which WLAN to connect to with what password).
  3. We then request the router to give the camera an IP address, so that we can access it on our local network.
  4. We activate the telnetd service, which allows us to administrate the camera remotely over our local network. This change replaces the soldered UART serial port connection I used for my initial analysis.
  5. We create a temporary 4MB RAMFS for the camera to dump recorded material into (before flushing it to the MicroSD card), without this the camera will refuse to record data, just trust me on this, I did my research.
  6. Afterwards, we start the hidden offline recorder “miSafes” left inside the camera operating system (thank you for leaving all this delicious debug-code in there for me), either in motion-based recording mode, or continuous recording mode.
  7. Finally we enable the built-in speaker of the camera, play a snarky Doctor Who quote to tell the user the hack was successful, disable the speaker again (as it has a annoying popping sound coming out of it when idle) and position our camera to record whatever we want.

To stop recording, simply unplug the camera and remove the MicroSD card.
You will find all your recordings inside a folder named “snrecord”.

What to take away from this?

Don’t trust cheap chinese IoT devices, they are cheap for a reason, insecure, and god knows how easy to hack for anyone that knows at least a little bit of what they are doing.

In this case however, this hack was born out of the simple fact that I was too greedy to dish out another 40€ for yet another IoT IP camera just to get a simple job done for which I knew I already had the right equipment.

I hope that this explanation and ready-to-use hack will help all of those that bought this camera and find themselves unable to use it due to the recent “miSafes” webserver shutdown.

Downloads

Leave a Reply