hmascs/ksurootFerramenta de root do kernel Android com um clique que explora CVE-2026-43499 para instalar KernelSU, com fontes de payload .so oficiais, incluídas e personalizadas.
⚠️ Aviso: as políticas de agendamento dos modelos da Blue Factory são bastante rígidas, e os processos filhos são facilmente recolhidos pelo sistema durante a escalada de privilégios. Ative primeiro "Parar de restringir processos filhos" nas "Opções do desenvolvedor" antes de executar a escalada de privilégios; a taxa de sucesso será maior.
Ferramenta de escalada de privilégios KernelSU com um clique baseada na vulnerabilidade de kernel CVE-2026-43499 (GhostLock).
Este branch tem o KSuRoot como base, sincroniza completamente as atualizações da linha principal do Root-My-Galaxy v0.2.6 e, sobre essa base, adiciona construção de payload, payloads de fabricante integrados e todo um conjunto de UI em vidro líquido.
Mod by hmascs · Versão 4.1.2 · Apache-2.0 Repositório: https://github.com/hmascs/KSuRoot
O vr.ko marca as tasks vindas do app, e esse deslocamento tem duas variantes, 0x04 / 0x06, e é assado no payload em tempo de compilação, não sendo possível aplicar patch. Pior ainda, duas cópias do vr.ko na mesma máquina têm cada uma a sua variante
(o vendor_boot do Y300 Pro+ tem duas cópias, com srcversion completamente idêntico) —
escolher a errada manifesta-se como "limpar os bytes errados, a marcação não é apagada, e os processos filhos continuam a ser mortos", enquanto nos logs tudo parece normal.
Agora a solução da Blue Factory exige que forneças um vendor_boot.img: a aplicação lê o deslocamento real da máquina a partir do lib/modules/vr.ko efetivamente carregado nessa imagem e depois reescreve o payload. As quatro bibliotecas incluídas/compiladas
(libbaseline_6_1 / libbaseline_6_12 / libbs / libionstack) são todas forçadas a corresponder ao seu próprio perfil,
e uma escolha errada é travada imediatamente pelo portão de zero correspondências, em vez de te dar um produto copiado tal e qual.
Além disso, foi adicionado "Importar pacote de flash completo": seleciona diretamente o zip OTA ou o tgz fastboot que descarregaste,
e ele próprio extrai o boot e o vendor_boot, sem precisares de descompactar primeiro nem de extrair manualmente.
⚠️ O pacote completo tem de ser copiado integralmente para a cache da aplicação para permitir leitura aleatória (o diretório central do ZIP está no fim do pacote, e o uri do SAF não pode ser convertido em File). Se não houver espaço suficiente, será recusado imediatamente, e a cache é apagada logo após a extração.
4.1.2 = 4.1.0 + 19 commits. Estes commits estavam originalmente parados no branch fix/baseline-routing,
e agora foram integrados no main. O pacote de instalação 4.1.0 já publicado não os inclui — cada um dos itens abaixo só foi corrigido depois disso.
| # | Defeito | Consequência |
|---|---|---|
| 1 | O VR_TAG_A_OFF do 6.1 preenchido como 0x06 (na prática deveria ser 0x04) | Nos modelos 6.1 da Blue Factory a marcação não foi apagada nem um único byte, enquanto a autoverificação reportava sucesso. O sintoma é "após a escalada de privilégios bem-sucedida, os processos filhos são imediatamente mortos", sem se perceber que esta é a causa |
| 2 | A localização da tabela de deslocamentos do kallsyms usava módulo com número negativo (tradução literal da semântica de Python) | Falha total em kernels 6.4+, com o endereço base a apontar para um trecho de texto ASCII |
| 3 | O critério da tabela de deslocamentos só verificava "os três primeiros itens são monótonos" | Quase nenhum poder de distinção (qualquer posição dentro da tabela é monótona); foi alterado para verificar a forma da tabela |
| 4 | O BASELINE_6_12.imageBase preenchido com o endereço base alvo | Todos os pontos de construção em forma de endereço absoluto deixaram de ser alterados (39 pontos → 9 pontos) |
| 5 | Quando os símbolos não alinham, apenas se esvazia o produto e o gate continua Proceed | blocked=false e produto de 0 B, a UI não mostra a caixa de bloqueio |
| 6 | O fallback do FopsSlot nunca foi utilizado | Se a tabela não for encontrada, desiste-se logo, sem recuar para o símbolo alternativo |
TARGET_ASHMEM_FOPS_UNSYMBOLED)07-文档/6.1-6.12-双方案清单.md0x04, 6.6 / 6.12 = 0x06 (o vr.ko no firmware de fábrica de três máquinas reais)载荷构建/): anteriormente havia 15 referências no repositório a apontar para um diretório inexistenteO resultado da execução da construção no X100 Pro (6.1.145) foi:
偏移解析: 28 / 28 项
需要改写: 26 项 · 校验通过: 0 项
该动态库未引用 26 项偏移
Isso não é "não há nada a mudar", é "estas duas coisas não são um conjunto". A causa raiz é que dois caminhos independentes divergiram:
| O que escolher | Com base em quê escolher | Selecionado em 6.1.145 |
|---|---|---|
| Biblioteca base | Família de estruturas (F6_1) | libbaseline_6_1.so (valor antigo vindo de baseline-6.1-tokay/target.h) |
| Perfil | Roteamento de três níveis (string do kernel) | up-6-1-145-… (valor antigo vindo de offsets.h do GhostLock) |
A forma de aplicar o patch é "pegar o valor antigo do perfil e procurar o literal no .so". Os dois conjuntos de valores antigos não têm interseção alguma, por isso nenhum dos 26 itens corresponde, e o produto final equivale a uma cópia idêntica da biblioteca base.
Por que o portão rígido original não bloqueou: o critério de hasFailures é changed && !ok && !absent ——
absent é explicitamente excluído. Essa justificativa ("a versão antiga do .so pode não ter o caminho de código correspondente") vale para chaves individuais,
mas não vale para "todas as chaves estarem absent".
Duas formas de corrigir:
libbaseline_6_1.so / libbaseline_6_12.so)
devem ser emparelhadas com o seu próprio perfil (baseline-6-1-tokay / baseline-6-12-honor),
os perfis up-* a montante só se aplicam àquele .so a montante. Adicionado BaselineLibraries.profileIdForLibrary().kind a SpecOutcome.Os casos de regressão estão em BaselineLibraryPairingTest (4 casos), um dos quais afirma diretamente que os dois conjuntos de valores antigos não têm interseção ——
transformando "por que é obrigatório emparelhar" num facto executável.