Erkennen und Patchen des eMMC-Superbrick-Bugs für Stock-ICS-Kernel

[darth_mickrig]

Einleitung

Wie es bereits bekannt ist, existiert in den Samsung Stock-ICS 4.0.4 Rom wieder der Superbrick-Bug, der bei Wipe-Operationen in der Recovery den interen Flashspeicher zerschießt und aus dem S2 einen Briefbeschwerer macht.
Bisher war es für den normalen User nicht möglich zu erkennen, ob der Kernel eines neuen ICS-Releases den Bug besitzt, ohne sein Handy danach zum Service-Center schicken zu müssen. Grundsätzlich wird und wurde bei jedem neuen Release angenommen, dass dieser Brick-gefährdet ist.
Tungstwenty bei XDA hat eine Methode gefunden, den Kernel völlig gefahrenlos auf den Brick-Bug zu testen und den betroffenen MMC_CAP_ERASE Befehl zu deaktivieren.

Erkennen des Bugs

Jeder Kernel mit aktivierten MMC_CAP_ERASE löst den Brick-Bug aus. Zur Erkennung des Bugs muss also erkannt werden, ob dies bei dem zu untersuchenden Kernel der Fall ist.

Voraussetzungen:

Linux
oder
Windows mit Cygwin
Tungstwentys Script
Kernel als zImage

Durchführung:

Zur Untersuchung des Kernels das Script ausführen und den Kernel-Namen als Argument einfügen.
Bei Windows und Cygwin empfehle ich, sowohl das Script als auch den Kernel per Drag&Drop in das Cygwin Terminal Fenster zu schieben. Dabei auch darauf achten, dass beim Kernel-Pfad keine Leerzeichen vorhanden sind (dies hatte bei mir Probleme bereitet).
Auf einem Ubuntu 12.04 32-Bit musste ich vor Verwendung des Scriptes erstmal die Berechtigungen neu setzen, da es sonst immer zu einem Abbruch kam. Danach sollte es egal sein, ob man das Script als root oder Standard-User ausführt.

Beispiel Output des Scripts:

XWLPI-Kernel

Spoiler

###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# Tungstwenty@gmail.com #
# #
###############################################

Detecting safety of kernel: /cygdrive/c/Brick/XWLPI-zImage
Kernel: Linux version 3.0.15-I9100XWLPI-CL686447 (dpi@DELL141) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Fri Jun 8 10:36:35 KST 2012

0 ocurrences of the bad code signature
1 ocurrences of the good code signature


The kernel appears to be good (MMC_CAP_ERASE disabled)

XWLPO-Kernel:

Spoiler

###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# Tungstwenty@gmail.com #
# #
###############################################

Detecting safety of kernel: /cygdrive/c/zImage
Kernel: Linux version 3.0.15-I9100XXLQ7-CL753921 (se.infra@SEP-107) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Wed Jul 4 20:32:40 KST 2012

1 ocurrences of the bad code signature
0 ocurrences of the good code signature


***************
!!! WARNING !!!
***************

The kernel appears to have MMC_CAP_ERASE *enabled*, which is dangerous on many devices

Unpacked kernel code stored at: /cygdrive/c/zImage_unpacked
The unsafe instruction can be found at offset 0x00594ef4

==================== Disassembly of the instruction ====================
If you want to check the disassembly make sure CROSS_COMPILE is correctly set and exported
========================================================================

*** Instructions for patching ***

- Choose one of the existing unpack/repack scripts
- Unpack the kernel code, initramfs, etc.
- Do a binary edit of the unpacked code
- At offset 0x00594ef4, replace "01 ?b 8? e3" with "00 ?b 8? e3" - change just the first byte to 00
- Repack the kernel, including the changed code and all original contents
- Re-run this script to confirm that the newly generated file no longer has MMC_CAP_ERASE enabled

Mehr Beispiele findet ihr im originalen XDA-Thread

Wie ihr seht, wird bei gefundenen Fehler auch noch angegeben, wo MMC_CAP_ERASE Code sich befindet und wie man ihn ändern muss um den Bug zu verhindern.

Beheben des Bugs

Voraussetzungen:
* Externes Kernel Unpack/Repack Script (Zu finden bei XDA)
* Linux box
* einen Hex-Editor
* Weitere, vom Kernel-Script vorausgesetzte, Dateien

1. Extrahiert mit dem Unpack/Repack Script die zImage-Datei (Kernel)
2. Bearbeitet die Datei piggy
3. Dazu öffnet ihr die Datei in einem Hex-Editor und geht zu dem vom Check-Script genannten Offset
4. Ändert die 01 in 00 und speichert die Datei
5. Packt den Kernel wieder zusammen. Dabei müsst ihr darauf achten, dass die Piggy benutzt wird, die ihr editiert habt, da es durchaus sein kann, dass das Script die Piggy aus Einzelteilen neu zusammensetzt.
6. Checkt den neuen Kernel mit tungstwentys Script. Als Output solltet ihr nun erhalten

Spoiler

###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# Tungstwenty@gmail.com #
# #
###############################################

Detecting safety of kernel: /home/user/Arbeitsfläche/Repack/zImage_packing/zImage
Kernel: Linux version 3.0.15-I9100XWLPT-CL941023 (dpi@DELL169) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Fri Jul 27 18:08:15 KST 2012

0 ocurrences of the bad code signature
1 ocurrences of the good code signature


The kernel has been patched by this method to disable MMC_CAP_ERASE and should now be entirely safe

7. Flasht diesen Kernel nun auf euer Handy.

Disclaimer:
Es kann keine 100% erfolgreiche Erkennung versprochen werden.
Der gepatchte Kernel sollte flashbar sein, jedoch wurde es nicht mit kompletten Unpack/Repack ausprobiert.


