Discussion :

[RBN1994]

Bonjour a tous,

je suis entrain de realiser un petit projet sur C qui consiste a lire une video YUV , de faire une copie de cette derniere et d'ajouter un bruit gaussien a la version copié, cest a dire la video original ne doit pas etre modifier et le resultat de la modification doit etre visible sur la deuxieme video.
pour l'addition du bruit gaussien je dois utiliser la methode Polar (Polar Method)
https://en.wikipedia.org/wiki/Marsaglia_polar_method
maintenemant je vais vous montrer mon travail et dites moi ce que vous pensez.
le code bien evidement nest pas fonctionnel, j'ai bien pu lire le premier fichier (video) et de faire une copie sans modifier le contenu et je n'arrive pas d'implimenter la function Polar sur la version copié, donc si vous avez une idée a ce sujet, n'hesitez pas a me repondre.
(PS: desoler pour le français cassé, je suis un etudiant étranger en Allemagne)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
 
void polar(double *x1, double *x2) //methode polar
{
   double u, v, q, p;
 
   do {
      u = 2.0 * ((float) rand()/RAND_MAX) - 1;
      v = 2.0 * ((float) rand()/RAND_MAX) - 1;
      q  = u * u + v * v;
   } while (q >= 1.0 || q == 0.0);
 
   p = sqrt(-2 * log(q) / q);
   *x1 = u * p;
   *x2 = v * p;
}
int main(void) {
    FILE *fp1, *fp2;
   double a1,a2;
	fp1= fopen("FOOTBALL_352x288_30_orig_01.yuv","rb");
	 if (fp1 == NULL)
  	{
    exit(1);
  	}
	fp2= fopen("FOOTBALL_352x288_30_copy_02.yuv","wb");
    if (fp2 == NULL)
  	{
    exit(1);
  	}
 
 
int buffer;
while(!feof(fp1))
 
	{
		 fread((void *)&buffer, sizeof(buffer),1,fp1);
		polar(&a1,&a2);
 
 
		fwrite((void *)&a1,sizeof(buffer),1,fp2);
	}
 
    fclose(fp1);
    fclose(fp2);
 
	return 0;
}

[dalfab]

Bonjour,

Ligne 32 : on ne doit utiliser feof() que pour connaître une cause d'erreur pas pour savoir si la fin de fichier est atteinte. pour cela il faut commencer essayer de lire, et c'est le résultat de fread() qui dira si la fin a été atteinte ou pas. A vérifier : Le fichier résultat a exactement la même taille que le fichier initial.
Ligne 35 : tu lis dans un fichier une donnée entière de la taille d'un int. La taille d'un int ça ne veut rien dire en C (ça dépend), il faut lire des données dont la taille correspond au données dans le fichier. Pour cela il faut bien se renseigner sur le format. Par exemple si la taille est 1 octet, le type à utiliser est uint8_t.
Ligne 36 : tu supposes que par magie l'entier précédemment lu dans buffer a été transféré et converti dans a1. Il manque du code. D'autant que buffer est peut-être un nombre de 0 à 255, et a1 serait un double de 0.0 à 1.0.
Ligne 37 : Ici aussi magie de a2 vers rien. Et c'est a1 (donc un double) au lieu d'un a2 converti qui est écrit, et ce en utilisant la taille d'un int!

[sambia39]

Bonjour,
Contrairement à ce qui a été dit feof permet de détecter la fin de fichier elle renvoie 0 lorsque la fin de fichier n'est pas atteinte ou autres valeurs non-nulles dans le cas contraire ; de plus, l'emploi de feof sur le format YUV est justifié, car il est utilisable sur des fichiers aussi bien en mode binaire/mode texte. Ceci dit si vous souhaitez détecter des éventuelles erreurs lors du traitement du fichier, il faut utiliser ferror..

Effectivement, il faut se renseigner sur le format du fichier au préalable (Connaître les spécifications ; donc, structure du fichier) pour pouvoir manipuler les données souhaitées et ainsi évité de modifier à l'aveugle le fichier (écraser ou alterner de manière significative le fichier) et le rendre illisible.

à bientôt

[dalfab]

documentation de la fonction feof()
Dans le code précédent, un int de trop est lu.

