Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Workflow

Schützen Sie Ihre Flash-Dateien mithilfe der Verschlüsselung vor Dekompilierern

by
Read Time:16 minsLanguages:

German (Deutsch) translation by Władysław Łucyszyn (you can also view the original English article)

Zweimal im Monat besuchen wir einige der Lieblingsbeiträge unserer Leser aus der gesamten Geschichte von Activetuts+. Dieses Tutorial wurde erstmals im Februar 2010 veröffentlicht.

In diesem Tutorial werde ich eine Technik demonstrieren, mit der ich Code und Assets vor Diebstahl schütze.

Dekompiler sind eine echte Sorge für Leute, die Flash-Inhalte erstellen. Sie können sich viel Mühe geben, um das beste Spiel zu entwickeln, dann kann jemand es stehlen, das Logo ersetzen und es auf seiner Website platzieren, ohne Sie zu fragen. Wie? Verwenden eines Flash-Dekompilierers. Wenn Sie Ihre SWF nicht schützen, kann sie per Knopfdruck dekompiliert werden und der Dekompiler gibt lesbaren Quellcode aus.


Bevor wir anfangen

Ich habe ein kleines Projekt von mir verwendet, um zu demonstrieren, wie anfällig SWFs für die Dekompilierung sind. Sie können es herunterladen und selbst über den obigen Quelllink testen. Ich habe Sothink SWF Decompiler 5 verwendet, um den SWF zu dekompilieren und unter seine Haube zu schauen. Der Code ist gut lesbar und Sie können ihn ziemlich leicht verstehen und wiederverwenden.


Was können wir dagegen tun?

Ich habe eine Technik zum Schutz von SWFs vor Dekompilierern entwickelt und werde sie in diesem Tutorial demonstrieren. Wir sollten in der Lage sein, dies zu produzieren:

Der Code, der dekompiliert wird, ist eigentlich der Code zum Entschlüsseln des Inhalts und hat nichts mit Ihrem Hauptcode zu tun. Außerdem sind die Namen unzulässig, sodass sie nicht zurückkompiliert werden. Versuchen Sie es selbst zu dekompilieren.

Bevor wir loslegen, möchte ich darauf hinweisen, dass dieses Tutorial nicht für Anfänger geeignet ist und Sie über solide Kenntnisse in AS3 verfügen sollten, wenn Sie mitmachen möchten. In diesem Tutorial geht es auch um die Programmierung auf niedriger Ebene, die Bytes, ByteArrays und das Bearbeiten von SWF-Dateien mit einem Hex-Editor umfasst.

Wir brauchen Folgendes:

  • Ein SWF zum Schutz. Fühlen Sie sich frei, die SWF herunterzuladen, an der ich arbeiten werde.
  • Flex SDK. Wir werden es verwenden, um Inhalte mit dem Embed-Tag einzubetten. Sie können es von opensource.adobe.com herunterladen.
  • Ein Hex-Editor. Ich werde einen kostenlosen Editor namens Hex-Ed verwenden. Sie können es von nielshorn.net herunterladen oder einen Editor Ihrer Wahl verwenden.
  • Ein Dekompiler. Es ist zwar nicht notwendig, aber es wäre schön zu überprüfen, ob unser Schutz tatsächlich funktioniert. Sie können eine Testversion von Sothink SWF Decompiler von sothink.com herunterladen

Schritt 1: Laden Sie SWF zur Laufzeit

Öffnen Sie ein neues ActionScript 3.0-Projekt und stellen Sie es so ein, dass es mit dem Flex SDK kompiliert wird (ich verwende FlashDevelop zum Schreiben von Code). Wählen Sie eine SWF-Datei aus, die Sie schützen möchten, und binden Sie sie mithilfe des Tags "Einbetten" als Binärdaten ein:

Jetzt ist die SWF als ByteArray in die Loader-SWF eingebettet und kann über Loader.loadBytes() geladen werden.

Am Ende sollten wir diesen Code haben:

Kompilieren Sie und sehen Sie, ob es funktioniert (es sollte). Von nun an werde ich die eingebettete SWF als "geschützte SWF" bezeichnen, und die SWF haben wir gerade als "Lade-SWF" kompiliert.


