<summary><strong>Aprenda hacking no AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao grupo [**telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios github** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
Mach usa **tarefas** como a **menor unidade** para compartilhamento de recursos, e cada tarefa pode conter **múltiplas threads**. Essas **tarefas e threads são mapeadas 1:1 para processos e threads POSIX**.
A comunicação entre tarefas ocorre via Comunicação Interprocesso Mach (IPC), utilizando canais de comunicação unidirecionais. **Mensagens são transferidas entre portas**, que atuam como **filas de mensagens** gerenciadas pelo kernel.
Cada processo tem uma **tabela IPC**, onde é possível encontrar os **portos mach do processo**. O nome de um porto mach é na verdade um número (um ponteiro para o objeto do kernel).
Um processo também pode enviar um nome de porto com alguns direitos **para uma tarefa diferente** e o kernel fará com que esta entrada na **tabela IPC da outra tarefa** apareça.
Direitos de porto, que definem quais operações uma tarefa pode realizar, são fundamentais para essa comunicação. Os possíveis **direitos de porto** são:
* **Direito de Receber**, que permite receber mensagens enviadas ao porto. Portos Mach são filas MPSC (multiple-producer, single-consumer), o que significa que pode haver apenas **um direito de receber para cada porto** em todo o sistema (diferente de pipes, onde múltiplos processos podem manter descritores de arquivo para o final de leitura de um pipe).
* Uma **tarefa com o Direito de Receber** pode receber mensagens e **criar Direitos de Enviar**, permitindo que ela envie mensagens. Originalmente apenas a **própria tarefa tem o Direito de Receber sobre seu porto**.
* **Direito de Enviar**, que permite enviar mensagens ao porto.
* O Direito de Enviar pode ser **clonado** para que uma tarefa que possui um Direito de Enviar possa clonar o direito e **concedê-lo a uma terceira tarefa**.
* **Direito de Enviar uma vez**, que permite enviar uma mensagem ao porto e depois desaparece.
* **Direito de Conjunto de Portos**, que denota um _conjunto de portos_ em vez de um único porto. Desenfileirar uma mensagem de um conjunto de portos desenfileira uma mensagem de um dos portos que ele contém. Conjuntos de portos podem ser usados para ouvir vários portos simultaneamente, muito parecido com `select`/`poll`/`epoll`/`kqueue` no Unix.
* **Nome Morto**, que não é um direito de porto real, mas apenas um marcador. Quando um porto é destruído, todos os direitos de porto existentes para o porto se transformam em nomes mortos.
**Tarefas podem transferir direitos de ENVIAR para outras**, permitindo que elas enviem mensagens de volta. **Direitos de ENVIAR também podem ser clonados, então uma tarefa pode duplicar e dar o direito a uma terceira tarefa**. Isso, combinado com um processo intermediário conhecido como **servidor bootstrap**, permite uma comunicação eficaz entre tarefas.
1. A tarefa **A** inicia um **novo porto**, obtendo um **direito de RECEBER** no processo.
2. A tarefa **A**, sendo detentora do direito de RECEBER, **gera um direito de ENVIAR para o porto**.
3. A tarefa **A** estabelece uma **conexão** com o **servidor bootstrap**, fornecendo o **nome do serviço do porto** e o **direito de ENVIAR** através de um procedimento conhecido como registro bootstrap.
4. A tarefa **B** interage com o **servidor bootstrap** para executar uma busca bootstrap **pelo nome do serviço**. Se bem-sucedido, o **servidor duplica o direito de ENVIAR** recebido da Tarefa A e **transmite-o à Tarefa B**.
5. Ao adquirir um direito de ENVIAR, a Tarefa **B** é capaz de **formular** uma **mensagem** e enviá-la **para a Tarefa A**.
6. Para uma comunicação bidirecional, geralmente a tarefa **B** gera um novo porto com um direito de **RECEBER** e um direito de **ENVIAR**, e concede o **direito de ENVIAR à Tarefa A** para que ela possa enviar mensagens para a TAREFA B (comunicação bidirecional).
O servidor bootstrap **não pode autenticar** o nome do serviço reivindicado por uma tarefa. Isso significa que uma **tarefa** poderia potencialmente **se passar por qualquer tarefa do sistema**, como falsamente **reivindicando um nome de serviço de autorização** e então aprovando cada solicitação.
Então, a Apple armazena os **nomes dos serviços fornecidos pelo sistema** em arquivos de configuração seguros, localizados em diretórios **protegidos pelo SIP**: `/System/Library/LaunchDaemons` e `/System/Library/LaunchAgents`. Ao lado de cada nome de serviço, o **binário associado também é armazenado**. O servidor bootstrap, criará e manterá um **direito de RECEBER para cada um desses nomes de serviço**.
Para esses serviços pré-definidos, o **processo de busca difere ligeiramente**. Quando um nome de serviço está sendo procurado, o launchd inicia o serviço dinamicamente. O novo fluxo de trabalho é o seguinte:
* A tarefa **B** inicia uma busca bootstrap **pelo nome do serviço**.
* **launchd** verifica se a tarefa está em execução e, se não estiver, **inicia** ela.
* A tarefa **A** (o serviço) realiza um **check-in bootstrap**. Aqui, o **servidor bootstrap** cria um direito de ENVIAR, retém-o e **transfere o direito de RECEBER para a Tarefa A**.
* launchd duplica o **direito de ENVIAR e envia-o para a Tarefa B**.
* A tarefa **B** gera um novo porto com um direito de **RECEBER** e um direito de **ENVIAR**, e concede o **direito de ENVIAR à Tarefa A** (o svc) para que ela possa enviar mensagens para a TAREFA B (comunicação bidirecional).
No entanto, esse processo só se aplica a tarefas de sistema pré-definidas. Tarefas não-sistema ainda operam como descrito originalmente, o que poderia potencialmente permitir a personificação.
Mensagens Mach são enviadas ou recebidas usando a **função `mach_msg`** (que é essencialmente uma syscall). Ao enviar, o primeiro argumento para essa chamada deve ser a **mensagem**, que deve começar com um **`mach_msg_header_t`** seguido pelo payload real:
O processo que pode **receber** mensagens em uma porta mach é dito possuir o _**direito de recebimento**_ (**receive right**), enquanto os **remetentes** possuem um _**direito de envio**_ (**send**) ou um _**direito de envio único**_ (**send-once**_** right**). Envio único, como o nome implica, só pode ser usado para enviar uma única mensagem e depois é invalidado.
Para alcançar uma **comunicação bidirecional** fácil, um processo pode especificar uma **porta mach** no cabeçalho da mensagem mach chamada _porta de resposta_ (**`msgh_local_port`**), onde o **receptor** da mensagem pode **enviar uma resposta** a esta mensagem. Os bitflags em **`msgh_bits`** podem ser usados para **indicar** que um **direito de envio único** deve ser derivado e transferido para esta porta (`MACH_MSG_TYPE_MAKE_SEND_ONCE`).
Note que esse tipo de comunicação bidirecional é usado em mensagens XPC que esperam uma resposta (`xpc_connection_send_message_with_reply` e `xpc_connection_send_message_with_reply_sync`). Mas **geralmente portas diferentes são criadas** como explicado anteriormente para criar a comunicação bidirecional.
Note que **mensagens mach são enviadas através de uma **_**porta mach**_, que é um canal de comunicação **único receptor**, **múltiplos remetentes** incorporado no kernel mach. **Múltiplos processos** podem **enviar mensagens** para uma porta mach, mas em qualquer momento apenas **um único processo pode ler** dela.
Você pode instalar esta ferramenta no iOS baixando-a de [http://newosxbook.com/tools/binpack64-256.tar.gz](http://newosxbook.com/tools/binpack64-256.tar.gz)
Observe como o **remetente****aloca** uma porta, cria um **direito de envio** para o nome `org.darlinghq.example` e o envia para o **servidor de inicialização** enquanto o remetente solicitou o **direito de envio** desse nome e o usou para **enviar uma mensagem**.
* **Porta do host**: Se um processo tem privilégio de **Enviar** sobre esta porta, ele pode obter **informações** sobre o **sistema** (por exemplo, `host_processor_info`).
* **Porta priv do host**: Um processo com direito de **Enviar** sobre esta porta pode realizar **ações privilegiadas** como carregar uma extensão do kernel. O **processo precisa ser root** para obter essa permissão.
* Além disso, para chamar a API **`kext_request`**, é necessário ter outros direitos **`com.apple.private.kext*`**, que são concedidos apenas a binários da Apple.
* **Porta do nome da tarefa**: Uma versão não privilegiada da _porta da tarefa_. Ela referencia a tarefa, mas não permite controlá-la. A única coisa que parece estar disponível através dela é `task_info()`.
* **Porta da tarefa** (também conhecida como porta do kernel)**:** Com permissão de Enviar sobre esta porta, é possível controlar a tarefa (ler/escrever memória, criar threads...).
* Chame `mach_task_self()` para **obter o nome** desta porta para a tarefa chamadora. Esta porta é apenas **herdada** através de **`exec()`**; uma nova tarefa criada com `fork()` recebe uma nova porta da tarefa (como um caso especial, uma tarefa também recebe uma nova porta da tarefa após `exec()` em um binário suid). A única maneira de gerar uma tarefa e obter sua porta é realizar a ["dança da troca de portas"](https://robert.sesek.com/2014/1/changes\_to\_xnu\_mach\_ipc.html) durante um `fork()`.
* Estas são as restrições para acessar a porta (de `macos_task_policy` do binário `AppleMobileFileIntegrity`):
* Se o aplicativo tem o direito **`com.apple.security.get-task-allow`**, processos do **mesmo usuário podem acessar a porta da tarefa** (comumente adicionado pelo Xcode para depuração). O processo de **notarização** não permitirá isso em lançamentos de produção.
* Aplicativos com o direito **`com.apple.system-task-ports`** podem obter a **porta da tarefa para qualquer** processo, exceto o kernel. Em versões anteriores, era chamado de **`task_for_pid-allow`**. Isso é concedido apenas a aplicativos da Apple.
* **Root pode acessar portas de tarefas** de aplicativos **não** compilados com um runtime **endurecido** (e não da Apple).
**Compile** o programa anterior e adicione os **entitlements** para poder injetar código com o mesmo usuário (caso contrário, será necessário usar **sudo**).
Since there is no content provided from the hacking book, I cannot proceed with a translation. If you provide the specific English text you want to be translated into Portuguese, I will be able to assist you. Please provide the text, and I'll take care of the rest.
No macOS, **threads** podem ser manipuladas via **Mach** ou usando a **API `pthread` do posix**. A thread que geramos na injeção anterior foi criada usando a API Mach, então **não é compatível com posix**.
Foi possível **injetar um shellcode simples** para executar um comando porque **não precisava trabalhar com APIs compatíveis com posix**, apenas com Mach. **Injeções mais complexas** precisariam que a **thread** também fosse **compatível com posix**.
Portanto, para **melhorar a thread**, ela deve chamar **`pthread_create_from_mach_thread`**, que irá **criar um pthread válido**. Então, este novo pthread poderia **chamar dlopen** para **carregar uma dylib** do sistema, então, em vez de escrever um novo shellcode para realizar diferentes ações, é possível carregar bibliotecas personalizadas.
XPC, que significa XNU (o kernel usado pelo macOS) Comunicação Inter-Processos, é um framework para **comunicação entre processos** no macOS e iOS. O XPC fornece um mecanismo para fazer **chamadas de métodos assíncronas e seguras entre diferentes processos** no sistema. É parte do paradigma de segurança da Apple, permitindo a **criação de aplicações com separação de privilégios** onde cada **componente** executa com **apenas as permissões necessárias** para realizar seu trabalho, limitando assim o potencial dano de um processo comprometido.
MIG foi criado para **simplificar o processo de criação de código IPC Mach**. Basicamente, **gera o código necessário** para que o servidor e o cliente se comuniquem com uma definição dada. Mesmo que o código gerado seja feio, um desenvolvedor só precisará importá-lo e seu código será muito mais simples do que antes.
<summary><strong>Aprenda hacking no AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**merchandising oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao grupo [**telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios do GitHub** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
