O que foi feito

1. Análise do código-fonte → Extração de offsets de structs

Extraído de arch/arm64/include/asm/memory.h + include/linux/fs.h + android/abi_gki_aarch64.xml:

• Layout de memória: KIMAGE_TEXT_BASE = 0xffffffc008000000, VA_BITS=39, DIRECT_MAP=256GB
• task_struct: 36864 bits, totalmente analisado (ABI XML layout-offset-in-bits)
• file_operations: sem iopoll (android13 GKI), IOCTL=0x48, open=0x68
• cred: atomic_t usage = 4 bytes, uid=0x04
• struct page: 64 bytes, slab_cache=0x18

Descoberta-chave: o código-fonte é android15 GKI, o dispositivo é android13 GKI — os offsets do task_struct diferem em 0x40~0x88 bytes, não é possível copiar diretamente do código-fonte.

2. Descompactação do firmware → Extração de símbolos

Símbolos extraídos de duas versões de firmware (15.2.7.6 / 15.2.10.2) — o mesmo símbolo difere em 10KB~200KB entre as duas versões, é obrigatório usar a versão correta.

3. Verificação por desmontagem → capstone confirma offsets críticos

Isso confirma que o layout do task_struct é do branch android15, não o android13 do frankel.

4. Compilação → Passou

NDK r29, make PROJECT=android_15.0_kernel_MT6985 → preload.so (150KB).

5. Execução → Travamentos repetidos

Instrução do travamento (capstone):

Por que falhou

Causa raiz 1: KernelSnitch não é confiável no MTK

KernelSnitch é a porta de entrada de todo o exploit — ele vaza o endereço do mm_struct através da diferença de temporização no bucket do hash do futex:

1. Detecção de colisão bem-sucedida — 5 colisões encontradas com limiar baixo
2. Correspondência por bruteforce quase sempre falha — o problema central está em:

Dispositivos Pixel não têm KASAN_HW_TAGS, esse mecanismo funciona. MTK não funciona.

Causa raiz 2: CONFIG_PANIC_ON_OOPS é o assassino

E o bootloader está bloqueado (flash.locked=1) → não é possível flashar um kernel personalizado para remover essa opção.

Causa raiz 3: Derivação da versão do kernel

Embora o número da versão principal seja o mesmo 5.15.178, os branches GKI são diferentes (android13 vs android15), e os layouts de structs críticas como task_struct/cred não são consistentes. Após alternar repetidamente entre os dois conjuntos de offsets (frankel/android15), só foi possível confirmar através de desmontagem.

Ajustes tentados (todos inúteis)

Estado atual do target.h

Em exploit/targets/android_15.0_kernel_MT6985/target.h:

A montagem compila, o exploit executa, mas perdeu no último quilômetro.

Se você quiser continuar

Condições necessárias (todas indispensáveis)

1. Remover CONFIG_PANIC_ON_OOPS — ou flashar um kernel personalizado (requer desbloquear o bootloader), ou encontrar um dispositivo MT6985 com essa opção desativada por padrão
2. Resolver o KernelSnitch — é necessária a calibração de temporização de cache do MTK Dimensity 9200, ou substituir completamente o KernelSnitch por outro método de vazamento do mm_struct no exploit

Possíveis abordagens alternativas

• /proc/self/pagemap — restrito neste dispositivo (retorna tudo zero)
• Interfaces de depuração específicas do MTK (/proc/mtk_*) — existem, mas precisam de análise adicional
• Vulnerabilidades de ioctl nos drivers de câmera/GPU do MTK — caminho de escalonamento mais simples
• Aguardar a comunidade adaptar uma variante MTK

Valor residual deste repositório

• symbols/kallsyms_PD2241_15.2.10.2.txt — tabela de símbolos completa do 15.2.10.2, utilizável diretamente por outros
• device_config.txt — configuração real do kernel do dispositivo, mostra o que o vendor alterou
• exploit/targets/android_15.0_kernel_MT6985/target.h — offsets de structs verificados
• scripts/server_compile.py — compilação automatizada, recompilação rápida após alterar parâmetros

Lista de armadilhas (para evitar no futuro)

