Funzionalità generali

Protegge il tuo codice e la tua proprietà intellettuale dal reverse engineering

Babel Obfuscator applica a un assembly compilato diversi strati di protezione indipendenti: rinomina i simboli con identificatori privi di significato, cifra le stringhe, le costanti e gli array e le risorse, riscrive il flusso di controllo dei metodi, nasconde le destinazioni delle chiamate dietro il proxy dinamico e può cifrare interi corpi di metodo per eseguirli in una macchina virtuale gestita. L’applicazione conserva il suo comportamento e la sua interfaccia pubblica; ciò che un decompilatore recupera non è più il sorgente che hai scritto.

Gli strati si sommano. La ridenominazione toglie il vocabolario su cui fa affidamento chi legge, la cifratura delle stringhe e dei valori toglie gli indizi che sopravvivono alla ridenominazione, l’offuscamento del flusso di controllo toglie la struttura e la cifratura del codice toglie il codice stesso. Applicati insieme, e in modo selettivo dove si trova la proprietà intellettuale, portano il costo di comprendere e modificare l’assembly molto al di sopra del valore che un attaccante può ricavarne.

Compatibile con tutto l’ecosistema .NET

Babel Obfuscator lavora a livello di IL e di metadati, quindi supporta ogni runtime e ogni modello di applicazione che produce assembly .NET standard:

• .NET 10 e tutte le versioni precedenti di .NET e .NET Core
• .NET Framework dalla 2.0 alla 4.8
• Applicazioni desktop realizzate con WPF, Windows Forms o Avalonia
• .NET MAUI su Android e iOS, e Xamarin
• Blazor e ASP.NET Core
• .NET Standard, UWP, Mono e nanoFramework

Gestisce il codice scritto in C#, fino a C# 14, in VB.NET e in F#, e segue le modalità di pubblicazione dell’SDK moderno: dipendente dal framework, autonoma, a file singolo, con trimming e NativeAOT. La ridenominazione dei simboli, la cifratura delle stringhe STREAM e l’offuscamento del flusso di controllo, compreso Chained State, superano inalterati il trimming e la compilazione ahead-of-time (AOT). Le funzionalità che si basano su un’immagine mappata in memoria o su IL dinamico, come la cifratura del codice, il proxy dinamico e il controllo delle manomissioni per desktop, hanno limiti documentati sui target MAUI, Blazor e AOT; la pagina di ogni funzionalità li indica, e gli esempi Offuscare .NET MAUI e Blazor Web App mostrano configurazioni funzionanti.

Funziona su Windows, macOS e Linux ★Ultimate

Ogni edizione include lo strumento da riga di comando e il task MSBuild per Windows (pacchetti zip). Per eseguire Babel Desktop, per eseguire Babel su macOS e Linux e all’interno di Azure DevOps, GitHub Actions e pipeline di build per la CI analoghe serve l’edizione Ultimate, oppure le edizioni Server e Data Center di Babel Licensing, che la includono: solo queste forniscono i pacchetti NuGet di Babel Obfuscator, che eseguono Babel come strumento dotnet su qualsiasi sistema operativo e lo integrano in dotnet build e dotnet publish. L’edizione Enterprise è limitata allo strumento da riga di comando per Windows e al task MSBuild del pacchetto zip per .NET Framework.

Poiché l’offuscamento lavora sull’IL, il sistema operativo dell’host di build non vincola il target: un agente di build Windows può proteggere assembly pubblicati per linux-x64, linux-arm64 o osx-arm64, e un container Linux può proteggere un’applicazione desktop per Windows. I team possono quindi mantenere l’ambiente di build che hanno già.

Cifratura del codice e virtualizzazione interamente gestite

La cifratura del codice riscrive l’IL di un metodo in un set di istruzioni personalizzato, lo cifra e lascia al suo posto uno stub che passa il controllo alla Babel Virtual Machine (BVM), un runtime gestito leggero incorporato nell’assembly offuscato. La BVM decifra ed esegue il metodo quando viene chiamato. Il corpo del metodo non esiste più nell’assembly in una forma che un decompilatore possa leggere, e le istruzioni non possono essere modificate con una patch.

La soluzione è interamente gestita: i metodi cifrati non vengono sostituiti da codice nativo per una piattaforma specifica, quindi la natura multipiattaforma di .NET è preservata e il compilatore JIT continua a ottimizzare per la CPU di destinazione. Il codice cifrato può essere conservato in file di codice esterni distribuiti insieme a una licenza, oppure protetto da una password fornita in fase di esecuzione, che è la base delle licenze basate sulle funzionalità. L’articolo Associazione a dongle hardware mostra come legare il codice cifrato a un dispositivo fisico. Poiché incide sulle prestazioni, la cifratura del codice è pensata per le parti sensibili del codice, mentre le altre protezioni coprono il resto.

