Windows Native Applications ושירות Acronis Active Restore

היום אנחנו ממשיכים את הסיפור של איך אנחנו, יחד עם החבר'ה מאוניברסיטת Innopolis, מפתחים את טכנולוגיית Active Restore כדי לאפשר למשתמש להתחיל לעבוד על המחשב שלו בהקדם האפשרי לאחר תקלה. נדבר על יישומי Windows מקוריים, כולל תכונות היצירה וההשקה שלהם. מתחת לחיתוך יש קצת על הפרויקט שלנו, כמו גם מדריך מעשי כיצד לכתוב יישומים מקוריים.

בפוסטים קודמים כבר דיברנו על מה זה שחזור פעיל, וכיצד מתפתחים תלמידים מאינופוליס שרות. היום אני רוצה להתמקד ביישומים מקוריים, שברמתם אנחנו רוצים "לקבור" את שירות השחזור הפעיל שלנו. אם הכל יסתדר, נוכל:

• הפעל את השירות עצמו הרבה יותר מוקדם
• צור קשר עם הענן שבו נמצא הגיבוי הרבה קודם לכן
• הרבה קודם כדי להבין באיזה מצב המערכת נמצאת - אתחול רגיל או שחזור
• הרבה פחות קבצים לשחזור מראש
• אפשר למשתמש להתחיל אפילו מהר יותר.

מהי בכלל אפליקציה מקורית?

כדי לענות על שאלה זו, נסתכל על רצף השיחות שהמערכת מבצעת, למשל, אם מתכנת באפליקציה שלו מנסה ליצור קובץ.

פאבל יוסיפוביץ' - תכנות ליבת Windows (2019)

המתכנת משתמש בפונקציה CreateFile, המוצהר בקובץ הכותרת fileapi.h ומיושם ב-Kernel32.dll. עם זאת, פונקציה זו עצמה לא יוצרת את הקובץ, היא רק בודקת את ארגומנטי הקלט וקוראת לפונקציה NtCreateFile (הקידומת Nt רק מציינת שהפונקציה מקורית). פונקציה זו מוצהרת בקובץ הכותרת winternl.h ומיושמת ב-ntdll.dll. הוא מתכונן לקפוץ לחלל הגרעיני, ולאחר מכן הוא מבצע קריאת מערכת ליצירת קובץ. במקרה זה, מסתבר ש-Kernel32 הוא רק מעטפת עבור Ntdll. אחת הסיבות שבגללן זה נעשה היא שלמיקרוסופט יש את היכולת לשנות את הפונקציות של העולם המקומי, אבל לא לגעת בממשקים הסטנדרטיים. מיקרוסופט לא ממליצה לקרוא ישירות לפונקציות מקוריות ואינה מתעדת את רובן. אגב, ניתן למצוא פונקציות לא מתועדות כאן.

היתרון העיקרי של יישומים מקוריים הוא ש-ntdll נטען למערכת הרבה יותר מוקדם מאשר kernel32. זה הגיוני, כי kernel32 דורש ntdll לעבוד. כתוצאה מכך, אפליקציות המשתמשות בפונקציות מקוריות יכולות להתחיל לעבוד הרבה יותר מוקדם.

לפיכך, יישומי Windows Native הם תוכניות שיכולות להתחיל מוקדם באתחול של Windows. הם משתמשים רק בפונקציות מ-ntdll. דוגמה ליישום כזה: autochk מי מבצע כלי השירות chkdisk כדי לבדוק אם יש שגיאות בדיסק לפני הפעלת השירותים הראשיים. זו בדיוק הרמה שאנחנו רוצים שה-Active Restore שלנו תהיה.

בשביל מה אנחנו צריכים?

• DDK (ערכת פיתוח מנהלי התקנים), הידועה כיום גם בשם WDK 7 (ערכת מנהלי התקן של Windows).
• מכונה וירטואלית (לדוגמה, Windows 7 x64)
• לא הכרחי, אבל קבצי כותרות שניתן להוריד עשויים לעזור כאן

מה יש בקוד?

בואו נתאמן קצת, ולדוגמה, נכתוב אפליקציה קטנה ש:

1. מציג הודעה על המסך
2. מקצה קצת זיכרון
3. ממתין לקלט מקלדת
4. מפנה זיכרון משומש

ביישומים מקוריים, נקודת הכניסה היא לא ראשי או winmain, אלא פונקציית NtProcessStartup, מכיוון שאנו למעשה משיקים ישירות תהליכים חדשים במערכת.

נתחיל בהצגת הודעה על המסך. בשביל זה יש לנו פונקציה מקומית NtDisplayString, שלוקח כארגומנט מצביע לאובייקט מבנה UNICODE_STRING. RtlInitUnicodeString יעזור לנו לאתחל אותו. כתוצאה מכך, כדי להציג טקסט על המסך נוכל לכתוב את הפונקציה הקטנה הזו:

//usage: WriteLn(L"Here is my textn");
void WriteLn(LPWSTR Message)
{
    UNICODE_STRING string;
    RtlInitUnicodeString(&string, Message);
    NtDisplayString(&string);
}

מכיוון שרק פונקציות מ-ntdll זמינות לנו, ופשוט אין עדיין ספריות אחרות בזיכרון, בהחלט יהיו לנו בעיות כיצד להקצות זיכרון. האופרטור החדש עדיין לא קיים (מכיוון שהוא מגיע מהעולם הגבוה מדי של C++), ואין פונקציית malloc (זה דורש ספריות C בזמן ריצה). כמובן, אתה יכול להשתמש רק בערימה. אבל אם נצטרך להקצות באופן דינמי זיכרון, נצטרך לעשות זאת בערימה (כלומר ערימה). אז בואו ניצור לעצמנו ערימה וניקח ממנה זיכרון בכל פעם שנצטרך אותו.

הפונקציה מתאימה למשימה זו RtlCreateHeap. לאחר מכן, באמצעות RtlAllocateHeap ו-RtlFreeHeap, נכבוש ונפנה זיכרון כשנצטרך אותו.

PVOID memory = NULL;
PVOID buffer = NULL;
ULONG bufferSize = 42;

// create heap in order to allocate memory later
memory = RtlCreateHeap(
  HEAP_GROWABLE, 
  NULL, 
  1000, 
  0, NULL, NULL
);

// allocate buffer of size bufferSize
buffer = RtlAllocateHeap(
  memory, 
  HEAP_ZERO_MEMORY, 
  bufferSize
);

// free buffer (actually not needed because we destroy heap in next step)
RtlFreeHeap(memory, 0, buffer);

RtlDestroyHeap(memory);

בואו נעבור להמתנה לקלט מקלדת.

// https://docs.microsoft.com/en-us/windows/win32/api/ntddkbd/ns-ntddkbd-keyboard_input_data
typedef struct _KEYBOARD_INPUT_DATA {
  USHORT UnitId;
  USHORT MakeCode;
  USHORT Flags;
  USHORT Reserved;
  ULONG  ExtraInformation;
} KEYBOARD_INPUT_DATA, *PKEYBOARD_INPUT_DATA;

//...

HANDLE hKeyBoard, hEvent;
UNICODE_STRING skull, keyboard;
OBJECT_ATTRIBUTES ObjectAttributes;
IO_STATUS_BLOCK Iosb;
LARGE_INTEGER ByteOffset;
KEYBOARD_INPUT_DATA kbData;

// inialize variables
RtlInitUnicodeString(&keyboard, L"DeviceKeyboardClass0");
InitializeObjectAttributes(&ObjectAttributes, &keyboard, OBJ_CASE_INSENSITIVE, NULL, NULL);

// open keyboard device
NtCreateFile(&hKeyBoard,
			SYNCHRONIZE | GENERIC_READ | FILE_READ_ATTRIBUTES,
			&ObjectAttributes,
			&Iosb,
			NULL,
			FILE_ATTRIBUTE_NORMAL,
			0,
			FILE_OPEN,FILE_DIRECTORY_FILE,
			NULL, 0);

// create event to wait on
InitializeObjectAttributes(&ObjectAttributes, NULL, 0, NULL, NULL);
NtCreateEvent(&hEvent, EVENT_ALL_ACCESS, &ObjectAttributes, 1, 0);

