ATTENZIONE: RISCHIO DI BRICK con FIRMWARES ics 4.0.4 e leaked jelly bean 4.1.2

[Anna]

Esatto, se fosse implementato per errore anche in altri terminali android, li brikkerebbe ugualmente. E' per questo che mi fa pensare ad una semplice faglia software

leggi ciò che c'è scritto in prima pagina....

COS'E' il COSIDDETTO HARD BRICK BUG

Non è un bug propriamente detto, ma una fatale conseguenza, dovuta ad una combinazione altrettanto fatale: un kernel con un flag attivo nella gestione driver dell'mmc e dell'sdhc combinata ad una serie di microchip di memoria flash (la sd interna) che equipaggiano buona parte dei galaxy s2 in commercio, dotati di controller firmware difettoso.

L'entità del danno che ne deriva non è costante ed ha una tempestività randomica, non è un errore di programmazione o un semplice FC: a volte può semplicemente corrompersi una partizione di sistema (come è successo a Darham Maniar, lo sviluppatore del exDarkNight kernel) o altre volte può capitare di danneggiare irreparabilmente il device (come successo a steULM o altri) e in ogni caso il danno non mostra subito i denti, possono essere necesari giorni o minuti successivi allo scatenarsi dell'evento per far si che si presenti il bug nella peggiore delle sue forme.

I recenti kernel STOCK samsung derivati dall'update 7 (i codici opensource rilasciati dalla stessa samsung), gli unici ad assicurare la piena compatibilità con i firmware 4.0.4 ICS, hanno un "opzione" attivata esattamente nei moduli dei driver delle memorie interna (mmhc) ed esterna (sdhc) che consentono di eseguire da recovery (specialmente CWM) una cancellazione diciamo "pesante" dei blocchi di memoria allocati rispettivamente. Il firmware del controller del chip mmc (che è dove risiedono, tra le altre, le partizioni system, data e comunque tutto ciò che serve al device per effettuare il boot e quant'altro) non gestisce in maniera appropriata lo svolgimento delle operazioni, dando luogo ad un errore che risulta tanto più grave quanto più grossa è la quantità di dati da eliminare in una sola sessione (un wipe data ad esempio). Da precisare che l' MMC_CAP_ERASE è attivo sia su sd interna che esterna: IL DANNO lo subirà solo la prima, perchè la esterna non è dotata di alcun controller attivo e quindi di nessun firmware.

Nella peggiore delle ipotesi, in casi di brick, è necessaria la sostituzione della scheda madre: l'mmc non è una scheda sd così come la intendiamo comunemente, si tratta di un chip che è saldato alla scheda madre stessa.

QUALI CONDIZIONI SONO NECESSARIE PERCHE' SI VERIFICHI IL BUG

La condizione sfavorevole:

- Un kernel Stock basato su update 7, ad esempio quello che trovate nelle stock 4.0.4 XWLPM e a seguire

- Una recovery CWM

- Un chip difettoso

MA COSA C'ENTRA LA CWM RECOVERY

Il kernel pericoloso è la bomba e una recovery CWM è il detonatore. La recovery ClockWorkMod contiene una serie di istruzioni precaricate che servono per eseguire svariate operazioni, tra cui il wipe data. Il comando di wipe data, ad esempio, eseguito da recovery CWM è costituito da una serie di "format" di varie partizioni ed è proprio il comando format che richiama il bug in questione. Dovete sapere che comunque non è solo la recovery ad essere pericolosa: anche senza eseguire alcun wipe volontario ci si può trovare con un mattone di 500 euro in mano. La maggior parte delle custom rom possiede ad esempio una cartella meta-inf, all'interno della quale si trova parcheggiato un update.binary. Non è altro che un binario (eseguibile) contenente tutti i comandi basilari specifici per un device: operazioni di format, di mount ecc. ecc. le quali possono essere richiamate (senza che l'utente medio ne sia a conoscenza) in qualunque fase dell'installazione di una rom o un tema (anche il wipe cache è letale) generando gli stessi effetti di un wipe eseguito volontariamente da recovery.

COME POSSO EVITARE DI FAR DANNI (a prescindere che il chip sia difettoso o meno)

Ecco la procedura corretta e a seguire qualche spiegazione

- flash con Odin della rom stock 4.0.4, (non eseguite alcuna operazione di format o cancellazione dati personali successivamente all' installazione) e avviate normalmente

- flash sempre con Odin di un kernel, sempre update 7, ma reso SICURO dallo sviluppatore

Da questo memento in poi potrete fare tutti i wipe data (o simili) che volete in assoluta sicurezza.

I kernel compilati dagli sviluppatori (tutti i più recenti TRANNE il cfroot) sono stati resi sicuri grazie alla rimozione dell'opzione dai driver che costituiranno il kernel: in questo modo la catena di eventi viene interrotta in maniera inequivocabile prima che si possano ottenere danni.

MA QUALI SONO I KERNEL SICURI, NOOB CHE NON SEI ALTRO??!!

Quelli per i quali ad oggi mi risulta essere sicuri sono:

- Siyah kernel

- Phenomenal

- NEAK

- DM KERNEL

- SpeedMOD kernel

- Galaxian Kernel

- SpeedWizz kernel

- sicuramente altri lo sono, bisogna informarsi nel relativo thread informativo o chiedendo allo sviluppatore

Gli sviluppatori dei relativi kernel compilano lo zImage (kernel) direttamente dai sorgenti: sanno dove scovare il flag e lo disabilitano, solo successivamente compilano l'immagine del kernel. Vi consiglio di non usare il CF_Root: chainfire è solito realizzare il proprio kernel SENZA compilare dai sorgenti; decomprime il kernel della rom stock, aggiunge gli initramfs (CWM recovery, superuser, busybox applets, supporto alla bootanimation) e ricomprime il tutto. Il motivo della strage di devices è proprio da ricercarsi nel fatto che, a differenza di un codice sorgente non compilato (costituito da file di testo, script e driver), l'immagine di un kernel compilato è interpretabile solo usando un editor esadecimale e sapendo con esattezza cosa andare a cercare.

IMPORTANTE: Anche se nelle ultime versioni di CFroot è stata introdotta una nuova recovery inserendone una che non possiede i comandi di format (ma solo di cancellazione e sovrascrittura) sono stati riportati casi (molto recenti ad esempio quelli sulla Wanam Lite 12.3 XWLPU, equipaggiata proprio con CF root) di hard Brick irreversibile, molto probabilmente dovuti all'uso involontario di update.binary (non importa se sono eseguiti con recovery stock o CWM) su un kernel pericoloso come il CFroot.

IN BUONA SOSTANZA SIAMO AL SICURO OPPURE NO??!!

Cito le parole del noto sviluppatore Entropy512 di XDA:

"....annullando il flag dell' MMC_CAP_ERASE non abbiamo fatto altro che introdurre un bug nel codice di un kernel potenzialmente pericoloso...."

Ai posteri l'ardua sentenza!

[0raziel0]

Esatto, se fosse implementato per errore anche in altri terminali android, li brikkerebbe ugualmente. E' per questo che mi fa pensare ad una semplice faglia software

E no, perche alcuni chip sembrava che avessero bisogno di questa stringa per funzionare, facci caso tutti i telefoni della lista o montano un exynos o un vecchio qualcomn, in tutti questi chip, ma sopratutto negli exynos quella stringa serviva, poi per fortuna con ics l'hanno finalmente tolta ma non per tutti, la versione 4.0.4 in pratica e uscita solo in italia e solo per ka tim e causava problemi, con jb l'hanno definitivamente tolta, un problema software riguarda il sistema, qui si parla di hardware

[Mattyx89]

E no, perche alcuni chip sembrava che avessero bisogno di questa stringa per funzionare, facci caso tutti i telefoni della lista o montano un exynos o un vecchio qualcomn, in tutti questi chip, ma sopratutto negli exynos quella stringa serviva, poi per fortuna con ics l'hanno finalmente tolta ma non per tutti, la versione 4.0.4 in pratica e uscita solo in italia e solo per ka tim e causava problemi, con jb l'hanno definitivamente tolta, un problema software riguarda il sistema, qui si parla di hardware

Ah quindi alcuni telefoni la utilizzano per eseguire correttamente il format... Ad oggi quindi chi si ritrova con un Samsung Gs2 con chip ufficialmente sano?

[0raziel0]

Ah quindi alcuni telefoni la utilizzano per eseguire correttamente il format... Ad oggi quindi chi si ritrova con un Samsung Gs2 con chip ufficialmente sano?

Ti ha scritto tutto jac0, comunque dei chip sani ci sono, ma su questo theard non fa da sondaggio, se vuoi sapere chi ha un chip safe dovresti aprire un theard di sondaggio

[Mattyx89]

Ti ha scritto tutto jac0, comunque dei chip sani ci sono, ma su questo theard non fa da sondaggio, se vuoi sapere chi ha un chip safe dovresti aprire un theard di sondaggio

E posso farlo?

[0raziel0]

E posso farlo?

E perche no ? Hanno fatto un sondaggio su un chip del wifi farne uno su chi ha il chip safe

[fabiano88]

Io ho messo su con odin la stock ma non ricordo se era leaked oppure ufficiale come faccio a saperlo?
Se metto la cyano però questo problema non l'ho?

[marcangelo]

PDA :I9100XWLSD
PHONE:I9100XXLS8
CSC :I9100WINLS2
Build info : Thu Jan 31 14:30:29 KST 2013
Ho installato la Clock Word recovery v.5.5.3.2
Kernel 3.0.31 - 889555 dpi@DELL22#3 SMP PREEMPT Thu jan 13 14:48:54 KST 2013
La precedente è la situazione del mio device, considerato che ho continui blocchi nel device e riavvi improvvisi, volevo fare un reset totole di tutto.
Potete dirmi se rischio il brik del device.
Inoltre come faccio a capire se ho un kernel safe?

[Misterx86]

PDA :I9100XWLSD
PHONE:I9100XXLS8
CSC :I9100WINLS2
Build info : Thu Jan 31 14:30:29 KST 2013
Ho installato la Clock Word recovery v.5.5.3.2
Kernel 3.0.31 - 889555 dpi@DELL22#3 SMP PREEMPT Thu jan 13 14:48:54 KST 2013
La precedente è la situazione del mio device, considerato che ho continui blocchi nel device e riavvi improvvisi, volevo fare un reset totole di tutto.
Potete dirmi se rischio il brik del device.
Inoltre come faccio a capire se ho un kernel safe?

Leggi bene la prima pagina....il rischio brick si verifiva su firmware 4.0.4 e la leaked 4.1.2 tu hai una versione ufficiale di jb

[marcangelo]

Ok il mio dubbio era solo riconoscere la versione ufficiale... Quindi posso andare tranquillo giusto... Grazie amico

Inviato dal mio GT-I9100 usando Androidiani App