BSP Obfuscation: was sie bei GMod Maps bewirkt
BSP Obfuscation verändert eine kompilierte Map so, dass sie normal läuft, sich aber schwerer rekonstruieren lässt. Wirkung, Risiken und Grenzen.
BSP Obfuscation verändert die Darstellung einer kompilierten Map so, dass die Engine sie weiterhin normal lädt, Werkzeuge zur Rekonstruktion aber weniger brauchbare Ergebnisse liefern. Sie macht eine Map nicht unlesbar und ist kein Kopierschutz. Ihr Zweck ist, das bequeme Dekompilieren und Weiterbearbeiten aufwendiger zu machen.
Was Obfuscation bei einer BSP bedeutet
Den Begriff kennst du vielleicht von Programmcode: Ein obfuskiertes Script tut dasselbe wie vorher, ist für Menschen aber schwer nachzuvollziehen. Bei einer Map ist die Idee ähnlich.
Eine BSP enthält zwei Arten von Informationen. Die erste braucht die Engine, um die Map darzustellen und zu simulieren. Die zweite hilft vor allem Menschen und Editoren: sprechende Pfade, Editor-Kennungen, Reste aus dem Arbeitsprozess.
Obfuscation setzt bei der zweiten Art an und kann in mehreren Schritten arbeiten:
- Informationen reduzieren. Was die Engine nicht braucht, kann weg. Dazu gehören Editor-Kennungen an Entities sowie Quelldateien, Compile-Logs und Backup-Reste, die versehentlich im Pakfile gelandet sind. Dieser Teil wird auch Cleanup genannt.
- Darstellung verändern. Die Datei wird so umgebaut, dass sie sich weniger direkt in eine komfortable Editor-Fassung zurückführen lässt. Ein anschauliches Beispiel sind Materialpfade: Aus einem sprechenden Pfad wird ein neutraler, und die Verweise in der Map werden passend angeglichen.
Was Obfuscation erschwert
- Automatische Rekonstruktion. Ein Decompiler liefert weniger saubere Ergebnisse, die mehr Handarbeit verlangen. Was ein Decompile normalerweise zurückgibt, steht in BSP dekompilieren erklärt.
- Orientierung. Ohne sprechende Namen und Pfade dauert es länger, eine fremde Map zu verstehen.
- Wiederverwendung von Inhalten. Umbenannte Materialien lassen sich schwerer zuordnen und in andere Projekte übernehmen.
- Einblick in deinen Arbeitsprozess. Entfernte Quelldateien und Logs verraten nichts mehr über Ordner, Werkzeuge und Zwischenstände.
Die Map muss weiter laufen
Die wichtigste Bedingung für jede Obfuscation: Die Map muss sich danach genauso laden und spielen wie zuvor. Das begrenzt, was verändert werden darf.
| Bereich | Warum er erhalten bleiben muss |
|---|---|
Namen von Entities (targetname) | Map-Logik und Server-Scripts sprechen Entities darüber an |
| Verbindungen zwischen Entities | Türen, Knöpfe und Trigger hängen an Inputs und Outputs |
| Klassen der Entities | Die Engine erzeugt Objekte anhand des Klassennamens |
| Verweise auf Materialien, Models, Sounds | Jeder Verweis muss auf eine vorhandene Datei zeigen |
| Header, Lump-Tabelle, Offsets | Ohne stimmige Struktur lädt die Map nicht |
Wird ein Materialpfad umbenannt, ohne dass alle Verweise mitgehen, siehst du im Spiel das Schachbrettmuster für fehlende Texturen. Ein seriöses Verfahren prüft die Ausgabe deshalb nach der Verarbeitung erneut und gibt keine Datei frei, die diese Prüfung nicht besteht.
Eine strukturelle Prüfung ersetzt aber keinen Test im Spiel. Bevor eine obfuskierte Map live geht, solltest du sie einmal auf deinem Server durchgehen:
- Map auf einem Testserver laden und die Konsole auf Fehler prüfen.
- Durch die Map laufen und auf Texturen, Models und Reflexionen achten.
- Türen, Knöpfe, Trigger und Teleporter auslösen.
- Addons prüfen, die sich Map-Entities merken, zum Beispiel Zuordnungen von Türen oder dauerhaft platzierte Objekte.
- Mit einem zweiten Client beitreten, der die Map über deinen normalen Download-Weg erhält.
Punkt 4 gilt übrigens für jede neue Fassung einer Map, auch nach einem gewöhnlichen Update.
Grenzen der Obfuscation
Die Engine muss alles lesen können, was sie zum Laden braucht. Daraus folgen feste Grenzen:
- Eine obfuskierte Map bleibt grundsätzlich auswertbar.
- Decompiler entwickeln sich weiter. Was heute eine hohe Hürde ist, kann morgen niedriger sein.
- Mit genug Zeit lässt sich jede Map von Hand nachbauen.
- Obfuscation verhindert nicht, dass die Datei unverändert kopiert und auf einem anderen Server eingesetzt wird.
| Obfuscation hilft gegen | Obfuscation hilft nicht gegen |
|---|---|
| bequemes Dekompilieren und Weiterbearbeiten | das Kopieren der fertigen Datei |
| schnelles Verstehen einer fremden Map | den Einsatz auf fremden Servern |
| Übernahme von Inhalten in andere Projekte | einen Nachbau von Hand |
Für die rechte Spalte gibt es andere Werkzeuge. Ein Fingerprint macht Kopien zuordenbar, und eine Server-Exclusive Map läuft nur auf einem lizenzierten Server vollständig. Wie die Teile zusammenpassen, steht in GMod Map vor Leaks schützen.
Obfuscation bei bspmarket.de
In der BSP Protection von bspmarket.de ist Obfuscation eine eigene Schutzstufe. Die Seite beschreibt das Ziel ausdrücklich nicht als Unlesbarkeit, sondern als Erschweren typischer Rekonstruktionswege. Öffentlich dokumentiert sind folgende Punkte:
- Die Obfuscation arbeitet in mehreren kontrollierten Schichten.
- Umbenannt werden nur Materialpfade. Entity- und Targetnamen bleiben erhalten, damit Server-Scripts weiter funktionieren.
- Die Ausgabedatei wird erneut validiert. Schlägt das fehl, gibt es kein Ergebnis statt einer kaputten Map.
- Die Originaldatei wird nicht verändert, der Schutz erzeugt eine separate Ausgabe.
- Abgerechnet wird nur bei einem erfolgreich abgeschlossenen Job.
- Ein Test auf dem Zielserver wird vor dem Release weiterhin empfohlen.
Welche Details bewusst nicht veröffentlicht werden und warum, erklärt die Seite Schutz erklärt.
Häufige Fragen
Verändert Obfuscation, wie die Map aussieht oder sich spielt?
Das soll sie nicht. Funktionsrelevante Namen und Verweise bleiben erhalten, und die Ausgabe wird strukturell geprüft. Ein kurzer Test auf dem eigenen Server bleibt trotzdem sinnvoll.
Macht Obfuscation das Dekompilieren unmöglich?
Nein. Sie erschwert typische Decompile-Versuche und reduziert verwertbare Editor-Informationen. Ausschließen lässt sich ein Decompile bei Source-Maps nicht.
Kann ich eine obfuskierte Map später noch bearbeiten?
Du bearbeitest nicht die obfuskierte BSP, sondern deine VMF, kompilierst neu und schützt die neue Fassung erneut. Bewahre deshalb VMF und Original-BSP immer sicher auf.
Brauche ich Obfuscation, wenn ich schon einen Fingerprint nutze?
Beide lösen unterschiedliche Probleme. Der Fingerprint macht eine Kopie zuordenbar, Obfuscation erschwert das Weiterbearbeiten. Zusammen decken sie mehr ab als jede Maßnahme allein.