Protection logicielle pour les petits vendeurs

Question

C’est un problème que nous devons tous examiner à un moment donné.

Après de nombreuses années et de nombreuses approches, j'ai tendance à être d'accord avec le statut: "Pour tout logiciel protégé utilisé par plus de quelques centaines de personnes, vous pouvez trouver une version fissurée. Jusqu'à présent, chaque système de protection peut être altéré. " Votre employeur impose-t-il l'utilisation d'un logiciel anti-piratage?

De plus, chaque fois que je posterai sur ce sujet, quelqu'un me le rappellera; "Tout d’abord, quel que soit le type de protection que vous employez, un craqueur véritablement dédié finira par surmonter toutes les barrières de protection". Quel est le meilleur rapport qualité-prix? Protection du code c # pour un seul développeur

Donc, malgré ces deux grands avertissements, parlons de "protection"!

J'ai toujours le sentiment que la protection est un exercice qui en vaut la peine pour les applications de petite taille qui ne mériteront probablement pas le temps et l'attention d'un cracker expérimenté.

Il semble évident que, quoi que vous fassiez, si le pirate peut changer le résultat d’une instruction IF (jmp) en appliquant une correction à l’application, tous les mots de passe et les dongles du monde ne pourront pas vous aider.

Mon approche a donc consisté à obscurcir le code avec la virtualisation à l'aide de produits tels que: http://www.oreans.com/codevirtualizer.php J'ai été très heureux avec ce produit. À ma connaissance, il n'a jamais été vaincu. Je peux même compresser l'exécutable avec PEcompact Quelqu'un d'autre en a-t-il déjà l'expérience?

N'avait que des problèmes avec EXEcryptor http://www.strongbit.com/news.asp Même le site est un casse-tête à utiliser. Les applications compilées planteraient en cas d'appel WMI.

Cette approche vous permet d’entourer les sections de code plus petites avec l’obscurcissement et de protéger ainsi le contrôle de sécurité, etc.

I Utilisez l'approche d'autorisation en ligne, car l'application a régulièrement besoin des données du serveur. Il est donc inutile que l'utilisateur les utilise hors ligne pendant une période prolongée. Par définition, l’application n’a aucune valeur à ce stade, même si elle est fissurée.

Donc, une simple poignée de main cryptée est très bien. Je viens de vérifier à l'occasion dans la protection contre l'obscurcissement. Si l'utilisateur installe l'application sur un ordinateur différent, un nouvel identifiant est chargé au lancement et le serveur désactive l'ancien identifiant et renvoie une nouvelle autorisation.

J'utilise également un hachage de l'application compilée et le vérifie au lancement pour voir si un bit a été modifié, puis ouvre l'application en tant que fichier (avec un verrou en lecture) depuis l'application pour empêcher quiconque de le modifier une fois lancé. .

Comme toutes les chaînes statiques sont clairement visibles dans le fichier .exe, j’essaie d’être générique avec des messages d’erreur, etc. Vous ne trouverez pas la chaîne " Échec de l'autorisation " n'importe où.

Pour me protéger contre les vidages de mémoire, j’utilise une technique simple d’obscurcissement de texte (comme chaque caractère XOR). Cela rend les données de texte brut en mémoire plus difficiles à distinguer des variables, etc.

.

Ensuite, bien sûr, il existe un système AES pour toutes les données réellement sensibles. J'aime le mode compteur pour le texte car il en résulte qu'aucune séquence répétée ne révèle les données sous-jacentes comme une séquence d'espaces blancs.

Mais avec toutes ces techniques, si le vecteur de clé ou d'initialisation peut être vidé de la mémoire ou si l'instruction IF est ignorée, tout est perdu.

J'ai tendance à utiliser une instruction switch plutôt qu'une instruction conditionnelle. Ensuite, je crée une deuxième fonction qui est essentiellement une impasse au lieu de la fonction qui effectue la tâche souhaitée.

Answer 1

Je ne suis pas d'accord avec xsl.

Nous protégeons notre code, non pas parce que nous voulons protéger nos revenus - nous acceptons que ceux qui les utiliseraient sans licence ne le paieraient probablement jamais de toute façon.

