Jailbreak Detection em aplicativos iOS: essência, métodos de detecção e verificação

O que é Jailbreak Detection?

Jailbreak Detection é o processo de identificar dispositivos iOS que tiveram suas restrições do sistema operacional removidas. O jailbreak modifica o kernel do iOS, desativa a assinatura de código, fornece acesso ao sistema de arquivos completo e permite carregar bibliotecas não autorizadas. Para um aplicativo executado em tal dispositivo, não há garantias de integridade do ambiente de execução: qualquer processo pode ler a memória do aplicativo, interceptar tráfego SSL/TLS instalando seus próprios certificados no armazenamento confiável do sistema e injetar código via Cydia Substrate ou Substitute.

Aplicativos financeiros no iOS são obrigados a implementar Jailbreak Detection de acordo com os padrões PCI DSS — para certificação, o aplicativo deve provar que não está sendo executado em um dispositivo comprometido. O OWASP Mobile Security (2024) classifica a ausência de Jailbreak Detection como vulnerabilidade M8. Para aplicativos da App Store, a Apple não proíbe bloquear a funcionalidade em dispositivos com jailbreak, mas recomenda combinar verificações do lado do cliente e do servidor para não depender exclusivamente do código do cliente que pode ser modificado.

A arquitetura do Jailbreak Detection no iOS é mais complexa que o Root Detection no Android devido ao modelo de sandbox. No Android, um aplicativo pode ler /proc para analisar o sistema. A sandbox do iOS bloqueia o acesso direto à maioria dos indicadores do sistema. Os desenvolvedores são forçados a usar técnicas alternativas, como verificar a disponibilidade de arquivos em zonas restritas através da API canAccessFile ou iniciar processos filhos via fork() com verificação do código de saída. As verificações modernas são construídas tentando ações disponíveis apenas sob jailbreak e analisando o resultado.

Métodos de Detecção Baseados em Arquivos

A abordagem mais simples e historicamente primeira é verificar a presença de arquivos e aplicativos que só são instalados em dispositivos com jailbreak. Apesar da simplicidade, as verificações de arquivos continuam sendo uma camada básica de defesa, pois contorná-las exige ação ativa do usuário.

Verificação de Pacotes de Jailbreak

Em um dispositivo com jailbreak, aplicativos como Cydia, Sileo, Zebra ou Installer estão presentes. Sua presença é verificada via NSFileManager: [[NSFileManager defaultManager] fileExistsAtPath:@"/Applications/Cydia.app"]. Pacotes do unc0ver, checkra1n, Taurine e Chimera são verificados de forma similar. Essas verificações podem ser contornadas através de tweaks HideJB que interceptam chamadas do NSFileManager.

Verificação de Utilitários em /usr/bin

O jailbreak instala utilitários UNIX indisponíveis no iOS padrão: apt, dpkg, ssh, rsync, sftp, dd, readlink e outros. A existência de /usr/bin/ssh, /bin/bash, /bin/sh e /usr/libexec/sftp-server é verificada. Se qualquer um desses arquivos for detectado com sucesso, a probabilidade de jailbreak é alta. Para iOS 13–17, também é relevante verificar a presença de /var/jb — o diretório raiz de bootstrap para unc0ver e Taurine.

Verificação de Bibliotecas Dinâmicas

MobileSubstrate (CydiaSubstrate.dylib) e Substitute são bibliotecas para injeção de código em processos. Sua presença é verificada via dlopen() com a flag RTLD_NOLOAD. Se a biblioteca estiver carregada no espaço de endereços — o processo está executando em um ambiente com jailbreak. Esta é uma verificação mais confiável, pois o HideJB não pode descarregar uma biblioteca já carregada em um processo.

- (BOOL)isJailbrokenByFiles {
    NSArray *paths = @[
        @"/Applications/Cydia.app",
        @"/Applications/Sileo.app",
        @"/Applications/Zebra.app",
        @"/usr/bin/ssh",
        @"/bin/bash",
        @"/var/jb",
        @"/etc/apt"
    ];

    for (NSString *path in paths) {
        if ([[NSFileManager defaultManager]
            fileExistsAtPath:path]) {
            return YES;
        }
    }
    return NO;
}

