Code identique, exe diff�rent

**eric_marciano** · 17/10/2011, 14h52

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** · 17/10/2011, 15h02

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** · 17/10/2011, 15h09

Envoy� par 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.

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** · 17/10/2011, 18h20

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** · 17/10/2011, 20h30

Envoy� par 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 ?

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** · 18/10/2011, 12h13

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

**eric_marciano** · 18/10/2011, 13h31

Envoy� par bacelar

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** · 20/10/2011, 13h51

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** · 20/10/2011, 21h11

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** · 21/10/2011, 09h07

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** · 21/10/2011, 11h31

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** · 21/10/2011, 12h30

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** · 21/10/2011, 14h39

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** · 14/11/2011, 14h57

Envoy� par bacelar

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

Code identique, exe diff�rent

Visual C++

Discussions similaires

Partager

Partager