Skip to content

Android (LineageOS 15.1 and 16) Auto Boot on Charging

For a project I am currently working on I needed an old mobile phone with Android (a Motorola Moto G 2014) to automatically boot up as soon as it gets charged. In this project, the mobile phone is always connected to a charger and as soon as this charger gets power, the phone should start its boot process. Normally, any mobile phone goes into a special "charging screen". I searched a lot in the depth of the Internet but did not find much about this topic. Therefore, I write this article so others do not have the same problem (and I have notes available if I want to do it again ;-) ). Since this is a change to the operating system, I needed something like LineageOS to have access to it. So, this is a description how to set up your LineageOS 16 to boot up as soon as it gets power via the charger. However, I also tested it on LineageOS 15.1 on a Nexus 5X and it works.

Installing LineageOS 16

The first step is to install LineageOS 16 onto your mobile phone. I will not describe how this is done, because the LineageOS website has really good tutorials for this (here for the Moto G 2014). Since my phone is no longer supported, there are no official images for it. But I did not want to build LineageOS for myself. So I searched for unofficial builds and found one with the name I used this to flash my mobile phone. Additionally, please install the LineageOS SU Addon to get root permissions on the phone. When everything is working, we can start our changes to the operating system.

Auto Boot on Charging

As I said, I tested a lot of different methods I found on the Internet. The one that worked for me I found in a forum thread. In a short description, we have to change the init.rc in the boot image. However, for this we have to reflash the mobile phone. I tried to change the file directly via adb (getting write permissions to the file and editing it directly). However, after each reboot it changes back to the original file. So, we have to change it in the boot image itself.

