Come mantenere la logica del programma .NET (ragionevolmente) segreta?

Question

Giusto, sto parlando del codice di convalida della licenza in un'applicazione desktop, ad es. un metodo bool ValidateLicense(string licenseCode). Ovviamente, qualsiasi schema di protezione può essere decodificato da un cracker esperto e determinato. Tuttavia, vorrei evitare che chiunque abbia qualche conoscenza di programmazione di base possa utilizzare Reflector per creare un keygen in un paio di minuti.

possibili approcci

1. Oscurazione. La mia comprensione è che offuscare causa un overhead delle prestazioni e può ostacolare il debug (legittimo). Quindi ci sono strumenti che consentono di offuscare solo i metodi selezionati?

2. Spostare il metodo sull'assembly di ngen o sulla DLL non gestita. Ma non è questo un invito a sostituire semplicemente la DLL? Qualche idea su come prevenirlo (leggi: renderlo un po 'più difficile per un aggressore)?

3. Altro?

PS: La domanda è ovviamente legato alla Protect .NET code from reverse engineering? cercando di mettere i pensieri da lì a praticare

UPDATE

A 1. Un primo passo offuscamento sarebbe sicuramente per rinominare il metodo di convalida. (Grazie, Jonathan)

A 2. Supponendo che l'applicazione utilizzi i metodi API Win32, è possibile reindirizzare le chiamate attraverso una DLL non gestita rendendola così parte integrante dell'applicazione. Giocherellare con le firme del metodo (ad esempio cambiare nome, parametri di swap) renderebbe questo meno ovvio. Pensi che gli inconvenienti innati siano giustificati?

A 3. Non distribuire il metodo di convalida appartiene qui. Conservalo sul tuo server e chiama da remoto, cioè usa la convalida online (Grazie, David Hedlund)

Answer 1

Eazfuscator ti consente di offuscare il tuo codice solo in Versione, lo stiamo utilizzando e non ci sono problemi di prestazioni. Ti consente di nascondere anche i metodi selezionati. Si noti che i metodi pubblici non possono essere offuscati.

Qualsiasi funzione di come il vostro ValidateLicense può essere facilmente modificata con un buon riflettore l'inserimento di un ritorno vero come la prima linea :(si Raccomando questo articule circa l'inserimento di codice nelle assemblee: http://www.codeproject.com/Articles/20565/Assembly-Manipulation-and-C-VB-NET-Code-Injection

Si dovrebbe firmare gli assembly da evitare modifiche, ma ... La firma può anche essere rimossa con gli strumenti propper: http://www.nirsoft.net/dot_net_tools/strong_name_remove.html

Ci scusiamo, ma non c'è alcun trucco per evitare il reverse engineering in .Net, è solo possibile rendere le cose più difficili. (Ad es. non nominare la tua funzione ValidateLicense e rendere la tua logica di validazione un po 'criptica)

Answer 2

Un approccio adottato da molti fornitori di software richiede l'attivazione online. In questo modo, il codice di convalida della chiave può essere eseguito solo sul tuo server, il che lo renderebbe meno accessibile agli aspiranti hacker.

Ovviamente, si introduce la nuova vulnerabilità del semplice reindirizzamento della chiamata di convalida a un server personalizzato che invia una risposta positiva, se l'hacker conosce o può estrarre informazioni su come si prevede che tale risposta venga visualizzata. Ma poi, come fai notare, ci sarà sempre qualcuno che sarà in grado di hackerare il tuo prodotto, quindi direi comunque che questa è una valida opzione.

Answer 3

Tre possibili attacchi alla convalida sono

1. scavalcando convalida rimuovendo le chiamate ad esso
2. inversione logica di convalida ingegnere rivelare codici legittimi
3. inversione logica di convalida ingegnere per consentire condizione convalida per soddisfatte modificando ambiente

Un approccio è quello di convalidare la licenza in diversi punti dell'applicazione - questo aiuta a mitigare 1. L'offuscamento del codice aiuta a mitigare il 2 e il 3 - ma alla fine è un problema irrisolvibile.

La mia opinione è una combinazione di questi approcci che impedirebbe ai programmatori di base di rubare il tuo programma, ma poi di nuovo, se qualcosa ne vale la pena - allora qualcuno lo farà.

Answer 4

So che non è la risposta, ma vorrei suggerire l'utilizzo di .NET Reactor http://www.eziriz.com/ in quanto ha già meccanismi per entrambe le licenze (con vari scenari di licenza) e protezione del codice forte.