Windowsi natiivrakendused ja Acronis Active Restore teenus

Täna jätkame juttu sellest, kuidas koos Innopolis Ülikooli poistega arendame Active Restore tehnoloogiat, et lubada kasutajal alustada oma masinal tööle naasmist võimalikult kiiresti pärast riket. Jutuks on natiivrakendused Windowsis, sealhulgas nende loomise ja käitamise eripära. Allpool on natuke meie projektist ning praktiline juhend, kuidas kirjutada natiivrakendusi.

Eelmistes postitustes oleme juba rääkinud, mis on Active Restore, ja kuidas Innopolis Ülikooli tudengid seda arendavad teenus. Täna tahan peatuda natiivrakendustel, mille tasemeni soovime meie aktiivse taastamise teenuse „kaevata“. Kui kõik läheb hästi, siis suudame:

• Käivitada teenuse palju varem
• Suhtuda pilvega, kus varukoopia asub, palju varem
• Mõista, millises režiimis süsteem on – normaalse käivitamise või taastamise režiimis, palju varem
• Taastada palju vähem faile eelnevalt
• Lubada kasutajal alustada tööd veelgi kiiremini.

Mis on üldse natiivne rakendus?

Küsimusele vastamiseks vaatame süsteemi väljakutseid, näiteks kui programmeerija üritab oma rakenduses faili luua.

Pavel Yosifovich — Windows Kernel Programming (2019)

Programmeerija kasutab funktsiooni CreateFile, mis on deklareeritud pealkirjafailis fileapi.h ja rakendatud Kernel32.dll-is. Siiski ei tegele see funktsioon failide loomisega, see vaid kontrollib sisendi argumendid ja kutsub välja funktsiooni NtCreateFile (Nt-silt näitab, et funktsioon on natiivne). See funktsioon on deklareeritud pealkirjafailis winternl.h ja rakendatud ntdll.dll-is. See valmistab ette hüppe tuumaruumi ja teeb seejärel süsteemi väljakutse faili loomiseks. Seega on Kernel32 lihtsalt Ntdll'i mähis. Üks põhjusi, miks see nii on tehtud, on see, et Microsoft saab sel viisil natiivsete maailmade funktsioone muuta, ilma et nad puutuksid tavalisi liideseid. Microsoft ei soovita otse kutsuda esile natiivsete funktsioonide ja ei dokumenteeri enamikku neist. Muide, dokumenteerimata funktsioone võib leida siin.

Põhiline eelis natiivsete rakenduste puhul on see, et ntdll laaditakse süsteemi palju varem kui kernel32. See on loogiline, sest kernel32 vajab ntdll-i oma tööks. Seetõttu saavad rakendused, mis kasutavad natiivseid funktsioone, alustada tööle asumist märkimisväärselt varem.

Seega on Windowsi natiivsed rakendused programmid, mis suudavad käivituda Windowsi laadimise varajases staadiumis. Need kasutavad AINULT funktsioone ntdll-ist. Näide sellisest rakendusest: autochk mis käivitab chkdisk utility kettavead kontrollimiseks juba enne põhiteenuste käivitamist. Just sellisel tasemel soovime näha meie Active Restore'i.

Mida me vajame?

• DDK (Driver Development Kit), tuntud ka kui WDK 7 (Windows Driver Kit).
• Virtuaalne masin (nt Windows 7 x64)
• Ei ole kohustuslik, kuid päisefailid võivad olla kasulikud ja neid saab alla laadida siin

Mis on koodis?

Harjutame veidi ja kirjutame näitena väikese rakenduse, mis:

1. Kuvab ekraanile sõnum
2. Allocateerib natuke mälu
3. Ootab sisestust klaviatuurilt
4. Vabastab reserveeritud mälu

Natiivsetes rakendustes on sisenemiskoht mitte main või winmain, vaid funktsioon NtProcessStartup, kuna me käivitame uusi protsesse süsteemis otse.

Alustame sõnumi ekraanile kuvamisest. Selleks on meil natiivne funktsioon NtDisplayString, mis võtab argumendiks UNICODE_STRING struktuuri objekti näidiku. Selle algatamiseks aitab meid RtlInitUnicodeString. Seetõttu saame teksti ekraanile kuvamiseks kirjutada sellise väikese funktsiooni:

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

Kuna meil on juurdepääs ainult ntdll funktsioonidele ja teised teegid ei ole mälus veel olemas, tekivad meil kindlasti probleemid mälu eraldamisega. Operaatoreid new veel ei eksisteeri (sest see pärineb liiga kõrgetasemelisest C++ maailmast), samuti ei ole funktsiooni malloc (selle jaoks on vajalikud C runtime teegid). Loomulikult saame kasutada ainult virna. Kuid kui peame dünaamiliselt mälu eraldama, peab seda tegema kuhjas. Seega loome endale kuhja ja võtame sealt mälu, kui meil on seda vaja.

Selle ülesande jaoks sobib funktsioon RtlCreateHeap. Jätkame RtlAllocateHeap'i ja RtlFreeHeap'i kasutamisega, et mälu kasutada ja vabastada, kui me seda vajame.

PVOID mälu = NULL;
PVOID puhver = NULL;
ULONG puhverSuurus = 42;

// loome kuhja, et hiljem mälu eraldada
mälu = RtlCreateHeap(
  HEAP_GROWABLE, 
  NULL, 
  1000, 
  0, NULL, NULL
);

// eraldame puhversuuruse suitset
puhver = RtlAllocateHeap(
  mälu, 
  HEAP_ZERO_MEMORY, 
  puhverSuurus
);

// vabastame puhvri (tegelikult pole vajalik, sest hävitame kuhja järgmises etapis)
RtlFreeHeap(mälu, 0, puhver);

