Kiel kreiĝis la backend de hakerludo pri detruado de servilo

Kiel kreiĝis la backend de hakerludo pri detruado de servilo
Ni daŭre rakontas al vi kiel nia laserserĉo kun la detruo de la servilo estis aranĝita. Komencu en la antaŭa artikolo pri solvado de la serĉo.

Entute, la backend de la ludo havis 6 arkitekturajn unuojn, kiujn ni analizos en ĉi tiu artikolo:

  1. Backend de ludunuoj kiuj respondecis pri ludmekanismoj
  2. Backend kaj retejo-datuma interŝanĝo buso sur VPS
  3. Tradukisto de backend-petoj (ludelementoj) al Arduino kaj aparataro surloke
  4. Arduino, kiu respondecis pri kontrolado de la relajsoj, ricevis komandojn de la tradukisto kaj faris la realan laboron
  5. Faktaj aparatoj: ventumilo, girlandoj, plankaj lampoj, ktp.
  6. Frontend - la Falcon-retejo mem, de kiu ludantoj kontrolis aparatojn

Ni trarigardu ĉiun el ili.

Backend de ludunuoj

La backend estis efektivigita kiel printempa boto-aplikaĵo: ĝi havis plurajn ripozregilojn, ŭebsocket finpunkton kaj servojn kun ludlogiko.

Ekzistis nur tri regiloj:

  • Megatron. La nuna Megatron-paĝo estis sendita per GET-petoj: antaŭ kaj post ŝaltado de la potenco. La lasero pafis tra la POST-peto.
  • Mapante tildo-paĝojn por ke ili estu servataj per paĝonomo. Tilde produktas paĝojn por eksporto ne kun originalaj nomoj, sed kun internaj identigiloj kaj konformaj informoj.
  • Captcha-regilo por servi pseŭdo-alt-ŝarĝan servilon captcha.

Websocket finpunkto estis uzita por kontroli noviletojn: lampoj, girlandoj kaj leteroj. Ĝi estis elektita por sinkrone montri al ĉiuj ludantoj la nunan staton de la aparato: ĉu ĝi estas ŝaltita aŭ malŝaltita, aktiva aŭ ne, kia koloro de la litero estas nuntempe lumigita sur la muro. Por fari la taskon ŝalti la laseron iom pli malfacila, ni aldonis rajtigon al la girlando kaj la lasero kun la sama ensaluto kaj pasvorto admin/admin.

Ludantoj povus testi ĝin ŝaltante la girlandon kaj ripeti la samon per la lasero.

Ni elektis tian bagatelan ensalut-pasvortan paron por ne turmenti ludantojn per nenecesa elekto.

Por fari la taskon iom pli interesa, objektaj identigiloj de mongodb estis uzataj kiel aparataj identigiloj en la ĉambro.

ObjectId enhavas tempomarkon: du hazardaj valoroj, unu el kiuj estas prenita surbaze de la aparato-identigilo, kaj la dua bazita sur la pid de la procezo kiu generas ĝin kaj la nombrilo. Mi volis fari la identigilojn generitajn je regulaj intervaloj kaj kun malsamaj pid-procezoj, sed kun komuna nombrilo, por ke la elekto de lasera aparato-identigilo estus pli interesa. Tamen, finfine, ĉiuj komencis kun identigiloj, kiuj diferencis nur en la nombrila valoro. Ĉi tio eble igis la paŝon tro simpla kaj ne postulis analizon de la objectId-strukturo.

Tradukisto el backend-petoj

Python-skripto, kiu laboris pri tempigiloj kaj tradukis ilin de videoludadabstraktaĵoj en fizikan modelon. Ekzemple, "ŝaltu la plankan lampon" → "ŝaltu relajson N2."

La skripto konektita al la vosto de RabbitMQ kaj transdonis petojn de la atendovico al Arduino. Ĝi ankaŭ efektivigis la logikon de paralela lumŝanĝo: kune kun kelkaj aparatoj, la lumo sur ili estis ŝaltita, ekzemple, kiam potenco estis komence provizita al Megatron, ĝi estis lumigita per sceneja lumo. Luma dezajno por la kinematografio de la tuta sceno estas aparta rakonto pri la bonega laboro de nia projekta kunproduktanto kaj produktdezajnisto Ilya Serov, kaj ni rakontos pri ĝi en aparta afiŝo.

La tradukisto ankaŭ respondecis pri la logiko lanĉi la shredder uzante tempigilon kaj elsendante la bildon al la televido: la tempigilo por lanĉi la shredder, krieganta kapibaro, reklamvideo ĉe la fino de la ludo.

Kiel la logiko por generi la Megatron-ĵetonon estis strukturita

Prova pafo

