Y580 m. RapidDrive + Win7: Suche MBR-Infos

[thor.a]

Hallo,

aus Interesse an einer eher forensischen Wiederherstellung suche ich Infos zur originalen Festplattengeometrie eines:

Ideapad Y580 mit Windows 7 und: 1 SSD (32 GB) + 1 HDD (1 TB)

Die SSD und die HDD waren bei diesem Gerät von Werk aus mit dem sog. "Rapid Drive" verbunden (eine Art Raid 0-Verbindung beider Platten). Das Gerät sah im Betrieb nur eine Festplatte.

Falls jemand noch so ein Gerät in dieser originalen Konstellation besitzt und zwischendurch die Partitionierung nicht verändert hat (!), würden mich ein paar Infos zu MBR etc. interessieren, damit ich einen Defekt dieses Plattenverbundes bei mir evtl. reparieren kann.

Würde mich freuen, wenn sich ein Besitzer dieses Notebooks, der genau die o. g. Hardwarekombination hat, bei mir melden würde. Genaueres dann per PM.

Thorsten

 

[think_pad]

Hallo, aus Interesse an einer eher forensischen Wiederherstellung suche ich Infos zur originalen Festplattengeometrie eines ...

Es gibt keine "forensische Wiederherstellung" und auch keine "spezielle Festplattengeometrie" bei Rapid Drives, ebenso gibt es keine "Art Raid 0-Verbindung beider Platten".

Die Technik , die dahinter steht, ist ein stinknormales WINDOWS 7 auf der SSD mit System-Startpartition, das von dort sehr schnell bootet. Jeder kann sich nachträglich eine kleine SSD in sein M2-Slot einbauen und Rapid Drive aktivieren, insofern er WINDOWS neu installiert. Hierzu wird vor der Installation aus WINDOWS PE heraus ein Rapid-Tool gestartet, das zwischen SSD und HDD separiert, und dann wird in die (kleine) SSD installiert. Auf der HDD wird eine unallocated Partition angelegt, in die solche Dateien ausgelagert werden, die selten benutzt werden; dahinter folgt normalerweise die logische Wiederherstellungspartition von Lenovo. Direkt nach der WIN7-Installation wird der Rapid-Driver installiert, der seltene Daten auf die HDD schaufelt, wenn das System größer wird. Da man mit dem Treiber seine Platte unwiderruflich schrotten kann, werde ich hier keinen Link setzen.

Wenn Du jetzt ein laufendes WINDOWS 7 auf der HDD hast, wirst Du Rapid Drive nicht mehr nachträglich aktivieren können. Ich bräuchte einen ordentlichen Screenshot der Datenträgerverwaltung vom Ideapad Y580, um Näheres sagen zu können.

Oder geht es darum, wertvolle Daten von der "totgelegten SSD" zu retten?

 

[thor.a]

Oder geht es darum, wertvolle Daten von der "totgelegten SSD" zu retten?

Ja.

Mit "forensisch" meinte ich: ich möchte meinen momentan unbrauchbar gewordenen SSD-HDD-Verbund auf Basis von RapidDrive wiederherstellen, da ich dort eine bestimmt Datei suche, die ich seit der letzten Sicherung (s. u.) angelegt hatte. Momentan ist der Verbund zerstört, da der MBR beider Platten überschrieben wurde.

Festplattengeometrie war nicht korrekt ausgedrückt. Ich meinte: ich hätte gerne von jemanden die exakten MBR-Daten beider Platten erfahren (sofern die HDD überhaupt einen gültigen MBR-Eintrag besaß).

Insofern wäre es ein eleganter Weg, das System wieder lauffähig zu machen, wenn ich von jemandem mit genau dieser Konstellation die MBRs bzw. Track0 beider Platten sichern lasse, um sie dann bei mir wieder einzuspielen. Das müsste den Verbund wieder lauffähig machen. Das ginge problemlos mit mbrwizard.

Ich habe aber den Eindruck, das Du nicht zu denjenigen gehörst, die genau diese Hardware-Konstellation besitzen, oder? Aber vielleicht kennst Du ja jemanden?

Wenn Du jetzt ein laufendes WINDOWS 7 auf der HDD hast, wirst Du Rapid Drive nicht mehr nachträglich aktivieren können. Ich bräuchte einen ordentlichen Screenshot der Datenträgerverwaltung vom Ideapad Y580, um Näheres sagen zu können.

War mein Posting wirklich so unverständlich formuliert? Ich hatte doch von einen "Defekt des Plattenverbundes" geschrieben. Hatte ich etwas von einem "laufenden Windows 7" erwähnt?

