Sichern Sie sich heute 20%. Verwenden Sie beim Bezahlvorgang den Code WELCOME. WILLKOMMEN

Wie FiveM Escrow entschlüsselt wurde – Eine klare, technische Erklärung…

Kurze Zusammenfassung: Sie haben die Verschlüsselung nicht geknackt. Angreifer haben den Moment erfasst, in dem FiveM selbst geschützte Dateien entschlüsselte und die entschlüsselten Ausgaben oder die temporären Schlüssel mitnahm. Der Fehler liegt in der Implementierung und der Laufzeit, nicht in der Mathematik.

Warum das wichtig ist

Wenn Sie kostenpflichtige FiveM-Ressourcen (Skripte, Karten, Modelle) verkaufen oder nutzen, garantiert Escrow, dass Ihre Arbeit vertraulich bleibt und an lizenzierte Server gebunden ist. Wenn Escrow fehlschlägt, verbreiten sich Lecks schnell. Sie verlieren Einnahmen und Kontrolle, und Ihr Server riskiert Sperren wegen der Verwendung von geleakten Assets.

Dieser Artikel erklärt in einfacher Sprache, wie Angreifer das Treuhandkonto von FiveM umgangen haben, welche zwei technischen Hauptwege sie dafür verwendet haben und was Sie zum Schutz der Ressourcen tun können.

Das Escrow-Verfahren ist nicht fehlgeschlagen, weil AES schwach ist. Es ist fehlgeschlagen, weil Angreifer entschlüsselte Daten oder die Schlüssel erbeutet haben, während FiveM sie selbst verwendet hat.

Wie ein Treuhandkonto funktionieren soll (einfach)

  1. Ein Ersteller lädt ein Asset zum Treuhandservice hoch. Das Asset wird in ein verschlüsseltes Paket eingefügt.
  2. Ein lizenzierter Server oder Client fordert das Asset an. Der Treuhanddienst überprüft die Lizenz und führt einen kurzzeitigen Entschlüsselungsschritt aus.
  3. Der Client oder Server entschlüsselt das Asset im Speicher und verwendet es. Das Asset sollte niemals in lesbarer Form außerhalb des Prozesses gespeichert werden.

Das System geht davon aus, dass Client und Server vertrauenswürdigen Code ausführen und dass Geheimnisse (Schlüssel) schnell aus dem Speicher verschwinden.

Die grundlegende Schwäche

Jedes System, das auf einem Benutzercomputer entschlüsselt, muss zur Laufzeit Klartext oder Schlüssel offenlegen. Wenn ein Angreifer diese Laufzeit kontrolliert oder überprüft, kann er den Klartext kopieren oder die Schlüssel abgreifen.

Zusamenfassend: Sie können Daten im Ruhezustand und während der Übertragung schützen, jedoch nicht, solange ein vertrauenswürdiger Prozess den Klartext speichert.

Zwei reale Angriffswege, die Angreifer nutzten

Die Angreifer verwendeten zwei effektive Ansätze. Beide basieren auf derselben Grundidee: Sie erbeuten das Asset in dem Moment, in dem FiveM es bereits entschlüsselt hat.

1) Modifizierte Server-Binärdatei -> entschlüsselten Lua-Bytecode ausgeben

Was sie getan haben, ist einfach:

  • Sie haben eine benutzerdefinierte FiveM-Server-Binärdatei erstellt und den Lua-Ressourcenlader geändert.
  • Der modifizierte Loader fing das Skript direkt nach der Entschlüsselung durch FiveM ab und schrieb den entschlüsselten Bytecode auf die Festplatte.
  • Sie haben einen Lua-Dekompiler auf diesem Bytecode ausgeführt, um verwendbare Skripte zu erhalten.

Warum es funktioniert hat:

  • FiveM muss ausführbaren Bytecode an die Lua-VM übergeben. Der modifizierte Server hat den Loader ersetzt oder eingehängt und diesen Bytecode abgezweigt.
  • Der Loader wird auf dem Server ausgeführt und ein Serverbesitzer kann eine benutzerdefinierte Binärdatei kompilieren und ausführen, sodass Angreifer sein Verhalten ändern könnten.

Einschränkungen:

  • Der Dump erzeugte kompilierten Bytecode, nicht den Originalquellcode mit Variablennamen oder Kommentaren. Dekompiler rekonstruieren funktionalen Code, nicht den ursprünglichen Authoring-Stil.
  • Diese Methode zielte auf Lua-Skripte ab. Sie stellte nicht ohne Weiteres alle gestreamten Assets wie komplexe Karten oder Modelle bereit.

Technische Nachweise und Referenzimplementierungen:

  • Mehrere Community-Beiträge und ein öffentliches Proof-of-Concept-Repository zeigen, wie man patcht Dateiintern laden in der Skriptkomponente, um den entschlüsselten Bytecode auszugeben. Weitere Informationen finden Sie im PoC-Repo auf GitHub.

2) Clientseitige Erfassung -> verschlüsselte Datei + Sitzungsschlüssel erfassen -> offline entschlüsseln

Was sie getan haben, ist einfach:

  • Sie zeichneten den Asset-Download des Clients auf oder beobachteten den Netzwerkverkehr.
  • Sie untersuchten den FiveM-Prozessspeicher, um den temporären Sitzungsschlüssel zu finden, den der Client zum Entschlüsseln des Assets verwendet hatte.
  • Sie kombinierten die erfasste verschlüsselte Datei und den Schlüssel, um das Asset auf ihrem Computer zu entschlüsseln.

Warum es funktioniert hat:

  • Der Client muss einen Entschlüsselungsschlüssel erhalten oder ableiten, um das Asset verwenden zu können. Wenn dieser Schlüssel lange genug im Speicher verbleibt, können Angreifer ihn finden.
  • Durch Netzwerkabfangen (lokaler Proxy, Paketerfassung oder Einbinden von Netzwerk-APIs) kann die verschlüsselte Datei während des Streamings erfasst werden.

Was dies Angreifern bietet:

  • Vollständige Assets, nicht nur Lua-Skripte. Dazu gehören Karten, Modelle, Texturen und andere gestreamte Inhalte, wenn der Angreifer die richtigen Dateien und Schlüssel erfasst.

Größte Schwäche bei der Umsetzung:

  • Schlüssel blieben länger als nötig im RAM oder wurden nicht sofort gelöscht. Angreifer haben den RAM gelesen und sie gefunden.

Warum die Verschlüsselung selbst nicht das Problem ist

Die Angreifer haben weder AES noch andere Standard-Chiffren geknackt. Sie die Umwelt zerstört wo Schlüssel und Klartext vorhanden sein müssen, damit das Spiel ausgeführt werden kann. Dies ist eine häufige Fehlerklasse bei DRM- oder clientseitigen Schutzmechanismen.

Stellen Sie sich das so vor: Sie verschließen eine Kiste mit einem Safe, doch jemand öffnet das Schloss, als er den Inhalt wirklich braucht, und macht ein Foto von der geöffneten Kiste. Das Schloss funktionierte noch. Der Angreifer nutzte die Tatsache aus, dass sich die Kiste an einer gut sichtbaren Stelle öffnete.

Wie Angreifer Bytecode in lesbaren und nutzbaren Code verwandelten

Der gedumpte Bytecode ist Low-Level. Es fehlen Variablennamen, aber er enthält die Logik und Funktionsstruktur. Angreifer verwendeten oder adaptierten Lua-Dekompiler, um lesbaren Code zu rekonstruieren. Das Ergebnis läuft auf die gleiche Weise und enthüllt die Logik des Autors.

Durch die Dekompilierung kommt es zu Störungen (umbenannte Variablen, andere Formatierung), aber das Ergebnis ist ein verwendbares, bearbeitbares Skript.

Was FiveM und die Macher nach den Leaks geändert haben

FiveM reagierte auf verschiedene Weise:

  • Sie haben Server aufgespürt und gesperrt, die durchgesickerte oder raubkopierte Assets verwendeten.
  • Sie haben Teile des Laders und des Schlüssels ausgetauscht. Handhabung um den ursprünglichen Proof of Concept wirkungslos zu machen.
  • Sie verschärften die Lizenzprüfungen und verkürzten die Lebensdauer der Schlüssel.

Diese Schritte legen die Messlatte höher. Sie machen die clientseitige Ausführung zwar nicht auf magische Weise sicher, aber sie reduzieren einfache Angriffswege.

Praktische Empfehlungen für Ersteller und Serveradministratoren (was Sie tun können)

Sie müssen die clientseitige Ausführung als nicht vertrauenswürdig behandeln. Erschweren Sie Lecks und begrenzen Sie den Schaden.

