Olá a todos!

Provavelmente não é segredo que os serviços de vigilância por vídeo em nuvem têm ganhado popularidade recentemente. E está claro por que isso acontece, o vídeo é um conteúdo “pesado”, cujo armazenamento requer infraestrutura e grandes quantidades de armazenamento em disco. O uso de um sistema de vigilância por vídeo local requer fundos para operação e suporte, tanto para uma organização que utiliza centenas de câmeras de vigilância quanto para um usuário individual com diversas câmeras.

Os sistemas de vigilância por vídeo em nuvem resolvem esse problema fornecendo aos clientes uma infraestrutura existente de armazenamento e processamento de vídeo. Um cliente de vigilância por vídeo na nuvem simplesmente precisa conectar a câmera à Internet e vinculá-la à sua conta na nuvem.

Existem várias formas tecnológicas de conectar câmeras à nuvem. Sem dúvida, o método mais conveniente e barato é que a câmera se conecte e funcione diretamente com a nuvem, sem a participação de equipamentos adicionais como servidor ou gravador.

Para isso, é necessário que um módulo de software que funcione com nuvem esteja instalado na câmera. Porém, se falamos de câmeras baratas, então elas possuem recursos de hardware muito limitados, que são quase 100% ocupados pelo firmware nativo do fornecedor da câmera, e não há recursos necessários para o plugin de nuvem. Os desenvolvedores da ivideon dedicaram este problema статью, o que explica por que eles não podem instalar o plugin em câmeras baratas. Como resultado, o preço mínimo da câmera é de 5000 rublos (US$ 80 dólares) e milhões de dinheiro gastos em equipamentos.

Resolvemos este problema com sucesso. Se você estiver interessado em saber como - bem-vindo ao corte

Um pouco de história

Em 2016, iniciamos o desenvolvimento de uma plataforma de videovigilância em nuvem para a Rostelecom.

Em termos de software de câmera, numa primeira etapa seguimos o caminho “padrão” para tais tarefas: desenvolvemos nosso próprio plugin, que é instalado no firmware padrão da câmera do fornecedor e funciona com nossa nuvem. No entanto, é importante notar que durante o design usamos as soluções mais leves e eficientes (por exemplo, implementação C simples de protobuf, libev, mbedtls e abandonamos completamente bibliotecas convenientes, mas pesadas, como boost)

Atualmente, não existem soluções de integração universais no mercado de câmeras IP: cada fornecedor possui sua própria forma de instalação do plugin, seu próprio conjunto de APIs para operação do firmware e um mecanismo de atualização exclusivo.

Isto significa que para cada fornecedor de câmeras é necessário desenvolver individualmente uma camada abrangente de software de integração. E na hora de iniciar o desenvolvimento é aconselhável trabalhar apenas com 1 fornecedor para concentrar os esforços da equipe no desenvolvimento da lógica de trabalho com nuvem.

O primeiro fornecedor escolhido foi a Hikvision, um dos líderes mundiais no mercado de câmeras, que fornece uma API bem documentada e suporte técnico de engenharia competente.

Lançamos nosso primeiro projeto piloto, videovigilância em nuvem Video Comfort, usando câmeras Hikvision.

Quase imediatamente após o lançamento, nossos usuários começaram a fazer perguntas sobre a possibilidade de conectar câmeras mais baratas de outros fabricantes ao serviço.

Rejeitei a opção de implementar uma camada de integração para cada fornecedor quase imediatamente - pois é pouco escalonável e impõe sérios requisitos técnicos ao hardware da câmera. O custo de uma câmera que atenda a estes requisitos de entrada: ~60-70$

Portanto, decidi ir mais fundo - fazer meu próprio firmware para câmeras de qualquer fornecedor. Esta abordagem reduz significativamente os requisitos de recursos de hardware da câmera - porque A camada para trabalhar com a nuvem é integrada de forma muito mais eficaz ao aplicativo de vídeo e não há gordura desnecessária não utilizada no firmware.

E o importante é que ao trabalhar com a câmera em baixo nível, é possível usar hardware AES, que criptografa os dados sem criar carga adicional na CPU de baixo consumo.

Naquele momento não tínhamos absolutamente nada. Nada mesmo.

