Décompilation .NET, comment est-ce facile?

J'étais à la recherche dans le meilleur chiffrement d'une clé de licence pour une application, et quelqu'un a dit que quelqu'un peut facilement décompiler l'application et ensuite il suffit de sauter le test de la clé de licence.

comment quelqu'un va le faire qu'en pratique? Ils ont donc mon .dll, ils ont de le décompiler en quelque sorte, puis commenter l'appel de la fonction de vérification de la licence, puis le recompiler? Le decompiler a être vraiment bon, telles que le code compile!

source d'informationauteur Blankman

  1. 29

    Essayez d'ouvrir votre application avec Réflecteur. Vous serez probablement surpris 🙂

    Et une fois un pirate a trouvé le bon endroit dans votre code, ils peuvent utiliser une combinaison de ildasm/ilasm pour désactiver la case à partir de votre application, même si le code Réflecteur génère ne compile pas.

  2. 14

    Si le code source a été compilés il est très facile de le décompiler .NET assemblées.

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

    Vous pouvez parcourir vos espaces de noms et de classes et de voir le code source et les méthodes dans vos favoris .NET de la langue. Denis Bauer FileDisassembler vous permettra (ou le mal des pirates dans votre cas) pour la convertir en un VS solution et de faire des modifications au programme.

    Il y a quelques contre-mesures comme l'utilisation d'un obfuscateur de code afin de rendre votre code pratiquement illisible.

    Il y a d'autres questions intéressantes sur StackOverflow sur ce sujet:

    Capture d'écran de Réflecteur:

    le texte d'alt http://www.red-gate.com/products/reflector/images/screenshot_full_screen.gif

  3. 5

    Josh Smith a également publié Crack.NET récemment, qui peut être utilisé pour attacher à un exécutant .NET le processus, puis de l'ouvrir que dans Réflecteur - de sorte que même si les assemblées sur le disque sont chiffrés en quelque sorte (pour éviter que les gens à l'aide de Réflecteurs pour obtenir à eux), ils continuent à être en mesure d'utiliser la mémoire versions

  4. 2

    .NET est super facile à décompiler. L'Obfuscation va le rendre un peu plus difficile à comprendre ce qu'il se passe, mais quelqu'un décompilation votre code peut encore le comprendre si elles sont persistantes.

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

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

    Il suffit de noter qu'aucune des techniques abordées sont efficaces à 100%, c'est juste une question de combien de cerceaux que vous ferez le pétard de sauter à travers.

  5. 2

    .NET compilation en général est assez simple: pour obtenir une sensation pour vous-même, il suffit de prendre une copie de .NET Réflecteur et lui donner un essai.

    Dans la plupart des cas, il n'y aura pas besoin de recompiler le code pour supprimer une licence simple de vérifier: il suffit de patcher le MSIL fera l'affaire.

    De vous protéger contre ce scénario, les rendements rapidement des rendements décroissants: il y aura toujours être quelqu'un d'assez intelligent pour ignorer ce que des contrôles supplémentaires que vous ajoutez à votre code. Par exemple, vous pouvez ajouter une signature numérique à votre code, et de refuser d'exécuter de la signature ne correspond pas (en indiquant le code a été modifié, par exemple pour supprimer le contrôle de la licence).

    Le jeu devient alors de supprimer la signature à vérifier (en plus de la clé de licence à vérifier). Si vous ajoutez une autre vérification, qui peut ensuite être contourné, et ainsi de suite, ad infinitum.

    Il y a toute une industrie de code obfuscatation et protection contre la copie outils pour vous aider à défendre votre logiciel contre les questions de ce genre. C'est à vous de décider si l'effort supplémentaire de votre côté, et de l'ennui vous aurez à cause de vos clients légitimes, est la peine d'acheter dans ces solutions...

  6. 2

    Si c'est quelque chose que vous êtes à la recherche pour se défendre contre, vous pouvez lire sur la façon de l'attaquer.

    Exploiter Un Logiciel par Greg Holland & Gary McGraw est une excellente introduction.

  7. 2

    Il est préférable de ne pas aller à la mer sur la clé de licence de la technologie. Ce que vous ne pouvez être piraté par un utilisateur et que vous exécutez le grand risque de l'ajout de questions que s'arrêtent les utilisateurs légitimes à l'aide de votre application. J'ai même vu le code qui a été protégé avec Hasp Dongles brisée. Chiffrement de la clé de licence et d'obscurcir votre code devrait être suffisant pour entraver opportuniste des attaques, il y a peu de point d'aller au-delà.

    Eric Évier a écrit un bon article portant sur ce point, voir la section "4. Ne pas Embêter les Honnêtes Gens" de "Les principes de la Transparence"

  8. 1

    Même sans Réflecteur, les gens ont fait cela pendant des âges. Fondamentalement, vous montre l'application avec un débogueur - quelque chose comme WinDBG fera, et ensuite savoir si le contrôle de la licence qui se passe. Vous regardez la valeur de retour, et ensuite il vous suffit de patch de l'application pour accéder directement à l' "tout bon" vérifier.

    Que je recommanderais à tout ce que les gens ont posté ci-dessus. Vous avez juste à réaliser que c'est un chat et une souris de jeu, et si votre retour sur investissement est ça en vaut la peine. Si vous avez des utilisateurs qui ne sont pas en train de déjouer le système, puis quelque chose de simple à faire. Si vous avez quelque chose où la fissuration est endémique, alors vous aurez à regarder les différentes stratégies et aller à partir de là.

    De ne pas avoir à recompiler l'application pour le patch - beaucoup de correctif binaire outils existent là-bas. Et il ne s'arrêtera pas votre plus déterminés crackers si il y a assez d'argent pour être fait.

  9. 1

    "Trop"

    Une sorte de "norme"/habituelle de licence de mécanisme de contrôle est une cible pour l'outil de suppression automatique. Et dans le peu de commercial .NET applications, j'ai médité sur les, ces "Trop trivial" contrôles apparaissent communs.

    Meilleur pari est de protéger en faisant partie du programme dépend de service web. Cela ne devrait pas être trop bavard interface pour éviter de ralentir l'exécution, mais il ne doit être ni très gros, comme ces morceaux pourraient être juste alors téléchargé et mis en cache localement dans la "version crackée" sauf si l'application dépend d'eux de changer fréquemment.

    Si vous voulez éviter de connectivité réseau (certaines utilisations ou les utilisateurs peuvent trouver que la problématique/discutable en fonction de l'application, sauf si c'est quelque chose que vous décrivez et apporte de la valeur), puis fractionnement de certains du programme dans une dll native ou deux et avoir la licence vérifie dans toutes les parties de l'application et moins de toute évidence, dans le natif de dll, serait probablement suffisant pour dissuader la plupart.