Ĉiujn 25 sekundojn nova ĵetono estis generita kaj povus esti uzata por ŝalti la laseron dum 10 sekundoj ĉe 10/255 potenco. Ligo al github kun Megatron-kodo.

La lasero tiam malvarmiĝis dum 1 minuto - dum ĉi tiu tempo ĝi estis neatingebla kaj ne akceptis novajn pafpetojn.

Tiu potenco ne estis sufiĉe por bruligi tra la ŝnuro, sed ĉiu ludanto povis pafi Megatron kaj vidi la laserradion en ago.

La MD5-haĉa algoritmo estis uzata por generi la ĵetonon. Kaj la skemo funkciis MD5 el MD5 + nombrilo + sekreto por batalĵetono kaj sen sekreto por testĵetono.

MD5 estas referenco al komerca projekto, kiun faris Pavel, nia subtenanto. Antaŭ nur kelkaj jaroj ĉi tiu projekto uzis MD5, kaj kiam li diris al la projektarkitekto, ke ĝi estas malmoderna ĉifrada algoritmo, ili komencis uzi MD5 de MD5. Ĉar ni decidis fari la plej noob projekton ebla, li rememoris ĉion kaj decidis fari malgrandan referencon.

Batalpafo

La batalreĝimo de Megatron estas 100% lasera potenco je 3 vatoj. Ĉi tio sufiĉas dum 2 minutoj por bruligi tra la ŝnuro, kiu tenis la pezon, por rompi la akvarion kaj inundi la servilon per akvo.

Ni lasis kelkajn sugestojn pri la Github de la projekto: nome, la ĵeton-genera kodo, el kiu oni povus kompreni, ke la testaj kaj batalaj ĵetonoj estas generitaj surbaze de la sama nombrilo. En la kazo de batalĵetono, krom la kontraŭvaloro, ankaŭ estas uzata salo, kiu preskaŭ tute restas en la historio de ŝanĝo de ĉi tiu esenco, escepte de la lastaj du karakteroj.

Konante ĉi tiujn datumojn, eblis ordigi la lastajn 2 simbolojn de la salo kaj efektive ekscii, ke la nombroj de Lost, konvertitaj al la deksesuma sistemo, estis uzataj por ĝi.

Tiam la ludantoj devis kapti la nombrilo-valoron (analizante la testĵetonon) kaj generi batalĵetonon uzante la sekvan nombrilovaloron kaj la salon elektitan ĉe la antaŭa paŝo.

La nombrilo simple pliiĝis kun ĉiu prova pafo kaj ĉiujn 25 sekundojn. Ni ne skribis pri ĉi tio ie ajn, ĝi laŭsupoze estis malgranda ludsurprizo.

Captcha interaga servo

En la videoludada mondo, ĉi tio estis la sama captcha, kiu devis esti ŝarĝita por ŝalti la ventumilon kaj malfermi la paperfolion kun sugesto. Apud la fotilo estis tekokomputilo kun ŝarĝmonitorado.

Kiel kreiĝis la backend de hakerludo pri detruado de servilo

servo Mi kalkulis kion montri en monitorado kiel la nuna ŝarĝo: temperaturo kaj CPU-Ventilo. Metrikoj estis transdonitaj al la tempbaza datumbazo kaj tiritaj per grafana.

Se en la lastaj 5 sekundoj estis pli ol 50 petoj por montri la captcha, tiam la ŝarĝo pliiĝis per fiksa + hazarda nombro da paŝoj. La kalkulo estis ke 100% ŝarĝo povus esti atingita en du minutoj.

Fakte, estis pli da logiko en la servo ol estis montrita en la fina ludo: ni metis la monitoron tiel, ke nur la rotacio de la CPU-Ventilo estis videbla.

Komence de la serĉo ili volis lasi Grafan alirebla de la Falcon-retejo. Sed ĝi ankaŭ enhavis printempajn mezurojn de la raporto pri malantaŭa aplikaĵo, kiun ni ne havis tempon por forigi, do ni decidis bloki aliron al ĝi. Kaj prave - eĉ komence de la serĉo, iuj ludantoj divenis, ke la aplikaĵo estis skribita en la springboot kadro kaj eĉ elfosis la nomojn de iuj servoj.

Gastigado kaj datumbuso

Ilo por transdoni informojn de la backend al la retejo, la VPS-servilo sur kiu RabbitMQ funkciis.

La backend kaj datumbuso estis konservitaj nia VPS. Ĝia potenco estis komparebla al la komputilo, kiun vi vidis sur la ekrano: 2-kerna VPS kun du gigabajtoj da RAM. La tarifo estis ŝargita por rimedoj, ĉar la pinta ŝarĝo estis planita por nur kelkaj tagoj - jen kion faras niaj klientoj, kiuj planas ŝargi VPS dum mallonga tempo. Tiam montriĝis, ke la ŝarĝo estis pli alta ol ni atendis, kaj fiksa tarifo estus pli profita. Se vi faras serĉon, elektu la liniajn tarifojn turbo.

Por protekti la servilon kontraŭ DDoSa, ni uzis Cloudflare.

Indas diri, ke la VPS eltenis ĉion honore.

Arduino, kiu respondecis pri kontrolado de la relajsoj, ricevis komandojn de la tradukisto kaj faris la realan laboron

Ĉi tio estas pli la temo de la sekva artikolo pri la aparataro de la projekto: la backend simple sendis petojn por ŝalti specifan relajson. Okazis, ke la backend konis preskaŭ ĉiujn entojn kaj petoj de ĝi aspektis kiel "ŝalti ĉi tiun enton." Ni faris tion por frua testado de la retejo (ni ankoraŭ ne kunvenis ĉiujn Arduino kaj relajsojn), finfine ni lasis ĉion tiel.

Frontend

Ni rapide kreis la retejon sur tilde, ĝi daŭris unu labortagon kaj ŝparis al ni 30 mil sur nia buĝeto.

Komence, ni pensis simple eksporti la retejon kaj aldoni la logikon, kiun ni mankis, sed ni renkontis uzadojn, kiuj malpermesis al ni fari tion.

Ni ne estis pretaj malobservi la permesilon, do estis du ebloj: efektivigi ĉion mem aŭ kontakti Tilda rekte, paroli pri la projekto kaj peti permeson ŝanĝi la kodon.

Ni elektis la duan opcion kaj ili ne nur renkontis nin duonvoje, sed eĉ donis al ni jaron da senpaga komerca konto, pro kio ni tre dankas ilin. Estis tre mallerte montri al ili la retejo-dezajnon de Sokol.

Kiel rezulto, ni alfiksis js-logikon al la fasado por sendi petojn al elementaj aparatoj, kaj iomete ŝanĝis la stilojn de la butonoj por ŝalti kaj malŝalti ludelementojn.

Reteja dezajno

La historio de serĉoj, kiu valoras apartan ĉapitron.

Ni volis krei ne nur malmodernan retejon, sed absolute abomenan, kiu malobservas ĉiujn bazajn regulojn de dezajno. Samtempe, estis grave konservi kredeblecon: ĝi devis ne rompi la ENT-rakonton, pruvi la pretendon de la aŭtoro, kaj ludantoj devus kredi, ke tia retejo povus ekzisti kaj eĉ alporti klientojn. Kaj li alportis ĝin! Dum la ludo daŭris, ni estis kontaktitaj dufoje por krei retejojn.

Komence mi mem faris la dezajnon, provante inkluzivi pli da gifoj kaj brilaj elementoj. Sed mia dizajnisto edzo de 10 jaroj rigardis super lia ŝultro kaj malakceptis ĝin kiel "tro bona." Por rompi dezajn regulojn, vi devas koni ilin.

Kiel kreiĝis la backend de hakerludo pri detruado de servilo

Estas pluraj kolorkombinaĵoj, kiuj elvokas daŭran senton de abomeno: verda kaj ruĝa de egala riĉeco, griza kaj rozkolora, blua plus bruna. Fine ni decidis pri kombinaĵo de ruĝa kaj verda kiel bazaj koloroj, aldonis gifojn kun kato kaj elektis 3-4 fotojn de Sokolov mem el stoka foto. Mi havis nur kelkajn postulojn: mezaĝa viro, portanta malbone konvenan kostumon de kelkaj grandecoj tro granda kaj en pozo de "profesia studio-fota sesio". Por la testo, ili montris ĝin al amikoj kaj demandis "kiel vi ŝatas ĝin?"

Dum la disvolva procezo, mia edzo devis kuŝiĝi ĉiun duonhoron; la helikoptero ekflugis. Paŝao provis malfermi la programkonzolon al la plej granda parto de la ekrano dum li finis la fasadon - por protekti siajn okulojn.

Realaj aparatoj

La ventoliloj kaj lumoj estis muntitaj per solidsubstancaj relajsoj, por ke ili ne tuj enŝaltu plenan potencon - tiel ke la potenco pligrandiĝu paralele kun monitorado.

Sed ni parolos pri ĉi tio en la sekva afiŝo, pri la aparataro de la ludo kaj la reala konstruado de la retejo.

Restu agordita!

Aliaj artikoloj pri la serĉo por detrui la servilon

Kiel kreiĝis la backend de hakerludo pri detruado de servilo

fonto: www.habr.com

Aldoni komenton