एमआईटी पाठ्यक्रम "कंप्यूटर सिस्टम सुरक्षा"। व्याख्यान 21: डेटा ट्रैकिंग, भाग 2

मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी। व्याख्यान पाठ्यक्रम # 6.858। "कंप्यूटर सिस्टम की सुरक्षा।" निकोलाई ज़ेल्डोविच, जेम्स मिकेंस। 2014 साल

कंप्यूटर सिस्टम सुरक्षा सुरक्षित कंप्यूटर सिस्टम के विकास और कार्यान्वयन पर एक कोर्स है। व्याख्यान खतरे के मॉडल को कवर करते हैं, हमले जो सुरक्षा से समझौता करते हैं, और हाल के वैज्ञानिक कार्यों के आधार पर सुरक्षा तकनीक। विषयों में ऑपरेटिंग सिस्टम (OS) सुरक्षा, सुविधाएँ, सूचना प्रवाह प्रबंधन, भाषा सुरक्षा, नेटवर्क प्रोटोकॉल, हार्डवेयर सुरक्षा और वेब अनुप्रयोग सुरक्षा शामिल हैं।

व्याख्यान 1: "परिचय: खतरे के मॉडल" भाग 1 / भाग 2 / भाग 3
व्याख्यान 2: "हैकर हमलों का नियंत्रण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 3: "बफर ओवरफ्लो: शोषण और संरक्षण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 4: "पृथक्करण का पृथक्करण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 5: "सुरक्षा प्रणालियाँ कहाँ से आती हैं?" भाग 1 / भाग 2
व्याख्यान 6: "अवसर" भाग 1 / भाग 2 / भाग 3
व्याख्यान 7: "मूल ग्राहक सैंडबॉक्स" भाग 1 / भाग 2 / भाग 3
व्याख्यान 8: "नेटवर्क सुरक्षा मॉडल" भाग 1 / भाग 2 / भाग 3
व्याख्यान 9: "वेब अनुप्रयोग सुरक्षा" भाग 1 / भाग 2 / भाग 3
व्याख्यान 10: "प्रतीकात्मक निष्पादन" भाग 1 / भाग 2 / भाग 3
व्याख्यान 11: "उर / वेब प्रोग्रामिंग भाषा" भाग 1 / भाग 2 / भाग 3
व्याख्यान 12: नेटवर्क सुरक्षा भाग 1 / भाग 2 / भाग 3
व्याख्यान 13: "नेटवर्क प्रोटोकॉल" भाग 1 / भाग 2 / भाग 3
व्याख्यान 14: "एसएसएल और एचटीटीपीएस" भाग 1 / भाग 2 / भाग 3
व्याख्यान 15: "मेडिकल सॉफ्टवेयर" भाग 1 / भाग 2 / भाग 3
व्याख्यान 16: "साइड चैनल हमलों" भाग 1 / भाग 2 / भाग 3
व्याख्यान 17: "उपयोगकर्ता प्रमाणीकरण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 18: "निजी ब्राउज़िंग इंटरनेट" भाग 1 / भाग 2 / भाग 3
व्याख्यान 19: "बेनामी नेटवर्क" भाग 1 / भाग 2 / भाग 3
व्याख्यान 20: "मोबाइल फोन सुरक्षा" भाग 1 / भाग 2 / भाग 3
व्याख्यान 21: "ट्रैकिंग डेटा" भाग 1 / भाग 2 / भाग 3

छात्र: कोड को स्कैन करना और इसे मैन्युअल रूप से जांचना क्यों असंभव है?

प्रोफेसर: व्यवहार में, यही होता है। डेवलपर्स को पता है कि जब भी इंटरप्रेटर इस तरह का काम करता है, तो रिटर्न वैल्यू वापस करते समय, विशेष कोड का उपयोग किया जाता है जो स्वचालित रूप से संक्रमित सिस्टम वैल्यू को system.arraycopy () में असाइन करता है, जो इसके साथ जुड़ा होना चाहिए।

