Visualizzazione stampabile
-
Non puoi svuotarlo dicevo per dire :P Comunque ho già provato ad applicare l'update del Droid, e le firme sono effettivamente diverse.
In realtà dal punto di vista di Motorola una ragione per averle diverse c'è, ovvero evitare che i Droid possano installare la versione con Motonav ecc e che noi possiamo installare quella con CarDock ecc. Se hanno fatto una distinzione così pesante immagino vogliano mantenerla.. Dal lato del Droid hanno già fallito, e appena esce l'aggiornamento per il nostro Milestone avranno fallito anche di qui ;)
-
Quote:
Originariamente inviato da
MartinodF
Non puoi svuotarlo dicevo per dire :P Comunque ho già provato ad applicare l'update del Droid, e le firme sono effettivamente diverse.
In realtà dal punto di vista di Motorola una ragione per averle diverse c'è, ovvero evitare che i Droid possano installare la versione con Motonav ecc e che noi possiamo installare quella con CarDock ecc. Se hanno fatto una distinzione così pesante immagino vogliano mantenerla.. Dal lato del Droid hanno già fallito, e appena esce l'aggiornamento per il nostro Milestone avranno fallito anche di qui ;)
Senza andare OT vorrei aggiungere che il droid e milestone hanno hardware differente.. basti pensare che uno è cdma e l'altro umts..
Comunque è pazzesco che cyanogen abbia fixato quella falla.. Non poteva farsi gli stracazzi suoi? Bho
Btw, io non sarei in grado di creare l'update.zip.. Non ho capito la procedura per nascondere il vecchio contenuto e mostrare solamente la parte di update dedicata a root.
Ho letto in internet il problema di verifica e guardato la patch di cyanogen.. Però non ho capito proprio come funziona.
-
Hanno hardware differente ma il sistema operativo di uno (almeno /system, non so se anche la boot image) è compatibile anche con l'altro. Se guardi in /system ci sono init_mapphone_umts.rc e init_mapphone_cdma.rc, appunto per Milestone il primo e Droid il secondo.
Cyanogen l'ha fixata perchè tanto ne erano a conoscenza tutti a quel punto, era solo questione di giorni che l'avrebbe fixata qualcun altro anche perchè c'era un solo carattere sbagliato nel codice.. e poi l'ha fatto per dimostrare a Google e a tutti gli sviluppatori che intende lavorare a favore di Android, pur personalizzandolo. L'ho trovata una mossa intelligente a mio modo di vedere.
Per creare lo zip moddato:
- prendi l'update fota (ho scritto sotto la procedura più semplice per procurarselo)
- prendi il file droid-superuser.zip che trovi su internet
- aggiungi il secondo in fondo al primo:
Windows: copy /b nomeupdatefota.zip+droid-superuser.zip update.zip
Linux: cat nomeupdatefota.zip droid-superuser.zip > update.zip - metti update.zip nella sd
- riavvia tenendo premuto il tasto camera, quando compare il triangolo con punto esclamativo premi volume su+camera e poi scegli apply sdcard:update.zip
(Non è farina del mio sacco, ho solo tradotto una delle mille spiegazioni che ci sono in giro, anche se il procedimento è veramente basilare)
Per prendere il file dell'update fota, una volta che comparirà l'opzione di aggiornare clicchi su sì, aspetti la fine del download del file, quando chiede di riavviare (o riavvia da solo) spegni il cellulare, prendi la sd la metti in un lettore esterno e ti trovi il file update.zip dentro.
Per quanto riguarda la patch invece, la spiegazione è abbastanza basilare. Ci provo:
codice:
int i;
for (i = 4; i < eocd_size-3; ++i) {
if (eocd[i] == 0x50 && eocd[i+1] == 0x4b &&
eocd[i+2] == 0x05 && eocd[i+1] == 0x06) {
// if the sequence $50 $4b $05 $06 appears anywhere after
// the real one, minzip will find the later (wrong) one,
// which could be exploitable. Fail verification if
// this sequence occurs anywhere after the real one.
LOGE("EOCD marker occurs after start of EOCD\n");
fclose(f);
return VERIFY_FAILURE;
}
}
Questo è il codice originale che conteneva il bug.
Lo scopo è sostanzialmente quello di scorrere tutto il file update.zip dopo la signature vera e cercare la sequenza di byte 0x504b0506, che indica la presenza di un secondo zip e quindi l'exploit. Chi ha scritto quel codice ha copiato la prima riga dell'if (riga 3) e l'ha reincollata sotto (riga 4), correggendo poi i valori per evitare di riscriverla.
Peccato che si sia dimenticato di cambiare una cosa, e cioè quello che ho evidenziato in rosso che dovrebbe essere i+3 (va in ordine, i, i+1, i+2, i+3) e non i+1 di nuovo come sopra.
Abbastanza basilare, ma è bastato per il root ;)
Se dovessi aver fatto errori è per l'ora tarda, perdonatemi!
-
La spiegazione è eccellente..
Avevo capito l'errore guardando il fix di cyanogen.. Ovviamente prima in nessun caso quell'if andava a verificarsi. Però non sapevo che cosa stesse a significare 0x504b0506..
E' troppo lol sta cosa :P
Ma dove hai trovato la spiegazione di come creare l'update.zip modificato? Ho cercato parecchio in giro su alldroid.com e droid-devs ma non ero riuscito a trovarlo..
-
AllDroid.org - View topic - How to Root your Droid<<<ONLY
Qui per esempio, nel primo post ;)
Software:Root Access - Droid-Devs
Qui c'è la spiegazione dettagliata di come funziona il concatenamento dei due zip
-
@MartinodF grazie mille, più tardi mi leggo tutto :) grande!
-
Quote:
Originariamente inviato da
MartinodF
Quando avevo cercato non c'era..
-
Quote:
Originariamente inviato da
Andrea
Quando avevo cercato non c'era..
Ho letto un po di cose.. Sbaglio o droid-superuser.zip è vuoto ? LOL :P Sto provando ad appendere adesso vediamo che succede.
EDIT: L'appending infatti mostra uno zip vuoto.. Mentre quando avevo aperto il primo zip del primo root del droid si vedeva chiaramente solamente la parte di root.
-
guardate cosa ho trovato nel mio file build.prop
ro.product.brand=MOTO_WIND
eppure non l ho acquistato in un centro wind
-
Me ne ero accorto anche io che nel mio c'era questo.. Tuttavia non è utile al rooting quindi plz non andiamo ot.