Нативни приложения за Windows и услуга Acronis Active Restore

Днес продължаваме разказа за това как заедно с момчетата от Университета Иннополис разработваме технологията Active Restore, за да позволим на потребителите да започнат работа на своите устройства възможно най-рано след срив. Темата ще бъде нативни Windows приложения, включително характеристиките на тяхното създаване и стартиране. Под статията - малко информация за нашия проект, а също и практическо ръководство как да пишете нативни приложения.

В предишни статии вече обсъждахме какво е Active Restore, и как студентите от Иннополис го разработват. услугаДнес искам да се спра на нативните приложения, до нивото на които искаме да 'погребем' нашия сервиз за активно възстановяване. Ако всичко върви по план, ще можем да:

• Започнем самия сервис много по-рано
• Свържем се с облака, където се съхранява резервната копия, много по-рано
• Разберем в какъв режим е системата – нормално стартиране или възстановяване, много по-рано
• Възстановяваме много по-малко файлове предварително
• Позволим на потребителя да започне работа още по-бързо.

Какво всъщност е нативно приложение?

За да отговорим на този въпрос, нека погледнем поредицата от извиквания, които системата прави, когато програмистът в приложението си опитва да създаде файл.

Pavel Yosifovich — Windows Kernel Programming (2019)

Програмистът използва функцията CreateFile, която е обявена в заглавния файл fileapi.h и реализирана в Kernel32.dll. Но самата тази функция не създава файла, а само проверява аргументите на входа и извиква функцията NtCreateFile (представката Nt показва, че функцията е нативна). Тази функция е обявена в заглавния файл winternl.h и реализирана в ntdll.dll. Тя подготвя прехвърлянето в ядрено пространство, след което извършва системен повик за създаване на файл. В този случай се оказва, че Kernel32 всъщност е само обвивка за Ntdll. Една от причините за това е, че по този начин Microsoft може да променя функциите на нативния свят, без да засяга стандартните интерфейси. Microsoft не препоръчва директно извикване на нативни функции и не документира голяма част от тях. Между другото, недокументираните функции могат да бъдат намерени тук.

Основното предимство на нативните приложения е, че ntdll се зарежда в системата значително по-рано от kernel32. Това е логично, тъй като kernel32 изисква наличието на ntdll за работа. В резултат, приложенията, които използват нативни функции, могат да започнат работа значително по-рано.

Така Windows Native Applications са програми, способни да се стартират в ранния етап на зареждане на Windows. Те използват САМО функции от ntdll. Пример за такова приложение: autochk което изпълнява chkdisk utility за проверка на диска за грешки още преди стартирането на основните услуги. Именно на такова ниво искаме да видим нашия Active Restore.

Какво ще ни трябва?

• DDK (Driver Development Kit), сега известно и като WDK 7 (Windows Driver Kit).
• Виртуална машина (например, Windows 7 x64)
• Не е задължително, но може да помогне, заглавните файлове които могат да бъдат изтеглени тук

Какво става в кода?

Нека да направим малко упражнение и за пример да напишем малко приложение, което:

1. Извежда съобщение на екрана
2. Аллоцира малко памет
3. Очаква вход от клавиатурата
4. Освобождава заета памет

В нативните приложения точката на вход е не main или 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, а други библиотеки в паметта просто все още няма, непременно ще възникнат проблеми с алокацията на памет. Операторът new все още не съществува (тъй като е от твърде високо ниво в света на C++), също така няма функция malloc (тъй като за нея са нужни библиотеки от C runtime). Разбира се, можем да използваме само стека. Но ако ни трябва динамично алокиране на памет, ще трябва да го правим в купа (т.е. heap). Затова нека създадем купа за себе си и да взимаме памет от нея, когато ни е необходима.

За тази задача подхожда функцията RtlCreateHeap. След това, използвайки RtlAllocateHeap и RtlFreeHeap, ще задвижваме и освобождаваме памет, когато ни е необходимо.

PVOID памет = NULL;
PVOID буфер = NULL;
ULONG размерНаБуфер = 42;

// създаване на купчина, за да се задели памет по-късно
памет = RtlCreateHeap(
  HEAP_GROWABLE, 
  NULL, 
  1000, 
  0, NULL, NULL
);

// заделяне на буфер с размер размерНаБуфер
буфер = RtlAllocateHeap(
  памет, 
  HEAP_ZERO_MEMORY, 
  размерНаБуфер
);

// освобождаване на буфера (всъщност не е необходимо, защото унищожаваме купчината на следващата стъпка)
RtlFreeHeap(памет, 0, буфер);

RtlDestroyHeap(памет);

Преминаваме към изчакване на въвеждане от клавиатурата.

// 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);
}

PS: Можем лесно да използваме в кода функцията DbgBreakPoint() за спиране в дебъгера. Вярно е, че ще трябва да свържем WinDbg с виртуалната машина за ядрен дебъгинг. Инструкция за това как да го направите можете да намерите тук или просто да използвате VirtualKD.

Компилация и сборка

Най-простият начин да съберем нативно приложение е да използваме DDK (Driver Development Kit). Нуждаем се именно от старата седма версия, тъй като по-късните версии имат малко по-различен подход и тесно работят с Visual Studio. Ако използваме DDK, то проектът ни се нуждае само от Makefile и sources.

Makefile

!INCLUDE $(NTMAKEENV)makefile.def

sources:

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 ще бъде точно такъв. Нека спрем малко по-подробно на sources. В този файл се посочват източниците на вашата програма (файлове .c), опции за компилация и други параметри.

• TARGETNAME – името на изпълнимия файл, който трябва да се получи в крайна сметка.
• TARGETTYPE – типът на изпълнимия файл, това може да бъде драйвер (.sys), тогава стойността на полето трябва да бъде DRIVER, ако е библиотека (.lib), стойността LIBRARY. В нашия случай ни е необходим изпълним файл (.exe), затова задаваме стойността PROGRAM.
• UMTYPE – възможни стойности на това поле: console за конзолно приложение, windows за работа в прозорчен режим. Но трябва да зададем nt, за да получим нативно приложение.
• BUFFER_OVERFLOW_CHECKS – проверка на стека за препълване на буфера, за съжаление това не е нашият случай, деактивираме.
• MINWIN_SDK_LIB_PATH – тази стойност сочи към променливата SDK_LIB_PATH, не се притеснявайте, че нямате такава системна променлива, когато стартираме checked build от DDK, тази променлива ще бъде обявена и ще сочи към необходимите библиотеки.
• SOURCES – списък с изходни кодове на вашата програма.
• INCLUDES – заглавни файлове, необходими за компилация. Тук обикновено се посочва пътя към файловете, които идват с DDK, но можете да добавите и всякакви други.
• TARGETLIBS – списък с библиотеки, които трябва да се свържат.
• USE_NTDLL – задължително поле, което трябва да се зададе на 1. По очевидни причини.
• USER_C_FLAGS – всякакви флагове, които можете да използвате в директивите на предпроцесора при подготовка на кода на приложението.

И така, за компилация ни е необходимо да стартираме x86 (или x64) Checked 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_MACHINE\SYSTEM\CurrentControlSet\Control\Session 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 драйвера. Абонирайте се за нашия блог, за да не пропуснете следващата публикация.

Източник: habr.com