md5sum

jip wrote:

bonjour,

J'ai installé la même distribution sur 2 pc différents;
quand je fais un md5sum de certains fichiers (ex: chmod)
la somme de contrôle n'est pas la même sur les 2 pc alors
que la taille est la même.

ce n'est pas normal !
sauf mise a jour sur l'un des pc, les deux sommes de controles devraient
etre identiques.

dans le systeme de paquetage rpm, par exemple, c'est ce qui permet de
verifier si les fichiers ont ete modifies par rapport a l'installation.

Sont-ils différents ('recompilés' en fonction de la machine hôte)
bien qu'ayant la même taille ?

si tu utilise des paquetages (rpm, deb) tout prets, il n'y a pas de
compilation sur la machine, contrairement a des distributions comme la
gentoo

Si c'est le cas, la méthode du contrôle d'intégrité ne peut-elle
s'appliquer qu'en comparant les sommes de contrôle dans le temps
(entre le moment de la 1ère installation et le moment présent) ?

c'est comme ca que fonctionnent les outils de controle d'integrite :
tripwire, afick, aide ...

Si on 'injecte' un fichier d'une autre installation (mais de la
même distribution sur un autre pc), que va-t-il se passer ?

meme architecture materielle, meme distribution, meme version de
distribution : ok

merci de toutes ces infos;

(...)
meme architecture materielle, meme distribution, meme version de
distribution : ok

Un des pc est un 'ancêtre': Pentium 300 et l'autre un Pentium 2,4 Ghz.
"L'architecture matérielle" est-elle la même ? Ou explique-t-elle ces
différences ?

Mes comparaisons par calcul md5 se font sur plus de 100 fichiers 'sensibles'
(ps, su, ...); pratiquement tous donnent des md5 différents mais ont des
tailles identiques d'une machine à l'autre !

(j'ai installé et lancé rkhunter sur les pc, il ne détecte rien d'anormal)



merci,
jip

jip wrote:

merci de toutes ces infos;

Un des pc est un 'ancêtre': Pentium 300 et l'autre un Pentium 2,4 Ghz.
"L'architecture matérielle" est-elle la même ? Ou explique-t-elle ces
différences ?

ca n'explique rien a mon avis

Mes comparaisons par calcul md5 se font sur plus de 100 fichiers 'sensibles'
(ps, su, ...); pratiquement tous donnent des md5 différents mais ont des
tailles identiques d'une machine à l'autre !

tu peux preciser ta distribution de linux (et ta version) ?

(j'ai installé et lancé rkhunter sur les pc, il ne détecte rien d'anormal)

bon, c'est deja ca, quoique pour etre sur, il faudrait le lancer depuis
un os externe .

ce qui me fait penser a un essai possible : si tu as sous la main les cd
d'installation ou une distribution sur cd (knoppix, gnoppix,
mandrakemove ...), ce serait interessant de comparer les checksum vus
depuis l'os du cd

tu peux preciser ta distribution de linux (et ta version) ?
Aurox 10.1

(j'ai installé et lancé rkhunter sur les pc, il ne détecte rien
d'anormal)

bon, c'est deja ca, quoique pour etre sur, il faudrait le lancer depuis
un os externe .

ce qui me fait penser a un essai possible : si tu as sous la main les cd
d'installation ou une distribution sur cd (knoppix, gnoppix,
mandrakemove ...), ce serait interessant de comparer les checksum vus
depuis l'os du cd
je n'ai pas les 2 pc sous la main (2 lieux différents) mais j'ai copié

quelques fichiers sur disquette pour pouvoir les comparer...
la commande /usr/bin/cmp sur chaque paire de fichier m'indique un octet
différent (un seul !) donc sans incidence sur la taille mais bien sûr
qui fait varier md5sum.

ce qui m'étonne c'est justement que les fichiers aient la bonne taille...
et je ne vois pas ce qu'un octet peut présenter comme 'risque' (si une
'saleté' s'était infiltrée, les fichiers devraient avoir des écarts de
taille important);
encore plus étonnant: que des fichiers 'à risque' soient modifiés, je le
comprendrais (ps, chmod, su...), mais que des fichiers comme 'date', 'echo',
'cat'(...) le soient eux aussi et d'un octet seulement... je m'y perds !

Peut-on extraire des fichiers d'un cd d'install "à l'unité":
je m'explique: est-il possible de 'restaurer' par exemple le fichier 'date'
à partir des cd d'install sans justement tout réinstaller pour faire
justement des contrôles d'intégrité ?

