La protection contre le cracking

Disons les choses telles quelles sont dès le début: tout logiciel peut être cracké, d'au moins du point de vue théorique. Ne croyez pas ces personnes qui essayent de vous convaincre de l'opposé, nous avons étudiés le cracking assez longtemps pour en savoir mieux. Cependant, il existe des manières de lui faire extrêmement difficile, surtout vis-à-vis du sujet temps. En effet, lARP64Pro le rend si dur et long qui jusqu'ici, aucun dossier protégé par lARP64Pro a été cracké déjà ! Bien que naturellement ... !
La plupart de codage est fait dans les langages de haut niveau (HLL) mais le cracking est fait dans les débuggeurs et les désassembleurs en langage assembleur. L'assembleur offre tant de possibilités qui ne sont pas ou à peine possibles dans les HLLs. Par conséquent, le code protecteur dans lARP64Pro a été également complètement codé en assembleur. Pour être complet, mentionnerons que le GUI est codé en .NET



lARP64Tech
x64 software protection shield
x64 compression
x64 protection
La rétro-ingénierie ... ou le cracking?


Un peu d'histoire

Le RCE «moderne» a commencé par les programmeurs qui ont évité le système anti-copie sur les jeux d'ordinateur classiques, comme ceux écrits pour Apple II au début des années 80. Bien que cette tendance soit rapidement devenue une manière de distribuer le logiciel piraté, un noyau d'experts qui a développé le champ de RCE purement pour des raisons scientifiques, est demeuré. En effet, on ne peut pas dire que ces personnes ont eu des buts faux avec leur travail.

Certaines figures légendaires de ces débuts étaient des rétro-ingénieurs génials, des auteurs prolifiques et des professeurs du sujet. Aujourd'hui, leurs textes classiques sont encore considérés de la lecture obligatoire pour des étudiants de RCE. Plus tard, une nouvelle génération de rétro-ingénieurs ont redécouvert les textes «antiques» et ont de nouveau commencé à avancer la science.

En tant que rétro-ingénieur de logiciel, on est seulement aussi bon que ses outils. Et RCE a énormément d'outils. Avant, les hex éditeurs étaient des outils communs. De nos jours, afin d'éditer des binaires dans l'hexadécimal qui est également connu comme opcode patching, on n'a plus besoin d'un hex éditeur. Encore de nos jours, l'édition des binaires est également possible sous débuggeur. Un programme débuggeur est en fait un outil désassembleur avancé offrant également les possibilités d'exécuter le code au souhait. Un outil désassembleur essaye de disséquer un binaire exécutable dans un langage d'assemblage lisible pour l'homme. Le logiciel désassembleur lit le processeur et l'analyse dans des groupes d'instructions. Ces instructions sont alors traduites en instructions de langage d'assemblage. Le désassembleur fait son travail avec des résultats variables. Néanmoins, c'est l'outil de base pour un cracker de logiciel. Cependant et comme dit avant, les programmes modernes à débugger ont des possibilités de désassembler intégrées. Le désassemblage est fait avec l'outil lui-même. On pourrait également mentionner des decompileurs comme outil d'un cracker, pourtant, les decompileurs sont rarement l'outil principal.

Beaucoup de logiciels commerciaux sont comprimés avec les «emballeurs» commerciaux afin de gagner de l'espace ou pour faire difficile aux crackers. Un bon exemple d'un emballeur gratuit est lARP64Free. Après un compresseur, le plus haut niveau à gêner les crackers est l'outil protecteur. Certains compriment et protègent en ajoutant toutes sortes de ruses au programme protecté. Les ruses utilisés par un outil protecteur peuvent être nombreux et sous beaucoup de différentes formes. Un bon exemple d'un compresseur-protecteur combiné est lARP64Pro.

La science de déballer les binaires comprimées et protégées est très complexe et comporte une catégorie entière de RCE.

Puisqu'il est illégal de défaire les droits d'auteur, les rétro-ingénieurs programment maintenant leurs propres arrangements d'enregistrement pour le cracking. Ainsi, les crackmes sont de petits programmes qui ne contiennent que l'arrangement de protection de régistration.

Après tout, en vue du cracking illégal, la question devient: et qui gagnera la bataille?
Les lois

