Ciao a tutti!

Probabilmente non è un segreto che i servizi di videosorveglianza cloud stiano guadagnando popolarità di recente. Ed è chiaro il motivo per cui ciò accade: i video sono contenuti "pesanti", la cui archiviazione richiede infrastrutture e grandi quantità di spazio di archiviazione su disco. L'utilizzo di un sistema di videosorveglianza locale richiede fondi per il funzionamento e il supporto, sia per un'organizzazione che utilizza centinaia di telecamere di sorveglianza sia per un singolo utente con diverse telecamere.

I sistemi di videosorveglianza cloud risolvono questo problema fornendo ai clienti un'infrastruttura di archiviazione ed elaborazione video esistente. Un cliente di videosorveglianza cloud deve semplicemente connettere la telecamera a Internet e collegarla al suo account cloud.

Esistono diversi modi tecnologici per connettere le telecamere al cloud. Indubbiamente, il metodo più conveniente ed economico è che la telecamera si colleghi e funzioni direttamente con il cloud, senza la partecipazione di apparecchiature aggiuntive come un server o un registratore.

Per fare ciò è necessario che sulla telecamera sia installato un modulo software che funzioni con il cloud. Tuttavia, se parliamo di fotocamere economiche, hanno risorse hardware molto limitate, che sono occupate quasi al 100% dal firmware nativo del fornitore della fotocamera, e non ci sono risorse necessarie per il plug-in cloud. Gli sviluppatori di ivideon hanno dedicato questo problema Articolo, il che spiega perché non possono installare il plugin su fotocamere economiche. Di conseguenza, il prezzo minimo della fotocamera è di 5000 rubli (80 dollari) e si spendono milioni di soldi per l’attrezzatura.

Abbiamo risolto con successo questo problema. Se sei interessato a come, benvenuto nel taglio

Un po 'di storia

Nel 2016 abbiamo iniziato a sviluppare una piattaforma di videosorveglianza cloud per Rostelecom.

In termini di software della fotocamera, nella prima fase abbiamo seguito il percorso “standard” per tali attività: abbiamo sviluppato il nostro plugin, che è installato nel firmware standard della fotocamera del fornitore e funziona con il nostro cloud. Tuttavia, vale la pena notare che durante la progettazione abbiamo utilizzato le soluzioni più leggere ed efficienti (ad esempio, la semplice implementazione in C di protobuf, libev, mbedtls e abbiamo completamente abbandonato le librerie comode ma pesanti come boost)

Attualmente non esistono soluzioni di integrazione universali sul mercato delle telecamere IP: ogni fornitore ha il proprio modo di installare il plug-in, il proprio set di API per il funzionamento del firmware e un meccanismo di aggiornamento unico.

Ciò significa che per ciascun fornitore di fotocamere è necessario sviluppare individualmente un livello completo di software di integrazione. E al momento dell'avvio dello sviluppo, è consigliabile lavorare solo con 1 fornitore per concentrare gli sforzi del team sullo sviluppo della logica per lavorare con il cloud.

Il primo fornitore scelto è stato Hikvision, uno dei leader mondiali nel mercato delle fotocamere, che fornisce un'API ben documentata e un supporto tecnico tecnico competente.

Abbiamo lanciato il nostro primo progetto pilota, la videosorveglianza cloud Video Comfort, utilizzando telecamere Hikvision.

Quasi subito dopo il lancio, i nostri utenti hanno iniziato a porre domande sulla possibilità di collegare al servizio fotocamere più economiche di altri produttori.

Ho rifiutato quasi immediatamente l'opzione di implementare un livello di integrazione per ciascun fornitore, poiché è scarsamente scalabile e impone seri requisiti tecnici all'hardware della fotocamera. Il costo di una fotocamera che soddisfa questi requisiti di input: ~60-70$

Pertanto, ho deciso di scavare più a fondo e creare il mio firmware per fotocamere di qualsiasi fornitore. Questo approccio riduce significativamente i requisiti per le risorse hardware della fotocamera, perché Il livello per lavorare con il cloud è integrato in modo molto più efficace con l'applicazione video e nel firmware non è presente grasso inutilizzato non necessario.

E ciò che è importante è che quando si lavora con la fotocamera a basso livello, è possibile utilizzare l'hardware AES, che crittografa i dati senza creare carico aggiuntivo sulla CPU a basso consumo.

In quel momento non avevamo niente. Niente di niente.

Quasi tutti i fornitori non erano pronti a lavorare con noi a un livello così basso. Non ci sono informazioni sui circuiti e sui componenti, non esiste un SDK ufficiale di chipset e documentazione sui sensori.
Inoltre non c'è supporto tecnico.

È stato necessario rispondere a tutte le domande attraverso il reverse engineering: tentativi ed errori. Ma ci siamo riusciti.

I primi modelli di fotocamere su cui abbiamo testato sono state le fotocamere Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link e diverse fotocamere cinesi senza nome ultra economiche.

attrezzatura

Fotocamere basate sul chipset Hisilicon 3518E. Le caratteristiche hardware delle telecamere sono le seguenti:

Formiche Xiaomi Yi
Noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Sensore
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Microfono
+
+

Speaker
+
+

IRLed
+
+

Taglio IR
+
+

Abbiamo iniziato con loro.

Attualmente supportiamo i chipset Hisilicon 3516/3518 e Ambarella S2L/S2LM. Esistono dozzine di modelli di fotocamere.

Composizione del firmware

sottomarino

uboot è il boot loader, si avvia per primo dopo l'accensione, inizializza l'hardware e carica il kernel Linux.

Lo script di caricamento della fotocamera è piuttosto banale:

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

Una delle caratteristiche è che viene chiamato due volte bootm, ne parleremo più avanti, quando arriveremo al sottosistema di aggiornamento.

Prestare attenzione alla linea mem=38M. Sì, sì, non è un errore di battitura: il kernel Linux e tutte, tutte, tutte le applicazioni hanno accesso a soli 38 megabyte di RAM.

Inoltre accanto a uboot c'è un blocco speciale chiamato reg_info, che contiene uno script di basso livello per l'inizializzazione del DDR e una serie di registri di sistema del SoC. Contenuto reg_info dipende dal modello di fotocamera e, se non è corretto, la fotocamera non sarà nemmeno in grado di caricare uboot, ma si bloccherà nella primissima fase di caricamento.

All'inizio, quando lavoravamo senza il supporto del fornitore, copiavamo semplicemente questo blocco dal firmware originale della fotocamera.

Kernel Linux e rootf

Le telecamere utilizzano il kernel Linux, che fa parte dell'SDK del chip; di solito non si tratta dei kernel più recenti del ramo 3.x, quindi spesso dobbiamo fare i conti con il fatto che i driver di apparecchiature aggiuntive non sono compatibili con il kernel utilizzato , e dobbiamo eseguirne il backport sulle telecamere del kernel.

Un altro problema è la dimensione del kernel. Quando la dimensione della FLASH è di soli 8 MB, allora ogni byte conta e il nostro compito è disabilitare attentamente tutte le funzioni del kernel non utilizzate per ridurre la dimensione al minimo.

Rootfs è un file system di base. Include busybox, driver dei moduli Wi-Fi, una serie di librerie di sistema standard, come libld и libc, così come il nostro software, che è responsabile della logica di controllo dei LED, della gestione della connessione di rete e degli aggiornamenti del firmware.

Il file system root è connesso al kernel come initramfs e come risultato della compilazione otteniamo un file uImage, che contiene sia il kernel che rootfs.

Applicazione video

La parte più complessa e dispendiosa in termini di risorse del firmware è l'applicazione, che fornisce acquisizione video-audio, codifica video, configura i parametri dell'immagine, implementa l'analisi video, ad esempio rilevatori di movimento o suono, controlla PTZ ed è responsabile del cambio di giorno e ora. modalità notturne.

Una caratteristica importante, direi addirittura fondamentale, è il modo in cui l'applicazione video interagisce con il plug-in cloud.

Nelle soluzioni tradizionali "firmware del fornitore + plug-in cloud", che non possono funzionare su hardware economico, il video all'interno della telecamera viene trasmesso tramite il protocollo RTSP - e questo comporta un enorme sovraccarico: copia e trasmissione di dati tramite socket, chiamate di sistema non necessarie.

Qui utilizziamo il meccanismo della memoria condivisa: il video non viene copiato o inviato tramite presa tra i componenti software della fotocamera, sfruttando così in modo ottimale e attento le modeste capacità hardware della fotocamera.

Aggiorna sottosistema

Un punto di particolare orgoglio è il sottosistema con tolleranza agli errori per gli aggiornamenti del firmware online.

Lasciami spiegare il problema. L'aggiornamento del firmware non è tecnicamente un'operazione atomica e, se si verifica un'interruzione di corrente nel mezzo dell'aggiornamento, la memoria flash conterrà parte del nuovo firmware "sottoscritto". Se non si adottano misure particolari, la fotocamera diventerà un “mattone” da portare in un centro assistenza.

