• Was ist Code-Verschleierung?
• Warum sollte man Code verschleiern?
• Was sind die Unterschiede zwischen den Professional- und Personal-Editionen von secureSWF?
• Kann ich eine Testversion bekommen?
• DÄndert secureSWF den Quellcode meiner Applikation?
• Wie schützt secureSWF SWF-Dateien?
• Was ist Statement-Level-Randomisierung?
• Was ist Kontrollstruktur-Verschleierung?
• Was ist Dynamic Code Wrapping?
• Was ist Verschlüsselung von String-Literalen?
• Warum sollte ich Verschleierung nutzen, um Sicherheitsschwachstellen zu verstecken? Wäre es nicht besser, sicherzustellen, dass ich gar keine Schwachstellen habe?
• Was passiert, wenn ich versuche, einen Decompiler bei einer durch secureSWF geschützten Applikation zu nutzen?
• Welche Art von Codeoptimierungsverfahren bietet secureSWF?
• Welche Flash-Versionen unterstützt secureSWF?
• Gibt es einen Weg, in meinem Quellcode zu deklarieren, welche Identifier ich nicht verschleieren lassen möchte?
• Kann ich reguläre Ausdrücke verwenden, um bestimmte Identifier aus- oder einzuschließen?
• Wie integriere ich secureSWF in meinen automatischen Build-Prozess?
• Was ist mit Tools, die SWF-Dateien in ausführbare Programme wie .EXE-Dateien verwandeln?
• Ist die Nutzung von eval in ActionScript immer in Ordnung?
• Ist Flash Remoting ein Problem für secureSWF?
• Meine Applikation nutzt Flash-Komponenten. Kann ich secureSWF trotzdem nutzen?
• Wie kann secureSWF Decompiler funktionsunfähig machen, ohne, dass der Flash Player betroffen wird?
• Was bedeutet Umbenennung in "nichtdarstellbare und illegale Zeichen"?
• Produziert secureSWF nichtverifizierbaren Code?

Verschleierung bedeutet, die Bedeutung des Codes zu verdecken, damit er verwirrender und schwerer zu verstehen ist. Es ist keine Verschlüsselung, aber im Kontext von Code ist diese Maßnahme sinnvoller. Obwohl Verschlüsselung Ihren Code komplett unlesbar machen kann, leidet sie unter einem klassischen Problem der Kryptographie - der Schlüssel muss bei den verschlüsselten Daten bleiben. Es könnte also ein automatisches Tool erstellt werden, um den Code zu entschlüsseln. Sobald dies passiert, ist der vollständig entschlüsselte, unverschleierte Code sichtbar.

Natürlich ist Verschleierung (oder sogar Verschlüsselung) kein hundertprozentiger Schutz. Wenn ein Hacker hartnäckig genug ist, kann er oder sie die Bedeutung Ihres Codes herausfinden. Das Ziel eines Obfuscators ist es, den Prozess des Reverse Engineerings extrem zeitaufwändig und schwierig zu machen, damit er den Aufwand nicht lohnt. So sollen sämtliche Hobbyhacker und so viele erfahrene Hacker wie möglich gestoppt werden.

Verschleierung entfernt den Kontext aus kompiliertem Code, den Menschen (und Decompiler) nutzen würden, um die Bedeutung des Codes zu entziffern. Der Trick ist, diesen Kontext vor boshaften Absichten zu schützen, während gleichzeitig die vollständige Ausführungsintegrität des Originalprogramms bewahrt wird. Die Produkte von Kindisoft haben dies vollständig erreicht - Ihr Programm wird die selben Ergebnisse produzieren, die es auch vor der Verschleierung produziert hat, aber der Code ist viel weniger anfällig gegenüber Reverse Engineering.

Flash-Applikationen lassen sich leicht mit Reverse Engineering knacken. Dies ist kein Designfehler - sondern einfach eine unvermeidbare Tatsache bei interpretierten, zwischenkompilierten Sprachen. Java und .NET-Applikationen leiden unter genau dem gleichen Problem. Als Produkt einer höheren Sprache im Vergleich zu binärem Maschinencode, sind die zwischenkompilierten Dateien voller Identifier und Algorithmen, die leicht verständlich sind. Letztlich ist es natürlich schwierig, etwas leicht verständlich und flexibel zu machen und gleichzeitig die wichtigen Details zu verstecken.

Somit kann jeder, der im Besitz eines Flash ActionScript-Decompilers wie ASV oder Sothink Decompiler ist, Ihren Code einsehen und Ihre Applikation dem Reverse Engineering unterziehen. Plötzlich sind Lizenz-Code, Kopierschutzmechanismen und proprietäre Logik Ihres Programms für alle viel einfacher einsehbar - egal, ob es legal ist oder nicht. Jeder kann die Details Ihrer Software aus irgendeinem Grunde nutzen. Man könnte nach ausnutzbaren Sicherheitsschwachstellen suchen, Ihre Ideen stehlen, Programme cracken, etc.

Doch ist noch nichts verloren. Entwickler, die sich über Ihr geistiges Eigentum in Flash-Programmen Gedanken machen, müssen verstehen, dass es eine Lösung gibt, um Dekompilierung und Reverse Engineering zu stoppen. Verschleierung sorgt für nahtlose Umbenennung von Identifiern in SWF-Dateien sowie andere Techniken, um Decompiler in die Flucht zu schlagen. Eine richtig angewandte Verschleierung kann den Schutz vor Dekompilierung in vielfacher Hinsicht erhöhen, während Verhalten und Output der Applikation gleich bleibt.

Die Professional-Edition bietet einen verbesserten Schutz, um Dekompilierung zu verhindern, eine Verkleinerung der Dateigröße, um Arbeitsspeicher zu sparen und Ladezeiten zu verbessern, die Verschlüsselung von String-Literalen, Integration in den Build-Prozess und andere Features, mit denen Sie Ihre SWF-Dateien vor Download und Weitergabe schützen können.

Die Personal-Edition ist ein Obfuscator für Einsteiger. Sie richtet sich an Freelancer und Freeware-Autoren. Sie können eine detailierte Vergleichstabelle hier finden.

Natürlich! Sie können die Demo direkt hier herunterladen, oder aber eine voll funktionsfähige Testversion der secureSWF Professional-Edition hier beantragen.

Außerdem kommen secureSWF Personal- und Professional-Editionen, die über das Internet gekauft werden, mit einer 30-tägigen Geld-zurück-Garantie.

Nein. secureSWF arbeitet lediglich mit bereits kompilierten SWF-Dateien. Ihr Quellcode ist nicht benötigt (oder betroffen).

secureSWF benennt alle möglichen Methoden, Felder, Klassen und Symbolinstanzen um und entfernt Frame-Labels. Es erkennt automatisch, welche Identifier sich sicher umbenennen lassen und ist genau konfigurierbar, sodass Sie selbst die Identifier wählen können, die es umbenennen oder überspringen soll.

secureSWF enthält außerdem weitere fortschrittliche Verschleierungsverfahren wie Kontrollstruktur-Verschleierung, Statement-Level-Randomisierung, Dynamic Code Wrapping und die Verschlüsselungen von String-Literalen. Kein Obfuscator kann die Dekompilierung in allen Fällen verhindern - jedoch sorgt secureSWF für einen extrem schwer lesbaren Decompiler-Output. Damit lässt es Decompiler mehr wie Disassembler arbeiten!

Statement-Level-Randomisierung ist unsere proprietäre Verschleierungs-Methodologie, die die Sequenz der SWF Bytecode-Anweisungen zufällig restrukturiert und damit ihre Nutzung durch Decompiler zwecks Erstellung eines kompletten ActionScript-Statements erschwert. Es entfernt alle möglichen Links zwischen dem kompilierten Bytecode und dem ActionScript-Quellcode, wodurch das Dekompilieren praktisch unmöglich wird. Im Gegensatz zur traditionellen Verschleierung der Kontrollstruktur kann Statement-Level-Randomisierung die Größe des Quellcodes sogar verkleinern und die Geschwindigkeit verbessern.