छात्र: सही है, लेकिन फिर काम का मैनुअल हिस्सा क्या है?

प्रोफेसर: मैनुअल भाग मुख्य रूप से यह पता लगाने के लिए है कि ऑडिट निष्पादन नीति क्या होनी चाहिए। दूसरे शब्दों में, यदि आप केवल मानक टेंटड्रॉइड या मानक एंड्रॉइड को देखते हैं, तो वे आपके लिए कुछ करेंगे, लेकिन वे स्वचालित रूप से टेंट को सही तरीके से असाइन नहीं कर पाएंगे। इसलिए किसी को मैन्युअल रूप से ट्रैकिंग नीति प्रदान करनी चाहिए।



ऐसा नहीं लगता कि यह व्यवहार में एक बड़ी समस्या होगी। लेकिन अगर मशीन-उन्मुख तरीकों का उपयोग करने वाले अनुप्रयोगों की संख्या में लगातार वृद्धि हुई है, तो हमें छोटी समस्याएं हो सकती हैं।

एक अन्य प्रकार के डेटा के बारे में चिंता करने के लिए एक संक्रमण असाइन करने के मामले में आईपीसी संदेश है। IPC संदेशों को अनिवार्य रूप से सरणियों के रूप में माना जाता है। इसलिए, इन संदेशों में से प्रत्येक एक एकल सामान्य टेंट के साथ जुड़ा होगा, जो उसके सभी घटक भागों के संक्रमण का संघ है।

यह सिस्टम प्रदर्शन में योगदान देता है क्योंकि हमें इनमें से प्रत्येक संदेश के लिए केवल एक टेंट टैग को संग्रहीत करने की आवश्यकता है। एक चरम मामले में, संक्रमण की एक डिग्री को बस आश्वस्त किया जाएगा, लेकिन यह कभी भी सुरक्षा में कमी नहीं करेगा। एक ही समय में सबसे बुरी बात यह हो सकती है कि नेटवर्क को डेटा नहीं मिलेगा जो गोपनीयता के लिए किसी भी खतरनाक परिणाम के बिना वहां पहुंच सकता है।

इसलिए, जब आप एक IPC संदेश बनाते हैं, तो यह संयुक्त टेंट प्राप्त करता है। जब आप पढ़ते हैं कि आपको इस संदेश में क्या मिला है, तो निकाले गए डेटा संदेश से ही संक्रमित हो जाते हैं, जो समझ में आता है। इस प्रकार IPC संदेशों को नियंत्रित किया जाता है।

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



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

तो, हम जावा परिप्रेक्ष्य से किन चीजों को संक्रमित कर सकते हैं? मूल रूप से जावा के पांच प्रकार के ऑब्जेक्ट हैं, जिन्हें टेंट फ्लैग की आवश्यकता होती है। सबसे पहले, ये स्थानीय चर हैं स्थानीय चर जो विधि में उपयोग किए जाते हैं। पिछले उदाहरणों पर लौटते हुए, हम मान सकते हैं कि चार सी एक ऐसा चर है।

इसलिए, हमें इन तत्वों को झंडे सौंपने चाहिए। दूसरा प्रकार विधि तर्क पद्धति का तर्क है, उनके पास संक्रमण के झंडे भी होने चाहिए। ये दोनों चीजें स्टैक पर रहती हैं, इसलिए टेंटड्रॉइड को झंडे के उद्देश्य का ध्यान रखना पड़ता है और इस प्रकार की वस्तुओं के लिए बहुत अधिक है।
हमें ऑब्जेक्ट इंस्टीट्यूशन फील्ड के उदाहरणों के लिए झंडे लगाने की भी आवश्यकता है। कल्पना कीजिए कि एक निश्चित वस्तु सी है, यह एक चक्र है, और मैं इसकी त्रिज्या जानना चाहता हूं। इस प्रकार, हमारे पास c.radius फ़ील्ड है, और हमें इन क्षेत्रों में से प्रत्येक के लिए संक्रमण जानकारी को संबद्ध करना चाहिए: साथ और त्रिज्या।
चौथे प्रकार का जावा ऑब्जेक्ट स्टेटिक क्लास फ़ील्ड्स का स्थिर वर्ग फ़ील्ड है, जिसे टेंट की जानकारी भी आवश्यक है। यह Circle.property की तरह कुछ हो सकता है, अर्थात, उस सर्कल के गुणों का वर्णन जिसके लिए हम कुछ जानकारी को टेंट में असाइन करते हैं।