Rafforzato contro il deoffuscamento automatico ★Ultimate

L’offuscamento classico ferma un lettore umano; una categoria di strumenti automatici riesce però ad annullarne una parte in un solo passaggio, recuperando staticamente l’ordine di un metodo sottoposto ad appiattimento (flattening) o leggendo la chiave che si trova accanto a una stringa cifrata. La versione 12.0 aggiunge due trasformazioni pensate per questo avversario:

• Chained State appiattisce un metodo attorno a un dispatcher il cui ordine originale non può essere recuperato con la sola analisi statica. Nei test interni contro un comune deoffuscatore automatico, i metodi appiattiti con il normale algoritmo switch sono stati ricostruiti, mentre gli stessi metodi appiattiti con chain sono rimasti intatti. Genera IL verificabile, non aggiunge dipendenze di runtime e le sue prestazioni si discostano di pochi punti percentuali da quelle dell’appiattimento normale.
• La cifratura delle stringhe STREAM cifra ogni stringa singolarmente con un cifrario autenticato, la decifra in modo differito (lazy) al primo utilizzo e non memorizza mai la chiave inline. Stringhe identiche producono byte cifrati diversi, in nessun momento l’intero insieme delle stringhe è in chiaro, e il decifratore interamente gestito viene pubblicato senza modifiche con il trimming, con NativeAOT e in modalità FIPS.

Rileva debug e manomissioni, su desktop e mobile

Il codice di protezione dal debug iniettato nell’assembly rileva un debugger collegato e termina il processo oppure invoca un tuo metodo. Il rilevamento delle manomissioni verifica all’avvio che l’assembly sia quello prodotto da Babel: sui target desktop calcola l’hash dell’immagine caricata in memoria e lo confronta con un hash impresso al momento dell’offuscamento.

A partire dalla versione 12.0 il rilevamento delle manomissioni copre .NET MAUI, dove la tecnica per desktop non è applicabile. Su Android l’app offuscata confronta il certificato con cui è stato firmato l’APK in esecuzione con le impronte dei firmatari attendibili che fissi al momento dell’offuscamento, quindi un’app riconfezionata o firmata di nuovo viene rifiutata. Su iOS verifica il proprio identificatore del bundle e l’identificatore del team Apple. Entrambi i controlli esaminano il pacchetto del sistema operativo anziché l’immagine gestita, quindi continuano a funzionare con il trimming e con AOT completo. In ogni caso la reazione la scegli tu: terminare il processo, oppure eseguire un gestore personalizzato che può scrivere nel log, ridurre le funzionalità o contattare un tuo server.

Semplifica la distribuzione unendo e incorporando le dipendenze

Unione e incorporamento trasforma un’applicazione e le sue dipendenze in un unico file. L’unione integra nel target il codice degli assembly referenziati e lo rinomina insieme al tuo, così i tipi uniti possono essere internalizzati e offuscati come un’unica unità: la distribuzione si semplifica e la superficie di codice leggibile si riduce. L’incorporamento memorizza un assembly intero, come risorsa cifrata caricata in fase di esecuzione, ed è adatto agli assembly di terze parti o con nome sicuro che non devono essere alterati. Le due tecniche si possono combinare nello stesso progetto.

Ottimizza il codice e i metadati

Oltre a proteggerlo, Babel ottimizza l’assembly che produce. La rimozione del codice inutilizzato elimina metodi, campi, proprietà e tipi che non vengono mai usati. Le ottimizzazioni dei metadati sigillano automaticamente le classi e rimuovono gli attributi personalizzati superflui, i tipi System.Enum e i costrutti di proprietà ed eventi. Le ottimizzazioni del codice espandono inline i metodi e le proprietà di piccole dimensioni e rimuovono i campi const. Il risultato è un assembly più piccolo su disco, più rapido da caricare e più difficile da leggere, perché i metadati su cui fa affidamento chi fa reverse engineering sono stati ridotti a ciò che serve al runtime.

Integrato con Visual Studio, MSBuild, NuGet e i server di build

