Discussion :

[.....1.....]

Bonjour à tous,

Tout d'abords, bon courage pour la lecture ! J'espère avoir posté au bon endroit, mais ça je le redirai et et je préciserai pourquoi j'ai choisi la section C.

Premier point :

Je débute un peu en programmation, et je ne parviens pas à m'expliquer techniquement de façon clair le phénomène suivant :

Voici l'idée : dans mon programme, je déclare plusieurs variables, et je souhaite écraser le contenu de l'une d'elle, en lui envoyant une valeur choisie. La variable int uNe = 0 est déclarée avant les autres ; vient ensuite la variable int dEux = ____, puis enfin char tRois[XX].

Mon souhait, c'est d'écraser le contenu de dEux en jouant avec uNe puis tRois - le programme est conçu ainsi, il est prévu pour, il permet justement de comprendre ce que je ne comprends pas - : ce qu'il faut faire, c'est envoyer une valeur qui, selon une condition du programme, va effectuer un décrémentation de uNe. Après quoi on va envoyer les valeurs que l'on souhaite placer dans dEux, ces valeurs étant donnée à tRois qui, grâce aux opérations de décrémentation effectuées sur uNe, vont aller se placer dans dEux.

M'avez-vous suivi ? Tout se base sur un jeu de conditions et de boucles. Je ne peux vous communiquer le code source : c'est un challenge qui exige confidentialité =/

Je débute également en Assembleur et en déboggage, toutefois, je vais essayer d'être le plus clair possible par rapport à ce que je ne comprends pas :

• uNe = 0x00000000 == 00000000 en binaire.
• Je décrémente : uNe = uNe - 1 == 0xFFFFFFFF == 11111111
• Je décrémente encore une fois : uNe = uNe - 1 == 0xFFFFFFFE == 1 0000 0000 ===> Déjà, est-ce correct ?
• Je décrémente encore : uNe = uNe - 1 == 0xFFFFFFFD == 1111 1111 ?...

Il y a donc un problème - voulu - : l'un des bits de ' uNe - 2 ' va être écrit là où il ne faut pas sur la pile. La faille est là : j'utilise cette erreur pour déplacer esp car, comme je l'ai dit, l'une des conditions permet de placer des valeurs dans tRois, sauf que esp ne pointant pas là où il le faudrait à cause de la décrémentation, je pourrai écraser dEux.

C'est ça que je ne comprends pas :

• Cette erreur de bit, en quoi permet-elle de déplacer esp ?? Ça fait trois jours que je planche là-dessus, mais rien à faire. Je vais attaquer une opération de déboggage plus sérieuse pour essayer de comprendre, toutefois comme je débute je galère encore un peu.
• La deuxième décrémentation permet d'obtenir un bit en plus (1 0000 0000), mais je ne vois pas en quoi la troisième permet de déplacer esp de nouveau...
• Je parle de esp, mais je me trompe peut-être ^^

C'est un challenge que j'ai réussi plus par déduction logique que par compréhension technique, et c'est ce qui m'embête justement ^^ Du coup ça fait plusieurs fois qu'on m'explique le concept, j'ai encore des pistes de recherche, donc je vais continuer de bosser ça, mais si quelqu'un pouvait me l'expliquer à travers des schémas, je pense que ça m'aiderait beaucoup. Je fonctionne beaucoup à l'aide de schéma et de captures d'écran (de pile par exemple).

Deuxième point :

Que me conseilleriez-vous pour évoluer de façon considérable en programmation système (C) ? J'utilise des cours .pdf, mais ça trouve vite des limites...du genre "programmer un menu qui ptati patata"...donc en soit, rien qui ne nécessite de syscall ou autre...

Troisième point :

Comme je l'ai dit, j'espère avoir posté au bon endroit ^^ Car de base, le sujet est l'audit d'un code C. D'ailleurs comme je m'intéresse aussi à l'ASM, si vous aviez-vous des ouvrages à me conseillez pour bien comprendre l'Assembleur, je suis preneur. J'ai utilisé des ouvrages .pdf également, toutefois il y avait plus de code balancé comme exemple que d'explications concrètes avec tutoriel.


Merci aux courageux qui liront jusqu'au bout, et aux généreux qui m'aideront'

[dalfab]

Bonjour,

Je vais essayer de répondre aux phrases avec un point d’interrogation :
M'avez-vous suivi ? Non.

Déjà, est-ce correct ? Non.

