Influence d'un int non signé sur le comportement de la pile

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'

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.

Bonjour

Citation:

---

Envoyé par .....1.....

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

Citation:

---

Envoyé par .....1.....

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

---

Non. 11111111=0x000000FF, pas 0xFFFFFFFF

Citation:

---

Envoyé par .....1.....

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

Citation:

---

Envoyé par .....1.....

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.

Citation:

---

Envoyé par .....1.....

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.

Citation:

---

Envoyé par .....1.....

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.

Citation:

---

Envoyé par .....1.....

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

Citation:

---

Envoyé par .....1.....

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

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.

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

Citation:

---

Envoyé par .....1.....

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 :aie:
(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 :aie:

Citation:

---

Envoyé par .....1.....

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

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:

---

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 :aie: ==> 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 :mrgreen::mrgreen::mrgreen: 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'

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.

Citation:

---

Envoyé par .....1.....

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

Citation:

---

Envoyé par .....1.....

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.

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?

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

Haha, grillé, je sais exactement de quel challenge ça vient... Bonjour R***-*E.

- D'une part tu n'as pas compris l'arithmétique binaire et c'est dommage parce que c'est très simple.
- D'autre part l'arithmétique binaire ne sert pas du tout dans ce challenge mais alors vraiment aucun rapport.
- Ni l'assembleur d'ailleurs

Renseigne toi sur la mécanique de Stack Buffer Overflow, c'est ça qui te permettra de résoudre ce challenge. Honnetement vu tes interventions tu n'as rien compris ni à la logique de l'exploit ni à son fonctionnement bas-niveau.

Comment se passe l'écriture dans un tableau en mémoire?

Reprend le code original, essaye de comprendre comment tu pourrais écrire sur la variable pate (check dans le code original).

Au fait, comme ça, ça marche mieux read(fileno(stdin),&tmp,1);
Note: Pour la prochaine fois, tu peux demander de l'aide directement sur le forum de R***-*E, ou sur leur IRC c'est plus adapté qu'ici.

Citation:

---

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.

---

Ici, le but c'est justement d'exploiter un Stack Buffer Overflow donc c'est normal si c'est bizarre. On exploite un comportement indéterminé selon les normes C mais clairement déterministe et assez logique (https://stackoverflow.com/questions/...s-allowed-in-c)

PS: Je vois que tu ne comprends pas la base du challenge ni les concepts sous-jacents: My two cents: tu as simplement regardé une solution sur internet et tu n'as pas résolu le challenge. Honnêtement je m'en fous mais l'objectif c'est d'apprendre et si tu ne te forces pas à les faire tu apprends très peu, le fait d'essayer de comprendre la solution n'est pas suffisant car il te manque le cheminement logique pour y arriver Bref, les Buffers Overflow, ça ne s'apprend pas du jour au lendemain (même si celui-ci est relativement simple). Revois les bases de l'informatique avant de te lancer dedans ou tu vas vite te retrouver face à un mur.

Citation:

---

Envoyé par emixam16

Haha, grillé, je sais exactement de quel challenge ça vient... Bonjour R***-*E.

---

Et grâce à toi, maintenant moi aussi ;)
Je vais peut-être m'attaquer à la partie "Cr.........e" vu que je semble doué pour ça... :D

Citation:

---

Envoyé par .....1.....

@Médinoc oui c'est possible :aie: 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.

---

Et c'est là tout le principe des nombres négatifs sur la plupart des architectures informatiques de nos jours: Sur trois chiffres décimaux, on considère que 999 c'est -1. Sur 32 bits, on considère que 11111111 11111111 11111111 11111111 c'est -1.
En gros, toute la moitié "supérieure" de l'espace représentable est considérée comme négative (et l'Unité Arithmétique et Logique (ALU) du processeur possède des circuits spéciaux pour prendre ça en compte sur les comparaisons, les soustractions, etc.).

Merci encore pour vos réponses.

Effectivement, je n'ai rien compris à quoi que ce soit mais comme les réponses sont sur Google, à quoi bon me faire chier à essayer de comprendre.

Ça marche Médinoc merci pour cette explication :)

Citation:

---

Effectivement, je n'ai rien compris à quoi que ce soit mais comme les réponses sont sur Google, à quoi bon me faire chier à essayer de comprendre.

---

Tu as raison, à quoi bon s’embêter à apprendre quoi que ce soit, vu que tout est disponible sur internet... Autant tout copier-coller sans fatiguer son cerveau à réfléchir.

Citation:

---

Je vais peut-être m'attaquer à la partie "Cr.........e" vu que je semble doué pour ça... :D

---

Et tu fais bien, ces challenges sont dans l'ensemble très bien faits et assez progressifs. Il faut quand même être une brute en C****o pour passer les derniers challenges!

Citation:

---

Envoyé par emixam16

Tu as raison, à quoi bon s’embêter à apprendre quoi que ce soit, vu que tout est disponible sur internet... Autant tout copier-coller sans fatiguer son cerveau à réfléchir.

---

Ben tu es sarcastique... mais j'ai bien l'impression que c'est ce vers quoi on tend. Maintenant les exposés sont faits à partir du net, les profs mettent leurs cours sur youtube, et on trouve même des sites offrant aux élèves de faire faire leurs devoirs par des pros contre rémunération et du site, et du pro. Alors...
Ce sujet a même fait l'objet d'un épisode de "Au delà du réel, l'aventure continue" où toute la population est connectée au cloud par une oreillette et peut accéder directement à n'importe quelle info (Sursaut de conscience, saison 3, épisode 5).

Citation:

---

Envoyé par emixam16

Tu as raison, à quoi bon s’embêter à apprendre quoi que ce soit, vu que tout est disponible sur internet... Autant tout copier-coller sans fatiguer son cerveau à réfléchir.

---

Tu affirmes que j'ai bêtement cherché la solution sur le Net pour résoudre le problème, et que suite à ça je n'ai pas fait l'effort de chercher à comprendre. Or tu vois bien que j'ai essayé de comprendre, et que j'y suis même arrivé. Quant à la façon que j'ai utilisée pour obtenir une solution au fameux challenge, je ne sais pas où tu as vu que j'étais allé chercher ça sur Internet. Sauf que quelqu'un m'a à un moment mis sur une fausse piste et je me suis buté à essayer de comprendre alors que j'avais probablement mal interprété son propos.

Bref, on ne va pas faire un scandale pour si peu. Mais moi je ne suis pas doctorant en sécurité informatique - si je ne me trompe pas - donc ce qui paraît simple pour toi ne l'est pas forcément pour un autodidacte débutant.

Mais je suis bon joueur, et je ne t'en veux pas car effectivement la solution se trouve sur Google - j'ai cherché ce matin :mrgreen: -.

Sinon Sve@r c'est triste mais pendant mes études j'avais un prof qui nous disait d'aller voir sur Wikipédia pour approfondir son cours - sous-entendu ce qu'il avait la flemme d'expliquer -.

Apluss'