1. Descompactar arquivos no Windows: tar -xf pode falhar com zips grandes, use Python zipfile ou descompacte manualmente primeiro
2. Conflito de versão do protobuf no payload_dumper: o update_metadata_pb2.py gerado requer protobuf 5.x, é necessário remover manualmente a linha de importação runtime_version
3. Executar ./preload.so diretamente causa segfault: é obrigatório usar /system/bin/linker64 /data/local/tmp/preload.so
4. ABI XML é mais preciso que o código-fonte: layout-offset-in-bits é calculado pelo compilador, 100x mais preciso que contar 5000 bytes manualmente
5. O branch GKI afeta o layout: task_struct difere entre android13/14/15, não é possível copiar offsets entre branches
6. Versões diferentes de firmware têm offsets de símbolos diferentes: 15.2.7.6 e 15.2.10.2 diferem em 10KB~200KB
7. O vendor vivo adicionou muitos campos OEM: CONFIG_ANDROID_VENDOR_OEM_DATA=y, CONFIG_SCHED_INFO=y, CONFIG_RSC_* → desvia do GKI padrão
8. Cadeia de ferramentas de extração de símbolos: boot.img → kernel.bin → descompressão LZ4 → Image → kallsyms-finder → tabela de símbolos

Linha do tempo

2026-07-29, sobrevivi para contar a história

Continuação de 2026-07-31: Verificação e correção após obter o código-fonte

Após obter android_15.0_kernel_MT6985.tar.gz (árvore de código-fonte 5.15.178 + ABI XML), foi feita validação cruzada completa, detalhes em VERIFICATION.md. Resumo:

1. MT6985 = Dimensity 9200 (MT6989 é o 9300), corrigido acima.
2. Offsets de símbolos 23/23 corretos (verificação via kallsyms), offsets de task_struct / cred / waiter / page / pipe / configfs todos consistentes com o ABI da árvore de código-fonte.
3. Offsets FOPS estavam errados: o valor original foi copiado do frankel (android13 GKI, sem iopoll, ioctl=0x48); mas o layout do task_struct do dispositivo (pi_blocked_on=0x8b0, confirmado por desmontagem em tempo de execução) é consistente com esta árvore de código-fonte, então o file_operations do mesmo kernel deve ter iopoll@0x30, ioctl=0x50, open=0x70 etc. — target.h foi corrigido, e a auto-verificação em dispositivo real via leak_kernel_base() embutida no exploit foi usada como salvaguarda.
4. Patch de compatibilidade MTK para KernelSnitch (patches/kernelsnitch_mtk_fixes.patch):
   • O tamanho da tabela de hash futex no espaço do usuário foi alterado para corresponder ao do kernel (possible CPU + 2 arredondado para potência de 2), evitando falha garantida do bruteforce quando possible≠online;
   • A varredura de tags MTE agora inclui 0xf (sem tag), e KSNITCH_MTE_ENABLED=1 realmente tem efeito (o util.c original tinha mte=0 codificado);
   • Não afeta targets não-MTK.
5. O ponto de travamento rt_mutex_adjust_prio_chain+0x1b0 está na fase da cadeia pselect/pi, antes da auto-verificação FOPS; após as correções acima, vale a pena testar novamente no dispositivo.

Teste em dispositivo real em 2026-07-31: KernelSnitch funcionando, fase slide ainda é um obstáculo

Dispositivo (PD2241, compiler251203103903) — 8+ rodadas de teste em hardware real:

• KernelSnitch corrigido e verificado: MM_STRUCT_SZ=0x400 (o valor original 0x500 causava desalinhamento da grade de varredura, produzindo apenas falsos positivos) + varredura de tags MTE 0..15 (a tag do ponteiro mm do dispositivo muda) + remoção de tag em endereços falsificados. Agora encontra o mm_struct real de forma estável.
• Cada rodada ainda trava em rt_mutex_adjust_prio_chain+0x1b0: corrida de temporização na cadeia pselect/pi (o waiter falsificado não cai no offset correto da pilha do kernel). O escalonador RSC da vivo modificou o caminho futex/pi, possivelmente quebrando essa corrida por completo. O alinhamento da pilha do slide foi parametrizado como variável de ambiente SLIDE_SHIFT, varredura não concluída.
• As fases FOPS/pipe/cred ainda não foram alcançadas, verificação em dispositivo real pendente.

Escolha final: rebaixar para desbloqueio pago do bootloader (não depender mais deste caminho).