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.