[System_Hacking] stage5_SYSV디버깅

한학기동안 많은 문제를 풀었는데 (그때 써둔 write-up보면 가관이다ㅋㅋ) 당시에는 gdb로 하는 일이라고는 plt, got주소 찾기나 checksec, elfheader정도가 전부였던 것 같다. (심지어 스택을 보는 방법도 제대로 몰랐으니 말 다했음) 

 

암튼 디버깅이라는 gdb의 근본적인 기능을 통으로 놓치고 있던 느낌이라 종강하면 디버깅하는 방법부터 공부해야지..생각하다가 어셈블리 공부에 빠져버려서 결국 종강 1주일이 지나서야 디버깅 공부중이다...ㅎ (근데 어차피 어셈블리를 잘 봐야 디버깅도 쉽다.)

 

그런데 마침 드림핵 코스에서 간단한 코드로 디버깅하는게 있어서 관찰할 겸 데려와봤다.

 

#define ull unsigned long long
ull callee(ull a1, int a2, int a3, int a4, int a5, int a6, int a7) {
  ull ret = a1 + a2 + a3 + a4 + a5 + a6 + a7;
  return ret;
}
void caller() { callee(123456789123456789, 2, 3, 4, 5, 6, 7); }
int main() { caller(); }

 

뭐 이런 간단한 코드인데 인자를 7개나 전달하는 게 분명 흔한 광경은 아닌 것 같다.

 

(컴파일 : gcc -fno-asynchronous-unwind-tables -masm=intel -fno-omit-frame-pointer -o callee callee.c -fno-pic -O0)

 

 

일단 처음 실행시키면 rip가 entry point에서 시작하는 것을 알 수 있다.

 

 

(readelf해보면 사실 entry point랑 좀 다른 것 같긴 한데...🤔) 

 

 

암튼 쭉쭉 진행시키다가 caller호출에서 si해주자. caller에서 callee를 호출해야 하기 때문에 callee호출 전까지 레지스터에 인자들을 모두 세팅할 것이다.

 

 

callee의 프롤로그 직후 스택을 보면,

 

0024에 있는건 main의 스택 프레임의 ret인것을 알 수 있다. 그리고 그 위에 0x0은 main의 프롤로그 때 push rbp해서 쌓인 거다. 즉, main의 스택 프레임의 sfp이다. (내용물이 0인거 보면 __libc_main_start의 bp는 0x0인가..?) 

 

암튼 그 위에 쌓인(0008위치)건 caller를 call함과 동시에 돌아갈 주소 (여기서는 main의 + 18)를 써둔 거다. caller역시 매개변수가 별도로 없기 때문에 바로 ret이 쌓인 것을 관찰 가능하다.

 

그리고 그 위에 쌓인 값은 push rbp 즉 main의 bp주소(== caller의 sfp)인데,  잘 보면 아까 main의 sfp주소가 그대로 쌓인 것을 볼 수 있다.

 

 

 

그리고 여기서 왜 push 0x7을 했냐면... 인자가 7개라서 그렇다. 7번째 인자부터는 스택으로 전달되므로 스택에 push한 것.몇 번째 인자인지를 셀 때는 왼쪽부터 세지만 인자 처리는 32비트에서도 그렇고 오른쪽부터인 것 같다. 

 

 

매개변수 세팅이 다 됐으니 이제 callee를 호출한다. 진행흐름을 callee안으로 해서 들어가보자.

 

 

callee를 호출하자마자 스택에 ret주소가 쌓인 것을 볼 수 있다. 

 

 

push rbp. 이것도 역시 caller의 sfp주소와 같다.

 

그리고 callee는 아무 지역변수도 만들지 않으므로...

 

 

rsp == rbp인것을 확인 가능하다.

 

아 그리고 당연한 소리긴 한데 함수의 반환값을 저장하는 건 라이브러리 함수가 아니라도 마찬가지다.

 

 

잘 저장되어있다.