Protéger le code .NET de l'ingénierie inverse?

L'obfuscation est un moyen, mais elle ne peut pas empêcher de briser la sécurité de protection contre le piratage de l'application. Comment puis-je m'assurer que l'application n'est pas falsifiée et comment m'assurer que le mécanisme d'enregistrement ne peut pas être rétroconçu?

Il est également possible de convertir une application C # en code natif et le Xenocode est trop coûteux.

C # fournit de nombreuses fonctionnalités et est le langage idéal pour mon code, il est donc impossible d'écrire à nouveau l'intégralité de la base de code en C ++.

Les certificats sécurisés peuvent être facilement supprimés des assemblys signés dans .NET.

Tu ne peux pas.

Il existe des mesures que vous pouvez prendre pour le rendre un peu plus difficile, mais en fin de compte, tout exécutable sur la machine locale peut être fissuré. Finalement, ce code doit être converti en code machine natif et chaque application exécutable est vulnérable.

Ce que vous voulez faire, c'est simplement le rendre assez difficile à casser pour qu'il ne vaille pas la peine aux gens.

Voici quelques suggestions que j'ai pour vous aider à protéger votre application:

• Obscurcissez votre code. Dotfuscator a une édition gratuite et est livré avec Visual Studio.
• Utilisez une clé publique / privée ou un cryptage asymétrique pour générer vos licences de produit. Cela garantit que vous seul pouvez générer vos codes de licence. Même si votre application est piratée, vous pouvez être sûr qu'ils ne publieront pas de générateur de clés pour votre application, car il est impossible d'inverser l'algorithme de génération de clés.
• Utilisez un packer tiers pour compresser votre exécutable .NET dans une application wrapper Win32 chiffrée. Themida est l'un des meilleurs. Cela empêche les gens de refléter votre application dans .NET Reflector et rend difficile le déballage pour l'inversion.
• Écrivez votre propre packer personnalisé . Si les emballeurs tiers sont trop chers, pensez à écrire les vôtres. Parfois, les emballeurs personnalisés peuvent être très efficaces, car il n'existe pas de méthodes bien publiées sur la façon de les décompresser. Le tutoriel Comment écrire votre propre packer donne une tonne de bonnes informations sur l'écriture de votre propre packer Win32.

En fin de compte, si les gens veulent que votre application soit fissurée, ils le feront. Regardez tous les logiciels commerciaux qui ont une grande quantité de ressources pour protéger leurs applications et pourtant ils sont piratés avant même que les applications ne soient rendues publiques.

Un ingénieur inversé qualifié peut lancer IDA-Pro et parcourir votre application comme du beurre, peu importe ce que vous faites. Une application emballée peut être déballée et l'obscurcissement l'empêche seulement d'en faire une promenade dans le parc. Tout votre travail acharné avec votre code de licence complexe peut être annulé avec un patch à un octet.

Vous avez juste besoin d'accepter qu'il y a une chance très réelle que des gens piratent votre logiciel. Il y a des gens qui ne paieront jamais pour votre demande quoi qu'il arrive et ce sont les gens dont vous n'avez pas à vous soucier.

Il existe cependant de nombreuses entreprises qui ne risqueraient jamais une action en justice et achèteraient volontiers des licences de logiciels et de nombreux utilisateurs d'ordinateurs qui ne veulent pas le risquer, le trouvent mal ou ne sont pas assez avertis pour pirater. Ce sont vos vrais clients, et vous devez concentrer vos efforts sur leur fournir une bonne expérience utilisateur et ignorer les personnes qui piratent votre logiciel.

J'ai déjà fait pirater mon application, et je l'ai prise comme un affront personnel. J'étais là, un petit développeur, versant mon cœur et mon âme dans une application et ces gens ont eu le culot de pirater de moi?! Ils prenaient de l'argent directement de ma poche!

J'ai immédiatement ajouté un tas de code DRM draconien et tenté de saboter toute personne utilisant une copie illégitime ou piratée. J'aurais bien sûr dû travailler à améliorer ma candidature au lieu d'essayer d'arrêter l'inévitable. Non seulement cela, mais je blessais mes vrais clients avec toutes ces protections supplémentaires que je mettais.

Après une longue bataille, j'ai réalisé que je combattais les marées et que tout ce temps perdu était pour rien. J'ai retiré tout le code du téléphone personnel, à l'exception des fonctions de licence barebones et je n'ai jamais regardé en arrière.

Vous ne pouvez pas sécuriser complètement une application (gérée ou non). Si des systèmes comme la Playstation et l'iPad peuvent se fissurer - où le fournisseur contrôle même le matériel - quel espoir votre application a-t-elle? Heureusement, vous n'en avez pas vraiment envie. À mon avis, vous devez sécuriser votre application juste assez pour que quelqu'un ne puisse pas pirater accidentellement votre produit, et pas plus.

