ASM dans programme C

Version imprimable

05/07/2008, 17h53
chuko

ASM dans programme C

Bonjour a tous, voila ma question et simple comment faire executer un code ASM en l'occurence un shell code dans un programme C?
J'avai penser a creer un pointeur sur mon shellcode et ensuite faire sauter ma fonction dessu mais j'ai beaucou de mal a realiser mon code source y a til une commande special pour executer mon shellcode dans mon programme c merci d'avance.
06/07/2008, 08h56
battosai.mt67
Si tu veux executer de l'asm dans ton code C, tu peux le faire en mettant dans ton code:
Code:

1 2 3 asm("codeAsm"); par exemple asm("push eax");
voila ++
06/07/2008, 09h29
Melem
Citation:
Envoyé par battosai.mt67

Si tu veux executer de l'asm dans ton code C, tu peux le faire en mettant dans ton code:

Code:

1 2 3 asm("codeAsm"); par exemple asm("push eax");

voila ++
Bon tout d'abord tu utilises là une extension du langage C apportée par certains compilateurs dont gcc mais en plus ça ne répond pas complètement à la question.

Citation:

Envoyé par chuko

Bonjour a tous, voila ma question et simple comment faire exécuter un code ASM ... dans un programme C ?

En utilisant l'assembleur en ligne, comme l'a montré battosai.mt67 si tu utilises gcc. La syntaxe est différente sous Visual C++ ou C++ Builder par exemple.

Citation:

Envoyé par chuko

J'avais pensé a créer un pointeur sur mon shellcode et ensuite faire sauter ma fonction dessus mais j'ai beaucoup de mal a réaliser mon code source y a t-il une commande spéciale pour exécuter mon shellcode dans mon programme C ?

Il n'y a pas de commande spéciale. Tu crées un buffer contenant le code à exécuter, tu pointes sur ce buffer avec un pointeur de fonction puis tu appelles la fonction. Le code contenu dans le buffer doit donc être le code d'une fonction complète. Il "suffit" donc de bien connaître le langage machine du processeur utilisé.
06/07/2008, 15h59
chuko

merci pour vos reponse elle sont plus clair que je ne l'esperai n'avrez d'avoir repondu si tard mais jusque la personne n'avai repondu merci encore je vai essayer de sivre vos conseil
06/07/2008, 16h41
chuko

re code asm dans C

bonjour, bon je revient sur un poste que j'ai moi meme poste car je n'ai toujour, pas pu résoudre mon problème a savoir executer un shellcode contenu dans buffer dans un programme C.
Sur vos conseil j'ai créer un pointeur sur mon buffer,le probleme etant que je sais pa comment faire sauter ma fonction dessu, si quelqu'un pouvait me mettre un code d'exemple juste pour que je comprenne le principe ce serai sympa vraiment merci par avance .
06/07/2008, 23h16
dapounet

Citation:

Envoyé par Melem

Bon tout d'abord tu utilises là une extension du langage C apportée par certains compilateurs dont gcc mais en plus ça ne répond pas complètement à la question.

En utilisant l'assembleur en ligne, comme l'a montré battosai.mt67 si tu utilises gcc. La syntaxe est différente sous Visual C++ ou C++ Builder par exemple.

Il n'y a pas de commande spéciale. Tu crées un buffer contenant le code à exécuter, tu pointes sur ce buffer avec un pointeur de fonction puis tu appelles la fonction. Le code contenu dans le buffer doit donc être le code d'une fonction complète. Il "suffit" donc de bien connaître le langage machine du processeur utilisé.

Ça m'intéresserait d'avoir un exemple concret.

J'avoue ne pas voir trop le rapport entre un shellcode et un pointeur de fonction melem, je n'ai même jamais vu de shellcode basé sur des pointeurs de fonctions, d'ordinaire, on s'en sort avec un truc du genre :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 #include <stdint.h> char shellcode[] = "\xeb\x2a\x5e\x89\x76\x08\xc6\x46\x07\x00\xc7\x46\x0c\x00\x00\x00" "\x00\xb8\x0b\x00\x00\x00\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80" "\xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xe8\xd1\xff\xff" "\xff\x2f\x62\x69\x6e\x2f\x73\x68\x00\x89\xec\x5d\xc3"; int main (void) { intptr_t *ret = (intptr_t *)&ret + 2; (*ret) = (intptr_t)shellcode; return 0; }
fonctionne sous linux i386/x86_64 (shell spawning shellcode : un classique sans la gestion des NUL bytes).

J'avais essayé ça mais ça plante :

Code:

1
2
3
4
5
6
7
8
9
unsigned char shellcode[] = "\xC3";  /* RET */
 
int main (void)
{
  void (*f) (void) = (void (*) ())shellcode;
  (*f)();
 
  return 0;
}

Pourtant ça a pas l'air faux :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
0000000000400530 <main>:
  400530:	55                   	push   rbp
  400531:	48 89 e5             	mov    rbp,rsp
  400534:	48 83 ec 10          	sub    rsp,0x10
  400538:	48 c7 45 f8 40 06 50 	mov    DWORD PTR [rbp-8],0x500640
  40053f:	00 
  400540:	48 8b 45 f8          	mov    rax,DWORD PTR [rbp-8]
  400544:	ff d0                	call   eax
  400546:	b8 00 00 00 00       	mov    eax,0x0
  40054b:	c9                   	leave  
  40054c:	c3                   	ret    
  40054d:	90                   	nop    
  40054e:	90                   	nop    
  40054f:	90                   	nop   
 
[...]
 
0000000000500640 <shellcode>:
  500640:	c3                   	ret    
  500641:	00 00                	add    BYTE PTR [rax],al

Je me disais que ça devait juste être parce que .data n'est pas exécutable mais le tien fonctionne en 32 bits... bizarre.
Mais ça sert à quoi de tout mettre en hexadécimal en fait, c'est juste pour faire style ?

07/07/2008, 08h15
nicolas.sitbon

Citation:

Envoyé par dapounet

Mais ça sert à quoi de tout mettre en hexadécimal en fait, c'est juste pour faire style ?

Heu non! le shellcode ne tombe pas du ciel, généralement, on les forge toujours à partir d'un désassembleur et comme la sortie de celui-ci est en hexa, on va pas s'amuser à le changer de base pour le plaisir.
Oublie le pointeur de fonction, je n'ai jamais vu ça de ma vie!
07/07/2008, 14h18
Melem

Citation:

Envoyé par dapounet

J'avais essayé ça mais ça plante : ...

Evidemment que ça plante. Dans la convention d'appel du C une fonction doit commencer par push ebp, mov ebp, esp et se terminer par ret. Si la fonction retourne un entier, c'est eax qui est retourné. Si tu utilises la méthode exposée par nicolas.sitbon, tu n'as pas besoin de te soucier de cela car c'est déjà fait par main, on écrase tout simplement l'adresse de retour par l'adresse du buffer contenant le shellcode (c'est également le principe de l'exploitation du buffer overflow ...). C'est la méthode "commune", l'autre c'est une méthode que j'ai mis au point car elle permet non seulement de copier bêtement le code d'une fonction en la désassemblant mais aussi d'exécuter plus d'un shellcode à l'intérieur d'une fonction. Par contre c'est plus lent à l'exécution à cause des instructions supplémentaires, mais les deux méthodes sont tous valables.

Citation:

Envoyé par dapounet

Mais ça sert à quoi de tout mettre en hexadécimal en fait, c'est juste pour faire style ?

Déjà répondu par nicolas.sitbon, mais ce n'est pas une obligation.
07/07/2008, 14h58
Lucien63

Citation:

Envoyé par Melem

Dans la convention d'appel du C une fonction doit commencer par push ebp, mov ebp, esp et se terminer par ret.

Ce n'est pas une obligation absolue, et dans le code de dapounet ce n'est pas indispensable.
De plus ce n'est pas tout à fait cela mais "push ebp", "mov ebp,esp" et se terminer par "mov sp,bp"(si variable locales) "pop ebp" puis "ret".
Ce morceau de code sert à sauvegarder le pointeur de pile et le restituer à la sortie de la fonction (C'est d'ailleurs ce qui libère toutes les variables locales alloué sur la pile dans une fonction). Si tu ne touche pas au pointeur de pile (esp) alors tu peux t'en passer.

Le code de dapounet fonctionne. je l'ai testé.
07/07/2008, 15h36
dapounet

Citation:

Envoyé par nicolas.sitbon

Heu non! le shellcode ne tombe pas du ciel, généralement, on les forge toujours à partir d'un désassembleur et comme la sortie de celui-ci est en hexa, on va pas s'amuser à le changer de base pour le plaisir.

En voyant le contenu du shellcode ça a sans doute écrit en assembleur donc je me demandais l'intérêt de passer par ce machin-là. Au fait INT 0x80 fonctionne sur un Linux 64 bits ou tu voulais dire qu'il faut le compiler en 32 bits et le faire tourner en "émulation" 32 bits ?

Citation:

Envoyé par Melem

Evidemment que ça plante. Dans la convention d'appel du C une fonction doit commencer par push ebp, mov ebp, esp et se terminer par ret. Si la fonction retourne un entier, c'est eax qui est retourné.

C'est sans doute pour ça que VC++ et GCC ont des options (-fomit-frame-pointer pour GCC) pour ne pas créer ces instructions.

Citation:

Envoyé par Lucien63

De plus ce n'est pas tout à fait cela mais "push ebp", "mov ebp,esp" et se terminer par "mov sp,bp"(si variable locales) "pop ebp" puis "ret".
Ce morceau de code sert à sauvegarder le pointeur de pile et le restituer à la sortie de la fonction (C'est d'ailleurs ce qui libère toutes les variables locales alloué sur la pile dans une fonction). Si tu ne touche pas au pointeur de pile (esp) alors tu peux t'en passer.