Nous le faisons plutôt pour protéger l'investissement que nos clients ont réalisé dans notre logiciel . Nous pensons que l'utilisation de nos logiciels les rend plus compétitifs sur leur marché et que, si d'autres entreprises y ont accès sans payer, elles ont un avantage injuste, c'est-à-dire qu'elles deviennent aussi concurrentielles sans avoir à supporter les frais de licence.

Nous sommes très attentifs à ce que la protection - qui est développée chez nous - soit aussi discrète que possible pour les utilisateurs valides, et à cette fin, nous n’envisagerons jamais d’acheter une solution prête à l'emploi pouvant avoir un impact.

Answer 2

Vous n'avez pas besoin de quelques centaines d'utilisateurs pour faire craquer votre logiciel. Je me suis énervé de voir mon shareware craquer si souvent, alors, à titre expérimental, j'ai créé un programme appelé Magic Textbox (qui était juste un formulaire avec une zone de texte) et je l'ai publié sur des sites de shareware (il avait son propre fichier PAD et tout le reste). ). Un jour plus tard, une version fissurée de Magic Textbox était disponible.

Cette expérience m'a fait arrêter de vouloir protéger mon logiciel avec autre chose qu'une protection rudimentaire contre la copie.

Answer 3

J'utilise personnellement les techniques de code décrites ici . Ces astuces ont l’avantage d’incommoder les pirates sans rendre la vie plus difficile pour vos utilisateurs finaux légitimes

Mais la question la plus intéressante n’est pas "quoi", mais "pourquoi". Avant qu'un éditeur de logiciel ne se lance dans ce type d'exercice, il est vraiment important de créer un modèle de menace. Par exemple, les menaces pour un jeu B2C à bas prix sont entièrement différentes de celles pour une application B2B de grande valeur.

Patrick Mackenzie a un bon essai dans lequel il traite de certaines des menaces , y compris une analyse de 4 types de clients potentiels. Je recommande d'effectuer cette analyse des menaces pour votre propre application avant de choisir la protection de votre modèle d'entreprise.

Answer 4

J'ai déjà implémenté la clé matérielle (dongles) avant, donc je ne suis pas totalement étranger à ces problèmes. En fait, j'y ai beaucoup réfléchi. Je ne suis pas d'accord avec quiconque viole la loi sur le droit d'auteur, comme le font vos crackers. Quiconque ne veut pas acquérir légalement une copie de votre logiciel devrait s'en passer. Je ne viole jamais moi-même les droits d'auteur sur les logiciels. Cela étant dit ...

Je n'aime vraiment pas vraiment le mot "protéger". utilisé ici. La seule chose que vous essayez de protéger est votre contrôle . Vous ne protégez pas le logiciel . Le logiciel fonctionne parfaitement dans les deux cas, de même que vos utilisateurs.

La raison pour laquelle empêcher les utilisateurs de copier et de partager votre logiciel est un tel PITA est qu’empêcher de telles activités n’est pas naturel. Tout le concept d’un ordinateur s’articule autour de la copie de données et c’est une simple nature humaine de vouloir partager des choses utiles. Vous pouvez combattre ces faits si vous insistez vraiment, mais ce sera un combat qui durera toute la vie. Dieu ne fabrique pas les humains différemment, et je n'achète pas un ordinateur qui ne peut pas copier des choses. Peut-être serait-il préférable de trouver un moyen de travailler avec des ordinateurs et des personnes, plutôt que de se battre contre eux tout le temps?

