Randar: Minecraft-Schwachstelle knackt Server-RNG per LLL-Gitterreduktion

 (github.com/spawnmason)
1 Punkte von GN⁺ 2024-04-19 | 1 Kommentare | Auf WhatsApp teilen
  • Randar ist ein Exploit für Minecraft Beta 1.8 bis 1.12.2, der den Zustand von java.util.Random des Servers aus den Koordinaten von Item-Drops beim Blockabbau rekonstruiert und damit die Position anderer Spieler zurückverfolgt
  • Die Kernursache ist die Wiederverwendung derselben RNG: Terrain-/Strukturgenerierung und Mining-Events teilen sich denselben Zufallszahlengenerator, und beobachtbare Drop-Positionen liefern Hinweise auf den internen Zustand
  • Die X/Y/Z-Offsets eines Item-Drops sind drei aufeinanderfolgende Ausgaben von World.rand.nextFloat(), wodurch die oberen 24 Bit eines 48-Bit-Seeds preisgegeben werden und sich der Seed per LLL-Gitterreduktion schnell rekonstruieren lässt
  • Der rekonstruierte Seed wird rückwärts gespult und darauf geprüft, ob er aus einem Woodland-Mansion-Check stammt; falls ja, lässt sich die zuletzt geladene 1280×1280-Block-Woodland-Region identifizieren
  • Wenn frühere Paketmitschnitte etwa mit ReplayMod Drop-Daten enthalten, können Aktivitäten aus der Zeit von Beta 1.8 bis 1.12.2 auch nach einem späteren Server-Patch nachträglich offengelegt werden

Welche Informationen Randar angreift

  • Das Ziel ist, die Ingame-Koordinaten anderer Spieler in derselben Welt zu finden
  • 2b2t dient als Hauptbeispiel
    • 2b2t ist ein regelloser Minecraft-„Anarchy“-Server
    • Die Server-Map umfasst 3,6 Quadrillionen Quadrat-Tiles, daher ist die Geheimhaltung von Positionen die wichtigste Voraussetzung, um Items zu schützen
  • Schon vor Randar gab es auf 2b2t den Koordinaten-Exploit Nocom, der von 2018 bis 2021 genutzt wurde

Betroffene Versionen und der Codefehler

  • Das Problem existierte von der Veröffentlichung von Minecraft Beta 1.8 im Jahr 2011 bis zur Veröffentlichung von 1.12.2 im Jahr 2017
    • 2b2t blieb bis zum 14. August 2023 auf 1.12.2
  • Der zentrale Fehler war die unvorsichtige Wiederverwendung derselben java.util.Random-Instanz über mehrere Codepfade hinweg
    • Die RNG wurde zwischen Weltgenerierung und Spielaktionen wie Mining geteilt
    • java.util.Random ist zudem keine sichere RNG für Sicherheitszwecke
  • Minecraft verwendet deterministische Generierung, damit mit demselben World-Seed an derselben Position dasselbe Terrain entsteht
    • Dafür ist der Einsatz von java.util.Random naheliegend
    • Das Problem ist, dass die für die vorhersagbare Weltgenerierung gedachte Manipulation der RNG auch Events beeinflusste, die eigentlich nicht vorhersagbar sein sollten

Woodland-Mansion-Checks und globales World.rand

  • Beim Prüfen, wo Woodland Mansions erzeugt werden, wird World.rand zurückgesetzt
    • Woodland-Regionen werden in Einheiten von 80×80 Chunks berechnet
    • Um den Chunk auszuwählen, in dem in einer Region eine Mansion erzeugt wird, wird random.nextInt(60) viermal aufgerufen
  • Der verwundbare Ablauf besteht darin, dass World.setRandomSeed(seedX, seedY, seedZ) einen neuen Seed in das globale this.rand schreibt und dasselbe Objekt zurückgibt
  • Die 2b2t-spezifische Formel lautet wie folgt
seed = x * 341873128712 + z * 132897987541 - 4172144997891902323 mod 2^48
  • setRandomSeed wird nicht nur in der Nähe echter Woodland Mansions aufgerufen, sondern bei jedem Chunk-Load zu Prüfzwecken
  • Die Auswirkungen unterscheiden sich je nach Dimension
    • Die Overworld ist das Hauptziel der Auswirkungen
    • Der Nether ist sicher, weil die Strukturgenerierung dort immer eine sichere RNG verwendet
    • The End ist wegen End Cities bei der ersten Generierung betroffen, bei späteren Reloads desselben Chunks aber nicht erneut, und daher vergleichsweise sicher

