OWN-Defender は、Windows Security Center (WSC) がCOMインターフェースを通じてウイルス対策セキュリティ製品をどのように表現・管理するかを理解することに焦点を当てたWindowsセキュリティリサーチプロジェクトです。
このプロジェクトは、DefendNot が示す動作の調査として始まりましたが、既存の実装をブラックボックスとして扱うのではなく、独立したリバースエンジニアリングと検証の出発点として使用しました。
このプロジェクトの目標は、完全な実行パスを理解することです：
COM
↓
CLSID / IID
↓
CoCreateInstance
↓
QueryInterface
↓
ATL Interface Map
↓
vtable
↓
IWscAVStatus4
↓
CWscIsv
↓
WSCAPI.dll
↓
RPC
↓
Windows Security Center
このプロジェクトは、管理されたWindowsリサーチ環境で開発・テストされました。
リサーチ / 教育目的のみ
このプロジェクトは、Windows内部のリサーチ、リバースエンジニアリング、セキュリティ教育、および許可されたセキュリティテストを目的としています。所有していない、または明示的なテスト許可がないシステム上のセキュリティソフトウェアに干渉するために使用しないでください。
最初の疑問は単純でした：
Windows Security Centerは、ウイルス対策製品が存在することをどのように知るのか？
公開されているAPIドキュメントで止まるのではなく、APIの内部で何が起こっているのかを理解したいと考えました。
これにより、いくつかの疑問が生まれました：
QueryInterface() はインターフェースをどのように解決するのか？__int64 a1 しか表示しないことがあるのはなぜか？Register() はどれか？最初のステップは、Windows Security CenterのCOMクラスを特定することでした。
このプロジェクトでは、WSC COMクラスを使用します：
CLSID_WscIsv
F2102C37-90C3-450C-B3F6-92BE1693BDF2
実装には、ハードコードされた値にのみ依存するのではなく、WindowsレジストリからCLSIDを動的に特定するロジックも含まれています。
概念的には：
HKLM
└── SOFTWARE
└── Classes
└── CLSID
└── {CLSID}
└── Windows Security Center ISV API
これにより、最初の重要な関係が得られました：
Registry
↓
CLSID
↓
Windows Security Center ISV API
次の課題は、どのCOMインターフェースを要求すべきかを判断することでした。
このプロジェクトでは、以下を使用します：
IWscAVStatus4
以下とともに：
4DCBAFAC-29BA-46B1-80FC-B8BDE3C0AE4D
リサーチから得られた重要な教訓の1つは：
GUID名だけでは十分な証拠にはならない。
インターフェース名とGUIDが正しいと仮定するのではなく、リバースエンジニアリングを通じて関係を検証しました。
調査には以下が含まれます：
QueryInterface_ATL_INTMAP_ENTRYQueryInterface の理解最も有用なリバースエンジニアリング手順の1つは、以下の実装を追跡することでした：
CComAggObject<CWscIsv>::QueryInterface()
これは最終的に以下に到達します：
ATL::CComObjectRootBase::InternalQueryInterface()
ATLインターフェースマップは、要求されたIIDを登録済みのインターフェースエントリと比較するために使用されます。
概念的には：
Requested IID
↓
QueryInterface()
↓
InternalQueryInterface()
↓
ATL Interface Map
↓
GUID comparison
↓
Matching interface
↓
Interface pointer
これにより、調査中のGUIDが実際に期待されるCOMインターフェースに対応しているという独立した証拠が得られました。
Register() の混乱最大のリバースエンジニアリングの課題の1つは、IDA/Ghidraが期待するメソッドシグネチャを常に表示しない理由を理解することでした。
再構築されたインターフェースには以下が含まれます：
virtual HRESULT __stdcall Register(
BSTR path,
BSTR name,
unsigned int,
unsigned int
) = 0;
しかし、デコンパイラは以下のような実装を表示することがあります：
_IWscAVStatus4<CWscIsv>::Register(__int64 a1)
最初はこれが一貫性がないように見えました。
さらなる調査により、デコンパイラの表現は、完全な論理インターフェースシグネチャを提示するのではなく、ラッパー/サンクとその基盤となる間接vtable呼び出しを記述していることが示されました。
これは重要な教訓となりました：
デコンパイラの出力は機械語の解釈であり、元のソースレベルの真実ではありません。
これらの不一致を解決するために、以下を比較しました：
COM interface definition
↓
vtable layout
↓
assembly
↓
wrapper/thunk
↓
calling convention
↓
actual target function
Register() 関数混乱のもう1つの原因は、以下のような名前を持つ複数の関数の存在でした：
IWscAVStatus2::Register
IWscAVStatus4::Register
IWscFWStatus2::Register
RegisterAV
重要な気づきは、類似した名前は同一のインターフェースを意味しないということでした。
例えば：
AV
↓
IWscAVStatus4
↓
AV registration
一方：
Firewall
↓
IWscFWStatus2
↓
Firewall registration
名前が Register を含むという理由だけで関数を選択するのではなく、インターフェース番号と周囲の実装を検証する必要がありました。
これはリサーチの最も有用な部分の1つでした。なぜなら、以下を関連付けることを強制されたからです：
Interface
+
IID
+
vtable
+
implementation
+
parameter layout
+
call target
正しいインターフェースを特定した後、登録操作をバイナリのより深い部分まで追跡しました。
観察されたパスはおおよそ以下の通りです：
IWscAVStatus4::Register()
↓
CWscIsv
↓
RegisterSecurityProductFunction
↓
wscRegisterSecurityProduct()
↓
WSCAPI.dll
↓
s_wscRegisterSecurityProduct()
↓
NdrClientCall3()
↓
RPC
↓
Windows Security Center
COMメソッド自体が最終的な操作ではないため、これは特に重要でした。
呼び出しは最終的にRPC境界を越えました。
これにより、アーキテクチャの見方が変わりました：
COM
≠
final implementation
代わりに：
COM
↓
local implementation
↓
WSC API
↓
RPC client
↓
Windows component
WSCAPI.dll の理解次のレイヤーは WSCAPI.dll でした。
リバースエンジニアリングされたパスは以下に到達しました：
wscRegisterSecurityProduct()
これは最終的に以下を呼び出します：
s_wscRegisterSecurityProduct()
そして：
NdrClientCall3()
これが、調査が通常のCOM呼び出しからWindows RPCインフラストラクチャに移行したポイントでした。
このレイヤーを理解することで、元のCOM DLLだけを見ても動作を完全に理解できない理由が説明できました。
静的解析はリサーチの一部に過ぎませんでした。
関連するインターフェースと呼び出しパスを再構築した後、独自の管理された実装を作成し、結果の動作をWindows Security Centerと比較しました。
Windows Security Center / WMI情報を使用しました：
ROOT\SecurityCenter2
AntiVirusProduct
登録された製品情報を独立して観察するためです。
検証プロセスは以下の通りでした：
Reverse engineering
↓
Interface reconstruction
↓
Own implementation
↓
Runtime execution
↓
Windows Security Center
↓
WMI observation
↓
Compare results
これにより、静的解析からの結論が観察可能なWindowsの動作と一致することを検証できました。
このプロジェクトは、1つのCOMインターフェースとの対話方法以上のことを教えてくれました。
CoCreateInstanceQueryInterfaceWSCAPI.dllNdrClientCall3最も重要なのは、単一の証拠に依存することを避けることを学んだことです。
代わりに：
Symbol
↓
Decompiler
↓
Assembly
↓
GUID
↓
Interface Map
↓
vtable
↓
Call Graph
↓
RPC
↓
Runtime Verification
各レイヤーが結論への信頼度を高めます。
リサーチ実装は、2つの主要コンポーネントで構成されています。
OWN-Defender
│
├── OWN-Defender.cpp
│ ├── WSC COM interaction
│ ├── CLSID discovery
│ ├── COM initialization
│ ├── IWscAVStatus4 interaction
│ ├── registration
│ ├── status update
│ └── cleanup
│
└── dllmain.cpp
├── DLL entry point
├── research loader
├── controlled execution
└── cleanup/stop handling
リポジトリは意図的に小さく、リバースエンジニアリングされた動作と実装の関係が追跡しやすいようにしています。
このプロジェクトは、単に機能を再現するのではなく、質問を中心に構築されました：
WSCはCOMクラスをどのように特定するのか？
IIDはインターフェースにどのようにマッピングされるのか？
QueryInterfaceはインターフェースをどのように見つけるのか？
IDAが異なる関数シグネチャを表示するのはなぜか？
実際のvtableはどこにあるのか？
AV実装であるRegister()はどれか？
COMメソッドの後で何が起こるのか？
WSCAPI.dllは呼び出しチェーンのどこに入るのか？
RPCはどこから始まるのか？
結果はどのように独立して検証できるのか？
これらの質問は、最終的な実装自体よりも最終的に価値がありました。
このプロジェクトは、以下の間のセキュリティ境界を研究するための有用な出発点も提供します：
Application
↓
COM
↓
Windows Security Center
↓
Security Provider Information
重要な区別は、セキュリティ製品情報の登録は、Defenderエンジンの無効化やその保護メカニズムのバイパスと自動的に同等ではないということです。
したがって、このプロジェクトは主に以下のように見なされるべきです：
Windows Security Center / COM リバースエンジニアリングリサーチ
WSC登録だけでDefenderの脆弱性を構成するという主張ではありません。
セキュリティへの影響には、別途調査と検証が必要です。
このリサーチは、es3n1n による DefendNot で示された作業に部分的に触発されました。
WSCメカニズムを理解するための有用な出発点を提供してくれた作者に特別な感謝を捧げます。
元のプロジェクト： https://github.com/es3n1n/defendnot
このリポジトリの目的は、元のリサーチを自分のものとして主張することではなく、基盤となるWindowsの動作に対する独自のリバースエンジニアリングプロセス、独立した実装、および検証を文書化することです。
このリポジトリは以下を目的として提供されています：
所有している、または明示的にテストを許可されているシステムでのみこのプロジェクトを使用してください。
作者は、誤用、損害、データ損失、セキュリティ制御への干渉、または不正な展開について責任を負いません。
このプロジェクトは GNU General Public License v3.0 の下でライセンスされています。
詳細については LICENSE を参照してください。
OWN-Defender の主な目標は、単にAV登録テクニックを再現することではありません。
再現可能なリバースエンジニアリング方法論を示すことです：
Find
↓
Map
↓
Reverse
↓
Reconstruct
↓
Trace
↓
Implement
↓
Verify
Windows Security Centerに関する疑問から始まったものが、COM、ATL、GUID/IIDマッピング、vtable、コンパイラ生成コード、WSCAPI、RPC、およびWindowsセキュリティアーキテクチャのより深い探求になりました。
実装は結果です。リバースエンジニアリングプロセスこそが本当のプロジェクトです。