GhostLock-App

中文: README_ZH.md

Documentação

• Guia de Portabilidade de Perfis de Kernel - adicione suporte a um novo kernel. O GhostLock corresponde kernels pelo uname -r exato e rejeita builds não suportados, exibindo o status no topo. Os perfis integrados ficam em app/src/main/assets/kernel_profiles/: um arquivo HOCON por versão, index.conf como índice de execução, e templates de família de versão <major.minor>-template.conf.
• Dispositivos suportados - a lista de kernels integrados.
• Padrões de execução compartilhados - cada campo de ajuste de execução, seu padrão e o motivo.
• Esquema de perfil - estrutura completa do perfil e fluxo de dados.
• Adicionando um componente - guia do desenvolvedor para um novo middleware nativo / backend / frontend (chinês).

Para o fluxo completo de portabilidade de dispositivos, links de templates de família de kernel e justificativa de ajustes, consulte o Guia de Portabilidade de Perfis de Kernel.

Linhas explicitamente marcadas como Shizuku required são executadas através de um shell UserService. Inicie o Shizuku com ADB e toque no cartão de status para conceder acesso; todas as outras linhas usam o caminho de execução normal do aplicativo.

Início Rápido

Abra o GhostLock e toque em Run. KernelSU (me.weishu.kernelsu), ReSukiSU (com.resukisu.resukisu) ou KowSU (com.kowx712.supermanager) fornecem ksud para carregamento de módulos; sem ele, W1/W2 ainda concedem uid 0, mas nenhum módulo é carregado.

A cadeia de execução é um pipeline de três componentes: um frontend (inicialização/handoff do root_child), um backend (a primitiva futex CVE-2026-43499) e uma rota de middleware. As combinações catalogadas são instanciadas em tempo de build; o perfil resolvido seleciona qual delas é executada. A rota disputa dois núcleos: nos kernels tree-waiter 6.6/6.12, a thread principal martela select enquanto uma thread consumidora perturba a prioridade do waiter; nos kernels compact-waiter 6.1, ela aciona getsockopt(TCP_ZEROCOPY_RECEIVE) através de uma página com furo perfurado; os kernels 5.15 usam o waiter multicast. O par de CPUs também vem do perfil resolvido.

Depuração por Linha de Comando

adb/shell não possui filtro seccomp, então W3 é ignorado - útil para verificação rápida:

make -C src ghostlock
./gradlew exportKernelProfiles
adb push build/native/ghostlock /data/local/tmp/ghostlock
adb push build/kernel-profiles/<release>.bin /data/local/tmp/profile.bin
adb shell chmod 755 /data/local/tmp/ghostlock
adb shell /data/local/tmp/ghostlock --load-prebuilt-profile /data/local/tmp/profile.bin

Extração de Offsets

tools/extract_rs deriva offsets de um boot.img (mais xbl_config.img opcional), um ZIP de OTA completo, ou uma URL http(s) apontando para um deles. Os kallsyms vêm de --kallsyms ou são recuperados da tabela embutida na imagem. pselect_waiter_shift e off_slide_loggers_0_1 são derivados pelo desmontador arm64 integrado. Imagens MediaTek não possuem xbl_config.img e geralmente não possuem BTF: o endereço físico de carregamento é derivado do kallsyms _text (substitua com --phys).

Push-Location tools/extract_rs
cargo build --release
Pop-Location
build/extract/release/ghostlock-extract.exe boot.img --xbl-config xbl_config.img --format conf --out profile.conf
build/extract/release/ghostlock-extract.exe OTA.zip --format conf --out profile.conf

--format conf é a saída do extrator: um perfil achatado e autocontido (sem linhas include, as constantes compartilhadas de credencial/KernelSnitch 6.x embutidas, a rota selecionada a partir das evidências de --analysis, a menos que --route a substitua). O extrator emite todos os campos que a imagem realmente fornece e omite o restante; ele nunca preenche lacunas com suposições de uma família de kernel vizinha (6.6 de família não verificada, o padrão -2, as constantes multicast 5.15, ou um padrão phys). Cada saída é um candidato não verificado: importável e analisável, com campos ausentes ou inválidos bloqueados pela validação pré-execução do aplicativo, de modo que uma execução bem-sucedida nunca implica suporte ao dispositivo. No 5.x, ele também deriva o reparo de referência de credencial a partir de init_cred e a geometria multicast a partir do BTF (veja docs/analysis/extractor-5x-derivation-plan.md). --format json permanece para o caminho de importação v1. Para adicionar um perfil integrado, complete e valide o template de família de versão correspondente, salve-o como um perfil .conf autônomo e adicione-o a kernel_profiles/index.conf. O antigo registro C offsets.h está obsoleto e foi removido.

MediaTek

Imagens MediaTek não possuem xbl_config.img e geralmente não possuem BTF embutido, então o extrator não consegue derivar os dois endereços físicos (kernel_phys_load, kernel_phys_offset) a partir da imagem e os deixa como null. O runtime então recorre à fórmula do SoC, que falha em W1 no MediaTek. Preencha ambos executando o extrator separado tools/mtk-phys/ em um dispositivo com root (ele lê /proc/iomem) e colando os valores nas substituições avançadas do aplicativo. Veja MEDIATEK.md.

Pré-verificação

O extrator desmonta remove_waiter() antes de extrair offsets. Kernels com a correção são rejeitados com código de saída 6; apenas kernels vulneráveis continuam.

Análise no dispositivo

Uma OTA completa pode ser analisada inteiramente no telefone: boot mais xbl_config são extraídos automaticamente. Passe --work-dir um diretório gravável pelo aplicativo quando executado dentro do sandbox do aplicativo. Compile cruzado e envie:

rustup target add aarch64-linux-android
$ndk = "$env:ANDROID_HOME\ndk\<version>\toolchains\llvm\prebuilt\windows-x86_64\bin"
$env:CC_aarch64_linux_android = "$ndk\aarch64-linux-android35-clang.cmd"
$env:AR_aarch64_linux_android = "$ndk\llvm-ar.exe"
$env:CARGO_TARGET_AARCH64_LINUX_ANDROID_LINKER = $env:CC_aarch64_linux_android
Push-Location tools/extract_rs
cargo build --release --target aarch64-linux-android
Pop-Location
adb push build/extract/aarch64-linux-android/release/ghostlock-extract /data/local/tmp/
adb shell /data/local/tmp/ghostlock-extract /sdcard/OTA.zip

Importando offsets sem recompilar o aplicativo

Novos kernels não precisam mais de uma recompilação do aplicativo: toque em Import offsets.conf (HOCON) e escolha o .conf achatado do extrator, ou use Import offsets.json (v1) para um relatório JSON mais antigo. O JSON v1 é convertido no aplicativo, então nada precisa ser enviado ao dispositivo: o nativo sempre começa a partir do documento GLK1 que o aplicativo envia no stdin, e corresponde o uname -r atual ao perfil resolvido antes de rejeitar o kernel. As importações são mescladas entre arquivos; uma versão já armazenada solicita confirmação antes de sobrescrever.

O aplicativo também pode gerar o perfil por conta própria — Parse OTA link (URL completa do ZIP da OTA) e Parse image (boot.img + xbl_config.img opcional) executam o extrator em processo e gravam um .conf achatado no diretório de dados do aplicativo em caso de sucesso: