Feature bettercap

.github/workflows/python-publish.yml

@@ -32,4 +32,3 @@ jobs:
       run: python -m build
     - name: Publish package distributions to PyPI
       uses: pypa/gh-action-pypi-publish@release/v1
-

.pre-commit-config.yaml

@@ -31,7 +31,11 @@ repos:
     - id: autopep8
       args: [--max-line-length=110, --diff]
 
-
+        #-   repo: https://github.com/astral-sh/uv-pre-commit
+        #    # uv version.
+        #    rev: 0.8.12
+        #    hooks:
+        #      - id: uv-lock
       # PROBLEMS WITH IMPORTS IN PYLINT!!!
       #-   repo: https://github.com/PyCQA/prospector
       #    rev: 1.10.0 # The version of Prospector to use, if not 'master' for latest

docs/source/configuration/bettercap_config.rst

@@ -0,0 +1,62 @@
+.. _bettercap_config:
+
+================
+bettercap_config
+================
+
+bettercap_config holds settings for the Bettercap rest-api. The configuration
+always starts with an identifier for the connection. This identifier can be
+selected when executing a command in a playbook. The first connection in this
+file is the default if no explicit connection was selected in the command.
+
+.. code-block:: yaml
+
+   ###
+   bettercap_config:
+     default:
+       url: "http://localhost:8081"
+       username: user
+       password: password
+     remote:
+       url: "http://remote.host.tld:8081"
+       username: btrcp
+       password: somepass
+
+.. code-block:: yaml
+
+   # bettercap-playbook.yml:
+   commands:
+     # this is executed on the remote host:
+     - type: bettercap
+       cmd: post_api_session
+       data:
+         cmd: "net.sniff on"
+       connection: remote
+     # this is executed on localhost:
+     - type: bettercap
+       cmd: get_events
+
+
+.. confval:: url
+
+   This option stores the url to the rest-api
+
+   :type: str
+
+.. confval:: username
+
+   The http basic username for the rest-api
+
+   :type: str
+
+.. confval:: password
+
+   The http basic password for the rest-api
+
+   :type: str
+
+.. confval:: cafile
+
+   The path to the ca-file for the encryption if https is in use.
+
+   :type: str

docs/source/configuration/index.rst

@@ -15,6 +15,7 @@ The optional configuration-file is in yaml-format and is divided into three sect
 
 * **cmd_config**: defines settings for all commands
 * **msf_config**: connection settings for the msfrpcd
+* **bettercap_config**: connection settings for the bettercap rest-api
 * **sliver_config**: connection settings for the sliver-api
 
 The following configuration file is an example for a basic configuration with
@@ -27,6 +28,12 @@ sliver and metasploit:
      loop_sleep: 5
      command_delay: 0
 
+   bettercap_config:
+     default:
+       url: "http://localhost:8081"
+       username: user
+       password: password
+
    msf_config:
      password: securepassword
      server: 127.0.0.1
@@ -41,5 +48,6 @@ For detailed information about the config sections see:
 
    config_vars
    command_config
+   bettercap_config
    msf_config
    sliver_config

docs/source/developing/baseexecutor.rst

@@ -6,7 +6,7 @@ Adding a New Executor
 Base Executor
 ================
 
-The ``BaseExecutor`` is the core class from which all executors in AttackMate inherit.  
+The ``BaseExecutor`` is the core class from which all executors in AttackMate inherit.
 It provides a structured approach to implementing custom executors.
 
 Key Features
@@ -64,8 +64,8 @@ Overridable Methods
 
 The following methods can be overridden in custom executors to modify behavior:
 
-**Command Execution**  
-   
+**Command Execution**
+
 .. code-block:: python
 
     def _exec_cmd(self, command: BaseCommand) -> Result:
@@ -74,24 +74,21 @@ The following methods can be overridden in custom executors to modify behavior:
 This is the core execution function and must be implemented in subclasses.
 It should return a ``Result`` object containing the execution outcome.
 
-.. note:: 
+.. note::
 
-    The ``_exec_cmd()`` method **must** be implemented in any subclass of ``BaseExecutor``.  
-    This method defines the core execution logic for the command and is responsible for returning a ``Result`` object.  
+    The ``_exec_cmd()`` method **must** be implemented in any subclass of ``BaseExecutor``.
+    This method defines the core execution logic for the command and is responsible for returning a ``Result`` object.
 
 
-**Logging Functions**  
+**Logging Functions**
 
 The methods ``log_command``, ``log_matadata`` and ``log_json`` log command execution details and can be overridden for custom logging formats.
 
-**Command Execution Flow**  
+**Command Execution Flow**
 
 The ``run()`` method defines the high-level execution flow of a command.
 It includes condition checking, logging, and calling the actual execution logic.
 
-**Output Handling**  
+**Output Handling**
 
 The ``save_output()`` function manages saving output to a file. It can be overridden to implement alternative storage methods.
-
-
-

docs/source/developing/command.rst

@@ -4,14 +4,14 @@
 Adding a New Command
 ======================
 
-AttackMate supports extending its functionality by adding new commands. 
+AttackMate supports extending its functionality by adding new commands.
 This section details the steps required to integrate a new command.
 
 
 1. Define the Command Schema
 =============================
 
-All Commands in AttackMate inherit from ``BaseCommand``.  
+All Commands in AttackMate inherit from ``BaseCommand``.
 To create a new command, define a class in `/src/attackmate/schemas` and register it using the ``@CommandRegistry.register('<command_type>')`` decorator.
 
 For example, to add a ``debug`` command:
@@ -21,7 +21,7 @@ For example, to add a ``debug`` command:
     from typing import Literal
     from .base import BaseCommand
     from attackmate.command import CommandRegistry
-    
+
     @CommandRegistry.register('debug')
     class DebugCommand(BaseCommand):
         type: Literal['debug']
@@ -30,7 +30,7 @@ For example, to add a ``debug`` command:
         wait_for_key: bool = False
         cmd: str = ''
 
-Registering the command in the ``CommandRegistry`` allows the command to be also instantiated dynamically using the ``Command.create()`` method and is essential to 
+Registering the command in the ``CommandRegistry`` allows the command to be also instantiated dynamically using the ``Command.create()`` method and is essential to
 make them usable in external python scripts.
 
 
@@ -53,16 +53,16 @@ The new command should be handled by an executor in `src/attackmate/executors``
 
 3. Ensure the Executor Handles the New Command
 ==============================================
- 
-The ``ExecutorFactory`` class manages and creates executor instances based on command types.  
+
+The ``ExecutorFactory`` class manages and creates executor instances based on command types.
 It maintains a registry (``_executors``) that maps command type strings to executor classes, allowing for dynamic execution of different command types.
-Executors are registered using the ``register_executor`` method, which provides a decorator to associate a command type with a class.  
+Executors are registered using the ``register_executor`` method, which provides a decorator to associate a command type with a class.
 When a command is executed, the ``create_executor`` method retrieves the corresponding executor class, filters the constructor arguments based on the class's signature, and then creates an instance.
 
-Accordingly, executors must be registered using the ``@executor_factory.register_executor('<command_type>')`` decorator. 
+Accordingly, executors must be registered using the ``@executor_factory.register_executor('<command_type>')`` decorator.
 
-If the new executor class requires additional initialization arguments, these must be added to the ``_get_executor_config`` method in ``attackmate.py``. 
-All configurations are always passed to the ``ExecutorFactory``.  
+If the new executor class requires additional initialization arguments, these must be added to the ``_get_executor_config`` method in ``attackmate.py``.
+All configurations are always passed to the ``ExecutorFactory``.
 The factory filters the provided configurations based on the class constructor signature, ensuring that only the required parameters are used.
 
 ::
@@ -93,7 +93,7 @@ Update the ``LoopCommand`` schema to include the new command.
             DebugCommand,  # Newly added command
             # ... other command classes ...
         ]
-    
+
 
 5. Modify playbook.py to Include the New Command
 =====================================================
@@ -116,10 +116,3 @@ Once these steps are completed, the new command will be fully integrated into At
 =====================
 
 Finally, update the documentation in `docs/source/playbook/commands` to include the new command.
-
-
-
-
-
-
-

docs/source/developing/integration.rst

@@ -101,4 +101,4 @@ The return code can be used to determine if the command was successful:
     if result.returncode == 0:
         print("Command executed successfully.")
     else:
-        print(f"Command failed with return code {result.returncode}")
+        print(f"Command failed with return code {result.returncode}")

docs/source/installation/uv.rst

@@ -59,4 +59,4 @@ Installation Steps
 .. warning::
 
    Please note that you need to :ref:`sliver-fix` if you want
-   to use the sliver commands!
+   to use the sliver commands!