Tout d'abord, je comprends que presque toutes les applications peuvent être fissurées (en particulier écrites en C #). Ma question ici est de le faire un peu plus difficile de craquer. P>
Supposons que l'utilisateur a enregistré le fichier de licence sous l'application.StartuTutuPPath, où tous les utilisateurs peuvent lire. P>
Et puis, à chaque fois que l'application commence, elle vérifiera s'il peut trouver et vérifier le fichier de licence. P>
Si l'application peut trouver et vérifier, nous laissons l'utilisateur de continuer avec des fonctionnalités complètes. P>
Sinon, nous invitons une émission de MessageBox montrant "sans licence, continuez à utiliser avec la version d'essai, les fonctionnalités limitées" P>
Ma question est, si je suis un pirate informatique / cracker, j'essaierais de me déplacer ou de contourner le chèque de licence au lieu de craquer le fichier de licence, car, si nous utilisons la signature RSA, il est très difficile de craquer un fichier de licence. . p>
Alors, où devrions-nous mettre le chèque de licence? P>
P.s.: Et aussi, est-il en sécurité si je mettais une variable globale islicensed (vrai / faux) pour limiter les fonctionnalités? Est-il facile pour un pirate informatique de changer islicensed = TRUE? P>
4 Réponses :
Vous pouvez obgliger le code (rendez-vous plus difficile à décompiler / utiliser le réflecteur dessus), mais avec suffisamment d'énergie et de connaissances, il sera brisé, après cela, il est assez facile de changer le bytecode de l'Assemblée, qui contournent ainsi la Vérification de la licence. En outre, vous pouvez investir l'argent pour vous permettre de signer vos assemblées, ce qui rendrait plus difficile la modification de l'assemblage lui-même, mais avec suffisamment d'énergie (plus que casser l'obfuscation), cela peut également être contourné. P >
Votre objectif ne devrait pas être de rendre le processus de licence incassable, mais de rendre votre logiciel lui-même à acheter. C'est une protection bien meilleure. Crackers (et seulement eux, les pirates pirates sont quelque chose de complètement différent, voir Cet article a > Pour plus) ne sera pas entravé par cela, mais avec le logiciel en vaut la peine, beaucoup plus de gens l'achèteraient. P>
@Fermaref: Oui, je pense que l'obscurcissement du code rendra plus difficile à craquer.
La signature de code ne fait vraiment que plus difficile de tromper l'utilisateur à penser que les fichiers sont authentiques. Mais dans ce cas, l'utilisateur a l'intention d'utiliser une version fissurée, la signature de code ne fait donc rien.
Ce n'est pas correct Ben. La signature de code signifie que l'assemblage est fortement nommé, ce qui signifie qu'il fournit un moyen de vérifier l'authenticité, de sorte que le code IL ne peut pas être modifié, à moins que vous ne vous débarrassiez également du nom fort (qui, franchement, est possible). C'est juste un autre ralentissement (car toutes les références dans tous les assemblées doivent également être modifiées), mais avec suffisamment de temps, seront également cassés.
Non; Tout ce que vous avez à faire est sn -vr code> pour contourner la vérification.
Cela compte-t-il également des références de noms fortes dans les assemblées?
@Femaref: Je ne le dirais pas aussi i> Est-ce que cela. Sauter la vérification du nom fort est l'objectif principal de l'option -vr code>. Pas un effet secondaire, pas une réflexion après coup. Ignorer les noms forts dans les références de montage est ce qu'il fait.
Je pense que la vérification doit être effectuée dans plusieurs endroits différents dans le code source; Il est beaucoup plus difficile de les attraper que tout seul. En outre, si vous souhaitez protéger le programme écrit en C # (ou toute autre langue .NET), il faut envisager d'utiliser un obfuscator . Dans la contrepartie, un cracker ou même Lamer pourra craquer un programme à l'aide de certains logiciels comme .NET réflecteur p>
Je vais essayer d'obscurcir le code :-) Merci.
La loi n ° 1 de la licence de logiciels: vous ne contrôlez pas votre logiciel une fois que vous lui permettez d'être installé sur un ordinateur que vous ne contrôlez pas. P>
Si vous souhaitez continuer à contrôler votre code, vous devez en faire un service Web et donner à l'utilisateur final juste un client léger qui interface à ce service Web. P>
Dans de nombreux scénarios, cela est inacceptable, car les utilisateurs souhaitent pouvoir utiliser leur logiciel même lorsqu'ils n'ont pas de connexion Internet. P>
Dans presque tous les cas, vous devez vous concentrer sur l'expérience de l'utilisateur, et toutes les formes de protection contre la copie le rendent pire à la place. Une fois que vous arrivez au point où l'expérience de téléchargement à partir d'un site Warez et de l'exécution de plusieurs analyses de virus est meilleure que de faire la configuration de la licence pour la version légitime, vous avez perdu. P>
+1 aurait pu ne pas l'avoir dit mieux moi-même
Cette. Ce n'est pas bon de verser du temps à développer une protection contre la copie, car cette période aurait pu être utilisée pour le développement d'applications réel.
@Ben Voigt et Vash47: Je comprends ce que tu veux dire. Mais ici ce que je veux faire, c'est juste pour en faire un peu plus difficile à craquer. Il devrait y avoir des pensées de craquage triviales dans notre esprit.
@Peter Lee: Si tout ce que vous voulez, c'est de faire un "petit" plus difficile à craquer, utilisez un bon obfuscator (note: Dotfuscator n'est pas un très bon obfuscator).
@Peter: C'est une perte de temps. Si vous n'êtes pas un expert, vous passerez des heures à ralentir des craquelins dans quelques minutes. La cible la plus rentable est «Garder les honnêtes honnêtes honnêtes et ne vous inquiétez pas des craquelins», mais même cela dégrade un peu l'expérience de l'utilisateur.
En plus de cela: Si vous avez la peine de protéger quelque chose avec une protection de licence / copie vigilante, vous travaillez probablement sur quelque chose d'une valeur de milliers de dollars, ce qui implique plus ou moins que vous n'allez pas en solo. Même dans ce cas, je suggérerais presque que l'externalisation de la part de la licence à une entreprise spécialisée dans une entreprise. Mais un +1 pour ne pas vous inquiéter de beaucoup, et certainement un +1 pour s'assurer que votre protection contre la copie ne gâche pas l'expérience utilisateur de votre programme!
@Erik: Je suis d'accord. Je pense que certains logiciels professionnels tiers devraient fonctionner mieux que ce que j'ai :-)
Comme mentionné précédemment, on peut simplement utiliser le réflecteur .NET pour obtenir tout le code source de votre logiciel (en fait, il peut même l'obtenir dans vb.net ou dans d'autres langues, même si vous l'avez écrit en C #!) . Vous Qu'est-ce qu'il faut empêcher les gens de copier directement des licences? Si vous avez une licence signée, elle sera alors simplement signée à deux endroits - qu'avez-vous mis en place pour arrêter cela? Peu importe si une variable globale affaiblirait davantage votre protection sans prendre en compte des "fissures" triviales. P>
Il n'y a vraiment aucune bonne réponse à cela que Ben Voigt a souligné. Si vous avez besoin de quelque chose qui est incordable, faites-en une application Web à la source fermée. Astalavista vous montrera que la plupart des choses ont été fissurées. Les produits Adobe qui coûtent des milliers de dollars ont été fissurés et je suis sûr que leurs employés sont assez bien envers les techniques de protection de la copie. P>
Obfusquer le code est une bonne idée, mais je pense en même temps, mettre le chèque de licence quelque part devrait également rendre plus difficile à casser, ce qui est ma vraie question.
Related: Stackoverflow.com/q/506282/103167