Ça sert surtout à adresser plus facilement les variables locales, mais comme on ne cherche pas spécialement à éviter du boulot au compilateur normalement c'est pas un problème de faire utiliser directement ESP. En général les compilateurs utilisent LEAVE parce que c'est plus court et dans mes tests c'est même plus rapide mais je ne suis pas sûr qu'ils reflètent la réalité.

Citation:

Envoyé par Lucien63

Le code de dapounet fonctionne. je l'ai testé.

OK donc ça doit être FreeBSD qui contrôle quelles pages ont le droit d'être exécutées. Je vérifierai avec gdb le jour où j'y comprendrai quelque chose.
07/07/2008, 16h12
ram-0000

Citation:

Envoyé par dapounet

OK donc ça doit être FreeBSD qui contrôle quelles pages ont le droit d'être exécutées. Je vérifierai avec gdb le jour où j'y comprendrai quelque chose.

Certains OS maintenant protège les pages mémoire de la pile et du tas de manière à ne plus les rendre exécutables afin de rendre la vie un peu plus dure à tous les programmes "malins" qui tentent de faire déborder la pile pour exécuter du code;).
07/07/2008, 18h46
chuko

Bonjour tout d'abord navrer d'avoir mi aussi longtemps pour revenir au poste que j'ai poste.Merci pour vos explication en effet j'avais en autre eu l'idée d'exécuter
mon fameux shellcode en simulant volontairement un stack overflow le problème étant que le programme tourne sous vista et leur fameuse protection pour empêcher de dépasser la pile me rende la vie dur merci pour l'exemple les exemple en tout cas par contre certain me dise que les pointeurs de fonction n'existe pas pourtant sur le net il existe des cours qui en parle.
en tous cas merci a vous pour l'aide apporte.
07/07/2008, 18h54
ram-0000

Citation:

Envoyé par chuko

le problème étant que le programme tourne sous vista et leur fameuse protection pour empêcher de dépasser la pile me rende la vie dur

La vie dure ? non la vie impossible oui:P
07/07/2008, 19h38
chuko

protoction contre les BOF

Je suis depuis un bout de temp sur l'aprentisage des bufer overflow ou plus precisement dans mon cas les stack overflow le probleme etant que je suis sous vista et que du a la protection aporter au system (pile non executable etc....) je ne peut faire mes test,d'ou ma question y a t'il une façon temporaire je l'entend dde desactiver des protection.Et deuxieme question que je me pose etant sous vista je n'ai pa essayer mes test de BOF sur xp et t 'il lui aussi proteger ?merci de vos reponses
07/07/2008, 21h40
nicolas.sitbon

Citation:

Envoyé par dapounet

Au fait INT 0x80 fonctionne sur un Linux 64 bits ou tu voulais dire qu'il faut le compiler en 32 bits et le faire tourner en "émulation" 32 bits ?

Non non, ça fonctionne bien en 64 bits.
08/07/2008, 09h46
Médinoc
Tu peux obtenir de la mémoire exécutable sous Windows assez facilement :
- soit une grosse allocation avec VirtualAlloc() + spécifier les droits
- soit HeapCreate() pour créer un tas exécutable, puis on peut faire plusieurs petites allocations avec HeapAlloc()...

Citation:

Envoyé par Lucien63

Citation:

Envoyé par Melem

Dans la convention d'appel du C une fonction doit commencer par push ebp, mov ebp, esp et se terminer par ret.

Ce n'est pas une obligation absolue, et dans le code de dapounet ce n'est pas indispensable.

C'est exact. En fait, j'ai même pas tout lu (faute de temps) mais d'habitude les plantages lors des appels viennent du non respect des conventions d'appel, alors j'ai comme quoi un peu anticipé mais en effet, le problème venait du fait que la mémoire n'était pas exécutable (en plus j'ai en effet oublié le pop ebp :)). J'ai quand même moi aussi fait quelques tests même si ce n'est plus d'actualité :lol: :

On veut écrire les fonctions suivantes dans le jeu d'instructions des processeurs (x86) 32 bits :
Code:

1 2 3 4 5 6 7 8 void f(void) { } int g(void) { return 1; }
Voici le programme :
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 #include <stdio.h> #define PUSH_EBP 0x55 #define MOV_EBP_ESP 0x8B, 0xEC #define MOV_EAX_IMM 0xB8 #define POP_EBP 0x5D #define RET 0xC3 unsigned char f1[] /* f */ = { RET }; unsigned char g1[] /* g */ = { MOV_EAX_IMM, 0x01, 0x00, 0x00, 0x00, RET }; typedef void VFV(void); typedef int IFV(void); int main() { VFV * f = (VFV *)f1; IFV * g = (IFV *)g1; f(); printf("%d\n", g()); return 0; }
On peut aussi utiliser la forme cannonique même si c'est complètement inutile ici car aucun paramètre n'est passé :
Code:

1 2 3 4 5 6 7 8 9 10 unsigned char f2[] /* f */ = { PUSH_EBP, MOV_EBP_ESP, POP_EBP, RET }; unsigned char g2[] /* g */ = { PUSH_EBP, MOV_EBP_ESP, MOV_EAX_IMM, 0x01, 0x00, 0x00, 0x00, POP_EBP, RET };