Question

Ma question est assez simple: vous êtes un fichier exécutable qui affiche le message "Accès accordé". ou " Accès refusé " et des personnes malfaisantes tentent de comprendre votre algorithme ou corrigent vos entrailles afin de vous faire dire "Accès accordé". tout le temps.

Après cette introduction, vous vous demandez peut-être ce que je fais. Est-ce qu'il va craquer Diablo3 une fois qu'il est sorti? Je peux apaiser vos soucis, je ne suis pas un de ces craquelins. Mon but est de craquer.

Crackmes peut être trouvé sur - par exemple - www.crackmes.de. Un Crackme est un petit exécutable qui (la plupart du temps) contient un petit algorithme pour vérifier une série et une sortie "Accès accordé" ou " Accès refusé " en fonction de la série. L’objectif est de rendre cette sortie exécutable " Accès accordé " tout le temps. Les méthodes que vous êtes autorisé à utiliser peuvent être restreintes par l'auteur - aucune correction, aucun démontage - ou impliquer tout ce que vous pouvez faire avec un éditeur binaire, objdump et un éditeur hexadécimal. La fissuration est un aspect amusant, mais en tant que programmeur, je me demande bien comment vous pouvez créer des craquements difficiles.

En gros, je pense que le crackme comprend deux parties principales: une certaine vérification en série et le code qui l’entoure.

Il est très possible de suivre difficilement la vérification de la série en utilisant simplement l’assemblage. Par exemple, j’ai eu l’idée de prendre la série en tant qu’entrée pour un microprocesseur simulé qui doit se retrouver dans un certain état pour que la série soit acceptée. . D'autre part, on pourrait devenir bon marché et en apprendre davantage sur les moyens cryptographiquement puissants de sécuriser cette partie. Ainsi, rendre l’attaquant suffisamment difficile pour corriger le fichier exécutable ne devrait pas être t difficile.

Cependant, la partie la plus difficile est de sécuriser le binaire. Supposons une vérification en série parfaitement sécurisée qui ne puisse pas être inversée (bien sûr, je sais qu’elle peut être inversée, en cas de doute, vous extrayez des parties du fichier binaire que vous essayez de craquer et jetez-y des séries aléatoires jusqu’à ce qu’il accepte). Comment pouvons-nous empêcher un attaquant de simplement annuler des sauts dans le fichier binaire afin que notre fichier binaire accepte quoi que ce soit?

J'ai un peu cherché sur ce sujet, mais la plupart des résultats sur la sécurité binaire, l'auto-vérification des fichiers binaires, etc., aboutissent à des articles qui tentent de prévenir les attaques sur un système d'exploitation utilisant des fichiers binaires compromis. en signant certains fichiers binaires et en validant ces signatures avec le noyau.

Mes pensées consistent actuellement en:

  • vérifiant que des emplacements explicites dans le binaire sont des sauts.
  • somme de contrôle des parties du binaire et compare les sommes de contrôle calculées à l'exécution avec celles-ci.
  • ont des contrôles d’exécution positifs et négatifs pour vos fonctions dans le code. Avec des effets secondaires sur la vérification en série. :)