Wie Item-Drop-Koordinaten die RNG offenlegen

  • Wenn ein Block abgebaut wird, droppt das Item an einer zufälligen Position innerhalb des Blocks
    • Bei Blockkoordinaten (10, 20, 30) erscheint das Item zum Beispiel zwischen (10.25, 20.25, 30.25) und (10.75, 20.75, 30.75)
  • Diese Position wird durch drei Aufrufe von world.rand.nextFloat() für die X-, Y- und Z-Offsets bestimmt
  • Aus den Drop-Koordinaten lässt sich auf die ursprünglichen nextFloat()-Werte zurückrechnen
    • Das Multiplizieren des Floats mit 0,5 reduziert nur den Exponenten und verursacht keinen Informationsverlust
    • Danach wird in double umgewandelt und die Blockkoordinate addiert; übertragen wird über das Netzwerk in voller Präzision
  • java.util.Random.nextFloat() aktualisiert den 48-Bit-Seed und entnimmt anschließend die oberen 24 Bit als Integer, der durch 2^24 geteilt wird
    • Die LCG-Formel lautet newSeed = oldSeed * 25214903917 + 11 mod 2^48
    • Drei aufeinanderfolgende Floats liefern also die oberen 24 Bit von drei aufeinanderfolgenden Seeds

Seed-Rekonstruktion per LLL-Gitterreduktion

  • Die einfache Methode wäre, alle 2^24 Kandidaten für die unteren 24 Bit zu testen, die zum ersten Messwert passen
    • Das funktioniert ebenfalls, ist aber langsam, daher wird der Gitteransatz verwendet
  • Die drei Messwerte liefern Bereiche für die folgenden drei Werte
    • seed
    • nextSeed(seed)
    • nextSeed(nextSeed(seed))
  • Betrachtet man diese drei Werte als den 3D-Punkt (seed, nextSeed(seed), nextSeed(nextSeed(seed))), bilden alle möglichen Seeds eine Gitterstruktur
  • Die Basisvektoren werden wie folgt gewählt
    • (1, a, a^2)
    • (0, c, 0)
    • (0, 0, c)
    • wobei a = 25214903917, c = 2^48
  • LLL basis reduction findet eine kürzere, nahezu orthogonale Basis, die dasselbe Gitter erzeugt
    • Das Mathematica-Beispiel lautet LatticeReduce[{{1, a, a^2}, {0, c, 0}, {0, 0, c}}]
    • Die resultierende Basis ist (1270789291, -2446815537, 2154219555), (-2355713969, 1026597795, 4110294631) und (-3756485696, -2345310016, -2015749696)
  • Wenn das Zentrum des Messwürfels in den Raum der reduzierten Basis transformiert und jeder Koeffizient auf die nächste ganze Zahl gerundet wird, erhält man einen gültigen Gitterpunkt; die erste Koordinate ist der rekonstruierte interne Seed
  • Ein optimiertes Java-Beispiel kann den Seed aus drei Messwerten in etwa 10 ns rekonstruieren

Den Seed zurückspulen und die Position finden

  • Das LCG von java.util.Random lässt sich sowohl vorwärts als auch rückwärts durchlaufen
    • Vorwärts: newSeed = oldSeed * 25214903917 + 11 mod 2^48
    • Rückwärts: oldSeed = (newSeed - 11) * 246154705703781 mod 2^48
  • Der rekonstruierte Seed wird rückwärts gespult und bei jedem Schritt darauf geprüft, ob er ein Seed aus einem Woodland-Mansion-Check sein könnte
  • Der Minecraft-Weltbereich reicht von -30 Millionen bis +30 Millionen Blöcken
    • In der Implementierung entspricht das einem Woodland-Region-Bereich von -23440 bis +23440 pro Achse
    • Die Zahl möglicher Woodland-Regionen beträgt (23440*2+1)^2, also 2.197.828.161
  • Alle 2,2 Milliarden Kandidaten direkt zu vergleichen ist langsam, und auch ein großes HashSet verbraucht viel Speicher
  • Weil der Z-Koeffizient 132897987541 ungerade ist, besitzt er modulo 2^48 ein Inverses
    • Das Inverse ist 211541297333629
    • Damit müssen nur noch alle 46.881 möglichen X-Werte durchlaufen werden, um Z zu berechnen und Kandidatenregionen zu finden

