Smartassembly

Ein Programm zur Optimierung von Assemblys für den .NET Entwickler, was viel verspricht und es auch hält.

Persönlicher Erfahrungsbericht von Tim Hartwig

In diesem Erfahrungsbericht werde ich alle Schritte und Optionen in dem Programm beschreiben und meine eigene Meinung dazu schreiben.

Ich beginne bei der Programmoberfläche, welche mich sehr überzeugt hat. Keine überfüllten Menüs oder Navigationen von denen man die meisten Funktionen selten benutzt. Es wird nur das nötigste angezeigt, was einen optimalen Überblick gewährt.

Zu Beginn, wenn auf Home Page geklickt wird, kann ein neues Projekt erstellt werden oder ein vorhandenes Projekt geöffnet werden.

Sobald man dann auf New Project geklickt hat kommt man dann zu einem Dialog wo man die Assembly auswählen muss welche optimiert werden soll. Hier bekommt man auch direkt einen Überblick was alles optimiert werden kann.
• Windows Forms Applikationen
• Konsolen Applikationen
• ASP.NET Web Anwendungen
• .NET WebService
• und DLLs
Das Programm kann also mit allen .NET Assemblys umgehen.

Zum testen habe ich ein einfaches kleines „Hallo Welt“ Programm geschrieben. Dieses enthält lesbare Strings (Hardcodiert) und einem provoziertem Fehler welcher unbehandelt ist. Dazu komme ich später.

Nachdem ich nun meine Assembly ausgewählt habe, geht es direkt weiter mit:

Schritt 1 – Pfad auswählen
Hier muss man einen Ordner auswählen wo später die neue, optimierte Assembly gespeichert werden soll. Das war es auch schon mit Schritt 1.

Schritt 2 – Zusammenführen von DLLs
Hier geht es dann auch direkt los mit dem ersten sehr nützlichen Feature und zwar kann man hier alle DLLs die das Programm braucht und somit  immer mitgeschleppt werden müssen, direkt in die Assembly einbauen lassen. Man nennt so was auch „Merging“
Der Vorteil liegt auf der Hand. Man hat immer nur eine Datei und zwar das Programm selber. Da .NET DLLs nicht im System registriert werden müssen ist das auch kein Problem. Außer man will seine DLL im GlobalAssemblyCache registrieren. Ich persönlich mache das aber nicht.
Natürlich erkennt {smartassembly} diese eingebundenen DLLs selber so dass man diese nur noch auswählen muss. Also müssen nicht zwingend alle DLLs mit dem Hauptprogramm vereint werden.

Schritt 3 -  Ungenutzten Code entfernen
Wieder ein Feature was ich für sehr Nützlich halte. Wie oft kommt es vor, dass man bei größeren Projekten Funktionen oder Klassen eingebaut hat und diese doch nicht benutzt. Wenn man z.B. für Testzwecke eine Funktion geschrieben hat diese aber nicht im Final Release benutzt und man vergessen hat diese zu entfernen oder auszukommentieren. Gar kein Problem. {smartassembly} scannt den Code und prüft ob bestimmten Funktionen oder Klassen jemals aufgerufen werden oder nicht. Diese ungenutzten „Code-Leichen“ werden dann einfach entfernt um hier und da vielleicht ein paar hundert Kilobytes einzusparen. Ich habe das mal an meinem Backup Manager angewendet und war erstaunt dass die Assembly von 580 KB auf 474 KB geschrumpft ist. Dabei ist da eigentlich so gut wie keine Funktion ungenutzt. Also ein sehr effizientes Feature.

Schritt 4 – Obfuscation (Renaming)
Das ist mein Favorit unter allen Features von {smartassembly}.
Meiner Meinung nach, die beste Codeverschleierung auf dem Markt.
Selbstverständlich kann man auch hier auswählen welche Bereiche man auslassen möchte und nicht verschleiert werden sollen. Dann hat man für die Verschleierung 3 Sicherheitsstufen (siehe Screenshot).

In diesem Schritt der Verschleierung geht es um die Umbenennung von Namen und Feldern im nächsten Schritt wird der Code selber durcheinander gebracht was aber keine Auswirkung zur Laufzeit hat.

