Okay, es gibt 2 Dinge zu lösen, um hiberfil.sys zu bewegen
Sagen Sie 'ntoskrnl.exe', die als Prozess 'System' ausgeführt wird, um Ruhezustandsdaten in D: \ hiberfil.sys anstelle von C: \ -> noch ungelöst zu öffnen / speichern!
Diese Chance auch auf die Startkonfigurationsdatei (c: \ BOOT \ BCD) anzuwenden -> Dies ist mit Tools wie der VisualBCD https://www.boyans.net/DownloadVisualBCD.html relativ einfach
-> oder auch nur mit regedit Bearbeiten von HKLM \ BCD00000000 \ Objects {71575733-c376-11e4-80ea-806e6f6e6963} \ Elements \ 21000001, das das HiberFileDrive von ResumeLoader oder \ 22000002 HiberFilePath ist. Möglicherweise müssen Sie 'File / Load hive' c: \ BOOT \ BCD verwenden, um den Zweig 'BCD00000000' zu mounten (Cursor muss sich auf HKLM befinden, sonst ist der Menüpunkt ausgegraut)
-> wie es scheint, ist dies bereits erledigt Durch ntosknl.exe muss dies nicht geändert werden, da die Änderungen überschrieben werden.
Nummer 1 ist jedoch die schlechtere und schwerer zu ändernde Sache. Hmm, lass uns ntoskrnl.exe in IDA laden und die Funktion finden, die sich mit /hiberfil.sys befasst, und dekompilieren, um zu sehen, was genau dort vor sich geht ...
__int64 __fastcall PopCreateHiberFile(LARGE_INTEGER *a1)
{
...
RtlInitUnicodeString(&Source, L"\\hiberfil.sys");
...
RtlAppendUnicodeStringToString(&Destination, &IoArcBootDeviceName);
RtlAppendUnicodeStringToString(&Destination, &Source);
...
ObjectAttributes.RootDirectory = 0i64;
ObjectAttributes.Attributes = 576;
ObjectAttributes.ObjectName = &Destination;
ObjectAttributes.SecurityDescriptor = v5;
ObjectAttributes.SecurityQualityOfService = 0i64;
ret_2 = IoCreateFile(
&FileHandle,
0x100003u,
&ObjectAttributes,
...
Okay, kurz gesagt, der Pfad ist wie folgt fest codiert :
IoArcBootDeviceName + "\ hiberfil.sys"
Ohne ein böses binäres Patching gibt es keine Möglichkeit, dies zu ändern. Naja, neben dem Berühren des Holy Windows Grail Patches kann das "ntoskernel" zu Problemen führen, wie zum Beispiel das Rückgängigmachen des Patches oder das Verrücktwerden von Antivirenprogrammen.
IopLoadCrashdumpDriver PopDeleteHiberFile PopCreateHiberFile PopBcdSetupResumeObject PopBcdSetDefaultResumeObjectElements PopBcdSetPendingResume PopBcdRegenerateResumeObject PopBcdEstablishResumeObjectObject PopResumeObject
Wow, das scheint in Ordnung zu sein (nur IopLoadCrashdumpDriver System32 \ Drivers \ crashdmp.sys geht ein bisschen runter, aber wer Crashdump braucht - ist egal, ob wir dort etwas kaputt machen)
So Patchen IopCreateArcNames , die schafft ArcBootDeviceName fein sein wird:
NTSTATUS INIT_FUNCTION NTAPI IopCreateArcNames ( IN PLOADER_PARAMETER_BLOCK LoaderBlock )
...
/* Create the global system partition name */
63 sprintf(Buffer, "\\ArcName\\%s", LoaderBlock->ArcBootDeviceName);
64 RtlInitAnsiString(&ArcString, Buffer);
65 RtlAnsiStringToUnicodeString(&IoArcBootDeviceName, &ArcString, TRUE);
66
67 /* Allocate memory for the string */
68 Length = strlen(LoaderBlock->ArcBootDeviceName) + sizeof(ANSI_NULL);
69 IoLoaderArcBootDeviceName = ExAllocatePoolWithTag(PagedPool,
70 Length,
71 TAG_IO);
72 if (IoLoaderArcBootDeviceName)
73 {
74 /* Copy the name */
75 RtlCopyMemory(IoLoaderArcBootDeviceName,
76 LoaderBlock->ArcBootDeviceName,
77 Length);
78 }
...
https://doxygen.reactos.org/d3/d82/ntoskrnl_2io_2iomgr_2arcname_8c.html
Übrigens Ich verwende ntkrnlmp.exe 6.1.7601.19045 von Win7 64 Bit und überprüfte diesen Code gegen ReactOS. (Der Ruhezustand ist jedoch noch nicht in den Reactos-Quellen implementiert.)
Beachten Sie, dass ArcBootDeviceName etwa wie folgt lautet: \ Device \ Harddisk1 \ Partition0
Hmm lass uns ArcBootDeviceName (LoaderBlock + 0x78) auf ArcHalDeviceName (LoaderBlock + 0x80) patchen
Falls sich der Bootmgr-Loader auf einer anderen Partition befindet als Windows, wird hoffentlich hibernate.sys dort erstellt, wo bootmgr ist.
1405A9C15 4C 8B 4B 78 mov r9, [rbx+78h]
Patch #1 80
1405A9C19 4C 8D 05 30 06+ lea r8, aArcnameS ; "\\ArcName\\%s"
1405A9C20 48 8D 4C 24 40 lea rcx, [rsp+0D8h+pszDest] ; pszDest
1405A9C25 48 8B D7 mov rdx, rdi ; cchDest
1405A9C28 E8 E3 AE B6 FF call RtlStringCchPrintfA
...
1405A9C41 48 8D 0D C0 E7+ lea rcx, IoArcBootDeviceName ; DestinationString
1405A9C48 41 B0 01 mov r8b, 1 ; AllocateDestinationString
1405A9C4B E8 60 13 DB FF call RtlAnsiStringToUnicodeString
1405A9C50 48 8B 7B 78 mov rdi, [rbx+78h]
Patch #2 80
Ersetzen Sie daher in ntoskrnl.exe 4C8B4B78 an zwei Stellen durch 4C8B4B80. Vergessen Sie nicht, die PE-Checksumme nachträglich zu reparieren.