Par exemple, si vous utilisez une licence par machine, elle ne devrait pas fonctionner uniquement lorsque vous l'installez sur une nouvelle deuxième machine. Vous voudrez un bon message d'erreur pour éviter les appels de support supplémentaires, mais ne passez pas de temps supplémentaire à le rendre trop difficile à contourner et ne frappez pas les utilisateurs par dessus la tête avec.

Un autre exemple est un procès limité dans le temps. Ne vous inquiétez même pas de choses simples comme si les utilisateurs peuvent simplement faire reculer l'horloge système. Quelqu'un qui fait cela sait qu'il casse votre licence, et tant qu'un utilisateur sait quand il viole, vous en avez assez fait.

Vous devez faire beaucoup de choses car les utilisateurs ne se soucient pas de votre licence. Les licences sont des choses inventées dont personne ne se soucie avant d'en avoir besoin. Personne ne les lit, et ils ne devraient vraiment pas avoir à le faire. Par conséquent, la meilleure façon d'indiquer à l'utilisateur où se trouvent les limites est de savoir si le comportement prêt à l'emploi de votre application est conforme à la licence. Dans ce premier cas, cela signifie soit l'échec de l'installation ou l'installation en mode de version d'essai la deuxième fois. Pour ce dernier, cela pourrait simplement signifier la vérification d'une date en texte brut dans un fichier de configuration. Quoi qu'il en soit, assurez-vous de le manipuler de manière élégante, utile et respectueuse.

Cela explique donc ce que cela signifie. Mais pourquoi ne pas aller plus loin? Pourquoi ne pas boucher chaque petit trou que vous pouvez trouver? La réponse est en deux parties. Premièrement, si quelqu'un franchit le seuil éthique de la rupture consciente de vos conditions de licence - même de manière simple - il sera également disposé à faire quelque chose de plus difficile ou dangereux comme retirer votre application d'un torrentsite - et il existe un certain danger lié à l'exécution d'applications téléchargées à partir de sources non fiables. Le rendre plus difficile n'est qu'une gêne mineure pour ces utilisateurs et risque de causer des problèmes avec vos clients payants. Rester simple peut empêcher quelqu'un de creuser dans votre application et de publier un crack plus complet. Deuxièmement, vous avez peu d'yeux pour chercher des défauts; les pirates en ont beaucoup, et ils ont plus de pratique pour les trouver. Il vous suffit de manquer un petit défaut, et votre application aura la même distribution sur les sites pirates que si vous ne faisiez rien. Vous devez avoir raison à chaque fois; ils n'ont de chance qu'une seule fois. L'effort requis est donc très élevé et la probabilité de toute mesure de succès est très faible.

En fin de compte, si quelqu'un veut pirater votre application (au lieu de simplement l'utiliser), et c'est leur principal objectif, il le fera. Il n'y a rien que vous puissiez faire pour les arrêter. Telle est la nature du logiciel; une fois que les fichiers qui composent votre produit sont sur l'ordinateur d'un utilisateur , ils seront en mesure de le faire avec eux comme ils le souhaitent. Cela est particulièrement pertinent dans les environnements gérés comme Java ou .NET , mais cela s'applique également au code natif. Le temps est de leur côté et avec suffisamment de temps, toute sécurité numérique peut être brisée.

Étant donné que vous ne pouvez pas empêcher les utilisateurs de pirater votre produit, votre meilleure solution consiste à engager cette classe d'utilisateurs d'une manière qui les utilise à votre avantage. Il est souvent possible de les faire travailler pour vous plutôt que contre vous. Dans cet esprit, quelle que soit votre application, il vaut probablement la peine de conserver une version gratuite presque entièrement fonctionnelle et qui n'expire pas. La différence entre même une étiquette de prix de 1 $ US et gratuite est énorme, si pour aucune autre raison que le client n'a pas à vous faire confiance avec sa carte de crédit. Une édition gratuite de votre produit ne tuera pas seulement efficacement la distribution piratée (pourquoi risquer une version piratée alors que vous pouvez être légitime pour le même prix?), Elle a le potentiel d'élargir considérablement votre audience.

Le résultat est que vous devrez peut-être augmenter le prix de l'édition payante, de sorte qu'au final au lieu de 2 000 utilisateurs à 20 $ chacun, vous aurez 100 000 utilisateurs gratuits, dont 500 sont prêts à payer 99 $ pour l'édition "professionnelle" . Cela vous fait gagner plus d'argent que si vous passiez beaucoup de temps à verrouiller votre produit. Plus que cela, vous pouvez engager ces utilisateurs gratuits et tirer parti de la relation de plusieurs manières importantes.

