JavaScriptVM-Obfuskierung

Es gibt zahlreiche Gründe, Ihren Code zu schützen: Sie verhindern, dass jemand Ihre Arbeit einfach per Copy-and-paste übernimmt (besonders wichtig bei clientseitigen Projekten wie HTML5-Spielen), Sie entfernen Kommentare und Leerräume, damit der Code schneller lädt und schwerer zu verstehen ist, und Sie schützen Arbeiten, die noch nicht bezahlt wurden, sodass Sie sie Kunden zeigen können, ohne den Quellcode herauszugeben.

Die VM-Obfuskierung (Virtual Machine) verwandelt Ihren JavaScript-Code in eigenen Bytecode, der auf einem eingebetteten Interpreter läuft. Anders als die Standard-Obfuskierung, die weiterhin lesbares JavaScript erzeugt, verbirgt die VM-Obfuskierung die Struktur Ihres ursprünglichen Codes vollständig. Werkzeuge zur statischen Analyse können die Logik nicht verstehen, ohne zuvor die gesamte virtuelle Maschine per Reverse Engineering zu erschließen. Mehr dazu in unserem Leitfaden zur VM-Obfuskierung.

Ja! Wir bieten eine Option, mit der Sie die VM-Obfuskierung gezielt auf bestimmte Funktionen oder Methoden anwenden. Versehen Sie die gewünschte Funktion einfach mit einem speziellen Kommentar (/* javascript-obfuscator:vm */), und nur diese Funktion wird durch den VM-Obfuscator verarbeitet. Das ist ideal, um ausschließlich Ihre sensibelsten Algorithmen zu schützen, während der Rest Ihres Codes standardmäßig obfuskiert oder unangetastet bleibt — so minimieren Sie den Performance-Overhead.

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.

Keine Obfuskierung ist zu 100 % narrensicher — JavaScript läuft letztlich in einer Umgebung, die der Angreifer kontrolliert (Browser oder Node.js), und die Untersuchung des Laufzeitspeichers ist dort immer möglich. Keine JavaScript-Obfuskierung kann das ausschließen; sie kann aber den Aufwand erhöhen, dorthin zu gelangen. Für VM-obfuskierten Code existieren derzeit keine automatisierten Online-Deobfuscator-Dienste — jede Obfuskierung kompiliert den Code in eigenen Bytecode mit einer einzigartigen virtuellen Maschine, wodurch universelle Werkzeuge unmöglich werden. Die Standard-Obfuskierung lässt sich weit leichter aushebeln: Sie kann mit automatisierten Werkzeugen und Beautifiern oft teilweise rückgängig gemacht werden. Die VM-Obfuskierung erfordert es, die virtuelle Maschine vollständig per Reverse Engineering zu erschließen, ihren Bytecode zu entschlüsseln und zu dekodieren, ihren Befehlssatz zu verstehen und die Ausführung nachzuverfolgen — ein Prozess, der Wochen konzentrierter Arbeit dauern kann. Ohne VM Self Defending können leistungsfähige KI-Agenten (z. B. Claude Opus 4.7) den Bytecode nachverfolgen und den ursprünglichen Code bei kleineren Codebasen grob rekonstruieren. Mit aktiviertem VM Self Defending stören mehrschichtige Anti-LLM-Abwehrmaßnahmen — Anti-Hooking, realmübergreifende Integritätsprüfung und Nativitätsprüfungen des Bytecodes — genau die dynamischen Techniken, mit denen ein Agent dem Bytecode Sinn abgewinnt: Instrumentierung, Hooking und Ausführung in einer Sandbox. Statisches Lesen der Datei bleibt möglich, offenbart aber nur undurchsichtigen Bytecode, und jeder Versuch, die interpretierende Laufzeit zu beobachten, löst eine Integritätsprüfung aus. Allein aus der Datei wird eine automatisierte KI-Deobfuskierung damit undurchführbar. Zur weiteren Härtung Ihres Codes: Kapseln Sie sensible Funktionen in eine IIFE, damit Namen vollständig transformiert werden, und aktivieren Sie Härtungsoptionen wie die Bytecode-Verschlüsselung. Erfahren Sie mehr darüber, wie die VM Code transformiert.