while (TRUE)
{
	NtReadFile(hKeyBoard, hEvent, NULL, NULL, &Iosb, &kbData, sizeof(KEYBOARD_INPUT_DATA), &ByteOffset, NULL);
	NtWaitForSingleObject(hEvent, TRUE, NULL);

	if (kbData.MakeCode == 0x01)    // if ESC pressed
	{
			break;
	}
}

כל מה שאנחנו צריכים זה להשתמש NtReadFile במכשיר פתוח, והמתן עד שהמקלדת תחזיר לנו כל לחיצה. אם מקש ESC נלחץ, נמשיך לעבוד. כדי לפתוח את המכשיר, נצטרך לקרוא לפונקציה NtCreateFile (נצטרך לפתוח את DeviceKeyboardClass0). גם אנחנו נתקשר NtCreateEventכדי לאתחל את אובייקט ההמתנה. אנו נכריז בעצמנו על מבנה KEYBOARD_INPUT_DATA, המייצג את נתוני המקלדת. זה יקל על העבודה שלנו.

האפליקציה המקורית מסתיימת בקריאת פונקציה NtTerminateProcessכי אנחנו פשוט הורגים את התהליך שלנו.

כל הקוד לאפליקציה הקטנה שלנו:

#include "ntifs.h" // WinDDK7600.16385.1incddk
#include "ntdef.h"

//------------------------------------
// Following function definitions can be found in native development kit
// but I am too lazy to include `em so I declare it here
//------------------------------------

NTSYSAPI
NTSTATUS
NTAPI
NtTerminateProcess(
  IN HANDLE               ProcessHandle OPTIONAL,
  IN NTSTATUS             ExitStatus
);

NTSYSAPI 
NTSTATUS
NTAPI
NtDisplayString(
	IN PUNICODE_STRING String
);

NTSTATUS 
NtWaitForSingleObject(
  IN HANDLE         Handle,
  IN BOOLEAN        Alertable,
  IN PLARGE_INTEGER Timeout
);

NTSYSAPI 
NTSTATUS
NTAPI
NtCreateEvent(
    OUT PHANDLE             EventHandle,
    IN ACCESS_MASK          DesiredAccess,
    IN POBJECT_ATTRIBUTES   ObjectAttributes OPTIONAL,
    IN EVENT_TYPE           EventType,
    IN BOOLEAN              InitialState
);



// https://docs.microsoft.com/en-us/windows/win32/api/ntddkbd/ns-ntddkbd-keyboard_input_data
typedef struct _KEYBOARD_INPUT_DATA {
  USHORT UnitId;
  USHORT MakeCode;
  USHORT Flags;
  USHORT Reserved;
  ULONG  ExtraInformation;
} KEYBOARD_INPUT_DATA, *PKEYBOARD_INPUT_DATA;

//----------------------------------------------------------
// Our code goes here
//----------------------------------------------------------

// usage: WriteLn(L"Hello Native World!n");
void WriteLn(LPWSTR Message)
{
    UNICODE_STRING string;
    RtlInitUnicodeString(&string, Message);
    NtDisplayString(&string);
}