L'un est le soutien. Un pessimiste saisirait cette occasion pour se plaindre du coût accru de la prise en charge de 100 000 utilisateurs gratuits, mais quelque chose d'incroyable se produit à la place: votre produit devient largement autosuffisant. Vous voyez cela tout le temps avec de grands projets open source qui n'ont pas d'argent pour les coûts de support. Les utilisateurs intensifieront et y arriveront.

Les utilisateurs gratuits ont généralement des attentes de support réduites pour commencer, et pour une bonne raison. Tout ce que vous avez à faire est de marquer l'édition gratuite comme étant uniquement admissible au support communautaire et de mettre en place un forum en ligne modéré par l'utilisateur à cet effet. Votre base de connaissances de support est auto-générée et les utilisateurs avancés guideront ceux qui ont besoin d'une prise en main supplémentaire en votre nom. Plus important encore, cela vous permettra d'identifier et de corriger les bogues plus rapidement, améliorant finalement la qualité de votre produit et réduisant les coûts totaux de support. Cela n'était pas possible auparavant parce que votre base d'utilisateurs n'était pas assez grande, mais lorsque vous traitez les utilisateurs gratuits comme des clients, cela peut très bien fonctionner.

Un autre est la rétroaction. En regardant votre forum, vous apprenez des idées d'amélioration importantes que vous n'auriez peut-être jamais envisagées autrement. Cela peut vous permettre de transformer davantage de vos utilisateurs gratuits en utilisateurs payants et de créer un produit plus attrayant qui attirera un public encore plus large.

Enfin, vous devez considérer le marketing. Tous ces utilisateurs gratuits sont désormais des fans plutôt que des adversaires, et ils agiront en conséquence. Non seulement cela, mais quand viendra le temps de publier votre prochaine version, ces utilisateurs seront tous passés par votre canal de distribution approuvé, plutôt que par un autre mécanisme inconnu. Cela signifie que pour votre prochaine version, vous commencez par être connecté à un public plus large, très intéressé et solidaire.

Les meilleures fonctionnalités à réserver pour l'édition professionnelle sont des outils destinés à faciliter le déploiement et la gestion de l'entreprise. Un pirate ne verra pas cela comme une raison suffisante pour le pirater pour son propre usage, mais pour une entreprise qui cherche à acheter 300 licences et à la diffuser dans toute l'entreprise, c'est un must-have. Bien sûr, l'édition professionnelle sera de toute façon piratée, mais encore une fois: ne vous en faites pas car vous ne seriez probablement pas en mesure de vendre le produit à ces pirates, peu importe ce que vous avez fait, donc cela ne vous coûte aucun revenu.

Bien que psychologiquement, il puisse être difficile de donner autant à votre produit, j'espère que vous pourrez comprendre comment c'est vraiment la meilleure façon de procéder. Non seulement cela, c'est la seule voie à suivre à long terme. Je sais que quelqu'un pense qu'il ne veut pas le faire de cette façon. Après tout, ils se débrouillent très bien pour vendre leur produit verrouillé de 20 $ pendant des années. Mais c'est tout simplement dommage, car si vous ne le faites pas de cette façon, quelqu'un d'autre finira par le faire . Et leur produit sera aussi bon que le vôtre, ou assez proche, ils pourront s'en tirer en le réclamant. Ensuite, tout à coup, vos prix semblent scandaleux, les ventes baissent considérablement et vous ne pouvez rien faire d'autre. Vous pouvez opter pour un niveau intermédiaire supplémentaire si vous le devez, mais il est peu probable que cela vous aide.

D'après mon expérience, rendre votre application ou votre bibliothèque plus difficile à casser nuit à vos clients honnêtes tout en retardant légèrement les plus malhonnêtes. Concentrez-vous sur la fabrication d'un excellent produit à faible friction au lieu de faire beaucoup d'efforts pour retarder l'inévitable.

Un secret que vous partagez avec de nombreuses personnes n'est pas un secret. Si vous avez des éléments secrets dans votre code, les masquer n'est pas une protection; il ne doit être désobfusqué qu'une seule fois . Si vous avez un secret que vous ne voulez pas partager avec vos clients, ne le partagez pas avec vos clients . Écrivez votre code en tant que service Web et conservez votre code super secret sur votre propre serveur, où vous seul pouvez le voir.

D'une manière générale, il existe trois groupes de personnes.

• Ceux qui n'achèteront pas votre logiciel et recourront à des fissures, ou s'ils n'en trouvent pas, n'utilisent pas du tout votre logiciel. Ne vous attendez pas à gagner de l'argent avec ce groupe. Ils s'appuient soit sur leurs propres compétences, soit sur des crackers (qui ont tendance à prioriser leur temps en fonction de votre utilité et de la taille de votre audience. Plus utile, plus tôt une crack sera disponible).