0xFFFFFFFD == 1111 1111 ? Non. Quand on soustrait 1 à un nombre, on obtient le nombre précédent. C'est vrai dans tous les langages, toutes les bases et pour tous les nombres. Sauf le précédent de 0 qui est le plus grand entier donc dans le "monde" 32 bits : 4294967295 soit FFFFFFFF hexa soit 11111111111111111111111111111111 binaire. En ôtant 1 on obtient 4294967294 soit FFFFFFFE hexa soit 11111111111111111111111111111110 binaire. En ôtant encore 1 on obtient 4294967293 soit FFFFFFFD hexa soit 11111111111111111111111111111101 binaire.

Cette erreur de bit, en quoi permet-elle de déplacer esp ?? D'où sort cette erreur de bit et cet ESP?

Que me conseilleriez-vous pour évoluer de façon considérable en programmation système (C) ? Apprendre un système (en choisir un avant s'apprendre les généralités), apprendre la programmation dans un langage simple. Ensuite s'intéresser au langage C, puis quelques langages assembleurs.

[Sve@r]

Bonjour

Je débute également en Assembleur et en déboggage, toutefois, je vais essayer d'être le plus clair possible par rapport à ce que je ne comprends pas

Tenter d'expliquer ce qu'on ne comprend pas...

uNe = 0x00000000 == 00000000 en binaire.
Je décrémente : uNe = uNe - 1 == 0xFFFFFFFF == 11111111

Non. 11111111=0x000000FF, pas 0xFFFFFFFF

Je décrémente encore une fois : uNe = uNe - 1 == 0xFFFFFFFE == 1 0000 0000 ===> Déjà, est-ce correct ?

Non plus. 11111111 - 1 = 11111110 et ça reste vrai dans toutes les bases.
Sinon pour convertir un hexa en binaire c'est assez facile: tu convertis chaque digit de l'hexa en binaire sur 4 chiffres et tu colles le tout. Exemple A5 c'est A (1010) et 5 (0101) donc 1010 0101. Et pour passer du binaire à l'hexa c'est l'inverse (tu regroupes les chiffres 4 par 4). C'est dû au fait que 16=2^4. Et en remarquant que 8=2^3 ou 9=3^2 ça te donne la technique analogue pour passer du binaire à l'octal (grouper les chiffres 3 par 3) ou de la base 3 à la base 9 si tu devais t'amuser à ça un jour (grouper les chiffres 2 par 2).

Il y a donc un problème - voulu - : l'un des bits de ' uNe - 2 ' va être écrit là où il ne faut pas sur la pile.

Non. En C, si une valeur dépasse la plage possible de la variable destinatrice, elle est tronquée et ce qui dépasse est perdu.

La faille est là : j'utilise cette erreur pour déplacer esp...

Non plus. En C, tout ce qui n'est pas autorisé produit un comportement indéterminé c'est à dire imprévisible. Au sens littéral. Si par exemple tu écris char tab[3]="abcd" tu ne peux absolument pas dire ce qui se passera. Peut-être que "tab" contiendra "abcd", peut-être seulement "abc", peut-être que le programme plantera, peut-être qu'il ne plantera pas, peut-être même que ça te reformatera ton disque dur. Imprévisible.

C'est un challenge que j'ai réussi plus par déduction logique que par compréhension technique, et c'est ce qui m'embête justement ^^

Comme dit M. Spock, même la logique doit s'effacer devant la physique (Star Trek VI, Terre Inconnue). Tu auras beau faire tous les raisonnements que tu voudras, tu seras fatalement confronté à la réalité du C.

Je ne peux vous communiquer le code source : c'est un challenge qui exige confidentialité =/

Tu peux nous communiquer l'énoncé. Ou juste les lignes où tu modifies et affiches tes variables...

Que me conseilleriez-vous pour évoluer de façon considérable en programmation système (C) ?

Tu peux t'amuser à divers TP. Un ping/pong à base de deux processus qui s'envoient un SIGUSR1 et SIGUSR2, un morse (ti-ta-ti) avec ces mêmes signaux, coder le problème des philosophes (sémaphores). Ou sinon tu refais un shell...

[Christophe]

As tu compris le fonctionnement de l'arithmétique signé ? je ne pense pas.
En arithmétique signée, le bit de poids fort est le bit de signe 0=positif, 1=négatif
11111111 en binaire = 255 en arithmétique non signé, mais -127 en arithmétique signé.

Si tu fais une addition provoquant un overflow en C, cela n’écrasera rien en mémoire, mais donnera un résultat erroné qui tiendra dans l'espace réservé à ta variable, il n'ira pas écrire une éventuelle retenue ou autre quelque part. Il faut implémenter toi-même le test de non dépassement si besoin. En assembleur c'est pareil, mais tu au auras le flag buffer overflow du CPU de positionné. Si tu ne testes pas ce flag, temps-pis pour toi, tu travailleras avec des résultats erronés mais tu n'auras pas de crash sauf à générer des trucs interdits comme une divison par 0, un accès à une adresse mémoire non autorisée.

Après pour écraser des variables, rien de bien compliqué.Tu récupères l'adresse d'une de tes variables et tu écrit des octets derrière. Chacune de tes variables va avoir une adresse mémoire, chaque variable étant l'une derrière l'autre. Par contre, rien n'empêche le compilateur de ne pas stocker tes variables dans le même ordre que toi, ou de laisser quelques octets vides entre 2 variables. Mais en bidouillant le contenu de tes variables, tu auras ce qu'on appelle des comportements indéfinis.

L'évocation de ESP me fait penser que tu veux faire un shelcode.

En usage normal, tu n'as pas à toucher à la pile en C. Et il y a des techniques permettant de protéger la pile (cookie). Et la pile est censée être non exécutable avec le bit NX. Il y a aussi l'ALSR.

Donc en gros, tu vas compromettre ton propre programme, mais normalement pas l'OS.

[.....1.....]

Bonjour à tous, et merci pour vos réponses.

Alors en effet, je n'ai pas été très clair dans mes explications. Comme quoi un jour de pause aide à y voir moins flou...je connais effectivement les calculs arithmétiques et les règles de conversions binaire/hexadécimal/décimal. Mais je me suis bien mal exprimé...

J'ai donc eu une meilleure idée : le code source est en accès libre, il n'est donc pas interdit de le partager (on a le droit d'accéder au challenge sans condition). Ce qui est interdit, c'est d'en dévoiler la solution - la commande à exécuter et qui aboutirait donc sans aucune réflexion à la solution, par exemple -. Du coup, je vais soit vous transmettre le code source ici, en l'épurant un peu, soit réécrire un programme semblable.

Je pense que ça me permettra de vous aider à cerner plus explicitement ce que je ne comprends pas...

A demain !!

[Kannagi]

j'utilise cette erreur pour déplacer esp car, comme je l'ai dit, l'une des conditions permet de placer des valeurs dans tRois, sauf que esp ne pointant pas là où il le faudrait à cause de la décrémentation, je pourrai écraser dEux.

C'est ça que je ne comprends pas :

• Cette erreur de bit, en quoi permet-elle de déplacer esp ?? Ça fait trois jours que je planche là-dessus, mais rien à faire. Je vais attaquer une opération de déboggage plus sérieuse pour essayer de comprendre, toutefois comme je débute je galère encore un peu.
• La deuxième décrémentation permet d'obtenir un bit en plus (1 0000 0000), mais je ne vois pas en quoi la troisième permet de déplacer esp de nouveau...
• Je parle de esp, mais je me trompe peut-être ^^

Déjà si on fait du C , osef de l'assembleur ,le compilateur s'assurera de faire le code demandé surtout que bon depuis quelque années on devrait parler de RSP et non ESP , de plus les registres étant généraux rien n’empêche d'utiliser un autre registre , et si on reste strictement sur le C alors le compilo peut utiliser un autre registre pour la pile si ça lui chante
(même si par convention ça risque d’être compliqué , mais pas impossible ).
Sinon ton explication n'a pas de sens , esp étant la pile, si tu décrémente une variable ça change pas l'adresse de la pile

D'ailleurs comme je m'intéresse aussi à l'ASM, si vous aviez-vous des ouvrages à me conseillez pour bien comprendre l'Assembleur, je suis preneur. J'ai utilisé des ouvrages .pdf également, toutefois il y avait plus de code balancé comme exemple que d'explications concrètes avec tutoriel.

C'est une question qui revient souvent et on répond toujours par : "il y 'en a pas vraiment" , l'assembleur à "disparu" vers la fin des années 1995 , et depuis il n'est plus vraiment utilisé , de plus les processeurs modernes étant largement plus complexe , les comprendre demandent un sacré bagage , mais je conseille personnellement de s’intéresse a des processeurs 8 bits en premier (un avr Atmel , ou un vieux proc).

[.....1.....]

Hello, merci pour ta réponse.

L'assembleur est utile quand je déboggue un binaire...

Bon, voici le code source, que j'ai un peu bidouillé:

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
#include <stdio.h>
#include <stdlib.h>
 
void win(void);
 
int main()
{
	char rouleau[64];
	int pate;
	int tamp = 0;
	int boum = 0;
 
	while(1)
	{
		if (boum >= 64)
			printf("Nopnopnopnop...\n");
		if(pate == 0xaaaaaaaa)
			win();
		else
		{
			read(fileno(stdin),&tamp,tamp);
			switch(tamp)
			{
				case 0x88:
					boum--;
					break;
				case 0x66:
					printf("Nop...");
					boum++;
					break;
				default:
					rouleau[boum] = tamp;
					boum++;
					break;
			}
		}
	}
}
 
void win(void)
{
	printf("Bien joue !!");
}

Le but, c'est de faire apparaître "Bien joue !!" à l'écran. Pour cela, on utilise le fait que boum est un int signé : on le décrémente quatre fois, puis on envoie dans rouleau le contenu de ce que l'on souhaite placer dans pate afin d'appeler la fonction win. Pour écrire dans rouleau, le default du switch nous y aidera.

Exemple : envoyer dans le stdin les paramètres suivants : ' \x88'*4+'\xaa'x4 /////// La première partie permet la décrémentation, la deuxième permet l'écriture de la valeur dans pate.

Et voilà, en fait...je viens de comprendre le pourquoi du comment en écrivant ce texte ==> rouleau[boum] : ici, on écrit au boum octet de rouleau, sauf que boum ==... -4 : dans la pile, on va écrire quatre octets avant rouleau, donc dans...pate.

J'ai mis le temps mais je pense que j'ai été embrouillé par une explication que j'aurais mal interprétée. Merci à vous en tout cas, j'ai résolu mon problème, et je comprends mieux vos explications concernant ce satané bit sans effet quelconque Le truc c'est que j'ai abordé ce code comme s'il comportait une faille système ou l'utilisation d'une fonction non sécurisée, or là c'est plutôt un puzzle permettant d'écrire où on le souhaite, donc dans pate.

Autrement je vais suivre vos conseils concernant les pistes d'apprentissage'

[Matt_Houston]

Je vais pas écrire autre chose que les intervenants précédents : si bidouiller ce genre de choses te plaît, fais de l'assembleur. Au moins ce sera déterministe.

En C, il existe la notion de comportement indéterminé : à partir du moment où ton programme effectue une opération illicite, l'implémentation n'est tenue à aucune mission. L'écrasement de pile dans ton environnement peut se traduire par un lancement de missile ballistique intercontinental dans un autre. Surtout, tu ne peux pas en déduire grand chose, ni t'en servir pour le développement d'un logiciel qualitatif.

[Sve@r]

Exemple : envoyer dans le stdin les paramètres suivants : ' \x88'*4+'\xaa'x4 /////// La première partie permet la décrémentation, la deuxième permet l'écriture de la valeur dans pate.

Parce que "tamp" est défini juste avant "pate" ? Ben c'est possible mais ce n'est pas garanti et surtout ça produit un comportement indéterminé. Le C est totalement permissif car sa philosophie est "le programmeur sait ce qu'il fait". C'est voulu afin qu'il aille le plus vite possible. Mais quand le programmeur ne sait pas ce qu'il fait ou qu'il tente volontairement un truc zarbi alors ça part en torche totale.
Et les trucs zarbis ne sont pas forcément compliqués à trouver. Par exemple i=0; printf("%d %d\n", i++, i++) donnera un affichage imprévisible.

Et même ton read(fileno(stdin),&tamp,tamp); me semble foireux. Bon déjà fileno(stdin) peut se remplacer par STDIN_FILEN0 (plus rapide d'utiliser une constante qu'une fonction qui calcule le même résultat) mais surtout le 3° paramètre "tamp" me laisse perplexe car la fonction attend à cet endroit le nb d'octets à lire...

or là c'est plutôt un puzzle permettant d'écrire où on le souhaite, donc dans pate.

La seule bonne façon d'écrire dans "pate" est d'écrire réellement dans "pate". Soit directement, soit en passant par son adresse. Mais tu ne pourras pas y écrire de façon certaine si tu tentes un truc batard comme d'écrire dans la variable d'à côté en espérant un débordement.

[Médinoc]

Au passage, ton premier message sous-entend une incompréhension du fonctionnement des nombres négatifs binaires. Ce sera peut-être plus facile à comprendre en décimal:

• Prend un bête compteur à trois chiffres, comme on en trouvait sur les magnétophones dans les années 80.
• On considère qu'au départ, ce compteur affiche "043"
• On ajoute 999 au compteur.
• Quel est le résultat final?

[.....1.....]

Salut

@Sve@r je comprends tout à fait le sens de tes remarques. Après comme je l'ai dit, le code n'est pas de moi, j'ai réutilisé les fonctions du code que j'ai repris afin de mieux illustrer mon problème. Néanmoins je prends bonne note de tes remarques pour le jour où j'écrirai un code digne de ce nom.

@Médinoc oui c'est possible Je n'ai pas fait d'école d'informatique, mais j'ai eu quelques cours à ce sujet : de mémoire je ne comprenais rien...donc, pour répondre à ta question, je dirais :

• 042.