Strumenti/strategia di offuscamento .NET [chiuso]

https://stackoverflow.com/questions/2525

08-06-2019
|

Domanda

Il mio prodotto ha diversi componenti:ASP.NET, app Windows Form e servizio Windows.Circa il 95% del codice è scritto in VB.NET.

Per motivi di proprietà intellettuale, ho bisogno di offuscare il codice e fino ad ora ho utilizzato una versione di dotfuscator che ha ormai più di 5 anni.Penso che sia giunto il momento di passare a uno strumento di nuova generazione.Quello che sto cercando è un elenco di requisiti che dovrei considerare quando cerco un nuovo offuscatore.

Quello che so che dovrei cercare finora:

Serializzazione/Deserializzazione.Nella mia soluzione attuale, dico semplicemente allo strumento non per offuscare qualsiasi membro dei dati della classe perché il problema di non riuscire a caricare i dati precedentemente serializzati è semplicemente troppo grande.
Integrazione con il processo di creazione
Lavorare con ASP.NET.In passato, ho riscontrato questo problema a causa della modifica dei nomi .dll (spesso ne hai uno per pagina), che non tutti gli strumenti gestiscono bene.

Soluzione

Tornando con .Net 1.1 l'offuscamento era essenziale:decompilare il codice era facile e potevi passare dall'assembly, al codice IL, al codice C# e compilarlo di nuovo con il minimo sforzo.

Ora con .Net 3.5 non ne sono affatto sicuro.Prova a decompilare un assembly 3.5;quello che ottieni è molto lontano dalla compilazione.

Aggiungi le ottimizzazioni da 3.5 (molto meglio di 1.1) e il modo in cui tipi anonimi, delegati e così via vengono gestiti dalla riflessione (sono un incubo da ricompilare).Aggiungi espressioni lambda, compilatore "magico" come la sintassi Linq e var, e C#2 funziona come yield (che si traduce in nuove classi con nomi illeggibili).Il tuo codice decompilato finisce per essere molto lontano dall'essere compilabile.

Un team di professionisti con molto tempo a disposizione potrebbe ancora effettuare il reverse engineering, ma lo stesso vale per qualsiasi codice offuscato.Il codice che ne sarebbero usciti sarebbe non mantenibile e molto probabilmente sarebbe molto difettoso.

Consiglierei di firmare la chiave dei tuoi assembly (il che significa che se gli hacker possono ricompilarne uno devono ricompilare tutti) ma non credo che ne valga la pena.

Altri suggerimenti

Abbiamo provato diversi offuscatori.Nessuno di essi funziona su un'app client/server di grandi dimensioni che utilizza la comunicazione remota.Il problema è che client e server condividono alcune DLL e non abbiamo trovato alcun offuscatore in grado di gestirlo.

Abbiamo provato DotFuscator Pro, SmartAssembly, XenoCode, Salamander e diverse app per piccoli tempi i cui nomi mi sfuggono.

Francamente, sono convinto che l'offuscamento sia un grosso trucco.

Anche i problemi che affronta non sono del tutto un problema reale.L'unica cosa che devi veramente proteggere sono le stringhe di connessione, i codici di attivazione e cose del genere sensibili alla sicurezza.Questa assurdità secondo cui un'altra azienda effettuerà il reverse engineering dell'intera base di codice e creerà un prodotto concorrente da esso è qualcosa che proviene dall'incubo di un manager paranoico, non dalla realtà.

Adesso sono "al ginocchio" in questo momento, cercando di trovare una buona soluzione.Ecco le mie impressioni finora.

Xenocodice - Ho una vecchia licenza per Xenocode2005 che usavo per offuscare i miei assembly .net 2.0.Ha funzionato bene su XP ed è stata una soluzione decente.Il mio progetto attuale è .net 3.5 e sono su Vista, il supporto mi ha detto di provarlo ma la versione 2005 non funziona nemmeno su Vista (si blocca), quindi ora devo acquistare "PostBuild2008" a un prezzo sbalorditivo di $ 1900.Questo potrebbe essere un buon strumento ma non lo scoprirò.Troppo caro.

Reactor.Net - Questo è un prezzo molto più interessante e ha funzionato bene sul mio eseguibile autonomo.Anche il modulo di licenza era carino e mi avrebbe risparmiato un sacco di fatica.Sfortunatamente, manca una caratteristica fondamentale e cioè la capacità di escludere elementi dall'offuscamento.Ciò rende impossibile ottenere il risultato di cui avevo bisogno (unire più assiemi insieme, offuscarne alcuni, non offuscare altri).

