Linux Core Dump Analysis - 4 (분석실습_a)

덤프 분석에서는 기본적으로 CORE 메모리 덤프 파일과 . 해당 덤프를 발생 시킨 실행 프로그램이 필요하다. 

sample_core.zip

8.08MB

아래내용은  App2D를 분석한 내용이다. 

 

 

gdb -c ./core -se ./App2D 

 

 

gdb 로 core 덤프 파일 열면 위 그림과 같이 procA() 함수에서 크래쉬가 발생 한 걸 확인 할 수 있다. 

 

 

info thread                           - 덤프 발생 시점에 수행중인모든 스레드를 보여준다. 

 

현재 6개의 스레드가 돌고 있고, 1,6번을 제외하고 4개의 스레드는 현재 중지 상태에 있는걸 확인 할 수 있다. 

 

 

thread 1        -  1번 스레드 선택 

bt                -  현재 스레드의 콜스택 

 

문제가 된 1번 스레드로 context를 맞춰 놓고 콜 스택을 보면 위 그림과 같다. 

 

x/i <address>                        - x 메모리 데이터 View, i<명령> 형식

x/i 0x0000000000400500

 

크래쉬 난 지점의 명령어를 보면  mov    DWORD PTR [rax],0x1

즉 rax 메모리지점에 0x1를 Write 하는 명령어 이다. 

info r $rax                 - info r 는 레지스터의 정보. 

rax 레지스터의 값을 보면 0x0 임을 확인 할수 있고, 즉 0번지에 0x1를 쓰려고 하다가 크래쉬가 발생 하였다. 

 

 

pdis procA            - pdis 는 디스어셈블 

 

procA 함수의 전체 코드를 디스어셈블 해 보면 위와 같다.

rbp는 베이스 레지스터로 위에 보면 mov rbp, rsp 로 함수 시작시 rsp의 값을 가지고 있는걸 확인 할 수 있다. 

위 그림은 스택 프레임 구성이 끝나후의 스택 메모리의 모습니다. 

위 어셈블리코드로 확인하면 mov rbp, rsp 까지 의 내용. 스택메모리는 높은 메모리에서 낮은 메모리쪽으로 수행 된다. 

여기서 [rbp-0x8]은 함수를 호출시 넘겨 온 첫 번째 인자이다. (호출 하는 코드에서 인자를 전달 하였다면)

 

하지만 여기 문제가 된 코드를 보면 rax는 위에  mov rax,QWORD PTR [rbp-0x8] 에서 가져온걸 확인 할 수 있고, 그위에 QWORD PTR [rbp-0x8], 0x0 으로 해당 스택에 0을 저장 하고 있다. (해당 덤프는 연습을 하기위에 일부러 CRASH  발생을 내기위한 예제 코드), 즉 보통 인자로 전달되는 영역에 0을 들어가므로서 크래쉬를 유발 시켰다.