void NtProcessStartup(void* StartupArgument)
{
	// it is important to declare all variables at the beginning
	HANDLE hKeyBoard, hEvent;
	UNICODE_STRING skull, keyboard;
	OBJECT_ATTRIBUTES ObjectAttributes;
	IO_STATUS_BLOCK Iosb;
	LARGE_INTEGER ByteOffset;
	KEYBOARD_INPUT_DATA kbData;
	
	PVOID memory = NULL;
	PVOID buffer = NULL;
	ULONG bufferSize = 42;

	//use it if debugger connected to break
	//DbgBreakPoint();

	WriteLn(L"Hello Native World!n");

	// inialize variables
	RtlInitUnicodeString(&keyboard, L"DeviceKeyboardClass0");
	InitializeObjectAttributes(&ObjectAttributes, &keyboard, OBJ_CASE_INSENSITIVE, NULL, NULL);

	// open keyboard device
	NtCreateFile(&hKeyBoard,
				SYNCHRONIZE | GENERIC_READ | FILE_READ_ATTRIBUTES,
				&ObjectAttributes,
				&Iosb,
				NULL,
				FILE_ATTRIBUTE_NORMAL,
				0,
				FILE_OPEN,FILE_DIRECTORY_FILE,
				NULL, 0);

	// create event to wait on
	InitializeObjectAttributes(&ObjectAttributes, NULL, 0, NULL, NULL);
	NtCreateEvent(&hEvent, EVENT_ALL_ACCESS, &ObjectAttributes, 1, 0);
	
	WriteLn(L"Keyboard readyn");
	
	// create heap in order to allocate memory later
	memory = RtlCreateHeap(
	  HEAP_GROWABLE, 
	  NULL, 
	  1000, 
	  0, NULL, NULL
	);
	
	WriteLn(L"Heap readyn");

	// allocate buffer of size bufferSize
	buffer = RtlAllocateHeap(
	  memory, 
	  HEAP_ZERO_MEMORY, 
	  bufferSize
	);
	
	WriteLn(L"Buffer allocatedn");

	// free buffer (actually not needed because we destroy heap in next step)
	RtlFreeHeap(memory, 0, buffer);

	RtlDestroyHeap(memory);
	
	WriteLn(L"Heap destroyedn");
	
	WriteLn(L"Press ESC to continue...n");

	while (TRUE)
	{
		NtReadFile(hKeyBoard, hEvent, NULL, NULL, &Iosb, &kbData, sizeof(KEYBOARD_INPUT_DATA), &ByteOffset, NULL);
		NtWaitForSingleObject(hEvent, TRUE, NULL);

		if (kbData.MakeCode == 0x01)    // if ESC pressed
		{
				break;
		}
	}

	NtTerminateProcess(NtCurrentProcess(), 0);
}

נ.ב.: אנו יכולים להשתמש בקלות בפונקציה DbgBreakPoint() בקוד שלנו כדי לעצור אותה ב-debugger. נכון, תצטרך לחבר את WinDbg למכונה וירטואלית לצורך איתור באגים בליבה. ניתן למצוא הוראות כיצד לעשות זאת כאן או פשוט להשתמש VirtualKD.

קומפילציה והרכבה

הדרך הקלה ביותר לבנות אפליקציה מקורית היא להשתמש DDK (ערכת פיתוח דרייברים). אנו זקוקים לגרסה השביעית העתיקה, מכיוון שלגרסאות מאוחרות יותר יש גישה מעט שונה ועובדות בשיתוף פעולה הדוק עם Visual Studio. אם אנחנו משתמשים ב-DDK, אז הפרויקט שלנו צריך רק Makefile ומקורות.

קובץ Makefile

!INCLUDE $(NTMAKEENV)makefile.def

מקורות:

TARGETNAME			= MyNative
TARGETTYPE			= PROGRAM
UMTYPE				= nt
BUFFER_OVERFLOW_CHECKS 		= 0
MINWIN_SDK_LIB_PATH		= $(SDK_LIB_PATH)
SOURCES 			= source.c

INCLUDES 			= $(DDK_INC_PATH); 
				  C:WinDDK7600.16385.1ndk;

TARGETLIBS 			= $(DDK_LIB_PATH)ntdll.lib	
				  $(DDK_LIB_PATH)nt.lib

USE_NTDLL			= 1

ה-Makefile שלך ​​יהיה זהה לחלוטין, אבל בואו נסתכל על מקורות קצת יותר בפירוט. קובץ זה מציין את מקורות התוכנית שלך (קבצי.c), אפשרויות בנייה ופרמטרים אחרים.

