diff --git a/attack_scenarios/Man-in-the-middle_attack/README.md b/attack_scenarios/Man-in-the-middle_attack/README.md
new file mode 100644
index 0000000..35a14b6
--- /dev/null
+++ b/attack_scenarios/Man-in-the-middle_attack/README.md
@@ -0,0 +1,49 @@
+# 2. Man-in-the-middle Attack
+
+## Attack Scenario 1: Intercept and Tamper The File Uploaded to OTA webpages
+
+### Precondition of Attack Scenario
+It is assumed that the attack has successfully changed the proxy server settings of the administrator’s PC (used to upload firmware) to route traffic through the attacker's proxy server.
+
+### Attack Procdure
+1. Assign the proxy server IP address of the administrator’s PC to that of the attacker.
+2. Use tools like Burp Suite to intercept the HTTP packet sent when uploading the firmware file to the OTA server.
+3. Tamper the captured file and send it to the OTA server
+4. Vehicles without authentication mechanisms will download and install the malware.
+---
+
+## Attack Scenario 2: DNS/Proxy Spoofing for Fake Server Redirection 
+
+### Precondition
+Assume that an attacker can compromise a proxy server or DNS server and manipulate its responses to IP address queries.
+
+### Attack Procedure
+1. Assume that the attacker has forged the IP address responded from proxey or DNS,  connect the client directly to the fake MQTT broker or OTA server.
+2. After comfirm the connection and request from targe vehicle, Generate correct packet for the vehicle.
+3. Send the generated malware to the vehicle.
+4.  Vehicles without authentication mechanisms will download and install the malware.
+
+### Additional Scenarios with secure OTA
+
+#### 1. On Server: Using HTTPS(SSL/TLS)
+- We will use a fake CA file injectied on the vehicle.
+- We will perform the activity by injecting the same CA file as the fake server to the client corresponding to the vehicle for the attack scenario
+
+#### 2. On vehicle: Digital sign verification
+- After injecting the vehicle to use the attacker's signature instead of the server's public key
+- To perform the activity, the public key of attacker for the vehicle is performed.
+
+---
+
+## Attack Scenario 3: Packet Interception and Tamperation via Compromised Router
+
+### Precondition
+Assume the attacker has gained control over a router that relays wireless communication, allowing interception and modification of OTA update packets.
+
+### Attack Procedure
+1. Upload the update file via OTA.
+2. Assuming that the router sends packets to the vehicle via the attacker IP, send the file to the attacker IP.
+3. Disguise the attacker IP as the server IP and send it to the vehicle.
+4. Vehicles without authentication mechanisms will download and install the malware.
+
+---
diff --git a/attack_scenarios/Man-in-the-middle_attack/scenario1/README.md b/attack_scenarios/Man-in-the-middle_attack/scenario1/README.md
new file mode 100644
index 0000000..a0fd245
--- /dev/null
+++ b/attack_scenarios/Man-in-the-middle_attack/scenario1/README.md
@@ -0,0 +1,15 @@
+# Attack Scenario 1: Capture OTA webpage to leak and tamper with files
+
+## Attack scenario prerequisites
+Assume that the designated proxy server of the computer (device) used by the administrator to upload firmware has been changed to the attacker's proxy server through hacking.
+
+### How to perform the attack scenario
+1. Assign the IP address of the proxy server of the computer that will perform the update file upload to the attacker's IP address.
+![Screenshot 2025-05-01 123313](https://github.com/user-attachments/assets/d3703274-8741-4da6-a8a5-2a7a4606fa31)
+
+2. Capture the packets transmitted to the server when performing a file upload on the web using a tool such as burf. ![Screenshot 2025-05-01 123507](https://github.com/user-attachments/assets/930ba93e-8924-4cd4-8327-fa45cc5df02c)
+
+3. Transmit the unencrypted file contents from the captured packets by modifying them.
+![Screenshot 2025-05-01 123546](https://github.com/user-attachments/assets/e5ada10a-4d60-4428-8153-cecf15f13a24)
+
+4. Install the malicious file on vehicles without authentication. ![Screenshot 2025-05-01 123714](https://github.com/user-attachments/assets/894f1c63-f3e4-4071-a484-b5f54897da9c)
diff --git a/attack_scenarios/Man-in-the-middle_attack/scenario_PJW/README.md b/attack_scenarios/Man-in-the-middle_attack/scenario_PJW/README.md
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/attack_scenarios/Man-in-the-middle_attack/scenario_PJW/README.md
@@ -0,0 +1 @@
+
diff --git a/attack_scenarios/Man-in-the-middle_attack/scenario_PYL/README.md b/attack_scenarios/Man-in-the-middle_attack/scenario_PYL/README.md
new file mode 100644
index 0000000..28e85a2
--- /dev/null
+++ b/attack_scenarios/Man-in-the-middle_attack/scenario_PYL/README.md
@@ -0,0 +1,125 @@
+# OTA MITM Attack Simulation
+
+This project simulates a Man-In-The-Middle (MITM) attack on an insecure OTA (Over-The-Air) update system. The attacker intercepts and redirects OTA requests, delivering a malicious update file instead of the legitimate one.
+
+## Assumptions
+
+- The attacker has already compromised the proxy server.
+- The vehicle’s communication module makes OTA requests using domain names (e.g., `ota.com`).
+- The proxy server, under the attacker's control, can inspect and modify traffic.
+- The OTA server lacks authentication, integrity checks, and encryption.
+- The vehicle does not verify signatures or hashes on received files.
+
+---
+
+## Attack Scenario (Attacker’s Perspective)
+
+### Step 1: Firmware Update Uploaded to OTA Server (Baseline Assumption)
+- The legitimate OTA server hosts a new firmware file.
+- It is published at a downloadable URL.
+- A notice is sent out that an update is available.
+
+### Step 2: Vehicle Makes OTA Request
+- The vehicle's communication module sends an OTA request to `http://ota.com`.
+- To fetch the file, it needs to resolve the domain to an IP.
+- The attacker intercepts the IP resolution response and replaces it with the attacker’s server IP.
+- From the vehicle’s perspective, `ota.com` now points to the attacker-controlled server.
+
+### Step 3: Attacker Hosts a Fake OTA Server
+- The attacker operates a malicious OTA server that mimics the real one.
+- The fake server responds with a crafted `fake_ota_update.bin`.
+- The file mimics the format of the real update (headers, version, etc.) but contains malicious code.
+- Optionally, the attacker recomputes the hash and signature fields to match the file content.
+- Alternatively, the attacker may deliver an old vulnerable version (rollback attack).
+
+### Step 4: Vehicle Downloads Malicious OTA File
+- The vehicle downloads the file, assuming it’s legitimate.
+- If integrity verification is skipped or bypassed, the malicious update is accepted.
+- The update is passed to the ECU, which applies it without further verification.
+- The attacker gains the ability to remotely control or disrupt the vehicle.
+
+---
+
+## Additional Attack Variants
+
+- **Rollback attack**: Serving outdated vulnerable firmware.
+- **Hash collision attack**: Reusing the same hash in the OTA package.
+- **Fake version metadata**: Tricking version checks by spoofing metadata.
+- **Signed-but-malicious file**: When code signing is not enforced.
+
+---
+
+## Step-by-Step Simulation
+
+### Step 1: Create a Fake OTA Server
+
+```python
+# fake_ota_server.py
+
+from flask import Flask, send_file
+
+app = Flask(__name__)
+
+@app.route("/ota")
+def send_fake_file():
+    return send_file("fake_ota_update.bin", as_attachment=True)
+
+if __name__ == "__main__":
+    app.run(host="0.0.0.0", port=8000)
+```
+
+#### Explanation
+
+- A simple Flask server listens on port 8000.
+- When /ota is accessed, it returns the fake binary file.
+- The .bin file imitates a real OTA update.
+
+### Step 2: Simulate the Vehicle's Communication Module
+
+```python
+# vehicle_module.py
+
+import requests
+
+url = "http://ota.com:8000/ota"
+
+print("[Vehicle] Sending OTA update request...")
+
+response = requests.get(url)
+
+if response.status_code == 200:
+    with open("downloaded_ota.bin", "wb") as f:
+        f.write(response.content)
+    print("[Vehicle] OTA file received! Saved as downloaded_ota.bin")
+else:
+    print("[Vehicle] Failed to download OTA file. Status code:", response.status_code)
+```
+
+#### Explanation
+
+- Sends an HTTP GET request to `http://ota.com:8000/ota`.
+- If successful, saves the file as `downloaded_ota.bin`.
+- Simulates a vehicle blindly trusting the update file.
+
+## Configuration (for local testing)
+### 1. Modify `hosts` file on your machine (Windows only)
+To redirect `ota.com` to your local attacker server:
+1. Run Notepad as Administrator
+2. Open: `C:\Windows\System32\drivers\etc\hosts`
+3. Add the following line:
+```
+127.0.0.1 ota.com
+```
+4. Save and close
+
+## Disclaimer
+This simulation is for educational and research purposes only. Never use these techniques against real vehicles or systems. Always get permission before performing security testing.
+
+## File Structure
+```graphql
+.
+├── fake_ota_server.py        # Fake OTA server (attacker)
+├── vehicle_module.py         # Simulated vehicle requesting the OTA file
+├── fake_ota_update.bin       # Malicious binary (crafted by attacker)
+└── README.md                 # This file
+```
\ No newline at end of file
diff --git a/attack_scenarios/README.md b/attack_scenarios/README.md
new file mode 100644
index 0000000..50b2fd9
--- /dev/null
+++ b/attack_scenarios/README.md
@@ -0,0 +1,93 @@
+# Attack Scenarios
+
+---
+## Attack Proposol
+- The attacker aims to **cause a vehicle accident or gain control of it** by injecting malicious code
+- The attacker aims to **keep the vehicle in a secure or functionally vulnerable state** by interfering with the official OTA
+
+  
+## 1. Supply Chain Attack
+
+### Attack Scenario 1: Malware Update via Official OTA File Upload Webpage [Level 1]
+
+#### Precondition
+Assume that the attacker has obtained the IP address (or domain) of the website where the file is uploaded.
+
+#### Attack Procedure
+1. The attacker creates a .bin file corresponding to the malicious firmware/software to be injected into the target ECU.
+2. The .bin file is uploaded through the official website that uploads OTA files.
+3. Vehicles without authentication install the malicious file.
+---
+
+### Attack Scenario 2: Publishing malicious code or URL to MQTT broker [Level 1]
+
+#### Precondition
+Assume that an authenticated vehicle has been hacked and the IP of the MQTT Broker used by the OEM has been acquired.
+
+#### Attack Procedure
+1. Publish a malicious file or firmware/software download URL to the MQTT broker.
+2. The broker broadcasts the information to all vehicles with matching topics.
+3. Vehicles without authentication install the malicious file.
+---
+
+## 2. Man-in-the-middle Attack
+
+### Attack Scenario 1: Intercept and Tamper The File Uploaded to OTA webpages
+
+#### Precondition of Attack Scenario
+It is assumed that the attack has successfully changed the proxy server settings of the administrator’s PC (used to upload firmware) to route traffic through the attacker's proxy server.
+
+#### Attack Procdure
+1. Assign the proxy server IP address of the administrator’s PC to that of the attacker.
+2. Use tools like Burp Suite to intercept the HTTP packet sent when uploading the firmware file to the OTA server.
+3. Tamper the captured file and send it to the OTA server
+4. Vehicles without authentication mechanisms will download and install the malware.
+---
+
+### Attack Scenario 2: DNS/Proxy Spoofing for Fake Server Redirection 
+
+#### Precondition
+Assume that an attacker can compromise a proxy server or DNS server and manipulate its responses to IP address queries.
+
+#### Attack Procedure
+1. Assume that the attacker has forged the IP address responded from proxey or DNS,  connect the client directly to the fake MQTT broker or OTA server.
+2. After comfirm the connection and request from targe vehicle, Generate correct packet for the vehicle.
+3. Send the generated malware to the vehicle.
+4.  Vehicles without authentication mechanisms will download and install the malware.
+
+#### Additional Scenarios with secure OTA
+
+##### 1. On Server: Using HTTPS(SSL/TLS)
+- We will use a fake CA file injectied on the vehicle.
+- We will perform the activity by injecting the same CA file as the fake server to the client corresponding to the vehicle for the attack scenario
+
+##### 2. On vehicle: Digital sign verification
+- After injecting the vehicle to use the attacker's signature instead of the server's public key
+- To perform the activity, the public key of attacker for the vehicle is performed.
+
+---
+
+### Attack Scenario 3: Packet Interception and Tamperation via Compromised Router
+
+#### Precondition
+Assume the attacker has gained control over a router that relays wireless communication, allowing interception and modification of OTA update packets.
+
+#### Attack Procedure
+1. Upload the update file via OTA.
+2. Assuming that the router sends packets to the vehicle via the attacker IP, send the file to the attacker IP.
+3. Disguise the attacker IP as the server IP and send it to the vehicle.
+4. Vehicles without authentication mechanisms will download and install the malware.
+
+---
+
+## 3. Replay Attack
+
+### Attack Scenario 1: Reuse Previous Update Packet
+
+#### Precondition
+Assume that the vehicle is connected to the fake MQTT broker. So the attacker can try to update malware at anytime
+#### Attack Prcedure
+1. Capture and store normal packets from the another OTA target.
+2. Assuming that vulnerabilities in the past version have been fixed by the new version, update the past version of the file through a fake MQTT broker.
+3. The vehicle installs the packet due to insufficient message freshness verification.
+---
diff --git a/attack_scenarios/replay_attack/README.md b/attack_scenarios/replay_attack/README.md
new file mode 100644
index 0000000..45c1ced
--- /dev/null
+++ b/attack_scenarios/replay_attack/README.md
@@ -0,0 +1,11 @@
+# 3. Replay Attack
+
+## Attack Scenario 1: Reuse Previous Update Packet
+
+### Precondition
+Assume that the vehicle is connected to the fake MQTT broker. So the attacker can try to update malware at anytime
+### Attack Prcedure
+1. Capture and store normal packets from the another OTA target.
+2. Assuming that vulnerabilities in the past version have been fixed by the new version, update the past version of the file through a fake MQTT broker.
+3. The vehicle installs the packet due to insufficient message freshness verification.
+---
diff --git a/attack_scenarios/supply_chain_attack/README.md b/attack_scenarios/supply_chain_attack/README.md
new file mode 100644
index 0000000..2088949
--- /dev/null
+++ b/attack_scenarios/supply_chain_attack/README.md
@@ -0,0 +1,23 @@
+# 1. Supply Chain Attack
+
+## Attack Scenario 1: Malware Update via Official OTA File Upload Webpage [Level 1]
+
+### Precondition
+Assume that the attacker has obtained the IP address (or domain) of the website where the file is uploaded.
+
+### Attack Procedure
+1. The attacker creates a .bin file corresponding to the malicious firmware/software to be injected into the target ECU.
+2. The .bin file is uploaded through the official website that uploads OTA files.
+3. Vehicles without authentication install the malicious file.
+---
+
+## Attack Scenario 2: Publishing malicious code or URL to MQTT broker [Level 1]
+
+### Precondition
+Assume that an authenticated vehicle has been hacked and the IP of the MQTT Broker used by the OEM has been acquired.
+
+### Attack Procedure
+1. Publish a malicious file or firmware/software download URL to the MQTT broker.
+2. The broker broadcasts the information to all vehicles with matching topics.
+3. Vehicles without authentication install the malicious file.
+---