BTW Falls es Dich interessiert: Ich habe das komplette Windows 7 auf RapidDrive-Basis auf Basis meiner letzten (Live-) True Image Sicherung (von vor ein paar Wochen) erfolgreich auf eine einzige Festplatte transferiert. Ohne jeglichen Datenverlust. Es läuft jetzt natürlich ohne den RapidDrive-Treiber bzw. Service.

Bislang war mir nicht klar, dass eine solche Migration überhaupt funktionieren kann, daher hatte ich es bislang nie versucht, sondern nur pro forma hin und wieder ein Image angefertigt. Jetzt hatte ich allerdings genügend Motivation, es endlich anzugehen. Im Netz hatte ich zum Thema "Trennung des RapidDrive-Verbundes ohne Datenverlust" bislang keine Anleitung gefunden. Evtl. schreibe ich mal eine, falls sich überhaupt noch irgend jemand außer mir für dieses Thema interessieren sollte.

Thorsten

 

[think_pad]

Insofern wäre es ein eleganter Weg, das System wieder lauffähig zu machen, wenn ich von jemandem mit genau dieser Konstellation die MBRs bzw. Track0 beider Platten sichern lasse, um sie dann bei mir wieder einzuspielen.

In Berlin sagt man dazu: Eine Schnapsidee...

BTW Falls es Dich interessiert: Ich habe das komplette Windows 7 auf RapidDrive-Basis auf Basis meiner letzten (Live-) True Image Sicherung (von vor ein paar Wochen) erfolgreich auf eine einzige Festplatte transferiert.

War es eine andere Festplatte als die verbaute? Existiert die originale HDD noch?

Momentan ist der Verbund zerstört, da der MBR beider Platten überschrieben wurde.

Sicher, dass es nur das ist? Und wegen des MBR so einen Aufstand? Warum baust Du dann nicht einfach die SSD und die Original-HDD wieder ein, bootest von einer WINDOWS 7-Reparatur- oder Installations-CD und führst eine

Startreparatur

aus? Dann wird auch der MBR der SSD neu geschrieben, die SSD bootet ganz normal, und die HDD bekommt ihre Infos vom Rapid -Treiber.

Du kannst aber auch diskpart und bootrec in der Konsole verwenden:

1. bootrec /FixMbr repariert den MBR.
2. Der Bootmananger bootmgr wird durch bootrec /FixBoot wiederhergestellt.
3. Einen komplett neuen Boot-Speicher baut bootrec /RebuildBcd, scannt danach nach Windows-Installationen und bietet die Möglichkeit, diese dem Boot-Speicher hinzuzufügen.
4. Ist der Boot-Speicher an sich in Ordnung, und man will nur vermisste Einträge manuell hinzufügen, bietet bootrec /ScanOs einen nicht-schreibenden Modus, bei dem die beim Scan gefundene Systeme nur aufgeführt werden.
5. Geben die Befehle 2. und 3. den Fehler „Element not found“ aus, fehlt das "Aktiv-Attribut:

select disk 0
select partition 1
active
exit

​

Source: -> https://www.windowspro.de/andreas-k...en-unter-windows-7-und-windows-server-2008-r2

 

[thor.a]

In Berlin sagt man dazu: Eine Schnapsidee...

Das denke ich nicht, weil... (s.u.)

War es eine andere Festplatte als die verbaute? Existiert die originale HDD noch?

Es sind noch die originalen Festplatten vorhanden.

Sicher, dass es nur das ist? Und wegen des MBR so einen Aufstand?

Der MBR enthält üblicherweise auch die Partitionstabelle. Selbige ist leider ebenfalls gelöscht. Ich denke, dass das der wesentliche Teil des Problems ist. (Leicht mit Diskeditor zu sehen).

Warum baust Du dann nicht einfach die SSD und die Original-HDD wieder ein, bootest von einer WINDOWS 7-Reparatur- oder Installations-CD und führst eine aus? Dann wird auch der MBR der SSD neu geschrieben, die SSD bootet ganz normal, und die HDD bekommt ihre Infos vom Rapid -Treiber.

Ich hatte das tatsächlich am Anfang meiner Recoverybemühungen so gehandhabt. Allerdings ohne Erfolg. Mittlerweile finde ich es logisch, dass es nicht geklappt hat. Zum Einen fehlten die Infos in der Partitionstabelle, zum Anderen fehlte der WinRE-Umgebung jegliche Infos über die RapidDrive-SSD/HDD-Kombination, so dass sie keine intakte Windows7-Partition bzw. ein intaktes NTFS-Dateisystem vorgefunden hat. Sie hat sich nach der allerersten MBR-Reparatur dann mit einem Error beendet. Falls zu dem Zeitpunkt vor Anwendung der WinRE doch noch Partitionsinfos da gewesen waren bzw. "richtige" Sektorenanzahlen: jetzt jedenfalls nicht mehr. Entweder wurden sie bereits durch die Reparaturversuche (falsch) modifiziert, oder aber sie waren nicht vorhanden.

Du kannst aber auch diskpart und bootrec in der Konsole verwenden:

1. bootrec /FixMbr repariert den MBR.
2. Der Bootmananger bootmgr wird durch bootrec /FixBoot wiederhergestellt.
3. Einen komplett neuen Boot-Speicher baut bootrec /RebuildBcd, scannt danach nach Windows-Installationen und bietet die Möglichkeit, diese dem Boot-Speicher hinzuzufügen.

Ein /fixMBR ignoriert normalerweise eine Partitionstabelle. Noch nicht einmal eine WinRE mit integriertem RapidDrive-Treiber könnte die Partitionstabelle wiederherstellen.

M. W. ist nur der MBR inkl. Partitionstabelle defekt; somit sollten Bootmanager und Boot-Speicher noch intakt sein. Aber es wäre ein Versuch wert, die Reparatur der BCD mit einer WinRE-Umgebung mit integriertem RapidDrive-Treiber zu versuchen. (Ein Skript zur Injektion eines RapidDrive-Treibers in WinRE liegt tatsächlich im Treiberverzeichnis beim RapidDrive-Treiber. Vielleicht probiere ich das jetzt auch noch aus...)

Ich befürchte jedoch, dass ich ohne die "richtigen" Angaben in der Partitionstabelle nicht weiterkomme. Selbst berechnen habe ich nicht geschafft:
Ich habe zwar mit dem Diskeditor zweifelsfrei die Sektorennummer aller NTFS-Partitionen (Anfang/Ende) auf SSD und HDD lokalisiert, aber trotz diverser Sektorenrechnerei bin ich nicht auf den Wert gekommen, den die NTFS-Partition in ihrem Backupsektor für die Windows-Partition angibt. (Ich glaube, dass dieser Wert noch korrekt ist. Beim Hauptbootsektor bin ich mir nicht mehr so sicher.)

Insofern wäre es also keine Schnapsidee, falls mir diese Partitionsinfos jemand anders geben würde. Möglicherweise würde das klappen. Oder mir erklärt jemand, wie man die Sektornummern der HDD in der Partitionstabelle der SSD angibt, das wäre auch nicht schlecht. Aber ich bin offenbar der letzte (gewesen), der diese Kombination noch gefahren ist (und die anderen lesen hier nicht mit...)

Allerletzte Idee: den Verbund in einer virtuellen Maschine nachspielen und gucken, was der RapidDrive-Treiber genau mit der Partitionstabelle so alles anstellt....

Thorsten

 

[think_pad]

Der MBR enthält üblicherweise auch die Partitionstabelle. Selbige ist leider ebenfalls gelöscht. Ich denke, dass das der wesentliche Teil des Problems ist. (Leicht mit Diskeditor zu sehen).

Ich hätte gern einen Screenshot mit gparted.

„No bootable device -- insert boot disk and press any key“

... heißt nämlich nicht, dass die Partitionen zerschossen sind. Der Diskeditor kann die Partitionen nicht sehen, weil es virtuelle Partitionen von Rapid Drive sind.

Sind die Hauptpartionen noch da, kann man die eine "wertvolle Datei" auf USB retten, in dem man die Lenovo Recovery-Taste in eine WINDOWS-Kommandozeile umbiegt. Hierfür klaut man aus der Recovery-Partion des beschädigten Original-Rechners die lrs.wim, eine gepackte Lenovo-Ressouce-Datei, welche den Recovery-Prozess anstösst. Die darin enthaltene winpeshl.ini wird um den Eintrag

[LaunchApps]
%SYSTEMDRIVE%\windows\system32\cmd.exe

... geändert und dann auf die Original-Platte zurück transferiert, so das vor dem Booten die Lenovo-Taste gedrückt werden kann und man vom Command-Fenster Dateien kopieren kann. Diese PE-Version von der Recovery enthält bereits den Rapid-Treiber und kann auf Dein System zugreifen, wenn ich diesen absolut vertraulichen Geheimtipp hier ganz heimlich und gleichzeitig whistleblowermäßig in aller Öffentlichkeit verraten darf.

Merke:

"Forensik" klingt zwar gut, aber etwas Gehirnschmalz tut es manchmal auch.

 

[thor.a]

... heißt nämlich nicht, dass die Partitionen zerschossen sind. Der Diskeditor kann die Partitionen nicht sehen, weil es virtuelle Partitionen von Rapid Drive sind.
(...)
Diese PE-Version von der Recovery enthält bereits den Rapid-Treiber und kann auf Dein System zugreifen

Dass die Partitionstabelle intern gehalten wird, war ein guter Gedankenanstoß von Dir. Da ich die mit RapidDrive ergänzte Rettungsumgebung bereits in Erwägung gezogen habe, habe ich diesen Ansatz weiterverfolgt und aufgehört, mit Sektoren herumzurechnen. Das System ist momentan wieder mit der alten SSD-/HDD-Kombination komplett und stabil am Laufen. Hätte ich fast nicht mehr für möglich gehalten...

Es war ein wenig einfacher als Dein Lösungsvorschlag mit Hilfe der Recovery und einer modifizierten lrs.wim. Falls es Dich interessiert, wie ich es erreicht habe:

• WinRE-Stick mit RapidDrive gebaut:
  • aus meinem vorhanden TrueImage-Backup habe ich die winre.wim extrahiert (aus C:\recovery).
  • winre.wim gecheckt auf vorhandenen RapidDrive-Treiber und Registry-Einträge (war alles vorhanden)
  • winre.wim in ein normales Windows7-Rettungsmedium transferiert (Imageergänzung mit imagex.exe)
• Laptop mit SSD und HDD vom WinRE-Stick gebootet:
  • bis zum Booten (Windows-Fortschrittbalken) hat es ein wenig gedauert
    • evtl. hat in dieser Zeit der RapidDrive-Treiber schon ein wenig gefixt
  • in WinRE dann automatischen Reparaturversuch angestoßen
    • hat ewig gedauert, dann irgendwann Errormeldung
  • dann per cmd die üblichen Boot-Reparaturen vorgenommen
    • /fixmbr
    • /rebuildbcd
    • /scanos
    • (keine Ahnung, ob ich das auch noch gemacht habe: /fixboot)

Das war's. Der Laptop bootete wieder. Bin mir nicht so sicher, welcher Teil meiner Lösung jetzt die eigentliche Reparatur durchgeführt hat. Vielleicht das /rebuildbcd. Aber vielleicht wurde sogar schon bei der automatischen Reparatur, die mit einem Fehler abbrach, das Wesentlichste repariert.

Der einzige Kollateralschaden, der momentan existiert, ist, dass die Partition mit den Treibern (zwischen Win und Recovery-Partition) tatsächlich inkonsistent geworden geworden ist. Das NTFS-Dateisystem ist lt. chkdsk nicht reparierbar; sie wird als raw angezeigt. Vorher war sie sichtbar. Egal, da das System sowieso nur noch temporär läuft.

BTW Auf der HDD wurde vom RapidDrive-Treiber die Partitionstabelle neu angelegt bzw. um eine "compaq-"-Partition ergänzt (die HDD-Ergänzung der Win7-Partition).

Die Datei, die ich gesucht habe, war leider, leider nicht mehr auf der Platte. Auch Recuva hat sie nicht gefunden; vmtl. waren die Blöcke bereits anderweitig beschrieben worden, da ich direkt danach noch einige weitere Programme installiert hatte. Es handelte sich laut Downloadliste vom Browser um eine "simple" smplayer.exe, welche ich am 3.8.2016 von fosshub heruntergeladen hatte. Selbige Datei war leider infiziert (siehe Retrovirus-Befall von ClassicShell vom 29.7.2016 bei fosshub). Wenn ich auf die Dateigröße geachtet hätte (32 kB statt 32 MB), wäre nichts passiert. Hatte ich jedoch nicht...

Thorsten

PS

"Forensik" klingt zwar gut, aber etwas Gehirnschmalz tut es manchmal auch.

Dein Lösungsansatz erfordert tiefergehende Kenntnisse der internen Strukturen der Recoverypartition bzw. des RapidDrive-Treibers. Er hat somit nichts mit "Gehirnschmalz" zu tun, sondern mit der Kenntnis von Interna.

PPS Die Analyse eines (schwer zugänglichen) Datenträger kann man ohne Weiteres als IT-Forensik bezeichnen. Allerdings belasse ich es jetzt auch dabei; der bislang von mir investierte Zeitaufwand ist mittlerweile unverhältnismäßig groß geworden. Aber mich hatte das Lahmlegen meines Rechners ziemlich geärgert, und ich werde vorsorgen, damit mir das nicht wieder passiert. Zum Testen wäre der Verursacher ganz praktisch gewesen.