Üdvözlet, utazók!

Már közel nyolc megamásodperc eltelt a Vanguard League of Legendses bevezetése óta. Ennek a felfoghatatlanul hosszú időtartamnak megvoltak a fénypontjai, a mélypontjai, és még egy Vanguard-cosplayer is jelentkezett (a divat magasiskolája). Most az első kettőről fogunk beszélni, tovább törekedve arra, hogy mi legyünk a PC-s játékok leghangosabb és a legátláthatóbb csalásellenes csapata. De mielőtt így tennénk, ráhangolódásként fontoljátok meg a Vanguard bevezetése előtt írt cikkünk elolvasását, ami felér egy 14 fogásos előétellel.

Indítsunk egy gondolatébresztő falatkával: amíg a Vanguard és a LoL integrálásának javításán dolgozunk (a csalók pedig a csalásaikat tökéletesítik), nem fogjuk újratárgyalni a technológia használatával kapcsolatos döntésünket. A csalás elleni módszerek a súrlódás és a hatékonyság közötti egyensúlyt keresik, és a görbén elfoglalt helyünk a bizonyíték arra, hogy a Riot mennyire komolyan veszi a versenyélményt. Az ingyenes modell túl sok leküzdhetetlen problémának néz elébe, ha a kitiltások nem tudják tartósan kiiktatni a rosszindulatú játékosokat az olyan viselkedésekért, mint a szándékos öngyilkosság, a bomlasztó magatartás és a rangnövelés. Megértjük, ha nem kedvelitek a kernelszintű csalásvédelmet, de nem fogjuk kivárni, hogy a PC platform elkezdjen megfelelő biztonsági funkciókat kínálni a játékaink támogatásához. Addig viszont őszintén hisszük, hogy a hatékony csalás elleni védelem a legjobb megoldás a LoL jövője szempontjából.

Oké, jöhet a többi fogás. Még egyszer bemutatkozom, „mirageofpenguins” vagyok, és én leszek a főpincéretek ma este. A kulináris tapasztalataim addig terjednek, hogy kilenc hónapnyi munka után kirúgtak a Subway lánctól, de annak már több mint egy évtizede, és azóta folyamatosan főzöm ki a friss csalásellenes megoldásokat a Riotnál.

A dolgok állása

Mint minden tisztességes szendvicsnél, a Vanguardnál is a kenyér került legfelülre. A LoL csalás elleni védelmének frissítésével számos kezdeti célkitűzésünk teljesült, néhányuk olyan jól, hogy vannak, akik a Vanguard 2 kiadásán gondolkodnak. Oké, senki sem gondolt erre (és a csalás elleni védelem frissítései kb. annyira szórakoztatóak, mint kesztyűt húzni egy macskára), de szerintem nem okoz meglepetést, hogy a LoL csalás elleni rendszerének korszerűsítése több téren is azonnali sikert hozott.

Kevesebb szkriptelő

A legalább egy szkriptelőt tartalmazó rangsorolt játékok, és a versenyjáték során kifejezetten „szkriptelésért” kiosztott kitiltások százalékos aránya. A legendák szerint annyira szeretem ezt a grafikont, hogy mindkét alkaromra rátetováltattam, és háromhetente visszamegyek a szalonba, hogy nagy fájdalmak közepette frissítsék őket az új adatokkal. Nagyon remélem, hogy hamarabb fogynak el a szkriptelők, mint a rendelkezésre álló hely.

Az első és legnyilvánvalóbb győzelem az, hogy sokkal kevesebb csaló van a játékban. Odafent látható a LoL rangsorolt játékának szkriptelési aránya a napi csalás elleni kitiltások mennyiségével összevetve, a kitiltást kiosztó rendszer alapján felosztva (a „Packman” a régi csalás elleni rendszer, a „Vanguard” az új). A szkriptelők számának azonnali csökkenése mögött javarészt a Vanguard megelőző funkciói állnak, de a „hardveres kitiltás” kategória egyértelműen szemlélteti, hogy további csökkenéseket értünk el azon csalók észlelésével, akik a Vanguard bevezetése után hősiesen tovább próbálkoztak, bátran feláldozva összes fiókjukat, hogy teszteljék, van-e kitiltási korlát a csalás elleni rendszerben (nem volt).

