JPEG की जालसाजी करना

 (ty-penguin.org.uk)
2 पॉइंट द्वारा GN⁺ 2025-07-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • लेखक Spigot नामक एक नकली वेबपेज hierarchy generator चलाते हैं, जो आक्रामक web crawlers के सामने यादृच्छिक रूप से जनरेट किए गए पेज प्रस्तुत करता है
  • हाल ही में उन्होंने देखा कि image crawlers jpg images खोजने के लिए साइट को गहन रूप से खंगाल रहे थे
  • real-time image generation को न्यूनतम CPU resources के साथ संभालने के लिए, वास्तविक JPEG फ़ाइल के केवल structured parts को इकट्ठा कर template की तरह इस्तेमाल करने और compressed हिस्से में random data डालने का तरीका प्रस्तावित किया गया है
  • प्रयोगों के अनुसार, इस तरीके से बनाई गई JPEG फ़ाइलों में त्रुटियाँ होने पर भी अधिकांश image viewers उनमें image दिखा सकते हैं, और crawlers को भी वे काफ़ी विश्वसनीय लगती हैं
  • यह तरीका server resources की खपत कम रखता है, जबकि crawlers पर बोझ डालता है, और Spigot के लगभग 60% पेजों पर लागू है

Spigot और JPEG जालसाजी की पृष्ठभूमि

  • Spigot, Markov Chain आधारित नकली web page hierarchy को real-time में जनरेट करता है, ताकि आक्रामक web crawlers को निरर्थक data दिया जा सके
  • कुछ crawlers अपनी पहचान छिपाने के लिए random browser signatures और IPs का उपयोग करते हैं, जिससे botnet के जरिए devices के अवैध दुरुपयोग की संभावना मिली
  • traffic analysis के ज़रिए यह पुष्टि हुई कि नया crawler "ImageSiftBot" images इकट्ठा करने के लिए Spigot पेजों को गहन रूप से request कर रहा था
  • Spigot का मुख्य लक्ष्य server CPU usage को न्यूनतम रखना और efficient operation बनाए रखना है

सस्ते image generation तरीकों पर विचार

  • images को dynamically generate करना compression की वजह से CPU पर भारी पड़ता है, इसलिए अधिक efficient तरीका ज़रूरी है
  • ध्यान इस बात पर गया कि JPEG फ़ाइलें file structure (size, color आदि) और compressed pixel data क्षेत्र से बनी होती हैं
  • कई JPEGs से केवल structured header information निकालकर, pixel data क्षेत्र को random data से भरने का तरीका तैयार किया गया
  • इससे हर बार image compress करने की ज़रूरत नहीं रहती, और images तुरंत generate की जा सकती हैं, जिससे server पर बोझ न्यूनतम रहता है

JPEG file structure और वास्तविक implementation

  • JPEG फ़ाइल कई chunks (जिनमें markers और length होती है) से बनी होती है
  • header/meta information को रखा जाता है, compressed pixel data की लंबाई दर्ज की जाती है, और केवल इसी क्षेत्र में random data डाला जाता है
  • 514 JPEG samples के उपयोग पर, पूरे header information और आवश्यक structured data का आकार केवल लगभग 500KB था, इसलिए memory पर बोझ बहुत कम है
  • code example: हर template के pixel data chunk में random numbers भरकर image generate की जाती है

वास्तविक उपयोग के परिणाम और open source रिलीज़

  • वास्तविक image viewers, pixel क्षेत्र पूरी तरह random होने पर भी कुछ हद तक image दिखा सकते हैं
  • web crawlers के लिए त्रुटियों की पहचान करना कठिन होता है, और data collection की लागत बढ़ जाती है
  • 1280x960, 200~300KB size की JPEG के आधार पर लगभग 900 images प्रति सेकंड generate की गईं, इसलिए real-time processing में दिक्कत नहीं हुई
  • Spigot के कुल पेजों में से 60% पर यह तरीका लागू है, और URL-आधारित random seed का उपयोग कर दोबारा request पर वही image लौटाई जाती है
  • ImageSiftBot, Meta, AmazonBot, GPTBot आदि से उच्च request volume देखा गया
  • मुख्य उद्देश्य कम server resources के साथ crawlers पर बोझ डालना है

Huffman code और अतिरिक्त optimization

  • JPEG का pixel data Huffman encoding का उपयोग करता है, इसलिए पूरी तरह random data डालने पर कुछ viewers में errors आ सकती हैं
  • सरल bit masking (0x6D) तकनीक जोड़कर लगातार 3 या अधिक 1 आने से रोका गया, जिससे invalid Huffman codes की संभावना 90% से घटकर 4% से कम हो गई
  • पूरी तरह valid Huffman stream भी बनाई जा सकती है, लेकिन server resources और development time की तुलना में उसका लाभ बहुत कम है

निष्कर्ष

  • Spigot की नकली JPEG generation विधि, असाधारण efficiency के साथ server resources बचाते हुए crawlers में भ्रम और resource wastage पैदा करती है
  • संबंधित code 100 lines से कम का है और GitHub पर public किया गया है
  • यह एक सरल लेकिन रचनात्मक web traffic defense और distribution technique है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-07-13
Hacker News राय

  • यह तो उम्मीद के मुताबिक था कि robots.txt फ़ाइल /spigot/ ट्री के लिए robots access को ब्लॉक कर रही है, लेकिन यह पता चला कि URL से सिर्फ /spigot/ हटाने पर भी Spigot तक पहुँचना संभव है, और क्योंकि /~auj namespace को robots.txt से ब्लॉक नहीं किया गया है, इसलिए कोई भला crawler भी अगर संयोग से उस path पर पहुँच जाए तो infinite page loop में फँस सकता है, जो काफ़ी अप्रिय स्थिति है robots.txt संदर्भ लिंक

    • पहले लेखक की एक टिप्पणी में यह कहा गया था कि उन्होंने अलग से robots.txt configure नहीं किया था; उन्होंने कहा कि इस तरह इतना चरम कदम उठाने पर उन्हें आपत्ति इसलिए है क्योंकि उन्हें यह विचार पसंद नहीं कि crawler से होने वाले DOS को रोकने के लिए वेबसाइट ऑपरेटर को जानबूझकर ऐसी सेटिंग करनी पड़े। उनका मानना है कि कोई वैध crawler किसी एक साइट को लगातार 15 requests प्रति सेकंड से ज़्यादा की दर पर scrape नहीं करना चाहिए

    • यहाँ तक कि भले crawler भी infinite page loop में फँस जाएँ, इस बात पर भी यह संदेह व्यक्त किया गया कि वेबसाइट ऑपरेटर पर scrape करने वालों के प्रति "दयालु" होने की कोई ज़िम्मेदारी है भी या नहीं; ज़रूरी ही क्यों हो

  • अगर यह पहचान लिया जाए कि crawler robots.txt को नज़रअंदाज़ कर रहा है, तो उसे 'कचरा' जानकारी देने के बजाय network connection को व्यस्त रखकर छोड़ देना ज़्यादा प्रभावी हो सकता है; endpoint पर अनंत कचरा परोसना आखिर क्यों ज़रूरी है, यह स्पष्ट नहीं

  • AI input के लिए आने वाले scrapers को भ्रमित करने के लिए क्या हर image पर नकली caption लगा देना चाहिए? जैसे हरे blob वाली image पर "बिल्ली catnip बॉल के साथ खेल रही है" और नीली image पर "रॉबिन घोंसला बना रही है" जैसा अलग-अलग लिखना

    • कोई अच्छी तरह बना scraper image को खुद CLIP मॉडल या किसी दूसरे caption model से analyze करके दोबारा जाँच सकता है कि text description और image वास्तव में मेल खाते हैं या नहीं

  • सबसे गंभीर मामला meta (Facebook) के facebookexternalhit bot का है; दस्तावेज़ों में साफ़ लिखा है कि यह bot आधिकारिक रूप से robots.txt को ignore करता है। Facebook का कहना है कि यह malicious links detect करने के लिए है, लेकिन व्यवहार में अगर कोई दुर्भावनापूर्ण user बार-बार Facebook पर महंगे endpoint के URL submit करे, तो Facebook खुद उसकी ओर से traffic bomb जैसा असर पैदा कर देता है। नतीजा यह कि हर महीने कुछ दिनों तक साइट पर 10 r/s से ज़्यादा ट्रैफ़िक टूट पड़ता है

    • लेकिन क्या 10 r/s सच में "traffic bomb" कहलाने लायक है? एक single server पर भी यह मुश्किल से महसूस होगा

  • Spigot पर यह पोस्ट पढ़ते हुए Project Honeypot याद आ गया। 20 साल पहले इस project की script और donate किया गया MX record मेरी साइट के email harvester पकड़ने में मदद कर रहा है—ऐसे ईमेल मिलते थे तो बड़ा उत्साह होता था। उदाहरण के लिए, सूचना मिलती थी कि मेरे MX की वजह से किसी unconfirmed spam sender (IP: 172.180.164.102) को पकड़ा गया

    • honeypot script बढ़िया है, लेकिन आज के हिसाब से यह काफ़ी पुराना तरीका है। (TOS के अनुसार इसे modify भी नहीं किया जा सकता) और Python script में CGI, Zope का ही बुनियादी समर्थन है, इसलिए जो लोग WSGI app बनाते हैं उन्हें शायद wrapper लगाकर काम चलाना पड़े

  • JPEG को नकली बनाना, उसे सही तरीके से बनाने की तुलना में CPU पर बहुत कम भारी पड़ता है। साथ ही यह प्रक्रिया सामने वाले malware की तरफ़ JPEG decoding ढीली होने पर crash करा सकती है, यानी एक तरह की fuzzing भी बन सकती है

  • हाल में जो inbound traffic हज़ारों residential IPs से आता दिखा, वह ज़रूरी नहीं कि पारंपरिक botnet ही हो। यह भी हो सकता है कि बहुत से लोग 'free VPN' या 'passive income generation' tools में शामिल हों, जहाँ उनकी device दूसरे users के traffic के लिए exit node बन जाती है—यानी 'proxyware' संरचना। ऐसे में वे अनजाने में AI crawler traffic के रास्ते का हिस्सा बन सकते हैं संबंधित संदर्भ

    • आखिरकार ऐसी proxyware भी botnet का ही एक रूप है, जिसमें user स्वेच्छा से शामिल होते हैं। और ऐसे users को HN जैसी जगहों से यह पता चलने की संभावना भी कम है कि उनका IP समस्या पैदा कर रहा है, इसलिए किसी IP को अलग warning page पर भेजकर यह बताना कि 'तुम botnet का हिस्सा हो' बुरा विचार नहीं लगता। व्यावहारिक रूप से, बस सीधे block कर देना सबसे आसान है

    • राय यह भी है कि ऐसी संरचना को botnet की श्रेणी में रखना पूरी तरह उचित है

  • bots को संतुष्ट करने के तरीके पर बात करने का अंदाज़ प्रभावशाली लगा। मज़ेदार लेख था और project भी दिलचस्प है

  • "मैंने सोचा कि अपने दिए गए काम में जूझ रहे bot पर तरस खाकर उसे थोड़ा मनोरंजन कैसे दिया जाए"—यह रवैया काफ़ी नया और मज़ेदार लगा। आम तौर पर ऐसे threads गुस्से और शिकायतों से भरे होते हैं, उससे यह बिल्कुल अलग है

    • शायद यह सकारात्मक रवैया इसलिए भी संभव है क्योंकि बुरे crawlers को कष्ट और कचरा परोसने की गुंजाइश मौजूद है

  • इस लिंक का परिणाम (image) पसंद आया image देखें, इसमें किसी संदेश वाली art piece जैसा एहसास है

    • अगर असली Spigot अनुभव चाहिए, तो Firefox में F12 > Network > No Throttling को GPRS में बदलें, और Chromium में F12 > Network > Custom profile को 20kbps पर सेट करके speed limit लगाएँ—तभी असली एहसास आएगा

    • क्या यहाँ Shakespeare से जुड़ा content भी है?