Protection de l'Application

Protection de l'Application

Protection de l'Application : Plusieurs milliers de conseils pour vous faciliter la vie.

Comment proteger vos applications.
La parfaite application du systeme de protection
par Vegard A. Larsen
j'ai ete de penser a ce sujet pendant une longue periode, et la creation d'un parfait systeme de protection pour mon (et votre) des applications semble comme une tache impossible. Apres tout, les fissures de votre application peut etre disponible sur Internet le lendemain de la liberation. Mais, en pensant a la façon dont Microsoft (et similaire), les grandes entreprises, permettent aux utilisateurs de s'inscrire en entrant simplement un code de serie, j'ai eu l'idee de la creation d'un quasi-parfaite du systeme de protection. Ce que je vais presenter ici sont les bases de ce qui semble etre un systeme de protection incassable. Notez que cet article ne contiendra pas de code source, de sorte que c'est seulement une suggestion de comment le faire, et toutes les suggestions d'amelioration seront grandement apprecies.
Recuperer le numero de serie
La premiere pensee qui m'a frappe, a ete d'avoir le systeme le web, ce qui signifie qu'il va se connecter a une sorte de serveur d'authentification. Au premier abord, nous aurons besoin de l'utilisateur a recuperer son de numeros de serie. Cela peut etre fait dans un certain nombre de façons, mais pour le bien de cette experience de pensee, je vais specifier une methode utilisable. L'utilisateur s'enregistre via une application externe qui envoie le nom et l'organisation de votre serveur, vous devez verifier qu'il/elle a effectue le paiement, et envoie-lui un e-mail contenant cette serie. Ensuite, l'utilisateur devra saisir ces informations dans l'application principale, ou le 'vrai' processus d'enregistrement.
Verifier le numero de serie
prenons le scenario suivant: un utilisateur entre son nom, de son organisation, de serie et le code qu'il/elle a reçu quand il/elle a enregistre. Le systeme se connecte a un serveur d'authentification, qui contient toutes les informations de l'utilisateur (nom, organisation et un numero de serie) pour tous les utilisateurs. Nos informations de l'utilisateur est soumis (avec chiffrement applique) sur le serveur, ou une reponse est renvoyee a l'application. Cette reponse a egalement besoin d'une sorte de cryptage, de prevenir d'eventuelles craquelins d'intercepter le signal envoye au serveur (en utilisant par exemple de faux IPs) et de fournir simplement un '220 OK' reponse a la demande. Aussi, le chiffrement applique devra varier d'un ordinateur a ordinateur. Si nous devions utiliser le meme cryptage sur chaque ordinateur, le potentiel cracker pourrait tout simplement obtenir le nom, l'organisation et le numero de serie d'un autre utilisateur inscrit, et on aurait craque l'application. Alors, comment fait-on pour generer une cle qui varie d'un ordinateur a ordinateur, mais est reproductible sur le meme, seul ordinateur? Cela pose un assez gros probleme. Intel a integre un PROCESSEUR ID-code il y a quelques temps, mais cela peut ne pas etre fiable. Supposons que l'utilisateur decide de changer de PROCESSEUR? (Il existe aussi des patchs qui peut enlever ce CPU-ID code.) Ensuite, la valeur de cet ID. Techniquement, il n'y a rien a l'interieur d'un systeme informatique qui va rester exactement la meme fonction sur les personnes qui utilisent le systeme. Si un utilisateur decide de reinstaller Windows, toutes les donnees
enregistre dans le dossier Windows est supprime, de sorte que le stockage de donnees (comme un aleatoires generes par la cle de chiffrement) ne serait pas la meilleure idee.
La reponse pourrait etre aussi simple que de passer par l ' 'utilisateur Enregistre' valeur stockee par les Fenetres, a l'interieur du registre. Pensez-y, si l'utilisateur decide de reinstaller Windows, il/elle sera tres probablement encore entrer son nom l'utilisateur enregistre! Encore une fois, cela pose un probleme: de nombreux ordinateurs qui viennent retrecir, avec Windows et tout un tas d'applications installees hors de la boîte, le plus souvent, ont cette valeur est definie a quelque chose comme 'utilisateur'. Alors, quand notre utilisateur reinstalle sa version de Windows, cette valeur sera plus susceptible de changer. C'est le moment ou il faudra appliquer des 'extras' dans le contrat de licence, indiquant que si l'utilisateur decide de reinstaller Windows, il/elle devra en aviser votre compagnie sur ce 48 heures a l'avance, ou il/elle perdrait sa licence.
nous pouvons Alors effectuer les operations suivantes: definir le serveur a l'expiration de ce delai de 48 heures pour permettre a la reinscription de l'utilisateur, si il ne l'a pas fait dans le delai imparti, la reinitialisation de la 'utilisateur Enregistre' a ce qu'il etait avant qu'il/elle vous a notifie. Pour limiter ce (veiller a ce qu'aucun utilisateur de garder la reinstallation de Windows 3 fois par semaine), nous allons avoir un compteur du nombre de fois que l'utilisateur a enregistre cette annee, et une limite de 12 fois par annee sera un peu normal.
Nous obtenons alors le resultat suivant: votre application envoie les donnees cryptees avec une cle generee a partir de ce qu'il a trouve dans la 'utilisateur Enregistre' la cle, de preference par l'ajout d'un controle de coherence sur les donnees a la fin. Le serveur reçoit des donnees, les verifications de la coherence, et le dechiffre avec la cle generee a partir de la 'utilisateur Enregistre' (qui etaient deja presents sur le serveur).
Ensuite, le serveur peut envoyer la reponse, a l'aide de la meme cle de chiffrement, de retour pour le programme, et de dire au programme si le code de serie est valide ou pas. En fonction de cela, le programme verrouille/deverrouille lui-meme.
l'Enregistrement des donnees dans le systeme actuel
tout en evitant la detection