GPU- und Lookup-Table-Optimierungen

  • Das reine Durchlaufen von X ist für einen einzelnen Seed praktikabel, aber wenn viele Bots pro Sekunde mehrere Blöcke abbauen und für jede Messung Tausende RNG-Schritte prüfen, war Echtzeitverarbeitung auf einem schwachen VPS nicht machbar
  • Die Implementierung wurde später auf CUDA-Batch-Jobs und eine Lookup-Tabelle umgestellt
    • Der Schlüssel der Tabelle sind die unteren 32 Bit des Mansion-Seeds
    • Der Wert ist die X-Koordinate der Woodland-Region
    • Bei den unteren 32 Bit traten keine Kollisionen auf; der Grund dafür sei unklar geblieben
  • Die Tabelle verwendet 2^32 Einträge mit je 2 Byte und benötigt damit etwa 9 GB VRAM
  • Auf einer RTX 3090 konnten rund 10 Millionen Seeds pro Sekunde geknackt werden
  • Das Rekonstruktionsergebnis zeigt die zuletzt geladene 1280×1280-Block-Woodland-Region an; das reicht aus, um die Position innerhalb weniger Minuten zu finden

In realen Servern beobachtete Step-Verteilungen

  • Theoretisch liegt der durchschnittliche Abstand zwischen Woodland-Seeds bei etwa 128.000 RNG-Schritten
  • Auf 2b2t wurde ein Woodland-Seed meist schon nach wenigen Dutzend Schritten gefunden
    • Die Messung erfolgt beim Paket-Handling sehr früh im Tick
    • Meist wurde der Chunk bereits im vorherigen Tick geladen
  • Verlässliche Messungen beginnen bei mindestens 4 RNG-Schritten
    • Denn der Woodland-Mansion-Code ruft vor der Beobachtung viermal rand.nextInt auf
  • Große Spikes treten bei Vielfachen von 1354 Schritten auf
    • Als mögliche Ursache werden End-Crystal-Explosionen oder Wither-Schädel genannt
    • Bei End-Crystal-Explosionen passt die Blockschadensberechnung 16^3-14^3=1352 plus zwei Soundeffekte zu 1354 Schritten

ReplayMod und das Risiko nachträglicher Offenlegung

  • Selbst wenn ein Server auf eine aktuelle Version aktualisiert oder die RNG-Manipulation gepatcht wurde, bleibt das Randar-Risiko bestehen, solange alte Daten erhalten sind
  • Manche Minecraft-Spieler zeichnen Pakete mit Mods wie ReplayMod auf
    • Wenn die Aufzeichnung Item-Drops enthält, lässt sich daraus der damalige Zustand der Server-RNG rekonstruieren
    • Blockabbau ist extrem häufig, daher ist es wahrscheinlich, dass solche Daten enthalten sind
  • Alle Positionen, die in Beta 1.8 bis 1.12.2 aktiv genutzt wurden, müssen als offengelegt betrachtet werden, selbst wenn der Server längst aktualisiert wurde
  • Es gibt ein clientseitiges Web-Tool, mit dem sich Randar direkt ausprobieren lässt
    • Unter hobune.stream/randar kann man eine ReplayMod-Datei für 1.12.2 per Drag-and-drop laden und Koordinaten prüfen
    • Die Aufzeichnungsdatei verlässt den Browser nicht

