Continuem explicant-vos com es va organitzar la nostra recerca làser amb la destrucció del servidor. Comença a l'anterior .
En total, el backend del joc tenia 6 unitats arquitectòniques, que analitzarem en aquest article:
- Backend de les entitats del joc que eren responsables dels mecanismes del joc
- Bus d'intercanvi de dades de backend i lloc a VPS
- Traductor de sol·licituds de backend (elements del joc) a Arduino i maquinari in situ
- Arduino, que s'encarregava de controlar els relés, va rebre ordres del traductor i va fer el treball real
- Dispositius reals: ventilador, garlandes, làmpades de peu, etc.
- Frontend: el mateix lloc web de Falcon, des del qual els jugadors controlaven els dispositius
Repassem cadascun d'ells.
Backend de les entitats del joc
El backend es va implementar com una aplicació d'arrencada de primavera: tenia diversos controladors de descans, un punt final de websocket i serveis amb lògica de joc.
Només hi havia tres controladors:
- Megatron. La pàgina actual de Megatron es va enviar mitjançant sol·licituds GET: abans i després d'encendre l'alimentació. El làser es va disparar mitjançant la sol·licitud POST.
- Assignació de pàgines de tilde perquè es publiquin pel nom de la pàgina. Tilde produeix pàgines per exportar no amb noms originals, sinó amb identificació interna i informació de compliment.
- Controlador de captcha per servir captcha del servidor de pseudo-alta càrrega.
El punt final de Websocket es va utilitzar per controlar gadgets: llums, garlanda i lletres. Es va triar per mostrar de manera sincrònica a tots els jugadors l'estat actual del dispositiu: si està encès o apagat, actiu o no, quin color de la lletra està il·luminat actualment a la paret. Per tal de dificultar una mica la tasca d'encendre el làser, hem afegit autorització a la garlanda i al làser amb el mateix inici de sessió i contrasenya admin/admin.
Els jugadors podrien provar-ho engegant la garlanda i repetint el mateix amb el làser.
Hem escollit una parella d'inici de sessió-contrasenya tan trivial per no turmentar els jugadors amb una selecció innecessària.
Per fer la tasca una mica més interessant, es van utilitzar els identificadors d'objectes de mongodb com a identificadors de dispositius a la sala.
ObjectId conté una marca de temps: dos valors aleatoris, un dels quals es pren en funció de l'identificador del dispositiu i el segon basat en el pid del procés que el genera i el valor del comptador. Volia fer els identificadors generats a intervals regulars i amb diferents processos pid, però amb un comptador comú, perquè la selecció d'un identificador de dispositiu làser fos més interessant. Tanmateix, al final, tothom va començar amb identificadors que només es diferenciaven pel valor del comptador. Això pot haver fet que el pas sigui massa senzill i no requereixi una anàlisi de l'estructura objectId.
Traductor de sol·licituds de backend
, que va treballar amb temporitzadors i els va traduir d'abstraccions de jocs a un model físic. Per exemple, "enceneu el llum de peu" → "enceneu el relé N2".
L'script es va connectar a la cua RabbitMQ i va transferir les sol·licituds de la cua a Arduino. També va implementar la lògica de la commutació de la llum paral·lela: juntament amb alguns dispositius, la llum d'ells s'encenia, per exemple, quan es va subministrar energia inicialment a Megatron, s'il·luminava amb llum d'escenari. El disseny d'il·luminació per a la cinematografia de tota l'escena és una història a part sobre el gran treball del nostre coproductor de projecte i dissenyador de producció Ilya Serov, i ho explicarem en una publicació a part.
El traductor també s'encarregava de la lògica d'engegar la trituradora amb un temporitzador i transmetre la imatge al televisor: el temporitzador per llançar la trituradora, un capibara cridant, un anunci al final del joc.
Com es va estructurar la lògica per generar el testimoni Megatron
Tir de prova
Cada 25 segons es generava un nou testimoni que es podia utilitzar per encendre el làser durant 10 segons a una potència 10/255. Enllaç a .
Aleshores, el làser es va refredar durant 1 minut; durant aquest temps no estava disponible i no va acceptar noves sol·licituds de trets.
Aquest poder no era suficient per cremar la corda, però qualsevol jugador podia disparar Megatron i veure el raig làser en acció.
Es va utilitzar l'algoritme de hash MD5 per generar el testimoni. I l'esquema va funcionar MD5 de MD5 + comptador + secret per a una fitxa de combat i sense secret per a una fitxa de prova.
MD5 és una referència a un projecte comercial que va fer Pavel, el nostre backender. Fa només un parell d'anys, aquest projecte va utilitzar MD5, i quan va dir a l'arquitecte del projecte que era un algorisme de xifratge obsolet, van començar a utilitzar MD5 a partir de MD5. Com que vam decidir fer el projecte més noob possible, ell ho va recordar tot i va decidir fer una petita referència.
Tir de combat
El mode de combat de Megatron és 100% de potència làser a 3 watts. Això és suficient per 2 minuts per cremar la corda que aguantava el pes, per trencar l'aquari i inundar el servidor amb aigua.
Hem deixat algunes pistes sobre el Github del projecte: és a dir, el codi de generació de fitxes, a partir del qual es podria entendre que les fitxes de prova i de combat es generen a partir del mateix indicador de comptador. En el cas d'una fitxa de combat, a més del valor del comptador, també s'utilitza una sal, que queda gairebé completament en la història del canvi d'aquesta essència, amb l'excepció dels dos darrers personatges.
Coneixent aquestes dades, va ser possible ordenar els 2 últims símbols de la sal i realment esbrinar que els números de Lost, convertits al sistema hexadecimal, s'utilitzaven per a això.
Aleshores, els jugadors havien d'agafar el valor del comptador (analitzant la fitxa de prova) i generar una fitxa de combat utilitzant el valor del comptador següent i la sal seleccionada al pas anterior.
El comptador simplement augmentava amb cada tir de prova i cada 25 segons. No vam escriure sobre això enlloc, se suposava que havia de ser una petita sorpresa.
Servei d'interacció captcha
Al món dels jocs, aquest era el mateix captcha que s'havia de carregar per encendre el ventilador i obrir el rotafolio amb una pista. Al costat de la càmera hi havia un ordinador portàtil amb control de càrrega.
Vaig calcular què mostrar al monitoratge com a càrrega actual: temperatura i ventilador de la CPU. Les mètriques es van transferir a la base de dades de la base de temps i es van dibuixar mitjançant grafana.
Si en els últims 5 segons hi ha hagut més de 50 sol·licituds per mostrar el captcha, la càrrega augmenta en un nombre de passos fix + aleatori. El càlcul va ser que es podria aconseguir el 100% de càrrega en dos minuts.
De fet, hi havia més lògica en el servei de la que es mostrava en el joc final: vam col·locar el monitor de manera que només fos visible la rotació del ventilador de la CPU.
Al principi de la recerca, volien deixar accessible Grafan des del lloc web de Falcon. Però també contenia mètriques d'inici de primavera de l'informe de l'aplicació de fons, que no vam tenir temps d'esborrar, així que vam decidir bloquejar-hi l'accés. I amb raó, fins i tot al començament de la recerca, alguns jugadors van endevinar que l'aplicació estava escrita al marc de Springboot i fins i tot van desenterrar els noms d'alguns serveis.
Allotjament i bus de dades
Una eina per transferir informació del backend al lloc, el servidor VPS en què s'executava RabbitMQ.
El backend i el bus de dades es van mantenir activats . La seva potència era comparable a l'ordinador que veieu a la pantalla: un VPS de 2 nuclis amb dos gigabytes de memòria RAM. La tarifa es va cobrar pels recursos, ja que la càrrega màxima es va planificar per només uns dies; això és el que fan els nostres clients que tenen previst carregar VPS durant un període de temps curt. Llavors va resultar que la càrrega era més gran del que esperàvem i una tarifa fixa seria més rendible. Si feu una recerca, trieu les tarifes de línia .
Per protegir el servidor de DDoSa, hem utilitzat Cloudflare.
Val la pena dir que el VPS ho va resistir tot amb honor.
Arduino, que s'encarregava de controlar els relés, va rebre ordres del traductor i va fer el treball real
Aquest és més el tema del següent article sobre la part de maquinari del projecte: el backend simplement envia sol·licituds per activar un relé específic. Va passar que el backend coneixia gairebé totes les entitats i les sol·licituds d'ell semblaven "activar aquesta entitat". Ho vam fer per a les proves primerenques del lloc (encara no havíem muntat tot l'Arduino i els relés), al final ho vam deixar tot així.
Frontend
Vam crear ràpidament el lloc a tilde, vam trigar un dia laborable i ens vam estalviar 30 mil en el nostre pressupost.
Al principi, vam pensar simplement exportar el lloc i afegir la lògica que ens faltava, però ens vam trobar amb termes d'ús que ens prohibien fer-ho.
No estàvem preparats per infringir la llicència, així que hi havia dues opcions: implementar-ho tot nosaltres mateixos o contactar directament amb Tilda, parlar del projecte i demanar permís per canviar el codi.
Vam triar la segona opció i no només ens van conèixer a mig camí, sinó que fins i tot ens van donar un any de compte comercial gratuït, fet que els estem molt agraïts. Va ser molt incòmode mostrar-los el disseny del lloc web de Sokol.
Com a resultat, vam connectar la lògica js a la interfície per enviar sol·licituds a dispositius elementals i vam canviar lleugerament els estils dels botons per activar i desactivar els elements del joc.
Disseny de llocs web
L'historial de les cerques, que val la pena un capítol a part.
Volíem crear no només un lloc passat de moda, sinó un de absolutament repugnant que infringeixi totes les regles bàsiques del disseny. Al mateix temps, era important mantenir la credibilitat: no havia de trencar la història d'ENT, demostrar la pretensió de l'autor i els jugadors haurien de creure que aquest lloc podria existir i fins i tot portar clients. I el va portar! Mentre el joc continuava, ens van contactar dues vegades per crear llocs web.
Al principi vaig fer el disseny jo mateix, intentant incloure més gifs i elements brillants. Però el meu marit dissenyador de 10 anys es va mirar per sobre de la seva espatlla i ho va descartar com a "massa bo". Per trencar les regles de disseny, cal conèixer-les.
Hi ha diverses combinacions de colors que evoquen una sensació de fàstic duradora: verd i vermell d'igual riquesa, gris i rosa, blau més marró. Al final, vam optar per una combinació de vermell i verd com a colors base, vam afegir gifs amb un gat i vam seleccionar 3-4 fotos del mateix Sokolov d'una foto d'estoc. Només tenia uns quants requisits: un home de mitjana edat, amb un vestit poc ajustat d'un parell de talles massa gran i en una postura de "secció de fotos d'estudi professional". Per a la prova, la van ensenyar als amics i van preguntar "com us agrada?"
Durant el procés de desenvolupament del disseny, el meu marit havia d'anar a estirar cada mitja hora; l'helicòpter va començar a volar. En Pasha va intentar obrir la consola del desenvolupador a la major part de la pantalla mentre acabava d'acabar la interfície, per protegir-se els ulls.
Dispositius reals
Els ventiladors i les llums es van muntar mitjançant relés d'estat sòlid perquè no s'encenguessin a plena potència immediatament, de manera que la potència augmentaria paral·lelament a la monitorització.
Però en parlarem a la propera publicació, sobre la part de maquinari del joc i la construcció real del lloc.
Estiguin atents!
Altres articles sobre la recerca per destruir el servidor
Font: www.habr.com