begin process at 2012 05 24 02:50:00
  Trouver un code source :
 
dans
 
Accueil > 

Code

 > 

Sécurité & Cryptage

 > EXÉCUTABLES SE VÉRIFIANT LORSQU'ILS SONT LANCÉS

EXÉCUTABLES SE VÉRIFIANT LORSQU'ILS SONT LANCÉS


 Information sur la source

Note :
10 / 10 - par 2 personnes
10,00 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10
Catégorie :Sécurité & Cryptage Niveau :Initié Date de création :27/02/2005 Vu / téléchargé :7 699 / 603

Auteur : Nebula

Ecrire un message privé
Site perso
Commentaire sur cette source (12)
Ajouter un commentaire et/ou une note

 Description

Un petit exercice de style : calculer le hash MD5 d'un fichier exécutable, et vérifier au lancement de ce dernier si sa signature actuelle correspond à celle qui a été mémorisée. Si les calculs ne correspondent pas, c'est que l'exe a été modifié (un simple bit fausse le calcul).

Comment ? Hé bien, un programme "sign" se charge de calculer le hash MD5 d'un autre exécutable, et injecte dans ce dernier une signature (l'empreinte MD5, voir ma source précédente pour plus de détails) dans une partie inutilisée de l'entête MZ (le tableau e_res2, pour ceux à qui cela dit quelque chose). Bien sûr, lors du calcul cette zone est mise à zéro afin de ne pas fausser les empreintes...

Ensuite lors de l'exécution, le programme signé hashe le fichier qui a serci à créer son processus et compare l'empreinte MD5 qu'il trouve à celle qui est mémorisée, et peut agir en conséquence (corrompu : afficher un warning et laisser le choix à l'utilisateur de continuer l'exécution ou pas, intègre : continuer l'exécution).

Bien sûr, cette petite astuce n'est que de peu d'efficacité contre un "cracker" confirmé, mais elle peut servir à assurer l'intégrité d'un exe téléchargé ;-)


 Conclusion

Contenu du ZIP :

bon.exe = un binaire signé, dont le test automatique devrait réussir
mauvais.exe = le même binaire mais non signé, évidemment le test va échouer
sign.exe = le programme qui signe les autres, sign <nom des programmes>

check\* = les sources de bon.exe et mauvais.exe, seul le fichier main.c contient la routine de vérification

sign\* = les sources de sign.exe, idem seul main.c contient la routine de signature

Dans les deux dossiers, assert.* correspond aux assertions (des fonctions permettant de vérifier simplement les retours d'API et de savoir ce qui ne va pas en cas d'erreur) et console.* permet d'utiliser la console en Unicode (avec accents, donc). Quand à config.h, je vous laisse deviner ;-)

Codé avec GCC, mais devrait compiler sous n'importe quel compilateur C.

 Fichier Zip

Les Membres Club peuvent télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

Télécharger le zip


 Sources du même auteur

Source avec Zip ÉNUMÉRATION DES PROCESSUS ET DÉCHARGEMENT FORCÉ DE DLL
Source avec Zip Source avec une capture RICHEDIT AVEC SUPPORT DES THÈMES XP
Source avec Zip CALCUL DE HASH MD5 (WIN32)
Source avec Zip VÉRIFIER QUE L'UTILISATEUR EST ADMINISTRATEUR
Source avec Zip KILL ANY PROCESS

 Sources de la même categorie

PROJET DE CRYPTOGRAPHIE: RSA À JEU REDUIT D'INSTRUCTION par samatarahmed
Source avec Zip Source avec une capture CRYPTOSYSTÈME ELGAMAL LIBRAIRIE GMP par louelh95
Source avec Zip Source .NET (Dotnet) NOUVEL ALGORITHME D'ENCRYPTION-DÉSENCRYPTION DYNAMIQUE (INFA... par vletktol
Source avec Zip A2DCRYPT - CRYPTAGE 2048 BITS par darkor
Source avec Zip Source avec une capture CRYPTEUR-DÉCRYPTEUR-IP par antho974

Commentaires et avis

Commentaire de NitRic le 27/02/2005 06:31:35

Tu devrais peut-être revoir l'utilité de `assert()` ... C'est carrément de l'abus dans le cas présent :P

Commentaire de Nebula le 27/02/2005 06:55:57

C'est vrai que j'abuse un peu, mais j'ai déjà trouvé des choses assez surprenantes grâce à cette petite macro... Et vu qu'il n'en reste aucune trace en mode release si on définit la macro NDEBUG, pourquoi se priver ;-)

Commentaire de vecchio56 le 27/02/2005 10:56:42 administrateur CS

