Je travaille actuellement sur un projet où je dois créer une certaine architecture, cadre ou toute normale que je peux "au moins" augmenter la méthode de fissuration pour un logiciel, c'est-à-dire d'ajouter à la sécurité logicielle. Il existe déjà des façons différentes d'activer un logiciel qui inclut une activation en ligne, des clés, etc. J'étudie actuellement peu de documents de recherche. Mais il y a encore beaucoup de choses que je veux discuter.
Quelqu'un pourrait-il me guider dans un forum décent, une liste de diffusion ou quelque chose comme ça? ou toute autre aide serait appréciée.
7 Réponses :
N'est-ce pas un signe de succès lorsque votre produit est fissuré? :)
Sérieusement, mais une approche consiste à utiliser des objets de licence sérialisés à XML, puis cryptés à l'aide de paires de clés publiques / privées. Ils sont ensuite relués au moment de l'exécution, dés-sérialisé et traité pour s'assurer qu'ils sont valides.
mais il y a toujours la méthode omniprésente "isvalid ()" qui peut être fissurée pour toujours retourner vrai.
Vous pouvez même mettre cette méthode dans un assemblage signé pour empêcher la falsification, mais tout ce que vous avez fait, c'est créer une autre couche de "isvalid ()" qui peut aussi être fissurée.
Nous utilisons des licences pour activer ou désactiver diverses fonctionnalités de notre logiciel et pour valider les périodes de support / mise à niveau. Mais ce n'est que pour nos clients légitimes. Toute personne qui veut le contourner cela pourrait probablement.
Nous faisons confiance à nos clients légitimes pour ne pas essayer de contourner la licence et nous acceptons que nos clients illégitimes trouveront une manière.
Nous allons perdre plus d'argent à tenter d'imposer la nature «preuve d'inviolation» de notre solution que nous perdons aux personnes qui pirent des logiciels.
Plus, vous devez considérer la douleur à nos clients légitimes et leur demander de coller une chaîne de licence de leur page de compte en ligne est autant de douleur que je voudrais les mettre à travers. Pourquoi créer des obstacles supplémentaires à l'entrée pour les clients potentiels?
Quoi qu'il en soit, selon la solution que vous avez déjà mise en place, ma description ci-dessus pourrait vous donner des idées qui pourraient diminuer la probabilité que quelqu'un craque votre produit.
Oui, je comprends la douleur et je craque la méthode "Validate". Je sais que faire une chose ultime à la résistance à la fissure n'est pas possible tant que votre validation dépend de certains calculs mathématiques et de certaines communications entre serveur et client, car Communicaton peut être bloquée et que les mathématiques peuvent être ingénieur de reserge. Le point que je recherche toute la solution possible ou un peu de forum où je peux discuter de différentes choses avec des geeks qui y travaillent déjà.
Je vais vous dire la chose la plus proche de "crier": une application Web.
Les applications de bureau sont condamnées, pour de nombreuses autres raisons, mais rendez votre application "dans le nuage", dans un navigateur, vous donne beaucoup plus de contrôle de la sécurité.
Un logiciel de bureau s'exécute sur l'ordinateur du client, le client l'accède pleinement. Une application Web s'exécute sur votre serveur, de sorte que le client ne voit qu'un peu de celui-ci.
En outre, si vous avez absolument besoin d'une application de bureau. Vous pouvez également faire fonctionner certaines fonctionnalités principales sur un serveur distant. De cette façon, l'utilisateur ne peut fonctionner que lorsque vous le laissez, et vous pouvez révoquer l'accès à distance. Bien sûr, cela signifie que l'application ne fonctionnera que lors de la connexion en ligne. Mais bon, c'est le 21ème siècle, qui est hors ligne?
Quiconque vit dans une banlieue avec de vieux câbles, souterrains dans lesquels l'eau devient chaque fois qu'il pleut lourdement ...
Comme d'autres personnes ont mentionné, une fois que vous avez libéré les bits aux utilisateurs, vous en avez abandonné le contrôle. Un pirate informatique dédié peut changer le code pour faire ce qu'ils veulent. Si vous voulez quelque chose qui est plus proche de la crise, ne libérez pas les bits aux utilisateurs. Gardez-le sur le serveur. Fournissez un accès à l'application via Internet ou, si l'utilisateur a besoin d'un client de bureau, gardez des bits critiques sur le serveur et donnez-leur accès via des services Web.
Comme les autres l'a dit, il n'ya aucun moyen de créer un logiciel complet à la fissure, mais il existe des moyens de faire craquer le logiciel plus difficile; La plupart de ces techniques sont en fait utilisés par les méchants pour masquer les logiciels malveillants à l'intérieur des fichiers binaires et par des sociétés de jeu pour faire craquer et copier les jeux plus difficiles.
Si vous êtes vraiment sérieux de le faire, vous pouvez vérifier par exemple, quels emballeurs exécutables comme UPX font. Mais alors vous devez également mettre en œuvre le déballum! Je ne recommande pas de faire cela, mais étudier les protections de jeu et l'obfuscation binaire pourrait vous aider dans votre quête.
Merci beaucoup. C'est un conseil utile et une nouvelle directive :)
Vous devez commencer par infiltrer le gang de piratage local, posant comme un enfant de 11 ans qui veut "pirater la hacelle". Une fois que vous avez gagné leur confiance, vous pouvez apprendre quelles caractéristiques ils trouvent la plus difficile à craquer. Lorsque vous libérez secrètement un logiciel "indemnable" aux cartes de message locales, vous pouvez voir ce qu'ils font avec elle. Construisez votre connaissance intérieure jusqu'à ce qu'ils ne puissent plus craquer votre logiciel. Lorsque cela est fait, laissez votre identité connue. Idéalement, cela sera considéré comme un signe de trahison, que vous travaillez contre eux. Espérons que cela les amènera à contacter d'autres pirates en dehors de la communauté locale pour attaquer votre logiciel.
Continuez jusqu'à ce que vous ayez atteint le haut de la mafia hacker. Écrivez votre thèse comme un livre, vendez à HBO.
lol .... puis-je obtenir des contacts souterrains de cette mafia?
Comme indiqué nute, tout code que vous publiez sur la machine d'un client est fissuable.
N'essayez pas de "inscrancable". Essayez de "il y a assez de dissuasion pour protéger raisonnablement mes actifs".
Il y a beaucoup de façons que vous pouvez essayer d'augmenter le coût de la fissuration. la plupart d'entre eux vous coûtent, mais une chose que vous pouvez faire cela réduit vos coûts tout en augmentant le coût de la fissuration: livrer souvent.
Il y a un coût fini pour craquer tout binaire donné. Ce coût est augmenté par le nombre de binaires étant fissurés. Si vous publiez de nouvelles fonctionnalités chaque semaine, vous bifurciez essentiellement vos utilisateurs en deux groupes:
En participant aux techniques anti-craquelations traditionnelles, vous pouvez multiplier le coût de la fissuration d'un binaire an, par conséquent, élargir l'écart entre le moment où une nouvelle fonctionnalité est libérée et lorsqu'elle est disponible sur le marché noir. Pour top tout, vos coûts vont diminuer et la quantité de valeur que vous livrez dans une période de temps sera montée - c'est ce qui le rend gratuit.
Plus vous libérez le plus souvent, plus vous constaterez que la qualité et la valeur montent, le coût diminue et les personnes moins susceptibles de voler votre logiciel.
+1 pour "livrer souvent", plus de nombreux autres grands points de ce post.
+1 à votre +1 pour être d'accord avec moi. :)
Tout d'abord, dans quelle langue écrivez-vous cela? Il est vrai qu'un programme à la fissure est impossible à réaliser, mais vous pouvez toujours le rendre plus difficile. Une approche naïve de la sécurité des applications signifie qu'un programme peut être fissuré en quelques minutes. Quelques conseils:
Si vous déployez sur une machine virtuelle, c'est dommage. Il n'y a pas beaucoup de variantes là-bas. Tous les VMS populaires (Java, CLR, etc.) sont très simples à décompiler et qu'aucun obfousciateur ni la signature ne suffit.
Essayez de découpler autant que possible la programmation de l'interface utilisateur avec le programme sous-jacent. Il s'agit également d'un excellent principe de design et rendra le travail du cracker plus fort de l'interface graphique (par exemple, entrez votre fenêtre série) pour suivre le code où vous effectuez réellement le chèque
Si vous compilez un code de machine natif réel, vous pouvez toujours définir la construction en tant que version (ne pas inclure aucune information de débogage n'est cruciale), avec optimisation le plus élevé possible. Également dans les parties critiques de votre application (par exemple lorsque vous validez le logiciel), assurez-vous d'en faire un appel de fonction inline, de sorte que vous ne vous retrouvez pas avec un seul point d'échec. Et appelez cette fonction de nombreux endroits différents dans votre application.
Comme il a été dit auparavant, les emballeurs additionnent toujours une autre couche de protection. Et bien qu'il existe de nombreux choix fiables, vous pouvez finir par être identifié comme un virus faux positif par certains programmes anti-virus, et tous les choix célèbres (par exemple UPX) ont déjà assez de déballumers simples.
Il y a quelques astuces anti-débogage que vous pouvez également rechercher. Mais ceci est un problème pour vous, car à un moment donné, vous devrez peut-être aussi déboguer l'application de libération!
Gardez à l'esprit que votre priorité est de rendre la partie critique de votre code aussi introuvable que possible. Cordes de texte clair, appels de bibliothèque, éléments d'interface graphique, etc. Ils sont tous des points où un attaquant peut utiliser pour tracer les parties critiques de votre code.
Vous allez vous faire craquer de toute façon si le logiciel vaut quelque chose. Êtes-vous sûr de vouloir rendre l'expérience pire pour les utilisateurs en ajoutant une autre couche de chèques / activation? (Pour autant que je sache, vous avez déjà une activation en ligne et des clés ... ce qui semble suffisant) le logiciel "anti-crack" est un mythe - il ne peut pas sortir.
J'aurais un bon coup d'œil sur les différentes discussions sur ce sujet même. Cette question récolte un lot
Changer une carrière n'est pas une option, c'est la question de terminer ma maîtrise et c'est mon projet de recherche.
Il n'y a pas de "logiciel" anti-craquement ". Tout est question de savoir combien d'effort contre le coût pour l'achat / la licence.
Je pensais juste que c'était drôle. [UBISOFTS NOUVEAU DRM a craqué en moins de 25 heures] Infoaddict. com / ubisofts-new-drm-fissuré-in-moins de 25 heures