किसी ने DOOM को PDF फ़ाइल के भीतर चला दिया। यह कुछ बताता है

कंप्यूटिंग की दुनिया में एक पुराना मज़ाक चलता है: DOOM आख़िरकार हर चीज़ पर चलेगा। खेल की तारीफ़ के तौर पर नहीं, चुनौती के तौर पर। 1993 के इस शूटर को अब तक एटीएम मशीनों, प्रिंटरों, प्रेग्नेंसी टेस्ट, कैलकुलेटरों, LEGO की एक अकेली ईंट और मैकबुक की टच बार पर चलाया जा चुका है।

जनवरी 2025 में एक हाई-स्कूल विद्यार्थी ने इस सूची में एक और नाम जोड़ दिया। उसने DOOM को एक PDF फ़ाइल के भीतर चला दिया।

संक्षेप में

एक हाई-स्कूल विद्यार्थी ने 2020 के Emscripten संस्करण से DOOM को asm.js में संकलित किया और उसे एक PDF के भीतर चलाया — पर्दे की हर पंक्ति के लिए एक फ़ॉर्म फ़ील्ड को डिस्प्ले बनाकर: 320×200, धूसर के छह शेड, हर फ़्रेम पर लगभग 80 मिलीसेकंड। इसमें कोई सुरक्षा-ख़ामी शामिल नहीं थी। जो भी सुविधा इस्तेमाल हुई, वह PDF विनिर्देश का प्रलेखित हिस्सा है और ठीक वैसे ही काम करती है जैसे उसे बनाया गया था। दिलचस्प बात यही है — और यही वजह है कि दस्तावेज़ों को एक बार दस मिनट देना बनता है।

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

यह असल में कैसे काम करता है

परियोजना का नाम doompdf है, बनाने वाला डेवलपर ख़ुद को ading2210 कहता है। तरीक़ा इस करतब से भी दिलचस्प है और उसके चार हिस्से हैं।

PDF, JavaScript का समर्थन करता है। किसी ऐड-ऑन या प्लगइन के रूप में नहीं — यह प्रारूप का ही हिस्सा है, अपनी मानक लाइब्रेरी के साथ, और ब्राउज़र इसे अपने अंतर्निर्मित PDF इंजनों में लागू करते हैं। यह इसलिए है ताकि फ़ॉर्म आपकी लिखी बात जाँच सकें और अन्तःक्रियात्मक दस्तावेज़ क्लिक का जवाब दे सकें। इसे किसी ने खेलों के लिए नहीं जोड़ा था।

DOOM का स्रोत कोड सार्वजनिक है — हालाँकि कहानी उस संक्षेप से अधिक बारीक है। id Software ने कोड 23 दिसंबर 1997 को प्रकाशित किया, पर ऐसे लाइसेंस के तहत जो केवल शैक्षिक उपयोग की अनुमति देता था, और वह लिनक्स पोर्ट का कोड था, DOS वाले मूल का नहीं — DMX ध्वनि लाइब्रेरी के अलग लाइसेंस की वजह से। GPL में बदलाव लगभग दो साल बाद, 3 अक्तूबर 1999 को आया। असल में यही दूसरी तारीख़ मायने रखती है: इसने DOOM को पढ़ी जा सकने वाली चीज़ से क़ानूनी तौर पर दोबारा बनाई जा सकने वाली चीज़ में बदल दिया। इसीलिए यह खेल अनपेक्षित जगहों पर उभरता रहता है।

दोनों को जोड़ा एक जान-बूझकर पुराने कंपाइलर ने। ading2210 ने Emscripten 1.39.20 इस्तेमाल किया — 2020 का संस्करण — क्योंकि वह WebAssembly नहीं, asm.js बनाता है। आजकल का Emscripten WebAssembly देता है, और PDF के पास WebAssembly चलाने का कोई परिवेश नहीं है। asm.js सामान्य JavaScript की एक सीमित बोली है, इसलिए वह वहीं चलती है जहाँ JavaScript चलता है। पुराने औज़ार उठाना पुरानी यादों का मोह नहीं था; अंदर जाने का यही अकेला रास्ता था।

फिर बचता है प्रदर्शन, वह हिस्सा जिस पर लोग ठहाका लगाते हैं। PDF के पास कोई कैनवस नहीं, कोई फ़्रेमबफ़र नहीं, पिक्सेल रँगने को कुछ नहीं। पर उसके पास फ़ॉर्म फ़ील्ड हैं। इसलिए खेल का 320×200 आउटपुट ASCII अक्षरों से बनाया जाता है — पर्दे की हर पंक्ति के लिए एक टेक्स्ट फ़ील्ड, धूसर के छह शेड में — और उतनी ही तेज़ी से ताज़ा होता है जितनी तेज़ी से वह टेक्स्ट दोबारा लिखा जा सके, यानी क़रीब 80 मिलीसेकंड प्रति फ़्रेम। इनपुट भी उसी रास्ते आता है: उन्हीं फ़ील्डों और बटनों से जिन्हें PDF इंजन पहले से सँभालना जानता है। आप सचमुच एक भरने योग्य फ़ॉर्म के भीतर DOOM खेल रहे होते हैं।

