여행 다녀온 후 오랜만에 푼 문제이다.

문제는 ascii_easy !

문제 이름대로 쉬운? (다른문제에 비해)




(ascii_easy)



문제내용은 이렇다.



(문제 내용)



일단 접속하여 소스코드부터 확인하였다.




(소스코드)



소스코드를 보니 아스키문자인지 체크하는 함수가 들어있다.
인자로 아스키문자가 아니면 쫓겨난다.

그리고 취약한 함수를 대놓고 vuln 이름으로 만들어놓았다. 
이 부분을 버퍼 오버플로우하는 거구만! (다행히 스택카나리가 적용되어있지 않았다.)

그리고 주목되는? 부분이 있었다.



(중요부분)



???
libc-2.15.so 파일을 가져다가 통째로 메모리에 쿵 올린다.

mmap 함수를 gdb로 동작확인해보겠다.



(mmap 함수 인자)



인자를 보니 파일 내용이 덤프될 주소 0x5555e000 이 보인다.

함수를 실행하여 덤프된 주소를 보자!



(덤프된 내용)



처음에는 데이터가 매핑이 이상하게 되었나 싶었다. (여기서 조금 헤맸다.)
(위의 캡쳐 화면은 내가 so 파일을 헥스로 수정하여 그대로 저장시킨 값이다. 그래서 위처럼 나온것)

아래 내용은 hex모드로 so 파일을 연 것이다.



(so 파일)



여기서 30303030... 이 뭘까 싶었는데 내가 헥스로 수정하고 다시 제대로 저장해야하는데 그대로 저장을 시켜서 위 화면대로 저장이 된것이다... 그렇기 때문에 아래와 같이

00000000: ~~~~ 헥스모드에 나와있는 텍스트가 그대로 메모리에 올라간 것이다...


(헥스모드 상황)



그렇군! 여기서 파일의 데이터가 떡하니 올라가는 것을 확인했으니 그 다음부터는 고민 없이
이 파일에 Nop 코드와 쉘코드를 넣어주어 bof 시킨 후 ret 주소에 해당 쉘코드 주소를 넣어주면 된다.

사실 여기서 Nop 코드 없이 정확히 쉘코드 주소를 맞출 수 있기 때문에 필요없긴 하지만
그냥 넣었다.

테스트!
놉코드 100개와 A 10개를 넣어보았다.




(테스트!)



그 후 메모리 상황!



(메모리 모습)



그렇다면 내가 만들수 있는 아스키문자중 가장 작은 값이
55562121 -> UV!! 

이다. 그렇기에 해당 주소까지 놉이 몇개 필요한지 계산해본다.




(Nop 개수)



16진수로 4121 
10진수로 16673개가 필요하다.

놉코드를 4개 더 추가시켜서 ( 놉코드 안에 안착시키기 위해)

그 뒤에 쉘코드를 이어붙여준다.



(so 파일 구성)



이렇게 하고 UV!! (55562121) 주소로 가보면



(쉘코드)



놉코드와 쉘코드를 만날 수 있다.

이제 원본 파일에 링크를 걸어서 실행할 것이다.(원본파일에 setuid가 걸려있기 때문에!)

취약 함수를 오버플로우 시켜 (더미 32개) ret 주소에 UV!! 를 넣어준다. (엔디안에 맞춰서)



(공격 성공!)



쉘을 획득하였다.

의도된 풀이를 보니 execve 함수를 이용하여 풀게 되어있다. execve 함수 주소를 보니 우리가 구성할 수 있는 아스키코드 주소로 되어있는 걸 확인 할 수 있다.



(의도된 방법)

'WarGame > 500 Project' 카테고리의 다른 글

(59/500) pwnable.kr - dragon  (0) 2017.08.17
(58/500) pwnable.kr - fsb  (0) 2017.08.12
(56/500) pwnable.kr - asm  (0) 2017.07.14
(55/500) pwnable.kr - uaf  (0) 2017.07.12
(54/500) pwnable.kr - cmd1  (0) 2017.07.12