Normally, I work on Linux. However, since there is a Windows tool that does all the packing and repacking (and I actually do not care about the Android image internals), I used Windows for this part. The steps we have to do are the following:

  1. Download Android Image Kitchen. I used version 3.5.

  2. Unzip our LineageOS file (the and copy the boot.img into the Android Image Kitchen directory (next to unpackimg.bat and repackimg.bat).

  3. Open a command line in Windows into this directory and execute:

  4. unpackimg.bat boot.img

  5. Go into the directory ramdisk and edit the file init.rc. I would suggest to use Notepad++ for this, since the normal Windows editor could fuck up the charset (e.g., by using \r\n instead of \n).

  6. Find the section that starts with on charger and change it to the following:

  7. #[...]
    on charger
        class_start charger
        class_stop charger
        trigger late-init

  8. Repack the image by open a command line into the Android Image Kitchen directory and execute repackimg.bat. You should now have a file that is called image-new.img. This is our new boot image.

  9. Copy the image-new.img to your phone (I used a SD card for this).

  10. Start TWRP on your phone (you used it to flash your LineageOS onto your phone, so do the same steps to go into the recovery mode which uses TWRP).

  11. In TWRP, go to install, switch to install image and then select the image-new.img file you copied to your phone. Select the boot partition and swipe to install it. In short, do install -> install image -> select image-new.img -> select boot partition -> swipe to install.

  12. Reboot.

  13. Done.

After this, the mobile phone should boot up as soon as your charger delivers power to it. If you want to check if your changes are now on the phone, you can use adb for it. Do the following if you want to check:

  1. Turn on the developer options on your mobile phone.

  2. Allow USB debugging.

  3. Allow adb to have root access.

  4. Use the command adb root on your computer to restart adb with root access.

  5. Use the command adb shell to get a shell on the phone.

  6. Output the file init.rc file via cat init.rc and see if your changes are there.

So, I hope this is useful for others that have the same problem as I did.

AlertR User Management Update in Version 0.503-5

AlertR User Management Update

In version 0.503-5 of the AlertR server I updated the user management. The previous user management was always a thorn in my side. Every user has to be added manually to the users.csv and the server has to be restarted. Additionally, the passwords of the users were stored in cleartext in the file (since I am working in security, this was always nagging at me). Hence, updating the user management was definitely necessary.

User Management Script

So what is actually new? First of all, the users are no more added by manually updating the users.csv file. The server now has a new script called which handles all the user management. It can add, delete, modify any user and list all existing ones. To make it more simple, it prompts questions for data it needs and downloads information from the central repository. For example, when adding a new user it will ask for the username and password, downloads the list of existing clients from the central repository and asks you what kind of client you want to add. Adding a user looks then like the following:

alertr@towel:/home/alertr/server# python -a

Please make sure that the AlertR Server is not running while adding a user.
Otherwise it can lead to an inconsistent state and a corrupted database.
Are you sure to continue?
(y/n): y

Please enter username:

Please enter password:

Please verify password:

No.  | Option
---------------------------------------- Type: alert -----------------------------------------------
1.   | Use instance 'alertClientDbus'.
2.   | Use instance 'alertClientExecuter'.
3.   | Use instance 'alertClientMail'.
4.   | Use instance 'alertClientPushNotification'.
5.   | Use instance 'alertClientRaspberryPi'.
6.   | Use instance 'alertClientTemplate'.
7.   | Use instance 'alertClientXBMC'.
---------------------------------------- Type: manager ---------------------------------------------
8.   | Use instance 'managerClientConsole'.
9.   | Use instance 'managerClientDatabase'.
10.  | Use instance 'managerClientKeypad'.
---------------------------------------- Type: sensor ----------------------------------------------
11.  | Use instance 'sensorClientDevelopment'.
12.  | Use instance 'sensorClientExecuter'.
13.  | Use instance 'sensorClientFIFO'.
14.  | Use instance 'sensorClientICalendar'.
15.  | Use instance 'sensorClientLightning'.
16.  | Use instance 'sensorClientPing'.
17.  | Use instance 'sensorClientRaspberryPi'.
18.  | Use instance 'sensorClientWeatherService'.
---------------------------------------- Type: other -----------------------------------------------
19. Enter instance and node type manually.

Please choose an option: 17

However, it also allows you to add the same user just with a single command execution:

alertr@towel:/home/alertr/server# python -a -u client_raspi_kitchen -p totally_secret_pw -t sensor -i sensorClientRaspberryPi

Please make sure that the AlertR Server is not running while adding a user.
Otherwise it can lead to an inconsistent state and a corrupted database.
Are you sure to continue?
(y/n): y

If the last prompt about asking if the AlertR server is stopped at the moment is also annoying, we can also suppress this:

alertr@towel:/home/alertr/server# python -a -u client_raspi_kitchen -p totally_secret_pw -t sensor -i sensorClientRaspberryPi -y

If you do not have an Internet connection or you do not want to connect to the central repository you can use the -o argument to disable it.

Password Storage

The password is no longer stored in cleartext but using bcrypt. This ensures that an adversary that is able to get the users.csv file cannot read them. When updating the AlertR server from a previous version, the old users.csv file will automatically be converted into the new version. So nothing to change here. However, the AlertR server needs a new pip package called bcrypt to work correctly.

Adding and Deleting Users

An additional new thing is that the AlertR server does not have to be restarted when adding or deleting a new user. The server will check every 60 seconds if the users.csv has changed and reload it if it has. However, this does not work correctly when modifying a user. Modifying a user without stopping the server will definitely corrupt your database. This happens because of the way the users are managed internally. And since this small edge case is just too much effort to fix (regarding cost-benefit assessment), I added the warning prompt when using the

A thoughtful reader might now ask: but you also show the warning prompt when adding or deleting a user. This is correct. Since deleting a user and instantly adding the same user with other features is the same as modifying it (because the AlertR server needs around 60 seconds before reloading the users.csv file), I also added the warning prompt to the adding and deleting options.

Behind the Scenes: CTF Watchdog Infrastructure

After the 2017 CTF was successful, there is some time to recap the feedback. One thing that we heard the last years was that the availability of our challenges is really great. To quote one of the feedbacks we got this year: "The CTF runs so flawlessly that I didn't realized I needed to ask for support.". I think there are two reasons for this (and everyone who ever hosted a CTF knows it is not the well written code of the challenges ;-) ). The first and main reason is the awesome team we have. Everyone is really dedicated to the CTF and wants to make it a great experience for each participating team. The other reason, I like to think, is that we constantly monitor our challenges. And this is what this article is about.

Every challenge author always writes a proof-of-concept exploit for his challenge during the creation process in order to check if the challenge works. And our idea was that since the author writes the proof-of-concept exploit anyway, why not use it for the monitoring? So we created the guideline that each proof-of-concept exploit should be using the first argument for the address of the service, the second argument for the port, and an exit code unequal to 0 if an error occurred (there might be exceptions for this but this guideline is usually sufficient). That is all a challenge author has to take care of in order to provide a monitoring for his service.

But a bunch of scripts that can exploit the services of the CTF are not sufficient alone. We need a central entity that will notify us if anything goes wrong. And for this we use the alertR monitoring system. Mainly we use the following components of the monitoring system:

* alertR Server
* alertR Sensor Client Executer
* alertR Alert Client Push Notification
* alertR Manager Client Database

In the following sections I will describe what these components do and how they help us keeping the services up and running.

alertR Server

This is the main component of the monitoring system. Each client will connect to this server and send all information about the monitored services to it. In our case, the server has exactly one group (called alertLevel) to which each sensor (exploit that tests the services) and each actuator (called alert) belongs to. This alertLevel is set to trigger always an alarm even if the monitoring system is deactivated. How the alertR infrastructure looks in detail, can be read on the corresponding Github Wiki Page.

alertR Sensor Client Executer

This is the part that executes the exploits. It will check the exit code of each executed exploit and will raise an alarm if it is unequal to 0 (or the exploit times out). The interval in which the exploit is executed and a timeout value for the exploit is given by the author of the challenge.

alertR Alert Client Push Notification

alertR is able to send you push notifications to your Android devices. For this, you have to install the official alertR App on your Android and set up an alertR account (one account per monitoring system, not per Android device). Now every time a challenge has a problem, you get a push notification on your mobile device.

alertR Manager Client Database

This component allows you to provide the monitoring system data in a MySQL database for any component to process it. With the help of this, we provide two services:


We wrote an IRC bot which can process the alertR system data. Most of our team is online in our internal IRC channel. Therefore, it was only a logical step to implement an IRC bot which will keep us updated on the current state of the CTF challenges. If a challenge encounters any problems, the IRC bot will post it into the channel.

Status Website

The website that shows the state of our challenges is used by us internally as well as by the CTF users. This website just shows the state of each challenge plain and simple. With this, CTF users can see if a challenge is actually working before they are asking for any support if they encounter problems.

Monitoring Infrastructure

Well, the CTF is a hacking competition. Therefore, we try to make the infrastructure as secure as possible. This also applies to the monitoring system infrastructure. The alertR monitoring system is network based. This means that each component can be run on a different host. Since most watchdog scripts have the flag hardcoded, we have to make sure they can not be read by anyone. Because of this, we set up the executing mechanism on a separate host that only runs this part. As a result, we make sure that the attack vector for this crucial part is as narrow as possible. The status website as well as the IRC bot are also running on a different host than the alertR server. This is just circumstantial, but it certainly does not weaken the security of the system.

Final Words

I hope you enjoyed this little article about one internal aspect of the CTF. Perhaps it is helpful to some people out there that are also hosting CTFs.

Building a MagicMirror using VESA mount

There are a lot of MagicMirror building tutorials out there. So why another one? The tutorials I saw always dismantled the display in order to build the case around it. I did not want to do it this way. Actually, I wanted to be able to easily exchange the display if it breaks down. So I decided to use the VESA wall mount capability of the display in order to fixate it into the mirror.

Another thing I saw a lot in other MagicMirror tutorials was that the front part of the frame had screws in it or was not sawed in a straight line. This I found rather ugly because it is the part you see the most when you use your MagicMirror in your living space. Therefore, I decided to use a frame for pictures that I can buy. At this shop (German link) I bought the frame "Monaco" in black with a size of 60cm x 40cm. Now the only missing part was the mirror glass. This I bought at this shop (German link), again with a size of 60cm x 40cm. When I got both, the mirror glass fitted perfectly into the frame. Now it was time to build the rest of it.

The first thing I did, I crafted a casing that I can put under the bought frame. I used a height of 13cm, but afterwards I realized it could be smaller (perhaps 8cm).

Next thing was that I painted the casing black in order to make it fitting for the bought frame.

Next I used wood glue to glue both parts together.

Because the mirror glass is really heavy, I did not think the glue alone would hold. Therefore I also screwed everything together from the inside.

This was the first intermediate result.

Next I used the VESA 100x100 mounting feature of my display to connect it to the mirror casing. I used an old 24" LCD display I had at home. If you use a new LED display, it would be thinner and much lighter. Personally, I would recommend to use a new LED display.

The first test of the display.

I used normal angle brackets to build a mount for the wall. These I use to hook the mirror up to screws I put into the wall.

Next I build a small mount for my Raspberry Pi 3 casing.

A small test if the new Raspberry Pi works with the vertical video output option.

Next I just added all the cables for the power supply and hooked it up to the wall.

And here is a final picture of it running the MagicMirror framework.

The mirror shows the sate of the alertR monitoring and alarm system. I wrote two MagicMirror modules, one that displays the states of the sensors and one that displays all sensor alerts. Also in order to reduce the power consumption, the MagicMirror tests if the alarm system is activated (and therefore everyone is sleeping or not at home) and turns off the display if it is. So if you are not only interested in the MagicMirror itself but also in alertR, feel free to give it a try :-)

Security Issues in PrivateEyePi Home Alarm System: Why I would not use it!


PrivateEyePi is a home automation and monitoring project for the RaspberryPi. I saw some articles about PrivateEyePi and saw that they even have their own store on their website. Since I am the author of alertR (another open-source alarm system), I thought I take a closer look at what they are doing. Before I started with alertR, I looked briefly at some open-source projects to see if some project is doing what I wanted to do. In most cases it was sufficient to only look at the website of the project. PrivateEyePi was quickly dismissed by me because they only work with one host. Hence, I never took a closer look into it. And I know that it looks a little bit pitiful that I am writing an article about "how insecure this project is". But after taking a closer look, I have to say that from a security perspective I strongly discourage anybody to use it. And the following will explain why ...


Let us start at the beginning. And in the beginning was ... the installation. As far as I can tell I analyzed version v12 of the PrivateEyePi software. For all versions, the project explains in a small tutorial how to install PrivateEyePi. They describe that you should download the file and execute it via sudo sh The file looks like the following:

sudo rm -f
sudo mkdir -p pep_backup
sudo mv pep_backup 2>/dev/null
sudo mv pep_backup 2>/dev/null
sudo mv pep_backup 2>/dev/null
sudo mv pep_backup 2>/dev/null
sudo mv pep_backup 2>/dev/null
sudo mv pep_backup 2>/dev/null
sudo mv pep_backup 2>/dev/null
sudo mv pep_backup 2>/dev/null

sudo mv pep_backup 2>/dev/null
sudo mv pep_backup 2>/dev/null
sudo mv pep_backup 2>/dev/null
sudo mv pep_backup 2>/dev/null
sudo mv pep_backup 2>/dev/null

sudo wget
unzip -o
sudo chmod 777
sudo chmod 777
sudo chmod 777
sudo chmod 777
sudo chmod 777
sudo chmod 777
sudo chmod 777 pep_backup
sudo chmod 777

sudo chmod 777
sudo chmod 777
sudo chmod 777
sudo chmod 777
sudo chmod 777

sudo apt-get install python-serial

Perhaps some of you saw my little Twitter rant (actually, I do not think so but everyone can hope, right? ;-) ). First of all the file is already executed with sudo. Therefore all the additional sudos are unnecessarily. Second, you should not execute wget or unzip with root permissions. You never know what nasty bug could be triggered. But what you certainly do not do is change the file permissions for a file owned by root (or in this matter for any other user) to 777 (world-read-exec-write)! To make this bug complete, in the next steps of the tutorial the alarm system is started via the command sudo python, which means it is also run with root permissions.

Perhaps some of you ask now "Why shouldn't I have a file world-read-exec-writable? And why not as root?". Well, some other user on the same system can write into the file (it is writable by everyone, so it can be any user). And when the application is now executed with root permissions, this user can execute code with root privileges.

Well, this was the installation process. Let us switch to the next step in the installation tutorial, the registration at the central server of PrivateEyePi.

Central Server Webinterface

You have to register an account on the central server of PrivateEyePi in order to use your alarm system at home. Wait, what?! Yes, PrivateEyePi uses a central server which is owned by them to give user access to their home alarm system. Sounds suspicious you think? Well, we will come back to this later.

We go not into depth here, since I am not the owner of this server and probably have no permission to test the webinterface. But again, perhaps you saw my little rant on Twitter again :-) .

You can see that when I want to change my user account information, I can see my used password in the source code of the page. What does this mean? First of all this means that the password is stored in plaintext. This means anyone of the PrivateEyePi guys can read your password (or any attacker that compromised the server). If you have used your default password and your default eMail address that you use everywhere: Sucks to be you :-P ! Second, even if you have a magical reason to store the password in plaintext (there is none!), you certainly do not send it back to a web page. For example, if you are logged in to the webinterface and someone else uses your browser, this someone can see your password.

This is all I can say about the webinterface. But seeing the quality of the code so far I am pretty sure that you will find other security issues there like SQLi (which would probably allow you to get user informations like eMail addresses and passwords ... in plaintext).

What is next in the installation tutorial? The configuration of the alarm system.

Configuring the Alarm System

