Protezione del software per piccoli fornitori

Question

Questo è un problema che tutti noi dobbiamo considerare ad un certo punto.

Dopo molti anni e molti approcci, tendo a concordare in generale con la staterment: " Per qualsiasi software protetto utilizzato da più di qualche centinaio di persone, puoi trovare una versione crackata. Finora, ogni schema di protezione può essere manomesso. & Quot; Il tuo datore di lavoro impone l'uso di software antipirateria?

Inoltre, ogni volta che posterò su questo argomento, qualcuno me lo ricorderà; "Prima di tutto, indipendentemente dal tipo di protezione che impiegherai, un cracker veramente dedicato alla fine supererà tutte le barriere protettive." Qual è il miglior rapporto qualità-prezzo protezione del codice c # per un singolo sviluppatore

Quindi, nonostante questi due disclaimer in senso lato, parliamo di " protezione " ;!

Sento ancora che per le app più piccole che è improbabile che guadagnino tempo e attenzione da un esperto cracker, la protezione È un esercizio utile.

Sembra ovvio che, qualunque cosa tu faccia, se il cracker può cambiare il risultato di un'istruzione IF (jmp) rattoppando l'applicazione, allora tutte le password e le chiavi del mondo non saranno di aiuto.

Quindi il mio approccio è stato quello di offuscare il codice con la virtualizzazione usando prodotti come: http://www.oreans.com/codevirtualizer.php Sono stato molto contento di questo prodotto. Per quanto ne sappia, è stata sconfitta. Posso persino comprimere l'eseguibile con PEcompact Qualcun altro ha esperienza con esso?

Non ho avuto altro che problemi con EXEcryptor http://www.strongbit.com/news.asp Anche il sito è un mal di testa da usare. Le app compilate si arresterebbero in modo anomalo quando si eseguono chiamate WMI.

Questo approccio consente di circondare sezioni più piccole di codice con l'offuscamento e quindi proteggere il controllo di sicurezza ecc.

Uso l'approccio di autorizzazione online, poiché l'applicazione necessita regolarmente di dati dal server, quindi non ha senso per l'utente utilizzarlo off-line per lunghi periodi. Per definizione, l'app è inutile a quel punto, anche se è crackata.

Quindi una semplice stretta di mano crittografata è molto buona. Lo controllo solo occasionalmente all'interno della protezione offuscata. Se l'utente installa l'app su un altro computer, un nuovo ID viene caricato all'avvio e il server disattiva il vecchio ID e restituisce una nuova autorizzazione.

Uso anche un hash dell'app compilata e lo controllo all'avvio per vedere se un singolo bit è cambiato, quindi apro l'app come file (con un BLOCCO di lettura) dall'interno dell'app per impedire a chiunque di cambiarlo una volta avviato .

Poiché tutte le stringhe statiche sono chiaramente visibili nel file .exe, provo ad essere generico con messaggi di errore e così via. Non troverai la stringa " Autorizzazione fallita " ovunque.

Per proteggermi dai dump della memoria, utilizzo una semplice tecnica di offuscamento del testo (come XOR ogni carattere) Questo rende più difficile distinguere i dati di testo in memoria dalle variabili e così via.

Quindi ovviamente c'è AES per tutti i dati che sono veramente sensibili. Mi piace la modalità contatore per il testo in quanto ciò non comporta sequenze ripetitive che rivelano i dati sottostanti come una sequenza di spazi bianchi.

Ma con tutte queste tecniche, se il vettore di chiave o di inizializzazione può essere scaricato dalla memoria o l'istruzione IF esclusa, tutto è sprecato.

Tendo a usare un'istruzione switch anziché un'istruzione condizionale. Quindi creo una seconda funzione che è sostanzialmente un vicolo cieco invece della funzione che esegue effettivamente l'attività desiderata

Answer 1

Non sono d'accordo xsl.

Proteggiamo il nostro codice, non perché vogliamo proteggere le nostre entrate - accettiamo che coloro che utilizzerebbero se senza una licenza probabilmente non lo pagherebbero comunque.

