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


Le brouillage est un moyen, mais il ne peut pas empêcher de briser la sécurité de la protection contre le piratage de l'application. Comment puis-je m'assurer que l'application n'est pas falsifiée et comment puis-je m'assurer que le mécanisme d'enregistrement ne peut pas être désossé?

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

C # fournit beaucoup de fonctionnalités et est le langage idéal pour mon code. Il est donc inutile d'écrire le code entier dans C ++.

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


436


origine


Réponses:


Tu ne peux pas.

Il y a des mesures que vous pouvez prendre pour en faire un peu plus difficile, mais finalement tout exécutable sur la machine locale est craquable. Finalement, ce code doit être converti en code machine natif et toute application exécutable est vulnérable.

Ce que vous voulez faire, c'est juste le rendre assez difficile à casser pour que cela ne vaille pas la peine des gens.

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

  • Obscurcir votre code. Dotfuscator a une édition gratuite et est livré avec Visual Studio.
  • Utilisation clé publique / privée ou cryptage asymétrique pour générer vos licences de produits. Cela garantit que seulement toi peut générer vos codes de licence. Même si votre application est craqué, 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é.
  • Utiliser un emballeur tiers pour emballer votre exécutable .NET dans une application d'encapsulation Win32 chiffrée. Themida est l'un des meilleurs. Cela empêche les gens de refléter votre demande dans Réflecteur .NET et fait une peine à déballer pour l'inversion.
  • Écrivez votre propre emballeur personnalisé. Si les conditionneurs tiers coûtent trop cher, envisagez d'écrire votre propre code. Parfois, les packers personnalisés peuvent être très efficaces, car il n'existe pas de méthodes publiées pour les décompresser. Le tutoriel Comment écrire votre propre emballeur 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 piraté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 fissurés avant même que les applications ne soient publiées.

Un ingénieur inversé 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 l'empêche d'en faire une promenade dans le parc. Tout votre dur travail avec votre code de licence complexe peut être annulé avec un seul correctif octet.

Vous avez juste besoin d'accepter qu'il y a une chance très réelle que les gens piratent votre logiciel. Il y a des gens qui sont jamais va payer pour votre application, peu importe quoi et ce sont les gens dont vous n'avez pas besoin de s'inquiéter.

Il existe cependant de nombreuses entreprises qui ne risqueraient jamais une poursuite et achèteraient volontiers des licences de logiciels et de nombreux utilisateurs d'ordinateurs qui ne veulent pas prendre le risque, se tromper ou qui ne sont pas assez doués pour pirater. Ce sont vos vrais clients, et vous devriez 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 pris comme un affront personnel. J'étais ici, un développeur à temps partiel, versant mon coeur et mon âme dans une application et ces gens avaient le culot de pirater de moi ?! Ils prenaient de l'argent directement dans ma poche!

J'ai immédiatement ajouté un code DRM draconien et tenté de saboter toute personne utilisant une copie illégitime ou fêlée. Bien sûr, je devrais travailler à améliorer ma demande au lieu d'essayer d'arrêter l'inévitable. Non seulement cela, mais je me suis fait mal vrai les clients auront toutes ces protections supplémentaires que je mettais en.

Après une longue bataille, j'ai réalisé que je me battais contre les marées et tout ce temps perdu était pour rien. J'ai sorti tout le code de la maison, sauf pour les fonctions de licence barebones et je n'ai jamais regardé en arrière.


607



Vous ne pouvez sécuriser complètement aucune application (gérée ou non). Si des systèmes comme la Playstation et l'iPad peuvent être piratés - où le fournisseur contrôle même le matériel - quel est l'espoir de votre application? Heureusement, vous ne le voulez pas vraiment. À mon avis, vous devez sécuriser votre application juste assez que quelqu'un ne peut 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 seconde machine. Vous voudrez un bon message d'erreur pour éviter les appels de support supplémentaires, mais ne perdez pas de temps supplémentaire à le rendre trop difficile à manipuler et à ne pas toucher les utilisateurs.

Un autre exemple est un essai limité dans le temps. Ne vous inquiétez même pas de choses simples comme si les utilisateurs peuvent simplement revenir en arrière l'horloge du système. Quelqu'un qui fait cela sait qu'il rompt votre licence, et aussi longtemps qu'un utilisateur sait quand ils sont en violation, vous avez fait assez.

Vous devez faire cela car les utilisateurs ne se soucient pas de votre licence. Les licences sont des choses inventées personne se soucie jusqu'à ce qu'ils en ont besoin. Personne ne les lit, et ils ne devraient vraiment pas avoir à le faire. Par conséquent, la meilleure façon de dire à l'utilisateur où se trouvent les limites est de savoir si le comportement standard de votre application est conforme à la licence. Dans ce premier cas, cela signifie soit ne pas installer ou installer en mode de version d'essai la deuxième fois. Pour ce dernier, cela peut signifier simplement vérifier une date en texte brut dans un fichier de configuration. De toute façon, assurez-vous de le gérer d'une manière élégante, utile et respectueuse.

