प्रीफिक्स काढल्यानंतरही proxychains तिथेच असतो

तुम्ही आदेशातून proxychains काढता, तो पुन्हा चालवता आणि तरीही रॅपरचा सुरुवातीचा संदेश दिसतो. ॲप्लिकेशन सेटिंग शोधण्यापूर्वी लाँच वातावरण तपासा.

लिनक्सवर LD_PRELOAD डायनॅमिक लिंकरला सांगते की निर्दिष्ट शेअर्ड ऑब्जेक्ट सामान्य लायब्ररींपूर्वी लोड करावेत. प्रॉक्सी रॅपर हे यंत्रणा समर्थित नेटवर्क कॉल अडवण्यासाठी वापरू शकतात. जर कोणी शेलमध्ये हे चल एक्सपोर्ट केले असेल, तर नंतरचे चाइल्ड प्रोग्राम ते वारशाने घेऊ शकतात, त्यांच्या कमांड ओळींमध्ये रॅपर प्रीफिक्स नसला तरीही.

त्या शेलमधील पहिली फक्त-वाचन तपासणी ही आहे:

printf '%s\n' "$LD_PRELOAD"

प्रॉक्सी रॅपर लायब्ररी शोधा, पण चलामध्ये जाणीवपूर्वक लोड केलेल्या इतर लायब्ररींचाही समावेश असू शकतो ही शक्यता ठेवा. सर्व नोंदी डोळे झाकून काढल्यास दुसरे साधन बिघडू शकते.

लाँचर बदला, नंतर प्रोग्राम पुन्हा सुरू करा

बाधित प्रोग्राम सुरू करणाऱ्या वातावरणातून अनपेक्षित प्रॉक्सी प्रीलोड काढा. स्टार्टअप फाइल किंवा लाँचर ते एक्सपोर्ट करत असेल, तर तो स्रोतही दुरुस्त करा. Bash लाँचसाठी स्टार्टअप फाइलांचा क्रम पाळा. स्वच्छ शेलचा नवीन चाइल्ड आणि चल अजूनही धरून ठेवणारा जुना टर्मिनल किंवा IDE यांचा चाइल्ड वेगळी परिस्थिती आहे.

वातावरण चल अनसेट केल्याने आधीच त्यासह सुरू झालेल्या प्रोसेसमधून लायब्ररी अनलोड होत नाही. त्यामुळे चालू असलेले ॲप्लिकेशन दुरुस्त केलेल्या लाँच मार्गाने पुन्हा सुरू होईपर्यंत रॅपर टिकवू शकते.

चल नसल्यास /etc/ld.so.preload सारखे इतर कॉन्फिगर केलेले प्रीलोड स्रोत आणि प्रत्यक्ष लाँचर तपासा. या यंत्रणेच्या मर्यादा आहेत: स्थिर एक्झिक्युटेबल, थेट सिस्टम कॉल आणि सुरक्षित-अंमलबजावणी निर्बंध वेगळे वागू शकतात. sudo सोबत रॅपरचा क्रम महत्त्वाचा. वारशाने मिळालेला प्रीलोड अनपेक्षित अडवणूक स्पष्ट करतो; सर्व प्रकारचा नेटवर्क रहदारी प्रॉक्सी वापरतो याचा तो पुरावा नाही.