/dev/null: Kernel-illesztőprogram csalás ellen

Figyelmeztetés: ebben a cikkben sok technikai részletről lesz szó, és az ismertetett csalás elleni eszközöket nem csak a League of Legendsben fogjuk használni. Ez a védelem a LoL előtt más játékokban fog bemutatkozni (például az Project A-ban).

Egy több szervezet részvételével 8 év alatt, a szövetségi kormány 20 millió dolláros támogatásával elvégzett vizsgálatban a szakterület legkiválóbb szakértői megállapították, hogy az első csalásra valamikor i. e. 3,5 milliárd és 1985. november 20-a között került sor. A pontos eredetét nem sikerült megállapítani, de elfogadott tudományos tény, hogy mindig lesznek csalók.

Az elmúlt két évtizedben sokat fejlődtek a csalások és az ellenük fellépő technológiák. Eleinte a játékkliens által lefoglalt memória fölötti irányítás volt a nemes harc tétje, ma viszont már a csaló játékos operációs rendszerét és néha a hardverét is módosítják. Így akarják megakadályozni, hogy a csalás elleni rendszerek megfelelő adatokhoz jussanak, különösen, ha a csalás elleni védelmet felhasználói üzemmódban kell futtatni.

Mi az a felhasználói üzemmód?

Ez egy jogosultsági szint az operációs rendszerben, a legszigorúbban korlátozott szint, amelyen szoftvert lehet futtatni. A webböngésző, a jogtiszta WinRAR-példányok és a kedvenc játékaid mind felhasználói üzemmódban futnak. Ezen a szinten az alkalmazások általában nem „látják” a saját magukon kívüli adatokat, ezért a kód általában az operációs rendszer natív API-jain keresztül olvassa és írja a memóriát, nem a saját folyamatai keretében. Egy többé-kevésbé érthető metaforaként: mi (felhasználói üzemmódban) csak a konyhától (Microsoft Windows) tudjuk megkérdezni, hogy mi került a gulyásunkba (League of Legends).

Ha valami okos gyerek azt írta neked, hogy „lol, a csalásomat nem észleli a 0. gyűrű”, akkor erre próbált célozni, mielőtt kitiltotta a rendszer.

Az elmúlt években a csalások fejlesztői sebezhetőségeket kihasználva vagy a Windows aláírás-ellenőrzését megtévesztve kezdték futtatni az alkalmazásaikat (vagy azok egy részét) a kernelszinten. Ezzel az a gond, hogy a rendszermag módban futtatott kód eltérítheti azokat a rendszerhívásokat, amelyekből az adatokat szerezzük, gyakorlatilag úgy módosítva az eredményeket, mintha minden rendben menne, így nehéz észlelni a csalást. Olyan esettel is találkoztunk, amikor egy speciális hardver DMA¹ alkalmazásával olvasta és dolgozta fel a rendszermemóriát... ami tökéletes kivitelezés mellett észlelhetetlenné² teszi a módszert felhasználói üzemmódban.

Bár a játékosok nagy része nem hajlandó ilyen szinten belepiszkálni a Windowsba, ijesztően sokan vannak, akik látszólag lelkesen vetik bele magukat valaki más botnetjébe, ha cserébe előnyhöz jutnak a játékban. Vagyis a csalások jelentős része ma már magasabb jogosultsági szinten fut, mint a csalás elleni alkalmazások. Fordítsuk le mindezt a szívfájdítóan gyönyörű konyhaanalógiánk nyelvére: Amikor megkérdezzük a főszakácsot, hogy a gulyáshoz kizárólag biotermelésből származó hozzávalókat használtak-e fel, az utcáról besétált kötényes csávó int a vezetőségnek, hogy „majd ő intézi”, majd közli velünk, hogy „minden oké, láss csak neki.”

¹ A DMA a Direct Memory Access (közvetlen memória-hozzáférés) rövidítése: ezek a hardverek a Windows API-t megkerülve, közvetlenül férnek hozzá a memóriához. Egyes, komolyabb szakmai hátterű csaló közösségek már használtak ilyet a memória másik számítógépre való „átsugárzására” későbbi felhasználásra és az ESP megtévesztésére.

² Egyből alkalmaztuk a technika kidolgozóját, hogy segítsen észlelhetővé tenni.

De miért írjuk mindezt le?

Eddig a kedvenc csalás elleni csapatod kénytelen volt a felhasználói szinten játszani, így a csalók kényelmes előnnyel vághattak neki a versenynek. Eddig azért nem ütött be a krach, mert fix fizetést kapunk, és akkor megyünk aludni, amikor akarunk. Bár rendkívül szórakoztató alkalmazásbiztonsági állóháborút folytatni néhány tizenévessel, nemsokára több játékból álló portfóliót[1] kell kezelnünk, így nyolcórás munkanapok és tartós alvásmegvonás mellett nem lesz fenntartható az eddigi stratégia.

Ezért a Riot egyes későbbi címeit kernel-illesztőprogram fogja védeni.

Akkor most kezdhetek pánikolni?

Egyáltalán nem, el is mondom, miért

1. Egyrészt a stressz fokozott hajhulláshoz vezet, és nem szeretném, hogy fázzon a fejed.
2. Ezzel nem fogunk a korábbinál több felhasználói adathoz hozzájutni. Ha a nagymama titkos karácsonyi bejglireceptjeire fájna a fogunk, azokat felhasználói üzemmódban is könnyedén el tudnánk érni, hogy aztán eladhassuk a Paprika TV-nek. Ezzel a fejlesztéssel azt ellenőrizzük, hogy nem sérült-e a rendszer épsége (és így az adatok megbízhatósága), megnehezítve a csalók dolgát, hogy belenyúljanak a játékainkba. Így senki se foghatja aimbotokra, ha kikapott.
3. De nem is ez a legfontosabb változás. Számos csalás elleni védelmet nyújtó külső rendszer (pl. EasyAntiCheat, Battleye és Xigncode3) már ma is kernel-illesztőprogramokkal védi a kedvenc, nagyobb játékaidat. Beállítjuk a magunk főszakácshelyettesét a Windows konyhájába, hogy ha megkérdezzük, gluténmentes-e ez a kifli, biztosan őszinte választ kapjunk.
4.  Így sokkal nehezebb lesz észrevétlenül csalni, a becsületes játékosokat megvédjük az aimbotoktól, magunkat a Reddittől, a csalókat pedig önmaguktól.

A csalás elleni védelem az online többjátékos élmény egyik legfontosabb eleme, és szerintünk alapvető fontosságú, hogy soha ne kelljen kételkedned az ellenfél játéktudásában. A csalókra nincs igazi gyógyír, mi viszont továbbra is folyamatosan azon dolgozunk, hogy a legjobb versenykörnyezetet biztosítsuk számotokra.

Adás vége. Megközelítőleg négy megamásodperc múlva visszatérek, hogy az ARAM-beli botokról beszéljek díjnyertes novellánk, „A csalók eltávolítása a LoL-ból ” folytatásában.