A Vanguard megjelenése óta több mint 175 000 fiókot tiltottunk ki csalásért, de ennél is fontosabb, hogy a rangsorolt szkriptelés aránya közel négy év óta először 1% alá esett. A cikk írása közben 200 rangsorolt játékból csak 1-ben van jelen szkriptelő, és úgy gondolom, végre zavartalanul le tudom játszani a besorolómeccseimet. Biztos, hogy így is a Vas II-ben kötök ki, fantasztikus 10%-os győzelmi aránnyal, de most már legalább csak Zedet tudom hibáztatni érte.

A kitiltások számának legújabb növekedését (július 8.) egy olyan jelenség okozta, amit a Riot „nyári szünetnek” nevez. A visszatérésünket hirtelen felszabaduló nyers csalásellenes energia kísérte: 48 óra alatt 35 000 szkriptelőt iktattunk ki. Sokan meglepődtek, hogy a csalás elleni csapat tagjainak szüksége van egyáltalán alvásra, de higgyétek el, a legtöbb tagunk közel 100%-ban emberi lény. Mi is szeretjük az olyan egyszerű örömöket, mint a fák nézése és a tápanyagok bevitele, így a pihenéssel töltött hét csak megerősítette az elszántságunkat.

Kevesebb bot

A bothasználat óráinak nyers száma, várólisták szerint lebontva. Helyes a feltételezés, hogy azért használtam az „óra” kifejezést, hogy a vezetők azonnal megérezzék a hatását a pénztárcájuk mélyén (a szerverköltségekben).

A második grafikon azt mutatja, hogy mennyi játékórát pazaroltak el idén a botok. A botoláshoz és a szkripteléshez használt szoftverek hasonlítanak, ezért a két kihágást elsősorban a játékos és a játékkliens teljesítménye alapján választjuk külön (például a botokat a tornyok ölik meg, és hajmeresztő teljesítményen, maximum 9 FPS-en játszanak). Natív adat nyelven ez valahogy így hangzana:

select date, game_mode, sum(minutes_in_game) * 60

from anticheat.detections

where client.resolution_x + client.resolution_y < 1000

and client.avg_fps < 15 fps

group by 1, 2

A Vanguard virtuális gépeket észlelő technikái mindenesetre rendesen megnehezítik az átlagos programozható kávéfőzők számára a League of Legends-játékmenetek lefőzését, és a napi 1 milliónál több botolással töltött órát 5 ezer alá csökkentették. Számos botfarm tartós érzelmi válságba került ettől, és ha játszottatok Emberek vs. MI meccseket, láthattátok is őket, miközben a gondolataikba merülve álldogálnak a forrásotokban. A botparalízis gyors kialakulása annak volt köszönhető, hogy nem futtatták a Vanguardot – és ha nincs Vanguard-munkamenet, nem lehet csatlakozni a kiszolgálóhoz. Néhány bot megpróbált visszasettenkedni régi OSX virtuális gépekről, de ezt desszertnek tartogatjuk a cikk végére (olvass tovább).

Röviddel a Vanguard bevezetése után 3,5 millió eladásra váró botfiókot is felszámoltunk, azzal a szándékkal, hogy lassan kiéheztetjük a másodlagos fiókok piacát. A botok fontos részét képezik a LoL versenyjátékát kizsákmányoló motornak – új törpefiókokkal látják el a rangnövelőket, amelyekről a vásárlóik mellett beléphetnek a várólistára, valamint új fiókokat biztosítanak a szkriptelőknek a „játékhoz”. Nem vagyok biztos benne, hogy ezek bármelyike is „játéknak” minősül, úgyhogy továbbra is éberen fogjuk figyelni az intelligens kenyérpirítókat, hogy maximálisra fokozzuk a többi büntetésünk okozta szenvedést.

Gyorsabb kitiltások

Egy pillanatra talán fellélegeztetek, remélve, hogy elvetettem a borzalmas szendvics hasonlatot, de mint minden küszködő író, én is elköteleztem magamat művészileg az irodalom és a táplálkozás mellett. Ennek fényében a következő ábrákra tekintsetek úgy, mintha majonéz lenne. A valódi majonézhez hasonlóan itt is ők képezik a szendvics lényegét.

A „Cselekvési idő” (balra) játékokban van mérve, az „Észlelési idő” (jobbra) pedig napokban. Az előbbi inkább azt méri, hogy milyen gyorsan távolítjuk el a rosszindulatú felhasználókat, az utóbbi pedig a sebességet vizsgálja, amellyel észlelni tudjuk az ismert csalásokat. Fontos megjegyezni, hogy az észlelés nem jelent azonnali kitiltást.

