pwnkidhn.github.io

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

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