Hallo an alle!

Es ist wahrscheinlich kein Geheimnis, dass Cloud-Videoüberwachungsdienste in letzter Zeit immer beliebter werden. Und es ist klar, warum das passiert, denn Videos sind „schwere“ Inhalte, deren Speicherung Infrastruktur und große Mengen an Festplattenspeicher erfordert. Der Einsatz eines Videoüberwachungssystems vor Ort erfordert finanzielle Mittel für Betrieb und Support, sowohl für eine Organisation, die Hunderte von Überwachungskameras verwendet, als auch für einen einzelnen Benutzer mit mehreren Kameras.

Cloud-Videoüberwachungssysteme lösen dieses Problem, indem sie Kunden eine vorhandene Videospeicher- und -verarbeitungsinfrastruktur zur Verfügung stellen. Ein Cloud-Videoüberwachungskunde muss lediglich die Kamera mit dem Internet verbinden und sie mit seinem Cloud-Konto verknüpfen.

Es gibt verschiedene technologische Möglichkeiten, Kameras mit der Cloud zu verbinden. Die bequemste und kostengünstigste Methode besteht zweifellos darin, dass sich die Kamera direkt mit der Cloud verbindet und mit ihr zusammenarbeitet, ohne dass zusätzliche Geräte wie ein Server oder ein Rekorder erforderlich sind.

Hierzu ist es notwendig, dass auf der Kamera ein mit der Cloud arbeitendes Softwaremodul installiert ist. Wenn es sich jedoch um günstige Kameras handelt, verfügen diese über sehr begrenzte Hardwareressourcen, die fast zu 100 % von der nativen Firmware des Kameraherstellers belegt werden, und es sind keine Ressourcen für das Cloud-Plugin erforderlich. Entwickler von ivideon haben sich diesem Problem gewidmet Artikel, was erklärt, warum sie das Plugin nicht auf billigen Kameras installieren können. Infolgedessen beträgt der Mindestpreis der Kamera 5000 Rubel (80 US-Dollar) und es werden Millionen von Geld für die Ausrüstung ausgegeben.

Wir haben dieses Problem erfolgreich gelöst. Wenn Sie daran interessiert sind, wie – willkommen zum Schnitt

Ein wenig Geschichte

Im Jahr 2016 begannen wir mit der Entwicklung einer Cloud-Videoüberwachungsplattform für Rostelecom.

Was die Kamerasoftware angeht, sind wir für solche Aufgaben im ersten Schritt den „Standard“-Weg gegangen: Wir haben ein eigenes Plugin entwickelt, das in der Standard-Firmware der Kamera des Herstellers installiert ist und mit unserer Cloud funktioniert. Es ist jedoch erwähnenswert, dass wir während des Entwurfs die leichtesten und effizientesten Lösungen verwendet haben (z. B. die einfache C-Implementierung von Protobuf, Libev, Mbedtls und den Verzicht auf praktische, aber umfangreiche Bibliotheken wie Boost).

Derzeit gibt es keine universellen Integrationslösungen auf dem Markt für IP-Kameras: Jeder Anbieter hat seine eigene Art, das Plugin zu installieren, seine eigenen APIs für den Betrieb der Firmware und einen einzigartigen Update-Mechanismus.

Das bedeutet, dass es für jeden Kamerahersteller notwendig ist, individuell eine umfassende Ebene der Integrationssoftware zu entwickeln. Und zu Beginn der Entwicklung ist es ratsam, nur mit einem Anbieter zusammenzuarbeiten, um die Bemühungen des Teams auf die Entwicklung der Logik für die Arbeit mit der Cloud zu konzentrieren.

Der erste ausgewählte Anbieter war Hikvision, einer der Weltmarktführer im Kameramarkt, der eine gut dokumentierte API und kompetenten technischen Support bietet.

Wir haben unser erstes Pilotprojekt, die Cloud-Videoüberwachung Video Comfort, mit Hikvision-Kameras gestartet.

Fast unmittelbar nach dem Start stellten unsere Benutzer Fragen zur Möglichkeit, günstigere Kameras anderer Hersteller an den Dienst anzuschließen.

Ich habe die Option, für jeden Anbieter eine Integrationsschicht zu implementieren, fast sofort abgelehnt, da diese schlecht skalierbar ist und erhebliche technische Anforderungen an die Kamerahardware stellt. Die Kosten für eine Kamera, die diese Eingabeanforderungen erfüllt: ~60–70 $

Deshalb habe ich beschlossen, tiefer zu graben und meine eigene Firmware für Kameras aller Hersteller zu erstellen. Dieser Ansatz reduziert den Bedarf an Kamera-Hardware-Ressourcen erheblich – denn Die Ebene für die Arbeit mit der Cloud ist viel effektiver in die Videoanwendung integriert und es gibt kein unnötiges ungenutztes Fett in der Firmware.

Und was wichtig ist, ist, dass bei Arbeiten mit der Kamera auf niedriger Ebene die Verwendung von Hardware-AES möglich ist, das Daten verschlüsselt, ohne die CPU mit geringem Stromverbrauch zusätzlich zu belasten.

In diesem Moment hatten wir überhaupt nichts. Gar nichts.

Fast alle Anbieter waren auf einem so niedrigen Niveau nicht bereit, mit uns zusammenzuarbeiten. Es gibt keine Informationen über die Schaltung und Komponenten, es gibt kein offizielles SDK von Chipsätzen und keine Sensordokumentation.
Es gibt auch keinen technischen Support.

Alle Fragen mussten durch Reverse Engineering – Versuch und Irrtum – beantwortet werden. Aber wir haben es geschafft.

Die ersten Kameramodelle, die wir getestet haben, waren Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link-Kameras und mehrere ultragünstige namenlose chinesische Kameras.

Ausrüstung

Kameras basierend auf dem Hisilicon 3518E-Chipsatz. Die Hardware-Eigenschaften der Kameras sind wie folgt:

Xiaomi Yi Ameisen
Noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

BLINKEN
16MB
8MB

W-Lan
mt7601/bcm43143
-

Sensor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Mikrofon
+
+

Speaker
+
+

Infrarot-LED
+
+

IRCut
+
+

Wir haben mit ihnen angefangen.

Wir unterstützen derzeit Hisilicon 3516/3518-Chipsätze sowie Ambarella S2L/S2LM. Es gibt Dutzende Kameramodelle.

Firmware-Zusammensetzung

uboot

uboot ist der Bootloader, der nach dem Einschalten zuerst bootet, die Hardware initialisiert und den Linux-Kernel lädt.

Das Skript zum Laden der Kamera ist recht trivial:

bootargs=mem=38M console=ttyAMA0,115200 rootfstype=ramfs mtdparts=hi_sfc:256K(boot),64K(tech),4096K(kernel),8192K(app),-(config) hw_type=101
bootcmd=sf probe 0; sf read 0x82000000 0x50000 0x400000; bootm 0x82000000; setenv bootargs $(bootargs) bkp=1; sf read 0x82000000 0x450000 0x400000; bootm 0x82000000

Eines der Merkmale ist, dass es zweimal aufgerufen wird bootm, mehr dazu später, wenn wir zum Update-Subsystem kommen.

Achten Sie auf die Linie mem=38M. Ja, ja, das ist kein Tippfehler – der Linux-Kernel und alle, alle, alle Anwendungen haben Zugriff auf nur 38 Megabyte RAM.

Neben uboot gibt es auch einen speziellen Block namens reg_info, das ein Low-Level-Skript zum Initialisieren von DDR und einer Reihe von Systemregistern des SoC enthält. Inhalt reg_info Hängt vom Kameramodell ab. Wenn es nicht korrekt ist, kann die Kamera uboot nicht einmal laden, sondern friert in der sehr frühen Phase des Ladevorgangs ein.

Als wir zunächst ohne Herstellerunterstützung arbeiteten, kopierten wir diesen Block einfach von der ursprünglichen Kamera-Firmware.

Linux-Kernel und RootFS

