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

Question

L'obscurcissement est un moyen, mais il ne peut pas empêcher de briser la sécurité de l'application en matière de protection contre le piratage. Comment m'assurer que l'application n'est pas altérée et que le mécanisme d'enregistrement ne peut pas faire l'objet d'une ingénierie inverse ?

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

C# offre de nombreuses fonctionnalités et constitue le langage idéal pour mon code. Il est donc hors de question de réécrire l'ensemble du code en C++.

Les certificats sécurisés peuvent être facilement retirés des assemblages signés dans .NET.

Answer 1

Tu ne peux pas.

Il y a des mesures que vous pouvez prendre pour en faire une petit plus difficile, mais en fin de compte, 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 le rendre suffisamment difficile à craquer pour qu'il ne vaille pas la peine que les gens s'embêtent.

J'ai quelques suggestions à vous faire pour vous aider à protéger votre application :

• Obfuscate votre code. Dotfuscator dispose d'une édition gratuite et est livré avec Visual Studio.
• Utilisez clé publique/privée ou chiffrement asymétrique pour générer vos licences de produits. Cela garantit que seuls les vous 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és.
• Utilisez un emballeur tiers pour emballer votre exécutable .NET dans une application wrapper Win32 cryptée. Themida est l'un des meilleurs. Cela empêche les gens de refléter votre candidature dans .NET Reflector et le rend pénible à déballer pour faire marche arrière.
• Écrivez votre propre emballeur sur mesure . Si les emballeurs tiers sont trop chers, envisagez d'écrire le vôtre. 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éballer. Le tutoriel Comment écrire votre propre packer donne une tonne de bonnes informations sur l'écriture de votre propre packer Win32.

Mais en fin de compte, si les gens veulent votre application, ils la craqueront. Regardez tous les logiciels commerciaux qui disposent d'une grande quantité de ressources pour protéger leurs applications et qui sont pourtant piratés avant même d'être mis à la disposition du public.

Un ingénieur inverse compétent peut allumer IDA-Pro et trancheront votre application comme du beurre, peu importe ce que vous faites. Une application emballée peut être déballée et l'obscurcissement ne fait que l'empêcher d'en faire une promenade de santé. Tout votre dur labeur avec votre code de licence complexe peut être annulé par un patch d'un seul octet.

Vous devez simplement accepter le fait qu'il existe un risque très réel que des personnes piratent votre logiciel. Il y a des gens qui sont jamais vont payer pour votre demande quoi qu'il arrive et ce sont les personnes dont vous n'avez pas à vous soucier.

Il existe cependant de nombreuses entreprises qui ne risqueraient jamais un procès et qui achètent volontiers des licences de logiciels, ainsi que de nombreux utilisateurs d'ordinateurs qui ne veulent pas prendre de risques, qui ne trouvent pas cela correct ou qui ne sont pas assez doués pour pirater. Ce sont vos véritables clients, et vous devriez concentrer vos efforts pour leur offrir une bonne expérience utilisateur et ignorer les personnes qui piratent vos logiciels.

Mon application a déjà été piratée, et je l'ai pris comme un affront personnel. J'étais là, un petit développeur qui mettait tout son cœur et son âme dans une application et ces gens avaient le culot de me pirater ?! Ils prenaient l'argent directement dans ma poche !

J'ai immédiatement ajouté un tas de codes DRM draconiens et tenté de saboter toute personne utilisant une copie illégitime ou piratée. J'aurais bien sûr dû m'efforcer d'améliorer mon application au lieu d'essayer d'empêcher l'inévitable. Non seulement cela, mais je faisais du tort à mon vrai les clients vont toutes ces protections supplémentaires que je mettais en place.

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

Answer 2

Vous ne pouvez pas sécuriser totalement une application (gérée ou non). Si des systèmes comme la Playstation et l'iPad peuvent être piratés - le fournisseur contrôlant même le matériel - quel espoir a votre application ? 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 accidentellement piratez votre produit, et pas plus.

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

Un autre exemple est celui d'un essai limité dans le temps. Ne vous préoccupez même pas de choses simples, comme le fait de savoir si les utilisateurs peuvent simplement remonter l'horloge du système. Quelqu'un qui fait cela sait qu'il rompt votre licence, et tant qu'un utilisateur connaît quand ils sont en infraction, vous en avez fait assez.

