thermoptic

"मुझे विश्वास नहीं हो रहा, थर्मोप्टिक छलावरण!"

यह क्या है?

यह एक HTTP प्रॉक्सी है जिसे JA4+ जैसी फिंगरप्रिंटिंग का उपयोग करके कुछ HTTP क्लाइंट्स को ब्लॉक करने वाली सेवाओं को बायपास करने के लिए डिज़ाइन किया गया है। इस प्रॉक्सी का उपयोग करके, आप curl जैसे अपने पसंदीदा HTTP क्लाइंट्स का उपयोग कर सकते हैं और फिर भी एक असली (Chrome/Chromium) वेब ब्राउज़र से जादुई रूप से अभेद्य फिंगरप्रिंट प्राप्त कर सकते हैं। thermoptic में JavaScript-आधारित फिंगरप्रिंटिंग को कम करने के लिए कुछ मज़ेदार सुविधाएँ भी हैं। यह वेब ब्राउज़र और लो-लेवल HTTP क्लाइंट्स दोनों का एक साथ उपयोग करके हाइब्रिड स्क्रैपिंग करना भी आसान बनाता है।

भले ही आप JA4+ फिंगरप्रिंटिंग से परिचित न हों, यदि आपने कभी स्क्रैपिंग की है तो संभवतः आपको पहले भी इसके द्वारा ब्लॉक किया गया होगा। Cloudflare जैसी लोकप्रिय सेवाएँ अनुरोधों को ब्लॉक करने के लिए "गैर-मानव" HTTP क्लाइंट्स के उपयोग का पता लगाने हेतु ऐसी तकनीकों (और अन्य तरकीबों) का उपयोग करती हैं। ये सेवाएँ इस फिंगरप्रिंटिंग का उपयोग यह पता लगाने के लिए भी कर सकती हैं कि आपने किसी असली ब्राउज़र के साथ सत्र शुरू किया और बाद में curl जैसे लो-लेवल क्लाइंट पर स्विच कर दिया। thermoptic सभी स्क्रैपिंग अनुरोधों के लिए एक एकीकृत "असली" ब्राउज़र फिंगरप्रिंट प्रस्तुत करके इन सभी समस्याओं का समाधान करता है।

उदाहरण

यहाँ प्रॉक्सी के बिना curl का एक उदाहरण JA4H (HTTP) फिंगरप्रिंट है:

$ curl https://ja4db.com/id/ja4h/
ge11nn090000_b6a016211e8a_000000000000_e3b0c44298fc

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

ge11cn19enus_f2808f0d04cf_9a10d4221160_7068f58def6e

हालाँकि, जब हम अनुरोध करने के लिए प्रॉक्सी का उपयोग करते हैं, तो हमारा JA4H फ़िंगरप्रिंट जादुई रूप से समान होता है:

$ curl --proxy http://thermoptic:1234 https://ja4db.com/id/ja4h/
ge11cn19enus_f2808f0d04cf_9a10d4221160_7068f58def6e

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

सेटअप

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

नियमित Docker सेटअप (उन होस्ट्स पर काम करता है जिनमें GPU रनटाइम नहीं है):

docker compose up --build

बस इतना ही, अब आप इसके माध्यम से ट्रैफ़िक प्रॉक्सी कर सकते हैं:

curl --proxy http://127.0.0.1:1234 --insecure https://ja4db.com/id/ja4h/

महत्वपूर्ण नोट्स:

• डिफ़ॉल्ट रूप से प्रॉक्सी बिना प्रमाणीकरण के चलता है। यदि आप प्रॉक्सी को बाहरी रूप से उजागर करने की योजना बना रहे हैं तो कृपया सुनिश्चित करें कि आप PROXY_USERNAME और PROXY_PASSWORD एनवायरनमेंट वेरिएबल्स के साथ प्रमाणीकरण सेट करें।
• यदि आप ---insecure का उपयोग नहीं करना चाहते हैं तो आपको ./ssl/rootCA.crt में स्थित जनरेट की गई CA फ़ाइल का उपयोग करना होगा। यह पहली बार thermoptic चलाने पर जनरेट होती है।
• आप thermoptic को किसी भी Chrome/Chromium इंस्टेंस से कनेक्ट कर सकते हैं जो --remote-debugging-port फ़्लैग के साथ लॉन्च किया गया हो। यह आवश्यक है क्योंकि आप अपने फ़िंगरप्रिंट को यथासंभव कम प्रोफ़ाइल रखने के लिए अधिक सामान्य रूप से उपयोग किए जाने वाले वातावरण (जैसे 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 चलाएँ।

विशेषताएँ

• 🕵️ ब्राउज़र-समानता प्रॉक्सिंग जो वास्तविक Chrome सत्र के माध्यम से अनुरोधों को रीप्ले करती है ताकि JA4 फ़िंगरप्रिंट्स बाइट-दर-बाइट मेल खाएँ।
• 🤝 आपके HTTP क्लाइंट (जैसे curl, requests, आदि) को thermoptic के साथ एकीकृत करने के लिए बहुत कम या कोई कस्टम कोड आवश्यक नहीं, बस प्रॉक्सी सेट करें और आपके फ़िंगरप्रिंट्स का ध्यान रखा जाएगा।
• 🪝 before-request/after-request/on-start ऑटोमेशन के लिए हुक फ़्रेमवर्क ताकि आप चुनौतियों को हल करने के लिए पूरे ब्राउज़र को चला सकें, या आर्टिफ़ैक्ट्स कैप्चर कर सकें।
  • 📘 Cloudflare turnstile हल करने वाले हुक का एक उदाहरण ./hooks/onstart.js में देखा जा सकता है।
• 🖥️ वेब-ब्राउज़र नियंत्रण UI (http://127.0.0.1:14111 पर) Dockerized Chrome ब्राउज़र विंडो को नियंत्रित करने के लिए। साइटों में मैन्युअल रूप से लॉग इन करने और फिर अपने लॉग-इन सत्र के रूप में अनुरोध करने के लिए प्रॉक्सी का सहज उपयोग करने (और डीबगिंग के लिए) में उपयोगी।
• 🔌 docker-compose.yml में UPSTREAM_PROXY एनवायरनमेंट वेरिएबल के माध्यम से एक अपस्ट्रीम HTTP या SOCKS प्रॉक्सी URI सेट करें।
• 🛡️ अंतर्निहित हेल्थ चेक और रीस्टार्ट कंट्रोल लूप जो फ्रोज़न ब्राउज़रों का पता लगाता है और ऑपरेटर की देखरेख के बिना स्वचालित रूप से रिकवर करता है।
• ⚡ HTTP/1.1 और HTTP/2 का समर्थन करता है, जिससे ट्रैफ़िक को किसी भी प्रोटोकॉल पर प्रॉक्सी किया जा सकता है। (ध्यान दें कि आप प्रॉक्सी से HTTP/1.1 में बात कर सकते हैं, और puppeted Chrome अंत साइट के साथ एक अलग प्रोटोकॉल पर बातचीत कर सकता है।)

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

• एक HTTP अनुरोध curl जैसे HTTP क्लाइंट का उपयोग करके किया जाता है जिसमें thermoptic प्रॉक्सी के रूप में सेट होता है।
• thermoptic अनुरोध का विश्लेषण करता है ताकि यह सर्वोत्तम रूप से निर्धारित कर सके कि यह किस प्रकार का ब्राउज़र अनुरोध होना चाहिए (जैसे मैन्युअल URL विज़िट? फ़ॉर्म सबमिशन? एक fetch() अनुरोध?)।
• thermoptic ब्राउज़र को puppet करने और एक पेज सेट करने के लिए Chrome Debugging Protocol (CDP) का उपयोग करता है जो अनुरोध को ठीक वैसे ही mock करता है जैसे यह वास्तविक वेब ब्राउज़र में सामान्य रूप से होता है।
• thermoptic mocked context के माध्यम से अनुरोध को ट्रिगर करता है और HTTP प्रतिक्रिया को कैप्चर करता है।
• thermoptic HTTP प्रतिक्रिया को क्लाइंट को वापस भेजता है।

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

नोट: चूँकि कई WAFs वेब ब्राउज़रों की JavaScript-स्तरीय फ़िंगरप्रिंटिंग का उपयोग करते हैं, thermoptic स्क्रैपिंग प्रक्रिया के प्रमुख चरणों के लिए ब्राउज़र का उपयोग करने के लिए हुक भी उजागर करता है। इस पर अधिक जानकारी के लिए यह अनुभाग देखें।

अन्य समाधानों की तुलना में यह दृष्टिकोण क्यों?

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

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

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