Ich würde es sehr begrüßen, wenn wir auch eine Verpflichtung hätten, dass Beiträge die einzig und alleine auf Informationen derjenigen Stelle beruhen, über die berichtet wird, ebenfalls als solche gekennzeichnet werden: als PR. Wir haben klaren Regeln die vorschreiben, dass bezahlte redaktionelle Beiträge, und so liest er sich eben, eindeutig als "Anzeige" gekennzeichnet werden müssen.
Hätte Valve einen entsprechenden Artikel zum Zustand von VAC und der Cheater-Situation in Counter-Strike veröffentlicht muss man demnach annehmen, dass die Redaktion mit ihrem Artikel zu dieser Publikation Counter-Strike quasi als Cheater-frei deklariert hätte. Etwas, worüber sich jeder Mensch der CS2 im Premier-Matchmaking spielt, unabhängig ob man mit einem Elo-Rating von 1.000, 10.000 oder 20.000 unterwegs ist, sehr wundern würde.
Statt lediglich die PR eines Unternehmens aufzugreifen und ungeprüft wiederzugeben und den Inhalt damit als Tatsache darzustellen hätte ich mir gewünscht, wenn die Redaktion versucht hätte, diese Aussagen zu verifizieren und damit einzuordnen. Man muss nicht tief in der Szene drinnen sein. Es reicht ein Account in der Unknowncheats-Community um sich einen Eindruck bilden zu können, wie es um die Anti-Cheat-Maßnahmen eines Herstellers wirklich aussieht.
Wenn man bereits in so einer öffentlichen Community für wenig Geld alles zu bekommen scheint, muss man zu Private-Cheats gar nicht erst recherchieren. Um einen Recherche-Ansatz zu liefern: Sowohl Vanguard, welches bei Valorant eingesetzt wird, wie auch FaceIt, welches man Alternativ zu VAC für Counter-Strike verwenden kann, gelten wie EA's Javelin als Anti-Cheat auf Kernel-Ebene. Doch scheinbar gibt es einen Unterschied zwischen den drei Lösungen, welcher selbst einem Laien auffallen sollte:
Nach der Erstinstallation von Vanguard oder FaceIt ist ein Neustart des Computers erforderlich, um die Integrität des Systems zu gewährleisten. Solange man sein System nicht neu gestartet hat, wird man nicht spielen können. Auch später wird man von Zeit zu Zeit dazu aufgefordert sein System neu zu starten, weil Vanguard oder FaceIt aktualisiert worden sind. Solange man das nicht getan hat, wird man kein neues Spiel starten können. Doch wie war das im Rahmen der Javelin-Erstinstallation? Hier sollte jedem Anwender aufgefallen sein, dass man nach der Battlefield 6 Installation direkt anfangen konnte zu spielen. Es war kein Neustart erforderlich. Auch gab es seit dem Release zwar Updates für den Anti-Cheat, aber keiner davon erforderte einen Neustart des Computers.
Rein technisch ist es natürlich schon möglich, Kernel-Treiber zur Laufzeit zu laden. Ein prominentes und für jeden leicht nachvollziehbares Beispiel stellt bspw. ProcMon aus der SysInternals-Suite dar: Damit ProcMon die ganzen Details liefern kann, benötigt es einen Kernel-Treiber. Dieser wird nicht dauerhaft installiert sondern lediglich beim Programmstart geladen. Dem ein oder anderen wird jedoch schon aufgefallen sein (bspw. weil die Anti-Cheat Lösung seines Lieblingsspiels sich über das Vorhandensein des Treibers beschwert hat), dass der Treiber bei Programmende nicht wieder entladen wird, denn das ist bei Kernel-Treibern unmöglich.
Weswegen erzähle ich das? Weil ich geschildert habe, dass Javelin auch als Anti-Cheat auf Kernel-Ebene zur Laufzeit geladen werden kann. Der kritische Forenteilnehmer wird sich hoffentlich die Frage stellen, weswegen Vanguard oder FaceIt auf einen Neustart bestehen und es nicht ähnlich wie EA lösen und ohne Neustart auskommen. Das wäre doch viel nutzerfreundlicher. Der Grund ist einfach und evtl. auch aus dem Umfeld von Cybersecurity-Lösungen der Virenscanner (SentinelOne, Crowdstrike) etc. bekannt, die in der Regel auch auf einen Neustart bestehen (oder teilweise davor warnen, dass man den Computer zwar weiter nutzen könne, aber bis zu einem Neustart eben nicht der versprochene Schutz garantiert werden kann): Man kann nicht sicher sein, dass die System-Integrität zum jetzigen Zeitpunkt wo man den Treiber laden würde, sichergestellt ist. Es könnte ein anderer Kernel-Treiber aktiv sein, welcher den Cheat versteckt oder überhaupt erst ermöglicht (siehe dazu bspw. den Golem-Artikel zu WinRing0 mit dem Titel "
Windows stuft beliebte Tools plötzlich als Bedrohung ein")
An diesem Treiber hat sich Vanguard schon vor mehr als zwei Jahren gestört und sofern dieser geladen war es verweigert, Valorant auszuführen. Warum? Weil der Treiber es dem Userspace (also Programme die der Anwender selber ausführen) ermöglicht hat, beliebig auf den Kernel zuzugreifen). Wenn man trotzdem glauben möchte, dass EA's Javelin eine gute Anti-Cheat Lösung sei könnte man jetzt argumentieren, dass der Hersteller hier womöglich zwischen Sicherheit und Usability abgewogen hat und die Meinung vertritt, dass es eher unwahrscheinlich ist, dass ein Spieler in den ersten Minuten gleich betrügen wird und die Wahrscheinlichkeit doch relativ hoch ist, dass das Spielgerät binnen der nächsten Stunden eh neu gestartet wird (irgendwann geht der Cheater schlafen und schaltet hierzu den Computer aus) und ab dem Moment die versprochene Sicherheit gewährleistet ist. Eine tiefere Recherche könnte dann unter Umständen jedoch zu Tage fördern, dass EA's Javelin die Windows API fragt um den Zustand von SecureBoot zu erfahren. Glücklicherweise ist es technisch natürlich absolut unüblich sich in irgendeine API einzuklinken (hooken) um einem abfragenden Programm eine nicht den Tatsachen entsprechende Antwort zu liefern.
Handelt es sich bei EA's Javelin in der derzeitigen Form also lediglich um ein Placebo?
Die technische Idee hinter Secure Boot begrüße ich. Es ist die einzige Möglichkeit die wir derzeit haben, um so etwas wie eine kontrollierte und damit vertrauenswürdige Umgebung zu schaffen, wenn denn alles richtig implementiert ist. Davon profitiert Windows, MacOS wie auch Linux. Problematisch sehe ich lediglich das Key-Management: Niemand käme auf die Idee ein Türschloss von ABUS, BKS, GERA und wie sie alle heißen zu kaufen wenn der jeweilige Hersteller einen Zentralschlüssel hat. Diesen hat Microsoft de facto dadurch, dass in den meisten Secure Boot Konfigurationen eben der Schlüssel von Microsoft hinterlegt ist. Dabei kritisiere ich gar nicht die Vorkonfiguration, dass bspw. Computer mit dem Microsoft-Schlüssel gleich ab Werk ausgeliefert werden (ich verstehe die Notwendigkeit und wüsste nicht, wie man es praktisch anders handhaben könnte). Das macht es allerdings nur einfacher einen Bootloader und damit bspw. ein Installationsmedium von Microsoft direkt zu starten. Und wie eben erwähnt konterkariert diese Popularität (kommerzielle Linux-Distributionen lassen ihren Bootloader aus Bequemlichkeit auch vom gleichen Microsoft-Key signieren) die Idee hinter Secure Boot ähnlich wie Zertifizierungsstellen (CAs) in den Trust Stores der Browser: Wenn jeder letztendlich den gleichen vertrauenswürdigen Schlüssel nutzt, schützt der Schlüssel irgendwann gar nichts mehr. Genau so ist die Praxis diverser Linux-Distributionen aus meiner Sicht fragwürdig zu bewerten, welche ihren Loader per Shim-signed Chain-Loading laden und nach ihrem Shim-Loader auf Signaturen verzichten.
Aber wer möchte dies bitte für alle seine Geräte tun müssen, die Geräte seiner Familie usw.? Es gibt diverse Live-Systeme oder Multi-Bootable ISO-Lösungen welche ihren eigenen Key automatisch installieren (enrollen) können. Hierzu stellt Secure Boot eine eigene API bereit (zugegeben: Hierfür greifen sie einmalig auf Shim-signed Chain-Loading zurück weil es sonst eine Henne-Ei-Problem gäbe; Willst Du ganz ohne auskommen, müsstest Du den Key halt erst manuell im BIOS-Menü selbst einspielen). Aber das skaliert nicht bzw. ist nicht praktikabel für die breite Masse.
Und so kommt es dann eben, dass die meisten Systemen dem gleichen Key vertrauen. Diese Vertrauensproblematik ändert aber nichts an dem technischen Nutzen von Secure Boot. Ohne eine vermeintlich vertrauenswürdige Basis braucht man mit allem was Integrität voraussetzt, dazu zählen eben auch Anti-Cheat Lösungen, nicht anzufangen. Man darf aber auch nicht den Fehler machen und eine vertrauenswürdige Basis zu überhöhen: FaceIt hat sich einen sehr guten Ruf über die letzten Jahre erarbeitet. Mit der zunehmenden Popularität von Hardware-Hacks (Stichwort DMA) die leider immer günstiger werden, steigt auch die Cheater-Zahl auf FaceIt (und ich spreche hier vor allem von den zahlreichen dokumentieren Rage-Hack Cheatern). Wie leider so häufig hilft es nicht, wenn man ein aufkommendes Problem leugnet, totschweigt und behauptet Herr der Lage zu sein.
Bzgl. Linux habe ich leider wenig Hoffnung: Es gibt nicht DAS Linux für Privatnutzer. Im geschöftlichen Umfeld ist der Markt eigentlich zwischen Debian, Ubuntu, Suse und RedHat aufgeteilt. Wenn man es aber nicht einmal schafft Spiele-Konsolen (da sollte man sogar die Hardware unter seiner Kontrolle haben) oder eben Windows nahezu Cheater-frei zu bekommen, verstehe ich jeden der Linux diesbezüglich gar keine Beachtung schenkt. Auch wenn ich es mir, als ewiger Linux-Nutzer, anders wünschen würde. Hier könnte SteamOS Abhilfe schaffen.
Man könnte sogar als Open Source (oder eben nicht) einen Kenrel Level Anti Cheat für Linux entwickeln. Da gäbe auch keine Verpflichtung zur Veröffentlichung des Codes, auch nicht durch die GPL des Kernel selbst. Die ist nur relevant, wenn du den Kernel-Quellcode oder Teile davon in dein Produkt integrierst. Wenn der Hersteller aber den Anti-Cheat einfach als Kernel-Modul implementiert, berührt man die Lizenz des Kernels gar nicht. Der Kernel kann auch problemlos proprietäre Closed-Source Kernelmodule laden, wie mit den Grafiktreibern von Nvidia seit Ewigkeiten üblich, ohne dass Nvidia damit irgendwie die GPL verletzt. Mittlerweile hat Nvidia zwar das Kernel-Modul des Treiber als Open Source umgesetzt, aber das ist letzlich nur ein simpler Loader, der dann den weiterhin Closed Source Binärblob von Nvidia mit der eigentlichen Funktionalität lädt. Genauso ließe sich das dann mit einem Anti-Cheat machen. Ein Kernelmodul (egal ob Closed oder Open Source), welches dann die Closed Source Komponenten des Anti-Cheat lädt. Man müsste lediglich sicherstellen, dass das Kernelmodul nur signierte Binärblobs nachlädt.
Davon abgesehen können Cheater sich auch mit externer Hardware Abhilfe schaffen, gerade so etwas wie Aimbot. Und das ist keine Theorie und Nischenerscheinung; ein Chronus Zen bekommst du online für ca. 100 Euro und das funktioniert dann am PC, PS5, Xbox und Switch. Das ist ein ewiges Katz und Maus-Spiel. Und Kernel-Anticheat nur eine weitere Runde in dem Spiel. Die nächste Runde hat Microsoft bereits angekündigt:
https://www.pcgamer.com/software/mi...e-attestation-for-online-system-verification/
Aber egal was da kommt, die Cheats werden sich entsprechend weiterentwickeln. Wie ich das sehe gibt es nur einen Weg, nachhaltig diese Spirale zu durchbrechen: Und das wäre mit echter Konsequenz fürs Cheaten, d.h. Account mit Personalausweis verknüpfen. Aber das will aus offensichtlichen Gründen auch niemand. (Gläserner Bürger muss nicht sein)
Das ist wie wenn du gegen Schwarzfahren vorgehen wolltest. Du hättest 2 Möglichkeiten: Du tolerierst keine ungeschützten Bahnhöfe, jeder Gast der einsteigt wird kontrolliert. Oder du siehst ein, dass an dieser Stelle ein 100%-iger Schutz völlig unrealistisch ist. - Beim Gaming wirst du einen geschützen Bereich letztendlich nur bekommen, wenn man am Ende Battlefield nur noch von EA betriebenen "Arcade"-Hallen spielen kann - Und versuchst den anderen Vektor, also das Schwarzfahren bzw. Cheaten, unlukrativ zu machen indem du die Strafen erhöhst. Ich sage ganz einfach, solange man bequem cheaten kann, wird sich an der Gesammtsituation nicht wirklich etwas ändern... Im Zweifel bleibt eben nur die aktive Moderation, die in Personalkosten mündet.
PS: Ich bitte darum, dass meine Aussagen nicht wertend bzgl. FaceIt oder Vanguard gesehen werden sollen. Ich stelle lediglich fest, dass der vermeintliche große Wurf von EA's neuem Anti-Cheat, Javelin, der angeblich auf Kernel-Ebene funktioniert, in diesem Punkt eine Irreführung ist. Hat man das einmal verstanden, erscheinen jegliche Aussagen des Herstellers, die schon von Natur aus nicht unabhängig überprüft werden können, noch zweifelhafter.
