Deobfuskierungsresistenz

Weil die umgeschriebenen Aufrufstellen ihre Ziele nicht mehr direkt referenzieren und die Codierung von Build zu Build variiert, können automatisierte Deobfuskierungstools den ursprünglichen Aufrufgraphen nicht durch statische Analyse wiederherstellen. Dynamic Proxy von Babel wird regelmäßig gegen führende Open-Source-Deobfuskierungstools für .NET geprüft: Deren Resolver für Proxy-Aufrufe stellen keinen der über Proxys geleiteten Aufrufe wieder her, und die bereinigte Ausgabe rekonstruiert die ursprünglichen direkten Aufrufe nicht.

Die Kombination von Dynamic Proxy mit der Umbenennung von Symbolen, der Kontrollflussverschleierung und der Manipulationserkennung erhöht den Aufwand für das Reverse Engineering einer geschützten Assembly weiter.

Bewährte Vorgehensweisen

• Schützen Sie, was zählt. Richten Sie den Schutz mit Filtern auf den sensiblen Aufruffluss (Lizenzierung, Sicherheitsprüfungen, proprietäre Algorithmen), statt jeden Aufruf über einen Proxy zu leiten. So erreichen Sie den größten Schutz bei der geringsten Auswirkung auf Größe und Startzeit.
• Wählen Sie den richtigen Modus. external ist eine leichtgewichtige Option, die vor allem verhindert, dass Decompiler Variablennamen wiederherstellen und Typen ableiten. all bietet die stärkste Verschleierung des Aufrufflusses für die interne Logik (siehe Interne und externe Aufrufe).
• Kombinieren Sie Funktionen. Dynamic Proxy wirkt am besten zusammen mit Umbenennung, Kontrollflussverschleierung und Manipulationserkennung.
• Schalten Sie die Funktion auf AOT-Zielen aus. Setzen Sie DynamicProxy=false für Assemblys von .NET MAUI und Blazor (siehe Einschränkungen bei AOT und Plattformkompatibilität).
• Prüfen Sie nach dem Build. Führen Sie Ihre Testsuite gegen die verschleierte Assembly aus, wie Sie es bei jeder Schutzeinstellung tun würden.

Mit dem Schutz durch dynamische Proxys in Babel Obfuscator erhöhen Sie die Sicherheit Ihrer Anwendung deutlich, weil Methodenaufrufe verborgen werden und das Reverse Engineering erschwert wird.