Comment le backend d'un jeu de hacker sur la destruction d'un serveur a été créé

Comment le backend d'un jeu de hacker sur la destruction d'un serveur a été créé
Nous continuons à vous raconter comment s'est déroulée notre quête laser avec destruction du serveur. Commencer dans le précédent article sur la résolution de la quête.

Au total, le backend du jeu comportait 6 unités architecturales, que nous analyserons dans cet article :

  1. Backend des entités de jeu responsables des mécanismes de jeu
  2. Bus d'échange de données backend et site sur VPS
  3. Traducteur des requêtes backend (éléments de jeu) vers Arduino et matériel sur place
  4. Arduino, qui était responsable du contrôle des relais, recevait les commandes du traducteur et effectuait le travail proprement dit.
  5. Appareils réels : ventilateur, guirlandes, lampadaires, etc.
  6. Frontend - le site Web Falcon lui-même, à partir duquel les joueurs contrôlaient les appareils

Passons en revue chacun d'eux.

Backend des entités de jeu

Le backend a été implémenté en tant qu'application Spring Boot : il disposait de plusieurs contrôleurs de repos, d'un point de terminaison Websocket et de services avec une logique de jeu.

Il n'y avait que trois contrôleurs :

  • Mégatron. La page Megatron actuelle a été envoyée via des requêtes GET : avant et après la mise sous tension. Le laser s'est déclenché via la requête POST.
  • Mappage des pages tilde afin qu'elles soient servies par nom de page. Tilde produit des pages à exporter non pas avec les noms d'origine, mais avec des informations d'identification et de conformité internes.
  • Contrôleur Captcha pour servir le captcha de serveur pseudo-haute charge.

Le point de terminaison Websocket était utilisé pour contrôler les gadgets : lampes, guirlandes et lettres. Il a été choisi d'afficher de manière synchrone à tous les joueurs l'état actuel de l'appareil : s'il est allumé ou éteint, actif ou non, quelle couleur de la lettre est actuellement allumée sur le mur. Afin de rendre un peu plus difficile la tâche d'allumage du laser, nous avons ajouté une autorisation à la guirlande et au laser avec le même login et mot de passe admin/admin.

Les joueurs pouvaient le tester en allumant la guirlande et répéter la même chose avec le laser.

Nous avons choisi une paire login-mot de passe aussi triviale afin de ne pas tourmenter les joueurs avec une sélection inutile.

Pour rendre la tâche un peu plus intéressante, les identifiants d'objet de mongodb ont été utilisés comme identifiants de périphérique dans la pièce.

ObjectId contient un horodatage : deux valeurs aléatoires, dont l'une est prise en fonction de l'identifiant de l'appareil et la seconde en fonction du pid du processus qui le génère et de la valeur du compteur. Je voulais que les identifiants soient générés à intervalles réguliers et avec des processus pid différents, mais avec un compteur commun, afin que la sélection d'un identifiant d'appareil laser soit plus intéressante. Cependant, au final, tout le monde a commencé avec des identifiants qui ne différaient que par la valeur du compteur. Cela a peut-être rendu l'étape trop simple et ne nécessitant pas d'analyse de la structure objectId.

Traducteur à partir des requêtes backend

Script Python, qui a travaillé sur des minuteries et les a traduites d'abstractions de jeu en un modèle physique. Par exemple, « allumer le lampadaire » → « allumer le relais N2 ».

Le script s'est connecté à la file d'attente RabbitMQ et a transféré les requêtes de la file d'attente vers Arduino. Il a également mis en œuvre la logique de commutation de lumière parallèle : avec certains appareils, la lumière sur eux était allumée, par exemple, lors de la première alimentation du Megatron, il était éclairé par la lumière de la scène. La conception de l'éclairage pour la cinématographie de l'ensemble de la scène est une histoire à part sur l'excellent travail de notre coproducteur et concepteur de production Ilya Serov, et nous en parlerons dans un article séparé.

Le traducteur était également responsable de la logique de lancement du broyeur à l'aide d'un minuteur et de transmission de l'image au téléviseur : le minuteur de lancement du broyeur, un capybara hurlant, une publicité à la fin du jeu.

Comment la logique de génération du jeton Megatron a été structurée

Tir d'essai

Toutes les 25 secondes, un nouveau jeton était généré et pouvait être utilisé pour allumer le laser pendant 10 secondes à une puissance de 10/255. Lié à github avec le code Megatron.

Le laser s'est ensuite refroidi pendant 1 minute. Pendant ce temps, il était indisponible et n'acceptait pas de nouvelles demandes de tir.

Cette puissance n'était pas suffisante pour brûler la corde, mais n'importe quel joueur pouvait tirer Megatron et voir le faisceau laser en action.

L'algorithme de hachage MD5 a été utilisé pour générer le jeton. Et le plan a fonctionné MD5 de MD5 + compteur + secret pour un jeton de combat et sans secret pour un jeton de test.

MD5 est une référence à un projet commercial réalisé par Pavel, notre backender. Il y a quelques années à peine, ce projet utilisait MD5, et lorsqu'il a dit à l'architecte du projet qu'il s'agissait d'un algorithme de cryptage obsolète, ils ont commencé à utiliser MD5 à partir de MD5. Depuis que nous avons décidé de réaliser le projet le plus noob possible, il s'est souvenu de tout et a décidé de faire une petite référence.

Tir de combat

Le mode de combat de Megatron est une puissance laser à 100 % à 3 watts. Cela suffit pendant 2 minutes pour brûler la corde qui retenait le poids, pour briser l'aquarium et inonder le serveur d'eau.

Nous avons laissé plusieurs indices sur le Github du projet : à savoir le code de génération de token, à partir duquel on pourrait comprendre que les tokens de test et de combat sont générés sur la base du même indicateur de compteur. Dans le cas d'un jeton de combat, en plus de la valeur du compteur, un sel est également utilisé, qui est presque entièrement laissé dans l'historique des modifications de cet élément essentiel, à l'exception des deux derniers caractères.

Connaissant ces données, il a été possible de trier les 2 derniers symboles du sel et de découvrir effectivement que les nombres de Lost, convertis au système hexadécimal, ont été utilisés pour cela.

Ensuite, les joueurs devaient saisir la valeur du compteur (en analysant le jeton de test) et générer un jeton de combat en utilisant la valeur du compteur suivante et le sel sélectionné à l'étape précédente.

Le compteur s'incrémente simplement à chaque tir test et toutes les 25 secondes. Nous n’en avons parlé nulle part, c’était censé être une petite surprise de jeu.

Service d'interaction Captcha

Dans le monde du jeu vidéo, c'était le même captcha qu'il fallait charger pour allumer le ventilateur et ouvrir le paperboard avec un indice. À côté de la caméra se trouvait un ordinateur portable avec surveillance de la charge.

Comment le backend d'un jeu de hacker sur la destruction d'un serveur a été créé

Service J'ai calculé ce qu'il fallait afficher dans la surveillance comme charge actuelle : la température et le ventilateur du processeur. Les métriques ont été transférées vers la base de données de base de temps et dessinées par grafana.

Si au cours des 5 dernières secondes il y a eu plus de 50 demandes d'affichage du captcha, alors la charge a augmenté d'un nombre fixe + aléatoire d'étapes. Le calcul était qu'une charge à 100 % pouvait être atteinte en deux minutes.

En fait, il y avait plus de logique dans le service que ce qui était affiché dans le jeu final : nous avons placé le moniteur de manière à ce que seule la rotation du ventilateur du processeur soit visible.

Au début de la quête, ils voulaient laisser Grafan accessible depuis le site Falcon. Mais il contenait également des métriques Springboot provenant du rapport de l'application backend, que nous n'avons pas eu le temps d'effacer, nous avons donc décidé d'en bloquer l'accès. Et à juste titre - même au début de la quête, certains joueurs ont deviné que l'application était écrite dans le framework Springboot et ont même déterré les noms de certains services.

Hébergement et bus de données

Un outil pour transférer des informations du backend vers le site, le serveur VPS sur lequel RabbitMQ fonctionnait.

Le backend et le bus de données sont restés allumés notre VPS. Sa puissance était comparable à l’ordinateur que vous voyiez à l’écran : un VPS à 2 cœurs avec deux gigaoctets de RAM. Le tarif était facturé pour les ressources, puisque la charge de pointe n'était prévue que pour quelques jours - c'est ce que font nos clients qui envisagent de charger des VPS pendant une courte période. Ensuite, il s'est avéré que la charge était plus élevée que prévu et qu'un tarif fixe serait plus rentable. Si vous faites une quête, choisissez les tarifs de ligne turbo.