Fent, a bal oldalon látható az első számú csalásvédelmi teljesítménymutatónk, a „Cselekvési idő”, amit úgy kell értelmezni, mint azon játékok számát, amelyekben a csaló részt tud venni, mielőtt a fiókja összeolvadna egy olyan valósággal, ahol soha nem is létezett – egy téridőt összetömörítő algoritmusként, amelyet a háromdimenziós lények kitiltásként érzékelnek. A Vanguard jelentősen felgyorsította a szkriptelők LoL-ból való eltávolításának folyamatát, részben amiatt, hogy nem kell többé a LoL frissítési ütemtervére támaszkodnunk. A cselekvési időnk 45+ játékról kevesebb, mint 10-re csökkent, és még ez az apró késés is szinte teljesen szándékos, hogy a csalásfejlesztők lassabban „ébredjenek rá” arra, hogy körülvettük őket.

A jobb oldali grafikon az érme másik oldalát mutatja. Az „Észlelési idő” azt méri, hogy egy csalás (vagy egy csalás frissítése) mennyi ideig képes rejtőzködni a LoL ökoszisztémájában, mielőtt papírra vetnék az észlelését, és elégetnék az öntudatra ébredt Vanguard Cloud oltárán. Ezt úgy tudjuk megbecsülni, hogy megnézzük, az új észlelés feljegyzésekor (amikor feltehetőleg „először megjelent”) elsőként azonosított fiókok és a hardverkombinációk közül melyik a legrégebbi (napokban kifejezve). Jelenleg nagyon gyorsan működünk, de a csalások jobb rejtőzködésével és fejlődésével hosszabb időbe fog telni a megtalálásuk és az észlelésük létrehozása. A csalás elleni technológia egyensúlya igencsak kényes: nem részesíthetjük előnyben a „cselekvést” a csalók frissítéseinek felgyorsítása és az „észleléseink” lelassítása nélkül.

Azokat a csalókat, akik a Vanguard után is képesek csalásra adni a fejüket, általában nem érdekli a fióktulajdonlás és az igazságos játék elve. A közösségüket általában más csalók alkotják, csalás útján érintkeznek a játékkal, és ezen csak az idő múlása és a serdülőkor változtathat. Addig csak annyit tehetünk, hogy igazodunk hozzájuk, és az újbóli azonosításuk sebessége tükrözi, hogy mennyire hatékonyan tudjuk rákényszeríteni őket az újrakezdésre.

Egyéb „érdekes” változások

Az a Zeri-eltérés lehet, hogy jól mutat, de hadd emlékeztesselek rá titeket: a csalás egyirányú út Kitiltásvárosba, ahol az adókulcs az éves fiókok 100%-a.

A fenti felület a 9 legnépszerűbb szkriptelős hős olyan változásait követi nyomon, amelyek a Vanguard bevezetéséből adódhatnak. Mivel a szkriptek az embereknél gyorsabban tálalják az egérkattintások gazdag svédasztalát, a legtöbb ilyen hős lövész. A bal oldalon látható idővonal azt mutatja, hogy mennyivel gyakrabban győz egy hős csalás esetén, mint anélkül (a rangsorolt győzelmek arányának különbsége a szkriptelők és a normál játékosok között), a jobb oldali grafikon pedig ugyanazon hős győzelmi arányát mutatja 60 nappal a Vanguard bevezetése előtt és után. A versenyképes minta biztosításához az azonosított hős játékosa minden itt feltüntetett játékban Platina vagy magasabb osztályba tartozott.

Örömteli dolgot láthattok, ha engeditek, hogy a fotonok az ábráról visszaverődve megérkezzenek a retinátokra: a csalók teljesítménye lassan ugyan, de romlásnak indult. Rengeteg tényező befolyásolja ezt, de az MVP a Vanguard, ami különösen bosszantóvá teszi a „belső” csalások érzékelhető minták közvetlen alkalmazása nélküli használatát, így sok csaló vagy (1) a manuális játék, vagy (2) a „külső” csalástípusok felé fordul. Ahogy arra a cím is utal, ez utóbbi csalások nem tudják olvasni a játék memóriáját, így a képernyő olvasásával szerzik meg az adatokat, majd megpróbálnak a csaló helyett beviteli adatokat továbbítani. Röviden összefoglalva… nem túl ügyesek.

