Documentation improvement

doc/README.md

@@ -29,4 +29,49 @@ Alternatively, in station mode, the device attempts to join an existing network
 ### Access the Testbed
 First **connect in AP mode** to access the different applications running on the system.
 
+## Virtual Environment
+As a requriement docker and docker compose needs to be setup on the system.
+
+### Option 1: Run within VS Code / Codium Devcontainer
+VS Code oder Codium is required for this method.
+After starting VS Code / Codium, you are asked to open the git project in a container.
+By selecting CybICS-Virtual, the virtual CybICS is started.
+
+<table align="center"><tr><td align="center" width="9999">
+<img src="pics/virtualCode.png" width=99%></img>
+</td></tr></table>
+
+### Option 2: Run within Terminal
+Switch to the location of the docker compose file.
+```sh
+cd CybICS/.devcontainer/virtual
+```
+
+Start the containers.
+```sh
+sudo docker compose up
+```
+
+The output should look like the following:
+<table align="center"><tr><td align="center" width="9999">
+<img src="pics/dockerCompose.png" width=99%></img>
+</td></tr></table>
+
+With CTRL+C, the containers can be stopped again.
+
+
+### Access to the Virtual CybICS
+The applications provide a webinterface for monitoring and configuration.
+
+| What              | link/url                                         |
+|-------------------|--------------------------------------------------|
+| Physical process  | [http://localhost/](http://localhost/)           |
+| OpenPLC           | [http://localhost:8080/](http://localhost:8080/) |
+| FUXA HMI          | [http://localhost:1881/](http://localhost:1881/) |
+
+
+Example of the virtual physical process (same represenation as the PCB).
+<table align="center"><tr><td align="center" width="9999">
+<img src="pics/virtual.png" width=80%></img>
+</td></tr></table>
 

training/flood_overwrite/README.md

@@ -3,17 +3,51 @@ A flooding attack in an industrial security context can have devastating consequ
 By overwhelming industrial control systems (ICS) or Supervisory Control and Data Acquisition (SCADA) networks with excessive traffic, attackers can cause delays or complete halts in manufacturing processes, energy distribution, or other essential industrial functions.
 These disruptions can lead to significant financial losses, damage to equipment, and potential safety hazards for workers and the surrounding community.
 
+In this scenario, an attacker is continuously flooding the Modbus server (e.g., a PLC) with malicious commands to override a specific register value.
+
+```
+Client       Attacker           PLC (Server)
+   |            |                      |
+   |            |  Floods              |
+   |            |  Write Command       |
+   |            |  (Register X = 0)    |
+   |            |  --------------------> 
+   |            |                      |
+   |            |  Floods              |
+   |            |  Write Command       |
+   |            |  (Register X = 0)    |
+   |            |  -------------------->
+   |            |                      |
+   |            |   Override           |
+   |            |   Register X         |
+   |            |  (Continuously)      |
+   |            |  -------------------->
+```
+
+How this works:
+- The Attacker floods the PLC (Modbus server) with write commands targeting a specific Modbus register (e.g., Register X).
+- The attacker's command overrides the correct value of Register X, continuously forcing it to a specific value (e.g., 0).
+- This continuous flood makes it impossible for the legitimate Client to write or control the register normally.
+
+The attacker’s goal is to override the register and control the behavior of the device by continuously sending malicious write commands to the PLC.
+
+### Spoofing
 Spoofing a Modbus register involves an attacker sending fraudulent data to a Modbus device, tricking it into believing the data is legitimate.
 This type of attack can severely disrupt industrial processes by manipulating the readings or settings of critical devices such as sensors, actuators, or controllers.
 For instance, an attacker could alter temperature or pressure readings, causing a system to operate outside safe parameters, potentially leading to equipment damage or safety hazards.
 
+
+### Example
+
 The provided script `flooding_hpt.py` floods via modbus the high pressure tank (HPT) values to 10.
 With this flooding, the OpenPLC does not get the correct values and enables the compressor (C) all the time.
 This is leading to a critical pressure value in the HPT.
 
 The script uses the `.dev.env` file in the root folder of the git.
 Check if these settings are correct, before executing the flooding script.
 
+A basic understanding of Modbus/TCP is required for this example.
+
 
 <details>
   <summary><strong><span style="color:orange;font-weight: 900">Solution</span></strong></summary>

training/mitm/README.md

@@ -3,6 +3,33 @@
 This guide explains how to create a Modbus TCP proxy in Python that listens on all network interfaces (0.0.0.0).
 The proxy intercepts Modbus traffic between a Modbus client and a Modbus server, allowing you to manipulate the traffic (requests and responses) like a "man-in-the-middle" attack.
 
+
+### Man-in-the-Middle with an Attack Proxy
+A Man-in-the-Middle (MITM) attack is a type of cyberattack where a malicious actor secretly intercepts and possibly alters the communication between two parties, without either party realizing it. In the context of Modbus TCP, a widely used protocol in industrial control systems (ICS) for communication between controllers (like PLCs) and devices (like sensors or actuators), a MITM attack can be particularly dangerous.
+
+Explanation of a Man-in-the-Middle Attack with Modbus TCP:
+Modbus TCP works over a TCP/IP network and follows a client-server model, where:
+
+Client (usually the Human-Machine Interface (HMI) or SCADA system) sends Modbus requests (like read/write commands) to control devices.
+Server (typically a Programmable Logic Controller (PLC) or other field devices) responds to these commands.
+In a MITM attack on Modbus TCP, an attacker positions themselves between the client and the server to intercept and manipulate Modbus requests and responses.
+
+```
+Client     Attacker (Proxy)  Server
+   |            |              |
+   |----->      |              |
+   |            |----->        |
+   |            |<-----        |
+   |<-----      |              |
+```
+
+This shows the basic flow:
+- Client sends a request (----->) to the Attacker (posing as the server).
+- Attacker forwards the request to the Server.
+- Server responds (<-----) to the Attacker.
+- Attacker potentially modifies and sends the response back to the Client.
+
+
 ### Prerequisite: Admin Access on FUXA HMI
 Before setting up the Python proxy for intercepting Modbus traffic, you need administrator access on the FUXA HMI. This is necessary to modify the IP settings of the connected PLC, directing its communication through the Python proxy.
 
@@ -15,6 +42,8 @@ With admin access, you'll be able to change the PLC's configuration to use the p
 ### Example
 An example of this proxy can be found in the mitm.py file. 
 However, it does not modify or manipulate any values that are meaningfull by default, allowing the proxy to only focus on significant traffic changes. You can easily extend it to customize the manipulations as needed for your specific use case.
+For this, a good understanding of Modbus/TCP is required.
+
 ```sh
 python3 mitm.py
 ```