Come proteggere .NET exe dal decompilazione / cracking

https://stackoverflow.com//questions/11711446

13-12-2019
|

Domanda

Sono davvero triste perché pochi giorni fa abbiamo lanciato il nostro software sviluppato in .NET 4.0 (applicazione desktop). Dopo 3 giorni, la sua crack era disponibile su Internet. Abbiamo cercato di proteggere il software da questo, ma in qualche modo la gente è andata via.

Ecco lo scenario: Quando l'applicazione avvia la prima volta che comunica con il server Web e controlla le credenziali passate dall'utente. Se le credenziali sono corrette, il software salva i valori nel registro, invia il computer del server e lo memorizza nel database.

Ora, l'hacker ha sostituito la comunicazione del server con un "return true; dichiarazione (l'ho controllato con Telrik JustDecompile). E ha caricato il software incrinato su Internet.

Ora, segue le mie domande:
1- Come assicurarsi che l'applicazione .NET non si spezzerà?
. 2- L'hacker ora conosce il mio codice da quando ha fatto la modifica. Quali misure dovrei prendere?
3- Ho letto su Internet su - Obfuscolatori. Ma l'hacker conosce il mio codice cosa dovrei fare?
4- Qualsiasi altro PRO suggerimenti che posso utilizzare per evitare di ottenere il software incrinato?
5- Non sono sicuro, ma questi software possono anche decompilare anche l'app.config con dati sensibili?

Soluzione

.
1- Come assicurarsi che l'applicazione .NET non si spezzerà?

Se un computer può eseguire il tuo codice + l'hacker può eseguire il proprio codice a un livello di privilegio più alto di te, non c'è nulla che può essere il 100% impedire che la tua app venisse incrinata. Anche se hanno appena accesso all'eseguibile ma non alla piattaforma di destinazione che possono ancora passare e imitare ciò che la piattaforma di destinazione dovrebbe fare e capire come viene eseguita la protezione.

.
2- L'hacker ora conosce il mio codice da quando ha fatto la modifica. Quali passi dovrei prendere?

Riscrivi totalmente la porzione di autenticazione in modo da poter partire da zero, ma lo recupereranno di nuovo, è solo una questione di quanto tempo.

.
3- Letto su Internet su - Obfuscolatori. Ma l'hacker conosce il mio codice cosa dovrei fare?

Il Jinni è fuori dalla bottiglia ora che hanno il codice non offuscato. Non c'è molto che puoi fare a meno che non si riconosca drasticamente il software in modo da poter iniziare da zero. Un offuscatore non previene un determinato attaccante, solo la cosa che può impedire che stia mantenendo il binario dalle loro mani.

.
4- Qualsiasi altro Pro suggerimenti che posso utilizzare per evitare di ottenere il software incrinato?

L'unica protezione da copia che ho visto per ritardare in remoto per qualsiasi periodo di tempo è ciò che Ubisoft ha fatto con Assassin's Creed: Brotherhood. Hanno crittografato a livelli con il disco del gioco e ha dovuto scaricare la chiave di decrittografia da Internet come era necessario (questo è il mantenimento del binario fuori dalle loro mani). Ma questo non ha funzionato per sempre, alla fine gli hacker hanno preso quei livelli decifrati ed è stato completamente incrinato. Questo approccio è proprio quello che ho visto prendere il tempo più lungo per andare in giro senza coinvolgimento legale (vedi punto 2 in basso)

.
5- Non sono sicuro, ma questi software possono anche decompilare anche l'app.config con dati sensibili?

Tutto il software del riflettore deve fare è cercare la sezione che carica app.config e leggi quali sono i valori predefiniti. C'è NO Secure Place Per memorizzare le informazioni su un computer che non hai pieno controllo. Se è sul computer, può essere letto. Se può essere letto, può essere inversa ingegnerizzato.

.
L'unica soluzione reale che posso vedere per evitare che la pirateria sia una delle due opzioni.

.

La persona non riceve mai la tua app, viene trasmessa da un server sotto il controllo e non riesce mai a vedere il binario. L'unica cosa che li mandi è le informazioni necessarie per guidare l'interfaccia utente. Questo è l'approccio che tutto il lavoro di MMO. Le persone possono invertire l'ingegnere ciò che stai inviando all'UI e imita la logica che sta succedendo sui tuoi server, ma non saranno mai in grado di vedere a titolo definitivo, vedere cosa sta facendo e se il tuo software è abbastanza complesso potrebbe non essere gradito per l'attaccante Per ricreare il codice laterale del server. Il lato negativo di questo approccio è necessario ospitare i server per i tuoi utenti a cui connettersi, questo sarà un costo ricorrente avrai bisogno di un modo per ri-colpo. Spesso questo metodo è chiamato "client ricco" o "client ricco" o "sottile client" a seconda della quantità di elaborazione sia eseguita lato client e la quantità di elaborazione è eseguita il lato server. Vedi Capitolo 22 di "< Guida all'architettura di Microsoft Application Architecture, 2a edizione ". In particolare, sto descrivendo ciò che viene mostrato in Figura 4 e 5