Für Kreative

  1. Split-Logik: Platzieren Sie kritische oder sensible Logik nach Möglichkeit auf dem Server. Beschränken Sie den Client-Code auf ein Minimum. Wenn eine Funktion keine clientseitige Logik erfordert, verschieben Sie sie auf serverseitige Prüfungen.
  2. Kurze Schlüssellebensdauer: Stellen Sie sicher, dass jeder Entschlüsselungsschlüssel nur für die kürzeste praktische Zeit existiert und dann sicher aus dem Speicher gelöscht wird.
  3. Verschleierung plus Treuhandkonto: Verwenden Sie mehrschichtige Schutzmaßnahmen. Treuhand, Verschleierung und rechtliche Kontrollen reduzieren zufällige Lecks. Verschleierung verlangsamt zwar Reverse Engineering, hält aber entschlossene Angreifer nicht auf.
  4. Schiffsintegritätsprüfungen: Integrieren Sie Integritätsprüfung und Remote-Widerruf. Wenn Sie ein Leck feststellen, widerrufen Sie die Ressource und machen Sie die Lizenzen schnell ungültig.
  5. Instrumentennutzung und Berichterstattung: Protokollieren Sie, welche Server welche Assets anfordern, damit Sie verdächtige Massendownloads erkennen können.

Für Serverbetreiber

  1. Führen Sie keine geänderten Binärdateien aus: Benutzerdefinierte Server-Binärdateien können durchgesickerte Inhalte ausführen. Verwenden Sie offizielle Builds, um zu vermeiden, dass Sie versehentlich zu einem Verteilungspunkt werden.
  2. Serverdateien und Berechtigungen überwachen: Verhindern Sie das automatische Dumping, indem Sie den Schreibzugriff einschränken und Laufzeitänderungen scannen.
  3. Lecks melden: Wenn Sie auf ein durchgesickertes Vermögen stoßen, melden Sie es dem Treuhänder, damit dieser gegen die Missbraucher vorgehen kann.

Was Verteidiger nicht vollständig verhindern können (seien Sie realistisch)

  • Sie können einen entschlossenen Angreifer mit vollständiger Kontrolle über einen Benutzercomputer nicht daran hindern, Klartext abzufangen. Wenn der Client ihn ausführen kann, kann ihn jemand mit lokaler Kontrolle kopieren.
  • Sie können sich bei der Durchsetzung der Lizenzierung nicht ausschließlich auf die Kryptografie verlassen, wenn die Entschlüsselung auf einem Benutzergerät erfolgt, über das Sie keine Kontrolle haben.

Der richtige Ansatz kombiniert technische Kontrollen, rechtliche Maßnahmen und aktive Überwachung.

Ein kurzes, einfaches Beispiel (kein Code)

  1. Server sendet verschlüsselt Skript.fxap zum Spieler.
  2. Der Player-Client erhält die Datei und den kurzlebigen Schlüssel.
  3. Der Client entschlüsselt die Datei im Speicher und übergibt den Bytecode an die Lua-VM.
  4. Ein Angreifer hakt sich in den Client- oder Server-Loader ein und kopiert den Bytecode während der Ausführung.
  5. Der Angreifer führt einen Lua-Dekompiler auf dem Bytecode aus und rekonstruiert lesbare Skripte.

Genau diese Abfolge ist in mehreren durchgesickerten Fällen passiert.

Rechtliche Angelegenheiten und Durchsetzung der Plattform

Treuhandanbieter können Server und Benutzer sperren, die durchgesickerte Daten verwenden. Dadurch wird der wirtschaftliche Anreiz für gelegentliche Piraterie beseitigt. Rechtliche Schritte und Sperren können jedoch nicht jeden motivierten Angreifer stoppen.

Zusammenfassung – der einzige Satz, den Sie in Ihrem Artikel verwenden können

Das Escrow-Verfahren scheiterte nicht an einer schwachen Verschlüsselung, sondern daran, dass die Angreifer den Moment der Entschlüsselung der Vermögenswerte durch das System selbst nutzten und den daraus resultierenden Klartext bzw. die Schlüssel mitnahmen.

Interne Links (weiterführende Literatur auf dieser Site)

Sehen Sie sich unsere QBCore-Ressourcen und Hinweise zur sicheren Bereitstellung an

Quellen und weiterführende Literatur

Mehr über FiveM Escrow
Lukas
Lukas

Ich bin Luke, ein Gamer und schreibe gerne über FiveM, GTA und Rollenspiele. Ich betreibe eine Rollenspiel-Community und habe etwa 10 Jahre Erfahrung in der Verwaltung von Servern.

Artikel570

Ähnliche Beiträge

Im Trend

FiveM-Leaks
140753 Sind FiveM-Leaks erlaubt? – FiveMX
FiveM-Server erstellen
So erstellen Sie einen FiveM-Server: Unverzichtbare Kurzanleitung
Beste vollständige QBCore-Server (FiveM) – Liste
Beste vollständige QBCore-Server (FiveM) – Liste
FiveM Server Hosting
FiveM Server Hosting – Must-Have mit der besten Leistung 2025