SmartAssembly - Ho scaricato Eval per questo e ha funzionato perfettamente.Sono riuscito a ottenere tutto ciò che volevo e l'interfaccia era di prima classe.Il prezzo è ancora un po' alto.

Dotfuscator Pro - Impossibile trovare il prezzo sul sito web.Attualmente in trattative per ottenere un preventivo.Sembra inquietante.

Confuso - un progetto open source che funziona abbastanza bene (per confondere le persone, proprio come suggerisce il nome). https://confuser.codeplex.com/
(aggiunto da jgauffin)

Nota:Secondo quanto riferito, ConfuserEx è "rotto". Numero 498 sul loro repository GitHub.

Se ne stai cercando uno gratuito, puoi provare DotObfuscator Community Edition fornito con Visual Studio o Eazfuscator.NET.

Dal 29 giugno 2012, Eazfuscator.NET è ora commerciale.L'ultima versione gratuita disponibile è la 3.3.

Sto usando smartassembly.Fondamentalmente, scegli una DLL e la restituisce offuscata.Sembra funzionare bene e finora non ho avuto problemi.Molto, molto facile da usare.

Ho provato quasi tutti gli offuscatori sul mercato e SmartAssembly è il migliore secondo me.

Ho anche utilizzato SmartAssembly.Ho scoperto che Ezrinz .Net Reactor è molto migliore per me sulle applicazioni .net.Offusca, supporta Mono, unisce assiemi e ha anche un modulo di licenza molto carino per creare versioni di prova o collegare la licenza a una macchina particolare (molto facile da implementare).Anche il prezzo è molto competitivo e quando ho avuto bisogno di supporto sono stati rapidi.Eziriz

Tanto per essere chiari, sono semplicemente un cliente a cui piace il prodotto e non ho alcuna relazione con l'azienda.

La risposta breve è che non puoi.

Esistono vari strumenti in giro che renderanno più difficile per qualcuno leggere il tuo codice, alcuni dei quali sono stati sottolineati da altre risposte.

Tuttavia, tutto ciò non fa altro che rendere più difficile la lettura: aumentano la quantità di sforzo richiesto, tutto qui.Spesso questo è sufficiente per scoraggiare i lettori occasionali, ma qualcuno che è determinato a scavare nel tuo codice sarà sempre in grado di farlo.

Disponiamo di un'app multilivello con un'interfaccia asp.net e winform che supporta anche la comunicazione remota.Non ho avuto problemi con l'utilizzo di qualsiasi offuscatore, ad eccezione del tipo di crittografia che genera un caricatore che può essere problematico in tutti i modi inaspettati e secondo me non ne vale la pena.In realtà il mio consiglio sarebbe più sulla falsariga di "Evitare come la peste la crittografia degli offuscatori del tipo caricatore".:)

Nella mia esperienza, qualsiasi offuscatore funzionerà bene con qualsiasi aspetto di .net, inclusi asp.net e servizi remoti, devi solo acquisire familiarità con le impostazioni e imparare fino a che punto puoi spingerti in quali aree del tuo codice.E prenditi il tempo per tentare il reverse engineering su ciò che ottieni e vedere come funziona con le varie impostazioni.

Ne abbiamo utilizzati diversi nel corso degli anni nelle nostre app commerciali e abbiamo optato per l'offuscatore Spices di 9rays.net perché il prezzo è giusto, fa il suo lavoro e hanno un buon supporto anche se non ne abbiamo più bisogno da anni, ma ad essere onesti Non penso che sia davvero importante quale offuscatore usi, i problemi e la curva di apprendimento sono tutti gli stessi se vuoi che funzioni correttamente con i servizi remoti e asp.net.

Come altri hanno già detto, tutto ciò che stai facendo è l'equivalente di un lucchetto, tenendo lontane le persone altrimenti oneste e/o rendendo più difficile la semplice ricompilazione di un'app.

La licenza è solitamente l'area chiave per la maggior parte delle persone e dovresti comunque utilizzare comunque una sorta di sistema di certificazione con firma digitale per la licenza.La perdita più grande deriverà dalla condivisione casuale delle licenze: se non si dispone di un sistema intelligente, le persone che infrangono il sistema di licenza non avrebbero mai acquistato.

È davvero facile spingersi troppo oltre e avere un impatto negativo sui tuoi clienti e sulla tua attività, fai ciò che è semplice e ragionevole e poi non preoccuparti.

Negli ultimi due giorni ho sperimentato Dotfuscator Community Edition advanced (un download gratuito dopo aver registrato il CE di base fornito in bundle con Visual Studio).

Penso che il motivo per cui molte persone non utilizzano l'offuscamento come opzione predefinita è che è una seccatura seria rispetto al rischio.Su progetti di test più piccoli ho potuto far funzionare il codice offuscato con molto sforzo.La distribuzione di un progetto semplice tramite ClickOnce è stata problematica, ma realizzabile dopo aver firmato manualmente i manifest con mage.L'unico problema era che in caso di errore l'analisi dello stack tornava offuscata e CE non dispone di un deoffuscatore o di un chiarificatore confezionato.

Ho provato a offuscare un progetto reale basato su VSTO in Excel, con l'integrazione di Virtual Earth, molte chiamate a servizi Web e un contenitore IOC e molte riflessioni.Era impossibile.

Se l'offuscamento è davvero un requisito fondamentale, dovresti progettare la tua applicazione tenendolo presente fin dall'inizio, testando le build offuscate man mano che avanzi.Altrimenti, se si tratta di un progetto abbastanza complesso, ti ritroverai con una grande quantità di dolore.

Offuscatore crittografico affrontare tutte le tue preoccupazioni e scenari.Esso :

Esclude automaticamente tipi/membri dall'offuscamento in base alle regole.I tipi/campi serializzati sono uno di questi.
Può essere integrato nel processo di compilazione utilizzando MSBUild.
Supporta progetti ASP.Net.

Recentemente ho provato a convogliare l'output di un offuscatore gratuito in un altro offuscatore gratuito, vale a dire Dotfuscator CE e il nuovo offuscatore Babel su CodePlex.Più dettagli sul mio blog.

Per quanto riguarda la serializzazione, ho spostato il codice in una DLL diversa e l'ho incluso nel progetto.Ho pensato che comunque non ci fossero segreti che non fossero nell'XML, quindi non c'era bisogno di offuscamento.Se in quelle classi è presente del codice serio, l'utilizzo di classi parziali nell'assembly principale dovrebbe coprirlo.

Dovresti utilizzare ciò che è più economico e più conosciuto per la tua piattaforma e chiamarlo un giorno.L'offuscamento dei linguaggi di alto livello è un problema difficile, perché i flussi di codice operativo VM non soffrono dei due maggiori problemi che soffrono i flussi di codice operativo nativo:identificazione di funzioni/metodi e aliasing di registri.

Ciò che dovresti sapere sull'inversione del bytecode è che è già una pratica standard per i tester della sicurezza esaminare il codice X86 diretto e trovare vulnerabilità in esso.Nell'X86 grezzo, non è necessariamente possibile trovare funzioni valide, per non parlare di tenere traccia di una variabile locale durante una chiamata di funzione.In quasi nessuna circostanza gli invertitori di codice nativi hanno accesso ai nomi di funzioni e variabili, a meno che non stiano rivedendo il codice Microsoft, per il quale MSFT fornisce utilmente tali informazioni al pubblico.

"Dotfuscation" funziona principalmente rimescolando i nomi delle funzioni e delle variabili.Probabilmente è meglio farlo piuttosto che pubblicare codice con informazioni a livello di debug, dove Reflector rinuncia letteralmente al tuo codice sorgente.Ma qualsiasi cosa tu faccia oltre a questo probabilmente avrà rendimenti decrescenti.

Non ho avuto problemi con Smartassembly.

Potresti utilizzare "Dotfuscator Community Edition": è disponibile per impostazione predefinita in Visual Studio 2008 Professional.Puoi leggerlo su:

http://msdn.microsoft.com/en-us/library/ms227240%28VS.80%29.aspx
http://www.preemptive.com/dotfuscator.html

La versione "Professional" del prodotto costa ma è migliore.

Hai davvero bisogno che il tuo codice sia offuscato?Di solito c'è ben poco di sbagliato nel fatto che la tua applicazione venga decompilata, a meno che non venga utilizzata per scopi di sicurezza.Se sei preoccupato che le persone "rubino" il tuo codice, non esserlo;la stragrande maggioranza delle persone che guarderanno il tuo codice sarà per scopi di apprendimento.Ad ogni modo, non esiste una strategia di offuscamento totalmente efficace per .NET: qualcuno con sufficiente abilità sarà sempre in grado di decompilare/modificare l'applicazione.