Kontrollstruktur-Verschleierung ist ein traditionelles, aber effektives Verschleierungsverfahren. Die zum Reverse Engineering verwendeten Tools und der Flash Player unterscheiden sich in einem wichtigen Punkt. Der Flash Player führt Code aus - wenn der Code "GOTO" sagt, führt der Flash Player das aus. Reverse-Engineering Tools versuchen, ganze Codesektionen auf einmal anzusehen und Codestücke wie For-Schleifen oder If-Blöcke, oder andere im Quellcode vorhandene Strukturen zu identifizieren. Für den Flash Player sind diese Strukturen nicht relevant und auch nicht benötigt. Schleifen entsprechen einfach einem häufig gefolgten GOTO.

Kontrollstruktur-Verschleierung zerstört die übliche Einsicht kompilierter Kontrollstrukturen. Dem Flash Player ist es egal, ob ein Set von GOTOs durch ein anderes ersetzt wurde. Aber Reverse-Engineering-Tools bleibt jetzt nur Spaghetti-Code. Da ActionScript keinen tatsächlichen GOTO-Befehl hat (kompilierter Bytecode hat ihn), stellt dies oft ein bedeutendes Problem beim Reverse Engineering dar.

Damit werden Codeblöcke des ActionScript-Bytecodes in Ihren SWF-Dateien dynamisch gewrappt, wodurch es für Decompiler viel schwieriger wird, Ihren Code überhaupt zu finden.

secureSWF Professional implementiert Laufzeit-String-Verschlüsselung/Entschlüsselung. Wie zuvor gesagt ist jegliche Verschlüsselung, die zur Laufzeit ausgeführt wird, von Natur aus unsicher. Das heißt, ein cleverer Hacker kann sie früher oder später knacken, aber wir dachten, dass es sich für im Client-Code vorhandene Strings dennoch lohnt. Im Prinzip ermöglichen wir es Ihnen, einen sicheren Verschlüsselungsalgorithmus (mit einem Kniff, um Decompiler auszutricksen) auf jegliche Strings in Ihrer Applikation anzuwenden. Diese Strings werden nur zur Laufzeit bei ihrer Verwendung entschlüsselt.

Wenn ein Hacker Ihren Code haben will, würde er nicht blind nach umbenannten Typen suchen. Er würde wahrscheinlich nach Strings suchen, die ihn gleich an die Stellen im Code bringen, welche für ihn interessant sind. Die Suche nach Strings ist extrem einfach. String-Verschlüsselung wirft Hobbyhacker aus der Bahn und wird auch viele weitere unerfahrene Hacker abschrecken. Sie sollten sicherstellen, dass Sie Stringverschlüsselung anwenden, um sensible Informationen wie URLs, feste Nutzernamen und Passwörter, oder Spiele-Cheats usw. zu schützen. Dieser Algorithmus sorgt für eine winzige Leistungsverringerung zur Laufzeit, aber wie sämtliche anderen Features bei secureSWF ist auch diese Option voll konfigurierbar.

Die Beseitigung von Sicherheitsschwachstellen ist das Beste, was Sie tun können. Jedoch kann niemand null Schwachstellen garantieren. Wenn dies möglich wäre, würden wir nicht den ständigen Fluss an Patches von jedem Softwarepublisher sehen. Diese Probleme existieren auch mit "schwachstellenfreiem

Viele der Code-Änderungen, die durch secureSWF durchgeführt werden, sorgen für einen Absturz oder eine Fehlfunktion des Decompilers. Selbst wenn secureSWF einen Decompiler nicht völlig zum Absturz bringt, hindert er ihn an der Generierung sinnvollen Outputs. Zum Beispiel könnte der Decompiler eine leere oder falsche Funktion generieren, weil auf sie Kontrollstruktur-Verschleierung angewandt wurde. Und zusätzliche Veränderungen wie Statement-Level-Randomisierung machen es fast unmöglich, herauszufinden, was überhaupt passiert.

Neben Umbenennung optimiert secureSWF Tag-Header, entfernt doppelte Not-Statements, eliminiert tote Codeblöcke und optimiert Kontrollstruktur-Anweisungen durch die Reduktion der Anzahl an GOTOs im Code.

secureSWF unterstützt alle Flash-Versionen von 4 bis CS4 einschließlich ActionScript v3, und Flex v2 und v3.

Leider gibt es keinen direkten Weg, entsprechende Informationen in Ihrem ActionScript v1.0 oder v2.0 einzuschließen, um Identifier vor der Verschleierung zu bewahren. Aber Sie können ein eindeutiges Prefix oder Postfix zu Identifiernamen hinzufügen, und sie dann mithilfe regulärer Ausdrücke innerhalb secureSWF ausschließen.

