sliver
sliver copied to clipboard
BishopFox
"safer" keyboard interactions
If you hit control-c it it will exit the server. it doesn't look like there's a way to 'background a shell', kind of like one would expect using meterpreter (where exit will actually kill the shell, bg will background it and leave it running and return you to the menu)
if a migrate command takes too long, and you hit control-c, it exits all of sliver versus stopping the migrate command
tl;dr - it would be nice if there was a clear way to go back to the main menu inside of sliver, and if there were ways to "stop an operation in progress" without killing the server.
It's an issue we have on the backlog, there's sort of a workaround for it: use the multiplayer mode and connect to the server using the client. That way if you accidentally kill the client by sending a SIGINT signal, you can still relaunch it, the server won't be impacted.
The core of the issue is a mix of UI issue and design:
- the spinner we use hijacks the UI lib we use (grumble), and does not catch the sigint signal
- we currently do not have a way to cancel a running job, which means even if the spinner issue would be fixed, sending SIGINT would not do what the user expects it would (canceling the taks/job)
When we'll find the time to work around those, we'll surely push an update. Feel free to submit a PR though :)
As for the background mode in shell, I've been thinking about it a lot, but right now the way the shell command operates doesn't give us insights into what the user types, so we can't catch a specific "magic" command like background or a signal like SIGSTOP (CTRL + Z) and put the shell in background.
When I have too many windows open I can't tell from the prompt if I am on the server console, or a client session. Propose client shell ${player}-sliver >
Hmm, how's this, instead of the player name to indicate the server console vs. normal console:
https://github.com/BishopFox/sliver/pull/455
Prepping for a competition and just saw this went in. A user can now better understand the impact of the ctrl+c, I would consider this issue closed.
With the recent reorg of the client code, I think we can also add a reliable SIGINT handler to the animation code.