🚴🏿 🏤 😍 C＃で仮想マシンを検出：レベル1 🏆 🉐 📯

1月の朝、友人から質問がどれほど涼しかったかという1つの恐怖-プログラムが仮想マシンのOS（Windows 7以降のウィンドウアプリケーション）で実行されているかどうかをC＃で判断する方法。

そのような検出器の要件は非常に厳しいものでした。

完全にソースコードである必要があります。
Visual Studioを使用して構築する必要があり、
権限のないユーザーのアカウントで動作するはずです（たとえば、デバイスドライバーのインストール、または管理者権限を必要とする他の操作を必要とする方法は使用できません）。
.NET Framework 4.5を使用でき、不要な依存関係（Visual C ++再頒布可能パッケージなど）は使用できません。

カットの下には、C＃で実装された検出器の説明（次のパートではC ++要素を使用）と、 Visual Studio 2015 Communityを使用したまともな量の不適切なコードがあります。

出版構造

第1レベル。材料と最も単純な既存のソリューションの研究：
- 仮想化に関するいくつかの理論、
- Windows Management Instrumentation（WMI）のデータを使用したVM検証の実装。
第2レベル。仮想マシンでの起動検出に関する記事と出版物を検索します。
- WMIで実装を完了します。
- CPUID命令を処理します。
第3レベル。ハッカー会議の資料を検索：
- CPUIDで作業を終了し、
- パラメータとテスト結果の要約表を作成します。

第1レベル。機器と既存のソリューションの研究

仮想化に関する少しの理論

仮想マシンの~~真空内で球形の馬の~~検出器を作成する前に、問題のフレームワーク内で「仮想マシン」という用語をどのように理解するかを簡単に説明する必要があります。

仮想化の概念は、2つのカテゴリー（ 1 ）に分類できます。

1つ目はリソースの仮想化です。 Dropboxファイルストレージサービスの原理をリソース仮想化として解釈できる理由を、実例を見てみましょう。
1. ファイルをアップロード/ダウンロードする方法、およびサービスとやり取りする方法は正確に知っていますが、=> カプセル化の内部でどのように機能するかを自信を持って言うことはできません。
2. 各ユーザーは独自の一意のアカウントを持ち、各アカウントには保存するファイルのサイズの割り当てがあり、各アカウントに対して個別にアクセス許可を設定できます（実際、異なるユーザーのデータは同じストレージメディアに保存される場合があります）=> リソースを共有します。
3. ほとんどの場合、Dropboxの内部には1台または2台のコンピューターではなく、Dropboxシステム内のクライアントからのコマンドを単一の全体=> クラスタリングとして操作および処理する少なくとも数百台のサーバーがあります。
2つ目はプラットフォームの仮想化です。既存のハードウェアと、それらに依存する、または依存しないソフトウェアシステムに基づいてソフトウェアシステムを作成します（ 1 ）。

2番目のカテゴリでは、仮想化用のハードウェアリソースとソフトウェアを提供するシステム（ホストシステム、ホスト）とエミュレートシステム（ゲストシステム、ゲスト）の2つの用語をすぐに紹介します。

さらに、実際には、「ゲストシステム」の役割は次のとおりです。

エミュレートされたシステムのすべてのハードウェアとソフトウェア-このタイプの仮想化は、完全エミュレーションまたはシミュレーションと呼ばれます。このタイプの仮想化を提供するプログラムの例：Bochs、QEMU。
すべてのソフトウェアおよびハードウェアの一部のみ（ゲストシステムの分離を保証するのに十分な部分）-このタイプの仮想化は、部分エミュレーションまたはネイティブ仮想化と呼ばれます。このタイプの仮想化を提供するプログラムの例：VMWareワークステーション、VMWare ESXi、Microsoft Hyper-V、Oracle VirtualBox。
部分仮想化、準仮想化、オペレーティングシステムレベルの仮想化、およびアプリケーションレベルの仮想化も存在します。 3つの場合すべてで、物理的に1つのOSがあり、ゲストシステムは個別のプロセスまたは個別のプロセスグループ（ユーザーモードプロセスなど）です。

このエクスカーションの結果：この記事のフレームワークと仮想マシン検出器の作成では、ネイティブプラットフォームの仮想化のみに関心があります （つまり、Hyper-V、VirtualBox、またはネイティブ仮想化を使用する他のプログラムの環境でのみ起動を確認します）。さらに、VMWare Webサイトの定義に従って、「仮想マシン」という用語を解釈します。「仮想マシン」は、「オペレーティングシステムとアプリケーションを含む厳密に分離されたソフトウェアコンテナーです」（ 2 ）。