Pouvez-vous penser à plus de moyens d’ennuyer un éventuel attaquant plus longtemps? (Bien sûr, vous ne pouvez pas l'éloigner indéfiniment, certains moments, toutes les vérifications seront brisées, à moins que vous ne réussissiez à briser un générateur de sommes de contrôle en intégrant la somme de contrôle correcte pour un programme dans le programme lui-même, hehe.

Était-ce utile?

La solution

Vous entrez dans les "techniques anti-inversion". Et c'est un art fondamentalement. Pire, même si vous écrasez les débutants, il existe des "plug-ins anti-anti-inversion". pour olly et IDA Pro, ils peuvent télécharger et contourner une grande partie de vos contre-mesures.

Les contre-mesures incluent la détection du débogueur par les API d'interception du débogueur ou la détection du "pas à pas". Vous pouvez insérer du code qui, après avoir détecté un casse du débogueur, continue de fonctionner, mais commence à agir à des moments aléatoires bien plus tard dans le programme. C’est vraiment un jeu de chat et de souris et les crackers ont un avantage considérable.

Découvrez ... http://www.openrce.org/reference_library/anti_reversing - Quelques exemples de ce qui existe.

http://www.amazon.com/Reversing-Secrets-Engineering-Eldad- Eilam / dp / 0764574817 / - Ce livre contient une très bonne information anti-retour et décrit les techniques. C'est un bon endroit pour commencer si vous avez l'habitude de faire marche arrière.

Autres conseils

Je pense que ces problèmes sont généralement plus problématiques qu'ils ne valent.

Vous passez beaucoup de temps à écrire du code pour protéger votre binaire. Les méchants dépensent moins d'effort pour le réparer (ils sont généralement plus expérimentés que vous), puis libèrent le crack pour que tout le monde puisse contourner votre protection. Les seules personnes que vous ennuierez sont les personnes honnêtes qui sont gênées par votre protection.

Voyez le piratage comme un coût commercial: le coût supplémentaire des logiciels piratés est nul si vous veillez à ce que toute l'assistance ne soit fournie qu'à des clients payants.

Il existe une technologie TPM: tpm sur wikipedia

Il vous permet de stocker les sommes de contrôle cryptographique d'un fichier binaire sur une puce spéciale, ce qui pourrait servir de vérification à sens unique.

Remarque : le TPM est en quelque sorte un mauvais coup parce qu'il pourrait être utilisé pour la gestion des droits numériques. Mais pour les experts sur le terrain, c'est injuste, et il existe même un open-TPM , un groupe permettant aux utilisateurs de Linux de contrôler exactement comment leur puce TPM est utilisée.

L’une des solutions les plus efficaces pour résoudre ce problème est Trusted Computing . En gros, vous devez chiffrer l'application et transmettre la clé de déchiffrement à une puce spéciale (le module de plateforme fiable . ), La puce ne décrypterait l’application qu’après s’être assurée que l’ordinateur se trouvait dans un emplacement "de confiance". état: pas de visualiseurs / éditeurs de mémoire, pas de débogueurs, etc. En principe, vous aurez besoin d’un matériel spécial pour pouvoir visualiser le code du programme déchiffré.

Donc, vous voulez écrire un programme qui accepte une clé au début et la stocke en mémoire, puis la récupère du disque. Si c'est la bonne clé, le logiciel fonctionne. Si c'est la mauvaise clé, le logiciel se bloque. L’objectif est qu’il est difficile pour les pirates de générer une clé de travail et qu’il soit difficile de corriger le programme pour qu’il fonctionne avec une clé sans licence.

Ceci peut effectivement être réalisé sans matériel spécial. Considérons notre code génétique. Cela fonctionne sur la physique de cet univers. Nous essayons de le pirater, de créer de la drogue, etc., et nous échouons lamentablement, en créant généralement des tonnes d'effets secondaires indésirables, car nous n'avons pas encore complètement inversé le système complexe "monde". dans lequel le "code" génétique a évolué pour fonctionner. Fondamentalement, si vous utilisez tout sur un processeur commun (un "monde" commun), accessible à tous, il est pratiquement impossible d'écrire un tel code sécurisé, comme le prouve le logiciel actuel craquant si facilement.

Pour assurer la sécurité des logiciels, vous devez essentiellement écrire votre propre plate-forme suffisamment complexe, ce que les autres utilisateurs doivent procéder à un reverse engineering complet et approfondi afin de modifier le comportement de votre code sans effets secondaires imprévisibles. Une fois que votre plate-forme est désossée, vous revenez à la case départ.

Le problème, c'est que votre plate-forme fonctionnera probablement sur du matériel commun, ce qui facilite son ingénierie inverse, ce qui simplifie également le code. Bien entendu, cela peut simplement signifier que la barre est un peu levée pour que le niveau de complexité requis de votre plate-forme soit suffisamment difficile à inverser.

À quoi ressemblerait une plate-forme logicielle suffisamment complexe? Par exemple, peut-être après toutes les 6 additions, la 7ème addition renvoie le résultat multiplié par PI divisé par la racine carrée du log du module 5 de la différence du nombre total d'opérations de soustraction et de multiplication effectuées depuis l'initialisation du système. La plate-forme devrait garder une trace de ces numéros indépendamment, tout comme le code lui-même, afin de décoder les résultats corrects. Ainsi, votre code serait écrit en fonction de la connaissance du comportement sous-jacent complexe d'une plate-forme que vous avez conçue. Oui, cela prendrait des cycles de processeur, mais quelqu'un devrait désosser ce petit comportement inattendu et le reconfigurer dans n'importe quel nouveau code pour qu'il se comporte correctement. En outre, votre propre code serait difficile à modifier une fois écrit, car il se transformerait en une complexité irréductible, chaque ligne dépendant de tout ce qui s'est passé auparavant. Bien entendu, une plate-forme suffisamment sécurisée serait beaucoup plus complexe, mais le fait est que quelqu'un devrait procéder à l'ingénierie inverse de votre plate-forme avant de pouvoir procéder à l'ingénierie inverse et à la modification de votre code, sans effets secondaires débilitants.

Excellent article sur la protection contre la copie et la protection Garder les pirates à distance: Mise en œuvre de la protection anti-fissure pour Spyro: l'année du dragon

L’idée la plus intéressante mentionnée ici et qui n’a pas encore été mentionnée est celle des échecs en cascade: vous avez des sommes de contrôle qui modifient un seul octet et qui entraînent l’échec d’une autre somme de contrôle. Finalement, l’une des sommes de contrôle provoque le blocage du système ou des actions étranges. Les tentatives de piratage de votre programme semblent donc instables et la cause en est éloignée du crash.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top