La légalité de RCE est encore en question dans beaucoup de secteurs. La plupart des freewares et des logiciels commercials sont livrés avec un accord de licence d'utilisateur ou d'un EULA, exactement comme avec lARP64Free et lARP64Pro par example. Selon lARP64Tech et ces autres fabricants de logiciel, en cliquant sur «J'accepte» pendant l'installation du logiciel, on est contractuellement lié à accepter les limites d'autorisation. La plupart des EULAs incluent une clause qui empêche l'utilisateur d'exécuter de la rétro-ingénierie sur l'application afin de protéger la propriété intellectuelle du fabricant. Il n'y a aucun doute que dans ces cas où l'auteur interdit la rétro-ingénierie explicitement, les gens qui font la rétro-ingénierie quand-même, violent toujours la loi. En fait, le Digital Millennium Copyright Act (DMCA) fournit des pénalités criminelles dures pour quelques exemples de rétro-ingénierie. On pourrait soulever la question pourquoi tant de personnes risquent ces pénalités et semblent ne pas pouvoir arrêter ces actions criminelles. Voyons d'abord un peu l'histoire pour pouvoir répondre à cette question pressante.
La réponse est double: d'une part, les développeurs doivent utiliser un protecteur professionel pour protéger leurs logiciels contre le cracking. Pour la protection du logiciel de 64 bits, lARP64Pro est le premier choix. D'autre part, les développeurs devraient également appliquer quelques règles de base sur la vérification de l'enregistrement. Regardez mesures de protection pour les développeurs.
lARP64Tech

Ainsi, avec toute la discussion pour et contre décrite ci-dessus, quelle est la décision? Selon lARP64Tech, la réponse est claire: la rétro-ingénierie a en effet un droit d'exister. Mais ce droit va seulement jusque «mais ils doivent laisser seul mon propre logiciel!» En effet, et nous sommes très ferme en cela: personne n'a le droit de cracker un logiciel d'un autre développeur pour le distribuer gratuitement! Ces crackers peuvent aussi bien écrire leurs propres programmes «crackme» et cracker ceux-là. Il n'y a absolument aucun besoin de voler votre revenu et ces personnes n'ont certainement aucun besoin de jouer avec vos revenus résultant de votre labeur. Point final! Demandez à n'importe quel développeur qui en a souffert ce qu'il en pense! Il répondra immédiatement qu'il a perdu de l'argent, et pas peu mais souvent un tôt d'argent a été perdu!

Mais si les lois ne peuvent pas aider … que faire? Évidemment, il y a seulement une solution: les développeurs des logiciels eux-mêmes doivent protéger leur travail. Mais comment ?
Pour et contre

Il a été indiquée par des autorités dans le domaine que les crackers et les développeurs des mécanismes de protection ne sont pas simplement des adversaires … ils sont également des collègues. Si l'on suppose que les crackers sont des parasites parce qu'ils exploitent l'incapacité des programmeurs de construire des mécanismes de haute qualité de protection, alors on doit se rendre compte que les programmeurs sont également des parasites, exploitant l'incapacité des utilisateurs d'écrire des programmes!

La rétro-ingénierie avec l'emphase sur l'action illégale et la programmation avec l'emphase sur l'action légale, ont beaucoup en commun. La création des mécanismes de haute qualité et fiables de protection exige des qualifications de programmation de très haut niveau et la capacité de travailler avec le système d'opération, les conducteurs, l'équipement et la connaissance de l'architecture des processeurs, les dispositifs spécifiques de la génération de code typiques pour les compilateurs spécifiques, et la biologie des bibliothèques étant employées. À ce niveau de la programmation, la distinction entre la programmation et le cracking devient tellement trouble qu'il est à peine possible de tracer une ligne entre les deux.

Chaque protection, comme n'importe quel autre composant du logiciel, exige un essai profond et complet pour évaluer sa rentabilité. Dans ce contexte, la rentabilité est interprété comme la capacité de résister à des tentatives d'ouvrir une brèche par les crackers qualifiés, armé avec ou sans outils de cracking. La qualité de protection n'est pas évaluée par sa force mais par le rapport entre les heures de travail exigées pour créer l'application et les heures de travail exigées pour le cracker. En fin de compte, chaque système de protection peut être cracké, parce que cracking est seulement une question de temps, d'argent, des qualifications du cracker et d'effort. Cependant, la protection ne doit pas présenter des moyens faciles aux crackers. Et c'est exactement là que lARP64Pro vient dans le jeu: nous avons rendu lARP64Pro si fort et si long à cracker qu'il est à peine «crackable». Mais regardons d'abord plus d'arguments du point de vue du cracker.

