Registros de falhas e ofuscação: um curso intensivo

Depurar uma falha em tempo de execução pode ser um processo doloroso. Quando um aplicativo iOS trava em uso intenso.O dispositivo possui apenas informações sobre os endereços de memória e os deslocamentos do processo em execução no momento da falha. Essas informações são apresentadas como um rastreamento de pilha, uma lista de chamadas de método em ordem de execução mais recente, indicando onde a falha ocorreu. Os rastreamentos de pilha podem ter diferentes níveis de detalhamento, e existem mecanismos para ajudar os desenvolvedores a extrair o máximo proveito deles. 

No entanto, um equívoco comum entre engenheiros focados em segurança é que um aplicativo com segurança reforçada impede o funcionamento de ferramentas de depuração de campo comuns (como o Firebase Crashlytics), tornando ainda mais difícil a compreensão das falhas do aplicativo. Isso não precisa ser assim; um aplicativo pode ter tanto segurança robusta quanto registros de falhas relevantes e acionáveis. Então, como conseguimos isso? 

Para ajudar a obter registros de falhas legíveis para aplicativos iOS em produção, os desenvolvedores podem utilizar arquivos dSYM. Os arquivos dSYM contêm informações de símbolos para depuração e podem ser gerados pelo Xcode durante o processo de compilação. Analisaremos o conteúdo desses arquivos, por que eles são úteis e como utilizá-los. Digital.ai Application Security Os produtos se integram a esse mecanismo para possibilitar a depuração de seu aplicativo seguro. 

Vamos analisar um exemplo usando nossa plataforma de código aberto. Despachante de Empregos Aplicativo iOS.  

O que contém um pacote dSYM? 

Um pacote dSYM (abreviação de símbolos de depuração) contém símbolos e informações sobre as linhas de código-fonte do seu aplicativo iOS/tvOS/macOS. Esses pacotes são gerados pelo Xcode quando a opção "Formato de informações de depuração" está definida como "DWARF com arquivo dSYM" para a configuração de compilação que você está usando.

Você deve estar se perguntando: por que teríamos todos os nossos símbolos em um arquivo separado em vez de dentro do próprio aplicativo? O principal motivo é a portabilidade para depuração. Você pode compilar um aplicativo e depurá-lo em outra máquina sem precisar dos arquivos objeto usados ​​na compilação. O dSYM também permite depurar versões de lançamento do seu aplicativo, o que pode representar uma enorme economia de tempo.  

Agora que apresentamos o que é o dSYM – e um pouco sobre por que ele é importante – vamos abrir o arquivo .xcarchive que acabamos de criar e dar uma olhada no pacote 'Job Dispatcher.app.dSYM' abaixo.

O Job Dispatcher possui apenas um pacote para o aplicativo principal, mas outros podem ser gerados se o seu projeto compilar bibliotecas ou frameworks adicionais durante o processo de compilação. 

Então, o que exatamente contém o pacote dSYM? Se clicarmos com o botão direito do mouse no pacote e selecionarmos "Mostrar conteúdo do pacote", podemos ver o seguinte:

Tele 'Info.plist' lima apenas por contém metdados sobre o bse libertar e não é muito útil. Bambos os 'Trabalho Dispatcher.yml' arquivo e o 'Despachante de Empregos Mach-O depurador lima não contenho símbolo nomes e locais e são aquilo que nos importa.. Vamos primeiro Abrir a 'Trabalho Dispatcher.yml' lima (Imagem truncada por questões de brevidade):

Aqui, podemos ver uma lista de propriedades para cada símbolo no binário. Por exemplo, 'tamanho'. está relacionado ao tamanho do ponteiro (todos esses são símbolos de 64 bits), 'symName' corresponde ao nome do símbolo, 'symBinAddr' é onde o símbolo existe no próprio binário, e 'tamanho simbólico' é o tamanho da função ou do objeto de dados. Este arquivo se concentra em informações de realocação, que são uma parte importante da arquitetura AArch64, mas não vamos nos aprofundar nisso aqui.  

Vamos agora analisar o arquivo na pasta DWARF chamado 'Job Dispatcher'. Este arquivo binário contém informações detalhadas de depuração para todos os símbolos do aplicativo que criamos (como você pode ver, o nome do arquivo DWARF e do aplicativo são os mesmos). Podemos executar o comando 'dwarfdump' nele para obter um dump legível das informações contidas neste arquivo. Vamos dar uma olhada no autenticar símbolo:

Algumas propriedades notáveis ​​são as Arquivo DW_AT_decl e DW_AT_decl_line, que nos dizem que o autenticar A função foi definida no arquivo 'LoginFunc.m' na linha 13. Outra propriedade é a DW_AT_tipo, que nos dá o tipo da função (que é um booleano neste caso). Cada símbolo tem uma seção como esta no arquivo DWARF com informações explicando o que ele é e onde foi definido, entre outras coisas. 

Embora o conteúdo do pacote dSYM possa ser bastante difícil de analisar, não é algo que todos precisem saber para utilizá-lo. Agora vamos examinar o que o dSYM realmente faz por nós ao tentar depurar uma falha em tempo real. 

dSYM em ação 

Vamos observar o poder do dSYM em ação, forçando uma falha no Job Dispatcher. Podemos fazer isso atribuindo um valor a um ponteiro nulo nas linhas 14 e 15 do arquivo. autenticar função:

Ao Executamos o aplicativo comfora um aassociado dSYM, o aplicativo trava, e Obtemos um rastreamento de pilha como este:

AQUI, é Certamente é possível depurar um aplicativo. usando essas informações. Cada O quadro de pilha contém informações sobre o endereço da falha. e os deslocamentos do (bastante inútil) Nome do símbolo onde ocorre a falha. Contudo, vocêA compreensão desse rastreamento de pilha requers análise profunda do binário em si e fornece quase nada introspecção para dentro Qual parte do código-fonte está causando o problema?. Compare este resultado com um registro de falha com dSYM INFORMAÇÕES disponível:

Cada quadro de pilha ainda contém o endereço onde o aplicativo travou, mas as informações do símbolo estão muito mais completas. Podemos ver que a falha ocorreu em _autenticar A função na linha 15 de 'LoginFunc.m' (exatamente onde provocamos a falha em nosso código-fonte) é o objetivo de todas as ferramentas de relatório de falhas (Firebase Crashlytics, BugSnag, Instabug, etc.), e é por isso que essas ferramentas exigem que você envie um pacote dSYM para conseguir isso. 

Onde a segurança de aplicativos se encaixa nisso tudo? 

Tudo o que discutimos sobre dSYM até agora pressupõe que o aplicativo criado com o Xcode permaneça completamente inalterado. Mas o que acontece se quisermos proteger nosso aplicativo de agentes mal-intencionados antes de enviá-lo para a App Store? 

Bem, durante a proteção, o binário é reorganizado de forma que as localizações dos símbolos recém-ofuscados não correspondam mais às informações encontradas no pacote dSYM. Se tentarmos simbolizar uma falha em nosso aplicativo protegido com o pacote dSYM do aplicativo desprotegido, os resultados não farão sentido. Há algo que possamos fazer para corrigir isso? 

Proteções pós-construção versus proteções durante a construção 

Os nossos Proteção de aplicativos para dispositivos móveis: ARM O produto é uma solução de proteção pós-compilação que pode ser usada sem qualquer configuração. Isso facilita a proteção de um aplicativo contra agentes maliciosos e permite que os desenvolvedores tenham um ciclo de feedback mais eficiente ao testar o aplicativo protegido, pois ele precisa ser compilado apenas uma vez. No entanto, como mencionado anteriormente, isso tem a ressalva de que o pacote dSYM original é incompatível com o aplicativo protegido. Os desenvolvedores devem reescrever os arquivos dSYM após a proteção para levar em conta as alterações no código e simbolizar possíveis falhas. 

Por outro lado, podemos proteger um aplicativo sem precisar reescrever os arquivos dSYM gerados pelo Xcode. Nosso produto App Protection for Apple Native possui essa capacidade por ser uma solução de proteção integrada. O aplicativo é compilado e vinculado com diversos recursos de segurança habilitados juntamente com o código-fonte original. Isso possibilita a simbolização de um aplicativo protegido, já que os arquivos dSYM gerados são estruturados para contemplar tudo o que foi especificado na compilação. A desvantagem é que as proteções em tempo de compilação exigem mais configuração por parte do desenvolvedor, o que pode se tornar mais complexo à medida que o aplicativo cresce e se torna mais difícil de gerenciar. 

Envolvendo as Coisas 

Esperamos que isso tenha dado uma ideia da importância dos pacotes dSYM, o que eles contêm, como são usados ​​e as soluções existentes para garantir que os engenheiros focados em segurança não precisem fazer sacrifícios para utilizar ferramentas que facilitam a depuração de aplicativos iOS.