Socket_client.py
2015.05.28
no image
FTZ Level19 //Chaining RTL Calls
문제확인우선 문제는 아래와 같이 단순한 형태를 띄고 있다. 하지만 여기에서 주의 해야할 것은 기존과는 다르게도 setreuid가 존재 하지 않는 것을 유의 하여야 한다. 이제 아래와 같이 GDB를 통하여 스택을 확인해보면 40바이트가 할당이 되어 있는 것을 확인 할 수가 있다. 이는 buf[20] - Dummy[20] - SFP - RET의 형태로 존재하는 것을 확인 할 수가 있다. RTL - 실패우선 RTL을 통하여 공격을 하여보자. 기존과 같이 system( ) 함수를 이용한 공격을 할 경우 권한 상승이 이루어지지 않은 것을 확인 할 수가 있다. 바로 setreuid가 존재하지 않기 떄문이다. 따라서 system()함수를 이용한 공격은 현재 이 자체만으로는 효력이 부족하다는 것을 알 수 있다. 따라서..
2015.05.28
no image
FTZ Level18
문제확인우선 바로 hint를 확인하여 소스코드를 보면 아래와 같이, 지금까지의 소스보다 긴 것을 확인 할 수가 있다. 하지만 여기서 잡아야 할 것은 난잡한 다른 코드가 아닌 count의 값을 감소시켜주는 swith문을 확인 할 수가 있어야한다. 아래 코드에서 보는 것과 같이 "\x08"이 입력될 경우 count의 1 감소하는 것을 확인 할 수가 있다. 스택의 구조를 아래와 같이 확인을 해볼 경우 fds[132] - count[4] - x[4] - Check[4] - string[0] ~ string[100] - SFP -RET 이러한 형태로 나타나는 것을 확인 할 수가 있다. 여기서 우리가 알아야할 것은 기존의 string과 같은 역할을 하는 변수의 위치가 Low 쪽에 위치하기에 우리는 버퍼를 덮어 씌울..
2015.05.25
no image
FTZ Level17
문제 확인이제 벌써 17번 문제이다. 끝이 보이고 있으니 마저 풀이를 계속하여보자. 아래의 소스와 같이 16번 문제와는 다르게 Shell()이라는 함수가 존재하지 않고 main()에 setreuid가 존재하고 있는 것을 확인 할 수가 있다. 따라서 우리는 *call 포인터변수를 통하여 printit()가 아니라 우리가 쉘코드를 메모리에 올려 그 메모리의 주소를 가리키도록 해야 이 문제에서 쉘을 획득 할 수가 있다. GDB를 통하여 디스어셈블링을 해본다면 우선 main()에서 0x38만큼의 스택이 할당 되는 것을 확인 할 수가 있다. 또한 이전의 문제들을 통하여 우리는 스택의 구조를 짐작 할 수가 있다. 우선 Buf[20] - Dummy[20] - *Call[4] - Crap[4] - Dummy[8] - ..
2015.05.24
no image
FTZ Level16
문제확인바로 문제를 확인하여 보자. main()에서와 보는 것과 같이 printit를 호출한다. 하지만 여기서 shell()을 호출하도록 유도를 해야 쉘을 획득 할 수 있다는 것을 알 수가 있다. 여기서 *call 은 포인터 변수임을 잊지 말아야 한다. 우선 GDB를 통하여 프로그램을 분석해본다면 아래와 같이 shell() , printit(), main()의 순으로 되어있는 것을 확인 할 수가 있다. 여기서 확인 할 것은 main() 함수에 0x38만큼 스택이 할당 되는 것을 확인 할 수가 있다. 정확한 위치를 확인 하기 위하여 아래와 같이 입력을 하여 새로운 attackme_2를 만들어주자. 여기서 달라진 것이라 함은 crap에 "AAAA"라는 값을 주는 것으로 정확한 crap의 위치를 확인하기 위하..
2015.05.22
no image
FTZ Level15 //Hard Coding, EGG
문제확인우선 문제를 확인하여 보자. 레벨14와 비슷하지만 check 변수가 포인터 변수임에서 차이가 난다. 여기서 중요한 것은 포인터 변수는 그 변수가 메모리의 주소를 가리키고 있으며 그 주소의 값이 0xdeadbeef를 나타내어야 쉘을 획득 할 수 가 있는 문제이다. GDB를 통하여 확인을 해본다면, 스택에 0x38( = 56 ) 만큼이 할당 되는 것을 확인 할 수가 있다. 이를 통해 우리는 어느정도 유추를 할 수가 있지만 정확한 *check변수의 위치를 알아야 한다. 아래와 같이 코딩을 한 후에 실행을 하면 Buf[20] - Dummy[20] - Check[4] - Crap[4] - Dummy[8] - SFP[4] - RET[4] 가 스택에 놓여있는 것을 확인 할 수가 있다. 여기서 우리는 더 명확하..
2015.05.21
no image
FTZ Level14 //Distance
문제확인우선 hint 파일을 먼저 확인을 해보면 buf[20]과 check, crap이 스택에 할당 되는 것을 확인 할 수가 있다. 그리고 check의 값이 0xdeadbeef 일 경우에 쉘을 획득 할 수 있는 소스이다. 이또한 fgets를 통하여 45바이트 만큼만 전달이 될 수 있기에 BOF를 방지하고 있다. 이제 GDB를 통하여 메모리를 확인 하여 보자. DIsas을 통하여 확인 하였을때 0x38 == 50 바이트 만큼이 스택에 할당 되는 것을 확인 할 수가 있다. 하지만 여기서 우리는 Check라는 정확한 위치를 찾아야 하기 떄문에 우리는 더미가 얼마나 할당이 되는 지를 확인 할 수가 있어야 한다. 그렇기에 distance.c라는 프로그램을 우리가 작성하여 확인을 해보자. 아래와 같이 컴파일을 한 ..
2015.05.17
no image
FTZ Level13 //RTL, EGG
문제확인 Level13의 힌트를 확인하면 아래와 같은 소스가 출력이 된다. 인자를 입력 받고 그 인자를 buf에 복사하여 넣는 것으로 strcpy가 취약점이 있는 함수의 위치이다. 그리고 i 의 값 0x1234567이 변화 될경우 "Warnning Buffer Overflow !!!를 출력하며 그대로 프로그램이 종료가 된다. 여기서 i 와 같은 것을 바로 Stack Guard 라고 부른다. 이제 이 프로그램을 GDB로 분석하여 보자 디버깅 권한을 위하여 cp 명령어를 통하여 tmp 로 복사한 후에 분석을 시작하면 된다. 아래 사진과 같이 프롤로그에서 0x418(1048)만큼의 스택이 할당 되는 것을 확인 할 수가 있다. 그렇다면 스택의 구조는 1048 + SFP + RET 라는 것을 이제는 충분히 예상 ..
2015.05.13

Socket_client.py

Kail-KM
|2015. 5. 28. 19:05



'Programming > Python' 카테고리의 다른 글

Search_File.py  (1) 2015.06.20
Socket_server.py  (0) 2015.05.28
Code Injection by Python  (1) 2015.03.26
DLL Injection API by Python  (0) 2015.03.25
if f=open('test.txt','r') == True: ||if not f=open('test.txt','r'): 은 안된다.  (0) 2015.03.05

문제확인


우선 문제는 아래와 같이 단순한 형태를 띄고 있다. 하지만 여기에서 주의 해야할 것은 기존과는 다르게도 setreuid가 존재 하지 않는 것을 유의 하여야 한다. 이제 아래와 같이 GDB를 통하여 스택을 확인해보면 40바이트가 할당이 되어 있는 것을 확인 할 수가 있다. 이는 buf[20] - Dummy[20] - SFP - RET의 형태로 존재하는 것을 확인 할 수가 있다.





RTL - 실패


우선 RTL을 통하여 공격을 하여보자. 기존과 같이 system( ) 함수를 이용한 공격을 할 경우 권한 상승이 이루어지지 않은 것을 확인 할 수가 있다. 바로 setreuid가 존재하지 않기 떄문이다. 따라서 system()함수를 이용한 공격은 현재 이 자체만으로는 효력이 부족하다는 것을 알 수 있다.


따라서 이번에는 execl() 함수를 통한 공격을 해보려 했다. 하지만 깔끔하게 Segmentation fault가 발생 한 것을 확인 할 수가 있다. //사실 이 방법은 첫 시도 였는데...실패..





Chaining RTL Calls


위 와 같이 그냥 공격으로는 공격이 성공하지 않는 다는 것을 확인 했다. 그래서 RTL과는 비슷하면서도 좀더 고급기법인 ROP를 공부하던 도중에 Chaining RTL Calls 라는 방식을 알게 되었다. 이는 RTL을 체인처럼 이어 여러 함수를 호출 하게 하는 것이고 그것을 가능하게 하는것이 바로 POP-RET 이다. 

대략적인 페이로드는 아래와 같이 구성을 하면 된다. 여기서 pop-pop-ret를 통하여 argv1,argv2를 Setreuid()함수에 인자로 전달을 해주고 마지막의 ret를 통하여 다시 system() 함수를 이어서 호출하게 된다. 그렇게 호출된 system()함수는 4바이트의 Exit()를 지나 "/bin/sh"를 인자로 전달 받게 되면서 결국 RTL을 통하여 한개가 아닌 함수를 호출하는 것을 볼 수가 있다. 


아래와 같이 연속된 주소로 구성된 지점을 찾아야 한다. objdump를 통하여 찾을 수가 있으며 여기서 우리는 setreuid가 인자를 2개 전달받아야 하기 떄문에 붉은 테두리 안에 표시한 지점을 사용 할 것이다. 만약 인자 수가 더 많으면 pop-pop-pop-ret를 사용하면 되고 더 여러개의 함수를 사용하고자 할 경우에는 exit()의 위치에 다시 pop-ret를 넣어주면 된다. 저 붉은 상자에서 맨위의 pop주소가 우리가 사용할 주소가 되는 것이다.








EGG


Shell Code에 setreuid를 추가한 새로운 쉘코드이다. 기존의 쉘코드에 Setreuid(3100,3100)만 추가하면 되는 것으로 이 부분의 쉘코드는 아래와 같다. 쉘 코드는 다른 블로그를 찾다가 발견한 것 >> http://geundi.tistory.com/132 

"\x31\xc0\x31\xdb\x31\xc9\x66\xbb\x1c\x0c\x66\xb9\x1c\x0c\xb0\x46\xcd\x80"

따라서 여기에 기존의 25바이트 코드를 추가하면 된다. (붉게 표시한 부분이 해당 uid의 번호인 것 같다.)

"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x89\xc2\xb0\x0b\xcd\x80"

따라서 최종 쉘코드는 다음과 같다.

"\x31\xc0\x31\xdb\x31\xc9\x66\xbb\x1c\x0c\x66\xb9\x1c\x0c\xb0\x46\xcd\x80\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x89\xc2\xb0\x0b\xcd\x80"



'Hacking > System Hacking' 카테고리의 다른 글

Cracking Windows Password Hash with Kali linux Live Booting  (1) 2015.08.22
FTZ Level20 //FSB  (0) 2015.05.31
FTZ Level18  (0) 2015.05.25
FTZ Level17  (0) 2015.05.24
FTZ Level16  (0) 2015.05.22

FTZ Level18

Kail-KM
|2015. 5. 25. 01:30

문제확인


우선 바로 hint를 확인하여 소스코드를 보면 아래와 같이, 지금까지의 소스보다 긴 것을 확인 할 수가 있다. 하지만 여기서 잡아야 할 것은 난잡한 다른 코드가 아닌 count의 값을 감소시켜주는 swith문을 확인 할 수가 있어야한다. 아래 코드에서 보는 것과 같이 "\x08"이 입력될 경우 count의 1 감소하는 것을 확인 할 수가 있다.


스택의 구조를 아래와 같이 확인을 해볼 경우 <Low>  fds[132] - count[4] - x[4] - Check[4] - string[0] ~ string[100] - SFP -RET  <High> 이러한 형태로 나타나는 것을 확인 할 수가 있다. 여기서 우리가 알아야할 것은 기존의 string과 같은 역할을 하는 변수의 위치가 Low 쪽에 위치하기에 우리는 버퍼를 덮어 씌울 수가 있었지만 여기서는 string이 Check보다 위쪽에 있기에 덮어 씌울 수가 없다. 하지만 우리가 알아야 할 것은 바로 포인터 변수의 이동이다. 바로 count-1을 통하여 우리는 버퍼를 이동 시킬 수가 있고 바로 그 조건이 위의 붉은 상자 안에 있는 값이다. 




공격


따라서 우리는 count의 값을 4번 이동 시켜 check에 0xdeadbeef의 값을 주어야 한다. 따라서 페이로드는 아래와 같다.