Windows Management Instrumentation（WMI）のデータを使用したVM検証の実装

目標（部分エミュレーションを備えた環境でのプログラムの動作の事実を決定する）がほぼ指定された後、このタイプの最も有名な仮想マシン（以降、短いVMの場合）と、これらのVMに囲まれた起動と実際のハードウェアでのOSの起動を区別する方法が見つかります

人気のある仮想化プログラムの開発者の著しく折りたたまれた広告ページを読んで、彼らの仕事の特定の一般的なスキームが私の頭に浮かびます（もちろん、開発者ではなくプログラムの仕事のスキーム）：

ホストOSがあります。一般性を失うことなく、それが1つであると想定します。
仮想化のプログラムは、ホストOS（以下、ハイパーバイザーと呼びます）にインストールされます。
ハイパーバイザーは、ゲストOSのインストールとその後の操作のためのインターフェースを提供します。

注：ホストOSとハイパーバイザーが単一のシン全体である場合があり、ホストOSとハイパーバイザーを別々に使用する場合と比較してコンピューターリソースの消費を削減できます（例：VMWare ESXiまたはWindows Hyper-V Server）。

しかし、実際には、ほとんどすべてのハイパーバイザーが「ゲスト追加」をインストールする機能を持っています-ハイパーバイザーを提供する特別なプログラムとドライバー

ゲストOSの機能の拡張制御（ゲストOSがフリーズしているかどうかの確認、RAMの使用可能なRAMの動的な変更、ホストおよびゲストOSの「共通」マウス）。しかし、広告によると、「VMは厳密に分離されたソフトウェアコンテナーである」場合、そのようなアクションはどのように実装されますか？

ゲストOSにインストールされたゲストアドオンは、厳密に定義された方法で、ホストOSで実行されているハイパーバイザーと直接対話することがわかりました。つまり、VM定義プログラムがこの相互作用を利用できる場合、OSがVM上で実行されていることが証明されます。確かに、問題の状況に応じて、独自のドライバーを使用せずにユーザーモードで証明を実行する必要があります...

次の場所をすぐに確認して確認します。

単に物理マシン上に存在できないシステム内の特定の機器を検索します。
VMにのみ実装されている（またはその逆、物理マシンにのみ実装されている）ハードウェアインターフェイスを検索します。

実際、検索行に「detect hyper-v C＃」または「detect vmware C＃」と入力すると、このようなものに遭遇しますが、それは一般化するためだけです。

さまざまな検証基準の最も完全な説明は、2013年のHacker誌の記事（ 3 ）で見つかりました。記事を基礎として取り上げます。また、OSの機器とプロセスに関する関連データを取得するには、Windows Management Instrumentation（WMI）メカニズム（文字通り「Windows Management Instrumentation」）を使用します。特に、WMIを使用すると、管理者権限なしで、OSが認識する機器に関する大量の情報を簡単に、すばやく、受け取ることができます。

WMIを介してデータを取得するには、WQL言語（WMIクエリ言語）でクエリを作成する必要があります。WQL言語は、本質的に非常に単純化されたSQLです。たとえば、WMIを介してOSで利用可能なプロセッサに関する情報を取得するには、次の要求が必要です。

SELECT * FROM Win32_Processor

この要求に対する答えは、既知のフィールド名を持つWin32_Processorタイプのオブジェクトのセットです（使用可能なフィールドとクラスの詳細なリストについては、 4を参照してください）。もちろん、すべてのフィールドが必要ない場合は、*の代わりに、必要なフィールドのみをコンマでリストできます。 WQL SELECTステートメントでは、SQLと同様に、WHERE句もサポートされています。これにより、フィールドの値が指定された条件を満たすオブジェクトのみを選択できます。

「シード」するために、次のタイプのWMIオブジェクトから次のデータを取得する方法を学習します（VMのデータと期待値は3から取得されます）。

WMIオブジェクトとそのプロパティ		オブジェクトのWQLクエリの条件	使い方
Win32_Processor
	メーカー		VirtualBoxの場合は「VBoxVBoxVBox」、VMWareの場合は「VMwareVMware」、Parallelsの場合は「prl hyperv」に等しくなります。
Win32_BaseBoard
	メーカー		Hyper-Vの場合、Microsoftがマザーボードをリリースしないという事実にもかかわらず、「Microsoft Corporation」と同等です（興味深いことに、このパラメーターはMicrosoft Surfaceタブレットで何を示しますか？）。
Win32_DiskDrive
	PNPDeviceID		VirtualBoxの場合は「VBOX_HARDDISK」を含み、VMWareの場合は「VEN_VMWARE」を含みます。
