[어설픈] LOB 9번 troll 문제풀이

2019. 3. 26. 17:41System Hacking/[LOB] Hacker School

안녕하세요!

오늘은 LOB 9번 문제

troll 문제풀이를 하겠습니다!


문제의 소스코드는 아래와 같이 나와있습니다!

근데 직전 문제와 바뀐 게 좀 있네요!


argument 길이 체크하는 것도 없어지고

버퍼 초기화하는 것도 없어지고 


이번 문제는 컨셉이 좀 달리진거 같네요!


우선 보면,

argument 개수가 2개 이상인건 똑같구여

argv[1]의 48번째가 \xbf 값이여야 하는 것도 동일하구요


근데 //here is changed! 부분을 보니

argv[1]의 47번째 부분이 \xff이면 안된다네요!

그거 말고는 밑에는 뭐 똑같이 strcpy 해서 취약점 터지는 부분이구요!


근데 여기서 왜 굳이 argv[1]의 47번째 값이 \xff면 안되게 했을까요?

왜냐하면 저희가 이때까지 payload에서

 계속 return 주소로 넣었던 

부분의 앞 부분을 보면

0xbffffdc1이런 형태로 


한 마디로 이 문제의 출제의도는

"이때까지 너가 계속 반복적으로 return 했던 패턴을 바꿔보렴^^"

이라고 생각할 수 있겠네요.


그러면 여기서 생각을 해야합니다!

아니 어떻게 하면 47번째가 \xff가 안되게 할 수 있을까?


이건 기본적으로 스택의 구조에 대해서 좀만 생각을 하시면 됩니다!

스택은 kernel과 가까운 부분에서 위쪽 방향으로 자라게 되죠!


높은 주소

[커널 ]    

 [스택 ]

| |

| |

| |

낮은 주소로 자람


한 마디로 어마어마한 양의 값을 버퍼에 넣으면

사람의 위가 음식을 엄청 많이 먹어서 팽창하듯이,

버퍼도 엄청 커져서 0xbfff값을 벗어나 0xbffe까지 갈 수 있지 않을까요? 


근데 물론 여기서 주의해야 할 점은!

적당히 넣어서는 안됩니다!

저도 맨 처음에 5000개 정도 넣었는데 안되더라구요!

계산해보니 대략 66000 몇 개인가 넣어야 하는데 

저는 그냥 깔끔하게 7만개 넣기로 했습니다!

0xbfffffff~0xbffeffff(대략 이 정도 거리)


그래서 gdb로 진짜 \xfe로 바뀌는지 확인하려고

gdb를 킨 후에! 

main에다가 breakpoint를 걸고!


제가 위에서 말씀드렸던 바와 같이 48byte는 

원래대로 저희가 풀던 방식으로 넣고

그 뒤에 \x90을 7만개를 주고 뒤에 

쉘코드가 들어갈 aaaaaaaa를 임시로 넣었습니다!



그리고 저희의 argument 들이 잘 들어갔나

argc 값 0x00000002 옆에

0xbffee9a4 이 부분을 보면!

원래 전에 문제들에선 

argv들의 주소가 0xbfff~~~~~이였는데

이번에는 0xbffe9a4네요!


그래서 argv[1]의 주소값을 확인하고!

0xbffeffff(0xbfff0000에서 -1한 값)을 확인해보면!

저희가 입력한 0x90이 들어가있죠!


그래서 이렇게 스택이 변조되어 argv[1]의 47번째 값이 

0xff가 아닌 0xfe로 바뀌었기 때문에!


저희는 바로 return address에 0xbffeffff를 주고!

7만개의 \x90 바로 뒤에 쉘코드를 입력하면!

ret address는 nop sled를 쭉 타고 내려오다가

shell code를 만나면 실행이 되겠죠?


payload= buffer~ebp 44byte a로 채움+NOP sled 탈 return 주소(0xbffeffff)+\x90 7만개 + 쉘코드


이렇게 해서 아래와 같이 쉘이 따지고!

비밀번호가 뜨는 것을 볼 수 있습니다!