IssueRaiser

The executable appears to be packed using vanilla UPX.

The executable appears to be packed using vanilla UPX. Decompressing it and grepping the symbol table reveals the presence /lib/libc.so.6, /lib/libm.so.6 and /lib/libpthread.so.0. By method of exclusion, it cannot be musl because musl unifies everything into a single /lib/libc.so. It most likely is not uClibc because uClibc is typically symlinked to /lib/libc.so.0 from /lib/libuClibc. Considering that the soname of /lib/libc.so.6 has been reserved by glibc since the 2.x days (to differentiate it from the Linux libc days of libc4 and libc5), it is most likely indeed glibc in use. It's obvious this program isn't making use of NSS or anything like that, so it's doable to use glibc for static linking, if frustrating.

Posted by vezzy-fnord on Jun 26, 2015, 2:06 PM

Tags

Related issues

Raise real-world problems, find people facing the same issue, and discuss solutions.5,500 issues0 comments

hackernews (Sysadmin)

The executable appears to be packed using vanilla UPX.

vezzy-fnordJun 26, 2015, 2:06 PM

The executable appears to be packed using vanilla UPX. Decompressing it and grepping the symbol table reveals the presence /lib/libc.so.6, /lib/libm.so.6 and /lib/libpthread.so.0. By method of exclusion, it cannot be musl because musl unifies everything into a single /lib/libc.so. It most likely is not uClibc because uClibc is typically symlinked to /lib/libc.so.0 from /lib/libuClibc. Considering that the soname of /lib/libc.so.6 has been reserved by glibc since the 2.x days (to differentiate it from the Linux libc days of libc4 and libc5), it is most likely indeed glibc in use. It's obvious this program isn't making use of NSS or anything like that, so it's doable to use glibc for static linking, if frustrating.

Comments (0)

No comments yet. Start the discussion.

Comment on this issue