[BUG][PRIORITY] Fix logic bug that deadlocks the server (from TODO)

[panagiks]

When executing a direct command to Client's OS (through the Execute command), if the execution of the given command is perpetual the Server deadlocks. Also, even if the execution is not perpetual and just takes a lot of time the user is stuck looking at the blank window and waiting for client response (not being able to focus on another client for example). There is currently no way to send a keyboard interrupt. My current idea is to implement a detach feature (This will solve the long waiting time). For the perpetual execution my current approach is to move the client handling of the Execute command in a thread and while it's executing wait for a KILL command from the Server (somewhat like flooding functions are currently handled on the Client side).
The reason this is marked as a priority is that a malicious Client can exploit this to deadlock the Server as soon as the later send it an Exexute command, effectively forcing the PenTester to restart the Server. It's not marked as severe as the later versions of Clients will automatically try to reconnect upon losing the Server so no Client will be lost.

[panagiks]

Development towards fixing this is in fix-deadlock branch. Feel free to join me with suggestions, testing and code :)

[panagiks]

In the current state of the branch the second point (Killing off a perpetual or extremely long execution) has been implemented. Issuing a KeyboardInterupt while waiting for a client response during Execute will result in the Server returning to the command input mode (the same state it was before issuing the Execute command) and the Client returning to its listen/standby mode. The only drawback it that in case the client has produced any feedback it will be lost as the Process is terminated. For example issuing a standard ping command to a Linux Client (where ping is perpetual by default) or a perpetual ping command to a Windows Client and then killing it of by providing a KeyboardInterupt to the Server will present no visible output to the server although some runs of the ping command were executed. This is because of the way commands to the system are called (through Popen) and how data is recovered from Popen (through PIPEs). Will investigate alternatives.

[panagiks]

This branch has been abandoned and is lacking some main changes that are in 0.4.0_rc ...

The good news is that an alternative solution might be available. Instead of .communicate() we can use a non blocking function of POPEN and poll it periodically (say each 0.1 sec). Will look into implementing this asap.