maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/generic-methodologies-and-resources/basic-forensic-meth

Browse Source
This commit is contained in:
Translator 2025-10-01 01:54:36 +00:00
parent b7a7e5ece0
commit 486a72aa67
5 changed files with 439 additions and 210 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
src/SUMMARY.md
View File

@ -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) - [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) - [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) - [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) - [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) - [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) - [PNG tricks](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/png-tricks.md)

9
src/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/README.md
View File

@ -1,8 +1,8 @@
# Spesifieke sagteware-/lêertipe-truuks # Spesifieke Sagteware/Lêertipe Trikke
{{#include ../../../banners/hacktricks-training.md}} {{#include ../../../banners/hacktricks-training.md}}
Hier kan jy interessante truuks vir spesifieke lêertipes en/of sagteware vind: Hier kan jy interessante trikke vir spesifieke lêertipes en/of sagteware vind:
{{#ref}} {{#ref}}
@ -54,4 +54,9 @@ video-and-audio-file-analysis.md
zips-tricks.md zips-tricks.md
{{#endref}} {{#endref}}
{{#ref}}
mach-o-entitlements-and-ipsw-indexing.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}} {{#include ../../../banners/hacktricks-training.md}}

213
src/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/mach-o-entitlements-and-ipsw-indexing.md Normal file
View File

@ -0,0 +1,213 @@
# Mach-O Entitlements Extraction & IPSW Indexing
{{#include ../../../banners/hacktricks-training.md}}
## Oorsig
Hierdie bladsy behandel hoe om entitlements uit Mach-O binaries programmaties te onttrek deur LC_CODE_SIGNATURE te deurloop en die code signing SuperBlob te ontleed, en hoe om dit op te skaal oor Apple IPSW firmwares deur hul inhoud te mount en te indekseer vir forensiese soektog/vergelyking.
As jy 'n opfrisser nodig het oor Mach-O formaat en code signing, sien ook: macOS code signing and SuperBlob internals.
- Kyk na macOS code signing besonderhede (SuperBlob, Code Directory, special slots): [macOS Code Signing](../../../macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-code-signing.md)
- Kyk na algemene Mach-O strukture/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)
## Entitlements in Mach-O: waar hulle geleë is
Entitlements word gestoor binne die code signature data wat deur die LC_CODE_SIGNATURE load command verwys word en geplaas in die __LINKEDIT segment. Die signature is 'n CS_SuperBlob wat meerdere blobs bevat (code directory, requirements, entitlements, CMS, ens.). Die entitlements blob is 'n CS_GenericBlob waarvan die data 'n Apple Binary Property List (bplist00) is wat entitlement-sleutels na waardes map.
Sleutelstrukture (van 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;
```
Belangrike konstantes:
- 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
Let wel: Multi-arch (fat) binaries bevat meerdere Mach-O slices. Jy moet die slice vir die argitektuur wat jy wil inspekteer kies en dan sy load commands deurloop.
## Uittrekselstappe (generies, genoegsaam verliesloos)
1) Ontleed die Mach-O header; itereer oor ncmds load_command rekords.
2) Vind LC_CODE_SIGNATURE; lees linkedit_data_command.dataoff/datasize om die Code Signing SuperBlob in __LINKEDIT te map.
3) Valideer CS_SuperBlob.magic == 0xfade0cc0; itereer deur die count inskrywings van CS_BlobIndex.
4) Vind index.type == 0xfade7171 (embedded entitlements). Lees die aangeduide CS_GenericBlob en parse sy data as 'n Apple binary plist (bplist00) na sleutel/waarde entitlements.
Implementasienotas:
- Code signature structures gebruik big-endian fields; ruil die byte volgorde wanneer jy op little-endian hosts parse.
- Die entitlements GenericBlob data self is 'n binary plist (hanteer deur standaard plist-biblioteke).
- Sommige iOS binaries kan DER entitlements dra; ook verskil sommige stores/slots oor platforms/weergawe. Kontroleer beide standaard en DER entitlements soos nodig.
- Vir fat binaries, gebruik die fat headers (FAT_MAGIC/FAT_MAGIC_64) om die korrekte slice en offset te vind voordat jy die Mach-O load commands deurloop.
## Minimale parsing-opsomming (Python)
Die volgende is 'n beknopte opsomming wat die beheervloei toon om entitlements te vind en te decodeer. Dit laat doelbewus robuuste bounds checks en volledige fat binary ondersteuning uit ter wille van beknoptheid.
```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
```
Gebruikswenke:
- To handle fat binaries, first read struct fat_header/fat_arch, choose the desired architecture slice, then pass the subrange to parse_entitlements.
- Op macOS kan jy resultate valideer met: codesign -d --entitlements :- /path/to/binary
## Voorbeeldbevindinge
Privileged platform binaries vra dikwels vir sensitiewe entitlements soos:
- 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"]
Om hierna op skaal oor firmware images te soek is uiters waardevol vir attack surface mapping en diffing oor weergawes/toestelle.
## Opskaal oor IPSWs (mounting and indexing)
Om executables te enumereer en entitlements op skaal te onttrek sonder om volledige images te stoor:
- Gebruik die ipsw tool deur @blacktop om firmware filesystems af te laai en te mount. Mounting maak gebruik van apfs-fuse, sodat jy APFS-volumes kan deurkruis sonder volledige ekstraksie.
```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>
```
- Loop deur gemonteerde volumes om Mach-O files te lokaliseer (kontroleer magic en/of gebruik file/otool), en ontleed dan entitlements en imported frameworks.
- Bêre 'n genormaliseerde aansig in 'n relationele databasis om lineêre groei oor duisende IPSWs te vermy:
- executables, operating_system_versions, entitlements, frameworks
- veel-tot-veel: executable↔OS version, executable↔entitlement, executable↔framework
Voorbeeld navraag om alle OS versions te lys wat 'n gegewe executable naam bevat:
```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";
```
Aantekeninge oor DB-draagbaarheid (as jy jou eie indekser implementeer):
- Gebruik 'n ORM/abstraksie (bv. SeaORM) om kode DB-agnosties te hou (SQLite/PostgreSQL).
- SQLite vereis AUTOINCREMENT slegs op 'n INTEGER PRIMARY KEY; as jy i64 PKs in Rust wil hê, genereer entiteite as i32 en converteer tipes, SQLite stoor INTEGER intern as 8-byte signed.
## Open-source tooling and references for entitlement hunting
- Firmware mount/aflaai: https://github.com/blacktop/ipsw
- Entitlement databasisse en verwysings:
- Jonathan Levin se entitlement DB: https://newosxbook.com/ent.php
- entdb: https://github.com/ChiChou/entdb
- Grootskaalse indekser (Rust, self-hosted Web UI + OpenAPI): https://github.com/synacktiv/appledb_rs
- Apple headers vir strukture en konstantes:
- loader.h (Mach-O headers, load commands)
- cs_blobs.h (SuperBlob, GenericBlob, CodeDirectory)
Vir meer oor code signing internals (Code Directory, special slots, DER entitlements), sien: [macOS Code Signing](../../../macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-code-signing.md)
## Verwysings
- [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}}

293
src/macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/universal-binaries-and-mach-o-format.md
View File

@ -1,78 +1,78 @@
# macOS Universele binêre & Mach-O Formaat # macOS Universal binaries & Mach-O Format
{{#include ../../../banners/hacktricks-training.md}} {{#include ../../../banners/hacktricks-training.md}}
## Basiese Inligting ## Basiese Inligting
Mac OS binêre word gewoonlik saamgekompileer as **universele binêre**. 'n **universale binêre** kan **meerdere argitekture in dieselfde lêer ondersteun**. Mac OS-binaries word gewoonlik as **universal binaries** gekompileer. 'n **universal binary** kan **verskeie argitekture in dieselfde lêer ondersteun**.
Hierdie binêre volg die **Mach-O struktuur** wat basies bestaan uit: Hierdie binaries volg die **Mach-O structure**, wat basies bestaan uit:
- Kop - Header
- Laai Opdragte - Load Commands
- Data - Data
![https://alexdremov.me/content/images/2022/10/6XLCD.gif](<../../../images/image (470).png>) ![https://alexdremov.me/content/images/2022/10/6XLCD.gif](<../../../images/image (470).png>)
## Vet Kop ## Fat Header
Soek vir die lêer met: `mdfind fat.h | grep -i mach-o | grep -E "fat.h$"` Soek die lêer met: `mdfind fat.h | grep -i mach-o | grep -E "fat.h$"`
<pre class="language-c"><code class="lang-c"><strong>#define FAT_MAGIC 0xcafebabe <pre class="language-c"><code class="lang-c"><strong>#define FAT_MAGIC 0xcafebabe
</strong><strong>#define FAT_CIGAM 0xbebafeca /* NXSwapLong(FAT_MAGIC) */ </strong><strong>#define FAT_CIGAM 0xbebafeca /* NXSwapLong(FAT_MAGIC) */
</strong> </strong>
struct fat_header { struct fat_header {
<strong> uint32_t magic; /* FAT_MAGIC of FAT_MAGIC_64 */ <strong> uint32_t magic; /* FAT_MAGIC or FAT_MAGIC_64 */
</strong><strong> uint32_t nfat_arch; /* aantal strukture wat volg */ </strong><strong> uint32_t nfat_arch; /* number of structs that follow */
</strong>}; </strong>};
struct fat_arch { struct fat_arch {
cpu_type_t cputype; /* cpu spesifiseerder (int) */ cpu_type_t cputype; /* cpu specifier (int) */
cpu_subtype_t cpusubtype; /* masjien spesifiseerder (int) */ cpu_subtype_t cpusubtype; /* machine specifier (int) */
uint32_t offset; /* lêer offset na hierdie objek lêer */ uint32_t offset; /* file offset to this object file */
uint32_t size; /* grootte van hierdie objek lêer */ uint32_t size; /* size of this object file */
uint32_t align; /* uitlijning as 'n mag van 2 */ uint32_t align; /* alignment as a power of 2 */
}; };
</code></pre> </code></pre>
Die kop het die **magiese** bytes gevolg deur die **aantal** **argitekture** wat die lêer **bevat** (`nfat_arch`) en elke argitektuur sal 'n `fat_arch` struktuur hê. Die header bevat die **magic** bytes gevolg deur die **aantal** **archs** wat die lêer **bevat** (`nfat_arch`) en elke arch sal 'n `fat_arch`-struktuur hê.
Kontroleer dit met: Kontroleer dit met:
<pre class="language-shell-session"><code class="lang-shell-session">% file /bin/ls <pre class="language-shell-session"><code class="lang-shell-session">% file /bin/ls
/bin/ls: Mach-O universele binêre met 2 argitekture: [x86_64:Mach-O 64-bit uitvoerbare x86_64] [arm64e:Mach-O 64-bit uitvoerbare 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 (vir argitektuur x86_64): Mach-O 64-bit uitvoerbare x86_64 /bin/ls (for architecture x86_64): Mach-O 64-bit executable x86_64
/bin/ls (vir argitektuur arm64e): Mach-O 64-bit uitvoerbare arm64e /bin/ls (for architecture arm64e): Mach-O 64-bit executable arm64e
% otool -f -v /bin/ls % otool -f -v /bin/ls
Vet koppe Fat headers
fat_magic FAT_MAGIC fat_magic FAT_MAGIC
<strong>nfat_arch 2 <strong>nfat_arch 2
</strong><strong>argitektuur x86_64 </strong><strong>architecture x86_64
</strong> cputype CPU_TYPE_X86_64 </strong> cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL cpusubtype CPU_SUBTYPE_X86_64_ALL
capabilities 0x0 capabilities 0x0
<strong> offset 16384 <strong> offset 16384
</strong><strong> grootte 72896 </strong><strong> size 72896
</strong> uitlijning 2^14 (16384) </strong> align 2^14 (16384)
<strong>argitektuur arm64e <strong>architecture arm64e
</strong> cputype CPU_TYPE_ARM64 </strong> cputype CPU_TYPE_ARM64
cpusubtype CPU_SUBTYPE_ARM64E cpusubtype CPU_SUBTYPE_ARM64E
capabilities PTR_AUTH_VERSION USERSPACE 0 capabilities PTR_AUTH_VERSION USERSPACE 0
<strong> offset 98304 <strong> offset 98304
</strong><strong> grootte 88816 </strong><strong> size 88816
</strong> uitlijning 2^14 (16384) </strong> align 2^14 (16384)
</code></pre> </code></pre>
of deur die [Mach-O View](https://sourceforge.net/projects/machoview/) hulpmiddel te gebruik: of deur die [Mach-O View](https://sourceforge.net/projects/machoview/) gereedskap te gebruik:
<figure><img src="../../../images/image (1094).png" alt=""><figcaption></figcaption></figure> <figure><img src="../../../images/image (1094).png" alt=""><figcaption></figcaption></figure>
Soos jy dalk dink, verdubbel 'n universele binêre wat saamgekompileer is vir 2 argitekture gewoonlik die grootte van een wat net vir 1 argitektuur saamgekompileer is. Soos jy dalk dink, 'n universal binary wat vir 2 argitekture gekompileer is, **verdubbel gewoonlik die grootte** van een wat slegs vir 1 arch gekompileer is.
## **Mach-O Kop** ## **Mach-O Header**
Die kop bevat basiese inligting oor die lêer, soos magiese bytes om dit as 'n Mach-O lêer te identifiseer en inligting oor die teikenargitektuur. Jy kan dit vind in: `mdfind loader.h | grep -i mach-o | grep -E "loader.h$"` Die header bevat basiese inligting oor die lêer, soos magic bytes om dit as 'n Mach-O-lêer te identifiseer en inligting oor die teiken-argitektuur. Jy kan dit vind in: `mdfind loader.h | grep -i mach-o | grep -E "loader.h$"`
```c ```c
#define MH_MAGIC 0xfeedface /* the mach magic number */ #define MH_MAGIC 0xfeedface /* the mach magic number */
#define MH_CIGAM 0xcefaedfe /* NXSwapInt(MH_MAGIC) */ #define MH_CIGAM 0xcefaedfe /* NXSwapInt(MH_MAGIC) */
@ -99,20 +99,20 @@ uint32_t flags; /* flags */
uint32_t reserved; /* reserved */ uint32_t reserved; /* reserved */
}; };
``` ```
### Mach-O Lêertipes ### Mach-O lêer-tipes
Daar is verskillende lêertipes, jy kan hulle gedefinieer vind in die [**bronkode byvoorbeeld hier**](https://opensource.apple.com/source/xnu/xnu-2050.18.24/EXTERNAL_HEADERS/mach-o/loader.h). Die belangrikste is: Daar is verskillende lêertipes; jy kan hulle gedefinieer vind in die [**source code for example here**](https://opensource.apple.com/source/xnu/xnu-2050.18.24/EXTERNAL_HEADERS/mach-o/loader.h). Die belangrikste is:
- `MH_OBJECT`: Herlokasiebare objeklêer (tussenprodukte van kompilasie, nog nie uitvoerbaar nie). - `MH_OBJECT`: Verplaasbare objeklêer (tussenprodukte van samestelling, nog nie uitvoerbare lêers nie).
- `MH_EXECUTE`: Uitvoerbare lêers. - `MH_EXECUTE`: Uitvoerbare lêers.
- `MH_FVMLIB`: Vaste VM-biblioteeklêer. - `MH_FVMLIB`: Vaste VM-biblioteeklêer.
- `MH_CORE`: Kode-dumps - `MH_CORE`: Kode-dumps
- `MH_PRELOAD`: Vooraf gelaaide uitvoerbare lêer (nie meer ondersteun in XNU nie) - `MH_PRELOAD`: Voorafgelaaide uitvoerbare lêer (nie meer deur XNU ondersteun nie)
- `MH_DYLIB`: Dinamiese biblioteke - `MH_DYLIB`: Dinamiese biblioteke
- `MH_DYLINKER`: Dinamiese skakelaar - `MH_DYLINKER`: Dinamiese linker
- `MH_BUNDLE`: "Pluginlêers". Genereer met -bundle in gcc en eksplisiet gelaai deur `NSBundle` of `dlopen`. - `MH_BUNDLE`: "Plugin-lêers". Gegenereer met -bundle in gcc en eksplisiet gelaai deur `NSBundle` of `dlopen`.
- `MH_DYSM`: Metgesel `.dSym` lêer (lêer met simbole vir foutopsporing). - `MH_DYSM`: Geselskap `.dSym`-lêer (lêer met simbole vir foutopsporing).
- `MH_KEXT_BUNDLE`: Kernel-uitbreidings. - `MH_KEXT_BUNDLE`: Kernuitbreidings.
```bash ```bash
# Checking the mac header of a binary # Checking the mac header of a binary
otool -arch arm64e -hv /bin/ls otool -arch arm64e -hv /bin/ls
@ -124,71 +124,71 @@ Of deur [Mach-O View](https://sourceforge.net/projects/machoview/) te gebruik:
<figure><img src="../../../images/image (1133).png" alt=""><figcaption></figcaption></figure> <figure><img src="../../../images/image (1133).png" alt=""><figcaption></figcaption></figure>
## **Mach-O Vlaggies** ## **Mach-O vlae**
Die bronkode definieer ook verskeie vlaggies wat nuttig is vir die laai van biblioteke: Die bronkode definieer ook verskeie vlae wat nuttig is vir die laai van biblioteke:
- `MH_NOUNDEFS`: Geen ongedefinieerde verwysings nie (volledig gekoppel) - `MH_NOUNDEFS`: No undefined references (fully linked)
- `MH_DYLDLINK`: Dyld-koppeling - `MH_DYLDLINK`: Dyld linking
- `MH_PREBOUND`: Dinamiese verwysings vooraf gekoppel. - `MH_PREBOUND`: Dynamic references prebound.
- `MH_SPLIT_SEGS`: Lêer verdeel r/o en r/w segmente. - `MH_SPLIT_SEGS`: File splits r/o and r/w segments.
- `MH_WEAK_DEFINES`: Binêre het swak gedefinieerde simbole - `MH_WEAK_DEFINES`: Binary has weak defined symbols
- `MH_BINDS_TO_WEAK`: Binêre gebruik swak simbole - `MH_BINDS_TO_WEAK`: Binary uses weak symbols
- `MH_ALLOW_STACK_EXECUTION`: Maak die stapel uitvoerbaar - `MH_ALLOW_STACK_EXECUTION`: Make the stack executable
- `MH_NO_REEXPORTED_DYLIBS`: Biblioteek het nie LC_REEXPORT opdragte nie - `MH_NO_REEXPORTED_DYLIBS`: Library not LC_REEXPORT commands
- `MH_PIE`: Posisie Onafhanklike Uitvoerbare - `MH_PIE`: Position Independent Executable
- `MH_HAS_TLV_DESCRIPTORS`: Daar is 'n afdeling met draad plaaslike veranderlikes - `MH_HAS_TLV_DESCRIPTORS`: There is a section with thread local variables
- `MH_NO_HEAP_EXECUTION`: Geen uitvoering vir heap/data bladsye nie - `MH_NO_HEAP_EXECUTION`: No execution for heap/data pages
- `MH_HAS_OBJC`: Binêre het oBject-C afdelings - `MH_HAS_OBJC`: Binary has oBject-C sections
- `MH_SIM_SUPPORT`: Simulator ondersteuning - `MH_SIM_SUPPORT`: Simulator support
- `MH_DYLIB_IN_CACHE`: Gebruik op dylibs/raamwerke in gedeelde biblioteek kas. - `MH_DYLIB_IN_CACHE`: Used on dylibs/frameworks in shared library cache.
## **Mach-O Laai opdragte** ## **Mach-O Laai-opdragte**
Die **lêer se uitleg in geheue** word hier gespesifiseer, wat die **simbol tabel se ligging**, die konteks van die hoofdraad by uitvoering begin, en die vereiste **gedeelde biblioteke** detail. Instruksies word aan die dinamiese laaier **(dyld)** gegee oor die binêre se laai proses in geheue. Die lêer se uitleg in geheue word hier gespesifiseer, en beskryf die ligging van die simbooltabel, die konteks van die hoofdraad by die begin van uitvoering, en die vereiste gedeelde biblioteke. Instruksies word aan die dinamiese laaier (dyld) gegee oor die proses om die binêr in geheue te laai.
Die gebruik die **load_command** struktuur, gedefinieer in die genoemde **`loader.h`**: Dit gebruik die `load_command`-struktuur, gedefinieer in die genoemde `loader.h`:
```objectivec ```objectivec
struct load_command { struct load_command {
uint32_t cmd; /* type of load command */ uint32_t cmd; /* type of load command */
uint32_t cmdsize; /* total size of command in bytes */ uint32_t cmdsize; /* total size of command in bytes */
}; };
``` ```
Daar is ongeveer **50 verskillende tipes laaiopdragte** wat die stelsel anders hanteer. Die mees algemene is: `LC_SEGMENT_64`, `LC_LOAD_DYLINKER`, `LC_MAIN`, `LC_LOAD_DYLIB`, en `LC_CODE_SIGNATURE`. Daar is omtrent **50 verskillende soorte load commands** wat die stelsel op verskillende maniere hanteer. Die mees algemene is: `LC_SEGMENT_64`, `LC_LOAD_DYLINKER`, `LC_MAIN`, `LC_LOAD_DYLIB`, and `LC_CODE_SIGNATURE`.
### **LC_SEGMENT/LC_SEGMENT_64** ### **LC_SEGMENT/LC_SEGMENT_64**
> [!TIP] > [!TIP]
> Basies definieer hierdie tipe Laaiopdrag **hoe om die \_\_TEXT** (uitvoerbare kode) **en \_\_DATA** (data vir die proses) **segmente** te laai volgens die **offsets wat in die Data afdeling aangedui word** wanneer die binêre uitgevoer word. > Basies definieer hierdie tipe Load Command **hoe om die \_\_TEXT** (uitvoerbare kode) **en \_\_DATA** (data vir die proses) **segmente te laai** volgens die **offsets aangedui in die Data section** wanneer die binary uitgevoer word.
Hierdie opdragte **definieer segmente** wat in die **virtuele geheue ruimte** van 'n proses gemap word wanneer dit uitgevoer word. Hierdie commands **definieer segment** wat **gemap** word in die **virtuele geheue-ruimte** van 'n proses wanneer dit uitgevoer word.
Daar is **verskillende tipes** segmente, soos die **\_\_TEXT** segment, wat die uitvoerbare kode van 'n program bevat, en die **\_\_DATA** segment, wat data bevat wat deur die proses gebruik word. Hierdie **segmente is geleë in die data afdeling** van die Mach-O lêer. Daar is **verskillende tipes** segment, soos die **\_\_TEXT** segment, wat die uitvoerbare kode van 'n program bevat, en die **\_\_DATA** segment, wat data bevat wat deur die proses gebruik word. Hierdie **segmente lê in die data section** van die Mach-O lêer.
**Elke segment** kan verder in meerdere **afdelings** **verdeeld** word. Die **laaiopdragstruktuur** bevat **inligting** oor **hierdie afdelings** binne die onderskeie segment. **Elke segment** kan verder **verdeeld** word in meerdere **sections**. Die **load command structure** bevat **inligting** oor **hierdie sections** binne die betrokke segment.
In die kop vind jy eers die **segmentkop**: In die header vind jy eers die **segment header**:
<pre class="language-c"><code class="lang-c">struct segment_command_64 { /* vir 64-bis argitekture */ <pre class="language-c"><code class="lang-c">struct segment_command_64 { /* for 64-bit architectures */
uint32_t cmd; /* LC_SEGMENT_64 */ uint32_t cmd; /* LC_SEGMENT_64 */
uint32_t cmdsize; /* sluit sizeof section_64 strukture in */ uint32_t cmdsize; /* includes sizeof section_64 structs */
char segname[16]; /* segmentnaam */ char segname[16]; /* segment name */
uint64_t vmaddr; /* geheueadres van hierdie segment */ uint64_t vmaddr; /* memory address of this segment */
uint64_t vmsize; /* geheuegrootte van hierdie segment */ uint64_t vmsize; /* memory size of this segment */
uint64_t fileoff; /* lêer offset van hierdie segment */ uint64_t fileoff; /* file offset of this segment */
uint64_t filesize; /* hoeveelheid om van die lêer te map */ uint64_t filesize; /* amount to map from the file */
int32_t maxprot; /* maksimum VM beskerming */ int32_t maxprot; /* maximum VM protection */
int32_t initprot; /* aanvanklike VM beskerming */ int32_t initprot; /* initial VM protection */
<strong> uint32_t nsects; /* aantal afdelings in segment */ <strong> uint32_t nsects; /* number of sections in segment */
</strong> uint32_t flags; /* vlae */ </strong> uint32_t flags; /* flags */
}; };
</code></pre> </code></pre>
Voorbeeld van segmentkop: Voorbeeld van 'n segment header:
<figure><img src="../../../images/image (1126).png" alt=""><figcaption></figcaption></figure> <figure><img src="../../../images/image (1126).png" alt=""><figcaption></figcaption></figure>
Hierdie kop definieer die **aantal afdelings waarvan die koppe na** dit verskyn: Hierdie header definieer die **aantal sections wie se headers daarna verskyn**:
```c ```c
struct section_64 { /* for 64-bit architectures */ struct section_64 { /* for 64-bit architectures */
char sectname[16]; /* name of this section */ char sectname[16]; /* name of this section */
@ -205,62 +205,62 @@ uint32_t reserved2; /* reserved (for count or sizeof) */
uint32_t reserved3; /* reserved */ uint32_t reserved3; /* reserved */
}; };
``` ```
Voorbeeld van **afdelingskop**: Voorbeeld van **afdelingsopskrif**:
<figure><img src="../../../images/image (1108).png" alt=""><figcaption></figcaption></figure> <figure><img src="../../../images/image (1108).png" alt=""><figcaption></figcaption></figure>
As jy die **afdelingsoffset** (0x37DC) + die **offset** waar die **arch begin**, in hierdie geval `0x18000` --> `0x37DC + 0x18000 = 0x1B7DC` As jy die **afdelingsverskuiwing** (0x37DC) by die **verskuiwing** waar die **argitektuur** begin optel, in hierdie geval `0x18000` --> `0x37DC + 0x18000 = 0x1B7DC`
<figure><img src="../../../images/image (701).png" alt=""><figcaption></figcaption></figure> <figure><img src="../../../images/image (701).png" alt=""><figcaption></figcaption></figure>
Dit is ook moontlik om **kopinligting** van die **opdraglyn** te verkry met: Dit is ook moontlik om **header-inligting** vanaf die **opdraglyn** te kry met:
```bash ```bash
otool -lv /bin/ls otool -lv /bin/ls
``` ```
Algemene segmente wat deur hierdie cmd gelaai word: Algemene segmente wat deur hierdie cmd gelaai word:
- **`__PAGEZERO`:** Dit gee die kernel opdrag om die **adres nul** te **kaart**, sodat dit **nie gelees, geskryf of uitgevoer kan word** nie. Die maxprot en minprot veranderlikes in die struktuur is op nul gestel om aan te dui dat daar **geen lees-skrif-uitvoer regte op hierdie bladsy is** nie. - **`__PAGEZERO`:** Dit beveel die kernel om die **adres nul** te **map** sodat dit **nie gelees, geskryf of uitgevoer kan word nie**. Die maxprot- en minprot-veranderlikes in die struktuur is op nul gestel om aan te dui dat daar **geen lees-skryf-uitvoer regte op hierdie bladsy is nie**.
- Hierdie toewysing is belangrik om **NULL pointer dereference kwesbaarhede te verminder**. Dit is omdat XNU 'n harde bladsy nul afdwing wat verseker dat die eerste bladsy (slegs die eerste) van geheue ontoeganklik is (behalwe in i386). 'n Binêre kan aan hierdie vereistes voldoen deur 'n klein \_\_PAGEZERO te skep (met die `-pagezero_size`) om die eerste 4k te dek en die res van die 32-bit geheue in beide gebruiker- en kernelmodus toeganklik te hê. - Hierdie toekenning is belangrik om **NULL pointer dereference vulnerabilities** te verminder. Dit is omdat XNU 'n harde page zero afdwing wat verseker dat die eerste bladsy (slegs die eerste) van geheue ontoeganklik is (behalwe in i386). 'n binary kan aan hierdie vereistes voldoen deur 'n klein \_\_PAGEZERO te vervaardig (gebruik `-pagezero_size`) om die eerste 4k te dek en die res van die 32bit geheue toeganklik te maak in beide user- en kernel-modus.
- **`__TEXT`**: Bevat **uitvoerbare** **kode** met **lees** en **uitvoer** toestemmings (geen skryfbare)**.** Algemene afdelings van hierdie segment: - **`__TEXT`**: Bevat **uitvoerbare** **kode** met **lees** en **uitvoering** regte (nie skryfbaar nie). Algemene afdelings van hierdie segment:
- `__text`: Gecompileerde binêre kode - `__text`: Gekomileerde kode
- `__const`: Konstant data (slegs lees) - `__const`: Konstantedata (slegs leesbaar)
- `__[c/u/os_log]string`: C, Unicode of os logs string konstantes - `__[c/u/os_log]string`: C-, Unicode- of os_log-string konstantes
- `__stubs` en `__stubs_helper`: Betrokke tydens die dinamiese biblioteek laai proses - `__stubs` and `__stubs_helper`: Betrokke tydens die dinamiese biblioteek-laaiproses
- `__unwind_info`: Stapel ontrafel data. - `__unwind_info`: Stack unwind-data.
- Let daarop dat al hierdie inhoud onderteken is, maar ook as uitvoerbaar gemerk is (wat meer opsies vir die uitbuiting van afdelings skep wat nie noodwendig hierdie voorreg benodig nie, soos string toegewyde afdelings). - Let wel dat al hierdie inhoud gesigneer is maar ook as uitvoerbaar gemerk is (wat meer opsies skep vir die uitbuiting van afdelings wat nie noodwendig hierdie voorreg benodig nie, soos string-toegewyde afdelings).
- **`__DATA`**: Bevat data wat **leesbaar** en **skryfbaar** is (geen uitvoerbare)**.** - **`__DATA`**: Bevat data wat **leesbaar** en **skryfbaar** is (nie uitvoerbaar nie).
- `__got:` Globale Offset Tabel - `__got:` Global Offset Table
- `__nl_symbol_ptr`: Nie lui (bind by laai) simbool pointer - `__nl_symbol_ptr`: Non lazy (bind at load) symbol pointer
- `__la_symbol_ptr`: Lui (bind by gebruik) simbool pointer - `__la_symbol_ptr`: Lazy (bind on use) symbol pointer
- `__const`: Moet slegs leesbare data wees (nie regtig nie) - `__const`: Sou lees-alleen data wees (maar nie regtig nie)
- `__cfstring`: CoreFoundation strings - `__cfstring`: CoreFoundation strings
- `__data`: Globale veranderlikes (wat geinitialiseer is) - `__data`: Globale veranderlikes (wat geïnitialiseer is)
- `__bss`: Statiese veranderlikes (wat nie geinitialiseer is nie) - `__bss`: Statiese veranderlikes (wat nie geïnitialiseer is nie)
- `__objc_*` (\_\_objc_classlist, \_\_objc_protolist, ens): Inligting wat deur die Objective-C runtime gebruik word - `__objc_*` (\_\_objc_classlist, \_\_objc_protolist, etc): Inligting wat deur die Objective-C runtime gebruik word
- **`__DATA_CONST`**: \_\_DATA.\_\_const is nie gewaarborg om konstant te wees nie (skryf toestemmings), en ander pointers en die GOT ook nie. Hierdie afdeling maak `__const`, sommige inisialisators en die GOT tabel (sodra dit opgelos is) **slegs lees** met behulp van `mprotect`. - **`__DATA_CONST`**: \_\_DATA.\_\_const is nie gewaarborg om konstant te wees nie (skryfregte), en ander pointers en die GOT ook nie. Hierdie afdeling maak `__const`, sommige initialiseerders en die GOT-tabel (sodra dit opgelos is) **slegs-lees** deur `mprotect`.
- **`__LINKEDIT`**: Bevat inligting vir die linker (dyld) soos simbool, string, en herlokasie tabel inskrywings. Dit is 'n generiese houer vir inhoud wat nie in `__TEXT` of `__DATA` is nie en sy inhoud word in ander laaiopdragte beskryf. - **`__LINKEDIT`**: Bevat inligting vir die linker (dyld) soos simbool-, string- en relocasie-tabelinskrywings. Dit is 'n generiese houer vir inhoud wat nie in `__TEXT` of `__DATA` is nie en sy inhoud word in ander load commands beskryf.
- dyld inligting: Rebase, Nie-lui/lui/swak binding opcodes en uitvoer info - dyld-inligting: Rebase, Non-lazy/lazy/weak binding opcodes en export-inligting
- Funksies begin: Tabel van begin adresse van funksies - Functions starts: Tabel van beginadresse van funksies
- Data In Kode: Data-eilande in \_\_text - Data In Code: Data-eilandjies in \_\_text
- Simbool Tabel: Simbole in binêre - SYmbol Table: Simbole in die binary
- Indirekte Simbool Tabel: Pointer/stub simbole - Indirect Symbol Table: Pointer/stub-simbole
- String Tabel - String Table
- Kode Handtekening - Code Signature
- **`__OBJC`**: Bevat inligting wat deur die Objective-C runtime gebruik word. Alhoewel hierdie inligting ook in die \_\_DATA segment gevind kan word, binne verskeie in \_\_objc\_\* afdelings. - **`__OBJC`**: Bevat inligting wat deur die Objective-C runtime gebruik word. Hierdie inligting kan egter ook in die \_\_DATA-segment voorkom, binne verskeie \_\_objc\_\* afdelings.
- **`__RESTRICT`**: 'n Segment sonder inhoud met 'n enkele afdeling genaamd **`__restrict`** (ook leeg) wat verseker dat wanneer die binêre uitgevoer word, dit DYLD omgewingsveranderlikes sal ignoreer. - **`__RESTRICT`**: 'n Segment sonder inhoud met 'n enkele afdeling genaamd **`__restrict`** (ook leeg) wat verseker dat wanneer die binary uitgevoer word, dit DYLD-omgewingsvariabeles sal ignoreer.
Soos dit moontlik was om in die kode te sien, **ondersteun segmente ook vlae** (alhoewel hulle nie baie gebruik word nie): Soos in die kode gesien kan word, **ondersteun segmente ook vlae** (alhoewel hulle nie baie gebruik word nie):
- `SG_HIGHVM`: Slegs kern (nie gebruik nie) - `SG_HIGHVM`: Core only (not used)
- `SG_FVMLIB`: Nie gebruik nie - `SG_FVMLIB`: Not used
- `SG_NORELOC`: Segment het geen herlokasie nie - `SG_NORELOC`: Segment has no relocation
- `SG_PROTECTED_VERSION_1`: Enkripsie. Gebruik byvoorbeeld deur Finder om teks in die `__TEXT` segment te enkripteer. - `SG_PROTECTED_VERSION_1`: Encryption. Used for example by Finder to encrypt text `__TEXT` segment.
### **`LC_UNIXTHREAD/LC_MAIN`** ### **`LC_UNIXTHREAD/LC_MAIN`**
**`LC_MAIN`** bevat die toegangspunt in die **entryoff attribuut.** Tydens laai, **dyld** voeg eenvoudig **hierdie waarde** by die (in-geheue) **basis van die binêre**, dan **spring** dit na hierdie instruksie om die uitvoering van die binêre se kode te begin. **`LC_MAIN`** bevat die entrypoint in die **entryoff-atribuut.** Tydens laai voeg **dyld** bloot hierdie waarde by die (in-memory) **basis van die binary**, en **spring** dan na hierdie instruksie om die uitvoering van die binary se kode te begin.
**`LC_UNIXTHREAD`** bevat die waardes wat die register moet hê wanneer die hoofdraad begin. Dit is reeds verouderd, maar **`dyld`** gebruik dit steeds. Dit is moontlik om die waardes van die registers wat deur hierdie gestel is, te sien met: **`LC_UNIXTHREAD`** bevat die waardes wat registers moet hê wanneer die hoofdraad begin word. Dit is reeds verouderd, maar **`dyld`** gebruik dit steeds. Dit is moontlik om die waardes van die registers wat daarmee gestel word te sien met:
```bash ```bash
otool -l /usr/lib/dyld otool -l /usr/lib/dyld
[...] [...]
@ -286,34 +286,39 @@ cpsr 0x00000000
``` ```
### **`LC_CODE_SIGNATURE`** ### **`LC_CODE_SIGNATURE`**
Bevat inligting oor die **kodehandtekening van die Macho-O lêer**. Dit bevat slegs 'n **offset** wat na die **handtekening blob** **wys**. Dit is tipies aan die einde van die lêer.\ {{#ref}}
U kan egter 'n paar inligting oor hierdie afdeling vind in [**hierdie blogpos**](https://davedelong.com/blog/2018/01/10/reading-your-own-entitlements/) en hierdie [**gists**](https://gist.github.com/carlospolop/ef26f8eb9fafd4bc22e69e1a32b81da4). ../../../generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/mach-o-entitlements-and-ipsw-indexing.md
{{#endref}}
Bevat inligting oor die **code signature of the Macho-O file**. Dit bevat slegs 'n **offset** wat **wys na** die **signature blob**. Dit is gewoonlik aan die einde van die lêer.\
Jy kan egter inligting oor hierdie afdeling vind in [**this blog post**](https://davedelong.com/blog/2018/01/10/reading-your-own-entitlements/) en hierdie [**gists**](https://gist.github.com/carlospolop/ef26f8eb9fafd4bc22e69e1a32b81da4).
### **`LC_ENCRYPTION_INFO[_64]`** ### **`LC_ENCRYPTION_INFO[_64]`**
Ondersteuning vir binêre versleuteling. Dit gesê, as 'n aanvaller daarin slaag om die proses te kompromitteer, sal hy in staat wees om die geheue onversleuteld te dump. Ondersteun binary encryption. Uiteraard, as 'n attacker daarin slaag om die proses te kompromitteer, sal hy die geheue ongeënkripteerd kan dump.
### **`LC_LOAD_DYLINKER`** ### **`LC_LOAD_DYLINKER`**
Bevat die **pad na die dinamiese linker uitvoerbare lêer** wat gedeelde biblioteke in die prosesadresruimte in kaart bring. Die **waarde is altyd ingestel op `/usr/lib/dyld`**. Dit is belangrik om te noem dat in macOS, dylib-mapping in **gebruikermodus** plaasvind, nie in kernmodus nie. Bevat die **pad na die dynamic linker executable** wat shared libraries in die proses adresruimte map. Die **waarde is altyd gestel op `/usr/lib/dyld`**. Dit is belangrik om daarop te let dat in macOS, dylib mapping in **user mode** plaasvind, nie in kernel mode nie.
### **`LC_IDENT`** ### **`LC_IDENT`**
Verouderd, maar wanneer dit gekonfigureer is om dumps op paniek te genereer, word 'n Mach-O kern dump geskep en die kern weergawe word in die `LC_IDENT` opdrag ingestel. Verouderd — maar wanneer dit gekonfigureer is om dumps op panic te genereer, word 'n Mach-O core dump geskep en die kernel version in die `LC_IDENT` command gestel.
### **`LC_UUID`** ### **`LC_UUID`**
Ewekansige UUID. Dit is nuttig vir enigiets direk, maar XNU kas dit saam met die res van die prosesinligting. Dit kan in ongelukverslae gebruik word. Willekeurige UUID. Dit is nie direk nuttig vir iets nie, maar XNU cache dit saam met die res van die prosesinligting. Dit kan in crash reports gebruik word.
### **`LC_DYLD_ENVIRONMENT`** ### **`LC_DYLD_ENVIRONMENT`**
Stel in staat om omgewingsveranderlikes aan die dyld aan te dui voordat die proses uitgevoer word. Dit kan baie gevaarlik wees aangesien dit die uitvoering van arbitrêre kode binne die proses kan toelaat, so hierdie laaiopdrag word slegs in dyld-bou met `#define SUPPORT_LC_DYLD_ENVIRONMENT` gebruik en beperk die verwerking verder slegs tot veranderlikes van die vorm `DYLD_..._PATH` wat laai-pade spesifiseer. Laat toe om environment variables aan dyld aan te dui voordat die proses uitgevoer word. Dit kan baie gevaarlik wees aangesien dit toelaat om arbitrary code binne die proses uit te voer, daarom word hierdie load command slegs gebruik in dyld builds met `#define SUPPORT_LC_DYLD_ENVIRONMENT` en beperk verwerking verder slegs tot veranderlikes van die vorm `DYLD_..._PATH` wat load paths spesifiseer.
### **`LC_LOAD_DYLIB`** ### **`LC_LOAD_DYLIB`**
Hierdie laaiopdrag beskryf 'n **dinamiese** **biblioteek** afhanklikheid wat die **laaier** (dyld) **instrueer** om die **gesê biblioteek te laai en te koppel**. Daar is 'n `LC_LOAD_DYLIB` laaiopdrag **vir elke biblioteek** wat die Mach-O binêre benodig. Hierdie load command beskryf 'n **dynamic** **library** afhanklikheid wat die **loader** (dyld) **instrueer** om genoemde library te **load and link**. Daar is 'n `LC_LOAD_DYLIB` load command **vir elke library** wat die Mach-O binary benodig.
- Hierdie laaiopdrag is 'n struktuur van tipe **`dylib_command`** (wat 'n struktuur dylib bevat, wat die werklike afhanklike dinamiese biblioteek beskryf): - Hierdie load command is 'n struktuur van tipe **`dylib_command`** (wat 'n struct dylib bevat, wat die werklike afhanklike dynamic library beskryf):
```objectivec ```objectivec
struct dylib_command { struct dylib_command {
uint32_t cmd; /* LC_LOAD_{,WEAK_}DYLIB */ uint32_t cmd; /* LC_LOAD_{,WEAK_}DYLIB */
@ -330,7 +335,7 @@ uint32_t compatibility_version; /* library's compatibility vers number*/
``` ```
![](<../../../images/image (486).png>) ![](<../../../images/image (486).png>)
Jy kan ook hierdie inligting van die cli kry met: Jy kan hierdie inligting ook vanaf die cli kry met:
```bash ```bash
otool -L /bin/ls otool -L /bin/ls
/bin/ls: /bin/ls:
@ -340,30 +345,30 @@ otool -L /bin/ls
``` ```
Sommige potensiële malware-verwante biblioteke is: Sommige potensiële malware-verwante biblioteke is:
- **DiskArbitration**: Monitering van USB skywe - **DiskArbitration**: Monitering van USB-stasies
- **AVFoundation:** Opname van audio en video - **AVFoundation:** Neem klank en video op
- **CoreWLAN**: Wifi skandeer. - **CoreWLAN**: Wi‑Fi-skanderings.
> [!NOTE] > [!TIP]
> 'n Mach-O binêre kan een of **meer** **konstruktore** bevat, wat **uitgevoer** sal word **voor** die adres wat in **LC_MAIN** gespesifiseer is.\ > 'n Mach-O binary kan een of **meer** **constructors** bevat, wat **uitgevoer** sal word **voor** die adres wat in **LC_MAIN** gespesifiseer is.\
> Die offsets van enige konstruktore word in die **\_\_mod_init_func** afdeling van die **\_\_DATA_CONST** segment gehou. > Die offsets van enige constructors word gehou in die **\_\_mod_init_func** afdeling van die **\_\_DATA_CONST** segment.
## **Mach-O Data** ## **Mach-O Data**
In die kern van die lêer lê die datastreek, wat uit verskeie segmente bestaan soos gedefinieer in die laai-opdragte streek. **'n Verskeidenheid dataseksies kan binne elke segment gehuisves word**, met elke afdeling **wat kode of data** spesifiek vir 'n tipe hou. In die kern van die lêer lê die data-streek, wat uit verskeie segmente saamgestel is soos gedefinieer in die load-commands streek. **'n Verskeidenheid data-afdelings kan binne elke segment gehuisves word**, met elke afdeling wat **kode of data bevat** spesifiek vir 'n tipe.
> [!TIP] > [!TIP]
> Die data is basies die deel wat al die **inligting** bevat wat deur die laai-opdragte **LC_SEGMENTS_64** gelaai word. > Die data is basies die deel wat al die **inligting** bevat wat deur die load commands **LC_SEGMENTS_64** gelaai word
![https://www.oreilly.com/api/v2/epubs/9781785883378/files/graphics/B05055_02_38.jpg](<../../../images/image (507) (3).png>) ![https://www.oreilly.com/api/v2/epubs/9781785883378/files/graphics/B05055_02_38.jpg](<../../../images/image (507) (3).png>)
Dit sluit in: Dit sluit in:
- **Funksietabel:** Wat inligting oor die programfunksies hou. - **Function table:** Wat inligting oor die program se funksies bevat.
- **Simboltabel**: Wat inligting bevat oor die eksterne funksie wat deur die binêre gebruik word - **Symbol table**: Wat inligting bevat oor die eksterne funksies wat deur die binary gebruik word
- Dit kan ook interne funksie, veranderlike name sowel as meer bevat. - Dit kan ook interne funksies, veranderlike name en meer bevat.
Om dit te kontroleer kan jy die [**Mach-O View**](https://sourceforge.net/projects/machoview/) hulpmiddel gebruik: 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> <figure><img src="../../../images/image (1120).png" alt=""><figcaption></figcaption></figure>
@ -373,20 +378,20 @@ size -m /bin/ls
``` ```
## Objetive-C Algemene Afdelings ## Objetive-C Algemene Afdelings
In `__TEXT` segment (r-x): In die `__TEXT` segment (r-x):
- `__objc_classname`: Klasname (strings) - `__objc_classname`: Klasname (strings)
- `__objc_methname`: Metode name (strings) - `__objc_methname`: Metodenamme (strings)
- `__objc_methtype`: Metode tipes (strings) - `__objc_methtype`: Metode tipes (strings)
In `__DATA` segment (rw-): In die `__DATA` segment (rw-):
- `__objc_classlist`: Pointers na alle Objetive-C klasse - `__objc_classlist`: Wysigers na alle Objetive-C klasse
- `__objc_nlclslist`: Pointers na Non-Lazy Objective-C klasse - `__objc_nlclslist`: Wysigers na Non-Lazy Objective-C klasse
- `__objc_catlist`: Pointer na Kategories - `__objc_catlist`: Wysiger na Categories
- `__objc_nlcatlist`: Pointer na Non-Lazy Kategories - `__objc_nlcatlist`: Wysiger na Non-Lazy Categories
- `__objc_protolist`: Protokolle lys - `__objc_protolist`: Protokollys
- `__objc_const`: Konstant data - `__objc_const`: Konstante data
- `__objc_imageinfo`, `__objc_selrefs`, `objc__protorefs`... - `__objc_imageinfo`, `__objc_selrefs`, `objc__protorefs`...
## Swift ## Swift

133
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-code-signing.md
View File

@ -4,12 +4,17 @@
## Basiese Inligting ## Basiese Inligting
Mach-o binaries bevat 'n laaiopdrag genaamd **`LC_CODE_SIGNATURE`** wat die **offset** en **grootte** van die handtekeninge binne die binêre aandui. Trouens, deur die GUI-gereedskap MachOView te gebruik, is dit moontlik om aan die einde van die binêre 'n afdeling genaamd **Code Signature** met hierdie inligting te vind: {{#ref}}
../../../generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/mach-o-entitlements-and-ipsw-indexing.md
{{#endref}}
Mach-o binaries bevat 'n load command genaamd **`LC_CODE_SIGNATURE`** wat die **offset** en **size** van die signatures binne die binary aandui. Met die GUI-instrument MachOView is dit moontlik om aan die einde van die binary 'n afdeling met die naam **Code Signature** te vind met hierdie inligting:
<figure><img src="../../../images/image (1) (1) (1) (1).png" alt="" width="431"><figcaption></figcaption></figure> <figure><img src="../../../images/image (1) (1) (1) (1).png" alt="" width="431"><figcaption></figcaption></figure>
Die magiese kop van die Code Signature is **`0xFADE0CC0`**. Dan het jy inligting soos die lengte en die aantal blobs van die superBlob wat hulle bevat.\ Die magic header van die Code Signature is **`0xFADE0CC0`**. Daarna is daar inligting soos die lengte en die aantal blobs van die superBlob wat hulle bevat.\
Dit is moontlik om hierdie inligting in die [bron kode hier](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/osfmk/kern/cs_blobs.h#L276) te vind: Dit is moontlik om hierdie inligting in die [source code here](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/osfmk/kern/cs_blobs.h#L276):
```c ```c
/* /*
* Structure of an embedded-signature SuperBlob * Structure of an embedded-signature SuperBlob
@ -38,14 +43,14 @@ char data[];
} CS_GenericBlob } CS_GenericBlob
__attribute__ ((aligned(1))); __attribute__ ((aligned(1)));
``` ```
Gewone blobs wat bevat word, is Code Directory, Requirements en Entitlements en 'n Cryptographic Message Syntax (CMS).\ Gereelde blobs wat ingesluit is, is Code Directory, Requirements en Entitlements en 'n Cryptographic Message Syntax (CMS).\
Boonop, let op hoe die data wat in die blobs gekodeer is, in **Big Endian** gekodeer is. Let ook daarop dat die data in die blobs in **Big Endian.**
Boonop kan handtekeninge van die binaries losgemaak word en gestoor word in `/var/db/DetachedSignatures` (gebruik deur iOS). Verder kan handtekeninge van die binaries afgekoppel wees en in `/var/db/DetachedSignatures` gestoor word (gebruik deur iOS).
## Code Directory Blob ## Code Directory Blob
Dit is moontlik om die verklaring van die [Code Directory Blob in die kode](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/osfmk/kern/cs_blobs.h#L104) te vind: Dit is moontlik om die deklarasie van die [Code Directory Blob in the code](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/osfmk/kern/cs_blobs.h#L104):
```c ```c
typedef struct __CodeDirectory { typedef struct __CodeDirectory {
uint32_t magic; /* magic number (CSMAGIC_CODEDIRECTORY) */ uint32_t magic; /* magic number (CSMAGIC_CODEDIRECTORY) */
@ -101,12 +106,12 @@ char end_withLinkage[0];
} CS_CodeDirectory } CS_CodeDirectory
__attribute__ ((aligned(1))); __attribute__ ((aligned(1)));
``` ```
Let wel dat daar verskillende weergawes van hierdie struktuur is waar oues minder inligting mag bevat. Let wel dat daar verskillende weergawes van hierdie struct is, en ouer weergawes kan minder inligting bevat.
## Ondertekening van Kode Bladsye ## Ondertekening van Code Pages
Hashing van die volle binêre sou ondoeltreffend en selfs nutteloos wees as dit net gedeeltelik in geheue gelaai word. Daarom is die kodehandtekening eintlik 'n hash van hashes waar elke binêre bladsy individueel gehasht word.\ Hashing van die volle binary sou ondoeltreffend wees en selfs nutteloos wees as dit slegs gedeeltelik in geheue gelaai word. Daarom is die code signature eintlik 'n hash of hashes waar elke binary page individueel gehashed word.\
Eintlik kan jy in die vorige **Kode Gids** kode sien dat die **bladgrootte gespesifiseer is** in een van sy velde. Boonop, as die grootte van die binêre nie 'n veelvoud van die grootte van 'n bladsy is nie, spesifiseer die veld **CodeLimit** waar die einde van die handtekening is. In werklikheid kan jy in die vorige **Code Directory** code sien dat die **page size is specified** in een van sy velde. Verder, as die grootte van die binary nie 'n veelvoud van die grootte van 'n page is nie, spesifiseer die veld **CodeLimit** waar die einde van die signature is.
```bash ```bash
# Get all hashes of /bin/ps # Get all hashes of /bin/ps
codesign -d -vvvvvv /bin/ps codesign -d -vvvvvv /bin/ps
@ -142,27 +147,27 @@ dd if=$BINARY of=/tmp/`basename $BINARY`.page.$i bs=$PAGESIZE skip=$i count=1
done done
openssl sha256 /tmp/*.page.* openssl sha256 /tmp/*.page.*
``` ```
## Toelaag Blob ## Entitlements Blob
Let daarop dat toepassings ook 'n **toelaag blob** kan bevat waar al die toelaes gedefinieer is. Boonop mag sommige iOS binêre hul toelaes spesifiek in die spesiale slot -7 hê (in plaas van in die -5 toelaes spesiale slot). Let op dat toepassings ook 'n **entitlement blob** kan bevat waar al die entitlements gedefinieer is. Boonop kan sommige iOS-binaries hul entitlements spesifiseer in die spesiale slot -7 (in plaas van in die -5 entitlements spesiale slot).
## Spesiale Slots ## Special Slots
MacOS toepassings het nie alles wat hulle nodig het om binne die binêre uit te voer nie, maar hulle gebruik ook **buitelandse hulpbronne** (gewoonlik binne die toepassings **bundel**). Daarom is daar 'n paar slots binne die binêre wat die hashes van 'n paar interessante buitelandse hulpbronne sal bevat om te kontroleer dat hulle nie gewysig is nie. MacOS-toepassings het nie alles wat hulle nodig het om binne die binary uit te voer nie; hulle gebruik ook **external resources** (gewoonlik binne die toepassing se **bundle**). Daarom is daar sekere slots binne die binary wat die hashes van sommige belangrike eksterne hulpbronne sal bevat om te verifieer dat dit nie verander is nie.
Werklik, dit is moontlik om in die Code Directory strukture 'n parameter genaamd **`nSpecialSlots`** te sien wat die aantal spesiale slots aandui. Daar is nie 'n spesiale slot 0 nie en die mees algemene (van -1 tot -6) is: Dit is moontlik om in die Code Directory structs 'n parameter genaamd **`nSpecialSlots`** te sien wat die aantal spesiale slots aandui. Daar is nie 'n spesiale slot 0 nie en die mees algemene (van -1 tot -6) is:
- Hash van `info.plist` (of die een binne `__TEXT.__info__plist`). - Hash van `info.plist` (of die een binne `__TEXT.__info__plist`).
- Hash van die Vereistes - Hash van die Requirements
- Hash van die Hulpbron Gids (hash van `_CodeSignature/CodeResources` lêer binne die bundel). - Hash van die Resource Directory (hash van die `_CodeSignature/CodeResources`-lêer binne die bundle).
- Toepassing spesifiek (onbenut) - Toepassingspesifiek (nie gebruik nie)
- Hash van die toelaes - Hash van die entitlements
- DMG kode handtekeninge slegs - Slegs DMG code signatures
- DER Toelaes - DER Entitlements
## Kode Handtekening Vlaggies ## Code Signing Flags
Elke proses het 'n bitmasker wat bekend staan as die `status` wat deur die kernel begin word en sommige daarvan kan oorgeskryf word deur die **kode handtekening**. Hierdie vlaggies wat in die kode handtekening ingesluit kan word, is [gedefinieer in die kode](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/osfmk/kern/cs_blobs.h#L36): Elke proses het 'n verwante bitmasker bekend as die `status` wat deur die kernel gestel word, en sommige kan oorrompel word deur die **code signature**. Hierdie vlae wat in die code signing ingesluit kan word, is [in die kode gedefinieer](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/osfmk/kern/cs_blobs.h#L36):
```c ```c
/* code signing attributes of a process */ /* code signing attributes of a process */
#define CS_VALID 0x00000001 /* dynamically valid */ #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) #define CS_ENTITLEMENT_FLAGS (CS_GET_TASK_ALLOW | CS_INSTALLER | CS_DATAVAULT_CONTROLLER | CS_NVRAM_UNRESTRICTED)
``` ```
Let wel, die funksie [**exec_mach_imgact**](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/bsd/kern/kern_exec.c#L1420) kan ook die `CS_EXEC_*` vlae dinamies byvoeg wanneer die uitvoering begin. Let daarop dat die funksie [**exec_mach_imgact**](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/bsd/kern/kern_exec.c#L1420) ook die `CS_EXEC_*` vlagte dinamies kan byvoeg wanneer dit die uitvoering begin.
## Kode Handtekening Vereistes ## Vereistes vir kodehandtekening
Elke toepassing stoor **vereistes** wat dit moet **tevrede stel** om uitgevoer te kan word. As die **toepassing vereistes bevat wat nie deur die toepassing tevrede gestel word nie**, sal dit nie uitgevoer word nie (soos dit waarskynlik verander is). Elke toepassing stoor sekere **vereistes** wat dit moet **bevredig** om uitgevoer te kan word. As die **vereistes wat in die toepassing vervat is nie deur die toepassing bevredig word nie**, sal dit nie uitgevoer word nie (aangesien dit waarskynlik verander is).
Die vereistes van 'n binêre gebruik 'n **spesiale grammatika** wat 'n stroom van **uitdrukkings** is en word as blobs gekodeer met `0xfade0c00` as die magie waarvan die **hash in 'n spesiale kode-slot gestoor word**. Die vereistes van 'n binêre gebruik 'n **spesiale grammatika** wat 'n stroom van **uitdrukkings** is en word gekodeer as blobs wat `0xfade0c00` as die magiese waarde gebruik, waarvan die **hash in 'n spesiale code slot gestoor word**.
Die vereistes van 'n binêre kan gesien word deur te loop: Die vereistes van 'n binêre kan gesien word deur dit uit te voer:
```bash ```bash
codesign -d -r- /bin/ls codesign -d -r- /bin/ls
Executable=/bin/ls Executable=/bin/ls
@ -225,10 +230,10 @@ codesign -d -r- /Applications/Signal.app/
Executable=/Applications/Signal.app/Contents/MacOS/Signal 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 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] > [!TIP]
> Let op hoe hierdie handtekeninge dinge soos sertifiseringsinligting, TeamID, ID's, regte en baie ander data kan nagaan. > Let op hoe hierdie signatures dinge kan nagaan soos sertifiseringsinligting, TeamID, IDs, entitlements en baie ander data.
Boonop is dit moontlik om 'n paar saamgestelde vereistes te genereer met die `csreq` hulpmiddel: Verder is dit moontlik om sekere gekompileerde vereistes te genereer met die `csreq`-tool:
```bash ```bash
# Generate compiled requirements # 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' 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 0000020 00 00 00 21 6f 72 67 2e 77 68 69 73 70 65 72 73
[...] [...]
``` ```
It's possible to access this information and create or modify requirements with some APIs from the `Security.framework` like: Dit is moontlik om toegang tot hierdie inligting te kry en vereistes te skep of te wysig met sommige API's van die `Security.framework` soos:
#### **Kontroleer Geldigheid** #### **Checking Validity**
- **`Sec[Static]CodeCheckValidity`**: Kontroleer die geldigheid van SecCodeRef per Vereiste. - **`Sec[Static]CodeCheckValidity`**: Kontroleer die geldigheid van `SecCodeRef` volgens 'n vereiste.
- **`SecRequirementEvaluate`**: Valideer vereiste in sertifikaat konteks - **`SecRequirementEvaluate`**: Valideer 'n vereiste in die sertifikaatkonteks.
- **`SecTaskValidateForRequirement`**: Valideer 'n lopende SecTask teen `CFString` vereiste. - **`SecTaskValidateForRequirement`**: Valideer 'n lopende `SecTask` teen 'n `CFString` vereiste.
#### **Skep en Bestuur Kode Vereistes** #### **Creating and Managing Code Requirements**
- **`SecRequirementCreateWithData`:** Skep 'n `SecRequirementRef` uit binêre data wat die vereiste verteenwoordig. - **`SecRequirementCreateWithData`:** Skep 'n `SecRequirementRef` vanaf binêre data wat die vereiste voorstel.
- **`SecRequirementCreateWithString`:** Skep 'n `SecRequirementRef` uit 'n stringuitdrukking van die vereiste. - **`SecRequirementCreateWithString`:** Skep 'n `SecRequirementRef` vanaf 'n stringuitdrukking van die vereiste.
- **`SecRequirementCopy[Data/String]`**: Verkry die binêre data voorstelling van 'n `SecRequirementRef`. - **`SecRequirementCopy[Data/String]`**: Haal die binêre datarepresentasie van 'n `SecRequirementRef`.
- **`SecRequirementCreateGroup`**: Skep 'n vereiste vir app-groep lidmaatskap - **`SecRequirementCreateGroup`**: Skep 'n vereiste vir app-groep lidmaatskap.
#### **Toegang tot Kode Handtekening Inligting** #### **Accessing Code Signing Information**
- **`SecStaticCodeCreateWithPath`**: Inisialiseer 'n `SecStaticCodeRef` objek vanaf 'n lêerstelsel pad vir die inspeksie van kode handtekeninge. - **`SecStaticCodeCreateWithPath`**: Initialiseer 'n `SecStaticCodeRef` objek vanaf 'n lêerstelselpad om kodehandtekeninge te ondersoek.
- **`SecCodeCopySigningInformation`**: Verkry handtekening inligting van 'n `SecCodeRef` of `SecStaticCodeRef`. - **`SecCodeCopySigningInformation`**: Verkry ondertekeningsinligting vanaf 'n `SecCodeRef` of `SecStaticCodeRef`.
#### **Wysig Kode Vereistes** #### **Modifying Code Requirements**
- **`SecCodeSignerCreate`**: Skep 'n `SecCodeSignerRef` objek vir die uitvoering van kode handtekening operasies. - **`SecCodeSignerCreate`**: Skep 'n `SecCodeSignerRef` objek vir die uitvoering van kodeondertekeningsoperasies.
- **`SecCodeSignerSetRequirement`**: Stel 'n nuwe vereiste vir die kode ondertekenaar in om tydens ondertekening toe te pas. - **`SecCodeSignerSetRequirement`**: Stel 'n nuwe vereiste vir die kode-signer wat tydens ondertekening toegepas moet word.
- **`SecCodeSignerAddSignature`**: Voeg 'n handtekening by die kode wat onderteken word met die gespesifiseerde ondertekenaar. - **`SecCodeSignerAddSignature`**: Voeg 'n handtekening by die kode wat met die gespesifiseerde signer onderteken word.
#### **Valideer Kode met Vereistes** #### **Validating Code with Requirements**
- **`SecStaticCodeCheckValidity`**: Valideer 'n statiese kode objek teen gespesifiseerde vereistes. - **`SecStaticCodeCheckValidity`**: Valideer 'n statiese kode-objek teen gespesifiseerde vereistes.
#### **Addisionele Nuttige APIs** #### **Additional Useful APIs**
- **`SecCodeCopy[Internal/Designated]Requirement`: Kry SecRequirementRef van SecCodeRef** - **`SecCodeCopy[Internal/Designated]Requirement`: Get SecRequirementRef from SecCodeRef**
- **`SecCodeCopyGuestWithAttributes`**: Skep 'n `SecCodeRef` wat 'n kode objek verteenwoordig gebaseer op spesifieke eienskappe, nuttig vir sandboxing. - **`SecCodeCopyGuestWithAttributes`**: Skep 'n `SecCodeRef` wat 'n kode-objek voorstel gebaseer op spesifieke eienskappe, nuttig vir sandboxing.
- **`SecCodeCopyPath`**: Verkry die lêerstelsel pad geassosieer met 'n `SecCodeRef`. - **`SecCodeCopyPath`**: Haal die lêerstelselpad wat by 'n `SecCodeRef` hoort.
- **`SecCodeCopySigningIdentifier`**: Verkry die handtekening identifiseerder (bv. Span ID) van 'n `SecCodeRef`. - **`SecCodeCopySigningIdentifier`**: Verkry die ondertekeningsidentifiseerder (bv. Team ID) vanaf 'n `SecCodeRef`.
- **`SecCodeGetTypeID`**: Gee die tipe identifiseerder vir `SecCodeRef` objek. - **`SecCodeGetTypeID`**: Gee die tipe-identifiseerder vir `SecCodeRef`-objekte terug.
- **`SecRequirementGetTypeID`**: Kry 'n CFTypeID van 'n `SecRequirementRef` - **`SecRequirementGetTypeID`**: Kry 'n CFTypeID van 'n `SecRequirementRef`.
#### **Kode Handtekening Vlaggies en Konstanten** #### **Code Signing Flags and Constants**
- **`kSecCSDefaultFlags`**: Standaard vlaggies wat in baie Security.framework funksies vir kode handtekening operasies gebruik word. - **`kSecCSDefaultFlags`**: Verstekvlae wat in baie Security.framework-funksies vir kodeondertekeningsoperasies gebruik word.
- **`kSecCSSigningInformation`**: Vlag wat gebruik word om aan te dui dat handtekening inligting verkry moet word. - **`kSecCSSigningInformation`**: Vlae wat gebruik word om te spesifiseer dat ondertekeningsinligting verkry moet word.
## Kode Handtekening Afforcing ## Code Signature Enforcement
Die **kernel** is die een wat **die kode handtekening kontroleer** voordat dit die kode van die app toelaat om uit te voer. Boonop, een manier om in geheue nuwe kode te kan skryf en uitvoer is om JIT te misbruik as `mprotect` met `MAP_JIT` vlag aangeroep word. Let daarop dat die toepassing 'n spesiale regte benodig om dit te kan doen. Die kernel is die een wat die kodehandtekening nagaan voordat die app se kode toegelaat word om uit te voer. Verder is een manier om nuwe kode in geheue te kan skryf en uitvoer deur misbruik van JIT indien `mprotect` met die `MAP_JIT` vlag aangeroep word. Let wel dat die toepassing 'n spesiale entitlement nodig het om dit te kan doen.
## `cs_blobs` & `cs_blob` ## `cs_blobs` & `cs_blob`
[**cs_blob**](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/bsd/sys/ubc_internal.h#L106) struktuur bevat die inligting oor die regte van die lopende proses daarop. `csb_platform_binary` dui ook aan of die toepassing 'n platform binêre is (wat op verskillende tye deur die OS gekontroleer word om sekuriteitsmeganismes toe te pas soos om die SEND regte na die taak poorte van hierdie prosesse te beskerm). [**cs_blob**](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/bsd/sys/ubc_internal.h#L106) struct bevat die inligting oor die entitlement van die lopende proses daarop. `csb_platform_binary` dui ook aan of die toepassing 'n platform-binary is (wat op verskillende oomblikke deur die OS nagegaan word om sekuriteitsmeganismes toe te pas, soos die beskerming van die SEND rights na die task ports van hierdie prosesse).
```c ```c
struct cs_blob { struct cs_blob {
struct cs_blob *csb_next; struct cs_blob *csb_next;