[sambia39]

documentation de la fonction feof()
Dans le code précédent, un int de trop est lu.

Dans la documentation de feof que vous proposez, il est écrit que feof vérifie si la fin du flux de fichiers a été atteinte et dans ce cas renvoie une valeur non-nulle. Et quand bien même s'il y a lecture de trop ou erreur, le seul moyen de déterminer une erreur ou que l'on a atteint la fin du fichier est l'emploi de ferror et feof, sachant que fread ne fait aucune distinction entre la fin du fichier et une erreur donc même avec l'emploi de fread, il faut distinguer la fin du fichier et une erreur.

À bientôt;

[Médinoc]

Ce que dalfab cherchait à dire, ce n'est pas la pertinence de feof() contre ferror(), c'est que ces deux fonctions ne doivent être appelées qu'après un échec d'une fonction de lecture (ici, fread()).
En termes simples, toute boucle while(!feof(file)) est fausse.

La bonne façon, c'est un truc de ce style:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
while((nbLus=fread(file, ...)>=0)
{
	//Traitement
}
if(feof(file))
{
	//Succès! Le fichier a été lu jusqu'à la fin
}
else
{
	//Erreur! fread() a échoué pour une autre raison que "fin de fichier"
}

[sambia39]

Ce que dalfab cherchait à dire, ce n'est pas la pertinence de feof() contre ferror(), c'est que ces deux fonctions ne doivent être appelées qu'après un échec d'une fonction de lecture (ici, fread()).

La valeur que retourne fread correspond au nombre d'éléments correctement lus / un nombre inférieure à ce qui est attendu peut être renvoyer sans qu'aucune erreur ne soit détectée, c'est le cas par exemple lorsque l'on a atteint la fin du fichier (sans oublier qu'il peut tout aussi bien retourner zéro). La phrase "on ne doit utiliser feof() que pour connaître une cause d'erreurs pas pour savoir si la fin de fichier est atteinte. Pour cela, il faut commencer à essayer de lire, et c'est le résultat de fread() qui dira si la fin a été atteinte ou pas..." n'est pas correcte et n'est pas évidente à comprendre pour un débutant sachant que le seul moyen de savoir s'il y a eu erreur lors du traitement est de faire appel à ferror qui va tester l'indicateur d'erreur sur le flux en question, et pour savoir si on atteint la fin du fichier, c'est feof. Ce n'est pas le retour de fread qui nous dira s'il y a une erreur ou fin de fichier atteint, car celui-ci ne fait aucune distinction entre une erreur et une fin de fichier. Il m'a paru donc pertinent de le souligner que l'emploi de ferrordétecte l'erreur et feof fin de fichier.


Ceci dit, même-ci l'on écrit while(!feof(fp1))comme condition de boucle, ce n'est pas forcément faux en soi. Cela relève plus d'une erreur d'implementation / construction algorithmique. feof peut donc, tout aussi bien être utilisé comme condition pour lire des données tant que l'on n'a pas atteint la fin du fichier (et donc seule une lecture de trop lève le flag "fin du fichier" pas avant) + ferror bien placé (dans la boucle) détectera les erreurs sur le flux du fichier et ce le plus tôt possible comme l'exemple ci-dessous. (Attention, l'exemple ci-dessous illustre juste que l'on peut avoir une implémentation possible comme ci-dessous). Quant à un emploi de feof sans ferror et comme condition de boucle, je suis d'accord avec vous que ce n'est pas conseillé.

Code C :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
    --- snip ---
    while( !feof(p) ){
 
        (void)memset(buffer, 0, sizeof(buffer)); 
        fscanf(pf, "%s", buffer);
 
        if( ferror(p) ){
            perror("Erreur traitement sur le fichier");
            abort();
        }else
            (void)puts(buffer);
 
 
        /* Géneration d'error */
        /* (void)fputc(666, p); */
    }
    --- snip ---

à bientôt.

[Médinoc]

Ce code affichera une ligne en trop, toute vide soit-elle.
(En plus d'être un trou de Sécurité gros comme gets())

[sambia39]

Ce code affichera une ligne en trop, toute vide soit-elle.
(En plus d'être un trou de Sécurité gros comme gets())

Gros "comme gets", absolument pas, sachant tout de même qu'il y a une différence. Ce n'est pas parce que l'exploitation d'une vulnérabilité est basée sur un principe que cela est tout comme gets. Prenant par exemple la famille des overflow. On qualifie, à tord les vulnérabilités "format string" comme étant ou désignées comme des "Buffer Overflow" qui dans les faits ne sont techniquement pas des débordements de tampons. Autre exemple, les vulnérabilités de type "bugs off by one" qui occasionnent un overflow sur quelques bytes voire un seul byte et dont exploitation n'est pas à l'identique ou pas comme gets. Voir les erreurs dites "bugs format" (liées à toute la famille scanf dont fscanf.) ne sont pas comme gets même-ci, ils permettent un overflow, il faudrait voir dans quel contexte les exploiter pour être "tout comme gets".
Ceci dit, c'est tout de même une bonne chose de l'évoquer, car tout le monde est concerné, les débutants comme experts avertis /confirmés, dommage que ce ne soit pas le bon endroit du forum pour en discuter de manière approfondie avec des exemples.


À bientôt.

[Médinoc]

Note: La partie "off-by-one" et la partie "faille de sécurité" étaient indépendantes dans ma précédente remarque.

xxxscanf("%s") sans aucun autre spécificateur de format est une vulnérabilité grosse comme gets() (indépendamment de la boucle autour). Exactement de la même taille en fait, ou pour être précis exactement du même manque de taille.

Ce n'est même pas ce que j'appellerais une vulnérabilité "de chaîne de format", vu que ces vulnérabilités consistent généralement à utiliser comme chaîne de format une chaîne venue de l'extérieur. C'est juste un exemple classique de saisie sans borne.
Par contre, je t'accorderais que la destination de cette lecture non-bornée n'est pas dans la pile, le débordement de tampon est donc moins directement exploitable (pas de stack smashing); mais demeure néanmoins dangereux (denial-of-service si le tas est géré par une liste chaînée, écrasement de pointeur de vtable dans le cas d'un code C++...)

[sambia39]

Pour faire simple, je suis d'accord avec vous sur le fait que les fonctions de la famille scanf dont fscanf occasionnent des overflow.
Comme gets non, pourquoi ? La passoire universelle gets est dite always vulnérable donc peu importe ce que l'on fait, on a toujours un overflow; tant dis que fscanf , est dit sometimes vulnérable, ce qui veut dire que l'overflow est dû à un bug format (erreur sur le tag format) ou dans le cas actuel un manque de spécificateur complémentaire comme vous l'avez signifié dans votre dernier message et que j'ai fait de même dans mon précédent sans préciser qu'il s'agissait de la taille ("Voir les erreurs dites "bugs format" (liées à toute la famille scanf dont fscanf."). fscanf est également sujet à un byte-off-by-one car même si la taille / tag format a été spécifié, il ne reste pas moins qu'il est sujet à un overflow. Exemple d'illustration « erreur bug format ».

Code C :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
-- snip --
    /*
    *    Avec un fichier dans lequel on a des données
    *    du style AZER 9999
    */
 
    (void)memset(buffer, 68, BUFSIZ );
    ret = fscanf(pFile, "%4s %d", buffer, &val );
 
    if( ret ){
 
        buffer[val] = 'X';
        (void)puts(buffer);
    }
 
    -- snip --

Finalement sur le principe des overflow les deux sont à l'identique et donc permettent des overflow, mais techniquement, ils ne sont pas identiques ou tout comme. fscanf est sujet ou soumis à des risques de bug format dans leur utilisation et techniquement les bugs format ne font pas partie des overflow même si la technique d'exploitation de ces bugs format sont très proches de celle des buffers overflow.


Quant aux vulnérabilités format string du style printf(buffer), j'ai bien précisé que ce ne sont techniquement pas des débordements de tampons, mais que l'on les classe le plus souvent à tord dans cette catégorie pour ensuite parler des "bugs formats" liés à toute la famille scanf dont fscanf.

à bientôt

[chrtophe]

De toute façon, on est plus censé utilisé gets depuis le C11, la fonction ayant été remplacée par gets_s. Un code avec gets ne compilera donc plus, sauf a utiliser les anciennes normes.