La décompilation .NET, est-ce facile?

https://stackoverflow.com/questions/265295

06-07-2019
|

Question

Je recherchais le meilleur cryptage pour une clé de licence pour une application et quelqu'un a dit que quelqu'un pouvait facilement décompiler l'application, puis ignorer simplement le test de la clé de licence.

comment quelqu'un s'y prendrait-il concrètement? Donc, ils ont mon .dll, ils doivent le décompiler en quelque sorte, puis commenter l'appel de fonction pour vérifier la licence, puis le recompiler? Le décompilateur doit être vraiment bon pour que le code soit toujours compilé!

La solution

Essayez d’ouvrir votre application avec Reflector . Vous serez probablement surpris: -)

Et une fois qu'un cracker a localisé le bon emplacement dans votre code, il peut utiliser une combinaison de ildasm / ilasm pour supprimer le chèque de votre application, même si le code généré par Reflector ne sera pas compilé.

Autres conseils

Si le code source était normalement compilé, il est très facile de décompiler les assemblys .NET.

Vous pouvez utiliser le réflecteur .NET , développé à l'origine par Lutz Roeder, maintenant pris en charge par Redgate Software. Il y a une capture d'écran au bas de cette réponse qui vous donne une impression de ce que fait Reflector.

Vous pouvez parcourir vos espaces de noms et vos classes et voir le code source et les méthodes dans votre langage .NET préféré. Le FileDisassembler de Denis Bauer vous permettra (ou aux pirates malveillants). dans votre cas) pour le convertir en solution VS et apporter des modifications au programme.

Il existe des contre-mesures telles que l'utilisation d'un obfuscateur de code pour rendre votre code pratiquement illisible.

Il existe d'autres questions intéressantes sur StackOverflow à ce sujet:

Capture d'écran de Reflector:

Josh Smith a également publié le Crack.NET , qui peut être utilisé pour se connecter à un fichier .NET en cours d'exécution. processus, puis ouvrez-le dans Reflector - même si les assemblages sur disque sont En quelque sorte crypté (pour éviter que les utilisateurs n'utilisent Reflector pour les atteindre), ils pourront toujours utiliser les versions en mémoire

.NET est très facile à décompiler. L'obscurcissement rendra un peu plus difficile la compréhension de ce qui se passe, mais quelqu'un qui décompilera votre code peut tout de même savoir s'il est persistant.

Voici quelques conseils pour la protection de votre code .NET que j'ai trouvé en ligne:

http://blogs.msdn.com/ericgu /archive/2004/02/24/79236.aspx

Notez simplement qu'aucune des techniques évoquées n'est efficace à 100%, c'est juste une question de combien de cerceaux vous allez faire franchir au cracker.

La compilation .NET en général est assez simple: pour vous en rendre compte vous-même, il vous suffit de vous procurer une copie de .NET Reflector et essayez-le.

Dans la plupart des cas, il ne sera pas nécessaire de recompiler le code pour supprimer une vérification de licence simple: il suffit de corriger le MSIL fera l'affaire.

En vous protégeant contre ce scénario, les rendements diminuent rapidement: il y aura toujours quelqu'un d'assez intelligent pour éviter les vérifications supplémentaires que vous ajouterez à votre code. Par exemple, vous pouvez ajouter une signature numérique à votre code et refuser l'exécution d'une signature qui ne correspond pas (en indiquant que le code a été falsifié, par exemple pour supprimer le contrôle de licence).

Le jeu consiste alors à supprimer la vérification de la signature (en plus de la vérification de la clé de licence). Vous ajoutez donc un autre chèque, qui peut ensuite être ignoré, et cetera, à l'infini.

Il existe toute une industrie de obfuscation de code et protection contre la copie , pour vous aider à défendre votre logiciel contre de tels problèmes. C'est à vous de décider si l'effort supplémentaire de votre part et la gêne que vous causerez à vos clients légitimes valent la peine de choisir ces solutions ...

Si vous cherchez à vous défendre, essayez de lire comment l’attaquer.

Exploitation de logiciels par Greg Holland & amp; Gary McGraw est une excellente introduction.

Il est préférable de ne pas abuser de la technologie des clés de licence. Tout ce que vous faites peut être piraté par un utilisateur déterminé et vous courez le plus grand risque d'ajouter des problèmes qui empêchent des utilisateurs légitimes d'utiliser votre application. J'ai même vu du code qui était protégé avec des Hasp Dongles . Le cryptage de votre clé de licence et la dissimulation de votre code devraient suffire à empêcher les attaques opportunistes, il n'y a guère d'intérêt à aller plus loin.

Eric Sink a rédigé un bon article sur ce point, voir la section " 4. N'embêtez pas les personnes honnêtes & ; de & "; Les principes de la transparence"

Même sans Reflector, les gens le font depuis des lustres. Fondamentalement, vous regardez l’application avec un débogueur - ce que WinDBG fera normalement - et vous découvrez ensuite quand la vérification de la licence a lieu. Vous observez la valeur de retour, puis vous corrigez l'application pour passer directement au paramètre "tout bon". vérifier.

Je recommanderais tout ce que les gens ont posté ci-dessus. Vous devez juste comprendre que c'est un jeu de chat et de souris, et que votre retour sur investissement en vaudra la peine. Si vous avez des utilisateurs qui n'essayent pas de jouer au système, alors quelque chose de simple peut faire. Si vous craquez pour quelque chose de craquant, vous devrez alors envisager différentes stratégies et partir de là.

Il n'est pas nécessaire de recompiler l'application pour la corriger - il existe de nombreux outils de correction binaires. Et cela n’arrêtera pas vos crackers les plus déterminés s’il ya suffisamment d’argent à gagner.

"Trop"

Tout type de mécanisme de vérification de licence "standard" / habituel est une cible pour l'outil de suppression automatique. Et dans les quelques applications .NET commerciales que j'ai consultées, celles-ci "Trop trivial". les chèques semblent communs.

Le mieux est de protéger en rendant une partie du programme dépendante du service Web. Cela ne devrait pas être une interface trop bavarde pour éviter de ralentir l'exécution, mais cela ne devrait pas non plus être très volumineux, car ces morceaux pourraient juste être téléchargés et mis en cache localement dans la "version fissurée". sauf si l'application en dépend fréquemment.

Si vous souhaitez éviter la connectivité réseau (certaines utilisations ou certains utilisateurs pourraient trouver cela problématique / problématique en fonction de l'application, à moins que cela ne soit quelque chose que vous décriviez et que vous fournissiez de la valeur), divisez une partie du programme en une dll native ou deux et des contrôles de licence dans toutes les parties de l'application et, de manière moins évidente, dans les dll natives, seraient probablement suffisants pour dissuader le plus.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow