GUI to Server Interaction

2. Description

image004
Pic 2.1.

When EAST framework user connects to the web interface (GUI ) and loads appropriate content, that triggers an “event”  which causes the webServer to connect to websocket main Server.

Right after successfull connection, the command «get_all_server_data» is generated.

After the receiption of that command the Server collects all modules data,  which contains in the INFO dict  of each module.

There is a PATH key in the Info dict which represents module path. The modules GUI tree is generated based on that keys.

The main server script – start.py also defines framework version. All that info influences the generation of the tree.

After the initial tree generation the «restore_tabs» command is sent to already started modules ( exploits or tools), listeners – so that all the information could be displayed in GUI and to make available correct interaction between Server and modules.  GUI is also responsible for modules management and messages logging/displaying.

2.1. Web Interface

image006
Pic. 2.2.  GUI.

1) http address;
2) reconnect button (shows current connection state);
3) field for default target “host and port” used for current exploit;
4) exploits search field;
5) Button to start “on the fly” editor for chosen exploit;
6) Modules Tree;
7) Info about selected module;
8) Module Tab (with color showing the state of the module);
9) Messages received from the module;
10) Messages received from the Listener;
11) Commands to be sent to the Listener.

2.2. Modules launching.

After the double clicking the module, – GUI sends the Server a query in order to receive available module options. Query structure:

image008

,  module_name – module name for which we are going to receive options. Server responds with the following structure:

image010

With the help of such options GUI  displays appropriate dialog window (pic. 2.3).

image012

Pic. 2.3. Module options dialog window. 1) Checkbox for listener 2) Modules options

Exploit developers could set appropriate option types, which will be displayed  as more complex dialog windows.  More info about complex option types could be found in developers section of the Manual.

After [Run] buttton is pressed GUI sends the following command with parameters:

image014

  1. module_name, 2. isListenerEnabled , 3. options – dict with keys being option names, and values defined from GUI ( pic.2.3.).

Server executes each module as a separate process, and also start listener if needed. Options are stored inside the memory of each process. Module and server always have access to stored options (see Developers Manual ).

Each started module has its own Data structure (pic. 2.4). This structure could be accessed from outside the process by PID or module name:

image016
Pic. 2.4. Module data structure.

Pic 2.4.:

  • module_name – uniqe module name, which Server sets for each launched module. In case of several instances of the same module there is a suffix «(n)», which corresponds to the number of the instances.
  • shown_name – originally shown name.
  • process – Process instance which is started with subprocess.Popen() It is possible to kill the process at any time.
  • pid – PID .
  • options – modules options to be set from GUI. These options are used by modules to define internal parameters.
  • log – list structure. Contains ModuleMessageElement class, with 2 attributes: time and message. Examples of such class are created when module sends message to the Server.
  • state – Current modules stage: None – keep running, True – finished succsessfully, False – failed
  • new_messages – True if there are new messages from that module waiting to be sent to GUI; False – no new messages.

After the module start the Server sends the following command to GUI (webserver):

image018

, module_name – unique module name, listener – variable which defines whether to show Listener window in GUI or not.

After the receiption of that command GUI starts timer and then «status» command without arguments (once per 300 ms).

Server collects the data from all started modules (pic. 2.4) stores it in the from of dict, with keys being module names. If module is started with Listener, dictionary also contains info about its Listener instance.

When module Tab is closed in the GUI, Server sends command «kill_process» with «module_name» argument.