पांचवा प्रकार Arrays arrays है, जिसके बारे में हमने पहले बात की थी, और हम पूरे सरणी के लिए संक्रमण की जानकारी का एक सामान्य टुकड़ा प्रदान करते हैं।

इस प्रकार की जावा वस्तुओं के लिए दागी झंडे को लागू करने का मूल विचार केवल चर के बगल में एक चर के लिए दागी झंडे को संग्रहीत करने का प्रयास करना है।



मान लें कि हमारे पास कुछ पूर्णांक चर हैं, और हम इसके साथ कुछ प्रकार के प्रदूषण को रखना चाहते हैं। हम इस स्थिति को संभव के रूप में संभव के रूप में चर के करीब रखने की कोशिश करना चाहते हैं, संभवतः प्रोसेसर स्तर पर कुशल कैश संचालन सुनिश्चित करने के कारणों के लिए। अगर हम इस वैरिएबल से बहुत दूर रहते हैं, तो यह समस्या पैदा कर सकता है, क्योंकि दुभाषिया इस वास्तविक जावा वैरिएबल के लिए मेमोरी वैल्यू को देखने के बाद, इसके संक्रमण के बारे में जल्द से जल्द जानकारी प्राप्त करना चाहेगा।

यदि हम मूव-ऑप ऑपरेशन को देखते हैं, तो हम नोटिस करते हैं कि कोड में इन जगहों पर, dst और src, जब दुभाषिया मूल्यों पर विचार करता है, तो यह संबंधित टेंट संक्रमण पर भी विचार करता है।

इस प्रकार, इन चीजों को एक-दूसरे के जितना करीब हो सके, आप कैश के अधिक कुशल उपयोग को सुनिश्चित करने का प्रयास कर रहे हैं। यह बहुत आसान है। यदि आप देखते हैं कि डेवलपर्स स्टैक पर रहने वाले तरीकों और स्थानीय चर के तर्कों के लिए क्या करते हैं, तो आप देख सकते हैं कि वे अनिवार्य रूप से वैवाहिक झंडों को हाइलाइट करते हैं जहां वैरिएबल स्थित हैं।

मान लीजिए हमारे पास हमारे व्याख्यान के बारे में एक पसंदीदा चीज है, एक स्टैक आरेख जिसे आप शायद जल्द ही लगातार उल्लेख के लिए नफरत करेंगे। स्थानीय चर 0 को हमारे स्टैक में स्थित होने दें, फिर टेंटडायराइड इस चर के संक्रमण के बारे में एक टैग को मेमोरी में स्टोर करेगा। यदि आपके पास एक और चर है, तो इसका टैग भी सीधे इसके नीचे स्थित होगा, और इसी तरह। यह बहुत सरल है। ये सभी चीजें एक ही कैश लाइन पर स्थित होंगी, जिससे मेमोरी कम खर्चीली हो जाएगी।



छात्र: मुझे आश्चर्य है कि आपके पास एक पूरे सरणी के लिए एक झंडा कैसे हो सकता है और किसी वस्तु की प्रत्येक संपत्ति के लिए अलग-अलग झंडे हो सकते हैं। क्या होगा यदि वस्तु का एक तरीका इसके गुणों में संग्रहीत डेटा तक पहुंच सकता है? यह होगा ... आप जानते हैं कि मेरा क्या मतलब है?

प्रोफेसर: क्या आप ऐसी किसी नीति को लागू करने के कारण के बारे में पूछ रहे हैं?

छात्र: हाँ, इस तरह की नीति का उपयोग करने के कारण के बारे में।

प्रोफेसर: मुझे लगता है कि यह कार्यान्वयन की प्रभावशीलता सुनिश्चित करने के लिए किया जाता है। संभवतः अन्य नियम हैं - उदाहरण के लिए, वे डेटा सरणी की लंबाई की रिपोर्ट नहीं करते हैं, क्योंकि सूचना रिसाव संभव है, इसलिए वे इस संकेतक में संक्रमण का विस्तार नहीं करते हैं। इसलिए मुझे लगता है कि कुछ निर्णय दक्षता के कारणों से लिए जाते हैं। सिद्धांत रूप में, ऐसा कुछ भी नहीं है जो यह इंगित करने के लिए कि सरणी के प्रत्येक तत्व को एक्सेस करते समय बाधा उत्पन्न करता है कि बाईं तरफ की बात किसी भी विशिष्ट तत्वों से केवल दागी प्राप्त करती है।

हालांकि, यह स्पष्ट नहीं है कि क्या यह सही होगा, क्योंकि, जाहिरा तौर पर, अगर आप किसी चीज़ को सरणी में रखते हैं, तो इस चीज़ को इस सरणी के बारे में कुछ जानना चाहिए। इसलिए, मुझे लगता है कि डेवलपर्स दोनों नीतियों के संयोजन का उपयोग करते हैं। अत्यधिक रूढ़िवादी होने के नाते, आपको उन डेटा के रिसाव की अनुमति नहीं देनी चाहिए जिन्हें आप संरक्षित करना चाहते हैं, लेकिन साथ ही, सरणी तक पहुंच के लिए, आपको इसके बारे में कुछ पता होना चाहिए। और जब आपको किसी चीज़ के बारे में कुछ सीखने की ज़रूरत होती है, तो इसका आमतौर पर मतलब होता है कि आप टेंट का इस्तेमाल करते हैं।

तो, यह मूल योजना है जिसका उपयोग वे एक दूसरे के बगल में इस सभी जानकारी को संग्रहीत करने के लिए करते हैं। कोई कल्पना कर सकता है कि क्लास फील्ड्स और ऑब्जेक्ट फील्ड्स के लिए भी यही किया जाता है। कक्षा की घोषणा करते समय, आपके पास किसी विशेष चर के लिए कुछ स्लॉट मेमोरी होती है, और इस स्लॉट के ठीक बगल में उस चर के बारे में जानकारी होती है। इसलिए मुझे लगता है कि यह सब बहुत उचित है।

यह TaintDroid का सिद्धांत है। जब सिस्टम के संचालन के दौरान सिस्टम को इनिशियलाइज़ या अन्य समय पर किया जाता है, तो TaintDroid संभावित रूप से संक्रमित जानकारी के सभी स्रोतों को देखता है और इनमें से प्रत्येक चीज़ को एक ध्वज प्रदान करता है - GPS सेंसर, कैमरा, और इसी तरह। जैसा कि कार्यक्रम चलता है, यह इन स्रोतों से गोपनीय जानकारी निकालेगा, जिसके बाद दुभाषिया लेख में दी गई तालिका के अनुसार सभी प्रकार के कार्यों पर विचार करेगा, ताकि यह पता लगाया जा सके कि पूरे सिस्टम में दागी संक्रमण कैसे फैलता है।

सबसे दिलचस्प बात तब होती है जब डेटा सिस्टम में घुसने की कोशिश करता है। TaintDroid नेटवर्क इंटरफेस को नियंत्रित कर सकता है और उन सभी चीजों को देख सकता है जो उनके माध्यम से गुजरने की कोशिश करता है। वह दागी टैग्स की तलाश करता है, और अगर नेटवर्क में घुसने की कोशिश कर रहे डेटा में इन में से एक या अधिक झंडे हैं, तो उन्हें नेटवर्क का उपयोग करने से प्रतिबंधित किया जाएगा। इस समय क्या होता है यह वास्तव में आवेदन पर निर्भर करता है।



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

