Technische Transparenz ohne Angriffsanleitung
Du sollst beurteilen können, was verarbeitet, geprüft und nachgewiesen wird. Sicherheitskritische Implementierungsdetails bleiben bewusst nicht öffentlich.
Was wir zeigen
Prozessphasen, Vertrauensziele, Berichtsfelder, Validierungsgrenzen und die Rolle mehrerer unabhängiger Nachweissignale.
Was geschützt bleibt
Konkrete Trägerpositionen, Schlüsselmaterial, Ableitungslogik, Schwellenwerte und Details, die Umgehungsversuche erleichtern würden.
Fünf kontrollierte Phasen statt einer Blackbox
Jede Phase hat einen klaren Zweck und eine überprüfbare Ausgabe. Ein Fehler stoppt die Freigabe, statt eine zweifelhafte Datei als erfolgreich auszugeben.
- 01Upload isolieren
- 02Struktur prüfen
- 03Gewählte Layer
- 04Output validieren
- 05Report & Nachweis
Ein vollständiger Beispiellauf mit nachvollziehbaren Zahlen
Das fiktive Projekt gm_harbor_release_v12.bsp zeigt, wie Eingabe, Verarbeitung, Ausgabe und Bericht zusammenhängen. Alle Werte sind intern konsistent und bewusst konkret.
Die Zahlen bilden einen realistischen Musterlauf ab, sind aber keine Produktionsstatistik, kein Benchmark und keine garantierte Schutzquote. Laufzeit und Ergebnis hängen von Map, Schutzstufe und Systemlast ab.
| Prüfpunkt | Input | Output | Was das bedeutet |
|---|---|---|---|
| Dateigröße | 186,4 MB | 189,1 MB | 2,7 MB zusätzliche Schutz- und Nachweisdaten im Musterlauf |
| SHA-256-Kurzform | 8f3a…91c2 | c71d…0ae4 | Getrennte Hashes belegen, dass Input und Output nicht verwechselt werden |
| Funktionsobjekte | 1.284 | 1.284 | Der kontrollierte Beispielbestand bleibt erhalten |
| Materialreferenzen | 612 | 612 | Benötigte Referenzen werden im Beispiel nicht entfernt |
| Nachweissignale | 0 / 3 | 3 / 3 | Drei konzeptionelle Signalgruppen sind dem serverseitigen Job zugeordnet |
| Strukturgates | 14 / 14 | 14 / 14 | Die Ausgabe besteht dieselben relevanten Plausibilitätsprüfungen erneut |
Herkunft wird über mehrere unabhängige Signale belegbar
Ein Fingerprint ist kein sichtbares Wasserzeichen und enthält keine Klartext-Kontaktdaten. Er verbindet eine konkrete Ausgabe mit einem serverseitigen Herkunftsdatensatz.
Der Nachweis stützt sich konzeptionell auf mehrere natürliche Signalgruppen. Wird eine Gruppe beschädigt oder ist für eine Map nicht anwendbar, können die übrigen Gruppen weiterhin zur Bewertung beitragen.
- Mehrere Signalgruppen reduzieren die Abhängigkeit von einem einzelnen Marker.
- Ein serverseitiger Ledger ordnet den Nachweis dem Schutzjob zu.
- Der Report unterscheidet vollständig, teilweise, beschädigt und nicht anwendbar.
Weniger direkt verwertbare Struktur, mehr Aufwand für Rekonstruktion
Obfuscation verändert die Ausgabedarstellung in mehreren kontrollierten Schichten. Das Ziel ist nicht, eine BSP „unlesbar“ zu machen, sondern typische Rekonstruktionswege unzuverlässiger und arbeitsintensiver zu machen.
Funktionsrelevante Namen und Referenzen werden soweit erforderlich erhalten. Nach jeder Verarbeitung entscheidet die Output-Validierung, ob die Datei freigegeben werden darf.
- 01Informationsminimierung
- 02Strukturelle Diversifizierung
- 03Integritätsgate
materials/hallway/wood_floor_02.vmtmaterials/custom/7f2ac91e.vmtNur Materialpfade werden umbenannt. Entity-/Targetnamen bleiben erhalten, damit Server-Skripte weiterhin funktionieren.
Die Ausgabe muss sich ihren Status verdienen
Ein Job gilt erst nach Verarbeitung und erneuter Prüfung als erfolgreich. Das schützt vor falschen Erfolgsmeldungen und macht den Bericht überprüfbar.
Struktur
Dateikopf, Bereiche, Grenzen und grundlegende Konsistenz müssen plausibel bleiben.
Angewendete Schritte
Der Report übernimmt nur Schritte, die wirklich durchgeführt und bestätigt wurden.
Ausgabegrenzen
Sicherheits- und Größenlimits verhindern unkontrollierte oder unplausible Ergebnisse.
Nachweiskette
Input, Output, Schutz-ID und Ereignisse bleiben serverseitig miteinander verknüpft.
Nicht jede Map nimmt denselben Weg
Die Beispiele zeigen, wie Größe, Eingabequalität und Validierung den Ablauf verändern. Die Entscheidungen bleiben gleich, auch wenn die Zahlen variieren.
Release-fertige RP-Map
Saubere Eingabe, mittlere Dateigröße und drei gewählte Schutzschichten.
- Input
- 186,4 MB
- Laufzeit
- 39,0 s
- Gates
- 14 / 14
Output bereit, Report vollständig, Smoke-Test empfohlen.
Große Environment-Map
Viele eingebettete Inhalte verlängern Audit und Validierung; drei Hinweise werden transparent dokumentiert.
- Input
- 2,80 GB
- Laufzeit
- 4 min 12 s
- Hinweise
- 3
Strukturell freigegeben; Hinweise vor dem Server-Test lesen.
Beschädigte Eingabedatei
Die Vorprüfung erkennt eine inkonsistente Bereichsgrenze und beendet den Job vor jeder Schutzverarbeitung.
- Input
- 94,7 MB
- Stopp nach
- 2,1 s
- Output
- keiner
Fehlerreport statt fragwürdiger Ausgabe; kein Verbrauch als erfolgreicher Job.
| Input prüfen | Nein | Ja |
|---|---|---|
| plausibel? | Stopp + Fehlerreport | Schutzschichten |
| Output valide? | Freigabe blockieren | Report + Download |
Was du nach einem Lauf selbst prüfen kannst
Die technische Ausgabe soll nicht nur „grün“ anzeigen. Sie liefert konkrete Anhaltspunkte dafür, was geprüft und angewendet wurde.
- Input-/Output-Hash
- Dateien eindeutig vergleichen
- Schutzflags
- Angewendet oder nicht angewendet
- Warnungen & Fehler
- Grenzen offen nachvollziehen
- Validierungsstatus
- Freigabe der Ausgabe prüfen
- Versionskette
- Änderungen getrennt dokumentieren
Ist diese Datei wirklich von bspmarket.de?
Kein Login nötig. Füge den sha256-Hash einer Datei ein oder den Inhalt eines heruntergeladenen Prüfberichts – der Server bestätigt nur, was er selbst ausgeliefert hat.
Wir behalten deine Map auch nach dem Verkauf im Blick
Schutz endet nicht mit dem Upload. bspmarket.de überwacht öffentliche Quellen, prüft gemeldete Leaks automatisch und gibt dir Werkzeuge für den Ernstfall. Alles läuft über den Bereich „Schutz“ deines Produkts.
Server-Überwachung
Alle sechs Stunden gleichen wir die öffentliche Steam-Serverliste mit den Map-Namen deiner Produkte ab. Läuft deine Map auf mehr Servern, als du Käufer hast, bekommst du einen Hinweis.
Workshop-Überwachung
Wir durchsuchen den Steam Workshop regelmäßig nach Re-Uploads deiner Maps. Jeder Fund landet mit Link in deiner Schutz-Übersicht und lässt sich mit einem Klick als Leak-Fall eröffnen.
Leak melden, Käufer-Kopie erkennen
Lade eine gefundene Datei hoch. Das System liest den Käufer-Fingerprint aus und ordnet sie der ursprünglichen Auslieferung zu, auch wenn die Datei nachträglich verändert wurde. Nach der Prüfung wird die Datei gelöscht; als Beweis bleibt der Hash.
Notfall-Rollback und Download-Pause
Fehlerhafte Version oder akuter Leak? Du stellst eine bereits geprüfte Vorversion sofort wieder her oder pausierst neue Downloads, ohne auf einen Review zu warten.
Fallbearbeitung durch das Team
Das bspmarket-Team prüft jeden bestätigten Treffer, sperrt die Downloads der betroffenen Kopie und dokumentiert den Fall. Du erhältst eine fertige Takedown-Vorlage für Workshop oder Filehoster.
Fair für beide Seiten
Du siehst eine pseudonyme Referenz und die Nachweisqualität. Käuferdaten sieht nur das Team. So wird niemand vorschnell beschuldigt, und Maßnahmen beruhen auf einem nachprüfbaren Befund.
Voraussetzung für die Käufer-Zuordnung ist der aktivierte Käufer-Fingerprint im Produkt. Die automatische Überwachung sieht nur öffentliche Server und Workshop-Einträge; Funde aus privaten Foren oder Discord-Servern meldest du über „Leak melden“.
Schutz erhöht Aufwand und Nachweisbarkeit – er garantiert keine Unmöglichkeit
Source-BSPs müssen von der Engine gelesen werden können. Deshalb wäre ein Versprechen absoluter Unlesbarkeit technisch unseriös.
Was der Schutz leistet
- Technischen Herkunftsnachweis aufbauen
- Typische Rekonstruktion erschweren
- Editor-Metadaten kontrolliert reduzieren
- Ergebnisse und Versionen dokumentieren
- Leaks laufend aufspüren und Käufer-Kopien zuordnen
Was niemand seriös garantieren kann
- Jede Form von Decompiling unmöglich machen
- Kompromittierte Server vollständig kontrollieren
- Manuelle Rekonstruktion grundsätzlich ausschließen
- Einen echten GMod-Smoke-Test ersetzen
- Private Server oder geschlossene Foren automatisch durchsuchen
Kurz und technisch sauber beantwortet
Kann der Fingerprint meine persönlichen Daten offenlegen?
Nein. Der technische Nachweis benötigt keine Klartext-Kontaktdaten in der BSP. Die Zuordnung erfolgt über serverseitige Datensätze.
Verändert Obfuscation die Spiellogik?
Funktionsrelevante Referenzen werden soweit erforderlich erhalten und die Ausgabe wird strukturell validiert. Ein echter Smoke-Test auf dem Zielserver bleibt vor dem Release empfohlen.
Warum werden keine genauen Fingerprint-Positionen gezeigt?
Weil diese Details keinen zusätzlichen Vertrauensbeleg liefern, aber gezielte Entfernung und Umgehung erleichtern würden. Der Report zeigt stattdessen Status und Nachweisqualität.
Was passiert bei einem fehlgeschlagenen Schutzlauf?
Eine nicht freigegebene Ausgabe wird nicht als erfolgreich bereitgestellt. Für fehlgeschlagene Jobs werden keine Credits als erfolgreicher Schutz verbraucht.
Kann ich eine fremde Datei ohne eigenen Account prüfen?
Ja. Über „Nachweis prüfen" auf dieser Seite kannst du ohne Login einen sha256-Hash oder einen erhaltenen Prüfbericht gegen unser Server-Ledger abgleichen. Ersteller-, Produkt- oder Kaufdaten werden dabei nie offengelegt.
Was passiert, wenn meine Map geleakt wird?
Du meldest den Leak im Creator-Bereich unter „Schutz“, am besten mit der gefundenen Datei. Das System prüft sie automatisch auf den Käufer-Fingerprint, das Team bewertet den Fall und kann die Downloads der betroffenen Kopie sperren. Parallel kannst du Downloads pausieren oder eine frühere Version wiederherstellen.
Prüfe deine Map und entscheide anhand echter Ergebnisse.
Starte mit einem Audit oder wähle die Schutzstufe, die zu deinem Release-Risiko passt.