ret2dlresolve

初見 ret2dlresolve
在 HackTheBox CTF 看到 void 這題 結果完全沒想法
- x86_64
- dynamic link
- no pie
- no canary
- 有給 libc
- 整個程式就只 call 了一個 read
↓ file
1 | void: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter ./glibc/ld-linux-x86-64.so.2, BuildID[sha1]=a5a29f47fbeeeff863522acff838636b57d1c213, for GNU/Linux 3.2.0, not stripped |
↓ checksec
1 | Arch: amd64 |
↓ info functions
1 | pwndbg> info functions |
↓ disassemble main
1 | pwndbg> disassemble main |
想法
- 有給 libc 那看來八成是要 ret2libc 之類的
- 但只有一個 read 完全沒有輸出 根本不知道怎麼 leak
- 看到 __libc_csu_init 但是根本沒有 syscall gadget
- 查到一個我完全看不懂的解法
ret2dlresolve
為什麼說看不懂呢 因為大家的解法都是用 pwntools 寫腳本就完事
1 | offset = 72 |
這是我解這題用的部分腳本 就 蠻噁心的
我甚至從來不知道 pwnlib 有 rop 這東西
更不知道還可以用 rop.read 直接呼叫
更更不知道有個東西叫 Ret2dlresolvePayload 直接把東西都幫我寫好了
第一次感受到 pwntools 的偉大
Ret2dlresolve
原理
我們知道在執行一個動態編譯的程式時
呼叫一個函式 -> plt -> got -> libc
下次呼叫同一個函式時就可以直接在 got 中找
而 linux 中用了下面的函式來動態鏈結到 libc
_dl_runtime_resolve(link_map_obj, reloc_offset)
而他會調用到的東東都在 .dynamic section
所以我們只要有辦法修改 .dynsym (動態字符串表) 就可以隨便解析任何函式!!!
但是這東西可想而知,是唯獨的,所以我們有了新的想法
因為動態鍊結器會從 .dynamic 中索引到目標,所以修改這個行得通
又或者偽造 link map 控制程式執行目標函式
Exploit
1 | from pwn import * |
- 標題: ret2dlresolve
- 作者: Grissia
- 撰寫于 : 2024-11-17 20:18:22
- 更新于 : 2024-11-27 19:16:56
- 連結: https://grissia.github.io/2024/11/17/ret2dlresolve/
- 版權宣告: 本作品采用 CC BY-NC-SA 4.0 进行许可。