Quase todos os fornecedores não estavam preparados para trabalhar conosco em um nível tão baixo. Não há informações sobre design de circuitos e componentes, não há SDK oficial de chipsets e documentação de sensores.
Também não há suporte técnico.

Todas as perguntas tiveram que ser respondidas por meio de engenharia reversa – tentativa e erro. Mas conseguimos.

Os primeiros modelos de câmeras que testamos foram Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, câmeras D-Link e várias câmeras chinesas ultrabaratas e sem nome.

Técnica

Câmeras baseadas no chipset Hisilicon 3518E. As características de hardware das câmeras são as seguintes:

Formigas Xiaomi Yi
noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

Wi-fi
mt7601/bcm43143
-

Sensor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Microfone
+
+

Palestrantes
+
+

IRLed
+
+

Corte de IR
+
+

Começamos com eles.

Atualmente oferecemos suporte aos chipsets Hisilicon 3516/3518, bem como Ambarella S2L/S2LM. Existem dezenas de modelos de câmeras.

Composição do firmware

uboot

uboot é o gerenciador de boot, ele inicializa primeiro após ligar, inicializa o hardware e carrega o kernel do Linux.

O script de carregamento da câmera é bastante 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

Uma das características é que ele é chamado duas vezes bootm, falaremos mais sobre isso um pouco mais tarde, quando chegarmos ao subsistema de atualização.

Preste atenção na linha mem=38M. Sim, sim, isso não é um erro de digitação - o kernel do Linux e todos, todos, todos os aplicativos têm acesso a apenas 38 megabytes de RAM.

Também próximo ao uboot existe um bloco especial chamado reg_info, que contém um script de baixo nível para inicializar DDR e vários registros de sistema do SoC. Contente reg_info depende do modelo da câmera, e se não estiver correto, a câmera nem conseguirá carregar o uboot, mas irá congelar logo no início do carregamento.

No início, quando trabalhávamos sem suporte do fornecedor, simplesmente copiamos esse bloco do firmware original da câmera.

Kernel Linux e rootfs

As câmeras usam o kernel Linux, que faz parte do SDK do chip; geralmente esses não são os kernels mais recentes do ramo 3.x, então muitas vezes temos que lidar com o fato de que drivers para equipamentos adicionais não são compatíveis com o kernel usado , e temos que fazer backport deles para as câmeras do kernel.

Outro problema é o tamanho do kernel. Quando o tamanho do FLASH é de apenas 8 MB, cada byte conta e nossa tarefa é desabilitar cuidadosamente todas as funções do kernel não utilizadas para reduzir o tamanho ao mínimo.

Rootfs é um sistema de arquivos básico. Inclui busybox, drivers de módulo wifi, um conjunto de bibliotecas de sistema padrão, como libld и libc, bem como nosso software, que é responsável pela lógica de controle dos LEDs, gerenciamento de conexões de rede e atualizações de firmware.

O sistema de arquivos raiz está conectado ao kernel como initramfs e como resultado da construção obtemos um arquivo uImage, que contém o kernel e o rootfs.

Aplicativo de vídeo

A parte mais complexa e que consome muitos recursos do firmware é o aplicativo, que fornece captura de vídeo-áudio, codificação de vídeo, configura parâmetros de imagem, implementa análise de vídeo, por exemplo, detectores de movimento ou som, controla PTZ e é responsável por alternar dia e modos noturnos.

Um recurso importante, eu diria até fundamental, é como o aplicativo de vídeo interage com o plugin da nuvem.

Nas soluções tradicionais 'firmware do fornecedor + plugin de nuvem', que não funcionam em hardware barato, o vídeo dentro da câmera é transmitido via protocolo RTSP - e isso é uma sobrecarga enorme: cópia e transmissão de dados via soquete, syscalls desnecessários.

Neste local usamos o mecanismo de memória compartilhada - o vídeo não é copiado ou enviado via soquete entre os componentes de software da câmera, usando assim de forma otimizada e cuidadosa os modestos recursos de hardware da câmera.

Atualizar subsistema

Um motivo de orgulho especial é o subsistema tolerante a falhas para atualizações de firmware online.

Deixe-me explicar o problema. Atualizar o firmware não é tecnicamente uma operação atômica e, se ocorrer uma falha de energia no meio da atualização, a memória flash conterá parte do novo firmware “subescrito”. Se você não tomar medidas especiais, a câmera se tornará um “tijolo” que precisa ser levado a um centro de serviço.

