Proteggere il codice .NET dal reverse engineering?


491

L'offuscamento è un modo, ma non può proteggere dalla violazione della protezione della pirateria dell'applicazione. Come posso assicurarmi che l'applicazione non sia manomessa e come posso assicurarmi che il meccanismo di registrazione non possa essere decodificato?

Inoltre è possibile convertire un'applicazione C # in codice nativo e Xenocode è troppo costoso.

C # offre molte funzionalità ed è il linguaggio ideale per il mio codice, quindi scrivere di nuovo l'intera base di codice in C ++ è fuori discussione.

I certificati sicuri possono essere facilmente rimossi dagli assembly firmati in .NET.



@Andreas: è fantastico !! Ho intenzione di provare. Qualcuno lo sta usando?
Jack,

1
@Jack è solo per le app di vetrine. Non esiste una sequenza temporale per le app desktop (per quanto ne so).
Tyler Long,

Se vuoi nativo senza C ++ arcaico, usa Delphi. La facilità di .Net proviene comunque da Delphi.
William Egge,

Risposte:


671

Non puoi.

Ci sono passaggi che puoi prendere per renderlo un po ' più difficile, ma alla fine qualsiasi eseguibile sul computer locale è crackabile. Alla fine, quel codice deve essere convertito in codice macchina nativo e ogni applicazione eseguibile è vulnerabile.

Quello che vuoi fare è solo rendere abbastanza difficile da decifrare per rendere non degno i problemi della gente.

Alcuni suggerimenti che ho per te per aiutarti a proteggere la tua applicazione:

  • Offusca il tuo codice. Dotfuscator ha un'edizione gratuita e viene fornito con Visual Studio.
  • Utilizzare la chiave pubblica / privata o la crittografia asimmetrica per generare le licenze del prodotto. Questo assicura che solo tu puoi generare i tuoi codici di licenza. Anche se la tua applicazione è craccata, puoi essere sicuro che non rilasceranno un generatore di chiavi per la tua applicazione, perché è impossibile invertire l'algoritmo di generazione delle chiavi.
  • Utilizzare un packer di terze parti per comprimere il file eseguibile .NET in un'applicazione wrapper Win32 crittografata. Themida è uno dei migliori. Questo impedisce alle persone di riflettere la tua applicazione in .NET Reflector e rende difficile decomprimere per l'inversione.
  • Scrivi il tuo packer personalizzato . Se i packer di terze parti sono troppo costosi, prendi in considerazione di scriverne uno tuo. A volte i packer personalizzati possono essere molto efficaci, perché non esistono metodi ben pubblicati su come decomprimerli. Il tutorial su come scrivere il proprio packer fornisce moltissime informazioni utili sulla scrittura del proprio packer Win32.

Alla fine, però, se le persone vogliono che la tua applicazione venga violata, lo faranno. Guarda tutti i software commerciali là fuori che hanno una grande quantità di risorse per proteggere le loro applicazioni e tuttavia sono craccati prima ancora che le applicazioni vengano rese pubbliche.

Un esperto ingegnere inverso può avviare IDA-Pro e tagliare l'applicazione come burro, qualunque cosa tu faccia. Un'applicazione compressa può essere decompressa e l'offuscamento impedisce solo di renderla una passeggiata nel parco. Tutto il tuo duro lavoro con il tuo codice di licenza complesso può essere annullato con una patch a singolo byte.

Devi solo accettare che esiste una reale possibilità che le persone piratino il tuo software. Ci sono alcune persone che non pagheranno mai la tua domanda, non importa cosa e queste sono le persone di cui non devi preoccuparti.

Ci sono tuttavia molte aziende là fuori che non rischierebbero mai una causa e comprerebbero felicemente licenze software e molti utenti di computer che non vogliono rischiare, trovano sbagliato o non sono abbastanza esperti di tecnologia da piratare. Questi sono i tuoi veri clienti e dovresti concentrare i tuoi sforzi nel fornire loro una buona esperienza utente e ignorare le persone che violano il tuo software.

Ho già piratato la mia domanda prima e l'ho presa come un affronto personale. Ero qui, uno sviluppatore di piccole dimensioni, a riversare il mio cuore e la mia anima in un'applicazione e queste persone avevano il coraggio di piratare da me ?! Stavano prendendo soldi direttamente dalla mia tasca!

Ho immediatamente aggiunto un sacco di codice DRM draconiano e ho tentato di sabotare qualsiasi persona usando una copia illegittima o crackata. Ovviamente avrei dovuto lavorare per migliorare la mia applicazione invece di provare a fermare l'inevitabile. Non solo, ma stavo ferendo i miei veri clienti con tutte queste protezioni extra che stavo inserendo.

Dopo una lunga battaglia mi sono reso conto che stavo combattendo le maree e tutto questo tempo sprecato è stato per nulla. Ho estratto tutto il codice di telefono a casa tranne le funzioni di licenza barebone e non ho mai guardato indietro.


67
Quindi +1 che è quasi +2. Vorrei che più persone avrebbero finalmente capito che semplicemente non puoi proteggere il tuo software da un determinato aggressore.
Bombe

102
Hai raggiunto il nirvana di protezione del software: non si tratta di aggiungere ulteriore protezione, si tratta di concentrarsi sul prodotto e renderlo così buono che le persone VOGLIONO pagarlo. E per quelli che lo piratano, non avrebbero mai pagato comunque, quindi è come se non fossero mai esistiti.
Arthur Chaparyan,

6
@Arthur Chaparyan, sono d'accordo. Ci è voluto molto tempo per arrivare qui, ma finalmente ho visto la luce. Sono andato sulla strada di protezioni più restrittive e combattendo contro i cracker. Ho imparato tutto ciò che potevo sull'ingegnerizzazione inversa nel tentativo di impedire la mia.
Alla

50
Diavolo, sarei stato onorato di scoprire che qualcuno pensava che il mio software valesse la pena di essere piratato ...
Erik Forbes,

10
Quando inizi a fare affidamento sulle vendite del tuo software per gran parte delle tue entrate, le cose cambiano. Sembra che qualcuno ti stia rubando. Ho capito cosa stai dicendo però. Sono rimasto scioccato quando ho scoperto per la prima volta crepe per il mio software su siti torrent.
mmcdole,

265

