Robot Not a Dev? Pre-order Now
Not a Dev?

Misty Community Forum

Misty II and Security?

Was security not even a concern when developing this robot?

I just found out that you can remotely connect to the Misty Robot II and get an ADB(Android) shell. Then all you have to type is su root; now you can do whatever you want. Really, by default?

I understand that this is a robot for developers, but shouldn’t the defaults be secure and then allow us to do something stupid like set it up the way it is NOW! This is almost worse than raspbian having SSH on by default with default username and password.

Has anyone found documentation on how to secure the android system from wireless networks? So that people cannot just create an ADB session. Also, maybe adding a password to the android system by default would have been a smart idea MistyRobotics.

One last time, documentation, documentation, and a little more documentation would be excellent, regarding security.

You guys designed this amazing robot that can do a bunch of stuff, but you did not even think about security. You did not know about people who may not know anything about android development who just wanted a nice robot to set up some API stuff and have it do amazing things.

Being able to send API commands to a robot without authentication is irresponsible.

Also, is the android app code on GitHub? So many things need to be changed -_-

Hi @bran0847,
Years ago when we were starting the development of Misty II we drew a line on our whiteboard and marked one side as “extremely secure” and the other side as “no security.” We then asked ourselves where we wanted Misty II to fall on that line. The advantage of security is that it allows us to sell to people who require Misty II to be highly secure. On the other side, no security allows developers to have a lot more freedom in how they can use Misty. It means they can get under the hood to potentially implement features that could otherwise take us months to expose in a secure way. We made a conscious decision to be at a ~2-3 where 0 = completely open, 10 = iPhone.

We want developers to be able to be extremely creative and not be inhibited by sandboxes that can limit what they can do. It would have also had meant us giving a lot of foresight into what we allowed people to do and not to and how they did it. Since we’re just at the beginning of learning how robots can be used in our lives we felt that would also be preemptively limiting to developers.

As someone who attends conferences like DEFCON I know the importance of security. Misty II’s lack of security wasn’t an oversight and was planned. As we all work together to figure out how robots are best used in our lives we will start to lock down and sandbox our robots in ways that make sense to both allow the use cases but provide the security we know will be needed. As to why Android wasn’t locked by default with a password like the Windows side is I don’t have a great answer.

That said, I’d love to hear more about your use case, what level of security is important, and why so we can think through the tradeoffs. I think this thread may be important to others so it would be great for you to reply here but if you don’t want to share details of your specific situation you can message me directly also.


As additional context and comparison, one of the most prolific robotics communities and projects, ROS, is insecure by default (Security - ROS Wiki). In summary, ROS1 transmits messages in cleartext and performs no authentication for peers that send robot motion commands or sensor data. In other words, if you are on the right network, you can easily command the robot to crash, or fuzz the master node.