Wir arbeiten zur Zeit daran, diese Option auch für ActionScript v3.0 anzubieten.

Ja, Sie können reguläre Ausdrücke verwenden, um bestimmte Identifier aus- oder einzuschließen. Tun Sie dies, indem Sie auf den "Erweitert"-Button rechts unter dem Identifier-Namensbaum/Liste klicken. Dort können Sie die Selektionskriterien einstellen, indem Sie die Identifiertypen und ein entsprechendes String-Muster, mit dem die Identifiernamen verglichen werden sollen, auswählen. Das String-Muster kann alternativ auch als regulärer Ausdruck behandelt werden.

secureSWF Professional besitzt ein Befehlszeilen-Interface, mit dessen Hilfe sie es in Scripting-Umgebungen integrieren können. Zusätzlich dazu sind die Konfgurationsdateien von secureSWF im XML-Format geschrieben, was sie leicht les- und veränderbar macht.

Flash-Projektoren werden absolut kein Problem haben, mit von secureSWF verschleierten SWF-Dateien zu arbeiten.

Meistens. secureSWF kann herausfinden, wann eval (oder set) benutzt wird, und wie es damit in den meisten Fällen umzugehen hat, etwa:

for(i = 0; i < 10; i++)
    trace(eval("myArray" + i));

Aber in anderen von uns gesehenen Fällen war der Umgang mit eval und set sowohl ein Problem für secureSWF wie auch für uns:

vars = "abc";

...

set(vars.substring(0,1), 5);

...

trace(a);

Die Regel lautet - Sie können eval und set verwenden, um zur Schaffung eines Variablennamens Strings zu verknüpfen. Aber wenn Sie etwas ähnlich des Beispiels oben haben, brauchen Sie secureSWF nicht zur Verarbeitung des Codes - er ist bereits verschleiert :-)

Überhaupt nicht. In manchen Fällen müssen Sie einen zusätzlichen Schritt durchführen, um beim Remoting genutzte Identifier manuell auszuschließen. Aber in den meisten Fällen funktioniert es ohne weiteres Zutun.

Ja. Sie können sogar den Code der Komponente verschleiern!

Decompiler und der Flash Player unterscheiden sich an einem wichtigen Punkt. Der Flash Player führt Code aus - wenn der Code "GOTO" sagt, führt der Flash Player das aus. Reverse-Engineering Tools versuchen, ganze Codesektionen auf einmal anzusehen und Codestücke wie For-Schleifen oder If-Blöcke, oder andere im Quellcode vorhandene Strukturen zu identifizieren. Für den Flash Player sind diese Strukturen nicht relevant und auch nicht benötigt. Schleifen und If-Anweisungen entsprechen einfach einem häufig gefolgten GOTO.

er Code von secureSWF zerstört die bekannte Sicht kompilierter Kontrollstrukturen. Dem Flash Player ist es egal, ob ein Set von GOTOs durch ein anderes ersetzt wurde. Aber Decompilern bleibt nur Spaghetti-Code. Da ActionScript keinen tatsächlichen GOTO-Befehl hat (kompilierter Bytecode hat ihn), stellt dies oft ein bedeutendes Problem beim Reverse Engineering dar.

secureSWF wird Ihre Variablen, Methoden und Klassen so umbenennen, dass die neuen Namen stets mit Zeichen beginnen, die Identifier in ActionScript nicht als Anfangsbuchstabe haben dürfen (etwa "?"). Weiterhin nutzt secureSWF nichtdarstellbaren Zeichen mit niedrigen ASCII-Codes, wie das Zeilenvorschub-Zeichen. Die Nutzung dieser Zeichen funktioniert im Flash Player, aber wird den Decompiler verwirren. Und noch wichtiger: Sie können sicher sein, dass der Output des Decompilers nicht direkt für den Flash-Compiler genutzt werden kann.

Nur, wenn Ihr Input-Code nicht verifizierbar ist. Im Gegensatz zu anderen Obfuscators machen die Änderungen von secureSWF verifizierbaren Code nicht unverifizierbar.