Skip to Content
Neue Version 12 verfügbar 🎉
ObfuscatorDynamic Proxy

Dynamic Proxy

Der Schutz durch Dynamic Proxy ist eine leistungsfähige Funktion von Babel Obfuscator, die die Verschleierung und den Schutz des Codes Ihrer Anwendung verstärkt. Mit ihr verbergen Sie Methodenaufrufe in externen wie in internen Code, indem dynamische Proxy-Klassen erzeugt werden.

Wenn der Schutz durch dynamische Proxys eingeschaltet ist, erzeugt Babel Obfuscator Delegattypen oder Proxy-Klassen, die als Vermittler für Methodenaufrufe dienen. Diese Proxy-Klassen werden während der Verschleierung dynamisch erstellt und ersetzen die ursprünglichen Methodenaufrufe in Ihrem Code.

Der wichtigste Vorteil dynamischer Proxys ist, dass sie die tatsächlichen Methodenaufrufe wirksam verbergen. Angreifern und allen, die Reverse Engineering betreiben, fällt es dadurch deutlich schwerer, den Ablauf des Codes zu verstehen und zu analysieren. Mit dynamischen Proxys verhindern Sie den direkten Zugriff auf sensible Methoden und verbergen die Anwendungslogik.

Dieser Abschnitt behandelt:

Funktionsweise von Dynamic Proxy

Beim Build erzeugt Babel Obfuscator für jeden geschützten Aufruf einen kleinen Proxy-Delegattyp und schreibt die ursprüngliche Anweisung call, callvirt oder newobj so um, dass sie über diesen Proxy geleitet wird. Das eigentliche Ziel, also der deklarierende Typ, die Methode und das Feld, das den aufgelösten Aufruf aufnimmt, wird vom umgeschriebenen Code nicht mehr direkt referenziert. Stattdessen ermittelt es ein winziger eingefügter Resolver, wenn ein über einen Proxy geleiteter Aufruf zum ersten Mal ausgeführt wird. Danach wird es zwischengespeichert, sodass spätere Aufrufe direkt durchlaufen.

Aus diesem Aufbau folgen zwei Eigenschaften:

  • Die statische Analyse wird gestört. Die umgeschriebenen Aufrufstellen tragen keine direkte Metadatenreferenz auf das Ziel mehr, sodass Decompiler und automatisierte Deobfuskatoren den ursprünglichen Aufrufgraphen nicht allein aus den Metadaten rekonstruieren können. Auch die Codierung der Ziele variiert von Build zu Build, sodass sich Tools nicht auf feste Muster verlassen können, siehe Deobfuskierungsresistenz.
  • Die Auflösung erfolgt verzögert und wird zwischengespeichert. Der erste Aufruf eines über einen Proxy geleiteten Members trägt einmalig geringe Kosten, um das Ziel aufzulösen und den Delegaten zu verbinden. Jeder spätere Aufruf läuft mit vernachlässigbarem Mehraufwand über den zwischengespeicherten Delegaten, siehe Leistung.

Die Umleitung über Proxys ist eine rein verwaltete Transformation, die beim Build stattfindet: Sie setzt das .NET Framework nicht voraus, funktioniert unter .NET und .NET Framework und ändert das beobachtbare Verhalten Ihres Programms nicht (mit Ausnahme der wenigen unter Abdeckung aufgeführten Aufrufe, die absichtlich direkt bleiben).

Einschränkungen bei AOT und Plattformkompatibilität

Dynamic Proxy wird für Assemblys von .NET MAUI und Blazor derzeit nicht unterstützt. Grund ist eine Kombination aus Einschränkungen der Plattformen und der Laufzeit, die eine sichere oder konsistente Erzeugung und Ausführung von Proxys in diesen Umgebungen verhindern.

Plattformbedingte Einschränkungen

  • AOT-Kompilierung (Ahead-of-Time): Plattformen wie iOS (von .NET MAUI verwendet) und WebAssembly (von Blazor WebAssembly verwendet) erzwingen die AOT-Kompilierung. Damit entfallen Laufzeitfunktionen wie die Codeausgabe über Reflexion oder die Erzeugung von Typen zur Laufzeit. DynamicProxy von Babel verwendet zwar keine Codegenerierung zur Laufzeit, die erzeugte Proxy-Logik kann aber von Metadaten und IL-Konstrukten abhängen, die in AOT-kompilierten Umgebungen entfernt oder nicht unterstützt werden.

Einschränkungen der IL-Kompatibilität

  • Nicht unterstützte Metadatentoken: Der Mechanismus der dynamischen Proxys fügt über erzeugte Proxy-Typen und Delegat-Stubs zwischengeschaltete Aufrufebenen ein. Diese stützen sich auf Metadatentoken und Indirektionsmechanismen, die auf bestimmten AOT-Zielen möglicherweise nicht verifizierbar sind oder gar nicht unterstützt werden. Das führt zu Validierungsfehlern zur Laufzeit oder zu Abstürzen der Anwendung.

Einschränkungen bei Blazor/WebAssembly

  • Eingeschränkte Reflexion: In Blazor WebAssembly ist die Reflexion stark eingeschränkt. Da DynamicProxy Methodenaufrufe häufig umhüllt oder abfängt, können indirekte Aufrufpfade entstehen, die mit dem Linking und dem Tree Shaking bei der Veröffentlichung für WebAssembly nicht vereinbar sind.

Empfehlung

Für die volle Kompatibilität mit AOT-Umgebungen wie .NET MAUI und Blazor empfiehlt es sich, DynamicProxy=false zu setzen. So bleiben die erzeugten Assemblys vollständig verifizierbar, plattformkonform und frei von Funktionen, die beim nativen Linking oder beim Start der Laufzeit versagen können.

Last updated on