Microsoft veröffentlichte im November 2010 ein Windows Phone Marketplace Anti-Piracy Model white paper. Dieses beschreibt, welche Methoden letztlich angewendet wurden und werden, um gegen Piraterie unter WP7 gewappnet zu sein. Liest man jedoch genauer zwischen den Zeilen, so bleibt letztlich übrig, dass alle Maßnahmen ergriffen wurden, die ebenfalls auch kosteneffizient sind. Dies heißt jedoch im Umkehrschluss, dass Sicherheit nur bis zu einem gewissen Level gegeben ist und Schlupflöcher anscheinend existieren können. Was kann man also selbst dagegen tun, um seine Anwendung dagegen zu schützen?

Hintergründe

Ohne in die technischen Details eintauchen zu wollen und die “Piraterie” hier zu unterstützen, wird einfach die theoretische Basis geschaffen, auf die im Nachgang aufgesetzt wird.

Angenommen es gäbe die Möglichkeit die zertifizierten Installationsdateien aus dem Marketplace zu erhalten, ohne diese ggfs. kaufen zu müssen. Zwar wird bei der Installation auch noch die Signatur geprüft, jedoch auch hier angenommen diese würde überwunden. Theoretisch könnte man dann Anwendungen kopieren und kostenfrei installieren.

Dies an sich ist schon schlimm. Schlimmer ist jedoch, dass man den Sourcecode der eigenen Anwendung fast frei Haus liefert.

Nehmen wir zur Demonstration dieses super tolle “Hello World” Sample. Die Anwendungsoberfläche ist sehr ansprechend:

HelloWorld1  HelloWorld2

Der zugehörige Sourceode ist auch super schlank gehalten:

HelloWorldSource

Wie jede andere Anwendung für WP7 auch besitzt diese eine Anwendungsinstallation in Form einer XAP-Datei. Diese selbst ist nichts anderes als ein ZIP-Archiv, welches alle zugehörigen Dateien, wie auch die auszuführende Assembly beinhaltet.

Im Debug-Ordner des Projekts finden sich folglich diese Dateien:

Debug-Folderpng

Angenommen man hätte böse Absichten und wolle schauen, wie die Anwendung funktioniert, da einen beispielsweise die Authentifizierungsmechanismen oder andere Funktionen einer Anwendung interessieren, die vielleicht nicht unbedingt der Öffentlichkeit zugänglich gemacht werden sollen, um seine eigenen Systeme nicht zu kompromittieren.

Jede Assembly lässt sich, sofern diese nicht geschützt ist, mit dem .NET Reflector genauer inspizieren. So sieht unsere Assembly der Superanwendung im Reflector aus.

Plain

Wäre hier jedoch nicht nur unser “Hello World” sondern wirklich wichtiger und schützenswerter Quellcode enthalten, hätte man diese Informationen in kürzester Zeit auf dem Bildschirm stehen, was höchstwahrscheinlich nicht gewünscht ist.

(Zu den Hintergründen, wieso dies mit Assemblies möglich ist, empfiehlt sich dieser Artikel)

Obfuskation

Wie kann man dem jedoch entgegnen oder verhindern?

Ganz verhindern lässt sich dies nicht. Man kann lediglich den Aufwand hierfür in die Höhe treiben. Den kann man so weit in die Höhe treiben, dass der Aufwand zum “dekodieren” diese Information so hoch ist, das es sich nicht mehr lohnt. Möglich ist es aber immer noch.

Hierfür wird die so genannte “Obfuskation”, oder auch “Verschleierung” angewendet. Dabei werden Methodennamen unkenntlich gemacht und Zeichenfolgen quasi verschlüsselt. Der gleiche Quellcode sieht obfuskiert, wie folgt aus:

Obfuscated

Man sieht dabei, dass der Methodenname verschleiert wurde und auch die Zeichenfolge, wie auch der Methodenaufruf sind so nicht mehr erkennbar.

(Mehr zu den Hintergründen einer Obfuskation gibt es hier)

Um eine Obfuskation der eigenen Anwendung zu erreichen benötigt man ein Programm. Aktuell bietet sich der Dotfuscator von PreEmptive Solutions an, da dieser noch bis zum 31.03.2011 kostenlos genutzt werden kann. Wem der Name bekannt vorkommt: Eine Community Edition war Bestandteil der Visual Studio Installation bis zur Version 2008.

Dotfuscator

Mit dem Dotfuscator lässt sich die eigene Assembly verschleiern und der Aufwand zum “Dekodieren” erhöhen.

Es gibt jedoch noch ein paar Punkte zu beachten, bevor man sich in Sicherheit wiegt:

  • Eine verschleierte Assembly benötigt ein wenig mehr Performance als eine nicht verschleierte.
  • Wichtige Zeichenfolgen und Funktionen sollten nach Möglichkeit dennoch auf einen Server verlagert werden. Selbst wenn der Aufwand hoch sein sollte eine Assembly zu “dekodieren”, so ist es sicherer garnicht erst diese Angriffsfläche zu bieten.

Update:

Rene Schulte weißt darauf hin, dass der Dotfuscator nicht richtig weiterhilft, wenn Datenbindung genutzt wird, da hier die Bindung durch das Umbenennen verloren geht. Dies sollte man, wenn man den Einsatz von Dotfuscator erwägt auch berücksichtigen.