Melde dich an, um diesem Inhalt zu folgen  
Folgen diesem Inhalt 0

Hardbrick Bug

204 Beiträge in diesem Thema

Geschrieben (bearbeitet)

Da ich hier zu dem Thema noch nichts gefunden habe, habe ich einen Sammelthread zu dieser Problematik erstellt.

Was ist der Hardbrick Bug?

Der Hardbrick Bug mag einigen Usern vom Galaxy Note bekannt sein.

Hat man dort bestimmte, geleakte Beta-Firmwares geflasht, konnte das Gerät komplett unbrauchbar gemacht werden. Das hängt mit einem fehlerhaften eMMC-Chip zusammen, welcher anscheinend auch im Galaxy S2 verbaut ist.

Sollte man bei bestimmten Kernels (bekannt ist z.B. Siyah 3.1rc6) einen Factory Reset durchführen, kann das Device irreparabel beschädigt werden, wobei JTAG hier auch nichts mehr hilft. Dies passiert möglicherweise auch bei einer (meist dreiteiligen) Firmware, welche ein data-Image enthält. Odin hört dann bei "data.img" einfach auf zu flashen.

Das hängt aber weder mit dem Kernel, noch mit Odin zusammen, sondern wirklich nur mit der Hardware. Es ist zwar möglich diesen Bug zu umgehen, jedoch kann dieser nicht gefixt werden.

Bin ich betroffen?

Ob ihr betroffen seid, könnt ihr mit Chainfire's "Got Brickbug ?"-App herausfinden.

Was kann ich tun?

Bisher heißt es, dass alle GT-I9100 ICS Leaks und Releases sicher sind (Edit: I9100XXLQ5 ist NICHT sicher!!!). Samsung arbeitet derzeit an einem "Fix", welcher den Hardbrick verhindern soll, und wird demnächst neue Kernel Sources veröffentlichen.

Patches will be out in form of new official ROMs and also sourcecode releases after testing, which might take some time.

Was den Brick durch einen Factory-Reset betrifft, sind nur Recovery-Builds sicher, welche auf Gingerbread basieren. Fragt also bei eurem Kernel-Dev nach, was er für ein Recovery-Build benutzt (bisher heißt es, dass z.B. alle Siyah Kernels, bis auf 3.1rc6, sicher sind, des Weiteren sollen der CM9- und CM10-Kernel auch sicher sein).

Um ganz sicher zu gehen, immer einen Stock Kernel zum Wipen benutzen (Edit: NICHT den von I9100XXLQ5!!!).

Fazit

Solltest du dein Gerät wipen wollen und bist laut "Got Brickbug" betroffen, musst du einen offiziellen Samsung Kernel, welcher auf Android 4.0.3 basiert, benutzen oder anders formuliert: jeden Kernel einer Stock Firmware vor I9100XXLQ5.

Außerdem kannst du den CM9/10 Kernel benutzen, sowie jeden Siyah Kernel außer v3.1rc6, der SpeedMod Kernel soll laut Entwickler auch sicher sein.

Wenn du einen anderen Kernel verwendest, solltest du im Thread unbedingt nachlesen, ob der Kernel sicher ist. Der Dev schreibt dann etwas wie "Kernel safe" "Brickbug fixed" oder "MMC_CAP_ERASE disabled", also unbedingt darauf achten oder bei Unklarheiten direkt nachfragen.

Bist du immer noch ein Nutzer von Gingerbread, brauchst du dir überhaupt keine Sorgen machen und kannst jeden (Gingerbreak-)Kernel verwenden.

Bei Odin Flashes, solltest du, wie bereits erwähnt, die tar-Datei entpacken und nachschauen, ob eine data.img-Datei vorhanden ist. Sollte dies der Fall sein, muss diese gelöscht und die übrigen Dateien wieder zu einer tar-Datei verpackt werden. Achtung: Mit 7zip funktioniert das nicht, sondern ausschließlich mit IZArc, einem Linux-Emulator oder in Linux direkt mit

tar cvf PDA.tar *

(hierbei dürfen sich ausschließlich die entpackten Dateien im entsprechenden Ordner befinden).

Danach muss unbedingt manuell mit einem sicheren Kernel gewiped werden.

Sollte irgendetwas nicht klar sein, schicke mir bitte keine PN, sondern poste im Thread, damit die anderen User auch etwas davon haben.

Mehr Infos gibt es in diesem Post: http://forum.xda-developers.com/showpost.php?p=27074278&postcount=69

bearbeitet von UltraPower
8 Personen gefällt das

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben

So, dann fang ich mal an. Bin wohl der erste geschädigte.......:bang:

post-146578-14356888690686_thumb.png

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben

Schließe Mich DONHUGO an genau das Gleiche sagt mein Handy auch :) :)

Lg

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben

dito, ist bei mir auch :P

1 Person gefällt das

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben

Na da bin ich doch dabei :biggrin:

Selben Anzeigen wie beim Don

1 Person gefällt das

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben

D.h., wenn ihr wipen wollt, solltet ihr, um sicher zu gehen, davor einen Stock Kernel flashen.

Wirklich betroffen seid ihr aber nur, wenn ihr ICS benutzt.

Außerdem solltet ihr über Odin keine dreiteiligen ICS-Firmwares flashen oder zumindest vorher die data.img-Datei daraus entfernen.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben

bin auch mit im "bunde".....

sieht so aus das wohl alle betroffen sind (europa). ist ja wohl jetzt erst wegen ics entdeckt worden wenn ich das richtig verstanden habe.

lwiss

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben

D.h., wenn ihr wipen wollt, solltet ihr, um sicher zu gehen, davor einen Stock Kernel flashen.

Wirklich betroffen seid ihr aber nur, wenn ihr ICS benutzt.

Außerdem solltet ihr über Odin keine dreiteiligen ICS-Firmwares flashen oder zumindest vorher die data.img-Datei daraus entfernen.

Also gewipet hab ich schon mehrfach...ohne Stock...allerdings noch keine 3teilige druff geklöppelt.:huh:

Mal sehen wann der erste ohne den Bug sich hier meldet :icon_wink

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben

ist ja wohl jetzt erst wegen ics entdeckt worden wenn ich das richtig verstanden habe.

So ähnlich. Auf dem Gerät gibt es eine bestimmte Bibliothek, die erst in ICS verwendet wurde, in Gingerbread aber schon vorhanden war. Die Kernel Devs können den Bug also ganz leicht "fixen" bzw umgehen. Das Problem bleibt aber weiterhin bestehen, da es sich um einen Hardware-Fehler handelt.

allerdings noch keine 3teilige druff geklöppelt.:huh:

Sollte man auch lieber nicht ausprobieren ;)

Vor dem flashen also immer schauen, ob eine data.img-Datei vorhanden ist und wenn ja, entfernen.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben

Sollte man auch lieber nicht ausprobieren ;)

Vor dem flashen also immer schauen, ob eine data.img-Datei vorhanden ist und wenn ja, entfernen.

Dazu ne rein technische Frage an den Koch in dir :biggrin:

Bleibt die FW dann voll flashbar,auch wenn die data.img entfernt wird?

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben

Glaube Das Problem ist gar nicht mehr So Gravierend bzw ist alles wieder relativ sicher Geworden.

Schaut mal hier:

http://forum.xda-developers.com/showthread.php?t=1693704&page=7

Besonderst der Post 69 von Entropy512

Lg

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben

Dazu ne rein technische Frage an den Koch in dir :biggrin:

Bleibt die FW dann voll flashbar,auch wenn die data.img entfernt wird?

Ja, natürlich. Die data.img-Datei in einer dreiteiligen Firmware ist im Prinzip "leer", was den Wipe erst auslöst.

Glaube Das Problem ist gar nicht mehr So Gravierend bzw ist alles wieder relativ sicher Geworden.

Man muss eben bei Custom Recoverys aufpassen und sollte keine Data-Partitionen via Odin flashen, dann ist man auf der sicheren Seite.

2 Personen gefällt das

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben

Danke für die Antwort. Zum Glück nehme ich Odin nicht :)

Könntest du das Custom Recoverys Vielleicht noch ein wenig genauer beschreiben bzw definieren für die anderen User. Wäre Total nett :)

Weil denke mal dein Thread wird sehr oft angeschaut.

LG

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben (bearbeitet)

Könntest du das Custom Recoverys Vielleicht noch ein wenig genauer beschreiben bzw definieren für die anderen User.

Wie ich im OP schon geschrieben habe, sind Custom Recoverys betroffen, die auf ICS basieren, jedoch nicht alle. Leider habe ich noch keine Liste von den "gefährlichen" gefunden. Bisher ist mir nur bekannt, dass das im Siyah Kernel enthaltene Recovery (bis auf das in 3.1rc6) weitgehend sicher ist, was die meisten User schon man beruhigen sollte, da das der beliebteste Kernel ist.

Sollte man einen anderen Kernel benutzen muss man im entsprechenden Thread auf XDA nachfragen.

Um ganz sicher zu gehen sollte man immer einen Stock Kernel zum Wipen benutzen. Das Flashen dauert schließlich nicht lange und ist immer noch besser als einen 500€ teuren Briefbeschwerer zu bekommen, der nicht mehr zu retten ist (auch nicht mehr durch JTAG!!!).

Edit: Das Recovery in CM9 soll auch sicher sein.

bearbeitet von UltraPower

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben

Costum Recovery ist nicht weiter als CWM. Da brauch man eigentlich nichts weiter erklären...;) Ist in jedem Costum Kernel enthalten.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben (bearbeitet)

Ja wir wissen das Don Hugo aber nicht alle User (Was auch nicht schlimm ist) und deswegen ist es schön wenn es näher beschrieben ist.

Weil manche User sind Froh wenn sie eine Custom Rom geflasht kriegen.

Lg

Edit:

Update4 Source-Basis (Google Pushes Source Code Of Android 4.0.4 (IMM76D) ist der Fix/Patch von Samsung man sollte also darauf achten das der Kernel darauf basiert.

Und der Siyah Kernel wurde mit dem Update auf den v3.2.5.2 sicher gemacht :)

Zitat der Dev:

SiyahKernel v3.2.5.2

Posted on May 23, 2012

Changelog:

Patch the firmware of certain Samsung emmc parts to fix a bug in the wear leveling code

Quelle: http://www.gokhanmoral.com/

Die Unsicheren Kernel sind also die zum bsp. auf dem Siyah oder anderen basieren. Und die weniger oft geupdatet werden und auf einem älteren Release basieren.

bearbeitet von chris264

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben

Hab jetzt auch mal geschaut und mich hat es Gott sei Dank dieses Mal nicht getroffen. In der Regel ziehe ich sowas auch immer magisch an!

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben

Der neue Kernel Dorimanx 3.3

WE SAFE (MMC_CAP_ERASE not present) in kernel MMC Code!

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben

Mein Gott auch von mir, wie viel Pech kann ein Mensch allein haben... ich habe selbstverständlich den emmc, der eine potenzielle gefahr birgt!

Naja, die Kehrseite der Medaille: Zum Glück ist bis jetzt nichts passiert!

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Geschrieben

Naja ich hab den Siyah 3.3.1 drauf und mir sagt die App auch dass ich gefährdet bin. :( aber naja wenn der trotzdem sicher is dann is das ja gut :D

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Geht einfach!


Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.


Jetzt anmelden
Melde dich an, um diesem Inhalt zu folgen  
Folgen diesem Inhalt 0