mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/macos-hardening/macos-security-and-privilege-escalation
This commit is contained in:
Translator
parent
7a11c655a7
commit
2c4b3975b2
@ -61,6 +61,7 @@
|
||||
- [Deofuscation vbs (cscript.exe)](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/desofuscation-vbs-cscript.exe.md)
|
||||
- [Discord Cache Forensics](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/discord-cache-forensics.md)
|
||||
- [Local Cloud Storage](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/local-cloud-storage.md)
|
||||
- [Mach O Entitlements And Ipsw Indexing](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/mach-o-entitlements-and-ipsw-indexing.md)
|
||||
- [Office file analysis](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/office-file-analysis.md)
|
||||
- [PDF File analysis](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/pdf-file-analysis.md)
|
||||
- [PNG tricks](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/png-tricks.md)
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
# विशिष्ट सॉफ़्टवेयर/फ़ाइल प्रकार युक्तियाँ
|
||||
# विशिष्ट सॉफ़्टवेयर/फ़ाइल प्रकार ट्रिक्स
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
यहाँ आप विशिष्ट फ़ाइल-प्रकार और/या सॉफ़्टवेयर के लिए रोचक ट्रिक्स पा सकते हैं:
|
||||
यहाँ आप विशिष्ट फ़ाइल-प्रकार और/या सॉफ़्टवेयर के लिए दिलचस्प ट्रिक्स पा सकते हैं:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -54,4 +54,9 @@ video-and-audio-file-analysis.md
|
||||
zips-tricks.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
{{#ref}}
|
||||
mach-o-entitlements-and-ipsw-indexing.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -0,0 +1,213 @@
|
||||
# Mach-O Entitlements Extraction & IPSW Indexing
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## अवलोकन
|
||||
|
||||
यह पृष्ठ बताता है कि कैसे Mach-O बाइनरी से प्रोग्रामेटिक रूप से entitlements निकाले जाएं by walking LC_CODE_SIGNATURE और code signing SuperBlob को parse करके, और कैसे इसे Apple IPSW firmwares पर स्केल किया जाए उनके contents को mount और index करके forensic search/diff के लिए।
|
||||
|
||||
यदि आपको Mach-O फॉर्मैट और code signing पर refresher चाहिए, तो नीचे देखें:
|
||||
- macOS code signing विवरण (SuperBlob, Code Directory, special slots) देखें: [macOS Code Signing](../../../macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-code-signing.md)
|
||||
- सामान्य Mach-O संरचनाएं/load commands देखें: [Universal binaries & Mach-O Format](../../../macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/universal-binaries-and-mach-o-format.md)
|
||||
|
||||
|
||||
## Mach-O में Entitlements: वे कहाँ होते हैं
|
||||
|
||||
Entitlements code signature data के अंदर संग्रहीत होते हैं जो LC_CODE_SIGNATURE load command द्वारा संदर्भित होते हैं और __LINKEDIT segment में रखे जाते हैं। Signature एक CS_SuperBlob है जिसमें कई blobs होते हैं (code directory, requirements, entitlements, CMS, आदि)। Entitlements blob एक CS_GenericBlob है जिसका data एक Apple Binary Property List (bplist00) है जो entitlement keys को values से map करता है।
|
||||
|
||||
मुख्य संरचनाएँ (xnu से):
|
||||
```c
|
||||
/* mach-o/loader.h */
|
||||
struct mach_header_64 {
|
||||
uint32_t magic;
|
||||
cpu_type_t cputype;
|
||||
cpu_subtype_t cpusubtype;
|
||||
uint32_t filetype;
|
||||
uint32_t ncmds;
|
||||
uint32_t sizeofcmds;
|
||||
uint32_t flags;
|
||||
uint32_t reserved;
|
||||
};
|
||||
|
||||
struct load_command {
|
||||
uint32_t cmd;
|
||||
uint32_t cmdsize;
|
||||
};
|
||||
|
||||
/* Entitlements live behind LC_CODE_SIGNATURE (cmd=0x1d) */
|
||||
struct linkedit_data_command {
|
||||
uint32_t cmd; /* LC_CODE_SIGNATURE */
|
||||
uint32_t cmdsize; /* sizeof(struct linkedit_data_command) */
|
||||
uint32_t dataoff; /* file offset of data in __LINKEDIT */
|
||||
uint32_t datasize; /* file size of data in __LINKEDIT */
|
||||
};
|
||||
|
||||
/* osfmk/kern/cs_blobs.h */
|
||||
typedef struct __SC_SuperBlob {
|
||||
uint32_t magic; /* CSMAGIC_EMBEDDED_SIGNATURE = 0xfade0cc0 */
|
||||
uint32_t length;
|
||||
uint32_t count;
|
||||
CS_BlobIndex index[];
|
||||
} CS_SuperBlob;
|
||||
|
||||
typedef struct __BlobIndex {
|
||||
uint32_t type; /* e.g., CSMAGIC_EMBEDDED_ENTITLEMENTS = 0xfade7171 */
|
||||
uint32_t offset; /* offset of entry */
|
||||
} CS_BlobIndex;
|
||||
|
||||
typedef struct __SC_GenericBlob {
|
||||
uint32_t magic; /* same as type when standalone */
|
||||
uint32_t length;
|
||||
char data[]; /* Apple Binary Plist containing entitlements */
|
||||
} CS_GenericBlob;
|
||||
```
|
||||
महत्वपूर्ण स्थिरांक:
|
||||
- LC_CODE_SIGNATURE cmd = 0x1d
|
||||
- CS SuperBlob magic = 0xfade0cc0
|
||||
- Entitlements blob type (CSMAGIC_EMBEDDED_ENTITLEMENTS) = 0xfade7171
|
||||
- DER entitlements may be present via special slot (e.g., -7), see the macOS Code Signing page for special slots and DER entitlements notes
|
||||
|
||||
नोट: Multi-arch (fat) binaries में एक से अधिक Mach-O slices होते हैं। आपको उस आर्किटेक्चर के लिए उपयुक्त slice चुनना होगा जिसे आप निरीक्षण करना चाहते हैं और फिर उसके load commands को वॉक करना होगा।
|
||||
|
||||
|
||||
## निष्कर्षण चरण (सामान्य, पर्याप्त हानि-रहित)
|
||||
|
||||
1) Mach-O header पार्स करें; ncmds जितने load_command रिकॉर्ड्स पर iterate करें।
|
||||
2) LC_CODE_SIGNATURE खोजें; linkedit_data_command.dataoff/datasize पढ़कर __LINKEDIT में रखे Code Signing SuperBlob को मैप करें।
|
||||
3) CS_SuperBlob.magic == 0xfade0cc0 मान्य करें; CS_BlobIndex की count प्रविष्टियों पर iterate करें।
|
||||
4) index.type == 0xfade7171 (embedded entitlements) वाले एंट्री को खोजें। उस द्वारा संकेतित CS_GenericBlob पढ़ें और उसके डेटा को Apple binary plist (bplist00) के रूप में पार्स करके key/value entitlements निकालें।
|
||||
|
||||
कार्यान्वयन नोट्स:
|
||||
- Code signature संरचनाएँ big-endian फील्ड्स का उपयोग करती हैं; little-endian होस्ट पर पार्स करते समय byte order swap करें।
|
||||
- Entitlements GenericBlob का डेटा स्वयं एक binary plist है (मानक plist लाइब्रेरीज़ द्वारा संभाला जाता है)।
|
||||
- कुछ iOS बाइनरीज़ में DER entitlements हो सकते हैं; साथ ही कुछ stores/slots प्लेटफ़ॉर्म/वर्शन के अनुसार अलग होते हैं। आवश्यकता अनुसार standard और DER entitlements दोनों को क्रॉस-चेक करें।
|
||||
- fat बाइनरीज़ के लिए, Mach-O load commands पर जाएँ उससे पहले सही slice और offset ढूँढने हेतु fat headers (FAT_MAGIC/FAT_MAGIC_64) का उपयोग करें।
|
||||
|
||||
|
||||
## न्यूनतम पार्सिंग रूपरेखा (Python)
|
||||
|
||||
निम्न एक संक्षिप्त रूपरेखा है जो entitlements खोजने और डिकोड करने के नियंत्रण प्रवाह को दिखाती है। संक्षिप्तता के लिए इसमें जानबूझकर सख्त bounds checks और पूर्ण fat binary समर्थन शामिल नहीं किया गया है।
|
||||
```python
|
||||
import plistlib, struct
|
||||
|
||||
LC_CODE_SIGNATURE = 0x1d
|
||||
CSMAGIC_EMBEDDED_SIGNATURE = 0xfade0cc0
|
||||
CSMAGIC_EMBEDDED_ENTITLEMENTS = 0xfade7171
|
||||
|
||||
# all code-signing integers are big-endian per cs_blobs.h
|
||||
be32 = lambda b, off: struct.unpack_from(">I", b, off)[0]
|
||||
|
||||
def parse_entitlements(macho_bytes):
|
||||
# assume already positioned at a single-arch Mach-O slice
|
||||
magic, = struct.unpack_from("<I", macho_bytes, 0)
|
||||
is64 = magic in (0xfeedfacf,)
|
||||
if is64:
|
||||
ncmds = struct.unpack_from("<I", macho_bytes, 0x10)[0]
|
||||
sizeofcmds = struct.unpack_from("<I", macho_bytes, 0x14)[0]
|
||||
off = 0x20
|
||||
else:
|
||||
# 32-bit not shown
|
||||
return None
|
||||
|
||||
code_sig_off = code_sig_size = None
|
||||
for _ in range(ncmds):
|
||||
cmd, cmdsize = struct.unpack_from("<II", macho_bytes, off)
|
||||
if cmd == LC_CODE_SIGNATURE:
|
||||
# struct linkedit_data_command is little-endian in file
|
||||
_, _, dataoff, datasize = struct.unpack_from("<IIII", macho_bytes, off)
|
||||
code_sig_off, code_sig_size = dataoff, datasize
|
||||
off += cmdsize
|
||||
|
||||
if code_sig_off is None:
|
||||
return None
|
||||
|
||||
blob = macho_bytes[code_sig_off: code_sig_off + code_sig_size]
|
||||
if be32(blob, 0x0) != CSMAGIC_EMBEDDED_SIGNATURE:
|
||||
return None
|
||||
|
||||
count = be32(blob, 0x8)
|
||||
# iterate BlobIndex entries (8 bytes each after 12-byte header)
|
||||
for i in range(count):
|
||||
idx_off = 12 + i*8
|
||||
btype = be32(blob, idx_off)
|
||||
boff = be32(blob, idx_off+4)
|
||||
if btype == CSMAGIC_EMBEDDED_ENTITLEMENTS:
|
||||
# GenericBlob is big-endian header followed by bplist
|
||||
glen = be32(blob, boff+4)
|
||||
data = blob[boff+8: boff+glen]
|
||||
return plistlib.loads(data)
|
||||
return None
|
||||
```
|
||||
Usage tips:
|
||||
- fat binaries को संभालने के लिए, पहले struct fat_header/fat_arch पढ़ें, इच्छित architecture slice चुनें, फिर subrange को parse_entitlements में पास करें।
|
||||
- macOS पर आप परिणामों को निम्न से मान्य कर सकते हैं: codesign -d --entitlements :- /path/to/binary
|
||||
|
||||
|
||||
## उदाहरण निष्कर्ष
|
||||
|
||||
Privileged platform binaries अक्सर निम्न संवेदनशील entitlements का अनुरोध करते हैं:
|
||||
- com.apple.security.network.server = true
|
||||
- com.apple.rootless.storage.early_boot_mount = true
|
||||
- com.apple.private.kernel.system-override = true
|
||||
- com.apple.private.pmap.load-trust-cache = ["cryptex1.boot.os", "cryptex1.boot.app", "cryptex1.safari-downlevel"]
|
||||
|
||||
इनें firmware images में बड़े पैमाने पर खोजना releases/devices के बीच attack surface mapping और diffing के लिए अत्यंत उपयोगी है।
|
||||
|
||||
|
||||
## IPSWs पर स्केलिंग (mounting और indexing)
|
||||
|
||||
पूर्ण images को स्टोर किए बिना बड़े पैमाने पर executables को enumerate करके entitlements निकालने के लिए:
|
||||
|
||||
- @blacktop द्वारा बनाए गए ipsw tool का उपयोग करके firmware filesystems को डाउनलोड और mount करें। Mounting apfs-fuse का उपयोग करता है, इसलिए आप बिना पूर्ण extraction के APFS volumes को traverse कर सकते हैं।
|
||||
```bash
|
||||
# Download latest IPSW for iPhone11,2 (iPhone XS)
|
||||
ipsw download ipsw -y --device iPhone11,2 --latest
|
||||
|
||||
# Mount IPSW filesystem (uses underlying apfs-fuse)
|
||||
ipsw mount fs <IPSW_FILE>
|
||||
```
|
||||
- Mounted volumes को स्कैन करके Mach-O files ढूंढें (check magic and/or use file/otool), फिर entitlements और imported frameworks पार्स करें।
|
||||
- हजारों IPSWs में रेखीय वृद्धि से बचने के लिए एक normalized view को relational database में persist करें:
|
||||
- executables, operating_system_versions, entitlements, frameworks
|
||||
- many-to-many: executable↔OS version, executable↔entitlement, executable↔framework
|
||||
|
||||
उदाहरण क्वेरी: किसी दिए गए executable नाम को शामिल करने वाले सभी OS versions सूचीबद्ध करने के लिए:
|
||||
```sql
|
||||
SELECT osv.version AS "Versions"
|
||||
FROM device d
|
||||
LEFT JOIN operating_system_version osv ON osv.device_id = d.id
|
||||
LEFT JOIN executable_operating_system_version eosv ON eosv.operating_system_version_id = osv.id
|
||||
LEFT JOIN executable e ON e.id = eosv.executable_id
|
||||
WHERE e.name = "launchd";
|
||||
```
|
||||
Notes on DB portability (if you implement your own indexer):
|
||||
- Use an ORM/abstraction (e.g., SeaORM) to keep code DB-agnostic (SQLite/PostgreSQL).
|
||||
- SQLite requires AUTOINCREMENT only on an INTEGER PRIMARY KEY; if you want i64 PKs in Rust, generate entities as i32 and convert types, SQLite stores INTEGER as 8-byte signed internally.
|
||||
|
||||
|
||||
## entitlement hunting के लिए ओपन-सोर्स टूलिंग और संदर्भ
|
||||
|
||||
- Firmware माउंट/डाउनलोड: https://github.com/blacktop/ipsw
|
||||
- Entitlement डेटाबेस और संदर्भ:
|
||||
- Jonathan Levin का entitlement DB: https://newosxbook.com/ent.php
|
||||
- entdb: https://github.com/ChiChou/entdb
|
||||
- Large-scale indexer (Rust, self-hosted Web UI + OpenAPI): https://github.com/synacktiv/appledb_rs
|
||||
- Apple headers for structures and constants:
|
||||
- loader.h (Mach-O headers, load commands)
|
||||
- cs_blobs.h (SuperBlob, GenericBlob, CodeDirectory)
|
||||
|
||||
Code signing के अंदरूनी विवरण (Code Directory, special slots, DER entitlements) के बारे में अधिक जानकारी के लिए देखें: [macOS Code Signing](../../../macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-code-signing.md)
|
||||
|
||||
|
||||
## संदर्भ
|
||||
|
||||
- [appledb_rs: a research support tool for Apple platforms](https://www.synacktiv.com/publications/appledbrs-un-outil-daide-a-la-recherche-sur-plateformes-apple.html)
|
||||
- [synacktiv/appledb_rs](https://github.com/synacktiv/appledb_rs)
|
||||
- [blacktop/ipsw](https://github.com/blacktop/ipsw)
|
||||
- [Jonathan Levin’s entitlement DB](https://newosxbook.com/ent.php)
|
||||
- [ChiChou/entdb](https://github.com/ChiChou/entdb)
|
||||
- [XNU cs_blobs.h](https://github.com/apple-oss-distributions/xnu/blob/main/osfmk/kern/cs_blobs.h)
|
||||
- [XNU mach-o/loader.h](https://github.com/apple-oss-distributions/xnu/blob/main/EXTERNAL_HEADERS/mach-o/loader.h)
|
||||
- [SQLite Datatypes](https://sqlite.org/datatype3.html)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@ -1,61 +1,61 @@
|
||||
# macOS यूनिवर्सल बाइनरी और Mach-O प्रारूप
|
||||
# macOS यूनिवर्सल बायनरी और Mach-O फॉर्मेट
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## बुनियादी जानकारी
|
||||
|
||||
Mac OS बाइनरी आमतौर पर **यूनिवर्सल बाइनरी** के रूप में संकलित होती हैं। एक **यूनिवर्सल बाइनरी** **एक ही फ़ाइल में कई आर्किटेक्चर का समर्थन कर सकती है**।
|
||||
Mac OS के बायनरी आमतौर पर **यूनिवर्सल बायनरी** के रूप में कम्पाइल होते हैं। एक **यूनिवर्सल बायनरी** एक ही फ़ाइल में **कई आर्किटेक्चर का समर्थन कर सकती है**।
|
||||
|
||||
ये बाइनरी **Mach-O संरचना** का पालन करती हैं जो मूल रूप से निम्नलिखित से बनी होती है:
|
||||
ये बायनरी **Mach-O संरचना** का पालन करते हैं, जो मूल रूप से निम्न हिस्सों से मिलकर बनती है:
|
||||
|
||||
- हेडर
|
||||
- लोड कमांड
|
||||
- लोड कमांड्स
|
||||
- डेटा
|
||||
|
||||
.png>)
|
||||
|
||||
## फैट हेडर
|
||||
|
||||
फ़ाइल के लिए खोजें: `mdfind fat.h | grep -i mach-o | grep -E "fat.h$"`
|
||||
फाइल खोजने के लिए उपयोग करें: `mdfind fat.h | grep -i mach-o | grep -E "fat.h$"`
|
||||
|
||||
<pre class="language-c"><code class="lang-c"><strong>#define FAT_MAGIC 0xcafebabe
|
||||
</strong><strong>#define FAT_CIGAM 0xbebafeca /* NXSwapLong(FAT_MAGIC) */
|
||||
</strong>
|
||||
struct fat_header {
|
||||
<strong> uint32_t magic; /* FAT_MAGIC या FAT_MAGIC_64 */
|
||||
</strong><strong> uint32_t nfat_arch; /* उसके बाद आने वाले संरचनाओं की संख्या */
|
||||
<strong> uint32_t magic; /* FAT_MAGIC or FAT_MAGIC_64 */
|
||||
</strong><strong> uint32_t nfat_arch; /* number of structs that follow */
|
||||
</strong>};
|
||||
|
||||
struct fat_arch {
|
||||
cpu_type_t cputype; /* cpu निर्दिष्ट करने वाला (int) */
|
||||
cpu_subtype_t cpusubtype; /* मशीन निर्दिष्ट करने वाला (int) */
|
||||
uint32_t offset; /* इस ऑब्जेक्ट फ़ाइल के लिए फ़ाइल ऑफ़सेट */
|
||||
uint32_t size; /* इस ऑब्जेक्ट फ़ाइल का आकार */
|
||||
uint32_t align; /* 2 की शक्ति के रूप में संरेखण */
|
||||
cpu_type_t cputype; /* cpu specifier (int) */
|
||||
cpu_subtype_t cpusubtype; /* machine specifier (int) */
|
||||
uint32_t offset; /* file offset to this object file */
|
||||
uint32_t size; /* size of this object file */
|
||||
uint32_t align; /* alignment as a power of 2 */
|
||||
};
|
||||
</code></pre>
|
||||
|
||||
हेडर में **जादुई** बाइट्स होते हैं जिनके बाद फ़ाइल में **आर्क्स** की **संख्या** होती है (`nfat_arch`) और प्रत्येक आर्क में एक `fat_arch` संरचना होगी।
|
||||
हेडर में **magic** बाइट्स होती हैं, उसके बाद फ़ाइल में मौजूद **archs** की **संख्या** (`nfat_arch`) होती है और हर arch के लिए एक `fat_arch` struct होगा।
|
||||
|
||||
इसे जांचें:
|
||||
इसे जाँचें:
|
||||
|
||||
<pre class="language-shell-session"><code class="lang-shell-session">% file /bin/ls
|
||||
/bin/ls: Mach-O यूनिवर्सल बाइनरी जिसमें 2 आर्किटेक्चर हैं: [x86_64:Mach-O 64-बिट निष्पादन योग्य x86_64] [arm64e:Mach-O 64-बिट निष्पादन योग्य arm64e]
|
||||
/bin/ls (आर्किटेक्चर x86_64 के लिए): Mach-O 64-बिट निष्पादन योग्य x86_64
|
||||
/bin/ls (आर्किटेक्चर arm64e के लिए): Mach-O 64-बिट निष्पादन योग्य arm64e
|
||||
/bin/ls: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
|
||||
/bin/ls (for architecture x86_64): Mach-O 64-bit executable x86_64
|
||||
/bin/ls (for architecture arm64e): Mach-O 64-bit executable arm64e
|
||||
|
||||
% otool -f -v /bin/ls
|
||||
फैट हेडर्स
|
||||
Fat headers
|
||||
fat_magic FAT_MAGIC
|
||||
<strong>nfat_arch 2
|
||||
</strong><strong>आर्किटेक्चर x86_64
|
||||
</strong><strong>architecture x86_64
|
||||
</strong> cputype CPU_TYPE_X86_64
|
||||
cpusubtype CPU_SUBTYPE_X86_64_ALL
|
||||
capabilities 0x0
|
||||
<strong> offset 16384
|
||||
</strong><strong> size 72896
|
||||
</strong> align 2^14 (16384)
|
||||
<strong>आर्किटेक्चर arm64e
|
||||
<strong>architecture arm64e
|
||||
</strong> cputype CPU_TYPE_ARM64
|
||||
cpusubtype CPU_SUBTYPE_ARM64E
|
||||
capabilities PTR_AUTH_VERSION USERSPACE 0
|
||||
@ -64,15 +64,15 @@ capabilities PTR_AUTH_VERSION USERSPACE 0
|
||||
</strong> align 2^14 (16384)
|
||||
</code></pre>
|
||||
|
||||
या [Mach-O View](https://sourceforge.net/projects/machoview/) उपकरण का उपयोग करके:
|
||||
या [Mach-O View](https://sourceforge.net/projects/machoview/) टूल का उपयोग करके:
|
||||
|
||||
<figure><img src="../../../images/image (1094).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
जैसा कि आप सोच रहे होंगे, आमतौर पर 2 आर्किटेक्चर के लिए संकलित एक यूनिवर्सल बाइनरी **एक आर्क के लिए संकलित बाइनरी के आकार को दोगुना कर देती है**।
|
||||
जैसा कि आप सोच रहे होंगे, सामान्यतः 2 आर्किटेक्चर के लिए कम्पाइल की गई एक यूनिवर्सल बाइनरी एक ही आर्किटेक्चर के लिए कम्पाइल की गई बाइनरी के आकार को **दो गुना** कर देती है।
|
||||
|
||||
## **Mach-O हेडर**
|
||||
## **Mach-O Header**
|
||||
|
||||
हेडर फ़ाइल के बारे में बुनियादी जानकारी प्रदान करता है, जैसे कि इसे Mach-O फ़ाइल के रूप में पहचानने के लिए जादुई बाइट्स और लक्षित आर्किटेक्चर के बारे में जानकारी। आप इसे यहाँ पा सकते हैं: `mdfind loader.h | grep -i mach-o | grep -E "loader.h$"`
|
||||
हेडर फ़ाइल के बारे में बुनियादी जानकारी रखता है, जैसे कि उसे Mach-O फ़ाइल के रूप में पहचानने के लिए magic बाइट्स और लक्ष्य आर्किटेक्चर की जानकारी। आप इसे यहाँ पा सकते हैं: `mdfind loader.h | grep -i mach-o | grep -E "loader.h$"`
|
||||
```c
|
||||
#define MH_MAGIC 0xfeedface /* the mach magic number */
|
||||
#define MH_CIGAM 0xcefaedfe /* NXSwapInt(MH_MAGIC) */
|
||||
@ -101,18 +101,18 @@ uint32_t reserved; /* reserved */
|
||||
```
|
||||
### Mach-O फ़ाइल प्रकार
|
||||
|
||||
विभिन्न फ़ाइल प्रकार हैं, जिन्हें आप [**स्रोत कोड में उदाहरण के लिए यहाँ**](https://opensource.apple.com/source/xnu/xnu-2050.18.24/EXTERNAL_HEADERS/mach-o/loader.h) पर परिभाषित कर सकते हैं। सबसे महत्वपूर्ण हैं:
|
||||
There are different file types, you can find them defined in the [**source code for example here**](https://opensource.apple.com/source/xnu/xnu-2050.18.24/EXTERNAL_HEADERS/mach-o/loader.h). The most important ones are:
|
||||
|
||||
- `MH_OBJECT`: पुनर्स्थापनीय ऑब्जेक्ट फ़ाइल (संकलन के मध्यवर्ती उत्पाद, अभी निष्पादन योग्य नहीं)।
|
||||
- `MH_OBJECT`: रिलोकेटेबल ऑब्जेक्ट फ़ाइल (कम्पाइलिंग के मध्यवर्ती उत्पाद, अभी निष्पादन योग्य नहीं)।
|
||||
- `MH_EXECUTE`: निष्पादन योग्य फ़ाइलें।
|
||||
- `MH_FVMLIB`: निश्चित VM पुस्तकालय फ़ाइल।
|
||||
- `MH_CORE`: कोड डंप
|
||||
- `MH_PRELOAD`: प्रीलोडेड निष्पादन योग्य फ़ाइल (XNU में अब समर्थित नहीं)
|
||||
- `MH_DYLIB`: गतिशील पुस्तकालय
|
||||
- `MH_DYLINKER`: गतिशील लिंकर्स
|
||||
- `MH_BUNDLE`: "प्लगइन फ़ाइलें"। gcc में -bundle का उपयोग करके उत्पन्न और `NSBundle` या `dlopen` द्वारा स्पष्ट रूप से लोड की गई।
|
||||
- `MH_DYSM`: साथी `.dSym` फ़ाइल (डिबगिंग के लिए प्रतीकों के साथ फ़ाइल)।
|
||||
- `MH_KEXT_BUNDLE`: कर्नेल एक्सटेंशन।
|
||||
- `MH_FVMLIB`: Fixed VM लाइब्रेरी फ़ाइल।
|
||||
- `MH_CORE`: कोड डंप्स
|
||||
- `MH_PRELOAD`: प्रीलोडेड निष्पादन योग्य फ़ाइल (अब XNU में समर्थित नहीं)
|
||||
- `MH_DYLIB`: डायनेमिक लाइब्रेरीज़
|
||||
- `MH_DYLINKER`: डायनेमिक लिंकर
|
||||
- `MH_BUNDLE`: "प्लगइन फ़ाइलें". Generated using -bundle in gcc and explicitly loaded by `NSBundle` or `dlopen`.
|
||||
- `MH_DYSM`: Companion `.dSym` file (file with symbols for debugging).
|
||||
- `MH_KEXT_BUNDLE`: कर्नल एक्सटेंशंस।
|
||||
```bash
|
||||
# Checking the mac header of a binary
|
||||
otool -arch arm64e -hv /bin/ls
|
||||
@ -120,34 +120,34 @@ Mach header
|
||||
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
|
||||
MH_MAGIC_64 ARM64 E USR00 EXECUTE 19 1728 NOUNDEFS DYLDLINK TWOLEVEL PIE
|
||||
```
|
||||
या [Mach-O View](https://sourceforge.net/projects/machoview/) का उपयोग करके:
|
||||
Or using [Mach-O View](https://sourceforge.net/projects/machoview/):
|
||||
|
||||
<figure><img src="../../../images/image (1133).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## **Mach-O फ्लैग्स**
|
||||
## **Mach-O फ़्लैग्स**
|
||||
|
||||
स्रोत कोड कई फ्लैग्स को परिभाषित करता है जो लाइब्रेरी लोड करने के लिए उपयोगी होते हैं:
|
||||
स्रोत कोड कुछ फ़्लैग्स भी परिभाषित करता है जो लाइब्रेरीज़ लोड करने में उपयोगी होते हैं:
|
||||
|
||||
- `MH_NOUNDEFS`: कोई अपरिभाषित संदर्भ नहीं (पूर्ण रूप से लिंक किया गया)
|
||||
- `MH_NOUNDEFS`: कोई अपरिभाषित संदर्भ नहीं (पूर्ण रूप से लिंक्ड)
|
||||
- `MH_DYLDLINK`: Dyld लिंकिंग
|
||||
- `MH_PREBOUND`: गतिशील संदर्भ पूर्व बंधित।
|
||||
- `MH_SPLIT_SEGS`: फ़ाइल r/o और r/w खंडों में विभाजित होती है।
|
||||
- `MH_WEAK_DEFINES`: बाइनरी में कमजोर परिभाषित प्रतीक हैं
|
||||
- `MH_BINDS_TO_WEAK`: बाइनरी कमजोर प्रतीकों का उपयोग करती है
|
||||
- `MH_ALLOW_STACK_EXECUTION`: स्टैक को निष्पादित करने योग्य बनाएं
|
||||
- `MH_NO_REEXPORTED_DYLIBS`: लाइब्रेरी में LC_REEXPORT कमांड नहीं हैं
|
||||
- `MH_PIE`: स्थिति स्वतंत्र निष्पादन योग्य
|
||||
- `MH_HAS_TLV_DESCRIPTORS`: वहाँ एक अनुभाग है जिसमें थ्रेड स्थानीय चर हैं
|
||||
- `MH_NO_HEAP_EXECUTION`: हीप/डेटा पृष्ठों के लिए कोई निष्पादन नहीं
|
||||
- `MH_HAS_OBJC`: बाइनरी में oBject-C अनुभाग हैं
|
||||
- `MH_SIM_SUPPORT`: सिम्युलेटर समर्थन
|
||||
- `MH_DYLIB_IN_CACHE`: साझा लाइब्रेरी कैश में dylibs/फ्रेमवर्क पर उपयोग किया गया।
|
||||
- `MH_PREBOUND`: डायनमिक संदर्भ प्रीबाउंड।
|
||||
- `MH_SPLIT_SEGS`: फ़ाइल को r/o और r/w सेगमेंट में विभाजित करता है।
|
||||
- `MH_WEAK_DEFINES`: बाइनरी में weak परिभाषित प्रतीक हैं
|
||||
- `MH_BINDS_TO_WEAK`: बाइनरी weak symbols का उपयोग करती है
|
||||
- `MH_ALLOW_STACK_EXECUTION`: स्टैक को executable बनाता है
|
||||
- `MH_NO_REEXPORTED_DYLIBS`: लाइब्रेरी LC_REEXPORT कमांड्स के रूप में पुनः निर्यात नहीं होती
|
||||
- `MH_PIE`: Position Independent Executable
|
||||
- `MH_HAS_TLV_DESCRIPTORS`: थ्रेड लोकल वेरिएबल्स वाला सेक्शन मौजूद है
|
||||
- `MH_NO_HEAP_EXECUTION`: heap/data पृष्ठों पर execution नहीं
|
||||
- `MH_HAS_OBJC`: बाइनरी में Objective-C सेक्शन हैं
|
||||
- `MH_SIM_SUPPORT`: सिम्युलेटर सपोर्ट
|
||||
- `MH_DYLIB_IN_CACHE`: shared library cache में dylibs/frameworks पर उपयोग होता है।
|
||||
|
||||
## **Mach-O लोड कमांड्स**
|
||||
|
||||
**फाइल का लेआउट मेमोरी में** यहाँ निर्दिष्ट किया गया है, जिसमें **प्रतीक तालिका का स्थान**, निष्पादन प्रारंभ पर मुख्य थ्रेड का संदर्भ, और आवश्यक **साझा लाइब्रेरी** का विवरण है। गतिशील लोडर **(dyld)** को बाइनरी के मेमोरी में लोडिंग प्रक्रिया के लिए निर्देश दिए जाते हैं।
|
||||
The **file's layout in memory** is specified here, detailing the **symbol table's location**, the context of the main thread at execution start, and the required **shared libraries**. Instructions are provided to the dynamic loader **(dyld)** on the binary's loading process into memory.
|
||||
|
||||
यह **load_command** संरचना का उपयोग करता है, जिसे उल्लेखित **`loader.h`** में परिभाषित किया गया है:
|
||||
The uses the **load_command** structure, defined in the mentioned **`loader.h`**:
|
||||
```objectivec
|
||||
struct load_command {
|
||||
uint32_t cmd; /* type of load command */
|
||||
@ -159,15 +159,15 @@ There are about **50 different types of load commands** that the system handles
|
||||
### **LC_SEGMENT/LC_SEGMENT_64**
|
||||
|
||||
> [!TIP]
|
||||
> मूल रूप से, इस प्रकार का लोड कमांड **कैसे \_\_TEXT** (कार्यकारी कोड) **और \_\_DATA** (प्रक्रिया के लिए डेटा) **सेगमेंट को लोड करना है** यह परिभाषित करता है **जो डेटा अनुभाग में निर्दिष्ट ऑफसेट के अनुसार** बाइनरी के निष्पादन के समय।
|
||||
> मूलतः, इस प्रकार का Load Command यह परिभाषित करता है कि बाइनरी के execute होने पर **\_\_TEXT** (एक्जीक्यूटेबल कोड) और **\_\_DATA** (प्रोसेस के लिए डेटा) **segments** को Data सेक्शन में दिए गए **offsets** के अनुसार कैसे लोड किया जाए।
|
||||
|
||||
ये कमांड **सेगमेंट को परिभाषित करते हैं** जो **प्रक्रिया के निष्पादन के समय** के **वर्चुअल मेमोरी स्पेस** में **मैप** होते हैं।
|
||||
ये कमांड्स उन **segments को परिभाषित करते हैं** जो किसी प्रोसेस के execute होने पर उसके **वर्चुअल मेमोरी स्पेस** में **मैप** किए जाते हैं।
|
||||
|
||||
सेगमेंट के **विभिन्न प्रकार** होते हैं, जैसे कि **\_\_TEXT** सेगमेंट, जो एक प्रोग्राम के कार्यकारी कोड को रखता है, और **\_\_DATA** सेगमेंट, जो प्रक्रिया द्वारा उपयोग किए जाने वाले डेटा को शामिल करता है। ये **सेगमेंट Mach-O फ़ाइल के डेटा अनुभाग में स्थित होते हैं**।
|
||||
कई तरह के **segments** होते हैं, जैसे कि **\_\_TEXT** segment, जो किसी प्रोग्राम का executable code रखता है, और **\_\_DATA** segment, जो प्रोसेस द्वारा उपयोग किए जाने वाले डेटा को रखता है। ये **segments Mach-O फाइल के data section में स्थित** होते हैं।
|
||||
|
||||
**प्रत्येक सेगमेंट** को आगे **कई अनुभागों** में **विभाजित** किया जा सकता है। **लोड कमांड संरचना** में **इन अनुभागों** के बारे में **जानकारी** होती है जो संबंधित सेगमेंट के भीतर होती है।
|
||||
**प्रत्येक segment** को और भी छोटे-छोटे **sections** में **बाँटा** जा सकता है। **लोड कमांड संरचना** संबंधित segment के भीतर इन **sections** के बारे में **जानकारी** रखती है।
|
||||
|
||||
हेडर में पहले आपको **सेगमेंट हेडर** मिलता है:
|
||||
हैडर में सबसे पहले आपको **segment header** मिलता है:
|
||||
|
||||
<pre class="language-c"><code class="lang-c">struct segment_command_64 { /* for 64-bit architectures */
|
||||
uint32_t cmd; /* LC_SEGMENT_64 */
|
||||
@ -188,7 +188,7 @@ Example of segment header:
|
||||
|
||||
<figure><img src="../../../images/image (1126).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
This header defines the **number of sections whose headers appear after** it:
|
||||
यह हेडर उन **sections की संख्या जिनके हैडर इसके बाद दिखाई देते हैं** को परिभाषित करता है:
|
||||
```c
|
||||
struct section_64 { /* for 64-bit architectures */
|
||||
char sectname[16]; /* name of this section */
|
||||
@ -205,62 +205,62 @@ uint32_t reserved2; /* reserved (for count or sizeof) */
|
||||
uint32_t reserved3; /* reserved */
|
||||
};
|
||||
```
|
||||
उदाहरण **अनुभाग शीर्षक** का:
|
||||
उदाहरण: **सेक्शन हेडर**:
|
||||
|
||||
<figure><img src="../../../images/image (1108).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
यदि आप **अनुभाग ऑफसेट** (0x37DC) + **ऑफसेट** जहां **आर्क शुरू होता है**, इस मामले में `0x18000` जोड़ते हैं --> `0x37DC + 0x18000 = 0x1B7DC`
|
||||
यदि आप **section offset** (0x37DC) में उस **offset** को जोड़ें जहाँ **arch** शुरू होता है — इस मामले में `0x18000` — तो `0x37DC + 0x18000 = 0x1B7DC`
|
||||
|
||||
<figure><img src="../../../images/image (701).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
यह **कमांड लाइन** से **हेडर जानकारी** प्राप्त करना भी संभव है:
|
||||
आप **command line** के जरिए **headers information** भी प्राप्त कर सकते हैं:
|
||||
```bash
|
||||
otool -lv /bin/ls
|
||||
```
|
||||
सामान्य खंड जो इस cmd द्वारा लोड होते हैं:
|
||||
Common segments loaded by this cmd:
|
||||
|
||||
- **`__PAGEZERO`:** यह कर्नेल को **निर्देश** देता है कि **पता शून्य** को **मैप** करें ताकि इसे **पढ़ा, लिखा या निष्पादित** नहीं किया जा सके। संरचना में maxprot और minprot वेरिएबल को शून्य पर सेट किया गया है ताकि यह संकेत दिया जा सके कि इस पृष्ठ पर **कोई पढ़ने-लिखने-निष्पादन अधिकार नहीं हैं**।
|
||||
- यह आवंटन **NULL पॉइंटर डेरिफरेंस कमजोरियों** को **कम करने** के लिए महत्वपूर्ण है। इसका कारण यह है कि XNU एक कठोर पृष्ठ शून्य को लागू करता है जो सुनिश्चित करता है कि मेमोरी का पहला पृष्ठ (केवल पहला) अनुपलब्ध है (i386 को छोड़कर)। एक बाइनरी इस आवश्यकताओं को पूरा कर सकती है एक छोटे \_\_PAGEZERO ( `-pagezero_size` का उपयोग करके) को तैयार करके जो पहले 4k को कवर करता है और शेष 32-बिट मेमोरी को उपयोगकर्ता और कर्नेल मोड दोनों में सुलभ बनाता है।
|
||||
- **`__TEXT`**: इसमें **निष्पादन योग्य** **कोड** होता है जिसमें **पढ़ने** और **निष्पादन** की अनुमति होती है (कोई लिखने योग्य नहीं)**।** इस खंड के सामान्य अनुभाग:
|
||||
- `__text`: संकलित बाइनरी कोड
|
||||
- `__const`: स्थायी डेटा (केवल पढ़ने के लिए)
|
||||
- `__[c/u/os_log]string`: C, यूनिकोड या os लॉग स्ट्रिंग स्थिरांक
|
||||
- `__stubs` और `__stubs_helper`: गतिशील पुस्तकालय लोडिंग प्रक्रिया के दौरान शामिल होते हैं
|
||||
- **`__PAGEZERO`:** यह kernel को निर्देश देता है कि वह **map** करे `address zero` को ताकि इसे **read से, write से, या execute से रोक दिया जाए**। संरचना में maxprot और minprot वेरिएबल्स को शून्य पर सेट किया जाता है ताकि सूचित हो कि इस पेज पर **कोई read-write-execute अधिकार नहीं हैं**।
|
||||
- यह allocation महत्वपूर्ण है ताकि **NULL pointer dereference vulnerabilities** को mitigate किया जा सके। इसका कारण यह है कि XNU एक hard page zero लागू करता है जो सुनिश्चित करता है कि memory का पहला पेज (सिर्फ पहला) inaccessible हो (i386 को छोड़कर)। एक बाइनरी इस आवश्यकता को पूरा कर सकता है छोटे \_\_PAGEZERO का निर्माण करके ( `-pagezero_size` का उपयोग करके) जो पहले 4k को कवर करे और शेष 32bit memory को user और kernel मोड दोनों में accessible रखे।
|
||||
- **`__TEXT`**: इसमें **executable** **code** होता है जिसमें **read** और **execute** permissions होते हैं (कोई writable नहीं)**.** इस सेगमेंट के सामान्य सेक्शन्स:
|
||||
- `__text`: Compiled binary code
|
||||
- `__const`: Constant data (read only)
|
||||
- `__[c/u/os_log]string`: C, Unicode or os logs string constants
|
||||
- `__stubs` and `__stubs_helper`: डायनेमिक लाइब्रेरी लोडिंग प्रक्रिया के दौरान उपयोग होते हैं
|
||||
- `__unwind_info`: स्टैक अनवाइंड डेटा।
|
||||
- ध्यान दें कि इस सभी सामग्री पर हस्ताक्षर किया गया है लेकिन इसे निष्पादन योग्य के रूप में भी चिह्नित किया गया है (ऐसे अनुभागों के शोषण के लिए अधिक विकल्प बनाना जिन्हें इस विशेषाधिकार की आवश्यकता नहीं होती, जैसे स्ट्रिंग समर्पित अनुभाग)।
|
||||
- **`__DATA`**: इसमें डेटा होता है जो **पढ़ने योग्य** और **लिखने योग्य** (कोई निष्पादन योग्य नहीं)**।**
|
||||
- `__got:` वैश्विक ऑफसेट तालिका
|
||||
- `__nl_symbol_ptr`: गैर आलसी (लोड पर बाइंड) प्रतीक पॉइंटर
|
||||
- `__la_symbol_ptr`: आलसी (उपयोग पर बाइंड) प्रतीक पॉइंटर
|
||||
- `__const`: इसे केवल पढ़ने योग्य डेटा होना चाहिए (वास्तव में नहीं)
|
||||
- `__cfstring`: कोरफाउंडेशन स्ट्रिंग
|
||||
- `__data`: वैश्विक वेरिएबल (जो प्रारंभिक किया गया है)
|
||||
- `__bss`: स्थिर वेरिएबल (जो प्रारंभिक नहीं किया गया है)
|
||||
- `__objc_*` (\_\_objc_classlist, \_\_objc_protolist, आदि): जानकारी जो ऑब्जेक्टिव-C रनटाइम द्वारा उपयोग की जाती है
|
||||
- **`__DATA_CONST`**: \_\_DATA.\_\_const को स्थायी होने की गारंटी नहीं है (लिखने की अनुमति), न ही अन्य पॉइंटर्स और GOT। यह अनुभाग `__const`, कुछ प्रारंभिक और GOT तालिका (एक बार हल होने पर) को **केवल पढ़ने योग्य** बनाता है `mprotect` का उपयोग करके।
|
||||
- **`__LINKEDIT`**: इसमें लिंकर्स (dyld) के लिए जानकारी होती है जैसे, प्रतीक, स्ट्रिंग, और पुनर्स्थापन तालिका प्रविष्टियाँ। यह `__TEXT` या `__DATA` में न होने वाली सामग्री के लिए एक सामान्य कंटेनर है और इसकी सामग्री अन्य लोड कमांड में वर्णित है।
|
||||
- dyld जानकारी: रीबेस, गैर-आलसी/आलसी/कमजोर बाइंडिंग ऑपकोड और निर्यात जानकारी
|
||||
- फ़ंक्शंस प्रारंभ: फ़ंक्शंस के प्रारंभ पते की तालिका
|
||||
- कोड में डेटा: \_\_text में डेटा द्वीप
|
||||
- प्रतीक तालिका: बाइनरी में प्रतीक
|
||||
- अप्रत्यक्ष प्रतीक तालिका: पॉइंटर/स्टब प्रतीक
|
||||
- स्ट्रिंग तालिका
|
||||
- कोड सिग्नेचर
|
||||
- **`__OBJC`**: इसमें ऑब्जेक्टिव-C रनटाइम द्वारा उपयोग की जाने वाली जानकारी होती है। हालांकि यह जानकारी \_\_DATA खंड में भी पाई जा सकती है, विभिन्न \_\_objc\_\* अनुभागों के भीतर।
|
||||
- **`__RESTRICT`**: एक ऐसा खंड जिसमें सामग्री नहीं होती है जिसमें एकल अनुभाग होता है जिसे **`__restrict`** (भी खाली) कहा जाता है जो सुनिश्चित करता है कि बाइनरी चलाते समय, यह DYLD पर्यावरणीय चर को अनदेखा करेगा।
|
||||
- ध्यान दें कि यह सभी कंटेंट signed होते हैं पर साथ ही executable के रूप में चिह्नित भी होते हैं (जिससे उन सेक्शन्स का exploitation करने के और विकल्प बनते हैं जिनको जरूरी नहीं कि यह privilege चाहिए, जैसे string dedicated sections)।
|
||||
- **`__DATA`**: इसमें डेटा होता है जो **readable** और **writable** होता है (कोई executable नहीं)**.**
|
||||
- `__got:` Global Offset Table
|
||||
- `__nl_symbol_ptr`: Non lazy (bind at load) symbol pointer
|
||||
- `__la_symbol_ptr`: Lazy (bind on use) symbol pointer
|
||||
- `__const`: पढ़ने योग्य होना चाहिए (वास्तव में नहीं)
|
||||
- `__cfstring`: CoreFoundation strings
|
||||
- `__data`: Global variables (that have been initialized)
|
||||
- `__bss`: Static variables (that have not been initialized)
|
||||
- `__objc_*` (\_\_objc_classlist, \_\_objc_protolist, etc): Objective-C runtime द्वारा उपयोग की जाने वाली जानकारी
|
||||
- **`__DATA_CONST`**: \_\_DATA.\_\_const की constant होने की गारंटी नहीं होती (write permissions), न ही अन्य pointers और GOT की। यह सेक्शन `__const`, कुछ initializers और GOT टेबल (एक बार resolved होने पर) को `mprotect` का उपयोग करके **read only** बनाता है।
|
||||
- **`__LINKEDIT`**: linker (dyld) के लिए जानकारी रखता है जैसे कि symbol, string, और relocation table entries। यह उन कंटेंट्स के लिए एक generic container है जो `__TEXT` या `__DATA` में नहीं हैं और इसकी सामग्री अन्य load commands में वर्णित है।
|
||||
- dyld information: Rebase, Non-lazy/lazy/weak binding opcodes and export info
|
||||
- Functions starts: Table of start addresses of functions
|
||||
- Data In Code: Data islands in \_\_text
|
||||
- SYmbol Table: Symbols in binary
|
||||
- Indirect Symbol Table: Pointer/stub symbols
|
||||
- String Table
|
||||
- Code Signature
|
||||
- **`__OBJC`**: Objective-C runtime द्वारा उपयोग की जाने वाली जानकारी रखता है। हालांकि यह जानकारी \_\_DATA सेगमेंट में भी मिल सकती है, विभिन्न \_\_objc\_\* सेक्शन्स के भीतर।
|
||||
- **`__RESTRICT`**: एक ऐसा सेगमेंट जिसका कोई कंटेंट नहीं होता और जिसमें एक अकेला सेक्शन होता है जिसका नाम **`__restrict`** (यह भी खाली) है, जो सुनिश्चित करता है कि बाइनरी चलने पर यह DYLD environmental variables को ignore करे।
|
||||
|
||||
जैसा कि कोड में देखा जा सकता है, **खंड भी फ़्लैग का समर्थन करते हैं** (हालांकि उनका बहुत अधिक उपयोग नहीं किया जाता):
|
||||
जैसा कि कोड में देखा जा सकता है, **segments flags को भी सपोर्ट करते हैं** (हालाँकि इनका बहुत अधिक उपयोग नहीं होता):
|
||||
|
||||
- `SG_HIGHVM`: केवल कोर (उपयोग नहीं किया गया)
|
||||
- `SG_FVMLIB`: उपयोग नहीं किया गया
|
||||
- `SG_NORELOC`: खंड में कोई पुनर्स्थापन नहीं है
|
||||
- `SG_PROTECTED_VERSION_1`: एन्क्रिप्शन। उदाहरण के लिए Finder द्वारा `__TEXT` खंड को एन्क्रिप्ट करने के लिए उपयोग किया जाता है।
|
||||
- `SG_HIGHVM`: Core only (not used)
|
||||
- `SG_FVMLIB`: Not used
|
||||
- `SG_NORELOC`: Segment has no relocation
|
||||
- `SG_PROTECTED_VERSION_1`: एन्क्रिप्शन। उदाहरण के लिए Finder द्वारा text `__TEXT` segment को एन्क्रिप्ट करने के लिए प्रयोग किया जाता है।
|
||||
|
||||
### **`LC_UNIXTHREAD/LC_MAIN`**
|
||||
|
||||
**`LC_MAIN`** में **entryoff विशेषता** में प्रवेश बिंदु होता है। लोड समय पर, **dyld** बस इस मान को (मेमोरी में) **बाइनरी के आधार** में **जोड़ता** है, फिर **इस निर्देश पर कूदता** है ताकि बाइनरी के कोड का निष्पादन शुरू हो सके।
|
||||
**`LC_MAIN`** entryoff attribute में entrypoint रखता है। लोड समय पर, **dyld** बस इस मान को (in-memory) **base of the binary** में जोड़ देता है, फिर इस निर्देश पर **jump** करके बाइनरी के कोड के निष्पादन को शुरू करता है।
|
||||
|
||||
**`LC_UNIXTHREAD`** में वे मान होते हैं जो रजिस्टर को मुख्य धागा शुरू करते समय होना चाहिए। इसे पहले ही अमान्य कर दिया गया था लेकिन **`dyld`** अभी भी इसका उपयोग करता है। इसे सेट किए गए रजिस्टर के मानों को देखने के लिए संभव है:
|
||||
**`LC_UNIXTHREAD`** में वे मान होते हैं जो main thread शुरू करते समय registers में होने चाहिए। यह पहले से ही deprecated है लेकिन **`dyld`** अभी भी इसका उपयोग करता है। आप इसके द्वारा सेट किए गए registers के values को यह कमांड देखकर देख सकते हैं:
|
||||
```bash
|
||||
otool -l /usr/lib/dyld
|
||||
[...]
|
||||
@ -286,34 +286,39 @@ cpsr 0x00000000
|
||||
```
|
||||
### **`LC_CODE_SIGNATURE`**
|
||||
|
||||
यह **Macho-O फ़ाइल** के **कोड हस्ताक्षर** के बारे में जानकारी रखता है। इसमें केवल एक **ऑफसेट** होता है जो **हस्ताक्षर ब्लॉब** की ओर **संकेत** करता है। यह आमतौर पर फ़ाइल के अंत में होता है।\
|
||||
हालांकि, आप इस अनुभाग के बारे में कुछ जानकारी [**इस ब्लॉग पोस्ट**](https://davedelong.com/blog/2018/01/10/reading-your-own-entitlements/) और इस [**gists**](https://gist.github.com/carlospolop/ef26f8eb9fafd4bc22e69e1a32b81da4) में पा सकते हैं।
|
||||
{{#ref}}
|
||||
../../../generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/mach-o-entitlements-and-ipsw-indexing.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
Contains information about the **code signature of the Mach-O file**. It only contains an **offset** that **points** to the **signature blob**. This is typically at the very end of the file.\
|
||||
However, you can find some information about this section in [**this blog post**](https://davedelong.com/blog/2018/01/10/reading-your-own-entitlements/) and this [**gists**](https://gist.github.com/carlospolop/ef26f8eb9fafd4bc22e69e1a32b81da4).
|
||||
|
||||
### **`LC_ENCRYPTION_INFO[_64]`**
|
||||
|
||||
बाइनरी एन्क्रिप्शन के लिए समर्थन। हालाँकि, यदि एक हमलावर प्रक्रिया को समझौता करने में सफल हो जाता है, तो वह बिना एन्क्रिप्टेड मेमोरी को डंप कर सकेगा।
|
||||
बाइनरी एन्क्रिप्शन के लिए समर्थन। हालांकि, ज़ाहिर है, अगर कोई attacker प्रक्रिया को compromise कर लेता है, तो वह मेमोरी को अनएन्क्रिप्टेड dump कर पाएगा।
|
||||
|
||||
### **`LC_LOAD_DYLINKER`**
|
||||
|
||||
यह **डायनामिक लिंकर्स निष्पादन योग्य** का **पथ** रखता है जो साझा पुस्तकालयों को प्रक्रिया के पते की जगह में मैप करता है। **मान हमेशा `/usr/lib/dyld` पर सेट होता है**। यह ध्यान रखना महत्वपूर्ण है कि macOS में, dylib मैपिंग **उपयोगकर्ता मोड** में होती है, न कि कर्नेल मोड में।
|
||||
यह उस **dynamic linker executable के path** को बताता है जो shared libraries को process address space में map करता है। **value हमेशा `/usr/lib/dyld` पर सेट रहती है**। यह ध्यान देने योग्य है कि macOS में, dylib mapping **user mode** में होता है, kernel mode में नहीं।
|
||||
|
||||
### **`LC_IDENT`**
|
||||
|
||||
पुराना लेकिन जब पैनिक पर डंप उत्पन्न करने के लिए कॉन्फ़िगर किया जाता है, तो एक Mach-O कोर डंप बनाया जाता है और कर्नेल संस्करण `LC_IDENT` कमांड में सेट होता है।
|
||||
अब प्रचलन में नहीं है, लेकिन जब panic पर dumps generate करने के लिए कॉन्फ़िगर किया जाता है, तो एक Mach-O core dump बनाया जाता है और kernel version `LC_IDENT` कमांड में सेट किया जाता है।
|
||||
|
||||
### **`LC_UUID`**
|
||||
|
||||
यादृच्छिक UUID। यह किसी भी चीज़ के लिए उपयोगी है लेकिन XNU इसे प्रक्रिया की अन्य जानकारी के साथ कैश करता है। इसका उपयोग क्रैश रिपोर्ट में किया जा सकता है।
|
||||
Random UUID। यह प्रत्यक्ष रूप से किसी भी चीज़ के लिए उपयोगी हो सकता है लेकिन XNU इसे बाकी process info के साथ cache करता है। इसे crash reports में इस्तेमाल किया जा सकता है।
|
||||
|
||||
### **`LC_DYLD_ENVIRONMENT`**
|
||||
|
||||
प्रक्रिया के निष्पादन से पहले dyld को पर्यावरण चर निर्दिष्ट करने की अनुमति देता है। यह बहुत खतरनाक हो सकता है क्योंकि यह प्रक्रिया के अंदर मनमाना कोड निष्पादित करने की अनुमति दे सकता है, इसलिए यह लोड कमांड केवल `#define SUPPORT_LC_DYLD_ENVIRONMENT` के साथ dyld निर्माण में उपयोग किया जाता है और केवल `DYLD_..._PATH` के रूप के चर को लोड पथ निर्दिष्ट करने के लिए आगे संसाधित करने की अनुमति देता है।
|
||||
यह dyld को environment variables बताने की अनुमति देता है इससे पहले कि process execute हो। यह बहुत खतरनाक हो सकता है क्योंकि इससे process के अंदर arbitrary code execute होने की अनुमति मिल सकती है, इसलिए यह load command केवल dyld build में `#define SUPPORT_LC_DYLD_ENVIRONMENT` के साथ उपयोग किया जाता है और प्रोसेसिंग को केवल `DYLD_..._PATH` स्वरूप के variables तक सीमित करता है जो load paths निर्दिष्ट करते हैं।
|
||||
|
||||
### **`LC_LOAD_DYLIB`**
|
||||
|
||||
यह लोड कमांड एक **डायनामिक** **लाइब्रेरी** निर्भरता का वर्णन करता है जो **लोडर** (dyld) को **कहा गया लाइब्रेरी लोड और लिंक करने** के लिए **निर्देश** देता है। Mach-O बाइनरी के लिए आवश्यक **प्रत्येक लाइब्रेरी** के लिए एक `LC_LOAD_DYLIB` लोड कमांड है।
|
||||
This load command describes a **dynamic** **library** dependency which **instructs** the **loader** (dyld) to **load and link said library**. There is a `LC_LOAD_DYLIB` load command **for each library** that the Mach-O binary requires.
|
||||
|
||||
- यह लोड कमांड **`dylib_command`** प्रकार की संरचना है (जिसमें एक स्ट्रक्चर dylib होता है, जो वास्तविक निर्भरता डायनामिक लाइब्रेरी का वर्णन करता है):
|
||||
- यह load command प्रकार **`dylib_command`** की एक संरचना है (जिसमें एक struct dylib होता है, जो वास्तविक dependent dynamic library का वर्णन करता है):
|
||||
```objectivec
|
||||
struct dylib_command {
|
||||
uint32_t cmd; /* LC_LOAD_{,WEAK_}DYLIB */
|
||||
@ -330,7 +335,7 @@ uint32_t compatibility_version; /* library's compatibility vers number*/
|
||||
```
|
||||
.png>)
|
||||
|
||||
आप इस जानकारी को cli से भी प्राप्त कर सकते हैं:
|
||||
आप यह जानकारी cli से भी प्राप्त कर सकते हैं:
|
||||
```bash
|
||||
otool -L /bin/ls
|
||||
/bin/ls:
|
||||
@ -338,55 +343,55 @@ otool -L /bin/ls
|
||||
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
|
||||
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
|
||||
```
|
||||
कुछ संभावित मैलवेयर से संबंधित पुस्तकालय हैं:
|
||||
कुछ संभावित malware संबंधित लाइब्रेरीज़ हैं:
|
||||
|
||||
- **DiskArbitration**: USB ड्राइव की निगरानी
|
||||
- **AVFoundation:** ऑडियो और वीडियो कैप्चर
|
||||
- **CoreWLAN**: वाईफाई स्कैन।
|
||||
- **DiskArbitration**: USB ड्राइव्स की निगरानी
|
||||
- **AVFoundation:** ऑडियो और वीडियो कैप्चर करना
|
||||
- **CoreWLAN**: Wi-Fi स्कैन।
|
||||
|
||||
> [!NOTE]
|
||||
> एक Mach-O बाइनरी में एक या **अधिक** **कंस्ट्रक्टर्स** हो सकते हैं, जिन्हें **LC_MAIN** में निर्दिष्ट पते से **पहले** **निष्पादित** किया जाएगा।\
|
||||
> किसी भी कंस्ट्रक्टर के ऑफसेट **\_\_mod_init_func** सेक्शन में **\_\_DATA_CONST** सेगमेंट में रखे जाते हैं।
|
||||
> [!TIP]
|
||||
> एक Mach-O बाइनरी में एक या अधिक **constructors** हो सकते हैं, जिन्हें **LC_MAIN** में निर्दिष्ट पते से पहले निष्पादित किया जाता है।\
|
||||
> किसी भी constructors के offsets **\_\_mod_init_func** सेक्शन में रखे जाते हैं जो **\_\_DATA_CONST** सेगमेंट का हिस्सा है।
|
||||
|
||||
## **Mach-O डेटा**
|
||||
|
||||
फाइल के मूल में डेटा क्षेत्र है, जो लोड-कमांड क्षेत्र में परिभाषित कई सेगमेंट से बना है। **प्रत्येक सेगमेंट के भीतर विभिन्न प्रकार के डेटा सेक्शन हो सकते हैं**, प्रत्येक सेक्शन में एक प्रकार के लिए विशिष्ट **कोड या डेटा** होता है।
|
||||
फाइल के मूल में डेटा क्षेत्र होता है, जो load-commands क्षेत्र में परिभाषित कई सेगमेंट्स से बना होता है। **प्रत्येक सेगमेंट के भीतर विभिन्न डेटा सेक्शन्स हो सकते हैं**, और प्रत्येक सेक्शन किसी विशिष्ट प्रकार के लिए **code या data** रखता है।
|
||||
|
||||
> [!TIP]
|
||||
> डेटा मूल रूप से वह भाग है जिसमें सभी **जानकारी** होती है जो लोड कमांड **LC_SEGMENTS_64** द्वारा लोड की जाती है।
|
||||
> डेटा मूलतः वह भाग है जिसमें load commands **LC_SEGMENTS_64** द्वारा लोड की जाने वाली सभी जानकारी होती है।
|
||||
|
||||
 (3).png>)
|
||||
|
||||
इसमें शामिल हैं:
|
||||
यह शामिल करता है:
|
||||
|
||||
- **फंक्शन टेबल:** जो प्रोग्राम फंक्शंस के बारे में जानकारी रखता है।
|
||||
- **सिंबल टेबल**: जो बाइनरी द्वारा उपयोग किए जाने वाले बाहरी फंक्शन के बारे में जानकारी रखता है
|
||||
- इसमें आंतरिक फंक्शन, वेरिएबल नाम भी हो सकते हैं और अधिक।
|
||||
- **Function table:** जो प्रोग्राम के functions के बारे में जानकारी रखता है।
|
||||
- **Symbol table**: जो बाइनरी द्वारा उपयोग की जाने वाली external functions के बारे में जानकारी रखता है।
|
||||
- यह अंदरूनी function, variable नामों और अन्य चीज़ों को भी शामिल कर सकता है।
|
||||
|
||||
इसे जांचने के लिए आप [**Mach-O View**](https://sourceforge.net/projects/machoview/) टूल का उपयोग कर सकते हैं:
|
||||
To check it you could use the [**Mach-O View**](https://sourceforge.net/projects/machoview/) tool:
|
||||
|
||||
<figure><img src="../../../images/image (1120).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
या CLI से:
|
||||
Or from the cli:
|
||||
```bash
|
||||
size -m /bin/ls
|
||||
```
|
||||
## Objetive-C सामान्य अनुभाग
|
||||
|
||||
In `__TEXT` segment (r-x):
|
||||
`__TEXT` सेगमेंट (r-x) में:
|
||||
|
||||
- `__objc_classname`: क्लास नाम (स्ट्रिंग)
|
||||
- `__objc_methname`: मेथड नाम (स्ट्रिंग)
|
||||
- `__objc_methtype`: मेथड प्रकार (स्ट्रिंग)
|
||||
- `__objc_classname`: क्लास नाम (strings)
|
||||
- `__objc_methname`: मेथड नाम (strings)
|
||||
- `__objc_methtype`: मेथड प्रकार (strings)
|
||||
|
||||
In `__DATA` segment (rw-):
|
||||
`__DATA` सेगमेंट (rw-) में:
|
||||
|
||||
- `__objc_classlist`: सभी Objetive-C क्लासेस के लिए पॉइंटर्स
|
||||
- `__objc_nlclslist`: नॉन-लेज़ी Objective-C क्लासेस के लिए पॉइंटर्स
|
||||
- `__objc_catlist`: श्रेणियों के लिए पॉइंटर
|
||||
- `__objc_nlcatlist`: नॉन-लेज़ी श्रेणियों के लिए पॉइंटर
|
||||
- `__objc_protolist`: प्रोटोकॉल सूची
|
||||
- `__objc_const`: स्थायी डेटा
|
||||
- `__objc_classlist`: सभी Objetive-C क्लासेस के पॉइंटर्स
|
||||
- `__objc_nlclslist`: Non-Lazy Objetive-C क्लासेस के पॉइंटर्स
|
||||
- `__objc_catlist`: Categories का पॉइंटर
|
||||
- `__objc_nlcatlist`: Non-Lazy Categories का पॉइंटर
|
||||
- `__objc_protolist`: प्रोटोकॉल्स सूची
|
||||
- `__objc_const`: स्थिर डेटा
|
||||
- `__objc_imageinfo`, `__objc_selrefs`, `objc__protorefs`...
|
||||
|
||||
## Swift
|
||||
|
||||
@ -1,15 +1,20 @@
|
||||
# macOS कोड साइनिंग
|
||||
# macOS Code Signing
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## बुनियादी जानकारी
|
||||
## बेसिक जानकारी
|
||||
|
||||
Mach-o बाइनरी में एक लोड कमांड होता है जिसे **`LC_CODE_SIGNATURE`** कहा जाता है, जो बाइनरी के अंदर सिग्नेचर के **ऑफसेट** और **आकार** को इंगित करता है। वास्तव में, GUI टूल MachOView का उपयोग करके, बाइनरी के अंत में **कोड सिग्नेचर** नामक एक अनुभाग पाया जा सकता है जिसमें यह जानकारी होती है:
|
||||
{{#ref}}
|
||||
../../../generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/mach-o-entitlements-and-ipsw-indexing.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
Mach-o binaries में एक load command होता है जिसका नाम **`LC_CODE_SIGNATURE`** है जो बाइनरी के अंदर signatures के **offset** और **size** को दर्शाता है। दरअसल, GUI tool MachOView का उपयोग करके, बाइनरी के अंत में **Code Signature** नामक एक section पाया जा सकता है जिसमें यह जानकारी रहती है:
|
||||
|
||||
<figure><img src="../../../images/image (1) (1) (1) (1).png" alt="" width="431"><figcaption></figcaption></figure>
|
||||
|
||||
कोड सिग्नेचर का जादुई हेडर **`0xFADE0CC0`** है। फिर आपके पास सुपरब्लॉब के ब्लॉब की लंबाई और संख्या जैसी जानकारी होती है जो उन्हें शामिल करती है।\
|
||||
यह जानकारी [स्रोत कोड यहाँ](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/osfmk/kern/cs_blobs.h#L276) पर पाई जा सकती है:
|
||||
Code Signature का magic header **`0xFADE0CC0`** है। फिर आपको उन blobs को contain करने वाले superBlob की length और number of blobs जैसी जानकारी मिलती है।\
|
||||
यह जानकारी आप [source code here](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/osfmk/kern/cs_blobs.h#L276):
|
||||
```c
|
||||
/*
|
||||
* Structure of an embedded-signature SuperBlob
|
||||
@ -38,14 +43,14 @@ char data[];
|
||||
} CS_GenericBlob
|
||||
__attribute__ ((aligned(1)));
|
||||
```
|
||||
सामान्य ब्लॉब में कोड निर्देशिका, आवश्यकताएँ और अधिकार और एक क्रिप्टोग्राफिक संदेश सिंटैक्स (CMS) शामिल होते हैं।\
|
||||
इसके अलावा, ध्यान दें कि ब्लॉब में एन्कोडेड डेटा **बिग एंडियन** में एन्कोडेड है।
|
||||
सामान्य रूप से मौजूद blobs में Code Directory, Requirements और Entitlements तथा एक Cryptographic Message Syntax (CMS) शामिल होते हैं।\
|
||||
साथ ही ध्यान दें कि blobs में एन्कोड किया गया डेटा **Big Endian.**
|
||||
|
||||
इसके अलावा, हस्ताक्षर बाइनरी से अलग किए जा सकते हैं और `/var/db/DetachedSignatures` में संग्रहीत किए जा सकते हैं (जो iOS द्वारा उपयोग किया जाता है)।
|
||||
साथ ही, signatures बाइनरी से अलग करके `/var/db/DetachedSignatures` में स्टोर की जा सकती हैं (iOS द्वारा उपयोग)।
|
||||
|
||||
## कोड निर्देशिका ब्लॉब
|
||||
## Code Directory Blob
|
||||
|
||||
[कोड निर्देशिका ब्लॉब की घोषणा कोड में पाई जा सकती है](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/osfmk/kern/cs_blobs.h#L104):
|
||||
कोड में [Code Directory Blob in the code](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/osfmk/kern/cs_blobs.h#L104) की घोषणा देखी जा सकती है:
|
||||
```c
|
||||
typedef struct __CodeDirectory {
|
||||
uint32_t magic; /* magic number (CSMAGIC_CODEDIRECTORY) */
|
||||
@ -101,12 +106,12 @@ char end_withLinkage[0];
|
||||
} CS_CodeDirectory
|
||||
__attribute__ ((aligned(1)));
|
||||
```
|
||||
ध्यान दें कि इस संरचना के विभिन्न संस्करण हैं जहाँ पुराने संस्करणों में कम जानकारी हो सकती है।
|
||||
ध्यान दें कि इस struct के अलग-अलग संस्करण हैं जहाँ पुराने वाले कम जानकारी रख सकते हैं।
|
||||
|
||||
## साइनिंग कोड पेजेस
|
||||
## Signing Code Pages
|
||||
|
||||
पूर्ण बाइनरी का हैशिंग अप्रभावी और यहां तक कि बेकार होगा यदि इसे केवल आंशिक रूप से मेमोरी में लोड किया गया हो। इसलिए, कोड सिग्नेचर वास्तव में हैश का हैश है जहाँ प्रत्येक बाइनरी पृष्ठ को व्यक्तिगत रूप से हैश किया जाता है।\
|
||||
वास्तव में, पिछले **कोड डायरेक्टरी** कोड में आप देख सकते हैं कि **पृष्ठ का आकार निर्दिष्ट है** इसके एक क्षेत्र में। इसके अलावा, यदि बाइनरी का आकार पृष्ठ के आकार का गुणांक नहीं है, तो क्षेत्र **CodeLimit** यह निर्दिष्ट करता है कि सिग्नेचर का अंत कहाँ है।
|
||||
यदि पूरा binary हैश किया जाए तो यह अप्रभावी और बेकार होगा जब वह केवल memory में आंशिक रूप से लोड हो। इसलिए, code signature वास्तव में एक hash of hashes है जहाँ प्रत्येक binary page को अलग-अलग hashed किया जाता है।\
|
||||
वास्तव में, पिछले **Code Directory** code में आप देख सकते हैं कि उसके एक field में **page size is specified**। इसके अलावा, यदि binary का size किसी page के size का multiple नहीं है, तो field **CodeLimit** यह निर्दिष्ट करता है कि signature का अंत कहाँ है।
|
||||
```bash
|
||||
# Get all hashes of /bin/ps
|
||||
codesign -d -vvvvvv /bin/ps
|
||||
@ -144,25 +149,25 @@ openssl sha256 /tmp/*.page.*
|
||||
```
|
||||
## Entitlements Blob
|
||||
|
||||
ध्यान दें कि अनुप्रयोगों में एक **entitlement blob** भी हो सकता है जहाँ सभी अधिकार परिभाषित होते हैं। इसके अलावा, कुछ iOS बाइनरी में उनके अधिकार विशेष स्लॉट -7 में विशिष्ट हो सकते हैं (बजाय -5 अधिकार विशेष स्लॉट में)।
|
||||
ध्यान दें कि applications में एक **entitlement blob** भी हो सकता है जहाँ सभी entitlements परिभाषित होते हैं। इसके अलावा, कुछ iOS binaries में उनके entitlements विशेष स्लॉट -7 में हो सकते हैं (बज़ाय -5 entitlements विशेष स्लॉट के)।
|
||||
|
||||
## Special Slots
|
||||
|
||||
MacOS अनुप्रयोगों को बाइनरी के अंदर निष्पादित करने के लिए उन्हें जो कुछ भी चाहिए वह नहीं होता, बल्कि वे **external resources** (आमतौर पर अनुप्रयोगों के **bundle** के अंदर) का भी उपयोग करते हैं। इसलिए, बाइनरी के अंदर कुछ स्लॉट होते हैं जो कुछ दिलचस्प बाहरी संसाधनों के हैश को रखेंगे ताकि यह जांचा जा सके कि उन्हें संशोधित नहीं किया गया है।
|
||||
MacOS applications के पास binary के अंदर चलने के लिए सब कुछ नहीं होता, बल्कि वे **external resources** का भी उपयोग करते हैं (आम तौर पर applications के **bundle** के भीतर)। इसलिए, binary के अंदर कुछ ऐसे स्लॉट होते हैं जो कुछ महत्वपूर्ण external resources के hashes रखेंगे ताकि यह जांचा जा सके कि उन्हें modify नहीं किया गया है।
|
||||
|
||||
वास्तव में, कोड निर्देशिका संरचनाओं में एक पैरामीटर है जिसे **`nSpecialSlots`** कहा जाता है, जो विशेष स्लॉट की संख्या को इंगित करता है। वहाँ विशेष स्लॉट 0 नहीं है और सबसे सामान्य ( -1 से -6 तक) हैं:
|
||||
वास्तव में, Code Directory structs में **`nSpecialSlots`** नाम का एक parameter देखा जा सकता है जो special slots की संख्या दर्शाता है। यहाँ कोई special slot 0 नहीं होता और सबसे आम ones (from -1 to -6) हैं:
|
||||
|
||||
- `info.plist` का हैश (या वह जो `__TEXT.__info__plist` के अंदर है)।
|
||||
- आवश्यकताओं का हैश
|
||||
- संसाधन निर्देशिका का हैश (बंडल के अंदर `_CodeSignature/CodeResources` फ़ाइल का हैश)।
|
||||
- अनुप्रयोग विशिष्ट (अप्रयुक्त)
|
||||
- अधिकारों का हैश
|
||||
- केवल DMG कोड हस्ताक्षर
|
||||
- DER अधिकार
|
||||
- `info.plist` का Hash (या जो `__TEXT.__info__plist` के अंदर है)।
|
||||
- Requirements का Hash
|
||||
- Resource Directory का Hash (`_CodeSignature/CodeResources` फ़ाइल का bundle के अंदर hash)।
|
||||
- Application specific (unused)
|
||||
- Entitlements का Hash
|
||||
- केवल DMG code signatures
|
||||
- DER Entitlements
|
||||
|
||||
## Code Signing Flags
|
||||
|
||||
हर प्रक्रिया से संबंधित एक बिटमास्क होता है जिसे `status` के रूप में जाना जाता है जिसे कर्नेल द्वारा शुरू किया जाता है और इनमें से कुछ को **कोड हस्ताक्षर** द्वारा ओवरराइड किया जा सकता है। कोड हस्ताक्षर में शामिल किए जा सकने वाले ये ध्वज [कोड में परिभाषित हैं](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/osfmk/kern/cs_blobs.h#L36):
|
||||
हर process से संबंधित एक bitmask होता है जिसे `status` कहा जाता है, जिसे kernel द्वारा सेट किया जाता है और जिनमें से कुछ को **code signature** द्वारा override किया जा सकता है। ये flags जो code signing में शामिल किए जा सकते हैं [defined in the code](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/osfmk/kern/cs_blobs.h#L36):
|
||||
```c
|
||||
/* code signing attributes of a process */
|
||||
#define CS_VALID 0x00000001 /* dynamically valid */
|
||||
@ -207,15 +212,15 @@ CS_RESTRICT | CS_ENFORCEMENT | CS_REQUIRE_LV | CS_RUNTIME | CS_LINKER_SIGNED)
|
||||
|
||||
#define CS_ENTITLEMENT_FLAGS (CS_GET_TASK_ALLOW | CS_INSTALLER | CS_DATAVAULT_CONTROLLER | CS_NVRAM_UNRESTRICTED)
|
||||
```
|
||||
ध्यान दें कि फ़ंक्शन [**exec_mach_imgact**](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/bsd/kern/kern_exec.c#L1420) कार्यान्वयन शुरू करते समय `CS_EXEC_*` फ़्लैग को गतिशील रूप से जोड़ सकता है।
|
||||
ध्यान दें कि फ़ंक्शन [**exec_mach_imgact**](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/bsd/kern/kern_exec.c#L1420) निष्पादन शुरू करते समय डायनामिक रूप से `CS_EXEC_*` फ्लैग भी जोड़ सकता है।
|
||||
|
||||
## कोड सिग्नेचर आवश्यकताएँ
|
||||
|
||||
प्रत्येक एप्लिकेशन कुछ **आवश्यकताएँ** संग्रहीत करता है जिन्हें इसे कार्यान्वित करने के लिए **पूरा करना** आवश्यक है। यदि **एप्लिकेशन में ऐसी आवश्यकताएँ हैं जो एप्लिकेशन द्वारा पूरी नहीं की गई हैं**, तो इसे कार्यान्वित नहीं किया जाएगा (क्योंकि इसे शायद संशोधित किया गया है)।
|
||||
प्रत्येक एप्लिकेशन कुछ **आवश्यकताएँ** संग्रहीत करता है जिन्हें निष्पादन योग्य होने के लिए **संतुष्ट** होना आवश्यक है। यदि एप्लिकेशन में मौजूद **आवश्यकताएँ** संतुष्ट नहीं होतीं, तो इसे निष्पादित नहीं किया जाएगा (क्योंकि संभवतः इसे बदल दिया गया है)।
|
||||
|
||||
एक बाइनरी की आवश्यकताएँ एक **विशेष व्याकरण** का उपयोग करती हैं जो **व्यक्तियों** की एक धारा होती है और इन्हें `0xfade0c00` को जादू के रूप में उपयोग करके ब्लॉब के रूप में एन्कोड किया जाता है, जिसका **हैश एक विशेष कोड स्लॉट में संग्रहीत होता है**।
|
||||
किसी बाइनरी की आवश्यकताएँ एक **विशेष व्याकरण** का उपयोग करती हैं जो **अभिव्यक्तियों** की एक धारा है और इन्हें ब्लॉब्स के रूप में एन्कोड किया जाता है जो `0xfade0c00` को magic के रूप में उपयोग करते हैं, जिसका **हैश एक विशेष कोड स्लॉट में संग्रहीत** होता है।
|
||||
|
||||
एक बाइनरी की आवश्यकताएँ चलाते समय देखी जा सकती हैं:
|
||||
किसी बाइनरी की आवश्यकताओं को निष्पादन के समय देखा जा सकता है:
|
||||
```bash
|
||||
codesign -d -r- /bin/ls
|
||||
Executable=/bin/ls
|
||||
@ -225,10 +230,10 @@ codesign -d -r- /Applications/Signal.app/
|
||||
Executable=/Applications/Signal.app/Contents/MacOS/Signal
|
||||
designated => identifier "org.whispersystems.signal-desktop" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = U68MSDN6DR
|
||||
```
|
||||
> [!NOTE]
|
||||
> ध्यान दें कि ये सिग्नेचर प्रमाणन जानकारी, TeamID, IDs, अधिकार और कई अन्य डेटा जैसी चीजों की जांच कर सकते हैं।
|
||||
> [!TIP]
|
||||
> ध्यान दें कि ये signatures प्रमाणपत्र जानकारी, TeamID, IDs, entitlements और कई अन्य डेटा जैसी चीज़ों की जाँच कर सकते हैं।
|
||||
|
||||
इसके अलावा, `csreq` टूल का उपयोग करके कुछ संकलित आवश्यकताएँ उत्पन्न करना संभव है:
|
||||
इसके अलावा, `csreq` टूल का उपयोग करके कुछ compiled requirements बनाना संभव है:
|
||||
```bash
|
||||
# Generate compiled requirements
|
||||
csreq -b /tmp/output.csreq -r='identifier "org.whispersystems.signal-desktop" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = U68MSDN6DR'
|
||||
@ -240,57 +245,57 @@ od -A x -t x1 /tmp/output.csreq
|
||||
0000020 00 00 00 21 6f 72 67 2e 77 68 69 73 70 65 72 73
|
||||
[...]
|
||||
```
|
||||
यह जानकारी प्राप्त करना और `Security.framework` के कुछ APIs के साथ आवश्यकताओं को बनाना या संशोधित करना संभव है जैसे:
|
||||
यह जानकारी एक्सेस करना और `Security.framework` के कुछ APIs के माध्यम से requirements बनाना या संशोधित करना संभव है, जैसे:
|
||||
|
||||
#### **वैधता की जांच करना**
|
||||
#### **वैधता की जाँच**
|
||||
|
||||
- **`Sec[Static]CodeCheckValidity`**: आवश्यकता के अनुसार SecCodeRef की वैधता की जांच करें।
|
||||
- **`SecRequirementEvaluate`**: प्रमाणपत्र संदर्भ में आवश्यकता को मान्य करें।
|
||||
- **`SecTaskValidateForRequirement`**: `CFString` आवश्यकता के खिलाफ चल रहे SecTask को मान्य करें।
|
||||
- **`Sec[Static]CodeCheckValidity`**: SecCodeRef की वैधता Requirement के अनुसार जाँचें।
|
||||
- **`SecRequirementEvaluate`**: प्रमाणपत्र संदर्भ (certificate context) में Requirement को मान्य करें।
|
||||
- **`SecTaskValidateForRequirement`**: चल रहे SecTask को `CFString` requirement के विरुद्ध मान्य करें।
|
||||
|
||||
#### **कोड आवश्यकताओं का निर्माण और प्रबंधन**
|
||||
#### **Code Requirements बनाना और प्रबंधित करना**
|
||||
|
||||
- **`SecRequirementCreateWithData`:** आवश्यकता का प्रतिनिधित्व करने वाले बाइनरी डेटा से `SecRequirementRef` बनाता है।
|
||||
- **`SecRequirementCreateWithString`:** आवश्यकता के स्ट्रिंग अभिव्यक्ति से `SecRequirementRef` बनाता है।
|
||||
- **`SecRequirementCreateWithData`:** Requirement का प्रतिनिधित्व करने वाले बाइनरी डेटा से `SecRequirementRef` बनाता है।
|
||||
- **`SecRequirementCreateWithString`:** Requirement के स्ट्रिंग एक्सप्रेशन से `SecRequirementRef` बनाता है।
|
||||
- **`SecRequirementCopy[Data/String]`**: `SecRequirementRef` का बाइनरी डेटा प्रतिनिधित्व प्राप्त करता है।
|
||||
- **`SecRequirementCreateGroup`**: ऐप-ग्रुप सदस्यता के लिए एक आवश्यकता बनाएं।
|
||||
- **`SecRequirementCreateGroup`**: app-group सदस्यता के लिए requirement बनाता है।
|
||||
|
||||
#### **कोड साइनिंग जानकारी तक पहुंचना**
|
||||
#### **Code Signing जानकारी तक पहुँच**
|
||||
|
||||
- **`SecStaticCodeCreateWithPath`**: कोड सिग्नेचर का निरीक्षण करने के लिए फ़ाइल सिस्टम पथ से `SecStaticCodeRef` ऑब्जेक्ट प्रारंभ करता है।
|
||||
- **`SecStaticCodeCreateWithPath`**: कोड सिग्नेचर inspect करने के लिए फाइल सिस्टम पाथ से `SecStaticCodeRef` ऑब्जेक्ट इनिशियलाइज़ करता है।
|
||||
- **`SecCodeCopySigningInformation`**: `SecCodeRef` या `SecStaticCodeRef` से साइनिंग जानकारी प्राप्त करता है।
|
||||
|
||||
#### **कोड आवश्यकताओं को संशोधित करना**
|
||||
#### **Code Requirements संशोधित करना**
|
||||
|
||||
- **`SecCodeSignerCreate`**: कोड साइनिंग संचालन करने के लिए `SecCodeSignerRef` ऑब्जेक्ट बनाता है।
|
||||
- **`SecCodeSignerSetRequirement`**: साइनिंग के दौरान लागू करने के लिए कोड साइनर के लिए एक नई आवश्यकता सेट करता है।
|
||||
- **`SecCodeSignerAddSignature`**: निर्दिष्ट साइनर के साथ साइन किए जा रहे कोड में एक सिग्नेचर जोड़ता है।
|
||||
- **`SecCodeSignerCreate`**: कोड साइनिंग ऑपरेशन के लिए `SecCodeSignerRef` ऑब्जेक्ट बनाता है।
|
||||
- **`SecCodeSignerSetRequirement`**: साइनिंग के दौरान लागू करने के लिए कोड साइनर के लिए नया requirement सेट करता है।
|
||||
- **`SecCodeSignerAddSignature`**: निर्दिष्ट signer के साथ साइन किए जा रहे कोड में सिग्नेचर जोड़ता है।
|
||||
|
||||
#### **आवश्यकताओं के साथ कोड को मान्य करना**
|
||||
#### **Requirements के साथ कोड को मान्य करना**
|
||||
|
||||
- **`SecStaticCodeCheckValidity`**: निर्दिष्ट आवश्यकताओं के खिलाफ एक स्थिर कोड ऑब्जेक्ट को मान्य करता है।
|
||||
- **`SecStaticCodeCheckValidity`**: निर्दिष्ट requirements के खिलाफ static code ऑब्जेक्ट को मान्य करता है।
|
||||
|
||||
#### **अतिरिक्त उपयोगी APIs**
|
||||
#### **अन्य उपयोगी APIs**
|
||||
|
||||
- **`SecCodeCopy[Internal/Designated]Requirement`: SecCodeRef से SecRequirementRef प्राप्त करें**
|
||||
- **`SecCodeCopyGuestWithAttributes`**: विशिष्ट विशेषताओं के आधार पर कोड ऑब्जेक्ट का प्रतिनिधित्व करने वाला `SecCodeRef` बनाता है, जो सैंडबॉक्सिंग के लिए उपयोगी है।
|
||||
- **`SecCodeCopyPath`**: `SecCodeRef` से संबंधित फ़ाइल सिस्टम पथ प्राप्त करता है।
|
||||
- **`SecCodeCopySigningIdentifier`**: `SecCodeRef` से साइनिंग पहचानकर्ता (जैसे, टीम आईडी) प्राप्त करता है।
|
||||
- **`SecCodeGetTypeID`**: `SecCodeRef` ऑब्जेक्ट के लिए प्रकार पहचानकर्ता लौटाता है।
|
||||
- **`SecCodeCopy[Internal/Designated]Requirement`: Get SecRequirementRef from SecCodeRef**
|
||||
- **`SecCodeCopyGuestWithAttributes`**: विशिष्ट attributes के आधार पर कोड ऑब्जेक्ट को दर्शाने वाला `SecCodeRef` बनाता है, sandboxing के लिए उपयोगी।
|
||||
- **`SecCodeCopyPath`**: `SecCodeRef` से संबंधित फाइल सिस्टम पाथ प्राप्त करता है।
|
||||
- **`SecCodeCopySigningIdentifier`**: `SecCodeRef` से signing identifier (उदा., Team ID) प्राप्त करता है।
|
||||
- **`SecCodeGetTypeID`**: `SecCodeRef` ऑब्जेक्ट्स के लिए type identifier लौटाता है।
|
||||
- **`SecRequirementGetTypeID`**: `SecRequirementRef` का CFTypeID प्राप्त करता है।
|
||||
|
||||
#### **कोड साइनिंग फ्लैग और स्थिरांक**
|
||||
#### **Code Signing फ्लैग्स और कॉन्स्टैंट्स**
|
||||
|
||||
- **`kSecCSDefaultFlags`**: कोड साइनिंग संचालन के लिए कई Security.framework कार्यों में उपयोग किए जाने वाले डिफ़ॉल्ट फ्लैग।
|
||||
- **`kSecCSSigningInformation`**: फ्लैग जो यह निर्दिष्ट करने के लिए उपयोग किया जाता है कि साइनिंग जानकारी प्राप्त की जानी चाहिए।
|
||||
- **`kSecCSDefaultFlags`**: कोड साइनिंग ऑपरेशनों के लिए कई Security.framework फंक्शन्स में उपयोग होने वाले डिफ़ॉल्ट फ्लैग्स।
|
||||
- **`kSecCSSigningInformation`**: यह फ्लैग यह निर्दिष्ट करने के लिए उपयोग होता है कि साइनिंग जानकारी प्राप्त की जानी चाहिए।
|
||||
|
||||
## कोड सिग्नेचर प्रवर्तन
|
||||
## कोड सिग्नेचर लागू करना (Code Signature Enforcement)
|
||||
|
||||
**कर्नेल** वह है जो **कोड सिग्नेचर की जांच करता है** इससे पहले कि ऐप का कोड निष्पादित हो सके। इसके अलावा, मेमोरी में नए कोड को लिखने और निष्पादित करने के लिए एक तरीका JIT का दुरुपयोग करना है यदि `mprotect` को `MAP_JIT` फ्लैग के साथ कॉल किया जाता है। ध्यान दें कि एप्लिकेशन को ऐसा करने के लिए एक विशेष अधिकार की आवश्यकता होती है।
|
||||
**कर्नेल** वह घटक है जो ऐप के कोड को निष्पादित करने की अनुमति देने से पहले **कोड सिग्नेचर की जाँच** करता है। इसके अलावा, मेमोरी में नया कोड लिखने और निष्पादित करने में सक्षम होने का एक तरीका JIT का दुरुपयोग करना है यदि `mprotect` को `MAP_JIT` फ्लैग के साथ कॉल किया जाए। ध्यान दें कि इसको करने के लिए एप्लिकेशन को एक विशेष entitlement की आवश्यकता होती है।
|
||||
|
||||
## `cs_blobs` & `cs_blob`
|
||||
|
||||
[**cs_blob**](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/bsd/sys/ubc_internal.h#L106) संरचना में चल रहे प्रक्रिया के अधिकार के बारे में जानकारी होती है। `csb_platform_binary` यह भी सूचित करता है कि क्या एप्लिकेशन एक प्लेटफ़ॉर्म बाइनरी है (जिसकी जांच OS द्वारा विभिन्न क्षणों में सुरक्षा तंत्र लागू करने के लिए की जाती है जैसे कि इन प्रक्रियाओं के कार्य पोर्ट के लिए SEND अधिकारों की रक्षा करना)।
|
||||
[**cs_blob**](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/bsd/sys/ubc_internal.h#L106) struct उस पर चल रहे प्रोसेस के entitlement के बारे में जानकारी रखता है। `csb_platform_binary` यह भी बताता है कि एप्लिकेशन एक platform binary है या नहीं (जिसे OS विभिन्न समयों पर जाँचता है ताकि सुरक्षा तंत्र लागू किये जा सकें, जैसे इन प्रोसेसेस के task ports के SEND rights की रक्षा करना)।
|
||||
```c
|
||||
struct cs_blob {
|
||||
struct cs_blob *csb_next;
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user