Hej alle!

Det er nok ingen hemmelighed, at cloud-videoovervågningstjenester har vundet popularitet for nylig. Og det er klart, hvorfor dette sker, video er "tungt" indhold, hvis lagring kræver infrastruktur og store mængder disklager. Brug af et lokalt videoovervågningssystem kræver midler til drift og støtte, både for en organisation, der bruger hundredvis af overvågningskameraer, og for en individuel bruger med flere kameraer.

Cloud-videoovervågningssystemer løser dette problem ved at give kunderne en eksisterende videolagrings- og -behandlingsinfrastruktur. En cloud-videoovervågningsklient skal blot forbinde kameraet til internettet og knytte det til sin cloud-konto.

Der er flere teknologiske måder at forbinde kameraer til skyen på. Den mest bekvemme og billigste metode er utvivlsomt, at kameraet direkte forbinder og arbejder med skyen, uden deltagelse af ekstra udstyr såsom en server eller optager.

For at gøre dette er det nødvendigt, at et softwaremodul, der arbejder med skyen, er installeret på kameraet. Men hvis vi taler om billige kameraer, så har de meget begrænsede hardwareressourcer, som næsten er 100% besat af kameraleverandørens native firmware, og der er ingen nødvendige ressourcer til cloud-plugin'et. Udviklere fra ivideon viede dette problem en artikel, hvilket forklarer hvorfor de ikke kan installere pluginnet på billige kameraer. Som et resultat er minimumsprisen for kameraet 5000 rubler ($80 dollars) og millioner af penge brugt på udstyr.

Vi har med succes løst dette problem. Hvis du er interesseret i hvordan - velkommen til skæringen

Lidt historie

I 2016 begyndte vi at udvikle en cloud-videoovervågningsplatform til Rostelecom.

Med hensyn til kamerasoftware fulgte vi i første fase "standard"-stien til sådanne opgaver: Vi udviklede vores eget plugin, som er installeret i standardfirmwaren på leverandørens kamera og fungerer med vores sky. Det er dog værd at bemærke, at vi under designet brugte de mest lette og effektive løsninger (for eksempel almindelig C-implementering af protobuf, libev, mbedtls og fuldstændigt forladte praktiske, men tunge biblioteker som boost)

I øjeblikket er der ingen universelle integrationsløsninger på IP-kameramarkedet: hver leverandør har sin egen måde at installere plugin på, sit eget sæt API'er til betjening af firmwaren og en unik opdateringsmekanisme.

Det betyder, at det for hver kameraleverandør er nødvendigt individuelt at udvikle et omfattende lag af integrationssoftware. Og på tidspunktet for udviklingsstart, er det tilrådeligt kun at arbejde med 1 leverandør for at koncentrere teamets indsats om at udvikle logikken for at arbejde med skyen.

Den første leverandør, der blev valgt, var Hikvision, en af ​​verdens førende på kameramarkedet, der leverede en veldokumenteret API og kompetent teknisk teknisk support.

Vi lancerede vores første pilotprojekt, cloud-videoovervågning Video Comfort, ved hjælp af Hikvision-kameraer.

Næsten umiddelbart efter lanceringen begyndte vores brugere at stille spørgsmål om muligheden for at tilslutte billigere kameraer fra andre producenter til tjenesten.

Jeg afviste muligheden for at implementere et integrationslag for hver leverandør næsten med det samme - da det er dårligt skalerbart og stiller alvorlige tekniske krav til kameraets hardware. Prisen for et kamera, der opfylder disse inputkrav: ~60-70$

Derfor besluttede jeg at grave dybere - at lave min egen firmware til kameraer fra enhver leverandør. Denne tilgang reducerer kravene til kamerahardwareressourcer markant - pga Laget til at arbejde med skyen er meget mere effektivt integreret med videoapplikationen, og der er ikke unødvendigt ubrugt fedt i firmwaren.

Og det, der er vigtigt, er, at når man arbejder med kameraet på et lavt niveau, er det muligt at bruge hardware AES, som krypterer data uden at skabe yderligere belastning på laveffekt-CPU'en.

I det øjeblik havde vi intet overhovedet. Ingenting overhovedet.

Næsten alle leverandører var ikke klar til at arbejde med os på et så lavt niveau. Der er ingen oplysninger om kredsløb og komponenter, der er ingen officiel SDK for chipsæt og sensordokumentation.
Der er heller ingen teknisk support.