Non è possibile proteggere completamente qualsiasi applicazione (gestita o meno). Se sistemi come la Playstation e l'iPad possono rompersi, laddove il fornitore controlla persino l'hardware, che speranza ha la tua app? Per fortuna, non vuoi davvero. A mio avviso, devi proteggere la tua applicazione quanto basta affinché qualcuno non possa piratare accidentalmente il tuo prodotto e non di più.

Ad esempio, se usi una licenza per macchina, non dovrebbe funzionare solo quando la installi su una nuova seconda macchina. Avrai bisogno di un buon messaggio di errore per evitare ulteriori chiamate di supporto, ma non perdere tempo extra a renderlo troppo difficile da aggirare e non colpire gli utenti con esso.

Un altro esempio è una prova a tempo limitato. Non preoccuparti nemmeno di cose semplici come se gli utenti possono semplicemente ripristinare l'orologio di sistema. Qualcuno che lo fa sa che sta violando la tua licenza e fintanto che un utente sa quando sono in violazione hai fatto abbastanza.

Devi fare molto perché agli utenti non importa della tua licenza. Le licenze sono cose inventate di cui nessuno si preoccupa fino a quando non è necessario. Nessuno li legge e non dovrebbero proprio doverlo fare. Pertanto, il modo migliore per dire all'utente dove sono i limiti è se il comportamento immediato per la propria applicazione è conforme alla licenza. In questo primo caso ciò significa che non è possibile installare o installare in modalità di prova la seconda volta. Per quest'ultimo, potrebbe significare semplicemente il controllo di una data in testo semplice in un file di configurazione. In entrambi i casi, assicurati di gestirlo in modo elegante, utile e rispettoso.

Questo spiega cosa significa fare proprio così tanto. Ma perché non andare oltre? Perché non tappare ogni piccolo buco che puoi trovare? La risposta è in due parti. In primo luogo, se qualcuno varcherà la soglia etica di infrangere consapevolmente i termini della tua licenza - anche in modo semplice - saranno anche disposti a fare qualcosa di più difficile o pericoloso come estrarre la tua applicazione da un torrentsito - e vi è un certo grado di pericolo legato all'esecuzione di applicazioni scaricate da fonti non attendibili. Renderlo più difficile è solo un piccolo fastidio per questi utenti e rischia di causare problemi con i tuoi clienti paganti. Mantenerlo semplice può impedire a qualcuno di scavare nella tua applicazione e di rilasciare una crepa più completa. In secondo luogo, hai pochi occhi disponibili per cercare difetti; gli hacker ne hanno molti e hanno più pratica nel trovarli. Devi solo perdere un piccolo difetto e la tua app avrà la stessa distribuzione sui siti dei pirati come se non avessi fatto nulla. Devi avere ragione ogni volta; devono essere fortunati solo una volta. Quindi lo sforzo richiesto è molto alto e la probabilità di qualsiasi misura di successo è molto bassa.

Alla fine, se qualcuno vuole piratare la tua applicazione (invece di usarla solo), e questo è il loro obiettivo principale, lo faranno. Non c'è niente che puoi fare per fermarli. Questa è la natura del software; una volta che i file che compongono il tuo prodotto sono sul computer di un utente saranno in grado di fare con loro come vogliono. Ciò è particolarmente rilevante in ambienti gestiti come Java o .NET , ma si applica sicuramente anche al codice nativo. Il tempo è dalla loro parte e viene concesso abbastanza tempo per impedire la sicurezza digitale.

Dal momento che non puoi impedire agli utenti di piratare il tuo prodotto, il miglior modo di agire è coinvolgere questa classe di utenti in modo da utilizzarli a tuo vantaggio. Spesso è possibile farli lavorare per te piuttosto che contro di te. Con questo in mente, indipendentemente dalla tua applicazione, probabilmente ne vale la pena mantenere una versione gratuita che è quasi completamente funzionale e non scade. La differenza tra anche un prezzo da $ 1 e gratuito è enorme, se non altro per il fatto che il cliente non deve fidarsi di te con la sua carta di credito. Un'edizione gratuita del tuo prodotto non solo ucciderà efficacemente la distribuzione piratata (perché rischiare una versione piratata quando puoi essere legittima allo stesso prezzo?), Ha il potenziale per espandere notevolmente il tuo pubblico.

Il risultato è che potrebbe essere necessario aumentare il prezzo dell'edizione for-pay, in modo che alla fine invece di 2.000 utenti a $ 20 ciascuno, si abbiano 100.000 utenti gratuiti, di cui 500 disposti a pagare $ 99 per l'edizione "professionale" . Questo ti farà guadagnare più denaro che se avessi speso un sacco di tempo a bloccare il tuo prodotto. Inoltre, puoi coinvolgere questi utenti gratuiti e sfruttare la relazione in diversi modi importanti.

Uno è il supporto. Un pessimista coglierebbe l'occasione per lamentarsi dell'aumentato costo di supporto di 100.000 utenti gratuiti, ma succede invece qualcosa di straordinario: il tuo prodotto diventa in gran parte autosufficiente. Lo vedi sempre con grandi progetti open source che non hanno soldi per i costi di supporto. Gli utenti si faranno avanti e lo faranno accadere.

Gli utenti gratuiti generalmente hanno inizialmente aspettative di supporto ridotte e per buoni motivi. Tutto quello che devi fare è contrassegnare l'edizione gratuita come qualificante solo per il supporto della comunità e creare un forum online moderato dall'utente a tale scopo. La tua base di conoscenza di supporto è auto-generante e gli utenti avanzati guideranno coloro che hanno bisogno di una mano in più per tuo conto. Ancora più importante, questo ti permetterà di identificare e correggere i bug più velocemente, migliorando in definitiva la qualità del tuo prodotto e abbassando i costi di supporto totali. Questo non era possibile prima perché la tua base di utenti non era abbastanza grande, ma quando tratti gli utenti gratuiti come clienti, può funzionare molto bene.

Un altro è il feedback. Guardando il tuo forum, impari importanti idee di miglioramento che potresti non aver mai considerato diversamente. Ciò può consentire in ultima analisi di trasformare un maggior numero di utenti gratuiti in utenti a pagamento e creare un prodotto più avvincente che attirerà un pubblico ancora più vasto.