Schritt 2: Analysieren Sie das Ergebnis

Versuchen wir zu dekompilieren und zu sehen, ob es funktioniert.

Ja! Die Assets und der Originalcode sind weg! Was jetzt angezeigt wird, ist der Code, der die geschützte SWF lädt und nicht deren Inhalt. Dies würde wahrscheinlich die meisten erstmaligen Angreifer stoppen, die mit Flash nicht allzu vertraut sind, aber es ist immer noch nicht gut genug, um Ihre Arbeit vor erfahrenen Angreifern zu schützen, da die geschützte SWF innerhalb der ladenden SWF unberührt auf sie wartet.


Schritt 3: Dekomprimieren des SWF

Öffnen wir die Laden-SWF mit einem Hex-Editor:

Es sollte wie zufällige Binärdaten aussehen, da es komprimiert ist und mit ASCII "CWS" beginnen sollte. Wir müssen es dekomprimieren! (Wenn Ihre SWF mit "FWS" beginnt und Sie aussagekräftige Zeichenfolgen in der SWF sehen, wurde sie wahrscheinlich nicht komprimiert. Sie müssen die Komprimierung aktivieren, um mitzumachen.)

Zuerst mag es schwierig klingen, ist es aber nicht. Das SWF-Format ist ein offenes Format und es gibt ein Dokument, das es beschreibt. Laden Sie es von adobe.com herunter und scrollen Sie im Dokument nach unten zu Seite 25. Es gibt eine Beschreibung des Headers und wie die SWF komprimiert wird, damit wir sie einfach dekomprimieren können.

Dort steht, dass die ersten 3 Bytes eine Signatur (CWS oder FWS) sind, das nächste Byte die Flash-Version, die nächsten 4 Bytes die Größe der SWF. Der Rest wird komprimiert, wenn die Signatur CWS ist, oder unkomprimiert, wenn die Signatur FWS ist. Schreiben wir eine einfache Funktion zum Dekomprimieren einer SWF:

Die Funktion macht ein paar Dinge:

  1. Es liest den unkomprimierten Header (die ersten 8 Bytes) ohne die Signatur und merkt sich diese.
  2. Es liest den Rest der Daten und dekomprimiert sie.
  3. Es schreibt den Header (mit der "FWS" -Signatur) und die unkomprimierten Daten zurück und erstellt eine neue, unkomprimierte SWF.

Schritt 4: Erstellen eines Dienstprogramms

Als Nächstes erstellen wir in Flash ein praktisches Dienstprogramm zum Komprimieren und Dekomprimieren von SWF-Dateien. Kompilieren Sie in einem neuen AS3-Projekt die folgende Klasse als Dokumentklasse:

Wie Sie wahrscheinlich bemerkt haben, habe ich zwei Dinge hinzugefügt: das Laden von Dateien und die Komprimierungsfunktion.

Die Komprimierungsfunktion ist identisch mit der Dekomprimierungsfunktion, jedoch umgekehrt. Das Laden der Datei erfolgt mit FileReference (FP10 erforderlich) und die geladene Datei wird entweder komprimiert oder nicht komprimiert. Beachten Sie, dass Sie die SWF lokal von einem eigenständigen Player aus ausführen müssen, da FileReference.browse() durch Benutzerinteraktion aufgerufen werden muss (der lokale eigenständige Player kann sie jedoch ohne ausführen).


Schritt 5: Dekomprimieren des Laden-SWF

Um das Werkzeug zu testen, starten Sie es, wählen Sie die Lade-SWF aus und wählen Sie, wo es gespeichert werden soll. Öffnen Sie es dann mit einem Hex-Editor und scrubben Sie durch. Sie sollten ASCII-Zeichenfolgen wie folgt sehen:


Schritt 6: Erneut analysieren

Kehren wir zu Schritt 2 zurück. Obwohl der Dekompiler keine nützlichen Informationen über die geschützte SWF angezeigt hat, ist es recht einfach, die SWF vom jetzt unkomprimierten Loader abzurufen. Suchen Sie einfach nach der Signatur "CWS" (wenn die geschützte SWF unkomprimiert ist, suchen Sie nach "FWS") und sehen Sie die Ergebnisse:

