Hardware do projeto: como construímos uma sala com uma busca de hacker



Algumas semanas atrás, conduzimos uma busca online por hackers : construímos uma sala, a enchemos com dispositivos inteligentes e lançamos uma transmissão no YouTube a partir dela. Os jogadores podem controlar os dispositivos IoT do site do jogo; o objetivo era encontrar uma arma escondida na sala (um poderoso apontador laser), hackea-la e causar um curto-circuito na sala.



Para adicionar um enredo emocionante, colocamos um triturador na sala, no qual carregamos 200.000 rublos: o triturador comia uma nota por hora. Depois de vencer o jogo, foi possível parar o triturador e tirar todo o dinheiro restante.



Já descrevemos a passagem do jogo , bem como a forma como o backend do projeto foi feito . É hora de falar sobre o hardware e como estava indo.





Houve muitos pedidos para mostrar o momento da limpeza da sala - mostramos como a desmontamos



Arquitetura de ferro: controle da sala



Começamos a projetar a solução de hardware quando o cenário já estava aproximadamente claro, o back-end estava pronto e tínhamos uma sala vazia pronta para instalação do equipamento.



Recordando a velha piada "O S na IoT significa Segurança" ("A letra S na abreviatura IoT significa Segurança"), decidimos que desta vez os jogadores no cenário do jogo interagem apenas com o front-end e o back-end do site, mas não têm a oportunidade de obter diretamente para a glândula.



Isso foi feito por motivos de segurança e entretenimento do que está acontecendo na tela: com o acesso direto dos jogadores ao hardware, seria muito mais difícil isolar ações seguras e potencialmente perigosas, por exemplo, acelerar o triturador ou controlar pirotecnia.



Antes de iniciar o design, formulamos vários princípios para controlar dispositivos de jogos, que se tornaram a base do design:



Não use soluções sem fio



Todo o espaço de jogo está em um quadro, cada canto que você pode alcançar. Não havia necessidade real de conexões sem fio e elas se tornariam apenas mais um ponto de falha.



Não use nenhum dispositivo especial da casa inteligente



Principalmente por uma questão de flexibilidade de personalização. É claro que é possível personalizar muitas versões em caixa de sistemas domésticos inteligentes com um painel de administração e gerenciamento prontos para a nossa tarefa, mas os custos de mão de obra seriam comparáveis ​​à criação de sua própria solução simples.



Além disso, era necessário criar dispositivos que mostrassem claramente o que exatamente os jogadores mudam de estado: ligado / desligado ou colocar uma luz específica nas letras FALCON.



Coletamos todos os elementos do ferro disponível ao público, que pode ser comprado em lojas de peças de rádio comuns: entre a entrega de pizza e cola diet, os mensageiros Chip e Deep e Leroy vinham constantemente ao site.



A escolha de montar tudo por nós mesmos simplificou a depuração e a escalabilidade, porém, exigiu mais precisão durante a instalação.



Todos os relés e arudino não devem ser visíveis no quadro



Decidimos colocar todos os elementos controláveis ​​em um lugar e ocultá-los nos bastidores para poder controlar a performance e, se necessário, rastejar cuidadosamente para fora do campo de visão da câmera e substituir a unidade com falha.





Como resultado, tudo foi escondido sob a mesa, e a câmera foi instalada de forma que nada pudesse ser visto abaixo da mesa. Este foi o nosso "



ponto cego" para o engatinhamento do engenheiro. Do ponto de vista do hardware, este dispositivo controlava 6 elementos:



  1. Vários abajures de mesa, eles têm um estado ligado / desligado e são controlados pelos jogadores
  2. Letras na parede, podem mudar de cor ao comando dos jogadores
  3. Fãs que giram e abrem o flipchart quando o servidor está sob carga
  4. Laser controlado por PWM
  5. O triturador que comia dinheiro de acordo com uma programação
  6. Uma máquina de fumaça que disparava antes de cada disparo de laser




Testamos a máquina de fumaça junto com o laser.



Posteriormente, foi adicionada uma luz de palco, que ficava atrás da moldura e era controlada exatamente como as lâmpadas do ponto 1. A luz de palco foi acionada em dois casos: iluminou o laser quando a energia foi aplicada a ele e iluminou o peso antes do laser ser lançado em combate modo.



O que era esse dispositivo inteligente?







Na verdade, acabamos com um dispositivo inteligente: ele recebeu o estado de cada uma de suas partes do back-end e o alterou com o comando apropriado.



Foi assumido que um script simples estará rodando no computador que recebe json com o estado dos dispositivos e o envia para o arduinka conectado via usb. Posteriormente, este computador foi substituído pelo rasberry, ele foi conectado ao back-end por causa do nat.



Conectado às portas:



  • 16 relés convencionais (foram eles que fizeram o som de clique que foi ouvido no vídeo. Nós os escolhemos principalmente por causa desse som)
  • 4 relés de estado sólido para controlar canais PWM, como ventiladores,
  • saída PWM separada para laser
  • saída formando um sinal para a faixa de LED


Aqui está um exemplo de um comando json que veio para a retransmissão do servidor



{"power":false,"speed":0,"period":null,"deviceIdentifier":"FAN"}


E este é um exemplo da função com que a equipe chegou a Arudino




def callback(ch, method, properties, body):    
    request = json.loads(body.decode("utf-8"))    
    print(request, end="\n")     
    send_to_serial(body)


Para rastrear o momento em que o laser finalmente queima a corda e o peso vai voar para o aquário, fizemos um pequeno botão que acionava a queda do peso e dava um sinal para o sistema.





Monitoramento de botão do movimento do kettlebell



Neste sinal, bombas de fumaça feitas de bolas de pingue-pongue deveriam ter acendido. Colocamos 4 dutos de fumaça diretamente na caixa do servidor e trouxemos um fio de nicromo para eles, que deveria aquecer e funcionar como um fusível.





Corpo com bombas de fumaça e guirlanda chinesa







Arduino



No arduinka, de acordo com o plano original, ocorreram duas ações.



Primeiro, quando uma nova solicitação foi recebida, a solicitação foi analisada usando a biblioteca ArduinoJson. Além disso, várias de suas propriedades foram associadas a cada dispositivo controlado:



  • «» «» ( )
  • , ( JSON , , )
  • PWM ,
  • , . 587 . , , , . .


A última vez foi definida quando o parâmetro correspondente foi recebido em JSON, mas não poderia ter sido transmitido, então o valor foi definido como 0 e não ocorreu a zeragem.



A segunda ação que o arduinka executava a cada ciclo era a atualização dos estados, ou seja, verificar se era necessário ligar algo ou se era hora de desligar um aparelho.



Ponteiro laser - o mesmo Megatron 3000







Este é um módulo laser convencional para corte e marcação LSMVR450-3000MF 3000mW 450nm foco manual.



Letras de falcão



Muito simples - apenas copiamos as letras do logotipo, recortamos em papelão e colamos com fita adesiva. Nesse caso, foi necessário soldar pedaços de fita, 4 contatos em cada costura, mas o resultado valeu a pena. Nosso backend Pasha mostrou milagres de habilidade, fazendo isso em menos de algumas horas.





Primeiros testes do dispositivo iot e acabamento



Fizemos os primeiros testes e ao mesmo tempo tivemos novos problemas. O fato é que, no meio do processo, um verdadeiro produtor de cinema e cinegrafista da VGIK, Ilya Serov, se juntou à equipe - ele construiu o quadro, acrescentou iluminação cinematográfica adicional e mudou ligeiramente o cenário do jogo para que o enredo fosse mais emocional e a imagem fosse mais dramática e teatral.



Isso aumentou significativamente a qualidade, mas havia elementos que também precisavam ser conectados ao relé e o algoritmo de operação foi prescrito.



O laser acabou sendo outro problema: fizemos vários experimentos com diferentes tipos de cordas e lasers de diferentes potências. Para o teste, simplesmente penduramos a carga verticalmente em uma corda.



