Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 20 von 27
  1. #1
    Mitglied Avatar von Annika_Kremer
    Registriert seit
    Aug 2008
    Beiträge
    4.840
    NewsPresso
    166 (Virtuose)
    Danksagungen
    36

    Standard Diablo 3: Account-Sperren wegen veränderter Software

    In letzter Zeit kam es zu einer Reihe von Account-Sperrungen in Blizzards Action-Rollenspiel "Diablo 3". Anlass für die Sperrungen war offenbar die Nutzung einer veränderten Version der Spiele-Software, die von Blizzard als Betrug beziehungsweise "Cheating" interpretiert wird.

    zur News

  2. #2
    Mitglied
    Registriert seit
    Jun 2010
    Beiträge
    264
    Danksagungen
    2

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    Schon kacke wenn man ein Singleplayer-/Coop-Spiel nicht so spielen darf, wie man möchte

  3. #3
    Mitglied
    Registriert seit
    Nov 2008
    Beiträge
    1
    Danksagungen
    0

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    Höllisch gut ist das Spielvergnügen bei Diablo 3 leider auch so nicht.

    Kommt nicht mal ansatzweise an Teil 1 und 2 heran....

  4. #4
    Mitglied Avatar von Hagar Quinn
    Registriert seit
    Mar 2007
    Beiträge
    252
    Danksagungen
    1

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    So ist das Transport Tycoon fand ich spannender...

    D3 einmal durch und das wars...

  5. #5
    Gesperrt Avatar von Aluhut
    Registriert seit
    Oct 2012
    Beiträge
    260
    Danksagungen
    9

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    Tja... Their game, their rules...

    Da haben die Gamer selber Schuld dran. Die Haltung von Blizzard (und anderen Publishern) ist ja nicht gerade eine Neuigkeit!
    Und wenn man sowas dann kauft, muss man auch damit leben!

  6. #6
    deaktivierter Nutzer
    deaktiviertes Benutzerkonto

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    Zitat Zitat von SanitysDownfall Beitrag anzeigen
    Schon kacke wenn man ein Singleplayer-/Coop-Spiel nicht so spielen darf, wie man möchte
    was ist daran "kacke"? es war lange vor verkaufsbeginn bekannt das diablo 3 zum einen accountegebunden und zum anderen eine dauerhafte internetverbindung benötigt. bevor man da rumjammert sollte man doch so konsequent sein und unter diesen umständen die finger davon lassen.
    und davon abgesehen, unter den betroffenen wird eh nur ein kleiner teil spieler sein die tatsächlich allein und ohne böse absichten geschummelt haben. der großteil dürfte versuchen die mit den erträgen seiner geschummelten spielweise entweder vorteile ingame durch das ah zu bekommen oder eben schlicht geld zu machen. was beides nicht ins spiel gehört.
    und ob das spiel an sich nun gut ist oder nicht sei mal dahingestellt, das ist ja nicht thema.
    und das man wegen:
    In jedem dieser Fälle haben Spieler ein Hackprogramm für betrügerische Zwecke verwendet und haben somit z.B. die Reichweite des Zooms so stark erhöht, das Monster getötet werden konnten ohne zu reagieren (Umgehung der KI).
    den account gesperrt bekommt ist ja nun nichts ungewöhnliches, ganz im gegenteil. als käufer erwarte ich sowas. der sperrgrund war gerechtfertigt und gerade bei blizzard ist auch eine accountsperre das verändern der software/cheaten nichts was einen unerwartet trifft, es sei denn man bewegt sich gänzlich merkbefreit durch die gegend.
    ob das nun ne news wert war, lassen wir mal aussen vor. sowas passiert ja nicht nur bei blizzardprodukten beinahe täglich.
    Geändert von Erbseneintopf (10. 11. 2012 um 11:34 Uhr)

  7. #7
    Mitglied
    Registriert seit
    Aug 2007
    Beiträge
    265
    Danksagungen
    3

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    Im Endeffekt ist euer Spielerlebnis dann nicht mehr höllisch gut, sondern das genaue Gegenteil
    Also himmlisch schlecht?

  8. #8
    Mitglied Avatar von Baalrun1337
    Registriert seit
    Sep 2011
    Beiträge
    13
    Danksagungen
    0

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    Path of Exile. PUNKT!

  9. #9
    Mitglied
    Registriert seit
    Dec 2004
    Ort
    Germany
    Beiträge
    208
    Danksagungen
    2

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    Ich bin D3 wieder voll eingestiegen, alle Änderungen haben mich angesprochen :-)

  10. #10
    Mitglied Avatar von MystiqueMax
    Registriert seit
    Apr 2009
    Beiträge
    696
    Danksagungen
    0

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    Zitat Zitat von Erbseneintopf Beitrag anzeigen
    was ist daran "kacke"? es war lange vor verkaufsbeginn bekannt das diablo 3 zum einen accountegebunden und zum anderen eine dauerhafte internetverbindung benötigt.
    Das ist nämlich genau der Grund, warum ich mich total auf D3 gefreut habe und es bis heute noch kein einziges mal gezockt habe. Ich habe es nicht gekauft. In einem SP-Spiel will ich cheaten dürfen. Jedenfalls für das x-te mal durchspielen oder so. Modden dürfen, etc. Wenn man für so etwas gesperrt wird, nun ja, ich kann es verstehen. Da bei D3 offline gleich online Charakter ist. Aber so etwas treib ich Spielefirmen durch mein Nichtkaufen schnell wieder aus.. So jedenfalls die Hoffnung, aber solange ich hierbei allein stehe... Trotzdem dürfen die Leute das "kacke" finden, denn vielleicht lernen sie etwas für den nächsten Blockbuster mit Onlinezwang.. Aber diese Hoffnung ist kaum eine exotherme Reaktion, geschweige denn ein Funken...

    Ich würde übrigens mehr über diesen Hack wissen wollen. War es eigentlich zweifelsfrei als Hack erkennbar oder konnte man es als WoW-like Addon interpretieren?

  11. #11
    Mitglied
    Registriert seit
    Jun 2005
    Ort
    Hooked_glBegin
    Beiträge
    258
    Danksagungen
    91

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    Ich hab' mich vom Hype mitreissen lassen, der ua. auch von D2 ausging und konnte über den Online-Zwang hinwegsehen. Die Login-Server in EU sind nun schon über 2std. Offline und das Blizz-Forum quillt fast über mit Nachrichten von angepi**** Spielern. tjoa, das hab' ich nun davon

  12. #12
    ex-Moderator Avatar von Kugelfisch23
    Registriert seit
    Oct 2007
    Beiträge
    18.640
    Danksagungen
    458

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    Fragwürdig scheint mir insbesondere die technische Begründung
    Diese Art von Software [...] kann zu schweren technischen Fehlern, Bugs im Spiel sowie Stabilitäts- und Geschwindigkeitsproblemen auf Battle.net führen
    für das Verbot von manipulierten Clients. Wenn dem tatsächlich so ist, sind die Server fehlerhaft implementiert, da sie den von den Clients übermittelten Daten vertrauen. Schliesslich befinden sich die Clients prinzipbedingt ausserhalb der Kontrolle der Entwickler (auch wenn sie regelmässig mit fragwürdigen Methoden wie `Anti-Cheat`-Spyware, Rootkit-ähnlichen Ansätzen u.ä. versuchen, sie zu kontrollieren), daher sind von ihnen übermittelte Daten als potentiell manipuliert (und daher schädlich) zu betrachten. Berücksichtigt man dies, könnte man sich über manipulierte Clients nur noch insofern Vorteile verschaffen, als dass man alle vom Server übermittelten Informationen anzeigt (daher sollte der Server den einzelnen Clients nur die Informationen über die Spielwelt übermitteln, welche sie tatsächlich benötigen und auch anzeigen dürfen) und die Steuerung automatisiert (Bots - das lässt sich nicht vermeiden).

  13. #13
    Mitglied
    Registriert seit
    Jun 2008
    Beiträge
    274
    Danksagungen
    2

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    wäre nur das problem das alles was nicht auf dem client läuft bzw. durch den server kontrolliert werden muss zusätzlichen rechenaufwand verursacht und auch hierbei wie der server die daten die er vom client bekommt verarbeitet gibt es lücken mit denen sich der server manipulieren lässt weil es beim compilen nicht zu verhindern ist das solcher code erstellt wird. schon desöfteren gesehen das einige ganze simple sachen jeden spieler auf dem server kicken oder andere direkte einflüsse auf die spieler haben bloß weil ich ein bischen experimentiert habe(dabei habe ich nicht einmal versucht irgendetwas ernsthaft stark zu manipulieren), am weit verbreitesten als beispiel ist wohl ein "speedhack"(ich wage es kaum so zu bezeichnen weil die ja nur das programm schneller oder langsamer ablaufen lassen) der den server mit packeten zubombt. auf andere methoden und sachen will ich hier jetzt nicht genau darauf eingehen sonst bringe ich hier noch jemanden auf dumme gedanken.

    wenn ich so sehe welchen einfluss die ganzen goldseller und cheater inzwischen auf die spiele haben und teils(oder oft?) das ganze spielsystem ruinieren werde ich keine cheats mehr benutzen(habe ich mir so oder so abgewöhnt weil die spiele ohne viel länger spaß machen) oder welche erstellen

    theoretisch kannst auch deren methoden zum finden von veränderungen am client ganz sicher beheben, würde aber wohl wieder den cheatern tür und tor öffnen weswegen ich mich dazu auch nicht weiter äußere. die bauen so schon genug scheiße

    so ist es im cyberkrieg ^_^

  14. #14
    ex-Moderator Avatar von Kugelfisch23
    Registriert seit
    Oct 2007
    Beiträge
    18.640
    Danksagungen
    458

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    Zitat Zitat von Matek0101 Beitrag anzeigen
    wäre nur das problem das alles was nicht auf dem client läuft bzw. durch den server kontrolliert werden muss zusätzlichen rechenaufwand verursacht
    Das ist sicherlich korrekt, aber diesen Rechenaufwand muss der Server übernehmen, andernfalls sollte man sich nicht wundern, wenn Benutzer Daten mit dem Ziel manipulieren, sich selbst Vorteile zu verschaffen. Der Client darf nicht mehr Autorität als der Spieler selbst haben, dementsprechend sind auch die von ihm übermittelten Daten zu behandeln.

    Zitat Zitat von Matek0101 Beitrag anzeigen
    und auch hierbei wie der server die daten die er vom client bekommt verarbeitet gibt es lücken mit denen sich der server manipulieren lässt weil es beim compilen nicht zu verhindern ist das solcher code erstellt wird.
    Kaum. Wenn der Compiler unsicheren Maschinencode erzeugt, ist entweder der Quellcode oder der Compiler fehlerhaft. In der Regel eher Ersteres, da ein entsprechender Compiler-Bug durch die globalen Auswirkungen auf alle damit erstellten Anwendungen schnell bemerkt und behoben würde.

    Zitat Zitat von Matek0101 Beitrag anzeigen
    schon desöfteren gesehen das einige ganze simple sachen jeden spieler auf dem server kicken oder andere direkte einflüsse auf die spieler haben bloß weil ich ein bischen experimentiert habe
    Das sind typische Implementierungsfehler auf der Serverseite. In diesem konkreten Fall prüft der Server offenbar nicht (oder nicht ausreichend), welcher Client welchen Spieler kontrolliert und dementsprechend für diesen Spieler Handlungen vornehmen darf. Dass solch offensichtliche Fehler schnell gefunden und ausgenutzt werden, ist wenig verwunderlich.

    Zitat Zitat von Matek0101 Beitrag anzeigen
    am weit verbreitesten als beispiel ist wohl ein "speedhack"(ich wage es kaum so zu bezeichnen weil die ja nur das programm schneller oder langsamer ablaufen lassen) der den server mit packeten zubombt.
    Darauf sollte der Server nicht mit einer Fehlfunktion (etwa einem langsameren oder schnelleren Spielablauf) reagieren, sondern den betreffenden (offensichtlich fehlerhaften/manipulierten) Client aus dem Spiel entfernen und seine Pakete fortan verwerfen. Dasselbe tut auch jeder andere im Internet angebotene Server-Dienst sinnvollerweise, wenn ein einzelner Client seine Ressourcen (gezielt oder durch eine Fehlfunktion) übermässig stark belastet.

  15. #15
    Mitglied
    Registriert seit
    Jun 2008
    Beiträge
    274
    Danksagungen
    2

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    Zitat Zitat von Kugelfisch23 Beitrag anzeigen
    Das ist sicherlich korrekt, aber diesen Rechenaufwand muss der Server übernehmen, andernfalls sollte man sich nicht wundern, wenn Benutzer Daten mit dem Ziel manipulieren, sich selbst Vorteile zu verschaffen. Der Client darf nicht mehr Autorität als der Spieler selbst haben, dementsprechend sind auch die von ihm übermittelten Daten zu behandeln.
    Ich wollte darauf hinaus das Rechenlast ein Problem ist, es treibt die kosten in die höhe weswegen sich jeder Spielepublisher(heist das so?) und Entwickler überlegen sollte wieviele Resourcen er in solche Kosten investiert. Mit dem Ziel Sicherheit muss das notwendigste auf dem Client laufen oder der Server so ausgeklügelte Algorythmen haben das die Berechnungen doch auf dem Client laufen können und der Server mit seltenen weniger Rechenaufwendigen Prüfungen Schlussfolget ob das was der Spieler in der Zwischenzeit gemacht hat legal gewesen ist und solche Algorythmen haben auch ihre tücken wo wir wieder bei dem selben Problem sind wie man nun genau im Endeffekt bei der Entwicklung seines Spieles die Resourcen aufwendet oder später aufwenden will wenn die Server laufen. Und auch bei den notwendigsten Clientseitigen Berechnungen gibt es durch die Grafik die notwendig ist bei jedem Spiel Lücken sowie dem Risiko das die Cheater besser darin werden die Server auszutricksen.

    Zitat Zitat von Kugelfisch23 Beitrag anzeigen
    Kaum. Wenn der Compiler unsicheren Maschinencode erzeugt, ist entweder der Quellcode oder der Compiler fehlerhaft. In der Regel eher Ersteres, da ein entsprechender Compiler-Bug durch die globalen Auswirkungen auf alle damit erstellten Anwendungen schnell bemerkt und behoben würde.
    Vorausgesetzt es würde jeder Compiler-Bug als solcher erkannt und auch bekannt werden, ich verstehe von Compilern im Detail nicht viel. Ich weis das es verschiedene Compiler gibt die alle unterschiedlich aufwendig sind und sich meiner Meinung kaum genug Leute damit auskennen um die wirklich Sicher zu kriegen. Wer schreibt denn schon Tag&Nacht an einem Compiler? Die Compiler sind soweit ich es verstehe Programme die beliebig komplizierten Quellcode interpretieren und dann per "Zufall" Code erzeugen. Da laufen ja allemöglichen Algorythmen zur Fehler-Reduktion, Leistungsoptimierung und Sicherheitsverbesserung die, obwohl Sie nach festen Regeln funktionieren, aus dem randomisierenden Quellcode verschiedenste Dinge generieren. Ich habe schon Compiler gesehen die von selbst lernen und ihren Code aus dem was sie gelernt haben ändern. Gegen soviele Faktoren kann man sich kaum effizient wappnen weswegen ich auch bezweifel das jeder Bug bekannt, geschweige denn erkannt wird.

    Zitat Zitat von Kugelfisch23 Beitrag anzeigen
    Das sind typische Implementierungsfehler auf der Serverseite. In diesem konkreten Fall prüft der Server offenbar nicht (oder nicht ausreichend), welcher Client welchen Spieler kontrolliert und dementsprechend für diesen Spieler Handlungen vornehmen darf. Dass solch offensichtliche Fehler schnell gefunden und ausgenutzt werden, ist wenig verwunderlich.
    Wohl eher weil der Server den von mir generierten Fehler an die Clients weiterreicht die dann auch an dem Fehler sterben(so habe ich es auch schon gesehen). Gibt es verschiedenste Variationen weswegen das so sein kann, auf die Serverseite würde ich es nicht generell schieben.

    Zitat Zitat von Kugelfisch23 Beitrag anzeigen
    Darauf sollte der Server nicht mit einer Fehlfunktion (etwa einem langsameren oder schnelleren Spielablauf) reagieren, sondern den betreffenden (offensichtlich fehlerhaften/manipulierten) Client aus dem Spiel entfernen und seine Pakete fortan verwerfen. Dasselbe tut auch jeder andere im Internet angebotene Server-Dienst sinnvollerweise, wenn ein einzelner Client seine Ressourcen (gezielt oder durch eine Fehlfunktion) übermässig stark belastet.
    Bei viele Spielen im Internet funktioniert das heutzutage auch nicht mehr, ist ja nur ein simples Beispiel gewesen warum die Cheater den Servern so zu schaffen machen. Der Server läuft dabei nicht schneller, die Clients laufen schneller bzw. langsamer und bei schnelleren Clients wird massiv höhere Serverlast erzeugt was heute noch bei anderen Cheats ähnlich ist weil es auf dem Server Probleme/Störungen verursacht.

  16. #16
    deaktivierter Nutzer
    deaktiviertes Benutzerkonto

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    Die verdammten Server bei Blizzard haben mich als Berufstätigen (meine Freizeit fällt mit der vieler anderer zusammen) schließlich dazu gebracht, Diablo3 zu löschen, obwohl ich D1 und D2 verschlungen habe!
    Diablo 3 war der letzte Blindkauf bei Blizzard. Und so, wie dieses Spiel kommerzgeil vergewaltigt wurde, wundern mich solche Aktionen von Blizzard nicht und es wunder mich noch weniger, dass die Server mal wieder nicht erreichbar sind (wer will schon Sonntagabend zocken!).

    Zum Glück gibts ja Torch Light 2

  17. #17
    ex-Moderator Avatar von Kugelfisch23
    Registriert seit
    Oct 2007
    Beiträge
    18.640
    Danksagungen
    458

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    Zitat Zitat von Matek0101 Beitrag anzeigen
    Ich wollte darauf hinaus das Rechenlast ein Problem ist, es treibt die kosten in die höhe weswegen sich jeder Spielepublisher(heist das so?) und Entwickler überlegen sollte wieviele Resourcen er in solche Kosten investiert.
    Mein Punkt ist, dass wenn die Spielmechanik (um Rechenzeit und damit Kosten zu sparen) nicht komplett auf dem Server läuft zumindest wenig verwunderlich ist, dass die auf die Clients ausgelagerten Berechnungen manipuliert werden. Der Ansatz, den Client kontrollieren zu wollen, wird ebenso scheitern wie vergleichbare Ansätze an anderer Stelle mehrfach gescheitert sind - etwa DRM- und Kopierschutz-Techniken jeglicher Art, Versuche von Webmastern, die Darstellung von Werbung im Browser der Besucher sicherzustellen, ...

    Der Client befindet sich schlicht nicht unter der Kontrolle der Entwickler. Es wäre besser, diese technisch bedingte Tatsache zu akzeptieren und die nötigen Konsequenzen zu ziehen, als zu versuchen, mit höchst fragwürdigen (und zudem technisch bedingt unzuverlässigen) Methoden zu versuchen, den Client zu kontrollieren.

    Selbst wenn die komplette Spielmechanik auf dem Server läuft, ist nach wie vor möglich, dass sich Benutzer durch Anpassungen der Grafiken bzw. ihrer Darstellung Vorteile verschaffen, indem sie z.B. störende Lichteffekte unterdrücken, Informationen über Vorgänge ausserhalb des sichtbaren Bildschirmbereichs anzeigen (sofern der Server sie darüber informiert), o.ä. - die Auswirkungen davon sind jedoch verhältnismässig gering, wenn man serverseitig darauf achtet, dem Client nur die tatsächlich nötigen Informationen zu übermitteln.

    Ein weiteres dadurch nicht zu behebendes `Problem` sind Bots jeglicher Art, sofern sich diese nicht anders als normale Clients verhalten. Diese lassen sich schlicht nicht zuverlässig erkennen - eine Abhilfe wäre an dieser Stelle, das Spiel so zu gestalten, dass man sich nicht durch sehr einfache, repetitive Tätigkeiten (`farmen`, ...) Vorteile verschaffen kann. Dann würden zumindest die üblichen trivialen Bots kaum mehr einen Mehrwert bieten.


    Zitat Zitat von Matek0101 Beitrag anzeigen
    Die Compiler sind soweit ich es verstehe Programme die beliebig komplizierten Quellcode interpretieren und dann per "Zufall" Code erzeugen.
    Der erzeugte Maschinencode ist keineswegs zufällig, sondern (ohne Compiler-Bugs) ein mehr oder weniger optimiertes Äquivalent des zu kompilierenden Hochsprachen-Codes. Auch arbeiten verbreitete Compiler deterministisch, erzeugen also bei gleichen Einstellungen immer denselben Maschinencode aus einem bestimmten Hochsprachen-Quellcode.

    Zitat Zitat von Matek0101 Beitrag anzeigen
    Da laufen ja allemöglichen Algorythmen zur Fehler-Reduktion, Leistungsoptimierung und Sicherheitsverbesserung die, obwohl Sie nach festen Regeln funktionieren, aus dem randomisierenden Quellcode verschiedenste Dinge generieren.
    Compiler optimieren den Code zwar in der Tat unterschiedlich stark, der erzeugte Maschinencode sollte jedoch funktionstechnisch zum eingegebenen Quellcode äquivalent sein. Eine `Fehler-Reduktion` nimmt der Compiler nicht vor, lässt sich der Quellcode nicht parsen, bricht er mit einem entsprechenden Fehler ab, werden Konstrukte erkannt, welche u.U. zu Fehlern oder Performance-Problemen führen könnten, werden ggf. (abhängig von den Compiler-Einstellungen) Warnmeldungen ausgegeben.

    Zitat Zitat von Matek0101 Beitrag anzeigen
    Ich habe schon Compiler gesehen die von selbst lernen und ihren Code aus dem was sie gelernt haben ändern.
    Solch ein Compiler wäre mir nicht bekannt, zumindest nicht in praktisch nutzbarer Form ausserhalb der akademischen Welt. Zumindest verbreitete Compiler wie z.B. gcc, g++ oder die Microsoft-C/C++-Compiler tun das nicht. Kannst du ein Beispiel nennen?

    Zitat Zitat von Matek0101 Beitrag anzeigen
    Gegen soviele Faktoren kann man sich kaum effizient wappnen weswegen ich auch bezweifel das jeder Bug bekannt, geschweige denn erkannt wird.
    Sicherlich wird nicht jeder Compiler-Bug sofort erkannt und - so er denn bekannt wird - umgehend behoben. Bugs, welche zu sicherheitsrelevanten Problemen oder gar zu konkreten ausnutzbaren Schwachstellen im erzeugten Code führen, werden jedoch spätestens dann erkannt, wenn Malware in freier Wildbahn die entsprechende Schwachstelle zu ihrer Verbreitung ausnutzen. Da die Verbreitung von Malware lukrativer ist als diverse Betrügereien in Spielen, würden solche Bugs wohl eher dazu ausgenutzt. Verglichen mit Schwachstellen im Quellcode war ihre Anzahl in den letzten Jahren jedoch verschwindend gering.


    Zitat Zitat von Matek0101 Beitrag anzeigen
    Wohl eher weil der Server den von mir generierten Fehler an die Clients weiterreicht die dann auch an dem Fehler sterben(so habe ich es auch schon gesehen). Gibt es verschiedenste Variationen weswegen das so sein kann, auf die Serverseite würde ich es nicht generell schieben.
    Wenn der Server dazu gebracht werden kann, den Clients inkorrekte Daten weiterzuleiten, würde ich das durchaus als Problem auf der Serverseite betrachten. Der Server hat schliesslich die Autorität in einem Spiel (bzw. sollte sie haben). Wenn z.B. der Server allen Clients sagt, dass sich eine Spielfigur auf Einmal an einer komplett anderen Position befindet, ist es nicht die Aufgabe der Clients, diese Information zu überprüfen. Ebenso wenig kann ein Client im Allgemeinen überprüfen, welcher Spieler in wessen Namen welche Aktionen durchführt, sofern die Pakete alle vom Server kommen. Das muss der Server tun.

    Zitat Zitat von Matek0101 Beitrag anzeigen
    Der Server läuft dabei nicht schneller, die Clients laufen schneller bzw. langsamer und bei schnelleren Clients wird massiv höhere Serverlast erzeugt was heute noch bei anderen Cheats ähnlich ist weil es auf dem Server Probleme/Störungen verursacht.
    Wenn ein Client durch eine Manipulation oder durch eine Fehlfunktion massiv höhere Serverlast verursacht, sollte ihn der Server aus dem Spiel entfernen und seine Pakete droppen, um die anderen Spieler vor den Auswirkungen zu schützen. Wenn ein Client langsamer läuft als erwartet, sehe ich darin kein Problem, da das Timing der eigentlichen Spielmechanik dem Server obliegen sollte. Stellt ein Client das Spielgeschehen langsamer dar, sollte das keine Auswirkungen auf den serverseitigen Spielablauf haben.

  18. #18
    Mitglied
    Registriert seit
    Jun 2008
    Beiträge
    274
    Danksagungen
    2

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    Zitat Zitat von Kugelfisch23 Beitrag anzeigen
    Mein Punkt ist, dass wenn die Spielmechanik (um Rechenzeit und damit Kosten zu sparen) nicht komplett auf dem Server läuft zumindest wenig verwunderlich ist, dass die auf die Clients ausgelagerten Berechnungen manipuliert werden. Der Ansatz, den Client kontrollieren zu wollen, wird ebenso scheitern wie vergleichbare Ansätze an anderer Stelle mehrfach gescheitert sind - etwa DRM- und Kopierschutz-Techniken jeglicher Art, Versuche von Webmastern, die Darstellung von Werbung im Browser der Besucher sicherzustellen, ...

    Der Client befindet sich schlicht nicht unter der Kontrolle der Entwickler. Es wäre besser, diese technisch bedingte Tatsache zu akzeptieren und die nötigen Konsequenzen zu ziehen, als zu versuchen, mit höchst fragwürdigen (und zudem technisch bedingt unzuverlässigen) Methoden zu versuchen, den Client zu kontrollieren.

    Selbst wenn die komplette Spielmechanik auf dem Server läuft, ist nach wie vor möglich, dass sich Benutzer durch Anpassungen der Grafiken bzw. ihrer Darstellung Vorteile verschaffen, indem sie z.B. störende Lichteffekte unterdrücken, Informationen über Vorgänge ausserhalb des sichtbaren Bildschirmbereichs anzeigen (sofern der Server sie darüber informiert), o.ä. - die Auswirkungen davon sind jedoch verhältnismässig gering, wenn man serverseitig darauf achtet, dem Client nur die tatsächlich nötigen Informationen zu übermitteln.

    Ein weiteres dadurch nicht zu behebendes `Problem` sind Bots jeglicher Art, sofern sich diese nicht anders als normale Clients verhalten. Diese lassen sich schlicht nicht zuverlässig erkennen - eine Abhilfe wäre an dieser Stelle, das Spiel so zu gestalten, dass man sich nicht durch sehr einfache, repetitive Tätigkeiten (`farmen`, ...) Vorteile verschaffen kann. Dann würden zumindest die üblichen trivialen Bots kaum mehr einen Mehrwert bieten.
    den punkt hat wohl jeder verstanden, das problem an deinen punkt ist nur das es nicht jeder schafft ihn umzusetzen

    bei grafik-cheats ist es wie du sagst kaum möglich sie zu verhindern aber bei den bots brauchst du jawohl z.b. nur mal versuchen mit ihm zu reden wobei es verschiedene relativ einfache methoden gibt herauszufinden ob es ein bot ist.

    Zitat Zitat von Kugelfisch23 Beitrag anzeigen
    Der erzeugte Maschinencode ist keineswegs zufällig, sondern (ohne Compiler-Bugs) ein mehr oder weniger optimiertes Äquivalent des zu kompilierenden Hochsprachen-Codes. Auch arbeiten verbreitete Compiler deterministisch, erzeugen also bei gleichen Einstellungen immer denselben Maschinencode aus einem bestimmten Hochsprachen-Quellcode.
    der compilierte maschinencode kann kein äquivalent des hochspachen-codes sein weil sich beide sehr stark in ihrer komplexität voneinander unterscheiden, ein einfachr befehl in hochsprache kann viel maschinencode beanspruchen was von compiler zu compiler und bibliothek zu bibliothek je nach dem mehr oder weniger stark variiert. sie erzeugen den selben code wenn der hochsprachencode der selbe ist was wohl nicht der fall ist wenn ich von randomisierenden code rede. der hochsprachencode ist ja das was die ergebnisse anders aussehen lässt weswegen man nur mutmaßen kann das die erzeugten ergebnisse sicher sind weil ja durchaus kontellationen zustande kommen könnten die noch nicht getestet wurden was beim programmieren äußerst wahrscheinlich ist wegen der vielfalt an möglichkeiten.

    Zitat Zitat von Kugelfisch23 Beitrag anzeigen
    Compiler optimieren den Code zwar in der Tat unterschiedlich stark, der erzeugte Maschinencode sollte jedoch funktionstechnisch zum eingegebenen Quellcode äquivalent sein. Eine `Fehler-Reduktion` nimmt der Compiler nicht vor, lässt sich der Quellcode nicht parsen, bricht er mit einem entsprechenden Fehler ab, werden Konstrukte erkannt, welche u.U. zu Fehlern oder Performance-Problemen führen könnten, werden ggf. (abhängig von den Compiler-Einstellungen) Warnmeldungen ausgegeben.
    der compiler brauch ja nur die ergebnisse an code zu optimierungszwecken von 2 verschiedenen codebereichnen die unterschiedliche zwecke erfüllen zusammenzulegen und schon öffnet das möglichkeiten für potentielle cheats. eine fehler-reduktion sollte sehr wohl beim kompilieren des hoffentlich fehlerfreien quellcode stattfinden denn es gibt ja wohl beim kompilieren des codes mögliche konstellationen die ein höheres potential an fehlern aufweisen wenn z.b. wie im vorher genannten beispiel die zusammengelegten funktionen in irgendeiner form kompromitierend wirken weil sie z.b. höhere last erzeugen oder unter hoher last fehler generieren bzw. unter seltenen umständen einfach falsche werte kriegen weil beim programmieren des compilers nicht vorhergesehen werden konnte das die untereinander verknüpften befehle bei denen nie angenommen wurde sie werden untereinander verknüpft fehler generieren können. die algorythmen optimieren ja den code also muss man um sicher zu sein das durch die algorythem keine fehler auftreten mindestens am ende noch einmal einen algorythmus durchlaufen lassen der den generierten code auf fehler prüft weil ja die algorythmen je nach zweck relativ dumm sein können und beim erfüllen ihrer aufgabe sachen erzeugen bei denen probleme in form von fehlern, performanceproblemen oder anderen sicherheitsrelevanten sachen aufkommen. ein guter programmierer sollte seinen code unter anderem auch handoptimieren weil die algorythmen ja nie wissen was wozu ist und so oder so kompiliert werden sollte aber welcher genervte programmierer wird in einem unternehmen bei starkem zeitdruck und ständigen planänderungen soweit kommen? im endeffekt ist es ihm einfach egal, kassiert die kohle und denkt sich das verfickte management kann ihn mal sonst wo. oder schau doch mal die unzähligen spiele die verbugt und unfertig auf dem markt kommen weil die den mund einfach zu voll genommen haben... so dabei der feinschliff fehlt kannst du davon ausgehen das auch der code entsprechend unsicher ist.

    Zitat Zitat von Kugelfisch23 Beitrag anzeigen
    Solch ein Compiler wäre mir nicht bekannt, zumindest nicht in praktisch nutzbarer Form ausserhalb der akademischen Welt. Zumindest verbreitete Compiler wie z.B. gcc, g++ oder die Microsoft-C/C++-Compiler tun das nicht. Kannst du ein Beispiel nennen?
    http://board.gulli.com/thread/128452...3#post10349883

    hier hätten wir ein beispiel wo, wie mir schien, automatisch erkannt wurde was ich programmieren wollte ohne es einzugeben?? beitrag 25, die compilierten ergebnisse sind anders gewesen und haben funktioniert obwohl der befehl nicht erklärt werden konnte

    ich weiß jetzt nicht genau ob es der compiler gewesen ist der von mir gelernt hat oder etwas anderes, jedenfalls haben sich ohne veränderungen der einstellungen oder irgendwas die compilierten ergebnisse in form vom erzeugten code geändert sowie einen frei erfundenen befehl automatisch erkannt. ich konnte es in einem neuen projekt auch nicht reproduzieren, der befehl funktionierte nur in dem alten projekt also hat irgendetwas aus dem projekt geschlussfolgert was ich vor habe oder so.

    Zitat Zitat von Kugelfisch23 Beitrag anzeigen
    Sicherlich wird nicht jeder Compiler-Bug sofort erkannt und - so er denn bekannt wird - umgehend behoben. Bugs, welche zu sicherheitsrelevanten Problemen oder gar zu konkreten ausnutzbaren Schwachstellen im erzeugten Code führen, werden jedoch spätestens dann erkannt, wenn Malware in freier Wildbahn die entsprechende Schwachstelle zu ihrer Verbreitung ausnutzen. Da die Verbreitung von Malware lukrativer ist als diverse Betrügereien in Spielen, würden solche Bugs wohl eher dazu ausgenutzt. Verglichen mit Schwachstellen im Quellcode war ihre Anzahl in den letzten Jahren jedoch verschwindend gering.
    ich lese desöfteren auch von methoden die dem hacken von webseiten immer wieder sehr ähnlich sind und bis heute nicht behoben wurden, ich würde auch soweit gehen und behaupten das man hier auch bewusst sicherheitslücken offen hält die nicht soviel aufmerksamkeit erregen das man sie schließen müsste

    Zitat Zitat von Kugelfisch23 Beitrag anzeigen
    Wenn der Server dazu gebracht werden kann, den Clients inkorrekte Daten weiterzuleiten, würde ich das durchaus als Problem auf der Serverseite betrachten. Der Server hat schliesslich die Autorität in einem Spiel (bzw. sollte sie haben). Wenn z.B. der Server allen Clients sagt, dass sich eine Spielfigur auf Einmal an einer komplett anderen Position befindet, ist es nicht die Aufgabe der Clients, diese Information zu überprüfen. Ebenso wenig kann ein Client im Allgemeinen überprüfen, welcher Spieler in wessen Namen welche Aktionen durchführt, sofern die Pakete alle vom Server kommen. Das muss der Server tun.
    desöfteren weiß man wohl im vorfeld nicht das funktionen die daten vom client weiterleiten bei ganz speziellen daten zu solchen fehlern führen die dann wenn es gut ist noch einen hohen nutzen bringen.

    Zitat Zitat von Kugelfisch23 Beitrag anzeigen
    Wenn ein Client durch eine Manipulation oder durch eine Fehlfunktion massiv höhere Serverlast verursacht, sollte ihn der Server aus dem Spiel entfernen und seine Pakete droppen, um die anderen Spieler vor den Auswirkungen zu schützen. Wenn ein Client langsamer läuft als erwartet, sehe ich darin kein Problem, da das Timing der eigentlichen Spielmechanik dem Server obliegen sollte. Stellt ein Client das Spielgeschehen langsamer dar, sollte das keine Auswirkungen auf den serverseitigen Spielablauf haben.
    hier ist nicht die rede von offensichtlich höherer serverlast durch einen client sondern vom client ausgehnden manipulationen die dann IM server IN seinen prozessen fehler oder höhere last erzeugen die sich nicht oder kaum auf den jeweiligen client zurückverfolgen lässt. habe ja schon gesagt das das solche sonst geblockt werden würden.

  19. #19
    ex-Moderator Avatar von Kugelfisch23
    Registriert seit
    Oct 2007
    Beiträge
    18.640
    Danksagungen
    458

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    Zitat Zitat von Matek0101 Beitrag anzeigen
    bei grafik-cheats ist es wie du sagst kaum möglich sie zu verhindern aber bei den bots brauchst du jawohl z.b. nur mal versuchen mit ihm zu reden wobei es verschiedene relativ einfache methoden gibt herauszufinden ob es ein bot ist.
    Weder die Frage, ob ein Client verändert wurde, noch die Frage, ob ein Client von einem Bot bedient wird, lässt sich zuverlässig klären. Man kann natürlich versuchen, heuristisch (z.B. durch automatisierte Turing-Tests - CAPTCHAs - oder durch Erkennung von Verhaltensmustern bekannter Bots) zu ermitteln, ob es sich um einen Bot handelt. Zuverlässig ist dies jedoch nicht, weder in Bezug auf falsch-negative (Bots entgehen der Erkennung) noch in Bezug auf falsch-positive Treffer (Benutzer werden irrtümlich als Bots klassifiziert).

    Anyway - darauf bezogen sich meine Bedenken gar nicht. Ein manipulierter Client, der Abläufe automatisiert oder zusätzliche Informationen anzeigt, wird sicherlich nicht zu
    [...] schweren technischen Fehlern, Bugs im Spiel sowie Stabilitäts- und Geschwindigkeitsproblemen auf Battle.net führen
    sondern dem Benutzer maximal einen vergleichsweise geringen Vorteil verschaffen, da er nach wie vor an die grundlegenden Regeln des Spiels gebunden ist. Verhindern lassen sich mit einer sicheren Implementierung jedoch sowohl echte Manipulationen an der Spielmechanik, z.B. die Manipulation von Charakterdaten zur Erzeugung oder Duplikation von Items, als auch gezielte oder versehentliche DoS-Angriffe auf den Server aufgrund einzelner(!) Clients (d.h. keine dDoS-Angriffe).

    Zitat Zitat von Matek0101 Beitrag anzeigen
    der compilierte maschinencode kann kein äquivalent des hochspachen-codes sein weil sich beide sehr stark in ihrer komplexität voneinander unterscheiden, ein einfachr befehl in hochsprache kann viel maschinencode beanspruchen was von compiler zu compiler und bibliothek zu bibliothek je nach dem mehr oder weniger stark variiert.
    Mit `Äquivalent` war in diesem Kontext gemeint, dass der erzeugte Maschinencode funktionell identisch mit dem ursprünglichen Hochsprachen-Code ist. Korrekt ist, dass beim Kompilieren Informationen in der Regel verloren gehen, die Kompilierung also keine bijektive Abbildung ist. Das betrifft übrigens bei der Erzeugung von optimiertem Maschinencode in der Regel nicht nur Kommentare und Bezeichner, sondern auch die Ablaufsteuerung durch Kontrollstrukturen. Dennoch muss der erzeugte Code am Ende für jede Eingabe dasselbe Ergebnis liefern wie der ursprüngliche Hochsprachen-Code, andernfalls liegt ein Compiler-Bug vor.

    Solche Bugs sind in verbreiteten und häufig benutzeren Compileren wie gcc/g++ oder den Microsoft-C/C++-Compilern bereits sehr selten, noch seltener dürften sie jedoch zu ausnutzbaren Schwachstellen führen. Im Allgemeinen wird lediglich ein Programmabsturz die Folge sein.

    Zitat Zitat von Matek0101 Beitrag anzeigen
    sie erzeugen den selben code wenn der hochsprachencode der selbe ist was wohl nicht der fall ist wenn ich von randomisierenden code rede.
    Dann stellt sich die Frage, was du genau mit `randomisierende[m]` Code meinst. Zufällig (=`random`) wird der Hochsprachen-Code kaum erzeugt worden sein, schliesslich wäre er dann im Allgemeinen weder syntaktisch oder semantisch korrekt, noch würde er ein definiertes Ergebnis liefern. Meinst du damit möglicherweise beliebigen (=`arbitrary`) Code, d.h. Code?

    Korrekt ist natürlich, dass der zu kompilierende Code insofern beliebig ist, als dass er zum Zeitpunkt der Compilerentwicklung unbekannt ist. Die Syntax und Semantik sind jedoch durch die Hochsprache vorgegeben, andernfalls liesse sich gar kein Compiler dafür entwickeln. Insofern ist mir unklar, worauf du an dieser Stelle hinaus möchtest.

    Zitat Zitat von Matek0101 Beitrag anzeigen
    der compiler brauch ja nur die ergebnisse an code zu optimierungszwecken von 2 verschiedenen codebereichnen die unterschiedliche zwecke erfüllen zusammenzulegen und schon öffnet das möglichkeiten für potentielle cheats.
    Das wird er nicht tun, sofern es das Ergebnis verändert, zumindest nicht im Rahmen sicherer Optimierungen (und in dieser Hinsicht unsichere Optimierungen sollte man - so sie denn aktivierbar sind - nicht aktivieren, wenn man den Compiler nicht genau kennt und genau weiss, was man tut).

    Zitat Zitat von Matek0101 Beitrag anzeigen
    eine fehler-reduktion sollte sehr wohl beim kompilieren des hoffentlich fehlerfreien quellcode stattfinden denn es gibt ja wohl beim kompilieren des codes mögliche konstellationen die ein höheres potential an fehlern aufweisen wenn z.b. wie im vorher genannten beispiel die zusammengelegten funktionen in irgendeiner form kompromitierend wirken weil sie z.b. höhere last erzeugen oder unter hoher last fehler generieren bzw. unter seltenen umständen einfach falsche werte kriegen weil beim programmieren des compilers nicht vorhergesehen werden konnte das die untereinander verknüpften befehle bei denen nie angenommen wurde sie werden untereinander verknüpft fehler generieren können.
    Eine seltsame Aussage. Der Compiler wird keine unsicheren Optimierungen vornehmen, sofern er nicht explizit dazu angewiesen wird. Wenn durch einen Bug oder eine fälschlicherweise vorgenommene unsichere Optimierung tatsächlich Fehler auftreten, werden sich diese im Allgemeinen nicht automatisiert erkennen lassen. Insbesondere dann nicht, wenn sie `nur` zu schwer quantifizierbaren Folgen wie einer erhöhten Last führen.

    Zitat Zitat von Matek0101 Beitrag anzeigen
    ein guter programmierer sollte seinen code unter anderem auch handoptimieren weil die algorythmen ja nie wissen was wozu ist und so oder so kompiliert werden sollte [...] so dabei der feinschliff fehlt kannst du davon ausgehen das auch der code entsprechend unsicher ist.
    Das Eine hat mit dem Anderen wenig zu tun. In Einzelfällen kann es durchaus sinnvoll sein, Code aus Performancegründen manuell zu optimieren bzw. bestimmte Teile manuell direkt in Assembler/Maschinencode zu übersetzen. Allerdings sind die Optimierungen moderner Compiler im Allgemeinen ausreichend und das Fehlerpotential bei manuellen Optimierungen gross.

    Für sicheren Code werden solche Optimierungen jedoch kaum sorgen - eher im Gegenteil, die Gefahr, dass bei der manuellen Optimierung Fehler entstehen, ist bei weitem höher als die Wahrscheinlichkeit, dass ein Compiler-Bug zu Fehlern im erzeugten Maschinencode führen.



    Zitat Zitat von Matek0101 Beitrag anzeigen
    http://board.gulli.com/thread/128452...3#post10349883
    hier hätten wir ein beispiel wo, wie mir schien, automatisch erkannt wurde was ich programmieren wollte ohne es einzugeben?? beitrag 25, die compilierten ergebnisse sind anders gewesen und haben funktioniert obwohl der befehl nicht erklärt werden konnte
    Mir ist zwar nicht bewusst, was genau das gewünschte Ergebnis war, jedoch wird dein (syntaktisch, jedoch nicht semantisch korrekter) Object-Pascal-Code im Allgemeinen kaum dazu führen, wie auch in den nachfolgenden Beiträgen erklärt wurde. Borlands Delphi-Compiler wird jedoch nicht
    [...] von selbst lernen und [seinen] Code aus dem was sie gelernt haben ändern
    denn solch eine (unsichere) Funktionalität wäre bestimmt in der Dokumentation erwähnt.

    Zitat Zitat von Matek0101 Beitrag anzeigen
    jedenfalls haben sich ohne veränderungen der einstellungen oder irgendwas die compilierten ergebnisse in form vom erzeugten code geändert sowie einen frei erfundenen befehl automatisch erkannt.
    Kaum. Einerseits kann ich keinen frei erfundenen `Befehl` erkennen - falls du den Length()-Funktionsaufruf meinst: Length ist eine Object-Pascal-Funktion, welche in der automatisch eingebundenen System-Unit definiert ist und die Länge eines Strings oder Arrays liefert. Allerdings wird dein Code wohl dennoch nicht kompilieren, da du versuchst, die zurückgelieferten und addierten Integer-Werte der Text-Eigenschaft eines TRichEdit-Objekts zuzuweisen. Meines Wissens akzeptiert der dazu definierte Property-write-Handler lediglich Strings als Werte. Möglicherweise hast du nach dem fehlgeschlagenen Kompilieren irrtümlich ein altes Kompilat ausgeführt?

    Anyway - die Ursachenforschung wird einerseits im Nachhinein kaum mehr möglich sein, andererseits hat der Vorfall kaum etwas mit der in diesem Thread angesprochenen Problematik zu tun.

    Zitat Zitat von Matek0101 Beitrag anzeigen
    ich lese desöfteren auch von methoden die dem hacken von webseiten immer wieder sehr ähnlich sind und bis heute nicht behoben wurden,
    Korrekt. Allerdings werden Webentwickler deshalb nicht (ähnlich einigen Spieleentwicklern) fordern, dass nur noch von ihnen verteilte Browser (=Clients) eingesetzt werden dürfen, welche diese Angriffe clientseitig zu unterdrücken versuchen, und andere Browser serverseitig auszusperren versuchen. Viel eher versuchen zumindest verantwortungsbewusste Webentwickler, Schwachstellen zu vermeiden oder zumindest bei Bekanntwerden umgehend zu schliessen.


    Zitat Zitat von Matek0101 Beitrag anzeigen
    hier ist nicht die rede von offensichtlich höherer serverlast durch einen client sondern vom client ausgehnden manipulationen die dann IM server IN seinen prozessen fehler oder höhere last erzeugen die sich nicht oder kaum auf den jeweiligen client zurückverfolgen lässt. habe ja schon gesagt das das solche sonst geblockt werden würden.
    Wenn sich durch bestimmte von manipulierten Clients übermittelte Daten eine stark erhöhte serverseitige Last erzeugen lässt, ist dies ein serverseitiger Fehler. Entweder wurde bei der Entwicklung nicht berücksichtigt, dass ein Client solche Daten übermitteln könnte (den Daten des Clients wird also vertraut, was ein Fehler ist), oder die Daten stammen von einem legitimen Client und der Server ist bloss ineffizient. Ersteres lässt sich serverseitig lösen, Letzteres hat keinen Zusammenhang mit manipulierten Clients.

  20. #20
    while(true) { Avatar von damnemokid
    Registriert seit
    Jun 2009
    Ort
    Nähe Freiburg
    Beiträge
    627
    Danksagungen
    3

    Standard Re: Diablo 3: Account-Sperren wegen veränderter Software

    Aus dem selben Grund wurd ich damals wegen eines WoW-Nacktpatchs gebannt

  21.  
     
     
Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •