Tout le monde connais les differents checksum introduit pas certains packers ou par les programmeurs eux-mêmes dans leurs codes.
Il existe un autre type de test d'intégritée plus formel introduit pas Microsoft, il s'agit de l'Authenticode qui est simplement une signature numérique intégrée aux fichiers executables (EXE's,DLL's,OCX's).
Si vous vous demandez a quoi ressemble ce genre de signature il vous suffit d'ouvrir le dossier %SYSTEMROOT%\system32\ et d'aller chercher le fichier "LegitCheckControl.DLL", ce fichier servant au WGA (Windows Genuine Advantage) est signé comme la plupars des binaires 'sensible' et récents délivrer pas Microsoft.
Faite un click droit dessus, et observez l'onglet "Signatures numériques" regarder le signataire, puis clickez sur "Détails".
Dans détails on peut voir qu'il s'agt d'un certificat RSA intégré au fichier, l'empreinte numérique du fichier est hachée suivant le modéle SHA1.
Si vous voulez signé vos propres binaires, recherchez sous Google le paquetage "codesigningx86", il vous faudra générer un certificat puis l'intégrer a l'executable (Authenticode).
Vous allez me dire j'usque la tout va bien, on s'en carre que MS signe ses binaires.
Je suis d'accord, mais la ou ca se corse c'est quand M$ décide d'intégrer au binaire un algorithme de vérification du dit certificat.
J'ai pu observez cela sur les nouveaux produits de chez M$, par exemple Internet Explorer 7 Beta 2 contient une vérification de votre clé (WGA) avant d'autoriser l'installation, quand on patche en RAM sous Olly par exemple, on peut outre-passer cette vérification (normal le binaire reste intact), mais si on entreprend figé cette modif en hard (sur le dur) le binaire refuse de fonctionner de maniere totalement silencieuse (pas de notification), cette vérification d'intégrité ne se limite pas a la section code, mais a tout le binaire.
J'ai donc entrepris de comprendre le fonctionnement de la routine en charge de vérifié l'Authenticode, comme je ne connaissez pas les API utilisé j'ai fait un tour par le table d'import, R-A-S, pas d'API chelou en vue.
Aprés quelques recherches et pas mal d'API Spy, j'ai découvert les API principales mises en oeuvre pour la vérification des certificats, il s'agit de par ordre d'appel :
- Code: Tout sélectionner
WINTRUST.DLL : WinVerifyTrust // En charge de vérifier que la signature n'est pas brisée (par un hard patch par ex)
CRYPT32.DLL : WTHelperGetProvSignerFromChain // En charge de récuprer le signataire et le contre-signataire s'il existe.
CRYPT32.DLL : WTHelperProvDataFromStateData // En charge de vérifier la contre-signature d'un certificat.
CRYPT32.DLL : CertVerifyCertificateChainPolicy // Et enfin cette API vérifie l'ensemble de la chaine de certification (emeteur, signataire,contre-signataire).
De la bouche meme de microsoft : This function has no associated import library. You must use the LoadLibrary and GetProcAddress functions to dynamically link to Wintrust.dll or Crypt32.dll.
N'esperez donc pas les voir apparaitres dans l'IT.
Un kit de sources et d'exmples permettant ce genre d'implentation dans vos codes s'appelle "CAPICOM" et est disponible chez Microsoft.
Bref si vous patchez un programme signé numériquement et qu'il refuse de se lancer par la suite ou n'a pas le même comportement dans un débugger qu'une fois modifié, posez un bp sur l'API WINTRUST.DLL:WinVerifyTrust car c'est elle qui est appelé en premier, vérifiez les paramettres d'appel passer a l'api afin de connaitre le fichier a vérifié (les prototypes des fonctions sont dispo chez M$), puis sortez du call et empechez / forcez le saut.
Voila je voulais simplement vous faire partager ma découverte, sur ce j'éspere que je vous ai pas trop saouler
Merci pour l'info mr tux
merci pour cette information.
une protection peut etre plus serieuse 
par exemle il y a pas longtemps j'ai du faire une pseudo etude sur les anti-spyware et la paf wga veut mettre a jour des fichiers et comme j'utilisait une version d'eval d'XP impossible de faire quoi que ce soit ! et meme office 12 le recherche cette chose !!!