JavaScript Obfuscator
Umbenannt, verschlüsselt, läuft noch

Was ein JavaScript Obfuscator macht

Quellcode gibt zwei Dinge auf einmal preis: was ein Programm tut und wie es das tut. Deshalb bekommt ein Leser, der ein Modul erhält, die Überlegung gratis dazu.

Ein Obfuscator trennt die beiden. Dieser JavaScript Obfuscator behält das Verhalten und nimmt die Namen, die String-Literale und die einfachen Zahlen weg.

Er arbeitet vom Syntaxbaum aus, nicht vom Text. Weil der Baum schon weiß, welcher Name eine Variable und welcher eine Eigenschaft ist, kann der Umbenenner pro Gültigkeitsbereich arbeiten statt global.

Vier Transformationen sitzen hinter einem Editor, und jede ist ein Kästchen. Also kannst du ein Programm allein umbenennen oder alle laufen lassen für ein viel härteres Lesen.

Nichts läuft und nichts wird hochgeladen. Da der Leser das Modul nur parst und umschreibt, unterscheidet sich ein Programm unter einer Geheimhaltungsklausel hier nicht von einem öffentlichen.

Wie ein JavaScript Obfuscator ein Skript umschreibt

Der erste Durchgang baut den Syntaxbaum, genau wie ein Validator. Das Regelwerk ist ECMA-262, also passt der Baum zu dem, was eine Engine bauen würde.

Vom Baum aus geht der Umbenenner jeden Bereich der Reihe nach durch. Ein Parameter, ein Local, ein Funktionsname und ein Klassenname bekommen jeweils einen neuen undurchsichtigen Namen aus einem Bereich, der nicht mit einem schon benutzten Namen kollidieren kann.

Zwei Dinge bleiben absichtlich unberührt. Eine Eigenschaft eines Objekts ist keine Variable, also behält obj.userName seine Schreibweise. Ein Name, der über das Modul hinausreicht, etwa ein exportierter Name oder ein Global, das die Seite aufruft, bleibt ebenfalls, außer du schaltest das Umbenennen der obersten Ebene ein.

Jeder Durchgang erzeugt seinen eigenen Baum, statt den Text zu bearbeiten. Der Schreiber läuft erst am Ende, also wird ein Programm, das nicht parst, nie halb umgeschrieben.

Der letzte Schritt parst die Ausgabe erneut. Weil der Obfuscator sein eigenes Ergebnis zurückliest, bevor er es zeigt, gibt ein Durchgang, der ungültigen Code erzeugte, deine Originaldatei zurück.

Die vier Transformationen, in der Reihenfolge, in der sie laufen

Das Umbenennen läuft zuerst. Parameter, Locals, Funktions- und Klassennamen werden kurze undurchsichtige Namen wie _0x1a2b, mit Bereich, sodass zwei Funktionen denselben Namen sicher nutzen. Exportierte und Namen der obersten Ebene bleiben, außer du verlangst sie auch.

Der String-Durchgang läuft danach. Jedes String-Literal wandert in ein Array oben, und jede Nutzung wird eine Suche per Index durch einen kleinen Accessor, der die Reihenfolge dreht. Weil die Strings nicht mehr neben dem Code stehen, der sie liest, findet eine Suche nach einer Nachricht nichts Nützliches mehr.

Die Zahlenkodierung folgt. Jede einfache Ganzzahl wird hexadezimal gedruckt, also wird 1000 zu 0x3e8. Der Wert ändert sich nicht; die Ziffern lesen sich nur nicht mehr als vertraute Zahl.

Das Kompaktieren kommt zuletzt. Das ganze Modul läuft durch den Minifier, der die Kommentare und den Abstand streicht, also ist das Ergebnis ein dichter Block statt ordentlicher Zeilen.

Was Verschleierung nicht tut

Sie verbirgt deinen Code nicht vor einem entschlossenen Leser. Jede Transformation hier ist im Prinzip umkehrbar, und für die meisten gibt es ein Werkzeug.

Sie hält kein Geheimnis sicher. Ein Schlüssel, der in ein Browser-Skript kompiliert ist, ist ein Schlüssel, den der Browser hat, und jeder, der die Seite lädt, kann ihn lesen. Weil Verschleierung nur den Aufwand hebt, gehört ein API-Schlüssel auf einen Server.

Sie stoppt das Kopieren nicht. Jemand kann eine umgeschriebene Datei immer noch speichern, ausliefern und ausführen. Die Lizenz und der Vertrag sind es, die das regeln, und keines ist ein Build-Schritt.

Sie macht ein Modul nicht schneller, und sie kann es langsamer machen. Weil die String-Suchen zur Laufzeit etwas Arbeit kosten, ist der Tausch Lesbarkeit gegen ein paar Millisekunden.

Sie schützt auch kein Skript auf dem Server. Wer Zugriff auf die Maschine hat, hat die Originaldatei, egal was der Browser bekam.

Das Namenspräfix und die Ausgabe gültig halten

Das Namenspräfix ist die eine Einstellung jenseits der Kästchen, und es gibt sie, um eine Kollision zu vermeiden. Ein Generator, der einen Helfer namens a oder b ausgibt, kann mit einem Global der Seite kollidieren, also nimmt ein kurzes, eigenes Präfix wie _0x das Risiko weg.

Das Umbenennen der obersten Ebene bleibt standardmäßig aus. Eingefügter Code ist oft ein klassisches Modul, wo eine Funktion der obersten Ebene eine Eigenschaft von window wird, die eine andere Datei beim Namen ruft, und sie dort umzubenennen würde einen Aufrufer brechen, den der Obfuscator nicht sieht.

In einem Modul oder einer IIFE erreicht nichts von außen diese Namen, also ist das Umbenennen der obersten Ebene dort sicher und verbirgt weit mehr.

Jeder Lauf endet mit einem Parsen seiner eigenen Ausgabe. Weil der Obfuscator sein eigenes Ergebnis zurückliest, bevor er es zeigt, meldet er eine Transformation, die ungültigen Code erzeugte, statt den Code zu übergeben.