mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-15 09:27:32 +00:00
Translated ['macos-hardening/macos-security-and-privilege-escalation/mac
This commit is contained in:
Translator
parent
f8da75d90a
commit
065144ba9a
2 changed files with 193 additions and 155 deletions
|
|
@ -1,4 +1,4 @@
|
|||
# macOS IPC - इंटर प्रोसेस कम्युनिकेशन
|
||||
# macOS IPC - इंटर प्रोसेस कम्यूनिकेशन
|
||||
|
||||
<details>
|
||||
|
||||
|
|
@ -6,7 +6,7 @@
|
|||
|
||||
HackTricks का समर्थन करने के अन्य तरीके:
|
||||
|
||||
* यदि आप अपनी कंपनी का विज्ञापन **HackTricks में देखना चाहते हैं** या **HackTricks को PDF में डाउनलोड करना चाहते हैं** तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) देखें!
|
||||
* अगर आप अपनी कंपनी का विज्ञापन **HackTricks में देखना चाहते हैं** या **HackTricks को PDF में डाउनलोड करना चाहते हैं** तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) देखें!
|
||||
* [**आधिकारिक PEASS और HackTricks स्वैग**](https://peass.creator-spring.com) प्राप्त करें
|
||||
* हमारे विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) संग्रह, **The PEASS Family** की खोज करें
|
||||
* **शामिल हों** 💬 [**डिस्कॉर्ड समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) या हमें **ट्विटर** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** पर फॉलो** करें।
|
||||
|
|
@ -18,45 +18,46 @@ HackTricks का समर्थन करने के अन्य तरी
|
|||
|
||||
### मौलिक जानकारी
|
||||
|
||||
Mach **कार्यों** का उपयोग संसाधन साझा करने के लिए **सबसे छोटी इकाई** के रूप में करता है, और प्रत्येक कार्य में **कई धागे** हो सकते हैं। ये **कार्य और धागे 1:1 मैप किए गए हैं POSIX प्रक्रियाओं और धागों के साथ**।
|
||||
Mach **कार्यों** का उपयोग संसाधन साझा करने के लिए **सबसे छोटी इकाई** के रूप में करता है, और प्रत्येक कार्य में **कई धागे** हो सकते हैं। ये **कार्य और धागे 1:1 से POSIX प्रक्रियाओं और धागों के साथ मैप होते हैं**।
|
||||
|
||||
कार्यों के बीच संचार Mach इंटर-प्रोसेस कम्युनिकेशन (IPC) के माध्यम से होता है, जो एक-तरफा संचार चैनल का उपयोग करता है। **संदेश पोर्टों के बीच स्थानांतरित किए जाते हैं**, जो कर्नेल द्वारा प्रबंधित **संदेश कतारों** की तरह कार्य करते हैं।
|
||||
कार्यों के बीच संचार Mach इंटर-प्रोसेस कम्यूनिकेशन (IPC) के माध्यम से होता है, जो एक-तरफा संचार चैनलों का उपयोग करता है। **संदेश पोर्टों के बीच स्थानांतरित किए जाते हैं**, जो कर्नेल द्वारा प्रबंधित **संदेश कतारों** की तरह कार्य करते हैं।
|
||||
|
||||
**पोर्ट** Mach IPC का **मौलिक** तत्व है। इसका उपयोग **संदेश भेजने और प्राप्त करने** के लिए किया जा सकता है।
|
||||
|
||||
प्रत्येक प्रक्रिया के पास एक **IPC तालिका** होती है, जिसमें प्रक्रिया के **mach पोर्ट** मिल सकते हैं। मच पोर्ट का नाम वास्तव में एक संख्या है (कर्नेल ऑब्जेक्ट के लिए एक पॉइंटर)।
|
||||
|
||||
एक प्रक्रिया एक पोर्ट नाम को कुछ अधिकारों के साथ **एक विभिन्न कार्य** को भेज सकती है और कर्नेल इसे **दूसरे कार्य की IPC तालिका में एंट्री** बना देगा।
|
||||
एक प्रक्रिया एक पोर्ट नाम को कुछ अधिकारों के साथ **एक विभिन्न कार्य** को भेज सकती है और कर्नेल इसे **दूसरे कार्य की IPC तालिका में** दर्शाएगा।
|
||||
|
||||
### पोर्ट अधिकार
|
||||
|
||||
पोर्ट अधिकार, जो यह परिभाषित करते हैं कि एक कार्य किस कार्रवाई कर सकता है, इस संचार के लिए महत्वपूर्ण हैं। संभावित **पोर्ट अधिकार** हैं ([यहाँ से परिभाषाएँ](https://docs.darlinghq.org/internals/macos-specifics/mach-ports.html)):
|
||||
|
||||
* **प्राप्ति अधिकार**, जो पोर्ट को भेजे गए संदेश प्राप्त करने की अनुमति देता है। Mach पोर्ट MPSC (एकाधिक उत्पादक, एक उपभोक्ता) कतारें होती हैं, जिसका मतलब है कि पूरे सिस्टम में प्रत्येक पोर्ट के लिए केवल **एक प्राप्ति अधिकार हो सकता है** (जैसे कि पाइप में, जहां कई प्रक्रियाएं सभी एक पाइप के पढ़ने के अंत के लिए फ़ाइल डिस्क्रिप्टर्स को धारण कर सकती हैं)।
|
||||
* **प्राप्ति अधिकार वाला** एक **कार्य संदेश प्राप्त कर सकता है और** **भेजने के अधिकार बना सकता है**, जिससे उसे संदेश भेजने की अनुमति मिलती है। मूल रूप से केवल **अपने कार्य के पास प्राप्ति अधिकार होता है**।
|
||||
* अगर प्राप्ति अधिकार का मालिक **मर जाता है** या उसे मार देता है, तो **भेजने का अधिकार अनर्थक (मरा नाम) हो जाता है**।
|
||||
* **प्राप्ति अधिकार**, जो पोर्ट को भेजे गए संदेश प्राप्त करने की अनुमति देता है। Mach पोर्ट MPSC (एकाधिक उत्पादक, एक उपभोक्ता) कतारें होती हैं, जिसका मतलब है कि पूरे सिस्टम में प्रत्येक पोर्ट के लिए केवल **एक प्राप्ति अधिकार हो सकता है** (जैसे कि पाइप्स में, जहां कई प्रक्रियाएं सभी एक पाइप के पढ़ने के अंत के लिए फ़ाइल डिस्क्रिप्टर्स को धारण कर सकती हैं)।
|
||||
* **प्राप्ति अधिकार वाले कार्य** संदेश प्राप्त कर सकते हैं और **भेजने के अधिकार बना सकते हैं**, जिससे उसे संदेश भेजने की अनुमति मिलती है। मूल रूप से केवल **अपने कार्य के पास प्राप्ति अधिकार होता है**।
|
||||
* अगर प्राप्ति अधिकार के मालिक **मर जाता है** या उसे मार देता है, तो **भेजने का अधिकार अनर्थक (मरा नाम) हो जाता है**।
|
||||
* **भेजने का अधिकार**, जो पोर्ट को संदेश भेजने की अनुमति देता है।
|
||||
* भेजने का अधिकार **क्लोन** किया जा सकता है ताकि भेजने का अधिकार वाले कार्य अधिकार को क्लोन कर सके और **तीसरे कार्य को दे सके**।
|
||||
* भेजने का अधिकार **क्लोन** किया जा सकता है ताकि भेजने का अधिकार वाले कार्य अधिकार को क्लोन कर सके और इसे तीसरे कार्य को **प्रदान** कर सके।
|
||||
* ध्यान दें कि **पोर्ट अधिकार** Mac संदेश के माध्यम से भी **पारित** किए जा सकते हैं।
|
||||
* **एक बार भेजने का अधिकार**, जो पोर्ट को एक संदेश भेजने की अनुमति देता है और फिर गायब हो जाता है।
|
||||
* यह अधिकार **क्लोन** नहीं किया जा सकता है, लेकिन इसे **हटाया** जा सकता है।
|
||||
* **पोर्ट सेट अधिकार**, जो एक _पोर्ट सेट_ को दर्शाता है बल्कि एक एकल पोर्ट। पोर्ट सेट से संदेश को निकालने पोर्ट सेट में एक पोर्ट से संदेश को निकालता है। पोर्ट सेट का उपयोग कई पोर्टों पर समय-समय पर सुनने के लिए किया जा सकता है, बहुत सारे `select`/`poll`/`epoll`/`kqueue`/`Unix` की तरह।
|
||||
* **मरा नाम**, जो वास्तव में एक पोर्ट अधिकार नहीं है, बल्कि केवल एक प्लेसहोल्डर है। जब एक पोर्ट नष्ट होता है, तो पोर्ट के सभी मौजूदा पोर्ट अधिकार मरे नाम में बदल जाते हैं।
|
||||
* यह अधिकार **क्लोन नहीं** किया जा सकता है, लेकिन इसे **हटाया** जा सकता है।
|
||||
* **पोर्ट सेट अधिकार**, जो एक _पोर्ट सेट_ को दर्शाता है बल्कि एक एकल पोर्ट नहीं। पोर्ट सेट से संदेश को डीक्यू करने से यह उसमें शामिल पोर्टों में से एक से संदेश को डीक्यू करता है। पोर्ट सेट का उपयोग कई पोर्टों पर सुनने के लिए किया जा सकता है, जैसे `select`/`poll`/`epoll`/`kqueue` Unix में।
|
||||
* **मरा नाम**, जो वास्तव में एक पोर्ट अधिकार नहीं है, बल्कि केवल एक जगहधारी है। जब एक पोर्ट नष्ट होता है, तो पोर्ट के सभी मौजूदा पोर्ट अधिकार मरे नाम में बदल जाते हैं।
|
||||
|
||||
**कार्य अन्यों को SEND अधिकार पारित कर सकते हैं**, जिससे उन्हें संदेश वापस भेजने की अनुमति मिलती है। **SEND अधिकार को क्लोन भी किया जा सकता है**, ताकि एक कार्य अधिकार को डुप्लिकेट कर सके और तीसरे कार्य को अधिकार दे सके। इसके साथ, एक मध्यस्थ प्रक्रिया जिसे **बूटस्ट्रैप सर्वर** के रूप में जाना जाता है, के साथ मिलाकर, कार्यों के बीच प्रभावी संचार की अनुमति देता है।
|
||||
**कार्य अन्यों को SEND अधिकार पारित कर सकते हैं**, जिससे उन्हें संदेश वापस भेजने की अनुमति मिलती है। **SEND अधिकार भी क्लोन किया जा सकता है**, ताकि एक कार्य अधिकार को डुप्लिकेट कर सके और तीसरे कार्य को अधिकार दे सके। इसके साथ, एक मध्यस्थ प्रक्रिया जिसे **बूटस्ट्रैप सर्वर** के रूप में जाना जाता है, के साथ मिलाकर, कार्यों के बीच प्रभावी संचार की अनुमति देता है।
|
||||
|
||||
### फाइल पोर्ट
|
||||
|
||||
फाइल पोर्ट फाइल डिस्क्रिप्टर्स को Mac पोर्ट में एनकैप्सुलेट करने की अनुमति देते हैं (Mach पोर्ट अधिकार का उपयोग करके)। `fileport_makeport` का उपयोग करके दिए गए FD से `fileport_makefd` का उपयोग करके एक `fileport` बनाया जा सकता है।
|
||||
फाइल पोर्ट फाइल डिस्क्रिप्टर्स को Mac पोर्ट में बंधने की अनुमति देते हैं (Mach पोर्ट अधिकार का उपयोग करके)। `fileport_makeport` का उपयोग करके दिए गए FD से `fileport` बनाना संभव है और `fileport_makefd` का उपयोग करके एक FD बनाना संभव है।
|
||||
|
||||
### संचार स्थापित करना
|
||||
|
||||
पहले से किए गए तरीके के अनुसार, Mach संदेश का उपयोग करके अधिकार भेजना संभव है, हालांकि, आप **एक संदेश भेजने के अधिकार के बिना अधिकार भेज सकते हैं**। तो, पहली संचार कैसे स्थापित की जाती है?
|
||||
पहले से किसी अधिकार के बिना एक अधिकार भेजना संभव नहीं है, इसलिए, पहली संचार कैसे स्थापित की जाती है?
|
||||
|
||||
इसके लिए, **बूटस्ट्रैप सर्वर** (**मैक में लॉन्चडी**), जैसे कि **हर कोई बूटस्ट्रैप सर्वर को SEND अधिकार प्राप्त कर सकता है**, इसे संभव बनाता है कि यह किसी अन्य प्रक्रिया को संदेश भेजने के लिए अधिकार के लिए उससे पूछा जा सकता है:
|
||||
इसके लिए, **बूटस्ट्रैप सर्वर** (**मैक में launchd**) शामिल है, क्योंकि **हर कोई बूटस्ट्रैप सर्वर को SEND अधिकार** प्राप्त कर सकता है, इससे दूसरे प्रक्रिया को संदेश भेजने के लिए अधिकार मांग सकता है:
|
||||
|
||||
1. कार्य **A** एक **नया पोर्ट बनाता है**, जिसे उसके पास **प्राप्ति अधिकार** होता है।
|
||||
2. कार्य **A**, प्राप्ति अधिकार के धारक होने के नाते, **पोर्ट के लिए एक SEND
|
||||
1. कार्य **A** एक **नया पोर्ट बनाता है**, जिसे पर उसके पास **प्राप्ति अधिकार** होता है।
|
||||
2. कार्य **A**, प्राप्ति अधिकार के धारक के रूप में, **पोर्ट के लिए SEND अधिकार उत्पन्न करता है**।
|
||||
3. कार्य **A** बूटस्ट्रैप सर्वर के साथ एक **संबंध स्थापित करता है**, और उसे उस पोर्ट
|
||||
### एक Mach संदेश
|
||||
|
||||
[यहाँ अधिक जानकारी पाएं](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/)
|
||||
|
|
@ -77,12 +78,12 @@ Processes possessing a _**प्राप्ति अधिकार**_ Mach
|
|||
प्रारंभिक फ़ील्ड **`msgh_bits`** एक बिटमैप है:
|
||||
|
||||
* पहला बिट (सबसे महत्वपूर्ण) यह दर्शाता है कि एक संदेश जटिल है (इसके बारे में और अधिक नीचे)
|
||||
* तीसरा और चौथा कर्नल द्वारा उपयोग किया जाता है
|
||||
* दूसरे बाइट के **5 सबसे कम महत्वपूर्ण बिट** का उपयोग **वाउचर** के लिए किया जा सकता है: एक और प्रकार का पोर्ट कुंजी/मान संयोजन भेजने के लिए।
|
||||
* तीसरे बाइट के **5 सबसे कम महत्वपूर्ण बिट** का उपयोग **स्थानीय पोर्ट** के लिए किया जा सकता है
|
||||
* चौथे बाइट के **5 सबसे कम महत्वपूर्ण बिट** का उपयोग **दूरस्थ पोर्ट** के लिए किया जा सकता है
|
||||
* तीसरा और चौथा कर्णल द्वारा उपयोग किया जाता है
|
||||
* दूसरे बाइट के **5 सबसे कमजोर बिट** का उपयोग **वाउचर** के लिए किया जा सकता है: एक और प्रकार का पोर्ट कुंजी/मान संयोजन भेजने के लिए।
|
||||
* तीसरे बाइट के **5 सबसे कमजोर बिट** का उपयोग **स्थानीय पोर्ट** के लिए किया जा सकता है
|
||||
* चौथे बाइट के **5 सबसे कमजोर बिट** का उपयोग **दूरस्थ पोर्ट** के लिए किया जा सकता है
|
||||
|
||||
वाउचर, स्थानीय और दूरस्थ पोर्ट में निर्दिष्ट किए जा सकने वाले प्रकार हैं ([**mach/message.h**](https://opensource.apple.com/source/xnu/xnu-7195.81.3/osfmk/mach/message.h.auto.html) से):
|
||||
वाउचर, स्थानीय और दूरस्थ पोर्ट में निर्दिष्ट किए जा सकने वाले प्रकार हैं ([**mach/message.h**](https://opensource.apple.com/source/xnu/xnu-7195.81.3/osfmk/mach/message.h.auto.html)):
|
||||
```c
|
||||
#define MACH_MSG_TYPE_MOVE_RECEIVE 16 /* Must hold receive right */
|
||||
#define MACH_MSG_TYPE_MOVE_SEND 17 /* Must hold send right(s) */
|
||||
|
|
@ -97,10 +98,10 @@ Processes possessing a _**प्राप्ति अधिकार**_ Mach
|
|||
```
|
||||
उदाहरण के लिए, `MACH_MSG_TYPE_MAKE_SEND_ONCE` का उपयोग **सूचित** करने के लिए किया जा सकता है कि इस पोर्ट के लिए एक **एक-बार-भेजें** **अधिकार** उत्पन्न और स्थानांतरित किया जाना चाहिए। इसे `MACH_PORT_NULL` को निर्दिष्ट किया जा सकता है ताकि प्राप्तकर्ता को जवाब देने की क्षमता न हो।
|
||||
|
||||
एक सरल **द्विदिशीय संचार** प्राप्त करने के लिए एक प्रक्रिया मशीन **संदेश हेडर** में एक _उत्तर पोर्ट_ (**`msgh_local_port`**) निर्दिष्ट कर सकती है जहां संदेश का प्राप्तकर्ता इस संदेश का उत्तर भेज सकता है।
|
||||
एक सरल **द्विदिशीय संचार** प्राप्त करने के लिए एक प्रक्रिया मशीन **संदेश हेडर** में एक _उत्तर पोर्ट_ (**`msgh_local_port`**) निर्दिष्ट कर सकती है जहां संदेश के **प्राप्तकर्ता** इस संदेश का उत्तर भेज सकता है।
|
||||
|
||||
{% hint style="success" %}
|
||||
ध्यान दें कि इस प्रकार के द्विदिशीय संचार का उपयोग एक्सपीसी संदेशों में किया जाता है जो एक प्रतिक्रिया की उम्मीद रखते हैं (`xpc_connection_send_message_with_reply` और `xpc_connection_send_message_with_reply_sync`)। लेकिन **आम तौर पर विभिन्न पोर्ट बनाए जाते हैं** जैसा पहले स्पष्ट किया गया है द्विदिशीय संचार बनाने के लिए।
|
||||
ध्यान दें कि इस प्रकार के द्विदिशीय संचार का उपयोग एक्सपीसी संदेशों में किया जाता है जो एक प्रतिक्रिया की उम्मीद रखते हैं (`xpc_connection_send_message_with_reply` और `xpc_connection_send_message_with_reply_sync`)। लेकिन **आम तौर पर विभिन्न पोर्ट बनाए जाते हैं** जैसा पहले स्पष्ट किया गया है ताकि द्विदिशीय संचार बनाया जा सके।
|
||||
{% endhint %}
|
||||
|
||||
संदेश हेडर के अन्य फ़ील्ड हैं:
|
||||
|
|
@ -111,16 +112,16 @@ Processes possessing a _**प्राप्ति अधिकार**_ Mach
|
|||
- `msgh_id`: इस संदेश का आईडी, जिसे प्राप्तकर्ता द्वारा व्याख्या किया जाता है।
|
||||
|
||||
{% hint style="danger" %}
|
||||
ध्यान दें कि **मश संदेश `मश पोर्ट`** के माध्यम से भेजे जाते हैं, जो मश कर्नल में बनाया गया एक **एकल प्राप्तकर्ता**, **एकाधिक भेजने वाला** संचार चैनल है। **एकाधिक प्रक्रियाएँ** एक मश पोर्ट पर संदेश भेज सकती हैं, लेकिन किसी भी समय केवल **एक प्रक्रिया पढ़ सकती है**।
|
||||
ध्यान दें कि **मश संदेश** एक `मश पोर्ट` के माध्यम से भेजे जाते हैं, जो मश कर्नल में बनाया गया एक **एकल प्राप्तकर्ता**, **एकाधिक भेजने वाला** संचार चैनल है। **एकाधिक प्रक्रियाएँ** एक मश पोर्ट को संदेश भेज सकती हैं, लेकिन किसी भी समय केवल **एक प्रक्रिया** इसे पढ़ सकती है।
|
||||
{% endhint %}
|
||||
|
||||
उसके बाद संदेश **`mach_msg_header_t`** हेडर द्वारा और **बॉडी** द्वारा और **ट्रेलर** (यदि कोई हो) द्वारा बनाए जाते हैं और इसे उत्तर देने की अनुमति दे सकते हैं। इन मामलों में, कर्नल को सिर्फ एक कार्य से दूसरे कार्य तक संदेश पारित करने की आवश्यकता होती है।
|
||||
|
||||
एक **ट्रेलर** एक **संदेश में कर्नल द्वारा जोड़ी गई जानकारी** है (उपयोगकर्ता द्वारा सेट नहीं की जा सकती) जिसे संदेश प्राप्ति में अनुरोध किया जा सकता है झंडियों `MACH_RCV_TRAILER_<trailer_opt>` (वहाँ विभिन्न जानकारी हो सकती है जो अनुरोध की जा सकती है)।
|
||||
एक **ट्रेलर** एक **संदेश में कर्नल द्वारा जोड़ी गई जानकारी** है (उपयोगकर्ता द्वारा सेट नहीं की जा सकती) जिसे संदेश स्वीकृति में अनुरोध किया जा सकता है झंडियों `MACH_RCV_TRAILER_<trailer_opt>` (वहाँ विभिन्न जानकारी हो सकती है जो अनुरोध की जा सकती है)।
|
||||
|
||||
#### जटिल संदेश
|
||||
|
||||
हालांकि, अन्य अधिक **जटिल** संदेश हैं, जैसे अतिरिक्त पोर्ट अधिकार या साझा मेमोरी पास करने वाले, जहां कर्नल को भी इन वस्तुओं को प्राप्तकर्ता को भेजने की आवश्यकता होती है। इस मामले में, हेडर `msgh_bits` का सबसे महत्वपूर्ण बिट सेट किया जाता है।
|
||||
हालांकि, और भी अधिक **जटिल** संदेश हैं, जैसे अतिरिक्त पोर्ट अधिकार या साझा मेमोरी पास करने वाले, जहां कर्नल को इन वस्तुओं को प्राप्तकर्ता को भेजने की आवश्यकता होती है। इस मामले में, हेडर `msgh_bits` का सबसे महत्वपूर्ण बिट सेट किया जाता है।
|
||||
|
||||
पारित करने के लिए संभावित वर्णन [**`mach/message.h`**](https://opensource.apple.com/source/xnu/xnu-7195.81.3/osfmk/mach/message.h.auto.html) में परिभाषित हैं:
|
||||
```c
|
||||
|
|
@ -141,18 +142,18 @@ mach_msg_descriptor_type_t type : 8;
|
|||
```
|
||||
### Mac Ports APIs
|
||||
|
||||
नोट करें कि पोर्ट्स को टास्क नेमस्पेस से जुड़ा होता है, इसलिए पोर्ट बनाने या खोजने के लिए, टास्क नेमस्पेस भी क्वेरी किया जाता है (अधिक जानकारी `mach/mach_port.h` में):
|
||||
नोट करें कि पोर्ट्स को टास्क नेमस्पेस से जुड़ा होता है, इसलिए पोर्ट बनाने या खोजने के लिए, टास्क नेमस्पेस भी क्वेरी की जाती है (अधिक जानकारी `mach/mach_port.h` में):
|
||||
|
||||
* **`mach_port_allocate` | `mach_port_construct`**: एक पोर्ट बनाएं।
|
||||
* `mach_port_allocate` एक **पोर्ट सेट** भी बना सकता है: एक समूह के पोर्ट्स पर प्राप्ति अधिकार। जब कोई संदेश प्राप्त होता है, तो इसमें संकेतित किया जाता है कि संदेश किस पोर्ट से आया है।
|
||||
* `mach_port_allocate_name`: पोर्ट का नाम बदलें (डिफ़ॉल्ट रूप से 32बिट पूर्णांक)
|
||||
* `mach_port_names`: लक्षित से पोर्ट नाम प्राप्त करें
|
||||
* `mach_port_type`: एक नाम पर टास्क के अधिकार प्राप्त करें
|
||||
* `mach_port_rename`: एक पोर्ट का नाम बदलें (जैसे FDs के लिए dup2)
|
||||
* `mach_port_allocate`: एक नया प्राप्ति, पोर्ट सेट या DEAD_NAME आवंटित करें
|
||||
* `mach_port_insert_right`: उस पोर्ट में एक नया अधिकार बनाएं जिस पर आपके पास प्राप्ति है
|
||||
* `mach_port_...`
|
||||
* **`mach_msg`** | **`mach_msg_overwrite`**: **mach संदेश भेजने और प्राप्त करने** के लिए उपयोग किए जाने वाले फ़ंक्शन। ओवरराइट संस्करण संदेश प्राप्ति के लिए एक विभिन्न बफ़र निर्दिष्ट करने की अनुमति देता है (दूसरा संस्करण इसे फिर से उपयोग करेगा)।
|
||||
- **`mach_port_allocate` | `mach_port_construct`**: एक पोर्ट **बनाएं**।
|
||||
- `mach_port_allocate` एक **पोर्ट सेट** भी बना सकता है: एक समूह के पोर्ट्स पर प्राप्ति अधिकार। जब भी एक संदेश प्राप्त होता है, तो इसमें संकेतित किया जाता है कि संदेश किस पोर्ट से आया है।
|
||||
- `mach_port_allocate_name`: पोर्ट का नाम बदलें (डिफ़ॉल्ट रूप से 32बिट पूर्णांक)
|
||||
- `mach_port_names`: लक्षित से पोर्ट नाम प्राप्त करें
|
||||
- `mach_port_type`: एक नाम पर टास्क के अधिकार प्राप्त करें
|
||||
- `mach_port_rename`: एक पोर्ट का नाम बदलें (FDs के लिए dup2 की तरह)
|
||||
- `mach_port_allocate`: एक नया प्राप्ति, PORT\_SET या DEAD\_NAME आवंटित करें
|
||||
- `mach_port_insert_right`: उस पोर्ट में एक नया अधिकार बनाएं जिस पर आपके पास प्राप्ति है
|
||||
- `mach_port_...`
|
||||
- **`mach_msg`** | **`mach_msg_overwrite`**: **mach संदेश भेजने और प्राप्त करने** के लिए उपयोग किए जाने वाले फ़ंक्शन। ओवरराइट संस्करण संदेश प्राप्ति के लिए एक विभिन्न बफ़र निर्दिष्ट करने की अनुमति देता है (अन्य संस्करण उसे पुनः उपयोग करेगा)।
|
||||
```c
|
||||
__WATCHOS_PROHIBITED __TVOS_PROHIBITED
|
||||
extern mach_msg_return_t mach_msg(
|
||||
|
|
@ -164,7 +165,7 @@ mach_port_name_t rcv_name,
|
|||
mach_msg_timeout_t timeout,
|
||||
mach_port_name_t notify);
|
||||
```
|
||||
विनिर्देशिकाओं से मान प्राप्त करें:
|
||||
रजिस्ट्री से मान प्राप्त करें:
|
||||
```armasm
|
||||
reg read $x0 $x1 $x2 $x3 $x4 $x5 $x6
|
||||
x0 = 0x0000000124e04ce8 ;mach_msg_header_t (*msg)
|
||||
|
|
@ -175,7 +176,7 @@ x4 = 0x0000000000001f03 ;mach_port_name_t (rcv_name)
|
|||
x5 = 0x0000000000000000 ;mach_msg_timeout_t (timeout)
|
||||
x6 = 0x0000000000000000 ;mach_port_name_t (notify)
|
||||
```
|
||||
**संदेश हेडर की जांच करें पहले तर्क को देखकर:**
|
||||
मैसेज हेडर की जांच करें और पहला आर्ग्यूमेंट देखें:
|
||||
```armasm
|
||||
(lldb) x/6w $x0
|
||||
0x124e04ce8: 0x00131513 0x00000388 0x00000807 0x00001f03
|
||||
|
|
@ -216,11 +217,11 @@ name ipc-object rights flags boost reqs recv send sonce oref q
|
|||
+ send -------- --- 1 <- 0x00002603 (74295) passd
|
||||
[...]
|
||||
```
|
||||
**नाम** पोर्ट को दिया गया डिफ़ॉल्ट नाम है (जांचें कि यह पहले 3 बाइट में **बढ़ रहा** है)। **`ipc-object`** पोर्ट की **विशिष्ट पहचानकर्ता** को **अविवादित** अंकित करता है।
|
||||
ध्यान दें कि केवल **`send`** अधिकार वाले पोर्ट्स में इसके मालिक की पहचान की जाती है (पोर्ट नाम + pid)।
|
||||
यहाँ ध्यान दें कि **`+`** का उपयोग करके **उसी पोर्ट से जुड़े अन्य कार्यों** को दर्शाने के लिए किया जा सकता है।
|
||||
**नाम** पोर्ट का डिफ़ॉल्ट नाम है (जांचें कि पहले 3 बाइट्स में कैसे **बढ़ रहा** है)। **`ipc-object`** पोर्ट की **विशिष्ट पहचानकर्ता** है जिसे **अस्पष्ट** बनाया गया है।
|
||||
ध्यान दें कि केवल **`send`** अधिकार वाले पोर्ट के स्वामी की पहचान कैसे की जा रही है (पोर्ट नाम + pid)।
|
||||
यहाँ ध्यान दें कि **`+`** का उपयोग करके **उसी पोर्ट से जुड़े अन्य कार्यों** को दर्शाने के लिए किया जा रहा है।
|
||||
|
||||
यहाँ देखने के लिए [**procesxp**](https://www.newosxbook.com/tools/procexp.html) का भी उपयोग किया जा सकता है ताकि **पंजीकृत सेवा नामों** (SIP अक्षम होने के कारण `com.apple.system-task-port` की आवश्यकता होने पर) भी देखा जा सके:
|
||||
[**procesxp**](https://www.newosxbook.com/tools/procexp.html) का उपयोग करके भी **पंजीकृत सेवा नामों** (SIP अक्षम होने के कारण `com.apple.system-task-port` की आवश्यकता होने पर) देखना संभव है:
|
||||
```
|
||||
procesp 1 ports
|
||||
```
|
||||
|
|
@ -228,7 +229,7 @@ procesp 1 ports
|
|||
|
||||
### कोड उदाहरण
|
||||
|
||||
नोट करें कि **भेजने वाला** एक पोर्ट आवंटित करता है, `org.darlinghq.example` नाम के लिए एक **भेजने का हक** बनाता है और इसे **बूटस्ट्रैप सर्वर** को भेजता है जबकि भेजने वाला उस नाम के **भेजने का हक** के लिए अनुरोध करता है और इसका उपयोग **संदेश भेजने** के लिए करता है।
|
||||
ध्यान दें कि **भेजने वाला** एक पोर्ट आवंटित करता है, `org.darlinghq.example` नाम के लिए एक **भेजने का अधिकार** बनाता है और इसे **बूटस्ट्रैप सर्वर** को भेजता है जबकि भेजने वाला उस नाम के **भेजने का अधिकार** मांगता है और उसे उसे को **संदेश भेजने** के लिए उपयोग करता है।
|
||||
|
||||
{% tabs %}
|
||||
{% tab title="receiver.c" %}
|
||||
|
|
@ -299,7 +300,30 @@ printf("Text: %s, number: %d\n", message.some_text, message.some_number);
|
|||
```
|
||||
{% endtab %}
|
||||
|
||||
{% टैब शीर्षक="sender.c" %}
|
||||
{% tab title="sender.c" %}
|
||||
## macOS IPC (Inter-Process Communication)
|
||||
|
||||
### Overview
|
||||
|
||||
Inter-Process Communication (IPC) mechanisms are essential for processes to communicate with each other on macOS. This can be abused by malicious actors to escalate privileges or perform other unauthorized actions.
|
||||
|
||||
### Techniques
|
||||
|
||||
1. **Mach Ports**: Mach ports are endpoints for Mach messages, allowing processes to send and receive messages. Malicious actors can abuse Mach ports for IPC-based attacks.
|
||||
|
||||
2. **XPC Services**: XPC services are lightweight, secure processes that provide inter-process communication. Attackers can exploit insecure XPC services to escalate privileges.
|
||||
|
||||
3. **Distributed Objects**: Distributed Objects is an IPC mechanism that allows objects to be used across process boundaries. This can be abused for privilege escalation attacks.
|
||||
|
||||
### Mitigations
|
||||
|
||||
- **Use Code Signing**: Ensure that all processes involved in IPC are properly code-signed to prevent unauthorized processes from communicating.
|
||||
- **Implement Secure Communication**: Encrypt and authenticate messages sent over IPC channels to prevent eavesdropping and tampering.
|
||||
- **Least Privilege**: Follow the principle of least privilege when designing IPC mechanisms to restrict processes to only necessary privileges.
|
||||
- **Monitor IPC Activity**: Regularly monitor IPC activity for any suspicious behavior or unauthorized communication attempts.
|
||||
|
||||
By understanding macOS IPC mechanisms and implementing proper security measures, you can protect your system from privilege escalation and unauthorized process abuse.
|
||||
{% endtab %}
|
||||
```c
|
||||
// Code from https://docs.darlinghq.org/internals/macos-specifics/mach-ports.html
|
||||
// gcc sender.c -o sender
|
||||
|
|
@ -351,29 +375,29 @@ return 1;
|
|||
printf("Sent a message\n");
|
||||
}
|
||||
```
|
||||
{% endtab %}
|
||||
{% endtabs %}
|
||||
|
||||
### विशेषाधिकारित पोर्ट
|
||||
|
||||
* **होस्ट पोर्ट**: यदि किसी प्रक्रिया के पास इस पोर्ट पर **भेजने** की अनुमति है तो वह **सिस्टम** के बारे में **जानकारी** प्राप्त कर सकता है (जैसे `host_processor_info`।)
|
||||
* **होस्ट प्रिव पोर्ट**: इस पोर्ट पर **भेजने** के अधिकार वाली प्रक्रिया विशेषाधिकारित क्रियाएँ कर सकती हैं जैसे कर्नेल एक्सटेंशन लोड करना। **प्रक्रिया को रूट होना चाहिए** इस अनुमति को प्राप्त करने के लिए।
|
||||
* **होस्ट प्रिव पोर्ट**: इस पोर्ट पर **भेजने** के अधिकार वाली प्रक्रिया उच्चाधिकारित क्रियाएँ कर सकती है जैसे कर्नेल एक्सटेंशन लोड करना। **प्रक्रिया को रूट होना चाहिए** इस अनुमति को प्राप्त करने के लिए।
|
||||
* इसके अतिरिक्त, **`kext_request`** API को बुलाने के लिए अन्य entitlements **`com.apple.private.kext*`** की आवश्यकता है जो केवल Apple binaries को दी जाती हैं।
|
||||
* **टास्क नाम पोर्ट:** _टास्क पोर्ट_ का एक अनुग्रहित संस्करण। यह टास्क को संदर्भित करता है, लेकिन इसे नियंत्रित करने की अनुमति नहीं देता। इसके माध्यम से केवल `task_info()` उपलब्ध लगता है।
|
||||
* **टास्क पोर्ट** (जिसे कर्नेल पोर्ट भी कहा जाता है)**:** इस पोर्ट पर भेजने के अनुमति होने पर टास्क को नियंत्रित करना संभव है (मेमोरी पढ़ना/लिखना, थ्रेड बनाना...।)
|
||||
* कॉल करें `mach_task_self()` इस पोर्ट के लिए कॉलर टास्क के लिए नाम प्राप्त करने के लिए। यह पोर्ट केवल **`exec()`** के अवसान तक विरासत में मिलता है; `fork()` के साथ नया टास्क बनाया जाता है (एक विशेष मामले के रूप में, एक टास्क को `exec()` के बाद भी एक नया टास्क पोर्ट मिलता है।) एक टास्क उत्पन्न करने और इसका पोर्ट प्राप्त करने का एकमात्र तरीका "पोर्ट स्वैप नृत्य" करना है जब `fork()` किया जा रहा हो।
|
||||
* इन पोर्ट तक पहुंचने की प्रतिबंधाएँ (बाइनरी `AppleMobileFileIntegrity` से `macos_task_policy` से):
|
||||
* यदि ऐप के पास **`com.apple.security.get-task-allow` entitlement** है तो **एक ही उपयोगकर्ता के प्रक्रियाएँ टास्क पोर्ट तक पहुंच सकती हैं** (सामान्यत: डीबगिंग के लिए Xcode द्वारा जोड़ा जाता है)। **नोटराइजेशन** प्रक्रिया इसे उत्पादन रिलीज़ में नहीं देगी।
|
||||
* **`com.apple.system-task-ports`** entitlement वाली ऐप्स किसी भी प्रक्रिया के लिए **टास्क पोर्ट प्राप्त कर सकती हैं**, केवल कर्नेल को छोड़कर। पुराने संस्करणों में इसे **`task_for_pid-allow`** कहा जाता था। यह केवल Apple एप्लिकेशन्स को प्रदान किया जाता है।
|
||||
* **रूट** एक्सेस कर सकता है ऐप्स के टास्क पोर्ट को जिन्हें **हार्डन किया नहीं गया है** (और न किसी भी Apple से)।
|
||||
* **कार्य नाम पोर्ट:** _कार्य पोर्ट_ का एक अअधिकारित संस्करण। यह कार्य को संदर्भित करता है, लेकिन इसे नियंत्रित करने की अनुमति नहीं देता। इसके माध्यम से केवल `task_info()` उपलब्ध लगता है।
|
||||
* **कार्य पोर्ट** (जिसे कर्नेल पोर्ट भी कहा जाता है)**:** इस पोर्ट पर भेजने के अधिकार से कार्य को नियंत्रित करना संभव है (मेमोरी पढ़ना/लिखना, थ्रेड बनाना...।)
|
||||
* कॉल करें `mach_task_self()` ताकि कॉलर कार्य के लिए इस पोर्ट का नाम प्राप्त कर सके। यह पोर्ट केवल **`exec()`** के अवसर पर विरासत में मिलता है; `fork()` के साथ नया कार्य बनाया जाता है (एक विशेष मामले के रूप में, एक कार्य को `exec()` के बाद भी एक नया कार्य पोर्ट मिलता है।) कार्य उत्पन्न करने और इसका पोर्ट प्राप्त करने का एकमात्र तरीका "पोर्ट स्वैप नृत्य" करना है जब `fork()` किया जा रहा हो।
|
||||
* इस पोर्ट तक पहुंचने की प्रतिबंधाएं (बाइनरी `AppleMobileFileIntegrity` से `macos_task_policy` से):
|
||||
* यदि ऐप के पास **`com.apple.security.get-task-allow` entitlement** है तो **एक ही उपयोगकर्ता के प्रक्रियाएँ कार्य पोर्ट तक पहुंच सकती हैं** (डीबगिंग के लिए Xcode द्वारा सामान्य रूप से जोड़ा जाता है)। **नोटराइजेशन** प्रक्रिया इसे उत्पादन रिलीज़ में नहीं देगी।
|
||||
* **`com.apple.system-task-ports`** entitlement वाली ऐप्स किसी भी प्रक्रिया के लिए **कार्य पोर्ट प्राप्त कर सकती हैं**, केवल कर्नेल को छोड़कर। पुराने संस्करणों में इसे **`task_for_pid-allow`** कहा जाता था। यह केवल Apple एप्लिकेशन्स को प्रदान किया जाता है।
|
||||
* **रूट किसी भी** हार्डन्ड **रनटाइम के साथ कंपाइल नहीं की गई** ऐप्स के कार्य पोर्ट तक पहुंच सकता है (और ना ही Apple के द्वारा)।
|
||||
|
||||
### शैलकोड इन्जेक्शन थ्रेड के माध्यम से टास्क पोर्ट में
|
||||
### शैलकोड इंजेक्शन थ्रेड के माध्यम से कार्य पोर्ट में
|
||||
|
||||
आप यहाँ से एक शैलकोड प्राप्त कर सकते हैं:
|
||||
आप एक शैलकोड प्राप्त कर सकते हैं:
|
||||
|
||||
{% content-ref url="../../macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md" %}
|
||||
[arm64-basic-assembly.md](../../macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
{% tabs %}
|
||||
{% tab title="mysleep.m" %}
|
||||
```objectivec
|
||||
// clang -framework Foundation mysleep.m -o mysleep
|
||||
// codesign --entitlements entitlements.plist -s - mysleep
|
||||
|
|
@ -405,7 +429,11 @@ return 0;
|
|||
```
|
||||
{% endtab %}
|
||||
|
||||
{% tab title="entitlements.plist" %}हक़िक़तें.plist{% endtab %}
|
||||
{% tab title="entitlements.plist" %}
|
||||
### अधिकार (Entitlements)
|
||||
|
||||
यह फ़ाइल एप्लिकेशन के लिए विशेष अधिकारों को परिभाषित करती है जो उसे उपयोग करने की अनुमति देती हैं। यह अधिकारों को सीमित करने और सुनिश्चित करने में मदद करती ह।
|
||||
{% endtab %}
|
||||
```xml
|
||||
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
|
||||
<plist version="1.0">
|
||||
|
|
@ -418,7 +446,7 @@ return 0;
|
|||
{% endtab %}
|
||||
{% endtabs %}
|
||||
|
||||
**कंपाइल** करें पिछले प्रोग्राम को और **अधिकार** जोड़ें कोड इंजेक्शन करने के लिए एक ही उपयोगकर्ता के साथ (अगर नहीं तो आपको **sudo** का उपयोग करना होगा)।
|
||||
**कंपाइल** करें पिछले प्रोग्राम को और **अधिकार** जोड़ें कोड इंजेक्शन करने के लिए एक ही उपयोगकर्ता के साथ (अगर नहीं तो आपको **sudo** का उपयोग करने की आवश्यकता होगी)।
|
||||
|
||||
<details>
|
||||
|
||||
|
|
@ -619,32 +647,7 @@ inject(pid);
|
|||
return 0;
|
||||
}
|
||||
```
|
||||
</details>
|
||||
|
||||
### macOS IPC (Inter-Process Communication)
|
||||
|
||||
#### macOS IPC Overview
|
||||
|
||||
Inter-process communication (IPC) mechanisms are commonly used in macOS to allow communication between processes. Understanding how IPC works is crucial for identifying potential security vulnerabilities and privilege escalation opportunities.
|
||||
|
||||
#### Types of macOS IPC
|
||||
|
||||
There are several types of IPC mechanisms used in macOS, including:
|
||||
|
||||
- **Mach Messages**: Low-level IPC mechanism used for communication between tasks in macOS.
|
||||
- **XPC Services**: High-level IPC mechanism that allows processes to communicate with each other securely.
|
||||
- **Distributed Objects**: IPC mechanism that enables communication between objects in different processes.
|
||||
- **Apple Events**: Mechanism used for inter-application communication in macOS.
|
||||
|
||||
#### macOS IPC Security Considerations
|
||||
|
||||
When analyzing macOS applications for security vulnerabilities, it is important to consider the security implications of IPC mechanisms. Common security issues related to IPC include:
|
||||
|
||||
- Insecure communication channels that can be intercepted by malicious actors.
|
||||
- Lack of proper authentication and authorization mechanisms.
|
||||
- Improper input validation leading to potential exploitation of IPC interfaces.
|
||||
|
||||
By understanding how IPC works and the potential security risks associated with it, security researchers can effectively assess the security posture of macOS applications.
|
||||
</details>
|
||||
```bash
|
||||
gcc -framework Foundation -framework Appkit sc_inject.m -o sc_inject
|
||||
./inject <pi or string>
|
||||
|
|
@ -655,9 +658,9 @@ macOS में **थ्रेड** को **Mach** का उपयोग क
|
|||
|
||||
एक सरल शैलकोड को इंजेक्ट करना संभव था ताकि एक कमांड को निष्पादित किया जा सके क्योंकि इसे **posix अनुरूप एपीआई के साथ काम करने की आवश्यकता नहीं थी**, केवल Mach के साथ। **अधिक जटिल इंजेक्शन** के लिए **थ्रेड** को भी **posix अनुरूप होना** चाहिए।
|
||||
|
||||
इसलिए, **थ्रेड** को सुधारने के लिए यह कहा जा सकता है कि यह **`pthread_create_from_mach_thread`** को कॉल करना चाहिए जो एक मान्य pthread बनाएगा। फिर, इस नए pthread को **dlopen** को कॉल करने के लिए एक dylib लोड करने के लिए संभव होगा, इसलिए विभिन्न क्रियाएँ करने के लिए नए शैलकोड लिखने की बजाय कस्टम लाइब्रेरीज लोड करना संभव है।
|
||||
इसलिए, **थ्रेड** को **सुधारने** के लिए यह कहा जा सकता है कि यह **`pthread_create_from_mach_thread`** को कॉल करना चाहिए जो एक मान्य pthread बनाएगा। फिर, इस नए pthread को **dlopen** को कॉल करने के लिए एक डायलिब लोड करने के लिए सिस्टम से, इसलिए नए शैलकोड लिखने की बजाय विभिन्न क्रियाएँ करने के लिए कस्टम पुस्तकालयों को लोड करना संभव है।
|
||||
|
||||
आप (उदाहरण के लिए जो एक लॉग उत्पन्न करता है और फिर आप इसे सुन सकते हैं) में **उदाहरण dylibs** पा सकते हैं:
|
||||
आप (उदाहरण के लिए जो एक लॉग उत्पन्न करता है और फिर आप इसे सुन सकते हैं) में **उदाहरण डायलिब** ढूंढ सकते हैं:
|
||||
|
||||
{% content-ref url="../macos-library-injection/macos-dyld-hijacking-and-dyld_insert_libraries.md" %}
|
||||
[macos-dyld-hijacking-and-dyld\_insert\_libraries.md](../macos-library-injection/macos-dyld-hijacking-and-dyld\_insert\_libraries.md)
|
||||
|
|
@ -884,7 +887,7 @@ return (-4);
|
|||
}
|
||||
|
||||
|
||||
// शैलकोड चलाने के लिए धागा बनाएं
|
||||
// शेलकोड चलाने के लिए धागा बनाएं
|
||||
struct arm_unified_thread_state remoteThreadState64;
|
||||
thread_act_t remoteThread;
|
||||
|
||||
|
|
@ -920,7 +923,7 @@ int main(int argc, const char * argv[])
|
|||
if (argc < 3)
|
||||
{
|
||||
fprintf (stderr, "उपयोग: %s _pid_ _क्रिया_\n", argv[0]);
|
||||
fprintf (stderr, " _क्रिया_: डिस्क पर एक dylib का पथ\n");
|
||||
fprintf (stderr, " _क्रिया_: डिस्क पर एक डायलिब का पथ\n");
|
||||
exit(0);
|
||||
}
|
||||
|
||||
|
|
@ -932,7 +935,7 @@ int rc = stat (action, &buf);
|
|||
if (rc == 0) inject(pid,action);
|
||||
else
|
||||
{
|
||||
fprintf(stderr,"Dylib नहीं मिला\n");
|
||||
fprintf(stderr,"Dylib नहीं मिली\n");
|
||||
}
|
||||
|
||||
}
|
||||
|
|
@ -944,9 +947,9 @@ fprintf(stderr,"Dylib नहीं मिला\n");
|
|||
gcc -framework Foundation -framework Appkit dylib_injector.m -o dylib_injector
|
||||
./inject <pid-of-mysleep> </path/to/lib.dylib>
|
||||
```
|
||||
### थ्रेड हाइजैकिंग के माध्यम से टास्क पोर्ट के माध्यम से <a href="#step-1-thread-hijacking" id="step-1-thread-hijacking"></a>
|
||||
### धागा हाइजैकिंग के माध्यम से टास्क पोर्ट <a href="#step-1-thread-hijacking" id="step-1-thread-hijacking"></a>
|
||||
|
||||
इस तकनीक में प्रक्रिया का एक थ्रेड हाइजैक किया जाता है:
|
||||
इस तकनीक में प्रक्रिया का एक धागा हाइजैक किया जाता है:
|
||||
|
||||
{% content-ref url="macos-thread-injection-via-task-port.md" %}
|
||||
[macos-thread-injection-via-task-port.md](macos-thread-injection-via-task-port.md)
|
||||
|
|
@ -956,9 +959,9 @@ gcc -framework Foundation -framework Appkit dylib_injector.m -o dylib_injector
|
|||
|
||||
### मौलिक जानकारी
|
||||
|
||||
XPC, जिसका मतलब है XNU (macOS द्वारा उपयोग किया जाने वाला कर्नेल) इंटर-प्रोसेस कम्युनिकेशन, macOS और iOS पर प्रक्रियाओं के बीच **संचार** के लिए एक फ्रेमवर्क है। XPC विभिन्न प्रक्रियाओं के बीच **सुरक्षित, असिंक्रोनस मेथड कॉल** करने के लिए एक तंत्र प्रदान करता है। यह Apple की सुरक्षा पैराडाइम का हिस्सा है, जो **विशेषाधिकार विभाजित अनुप्रयोगों** की सृष्टि को संभव बनाता है जहां प्रत्येक **घटक** केवल **उस अनुमतियों के साथ** चलता है जो उसके काम के लिए आवश्यक हैं, इससे किसी संक्रमित प्रक्रिया से होने वाले संभावित हानि को सीमित किया जाता है।
|
||||
XPC, जिसका मतलब है XNU (macOS द्वारा उपयोग किया जाने वाला कर्नेल) इंटर-प्रोसेस कम्युनिकेशन, macOS और iOS पर प्रक्रियाओं के बीच **संचार** के लिए एक फ्रेमवर्क है। XPC विभिन्न प्रक्रियाओं के बीच **सुरक्षित, असिंक्रोनस मेथड कॉल्स** करने के लिए एक तंत्र प्रदान करता है। यह Apple की सुरक्षा परिदृश्य का एक हिस्सा है, जो **विशेषाधिकार से अलग अनुप्रयोगों** का निर्माण संभव बनाता है जहाँ प्रत्येक **घटक** केवल उस अनुमतियों के साथ चलता है जो उसके काम को करने के लिए आवश्यक हैं, इससे किसी भी कंप्रोमाइज़ प्रक्रिया से होने वाली संभावित हानि को सीमित किया जाता है।
|
||||
|
||||
इस **संचार** काम करने के बारे में अधिक जानकारी के लिए यहाँ देखें:
|
||||
इस **संचार** काम कैसे करता है और यह **कैसे वंलरेबल** हो सकता है के बारे में अधिक जानकारी के लिए देखें:
|
||||
|
||||
{% content-ref url="macos-xpc/" %}
|
||||
[macos-xpc](macos-xpc/)
|
||||
|
|
@ -966,9 +969,9 @@ XPC, जिसका मतलब है XNU (macOS द्वारा उपय
|
|||
|
||||
## MIG - मैक इंटरफेस जेनरेटर
|
||||
|
||||
MIG को **मैक IPC** कोड निर्माण की प्रक्रिया को सरल बनाने के लिए बनाया गया था। यह इसलिए है क्योंकि आरपीसी को प्रोग्राम करने के लिए बहुत सारा काम समान क्रियाएं शामिल करता है (प्रारूपण तत्वों को पैक करना, संदेश भेजना, सर्वर में डेटा को अनपैक करना...).
|
||||
MIG को **मैक IPC** कोड निर्माण की प्रक्रिया को सरल बनाने के लिए बनाया गया था। इसलिए, RPC कार्य को कार्यान्वयन के लिए बहुत सारा काम समान क्रियाएं शामिल होती हैं (प्रारूपीकरण तत्वों को पैक करना, संदेश भेजना, सर्वर में डेटा को अनपैक करना...).
|
||||
|
||||
MIC मूल रूप से एक विशिष्ट परिभाषा (आईडीएल - इंटरफेस परिभाषा भाषा -) के साथ सर्वर और क्लाइंट को संवाद करने के लिए आवश्यक कोड उत्पन्न करता है। यद्यपि उत्पन्न कोड बेहद बुरा हो, एक डेवलपर को इसे आयात करने की आवश्यकता होगी और उसका कोड पहले की तुलना में बहुत सरल होगा।
|
||||
MIC मूल रूप से एक विशिष्ट परिभाषा (IDL -इंटरफेस परिभाषा भाषा-) के साथ सर्वर और क्लाइंट को संवाद करने के लिए आवश्यक कोड उत्पन्न करता है। यद्यपि उत्पन्न कोड बेहद बुरा हो, एक डेवलपर को इसे आयात करने की आवश्यकता होगी और उसका कोड पहले की तुलना में बहुत सरल होगा।
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
|
|
@ -983,17 +986,4 @@ MIC मूल रूप से एक विशिष्ट परिभाष
|
|||
* [https://gist.github.com/knightsc/45edfc4903a9d2fa9f5905f60b02ce5a](https://gist.github.com/knightsc/45edfc4903a9d2fa9f5905f60b02ce5a)
|
||||
* [https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/)
|
||||
* [https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/)
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>जानें AWS हैकिंग को शून्य से हीरो तक</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> के साथ!</strong></summary>
|
||||
|
||||
HackTricks का समर्थन करने के अन्य तरीके:
|
||||
|
||||
* यदि आप अपनी कंपनी का विज्ञापन **HackTricks** में देखना चाहते हैं या **HackTricks को PDF में डाउनलोड** करना चाहते हैं तो [**सब्सक्रिप्शन प्लान**](https://github.com/sponsors/carlospolop) की जांच करें!
|
||||
* [**आधिकारिक PEASS और HackTricks स्वैग**](https://peass.creator-spring.com) प्राप्त करें
|
||||
* हमारे विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) कलेक्शन, [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें
|
||||
* **शामिल हों** 💬 [**डिस्कॉर्ड समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) या हमें **ट्विटर** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** पर **फॉलो** करें।
|
||||
* **अपने हैकिंग ट्रिक्स साझा करें, PRs सबमिट करके** [**HackTricks**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github रेपो में।
|
||||
|
||||
</details>
|
||||
* [\*OS Internals, Volume I, User Mode, Jonathan Levin](https://www.amazon.com/MacOS-iOS-Internals-User-Mode/dp/099105556X)
|
||||
|
|
|
|||
|
|
@ -6,26 +6,26 @@
|
|||
|
||||
HackTricks का समर्थन करने के अन्य तरीके:
|
||||
|
||||
* यदि आप अपनी **कंपनी का विज्ञापन HackTricks में** देखना चाहते हैं या **HackTricks को PDF में डाउनलोड** करना चाहते हैं तो [**सब्सक्रिप्शन प्लान**](https://github.com/sponsors/carlospolop) देखें!
|
||||
* यदि आप अपनी कंपनी का विज्ञापन **HackTricks** में देखना चाहते हैं या **HackTricks को PDF में डाउनलोड** करना चाहते हैं तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) देखें!
|
||||
* [**आधिकारिक PEASS और HackTricks स्वैग**](https://peass.creator-spring.com) प्राप्त करें
|
||||
* हमारे विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) संग्रह, [**The PEASS Family**](https://opensea.io/collection/the-peass-family) खोजें
|
||||
* **शामिल हों** 💬 [**डिस्कॉर्ड समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) और हमें **ट्विटर** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** पर फॉलो** करें।
|
||||
* **अपने हैकिंग ट्रिक्स साझा करें** [**HackTricks**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos को PRs सबमिट करके।
|
||||
* **शामिल हों** 💬 [**डिस्कॉर्ड समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) और हमें **ट्विटर** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live) पर **फॉलो** करें।
|
||||
* **अपने हैकिंग ट्रिक्स साझा करें, PRs सबमिट करके** [**HackTricks**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos में।
|
||||
|
||||
</details>
|
||||
|
||||
## मूल जानकारी
|
||||
|
||||
MIG को **Mach IPC** कोड निर्माण की प्रक्रिया को सरल बनाने के लिए बनाया गया था। यह मौजूदा परिभाषा के साथ सर्वर और क्लाइंट के बीच संवाद के लिए आवश्यक कोड उत्पन्न करता है। यदी उत्पन्न कोड बेहद बेहद भद्दा है, तो एक डेवलपर को उसे आयात करने की आवश्यकता होगी और उसका कोड पहले की तुलना में बहुत सरल होगा।
|
||||
MIG को **Mach IPC** कोड निर्माण की प्रक्रिया को सरल बनाने के लिए बनाया गया था। यह मौजूदा परिभाषा के साथ सर्वर और क्लाइंट के बीच संवाद के लिए आवश्यक कोड उत्पन्न करता है। यदी उत्पन्न कोड बेहद बेहद भद्दा हो, तो एक डेवलपर को उसे आयात करने की आवश्यकता होगी और उसका कोड पहले की तुलना में बहुत सरल होगा।
|
||||
|
||||
परिभाषा इंटरफेस परिभाषा भाषा (IDL) में निर्दिष्ट की जाती है जिसमें `.defs` एक्सटेंशन का उपयोग किया जाता है।
|
||||
|
||||
इन परिभाषाओं में 5 खंड होते हैं:
|
||||
|
||||
* **सबसिस्टम घोषणा**: सबसिस्टम शब्द का उपयोग नाम और आईडी की घोषणा के लिए किया जाता है। इसे **`KernelServer`** के रूप में चिह्नित करना भी संभव है अगर सर्वर कर्नल में चलना चाहिए।
|
||||
* **सबसिस्टम घोषणा**: सबसिस्टम शब्द का उपयोग नाम और आईडी की घोषणा के लिए किया जाता है। इसे **`KernelServer`** के रूप में चिह्नित करना भी संभव है अगर सर्वर कर्नेल में चलाना चाहिए।
|
||||
* **समावेश और आयात**: MIG C-प्रीप्रोसेसर का उपयोग करता है, इसलिए यह आयात का उपयोग कर सकता है। इसके अतिरिक्त, उपयोगकर्ता या सर्वर उत्पन्न कोड के लिए `uimport` और `simport` का उपयोग किया जा सकता है।
|
||||
* **प्रकार की घोषणाएँ**: डेटा प्रकारों को परिभाषित करना संभव है हालांकि सामान्यत: यह `mach_types.defs` और `std_types.defs` को आयात करेगा। कस्टम वाले कुछ सिंटैक्स का उपयोग किया जा सकता है:
|
||||
* \[i`n/out]tran`: एक फ़ंक्शन जिसे आउटगोइंग संदेश से अनुवाद किया जाना चाहिए
|
||||
* \[i`n/out]tran`: एक फ़ंक्शन जिसे आउटगोइंग संदेश से या आउटगोइंग संदेश में से अनुवाद किया जाना चाहिए
|
||||
* `c[user/server]type`: दूसरे सी टाइप को मैप करना।
|
||||
* `destructor`: इस फ़ंक्शन को कॉल करें जब प्रकार रिलीज़ होता है।
|
||||
* **ऑपरेशन**: ये RPC विधियों की परिभाषाएँ हैं। यहाँ 5 विभिन्न प्रकार हैं:
|
||||
|
|
@ -56,18 +56,20 @@ n2 : uint32_t);
|
|||
```
|
||||
{% endcode %}
|
||||
|
||||
नोट करें कि पहला **आर्ग्यूमेंट बाइंड करने के लिए पोर्ट है** और MIG **स्वचालित रूप से उत्तर पोर्ट का हैंडल करेगा** (जब तक क्लाइंट कोड में `mig_get_reply_port()` को कॉल नहीं किया जा रहा है)। इसके अतिरिक्त, **ऑपरेशन्स की आईडी** क्रमांकांकित होगी जिसकी शुरुआत निर्दिष्ट सबसिस्टम आईडी से होगी (तो अगर कोई ऑपरेशन पुराना हो जाता है तो उसे हटा दिया जाता है और `skip` का उपयोग इसकी आईडी का उपयोग करने के लिए किया जाता है)।
|
||||
नोट करें कि पहला **आर्ग्यूमेंट बाइंड करने के लिए पोर्ट है** और MIG **स्वचालित रूप से उत्तर पोर्ट का हैंडल करेगा** (जब तक क्लाइंट कोड में `mig_get_reply_port()` को कॉल नहीं किया जाता है)। इसके अतिरिक्त, **ऑपरेशन्स की आईडी** क्रमांकांकित होगी जो सुचित सबसिस्टम आईडी से शुरू होगी (तो अगर कोई ऑपरेशन पुराना हो जाता है तो वह हटा दिया जाता है और `skip` का उपयोग इसकी आईडी का उपयोग करने के लिए किया जाता है)।
|
||||
|
||||
अब MIG का उपयोग करें सर्वर और क्लाइंट कोड उत्पन्न करने के लिए जो एक-दूसरे के भीतर संवाद करने में सक्षम होंगे Subtract फ़ंक्शन को कॉल करने के लिए:
|
||||
अब MIG का उपयोग करें ताकि सर्वर और क्लाइंट कोड जेनरेट किया जा सके जो एक-दूसरे के भीतर संवाद करने में सक्षम हों और Subtract फ़ंक्शन को कॉल करने के लिए:
|
||||
```bash
|
||||
mig -header myipcUser.h -sheader myipcServer.h myipc.defs
|
||||
```
|
||||
कई नए फ़ाइलें मौजूदा निर्देशिका में बनाई जाएंगी।
|
||||
|
||||
फ़ाइलों **`myipcServer.c`** और **`myipcServer.h`** में आप **`SERVERPREFmyipc_subsystem`** संरचना की घोषणा और परिभाषण पा सकते हैं, जो मैसेज आईडी पर आधारित कॉल की परिभाषा करता है (हमने 500 की शुरुआती संख्या दी है):
|
||||
{% hint style="success" %}
|
||||
आप अपने सिस्टम में एक अधिक जटिल उदाहरण ढूंढ सकते हैं: `mdfind mach_port.defs`\
|
||||
और आप इसे कंपाइल कर सकते हैं उसी फ़ोल्डर से जहां फ़ाइल है: `mig -DLIBSYSCALL_INTERFACE mach_ports.defs`
|
||||
{% endhint %}
|
||||
|
||||
{% tabs %}
|
||||
{% tab title="myipcServer.c" %}
|
||||
फ़ाइलों **`myipcServer.c`** और **`myipcServer.h`** में आपको संरचना **`SERVERPREFmyipc_subsystem`** की घोषणा और परिभाषा मिलेगी, जो मूल रूप से प्राप्त संदेश आईडी पर कॉल करने के लिए फ़ंक्शन को परिभाषित करती है (हमने 500 की शुरुआती संख्या दी है):
|
||||
```c
|
||||
/* Description of this subsystem, for use in direct RPC */
|
||||
const struct SERVERPREFmyipc_subsystem SERVERPREFmyipc_subsystem = {
|
||||
|
|
@ -85,7 +87,7 @@ myipc_server_routine,
|
|||
```
|
||||
{% endtab %}
|
||||
|
||||
{% tab title="myipcServer.h" %}सर्वर साइड आईपीसी हेडर{% endtab %}
|
||||
{% tab title="myipcServer.h" %}हमने एक नया फ़ाइल `myipcServer.h` बनाया है जिसमें हमने एक नया मेथड `myipc_server` डिफ़ाइन किया है। यह मेथड एक नया IPC विंडो क्रिएट करेगा और उसे एक नये मेसेज रिसीव करने के लिए ब्लॉक करेगा। जब एक मेसेज आता है, तो यह मेथड उसे प्रिंट करेगा और फिर उसे रिलीज कर देगा। इसके बाद, यह वापस IPC विंडो के लिए ब्लॉक हो जाएगा। यहाँ हमने एक नया IPC विंडो बनाने के लिए `mach_port_allocate` और `mach_msg` का उपयोग किया ह। इसके बाद, हमने इस IPC विंडो को रिलीज करने के लिए `mach_port_destroy` का उपयोग किया है।{% endtab %}
|
||||
```c
|
||||
/* Description of this subsystem, for use in direct RPC */
|
||||
extern const struct SERVERPREFmyipc_subsystem {
|
||||
|
|
@ -101,7 +103,7 @@ routine[1];
|
|||
{% endtab %}
|
||||
{% endtabs %}
|
||||
|
||||
पिछले स्ट्रक्टर के आधार पर **`myipc_server_routine`** फ़ंक्शन **मैसेज आईडी** प्राप्त करेगा और सही फ़ंक्शन को कॉल करने के लिए वापस लौटेगा:
|
||||
पिछले संरचना के आधार पर **`myipc_server_routine`** फ़ंक्शन **संदेश आईडी** प्राप्त करेगा और सही फ़ंक्शन को कॉल करने के लिए लौटेगा:
|
||||
```c
|
||||
mig_external mig_routine_t myipc_server_routine
|
||||
(mach_msg_header_t *InHeadP)
|
||||
|
|
@ -116,16 +118,18 @@ return 0;
|
|||
return SERVERPREFmyipc_subsystem.routine[msgh_id].stub_routine;
|
||||
}
|
||||
```
|
||||
इस उदाहरण में हमने परिभाषणों में केवल 1 फ़ंक्शन परिभाषित किया है, लेकिन अगर हम अधिक फ़ंक्शन परिभाषित करते, तो वे **`SERVERPREFmyipc_subsystem`** के एरे के अंदर होते और पहला फ़ंक्शन **500** आईडी को सौंपा जाता, दूसरा **501** आईडी को...
|
||||
इस उदाहरण में हमने परिभाषणों में केवल 1 फ़ंक्शन को परिभाषित किया है, लेकिन अगर हमने अधिक फ़ंक्शनों को परिभाषित किया होता, तो वे **`SERVERPREFmyipc_subsystem`** के एरे के अंदर होते और पहला फ़ंक्शन **500** आईडी को असाइन किया जाता, दूसरा **501** आईडी को...
|
||||
|
||||
वास्तव में इस संरचना **`myipcServer.h`** में से **`subsystem_to_name_map_myipc`** में इस संबंध की पहचान करना संभव है:
|
||||
अगर फ़ंक्शन से एक **जवाब** भेजने की उम्मीद थी तो फ़ंक्शन `mig_internal kern_return_t __MIG_check__Reply__<नाम>` भी मौजूद होता।
|
||||
|
||||
वास्तव में इस संरचना को पहचानना संभव है **`myipcServer.h`** में संरचना **`subsystem_to_name_map_myipc`** में (**अन्य फ़ाइलों में **`subsystem_to_name_map_***`**):
|
||||
```c
|
||||
#ifndef subsystem_to_name_map_myipc
|
||||
#define subsystem_to_name_map_myipc \
|
||||
{ "Subtract", 500 }
|
||||
#endif
|
||||
```
|
||||
अंत में, सर्वर काम करने के लिए एक और महत्वपूर्ण फ़ंक्शन **`myipc_server`** होगा, जो वास्तव में प्राप्त आईडी से संबंधित **फ़ंक्शन को कॉल करेगा**:
|
||||
अंत में, सर्वर काम करने के लिए एक और महत्वपूर्ण फ़ंक्शन **`myipc_server`** होगा, जो वास्तव में प्राप्त आईडी के संबंधित फ़ंक्शन को **कॉल** करेगा:
|
||||
|
||||
<pre class="language-c"><code class="lang-c">mig_external boolean_t myipc_server
|
||||
(mach_msg_header_t *InHeadP, mach_msg_header_t *OutHeadP)
|
||||
|
|
@ -161,7 +165,7 @@ return FALSE;
|
|||
|
||||
पिछले हाइलाइट किए गए लाइनों की जांच करें जो आईडी द्वारा कॉल करने के लिए फ़ंक्शन तक पहुंचती हैं।
|
||||
|
||||
निम्नलिखित में एक सरल **सर्वर** और **क्लाइंट** बनाने के लिए कोड है जहां क्लाइंट सर्वर से फ़ंक्शन Subtract को कॉल कर सकता है:
|
||||
निम्नलिखित कोड एक सरल **सर्वर** और **क्लाइंट** बनाने के लिए है जहां क्लाइंट सर्वर से घटाने वाले फ़ंक्शन को कॉल कर सकता है:
|
||||
|
||||
{% tabs %}
|
||||
{% tab title="myipc_server.c" %}
|
||||
|
|
@ -222,44 +226,65 @@ printf("Port right name %d\n", port);
|
|||
USERPREFSubtract(port, 40, 2);
|
||||
}
|
||||
```
|
||||
### बाइनरी विश्लेषण
|
||||
{% endtab %}
|
||||
{% endtabs %}
|
||||
|
||||
जैसे कि कई बाइनरी अब MIG का उपयोग मैक पोर्ट्स को उजागर करने के लिए करते हैं, इसे पहचानना और प्रत्येक संदेश आईडी के साथ MIG द्वारा कार्यान्वित किए जाने वाले **कार्यों को पहचानना** दिलचस्प है।
|
||||
### NDR\_record
|
||||
|
||||
[**jtool2**](../../macos-apps-inspecting-debugging-and-fuzzing/#jtool2) एक Mach-O बाइनरी से MIG सूचना का विश्लेषण कर सकता है जिससे संदेश आईडी का पता चलता है और कार्य को क्रियान्वित करने के लिए पहचानता है:
|
||||
NDR\_record को `libsystem_kernel.dylib` द्वारा निर्यात किया गया है, और यह एक संरचना है जो MIG को **डेटा को परिवर्तित करने की अनुमति देती है ताकि यह उस सिस्टम के प्रति निर्विकार हो जिसमें इसका उपयोग किया जा रहा है** क्योंकि MIG का उपयोग विभिन्न सिस्टमों के बीच किया जाने के लिए सोचा गया था (और केवल एक ही मशीन में नहीं).
|
||||
|
||||
यह दिलचस्प है क्योंकि यदि `_NDR_record` एक डिपेंडेंसी के रूप में किसी बाइनरी में पाया जाता है (`jtool2 -S <binary> | grep NDR` या `nm`), तो इसका मतलब है कि बाइनरी एक MIG client या Server है।
|
||||
|
||||
इसके अतिरिक्त **MIG सर्वर** के पास `__DATA.__const` में डिस्पैच टेबल होता है (या macOS कर्नेल में `__CONST.__constdata` में और अन्य \*OS कर्नेल में `__DATA_CONST.__const` में). इसे **`jtool2`** के साथ डंप किया जा सकता है।
|
||||
|
||||
और **MIG clients** `__mach_msg` के साथ भेजने के लिए `__NDR_record` का उपयोग करेंगे।
|
||||
|
||||
## बाइनरी विश्लेषण
|
||||
|
||||
### jtool
|
||||
|
||||
जैसे कि कई बाइनरी अब MIG का उपयोग मच पोर्ट्स को उजागर करने के लिए करते हैं, इसे पहचानना और प्रत्येक संदेश आईडी के साथ MIG द्वारा कार्यान्वित किए जाने वाले **कार्यों को पहचानना** दिलचस्प है।
|
||||
|
||||
[**jtool2**](../../macos-apps-inspecting-debugging-and-fuzzing/#jtool2) एक Mach-O बाइनरी से MIG जानकारी को पार्स कर सकता है जिसमें संदेश आईडी को निर्दिष्ट करता है और कार्य को क्रियान्वित करने के लिए पहचानता है:
|
||||
```bash
|
||||
jtool2 -d __DATA.__const myipc_server | grep MIG
|
||||
```
|
||||
यह पहले से ही उल्लेख किया गया था कि **प्राप्त संदेश आईडी के आधार पर सही फ़ंक्शन को बुलाने का कार्य संभालेगा** वह `myipc_server` था। हालांकि, आम तौर पर बाइनरी के प्रतीक नहीं होते (कोई फ़ंक्शन नाम नहीं), इसलिए यह देकना दिलचस्प है कि **डीकंपाइल कैसे दिखता है** क्योंकि यह हमेशा बहुत समान होगा (इस फ़ंक्शन का कोड फ़ंक्शनों से अलग है):
|
||||
इसके अतिरिक्त, MIG functions केवल उस वास्तविक फ़ंक्शन के wrappers होते हैं जो कॉल किया जाता है, जिसका मतलब है कि उसके disassembly प्राप्त करने और BL के लिए grepping करने से आप वास्तविक फ़ंक्शन को खोजने में सक्षम हो सकते हैं:
|
||||
```bash
|
||||
jtool2 -d __DATA.__const myipc_server | grep BL
|
||||
```
|
||||
### असेम्बली
|
||||
|
||||
पहले ही उल्लेख किया गया था कि **प्राप्त संदेश आईडी के आधार पर सही फ़ंक्शन को बुलाने का कार्य संभालेगा** वह `myipc_server` था। हालांकि, आम तौर पर बाइनरी के प्रतीक (कोई फ़ंक्शन नाम नहीं) नहीं होते, इसलिए यह देकना दिलचस्प होता है कि **डीकंपाइल कैसे दिखता है** क्योंकि यह हमेशा बहुत समान होगा (इस फ़ंक्शन का कोड फ़ंक्शनों से अलग है):
|
||||
|
||||
{% tabs %}
|
||||
{% tab title="मेरा आईपीसी सर्वर डीकंपाइल 1" %}
|
||||
<pre class="language-c"><code class="lang-c">int _myipc_server(int arg0, int arg1) {
|
||||
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 में उस कॉल का पॉइंटर स्टोर करता है जिसे कॉल किया जाना चाहिए
|
||||
// इस फ़ंक्शन को पहचानने में मदद कर सकता है
|
||||
// यह rax में उस कॉल पॉइंटर को स्टोर करता है जिसे बुलाया जाना चाहिए
|
||||
// पता करें कि पता 0x100004040 (फ़ंक्शन पतों का एरे) का उपयोग किया गया है
|
||||
// 0x1f4 = 500 (प्रारंभिक आईडी)
|
||||
<strong> rax = *(sign_extend_64(rax - 0x1f4) * 0x28 + 0x100004040);
|
||||
</strong> var_20 = rax;
|
||||
// अगर - अन्यथा, अगर फॉल्स लौटता है, जबकि अन्यथा सही फ़ंक्शन को कॉल करता है और सच लौटता है
|
||||
// अगर - अन्यथा, अगर फॉल्स लौटता है, जबकि अन्यथा सही फ़ंक्शन को बुलाता है और सच लौटता है
|
||||
<strong> if (rax == 0x0) {
|
||||
</strong> *(var_18 + 0x18) = **_NDR_record;
|
||||
*(int32_t *)(var_18 + 0x20) = 0xfffffffffffffed1;
|
||||
var_4 = 0x0;
|
||||
}
|
||||
else {
|
||||
// 2 तर्कों के साथ सही फ़ंक्शन को कॉल करने वाला गणना किया गया पता
|
||||
// 2 तर्कों के साथ सही फ़ंक्शन को बुलाने वाला गणना किया गया पता
|
||||
<strong> (var_20)(var_10, var_18);
|
||||
</strong> var_4 = 0x1;
|
||||
}
|
||||
|
|
@ -284,8 +309,8 @@ saved_fp = r29;
|
|||
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;
|
||||
|
|
@ -294,19 +319,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 (प्रारंभिक आईडी)
|
||||
<strong> r8 = r8 - 0x1f4;
|
||||
|
|
@ -315,19 +340,18 @@ r8 = *(r8 + 0x8);
|
|||
var_20 = r8;
|
||||
r8 = r8 - 0x0;
|
||||
if (r8 != 0x0) {
|
||||
if (CPU_FLAGS & NE) {
|
||||
if (CPU_FLAGS & NE) {
|
||||
r8 = 0x1;
|
||||
}
|
||||
}
|
||||
// पिछले संस्करण की तरह समान अगर नहीं तो अगर वापस लौटता है, जबकि अन्यथा सही फ़ंक्शन को कॉल करता है और सच लौटता है
|
||||
// पता करें कि पता 0x100004040 (फ़ंक्शन पतों का एरे) का उपयोग किया गया है
|
||||
<strong> if ((r8 & 0x1) == 0x0) {
|
||||
// पिछले संस्करण की तरह समान अगर नहीं तो अगर वापस लौटता है, जबकि अन्यथा सही फ़ंक्शन को बुलाता है और सच लौटता है
|
||||
<strong> if ((r8 & 0x1) == 0x0) {
|
||||
</strong><strong> *(var_18 + 0x18) = **0x100004000;
|
||||
</strong> *(int32_t *)(var_18 + 0x20) = 0xfffffed1;
|
||||
var_4 = 0x0;
|
||||
}
|
||||
else {
|
||||
// फ़ंक्शन होना चाहिए उस पते पर कॉल करने के लिए गणना का कॉल
|
||||
// गणना किए गए पते को बुलाने वाले स्थान पर कॉल
|
||||
<strong> (var_20)(var_10, var_18);
|
||||
</strong> var_4 = 0x1;
|
||||
}
|
||||
|
|
@ -351,7 +375,31 @@ return r0;
|
|||
{% endtab %}
|
||||
{% endtabs %}
|
||||
|
||||
वास्तव में अगर आप **`0x100004000`** फ़ंक्शन पर जाते हैं तो आपको **`routine_descriptor`** संरचनाओं का एरे मिलेगा। संरचना का पहला तत्व वहाँ **फ़ंक्शन का अंतर्निहित किया गया पता** है, और **संरचना 0x28 बाइट लेती है**, इसलिए प्रत्येक 0x28 बाइट (बाइट 0 से प्रारंभ होकर) आप 8 बाइट प्राप्त कर सकते हैं और वह **फ़ंक्शन का पता** होगा जो कॉल किया जाएगा:
|
||||
* **अपनी हैकिंग ट्रिक्स साझा करें PR जमा करके** [**HackTricks**](https://github.com/carlospolop/hacktricks) **और** [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) **github repos पर।**
|
||||
वास्तव में अगर आप **`0x100004000`** फ़ंक्शन पर जाते हैं तो आपको **`routine_descriptor`** संरचना का एरे मिलेगा। संरचना का पहला तत्व वहाँ **फ़ंक्शन** का कार्यान्वयन किया गया है, और **संरचना 0x28 बाइट लेती है**, इसलिए प्रत्येक 0x28 बाइट (बाइट 0 से प्रारंभ होकर) आप 8 बाइट प्राप्त कर सकते हैं और वह **फ़ंक्शन का पता** होगा जो बुलाया जाएगा:
|
||||
|
||||
<figure><img src="../../../../.gitbook/assets/image (35).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
<figure><img src="../../../../.gitbook/assets/image (36).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
यह डेटा [**इस Hopper स्क्रिप्ट का उपयोग करके**](https://github.com/knightsc/hopper/blob/master/scripts/MIG%20Detect.py) निकाला जा सकता है।
|
||||
### डीबग
|
||||
|
||||
MIG द्वारा उत्पन्न कोड भी `kernel_debug` को कॉल करता है ताकि प्रवेश और निकासी पर ऑपरेशन के बारे में लॉग उत्पन्न किया जा सके। इन्हें **`trace`** या **`kdv`** का उपयोग करके जांचना संभव है: `kdv all | grep MIG`
|
||||
|
||||
## संदर्भ
|
||||
|
||||
* [\*OS Internals, Volume I, User Mode, Jonathan Levin](https://www.amazon.com/MacOS-iOS-Internals-User-Mode/dp/099105556X)
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>जीरो से हीरो तक AWS हैकिंग सीखें</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
HackTricks का समर्थन करने के अन्य तरीके:
|
||||
|
||||
* यदि आप अपनी कंपनी का **विज्ञापन HackTricks में देखना चाहते हैं** या **HackTricks को PDF में डाउनलोड करना चाहते हैं** तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) की जांच करें!
|
||||
* [**आधिकारिक PEASS & HackTricks स्वैग**](https://peass.creator-spring.com) प्राप्त करें
|
||||
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) संग्रह
|
||||
* **शामिल हों** 💬 [**डिस्कॉर्ड समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) या हमें **ट्विटर** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** पर फॉलो** करें।
|
||||
* **हैकिंग ट्रिक्स साझा करें** द्वारा **पीआर जमा करके** [**HackTricks**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github रेपो में।
|
||||
|
||||
</details>
|
||||
|
|
|
|||
Loading…
Reference in a new issue