Win32_NetworkAdapter
	MACAddress	PhysicalAdapter = 1	製造元はMACアドレスの上位3バイトで識別できることがわかっており、仮想マシンの製造元も例外ではありません（つまり、PhysicalAdapter符号= 1のアダプターがVMWareプールからMACアドレスを持っている場合は、VMでプログラムが起動される可能性が高くなります）。
Win32_Process
	お名前		ゲストアドオンがVMにインストールされると、既知の名前を持つ追加のプロセスがシステムに表示されます。

TMI.Utils.Environmentライブラリの形式で、WMIを介した機器データの受信を別のプロジェクトに実装します。

プロジェクトを次のように構成します。

エンティティ-WMIから受信したデータ（エンティティ）を持つオブジェクト。
サービス -サービス; たとえば、.NET WMIラッパーとの相互作用をカプセル化するサービス。
インターフェース -インターフェース; たとえば、WMIサービスインターフェイス。
クエリ -WMI要求のパラメーターを含むオブジェクト。指定されたエンティティタイプが取得されます。

このライブラリのユーザーが次のようなものを作成できるようにしたいと思います。

 var bios = wmiService.QueryFirst<WmiBios>(new WmiBiosQuery()); var processors = wmiService.QueryAll<WmiProcessor>(new WmiProcessorQuery());

WMIとやり取りする、リクエストを作成する、またはレスポンスを厳密に型指定されたC＃言語クラスに変換するメカニズムについて心配しませんでした。

実際、これを実装するのはそれほど難しくありません。

最初に、System.Managementライブラリへのリンクをプロジェクトに接続します（これは、WMIにアクセスするための.NETクラスが存在する場所です）。次に、IWmiServiceサービスのインターフェイスについて説明します（このインターフェイスの実装は、データを取得し、それを厳密に型指定されたオブジェクトに変換します）。

コードIWmiService.cs

 /// <summary> ///     Windows Management Instrumentation (WMI). /// </summary> public interface IWmiService { /// <summary> ///        WMI. /// </summary> /// <typeparam name="TResult"> ,     .</typeparam> /// <param name="wmiQuery">,   WMI-.</param> /// <returns>   .</returns> TResult QueryFirst<TResult>(WmiQueryBase wmiQuery) where TResult : class, new(); /// <summary> ///        WMI. /// </summary> /// <typeparam name="TResult"> ,     .</typeparam> /// <param name="wmiQuery">,   WMI-.</param> /// <returns>    .</returns> IReadOnlyCollection<TResult> QueryAll<TResult>(WmiQueryBase wmiQuery) where TResult : class, new(); }

次に、プロジェクトでエンティティがどのように見えるかを設定しましょう。検出のために、Win32_BaseBoard型のWMIオブジェクトからの次のフィールドが必要だとします。

WmiBaseBoard.csコード-最大

 public class WmiBaseBoard { public string Manufacturer { get; private set; } public string Product { get; private set; } public string SerialNumber { get; private set; } }

理想的には、WMLリクエストの結果からのデータを上記のエンティティに変換するためにDTOを作成する必要がありますが、プロジェクトのエンティティのプロパティがWMLリクエストの結果からのオブジェクトのフィールドに1対1で対応すると仮定すると、各エンティティでDTOを実行します単調なコードをたくさん書きます。

プログラマーのメインプロパティ（遅延）を使用し、本格的なDTOを作成する代わりに、各プロパティを次の属性として属性でマークするだけで、プロパティとWMLリクエストの結果フィールドを関連付けることができます。

WmiResultAttribute.csコード

 /// <summary> /// ,       WMI. /// </summary> [AttributeUsage(AttributeTargets.Property)] public class WmiResultAttribute : Attribute { public WmiResultAttribute(string propertyName) { PropertyName = propertyName; } /// <summary> ///     WMI. /// </summary> public string PropertyName { get; } }

指定された属性でエンティティのプロパティをマークすると、次のようになります。

