Difference between revisions of "Compel usage scenarios"
Jump to navigation
Jump to search
m (Kir moved page Compel/Usage scenarios to Compel usage scenarios) |
(add usage scenarios) |
||
Line 32: | Line 32: | ||
** Re-open all files to force daemonize | ** Re-open all files to force daemonize | ||
− | [[Category: Compel]] | + | [[Category: Compel|Usage]] |
Revision as of 19:37, 22 September 2016
This article is a collection of ideas of how compel can be used.
One thing parasite code can do is call clone()
and create a thread having access to main process' VM, FDT, FS, etc. The new thread can then do the following things:
- Check socket FDs to get stuck/closed by polling them
- Apply "logrotate" on the fly
- Perform garbage collection
- Catch SIGSEGV, do something with mappings and act upon "illegal" memory access
- Remote swap for task
- WSS detection
Another thing is to perform some activity on behalf of the victim and then just unload itself. With this, we can do:
- Death detection. Open a pipe/socket and pass the other end outside. Once the victim dies, the pipe/socket will wake up.
- Binary updates, e.g. live patching or libs relink
- Tunneling. Replace an open socket with a unix one, and send the former socket to the caller.
- Inject a socket spy
- Pack/Unpack
- Crypt/Decrypt
- Analyze traffic
- Perform traffic fanout (multiplex)
- Similar thing for files on disks -- proxy via pipe(s)
- Filter/split logs
- Do "nohup" on the fly
- Debug stuff by MSG_PEEKing sockets messages of tee+splice sockets
- Re-connect sleeping sockets to other addresses (not 100% safe)
- "Soft" restart of a service -- call execve() from it's context
- Force entering into a container (except the PID namespace, probably)
- Re-open all files (and cwd, root) to facilitate moving on new / (e.g. for disk replacement)
- Remove leaks from e.g. malloc/free heap
- Force reparent (PID change!)
- Re-open all files to force daemonize