Emellett a szkriptelők számának (és a szkriptelés hatékonyságának) csökkenése még a népszerű szkriptelős hősök általános győzelmi arányára is hatással van. Nehéz irányítani, ha olyan dolgokról van szó, mint a játékegyensúly-módosítások, a szezonális visszaállítások és a népszerűvé váló hősök elleni célzott hősválasztások, de a csökkenések néhány százaléka mögött az áll, hogy a csalóknak nehezére esik a Gyémánt osztályban tartani a fiókokat. Nagyon fel tud dobni ez a gondolat.

Minimális számú téves riasztás

Minden új csalás elleni rendszernél felmerülhet a csalásnak „tűnő” szoftvereszközök megjelölésének kockázata (ezek általában rosszindulatú programok vagy más játékokhoz készült csalások), de a Vanguard szerencsére már nem számít „újnak”: idén lett négy éves. Vessünk egy pillantást a szendvicsünk utolsó hozzávalójára (most jövök rá, hogy szendvicsünket két majonézbe áztatott ciabatta szelet alkotja), a Vanguard tévesriasztás-arányára a LoL-nál.

Érdemes megemlíteni, hogy „a bátyám leguánja szkripteket telepített a gépemre” kifogást jelenleg nem fogadjuk el a csalásoknál, de a gyakori előfordulása miatt kezdjük azt hinni, hogy a „Godzilla” franchise megjósolta a jövőt.

A fent látható bal oldali tengely a Vanguard visszavont felfüggesztéseinek százalékos arányát mutatja (sávok), a feloldás oka alapján felosztva, a jobb oldali tengely pedig ugyanaz a bontás, csak a fiókok felfüggesztésének általános időtartamát vizsgálja (vonalak). Háromféle visszavonás szerepel rajta, amelyek a megjelenésük sorrendjében:

1. Olyan fiók, amely el volt lopva a csalás észlelésének időpontjában (nem szándékosan osztották meg másokkal).

2. Olyan fiók, amely korábban kitiltott hardver kölcsönzése vagy vásárlása miatt zárolva volt.

3. Olyan fiók, amely egy nem kimondottan LoL-os csalásra szolgáló eszköz vagy viselkedés miatt volt kitiltva.

Az utolsó feltételt tekintjük „valódi” téves riasztásnak, és ennek aránya eddig összesen 0,01% alatt van, azaz 10 000 kitiltásonként kevesebb, mint 1 alkalommal fordul elő. Ennél is jobb, hogy az ártatlan fiókok felfüggesztésének átlagos időtartama 72 óránál kevesebb volt. A Vanguard bevezetésekor módosítanunk kellett néhány szabályt, hogy jobban igazodjunk a LoL atipikus mintáihoz (más játékokkal való párhuzamos játék), de azóta viszonylag zökkenőmentesen működik. Továbbra is teljes mértékben elkötelezettek vagyunk a büntető intézkedéseink pontossága iránt, és a Vanguard szabályait folyamatosan felülvizsgáljuk, hogy minimalizáljuk a járulékos károkat.

Mindezek ellenére a csalóknak továbbra is fiókokra van szükségük a csaláshoz, így az „ellopott fiók” kategória magasan vezeti a mezőnyt. Míg a játékostámogatás időként kivételt tesz az olyan fiókoknál, amelyeket egyértelműen feltörtek, néha nem lehet megállapítani, hogy ki volt a fiók eredeti tulajdonosa, főleg akkor, ha sokáig szándékosan meg volt osztva másokkal. Azzal, hogy bevezettük a LoL-ban a Vanguardot, sok fiók-tulajdonostárs értesült bajtársának csalási hajlamairól, de valójában nem sokat tudunk tenni, ha két vagy több játékos is rendelkezik egy közös fiók felett.

Ne oszd meg a fiókodat, ne használd újra a jelszavaidat, és kérlek, engedélyezd a többtényezős hitelesítést.

A nehezebb témák

Az emberek körülbelül 0,0%-át tölti el örömmel a kötelező csalásvédelem telepítésének ötlete, így valószínűleg senkit sem lep meg, hogy a Vanguard csapata nem éppen vörös szőnyeges fogadtatást várt a LoL-nál. A Vanguard egy meglehetősen összetett termék, amely szinte teljes átláthatatlanságban működik. Ennek nagy része szükséges ahhoz, hogy hatékony legyen a csalókkal szemben, akik akár csak egy kicsivel is többet szeretnének érteni belőle, de ugyanez az átláthatatlanság teszi a Vanguardot egy rendkívül látható célponttá, amely nem mindig kínál magyarázatot. A következő pár szakasz egy kicsit technikailag intenzív lesz, de maradj velem, és együtt átvágunk rajta.

