[Débutant] xor ebx, ebx => segfault

**Gabriel13012** · 01/05/2017, 19h25

Bonjour à tous

tout d'abord, je précise que je ne m'y connais pas du tout en ASM, et je suppose que le problème que j'expose ici est trivial pour vous.

J'ai souhaité faire une petite expérience avec un code C basique que voici :

Code C :

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

1
2
3
4
5
6
7
8
9
10
11
#include <stdio.h>
 
 
unsigned char buf[] = "\x31\xdb";
 
 
int main(void){
        ((void (*)(void)) buf)();
        return 0;
 
}

Il s'agit simplement d'un programme qui réalise un appel vers buf, contenant un simple xor ebx, ebx
A l'exécution, si je débug le tout avec gdb et que j'affiche les instructions ASM, j'arrive à quelque chose comme ça :

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
0x080483db <+0>:	lea    ecx,[esp+0x4]
0x080483df <+4>:	and    esp,0xfffffff0
0x080483e2 <+7>:	push   DWORD PTR [ecx-0x4]
0x080483e5 <+10>:	push   ebp
0x080483e6 <+11>:	mov    ebp,esp
0x080483e8 <+13>:	push   ecx
0x080483e9 <+14>:	sub    esp,0x4
0x080483ec <+17>:	mov    eax,0x804a014
0x080483f1 <+22>:	call   eax
0x080483f3 <+24>:	mov    eax,0x0
0x080483f8 <+29>:	add    esp,0x4
0x080483fb <+32>:	pop    ecx
0x080483fc <+33>:	pop    ebp
0x080483fd <+34>:	lea    esp,[ecx-0x4]
0x08048400 <+37>:	ret

et mon buffer :

Code :

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

1
2
0x0804a014 <+0>:	xor    ebx,ebx
0x0804a016 <+2>:	add    BYTE PTR [eax],al

Seulement voilà, l'instruction xor ci-dessus provoque un SIGSEGV et je n'arrive pas à comprendre pourquoi.
A noter que ce comportement n'intervient que si j'ai une instruction call vers le buffer
(ne serait-ce pas d'ailleurs plus logique que ce soit elle qui lève le sigsegv ? Mais si oui, pourquoi ? Et pourquoi l'exception n'est levée qu'après l'exécution du xor ?)

Merci d'avance pour vos lumières

**Prof** · 02/05/2017, 11h17

Bonjour.

Ce n'est pas l'instruction "xor ebx,ebx" qui provoque le segfault, mais ce qui suit cette instruction.

Une procédure doit obligatoirement se terminer par un retour, lequel est codé C3 dans la version la plus simple.

Comme ici l'instruction retour n'a pas été prévue, le processeur poursuit l'exécution après "xor ebx,ebx".
Et il interprète tout ce qui suit comme du code, alors que ce n'est pas du code.
Le plantage est inévitable ...

**Gabriel13012** · 03/05/2017, 20h52

Envoyé par Prof

Bonjour.

Ce n'est pas l'instruction "xor ebx,ebx" qui provoque le segfault, mais ce qui suit cette instruction.

Une procédure doit obligatoirement se terminer par un retour, lequel est codé C3 dans la version la plus simple.

Comme ici l'instruction retour n'a pas été prévue, le processeur poursuit l'exécution après "xor ebx,ebx".
Et il interprète tout ce qui suit comme du code, alors que ce n'est pas du code.
Le plantage est inévitable ...

Merci pour cette réponse,

cependant, je ne comprends toujours pas.
L'ajout d'une instruction return provoque le même plantage.

J'ai compilé le même code qu'au dessus, mais en changeant les instructions de mon buf, de manière à rajouter le return :

unsigned char buf[] = "\x31\xdb\xc3";

et c'est toujours pareil

J'ai débogué le tout avec gdb, et ai suivi l'exécution du programme pas à pas. L'exception est levée juste après l'exécution du xor ebx, ebx
Je me doute que ça ne vient pas de ça, mais peu importe ce que je place derrière cette instruction, j'ai exactement le même résultat
(par exemple, avec une suite de xor ebx, ebx:
unsigned char buf[] = "\x31\xdb\x31\xdb\x31\xdb\x31\xdb\xc3"; )

N'y-a-t-il pas quelque chose que j'ai raté/pas pensé à faire après le call ? Une initialisation ou quelque chose comme ça ?

EDIT: je viens de lancer le programme avec Valgrind et voilà le résultat:

==5848== Process terminating with default action of signal 11 (SIGSEGV)
==5848== Bad permissions for mapped region at address 0x601020

Il semblerait qu'il y ait un problème de droit d'exécution à l'adresse où sont chargées mes instructions. Sécurité Linux ?

**Obsidian** · 04/05/2017, 00h15

Bonjour,

Ce que dit Prof est déjà vrai en soi mais il faut également tenir compte de quelque chose d'autre : le programme exécutable est chargé dans un segment de code et les données dans un segment de données distinct. Et celui-ci est généralement privé du droit d'exécution, à l'aide d'un bit spécial.

Tu ne peux donc pas insérer le code directement de cette façon sur un système multitâche grand public fonctionnant sur PC en mode protégé. Par contre, tu peux tout-à-fait écrire de l'assembleur inline au sein de ta fonction en écrivant asm("ton code assembleur…");. Tu pourras alors écrire directement les instructions que tu veux utiliser. Si tu tiens à les écrire en hexadécimal quand même, il faudra passer par db.

**Prof** · 04/05/2017, 09h30

Bonjour.

Effectivement, j'avais vu que le code de la procédure était incomplet, mais j'avais zappé le fait que cette procédure se trouvait en fait dans la zone des données.