Como o back-end de um jogo de hacker sobre a destruição de um servidor foi criado



Continuamos contando como nossa busca do laser com a destruição do servidor foi organizada. Começando no artigo anterior sobre como resolver a missão .



No total, o back-end do jogo tinha 6 unidades arquitetônicas, que analisaremos neste artigo:



  1. Back-end das entidades do jogo responsáveis ​​pelos mecanismos do jogo
  2. Back-end e barramento de troca de dados do site em VPS
  3. Tradutor de solicitações de back-end (elementos do jogo) para arduino e hardware no site
  4. O Arduino, que era responsável pelo controle do relé, recebia comandos do tradutor e fazia o trabalho real
  5. Dispositivos reais: ventilador, margaridas, lâmpadas de assoalho, etc.
  6. Frontend - o próprio site do Falcon, a partir do qual os jogadores controlavam dispositivos


Vamos examinar cada um deles.



Back-end das entidades do jogo



O back-end foi implementado como um aplicativo de boot de primavera: tinha vários controladores rest, um endpoint de websocket e serviços com lógica de jogo.



Havia apenas três controladores:



  • Megatron. Por meio de solicitações GET, foi enviada a página atual do Megatron: antes e depois da inicialização. O laser disparou por meio de uma solicitação POST.
  • , . , ID .
  • , - .


O endpoint da Websocket foi usado para controlar dispositivos: lâmpadas, guirlandas e letras. Foi escolhido para mostrar de forma síncrona o estado atual do dispositivo para todos os jogadores: se está ligado ou desligado, ativo ou não, qual a cor da letra que está agora na parede. Para complicar um pouco a tarefa de ligar o laser, colocamos a autorização na guirlanda e no laser com o mesmo login e senha de administrador / administrador.



Os jogadores podem testá-lo ligando a guirlanda e fazendo o mesmo com o laser.



Escolhemos um par de senha de login tão trivial para não atormentar os jogadores com uma seleção desnecessária.



Para tornar a tarefa um pouco mais interessante, o ID do objeto de mongodb foi usado como identificadores de dispositivo na sala.



ObjectId contém um carimbo de data / hora: dois valores aleatórios, um dos quais é obtido com base no identificador do dispositivo e o segundo com base no processo pid que o gera e no valor do contador. Queria fazer os identificadores gerados em intervalos regulares e a partir de diferentes processos pid, mas com um contador comum, para que a seleção do identificador do dispositivo a laser fosse mais interessante. No entanto, no final, todos começaram com identificadores que diferem apenas no valor do contador. Talvez isso tenha tornado o estágio muito simples e não exigisse a análise da estrutura dos identificadores objectId.



Tradutor de solicitações de back-end



Script Python que lida com cronômetros e traduzido de abstrações de jogo em um modelo físico. Por exemplo, "acenda a luminária de chão" → "acenda o relé N2".



O script se conectou à fila RabbitMQ e passou solicitações da fila para o Arduino. Implementou também a lógica de acendimento paralelo da luz: junto com alguns dispositivos, a luz foi ligada neles, por exemplo, quando o Megatron foi inicialmente ligado, ele foi iluminado com luz de palco. O design de iluminação para uma cena cinematográfica inteira é uma história separada sobre o excelente trabalho de nosso coprodutor e designer de produção Ilya Serov, e contaremos sobre isso em um post separado.



O tradutor também ficou responsável pela lógica de ligar o triturador por cronômetro e transmitir a imagem para a TV: o cronômetro de acionamento do triturador, a capivara gritando, o anúncio do final do jogo.



Como a lógica de geração do token megatron foi organizada



Tiro de teste



A cada 25 segundos, um novo token era gerado, ele poderia ser usado para ligar o laser por 10 segundos na potência 10/255. Link para o github com o código Megatron .



Em seguida, o laser foi resfriado por 1 minuto - durante esse tempo, ele ficou indisponível e não aceitou novos pedidos de injeção.



Este poder não foi suficiente para queimar a corda, mas qualquer jogador poderia atirar do Megatron e ver o feixe de laser em ação.



O algoritmo de hashing MD5 foi usado para gerar o token. E o esquema era MD5 do MD5 + contador + segredo para o token de combate e sem segredo para o de teste.



MD5 é uma referência a um projeto comercial feito por Pavel, nosso backender. Há apenas alguns anos, esse projeto usava MD5 e, quando ele disse ao arquiteto do projeto que era um algoritmo de criptografia legado, eles começaram a usar MD5 a partir de MD5. Já que decidimos fazer o máximo do projeto Noob, ele se lembrou de tudo e resolveu fazer uma pequena referência.



Tiro de combate



O modo de combate do Megatron é 100% laser de 3W. Isso é suficiente para 2 minutos para queimar a corda que segurava o kettlebell para quebrar o aquário e encher o servidor com água.



Deixamos algumas dicas no github do projeto: a saber, o código de geração de tokens, pelo qual foi possível entender que tokens de teste e combate são gerados a partir de um contador-indicador. No caso da ficha de combate, além do valor do contador, também é utilizado o sal, que ficou quase que totalmente deixado na história de mudanças nesta essência, com exceção dos dois últimos caracteres.



Conhecendo esses dados, foi possível iterar os últimos 2 símbolos de sal e de fato descobrir que números de Lost foram usados ​​para eles, traduzidos no sistema de 16 dígitos.



Em seguida, os jogadores tinham que pegar o valor do contador (analisando o token de teste) e gerar um token de combate usando o próximo valor do contador e o sal selecionado na última etapa.



O contador foi simplesmente incrementado a cada disparo de teste e a cada 25 segundos. Não escrevemos sobre isso em lugar nenhum, deveria ter sido uma pequena surpresa de jogo.



Serviço para interação com captcha



No mundo do jogo, esse era o mesmo captcha que precisava ser carregado para ligar o ventilador e abrir um flipchart com uma dica. Havia um laptop com monitoramento de carga ao lado da câmera.







O serviço calculou o que exibir no monitoramento como a carga atual: temperatura e ventilador da CPU. As métricas foram passadas para o banco de dados de base de tempo e renderizadas em grafana.



Se nos últimos 5 segundos, mais de 50 solicitações de exibição de captcha foram recebidas, a carga aumentou por correção + um número aleatório de etapas. O cálculo foi que 100% da carga pudesse ser obtida em dois minutos.



Na verdade, havia mais lógica no serviço do que era exibido no jogo final: configuramos o monitor de forma que apenas a rotação do Ventilador da CPU fosse visível.



No início da missão, eles queriam deixar Grafana acessível no site da Sokol. Mas ele também continha métricas do springboot para o relatório do aplicativo de back-end, que não tivemos tempo de limpar, então decidimos fechar o acesso a ele. E com razão - no início da missão, alguns jogadores adivinharam que o aplicativo foi escrito no framework springboot e até desenterraram o nome de alguns serviços.



Hospedagem e barramento de dados



Uma ferramenta para transferir informações do backend para o site, o servidor VPS no qual o RabbitMQ foi lançado.



O backend e o barramento de dados foram mantidos em nosso VPS . Seu poder era comparável ao do computador que você via na tela: um VPS de 2 núcleos com 2 gigabytes de RAM. A tarifa foi tomada para recursos, pois o pico de carga foi planejado para apenas alguns dias - é o que fazem nossos clientes, que pretendem carregar VPS por um curto período de tempo. Então descobrimos que a carga era maior do que esperávamos e uma tarifa fixa seria mais lucrativa. Ao fazer uma missão, escolha as tarifas da linha turbo .



Para proteger o servidor de DDoSa, usamos Cloudflare.



Deve ser dito que o VPS resistiu a tudo com louvor.



O Arduino, que era responsável pelo controle do relé, recebia comandos do tradutor e fazia o trabalho real



Este é mais um tópico para o próximo artigo sobre a parte de hardware do projeto: o back-end simplesmente enviou solicitações para habilitar um relé específico. Acontece que o back-end conhecia quase todas as entidades e as solicitações dele pareciam "habilitar esta entidade". Fizemos isso para os primeiros testes do site (ainda não coletamos todo o Arduino e relés), no final deixamos tudo assim.



A parte dianteira



Rapidamente criamos o site no til, demorou um dia útil e nos economizou 30 mil do orçamento.



Inicialmente, pensamos em apenas exportar o site e inserir a lógica que faltava, mas encontramos termos de uso que nos proibiam de fazer isso.



Não estávamos preparados para violar a licença, então havia duas opções: fazer tudo nós mesmos ou entrar em contato diretamente com a Tilda, contar sobre o projeto e pedir permissão para alterar o código.



Escolhemos a segunda opção e eles não apenas nos atenderam no meio do caminho, mas até nos deram um ano de conta empresarial gratuita, pelo qual somos muito gratos. Foi muito constrangedor mostrar a eles o design do site do Sokol.



Como resultado, anexamos js-logic ao frontend para enviar solicitações a dispositivos elementares, mudamos ligeiramente os estilos dos botões para ligar e desligar os elementos do jogo.



Design do site



Histórico de pesquisa, que vale um capítulo separado.



Queríamos criar não apenas um site antiquado, mas um site absolutamente nauseante que violasse todas as regras básicas de design. Ao mesmo tempo, era importante preservar a credibilidade: ele tinha que não quebrar as histórias do ENT, demonstrar a pretensão do autor, e os jogadores teriam que acreditar que tal site poderia existir e até trazer clientes. E ele trouxe! Enquanto o jogo estava rodando, fomos duas vezes solicitados a criar sites.



No início, eu mesmo fiz o design, tentando inserir mais GIFs e elementos brilhantes. Mas meu marido, um designer com 10 anos de experiência, olhou por cima do ombro e o considerou "bom demais". Para quebrar as regras de design, você precisa conhecê-las.







São várias combinações de cores que causam uma sensação persistente de nojo: verde e vermelho de igual suculência, cinza e rosa, azul mais marrom. Como resultado, optamos por uma combinação de vermelho e verde como cores básicas, adicionamos gifs com um gato e escolhemos 3-4 fotos do próprio Sokolov no estoque de fotos. Eu tinha apenas alguns requisitos: um homem de meia-idade, em um terno mal ajustado um pouco maior e na pose de "sessão de fotos profissional no estúdio". Para o teste, eles mostraram aos amigos e perguntaram: "Você gostou?"



No processo de desenvolvimento do projeto, meu marido teve que se deitar a cada meia hora e começou a pilotar um helicóptero. Pasha tentou abrir o console do desenvolvedor para a maior parte da tela, enquanto ele estava terminando o front-end - ele cuidou de seus olhos.



Dispositivos reais



Ventiladores e luzes foram montados por meio de relés de estado sólido para que não ligassem com potência total imediatamente - para que o aumento de potência ocorresse em paralelo com o monitoramento.



Mas falaremos sobre isso no próximo post, sobre a parte de hardware do jogo e a própria construção do site.



Fique ligado!



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








All Articles