Windows ネイティブ アプリケーションと Acronis Active Restore サービス

今日は、イノポリス大学の人々と協力して、ユーザーが障害発生後にできるだけ早くマシンで作業を開始できるようにするアクティブ リストア テクノロジをどのように開発しているかについての話を続けます。 ネイティブ Windows アプリケーションについて、その作成と起動の機能を含めて説明します。 その下には、私たちのプロジェクトについて少し説明するとともに、ネイティブ アプリケーションの作成方法に関する実践的なガイドを示します。

以前の投稿で、それが何であるかについてすでに説明しました アクティブリストア、イノポリスの学生がどのように成長するか サービス。 今日は、ネイティブ アプリケーションに焦点を当てたいと思います。これは、アクティブな回復サービスを「埋める」レベルまでです。 すべてがうまくいけば、次のことができるようになります。

• サービス自体をもっと早く立ち上げる
• かなり早い段階でバックアップが保存されているクラウドに連絡します。
• システムが通常のブートまたはリカバリのどのモードにあるかをより早い段階で理解する
• 事前にリカバリする必要のあるファイルがはるかに少なくなります
• ユーザーがさらに早く始められるようにします。

そもそもネイティブアプリとは何でしょうか？

この質問に答えるために、たとえばアプリケーションのプログラマがファイルを作成しようとした場合に、システムが行う一連の呼び出しを見てみましょう。

Pavel Yosifovich - Windows カーネル プログラミング (2019)

プログラマは関数を使用します CreateFile、ヘッダー ファイル fileapi.h で宣言され、Kernel32.dll で実装されます。 ただし、この関数自体はファイルを作成せず、入力引数をチェックして関数を呼び出すだけです。 NtCreateFile (接頭辞 Nt は、関数がネイティブであることを示しているだけです)。 この関数は、Winternl.h ヘッダー ファイルで宣言され、ntdll.dll に実装されます。 核空間に飛び込む準備をした後、システムコールを呼び出してファイルを作成します。 この場合、Kernel32 は Ntdll の単なるラッパーであることがわかります。 これが行われた理由の XNUMX つは、Microsoft がネイティブ世界の機能を変更する能力を持っているが、標準インターフェイスには手を加えないことです。 Microsoft はネイティブ関数を直接呼び出すことを推奨しておらず、そのほとんどについては文書化していません。 ちなみに、文書化されていない関数も見つかります ここで.

ネイティブ アプリケーションの主な利点は、ntdll が kernel32 よりもはるかに早くシステムにロードされることです。 kernel32 が動作するには ntdll が必要であるため、これは論理的です。 その結果、ネイティブ関数を使用するアプリケーションは、より早く動作を開始できるようになります。

したがって、Windows ネイティブ アプリケーションは、Windows 起動の早い段階で開始できるプログラムです。 ntdll の関数のみを使用します。 そのようなアプリケーションの例: オートチェック 誰が演じるのか chkdiskユーティリティ メインサービスを開始する前にディスクのエラーをチェックします。 これはまさに私たちがアクティブ リストアに望むレベルです。

何が必要ですか？

• DDK (ドライバー開発キット)、現在は WDK 7 (Windows ドライバー キット) としても知られています。
• 仮想マシン (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 ライブラリが必要です)。 もちろん、スタックのみを使用することもできます。 ただし、メモリを動的に割り当てる必要がある場合は、ヒープ (つまりヒープ) 上で行う必要があります。 そこで、自分用のヒープを作成し、必要なときにいつでもそこからメモリを取り出してみましょう。

この機能はこのタスクに適しています RtlCreateヒープ。 次に、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 構造体を自分で宣言します。 これで私たちの仕事が楽になります。

ネイティブ アプリケーションは関数呼び出しで終了します NtTerminateプロセスなぜなら、単に自分自身のプロセスを強制終了しているだけだからです。

私たちの小さなアプリケーションのすべてのコード:

#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 (ドライバー開発キット)。 それ以降のバージョンではアプローチが若干異なり、Visual Studio と密接に連携するため、古代の XNUMX 番目のバージョンが必要です。 DDK を使用する場合、プロジェクトに必要なのは 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 – このフィールドに指定できる値: コンソール アプリケーションの場合は console、ウィンドウ モードで動作する場合は windows。 ただし、ネイティブ アプリケーションを取得するには nt を指定する必要があります。
• BUFFER_OVERFLOW_CHECKS – スタックのバッファ オーバーフローをチェックします。残念ながら今回の場合はそうではなく、オフにします。
• MINWIN_SDK_LIB_PATH – この値は SDK_LIB_PATH 変数を参照します。そのようなシステム変数が宣言されていないことを心配する必要はありません。DDK からチェック ビルドを実行すると、この変数が宣言され、必要なライブラリを指します。
• SOURCES – プログラムのソースのリスト。
• INCLUDES – アセンブリに必要なヘッダー ファイル。 ここでは通常、DDK に付属するファイルへのパスを示しますが、その他のパスを追加で指定することもできます。
• TARGETLIBS – リンクする必要があるライブラリのリスト。
• USE_NTDLL は必須フィールドであり、明らかな理由から 1 に設定する必要があります。
• USER_C_FLAGS – アプリケーション コードを準備するときにプリプロセッサ ディレクティブで使用できるフラグ。

したがって、ビルドするには、x86 (または x64) Checked Build を実行し、作業ディレクトリをプロジェクト フォルダーに変更して、Build コマンドを実行する必要があります。 スクリーンショットの結果は、実行可能ファイルが XNUMX つあることを示しています。

このファイルはそう簡単には起動できないため、システムは次のエラーを表示してその動作について考えるように指示します。

ネイティブ アプリケーションを起動するにはどうすればよいですか?

autochk が開始されるとき、プログラムの起動順序はレジストリ キーの値によって決まります。

HKLMSystemCurrentControlSetControlSession ManagerBootExecute

セッション マネージャーは、このリストにあるプログラムを 32 つずつ実行します。 セッション マネージャーは、systemXNUMX ディレクトリで実行可能ファイル自体を探します。 レジストリ キー値の形式は次のとおりです。

autocheck autochk *MyNative

値は通常の ASCII ではなく XNUMX 進形式である必要があるため、上記のキーは次の形式になります。

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

追加登録

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 ネイティブ レベルで実行することがかなり可能であると確信しました。 次に、イノポリス大学のスタッフと私は、プロジェクトの前のバージョンよりもはるかに早くドライバーとの対話プロセスを開始するサービスの構築を続けます。 そして、win32 シェルの出現により、すでに開発されている本格的なサービスに制御を移すのが論理的です (詳細はこちら) ここで).

次の記事では、Active Restore サービスの別のコンポーネント、つまり UEFI ドライバーについて触れます。 次の投稿を見逃さないように、ブログを購読してください。

出所： habr.com