Altro mio articolo che aggiungo alla mia collezione.
A seguito di quel che è accaduto a Nick di AndroidMod, il quale Galaxy SII si suppone sia morto per il così detto brickbug, decisi di scrivere questo speciale per far sì che questa bestia si possa conoscere un po' meglio e per vedere come fare in modo di non incapparci.
Innanzitutto non temete, nessuno poteva sapere (prima dell'estate scorsa) di questo bug, ha colto tutti quanti impreparati, Chainfire in primis (il maestro indiscusso del modding), per cui non rimproveratevi più di tanto se avete sbagliato qualcosa l'anno scorso; adesso, comunque c'è più informazione, è vostro obbligo morale nei confronti del vostro Galaxy, conoscere e prevenire. Veniamo al sodo.
Questo danno avverrà solo nel caso in cui monterete un firmware ICS 4.0.4 XWLPM o una leaked di Jelly Bean (ossia una ROM ufficiosa rilasciata da SamMobile) e solo e soltanto se utilizzerete kernel che si basano sull'update 7 (ossia i kernel, i quali sorgenti sono stati rilasciati da Samsung), gli unici compatibili con i firmware sopra citati. Il che significa che tutti coloro che hanno evitato questi firmware (ed i relativi kernel) sono al sicuro. Sono inoltre al sicuro chiunque utilizzi ROM AOSP, AOKP, CM etc, ossia tutte quelle ROM che si basano su sorgenti Android puro e non su base Samsung.
Essendo Chainfire colui che ha scoperto la procedura per rootare i nostri device, è stato lui l'artefice del kernel che ci fornisce i permessi di amministratore del nostro device, il CF-root per l'appunto, ma non per questo lui ne è il responsabile (visto che, come detto prima, nessuno poteva sapere).
Vediamo nel dettagli come agisce questo brickbug.
Specifichiamo che non è propriamente un bug, è una serie di sfortunate coincidenze che vanno a creare un danno più o meno riparabile. Eccole:
- La procedura di root col kernel successivo all'update 7 ha attivata la stringa MMC_CAP_ERASE che consente alla CWM di eseguire il danno.
- La CWM vi conferisce la possibilità di eseguire i wipe (i veri responsabili del danno).
- La ROM che gira sul kernel update 7 è per forza di cose una leaked JB sammy o una ICS ufficiale.
- Il chip (attivo solo sulla eMMC) che controlla e gestisce i blocchi di allocazione della memoria è difettoso e non fa quel che dovrebbe fare.
Il danno avviene quando questa serie di eventi è presente e quando attivate una procedura di cancellazione di massa dei dati, come ad esempio un wipe data. In quel momento la CWM si metterà in moto e richiamerà il comando MMC_CAP_ERASE che andrà a svegliare il bug nel chip controller della SD interna, bruciandola.
Ma non è l'unica maniera di distruggere il proprio telefono: difatti esiste un file chiamato update.binary allocato nella cartella META-INF che contiene al suo interno un set di istruzioni di wipe (cache, data o dalvik) richiamato all'insaputa di chi gestisce il telefono e può essere attivato anche durante l'installazione di un tema, di un flash innocente (tipo una mod o uno script) che porterà all'esatto identico danno (che è quello che presumo sia successo a Nick).
Centinaia (ed è una stima in ribasso) di device sono andati persi per colpa di questa serie concatenata di eventi, pochi sono quelli sopravvissuti.
Ma come evitare questo sfacelo? Innanzitutto, adesso che il tornado è finito da un po' e si conosce meglio l'entità del danno e come prevenirlo, è molto semplice. Ma se per caso montate su ancora una di quei firmware incriminati e volete sbarazzarvene perché volete rootare, i passi sono semplici: rootate con ODIN con un kernel sempre successivo all'update 7, ma stavolta reso sicuro dallo sviluppatore (ossia un kernel al quale è stata eliminata la riga di codice MMC_CAP_ERASE).
Ecco alcuni kernel:
- Siyah
- Dorimanx
- Phenomenal
- Speedwizz
- molti altri, ma questi sono i più famosi.
Oppure potete aggiornare tramite Kies o sempre ODIN alle ultime versioni di Jelly Bean (Samsung ha provveduto a rimuovere il danno almeno a livello software), per poi rootare con Philz, Jeboo o Dorimanx.
I kernel in questione sono stati compilati dai sorgenti, dove è stato possibile trovare la stringa responsabile della strage e cancellarla: difatti, come dice il grande Entropy512 di XDA, è stato introdotto un bug nel codice di un kernel potenzialmente dannoso.
Esiste la possibilità che alcuni device possano riprendersi, ma è molto remota e si può ottenere attraverso una procedura molto rischiosa, che intraprenderete a vostro rischio e pericolo:
- si preleva il file PIT da questo thread
- flashate il solo file PIT attraverso ODIN (ripartizionerà la vostra SD interna)
- togliete la batteria a flash finito e ritornate in modalità download
- flashate tramite ODIN un firmware non rootato e suddiviso nei 3 file (modem, code e CSC)
- entrate in recovery ed effettuate un wipe data
- accendete il device ed eseguire un format della sd interna
In questo modo isolerete la partizione danneggiata, perdendo 2 gigabyte di memoria (il blocco non viene conteggiato nel computo totale della memoria), ma almeno avrete il device funzionante. Se volete, potete mandare in assistenza il telefono lamentando questa perdita di memoria, all'utente cicciocant di Androidiani hanno sostituito la scheda madre gratuitamente con un nuovo chip non difettoso.
Se volete controllare se il vostro chip è difettoso o meno, utilizzate l'applicazione eMMC Brickbug Checker. È innocua e vi informa se siete al sicuro.
Se siete stati vittima di questo danno e non potete più usufruire della garanzia, su Androidiani, l'utente STEULM offre un servizio gratuito di riscrittura della partizione di boot in questo thread. È gratuito, ma per gentilezza e per ripagare chi offre il suo tempo per sistemare il vostro device, sarebbe cosa molto gentile offrirgli la birra che berrà durante il tempo speso nella riparazione del vostro device (nel thread ci sono tutte le indicazioni).
Nella speranza di non trovarci un mattone da 500€ in mano, vi auguro un buon modding!
Trovate la storia del brickbug in questo thread.
Alla prossima.
Nessun commento:
Posta un commento