Evita il reattore.È completamente inutile (e sì, ho pagato una licenza).Xenocode è stato il migliore che ho incontrato e per il quale ho acquistato anche una licenza.Il supporto è stato molto buono ma non ne ho avuto bisogno perché ha funzionato e basta.Ho testato tutti gli offuscatori che ho trovato e la mia conclusione è che lo xenocode era di gran lunga il più robusto e faceva il lavoro migliore (anche possibilità di pubblicare il tuo exe .NET su un exe nativo che non ho visto da nessun'altra parte).

Esistono due differenze principali tra reattore e xenocodice.Il primo è che Xenocode funziona davvero.Il secondo è che la velocità di esecuzione dei tuoi assiemi non è diversa.Con il reattore era circa 6 milioni di volte più lento.Ho anche avuto l'impressione che il reattore fosse un'operazione gestita da un solo uomo.

Ho scoperto che Agile.Net fornisce una protezione abbastanza buona per il tuo assembly .Net perché offre non solo offuscamento ma anche crittografia.Scarica un percorso gratuito.
http://secureteam.net/NET-Code-Protection.aspx http://secureteam.net/downloads.aspx

Ho offuscato il codice nella stessa applicazione da .Net 1 ed è stato un grosso grattacapo dal punto di vista della manutenzione.Come hai già detto, il problema della serializzazione può essere evitato, ma è davvero facile commettere un errore e offuscare qualcosa che non volevi offuscato.È facile interrompere la build o modificare il modello di offuscamento e non riuscire ad aprire i vecchi file.Inoltre può essere difficile scoprire cosa è andato storto e dove.

La nostra scelta è stata Xenocode e, se dovessi fare di nuovo la scelta oggi, preferirei non offuscare il codice o utilizzare Dotfuscator.

Ecco un documento della stessa Microsoft. Spero che questo aiuti..., è del 2003, ma potrebbe essere ancora rilevante.

Stiamo utilizzando SmartAssembly sul nostro client Windows.Funziona bene.

Aggiunge anche alcuni problemi aggiuntivi.La stampa dei nomi delle classi nei file di registro/eccezioni deve essere deoffuscata.E ovviamente non è possibile creare una classe dal suo nome.Quindi è una buona idea dare un'occhiata al tuo cliente e vedere quali problemi puoi ottenere offuscando.

Tutto dipende dal linguaggio di programmazione che usi.Leggi l'articolo: Codice offuscato

il modo gratuito sarebbe utilizzare dotfuscator da Visual Studio, altrimenti dovresti uscire e acquistare un offuscatore come Postbuild (http://www.xenocode.com/Landing/Obfuscation.aspx)

Ho dovuto utilizzare un'offuscamento/protezione delle risorse nel mio ultimo progetto e ho trovato Offuscatore crittografico come uno strumento piacevole e semplice da usare.Il problema della serializzazione è solo una questione di impostazioni in questo strumento.

Esiste una buona versione open source chiamata Obfuscar.Sembra funzionare bene.Tipi, proprietà, campi, metodi possono essere esclusi.L'originale è qui: https://code.google.com/p/obfuscar/, ma poiché sembra non essere più aggiornato, qualcuno lo ha biforcato qui: https://obfuscar.codeplex.com/

Potresti anche voler esaminare nuove tecnologie di protezione del codice come Metaforico E V.i.Labs e nuove tecnologie di protezione dalla copia del software come ByteShield.Divulgazione:Lavoro per ByteShield.

Utilizzo anche smartassembly.Tuttavia, non so come funzioni per un'applicazione web.Tuttavia, vorrei sottolineare che se la tua app utilizza la protezione di tipo shareware, assicurati che non controlli una licenza con un ritorno booleano.è troppo facile byte crack.http://blogs.compdj.com/post/Binary-hack-a-NET-executable.aspx

SmartAssembly è fantastico, è stato utilizzato nella maggior parte dei miei progetti

Ho provato la versione demo di Eziriz....mi è piaciuta.Ma non ho mai portato il software.

L'offuscamento non è una vera protezione.

Se hai un file .NET Exe, è disponibile un file .NET Exe Molto meglio soluzione.

Io uso Themida e posso dire che funziona molto bene.

L'unico inconveniente di Themida è che non può proteggere le DLL .NET.(Protegge anche il codice C++ in Exe e DLL)

Themida è di gran lunga più economico degli offuscatori qui menzionati ed è il migliore in circolazione anti pirateria protezione sul mercato.Crea una macchina virtuale in cui vengono eseguite parti critiche del codice ed esegue diversi thread che rilevano manipolazioni o punti di interruzione impostati da un cracker.Converte .NET Exe in qualcosa che Reflector non riconosce più nemmeno come assembly .NET.

Si prega di leggere la descrizione dettagliata sul loro sito web:http://www.oreans.com/themida_features.php

Ho provato un prodotto chiamato Rummage e fa un buon lavoro nel darti un po' di controllo...Anche se mancano molte cose che offre Eziriz, ma il prezzo per Rummage è troppo buono...

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow