बाइनरी फ़ाइल निरीक्षक

कोई प्रोग्राम फ़ाइल डालें — Windows PE (.exe, .dll), Linux ELF बाइनरी, या macOS/iOS Mach-O — और भारी टूल निकालने से पहले पढ़ें कि वह अपने बारे में क्या घोषित करती है: उसके हेडर, सेक्शन और सेगमेंट, वे लाइब्रेरी और फ़ंक्शन जिन्हें वह इम्पोर्ट करती है, उसके एक्सपोर्ट और सिंबल, और उसके अंदर की हर प्रिंट योग्य स्ट्रिंग, MD5 और SHA हैश तथा प्रति-सेक्शन एन्ट्रॉपी के साथ। फ़ाइल कभी आपके डिवाइस को नहीं छोड़ती और कभी चलाई नहीं जाती: वह अपलोड नहीं होती, बल्कि इसी पेज में खोली और पढ़ी जाती है, क्योंकि जिस बाइनरी पर आपको संदेह है, वही फ़ाइल है जिसे आपको किसी अजनबी के सर्वर को नहीं सौंपना चाहिए।

अंतिम अपडेट:

या फ़ाइल को इस बॉक्स में कहीं भी छोड़ें। नीचे की हर चीज़ फ़ाइल से ही, इस डिवाइस पर पढ़ी जाती है। केवल स्टैटिक विश्लेषण: फ़ाइल को पार्स किया जाता है, कभी चलाया नहीं जाता। सीमा: 128 MB।

यह पेज क्या है — और क्या नहीं है

यह एक पहली-नज़र का, स्टैटिक निरीक्षण है: फ़ाइल को पार्स किया जाता है, कभी चलाया नहीं जाता, और यहाँ कुछ भी मैलवेयर का फ़ैसला नहीं है। निष्कर्ष टिप्पणियाँ हैं, सज़ा नहीं — बिना हस्ताक्षर वाली फ़ाइल एक तथ्य है (कई वैध टूल बिना हस्ताक्षर के होते हैं), 7.2 से ऊपर एन्ट्रॉपी एक तथ्य है (पैकर इसे बढ़ाते हैं, लेकिन साधारण कंप्रेस किए गए संसाधन भी), और Authenticode हस्ताक्षर ब्लॉक का मौजूद होना यह नहीं बताता कि हस्ताक्षर मान्य है या नहीं, केवल यह कि वह वहाँ है। जिस फ़ाइल पर आपको भरोसा नहीं है, उसके बारे में दूसरी राय के लिए अवलोकन टैब में दिए गए लुकअप से उसके SHA-256 की तुलना किसी सार्वजनिक फ़ैसले से करें — हैश खोजा जाता है, फ़ाइल खुद कभी भेजी नहीं जाती। Android पैकेजों के लिए उनका अपना समर्पित रीडर है, APK Analyzer; कोई प्रोग्राम नेटवर्क पर क्या करता है, वह PCAP Analyzer का विषय है; और सहायक लेख, क्या AI एजेंट आपके ऐप को रिवर्स-इंजीनियर कर सकते हैं?, बताता है कि स्वचालित विश्लेषण अब कितनी दूर जा चुका है।

कोई प्रोग्राम फ़ाइल चलने से पहले क्या घोषित करती है

हर नेटिव प्रोग्राम फ़ाइल ऑपरेटिंग सिस्टम के लोडर के लिए लिखी गई मंशा की घोषणा से शुरू होती है। Windows PE अपनी लक्षित मशीन, अपना बिल्ड टाइमस्टैम्प, वह पता जहाँ वह लोड होना चाहती है और वह सबसिस्टम जिसका वह अनुमान लगाती है, बताती है; उसकी सेक्शन तालिका बताती है कि कोड, डेटा और संसाधन कहाँ रहते हैं, और उसकी इम्पोर्ट तालिका हर उस लाइब्रेरी और फ़ंक्शन को — नाम से — सूचीबद्ध करती है जिसे वह बुलाने का इरादा रखती है, जो किसी बंद बाइनरी के पास विषय-सूची के सबसे करीब चीज़ है। ELF बाइनरी अपनी क्लास, एंडियननेस और मशीन, उसे लॉन्च करने वाले इंटरप्रेटर, कर्नेल को मैप करने वाले सेगमेंट और क्रम में, उसे चाहिए साझा लाइब्रेरी घोषित करती है। Mach-O अपना CPU और फ़ाइल प्रकार, अपने सेगमेंट और सेक्शन, वे dylib जिनसे वह जुड़ी है, बिल्ड की पहचान करने वाला UUID, और यह कि उसका कोड हस्ताक्षरित है या FairPlay-एन्क्रिप्टेड है, घोषित करती है। इनमें से किसी के लिए भी फ़ाइल को चलाना, फ़ाइल पर भरोसा करना या फ़ाइल को अपलोड करना ज़रूरी नहीं है — यह सब उन हेडर में है जिन्हें लोडर खुद पढ़ेगा।

