android/SukiSU-Ultra
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Add Brazilian Portuguese language to the website (#965)

Browse Source
This commit is contained in:
igor
2023-09-18 06:22:17 -03:00
committed by GitHub
parent 1f42bbac5e
commit c19ba7fab0
14 changed files with 1162 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

118
website/docs/pt_BR/guide/app-profile.md Normal file
View File

@@ -0,0 +1,118 @@
# Perfil do Aplicativo
O Perfil do Aplicativo é um mecanismo fornecido pelo KernelSU para personalizar a configuração de vários apps.
Para apps com permissões de root (ou seja, capazes de usar `su`), o Perfil do Aplicativo também pode ser chamado de Perfil Raiz. Ele permite a customização das regras `uid`, `gid`, `groups`, `capabilities` e `SELinux` do comando `su`, restringindo assim os privilégios do usuário root. Por exemplo, ele pode conceder permissões de rede apenas para apps de firewall enquanto nega permissões de acesso a arquivos, ou pode conceder permissões de shell em vez de acesso root completo para apps congelados: **mantendo o poder confinado com o princípio do menor privilégio.**
Para apps comuns sem permissões de root, o Perfil do Aplicativo pode controlar o comportamento do kernel e do sistema de módulos em relação a esses apps. Por exemplo, pode determinar se as modificações resultantes dos módulos devem ser abordadas. O kernel e o sistema de módulos podem tomar decisões com base nesta configuração, como realizar operações semelhantes a "ocultar"
## Perfil Raiz
### UID, GID e Grupos
Os sistemas Linux possuem dois conceitos: usuários e grupos. Cada usuário possui um ID de usuário (UID) e um usuário pode pertencer a vários grupos, cada um com seu próprio ID de grupo (GID). Esses IDs são usados ​​para identificar usuários no sistema e determinar quais recursos do sistema eles podem acessar.
Os usuários com UID 0 são conhecidos como usuários root e os grupos com GID 0 são conhecidos como grupos raiz. O grupo de usuários root normalmente possui os privilégios de sistema mais altos.
No caso do sistema Android, cada app é um usuário separado (excluindo cenários de UID compartilhados) com um UID exclusivo. Por exemplo, `0` representa o usuário root, `1000` representa `system`, `2000` representa o shell ADB e UIDs variando de 10.000 a 19.999 representam apps comuns.
:::informações
Aqui, o UID mencionado não é o mesmo que o conceito de múltiplos usuários ou perfis de trabalho no sistema Android. Os perfis de trabalho são, na verdade, implementados particionando o intervalo UID. Por exemplo, 10000-19999 representa o usuário principal, enquanto 110000-119999 representa um perfil de trabalho. Cada app comum entre eles possui seu próprio UID exclusivo.
:::
Cada app pode ter vários grupos, com o GID representando o grupo principal, que geralmente corresponde ao UID. Outros grupos são conhecidos como grupos suplementares. Certas permissões são controladas por meio de grupos, como permissões de acesso à rede ou acesso Bluetooth.
Por exemplo, se executarmos o comando `id` no shell ADB, a saída pode ser semelhante a esta:
```sh
oriole:/ $ id
uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),1078(ext_data_rw),1079(ext_obb_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid),3012(readtracefs) context=u:r:shell:s0
```
Aqui, o UID é `2000` e o GID (ID do grupo primário) também é `2000`. Além disso, pertence a vários grupos suplementares, como `inet` (indicando a capacidade de criar soquetes `AF_INET` e `AF_INET6`) e `sdcard_rw` (indicando permissões de leitura/gravação para o cartão SD).
O Perfil Raiz do KernelSU permite a personalização do UID, GID e grupos para o processo raiz após a execução de `su`. Por exemplo, o Perfil Raiz de um app raiz pode definir seu UID como `2000`, o que significa que ao usar `su`, as permissões reais do app estão no nível do shell ADB. O grupo `inet` pode ser removido, evitando que o comando `su` acesse a rede.
:::tip Observação
O Perfil do Aplicativo controla apenas as permissões do processo root após usar `su`; ele não controla as permissões do próprio app. Se um app solicitou permissão de acesso à rede, ele ainda poderá acessar a rede mesmo sem usar `su`. Remover o grupo `inet` de `su` apenas impede que `su` acesse a rede.
:::
O Perfil Raiz é aplicado no kernel e não depende do comportamento voluntário de apps root, ao contrário da troca de usuários ou grupos através do `su`, a concessão da permissão `su` depende inteiramente do usuário e não do desenvolvedor.
### Capacidades
As capacidades são um mecanismo para separação de privilégios no Linux.
Para realizar verificações de permissão, as implementações tradicionais do UNIX distinguem duas categorias de processos: processos privilegiados (cujo ID de usuário efetivo é 0, referido como superusuário ou root) e processos sem privilégios (cujo UID efetivo é diferente de zero). Os processos privilegiados ignoram todas as verificações de permissão do kernel, enquanto os processos não privilegiados estão sujeitos à verificação completa de permissão com base nas credenciais do processo (geralmente: UID efetivo, GID efetivo e lista de grupos suplementares).
A partir do Linux 2.2, o Linux divide os privilégios tradicionalmente associados ao superusuário em unidades distintas, conhecidas como capacidades, que podem ser habilitadas e desabilitadas de forma independente.
Cada capacidade representa um ou mais privilégios. Por exemplo, `CAP_DAC_READ_SEARCH` representa a capacidade de ignorar verificações de permissão para leitura de arquivos, bem como permissões de leitura e execução de diretório. Se um usuário com um UID efetivo de `0` (usuário root) não tiver recursos `CAP_DAC_READ_SEARCH` ou superiores, isso significa que mesmo sendo root, ele não pode ler arquivos à vontade.
O Perfil Raiz do KernelSU permite a personalização das Capacidades do processo raiz após a execução de `su`, conseguindo assim conceder parcialmente "permissões de root". Ao contrário do UID e GID mencionados acima, certos apps root exigem um UID de `0` após usar `su`. Nesses casos, limitar as capacidades deste usuário root com UID `0` pode restringir suas operações permitidas.
:::tip Forte Recomendação
Capacidade do Linux [documentação oficial](https://man7.org/linux/man-pages/man7/capabilities.7.html) fornece explicações detalhadas das habilidades representadas por cada capacidade. Se você pretende customizar Capacidades, é altamente recomendável que você leia este documento primeiro.
:::
### SELinux
SELinux é um poderoso mecanismo de Controle de Acesso Obrigatório (MAC). Ele opera com base no princípio de **negação padrão**: qualquer ação não explicitamente permitida é negada.
O SELinux pode ser executado em dois modos globais:
1. Modo permissivo: Os eventos de negação são registrados, mas não aplicados.
2. Modo de aplicação: Os eventos de negação são registrados e aplicados.
:::warning Aviso
Os sistemas Android modernos dependem fortemente do SELinux para garantir a segurança geral do sistema. É altamente recomendável não usar nenhum sistema personalizado executado em "modo permissivo", pois não oferece vantagens significativas em relação a um sistema completamente aberto..
:::
Explicar o conceito completo do SELinux é complexo e está além do escopo deste documento. Recomenda-se primeiro entender seu funcionamento através dos seguintes recursos:
1. [Wikipédia](https://en.wikipedia.org/wiki/Security-Enhanced_Linux)
2. [Red Hat: O que é SELinux?](https://www.redhat.com/en/topics/linux/what-is-selinux)
3. [ArchLinux: SELinux](https://wiki.archlinux.org/title/SELinux)
O Perfil Raiz do KernelSU permite a personalização do contexto SELinux do processo raiz após a execução de `su`. Regras específicas de controle de acesso podem ser definidas para este contexto para permitir um controle refinado sobre as permissões de root.
Em cenários típicos, quando um app executa `su`, ele alterna o processo para um domínio SELinux com **acesso irrestrito**, como `u:r:su:s0`. Através do Perfil Raiz, este domínio pode ser mudado para um domínio personalizado, como `u:r:app1:s0`, e uma série de regras podem ser definidas para este domínio:
```sh
type app1
enforce app1
typeattribute app1 mlstrustedsubject
allow app1 * * *
```
Observe que a regra `allow app1 * * *` é usada apenas para fins de demonstração. Na prática, esta regra não deve ser utilizada extensivamente, pois não difere muito do modo permissivo.
### Escalação
Se a configuração do Perfil Raiz não estiver definida corretamente, poderá ocorrer um cenário de escalonamento: as restrições impostas pelo Perfil Raiz poderão falhar involuntariamente.
Por exemplo, se você conceder permissão root a um usuário shell ADB (que é um caso comum) e, em seguida, conceder permissão root a um app normal, mas configurar seu perfil root com UID 2000 (que é o UID do usuário shell ADB) , o app pode obter acesso root completo executando o comando `su` duas vezes:
1. A primeira execução `su` está sujeita à aplicação do Perfil do Aplicativo e mudará para UID `2000` (adb shell) em vez de `0` (root).
2. A segunda execução `su`, como o UID é `2000` e você concedeu acesso root ao UID `2000` (adb shell) na configuração, o app obterá privilégios de root completos.
:::warning Observação
Este comportamento é totalmente esperado e não é um bug. Portanto, recomendamos o seguinte:
Se você realmente precisa conceder permissões de root ao ADB (por exemplo, como desenvolvedor), não é aconselhável alterar o UID para `2000` ao configurar o Perfil Raiz. Usar `1000` (sistema) seria uma escolha melhor.
:::
## Perfil não Raiz
### Desmontar Módulos
O KernelSU fornece um mecanismo sem sistema para modificar partições do sistema, obtido através da montagem overlayfs. No entanto, alguns apps podem ser sensíveis a esse comportamento. Assim, podemos descarregar módulos montados nesses apps configurando a opção “desmontar módulo”.
Além disso, a interface de configurações do gerenciador KernelSU fornece uma opção para "desmontar módulos por padrão". Por padrão, essa opção está **ativada**, o que significa que o KernelSU ou alguns módulos descarregarão módulos para este app, a menos que configurações adicionais sejam aplicadas. Se você não preferir esta configuração ou se ela afetar determinados apps, você terá as seguintes opções:
1. Mantenha a opção "desmontar módulos por padrão" e desative individualmente a opção "desmontar módulos" no Perfil do Aplicativo para apps que exigem carregamento de módulo (agindo como uma "lista de permissões").
2. Desative a opção "desmontar módulos por padrão" e ative individualmente a opção "desmontar módulos" no Perfil do Aplicativo para apps que exigem descarregamento de módulo (agindo como uma "lista negra").
:::informações
Em dispositivos que utilizam kernel versão 5.10 e superior, o kernel realiza o descarregamento dos módulos. No entanto, para dispositivos que executam versões de kernel abaixo de 5.10, essa opção é apenas uma opção de configuração e o próprio KernelSU não executa nenhuma ação. Alguns módulos, como Zygisksu, podem usar essa opção para determinar se o descarregamento do módulo é necessário.
:::

28
website/docs/pt_BR/guide/difference-with-magisk.md Normal file
View File

@@ -0,0 +1,28 @@
# Diferença com Magisk
Embora existam muitas semelhanças entre os módulos KernelSU e os módulos Magisk, existem inevitavelmente algumas diferenças devido aos seus mecanismos de implementação completamente diferentes. Se você deseja que seu módulo seja executado no Magisk e no KernelSU, você deve entender essas diferenças.
## Semelhanças
- Formato de arquivo do módulo: ambos usam o formato zip para organizar os módulos, e o formato dos módulos é quase o mesmo
- Diretório de instalação do módulo: ambos localizados em `/data/adb/modules`
- Sem sistema: ambos suportam a modificação de /system de maneira sem sistema por meio de módulos
- post-fs-data.sh: o tempo de execução e a semântica são exatamente os mesmos
- service.sh: o tempo de execução e a semântica são exatamente os mesmos
- system.prop: completamente o mesmo
- sepolicy.rule: completamente o mesmo
- BusyBox: os scripts são executados no BusyBox com o "modo autônomo" habilitado em ambos os casos
## Diferenças
Antes de entender as diferenças, você precisa saber diferenciar se o seu módulo está rodando no KernelSU ou Magisk. Você pode usar a variável de ambiente `KSU` para diferenciá-la em todos os locais onde você pode executar scripts do módulo (`customize.sh`, `post-fs-data.sh`, `service.sh`). No KernelSU, esta variável de ambiente será definida como `true`.
Aqui estão algumas diferenças:
- Os módulos KernelSU não podem ser instalados no modo Recovery.
- Os módulos KernelSU não têm suporte integrado para Zygisk (mas você pode usar módulos Zygisk através do [ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU).
- O método para substituir ou excluir arquivos nos módulos KernelSU é completamente diferente do Magisk. KernelSU não suporta o método `.replace`. Em vez disso, você precisa criar um arquivo com o mesmo nome `mknod filename c 0 0` para excluir o arquivo correspondente.
- Os diretórios do BusyBox são diferentes. O BusyBox integrado no KernelSU está localizado em `/data/adb/ksu/bin/busybox`, enquanto no Magisk está em `/data/adb/magisk/busybox`. **Observe que este é um comportamento interno do KernelSU e pode mudar no futuro!**
- KernelSU não suporta arquivos `.replace`; entretanto, KernelSU suporta as variáveis ​​`REMOVE` e `REPLACE` para remover ou substituir arquivos e pastas.
- KernelSU adiciona o estágio `boot-completed` para executar alguns scripts na inicialização concluída.
- KernelSU adiciona o estágio `post-mount` para executar alguns scripts após montar overlayfs.

67
website/docs/pt_BR/guide/faq.md Normal file
View File

@@ -0,0 +1,67 @@
# FAQ
## KernelSU oferece suporte ao meu dispositivo?
Primeiro, seus dispositivos devem ser capazes de desbloquear o bootloader. Se não puder, então não há suporte.
Em seguida, instale o app gerenciador KernelSU em seu dispositivo e abra-o, se mostrar `Unsupported` então seu dispositivo não pode ser suportado imediatamente, mas você pode construir a fonte do kernel e integrar o KernelSU para fazê-lo funcionar ou usar [dispositivos de suporte não oficial](unofficially-support-devices).
## O KernelSU precisa desbloquear o Bootloader?
Certamente, sim
## O KernelSU suporta módulos?
Sim, mas está na versão inicial, pode apresentar bugs. Aguarde até que fique estável :)
## KernelSU suporta Xposed?
Sim, [Dreamland](https://github.com/canyie/Dreamland) e [TaiChi](https://taichi.cool) funcionam agora. Para o LSPosed, você pode fazer funcionar [Zygisk on KernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU)
## KernelSU suporta Zygisk?
KernelSU não tem suporte integrado ao Zygisk, mas você pode usar [Zygisk on KernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU).
## O KernelSU é compatível com Magisk?
O sistema de módulos do KernelSU está em conflito com a montagem mágica do Magisk, se houver algum módulo habilitado no KernelSU, então todo o Magisk não funcionaria.
Mas se você usar apenas o `su` do KernelSU, então funcionará bem com o Magisk: KernelSU modifica o `kernel` e o Magisk modifica o `ramdisk`, eles podem trabalhar juntos.
## O KernelSU substituirá o Magisk?
Achamos que não e esse não é o nosso objetivo. Magisk é bom o suficiente para solução raiz do espaço do usuário e terá uma vida longa. O objetivo do KernelSU é fornecer uma interface de kernel aos usuários, não substituindo o Magisk.
## O KernelSU pode oferecer suporte a dispositivos não GKI?
É possível. Mas você deve baixar o código-fonte do kernel e integrar o KernelSU à árvore de código-fonte e compilar o kernel você mesmo.
## O KernelSU pode oferecer suporte a dispositivos abaixo do Android 12?
É o kernel do dispositivo que afeta a compatibilidade do KernelSU e não tem nada a ver com a versão do Android. A única restrição é que os dispositivos lançados com Android 12 devem ser kernel 5.10+ (dispositivos GKI). Então:
1. Os dispositivos lançados com Android 12 devem ser compatíveis.
2. Dispositivos com kernel antigo (alguns dispositivos Android 12 também têm kernel antigo) são compatíveis (você mesmo deve construir o kernel)
## O KernelSU pode suportar kernel antigo?
É possível, o KernelSU é portado para o kernel 4.14 agora, para o kernel mais antigo, você precisa fazer o backport manualmente e PRs são bem-vindos!
## Como integrar o KernelSU para o kernel antigo?
Por favor, consulte [guia](how-to-integrate-for-non-gki)
## Por que minha versão do Android é 13 e o kernel mostra “android12-5.10”?
A versão do Kernel não tem nada a ver com a versão do Android, se você precisar fazer o flash do kernel, use sempre a versão do kernel, a versão do Android não é tão importante.
## Existe algum namespace de montagem --mount-master/global no KernelSU?
Não existe agora (talvez no futuro), mas há muitas maneiras de mudar manualmente para o namespace de montagem global, como:
1. `nsenter -t 1 -m sh` para obter um shell no namespace de montagem global.
2. adicione `nsenter --mount=/proc/1/ns/mnt` ao comando que você deseja executar, o comando será executado no namespace de montagem global. O KernelSU também está [usando desta forma](https://github.com/tiann/KernelSU/blob/77056a710073d7a5f7ee38f9e77c9fd0b3256576/manager/app/src/main/java/me/weishu/kernelsu/ui/util/KsuCli.kt#L115)
## Eu sou GKI1.0, posso usar isso?
GKI1 é completamente diferente do GKI2, você deve compilar o kernel sozinho.

65
website/docs/pt_BR/guide/how-to-build.md Normal file
View File

@@ -0,0 +1,65 @@
# Como construir o KernelSU?
Primeiro, você deve ler a documentação oficial do Android para construção do kernel:
1. [Construindo Kernels](https://source.android.com/docs/setup/build/building-kernels)
2. [Versões de lançamento do GKI](https://source.android.com/docs/core/architecture/kernel/gki-release-builds)
::: aviso
Esta página é para dispositivos GKI, se você usa um kernel antigo, consulte [como integrar o KernelSU para kernel antigo](how-to-integrate-for-non-gki)
:::
## Construir Kernel
### Sincronize o código-fonte do kernel
```sh
repo init -u https://android.googlesource.com/kernel/manifest
mv <kernel_manifest.xml> .repo/manifests
repo init -m manifest.xml
repo sync
```
O `<kernel_manifest.xml>` é um arquivo de manifesto que pode determinar uma construção exclusivamente, você pode usar o manifesto para fazer uma construção re-preduzível. Você deve baixar o arquivo de manifesto em [compilações de lançamento do Google GKI](https://source.android.com/docs/core/architecture/kernel/gki-release-builds)
### Construir
Por favor, verifique os [documentos oficiais](https://source.android.com/docs/setup/build/building-kernels) first.
Por exemplo, precisamos construir a imagem do kernel aarch64:
```sh
LTO=thin BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
```
Não se esqueça de adicionar o sinalizador `LTO=thin`, caso contrário a compilação poderá falhar se a memória do seu computador for inferior a 24 Gb.
A partir do Android 13, o kernel é construído pelo `bazel`:
```sh
tools/bazel build --config=fast //common:kernel_aarch64_dist
```
## Construa Kernel com KernelSU
Se você conseguir construir o kernel com sucesso, então construir o KernelSU é muito fácil. Selecione qualquer um executado no diretório raiz de origem do kernel:
- Tag mais recente(estável)
```sh
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -
```
- branch principal(dev)
```sh
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s main
```
- Selecione a tag (Como v0.5.2)
```sh
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.5.2
```
E então reconstrua o kernel e você obterá uma imagem do kernel com KernelSU!

251
website/docs/pt_BR/guide/how-to-integrate-for-non-gki.md Normal file
View File

@@ -0,0 +1,251 @@
# Como integrar o KernelSU para kernels não GKI?
O KernelSU pode ser integrado em kernels não GKI e foi portado para 4.14 e versões anteriores.
Devido à fragmentação de kernels não GKI, não temos uma maneira uniforme de construí-lo, portanto não podemos fornecer imagens de inicialização não GKI. Mas você mesmo pode construir o kernel com o KernelSU integrado.
Primeiro, você deve ser capaz de construir um kernel inicializável a partir do código-fonte do kernel. Se o kernel não for de código aberto, será difícil executar o KernelSU no seu dispositivo.
Se você puder construir um kernel inicializável, existem duas maneiras de integrar o KernelSU ao código-fonte do kernel:
1. Automaticamente com `kprobe`
2. Manualmente
## Integrar com kprobe
O KernelSU usa kprobe para fazer ganchos de kernel, se o *kprobe* funcionar bem em seu kernel, é recomendado usar desta forma.
Primeiro, adicione o KernelSU à árvore de origem do kernel:
```sh
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -
```
Então, você deve verificar se *kprobe* está habilitado na configuração do seu kernel, se não estiver, adicione estas configurações a ele:
```
CONFIG_KPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_KPROBE_EVENTS=y
```
E construa seu kernel novamente, KernelSU deve funcionar bem.
Se você descobrir que o KPROBES ainda não está ativado, você pode tentar ativar `CONFIG_MODULES`. (Se ainda assim não surtir efeito, use `make menuconfig` para procurar outras dependências do KPROBES)
Mas se você encontrar um loop de inicialização quando o KernelSU integrado, talvez *kprobe esteja quebrado em seu kernel*, você deve corrigir o bug do kprobe ou usar o segundo caminho.
:::tip Como verificar se o kprobe está quebrado?
comente `ksu_enable_sucompat()` e `ksu_enable_ksud()` em `KernelSU/kernel/ksu.c`, se o dispositivo inicializar normalmente, então o kprobe pode estar quebrado.
:::
## Modifique manualmente a fonte do kernel
Se o kprobe não funcionar no seu kernel (pode ser um bug do upstream ou do kernel abaixo de 4.8), então você pode tentar desta forma:
Primeiro, adicione o KernelSU à árvore de origem do kernel:
- Tag mais recente (estável)
```sh
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -
```
- branch principal(dev)
```sh
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s main
```
- Selecione a tag(Como v0.5.2)
-
```sh
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.5.2
```
Em seguida, adicione chamadas KernelSU à fonte do kernel. Aqui está um patch para referência:
```diff
diff --git a/fs/exec.c b/fs/exec.c
index ac59664eaecf..bdd585e1d2cc 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1890,11 +1890,14 @@ static int __do_execve_file(int fd, struct filename *filename,
return retval;
}
+extern bool ksu_execveat_hook __read_mostly;
+extern int ksu_handle_execveat(int *fd, struct filename **filename_ptr, void *argv,
+ void *envp, int *flags);
+extern int ksu_handle_execveat_sucompat(int *fd, struct filename **filename_ptr,
+ void *argv, void *envp, int *flags);
static int do_execveat_common(int fd, struct filename *filename,
struct user_arg_ptr argv,
struct user_arg_ptr envp,
int flags)
{
+ if (unlikely(ksu_execveat_hook))
+ ksu_handle_execveat(&fd, &filename, &argv, &envp, &flags);
+ else
+ ksu_handle_execveat_sucompat(&fd, &filename, &argv, &envp, &flags);
return __do_execve_file(fd, filename, argv, envp, flags, NULL);
}
diff --git a/fs/open.c b/fs/open.c
index 05036d819197..965b84d486b8 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -348,6 +348,8 @@ SYSCALL_DEFINE4(fallocate, int, fd, int, mode, loff_t, offset, loff_t, len)
return ksys_fallocate(fd, mode, offset, len);
}
+extern int ksu_handle_faccessat(int *dfd, const char __user **filename_user, int *mode,
+ int *flags);
/*
* access() needs to use the real uid/gid, not the effective uid/gid.
* We do this by temporarily clearing all FS-related capabilities and
@@ -355,6 +357,7 @@ SYSCALL_DEFINE4(fallocate, int, fd, int, mode, loff_t, offset, loff_t, len)
*/
long do_faccessat(int dfd, const char __user *filename, int mode)
{
+ ksu_handle_faccessat(&dfd, &filename, &mode, NULL);
const struct cred *old_cred;
struct cred *override_cred;
struct path path;
diff --git a/fs/read_write.c b/fs/read_write.c
index 650fc7e0f3a6..55be193913b6 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -434,10 +434,14 @@ ssize_t kernel_read(struct file *file, void *buf, size_t count, loff_t *pos)
}
EXPORT_SYMBOL(kernel_read);
+extern bool ksu_vfs_read_hook __read_mostly;
+extern int ksu_handle_vfs_read(struct file **file_ptr, char __user **buf_ptr,
+ size_t *count_ptr, loff_t **pos);
ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos)
{
ssize_t ret;
+ if (unlikely(ksu_vfs_read_hook))
+ ksu_handle_vfs_read(&file, &buf, &count, &pos);
+
if (!(file->f_mode & FMODE_READ))
return -EBADF;
if (!(file->f_mode & FMODE_CAN_READ))
diff --git a/fs/stat.c b/fs/stat.c
index 376543199b5a..82adcef03ecc 100644
--- a/fs/stat.c
+++ b/fs/stat.c
@@ -148,6 +148,8 @@ int vfs_statx_fd(unsigned int fd, struct kstat *stat,
}
EXPORT_SYMBOL(vfs_statx_fd);
+extern int ksu_handle_stat(int *dfd, const char __user **filename_user, int *flags);
+
/**
* vfs_statx - Get basic and extra attributes by filename
* @dfd: A file descriptor representing the base dir for a relative filename
@@ -170,6 +172,7 @@ int vfs_statx(int dfd, const char __user *filename, int flags,
int error = -EINVAL;
unsigned int lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT;
+ ksu_handle_stat(&dfd, &filename, &flags);
if ((flags & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
AT_EMPTY_PATH | KSTAT_QUERY_FLAGS)) != 0)
return -EINVAL;
```
Você deve encontrar as quatro funções no código-fonte do kernel:
1. do_faccessat, geralmente em `fs/open.c`
2. do_execveat_common, geralmente em `fs/exec.c`
3. vfs_read, geralmente em `fs/read_write.c`
4. vfs_statx, geralmente em `fs/stat.c`
Se o seu kernel não tiver `vfs_statx`, use `vfs_fstatat`:
```diff
diff --git a/fs/stat.c b/fs/stat.c
index 068fdbcc9e26..5348b7bb9db2 100644
--- a/fs/stat.c
+++ b/fs/stat.c
@@ -87,6 +87,8 @@ int vfs_fstat(unsigned int fd, struct kstat *stat)
}
EXPORT_SYMBOL(vfs_fstat);
+extern int ksu_handle_stat(int *dfd, const char __user **filename_user, int *flags);
+
int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
int flag)
{
@@ -94,6 +96,8 @@ int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
int error = -EINVAL;
unsigned int lookup_flags = 0;
+ ksu_handle_stat(&dfd, &filename, &flag);
+
if ((flag & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
AT_EMPTY_PATH)) != 0)
goto out;
```
Para kernels anteriores ao 4.17, se você não conseguir encontrar `do_faccessat`, basta ir até a definição do syscall `faccessat` e fazer a chamada lá:
```diff
diff --git a/fs/open.c b/fs/open.c
index 2ff887661237..e758d7db7663 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -355,6 +355,9 @@ SYSCALL_DEFINE4(fallocate, int, fd, int, mode, loff_t, offset, loff_t, len)
return error;
}
+extern int ksu_handle_faccessat(int *dfd, const char __user **filename_user, int *mode,
+ int *flags);
+
/*
* access() needs to use the real uid/gid, not the effective uid/gid.
* We do this by temporarily clearing all FS-related capabilities and
@@ -370,6 +373,8 @@ SYSCALL_DEFINE3(faccessat, int, dfd, const char __user *, filename, int, mode)
int res;
unsigned int lookup_flags = LOOKUP_FOLLOW;
+ ksu_handle_faccessat(&dfd, &filename, &mode, NULL);
+
if (mode & ~S_IRWXO) /* where's F_OK, X_OK, W_OK, R_OK? */
return -EINVAL;
```
Para ativar o SafeMode integrado do KernelSU, você também deve modificar `input_handle_event` em `drivers/input/input.c`:
:::dica
É altamente recomendável habilitar este recurso, é muito útil para evitar bootloops!
:::
```diff
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 45306f9ef247..815091ebfca4 100755
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -367,10 +367,13 @@ static int input_get_disposition(struct input_dev *dev,
return disposition;
}
+extern bool ksu_input_hook __read_mostly;
+extern int ksu_handle_input_handle_event(unsigned int *type, unsigned int *code, int *value);
+
static void input_handle_event(struct input_dev *dev,
unsigned int type, unsigned int code, int value)
{
int disposition = input_get_disposition(dev, type, code, &value);
+
+ if (unlikely(ksu_input_hook))
+ ksu_handle_input_handle_event(&type, &code, &value);
if (disposition != INPUT_IGNORE_EVENT && type != EV_SYN)
add_input_randomness(type, code, value);
```
Finalmente, construa seu kernel novamente, o KernelSU deve funcionar bem.

169
website/docs/pt_BR/guide/installation.md Normal file
View File

@@ -0,0 +1,169 @@
# Instalação
## Verifique se o seu dispositivo é compatível
Baixe o app gerenciador KernelSU em [Lançamentos do GitHub](https://github.com/tiann/KernelSU/releases) ou [Coolapk market](https://www.coolapk.com/apk/me.weishu.kernelsu), e instale-o no seu dispositivo:
- Se o app mostrar `Unsupported`, significa que **Você deve compilar o kernel sozinho**, o KernelSU não fornecerá e nunca fornecerá uma imagem de inicialização para você atualizar.
- Se o app mostrar `Not installed`, então seus dispositivos são oficialmente suportados pelo KernelSU.
:::informações
Para dispositivos mostrando `Unsupported`, aqui está um [Dispositivos com suporte não oficial](unofficially-support-devices.md), você mesmo pode compilar o kernel.
:::
## Backup stock boot.img
Antes de atualizar, você deve primeiro fazer backup do seu stock boot.img. Se você encontrar algum bootloop, você sempre pode restaurar o sistema voltando para a inicialização de fábrica usando o fastboot.
::: aviso
Piscar pode causar perda de dados, certifique-se de executar esta etapa bem antes de prosseguir para a próxima!! Você também pode fazer backup de todos os dados do seu telefone, se necessário.
:::
## Conhecimento necessário
### ADB e fastboot
Por padrão, você usará as ferramentas ADB e fastboot neste tutorial, portanto, se você não as conhece, recomendamos usar um mecanismo de pesquisa para aprender sobre elas primeiro.
### KMI
Kernel Module Interface (KMI), versões de kernel com o mesmo KMI são **compatíveis** Isso é o que "geral" significa no GKI; por outro lado, se o KMI for diferente, então esses kernels não são compatíveis entre si, e atualizar uma imagem do kernel com um KMI diferente do seu dispositivo pode causar um bootloop.
Especificamente, para dispositivos GKI, o formato da versão do kernel deve ser o seguinte:
```txt
KernelRelease :=
Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix
w .x .y -zzz -k -something
```
`w.x-zzz-k` é a versão KMI. Por exemplo, se a versão do kernel de um dispositivo for `5.10.101-android12-9-g30979850fc20`, então seu KMI será `5.10-android12-9`; teoricamente, ele pode inicializar normalmente com outros kernels KMI.
::: dica
Observe que o SubLevel na versão do kernel não faz parte do KMI! Isso significa que `5.10.101-android12-9-g30979850fc20` tem o mesmo KMI que `5.10.137-android12-9-g30979850fc20`!
:::
### Versão do kernel vs Versão do Android
Por favor, observe: **A versão do kernel e a versão do Android não são necessariamente iguais!**
Se você descobrir que a versão do seu kernel é `android12-5.10.101`, mas a versão do seu sistema Android é Android 13 ou outra; não se surpreenda, pois o número da versão do sistema Android não é necessariamente igual ao número da versão do kernel Linux; O número da versão do kernel Linux geralmente é consistente com a versão do sistema Android que acompanha o **dispositivo quando ele é enviado**. Se o sistema Android for atualizado posteriormente, a versão do kernel geralmente não será alterada. Se você precisar atualizar, **consulte sempre a versão do kernel!!**
## Introdução
Existem vários métodos de instalação do KernelSU, cada um adequado para um cenário diferente, portanto escolha conforme necessário.
1. Instale com Recovery personalizado (por exemplo, TWRP)
2. Instale com um aplicativo kernel flash, como Franco Kernel Manager
3. Instale com fastboot usando boot.img fornecido por KernelSU
4. Repare o boot.img manualmente e instale-o
## Instalar com recuperação personalizada
Pré-requisito: Seu dispositivo deve ter um Recovery personalizada, como TWRP; se não ou apenas a Recovery oficial estiver disponível, use outro método.
Etapa:
1. Na [página de lançamento](https://github.com/tiann/KernelSU/releases) do KernelSU, baixe o pacote zip começando com AnyKernel3 que corresponde à versão do seu telefone; por exemplo, a versão do kernel do telefone é `android12-5.10. 66`, então você deve baixar o arquivo `AnyKernel3-android12-5.10.66_yyyy-MM.zip` (onde `yyyy` é o ano e `MM` é o mês).
2. Reinicie o telefone no TWRP.
3. Use adb para colocar AnyKernel3-*.zip no telefone /sdcard e escolha instalá-lo na GUI TWRP; ou você pode diretamente `adb sideload AnyKernel-*.zip` para instalar.
PS. Este método é adequado para qualquer instalação (não limitado à instalação inicial ou atualizações subsequentes), desde que você use TWRP.
## Instalar com Kernel Flasher
Pré-requisito: Seu dispositivo deve estar enraizado. Por exemplo, você instalou o Magisk para obter root ou instalou uma versão antiga do KernelSU e precisa atualizar para outra versão do KernelSU; se o seu dispositivo não estiver enraizado, tente outros métodos.
Etapa:
1. Baixe o zip AnyKernel3; consulte a seção *Instalando com Recovery Personalizado* para obter instruções de download.
2. Abra o app Kernel Flash e use o zip AnyKernel3 fornecido para fazer o flash.
Se você nunca usou o app Kernel flash antes, os seguintes são os mais populares.
1. [Kernel Flasher](https://github.com/capntrips/KernelFlasher/releases)
2. [Franco Kernel Manager](https://play.google.com/store/apps/details?id=com.franco.kernel)
3. [Ex Kernel Manager](https://play.google.com/store/apps/details?id=flar2.exkernelmanager)
PS. Este método é mais conveniente ao atualizar o KernelSU e pode ser feito sem um computador (backup primeiro!).
## Instale com boot.img fornecido por KernelSU
Este método não requer que você tenha TWRP, nem que seu telefone tenha privilégios de root; é adequado para sua primeira instalação do KernelSU.
### Encontre o boot.img adequado
O KernelSU fornece um boot.img genérico para dispositivos GKI e você deve liberar o boot.img para a partição de inicialização do dispositivo.
Você pode baixar o boot.img em [Lançamento do GitHub](https://github.com/tiann/KernelSU/releases), por favor, observe que você deve usar a versão correta do boot.img. Por exemplo, se o seu dispositivo exibe o kernel `android12-5.10.101` , você precisa baixar `android-5.10.101_yyyy-MM.boot-<format>.img`. (Mantenha o KMI consistente!)
Onde `<formato>` se refere ao formato de compactação do kernel do seu boot.img oficial, verifique o formato de compactação do kernel do seu boot.img original, você deve usar o formato correto, por exemplo. `lz4`, `gz`; se você usar um formato de compactação incorreto, poderá encontrar bootloop.
::: informações
1. Você pode usar o magiskboot para obter o formato de compactação da sua inicialização original; é claro que você também pode perguntar a outras crianças mais experientes com o mesmo modelo do seu dispositivo. Além disso, o formato de compactação do kernel geralmente não muda; portanto, se você inicializar com êxito com um determinado formato de compactação, poderá tentar esse formato mais tarde.
2. Os dispositivos Xiaomi geralmente usam `gz` ou **uncompressed**.
3. Para dispositivos Pixel, siga as instruções abaixo.
:::
### flash boot.img para o dispositivo
Use `adb` para conectar seu dispositivo, execute `adb reboot bootloader` para entrar no modo fastboot e use este comando para atualizar o KernelSU:
```sh
fastboot flash boot boot.img
```
::: informações
Se o seu dispositivo suportar `fastboot boot`, você pode primeiro usar `fastboot boot boot.img` para tentar usar o boot.img para inicializar o sistema primeiro. Se algo inesperado acontecer, reinicie-o novamente para inicializar.
:::
### reniciar
Após a conclusão do flash, você deve reiniciar o dispositivo:
```sh
fastboot reboot
```
## Corrigir boot.img manualmente
Para alguns dispositivos, o formato boot.img não é tão comum, como `lz4`, `gz` e descompactado; o mais típico é Pixel, seu formato boot.img é compactado `lz4_legacy`, ramdisk pode ser `gz` também pode ser compactado `lz4_legacy`; neste momento, se você atualizar diretamente o boot.img fornecido pelo KernelSU, o telefone pode não conseguir inicializar; neste momento, você pode corrigir manualmente o boot.img para conseguir isso.
Geralmente existem dois métodos de patch:
1. [Android-Image-Kitchen](https://forum.xda-developers.com/t/tool-android-image-kitchen-unpack-repack-kernel-ramdisk-win-android-linux-mac.2073775/)
2. [magiskboot](https://github.com/topjohnwu/Magisk/releases)
Entre eles, o Android-Image-Kitchen é adequado para operação no PC e o magiskboot precisa da cooperação do telefone celular.
### Preparação
1. Obtenha o stock boot.img do telefone; você pode obtê-lo com os fabricantes do seu dispositivo, você pode precisar do [payload-dumper-go](https://github.com/ssut/payload-dumper-go)
2. Baixe o arquivo zip AnyKernel3 fornecido pelo KernelSU que corresponde à versão KMI do seu dispositivo (você pode consultar *Instalar com Recovery personalizado*).
3. Descompacte o pacote AnyKernel3 e obtenha o arquivo `Image`, que é o arquivo do kernel do KernelSU.
### Usando Android-Image-Kitchen
1. Baixe o Android-Image-Kitchen para o seu computador.
2. Coloque o stock boot.img na pasta raiz do Android-Image-Kitchen.
3. Execute `./unpackimg.sh boot.img` no diretório raiz do Android-Image-Kitchen, este comando descompactará o boot.img e você obterá alguns arquivos.
4. Substitua `boot.img-kernel` no diretório `split_img` pela `Image` que você extraiu do AnyKernel3 (observe a mudança de nome para boot.img-kernel).
5. Execute `./repackimg.sh` no diretório raiz de 在 Android-Image-Kitchen; E você obterá um arquivo chamado `image-new.img`; Atualize este boot.img por fastboot (consulte a seção anterior).
### Usando magiskboot
1. Baixe o Magisk mais recente em [Página de lançamento](https://github.com/topjohnwu/Magisk/releases)
2. Renomeie o Magisk-*.apk para Magisk-vesion.zip e descompacte-o.
3. Envie `Magisk-v25.2/lib/arm64-v8a/libmagiskboot.so` para o seu dispositivo por adb: `adb push Magisk-v25.2/lib/arm64-v8a/libmagiskboot.so /data/local/tmp/magiskboot`
4. Envie stock boot.img e Image em AnyKernel3 para o seu dispositivo.
5. Entre no diretório adb shell e cd `/data/local/tmp/` e, em seguida, `chmod +x magiskboot`
6. Entre no shell adb e no diretório cd `/data/local/tmp/`, execute `./magiskboot unpack boot.img` para descompactar `boot.img`, você obterá um arquivo `kernel`, este é o seu kernel padrão.
7. Substitua `kernel` por `Image`: `mv -f Image kernel`
8. Execute `./magiskboot repack boot.img` para reembalar o boot img, e você obterá um arquivo `new-boot.img`, atualize este arquivo para o dispositivo por fastboot.
## Outros métodos
Na verdade, todos esses métodos de instalação têm apenas uma ideia principal, que é **substituir o kernel original pelo fornecido pelo KernelSU**; desde que isso possa ser alcançado, ele pode ser instalado; por exemplo, a seguir estão outros métodos possíveis.
1. Primeiro instale o Magisk, obtenha privilégios de root através do Magisk e então use o flasher do kernel para atualizar no zip AnyKernel do KernelSU.
2. Use algum kit de ferramentas de atualização em PCs para atualizar no kernel fornecido KernelSU.

257
website/docs/pt_BR/guide/module.md Normal file
View File

@@ -0,0 +1,257 @@
# Guias de módulo
O KernelSU fornece um mecanismo de módulo que consegue modificar o diretório do sistema enquanto mantém a integridade da partição do sistema. Este mecanismo é comumente conhecido como "sem sistema".
O mecanismo do módulo do KernelSU é quase o mesmo do Magisk. Se você está familiarizado com o desenvolvimento de módulos Magisk, o desenvolvimento de módulos KernelSU é muito semelhante. Você pode pular a introdução dos módulos abaixo e só precisa ler [diferença com Magisk](difference-with-magisk.md).
## Busybox
O KernelSU vem com um recurso binário BusyBox completo (incluindo suporte completo a SELinux). O executável está localizado em `/data/adb/ksu/bin/busybox`. O BusyBox do KernelSU suporta o "ASH Standalone Shell Mode" alternável em tempo de execução. O que este modo autônomo significa é que ao executar no shell `ash` do BusyBox, cada comando usará diretamente o miniaplicativo dentro do BusyBox, independentemente do que estiver definido como `PATH`. Por exemplo, comandos como `ls`, `rm`, `chmod` **NÃO** usarão o que está em `PATH` (no caso do Android por padrão será `/system/bin/ls`, ` /system/bin/rm` e `/system/bin/chmod` respectivamente), mas em vez disso chamará diretamente os miniaplicativos internos do BusyBox. Isso garante que os scripts sempre sejam executados em um ambiente previsível e sempre tenham o conjunto completo de comandos, independentemente da versão do Android em que estão sendo executados. Para forçar um comando _não_ a usar o BusyBox, você deve chamar o executável com caminhos completos.
Cada script de shell executado no contexto do KernelSU será executado no shell `ash` do BusyBox com o modo autônomo habilitado. Para o que é relevante para desenvolvedores terceirizados, isso inclui todos os scripts de inicialização e scripts de instalação de módulos.
Para aqueles que desejam usar este recurso de “Modo Autônomo” fora do KernelSU, existem 2 maneiras de habilitá-lo:
1. Defina a variável de ambiente `ASH_STANDALONE` como `1`<br>Exemplo: `ASH_STANDALONE=1 /data/adb/ksu/bin/busybox sh <script>`
2. Alternar com opções de linha de comando:<br>`/data/adb/ksu/bin/busybox sh -o standalone <script>`
Para garantir que todos os shells `sh` subsequentes executados também sejam executados em modo autônomo, a opção 1 é o método preferido (e é isso que o KernelSU e o gerenciador KernelSU usam internamente), pois as variáveis ​​de ambiente são herdadas para os processos filhos.
::: tip diferença com Magisk
O BusyBox do KernelSU agora está usando o arquivo binário compilado diretamente do projeto Magisk. **Obrigado ao Magisk!** Portanto, você não precisa se preocupar com problemas de compatibilidade entre scripts BusyBox no Magisk e KernelSU porque eles são exatamente iguais!
:::
## Módulos KernelSU
Um módulo KernelSU é uma pasta colocada em `/data/adb/modules` com a estrutura abaixo:
```txt
/data/adb/modules
├── .
├── .
|
├── $MODID <--- The folder is named with the ID of the module
│ │
│ │ *** Module Identity ***
│ │
│ ├── module.prop <--- This file stores the metadata of the module
│ │
│ │ *** Main Contents ***
│ │
│ ├── system <--- This folder will be mounted if skip_mount does not exist
│ │ ├── ...
│ │ ├── ...
│ │ └── ...
│ │
│ │ *** Status Flags ***
│ │
│ ├── skip_mount <--- If exists, KernelSU will NOT mount your system folder
│ ├── disable <--- If exists, the module will be disabled
│ ├── remove <--- If exists, the module will be removed next reboot
│ │
│ │ *** Optional Files ***
│ │
│ ├── post-fs-data.sh <--- This script will be executed in post-fs-data
│ ├── post-mount.sh <--- This script will be executed in post-mount
│ ├── service.sh <--- This script will be executed in late_start service
│ ├── boot-completed.sh <--- This script will be executed on boot completed
| ├── uninstall.sh <--- This script will be executed when KernelSU removes your module
│ ├── system.prop <--- Properties in this file will be loaded as system properties by resetprop
│ ├── sepolicy.rule <--- Additional custom sepolicy rules
│ │
│ │ *** Auto Generated, DO NOT MANUALLY CREATE OR MODIFY ***
│ │
│ ├── vendor <--- A symlink to $MODID/system/vendor
│ ├── product <--- A symlink to $MODID/system/product
│ ├── system_ext <--- A symlink to $MODID/system/system_ext
│ │
│ │ *** Any additional files / folders are allowed ***
│ │
│ ├── ...
│ └── ...
|
├── another_module
│ ├── .
│ └── .
├── .
├── .
```
::: tip diferença com Magisk
KernelSU não possui suporte integrado para o Zygisk, portanto não há conteúdo relacionado ao Zygisk no módulo. No entanto, você pode usar [ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU) para suportar módulos Zygisk. Neste caso, o conteúdo do módulo Zygisk é idêntico ao suportado pelo Magisk.
:::
### module.prop
module.prop é um arquivo de configuração para um módulo. No KernelSU, se um módulo não contiver este arquivo, ele não será reconhecido como um módulo. O formato deste arquivo é o seguinte:
```txt
id=<string>
name=<string>
version=<string>
versionCode=<int>
author=<string>
description=<string>
```
- `id` deve corresponder a esta expressão regular: `^[a-zA-Z][a-zA-Z0-9._-]+$`<br>
ex: ✓ `a_module`, ✓ `a.module`, ✓ `module-101`, ✗ `a module`, ✗ `1_module`, ✗ `-a-module`<br>
Este é o **identificador exclusivo** do seu módulo. Você não deve alterá-lo depois de publicado.
- `versionCode` deve ser um **inteiro**. Isso é usado para comparar versões
- Outros que não foram mencionados acima podem ser qualquer string de **linha única**.
- Certifique-se de usar o tipo de quebra de linha `UNIX (LF)` e não o `Windows (CR+LF)` ou `Macintosh (CR)`.
### Shell scripts
Por favor, leia a seção [Scripts de inicialização](#boot-scripts) para entender a diferença entre `post-fs-data.sh` e `service.sh`. Para a maioria dos desenvolvedores de módulos, `service.sh` deve ser bom o suficiente se você precisar apenas executar um script de inicialização. Se precisar executar o script após a inicialização ser concluída, use `boot-completed.sh`. Se você quiser fazer algo após montar overlayfs, use `post-mount.sh`.
Em todos os scripts do seu módulo, use `MODDIR=${0%/*}` para obter o caminho do diretório base do seu módulo; **NÃO** codifique o caminho do seu módulo em scripts.
::: tip diferença com Magisk
Você pode usar a variável de ambiente KSU para determinar se um script está sendo executado no KernelSU ou Magisk. Se estiver executando em KernelSU, esse valor será definido como verdadeiro.
:::
### `system` diretório
O conteúdo deste diretório será sobreposto à partição /system do sistema usando overlayfs após a inicialização do sistema. Isso significa que:
1. Arquivos com o mesmo nome daqueles no diretório correspondente no sistema serão substituídos pelos arquivos deste diretório.
2. Pastas com o mesmo nome daquelas no diretório correspondente no sistema serão mescladas com as pastas neste diretório.
Se você deseja excluir um arquivo ou pasta no diretório original do sistema, você precisa criar um arquivo com o mesmo nome do arquivo/pasta no diretório do módulo usando `mknod filename c 0 0`. Dessa forma, o sistema overlayfs irá automaticamente "branquear" este arquivo como se ele tivesse sido excluído (a partição /system não foi realmente alterada).
Você também pode declarar uma variável chamada `REMOVE` contendo uma lista de diretórios em `customize.sh` para executar operações de remoção, e KernelSU executará automaticamente `mknod <TARGET> c 0 0` nos diretórios correspondentes do módulo. Por exemplo:
```sh
REMOVE="
/system/app/YouTube
/system/app/Bloatware
"
```
A lista acima irá executar `mknod $MODPATH/system/app/YouTuBe c 0 0` e `mknod $MODPATH/system/app/Bloatware c 0 0`; e `/system/app/YouTube` e `/system/app/Bloatware` serão removidos após o módulo entrar em vigor.
Se você deseja substituir um diretório no sistema, você precisa criar um diretório com o mesmo caminho no diretório do módulo e, em seguida, definir o atributo `setfattr -n Trusted.overlay.opaque -v y <TARGET>` para este diretório. Desta forma, o sistema overlayfs substituirá automaticamente o diretório correspondente no sistema (sem alterar a partição /system).
Você pode declarar uma variável chamada `REPLACE` em seu arquivo `customize.sh`, que inclui uma lista de diretórios a serem substituídos, e KernelSU executará automaticamente as operações correspondentes em seu diretório de módulo. Por exemplo:
REPLACE="
/system/app/YouTube
/system/app/Bloatware
"
Esta lista criará automaticamente os diretórios `$MODPATH/system/app/YouTube` e `$MODPATH/system/app/Bloatware` e, em seguida, executará `setfattr -n Trusted.overlay.opaque -v e $MODPATH/system/app/ YouTube` e `setfattr -n Trusted.overlay.opaque -v e $MODPATH/system/app/Bloatware`. Após o módulo entrar em vigor, `/system/app/YouTube` e `/system/app/Bloatware` serão substituídos por diretórios vazios.
::: tip diferença com Magisk
O mecanismo sem sistema do KernelSU é implementado através do overlayfs do kernel, enquanto o Magisk atualmente usa montagem mágica (montagem de ligação). Os dois métodos de implementação têm diferenças significativas, mas o objetivo final é o mesmo: modificar os arquivos /system sem modificar fisicamente a partição /system.
:::
Se você estiver interessado em overlayfs, é recomendável ler a [documentação sobre overlayfs do Kernel Linux](https://docs.kernel.org/filesystems/overlayfs.html).
### system.prop
Este arquivo segue o mesmo formato de `build.prop`. Cada linha é composta por `[chave]=[valor]`.
### sepolicy.rule
Se o seu módulo exigir alguns patches adicionais de sepolicy, adicione essas regras a este arquivo. Cada linha neste arquivo será tratada como uma declaração de política.
## Instalador de módulo
Um instalador de módulo KernelSU é um módulo KernelSU empacotado em um arquivo zip que pode ser atualizado no app gerenciador KernelSU. O instalador de módulo KernelSU mais simples é apenas um módulo KernelSU compactado como um arquivo zip.
```txt
module.zip
│
├── customize.sh <--- (Optional, more details later)
│ This script will be sourced by update-binary
├── ...
├── ... /* The rest of module's files */
│
```
:::aviso
O módulo KernelSU NÃO é compatível para instalação no recovery personalizado!!
:::
### Costumização
Se precisar personalizar o processo de instalação do módulo, opcionalmente você pode criar um script no instalador chamado `customize.sh`. Este script será _sourced_ (não executado!) pelo script do instalador do módulo depois que todos os arquivos forem extraídos e as permissões padrão e o contexto secundário forem aplicados. Isso é muito útil se o seu módulo exigir configuração adicional com base na ABI do dispositivo ou se você precisar definir permissões/segundo contexto especiais para alguns dos arquivos do seu módulo.
Se você quiser controlar e personalizar totalmente o processo de instalação, declare `SKIPUNZIP=1` em `customize.sh` para pular todas as etapas de instalação padrão. Ao fazer isso, seu `customize.sh` será responsável por instalar tudo sozinho.
O script `customize.sh` é executado no shell BusyBox `ash` do KernelSU com o "Modo autônomo" ativado. As seguintes variáveis ​​e funções estão disponíveis:
#### Variáveis
- `KSU` (bool): uma variável para marcar que o script está sendo executado no ambiente KernelSU, e o valor desta variável sempre será true. Você pode usá-lo para distinguir entre KernelSU e Magisk.
- `KSU_VER` (string): a string da versão do KernelSU atualmente instalado (por exemplo, `v0.4.0`)
- `KSU_VER_CODE` (int): o código da versão do KernelSU atualmente instalado no espaço do usuário (por exemplo, `10672`)
- `KSU_KERNEL_VER_CODE` (int): o código da versão do KernelSU atualmente instalado no espaço do kernel (por exemplo, `10672`)
- `BOOTMODE` (bool): sempre seja `true` no KernelSU
- `MODPATH` (path): o caminho onde os arquivos do seu módulo devem ser instalados
- `TMPDIR` (path): um lugar onde você pode armazenar arquivos temporariamente
- `ZIPFILE` (path): zip de instalação do seu módulo
- `ARCH` (string): a arquitetura da CPU do dispositivo. O valor é `arm`, `arm64`, `x86` ou `x64`
- `IS64BIT` (bool): `true` se `$ARCH` for `arm64` ou `x64`
- `API` (int): o nível da API (versão Android) do dispositivo (por exemplo, `23` para Android 6.0)
::: aviso
No KernelSU, MAGISK_VER_CODE é sempre 25200 e MAGISK_VER é sempre v25.2. Por favor, não use essas duas variáveis ​​para determinar se ele está sendo executado no KernelSU ou não.
:::
#### Funções
```txt
ui_print <msg>
print <msg> to console
Avoid using 'echo' as it will not display in custom recovery's console
abort <msg>
print error message <msg> to console and terminate the installation
Avoid using 'exit' as it will skip the termination cleanup steps
set_perm <target> <owner> <group> <permission> [context]
if [context] is not set, the default is "u:object_r:system_file:s0"
this function is a shorthand for the following commands:
chown owner.group target
chmod permission target
chcon context target
set_perm_recursive <directory> <owner> <group> <dirpermission> <filepermission> [context]
if [context] is not set, the default is "u:object_r:system_file:s0"
for all files in <directory>, it will call:
set_perm file owner group filepermission context
for all directories in <directory> (including itself), it will call:
set_perm dir owner group dirpermission context
```
## Scripts de inicialização
No KernelSU, os scripts são divididos em dois tipos com base em seu modo de execução: modo post-fs-data e modo de serviço late_start:
- modo post-fs-data
- Esta etapa está BLOQUEANDO. O processo de inicialização é pausado antes da execução ser concluída ou 10 segundos se passaram.
- Os scripts são executados antes de qualquer módulo ser montado. Isso permite que um desenvolvedor de módulo ajuste dinamicamente seus módulos antes de serem montados.
- Este estágio acontece antes do início do Zygote, o que significa praticamente tudo no Android
- **AVISO:** usar `setprop` irá bloquear o processo de inicialização! Por favor, use `resetprop -n <prop_name> <prop_value>` em vez disso.
- **Execute scripts neste modo apenas se necessário.**
- modo de serviço late_start
- Esta etapa é SEM BLOQUEIO. Seu script é executado em paralelo com o restante do processo de inicialização.
- **Este é o estágio recomendado para executar a maioria dos scripts.**
No KernelSU, os scripts de inicialização são divididos em dois tipos com base no local de armazenamento: scripts gerais e scripts de módulo:
- Scripts Gerais
- Colocado em `/data/adb/post-fs-data.d`, `/data/adb/service.d`, `/data/adb/post-mount.d` ou `/data/adb/boot- concluído.d`
- Somente executado se o script estiver definido como executável (`chmod +x script.sh`)
- Os scripts em `post-fs-data.d` são executados no modo post-fs-data e os scripts em `service.d` são executados no modo de serviço late_start.
- Os módulos **NÃO** devem adicionar scripts gerais durante a instalação
- Scripts de Módulo
- Colocado na própria pasta do módulo
- Executado apenas se o módulo estiver habilitado
- `post-fs-data.sh` é executado no modo post-fs-data, `service.sh` é executado no modo de serviço late_start, `boot-completed.sh` é executado na inicialização concluída, `post-mount.sh` é executado em overlayfs montado.
Todos os scripts de inicialização serão executados no shell BusyBox `ash` do KernelSU com o "Modo Autônomo" ativado.

50
website/docs/pt_BR/guide/rescue-from-bootloop.md Normal file
View File

@@ -0,0 +1,50 @@
# Resgate do bootloop
Ao atualizar um dispositivo, podemos encontrar situações em que o dispositivo fica "emparedado". Em teoria, se você usar o fastboot apenas para atualizar a partição de boot ou instalar módulos inadequados que causam falha na inicialização do dispositivo, isso poderá ser restaurado por meio de operações apropriadas. Este documento tem como objetivo fornecer alguns métodos de emergência para ajudá-lo a se recuperar de um dispositivo "bloqueado".
## Bloqueio por piscar partição boot
No KernelSU, as seguintes situações podem causar bloqueio de inicialização ao atualizar a partição boot:
1. Você atualizou uma imagem boot no formato errado. Por exemplo, se o formato de boot do seu telefone for `gz`, mas você atualizou uma imagem no formato `lz4`, o telefone não será capaz de inicializar.
2. Seu telefone precisa desativar a verificação AVB para inicializar corretamente (geralmente exigindo a limpeza de todos os dados do telefone).
3. Seu kernel tem alguns bugs ou não é adequado para o flash do seu telefone.
Não importa qual seja a situação, você pode recuperar **atualizando a stock boot image**. Portanto, no início do tutorial de instalação, recomendamos fortemente que você faça backup de seu boot padrão antes de atualizar. Se você não fez backup, poderá obter o boot original de fábrica de outros usuários com o mesmo dispositivo que você ou do firmware oficial.
## Bloqueio por módulos
A instalação de módulos pode ser uma causa mais comum de bloqueio do seu dispositivo, mas devemos avisá-lo seriamente: **Não instale módulos de fontes desconhecidas**! Como os módulos têm privilégios de root, eles podem causar danos irreversíveis ao seu dispositivo!
### Módulos normais
Se você atualizou um módulo que foi comprovadamente seguro, mas faz com que seu dispositivo não inicialize, então esta situação é facilmente recuperável no KernelSU sem qualquer preocupação. KernelSU possui mecanismos integrados para resgatar seu dispositivo, incluindo o seguinte:
1. Atualização AB
2. Resgate pressionando o botão de diminuir volume
#### Atualização AB
As atualizações do módulo KernelSU inspiram-se no mecanismo de atualização AB do sistema Android usado em atualizações OTA. Se você instalar um novo módulo ou atualizar um existente, isso não modificará diretamente o arquivo do módulo usado atualmente. Em vez disso, todos os módulos serão integrados em outra imagem de atualização. Depois que o sistema for reiniciado, ele tentará começar a usar esta imagem de atualização. Se o sistema Android inicializar com sucesso, os módulos serão realmente atualizados.
Portanto, o método mais simples e comumente usado para resgatar seu dispositivo é **forçar uma reinicialização**. Se você não conseguir iniciar o sistema após atualizar um módulo, você pode pressionar e segurar o botão liga/desliga por mais de 10 segundos e o sistema será reinicializado automaticamente; após a reinicialização, ele retornará ao estado anterior à atualização do módulo e os módulos atualizados anteriormente serão desativados automaticamente.
#### Resgate pressionando o botão de diminuir volume
Se as atualizações AB ainda não resolverem o problema, você pode tentar usar o **Modo de segurança**. No Modo de Segurança, todos os módulos estão desabilitados.
Existem duas maneiras de entrar no modo de segurança:
1. O Modo de Segurança integrado de alguns sistemas; alguns sistemas possuem um Modo de Segurança integrado que pode ser acessado pressionando longamente o botão de diminuir volume, enquanto outros (como MIUI) podem ativar o Modo de Segurança no Recovery. Ao entrar no Modo de Segurança do sistema, o KernelSU também entrará no Modo de Segurança e desativará automaticamente os módulos.
2. O Modo de Segurança integrado do KernelSU; o método de operação é **pressionar a tecla de diminuir volume continuamente por mais de três vezes** após a primeira tela de inicialização. Observe que é um comunicado à imprensa, um comunicado à imprensa, um comunicado à imprensa, não pressione e segure.
Após entrar no Modo de Segurança, todos os módulos na página de módulos do Gerenciador KernelSU são desabilitados, mas você pode executar operações de "desinstalação" para desinstalar quaisquer módulos que possam estar causando problemas.
O modo de segurança integrado é implementado no kernel, portanto não há possibilidade de perder eventos importantes devido à interceptação. No entanto, para kernels não GKI, a integração manual do código pode ser necessária e você pode consultar a documentação oficial para obter orientação.
### Módulos maliciosos
Se os métodos acima não conseguirem recuperar seu dispositivo, é altamente provável que o módulo que você instalou tenha operações maliciosas ou tenha danificado seu dispositivo por outros meios. Neste caso, existem apenas duas sugestões:
1. Limpe os dados e atualize o sistema oficial.
2. Consulte o serviço pós-venda.

30
website/docs/pt_BR/guide/unofficially-support-devices.md Normal file
View File

@@ -0,0 +1,30 @@
# Dispositivos não oficialmente suportados
::: aviso
Nesta página, existem kernels para dispositivos não GKI que suportam KernelSU mantidos por outros desenvolvedores.
:::
::: aviso
Esta página é apenas para você encontrar o código-fonte correspondente ao seu dispositivo. **NÃO** significa que o código-fonte foi revisado por _KernelSU Developers_. Você deve usá-lo por sua própria conta e risco.
:::
<script setup>
import data from '../repos.json'
</script>
<table>
<thead>
<tr>
<th>Mantenedor</th>
<th>Repositório</th>
<th>Dispositivos suportados</th>
</tr>
</thead>
<tbody>
<tr v-for="repo in data" :key="repo.devices">
<td><a :href="repo.maintainer_link" target="_blank" rel="noreferrer">{{ repo.maintainer }}</a></td>
<td><a :href="repo.kernel_link" target="_blank" rel="noreferrer">{{ repo.kernel_name }}</a></td>
<td>{{ repo.devices }}</td>
</tr>
</tbody>
</table>

21
website/docs/pt_BR/guide/what-is-kernelsu.md Normal file
View File

@@ -0,0 +1,21 @@
# O que é KernelSU?
O KernelSU é uma solução root para dispositivos Android GKI, funciona no modo kernel e concede permissão root ao app do espaço do usuário diretamente no espaço do kernel.
## Características
A principal característica do KernelSU é que ele é **baseado em kernel**. KernelSU funciona no modo kernel, portanto pode fornecer uma interface de kernel que nunca tivemos antes. Por exemplo, podemos adicionar um ponto de interrupção de hardware a qualquer processo no modo kernel; Podemos acessar a memória física de qualquer processo sem que ninguém perceba; Podemos interceptar qualquer syscall no espaço do kernel; etc.
E também, o KernelSU fornece um sistema de módulos via overlayfs, que permite carregar seu plugin personalizado no sistema. Ele também fornece um mecanismo para modificar arquivos na partição `/system`.
## Como usar
Consulte: [Instalação](installation)
## Como construir
[Como construir](how-to-build)
## Discussão
- Telegram: [@KernelSU](https://t.me/KernelSU)

29
website/docs/pt_BR/index.md Normal file
View File

@@ -0,0 +1,29 @@
---
layout: home
title: Uma solução raiz baseada em kernel para Android
hero:
name: KernelSU
text: Uma solução raiz baseada em kernel para Android
tagline: ""
image:
src: /logo.png
alt: KernelSU
actions:
- theme: brand
text: Iniciar
link: /pt_BR/guide/what-is-kernelsu
- theme: alt
text: Ver no GitHub
link: https://github.com/tiann/KernelSU
features:
- title: Baseado em kernel
details: KernelSU está funcionando no modo kernel Linux, tem mais controle sobre os apps do espaço do usuário.
- title: Controle de acesso à lista de permissões
details: Somente apps que recebem permissão de root podem acessar `su`, outros apps não podem perceber su.
- title: Permissão de root restrita
details: KernelSU permite que você personalize o uid, gid, grupos, recursos e regras SELinux do su. Tranque o poder raiz em uma gaiola.
- title: Módulo e Código aberto
details: KernelSU suporta modificação /system sem sistema por overlayfs e é de código aberto sob GPL-3.