Perché il binario su non può essere semplicemente copiato (risposta tecnica per favore)

Ho effettuato il root di diversi dispositivi Samsung e il "goal" sottostante, per così dire, sembra essere quello di ottenere il subinario /system/xbine installare Superuser.apk .

La mia domanda è: perché si deve saltare attraverso tutti questi cerchi per eseguire il root del telefono (installare il ripristino personalizzato e eseguire il flashing della ROM pre-root o sfruttare l'installazione corrente)? Non si può semplicemente scaricare un su precompilato, spostarlo sulla scheda SD ed eseguirlo tramite adb? La cosa che sembra rendere una ROM "pre-rooted" è che ha Superuser e il binario secondario nei rispettivi percorsi di sistema. Non vedo perché sia così importante che venga eseguito /system/xbin.

— user974896
fonte

Risposte:

Il binario secondario richiede sia l'esecuzione sia il bit di autorizzazione setuid impostato. Il primo è necessario che il file possa essere eseguito e il secondo è che viene eseguito automaticamente con i diritti del proprietario del file (imposta ID utente o setuid. In questo caso il proprietario è root. Leggi di più qui ).

I file sulla memoria esterna non hanno i bit di autorizzazione eseguibili e setuid impostati e non possono essere concessi senza i diritti di root. Si noti inoltre che la scheda SD è montata con il flag 'noexec' per impedire l'avvio generale dell'esecuzione:

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,[...]

Questo è fondamentalmente il motivo per cui non puoi semplicemente copiare susulla scheda SD e quindi eseguirlo per concederti il root.

— eldarerathis
fonte

Quindi questa è l'unica cosa che impedisce il rooting, il fatto che / sdcard non sia eseguibile e non puoi farlo? Una volta che su è nella posizione appropriata dove può essere eseguito il tuo eseguibile d'oro. Penserei che ci sarebbe un livello di sicurezza per impedire a qualcuno di eseguire semplicemente su. Sul mio server e debian box non posso semplicemente eseguire su come utente normale, mi viene richiesta una password. Suppongo che se si può installare su possono sovrascrivere il file shadow per cambiare la password?

— user974896

@ user974896: Beh, non c'è nessun altro posto per un utente non di sistema che può essere eseguito e Android non ha nemmeno file passwdo shadowcomunque. Hai letteralmente bisogno di root per mettere suin una posizione eseguibile, motivo per cui i metodi di rooting comportano un exploit di escalation di privilegi o entrano in un recupero personalizzato (dove tutte le scommesse sono sostanzialmente disattivate).

— eldarerathis,

Sì. Questa è la risposta

— Android Quesito

@ user974896: oltre a / sdcard che viene montato noexec, la chiamata di sistema setuid può essere chiamata solo quando il bit di autorizzazione suid è impostato nell'eseguibile e chown e chmod system call consentirà solo a root di impostare il bit setuid di un file di proprietà di root (in effetti, solo root può creare un eseguibile che può essere eseguito con i privilegi di root). Chiunque può chiamare su, ma a meno che al chiamante non sia permesso farlo nel database di Superuser (o in Linux tradizionale, nel database passwd / shadow), la chiamata non avrà esito positivo. Solo l'app Superuser (e i processi privilegiati) può modificare il database di Superuser.

— Sdraiati Ryan il

@ user974896: Questo, oltre al normale sistema di sicurezza in Android in cui ogni applicazione dalvik viene eseguita come proprio utente, significa che le applicazioni che solo l'applicazione nella whitelist di Superuser possono passare a root senza prompt, tutti gli altri verranno rifiutati (se è nella lista nera), o farà sì che Superuser richieda l'autorizzazione all'utente.

— Sdraiati Ryan il

Il rooting implica lo sfruttamento della debolezza a seconda della versione di Android, quindi " salta attraverso tutti i cerchi per eseguire il root del telefono "

È un pollo e uova!

Per sfruttare root, hai bisogno di un demone adb non protetto (cioè la capacità di rimontare /system) sul portatile, e per avere un adb non protetto, hai bisogno di root! E inoltre, è necessario un bootloader sbloccato.

Dai un'occhiata a un exploit chiamato zergRush trovato su github; la funzione di interesse viene chiamata nel caso in do_fault()cui si tenti di "spezzare" lo stack-frame del volddemone del '' '', connettendosi alla pipa di sua proprietà e causarne il crash sovrascrivendo il puntatore dello stack in modo che punti a una copia versione della shell da boomshcui parte /data/local/tmp.

Dopo aver letto la fonte, ora capirai perché la copia del file subinario non è sufficiente per "radicare" il portatile e perché i cerchi devono essere saltati. Inoltre, poiché il bit eseguibile a livello di file system per la scheda SD è bloccato, quindi non andare lì - questo è lì per ovvi motivi! :)

— t0mm13b
fonte

Grazie per i collegamenti li leggerò più avanti. Quindi, anche se la sdcard fosse stata selezionata dalla fabbrica 777, non avrei potuto diventare root semplicemente scaricandola ed eseguendola?

— user974896

corretta! No vai! Non fa la differenza e dal momento che la ROM installata in fabbrica avrà una protezione protetta, è necessario il root per ottenere quel chmod-ding le autorizzazioni della scheda SD per farlo! :)

— t0mm13b

Bene, cosa rende Su così speciale se è in / system / xbin? Se inserisci la shell adb (o esegui un'app come utente normale) sei un utente non privilegiato. Perché eseguire su quando è in / system / xbin ti rende root invece di eseguirlo nel nostro chmod 777 / sdcard teoricamente?

— user974896

/system/xbinè la directory in cui vanno le utility busybox, e ... in un portatile con root, emettendo questo echo $PATHprodurrà / sbin: / vendor / bin: / system / sbin: / system / bin: / system / xbin <- notatelo ! È nel percorso! Per avere questo dentro, hai bisogno di root, quindi molte situazioni di pollo e uova ...: D

— t0mm13b

Sì, lo so che è dove va di default. Quello che voglio dire è ciò che è così speciale di eseguirlo lì. Perché eseguire ./su in / sdcard /, / data / o qualsiasi directory non root richiesta non funzionerebbe supponendo che la factory abbia spedito la ROM con la directory selezionata a 777. Quello che intendo sostanzialmente è l'unica cosa che impedisce a uno di scaricare e in esecuzione ./su è il fatto che le directory in cui un utente non root può farlo non sono eseguibili o c'è un quadro più ampio.

— user974896