Now we come back to the central server part. The alarm system is mainly configured via the webinterface on the central PrivateEyePi server. Stuff like eMail addresses the alarms should be sent to, GPIOs of the sensors etc. are configured via the central server. The stuff that is configured locally can be found in the This is rather uninteresting stuff like user credentials for the central PrivateEyePi server, or if the temperature is shown in Fahrenheit, SMTP server settings, or the GPIO for a connected siren (I do not know why this is actually configured locally when the sensors are configured on the central server).

The architecture of the system can be seen in the following figure:

As can be seen, all sensors and other hardware is connected to the RaspberryPi. The home alarm system collects the data and sends it to the central server. Additionally, the home alarm system polls the server for commands it should execute. The webinterface of the central server can be used by the user to see the information the sensors collect and give commands like turning off the alarm system (hopefully, some of you already see how problematic this design is ... if not, I will come to it in a few seconds).

I think this design was chosen to circumvent the need to configure port forwarding on the local router. This way, a user is able to reach his home alarm system from his mobile phone without changing any Internet settings at home or setting up a service that is reachable from the Internet. But this design is quite problematic and also naive. Why naive? Well, imagine you have a home alarm system. Would you tell a stranger that nobody is at your home? And while we are on it, would you also give this stranger the key to disarm your home alarm system? No? Well, me neither. But if you use PrivateEyePi you do.

Let me explain why before I show concrete attack scenarios. PrivateEyePi sends the collected sensor data to the central server. If you have motion detection sensors and sensors at your windows and doors, their states are send to the central server and stored there. Not only you, but also the PrivateEyePi guys and an attacker that compromised their server are able to see this information. Therefore, they know when no one is at your home. Since the central server is able to send commands to your alarm system, the PrivateEyePi guys and an attacker is also able to do it. Hence, these strangers are able to disarm your alarm system.

Now let us take a look at concrete attack scenarios.

We are secure. We used encryption!

First we take a look at the connection between the home alarm system and the central server. These connections can be found in the and file. Both are done in the same way. A https URL is visited with GET parameters that either update the data on the central server or request data. This URL also contains the username and password of your user account. Well, since they are using an encrypted connection to their central server, everything is fine and we can go to the next section? Not exactly. Yes, they are setting up an encrypted connection. But they are using urllib2 for it. And urllib2 does not validate the certificate offered by the server by default. This option has to be manually set. And yes, there is a proposal to activate this check by default. But I do not know if it is already implemented. I checked it with Python 2.7.6 and it does not verify the certificate. Hence, when an attacker is able to hijack the connection he can just offer any certificate and the home alarm system will accept it. Therefore, an attacker does not necessarily have to compromise the central server, he just needs to hijack the connection (although I guess the first option might be easier).

I spy with my little eye ... uff, why am I suddenly blind?

The home alarm system gets its sensor configuration from the central server. Therefore, the central server can just send an empty or false configuration to the home alarm system. And suddenly ... the home alarm system is blind. This way an attacker is able to disable the alarm system completely or just remove specific sensors (to be a little bit sneakier).

Why does this work? Well, in the file the main() function enters an infinity loop which polls the GPIO states of the sensors. And this infinity loop polls also the current configuration from the central server and applies it locally any 600 seconds.

Look mum no hands!

One interesting command is the /PHOTO command. This attack only works if a webcam is connected to the home alarm system and the SMTP server is configured to send eMails. Well, what does it do? The command tells the home alarm system to send an eMail to the configured eMail addresses with a picture taken by the webcam. The fun part is, the eMail addresses this message is sent to are also configured via the central server. Before the home alarm system sends this message, it asks the central server for the eMail addresses. Therefore, the attacker can just send his eMail address to the home alarm system and gets a picture taken by the webcam. No one else is getting this message. So it is kind of sneaky ;-) .

If you want to see it for yourself, you can find it in the file. ProcessActions() is called when a message is received from the central server. This calls SendEmailAlertFromRule() with all the necessary arguments to take a picture. A thread is started that executes SendEmailAlertThread(). This function gets the eMail addresses from the central server with GetDataFromHost() and the used arguments. Then it builds the message and sends it to the received eMail addresses.

Inoutput. What?!

