Va bene ci sono 2 cose da risolvere per spostare hiberfil.sys
Di 'a' ntoskrnl.exe 'che funziona come' Sistema 'di processo per aprire / salvare i dati di ibernazione su D: \ hiberfil.sys invece di C: \ -> ancora irrisolti!
Applicare questa possibilità anche al file di dati di configurazione di avvio (c: \ BOOT \ BCD) -> Questo è relativamente facile con strumenti come VisualBCD https://www.boyans.net/DownloadVisualBCD.html
-> O anche semplicemente usando regedit modifica HKLM \ BCD00000000 \ Objects {71575733-c376-11e4-80ea-806e6f6e6963} \ Elements \ 21000001 ovvero HiberFileDrive di ResumeLoader Or \ 22000002 HiberFilePath. Forse devi usare 'File / Load hive' c: \ BOOT \ BCD per montare il ramo 'BCD00000000' (il cursore deve essere su HKLM, altrimenti la voce di menu è disattivata)
-> poiché sembra che sia già stato fatto da ntosknl.exe, quindi non è necessario cambiarlo poiché le modifiche verranno sovrascritte.
Comunque il numero 1. è la cosa peggiore e più difficile da cambiare. Hmm cariciamo ntoskrnl.exe in IDA e individuiamo la funzione che si occupa di /hiberfil.sys e decompiliamola per vedere cosa sta succedendo esattamente lì ...
__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,
...
Va bene in breve il percorso è hardcoded in questo modo:
IoArcBootDeviceName + "\ hiberfil.sys"
senza qualche brutta patch binaria non c'è modo di cambiarlo. Bene, oltre a toccare il patch graal di Windows santo, il "ntoskernel" potrebbe causare problemi come gli aggiornamenti, annullare la patch, oppure i programmi antivirus potrebbero impazzire ... Comunque vediamo quali sono i riferimenti a IoArcBootDeviceName:
IopLoadCrashdumpDriver PopDeleteHiberFile PopCreateHiberFile PopBcdSetupResumeObject PopBcdSetDefaultResumeObjectElements PopBcdSetPendingResume PopBcdRegenerateResumeObject PopBcdEstablishResumeObject Pop
Wow cambiando che sembra andare bene (l'unica cosa che si spegne un po 'è IopLoadCrashdumpDriver System32 \ Drivers \ crashdmp.sys tuttavia chi ha bisogno di crashdump - non importa se rompiamo qualcosa lì)
Quindi patchare IopCreateArcNames che crea ArcBootDeviceName andrà bene:
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
btw sto usando ntkrnlmp.exe 6.1.7601.19045 da Win7 64 bit e ho controllato questo codice con ReactOS. (Tuttavia la parte in letargo non è ancora implementata nelle fonti di Reactos)
Nota che ArcBootDeviceName sarà simile a: \ Device \ Harddisk1 \ Partition0
Hmm patch Patch ArcBootDeviceName (LoaderBlock + 0x78) su ArcHalDeviceName (LoaderBlock + 0x80)
Quindi nel caso in cui il caricatore bootmgr si trovi su una partizione diversa da quella che si spera hibernate.sys di Windows sia stato creato da bootmgr.
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
Quindi in ntoskrnl.exe sostituire 4C8B4B78 con 4C8B4B80 in due posizioni. Non dimenticare di riparare PE-Checksum in seguito.