यह उस फ़िंगरप्रिंट से काफी अलग है जो Chrome तब उत्पन्न करता है जब आप URL पर सीधे जाते हैं:```
ge11cn19enus_f2808f0d04cf_9a10d4221160_7068f58def6e

(यही बात हमारे JA4 TLS फिंगरप्रिंट पर भी लागू होती है, आदि).

## सेटअप

Ubuntu 22.04 पर एक कंटेनरीकृत Chrome इंस्टेंस के माध्यम से आपके ट्रैफ़िक को छुपाने वाले `thermoptic` प्रॉक्सी को शुरू करने के लिए:

नियमित Docker सेटअप (बिना GPU रनटाइम वाले होस्ट पर काम करता है):```
docker compose up --build

महत्वपूर्ण नोट्स:
* डिफ़ॉल्ट रूप से प्रॉक्सी बिना प्रमाणीकरण के चलता है। यदि आप प्रॉक्सी को बाहरी रूप से एक्सपोज़ करने की योजना बना रहे हैं तो कृपया `PROXY_USERNAME` और `PROXY_PASSWORD` environment variables के साथ प्रमाणीकरण सेट करना सुनिश्चित करें।
* यदि आप `---insecure` उपयोग नहीं करना चाहते हैं तो आपको `./ssl/rootCA.crt` में स्थित जनरेटेड CA फ़ाइल का उपयोग करना होगा। यह पहली बार जब आप `thermoptic` चलाते हैं तो जनरेट होती है।
* आप `thermoptic` को `--remote-debugging-port` फ़्लैग के साथ लॉन्च किए गए किसी भी Chrome/Chromium इंस्टेंस से कनेक्ट कर सकते हैं। यह आवश्यक है क्योंकि आप अधिक सामान्य वातावरणों के माध्यम से प्रॉक्सी सेट करना चाहेंगे ताकि आपका फ़िंगरप्रिंट यथासंभव कम प्रोफ़ाइल वाला रहे (जैसे Windows पर Chrome)।
* GPU compose override उन NVIDIA होस्ट्स के लिए है जिनके पास पहले से Docker का NVIDIA runtime/toolkit इंस्टॉल है। यह GPU डिवाइस को रिज़र्व करता है, `/dev/dri` को माउंट करता है, और बंडल किए गए Chrome कंटेनर को NVIDIA/Vulkan रेंडरिंग पथ पर स्विच करने देता है। इसका उपयोग करने के लिए, `docker compose -f docker-compose.yml -f docker-compose.gpu.yml up --build` चलाएँ।

## सुविधाएँ