• Le groupe d'utilisateurs légitimes qui achèteront (paieront) votre logiciel, quel que soit le mécanisme de protection que vous utilisez. Ne rendez pas la vie difficile à vos utilisateurs légitimes en utilisant un mécanisme de protection élaboré car ils vont en payer le prix dans tous les cas. Un mécanisme de protection complexe peut facilement gâcher l'expérience utilisateur et vous ne voulez pas que cela arrive à ce groupe. Personnellement, je voterais contre toute solution matérielle, ce qui augmenterait le coût de votre logiciel.

• Une minorité qui recourra au crack "contraire à l'éthique" et ne paiera que pour votre logiciel car ses fonctionnalités sont protégées par un mécanisme de licence. Vous ne voulez probablement pas qu'il soit extrêmement facile pour ce groupe de contourner votre protection. Cependant, tout cet effort que vous consacrez à la protection de votre logiciel sera rentable, selon la taille de ce groupe de personnes. Cela dépend entièrement du type de logiciel que vous créez.

Compte tenu de ce que vous avez dit, si vous pensez qu'une minorité suffisamment importante peut être poussée à acheter votre logiciel, allez-y et mettez en place une forme de protection. Pensez à combien d'argent vous pouvez gagner de cette minorité par rapport au temps que vous passez à travailler sur la protection, ou le montant que vous dépensez sur un API / outil de protection tiers.

Si vous aimez implémenter votre propre solution, l'utilisation de la cryptographie à clé publique est un bon moyen (par opposition aux algorithmes symétriques) pour éviter les hacks faciles. Vous pouvez par exemple signer numériquement votre licence (numéro de série ou fichier de licence). La seule façon de contourner ce problème serait alors de décompiler, altérer et recompiler le code (que vous pourriez rendre plus difficile en utilisant des techniques telles que celles suggérées dans la réponse de Simucal).

Vous ne pouvez pas empêcher les gens de casser votre logiciel.

Cependant, vous pouvez leur faire créer des fissures qui nuiront moins à vos ventes. Les générateurs de clés qui peuvent émettre un code d'enregistrement valide pour votre logiciel sont bien pires que de simples correctifs qui suppriment les incitations à l'enregistrement de votre logiciel. En effet, un crack ne fonctionnera que pour une seule version du logiciel et cessera de fonctionner avec la prochaine mise à jour logicielle que vous publierez. Le générateur de clés continuera de fonctionner jusqu'à ce que vous changiez votre algorithme de clé d'enregistrement et c'est quelque chose que vous ne voulez pas faire souvent car cela rebutera vos clients honnêtes.

Donc, si vous cherchez une méthode pour lutter contre les générateurs de clés illégaux pour votre logiciel et que vous ne souhaitez pas utiliser le cryptage asymétrique en raison des longs codes d'enregistrement que cela génère, vous pouvez jeter un œil à la vérification partielle des clés.

La vérification partielle des clés garantit que chaque générateur de clés illégal ne fonctionne que pour une version particulière de votre logiciel. Fondamentalement, ce que vous faites est de vous assurer que chaque version de votre logiciel est uniquement liée au code pour vérifier QUELQUES chiffres du code d'enregistrement. Quels chiffres sont exactement aléatoires, les crackers devraient donc inverser la conception de nombreuses versions différentes de votre logiciel et combiner tout cela en un seul générateur de clés afin de libérer un générateur de clés qui fonctionne pour toutes les versions de votre logiciel.

Si vous publiez régulièrement de nouvelles versions de logiciels, cela conduit à de nombreux générateurs de clés répartis sur toutes sortes d'archives de piratage de logiciels qui ne fonctionnent plus. Les pirates de logiciels potentiels recherchent généralement un crack ou un keygen pour la dernière version, ils en essayeront probablement quelques-uns et abandonneront finalement.

J'ai utilisé la vérification de clé partielle dans mes nouveaux jeux de shareware (C ++) et elle a été très efficace. Avant, nous avions beaucoup de problèmes avec les générateurs de clés que nous ne pouvions pas combattre. Par la suite, il y avait beaucoup de fissures et quelques générateurs de clés qui ne fonctionnaient que pour cette version particulière du jeu, mais pas de générateur de clés qui fonctionnerait avec toutes les versions. Nous avons régulièrement publié des mises à jour très mineures du jeu et pour rendre inutiles toutes les fissures existantes.

Il semble y avoir un framework .NET open source pour la vérification des clés partielles , même si je ne l'ai pas essayé.

• Utilisez la mise à jour en ligne pour bloquer ces copies sans licence.

