OWN-Defender — Windows Security Center COM 연구

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 아래에서 어떤 일이 일어나는지 이해하고 싶었습니다.

이것은 여러 질문으로 이어졌습니다:

어떤 COM 클래스가 WSC 기능을 구현하는가?
어떤 IID가 바이러스 백신 인터페이스에 해당하는가?
QueryInterface()는 인터페이스를 어떻게 해석하는가?
인터페이스는 ATL 인터페이스 맵의 어디에 저장되는가?
IDA가 메서드에 대해 __int64 a1만 표시하는 이유는 무엇인가?
재구성된 C++ 인터페이스에 추가 매개변수가 포함된 이유는 무엇인가?
실제 AV 등록 함수는 어떤 Register() 함수인가?
등록은 어떻게 최종적으로 Windows Security Center에 도달하는가?
RPC 경계는 어디에 나타나는가?
결과를 독립적으로 검증하는 방법은 무엇인가?

리버스 엔지니어링 여정

1. COM 클래스 식별

첫 번째 단계는 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

2. 올바른 인터페이스 식별

다음 과제는 요청해야 할 COM 인터페이스를 결정하는 것이었습니다.

이 프로젝트는 다음을 사용합니다:

IWscAVStatus4

다음과 함께:

4DCBAFAC-29BA-46B1-80FC-B8BDE3C0AE4D

연구에서 얻은 중요한 교훈 중 하나는:

GUID 이름만으로는 충분한 증거가 아닙니다.

인터페이스 이름과 GUID가 올바르다고 가정하는 대신 리버스 엔지니어링을 통해 관계를 검증했습니다.

조사에는 다음이 포함되었습니다:

GUID 참조
QueryInterface
ATL 인터페이스 맵
_ATL_INTMAP_ENTRY
vtable 위치
교차 참조
함수 구현
런타임 동작

3. `QueryInterface` 이해

가장 유용한 리버싱 단계 중 하나는 다음의 구현을 추적하는 것이었습니다:

CComAggObject<CWscIsv>::QueryInterface()

이는 궁극적으로 다음에 도달합니다:

ATL::CComObjectRootBase::InternalQueryInterface()

ATL 인터페이스 맵은 요청된 IID를 등록된 인터페이스 항목과 비교하는 데 사용됩니다.

개념적으로:

Requested IID
     ↓
QueryInterface()
     ↓
InternalQueryInterface()
     ↓
ATL Interface Map
     ↓
GUID comparison
     ↓
Matching interface
     ↓
Interface pointer

이것은 조사 중인 GUID가 실제로 예상된 COM 인터페이스에 해당한다는 독립적인 증거를 제공했습니다.

4. `Register()` 혼동

가장 큰 리버싱 과제 중 하나는 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

5. 여러 `Register()` 함수

혼동의 또 다른 원인은 다음과 같은 이름을 가진 여러 함수의 존재였습니다:

IWscAVStatus2::Register
IWscAVStatus4::Register
IWscFWStatus2::Register
RegisterAV

중요한 깨달음은 유사한 이름이 동일한 인터페이스를 의미하지 않는다는 것이었습니다.

예를 들어:

AV
 ↓
IWscAVStatus4
 ↓
AV registration

반면:

Firewall
 ↓
IWscFWStatus2
 ↓
Firewall registration

이름에 Register가 포함되어 있다는 이유만으로 함수를 선택하는 대신 인터페이스 번호와 주변 구현을 검증해야 했습니다.

이것은 연구에서 가장 유용한 부분 중 하나였습니다. 왜냐하면 다음을 연관시켜야 했기 때문입니다:

Interface
+
IID
+
vtable
+
implementation
+
parameter layout
+
call target

6. 등록 경로 추적

올바른 인터페이스를 식별한 후, 등록 작업을 바이너리 더 깊이 추적했습니다.

관찰된 경로는 대략 다음과 같습니다:

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

7. `WSCAPI.dll` 이해

다음 계층은 WSCAPI.dll이었습니다.

리버스 엔지니어링된 경로는 다음에 도달했습니다:

wscRegisterSecurityProduct()

이는 결국 다음을 호출했습니다:

s_wscRegisterSecurityProduct()

그리고 다음을 호출했습니다:

NdrClientCall3()

이 시점에서 조사는 일반적인 COM 호출에서 Windows RPC 인프라로 이동했습니다.

이 계층을 이해하면 원래 COM DLL만 살펴보는 것으로는 동작을 완전히 이해할 수 없는 이유를 설명하는 데 도움이 되었습니다.

8. 런타임 검증

정적 분석은 연구의 한 부분에 불과했습니다.

관련 인터페이스와 호출 경로를 재구성한 후, 자체 통제된 구현을 만들고 결과 동작을 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 동작과 일치하는지 검증할 수 있었습니다.

9. 배운 점

이 프로젝트는 단일 COM 인터페이스와 상호작용하는 방법보다 훨씬 더 많은 것을 가르쳐 주었습니다.

COM

CLSID vs IID
COM 활성화
CoCreateInstance
QueryInterface
참조 카운팅
인터페이스 포인터
vtable
ATL 인터페이스 맵

리버스 엔지니어링

IDA/Ghidra 디컴파일러 한계
교차 참조 추적
GUID 식별
인터페이스 재구성
컴파일러 생성 래퍼/썽크 분석
간접 vtable 호출 이해
호출 규약 검증

Windows 내부 구조

Windows Security Center
WSC 공급자 인터페이스
WSCAPI.dll
Windows RPC
MIDL 생성 RPC 스텁
NdrClientCall3
Security Center 제품 상태

연구 방법론

가장 중요한 것은 단일 증거에 의존하는 것을 피하는 법을 배운 것입니다.

대신:

Symbol
   ↓
Decompiler
   ↓
Assembly
   ↓
GUID
   ↓
Interface Map
   ↓
vtable
   ↓
Call Graph
   ↓
RPC
   ↓
Runtime Verification

각 계층은 결론에 대한 신뢰도를 높입니다.

프로젝트 아키텍처

연구 구현은 두 가지 주요 구성 요소로 구성됩니다.

OWN-Defender
│
├── OWN-Defender.cpp
│   ├── WSC COM 상호작용
│   ├── CLSID 검색
│   ├── COM 초기화
│   ├── IWscAVStatus4 상호작용
│   ├── 등록
│   ├── 상태 업데이트
│   └── 정리
│
└── dllmain.cpp
    ├── DLL 진입점
    ├── 연구 로더
    ├── 통제된 실행
    └── 정리/중지 처리

리포지토리는 의도적으로 작게 유지되어 리버스 엔지니어링된 동작과 구현 간의 관계를 쉽게 따라갈 수 있도록 합니다.

주요 연구 질문

이 프로젝트는 단순히 기능을 재현하는 것이 아니라 질문을 중심으로 구축되었습니다:

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 동작에 대한 자체 리버스 엔지니어링 프로세스, 독립적인 구현 및 검증을 문서화하는 것입니다.

면책 조항

이 리포지토리는 다음을 위해 제공됩니다:

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 보안 아키텍처에 대한 더 깊은 탐구가 되었습니다.

구현은 결과입니다. 리버스 엔지니어링 프로세스가 진정한 프로젝트입니다.

OWN-Defender

인기