Windows Native Applications ja teenus Acronis Active Restore

Täna jätkame rääkimist sellest, kuidas koos Innopolis Ülikooli noorte arendame Active Restore tehnoloogiat, et võimaldada kasutajal võimalikult kiiresti oma masinal tööle asuda pärast riket. Räägime Windowsi kohalikke rakendusi, sealhulgas nende loomise ja käivitamise eripäradest. Postituse all – natuke meie projektist ning praktiline juhend kohalike rakenduste kirjutamiseks.

Varasemates postitustes oleme juba rääkinud, mis see on Active Restore, ja kuidas Innopolis üliõpilased seda arendavad. teenusTäna soovin peatuda kohalikel rakendustel, millesse soovime „kaevata“ meie aktiivse taastamise teenust. Kui kõik õnnestub, siis suudame:

• Oluliselt varem käivitada teenuse
• Oluliselt varem ühenduda pilvega, kus asub varukoopia
• Oluliselt varem mõista, millises režiimis süsteem asub – tavaliselt käivitamisel või taastamisel
• Oluliselt vähem faile taastuda ette
• Katta kasutaja võimalikult kiiresti tööle asuda.

Mis üldse on kohalik rakendus?

Et sellele küsimusele vastata, vaatame järjestust, mille süsteem kutsub välja, näiteks siis, kui programmeerija üritab oma rakenduses faili luua.

Pavel Yosifovich — Windows Kernel Programming (2019)

Programmeerija kasutab funktsiooni CreateFile, mis on deklareeritud pealkirja failis fileapi.h ja rakendatud Kernel32.dll-is. Kuid see funktsioon ei loo faili, vaid kontrollib sisendi argumente ja kutsub välja funktsiooni NtCreateFile (Nt eesliide näitab, et funktsioon on kohaliku). See funktsioon on deklareeritud pealkirja failis winternl.h ja rakendatud ntdll.dll-is. See valmistab ette hüppe kerneli ruumi, seejärel kutsub välja süsteemikõne faili loomiseks. Sel juhul selgub, et Kernel32 on vaid Ntdll-i wrapper. Üks põhjus, miks see on tehtud, on see, et Microsoftil on võimalus muuta kohalike maailmade funktsioone, kuid samas mitte segada standardseid liideseid. Microsoft ei soovita otse kutsuda kohalikke funktsioone ega dokumenteeri enamikku neist. Muide, dokumenteerimata funktsioone on võimalik leida siit.

Peamine eelis natiivrakenduste puhul on see, et ntdll laaditakse süsteemi märgatavalt varem kui kernel32. See on mõistlik, kuna kernel32 vajab ntdll-i oma toimimiseks. Selle tulemusena saavad rakendused, mis kasutavad natiivseid funktsioone, alustada tööd märgatavalt varem.

Seega on Windowsi natiivrakendused programmid, mis suudavad käivituda Windowsi käivitamise varases etapis. Need kasutavad AINULT ntdll-i funktsioone. Sellise rakenduse näide: autochk mis täidab chkdisk utility kettaka vigade kontrollimiseks juba enne peamiste teenuste laadimist. Just sellisel tasemel tahame näha meie Active Restore'i.

Mida me vajame?

• DDK (Driver Development Kit), tuntud ka kui WDK 7 (Windows Driver Kit).
• Virtuaalne masin (näiteks Windows 7 x64)
• Ei ole kohustuslik, kuid võib aidata pealkirja faile, mida saab alla laadida siit

Mis on koodis?

Hakkame natuke harjutama ja kirjutame näiteks väikese rakenduse, mis:

1. Kuvab sõnumi ekraanile
2. Käivitab natuke mälu
3. Ootab sisendit klaviatuurilt
4. Vabastab hõivatud mälu

Natiivrakendustes on sisenemispunktiks mitte main ega winmain, vaid funktsioon NtProcessStartup, kuna me tegelikult käivitame uusi protsesse süsteemis otse.

Alustame ekraanile sõnumi kuvamisest. Selleks on meil natiivne funktsioon NtDisplayString, mis võtab argumentidena UNICODE_STRING struktuuri objekti näitaja. Selle initsialiseerimiseks aitab meid RtlInitUnicodeString. Tulemuseks, et teksti kuvamiseks ekraanil, saame 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 meile on saadaval ainult ntdll-i funktsioonid ja teisi teeke pole mälu veel, siis tekivad meil kindlasti probleemid mälu haldamisega. new operaatorit veel ei eksisteeri (sest see kuulub liiga kõrgema taseme C++ maailma), samuti ei ole funktsiooni malloc (selle jaoks on vajalikke runtime C teeke). Loomulikult võib kasutada ainult steeki. Kuid kui peame dünaamiliselt mälu haldama, tuleb seda teha kuhjast (tuntud ka kui heap). Seega loome endale kuhja ja võtame sellest mälu siis, kui seda vajame.

Selle ülesande jaoks sobib funktsioon RtlCreateHeap. Edasi liikudes kasutame RtlAllocateHeap ja RtlFreeHeap, et hallata mälu, kui meil seda vaja on.

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

// loome vahe mälu jaotamiseks hiljem
memory = RtlCreateHeap(
  HEAP_GROWABLE, 
  NULL, 
  1000, 
  0, NULL, NULL
);

// jaota buffer suurusega bufferSize
buffer = RtlAllocateHeap(
  memory, 
  HEAP_ZERO_MEMORY, 
  bufferSize
);

// vabasta buffer (tegelikult ei ole vajalik, kuna hävitage vahe järgmises etapis)
RtlFreeHeap(memory, 0, buffer);

RtlDestroyHeap(memory);

Liigume edasi ootama klaviatuuri sisendit.

// 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 meil on vaja – on kasutada NtReadFile avatud seadmes ja oodata, kuni klaviatuur tagastab meile mingi vajutuse. Kui vajutatakse klahvi ESC, jätkame tööd. Seadme avamiseks peame kutsuma funktsiooni NtCreateFile (avatakse DeviceKeyboardClass0). Samuti kutsume üles NtCreateEvent, et initsialiseerida ootamisobjekt. Me deklareerime ise KEYBOARD_INPUT_DATA struktuuri, mis esindab klaviatuuri andmeid. See lihtsustab meie tööd.

Natiivse rakenduse töö lõpeb funktsiooni kutsumisega NtTerminateProcess, kuna 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 võime koodis lihtsalt kasutada funktsiooni DbgBreakPoint() debugeerimise peatamiseks. Tõsi, tuleb WinDbg ühendada virtuaalmasinaga tuumadebugimiseks. Juhiseid, kuidas seda teha, saab leida siit või lihtsalt kasutada VirtualKD.

Kompileerimine ja kokkupanek

Kõige lihtsam viis natiivse rakenduse kokkupanekuks on kasutada DDK (Driver Development Kit). Me vajame just seda iidset seitsmendat versiooni, kuna hilisemad versioonid töötavad suuresti teistmoodi ja on tihedalt seotud Visual Studio’ga. Kui kasutada DDK-d, piisab meie projektist vaid Makefile’ist ja allikatest.

Makefile

!INCLUDE $(NTMAKEENV)makefile.def

allikad:

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 samasugune, allikatele peatume natuke rohkem. Selles failis näidatakse teie programmi allikaid (failid .c), kokkupaneku valikuid ja muid parameetreid.

• TARGETNAME – täidetava faili nimi, mis lõpuks peaks valmima.
• TARGETTYPE – täidetava faili tüüp, see võib olla draiver (.sys), siis peab väärtus olema DRIVER, kui teek (.lib), siis väärtus LIBRARY. Meie puhul on vajalik täidetav fail (.exe), seega seame väärtuseks PROGRAM.
• UMTYPE – selle välja võimalikke väärtusi: console konsooli rakenduse jaoks, windows aknarakenduse tööks. Kuid me peame määrama nt, et saada kohaliku rakenduse.
• BUFFER_OVERFLOW_CHECKS – ülevaatus mälustaki üleliigse täitmise kontrollimiseks, kahjuks ei ole see meie juhtum, lülitame välja.
• MINWIN_SDK_LIB_PATH – see väärtus viitab muutuja SDK_LIB_PATH, ei maksa muretseda, et sellist süsteemset muutujat ei ole deklareeritud, hetkel, kui käivitame checked build DDKst, see muutuja deklareeritakse ja osutab vajalikele raamatukogudele.
• SOURCES – teie programmi allikate nimekiri.
• INCLUDES – päisefailid, mis on vajalikud kompileerimiseks. Siin tavaliselt määratakse tee failidele, mis tulevad koos DDKga, kuid saate lisada ka teised.
• TARGETLIBS – raamatukogude nimekiri, mida tuleb linkida.
• USE_NTDLL – kohustuslik väljad, mis tuleb seada väärtusele 1. Ilmselgetel põhjustel.
• USER_C_FLAGS – kõik lipud, mida saate kasutada eelprotsessorite suunistes rakenduse koodi ettevalmistamisel.

Kokkuvõttes, et kompileerida, peame käivitama x86 (või x64) Checked Build, muutma töökausta projekti kaustaks ja käivitama Build käsu. Tulemus ekraanil näitab, et meil on kogutud üks täitmisfail.

Seda faili ei saa lihtsalt käivitada, süsteem nuriseb ja saadab meid mõtlema oma käitumise järgmise veaga:

Kuidas käivitada kohalikku rakendust?

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

HKLMSystemCurrentControlSetControlSession ManagerBootExecute

Seansi haldur käivitab järjekorras programme sellest nimekirjast. Isegi täidetavaid faile otsib seansi haldur direktoriumist system32. Registri võtme väärtuse formaat on järgmine:

autocheck autochk *MyNative

Väärtus peab olema kuuesajandilisel kujul, mitte tavalises ASCII formaadis, seega saab ülaltoodud võti järgmise formaadi:

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 konverteerimiseks saate kasutada veebiteenust, näiteks, see.

Tuleb välja, et kohalikku rakendust käivitamiseks on meil vajalik:

1. Kopeerida täitmisfail kausta system32
2. Lisada registrisse võti
3. Taaskäivitada masin

Mugavuse huvides on siin valmis skript kohaliku rakenduse installimiseks:

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

Pärast installimist ja taaskäivitamist, enne kasutajakonto valimise ekraani, näeme järgmiseid tulemusi:

Kokkuvõte

Selle väikses rakenduses oleme veendunud, et rakenduse käivitamine Windows Native tasemel on täiesti võimalik. Edasi koos Innopolis Ülikooli tiimiga ehitame teenust, mis algatab suhtlemisprotsessi draiveriga palju varem kui meie projekti eelmine versioon. Ja pärast win32 liidese ilmumist on mõistlik anda juhtimine juba välja töötatud täisfunktsionaalsesse teenusesse (sellega tutvume lähemalt siin).

Järgmises artiklis käsitleme veel ühte Active Restore teenuse komponenti, nimelt UEFI draiverit. Jälgige meie blogi, et mitte jääda ilma järgmistest postitustest.

Allikas: habr.com