Skip to Content
Nuova versione 12 disponibile 🎉
ObfuscatorProxy dinamico

Proxy dinamico

La protezione con proxy dinamico è una potente funzionalità di Babel Obfuscator che rafforza l’offuscamento e la protezione del codice della tua applicazione. Ti permette di nascondere le chiamate ai metodi, verso codice sia esterno sia interno, generando classi proxy dinamiche.

Quando la protezione con proxy dinamico è abilitata, Babel Obfuscator crea tipi delegate o classi proxy che fanno da intermediari per le chiamate ai metodi. Queste classi proxy vengono costruite dinamicamente durante il processo di offuscamento e sostituiscono le chiamate ai metodi originali nel tuo codice.

Il vantaggio principale dei proxy dinamici è che nascondono efficacemente le chiamate effettive ai metodi, rendendo molto più difficile per un attaccante o per chi fa reverse engineering capire e analizzare il flusso del codice. Con i proxy dinamici puoi impedire l’accesso diretto ai metodi sensibili e nascondere la logica dell’applicazione.

Questa sezione tratta:

Come funziona il proxy dinamico

In fase di build, per ogni chiamata protetta Babel Obfuscator genera un piccolo tipo delegate proxy e riscrive l’istruzione call, callvirt o newobj originale in modo che passi attraverso quel proxy. La destinazione reale (il tipo che la dichiara, il metodo e il campo che conterrà la chiamata risolta) non è più referenziata direttamente dal codice riscritto. Viene invece ricavata da un piccolo resolver iniettato nell’assembly la prima volta che ogni chiamata tramite proxy viene eseguita, e poi memorizzata nella cache, così le chiamate successive passano direttamente.

Da questa struttura derivano due proprietà:

  • L’analisi statica viene ostacolata. I punti di chiamata riscritti non contengono più un riferimento diretto nei metadati alla destinazione, quindi i decompilatori e i deoffuscatori automatici non possono ricostruire il grafo delle chiamate originale dai soli metadati. Anche il modo in cui le destinazioni sono codificate varia da una build all’altra, quindi gli strumenti non possono basarsi su schemi fissi: vedi Resistenza al deoffuscamento.
  • La risoluzione è differita (lazy) e memorizzata nella cache. La prima chiamata a un dato membro tramite proxy paga un piccolo costo una tantum per risolvere la destinazione e collegare il delegate; ogni chiamata successiva passa dal delegate nella cache con un overhead trascurabile: vedi Prestazioni.

L’applicazione del proxy è una trasformazione interamente gestita, eseguita in fase di build: non richiede .NET Framework, funziona su .NET e .NET Framework e non cambia il comportamento osservabile del tuo programma (fatta eccezione per il piccolo insieme di chiamate elencate in Copertura, lasciate intenzionalmente dirette).

Limitazioni di compatibilità con AOT e piattaforme

Il proxy dinamico non è attualmente supportato sugli assembly .NET MAUI e Blazor, a causa di una combinazione di limitazioni delle piattaforme e di restrizioni del runtime che in questi ambienti impediscono di generare ed eseguire i proxy in modo sicuro e coerente.

Vincoli della piattaforma

  • Compilazione ahead-of-time (AOT): piattaforme come iOS (usata da .NET MAUI) e WebAssembly (usata da Blazor WebAssembly) impongono la compilazione AOT. Questo esclude l’uso di funzionalità di runtime come l’emissione di codice basata sulla reflection o la generazione di tipi in fase di esecuzione. Anche se il DynamicProxy di Babel non usa la generazione di codice in fase di esecuzione, la logica dei proxy generati può dipendere da metadati e costrutti IL che negli ambienti compilati AOT vengono rimossi o non sono supportati.

Limitazioni di compatibilità IL

  • Token di metadati non supportati: il meccanismo del proxy dinamico inserisce livelli di chiamata intermedi tramite tipi proxy generati e stub di delegate. Questi si basano su token di metadati e meccanismi di indirezione che possono non essere verificabili, o non essere affatto supportati, in alcuni target AOT, causando errori di convalida in fase di esecuzione o arresti anomali dell’applicazione.

Limitazioni di Blazor/WebAssembly

  • Funzionalità di reflection limitate: in Blazor WebAssembly la reflection è fortemente limitata. Poiché DynamicProxy spesso racchiude o intercetta le chiamate ai metodi, può produrre percorsi di chiamata indiretti incompatibili con il processo di collegamento e di tree-shaking usato nei flussi di pubblicazione per WebAssembly.

Raccomandazione

Per la piena compatibilità con gli ambienti AOT come .NET MAUI e Blazor, imposta DynamicProxy=false. In questo modo gli assembly generati restano interamente verificabili, conformi alla piattaforma e privi di funzionalità che potrebbero non funzionare durante il collegamento nativo o all’avvio del runtime.

Last updated on