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

**Xav987** · 06/04/2007, 09h36

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

**josse95** · 06/04/2007, 10h23

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.

**lun4t1k** · 06/04/2007, 10h30

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é!

**Gruik** · 06/04/2007, 10h40

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

**Xav987** · 06/04/2007, 10h41

+ 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...

**souviron34** · 06/04/2007, 11h27

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

struct stat :

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

**josse95** · 06/04/2007, 11h32

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é.

**souviron34** · 06/04/2007, 11h43

OK, mais le PO avait dit :

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.

**Emmanuel Delahaye** · 06/04/2007, 13h25

Envoyé par souviron34

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

Pas à ma connaissance.

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.

**Emmanuel Delahaye** · 06/04/2007, 13h27

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...).

**souviron34** · 06/04/2007, 13h56

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

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

**josse95** · 06/04/2007, 13h59

Emmanuel, relis bien mon message:

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.

**Emmanuel Delahaye** · 06/04/2007, 14h53

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...

**Emmanuel Delahaye** · 06/04/2007, 14h55

Envoyé par souviron34

Ah bon ? OK je savais pas... merci

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

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

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.

**souviron34** · 06/04/2007, 15h09

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

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

**Emmanuel Delahaye** · 06/04/2007, 15h37

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...

**Jean-Marc.Bourguet** · 06/04/2007, 15h46

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.

**souviron34** · 06/04/2007, 15h58

OK on apprends tous les jours...

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.

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....

**Emmanuel Delahaye** · 06/04/2007, 15h59

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') ...

**josse95** · 06/04/2007, 16h04

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.

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

C

Discussions similaires

Partager

Partager