Live data from Hacker News

Show HN: Credentials dumper for Linux using eBPF

github.com

1–10 of 51 posts

Re: Show HN: Credentials dumper for Linux using eBPF

#4
post #3

> built as a static binary without any dependencies > As pamspy rely on libpam, we have to set the path where libpam is installed on your distribution. Confusing text in the readme. Does it have dependencies or not?

I read this as, due to pamspy setting an eBPF probe, pamspy needs to know where libpam.so lives. Not that the pamspy needs libpam to be built

Re: Show HN: Credentials dumper for Linux using eBPF

#5
post #4
post #3

> built as a static binary without any dependencies > As pamspy rely on libpam, we have to set the path where libpam is installed on your distribution. Confusing text in the readme. Does it have dependencies or not?

I read this as, due to pamspy setting an eBPF probe, pamspy needs to know where libpam.so lives. Not that the pamspy needs libpam to be built

Exactly, we have to found the address to hook on the system, so we need the path of the currently use of libpam by other process

Re: Show HN: Credentials dumper for Linux using eBPF

#8

eBPF is one of those things that I feel like I ought to get in to but havent found the time yet. Great app, was it your first venture in to eBPF?

Yes we also use for https://github.com/airbus-cert/dirtypipe-ebpf_detection which is a dirtypipe detection program!

Re: Show HN: Credentials dumper for Linux using eBPF

#10
post #3

> built as a static binary without any dependencies > As pamspy rely on libpam, we have to set the path where libpam is installed on your distribution. Confusing text in the readme. Does it have dependencies or not?

When the author says it “has no dependencies” they are referring to build time dependencies (i.e. development headers) and runtime library dependencies (dynamic libraries that will be linked and used at runtime).

In this case the function of the program is to hook a library function in `libpam` using eBPF so it has libpam as a “dependency” in roughly the same way that a program which converts wav to mp3 depends on “the input wav file”.

Given that this is a somewhat unusual way to depend on a `.so` file it’s reasonable for there to be some ambiguity in the language here.

Post reply on HN