Laden...

Schutz vor Deobfuscation

Letzter Beitrag vor 11 Jahren 5 Posts 4.272 Views
Information von herbivore vor 11 Jahren

Dies ist ein Thread, auf den aus der FAQ verwiesen wird. Bitte keine weitere Diskussion, sondern nur wichtige Ergänzungen und diese bitte knapp und präzise. Vielen Dank!

Schutz vor Deobfuscation

Hallo,

Es gibt schon unzählige Threads zum Thema obfuscation, wie sinnvoll es ist und welcher wohl der beste Obfuscator ist.. Aber hier mal was anderes:

Gibt es eine Möglichkeit Programme aufzuhalten, die sich ums Gegenteil kümmern?

Ich habe vor ein Paar Tagen den Confuser kennengelernt, der an sich ein sehr guter Obfuscator zu sein scheint. Heute musste ich leider feststellen, dass es da ja z.b. NETDeob gibt, wodurch das ja alles noch weniger Sinn hat.

Mir war klar, dass obfuscation kein wirklicher Schutz ist. Aber dass 1 Klick reicht ist ja wirklich nicht mehr lustig..

Kennt jenand eine Möglichkeit so einer automatisierten Umkehrung vorzubeugen?

Ich weiß nicht, wie oft man dieses Thema noch durchkauen muss: Nein, nein und wieder nein. Es gibt keine Möglichkeit (Stand heute). 🙂
Einfach mal mit .NET beschäftigen, wie das Framework funktioniert und man versteht auch wieso.

Update 06.01.2015: mittlerweile gibt es .NET native, mit dem dies möglich ist.

Hallo theYoRecords, hallo zusammen,

ich stimme Abt zu, dass wir das Thema "obfuscation, wie sinnvoll es ist und welcher wohl der beste Obfuscator ist" nicht noch mal durchkauen sollten und bitte alle darum, sich daran zu halten.

Das Thema Deobfuscation ist aus meiner Sicht allerdings noch recht neu und wurde auf myCSharp.de bisher wohl nur in WinRT Codesicherheit: Kann der "Quellcode" wie bei .NET angesehen werden? Welche Obfuscatoren gibts? und auch dort nur am Rande behandelt.

Praktisch kenne ich mich damit leider nicht aus und weiß nicht, wie gut Deobfuscatoren tatsächlich arbeiten. Aber Grundsätzlich ist klar, dass auch der beste Obfuscatior am Ende nur CIL-Code erzeugen kann und daher eine Umkehrung in einem gewissen Maße immer möglich sein wird. Die Frage ist, wie gut menschenlesbar das Ergebnis ist. Die meisten Obsfucatoren werden möglichst viel Information, die ein Mensch zum Verständnis des Codes benötigt, also z.B. Variablennamen, möglichst rückstandsfrei entfernen. Und was weg ist, ist weg. Aus meiner Sicht kann ein Deobfuscator nur weniger kryptische Namen verwenden, aber nicht die Originalnamen wieder herstellen.

Manche Namen können allerdings nicht entfernt werden, ohne die Schnittstelle einer Assembly nach außen zu verändern. Diese Namen muss ein Deobfuscator gar nicht wiederherstellen, sondern die waren ja nie weg.

herbivore

Und was weg ist, ist weg. Aus meiner Sicht kann ein Deobfuscator nur weniger kryptische Namen verwenden, aber nicht die Originalnamen wieder herstellen.

Manche Obfs verwenden leider keine numerischen Variablen, sondern haben einen Algorithmus, wie sie Variablen nennen.
Und mittlerweile ist in vielen Fällen bekannt, wie die Namen zusammen gesetzt werden und daher können einige Deobfs diese auch zurück wandeln.

Ich hole den Thread mal wieder raus, weil ich kürzlich eine tolle Alternative zur Obfuscation gefunden habe: http://www.infralution.com/netencryptor.html

Das Produkt wurde hier Erfahrungen mit dem Infralution NetEncryptor (Obfuscator) auch schonmal angesprochen. Ich habe mir es kürzlich gekauft und konnte bisher keinerlei Probleme feststellen.

Damit werden .NET Reflector, ILSpy und Konsorten nutzlos 😃

Hinweis von herbivore vor 11 Jahren

Kurze Erklärung: Im Unterschied zur normalen Obfuscation, bei dem die originale Assembly umgebaut wird, indem z.B. sprechende Namen durch kryptische ersetzt werden, aber die Assembly direkt ausführbar bleibt, wird sie beim .NET Encryptor verschlüsselt als Ressource in einer Bootstrapper EXE hinzugefügt, die die Assembly erst zur Laufzeit wieder entschlüsselt.