Was wir gefunden haben, ist ein DefineBinaryData-Tag, das die geschützte SWF enthält, und das Extrahieren von dort ist ein Kinderspiel. Wir sind dabei, eine weitere Schutzschicht über die ladende SWF hinzuzufügen: Verschlüsselung.


Schritt 7: Verschlüsselung

Um die geschützte SWF weniger "zugänglich" zu machen, werden wir eine Art Verschlüsselung hinzufügen. Ich habe mich für as3crypto entschieden und Sie können es von code.google.com herunterladen. Sie können stattdessen jede gewünschte Bibliothek verwenden (oder noch besser Ihre eigene Implementierung). Die einzige Voraussetzung ist, dass Binärdaten mit einem Schlüssel verschlüsselt und entschlüsselt werden können.


Schritt 8: Daten verschlüsseln

Als erstes möchten wir ein Dienstprogramm schreiben, um die geschützte SWF-Datei zu verschlüsseln, bevor wir sie einbetten. Es erfordert sehr grundlegende Kenntnisse der as3crypto-Bibliothek und ist ziemlich einfach. Fügen Sie die Bibliothek Ihrem Bibliothekspfad hinzu und schreiben Sie zunächst Folgendes:

Was ist denn hier los? Wir verwenden eine Klasse von as3crypto namens AESKey, um den Inhalt zu verschlüsseln. Die Klasse verschlüsselt 16 Bytes in einer Zeit (128 Bit), und wir müssen die Daten for-loopen, um alles zu verschlüsseln. Beachten Sie die zweite Zeile: data.length & ~ 15. Es stellt sicher, dass die Anzahl der verschlüsselten Bytes durch 16 geteilt werden kann und uns beim Aufruf von aes.encrypt() nicht die Daten ausgehen.

Hinweis: In diesem Fall ist es wichtig, den Verschlüsselungspunkt zu verstehen. Es ist nicht wirklich Verschlüsselung, sondern Verschleierung, da wir den Schlüssel in die SWF aufnehmen. Der Zweck besteht darin, die Daten in binären Müll umzuwandeln, und der obige Code erledigt seine Aufgabe, obwohl er bis zu 15 unverschlüsselte Bytes hinterlassen kann (was in unserem Fall keine Rolle spielt). Ich bin kein Kryptograf, und ich bin mir ziemlich sicher, dass der obige Code aus Sicht eines Kryptographen lahm und schwach aussehen könnte, aber wie gesagt, es ist ziemlich irrelevant, da wir den Schlüssel in die SWF aufnehmen.


Schritt 9: Verschlüsselungsdienstprogramm

Es ist Zeit, ein weiteres Dienstprogramm zu erstellen, mit dem wir SWF-Dateien verschlüsseln können. Es ist fast das gleiche wie der Kompressor, den wir zuvor erstellt haben, daher werde ich nicht viel darüber sprechen. Kompilieren Sie es in einem neuen Projekt als Dokumentklasse:

Führen Sie es nun aus und erstellen Sie eine verschlüsselte Kopie der geschützten SWF-Datei, indem Sie sie zuerst auswählen und dann unter einem anderen Namen speichern.


Schritt 10: Ändern des Laders

Kehren Sie zum ladenden SWF-Projekt zurück. Da der Inhalt jetzt verschlüsselt ist, müssen wir die Lade-SWF ändern und Entschlüsselungscode hinzufügen. Vergessen Sie nicht, den src im Embed-Tag so zu ändern, dass er auf die verschlüsselte SWF verweist.

Dies ist das gleiche wie zuvor, außer dass der Entschlüsselungscode in der Mitte steckt. Kompilieren Sie nun die Laden-SWF und testen Sie, ob sie funktioniert. Wenn Sie bisher sorgfältig vorgegangen sind, sollte das geschützte SWF fehlerfrei geladen und angezeigt werden.


Schritt 11: Mit einem Dekompiler nach innen schauen

Öffnen Sie die neue Laden-SWF mit einem Dekompiler und schauen Sie.

