“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

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:


# 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.



  • great info. I already had the back of mine off when i found your page. to clarify. can this hack be accomplished with the sd card strictly? or do I need the UART port in order to run the script? I have 4 of these, im wondering if i will need to sodder pins to all of them or just one and load it onto the others.

    ksweedDecember 27, 2018
    • You only need an SD-card, nothing else.
      All the research required to get things running has been done for you, pretty much.
      I’d wait a little bit longer though, as I am working on an updated hack that allows a few more things like live-webstreaming via HTTP, SSH access, etc.

      Black-SeraphFebruary 1, 2019
  • it is possible to enable a sort of webserver? it is present?

    How can i look at this cam realtime?

    BHDFebruary 8, 2019
    • The latest WIP version of the hack (which as of now hasn’t been uploaded yet) already has a webserver implemented.
      Realtime streaming on this thing is a little bit difficult though given the hardware is a proprietary Sonix interface with very little RAM to boot.
      The best way I’ve found is to run a vlc-based RTSP streamer… but the performance was below anything you’d call “reasonable”.

      In my own version of the hack I ended up falling back to recording video in 1 minute chunks… and then stitching the chunks together in a semi-realtime cgi-bin based web interface.
      It builds the illusion of realtime recording… and is 1 minute late, but it works.

      Black-SeraphMarch 15, 2019
  • Great article btw. Would kindly share what you soldered to the UART? I used your files and rebooted my miSafe camera and I do here the Doctor’s sound file but it appears that it is not picking up an IP address. I have scanned my network and all IPs are accounted for.

    When the miSafe camera is booted cold (and the SD card installed) I also hear that Chinese voice telling me it was successful.

    So I was thinking if I could telnet via the serial port I could fish around.

    Thanks for your time.


    BuddyFebruary 11, 2019
    • It’s pretty much in plain sight when you crack open the case.
      You need to solder 3 pins to the left-most 3 punch-holes on the miSafes PCB, which correspond to GRN, TX0 & RXI.

      The last pin carries 3.3v and mustn’t be soldered to as most USB FTDI interfaces output their own 3.3v on the rail when connected via USB.
      Soldering and linking the last fourth pin to a USB FTDI interface would cause irreversible damage to both your miSafes camera and your USB FTDI.
      As such, just leave the last pin alone.

      You should then be able to just pop in your USB FTDI interface, which should have the left-most 3 pins allocated to GRN, RXI & TX0… which will allow you to talk to the little thing.

      Black-SeraphMarch 15, 2019
  • i tested your project on mine miSafes Camera and it worked and it recorded but when i put the sd card back in the Camera it wont record anymore can you help me

    kill modzFebruary 26, 2019
    • The patch which has been uploaded to this page is somewhat outdated at this point and I haven’t had the time to package, upload and link the latest version of the hack yet.
      Sadly, given that my own miSafes camera bit the bucket as part of a soldering project gone bad, I no longer have access to a unit to actually keep developing this project further.

      I do plan on updating the latest state of the package one more time though, just to ensure the latest state of the hack is available for others to pick up.

      Black-SeraphMarch 15, 2019
  • I have two of these cameras: one worked with the MiCam app (until October 2018 when the server went dead) and the second one via the Misafecam app (until three days ago, unfortunately – server is unavailable) (:
    So I was quite thrilled to find your blog! Thank you for providing the files for the hack! Thanks to you I was able to telnet into the camera (and learning how to do that as I go) and copied all the files from /bin /sys /etc….. onto the SD card to study them… although I ain’t really a programmer. I would really love to get the latest WIP version of the hack with the web server and all. Hopefully you’ll get the time soon to upload. Great job!

    xstefMarch 29, 2019

Leave a Reply to Black-Seraph Cancel reply