Uno sguardo alle complicazioni della radice di marshmallow e della verità

Mentre la polvere si deposita sul Versione Android 6.0, Gli utenti di Nexus a bizzeffe si stanno immergendo per OTA e Immagini di fabbricae prepararsi per l'ultima iterazione del sistema operativo Android.

Mentre, dall'esterno, Android 6.0 appare (almeno visivamente) notevolmente simile ad Android 5.0 e 5.1 (le versioni Lollipop), ci sono una serie di cambiamenti significativi sul dentro. Uno di loro potenzialmente lo ha fatto ramificazioni per la ROM personalizzata e le comunità root. Innanzitutto, un po’ di background. Se non sei interessato a questo, passa semplicemente a "Perché è importante".

Una caratteristica chiamata Verità

Il problema (è un problema se ti piace eseguire il root e modificare i dispositivi) deriva da qualcosa che ho sottolineato molto tempo fa, quando ha colpito per la prima volta AOSP: l'introduzione di dm-verity su Android. Verity è una funzionalità di sicurezza, originariamente presente in ChromeOS, progettata per fornire dispositivi informatici sicuri e affidabili, impedendo a software dannoso di modificare un dispositivo. Già in Android 4.4, Google annunciò Verity per Android, e poi tutto rimase in silenzio. Mentre ce ne sono stati alcuni

ricerca sull’uso della verità, per la maggior parte, le cose sono rimaste tranquille. Fino ad ora, ovviamente.

Con Android 6.0, Google ha iniziato a migliorare la sicurezza dei dispositivi. Uno dei requisiti fondamentali a tal fine è impedire che il software su un dispositivo venga modificato all'insaputa dell'utente, mentre molti qui su XDA danno per scontato il root, immagina che il dispositivo di un utente venga rootato a sua insaputa o consenso e che l'accesso root venga utilizzato per rubare i suoi dati dati. Per questo motivo Google ha iniziato ad implementare la verifica della partizione di sistema su alcuni dispositivi. Hanno anche recentemente aggiornato il loro pagine di supporto per coprire questo.

Cosa significa questo per gli utenti rooted?

Con la verità in atto, eventuali modifiche apportate alla partizione di sistema verranno rilevate all'avvio o all'accesso. Ti troverai quindi di fronte a uno degli errori visti sopra. Alcuni ti consentono di procedere e altri vogliono proteggerti impedendo l'avvio del dispositivo. Sono disponibili tre stati. Uno viene mostrato quando il bootloader è sbloccato, indicando che potresti essere a rischio finché non blocchi nuovamente il bootloader. Questo è il caso poiché un'immagine del kernel modificata può aggirare la verità, poiché il ramdisk del kernel contiene le chiavi utilizzate per verificare lo stato di un sistema.

Le cose sembrano piuttosto poco divertenti per gli utenti che aspirano al root su dispositivi bloccati.

Lo stato successivo viene mostrato (presumibilmente) quando verity è disabilitato o disattivato o non può essere controllato a causa di modifiche al ramdisk. Non posso esserne sicuro, a causa della mancanza di un Nexus 5X o 6P per indagare, ma il mio sospetto (basato sui messaggi) è che se carichi un'altra ROM, che poi inserisce il proprio kernel nel dispositivo, verrà visualizzata la pagina "sistema operativo diverso". apparire.

Lo stato finale è l'avviso rosso che indica che il dispositivo è danneggiato. Sospetto che ciò significhi che l'immagine contiene verità, ma la verifica non è riuscita a causa della modifica dell'immagine del sistema. Ancora una volta, non possiamo esserne sicuri senza l'hardware in mano, ma quell'errore sembra essere quello che vedrai se un dispositivo stock è stato modificato da un software dannoso.

Perché questo è importante?

Su Android M (6.0), root attualmente richiede modifiche all'immagine del kernel, oltre al filesystem. Ciò significa che, anche se ignoriamo la verità (come su un vecchio dispositivo Nexus come a Nesso7 2013), è necessaria una nuova immagine del kernel per aggirare le protezioni SELinux che impediscono il funzionamento dell'accesso root.

Se vuoi eseguire il root oggi, su Android Marshmallow, dovrai utilizzare un'immagine di avvio modificata.

Finora ce ne sono state kernel modificati per impostare SELinux in modalità permissiva, ma questa è una soluzione non ideale, poiché significa che non si ottengono i vantaggi in termini di sicurezza della protezione SELinux. E, dopo il Panico da palcoscenicosaga, presumo che tu possa vedere i vantaggi di SELinux e di altre protezioni contro gli exploit di sicurezza.

Sviluppatore senior riconosciuto XDA, Catena di fuoco, master of all-things root ha rilasciato un file versione aggiornata di SuperSU che mantiene SELinux in modalità di applicazione, ma richiede ancora una volta di apportare modifiche alla configurazione SELinux dell'immagine di avvio. Ciò significa che è necessario installare SuperSU e un'immagine di avvio modificata.

E va tutto bene, fino a quando i vettori statunitensi non entreranno nel mix. I bastioni della scelta anti-consumatore, i sostenitori come AT&T e Verizon, sono noti per divertirsi a bloccare i dispositivi, impedendo agli utenti di installare firmware personalizzato attraverso i blocchi del bootloader. In effetti, Verizon è particolarmente pessima nel non trasferire nemmeno gli aggiornamenti del firmware agli utenti, con il Sony Xperia Z3v non impostato per ricevere Marshmallow mentre il resto della gamma Z3 (e in effetti la gamma Z2) lo farà. Diamine, non hanno ancora nemmeno implementato Lollipop sul dispositivo, nonostante sia disponibile per un bel po' di tempo (novembre 2014) sul normale Z3.

Al posto di uno sblocco non ufficiale del bootloader (quelli sono abbastanza rari al giorno d'oggi, a parte i bootloader tecnici trapelati per alcuni dispositivi Samsung), sembra altamente improbabile che otterrai il root su Android 6.0 senza alcun intervento divino: la combinazione di dm-verity (per impedire l'avvio del tuo telefono con qualsiasi modifica al partizione di sistema) e il requisito per le modifiche di SELinux nel ramdisk (per consentire il funzionamento di root), sembrano destinati a rendere le cose piuttosto poco divertenti per gli utenti che aspirano a root di questi dispositivi bloccati.

AndroidPaga?

Infine, Android Pay. Probabilmente sembra del tutto estraneo al resto di questo articolo, ma in realtà è abbastanza rilevante. Android Pay si basa sul nuovo API SafetyNet all'interno del framework dei servizi proprietari di Google, progettato per fornire attestazioni sullo stato del dispositivo indicando se un dispositivo è rootato, o altrimenti modificato o in esecuzione in uno stato non approvato.

Mentre c'è un progetto guardando le risposte di spoofing a SafetyNet, attualmente richiede un plug-in Xposed e questo non sembra destinato a cambiare, dato come funziona. Xposed richiede root e apporta modifiche alla partizione di sistema. Ciò rende difficile eseguire questa operazione su un dispositivo bloccato con il bootloader. Anche allora, cose come questa stanno semplicemente entrando in un gioco del gatto e del topo con Google. Con SafetyNet, i dispositivi rooted (o addirittura i dispositivi modificati) sono visti come "non conformi a CTS", che è un eufemismo per i dispositivi modificati.

C'è molto altro scritto su SafetyNet in questo post del blog sullo smontaggio, ma sembra certamente che possiamo identificare alcune aree su cui Google vuole porre un freno. In primo luogo, a loro non piace root, Xposed e qualsiasi cosa modifichi la partizione di sistema. In secondo luogo, sembra che Google stia valutando la possibilità di rilevare gli utenti che hanno abilitato il blocco degli annunci: l'handshake SSL verifica pubads.g.doubleclick.net sicuramente mi suggerisci che Google voglia sapere se stai bloccando la pubblicità sul tuo dispositivo. Considerando che root è solitamente un prerequisito lì, ma che l'API VPN potrebbe potenzialmente essere utilizzata per farlo questo senza root, sembra che Google voglia almeno avere un'idea di chi (o quante persone) sta bloccando Annunci. Il blocco degli annunci pubblicitari è una questione di attualità data la spinta di Apple a supportarlo nel browser web (probabilmente per incoraggiare le persone a utilizzare di più le app, dove controllano l'esperienza e possono offrire annunci non bloccabili), e queste mosse lo sono interessante.

Conclusione

Se vuoi eseguire il root oggi, su Android Marshmallow (6.0), dovrai utilizzare un'immagine di avvio modificata. Anche se resta da vedere se ciò rimarrà vero a tempo indeterminato, sembra probabile che sarà così per un po' di tempo: le modifiche a SELinux rendono molto più difficile ottenere l'accesso root senza modificare l'immagine di avvio. E poiché la modifica dell'immagine di avvio richiede un bootloader sbloccato, ciò potrebbe porre fine a root (e Xposed e altre funzionalità root) sui dispositivi forniti con bootloader che non possono essere sbloccati dagli utenti finali. Anche Dm-verity sta facendo la sua comparsa e sembra essere abilitato in modalità enforcing sui nuovi dispositivi. Ciò renderà difficile modificare /system, anche se dovessi ottenere l'accesso root, senza avere nuovamente un bootloader sbloccato.

Questo cambia la tua visione dei dispositivi bloccati con il bootloader? Android ha raggiunto la fase in cui compreresti comunque un dispositivo bloccato con il bootloader se il tuo operatore ti offrisse un buon affare, o sei interessato solo ai dispositivi sbloccati? Quali app o funzionalità root ti mancherebbero con un bootloader bloccato?

Sentiti libero di condividere i tuoi pensieri nei commenti qui sotto.