Häufig gestellte Fragen

Es gibt zahlreiche Gründe, Ihren Code zu schützen: Sie verhindern, dass jemand Ihre Arbeit einfach kopiert (besonders wichtig bei clientseitigen Projekten wie HTML5-Spielen), Sie machen den Code schwerer verständlich und schwerer veränderbar, und Sie schützen Arbeiten, die noch nicht bezahlt wurden, sodass Sie Kunden einen funktionierenden Build zeigen können, ohne den Quellcode herauszugeben.

Die Standard-Obfuskierung schreibt Ihr JavaScript in schwerer lesbares JavaScript um: Namen werden ersetzt, Strings verschoben und codiert, der Kontrollfluss wird umstrukturiert, doch das Ergebnis ist weiterhin JavaScript, das sich mit einem Debugger schrittweise durchlaufen lässt. Die VM-Obfuskierung (Virtual Machine) kompiliert die Rümpfe Ihrer Funktionen in eigenen Bytecode und liefert einen eingebetteten Interpreter mit, der ihn ausführt, sodass die geschützte Logik nicht mehr als JavaScript existiert. Welche Funktionen abgedeckt sind und wie Sie sie auswählen, erfahren Sie unter VM-Obfuskierung.

Ja. Setzen Sie vmTargetFunctionsMode auf comment und markieren Sie jede zu schützende Funktion mit /* javascript-obfuscator:vm */. Erhalten Sie diese Kommentare in allen Build-Schritten, die vor der Obfuskierung laufen. Siehe Funktionen gezielt auswählen.

Nein. API-Schlüssel, Geheimnisse und Zugangsdaten dürfen NIEMALS im Frontend-Code gespeichert werden. Selbst bei höchster Obfuskierungsstufe lassen sich alle Daten in Frontend-JavaScript von einem entschlossenen Angreifer extrahieren. Obfuskierung erschwert Reverse Engineering, ist aber keine Verschlüsselung und sollte nicht zur Absicherung von Geheimnissen herangezogen werden. Speichern Sie Geheimnisse stattdessen auf Ihrem Backend-Server, verwenden Sie serverseitige Umgebungsvariablen, leiten Sie API-Aufrufe über Ihr Backend, um Schlüssel zu verbergen, oder verwenden Sie kurzlebige Tokens, die Ihr Server ausstellt.

Obfuskierung erhöht den Aufwand, Code zu verstehen und zu verändern, ganz gleich, ob die Analyse von einem Menschen, einem Werkzeug oder einem KI-Assistenten durchgeführt wird; sie kann nicht garantieren, dass Reverse Engineering unmöglich ist. Die Laufzeit bleibt in einer vom Angreifer kontrollierten Umgebung beobachtbar. Bewahren Sie Geheimnisse und verbindliche Sicherheitsentscheidungen auf dem Server auf. Wie die VM Code transformiert.

Schließen Sie zuerst die Laufzeit-Schutzmechanismen aus. VM Self Defending und VM Debug Protection brechen absichtlich unter Automatisierungstools, Headless-Browsern und Debuggern ab sowie dann, wenn target nicht zur tatsächlichen Laufzeitumgebung passt. Führen Sie Funktionstests daher mit einem separaten Test-Build aus, in dem sie deaktiviert sind. Schlägt auch dieser Build fehl, grenzen Sie das Problem mit vmTargetFunctionsMode: 'comment' ein und virtualisieren Sie jeweils eine Funktion. Der Leitfaden zur Fehlerbehebung führt durch jeden Schritt und nennt, was in einen Fehlerbericht gehört.

Der Obfuscator fügt Code hinzu: Bezeichner erhalten generierte Namen, Strings wandern in ein String-Array mit Zugriffsfunktionen (optional codiert), und bei der VM-Obfuskierung wird ein vollständiger Interpreter für die virtuelle Maschine zusammen mit Ihrem Bytecode ausgeliefert. Machen Sie sich wegen der Größe nicht zu viele Gedanken - obfuskierter Code lässt sich mit gzip oder Brotli gut komprimieren, was die meisten Server standardmäßig aktiviert haben.

Stärkere Voreinstellungen können Ausgabegröße und Laufzeit erhöhen. Messen Sie Startzeit, häufig ausgeführte Pfade und komprimierte Bundle-Größe Ihres Codes, statt feste Verlangsamungsfaktoren anzunehmen. Optionsreferenz · Best Practices

Nein. Eine Umschreibung der Ausgabe kann sie beschädigen, insbesondere mit Self Defending oder VM Self Defending, die Änderungen am Code erkennen. Einen Minifier können Sie vor der Obfuskierung verwenden, sofern er javascript-obfuscator-Kommentare wie /* javascript-obfuscator:vm */ erhält.

