Compel usage scenarios - Revision history

Kir: make it a bit more structured

2017-03-04T20:55:05Z

make it a bit more structured

Xemul at 17:03, 30 November 2016

2016-11-30T17:03:26Z

Kir: add usage scenarios

2016-09-22T19:37:00Z

add usage scenarios

Kir: Kir moved page Compel/Usage scenarios to Compel usage scenarios

2016-09-22T19:36:43Z

Kir moved page Compel/Usage scenarios to Compel usage scenarios

Kir: +intro, some minor rewording

2016-09-22T18:39:53Z

+intro, some minor rewording

Xemul: Created page with "== Usage ideas == One thing parasite code can do is call clone() and create thread having access to main process VM, FDT, FS, etc. The new thread can then * Check socket FDs..."

2016-09-22T09:32:31Z

Created page with "== Usage ideas == One thing parasite code can do is call clone() and create thread having access to main process VM, FDT, FS, etc. The new thread can then * Check socket FDs..."

New page

== Usage ideas ==

One thing parasite code can do is call clone() and create thread having access to main process VM, FDT, FS, etc. The new thread can then

* Check socket FDs to get stuck/closed by polling them
* Apply "logrotate" on the fly
* Garbage collector
* Catch SIGSEGV, do smth with mappings and act upon "illegal" memory access
** Remote swap for task
** WSS detection

Another is to do some activity on the victim and then just unload. With this we can

* Death detection. Open 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 opened socket with unix one, and send the former one to the caller
** Inject socket spy
** Pack/Unpack
** Crypt/Decrypt
** Traffic analyzer
** Traffic fanout (multiplex)
* The same for files on disks -- proxy via pipe(s)
** Filter/split logs
* Do "nohup" on the fly
* Debug stuff by MSG_PEEK-ing 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 CT (except 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 -- force daemonize

[[Category: Compel]]

@@ Line 1: / Line 1: @@
 This article is a collection of ideas of how [[compel]] can be used.
 One thing parasite code can do is call <code>clone()</code> and create a thread having access to main process' VM, FDT, FS, etc. The new thread can then do the following things:
@@ Line 10: / Line 12: @@
 ** 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:

@@ Line 6: / Line 6: @@
 * Apply "logrotate" on the fly
 * Perform garbage collection
 * Catch SIGSEGV, do something with mappings and act upon "illegal" memory access
 ** Remote swap for task

← Older revision		Revision as of 19:37, 22 September 2016
Line 32:		Line 32:
	** Re-open all files to force daemonize		** Re-open all files to force daemonize

−	[[Category: Compel]]	+	[[Category: Compel\|Usage]]

← Older revision	Revision as of 19:36, 22 September 2016
(No difference)

@@ Line 1: / Line 1: @@
-== Usage ideas ==
+This article is a collection of ideas of how [[compel]] can be used.
-One thing parasite code can do is call clone() and create thread having access to main process VM, FDT, FS, etc. The new thread can then
+One thing parasite code can do is call <code>clone()</code> 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
-* Garbage collector
+* Perform garbage collection
-* Catch SIGSEGV, do smth with mappings and act upon "illegal" memory access
+* Catch SIGSEGV, do something with mappings and act upon "illegal" memory access
 ** Remote swap for task
 ** WSS detection
-Another is to do some activity on the victim and then just unload. With this we can
+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 pipe/socket and pass the other end outside. Once the victim dies the pipe/socket will wake up.
+* 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
+* Binary updates, e.g. live patching or libs relink
-* Tunneling -- replace opened socket with unix one, and send the former one to the caller
+* Tunneling. Replace an open socket with a unix one, and send the former socket to the caller.
-** Inject socket spy
+** Inject a socket spy
 ** Pack/Unpack
 ** Crypt/Decrypt
-** Traffic analyzer
+** Analyze traffic
-** Traffic fanout (multiplex)
+** Perform traffic fanout (multiplex)
-* The same for files on disks -- proxy via pipe(s)
+* Similar thing for files on disks -- proxy via pipe(s)
 ** Filter/split logs
 * Do "nohup" on the fly
-* Debug stuff by MSG_PEEK-ing sockets messages of tee+splice sockets
+* 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 CT (except pid namespace, probably)
+* 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!)
+* Force reparent (PID change!)
-** Re-open all files -- force daemonize
+** Re-open all files to force daemonize
 [[Category: Compel]]