Sebezhető illesztőprogramok blokkolása

A Vanguard célja nem az, hogy egyfajta folyamatosan felügyelő rendőrállam legyen, hanem az, hogy az eleve meglévő biztonság jelvényeként működjön a rendszeren, amelyen futtatják. Azáltal, hogy a Vanguard védvonalat húz a Windows kernele köré, lehetővé teszi, hogy kevesebb információt kérjünk le olyan rendszerektől, amelyeknél nem sérült a Windows natív védelme, és amelyek még mindig ismerten biztonságos állapotban vannak.

A csalásvédelmünk hálózati kapcsolat nélkül valósítja meg ezt a védvonalat azáltal, hogy az illesztőprogram-összetevője az operációs rendszer indulásakor indul, megakadályozva ezzel, hogy a csalások más illesztőprogramokat „versenylóként” használva elérjék a rendszermagot, ahol aztán korlátlan ideig elrejtőzhetnek minden utánuk betöltő eszköz elől. A gyakran „Ki tölt be először?” nevezetű probléma esetében a Vanguard egyszerűen azáltal biztosítja, hogy ez nem történhetett meg a rendszerindítás óta, hogy még mindig jelen van, amikor a játék elindul.

A Vanguard a következő dolgokat blokkolja:

1. Sebezhető illesztőprogramokat, amelyek a jogosultságok kiterjesztésével visszaélve kódot juttathatnak a kernelbe.

2. Viszonylag régi illesztőprogramokat olyan tanúsítványokkal, amelyekben az egyik aláírás nem rendelkezik időbélyeggel.

3. Olyan illesztőprogramokat, amelyeket kifejezetten csalásra használnak, és amelyeket magukat törvényes szoftvercégnek álcázó csalásfejlesztők írtak alá.

A második eset a leggyakoribb, de a régi tanúsítványok engedélyezésével az a probléma, hogy sokukat a csalók ellopták. A legtöbb esetben ez egyszerűen megoldható az érintett illesztőprogram újabb verziójának letöltésével, de néha a fejlesztők már rég továbbléptek. Még ha meg is tehetnék, a régi aláírások visszavonása megakadályozná, hogy a törvényes felhasználók valaha is futtathassák az általuk aláírt szoftvereket, ezért a Vanguard ehelyett akkor blokkolja az ilyen tanúsítványokkal rendelkező illesztőprogramokat, amikor aktív. A Vanguardot egyébként is bármikor ki lehet kapcsolni, hogy betölthesd őket, de ahhoz, hogy Vanguarddal játszhassunk, nekünk tudnunk kell, hogy a rendszerindítás óta semminek sem volt esélye kompromittálni a Windowst.

Bootlooping

Egy nemrégiben történt tömeges bootlooping (újraindítási ciklus) esemény világszerte aggodalmat keltett az operációs kernel-illesztőprogramok potenciális veszélyeivel kapcsolatban, és bár az eset kétségtelenül ijesztő volt, a Vanguardot nagyrészt nem fenyegeti ez a legrosszabb forgatókönyv. Számos megkülönböztető és közvetlen enyhítő tényező játszik itt szerepet.

Rendszerindítási különbségek

A Microsoft által tanúsított kártevőirtó komponensek rendelkeznek az ELAM jogosultsággal, és ezzel együtt azzal a kiváltsággal, hogy előbb, a „boot” rendszerindításkor töltik be az illesztőprogramjukat, mint a Vanguard, amely a „system” rendszerindításkor teszi ezt (a figyelmes olvasók talán felismerik, hogy ez a „Ki tölt be először?” fegyverkezési verseny természetes fejleménye). De ami ennél is fontosabb, hogy sok kártevőirtó illesztőprogram dinamikusan, futásidőben, egy távoli kiszolgálóról hívja le a konfigurációs blobokat, anélkül, hogy az illesztőprogramot újra kellene építeni és hitelesíteni. Az ilyen tervezés jelentősen felgyorsítja a fenyegetésekre való reagálást, de az adatokat helyben is megőrzi, hogy minden egyes inicializáláskor felhasználhassa, és így a visszavonhatatlan frissítések lehetővé tételével veszélyforrást jelenthet, ha bármelyik konfiguráció olyan versenyállapotot eredményezne, amelyben az operációs rendszer összeomlása előtt nem lehetséges új blobokat letölteni. Egy dinamikus, rendszerindításkor induló illesztőprogram jelentősen megnövelte volna a kockázatfelületet, és a Vanguard csapata úgy gondolta, hogy enélkül jobban fogunk aludni.