Invece, lo facciamo per proteggere l'investimento che i nostri clienti hanno effettuato nel nostro software. Riteniamo che l'uso del nostro software li renda più competitivi sul loro mercato e che se altre aziende hanno accesso ad esso senza pagare abbiano un vantaggio sleale, cioè diventano competitivi senza avere il sovraccarico del costo della licenza.

Siamo molto attenti a garantire che la protezione - che è cresciuta in casa - sia il più discreta possibile per gli utenti validi, e a tal fine non prenderemmo mai in considerazione l'acquisto di una soluzione standard che potrebbe avere un impatto su di essa.

Answer 2

Non hai bisogno di poche centinaia di utenti per far decifrare il tuo software. Mi sono infastidito il fatto che il mio shareware sia stato crackato così tante volte, quindi come esperimento ho creato un programma chiamato Magic Textbox (che era solo un modulo con una casella di testo su di esso) e l'ho rilasciato su siti shareware (aveva il suo file PAD e tutto il resto ). Il giorno dopo era disponibile una versione crackata di Magic Textbox.

Questa esperienza mi ha fatto praticamente rinunciare a provare a proteggere il mio software con qualcosa di più di una rudimentale protezione dalla copia.

Answer 3

Uso personalmente le tecniche del codice discusse qui . Questi trucchi hanno il vantaggio di disturbare i pirati senza rendere la vita più difficile ai tuoi legittimi utenti finali

Ma la domanda più interessante non è "cosa", ma "perché". Prima che un fornitore di software intraprenda questo tipo di esercizio, è davvero importante costruire un modello di minaccia. Ad esempio, le minacce per un gioco B2C a basso costo sono completamente diverse da quelle per un'app B2B di alto valore.

Patrick Mackenzie ha un buon saggio in cui discute alcune delle minacce , inclusa un'analisi di 4 tipi di potenziali clienti. Ti consiglio di fare questa analisi delle minacce per la tua app prima di fare delle scelte sulla protezione del tuo modello di business.

Answer 4

Ho implementato l'hardware keying (dongle) prima di me, quindi non ho familiarità con i problemi. In effetti, ci ho pensato molto. Non sono d'accordo con nessuno che violi la legge sul copyright, come fanno i tuoi cracker. Chi non vuole acquisire legalmente una copia del proprio software dovrebbe fare a meno. Non ho mai violato il copyright del software da solo. Detto questo ...

Non mi piace davvero la parola " proteggere " usato qui. L'unica cosa che stai cercando di proteggere è il tuo controllo . Non stai non proteggendo il software. Il software va bene in entrambi i modi, come lo sono i tuoi utenti.

La ragione per cui impedire alle persone di copiare e condividere il tuo software è una PITA così malvagia è che prevenire tali attività è innaturale. L'intero concetto di computer ruota attorno alla copia dei dati, ed è semplice natura umana voler condividere cose utili. Puoi combattere questi fatti se insisti davvero, ma sarà una lotta per tutta la vita. Dio non sta facendo gli umani in modo diverso, e non sto comprando un computer che non è in grado di copiare le cose. Forse sarebbe meglio trovare un modo per lavorare con computer e persone, piuttosto che combattere contro di loro tutto il tempo?

Io, insieme alla maggior parte degli sviluppatori di software professionali, sono impiegato a tempo pieno da un'azienda che ha bisogno di software sviluppato in modo che possa fare la propria attività, non così che possa avere un "prodotto software". con scarsità artificiale di "vendere" agli utenti. Se scrivo qualcosa di generalmente utile (che non è considerato un "vantaggio competitivo" qui), possiamo rilasciarlo come software libero. Nessuna "protezione" è necessario.

Answer 5

Da alcuni dei collegamenti:

Il concetto che ho cercato di spiegare è quello che chiamo & # 8220; crack spread & # 8221 ;. Non importa che esista una crepa (o keygen, o seriale pirata, o qualsiasi altra cosa) per la tua applicazione. Ciò che conta è quante persone hanno accesso alla crack.

Dove / quando controllare il numero seriale: controllo all'avvio. Molte persone dicono & # 8220; Controlla in tutti i tipi di posti & # 8221 ;, per rendere più difficile per qualcuno rompere togliendo il segno di spunta. Se vuoi essere particolarmente cattivo con il cracker, controlla in tutti i tipi di posti usando il codice interno (cioè DON & # 8217; T esternalizzalo tutto in SerialNumberVerifier.class) e, se possibile, rendilo multi-thread e difficile da riconoscere quando fallisce anche lui. Ma questo rende più difficile rendere il crack, non impossibile, e ricorda che il tuo obiettivo in generale non è quello di sconfiggere il cracker. Sconfiggere il cracker non ti rende una quantità apprezzabile di denaro. Devi solo sconfiggere l'utente occasionale nella maggior parte dei casi e l'utente casuale non ha accesso a un debugger né sa come utilizzarlo.

Se stai per telefonare a casa, dovresti telefonare a casa con le informazioni dell'utente e accettare il numero seriale come output dello script del tuo server, non telefonare a casa con il numero seriale e accettare un booleano, ecc. come output. vale a dire che dovresti eseguire l'inserimento chiave, non la verifica chiave. La verifica delle chiavi deve infine avvenire all'interno dell'applicazione, motivo per cui la crittografia a chiave pubblica è il modo migliore per farlo. Il motivo è che la connessione a Internet è anche nelle mani dell'avversario :) Sei un cambio di file host a partire da un exploit break-once, break-ovunque se il tuo software si aspetta solo di leggere un booleano su Internet .

Non rendere & # 8220; interessante & # 8221; o & # 8220; impegnativo & # 8221; protezione. Molti cracker si rompono per la sola sfida intellettuale. Rendi la tua protezione difficile da decifrare ma il più noiosa possibile.

Ci sono alcune crepe che cercano schemi di byte nella ricerca del posto da patchare. Di solito non sono sconfitti da una ricompilazione, ma se il tuo .EXE è imballato (da ASProtect, Armadillo, ecc.) Questo tipo di crepe deve prima decomprimere il .EXE .. e se usi un buon packer come ASProtect, il cracker sarà in grado di decomprimere manualmente il file EXE utilizzando un debugger a livello di assembly come SoftICE, ma non sarà in grado di creare uno strumento che decomprime automaticamente .EXE (per applicare successivamente le patch di byte).

Answer 6

xsl, questo è un punto di vista molto stretto con MOLTE ipotesi integrate.

Mi sembra ovvio che qualsiasi app che si affida alla consegna di qualcosa da un server sotto il tuo controllo dovrebbe essere in grado di fare un buon lavoro nel capire chi ha un account valido!

Sono anche convinto che aggiornamenti regolari (ovvero un'app appena compilata con codice in posizioni diverse) renderanno rapidamente obsolete le crack crack. Se l'app comunica con un server, l'avvio di un processo secondario per sostituire l'eseguibile principale ogni settimana è un gioco da ragazzi.

Quindi sì, nulla è irrefrenabile, ma con un qualche disegno intrinseco intelligente, diventa un punto controverso. L'unico fattore significativo è la quantità di tempo che i cracker sono disposti a spendere su di esso e quanti sforzi i tuoi potenziali clienti sono disposti a esercitare nel tentativo di trovare il prodotto dei loro sforzi su base settimanale o persino giornaliera!

Sospetto che se la tua app fornisce una funzione utile e preziosa, sarà disposta a pagare un prezzo equo. In caso contrario, i prodotti della concorrenza entreranno nel mercato e il tuo problema si sarà risolto da solo.

Answer 7

Ho usato .NET Reactor in passato con buoni risultati - http://www.eziriz.com/

Quello che mi è piaciuto di questo prodotto è che non ti è stato richiesto di offuscare il codice per avere una protezione abbastanza buona.