+- N-PN White-Hat Project (https://dev.n-pn.fr/forum)
+-- Forum : Programmation (https://dev.n-pn.fr/forum/forumdisplay.php?fid=72)
+--- Forum : Langages compilés (https://dev.n-pn.fr/forum/forumdisplay.php?fid=25)
+--- Sujet : [C / ASM inline] stack nostdlib (/showthread.php?tid=2492)
[C / ASM inline] stack nostdlib - ark - 11-12-2012
Plop
Je bosse actuellement sur un projet ou j'essaye de compiler sans la libc, parce que j'aimerais pouvoir étudier l’état de la stack a l’état "naturel".
Pour cela, j'ai une fais une fonction _start(), qui est donc l'entry point de mon programme. J'ai coder rapidement une lib utile pour afficher des données (cf pièce jointe)
Bref, quoiqu'il en soit, sur un programme en assembleur compilé avec nasm et linké avec ld, j'ai pas de soucis, je fais un pop au début de mon programme, je récupère bien mon argc.
Mon soucis vient du fait que lorsque je compile mon programme en C avec la commande gcc -nostdlib *.c, lorsque je l’exécute, quand je fais un pop, la valeur obtenu est nulle. Oo
En revanche, il semblerais bien que mes vecteurs auxiliaires de ELF soit bien sur la stack (bien que je n'ai pas vérifié que ce soit vraiment ça pour l'instant).
J'ai donc l'impression que ma stack n'est pas initialisée... J'ai chercher pas mal sur notre ami google, mais il y a pas grands chose a ce sujet malheureusement...
Du coup, si vous avez des idées, de ce qui fait que la stack est init sur un programme en assembleur brute et pas en C, je suis preneur ! ^^
Sinon, si vous avez une idée de ou je peux trouver mes arguments, je suis preneur aussi... parce que ça me semble bizarre... x)
L’idée au final serait d’être capable de se passer de la libc et d'avoir une stack initialisée quand même.
Le code source est dans le tar en pièce jointe, et comme je suis gentil j'ai même fait un makefile \o/
EDIT: J'ai oublier de préciser que je bosse sur du 64bits. J'ai également tester en 32 bits, même soucis. J'ai rajouter les sources en 32 bits au passage.
RE: [C / ASM inline] stack nostdlib - gruik - 11-12-2012
c'est __libc_start_main qui se charge d'initialiser tout le bouzin, arguments compris
à partir du moment où tu as void _start (void) gcc génère automatiquement un prologue (et un épilogue) push rbp/mov rsp,rbp
du coup c'est vrai que quand _start prend la main (jeu de mot tordant) on a directement argc dans [rsp] :
Code BASH :
gruik@leobotes:~/code$ echo "void main (int argc, char **argv) {}" | gcc -x c -o pouet -
gruik@leobotes:~/code$ gdb -q ./pouet
Reading symbols from ~/code/pouet...(no debugging symbols found)...done.
gdb$ b _start
Breakpoint 1 at 0x4003d0
gdb$ r
Breakpoint 1, 0x00000000004003d0 in _start ()
gdb$ x/x $rsp
0x7fffffffe140: 0x00000001
gdb$ r pouet gruik coincoin
Breakpoint 1, 0x00000000004003d0 in _start ()
gdb$ x/x $rsp
0x7fffffffe120: 0x00000004
sauf qu'en l'occurence _start() commence nécéssairement par un prologue qui décale l'adresse de argc typiquement
le fait de déclarer long argc également fait que gcc va sub de la place sur la stack, on en sort pas :p
32 ou 64bits ça ne change rien à l'affaire là, ce qu'il te faudrait c'est un __attribute__((naked)) qui... ne fonctionne pas sur x86/x86_64 ;p
la seule solution que je vois c'est donc de récuperer [ebp+x] dans ton long argc déclaré, truc moyennement folichon style :
Code C :
asm ("mov 0x8(%%rbp),%0\n\t" : "=r"(argc));
évidement ça génère un code un peu dégueu mais il y a peut-être moyen de tourner le truc autrement, à voir
Code BASH :
gruik@leobotes:~/code$ ./prog
argc = 1
gruik@leobotes:~/code$ ./prog pouet
argc = 2
gruik@leobotes:~/code$ ./prog pouet coincoin
argc = 3
gruik@leobotes:~/code$ ./prog pouet coincoin gruik bouzin bla prout
argc = 7
j'ai pas investigué sur **argv en revanche
edit: au temps pour moi, *argv est juste derrière (terminé par un null sur 64b) suivi de *envp
Code BASH :
gruik@leobotes:~/code$ gdb -q ./prog
Reading symbols from ~/code/prog...(no debugging symbols found)...done.
gdb$ b _start
Breakpoint 1 at 0x400148
gdb$ r pouet gruik coincoin
Breakpoint 1, 0x0000000000400148 in _start ()
gdb$ x/8gx $rbp
0x7fffffffe118: 0x0000000000000000 0x0000000000000004
0x7fffffffe128: 0x00007fffffffe403 0x00007fffffffe438
0x7fffffffe138: 0x00007fffffffe43e 0x00007fffffffe444
0x7fffffffe148: 0x0000000000000000 0x00007fffffffe44d
gdb$ x/s 0x00007fffffffe438
0x7fffffffe438: "pouet"
gdb$ x/s 0x00007fffffffe43e
0x7fffffffe43e: "gruik"
gdb$ x/s 0x00007fffffffe44d
0x7fffffffe44d: "SSH_AGENT_PID=1337"
f*ckin {gdb,64b}
RE: [C / ASM inline] stack nostdlib - ark - 11-12-2012
Merci beaucoup pour ta réponse
Il me sembles que je m'en étais rendu compte du prologue/épilogue il y a une semaine en plus... C'est pratique de voir un point de vues externe !
Y a t'il moyen de décaler rbp? J'ai essayer de faire:
Code C :
asm ("lea 0x8(%rbp),%rbp\n\t");Mais ça ne marche pas... Ça ne devrait pas de poser de problème de le décaler puisque j'exit() avant qu'il arrive a l’épilogue normalement.
Pour argv, je m'en doutais, il n'y avait pas de raison que ça change, merci quand même d'avoir check