• Vérifiez le numéro de série des différents modules de votre application et n'utilisez pas un seul appel de fonction pour effectuer la vérification (afin que les crackers ne puissent pas contourner la vérification facilement).

• Non seulement vérifiez le numéro de série au démarrage, faites la vérification lors de l'enregistrement des données, faites-le tous les vendredis soirs, faites-le lorsque l'utilisateur est inactif ...

• Vérifiez la somme de contrôle du fichier d'application, stockez votre somme de contrôle de sécurité à différents endroits.

• N'allez pas trop loin dans ce genre de trucs, assurez-vous que votre application ne plante jamais / ne tombe pas en panne lors de la vérification du code d'enregistrement.

• Construire une application utile pour les utilisateurs est beaucoup plus important que de créer un
  binaire incassable pour les crackers.

Vous pouvez..

Services Microsoft SLP Le potentiel logiciel d'InishTech offre la possibilité de protéger le code sans affecter la fonctionnalité de vos applications.

MISE À JOUR: (Divulgation: je travaille sur Eazfuscator.NET) Ce qui rend le potentiel logiciel des services Microsoft SLP différent, c'est la possibilité de virtualiser le code, donc vous pouvez certainement . Plusieurs années se sont écoulées depuis que la question a été initialement posée; aujourd'hui, il existe plus de produits disponibles qui fonctionnent également sur une base similaire, tels que:

• Agile.NET
• Eazfuscator.NET

.NET Reflector ne peut ouvrir que du "code managé" qui signifie essentiellement "du code .NET". Vous ne pouvez donc pas l'utiliser pour désassembler les fichiers DLL COM, le C ++ natif, le code Visual Basic 6.0 classique , etc. La structure du code .NET compilé le rend très pratique, portable, détectable, vérifiable, etc. .NET Reflector tire parti de ceci pour vous permettre de scruter les assemblys compilés mais les décompilateurs et désassembleurs ne sont en aucun cas spécifiques à .NET et existent depuis aussi longtemps que les compilateurs existent.

Vous pouvez utiliser des obfuscateurs pour rendre le code plus difficile à lire, mais vous ne pouvez pas exactement l'empêcher d'être décompilé sans le rendre également illisible pour .NET. Il existe une poignée de produits (généralement coûteux) qui prétendent «lier» votre application de code managé à une application de code natif, mais même si cela fonctionne réellement, une personne déterminée trouvera toujours un moyen.

Cependant, en matière d'obscurcissement, vous en avez pour votre argent. Donc, si votre code est si propriétaire que vous devez vous efforcer de le protéger, vous devriez être prêt à investir de l'argent dans un bon obscurcisseur.

Cependant, au cours de mes 15 années d'expérience dans l'écriture de code, j'ai réalisé que la protection excessive de votre code source est une perte de temps et a peu d'avantages. Il peut être très difficile de comprendre simplement essayer de lire le code source d'origine sans documentation, commentaires, etc. Ajoutez à cela les noms de variables insensés que les décompilateurs trouvent et le code spaghetti que les obscurcisseurs modernes créent - vous n'avez probablement pas à vous soucier trop des gens qui volent votre propriété intellectuelle.

ça en vaut vraiment la peine? Chaque mécanisme de protection peut être rompu avec une détermination suffisante. Tenez compte de votre marché, du prix du produit, du nombre de clients, etc.

Si vous voulez quelque chose de plus fiable, suivez le chemin des clés matérielles, mais c'est plutôt gênant (pour l'utilisateur) et plus cher. Les solutions logicielles seraient probablement une perte de temps et de ressources, et la seule chose qu'elles vous donneraient est le faux sentiment de «sécurité».

Peu d'idées supplémentaires (aucune n'est parfaite, car il n'y en a pas de parfaite).

• AntiDuplicate
• Changez la langue, utilisez les astuces que les auteurs de Skype ont utilisées
• Serveur de licence

Et ne perdez pas trop de temps dessus, car les crackers ont beaucoup d'expérience avec les techniques typiques et ont quelques pas d'avance sur vous. À moins que vous ne vouliez utiliser beaucoup de ressources, changez probablement le langage de programmation (faites-le à la manière de Skype).

Si vous voulez que les gens puissent exécuter votre code (et si vous ne le faites pas, alors pourquoi l'avez-vous écrit en premier lieu?), Alors leur processeur doit pouvoir exécuter votre code. Pour pouvoir exécuter le code, le CPU doit être capable de le comprendre .

Étant donné que les processeurs sont stupides et que les humains ne le sont pas, cela signifie que les humains peuvent également comprendre le code.

Il n'y a qu'une seule façon de s'assurer que vos utilisateurs ne reçoivent pas votre code: ne leur donnez pas votre code.

Cela peut être réalisé de deux manières: Logiciel en tant que service (SaaS), c'est-à-dire que vous exécutez votre logiciel sur votre serveur et ne laissez vos utilisateurs y accéder qu'à distance. C'est le modèle que Stack Overflow utilise, par exemple. Je suis presque sûr que Stack Overflow n'obscurcit pas leur code, mais vous ne pouvez pas le décompiler.

L'autre façon est le modèle de l'appliance: au lieu de donner à vos utilisateurs votre code, vous leur donnez un ordinateur contenant le code. C'est le modèle que les consoles de jeux, la plupart des téléphones portables et TiVo utilisent. Notez que cela ne fonctionne que si vous "possédez" l'intégralité du chemin d'exécution: vous devez construire votre propre CPU, votre propre ordinateur, écrire votre propre système d'exploitation et votre propre implémentation CLI . Alors, et alors seulement, vous pourrez protéger votre code. (Mais notez que même la moindre erreur rendra toutes vos protections inutiles. Microsoft, Apple, Sony, l'industrie musicale et l'industrie du cinéma peuvent en témoigner.)

Ou, vous pouvez simplement ne rien faire, ce qui signifie que votre code sera automatiquement protégé par la loi sur le droit d'auteur.

Malheureusement, vous n'allez pas vous enfuir. Votre meilleur pari est d'écrire votre code en C et P / l'invoquer .

Il y a un petit catch-22, quelqu'un pourrait simplement décompiler votre application vers CIL et tuer tout code de vérification / activation (par exemple, l'appel à votre bibliothèque C). N'oubliez pas que les applications écrites en C sont également rétro-conçues par les pirates informatiques les plus persistants (regardez simplement à quelle vitesse les jeux sont piratés ces jours-ci). Rien ne protégera votre application.

En fin de compte, cela fonctionne un peu comme votre maison, protégez-la suffisamment pour que ce soit trop d'effort (le code de spaghetti aiderait ici) et pour que l'agresseur passe juste à votre voisin (compétition :)). Regardez Windows Vista, il doit y avoir 10 façons différentes de le casser.

Il existe des packages qui crypteront votre fichier EXE et le décrypteront lorsque l'utilisateur sera autorisé à l'utiliser, mais encore une fois, cela utilise une solution générique qui a sans aucun doute été piratée.

Les mécanismes d'activation et d'enregistrement s'adressent au «Joe moyen»: les gens qui n'ont pas assez de connaissances techniques pour le contourner (ou d'ailleurs savent qu'ils peuvent le contourner). Ne vous embêtez pas avec les crackers, ils ont beaucoup trop de temps sur les mains.

Outre l'achat d'une protection, vous (ou vos développeurs) pouvez apprendre à protéger contre la copie.

Ce sont des idées:

Dans un premier temps, essayez d'écrire un programme qui s'auto-écrit sur la console. C'est un problème célèbre. Le but principal de cette tâche est de s'exercer à écrire du code autoréférentiel.

Deuxièmement, vous devez développer une technologie qui réécrira du code d'une manière qui dépendra du CIL des autres méthodes .

Vous pouvez écrire une machine virtuelle (encore en .NET ). Et mettez du code là-dedans. En fin de compte, la machine virtuelle exécute une autre machine virtuelle qui exécute le code. C'est pour une partie des fonctions rarement appelées pour ne pas trop ralentir les performances.

Réécrivez de la logique en C ++ / CLI et mélangez le code managé avec le non managé. Cela durcira le démontage. Dans ce cas, n'oubliez pas de fournir également des binaires x64 .

Oui. C'est vrai. Le code .NET est extrêmement facile à rétroconcevoir si le code n'est pas obscurci.

L'obfuscation ajoutera une couche de gêne aux personnes qui essaient de désosser votre logiciel. Selon la version que vous obtenez, vous obtiendrez différents niveaux de protection.

Visual Studio comprend une version de Dotfuscator . Puisqu'il s'agit d'une version groupée, vous n'obtenez certainement pas l'obscurcissement le plus fort possible. Si vous regardez leurs listes de fonctionnalités, vous verrez exactement ce qui vous manque (et exactement ce que l'application fera pour rendre votre code plus sûr).

