04.01.2011, 10:47 | #1 (permalink) |
Registriert seit: 16.11.2006
Ort: Paris-Rom-Erkner
Alter: 53
Beiträge: 6.205
|
Cheaten - wie kann dies serverseitig verhindert werden??
Hatte gestern in einer Warfare plötzlich ne GBU statt ner RPG auf dem Rücken und im Sidechat tauchten unter meinem Namen mehr oder weniger witzige Bemerkungen auf im Zusammenhang mit meiner Bombe.
Welche Dinge in der Engine und Mission könnte/sollte man ändern um so etwas zu verhindern? Grundsätzlich braucht man ja in jeder Mission die Funktion Objekte in die virtuelle Welt zu setzen. Aber man kann Funktionen, welche man garantiert nicht braucht im Laufe eine Mission doch als gesperrt im Missionsfile definieren? Oder bestimmte Waffen-vehikel Combinationen dfinieren, alles andere geht net etc. In einem auf Realismus getrimmten Spiel ist cheaten der Tod.
__________________
|
04.01.2011, 11:25 | #2 (permalink) |
Registriert seit: 26.11.2006
Ort: Kiel, S-H
Alter: 57
Beiträge: 3.013
|
Wenn man das/die Cheatingaddon(s) hätte würden mir sicherlich einige Möglichkeiten einfallen das Addon anhand gewisser Einträge zu identifizieren
und somit einen Spieler der das im aktiven Modfolder benutzt kurzerhand vom server zu treten. Sicherlich ist das nicht die ultimative Lösung, aber man kann den Burschen damit dann ganz gehörig in die Suppe spucken. Ich vermute das der Großteil der User die sowas benutzen nicht genug Know-How hat das Cheatingaddon entsprechend zu modifizieren das es dann nicht mehr identifiziert werden kann.
__________________
Nur ein Beispiel das zeigt wie BI "support" definiert: https://feedback.bistudio.com/T75547 |
04.01.2011, 12:59 | #3 (permalink) |
Registriert seit: 16.11.2006
Ort: Paris-Rom-Erkner
Alter: 53
Beiträge: 6.205
|
Das man grundsätzlich nur Positivlisten von addons auf dem server definieren sollte setze ich mal als gegeben.
Wie bekommt man aber vom server die Kontrolle über die Clientapp so dass man zu JEDEM BELIEBIGEN ZEITPUNKT checken kann ob 1.) alle in Fileform vorliegenden Bestandteile dem Original entsprechen 2.) diese auch im RAM unverändert vorliegen 3.) Funktionen ausgeführt werden die generell möglich sind, aber vom zentral gesteuerten ablauf zu dem Zeitpunkt nicht erlaubt sein sollen Beispiel(e): zu1.) mit irgendwekchen Hashs integrität verifizieren ist ja so neu nicht zu2.) im Ram ist schwieriger weil ja meist nur Teile aus den Archiven der Files in den Ram geladen werden und auch dort notwendigerweise verändert werden. Was da möglich ist müssen andere beantworten zu3.) das server-client protokoll sollte seitens BIS so gestaltet werden dass man am server dynamisch setzen kann wann und wie aktionen am client zulässig sind, auch in bezug auf grafische darstellung.
__________________
|
04.01.2011, 13:35 | #4 (permalink) |
Registriert seit: 26.11.2006
Ort: Kiel, S-H
Alter: 57
Beiträge: 3.013
|
zu 3)
Das kannst du meiner Meinung nach total vergessen, um das wirklich zu gewährleisten muß man einen erheblichen Aufwand betreiben der sich dann direkt auf die Performance niederschlägt. Ich hatte vor Jahren mal Einblick in Teile der OFP Netzcode und wie die Performancemäßig deutlich verbessert wurden. (Vorher-Nachher) Wir erinnern uns das bei OFP bis inkl. ca. V1.30 Coop im LAN kaum gescheit möglich war, weil dort mehr abgestimmt wurde als es unbedingt nötig war. Wenn jeder Client erst immer lieb "bitte bitte" sagt und das vom Server quitiert werden muß geht es wieder direkt dorthin. Einen gescheiten Schutz bekommt man imho bei dermaßen flexiblen Spielen wie ArmA nur durch knallhartes Hashvergleichen hin. Ist die "Sammelconfig" nebst allen Mods und Addons nicht identisch mit Server dann gibt es nen Tritt vor dem Bug. Im Falle von Soundmods z.B. ist das aber natürlich fatal, hier könnte nur eine Art gestattete Alternativ-"Sammelconfig" abhilfe schaffen. Um Speichermanipulationen vorzubeugen gibt es vermutlich irgendeine Form über das OS die Schreibrechte anderen Prozessen zu nehmen oder zumindest die Information zu erhalten wenn fragliche Prozesse darauf zugreifen und dann ihren Dienst verweigern. Wie auch immer eine 100%ige Sicherheit wird es eh nie geben, spätestens wenn irgendein Spezi die exe dermaßen manipuliert das sie immer die Wunschabstimmungsdaten quitiert ist alles machbare erreicht.
__________________
Nur ein Beispiel das zeigt wie BI "support" definiert: https://feedback.bistudio.com/T75547 Geändert von Lester (04.01.2011 um 13:37 Uhr). |
04.01.2011, 13:41 | #5 (permalink) |
Registriert seit: 05.01.2008
Beiträge: 105
|
Lauter schöne Ideen, die aber Arma2 größtenteils schon umsetzt .... und hilft nichts.
Wenn man sich mal einschlägigen Foren umsieht, dann merkt man recht schnell, dass momentan kein wirkliches Kraut gegen die Cheater wächst. Da wird zum richtigen Zeitpunkt via DLL-Injection der Code im Arma2-Client verändert, der Hash und RSA-Key eines Addons bzw. einer Arma2-Original-PBO zum Server schickt. Somit ist der Signatur-Check ausgehebelt. Man muss sich nichts vormachen: Ein so offenes System wie Arma2 (und Windows) ist nicht wirklich sicher zu machen. Battleeye hilft da leider auch wohl nur bedingt. Das einzig Gute ist: Viele Cheater machen zu Beginn etwas falsch und können so früh entdeckt und gebannt werden. Dummerweise kann man aber wohl auch die Player-ID austauschen, so dass der Bann nicht zuverlässig wirkt. Bleibt ein Bann auf IP-Ebene, der aber auch nicht zuverlässig funktioniert. Offenbar hilft auch: Kein Warfare und kein Domi. Alles andere ist wohl für Cheater uninteressant. Und vermutlich wird mit abnehmender Spielerzahl Arma2 für Hacker auch immer weniger interessant. Die konzentrieren sich dann auf "neue Herausforderungen". Und wo keine Hacker, da sind auch keine Cheater. Mir scheint, dass es für Arma2 nur eine Handvoll Hacker gibt. Wenn die weiterziehen, ist das Problem vom Tisch. Geändert von svenson (04.01.2011 um 13:49 Uhr). |
04.01.2011, 14:08 | #6 (permalink) |
Registriert seit: 16.11.2006
Ort: Paris-Rom-Erkner
Alter: 53
Beiträge: 6.205
|
Weiss ich. Deswegen muss man dies erweitern. zB Kann man am Server eine Session mitloggen, kann mit commands/funktionen aus der Mission getriggert werden. zB Cash/bonussysteme: Man kann kreditierung so gestalten das cash aus dem Nirvana unmöglich wird oder zumindest einer zyklischen überprüfung nicht standhält. Man kann zB bei JEDER Kontoänderung eines clients die Summe aller Konten überprüfen und ob ein event stattgefunden hat welches die erhöhung rechtfertigt. oder man loggt ganz banal wer(client-ID)-wann-welche assets in die spielwelt erstellt. Der server kann IMMER die plausibilität beurteilen wenn man die logik kennt. Ein client, welcher ein asset spawned ohne das es den abgang beim cash gibt muss ein "hönk"+"kick" triggern.
__________________
|
Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1) | |
Themen-Optionen | |
Ansicht | |
|
|
Ähnliche Themen | ||||
Thema | Autor | Forum | Antworten | Letzter Beitrag |
Cheaten in Steamversion | madmusti | Community | 9 | 04.09.2010 00:14 |