Essendo un incubo del cracker!

Question

Sto cercando di fare un codice difficile da rompere usando Objective-C su Mac.

Una delle cose che ho da fare è quello di verificare se l'applicazione era incrinato.

Sono nuovo di Objective-C e Xcode e qualunque modo immagino per testare la mia applicazione finisco sempre in un test di base che può essere patchato con facilità.

Ad esempio: supponiamo che io sto per verificare l'esistenza di un dato valore in una certa parte del binario. Tale operazione sarà qualcosa di simile:

"è questo valore = x?" se no, è incrinato.

Questo è molto facile da decifrare. L'hacker può facilmente correggere il test e renderlo vero sempre.

Sto cercando di immaginare qualcosa che potrebbe provare qualcosa, non appare come una prova che può essere facilmente patch.

So che non riesco a smettere di 100% la pirateria, ma almeno sto cercando di rendere le cose più difficili, per scoraggiare la maggior parte di cracker là fuori.

Tutte le idee di modi roba come questo può essere fatto senza e trasforma le cose difficili per qualcuno guardando il binario?

Grazie per qualsiasi aiuto.

Answer 1

Lo rendono difficile per loro di valutare il vostro schema, e cambiare il tuo schema di regolarità. Un esempio da manuale è quello di eseguire il controllo a intervalli dispari che sarà molto tempo per loro di individuare le fonti di assegni e di tutti i riferimenti incrociati durante lo svolgimento della valutazione di licenza. Che si combinano con più controlli e si dovrebbe essere impostato per la maggior parte dei rilasci, è sufficiente aggiungere una buona dose di creatività quando si crea il vostro schema. Inoltre, è un po 'divertente da giocare il loro gioco; per farli rilasciare una crepa che non riesce 1 mese dopo il crack è pubblicato ... ok, che può solo ritorcersi contro di voi, ma se si sta cercando duramente per combattere contro di loro, in primo luogo ...

Si tratta di una comunità di interessante; se siete nuovi a questo, lo studio delle comunità sarà anche utile. Come accennato in precedenza, le crepe accadono per la sfida, alcune versioni del prodotto saranno semplificare il loro schema di protezione anticopia per 'pubblicità gratuita'. Quindi ... non si può davvero combattere screpolature troppo difficile, perché se qualcuno è determinato, sarà solo sprecare il vostro tempo e frustrare. Osservando la cultura può essere interessante. Probabilmente siete nella posizione migliore se si riconosce che esso che è incrinato equivale a 'popolare software', e quindi, si dovrebbe essere felici. Non si deve perdere in genere molto sonno su questo (anche se ci sono ovviamente delle eccezioni a questo). Inoltre, come la questione è elencato nella categoria Mac:. Io non andare a scavare le statistiche, ma il software è meno probabilità di ricevere attenzione da cracker se ci si rivolge OS X

Se sei un programmatore inizio, uso intelligente di tali informazioni (e l'accettazione) può essere tutto quello che dovete sapere per combattere efficacemente i cracker.

Answer 2

A meno che il software è di sicurezza legato, penso che un approccio migliore sarebbe di cambiare il tuo piano di concessione di licenze per rendere il software gratuito per gli utenti domestici che utilizzano a malapena il software e costosi per le organizzazioni.

Le organizzazioni raramente utilizzano il software rotto, a causa dei problemi legali, dove come gli utenti domestici che sono gli utenti occasionali non piace a spendere $ 100s per l'utilizzo del software una volta ogni tanto.

Questo toglierebbe la motivazione dei cracker per rompere il software.

Answer 3

Non farlo. Ricordate, (buono) cracker crepa software per divertimento. Il più elaborato il vostro schema di protezione è, il più impegnativo e divertente sarà per il cracker. Inoltre, le persone che sono in grado di utilizzare il software illegale non stanno andando a pagare per questo in ogni caso, anche se non possono avere una versione di cracking. Il vostro tempo sarà speso meglio rendere il prodotto migliore.

Detto questo, si può scoraggiare la maggior parte cracker amatoriali mettendo a nudo l'eseguibile di simboli di debug. Dovrete abilitare questa nelle preferenze del progetto.

Answer 4

Tutti i programmi di protezione davvero forti io sappia l'uso auto-modificare il codice ampiamente , in un modo o nell'altro. Tuttavia, questo non è sicuramente qualcosa di un programmatore principiante dovrebbe essere pronto a gestire.

Answer 5

Un pericolo è che se si va a grandi lunghezze eccessivamente, si può finire per rompere le cose per gli utenti legittimi. Un certo numero di macchine arcade di Atari nel 1980 ha avuto codice che avrebbe fatto diverse cose interessanti, se ha rilevato che la ROM è stato alterato. Gli effetti sarebbero sottili; per esempio, un gioco chiamato sarebbe Tempest premio giochi gratis illimitate se la partita si è conclusa quando un giocatore ha avuto certi valori di punteggio. Nella ROM rilascio di Tempest, tuttavia, la somma di controllo è stata calcolata in modo errato, quindi tutte le macchine avuto questo comportamento. Non sono sicuro fino a che punto questo bug guadagni in macchine messe in campo influenzata, ma mi immagino alcuni operatori sarebbero stati piuttosto sconvolto dopo aver scoperto di esso.