"मूल्यांकन" नामक लेख का एक भाग प्रणाली के अध्ययन की प्रक्रिया में पाई गई कुछ चीजों पर चर्चा करता है। इसलिए, लेख के लेखकों ने पाया कि एंड्रॉइड एप्लिकेशन उन तरीकों से डेटा निकालने का प्रयास करेंगे जो उपयोगकर्ता के लिए अदृश्य हैं। मान लीजिए कि वे विज्ञापन के लिए आपके स्थान का उपयोग करने का प्रयास करेंगे, तो वे आपके नंबर को दूरस्थ सर्वर पर भेज देंगे, और इसी तरह। यह ध्यान रखना महत्वपूर्ण है कि ये एप्लिकेशन, एक नियम के रूप में, एंड्रॉइड सुरक्षा मॉडल को इस अर्थ में "ब्रेक" नहीं करते हैं कि उपयोगकर्ता को उन्हें नेटवर्क तक पहुंचने या उन्हें संपर्क सूची का उपयोग करने की अनुमति देनी चाहिए। हालाँकि, एप्लिकेशन EULA लाइसेंस समझौते में प्रदान नहीं करते हैं कि वे कुछ सिल्क रोड 8 सर्वर या उसके बाद कुछ के लिए एक फोन नंबर भेजने का इरादा रखते हैं। वास्तव में, यह एप्लिकेशन के असली इरादों के बारे में एक धोखाधड़ी और भ्रामक उपयोगकर्ता है, क्योंकि अगर उन्होंने इन EULA आवश्यकताओं को देखा और उन्हें पता था कि उनके साथ क्या हुआ, वे इस बारे में सोच सकते हैं कि इस तरह के एप्लिकेशन को अपने स्मार्टफोन पर इंस्टॉल करना है या नहीं।

छात्र: यह माना जा सकता है कि अगर वे इन आवश्यकताओं को लाइसेंस समझौते में डालते हैं, तो भी यह काम नहीं करेगा, क्योंकि लोग आमतौर पर यूएएलए नहीं पढ़ते हैं।

प्रोफेसर: यह एक बहुत ही उचित धारणा है, क्योंकि यहां तक ​​कि कंप्यूटर वैज्ञानिक भी हमेशा लाइसेंस समझौते की जांच नहीं करते हैं। हालांकि, EULA में ऐसी ईमानदारी अभी भी फायदेमंद होगी, क्योंकि ऐसे लोग हैं जो वास्तव में लाइसेंस समझौते को पढ़ते हैं। लेकिन आप यह मानने में बिल्कुल सही हैं कि उपयोगकर्ता छोटे प्रिंट में लिखे पृष्ठों का एक गुच्छा नहीं पढ़ेंगे, वे केवल "सहमत" पर क्लिक करते हैं और एप्लिकेशन इंस्टॉल करते हैं।

इसलिए, मुझे लगता है कि सिस्टम के माध्यम से जानकारी पारित करने के नियम काफी सरल हैं, जैसा कि हमने पहले ही कहा था, दागी बस दाईं ओर से बाईं ओर चलती है। हालांकि, कभी-कभी सूचना प्रवाह की गति के लिए इन नियमों के कुछ हद तक परस्पर विरोधी परिणाम हो सकते हैं।
कल्पना कीजिए कि एक आवेदन लिंक्ड सूची के अपने वर्ग को लागू करता है। हमारे पास ListNode नामक एक साधारण वर्ग है, इसमें ऑब्जेक्ट डेटा के लिए ऑब्जेक्ट फ़ील्ड और अगली सूची में एक ListNode ऑब्जेक्ट होगा जो अगली सूची का प्रतिनिधित्व करता है।

मान लें कि एप्लिकेशन ऑब्जेक्ट डेटा फ़ील्ड में संक्रमित डेटा असाइन करता है - GPS सेंसर या किसी अन्य चीज़ से प्राप्त गोपनीय जानकारी। सवाल यह है कि जब हम इस सूची की लंबाई की गणना करते हैं, तो क्या यह संक्रमित होना चाहिए? आप आश्चर्यचकित होंगे कि प्रश्न के उत्तर का उत्तर "नहीं" होगा, जिसे बताया गया है कि टेंटडायराइड और इनमें से कुछ सिस्टम सूचना प्रवाह कैसे निर्धारित करते हैं। आइए देखें कि किसी लिंक्ड सूची में नोड जोड़ने का क्या मतलब है।

नोड जोड़ने में 3 चरण होते हैं। तो, पहली बात यह है कि एक नई सूची नोड का चयन करें जिसमें वह डेटा है जिसे आप जोड़ना चाहते हैं - Alloc ListNode। दूसरा चरण इस नए नोड में डेटा फ़ील्ड असाइन करना है। और तीसरी चीज़ जो आप करते हैं, किसी सूची में नोड्स को मर्ज करने के लिए ListNode के लिए किसी प्रकार के पैच का उपयोग करें - यह "अगला" ptr पॉइंटर है।



दिलचस्प बात यह है कि तीसरा चरण डेटा क्षेत्र से संबंधित नहीं है, यह सिर्फ अगले मूल्य पर विचार करता है। जैसे ही ऑब्जेक्ट डेटा संक्रमित होता है, हम सूची की लंबाई की गणना करना शुरू करते हैं, कुछ सिर के नोड से शुरू होकर, सभी "अगले" ptr पॉइंटर्स के माध्यम से जाते हैं और केवल यह गिनते हैं कि कितने पॉइंटर्स पास हुए हैं। इसलिए गणना एल्गोरिथ्म संक्रमित डेटा को नहीं छूता है।

दिलचस्प है, अगर आपके पास एक लिंक की गई सूची है जो संक्रमित डेटा से भरी हुई है और फिर इसकी लंबाई की गणना करती है, तो इससे संक्रमित मूल्य का उत्पादन नहीं होगा। यह थोड़ा अतार्किक लग सकता है, हालांकि जब सरणियों पर विचार करते हैं, तो हम पहले ही कह चुके हैं कि सरणी की लंबाई में भी तनाव नहीं है। एक ही कारण है। व्याख्यान के अंत में, हम चर्चा करेंगे कि आप एक ऐसी भाषा का उपयोग कैसे कर सकते हैं जो आपको प्रोग्रामर के रूप में अपने स्वयं के संक्रमण का निर्धारण करने की अनुमति देता है, और फिर आप ऐसी चीजों के लिए अपनी खुद की नीति विकसित कर सकते हैं।
TaintDroid की एक अच्छी विशेषता यह है कि आप एक डेवलपर के रूप में, कुछ भी लेबल नहीं करते हैं, TaintDroid आपके लिए करता है। वह उन सभी गोपनीय चीजों को नोट करता है जो जानकारी का स्रोत हो सकती हैं, और वे सभी चीजें जो जानकारी के "डूब" हो सकती हैं, इसलिए आप, एक डेवलपर के रूप में, काम करने के लिए तैयार हैं। लेकिन यदि आप नोड्स को जोड़ना नियंत्रित करना चाहते हैं, तो आपको स्वयं कुछ नीतियां बनानी पड़ सकती हैं।
TaintDroid सिस्टम के प्रदर्शन को कैसे प्रभावित करता है? मौजूदा ओवरहेड वास्तव में बहुत उचित लगते हैं। मेमोरी ओवरहेड सभी संक्रमण टैग को संग्रहीत करना है। प्रोसेसर लोड में मुख्य रूप से इन संक्रमणों के गंतव्य, वितरण और सत्यापन शामिल होंगे, और यह ध्यान दिया जाना चाहिए कि Dalvik वर्चुअल मशीन का उपयोग करना एक अतिरिक्त काम है। इसलिए, स्रोत को देखते हुए, इस 32-बिट संक्रमण की जानकारी को देखते हुए, हम उन ऑपरेशनों को करते हैं जिन्हें हमने पहले ही माना है। यह कम्प्यूटेशनल ओवरहेड है।

