बूटलोडर को लॉक/अनलॉक करना

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

बूटलोडर में प्रवेश करना

fastboot कमांड जारी करने के लिए, आपको बूटलोडर मोड में होना चाहिए। ऐसा करने का एक तरीका एडीबी कमांड adb reboot bootloader भेजना है। कुछ फ़ोन आपको डिवाइस को बूट करते समय कुंजी संयोजन (आमतौर पर वॉल्यूम कम) दबाकर बूटलोडर में रीबूट करने की अनुमति भी देते हैं।

बूटलोडर को अनलॉक करना

एक बार बूटलोडर मोड में, बूटलोडर को अनलॉक करने और विभाजन को फिर से फ्लैश करने में सक्षम करने के लिए, डिवाइस पर fastboot flashing unlock कमांड चलाएं। सेटिंग के बाद, अनलॉक मोड रिबूट के दौरान बना रहता है।

जब तक get_unlock_ability 1 पर सेट न हो जाए तब तक डिवाइस को fastboot flashing unlock कमांड को अस्वीकार कर देना चाहिए। यदि 0 पर सेट है, तो उपयोगकर्ता को होम स्क्रीन पर बूट करना होगा, सेटिंग्स > सिस्टम > डेवलपर विकल्प मेनू खोलना होगा और OEM अनलॉकिंग विकल्प को सक्षम करना होगा (जो get_unlock_ability को 1 पर सेट करता है)। सेटिंग के बाद, यह मोड रीबूट और फ़ैक्टरी डेटा रीसेट के दौरान बना रहता है।

जब fastboot flashing unlock कमांड भेजा जाता है, तो डिवाइस को उपयोगकर्ताओं को यह चेतावनी देने के लिए संकेत देना चाहिए कि उन्हें अनौपचारिक छवियों के साथ समस्याओं का सामना करना पड़ सकता है। उपयोगकर्ता द्वारा चेतावनी स्वीकार करने के बाद, डिवाइस को अनधिकृत डेटा पहुंच को रोकने के लिए फ़ैक्टरी डेटा रीसेट करना चाहिए। बूटलोडर को डिवाइस को रीसेट करना चाहिए, भले ही वह इसे ठीक से पुन: स्वरूपित न कर सके। रीसेट के बाद ही लगातार फ़्लैग सेट किया जा सकता है ताकि डिवाइस को फिर से फ्लैश किया जा सके।

fastboot flashing unlock प्रक्रिया के दौरान पहले से अधिलेखित नहीं की गई सभी रैम को रीसेट किया जाना चाहिए। यह उपाय उन हमलों को रोकता है जो पिछले बूट से बची हुई रैम सामग्री को पढ़ते हैं। इसी तरह, अनलॉक किए गए उपकरणों को प्रत्येक बूट पर रैम को साफ़ करना चाहिए (जब तक कि इससे अस्वीकार्य विलंब न हो), लेकिन कर्नेल के ramoops के लिए उपयोग किए गए क्षेत्र को छोड़ देना चाहिए।

बूटलोडर को लॉक करना

बूटलोडर को लॉक करने और डिवाइस को रीसेट करने के लिए, डिवाइस पर fastboot flashing lock कमांड चलाएँ। खुदरा बिक्री के लिए इच्छित उपकरणों को लॉक स्थिति में भेजा जाना चाहिए ( get_unlock_ability 0 लौटाने के साथ) ताकि यह सुनिश्चित किया जा सके कि हमलावर एक नया सिस्टम या बूट छवि स्थापित करके डिवाइस से समझौता नहीं कर सकते हैं।

लॉक/अनलॉक गुण सेट करना

डिवाइस फ्लैशिंग अनलॉक का समर्थन करता है या नहीं, इसके आधार पर ro.oem_unlock_supported प्रॉपर्टी को बिल्ड समय पर सेट किया जाना चाहिए।

• यदि डिवाइस फ्लैशिंग अनलॉक का समर्थन करता है, तो ro.oem_unlock_supported 1 पर सेट करें।
• यदि डिवाइस फ्लैशिंग अनलॉक का समर्थन नहीं करता है, तो ro.oem_unlock_supported 0 पर सेट करें।

यदि डिवाइस फ्लैशिंग अनलॉक का समर्थन करता है, तो बूटलोडर को कर्नेल कमांड लाइन वेरिएबल androidboot.flash.locked को लॉक होने पर 1 पर या अनलॉक होने पर 0 पर सेट करके लॉक स्थिति को इंगित करना चाहिए। इस वेरिएबल को एंड्रॉइड 12 में कर्नेल कमांड लाइन के बजाय बूटकॉन्फिग में सेट किया जाना चाहिए।

उन उपकरणों के लिए जो dm-verity का समर्थन करते हैं, ro.boot.flash.locked का मान 0 पर सेट करने के लिए ro.boot.verifiedbootstate उपयोग करें; यदि सत्यापित बूट स्थिति नारंगी है तो यह बूटलोडर को अनलॉक कर देता है।

महत्वपूर्ण अनुभागों की सुरक्षा करना

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

लॉक से अनलॉक स्थिति में संक्रमण के लिए डिवाइस के साथ भौतिक संपर्क की आवश्यकता होनी चाहिए। यह इंटरैक्शन fastboot flashing unlock कमांड चलाने के प्रभावों के समान है लेकिन इसके लिए उपयोगकर्ता को डिवाइस पर एक भौतिक बटन दबाने की आवश्यकता होती है। डिवाइस को भौतिक इंटरैक्शन के बिना lock critical से unlock critical में प्रोग्रामेटिक रूप से संक्रमण की अनुमति नहीं देनी चाहिए, और डिवाइस को unlock critical स्थिति में शिप नहीं करना चाहिए।