Discussion :

[Lucas Panny]

Bonjour,

Je suis à la recherche d'un outil qui permet de tester un projet au niveau des erreurs: fuites de mémoires, buffer overflow, etc.
Je connais un peu KlocWork mais y a-t-il d'autres? Freeware?

Pour tester un projet ASSEMBLEUR par ex?

[bruno_pages]

klocwork fait une analyse statique du code

Pour une vérification à l'exécution il y a valgrind, mais seulement pour certains processeurs. Evidemment cela ne marchera pas pour un programme assembleur 'pure' (non issus d'une compilation c/c++) car dans ce cas valgrind sera incapable de savoir par exemple qu'on alloue/désalloue de la mémoire, il ne le sait qu'en repérant les appels aux fonctions d'allocation/désallocation 'standard'

[Lucas Panny]

Donc il ne sera jamais possible d'analyser les bugs d'un .exe ou autres binaires?

J'ai testé avec Klocwork un projet C++ et il affiche toujours des Security Vulnerabilities sur les buffers overflow (sprintf et autres). N'est-ce pas déjà évité par mon compilateur: Visual C++ 2005?

[bruno_pages]

Donc il ne sera jamais possible d'analyser les bugs d'un .exe ou autres binaires?

si s'il est compatible valgrind (ce qui est le cas sous Linux avec un processeur Intel par exemlpe, compilation avec debug of course)

J'ai testé avec Klocwork un projet C++ et il affiche toujours des Security Vulnerabilities sur les buffers overflow (sprintf et autres). N'est-ce pas déjà évité par mon compilateur: Visual C++ 2005?[/QUOTE]

ce n'est pas au compilateur de corriger les erreurs du programmeur

sur

Code :

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

1
2
3
4
int i = ...;
char s[4];
sprintf(s, "%d", i);

klocwork produit un buffer overflow car il y a pas mal d'entiers dont la représentation sous forme de chaine ne tient pas sur 3 caractères

[Lucas Panny]

Les risques de dépassement de pile sont quelquefois managés par certains compilateurs:

Toutefois elle reste assez complexe à mettre en oeuvre car les protections contre ce type de failles se multiplient (protection anti-dépassement de tampon depuis gcc 4.1, patch sur gcc tels que StackShield / PaX, compilateur StackGuard, flag /GS sous Microsoft Visual C++, …).

Avec Visual C++ que j'utilise, lorsqu'on compile: utiliser /GS

Concernant Valgrind, ne s'associe-t-il pas à un compilateur et teste après le binaire produit? C'est à dire qu'on n'y teste pas n'importe quel exécutable? En fait, il semble qu'il ne détecte pas les erreurs de dépassement mais seulement les non désalloués et les fuites?

[bruno_pages]

[QUOTE=Lucas Panny;3771927]Avec Visual C++ que j'utilise, lorsqu'on compile: utiliser /GS
débordement de pile et débordement de tampon ne sont pas la même chose, même si le second peut éventuellement provoquer le premier

Concernant Valgrind, ne s'associe-t-il pas à un compilateur et teste après le binaire produit?

comprends pas, que veut dire s'associe-t-il ?

En fait, il semble qu'il ne détecte pas les erreurs de dépassement mais seulement les non désalloués et les fuites?

il teste aussi les débordement de structures allouées lorsque le compilateur produit des accès du type read/write(adresse_base, offset)

encore une fois c'est un interpréteur de binaire, il n'a donc pas accès au programme initiale et à la sémantique associée sauf en repérant les appels de quelques fonctions particulières comme celles liées aux allocations

[Lucas Panny]

Concernant valgrind, merci j'ai pigé son fonctionnement!
Concernant les débordements/dépassements, je parle du buffer overflow, valgrind détecte-t-il?

Y a-t-il des freewares sur l'équivalent de KlocWork?

[bruno_pages]

Concernant les débordements/dépassements, je parle du buffer overflow, valgrind détecte-t-il?

tu as lu mes réponses précédentes ?
tu comprendras peut être mieux avec des exemples :

Code :

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

1
2
3
4
5
6
7
8
int a[8];
int b;
char * p = new int[16];

a[9] = 0; // valgrind ne voit rien car il ne connait pas la taille de 'a'
b = a[2]; // valgrind indique un accès à de la mémoire non initialisée ('a' non initialisé)
b = p[17]; // valgrind voit le débordement car il connait la taille du vecteur

[Lucas Panny]

OK merci Valgrind est donc à peu près ce que je cherche (tester un .EXE)

[Lucas Panny]

L'ironie avec Klocwork c'est qu'il ne détecte pas la plupart des probables overflow de buffer dans mon projet

ex:

Code :

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

1
2
3
4
5
const INT ACCUMULATOR_CHAR_COUNT				= 2048;

BOOL CUTF16File::LoadAccumulator()
{
	BYTE cbBuffer[ACCUMULATOR_CHAR_COUNT * sizeof(WCHAR)];

[bruno_pages]

je ne comprends pas, où est sensé être le problème dans ce code ?

[Lucas Panny]

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
BOOL CUTF16File::LoadAccumulator()
{
	BYTE cbBuffer[ACCUMULATOR_CHAR_COUNT * sizeof(WCHAR)];

	UINT uCount = CStdioFile::Read(cbBuffer, ACCUMULATOR_CHAR_COUNT * sizeof(WCHAR));

	WCHAR* pwszBuffer = reinterpret_cast<WCHAR*>(cbBuffer);

	for(UINT i = 0; i < uCount / 2; i++)
	{
		WCHAR c = *pwszBuffer++;

		if(TRUE == m_bByteSwapped)
		{
			BYTE b1 = BYTE(c >> 8);   // high order
			BYTE b2 = BYTE(c & 0xFF); // low order

			c = WCHAR(b1 | (b2 << 8));
		}

		m_Accumulator.push_back(c);
	}

	return 0 == uCount;
}

En fait, on charge dans cbBuffer du texte, et bien à un certain cas, des données dépassant 2048*sizeof(WCHAR) sont entrées causant un STACK OVERFLOW!!

[Lucas Panny]

Le problème avec VALGRIND c'est que c'est pour LINUX, je travaille sous WinXP