Pour développer des mécanismes de protection, le programmeur doit avoir au moins une idée générale au sujet des méthodes de travail et des outils techniques employés par ses adversaires. Il est encore meilleur de maîtriser cet arsenal technique à un niveau supérieur que l'adversaire. L'expérience pratique (avec les outils de cracking) est fortement souhaitable parce qu'elle permet d'étudier la tactique et la stratégie, de ce fait permettant l'organisation d'une défense optimale. Elle permet simplement au programmeur de détecter et de renforcer les cibles les plus probables contre les attaques du cracker, concentrant au maximum les ressources intellectuelles disponibles. Ceci signifie que le fabricant des mécanismes de protection doit être inspiré par la psychologie: il doit penser comme le cracker!

Ainsi, maîtrisant la technologie d'information-protection assume maîtriser la technologie du cracking. Si vous ne savez pas comment les mécanismes de protection sont crackés, si vous ignorez ce que sont leurs vulnérabilités, et si vous n'avez aucune information sur l'arsenal du cracker, vous ne puissiez jamais créer un mécanisme de protection fort qui est peu coûteux et facile à mettre en application. L'étude du mauvais porte le bon à un niveau plus élevé. Et connaître l'ennemi rend vos défenses meilleures. En effet, nous avons étudié le cracking, ses outils et ses techniques, pendant des années. Nous sommes devenus habiles de penser comme un cracker afin d'être toujours une étape en avant de l'adversaire. Seulement l'étude prolongée et l'étude pour penser comme un cracker avec la seule raison de rester un pas en avant, nous a rendus capables de développer la technologie lARP64 !

Quand on demande aux crackers pourquoi ils crackent des logiciels, une des réponses les plus communes est qu'ils le font pour le défi et le tressaillement du succès. En outre, le cracking est pratiqué pour apprendre et devenir plus futé avec le logiciel. La plupart du temps, les crackers sont des personnes très futées qui travailleront à enlever la protection d'un logiciel pendant des jours, et dans certains cas même pendant des semaines, sinon même jusqu'au défi de celui. Le succès du cracker dépend presque toujours de sa motivation. Il peut étonner d'apprendre que la majeure partie de la motivation du cracker n'est pas financière. Après tout, les crackers passent leurs cracks et leurs informations pour rien. Ils ne gagnent pas d'argent en crackant un logiciel, bien que les personnes qui emploient leurs cracks en profitent. Plutôt que cracker pour le gain financier, les crackers participent en une sorte de concurrence sans cérémonie. Un cracker qui peut enlever un nouvel arrangement de protection très compliqué, devient une personne considérée et respectée au sein de la communauté des crackers.

Il y a une opinion commune que les publications au sujet des trous dans les systèmes de sécurité apportent plus de mal que de profit et qu'elles doivent être interdites. En d'autres termes, les défenseurs de cette opinion indiquent qu'ils ne peuvent pas créer un digne mécanisme de copie-protection et ne veulent pas admettre leurs erreurs.


Les lois peuvent-elles aider ?

Il est très difficile de tracer des barrières en cette matière mais des barrières doivent être tracées quelque part. Comme remarqué avant, la rétro-ingénierie a également une raison d'existence distincte et légale. Les lois existent et surgissent, ainsi surgit aussi la question si ces lois sont assez fermes et capables de repousser le mal quand il surgit … la réponse n'est pas immédiatement claire … . Voyons d'abord à ce que les défenseurs des crackers disent.

Les avocats de la loi sur les Droits d'Auteur disent qu'au plus les mécanismes de protection sont crackés, au plus le progrès dans le domaine de leur développement seront réalisés! Dans de telles conditions, les développeurs ont une motivation forte pour créer des paquets de protection de haute qualité et concurrentiels. Le dispositif de distinction de chaque protection de haute qualité est une description détaillée de son algorithme. Il n'y a aucun besoin de cacher les choses que chaque cracker peut révéler utilisant un programme débuggeur ou désassembleur. La recherche scrupuleuse sur le mécanisme de protection doit être bien accueillie. Après tout, il y a le concept de la perfection d'information des marchandises. Les tentatives de cacher des défauts et des inconvénients évidents sont illégales. Le bon gagne et en devient plus fort tandis que les mauvaises choses craignent les recherches comme la peste.