Statikus kód

A Vanguard illesztőprogramja (VGK.sys) ehelyett nem csinál semmit dinamikusan az indításkor: az egész statikus kód. A Vanguard klienskomponensét (VGC.exe) használjuk arra, hogy az illesztőprogramban lévő funkciókat távolról aktiválja kizárólag akkor, amikor aktívan játszunk. A konfigurációkat nem tároljuk, nem változtatjuk meg, és nem tároljuk az illesztőprogram következő indításakor, és ha valaha is kritikus hiba lépne fel, egyszerűen leállítjuk az érintett konfiguráció küldését, és az illesztőprogramot a következő újraindításkor visszaállítjuk a statikusan passzív állapotba. A Vanguard illesztőprogram-összetevője maga nem rendelkezik hálózati kapcsolattal, és a kliensnek kapcsolatot kell létesítenie a platformmal, mielőtt bármit is aktívan „csinálna” azon túl, hogy blokkolja az utána betöltődő sebezhető illesztőprogramokat.

Egyszerű biztonsági mechanizmus

Néhány vállalkozó kedvű fiatal mérnök már részletezte ezt a folyamatot, de a Vanguard illesztőprogramja rendelkezik egy éberségellenőrző kapcsolóval a vgkbootstatus.dat fájl formájában. Amikor a Vanguard először elindul, ellenőrzi ennek a fájlnak az állapotát, és ha nem az áll benne, hogy „elindítva”, akkor az illesztőprogram biztonságosan kilép. Ellenkező esetben az említett fájl állapotát „indítás” állapotba teszi, és amint az előindítás sikeresen befejeződik, ugyanezt ismét „elindítva” állapotra állítja. Alapvetően, ha a VGK.sys elindítása nem sikerülne, a fájl továbbra is „indítás” állapotot jelezne, és az illesztőprogram nem futna újra, amíg nem frissül (egy Riot-alkalmazás elindításával vagy a Vanguard szándékos újratelepítésével).

„Vanguard-esemény” a közeledben

A Vanguard integrációi a LoL-lal egy kicsit egyediek, ezek közül a legfőbb, hogy a csalásellenes munkamenet akkor jön létre, amikor a könnyű asztali kliens elindul, nem pedig akkor, amikor a játékkliens (mint a VALORANT). Ez a csalásvédelem szempontjából furcsa, és egy megtévesztően egyszerű kihívással jár: a játékosok gyakran hagyják futva az asztali klienst. Ez azt jelenti, hogy (1) a számítógép alvó módba léphet, miközben egy LoL-munkamenet aktív, és (2) egy munkamenet általában lezárja a másikat (pl. az otthoni és a munkahelyi számítógép között).

Sajnos a LoL és a Vanguard integrációja nem kezelte ezeket az eseményeket, és mivel minden fióknak egyszerre csak egy Vanguard-munkamenete lehet, a végeredmény az, hogy a játékosok Vanguard nélküli állapotba kerülnek. Ha tehát játékban voltál, és egy második számítógép újból bejelentkezett a Vanguardba, akkor ki lettél rúgva a szerverről, mert már nem volt csalásvédelmi munkameneted. Hasonlóképpen, ha játékkeresés közben vesztetted el a munkamenetedet, lehet, hogy nem kaptál erről értesítést, amíg át nem jutottál a betöltő képernyőn, és ki nem rúgtak, ami a meccs újrajátszásának brutális élményét és az ebből eredő LP-veszteséget jelenthette.

A Riot ezt nagyon elszúrta, és bár a gyors megoldás a logisztika újraengedélyezéséhez szükséges javítások voltak, a LoL egy munkamenet-ellenőrzést is beiktat a meccskeresésbe, hogy 300%-ig biztos legyen abban, hogy ez nem történhet meg újra. Ha követtétek a csalhatatlan vacsora-metaforámat, ezt a fogást leginkább úgy lehetne leírni, mint a spagettit, és bár ez a Riot jellegzetes fogása, szeretnénk megelőzni azokat a körülményeket, hogy bárkinek is ennie kell belőle.

Ó, és még valami...

Végezetül még egy pillanatra elrablom a tekinteteteket, hogy szót ejtsek három másik, korábban felmerült kérdésről, arra az esetre, ha a Google elég jól indexeli ezt az oldalt ahhoz, hogy az érdekelt felek rábukkanhassanak. Mint mindig: a legjobb módja annak, hogy segítséget kapj, ha küldesz egy hibajegyet.