Vous avez besoin de faire tout cela parce que les utilisateurs ne se soucient pas de votre licence. Les licences sont des choses inventées qui personne se soucie jusqu'à ce qu'ils en aient 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 lui dire si le comportement de votre application est conforme à la licence. Dans le premier cas, cela signifie soit ne pas installer, soit installer en mode version d'essai la deuxième fois. Dans le second cas, il peut s'agir simplement de vérifier une date en texte clair dans un fichier de configuration. Quoi qu'il en soit, assurez-vous de traiter le problème d'une manière élégante, utile et respectueuse.

Cela explique donc ce que signifie faire juste autant. Mais pourquoi ne pas aller plus loin ? Pourquoi ne pas boucher tous les petits trous que vous pouvez trouver ? La réponse est en deux parties. Tout d'abord, si quelqu'un franchit le seuil éthique du consciemment si vous enfreignez les conditions de votre licence, même de manière simple, ils seront également prêts à faire quelque chose de plus difficile ou de plus dangereux, comme retirer votre application d'un site Web de l'UE. torrent et l'exécution d'applications téléchargées à partir de sources non fiables présente un certain danger. Rendre les choses plus difficiles n'est qu'un ennui mineur pour ces utilisateurs et risque de causer des problèmes avec vos clients payants. En restant simple, vous pouvez empêcher quelqu'un de creuser dans votre application et de publier un crack plus complet. Deuxièmement, vous n'avez que peu d'yeux pour chercher les failles ; les pirates en ont beaucoup, et ils ont plus de pratique pour les trouver. Il suffit d'une seule petite faille pour que votre application soit distribuée sur les sites pirates comme si vous n'aviez rien fait. Vous devez avoir raison à chaque fois ; ils ne doivent avoir de la chance qu'une fois. L'effort à fournir est donc très important, et la probabilité de réussite, quelle qu'elle soit, est très faible.

En fin de compte, si quelqu'un veut pirate votre application (plutôt que de simplement l'utiliser), et c'est là leur principal objectif, ils le feront. Il n'y a rien que vous puissiez faire pour les arrêter. C'est la nature même des logiciels : une fois que les fichiers qui composent votre produit sont sur l'ordinateur d'un utilisateur, ils sera être en mesure d'en faire ce qu'ils veulent. 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 joue en leur faveur, 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 meilleure ligne de conduite est d'engager cette catégorie 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 cette optique, quelle que soit votre application, il vaut probablement la peine de conserver une version gratuite qui est presque entièrement fonctionnelle et qui n'expire pas. La différence entre un prix d'un dollar US et la gratuité est énorme, ne serait-ce que parce que le client n'a pas à vous confier sa carte de crédit. Une édition gratuite de votre produit ne va pas seulement tuer efficacement la distribution pirate (pourquoi risquer une version pirate alors que vous pouvez être légitime pour le même prix ?), elle a le potentiel d'élargir considérablement votre public.

Le résultat est que vous devrez peut-être augmenter le prix de l'édition payante, de sorte qu'à la fin, au lieu de 2 000 utilisateurs à 20 $ chacun, vous avez 100 000 utilisateurs gratuits, dont 500 sont prêts à payer 99 $ pour l'édition "professionnelle". Vous gagnez ainsi plus d'argent que si vous passiez un temps fou à verrouiller votre produit. De plus, vous pouvez engager ces utilisateurs gratuits et tirer parti de cette relation de plusieurs manières importantes.

L'un d'eux est le soutien. Un pessimiste en profiterait pour se plaindre de l'augmentation du coût du support de 100 000 utilisateurs gratuits, mais il se passe quelque chose d'étonnant : votre produit devient largement autonome. Vous voyez cela tout le temps avec les grands projets open source qui n'ont pas d'argent pour les coûts de support. Les utilisateurs s'engagent et font en sorte que cela se produise.

Les utilisateurs gratuits ont généralement des attentes réduites en matière d'assistance, et ce pour une bonne raison. Il vous suffit d'indiquer que l'édition gratuite ne peut bénéficier que d'une assistance communautaire et de mettre en place un forum en ligne modéré par les utilisateurs à cet effet. Votre base de connaissances en matière d'assistance se générera d'elle-même et les utilisateurs avancés guideront ceux qui ont besoin d'un coup de main 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.

