Windows Native Applications och tjänsten Acronis Active Restore.

Idag fortsätter vi berättelsen om hur vi tillsammans med killarna från Innopolis universitet utvecklar teknologin Active Restore för att låta användaren börja arbeta på sin maskin så tidigt som möjligt efter ett fel. Det handlar om inhemska Windows-appar, inklusive egenskaperna för deras skapande och lansering. Under tryck – lite om vårt projekt samt en praktisk guide för hur man skriver inhemska appar.

I tidigare inlägg har vi redan berättat om vad Active Restoreär, och hur studenter från Innopolis utvecklar tjänst. Idag vill jag fokusera på inhemska appar, till den nivå vi vill "gräva ner" vår aktiva återställningstjänst. Om allt går som planerat, kan vi:

• Starta tjänsten mycket tidigare
• Kontakta molnet där backupen ligger mycket tidigare
• Förstå mycket tidigare vilket läge systemet befinner sig i – normalt läge eller återställningsläge
• Återställa mycket färre filer i förväg
• Låta användaren börja arbeta ännu snabbare.

Vad är egentligen en inhemsk app?

För att svara på denna fråga, låt oss titta på sekvensen av anrop som systemet gör, till exempel när en programmerare i sin app försöker skapa en fil.

Pavel Yosifovich — Windows Kernel Programming (2019)

Programmeraren använder funktionen CreateFile, som deklareras i header-filen fileapi.h och implementeras i Kernel32.dll. Men själva denna funktion sysslar inte med att skapa en fil, den kontrollerar bara argumenten in och anropar funktionen NtCreateFile (prefixet Nt indikerar just att funktionen är inhemsk). Denna funktion är deklarerad i header-filen winternl.h och implementeras i ntdll.dll. Den förbereder för hoppet in i kärnrymden, efter vilket den gör ett systemanrop för att skapa filen. I detta fall är Kernel32 bara en wrapper för Ntdll. En av anledningarna till varför detta görs är att Microsoft på så sätt kan ändra funktioner i den inhemska världen utan att röra de standardiserade gränssnitten. Microsoft rekommenderar inte att man anropar inhemska funktioner direkt och dokumenterar inte merparten av dem. För övrigt kan man hitta odokumenterade funktioner. ). Ett typiskt exempel på användning:.

Den största fördelen med inhemska applikationer är att ntdll laddas in i systemet betydligt tidigare än kernel32. Det är logiskt, eftersom kernel32 behöver ntdll för att fungera. Som en följd av detta kan applikationer som använder inhemska funktioner börja arbeta betydligt tidigare.

Således är Windows Native Applications program som kan starta i ett tidigt skede av Windows-laddningen. De använder ENDAST funktioner från ntdll. Ett exempel på en sådan applikation: autochk som kör chkdisk utility för att kontrollera disken för fel redan innan de huvudtjänsterna startar. På denna nivå vill vi verkligen se vår Active Restore.

Vad behöver vi?

• DDK (Driver Development Kit), numera även känt som WDK 7 (Windows Driver Kit).
• En virtuell maskin (till exempel Windows 7 x64)
• Även om det inte är nödvändigt kan headerfiler som kan laddas ner vara till hjälp ). Ett typiskt exempel på användning:

Vad sägs om koden?

Låt oss träna lite och som exempel skriva en liten applikation som:

1. Visar ett meddelande på skärmen
2. Allokerar lite minne
3. Väntar på tangentbordsinmatning
4. Frigör det upptagna minnet

I inhemska applikationer är inte ingångspunkten main eller winmain, utan funktionen NtProcessStartup, eftersom vi faktiskt startar nya processer direkt i systemet.

Låt oss börja med att visa ett meddelande på skärmen. För detta har vi en inhemsk funktion NtDisplayString, som tar en pekare till ett objekt av strukturen UNICODE_STRING som argument. Vi kan hjälpa till att initiera det med RtlInitUnicodeString. Därför kan vi skriva en liten funktion för att visa text på skärmen:

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

Eftersom vi endast har tillgång till funktioner från ntdll, och inga andra bibliotek finns i minnet, kommer vi troligtvis att stöta på problem med att allokera minne. Operatören new existerar ännu inte (eftersom den kommer från en alltför hög nivå i C++), och det finns inte heller någon malloc-funktion (som kräver C-löptider). Vi kan förstås bara använda stacken. Men om vi behöver dynamiskt allokera minne måste vi göra det i heapen. Därför låt oss skapa en heap för oss själva och ta minne därifrån när vi behöver.

För denna uppgift passar funktionen RtlCreateHeap. Därefter, med hjälp av RtlAllocateHeap och RtlFreeHeap, kommer vi att använda och frigöra minnage när vi behöver det.

PVOID minne = NULL;
PVOID buffert = NULL;
ULONG buffertStorlek = 42;

// skapa heap för att senare allokera minne
minne = RtlCreateHeap(
  HEAP_GROWABLE,
  NULL,
  1000,
  0, NULL, NULL
);

// allokera buffert av storlek buffertStorlek
buffert = RtlAllocateHeap(
  minne,
  HEAP_ZERO_MEMORY,
  buffertStorlek
);

// frigöra buffert (egentligen inte nödvändigt eftersom vi förstör heapen i nästa steg)
RtlFreeHeap(minne, 0, buffert);

