instruction de langue d'assembly pusha

Question

Je suis en train de faire un core dump dont la pile est corrompue. J'essaie de le démonter et trouvé ce qui suit plz aidez-moi à anaylyse .. il

(gdb) bt 
#0 0x55a63c98 in ??() 
#1 0x00000000 in ??() 

(gdb) disassemble 0x55a63c90 0x55a63ca8 

Dump of assembler code from 0x55a63c90 to 0x55a63ca8: 

0x55a63c90:  add %cl,%dh 

0x55a63c92:  cmpsb %es:(%edi),%ds:(%esi) 

0x55a63c93:  push %ebp 

0x55a63c94:  add %al,(%eax) 

0x55a63c96:  add %al,(%eax) 

**0x55a63c98:  pusha** 

0x55a63c99:  lret $0x9 

0x55a63c9c:  subb $0x56,0xd005598(%ebp) 

0x55a63ca3:  push %ebp 

0x55a63ca4:  jo  0x55a63cc5 

0x55a63ca6:  sahf 

0x55a63ca7:  push %ebp 

End of assembler dump. 
(gdb) q 

Peut cette instruction de Pusha peut conduire à une décharge de base?

Answer 1

Pas ^*, tout pusha n'est de pousser tous les registres à usage général à la pile, y compris le pointeur de la pile! Qu'est-ce qui cause la décharge du noyau est l'instruction après le pusha, lret, qui est un long retour avec stack pop. L'adresse de retour est la valeur la plus récente transmise à la pile, qui dans ce cas sera tout ce qui était dans esi: edi (car ce sont les dernières valeurs à être poussées par l'instruction pusha), et cela pointera probablement vers un endroit aléatoire.

* Sauf si vous manquez d'espace de pile.

Answer 2

pusha ne peut conduire à un vidage de la mémoire principale que si un débordement de pile se produit à ce point. Cette instruction pousse toutes les valeurs des registres sur la pile et cela pourrait conduire à un débordement. Cependant, la racine du problème est probablement ailleurs - la pile d'appels est probablement trop profonde à ce moment-là et pusha cause justement de telles conséquences parce qu'elle est exécutée dans de telles conditions.

Answer 3

vérifier si vous voyez aligné Code désassembler:

x/i $eip 

montrent également les valeurs des registres:

i r 

Answer 4

Absolument. PUSHA suivi par RET n'est jamais correct, l'adresse de retour sera indésirable. Voir ADD AL, [EAX] dans votre démontage est un autre don mort, c'est le démontage pour 0.

En d'autres termes: vous êtes en train de désassembler des données, pas de code. Votre programme a été bombardé parce qu'il exécutait des données. La façon classique de procéder est de corrompre un cadre de pile avec un dépassement de tampon. Lorsque la fonction retourne, elle renvoie une adresse de retour invalide de la pile corrompue et saute dans jamais jamais atterrir. Ne pas avoir une faute seg est très malchanceux.

Difficile à déboguer, la trace de la pile est rejetée. Vous devrez définir un point d'arrêt à la dernière bonne adresse de code connue et démarrer un pas simple. La dernière bonne fonction que vous avez prise juste avant que les bombes ne soient en général le fauteur de troubles.