Better security is coming in ROS2, and there have been projects to add security to ROS1, e.g., SROS (ROSCon 2017: SROS: Current Progress and Developments -- Ruffin White (University of California, San Diego) Gianluca Caiazza (Ca' Foscari University, Venice) - ROS robotics news). In hindsight 10 years later, would making ROS1 more secure by default have helped or hindered its current success? People have strong opinions about that, but in practice, security has not been an issue compared to providing realtime guarantees with ROS1.

One more small comparison: LCM ( is also not secure by default: messages are transmitted in cleartext via UDP multicast without authentication. In practice, this makes early development much easier and is not a problem under certain assumptions of the local network.


Wow, thanks for replying so quickly! @arobodude , I understand that you have to draw the line somewhere, but I feel like you went to open. Maybe adding extra security measures would hurt development. I am not the one who purchased Misty; it was our Computer Science department. We use Misty in an IoT class. The professor is hoping students have the chance to develop and create projects with Misty that may have a positive impact on children with autism and older patients as well. How Social Robots Could Help Older Patients Help Themselves

I am currently a graduate student at the University of Minnesota, Duluth. My research is on common security misconceptions. One of the security misconceptions is “this configuration works, so it’s probably secure.” The person who bought this robot assumed it was secured when we got it set up on our University network. They had no idea that the android system was rooted, and by default, it had no passwords for an ADB shell session. That open door allowed me to gain access from outside of my campus.

Two security issues jumped at me while using misty. One would be the command center API that allows anyone to make API requests without some key. Maybe something as simple as a unique key that displays on the face of Misty that a developer would have to add to the requests they send. h t t p s : / / w w w . f r e e c o d e c a m p . o r g / n e w s / b e s t - p r a c t i c e s - f o r - b u i l d i n g - a p i - k e y s - 9 7 c 2 6 e a b f e a 9 / You could even do a general use key for all requests.

My professor said that someone moved our Misty from a remote connection to test it out over the phone. I guess the solution is for this is to keep it off the main network, but our University has a policy of no private hotspots sharing campus internet. We will have to contact the IT department for a custom solution for Misty because it is to open. Maybe set up a VPN connection to the robot.

The second issue which is the most concerning is the android ADB shell. I am not sure how you could set this up when you ship them out. The reason I found this flaw was because someone posted on this site that if you want to connect to an open network, one controlled by white list Mac address. To do this, you have to create an ADB session and use a program to view the android system. I showed my adviser, who is a computer security professor, how easy it was to automate this attack. He told me to take the robot off the network and let the professor of the IoT class know.

After doing some research, it seems like there is no easy way to do this on a rooted android device. I think this is because most of the manufacturers root the device so users cannot ‘’‘su root’’’ into the phone. adb - Password protecting shell access - Android Enthusiasts Stack Exchange

I think this is my biggest concern. My solution is to use openVPN to get access to Misty.

I understand why you guys chose to not add standard default security settings to misty, but you have to disclose this to the consumer. Again I did not purchase this Misty; it was a department purchase at the University of Minnesota Duluth. I am just a graduate student taking a class and had the pleasure of working with Misty. I will say it is a fantastic robot. I have said nothing but praise about the well-documented API commands you the site has. Maybe adding a optional security step in the documentation? That would at least inform the user of the potential dangers of uses this device on a network like at a University.

Not going to lie, it has a high price tag, but even I am considering investing in one just because it is so much fun to develop on! You guys are doing a great job, and I apologize if this post looked like I was taking away from that.

Thank you @slivingston and @arobodude for the quick responses to my post!


I am also in Minnesota. And if you want since we have root obviously we can secure Misty. There maybe some hurdles, but there are always around it.

Microsoft machines are insecure unless protected via network security. Linux is secure normally by default, and can easily be extremely secure and still easy to access/develop. So android is linux based so I am sure we can secure it. We normally use SSL, tunnels, vpn, and other encrypted communication.

Bluetooth is another area of security. And eventually voice control similar to the issues, just like seen on voice control systems. (1. Voice recognition which I can fool most between my son 8yrs old and I. 2. Uploading voice data to a cloud machine [pretty insecure] 3. Auto installs a significant risk… spoofing, buggy package or failure during update)

We can talk more… Eventually it makes sense to be more secure but for now it is convenient for debugging it is good to think about when developing.

@markwdalton The misty II is not a windows machine. And linux is not secured normally by default. The default passwords are usually ubuntu:ubuntu root:toor admin:admin but that is not the issue with this system. IP-tables are usually empty, no extra security measure are put in place unless you set up your custom rules.

The android software running on the dragon boards are android and they have a back door via the ADB shell. Android development bridge. MistyRobotics does not provide a guide to secure this open channel. Mazar BOT malware invades and erases Android devices

If someone ran an infected APK which the ADB shell allows users to do then they could install a bot on the misty robot.

This means anyone outside the network scanning for devices with Android OS and running an automated script may be able to get root access to the robot and install whatever they want on the machine.

What could be done is adding a password for the android system so even if someone got a ADB shell they would have to accept it from the android interface. Downside is they would have to use a third party program like Vysor Downloads to get a screen for the system.

I agree with Ian that for Development it is simpler to have lower security. But it
would be good to explore, which is why I am willing to help you get that setup.
I have done A LOT of securing company products, company servers and
networks, universities and one nations SEC. (FYI to gain understanding of breaking
into machines look at ‘Hack the Box’).

Yes, Misty II is BOTH_ Windows and Android. Windows user and password
on the bottom of Misty II. Yes, and no password was setup on the Android
C02YW25LLVCJ:Hiality-garland mwd$ ssh administrator@
administrator@’s password:

Microsoft Windows [Version 10.0.17763.253]
Copyright © Microsoft Corporation. All rights reserved.

administrator@20193502680 C:\Data\Users\administrator>

Again, I am willing to help you get passwords and security setup if you want it
hardened. My main concerns would be ‘clear text’ data broadcast, passwords in
the log file (like your Wifi SID and password), access is via secure methods with passwords.

Yes default passwords are there and the instructions to CHANGE your password immediately.
That is the same for nearly every device (routers, switches, Dell idrac, etc.etc.) . I have been doing data security since 1998. We can take it off-line about data security of non-Misty if you want to understand the difference in security, but there is a user/admin responsibility during the install
or a product arrival.

RedHat, SuSE, IBM, Cray and other vendors all have Linux security in place. Of course they have
a default password, and as part of the Install process have you change the root password and setup a user with a user password. And all except perhaps Ubuntu have Firewalls, I can check that later today. But yes they are secured, limited port access, only via ssh.

The physical access is not as secured normally… (ie. you can modify the boot loader to boot single user). Or on Apple and Windows the key combo’s:
Mac: Command and S
Windows: Safe Mode


@markwdalton would adding a ssl cert really slow down the developement process? Would an API key really slow down the developement process? Would securing the android system ,LINUX based system, really slow down the development process?

@markwdalton how do you add a password to the root system of an android system? Because I cannot find an answer to that. The android system does not have passwd or any tools that allow you to create a root password out of the box. This process has to be done before installing the android system on the device. Once you have that solution I would recommend MistyRobotics use that.

And FYI I do not need to gain an understanding of breaking into machines. I broke into this one remotely very easily. I would recommend you visit that site if you are going to defend having debugging via WIFI connections default without informing the user of this flaw.

I am talking about the android LINUX based system that is currently running on one of the dragon boards that controls internet access. I have not seen any windows system running on our misty robot II.

Steps for getting root access and the ability to install infected APKs remotely.
Step1: Install ADB on your system. For windows, I use C:\ADB as the install directory.
Step2: run the command C:\ADB\adb.exe connect {Your misty IP}
Step3: run the command su root
Step4: type whoami
Step5: look at the screen.
Install Vysor
Step1: install ADB
Step2: run command C:\adb\adb.exe connect {mistyII IP address} or on linix /usr/bin/adb connet {mistyII IP address}
Step3: run Vysor and connect to the session.
Step4: install some malware

You can install malware, brick the android system, or anything else because the default setting is no password. In the documentation they did not have any information on android development or using android development tools like ADB to secure this.

I am not here to find ways to secure my network so no one can get into a system that is wide open, I am here because I think this is something that WOULD NOT hurt developement by having a password. That is like saying I do not want a strong bank password because that would hurt the login process.

If a password on the Android system running on the dragon boards would stop development, then we need to rethink development.

I do not need any help with securing my network. I will put misty behind a pfsense firewall running openVPN for now. The issue is MistyRobotics did not mention this BIG vulnerability in the documentation and our university assigns public IPs to all the devices connected to the network.

But let say making a password is not possible on the android system for root, then why not turn off ADB shell access via the wifi interface by default? This way you can still connect to the Android Development Bridge shell via the USB interface.

The second part, Yes we have already found that ADB is open access. And it is handy for development, but it could have been secured. Lets work together (I just do this as side project with a few others and I can get busy with my job).

I have not done as much Android work, but linux, bsd, mac, windows, Unix I know the OS well.

So both network access and USB I need to check. I have not gotten to all of my security testing of Misty II. And yes ADB/Android and Windows are known concerns.

Actually anyone running any OS can access the Android OS currently if it is on WiFI and connection, also
Implementing Security  |  Android Open Source Project
Android Debug Bridge (adb)  |  Android Developers

And I agree it should have a password, I was surprised when I received mine also.
But on development (versus production) I do understand.

I will know more by this weekend. I am pretty swamped today with my work.

Also I will check the Ubuntu install docs, I would be surprised if they did not have you secure the machine like every other vendor does (even fedora). For me it is automatic to secure, but fedora has a firewall by default.

The points of access I am concerned with will be, I have to run a audit on all before I can
start securing them:
1. The Windows side: WiFi, USB and bluetooth
- port scan and back doors
2. The Android side: WiFi, USB and bluetooth
- password, port scan and backdoors

My concern is:
1. I do not want to have us locked out (there is ALWAYS a back door).
2. Make sure auto-updates can happen (at least updates with a prompt
which is what I prefer). I trust NO ONE to auto-update (no offense), but
it is dangerous if it is automatic and there is a function.


Yes I do not know the details. It does simplify working with people. Because people
do mess up systems with security if they do not understand it.

I was offering to work with you to secure the Misty and give back the changes I make.
The USB is not very convenient for a moving robot. I believe we can find a way to
secure everything and make it function. (We just need to be careful not to break anything
that relies on it being password-less).
- I am guessing updates, perhaps communication to the Windows side of Misty, etc.

It is a computer and it is linux based… So pretty much ALL THINGS are possible, it just may
require some work and testing.


1 Like


Maybe something like this.

android - How to turn off Wifi via ADB? - Stack Overflow

@arobodude Maybe you guys could have the wifi disabled by defualt. Then add that into the instructions for getting into the ADB. Just run the enable command.
adb shell su -c 'svc wifi enable'

adb shell su -c 'svc wifi disable'

@markwdalton I will test this out tomorrow and let you know if that solves the ADB issue. I am just afraid a 3000 dollar robot will become infected.

Down side with that option above is you will need to connect it to a usb to enable the wifi/ADB shell if a user wanted to remotely access the ADB shell.

@markwdalton I think if you added a root password somehow then automatic updates would not be possible. A user would have to enter in a password if a update or APK is installed.

Hey guys!

I can try to offer up some insight as well because I am one of the engineers that worked on our build of the Android OS. You can turn off TCP access to ADB using the commands below.

adb connect <ip>
adb root
adb remount
adb shell

$ cp /vendor/build.prop /vendor/build.prop.bak
$ exit

adb pull /vendor/build.prop
<manual: remove line with 'service.adb.tcp.port=5555'>
adb push ./build.prop /vendor/build.prop

adb reboot

This will make so that if you need adb access you will have to use a screwdriver to open the head and plug into the micro-usb port. When you do that the audio, video and SLAM systems of the robot will go offline. You can only plug in once per power cycle. Doing this shouldn’t effect any systems on the robot after a reboot but it might make troubleshooting issues more difficult for you, if that is something that is acceptable for your use case (it sounds like it might be).

As far as I know, there isn’t a great way to set a root user password on Android. Granted I’m no expert in Android I just worked on it a bit for our robot. We could have removed the su command and root access but once you do that on an Android build there is no adding it back in and we don’t have the infrastructure in place to over-the-air update the Android OS like larger companies might do.

Personally I would much rather have HTTPS endpoints than plaintext HTTP but there are several hurdles to doing this. The first being that our robot really has two hosts inside the head. The Android host has access to WiFi and uses NAT port forwarding to give the Windows IoT Core host access to WiFi. But the USB port when used with a USB-Ethernet adapter on the backpack is wired to our Windows IoT Core host. So we would really need two certificates to properly encrypt our endpoints. I’m also no security expert so correct me if I’m wrong but I believe that those certificates need to be bound to a specific hostname or address? We could bind them to a private IP address but then we would need to have a mechanism to create and install certificates programmatically on both hosts. We could try to bind them to the hostnames on both the Windows and Android hosts but these hostnames change when someone changes their robot’s name and so we would either need to disable this functionality, have the user generate a new certificate when they change the name or have the hosts do it programmatically. All signs pointed to us needing to setup our own Root CA and having users install our root certificate on their devices so that the browser and other tools don’t complain about certificate verification.

I’m happy to help support the effort in making the robot more secure and to push for it internally so anything you guys need just tag me with @justin. The easiest way to push for an effort to secure the robot would be to add and vote for features here. We talk about the most wanted features from our community every week and it is highly influential on our feature prioritization.


Thanks! That does help. I was guessing there were dependencies and side affects.
And yes, there are potential pains and problems debugging with certificates, there are a
few alternatives. I am confident we can have this work.

My guess is use a firewall and block port 5555 except for trusted hosts (like the Windows side of the robot). And I will see how adb works, but it sounds from reading it uses su to get a root shell.
And the potential solution for that piece is swap out su. I will see if I can grab source for the adbd daemon, and that would be a good way to get a secure connection (encrypted and require a password
unless you enabled via a auth key).

I will try to get a prototype and we can pass it on to Misty and the community.
I don’t want a CA certificate since those are annoying on devices and require updates
and potentially internet access to validate. Everything should be self-contained on a given


Here we go…ADB source code:
adb - platform/system/core - Git at Google

I will look this weekend… But it may be enough to just disable adb via firewall
to external networks, but allow MS Windows locally on Misty. (that would be
a simple change) . And the web or phone app could allow new hosts and even
download a certificate.

adb does have public/private keys already and I will look into what it is broadcasting
on the network later tonight.



Yes, having two computers does make it a bit more tricky with the https. I can talk with some of my security friends, but yes, you would have to have your own CA and have users add that.

As much as I do not like the HTTP issue, the ADB shell was the one that was scaring me the most. Your solution will work because we are not touching the android system. We only use MistyII for small projects.

Thanks for the tip!

The ADB being wide open does seem like an issue @justin?

Our problem is Misty is given a public IP address. I could yell at our IT department to block all traffic outside of the university on that port. Could we somehow have it ask for a password when you use the su command? I have only developed apps, never messed with the actual android system.

Oh I must not have read the original thread thoroughly enough and missed that it was given a public IP address. That is challenging. But if you turn off the adb port then you’re safer but still not out of the woods. There are some additional security bit flags you could set to crank it up a notch. We do forward some ports that you will likely want to block on the public IP address and I can get a list of those for you. SSH and FTP on the Windows host are also turned on. Not sure if you have the capability for it but you could also setup a proxy server that does SSL termination and authentication on the public IP address and forwards the encrypted/authenticated requests to the robot. It would add some latency but if security is higher priority it might work for you. I’ll get a list of all of the open ports for you and what they correspond to so you can decide which ones to block/allow.

Maybe a starting point for HTTPS is to allow users to generate and install self-signed certificates that our server uses? There is a TPM on the Windows host that is used to store certificates to enable secure connection to Microsoft Azure IoT Hub. With coming .NET Native skills it would be possible to connect your robot to a Microsoft Azure IoT Hub to send it remote commands if you’re looking for an out of the box solution.

ADB being wide open is an issue that I’ll bring up in our planning meetings. One of the ways that I found to secure it only allows you to connect via USB if your computer has the certificates that we use to sign the OS build but those weren’t certificates that we were planning on sharing.

1 Like