• TARGETNAME - שם קובץ ההפעלה שאמור להיות מופק בסופו של דבר.
• TARGETTYPE – סוג של קובץ הפעלה, זה יכול להיות דרייבר (.sys), אז ערך השדה צריך להיות DRIVER, אם ספרייה (.lib), אז הערך הוא LIBRARY. במקרה שלנו, אנחנו צריכים קובץ הפעלה (.exe), אז אנחנו מגדירים את הערך ל-PROGRAM.
• UMTYPE - ערכים אפשריים לשדה זה: מסוף עבור יישום מסוף, חלונות לעבודה במצב חלונות. אבל אנחנו צריכים לציין nt כדי לקבל יישום מקורי.
• BUFFER_OVERFLOW_CHECKS - בדיקת המחסנית לאיתור גלישת מאגר, למרבה הצער לא המקרה שלנו, אנו מכבים אותה.
• MINWIN_SDK_LIB_PATH – ערך זה מתייחס למשתנה SDK_LIB_PATH, אל תדאג שאין לך משתנה מערכת שכזה, כאשר נריץ build checked מה-DDK, משתנה זה יוכרז ויצביע על הספריות הדרושות.
• SOURCES - רשימת מקורות לתוכנית שלך.
• כולל - קבצי כותרות הנדרשים להרכבה. כאן הם בדרך כלל מציינים את הנתיב לקבצים שמגיעים עם ה-DDK, אבל אתה יכול גם לציין כל קבצים אחרים.
• TARGETLIBS - רשימת ספריות שצריך לקשר.
• USE_NTDLL הוא שדה חובה שיש להגדיר ל-1 מסיבות ברורות.
• USER_C_FLAGS - כל הדגלים שבהם אתה יכול להשתמש בהנחיות מעבד קדם בעת הכנת קוד יישום.

אז כדי לבנות, אנחנו צריכים להריץ את x86 (או x64) מסומן Build, לשנות את ספריית העבודה לתיקיית הפרויקט ולהפעיל את הפקודה Build. התוצאה בצילום המסך מראה שיש לנו קובץ הפעלה אחד.

לא ניתן להפעיל את הקובץ הזה כל כך בקלות, המערכת מקללת ושולחת אותנו לחשוב על ההתנהגות שלו עם השגיאה הבאה:

איך להפעיל אפליקציה מקורית?

כאשר autochk מופעל, רצף האתחול של תוכניות נקבע לפי הערך של מפתח הרישום:

HKLMSystemCurrentControlSetControlSession ManagerBootExecute

מנהל הפגישות מבצע תוכניות מרשימה זו אחת אחת. מנהל הפגישות מחפש את קבצי ההפעלה עצמם בספריית system32. פורמט ערך מפתח הרישום הוא כדלקמן:

autocheck autochk *MyNative

הערך חייב להיות בפורמט הקסדצימלי, לא ב-ASCII הרגיל, כך שהמפתח המוצג לעיל יהיה בפורמט:

61,75,74,6f,63,68,65,63,6b,20,61,75,74,6f,63,68,6b,20,2a,00,4d,79,4e,61,74,69,76,65,00,00

כדי להמיר את הכותרת, אתה יכול להשתמש בשירות מקוון, למשל, זה.

מסתבר שכדי להשיק אפליקציה מקורית, אנחנו צריכים:

1. העתק את קובץ ההפעלה לתיקיית system32
2. הוסף מפתח לרישום
3. הפעל מחדש את המכונה

מטעמי נוחות, הנה סקריפט מוכן להתקנת אפליקציה מקורית:

install.bat

@echo off
copy MyNative.exe %systemroot%system32.
regedit /s add.reg
echo Native Example Installed
pause

add.reg

REGEDIT4

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Manager]
"BootExecute"=hex(7):61,75,74,6f,63,68,65,63,6b,20,61,75,74,6f,63,68,6b,20,2a,00,4d,79,4e,61,74,69,76,65,00,00

לאחר ההתקנה והאתחול מחדש, עוד לפני הופעת מסך בחירת המשתמש, נקבל את התמונה הבאה:

סך הכל

באמצעות הדוגמה של אפליקציה כל כך קטנה, השתכנענו שאפשר בהחלט להריץ את האפליקציה ברמת Windows Native. בשלב הבא, החבר'ה מאוניברסיטת איננופוליס ואני נמשיך לבנות שירות שיתחיל את תהליך האינטראקציה עם הנהג הרבה יותר מוקדם מאשר בגרסה הקודמת של הפרויקט שלנו. ועם הופעת מעטפת win32, זה יהיה הגיוני להעביר את השליטה לשירות מלא שכבר פותח (עוד על זה כאן).

במאמר הבא ניגע ברכיב נוסף של שירות Active Restore, כלומר מנהל ההתקן של UEFI. הירשמו לבלוג שלנו כדי שלא תפספסו את הפוסט הבא.

מקור: www.habr.com