カーネルへのパッチ適用とドライバーの作成の違いを理解しようとしています。
カーネル モード ドライバーは、カーネルが実行できることは何でも実行でき、ある意味で Linux モジュールに似ていると理解しています。
では、Microsoft が Windows カーネルへのパッチ適用を停止したとき、なぜ AV メーカーはこれほど動揺したのでしょうか?
ドライバーではできないことで、カーネルのパッチ適用ではどのようなことができますか?
カーネルへのパッチ適用とドライバーの作成の違いを理解しようとしています。
カーネル モード ドライバーは、カーネルが実行できることは何でも実行でき、ある意味で Linux モジュールに似ていると理解しています。
では、Microsoft が Windows カーネルへのパッチ適用を停止したとき、なぜ AV メーカーはこれほど動揺したのでしょうか?
ドライバーではできないことで、カーネルのパッチ適用ではどのようなことができますか?
このコンテキストでは、カーネルにパッチを適用するということは、いくつかの機能を実現するために(文書化されていない?)内部構造を変更することを意味します。自分のものではない内部カーネル構造をいじり回してはいけません。これまで、Microsoftはいくつかのことについて公式のフックを提供していなかったため、セキュリティ会社は内部をリバースエンジニアリングし、カーネルを直接フックしていました。最近、Microsoftはいくつかのものに公式のフックを提供しているので、カーネルを直接フックする必要性はそれほど強くありません。
確かに、カーネル モード ドライバーは、カーネルが実行できることなら何でも実行できます。結局のところ、どちらもリング 0 で実行されます。パッチの適用は、異なるカーネル リリース間で変更される可能性がある内部の詳細に依存します。たとえば、システム コール番号はNtTerminateProcess
バージョン間で変わるため、SSDT をフックするドライバーはバージョン間で壊れます (ただし、システム コール番号は他の方法で取得できます)。or などの内部構造のフィールドを読み取ったり変更したりするEPROCESS
ことETHREAD
も危険です。これは、これらの構造がバージョン間で変化するためです。これはドライバーにとって不可能なことではありませんが、難しいことです。
フック用の公式インターフェイスが提供されている場合、Microsoft はバージョン間の互換性を保証し、誰が何を実行できるかを制御できます (たとえば、署名されたドライバーのみがオブジェクト マネージャーのコールバックを使用できます)。ただし、一部のことは、ドライバーが知っておくべきではない単なる実装の詳細であるため、Microsoft はすべてに対してこれを行うことはできません。