Un autre est le retour d'information. En observant 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 un plus grand nombre de vos utilisateurs gratuits en utilisateurs payants et de créer un produit plus convaincant qui attirera un public encore plus large.

Enfin, vous devez tenir compte du marketing. Tous ces utilisateurs gratuits sont désormais des fans plutôt que des adversaires, et ils agiront en conséquence. De plus, au moment de lancer 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 serez connecté à un public plus large, très intéressé et qui vous soutiendra.

Les meilleures fonctionnalités à réserver à l'édition professionnelle sont les outils destinés à faciliter le déploiement et la gestion des entreprises. Un pirate n'y verra pas une raison suffisamment convaincante pour le pirater à des fins personnelles, mais pour une entreprise qui souhaite acheter 300 licences et les déployer à l'échelle de l'entreprise, ces outils sont indispensables. Bien sûr, l'édition professionnelle sera de toute façon piratée, mais une fois encore, ne vous en faites pas, car vous ne pourrez probablement pas vendre le produit à ces pirates, quoi que vous fassiez. tout revenu.

Bien qu'il puisse être difficile, d'un point de vue psychologique, de donner autant de votre produit, nous espérons que vous comprendrez que c'est vraiment la meilleure façon de procéder. Et ce n'est pas tout, c'est la seule façon de procéder sur le long terme. Je sais qu'il y a quelqu'un qui pense qu'il ne veut pas le faire de cette façon. Après tout, ils se sont bien débrouillés en vendant leur produit verrouillé à 20 $ pendant des années. Mais c'est dommage, parce que si vous ne le faites pas de cette façon, quelqu'un d'autre finira par le faire . Et leur produit sera tout aussi bon que le vôtre, ou suffisamment proche pour qu'ils puissent s'en tirer en le prétendant. Puis, tout à coup, vos prix paraissent scandaleux, les ventes chutent de façon spectaculaire et vous ne pouvez plus rien faire. Vous pouvez opter pour un niveau intermédiaire supplémentaire si vous le souhaitez, mais il est peu probable que cela vous aide.

Answer 3

D'après mon expérience, rendre votre application ou votre bibliothèque plus difficile à pirater nuit à vos clients honnêtes et ne retarde que légèrement les clients malhonnêtes. Concentrez-vous sur la création d'un excellent produit à faible friction au lieu de déployer beaucoup d'efforts pour retarder l'inévitable.

Answer 4

Un secret que vous partagez avec beaucoup de gens n'est pas un secret. Si vous avez des éléments secrets dans votre code, l'obscurcir n'est pas une protection ; il suffit de les désobstruer. 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 comme un service web et gardez votre code super secret sur votre propre serveur, où vous êtes le seul à pouvoir le voir.

Answer 5

Vous ne pouvez pas empêcher les gens de pirater 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 les 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 à la prochaine mise à jour du logiciel. Le générateur de clés continuera à fonctionner jusqu'à ce que vous changiez l'algorithme de votre clé d'enregistrement et c'est quelque chose que vous ne voulez pas faire souvent car cela découragera 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 cryptage assymétrique en raison des longs codes d'enregistrement que cela génère, vous pouvez jeter un coup d'œ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. En fait, il s'agit de s'assurer que chaque version de votre logiciel ne contient que le code permettant de vérifier CERTAINS chiffres du code d'enregistrement. Le choix de ces chiffres est aléatoire, de sorte que les pirates devraient faire de l'ingénierie inverse sur de nombreuses versions différentes de votre logiciel et combiner tout cela dans un générateur de clés afin de publier 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 entraîne la présence de nombreux générateurs de clés disséminés dans toutes sortes d'archives de piratage de logiciels qui ne fonctionnent plus. Les pirates potentiels de logiciels recherchent généralement un crack ou un keygen pour la dernière version, ils en essaieront probablement plusieurs et finiront par abandonner.

J'ai utilisé la vérification partielle des clés dans mes jeux shareware (C++) plus récents 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. Après, il y avait beaucoup de cracks et quelques générateurs de clés qui ne fonctionnaient que pour cette version particulière du jeu, mais aucun générateur de clés qui fonctionnait avec toutes les versions. Nous avons régulièrement publié des mises à jour très mineures du jeu et de rendre tous les cracks existants précédemment inutile.

Il semble y avoir une source ouverte Cadre .NET pour la vérification partielle des clés mais je ne l'ai pas encore essayé.