Reverse Engineering, padding bizarre

Salut, je fais un CTF et je dois jump à un fonction qui est à l’adresse mémoire 0x80485e6

le code est le suivant:

void vuln(){
  char buf[64];
  gets(buf);

  printf("Woah, were jumping to 0x%x !\n", get_return_address());
}

Get return adress affiche juste EIP. Dans ma tête il y a 64 bytes dans le buffer, aucun variable local (sauf le buffer) donc comme la stack est comme ceci :les variables local, ebp sauvgardé et eip, il suffit de faire 64 + 4 (4 étant la taille de ebp sauvgardé) pour commencer à écrire sur EIP, mais j’ai du écrire 76 byte avant de commencer à écrire sur EIP.

Pourquoi ?

Salut, tu peux envoyer un code un peu plus complet ? À première vue (et d’après ce site), je dirais que tu as raison, mais j’avoue que ça me laisse un peu perplexe.

Salut d3m0t3p,

76 bytes ça fait 64 + 4 + 4 + 4.

Je pense que les 8 bytes de padding restant servent à stocker les paramètres d’appel à printf qui sont au nombre de deux.

En effet, sur les compilateurs récents (ou du moins les compilateurs de l’époque) c’était plus pratique de faire :

mov [esp], "Woah, were jumping to 0x%x !\n"
mov [esp+4], get_return_address()

Ça permet d’avoir un pointeur esp constant dans ta fonction courante.

Or, si tu fais :

push get_return_address()
push "Woah, were jumping to 0x%x !\n"

C’est tout aussi juste, mais ça « décale » esp pour les calculs futurs et ça t’oblige à faire un : add esp, 8 après l’appel de la fonction pour nettoyer la stack.

Le fait est qu’ici tu n’as que des fonctions dont la convention d’appel est __cdecl où la fonction appelante se charge de nettoyer la pile (l’intérêt d’une telle approche est de pouvoir appeler les fonctions à nombre variables d’arguments, comme printf).

Ainsi si mes calculs sont exacts, tu as :

64 + taille ebp (4) + taille argument 1 printf/gets (4) + taille argument 2 printf(4) = 76 octets avant de réécrire eip.

Au final je t’invite à vérifier le désassemblage de ta fonction pour en avoir le cœur net.

À+ !