यह पेज ठीक उसी परत को पढ़ता है, और जानबूझकर केवल पहली परत को। यह कुछ भी डीकंपाइल नहीं करेगा, कुछ भी अनपैक नहीं करेगा और आपको नहीं बताएगा कि कोड क्या करता है — वह Ghidra, IDA और उन एजेंट-चालित टूलचेन का काम है जिनकी चर्चा सहायक लेख करता है। पहली नज़र का मक़सद है प्राथमिक छँटाई: क्या यह वही आर्किटेक्चर है जिसकी आपने उम्मीद की थी, क्या यह हस्ताक्षरित है, क्या यह नेटिव भेष में .NET असेंबली है, क्या कोई एक सेक्शन संदिग्ध रूप से घना डेटा लिए हुए है, क्या इम्पोर्ट सूची ऐसी लाइब्रेरी बताती है जिन्हें बुलाने का प्रोग्राम के पास कोई कारण नहीं है, और क्या आपको भेजी गई फ़ाइल वही है जो बाकी सबको मिली — जिसका जवाब हैश सीधे दे देते हैं (और हैश जनरेटर टेक्स्ट या छोटी फ़ाइलों के लिए इसकी पुष्टि करता है)। स्थानीय रूप से पढ़े गए पाँच मिनट के हेडर, किसी भारी टूल के इंस्टॉल होने से पहले ही, इनमें से अधिकांश का जवाब दे देते हैं।

अक्सर पूछे जाने वाले प्रश्न

क्या मेरी फ़ाइल कहीं अपलोड होती है?

नहीं। फ़ाइल इसी पेज में, आपके डिवाइस पर खोली और पार्स की जाती है, और कुछ भी अपलोड, प्रसारित या संग्रहीत नहीं होता — फ़ाइल का विश्लेषण करने से कोई नेटवर्क अनुरोध नहीं होता। पेज पर एकमात्र बाहरी लिंक VirusTotal लुकअप है, और वह फ़ाइल के SHA-256 हैश को टेक्स्ट के रूप में खोजता है; फ़ाइल खुद कभी भेजी नहीं जाती। पेज लोड हो जाने के बाद ऑफ़लाइन भी काम करता है।

क्या यह मुझे बता सकता है कि कोई फ़ाइल मैलवेयर है या नहीं?

नहीं, और कोई भी हेडर रीडर जो इसका वादा करे, वह बढ़ा-चढ़ाकर बेच रहा है। यह पेज वह रिपोर्ट करता है जो फ़ाइल घोषित करती है — प्रारूप, आर्किटेक्चर, सेक्शन, इम्पोर्ट, एक्सपोर्ट, स्ट्रिंग, हस्ताक्षर की मौजूदगी — जो लापरवाह मामलों को पकड़ने के लिए काफ़ी है: वह “चालान” जो असल में 32-बिट एक्ज़ीक्यूटेबल है, वह बिल्ड जिसमें एक असंभव रूप से घना सेक्शन है, वह बिना हस्ताक्षर वाला अपडेटर जिसका हैश विक्रेता द्वारा प्रकाशित किसी भी चीज़ से मेल नहीं खाता। कोड असल में क्या करता है, इसका निर्णय करने के लिए डीकंपाइल, सैंडबॉक्सिंग या किसी प्रतिष्ठित स्कैनर के फ़ैसले की ज़रूरत होती है। यहाँ साफ़-सुथरा दिखने वाले परिणाम को “हेडर में कुछ भी गलत नहीं दिखता” समझें, कभी सुरक्षा प्रमाणपत्र न समझें।

एन्ट्रॉपी क्या है, और 7.2 ही निशान क्यों है?

शैनन एन्ट्रॉपी मापती है कि बाइट्स का कोई हिस्सा कितना यादृच्छिक (रैंडम) दिखता है, 0 (सभी एक ही बाइट) से 8 (यादृच्छिक से अलग न किया जा सकने वाला) तक। साधारण कंपाइल किया गया कोड और टेक्स्ट 7 से काफ़ी नीचे रहते हैं; कंप्रेस किया गया डेटा 8 के करीब रहता है, और एन्क्रिप्टेड डेटा प्रभावी रूप से 8 होता है। पैकर किसी प्रोग्राम के असली कोड को कंप्रेस या एन्क्रिप्ट करते हैं, इसलिए लगभग 7.2 से ऊपर का सेक्शन “यहाँ कुछ दबाया गया था” का एक मानक प्राथमिक-छँटाई निशान है — लेकिन इंस्टॉलर, कंप्रेस किए गए संसाधन, एम्बेडेड मीडिया और आधुनिक रनटाइम भी पूरी तरह वैध फ़ाइलों पर उच्च-एन्ट्रॉपी सेक्शन बनाते हैं। यह और ध्यान से देखने का एक कारण है, निष्कर्ष नहीं।

मेरी फ़ाइल इतनी कम संरचना क्यों दिखाती है?

क्योंकि पेज वह रिपोर्ट करता है जो फ़ाइल वास्तव में घोषित करती है, और कुछ फ़ाइलें बहुत कम घोषित करती हैं। किसी स्ट्रिप की गई ELF में सेक्शन हेडर तालिका बिल्कुल हो ही नहीं सकती (केवल सेगमेंट); कोई हाथ से बनी या कटी हुई फ़ाइल उन संरचनाओं से पहले समाप्त हो सकती है जिनका वादा उसका हेडर करता है — जिस स्थिति में नोट ठीक यही कहते हैं और दिखाई गई हर चीज़ फिर भी मौजूद बाइट्स से ही पढ़ी गई थी। और कुछ प्रारूप गहरे पार्सर के दायरे से बाहर ही होते हैं: वे नाम से पहचाने जाते हैं (ZIP, PDF, छवियाँ आदि) और उन्हें सामान्य तथ्य मिलते हैं — आकार, हैश, एन्ट्रॉपी, स्ट्रिंग — बिना गढ़े गए विवरण के।