Por que o binário su simplesmente não pode ser copiado (resposta técnica, por favor)

Enraizei vários dispositivos Samsung e o "objetivo" subjacente, por assim dizer, parece ser o de obter o subinário /system/xbine instalar o Superuser.apk .

Minha pergunta é por que alguém precisa pular todos esses bastidores para fazer root no telefone (instalar recuperação personalizada e ROM pré-enraizada em flash ou explorar a instalação atual)? Não era possível baixar um su pré-compilado, movê-lo para o cartão SD e executá-lo via adb? O que parece fazer uma ROM "pré-enraizada" é que ela possui Superusuário e o binário em seus respectivos caminhos do sistema. Não vejo por que é tão importante que é executado /system/xbin.

— user974896
fonte

Respostas:

O binário su precisa da execução e do conjunto de bits de permissão setuid. O primeiro é necessário para que o arquivo possa ser executado e o segundo é que ele seja executado automaticamente com os direitos do proprietário do arquivo (definir ID do usuário ou setuid. Nesse caso, o proprietário é root. Leia mais aqui ).

Os arquivos no armazenamento externo não têm os bits de permissão executável e setuid definidos e não podem ser concedidos sem direitos de root. Observe também que o cartão SD é montado com o sinalizador 'noexec' para impedir a execução geralmente de inicialização:

shell@android:/sdcard $ ./su
/system/bin/sh: ./su: can't execute: Permission denied
126|shell@android:/sdcard $ chmod 4755 su
Unable to chmod su: Operation not permitted
10|shell@android:/sdcard $ mount | grep /mnt/sdcard
/dev/block/mmcblk0p1 /mnt/sdcard vfat [...],noexec,[...]

É basicamente por isso que você não pode simplesmente copiar supara o cartão SD e depois executá-lo para se garantir como root.

— eldarerathis
fonte

Então essa é a única coisa que impede o enraizamento, o fato de que / sdcard não é executável e você não pode chmod? Uma vez que su esteja no local apropriado, onde ele pode ser executado como seu ouro. Eu pensaria que haveria uma camada de segurança para impedir que alguém simplesmente executasse su. No meu servidor e na caixa debian, não posso simplesmente executar su como um usuário normal, é solicitado uma senha. Eu acho que a suposição é que, se alguém pode instalar su, pode substituir o arquivo shadow para alterar a senha?

— user974896

@ user974896: Bem não há outro lugar para um usuário não-sistema para colocá-lo de que ele pode ser executado, e o Android não tem mesmo passwdou shadowarquivos de qualquer maneira. Você precisa literalmente de root para colocar suem um local executável, e é por isso que os métodos de root envolvem uma exploração de escalação de privilégios ou entram em uma recuperação personalizada (onde todas as apostas estão basicamente desativadas).

— Eldarerathis

Sim. Essa é a resposta.

— Android Quesito

@ user974896: além de o / sdcard ser montado noexec, a chamada do sistema setuid só pode ser chamada quando o bit de permissão suid estiver definido no executável, e a chamada do sistema chown e chmod permitirá apenas que o root defina o bit setuid de um arquivo de propriedade do root (efetivamente, apenas o root pode criar um executável que possa ser executado com privilégios de root). Qualquer pessoa pode chamar su, mas, a menos que o chamador possa fazê-lo no banco de dados do Superuser (ou no Linux tradicional, no banco de dados passwd / shadow), a chamada não será bem-sucedida. Somente o aplicativo Superusuário (e processos privilegiados) podem modificar o banco de dados do Superusuário.

— Lie Ryan

@ user974896: Além do sistema de segurança normal no Android, no qual cada aplicativo da dalvik é executado como usuário, significa que aplicativos que apenas aplicativos da lista de desbloqueio do Superuser podem escalar para se tornar root sem aviso prévio, todos os outros serão recusados (se for na lista negra) ou fará com que o Superusuário solicite permissão ao usuário.

— Lie Ryan

Enraizamento envolve explorar a fraqueza, dependendo da versão do Android, portanto, " pule todos os obstáculos para fazer root no telefone "

É uma galinha e ovo!

Para explorar o root, você precisa de um daemon adb não seguro (ou seja, a capacidade de remontar /system) no aparelho e, para ter um adb não seguro, precisa do root! E também, você precisa de um gerenciador de inicialização desbloqueado.

Dê uma olhada em uma exploração chamada zergRush encontrada no github; a função de interesse é chamada do_fault()onde é feita uma tentativa de "quebrar" o quadro de pilha do volddaemon do, conectando-se ao canal de propriedade dele e causar travamento sobrescrevendo o ponteiro da pilha para apontar para uma cópia versão do shell da boomshqual é executado /data/local/tmp.

Depois de ler a fonte, você perceberá agora, por que copiar o subinário não é suficiente para ter o telefone "enraizado" e por que os aros devem ser saltados. E também, como o bit executável no nível do sistema de arquivos do cartão SD é bloqueado, então não é necessário ir lá - isso ocorre por razões óbvias! :)

— t0mm13b
fonte

Obrigado pelos links que os leremos mais tarde. Portanto, mesmo que o sdcard fosse chmodded 777 da fábrica, eu ainda não conseguiria me tornar root simplesmente baixando e executando?

— user974896

corrigir! Não vá! Não faz a menor diferença e, como a ROM instalada de fábrica terá essa proteção protegida, você precisará de root para conseguir isso chmod- com as permissões do cartão SD para fazer isso! :)

— t0mm13b

Bem, o que torna su tão especial se estiver em / system / xbin? Se você inserir o shell adb (ou executar um aplicativo como um usuário normal), será um usuário sem privilégios. Por que executar su quando está em / system / xbin faz com que você faça root em vez de executá-lo em nosso chmod 777 / sdcard?

— user974896

/system/xbiné o diretório em que os utilitários do busybox entram, e ... em um aparelho com root, emitir isso echo $PATHproduzirá / sbin: / vendor / bin: / system / sbin: / system / bin: / system / xbin <- observe! Está no caminho! Para ter isso aí, você precisa de raiz, portanto, uma série de situações de frango e ovos ...: D

— t0mm13b

Sim, eu sei que é para onde vai por padrão. O que quero dizer é o que há de tão especial em executá-lo lá. Por que executar ./su em / sdcard /, / data / ou qualquer diretório não raiz necessário não funcionaria, desde que a fábrica enviasse a ROM com o diretório chmodded em 777. O que quero dizer basicamente é a única coisa que impede o download e executando ./su é o fato de que os diretórios nos quais um usuário não root pode fazer isso não são executáveis ou há uma imagem maior.

— user974896