bof 문제이다!
bof 원정대의 실력을 꺼낼때가 됬다!

귀여운 너구리 클릭


(bof 문제)


문제화면이다.


(문제 화면)



remote bof? 
nc 로 접속하여 풀게 되어있다.
일단 취약한 프로그램을 한번 확인해보자.

소스 확인!


(소스코드)



소스코드를 보니 func 함수의 인자를 덮어 쓰면 될것 같다.

메모리에서 한번더 확인해보기 위하여 gdb에서 확인!



(메모리 상태)



입력으로 A를 여러개 주었을 때이다.
보면 위에 414141~~ 이 보이고 아래에 func 인자로 넘겨진 deadbeef가 보인다.
여기까지 덮어쓰면 되므로 일단 A 52개를 넣어보자!



(A 52개)


A 52개를 넣으니 딱 deadbeef 전까지 A가 채워졌다. 마지막은 Null 때문에 00이 덮여저있다.
여기에 이제 원하는 코드 를 넣으면 되니 이제 연결을 해보자!



(nc 연결)


전 문제 풀던 쉘에서 localhost로 바로 연결했다.

음! 이걸로 되겠군!

이제 표준입력으로 넘겨서 nc 로컬 연결할 것이다.



(공격!)


계획한대로 A 52개와 0xcafebabe 를 넣어준다. (엔디안 고려해서 뒤집어서 넣어준다.)



(성공!)



bof의 uid를 얻은 쉘을 획득했다.!




(문제 해결!)

'WarGame > 500 Project' 카테고리의 다른 글

(47/500) - pwnable.kr - passcode  (0) 2017.07.06
(46/500) - pwnable.kr - flag  (0) 2017.07.05
(44/500) - pwnable.kr - collision  (0) 2017.07.05
(43/500) - pwnable.kr - fd  (0) 2017.07.05
(42/500) - Lena's Tutorial 01  (0) 2017.07.05


BOF 원정대의 마지막 몬스터 death_knight를 잡아보자.!

* death_knight 소스


(death_knight.c)


소스코드를 보니 마지막 문제는 Remote BOF 문제였다.
원격에서 공격하는 방법인데
방법은 크게 두가지가 있다. 바인드쉘을 이용하거나, 리버스쉘을 이용하거나.

나의 계획은 바인드쉘을 이용할 것이었다.
일단 netstat 명령어로 소스코드대로 6666 포트가 열려있는지 확인해본다.


(열린 포트 확인)


파일 권한을 확인해보니 역시 setuid가 설정되어있고 eath_knight가 주인이다.



(setuid)



바인드 쉘을 구해서 테스트해보았다.
1337 포트를 오픈하는 코드이다.



(바인드쉘 테스트)



실행!


(1337 오픈!)