Quando lançado com um token de teste, a potência ajustável por meio do PWM foi inferior a 10% e a corda não danificou mesmo após exposição prolongada.



Para o modo de combate, o laser foi desfocado para aproximadamente um ponto com um diâmetro de 10 mm e queimou com segurança através da corda com uma carga a uma distância de cerca de um metro.





Então o laser funcionou perfeitamente nos testes.Quando



já começamos a testar tudo bem na sala com um peso suspenso, descobrimos que não era tão fácil consertar o laser com segurança. Então, quando a corda está pegando fogo, ela derrete, se estica e sai do foco original.





Mas é assim que não funcionava mais: a corda foi deslocada



Ilya moveu o laser para o fim da sala oposto à corda para que o feixe de laser atravessasse toda a cena e ficasse lindo no quadro, que dobrava a distância.



Depois de realizar mais alguns experimentos com queima de corda já na batalha, decidimos não torturar o destino e garantir o corte da corda com a ajuda de um fio de nicrômio. Ela destruiu o fio 120 segundos após ligar o laser no modo de combate. Isso, assim como a desconexão do fio e o fusível das bombas de fumaça quando o contato separável é acionado, decidimos hard-code direto no hardware do microcontrolador.





O fio, que acabou queimando a corda fora



da tela.Assim, apareceu uma terceira tarefa que o arduinka resolveu - trabalhar as sequências associadas à execução desses comandos.



Decidimos também dar framboesa, que costumava enviar simplesmente JSON ad-hoc recebido do back-end, e a necessidade de controlar o dinheiro na TV e executar o triturador. Inicialmente, supôs-se que o back-end faria isso e o saldo atual seria visível no site e, na TV, mostraríamos os comentários do YouTube como um elemento interativo adicional que informa aos espectadores que os eventos na sala estão acontecendo em tempo real.



Mas durante o teste, Ilya observou a cena e sugeriu mostrar o saldo do jogo na tela maior: quanto dinheiro sobrou, quanto foi comido e a contagem regressiva até a próxima partida do triturador.



Vinculamos o Raspberry ao horário atual: a cada hora inteira, o triturador era ligado. A imagem foi exibida na TV com o auxílio do framboesa, que naquele momento já recebia pedidos do servidor e os enviava para execução ao arduinka. Imagens com indicadores monetários foram desenhadas usando uma chamada para o utilitário do console fim como este



image = subprocess.Popen(["fim", "-q", "-r", "1920×1080", fim_str]),  fim_str



E foi formado com base na quantidade ou tempo necessário.



Geramos as fotos com antecedência: apenas fizemos o vídeo finalizado com um cronômetro e exportamos 200 fotos.



Este é o mecanismo que foi programado na missão. No momento em que a contagem regressiva final começou, todos nós dirigimos para o local, armados com extintores de incêndio e sentamos para esperar o fogo (que queimava com força e principal apenas em discórdia)



Como fazer uma transmissão que funciona por uma semana: escolhendo uma câmera



Para a missão, precisávamos de uma transmissão contínua no YouTube por 7 dias - isso é quanto colocamos como a duração máxima do jogo. Havia duas coisas que poderiam nos impedir:



  1. Superaquecimento da câmara de operação contínua
  2. Corte de internet


A câmera precisava fornecer pelo menos uma imagem Full HD para reproduzir e observar a sala confortavelmente.



Inicialmente, olhamos na direção das webcams que são liberadas para streamers. Cortamos o orçamento, então não queríamos comprar uma câmera, mas, como descobrimos, elas não estão disponíveis para aluguel. No mesmo momento, milagrosamente encontramos a câmera do Xbox Kinect em minha casa, colocamos no quarto e iniciamos um teste de transmissão por uma semana.



A câmera funcionou bem e não superaqueceu, mas Ilya quase imediatamente percebeu que faltava configurações, em particular, era impossível definir a exposição.



