[C, C++] Verifier l'integrité d'un TXT grace à une valeur dans la base de registre

Version imprimable

Voir 40 message(s) de cette discussion en une page

06/04/2007, 09h36
Xav987

[C, C++] Verifier l'integrité d'un TXT grace à une valeur dans la base de registre

Bonjour.

J'ai besoin de securiser, dans le cadre d'un projet, des fichiers texte.
C'est fichier ne doivent etre modifiés QUE par le programme.

Pour eviter que quelqu'un bidouille le fichier avec un editeur, je vais le coder (ce sera facile, puisque que le but est de rendre le contenue illisible si on l'ouvre avec un editeur, et non de le rendre indecryptable par un pro de la crypto, un simple XOR, par exemple, suffira donc).

Mais je voudrais aussi que le programme puisse verifier que le fichier n'a pas été modifier (par exemple que quelqu'un ne l'a pas ouvert dans un editeur, et à tout effacé).

Pour ça j'ai pensé à faire une espece d'operation mathematique sur le contenue du fichier (un peu comme un CRC, par exemple), et à en copier le resultat dans la base de registre.

Ainsi, si on edit manuelment le fichier, le "CRC" ne correspond plus, et le programme sait qu'il à été modifié.

Le probleme c'est que je ne sait pas du tout comment mettre ça en place, je n'y connait rien en crypto...

Alors si quelqu'un peu m'aiguiler, me mettre sur la voie, ou si quelqu'un connaitrait une sorte de tuto... bah Merci :D
06/04/2007, 10h23
josse95

Bonjour,

des exemples:

http://en.wikipedia.org/wiki/Fletcher%27s_checksum

http://en.wikipedia.org/wiki/Adler-32

tu peux trouver d'autres types de checksum sur wikipedia.
06/04/2007, 10h30
lun4t1k

Sinon, si tu ne veux pas une méthode de cryptage High tech, stocke la date du création du fichier dans le registre, et si la date du fichier a été modifiée, c'est que le fichier a été modifié!

:oops:
06/04/2007, 10h40
Gruik

En general le checksum est stoqué directement dans le fichier (dans un eventuel en tete), pas à l'exterieur du fichier

Un moyen plus simple serait aussi de zipper avec mot de passe
06/04/2007, 10h41
Xav987

+ Résolu !
Avec les liens externe en bas des pages Wiki j'ai reussit à trouver pleinde truc qui devraient pouvoir faire mon bonheur.

Je posterai le code que j'utilise, une fois que ça marchera. Peut etre que sa servira à d'autres...

Surtout que je cherchait un truc de quelque ligne, vraiment simple, car c'est vraiment pas un point important du projet...
06/04/2007, 11h27
souviron34
sans aller jusqu'à un checksum, tu as plus simple et standard en C, si ce qui t'intéresse est de savoir si ça a été modifié.

Avec la fonction stat :
Code:

1 2 3 4 5 6 7 #include <sys/stat.h> struct stat sbuf; stat("x",&sbuf);
struct stat :

Citation:

Data type Component name Meaning

mode_t st_mode
File mode, i.e. access rights and file type
ino_t st_ino
Inode number
dev_t st_dev
ID of device containing a directory entry for this file
dev_t st_rdev
ID of device This entry is defined only for char special or block special files
nlink_t st_nlink
Number of links
uid_t st_uid
User ID of the file's owner
gid_t st_gid
Group ID of the file's group
off_t st_size
File size in bytes
time_t st_atime
Time of last access
time_t st_mtime
Time of last data modification
time_t st_ctime
Time of last file status change
long st_blksize
Preferred I/O block size
long st_blocks
Number of 512 byte blocks allocated
06/04/2007, 11h32
josse95

stat ne te permet pas de savoir si ton fichier a réellement été modifié.
Il te permet de savoir si ton fichier a été réécrit.

Le checksum permet de savoir, avec une plus ou moins forte probabilité selon l'algorythme, si le fichier a été modifié.
06/04/2007, 11h43
souviron34

OK, mais le PO avait dit :

Citation:

Envoyé par Xav987

Mais je voudrais aussi que le programme puisse verifier que le fichier n'a pas été modifier (par exemple que quelqu'un ne l'a pas ouvert dans un editeur, et à tout effacé).

...

Ainsi, si on edit manuelment le fichier, le "CRC" ne correspond plus, et le programme sait qu'il à été modifié.

....

Et déjà avec stat tu as la date de modif et la taille.
06/04/2007, 13h25
Emmanuel Delahaye

Citation:

Envoyé par souviron34

sans aller jusqu'à un checksum, tu as plus simple et standard en C,

Pas à ma connaissance.

Citation:

si ce qui t'intéresse est de savoir si ça a été modifié.

Avec la fonction stat :

N'est pas standard C. POSIX.1, oui, mais pas C.
06/04/2007, 13h27
Emmanuel Delahaye

Citation:

Envoyé par josse95

Le checksum permet de savoir, avec une plus ou moins forte probabilité selon l'algorythme, si le fichier a été modifié.

Un checksum, non. Trop faible. Un CRC-16, par exemple, oui (ou MD5...).
06/04/2007, 13h56
souviron34

Citation:

Envoyé par Emmanuel Delahaye

Pas à ma connaissance.

N'est pas standard C. POSIX.1, oui, mais pas C.

Ah bon ? OK je savais pas... merci :mrgreen:

Mais là encore (la pratique...) ça a toujours marché pour moi sur Solaris, HPUX, Irix, et Linux... 8O
06/04/2007, 13h59
josse95

Emmanuel, relis bien mon message:

Citation:

avec une plus ou moins forte probabilité

Je n'ai pas dit que la conservation du checksum garantit qu'un fichier n'a pas été modifié. J'ai parlé de probabilité de détection de modification.
06/04/2007, 14h53
Emmanuel Delahaye

Citation:

Envoyé par josse95

Emmanuel, relis bien mon message:

Je n'ai pas dit que la conservation du checksum garantit qu'un fichier n'a pas été modifié. J'ai parlé de probabilité de détection de modification.

Et j'ai bien précisé qu'avec un checksum, la détection était faible...
06/04/2007, 14h55
Emmanuel Delahaye

Citation:

Envoyé par souviron34

Ah bon ? OK je savais pas... merci :mrgreen:

Mais là encore (la pratique...) ça a toujours marché pour moi sur Solaris, HPUX, Irix, et Linux... 8O

Ben oui, mais ça n'empêche pas de vérifier la rubrique 'portabilité' (ou conformité) du man...

http://man.developpez.com/man2/stat.2.php

Citation:

CONFORMITÉ
Les appels stat et fstat sont conformes aux versions SVr4, POSIX, X/OPEN, BSD 4.3. L'appel lstat est conforme aux versions BSD 4.3 et SVr4. SVr4 mentionne des conditions d'erreurs supplémentaires pour fstat EINTR, ENOLINK, et EOVERFLOW. Pour stat et lstat SVr4 indique les conditions supplémentaires EACCES, EINTR, EMULTIHOP, ENOLINK, et EOVERLOW. L'utilisation des champs st_blocks et st_blksize risque d'être moins portable. Ils ont été introduit dans BSD, et ne sont pas mentionnée dans POSIX. Leur interprétation change suivant les systèmes, voire sur un même système s'il y a des montages NFS.
Posix ne décrit pas les bits S_IFMT, S_IFSOCK, S_IFLNK, S_IFREG, S_IFBLK, S_IFDIR, S_IFCHR, S_IFIFO, S_ISVTX, mais réclame d'utiliser les macros S_ISDIR(), etc. Les macros S_ISLKNK et S_ISSOCK ne se trouvent pas dans POSI.1-1996 mais seront présentes dans le prochain standard POSIX. La première vient de SVID 4v2, la seconde de SUSv2.
Unix V7 (et les systèmes suivants) propose S_IREAD, S_IWRITE, S_IEXEC, là où POSIX préfère leurs synonymes S_IRUSR, S_IWUSR, S_IXUSR.
06/04/2007, 15h09
souviron34

OK Emmanuel, mais donc si j'en crois ce lien, utiliser stat pour déterminer uniquement taille et date du dernier accès ou de la dernière modif est portable.....

Voir aussi "Single Unix specification" http://www.opengroup.org/onlinepubs/...sysstat.h.html

Citation:

The following are declared as functions and may also be defined as macros. Function prototypes must be provided for use with an ISO C compiler.

et

http://sourceware.org/ml/glibc-cvs/2.../msg00100.html
06/04/2007, 15h37
Emmanuel Delahaye

Citation:

Envoyé par souviron34

OK Emmanuel, mais donc si j'en crois ce lien, utiliser stat pour déterminer uniquement taille et date du dernier accès ou de la dernière modif est portable.....

C'est portable sur les plateformes conformes à POSIX.1, oui. Win32 n'est pas réputé pour son haut degré de compatibilité avec POSIX.1. MinGW comble quelques lacunes, mais pas tout...
06/04/2007, 15h46
Jean-Marc.Bourguet

Citation:

Envoyé par souviron34

OK Emmanuel, mais donc si j'en crois ce lien, utiliser stat pour déterminer uniquement taille et date du dernier accès ou de la dernière modif est portable...

La portabilite est une notion relative. Si tu te limites a Posix, Emmanuel vise generalement beaucoup plus large et toute implementation conforme de C. Entre les deux, on peut aussi vouloir utiliser Windows sans une couche comme Cygwin, Uwin ou Interix. Personellement, quand je me sens vicieux je sors une implementation de C pour PDP-10 qui a l'art de mettre a mal pas mal d'hypotheses.
06/04/2007, 15h58
souviron34

OK on apprends tous les jours...

Citation:

Envoyé par Jean-Marc.Bourguet

Personellement, quand je me sens vicieux je sors une implementation de C pour PDP-10 qui a l'art de mettre a mal pas mal d'hypotheses.

:mrgreen: ;)

Je n'ai plus accès depuis bien longtemps à ça.. J'avais un vieux PDP 11/73 (64K mémoire 64k data), mais à l'époque pour moi c'était Fortran et assembleur....
06/04/2007, 15h59
Emmanuel Delahaye

Citation:

Envoyé par Jean-Marc.Bourguet

Personellement, quand je me sens vicieux je sors une implementation de C pour PDP-10 qui a l'art de mettre a mal pas mal d'hypotheses.

Oui, ou un bon vieux BC++ 3.1 (16-bit mode réel modèle large) avec lequel j'écrivais du code portable pour machines 68k et PowerPC (32-bit, 'à l'envers') ...
06/04/2007, 16h04
josse95

Pourquoi cette obsession de la portabilité ?

La portabilité peut faire partie du cahier des charges d'un logiciel. Mais elle n'est pas une nécessité en soit.

Voir 40 message(s) de cette discussion en une page