Wir speichern Ihren Quellcode nicht. Die Basis-Obfuskierung von JavaScript läuft in Ihrem Browser. Bei VM- und HTML-Obfuskierung wird der Quellcode an unsere Server gesendet, die ihn verarbeiten und verwerfen; ist eine Anfrage größer als 4.4 MB, laden die Team- und Business-Tarife ihn in einen temporären Speicher hoch, der nach der Verarbeitung gelöscht wird. Zur Missbrauchsbekämpfung und Nutzungsanalyse speichern wir drei Monate lang einen SHA-256-Hash jeder obfuskierten Ausgabe und einige der verwendeten Einstellungen (etwa Voreinstellung, Ziel und VM-Abwehrmaßnahmen), niemals den Code selbst oder Inhalte daraus. Der Dashboard-Verlauf wird ausschließlich in Ihrem Browser gespeichert; verwalten Sie ihn unter Verlauf.

Nein. Der Obfuscator bewahrt Ihre ursprünglichen Namen, Kommentare und Formatierung nicht auf, daher lässt sich die Ausgabe nicht wieder in Ihren Quellcode zurückverwandeln. Das ist keine Sicherheitsgarantie (siehe die Frage zur Deobfuskierung weiter oben), bedeutet aber, dass Sie das Original sicher aufbewahren müssen.

Ja. Sie können in den Obfuskierungsoptionen "Node" als Ziel auswählen, um die Ausgabe für Node.js-Umgebungen zu optimieren.

Unterstützt werden unter anderem ES2015+-Syntax, async/await, optionale Verkettung und private Klassenfelder; testen Sie neuere Syntax mit der Obfuscator-Version, die Sie auswählen. Kompilieren Sie TypeScript und JSX und bündeln Sie Ihre Anwendung vor der Obfuskierung - siehe Laufzeitkompatibilität. HTML-Dateien werden über parseHtml unterstützt; siehe HTML-Obfuskierung.

Die obfuskierte Ausgabe - einschließlich des VM-Interpreters und der Schutzschicht von Self Defending - wird aktiv unterstützt und auf Evergreen-Desktop-Browsern sowie iOS 16+ getestet (grob die letzten 4 Jahre). Ältere Browser werden nach bestem Bemühen bis zu einer harten Untergrenze bei der Unterstützung von ES2015-Modulen bedient; alles darunter, einschließlich Internet Explorer, liegt außerhalb des unterstützten Umfangs.

Sehen Sie sich unsere Preistarife für den VM-Schutz an oder nutzen Sie den kostenlosen Online-Testbereich für die Standard-Obfuskierung. Eine vollständige Anleitung finden Sie im Leitfaden für erste Schritte.

Die Nutzung wird anhand der Größe Ihres Eingabequellcodes in Bytes gemessen. Für jeden Obfuskierungsauftrag werden mindestens 0,1 MB (102.400 Bytes) berechnet, um eine faire Ressourcenverteilung sicherzustellen. Wenn Sie beispielsweise eine 50 KB große Datei obfuskieren, wird sie mit 0,1 MB auf Ihr Kontingent angerechnet. Dateien über 0,1 MB werden mit ihrer tatsächlichen Größe berechnet.

Sobald Sie Ihr Limit für die VM-Obfuskierung erreicht haben, können Sie die Standard-Obfuskierung (im Browser) weiterhin kostenlos und unbegrenzt nutzen. Bei kostenpflichtigen Tarifen wird Ihr VM-Kontingent jeden Monat an dem Kalendertag zurückgesetzt, an dem Ihr Abonnement begonnen hat, auch bei Jahrestarifen. Der Free-Tarif hat ein Limit auf Lebenszeit, das nicht zurückgesetzt wird. Bei Tarifen mit einem täglichen VM-Limit können Sie nach Erreichen dieses Limits am nächsten Tag wieder mit VM obfuskieren. Sie können Ihren Tarif jederzeit upgraden, um ein größeres Kontingent für die VM-Obfuskierung zu erhalten.

Ja, Sie können Ihren Tarif jederzeit upgraden oder downgraden. Bei einem Upgrade wird Ihnen der anteilige Betrag für den Rest Ihres Abrechnungszeitraums berechnet. Bei einem Downgrade gilt der neue Preis ab dem nächsten Abrechnungszeitraum.

Sie können Ihr Abonnement jederzeit kündigen. Bis zum Ende des laufenden Abrechnungszeitraums behalten Sie den Zugriff auf Ihren Tarif. Bitte beachten Sie, dass wir keine Rückerstattungen für angebrochene Abrechnungszeiträume oder ungenutzte Zeit anbieten.

Wir akzeptieren alle gängigen Kreditkarten (Visa, Mastercard, American Express) sowie Debitkarten über unseren sicheren Zahlungsdienstleister Stripe. Alle Transaktionen sind verschlüsselt und PCI-konform.