Ilya procurou aproximar o tipo de transmissão dos padrões de produção de filme e vídeo: transmitir uma cena de luz que muda dinamicamente com fontes de luz brilhantes, um fundo escurecido e objetos no enquadramento. Ao mesmo tempo, queria preservar a elaboração da imagem tanto nos realces quanto nas sombras, com o mínimo de ruído digital.



Portanto, embora o kinect tenha se mostrado confiável nos testes e não necessite de placa de captura de vídeo (outro ponto de falha), decidimos abandoná-lo. Depois de três dias testando câmeras diferentes, Ilya escolheu a Sony FDR-AX53 - uma camcorder pequena e confiável, acessível para aluguel, mas ao mesmo tempo com confiabilidade e características visuais suficientes.



Alugamos uma câmera, ligamos por uma semana em conjunto com uma placa de captura de vídeo, e percebemos que com ela podemos contar com uma transmissão contínua ao longo de toda a jornada.



:



Trabalhar a iluminação exigia uma certa graça, precisávamos construir uma partitura de luz com meios mínimos:



1. Iluminação dos objetos quando encontrados pelos jogadores (laser, peso), bem como luz constante no triturador. Aqui, eles usaram o dedolight 150 - dispositivos de iluminação de cinema compactos e confiáveis ​​com lâmpadas halógenas de baixa voltagem, que permitem focar o feixe em um assunto específico, sem tocar no fundo e em outros objetos.



2. Luz de jogo prática - abajur, abajur, estrela, guirlanda. Toda a luz prática foi harmoniosamente distribuída no quadro para iluminar sua área da imagem, dentro havia lâmpadas led com uma temperatura de cor de 3200K, a luminária da luminária de chão foi coberta com um filtro de fólio Rosco vermelho para criar um acento de dica de cor incomum.





Eu sou um engenheiro com minha mãe ou lançamento amanhã



Como fizemos backup da Internet e da eletricidade



A questão da tolerância a falhas foi abordada quase como em um data center: eles decidiram não se desviar dos princípios básicos e reservados de acordo com o esquema N + 1 usual.



Se a transmissão no YouTube parar, significa que será impossível se reconectar usando o mesmo link e continuar a transmissão. Foi um momento crítico e a sala estava em um escritório normal.



Para isso, usamos um roteador baseado em OpenWRT e o pacote mwan3. Ele testava automaticamente a disponibilidade do canal a cada 5 segundos e, em caso de interrupção, trocava para o modem de backup da Yota. Como resultado, a mudança para o canal de backup demorou menos de um minuto.



Também era igualmente importante excluir quedas de energia, porque mesmo uma oscilação de energia de curto prazo causaria a reinicialização de todos os computadores.



Por isso, pegamos a fonte de alimentação ininterrupta ippon innova g2 3000, que teria feito backup de todos os dispositivos de jogos: o consumo total de energia do nosso sistema era de cerca de 300 watts. Seria o suficiente para 75 minutos, o suficiente para nossos propósitos.



Decidimos sacrificar a iluminação adicional no caso de faltar eletricidade na sala - ela não estava conectada a uma fonte de alimentação ininterrupta.



Agradecimentos



  • A toda a equipe RUVDS , que inventou e implementou o jogo.
  • Separadamente para os administradores do RUVDS, para monitorar o trabalho dos servidores, a carga foi aceitável e tudo funcionou normalmente no modo normal.
  • Para o melhor chefe ntsaplinpelo fato de que em resposta ao chamado "há uma ideia: vamos pegar um servidor, colocar um aquário nele, e pendurar um peso sobre ele, bum, bum, está tudo inundado de água, curto-circuito, fogo!" ele sempre diz com confiança "faça!"
  • Tilda Publishing , - , .
  • S_ILya , , , , , .
  • zhovner , , , , .
  • samat , , .
  • daniemilk .
  • delfphe .
  • Dodo Pizza Engineering .


E o maior agradecimento é aos jogadores por todas as emoções que vivemos enquanto você invadiu a jornada sem dormir por dois dias e até adiou o trabalho.



Outros artigos sobre a missão com a destruição do servidor








All Articles