[ad#ad-cesco]
Come accennato sopra, Android 4.4 KitKat ha introdotto nuove funzionalità e ottimizzazioni, anche per quanto riguarda la sicurezza del dispositivo. Tra queste spicca dm-verity , una feature del kernel che si occupa di effettuare il check al boot sull’integrità dei blocchi del File System.
(I blocchi non sono altro che una sequenza di Byte o Bit a lunghezza fissa [dimensione del blocco]. Generalmente su dispositivi Flash la dimensione dei blocchi è di 4Kb. Per chiarire il concetto, un file di 1Mb verrà salvato fisicamente sulla memoria Flash in 250 blocchi da 4Kb).
Dm-verity , stando a quanto affermato sul sito ufficiale, serve e servirà per evitare a Rootkits e malware di effettuare modifiche sul File System. In sostanza, ogni volta che viene scritto un dato su disco, l’hash del blocco cambia, e se questo cambiamento non è autorizzato dal sistema, dm-verity al boot successivo rileverà il cambiamento, bloccando l’esecuzione.
il concetto alla base di DM-Verity
Dm-verity risiederà nel kernel. Quindi, se un software comprometterà il filesystem prima dell’avvio del kernel, questo bloccherà l’avvio del dispositivo.
Ad ora, i produttori utilizzano una chiave univoca per ogni dispositivo, scritta in qualche remoto angolo della memoria dello stesso, la quale non può più essere cambiata una volta che il dispositivo ha lasciato la fabbrica di produzione. Con questa chiave i produttori verificano l’integrità del primo livello del bootloader, il quale poi si occuperà della verifica dei livelli superiori.
Al momento però, la verifica viene eseguita solo sui bootloaders, tralasciando la verifica del kernel e successivamente del File System. Qui entra in gioco dm-verity, il quale si occupa della verifica in parallelo dell’hash di ogni blocco quando il sistema vi accede (per evitare eccessivi ritardi durante l’accesso alla memoria) e lo compara con “l’albero di hash” salvato precedentemente (immagine sopra) . se questi divergono, ogni blocco con hash diverso da quello precedentemente generato, verrà reso inaccessibile e di conseguenza verrà restituito un errore I/O, indicante che il blocco non risulta leggibile. In parole povere, il filesystem risulterà corrotto.
come opererà fisicamente dm-verity
- Generazione di un’immagine di sistema in formato EXT4
- Generazione dell’albero di hash
Per generare l’hash “root” l’immagine di sistema verrà divisa in blocchi da 4Kb (layer 0), ad ognuno dei quali verrà assegnato un hash SHA256. Il Layer 1 verrà composto unendo gli SHA256 precedenti e dividendo il risultante in blocchi da 4Kb, generando un’immagine di dimensione minore. Il procedimento verrà ripetuto sino a quando lo SHA256 potrà stare all’interno di un singolo blocco da 4k.
La dimensione dell’albero di hash varierà in base alla dimensione della partizione, ma mediamente al di sotto dei 30Mb. - Costruzione della tabella di mappatura
Questa tabella identifica il blocco(porzione) del file system analizzata durante la generazione dell’hash. Conterrà anche la posizione dell’albero di hash e l’offset/posizione del blocco di partenza . - Firma e convalida della tabella sopra generata
La tabella generata precedentemente verrà “firmata” con una chiave RSA-2048 posta nella partizione /boot. Generalmente queste chiavi sono private e generate in fase di produzione del dispositivo.
Il problema da punto di vista del rooting e del modding
Bene, vi ho scritto il funzionamento di dm-verity, ora è il momento di analizzare la situazione Modding/rooting applicata a questa nuova feature.
Ad eccezione dei dispositivi Nexus, che notoriamente sono sbloccabili con un semplice “fastboot oem unlock”, tutti gli altri dispositivi potrebbero, in futuro, non vedere più il root o custom roms. Perchè dico questo?? semplicemente perchè dm-verity intercetterà qualsiasi modifica eseguita sul file-system e di conseguenza qualsiasi file scritto o modificato senza autorizzazione. Va da se quindi che per dispositivi con bootloader bloccato e sbloccabili solo tramite una chiave univoca, trovare un exploit per avere l’accesso come amministratore risulterà decisamente piu’ difficile. Questo significa che, se il produttore deciderà di non rilasciare nessun tool di sblocco del bootloader, non sarà possibile trovare un modo per sbloccare il bootloader. E’ anche vero che dm-verity potrà essere disabilitato nel kernel o modificato in modo che legga una chiave RSA personale invece di quella dell’OEM, ma per fare tutto ciò è necessario avere un bootloader sbloccato per poter scrivere un nuovo kernel nella partizione /boot.
Concludo dicendo che dm-verity sicuramente è una nuova feature che aumenterà sensibilmente la sicurezza dei dispositivi per quanto riguarda i malware, ma potrebbe essere controproducente per tutto quel mondo che ruota intorno ai privilegi di root e alle rom custom.
A voi i commenti.
il prossimo os sarà android apple kut
Se android blocca ai suoi utenti la possibilità di smanettamento, da il via al suo declino.. bah
non so se ti sei accorto ma con jellybean non puoi più nememno attaccarci una pennina, non che fosse una qualche funzione utile ma a questo punto molto meglio iOS almeno si ha molto di più.
Sinceramente io con Jellybean 4.2.2 leggo tutt’ora le chiavette usb e posso collegarci via otg tastiere e mouse usb senza problemi… la questione è differente su dispositivi come il nexus 4 che non supportano la lettura di chiavette USB non tanto per problemi software, ma per un’incapacità hardware di alimentare tali dispositivi.
Ma cazzo non ci arrivate che è un “””troll”””?
Ci perdete pure tempo
Esistono smartphone con la porta USB standard?
Non credo, in genere si usa il cosiddetto adattatore OTG http://i916.photobucket.com/albums/ad3/billyjoe2882/cavootg-1.jpg
….ma dove le leggi ste cose sul postalmarket ??? Android Jelly Bean che non legge le pennine…ma per piacere.
Bella ca zzata
Al contrario, lo salva da morte sicura.
Ma… XDA può!!! Ci sarà sicuramente qualcuno che, presto o tardi, riuscirà a trovare un exploit in grado di ingannare questo efficiente sistema di sicurezza…
Sicuramente… ma a discapito di alcune features…
Vedremo più avanti cosa riusciranno a fare… Speriamo bene.
si ma ci riduciamo come il jb
in che senso?
che a ogni aggiornamento patchano, e comunque cambia la filosofia,google come apple chiude ufficialmente ai modder, che trovino o meno exploit, o forse google ritiene che rendendo tutti i moduli in apk esterni non ci sia più bisogno in futuro di moddare il sistema,del tipo non ti piace il dialer e ia gestione dei toggle? scarichi uno alternativo dallo store
Non cambia niente secondo me invece…per lo meno la gamma nexus di google sarà sempre libera, come da sua filosofia, lalimitazione é esterna all’ambiente google…poi per parere personale, se vuoi un esperienza android libera scegli nexus, lei Jon blocca bootloader e cose, se vai sugli a altri produttori e poi pretendi che il loro firmware, cioè quello modificato da loro, sia più libero non é certo colpa di google ma di chi lo personalizza..la filosofia di android non cambia..:) poi parlo un po da profano e ripeto sempre secondo la mia opinione..:)
Io tanto profano non sono ma la penso proprio come te. Anzi: ritengo che Google dovrebbe iniziare a valutare con attenzione certi orrori monumentali creati da gente come Samsung, etc… che rendono Android laggoso e persino talvolta buggoso :-) in qualunque banale operazione. IMHO chiaramente.
non so che device Samsung o altri possiedi o usi ma è sicuro che che parli a vanvera. Gli orrori monumentali erano i primi sistemi android non le personalizzazioni. Infatti è solo dalla 4.0.3 che android ha cominciato a smettere di laggare. Il primo android che ho preso non ricordo cosa montava ma era uno scempio non per la personalizzazione ma per il sistema in sé. Se adesso prendi un Samsung con un hardware del 1820 e fai un paragone con il nexus 4 è normale che ti esca dalla testa quello che hai scritto. Ma se prendi un note 2 per il paragone forse cambi idea. Il fatto che lo sviluppo dei vari sistemi android nel tempo ha inglobato di default alcune funzioni che esistevano solo come personalizzazione ti spiega perché Google lascia fare ai costruttori e ai modder/hacker/sviluppatori. Se questa gente non avesse avuto la possibilità di metterci le mani adesso non saremmo arrivati fin qui.
Lo penso anch’io, ci sono migliaia di hacker che lavorano con android quindi trovare un exploit non richiederà tanto tempo, anche perché android ha più falle della marina irachena
AHAHAHAHAHAH marina Irachena XD
dm-veriFy o dm-veriTy ?? oddio che confusione mi avete messo in testa con quest’articolo ahahah
Ma perché scrivete giusto per scrivere? Hanno scritto 1 volta Verify e 13 volte Verity. Ancora confuso?…
Ma perché TU scrivi giusto per scrivere?
La funzione si chiama dm-verify, ecco perché scrivo io
E allora non fai ridere comunque, fai notare l’errore e basta. Trollate dalla mattina alla sera.
Ma chi sta “trollando” (che termine orribile)…sei tu che sei paranoico…datti na calmata che niente ho detto
Beh invece di essere costruttivo scrivete ad cazzum. Ma ok scusami :D fai pure :)
Secondo me è un bene che aumentino la sicurezza del sistema. Certo dal mio canto scarterò tutti i device che non permettono lo sblocco del bootloader.
Beh, un po’ li capisco: se vogliono che la gente cominci a comprare la linea Nexus per poter giocare con i telefoni e per avere sempre (o quasi, vero Gnex ?) gli aggiornamenti in tempo quasi reale, qualcosa che invogli a farlo devono trovarla.
Magari invece è una cosa fatta fondamentalmente per sicurezza e che ha come rovescio della medaglia questa cosa che a Google va anche bene …
Boh, io tanto compro solo roba nexus, quindi … :)
[…] (…)Continua a leggere Android 4.4 KitKat: Google prende di mira gli sviluppatori di Custom ROMs? su And… […]
amen
per ora da quello che so è disabilitata
ma si.. figuriamoci.. sta in ogni ljvecd cd di Linux.. è un controllo che si f per vedere che l immagine sia integra.. DA mo che esiste nei kernel Linux… ma poi questi come chainfire, outlet, xpoldwild, Francisco franco etc.. so grandi developers nella vita.. figuriamoci se una cosa del genere li bloccherebbe.. haha XD
ahahahahahahahahaha
Vai Enrico, ti voglio bello cattivo. Se non ci riescono, o lo fai tu, o lo apriamo in due, e ci sbattiamo dentro du paia di fette di mortazza.
siete potenti allora oh… :D bella ragazzi!
io credo non ti sia ben chiaro il concetto di dm-verity.
1 – i dispositivi Nexus sono esenti da questi problemi, semplicemente perchè una volta sbloccato il bootloader con “fastboot oem unlock” hai accesso completo in lettura e scrittura a TUTTE le partizioni del dispositivo.
2 – il problema si presenta su dispositivi non nexus, quindi tipo S4/One/pincopallino, i quali sono soggetti alle regole del produttore. Se il produttore decide di non rendere sbloccabili i bootloader non c’e’ santo che tenga. Ogni tool per il root sfrutta un exploit per installare i binari “su”. Se dm-verity è abilitato di default e quindi effettua il check sui blocchi quando il sistema vi accedere, va di per se, che se questo tool rileva un cambiamento “non autorizzato”, automaticamente il file system risulterà corrotto e l’unica soluzione sarà il format del dispositivo per “rigenerare” il file system.
Non sarà impossibile trovare un modo, ma ci vorrà molto molto più tempo, o addirittura non si riuscirà a trovare un modo ( un esempio?? l’S-OFF per One-X: anni che ci lavorano e ancora non c’e’ un modo per averlo)
Leggere bene l’articolo e comprenderlo prima di rispondere forse è meglio…
Grande. Hai spiegato magnificamente.
Ma sul serio non sono riusciti per il One-X? C’era tanta community dietro, no?
io avevo il one x e non sono mai riuscito ad ottenere l’s-off, e a oggi non c’è un metodo…una cosa veramente triste…anche se alla fine non è una grande seccatura, l’unica cosa è che si può flashare solo la partizione di system tramite recovery, tutte le altre vanno flashate dal pc (boot, recovery, bootloader)…
Ma a quanto ho capito il problema non sussiste nel caso dei nexus, sbloccabili di fabbrica, ma per gli altri telefoni…pero potrei aver capito male quindi mi scuso anticipatamente..
hai capito bene ;)
e fidati, riusciremo a fare benzina maledizione!
io piscio sopra tua mmam
… non mi abbasso certamente al tuo livello da buzzurro e ignorante rispondendoti a tono -_-‘
Tranquillo enri… Oggi mancava la risposta dell’idiota di turno… Per fortuna c’era lui… Almeno oggi ha vinto questo fantastico e ambitissimo premio!
purtroppo il mondo è pieno di idioti come lui XD ;)
piscia sopra anche a tua..
ahahahahaahahahahahahaah Enricooo
se android permette lo screen recording direttamente dal telefono per me va bene.
tanto il root e le modifiche per me servono principalmente per questo
bisogna intervenire su qualcosa e trovare un compromesso
Io ho un Nexus 4 (a riparare). Sinceramente poco mi importa degli altri device (scusate l’egoismo ma se avessi scritto il contrario sarei risultato, a me stesso, ipocrita).
E sticazzi???
Emiliano basta grappa
quindi sarà impossibile effettuare il dual screen (dividere lo schermo con due app) su nexus 5 oppure si? o con questa limitazione addio certi tipi di implementazione?
Basta non acquistare più telefoni bloccati o buttarsi sui nexus anche se non mi risulta chiaro il perché google crei un sistema di sicurezza che poi non utilizzerà sui propri dispositivi nexus e che invece finiranno nelle braccia della concorrenza…
A parte questo, il rovescio della medaglia é che ci sarà maggiore stabilità, almeno a livello sistema operativo, ma a prescindere questo può anche generare guai in termini di assistenza…
perché android fa cacare in tutti i telefoni/tablet tranne nei nexus, fino ad ora c’erano le custom rom per risolvere le non poche magagne ma ora…..
spe frena.. io è da HTC One S che non sento + l’esigenza di montare custom rom su un HTC
ma no, ma no…almeno non per tutti i dispositivi!
>android è open source, quindi tutti posso prendere questi dati
>dm-verity blocca qualsiasi tentativo di modifica
>>aosp un corno, lo dovranno chiamare acsp
Da possessore di s plus non potrò mai vedere il kitkat sul mio device?
Google deludi.
Il bootloader nell’s plus è sbloccabile quindi puoi cambiare kernel e di conseguenza installare tutte le custom rom che ti pare.
il problema si pone solo con telefoni che escono di fabbrica con la 4.4 o che sono stati aggiornati a tale versione (a patto che sto dm-verity sia stato anche attivato). ovvio che in una custom basata su 4.4 sarà completamente falciato via, ma se non hai la possibilità di flasharla sulla tua 4.4 originale…
comunque è probabile che qualcosa si inventi google stessa, dopo tutto un SO modificato non è paragonabile ad un’app maligna…di rom virus ancora non ne ho sentito parlare :D
[…] (…)Continua a leggere Android 4.4 KitKat: Google prende di mira gli sviluppatori di Custom ROMs? su And… […]
Basta modificare le sorgenti del kernel e rimuovere questa funzione
Il bootloader nei telefoni attuali è sbloccabile quindi si può cambiare kernel e di conseguenza installare tutte le custom rom che ci pare. Il problema insorgerebbe con i dispositivi futuri se non viene rilasciato dal produttore un toolkit per sbloccare appunto il bootloader (vedi Motorola con il suo secondo tablet di cui mi sfugge il nome).
Per gli attuali dispositivi e per tutti quelli che non Monteranno KK stock il problema non sussisterà.
Google ha fatto questo per rendere più sicuri i dispositivi infatti nei nexus permette il modding come con il nexus 5.
Se poi gli altri produttori son pezzi di sterco e non permettono lo sblocco del bootloader non è colpa di Google ma di quei maledetti (non so come mai ma ho già in mente qualcuno che farà così, e credo che possa immaginare chiunque chi è)
Perfortuna quella volta ho comprato un Nexus 7 ;)
Come si dice.. Se riescono a decriptare codici cifrati militari.. Vi pare che non riescono a scavalcare un semplice check del kernel…
Ma possibile che a una settimana dall’uscita di kk 4.4 non sia ancora partito il rollout per gli altri Nexus… -.- ‘
se vuoi te la rollo io la canna ;)
E già, son problemi…
E già, son problemi…
secondo me è controproducente bloccare cosi il kernel
per diversi motivi:
1) con le custom rom le case le usano per indagini di mercato non di rado poi implementano cose “prese da esse”
2)le custom rom molte volte debuggano i problemi delle rom stock
3)nel caso di danni al device con custom la casa è libera da garanzia quindi ;-)
secondo metteranno il dm-verity ufficialmente e poi ufficiosamente uscirà a qualche parte il codice per lo sblocco
Bravi. Ottimo articolo
Fosse pure ora che tolgano quelle app nello store che richiede i permessi di root e trovino il modo di fare le stesse cose senza.
Veramente esistono app nello store di Google che chiedono (ed ottengono) i permessi di root? Se è vero mi viene veramente da ridere!
Ovvio che ti venga da ridere…….
Ovvio si: come si fa a permettere la pubblicazione di app che possono reclamare i privilegi di root in uno store senza alcun controllo preventivo? È ovvio che a Google non è mai interessato un fico secco la sicurezza dei suoi utenti.
Ovvio.
Tu non comprare mai uno smartphone google o android. Mi raccomando. In quel mondo ci sono un sacco di brutte app e anche tantissime brutte persone che prendono sempre in giro persone sveglie come te.
L’unico vantaggio è che sicuramente non avremo malware sul nostro smartphone…a discapito della libertà
Hai detto bene, non si possono avere entrambe le cose.
Certo che si possono avere entrambe le cose, bisognerebbe evitare di dare uno smartphone in mano a gente che ancora oggi per fare 2+2 usa i regoli. E’ la sempiterna stupidità, ignoranza e boccaloneria dell’utente medio che costringe i brand, viste le critiche subite, a dover usare la sferza. Il problema è che non c’è più selezione naturale e a farne le spese è l’utente attento che virus su android non ne ha mai visti perchè non installa porcate prese in giro.
Quindi in Google Play ci sono le “porcate”?
In effetti io moddo come un matto e non so cosa sia un virus
Ah perché il virus ti mette il cartello “ciao, sono il virus”?
C’è oltre 1 milione di malware per Android, difficile non venir beccati. Del resto se il problema non fosse più che reale Android non sarebbe corsa ai ripari, e nemmeno Samsung.
[…] (…)Continua a leggere Android 4.4 KitKat: Google prende di mira gli sviluppatori di Custom ROMs? su And… […]
Se fosse alla fine realmente così, sarebbe come darsi la zappa sui piedi. La forza di Android è la possibilità di modding. Se fosse un sistema chiuso allora tanto vale comprare Ios, bada o qualunque altro. Per me sarebbe un suicidio.
E alla debolezza di Android non ci pensi?
Certo che mi preoccupo, ma tengo un antivirus, e comunque non sono disposto a rinunciare al modding in nessun caso. …
Un antivirus? E dimmi, come farebbe un antivirus che gira in sandbox a svolgere il suo compito?
quale compito? vi hanno fatto il lavaggio del cervello con sti antivirus come con i pc.In realtà stanno creando un mercato di stupidate che frutterà soldi. E tutti giu a installare antivirus….
La conclusione è nexus per tutti!!!!!!!!!!!!!!!!!
la soluzione c’è…basta non aggiornare e attendere le rom cucinate su base 4.4..proprio come ho fatto per il 4.3 sul mio s4! Fuck knox e sto dm-verity!
il nexus 5 è stato rootato a poche ore dal lancio e si vedono rom 4.4 ovunque…..
questo è per evitare la maledizione dello sblocco del telefono…
ricordate la prima volta che avete sbloccato il vostro telefono? io ne ho fatti davvero tanti e ogni volta va allo stesso modo: NON SI è MAI SODDISFATTI
sia perchè le rom stock sono sempre meglio ottimizzate sia perchè maggiore è il modding, maggiore saranno i bug, rallentamenti ecc ecc…
questo porta le persone a pensare che terminali come un one x o un xperia p non siano buoni perchè la cm10.2 lagga, facendo perdere valore allo smartphone e al produttore, quando invece sono telefoni ottimi e siamo stati noi con queste procedure a “rovinarli” perchè vogliamo sempre di più
tengo a precisare che mi va benissimo tutto quello che accade, e che i bug sono le fondamenta della community di android, perchè se non ci fossero tutto sarebbe davvero noioso, ma cerchiamo di metterci dalla parte dei produttori che vedono il loro marchio svalutato perchè noi non possiamo fare a meno di smanettare…e capisco questa decisione