Exécutables se vérifiant lorsqu'ils sont lancés
Soyez le premier à donner votre avis sur cette source.
Vue 9 665 fois - Téléchargée 803 fois
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é ;-)
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.
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é ;-)
Source / Exemple :
goto zip;
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.
Codes Sources
A voir également
- Exécutables se vérifiant lorsqu'ils sont lancés
- Lancés de dés ✓ - Forum C++ & C++ .NET
- Fichier jnlp ne se lance pas ✓ - Forum Java
- Jar signé, Jnlp ok mais ca se lance toujours pas - Forum Java
- Erreur de chargement d'un fichier avec Java Web Start - Forum Java
- Execution du fichier jnlp - Forum Java
28 juil. 2008 à 22:46
23 juil. 2008 à 13:48
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 ;)
3 août 2006 à 13:57
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 :)
12 juin 2006 à 16:02
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
2 mars 2005 à 09:13
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
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.