यह धीमा चलता है। एकरंगा है। पूरी तरह खेलने योग्य है, जिस कोड पर बना है उसी की तरह GPL v2 के तहत जारी है, और आप इसे Chromium-आधारित ब्राउज़र में ख़ुद आज़मा सकते हैं। बनी हुई फ़ाइल में अपनी WAD फ़ाइल डालने तक की छूट है।

फिर उसने उसी में लिनक्स चला दिया

कुछ हफ़्ते बाद उसी डेवलपर ने linuxpdf जारी किया: एक पूरा लिनक्स कर्नेल जो PDF फ़ाइल के भीतर बूट होता है — RISC-V एमुलेटर TinyEMU को उसी asm.js तरकीब से संकलित करके। कर्नेल को उठने में 30 से 60 सेकंड लगते हैं — लेखक इसे असली हार्डवेयर से सौ गुना से भी धीमा बताता है — और उसे PDF बटनों से बने आभासी कीबोर्ड से चलाया जाता है।

दस्तावेज़ के भीतर DOOM एक मज़ाक है। दस्तावेज़ के भीतर ऑपरेटिंग सिस्टम बूट करता एमुलेटेड प्रोसेसर एक तर्क है। इन दोनों के बीच कहीं, बात DOOM की रह ही नहीं जाती।

वह हिस्सा जो मज़ाकिया नहीं है

यही वह विचार है जिस पर ठहरना चाहिए। doompdf में कुछ भी शोषण (exploit) नहीं है। कोई ख़ामी नहीं मिली, कुछ तोड़ा नहीं गया, कोई सुरक्षा-छेद शामिल नहीं था। यह जो कुछ इस्तेमाल करता है, वह PDF विनिर्देश की प्रलेखित और सोची-समझी सुविधा है, जो ठीक अपनी बनावट के मुताबिक़ काम करती है।

यानी जो क्षमता एक PDF को 1993 का शूटर चलाने देती है, वही उस बिल में भी मौजूद है जिसे आप कल खोलेंगे। वह घात लगाए नहीं बैठी, छिपी हुई नहीं है — बस वहाँ है, बिना इस्तेमाल के, क्योंकि ज़्यादातर दस्तावेज़ों के पास उसे बरतने की कोई वजह नहीं।

यह कहानी का ईमानदार रूप है और यह दोनों तरफ़ काटता है। जो तर्क कहता है «दस्तावेज़ कोड चला सकता है, इसलिए सावधान रहो», उसे यह भी मानना होगा कि उस कोड की दुनिया कितनी सँकरी है।

PDF के भीतर स्क्रिप्ट क्या कर सकती है और क्या नहीं

यहीं doompdf पर लिखी ज़्यादातर बातें धुँधली हो जाती हैं, इसलिए साफ़-साफ़ कहना ज़रूरी है। जवाब पूरी तरह इस पर टिका है कि आपने फ़ाइल किसमें खोली — और दोनों आम स्थितियाँ बहुत अलग हैं।

इस तालिका को सही दिशा से पढ़िए। ब्राउज़र में स्क्रिप्ट वाला PDF एक छोटे, नीरस डिब्बे में चलता है: न कुकीज़, न स्टोरेज, न आसपास के पन्ने तक पहुँच। ठीक इसीलिए doompdf एक कौतुक है, कोई सुरक्षा-घटना नहीं; और इसीलिए «DOOM एक PDF में चलता है» PDF से डरने की वजह नहीं है।

दिलचस्प स्तंभ डेस्कटॉप रीडर वाला है। उसके पास विनिर्देश में वर्णित पूरा JavaScript API है, क्योंकि वह असली कारोबारी दस्तावेज़ों के लिए बना है। यही वह परिवेश है जहाँ किसी दस्तावेज़ से कहा जा सकता है कि खुलते ही अपनी ख़बर दे, अलग-अलग रीडर में अलग बर्ताव करे, या साथ लाई हुई किसी चीज़ को खोलने का प्रस्ताव रखे।

तो तीन बातें हर प्रोग्राम में सच रहती हैं, और यही याद रखने लायक़ हैं।

• PDF ऐसे निर्देश ले जा सकता है जो खुलते ही चल जाते हैं, इससे पहले कि आपने कुछ पढ़ा हो।
• PDF इस बात पर अलग बर्ताव कर सकता है कि उसे कौन-सा सॉफ़्टवेयर खोल रहा है: जो फ़ाइल आप देख रहे हैं, ज़रूरी नहीं कि वही आपका सहकर्मी देख रहा हो।
• PDF दिखाने से ज़्यादा साथ ले जाता है: संलग्नक, छिपी परतें, संशोधन का इतिहास और वह मेटाडेटा जिसे भेजने का इरादा आपका कभी नहीं था।

इनमें से कुछ भी PDF को रोज़मर्रा के अर्थ में ख़तरनाक नहीं बनाता। इस महीने आप दर्जनों खोलेंगे और सब ठीक रहेगा। पर इसका मतलब यह है कि हममें से ज़्यादातर लोग जो मानसिक तस्वीर लिए चलते हैं — «यह तो बस एक दस्तावेज़ है» — वह ऐसे ढंग से ग़लत है जो कभी-कभी मायने रखता है।

वह सेटिंग जिसे लगभग कोई नहीं जानता

मानक सलाह है «अपने PDF रीडर में JavaScript बंद कर दें», और सलाह अच्छी है। पर अकेले वह अधूरी है — क्योंकि ज़्यादातर लोग अब PDF किसी PDF रीडर में नहीं खोलते। वे उसे ब्राउज़र के टैब में खोलते हैं, और ब्राउज़र का अपना अलग स्विच है।

Firefox PDF स्क्रिप्टिंग चालू हालत में आता है। सेटिंग का नाम about:config में pdfjs.enableScripting है; Firefox 87 तक यह false थी और Firefox 88 से true है। सामान्य स्विच javascript.enabled इसे छूता तक नहीं: PDF व्यूअर अलग दुनिया है, अलग सेटिंग के साथ।

Chrome और Edge PDF स्क्रिप्टिंग के लिए कोई अलग स्विच देते ही नहीं। PDF के भीतर की स्क्रिप्ट उस साइट की JavaScript अनुमति के अधीन है जहाँ से फ़ाइल आई; उसे पता-पट्टी के नियंत्रणों से साइट-दर-साइट बंद किया जा सकता है, या chrome://settings/content/javascript से पूरी तरह — जो कहीं ज़्यादा भोथरा औज़ार है।

Adobe Acrobat Reader में वही स्विच है जिसका ज़िक्र सब करते हैं: Preferences → JavaScript → Enable Acrobat JavaScript। यही निशान हटाने लायक़ है, क्योंकि Acrobat बड़े API वाला रीडर है और सामान्य काम में जान-बूझकर स्क्रिप्ट वाला PDF शायद ही कोई इस्तेमाल करता है।

व्यावहारिक रूप में: Acrobat में बंद कर देना और ब्राउज़र को छेड़ना नहीं — यह समझदार और संतुलित चुनाव है। पर यह मान लेना कि आपने हर जगह बंद कर दिया, जबकि किया सिर्फ़ Acrobat में — समझदारी नहीं।

इस जानकारी का करें क्या

व्यावहारिक जवाब छोटा है और उन दस मिनटों के लायक़ है।

डेस्कटॉप रीडर में JavaScript बंद कर दें। Acrobat Reader में: Preferences → JavaScript। इससे जोखिम की एक पूरी श्रेणी हट जाती है और — मानना पड़ेगा — फ़ॉर्म फ़ील्ड में DOOM खेलने की सुविधा के अलावा कुछ नहीं जाता।

रीडर को अद्यतन रखें। स्क्रिप्टिंग अंदर आने का एक रास्ता है। फ़ॉन्ट और चित्र डिकोड करने वाले कोड की ख़ामियाँ दूसरा रास्ता हैं, और वही अपडेट ठीक करते हैं — ऐतिहासिक रूप से यही ज़्यादा आम रास्ता भी है।

अनपेक्षित दस्तावेज़ों को अनपेक्षित ही समझें। जिस कंपनी से आपने कभी कुछ ख़रीदा ही नहीं, उसका बिल एक पल ठहरकर सोचने लायक़ है, चाहे किसी भी प्रारूप में आए। यह किसी भी सेटिंग से ज़्यादा क़ीमती है।

ग़ौर कीजिए कि इन तीनों में साझा क्या है: इनमें से कोई भी न PDF छोड़ने को कहता है, न आम तौर पर दस्तावेज़ों पर शक करने को। ये घर का दरवाज़ा बंद करने जैसे हैं — सस्ते, नीरस और ठीक इसीलिए समझदारी भरे कि ख़तरा छोटा है, पर शून्य नहीं।

इस परियोजना को मिला ध्यान क्यों जायज़ है

doompdf को «इंटरनेट की दिलचस्पी» की फ़ाइल में डालकर आगे बढ़ जाना आसान होता। मेरा कहना है कि यह उससे ज़्यादा उपयोगी है, और वजह का सुरक्षा-नाटक से कोई लेना-देना नहीं।

फ़ाइल प्रारूपों की जो समझ ज़्यादातर लोगों के पास है, वह पूरी तरह इस पर टिकी है कि प्रारूप किस काम आते हैं। दस्तावेज़ पढ़ने के लिए हैं। स्प्रेडशीट अंकों के लिए। तस्वीरें देखने के लिए। यह मॉडल लगभग हमेशा चलता है, और इसीलिए उसे हिलाना इतना मुश्किल है — और इसीलिए «PDF में सक्रिय सामग्री हो सकती है» वाली बात आम तौर पर शिष्ट संदेह से मिलती है।

दस्तावेज़ के भीतर खेलने योग्य खेल दस सेकंड में वह कर देता है जो एक लेख हज़ार शब्दों में मुश्किल से कर पाता है। वह अमूर्त दावे की जगह ऐसी चीज़ रख देता है जिस पर क्लिक किया जा सके।

और गहरी बात PDF से कहीं आगे जाती है। प्रारूप दशकों तक सुविधाएँ जमा करते जाते हैं। हर जोड़ किसी ऐसे व्यक्ति के लिए समझदारी भरा था जो कोई असली समस्या हल कर रहा था — फ़ॉर्म की जाँच सचमुच उपयोगी है, और अपना हिसाब ख़ुद जाँच लेने वाला दस्तावेज़ भी। नतीजा यह कि रोज़ जिन साधारण चीज़ों का हम आदान-प्रदान करते हैं, वे अपने नाम से कहीं अधिक सक्षम हैं। और कोई क्षमता एक बार विनिर्देश में आ जाए, तो हर उस व्यक्ति के लिए उपलब्ध है जो वह विनिर्देश पढ़ता है।

रोज़मर्रा के लिए इसका क्या मतलब

यहाँ कुछ भी PDF के ख़िलाफ़ तर्क नहीं है। ऐसा दस्तावेज़ भेजने के लिए, जो हर जगह, हर मशीन पर और सालों बाद भी एक जैसा दिखे, यह आज भी सबसे अच्छा प्रारूप है। यह सचमुच कठिन समस्या है और PDF ने उसे हल किया। जो सुविधाएँ doompdf को संभव बनाती हैं, वही भरने योग्य कर-फ़ॉर्म को भी संभव बनाती हैं।

यह इस बात के पक्ष में तर्क है कि आप जानें आपके हाथ में क्या है। जो बहुमुखी क्षमता दस्तावेज़ को खेल ढोने देती है, वही उसे स्क्रिप्ट, संलग्नक, छिपी परतें और वह मेटाडेटा ढोने देती है जिसे भेजने का इरादा आपका नहीं था। इन्हें समझना सार्थक है, और इनमें से कोई घबराने की वजह नहीं।

यही एक कारण भी है कि PDF Manipulator पूरी तरह आपके अपने कंप्यूटर पर चलता है। फ़ाइलें जोड़ते, बाँटते या बदलते समय जितने कम पक्ष शामिल हों उतना अच्छा — इसलिए नहीं कि ऑनलाइन सेवाएँ बदनीयत हैं, बल्कि इसलिए कि जो दस्तावेज़ आपकी मशीन से कभी बाहर गया ही नहीं, उसके बारे में सोचना उस दस्तावेज़ से कहीं आसान है जो किसी और के सर्वर पर हो आया है।

अपनी PDF फ़ाइलों पर पूरी तरह ऑफ़लाइन काम करें — PDF Manipulator मुफ़्त है →

डाउनलोड

हमें समर्थन

स्रोत

• ading2210, GitHub पर doompdf — स्रोत कोड और तकनीकी विवरण; Emscripten 1.39.20, छह शेड में 320×200 आउटपुट, ~80 मि.से. प्रति फ़्रेम, GPL v2
• ading2210, GitHub पर linuxpdf — PDF के भीतर TinyEMU RISC-V एमुलेटर पर लिनक्स, 30–60 सेकंड में बूट
• खेलने योग्य संस्करण (Chromium-आधारित ब्राउज़र)
• Eric Lawrence, Browser Security Bugs that Aren’t: JavaScript in PDF — ब्राउज़रों के PDF इंजन स्क्रिप्ट को क्या करने देते हैं और क्या नहीं
• Adobe, Restrict JavaScript API access in Acrobat
• DoomWiki, Licences — कोड 23 दिसंबर 1997 को प्रकाशित, 3 अक्तूबर 1999 को GPL में बदला
• The Register, It’s Doom … running in a PDF file
• Ars Technica, This PDF contains a playable copy of Doom