Il semble logique que la loi DMCA interdit la propagation des technologies, des dispositifs, et des services créés pour dévier les mécanismes existants de protection. Les avocats essaient de protéger le monde contre les criminels et les vandales évidents. Cependant, il est nécessaire de distinguer des activités de cracking et de recherches dans le domaine de la technologie informationnelle. Quelqu'un qui rétro-ingénie avec l'intention malveillante est au moins répréhensible, et mérite tout au plus d'être affiné ou même condamné à l'emprisonnement. Mais la pénalité doit être comparable aux dommages provoqués par le cracking. Il n'y a aucune nécessité de comparer des crackers avec des terroristes!
En tant qu'expert en matière de sécurité, pourquoi voudriez-vous apprendre la rétro-ingénierie du logiciel? Comme dit avant, la raison la plus commune est de renverser le logiciel malveillant tel que les virus ou les chevaux de Troie. Par exemple, l'industrie antivirus dépend de la capacité de disséquer des binaires afin de les diagnostiquer, désinfecter, et empêcher leur exécution. En outre, la prolifération du logiciel espion commercial non conformiste et les protections antipiracy qui «téléphonent à la maison» posent beaucoup de problèmes eux aussi.
Le problème

La rétro-ingénierie du logiciel, également connu comme la rétro-ingénierie du code, abbrévié comme RCE en anglais, est le «art» de disséquer et d'étudier des applications binaires. Les raisons pour la rétro-ingénierie sont plusieurs. Une des fonctions les plus importantes de RCE est la rétro-ingénierie des virus d'ordinateur, des vers, des chevaux de Troie, des publiciels et des logiciels espion ou tout autre forme de logiciel malveillant. La rétro-ingénierie est également commis parce que la documentation d'un dispositif particulier a été perdue ou n'a jamais été écrite, et la personne qui l'a établi n'est plus disponible. La seule manière d'incorporer ou d'étudier une nouvelle technologie peut être d'appliquer la rétro-ingénierie sur un logiciel. Il y a également l'analyse du produit pour examiner comment un produit fonctionne, de quels composants il se compose, etc. Il y a la sécurité du logiciel et n'oublie pas que dans l'industrie du logiciel antivirus, il y a «seulement» la rétro-ingénierie et à peine autre chose. De l'autre côté cependant, il y a également le système anti-copie, de la mise en échec des restrictions d'accès et de la création de reproductions non autorisées/inapprouvées. Contrairement au logiciel libre «open-source», le logiciel de source inconnu présente l'utilisateur avec une «boîte noire». Historiquement, RCE a été exécuté sur les plates-formes Windows, mais il y a maintenant un besoin croissant des experts de rétro-ingénierie pour Linux. En effet … le mot rétro-ingénierie a une signification double parce que la rétro-ingénierie peut aussi être une bonne chose parfaitement légale! D'une part, le mot «cracking» a presque toujours la signification de quelque chose illégale, d'une action frauduleuse.

Comme énigme: qui a indiqué qu'un créateur de virus ne devrait pas avoir des droits sur son travail lui aussi? Et où tracer la ligne s'il est légal ou pas de faire de la rétro-ingénierie sur le code d'un virus?

De toute façon, RCE permet de voir à l'intérieur de la boîte noire. En démontant une application binaire, on peut observer l'exécution du programme aux niveaux les plus bas. Une fois que l'application est décomposée en le langage de machine, un praticien habile peut tracer l'opération de n'importe quelle application binaire, peu importante la compétance de l'auteur qui essaye de la protéger.
Copyright (c) 2006-2010 lARP64Tech Software                                             All rights reserved

lARP64Pro accepte et même encourage de continuer à employer son propre système des licences. C'est parce qu'il serait plutôt stupide d'offrir seulement le schéma d'enregistrement de lARP64Pro. Même si cet arrangement le serait possible de l'appliquer avec des variations sur le thème. Nous avons constaté que ceci apporterait en effet seulement la facilité pour les crackers. Une fois qu'ils ont renversé un certain arrangement, il devient bien plus facile de toujours pouvoir casser le même schéma d'enregistrement du même protecteur qu'un nouvel schéma dans chaque nouveau programme. Et dans un tel cas, vous pouvez être sûr que n'importe comment difficile l'arrangement est, l'arrangement sera cassé tôt ou tard. Non, pas tôt ou tard mais plus tôt que plus tard! Par conséquent, nous avons délibérément visé la technologie lARP64 à protéger votre propre schéma d'autorisation !

lARP64Pro défend votre arrangement d'enregistrement par la technologie lARP64 qui totalise le code obscur avec toutes sortes de techniques avancées comme par exemple l'anti-dumping, l'anti-débugging et l'anti-désassemblage. Toutes ces techniques étant résultés de notre recherche interne.