Pour protéger le serveur contre DDoSa, nous avons utilisé Cloudflare.

Il faut dire que le VPS a résisté à tout avec honneur.

Arduino, qui était responsable du contrôle des relais, recevait les commandes du traducteur et effectuait le travail proprement dit.

C'est davantage le sujet du prochain article sur la partie matérielle du projet : le backend envoyait simplement des requêtes pour activer un relais spécifique. Il se trouve que le backend connaissait presque toutes les entités et que ses demandes ressemblaient à « allumer cette entité ». Nous avons fait cela pour les premiers tests du site (nous n'avions pas encore assemblé tous les Arduino et relais), au final nous avons tout laissé ainsi.

L'extrémité avant

Nous avons rapidement créé le site sur tilde, cela a pris un jour ouvrable et nous a permis d'économiser 30 mille sur notre budget.

Au départ, nous pensions simplement exporter le site et ajouter la logique qui nous manquait, mais nous nous sommes heurtés à des conditions d'utilisation qui nous interdisaient de le faire.

Nous n'étions pas prêts à violer la licence, nous avions donc deux options : tout mettre en œuvre nous-mêmes ou contacter directement Tilda, parler du projet et demander la permission de modifier le code.

Nous avons choisi la deuxième option et ils nous ont non seulement rencontré à mi-chemin, mais nous ont même offert un an de compte professionnel gratuit, ce dont nous leur sommes très reconnaissants. C'était très gênant de leur montrer le design du site Web de Sokol.

En conséquence, nous avons attaché la logique js au frontend pour envoyer des requêtes aux appareils élémentaires et avons légèrement modifié les styles des boutons pour activer et désactiver les éléments de jeu.

Дизайн сайта

L'historique des recherches, qui mérite un chapitre à part.

Nous voulions créer non seulement un site démodé, mais un site absolument dégoûtant qui viole toutes les règles de base du design. En même temps, il était important de maintenir la crédibilité : il ne fallait pas casser l'histoire d'ENT, démontrer la prétention de l'auteur, et les joueurs devaient croire qu'un tel site pouvait exister et même attirer des clients. Et il l'a apporté ! Pendant que le jeu se déroulait, nous avons été contactés à deux reprises pour créer des sites internet.

Au début, j'ai fait le design moi-même, en essayant d'inclure plus de gifs et d'éléments brillants. Mais mon mari designer depuis 10 ans a regardé par-dessus son épaule et l'a jugé « trop beau ». Pour enfreindre les règles de conception, vous devez les connaître.

Comment le backend d'un jeu de hacker sur la destruction d'un serveur a été créé

Il existe plusieurs combinaisons de couleurs qui évoquent un sentiment de dégoût durable : vert et rouge d'égale richesse, gris et rose, bleu plus marron. En fin de compte, nous avons opté pour une combinaison de rouge et de vert comme couleurs de base, ajouté des gifs avec un chat et sélectionné 3 à 4 photos de Sokolov lui-même à partir d'une photo d'archives. Je n'avais que quelques exigences : un homme d'âge moyen, portant un costume mal ajusté quelques tailles trop grandes et dans une pose de « séance photo en studio professionnel ». Pour le test, ils l'ont montré à des amis et leur ont demandé « comment l'aimez-vous ? »

Pendant le processus de développement de la conception, mon mari devait s'allonger toutes les demi-heures et l'hélicoptère a commencé à voler. Pasha a essayé d'ouvrir la console du développeur sur la majeure partie de l'écran pendant qu'il finissait de terminer l'interface - pour protéger ses yeux.

Appareils réels

Les ventilateurs et les lumières ont été montés via des relais à semi-conducteurs afin qu'ils ne s'allument pas immédiatement à pleine puissance - afin que la puissance augmente parallèlement à la surveillance.

Mais nous en reparlerons dans le prochain post, à propos de la partie matérielle du jeu et de la construction proprement dite du site.

Bientôt disponible!

Autres articles sur la quête pour détruire le serveur

Comment le backend d'un jeu de hacker sur la destruction d'un serveur a été créé

Source: habr.com

Ajouter un commentaire