Abbiamo affrontato anche questo problema. Anche se la fotocamera viene spenta durante l'aggiornamento, scaricherà automaticamente e senza l'intervento dell'utente il firmware dal cloud e ripristinerà il funzionamento.

Vediamo la tecnica più nel dettaglio:

Il punto più vulnerabile è sovrascrivere la partizione con il kernel Linux e il file system root. Se uno di questi componenti è danneggiato, la fotocamera non si avvierà affatto oltre il bootloader uboot, che non può scaricare il firmware dal cloud.

Ciò significa che dobbiamo assicurarci che la fotocamera abbia un kernel funzionante e rootfs in qualsiasi momento durante il processo di aggiornamento. Sembrerebbe che la soluzione più semplice sarebbe quella di archiviare costantemente due copie del kernel con rootfs sulla memoria flash e, se il kernel principale è danneggiato, caricarlo dalla copia di backup.

Una buona soluzione, tuttavia il kernel con rootfs occupa circa 3.5 MB e per un backup permanente è necessario allocare 3.5 MB. Le fotocamere più economiche semplicemente non hanno molto spazio libero per un kernel di backup.

Pertanto, per eseguire il backup del kernel durante un aggiornamento del firmware, utilizziamo la partizione dell'applicazione.
E per selezionare la partizione desiderata con il kernel, vengono utilizzati due comandi bootm in uboot - all'inizio proviamo a caricare il kernel principale e, se è danneggiato, quello di backup.

Ciò garantisce che in qualsiasi momento la fotocamera avrà il kernel corretto con rootfs e sarà in grado di avviare e ripristinare il firmware.

Sistema CI/CD per la creazione e la distribuzione del firmware

Per creare il firmware, utilizziamo gitlab CI, che crea automaticamente il firmware per tutti i modelli di fotocamera supportati e, dopo aver creato il firmware, viene automaticamente distribuito al servizio di aggiornamento del software della fotocamera.

Dal servizio, gli aggiornamenti del firmware vengono forniti alle nostre fotocamere di prova QA e, al completamento di tutte le fasi di test, alle fotocamere degli utenti.

Sicurezza delle informazioni

Non è un segreto che oggigiorno la sicurezza delle informazioni sia l'aspetto più importante di qualsiasi dispositivo IoT, comprese le fotocamere. Botnet come Mirai vagano per Internet, infettando milioni di fotocamere con firmware standard dei fornitori. Con tutto il rispetto per i fornitori di fotocamere, non posso fare a meno di notare che il firmware standard contiene molte funzionalità che non sono necessarie per lavorare con il cloud, ma contiene molte vulnerabilità di cui sfruttano le botnet.

Pertanto, tutte le funzionalità inutilizzate nel nostro firmware sono disabilitate, tutte le porte tcp/udp sono chiuse e durante l'aggiornamento del firmware viene controllata la firma digitale del software.

Inoltre, il firmware viene sottoposto a test regolari nel laboratorio di sicurezza informatica.

conclusione

Ora il nostro firmware viene utilizzato attivamente nei progetti di videosorveglianza. Forse il più grande di questi è la trasmissione delle votazioni nel giorno dell'elezione del Presidente della Federazione Russa.
Il progetto ha coinvolto più di 70mila telecamere con il nostro firmware, che sono state installate nei seggi elettorali del nostro Paese.

Avendo risolto una serie di problemi complessi e in alcuni punti anche a quel tempo quasi impossibili, ovviamente abbiamo ricevuto grandi soddisfazioni come ingegneri, ma oltre a questo abbiamo anche risparmiato milioni di dollari sull'acquisto di fotocamere. E in questo caso il risparmio non è solo parole e calcoli teorici, ma il risultato di una gara già conclusa per l'acquisto di attrezzature. Di conseguenza, se parliamo di videosorveglianza nel cloud: ci sono due approcci: affidarsi strategicamente a competenze e sviluppo di basso livello, con conseguenti enormi risparmi sulle apparecchiature, oppure utilizzare apparecchiature costose, che, se si guarda specificamente alle caratteristiche del consumatore, non è praticamente nulla diversi da quelli simili economici.

Perché è strategicamente importante decidere il prima possibile sulla scelta dell’approccio di integrazione? Quando sviluppano un plugin, gli sviluppatori si affidano a determinate tecnologie (librerie, protocolli, standard). E se un insieme di tecnologie viene scelto solo per apparecchiature costose, in futuro molto probabilmente un tentativo di passare a fotocamere economiche richiederà, come minimo, un tempo follemente lungo o addirittura fallirà e si verificherà un ritorno ad apparecchiature costose.

Fonte: habr.com