Decompilazione .NET, quanto è facile?

Question

Stavo cercando la migliore crittografia per una chiave di licenza per un'applicazione e qualcuno ha detto che qualcuno può facilmente decompilare l'applicazione e quindi saltare il test per la chiave di licenza.

come farebbe qualcuno a farlo praticamente? Quindi hanno il mio dll, devono decompilarlo in qualche modo, quindi commentare la chiamata di funzione per controllare la licenza, quindi ricompilarla? Il decompilatore deve essere davvero buono in modo che il codice sia ancora compilato!

Answer 1

Prova ad aprire l'applicazione con Reflector . Probabilmente rimarrai sorpreso :-)

E una volta che un cracker ha individuato la posizione corretta nel codice, può utilizzare una combinazione di ildasm / ilasm per rimuovere il segno di spunta dalla tua applicazione, anche se il codice generato da Reflector non verrà compilato.

Answer 2

Se il codice sorgente è stato normalmente compilato, è molto semplice decompilare gli assembly .NET.

Puoi utilizzare .NET Reflector , originariamente sviluppato da Lutz Roeder, ora supportato da Redgate Software. C'è uno screenshot in fondo a questa risposta che ti dà un'idea di cosa fa Reflector.

Puoi sfogliare i tuoi spazi dei nomi e le classi e vedere il codice sorgente e i metodi nella tua lingua .NET preferita. FileDisassembler di Denis Bauer ti permetterà (o gli hacker malvagi) nel tuo caso) per convertirlo in una soluzione VS e apportare modifiche al programma.

Esistono alcune contromisure come l'uso di un offuscatore di codice per rendere il tuo codice praticamente illeggibile.

Ci sono altre domande interessanti su StackOverflow su questo argomento:

• Dovresti offuscare un'applicazione commerciale .Net?
• Come posso decompilare un .NET EXE in codice sorgente C # leggibile?
• I migliori strumenti / strategie di offuscamento .NET
• Crittografia .NET per chiavi di licenza?

Schermata di Reflector:

Answer 3

Josh Smith ha anche rilasciato di recente Crack.NET che può essere utilizzato per collegarsi a .NET in esecuzione processo, quindi aprilo in Reflector - quindi anche se gli assembly su disco sono crittografato in qualche modo (per evitare che le persone utilizzino Reflector per accedervi), saranno comunque in grado di utilizzare le versioni in memoria

Answer 4

.NET è semplicissimo da decompilare. L'offuscamento renderà un po 'più difficile capire cosa sta succedendo, ma qualcuno che decompila il tuo codice può ancora capirlo se sono persistenti.

Ecco alcuni consigli sulla protezione del codice .NET che ho trovato online:

http://blogs.msdn.com/ericgu /archive/2004/02/24/79236.aspx

Nota che nessuna delle tecniche discusse è efficace al 100%, è solo una questione di quanti cerchi farai saltare il cracker.

Answer 5

La compilazione .NET in generale è piuttosto semplice: per avere un'idea di questo da solo, basta prendere una copia di . NET Reflector e provalo.

Nella maggior parte dei casi, non sarà necessario ricompilare il codice per rimuovere un semplice controllo della licenza: semplicemente rattoppando MSIL farà il trucco.

Proteggersi da questo scenario produce rendimenti in rapida diminuzione: ci sarà sempre sempre qualcuno abbastanza intelligente da aggirare qualsiasi controllo aggiuntivo che aggiungi al tuo codice. Ad esempio, è possibile aggiungere una firma digitale al codice e rifiutare l'esecuzione della firma non corrisponde (indicando che il codice è stato manomesso, ad esempio per rimuovere il controllo della licenza).

Il gioco diventa quindi rimuovere il controllo della firma (oltre al controllo del codice di licenza). Quindi aggiungi un altro controllo, che può quindi essere ignorato, eccetera, all'infinito.

Esiste un intero settore di offuscamento del codice e strumenti di protezione dalla copia per aiutarti a difendere il tuo software da problemi come questo. Sta a te decidere se lo sforzo aggiuntivo dalla tua parte e il fastidio che causerai ai tuoi clienti legittimi, vale la pena acquistare in queste soluzioni ...

Answer 6

Se questo è qualcosa che stai cercando di difendere, potresti voler leggere su come attaccarlo.

Exploiting Software di Greg Holland & amp; Gary McGraw è un'introduzione eccellente.

Answer 7

È meglio non esagerare con la tecnologia delle chiavi di licenza. Qualunque cosa tu faccia può essere violato da un determinato utente e corri il rischio maggiore di aggiungere problemi che impediscono agli utenti legittimi di utilizzare la tua applicazione. Ho anche visto il codice protetto con Dongle Hasp essere crackato. Crittografare la chiave di licenza e offuscare il codice dovrebbe essere sufficiente per ostacolare gli attacchi opportunisti, c'è ben poco da fare oltre.

Eric Sink ha scritto un buon articolo su questo punto, vedere la sezione " 4. Non infastidire le persone oneste " di " Principi di trasparenza "

Answer 8

Anche senza Reflector, le persone lo fanno da anni. Fondamentalmente guardi l'app con un debugger - cosa che farà WinDBG - e poi scopri quando si verifica il controllo della licenza. Guardi il valore restituito e poi semplicemente applica l'applicazione per passare direttamente a " tutto bene " dai un'occhiata.

Consiglierei tutto ciò che le persone hanno pubblicato sopra. Devi solo capire che si tratta di un gioco di gatto e topo e se il tuo ritorno sugli investimenti ne varrà la pena. Se hai utenti che non stanno provando a giocare con il sistema, potrebbe fare qualcosa di semplice. Se hai qualcosa in cui il crack è dilagante, allora dovrai guardare diverse strategie e andare da lì.

Non è necessario ricompilare l'applicazione per correggerla: esistono molti strumenti binari di patch. E non fermerà i tuoi cracker più determinati se ci sono abbastanza soldi da guadagnare.

Answer 9

" Troppo "

Qualsiasi tipo di meccanismo di controllo della licenza "standard" / standard è un obiettivo per lo strumento di rimozione automatica. E nelle poche app .NET commerciali su cui ho riflettuto, queste "troppo banali" i controlli appaiono comuni.

La migliore scommessa è proteggere facendo parte del programma dipendente dal servizio web. Questa non dovrebbe essere un'interfaccia troppo chiacchierona per evitare di rallentare l'esecuzione, ma non dovrebbe nemmeno essere molto pesante, poiché quei blocchi potrebbero essere appena scaricati e memorizzati nella cache locale nella "versione crackata". a meno che l'app non dipenda da loro cambiando frequentemente.

Se vuoi evitare la connettività di rete (alcuni usi o utenti potrebbero trovarlo problematico / discutibile a seconda dell'app a meno che non sia qualcosa che descrivi e fornisca valore) quindi suddividendo parte del programma in una dll o due nativa e avendo il verifiche di licenza in tutte le parti dell'app e, ovviamente, in modo meno evidente nelle DLL native, sarebbero probabilmente sufficienti a scoraggiare la maggior parte.