burrowers/garbleGo बिल्ड्स को Go टूलचेन को रैप करके, पहचानकर्ताओं, पैकेज पथों और स्थिति डेटा को हैश से बदलकर तथा डीबग और बिल्ड जानकारी हटाकर अस्पष्ट बनाता है।
go install mvdan.cc/garble@latest # or @master
Go कोड को Go टूलचेन को रैप करके अस्पष्ट करें। इसके लिए Go 1.27 या बाद का संस्करण आवश्यक है।
garble build [build flags] [packages]
यह टूल garble test को भी सपोर्ट करता है ताकि अस्पष्ट कोड के साथ टेस्ट चलाए जा सकें,
garble run सरल प्रोग्राम को अस्पष्ट करके निष्पादित करने के लिए,
garble reverse स्टैक ट्रेस जैसे टेक्स्ट को डी-ऑब्फस्केट करने के लिए,
और garble bug पहले से भरा हुआ बग रिपोर्ट फाइल करने के लिए।
सभी उपलब्ध कमांड और फ्लैग देखने के लिए garble -h चलाएँ।
एक ऐसा बाइनरी बनाएँ जो सामान्य बिल्ड की तरह काम करे, लेकिन मूल स्रोत कोड के बारे में यथासंभव कम जानकारी रखे।
यह टूल इस प्रकार डिज़ाइन किया गया है:
cmd/go के साथ युग्मित, मॉड्यूल और बिल्ड कैशिंग का समर्थन करने के लिएयह टूल Go कंपाइलर और लिंकर के कॉल को रैप करता है ताकि Go बिल्ड को रूपांतरित किया जा सके, जिससे:
-literals फ्लैग दिया गया हो-tiny फ्लैग दिया गया होयह टूल सभी समर्थित पैकेजों को अस्पष्ट करता है जो बनाए जा रहे हैं, जिसमें मानक रनटाइम भी शामिल है।
असमर्थित runtime/cgo और crypto/internal/fips140 पैकेजों को बाहर रखा गया है।
रनटाइम अस्पष्टीकरण Go के समर्थित GOOS/GOARCH लक्ष्यों का पालन करता है; Garble
संकीर्ण आर्किटेक्चर अनुमति सूची नहीं रखता।
ध्यान दें कि garble build जैसी कमांड आपके $PATH में मिली go संस्करण का उपयोग करेंगी। Go के विभिन्न संस्करणों का उपयोग करने के लिए, आप GOTOOLCHAIN का उपयोग कर सकते हैं।
एक सामान्य प्रश्न यह है कि Go, जो एक संकलित भाषा है, के लिए कोड ऑब्फस्केटर की आवश्यकता क्यों है। Go बाइनरीज़ में मूल स्रोत के बारे में आश्चर्यजनक मात्रा में जानकारी होती है; डीबग जानकारी और सिंबल टेबल हटाए जाने के बाद भी, ट्रेस, रिफ्लेक्शन और डीबगिंग के लिए कई नाम और स्थितियाँ बनी रहती हैं।
Go के कुछ उपयोग मामलों में अंतिम उपयोगकर्ता के साथ Go बाइनरी साझा करना आवश्यक होता है। यदि बाइनरी का स्रोत कोड निजी है या खरीद की आवश्यकता है, तो इसका अस्पष्टीकरण रिवर्स इंजीनियरिंग को हतोत्साहित करने में मदद कर सकता है।
एक समान उपयोग मामला Go लाइब्रेरी का है जिसका स्रोत निजी या खरीदा हुआ है। चूँकि Go लाइब्रेरीज़ को बाइनरी रूप में आयात नहीं किया जा सकता, और Go प्लगइन्स की अपनी कमियाँ हैं, अस्पष्ट स्रोत कोड साझा करना एक विकल्प बन जाता है। देखें #369।
अस्पष्टीकरण लाइसेंसिंग से पूरी तरह असंबंधित पहलुओं में भी मदद कर सकता है।
उदाहरण के लिए, -tiny फ्लैग बाइनरीज़ को 15% छोटा बना सकता है,
जो ऐप आकार कम करने के लिए Android में सामान्य प्रथा के समान है।
अस्पष्टीकरण ने कुछ ओपन सोर्स डेवलपर्स को एंटी-वायरस स्कैन द्वारा Go बाइनरीज़ को
गलत तरीके से मैलवेयर मानने की समस्या से निपटने में भी मदद की है।
-literals फ्लैग का उपयोग करने से स्ट्रिंग्स जैसे लिटरल एक्सप्रेशन को अधिक जटिल
एक्सप्रेशन से बदल दिया जाता है, जो रन-टाइम पर समान मान देते हैं।
-ldflags=-X के माध्यम से इंजेक्ट किए गए स्ट्रिंग लिटरल भी इस फ्लैग द्वारा बदल दिए जाते हैं।
यह सुविधा ऑप्ट-इन है, क्योंकि यह इनपुट कोड के आधार पर धीमा कर सकती है।
कॉन्स्टेंट एक्सप्रेशन में उपयोग किए गए लिटरल को अस्पष्ट नहीं किया जा सकता, क्योंकि वे
कंपाइल समय पर हल हो जाते हैं। इसमें उदाहरण के लिए, const घोषणा का कोई भी
एक्सप्रेशन शामिल है।
ध्यान दें कि पर्याप्त प्रयास दिए जाने पर इस प्रक्रिया को उलटा किया जा सकता है; देखें #984।
-tiny फ्लैग के साथ, Go बाइनरी से और भी अधिक जानकारी हटा दी जाती है।
स्थिति जानकारी को अस्पष्ट करने के बजाय पूरी तरह हटा दिया जाता है।
पैनिक, घातक त्रुटियाँ, और ट्रेस/डीबग जानकारी प्रिंट करने वाला रनटाइम कोड हटा दिया जाता है।
लिंक समय पर कई सिंबल नाम भी बाइनरी सेक्शन से छोड़ दिए जाते हैं।
कुल मिलाकर, यह बाइनरीज़ को लगभग 15% छोटा बना सकता है।
इस फ्लैग के साथ, कोई पैनिक या घातक रनटाइम त्रुटि कभी प्रिंट नहीं होगी, लेकिन उन्हें
recover के साथ सामान्य रूप से आंतरिक रूप से संभाला जा सकता है।
ध्यान दें कि यह फ्लैग क्रैश को डीबग करना कठिन बना सकता है, क्योंकि पैनिक बिना स्टैक ट्रेस
प्रिंट किए पूरे प्रोग्राम को समाप्त कर देगा, और स्रोत कोड स्थितियाँ और कई नाम हटा दिए जाते हैं।
इसी तरह, इस मोड में garble reverse आमतौर पर उपयोगी नहीं होता।
देखें: CONTROLFLOW.md
garble build में लगभग go build से दोगुना समय लगना चाहिए, क्योंकि इसे
दो बिल्ड पूरे करने होते हैं। मूल बिल्ड, ताकि इनपुट कोड को लोड और टाइप-चेक किया जा सके,
और फिर अस्पष्ट बिल्ड।
Garble एक समय में एक पैकेज को अस्पष्ट करता है, जो Go के एक समय में एक पैकेज
कंपाइल करने के तरीके को दर्शाता है। यह Garble को Go के बिल्ड कैश का पूरी तरह समर्थन
करने की अनुमति देता है; इंक्रीमेंटल garble build कॉल को केवल संशोधित कोड को
पुनः बिल्ड और पुनः अस्पष्ट करना चाहिए।
ध्यान दें कि garble build का पहला कॉल तुलनात्मक रूप से धीमा हो सकता है,
क्योंकि इसे पहली बार प्रत्येक पैकेज को अस्पष्ट करना होता है। यह go clean -cache के साथ
GOCACHE साफ़ करने और शुरू से go build चलाने के समान है।
Garble काम का पुनः उपयोग करने के लिए अपने स्वयं के कैश का भी उपयोग करता है, जो Go के GOCACHE के समान है।
यह डिफ़ॉल्ट रूप से आपकी उपयोगकर्ता की कैश निर्देशिका के अंतर्गत एक निर्देशिका में होता है,
जैसे ~/.cache/garble, और इसे GARBLE_CACHE सेट करके कहीं और रखा जा सकता है।
Go की तरह ही, garble बिल्ड प्रकृति में नियतात्मक और पुनरुत्पादनीय होते हैं।
इसके महत्वपूर्ण लाभ हैं, जैसे बिल्ड कैश करना और स्टैक ट्रेस को डी-ऑब्फस्केट करने के लिए
garble reverse का उपयोग कर पाना।
डिफ़ॉल्ट रूप से, garble प्रत्येक पैकेज को एक अनूठे तरीके से अस्पष्ट करेगा, जो इसके बिल्ड इनपुट बदलने पर बदल जाएगा: garble का संस्करण, Go का संस्करण, पैकेज का स्रोत कोड, या GOOS या -tags जैसा कोई भी बिल्ड पैरामीटर। यह एक उचित डिफ़ॉल्ट है क्योंकि उन इनपुट्स का अनुमान लगाना बहुत कठिन है।
आप अपना स्वयं का अस्पष्टीकरण यादृच्छिकता सीड प्रदान करने के लिए -seed फ्लैग का उपयोग कर सकते हैं।
एक ही सीड का पुनः उपयोग समान कोड अस्पष्टीकरण उत्पन्न करने में मदद कर सकता है,
जो डीबगिंग या समस्याओं को पुनरुत्पादित करने में सहायक हो सकता है।
नियमित रूप से सीड बदलना लंबे समय में रिवर्स इंजीनियरिंग के विरुद्ध भी मदद कर सकता है,
अन्यथा कोई यह देख सकता है कि Go की मानक लाइब्रेरी कैसे अस्पष्ट की जाती है, इसमें परिवर्तनों को देखकर
यह अनुमान लगाया जा सकता है कि बिल्ड की एक श्रृंखला में Go या garble संस्करण कब बदले गए।
प्रत्येक बिल्ड के लिए हमेशा एक अलग सीड का उपयोग करने के लिए, -seed=random का उपयोग करें।
ध्यान दें कि कस्टम सीड्स का उपयोग करते समय अतिरिक्त सावधानी बरतनी चाहिए:
यदि बिल्ड में उपयोग किया गया -seed मान खो जाता है, तो garble reverse काम नहीं करेगा।
इनमें से अधिकांश समय और प्रयास के साथ सुधर सकती हैं। इस अनुभाग का उद्देश्य इस टूल की वर्तमान कमियों का दस्तावेज़ीकरण करना है।
निर्यातित मेथड्स को इस समय कभी अस्पष्ट नहीं किया जाता, क्योंकि उन्हें इंटरफेस द्वारा आवश्यकता हो सकती है। यह क्षेत्र कार्य प्रगति पर है; देखें #3।
फ़ाइलों या पैकेजों के चयन को अस्पष्ट करने से बाहर करने का कोई समर्थित तरीका नहीं है। अधिकतर, उपयोगकर्ता किसी बग के समाधान के लिए ऐसा करना चाहेगा; कृपया इसके बजाय बग फाइल करें।
Go प्रोग्राम एक समय में एक पैकेज को इनिशियलाइज़ किए जाते हैं, जहाँ आयातित पैकेज हमेशा उनके आयातकों से पहले इनिशियलाइज़ होते हैं, और अन्यथा वे अपने आयात पथों के शाब्दिक क्रम में इनिशियलाइज़ होते हैं। चूँकि garble आयात पथों को अस्पष्ट करता है, यह शाब्दिक क्रम मनमाने ढंग से बदल सकता है।
Go प्लगइन्स वर्तमान में समर्थित नहीं हैं; देखें #87।