하지만 이 방법에 문제가 있었다.
(아직 이 문제에 대한 의문은 해결되지 않았다...)
(바로 bof 공격 코드까지 파이썬으로 만든후 공격을 성공시켜서 1337 포트가 열리는 것까지 확인했다.



(포트 오픈)



그런데 이상한점이 있었다.
여기서 '아! 이제 열렸으니 접속을 해볼까?' 하고 접속을 시도하면 짤린다...

와이어샤크로 분석해보니 ack 요청을 보내자마자 서버에서 fin 을 날려 종료시킨다...
이유는 모르겠다. 방화벽때문인가??...
계속 이것저것 시도했지만 여전히 접속이 안되었다...

그리하여 방법을 바꾸어 리버스 쉘을 이용하기로 했다.
내가 포트를 오픈하고 서버에서 나에게 접속을 시도하게 하는 것이다.
만약 이때 짤리면 내 방화벽을 내리면 되기때문에 이 방법으로 전환했다.

shell 코드는 인터넷에서 구했다. 내 호스트 IP 주소와 5555 포트번호로 접속을 시도하는 리버스 쉘코드이다.
이 코드를 이용하여 익스플로잇을 만든 후 실행했다.



(exploit 코드)




(공격 모습)



이 때 나는 nc를 이용하여 5555 포트를 열고 기다리고 있었는데 연결이 성립되면서 쉘을 획득 할 수 있었다.



(공격 성공)



쉘 획득!

이로서.....!

BOF 원정대의 모든 문제를 클리어할 수 있었다.



(all clear!)


'WarGame > 500 Project' 카테고리의 다른 글

(38/500) Suninatas - Binary(10)  (0) 2017.06.27
(37/500) Suninatas - Binary(9)  (0) 2017.06.27
(35/500) Lord of the BOF - xavius  (0) 2017.06.25
(34/500) Lord of the BOF - nightmare  (0) 2017.06.23
(33/500) Lord of the BOF - succubus  (0) 2017.06.23


BOF 원정대의 giant를 잡아보자!

* 소스코드


(giant.c)


중간에 복잡해보이는 코드가 있는데 친절하게 주석으로 설명이 되어있다.
ret주소에 execve 함수 주소가 들어가있는지 체크하기 위한 부분이다. 그렇기에 ret 주소에 execve를 넣어 execve 함수를 사용해서 문제를 해결하라는 의도같다.

그렇다면 execve를 어떻게 써야하나 구성인자를 살펴보자!



(execve 함수)



execve 함수의 인자
1. 파일이름(실행할파일)
2. 인자 주소(파일이름 문자열의 주소)
3. Null 문자열

예를 들기위해 C언어로 표현하여 실행해 보겠다



(execve c 코드)



(실행화면)



위와 같이 인자를 넘겨주니 execve 함수가 잘 실행되었다.

자 이제 이대로 인자를 만들어주어야한다.



(ret 주소)



ret 주소는 0x400a9d48 (execve 함수 주소) 를 넣었다.
이제 이 뒤에는 더미(4바이트) 를 넣은 후 그 뒤부터 인자가 들어가게된다.

execve 함수로 실행할 파일은 /bin/sh이다. 이 문자열을 직접 써주어도 되지만 그렇게 되면 문자열 주소를 넘겨주는 두번째 인자를 구성할 때 어려워진다. 왜냐하면 두번째 인자는 포인터 배열이기 때문에 주소와 널문자(4바이트)로 이루어져야하기 때문이다.

그렇기에 이미 로딩된 라이브러리에서 /bin/sh 문자열을 찾아 사용할 것이다.
system 함수 근처에 /bin/sh 문자열이 존재한다는 것을 알고 있기에 간단히 c코드를 만들어 /bin/sh 문자열 위치를 찾아낼 것이다.




(/bin/sh 주소찾기)



(/bin/sh 주소)



직접 gdb를 열어 해당 주소를 검색해보자.



(/bin/sh)



해당 주소에 /bin/sh 문자열이 들어있는 것을 확인 했다.

이제 첫번째 인자로 우리가 찾은 주소를 넣을 것이다.
두번째 인자를 구성해야한다. 일단 지금까지 만든 것을 토대로 메모리를 확인해보자.

A*44 + execve함수주소 + A*4(더미) + "/bin/sh주소" + "/bin/sh주소가 적힌 포인터배열 주소" + NULL

포인터배열을 만들계획이다. 일단 포인터배열 주소를 C*4 로 대체하고 메모리를 확인해보자!



(gdb 실행)


두번째 인자를 만들어줄 위치를 살펴보니 적당한 위치가 나왔다.



(4바이트 NULL)


포인터배열이기 때문에 주소뒤에 Null(4바이트)가 나와야하는데 우리가 입력은 못한다. 그렇기에 이미 존재하는걸 이용해야하는데 0xbffffae8 에 널 4바이트가 있다. 그러므로 그 앞에 문자열 주소를 입력한 후 해당 위치를 두번째 인자로 넘겨줄 것이다.

세번째 인자 Null은 0xbffffae8을 넘겨줄 것이다. 해당 주소가 이미 Null이기 때문에



(포인터배열)



위와 같이 포인터 주소배열을 만들 수 있다.



(포인터 배열)


0xbffffad4 위치에 정확히 포인터 배열이 들어갔다.
이제 두번째 인자로는 0xbffffad4를 
세번째 인자로는 0xbffffad8을 넣어줄 것이다.

마지막으로 확인 해보자.



(최종 확인)



해당 인자에 알맞은 값이 들어갔는지 체크!

공격!
0x10 바이트 앞뒤로 왔다갔다 하면서 올바른 위치를 잡았다.



(공격 성공)



쉘 획득!



bof 원정대의 golem을 잡아보자!

* 소스코드 분석



(golem.c)


...! 스택영역을 사용해야하는데 버퍼부터 스택 밑바닥까지 싹 초기화 시킨다.

기존의 방법으로는 접근이 안된다... 그래도 한번 실화인지 눈으로 체크해보자.



(스택 초기화)


우리가 쓰던 그리고 찾아내었던 구석구석 0으로 전부 초기화가 되었다.

여기서는 LD_PRELOAD를 제외하고는 방법이 없었다..

LD_PRELOAD란 유닉스계열에서 전역후킹을 위한 방법이다. 

예를 들어 간단한 LD_PRELOAD를 이용한 getuid 후킹 파일을 만들어보겠다.



(hook.c 파일)


getuid를 후킹하려면 그 원형과 똑같은 포멧의 함수여야한다.
return은 7777로 후킹이 되었는지 확인해본다. getuid 함수를 호출할때 이 파일이 불려나가 일을 할 것이다.

컴파일을 해준다.



(hook.so)


컴파일 방식이 조금 다르다.

그 후 export!


(export)



이제 getuid함수가 호출되면 내가 만든 hook.so가 일을 할 것이다. getuid가 불리는 대표적인 명령어 id를 사용해 보겠다.


(id 명령어)



id를 사용해보니 uid 가 7777로 나온다. 바로 내가 만든 so 파일이 일을 한 것이다.

그렇다면 이걸 여기서 어떻게 이용한단 말인가?...
물론 여기서 후킹을 이용해 my-pass 명령을 실행하여 답을 알아내는 방식이 있지만 그 방법은 불법이므로 정석대로 가볼것이다!

gdb를 통해 메모리 낮은 쪽을 찬찬히 훑다보면 LD_PRELOAD로 export한 내용이 담겨있는 것을 볼 수 있다.



(hook파일)



이 것을 이용할 것이다.
바로 hook파일에 링크를 걸어 바로 저 위치에 쉘코드를 올리고 ret주소로 저 주소를 입력하는 것이다!!!!

늘 그렇듯 경로 생성!



(경로 생성)



생성 후! 링크를 걸어준다. 바로 내가 만든 후킹파일에!


(링크 생성)



이제 export해준다.


(export)



이제 내가 건 링크 파일이 스택영역에 담길 것이고 즉 쉘코드가 올라갈 것이다.


(메모리 상황)


짠!
내가 넣은 Nop코드와 쉘코드가 보인다. 이제 Nop영역의 아무 주소나 하나 골라서 ret주소에 입력해주면 공격에 성공하게 된다.




(공격 성공!)


쉘 획득!


'WarGame > 500 Project' 카테고리의 다른 글

(29/500) Lord of the BOF - bugbear  (0) 2017.06.20
(28/500) Lord of the BOF - darkknight  (0) 2017.06.20
(26/500) Lord of the BOF - skeleton  (0) 2017.06.20
(25/500) Lord of the BOF - vampire  (0) 2017.06.20
(24/500) Lord of the BOF - troll  (0) 2017.06.20

bof 원정대의 skeleton을 잡아보자!

* 소스코드 분석


(skeleton.c)


skeleton의 소스코드를 보면 argc를 저장해 두었다가 넘어온 인자를 전부 0으로 초기화하는 코드가 눈에 띈다. 우리가 지금까지 했던 인자를 이용하는 건 못한다는 뜻이다.

gdb를 이용해 메모리를 확인해보겠다.



(gdb를 통한 실행)




(메모리 상태)


메모리를 보면 인자 데이터 영역이 모두 0으로 초기화 된 것을 확인할 수 있다...

그러다 맨 아래 스택 밑바닥에 가보니 뭔가가 있다?



(스택 밑바닥)


혹시?


(스택 밑바닥)


밑바닥을 확인해보니 프로그램 명(경로)가 적혀 있는 것을 확인 할 수 있었다.

그렇다면..! 링크를 이용하여 여기에 쉘코드를 올릴 수 있겠구나! 라는 생각이 들었다. :)