jusqu'ici, tout va bien, mais il y a encore plusieurs autres aspects a considerer. Comment enregistrer que le programme ont ete enregistres sur l'ordinateur local. Si vous procedez de cette façon 'normale', par stocker des valeurs dans le Registre, vous pouvez etre sûr que les craquelins aurez resolu comment obtenir autour d'elle dans la journee. Donc, une solution simple pourrait etre de stocker les donnees dans l'application fichier exe, vous etes plus susceptible de reflechir maintenant... Mal, ce sera la deuxieme place potentielle des craquelins look. Donc, j'ai eu une idee. Si nous etions a ajouter nos donnees apres les expressions du FOLKLORE d'un fichier DLL dans le repertoire Windows? C'est possible, et de cette maniere, le fichier ne sera meme pas l'augmentation de la taille que vous enregistrez votre application. Maintenant, ce fichier DLL est un fichier qui est tres rarement utilise, mais il est present sur toutes les versions de Windows (NT/2000 et 9x/Me), independamment de ce que les composants qu'ils ont choisi d'installer avec Windows. La localisation d'un tel fichier pourrait etre difficile, mais ce qui vous empeche de verifier les types de fichiers sur des systemes differents? Vous avez peut-etre ajoute a un fichier sur NT/2000 systemes, et d'un autre fichier sur 9x/Me / systemes. Vous pouvez meme diviser les donnees sur les differents fichiers dans le dossier Windows, en ajoutant seulement un octet pour chaque fichier (vous permettant de stocker plusieurs octets de donnees (par exemple, isRegistered, RegisterRetries). Remarque: Vous aurez pour verifier qu'aucun autre programme a ajoute des donnees apres les expressions du FOLKLORE, car plusieurs programmes peuvent utiliser cette methode pour stocker les valeurs.
Supplementaires de securite
Pour vous assurer que personne ne peut modifier l'executable principal, ou hex de le modifier afin de trouver une methode pour supprimer le numero de serie de la protection, nous seront de preference besoin de plusieurs couches de securite, le plus important etant de cryptage et de self-modifying code. Maintenant, a l'aide de ces dans le meme temps, il peut s'averer difficile, surtout quand vous avez besoin de faire les deux au moment de l'execution. La creation de self-modifying code est facile, mais le faire fonctionner avec des applications de chiffrement sera difficile, si pas impossible. Egalement, si possible, la compression sera utile, si tout simplement pour faire un cracker de travail d'une douleur dans son derriere. Je ne vais pas commenter beaucoup plus sur cette question, comme c'est un sujet que j'ai une connaissance limitee de l'.
Le serveur
Jusqu'a maintenant, j'ai simplement mentionne le serveur, ne pas expliquer ce qu'il fait dans le detail. Les bases sont claires, il sera une base de donnees contenant au moins les informations suivantes (peut evidemment etre etendu pour contenir d'autres elements tels que le code POSTAL, l'etat, la methode de paiement, etc.):
nom d'Utilisateur
Organisation
utilisateur Enregistre (a ne pas confondre avec le nom d'Utilisateur)
numero de Serie (peut egalement etre produite ici)
Nombre d'inscriptions des 12 derniers mois
Le serveur devra avoir au moins deux autres attributs, la premiere etant de chiffrement. La deuxieme etant qu'il n'accepte que les connexions de certains predefinis passerelles. Cela signifie que l'application cliente se connecte a un systeme, quel qu'il pense etre le serveur, alors que c'est en fait seulement une passerelle vers le serveur. De cette façon, les craquelins aurait aucun moyen de savoir quel systeme est en fait le serveur. Le plus de passerelles elle traverse, la meilleure protection pour le serveur, mais le ralentissement de la connexion. Assurez-vous que les portes sont securisees, ce qui signifie qu'ils ont aussi peu de ports ouverts que possible, et de ne pas imprimer l'adresse IP ils rediriger les messages (donc
cracker est de ne pas pirater la passerelle et de trouver la route vers le serveur).
Le serveur sera bien sûr aussi d'avoir a etre aussi sûr que possible, comme avec n'importe quel autre serveur.
remarques Supplementaires
Maintenant, la creation d'un composant comme cela, va introduire un autre probleme: Si les craquelins gerer pour une pause d'une application qui utilise ce systeme, ils ont craque tous. Par consequent, un tel composant devrait etre Open Source (ou, au moins, fourni avec la source), de sorte que tout le monde peut modifier l'algorithme de chiffrement a leurs propres besoins. Aussi, ils peuvent modifier les fichiers de l'information locale est ajoute.
est-ce son comme un parfait systeme de protection pour vous? Si vous pouvez voir des bugs, des failles de securite ou des problemes potentiels que je serai heureux de le savoir. Maintenant, le but de ce etait quelqu'un d'inspiration pour ecrire un composant qui n'est un peu comme ce modele decrit. Donc, quand quelqu'un ecrit de ce composant, assurez-vous de laissez-moi savoir a ce sujet...
Contactez-moi si vous avez des commentaires que ce soit lies a cet article, vous pouvez m'envoyer un mail ici. J'ai deja montre cet article a quelques gars sur le canal IRC #delphi, EFNet, et ils semblaient tres hate a ce sujet. Esperons que cela aide quelqu'un.
les Mises a jour de l'article

Reçu ce mail il y a quelques jours de Timothy Plocinski, et je peux voir qu'il a
a obtenu de tres bons points. Il est droit, c'est quelque chose de tres souvent
neglige, nous passons des jours fine-tuning de petites parties de notre programme principal GUI,
mais quitte a ce que le travail dur pour l'utilisateur.

'Vegard,

j'ai beaucoup apprecie votre article sur la protection des regimes de beaucoup. C'est une question que je
ruminer (que vous avez) sur un plan theorique tout le temps. Je
voir enorme faille dans votre systeme, cependant, et il
me semble que c'est un probleme souvent neglige. L'
la mise en œuvre exige trop de votre utilisateur, et sur le dessus
de qui, les traite comme si elles sont deja coupable.

en Voyant cette ligne:

C'est le moment ou il faudra appliquer des 'extras' dans la licence
d'accord en indiquant que si l'utilisateur decide de reinstaller
de Windows, il/elle aura pour aviser votre compagnie sur
cette 48 heures a l'avance, ou il/elle aurait lache son
licence.

je suppose que la plupart des utilisateurs serait tout simplement vers un autre produit
ce point. Et d'avoir des systemes de verrouillage et de deverrouillage eux-memes
en fonction de protocole fait que le systeme
'instable' pour toute mission de type critique application
vous pourriez etre la conception. Sur un plan theorique, j'ai vraiment
apprecie l'article, sur le plan pratique, j' pense
limite la trop de l'utilisateur. Apres tout, la majorite des utilisateurs de logiciels
pas de criminels, de sorte que le traitement de la majorite de cette façon, vous blesse seulement dans l' long
executer.

Cordialement,
Timothy Plocinski'

Et, je vous recommande de lire les commentaires, ils valent la peine d'etre approfondie lire.