- (BOOL)isSubstrateLoaded {
    void *handle = dlopen(
        "/Library/MobileSubstrate/MobileSubstrate.dylib",
        RTLD_NOLOAD | RTLD_LAZY
    );
    if (handle) {
        dlclose(handle);
        return YES;
    }
    return NO;
}

Verificações Dinâmicas em Tempo de Execução

As verificações dinâmicas realizam ações proibidas na sandbox do iOS e analisam o resultado. Se a ação não for bloqueada — o dispositivo provavelmente está com jailbreak.

Verificação de fork() e posix_spawn()

No iOS padrão, a chamada fork() retorna -1 com errno = EPERM. Em um dispositivo com jailbreak, fork() pode ser bem-sucedido, pois as restrições da sandbox são removidas. Esta verificação é confiável, mas pode produzir falsos positivos em algumas versões do iOS. fork() também pode ser substituído por posix_spawn() para verificar a capacidade de iniciar um processo filho.

Verificação da Assinatura do Sistema Sandbox

Tentativa de ler arquivos em zonas restritas: /etc/master.passwd, /var/log/system.log, /private/var/cache. No iOS padrão, essas leituras retornam um erro. Se o aplicativo ler esses arquivos com sucesso — a sandbox está desativada. Adicionalmente, a capacidade de escrever em /private/ é verificada — em uma sandbox, todas as partições do sistema são montadas como somente leitura para aplicativos normais.

Verificação de Símbolos do Sistema

O jailbreak modifica bibliotecas do sistema, incluindo o cache compartilhado do dyld. Verificar o hash de frameworks do sistema ou símbolos individuais pode revelar a modificação. Para iOS 14+, a presença do símbolo jit_region_create ou outros sinais de operação do Fugu14/checkra1n no espaço de endereço do kernel é verificada através da leitura de sysctl kern.version.

- (BOOL)isJailbrokenByRuntime {
    // Verificando fork()
    int pid = fork();
    if (pid == 0) {
        exit(0);
    }
    if (pid > 0) {
        waitpid(pid, NULL, 0);
        return YES;
    }

    // Verificando acesso a arquivos do sistema
    FILE *f = fopen("/etc/master.passwd", "r");
    if (f) {
        fclose(f);
        return YES;
    }

    // Verificando sysctl kern.version
    size_t size = 0;
    sysctlbyname("kern.version", NULL, &size, NULL, 0);
    if (size > 0) {
        char *version = malloc(size);
        sysctlbyname("kern.version", version, &size, NULL, 0);
        NSString *str = [NSString stringWithUTF8String:version];
        free(version);
        if ([str containsString:"pwned"]) {
            return YES;
        }
    }

    return NO;
}

Implementação Nativa em Objective-C

O código Swift é facilmente desmontado e contornado via Substrate. Uma implementação nativa em Objective-C com chamadas diretas ao libobjc e funções do sistema C torna as verificações significativamente mais resistentes a contornos.

Uso de stat() em vez de NSFileManager

A chamada stat() da libc não pode ser interceptada no nível Objective-C. Os tweaks HideJB que interceptam métodos do NSFileManager não afetam stat(). Uma verificação nativa usando stat() detecta indicadores de arquivo mesmo em dispositivos com módulos HideJB instalados. A combinação de stat() para arquivos e dlopen() com RTLD_NOLOAD para bibliotecas fornece dois canais de detecção não sobrepostos.

Verificação de Integridade da Assinatura de Código

A função nativa SecStaticCodeCheckValidity verifica a assinatura de código do aplicativo contra o certificado da Apple. Em um dispositivo com jailbreak, esta verificação pode ser falsificada através de um patch do kernel. Para evitar a falsificação, a verificação deve ser realizada a partir de código nativo com uma chamada através de dlopen() do Security.framework, em vez de através do Swift Bridge.

#import <sys/stat.h>
#import <dlfcn.h>

