Man sieht bei Software immer wieder was passiert wenn man vor dem Release das Testen vergisst. Lustig fand ich nun aber, dass auch Malwareautoren ab und an nicht daran denken. wie der Eintrag auf simple-talk beweist. Dort wurde vergessen, dass Assemblies, welche mit einer Evaluationsversion von {smartassembly} erstellt wurden, nach einer Zeit nicht mehr Funktionieren.

Die Malware welche sich als die Systemanwendung “svchost” tarnt installiert sich irgendwo auf dem Computer bis sie sich auf unfreiwillige Art und Weise nach einer Weile mit folgender Meldung selbst eliminiert:

“svchost' has been built with an evaluation version of {smartassembly}, which has expired on Wednesday, 20 January 2010. You need to purchase a license of {smartassembly}.

In diesem Falle ist das aber ganz positiv für den Benutzer, er bekommt so eine Info darüber das sein Rechner verseucht ist, und kann dann entsprechende Gegenschritte einleiten. Wie das am besten geht ist im oben verlinkten Blogeintrag beschrieben. Natürlich sollte man vermeiden sich sowas erst einzufangen, weshalb es immer Ratsam ist eine gängige und aktuelle Antivirenlösung installiert zu haben.

Heute habe ich wieder ein bisschen an meinem smsClient.NET gearbeitet und herausgekommen ist ein Update auf die Version 1.2 mit folgenden Neuerungen:

Ich habe auch meinen {smartassembly} Exceptiondienst ausgelagert. Vorher hatte ich den extra nur fürs updateSystem.NET geschrieben aber von nun an kann ich auch allen anderen Anwendungen welche ich mit {smartassembly} verschleiere den eigenen Exceptionhandler unterjubeln und so die Reports an meinen Server schicken lassen.

Wer selber auf {smartassembly} setzt und dessen Lizenz für die gehosteten Reports abgelaufen ist kann sich ja mal melden. Voraussetzung ist allerdings ein Windowsserver :-)

Ok, vermutlich wird das jetzt die wenigsten Interessieren, aber ich habe gestern festgestellt, dass die Firma Red Gate meinen Lieblings Obfuscator {smartassembly} übernommen hat. An sich nichts besonderes, aber lustiger weise hat die gleiche Firma vor etwas mehr als einem Jahr den .NET Reflector von Lutz Roeder übernommen hat. Also quasi die Anwendung gegen die man sich in Erster Linie mit solchen Verschleierungswerkzeugen, wie {smartassembly} eine ist, schützt.

Auf den ersten Blick etwas ironisch aber auf den zweiten relativ Schlau, denn wenn man den Decompiler kontrolliert kann man recht einfach dafür sorgen, dass Assemblies welche mit {smartassembly} geschützt wurden gar nicht mehr im Reflector analysiert werden können, unabhängig davon welche Sicherungsmethode verwendet wurde. Es würde quasi ein einfaches Abfragen des “Powered by {smartassembly}”-Attributes reichen um zu erkennen “STOP! Der Entwickler will dat nich!”. Was natürlich nicht heißt das man den Schutz vernachlässigen sollte, denn der .NET Reflector ist ja nicht das einzige Analysetool für .NET Assemblies. Es gibt z.B. noch den Xenocode Fox Code Analyserwelcher im übrigen genau das macht. Will man damit ein Assembly laden welches mit dem Hauseigenen Obfuscator “PostBuild” verschleiert wurde, verweigert das Tool die Arbeit. Ob das Red Gate jetzt genauso macht ist natürlich rein spekulativ aber ein logischer Schritt wäre es zumindest.