pwnkidhn.github.io

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

HINT : attackme의 소스코드 이제 앞으로 bof와 포맷 스트링 문제가 자주 나올 것 같다. 소스코드를 확인해보면 buf 크기는 20인데, fgets에서 45 만큼 buf에 쓰기 때문에 bof임을 알 수 있다. fgets를 통해 check을 0xdeadbeef 값으로 덮어 쓴다면 아래 조건문으로 들어가 쉘을 딸 수 있을 것 이다. 우선 buf에서부터 check까지의 크기를 알아보자. deadbeef와 비교하는 값의 위치는 ebp-16임을 알 수 있다. gdb를 통해 ebp-16에 어떤 값이 들어있는지 확인해 보자. 0xbfffed68이 들어 있는것을 확인했다. 이제 fgets 함수 다음에 breakpoint를 걸어 buf부터 check까지의 크기를 구해보자. 0x41이 들어있는 buf부터 0xb..

Pwnable Write-Up/01.hackerschool F.T.Z 2019. 12. 7. 20:58

HINT : attckme의 소스코드 bof 이지만 중간에 i == 0x1234567이어야 한다. 리눅스의 보호기법 중에 Canaries가 있는데 이와 비슷하게 bof를 보호해주는 기법이다. 하지만 쉽게 우회 할 수 있다. 우선 환경 변수로 저장한 shellcode의 위치를 알아 보자. 0xbffffbf8에 위치하고 있다. 그 다음 ret 위치와 i의 위치를 확인해 보자. i 위치에서 12바이트 뒤에 ret가 있는 것을 확인 할 수 있다. 자 그럼 strcpy 함수 뒤에 break point를 걸어서 i까지의 버퍼의 크기를 구해 보자. 0xbfffe780부터 0xbfffeb88 까지 임을 확인할 수 있으며 이 차이는 1036 이다. 즉 buf (1032) + i (4) + buf (8) + sfp (4)..

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

HINT : attackme의 소스코드 level11과 비슷한 bof이다. gets으로 str을 입력 받을 때 bof을 이용하여 ret값을 조작하여 쉘을 딸 수 있다. 환경변수에 shellcode를 입력한다. 0xbffffbfc를 보면 환경변수에 저장해놓은 \x90+shellcode가 들어있는 것을 알 수 있다. 이 주소를 ret 위치에 덮으면 된다. gets함수 뒤에 break point 를 걸어 놓고 A를 입력해 준 결과, 0xbffffe860부터 A가 입력된 것을 볼 수 있다. 그리고 0xbfffe96c에 ret 주소가 적혀 있는 것도 확인 할 수 있다. 이 둘 사이의 거리를 계산해보면, (buf + sfp) (268) + ret(4) 가 된다. 따라서 "A"*268 + "0xbffffbfc"(sh..

Pwnable Write-Up/01.hackerschool F.T.Z 2019. 12. 7. 02:37

HINT : attackme의 소스인것 같다 strcpy함수는 bof에 취약한 함수이며, argv[1]의 값을 받아서 str로 저장한다. bof로 우리가 원하는 실행을 하도록 ret값을 바꿔주면 되겠다. gdb로 attackme를 까보니 HINT의 코드와 일치한걸 확인 할 수 있다. bof를 하기위해 우선 환경변수에 shellcode를 추가해 보자. 잘 추가 되었다. 이제 gdb로 shellcode가 들어간 주소를 확인해 보자. 0xbfffffa8 을 보면 환경변수로 추가해준 \x90 + shellcode가 있음을 확인 할 수 있다. 이 주소를 잘 기억해 두었다가 bof시 조작할 ret값에 넣어 주면 쉘을 딸 수 있다. 자 이제 ret까지의 크기를 확인해 보자. 우선 ret에 들어있는 값을 확인해 보면 ..

Pwnable Write-Up/01.hackerschool F.T.Z 2019. 12. 6. 21:12