Infine, devi considerare il marketing. Tutti questi utenti gratuiti sono ora fan piuttosto che avversari, e agiranno di conseguenza. Non solo, ma quando arriverà il momento di rilasciare la tua prossima versione, questi utenti saranno passati attraverso il tuo canale di distribuzione approvato, piuttosto che qualche altro meccanismo sconosciuto. Ciò significa che per la tua prossima versione inizi a connetterti con un pubblico più ampio, molto interessato e di supporto.

Le migliori funzionalità da prenotare per l'edizione professionale sono strumenti volti a semplificare l'implementazione e la gestione aziendale. Un cracker non li vedrà come una ragione abbastanza convincente per hackerarlo per il proprio uso, ma per un'azienda che cerca di acquistare 300 licenze e spingerlo fuori in tutta l'azienda questo è un must. Certo, l'edizione professionale sarà comunque piratata, ma ancora: non sudare perché probabilmente non saresti in grado di vendere il prodotto a quei pirati, qualunque cosa tu abbia fatto, quindi non ti costerà alcun reddito.

Mentre psicologicamente può essere difficile dare così tanto il tuo prodotto, spero che tu possa capire come sia davvero il modo migliore per andare. Non solo, è l'unico modo per andare a lungo termine. So che qualcuno è là fuori a pensare che non vogliono farlo in questo modo. Dopotutto, hanno ottenuto vendendo il loro prodotto bloccato da $ 20 per anni. Ma è semplicemente un peccato, perché se non lo fai in questo modo, alla fine lo farà qualcun altro . E il loro prodotto sarà buono come il tuo, o abbastanza vicino da riuscire a farcela. Quindi all'improvviso i tuoi prezzi sembrano scandalosi, le vendite calano drasticamente e non c'è nient'altro che puoi fare. Puoi optare per un livello intermedio aggiuntivo se necessario, ma è improbabile che ti aiuti.


1
@Learning: è cresciuto nel tempo e ha superato la conversione automatica in soglia CW.
Joel Coehoorn,

1
+1 Meglio della risposta che ho dato alla versione precedente di questa domanda. @Joel Non sapevo che ci fosse un limite.
pipTheGeek,

1
Non sono completamente d'accordo con tutto qui, ed è comunque un +1 facile per la presentazione e l'argomento estremamente ben ponderati.
Beska,

2
Buona argomentazione, ma manca un punto sulla protezione della proprietà intellettuale. Se la tua app ha del codice che fa qualcosa di piuttosto complesso, l'offuscamento può fare la differenza tra copia e incolla del codice e provare a interpretare e riprogettare il codice in modo che funzioni. Ciò è particolarmente importante con gli aggiornamenti: se qualcuno ha copiato il tuo codice offuscato, quando rilasci un aggiornamento, lo devono ripetere ancora una volta - e per lo meno, causa loro più dolore / spese / tempo. Se non lo hai protetto in qualche modo, copia e incolla di nuovo e funziona.
Gregreg

4
Ottimo post - entra davvero nei dettagli giusti sui motivi per cui non vale la pena preoccuparsi di scrivere una complessa protezione dalla copia. Anche se la domanda è un duplicato, vale la pena riaprirla solo per questa risposta. Forse una mod può unirla?
EMP,

45

Nella mia esperienza, rendere la tua applicazione o libreria più difficile da decifrare fa male ai tuoi clienti onesti, ritardando solo leggermente quelli disonesti. Concentrati sulla realizzazione di un ottimo prodotto a basso attrito invece di fare un grande sforzo per ritardare l'inevitabile.


38

Un segreto che condividi con molte persone non è un segreto. Se hai cose segrete nel tuo codice, offuscarle non è una protezione; deve essere deo-offuscato solo una volta . Se hai un segreto che non vuoi condividere con i tuoi clienti, non condividerlo con i tuoi clienti . Scrivi il tuo codice come servizio web e mantieni il tuo codice super segreto sul tuo server, dove solo tu puoi vederlo.


1
Tra l'altro sto facendo un progetto in cui voglio attivare anche un prodotto "offline" (ho realizzato un servizio WCF per renderlo attivo online). In questo caso come manipolerai il codice? puoi darmi dei successi?
Piyush,

1
Un'idea interessante, ma quale linea di condotta consiglieresti a qualcuno che sviluppa un'applicazione che deve essere eseguita senza una connessione dati, come un gioco WP7?
Charlie Skilbeck,

23

In generale, ci sono tre gruppi di persone là fuori.

  • Coloro che non acquistano il tuo software e ricorrono a crepe, o se non ne trovano, non usano affatto il tuo software. Non aspettarti di fare soldi da questo gruppo. Si basano sulle proprie capacità o sui cracker (che tendono a dare la priorità al loro tempo a seconda del tuo utile e di quanto sia grande il tuo pubblico. Più utile, prima sarà disponibile un crack).

  • Il gruppo di utenti legittimi che acquisteranno (pagheranno) il tuo software, indipendentemente dal meccanismo di protezione che utilizzi. Non rendere la vita difficile per i tuoi utenti legittimi utilizzando un meccanismo di protezione elaborato poiché lo pagheranno comunque. Un meccanismo di protezione complesso può facilmente rovinare l'esperienza dell'utente e non vuoi che ciò accada a questo gruppo. Personalmente, voterei contro qualsiasi soluzione hardware, il che aumenta il costo del tuo software.

  • Una minoranza che ricorrerà a cracking "non etico" e pagherà solo per il tuo software perché le sue funzionalità sono protette da un meccanismo di licenza. Probabilmente non vorrai rendere estremamente facile per questo gruppo eludere la tua protezione. Tuttavia, tutto lo sforzo che spendi per proteggere il tuo software ripagherà, a seconda di quanto sia grande questo gruppo di persone. Questo dipende interamente dal tipo di software che stai costruendo.

Alla luce di ciò che hai detto, se ritieni che ci sia una minoranza abbastanza grande che può essere spinta ad acquistare il tuo software, vai avanti e implementa una qualche forma di protezione. Pensa a quanti soldi puoi guadagnare da questa minoranza rispetto al tempo speso lavorando sulla protezione o all'importo che spendi in un'API / strumento di protezione di terze parti.