- 🕵️ [ब्राउज़र-समानता प्रॉक्सिंग](#how-does-this-cloaking-work-exactly) जो अनुरोधों को एक वास्तविक Chrome सत्र के माध्यम से दोहराती है ताकि JA4 फ़िंगरप्रिंट बाइट-दर-बाइट मेल खा सकें।
- 🤝 अपने HTTP क्लाइंट (जैसे `curl`, `requests`, आदि) को `thermoptic` के साथ एकीकृत करने के लिए बहुत कम या कोई कस्टम कोड आवश्यक नहीं है, बस [प्रॉक्सी सेट करें](#setup) और आपके फ़िंगरप्रिंट का ध्यान रखा जाता है।
- 🪝 [हुक फ्रेमवर्क](#handling-browser-javascript-fingerprinting-with-thermoptic-hooks) before-request/after-request/on-start स्वचालन के लिए, ताकि आप पूरे ब्राउज़र को चुनौतियाँ हल करने या आर्टिफैक्ट कैप्चर करने के लिए चला सकें।
  - 📘 एक उदाहरण Cloudflare turnstile सॉल्विंग हुक [`./hooks/onstart.js`](https://github.com/mandatoryprogrammer/thermoptic/blob/main/hooks/onstart.js) में देखा जा सकता है।
- 🖥️ [वेब-ब्राउज़र नियंत्रण UI](#control-the-dockerized-chrome-browser-via-web-ui-xpra) (`http://127.0.0.1:14111` पर) Dockerized Chrome ब्राउज़र विंडो को नियंत्रित करने के लिए। साइटों में मैन्युअल रूप से लॉग इन करने और फिर अपने लॉग-इन सत्र के रूप में अनुरोध करने के लिए प्रॉक्सी का निर्बाध रूप से उपयोग करने के लिए उपयोगी (और डीबगिंग के लिए)।
- 🔌 `docker-compose.yml` में `UPSTREAM_PROXY` environment variable के माध्यम से एक अपस्ट्रीम HTTP या SOCKS प्रॉक्सी URI सेट करें।
- 🛡️ बिल्ट-इन स्वास्थ्य जाँच और रीस्टार्ट नियंत्रण लूप जो फ्रोज़न ब्राउज़रों का पता लगाता है और ऑपरेटर की निगरानी के बिना स्वचालित रूप से पुनर्प्राप्त करता है।
- ⚡ HTTP/1.1 और HTTP/2 का समर्थन करता है, जिससे ट्रैफ़िक को किसी भी प्रोटोकॉल पर प्रॉक्सी किया जा सकता है। (_ध्यान दें कि आप प्रॉक्सी से HTTP/1.1 पर बात कर सकते हैं, और नियंत्रित Chrome अंतिम साइट के साथ किसी भिन्न प्रोटोकॉल पर बातचीत कर सकता है।_)

## यह क्लोकिंग वास्तव में कैसे काम करती है?

![Visual diagram example](https://assets.kitploit.com/production/public/readmes/49068/f95c08eccfdbfce1b14513f2a5ad2a33a9b0fb0bd6851a2d005aedf4ff196338.png)

* एक HTTP अनुरोध किसी HTTP क्लाइंट जैसे `curl` का उपयोग करके किया जाता है, जिसमें `thermoptic` को प्रॉक्सी के रूप में सेट किया गया होता है।
* `thermoptic` यह निर्धारित करने के लिए अनुरोध का विश्लेषण करता है कि यह किस प्रकार का ब्राउज़र अनुरोध होना चाहिए (जैसे मैन्युअल URL विज़िट? फ़ॉर्म सबमिशन? एक `fetch()` अनुरोध?)।
* `thermoptic` [Chrome Debugging Protocol (CDP)](https://chromedevtools.github.io/devtools-protocol/) का उपयोग करके ब्राउज़र को नियंत्रित करता है और एक ऐसा पेज सेट करता है जो अनुरोध को बिल्कुल उसी तरह नकली बनाता है जैसे वह वास्तविक वेब ब्राउज़र में सामान्य रूप से होता है।
* `thermoptic` नकली संदर्भ के माध्यम से अनुरोध को ट्रिगर करता है और HTTP प्रतिक्रिया कैप्चर करता है।
* `thermoptic` HTTP प्रतिक्रिया को क्लाइंट को वापस भेजता है।

चूँकि ब्राउज़र वास्तव में अपने पूरे स्टैक का उपयोग करके अनुरोध कर रहा है, परिणामी JA4 फ़िंगरप्रिंट समान होते हैं।

नोट: कई WAFs द्वारा वेब ब्राउज़रों की JavaScript-स्तरीय फ़िंगरप्रिंटिंग का उपयोग करने के कारण, `thermoptic` स्क्रैपिंग प्रक्रिया के प्रमुख चरणों के लिए ब्राउज़र का उपयोग करने हेतु हुक भी उजागर करता है। इस पर अधिक जानकारी के लिए [यह अनुभाग](#handling-browser-javascript-fingerprinting-with-thermoptic-hooks) देखें।

## यह *दृष्टिकोण* अन्य समाधानों से बेहतर क्यों है?

सीधे शब्दों में कहें तो: अन्य दृष्टिकोणों में मूलभूत खामियाँ हैं जो उन्हें ब्राउज़र फ़िंगरप्रिंटिंग समस्या के व्यावहारिक दीर्घकालिक समाधान होने से रोकती हैं।

ब्राउज़र JA4+ फ़िंगरप्रिंटिंग को "हराने" के कई अन्य प्रयास ब्राउज़र स्टैक की विभिन्न परतों को फिर से लागू करके ऐसा करते हैं। इस दृष्टिकोण के कई गंभीर नुकसान हैं, जैसे:

* "वास्तविक" ब्राउज़र कार्यान्वयन के व्यवहार से पूरी तरह मेल खाने के लिए अत्यधिक सावधानी की आवश्यकता होती है। परिणामस्वरूप, *कोई भी* विचित्रता या विसंगति इन क्लाइंट्स को "वास्तविक" ब्राउज़र कार्यान्वयन से अलग करने के लिए उपयोग की जा सकती है।
* समस्या को केवल स्टैक की एक परत पर हल करने का प्रयास। Chrome वेब ब्राउज़िंग अनुभव प्रदान करने के लिए कई प्रोटोकॉल का उपयोग करता है। परिणामस्वरूप, भले ही आपने पूरी तरह मेल खाती TLS परत बना ली हो, यदि आपकी HTTP परत बाइट-परफेक्ट नहीं है तो यह आपको उजागर कर सकती है।
* जैसे-जैसे "वास्तविक" ब्राउज़र नियमित रूप से अपना व्यवहार बदलते हैं, उनके फ़िंगरप्रिंट बदलते हैं, और परिणामस्वरूप इन उपकरणों को क्षतिपूर्ति करने के लिए लगातार अधिक गहन विकास कार्य की आवश्यकता होती है।

इसके विपरीत, क्योंकि `thermoptic` HTTP अनुरोध करने के लिए स्वयं ब्राउज़र का उपयोग करता है:
* TCP, TLS, HTTP जैसी स्टैक की प्रत्येक परत वास्तविक ब्राउज़र से अप्रभेद्य होती है क्योंकि अनुरोध *वास्तविक* ब्राउज़र का उपयोग करके उस तरह से किया जाता है जैसे वह *सामान्य रूप से* होता है।
* विभिन्न परतों पर ब्राउज़र व्यवहार में परिवर्तन न्यूनतम विघटनकारी होते हैं, फ़िंगरप्रिंट के नवीनतम सेट से मेल खाने के लिए केवल `thermoptic` द्वारा नियंत्रित ब्राउज़र को अपडेट करने की आवश्यकता होती है।

बेशक, कोई भी समाधान खामियों से मुक्त नहीं है। `thermoptic` दृष्टिकोण के नुकसानों की एक विस्तृत सूची के लिए `DOWNSIDES.md` दस्तावेज़ देखें।

## FAQ

### `thermoptic` नाम क्यों?

"Thermoptic" ("thermoptic camouflage" के लिए संक्षिप्त) [Ghost in the Shell (1995) एनीमे में Major द्वारा उपयोग किए जाने वाले] (https://ghostintheshell.fandom.com/wiki/Thermoptic_camouflage) काल्पनिक छलावरण का संदर्भ है। फ़िल्म में, यह छलावरण पहनने वाले को दृश्य प्रकाश और तापीय विकिरण दोनों सहित कई पहचान स्पेक्ट्रमों में छिपाने में सक्षम दिखाया गया है। इसी तरह, यह उपकरण उपयोगकर्ता को कई चैनलों (HTTP, TLS, आदि) पर फ़िंगरप्रिंटिंग से बचाने का प्रयास करता है।

### JA4+ फ़िंगरप्रिंट का एक **सूट** है! यह किन्हें नकली बनाता है?

यह उपकरण निम्नलिखित JA4 फ़िंगरप्रिंट को आपके कनेक्टेड Chrome/Chromium ब्राउज़र के बिल्कुल समान बनाने के लिए नकली बनाएगा:
* JA4 (TLS फ़िंगरप्रिंट)
* JA4H (HTTP फ़िंगरप्रिंट)
* JA4X (X509 TLS प्रमाणपत्र फ़िंगरप्रिंट)
* JA4T (TCP फ़िंगरप्रिंट)

### यदि मैं इसके साथ कोई अन्य अपस्ट्रीम HTTP/SOCKS प्रॉक्सी उपयोग करना चाहूँ तो क्या होगा?

`thermoptic` अब नियंत्रित Chrome इंस्टेंस को एक आंतरिक `proxyrouter` सेवा के माध्यम से रूट करता है, ताकि आप Chrome को अपस्ट्रीम HTTP या SOCKS प्रॉक्सी (क्रेडेंशियल्स की आवश्यकता वाले प्रॉक्सी सहित) की ओर इंगित कर सकें। `docker-compose.yml` में `proxyrouter` सेवा के अंतर्गत `UPSTREAM_PROXY` मान को संपादित करके अपस्ट्रीम प्रॉक्सी URI सेट करें। जब आप इसे खाली छोड़ते हैं, तो Chrome बिना प्रमाणीकरण वाले इन-क्लस्टर प्रॉक्सी के माध्यम से सीधे इंटरनेट से बात करता है।

अपस्ट्रीम SOCKS प्रॉक्सी सेट करने का उदाहरण:```yaml
  proxyrouter:
    environment:
      UPSTREAM_PROXY: "socks5://username:[email protected]:1080"

एक उदाहरण कार्यान्वयन के लिए, [`./hooks/onstart.js`](https://github.com/mandatoryprogrammer/thermoptic/blob/main/hooks/onstart.js) फ़ाइल देखें जो [Cloudflare turnstile CAPTCHA को बायपास करती है](https://github.com/mandatoryprogrammer/thermoptic/blob/main/tutorials/turnstile/cloudflare-turnstile-bypass.md) (और अन्य Cloudflare anti-bot जाँचें)।

## Dockerized Chrome ब्राउज़र को Web UI (Xpra) के माध्यम से नियंत्रित करें

`thermoptic` के साथ Xpra web UI आता है जो `http://127.0.0.1:14111` पर उपलब्ध है। यह आपको Dockerized Chrome ब्राउज़र को आसानी से मैन्युअल रूप से नियंत्रित करने की सुविधा देता है:

<img src="https://assets.kitploit.com/production/public/readmes/49068/0fa1b187f46405dda2b0db5d461619daa6a7bdad2c385cb51994e870d9054d10.png" width="100%">

यह ऐसी चीज़ों के लिए उपयोगी है:
* अपने खाते में लॉग इन करना ताकि आप `thermoptic` के माध्यम से `curl` जैसे अपने पसंदीदा HTTP क्लाइंट का उपयोग करके प्रमाणित अनुरोध कर सकें।
  * उदाहरण के लिए, यदि आप ब्राउज़र से `reddit.com` में लॉग इन करते हैं, तो `thermoptic` के माध्यम से आप Reddit को भेजे जाने वाले सभी अनुरोध स्वचालित रूप से आपके Reddit खाते के रूप में प्रमाणित होंगे!
* अपने कस्टम `thermoptic` हुक्स को डीबग करना और वेबसाइटों के साथ समस्याओं की जाँच करना।

## कॉन्फ़िगरेशन

ये पर्यावरण चर बताते हैं कि चलते समय `thermoptic` को कैसे कॉन्फ़िगर किया जाना चाहिए।

`HTTP_PROXY_PORT`: वह पोर्ट जिस पर `thermoptic` प्रॉक्सी को सुनना चाहिए। यदि आप Docker में `thermoptic` चला रहे हैं, तो मेल खाने के लिए आपको `ports` मैपिंग फ़ील्ड भी बदलनी होगी।

`CHROME_DEBUGGING_PORT`: वह पोर्ट जिस पर Chrome डिबगिंग प्रोटोकॉल उजागर होता है। यह पोर्ट तब निर्दिष्ट होता है जब आप `--remote-debugging-port` फ़्लैग को `9222` जैसे मान पर सेट करके Chrome/Chromium लॉन्च करते हैं।

`CHROME_DEBUGGING_HOST`: वह होस्ट जिस पर Chrome डिबगिंग प्रोटोकॉल उजागर होता है। यह अक्सर `127.0.0.1` होता है यदि ब्राउज़र स्थानीय रूप से लॉन्च किया गया है और `thermoptic` Docker में नहीं चल रहा है। यदि यह Docker में चल रहा है, तो आपको `host.docker.internal` का उपयोग करना पड़ सकता है, जानकारी के लिए [Docker दस्तावेज़](https://docs.docker.com/desktop/features/networking/#i-want-to-connect-from-a-container-to-a-service-on-the-host) देखें।

`PORT`: CDP पोर्ट जिसे Chrome कंटेनर शेष स्टैक के लिए प्रकाशित करता है। इसे `CHROME_DEBUGGING_PORT` के अनुरूप रखें ताकि `socat` ब्रिज अपेक्षित रूप से काम करता रहे।

`CHROME_CONTROL_PORT`: Chrome का कंट्रोल-सर्विस पोर्ट जिसे thermoptic ब्राउज़र को प्रबंधित करने के लिए उपयोग करता है (उदाहरण के लिए, पुनरारंभ अनुरोध भेजना)।

`CHROME_CONTROL_COOLDOWN_MS`: Chrome पुनरारंभ प्रयासों के बीच न्यूनतम समय मिलीसेकंड में। इसे तब उपयोग करें जब एक के बाद एक कई विफलताएँ हों तो तीव्र पुनरारंभ लूप से बचने के लिए।

`ENABLE_GUI_CONTROL`: xpra वेब पैनल लॉन्च करने के लिए `true` सेट करें ताकि आप `http://127.0.0.1:14111` पर जाकर कंटेनराइज़्ड Chrome को चला सकें। इसे केवल हेडलेस रन के लिए अक्षम करें।

`CHROME_SCREEN_WIDTH` / `CHROME_SCREEN_HEIGHT`: dockerized headful Chrome डिस्प्ले के पिक्सेल आयाम।

`CHROME_ENABLE_GPU`: नियंत्रित करता है कि बंडल किया गया Chrome कंटेनर होस्ट GPU त्वरण का उपयोग करने का प्रयास करे या नहीं। आवश्यक रनटाइम और डिवाइस नोड मौजूद होने पर `auto` (डिफ़ॉल्ट) NVIDIA/Vulkan पथ को सक्षम करता है, अन्यथा यह सॉफ़्टवेयर रेंडरिंग पर वापस चला जाता है। पुराने केवल-सॉफ़्टवेयर व्यवहार को बाध्य करने के लिए इसे `false` पर सेट करें।

`CHROME_PROFILE_RECOVERY`: जब `true` (डिफ़ॉल्ट) होता है, तो बंडल किया गया Chrome लॉन्चर एक पुनर्प्राप्ति प्रयास करेगा यदि Chrome किसी दूषित प्रोफ़ाइल में देखे गए समान क्रैश-लूप एग्ज़िट कोड (`133`) के साथ तुरंत मर जाता है। एक साफ प्रोफ़ाइल के साथ पुनः प्रयास करने से पहले खराब प्रोफ़ाइल सामग्री को कंटेनर के अंदर `/tmp/chrome-profile-recovery/` के अंतर्गत ले जाया जाता है।

`PROXY_USERNAME`: वह उपयोगकर्ता नाम जो आपको प्रॉक्सी पर प्रमाणित करने के लिए उपयोग किया जाता है, डिफ़ॉल्ट `changeme` है। यदि सेट नहीं है तो प्रॉक्सी बिना प्रमाणीकरण की आवश्यकता के चलता है।

`PROXY_PASSWORD`: वह पासवर्ड जो आपको प्रॉक्सी पर प्रमाणित करने के लिए उपयोग किया जाता है, डिफ़ॉल्ट `changeme` है। यदि सेट नहीं है तो प्रॉक्सी बिना प्रमाणीकरण की आवश्यकता के चलता है।

`THERMOPTIC_CONTAINER_RUNTIME`: संकेत देता है कि thermoptic बंडल किए गए कंटेनर के अंदर चल रहा है। इसे `true` पर सेट रखें; यह अंतर्निहित स्वास्थ्य जाँच जैसे व्यवहारों को नियंत्रित करता है जो केवल पूर्ण Docker सेटअप में ही समझ में आते हैं।

`HEALTHCHECK_ENDPOINT_PORT`: वह पोर्ट जहाँ thermoptic अपना हेल्थ-चेक वेब एंडपॉइंट उजागर करता है। हेल्थ वर्कर प्रॉक्सी के माध्यम से इस पर कॉल करता है; यदि यह प्रतिक्रिया देना बंद कर देता है, तो जमे हुए सत्रों को अनस्टक करने के लिए Chrome स्वचालित रूप से पुनरारंभ हो जाता है।

`HEALTHCHECK_ENDPOINT_PATH`: ऊपर वर्णित हेल्थ-चेक एंडपॉइंट द्वारा परोसा गया HTTP पथ। यदि आपको कोई अलग URL चाहिए तो इसे बदलें।

`ON_START_HOOK_FILE_PATH`: प्रॉक्सी प्रारंभ पर चलाने के लिए कस्टम Node कोड। जब तक यह हुक पूरा नहीं हो जाता, प्रॉक्सी सुनना शुरू नहीं करेगा, `./hooks/` में उदाहरण देखें। नमूना प्रॉक्सी शुरू करने से पहले Cloudflare की JavaScript ब्राउज़र जाँच पर क्लिक करने के लिए ब्राउज़र का उपयोग करने का प्रदर्शन करता है।

`BEFORE_REQUEST_HOOK_FILE_PATH`: किसी अनुरोध को प्रॉक्सी किए जाने से पहले चलाने के लिए कस्टम Node कोड। यह तब उपयोगी है जब आपको साइट HTTP अनुरोध किए जाने से पहले ब्राउज़र से कुछ जाँच पास कराने की आवश्यकता होती है।

`AFTER_REQUEST_HOOK_FILE_PATH`: किसी अनुरोध को प्रॉक्सी किए जाने के बाद चलाने के लिए कस्टम Node कोड। अक्सर यह क्लाइंट द्वारा `Cookie` हेडर के माध्यम से सेट किए गए कुकीज़ को साफ करने जैसे कार्यों के लिए उपयोगी होता है।

`DEBUG`: जब आपको कोई बग मिले तो इसे `true` सेट करें ताकि इश्यू दर्ज करने से पहले thermoptic विस्तृत निदान प्रिंट करे; सामान्य संचालन के दौरान इसे `false` रखें।

## सुरक्षा

ध्यान दें कि इस समय `thermoptic` केवल उन HTTP क्लाइंट्स के साथ उपयोग के लिए है जिन पर आप स्पष्ट रूप से भरोसा करते हैं। यह अविश्वसनीय उपयोगकर्ताओं के लिए उजागर किए जाने के लिए *नहीं* है।

किसी भी सुरक्षा भेद्यता के लिए कृपया मुझे `mandatory@` Gmail पर रिपोर्ट भेजें।