diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 27f33cff3..2062b6f9d 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -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)
diff --git a/src/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/README.md b/src/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/README.md
index 88b0f5fb8..fcaf8a6b8 100644
--- a/src/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/README.md
+++ b/src/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/README.md
@@ -1,8 +1,8 @@
-# Spesifieke sagteware-/lêertipe-truuks
+# Spesifieke Sagteware/Lêertipe Trikke
 
 {{#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}}
@@ -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}}
diff --git a/src/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/mach-o-entitlements-and-ipsw-indexing.md b/src/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/mach-o-entitlements-and-ipsw-indexing.md
new file mode 100644
index 000000000..85246e037
--- /dev/null
+++ b/src/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/mach-o-entitlements-and-ipsw-indexing.md
@@ -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}}
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/universal-binaries-and-mach-o-format.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/universal-binaries-and-mach-o-format.md
index 61078ac10..c70f660b6 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/universal-binaries-and-mach-o-format.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/universal-binaries-and-mach-o-format.md
@@ -1,78 +1,78 @@
-# macOS Universele binêre & Mach-O Formaat
+# macOS Universal binaries & Mach-O Format
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## 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
-- Laai Opdragte
+- Header
+- Load Commands
 - Data
 
 ![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
 </strong><strong>#define FAT_CIGAM	0xbebafeca	/* NXSwapLong(FAT_MAGIC) */
 </strong>
 struct fat_header {
-<strong>	uint32_t	magic;		/* FAT_MAGIC of FAT_MAGIC_64 */
-</strong><strong>	uint32_t	nfat_arch;	/* aantal strukture wat volg */
+<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 spesifiseerder (int) */
-cpu_subtype_t	cpusubtype;	/* masjien spesifiseerder (int) */
-uint32_t	offset;		/* lêer offset na hierdie objek lêer */
-uint32_t	size;		/* grootte van hierdie objek lêer */
-uint32_t	align;		/* uitlijning as 'n mag van 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>
 
-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:
 
 <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 (vir argitektuur x86_64):	Mach-O 64-bit uitvoerbare x86_64
-/bin/ls (vir argitektuur 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 (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
-Vet koppe
+Fat headers
 fat_magic FAT_MAGIC
 <strong>nfat_arch 2
-</strong><strong>argitektuur 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>    grootte 72896
-</strong>    uitlijning 2^14 (16384)
-<strong>argitektuur arm64e
+</strong><strong>    size 72896
+</strong>    align 2^14 (16384)
+<strong>architecture arm64e
 </strong>    cputype CPU_TYPE_ARM64
 cpusubtype CPU_SUBTYPE_ARM64E
 capabilities PTR_AUTH_VERSION USERSPACE 0
 <strong>    offset 98304
-</strong><strong>    grootte 88816
-</strong>    uitlijning 2^14 (16384)
+</strong><strong>    size 88816
+</strong>    align 2^14 (16384)
 </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>
 
-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
 #define	MH_MAGIC	0xfeedface	/* the mach magic number */
 #define MH_CIGAM	0xcefaedfe	/* NXSwapInt(MH_MAGIC) */
@@ -99,20 +99,20 @@ uint32_t	flags;		/* flags */
 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_FVMLIB`: Vaste VM-biblioteeklêer.
 - `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_DYLINKER`: Dinamiese skakelaar
-- `MH_BUNDLE`: "Pluginlêers". Genereer met -bundle in gcc en eksplisiet gelaai deur `NSBundle` of `dlopen`.
-- `MH_DYSM`: Metgesel `.dSym` lêer (lêer met simbole vir foutopsporing).
-- `MH_KEXT_BUNDLE`: Kernel-uitbreidings.
+- `MH_DYLINKER`: Dinamiese linker
+- `MH_BUNDLE`: "Plugin-lêers". Gegenereer met -bundle in gcc en eksplisiet gelaai deur `NSBundle` of `dlopen`.
+- `MH_DYSM`: Geselskap `.dSym`-lêer (lêer met simbole vir foutopsporing).
+- `MH_KEXT_BUNDLE`: Kernuitbreidings.
 ```bash
 # Checking the mac header of a binary
 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>
 
-## **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_DYLDLINK`: Dyld-koppeling
-- `MH_PREBOUND`: Dinamiese verwysings vooraf gekoppel.
-- `MH_SPLIT_SEGS`: Lêer verdeel r/o en r/w segmente.
-- `MH_WEAK_DEFINES`: Binêre het swak gedefinieerde simbole
-- `MH_BINDS_TO_WEAK`: Binêre gebruik swak simbole
-- `MH_ALLOW_STACK_EXECUTION`: Maak die stapel uitvoerbaar
-- `MH_NO_REEXPORTED_DYLIBS`: Biblioteek het nie LC_REEXPORT opdragte nie
-- `MH_PIE`: Posisie Onafhanklike Uitvoerbare
-- `MH_HAS_TLV_DESCRIPTORS`: Daar is 'n afdeling met draad plaaslike veranderlikes
-- `MH_NO_HEAP_EXECUTION`: Geen uitvoering vir heap/data bladsye nie
-- `MH_HAS_OBJC`: Binêre het oBject-C afdelings
-- `MH_SIM_SUPPORT`: Simulator ondersteuning
-- `MH_DYLIB_IN_CACHE`: Gebruik op dylibs/raamwerke in gedeelde biblioteek kas.
+- `MH_NOUNDEFS`: No undefined references (fully linked)
+- `MH_DYLDLINK`: Dyld linking
+- `MH_PREBOUND`: Dynamic references prebound.
+- `MH_SPLIT_SEGS`: File splits r/o and r/w segments.
+- `MH_WEAK_DEFINES`: Binary has weak defined symbols
+- `MH_BINDS_TO_WEAK`: Binary uses weak symbols
+- `MH_ALLOW_STACK_EXECUTION`: Make the stack executable
+- `MH_NO_REEXPORTED_DYLIBS`: Library not LC_REEXPORT commands
+- `MH_PIE`: Position Independent Executable
+- `MH_HAS_TLV_DESCRIPTORS`: There is a section with thread local variables
+- `MH_NO_HEAP_EXECUTION`: No execution for heap/data pages
+- `MH_HAS_OBJC`: Binary has oBject-C sections
+- `MH_SIM_SUPPORT`: Simulator support
+- `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
 struct load_command {
 uint32_t cmd;           /* type of load command */
 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**
 
 > [!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	cmdsize;	/* sluit sizeof section_64 strukture in */
-char		segname[16];	/* segmentnaam */
-uint64_t	vmaddr;		/* geheueadres van hierdie segment */
-uint64_t	vmsize;		/* geheuegrootte van hierdie segment */
-uint64_t	fileoff;	/* lêer offset van hierdie segment */
-uint64_t	filesize;	/* hoeveelheid om van die lêer te map */
-int32_t		maxprot;	/* maksimum VM beskerming */
-int32_t		initprot;	/* aanvanklike VM beskerming */
-<strong>	uint32_t	nsects;		/* aantal afdelings in segment */
-</strong>	uint32_t	flags;		/* vlae */
+uint32_t	cmdsize;	/* includes sizeof section_64 structs */
+char		segname[16];	/* segment name */
+uint64_t	vmaddr;		/* memory address of this segment */
+uint64_t	vmsize;		/* memory size of this segment */
+uint64_t	fileoff;	/* file offset of this segment */
+uint64_t	filesize;	/* amount to map from the file */
+int32_t		maxprot;	/* maximum VM protection */
+int32_t		initprot;	/* initial VM protection */
+<strong>	uint32_t	nsects;		/* number of sections in segment */
+</strong>	uint32_t	flags;		/* flags */
 };
 </code></pre>
 
-Voorbeeld van segmentkop:
+Voorbeeld van 'n segment header:
 
 <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
 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 */
 };
 ```
-Voorbeeld van **afdelingskop**:
+Voorbeeld van **afdelingsopskrif**:
 
 <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>
 
-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
 otool -lv /bin/ls
 ```
 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.
-- 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ê.
-- **`__TEXT`**: Bevat **uitvoerbare** **kode** met **lees** en **uitvoer** toestemmings (geen skryfbare)**.** Algemene afdelings van hierdie segment:
-- `__text`: Gecompileerde binêre kode
-- `__const`: Konstant data (slegs lees)
-- `__[c/u/os_log]string`: C, Unicode of os logs string konstantes
-- `__stubs` en `__stubs_helper`: Betrokke tydens die dinamiese biblioteek laai proses
-- `__unwind_info`: Stapel ontrafel 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).
-- **`__DATA`**: Bevat data wat **leesbaar** en **skryfbaar** is (geen uitvoerbare)**.**
-- `__got:` Globale Offset Tabel
-- `__nl_symbol_ptr`: Nie lui (bind by laai) simbool pointer
-- `__la_symbol_ptr`: Lui (bind by gebruik) simbool pointer
-- `__const`: Moet slegs leesbare data wees (nie regtig 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 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 **uitvoering** regte (nie skryfbaar nie). Algemene afdelings van hierdie segment:
+- `__text`: Gekomileerde kode
+- `__const`: Konstantedata (slegs leesbaar)
+- `__[c/u/os_log]string`: C-, Unicode- of os_log-string konstantes
+- `__stubs` and `__stubs_helper`: Betrokke tydens die dinamiese biblioteek-laaiproses
+- `__unwind_info`: Stack unwind-data.
+- 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 (nie uitvoerbaar nie).
+- `__got:` Global Offset Table
+- `__nl_symbol_ptr`: Non lazy (bind at load) symbol pointer
+- `__la_symbol_ptr`: Lazy (bind on use) symbol pointer
+- `__const`: Sou lees-alleen data wees (maar nie regtig nie)
 - `__cfstring`: CoreFoundation strings
-- `__data`: Globale veranderlikes (wat geinitialiseer is)
-- `__bss`: Statiese veranderlikes (wat nie geinitialiseer is nie)
-- `__objc_*` (\_\_objc_classlist, \_\_objc_protolist, ens): 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`.
-- **`__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.
-- dyld inligting: Rebase, Nie-lui/lui/swak binding opcodes en uitvoer info
-- Funksies begin: Tabel van begin adresse van funksies
-- Data In Kode: Data-eilande in \_\_text
-- Simbool Tabel: Simbole in binêre
-- Indirekte Simbool Tabel: Pointer/stub simbole
-- String Tabel
-- Kode Handtekening
-- **`__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.
-- **`__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.
+- `__data`: Globale veranderlikes (wat geïnitialiseer is)
+- `__bss`: Statiese veranderlikes (wat nie geïnitialiseer is nie)
+- `__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 (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 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, Non-lazy/lazy/weak binding opcodes en export-inligting
+- Functions starts: Tabel van beginadresse van funksies
+- Data In Code: Data-eilandjies in \_\_text
+- SYmbol Table: Simbole in die binary
+- Indirect Symbol Table: Pointer/stub-simbole
+- String Table
+- Code Signature
+- **`__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 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_FVMLIB`: Nie gebruik nie
-- `SG_NORELOC`: Segment het geen herlokasie nie
-- `SG_PROTECTED_VERSION_1`: Enkripsie. Gebruik byvoorbeeld deur Finder om teks in die `__TEXT` segment te enkripteer.
+- `SG_HIGHVM`: Core only (not used)
+- `SG_FVMLIB`: Not used
+- `SG_NORELOC`: Segment has no relocation
+- `SG_PROTECTED_VERSION_1`: Encryption. Used for example by Finder to encrypt text `__TEXT` segment.
 
 ### **`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
 otool -l /usr/lib/dyld
 [...]
@@ -286,34 +286,39 @@ cpsr 0x00000000
 ```
 ### **`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.\
-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).
+{{#ref}}
+../../../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]`**
 
-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`**
 
-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`**
 
-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`**
 
-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`**
 
-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`**
 
-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
 struct dylib_command {
 uint32_t        cmd;            /* LC_LOAD_{,WEAK_}DYLIB */
@@ -330,7 +335,7 @@ uint32_t compatibility_version;     /* library's compatibility vers number*/
 ```
 ![](<../../../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
 otool -L /bin/ls
 /bin/ls:
@@ -340,30 +345,30 @@ otool -L /bin/ls
 ```
 Sommige potensiële malware-verwante biblioteke is:
 
-- **DiskArbitration**: Monitering van USB skywe
-- **AVFoundation:** Opname van audio en video
-- **CoreWLAN**: Wifi skandeer.
+- **DiskArbitration**: Monitering van USB-stasies
+- **AVFoundation:** Neem klank en video op
+- **CoreWLAN**: Wi‑Fi-skanderings.
 
-> [!NOTE]
-> 'n Mach-O binêre kan een of **meer** **konstruktore** 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.
+> [!TIP]
+> '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 constructors word gehou in die **\_\_mod_init_func** afdeling van die **\_\_DATA_CONST** segment.
 
 ## **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]
-> 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>)
 
 Dit sluit in:
 
-- **Funksietabel:** Wat inligting oor die programfunksies hou.
-- **Simboltabel**: Wat inligting bevat oor die eksterne funksie wat deur die binêre gebruik word
-- Dit kan ook interne funksie, veranderlike name sowel as meer bevat.
+- **Function table:** Wat inligting oor die program se funksies bevat.
+- **Symbol table**: Wat inligting bevat oor die eksterne funksies wat deur die binary gebruik word
+- 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>
 
@@ -373,20 +378,20 @@ size -m /bin/ls
 ```
 ## Objetive-C Algemene Afdelings
 
-In `__TEXT` segment (r-x):
+In die `__TEXT` segment (r-x):
 
 - `__objc_classname`: Klasname (strings)
-- `__objc_methname`: Metode name (strings)
+- `__objc_methname`: Metodenamme (strings)
 - `__objc_methtype`: Metode tipes (strings)
 
-In `__DATA` segment (rw-):
+In die `__DATA` segment (rw-):
 
-- `__objc_classlist`: Pointers na alle Objetive-C klasse
-- `__objc_nlclslist`: Pointers na Non-Lazy Objective-C klasse
-- `__objc_catlist`: Pointer na Kategories
-- `__objc_nlcatlist`: Pointer na Non-Lazy Kategories
-- `__objc_protolist`: Protokolle lys
-- `__objc_const`: Konstant data
+- `__objc_classlist`: Wysigers na alle Objetive-C klasse
+- `__objc_nlclslist`: Wysigers na Non-Lazy Objective-C klasse
+- `__objc_catlist`: Wysiger na Categories
+- `__objc_nlcatlist`: Wysiger na Non-Lazy Categories
+- `__objc_protolist`: Protokollys
+- `__objc_const`: Konstante data
 - `__objc_imageinfo`, `__objc_selrefs`, `objc__protorefs`...
 
 ## Swift
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-code-signing.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-code-signing.md
index 99e576d80..460035cfd 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-code-signing.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-code-signing.md
@@ -4,12 +4,17 @@
 
 ## 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>
 
-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.\
-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:
+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 [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)));
 ```
-Gewone blobs wat bevat word, 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.
+Gereelde blobs wat ingesluit is, is Code Directory, Requirements en Entitlements en 'n Cryptographic Message Syntax (CMS).\
+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
 
-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
 typedef struct __CodeDirectory {
 uint32_t magic;                                 /* magic number (CSMAGIC_CODEDIRECTORY) */
@@ -101,12 +106,12 @@ char end_withLinkage[0];
 } CS_CodeDirectory
 __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.\
-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.
+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.\
+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
 # Get all hashes of /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
 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 die Vereistes
-- Hash van die Hulpbron Gids (hash van `_CodeSignature/CodeResources` lêer binne die bundel).
-- Toepassing spesifiek (onbenut)
-- Hash van die toelaes
-- DMG kode handtekeninge slegs
-- DER Toelaes
+- Hash van die Requirements
+- Hash van die Resource Directory (hash van die `_CodeSignature/CodeResources`-lêer binne die bundle).
+- Toepassingspesifiek (nie gebruik nie)
+- Hash van die entitlements
+- Slegs DMG code signatures
+- 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
 /* 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)
 ```
-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
 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]
-> Let op hoe hierdie handtekeninge dinge soos sertifiseringsinligting, TeamID, ID's, regte en baie ander data kan nagaan.
+> [!TIP]
+> 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
 # 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
 [...]
 ```
-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.
-- **`SecRequirementEvaluate`**: Valideer vereiste in sertifikaat konteks
-- **`SecTaskValidateForRequirement`**: Valideer 'n lopende SecTask teen `CFString` vereiste.
+- **`Sec[Static]CodeCheckValidity`**: Kontroleer die geldigheid van `SecCodeRef` volgens 'n vereiste.
+- **`SecRequirementEvaluate`**: Valideer 'n vereiste in die sertifikaatkonteks.
+- **`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.
-- **`SecRequirementCreateWithString`:** Skep 'n `SecRequirementRef` uit 'n stringuitdrukking van die vereiste.
-- **`SecRequirementCopy[Data/String]`**: Verkry die binêre data voorstelling van 'n `SecRequirementRef`.
-- **`SecRequirementCreateGroup`**: Skep 'n vereiste vir app-groep lidmaatskap
+- **`SecRequirementCreateWithData`:** Skep 'n `SecRequirementRef` vanaf binêre data wat die vereiste voorstel.
+- **`SecRequirementCreateWithString`:** Skep 'n `SecRequirementRef` vanaf 'n stringuitdrukking van die vereiste.
+- **`SecRequirementCopy[Data/String]`**: Haal die binêre datarepresentasie van 'n `SecRequirementRef`.
+- **`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.
-- **`SecCodeCopySigningInformation`**: Verkry handtekening inligting van 'n `SecCodeRef` of `SecStaticCodeRef`.
+- **`SecStaticCodeCreateWithPath`**: Initialiseer 'n `SecStaticCodeRef` objek vanaf 'n lêerstelselpad om kodehandtekeninge te ondersoek.
+- **`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.
-- **`SecCodeSignerSetRequirement`**: Stel 'n nuwe vereiste vir die kode ondertekenaar in om tydens ondertekening toe te pas.
-- **`SecCodeSignerAddSignature`**: Voeg 'n handtekening by die kode wat onderteken word met die gespesifiseerde ondertekenaar.
+- **`SecCodeSignerCreate`**: Skep 'n `SecCodeSignerRef` objek vir die uitvoering van kodeondertekeningsoperasies.
+- **`SecCodeSignerSetRequirement`**: Stel 'n nuwe vereiste vir die kode-signer wat tydens ondertekening toegepas moet word.
+- **`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**
-- **`SecCodeCopyGuestWithAttributes`**: Skep 'n `SecCodeRef` wat 'n kode objek verteenwoordig gebaseer op spesifieke eienskappe, nuttig vir sandboxing.
-- **`SecCodeCopyPath`**: Verkry die lêerstelsel pad geassosieer met 'n `SecCodeRef`.
-- **`SecCodeCopySigningIdentifier`**: Verkry die handtekening identifiseerder (bv. Span ID) van 'n `SecCodeRef`.
-- **`SecCodeGetTypeID`**: Gee die tipe identifiseerder vir `SecCodeRef` objek.
-- **`SecRequirementGetTypeID`**: Kry 'n CFTypeID van 'n `SecRequirementRef`
+- **`SecCodeCopy[Internal/Designated]Requirement`: Get SecRequirementRef from SecCodeRef**
+- **`SecCodeCopyGuestWithAttributes`**: Skep 'n `SecCodeRef` wat 'n kode-objek voorstel gebaseer op spesifieke eienskappe, nuttig vir sandboxing.
+- **`SecCodeCopyPath`**: Haal die lêerstelselpad wat by 'n `SecCodeRef` hoort.
+- **`SecCodeCopySigningIdentifier`**: Verkry die ondertekeningsidentifiseerder (bv. Team ID) vanaf 'n `SecCodeRef`.
+- **`SecCodeGetTypeID`**: Gee die tipe-identifiseerder vir `SecCodeRef`-objekte terug.
+- **`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.
-- **`kSecCSSigningInformation`**: Vlag wat gebruik word om aan te dui dat handtekening inligting verkry moet word.
+- **`kSecCSDefaultFlags`**: Verstekvlae wat in baie Security.framework-funksies vir kodeondertekeningsoperasies gebruik 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_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
 struct cs_blob {
 struct cs_blob  *csb_next;