Moi, avec la majorité des développeurs de logiciels professionnels, je suis employé à temps plein par une entreprise qui a besoin de logiciels développés pour pouvoir exercer ses activités et non pour pouvoir disposer d'un "produit logiciel". avec une pénurie artificielle à " vendre " aux utilisateurs. Si j'écris quelque chose de généralement utile (qui n'est pas considéré ici comme un "avantage concurrentiel"), nous pouvons le publier en tant que logiciel libre. Pas de " protection " est nécessaire.

Answer 5

À partir de certains liens:

Le concept que j'ai essayé d'expliquer est ce que j'appelle la "propagation de fissure". Peu importe qu'une fissure (ou un keygen, une série piratée ou autre) existe pour votre application. Ce qui compte, c’est combien de personnes ont accès à la fissure.

Où / quand vérifier le numéro de série: Je vérifie une fois au démarrage. De nombreuses personnes disent "Vérifiez dans toutes sortes d'endroits", pour rendre plus difficile la tâche de quelqu'un qui craque en supprimant le chèque. Si vous voulez être particulièrement méchant avec le cracker, installez-vous dans toutes sortes d'endroits en utilisant du code en ligne (par exemple, DON n'extérialisez pas tout dans SerialNumberVerifier.class) et, dans la mesure du possible, faites-en plusieurs threads et difficile à reconnaître. ça échoue aussi. Mais cela rend juste plus difficile de faire la fissure, pas impossible, et rappelez-vous que votre objectif est généralement de ne pas vaincre le cracker. Vaincre le cracker ne vous fait pas une somme d'argent appréciable. Dans la plupart des cas, il vous suffit de vaincre l'utilisateur occasionnel, qui n'a pas accès à un débogueur et ne sait pas comment l'utiliser.

Si vous vous rendez chez vous par téléphone, vous devez téléphoner à la maison avec leurs informations d'utilisateur et accepter le numéro de série comme sortie du script de votre serveur. Ne pas téléphoner à la maison avec le numéro de série et accepter un numéro de série. booléen, etc., en sortie. c'est-à-dire que vous devriez faire l'injection de clé, pas la vérification de clé. La vérification de la clé doit en fin de compte se faire au sein de l'application, ce qui explique pourquoi le cryptage à clé publique est le meilleur moyen de le faire. La raison en est que la connexion Internet est également entre les mains de l’adversaire :) Vous êtes en train de changer un fichier hôtes, vous vous échappez ainsi d’un exploit si votre logiciel s’attend à lire un fichier booléen sur Internet .

Ne créez pas un & # 8220; intéressant & # 8221; ou & # 8220; difficile & # 8221; protection. Beaucoup de crackers craquent pour le seul défi intellectuel. Rendez votre protection difficile à craquer mais aussi ennuyeuse que possible.

Il existe des fissures qui recherchent des modèles d'octets dans la recherche de l'emplacement à patcher. Ils ne sont généralement pas vaincus par une recompilation, mais si votre fichier .EXE est compressé (par ASProtect, Armadillo, etc.), ces types de fissures doivent d’abord décompresser le fichier .EXE .. et si vous utilisez un bon programme de compression tel que ASProtect, le pirate pourra décompresser manuellement le fichier EXE à l’aide d’un débogueur de niveau assembleur tel que SoftICE, mais ne pourra pas créer d’outil qui décompresse automatiquement le fichier .EXE (pour appliquer les correctifs d’octets par la suite).

Answer 6

xsl, c’est un point de vue très étroit avec BEAUCOUP d’hypothèses intégrées.

Il me semble évident que toute application utilisant un serveur sous votre contrôle devrait pouvoir assez bien déterminer qui possède un compte valide!

Je suis également convaincu que les mises à jour régulières (c'est-à-dire une application nouvellement compilée avec du code dans différents emplacements) rendront rapidement obsolètes les vesrions craqués. Si votre application communique avec un serveur, lancer un processus secondaire pour remplacer l'exécutable principal chaque semaine est un jeu d'enfant.

Alors oui, rien n’est impossible à craquer, mais avec une conception intrinsèque intelligente, cela devient un point discutable. Le seul facteur qui compte est le temps que les craqueurs sont prêts à consacrer à ce projet et les clients que vous êtes prêt à dépenser pour que vous puissiez trouver le produit de leurs efforts hebdomadaire ou même quotidien!

Je soupçonne que si votre application fournit une fonction utile, ils seront disposés à en payer le juste prix. Sinon, des produits concurrents entreront sur le marché et votre problème se résoudra tout seul.

Answer 7

J'ai déjà utilisé .NET Reactor avec de bons résultats - http://www.eziriz.com/

Ce que j’ai aimé de ce produit, c’est qu’il ne vous obligeait pas à masquer le code afin d’être assez bien protégé.