कैसे साइट डिटेक्ट कार्ड को हटाएं: फिंगरप्रिंट स्क्रिप्ट्स का ऑडिट

```html

20 अगस्त 2026 को डेवलपर मैट कैलागन (ब्लॉग laserphile) ने एक अजीब बग का विश्लेषण प्रकाशित किया: उसके ब्लूटूथ हेडफ़ोन मल्टीपॉइंट से कंप्यूटर से फोन पर स्विच करना बंद कर देते थे। हर बार जब अलीएक्सप्रेस का टैब खुला होता। उसने अनुमान लगाने का प्रयास नहीं किया - उसने ब्राउज़र API को उपकरण बनाया और देखा कि पृष्ठ के अंदर क्या हो रहा है। पता चला कि एंटी-फ्रॉड स्टैक अलीबाबा के दो ओबफस्केटेड स्क्रिप्ट ऑडियो संदर्भ को उठाते थे और उस ध्वनि के माध्यम से डिवाइस का फ़िंगरप्रिंट लेते थे जिसे कोई नहीं सुनता।

यह उस चीज़ का आदर्श उदाहरण है जो लगभग कोई भी प्रोफाइल सेटअप या पार्सर शुरू करने से पहले नहीं करता: प्लेटफ़ॉर्म के डिटेक्ट स्टैक को नहीं पढ़ता, बल्कि इसका अनुमान लगाता है। नीचे एक व्यावहारिक विधि है, जिससे आप एक विशेष साइट का डिटेक्ट मैप अपने हाथों से एक घंटे में, बिना ओबफस्केशन रिवर्सिंग और बिना भुगतान सेवाओं के बना सकते हैं।

डिटेक्ट मैप बनाने की आवश्यकता

टिपिकल चक्र इस प्रकार है: खाते बैन होते हैं - एंटी-डिटेक्ट ब्राउज़र की सेटिंग्स को यादृच्छिक रूप से घुमाते हैं - प्रॉक्सी बदलते हैं - फिर से बैन होते हैं। "बैन" और "सेटिंग्स" के बीच कोई डेटा नहीं है: यह स्पष्ट नहीं है कि प्लेटफ़ॉर्म वास्तव में क्या पढ़ता है और किस स्तर पर पकड़ता है।

डिटेक्ट मैप इस अंतर को बंद करता है। यह एक सूची है: कौन सा सुरक्षा विक्रेता है, कौन से स्क्रिप्ट इसे लागू करते हैं, कौन से API को छूते हैं और परिणाम कहाँ जाता है। आगे यह स्पष्ट होता है कि वास्तव में तंग जगह कहाँ है - IP में, नेटवर्क फ़िंगरप्रिंट में या ब्राउज़र के हार्डवेयर स्तर में। यह तीन दर्शकों के लिए समान रूप से उपयोगी है:

मल्टी-एकाउंटिंग - समझना कि प्रोफाइल किस संकेत पर जुड़ते हैं। उनके IP अलग हैं, लेकिन ऑडियो स्टैक, WebGL-रेनडरर और hardwareConcurrency अक्सर पूरे फार्म के लिए समान होते हैं।
स्क्रैपिंग - समझना कि क्या ब्राउज़र उठाना उचित है या यह कार्य HTTP क्लाइंट के साथ सही TLS फ़िंगरप्रिंट के साथ हल होता है।
गोपनीयता - देखना कि वास्तव में दुकान या सेवा आपके डिवाइस के बारे में क्या एकत्र करती है, कुकीज़ के अलावा।

चरण 1. नेटवर्क द्वारा सुरक्षा विक्रेता का निर्धारण करें

पहली चीज जो आप करते हैं - नेटवर्क टैब पर DevTools खोलें, पृष्ठ लोड करें और पहले दस्तावेज़ के हेडर और कुकीज़ को देखें। पहचानने वाले चिह्न ज्ञात और स्थिर हैं:

CF-RAY उत्तर हेडर में और कुकी cf_clearance - क्लाउडफ्लेयर।
कुकी _abck और bmak फ़ंक्शन वाला स्क्रिप्ट - अकाamai बॉट प्रबंधक।
_px प्रीफिक्स के साथ वेरिएबल और कुकीज़ - पेरिमीटरX (HUMAN)।
कुकी datadome और विक्रेता डोमेन से अलग JS - डेटा डोम।
खाली 429 बिना उत्तर के शरीर के - कासाडा की विशेष पहचान।

अगर हाथ से करना आलसी है, तो microlinkhq/is-antibot (30+ प्रदाता) जैसे ओपन डिटेक्टर्स और 26+ विक्रेताओं के लिए ब्राउज़र एक्सटेंशन-डिटेक्टर्स हैं। वे तेज़ पहला उत्तर देते हैं, लेकिन मुख्य प्रश्न का उत्तर नहीं देते - आपके ब्राउज़र में वास्तव में क्या मापा जा रहा है। इसके लिए आगे जाना आवश्यक है।

चरण 2. संदिग्ध स्क्रिप्ट की सूची निकालें

नेटवर्क को JS प्रकार द्वारा फ़िल्टर करें और सब कुछ लिखें जो मुख्य डोमेन से नहीं लोड होता है या सेवा निर्देशिकाओं में है। अलीएक्सप्रेस के मामले में, ये दो फ़ाइलें स्पष्ट सेवा पथों के साथ थीं:

assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.js
assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js

एंटी-फ्रॉड स्क्रिप्ट के संकेत: ओबफस्केटेड कोड, पथ में संस्करण, स्थैतिक के लिए अलग उपडोमेन, पृष्ठ के दृश्य भाग के साथ कोई संबंध नहीं। ओबफस्केशन को खोलने और पढ़ने की आवश्यकता नहीं है - अगले चरण में स्क्रिप्ट खुद के बारे में बताएगी।

चरण 3. फ़िंगरप्रिंट-API को उपकरण बनाना

यह विधि का मूल है और ठीक वही है जो कैलागन ने किया: उसने AudioContext और AudioNode.prototype.connect() कंस्ट्रक्टर को लपेटा, जिसके बाद उसने पृष्ठ पर दो जीवित ऑडियो संदर्भ देखे, जहाँ कोई मीडिया तत्व और कोई play() कॉल नहीं था।

तर्क सरल है: आप जिस विधि में रुचि रखते हैं, उसे अपनी लपेट में बदल देते हैं, जो कॉल को स्टैक के साथ लॉग करती है और मूल को नियंत्रण में देती है। कॉल स्टैक दिखाता है कि वास्तव में कौन सा स्क्रिप्ट API को डायल करता है। इस प्रकार का स्निपेट DevTools Sources → Snippets के माध्यम से या एक एक्सटेंशन के माध्यम से जोड़ना सबसे सुविधाजनक है, जो कोड को document-start पर निष्पादित करता है - यह महत्वपूर्ण है कि एंटी-फ्रॉड स्क्रिप्ट के लोडिंग से पहले किया जाए।

जालों का न्यूनतम सेट, जो अधिकांश संकेतों को बंद करता है:

HTMLCanvasElement.prototype.toDataURL और getImageData - कैनवास फ़िंगरप्रिंट।
WebGLRenderingContext.prototype.getParameter - ग्राफ़िक्स कार्ड और ड्राइवर का मॉडल, शेडर्स की सटीकता।
AudioContext / OfflineAudioContext और AudioNode.prototype.connect - ऑडियो फ़िंगरप्रिंट।
गेटर्स navigator.hardwareConcurrency, navigator.deviceMemory, navigator.plugins, navigator.webdriver।
RTCPeerConnection - WebRTC और स्थानीय पते।
screen.width/height, devicePixelRatio, Intl.DateTimeFormat().resolvedOptions() - स्क्रीन और टाइमज़ोन।
navigator.mediaDevices.enumerateDevices - ऑडियो और वीडियो उपकरणों की सूची।

प्रगति के परिणामस्वरूप आपके पास एक सूची होगी: इनमें से कौन से API वास्तव में कॉल किए गए, कितनी बार और किसने। विश्लेषित मामले में, अलीबाबा के स्क्रिप्ट ने कैनवास और toDataURL, WebGL-रेनडरर और शेडर्स की सटीकता, ऑडियो को ऑस्सीलेटर और एनालाइज़र के माध्यम से, स्क्रीन के आकार और devicePixelRatio, hardwareConcurrency और deviceMemory, प्लगइन्स, कोडेक्स का समर्थन, WebRTC, प्रदर्शन समय, माउस और टच मूवमेंट पैटर्न, डिवाइस के मूवमेंट सेंसर और ऑटोमेशन के संकेतक गुणों का फ़िंगरप्रिंट लिया।

ऑडियो-ग्राफ़ द्वारा वास्तव में क्या किया गया

यह समझना उपयोगी है कि माप कैसा दिखता है, ताकि इसे अन्य स्थानों पर पहचान सकें। ग्राफ़ ऐसा था: दांतदार ऑस्सीलेटर → AnalyserNode → ScriptProcessorNode, जो विश्लेषण के परिणाम को पढ़ता है → GainNode जिसमें शून्य वृद्धि होती है → destination। कोई ध्वनि नहीं है, मात्रा का कोई महत्व नहीं है - यह बस मौजूद नहीं है। लेकिन destination से कनेक्शन, लेखक के शब्दों में, ब्राउज़र को ग्राफ़ को सक्रिय रूप से संसाधित करने के लिए मजबूर करता है, जबकि अंतिम मात्रा शून्य होती है। यही जीवित ऑडियो ट्रैक्ट था जिसने ब्लूटूथ पथ को खुला रखा, हेडफ़ोन के मल्टीपॉइंट स्विचिंग को तोड़ दिया।

इस संकेत की प्रक्रिया में भिन्नताएँ प्रोसेसर, ऑडियो हार्डवेयर, OS, ब्राउज़र और ड्राइवरों पर निर्भर करती हैं - यही कारण है कि एक स्थिर पहचानकर्ता है, जो IP परिवर्तन और कुकीज़ की सफाई को सहन करता है। इस स्तर का विस्तृत विश्लेषण और इसके लिए प्रोफाइल सेटिंग्स - ऑडियो संदर्भ फ़िंगरप्रिंटिंग से सुरक्षा पर लेख में है।

चरण 4. परिणाम भेजने को पकड़ें

बिना भेजे संग्रह बेकार है, इसलिए अगला कदम यह है कि पता करें कि एकत्रित फ़िंगरप्रिंट कहाँ जाता है। नेटवर्क को XHR/Fetch द्वारा फ़िल्टर करें और ping प्रकार के अनुरोधों को अलग से देखें - इन्हें navigator.sendBeacon उत्पन्न करता है, जिसका उपयोग टेलीमेट्री स्क्रिप्ट करना पसंद करते हैं, क्योंकि यह पृष्ठ से बाहर निकलने के बाद भी जीवित रहता है।

व्यावहारिक रूप से हमेशा fetch, XMLHttpRequest.prototype.send और navigator.sendBeacon को अतिरिक्त रूप से लपेटना उपयोगी होता है - तब आप अनुरोध का शरीर देखेंगे इससे पहले कि यह बाहर जाए। तैयार रहें कि सामग्री को सीरियलाइज और एन्क्रिप्ट किया जाएगा: अलीएक्सप्रेस के मामले में, डेटा को अलीबाबा की टेलीमेट्री पर भेजने से पहले एन्क्रिप्ट किया गया था। लेकिन फिर भी, आप दो तथ्य प्राप्त करते हैं: रिसीवर का पता और आपके कार्यों के सापेक्ष भेजने का समय।

यदि साइट केवल ब्राउज़र में काम नहीं करती है, बल्कि मोबाइल ऐप या अलग क्लाइंट के माध्यम से, तो वही प्रश्न ट्रैफ़िक के स्तर पर हल किया जाता है, न कि DOM - इंटरसेप्शन और विश्लेषण की विधि mitmproxy के माध्यम से ट्रैफ़िक ऑडिट में वर्णित है।

चरण 5. अपने प्रोफाइल के साथ मैप की तुलना करें

अब आपके पास संकेतों की एक सूची है जो प्लेटफ़ॉर्म वास्तव में पढ़ता है। यह जांचना बाकी है कि आपके कार्यात्मक प्रोफाइल इन संकेतों के अनुसार क्या देता है। क्रम इस प्रकार है: सामान्य ब्राउज़र में मान निकालें, फिर एंटी-डिटेक्ट के प्रत्येक प्रोफाइल में और तुलना करें।

दो चीजें एक साथ महत्वपूर्ण हैं: मान प्रोफाइल के बीच भिन्न होने चाहिए और एक ही प्रोफाइल के भीतर सत्रों के बीच स्थिर होने चाहिए। ऐसा प्रोफाइल, जिसका फ़िंगरप्रिंट हर बार लॉन्च पर कूदता है, एंटी-फ्रॉड के लिए उतना ही संदिग्ध दिखता है जितना कि दस प्रोफाइल जिनका फ़िंगरप्रिंट समान है।

अलग से जांचें कि क्या आवश्यक स्तर पर सब्स्टिट्यूशन वास्तव में मौजूद है। यहाँ ब्राउज़रों के बीच भिन्नता महत्वपूर्ण है: फ़ायरफ़ॉक्स संस्करण 118 से स्थिर WebAudio आउटपुट देता है, और विश्लेषण के डेटा के अनुसार 99.24% उपयोगकर्ता तीन मानों में समाहित होते हैं; ब्रेव यादृच्छिक डेटा को मिलाता है और 22 अगस्त 2026 से विशेष रूप से इन अलीएक्सप्रेस स्क्रिप्ट को ब्लॉक करता है, यह याद दिलाते हुए कि ऑडियो फ़िंगरप्रिंटिंग से सुरक्षा उसके पास डिफ़ॉल्ट रूप से छह साल से अधिक है; सफारी ऑडियो बफ़र्स में त्रुटियाँ मिलाता है; क्रोम में आक्रामक सुरक्षा नहीं है।

पानी के नीचे की चट्टानें

स्क्रिप्ट पहले ही काम कर चुकी है। फ़ाइल को ब्लॉक करना पहले से बनाए गए ऑडियो संदर्भ को समाप्त नहीं करता है - लेखक स्पष्ट रूप से उल्लेख करता है कि खुली टैब को बंद करना आवश्यक है। यही आपके उपकरणकरण के लिए भी लागू होता है: यदि लपेट स्क्रिप्ट के बाद आई है, तो आप कुछ नहीं देखेंगे।
ब्लॉकिंग कार्यक्षमता को तोड़ देती है। एंटी-फ्रॉड स्टैक अक्सर वैध चीजों के लिए भी जिम्मेदार होता है - प्राधिकरण, भुगतान, वास्तविक दुरुपयोग से एंटीबॉट सुरक्षा। डिटेक्ट मैप बनाना और स्क्रिप्ट को काटना अलग-अलग कार्य हैं; दूसरा साइट को तोड़ता है।
डिटेक्ट का एक संस्करण नहीं है। स्टैक भौगोलिक, उपकरण के प्रकार और A/B समूह के अनुसार भिन्न हो सकता है। मैप को उस IP और उस उपकरण से बनाना उचित है, जिससे आप वास्तव में काम कर रहे हैं, अन्यथा आप किसी और की कॉन्फ़िगरेशन का वर्णन कर रहे हैं।
स्वयं उपकरणकरण का पता लगाया जाता है। ओवरराइडेड नेटिव मेथड्स सही toString को खो देते हैं, और कनेक्टेड डिबगर निशान छोड़ता है। разведка के लिए यह महत्वपूर्ण नहीं है, लेकिन разведक प्रोफाइल को लड़ाकू प्रोफाइल से न मिलाएं - ऑटोमेशन के मास्किंग तकनीकों को हेडलेस ब्राउज़र की मास्किंग गाइड में वर्णित किया गया है।

परिणाम के लिए किस प्रॉक्सी की आवश्यकता है

इस प्रकार के मैप से मुख्य व्यावहारिक निष्कर्ष लगभग हमेशा एक ही होता है: IP केवल पहला स्तर है, और इसे अन्य सभी से पहले जांचा जाता है। यदि एंटी-फ्रॉड पहले से ही अनुरोध के स्तर पर होस्टिंग के पते को देखता है, तो ऑडियो ग्राफ और कैनवास तक मामला नहीं पहुंचेगा - आप एक चुनौती या खाली आउटपुट प्राप्त करेंगे और गलत चीज़ को ठीक करेंगे।

इसलिए चयन की तर्कशक्ति इस प्रकार है। गंभीर स्टैक वाले प्लेटफ़ॉर्म (अकाamai, डेटा डोम, पेरिमीटरX, अलीबाबा के स्तर के स्वामित्व विकास) के लिए आधार रेसिडेंशियल प्रॉक्सी हैं - वास्तविक प्रदाताओं के पते, जो पहले फ़िल्टर पर नहीं कटते। मोबाइल ऐप और प्लेटफ़ॉर्म के लिए, जहाँ मुख्य दर्शक स्मार्टफ़ोन से जुड़े होते हैं, मोबाइल प्रॉक्सी अधिक प्राकृतिक प्रोफाइल के करीब होते हैं: ऑपरेटर CGNAT पते को कई जीवित उपयोगकर्ताओं के बीच साझा करता है।

और विपरीत भी सच है: यदि मैप ने दिखाया कि प्लेटफ़ॉर्म हेडर और कुकीज़ द्वारा सीमित है, और भारी JS फ़िंगरप्रिंट नहीं है, - ब्राउज़र फार्म अधिक है, कार्य सामान्य HTTP क्लाइंट और डेटा सेंटर पते द्वारा हल किया जाता है।

निष्कर्ष

हेडफ़ोन के साथ मामला ऑडियो फ़िंगरप्रिंट के तथ्य से मूल्यवान नहीं है - इसके बारे में वर्षों से जाना जाता है। विधि मूल्यवान है: व्यक्ति ने अनुमान पर विश्वास नहीं किया, बल्कि दो ब्राउज़र API विधियों को लपेटा और एक शाम में यह पता लगाया कि उससे क्या लिया जा रहा है, और यह कहाँ जा रहा है। वही तकनीक किसी भी प्लेटफ़ॉर्म पर एक घंटे में लगती है, जिससे आप यादृच्छिक सेटिंग्स के महीनों के परीक्षण को बदल देते हैं। बैन ठीक करने से पहले डिटेक्ट मैप बनाएं - अन्यथा प्रॉक्सी पर बजट खर्च करने का जोखिम है, जहाँ समस्या सभी प्रोफाइल पर समान WebGL-रेनडरर में थी।