Es enthält über tausend Zeilen hart aussehenden Verschlüsselungscodes, und es ist wahrscheinlich schwieriger, die geschützte SWF-Datei herauszuholen. Wir haben ein paar weitere Schritte hinzugefügt, die der Angreifer ausführen muss:

  1. Er (oder sie) muss die DefineBinaryData finden, die den verschlüsselten Inhalt enthalten, und ihn extrahieren.
  2. Er muss ein Dienstprogramm erstellen, um es zu entschlüsseln.

Das Problem ist, dass das Erstellen eines Dienstprogramms so einfach ist wie das Einfügen vom Dekompiler in den Code-Editor und ein wenig Optimieren des Codes. Ich habe versucht, meinen Schutz selbst zu brechen, und es war ziemlich einfach - ich habe es in ungefähr 5 Minuten geschafft. Wir müssen also einige Messungen daran vornehmen.


Schritt 12: String-Verschleierung

Zuerst haben wir die geschützte SWF in die Lade-SWF eingefügt, dann verschlüsselt, und jetzt werden wir der Lade-SWF den letzten Schliff geben. Wir werden Klassen, Funktionen und Variablen in unzulässige Namen umbenennen.

Mit illegalen Namen meine ich Namen wie ,;!@@,^#^ und (^_^). Das Coole ist, dass dies für den Compiler wichtig ist, nicht aber für den Flash Player. Wenn der Compiler auf illegale Zeichen in Bezeichnern stößt, kann er diese nicht analysieren und das Projekt kann daher nicht kompiliert werden. Andererseits hat der Spieler keine Probleme mit diesen illegalen Namen. Wir können die SWF mit legalen Kennungen kompilieren, dekomprimieren und in eine Reihe bedeutungsloser illegaler Symbole umbenennen. Der Dekompiler gibt unzulässigen Code aus und der Angreifer muss die Hunderte von Codezeilen manuell durchgehen und unzulässige Bezeichner entfernen, bevor er ihn kompilieren kann. Er verdient es!

So sieht es vor einer Verschleierung von Zeichenfolgen aus:

Lasst uns beginnen! Dekomprimieren Sie die Laden-SWF mit dem zuvor erstellten Dienstprogramm und starten Sie einen Hex-Editor.


Schritt 13: Ihre erste Verschleierung

Versuchen wir, die Dokumentklasse umzubenennen. Angenommen, Sie haben den ursprünglichen Namen (Main) beibehalten, suchen wir ihn in der unkomprimierten Loader-SWF mit einem Hex-Editor:

Benennen Sie "Main" in ;;;; um. Suchen Sie nun nach anderen "Main" und benennen Sie sie in ;;;; auch um.

Stellen Sie beim Umbenennen sicher, dass Sie keine unnötigen Zeichenfolgen umbenennen, da sonst die SWF-Datei nicht ausgeführt wird.

Speichern Sie die SWF und führen Sie sie aus. Es klappt! Und schauen Sie, was der Dekompiler sagt:

Sieg!! :)


Schritt 14: Umbenennen der restlichen Klassen

Benennen Sie den Rest Ihrer Klassen weiter um. Wählen Sie einen Klassennamen und suchen Sie danach. Ersetzen Sie ihn durch unzulässige Symbole, bis Sie das Ende der Datei erreichen. Wie gesagt, das Wichtigste hier ist, Ihren gesunden Menschenverstand zu verwenden und sicherzustellen, dass Sie Ihre SWF nicht durcheinander bringen. Nach dem Umbenennen der Klassen können Sie mit dem Umbenennen der Pakete beginnen. Beachten Sie, dass Sie beim Umbenennen eines Pakets auch die Punkte löschen und daraus einen langen unzulässigen Paketnamen machen können. Schauen Sie was ich gemacht habe:

Nachdem Sie die Klassen und Pakete umbenannt haben, können Sie Funktionen und Variablen umbenennen. Sie sind noch einfacher umzubenennen, da sie normalerweise nur einmal in einer großen Wolke angezeigt werden. Stellen Sie erneut sicher, dass Sie nur "Ihre" Methoden und nicht die integrierten Flash-Methoden umbenennen. Stellen Sie sicher, dass Sie den Schlüssel nicht auslöschen (in unserem Fall "activetuts").


Schritt 15: Komprimieren Sie die SWF

Nach dem Umbenennen möchten Sie die SWF-Datei wahrscheinlich komprimieren, damit sie kleiner wird. Kein Problem, wir können das zuvor erstellte Komprimierungsprogramm verwenden und es wird die Arbeit erledigen. Führen Sie das Dienstprogramm aus, wählen Sie die SWF-Datei aus und speichern Sie sie unter einem anderen Namen.


Abschluss: Werfen Sie einen letzten Blick

Öffnen Sie es ein letztes Mal und schauen Sie an. Die Klassen, die Variablen und die Methodennamen sind verschleiert und die geschützte SWF befindet sich irgendwo im Inneren, verschlüsselt. Diese Technik kann zunächst langsam angewendet werden, dauert jedoch nach einigen Malen nur wenige Minuten.

Vor einiger Zeit habe ich ein automatisches Dienstprogramm erstellt, um die geschützte SWF für mich in die Laden-SWF zu injizieren, und es hat gut funktioniert. Das einzige Problem ist, dass wenn es mit einem automatischen Dienstprogramm injiziert werden kann, es mit einem anderen Dienstprogramm entschlüsselt werden kann. Wenn der Angreifer also ein Dienstprogramm dafür erstellt, erhält er problemlos alle Ihre SWF. Aus diesem Grund ziehe ich es vor, die SWFs jedes Mal manuell zu schützen und eine geringfügige Änderung hinzuzufügen, damit die Automatisierung schwieriger wird.

Eine weitere nette Anwendung der Technik ist das Sperren von Domänen. Anstatt die SWF mit einer konstanten Zeichenfolge zu entschlüsseln, können Sie sie mit der Domäne entschlüsseln, auf der die SWF gerade ausgeführt wird. Anstatt eine if-Anweisung zum Überprüfen der Domain zu haben, können Sie eine leistungsfähigere Methode einführen, um die SWF vor der Platzierung auf anderen Websites zu schützen.

Als letztes möchten Sie möglicherweise den Verschlüsselungscode durch Ihre eigene Implementierung ersetzen. Warum? Wir haben Anstrengungen unternommen, um den Kryptocode illegal zu machen, aber der von uns verwendete Code stammt aus einer beliebten Open-Source-Bibliothek, und der Angreifer könnte ihn als solchen erkennen. Er wird eine saubere Kopie herunterladen, und alle Verschleierungsarbeiten werden unnötig. Wenn Sie jedoch Ihre eigene Implementierung verwenden, muss er alle illegalen Namen korrigieren, bevor er fortfahren kann.


Andere Schutzmethoden

Da SWF-Diebstahl in der Flash-Welt ein großes Problem darstellt, gibt es andere Möglichkeiten, SWFs zu schützen. Es gibt zahlreiche Programme, um AS auf Bytecode-Ebene zu verschleiern (wie Kindisofts SecureSWF). Sie bringen den kompilierten Bytecode durcheinander und wenn der Dekompiler versucht, Code auszugeben, schlägt er fehl und stürzt manchmal sogar ab. Natürlich ist dieser Schutz in Bezug auf die Sicherheit besser, aber er kostet $$$. Bevor Sie also entscheiden, wie Sie Ihre SWF schützen möchten, sollten Sie die erforderliche Sicherheitsmenge berücksichtigen. Wenn es darum geht, einen proprietären Algorithmus zu schützen, den Ihr Flash-Studio mit 50 Mitarbeitern in den letzten zwei Jahren entwickelt hat, sollten Sie etwas Besseres in Betracht ziehen, als die Variablen umzubenennen. Wenn Sie jedoch verhindern möchten, dass die Kinder falsche Highscores einreichen, können Sie diese Technik in Betracht ziehen.

Was mir an dieser Technik gefällt, ist die Tatsache, dass Ihre geschützte SWF beim Ausführen unberührt bleibt. AS-Verschleierung manipuliert den Byte-Code und kann möglicherweise die SWF beschädigen und Fehler verursachen (obwohl ich selbst keine gefunden habe).

Das ist alles für heute, ich hoffe, Sie haben das Tutorial genossen und etwas Neues gelernt! Wenn Sie Fragen haben, können Sie gerne einen Kommentar abgeben.

Advertisement
Did you find this post useful?
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.