Die VM-Obfuskierung ist eine komplexe Technologie, und manche Randfälle werden möglicherweise nicht vollständig unterstützt. Wenn Ihr Code nach der VM-Obfuskierung nicht mehr funktioniert, können Sie das Problem mit vmTargetFunctionsMode: 'comment' eingrenzen, indem Sie gezielt einzelne Funktionen obfuskieren. In unserem Leitfaden zur Fehlerbehebung finden Sie eine Schritt-für-Schritt-Anleitung, wie Sie den problematischen Code identifizieren und das Problem melden.

Der Obfuscator fügt neuen Code ein, um vor Debugging und Reverse Engineering zu schützen. Strings werden in Hexadezimalform umgewandelt, 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 hervorragend komprimieren, was die meisten Server standardmäßig aktiviert haben.

Jede Obfuskierung wirkt sich in gewissem Maße auf die Performance aus. Die Standard-Obfuskierung verursacht nur minimalen Overhead. Die VM-Obfuskierung hat deutlich größere Auswirkungen, die stark vom Code abhängen – rekursionslastiger Bytecode ist zum Beispiel spürbar langsamer. Im Durchschnitt verursacht die Low-Voreinstellung etwa den 10-fachen Aufwand; die Anti-LLM-Voreinstellung mit Self Defending und Debug Protection ist rund 12-mal langsamer. Die Performance hängt stark vom Code ab — rekursionslastiger Bytecode ist zum Beispiel spürbar langsamer. Sie können die Balance feinjustieren, indem Sie die Optionen anpassen oder die VM-Obfuskierung selektiv nur auf sensible Codeabschnitte anwenden. Optimierungstipps finden Sie in unserem Leitfaden mit Best Practices.

Nein, das ist nicht empfehlenswert und zerstört den Code in manchen Fällen (insbesondere wenn Sie Self Defending aktivieren). Sie können Ihren Code aber vor der Obfuskierung durch einen Minifier laufen lassen.

Bei Dateien unter 4.4 MB wird der Quellcode vollständig im Arbeitsspeicher verarbeitet und sofort als obfuskierte Ausgabe zurückgegeben. Größere Dateien (Tarife Team/Business) laden wir vorübergehend in einen sicheren Speicher hoch und löschen sie unmittelbar nach Abschluss der Obfuskierung. Als zusätzliche Absicherung läuft alle 5 Minuten ein Bereinigungsauftrag, der sämtliche Dateien entfernt, die älter als 5 Minuten sind. Ihr Code wird niemals aufbewahrt.

Nein, es ist unmöglich, den obfuskierten Code wieder in Ihren ursprünglichen Code zurückzuverwandeln — bewahren Sie das Original daher sicher auf.

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

Wir unterstützen ES2015 (ES6) und alle modernen JavaScript-Funktionen, einschließlich ES2022+-Syntax, privater Klassenfelder, async/await, Optional Chaining und mehr. TypeScript und JSX müssen vor der Obfuskierung zu JavaScript kompiliert werden. Mit einem kostenpflichtigen Tarif können Sie außerdem HTML-Dateien obfuskieren — fügen Sie das Attribut data-javascript-obfuscator zu allen <script>-Tags hinzu, die Sie schützen möchten; sie werden dann einzeln obfuskiert, während die HTML-Struktur erhalten bleibt. Beachten Sie, dass der Code in jedem markierten Skript in sich geschlossen sein muss (keine Verweise auf andere Skripte) und dass ES-Modul-Skripte übersprungen werden.

Die obfuskierte Ausgabe — einschließlich des VM-Interpreters und der Self-Defending-Schicht — wird aktiv unterstützt und auf Evergreen-Desktop-Browsern sowie iOS 16+ getestet (grob die letzten 3 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.