Originaler XDA-Thread:
[BrickBug][Fix][Kernel][01.08]Detection of stock kernel safety + patch guide - xda-developers
Script und Thread erstellt durch Tungstwenty (unteranderem für den CRT-Flicker-Bug-Fix sowie 4.0.4 Kamera-Bug-Fix verantwortlich)


@Mods: Sollte dieser Thread im falschen Bereich gelandet sein, verschiebt ihn bitte. Da der Kernel-Bereich nur für die Vorstellung von Custom-Kernel ist, habe ich mich erstmal dazu entschieden, ihn im Root/Hacking/Modding/Bereich zu posten.

 

[huberheinz]

Erst mal danke für diese einfache methode der überprüfung. Allerdings scheint sie nur bei Stockkerneln zu funktionieren?!
Wollte auch mal den Speedmod k3-30 damit testen. Leider kommt es hierbei zu einer Fehlermeldung, weiß jemand wieso?

 

[darth_mickrig]

Guck mal auf den Thread-Titel
Und im Originalthread bei XDA:
"However, for custom kernels I won't expect the code patterns to be always the same and therefore it's possible that the detection cannot be performed - you will see that in the output."
Übersetzt: Das Code-Muster kann in Custom-Kerneln anders sein, weswegen eine Erkennung nich möglich sein könnte. Dies wird durch die Ausgabe wiedergegeben.

 

[huberheinz]

Sorry für meine dämliche Frage...
Wer lesen kann ist klar im Vorteil :blushing:

 

[darth_mickrig]

Allgemeine Anleitung zum Beheben des Bugs gepostet. Ich hab mit tungstwentys Hilfe und so für mich einen gefixten XWLPT Kernel, konnte ihn jedoch noch nicht auf Bootfähigkeit testen. Sobald ich das bewerkstelligt habe kann ich es hier posten mit dazugehörigen Links.

 

[kangaroo72]

Gibt jetzt schonmal ein Danke für den fertigen XWLPT-Kernel, damit ich das SGS2 von meiner besseren Hälfte mal wieder auf den neuesten Stand bringen kann ;-)

 

[Thoddü]

@ topas: Ich wusste, ich hab was vergessen

 

[darth_mickrig]

@kangaroo
Nimm für den Zweck mal lieber den Siyah. Ich kann für nichts garantieren. Und bis ich die XWLPT drauf habe kann das noch dauern, das Wochenende bin ich stark mit Geburtstagen beschäftigt.

 

[kangaroo72]

äääh - wadde ... bin mir jetzt nicht sicher ... aber wenn ich Siyah flashe, und was flashe ich dann als Stock?

 

[HipHopRulez]

Was hat denn Siyah jetzt mit Stock zu tun?

 

[kangaroo72]

ich meine ja nur quasi die GUI

 

[darth_mickrig]

Siyah = Kernel
Auf den 4.0.4 ICS ROMs sollte man einen der Custom Kernel benutzen. Bei Siyah ist MMC_CAP_ERASE NICHT aktiviert und man kann dadurch bedenkenlos mit CWM wipen. Es kristalisiert sich langsam heraus, dass Wipen in der Stock-Recovery ohne Probleme selbst mit Brick-Bug funktioniert.
Rein theoretisch kann man halt durch modifizieren des Stock-Kernels den Brick-Bug entfernen. Nur müsste man dann aber auch einen Kernel produzieren der bootet.

 

[nucleaR]

Falls ich das hier richtig Verstanden habe:

Bei dem neuen Update (noch unreleased) vom Siyah soll es jetzt nun gefixed sein.

Zitat:


"SiyahKernel S2-v4.0

Posted on August 5, 2012
Changelog:

• based on update7 sources
• supports Samsung 4.0.3/4.0.4 (no camera problem), CM9, CM10 and MIUI
• all the changes from v3.5.2 are applied
• no CAP_ERASE, no hardbrick
• fixed CM10 led behavior
• fixed led_fadeout behavior
• fixed autorotation problem with CM10 and 4.0.3 ROMs

Not released yet."

mfg

 

[kangaroo72]

So ganz ist der Groschen bei mir noch nicht gefallen ...

Wenn ich jetzt den Siyah flashe ... und dann die Samsung Stock Firmware.

Ist dann nicht der Siyah-Kernel wieder weg, und duch Samsung-Stock überschrieben?

Entschuldigt mein Laien-Wissen

Kangaroo

 

[HipHopRulez]

Ja ist er...

 

[nucleaR]

Müsstest ihn dann einfach nochmal drüberflashen.
*edit* natürlich vorher nochmal das telefon rooten

 

[kangaroo72]

So ...

SiyahKernel S2-v4.0.1 ist released.

Ich sehe das jetzt richtig?

Stockfirmware flashen - rebooten lassen - SiyahKernel flashen - reboot - Wipe - fertig?

Grüsse,

Kangaroo

 

[mecss]

Ja, aber das gehört hier ja nicht hin...

 

[Badtz-Maru]

Hab ich das nun richtig verstanden ?

Der Superbrick-Bugs tritt auf wenn man die Stockrom wipen möchte?
Bin gerade etwas verwirrt.
Bzw. ich muss nur einen neuen Kernel flashen um den Superbrick-Bugs zu verhindern oder ?

 

[Kai Disobey]

Hab ich das nun richtig verstanden ?

Der Superbrick-Bugs tritt auf wenn man die Stockrom wipen möchte?
Bin gerade etwas verwirrt.
Bzw. ich muss nur einen neuen Kernel flashen um den Superbrick-Bugs zu verhindern oder ?

Würde mich auch interessieren Ich hab ICS 4.0.3 und einen passenden CF-Root-Kernel darüber geflashd der ja eigentlich Stock ist nur mit Root.