hoodbilen's warroom

아...정말로 이 문제 풀다가 pwnable과 손절할뻔 했다....

우선 main문은 별게 없다. 그냥 buf에 보고싶은 값을 10진수로 입력받으면 해당 값을 주소로 변환해서 출력해주고, src에 값을 입력해주면 print_message에서 출력해준다음 끝나는 문제이다.

print_message함수를 자세히 보면 dest에 데이터를 넘겨주고 출력하는데 아까 main문에서 본 read함수의 입력값보다 dest의 값이 훨씬 작음으로 bof가 일어난다. 해당 함수의 ret를 잘 덮어 system함수값을 입력해주면 끝날 것 같다......라고 생각했는데 libc의 sh를 사용하지 않고 풀어야했다.(문제 난이도 급상승...)

일단 sh를 적을 공간이 필요했는데, bss에 적기에는 여분의 공간이 너무 적었다....해서, 스택을 이용해 문제를 풀기로 했다.

스택에 "sh"를 넣고 슥 풀면 문제가 해결된다. (절대 쓰기 귀찮아서 안쓰는게 아님)

pwnstudy에서 PIE에 대해 배웠다.

PIE는 보호기법의 일종으로 PIE로 컴파일 할 시 해당 파일은 위치 독립 시행파일이 된다. 즉 실행할때마다 매핑되는 주소가 어디든지에 상관없지 실행되는 파일로, 바이너리의 주소를 랜덤화하여 바이너리의 특정 주소의 값을 수정하는 공격등에서 보호된다.

예제를 보면 pie라는 파일이 존재한다.

해당 파일이 pie인지 검사하면 

PIE가 결려있는 것을 확인할 수 있다. 

뿐만아니라 file 명령어를 이용해 해당 파일이 shared object인것으로 pie가 걸렸는지 판단할 수 있다,

해당 문제를 gdb로 열어보면 

우리가 항상보는 절대주소를 보여주는것이 아닌 상대주소를 공간상에 맵핑하여 실행하는 것을 볼 수 있다.

해당 실행파일에 break를 걸고 실행을 시킨 뒤 Virtual Memory MAP을 보면 

이런식으로 주소가 설정되는 것을 볼 수 있다. 참고로 PIE가 걸렸을 경우 보통 라이브러리 주소는 555555..로 많이 시작한다 하더라.

이제 해당 문제를 분석해보면

릭을 하고 offset을 계산해 base를 찾고 getshell주소 맞춰서 버퍼 채워주고 나가면 될 것 같다.

a인자 8개를 넣고 rsp를 보면 56byte 뒤에 우리가 릭할때 쓸만한 주소가 있다.

이런 식으로 작성해주고.

이제 base는 아까 Virtual Memory MAP에서 본 주소 555555554000에서 555555554b4d를 뺀 b4d를 offset으로 하고 구할 수 있다.

다음으로 getshell의 offset을 구해 공격할 주소를 gogo에 넣어주고 

버퍼가 112임으로 fsp 까지 채워주면 120개, 그 뒤에 gogo붙여서 파일을 종료하면

슥  해결 된다!