Betrieb von Randar und Heatmaps

  • SpawnMasons begann, auf Accounts, die ohnehin rund um die Uhr Stone/Cobblestone für andere Projekte abbauten, die Item-Drop-Koordinaten mitzuschreiben
  • Das für Nocom verwendete headless-Minecraft-System wurde wiederverwendet und für die Speicherung der Messwerte um eine Postgres-Datenbank ergänzt
  • Die Software zum Knacken der RNG-Messwerte wurde mehrfach verbessert und landete schließlich bei asynchronen CUDA-Batch-Jobs
  • Sobald geknackte Messwerte in die Datenbank eingetragen werden, wird auch die Heatmap-Analysetabelle aktualisiert
    • Sie speichert Hit-Counts für den Gesamtzeitraum, pro Tag und pro Stunde
    • Über eine Plotly-Dash-UI lassen sich Zeitbereich und Granularität im Browser auswählen
  • Chunk-Load-Spam durch Elytra-Stash-Hunting wird herausgefiltert, indem nur Koordinaten berücksichtigt werden, die über mehrere unterschiedliche Stunden hinweg geladen wurden
  • Um entdeckte Hotspots nachzuverfolgen, wurde außerdem ein einfaches gemeinsames Annotationssystem ergänzt
  • Mit einem aus Nocom übernommenen Baritone-Bot wurde das Stehlen und Aufräumen von Item-Stashes AFK automatisiert

Schutz durch decoy Woodland-Regionen

  • Randar findet nicht immer den zuletzt geladenen Chunk exakt
    • Wenn beim Zurückspulen der RNG zuerst eine neuere decoy Woodland-Region auftaucht, kann ein Exploit, der den ersten Treffer zurückgibt, ein False Positive erzeugen
  • Im Durchschnitt ist nur etwa einer von 130.000 RNG-Seeds ein Woodland-Seed, die Verteilung enthält jedoch Ausreißer
  • Auf 2b2t soll ungefähr eine von 20.000 Woodland-Regionen die spezielle Eigenschaft besitzen, innerhalb der nächsten 4 RNG-Schritte eine weitere Woodland-Region zu haben
  • SpawnMasons legte Stashes in solchen Regionen an
    • Wegen der Render-Distanz wurden die Strukturen kompakt gebaut, damit keine Chunks außerhalb der Schutzregion geladen werden
    • An der decoy-Position wurde ein AFK-Account mit einer kleinen Base platziert, damit andere Randar-Nutzer die decoy-Position sehen
  • Laut den eigenen Randar-Logs waren diese Stashes über den gesamten Zeitraum „clean“, also ohne versehentlich geladene benachbarte Woodland-Regionen
  • Zum Zeitpunkt der Veröffentlichung seien diese Stashes bereits verlegt worden

Vollständige Beispiele und versionsspezifische Einschränkungen

  • Es wird ein Java-Beispiel bereitgestellt, das in SPacketSpawnObject wie Mining-Drops aussehende Items erkennt, die Drop-Koordinaten in drei Float-Messwerte zurückrechnet und anschließend das LLL-basierte Knacken sowie die Rückverfolgung der Woodland-Region ausführt
  • Ein reales Messbeispiel von 2b2t ergibt folgende Werte
    • item drop: 0.41882818937301636, 0.6833633482456207, 0.46088552474975586
    • RNG measurements: 5664934 14541261 7076144
    • interner Seed: 95041827771683
    • Woodland-Region: -12008 0
    • Positionsbereich: -15370368,-128 bis -15369089,1151
  • Das Diagrammbeispiel findet Woodland-Region 123,456
    • Der finale Positionsbereich ist 157312,583552 bis 158591,584831
    • Er enthält die ursprüngliche Eingabeposition x=157440 z=583680
  • Vor Version 1.11 ist die ausnutzbare Struktur nicht Woodland Mansion, sondern eine andere Struktur; dafür ist anderer Code nötig
  • Vor 1.9 wird die Item-Position nicht als double, sondern mit 5-Bit-Fixed-Point-Nachkommaanteil übertragen, weshalb das Knacken des RNG-Zustands mit nur einem Item unrealistisch ist und andere Messstrategien nötig sind

So lässt sich das patchen

  • Der einfache Weg ist, einen Patch oder eine Konfiguration zu finden, die die RNG-Manipulation deaktiviert
  • In der verwundbaren Implementierung setzt World.setRandomSeed den Seed im globalen this.rand und gibt dieses Objekt zurück
public Random setRandomSeed(int seedX, int seedY, int seedZ) {
    this.rand.setSeed(seedX * 341873128712L + seedY * 132897987541L + seedZ + this.getWorldInfo().getSeed());
    return this.rand;
}
  • Wenn vollständiger Schutz gewünscht ist, kann stattdessen bei jedem Aufruf ein neues Random zurückgegeben werden
public Random setRandomSeed(int seedX, int seedY, int seedZ) {
    return new Random(seedX * 341873128712L + seedY * 132897987541L + seedZ + this.getWorldInfo().getSeed());
}
  • Wenn die Performance Sorgen macht, kann ein separates RNG-Feld nur für die Weltgenerierung wie separateRandOnlyForWorldGen eingeführt werden, das nicht mit anderen Zwecken geteilt wird
  • Ein Patch für PaperMC 1.12.2 ist über den PaperWithRandarPatched commit und eine alternative Patch-Datei verfügbar

Anhang von n0pf0x: andere Wege zur Koordinatensuche und The End

  • n0pf0x verwendet statt der großen GPU-Lookup-Tabelle der Mason-Seite eine cachebasierte Koordinatensuche
    • Wenn ein Hit auftritt, werden diese Koordinate und Koordinaten im Umkreis in eine HashMap eingetragen
    • Im ersten Pass wird die RNG rückwärts gespult und schnell auf Cache-Treffer oder Duplikate mit dem zuletzt verarbeiteten Seed geprüft
    • Der zweite Pass läuft nur dann, wenn der erste fehlschlägt, und verwendet den zuvor beschriebenen teuren Koordinaten-Suchalgorithmus
  • Dieser Cache-Ansatz kann helfen, False Positives zu reduzieren, weil weniger plausible gültige Positionen übersprungen werden
  • In The End wirkt sich die RNG nur bei der ersten Chunk-Generierung aus, weshalb sich wiederholte Base-Chunk-Loads wie in der Overworld schwerer beobachten lassen
  • In The End gibt es zwei Situationen, auf die man sich verlassen kann
    • Ein Spieler an einer Base läuft herum und erzeugt dabei noch nicht generierte Chunks
    • Ein Spieler auf dem Weg zu einer Base erzeugt entlang seiner Route eine Spur neuer Chunks
  • Für solche Trails wäre ein automatisches Identifikationssystem möglich, n0pf0x hat es aber nicht implementiert und stattdessen visuell manuell verfolgt
  • Zur Spieleridentifikation wird die Idee eines End Occupancy Tracker (EOT) verwendet
    • Sie basiert auf der Annahme, dass die Zahl der RNG-Aufrufe pro Tick grob mit der Zahl der geladenen Chunks korreliert und diese wiederum mit der Zahl der Spieler in dieser Dimension zusammenhängt
    • Geschätzt wird die Zahl der Spieler in The End anhand von Anstiegen oder Rückgängen der RNG-Aufrufe direkt nach Join/Leave-Ereignissen
  • EOT wurde nur auf 9b9t getestet und funktioniert unter anderen Serverbedingungen wie auf 2b2t möglicherweise nicht
    • Die RNG muss pro Tick zuverlässig gesampelt werden können
    • Wenn die Aktivität von Spielern in The End deutlich höher ist, kann es noch schwieriger werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-19
