Jak powstał backend gry hakerskiej o zniszczeniu serwera

Jak powstał backend gry hakerskiej o zniszczeniu serwera
Nadal opowiadamy, jak zorganizowano naszą misję laserową ze zniszczeniem serwera. Zacznij od poprzedniego artykuł o rozwiązaniu zadania.

W sumie backend gry miał 6 jednostek architektonicznych, które przeanalizujemy w tym artykule:

  1. Backend podmiotów gry odpowiedzialnych za mechanizmy gry
  2. Magistrala wymiany danych backendu i witryny na VPS
  3. Tłumacz z żądań backendu (elementów gry) na Arduino i sprzęt na miejscu
  4. Arduino, które odpowiadało za sterowanie przekaźnikami, otrzymywało polecenia od tłumacza i wykonywało właściwą pracę
  5. Rzeczywiste urządzenia: wentylator, girlandy, lampy podłogowe itp.
  6. Frontend – sama strona internetowa Falcona, z poziomu której gracze sterowali urządzeniami

Przejrzyjmy każdy z nich.

Backend elementów gry

Backend został zaimplementowany jako aplikacja do uruchamiania wiosennego: posiadał kilka kontrolerów odpoczynku, punkt końcowy websocket i usługi z logiką gry.

Było tylko trzech kontrolerów:

  • Megatron. Bieżąca strona Megatron została wysłana poprzez żądania GET: przed i po włączeniu zasilania. Laser uruchomił się po żądaniu POST.
  • Mapowanie stron tyldy tak, aby były obsługiwane według nazwy strony. Tilde tworzy strony do eksportu nie z oryginalnymi nazwami, ale z wewnętrznym identyfikatorem i informacjami o zgodności.
  • Kontroler Captcha do obsługi captcha serwera o pseudo-wysokim obciążeniu.

Punkt końcowy Websocket służył do sterowania gadżetami: lampkami, girlandami i literami. Zdecydowano się tak, aby synchronicznie wyświetlać wszystkim graczom aktualny stan urządzenia: czy jest włączone, czy wyłączone, aktywne czy nie, jaki kolor litery aktualnie świeci na ścianie. Aby nieco utrudnić zadanie włączenia lasera, dodaliśmy autoryzację do girlandy i lasera tym samym loginem i hasłem admin/admin.

Gracze mogli to sprawdzić, włączając girlandę i powtarzając to samo z laserem.

Wybraliśmy tak banalną parę login-hasło, żeby nie dręczyć graczy zbędnym wyborem.

Aby zadanie było trochę bardziej interesujące, jako identyfikatory urządzeń w pokoju wykorzystano identyfikatory obiektów z mongodb.

ObjectId zawiera znacznik czasu: dwie losowe wartości, z których jedna jest pobierana na podstawie identyfikatora urządzenia, a druga na podstawie pid procesu, który ją generuje i wartości licznika. Chciałem, żeby identyfikatory były generowane w regularnych odstępach czasu i przy różnych procesach pid, ale ze wspólnym licznikiem, żeby wybór identyfikatora urządzenia laserowego był ciekawszy. Ostatecznie jednak wszyscy zaczynali od identyfikatorów, które różniły się jedynie wartością licznika. Mogło to sprawić, że krok był zbyt prosty i nie wymagał analizy struktury objectId.

Tłumacz z żądań zaplecza

Skrypt Pythona, który pracował nad licznikami czasu i przełożył je z abstrakcji gier na model fizyczny. Na przykład „włącz lampę podłogową” → „włącz przekaźnik N2”.

Skrypt łączył się z kolejką RabbitMQ i przesyłał żądania z kolejki do Arduino. Zaimplementowano także logikę równoległego włączania światła: wraz z niektórymi urządzeniami włączano na nich światło, np. gdy Megatron był początkowo zasilany, oświetlano je światłem scenicznym. Projekt oświetlenia do zdjęć całej sceny to osobna opowieść o wspaniałej pracy naszego współproducenta i scenografa Ilyi Serova, o której opowiemy w osobnym poście.

Tłumacz odpowiadał także za logikę uruchomienia niszczarki za pomocą timera i przesłania obrazu do telewizora: timer uruchomienia niszczarki, krzycząca kapibara, reklama na koniec gry.

Jak została zorganizowana logika generowania tokena Megatron

Strzał próbny

Co 25 sekund generowany był nowy token, za pomocą którego można było włączyć laser na 10 sekund przy mocy 10/255. Łączyć z github z kodem Megatron.

Laser następnie ostygł przez 1 minutę – w tym czasie był niedostępny i nie przyjmował próśb o nowe strzały.

Ta moc nie wystarczyła, aby przepalić linę, ale każdy gracz mógł wystrzelić Megatrona i zobaczyć wiązkę lasera w akcji.

Do wygenerowania tokena wykorzystano algorytm mieszający MD5. I schemat się powiódł MD5 z MD5 + licznik + sekret dla żetonu walki i bez sekretu dla żetonu testu.

MD5 jest nawiązaniem do komercyjnego projektu, który wykonał Pavel, nasz backender. Zaledwie kilka lat temu w tym projekcie wykorzystano MD5, a kiedy architekt projektu powiedział architektowi projektu, że jest to przestarzały algorytm szyfrowania, zaczął używać MD5 z MD5. Ponieważ zdecydowaliśmy się na możliwie najbardziej noobowy projekt, zapamiętał wszystko i postanowił zrobić małe odniesienie.

Strzał bojowy

Tryb walki Megatrona to 100% mocy lasera przy 3 watach. Wystarczy to na 2 minuty, aby przepalić linę utrzymującą ciężar, rozbić akwarium i zalać serwer wodą.

Na Githubie projektu zostawiliśmy kilka wskazówek: mianowicie kod generowania tokenów, z którego można zrozumieć, że tokeny testowe i bojowe generowane są w oparciu o ten sam licznik. W przypadku żetonu walki oprócz wartości licznika używana jest także sól, która jest prawie w całości pozostawiona w historii zmian tej istoty, z wyjątkiem dwóch ostatnich znaków.

Znając te dane, można było posortować 2 ostatnie symbole soli i faktycznie dowiedzieć się, że wykorzystano do tego liczby z Lost, przeliczone na system szesnastkowy.

Następnie gracze musieli wyłapać wartość licznika (analizując żeton testu) i wygenerować żeton walki, korzystając z kolejnej wartości licznika i wybranej w poprzednim kroku soli.

Licznik po prostu zwiększał się z każdym strzałem testowym i co 25 sekund. Nigdzie o tym nie pisaliśmy, miała to być mała gra-niespodzianka.

Usługa interakcji Captcha

W świecie gier była to ta sama captcha, którą trzeba było załadować, aby włączyć wentylator i otworzyć flipchart z podpowiedzią. Obok kamery stał laptop z monitoringiem obciążenia.

Jak powstał backend gry hakerskiej o zniszczeniu serwera

Platforma Obliczyłem co wyświetlić w monitorowaniu jako aktualne obciążenie: temperaturę i wentylator procesora. Metryki przeniesiono do bazy czasu i narysowano za pomocą grafany.

Jeśli w ciągu ostatnich 5 sekund pojawiło się więcej niż 50 żądań wyświetlenia captcha, wówczas obciążenie wzrosło o stałą + losową liczbę kroków. Obliczenia były takie, że 100% obciążenia można osiągnąć w ciągu dwóch minut.

Tak naprawdę w usłudze było więcej logiki, niż pokazano w finalnej grze: monitor umieściliśmy w taki sposób, że widoczny był tylko obrót wentylatora procesora.

Na początku zadania chcieli, aby Grafan był dostępny na stronie internetowej Falcona. Zawierał jednak także dane dotyczące springboota z raportu aplikacji backendowej, których nie mieliśmy czasu wyczyścić, więc postanowiliśmy zablokować do nich dostęp. I słusznie – już na początku questu część graczy domyślała się, że aplikacja została napisana w frameworku springboot, a nawet dokopywała się do nazw niektórych usług.

Hosting i magistrala danych

Narzędzie do przesyłania informacji z backendu na stronę, serwer VPS, na którym działał RabbitMQ.

Zaplecze i magistrala danych pozostały włączone naszego VPS-a. Jego moc była porównywalna z komputerem, który widziałeś na ekranie: 2-rdzeniowy VPS z dwoma gigabajtami pamięci RAM. Taryfa została naliczona za zasoby, gdyż szczytowe obciążenie było zaplanowane tylko na kilka dni – tak postępują nasi klienci, którzy planują doładować VPS na krótki okres czasu. Potem okazało się, że ładunek jest większy niż się spodziewaliśmy i bardziej opłacalna będzie stała taryfa. Jeśli wykonasz zadanie, wybierz taryfy liniowe turbo.

Aby zabezpieczyć serwer przed DDoSa użyliśmy Cloudflare.

Warto powiedzieć, że VPS zniósł wszystko z honorem.

Arduino, które odpowiadało za sterowanie przekaźnikami, otrzymywało polecenia od tłumacza i wykonywało właściwą pracę

Jest to bardziej temat następnego artykułu na temat sprzętowej części projektu: backend po prostu wysyłał żądania włączenia określonego przekaźnika. Tak się złożyło, że backend znał prawie wszystkie encje i żądania z niego wyglądały w stylu „włącz tę encję”. Zrobiliśmy to w celu wczesnego przetestowania witryny (nie zmontowaliśmy jeszcze całego Arduino i przekaźników), na koniec wszystko tak zostawiliśmy.

Interfejs użytkownika

Szybko stworzyliśmy stronę na tyldzie, zajęło to jeden dzień roboczy i zaoszczędziliśmy 30 tysięcy w naszym budżecie.

Początkowo myśleliśmy o prostym wyeksportowaniu witryny i dodaniu logiki, której nam brakowało, ale napotkaliśmy warunki użytkowania, które zabraniały nam tego.

Nie byliśmy gotowi na łamanie licencji, więc były dwie możliwości: wdrożyć wszystko samodzielnie lub skontaktować się bezpośrednio z Tildą, porozmawiać o projekcie i poprosić o pozwolenie na zmianę kodu.

Wybraliśmy drugą opcję i nie tylko spotkali nas w połowie drogi, ale nawet dali nam rok darmowego konta firmowego, za co jesteśmy im bardzo wdzięczni. Pokazywanie im projektu strony internetowej Sokola było bardzo niezręczne.

W rezultacie do frontendu dołączyliśmy logikę js do wysyłania żądań do elementarnych urządzeń oraz nieznacznie zmieniliśmy styl przycisków włączania i wyłączania elementów gry.

Projekt strony internetowej

Historia wyszukiwań, której warto poświęcić osobny rozdział.

Chcieliśmy stworzyć nie tylko staromodną witrynę, ale absolutnie obrzydliwą, która łamie wszystkie podstawowe zasady projektowania. Jednocześnie ważne było zachowanie wiarygodności: nie miała ona psuć historii laryngologicznej, pokazywać pretensjonalności autora, a gracze musieli uwierzyć, że taka strona może istnieć i nawet przyciągać klientów. I przyniósł! W trakcie trwania gry dwukrotnie skontaktowano się z nami w sprawie stworzenia stron internetowych.

Na początku projekt robiłem sam, starając się uwzględnić więcej gifów i błyszczących elementów. Ale mój mąż, projektant, z którym jestem od 10 lat, obejrzał się przez ramię i stwierdził, że jest „zbyt dobry”. Aby łamać zasady projektowania, trzeba je znać.

Jak powstał backend gry hakerskiej o zniszczeniu serwera

Istnieje kilka kombinacji kolorystycznych, które wywołują trwałe uczucie odrazy: zieleń i czerwień o jednakowej intensywności, szarość i róż, błękit i brąz. Ostatecznie zdecydowaliśmy się na połączenie czerwieni i zieleni jako kolorów podstawowych, dodaliśmy gify z kotem i wybraliśmy 3-4 zdjęcia samego Sokołowa ze zdjęcia stockowego. Miałem tylko kilka wymagań: mężczyzna w średnim wieku, ubrany w źle dopasowany garnitur o kilka numerów za duży i w pozie „profesjonalnej sesji zdjęciowej w studio”. Na potrzeby testu pokazali go znajomym i zapytali „jak ci się podoba?”

Podczas opracowywania projektu mój mąż co pół godziny musiał się położyć i helikopter zaczął latać. Pasza próbował otworzyć konsolę programistyczną na większą część ekranu, gdy kończył prace nad frontendem - aby chronić oczy.

Rzeczywiste urządzenia

Wentylatory i oświetlenie zamontowano poprzez przekaźniki półprzewodnikowe, tak aby nie włączały się od razu z pełną mocą - aby moc rosła równolegle z monitorowaniem.

Ale o tym porozmawiamy w następnym poście, o sprzętowej części gry i samej budowie strony.

Bądźcie czujni!

Inne artykuły o dążeniu do zniszczenia serwera

Jak powstał backend gry hakerskiej o zniszczeniu serwera

Źródło: www.habr.com

Dodaj komentarz