24/7-Notdienst
0800 3336670Vojtěch Kavan, Spezialist für forensische Datenrettung, DATARECOVERY • 20.04.2026
Moderner NAND-Flash setzt zur Fehlerkorrektur auf LDPC-Codes (Low-Density Parity-Check) anstelle der älteren BCH-Codes (Bose-Chaudhuri-Hocquenghem). Den Wechsel erzwang die Einführung von 3D-TLC- und QLC-Speichern, bei denen die Fehlerrate auf Ebene der Rohdaten so hoch ist, dass BCH nicht mehr genügt. Im Bereich der Datenrettung per Chip-off-Verfahren arbeiten jedoch sämtliche verfügbaren Werkzeuge, sei es PC-3000 Flash von ACE Lab, VNR von Rusolut oder Flash Extractor von Soft-Center, ausschließlich mit BCH. Die Firmware des Controllers, in der LDPC implementiert ist, lässt sich dabei prinzipiell reverse-engineeren, und es stellt sich daher die Frage, warum kein Chip-off-Decoder für LDPC existiert. Dahinter stehen mehrere Gründe, sowohl prinzipieller als auch rein praktischer Natur.
LDPC hat BCH aus einem praktischen Grund verdrängt: Es dekodiert mit sehr geringem Abstand zum theoretischen Shannon-Limit. Diese Fähigkeit steht und fällt damit, dass der Decoder nicht bloß Nullen und Einsen erhält, sondern zu jedem Bit zusätzlich eine Angabe darüber, wie zuverlässig das Leseergebnis ist. Dieses Maß an Zuverlässigkeit drückt das Log-Likelihood-Verhältnis (LLR) aus, also der Logarithmus des Verhältnisses der Wahrscheinlichkeiten, dass das Bit eine Null beziehungsweise eine Eins ist. Je weiter der Wert von Null entfernt liegt, desto sicherer ist der Lesevorgang.
Ein Chip-off-Reader liefert dies jedoch nicht. Jede Zelle wird nur ein einziges Mal und bei einer einzigen Referenzspannung gelesen, mit dem Ergebnis einer schlichten Null oder Eins ohne jede Angabe zur Zuverlässigkeit. LDPC-Dekodieralgorithmen vom Typ Min-Sum oder Sum-Product funktionieren mit solchen Eingaben zwar, verlieren dabei aber ihren entscheidenden Vorteil. Das Ergebnis ist dann in etwa mit einem BCH-Code vergleichbarer Redundanz gleichzusetzen. Mit anderen Worten: Selbst bei fehlerfreier Rekonstruktion der Paritätsprüfmatrix aus dem Controller würde der LDPC-Decoder an denselben verschlissenen Seiten scheitern, an denen auch BCH scheitert.
Wie kommt der Controller überhaupt an die Zuverlässigkeitsinformation einzelner Bits? Indem er die Seite mehrfach liest und dabei jedes Mal die Referenzspannung geringfügig verschiebt. Erst aus mehreren solchen Lesevorgängen ergibt sich für jedes Bit eine Aussage darüber, wie sicher das Leseergebnis ist. Die Spannungsverschiebung wird jedoch über Befehle gesteuert, die nicht öffentlich dokumentiert sind. Operationscodes, Adressen und die Bedeutung einzelner Werte handhabt jeder Hersteller (Samsung, Kioxia, Micron, SK Hynix, YMTC) auf seine eigene Weise und ändert sie zudem häufig zwischen aufeinanderfolgenden Generationen seiner Speicher.
Theoretisch steht damit nichts im Wege, dass auch ein Chip-off-Reader weiches Lesen beherrscht. Einige neuere Plattformen können eigene Befehle an den Flash-Speicher absetzen; für sich genommen sind sie jedoch auf das Auslesen in Stapelverarbeitung ausgelegt, und für den interaktiven Read-Retry-Zyklus, den weiches Lesen erfordert, müsste zunächst auch ihre Firmware angepasst werden. Die eigentliche Hürde bleibt aber die aufwändige Analyse und Dokumentation des Protokolls für jeden einzelnen Die-Typ.
BCH ist ein Code, der sich über wenige Parameter beschreiben lässt. Der Galois-Körper, das primitive Polynom und das Tripel (n, k, t) genügen, und damit ist der Code vollständig bestimmt. Bei LDPC liegt die Lage grundsätzlich anders, denn er ist durch seine gesamte Paritätsprüfmatrix H definiert. Diese wird in modernen Controllern nicht als Tabelle abgelegt, die sich aus der Firmware auslesen ließe. Sie ist in der Regel direkt in der ECC-Engine verdrahtet, also in jenem Stück Silizium, das die Paritätsbits berechnet.
Taucht doch einmal eine Tabellenform im Speicher auf, handelt es sich meist um eine quasi-zyklische (QC) Matrix. Das heißt, H setzt sich aus kleinen quadratischen Submatrizen mit einer regelmäßigen Struktur zusammen, die sich allein durch einen Verschiebungswert speichern lässt, fallweise ergänzt um seiten- oder blockspezifische Permutationen, die auf die jeweilige Kombination aus Controller und NAND-Speicher abgestimmt sind. Das Reverse Engineering einer solchen Kombination ist somit eine Arbeit, deren Ergebnis weder auf einen anderen Controller noch auf einen anderen Speicher übertragbar ist.
Der aus dem Flash-Speicher gewonnene Datenstrom ist kein unmittelbarer Eingang für den ECC-Decoder. Zuvor ist in aller Regel das Scrambling aufzuheben, also eine XOR-Operation mit einer pseudozufälligen Maske, mit der der Controller die Daten bereits vor dem eigentlichen Schreibvorgang transformiert, um deren statistische Eigenschaften so zu verteilen, dass sich im Speicher keine wiederkehrenden Muster ausbilden.
Die Aufgabe ist für sich genommen nicht prinzipiell schwierig, sie muss jedoch absolut präzise ausgeführt werden. BCH vermag kleine Ungenauigkeiten in der Vorverarbeitung zu absorbieren, da sein Arbeitspunkt deutlich unterhalb der Kanalkapazität liegt. LDPC verfügt über keine solche Reserve und operiert nahe am Shannon-Limit des Flash-Kanals. Eine Abweichung, die bei BCH folgenlos bliebe, führt bei LDPC zum Scheitern der gesamten Dekodierung.
Die Reverse-Analyse von BCH auf Ebene einer Controller-Familie stellt eine Aufgabe mit überschaubarem Aufwand dar. Der Code ist durch wenige Parameter vollständig bestimmt, die sich mit begrenztem Aufwand aus der Firmware gewinnen lassen, und ihre Gültigkeit überträgt sich auf alle Controller derselben Familie. Bei LDPC liegen die Dinge anders. Für jeden Controller sind die Paritätsprüfmatrix zu gewinnen, das Soft-Read-Protokoll zu beschreiben und ein iterativer Decoder abzustimmen, wobei sich das Ergebnis dieser Schritte nicht zwischen Controllern übertragen lässt und sich mit jeder weiteren Generation der gesamte Vorgang wiederholt. Der entsprechende Aufwand liegt damit um Größenordnungen über dem von BCH, und das auf einem Markt, auf dem die Stückzahlen einzelner Controller-Modelle begrenzt und ihre Lebenszyklen kurz sind. Unter diesen Bedingungen ist es nicht überraschend, dass bislang kein kommerzieller Hersteller von Werkzeugen die Integration einer LDPC-Dekodierung in einen produktiven Chip-off-Arbeitsablauf finanziert hat und dass sich der mit jeder Controller-Generation neu anfallende Aufwand auch unter den Bedingungen eines einzelnen Labors kaum rechtfertigen lässt.
Handelt es sich bei dem Gegenstand der Datenrettung um einen Speicher mit LDPC-geschützten Daten, wird vom Chip-off-Verfahren in der Praxis von vornherein Abstand genommen. Die Arbeit erfolgt direkt über den originalen Controller, typischerweise mit dem System PC-3000 von ACE Lab. Die ECC-Engine des Controllers erfüllt in dieser Konfiguration ihre ursprüngliche Funktion, führt also LDPC-Dekodierung und weiches Lesen wie vorgesehen aus, und das Labor befasst sich erst mit den höheren Schichten, namentlich mit der Rekonstruktion der Blöcke und der Wiederherstellung des Translators. Überall dort, wo LDPC als ECC zum Einsatz kommt, ist somit der Controller selbst der einzige praktisch verwendbare Decoder.