ये ओवरहेड बहुत मध्यम लगते हैं। लेख के लेखकों के अनुसार, टेंट टैग को संग्रहीत करने के लिए 3% से 5% अतिरिक्त मेमोरी की आवश्यकता होती है, इसलिए यह इतना बुरा नहीं है। प्रोसेसर लोड थोड़ा अधिक है और कंप्यूटिंग शक्ति के 3% से 29% तक पहुंच सकता है। यह इस तथ्य के कारण है कि हर बार लूप निष्पादित होने पर, दुभाषिया को इन टैगों को देखने और संबंधित संचालन करने की आवश्यकता होती है। हालांकि ये केवल बिटवाइज़ ऑपरेशन हैं, इन्हें हर समय निष्पादित करने की आवश्यकता होती है। यह 29% के भार के मामले में भी बुरा नहीं है, क्योंकि सिलिकॉन वैली के डेवलपर्स लगातार इस तथ्य के बारे में बात कर रहे हैं कि आधुनिक फोन को क्वाड-कोर प्रोसेसर की आवश्यकता होती है। बैटरी के साथ एकमात्र समस्या उत्पन्न हो सकती है, क्योंकि अगर आपके पास अतिरिक्त प्रोसेसर कोर है, तो भी आप अपनी जेब में एक गर्म फोन रखने की संभावना नहीं रखते हैं जो इन चीजों की गणना करने की कोशिश करते समय "विस्फोट" करना शुरू कर देता है। लेकिन अगर आपकी बैटरी इस तरह की गणनाओं से प्रभावित नहीं होती है, तो सब कुछ इतना बुरा नहीं है।



तो यह TaintDroid के काम का अवलोकन था। एक सवाल है?

स्टूडेंट: क्या आप हर समय केवल टैग करते हैं ? या प्रत्येक चर को टैग किया जाता है?

प्रोफेसर: सब कुछ चिह्नित है, इसलिए सैद्धांतिक रूप से कुछ भी आपको उन चीजों के लिए संक्रमण के बारे में कोई जानकारी देने से रोकता है जिनमें संक्रमण बिल्कुल नहीं है। मुझे लगता है कि जैसे ही कुछ कम से कम एक दागी हो जाता है, आपको एक गतिशील परिवर्तन लेआउट जैसा कुछ बनाने की आवश्यकता होती है। - , , . taint, , , - , , . , , - . TaintDroid . Dalvik.

– taint x86 ARM? , , , , , , Java . ?

, , , . , , , , , Java- - . x86, , , , , , .
, taint , , , . .



, x86 — . . , - x86, . , , , P, , , !

, taint x86. , , , AD, , .
-, , . -, , . , , , .

, . , . , , , . , « » Taint Explosion.
, , . , Dungeons and Dragons, .

, , - - . , , , .
, - esp esb. , .



, x86, , esp. , , . , , , ebp, , , . , , , taint .

, Linux . , . , - .

: ? , .

: . x86, , . , . Bochs – IBM PC, 86. TaintBochs, x86 . x86, , . , . , , , , , , - .

54:10

MIT « ». 21: « », 3


.

हमारे साथ बने रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक आदेश रखकर या अपने दोस्तों को इसकी अनुशंसा करके हमें समर्थन दें, एंट्री-लेवल सर्वरों के अनूठे एनालॉग पर हैबर उपयोगकर्ताओं के लिए 30% छूट जो हमने आपके लिए ईजाद की है: VPS (KVM) E5-2650 v4 (6 कोर) 10GB DDR4 240GB SSD 1Gbps से पूरा सच $ 20 या सर्वर को कैसे विभाजित करें? (विकल्प RAID1 और RAID10 के साथ उपलब्ध हैं, 24 कोर तक और 40GB DDR4 तक)।

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps , .

डेल R730xd 2 बार सस्ता? केवल हमारे पास 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps नीदरलैंड और यूएसए में $ 249 से 100 टीवी है ! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?