Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e automatizar facilmente fluxos de trabalho com as ferramentas comunitárias mais avançadas do mundo.\
* Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Durante o teste, **várias operações serão sugeridas** (conectar ao dispositivo, ler/escrever/fazer upload/fazer download de arquivos, usar algumas ferramentas...). Portanto, se você não sabe como realizar alguma dessas ações, **comece lendo a página**:
Recomenda-se usar a ferramenta [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF) para realizar uma Análise Estática automática no arquivo IPA.
***PIE (Position Independent Executable)**: Quando ativado, o aplicativo é carregado em um endereço de memória aleatório toda vez que é iniciado, tornando mais difícil prever seu endereço de memória inicial.
***Stack Canaries**: Para validar a integridade da pilha, um valor 'canary' é colocado na pilha antes de chamar uma função e é validado novamente quando a função termina.
Confira a análise dinâmica realizada pelo [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF). Você precisará navegar pelas diferentes visualizações e interagir com elas, mas o MobSF irá conectar várias classes e realizar outras ações, preparando um relatório quando você terminar.
Ao direcionar apps que estão instalados no dispositivo, você primeiro precisa descobrir o identificador de pacote correto do aplicativo que deseja analisar. Você pode usar `frida-ps -Uai` para obter todos os apps (`-a`) atualmente instalados (`-i`) no dispositivo USB conectado (`-U`):
Os arquivos `.ipa` são **pacotes compactados**, então você pode alterar a extensão para `.zip` e **descompactá-los**. Um aplicativo **completo e empacotado**, pronto para ser instalado, é comumente chamado de **Bundle**.\
Após descompactá-los, você deve ver `<NOME>.app`, um arquivo compactado que contém o restante dos recursos.
*`PlugIns/` pode conter extensões do aplicativo como arquivos .appex (não presentes no exemplo).
* [`Core Data`](https://developer.apple.com/documentation/coredata): É usado para salvar os dados permanentes do seu aplicativo para uso offline, para armazenar dados temporários em cache e adicionar funcionalidade de desfazer ao seu aplicativo em um único dispositivo. Para sincronizar dados em vários dispositivos em uma única conta do iCloud, o Core Data espelha automaticamente seu esquema em um contêiner do CloudKit.
* [`PkgInfo`](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/ConfigApplications.html): O arquivo `PkgInfo` é uma maneira alternativa de especificar os códigos de tipo e criador do seu aplicativo ou pacote.
* **en.lproj, fr.proj, Base.lproj**: São os pacotes de idioma que contêm recursos para esses idiomas específicos e um recurso padrão caso um idioma não seja suportado.
A lista de propriedades de informações ou `Info.plist` é a principal fonte de informações para um aplicativo iOS. Consiste em um arquivo estruturado contendo pares de **chave-valor** que descrevem informações de configuração essenciais sobre o aplicativo. Na verdade, todos os executáveis empacotados (extensões de aplicativos, frameworks e aplicativos) **devem ter** um arquivo `Info.plist`. Você pode encontrar todas as chaves possíveis na [**Documentação do Desenvolvedor da Apple**](https://developer.apple.com/documentation/bundleresources/information\_property\_list?language=objc).
Aqui está uma lista não exaustiva de algumas informações e as palavras-chave correspondentes que você pode pesquisar facilmente no arquivo `Info.plist` apenas inspecionando o arquivo ou usando `grep -i <palavra-chave> Info.plist`:
No iOS, os aplicativos do sistema podem ser encontrados no diretório `/Applications`, enquanto os aplicativos instalados pelo usuário estão disponíveis em `/private/var/containers/`. No entanto, encontrar a pasta certa apenas navegando no sistema de arquivos não é uma tarefa trivial, pois cada aplicativo recebe um UUID (Identificador Único Universal) de 128 bits aleatório atribuído para os nomes de seus diretórios.
Para obter facilmente as informações do diretório de instalação para aplicativos instalados pelo usuário, você pode usar o comando **`env`** do Objection, que também mostrará todas as informações de diretório do aplicativo:
Essas pastas contêm informações que devem ser examinadas de perto durante as avaliações de segurança do aplicativo (por exemplo, ao analisar os dados armazenados em busca de dados sensíveis).
* Este é o Pacote do Aplicativo, como visto anteriormente no IPA, ele contém dados essenciais do aplicativo, conteúdo estático e o binário compilado do aplicativo.
* Contém todos os **arquivos que não são específicos do usuário**, como **caches**, **preferências**, **cookies** e arquivos de configuração de lista de propriedades (plist).
* Os aplicativos iOS geralmente usam os subdiretórios `Application Support` e `Caches`, mas o aplicativo pode criar subdiretórios personalizados.
* Invisível para os usuários e **os usuários não podem gravar nele**.
* O conteúdo deste diretório **não é copiado**.
* O sistema operacional pode excluir automaticamente os arquivos deste diretório quando o aplicativo não está em execução e o espaço de armazenamento está baixo.
* Use este diretório para gravar **arquivos temporários** que não precisam persistir entre os lançamentos do aplicativo.
* Contém arquivos em cache não persistentes.
* **Invisível** para os usuários.
* O conteúdo deste diretório não é copiado.
* O sistema operacional pode excluir automaticamente os arquivos deste diretório quando o aplicativo não está em execução e o espaço de armazenamento está baixo.
Vamos dar uma olhada mais de perto no diretório do Pacote do Aplicativo (.app) do iGoat-Swift dentro do diretório Bundle (`/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app`):
Dentro da pasta `<nome-do-aplicativo>.app`, você encontrará um arquivo binário chamado `<nome-do-aplicativo>`. Este é o arquivo que será **executado**. Você pode realizar uma inspeção básica do binário com a ferramenta **`otool`**:
No entanto, as melhores opções para desmontar o binário são: [**Hopper**](https://www.hopperapp.com/download.html?) e [**IDA**](https://www.hex-rays.com/products/ida/support/download\_freeware/).
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** com as ferramentas comunitárias mais avançadas do mundo.\
Os seguintes locais para armazenar informações devem ser verificados **logo após a instalação do aplicativo**, **após verificar todas as funcionalidades** do aplicativo e até mesmo após **sair de um usuário e entrar em outro**.\
O objetivo é encontrar **informações sensíveis desprotegidas** do aplicativo (senhas, tokens), do usuário atual e de usuários que fizeram login anteriormente.
Os arquivos **plist** são arquivos XML estruturados que **contêm pares de chave-valor**. É uma forma de armazenar dados persistentes, então às vezes você pode encontrar **informações sensíveis nesses arquivos**. É recomendado verificar esses arquivos após instalar o aplicativo e após usá-lo intensivamente para ver se novos dados são gravados.
A forma mais comum de persistir dados em arquivos plist é através do uso do **NSUserDefaults**. Este arquivo plist é salvo dentro do sandbox do aplicativo em **`Library/Preferences/<appBundleID>.plist`**
A classe [`NSUserDefaults`](https://developer.apple.com/documentation/foundation/nsuserdefaults) fornece uma interface programática para interagir com o sistema padrão. O sistema padrão permite que um aplicativo personalize seu comportamento de acordo com as **preferências do usuário**. Os dados salvos pelo `NSUserDefaults` podem ser visualizados no pacote do aplicativo. Esta classe armazena **dados** em um **arquivo plist**, mas é destinada a ser usada com pequenas quantidades de dados.
[`Core Data`](https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreData/nsfetchedresultscontroller.html#//apple\_ref/doc/uid/TP40001075-CH8-SW1) é um framework para gerenciar a camada de modelo de objetos em seu aplicativo. [O Core Data pode usar o SQLite como seu armazenamento persistente](https://cocoacasts.com/what-is-the-difference-between-core-data-and-sqlite/), mas o próprio framework não é um banco de dados.\
O CoreData não criptografa seus dados por padrão. No entanto, uma camada adicional de criptografia pode ser adicionada ao CoreData. Consulte o [Repositório do GitHub](https://github.com/project-imas/encrypted-core-data) para mais detalhes.
Você pode encontrar as informações do SQLite Core Data de um aplicativo no caminho `/private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support`
É comum que os aplicativos criem seus próprios bancos de dados SQLite. Eles podem estar armazenando dados sensíveis neles e deixando-os sem criptografia. Portanto, é sempre interessante verificar todos os bancos de dados dentro do diretório do aplicativo. Portanto, vá para o diretório do aplicativo onde os dados são salvos (`/private/var/mobile/Containers/Data/Application/{APPID}`)
Eles podem ser aproveitados pelos desenvolvedores de aplicativos para **armazenar e sincronizar dados com um banco de dados hospedado em nuvem NoSQL**. Os dados são armazenados como JSON e são sincronizados em tempo real para cada cliente conectado, e também permanecem disponíveis mesmo quando o aplicativo está offline.
[Realm Objective-C](https://realm.io/docs/objc/latest/) e [Realm Swift](https://realm.io/docs/swift/latest/) não são fornecidos pela Apple, mas ainda valem a pena ser mencionados. Eles **armazenam tudo sem criptografia, a menos que a configuração tenha a criptografia habilitada**.
[Couchbase Lite](https://github.com/couchbase/couchbase-lite-ios) é um mecanismo de banco de dados leve, embutido e orientado a documentos (NoSQL) que pode ser sincronizado. Ele é compilado nativamente para iOS e macOS.
O iOS armazena os cookies dos aplicativos no arquivo **`Library/Cookies/cookies.binarycookies`** dentro da pasta de cada aplicativo. No entanto, os desenvolvedores às vezes decidem salvá-los no **keychain** pois o mencionado **arquivo de cookies pode ser acessado em backups**.
Para inspecionar o arquivo de cookies, você pode usar [**este script em python**](https://github.com/mdegrazia/Safari-Binary-Cookie-Parser) ou usar o comando **`ios cookies get`** do Objection.\
**Você também pode usar o Objection para** converter esses arquivos para um formato JSON e inspecionar os dados.
Por padrão, o NSURLSession armazena dados, como **solicitações e respostas HTTP no banco de dados Cache.db**. Este banco de dados pode conter **dados sensíveis**, se tokens, nomes de usuário ou qualquer outra informação sensível tiver sido armazenada em cache. Para encontrar as informações em cache, abra o diretório de dados do aplicativo (`/var/mobile/Containers/Data/Application/<UUID>`) e vá para `/Library/Caches/<Bundle Identifier>`. O **cache do WebKit também é armazenado no arquivo Cache.db**. O **Objection** pode abrir e interagir com o banco de dados com o comando `sqlite connect Cache.db`, pois é um **banco de dados SQLite normal**.
É **recomendado desativar o armazenamento em cache desses dados**, pois eles podem conter informações sensíveis na solicitação ou resposta. A lista a seguir mostra diferentes maneiras de fazer isso:
1. É recomendado remover as respostas em cache após o logout. Isso pode ser feito com o método fornecido pela Apple chamado [`removeAllCachedResponses`](https://developer.apple.com/documentation/foundation/urlcache/1417802-removeallcachedresponses). Você pode chamar esse método da seguinte forma:
2. Se você não precisa usar os cookies, seria recomendado usar apenas a propriedade [.ephemeral](https://developer.apple.com/documentation/foundation/urlsessionconfiguration/1410529-ephemeral) da configuração URLSession, que desativará o salvamento de cookies e caches.
`Um objeto de configuração de sessão efêmera é semelhante a uma configuração de sessão padrão (consulte default), exceto que o objeto de sessão correspondente não armazena caches, armazenamentos de credenciais ou quaisquer dados relacionados à sessão no disco. Em vez disso, os dados relacionados à sessão são armazenados na RAM. A única vez que uma sessão efêmera grava dados no disco é quando você solicita que ela grave o conteúdo de uma URL em um arquivo.`
3. O cache também pode ser desativado definindo a Política de Cache como [.notAllowed](https://developer.apple.com/documentation/foundation/urlcache/storagepolicy/notallowed). Isso desativará o armazenamento de cache de qualquer forma, seja na memória ou no disco.
Sempre que você pressiona o botão home, o iOS **tira uma captura de tela da tela atual** para poder fazer a transição para o aplicativo de maneira mais suave. No entanto, se houver **dados sensíveis** na tela atual, eles serão **salvos** na **imagem** (que **persiste** mesmo após reinicializações). Essas são as capturas de tela às quais você também pode acessar tocando duas vezes na tela inicial para alternar entre os aplicativos.
A menos que o iPhone esteja com jailbreak, o **atacante** precisa ter **acesso** ao **dispositivo desbloqueado** para ver essas capturas de tela. Por padrão, a última captura de tela é armazenada no sandbox do aplicativo na pasta `Library/Caches/Snapshots/` ou `Library/SplashBoard/Snapshots` (os computadores confiáveis não podem acessar o sistema de arquivos a partir do iOS 7.0).
Uma maneira de evitar esse comportamento indesejado é colocar uma tela em branco ou remover os dados sensíveis antes de tirar a captura de tela usando a função `ApplicationDidEnterBackground()`.
Objective-C é uma linguagem de programação utilizada para desenvolver aplicativos iOS. Ela é baseada na linguagem C e adiciona recursos de programação orientada a objetos. Neste guia, exploraremos técnicas de pentesting para aplicativos iOS escritos em Objective-C.
Antes de começar o pentesting em aplicativos iOS escritos em Objective-C, é necessário configurar o ambiente de trabalho. Aqui estão os passos para configurar o ambiente de pentesting:
1. Instale o Xcode: O Xcode é a IDE oficial da Apple para desenvolvimento de aplicativos iOS. Ele inclui todas as ferramentas necessárias para compilar e depurar aplicativos Objective-C.
2. Configure um dispositivo iOS para depuração: Para testar aplicativos iOS em um dispositivo físico, é necessário configurar o dispositivo para depuração. Isso envolve habilitar o modo de desenvolvedor e permitir a instalação de aplicativos de terceiros.
3. Instale ferramentas de pentesting: Existem várias ferramentas disponíveis para pentesting em aplicativos iOS escritos em Objective-C. Algumas das ferramentas populares incluem o Frida, Cycript e o Burp Suite.
1. Análise de código estático: A análise de código estático envolve a revisão do código-fonte do aplicativo em busca de vulnerabilidades conhecidas. Isso pode incluir a identificação de chamadas inseguras de API, uso inadequado de criptografia e outras práticas de programação inseguras.
2. Interceptação de tráfego de rede: A interceptação de tráfego de rede permite analisar as comunicações entre o aplicativo e o servidor. Isso pode revelar informações sensíveis, como credenciais de login, que estão sendo transmitidas sem criptografia adequada.
3. Injeção de código: A injeção de código envolve a modificação do código do aplicativo em tempo de execução para explorar vulnerabilidades. Isso pode ser usado para contornar verificações de segurança, acessar dados restritos ou executar código malicioso.
4. Teste de autenticação: O teste de autenticação envolve a tentativa de contornar os mecanismos de autenticação do aplicativo para obter acesso não autorizado. Isso pode incluir a tentativa de força bruta de senhas, a exploração de falhas de lógica ou a manipulação de tokens de autenticação.
5. Teste de autorização: O teste de autorização envolve a tentativa de contornar os mecanismos de autorização do aplicativo para acessar recursos restritos. Isso pode incluir a exploração de falhas de controle de acesso, a manipulação de parâmetros de solicitação ou a tentativa de acesso direto a URLs restritas.
O pentesting em aplicativos iOS escritos em Objective-C é uma parte essencial do processo de desenvolvimento seguro. Ao aplicar técnicas de pentesting, é possível identificar e corrigir vulnerabilidades antes que elas sejam exploradas por hackers mal-intencionados.
Isso define a imagem de fundo como `overlayImage.png` sempre que o aplicativo é colocado em segundo plano. Isso impede vazamentos de dados sensíveis, pois `overlayImage.png` sempre substituirá a visualização atual.
Ferramentas como [**Keychain-Dumper**](https://github.com/ptoomey3/Keychain-Dumper) podem ser usadas para extrair o keychain (o dispositivo deve estar com jailbreak).\
**NSURLCredential** é a classe perfeita para **armazenar nome de usuário e senha no keychain**. Não é necessário se preocupar com NSUserDefaults ou qualquer wrapper de keychain.\
Depois que o usuário fizer login, você pode armazenar seu nome de usuário e senha no keychain:
Teclados personalizados podem ser usados para **capturar** as **teclas digitadas** e enviá-las para o servidor do atacante. No entanto, observe que **teclados personalizados que requerem conectividade de rede serão notificados ao usuário**.\
Além disso, o **usuário pode alternar para um teclado diferente** (mais confiável) **para inserir as credenciais**.
Além disso, **aplicativos podem impedir que seus usuários usem teclados personalizados** dentro do aplicativo (ou pelo menos em partes sensíveis do aplicativo).
Observe que, devido à correção automática e sugestões automáticas, o teclado padrão do iOS capturará e armazenará cada palavra não padrão em um arquivo de cache, a menos que o atributo **secureTextEntry** seja definido como **true** ou que **autoCorrectionType** seja definido como **UITextAutoCorrectionTypeNo**.
Por padrão, os teclados **armazenam esse cache** dentro do sandbox do aplicativo no arquivo `Library/Keyboard/{locale}-dynamic-text.dat` ou em `/private/var/mobile/Library/Keyboard/dynamic-text.dat`. No entanto, pode estar salvando os dados em outro local.\
O protocolo [UITextInputTraits](https://developer.apple.com/reference/uikit/uitextinputtraits) é usado para o cache do teclado. As classes UITextField, UITextView e UISearchBar suportam automaticamente esse protocolo e oferecem as seguintes propriedades:
*`var autocorrectionType: UITextAutocorrectionType` determina se a correção automática está ativada durante a digitação. Quando a correção automática está ativada, o objeto de texto rastreia palavras desconhecidas e sugere substituições adequadas, substituindo automaticamente o texto digitado, a menos que o usuário anule a substituição. O valor padrão dessa propriedade é `UITextAutocorrectionTypeDefault`, que, para a maioria dos métodos de entrada, ativa a correção automática.
*`var secureTextEntry: BOOL` determina se a cópia de texto e o cache de texto estão desativados e oculta o texto digitado para `UITextField`. O valor padrão dessa propriedade é `NO`.
* Abra os arquivos xib e storyboard no `Interface Builder` do Xcode e verifique os estados de `Secure Text Entry` e `Correction` no `Attributes Inspector` para o objeto apropriado.
A aplicação deve impedir o armazenamento em cache de informações sensíveis inseridas nos campos de texto. Você pode evitar o armazenamento em cache desabilitando-o programaticamente, usando a diretiva `textObject.autocorrectionType = UITextAutocorrectionTypeNo` nos UITextFields, UITextViews e UISearchBars desejados. Para dados que devem ser mascarados, como PINs e senhas, defina `textObject.secureTextEntry` como `YES`.
As formas mais comuns de depurar código é usando logs, e o aplicativo **pode imprimir informações sensíveis nos logs**.\
Na versão do iOS 6 e abaixo, os logs eram legíveis para todos (um aplicativo malicioso poderia ler logs de outros aplicativos e extrair informações sensíveis de lá). **Hoje em dia, os aplicativos só podem acessar seus próprios logs**.
No entanto, um **atacante** com **acesso físico** a um dispositivo **desbloqueado** pode conectá-lo a um computador e **ler os logs** (observe que os logs gravados no disco por um aplicativo não são removidos se o aplicativo for desinstalado).
É recomendado **navegar por todas as telas** do aplicativo e **interagir** com **todos** os elementos de interface do usuário e **funcionalidades** e fornecer texto de entrada em todos os campos de texto e **revisar os logs** em busca de **informações****sensíveis** expostas.
Muitos aplicativos registram mensagens informativas (e potencialmente sensíveis) no registro do console. O registro também contém relatórios de falhas e outras informações úteis.
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e automatizar facilmente fluxos de trabalho com as ferramentas comunitárias mais avançadas do mundo.\
O iOS inclui recursos de backup automático que criam cópias dos dados armazenados no dispositivo. Você pode fazer **backups do iOS** a partir do seu computador host usando o iTunes (até o macOS Catalina) ou o Finder (a partir do macOS Catalina), ou através do recurso de backup do iCloud. Em ambos os casos, o backup inclui quase todos os dados armazenados no dispositivo iOS, exceto dados altamente sensíveis, como informações do Apple Pay e configurações do Touch ID.
Uma preocupação óbvia é se os backups do iOS podem **vazar acidentalmente dados sensíveis** armazenados pelo aplicativo. Outra preocupação, embora menos óbvia, é se as **configurações de configuração sensíveis usadas para proteger dados ou restringir a funcionalidade do aplicativo podem ser adulteradas para alterar o comportamento do aplicativo após a restauração de um backup modificado**. Ambas as preocupações são válidas e essas vulnerabilidades têm se mostrado existentes em um grande número de aplicativos hoje em dia.
Um backup de um dispositivo em que um aplicativo móvel foi instalado incluirá todos os subdiretórios (exceto `Library/Caches/`) e arquivos no [diretório privado do aplicativo](https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple\_ref/doc/uid/TP40010672-CH2-SW12).\
Portanto, **evite armazenar dados sensíveis em texto simples em qualquer um dos arquivos ou pastas que estão no diretório privado do aplicativo ou subdiretórios**.
Embora todos os arquivos em `Documents/` e `Library/Application Support/` sejam sempre incluídos no backup por padrão, você pode [excluir arquivos do backup](https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple\_ref/doc/uid/TP40010672-CH2-SW28) chamando `NSURL setResourceValue:forKey:error:` com a chave `NSURLIsExcludedFromBackupKey`.\
Você pode usar as propriedades do sistema de arquivos [NSURLIsExcludedFromBackupKey](https://developer.apple.com/reference/foundation/nsurl#//apple\_ref/c/data/NSURLIsExcludedFromBackupKey) e [CFURLIsExcludedFromBackupKey](https://developer.apple.com/reference/corefoundation/cfurl-rd7#//apple\_ref/c/data/kCFURLIsExcludedFromBackupKey) para excluir arquivos e diretórios de backups.
Portanto, ao verificar o backup de um aplicativo, verifique se **alguma informação sensível** é acessível e se você pode **modificar algum comportamento sensível** do aplicativo **modificando alguma configuração do backup** e restaurando o backup.
Comece **criando um backup do dispositivo** (você pode fazer isso usando o Finder) e encontre onde o backup está armazenado. A documentação oficial da Apple irá ajudá-lo a [localizar backups do seu iPhone, iPad e iPod touch](https://support.apple.com/en-us/HT204215).
Depois de encontrar o backup do dispositivo (`/Users/carlos.martin/Library/Application Support/MobileSync/Backup/{deviceID}`), você pode começar a procurar informações sensíveis usando o comando grep, por exemplo, ou usando ferramentas como [iMazing](https://imazing.com)).
Para identificar se um backup está criptografado, você pode verificar a chave chamada "IsEncrypted" do arquivo "Manifest.plist", localizado na raiz do diretório de backup. O exemplo a seguir mostra uma configuração que indica que o backup está criptografado:
Caso precise trabalhar com um backup criptografado, existem alguns scripts em Python no repositório do GitHub da DinoSec, como **backup_tool.py** e **backup_passwd.py**, que servirão como um bom ponto de partida. No entanto, observe que eles podem não funcionar com as versões mais recentes do iTunes/Finder e podem precisar ser ajustados.
No aplicativo de carteira de bitcoin de código aberto, Bither, você verá que é possível configurar um PIN para bloquear a interface do usuário. Esse PIN é armazenado no arquivo `net.bither.plist` dentro da **chave****pin_code**. Se você limpar essa chave do plist no backup e restaurar o backup, poderá acessar a carteira.
Em algum momento, informações sensíveis serão armazenadas na memória. O objetivo é garantir que essas informações sejam expostas pelo menor tempo possível.
Para investigar a memória de um aplicativo, primeiro crie um **dump de memória**. Alternativamente, você pode **analisar a memória em tempo real** com, por exemplo, um depurador. Independentemente do método que você usar, esse é um processo propenso a erros, pois os dumps fornecem os dados deixados pelas funções executadas e você pode perder etapas críticas. Além disso, é muito fácil ignorar dados durante a análise, a menos que você conheça o formato ou o valor exato dos dados que está procurando. Por exemplo, se o aplicativo criptografa de acordo com uma chave simétrica gerada aleatoriamente, é muito improvável que você encontre a chave na memória, a menos que encontre seu valor por outros meios.
Seja usando um dispositivo com jailbreak ou sem jailbreak, você pode fazer o dump da memória do processo do aplicativo com o [objection](https://github.com/sensepost/objection) e o [Fridump](https://github.com/Nightbringer21/fridump).
Após o dump da memória (por exemplo, em um arquivo chamado "memory"), dependendo da natureza dos dados que você está procurando, você precisará de um conjunto de ferramentas diferentes para processar e analisar esse dump de memória. Por exemplo, se você estiver focando em strings, pode ser suficiente executar o comando `strings` ou `rabin2 -zz` para extrair essas strings.
No entanto, se você deseja inspecionar outros tipos de dados, é melhor usar o radare2 e suas capacidades de pesquisa. Consulte a ajuda do radare2 no comando de pesquisa (`/?`) para obter mais informações e uma lista de opções. O seguinte mostra apenas um subconjunto delas:
Usando o [**r2frida**](https://github.com/nowsecure/r2frida), você pode analisar e inspecionar a memória do aplicativo enquanto ele está em execução, sem precisar fazer o dump dela. Por exemplo, você pode executar os comandos de pesquisa anteriores do r2frida e pesquisar a memória por uma string, valores hexadecimais, etc. Ao fazer isso, lembre-se de adicionar uma barra invertida `\` antes do comando de pesquisa (e de qualquer outro comando específico do r2frida) após iniciar a sessão com `r2 frida://usb//<nome_do_seu_app>`.
Alguns desenvolvedores salvam dados sensíveis no armazenamento local e os criptografam com uma chave codificada/predizível no código. Isso não deve ser feito, pois a reversão pode permitir que os atacantes extraiam as informações confidenciais.
Os desenvolvedores não devem usar **algoritmos obsoletos** para realizar **verificações** de autorização, **armazenar** ou **enviar** dados. Alguns desses algoritmos são: RC4, MD4, MD5, SHA1... Se forem usados **hashes** para armazenar senhas, por exemplo, devem ser usados hashes **resistentes** a ataques de força bruta com sal.
As principais verificações a serem realizadas são encontrar senhas/segredos **codificados** no código, ou se eles são **previsíveis**, e se o código está usando algum tipo de algoritmo de **criptografia****fraco**.
Para **mais informações** sobre APIs e bibliotecas criptográficas do iOS, acesse [https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography](https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography)
O testador deve estar ciente de que a **autenticação local deve sempre ser aplicada em um ponto remoto** ou com base em uma primitiva criptográfica. Os atacantes podem facilmente contornar a autenticação local se nenhum dado for retornado do processo de autenticação.
O [**framework de Autenticação Local**](https://developer.apple.com/documentation/localauthentication) fornece um conjunto de APIs para os desenvolvedores estenderem um diálogo de autenticação para um usuário. No contexto de conexão com um serviço remoto, é possível (e recomendado) aproveitar o [keychain](https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html) para implementar a autenticação local.
O sensor de **identificação por impressão digital** é operado pelo [coprocessador de segurança SecureEnclave](https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-Demystifying-The-Secure-Enclave-Processor.pdf) e não expõe os dados da impressão digital para outras partes do sistema. Além do Touch ID, a Apple introduziu o _Face ID_: que permite a autenticação com base no reconhecimento facial.
*`LocalAuthentication.framework` é uma API de alto nível que pode ser usada para **autenticar o usuário via Touch ID**. O aplicativo não pode acessar nenhum dado associado à impressão digital registrada e é notificado apenas se a autenticação foi bem-sucedida.
*`Security.framework` é uma API de nível inferior para acessar [serviços de keychain](https://developer.apple.com/documentation/security/keychain\_services). Essa é uma opção segura se o seu aplicativo precisar **proteger alguns dados secretos com autenticação biométrica**, pois o controle de acesso é gerenciado em nível de sistema e não pode ser facilmente contornado. `Security.framework` possui uma API em C, mas existem várias [bibliotecas de código aberto disponíveis](https://www.raywenderlich.com/147308/secure-ios-user-data-keychain-touch-id), tornando o acesso ao keychain tão simples quanto ao NSUserDefaults.
Esteja ciente de que o uso do `LocalAuthentication.framework` ou do `Security.framework` pode ser contornado por um atacante, pois ele retorna apenas um valor booleano e nenhum dado para prosseguir. Veja [Don't touch me that way, por David Lindner et al](https://www.youtube.com/watch?v=XhXIHVGCFFM) para mais detalhes.
Os desenvolvedores podem exibir uma **solicitação de autenticação** utilizando a função **`evaluatePolicy`** da classe **`LAContext`**. Duas políticas disponíveis definem formas aceitáveis de autenticação:
*`deviceOwnerAuthentication`(Swift) ou `LAPolicyDeviceOwnerAuthentication`(Objective-C): Quando disponível, o usuário é solicitado a realizar a autenticação do Touch ID. Se o Touch ID não estiver ativado, o código de acesso do dispositivo é solicitado. Se o código de acesso do dispositivo não estiver habilitado, a avaliação da política falha.
*`deviceOwnerAuthenticationWithBiometrics` (Swift) ou `LAPolicyDeviceOwnerAuthenticationWithBiometrics`(Objective-C): A autenticação é restrita a biometria, onde o usuário é solicitado a usar o Touch ID.
A função **`evaluatePolicy` retorna um valor booleano** indicando se o usuário foi autenticado com sucesso. Isso significa que pode ser facilmente contornado (veja abaixo)
As APIs do **keychain do iOS podem (e devem) ser usadas para implementar a autenticação local**. Durante esse processo, o aplicativo armazena um token de autenticação secreto ou outro dado secreto que identifica o usuário no keychain. Para autenticar em um serviço remoto, o usuário deve desbloquear o keychain usando sua senha ou impressão digital para obter os dados secretos.
O keychain permite salvar itens com o atributo especial `SecAccessControl`, que permitirá o acesso ao item apenas após o usuário passar pela autenticação do Touch ID (ou código de acesso, se tal fallback for permitido pelos parâmetros do atributo).
No exemplo a seguir, vamos salvar a string "test\_strong\_password" no keychain. A string só pode ser acessada no dispositivo atual enquanto o código de acesso estiver definido (parâmetro `kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly`) e após a autenticação do Touch ID para as impressões digitais atualmente registradas (parâmetro `SecAccessControlCreateFlags.biometryCurrentSet`):
Agora podemos solicitar o item salvo no keychain. Os serviços do keychain apresentarão a caixa de diálogo de autenticação ao usuário e retornarão os dados ou nil, dependendo se uma impressão digital adequada foi fornecida ou não.
```swift
let query: [String: Any] = [
kSecClass as String: kSecClassGenericPassword,
kSecAttrService as String: "MyApp",
kSecAttrAccount as String: "username",
kSecReturnData as String: true
]
var item: CFTypeRef?
let status = SecItemCopyMatching(query as CFDictionary, &item)
if status == errSecSuccess {
let passwordData = item as! Data
let password = String(data: passwordData, encoding: .utf8)
Este guia fornece uma visão geral das técnicas de pentesting para aplicativos iOS. Ele abrange várias áreas, incluindo análise estática e dinâmica, engenharia reversa, manipulação de dados em trânsito e em repouso, e exploração de vulnerabilidades comuns.
## Análise Estática
A análise estática envolve a revisão do código-fonte do aplicativo em busca de vulnerabilidades conhecidas e práticas inseguras. Isso pode ser feito usando ferramentas como o `grep` para procurar por palavras-chave específicas, ou usando ferramentas de análise estática automatizadas, como o `clang` ou o `Infer`.
## Análise Dinâmica
A análise dinâmica envolve a execução do aplicativo em um ambiente controlado para identificar vulnerabilidades em tempo de execução. Isso pode ser feito usando ferramentas como o `Frida` para injetar código em tempo de execução ou usando um proxy para interceptar e modificar o tráfego de rede.
## Engenharia Reversa
A engenharia reversa envolve a desmontagem do código binário do aplicativo para entender seu funcionamento interno. Isso pode ser feito usando ferramentas como o `Hopper` ou o `IDA Pro` para analisar o código de montagem e identificar vulnerabilidades ou comportamentos indesejados.
## Manipulação de Dados em Trânsito e em Repouso
A manipulação de dados em trânsito e em repouso envolve a identificação e exploração de vulnerabilidades relacionadas à criptografia, autenticação e armazenamento de dados sensíveis. Isso pode ser feito usando ferramentas como o `Wireshark` para capturar e analisar o tráfego de rede ou usando ferramentas de descompilação para examinar o código do aplicativo em busca de práticas inseguras.
## Exploração de Vulnerabilidades Comuns
A exploração de vulnerabilidades comuns envolve a identificação e exploração de vulnerabilidades conhecidas, como injeção de SQL, cross-site scripting (XSS) e deserialização insegura. Isso pode ser feito usando ferramentas como o `Burp Suite` para interceptar e modificar solicitações HTTP ou usando técnicas de fuzzing para encontrar entradas maliciosas que possam levar a vulnerabilidades.
## Conclusão
Este guia fornece uma visão geral das técnicas de pentesting para aplicativos iOS. No entanto, é importante lembrar que a segurança é um processo contínuo e que as técnicas e ferramentas estão sempre evoluindo. É essencial manter-se atualizado com as últimas práticas recomendadas e estar ciente das vulnerabilidades mais recentes para garantir a segurança dos aplicativos iOS.
O uso de frameworks em um aplicativo também pode ser detectado analisando a lista de bibliotecas dinâmicas compartilhadas do binário do aplicativo. Isso pode ser feito usando o `otool`:
Se o `LocalAuthentication.framework` for usado em um aplicativo, a saída conterá ambas as seguintes linhas (lembre-se de que o `LocalAuthentication.framework` usa o `Security.framework` por baixo dos panos):
[**Bypass de Biometria do Objeção**](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass) pode ser usado para contornar a autenticação local. O Objeção **usa o Frida para instrumentar a função `evaluatePolicy` para que ela retorne `True`** mesmo que a autenticação não tenha sido realizada com sucesso. Use o comando `ios ui biometrics_bypass` para contornar a autenticação biométrica insegura. O Objeção registrará um trabalho, que substituirá o resultado do `evaluatePolicy`. Isso funcionará tanto em implementações Swift quanto Objective-C.
[TouchIDAuthentication showAlert:@"Your device doesn't support Touch ID or you haven't configured Touch ID authentication on your device" withTitle:@"Error"];
Para contornar a Autenticação Local, precisamos escrever um script Frida que **contorne** a verificação mencionada do _**evaluatePolicy**. Como você pode ver no trecho de código acima, o **evaluatePolicy** usa um **callback** que determina o **resultado**. Portanto, a maneira mais fácil de realizar o hack é interceptar esse callback e garantir que ele sempre retorne o_**success=1**.
É importante verificar se não há comunicação ocorrendo **sem criptografia** e também se o aplicativo está corretamente **validando o certificado TLS** do servidor.\
Um problema comum na validação do certificado TLS é verificar se o certificado foi assinado por uma **CA confiável**, mas **não verificar** se **o nome do host** do certificado é o nome do host sendo acessado.\
Para verificar esse problema usando o Burp, depois de confiar no CA do Burp no iPhone, você pode **criar um novo certificado com o Burp para um nome de host diferente** e usá-lo. Se o aplicativo ainda funcionar, então algo está vulnerável.
Se um aplicativo estiver usando corretamente a Pinagem SSL, então o aplicativo só funcionará se o certificado for o esperado. Ao testar um aplicativo, **isso pode ser um problema, pois o Burp irá fornecer seu próprio certificado.**\
Para contornar essa proteção em um dispositivo com jailbreak, você pode instalar o aplicativo [**SSL Kill Switch**](https://github.com/nabla-c0d3/ssl-kill-switch2) ou instalar [**Burp Mobile Assistant**](https://portswigger.net/burp/documentation/desktop/mobile/config-ios-device)
* **`/Library/*`**: Contém as preferências e o cache. Em **`/Library/Cache/Snapshots/*`**, você pode encontrar o snapshot realizado pelo aplicativo antes de enviá-lo para o plano de fundo.
Os desenvolvedores podem **corrigir remotamente todas as instalações de seu aplicativo instantaneamente**, sem precisar enviar o aplicativo novamente para a App Store e esperar pela aprovação.\
Para esse propósito, geralmente é usado o [**JSPatch**](https://github.com/bang590/JSPatch)**.** Mas também existem outras opções, como [Siren](https://github.com/ArtSabintsev/Siren) e [react-native-appstore-version-checker](https://www.npmjs.com/package/react-native-appstore-version-checker).\
**Esse é um mecanismo perigoso que pode ser abusado por SDKs maliciosos de terceiros, portanto, é recomendado verificar qual método é usado para atualização automática (se houver) e testá-lo.** Você pode tentar baixar uma versão anterior do aplicativo para esse propósito.
Um problema dos SDKs de terceiros é que não há **controle granular sobre as funcionalidades oferecidas pelo SDK**. Você pode usar o SDK e ter todas as funcionalidades (incluindo vazamentos de diagnóstico e conexões HTTP inseguras), ou não usá-lo. Além disso, geralmente não é possível para os desenvolvedores de aplicativos **corrigir uma vulnerabilidade** no SDK.\
Além disso, alguns SDKs começam a **conter malware quando são muito confiáveis** pela comunidade.
Além disso, os serviços fornecidos por esses SDKs podem envolver **serviços de rastreamento para monitorar o comportamento do usuário** ao usar o aplicativo, vender anúncios em banner ou melhorar a experiência do usuário. A desvantagem dos serviços de terceiros é que os desenvolvedores não conhecem os detalhes do código executado por meio das bibliotecas de terceiros. Consequentemente, não deve ser enviado mais informações do que o necessário para um serviço e nenhuma informação sensível deve ser divulgada.
A desvantagem é que um **desenvolvedor não sabe em detalhes qual código é executado por meio de bibliotecas de terceiros** e, portanto, abre mão da visibilidade. Consequentemente, deve-se garantir que apenas as informações necessárias sejam enviadas ao serviço e que nenhuma informação sensível seja divulgada.
Todos os dados enviados para serviços de terceiros devem ser anonimizados para evitar a exposição de PII (Informações de Identificação Pessoal) que permitiria que a terceira parte identificasse a conta do usuário.
Você pode encontrar as **bibliotecas usadas por um aplicativo** executando o comando **`otool`** no aplicativo (e **executando** o comando **em cada** biblioteca **compartilhada** para encontrar mais bibliotecas compartilhadas usadas).
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** com as ferramentas comunitárias mais avançadas do mundo.\
* Você trabalha em uma **empresa de segurança cibernética**? Gostaria de ver sua **empresa anunciada no HackTricks**? Ou gostaria de ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
