Protéger le code .NET du reverse engineering?
L’obscurcissement est un moyen, mais il ne peut pas protéger la sécurité de l’application contre le piratage. 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 désossé?
En outre, il est possible de convertir une application C # en code natif et Xenocode est trop coûteux.
C # fournit de nombreuses fonctionnalités et constitue le langage idéal pour mon code. Il est donc impossible de réécrire 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.
Vous pouvez prendre certaines mesures pour rendre peu plus difficile, mais au final, tout fichier exécutable sur la machine locale est fissurable. 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 rendre assez difficile de craquer pour que cela ne vaille pas le trouble des gens.
Voici quelques suggestions pour vous aider à protéger votre application:
- masquer votre code. Dotfuscator a une édition gratuite et est fourni avec Visual Studio.
- Utilisez clé publique/privée ou un cryptage asymétrique pour générer les licences de votre produit. Cela garantit que seul vous pouvez générer vos codes de licence. Même si votre application est fissurée, vous pouvez être assuré qu'elle ne publiera pas de générateur de clé pour votre application, car il est impossible d'inverser l'algorithme de génération de clé.
- Utilisez un packer tiers pour intégrer votre fichier exécutable .NET dans une application d'encapsulation Win32 chiffrée. Themida est l'un des meilleurs. Cela empêche les utilisateurs de refléter votre application dans .NET Reflector et rend la décompression difficile à annuler.
- Écrivez votre propre emballeur personnalisé . Si les tiers emballeurs sont trop chers, envisagez d’écrire les vôtres. Parfois, les emballeurs personnalisés peuvent s'avérer très efficaces, car il n'existe pas de méthode bien publiée pour les décompresser. Le tutoriel Comment écrire votre propre logiciel de compression donne une tonne d'informations utiles sur la rédaction de votre propre logiciel de compression Win32.
En fin de compte, si les gens veulent que votre application soit craquée, ils le feront. Examinez tous les logiciels commerciaux qui disposent d'une grande quantité de ressources pour protéger leurs applications, mais ils sont déjà craqués avant même que les applications ne soient rendues publiques.
Un ingénieur en reverse qualifié peut lancer IDA-Pro et trancher votre application comme du beurre, peu importe ce que vous faites. Une application emballée peut être déballée et l’obscurcissement ne l’empêche que de faire une promenade dans le parc. Tout votre travail avec votre code de licence complexe peut être annulé avec un patch à un octet.
Vous devez simplement accepter le fait qu'il existe une très réelle chance que des personnes piratent votre logiciel. Il y a des gens qui ne vont jamais payer pour votre demande, peu importe ce qui se passe et ce sont des gens dont vous n'avez pas à vous soucier.
Cependant, il existe de nombreuses entreprises qui ne risqueraient jamais une action en justice et achèteraient avec bonheur des licences de logiciels, ainsi que de nombreux utilisateurs d'ordinateurs qui ne voulaient pas le risquer, le trouvaient mal ou n'étaient pas assez au fait des technologies pour pirater. Ce sont vos vrais clients et vous devez concentrer vos efforts pour leur fournir une bonne expérience utilisateur et ignorer les personnes qui font craquer votre logiciel.
J'ai déjà piraté ma candidature et je l'ai considérée comme un affront personnel. J'étais là, petit développeur, qui mettait tout mon coeur dans une application et ces gens avaient le culot de me pirater?! Ils prenaient de l'argent directement de ma poche!
J'ai immédiatement ajouté une série de codes draconiens DRM et tenté de saboter toute personne à l'aide d'une copie illégitime ou fissurée. J'aurais naturellement 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 sorti tout le code de la maison, à l'exception des fonctions de licence barebone, sans jamais regarder en arrière.
Vous ne pouvez sécuriser complètement aucune application (gérée ou non). Si des systèmes tels que la PlayStation et l'iPad peuvent être endommagés (le fabricant contrôlant même le matériel), quel espoir a votre application? Heureusement, vous ne voulez pas vraiment. À mon avis, vous devez sécuriser votre application juste assez pour que quelqu'un ne puisse pas accidentellement pirater 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 machine. Vous voudrez un bon message d'erreur pour empêcher les appels d'assistance supplémentaires, mais ne perdez pas de temps supplémentaire à travailler trop dur et évitez de frapper les utilisateurs.
Un autre exemple est un essai limité dans le temps. Ne vous préoccupez même pas de choses simples, par exemple, si les utilisateurs peuvent simplement faire reculer l'horloge système. Quelqu'un qui le sait sait qu'il enfreint votre licence, et tant qu'un utilisateur sait quand il est en infraction, vous en avez fait assez.
Vous devez le faire beaucoup car les utilisateurs ne se soucient pas de votre licence. Les licences sont des choses inventées dont personne se préoccupe jusqu'à ce qu'ils en aient besoin. Personne ne les lit, et ils ne devraient vraiment pas avoir à le faire. Par conséquent, le meilleur moyen d'indiquer à l'utilisateur où se trouvent les limites est de déterminer si le comportement par défaut de votre application est conforme à la licence. Dans ce premier cas, cela signifie que l’installation échoue ou que l’installation n’est pas effectuée en mode d'évaluation la deuxième fois. Pour ces derniers, il s’agit peut-être simplement de vérifier une date en clair dans un fichier de configuration. Quoi qu'il en soit, assurez-vous de le gérer de manière élégante, utile et respectueuse.
Cela explique donc ce que cela signifie d’en faire autant. 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 consciemment enfreindre les conditions de votre licence - même de manière simple - il sera également disposé à faire quelque chose de plus difficile ou de plus dangereux, comme de retirer votre application d'un torrent. site - et l'exécution d'applications téléchargées à partir de sources non fiables présente un certain danger. Rendre la tâche plus difficile n’est qu’un inconvénient mineur pour ces utilisateurs et risque de causer des problèmes avec vos clients payants. Garder les choses simples peut empêcher quelqu'un de creuser dans votre application et de libérer une fissure plus complète. Deuxièmement, vous avez peu d’œil disponible pour rechercher les 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 qu'à être chanceux une fois. L’effort requis est donc très élevé et la probabilité de succès est très faible.
En fin de compte, si quelqu'un veut pirate votre application (par opposition à son utilisation) et que c'est son objectif principal, il le fera. _ {Vous ne pouvez rien faire pour les arrêter. C'est la nature du logiciel; une fois que les fichiers qui composent votre produit se trouvent sur l’ordinateur d’un utilisateur, ils {pourront pouvoir les utiliser comme ils le souhaitent. Ceci est particulièrement pertinent dans les environnements gérés tels que 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.
Etant donné que vous ne pouvez pas empêcher les utilisateurs de pirater votre produit, la meilleure chose à faire est de faire participer ce groupe d'utilisateurs de manière à ce qu'il 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 sans date d'expiration. La différence entre 1 US $ et le prix de la gratuité est énorme, pour la seule raison que le client n'a pas à vous faire confiance avec sa carte de crédit. Une édition gratuite de votre produit ne supprimera pas seulement efficacement la distribution piratée (pourquoi risquer une version piratée quand vous pouvez être légitime au même prix?), Elle peut potentiellement élargir considérablement votre public.
Il en résulte que vous devrez peut-être augmenter le prix de l'édition payante, de sorte qu'à la fin, au lieu de 2 000 utilisateurs à 20 USD chacun, vous aurez 100 000 utilisateurs gratuits, dont 500 sont prêts à payer 99 USD pour l'édition "professionnelle". . Cela vous rapporte plus d'argent que si vous passiez beaucoup de temps à verrouiller votre produit. Plus que cela, vous pouvez impliquer ces utilisateurs gratuits et exploiter la relation de plusieurs manières importantes.
L'un est le soutien. Un pessimiste profite de cette occasion pour se plaindre du coût accru de la prise en charge de 100 000 utilisateurs gratuits, mais quelque chose d’extraordinaire se produit: votre produit devient en grande partie autonome. Vous le voyez tout le temps avec les grands projets open source qui n’ont pas d’argent pour les coûts de support. Les utilisateurs vont intensifier et y arriver.Les utilisateurs gratuits ont généralement au départ réduit leurs attentes en matière d'assistance, et ce pour de bonnes raisons. Pour ce faire, il vous suffit de marquer l'édition gratuite comme qualifiant uniquement pour le support de la communauté et de mettre en place un forum en ligne modéré à cet effet. Votre base de connaissances en matière de support technique est auto-générée et les utilisateurs avancés guideront ceux qui ont besoin d’un soutien supplémentaire en votre nom. Plus important encore, cela vous permettra d'identifier et de corriger les bogues plus rapidement, améliorant ainsi 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 importante, mais lorsque vous traitez les utilisateurs gratuits comme des clients, cela peut très bien fonctionner.
Une autre est la rétroaction. En regardant votre forum, vous découvrez des idées d’amélioration importantes que vous n’auriez peut-être jamais envisagées autrement. Cela peut vous permettre de transformer un plus grand nombre de vos utilisateurs gratuits en utilisateurs rémunérés et de créer un produit plus attrayant qui attirera un public encore plus vaste.
Enfin, vous devez envisager 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 vient le temps de publier votre prochaine version, ces utilisateurs auront tous utilisé votre canal de distribution approuvé, plutôt qu'un autre mécanisme inconnu. Cela signifie que pour votre prochaine version, vous débutez par vous connecter à un public plus large, très intéressé et favorable.
Les meilleures fonctionnalités à réserver pour l'édition professionnelle sont des outils destinés à faciliter le déploiement et la gestion en entreprise. Un craqueur ne verra pas cela comme une raison suffisamment convaincante de le pirater pour son propre usage, mais pour une entreprise cherchant à acheter 300 licences et à la propulser dans toute l'entreprise, ceci est un must-have. Bien sûr, l'édition professionnelle sera piratée de toute façon, 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. } _ chiffre d'affaires.
Bien que psychologiquement, il puisse être difficile de donner autant votre produit, espérons que vous puissiez comprendre comment il constitue vraiment la meilleure voie à suivre. Non seulement cela, c'est la seule façon d'aller à long terme. Je sais que quelqu'un est en train de penser qu'il ne veut pas le faire de cette façon. Après tout, ils vendent leur produit bloqué à 20 $ pendant des années. Mais c'est trop dommage, car si vous ne le faites pas de cette façon, éventuellement quelqu'un d'autre le fera. Et leurs produits seront aussi bons que les vôtres, ou suffisamment proches pour qu’ils puissent s’en sortir sans rien dire. Tout à coup, vos prix paraissent énormes, les ventes chutent de façon spectaculaire et vous ne pouvez rien faire de plus. Vous pouvez opter pour un niveau intermédiaire supplémentaire si vous le souhaitez, mais il est peu probable que cela vous aide.
While psychologically it can be hard to give away your product this much, hopefully you can understand how it really is the best way to go. Not only that, it's the only way to go in the long term. I know someone is out there thinking that they don't want to do it this way. After all, they've got by just fine selling their locked-down $20 product for years. But that's just too bad, because if you don't do it this way, eventually someone else will. And their product will be just as good as yours, or close enough they can get away with claiming that. Then all of a sudden your pricing looks outrageous, sales drop dramatically, and there's nothing else you can do. You can opt for an additional middle tier if you must, but it's unlikely to help you.
D'après mon expérience, rendre votre application ou votre bibliothèque plus difficile à cracker nuit à vos clients honnêtes tout en retardant légèrement les clients malhonnêtes. Concentrez-vous sur la fabrication d'un excellent produit à faible frottement au lieu de déployer beaucoup d'efforts pour retarder l'inévitable.
Un secret que vous partagez avec beaucoup de gens n'est pas un secret. Si votre code contient des informations secrètes, les obscurcir ne constitue pas une protection. il suffit de la désobfuser une fois. Si vous avez un secret que vous ne voulez pas partager avec vos clients, alors 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ù seul vous pouvez le voir.
De manière générale, il existe trois groupes de personnes.
Ceux qui n'achèteront pas votre logiciel et utiliseront des fissures, ou s'ils n'en trouvent pas, n'utilisent pas votre logiciel du tout. 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 tendent à hiérarchiser leur temps en fonction de votre utilité et de la taille de votre public. Plus il est utile, plus vite une fissure sera disponible).
Le groupe d'utilisateurs légitimes qui vont acheter (payer) votre logiciel, quel que soit le mécanisme de protection que vous utilisez. Ne compliquez pas la vie de vos utilisateurs légitimes en utilisant un mécanisme de protection élaboré, car ils vont payer pour cela dans tous les cas. Un mécanisme de protection complexe peut facilement gâcher l'expérience utilisateur et vous ne souhaitez pas que cela se produise pour ce groupe. Personnellement, je voterais contre toute solution matérielle, ce qui augmenterait le coût de votre logiciel.
Une minorité qui ne recourra pas à des fissures "contraires à l'éthique" et paiera pour votre logiciel car ses fonctionnalités sont protégées par un mécanisme de licence. Vous ne voulez probablement pas rendre extrêmement difficile pour ce groupe de contourner votre protection. Cependant, tous les efforts que vous déployez pour la protection de vos logiciels seront rentables, en fonction de la taille de ce groupe de personnes. Cela dépend entièrement du type de logiciel que vous construisez.
Compte tenu de ce que vous avez dit, si vous pensez qu’une minorité assez 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 avec cette minorité par rapport au temps que vous consacrez à la protection ou au montant que vous dépensez pour un API/outil de protection tiers.
Si vous souhaitez implémenter votre propre solution, l'utilisation de la cryptographie à clé publique est un bon moyen (par opposition aux algorithmes symétriques) d'empêcher les piratages faciles. Vous pouvez par exemple signer numériquement votre licence (numéro de série ou fichier de licence). Le seul moyen de contourner ce problème serait alors de décompiler, modifier et recompiler le code (ce 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 craquer votre logiciel.
Cependant, vous pouvez leur faire créer des fissures qui affecteront moins vos ventes. Les générateurs de clés pouvant é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, une fissure fonctionnera pour une seule version du logiciel et cessera de fonctionner avec la prochaine mise à jour logicielle que vous publiez. Le générateur de clé continuera à fonctionner jusqu'à ce que vous changiez l'algorithme de clé d'enregistrement et c'est quelque chose que vous ne voulez pas faire souvent car cela mettrait vos clients honnêtes à l'écart.
Ainsi, si vous recherchez une méthode pour lutter contre les générateurs de clé illégaux de 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, consultez la Vérification partielle de clé.
La vérification partielle de la clé permet de s'assurer que chaque générateur de clé non autorisé ne fonctionne que pour une version de votre logiciel. En gros, vous devez vous assurer que chaque version de votre logiciel est uniquement liée au code permettant de vérifier CERTAINS chiffres du code d'enregistrement. Quels chiffres sont exactement aléatoires, les pirates devraient alors procéder au reverse engineering de nombreuses versions différentes de votre logiciel et combiner tout cela en un seul générateur de clé afin de générer un générateur de clé compatible avec toutes les versions de votre logiciel.
Si vous publiez régulièrement de nouvelles versions de logiciels, de nombreux générateurs de clés sont répartis sur tous les types d'archives de piratage de logiciels qui ne fonctionnent plus. Les pirates informatiques potentiels recherchent généralement un crack ou un keygen pour la dernière version. Ils essaieront donc probablement quelques-uns d'entre eux et abandonneront éventuellement.
J'ai utilisé la vérification partielle des clés dans mes nouveaux jeux de shareware (C++) et cela a été très efficace. Avant, nous avions beaucoup de problèmes avec les générateurs de clés contre lesquels nous ne pouvions pas nous battre. Après coup, il y avait beaucoup de fissures et quelques générateurs de clés qui ne fonctionnaient que pour cette version du jeu, mais aucun générateur de clés ne fonctionnerait avec toutes les versions. Nous publions régulièrement des mises à jour mineures du jeu et rendons inutiles toutes les fissures existantes.
Il semble y avoir un open source Framework .NET pour la vérification partielle de clé , bien que je ne l’aie pas essayé.
Utilisez la mise à jour en ligne pour bloquer les copies sans licence.
Vérifiez le numéro de série de différents modules de votre application et n'utilisez pas un seul appel de fonction Pour effectuer la vérification (afin que les pirates ne puissent pas contourner facilement la vérification).
Non seulement vérifier le numéro de série au démarrage , Faire la vérification pendant Enregistrer les données, le faire tous les vendredis Soir., Le faire lorsque l'utilisateur est inactif ...
Vérifiez la somme du contrôle de la demande de sécurité, 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 se bloque jamais/tombe dans un dysfonctionnement En vérifiant le code d'enregistrement.
Construire une application utile pour les utilisateurs est beaucoup plus important que de créer une application.
binaire incassable pour les crackers.
Vous pouvez..
Services Microsoft SLPLe potentiel logiciel d'InishTech offre la possibilité d'aider à protéger le code sans affecter les fonctionnalités de vos applications.
UPDATE: (Divulgation: je travaille sur Eazfuscator.NET) Ce qui fait Services Microsoft SLPLe potentiel logiciel est la possibilité de virtualiser le code, vous pouvez donc can. Plusieurs années ont passé depuis que la question a été posée à l'origine; Aujourd'hui, il existe plus de produits disponibles qui fonctionnent également sur une base similaire, tels que:
.NET Reflector ne peut ouvrir que le "code géré", ce qui signifie fondamentalement "le code .NET". Vous ne pouvez donc pas l'utiliser pour désassembler les fichiers COM DLL, le C++ natif, le code classique Visual Basic 6.0 , etc. La structure du code .NET compilé le rend très pratique, portable, détectable, vérifiable, etc. .NET Reflector en profite pour vous permettre de scruter des assemblages compilés, mais les décompilateurs et les désassembleurs ne sont en aucun cas spécifiques à .NET et existent depuis aussi longtemps que les compilateurs.
Vous pouvez utiliser des obscurcisseurs pour rendre le code plus difficile à lire, mais vous ne pouvez pas empêcher exactement sa décompilation sans le rendre également illisible en .NET. Il existe une poignée de produits là-bas (généralement coûteux) qui prétendent "lier" votre application de code managé à une application de code natif, mais même si ceux-ci fonctionnent, 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 tellement propriétaire que vous devez faire tout ce qui est en votre pouvoir pour le protéger, vous devriez être prêt à investir de l'argent dans un bon obfuscateur.
Cependant, au cours de mes quelque 15 années d’écriture de code, j’ai réalisé qu’être trop protecteur contre votre code source est une perte de temps et présente peu d’avantages. Essayer de lire le code source original sans documentation, commentaires, etc. peut être très difficile à comprendre. Ajoutez à cela les noms de variables insensés que les décompilateurs proposent et le code spaghetti créé par les obfuscateurs modernes - vous n'avez probablement pas à vous inquiéter trop des personnes qui volent votre propriété intellectuelle.
Si vous voulez que les gens puissent exécuter votre code (et si vous ne le faites pas, pourquoi l'avez-vous écrit en premier lieu?), Leur processeur doit pouvoir exécuter votre code. Afin de pouvoir exécuter le code, le processeur doit pouvoir le comprendre le.
Étant donné que les processeurs sont stupides et que les humains ne le sont pas, cela signifie qu'ils peuvent également comprendre le code.
Il existe un seul moyen de vous 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 que vous ne laissez que vos utilisateurs y accéder à distance. C'est le modèle utilisé par Stack Overflow, par exemple. Je suis à peu près sûr que Stack Overflow ne masque pas leur code, mais vous ne pouvez pas le décompiler.
L’autre moyen est le modèle de l’appareil: au lieu de donner votre code à vos utilisateurs, vous leur donnez un ordinateur contenant le code. C’est le modèle que les consoles de jeu, la plupart des téléphones mobiles et TiVo utilisent. Notez que cela ne fonctionne que si vous "possédez" l'intégralité du chemin d'exécution: vous devez créer votre propre processeur, votre propre ordinateur, écrire votre propre système d'exploitation et votre propre implémentation CLI . Ensuite, et alors seulement pouvez protéger votre code. (Notez toutefois que même l'erreur la plus petite rendra toutes vos protections inutiles. Microsoft, Apple, Sony, l'industrie de la musique et l'industrie du film peuvent en témoigner.)
Ou bien, vous ne pouvez rien faire, ce qui signifie que votre code sera automatiquement protégé par le droit d'auteur.
ça en vaut vraiment la peine? Chaque mécanisme de protection peut être brisé 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, allez dans le chemin des clés matérielles, mais c'est plutôt gênant (pour l'utilisateur) et plus coûteux. Les solutions logicielles seraient probablement une perte de temps et de ressources, et la seule chose qu'elles vous donneraient serait un faux sentiment de «sécurité».
Peu plus d’idées (aucune n’est parfaite, car il n’en existe pas).
- AntiDuplicate
- Changez la langue, utilisez les astuces de Nice que les auteurs de Skype used
- Serveur de licences
Et ne perdez pas trop de temps là-dessus, car les crackers ont beaucoup d’expérience des techniques typiques et ont peu d’avance sur vous. À moins que vous ne souhaitiez utiliser beaucoup de ressources, changez probablement le langage de programmation (faites-le à l'aide de Skype).
Outre l'achat d'une protection, vous (ou vos développeurs) pouvez apprendre à protéger contre la copie.
Ce sont des idées:
Au début, essayez d’écrire un programme qui s’écrit sur la console. C'est un problème célèbre. L'objectif principal de cette tâche est de s'exercer à écrire du code à référence automatique.
Deuxièmement, vous devez développer une technologie qui réécrira du code d’une manière qui dépendra d’autres méthodes ' CIL .
Vous pouvez écrire une machine virtuelle (mais dans .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 une partie de la logique dans C++/CLI et mélangez le code managé avec un code non managé. Cela va durcir le démontage. Dans ce cas, n'oubliez pas de fournir également les binaires x64 .
Malheureusement, vous n'allez pas fuir cela. Votre meilleur pari est d'écrire votre code en C et P/Invoke it.
Il y a un petit catch-22, quelqu'un pourrait simplement décompiler votre application en CIL et tuer tout code de vérification/activation (par exemple, l'appel de votre bibliothèque C). Rappelez-vous que les pirates les plus persistants ont également procédé à une ingénierie inverse des applications écrites en C (il suffit de regarder à quelle vitesse les jeux sont fissurés de nos jours). Rien ne protégera votre application.
En fin de compte, cela fonctionne beaucoup comme chez vous, protégez-le suffisamment pour que vous fassiez trop d'effort (le code de spaghetti aiderait ici) et pour que l'agresseur passe chez votre voisin immédiat (concurrence :)). Regardez Windows Vista, il doit y avoir 10 façons différentes de le résoudre.
Il existe des packages qui chiffrent votre fichier EXE et le déchiffrent lorsque l'utilisateur est autorisé à l'utiliser, mais une fois encore, il utilise une solution générique qui a sans aucun doute été fissurée.
Les mécanismes d'activation et d'enregistrement sont destinés au «Joe moyen»: les personnes qui n'ont pas assez de connaissances en technologie pour le contourner (ou qui savent qu'elles peuvent le contourner). Ne vous embêtez pas avec des craquelins, ils ont beaucoup trop de temps.
Oui. C'est vrai. Le code .NET est extrêmement facile à ingénierie inverse si le code n'est pas dissimulé.
L'obscurcissement ajoutera une couche d'ennui aux personnes qui tentent de procéder à l'ingénierie inverse de votre logiciel. Selon la version que vous obtenez, vous obtiendrez différents niveaux de protection.
Visual Studio inclut une version de Dotfuscator . Comme 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écurisé).
Il existe quelques autres obfuscateurs .NET gratuits ou à code source ouvert (mais je ne peux pas dire de commentaires sur la qualité ni sur les différentes méthodes utilisées):
En fin de compte, 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 les fissures, mais vous pouvez maximiser/améliorer les niveaux de sécurité et rendre un peu trop difficile la fissuration par les débutants et les craquelins 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 être déchiffré. Quoi qu'il en soit, pour améliorer les niveaux de sécurité de votre application, vous pouvez prendre des mesures simples pour empêcher certains "non" tous les craqueleurs de craquer vos applications. Ces étapes rendront ces biscuits craquelés et peut-être désespérés:
- Brouiller votre code source, évidemment, cela fera paraître votre code source comme un gâchis et illisible.
- Déclenchez plusieurs routines de contrôle aléatoires dans votre application, par exemple toutes les deux heures, toutes les 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 validée sur votre serveur et implémentez une routine permettant de vérifier la somme de contrôle MD5 du fichier actuel avec celle réelle du côté serveur et de 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 puisse vérifier si certains de vos codes (fonctions, classes ou routines spécifiques) ont bien été modifiés ou altérés, voire supprimés. Je l'appelle (vérification de l'intégrité du code).
- Utilisez des emballeurs gratuits inconnus pour emballer votre application. Ou, si vous avez 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 cracker a décompressé votre application, vous pouvez simplement obtenir une nouvelle mise à jour de ces sociétés et une fois que vous avez la nouvelle mise à jour, vous ne faites que compiler votre programme et publier une nouvelle mise à jour.
- Publiez régulièrement les mises à jour et forcez votre client à télécharger la dernière mise à jour.
- Enfin, faites votre demande très bon marché. Ne faites pas ça trop cher. Croyez-moi, vous aurez plus de clients satisfaits et les craqueurs laisseront simplement votre application, car ils ne valent 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 craquelins intermédiaires de fissurer votre application. Si vous avez plus d’idées pour protéger votre application, n’hésitez pas à les mettre en oeuvre. Cela rendra simplement les crackers durs et frustrés, et ils finiront par quitter votre demande, car cela ne vaut tout simplement pas la peine.
Enfin, vous devez également envisager de passer votre temps à coder de bonnes applications. Ne perdez pas votre temps à coder des couches de sécurité compliquées. Si un bon craqueur veut faire craquer votre application, il le fera, peu importe ce que vous ferez ...
Maintenant, allez mettre en place des jouets pour les crackers ...
Il y a Salamander , qui est un compilateur .NET natif et un éditeur de liens de Remotesoft pouvant déployer des applications sans le framework .NET. Je ne sais pas à quel point il répond à ses revendications.
Si Microsoft pouvait proposer une solution, nous n'aurions pas de versions Windows piratées, rien n'est donc très sécurisé. Voici des questions similaires de Stack Overflow et vous pouvez mettre en œuvre votre propre façon de les protéger. Si vous publiez différentes versions, vous pouvez adopter différentes techniques pour chaque version. Ainsi, une fois que la première sera fissurée, la seconde pourra prendre le relais.
Mettre à jour
Jared a souligné que de4dot prétend pouvoir le décompiler.
.NET Reactor offre 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 n'ont accès à aucune forme intelligible de votre source.
Puissantes et flexibles, les fonctionnalités de licence .NET Reactor vous permettent de faire respecter vos conditions de licence et de protéger votre source de revenus en utilisant des verrous matériels et logiciels. Le gestionnaire de licence peut créer des licences d'évaluation ou permanentes en quelques secondes. Un kit de développement logiciel (SDK) entièrement documenté, accompagné d'exemples, vous permet d'appeler le système de licences directement à partir de votre code, ce qui vous permet de créer des extensions personnalisées du système de licences.
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, il leur suffit de supprimer la vérification. Outre la vérification des clés, le serveur doit également exécuter certaines tâches vitales que le client ne peut pas exécuter lui-même. Il est donc impossible de les 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 si vous avez un bon schéma de clé (contrôle de la propriété, etc.), les clés seront également difficiles à voler. C’est probablement plus invasif que vous le souhaitez, car vos utilisateurs devront être connectés à Internet pour utiliser votre logiciel.
Tout ce qui tourne sur le client peut être décompilé et fissuré. L'obfusification ne fait que rendre la tâche plus difficile. Je ne connais pas votre candidature, mais 99% du temps, je pense que cela ne vaut pas la peine.
Brouiller le code! Il existe un exemple dans Obfuscating C # Code.
Désolé, il est impossible de sécuriser complètement une application.
Franchement, nous devons parfois obscurcir le code (par exemple, enregistrer des classes de licences, etc.). Dans ce cas, votre projet n'est pas gratuit. OMI, vous devriez payer pour un bon obfucator.
Dotfuscator masque votre code et .NET Reflector affiche une erreur lorsque vous tentez de le décompiler.
En ce qui concerne .NET, si vous publiez une application Windows Forms (ou toute autre application pour laquelle le client dispose du fichier Portable Executable), elle peut être craquée.
Si vous souhaitez vous en tenir à .NET et minimiser les chances que votre code source soit pris, vous pouvez envisager de le déployer en tant qu'application ASP.NET sur un serveur Web au lieu d'en faire un Windows Forms. application.
Je peux recommander d'utiliser Obfuscator .
Il suffit de faire une bonne application et de coder un système de protection simple. Peu importe la protection que vous choisirez, elle sera inversée ... Ne perdez donc pas trop de temps et d’argent.
Gardez à l'esprit que plus de 99% de vos utilisateurs ne seront pas intéressés à examiner votre exécutable pour voir comment cela fonctionne.
Étant donné que si peu de gens vont même s'embêter à essayer et que la plupart des obfuscateurs peuvent être contournés, cela vaut-il la peine de consacrer du temps et des efforts?
Vous feriez mieux d'investir du temps dans l'amélioration de votre produit afin que plus de gens veulent l'utiliser.
S'il est écrit en .NET et compilé pour CIL , il peut être reflété. Si la sécurité vous préoccupe et qu'il faut éviter l'obscurcissement, nous vous recommandons d'écrire votre application en utilisant un langage non géré, qui est par nature plus difficile à inverser.
Comment s'assurer que l'application n'est pas falsifiée et comment s'assurer que le mécanisme d'enregistrement ne peut pas être désossé.
Les deux ont la même réponse très simple: ne donnez pas le code d'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.
Si ce n'est pas un application Web , vous pouvez peut-être autoriser SSH login avec un 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 à craquer, il sera craqué. Aucun moyen de le contourner.
Si vous ne me croyez pas, signalez une application très médiatisée qui n'a pas été piratée ni piratée.
Si vous utilisez les clés matérielles, cela rendra la production plus coûteuse et vos utilisateurs vont vous détester pour cela. C'est une vraie chienne de ramper sur le sol en branchant et débranchant vos 27 appareils USB différents parce que les fabricants de logiciels ne vous font pas confiance (j'imagine).
Il existe des paquets qui chiffrent votre fichier EXE et le déchiffrent lorsque l'utilisateur est autorisé à l'utiliser.
Bien sûr, la solution consiste à casser le test «je peux l’utiliser» pour qu’il retourne toujours vrai.
Une mauvaise astuce pourrait consister à utiliser les valeurs d'octet des opcodes qui effectuent le test ailleurs dans le programme de manière sale, ce qui le fera planter avec une probabilité élevée, à moins que la valeur ne soit juste. Cela vous rend lié à une architecture particulière, cependant :-(
Juste pour ajouter un avertissement: si vous allez utiliser l’obscurcissement, vérifiez que tout fonctionne toujours! L'obscurcissement peut changer des choses comme les noms de classe et de méthode. Ainsi, si vous utilisez la réflexion pour appeler certaines méthodes et/ou classes (comme dans une architecture de plugin), votre application pourrait échouer après avoir masqué. De plus, stacktraces peut être inutile pour localiser les erreurs.
J'ai également fait quelques réflexions sur la sécurité du piratage informatique dans ma conception et je souhaite les ajouter car certaines d'entre elles ne semblent pas être mentionnées:
J'ai une interface de script dans mon application. Pour s’assurer que les scripts ne peuvent appeler que les méthodes destinées à être appelées par des scripts (python), j’ai un scriptvisibilityattribute et System.Dynamic.DynamicMynamicObjectProvider qui reconnaît ces attributs.
Les licences utilisent une clé publique/privée.
Les modèles de vue doivent être déverrouillés en donnant un mot de passe à une fonction de déverrouillage.
Les CoreRoutines peuvent être implémentées sur un dongle. (Il y a des dongles autour desquels ça supporte)
Une grosse solution comme celle des wrappers n’était pas prévue.
Bien sûr, cet apporach script/viewModel ne permet pas de déverrouiller et d'appeler des fonctions non-scriptables à partir du code, mais cela le rend un peu plus difficile, comme avec tout ce qui est lié aux efforts anti-piratage.
La meilleure réponse est la première du petit développeur qui parle de sa propre expérience. Toutes les techniques anti-inversion discutées ci-dessus sont 101 cas d'école pour tout inverseur sérieux.
Certaines solutions DRM commerciales sont assez correctes, mais elles déchirent chaque jeu triple AAA avec des solutions DRM personnalisées en tout temps, en quelques heures (ou jours). Seule l’introduction d’une toute nouvelle solution DRM - parfois - retard inévitable pendant peut-être quelques semaines.
Tirer le meilleur parti des DRM coûte beaucoup de temps et d’argent, et peut facilement nuire aux performances, à la fiabilité, à la compatibilité/portabilité et aux relations clients en général. Soit vous en tenir à des DRM commerciaux décents sans essayer d’être trop intelligent et de prendre vos (moins) pertes ou tout simplement de l’oublier totalement ...
Un exemple de solution DRM qui a creusé son propre (commercial) Grave: http://en.wikipedia.org/wiki/StarForce
Oui, .NET les fichiers binaires (EXE et DLL) peuvent être facilement décompilés en code source. Vérifiez l'outil .NET Reflector . Essayez-le simplement avec n'importe quel fichier binaire .NET. La meilleure option est d’obscurcir les fichiers, ils peuvent toujours être décompilés par .NET Reflector, mais ils créent un désordre illisible. Je ne pense pas que de bons obscurcissements seraient gratuits ou bon marché. La première est Dotfuscator Community Edition, fournie avec Visual Studio.
répondre à plus de 600 votes: "Vous ne pouvez pas.";
il s'agit d'une situation d'un monde programmé socialement qui vous oblige à vivre dans l'enceinte dictée par la culture.
signifiant que, tout en apprenant à créer des programmes, d’autres ont appris à manipuler l’environnement;
la protection est alors considérée comme un problème d'autrui par le concept disponible qui est une réalité non attribuée par la logique du code;
les personnalités politiques sont ensuite schématisées dans le cadre de la production; dans lesquels leur enclos se produit en libérant un devoir de durée de vie qui résulte de leur présence est traité par les cultures sociales;
un conflit pour savoir qui est Lex Luthor\Superman dans l'intérêt de ces impositions sociales;
"Tu ne peux pas."
est le titre attribué à ne pas perturber le cours de l’humanité qui avait été programmé dans la situation, ce qui signifie l’absence de productivité dans la perception en révélant la connaissance de ne pas faire en harmonie pour satisfaire les intérêts de l’intrusion;
Selon la question ci-dessous dans le blog Microsoft:
Comment puis-je empêcher ILDASM de désassembler un assemblage?
.NET a un attribut appelé SuppressIldasmAttribute qui empêche le désassemblage du code. Par exemple, considérons le code suivant:
using System;
using System.Text;
using System.Runtime.CompilerServices;
[Assembly: SuppressIldasmAttribute()]
namespace HelloWorld
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello world...");
}
}
}
Comme vous pouvez le constater, il n'y a que deux différences:
Nous avons ajouté
System.Runtime.CompilerServicesnamespace deceleration.Nous avons ajouté l'attribut
[Assembly: SuppressIldasmAttribute()].
Après avoir créé l'application dans Visual Studio, lorsque nous essayons d'ouvrir le fichier EXE résultant dans ILDASM, nous obtenons maintenant le message suivant:
