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 원정대의 vampire 를 잡아보자!

생각보다 쉬운 문제이다.

먼저 소스코드를 분석해보자!



(소스코드)



소스코드를 보면 ret 주소가 bf로 시작하되 그 다음이 ff면 안된다.

그렇다면 주소를 낮춰주어야한다. 전에 문제를 풀면서 인자가 길어지거나 프로그램명(이것도 인자니까)이 길어지면 주소가 내려가는 것을 확인할 수 있었다.

즉 이걸 이용해서 주소를 ff가 아니도록 낮춰볼 것이다. 가볍게 5000 바이트의 Nop을 달면서 시작해보자!



(Nop 5000바이트)



주소가 0xbfffe7@@ 대역으로 왔다.
많이 낮춰졌지만 우리의 목표에는 멀다 더 낮춰야한다.

100000 바이트를 줘보자!



(100000 바이트 Nop)


주소가 눈에 띄게 낮아졌다. 0xbffe@@@@ 대역으로 낮춰졌다. 이정도면 충분하니 0xbffe@@ 대역의 주소를 ret 주소로 넣고 Nop 코드 뒤에 쉘코드를 붙여서 실행하면 가볍게 공격에 성공할 수 있을 것 같다.



(공격 성공)



직접 해보니 쉘을 획득 할 수 있었다. :)


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

(27/500) Lord of the BOF - golem  (0) 2017.06.20
(26/500) Lord of the BOF - skeleton  (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
(22/500) Lord of the BOF - darkelf  (0) 2017.06.20


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

*소스코드 분석


(troll.c)



소스코드를 보면 우리가 늘 사용하던 인자영역이 초기화 되는 코드가 추가된 것을 확인 할 수 있다.
하지만 argv[0]은 초기화가 안되는데 이점을 이용해서 전 문제에서 풀던것 처럼 풀수가 있다.

실제로 사용할 메모리 주소먼저 확인해본다.



(gdb를 통한 실행)




(초기화된 부분)



늘 사용하던 argv[1] 영역이 0으로 초기화 된것을 확인 할 수 있다.

하 지만!



(argv[0] 영역)


argv[0]영역을 보면 뭔가가 있다. 바로 프로그램명(경로) 이다! 확인해보면


(프로그램명)



프로그램 이름(경로)인 것을 확인 할 수 있다.
그러면 전에 문제처럼 링크를 걸어서!

경로 먼저 생성해준다. \x2f가 경로의 구분자로 사용되기 때문에


(경로 생성)


그 후 링크!


(링크 생성)



Nop이 200개 정도니 충분하겠지? 바로 공격해본다.



(Segmentation Fault)


Segmentation Fault가 난다.. 이런.. 확인해봐야겠다. tromy 라고 내가 복사시킨 복사본을 가지고 링크를 똑같이 생성한 후 메모리를 확인해본다.



(링크생성(복사본에게))



(메모리 모습)



아하 조금 달랐다. 프로그램 이름이 길어져서 메모리 주소가 조금 바뀌었나보다.

다시 원본에 링크를 걸어주고!



(링크 생성(원본))



(공격)



공격! 은.. 또 실패!
Segmentation Fault...
뭐지!!!! 다시 복사본으로 링크를 만든 후 core 파일을 열어보았다. ( 복사본 링크과정은 똑같아서 생략했다.)



(core 파일)



음... 위치가 또 다르네..
어쨋건 nop영역의 주소를 하나 가져다가 공격!



(공격 성공)



쉘 획득!

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

(26/500) Lord of the BOF - skeleton  (0) 2017.06.20
(25/500) Lord of the BOF - vampire  (0) 2017.06.20
(23/500) Lord of the BOF - orge  (0) 2017.06.20
(22/500) Lord of the BOF - darkelf  (0) 2017.06.20
(21/500) Lord of the BOF - wolfman  (0) 2017.06.20


bof 원정대 orge를 잡아보자!

소스코드를 분석한다.


(orge.c)



orge의 소스코드를 보면 특이한 점이 있다. 바로 argv[0]의 길이가 77이여야한다는 점이다.
argv[0]는 프로그램경로 명(프로그램이름포함) 이다.
그러므로 이 문제는 링크를 이용해서 프로그램이름 길이를 조절해야한다.

77바이트니 그 안에 쉘코드를 올리고 argv[0]주소를 넘겨주어도 이 문제를 해결할 수 있을 것이다!

먼저 프로그램 경로명의 길이 77바이트를 맞추기 위한 작업이다.
gdb를 통한 메모리 확인을 위한 것이므로 간단히 cp를 이용해 77바이트만 맞추겠다.



(경로명 77바이트)



이 경로까지 경로 길이는 총 14바이트이므로 나머지 63바이트를 채워주면 된다.

이렇게 만들어진 문제프로그램을 gdb로 열어보자.



(gdb로 실행)



(메모리 확인(인자영역))



인자 영역이 초기화 되지 않는 것을 확인 할 수 있다. 44로 채워진 공간이 프로그램 이름이다.
이 주소를 ret주소로 넘겨주고 이 영역을 NOP + 쉘코드로 만들것이다.

먼저 링크를 생성하기 위해 해야할 일이 있다.
일단한번 만들어보겠다.



(에러발생)


에러가 발생하였다.
이유는 쉘코드 안에 \x2f 가 들어있는데 이것이 아스키문자로 /  를 의미한다. 그렇기에 경로로 인식이 되어서 해당 디렉토리가 없다는 뜻이다. 그러므로 \x2f 가 들어있는 곳을 감안해서 디렉토리를 만들어준다.



(디렉토리 생성)



디렉토리를 생성할 때 -p 옵션을 주어 하위 디렉토리도 한번에 생성한다.


(링크 연결)


그 후 링크를 연결한다.
대상은 Nop(31바이트) + 쉘코드(32바이트) 이다.

자 이제 준비는 끝났다. ret 주소로 아까 확인한 0xbffffbac 로 주고 프로그램을 실행한다!



(Segmentation Fault)



??..?!

뭐지

원인을 파악하기 위해 orge를 ormy로 복사한 후 ormy를 아까 했던 대로 링크를 걸어서 gdb로 열어본다.


(링크 재생성(복사본으로))



그 후 gdb로 메모리를 확인해본다.



(메모리 확인(인자영역))



어라? 이 주소가 맞는데

프로그램을 실행시킨 후 core 파일을 확인해본다.


(core 파일)



core 파일을 확인해보니 원인을 알았다.
이유는 잘 모르겠지만 gdb를 통한 메모리 주소와 조금 다르다...
nop 위치의 아무 주소를 하나 택한 후 그 주소를 넣어준다.

다시 원본 파일에 링크 생성하여 공격 준비



(원본 파일에 링크)


그 후 아까 확인했던 nop영역의 주소 하나를 골라 입력해준다.



(공격 성공)



쉘을 획득하였다 :)


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

(25/500) Lord of the BOF - vampire  (0) 2017.06.20
(24/500) Lord of the BOF - troll  (0) 2017.06.20
(22/500) Lord of the BOF - darkelf  (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

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 원정대에서 wolfman을 잡아보자!

wolfman 소스코드를 확인!



(wolfman.c)



wolfman의 특징
1. 버퍼 40바이트
2. 인자 1개 이상 넘겨줘야한다.
3. 환경변수 초기화
4. 스택영역을 사용해야한다.
5. 버퍼를 초기화한다.!

사실 난 쉘코드 주소로 버퍼 주소를 사용하지 않았기에 버퍼를 초기화하는 기술이 추가해도 전문제와 큰 차이를 못느꼈다.

하지만 다른 방식으로 풀이해볼 겸하여 Nop 슬레이딩을 이용해보겠다.!

먼저 늘 그렇듯 gdb를 열어 메모리를 확인해본다.



(gdb를 이용하여 실행)



조건에 맞춰 strcpy 버퍼오버플로우가 일어나는 영역까지 진행시키기 위해 인자 하나를 추가하고 ret 주소 영역을 bf로 시작하게 하였다.




(메모리 확인(버퍼초기화))



버퍼가 초기화 된 모습을 볼 수 있다.

하지만 우리가 전문제에서 사용했던 영역은 인자 주소!



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



이 영역은 살아있다 :) 이영역을 이용해 보겠다.

Nop슬레이딩을 사용할 것이므로 앞에 Nop 코드를 붙여줄것이다. 단 첫번째 인자에는 Nop을 붙일 수 있는 한계가 있으므로 두번째 인자에 Nop코드와 Shell 코드의 주소를 넘겨줄 것이다.

바로 ret 주소를 대강 넘겨주어도 괜찮다는 것이 Nop슬레이딩 기법의 장점이다. 전 문제까지 우리는 정확한 주소를 찾기위해 core dump 도 하였고 하면서 정확한 주소를 찾아내었다. 이번에는 Nop 슬레이딩을 이용하여 터프하게 해볼 것이다.

대강 0xbffffc88 주소로 ret 주소를 넘겨주고 두번째 인자로 Nop코드 100개와 쉘코드를 넘겨준다.



(Nop+쉘코드 공격)



혹시 모르니 gdb를 이용해 대강의 주소를 확인해본다.
내가 넘겨준 주소는 0xbffffc88



(ret 주소)



ret주소에 잘 들어가 있는것을 체크!



(0xbffffc88 주소)



주소를 확인해보니 잘못 짚었다. 대강의 주소 0xbffffc08로 잡아주어 공격해볼것이다.



(gdb로 다시 확인)




(ret주소)



0xbffffc08 주소가 잘 들어간 것을 확인!



(0xbffffc08 주소)



0xbffffc08 주소에 Nop 영역이 있는것 확이!

이렇게 되면 Nop이 실행되면서 쭉쭉 내려가서 아래 우리의 쉘코드까지 실행을 시킬 것이다.

바로 대담하게 우리 복사본이아닌 원본 코드에 바로 공격해본다.




(공격 성공)



바로 쉘이 떨어진다.
Nop슬레이딩의 위력이다! :)

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

(23/500) Lord of the BOF - orge  (0) 2017.06.20
(22/500) Lord of the BOF - darkelf  (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
(18/500) Lord of the BOF - cobolt  (0) 2017.05.05


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