Se ti piace implementare una soluzione tutta tua, usare la crittografia a chiave pubblica è un buon modo (al contrario degli algoritmi simmetrici) per prevenire hack facili. Ad esempio, è possibile firmare digitalmente la propria licenza (numero di serie o file di licenza). L'unico modo per aggirare questo sarebbe quindi di decompilare, alterare e ricompilare il codice (che potresti rendere più difficile usando tecniche come quelle suggerite nella risposta di Simucal).


L'uso della crittografia avanzata per proteggere / verificare che le licenze siano completamente inutili se qualcuno strappa il codice che interrompe l'applicazione se la licenza non viene verificata. :)
Bombe

D'accordo, ma come stavo dicendo, la protezione non è per quei gruppi di utenti che ricorrono all'uso di crepe (supponendo che io abbia fatto esisterà).
Mistico

crittografia a chiave pubblica = crittografia asimmetrica. Penso che intendevi simmetrico.
mmcdole,

1
Ad essere onesti, il terzo punto è parziale in quanto presuppone che una parte delle persone sia sempre una minoranza. Sono abbastanza sicuro che in certi contesti sia una chiara maggioranza. Ho in mente giochi online con funzionalità multiplayer massiccia perché a) la maggior parte degli utenti sono bambini con standard etici molto bassi b) il costo può essere significativo per quegli utenti se si tratta di una tariffa mensile che trascina per mesi ecc.
j riv

19

Non puoi impedire alle persone di decifrare il tuo software.

Tuttavia, puoi farli creare crepe che danneggeranno di meno le tue vendite. I keygenerator che possono emettere un codice di registrazione valido per il tuo software sono molto peggio delle semplici patch che rimuovono gli incentivi per la registrazione dal tuo software. Questo perché una crepa funzionerà solo per una versione del software e cesserà di funzionare con il prossimo aggiornamento software rilasciato. Il generatore di chiavi continuerà a funzionare fino a quando non cambi l'algoritmo della chiave di registrazione e questo è qualcosa che non vuoi fare spesso perché rimanderà i tuoi clienti onesti.

Quindi, se stai cercando un metodo per combattere i keygenerator illegali per il tuo software e non vuoi usare la crittografia assimetrica a causa dei lunghi codici di registrazione generati, potresti dare un'occhiata alla verifica della chiave parziale.

La verifica parziale delle chiavi garantisce che ciascun generatore di chiavi illegale funzioni solo per una determinata versione del software. Fondamentalmente quello che fai è assicurarti che ogni versione del tuo software si colleghi solo al codice per controllare ALCUNE cifre del codice di registrazione. Quali cifre sono esattamente casuali, quindi i cracker dovrebbero decodificare molte versioni diverse del tuo software e combinare tutto questo in un generatore di chiavi per rilasciare un generatore di chiavi che funzioni per tutte le versioni del tuo software.

Se rilasci nuove versioni di software su base regolare, questo porta a numerosi generatori di chiavi diffusi su tutti i tipi di archivi di pirateria software che non funzionano più. I potenziali pirati del software di solito cercano una crepa o keygen per l'ultima versione, quindi probabilmente ne proveranno alcuni e alla fine si arrenderanno.

Ho usato la verifica parziale della chiave nei miei giochi shareware (C ++) più recenti ed è stato molto efficace. Prima avevamo molti problemi con i keygenerator che non potevamo combattere. Successivamente ci furono molte crepe e alcuni generatori di chiavi che funzionarono solo per quella particolare versione del gioco, ma nessun generatore di chiavi che avrebbe funzionato con tutte le versioni. Rilasciavamo regolarmente aggiornamenti molto minori del gioco e rendevamo inutili tutte le crepe esistenti in precedenza.

Sembra che ci sia un framework .NET open source per la verifica della chiave parziale , anche se non l'ho provato.


1
come l'idea, puoi anche usare password diverse per la crittografia assimetrica in diverse versioni.
Priyank Bolia,

Un'idea interessante, ma qual è esattamente il problema con un lungo codice di registrazione, comunque? Al giorno d'oggi nessuno lo avrebbe inserito a mano comunque: tutti lo avrebbero copiato e incollato, quindi che siano 10 caratteri o 100 caratteri non dovrebbe fare alcuna differenza.
EMP,

4
@Evgeny: è vero solo se i tuoi utenti sono utenti esperti. Da molti anni creiamo shareware / giochi casuali e posso dirti che la maggior parte dei nostri utenti non può copiare e incollare. La finestra di registrazione include anche un manuale su come copiare e incollare, e alcuni addirittura non lo fanno dopo averlo letto.
Adrian Grigore,

Wow! OK, beh, ovviamente hai più esperienza di me in questo, quindi non posso discutere, posso solo dire che sono sorpreso. Ma direi che se non sanno come copiare e incollare, dovresti allungare il codice di 200 caratteri, in modo che imparino un'abilità informatica generale molto utile. :)
EMP,

1
@Evgeny: Anche con i codici di registrazione brevi, abbiamo ancora ricevuto molte e-mail da persone che hanno sbagliato a digitare i loro codici e quindi hanno pensato che il codice non potesse essere valido perché non avrebbero mai commesso un errore come questo più volte in un riga. Preferisco lasciare l'insegnamento dell'IT ad altre aziende ... :-)
Adrian Grigore il

16
  • Usa l'aggiornamento online per bloccare quelle copie senza licenza.

  • Verifica il numero seriale da diversi moduli dell'applicazione e non utilizzare una singola chiamata di funzione per eseguire la verifica (in modo che i cracker non possano ignorare facilmente la verifica).

  • Non solo controlla il numero seriale all'avvio, esegui la verifica durante il salvataggio dei dati, fallo ogni venerdì sera, fallo quando l'utente è inattivo ...

  • Verifica la somma del controllo del file dell'applicazione, archivia la somma del controllo di sicurezza in luoghi diversi.

  • Non andare troppo lontano su questo tipo di trucchi, assicurati che la tua applicazione non si blocchi mai o non funzioni correttamente durante la verifica del codice di registrazione.

  • Costruire un'app utile per gli utenti è molto più importante che creare un
    binario indistruttibile per i cracker.


14

Puoi..

Servizi Microsoft SLP Il potenziale software di InishTech offre la possibilità di proteggere il codice senza influire sulla funzionalità delle applicazioni.

AGGIORNAMENTO: (Divulgazione: lavoro su Eazfuscator.NET) Ciò che differenzia il potenziale del software dei servizi SLP di Microsoft è la possibilità di virtualizzare il codice, quindi sicuramente puoi . Passarono diversi anni da quando la domanda fu inizialmente posta; oggi ci sono più prodotti disponibili che funzionano anche su una base simile come:


2
prezzi amico mio, l'acquisto di un software di licenza da Microsoft è troppo costoso per il normale ISV
Priyank Bolia,

L'ho provato, funziona molto bene ma crittografa solo il codice all'interno di un metodo, non l'intero assembly o progetto, quindi un cracker può facilmente modificare il flusso del programma con l'iniezione IL
Mohsen Afshin,

@ogggre Se aggiungi i link dei fornitori, devi davvero rivelare le tue connessioni nel post. Anche la versione attualmente disponibile di SLPS (che io lavoro su: D) fa generici di supporto. Naturalmente tutte le soluzioni hanno i loro pro e contro individuali che solo una valutazione può adeguatamente contestualizzare per le persone
Ruben Bartelink,

@MohsenAfshin Non capisco cosa stai dicendo: il punto è che devi proteggere tutti i metodi in cui l'aggiunta / rimozione / modifica di IL rappresenterebbe una violazione della licenza. Poiché la virtualizzazione delle cose non può essere libera, semplicemente non ha senso "proteggere magicamente tutto" come stai suggerendo. Torniamo al punto chiave: lo scopo di SP's Protection è quello di prevenire i cambiamenti IL sui metodi che selezioni sulla base della loro sensibilità (più in generale alcuni altri come rumore per evitare di piantare un che devi rompere questo bit qui -> segno )
Ruben Bartelink,

1
@RubenBartelink Sono d'accordo con te. Sfortunatamente questa discussione è troppo grande con diverse pagine di contenuti. All'inizio volevo aggiungere una nuova risposta, ma StackOverflow ha suggerito che è meglio estendere quella esistente. Così ho fatto. Spero che la mia piccola informazione sia utile. Grazie per un aggiornamento sul supporto generico in SLPS e le tue correzioni.
ogggre

10

.NET Reflector può aprire solo "codice gestito" che sostanzialmente significa "codice .NET". Quindi non puoi usarlo per disassemblare file COM COM, C ++ nativo, codice Visual Basic 6.0 classico , ecc. La struttura del codice .NET compilato lo rende molto conveniente, portatile, rilevabile, verificabile, ecc. .NET Reflector sfrutta i vantaggi di questo per permetterti di scrutare gli assiemi compilati ma i decompilatori e i disassemblatori non sono affatto specifici di .NET e sono in circolazione da quando esistono i compilatori.

Puoi usare gli offuscatori per rendere il codice più difficile da leggere, ma non puoi impedire che venga decompilato senza renderlo illeggibile per .NET. Ci sono una manciata di prodotti là fuori (di solito costosi) che pretendono di "collegare" l'applicazione di codice gestito a un'applicazione di codice nativo, ma anche se questi effettivamente funzionano, una persona determinata troverà sempre un modo.

Quando si tratta di offuscamento, tuttavia, ottieni ciò per cui paghi. Quindi, se il tuo codice è così proprietario che devi fare di tutto per proteggerlo, dovresti essere disposto a investire denaro in un buon offuscatore.

Tuttavia, in circa 15 anni di esperienza nella scrittura di codice, mi sono reso conto che l'eccessiva protezione del codice sorgente è una perdita di tempo e ha pochi vantaggi. Cercare di leggere il codice sorgente originale senza supportare documentazione, commenti, ecc. Può essere molto difficile da capire. Aggiungete a ciò i nomi variabili insensati che vengono decompilatori e il codice spaghetti che creano gli offuscatori moderni - probabilmente non dovrete preoccuparvi troppo delle persone che rubano la vostra proprietà intellettuale.


9

Ne vale davvero la pena? Ogni meccanismo di protezione può essere rotto con sufficiente determinazione. Considera il tuo mercato, il prezzo del prodotto, la quantità di clienti, ecc.

