From c19ba7fab06043b20f6863bbf378c10300960f49 Mon Sep 17 00:00:00 2001 From: igor <134963561+igormiguell@users.noreply.github.com> Date: Mon, 18 Sep 2023 06:22:17 -0300 Subject: [PATCH] Add Brazilian Portuguese language to the website (#965) --- docs/README_PT-BR.md | 18 +- website/docs/.vitepress/locales/index.ts | 7 + website/docs/.vitepress/locales/pt_BR.ts | 61 +++++ website/docs/pt_BR/guide/app-profile.md | 118 ++++++++ .../pt_BR/guide/difference-with-magisk.md | 28 ++ website/docs/pt_BR/guide/faq.md | 67 +++++ website/docs/pt_BR/guide/how-to-build.md | 65 +++++ .../guide/how-to-integrate-for-non-gki.md | 251 +++++++++++++++++ website/docs/pt_BR/guide/installation.md | 169 ++++++++++++ website/docs/pt_BR/guide/module.md | 257 ++++++++++++++++++ .../docs/pt_BR/guide/rescue-from-bootloop.md | 50 ++++ .../guide/unofficially-support-devices.md | 30 ++ website/docs/pt_BR/guide/what-is-kernelsu.md | 21 ++ website/docs/pt_BR/index.md | 29 ++ 14 files changed, 1162 insertions(+), 9 deletions(-) create mode 100644 website/docs/.vitepress/locales/pt_BR.ts create mode 100644 website/docs/pt_BR/guide/app-profile.md create mode 100644 website/docs/pt_BR/guide/difference-with-magisk.md create mode 100644 website/docs/pt_BR/guide/faq.md create mode 100644 website/docs/pt_BR/guide/how-to-build.md create mode 100644 website/docs/pt_BR/guide/how-to-integrate-for-non-gki.md create mode 100644 website/docs/pt_BR/guide/installation.md create mode 100644 website/docs/pt_BR/guide/module.md create mode 100644 website/docs/pt_BR/guide/rescue-from-bootloop.md create mode 100644 website/docs/pt_BR/guide/unofficially-support-devices.md create mode 100644 website/docs/pt_BR/guide/what-is-kernelsu.md create mode 100644 website/docs/pt_BR/index.md diff --git a/docs/README_PT-BR.md b/docs/README_PT-BR.md index 89226eda..fc9b81e0 100644 --- a/docs/README_PT-BR.md +++ b/docs/README_PT-BR.md @@ -1,32 +1,32 @@ -[English](README.md) | [Español](README_ES.md) | [简体中文](README_CN.md) | [繁體中文](README_TW.md) | [日本語](README_JP.md) | [Polski](README_PL.md) | **Portuguese-Brazil** | [Türkçe](README_TR.md) | [Русский](README_RU.md) | [Tiếng Việt](README_VI.md) | [Indonesia](README_ID.md) +[English](README.md) | [Español](README_ES.md) | [简体中文](README_CN.md) | [繁體中文](README_TW.md) | [日本語](README_JP.md) | [Polski](README_PL.md) | **Português (Brasil)** | [Türkçe](README_TR.md) | [Русский](README_RU.md) | [Tiếng Việt](README_VI.md) | [Indonesia](README_ID.md) # KernelSU -Uma solução raiz baseada em Kernel para dispositivos Android. +Uma solução raiz baseada em kernel para dispositivos Android. ## Características -1. `su` baseado em kernel e gerenciamento de acesso root. +1. `su` e gerenciamento de acesso root baseado em kernel. 2. Sistema modular baseado em overlayfs. -3. [App Perfil](https://kernelsu.org/guide/app-profile.html): Tranque o poder raiz em uma gaiola. +3. [Perfil do Aplicativo](https://kernelsu.org/guide/app-profile.html): Tranque o poder raiz em uma gaiola. -## Estado de compatibilidade +## Estado de Compatibilidade O KernelSU suporta oficialmente dispositivos Android GKI 2.0 (com kernel 5.10+), kernels antigos (4.14+) também são compatíveis, mas você mesmo precisa construir o kernel. WSA, ChromeOS e Android baseado em contêiner também deve funcionar com o KernelSU integrado. -E os ABIs atualmente suportados são: `arm64-v8a` e `x86_64` +E as ABIs atualmente suportadas são: `arm64-v8a` e `x86_64` ## Uso -- [Instalação](https://kernelsu.org/guide/installation.html) + - [Instrução de instalação](https://kernelsu.org/guide/installation.html) - [Como construir?](https://kernelsu.org/guide/how-to-build.html) - [Site Oficial](https://kernelsu.org/) ## Tradução -Para traduzir o KernelSU para o seu idioma, ou para melhorar uma tradução existente, use o [Weblate](https://hosted.weblate.org/engage/kernelsu/), por favor. +Para traduzir o KernelSU para o seu idioma ou melhorar uma tradução existente, use o [Weblate](https://hosted.weblate.org/engage/kernelsu/), por favor. ## Discussão @@ -41,6 +41,6 @@ Para traduzir o KernelSU para o seu idioma, ou para melhorar uma tradução exis ## Créditos - [kernel-assisted-superuser](https://git.zx2c4.com/kernel-assisted-superuser/about/): a ideia do KernelSU. -- [Magisk](https://github.com/topjohnwu/Magisk): a implementação da sepolicy. +- [Magisk](https://github.com/topjohnwu/Magisk): a poderosa ferramenta raiz. - [genuine](https://github.com/brevent/genuine/): validação de assinatura apk v2. - [Diamorphine](https://github.com/m0nad/Diamorphine): algumas habilidades de rootkit. diff --git a/website/docs/.vitepress/locales/index.ts b/website/docs/.vitepress/locales/index.ts index de728a6a..750e321b 100644 --- a/website/docs/.vitepress/locales/index.ts +++ b/website/docs/.vitepress/locales/index.ts @@ -6,6 +6,7 @@ import vi_VN from './vi_VN' import id_ID from './id_ID' import ja_JP from './ja_JP' import ru_RU from './ru_RU' +import pt_BR from './pt_BR' export default defineConfig({ locales: { @@ -50,6 +51,12 @@ export default defineConfig({ lang: ru_RU.lang, themeConfig: ru_RU.themeConfig, description: ru_RU.description + }, + pt_BR: { + label: 'Português (Brasil)', + lang: pt_BR.lang, + themeConfig: pt_BR.themeConfig, + description: pt_BR.description } } }) diff --git a/website/docs/.vitepress/locales/pt_BR.ts b/website/docs/.vitepress/locales/pt_BR.ts new file mode 100644 index 00000000..9448aa8c --- /dev/null +++ b/website/docs/.vitepress/locales/pt_BR.ts @@ -0,0 +1,61 @@ +import { createRequire } from 'module' +import { defineConfig } from 'vitepress' + +const require = createRequire(import.meta.url) +const pkg = require('vitepress/package.json') + +export default defineConfig({ + lang: 'pt-BR', + description: 'Uma solução raiz baseada em kernel para dispositivos Android GKI.', + + themeConfig: { + nav: nav(), + + lastUpdatedText: 'Última atualização', + + sidebar: { + '/pt_BR/guide/': sidebarGuide() + }, + + socialLinks: [ + { icon: 'github', link: 'https://github.com/tiann/KernelSU' } + ], + + footer: { + message: 'Lançado sob a Licença GPL3.', + copyright: 'Copyright © Desenvolvedores KernelSU atuais de 2022' + }, + + editLink: { + pattern: 'https://github.com/tiann/KernelSU/edit/main/website/docs/:path', + text: 'Edite esta página no GitHub' + } + } +}) + +function nav() { + return [ + { text: 'Guia', link: '/pt_BR/guide/what-is-kernelsu' }, + { text: 'Github', link: 'https://github.com/tiann/KernelSU' } + ] +} + +function sidebarGuide() { + return [ + { + text: 'Guia', + items: [ + { text: 'O que é KernelSU?', link: '/pt_BR/guide/what-is-kernelsu' }, + { text: 'Instalação', link: '/pt_BR/guide/installation' }, + { text: 'Como construir?', link: '/pt_BR/guide/how-to-build' }, + { text: 'Integração para dispositivos não GKI', link: '/pt_BR/guide/how-to-integrate-for-non-gki'}, + { text: 'Dispositivos com suporte não oficial', link: '/pt_BR/guide/unofficially-support-devices.md' }, + { text: 'Guia do Módulo', link: '/guide/module.md' }, + { text: 'Perfil do Aplicativo', link: '/pt_BR/guide/app-profile.md' }, + { text: 'Resgate do bootloop', link: '/pt_BR/guide/rescue-from-bootloop.md' }, + { text: 'FAQ', link: '/guide/faq' }, + { text: 'Recursos ocultos', link: '/pt_BR/guide/hidden-features' }, + ] + } + ] +} diff --git a/website/docs/pt_BR/guide/app-profile.md b/website/docs/pt_BR/guide/app-profile.md new file mode 100644 index 00000000..35b74ecf --- /dev/null +++ b/website/docs/pt_BR/guide/app-profile.md @@ -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. +::: diff --git a/website/docs/pt_BR/guide/difference-with-magisk.md b/website/docs/pt_BR/guide/difference-with-magisk.md new file mode 100644 index 00000000..7d882053 --- /dev/null +++ b/website/docs/pt_BR/guide/difference-with-magisk.md @@ -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. diff --git a/website/docs/pt_BR/guide/faq.md b/website/docs/pt_BR/guide/faq.md new file mode 100644 index 00000000..18d0ef17 --- /dev/null +++ b/website/docs/pt_BR/guide/faq.md @@ -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. diff --git a/website/docs/pt_BR/guide/how-to-build.md b/website/docs/pt_BR/guide/how-to-build.md new file mode 100644 index 00000000..197445dc --- /dev/null +++ b/website/docs/pt_BR/guide/how-to-build.md @@ -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 .repo/manifests +repo init -m manifest.xml +repo sync +``` + +O `` é 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! diff --git a/website/docs/pt_BR/guide/how-to-integrate-for-non-gki.md b/website/docs/pt_BR/guide/how-to-integrate-for-non-gki.md new file mode 100644 index 00000000..12ce8cb2 --- /dev/null +++ b/website/docs/pt_BR/guide/how-to-integrate-for-non-gki.md @@ -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. \ No newline at end of file diff --git a/website/docs/pt_BR/guide/installation.md b/website/docs/pt_BR/guide/installation.md new file mode 100644 index 00000000..259e5e7a --- /dev/null +++ b/website/docs/pt_BR/guide/installation.md @@ -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-.img`. (Mantenha o KMI consistente!) + +Onde `` 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. diff --git a/website/docs/pt_BR/guide/module.md b/website/docs/pt_BR/guide/module.md new file mode 100644 index 00000000..c4e726cf --- /dev/null +++ b/website/docs/pt_BR/guide/module.md @@ -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`
Exemplo: `ASH_STANDALONE=1 /data/adb/ksu/bin/busybox sh + + + + + + + + + + + + + + + + +
MantenedorRepositórioDispositivos suportados
{{ repo.maintainer }}{{ repo.kernel_name }}{{ repo.devices }}
\ No newline at end of file diff --git a/website/docs/pt_BR/guide/what-is-kernelsu.md b/website/docs/pt_BR/guide/what-is-kernelsu.md new file mode 100644 index 00000000..34886b21 --- /dev/null +++ b/website/docs/pt_BR/guide/what-is-kernelsu.md @@ -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) diff --git a/website/docs/pt_BR/index.md b/website/docs/pt_BR/index.md new file mode 100644 index 00000000..2b09cbf4 --- /dev/null +++ b/website/docs/pt_BR/index.md @@ -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. +