WmiBaseBoard.csコード-後

 public class WmiBaseBoard { internal const string MANUFACTURER = "Manufacturer"; internal const string PRODUCT = "Product"; internal const string SERIAL_NUMBER = "SerialNumber"; // ReSharper disable UnusedAutoPropertyAccessor.Local [WmiResult(MANUFACTURER)] public string Manufacturer { get; private set; } [WmiResult(PRODUCT)] public string Product { get; private set; } [WmiResult(SERIAL_NUMBER)] public string SerialNumber { get; private set; } // ReSharper restore UnusedAutoPropertyAccessor.Local }

リクエストを保存するオブジェクトを処理するために残ります。前のコード例では、WQLクエリ結果のフィールド名が内部定数でレンダリングされていることに気づいたと思います。これは、リクエストクラスで重複しないように特に行われました。ところで、興味深い副作用であることが判明しました。このモデルを使用すると、抽出するエンティティのプロパティを指定するまで、WMIオブジェクトのフィールドデータをWMIから読み取ることができません。

WmiQueryBase.csコード

 using System.Management; /// <summary> ///       WMI. /// </summary> public class WmiQueryBase { private readonly SelectQuery _selectQuery; /// <summary> ///    WMI. /// </summary> /// <param name="className"> ,    .</param> /// <param name="condition"> .</param> /// <param name="selectedProperties">  .</param> protected WmiQueryBase(string className, string condition = null, string[] selectedProperties = null) { _selectQuery = new SelectQuery(className, condition, selectedProperties); } /// <summary> ///    SELECT-  WMI. /// </summary> internal SelectQuery SelectQuery { get { return _selectQuery; } } }

WmiBaseBoardQuery.csコード

 using TTC.Utils.Environment.Entities; public class WmiBaseBoardQuery : WmiQueryBase { public WmiBiosQuery() : base("Win32_BaseBoard", null, new[] { WmiBios.MANUFACTURER, WmiBios.PRODUCT, WmiBios.SERIAL_NUMBER, }) { } }

クエリクラスのこのような構造では、厄介なことが1つだけあります。クラス内のWML要求のWHERE部分のパラメーターを作成するのは不便です。パラメータに応じて、昔ながらの方法でペンを使用して線を形成する必要があります。

WmiNetworkAdapterQuery.csコード

 using System.Text; using TTC.Utils.Environment.Entities; public class WmiNetworkAdapterQuery : WmiQueryBase { private static readonly string[] COLUMN_NAMES = { WmiNetworkAdapter.GUID, WmiNetworkAdapter.MAC_ADDRESS, WmiNetworkAdapter.PNP_DEVICE_ID, }; public WmiNetworkAdapterQuery(WmiNetworkAdapterType adapterType = WmiNetworkAdapterType.All) : base("Win32_NetworkAdapter", null, COLUMN_NAMES) { if (adapterType == WmiNetworkAdapterType.Physical) SelectQuery.Condition = "PhysicalAdapter=1"; else if (adapterType == WmiNetworkAdapterType.Virtual) SelectQuery.Condition = "PhysicalAdapter=0"; } }

良い：エンティティに散在するデータ、クエリを半分で書くことを学んだので、これらのクラスで動作するサービスがどのようになるかを理解する必要があります。

WmiService.csコード

 /// <summary> ///    Windows Management Instrumentation (WMI). /// </summary> public class WmiService : IWmiService { /// <summary> ///         WMI   . /// </summary> /// <typeparam name="TResult"> ,     .</typeparam> /// <param name="managementObject">,     WMI.</param> /// <returns>   .</returns> private static TResult Extract<TResult>(ManagementBaseObject managementObject) where TResult : class, new() { var result = new TResult(); foreach (var property in typeof(TResult).GetProperties()) { var wmiAttribute = (WmiResultAttribute)Attribute.GetCustomAttribute(property, typeof(WmiResultAttribute)); if (wmiAttribute != null) { var sourceValue = managementObject.Properties[wmiAttribute.PropertyName].Value; var targetType = Nullable.GetUnderlyingType(property.PropertyType) ?? property.PropertyType; object targetValue; if (sourceValue == null) { targetValue = null; } else if (targetType == typeof(DateTime)) { targetValue = ManagementDateTimeConverter.ToDateTime(sourceValue.ToString()).ToUniversalTime(); } else if (targetType == typeof(Guid)) { targetValue = Guid.Parse(sourceValue.ToString()); } else { targetValue = Convert.ChangeType( managementObject.Properties[wmiAttribute.PropertyName].Value, targetType); } property.SetValue(result, targetValue); } } return result; } /// <summary> ///        WMI. /// </summary> /// <param name="selectQuery">   .</param> /// <param name="searcher">      WMI.</param> /// <returns>    .</returns> private ManagementObjectCollection QueryAll(SelectQuery selectQuery, ManagementObjectSearcher searcher = null) { searcher = searcher ?? new ManagementObjectSearcher(); searcher.Query = selectQuery; return searcher.Get(); } /// <summary> ///         WMI. /// </summary> /// <param name="selectQuery">   .</param> /// <param name="searcher">      WMI.</param> /// <returns>    .</returns> private ManagementBaseObject QueryFirst(SelectQuery selectQuery, ManagementObjectSearcher searcher = null) { return QueryAll(selectQuery, searcher).Cast<ManagementBaseObject>().FirstOrDefault(); } public TResult QueryFirst<TResult>(WmiQueryBase wmiQuery) where TResult : class, new() { var managementObject = QueryFirst(wmiQuery.SelectQuery); return managementObject == null ? null : Extract<TResult>(managementObject); } public IReadOnlyCollection<TResult> QueryAll<TResult>(WmiQueryBase wmiQuery) where TResult : class, new() { var managementObjects = QueryAll(wmiQuery.SelectQuery); return managementObjects?.Cast<ManagementBaseObject>() .Select(Extract<TResult>) .ToList(); } }

WmiService.Extract <TResult>メソッドに関するいくつかの言葉。

通常、WMIオブジェクトにはかなり多数のプロパティがあります（多くのフィールドはNULLになる場合があります）。タスクの一環として、WMIから少数のオブジェクトプロパティのみをアンロードするという前提の下で、結果のエンティティのプロパティを並べ替えてデータのマッピングを開始することは論理的です。さらに、プロパティにWmiResultAttribute属性がある場合、クエリ結果オブジェクトから属性で指定された名前のプロパティの値を読み取り、型変換を実行します。さらに、エンティティのプロパティが、標準のConvert.ChangeTypeメソッドが処理できない型であるか、希望する方法で型を変換しない場合、System.DateTime型およびSystem.Guid型で行われているように、制御を変換に簡単に移行できます。

ちなみに、Extractを2つのメソッドに分離することをお勧めします：最初のメソッドはクラスタイプから情報を抽出し、2番目のメソッドはインスタンスを埋めます（そうでない場合、出力コレクションの2番目以降の要素のQueryAllメソッドは、そのタイプの構造の再検討に不要な作業を行います）ただし、特に仮想マシンを検出するために、1回のリクエストで10個を超えるオブジェクトを期待することはほとんどありません。したがって、このタスクを「実装されていません。しかし、誰かがそのような修正を手に入れたら-私はあなたの修正を喜んで受け入れます。

あとがき

記事のこの部分をライブラリだけで終わらせないために、このライブラリの機能を使用して、上記の基準に基づいてVMWare、Microsoft、Parallels、Oracleの最も人気のある仮想マシンのいくつかを検出する最も単純なアプリケーションを作成します。

別のプロジェクト-コンソールアプリケーションTTC.Utils.VMDetectを作成し、その中に次のクラスDemoTrivialVmDetectorを作成しましょう。

WmiService.csコード

 /// <summary> ///      - . /// </summary> class DemoTrivialVmDetector { private readonly IWmiService _wmiService; public DemoTrivialVmDetector(IWmiService wmiService) { _wmiService = wmiService; } public MachineType GetMachineType() { var wmiProcessor = _wmiService.QueryFirst<WmiProcessor>(new WmiProcessorQuery()); if (wmiProcessor.Manufacturer != null) { if (wmiProcessor.Manufacturer.Contains("VBoxVBoxVBox")) return MachineType.VirtualBox; if (wmiProcessor.Manufacturer.Contains("VMwareVMware")) return MachineType.VMWare; if (wmiProcessor.Manufacturer.Contains("prl hyperv")) return MachineType.Parallels; } var wmiBaseBoard = _wmiService.QueryFirst<WmiBaseBoard>(new WmiBaseBoardQuery()); if (wmiBaseBoard.Manufacturer != null) { if (wmiBaseBoard.Manufacturer.Contains("Microsoft Corporation")) return MachineType.HyperV; } var wmiDiskDrives = _wmiService.QueryAll<WmiDiskDrive>(new WmiDiskDriveQuery()); if (wmiDiskDrives != null) foreach (var wmiDiskDrive in wmiDiskDrives) { if (wmiDiskDrive.PnpDeviceId.Contains("VBOX_HARDDISK")) return MachineType.VirtualBox; if (wmiDiskDrive.PnpDeviceId.Contains("VEN_VMWARE")) return MachineType.VMWare; } return MachineType.Unknown; } }

ライブラリと最も単純なテストアプリケーションを含むすべてのコードはgithubリポジトリに投稿されています。レビューとコメントは歓迎します。

次のパートでは、既知のVMを使用して作業を少し構造化し、アセンブラー命令CPUIDを使用して、既に不明なVMを検出しようとします。

C＃で仮想マシンを検出：レベル1

出版構造

第1レベル。 機器と既存のソリューションの研究

仮想化に関する少しの理論

Windows Management Instrumentation（WMI）のデータを使用したVM検証の実装

あとがき

ソース

More articles:

第1レベル。機器と既存のソリューションの研究