Alle spørgsmål skulle besvares gennem reverse engineering - forsøg og fejl. Men vi klarede os.

De første kameramodeller, vi testede på, var Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link-kameraer og flere ultrabillige navnløse kinesiske kameraer.

Teknik

Kameraer baseret på Hisilicon 3518E chipset. Kameraernes hardwareegenskaber er som følger:

Xiaomi Yi myrer
noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
—

Sensor
ov9732 (720p)
ov9712 (720p)

Ethernet
—
+

MicroSD
+
+

Mikrofon
+
+

Højttaler
+
+

IRLed
+
+

IRCut
+
+

Vi startede med dem.

Vi understøtter i øjeblikket Hisilicon 3516/3518 chipsæt, samt Ambarella S2L/S2LM. Der er snesevis af kameramodeller.

Firmware sammensætning

undervandsbåd

uboot er opstartsindlæseren, den starter først efter tænding, initialiserer hardwaren og indlæser linux-kernen.

Kameraindlæsningsscriptet er ret trivielt:

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

En af funktionerne er, at den kaldes to gange bootm, mere om dette lidt senere, når vi kommer til opdateringsundersystemet.

Vær opmærksom på linjen mem=38M. Ja, ja, dette er ikke en tastefejl - Linux-kernen og alle, alle applikationer har kun adgang til 38 megabyte RAM.

Også ved siden af ​​uboot er der en speciel blok kaldet reg_info, som indeholder et script på lavt niveau til initialisering af DDR og en række systemregistre for SoC. Indhold reg_info afhænger af kameramodellen, og hvis det ikke er korrekt, vil kameraet ikke engang være i stand til at indlæse uboot, men vil fryse på det meget tidlige tidspunkt af indlæsningen.

Først, da vi arbejdede uden leverandørsupport, kopierede vi simpelthen denne blok fra den originale kamerafirmware.

Linux-kerne og rootfs

Kameraerne bruger Linux-kernen, som er en del af chippens SDK, normalt er det ikke de nyeste kerner fra 3.x-grenen, så vi må ofte forholde os til, at drivere til ekstraudstyr ikke er kompatible med den anvendte kerne. , og vi er nødt til at backportere dem til kernekameraerne.

Et andet problem er størrelsen af ​​kernen. Når FLASH-størrelsen kun er 8MB, så tæller hver byte, og vores opgave er omhyggeligt at deaktivere alle ubrugte kernefunktioner for at reducere størrelsen til et minimum.

Rootfs er et grundlæggende filsystem. Det omfatter busybox, wifi-moduldrivere, et sæt standard systembiblioteker, som f.eks libld и libc, samt vores software, som er ansvarlig for LED-kontrollogikken, netværksforbindelsesstyring og firmwareopdateringer.

Rodfilsystemet er forbundet til kernen som initramfs, og som et resultat af opbygningen får vi én fil uImage, som indeholder både kernen og rootfs.

Video applikation

Den mest komplekse og ressourcekrævende del af firmwaren er applikationen, som giver video-lydoptagelse, videokodning, konfigurerer billedparametre, implementerer videoanalyse, for eksempel bevægelses- eller lyddetektorer, styrer PTZ og er ansvarlig for skiftedag og nattilstande.

En vigtig, jeg vil endda sige nøglefunktion, er, hvordan videoapplikationen interagerer med cloud-plugin'et.

I traditionelle løsninger 'vendor firmware + cloud plugin', som ikke kan fungere på billig hardware, overføres video inde i kameraet via RTSP-protokollen - og det er en enorm overhead: kopiering og transmission af data via socket, unødvendige syscalls.

Her bruger vi den delte hukommelsesmekanisme - videoen kopieres eller sendes ikke via socket mellem kameraets softwarekomponenter, hvorved man optimalt og omhyggeligt udnytter kameraets beskedne hardwaremuligheder.

Opdater undersystem

En særlig stolthed er det fejltolerante undersystem til online firmwareopdateringer.

Lad mig forklare problemet. Opdatering af firmwaren er teknisk set ikke en atomoperation, og hvis der opstår strømsvigt midt i opdateringen, vil flashhukommelsen indeholde en del af den "underskrevne" nye firmware. Hvis du ikke tager særlige forholdsregler, bliver kameraet til en "klods", der skal tages med til et servicecenter.

Vi har også håndteret dette problem. Selvom kameraet er slukket under opdateringen, vil det automatisk og uden brugerindblanding downloade firmwaren fra skyen og genoprette driften.

Lad os se på teknikken mere detaljeret:

Det mest sårbare punkt er at overskrive partitionen med Linux-kernen og rodfilsystemet. Hvis en af ​​disse komponenter er beskadiget, starter kameraet slet ikke ud over uboot-bootloaderen, som ikke kan downloade firmware fra skyen.

Det betyder, at vi skal sikre, at kameraet har en fungerende kerne og rootfs til enhver tid under opdateringsprocessen. Det ser ud til, at den enkleste løsning ville være konstant at gemme to kopier af kernen med rootfs på flash-hukommelsen og, hvis hovedkernen er beskadiget, indlæse den fra sikkerhedskopien.

En god løsning - dog fylder kernen med rootfs omkring 3.5MB og for en permanent backup skal du allokere 3.5MB. De billigste kameraer har simpelthen ikke så meget ledig plads til en backupkerne.

Derfor bruger vi applikationspartitionen til at tage backup af kernen under en firmwareopdatering.
Og for at vælge den ønskede partition med kernen, bruges to kommandoer bootm i uboot - i begyndelsen forsøger vi at indlæse hovedkernen, og hvis den er beskadiget, så den backup.

Dette sikrer, at kameraet til enhver tid vil have den korrekte kerne med rootfs, og det vil være i stand til at starte og gendanne firmwaren.

CI/CD-system til opbygning og implementering af firmware

Til at bygge firmware bruger vi gitlab CI, som automatisk bygger firmware til alle understøttede kameramodeller, og efter opbygning af firmwaren implementeres den automatisk til kamerasoftwareopdateringstjenesten.

Fra tjenesten leveres firmwareopdateringer til vores QA-testkameraer og efter afslutning af alle teststadier til brugernes kameraer.

Informationssikkerhed

Det er ingen hemmelighed, at informationssikkerhed i dag er det vigtigste aspekt af enhver IoT-enhed, inklusive kameraer. Botnets som Mirai roamer på internettet og inficerer millioner af kameraer med standard firmware fra leverandører. Med al respekt for kameraleverandører kan jeg ikke undgå at bemærke, at standard firmware indeholder en masse funktionalitet, der ikke er nødvendig for at arbejde med skyen, men indeholder mange sårbarheder, som botnets udnytter.

Derfor er al ubrugt funktionalitet i vores firmware deaktiveret, alle tcp/udp-porte lukkes, og ved opdatering af firmwaren tjekkes softwarens digitale signatur.

Og udover dette gennemgår firmwaren regelmæssig test i informationssikkerhedslaboratoriet.

Konklusion

Nu bruges vores firmware aktivt i videoovervågningsprojekter. Måske den største af dem er udsendelsen af ​​afstemninger på dagen for valget af præsidenten for Den Russiske Føderation.
Projektet involverede mere end 70 tusinde kameraer med vores firmware, som blev installeret på valgsteder i vores land.

Efter at have løst en række komplekse, og nogle steder, selv på det tidspunkt næsten umulige problemer, fik vi naturligvis stor tilfredshed som ingeniører, men udover dette sparede vi også millioner af dollars på indkøb af kameraer. Og i dette tilfælde er besparelser ikke kun ord og teoretiske beregninger, men resultaterne af et allerede gennemført udbud til køb af udstyr. Derfor, hvis vi taler om cloud-videoovervågning: Der er to tilgange - strategisk afhængig af ekspertise og udvikling på lavt niveau, hvilket resulterer i enorme besparelser på udstyr, eller brug dyrt udstyr, som, hvis du ser specifikt på forbrugerkarakteristika, praktisk talt ikke er anderledes end lignende billige.

Hvorfor er det strategisk vigtigt at tage stilling til valget af integrationstilgang så tidligt som muligt? Når udviklere udvikler et plugin, er de afhængige af visse teknologier (biblioteker, protokoller, standarder). Og hvis et sæt teknologier kun vælges til dyrt udstyr, vil et forsøg på at skifte til billige kameraer i fremtiden højst sandsynligt, som minimum, tage sindssygt lang tid eller endda mislykkes, og en tilbagevenden til dyrt udstyr vil ske.

Kilde: www.habr.com