RtlDestroyHeap(minne);

Låt oss gå vidare till att vänta på inmatning från tangentbordet.

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

Allt vi behöver göra är att använda NtReadFile på den öppna enheten och vänta tills tangentbordet returnerar ett tangenttryck. Om ESC-tangenten trycks ned, fortsätter vi arbetet. För att öppna enheten behöver vi kalla på funktionen NtCreateFile (vi måste öppna DeviceKeyboardClass0). Vi kommer också att kalla på NtCreateEvent, för att initiera ett objekt för väntan. Vi kommer att deklarera strukturen KEYBOARD_INPUT_DATA, som representerar tangentbordsdata. Detta kommer att underlätta vårt arbete.

En nativen applikation avslutas med att kalla på funktionen NtTerminateProcess, eftersom vi helt enkelt dödar vår egen process.

Hela koden för vår lilla applikation:

#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: Vi kan enkelt använda funktionen DbgBreakPoint() i koden för att stanna i debuggan. Men vi behöver koppla WinDbg till den virtuella maskinen för kernel-debugging. Instruktioner om hur man gör detta finns ). Ett typiskt exempel på användning: eller helt enkelt använda VirtualKD.

Kompilering och byggande

Det enklaste sättet att bygga en nativen applikation är att använda DDK (Driver Development Kit). Vi behöver just den äldre sjunde versionen, eftersom senare versioner har en något annan metod och arbetar nära med Visual Studio. Om vi använder DDK, behövs endast Makefile och sources för vårt projekt.

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

Din Makefile kommer att vara exakt likadan, låt oss stanna lite längre vid sources. I den här filen anges källorna till ditt program (filer .c), byggalternativ och andra parametrar.

• TARGETNAME – namnet på den körbara filen som ska skapas i slutändan.
• TARGETTYPE – typen av körbar fil, detta kan vara en drivrutin (.sys), då bör värdet vara DRIVER, om det är ett bibliotek (.lib), så ska värdet LIBRARY. I vårt fall behövs en körbar fil (.exe), så vi sätter värdet PROGRAM.
• UMTYPE – möjliga värden för detta fält: console för konsolapplikation, windows för arbete i fönsterläge. Men vi behöver ange nt för att få en inbyggd applikation.
• BUFFER_OVERFLOW_CHECKS – kontroll av stacken för buffertöverskridning, tyvärr är det inte vårt fall, vi stänger av detta.
• MINWIN_SDK_LIB_PATH – detta värde hänvisar till variabeln SDK_LIB_PATH, det är ingen anledning att oroa sig för att ni inte har sådan systemvariabel deklarerad, vid den tidpunkt vi kör checked build från DDK, kommer denna variabel att deklareras och peka på nödvändiga bibliotek.
• SOURCES – lista över källor för ditt program.
• INCLUDES – headerfiler som behövs för att bygga. Här anger man vanligtvis sökvägen till filer som följer med DDK, men du kan också ange andra.
• TARGETLIBS – lista över bibliotek som behöver länkas.
• USE_NTDLL – obligatoriskt fält som måste ställas in till 1. Av uppenbara skäl.
• USER_C_FLAGS – alla flaggor som du kan använda i preprocessordirektiv vid förberedelse av programkoden.

Så för att bygga behöver vi starta x86 (eller x64) Checked Build, byta arbetskatalog till mappen med projektet och utföra kommandot Build. Resultatet i skärmdumpen visar att vi har samlat en körbar fil.

Denna fil går inte att köra så enkelt, systemet klagar och skickar oss att tänka på sitt beteende med följande felmeddelande:

Hur kör man en inbyggd applikation?

Vid start av autochk bestäms sekvensen för programstart av värdet i registreringsnyckeln:

HKLMSystemCurrentControlSetControlSession ManagerBootExecute

Sessionshanteraren kör program från denna lista i ordning. Själva programfilerna letar sessionshanteraren efter i katalogen system32. Formatet för värdet av registreringsnyckeln är följande:

autocheck autochk *MyNative

Värdet måste vara i hexadecimalt format, inte i det vanliga ASCII, därmed kommer nyckeln ovan att ha formatet:

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

För att konvertera namnet kan man använda en online-tjänst, till exempel, det här.

Så för att köra en inbyggd applikation behövs:

1. Kopiera den körbara filen till mappen system32
2. Lägg till en nyckel i registret
3. Starta om maskinen

För bekvämlighetens skull har jag här ett färdigt skript för att installera den inbyggda applikationen:

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

Efter installationen och omstarten, innan användarvals skärmen dyker upp, kommer vi att se följande bild:

Resultat

Med hjälp av en så liten applikation har vi visat att det är fullt möjligt att köra en applikation på Windows Native-nivå. Härnäst kommer vi, tillsammans med killarna från Innopolis universitet, att fortsätta bygga en tjänst som initierar interaktionen med drivrutinen mycket tidigare än i den tidigare versionen av vårt projekt. Med introduktionen av win32-gränssnittet kommer det logiskt att överlämna kontrollen till en fullfjädrad tjänst som redan har utvecklats (mer om detta längre fram) här).

I nästa artikel kommer vi att ta upp en annan komponent av Active Restore-tjänsten, nämligen UEFI-drivrutinen. Prenumerera på vår blogg för att inte missa nästa inlägg.

Källa: habr.com