참고 : http://geundi.tistory.com/131

'Hacking > System Hacking' 카테고리의 다른 글

FTZ Level20 //FSB  (0) 2015.05.31
FTZ Level19 //Chaining RTL Calls  (0) 2015.05.28
FTZ Level17  (0) 2015.05.24
FTZ Level16  (0) 2015.05.22
FTZ Level15 //Hard Coding, EGG  (2) 2015.05.21

FTZ Level17

Kail-KM
|2015. 5. 24. 15:59

문제 확인


이제 벌써 17번 문제이다. 끝이 보이고 있으니 마저 풀이를 계속하여보자. 아래의 소스와 같이 16번 문제와는 다르게 Shell()이라는 함수가 존재하지 않고 main()에 setreuid가 존재하고 있는 것을 확인 할 수가 있다. 따라서 우리는 *call 포인터변수를 통하여 printit()가 아니라 우리가 쉘코드를 메모리에 올려 그 메모리의 주소를 가리키도록 해야 이 문제에서 쉘을 획득 할 수가 있다.


GDB를 통하여 디스어셈블링을 해본다면 우선 main()에서 0x38만큼의 스택이 할당 되는 것을 확인 할 수가 있다. 또한 이전의 문제들을 통하여 우리는 스택의 구조를 짐작 할 수가 있다. 우선 Buf[20] - Dummy[20] - *Call[4] - Crap[4] - Dummy[8] - SFP - RET 의 순으로 할당이 되는 것을 알 수가 있다. 하지만 여기선 fgets를 통하여 48바이트 만큼만 전달을 할 수가 있기에 우리는 RET를 통한 공격을 할 수가 없다.


우선 브레이크지점을 형성 한 후 메모리의 상태를 확인 하여 보자. 아래와 같이 0xbfffe080에서부터 buf가 시작이 되며 그 후에 0xbfffe0a8에 *call과 crap이 순차적으로 있는 것을 확인 할 수가 있다. 





공격


환경변수를 통하여 공격을 진행하여 보자. 아래와 같이 페이로드를 입력한 후에 공격을 시도하면 공격에 성공하는 것을 확인 할 수가 있다.


Shell_Code[25Byte] : 

"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x89\xc2\xb0\x0b\xcd\x80"





의문점


아래와 같이 메모리를 확인할떄 A를 40개 만큼 줄경우 *call 위치에 0x804000a가 들어가는 것을 확인 할 수가 있으며, 만약 44만큼 A를 줄경우 Crap으ㅢ 위치에 0x804000a가 들어가므로 인하여 세그먼트 폴트를 일으켜 실행을 할 수가 없었다.




'Hacking > System Hacking' 카테고리의 다른 글

FTZ Level19 //Chaining RTL Calls  (0) 2015.05.28
FTZ Level18  (0) 2015.05.25
FTZ Level16  (0) 2015.05.22
FTZ Level15 //Hard Coding, EGG  (2) 2015.05.21
FTZ Level14 //Distance  (0) 2015.05.17

FTZ Level16

Kail-KM
|2015. 5. 22. 16:50

문제확인


바로 문제를 확인하여 보자. main()에서와 보는 것과 같이 printit를 호출한다. 하지만 여기서 shell()을 호출하도록 유도를 해야 쉘을 획득 할 수 있다는 것을 알 수가 있다. 여기서 *call 은 포인터 변수임을 잊지 말아야 한다.


우선 GDB를 통하여 프로그램을 분석해본다면 아래와 같이 shell() , printit(), main()의 순으로 되어있는 것을 확인 할 수가 있다. 여기서 확인 할 것은 main() 함수에 0x38만큼 스택이 할당 되는 것을 확인 할 수가 있다. 


정확한 위치를 확인 하기 위하여 아래와 같이 입력을 하여 새로운 attackme_2를 만들어주자. 여기서 달라진 것이라 함은 crap에 "AAAA"라는 값을 주는 것으로 정확한 crap의 위치를 확인하기 위하여 일부러 넣어 준 것이다.


gdb를 통하여 확인을 한 결과 우선 buf에 20만큼의 "A"를 넣어준다. 그리고 우리는 buf[20]이 할당 될 경우 dummy가 20만큼 추가로 할당 되는 것을 이미 여러 문제에서 확인을 할 수가 있었다. 이제 여기서 buf[20] + Dummy[20] + 호출주소값[4] - Crap[4] - Dummy[8] - SFP - RET 가 할당 되는 것을 알 수가 있다. 이제 호출주소값이 전달되는 위치에 shell()의 주소를 넘겨주면 된다

<Uttackme에서의 메모리>


<실제 Attackme에서의 메모리>

공격



'Hacking > System Hacking' 카테고리의 다른 글

FTZ Level18  (0) 2015.05.25
FTZ Level17  (0) 2015.05.24
FTZ Level15 //Hard Coding, EGG  (2) 2015.05.21
FTZ Level14 //Distance  (0) 2015.05.17
FTZ Level13 //RTL, EGG  (0) 2015.05.13

문제확인


우선 문제를 확인하여 보자. 레벨14와 비슷하지만 check 변수가 포인터 변수임에서 차이가 난다. 여기서 중요한 것은 포인터 변수는 그 변수가 메모리의 주소를 가리키고 있으며 그 주소의 값이 0xdeadbeef를 나타내어야 쉘을 획득 할 수 가 있는 문제이다. 


GDB를 통하여 확인을 해본다면, 스택에 0x38( = 56 ) 만큼이 할당 되는 것을 확인 할 수가 있다. 이를 통해 우리는 어느정도 유추를 할 수가 있지만 정확한 *check변수의 위치를 알아야 한다.


아래와 같이 코딩을 한 후에 실행을 하면 Buf[20] - Dummy[20] - Check[4] - Crap[4] - Dummy[8] - SFP[4] - RET[4] 가 스택에 놓여있는 것을 확인 할 수가 있다.


여기서 우리는 더 명확하게 Buf주소를 *check의 주소에 올리는 방법을 통하여 공격을 할 수 있는 지를 확인해보자. 아래와 같이 &buf의 주소를 보면 계속 변화하는 ASLR의 형태를 띄고 있는 것을 확인 할 수가 있다. 따라서 우리는 환경변수를 이용하거나 하드코딩의 방법을 이용하여야 한다.





Hard Coding


하드코딩이란 코딩시에 그 숫자나 문자열이 그대로 입력이 되어있는 것으로 이러한 방법을 통하여 풀 수 있는 문제가 은근히 많다는 것을 유의하여야 한다. 아래와 같이 GDB를 통하여 x/16x main을 확인하면 main+34의 부분에 키 값이 그대로 하드코딩 되어 있는 것을 확인 할 수가 있다.




EGG Shell


환경변수를 이용한 방법은 사실 여러번 실패를 하였다. 기존의 export EGG=`python -c 'print "\xef\xbe\xad\xde"'`를 이용한 방법의 경우는 실패 하였지만, 아래와 같은 방법으로 환경변수를 입력해 주었을때는 쉘을 획득 하는데에 성공을 하였다. 구체적인 이유는 알지 못하지만 일단 페이로드를 첨부한다.




'Hacking > System Hacking' 카테고리의 다른 글

FTZ Level17  (0) 2015.05.24
FTZ Level16  (0) 2015.05.22
FTZ Level14 //Distance  (0) 2015.05.17
FTZ Level13 //RTL, EGG  (0) 2015.05.13
FTZ Level12 //BOF,RTL,EGG,Backdoor  (0) 2015.05.10

문제확인


우선 hint 파일을 먼저 확인을 해보면 buf[20]과 check, crap이 스택에 할당 되는 것을 확인 할 수가 있다. 그리고 check의 값이 0xdeadbeef 일 경우에 쉘을 획득 할 수 있는 소스이다. 이또한 fgets를 통하여 45바이트 만큼만 전달이 될 수 있기에 BOF를 방지하고 있다. 이제 GDB를 통하여 메모리를 확인 하여 보자.


DIsas을 통하여 확인 하였을때 0x38 == 50 바이트 만큼이 스택에 할당 되는 것을 확인 할 수가 있다. 하지만 여기서 우리는 Check라는 정확한 위치를 찾아야 하기 떄문에 우리는 더미가 얼마나 할당이 되는 지를 확인 할 수가 있어야 한다. 그렇기에 distance.c라는 프로그램을 우리가 작성하여 확인을 해보자.


아래와 같이 컴파일을 한 후에 실행을 하였을 경우 Buf[20] + Dummy[20] + Check[4] + Crap[4] + Dummy[20] + SFP + RET 라는 것을 확인 할 수가 있다. 이제 이를 통하여 우리는 공격을 시도 할 수가 있다.



공격


Buf[20]과 Dummy[20]을 무작위 값으로 채운후에 Checkdp 0xdeadbeef를 씌어준다면 공격은 성공한다. 그리고 여기서 또한 cat을 붙여줌으로 인하여 입출력을 유지 하여야 한다는 것에 유의하여야 한다.


'Hacking > System Hacking' 카테고리의 다른 글

FTZ Level16  (0) 2015.05.22
FTZ Level15 //Hard Coding, EGG  (2) 2015.05.21
FTZ Level13 //RTL, EGG  (0) 2015.05.13
FTZ Level12 //BOF,RTL,EGG,Backdoor  (0) 2015.05.10
FTZ Level11 //BOF,EGG,Format String  (0) 2015.05.09
문제확인


Level13의 힌트를 확인하면 아래와 같은 소스가 출력이 된다. 인자를 입력 받고 그 인자를 buf에 복사하여 넣는 것으로 strcpy가 취약점이 있는 함수의 위치이다. 그리고 i 의 값 0x1234567이 변화 될경우 "Warnning Buffer Overflow !!!를 출력하며 그대로 프로그램이 종료가 된다. 여기서 i 와 같은 것을 바로 Stack Guard 라고 부른다. 이제 이 프로그램을 GDB로 분석하여 보자 디버깅 권한을 위하여 cp 명령어를 통하여 tmp 로 복사한 후에 분석을 시작하면 된다. 



아래 사진과 같이 프롤로그에서 0x418(1048)만큼의 스택이 할당 되는 것을 확인 할 수가 있다. 그렇다면 스택의 구조는 1048 + SFP + RET 라는 것을 이제는 충분히 예상 할 수가 있다. 하지만 여기서 중요한 것은 바로 i의 값이 변하면 안된다는 것이다. 그렇다면 i의 값을 찾기위해서 디버깅을 계속 실행하여 보자.



i를 찾기 위하여 buf[1024]에 A의 값을 넣고 BP를 걸어 실행을 해보자. r `python -c 'print "A"*1024'`를 입력하여 준다. 그리고 esp의 값을 확인하여 보면 아래와 같이 A(ASCII:41)의 값이 연속적으로 잘 입력된 것을 확인 할 수가 있다. 그렇게 쭉 따라 내려가보자.



0xbfffefc0로부터 "41"의 값이 입력되어서 0xbffff3c0 바로 전까지 "41"이 입력 된 것을 확인 할 수가 있다. 그리고 붉게 표시한 부분에 바로 i의 값이 저장이 되어있는 것을 확인 할 수가 있다. 그렇게 총 1048만큼 버퍼 뒤에는 SFP와 RET가 위치하고 있는 것을 확인 할 수가 있다. 이제 이 값은 유지한 채로 공격을 진행하여 보자.



RTL



디버깅을 통하여 system()과 exit()의 주소를 구한 다음에 "/bin/sh"의 주소를 구하여 공격을 진행하면 된다. 명령어에 대한 설명을 하자면 우선 i 의 값을 유지하기 위하여 i 바로 앞까지 1036만큼은 A로 채워주고 그 후 기존의 i 값을 다시 써준 후에 RET까지의 이동을 위하여 A를 12바이트 더 추가하여 준다. 그 후 system() 함수의 주소를 입력하여 주고 잘못된 종류로 인하여 로그에 기록이 되지 않게 하기 위하여 exit()의 주소를 넣어주고 그 후에 "/bin/sh"의 주소를 넣어 주면 쉽게 공격에 성공 한 것을 확인 할 수가 있다.






ENV-EGG Shell



에그쉘의 경우는 추가적인 설명을 하지는 않겠다.

'Hacking > System Hacking' 카테고리의 다른 글

FTZ Level15 //Hard Coding, EGG  (2) 2015.05.21
FTZ Level14 //Distance  (0) 2015.05.17
FTZ Level12 //BOF,RTL,EGG,Backdoor  (0) 2015.05.10
FTZ Level11 //BOF,EGG,Format String  (0) 2015.05.09
#25 Bytes Shell Code  (0) 2015.05.07