encore merci,
bonne soirée,
jip

jip wrote in message <421a2344$0$1244$8fcfb975@news.wanadoo.fr>:

je n'ai pas les 2 pc sous la main (2 lieux différents) mais j'ai copié
quelques fichiers sur disquette pour pouvoir les comparer...
la commande /usr/bin/cmp sur chaque paire de fichier m'indique un octet
différent (un seul !) donc sans incidence sur la taille mais bien sûr
qui fait varier md5sum.

C'est assez typique d'un problème de mémoire/bus qui a corrompu l'image du
fichier avant qu'elle se retrouve écrite sur disque. -> memtest86 sur les
deux PC.

je n'ai pas les 2 pc sous la main (2 lieux différents) mais j'ai copié
quelques fichiers sur disquette pour pouvoir les comparer...
la commande /usr/bin/cmp sur chaque paire de fichier m'indique un octet
différent (un seul !) donc sans incidence sur la taille mais bien sûr
qui fait varier md5sum.

C'est assez typique d'un problème de mémoire/bus qui a corrompu l'image du
fichier avant qu'elle se retrouve écrite sur disque. -> memtest86 sur les
deux PC.

Piste à suivre.... mais malgré ces changements d'octet, les pc fonctionnent
normalement ! Comment cette anomalie ne provoquerait pas de plantage ?

On Tue, 22 Feb 2005 08:34:48 +0100, jip wrote:

je n'ai pas les 2 pc sous la main (2 lieux différents) mais j'ai copié
quelques fichiers sur disquette pour pouvoir les comparer...
la commande /usr/bin/cmp sur chaque paire de fichier m'indique un octet
différent (un seul !) donc sans incidence sur la taille mais bien sûr
qui fait varier md5sum.

Comment lances-tu cmp ? Par défaut, celui-ci n'affiche que la première
différence. Il faut utiliser 'cmp -b <x> <y>'.

C'est assez typique d'un problème de mémoire/bus qui a corrompu l'image du
fichier avant qu'elle se retrouve écrite sur disque. -> memtest86 sur les
deux PC.

Piste à suivre.... mais malgré ces changements d'octet, les pc fonctionnent
normalement ! Comment cette anomalie ne provoquerait pas de plantage ?

Dans ce cas, je dirais que tes fichiers sont corrects, mais que c'est
md5sum qui a des problèmes dus à des corruptions de RAM...
As-tu des résultats reproductibles ?
Si tu fais en boucle des md5sum sur un gros fichier (genre /lib/libc.so),
as tu toujours le même résultat sur les 2 PC ?
Le problème peut venir de la disquette ou d'un des 2 lecteurs de
disquettes...
As-tu essayé de faire les md5sum des fichiers sur disquette sur les 2 PC
pour vérifier (ou non) cette hypothèse ?

Et, pour info, un PC qui a de la RAM défaillante peut très bien
fonctionner pendant des mois en corrompant des données de temps en temps,
sans qu'on s'en aperçoive: des crashes de temps en temps, genre un soft
qui plante par semaine, ça incite à penser que le soft en question est
buggé, pas que la RAM délire.
J'avais un PC comme celà au boulot, qui crashait environ 1 fois tous les
2 ou 3 mois et me vérolait un fichier tous les mois, à peu près...
Pourtant le résultat de memtest86 était catastrophique !
Comme quoi, les erreurs de RAM peuvent avoir des effets sournois et rester
invisibles pendant longtemps.

bonjour,

Dans ce cas, je dirais que tes fichiers sont corrects, mais que c'est
md5sum qui a des problèmes dus à des corruptions de RAM...

As-tu des résultats reproductibles ?
oui

As-tu essayé de faire les md5sum des fichiers sur disquette sur les 2 PC
pour vérifier (ou non) cette hypothèse ?
oui: toujours les mêmes anomalies

j'ai 'ramené' quelques fichiers du p300 sur disquette chez moi:
les md5sum sont les mêmes qu'ils soient obtenus sur le p300 (lui-même) ou
sur le p2,4 sur ces fichiers et bien sûr différents de ceux des fichiers
'réels' du p2,4 (alors que c'est bien sûr la même distribution installée sur
ces 2 pc il y a une quinzaine de jours)

Comment lances-tu cmp ? Par défaut, celui-ci n'affiche que la première
différence. Il faut utiliser 'cmp -b <x> <y>'.

