घमरा में टैमिंग गोरिनीच, या डिकम्पाइलिंग ईजीपीएफ

लेख के लेखक https://github.com/Nalen98

शुभ दोपहर

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

प्रागितिहास

यह विषय मेरे लिए भाग्य की एक बड़ी विडंबना के रूप में गया, क्योंकि मैं पहले EBPF से परिचित नहीं था, और Ghidr पहले इस्तेमाल नहीं किया गया था, क्योंकि एक निश्चित हठधर्मिता थी कि "आईडीए प्रो बेहतर है।" जैसा कि यह निकला, यह पूरी तरह सच नहीं है।

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

बैरिकेड के दूसरी तरफ एक विस्तारित बर्कले पैकेट फ़िल्टर था। लिनक्स कर्नेल में एक वर्चुअल मशीन है जो आपको मनमाने ढंग से उपयोगकर्ता कोड को लोड करने की अनुमति देती है जिसका उपयोग कर्नेल स्थान में प्रक्रियाओं का पता लगाने और पैकेट को फिल्टर करने के लिए किया जा सकता है। आर्किटेक्चर एक RISC रजिस्टर मशीन है जिसमें 11 64-बिट रजिस्टर, एक सॉफ्टवेयर काउंटर और एक 512-बाइट स्टैक है। EBPF के लिए कई सीमाएँ हैं:

• चक्र निषिद्ध हैं;
• मेमोरी तक पहुंच केवल स्टैक के माध्यम से संभव है (इसके बारे में एक अलग कहानी होगी);
• कर्नेल फ़ंक्शंस केवल विशेष आवरण कार्यों (eBPF- हेल्पर्स) के माध्यम से उपलब्ध हैं।

EBPF तकनीक की संरचना। छवि स्रोत: http://www.brendangregg.com/ebpf.html

मूल रूप से, इस तकनीक का उपयोग नेटवर्क कार्यों के लिए किया जाता है - डिबगिंग, पैकेट फ़िल्टरिंग, और इसी तरह कर्नेल स्तर पर। कर्नेल के संस्करण 3.15 से EBPF समर्थन जोड़ा गया है, लिनक्स प्लंबर सम्मेलन 2019 में इस तकनीक के लिए काफी कुछ रिपोर्ट समर्पित की गई थी। लेकिन eBPF में, Ghidra के विपरीत, प्रलेखन अपूर्ण है और इसमें बहुत कुछ नहीं है। इसलिए, स्पष्टीकरण और लापता जानकारी को इंटरनेट पर खोजा जाना था। उत्तरों को खोजने में काफी समय लगा, और जो कुछ भी बाकी है, वह उम्मीद करना है कि प्रौद्योगिकी को अंतिम रूप दिया जाएगा और सामान्य प्रलेखन बनाया जाएगा।

खराब प्रलेखन

स्लीव के लिए एक विनिर्देश विकसित करने के लिए, आपको पहले यह समझने की आवश्यकता है कि लक्ष्य प्रोसेसर की वास्तुकला कैसे काम करती है। और यहां हम आधिकारिक दस्तावेज की ओर मुड़ते हैं।

इसमें कई खामियां हैं:

• EBPF निर्देशों की संरचना पूरी तरह से वर्णित नहीं है।

  
  

  इंटेल x86 जैसे अधिकांश विनिर्देश, आमतौर पर इंगित करते हैं कि प्रत्येक निर्देश बिट क्या जाता है, यह किस ब्लॉक से संबंधित है। दुर्भाग्य से, eBPF विनिर्देश में, ये विवरण या तो पूरे दस्तावेज़ में बिखरे हुए हैं या पूरी तरह से अनुपस्थित हैं, जिसके परिणामस्वरूप हमें लिनक्स कर्नेल में कार्यान्वयन विवरण से लापता अनाज को आकर्षित करना होगा।

  
  

  उदाहरण के लिए, निर्देश संरचना में op:8, dst_reg:4, src_reg:4, off:16, imm:32 ऐसा शब्द नहीं कहा जाता है कि ऑफसेट (बंद) और तत्काल (imm) पर signed जाते हैं, और यह अत्यंत महत्वपूर्ण है, क्योंकि यह प्रभावित करता है अंकगणितीय निर्देशों से छलांग लगाने के लिए काम करना। लिनक्स कर्नेल के लिए स्रोत कोड ने मदद की।

  
  

