Discussion :

[eric_marciano]

Bonjour,
J'ai un code très simple que je compile et link, qui donne donc un premier exe en résultat (en mode release). 2 minutes plus tard, je recompile exactement le même code, ce qui donne un autre exe.
Les 2 exe fonctionnent évidemment de façon identique, leur taille est identique aussi, mais en comparant les 2 fichiers exe on voit qu'il y a quelques octets différents par ci par là (4 différences en tout). Je voudrais bien savoir comment éviter cela. A priori ce n'est pas gênant car le comportement est toujours le même, mais comme je cherche à faire un checksum sur l'exe, le fait qu'il y ait des différences à chaque compilation me dérange fortement.

Savez-vous comment l'éviter?

Pour info, j'ai fait le test avec un petit projet Win32 Console qui affiche juste "Hello World". J'ai laissé les options par défaut qui font que je link avec uuid.lib. Pensant que ça venait de là, j'ai ignoré uuid.lib dans les options de link, mais le problème subsiste...

Toute aide est la bienvenue

Merci,
Eric

[Malinaka]

Bonjour,
Utilises tu un IDE pour faire ton exe? Parfois les IDE peuvent rajouter des en tête. Cela pourrait expliquer les différences.

[eric_marciano]

Bonjour,
Utilises tu un IDE pour faire ton exe? Parfois les IDE peuvent rajouter des en tête. Cela pourrait expliquer les différences.

Ah oui, j'ai oublié de préciser ça: j'ai fait le test avec Visual Studio 2003 et 2008. Dans les 2 cas, quasiment le même résultat.
Et effectivement c'est Visual Studio qui me met par défaut la lib uuid.lib à l'édition de liens.

Eric

[bacelar]

Cela n'a rien à voir avec l'IDE, qui n'est qu'un éditeur amélioré.

La différence entre les exécutables est très probablement le timestamp de génération que le linker initialise pour avoir une traçabilité correcte des éléments compilés.

Ce n'est pas parce que le code source n'a pas changé que le résultat est identique. La configuration du projet, de l'environnement de compilation sont au moins aussi important que le code source.

Normalement, si aucune modification n'est faite dans les sources et dans la configuration des projets, VS ne recompile pas l'exécutable.

Il régénère l'exécutable s'il y a des modifications ou si vous lui forcez la main.
Et à chaque régénération, le linker met un nouveau timestamp.

Cela est extrêmement pratique quand vous utilisez un serveur de symbole et un serveur de code source hébergé dans un gestionnaire de configuration logiciel comme TFS ou ClearCase.

En résumé, si vous travaillez de manière professionnelle, c'est une obligation.

Donc chercher à éviter cette fonctionnalité serait s'interdire d'utiliser tous les outils modernes de traçabilité des codes sources.

Pourquoi le processus de calcul du checksum ne fait-il pas parti intégrante du processus de génération de l'exécutable ?

[eric_marciano]

Cela n'a rien à voir avec l'IDE, qui n'est qu'un éditeur amélioré.

La différence entre les exécutables est très probablement le timestamp de génération que le linker initialise pour avoir une traçabilité correcte des éléments compilés.

Ce n'est pas parce que le code source n'a pas changé que le résultat est identique. La configuration du projet, de l'environnement de compilation sont au moins aussi important que le code source.

Normalement, si aucune modification n'est faite dans les sources et dans la configuration des projets, VS ne recompile pas l'exécutable.

Il régénère l'exécutable s'il y a des modifications ou si vous lui forcez la main.
Et à chaque régénération, le linker met un nouveau timestamp.

Cela est extrêmement pratique quand vous utilisez un serveur de symbole et un serveur de code source hébergé dans un gestionnaire de configuration logiciel comme TFS ou ClearCase.

En résumé, si vous travaillez de manière professionnelle, c'est une obligation.

Donc chercher à éviter cette fonctionnalité serait s'interdire d'utiliser tous les outils modernes de traçabilité des codes sources.

Pourquoi le processus de calcul du checksum ne fait-il pas parti intégrante du processus de génération de l'exécutable ?

Oui, en effet VS ne régénère l’exécutable que parce que je lui force la main. Et je fais cela sans rien changer ni au code, ni aux options de compilation/link. Donc la logique voudrait que l’exécutable soit le même la 2ème fois, au détail près du time stamp dont vous parlez.
Je ne dit pas que cette fonction n'est pas utile, mais dans le cas qui nous occupe, je voudrais la débrayer pour résoudre mon problème bien spécifique à ce projet seulement. Est-ce possible?
En fait, mon projet cible est une DLL qui s'auto-vérifie au moment où elle est chargée pour s'assurer que son code et ses ressources n'ont pas été modifiées. C'est une protection anti-piratage pour éviter que les hackers ne modifient le code de vérification de ma clé. Je sais que ce n'est pas infaillible, mais c'est toujours ça... DOnc s'il y a possibilité de débrayer le time stamp, ou s'il existe un autre moyen d'auto-vérifier la DLL, je suis preneur

Eric

[bacelar]

Pourquoi ne pas exclure le Timestamp de la vérification ?

[eric_marciano]

Pourquoi ne pas exclure le Timestamp de la vérification ?

Tout simplement car je ne sais pas le localiser. Je l'ai déjà fait en localisant les différences "à la main", et ça marche, mais c'est drôlement galère. A chaque recompilation, il faut relocaliser les différences pour les exclure du checksum...
C'est pour ça que je préfèrerais éviter d'avoir un timestamp.

Eric

[bacelar]

Heu, le timestamp dans mon souvenir est toujours au même offset du fichier.
http://webster.cs.ucr.edu/Page_TechDocs/pe.txt

[eric_marciano]

Merci pour le lien, voilà une info intéressante sur les PE.
D'après ce qui est écrit, je devrais effectivement réussir à localiser le timestamp automatiquement pour l'exclure du calcul de checksum, ce qui résoudrait mon problème. Mais là, il y a un autre problème: dans une toute petite application Win32 Console qui affiche juste "hello world", j'ai 4 différences dans l'executable à chaque compilation. Le timestamp en est surement une, mais il en reste 3. Elles sont toujours localisées au même endroit, mais si je change mon code, les différences se déplacent, ce qui rend à nouveau mon calcul de checksum difficile. Peut-être devrais-je utiliser la fonction CheckSumMappedFile que j'ai découverte aujourd'hui? (grâce à toi)
A suivre...

Eric

[koala01]

Salut,

De toute évidence, ton code n'est pas public et ne risque pas d'être modifié en dehors de ton équipe...

Cela implique que... tu te charge de fournir, par les moyens de ton choix, cette dll à tes clients, qui n'ont sans doute pas à la compiler

Dés lors, pourquoi vouloir que le checksum soit d'office toujours identique

Tu le calcule dés que tu as compilé ta dll, tu l'utilise avec la dll sur base de laquelle il a été généré, et basta!

Si tu recompile ta dll, tu recalcule le checksum, et tu recommence

Au pire, une erreur de checksum en local t'indiquera que tu ne l'a pas régénéré après avoir forcé la recompilation de la dll

Tu devrais pouvoir automatiser la génération du checksumm du coté des "post build events"

[eric_marciano]

En effet, mon code n’est pas publique du tout, et l’utilisation de la DLL est conditionnée par une clé. Par rapport à ça, des petits malins se sont amusés à supprimer le bout de code qui vérifiait la clé pour pouvoir le pirater à souhait. Ca peut paraitre incroyable, mais c’est vrai. C’est pour mener la vie dure à ces pirates que j’ai mis en place le checksum.

Ce que tu expliques n’est pas bête, j’y ai déjà pensé, mais le problème est que le checksum valide que je compare avec le checksum calculé (pour vérifier la non-altération de la DLL) est écrit dans le code lui-même. Autrement dit, je compile 1 fois en mettant à XXXXX le checksum valide, puis je calcule le checksum avec un utilitaire externe qui prend soin d’ignorer mon XXXXXX, puis j’écris dans mon code le checksum valide à la place de XXXXXX et je recompile. Tout marcherait bien comme tu le décris si le code valide à comparer était écrit à l’extérieur du code, dans le registry par exemple, mais pour plus de sécurité il est à l’intérieur.

Eric

[bacelar]

Franchement, ce n’est pas vraiment très malin comme attaque, c'est l'attaque base.
Et j'ai l'impression que vous ne vous mettez pas dans les bottes de l'attaquant pour évaluer la pertinence de vos contre-mesures.

Si un attaquant est capable de supprimer le code qui vérifie une clé, il est capable de supprimer le code qui vérifie un checksum.

Pour qu'il soit efficace, il faut que le checksum soit vérifier par un composant externe.

Il est bien plus compliqué pour un attaquant de saisir une cible molle que de viser un bunker. Votre routine de vérification est un bunker, il sera détruit dés le départ.

Le simple fait de ne pas faire une vérification systématique ou de différé aléatoire le moment d'une vérification sera bien plus efficace que de faire une usine à gaz qu'une simple modification d'une instruction JUMP peut court-circuiter sans aucun problème.

Pensez comme un hacker.

Votre dll est sujette aux attaques de hacker, alors faites appel à un spécialiste de la sécurisation.

[eric_marciano]

C'est pas faux... La solution que tu préconises n'est pas simple à mettre en oeuvre dans mon contexte spécifique (développement de modules additionnels pour Flight Simulator), mais je vais quand même y réfléchir. La solution que tu proposes est sans doute plus difficile à contourner tout en étant plus simple côté codage car elle m'évitera d'avoir à jongler avec les timestamps et autres pour calculer le checksum.

Merci pour ton aide

Eric

[Mat.M]

La différence entre les exécutables est très probablement le timestamp de génération que le linker initialise pour avoir une traçabilité correcte des éléments compilés.

il y a fort à parier que cela ça l'explication oui