Schritt 5 – Spaghetti Code
Wie vorhin angekündigt folgt nun der Schritt in dem der Code in der Assembly durcheinander gebracht wird. Wie genau das funktioniert weiß ich leider nicht aber ich habe mir das Ergebnis mal angeschaut und zwar mit Lutz Roeder’s .NET Reflector. Dort wo eigentlich der Code stehen sollte stand nur noch „This item is obfuscated and can not be translated“. Das fand ich ja mal schon sehr gut und hat mich wirklich überzeugt. Wenn man bedenkt das es in den nächsten zwei Schritten noch mal auf anderen weise verschleiert, wird zusätzlich zu dem letzten Schritt und diesem.



Schritt 6 – String Verschlüsselung
In diesem Schritt geht es direkt weiter mit der nächsten Stufe der Codeverschleierung. Diesmal geht es den Hardcodierten Strings an den Kragen. Man kann die Strings entweder „Normal“ verschleiern oder man bindet die verschleierten Strings zusätzlich noch an eine Assembly ID was dazu führt das jede Veränderung an dieses Strings zum Absturz des Programms führen würden. Also ein sehr effektiver Schutz.

Schritt 7 – Decompiler Verwirrung
Das ist der letzte von insgesamt vier Obfuscating Schritten. Hier geht es dem Decompiler an den Kragen. Hier gibt es zwei Optionen. Die erste Option ermöglicht es einem falsche Meta-Daten zur Assembly hinzuzufügen was den angreifenden Decompiler verwirren soll und die zweite Option stellt die Assembly so um, dass der Microsoft IL Dissassembler die Assembly nicht mehr öffnen kann. Was auch tatsächlich funktioniert. Der MSIL DASM von Visual Studio hat direkt beim öffnen der Assembly eine Fehlermeldung ausgegeben:
 „Geschütztes Modul, kann nicht aufgelöst werden“

Schritt 8 – Unbehandelte Fehler
Ein weiteres Feature was mich vollkommen überzeugt hat. Hier hat man die Möglichkeit einen alternativen Fehlerdialog für unbehandelte Fehler einzubauen anstelle des Standard Dialogs (siehe Bild)

Der alternative Dialog sieht dagegen so aus:

Jetzt kommt der Höhepunkt. Man hat die Möglichkeit einen kostenpflichtigen Account einzurichten (Es gibt auch einen Testaccount) um diesen Fehlerbericht an dem Webserver von {smartassembly} zu senden so das man diesen dann über seinen Account auf alle eingegangenen Fehlerberichte zugreifen und auswerten kann.
Dieser Dialog erinnert stark an den Dialog von Windows XP der auftritt wenn dort ein Programm abgestürzt ist. Das ist dasselbe Prinzip und für den Eigenbedarf sehr praktisch. Wenn man die Enterprise Edition besitzt kann man sogar einen eigenen WebServer einrichten statt den von {smartassembly zu benutzen}.

Aber das war noch nicht alles. Wenn man auf den Button „Debug“ klickt erscheint folgendes Fenster:

Hier können alle relevanten Informationen bezüglich der Fehlermeldung eingesehen werden. Zusätzlich bekommt man noch eine Info über das Betriebssystem auf welches die Anwendung lief als der Fehler auftrat. Sowie viele weitere Informationen die ich aber in der Demo-Version nicht einsehen kann. Aber ich denke mal das man alles Wissenswerte über diese Exception aufgelistet bekommt.

Natürlich habe ich den Testaccount von {smartassembly} getestet.
Wenn im Programm nun ein unbehandelter Fehler auftritt dann kann man auf Fehlerbericht senden klicken und es erscheint dieser Dialog wo man beobachten kann wie der Bericht gesendet wird:

Der Zugriff auf deren WebServer erfolgt vom Programm aus. Man klickt in der Navigation auf „Download new reports“ und es werden alle Berichte vom Server heruntergeladen und anschließend vom Server gelöscht so dass diese nur noch Lokal verfügbar sind. Das sieht dann so aus:

Schritt 9 – Alternative zu Schritt 2 (Zusammenführen von DLLs)
Wenn man Schritt 2 nicht aktiviert hat, kann man hier eine erweiterte Möglichkeit seine DLLs in das Programm einzubinden. In Schritt 2 werden die DLLs nahtlos mit eingebunden, quasi mit der Assembly „fusioniert“. Hier werden die DLLs als eigene Datei mit eingebunden und zusätzlich komprimiert, man kann sich das wie bei einer Archiv Datei vorstellen (RAR, ZIP). In einer Archivdatei befinden sich dann z.B. 2 Dateien. Einmal die Assembly selber und dann eine DLL die von der Assembly benötigt wird. Wird das Programm gestartet wird dann diese DLL im Arbeitspeicher entpackt und eingebunden. Was auch noch möglich ist. Hier kann man die DLL auch noch im GAC (GlobalAssemblyCache) registrieren was bei Schritt 2 nicht möglich ist.

Schritt 10 – Weitere Optimierungen
In diesem Schritt gibt es zwei weitere Optimierungsmöglichkeiten.
Die erste Option löst ein leidiges Problem von .NET Framework Anwendungen und zwar das Fehlende Speichermanagement. .NET Framework Anwendungen sind selber nicht in der Lage ungenutzten Arbeitspeicher freizugeben. Das kann man leicht testen in dem man eine Schleife programmiert in der 100 große Bilder geöffnet werden. Sehr schnell wird der Arbeitspeicher randvoll und irgendwann kommt eine Fehlermeldung vom Programm das nicht genügend Arbeitspeicher zur Verfügung steht. Ich habe es selber schon erlebt. Allerdings kann man das Problem lösen indem man einfach den folgenden Code anwendet:

Hierfür brauch man die API-Deklaration für die Funktion
SetProcessWorkingSetSize
Diese Funktion stammt aus der kernel32.dll

Der folgende Aufruf räumt den Arbeitsspeicher frei:
SetProcessWorkingSetSize(Process.GetCurrentProcess().Handle, -1, -1)

Mit {smartassembly} kann dieses Feature allerdings automatisiert eingebaut werden so das es nicht nötig ist diese API bzw. Funktion im Code selber an entsprechenden stellen einzubauen.

Die zweite Option ist dann doch etwas interessanter. Hier geht es um ClassSealing. Ich selber habe davon leider keine Ahnung aber laut Beschreibung werden alle nicht abgeleiteten Klassen die dann wohl auch nicht benutzt werden sozusagen „versiegelt“ was der Performance der Anwendung zu gute kommen soll. Wer genau weiß was ClassSealing ist der wird mehr damit anfangen können und auch besser bewerten können ob das auch was bringt.

Schritt 11 – Debugging Informationen hinzufügen
Hier wird eine PDB Datei generiert um bei unbehandelten Fehlern eine ausführlichere Fehlermeldung zu bekommen. So eine PDB Datei wird auch beim kompilieren des Visual Studio Projekts erstellt. Aber {smartassembly} bietet auch hier eine weitere praktische Option mit allerdings einem Haken. Man kann die Dokumentenpfade der Quellcodedateien die bei der Fehlermeldung normalerweise im Klartext mit ausgegeben werden verschlüsseln und mit {smartassembly} wieder entschlüsseln. Der Haken hierbei ist aber, dass man dafür bei Schritt 4 nur die Sicherheitsstufe 1 auswählen darf damit diese Option auch funktioniert. Das dürfte aber bei den weiteren Möglichkeiten den Code zu verschleiern kein Problem sein.

Schritt 12 – Strong Name Key
Das ist der letzte Schritt und mit dem kann ich leider nichts anfangen. Man kann seine Assembly mit einem „Strong Name Key“ signieren. Ich habe mich damit nie beschäftigt und kann daher auch nicht viel dazu sagen.

Fazit
Das Programm hat mich vollkommen überzeugt. Wenn ich mich entscheiden müsste zwischen diesem Programm und anderen ähnlichen Programmen mit Obfuscator und Optimierungsmöglichkeiten würde ich mich auf jeden Fall für {smartassembly} entscheiden.
Sehr durchdachter Programmaufbau, modernes Design und effektive Optimierungs- und Verschleierungsoptionen sprechen für dieses Programm.

Der Preis ist auch verhältnismäßig gut, wenn dieses Programm mit anderen Obfuscatoren verglichen wird,  die nur zur Verschleierung gedacht sind und trotzdem viel mehr kosten.
Ich möchte an dieser Stelle keine anderen Programme auflisten aber wer das eine oder andere Programm und deren Preise dieser Kategorie kennt, der wird mir sicher zustimmen.

Was ich vermisste, ist eine Hilfe zu dem Programm was sich dann mit der relativ kurzen aber ausreichenden Online-Dokumentation erübrigt.
Dort wird fast jeder Schritt anhand von Beispielen kurz erläutert.