<summary><strong>Apprenez le hacking AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Partagez vos astuces de hacking en soumettant des PR aux dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
Mach utilise les **tâches** comme **unité la plus petite** pour partager des ressources, et chaque tâche peut contenir **plusieurs fils d'exécution**. Ces **tâches et fils d'exécution sont mappés 1:1 aux processus et fils d'exécution POSIX**.
La communication entre les tâches se fait via la Communication Inter-Processus Mach (IPC), utilisant des canaux de communication unidirectionnels. **Les messages sont transférés entre les ports**, qui agissent comme des **files d'attente de messages** gérées par le noyau.
Chaque processus a une **table IPC**, où il est possible de trouver les **ports mach du processus**. Le nom d'un port mach est en fait un nombre (un pointeur vers l'objet du noyau).
Un processus peut également envoyer un nom de port avec certains droits **à une autre tâche** et le noyau fera apparaître cette entrée dans la **table IPC de l'autre tâche**.
Les droits de port, qui définissent les opérations qu'une tâche peut effectuer, sont essentiels à cette communication. Les **droits de port** possibles sont :
* **Droit de réception**, qui permet de recevoir des messages envoyés au port. Les ports Mach sont des files d'attente MPSC (multiple-producer, single-consumer), ce qui signifie qu'il ne peut y avoir **qu'un seul droit de réception pour chaque port** dans tout le système (contrairement aux pipes, où plusieurs processus peuvent tous détenir des descripteurs de fichiers pour l'extrémité de lecture d'un pipe).
* Une **tâche avec le droit de réception** peut recevoir des messages et **créer des droits d'envoi**, lui permettant d'envoyer des messages. À l'origine, seule la **tâche propre a le droit de réception sur son port**.
* **Droit d'envoi**, qui permet d'envoyer des messages au port.
* Le droit d'envoi peut être **cloné** de sorte qu'une tâche possédant un droit d'envoi peut cloner le droit et **l'accorder à une troisième tâche**.
* **Droit d'envoi unique**, qui permet d'envoyer un message au port puis disparaît.
* **Droit de jeu de ports**, qui désigne un _ensemble de ports_ plutôt qu'un seul port. Défiler un message d'un ensemble de ports défile un message de l'un des ports qu'il contient. Les ensembles de ports peuvent être utilisés pour écouter plusieurs ports simultanément, un peu comme `select`/`poll`/`epoll`/`kqueue` dans Unix.
* **Nom mort**, qui n'est pas un véritable droit de port, mais simplement un espace réservé. Lorsqu'un port est détruit, tous les droits de port existants vers le port se transforment en noms morts.
**Les tâches peuvent transférer des droits d'ENVOI à d'autres**, leur permettant d'envoyer des messages en retour. **Les droits d'ENVOI peuvent également être clonés, de sorte qu'une tâche peut dupliquer et donner le droit à une troisième tâche**. Cela, combiné à un processus intermédiaire connu sous le nom de **serveur d'amorçage**, permet une communication efficace entre les tâches.
Comme mentionné, pour établir le canal de communication, le **serveur d'amorçage** (**launchd** sur mac) est impliqué.
1. La tâche **A** initie un **nouveau port**, obtenant un **droit de RÉCEPTION** dans le processus.
2. La tâche **A**, détentrice du droit de RÉCEPTION, **génère un droit d'ENVOI pour le port**.
3. La tâche **A** établit une **connexion** avec le **serveur d'amorçage**, fournissant le **nom de service du port** et le **droit d'ENVOI** via une procédure connue sous le nom d'enregistrement d'amorçage.
4. La tâche **B** interagit avec le **serveur d'amorçage** pour effectuer une recherche d'amorçage **pour le nom de service**. Si réussie, le **serveur duplique le droit d'ENVOI** reçu de la tâche A et **le transmet à la tâche B**.
5. Après avoir acquis un droit d'ENVOI, la tâche **B** est capable de **formuler** un **message** et de l'envoyer **à la tâche A**.
6. Pour une communication bidirectionnelle, la tâche **B** génère généralement un nouveau port avec un droit de **RÉCEPTION** et un droit d'**ENVOI**, et donne le droit d'**ENVOI à la tâche A** afin qu'elle puisse envoyer des messages à la TÂCHE B (communication bidirectionnelle).
Le serveur d'amorçage **ne peut pas authentifier** le nom de service revendiqué par une tâche. Cela signifie qu'une **tâche** pourrait potentiellement **usurper l'identité de n'importe quelle tâche système**, comme faussement **revendiquer un nom de service d'autorisation** puis approuver chaque demande.
Ensuite, Apple stocke les **noms des services fournis par le système** dans des fichiers de configuration sécurisés, situés dans des répertoires **protégés par SIP** : `/System/Library/LaunchDaemons` et `/System/Library/LaunchAgents`. À côté de chaque nom de service, le **binaire associé est également stocké**. Le serveur d'amorçage créera et détiendra un **droit de RÉCEPTION pour chacun de ces noms de service**.
Pour ces services prédéfinis, le **processus de recherche diffère légèrement**. Lorsqu'un nom de service est recherché, launchd démarre le service de manière dynamique. Le nouveau flux de travail est le suivant :
* La tâche **B** initie une recherche d'amorçage **pour un nom de service**.
* **launchd** vérifie si la tâche est en cours d'exécution et si ce n'est pas le cas, **la démarre**.
* La tâche **A** (le service) effectue un **contrôle d'amorçage**. Ici, le **serveur d'amorçage** crée un droit d'ENVOI, le retient et **transfère le droit de RÉCEPTION à la tâche A**.
* launchd duplique le **droit d'ENVOI et l'envoie à la tâche B**.
* La tâche **B** génère un nouveau port avec un droit de **RÉCEPTION** et un droit d'**ENVOI**, et donne le droit d'**ENVOI à la tâche A** (le svc) afin qu'elle puisse envoyer des messages à la TÂCHE B (communication bidirectionnelle).
Cependant, ce processus ne s'applique qu'aux tâches système prédéfinies. Les tâches non systémiques fonctionnent toujours comme décrit à l'origine, ce qui pourrait potentiellement permettre l'usurpation d'identité.
Les messages Mach sont envoyés ou reçus en utilisant la **fonction `mach_msg`** (qui est essentiellement un appel système). Lors de l'envoi, le premier argument pour cet appel doit être le **message**, qui doit commencer par un **`mach_msg_header_t`** suivi par la charge utile réelle :
Le processus qui peut **recevoir** des messages sur un port mach est dit détenir le _**droit de réception**_, tandis que les **expéditeurs** détiennent un droit de _**send**_ ou de _**send-once**_. Comme son nom l'indique, send-once ne peut être utilisé que pour envoyer un seul message puis est invalidé.
Afin de réaliser une **communication bidirectionnelle** facile, un processus peut spécifier un **port mach** dans l'en-tête du message mach appelé le _port de réponse_ (**`msgh_local_port`**) où le **récepteur** du message peut **envoyer une réponse** à ce message. Les bitflags dans **`msgh_bits`** peuvent être utilisés pour **indiquer** qu'un **droit send-once** doit être dérivé et transféré pour ce port (`MACH_MSG_TYPE_MAKE_SEND_ONCE`).
Notez que ce type de communication bidirectionnelle est utilisé dans les messages XPC qui attendent une réponse (`xpc_connection_send_message_with_reply` et `xpc_connection_send_message_with_reply_sync`). Mais **généralement, différents ports sont créés** comme expliqué précédemment pour créer la communication bidirectionnelle.
Notez que **les messages mach sont envoyés via un **_**port mach**_, qui est un canal de communication **à récepteur unique**, **à expéditeurs multiples** intégré dans le noyau mach. **Plusieurs processus** peuvent **envoyer des messages** à un port mach, mais à tout moment, seul **un seul processus peut lire** à partir de celui-ci.
Vous pouvez installer cet outil sur iOS en le téléchargeant depuis [http://newosxbook.com/tools/binpack64-256.tar.gz](http://newosxbook.com/tools/binpack64-256.tar.gz)
Remarquez comment l'**expéditeur** **alloue** un port, crée un **droit d'envoi** pour le nom `org.darlinghq.example` et l'envoie au **serveur de démarrage** tandis que l'expéditeur a demandé le **droit d'envoi** de ce nom et l'a utilisé pour **envoyer un message**.
* **Port hôte** : Si un processus a le privilège **Send** sur ce port, il peut obtenir des **informations** sur le **système** (par exemple, `host_processor_info`).
* **Port priv hôte** : Un processus avec le droit **Send** sur ce port peut effectuer des **actions privilégiées** comme charger une extension de noyau. Le **processus doit être root** pour obtenir cette permission.
* De plus, pour appeler l'API **`kext_request`**, il faut avoir d'autres droits **`com.apple.private.kext*`** qui sont uniquement accordés aux binaires Apple.
* **Port nom de tâche** : Une version non privilégiée du _port de tâche_. Il fait référence à la tâche, mais ne permet pas de la contrôler. La seule chose qui semble être disponible à travers lui est `task_info()`.
* **Port de tâche** (également connu sous le nom de port du noyau)** :** Avec le privilège Send sur ce port, il est possible de contrôler la tâche (lire/écrire en mémoire, créer des threads...).
* Appelez `mach_task_self()` pour **obtenir le nom** de ce port pour la tâche appelante. Ce port est uniquement **hérité** à travers **`exec()`** ; une nouvelle tâche créée avec `fork()` obtient un nouveau port de tâche (dans un cas spécial, une tâche obtient également un nouveau port de tâche après `exec()` dans un binaire suid). La seule façon de lancer une tâche et d'obtenir son port est de réaliser la ["danse d'échange de port"](https://robert.sesek.com/2014/1/changes\_to\_xnu\_mach\_ipc.html) lors d'un `fork()`.
* Voici les restrictions pour accéder au port (de `macos_task_policy` du binaire `AppleMobileFileIntegrity`) :
* Si l'application a le droit **`com.apple.security.get-task-allow`**, les processus du **même utilisateur peuvent accéder au port de tâche** (communément ajouté par Xcode pour le débogage). Le processus de **notarisation** ne le permettra pas pour les versions de production.
* Les applications avec le droit **`com.apple.system-task-ports`** peuvent obtenir le **port de tâche pour n'importe quel** processus, sauf le noyau. Dans les versions antérieures, il était appelé **`task_for_pid-allow`**. Ceci est uniquement accordé aux applications Apple.
* **Root peut accéder aux ports de tâche** des applications **non** compilées avec un runtime **renforcé** (et non issues d'Apple).
**Compilez** le programme précédent et ajoutez les **droits d'accès** pour pouvoir injecter du code avec le même utilisateur (sinon vous devrez utiliser **sudo**).
Since you haven't provided any English text to translate, I'm unable to provide a French translation. If you provide the specific English content from the hacking book that you want translated, I can then assist you with a concise and clear translation into French, while maintaining the original markdown and HTML syntax. Please provide the text, and I'll be happy to help.
Dans macOS, les **threads** peuvent être manipulés via **Mach** ou en utilisant l'**API `pthread` posix**. Le thread que nous avons généré dans l'injection précédente a été créé en utilisant l'API Mach, donc **il n'est pas conforme à posix**.
Il était possible d'**injecter un shellcode simple** pour exécuter une commande parce qu'il **n'avait pas besoin de travailler avec des API conformes à posix**, seulement avec Mach. Des **injections plus complexes** nécessiteraient que le **thread** soit également **conforme à posix**.
Par conséquent, pour **améliorer le thread**, il devrait appeler **`pthread_create_from_mach_thread`** qui va **créer un pthread valide**. Ensuite, ce nouveau pthread pourrait **appeler dlopen** pour **charger une dylib** du système, donc au lieu d'écrire un nouveau shellcode pour effectuer différentes actions, il est possible de charger des bibliothèques personnalisées.
XPC, qui signifie XNU (le noyau utilisé par macOS) inter-Process Communication, est un cadre pour **la communication entre processus** sur macOS et iOS. XPC fournit un mécanisme pour effectuer des **appels de méthodes asynchrones et sécurisés entre différents processus** sur le système. C'est une partie du paradigme de sécurité d'Apple, permettant la **création d'applications séparées par les privilèges** où chaque **composant** fonctionne avec **seulement les permissions nécessaires** pour effectuer son travail, limitant ainsi les dommages potentiels d'un processus compromis.
MIG a été créé pour **simplifier le processus de création de code IPC Mach**. Il **génère le code nécessaire** pour que le serveur et le client puissent communiquer avec une définition donnée. Même si le code généré est peu élégant, un développeur aura juste besoin de l'importer et son code sera beaucoup plus simple qu'auparavant.
<summary><strong>Apprenez le hacking AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Partagez vos astuces de hacking en soumettant des PR aux dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