Babel viene eseguito all’interno della build, non dopo. Il task MSBuild di Babel offusca da Visual Studio e da qualsiasi server di build che esegue MSBuild, e ogni proprietà del task è documentata con IntelliSense nel file di progetto. Il pacchetto NuGet Babel.Obfuscator ★Ultimate va oltre per i progetti in stile SDK: un solo riferimento al pacchetto colloca il task nel punto giusto della pipeline di dotnet build e dotnet publish, prima che il trimming e la compilazione ahead-of-time riscrivano l’assembly, ed è questo l’unico ordine in cui quelle modalità di pubblicazione possono essere protette. Gli esempi per i server di build coprono Azure DevOps, GitHub Actions, AppVeyor e App Center, e mostrano come eseguire i test unitari sull’output offuscato; come il pacchetto NuGet, richiedono l’edizione Ultimate.

Disponibile come strumento da riga di comando, con una modalità compatibile con l’AI

Tutto ciò che Babel sa fare è disponibile dalla riga di comando, su Windows, Linux e macOS. Dalla versione 11.7 lo strumento offre anche una modalità compatibile con l’AI per pipeline e agenti: --format=json o --format=ndjson emettono su stdout un flusso di eventi strutturato e con versione, mentre la diagnostica va su stderr, --quiet sopprime il banner e termina subito con un errore invece di chiedere un input, e --strict-exit abilita codici di uscita semantici che distinguono argomenti non validi, input mancante ed errori di offuscamento, di licenza e di firma. La stessa opzione trasforma --help in una descrizione leggibile dalle macchine di ogni opzione.

Utilizzabile dagli assistenti AI tramite MCP

Babel Desktop può ospitare un server Model Context Protocol, così un assistente come Claude Code si connette all’applicazione in esecuzione e la pilota: crea un progetto, aggiunge assembly, scrive regole, sceglie che cosa unire o incorporare, offusca, legge avvisi e statistiche, decodifica uno stack trace, crea un tema e fa uno screenshot per controllare il risultato. Gli strumenti coprono le operazioni che esegui più spesso, e a questi si aggiungono gli strumenti per le impostazioni, per Babel Licensing e per gli aggiornamenti dell’applicazione. Nelle edizioni Server e Data Center lo stesso server gestisce il database delle licenze: clienti, prodotti, ordini, licenze, chiavi di firma, generazione ed esportazione delle licenze.

Il server è disattivato per impostazione predefinita, è in ascolto solo sull’indirizzo di loopback e può richiedere un token di accesso a ogni richiesta. Babel Licensing offre un server MCP separato per il Licensing Service ospitato.

Decodifica gli stack trace offuscati

La ridenominazione cambia i nomi che compaiono negli stack trace delle eccezioni, perciò Babel produce un file map XML per ogni assembly offuscato e fornisce gli strumenti per riportare uno stack trace ai nomi originali. Il Decodificatore stack di Babel Desktop e l’opzione della riga di comando --stacktrace ripristinano i nomi originali, con il supporto facoltativo dei file PDB per i numeri di riga. Quando il proxy dinamico è abilitato, il decodificatore indica il metodo che sta dietro ogni frame ponte del proxy e può nascondere del tutto i frame generati da Babel, lasciando uno stack trace identico a quello che produrrebbe l’applicazione non offuscata. I file map guidano anche la ridenominazione cross-assembly, così un’applicazione e le sue librerie possono essere offuscate in build separate e concordare comunque sui simboli rinominati.

Pronto per FIPS

Gli assembly protetti con Babel funzionano sugli host in modalità FIPS. Le funzionalità che decifrano contenuti in fase di esecuzione, cioè la cifratura del codice, la cifratura delle stringhe, la cifratura delle risorse e la cifratura di valori e array, possono essere configurate per usare un decifratore AES gestito e autonomo, così il runtime iniettato non dipende mai dal provider crittografico della piattaforma e l’applicazione si avvia anche in un container in cui manca il provider FIPS di OpenSSL. La pagina Conformità FIPS spiega la condizione dell’ambiente, la correzione al momento dell’offuscamento e la correzione a livello di ambiente.

Estendibile con regole, attributi e plugin

Ogni funzionalità può essere regolata per singolo simbolo. Le regole XML selezionano tipi e membri per modello, attributo, visibilità o ereditarietà e abilitano, disabilitano o configurano una funzionalità per quei simboli; gli attributi personalizzati fanno lo stesso dal codice sorgente. L’Obfuscation Agent analizza l’assembly prima dell’offuscamento e genera le regole che mantengono funzionanti reflection, serializzazione, data binding e codice dinamico. Per tutto il resto, i plugin scritti in .NET possono aggiungere algoritmi di cifratura di stringhe e valori, schemi di ridenominazione personalizzati, regole generate e trasformazioni del codice, con esempi open source su GitHub come punto di partenza.