BSP dekompilieren: was ein Decompile wirklich liefert
BSP dekompilieren heißt, aus einer kompilierten Source-Map wieder eine VMF zu erzeugen. Was dabei zurückkommt, was fehlt und was Schutz bewirkt.
Beim Dekompilieren erzeugt ein Tool wie BSPSource aus einer kompilierten BSP-Datei wieder eine VMF-Datei, die sich im Hammer Editor öffnen lässt. Das Ergebnis ist eine Rekonstruktion und nicht die Originaldatei: Geometrie und Entities kommen weitgehend zurück, die Arbeitsstruktur des Mappers nicht. Weil die Engine jede BSP lesen können muss, ist eine kompilierte Map grundsätzlich nie geheim.
Warum sich BSP-Dateien dekompilieren lassen
Eine BSP ist kein verschlossener Behälter. Das Format ist seit Jahren bekannt, und die Engine braucht zum Laden genau die Daten, die auch ein Decompiler auswertet: Brushes für die Kollision, Flächen mit Materialien, Entities als Text. Ein Decompiler liest diese Bereiche aus und schreibt sie in das Textformat zurück, das Hammer versteht. Wie die Datei aufgebaut ist, zeigt Was ist eine BSP-Datei?.
Dekompilieren hat legitime Gründe. Mapper retten damit eigene Projekte, deren VMF verloren ging, untersuchen Fehler in einer kompilierten Fassung oder lernen an freigegebenen Maps, wie etwas gebaut wurde.
Was ein Decompile zurückliefert
Ein guter Decompile stellt erstaunlich viel wieder her:
- die Brushes der Welt, aus den gespeicherten Brush-Daten rekonstruiert
- Punkt-Entities mit allen Eigenschaften sowie Inputs und Outputs
- Brush-Entities wie Türen, Trigger und
func_detail - Displacements, also verformte Geländeflächen
prop_staticund Overlays- Positionen von Cubemaps sowie Areaportale, Letztere nicht immer an der richtigen Stelle
- die Zuordnung von Materialien zu Flächen
- den Inhalt des Pakfiles, der sich als normales Archiv entpacken lässt
Für jemanden mit Erfahrung in Hammer reicht das als Ausgangspunkt, um eine Map zu verändern und neu zu kompilieren.
Was fehlt oder nur ungefähr stimmt
Alles, was nur dem Editor diente, steht nicht in der BSP und kommt deshalb nicht zurück.
| Bereich | Zustand nach dem Decompile |
|---|---|
| VisGroups, Gruppen, Kommentare | fehlen, sie werden nie in die BSP geschrieben |
| Instanzen | sind aufgelöst, alle Inhalte liegen direkt in der Map |
Entities, die der Compiler vollständig verbraucht, etwa func_viscluster | lassen sich laut BSPSource-Readme nicht exakt wiederherstellen |
| Form der Brushes | die Brushes selbst stehen in der BSP, bei komplexen Brushes kommen die Eckpunkte aber ungenau zurück, bis hin zu ungültigen Solids |
| Tool-Texturen wie Clip | teils durch Nodraw ersetzt oder untereinander vertauscht |
| Beleuchtung | Licht-Entities sind da, die Lightmaps müssen neu berechnet werden |
| Quelldateien von Models und Texturen | fehlen, im Pakfile liegen nur kompilierte Fassungen |
In der Praxis bedeutet das Nacharbeit. Rekonstruierte Brushes können beim erneuten Kompilieren Leaks oder ungültige Solids erzeugen, und ohne Gruppen und VisGroups ist eine große Map unübersichtlich. Ein Decompile ist deshalb selten eine fertige Arbeitsdatei, aber meist ein brauchbarer Anfang.
Warum eine kompilierte Map nie geheim ist
Drei Tatsachen lassen sich nicht ändern:
- Jeder Spieler, der einem Server beitritt, erhält die Map-Datei.
- Die Engine muss die Datei vollständig lesen können.
- Was die Engine lesen kann, kann grundsätzlich auch ein anderes Programm lesen.
Wer eine Map schützen will, sollte deshalb nicht auf Geheimhaltung bauen. Realistische Ziele sind ein höherer Aufwand für die Rekonstruktion und ein Nachweis, woher eine Kopie stammt.
Was Anti-Decompile-Maßnahmen realistisch bewirken
Anti-Decompile-Maßnahmen setzen an zwei Stellen an. Zum einen entfernen sie Informationen, die die Engine nicht braucht, die einem Bearbeiter aber helfen, etwa Editor-Kennungen oder Reste von Quelldateien im Pakfile. Zum anderen verändern sie die Darstellung der Datei so, dass eine automatische Rekonstruktion weniger zuverlässig gelingt und mehr Handarbeit verlangt.
| Erwartung | Realität |
|---|---|
| Niemand kann meine Map mehr öffnen | Die Engine muss sie lesen, also bleibt sie grundsätzlich auswertbar |
| Ein Decompile ist danach ausgeschlossen | Er wird aufwendiger und liefert schlechtere Ergebnisse |
| Der Schutz hält für immer | Decompiler entwickeln sich weiter, Schutzverfahren auch |
| Anti-Decompile ersetzt einen Kopierschutz | Die Datei lässt sich weiterhin unverändert kopieren |
Der letzte Punkt wird oft übersehen: Eine obfuskierte Map läuft auf jedem Server, auf den jemand sie kopiert. Anti-Decompile schützt deine Arbeit vor dem bequemen Weiterbearbeiten, nicht vor der Weitergabe. Dafür braucht es andere Mittel, beschrieben in GMod Map vor Leaks schützen.
Wichtig ist außerdem die Gegenprobe. Jede Veränderung an einer BSP darf die Map nicht beschädigen. Seriöse Verfahren prüfen die Ausgabe erneut und geben keine Datei heraus, die diese Prüfung nicht besteht.
bspmarket.de formuliert das für die eigene BSP Protection bewusst zurückhaltend: Der Anti-Decompile Layer erschwert typische Decompile-Ausgaben, ein vollständiger Schutz vor Decompiling kann bei Source-BSP-Dateien nicht garantiert werden. Was die Stufen im Einzelnen tun, steht unter BSP Protection und in BSP Obfuscation erklärt. Weil sich ein Decompile nie ganz ausschließen lässt, ist ein Fingerprint die sinnvolle Ergänzung: Er macht eine Kopie zuordenbar, auch wenn sie sich nicht verhindern lässt.
Technisch möglich heißt nicht erlaubt
Dass sich eine Map dekompilieren lässt, sagt nichts darüber, ob du das Ergebnis verwenden darfst. Eine Map, in der eigene gestalterische Entscheidungen ihres Erstellers stecken, ist als dessen Werk geschützt, und daran ändert das Dekompilieren nichts. Wer fremde Maps verändert, neu veröffentlicht oder verkauft, braucht in aller Regel dessen Zustimmung. Eine Einordnung ohne Rechtsberatung findest du in Urheberrecht bei GMod-Maps.
Häufige Fragen
Kann man jede BSP-Datei dekompilieren?
Grundsätzlich lässt sich jede Source-BSP auswerten, weil die Engine sie lesen muss. Wie brauchbar das Ergebnis ist, hängt von der Map, vom Decompiler und von eingesetzten Schutzmaßnahmen ab.
Bekomme ich durch Dekompilieren meine verlorene VMF zurück?
Nur als Rekonstruktion. Geometrie und Entities kommen weitgehend zurück, Gruppen, VisGroups und Instanzen nicht. Regelmäßige Backups der VMF sind der bessere Weg.
Verhindert Obfuscation das Dekompilieren?
Nein. Sie erschwert typische Decompile-Versuche und reduziert verwertbare Editor-Informationen. Ausschließen lässt sich ein Decompile nicht.
Übersteht ein Fingerprint einen Decompile?
Das hängt vom Verfahren und vom Ausmaß der Änderungen ab. Verfahren, die sich auf mehrere unabhängige Signale stützen, sind robuster gegen einzelne Veränderungen. Eine Garantie gibt es dafür nicht.