macOS Universal binaries & Mach-O Format
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Os binários do Mac OS geralmente são compilados como binários universais. Um binário universal pode suportar múltiplas arquiteturas no mesmo arquivo.
Esses binários seguem a estrutura Mach-O, que é basicamente composta por:
Cabeçalho
Comandos de Carregamento
Dados
Procure pelo arquivo com: mdfind fat.h | grep -i mach-o | grep -E "fat.h$"
O cabeçalho tem os bytes mágicos seguidos pelo número de arquiteturas que o arquivo contém (nfat_arch) e cada arquitetura terá uma struct fat_arch.
Verifique com:
ou usando a ferramenta Mach-O View:
Como você pode estar pensando, geralmente um binário universal compilado para 2 arquiteturas dobra o tamanho de um compilado para apenas 1 arquitetura.
O cabeçalho contém informações básicas sobre o arquivo, como bytes mágicos para identificá-lo como um arquivo Mach-O e informações sobre a arquitetura alvo. Você pode encontrá-lo em: mdfind loader.h | grep -i mach-o | grep -E "loader.h$"
Existem diferentes tipos de arquivos, que podem ser encontrados definidos no código-fonte, por exemplo aqui. Os mais importantes são:
MH_OBJECT: Arquivo objeto relocável (produtos intermediários da compilação, ainda não executáveis).
MH_EXECUTE: Arquivos executáveis.
MH_FVMLIB: Arquivo de biblioteca VM fixa.
MH_CORE: Dumps de código.
MH_PRELOAD: Arquivo executável pré-carregado (não mais suportado no XNU).
MH_DYLIB: Bibliotecas dinâmicas.
MH_DYLINKER: Linker dinâmico.
MH_BUNDLE: "Arquivos de plugin". Gerados usando -bundle no gcc e carregados explicitamente por NSBundle ou dlopen.
MH_DYSM: Arquivo companheiro .dSym (arquivo com símbolos para depuração).
MH_KEXT_BUNDLE: Extensões do Kernel.
Ou usando Mach-O View:
O código-fonte também define várias flags úteis para carregar bibliotecas:
MH_NOUNDEFS: Sem referências indefinidas (totalmente vinculado)
MH_DYLDLINK: Vinculação Dyld
MH_PREBOUND: Referências dinâmicas pré-vinculadas.
MH_SPLIT_SEGS: Arquivo divide segmentos r/o e r/w.
MH_WEAK_DEFINES: O binário tem símbolos definidos fracos
MH_BINDS_TO_WEAK: O binário usa símbolos fracos
MH_ALLOW_STACK_EXECUTION: Torna a pilha executável
MH_NO_REEXPORTED_DYLIBS: Biblioteca não possui comandos LC_REEXPORT
MH_PIE: Executável Independente de Posição
MH_HAS_TLV_DESCRIPTORS: Há uma seção com variáveis locais de thread
MH_NO_HEAP_EXECUTION: Sem execução para páginas de heap/dados
MH_HAS_OBJC: O binário tem seções oBject-C
MH_SIM_SUPPORT: Suporte a simulador
MH_DYLIB_IN_CACHE: Usado em dylibs/frameworks no cache de biblioteca compartilhada.
O layout do arquivo na memória é especificado aqui, detalhando a localização da tabela de símbolos, o contexto da thread principal no início da execução e as bibliotecas compartilhadas necessárias. Instruções são fornecidas ao carregador dinâmico (dyld) sobre o processo de carregamento do binário na memória.
O utiliza a estrutura load_command, definida no mencionado loader.h:
Existem cerca de 50 tipos diferentes de comandos de carregamento que o sistema trata de maneira diferente. Os mais comuns são: LC_SEGMENT_64, LC_LOAD_DYLINKER, LC_MAIN, LC_LOAD_DYLIB e LC_CODE_SIGNATURE.
Basicamente, este tipo de Comando de Carregamento define como carregar o __TEXT (código executável) e __DATA (dados para o processo) segmentos de acordo com os offsets indicados na seção de Dados quando o binário é executado.
Esses comandos definem segmentos que são mapeados no espaço de memória virtual de um processo quando ele é executado.
Existem diferentes tipos de segmentos, como o __TEXT segmento, que contém o código executável de um programa, e o __DATA segmento, que contém dados usados pelo processo. Esses segmentos estão localizados na seção de dados do arquivo Mach-O.
Cada segmento pode ser ainda dividido em múltiplas seções. A estrutura do comando de carregamento contém informações sobre essas seções dentro do respectivo segmento.
No cabeçalho, primeiro você encontra o cabeçalho do segmento:
Exemplo de cabeçalho de segmento:
Este cabeçalho define o número de seções cujos cabeçalhos aparecem depois dele:
Exemplo de cabeçalho de seção:
Se você adicionar o offset da seção (0x37DC) + o offset onde a arquitetura começa, neste caso 0x18000 --> 0x37DC + 0x18000 = 0x1B7DC
Também é possível obter informações de cabeçalhos a partir da linha de comando com:
Comuns segmentos carregados por este cmd:
__PAGEZERO: Instruções para o kernel mapear o endereço zero para que não possa ser lido, escrito ou executado. As variáveis maxprot e minprot na estrutura são definidas como zero para indicar que não há direitos de leitura-gravação-execução nesta página.
Esta alocação é importante para mitigar vulnerabilidades de desreferência de ponteiro NULL. Isso ocorre porque o XNU impõe uma página zero rígida que garante que a primeira página (apenas a primeira) da memória seja inacessível (exceto em i386). Um binário poderia atender a esses requisitos criando um pequeno __PAGEZERO (usando o -pagezero_size) para cobrir os primeiros 4k e tendo o restante da memória de 32 bits acessível tanto em modo de usuário quanto em modo kernel.
__TEXT: Contém código executável com permissões de leitura e execução (sem permissões de escrita). Seções comuns deste segmento:
__text: Código binário compilado
__const: Dados constantes (somente leitura)
__[c/u/os_log]string: Constantes de string C, Unicode ou logs do os
__stubs e __stubs_helper: Envolvidos durante o processo de carregamento da biblioteca dinâmica
__unwind_info: Dados de desempilhamento.
Note que todo esse conteúdo é assinado, mas também marcado como executável (criando mais opções para exploração de seções que não necessariamente precisam desse privilégio, como seções dedicadas a strings).
__DATA: Contém dados que são legíveis e graváveis (sem executável).
__got: Tabela de Deslocamento Global
__nl_symbol_ptr: Ponteiro de símbolo não preguiçoso (vinculado no carregamento)
__la_symbol_ptr: Ponteiro de símbolo preguiçoso (vinculado no uso)
__const: Deveria ser dados somente leitura (não é realmente)
__cfstring: Strings do CoreFoundation
__data: Variáveis globais (que foram inicializadas)
__bss: Variáveis estáticas (que não foram inicializadas)
__objc_* (__objc_classlist, __objc_protolist, etc): Informações usadas pelo runtime do Objective-C
__DATA_CONST: __DATA.__const não é garantido que seja constante (permissões de escrita), nem outros ponteiros e a GOT. Esta seção torna __const, alguns inicializadores e a tabela GOT (uma vez resolvida) somente leitura usando mprotect.
__LINKEDIT: Contém informações para o linker (dyld), como entradas de tabela de símbolos, strings e relocação. É um contêiner genérico para conteúdos que não estão em __TEXT ou __DATA e seu conteúdo é descrito em outros comandos de carregamento.
Informações do dyld: Rebase, opcodes de vinculação não preguiçosa/preguiçosa/fraca e informações de exportação
Inícios de funções: Tabela de endereços de início de funções
Dados em Código: Ilhas de dados em __text
Tabela de Símbolos: Símbolos no binário
Tabela de Símbolos Indiretos: Símbolos de ponteiro/stub
Tabela de Strings
Assinatura de Código
__OBJC: Contém informações usadas pelo runtime do Objective-C. Embora essas informações também possam ser encontradas no segmento __DATA, dentro de várias seções em __objc_*.
__RESTRICT: Um segmento sem conteúdo com uma única seção chamada __restrict (também vazia) que garante que, ao executar o binário, ele ignorará variáveis ambientais DYLD.
Como foi possível ver no código, os segmentos também suportam flags (embora não sejam muito utilizados):
SG_HIGHVM: Apenas núcleo (não utilizado)
SG_FVMLIB: Não utilizado
SG_NORELOC: O segmento não tem relocação
SG_PROTECTED_VERSION_1: Criptografia. Usado, por exemplo, pelo Finder para criptografar o segmento __TEXT.
LC_UNIXTHREAD/LC_MAINLC_MAIN contém o ponto de entrada no atributo entryoff. No momento do carregamento, dyld simplesmente adiciona esse valor à (em memória) base do binário, então salta para essa instrução para iniciar a execução do código do binário.
LC_UNIXTHREAD contém os valores que o registrador deve ter ao iniciar a thread principal. Isso já foi descontinuado, mas dyld ainda o utiliza. É possível ver os valores dos registradores definidos por isso com:
LC_CODE_SIGNATUREContém informações sobre a assinatura de código do arquivo Macho-O. Ele contém apenas um offset que aponta para o blob de assinatura. Isso geralmente está no final do arquivo. No entanto, você pode encontrar algumas informações sobre esta seção em este post de blog e neste gists.
LC_ENCRYPTION_INFO[_64]Suporte para criptografia binária. No entanto, é claro que, se um atacante conseguir comprometer o processo, ele poderá despejar a memória sem criptografia.
LC_LOAD_DYLINKERContém o caminho para o executável do linker dinâmico que mapeia bibliotecas compartilhadas no espaço de endereço do processo. O valor é sempre definido como /usr/lib/dyld. É importante notar que no macOS, o mapeamento de dylib acontece em modo de usuário, não em modo de kernel.
LC_IDENTObsoleto, mas quando configurado para gerar dumps em caso de pânico, um core dump Mach-O é criado e a versão do kernel é definida no comando LC_IDENT.
LC_UUIDUUID aleatório. É útil para qualquer coisa diretamente, mas o XNU o armazena em cache com o resto das informações do processo. Pode ser usado em relatórios de falhas.
LC_DYLD_ENVIRONMENTPermite indicar variáveis de ambiente para o dyld antes que o processo seja executado. Isso pode ser muito perigoso, pois pode permitir a execução de código arbitrário dentro do processo, então este comando de carga é usado apenas em builds do dyld com #define SUPPORT_LC_DYLD_ENVIRONMENT e restringe ainda mais o processamento apenas para variáveis da forma DYLD_..._PATH especificando caminhos de carga.
LC_LOAD_DYLIBEste comando de carga descreve uma dependência de biblioteca dinâmica que instrui o loader (dyld) a carregar e vincular a referida biblioteca. Há um comando de carga LC_LOAD_DYLIB para cada biblioteca que o binário Mach-O requer.
Este comando de carga é uma estrutura do tipo dylib_command (que contém uma struct dylib, descrevendo a biblioteca dinâmica dependente real):
Você também pode obter essas informações pelo cli com:
Algumas bibliotecas relacionadas a malware potenciais são:
DiskArbitration: Monitoramento de drives USB
AVFoundation: Captura de áudio e vídeo
CoreWLAN: Scans de Wifi.
Um binário Mach-O pode conter um ou mais construtores, que serão executados antes do endereço especificado em LC_MAIN. Os offsets de quaisquer construtores são mantidos na seção __mod_init_func do segmento __DATA_CONST.
No núcleo do arquivo está a região de dados, que é composta por vários segmentos conforme definido na região de comandos de carregamento. Uma variedade de seções de dados pode ser hospedada dentro de cada segmento, com cada seção contendo código ou dados específicos a um tipo.
Os dados são basicamente a parte que contém todas as informações que são carregadas pelos comandos de carregamento LC_SEGMENTS_64
Isso inclui:
Tabela de funções: Que contém informações sobre as funções do programa.
Tabela de símbolos: Que contém informações sobre a função externa usada pelo binário
Também pode conter nomes de funções internas, variáveis e mais.
Para verificar, você pode usar a ferramenta Mach-O View:
Ou a partir da linha de comando:
No segmento __TEXT (r-x):
__objc_classname: Nomes das classes (strings)
__objc_methname: Nomes dos métodos (strings)
__objc_methtype: Tipos de métodos (strings)
No segmento __DATA (rw-):
__objc_classlist: Ponteiros para todas as classes Objetive-C
__objc_nlclslist: Ponteiros para classes Objetive-C Não-Lazy
__objc_catlist: Ponteiro para Categorias
__objc_nlcatlist: Ponteiro para Categorias Não-Lazy
__objc_protolist: Lista de Protocolos
__objc_const: Dados constantes
__objc_imageinfo, __objc_selrefs, objc__protorefs...
_swift_typeref, _swift3_capture, _swift3_assocty, _swift3_types, _swift3_proto, _swift3_fieldmd, _swift3_builtin, _swift3_reflstr
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