Cela explique donc ce que cela signifie. Mais pourquoi ne pas aller plus loin? Pourquoi ne pas brancher chaque petit trou que vous pouvez trouver? La réponse est en deux parties. Premièrement, si quelqu'un franchira le seuil éthique de consciemment briser vos conditions de licence - même de manière simple - ils seront également disposés à faire quelque chose de plus difficile ou dangereux, comme retirer votre application d'un torrent site - et il existe un certain nombre de dangers liés à l'exécution d'applications téléchargées à partir de sources non fiables. Le rendre plus difficile n'est qu'un inconvénient mineur pour ces utilisateurs et risque de causer des problèmes à vos clients payants. Garder cela simple 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 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 de pirates que si vous n'aviez rien fait. Vous devez avoir raison à chaque fois; ils doivent seulement avoir de la chance une fois. L'effort requis est donc très élevé et la probabilité de réussite est très faible.

En fin de compte, si quelqu'un veut pirate votre application (par opposition à simplement l'utiliser), et c'est leur objectif principal, ils le feront. Tu ne peux rien faire pour les arrêter. C'est la nature du logiciel; une fois que les fichiers qui composent votre produit sont sur l'ordinateur d'un utilisateur, ils volonté être capable de faire avec eux comme ils le souhaitent. Ceci est particulièrement pertinent dans les environnements gérés tels que Java ou .NET, mais cela s'applique aussi au code natif. Le temps est de leur côté et, avec suffisamment de temps, toute sécurité numérique peut être brisée.

Puisque vous ne pouvez pas empêcher les utilisateurs de pirater votre produit, votre meilleur plan d'action est d'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, peu importe ce que votre application est, il vaut probablement la peine de garder une version gratuite qui est presque complètement fonctionnelle et n'expire pas. La différence entre même un prix de 1 $ US et gratuit est énorme, si pour aucune autre raison que le client n'a pas à vous faire confiance avec leur carte de crédit. Une édition gratuite de votre produit va non seulement tuer efficacement la distribution piratée (pourquoi risquer une version piratée alors que vous pouvez être légitime pour le même prix?), Cela risque d’augmenter 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 dollars chacun, vous aurez 100 000 utilisateurs gratuits, dont 500 seront prêts à payer 99 dollars 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 engager ces utilisateurs libres et tirer parti de la relation de plusieurs façons importantes.

L'un est le soutien. Un pessimiste profite de l'occasion pour se plaindre de l'augmentation du coût de prise en charge de 100 000 utilisateurs gratuits, mais quelque chose d'étonnant 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 vont intensifier et y arriver.

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 soutien de la communauté et de créer un forum en ligne modéré par l'utilisateur à cette fin. Votre base de connaissances en matière de support est auto-générée et les utilisateurs avancés guideront ceux qui ont besoin d'une main courante supplémentaire pour vous. 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 d'assistance totaux. Ce n'était pas possible auparavant, car votre base d'utilisateurs n'était pas assez grande, mais lorsque vous traitez les utilisateurs gratuits en tant que 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 d’utilisateurs gratuits en utilisateurs payants et de créer un produit plus attractif qui attirera un public encore plus large.

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

Les meilleures fonctionnalités à réserver à l'édition professionnelle sont les outils destinés à faciliter le déploiement et la gestion d'entreprise. Un pirate ne verra pas ces derniers comme suffisamment convaincante raison de le pirater pour son propre usage, mais pour une entreprise qui cherche à acheter 300 licences et le pousser sur toute l'entreprise c'est un must-have. Bien sûr, l'édition professionnelle sera piraté de toute façon, mais encore une fois: ne suez pas parce que vous ne serait probablement pas en mesure de vendre le produit à ces pirates, peu importe ce que vous avez fait, il est donc pas vous coûter tout revenu.

Bien que psychologiquement, il peut être difficile de donner autant à votre produit, espérons que vous comprendrez comment c'est vraiment la meilleure façon de faire. Non seulement cela, c'est la seule façon de faire à long terme. Je sais que quelqu'un est là-bas en pensant qu'ils ne veulent pas le faire de cette façon. Après tout, ils se contentent de vendre leur produit verrouillé de 20 $ pendant des années. Mais c'est vraiment dommage, parce que si vous ne le faites pas de cette façon, finalement quelqu'un d'autre. Et leur produit sera aussi bon que le vôtre, ou suffisamment proche pour pouvoir prétendre à cela. Tout à coup, vos prix semblent scandaleux, 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.


252



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


44



Un secret que vous partagez avec beaucoup de gens n'est pas un secret. Si vous avez des trucs secrets dans votre code, l'obscurcir n'est pas une protection; il doit seulement être désobfuscated une fois que. Si vous avez un secret que vous ne voulez pas partager avec vos clients, alors ne le partagez pas avec vos clients. Ecrivez votre code en tant que service Web et conservez votre code super secret sur votre propre serveur, où vous seul pouvez le voir.


36



En gros, il y a trois groupes de personnes.

  • Ceux qui n'achèteront pas votre logiciel et qui recourent à des fissures, ou s'ils n'en trouvent pas, n'utilisent pas du tout votre logiciel. Ne vous attendez pas à gagner de l'argent de ce groupe. Ils s'appuient soit sur leurs propres compétences, soit sur des crackers (qui ont tendance à 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 achèteront (payera) votre logiciel, quel que soit le mécanisme de protection que vous utilisez. Ne faites pas la vie dure à 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 de l'utilisateur et vous ne voulez pas que cela arrive à ce groupe. Personnellement, je voterais contre toute solution matérielle, ce qui ajoute au coût de votre logiciel.

  • Une minorité qui ne recourra pas au cracking "contraire à 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 qu'il soit extrêmement facile pour ce groupe de contourner votre protection. Cependant, tous les efforts que vous consacrez à la protection de votre logiciel seront remboursés, 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’il existe une minorité suffisante, qui peut être poussé à acheter votre logiciel, mettez-vous en place une forme de protection. Pensez au montant que vous pouvez gagner avec cette minorité par rapport au temps que vous consacrez à la protection ou au montant que vous consacrez à une API ou à un outil de protection tiers.

Si vous souhaitez implémenter une solution de votre choix, l'utilisation de la cryptographie à clé publique est un bon moyen (contrairement aux algorithmes symétriques) pour éviter les piratages 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, modifier 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).


20



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

Cependant, vous pouvez les faire créer des fissures qui nuiront à vos ventes. Les générateurs de clés qui peuvent émettre un code d'enregistrement valide pour votre logiciel sont bien pires que les correctifs simples qui suppriment les incitations à l'enregistrement de votre logiciel. En effet, une fissure fonctionnera pour une seule version de logiciel et cessera de fonctionner avec la prochaine mise à jour logicielle que vous publiez. Le générateur de clés continuera à fonctionner jusqu’à ce que vous changiez l’algorithme de votre clé d’enregistrement, ce que vous ne voulez pas faire souvent, car cela détournera 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 voulez pas utiliser le chiffrement asymétrique en raison des longs codes d'enregistrement que cela génère, vous pouvez consulter la vérification des clés partielles.

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. Les chiffres exacts sont aléatoires, de sorte que les crackers devraient désosser de nombreuses versions de votre logiciel et les combiner en un seul générateur de clé afin de libérer un générateur de clés compatible avec toutes les versions de votre logiciel.

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

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

Il semble y avoir une source ouverte Framework .NET pour la vérification partielle des clés, même si je ne l'ai pas essayé.


19



  • 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 faire la vérification (de sorte que les craqueurs ne puissent pas contourner la vérification facilement).

  • Non seulement vérifier le numéro de série à démarrage, faire la vérification tout en enregistrer des données, le faire tous les vendredis le soir, faites-le quand l'utilisateur est inactif ...

  • Vérifier le contrôle du fichier d'application somme, stockez votre somme de contrôle de sécurité dans différents lieux.

  • Ne va pas trop loin sur ce genre de astuces, assurez-vous que votre application ne jamais tomber en panne / entrer en panne en vérifiant le code d'enregistrement.

  • Construire une application utile pour les utilisateurs est beaucoup plus important que de faire un
    binaire incassable pour les craquelins.


16



Vous pouvez..

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

MISE À JOUR: (Divulgation: je travaille sur Eazfuscator.NET) Ce qui rend Services SLP MicrosoftPotentiel logiciel différent est la possibilité de virtualiser le code, de sorte que vous certainement pouvez. Plusieurs années se sont écoulées depuis que la question a été posée à l'origine; Aujourd'hui, il y a plus de produits disponibles qui fonctionnent également sur des bases similaires telles que:


14



Réflecteur .NET ne peut ouvrir que du "code managé", ce qui signifie "code .NET". Donc, vous ne pouvez pas l'utiliser pour désassembler les fichiers DLL COM, natif C ++, classique Visual Basic 6.0 code, etc. La structure du code .NET compilé le rend très pratique, portable, découvrable, vérifiable, etc. .NET Reflector en profite pour vous permettre de scruter des assemblys compilés mais les décompilateurs et désassembleurs ne sont en aucun cas spécifiques à .NET et ont été autour aussi longtemps que les compilateurs ont été autour.

Vous pouvez utiliser des obfuscateurs pour rendre le code plus difficile à lire, mais vous ne pouvez pas empêcher qu'il soit décompilé sans le rendre illisible pour .NET. Il y a une poignée de des produits là-bas (généralement cher) qui prétendent "relier" votre application de code managé dans une application de code natif, mais même si ceux-ci fonctionnent réellement, une personne déterminée trouvera toujours un moyen.

Quand il s'agit d'obfuscation cependant, vous obtenez ce que vous payez. Donc, si votre code est si exclusif que vous devez aller si loin pour le protéger, vous devriez être prêt à investir de l'argent dans un bon obfuscator.

Cependant, au cours de mes quelque 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 présente peu d'avantages. Juste essayer de lire le code source original sans la documentation à l'appui, les commentaires, etc. peut être très difficile à comprendre. Ajoutez à cela les noms de variables insensés que les décompilateurs inventent et le code spaghetti que créent les obfuscateurs modernes - vous n'avez probablement pas à vous soucier trop des gens qui volent votre propriété intellectuelle.


10