바로 링크를 만들어주기 위해 경로를 만들었다.



(경로 생성)



그 후 링크!


(링크 생성)



링크를 만들었다면 끝이다! Nop 코드도 충분히 넣었겠다! 이제 공격하면 된다.



(공격 성공)



쉘 획득!

'WarGame > 500 Project' 카테고리의 다른 글

(28/500) Lord of the BOF - darkknight  (0) 2017.06.20
(27/500) Lord of the BOF - golem  (0) 2017.06.20
(25/500) Lord of the BOF - vampire  (0) 2017.06.20
(24/500) Lord of the BOF - troll  (0) 2017.06.20
(23/500) Lord of the BOF - orge  (0) 2017.06.20

bof 원정대의 darkelf를 잡아보자!

차근차근 darkelf 소스코드부터 분석해보자.



(소스코드)


추가 된 것은 인자 길이를 체크하고 있다. 게다가 인자를 1개만 넘겨줘야한다.

하나만 넘겨주는데 그 길이도 48바이트를 넘어서는 안된다.

전전 문제에서 풀었던 방법으로 하면 위 조건들을 모두 충족시킨 체로 공격에 성공시킬 수 있었다.

전략은 바로
인자 주소로 ret주소를 넘기는 것이다.
44개 바이트 뒤에 ret 주소가 오는데 여기 ret 주소에 첫번째 인자의 주소를 넘기는 것이다.
그리고 첫번째 인자에 쉘코드를 올리면된다. (아직 인자를 초기화시키지 않기 때문에 공격 가능하다.)

