gdb 활용 코드 분석

(1) 분석할 코드

C언어 코드

코드를 짧게 설명해보면 function에서는 buffer1이 15크기를 가지고 buffer2가 10크기를 가지게 만들어주고 있고, 메인에서는 function에 매개변수로 1, 2, 3을 넣어주고 있다.

(2) 분석 내용

gcc로 32비트 컴파일 해주고  gdb를 실행시켰다.

 

[기타 배경지식]

어셈블리어 sub에 esp가 인자로 오면 공간을 확보해주는 것이고, add에 esp가 인자로 오면 공간을 반환해주는 것이다.

프롤로그와 에필로그가 있는데,

프롤로그는 push ebp, move ebp,esp 이고,

에필로그는 leave, ret 이다.

function을 디스어셈블해줬더니 위와 같이 나왔다. 위에 2줄이 프롤로그 부분이고,

코드 부분 맨 밑 2줄이 에필로그인 걸 알수 있다.

프롤로그 바로 밑 코드에서 sub로 stack에 40byte 공간을 확보하고 있다.

40byte인 이유는 stack이 word단위 4byte씩이기 때문에 buffer1[15], buffer2[10]에서

각각 16byte와 12byte가 할당 돼서 28byte만 필요하다. 그런데 gcc 2.96 이후 버전에서는

9byte 이상의 버퍼일 때 4word(16byte) 단위로 할당하고 8byte dummy 값을 더해준 만큼의 크기가 확장된다.

그래서 총 40byte의 stack이 확장되는 것이라고 한다.

 

main을 디스어셈블했더니 위와 같이 나왔다.

main에서도 코드 부분 5~6번째 줄이 프롤로그, 아래쪽에서 에필로그를 발견할 수 있다. 

코드의 7~8번째 줄에서 sub로 4byte씩 공간을 확보하고 바로 밑 3줄에서 push로 3, 2, 1을 넣어주고 있다.

3, 2, 1 순서로 넣어주는 이유는 스택에서는 마지막에 넣은 걸 제일 먼저 꺼내므로 1, 2, 3 순서로 꺼내기 

취함으로 추측할 수 있다.

call로 function 함수를 실행하고 add로 16byte를 반환하고 있다. 

일단 메인에 breakpoint를 걸어줬다.

r 명령어로 실행시켰더니 나오는 화면이다.

현재 eip는 0x804846e로 breakpoint가 걸려있는 부분이 다음에 실행될 예정이다. main에 breakpoint를 걸어줬는데 disas로 main했을 때 나오는 프롤로그 부분 뒤쪽의 코드 부분이 breakpoint로 설정됐다.

몇번 더 si로 코드를 실행시켜서 function함수로 가보자.

위의 두 사진 다 같은 시점의 si 명령어를 실행했을 때 캡처인데 지금 주목할 부분이 stack이다.

stack을 확인해보면 0x3, 0x2, 0x1이 차례로 쌓인 것을 확인할 수 있다. 아직 function함수에 진입하지는 않았고,

한 번 더 si를 해보자.

si로 3~4번 정도 더 실행한 결과 function 함수 안으로 들어왔다.

function함수의 프롤로그 부분이 eip로 바뀐 것을 확인할 수 있고, esp를 확인하면 다시 돌아갈 주소값이 0x804847f 즉, add로 공간을 반환하는 부분인데 disas main 했을 때의 결과를 다시 참고해보면 이 코드가 바로 function을 call했을 때의 바로 다음 실행 순서라는 것을 알 수 있다.

이제 si 여러 번을 통해 다시 main으로 가볼 것이다.

main함수로 다시 돌아왔다. stack 부분을 살펴보면 esp였던 0x804847f 가 스택에서 없어졌다는 걸 확인할 수 있다. 

eip를 살펴보면 0x804847f를 발견할 수 있다.

이대로 쭉 si로 끝까지 실행하면 main의 에필로그 부분이 실행될 것을 예측할 수 있다. 이렇게 분석을 마치도록 하겠다.

 

분석을 하면서 gui 디버거의 소중함을 깨달을 수 있는 시간이었다... CLI에 익숙하지 않은 세대라 그런지 CLI가 어색하지만 점차 익숙해지길 바라면서 분석을 마치겠다.