Nós também lidamos com esse problema. Mesmo que a câmera seja desligada durante a atualização, ela baixará automaticamente e sem intervenção do usuário o firmware da nuvem e restaurará a operação.

Vejamos a técnica com mais detalhes:

O ponto mais vulnerável é substituir a partição pelo kernel Linux e pelo sistema de arquivos raiz. Se um desses componentes estiver danificado, a câmera não inicializará além do bootloader uboot, que não pode baixar firmware da nuvem.

Isso significa que precisamos garantir que a câmera tenha um kernel e rootfs funcionando a qualquer momento durante o processo de atualização. Parece que a solução mais simples seria armazenar constantemente duas cópias do kernel com rootfs na memória flash e, se o kernel principal estiver danificado, carregá-lo a partir da cópia de backup.

Uma boa solução - no entanto, o kernel com rootfs ocupa cerca de 3.5 MB e para um backup permanente você precisa alocar 3.5 MB. As câmeras mais baratas simplesmente não têm tanto espaço livre para um kernel de backup.

Portanto, para fazer backup do kernel durante uma atualização de firmware, usamos a partição do aplicativo.
E para selecionar a partição desejada com o kernel, dois comandos são usados bootm no uboot - no início tentamos carregar o kernel principal e se estiver danificado, então o de backup.

Isso garante que a qualquer momento a câmera terá o kernel correto com rootfs e será capaz de inicializar e restaurar o firmware.

Sistema CI/CD para construção e implantação de firmware

Para construir o firmware, usamos o gitlab CI, que cria firmware automaticamente para todos os modelos de câmera suportados e, após construir o firmware, ele é automaticamente implantado no serviço de atualização de software da câmera.

A partir do serviço, as atualizações de firmware são entregues às nossas câmeras de teste de controle de qualidade e, após a conclusão de todas as etapas de teste, às câmeras dos usuários.

Segurança da informação

Não é nenhum segredo que hoje em dia a segurança da informação é o aspecto mais importante de qualquer dispositivo IoT, incluindo câmeras. Botnets como o Mirai estão circulando pela Internet, infectando milhões de câmeras com firmware padrão de fornecedores. Com todo o respeito aos fornecedores de câmeras, não posso deixar de observar que o firmware padrão contém muitas funcionalidades que não são necessárias para trabalhar com a nuvem, mas contém muitas vulnerabilidades das quais os botnets se aproveitam.

Portanto, todas as funcionalidades não utilizadas em nosso firmware são desabilitadas, todas as portas tcp/udp são fechadas e, ao atualizar o firmware, a assinatura digital do software é verificada.

Além disso, o firmware passa por testes regulares no laboratório de segurança da informação.

Conclusão

Agora nosso firmware é usado ativamente em projetos de vigilância por vídeo. Talvez o maior deles seja a transmissão da votação no dia da eleição do Presidente da Federação Russa.
O projeto envolveu mais de 70 mil câmeras com nosso firmware, que foram instaladas em assembleias de voto do nosso país.

Tendo resolvido uma série de problemas complexos e, em alguns lugares, até mesmo quase impossíveis na época, é claro que recebemos grande satisfação como engenheiros, mas, além disso, também economizamos milhões de dólares na compra de câmeras. E, neste caso, a poupança não são apenas palavras e cálculos teóricos, mas o resultado de um concurso já concluído para aquisição de equipamentos. Assim, se falamos de vigilância por vídeo na nuvem: existem duas abordagens - contar estrategicamente com conhecimento e desenvolvimento de baixo nível, resultando em enormes economias em equipamentos, ou usar equipamentos caros, que, se você olhar especificamente para as características do consumidor, praticamente não há diferente de outros baratos semelhantes.

Por que é estrategicamente importante decidir a escolha da abordagem de integração o mais cedo possível? Ao desenvolver um plugin, os desenvolvedores contam com certas tecnologias (bibliotecas, protocolos, padrões). E se um conjunto de tecnologias for escolhido apenas para equipamentos caros, então, no futuro, uma tentativa de mudar para câmeras baratas provavelmente levará, no mínimo, um tempo absurdamente longo ou até mesmo falhará e ocorrerá um retorno a equipamentos caros.

Fonte: habr.com