pusha 어셈블리 언어 명령어

Question

스택이 손상된 코어 덤프가 발생했습니다. 나는 그것을 분해 시도하고있는 다음 PLZ

(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 

이 pusha 명령이 덤프 핵심으로 이어질 수 있습니다 .. 내가 그것을 anaylyse하는 데 도움이?

Answer 1

없음 ^*이 모든 pusha 스택에 모든 범용 레지스터를 밀어 것입니다 않습니다, 스택 포인터 포함! 코어 덤프의 원인은 pusha, lret 이후의 명령입니다. 이는 스택 팝이있는 긴 리턴입니다. 반환 주소는 스택에 푸시 된 가장 최근 값입니다.이 경우 esi : edi (pusha 명령에 의해 마지막으로 푸시 된 값이기 때문에)에있는 값이되며, 이는 임의의 위치를 ​​가리킬 가능성이 높습니다.

* 스택 공간이 부족하지 않은 경우.

Answer 2

pusha은 스택 오버 플로우가 발생하는 경우에만 코어 덤프가 발생할 수 있습니다. 이 명령은 모든 레지스터 값을 스택에 푸시하고 오버 플로우로 이어질 수 있습니다. 그러나 문제의 근원은 다른 곳에있을 가능성이 높습니다. 호출 스택이 그 시점에서 너무 깊어서 pusha이 그러한 조건에서 실행되기 때문에 이러한 결과가 발생하는 경우가 대부분입니다.

Answer 3

체크하면 정렬을 참조하면 분해 코드 :

x/i $eip 

는 또한 레지스터 값을 보여

i r 

Answer 4

물론입니다. PUSHA 다음에 RET이 올바르지 않으면 반환 주소는 쓸모 없게됩니다. ADD AL을 보면 해체에서 [EAX]가 또 다시 죽습니다. 0의 해체입니다.

즉 : 코드가 아니라 데이터를 분해하고 있습니다. 데이터를 실행 중이기 때문에 프로그램이 폭격을당했습니다. 고전적인 방법은 버퍼 오버 플로우가있는 스택 프레임을 손상시키는 것입니다. 함수가 반환되면 손상된 스택에서 잘못된 반환 주소가 튀어 나오고 절대로 땅에 떨어지지 않게됩니다. seg 오류가 발생하지 않는 것은 매우 재수가 없습니다.

디버그하기 어렵지만 스택 추적은 쓸모 없습니다. 마지막으로 알려진 올바른 코드 주소에 중단 점을 설정하고 단일 스테핑을 시작해야합니다. 폭탄이 터지기 직전에 마지막으로 성공한 기능은 일반적으로 문제 발생기입니다.