그렇다면 메모리 주소부터 확인해보자!



(gdb 실행)



(메모리 확인 (사용가능한 영역))



예상대로 첫번째 인자의 주소 영역은 날라가지 않았다.
여기에 쉘코드를 올리고 이 주소를 ret주소로 넘겨줄 것이다.

그냥하면 주소를 딱 맞춰야 하기 때문에 Nop 슬레이딩을 쓸것이다. 비록 44바이트 중 내가 쓸 쉘코드는 32바이트 이기 때문에 12바이트 Nop 밖에 쓰지 못하지만 그래도 유용할 것이다.



(gdb 실행)


gdb를 통해 메모리 주소를 확인해본다. 먼저 0xbffffc28 주소로 ret 주소를 넘겨준다.


(메모리 확인(ret주소))


ret 주소에 0xbffffc28 이 잘 넘어간 것을 체크!



(메모리 확인(0xbffffc28))



0xbffffc28 주소 메모리를 확인해보면 Nop코드 위치이고 여기서 Nop이 실행되면서 쉘코드까지 실행될 수 있을거라는 것을 확인 할 수 있다.

그렇다면 darkelf를 공격해보자!



(공격 성공)



바로 쉘을 획득할 수 있었다.



'WarGame > 500 Project' 카테고리의 다른 글

(24/500) Lord of the BOF - troll  (0) 2017.06.20
(23/500) Lord of the BOF - orge  (0) 2017.06.20
(21/500) Lord of the BOF - wolfman  (0) 2017.06.20
(20/500) Lord of the BOF - orc  (0) 2017.06.20
(19/500) Lord of the BOF - goblin  (0) 2017.05.07


BOF 원정대 ORC 를 잡아보자!

