प्रविष्टि
इस लेख में, मैं कर्नेल की तुलना में थोड़ी अधिक सुरक्षा पर विचार करने का प्रयास करूंगा, अर्थात्: मूल निवासी उपयोगकर्ता स्थान में सुरक्षा कैसे काम करती है। हम ऑपरेटिंग सिस्टम बूट प्रक्रिया के विषय को कवर करेंगे और एंड्रॉइड फाइल सिस्टम की संरचना पर विचार करेंगे। जैसा कि मैंने कहा, मैं लिनक्स पर बहुत मजबूत नहीं हूं, इसलिए यदि आप अशुद्धियों को नोटिस करते हैं, तो इसे सही करें - मुझे सिखाएं और लेख को सुधारें। चूंकि यह विषय काफी व्यापक है, इसलिए मैंने इसे दो भागों में तोड़ने का फैसला किया। पहले भाग में हम ऑपरेटिंग सिस्टम और फाइल सिस्टम की विशेषताओं को लोड करने की प्रक्रिया पर विचार करेंगे। हर कोई जो दिलचस्पी है, स्वागत है!
लेखों की सूची
इस विषय से मेरे लेखों के लिंक यहां दिए गए हैं:
- एंड्रॉइड ऑपरेटिंग सिस्टम की सुरक्षा मूल बातें। कोर स्तर
- एंड्रॉइड ऑपरेटिंग सिस्टम की सुरक्षा मूल बातें। मूल उपयोगकर्ता स्थान, भाग 1
- एंड्रॉइड ऑपरेटिंग सिस्टम की सुरक्षा मूल बातें। मूल उपयोगकर्ता स्थान, भाग 2
- एंड्रॉइड ऑपरेटिंग सिस्टम की सुरक्षा मूल बातें। अनुप्रयोग फ्रेमवर्क स्तर पर सुरक्षा। बाइंडर आई.पी.सी.
देशी उपयोगकर्ता अंतरिक्ष से क्या मतलब है
मूल उपयोगकर्ता स्थान उन सभी उपयोगकर्ता-अंतरिक्ष घटकों को संदर्भित करता है जो Dalvik वर्चुअल मशीन के बाहर चलते हैं और जो लिनक्स कर्नेल का हिस्सा नहीं हैं।
Android फ़ाइल सिस्टम
सबसे पहले, आइए एंड्रॉइड फाइल सिस्टम की संरचना को देखें। यद्यपि एंड्रॉइड लिनक्स कर्नेल पर आधारित है, हम यहां अपनी आंखों
से परिचित फाइल सिस्टम संरचना नहीं देखेंगे। आइए हम एमुलेटर चलाते हैं और देखते हैं कि हमारे पास क्या है। ऐसा करने के लिए, कमांड चलाएँ:
adb shell ls -al
एंड्रॉइड 4.2 पर एक एमुलेटर के लिए मेरे टर्मिनल में, मैं निम्नलिखित परिणाम देखता हूं:
drwxr-xr-x root root 2013-04-10 08:13 acct drwxrwx--- system cache 2013-04-10 08:13 cache dr-x------ root root 2013-04-10 08:13 config lrwxrwxrwx root root 2013-04-10 08:13 d -> /sys/kernel/debug drwxrwx--x system system 2013-04-10 08:14 data -rw-r--r-- root root 116 1970-01-01 00:00 default.prop drwxr-xr-x root root 2013-04-10 08:13 dev lrwxrwxrwx root root 2013-04-10 08:13 etc -> /system/etc -rwxr-x--- root root 244536 1970-01-01 00:00 init -rwxr-x--- root root 2487 1970-01-01 00:00 init.goldfish.rc -rwxr-x--- root root 18247 1970-01-01 00:00 init.rc -rwxr-x--- root root 1795 1970-01-01 00:00 init.trace.rc -rwxr-x--- root root 3915 1970-01-01 00:00 init.usb.rc drwxrwxr-x root system 2013-04-10 08:13 mnt dr-xr-xr-x root root 2013-04-10 08:13 proc drwx------ root root 2012-11-15 05:31 root drwxr-x--- root root 1970-01-01 00:00 sbin lrwxrwxrwx root root 2013-04-10 08:13 sdcard -> /mnt/sdcard d---rx--- root sdcard_r 2013-04-10 08:13 storage drwxr-xr-x root root 2013-04-10 08:13 sys drwxr-xr-x root root 2012-12-31 03:20 system -rw-r--r-- root root 272 1970-01-01 00:00 ueventd.goldfish.rc -rw-r--r-- root root 4024 1970-01-01 00:00 ueventd.rc lrwxrwxrwx root root 2013-04-10 08:13 vendor -> /system/vendor
मैं यहां केवल मुख्य निर्देशिका और उन लोगों को चिह्नित करूंगा जो भविष्य में हमारे लिए उपयोगी होंगे। इंटरनेट पर आप एक विवरण और अन्य निर्देशिकाओं का उद्देश्य पा सकते हैं। आप देख सकते हैं कि कुछ निर्देशिकाएँ लिनक्स पर समान हैं, उदाहरण के लिए,
/ dev ,
/ proc ,
/ sys ,
/ mnt ,
/ etc, और उनका उद्देश्य मूल रूप से Linux पर समान है। वैसे, ध्यान दें कि हम
/ bin और
/ lib निर्देशिका नहीं देखते हैं। वे कहां छिप गए, मैं थोड़ी देर बाद बताऊंगा।
दूसरी ओर, आप निर्देशिकाओं को देखेंगे कि लिनक्स में बिल्कुल भी नहीं है। उनमें से, हम
/ डेटा / सिस्टम ,
/ कैश ,
/ init ,
/init.rc में रुचि रखते हैं। आइए उनके उद्देश्य को अधिक विस्तार से देखें।
/ system यह मुख्य निर्देशिका है जहां Android सिस्टम के अपरिवर्तनीय घटक संग्रहीत हैं। यदि हम एक सादृश्य आकर्षित करते हैं, तो यह फ़ोल्डर केवल पढ़ने के लिए
C: \ windows \ फ़ोल्डर के समान है। यानी हम इस निर्देशिका में डेटा नहीं बदल सकते। यह वह जगह है जहाँ आप
/ bin और
/ lib निर्देशिकाएँ ढूँढ सकते हैं जहाँ विभिन्न निष्पादन योग्य और साझा लाइब्रेरी संग्रहीत हैं। इसके अलावा, ऐसे सिस्टम एप्लिकेशन भी हैं जो ऑपरेटिंग सिस्टम में बनाए गए हैं और जो डिफ़ॉल्ट रूप से हटाए नहीं जा सकते हैं। ऑपरेटिंग सिस्टम के संकलन के दौरान इस निर्देशिका की सामग्री उत्पन्न होती है।
/ डेटा / सिस्टम केवल पढ़ने के लिए है यहाँ, एक निर्देशिका होनी चाहिए जहां उत्परिवर्तित डेटा संग्रहीत किया जाता है।
/ डेटा सिर्फ इतना है। उदाहरण के लिए, इंस्टॉल किए गए एप्लिकेशन की एपीके फाइलें इस निर्देशिका
/ डेटा / ऐप में सहेजी जाती हैं, और उनका
डेटा / डेटा / डेटा में संग्रहीत किया जाता है (हमने पिछले लेख में इस निर्देशिका की विस्तार से जांच की है)।
/ कैश यह सिर्फ अस्थायी भंडारण है। साथ ही, इस निर्देशिका को सहेजा जाता है, और फिर सिस्टम अद्यतन इससे लॉन्च किए जाते हैं।
यह समझने के लिए कि
/ init फ़ाइल क्या है और हमें * .rc एक्सटेंशन वाली अस्पष्ट फ़ाइलों की आवश्यकता क्यों है, सिस्टम बूट प्रक्रिया पर विचार करें।
Android बूट प्रक्रिया
आइए एंड्रॉइड ऑपरेटिंग सिस्टम को लोड करने की प्रक्रिया में कुछ चरणों को देखें। यह चित्र "एंबेडेड एंड्रॉइड" पुस्तक से लिया गया है, वहां आप अधिक विस्तृत विवरण पा सकते हैं। हालांकि सामान्य तौर पर मैं इस प्रक्रिया को समझता हूं, लेकिन मेरे लिए यह अधिक जादू है :)
सीपीयू। जब आप पावर बटन दबाते हैं, तो वोल्टेज आपके डिवाइस के प्रोसेसर पर लागू होने लगता है। चूंकि इस क्षण तक प्रोसेसर बंद कर दिया गया था, और चूंकि यह वोल्टेज को लागू किए बिना अपने राज्य को बनाए रखने में सक्षम नहीं है, तो शुरुआत के तुरंत बाद यह कुछ असंगठित राज्य में है। इस मामले में, प्रोसेसर अपने विशेष रजिस्टर से कुछ हार्ड-वायर्ड पते को पढ़ता है और इससे शुरू होने वाले निर्देशों को निष्पादित करना शुरू करता है। सबसे अधिक बार, यह पता उस चिप को इंगित करता है जिसमें बूटलोडर (बूटलोडर) वायर्ड होता है।
बूटलोडर। बूटलोडर रैम को इनिशियलाइज़ करता है और उसमें लिनक्स कर्नेल लोड करता है। इसके अलावा, बूटलोडर एक रैमडिस्क बनाता है।
लिनक्स कर्नेल। कर्नेल विभिन्न सबसिस्टम, अंतर्निहित ड्रायवरों और रूट फाइल सिस्टम (रूट फाइल सिस्टम) को आरोहित करता है। उसके बाद, कर्नेल पहला प्रोग्राम चला सकता है।
इससे जादू समाप्त हो जाता है और फिर सब कुछ कम या ज्यादा स्पष्ट हो जाता है।
Init
Android के मामले में पहला कार्यक्रम
init है । निष्पादन योग्य फ़ाइल रूट निर्देशिका (
/ init ) में स्थित है। यह प्रोग्राम है कि कर्नेल बूट होने के बाद शुरू होता है। इसके स्रोत
सिस्टम / कोर / इनिट / फोल्डर में स्थित हैं
। आइए इन्हें थोड़ा खोदें। हम
सिस्टम / कोर / init / init.c में रुचि रखते हैं:
... int main(int argc, char **argv) { ... umask(0); mkdir("/dev", 0755); mkdir("/proc", 0755); mkdir("/sys", 0755); mount("tmpfs", "/dev", "tmpfs", MS_NOSUID, "mode=0755"); mkdir("/dev/pts", 0755); mkdir("/dev/socket", 0755); mount("devpts", "/dev/pts", "devpts", 0, NULL); mount("proc", "/proc", "proc", 0, NULL); mount("sysfs", "/sys", "sysfs", 0, NULL); ... init_parse_config_file("/init.rc"); ... }
सबसे पहले, हम काम के लिए आवश्यक कुछ निर्देशिकाओं को बनाते हैं और माउंट करते हैं, और फिर /init.rc फ़ाइल को पार्स करते हैं और जिसे हमने पार्स किया है उसे निष्पादित करते हैं।
/Init.rc फ़ाइल का प्रारूप बहुत अच्छी तरह से
readme में वर्णित है, जहाँ आप एक उदाहरण भी पा सकते हैं। संक्षेप में, यह फ़ाइल क्रियाओं का एक समूह है (अनुभाग - कमांड का एक अनुक्रम नाम)। आदेशों के प्रत्येक अनुक्रम को एक विशिष्ट ट्रिगर (ट्रिगर) द्वारा ट्रिगर किया जाता है। उदाहरण के लिए, अनुक्रम में निम्नलिखित क्रिया है, जिसमें ट्रिगर एफएस है, और कमांड का क्रम माउंट कमांड का एक सेट है:
on fs
स्रोत फ़ाइल
/init.rc सिस्टम / कोर / रूटडिर / init.rc. में स्थित है। आइए इसके कुछ मुख्य भागों पर ध्यान दें, हालांकि मैं दृढ़ता से आपको इसकी पूर्णता को देखने की सलाह देता हूं। उसके बाद, कई चीजें आपको स्पष्ट हो जानी चाहिए। तो, हमारी फ़ाइल निम्न पंक्तियों के साथ शुरू होती है:
import /init.usb.rc import /init.${ro.hardware}.rc import /init.trace.rc
उनका मतलब है कि
init.rc फ़ाइल के अलावा, आपको
init.usb.rc ,
init.trace.rc और अजीब नाम
init के साथ फाइल से सेटिंग्स आयात करने की आवश्यकता है
। $ {Ro.hardware} .rc हालांकि,
$ {ro.hardware}। केवल एक चर है जिसका मूल्य लोहे के प्रकार को निर्धारित करता है। एक एमुलेटर के मामले में, इसका मूल्य, उदाहरण के लिए,
सुनहरीमछली है । अगला, पर्यावरण चर परिभाषित किए गए हैं:
... on init ...
इसके बाद, डिवाइस के संचालन के लिए आवश्यक चर आरंभ किए जाते हैं। यदि आप इस विषय में रुचि रखते हैं, तो आप किसी विशेष कमांड के बारे में आसानी से जानकारी पा सकते हैं। आइए निम्नलिखित ब्लॉक पर एक नज़र डालें (जो मैंने पहले ही इस लेख में उद्धृत किया है):
on fs
एमटीडी - मेमोरी टेक्नोलॉजी डिवाइसेस। सामान्य शब्दों में, एमटीडी गैर-वाष्पशील (यानी, रिबूट या शटडाउन के बाद सहेजा जाता है) फ्लैश मेमोरी (जैसे NOR या NAND) के साथ एक विशेष चिप है, जिस पर डिस्क चित्र सहेजे जाते हैं।
यह लेख इस प्रकार के डिवाइस पर अधिक विस्तार से, साथ ही सीमाओं पर भी चर्चा करता है। विशेष रूप से इस प्रकार की फ्लैश-मेमोरी के लिए विशेष फ़ाइल सिस्टम विकसित किए गए थे, उदाहरण के लिए, YAFFS। इन प्रकार की मेमोरी की सबसे महत्वपूर्ण सीमाओं में से एक यह है कि किसी सेक्टर में डेटा लिखने के लिए जहां कुछ डेटा पहले से ही लिखा गया है, आपको पहले पूरे सेक्टर को पूरी तरह से मिटा देना चाहिए। इसलिए, निर्माताओं ने एक नए प्रकार की ब्लॉक फ्लैश मेमोरी (eMMC) पर स्विच करना शुरू किया, जिस पर आप एक नियमित ext4 फ़ाइल सिस्टम डाल सकते हैं और इस सीमा से छुटकारा पा सकते हैं। क्योंकि मैं एक एमुलेटर के लिए एक
init.rc फ़ाइल का एक उदाहरण दिखाता हूं जहां सभी काम का अनुकरण किया जाता है, फिर वह डिफ़ॉल्ट रूप से YAFFS2 फ़ाइल सिस्टम का उपयोग करता है (मुझे लगता है कि ये अतीत के अवशेष हैं, क्योंकि YAFFS2 Android 2.2 से पहले सभी उपकरणों के लिए उपयोग किया गया था)। एक वास्तविक डिवाइस में (यह सिर्फ एक उदाहरण है जब आपको एक विशेष हार्डवेयर के लिए
init.rc फ़ाइल का उपयोग करने की आवश्यकता होती है), ये कमांड ओवरराइट हो जाएंगे। उदाहरण के लिए,
init.herring.rc फ़ाइल में एक
हेरिंग डिवाइस (Google Nexus S) के मामले में
, यह खंड इस प्रकार दिखता है:
on fs mkdir /efs 0775 radio radio mount yaffs2 mtd@efs /efs noatime nosuid nodev chmod 770 /efs/bluetooth chmod 770 /efs/imei mount_all /fstab.herring ...
जहां
fstab.herring एक
फाइल है जिसकी सामग्री निम्नानुसार है:
... /dev/block/platform/s3c-sdhci.0/by-name/system /system ext4 ro wait /dev/block/platform/s3c-sdhci.0/by-name/userdata /data ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,encryptable=/efs/userdata_footer
जैसा कि आपने देखा होगा,
/ system ,
/ data ,
/ cache बस बढ़ते बिंदु (फ़ाइल सिस्टम के माउंट पॉइंट) हैं जो या तो MTD डिवाइस (एमुलेटर के मामले में) या ब्लॉक डिवाइस (एक वास्तविक डिवाइस के मामले में) को इंगित करते हैं जहां इसी डिस्क चित्र (system.img, userdata.img और cache.img)। मुझे यकीन नहीं है, लेकिन मुझे लगता है कि स्मार्टफोन के अंदर फ्लैश-मेमोरी के साथ एक एकल चिप है, जो विभाजन (वॉल्यूम) में विभाजित है, जिनमें से प्रत्येक में संबंधित छवि शामिल है। फ्लैश-मेमोरी के साथ यह चिप जिसे हम
आंतरिक भंडारण नाम से जानते हैं, जिसकी मात्रा स्मार्टफोन के मुख्य मापदंडों में से एक है।
यह ध्यान दिया जाना चाहिए कि
/ सिस्टम पठन-योग्य है (केवल-पढ़ने के लिए)। इसका मतलब है कि डिवाइस के संचालन के दौरान इस अनुभाग की सामग्री नहीं बदलती है, लेकिन केवल जब आप, उदाहरण के लिए, अपने डिवाइस पर सिस्टम को अपडेट करें (सिस्टम अपडेट का उपयोग करके)।
हम अपने
init.r आदि पर विचार करना जारी
रखते हैं पोस्ट-एफएस-डेटा ट्रिगर
/ डेटा विभाजन फ़ाइल सिस्टम की मूल संरचना उत्पन्न करता है। वहां, सामान्य तौर पर, सब कुछ स्पष्ट है -
एमकेडीआर ,
चाउन ,
चामोद कमांड का एक सेट।
अगला,
init.rc कई डेमॉन लॉन्च करता है। यदि आप लेख की शुरुआत में आंकड़े पर लौटते हैं, तो वे मूल निवासी डेमॉन ब्लॉक में सूचीबद्ध हैं। हम अभी यहां रुकेंगे। जैसा कि आप आंकड़े से देख सकते हैं, मैंने ऑपरेटिंग सिस्टम को लोड करने की प्रक्रिया पर पूरी तरह से विचार नहीं किया। कुछ अनदेखे कदम जिन पर मैं निम्नलिखित लेख में विचार करूंगा।
निष्कर्ष
अगले भाग में मैं आपको बताऊंगा कि इमेज सिस्टम .img, userdata.img और cache.img कहां से आते हैं और नेटिव यूजर स्पेस स्तर पर सुरक्षा पर विचार करते हैं। हमेशा की तरह, सुधार, परिवर्धन, साथ ही साथ क्या लिखना है के बारे में सुझाव का स्वागत है। और यद्यपि मेरे पास पहले से ही कुछ योजना है कि अगले लेख में क्या लिखना है, मैं इसे सही करने के लिए तैयार हूं।
संदर्भ
- एमटीडी उपकरणों के साथ काम करना
- करीम यागमोर द्वारा "एंबेडेड एंड्रॉइड"
- मार्को गार्जेंटा द्वारा एंड्रॉइड सिक्योरिटी अंडरपिनिंग्स
अद्यतन- MTD उपकरणों पर लोडर रखने के विभिन्न विकल्पों के बारे में bmx666 उपयोगकर्ता से टिप्पणी करें।
- विभिन्न समाजों पर सीपीयू आरंभीकरण के बारे में SamOwaR उपयोगकर्ता की टिप्पणी