यह डंप एक पहेली है

या मूर्खों और विद्रोहियों के लिए एडवांस्ड शॉटगन पार्सिंग

एक समय की बात है

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

उस समय कुछ तदर्थ (ad hoc) समाधान मैन्युअल रूप से उन हिस्सों को जोड़कर बनाया गया होगा जो एक साथ फिट होते दिखते थे, कुछ भयानक python कंसोल काम और बदसूरत ad hoc bash स्क्रिप्टिंग के साथ। यह पर्याप्त अच्छा था, लेकिन समय-गहन।

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

लेकिन निश्चित रूप से कोई बेहतर तरीका होना चाहिए?

Zip फ़ाइलों के बारे में विशेष रूप से कुछ दिलचस्प चीज़ें हैं (जो JAR फ़ाइलों के लिए उपयोग किया जाने वाला मूल प्रारूप है)। एक गंभीर छात्र के रूप में International Journal of PoC||GTFO का काफी समय से और विशेष रूप से फ़ाइल प्रारूप स्टंटिंग में Ange Albertini के काम का अनुसरण करते हुए, मैंने सोचा कि एक Zip फ़ाइल के अंदर Zip फ़ाइल के बारे में पर्याप्त डेटा हो सकता है कि आप इसे फिर से एक साथ जोड़ने का अच्छा काम कर सकें।

तो संदर्भ बिंदुओं को हटाकर, आइए तकनीकी विवरणों में आते हैं।

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

इनमें से कुछ सन्निहित (contiguous) रूप से चल सकते हैं, कुछ नहीं, जिसमें ब्लॉकों के सन्निहित होने का कोई स्पष्ट पैटर्न नहीं होता।

इसका सीधा सा मतलब है कि हमारे सामने समस्या यह है कि डेटा पृष्ठों को इस तरह कैसे पुनर्व्यवस्थित किया जाए कि वे हमें उन फ़ाइलों की वैध (या लगभग वैध) छवियाँ प्रदान करें जिन्हें हम निकालना चाहते हैं।

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

आइए इसे उल्टा करके देखें, थोड़ा और विवरण में जाते हुए:

• एंड ऑफ सेंट्रल डायरेक्टरी हमें बताता है:

  • Zip फ़ाइल के भीतर EOCD रिकॉर्ड का सटीक स्थान (CD का ऑफसेट, EOCD से पहले आने वाली CD की लंबाई के साथ)
  • कितनी फ़ाइलों (और इसलिए CD रिकॉर्ड) की तलाश करनी है।
  • Zip फ़ाइल में पहले CD रिकॉर्ड का सटीक स्थान।

• प्रत्येक सेंट्रल डायरेक्टरी रिकॉर्ड हमें बताता है:

  • संपीड़ित फ़ाइल डेटा का CRC32
  • टाइमस्टैम्प
  • बहुत सारा अन्य मेटाडेटा (संपीड़न विधि, फ्लैग, OS संस्करण प्रयुक्त/आवश्यक...)
  • संबंधित LF चंक के लिए फ़ाइल के भीतर एक इंडेक्स
  • महत्वपूर्ण रूप से: संबंधित LF चंक की छवि बनाने के लिए पर्याप्त डेटा।

• प्रत्येक लोकल फ़ाइल रिकॉर्ड हमें बताता है:

  • हमारे डंप में किसी फ़ाइल के आरंभ का स्थान
  • यदि फ़ाइल काफी छोटी है, तो हमें पूरी फ़ाइल उसी पृष्ठ के भीतर मिल जाती है, या अगले पेज किए गए चंक में अगले फ़ाइल हेडर की उपस्थिति के कारण!
  • यदि पर्याप्त छोटी फ़ाइलें पर्याप्त पृष्ठों में भरी हुई हैं, तो हम पृष्ठों के स्थान और ज्ञात डायरेक्टरी मानों का उपयोग करके पृष्ठों के लिए एक क्रम बना सकते हैं (ज्ञात अंतराल के साथ!)

उपरोक्त सब कुछ हमें इस ओर ले जाता है कि अधिकांश फ़ाइल का पुनर्निर्माण हो चुका है।

प्लॉट ट्विस्ट - हमें वास्तविक रूप से एक से अधिक JAR फ़र्मवेयर से निपटना होगा!

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

यहाँ आवश्यक समाधान kmeans एल्गोरिदम है (उर्फ "लॉयड का एल्गोरिदम")। यहाँ एक बहुत अच्छा वीडियो है जो बताता है कि यह कैसे काम करता है। SciPy के पास एक अच्छा संस्करण तैयार था, लेकिन मुझे पहचानना/ पैच एल्गोरिदम को लागू करने वाला एकमात्र क्लस्टरिंग/एनालिटिक्स क्रेट, ताकि यह Rust कार्यान्वयन के लिए काम कर सके। सौभाग्य से मुझे इसे शुरू से नहीं लिखना पड़ा।

उसके बाद काम आसान हो जाता है।

हम ऐसा करने के लिए कई सुविधाओं का उपयोग कर सकते हैं। Flags, Method और Version फ़ील्ड सभी फ़ाइल को संपीड़ित करने के लिए उपयोग किए गए Zip स्टैक के आधार पर भिन्न होते हैं। इसके अलावा, हेडर में टाइमस्टैम्प होते हैं, और सामान्यतः यह संभावना नहीं है कि सभी फ़र्मवेयर एक ही समय में संकलित और संपीड़ित किए गए हों।

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

हम इन्हें एक यूक्लिडियन वेक्टर (जो ℝ में मानों की एक n-आयामी सरणी, या फ्लोट कोऑर्डिनेट्स के लिए एक फैंसी शब्द है, लेकिन ऊपर दिया गया वीडियो शायद सबसे सीधा स्पष्टीकरण है) में परिवर्तित करते हैं और क्लस्टरिंग एल्गोरिदम हमारे लिए बाकी सब कुछ कर देता है, सभी पार्स किए गए हेडर को अपेक्षित संख्या में बकेट्स में इकट्ठा करता है।

पार्सिंग पर एक संक्षिप्त पार्श्व-टिप्पणी

हालाँकि मैंने इस विधि के प्रोटोटाइप के लिए इसे काफी अधूरे Python स्क्रिप्ट में लिखा है, PoC के साथ लगभग 70-80% JAR सामग्री पुनर्प्राप्ति दर तक पहुँचने के बाद मैंने वहीं रुकने और Rust में एक तेज़ संस्करण लागू करने का फैसला किया है।

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

यदि शानदार तेज़ और सुपाठ्य पार्सर दिलचस्प लगते हैं, तो देखें

• पार्सर लिखना, जैसे कि यह 2017 है
• Nom Benchmarks - जिसमें किसी ने शुरू से Rust में एक http पार्सर लिखा, जो बहुत तेज़ C कार्यान्वयन से थोड़ा तेज़ है, बिना किसी बफर ओवरफ्लो के।

इसके अलावा, इस तरह का विश्लेषण Python में चलाना स्वाभाविक रूप से धीमा है, और वास्तव में इस दृष्टिकोण की व्यवहार्यता का पता लगाने के लिए एक PoC तक पहुँचने का मार्ग होने के अलावा इसका बहुत अधिक उद्देश्य कभी नहीं था।

खैर, इतना ही काफी...

आगे बढ़ते हुए

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