L'opzione SecCond è chiunque vendi anche il tuo software, se non vendi un contratto giuridico per non distribuire il software (non un EULA, un contratto effettivo che deve essere firmato fisicamente dal cliente). In tale contratto si possono applicare ambienti di grandi dimensioni alla persona che perde il software, quindi il tuo programma con impronte digitali che sono uniche per la persona che acquista il software in modo che quando il programma sia trapelato, puoi vedere chi lo ha fatto. (Questo è il metodo che i raggi esagonali del venditore utilizzano per il loro disassemblatore IDA . Una ricerca rapida di Google non è riuscita a presentare versioni incrinate più nuove di 6.1, sono su 6.3 ). Questo metodo non interromperà la pirateria, ma potrebbe scoraggiare la copia per essere trapelata in primo luogo. Ciò consente inoltre di recuperare alcuni costi persi associati al programma che è trapelato in primo luogo. Un problema è che dovrai mettere un sacco di impronte digitali e dovranno essere sottili, se un utente malintenzionato può ottenere due copie del programma e può confrontare i file tra
Een i due che sarà in grado di dire quali sono le informazioni identificative e basta mettere ciò che vogliono in modo che non possano dire a chi ne hanno capito. L'unico modo per farlo viene messo un sacco di aringhe rosse in quanto non può essere spogliato o randomizzato, rendere il codice identificativo non critico per eseguire il software, se non devono lavorare per rompersi Sono più propensi a lasciarlo in.

Aggiornamento : Dopo aver rivisitato questa risposta al collegamento ad esso per un'altra domanda ho pensato a un modo semplice per implementare la soluzione # 2.

Tutto quello che devi fare è eseguire il tuo codice attraverso un offuscatore e lascia che rinomina le tue lezioni per ogni persona che vendi il tuo software a (Li farò comunque firmare un contratto di licenza, non solo fare clic su un EULA in modo da poter rispettare il parte successiva). Allora effettuare un database della mappatura dell'obfussazione, quando vedi una copia trapelata su Internet devi solo trovare una classe ovunque nel progetto, cercate nel tuo database, e saprai chi è trapelato e saprai di chi è necessario Per andare dopo per danni legali.

Altri suggerimenti

1: Non puoi.Puoi offuscare, ma l'unico modo di impedendo questo è: non dare a nessuno l'exe.Guarda quante partite di giochi spendono su questo;nemmeno non lo hanno risolto.

2: L'offuscamento aiuterà un po ', sebbene sia una corsa di armi tra gli offuscolici e i de-obfuscolatori

3: Troppo tardi per tornare indietro e annullarlo, ma l'offuscamento li rallenta un po 'in futuro

5: App.config è solitamente molto leggibile;Non puoi fare qui;La crittografia le rallenterà solo un po 'se i tasti sono nella tua app e quindi ottenibili

Come altri hanno detto che non c'è niente che tu possa fare contro un cracker determinato se hanno accesso al tuo codice.L'offuscamento fornirà una certa protezione contro un cracker pigro. Dotfusciator è integrato in VS puoi dargli un tentativo.Tieni presente che c'è un vero costo per offuscare.Lo renderanno molto difficile il debug dei problemi dalle tracce dello stack che i tuoi clienti (paganti) ti mandano.

La migliore risposta è quella che dovrai accettare.Non puoi.Concentrati a dare ai tuoi utenti una grande esperienza utente e rendere le licenze molto facili.La possibilità che la tua applicazione possa essere incrinata non significa che scegliere di costruire un'applicazione desktop è stata una cattiva idea.I pirati saranno pirati e i clienti onesti saranno clienti onesti.

Apparentemente c'è abbastanza valore commerciale o intellettuale che cracking della tua app che qualcuno con abilità ragionevoli lo ha provato quasi subito.

The solo Vincererai che la guerra è utilizzare pacchetti di protezione del software commerciale.

Se si tenta di implementare la protezione da copia te stesso, sarai un bersaglio facile da ridurre di nuovo.

Se si scrive un'applicazione aziendale non scriverai anche il motore del database che memorizza i dati.Non dovresti anche scrivere il codice di prevenzione delle crack per la tua applicazione.Non è ciò che risolve il problema del tuo cliente, e ci vuole una tremenda abilità impostata per farlo bene.

Cosa puoi fare, oltre al codice Obfuscinazione è, aggiungere un meccanismo di decrittografia del codice in base all'hardwareid, ha in mente il seguente scenario, invia il loro hwid al tuo server, si identifica il numero di copia / proprietario / di installazione/ etc con quel hwid, e si risponde con una chiave di discreption basata in quel hwid per quel binario specifico (con le impronte digitali menzionate prima), quindi l'hacking sarebbe più difficile, poiché per la funzionalità completamente necessaria è necessario un accesso valido al tuo server, altrimenti essiNon è possibile utilizzare il software.

Saluti,

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow