Pokračujeme v rozprávaní o tom, ako bol usporiadaný náš laserový quest so zničením servera. Začnite v predchádzajúcom .
Celkovo mal backend hry 6 architektonických jednotiek, ktoré budeme analyzovať v tomto článku:
- Backend herných entít, ktoré boli zodpovedné za herné mechanizmy
- Backend a zbernica na výmenu dát na VPS
- Prekladač z backendových požiadaviek (herných prvkov) do Arduina a hardvéru na mieste
- Arduino, ktoré bolo zodpovedné za ovládanie relé, dostalo príkazy od prekladača a vykonalo skutočnú prácu
- Skutočné zariadenia: ventilátor, girlandy, podlahové svietidlá atď.
- Frontend - samotná webová stránka Falcon, z ktorej hráči ovládali zariadenia
Poďme si prejsť každý z nich.
Backend herných entít
Backend bol implementovaný ako aplikácia na jarné zavádzanie: mal niekoľko zvyšných ovládačov, koncový bod websocket a služby s hernou logikou.
Boli len traja ovládače:
- Megatron. Aktuálna stránka Megatron bola odoslaná prostredníctvom žiadostí GET: pred a po zapnutí napájania. Laser vystrelil cez požiadavku POST.
- Mapovanie stránok vlnovky tak, aby sa zobrazovali podľa názvu stránky. Tilde vytvára stránky na export nie s pôvodnými názvami, ale s interným ID a informáciami o súlade.
- Kontrolér Captcha na obsluhu captcha servera s pseudovysokým zaťažením.
Koncový bod Websocket sa používal na ovládanie miniaplikácií: lámp, girlandy a písmen. Bol zvolený tak, aby synchrónne zobrazoval všetkým hráčom aktuálny stav zariadenia: či je zapnuté alebo vypnuté, aktívne alebo nie, aká farba písmena práve svieti na stene. Aby sme trochu sťažili zapnutie lasera, pridali sme oprávnenie girlande a laseru s rovnakým prihlasovacím menom a heslom admin/admin.
Hráči si to mohli vyskúšať zapnutím girlandy a zopakovať to isté s laserom.
Takúto triviálnu dvojicu login-heslo sme zvolili preto, aby sme hráčov netrápili zbytočným výberom.
Aby bola úloha trochu zaujímavejšia, ako identifikátory zariadení v miestnosti boli použité ID objektov z mongodb.
ObjectId obsahuje časovú značku: dve náhodné hodnoty, z ktorých jedna sa berie na základe identifikátora zariadenia a druhá na základe pid procesu, ktorý ho generuje, a hodnoty počítadla. Chcel som urobiť identifikátory generované v pravidelných intervaloch a rôznymi pid procesmi, ale so spoločným počítadlom, aby bol výber identifikátora laserového zariadenia zaujímavejší. Všetci však nakoniec začali s identifikátormi, ktoré sa líšili len hodnotou počítadla. To mohlo spôsobiť, že krok je príliš jednoduchý a nevyžaduje analýzu štruktúry objectId.
Prekladač z backendových požiadaviek
, ktorý pracoval na časovačoch a previedol ich z herných abstrakcií do fyzického modelu. Napríklad „zapnite stojacu lampu“ → „zapnite relé N2“.
Skript sa pripojil k frontu RabbitMQ a preniesol požiadavky z frontu do Arduina. Implementovala tiež logiku paralelného prepínania svetiel: spolu s niektorými zariadeniami sa svetlo na nich rozsvietilo, napríklad keď sa na začiatku dodávala energia do Megatronu, bolo osvetlené scénickým svetlom. Svetelný dizajn pre kinematografiu celej scény je samostatný príbeh o skvelej práci nášho projektového koproducenta a produkčného dizajnéra Ilju Serova a povieme o ňom v samostatnom príspevku.
Prekladateľ bol zodpovedný aj za logiku spustenia skartovačky pomocou časovača a prenosu obrazu do TV: časovač spustenia skartovačky, kričiaca kapybara, reklama na konci hry.
Ako bola štruktúrovaná logika generovania tokenu Megatron
Skúšobný výstrel
Každých 25 sekúnd sa vygeneroval nový token a mohol sa použiť na zapnutie lasera na 10 sekúnd pri výkone 10/255. Odkaz na .
Laser sa potom 1 minútu ochladzoval – počas tejto doby bol nedostupný a neakceptoval nové požiadavky na záber.
Táto sila nestačila na prepálenie lana, ale každý hráč mohol odpáliť Megatron a vidieť laserový lúč v akcii.
Na generovanie tokenu bol použitý hashovací algoritmus MD5. A schéma vyšla MD5 z MD5 + počítadlo + tajenka za bojový žetón a bez tajomstva za skúšobný žetón.
MD5 je odkaz na komerčný projekt, ktorý robil Pavel, náš backender. Len pred pár rokmi tento projekt používal MD5, a keď povedal architektovi projektu, že ide o zastaraný šifrovací algoritmus, začali používať MD5 z MD5. Keďže sme sa rozhodli urobiť čo najväčší noob projekt, všetko si zapamätal a rozhodol sa urobiť malú referenciu.
Bojová strela
Bojový režim Megatronu je 100% výkon lasera pri 3 wattoch. To stačí na 2 minúty na prepálenie lana, ktoré držalo váhu, na rozbitie akvária a zaplavenie servera vodou.
Na Github projektu sme zanechali niekoľko rád: konkrétne kód generovania tokenov, z ktorého by sa dalo pochopiť, že testovacie a bojové tokeny sa generujú na základe rovnakého indikátora počítadla. V prípade bojového tokenu sa okrem hodnoty počítadla používa aj soľ, ktorá takmer úplne zostala v histórii zmeny tejto podstaty, s výnimkou posledných dvoch postáv.
Pri poznaní týchto údajov bolo možné pretriediť posledné 2 symboly soli a vlastne zistiť, že na to boli použité čísla zo Strateného, prevedené do šestnástkovej sústavy.
Potom museli hráči zachytiť hodnotu počítadla (analýzou testovacieho žetónu) a vygenerovať bojový žetón pomocou nasledujúcej hodnoty počítadla a soli vybranej v predchádzajúcom kroku.
Počítadlo sa jednoducho zvýšilo pri každom testovacom výstrele a každých 25 sekúnd. Nikde sme o tom nepísali, malo to byť malé herné prekvapenie.
Interakčná služba captcha
V hernom svete to bola rovnaká captcha, ktorá sa musela načítať, aby sa zapol ventilátor a otvoril flipchart s náznakom. Vedľa kamery bol notebook s monitorovaním záťaže.
Počítal som, čo sa má zobraziť v monitorovaní ako aktuálna záťaž: teplota a ventilátor CPU. Metriky boli prenesené do databázy časovej základne a nakreslené grafanou.
Ak sa za posledných 5 sekúnd vyskytlo viac ako 50 požiadaviek na zobrazenie captcha, zaťaženie sa zvýšilo o pevný + náhodný počet krokov. Výpočet bol taký, že 100% zaťaženie sa dá dosiahnuť za dve minúty.
V skutočnosti bolo v službe viac logiky, ako sa zobrazilo vo finálnej hre: monitor sme umiestnili tak, aby bolo viditeľné iba otáčanie ventilátora CPU.
Na začiatku pátrania chceli nechať Grafana prístupný z webovej stránky Falcon. Obsahoval ale aj metriky springboot z reportu backendovej aplikácie, ktoré sme nestihli vyčistiť, preto sme sa rozhodli k nemu zablokovať prístup. A je to tak správne – už na začiatku questu niektorí hráči hádali, že aplikácia je napísaná v frameworku springboot a dokonca vykopali názvy niektorých služieb.
Hosting a dátová zbernica
Nástroj na prenos informácií z backendu na stránku, server VPS, na ktorom bežal RabbitMQ.
Backend a dátová zbernica zostali zapnuté . Jeho výkon bol porovnateľný s počítačom, ktorý ste videli na obrazovke: 2-jadrový VPS s dvoma gigabajtmi RAM. Tarifa bola spoplatnená za zdroje, keďže špičková záťaž bola plánovaná len na niekoľko dní – to robia naši klienti, ktorí plánujú zaťažiť VPS krátkodobo. Potom sa ukázalo, že zaťaženie bolo vyššie, ako sme očakávali, a fixná tarifa by bola výhodnejšia. Ak robíte quest, vyberte si tarify linky .
Na ochranu servera pred DDoSa sme použili Cloudflare.
Stojí za to povedať, že VPS vydržala všetko so cťou.
Arduino, ktoré bolo zodpovedné za ovládanie relé, dostalo príkazy od prekladača a vykonalo skutočnú prácu
To je viac témou ďalšieho článku o hardvérovej časti projektu: backend jednoducho odoslal požiadavky na zapnutie konkrétneho relé. Stalo sa, že backend poznal takmer všetky entity a požiadavky z neho vyzerali ako „zapnite túto entitu“. Urobili sme to pre skoré testovanie stránky (ešte sme nemali zostavené všetky Arduino a relé), nakoniec sme všetko nechali tak.
Frontend
Stránku sme vytvorili rýchlo na tilde, trvalo to jeden pracovný deň a ušetrilo nám to 30 tisíc v rozpočte.
Pôvodne sme mysleli, že jednoducho exportujeme stránku a pridáme logiku, ktorá nám chýba, ale narazili sme na podmienky používania, ktoré nám to zakazovali.
Neboli sme pripravení porušiť licenciu, takže boli dve možnosti: implementovať všetko sami alebo kontaktovať priamo Tildu, porozprávať sa o projekte a požiadať o povolenie na zmenu kódu.
Zvolili sme druhú možnosť a nielenže nám vyšli v ústrety na polceste, ale dokonca nám poskytli rok podnikania zadarmo, za čo sme im veľmi vďační. Bolo veľmi nepríjemné ukázať im dizajn Sokolovho webu.
V dôsledku toho sme k frontendu pripojili logiku js na odosielanie požiadaviek na základné zariadenia a mierne zmenili štýly tlačidiel na zapínanie a vypínanie herných prvkov.
Dizajn webových stránok
História rešerší, ktorá stojí za samostatnú kapitolu.
Chceli sme vytvoriť nielen staromódnu stránku, ale úplne ohavnú, ktorá porušuje všetky základné pravidlá dizajnu. Zároveň bolo dôležité zachovať vierohodnosť: muselo to neporušiť príbeh ORL, demonštrovať domýšľavosť autora a hráči museli veriť, že takáto stránka môže existovať a dokonca prinášať klientov. A priniesol to! Kým hra prebiehala, boli sme dvakrát kontaktovaní, aby sme vytvorili webové stránky.
Najprv som robil dizajn sám, snažil som sa zahrnúť viac gifov a lesklých prvkov. Ale môj 10-ročný dizajnérsky manžel sa pozrel cez rameno a odmietol to ako „príliš dobré“. Ak chcete porušiť pravidlá dizajnu, musíte ich poznať.
Existuje niekoľko farebných kombinácií, ktoré vyvolávajú trvalý pocit znechutenia: zelená a červená rovnakej sýtosti, šedá a ružová, modrá plus hnedá. Nakoniec sme sa rozhodli pre kombináciu červenej a zelenej ako základných farieb, pridali gify s mačkou a vybrali 3-4 fotky samotného Sokolova z stock fotky. Mal som len niekoľko požiadaviek: muž v strednom veku, oblečený v nepadnúcom obleku o pár čísel príliš veľkom a v póze „profesionálneho ateliérového fotenia“. Na test to ukázali priateľom a spýtali sa: „Ako sa vám to páči?
Počas vývoja dizajnu si manžel musel každú pol hodinu ľahnúť, helikoptéra začala lietať. Pasha sa pokúsil otvoriť konzolu pre vývojárov na väčšinu obrazovky, kým dokončil dokončovanie frontendu - aby si chránil oči.
Skutočné zariadenia
Ventilátory a svetlá boli namontované cez polovodičové relé, aby sa okamžite nezapli na plný výkon – aby sa výkon zvyšoval súbežne s monitorovaním.
Ale o tom si povieme v ďalšom príspevku, o hardvérovej časti hry a samotnej konštrukcii stránky.
Zostaňte naladení!
Ďalšie články o snahe zničiť server
Zdroj: hab.com