먼저 orc.c 소스코드 파일을 주었으니 열어서 확인해본다.


(orc.c 소스코드)



orc 의 특징
1. 버퍼 40바이트이다. 
2. 인자로 프로그램명을 제외하고 하나 이상을 넣어줘야한다.
3. 모든 환경변수를 0으로 초기화한다. ( 환경변수 사용X )
4. 스택영역(\xbf) 영역을 사용해야한다.

그렇다면 gdb를 이용하여 실제 메모리에 어떻게 들어가나 확인해보자.!



(gdb로 프로그램 실행)



인자를 하나 이상 넣어줘야하고 ret 영역의 주소를 bf로 시작하는 주소로 입력해야한다는 조건을 맞추어 시작했다.



메모리 상태(환경변수 초기화)


메모리 상태를 확인해보니 환경변수 있을 자리에 전부 0으로 초기화 되어있는 모습을 볼 수 있다.

그런데?..!



메모리 상태(이용할만한 공간)



바로 ebp 아래 부분에 우리가 인자로 넘겨주는 값을 저장하는 영역을 발견하였다.
이 곳에 쉘코드를 넣고 이 주소를 ret주소로 넘겨주면 쉘을 획득할 수 있을 것 같다 :)

그렇다면 앞에 44바이트 중 우리의 쉘코드(32바이트)를 넣을 것이므로 
쉘코드 + 12바이트(더미) + ret 주소 형식에 맞추어 입력할 것이다. 우리 쉘코드가 위치할 주소 두번째 인자가 저장되는 곳이 0xbffffc2f 이므로 ret 주소에 이 주소를 넣어서 실행해본다.



메모리 확인(ret주소)



ret 주소에 우리가 의도한 0xbffffc2f가 잘 들어가 있는 것 체크!




(메모리 확인(쉘코드))



0xbffffc2f에 쉘코드가 올라가 있는지 체크!

전부 딱 맞게 올라가 있다. 그러므로 이제 gdb를 나와서 직접 실행해보자!

실제로는 메모리 주소가 조금씩 차이가 날 수 있다. 그러므로 일단 core dump를 위해 우리가 복사한 프로그램으로 실행시켜본다.




(bof 시도)



역시 한방에 안됬다. core 덤프 파일을 확인해본다!

우리가 입력한 ret 주소 0xbffffc2f 주소 근처를 확인해본다.




(core dump 파일)



확인해보니 0xbffffc2f에는 다른 것이 들어가있고 우리가 원하는 쉘코드 주소는
0xbffffc32 라는 것을 알 수 있다.

이제 ret 주소에 0xbffffc32를 넣어주고 실행!



(bof 성공)



쉘을 획득 할 수 있었다.

이렇게 orc를 처치하였다. :)


'WarGame > 500 Project' 카테고리의 다른 글

(22/500) Lord of the BOF - darkelf  (0) 2017.06.20
(21/500) Lord of the BOF - wolfman  (0) 2017.06.20
(19/500) Lord of the BOF - goblin  (0) 2017.05.07
(18/500) Lord of the BOF - cobolt  (0) 2017.05.05
(17/500) Lord of the BOF - gremlin  (0) 2017.05.05


19번째 푼 문제이다!
오늘은 BOF원정대의 고블린을 처치해보자!

고블린이 보인다.



(고블린)



먼저 C코드를 확인해보자.



(고블린 C코드)



C코드를 보니 코볼트 녀석과 동일하다. 다만 입력에 있어서 차이가 있다.

입력을 표준입력으로 넣어주기만 하면 동일하게 처치할 수 있다.

먼저 메모리 주소를 확인하기 위하여 gdb로 분석해보자.



(표준입력 메모리 위치)



표준입력이 어디에 올라가는지 확인해보자.
여기서 버퍼를 배열을 사용한다. 배열은 힙 자료구조와 같이 높은주소로 자라기 때문에 배열로 된 버퍼가 주어지면 RET 주소를 쉽게 덮어 쓸 수 있다.