This is a really cool attack, because it can actually damage the hardware. The command /RELAYON is responsible for it. With this command, a GPIO pin number and the option HIGH or LOW is also received. What does it do? Well, it sets the given GPIO pin number as output pin and sets it to either HIGH or LOW. In the case of RaspberryPi, HIGH means it sets up 3.3V. This can be used for two attacks. First, we can trigger a sensor that is configured on our home alarm system. This can be done by setting the GPIO pin to a HIGH state that is also used as an input GPIO pin of a sensor. Second, if the sensor (or other hardware) that is connected to a GPIO pin that is set to a HIGH output is not built well, it can be damaged (I asked an electronics guy because I was not sure, and he told me it can happen). Not so often that we see a software attack that can actually damage hardware :-) .

Again, this can be found in the file. ProcessActions() is called when a message is received from the central server. This calls SwitchRelay() which sets the GPIO pin to an output port and to HIGH/LOW.

Miscellaneous Stuff

I am not a professional programmer. Therefore, I do not like to say stuff like "Uh, look at this shady code!". But there are some constructs in the PrivateEyePi code I wanted to show. Let us just look at the function ProcessActions():

def ProcessActions(ActionList):
    for x in ActionList:
        if x[0]=="/EMAIL":
                SendEmailAlertFromRule(x[1], x[2],0)
        if x[0]=="/SEMAIL":
        if x[0]=="/CHIME":
        if x[0]=="/rn588":
        if x[0]=="/FALSE":
        if x[0]=="/SIREN":
        if x[0]=="/PHOTO":
                SendEmailAlertFromRule(x[1], x[2],1)
        if x[0]=="/RELAYON":
        if x[0]=="/RELAYOFF":
        if x[0]=="/WRELAYON":
        if x[0]=="/WRELAYOFF":

The argument ActionList has the type list. Well, what does this function do? It iterates over the ActionList elements and checks if they contain a specific known command (more specifically, if the first element of this list contains a specific command). In the end, the function returns FalseInd.

Let us take a closer look at FalseInd. Do you see it? In the beginning this variable is set to True. If the command /FALSE is received, it is set to False. When the command /SIREN is received, it is set to 3. Dafuq?! I know that Python allows you to do this. But this does not mean that you should do it (like goto in C). If you use a variable as a boolean, stick to it and do not change it to an integer.

Also, each list element x should be removed from the ActionList (at least, I think this is what it should do). Hence, the line x.remove. Well, x is a list and has therefore the function remove(). But first of all, it is not invoked by the line x.remove. This just returns you the address of the function. And second, remove() takes an argument. Therefore, this line does actually nothing and does not make any sense.

Another thing you often see in the code is something like the following:

def PollGPIO():
# Routine to continuously poll the IO ports on the Raspberry Pi
        global ciruit
        global GPIOList
        global numgpio
        global GPIO
        global AlarmActioned

def NotifyHostEvent(z, status):
        global GPIOList
        global Locations

def PollRoutine():
        global start_time
        global elapsed_time

I do not know why they are using global variables for everything. Hell, even the whole configuration is done with global variables. And the file is called And because of the import globals in the beginning of each file, this has strange effects on the syntax highlighting of an editor. Because globals() is a built-in function in Python, the editor highlights any use of the configuration variables like globals.LCDAlarmActivity. Definitely another thing you do not do when programming in Python.


This was a non-exhaustive list of security issues I found in PrivateEyePi. Note that I did non take a detailed dive into any file. Only the parts that work directly with data from the central server I looked into (and I did not really track the complete data-flow ... there could be a lot more to find). Well, as you have seen these are the reasons I would not recommend using PrivateEyePi. In my opinion, it is totally broken by design. The complete alarm system can be controlled by the PrivateEyePi guys and if the server is compromised, an attacker can so too. Additionally, the design allows an attacker to actually damage the connected hardware.

Update 06-01-18

The PrivateEyePi authors contacted me and said that they fixed a lot of issues in their current version. The following is a summary of changes they send me. However, I like to stress that this is only a list of things the authors send to me. I did not check the code if these changes were actually made:

- User password encryption in database and password are no longer passed from server to client.
- Devices and sensors connecting to PrivateEyePi server now use a token to authenticate, not email and password. The token cannot be use used to login to the website. The token is only displayed to the user once and never transmitted from the server to the web page after the initial creation.
- Alarm activation/deactivation can only be done through the website.
- Remote control for GPIO, RF devices and web cam photo function configured off by default through a new setting AllowExternalControl.
- Installation script does not use chmod 777 anymore and removed sudo where it is not necessary.
- Python 2.7.9. now validates certificates by default.
- Cleaned up use of FalseInd Boolean variable to store status beyond True/False.
- Cleaned up remove function from ActionList.