Il existe quelques autres obscurcisseurs .NET gratuits ou open source (mais je ne peux pas commenter la qualité ou les différentes méthodes qu'ils utilisent):

• Obfuscar
• Babel.NET

Au final, rien n'est parfait. Si quelqu'un veut vraiment voir comment fonctionne votre logiciel, il le fera.

Eh bien, vous ne pouvez PAS ENTIÈREMENT protéger votre produit contre le craquage, mais vous pouvez maximiser / améliorer les niveaux de sécurité et le rendre un peu trop difficile à craquer par les débutants et les crackers intermédiaires.

Mais gardez à l'esprit que rien n'est impossible à craquer, seul le logiciel côté serveur est bien protégé et ne peut pas être craqué. Quoi qu'il en soit, pour améliorer les niveaux de sécurité de votre application, vous pouvez faire quelques étapes simples pour empêcher certains crackers "pas tous" de cracker vos applications. Ces étapes rendront ces craquelins fous et peut-être désespérés:

• Obscurcissez votre code source, cela rendra évidemment votre code source comme un gâchis et illisible.
• Déclenchez plusieurs routines de vérification aléatoire dans votre application, comme toutes les deux heures, 24 heures, un jour, une semaine, etc. ou peut-être après chaque action de l'utilisateur.
• Enregistrez la somme de contrôle MD5 de votre application publiée sur votre serveur et implémentez une routine qui peut vérifier la somme de contrôle MD5 du fichier actuel avec la vraie côté serveur et la déclencher de manière aléatoire. Si la somme de contrôle MD5 a été modifiée, cela signifie que cette copie a été piratée. Maintenant, vous pouvez simplement le bloquer ou publier une mise à jour pour le bloquer, etc.
• Essayez de créer une routine qui peut vérifier si certains de vos codes (fonctions, classes ou routines spécifiques) ont réellement été modifiés ou altérés ou même supprimés. Je l'appelle (vérification d'intégrité du code).
• Utilisez des packers inconnus gratuits pour pack votre application. Ou, si vous avez de l'argent, optez pour des solutions commerciales telles que Thamida ou .NET Reactor . Ces applications sont mises à jour régulièrement et une fois qu'un pirate a déballé votre application, vous pouvez simplement obtenir une nouvelle mise à jour de ces sociétés et une fois que vous avez obtenu la nouvelle mise à jour, vous n'avez qu'à emballer votre programme et publier une nouvelle mise à jour.
• Publiez régulièrement des mises à jour et forcez votre client à télécharger la dernière mise à jour.
• Enfin, rendez votre application très bon marché. Ne le rendez pas trop cher. Croyez-moi, vous obtiendrez des clients plus satisfaits et les crackers quitteront simplement votre application, car cela ne vaut pas la peine de craquer une application très bon marché.

Ce ne sont que des méthodes simples pour empêcher les débutants et les crackers intermédiaires de cracker votre application. Si vous avez d'autres idées pour protéger votre application, n'hésitez pas à les mettre en œuvre. Cela rendra la vie des crackers difficile, et ils seront frustrés, et finalement ils quitteront votre application, car cela ne vaut tout simplement pas leur temps.

Enfin, vous devez également envisager de passer votre temps à coder des applications de bonne qualité. Ne perdez pas votre temps à coder des couches de sécurité complexes. Si un bon pirate veut casser votre application, il fera quoi que vous fassiez ...

Maintenant, allez mettre en place des jouets pour les crackers ...

Il y a Salamander , qui est un compilateur et éditeur de liens .NET natif de Remotesoft qui peut déployer des applications sans le framework .NET. Je ne sais pas dans quelle mesure il répond à ses prétentions.

Si Microsoft pouvait trouver une solution, nous n'aurons pas de versions Windows piratées, donc rien n'est très sécurisé. Voici quelques questions similaires de Stack Overflow et vous pouvez implémenter votre propre façon de les protéger. Si vous publiez des versions différentes, vous pouvez adopter différentes techniques pour différentes versions, de sorte qu'au moment où la première est fissurée, la seconde peut prendre le relais.

• Gestion des fonctionnalités sous licence pour une application C ++

• Sécurisez un fichier DLL avec un fichier de licence

• Logiciel de licence / protection?

Réacteur .NET

Mise à jour

Jared a souligné que de4dot prétend pouvoir le décompiler.

.NET Reactor assure une protection complète de votre propriété intellectuelle sensible en convertissant vos assemblages .NET en processus non gérés qui ne peuvent pas être compris comme CIL et qu'aucun outil existant ne peut décompiler. Les pirates informatiques n'ont accès à aucune forme intelligible de votre source.

Puissantes et flexibles, les fonctionnalités de licence du .NET Reactor vous permettent d'appliquer vos conditions de licence et de protéger votre flux de revenus en utilisant des verrous matériels et logiciels. Le gestionnaire de licences peut créer des licences d'essai ou permanentes en quelques secondes. Un kit de développement logiciel (SDK) entièrement documenté, complet avec des exemples, vous permet d'appeler le système de licence directement à partir de votre code, vous permettant de créer des extensions personnalisées pour le système de licence.