먼저 주어진 배열 버퍼를 꽉채워보자. A 16개를 입력한다.



(메모리 상태)



16바이트가 A로 가득 찬 모습을 볼 수 있다. 마지막 00 널문자가 다음 메모리 영역으로 초과된 것을 볼 수 있다. 이제 우리는 여기서 +4바이트(Saved EBP자리) 를 A로 더 채워준 후 RET주소를 EBP+8의 주소로 덮어 쓸 것이다. EBP+8에 우리의 쉘코드를 올릴 것이기 때문이다. :)

그렇다면 우리가 쉘코드를 올릴 EBP+8의 위치를 먼저 살펴보자.



(쉘코드가 올라갈 위치)



쉘코드가 올라갈 위치까지 확인했다면 끝이다.

정리를 하면
A 20개를 입력한 후 그 뒤에 RET주소에 쉘코드가 올라갈 위치로 덮어쓴다. 그리고 그 뒤에 이어서 쉘코드를 올려서 입력할 것이다.

고!



(공격 성공)



바로 쉘이 떨어지는 것을 확인 할 수 있다.

whoami로 확인 후 my-pass를 확인해보면 고블린 문제도 해결할 수 있다.



(고블린 처치)


'WarGame > 500 Project' 카테고리의 다른 글

(21/500) Lord of the BOF - wolfman  (0) 2017.06.20
(20/500) Lord of the BOF - orc  (0) 2017.06.20
(18/500) Lord of the BOF - cobolt  (0) 2017.05.05
(17/500) Lord of the BOF - gremlin  (0) 2017.05.05
(16/500) Wargame.kr - ip log table  (0) 2017.04.20


18번째 문제 풀이이다.! :)

cobolt를 풀어보자!



(홈디렉토리)



파일이 2개 들어있다.
먼저 C코드를 확인해본다.



(C코드)



C코드를 보니 그렘린 문제와 비슷한데 다른점이 버퍼의 크기가 작다는 것이다..
16바이트. 우리의 쉘코드는 32바이트이다.

우리의 쉘코드를 줄이던가 다른 방법이 필요하다.



(메모리 구조)



그렇게 생각하던 도중 스택의 더 높은 주소를 쓰는게 어떨까 하는 생각이 들었다.
문제의 버퍼는 배열이므로 높은 주소방향으로 채워진다. 즉 긴~ 문자열을 입력하면 RET주소를 넘어 그 아래까지 덮어 쓸수 있다는 것이다.
그래서 나는 버퍼를 A로 가득 채운후 Saved EBP 범위까지 A로 채우고
그 다음 RET주소에 RET+4주소로 덮어 쓸것이다. 그 후 RET+4 주소에 우리의 쉘코드를 올릴 것이다.

그렇게 되면 쉘을 떨어뜨리는데는 문제가 없을 것이다.!



(BOF)



주소부분을 C로 채워보았고 그 그 오른쪽 주소부터 쉘코드가 올라가는 지점이다.

쉘코드의 주소 EBP+8을 확인해보자.



(쉘코드 위치)



쉘코드의 위치를 확인한다.

이제 실제 주소값을 넣어보고 잘 넣어지는지 확인해본다.




(테스트)



확인해보니 주소도 잘 들어갔고 쉘코드 또한 잘 들어갔다. :)

이제 실제 프로그램에서 공격해보면 된다.




(공격화면)



공격을 해보니 바로 쉘이 떨어지는 것을 확인 할 수 있었다.



(문제 해결)

'WarGame > 500 Project' 카테고리의 다른 글

(20/500) Lord of the BOF - orc  (0) 2017.06.20
(19/500) Lord of the BOF - goblin  (0) 2017.05.07
(17/500) Lord of the BOF - gremlin  (0) 2017.05.05
(16/500) Wargame.kr - ip log table  (0) 2017.04.20
(15/500) Wargame.kr - lonely guys  (0) 2017.04.18

+ Recent posts