Discussion :

[uriotcea]

bonjour,

Je fais une manip qui à priori me parait anodile, mais qui rend mon code instable. J'ai un code assez complexe en C & C++ sous windows avec du Qt4.8 compilé avec gcc4.7. Et j'ai besoin de le protéger par un checksum que j'ai bricolé comme suit.
J'ai une chaine dont le contenu en dur me permet de me repérer dans le binaire de l'exe.
Avec un code externe je calcul la somme des octects dans l'exe excluant la partie contenant ma chaine. Puis j'inscrit en dur dans l'exe cette somme dans les derniers octects de la chaine en question.
Ainsi au démarrage de mon exe je refais ce checksum que je compare aux données inscrite dans la chaine. protégeant ainsi cette exe contre toute modification visant à le modifier.
Mais voila, mon code est trés stable tant que je n'ai pas inscrit la somme dans la chaine. Aussitot que j'ai le fait, il fonctionne mais finit toujours par se cracher à des endroits différents.
Je n'arrive pas à reproduire ce comportement instable en mode débug. Il y a t-il quelquechose dans la structure d'un exe sous windows que je détruit en modifiant une chaine via un code externe?
Merci de vos lumiéres

[LittleWhite]

Bonjour,

En même temps, je trouve votre mécanisme assez dangereux.
Déjà, dans les différences :
en release (avec optimisation), l'executable ne sera pas agencé obligatoirement de la même façon qu'en debug. Du coup, votre code peut être bougé / manipulé et peut se référer à des morceaux qui n'existe pas spécialement (optimisation oblige). Du coup, je ne suis pas spécialement étonné que cela ne marche pas en release.

[uriotcea]

Merci de votre réponse mais je n'arrive pas à comprendre pas le souci, exactement.
Une fois compilé en release, je repère l'emplacement de ma chaine dans l'exe. C'est une suite de 30 caractères bien définis. Et via un code externe je modifié un de ces caractère. Je ne vois pas pourquoi cela altérerai la structure de l'exe.

Pour le mode debug, je procédais exactement de la même façon, c'est juste que dans ce cas l'exe est différent, mais le résultat semblais plus stable. Je parle au passé, parce que je viens de me rendre compte que ce n'est pas le cas non plus. Il fini aussi par planter.

[LittleWhite]

La questions que l'on peut se poser est : "Est-ce que le code est ultra propre ?" (pas de warnings, pas de fuite / lecteur de mémoire invalide et tout ce genre de trucs).
Maitenant, si Windows ou le compilateur se sert de votre chaine pour autre chose, ou s'il remarque qu'elle n'est pas utilisée, ou s'il fait lui même un check sum d'intégrité, cela peux planter.
Il faudrait être sur que des optimisations n'altèrent pas votre chaine, ni même le code qui utilise la chaîne.
De plus, il faut être sur que le '\0' à la fin de la chaîne n'est pas altéré non plus, ça serait dommage.

[uriotcea]

A priori, pas de fuite de mémoire ou d'autre probléme de ce type. J'ai validé ca sous linux avec valgrind.
Ensuite la chaine est bien utilisée et dailleurs bien lue au démarrage du code qui la trouve bien et qui trouve bien les valeurs du checksum à l'interieur qui sont correctes.
Et puisqu'en mode debug sans optimisation je rencontre aussi les instabilités, je ne pense pas que ce soit liée aux optimisations. Dailleurs cette partie du code est systématique exclue des options d'optimisation, parce que je me suis éffectivement posais comme vous la questions.

[Médinoc]

N'y a-t-il pas déjà des mécanismes de checksum et de certificats sous Windows?