libc에서 offset 찾기.

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 import *

libc = ELF('/lib/x86_64-linux-gnu/libc.so.6')

print('system = ',hex(libc.symbols['system']))
print('read = ',hex(libc.symbols['read']))
print('puts = ',hex(libc.symbols['puts']))

┌──(kali㉿kali)-[~/Downloads/1279bf21-e0f3-46a4-b577-3c3955c458fb]
└─$ python test.py
[*] '/lib/x86_64-linux-gnu/libc.so.6'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled
system =  0x49860
read =  0xee550
puts =  0x75e10

장점은 gdb로 찾기 어려운 함수의 offset까지 쉽게 찾을 수 있다.

---

gdb로 찾기

아래와 같이 프로그램 실행 전 간단히 찾을 수 있다.

┌──(kali㉿kali)-[~/Downloads/1279bf21-e0f3-46a4-b577-3c3955c458fb]
└─$ gdb -q /lib/x86_64-linux-gnu/libc.so.6
GEF for linux ready, type `gef' to start, `gef config' to configure
90 commands loaded and 5 functions added for GDB 10.1.90.20210103-git in 0.00ms using Python engine 3.10
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
Reading symbols from /usr/lib/debug/.build-id/3f/d3cdd423a18458d9db3a5e50a2b3c0d4529c07.debug...
gef➤  p system
$1 = {int (const char *)} 0x49860 <__libc_system>
gef➤  p read
$2 = {ssize_t (int, void *, size_t)} 0xee550 <__GI___libc_read>
gef➤  p puts
$3 = {int (const char *)} 0x75e10 <__GI__IO_puts>

하지만 _free_hook과 같이 일부는 함수 실행 전에는 찾아지지 않는다.

gef➤  p __free_hook
$5 = (void (*)(void *, const void *)) 0x0

---

objdump로 찾기.

짠 하고 나올 것만 같지만 실상은 그렇지 않다... 노가다 of 노가다.

┌──(kali㉿kali)-[~/Downloads/1279bf21-e0f3-46a4-b577-3c3955c458fb]
└─$ objdump -d /lib/x86_64-linux-gnu/libc.so.6 | grep __libc_system
0000000000049860 <__libc_system>:
   49863:       74 0b                   je     49870 <__libc_system+0x10>
                                                                                                                    
┌──(kali㉿kali)-[~/Downloads/1279bf21-e0f3-46a4-b577-3c3955c458fb]
└─$ objdump -d /lib/x86_64-linux-gnu/libc.so.6 | grep __GI__IO_puts   
0000000000026a38 <__GI__IO_puts.cold>:
   26a3f:       75 29                   jne    26a6a <__GI__IO_puts.cold+0x32>
   26a51:       75 17                   jne    26a6a <__GI__IO_puts.cold+0x32>
   26a65:       75 0b                   jne    26a72 <__GI__IO_puts.cold+0x3a>
   26a77:       7e f1                   jle    26a6a <__GI__IO_puts.cold+0x32>
   26a8d:       eb db                   jmp    26a6a <__GI__IO_puts.cold+0x32>
   75fe3:       e9 50 0a fb ff          jmp    26a38 <__GI__IO_puts.cold>
                                                                                                                    
┌──(kali㉿kali)-[~/Downloads/1279bf21-e0f3-46a4-b577-3c3955c458fb]
└─$ objdump -d /lib/x86_64-linux-gnu/libc.so.6 | grep puts         
...
0000000000075e10 <_IO_puts>:
...

... 속에 사실 함께 출력된 많은 데이터들이 있음...