Je m'y connais pas du tout en emprunte MD5, mais il est forcément possible que 2 fichiers différents aient la même signature, si des changements se compensent... sans doute dans une probabilité très faible?

Commentaire de LordBob le 27/02/2005 11:56:21

j'aimerais juste savoir ce que c'est un MD5, je vois ca très souvent, mais je ne sais jamais ce que c'est?

Commentaire de Nebula le 27/02/2005 12:21:07

Vecchio56 > Il paraît que la probabilité d'avoir la même empreinte pour une variation du fichier original est extrêmement faible, pour ainsi dire inexistante. Mais elle existe oui, et pour l'éviter il faudrait se tourner vers des algorithmes plus perfectionnés comme SHA. En tout cas elle est bien plus faible qu'avec un CRC, de ce que j'ai pu en lire.

LordBob > Un hash MD5 c'est un calcul perfectionné qui a lieu sur des données (ici, un fichier) et qui permet d'en extraire en quelque sorte une "empreinte digitale" sur 128 bits, cette empreinte étant hautement variable : si tu re-hashes le fichier en en modifiant seulement un bit, elle va être totalement changée... Plus d'informations (y compris la méthode de calcul) sur ce site http://abcdrfc.free.fr/rfc-vf/rfc1321.html

Commentaire de NitRic le 27/02/2005 21:06:29

Oui, c'est vrai, en release il n'y à plus de `assert()` mais, tu n'a aucune validation, gestion d'erreur, etc ... en release. Que préfère tu? Un soft `bogué` en release ou ~fonctionnel en debug?

Commentaire de Nebula le 27/02/2005 21:40:44

Ah oui, mais je ne laisse évidemment pas tout çà en release... J'essaie quand même de gérer toutes les erreurs qui peuvent survenir, avec une reprise possible dans la plupart des cas. Mais lors de la mise au point, je trouve (à mon sens, je conçois qu'on puisse le contester) que les assertions sont bien suffisantes : on s'occupe de gérer les erreurs quand le code marche, tant que ce n'est pas le cas çà ne sert à rien...

Désolé d'avoir mal interprété le sens de ton premier commentaire ;-)

Commentaire de magic_Nono le 02/03/2005 09:13:13

bien,

conseil pour plus tard Nebula

si tu as des sources identiques pour plusieurs fichiers, fais en une librairie simple cad un répertoire ou tu rassemble ces fichiers.

dans ton zip, seuls les main.c sont différents...

après, les assert sont bien à utiliser pour les débug, mais il n'empèchent pas de réaliser des conditions ou exceptions

si tu les conserves à l'avenir, utilise les uniquement pour assurer les préconditions de tes fonctions.
et évidemment, avant de produire ta version finale, ils ne doivent plus lever le moindre pb

++
Nono

Commentaire de bbear le 12/06/2006 16:02:02

Excellent
z'êtes trop fort :)

par contre, j'ai testé avec des packers d'exe :
ça passe avec upx et aspack mais pas avec Mew
y aurait un moyen ? (il doit modifier l'entete, supprimer la zone inutilisée... faut dire que quand il compacte, il compacte !!)

autre question : le #define UNICODE dans config.h est obligatoire si le prog n'est pas en mode console? car ça fait scratcher le texte d'une message box

Commentaire de Nebula le 03/08/2006 13:57:45

Non, l'unicode n'est pas obligatoire... Il permet juste d'afficher des accents dans la console ;)

Après çà dépend du packer... De toute façon un packer change l'exe, donc il faut réinjecter le MD5 après avoir packé l'exe je pense... Pas vraiment testé cette option :)

Commentaire de Rudy3212 le 23/07/2008 13:48:07

md5 n'est plus fiable, dans une utilisation courante tomber 2 fois sur le même md5 c'est rare, mais en bidouillant on arrive facilement a crée 2 exe qui ont le même md5.

Comme cette exemple :
http://www.mscs.dal.ca/~selinger/md5collision/hello.exe
et
http://www.mscs.dal.ca/~selinger/md5collision/erase.exe

2 exe différents qui ont le même md5, la procédure pour réaliser cela est ici :
http://www.mscs.dal.ca/~selinger/md5collision/

Donc ton programme ce basant sur le md5 n'est pas très fiable, il faudrai que tu change l'algo et après c'est impec ;)

Commentaire de Rudy3212 le 28/07/2008 22:46:52

Sa date, j'avais pas fait gaffe a la date :o

 Ajouter un commentaire




Nos sponsors


Sondage...

Comparez les prix

CalendriCode

Mai 2012
LMMJVSD
 123456
78910111213
14151617181920
21222324252627
28293031   

Consulter la suite du CalendriCode

A découvrir



 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 1,778 sec (4)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales