Obfuskation
Eintrag zuletzt aktualisiert am: 18.05.2023
Gegenspieler der
Decompiler/Disassembler sind Obfuskatoren (engl. Obfuscator). Ein Obfuskator kann durch Obfuskation die Dekompilierung nicht verhindern, aber erschweren.
Typische Strategien der Obfuskation
Typische Strategien der Obfuskation sind:
- Ersetzung der (sprechenden) Bezeichner durch kryptische Namen
- Zusätzliche Algorithmen (komplexerer Programmfluss)
- Verschlüsselung von Zeichenketten
- Verschlüsselung des Programmcodes
Grenzen der Obfuskation
Alles, was im Rahmen der Obfuskation verschlüsselt wurde, muss vor der Ausführung entschlüsselt werden, sodass ein Angreifer das Programm nur zur Ausführung bringen muss; dann kann der Angreifer alles lesen. Die Obfuskation von
Variablen und Algorithmen erschwert seine Arbeit, macht sie aber nicht unmöglich.
An die Grenzen stoßen Obfuskatoren auch, wenn die Anwendung den .NET-
Reflection-Mechanismus nutzt, um dynamische Aufrufe zu realisieren. Wenn die Namen von Typen statisch in
Reflection-Aufrufen hinterlegt sind, fällt die Anwendung nach der Obfuskation beim Einsatz von
Reflection auf die Nase. Hier ist also keine 100%ige Code-Äquivalenz gegeben.
Obfuskatoren für .NET
Alternativen zur Obfuskation
Eine alternative Strategie ist, sensible Algorithmen und intellektuelles Eigentum nicht durch Obfuskation, sondern durch Verlagerung auf den Server/in die Cloud vor der Dekompilierung zu schützen. Der Client, den Sie an die Kunden ausliefern, sollte keinen Code enthalten, von dem Sie nicht wollen, dass der Kunde ihn lesen kann. Solcher Code sollte nur auf Servern/Cloud-Diensten laufen, die nur Sie kontrollieren. Beispiel: Bei
Blazor Server läuft der Code nur auf dem Server/in der Cloud. Bei den anderen Blazor-Arten müssen Sie den zu schützenden Code in
Webservices verlagern.