Research and improvement of IP video server based on Orange Pi PC

About six months ago, I got a miniature video server, the application of which I found in a garage rented for a motorcycle, where he worked safely all this time in conjunction with two Chinese NoName IP cameras, at least supporting ONVIF, and a 3G modem, which allowed me to remotely Watch the video from the cameras with motion detection alerts, which fortunately coincided so far only with my arrival in the garage. I didn’t let this microserver work further on myself, since, when I had just got it in my hands, I took it out of curiosity and unexpectedly discovered that it was built on the Orange Pi PC single board, which, shortly before that, due to its low price, was widely reported on the Internet, including on Geektimes, therefore I approximately represented its opportunities.

Actually, after six months of use, in addition to the basic functions of the video server, I wanted to use the GPIO comb on its board to connect a smoke sensor, a door opening sensor and a relay to turn on the siren. The most interesting and, in my opinion, difficult stage of this hobby project, I decided to share with the community, hoping to get advice on further development. Attention: the actions described further, most likely, deprived me of guarantees for the device, I produced them at my own risk and risk and cite only as food for the mind, but not a guide to action.
')

Firmware study

First of all, in the hope that the video server uses a full distribution kit, I tried to connect the monitor and keyboard to the board, but there was no HDMI output signal, it seems the port is simply not involved in the firmware, which, however, the developers say, stating that this device is a class MicroNVR (Network Video Recorder), does not imply any user interaction with the server, except for remote access. The second goal is ssh, the port of which is open on the device, but the server only supports authorization by key, which I could not get at all.

Fortunately for me, the device is based on the version of the single-board device that comes without an eMMC, and the download is done from a standard MicroSD card that runs from the end of the board. Actually, all you need to get access to the contents of the firmware is to insert the card into the card reader. On 8Gb SanDisk there are 3 sections:

/dev/sdb1 on /media/user/disk type squashfs /dev/sdb2 on /media/user/UBOOT type vfat /dev/sdb3 on /media/user/07836191-ddf8-45ab-b02b-1103320c2e5b type ext4 

Sizes of sections:

 /dev/sdb1 25M 25M 0 100% /media/user/disk /dev/sdb2 16M 2.2M 14M 14% /media/user/UBOOT /dev/sdb3 58M 9.4M 45M 18% /media/user/07836191-ddf8-45ab-b02b-1103320c2e5b 

The “UBOOT” section seems to be used only by the U-Boot bootloader. The ext4 section contains logs (/ log) of the main subsystems (kern, lighttpd, line, netcfgd, syslog) and the video surveillance server settings that can be changed by the user (/ lib / line). And on the section “disk” with squashfs (compressed read-only) all the OS files and programs are already located. It turns out that the operating system and the logical part with all the "Analysts" and "Clouds" are fit for developers in 25 MB, which coincides with the size of the updates on their website, i.e. the entire firmware is being replaced, not just the video surveillance software.

The main section contains the usual set of directories:

 bin dev factory media root sbin tmp var boot etc lib proc run sys usr 

In general, there is nothing unusual in the directory tree, everything is in place. Runit services are running in / etc / service:

 dropbear hwclock-fix lighttpd line netcfgd socklog-klog socklog-unix 

Seeing the list lighttpd, I decided to check whether I can use it for their own purposes. It runs with the configuration:

 server.modules += ( "mod_cgi" ) $SERVER["socket"] == ":19587" { include_shell "/usr/share/adm/lighttpd-gencert" server.document-root = "/usr/share/adm/www" cgi.execute-x-only = "enable" cgi.assign = ( "" => "" ) } 

Content / usr / share / adm / www:

 datetime firmware password profiles sysinfo timezones factory-reset locale profile settings timezone 

By the set of scripts, it is clear that the HTTP server provides opportunities for the utility that allows you to change the system settings of the device and update the firmware, it turns out, all this can be done without its participation via the HTTP protocol. For example, you can get an archive with system information via a browser:

 https://192.168.1.2:19587/sysinfo 

The server uses the generated self-signed certificate and standard authorization with the ability to change the password (only hash is stored on the device). A ready HTTPS server with authorization and a very simple option to add my script saved me a lot of time and I proceeded directly to GPIO.

Firmware upgrade

A simple query in Google "Orange Pi PC GPIO" immediately led me to the commands:

 echo 0 > /sys/class/gpio_sw/PA1/data echo 1 > /sys/class/gpio_sw/PA1/data 

Finding port names was also not a problem:


Looking at the existing scripts, I created a new one with the name alarm and content:

 #!/bin/sh set -e . ../lib/devline/http.sh . ../lib/devline/auth.sh is_auth || http_err_unauth [ "$REQUEST_METHOD" = "PUT" ] || http_err_method PUT value="$(head -c "$CONTENT_LENGTH" | tr -d '.')" echo $value > /sys/class/gpio_sw/PA3/data echo "Content-Type: text/plain" echo echo OK 

Firmware upgrade

It only remained for me to add a new file to the device, which cannot be done by regular copying, since target file system is read only. Probably, there are different ways to make changes to squashfs, but I went the easiest, in my opinion. First of all, I considered the image of the section to file:

 dd if=/dev/sdb2 of=sdb2.img 

Then I unpacked the squashfs in a regular directory:

 unsquashfs sdb2.img 

I copied the alarm script along the necessary path to squashfs-root and collected a new squashfs image from it:

 mksquashfs squashfs-root sdb2-new.img 

Which then flooded back to the USB flash drive:

 dd if=sdb2-new.img of=/dev/sdb2 

Total

At the moment I can close the relay through a protected channel:

 curl -X PUT -k --data '1' https://admin:j3ks92ls8f@192.168.1.2:19587/alarm 

and open it:

 curl -X PUT -k --data '0' https://admin:j3ks92ls8f@192.168.1.2:19587/alarm 

By and large, for me personally, it was just an assessment of the technical feasibility of the implementation of the idea. The rating is positive: I have access to I / O ports and I can add my logic to the device firmware. As a bonus, I received a ready-to-use HTTPS server.

In my opinion, this was the most interesting part of the development, then for the most part there is only routine left, and I’m not sure if I’ll finish all my plans in full. In any case, if someone decides to repeat something similar, here are a couple of ideas for the further development of the current result:

1. Write a script service that will monitor the status of the inputs with sensors and respond to the triggering (notify, turn on the siren). Everything is clear here, there are no difficulties with the service or with the notification, even the curl executable file is already on the device, i.e. There are several options for notifications: SMTP and receiving messages via IMAP, ready SMS sending services, own server;
   
   
2. Achieve work over the Internet without a direct IP address. The fact is that only the main video server software works through the cloud, and the lighttp server that implements the system settings is accessible only directly, which, of course, is not bad for itself. On this point, I'm not so sure of the simplicity of implementation, my ideas are limited to two options so far: ssh-tunnel (you need to add your public key to the device) or your server and long polling from the device side.

I would be grateful for your ideas.