공부 초기에 offset을 찾는 방법이 너무 헷갈렸다. 왜 /bin/sh 문자열의 offset은 strings -tx filename | grep /bin/sh 로 찾아지고 system 함수는 strings -tx filename | grep system 으로 찾아지긴 하지만 실제 offset과 왜 다른가? 요약하자면 그 이유는 "함수명"은 함수 초기에 무조건 나오는 것이 아니기 때문이다. strings 명령어는 말 그대로 파일 내에 string을 찾아 출력해준다. 그 말인 즉슨, 파일 내에는 hex 값으로된 수 많은 데이터들이 있다. 이 값들 중 string으로 저장된 값들만 출력해주는 역할을 한다. 예를 들어보자. /bin/sh는 파일 내에 문자열로 들어있을 것 같지만 실제로는 ascii code에 ..

pwnable 문제를 풀다보면 libc 파일을 제공해주는 경우가 다수 있다. 하지만 offset을 구할때 자꾸 헷갈리는 부분이 있어 다시 정리한다. pwntools로 찾기 해당 파일의 libc 버전 또는 경로를 확인해서 ┌──(kali㉿kali)-[~/Downloads/1279bf21-e0f3-46a4-b577-3c3955c458fb] └─$ ldd oneshot linux-vdso.so.1 (0x00007ffc07293000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f361f1f0000) /lib64/ld-linux-x86-64.so.2 (0x00007f361f5e1000) 간단한 파이썬 코딩으로 libc 파일의 offset 확인. from pwn..

offset을 찾는 것은 아래 링크 참조. https://wyv3rn.tistory.com/64 libc에서 offset 찾기. pwnable 문제를 풀다보면 libc 파일을 제공해주는 경우가 다수 있다. 하지만 offset을 구할때 자꾸 헷갈리는 부분이 있어 다시 정리한다. pwntools로 찾기 해당 파일의 libc 버전 또는 경로를 확인해서 ┌ wyv3rn.tistory.com 문제에서 libc 파일을 제공할 때, 프로그램 실행 시 해당 libc 파일을 로드해주지 않으면 본인 컴퓨터의 libc를 사용하기 때문에 공격 대상 환경과 달라 offset이 차이가 난다. 예를 들면 아래와 같이 libc-2.27.so 파일이 제공되었지만 실제로는 다른 파일을 사용하는 것을 볼 수 있다. ┌──(kali㉿kal..

// Name: rop.c // Compile: gcc -o rop rop.c -fno-PIE -no-pie #include #include int main() { char buf[0x30]; setvbuf(stdin, 0, _IONBF, 0); setvbuf(stdout, 0, _IONBF, 0); // Leak canary puts("[1] Leak Canary"); printf("Buf: "); read(0, buf, 0x100); printf("Buf: %s\n", buf); // Do ROP puts("[2] Input ROP payload"); printf("Buf: "); read(0, buf, 0x100); return 0; } 앞선 문제와 동일하게 canary는 얻으면 되고, 이 문제의 ..