Implant Daemonization (Unix/Darwin)

[pooki3bear]

Is your feature request related to a problem? Please describe.
Hi, I would like the option for the darwin and linux implants to daemonize itself (release tty, open fd, new process group). The general steps can be found here: http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html

Describe the solution you'd like
Currently external mechanisms are used to release the process from the user session, it would be nice for the implant to handle this logic natively.

Describe alternatives you've considered
Daemonizing the process via service loader or scripting language, which may require interaction with disk.
Using well-known lolbin to detach process from user session.

[usiegl00]

@moloch-- Should this be an implant config, or a client command?

[moloch--]

Implant config methinks, basically an optional flag in generate --keep in mind it will also require changes to the model.ImplantConfig / etc.

[usiegl00]

@moloch-- I found that the daemon will only work on linux. Darwin does not support classical fork-setsid-fork daemons.

[usiegl00]

After further testing, I found that starting a goroutine after we daemonize will cause a crash.
Because implants can be run in memory, we cannot take advantage of the technique used in go-daemon.
See this github issue: golang/go#15538

[moloch--]

Yea, this does actually sound deceptively complicated based on the discussion in that issue thread.

[usiegl00]

One way to get around the goroutine crashes would be to reload the entire implant in memory.
See: https://magisterquis.github.io/2018/03/31/in-memory-only-elf-execution.html
If I could get the original implant file bytes in-memory, this might work.

[moloch--]

I'm wondering if we're just better off saying "you need to implement your own wrapper" to get this functionality, so long as the wrapper loads the go code after the fork it sounds like it should work.

However, if we can get a pure go version working that still sounds workable, since we add/remove the code at compile time.

We actually already have code to load ELFs in-memory using proc fs, but this isn't an ideal solution as it's of course tightly coupled to Linux's and any solution I think we'd want to work on any OS where we can realistically use fork() i.e., anything other than windows.

[rundx]

After further testing, I found that starting a goroutine after we daemonize will cause a crash. Because implants can be run in memory, we cannot take advantage of the technique used in go-daemon. See this github issue: golang/go#15538

I'm not getting this! what exactly would make the implant crash if we're using the go-daemon package