Wir haben fortlaufend darüber berichtet Samsung-Hard-Brick-Bug Das betrifft eine große Anzahl von Benutzern. Für diejenigen, die es nicht kennen: Der Hard-Brick-Bug verursacht vollständige und irreparable Schäden am eMMC-Speichergerät. Es entstand, als die ersten Leaks zu ICS auf verschiedenen Samsung-Geräten veröffentlicht wurden, und seitdem stellen sie ein Problem dar.
Eine Möglichkeit für Benutzer, den Überblick darüber zu behalten, ob sie den Brick-Bug haben, ist Got Brickbug-Anwendung von Chainfire, die bestimmt, ob Sie über gute oder schlechte Hardware verfügen. Es gibt eine andere Möglichkeit, festzustellen, ob Sie den Brick-Bug haben, wenn Sie ihn haben Samsung Galaxy S II. XDA-Senior-Mitglied Wolframzwanzig hat ein Skript veröffentlicht, das dabei hilft, weiter zu bestimmen, ob Benutzer den Brick-Bug haben oder nicht. Laut XDA Elite Recognized Developer Entropie512, der weiterhin an vorderster Front im Kampf gegen Brick Bug steht, funktioniert anders als die App von Chainfire. Entropy512 besagt:
Es erkennt eine andere Komponente des Brickbugs – Chainfire erkennt fehlerhafte Chips, wodurch einige Kernel erkannt werden, die gefährliche Befehle bis hin zu Chops zulassen.
Allerdings ist nicht alles gut. Aufgrund der Art und Weise, wie es erkennt, besteht eine sehr gute Wahrscheinlichkeit, dass es zu Fehlalarmen kommen kann Und falsche Negative. Auch hier erklärt Entropy512:
Es wird wahrscheinlich einige falsch-positive und falsch-negative Ergebnisse liefern, da kompilierte Binärdateien und nicht die Quelle überprüft werden. Wenn sich in der Nähe der Stelle, an der MMC_CAP_ERASE gesetzt ist, etwas ändert, kann dies beispielsweise zu falsch-negativen Ergebnissen führen.
Obwohl es sich also um ein sehr hilfreiches Tool handelt, ist es unklug, Ihr Gerät ausschließlich aufgrund der Angaben in dieser Anwendung als sicher oder gefährlich zu deklarieren. Da es in der Lage ist, falsch-positive und falsch-negative Ergebnisse zu liefern, könnte es selbst dann sauber sein, wenn Sie den Brick-Bug haben. Es wird am besten zusammen mit der Chainfire-Anwendung (oben verlinkt) verwendet, um dies noch einmal zu überprüfen. Wenn Sie sich nach beiden Tests immer noch nicht sicher sind und ein so gefährlicher Fehler vorliegt, sollten Sie dies wahrscheinlich tun. Dann ist es viel besser, einfach so zu tun, als ob Sie den Brick-Bug hätten. Sicher ist sicher.
Im zweiten Teil von Tungstwentys Thread wird erläutert, wie Sie das Problem beheben können, wenn es den Anschein hat, dass Sie es haben. Während dies funktionieren kann, lässt Entropy512 wieder einmal Worte der Weisheit fallen:
Wenn der Patch fehlschlägt, könnte dies dazu führen, dass Benutzer denken, sie seien sicher, obwohl dies nicht der Fall ist. Anstatt das Codesegment zu patchen, um einen Kernel sicher zu machen, kann es sein, dass nur ein anderer Teil des Kernels gepatcht wird, der einen Fehler verursacht, ohne den Kernel sicher zu machen. Da die Änderung außerdem die Flash-Zähler-/Änderungserkennungsmechanismen auslöst, hat dies wenig Sinn, anstatt einfach einen Kernel aus dem Quellcode zu erstellen.
Wenn Sie sich also dazu entschließen, dies auszuprobieren, sollten Sie dies mit größter Vorsicht tun. Sowohl der Test als auch der Patch könnten fehlschlagen, und wenn das passiert, könnten Sie am Ende scheitern. Dies sollte nicht als schlechte Entwicklung missverstanden werden. Es handelt sich absolut nicht um eine schlechte Entwicklung, und das Skript könnte sehr gut dazu verwendet werden, festzustellen, ob der Brick-Bug vorhanden ist. Allerdings ist es nie eine schlechte Idee, äußerste Vorsicht walten zu lassen. Derzeit stehen Entrop512 und andere in direktem Kontakt mit Samsung, um das Problem dauerhaft zu beheben.
Weitere Informationen finden Sie im Originalthread.
[Foto wurde von egztunder1 geklaut fantastischer Artikel auf dem Brick Bug. Vielen Dank auch an Entropy512 für die Beratung.]