oups: je faisais cmp <x> <y>

mais même en refaisant comme ci-dessous où <nom> et <nom2> sont les
variantes des mêmes fichiers en provenance des 2 machines), on obtient:

ici avec un même md5sum pour 'su':
[monpc@linux temp]$ cmp -b su su2
(rien en retour: c'est très normal !)

mais:

[monpc@linux temp]$ cmp -b cat cat2
cat cat2 diffèrent: octet 1449, ligne 2 est 231 M-^Y 11 ^I

[monpc@linux temp]$ cmp -b date date2
date date2 diffèrent: octet 2061, ligne 2 est 327 × 30 ^X

[monpc@linux temp]$ cmp -b echo echo2
echo echo2 diffèrent: octet 1409, ligne 2 est 231 M-^Y 11 ^I

[monpc@linux temp]$ cmp -b hostname hostname2
hostname hostname2 diffèrent: octet 1049, ligne 2 est 231 M-^Y 11 ^I


bizarre cet octet 1049 qui revient plusieurs fois ?!


merci de vous intéresser à mon problème.

jip

On Tue, 22 Feb 2005 12:26:28 +0100, jip wrote:

bonjour,

Dans ce cas, je dirais que tes fichiers sont corrects, mais que c'est
md5sum qui a des problèmes dus à des corruptions de RAM...

As-tu des résultats reproductibles ?
oui

As-tu essayé de faire les md5sum des fichiers sur disquette sur les 2 PC
pour vérifier (ou non) cette hypothèse ?
oui: toujours les mêmes anomalies

j'ai 'ramené' quelques fichiers du p300 sur disquette chez moi:
les md5sum sont les mêmes qu'ils soient obtenus sur le p300 (lui-même) ou
sur le p2,4 sur ces fichiers et bien sûr différents de ceux des fichiers
'réels' du p2,4 (alors que c'est bien sûr la même distribution installée sur
ces 2 pc il y a une quinzaine de jours)

Ce ne sont pas des fichiers copiés de l'un à l'autre ?
Dans ce cas, c'est peut-être normal: il se peut que la distribution
installe des fichiers différents, en fonction du CPU de la machine cible.
Mais, dans ce cas, il me semble extrèmement douteux qu'il n'y ait qu'un
seul octet qui diffère.
Pour le savoir, demande des infos sur les fichiers en question.
readelf est fait pour celà:
readelf -h <le_fichier>
ou
readelf -h -V <le_fichier>
voire
readelf -a <le_fichier>

En comparant les deux, tu sauras si c'est la même version de l'executable
ou pas. Si ce sont les mêmes versions, regarde ou se trouve l'offset en
question:
readelf -h -l -S <le_fichier>
Si tu ne sais pas interpréter ce dernier résultat, poste le, je te
dirais ce que j'en pense.

Ce ne sont pas des fichiers copiés de l'un à l'autre ?
non

Dans ce cas, c'est peut-être normal: il se peut que la distribution
installe des fichiers différents, en fonction du CPU de la machine cible.
je l'ai envisagé (voir mon premier message)

Mais, dans ce cas, il me semble extrèmement douteux qu'il n'y ait qu'un
seul octet qui diffère.
Pour le savoir, demande des infos sur les fichiers en question.
readelf est fait pour celà:
readelf -h <le_fichier>
ou
readelf -h -V <le_fichier>
voire
readelf -a <le_fichier>

En comparant les deux, tu sauras si c'est la même version de l'executable
ou pas. Si ce sont les mêmes versions, regarde ou se trouve l'offset en
question:
readelf -h -l -S <le_fichier>
Si tu ne sais pas interpréter ce dernier résultat, poste le, je te
dirais ce que j'en pense.

En suivant tes conseils, détail de mes manips sur le fichier 'cat' par
exemple (cat est la version d'un des pc et cat2 est la version de l'autre
pc):

[monpc@linux temp]$ md5sum cat
40071f72e53cb7d4d9dd7d9aa6f2f481 cat
[monpc@linux temp]$ md5sum cat2
037fe0456db43cf2b129f6c91704dc9f cat2

il y a donc bien 2 valeurs différentes calculées avec le même pc
(les calculs donnent toujours les mêmes résultats; ce qui semble exclure
un problème dans 'md5sum')

[monpc@linux temp]$ readelf -h -V cat > hVcat.txt
[monpc@linux temp]$ readelf -h -V cat2 > hVcat2.txt
[monpc@linux temp]$ kompare hVcat.txt hVcat2.txt
me dit: les fichiers sont identiques

[monpc@linux temp]$ readelf -h -l -S cat > hls_cat.txt
[monpc@linux temp]$ readelf -h -l -S cat2 > hls_cat2.txt
[monpc@linux temp]$ kompare hls_cat.txt hls_cat2.txt
me dit: les fichiers sont identiques

[monpc@linux temp]$ readelf -a cat > a_cat.txt
[monpc@linux temp]$ readelf -a cat2 > a_cat2.txt
[monpc@linux temp]$ kompare a_cat.txt a_cat2.txt
et là, kompare trouve des différences:


I) Fichier a_cat.txt (résultat de la commande: readelf -a cat > a_cat.txt)
(j'ai éliminé les lignes identiques)

Ligne 107 à 124 (différences dans les lignes 109 à 124):
=======================================================
Section de relocalisation « .gnu.conflict » à l'adresse de décalage 0x5cc
contient 16 entrées:
Décalage Info Type Val.-sym Noms-symb + Addenda
006fce4c 00000001 R_386_32 fffffff0
006fce50 00000001 R_386_32 00000001
006fce94 00000001 R_386_32 fffffff4
006fced8 00000001 R_386_32 ffffffec
006fcf24 00000001 R_386_32 ffffffdc
006fcf38 00000001 R_386_32 ffffffe0
006fcf60 00000001 R_386_32 fffffff8
006fcf68 00000001 R_386_32 ffffffe4
006fcf84 00000001 R_386_32 ffffffd8
006fcfa4 00000001 R_386_32 ffffffe8
006fcfb8 00000001 R_386_32 0804afa4
005e2fec 00000007 R_386_JUMP_SLOT 006463b0
005e2ff0 00000007 R_386_JUMP_SLOT 00646010
005e2ff4 00000007 R_386_JUMP_SLOT 006466a0
005e2ff8 00000007 R_386_JUMP_SLOT 00646190
005e2ffc 00000007 R_386_JUMP_SLOT 006486b0


Lignes 264 et 265 (fin du fichier):
==================================
Liste de libraire de la section « .gnu.liblist » contenant 2 entrées:
Library Time Stamp Checksum Version Flags
0: libc.so.6 2005-02-08T03:06:01 0xdfe70ff0 0 0
1: /lib/ld-linux.so.2 2005-02-08T03:06:01 0x46832140 0 0

=============================================================================== ===============================================================================
II) Fichier a_cat2.txt (résultat de la commande: readelf -a cat2 >
a_cat2.txt)

Ligne 107 à 124 (différences dans les lignes 109 à 124):
=======================================================
Section de relocalisation « .gnu.conflict » à l'adresse de décalage 0x5cc
contient 16 entrées:
Décalage Info Type Val.-sym Noms-symb + Addenda
0078ae4c 00000001 R_386_32 fffffff0
0078ae50 00000001 R_386_32 00000001
0078ae94 00000001 R_386_32 fffffff4
0078aed8 00000001 R_386_32 ffffffec
0078af24 00000001 R_386_32 ffffffdc
0078af38 00000001 R_386_32 ffffffe0
0078af60 00000001 R_386_32 fffffff8
0078af68 00000001 R_386_32 ffffffe4
0078af84 00000001 R_386_32 ffffffd8
0078afa4 00000001 R_386_32 ffffffe8
0078afb8 00000001 R_386_32 0804afa4
00670fec 00000007 R_386_JUMP_SLOT 006d43b0
00670ff0 00000007 R_386_JUMP_SLOT 006d4010
00670ff4 00000007 R_386_JUMP_SLOT 006d46a0
00670ff8 00000007 R_386_JUMP_SLOT 006d4190
00670ffc 00000007 R_386_JUMP_SLOT 006d66b0


Lignes 264 et 265 (fin du fichier):
==================================
Liste de libraire de la section « .gnu.liblist » contenant 2 entrées:
Library Time Stamp Checksum Version Flags
0: libc.so.6 2005-02-06T15:43:05 0x78f0327e 0 0
1: /lib/ld-linux.so.2 2005-02-06T15:43:05 0x80c9b51b 0 0

===============================================================================
Je suis perdu et dépassé. Mais j'apprends plein de trucs !

merci du temps passé,
jip