Die Kameras nutzen den Linux-Kernel, der Teil des SDK des Chips ist; in der Regel handelt es sich dabei nicht um die neuesten Kernel aus dem 3.x-Zweig, sodass wir oft damit rechnen müssen, dass Treiber für Zusatzgeräte nicht mit dem verwendeten Kernel kompatibel sind , und wir müssen sie auf die Kernel-Kameras zurückportieren.

Ein weiteres Problem ist die Größe des Kernels. Wenn die FLASH-Größe nur 8 MB beträgt, zählt jedes Byte und unsere Aufgabe besteht darin, alle nicht verwendeten Kernelfunktionen sorgfältig zu deaktivieren, um die Größe auf ein Minimum zu reduzieren.

Rootfs ist ein grundlegendes Dateisystem. Es enthält busybox, WLAN-Modultreiber, eine Reihe von Standardsystembibliotheken, wie z libld и libc, sowie unsere Software, die für die LED-Steuerungslogik, Netzwerkverbindungsverwaltung und Firmware-Updates verantwortlich ist.

Das Root-Dateisystem ist als initramfs mit dem Kernel verbunden und als Ergebnis des Builds erhalten wir eine Datei uImage, das sowohl den Kernel als auch Rootfs enthält.

Bewerbungsvideo

Der komplexeste und ressourcenintensivste Teil der Firmware ist die Anwendung, die Video-Audio-Aufnahme und Videokodierung bereitstellt, Bildparameter konfiguriert, Videoanalysen implementiert, beispielsweise Bewegungs- oder Tonmelder, PTZ steuert und für die Umschaltung von Tag und Nacht verantwortlich ist Nachtmodi.

Eine wichtige, ich würde sogar sagen Schlüsselfunktion ist die Art und Weise, wie die Videoanwendung mit dem Cloud-Plugin interagiert.

Bei herkömmlichen Lösungen „Hersteller-Firmware + Cloud-Plugin“, die auf billiger Hardware nicht funktionieren, wird das Video innerhalb der Kamera über das RTSP-Protokoll übertragen – und das stellt einen enormen Mehraufwand dar: Kopieren und Übertragen von Daten über Socket, unnötige Systemaufrufe.

Hier verwenden wir den Shared-Memory-Mechanismus – das Video wird nicht kopiert oder über Sockets zwischen den Softwarekomponenten der Kamera gesendet, wodurch die bescheidenen Hardwarefunktionen der Kamera optimal und schonend genutzt werden.

Subsystem aktualisieren

Besonders stolz ist das fehlertolerante Subsystem für Online-Firmware-Updates.

Lassen Sie mich das Problem erklären. Bei der Aktualisierung der Firmware handelt es sich technisch gesehen um keinen atomaren Vorgang, und wenn während der Aktualisierung ein Stromausfall auftritt, enthält der Flash-Speicher einen Teil der „unterschriebenen“ neuen Firmware. Wenn Sie keine besonderen Maßnahmen ergreifen, wird die Kamera zu einem „Baustein“, der zu einem Servicecenter gebracht werden muss.

Auch wir haben uns mit diesem Problem beschäftigt. Selbst wenn die Kamera während des Updates ausgeschaltet ist, lädt sie automatisch und ohne Benutzereingriff die Firmware aus der Cloud herunter und stellt den Betrieb wieder her.

Schauen wir uns die Technik genauer an:

Der anfälligste Punkt ist das Überschreiben der Partition mit dem Linux-Kernel und dem Root-Dateisystem. Wenn eine dieser Komponenten beschädigt ist, startet die Kamera überhaupt nicht über den Uboot-Bootloader hinaus, der keine Firmware aus der Cloud herunterladen kann.

Das bedeutet, dass wir sicherstellen müssen, dass die Kamera zu jedem Zeitpunkt des Aktualisierungsvorgangs über einen funktionierenden Kernel und Rootfs verfügt. Es scheint, dass die einfachste Lösung darin besteht, ständig zwei Kopien des Kernels mit RootFS im Flash-Speicher zu speichern und ihn, wenn der Hauptkernel beschädigt ist, von der Sicherungskopie zu laden.

Eine gute Lösung – allerdings nimmt der Kernel mit RootFS etwa 3.5 MB ein und für eine dauerhafte Sicherung müssen Sie 3.5 MB zuweisen. Die billigsten Kameras haben einfach nicht so viel freien Speicherplatz für einen Backup-Kernel.

Um den Kernel während eines Firmware-Updates zu sichern, verwenden wir daher die Anwendungspartition.
Und um mit dem Kernel die gewünschte Partition auszuwählen, werden zwei Befehle verwendet bootm in uboot - am Anfang versuchen wir, den Hauptkernel zu laden und wenn er beschädigt ist, dann den Backup-Kernel.

Dadurch wird sichergestellt, dass die Kamera zu jedem Zeitpunkt über den richtigen Kernel mit RootFS verfügt und die Firmware booten und wiederherstellen kann.

CI/CD-System zum Erstellen und Bereitstellen von Firmware

Zum Erstellen der Firmware verwenden wir Gitlab CI, das automatisch Firmware für alle unterstützten Kameramodelle erstellt und nach dem Erstellen der Firmware automatisch für den Software-Update-Dienst der Kamera bereitgestellt wird.

Über den Dienst werden Firmware-Updates an unsere QA-Testkameras und nach Abschluss aller Testphasen an die Kameras der Benutzer geliefert.

Informationssicherheit

Es ist kein Geheimnis, dass Informationssicherheit heutzutage der wichtigste Aspekt jedes IoT-Geräts ist, einschließlich Kameras. Botnetze wie Mirai durchstreifen das Internet und infizieren Millionen von Kameras mit Standard-Firmware von Anbietern. Bei allem Respekt vor den Kameraherstellern kann ich nicht umhin festzustellen, dass die Standard-Firmware viele Funktionen enthält, die für die Arbeit mit der Cloud nicht benötigt werden, aber viele Schwachstellen aufweisen, die Botnets ausnutzen.

Daher sind alle ungenutzten Funktionen in unserer Firmware deaktiviert, alle TCP/UDP-Ports geschlossen und beim Aktualisieren der Firmware wird die digitale Signatur der Software überprüft.

Darüber hinaus wird die Firmware regelmäßig im Informationssicherheitslabor getestet.

Abschluss

Jetzt wird unsere Firmware aktiv in Videoüberwachungsprojekten eingesetzt. Die vielleicht größte davon ist die Übertragung der Abstimmung am Tag der Wahl des Präsidenten der Russischen Föderation.
Das Projekt umfasste mehr als 70 Kameras mit unserer Firmware, die in Wahllokalen in unserem Land installiert wurden.

Nachdem wir eine Reihe komplexer und an manchen Stellen selbst damals fast unmöglicher Probleme gelöst hatten, waren wir als Ingenieure natürlich sehr zufrieden, aber darüber hinaus haben wir auch Millionen von Dollar beim Kauf von Kameras gespart. Und in diesem Fall sind Einsparungen nicht nur Worte und theoretische Berechnungen, sondern das Ergebnis einer bereits abgeschlossenen Ausschreibung für den Kauf von Ausrüstung. Wenn wir also über Cloud-Videoüberwachung sprechen, gibt es zwei Ansätze – strategisch auf geringes Fachwissen und geringe Entwicklung zu setzen, was zu enormen Einsparungen bei der Ausrüstung führt, oder teure Ausrüstung zu verwenden, die, wenn man sich speziell die Verbrauchereigenschaften ansieht, praktisch nein ist anders als ähnliche billige.

Warum ist es strategisch wichtig, so früh wie möglich über die Wahl des Integrationsansatzes zu entscheiden? Bei der Entwicklung eines Plugins greifen Entwickler auf bestimmte Technologien (Bibliotheken, Protokolle, Standards) zurück. Und wenn eine Reihe von Technologien nur für teure Geräte ausgewählt werden, wird der Versuch, auf billige Kameras umzusteigen, in Zukunft höchstwahrscheinlich zumindest wahnsinnig lange dauern oder sogar scheitern und es wird zu einer Rückkehr zu teuren Geräten kommen.

Source: habr.com