sesh = silent exploitation shell | security engineering shell | super epic shell | stealth espionage shell | standalone execution shell | sexy encrypted shell
- 
fully modular - enable/disable any feature at compile or runtime 
- 
total disregard foractive leveraging of established conventions
- 
does not touch disk without you knowing about it 
- 
read and write files without changing metadata 
- 
assume the identity of an already running process (or whatever you want it to be) 
- 
in-memory command history 
- 
embed arbitrary files in the binary for later use 
- 
configuration can be saved as a short string, which can be loaded with ease 
- 
built in enumeration scripts 
- 
spoof running time (may need root) 
- 
something like a cooler version of moonwalk 
- 
ignore SIGHUP (and/or other signals) 
- 
cool udp and tcp revshell capability, which when combined with the previous feature, means you can ssh (or whatever) to a target, run sesh, close ssh connection, and then reconnect via a more stealthy route (alla pwncat) 
- 
send random data to random (or not so random) ip addresses to cover communications 
- 
many useful tools built in, don't need to run binaries from disk, such as: - cat, base64, zip, tar, netcat, nano, ls, find, grep, wget, su, env, chmod, chown, chgrp, getcap, setcap, etc
- (note that most of these will be replaced with cool rewrites, i.e. ls->exa, find->bfs, etc. will be kinda like busybox but more based.)
- might also just chuck python in there
 
- 
run executables from memory, from network, or even local binaries with or without +x set - not sure if I can do this, but optimally, given a binary in any of the above forms, you would be able to execute them with userland exec without overwriting the original sesh process, i.e imagine you are in a sesh session, and you run silentexec /bin/ls, this would read thelsbinary, execute it with userland exec, show you the output, then return you to your sesh session, all without starting or stopping any processes at all!
- ok I thought a bit more about the above idea, and I think I can basically (before sesh performs a userland exec) patch the target binary (in memory) in such a way that rather than exiting post-execution, it instead would itself perform a userland exec to get back to sesh. This would mean losing whatever state sesh was previously in though, which might be a problem, but I could probably save the state and restore it using a method similar to that used by CryoPID.
- alternatively perhaps I should basically somehow spin up a userland virtual machine sort of thing. I'll have to investigate that avenue.
- less cool version: through the use of memfd, like this
 
- not sure if I can do this, but optimally, given a binary in any of the above forms, you would be able to execute them with userland exec without overwriting the original sesh process, i.e imagine you are in a sesh session, and you run 
- 
ability to start a process as a child of some arbitrary process (cursed+hard), or maybe something like this to start the process inside another process without causing any issues with the original process 
- 
awesome backdooring using a project I haven't started writing yet, which involves infecting preexisting executables with a self-replicating security flaw (thanks Johnny!) 
Warning
Written in Go!!!