Seguimos contándote cómo se organizó nuestra búsqueda láser con la destrucción del servidor. Empezar en anterior .
En total, el backend del juego contaba con 6 unidades arquitectónicas, las cuales analizaremos en este artículo:
- Backend de las entidades del juego que eran responsables de los mecanismos del juego.
- Bus de intercambio de datos de backend y sitio en VPS
- Traductor de solicitudes de backend (elementos de juego) a Arduino y hardware en sitio
- Arduino, que era responsable de controlar los relés, recibió comandos del traductor e hizo el trabajo real.
- Dispositivos reales: ventilador, guirnaldas, lámparas de pie, etc.
- Frontend: el propio sitio web de Falcon, desde donde los jugadores controlaban los dispositivos
Repasemos cada uno de ellos.
Backend de entidades del juego
El backend se implementó como una aplicación Spring Boot: tenía varios controladores de descanso, un punto final websocket y servicios con lógica de juego.
Sólo había tres controladores:
- Megatrón. La página actual de Megatron se envió a través de solicitudes GET: antes y después de encender la energía. El láser se disparó a través de la solicitud POST.
- Mapeo de páginas con tilde para que se muestren por nombre de página. Tilde produce páginas para exportar no con nombres originales, sino con identificación interna e información de cumplimiento.
- Controlador Captcha para servir captcha de servidor de pseudo-alta carga.
El punto final Websocket se utilizó para controlar dispositivos: lámparas, guirnaldas y letras. Se eligió mostrar de forma sincronizada a todos los jugadores el estado actual del dispositivo: si está encendido o apagado, activo o no, de qué color la letra está encendida actualmente en la pared. Para hacer un poco más difícil la tarea de encender el láser, agregamos autorización a la guirnalda y al láser con el mismo nombre de usuario y contraseña admin/admin.
Los jugadores pueden probarlo encendiendo la guirnalda y repetir lo mismo con el láser.
Elegimos un par de inicio de sesión y contraseña tan trivial para no atormentar a los jugadores con selecciones innecesarias.
Para hacer la tarea un poco más interesante, se utilizaron ID de objetos de mongodb como identificadores de dispositivos en la sala.
ObjectId contiene una marca de tiempo: dos valores aleatorios, uno de los cuales se toma en función del identificador del dispositivo y el segundo en función del pid del proceso que lo genera y el valor del contador. Quería generar los identificadores a intervalos regulares y con diferentes procesos pid, pero con un contador común, para que la selección de un identificador de dispositivo láser fuera más interesante. Sin embargo, al final todos empezaron con identificadores que se diferenciaban sólo en el valor del contador. Es posible que esto haya hecho que el paso sea demasiado simple y no requiera un análisis de la estructura del objectId.
Traductor de solicitudes de backend
, quien trabajó en temporizadores y los tradujo de abstracciones de juegos a un modelo físico. Por ejemplo, "encender la lámpara de pie" → "encender el relé N2".
El script se conectó a la cola RabbitMQ y transfirió solicitudes de la cola a Arduino. También implementó la lógica del cambio de luz en paralelo: junto con algunos dispositivos, la luz se encendía, por ejemplo, cuando se suministró energía inicialmente a Megatron, se iluminó con luz de escenario. El diseño de iluminación para la cinematografía de toda la escena es una historia separada sobre el gran trabajo de nuestro coproductor del proyecto y diseñador de producción Ilya Serov, y lo contaremos en una publicación separada.
El traductor también se encargó de la lógica de lanzar la trituradora mediante un cronómetro y transmitir la imagen al televisor: el cronómetro de lanzamiento de la trituradora, un capibara gritando, un anuncio al final del juego.
Cómo se estructuró la lógica para generar el token Megatron
tiro de prueba
Cada 25 segundos se generaba una nueva ficha que podía usarse para encender el láser durante 10 segundos a una potencia de 10/255. Enlace a .
Luego, el láser se enfrió durante 1 minuto; durante este tiempo no estuvo disponible y no aceptó nuevas solicitudes de disparo.
Este poder no fue suficiente para quemar la cuerda, pero cualquier jugador podría disparar Megatron y ver el rayo láser en acción.
Se utilizó el algoritmo hash MD5 para generar el token. Y el plan funcionó MD5 de MD5 + contador + secreto para una ficha de combate y sin secreto para una ficha de prueba.
MD5 es una referencia a un proyecto comercial que realizó Pavel, nuestro patrocinador. Hace apenas un par de años, este proyecto utilizó MD5, y cuando le dijo al arquitecto del proyecto que era un algoritmo de cifrado obsoleto, comenzaron a usar MD5 a partir de MD5. Como decidimos hacer el proyecto lo más novato posible, se acordó de todo y decidió hacer una pequeña referencia.
tiro de combate
El modo de combate de Megatron es 100% de potencia láser a 3 vatios. Esto es suficiente durante 2 minutos para quemar la cuerda que sostenía el peso, romper el acuario e inundar el servidor con agua.
Dejamos algunas pistas en el Github del proyecto: concretamente, el código de generación de tokens, a partir del cual se puede entender que los tokens de prueba y de combate se generan basándose en el mismo contador. En el caso de una ficha de combate, además del valor del contador, también se utiliza una sal, que queda casi por completo en la historia del cambio de esta esencia, a excepción de los dos últimos personajes.
Conociendo estos datos, fue posible clasificar los 2 últimos símbolos de la sal y descubrir que para ello se utilizaron los números de Lost, convertidos al sistema hexadecimal.
A continuación, los jugadores tenían que captar el valor del contador (mediante el análisis de la ficha de prueba) y generar una ficha de combate utilizando el siguiente valor del contador y la sal seleccionada en el último paso.
El contador simplemente aumentó con cada disparo de prueba y cada 25 segundos. No escribimos sobre esto en ninguna parte, se suponía que sería una pequeña sorpresa del juego.
Servicio de interacción captcha
En el mundo de los videojuegos, este era el mismo captcha que había que cargar para encender el ventilador y abrir el rotafolio con una pista. Junto a la cámara había un ordenador portátil con control de carga.
Calculé qué mostrar en el monitoreo como carga actual: temperatura y ventilador de la CPU. Las métricas se transfirieron a la base de datos de tiempo y se extrajeron mediante grafana.
Si en los últimos 5 segundos hubo más de 50 solicitudes para mostrar el captcha, entonces la carga aumentó en un número fijo + aleatorio de pasos. El cálculo fue que se podría lograr el 100% de carga en dos minutos.
De hecho, había más lógica en el servicio de la que se mostró en el juego final: colocamos el monitor de tal manera que solo era visible la rotación del ventilador de la CPU.
Al comienzo de la misión querían dejar Grafan accesible desde el sitio web de Falcon. Pero también contenía métricas de springboot del informe de la aplicación backend, que no tuvimos tiempo de borrar, por lo que decidimos bloquear el acceso a él. Y con razón: incluso al comienzo de la misión, algunos jugadores adivinaron que la aplicación estaba escrita en el marco Springboot e incluso desenterraron los nombres de algunos servicios.
Hosting y bus de datos
Una herramienta para transferir información desde el backend al sitio, el servidor VPS en el que se ejecutaba RabbitMQ.
El backend y el bus de datos se mantuvieron encendidos. . Su potencia era comparable a la del ordenador que veías en pantalla: un VPS de 2 núcleos con dos gigabytes de RAM. La tarifa se cobró por los recursos, ya que la carga máxima se planificó para solo unos pocos días; esto es lo que hacen nuestros clientes que planean cargar VPS por un corto período de tiempo. Luego resultó que la carga era mayor de lo que esperábamos y una tarifa fija sería más rentable. Si haces una misión, elige las tarifas de línea. .
Para proteger el servidor de DDoSa, utilizamos Cloudflare.
Vale la pena decir que el VPS resistió todo con honor.
Arduino, que era responsable de controlar los relés, recibió comandos del traductor e hizo el trabajo real.
Este es más bien el tema del próximo artículo sobre la parte de hardware del proyecto: el backend simplemente envió solicitudes para activar un relé específico. Sucedió que el backend conocía casi todas las entidades y sus solicitudes parecían "activar esta entidad". Hicimos esto para las primeras pruebas del sitio (aún no habíamos ensamblado todos los Arduino y los relés), al final dejamos todo así.
Interfaz
Creamos rápidamente el sitio en tilde, nos tomó un día hábil y nos ahorramos 30 mil de nuestro presupuesto.
Inicialmente, pensamos en simplemente exportar el sitio y agregar la lógica que nos faltaba, pero nos topamos con términos de uso que nos prohibían hacerlo.
No estábamos dispuestos a violar la licencia, por lo que había dos opciones: implementar todo nosotros mismos o contactar directamente a Tilda, hablar sobre el proyecto y pedir permiso para cambiar el código.
Elegimos la segunda opción y no sólo nos cumplieron a medio camino, sino que incluso nos dieron un año de cuenta comercial gratuita, por lo que les estamos muy agradecidos. Fue muy incómodo mostrarles el diseño del sitio web de Sokol.
Como resultado, adjuntamos lógica js a la interfaz para enviar solicitudes a dispositivos elementales y cambiamos ligeramente los estilos de los botones para activar y desactivar elementos del juego.
Diseño de sitio web
La historia de las búsquedas, que merece un capítulo aparte.
Queríamos crear no sólo un sitio anticuado, sino uno absolutamente repugnante que viole todas las reglas básicas de diseño. Al mismo tiempo, era importante mantener la credibilidad: no debía romper la historia otorrinolaringológica, demostrar la pretenciosidad del autor, y los jugadores tendrían que creer que un sitio así podría existir e incluso atraer clientes. ¡Y lo trajo! Mientras se desarrollaba el juego, nos contactaron dos veces para crear sitios web.
Al principio hice el diseño yo mismo, intentando incluir más gifs y elementos brillantes. Pero mi esposo diseñador durante 10 años miró por encima del hombro y lo descartó como "demasiado bueno". Para romper las reglas de diseño, es necesario conocerlas.
Hay varias combinaciones de colores que evocan un sentimiento duradero de disgusto: verde y rojo de igual riqueza, gris y rosa, azul más marrón. Al final, nos decidimos por una combinación de rojo y verde como colores base, agregamos gifs con un gato y seleccionamos 3-4 fotos del propio Sokolov de una foto de archivo. Solo tenía unos pocos requisitos: un hombre de mediana edad, vestido con un traje que no le quedaba bien y un par de tallas más grande y en una pose de “sesión fotográfica de estudio profesional”. Para la prueba, se lo mostraron a sus amigos y les preguntaron "¿Qué te parece?".
Durante el proceso de desarrollo del diseño, mi esposo tenía que ir a acostarse cada media hora, el helicóptero comenzó a volar. Pasha intentó abrir la consola de desarrollador en la mayor parte de la pantalla mientras terminaba de terminar la interfaz, para proteger sus ojos.
Dispositivos reales
Los ventiladores y las luces se montaron mediante relés de estado sólido para que no se encendieran inmediatamente a plena potencia, de modo que la potencia aumentara en paralelo con el monitoreo.
Pero hablaremos de esto en la próxima publicación, sobre la parte del hardware del juego y la construcción real del sitio.
¡Manténganse al tanto!
Otros artículos sobre la misión para destruir el servidor.
Fuente: habr.com