우선 코드의 내용을 확인하자 egghunter에 이어 buffer hunter라는 기능이 추가되었다. buffer hunter의 경우에는 입buffer에 쉘코드를 입력하여 쉘을 유도하지 못하도록 추가된 기능이며 memset(buffer, 0, 40)으로 buffer의 내용물을 비워 쉘코드를 입력하여도 무용지물이 되도록 하였다. 이에 해결방법으로는 2가지를 찾을 수 있었다. 1. RET 바로 뒷부분의 주소에 shellcode를 기록2. argv[2] 인자값으로 쉘코드를 입력하여 해당 위치로 이동. 2번 방법을 선택하여 문제를 풀어보도록 하자. 우선 argv[2]의 주소를 알기위해 코드를 복사하여 argv[2]의 주소를 출력하도록 설정하였다. argv[2]의 주소는 0xbffffc71이라는 것을 알 수 있었..
해당 문제의 소스코드를 읽어보도록 하자. 코드의 내용을 간단하게 살펴보면 다음과 같다. 1. environ( 환경변수값들) 을 전부 0으로 초기화한다. 2. argv[1][47]에는 '\xbf'가 들어가야 한다. buffer에 주어진 사이즈는 40바이트로 환경변수에 저장하지 않고 버퍼에 쉘코드를 덮어씌우는 방식으로 공격을 수행해야 할 것으로 예상된다. gdb로 분석을 하기 위해서 복사를 한 뒤에 분석하도록 하겠다. 복사를 할 때는 메모리 주소에 영향을 끼치는 것을 줄이기 위해 프로그램 이름의 길이를 똑같이 해준다. 전체적은 코드를 파악해보도록 하자. 우선 스택의 사이즈를 확인해보면 2c(44) 바이트를 확보한 것을 알 수 있다. 즉, RET의 주소는 buffer의 시작점으로부터 48바이트 떨어진 곳에 있..
3탄의 코드를 살펴보도록 하자. gets로 직접 입력을 받는다. 하지만 문자길이에 대해 체크하지 않기때문에 여기서 버퍼 오버프롤우가 일어날 수 있게된다. 변수의 사이즈를 고려하여 직접 쉘코드를 덮어씌우는건 힘들것으로 추측되어 환경변수에 쉘코드를 저장하고 RET의 값을 쉘코드의 주소로 덮어씌우는 것을 목표로 한다. 스택의 사이즈가 16인 것을 보면 더미가 존재하지 않는 것을 알 수 있다. 따라서 buf[16]+SFP[4]+RET 로 이루어진 것을 추측할 수 있다. 환경변수에 등록한 쉘코드에 대한 주소를 확인해보자. 0xbffffee7인 것을 확인했으므로 RET의 위치에 해당 값을 덮어씌워주면 된다. 공격에 성공하여 다음단계로 넘어갈 수 있게되었다.