Beviteli lag vagy képkockasebesség-csökkenés

Számos olyan külső forrásból származó alkalmazás (modok, átfedők vagy passzív teljesítménytesztelő eszközök) létezik, amelyek néha könnyelműen megpróbálnak bizonyos információkat kinyerni a LoL-kliensből, és most, hogy a játékot a Vanguard védi, ezek a műveletek elkerülhetetlenül meghiúsulnak. Egyértelműen nem akarjuk, hogy a dolgok zavarják a játékot, ezért a blokkoló viselkedés 100%-ban szándékos. Azonban az a mód, ahogyan bizonyos alkalmazások a Windows-műveletek meghiúsulását kezelik, a probléma csendes figyelmen kívül hagyásától kezdve az ismételt, mindenféle késedelem nélküli újrapróbálásig terjedhet, amit a mi oldalunkon szinte lehetetlen kezelni. Tehát, ha tudod, melyik alkalmazás a hibás, és még nem rendelkezik engedélyezési mechanizmusokkal a LoL.exe kivételek hozzáadásához, akkor a következő csalással megakadályozhatod, hogy az alkalmazás magát a LoL.exe-t próbálja manipulálni.

A TPM 2.0 engedélyezése

Azt tapasztaltuk, hogy a TPM 2.0 megkövetelése a Windows 11 rendszeren zavart okozhatott néhány játékosnál, amikor a BIOS-ba mentek, hogy engedélyezzék azt. A BIOS beállításai gyártótól függően nagyon eltérőek lehetnek, és pontosan két ismert esetben a játékosokat a rendszer arra is felszólította, hogy a TPM engedélyezéséhez váltsanak UEFI módra, annak ellenére, hogy a meglévő Windows telepítésük Master Boot Record (MBR) partíciós tábla stílusú volt. Sajnos az UEFI mód támogatásához a Windowst a GUID partíciós tábla formátumot (GPT) használó lemezre kellene telepíteni, különben a rendszer indíthatatlanná válhat. Bár ezt a Windows 11 eredeti telepítésekor kellett volna megoldani (ahogyan azt a Microsoft is megköveteli), a Vanguard kikényszerítette a dolgot néhány játékosnál, akik megkerülték a Microsoft eredeti TPM 2.0 ellenőrzéseit.

Ha megpróbálod engedélyezni a TPM 2.0-t a mostanában megkövetelt csalásvédelmek bármelyikéhez, illetve tudod, hogy rád is vonatkozik ez az MBR-forgatókönyv, és olyan adataid vannak, amelyeket nem akarsz elveszíteni egy egyenes újraformázás során, a Microsoftnak van egy eszköze, amely potenciálisan lehetővé teszi a lemez GPT-re való átalakítását anélkül, hogy bármilyen adatot törölne.

Különleges hardveres interakciók

Az illesztőprogramok fejlesztése különösen trükkös lehet, amikor az OEM-ek vagy a gyártók véletlenül hibás firmware-t telepítenek vagy frissítenek az eszközök egy részén. A kompatibilitási laboratóriumban megpróbáljuk ezt megelőzni, de vannak olyan dolgok, amelyekre ténylegesen nincs ráhatásunk. Ha még mindig véletlenszerű kék képernyők gyötörnek, és 13. vagy 14. generációs Intel processzorod van, akkor nagy valószínűséggel egy elavult firmware-rel rendelkező eszközzel van dolgod. Az Intel dolgozik a széleskörű problémák megoldásán.

A LoL csalásellenes rendszereinek jövője

A csalás elleni küzdelemnek sosincs vége, és bár a Vanguard csökkentette a felületünket és növelte a bejutási korlátot, a csalók mindig új módszerekre vadásznak, hogy tisztességtelen előnyre tegyenek szert. Íme néhány dolog, amit azért főzünk, hogy ők biztosan éhen maradjanak.

Feltöltődés

Míg sok csalásfejlesztő bedobta a törülközőt, örömmel jelentjük, hogy többen nem vették a lapot, és alig várjuk, hogy még több Vanguardot kapcsoljunk be, hogy legyen mivel bajlódniuk. A tiltások eddig csak aperitifként szolgáltak, és rendkívül biztosan vagyunk abban, hogy konyhánk felkészült erre a vacsorára. Sok csaló gyakran megreked a gyász folyamatának „tagadás” szakaszában, ezért úgy gondolunk minden egyes tiltásra, mint egy égő lekapcsolására a remény csillárján. Azzal, hogy fokozatosan hagyjuk, hogy minden csalót elnyeljen a teljes sötétség, végül elérhetik az igazi megvilágosodást.

„Igény szerinti” Vanguard

Ahogyan azt megjövendölték, előbb-utóbb eljön a jövő, ahol a Windows biztonsági funkciói megbízhatóan védeni fogják a saját kerneljét, ahelyett, hogy egy illesztőprogrammal kellene védenünk a rendszerindítástól kezdve. Ez lehetővé fogja tenni számunkra, hogy a játékkliens futtatásakor indítsuk el a csalás elleni szolgáltatásainkat, feltéve, hogy a végfelhasználó mindezeket a funkciókat engedélyezte. Jövő év elején több közlendőnk is lesz a témában, de ha Windows 11-et és viszonylag új hardvert használsz, szerettük volna tudatni veled, hogy nem kell örökké tűrnöd a tálcán szereplő ikont (bár a Vanguard logóján nagyon sokat dolgoztunk).

MKP-növelés észlelése

Az MKP-növelés arra a viselkedésre utal, amikor valaki szándékosan játszik alacsonyabb besorolású fiókokkal (vagy fiókon), hogy növelje a ranglistán elfoglalt helyezését. A detektálás olyasvalami, amihez a csalás elleni csapat 2018 óta nem nyúlt hozzá, és rendkívül izgatottak vagyunk, hogy most már elegendően kifejlett az azonosítási technológiánk, hogy ismét foglalkozzunk vele. Azt tervezzük, hogy az erőfeszítéseink nagy részét itt a frissen rangjavesztett törpefiókos ügyfelekkel együtt játszó MKP-növelők felderítésére összpontosítjuk, és ezeket a fiókokat a szezon maradékára érvényes kitiltással jutalmazzuk (1. réteg). Azok a játékosok, akik ismételten együtt játszanak az ilyesfajta büntetést elszenvedő MKP-növelőkkel, szintén hasonló szabadságra mehetnek (2. réteg). Ha valaki elég bátor lesz ahhoz, hogy teljes mértékben megossza a fiókját egy MKP-növelő szolgáltatással, azt hasonlóképpen törpefiókként fogjuk észlelni (lásd: 1. réteg), ezzel gyakorlatilag lezárva a kört.

Még sok munkánk lesz ezen a téren, de terv szerint jövő nyárra már teljes gőzzel fog haladni ez a hajó is.

A Mac és a Vanguard (vagyis Vanguard 2)

Ahogy a botokról szóló részben is említettük, néhány csaló elkezdett macOS-es virtuális gépekre váltani, hogy megszabaduljon a Vanguardot érintő követelménytől. Ez a lépés körülbelül annyira váratlan volt, mint a sajt a pizzán, ezért örömmel jelentjük be, hogy a Vanguard társterméke, a beágyazott Vanguard (mVG) hamarosan megérkezik egy közeli Mac buildre! A macOS környezetének egyedi biztonsága lehetővé teszi számunkra, hogy egy kicsit kevésbé szigorúan felügyeljük a kernelét, így ahogy a név is mutatja, nem lesz szükség semmilyen extra telepítésre: a biztonság közvetlenül a játékkliensbe van „beágyazva”. Az mVG-t emellett már most is hatékonyan használjuk a VALORANT konzolos verzióján és a Wild Riftben.

Amint az idei év végén megjelenik, reméljük, hogy ez jelenti a végső csapást a botok és a két nyilvános szkriptcsomag fejlesztője számára, akik most azzal a felismeréssel küzdenek, hogy három hónapot pazaroltak el a csalások OSX-re való portolásával. Azért ne aggódjatok túlságosan, a Swift jól fog mutatni az önéletrajzban.

Végszó

És most barátaim, vissza kell térnünk a sötét csalásellenes konyhába, hogy elkészítsük a következő fogást. De ne aggódjatok, mi mindig harcolni fogunk azért, hogy a versengés mentes lehessen a csalóktól, akik nem hajlandóak a jó útra térni. Nem minden évtizedben akad lehetőség egy olyan játékon dolgozni, amely a csalásgátló rendszerek négy különböző iterációján ment keresztül, de mérhetetlenül örülök, hogy a LoL mára a legjobbak közé tartozik. Öröm volt veletek együtt játszani, írni és csalókat tiltani.

U.I.: Azóta újraolvastam ezt a cikket, és elképzelhető, hogy éhes voltam, miközben írtam...