Von fertigen Maps bis zu modularen Buildings – kuratiert für Garry's Mod und Source-Workflows.
Eine ausführliche, sichere Erklärung mit Prozessgrafiken, Vertrauensnachweisen und einem verständlichen Blick auf Fingerprinting, Obfuscation und Ergebnisvalidierung.
Schütze deine Map mit Fingerprint, Prüfbericht und mehrstufiger Anti-Decompile-Protection.
Aktuell aktiv: Audit, Fingerprint, Metadata Cleanup, Obfuscaten und Server-Exclusive. Kein vollstaendiger Kopierschutz garantiert.
Jeder Schutzlauf folgt denselben überprüfbaren Qualitätsgrenzen. Der Bericht trennt angewendete, übersprungene und fehlgeschlagene Schritte.
Nur tatsächlich angewendete Stufen werden als aktiv ausgewiesen.
Die erzeugte BSP wird vor der Freigabe erneut strukturell geprüft.
Hashes und Job-Ereignisse schaffen eine serverseitige Nachweiskette.
Coins werden nur für erfolgreich abgeschlossene Jobs verbraucht.
Bezahle flexibel mit BSP Credits oder kaufe einen einmaligen Pass für genau eine Map.
Prüfbericht zu Struktur & Risiken. Das Ergebnis ist der Bericht – deine BSP bleibt unverändert.
Entfernt Editor- & Build-Metadaten, die deine Arbeitsumgebung verraten können.
Herkunft und Eigentum serverseitig nachweisbar machen – inkl. Metadata Cleanup.
Mehrstufiger Schutz für öffentliche Creator-Releases.
Stärkste Stufe plus signiertes Server-Lizenzpaket.
Jede angewendete Stufe wird im Prüfbericht dokumentiert. Wir zeigen nur als aktiv an, was technisch tatsächlich durchgeführt wurde.
BSP Protection ist ein mehrstufiger Workflow: Modus wählen, Datei hochladen, Checks & Protection-Stufen laufen lassen, Bericht lesen, Ergebnis herunterladen. Jede im Bericht als angewendet gemeldete Stufe wurde technisch wirklich durchgeführt.
Wähle Audit, Fingerprint, Metadata Cleanup, Obfuscaten oder Server-Exclusive und lade eine `.bsp`-Datei bis 3,7 GB hoch. Das Upload-Fenster zeigt Fortschritt, Dateiname und Status an.
Das Tool liest Header, Lump-Tabelle, Offsets, Dateigröße und Fingerprints. Auffällige Werte werden im Bericht nachvollziehbar markiert.
Je nach Modus werden signierte Evidence-Anker, eine verdeckte Multi-Carrier-Fingerprint-Schicht (über mehrere unabhängige Träger-Familien verteilt), Metadata-Cleanup und/oder Obfuscaten angewendet. Die Fingerprint-Schicht ist in Fingerprint, Cleanup, Obfuscaten und Server-Exclusive automatisch enthalten und über einen serverseitigen Ledger nachweisbar – auch wenn einzelne Marker-Familien später entfernt werden. Obfuscaten kann Materialnamen auf interne Alias-Pfade umschreiben, passende VMT-Aliase ins Pakfile legen, harmlose Decoy-Entities plus Decompiler-Bait einfügen und Geometry-/Brush-Reconstruction-Sabotage anwenden, soweit die Map-Struktur es sicher zulässt. Die Ausgabedatei wird danach erneut validiert; schlägt das fehl, gibt es kein Ergebnis statt einer kaputten Map.
Nur erfolgreich abgeschlossene Prüfungen bzw. Protections nutzen einen BSP Credit. Du erhältst einen JSON-Prüfbericht mit Status, Hash, angewendeten Stufen und gefundenen Hinweisen.
Server-Exclusive erzeugt zusaetzlich ein ZIP mit BSP, license.json, signiertem Lizenz-Lua, Maploader-Lua, Entity-JSON und Installationstext. Konfigurierte oder sicher ausgelagerte Point-/Logic-Entities werden erst nach gueltigem Lizenzcheck bzw. Grace-Cache aktiviert.
Diese Seite erklärt den Schutzprozess technisch verständlich: vom unveränderten Upload über Fingerprint und Obfuscation bis zur finalen Validierung und zum Herkunftsnachweis.
Du sollst beurteilen können, was verarbeitet, geprüft und nachgewiesen wird. Sicherheitskritische Implementierungsdetails bleiben bewusst nicht öffentlich.
Prozessphasen, Vertrauensziele, Berichtsfelder, Validierungsgrenzen und die Rolle mehrerer unabhängiger Nachweissignale.
Konkrete Trägerpositionen, Schlüsselmaterial, Ableitungslogik, Schwellenwerte und Details, die Umgehungsversuche erleichtern würden.
Jede Phase hat einen klaren Zweck und eine überprüfbare Ausgabe. Ein Fehler stoppt die Freigabe, statt eine zweifelhafte Datei als erfolgreich auszugeben.
Die Eingabe wird als Ausgangspunkt erfasst; der Schutz erzeugt eine separate Ausgabe.
Header, Bereiche und grundlegende Integrität werden vor Veränderungen bewertet.
Nur die gewählte Stufe wird angewendet und jeder echte Schritt protokolliert.
Die resultierende BSP muss die strukturellen Freigabegates erneut bestehen.
Status, Hashes und tatsächlich angewendete Stufen werden nachvollziehbar ausgegeben.
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.
4,8 + 7,6 + 18,9 + 6,3 + 1,4 = 39,0 Sekunden. Der größte Anteil entfällt in diesem Beispiel auf die gewählten Schutzschichten.
Der Index macht die Richtung vergleichbar; er ist keine Erfolgswahrscheinlichkeit und verrät keine internen Schwellenwerte.
| 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 |
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.
materials/hallway/wood_floor_02.vmtmaterials/custom/7f2ac91e.vmtNur Materialpfade werden umbenannt. Entity-/Targetnamen bleiben erhalten, damit Server-Skripte weiterhin funktionieren.
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.
Nicht benötigte Editor-Hinweise werden nur dort reduziert, wo es sicher möglich ist.
Die Ausgabe wird weniger direkt auf eine komfortable Editor-Rekonstruktion abbildbar.
Keine Schutzwirkung zählt als Erfolg, wenn die resultierende BSP die Prüfung nicht besteht.
Ein Job gilt erst nach Verarbeitung und erneuter Prüfung als erfolgreich. Das schützt vor falschen Erfolgsmeldungen und macht den Bericht überprüfbar.
Dateikopf, Bereiche, Grenzen und grundlegende Konsistenz müssen plausibel bleiben.
Der Report übernimmt nur Schritte, die wirklich durchgeführt und bestätigt wurden.
Sicherheits- und Größenlimits verhindern unkontrollierte oder unplausible Ergebnisse.
Input, Output, Schutz-ID und Ereignisse bleiben serverseitig miteinander verknüpft.
Die Beispiele zeigen, wie Größe, Eingabequalität und Validierung den Ablauf verändern. Die Entscheidungen bleiben gleich, auch wenn die Zahlen variieren.
Saubere Eingabe, mittlere Dateigröße und drei gewählte Schutzschichten.
Viele eingebettete Inhalte verlängern Audit und Validierung; drei Hinweise werden transparent dokumentiert.
Die Vorprüfung erkennt eine inkonsistente Bereichsgrenze und beendet den Job vor jeder Schutzverarbeitung.
Die technische Ausgabe soll nicht nur „grün“ anzeigen. Sie liefert konkrete Anhaltspunkte dafür, was geprüft und angewendet wurde.
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.
Source-BSPs müssen von der Engine gelesen werden können. Deshalb wäre ein Versprechen absoluter Unlesbarkeit technisch unseriös.
Nein. Der technische Nachweis benötigt keine Klartext-Kontaktdaten in der BSP. Die Zuordnung erfolgt über serverseitige Datensätze.
Funktionsrelevante Referenzen werden soweit erforderlich erhalten und die Ausgabe wird strukturell validiert. Ein echter Smoke-Test auf dem Zielserver bleibt vor dem Release empfohlen.
Weil diese Details keinen zusätzlichen Vertrauensbeleg liefern, aber gezielte Entfernung und Umgehung erleichtern würden. Der Report zeigt stattdessen Status und Nachweisqualität.
Eine nicht freigegebene Ausgabe wird nicht als erfolgreich bereitgestellt. Für fehlgeschlagene Jobs werden keine Credits als erfolgreicher Schutz verbraucht.
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.
Starte mit einem Audit oder wähle die Schutzstufe, die zu deinem Release-Risiko passt.
Einzelne Map oder regelmäßige Releases: Wähle genau das Modell, das zu deinem Workflow passt. Ohne versteckte Kosten.
Starte mit einem einzelnen Pass oder spare mit flexiblen Coin-Paketen und monatlichen Creator-Plänen.
BSP Credits werden für erfolgreiche BSP-Audits, Fingerprints und Protection-Jobs verwendet.
Ein Coin wird nur verbraucht, wenn ein Job erfolgreich verarbeitet wurde. Ungültige oder beschädigte Dateien führen nicht zu einem Coin-Abzug.
Einmalig gekaufte Coins bleiben im Account erhalten, solange dein Account besteht. Monatliche Abo-Coins werden pro Abrechnungszeitraum gutgeschrieben; gesetzliche Rechte und Erstattungsfälle bleiben unberührt.
Bei Creator Pro, Studio und Agency erhältst du monatlich BSP Credits für Protection-Services. Starter enthält nur einmalige Start-Coins.
Ja, zusätzliche Coin-Pakete können jederzeit gekauft werden.
Bei Rückerstattungen oder Zahlungsproblemen kann eine Korrektur im Coin-Ledger erfolgen. Dein Guthaben wird nachvollziehbar dokumentiert.
Überprüfe deine BSP-Maps auf Strukturfehler, riskante Entities und Pakfile-Auffälligkeiten – bevor sie auf dem Server oder im Store landen.
Analysiere echte BSP-Dateien oder Compile-Logs mit Ursachen-, Folgefehler- und Lösungserkennung.
Der Scanner liest Struktur, Entities und Pakfile und fasst Auffälligkeiten so zusammen, dass du direkt weißt, wo du in Hammer oder deinem Server-Setup nachsehen solltest.
Wähle eine BSP-Datei oder prüfe Entity-Text. Dein Ergebnis erscheint direkt daneben.
oder eine Datei von deinem Gerät auswählen
Secure Storage wird kontrolliert ausgerollt. Der Speichermodus wird ausschließlich serverseitig festgelegt.
.bsp, .txt oder .log · maximal 50 MBNur für die Analyse verarbeitet. Keine Veröffentlichung.
Wähle links eine Datei oder füge Entity-Text ein. Hier erscheint anschließend dein Report.
Weil kaputte Maps Vertrauen kosten. Ein sauberer Report macht Releases nachvollziehbar, reduziert Support-Fragen und hilft, Probleme zu finden, bevor Käufer oder Spieler sie entdecken.
Für GMod-Creator, DarkRP-Server, Mapping-Teams und Betreiber, die BSP-Dateien nicht nur hochladen, sondern professionell veröffentlichen wollen.
Prüfe deine Auswahl und schließe den Kauf sicher über Stripe ab.
Geprüfte Fehlermeldungen, Ursachen und konkrete Lösungsschritte für Hammer und Source-Compile-Tools.