Hacker-News-Kommentare

  • 1999–2000 gab es die International RoShamBo Programming Competition, bei der Computer-Bots in Schere, Stein, Papier gegeneinander antraten [1]
    Der Referenz-Bot wählte zufällig, also eine theoretisch nicht zu schlagende Strategie; ein scherzhafter Beitrag war jedoch so konstruiert, dass er den Zustand des Zufallszahlengenerators zurückrechnete und mit 100 % Genauigkeit vorhersagte, was der Zufallsspieler als Nächstes spielen würde.
    Nachtrag: Dieser Bot war Tim Dierks’ „Nostradamus“ und wurde beim ersten Wettbewerb zum Sieger in der Kategorie „supermodified“ erklärt [2]
    [1] https://web.archive.org/web/20180719050311/http://webdocs.cs...
    [2] https://groups.google.com/g/comp.ai.games/c/qvJqOLOg-oc

    • Das war ich. Schön, dieses alte Zitat wiederzusehen: „Mit seinen hervorragenden technischen Fähigkeiten und der Einstellung ‚früh und oft betrügen‘ könnte Tim eine vielversprechende Karriere als KI-Programmierer in der Computerspielbranche haben :)“
      Tatsächlich bin ich in den Security-Bereich gegangen, habe TLS-RFCs geschrieben und wurde Principal Engineer für Security bei Google. Danke fürs Wiederauflebenlassen der Erinnerung.
    • Im ersten Jahr habe ich den optimal schlechten Beitrag cheesebot eingereicht.
      https://web.archive.org/web/20180719050236/http://webdocs.cs...
    • Die komplette Beschreibung der Beiträge in der Kategorie „supermodified“ ist einfach zu komisch.
      Nostradamus wurde von Tim Dierks geschrieben, VP of Engineering bei Certicom mit viel Kryptografie-Expertise, und schlug den optimalen Spieler, indem er den internen Zustand des random()-Generators reverse-engineerte. Nach eigener Aussage war es „sowohl leichter als auch schwerer als erwartet“. Aus Sportsgeist spielte er gegen alle anderen Gegner aber optimal.
      Fork Bot entstand aus einer Idee, die Dan Egnor ein paar Minuten nachdem er von dem Wettbewerb gehört hatte, kam; er nutzte die „Bibliotheksroutinen erlaubt“-Regel, startete mit fork() drei Prozesse, ließ jeden einen anderen Zug spielen und tötete die beiden, die verloren. Andreas Junghanns implementierte das in etwa 10 Zeilen Code, aber nach der ersten Runde verloren alle drei Züge gegen Psychic Friends Network, das Programm beendete sich, und die restlichen Partien wurden als aufgegeben gewertet.
      Psychic Friends Network war wirklich urkomischer obfuskativer C-Code von Michael Schatz und Leuten der RST Corporation; er enthielt Hilfsfunktionen zum Auffinden von gutem Karma, astrologische Beratung, Spaghetti- und mystische Pizza-Gerichte, machte per #define Demokraten zu Kommunisten, undefte Gott und so weiter. Was genau es mit dem Stackframe macht, wird noch untersucht, aber solange es nicht gegen einen Meta-Meta-Cheater antritt, erzielt es in keiner Partie weniger als +998.
      The Matrix wurde von Darse Billings geschrieben, der den prestigeträchtigen Titel „Student for Life“ trägt, und besiegte nach dem einfachen Prinzip „Es gibt keinen Löffel“ alle Gegner mit perfekter Punktzahl.
      The Matrix ist zugleich das Turnierprogramm und hat daher vollständigen Zugriff auf alle anderen Algorithmen, Datenstrukturen und Ausgaberoutinen; es dürfte also auch künftig kaum zu übertreffen sein. Daher wurde diese Kategorie für gelöst erklärt und in späteren Wettbewerben abgeschafft.
    • Ich erinnere mich, dass jemand bei einer Online-Pokerseite, die in einem lobenswerten Versuch, transparenter zu sein, ihren Pseudozufallszahlengenerator dokumentiert hatte, dasselbe getan hat.
      Am Ende hat diese Transparenz tatsächlich die Sicherheit verbessert.
    • Dann haben sie also einen Pseudozufallszahlengenerator verwendet?

  • LLL-Gitterreduktion ist genau der Algorithmus, der vor ein paar Tagen auch in der CVE verwendet wurde, um PuTTY-Schlüssel mit verzerrten Nonces zu knacken.
    tptacek hat den Angriff ein wenig erklärt und auch auf eine cryptopals-Aufgabe verlinkt, bei der man, wenn man die Augen zusammenkneift, fast so tun kann, als würde man sie verstehen: https://news.ycombinator.com/item?id=40045377
    Ähnlich gab es auf dem SciCraft-Minecraft-Server eine Creeper-Farm, die mit irgendeiner Art schwarzer Magie den Zustand des Zufallszahlengenerators deterministisch manipulierte, sodass in jedem Frame „zufällige“ Blitze auf bestimmte Blöcke einschlugen und die Creeper-Drops besser wurden: https://youtu.be/TM7SutJyDCk

    • Sean und Kelby erklären viel besser, was LLL ist, aber warum LLL existiert, erklärt dieser Artikel so gut wie kaum etwas, das ich bisher gesehen habe.
      In allen drei Fällen braucht man nur grundlegende lineare Algebra, und nicht einmal besonders viel davon. Kelby setzt voraus, dass man Gram-Schmidt versteht; das ist Stoff, der ungefähr kurz vor der Zwischenprüfung in einer einführenden Lineare-Algebra-Vorlesung im Bachelor kommt.
      Ich finde kaum Worte dafür, wie großartig dieser Artikel ist. Er hat mir die Woche versüßt.
      Eine sehr knappe Erklärung desselben Ablaufs, die man später in Python nachvollziehen kann:
      https://crypto.stackexchange.com/questions/37836/problem-wit...
    • Es gibt auch Zufallsmanipulation, mit der Blöcke immer mit dem Maximalwert droppen; das wird hier erklärt:
      https://youtu.be/ZcdN1wCJPqM?t=390
    • „Schwarze-Magie-Gerät“ und „wenn man die Augen zusammenkneift, kann man fast so tun, als würde man es verstehen“ beschreiben ziemlich gut, wie ich auf Kryptografie schaue :D

  • Man wacht morgens auf und stellt fest, dass Blöcke, die am Vorabend noch nicht da waren, in der Luft schweben; erst wirken sie geisterhaft, wie Nebel, dann erkennt man Redstone, Observer und Slime-Blöcke, und vor dem inneren Auge sieht man endlos herabfallendes TNT
    Und das nur, weil der Server meine Position geleakt hat. Trotzdem kann man vielleicht noch fliehen, in ein paar Sekunden aus einer Kiste das Nötigste holen und wegrennen oder vielleicht noch einen Obsidian-Unterschlupf bauen. Aber das war’s dann auch
    Für eine präzise ausgerichtete Kanone reicht die Zeit nicht, und die Höhe wird man ohnehin nicht treffen. Wenn man Elytren und Raketen hat, könnte man vielleicht hinfliegen und stören, aber direkt 16 Chunks entfernt klafft ein riesiges World-Eater-Loch. Ob sie wohl an jedem Netherportal in der Nähe Lavafallen gelegt haben?

  • Ich habe schon viele interessante und lustige Probleme mit Zufallszahlengeneratoren gesehen, aber das hier ist einer der ausgefeiltesten Exploits gemessen daran, was man dafür bekommt. Fast wie ein tolles Kunstwerk

    • Wenn sie das Item verkauft hätten, hätten sie vielleicht etwas Geld verdienen können, möglicherweise ein paar Tausend Dollar. Gemessen am Arbeitsaufwand wäre das natürlich immer noch eine geringe Belohnung
    • Ich finde großartig, wie scheinbar harmlose Entscheidungen der Mojang-Entwickler hier ausgenutzt werden. Extrem cool

  • Ein ziemlich cooler Exploit
    Die Idee eines Servers, auf dem Bug-Ausnutzung erlaubt ist, ist auch ganz gut und wirkt wie eine völlig andere Stufe des Spiels
    Wenn das Metaverse tatsächlich passiert, dann stelle ich mir „wirklich kämpfen“ eher so vor, statt einfach nur In-Game-Kampfmechaniken zu benutzen

    • 2b2t-Kämpfe sehen auch nicht wie normales Minecraft aus
      Weil es seit langer Zeit viele duplizierte High-End-Items gibt, besteht PvP daraus, ständig Ender-Kristalle zu spammen, die beim Zerstören enormen Schaden verursachen; Verteidigung heißt, möglichst viele „Totems der Unsterblichkeit“ zu haben, die tödlichen Schaden abfangen
      Natürlich automatisieren Hack-Clients das Platzieren von Ender-Kristallen, das Nachladen von Totems sowie das Erkennen schwacher und starker Positionen, und die Spieler folgen diesen Hinweisen, um kontinuierlich Schaden zu verursachen
      Etwas davor gab es auch noch ein gehacktes Schwert mit +32.767 Schaden, das sofort tötete, bis es serverseitig gepatcht wurde
    • Dass sich das Gleichgewicht um Bugs und Exploits herum einpendelt, ist in hart umkämpften PvP-Sandbox-Spielen ziemlich typisch, selbst wenn der Server es nicht ausdrücklich erlaubt
      ARK: Survival Evolved und Eve Online sind berüchtigt dafür, dass riesige Clans mit Tausenden Mitgliedern beim Metagame und bei der Ausnutzung von Bugs extrem weit gehen
      Romantisch ist das nicht immer. In ARK gab es Mechaniken, mit denen man Spieler und ihre verschiedenen Steam-Accounts doxxen konnte, und während des Great War scheinen sich In-Game-Beziehungen teilweise in die reale Welt verlagert zu haben
      Manchmal sind es auch ganz einfache Methoden. Wenn man etwa während eines Raids einen riesigen Turm baut und ihn einstürzen lässt, um den Server per Denial of Service zum Crash zu bringen, rollt der Server auf ein Backup von vor 10 bis 20 Minuten zurück; dadurch wurden Basen mit aktiven Spielern sehr schwer zu raiden. Das ist ein uralter Trick und wurde vor Jahren behoben
      Rust hatte auch eine Policy, die dazu ermutigte, Bugs und Exploits auf YouTube zu verbreiten und öffentlich zu machen, allerdings aus einem anderen Grund: Die Entwickler sollten schneller darauf aufmerksam werden und sie patchen. Das Ergebnis ist ein ziemlich robustes Spiel, das sich ohne echte externe Cheats nur sehr schwer missbrauchen lässt
    • Ein Mittelweg ist Super Smash Bros Melee. Viele in Turnieren erlaubte In-Game-Taktiken beruhen auf Bugs
      Allerdings nur solche, die man mit einem normalen Controller manuell ausnutzen kann, kein echtes Hacking. Ein Exploit namens Wobbling wurde 2019 verboten; das Spiel stammt aus dem Jahr 2001
    • Aus Gameplay-Sicht gefiel mir die Idee eines echten Anarchie-Servers ziemlich gut, aber im echten 2b2t habe ich aufgehört, weil im Chat viel zu oft das N-Wort fiel
    • Ein „Server, auf dem Bug-Ausnutzung erlaubt ist“ – ist das nicht praktisch jeder CS-1.6-Server ohne VAC?

  • Ich habe mir gerade ein Video zu diesem Thema angesehen. Es ist ein klares warnendes Beispiel dafür, wie gefährlich es sein kann, wenn Quellen von Zufälligkeit miteinander interagieren, und das gilt auch für viele wichtige Systeme
    Aus Performance-Gründen teilt man im Code oft Zufallszahlengeneratoren; solche Geschichten lassen einen da definitiv innehalten

    • Ich glaube nicht, dass ich in ernsthafter Software je einen Pseudozufallszahlengenerator verwendet habe, aber intuitiv hätte ich gedacht, dass solche Angriffe schwieriger werden, wenn man denselben Zufallszahlengenerator an möglichst vielen Stellen benutzt
      Weil es dann schwieriger schiene, genügend Update-Punkte zu beobachten. Dieser Fall zeigt jedoch ziemlich eindrucksvoll und unterhaltsam, dass diese Intuition falsch ist

  • Dieses Video ist erstaunlich: https://www.youtube.com/watch?v=maMpMOnIJDE
    Ich wusste nicht, dass die Community so ausgefeilt ist

  • Darüber hinaus wurde diese Art von Knacken eines Zufallszahlengenerators sogar innerhalb des Spiels umgesetzt
    https://youtu.be/FPmQ0rnJjNc?si=tTFObcfZ-ILanL_A

  • Erstaunlicherweise gibt es eine Maschine namens Mess Detector, die in Minecraft selbst gebaut wurde. Statt Block-Drops nutzt sie die Position von gezündetem TNT, um den internen Zustand des Zufallszahlengenerators vorherzusagen
    https://www.youtube.com/watch?v=FPmQ0rnJjNc

  • Das sieht aus wie ein State-Compromise-Extension-Angriff (https://en.wikipedia.org/wiki/Random_number_generator_attack)
    Das ist ein Angriff, dem ein PRNG ausgesetzt sein kann, der kein kryptografisch sicherer Pseudozufallszahlengenerator (CSPRNG) ist
    Inzwischen fühlt es sich nicht mehr besonders sicher an, wenn Bibliotheken PRNGs überhaupt als Standard anbieten. Ähnlich, als würde man 2024 TLSv1.0 oder Blowfish standardmäßig zulassen