CODEWITHSUNDEEP
gdbsshdlzma
coffee
coffee

Reputation: 11

Debugging a function with gdb which is called by ifunc with binary patching

I am currently trying to debug the function crc64_resolve in liblzma.so.5 which is loaded by calling sshd. I'm following this medium post to reproduce the dynamic debugging of sshd loading the vulnerable lib. However, the function is loaded with ifunc and is loaded before gdbs init (/catch load).

I tried to follow the post with:

./configure && make && cp src/liblzma/.libs/liblzma.so.5.6.1 ../liblzma.so.5 # building liblzma.so
env -i LD_LIBRARY_PATH=/home/vboxuser/xz/ /usr/sbin/sshd -D -p 2222 # starting sshd according to the blog post (as the root user)
objdump -D liblzma.so.5 | grep crc64_resolve # getting the offset for the target function 
hexedit liblzma.so.5 # replacing the found offset byte manually with 0xCC for debugging
ps -fp $(pidof sshd) # getting pid of sshd
sudo gdb -p 19680 # debugging

After the last command gdb starts and loads all libs. At the point where liblzma is loaded gdb does not stop. I am stuck and don't konw if crc64_resolve is not called at all, the creation of the binary was done incorrectly or if my understanding elsewhere is wrong. I am on a Debian12.06.0-amd64 VM in VirtualBox I would appreciate all help and pointers.

sshd uses my liblzma confirmed by running

LD_LIBRARY_PATH=/home/vboxuser/xz/ ldd /usr/sbin/sshd
# [...]
# liblzma.so.5 => /home/vboxuser/xz/liblzma.so.5 (0x00007fadd8711000)
# [...]

There is a picture below where the link is leading, showing an expected gdb screenshot (call stack).

Upvotes: 1

Views: 86

Answers (1)

coffee
coffee

Reputation: 11

My approach was correct, I forgot to give SSHD an SSH connection (sorry).

Starting SSHD as described, editing after SSHD started and attaching gdb. After continuing in gdb, SSHD requires a SSH connection ssh -p 2222 localhost. After that the breakpoint will be reached in the started gdb session.

Upvotes: 0

Related Questions