• वास्तुकला के सभी संभावित mnemonics की पूरी तस्वीर नहीं है।

  
  

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

  
  

  EBPF के सभी निर्देश 64-बिट हैं, LDDW (लोड डबल शब्द) को छोड़कर, इसमें 128 बिट्स का आकार है, यह प्रत्येक 32 बिट्स के साथ दो को समेटता है। EBPF निर्देशों में निम्नलिखित संरचना है।
  
  eBPF निर्देश एन्कोडिंग

  
  

  OPAQUE फ़ील्ड की संरचना निर्देशों के वर्ग (ALU / JMP, लोड / स्टोर) पर निर्भर करती है।

  
  

  उदाहरण के लिए, ALU अनुदेश वर्ग:
  
  ALU निर्देश एन्कोडिंग

  
  

  और JMP वर्ग की अपनी क्षेत्र संरचना है:
  
  शाखा निर्देश एन्कोडिंग

  
  

  लोड / स्टोर निर्देशों के लिए, संरचना अलग है:
  
  लोड / स्टोर निर्देश एन्कोडिंग

  
  

  अनौपचारिक EBPF प्रलेखन ने इसे सुलझाने में मदद की।

  
  

• कॉल-हेल्पर्स के बारे में कोई जानकारी नहीं है, जिस पर लिनक्स कर्नेल के लिए eBPF कार्यक्रमों के अधिकांश तर्क निर्मित होते हैं।

  
  

  और यह बहुत अजीब है, क्योंकि हेल्पर्स ईपीपीएफ कार्यक्रमों में सबसे महत्वपूर्ण चीज हैं, वे सिर्फ उन कार्यों को करते हैं जिन पर प्रौद्योगिकी केंद्रित है।

  
  

परमाणु कार्यों के साथ EBPF इंटरऑपरेबिलिटी

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

• टेल कॉल के बारे में एक शब्द नहीं।

EBPF टेल कॉल। छवि स्रोत: https://cilium.readthedocs.io/en/latest/bpf/#tail-calls ।

टेल कॉल एक ऐसा तंत्र है, जो पिछले एक के बिना किसी दूसरे को कॉल करने के लिए एक ईजीपीएफ प्रोग्राम को अनुमति देता है, यानी विभिन्न ईएक्सपीएफ कार्यक्रमों के बीच कूद। उन्हें विकसित एक्सटेंशन में लागू नहीं किया गया है, विस्तृत जानकारी सिलियम प्रलेखन में पाई जा सकती है।

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

विकास के माहौल के बारे में

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

ग्रहण में, आप घिद्रा (पहले से ही चालू विस्तार के साथ), डिबग चला सकते हैं, जो बेहद सुविधाजनक है। लेकिन शायद सबसे अच्छा अवसर "घिद्रा हेडलेस" मोड का समर्थन करने के लिए है, आपको कोड में एक त्रुटि खोजने के लिए जीयूआई से 100500 बार Ghidr को पुनरारंभ करने की आवश्यकता नहीं है, सभी प्रक्रियाएं पृष्ठभूमि में की जाती हैं।

नोटपैड को बंद किया जा सकता है! और आप ग्रहण को आधिकारिक साइट से डाउनलोड कर सकते हैं। प्लग इन इंस्टॉल करने के लिए, Ecplise में, हेल्प → इनस्टॉल न्यू सॉफ्टवेयर का चयन करें ... जोड़ें पर क्लिक करें और प्लगइन ज़िप आर्काइव चुनें।

विस्तार विकास

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

एक्लिप्स आईडीई में प्रोजेक्ट के रूप में एक्सटेंशन फाइलें

अब मुख्य फाइलों के बारे में:

.cspec - यह इंगित करता है कि कौन से डेटा प्रकार का उपयोग किया जाता है, उन्हें eBPF में कितनी मेमोरी आवंटित की जाती है, स्टैक का आकार सेट होता है, "स्टैकपॉइंट" लेबल R10 को पंजीकृत करने के लिए सेट किया जाता है, और कॉल समझौते पर हस्ताक्षर किए जाते हैं। दस्तावेज़ के अनुसार समझौता (बाकी की तरह) लागू किया गया था:

इसलिए, ईबीपीएफ कॉलिंग कन्वेंशन को इस प्रकार परिभाषित किया गया है:

• R0 - इन-कर्नेल फ़ंक्शन से वापसी मान और eBPF प्रोग्राम के लिए निकास मान
• R1 - R5 - eBPF प्रोग्राम से इन-कर्नेल फ़ंक्शन के लिए तर्क
• R6 - R9 - कैली ने रजिस्टरों को बचाया कि इन-कर्नेल फ़ंक्शन संरक्षित करेगा
• R10 - स्टैक तक पहुंचने के लिए केवल-पढ़ने के लिए फ़्रेम पॉइंटर

 <?xml version="1.0" encoding="UTF-8"?> <compiler_spec> <data_organization> <absolute_max_alignment value="0" /> <machine_alignment value="2" /> <default_alignment value="1" /> <default_pointer_alignment value="4" /> <pointer_size value="4" /> <wchar_size value="4" /> <short_size value="2" /> <integer_size value="4" /> <long_size value="4" /> <long_long_size value="8" /> <float_size value="4" /> <double_size value="8" /> <long_double_size value="8" /> <size_alignment_map> <entry size="1" alignment="1" /> <entry size="2" alignment="2" /> <entry size="4" alignment="4" /> <entry size="8" alignment="8" /> </size_alignment_map> </data_organization> <global> <range space="ram"/> <range space="syscall"/> </global> <stackpointer register="R10" space="ram"/> <default_proto> <prototype name="__fastcall" extrapop="0" stackshift="0"> <input> <pentry minsize="1" maxsize="8"> <register name="R1"/> </pentry> <pentry minsize="1" maxsize="8"> <register name="R2"/> </pentry> <pentry minsize="1" maxsize="8"> <register name="R3"/> </pentry> <pentry minsize="1" maxsize="8"> <register name="R4"/> </pentry> <pentry minsize="1" maxsize="8"> <register name="R5"/> </pentry> </input> <output killedbycall="true"> <pentry minsize="1" maxsize="8"> <register name="R0"/> </pentry> </output> <unaffected> <varnode space="ram" offset="8" size="8"/> <register name="R6"/> <register name="R7"/> <register name="R8"/> <register name="R9"/> <register name="R10"/> </unaffected> </prototype> </default_proto> </compiler_spec> 

विकास फ़ाइलों का वर्णन करना जारी रखने से पहले, मैं .cspec फ़ाइल की एक छोटी लाइन पर .cspec ।

 <stackpointer register="R10" space="ram"/> 

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

हम सभी की जरूरत है ... ढेर

आइए आधिकारिक कर्नेल दस्तावेज देखें :

प्रश्न: क्या बीपीएफ प्रोग्राम इंस्ट्रक्टर पॉइंटर या रिटर्न एड्रेस एक्सेस कर सकता है?

A: नहीं।

प्रश्न: क्या बीपीएफ प्रोग्राम स्टैक पॉइंटर तक पहुंच सकते हैं?

A: नहीं। केवल फ़्रेम पॉइंटर (रजिस्टर आर 10) सुलभ है। संकलक बिंदु से स्टैक पॉइंटर होना आवश्यक है। उदाहरण के लिए, एलएलवीएम अपने बीपीएफ बैकएंड में स्टैक पॉइंटर के रूप में रजिस्टर आर 11 को परिभाषित करता है, लेकिन यह सुनिश्चित करता है कि उत्पन्न कोड कभी भी इसका उपयोग नहीं करता है।

प्रोसेसर में न तो एक निर्देश सूचक (आईपी) है और न ही स्टैक पॉइंटर (एसपी) है, और उत्तरार्द्ध घिडरा के लिए बेहद महत्वपूर्ण है, और विघटन की गुणवत्ता इस पर निर्भर करती है। cspec फ़ाइल में, आपको यह निर्दिष्ट करना होगा कि कौन सा रजिस्टर स्टैकपॉइंटर है (जैसा कि ऊपर दिखाया गया है)। R10 एकमात्र eBPF रजिस्टर है जो प्रोग्राम स्टैक तक पहुंचने की अनुमति देता है, यह फ्रेमपॉइंट है, यह स्थिर और हमेशा शून्य है। cspec फ़ाइल में R10 पर "स्टैकपॉइंटर" लेबल को cspec मौलिक रूप से गलत है, लेकिन कोई अन्य विकल्प नहीं हैं, क्योंकि तब Ghidra प्रोग्राम स्टैक के साथ काम नहीं करेगा। तदनुसार, मूल एसपी अनुपस्थित है, और यह EBPF आर्किटेक्चर में कुछ भी नहीं बदलता है।

इससे कई समस्याएं उत्पन्न होती हैं:

1. घिद्रा में "स्टैक डेप्थ" क्षेत्र को शून्य होने की गारंटी दी जाएगी, क्योंकि हमें बस R10 इन वास्तु स्थितियों में स्टैकर के रूप में नामित करना होगा, और संक्षेप में यह हमेशा शून्य है, जो पहले तर्क दिया गया था। "स्टैक डेप्थ" लेबल "स्टैकपॉइंटर" के साथ रजिस्टर को प्रतिबिंबित करेगा।

   
   

   और आपको इसके साथ जुड़ना होगा, ये वास्तुकला की विशेषताएं हैं।

   
   

2. निर्देश जो R10 पर काम करते हैं (अर्थात, स्टैक को संभालने वाले) अक्सर विघटित नहीं होते हैं। Ghidra आम तौर पर यह डिकॉपाइल नहीं करता है कि इसे मृत कोड (यानी स्निपेट जो कभी निष्पादित नहीं करता है) मानता है। और चूंकि R10 अपरिवर्तनीय है, इसलिए कई स्टोर / लोड निर्देशों को Ghidr द्वारा डेडकोड ​​के रूप में पहचाना जाता है और डिकंपाइलर से गायब हो जाता है।

   
   

   सौभाग्य से, इस समस्या को एक कस्टम विश्लेषक लिखने के साथ हल किया गया था, साथ ही एक pspec फ़ाइल में eBPF सहायकों के साथ एक अतिरिक्त पते की जगह की घोषणा की गई थी, जिसे इश्यू प्रोजेक्ट में घिद्रा डेवलपर्स में से एक द्वारा संकेत दिया गया था।

   
   

विस्तार विकास (जारी)

.ldefs प्रोसेसर की विशेषताओं का वर्णन करता है, विनिर्देश फाइलों को परिभाषित करता है।

 <?xml version="1.0" encoding="UTF-8"?> <language_definitions> <language processor="eBPF" endian="little" size="64" variant="default" version="1.0" slafile="eBPF.sla" processorspec="eBPF.pspec" id="eBPF:LE:64:default"> <description>eBPF processor 64-bit little-endian</description> <compiler name="default" spec="eBPF.cspec" id="default"/> <external_name tool="DWARF.register.mapping.file" name="eBPF.dwarf"/> </language> </language_definitions> 

.opinion फ़ाइल लोडर को प्रोसेसर में .opinion करती है।

 <opinions> <constraint loader="Executable and Linking Format (ELF)" compilerSpecID="default"> <constraint primary="247" processor="eBPF" endian="little" size="64" /> </constraint> </opinions> 

एक प्रोग्राम काउंटर को .pspec में घोषित किया गया है, लेकिन eBPF के साथ यह अंतर्निहित है और किसी भी तरह से विनिर्देश में उपयोग नहीं किया जाता है, इसलिए यह केवल प्रो फॉर्म के प्रयोजनों के लिए है। वैसे, ईपीपीएफ का PC अंकगणित है, पता नहीं (यह निर्देश को इंगित करता है, कार्यक्रम के विशिष्ट बाइट नहीं), कूदते समय इसे ध्यान में रखें।

फ़ाइल में eBPF सहायकों के लिए एक अतिरिक्त पता स्थान भी है, यहाँ उन्हें वर्णों के रूप में घोषित किया गया है।

 <?xml version="1.0" encoding="UTF-8"?> <processor_spec> <programcounter register="PC"/> <default_symbols> <symbol name="bpf_unspec" address="syscall:0x0"/> <symbol name="bpf_map_lookup_elem" address="syscall:0x1"/> <symbol name="bpf_map_update_elem" address="syscall:0x2"/> <symbol name="bpf_map_delete_elem" address="syscall:0x3"/> <symbol name="bpf_probe_read" address="syscall:0x4"/> <symbol name="bpf_ktime_get_ns" address="syscall:0x5"/> <symbol name="bpf_trace_printk" address="syscall:0x6"/> <symbol name="bpf_get_prandom_u32" address="syscall:0x7"/> <symbol name="bpf_get_smp_processor_id" address="syscall:0x8"/> <symbol name="bpf_skb_store_bytes" address="syscall:0x9"/> <symbol name="bpf_l3_csum_replace" address="syscall:0xa"/> <symbol name="bpf_l4_csum_replace" address="syscall:0xb"/> <symbol name="bpf_tail_call" address="syscall:0xc"/> <symbol name="bpf_clone_redirect" address="syscall:0xd"/> <symbol name="bpf_get_current_pid_tgid" address="syscall:0xe"/> <symbol name="bpf_get_current_uid_gid" address="syscall:0xf"/> <symbol name="bpf_get_current_comm" address="syscall:0x10"/> <symbol name="bpf_get_cgroup_classid" address="syscall:0x11"/> <symbol name="bpf_skb_vlan_push" address="syscall:0x12"/> <symbol name="bpf_skb_vlan_pop" address="syscall:0x13"/> <symbol name="bpf_skb_get_tunnel_key" address="syscall:0x14"/> <symbol name="bpf_skb_set_tunnel_key" address="syscall:0x15"/> <symbol name="bpf_perf_event_read" address="syscall:0x16"/> <symbol name="bpf_redirect" address="syscall:0x17"/> <symbol name="bpf_get_route_realm" address="syscall:0x18"/> <symbol name="bpf_perf_event_output" address="syscall:0x19"/> <symbol name="bpf_skb_load_bytes" address="syscall:0x1a"/> <symbol name="bpf_get_stackid" address="syscall:0x1b"/> <symbol name="bpf_csum_diff" address="syscall:0x1c"/> <symbol name="bpf_skb_get_tunnel_opt" address="syscall:0x1d"/> <symbol name="bpf_skb_set_tunnel_opt" address="syscall:0x1e"/> <symbol name="bpf_skb_change_proto" address="syscall:0x1f"/> <symbol name="bpf_skb_change_type" address="syscall:0x20"/> <symbol name="bpf_skb_under_cgroup" address="syscall:0x21"/> <symbol name="bpf_get_hash_recalc" address="syscall:0x22"/> <symbol name="bpf_get_current_task" address="syscall:0x23"/> <symbol name="bpf_probe_write_user" address="syscall:0x24"/> </default_symbols> <default_memory_blocks> <memory_block name="eBPFHelper_functions" start_address="syscall:0" length="0x200" initialized="true"/> </default_memory_blocks> </processor_spec> 

.sinc फ़ाइल सबसे अधिक .sinc एक्सटेंशन फ़ाइल है, सभी रजिस्टर, EBPF निर्देश की संरचना, टोकन, मेमोनामिक्स और स्लीघ में निर्देशों के शब्दार्थ यहां परिभाषित किए गए हैं।

 define space ram type=ram_space size=8 default; define space register type=register_space size=4; define space syscall type=ram_space size=2; define register offset=0 size=8 [ R0 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 PC ]; define token instr(64) imm=(32, 63) signed off=(16, 31) signed src=(12, 15) dst=(8, 11) op_alu_jmp_opcode=(4, 7) op_alu_jmp_source=(3, 3) op_ld_st_mode=(5, 7) op_ld_st_size=(3, 4) op_insn_class=(0, 2) ; #We'll need this token to operate with LDDW instruction, which has 64 bit imm value define token immtoken(64) imm2=(32, 63) ; #To operate with registers attach variables [ src dst ] [ R0 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 _ _ _ _ _ ]; … :ADD dst, src is src & dst & op_alu_jmp_opcode=0x0 & op_alu_jmp_source=1 & op_insn_class=0x7 { dst=dst + src; } :ADD dst, imm is imm & dst & op_alu_jmp_opcode=0x0 & op_alu_jmp_source=0 & op_insn_class=0x7 { dst=dst + imm; } … 

EBPF लोडर ELF लोडर की बुनियादी क्षमताओं का विस्तार करता है ताकि यह पहचान सके कि आपके द्वारा Ghidra पर डाउनलोड किए गए प्रोग्राम में एक EBPF प्रोसेसर है। उसके लिए, ElfConstants घिड्रा में एक बीपीएफ स्थिरांक आवंटित किया गया है, और लोडर इसके लिए ईएक्सपीएफ प्रोसेसर निर्धारित करता है।

 package ghidra.app.util.bin.format.elf.extend; import ghidra.app.util.bin.format.elf.*; import ghidra.program.model.lang.*; import ghidra.util.exception.*; import ghidra.util.task.TaskMonitor; public class eBPF_ElfExtension extends ElfExtension { @Override public boolean canHandle(ElfHeader elf) { return elf.e_machine() == ElfConstants.EM_BPF && elf.is64Bit(); } @Override public boolean canHandle(ElfLoadHelper elfLoadHelper) { Language language = elfLoadHelper.getProgram().getLanguage(); return canHandle(elfLoadHelper.getElfHeader()) && "eBPF".equals(language.getProcessor().toString()) && language.getLanguageDescription().getSize() == 64; } @Override public String getDataTypeSuffix() { return "eBPF"; } @Override public void processGotPlt(ElfLoadHelper elfLoadHelper, TaskMonitor monitor) throws CancelledException { if (!canHandle(elfLoadHelper)) { return; } super.processGotPlt(elfLoadHelper, monitor); } } 

स्थानांतरण हैंडलर disassembler और decompiler में eBPF नक्शे को लागू करने के लिए आवश्यक है। उनके साथ बातचीत कई सहायकों के माध्यम से की जाती है, फ़ंक्शंस नक्शे को इंगित करने के लिए एक फ़ाइल विवरणक का उपयोग करते हैं। स्थानांतरण तालिका के आधार पर, यह देखा जा सकता है कि लोडर LDDW निर्देश को पैच करता है, जो इन सहायकों के लिए Rn उत्पन्न करता है (उदाहरण के लिए, bpf_map_lookup_elem(…) )।

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

 public class eBPF_ElfRelocationHandler extends ElfRelocationHandler { @Override public boolean canRelocate(ElfHeader elf) { return elf.e_machine() == ElfConstants.EM_BPF; } @Override public void relocate(ElfRelocationContext elfRelocationContext, ElfRelocation relocation, Address relocationAddress) throws MemoryAccessException, NotFoundException { ElfHeader elf = elfRelocationContext.getElfHeader(); if (elf.e_machine() != ElfConstants.EM_BPF) { return; } Program program = elfRelocationContext.getProgram(); Memory memory = program.getMemory(); int type = relocation.getType(); int symbolIndex = relocation.getSymbolIndex(); long value; boolean appliedSymbol = true; //Relocations with maps always have type 0x1. Since eBPF hasn't names of constants (types) of relocations, it was decided to use magic //number 1. if (type == 1) { try { int SymbolIndex= relocation.getSymbolIndex(); ElfSymbol Symbol = elfRelocationContext.getSymbol(SymbolIndex); String map = Symbol.getNameAsString(); SymbolTable table = program.getSymbolTable(); Address mapAddr = table.getSymbol(map).getAddress(); String sec_name = elfRelocationContext.relocationTable.getSectionToBeRelocated().getNameAsString(); if (sec_name.toString().contains("debug")) { return; } value = mapAddr.getAddressableWordOffset(); Byte dst = memory.getByte(relocationAddress.add(0x1)); memory.setLong(relocationAddress.add(0x4), value); memory.setByte(relocationAddress.add(0x1), (byte) (dst + 0x10)); } catch(NullPointerException e) {} } if (appliedSymbol && symbolIndex == 0) { markAsWarning(program, relocationAddress, Long.toString(type), "applied relocation with symbol-index of 0", elfRelocationContext.getLog()); } } } 

EBPF को हटाने और विघटित करने का परिणाम है

और अंत में, हम eBPF disassembler और decompiler प्राप्त करते हैं! स्वास्थ्य के लिए उपयोग करें!

GitHub पर विस्तार: Ghidra के लिए eBPF ।

यहां जारी: यहां

पुनश्च

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