Se vuoi qualcosa di più affidabile, segui il percorso delle chiavi hardware, ma è piuttosto problematico (per l'utente) e più costoso. Le soluzioni software sarebbero probabilmente una perdita di tempo e risorse e l'unica cosa che ti darebbero è il falso senso di "sicurezza".

Poche altre idee (nessuna è perfetta, in quanto non esiste una perfetta).

  • AntiDuplicate
  • Cambia la lingua, usa i simpatici trucchi usati dagli autori di Skype
  • Server di licenza

E non perdere troppo tempo, perché i cracker hanno molta esperienza con le tecniche tipiche e sono pochi passi avanti a te. A meno che tu non voglia usare molte risorse, probabilmente cambia il linguaggio di programmazione (fallo in modo Skype).


Non dimenticare che è del tutto possibile attaccare la parte software del blocco hardware.
Magnus Hoff,

Sì, è vero, l'unica vera opzione sarebbe quella di avere l'applicazione parzialmente implementata nell'hardware (qualche strano mix di software-VHDL ad esempio). Anche questo sarebbe crackabile ...
Anonimo

Che dire dei dongle che implementano una strategia di chiave pubblica / privata. Solo la chiave privata della chiave hardware può decrittografare l'applicazione ed eseguirla.
mmcdole,

Questo è ciò che fa di solito la chiave hardware. Ma puoi attaccare il dongle: clonalo o il software responsabile per parlare con il dongle (eludere, disabilitare, ecc.).
Anonimo

1
Nel mio caso ne è valsa davvero la pena. Dopo aver implementato la verifica parziale delle chiavi e modificato lo schema delle chiavi di registrazione per un prodotto esistente, le vendite sono aumentate in modo significativo. Tutto il software può essere decifrato, la domanda è quanto in alto alzi il livello per il pirata informale del software.
Adrian Grigore,

9

Se vuoi che le persone siano in grado di eseguire il tuo codice (e in caso contrario, perché l'hai scritto in primo luogo?), Allora la loro CPU deve essere in grado di eseguire il tuo codice. Per poter eseguire il codice, la CPU deve essere in grado di capirlo .

Dato che le CPU sono stupide, e gli umani no, questo significa che anche gli umani possono capire il codice.

C'è solo un modo per assicurarsi che i tuoi utenti non ottengano il tuo codice: non dare loro il tuo codice.

Ciò può essere ottenuto in due modi: Software as a service (SaaS), che è, si esegue il software sul vostro server e lasciare solo agli utenti di accedere in remoto. Questo è il modello utilizzato da Stack Overflow, ad esempio. Sono abbastanza sicuro che Stack Overflow non offusca il loro codice, ma non puoi decompilarlo.

L'altro modo è il modello dell'appliance: invece di fornire il tuo codice agli utenti, dai loro un computer contenente il codice. Questo è il modello utilizzato dalle console di gioco, dalla maggior parte dei telefoni cellulari e TiVo . Nota che questo funziona solo se "possiedi" l'intero percorso di esecuzione: devi costruire la tua CPU, il tuo computer, scrivere il tuo sistema operativo e la tua implementazione CLI . Quindi, e solo allora puoi proteggere il tuo codice. (Ma nota che anche il più piccolo errore renderà inutili tutte le tue protezioni. Microsoft, Apple, Sony, l'industria musicale e l'industria cinematografica possono attestarlo.)

Oppure, non potresti fare nulla, il che significa che il tuo codice sarà automaticamente protetto dalla legge sul copyright.


8

Sfortunatamente, non scapperai da questo. La soluzione migliore è scrivere il codice in C e P / Richiamarlo .

C'è un piccolo catch-22, qualcuno potrebbe semplicemente decompilare la tua applicazione in CIL ed eliminare qualsiasi codice di verifica / attivazione (ad esempio, la chiamata alla tua libreria C). Ricorda che le applicazioni scritte in C sono anch'esse retroingegnerizzate dagli hacker più persistenti (guarda quanto velocemente i giochi vengono decifrati in questi giorni). Nulla proteggerà la tua applicazione.

Alla fine funziona molto come la tua casa, proteggila abbastanza bene da essere troppo sforzo (il codice spaghetti sarebbe di aiuto qui) e in modo che l'aggressore si sposterà sul tuo vicino di casa (concorrenza :)). Guarda Windows Vista, ci devono essere 10 modi diversi per decifrarlo.

Esistono pacchetti che crittografano il file EXE e lo decrittografano quando l'utente è autorizzato a utilizzarlo, ma ancora una volta utilizza una soluzione generica che senza dubbio è stata decifrata.

I meccanismi di attivazione e registrazione sono rivolti al "Joe medio:" persone che non hanno abbastanza esperti di tecnologia per bypassarlo (o per questo sanno che possono bypassarlo). Non preoccuparti dei cracker, hanno troppo tempo a disposizione.


1
Se ti preoccupi davvero di esternalizzare il tuo codice di registrazione in una dll, dovresti assicurarti che la DLL debba essere diversa con ogni nuova versione del tuo software. Altrimenti stai rendendo ancora più facile per le persone decifrare il tuo software. Tutto quello che dovrebbero fare è rompere la tua DLL una volta e usarla per tutte le versioni successive. Anche gli utenti finali potrebbero farlo una volta trovata una vecchia DLL incrinata, e questo è anche peggio che inserire il meccanismo di registrazione nel codice gestito.
Adrian Grigore,

8

Oltre alla protezione dell'acquisto, tu (o i tuoi sviluppatori) potete imparare a proteggere dalla copia.

Queste sono idee:

Inizialmente, prova a scrivere un programma che si scrive sulla console. Questo è un problema famoso. Lo scopo principale di questa attività è esercitarsi a scrivere codice autoreferenziale.

In secondo luogo, è necessario sviluppare una tecnologia che riscriva un po 'di codice in modo affidabile dal CIL di altri metodi .

Puoi scrivere una macchina virtuale (ancora in .NET ). E mettici dentro un po 'di codice. Alla fine, la macchina virtuale esegue un'altra macchina virtuale che esegue il codice. Questo è per una parte delle funzioni chiamate raramente per non rallentare troppo le prestazioni.

Riscrivi un po 'di logica in C ++ / CLI e mescola il codice gestito con non gestito. Questo indurirà lo smontaggio. In questo caso, non dimenticare di fornire anche binari x64 .


non ho capito puoi spiegarlo in dettaglio.
Priyank Bolia,

7

Sì. È vero. Il codice .NET è estremamente facile da decodificare se il codice non è offuscato.

L'offuscamento aggiungerà uno strato di fastidio alle persone che cercano di decodificare il software. A seconda della versione che ottieni, otterrai diversi livelli di protezione.

Visual Studio include una versione di Dotfuscator . Dal momento che è una versione in bundle, sicuramente non stai ottenendo il più forte offuscamento possibile. Se guardi i loro elenchi di funzionalità, vedrai esattamente ciò che ti manca (e esattamente cosa farà l'applicazione per rendere il tuo codice più sicuro).

Esistono un paio di altri offuscatori .NET gratuiti o open source (ma non posso commentare la qualità o i vari metodi che usano):

Alla fine, niente è perfetto. Se qualcuno vuole davvero vedere come funziona il tuo software, lo faranno.


11
Non è solo "se vogliono davvero vedere come funziona il tuo software, lo faranno". Se a loro importa, probabilmente possono indovinare senza guardare. Il 99,9% + di software non ha algoritmi di polvere magica di folletti. La parte difficile della programmazione non è una speciale tecnica segreta. Sta solo facendo in modo che tutte le parti si allineino e funzionino.
Ken,

9
@Ken - Shhhh! Non puoi far sapere al resto del mondo che la maggior parte delle volte non stiamo usando algoritmi di polvere magica di folletti.
Justin Niessner

9
Justin: L'amore conta come un algoritmo magico? L'amore è ciò che rende speciali i miei programmi. Non penso che tu possa smontare Amore.
Ken,

Babel.NET non è più gratuito. Puoi trovare un elenco degli offuscatori più comuni (gratuiti e commerciali) qui .
InputOutput

6

Bene, non puoi COMPLETAMENTE proteggere il tuo prodotto da crack, ma puoi massimizzare / migliorare i livelli di sicurezza e renderlo un po 'troppo difficile per essere crackato da principianti e cracker intermedi.

Ma tieni presente che nulla è irrefrenabile, solo il software sul lato server è ben protetto e non può essere crackato. Ad ogni modo, per migliorare i livelli di sicurezza nella tua applicazione, puoi fare alcuni semplici passi per impedire ad alcuni cracker "non tutti" di craccare le tue applicazioni. Questi passaggi faranno impazzire questi cracker e forse disperati:

  • Offusca il tuo codice sorgente, ovviamente questo renderà il tuo codice sorgente un disastro e illeggibile.
  • Attiva diverse routine di controllo casuale all'interno dell'applicazione come ogni due ore, 24 ore, un giorno, settimana, ecc. O forse dopo ogni azione intrapresa dall'utente.
  • Salvare il checksum MD5 dell'applicazione rilasciata sul server e implementare una routine in grado di verificare il checksum MD5 del file corrente con quello reale sul lato server e attivarlo in modo casuale. Se il checksum MD5 è stato modificato, significa che questa copia è stata piratata. Ora puoi semplicemente bloccarlo o rilasciare un aggiornamento per bloccarlo, ecc.
  • Prova a creare una routine in grado di verificare se alcuni dei tuoi codici (funzioni, classi o routine specifiche) sono stati effettivamente modificati o alterati o addirittura rimossi. Lo chiamo (verifica dell'integrità del codice).
  • Usa packer sconosciuti gratuiti per imballare la tua applicazione. Oppure, se hai i soldi, scegli soluzioni commerciali come Thamida o .NET Reactor . Tali applicazioni vengono aggiornate regolarmente e una volta decompresso un cracker dell'applicazione, è possibile ottenere un nuovo aggiornamento da tali società e, una volta ottenuto il nuovo aggiornamento, è sufficiente impacchettare il programma e rilasciare un nuovo aggiornamento.
  • Rilascia regolarmente gli aggiornamenti e forza il tuo cliente a scaricare l'ultimo aggiornamento.
  • Finalmente rendi la tua applicazione molto economica. Non renderlo troppo costoso. Credetemi, otterrete clienti più felici e i cracker lasceranno semplicemente la vostra applicazione, perché non vale la pena spendere una domanda molto economica.

Questi sono solo metodi semplici per impedire ai neofiti e ai cracker intermedi di violare l'applicazione. Se hai altre idee per proteggere la tua applicazione, non essere timido nel metterle in atto. Farà solo durare vite ai cracker, e si sentiranno frustrati, e alla fine lasceranno la tua applicazione, perché non vale la pena.

Infine, devi anche considerare di dedicare il tuo tempo alla programmazione di applicazioni valide e di qualità. Non perdere tempo a codificare complicati livelli di sicurezza. Se un buon cracker vuole decifrare la sua domanda, farà qualsiasi cosa tu faccia ...

Ora vai e implementa alcuni giocattoli per i cracker ...


5

C'è Salamander , che è un compilatore e linker .NET nativo di Remotesoft in grado di distribuire applicazioni senza il framework .NET. Non so quanto sia all'altezza delle sue affermazioni.


La risposta è abbastanza semplice: è un peccato che la maggior parte delle risposte parli di offuscamento. L'offuscamento è utile per fermare il primo tentativo (simile a quello di un riflettore) di cercare nel tuo codice, tutto qui. Questo non è male. E ovviamente non c'è nulla che fermi i veri hacker che capiscono il codice assembly, oltre a scrivere un'applicazione SAAS (anche allora possono provare a hackerare il tuo server). Ma c'è di più, ci sono strumenti come Salamander, .NET Reactor e un altro citato, che forniscono (forse) quasi lo stesso modulo di sicurezza non compilando un Win32 .exe compilato in C ++. Quale di questi strumenti sia il migliore, non posso ancora giudicare.
Philm,

5

Se Microsoft potesse trovare una soluzione, non avremo versioni piratate di Windows, quindi nulla è molto sicuro. Ecco alcune domande simili da Stack Overflow e puoi implementare il tuo modo di proteggerle. Se stai rilasciando versioni diverse, allora puoi adottare tecniche diverse per versione diversa, quindi quando la prima viene violata la seconda può prendere il controllo.


5

.NET Reactor

Aggiornare

Jared ha sottolineato che de4dot afferma di essere in grado di decompilarlo.

.NET Reactor fornisce una protezione completa per la tua proprietà intellettuale sensibile convertendo i tuoi assiemi .NET in processi non gestiti che non possono essere compresi come CIL e che nessuno strumento esistente può decompilare. Gli hacker non hanno accesso a nessuna forma intelligibile della tua fonte.

Potenti e flessibili, le funzionalità di licenza di .NET Reactor consentono di applicare le condizioni di licenza e proteggere il flusso di entrate utilizzando blocchi hardware e software. Il gestore delle licenze può creare licenze di prova o permanenti in pochi secondi. Un kit di sviluppo software (SDK) completamente documentato, completo di esempi, consente di chiamare il sistema di licenze direttamente dal proprio codice, consentendo di creare estensioni personalizzate al sistema di licenze.


3
Ho provato a contattare quei ragazzi con qualche domanda, avevo del loro prodotto, ma non hanno mai risposto. Hai provato il loro prodotto. Sono andato con l'assemblaggio intelligente e sia il loro prodotto che il supporto sono molto buoni. Ma come ho già detto nella domanda, l'offuscamento è un modo, ma non la prova completa.
Priyank Bolia,

1
Ho avuto alcuni problemi con il loro prodotto in precedenza e poi ho posto alcune domande relative alle icone ad alta risoluzione in groups.google.se/group/net-reactor-users e ho ricevuto una risposta e una correzione, ma ora sembra che siano difficili da ottenere. Peccato - è un ottimo prodotto e lo sto ancora usando
Loraderon,

2
Se "nessuno strumento esistente può decompilare", perché è elencato come offuscatore / packer supportato nella pagina delle funzionalità di de4dot
Jared Thirsk,

Probabilmente perché è una vecchia affermazione e non hanno aggiornato la loro pagina web. Non sono più un utente di nessuno strumento di offuscamento.
Loraderon,

de4dot è uno strumento molto potente. L'ho provato contro diversi offuscatori e fa un ottimo lavoro. Tuttavia, non è stato in grado di gestire i file protetti .NET Reactor (v6.0). Forse de4dot non è aggiornato.
InputOutput

4

Ecco un'idea: potresti avere un server ospitato dalla tua azienda a cui tutte le istanze del tuo software devono connettersi. Semplicemente collegarli e verificare che una chiave di registrazione non sia sufficiente: rimuoveranno semplicemente il segno di spunta. Oltre al controllo delle chiavi, è necessario che il server esegua alcune attività vitali che il client non può eseguire da solo, quindi è impossibile rimuoverlo. Questo ovviamente significherebbe probabilmente molta elaborazione pesante da parte del tuo server, ma renderebbe difficile rubare il tuo software, e supponendo che tu abbia un buon schema di chiavi (controlla la proprietà, ecc.), Le chiavi saranno anche difficili da rubare. Questo è probabilmente più invasivo di quanto tu voglia, poiché richiederà ai tuoi utenti di essere connesso a Internet per usare il tuo software.


5
cosa succede se il server è inattivo o gli utenti non hanno sempre accesso a Internet, il tuo metodo frustrerà semplicemente i clienti avendo così tanti frequenti viaggi di andata e ritorno sui server Internet solo per usare un'app.
Priyank Bolia,

Sono completamente d'accordo. Ecco perché ho detto "questo è probabilmente più invasivo di quanto tu voglia ..." nella mia ultima riga. Stavo solo offrendo all'OP la migliore soluzione che pensavo fosse tecnicamente fattibile, non l'approccio migliore per rendere felici i clienti :)
rmeador

Nel primo trimestre del 2010 (diversi mesi dopo la stesura di questa risposta), la società di sviluppo di giochi Ubisoft ci ha provato, e apparentemente il carico sui componenti lato server era così grande che i giochi non erano giocabili. Impressione generale del SW: "fastidio da installare, non utilizzabile offline, invasivo e inaffidabile ". Quindi, se dovessi decidere che l'elaborazione sul lato server è la strada da percorrere, assicurati di poter effettivamente ridimensionare su richiesta.
Piskvor lasciò l'edificio il

3

Qualunque cosa in esecuzione sul client può essere decompilata e decifrata. L'obfusificazione rende solo più difficile. Non conosco la tua candidatura, ma il 99% delle volte non penso che valga la pena.


3

Spiacente, è impossibile proteggere completamente un'applicazione.



2

Tieni presente che oltre il 99% dei tuoi utenti non sarà interessato a esaminare il tuo eseguibile per vedere come funziona.

Dato che così poche persone si preoccuperanno persino di provare e che la maggior parte degli offuscatori può essere aggirata, vale la pena il tuo tempo e il tuo sforzo?

Faresti meglio a investire il tempo per migliorare il tuo prodotto in modo che più persone lo vogliano utilizzare.


2

Solo per aggiungere un avvertimento: se hai intenzione di usare l'offuscamento, controlla che tutto funzioni ancora! L'offuscamento potrebbe cambiare cose come nomi di classi e metodi. Quindi, se usi la reflection per chiamare determinati metodi e / o classi (come in un'architettura plug-in), la tua applicazione potrebbe fallire dopo l'offuscamento. Anche stacktraces potrebbe essere inutile per rintracciare gli errori.


2

Se è scritto in .NET e compilato in CIL , può essere riflesso. Se la sicurezza è un problema e si deve evitare l'offuscamento, allora si consiglia di scrivere l'applicazione utilizzando un linguaggio non gestito, che è, per sua natura, più difficile da decodificare.


2

Come assicurarsi che l'applicazione non sia manomessa e come assicurarsi che il meccanismo di registrazione non possa essere retroingegnerizzato.

Entrambi hanno la stessa risposta molto semplice: non distribuire il codice oggetto a soggetti non attendibili, come (apparentemente) i tuoi clienti. Il fatto che sia possibile ospitare l'applicazione sui tuoi computer dipende solo da ciò che fa.

Se non è un'applicazione Web , forse puoi consentire l' accesso SSH con l'inoltro X a un server delle applicazioni (o Connessione desktop remoto , suppongo, per Windows).

Se dai il codice oggetto a persone di tipo nerd, e pensano che il tuo programma possa essere divertente da decifrare, verrà decifrato. Assolutamente no.

Se non mi credi, segnala un'applicazione di alto profilo che non è stata crackata e piratata.

Se vai con le chiavi hardware, renderà la produzione più costosa e i tuoi utenti ti odieranno per questo. È una vera cagna gattonare sul pavimento collegando e scollegando le tue 27 cose USB diverse perché i produttori di software non si fidano di te (immagino).

Esistono pacchetti che crittografano il tuo EXE e lo decrittografano quando l'utente è autorizzato a usarlo

Ovviamente, il modo per aggirarlo è quello di rompere il test "posso-io-uso-esso" in modo che ritorni sempre vero.

Un brutto trucco potrebbe essere quello di utilizzare i valori di byte degli opcode che eseguono il test da qualche altra parte nel programma in modo sporco che causerà il crash del programma con alta probabilità a meno che il valore non sia giusto. Ti rende collegato a una particolare architettura, però :-(


non è facile eseguire il debug di un punto di arresto anomalo e sovrascrivere il codice in .NET per ignorare tale controllo. Inoltre, come modificherai gli opcode in .NET, puoi approfondire questo?
Priyank Bolia,

Oh. Avevo in mente i trucchi di C; diciamo, prendi l'indirizzo della funzione di validazione, aggiungi i primi 10 byte in quell'array char (lancia il puntatore alla funzione); scegli una qualsiasi funzione f e memorizza [l'indirizzo di f meno la somma precedente] in fptr. Chiama sempre f come * (fptr + quella somma). Calcola "quella somma"
Jonas Kölker il

2

Basta fare una buona applicazione e codificare un semplice sistema di protezione. Non importa quale protezione scegli, verrà invertita ... Quindi non perdere troppo tempo / denaro.


2

Quando si tratta di .NET, se si sta rilasciando un'applicazione Windows Form (o qualsiasi applicazione in cui il client ha il file eseguibile portatile), è possibile eseguire il cracking.

Se si desidera attenersi a .NET e ridurre al minimo la possibilità di ricevere il codice sorgente, è possibile prendere in considerazione la distribuzione come applicazione ASP.NET su un server Web, anziché trasformarla in un'applicazione Windows Form.


2

Francamente, a volte è necessario offuscare il codice (ad esempio, registrare le classi di licenza e così via). In questo caso, il tuo progetto non è gratuito. IMO, dovresti pagare per un buon obfucator.

Dotfuscator nasconde il codice e .NET Reflector mostra un errore quando si tenta di decompilarlo.


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.