- (BOOL)nativeCheckForJailbreak {
    // stat() contornando o hook do NSFileManager
    struct stat st;
    if (stat("/Applications/Cydia.app", &st) == 0) {
        return YES;
    }

    // dlopen para verificar Substrate sem carregar
    void *substrate = dlopen(
        "/Library/MobileSubstrate/MobileSubstrate.dylib",
        RTLD_NOLOAD
    );
    if (substrate) {
        dlclose(substrate);
        return YES;
    }

    return NO;
}

Métodos de Evasão do Jailbreak Detection

Compreender as técnicas de evasão é essencial para construir uma proteção robusta. As ferramentas modernas de evasão estão evoluindo ativamente, e um conjunto estático de verificações torna-se ineficaz em questão de meses.

HideJB e Shadow

HideJB é um tweak que intercepta chamadas para NSFileManager, stat(), dlopen() e fork(), substituindo os valores de retorno. HideJB funciona no nível do Cydia Substrate, interceptando funções Objective-C e C. A versão do HideJB para iOS 15–16 (Shadow) usa metodologia de hooks em nível de kernel. Contramedida: realize a verificação em um processo separado com entrega do resultado via IPC, o que quebra a cadeia de hooks.

Choicy e Liberty Lite

Choicy permite desativar o Substrate para processos específicos. O usuário simplesmente desativa a injeção para o aplicativo protegido — todas as verificações de biblioteca retornam false. Liberty Lite é uma evasão abrangente que cobre a maioria das verificações de bibliotecas de proteção populares. Contramedida: verificação no lado do servidor via DeviceCheck e App Attest — o servidor verifica se o dispositivo possui um certificado Apple válido que não pode ser falsificado em um dispositivo com jailbreak.

Evasão via Fugu14 e KFD

Exploits do kernel, como Fugu14 e KFD, executam código no espaço do kernel, permitindo interceptar chamadas de sistema antes que o aplicativo as veja. Neste nível, as verificações stat() e fork() tornam-se ineficazes. A única contramedida confiável é a atestacão no lado do servidor com verificação de que o dispositivo passou pelo procedimento Apple Attestation. Este protocolo é baseado em chaves criptográficas dentro do Secure Enclave, que são ilegíveis mesmo com um exploit em nível de kernel.

Arquitetura de Segurança iOS e o Papel do Jailbreak

Para construir uma detecção de jailbreak eficaz, é necessário entender quais mecanismos de segurança do iOS são desativados durante o jailbreak.

Cadeia de Inicialização Segura (Secure Boot Chain)

O iOS inicializa através de uma sequência de verificações de assinatura: Boot ROM → iBoot → iOS Kernel. Se o jailbreak usar um exploit de bootrom (checkra1n), toda a cadeia de inicialização segura é comprometida — as verificações em nível de aplicativo são inúteis. Se for usado um exploit apenas de software (unc0ver, Taurine, Fugu14), a cadeia de inicialização não é quebrada e serviços da Apple como App Attest permanecem confiáveis.

Proteção de Patch do Kernel (KPP)

A partir do iOS 10, a Apple introduziu o KPP — proteção de hardware que verifica novamente a integridade do kernel a cada 200 ms. Todos os jailbreaks modernos (iOS 14–17) usam bypass de KTRR via PAC ou APRR, mas o KPP deixa rastros na forma de tabelas de sistema sysctl modificadas. Verificar kern.version em busca de strings como pwned, prod ou xnu com uma versão não padrão pode revelar um patch do kernel.

Integridade da Sandbox

A sandbox do iOS opera no nível TrustedBSD usando entitlements. O jailbreak substitui o perfil da sandbox por allow-all. Um aplicativo pode verificar a sandbox tentando ler qualquer arquivo fora de seu diretório Documents. Se bem-sucedido — a sandbox foi modificada. A integridade da Sandbox é um dos poucos indicadores que não pode ser falsificado sem um exploit em nível de kernel, já que a verificação de permissões é realizada no kernel antes que possa ser interceptada.