RtlDestroyHeap(mälu);

Liigume edasi klaviatuuri sisendi ootamise juurde.

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

Kõik, mida vajame, on kasutada NtReadFile avatud seadmes ning oodata, kuni klaviatuur tagastab meile mõne näppimise. Kui klahvi ESC vajutatakse, jätkame tööd. Seadme avamiseks peame kutsuma funktsiooni NtCreateFile (avama peab DeviceKeyboardClass0). Samuti kutsume üles NtCreateEvent, et algatada objekti ootamiseks. Me kuulutame iseseisvalt välja KEYBOARD_INPUT_DATA struktuuri, mis esindab klaviatuuri andmeid. See lihtsustab meie tööd.

Natiivrakenduse töö lõppeb funktsiooni NtTerminateProcess, kutsub üles, sest me lihtsalt tapame oma protsessi.

Kogu meie väikese rakenduse kood:

#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: Me saame koodis hõlpsasti kasutada DbgBreakPoint() funktsiooni, et peatuda silurisse. Kuid peame ühendama WinDbg virtuaalmasinaga tuumadebüügiks. Juhiseid selle tegemiseks leiate siin või lihtsalt kasutada VirtualKD.

Kompileerimine ja kogumine

Lihtsaim viis natiivrakenduse loomiseks on kasutada DDK (Driver Development Kit). Me vajame just vanimat seitsmenda versiooni, kuna hilisemad versioonid on natuke teistsugused ja töötavad tihedalt koos Visual Studio'ga. Kui aga kasutada DDK-d, siis vajab meie projekt lihtsalt Makefile'i ja 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

Teie Makefile on täpselt sama, kuid peatume sources'i juures natuke rohkem. Selles failis määratakse teie programmi lähtekood (failid .c), kogumise valikud ja muud parameetrid.

• TARGETNAME – täpselt see, mis peab olema lõpptulemuseks saadud täidetav fail.
• TARGETTYPE – täitmisfaili tüüp, see võib olla draiver (.sys), siis peab välja väärtus olema DRIVER, kui teek (.lib), siis väärtus LIBRARY. Meie juhul on vajalik täitmisfail (.exe), seega seadistame väärtuse PROGRAM.
• UMTYPE – selle välja võimalikud väärtused: console konsoolirakenduse jaoks, windows kas WINDOWS-ENV -le. Kuid peame määrama nt, et saada natiivne rakendus.
• BUFFER_OVERFLOW_CHECKS – virna ülevoolu kontroll, kahjuks ei ole see meie juhtum, lülitame välja.
• MINWIN_SDK_LIB_PATH – see väärtus viitab muutuja SDK_LIB_PATH, ei tasu muretseda, et teil ei ole sellist süsteemimuutujat deklareeritud, hetkel, kui käivitame checked build DDK-st, deklareeritakse see muutuja ja viitab vajalikele raamatukogudele.
• SOURCES – nimekiri teie programmi lähtekoodidest.
• INCLUDES – päised, mis on vajalikud kompileerimiseks. Siin tavaliselt määratakse tee failidele, mis tulevad koos DDK-ga, kuid võite lisada ka muid.
• TARGETLIBS – nimekiri raamatukogudest, mis tuleb siduda.
• USE_NTDLL – kohustuslik väli, mis tuleb seada väärtusele 1. Sellel on ilmselged põhjused.
• USER_C_FLAGS – kõik lipud, mida saab kasutada eeltöötlusdirektiivides rakenduse koodi ettevalmistamisel.

Seega, et koostada, peame käivitama x86 (või x64) Checked Build, muutma töökausta projekti kaustaks ja täitma Build käsu. Tulemuses, mis on ekraanipildil, on näha, et meil on loodud üks käivitatav fail.

Seda faili ei saa lihtsalt käivitada, süsteem teavitab meid ja saadab arvama järgmise veateate:

Kuidas käivitada natiivset rakendust?

Käivitamise hetkel määrab autochk programmi käivitamise järjekorra registri võtme väärtus:

HKLMSystemCurrentControlSetControlSession ManagerBootExecute

Seansi haldur käivitab programmid järjestikku sellest loendist. Käivitatavad failid otsitakse seansi halduri poolt kaustast system32. Registri võtme väärtuse formaat on järgmine:

autocheck autochk *MyNative

Väärtus peab olema kuuekümnendformaadis, mitte tavalises ASCII-s, seetõttu on ülaltoodud võtme formaat:

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

Nime konvertimiseks võite kasutada veebiteenust, näiteks seda.

Kokkuvõttes, et käivitada natiivne rakendus, peame me:

1. Kopeerima käivitatava faili kausta system32
2. Lisama registrisse võtme
3. Taaskäivitage masin

Kasutamiseks on siin valmis skript natiivse rakenduse installimiseks:

install.bat

@echo off
copy MyNative.exe %systemroot%system32.
regedit /s add.reg
echo Natiivne näidis installitud
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

Pärast installimist ja taaskäivitamist, enne kasutajate valimisekraani ilmumist, näeme järgmisi pilte:

Kokkuvõte

Selle väikese rakenduse näitel oleme veendunud, et natiivse rakenduse käivitamine Windowsi tasemel on täiesti võimalik. Jätkame koos Innopolis Ülikooli meestega teenuse loomist, mis algatab suhtlemisprotsessi draiveriga palju varem kui meie projekti eelmine versioon. Ja koos win32 keskustega on mõistlik juhtimise andmine täieliku teenuse arendamiseks, mis oli juba välja töötatud (selle kohta rohkem) siit).

Järgmises artiklis käsitleme veel ühte Active Restore'i teenuse komponenti, nimelt UEFI draivereid. Jälgige meie blogi, et mitte jääda ilma järgmisest postitusest.

Allikas: habr.com