A free and open-source rootkit for Linux • Hacker News Board

Re: A free and open-source rootkit for Linux

#41

Post by pests » Mon, Jan 19, 2026, 6:03 AM UTC

fc417fc802 wrote: post #30

throawayonthe wrote: post #23

Earlier quoted context omitted.

i think this comment is referring to the uniquely american controversy over "gun free zones", ie zones where... you aren't allowed to carry firearms by law, often marked with a sign which i find very entertaining, saying "a sign can't stop a criminal!" as if that's not the case with any law enforced via threat of criminal prosecution

I don't think I'd call it a controversy exactly. There are places where the signs make sense (ex court buildings) and then there are places where they are purely performative. When a school in the ghetto that suffers gang related violence prominently posts such signs they rightfully get made fun of. Meanwhile most schools (at least where I grew up) either don't bother to post such signs or only post a subdued "all we…

> What could possibly be the point of posting such a sign?

If you want a real answer, its increased penalties / extra charges if caught in the "zone".

Re: A free and open-source rootkit for Linux

#42

Post by pseudohadamard » Mon, Jan 19, 2026, 6:12 AM UTC

Onavo wrote: post #28

jraph wrote: post #2

> If one did wish to use Singularity for nefarious purposes, however, the code is MIT licensed and freely available — using it in that way would only be a crime, not an instance of copyright infringement. Too bad the author picked the MIT license. Had they picked (A)GPL, it would have forced the criminals to distribute a copy of LICENSE.TXT alongside their improved copy of the source code on systems they compromise.…

It's nice until you get spammed with emails from angry users. I think it happened to the sqlite and other popular open source project authors. Non technical users think they are polluting their computer. https://news.ycombinator.com/item?id=42358470

This is why our temp files have names like malware_dropper.exe and bitcoin_scam.xls. If anyone sees those they assume it's some virus and don't bother us with them.

Re: A free and open-source rootkit for Linux

#43

Post by fc417fc802 » Mon, Jan 19, 2026, 6:50 AM UTC

XorNot wrote: post #35

fc417fc802 wrote: post #31

Earlier quoted context omitted.

Yes, I am aware. I was suggesting that even going to the ridiculous length of patching and replacing libc system wide would likely make more sense than authoring a custom kernel module to accomplish most tasks for which such options are applicable.

Statically compiled binaries don't use libc. Golang is one, anything with Rust and MUSL is another, and reliably injecting an environment variables into Nix is well..not reliable. It also links its own hashed libc paths which you can't predict and which shouldn't be different to any process which isn't trying to establish TLS connections. It's not like I didn't try this stuff.

You can hook the system call to open a file regardless of libc use. If for some strange reason you really wanted to patch libc and the program you're using statically links it (ex musl) that isn't an issue - just patch the relevant libc implementation and recompile. But more generally, if you have access to the source code then why would you not directly patch the program in question instead of resorting to these sorts of shenanigans?

Seriously, you're doing it wrong. Just hook the relevant system call and be done with it. Your usecase is literally one of the first eBPF tutorials that comes up when looking for information about modifying system call arguments. https://github.com/eunomia-bpf/bpf-developer-tutorial/tree/m...

Re: A free and open-source rootkit for Linux

#44

Post by [deleted] » Mon, Jan 19, 2026, 1:03 PM UTC

fc417fc802 wrote: post #43

XorNot wrote: post #35

Earlier quoted context omitted.

Statically compiled binaries don't use libc. Golang is one, anything with Rust and MUSL is another, and reliably injecting an environment variables into Nix is well..not reliable. It also links its own hashed libc paths which you can't predict and which shouldn't be different to any process which isn't trying to establish TLS connections. It's not like I didn't try this stuff.

You can hook the system call to open a file regardless of libc use. If for some strange reason you really wanted to patch libc and the program you're using statically links it (ex musl) that isn't an issue - just patch the relevant libc implementation and recompile. But more generally, if you have access to the source code then why would you not directly patch the program in question instead of resorting to these sor…

[deleted]