pwnkidhn.github.io

small buffer이다. buffer의 크기가 작으니 buffer에 쉘코드를 직접 넣기는 어렵다. 이전 문제와 같이 argv로 줘도 되고, 환경변수에 추가해도 된다. 이번엔 환경변수에 추가해보자. 우선 buf에서 ret까지의 거리는 다음과 같다. buf [16] + sfp [4] + ret [4] 다음과 같이 환경변수에 추가했다. 이제 저장된 주소를 찾아보자. 적당한 값 0xbffffeec를 사용하겠다. 다음단계로 넘어가보자.

Pwnable Write-Up/02.hackerschool L.O.B 2020. 3. 9. 17:30

간단한 BOF 문제이다. strcpyt함수를 통해 argv[1]값을 buffer에 복사하므로 bof에 취약하다. 쉘코드를 환경변수에 등록하여 ret값을 쉘코드 실행주소로 바꾸는 것은 이미 많이 해봤으므로, 다른 방법으로 해보겠다. argc의 제한이 없기 때문에 argv로 쉘코드를 전달해보겠다. 우선 buf에서 ret 주소까지의 거리를 알아보자. BUF [256] + SFP [4] + RET [4] 임을 알 수 있다. 다음과 같이 argv에 쉘코드를 넣어서 실행시켜보자. argv[1]인 "A"*264가 끝난후 argv[2]인 \x90을 볼 수있다. 적당한 값 0xbffffbac를 이용하겠다. 다음 단계로 넘어가자.

Pwnable Write-Up/02.hackerschool L.O.B 2020. 3. 9. 17:13

HINT : attackme의 소스코드 FTZ의 마지막 문제이다. 코드를 보면 stdin으로 부터 입력 받은 문자를 fgets 함수를 통해 bleh에 저장한다. 이런 bleh를 printf로 출력하게 되는데, 일반적으로 사용하는 printf("%s", bleh)가 아닌 그냥 printf(bleh)를 하게 된다. 이는 Format String Bug를 발생시킬 수 있다. Format String Attack 방법은 구글링하여 잘 찾아보자. 우선 gdb로 분석 해 보자. main 함수를 보려고 하는데 main함수를 찾을 수 없다고 한다. 이런 경우에는 main 함수가 어디있는지 직접 찾아줘야 한다. 먼저 함수의 정보를 확인해봤다. __libc_start_main 이란 함수가 있으므로, 저 주소에 break ..

Pwnable Write-Up/01.hackerschool F.T.Z 2019. 12. 10. 15:17

HINT : attackme의 소스코드 코드를 보면, gets 함수로 buf에 받아 print 해준다. setreuid 해주는 부분도 없고, /bin/sh를 실행시켜주는 부분도 없다. 아는 정보가 없으니 Return to Library 기술을 써보자. 우선 buf부터 ret 까지의 거리를 알아 보자. buf(40) + sfp (4) + ret (4) 임을 알 수 있다. main 함수가 끝나면 setreuid(3100,3100)을 해준 다음, system("/bin/sh")를 해주면 될 것 같다. 우선 lib에서 setreuid와 system 함수의 주소를 알아 보자. 두 함수의 주소를 알았다. setreuid를 사용할 때는 함수의 인자값이 2개가 필요하다. 따라서 여기서 가젯이 필요하다. attackme..

Pwnable Write-Up/01.hackerschool F.T.Z 2019. 12. 10. 00:12

HINT : attackme의 소스코드 코드에서 중요한 부분을 보면 프로그램 실행 시 stdin으로 1바이트씩 읽고 있는데, 입력이 0x08인 경우 count의 값이 감소한다. count는 배열 string의 index를 가리키며, 만약 입력이 정상적인 입력인 경우 string[count] = x 를 해주고 count를 증가시킨다. 이제 gdb로 분석해 보자. 우선 각 버퍼의 위치를 확인해 보자. 소스코드와 gdb를 통해 유추해 보면, ebp-124 = check , ebp-128 = x, ebp-132 = count 인 것 같다. 적당히 if 분기문에 breakpoint를 걸고 A를 입력하여 어디서 부터 쓰여지는지 확인 해 보았다. ebp-120이 string의 시작 주소임을 알 수 있다. 정리해 보면..

Pwnable Write-Up/01.hackerschool F.T.Z 2019. 12. 9. 19:10

HINT : attackme의 소스코드 코드를 보면 이전 문제와 비슷하지만 다른점이 있다. 바로 shell이라는 함수가 없어졌다. 코드 상에서 /bin/sh를 실행시켜주는 함수가 없기 때문에 환경변수에 쉘코드를 추가하고, 그 주소를 call 함수가 실행되는 위치에 덮으면 될 것 같다. 우선 환경 변수로 지정해 둔 쉘코드의 위치를 찾아 보자. 0xbffffe48정도 사용하면 될 것 같다. 이제 gdb로 attackme를 봐보자. 이 부분이 call함수를 실행 시키는 부분이므로, fgets을 이용하여 ebp-16에 쉘코드 시작 주소를 넣어 보자. 이제 level18로 올라가 보자.

Pwnable Write-Up/01.hackerschool F.T.Z 2019. 12. 7. 23:27

HINT : attackme의 소스코드 소스코드를 보면 void형 함수 call이 가리키고 있는 문자열을 printit에서 shell로 바꿔주면 될 것 같다. 우선 gdb로 확인해 보자. 상자 부분을 보면 0x8048500을 ebp-16에 mov한다. 저 주소가 무엇인지 확인해 보자. 확인해보니 printit함수의 시작 주소이다. 여기가 *call = printit 하는 부분 인 것 같다. 그러면 ebp-16에 printit의 시작 주소가 아닌 shell의 시작 주소를 넣어보자. shell함수의 시작 주소는 0x080484d0 이므로 이 값을 fgets을 통해 ebp-16에 넣어주면 쉘을 딸 수 있었다. 이제 level17으로 올라가 보자.

Pwnable Write-Up/01.hackerschool F.T.Z 2019. 12. 7. 22:47

HINT : attackme의 소스코드 이번 문제 역시 bof이며, 이전 문제와 다른점은 check가 포인터 형 인 점이다. 우선 gdb로 attackme를 분석해보자. ebp-16이 가리키고 있는 값을 갖고와 eax에 넣은 다음. eax가 가리키고 있는 주소의 값과 deadbeef를 비교하게 된다. 따라서 ebp-16가 가리키고 있는 주소가 deadbeef를 가리키도록 하면 된다. 처음에는 환경변수로 deadbeef를 저장해 놓고, ebp-16에 환경변수가 들어있는 주소를 넣어보았지만, 실행할때마다 바뀌는 주소값 때문에 쉘을 딸 수가 없었다. 좀 더 생각해보면 0xdeadbeef가 하드 코딩 되어있기 때문에 분명 메모리에 있을 것이다. 0xdeadbeef와 cmp하는 부분 다음 주소를 확인해보면 dea..

Pwnable Write-Up/01.hackerschool F.T.Z 2019. 12. 7. 22:29