Voici une idée: vous pourriez avoir un serveur hébergé par votre entreprise auquel toutes les instances de votre logiciel doivent se connecter. Le simple fait de les connecter et de vérifier une clé d'enregistrement ne suffit pas - ils vont simplement retirer le chèque. En plus de la vérification des clés, vous devez également demander au serveur d'effectuer une tâche vitale que le client ne peut pas effectuer lui-même, il est donc impossible de la supprimer. Bien sûr, cela signifierait probablement beaucoup de traitement lourd de la part de votre serveur, mais cela rendrait votre logiciel difficile à voler, et en supposant que vous ayez un bon schéma de clés (contrôle de la propriété, etc.), les clés seront également difficiles à voler. C'est probablement plus invasif que vous le souhaitez, car cela nécessitera que vos utilisateurs soient connectés à Internet pour utiliser votre logiciel.

Tout ce qui s'exécute sur le client peut être décompilé et craqué. L'obfusification rend tout simplement plus difficile. Je ne connais pas votre candidature, mais dans 99% des cas, je ne pense pas que cela en vaille la peine.

Il est impossible de sécuriser complètement une application, désolé.

Obscurcissez le code! Il y a un exemple dans Obfuscating C # Code .

Gardez à l'esprit que 99% + de vos utilisateurs ne seront pas intéressés à examiner votre exécutable pour voir comment il fonctionne.

Étant donné que si peu de gens vont même prendre la peine d'essayer et que la plupart des obscurcisseurs peuvent être contournés, cela vaut-il votre temps et vos efforts?

Vous feriez mieux d'investir du temps dans l'amélioration de votre produit afin que plus de gens veuillent l'utiliser.

Juste pour ajouter un avertissement: si vous allez utiliser l'obscurcissement, vérifiez que tout fonctionne toujours! L'obfuscation peut changer des choses comme les noms de classe et de méthode. Donc, si vous utilisez la réflexion pour appeler certaines méthodes et / ou classes (comme dans une architecture de plug-in), votre application peut échouer après avoir obscurci. Les traces de pile peuvent également être inutiles pour rechercher les erreurs.

S'il est écrit en .NET et compilé en CIL , il peut être reflété. Si la sécurité est une préoccupation et que l'obscurcissement doit être évité, je vous recommande d'écrire votre application en utilisant un langage non géré, ce qui est, par nature, plus difficile à inverser.

Comment vous assurer que l'application n'est pas falsifiée et comment vous assurer que le mécanisme d'enregistrement ne peut pas être rétroconçu.

Les deux ont la même réponse très simple: ne distribuez pas de code objet à des parties non fiables, telles que (apparemment) vos clients. La possibilité d'héberger l'application sur vos machines ne dépend que de ce qu'elle fait.

S'il ne s'agit pas d'une application Web , vous pouvez peut-être autoriser SSH connexion avec le transfert X vers un serveur d'applications (ou Connexion Bureau à distance , je suppose, pour Windows).

Si vous donnez du code objet à des personnes de type ringard et qu’elles pensent que votre programme peut être amusant à sera craqué. Pas question.

Si vous ne me croyez pas, signalez une application de haut niveau qui n'a pas été piratée et piratée.

Si vous optez pour les clés matérielles, cela rendra la production plus chère et vos utilisateurs vous détesteront pour cela. C'est une vraie chienne de ramper sur le sol en branchant et débranchant vos 27 différents trucs USB parce que les fabricants de logiciels ne vous font pas confiance (j'imagine).

Il existe des packages pour crypter votre EXE et le décrypter lorsque l'utilisateur est autorisé à l'utiliser

Bien sûr, le moyen de contourner cela est de casser le test "can-I-use-it" pour qu'il revienne toujours vrai.

Une mauvaise astuce pourrait être d'utiliser les valeurs d'octets des opcodes qui effectuent le test ailleurs dans le programme d'une manière sale qui fera planter le programme avec une probabilité élevée à moins que la valeur ne soit juste. Cela vous rend lié à une architecture particulière, cependant :-(

Faites une bonne application et codez un système de protection simple. Peu importe la protection que vous choisissez, elle sera inversée ... Alors ne perdez pas trop de temps / argent.

En ce qui concerne .NET, si vous publiez un Windows Forms application (ou toute application où le client a le fichier exécutable portable), elle peut être piratée.

Si vous souhaitez vous en tenir à .NET et minimiser les chances de prendre votre code source, vous pouvez envisager de le déployer en tant qu'application ASP.NET sur un serveur Web, au lieu d'en faire une application Windows Forms.

Franchement, nous devons parfois masquer le code (par exemple, enregistrer des classes de licence, etc.). Dans ce cas, votre projet n'est pas gratuit. OMI, vous devriez payer pour un bon obfucateur.

Dotfuscator cache votre code et .NET Reflector affiche une erreur lorsque vous essayez de le décompiler.

Je peux recommander d'utiliser Obfuscator .