홍가일보(KB)

FileSystemFilterDriver 파일숨기기

(hongyver) — Sun, 14 Jun 2009 13:19:29 +0900

ZwQueryDirectoryFile

Window XP이후 버전 에서 폴더내 파일 또는 폴더의 정보를 얻기 위한 과정은 ZwCreateFile 또는 ZwOpenFile을 통해 얻어진 handle을 통해 ZwQueryDirectoryFile 에서 디렉토리에 대한 파일 또는 폴더 정보를 query하여 얻는다.
즉 윈도우에서 탐색기 혹은 cmd 창에서 dir 명령어도 Win32 API 에서 파일 및 폴더 정보를 얻어오는 과정과 사용된 API가 다르겠지만 결국 Native API 인 ZwQueryDirectoryFile 을 통해서 디렉토리내 파일 또는 폴더명을 얻는다는 이야기다.
따라서 파일 또는 폴더를 숨기기 위해서는 ZwQueryDirectoryFile 함수를 Hooking 하여 원하는 파일 또는 폴더를 숨길수 있다는 이야기다.

IRP_MJ_DIRECTORY_CONTROL

Hooking을 하지 않고 파일필터 드라이버에서 파일 및 폴더를 숨기는 기능을 수행하기 위해서는 아래의 IRP funtion code를 참고하면 된다.

IRP stack의 Major Function 이 IRP_MJ_DIRECTORY_CONTROL
IRP stack의 Minor Function 이 IRP_MN_QUERY_DIRECTORY

위의 두가지 Funtion code외에 FileInformationClass 를 조사하여야 한다.

IRP stack의 Parameters->FileInformationClass 가 FileBothDirectoryInformation

대부분의 win32에서의 폴더내의 파일 및 파일 열거에 대한 호출은 FileBothDirectoryInformation(VISTA에서는 FileIdBothDirectoryInformation 로 변경)이다. 따라서 대부분 FileBothDirectoryInformation로 원하는 처리(파일 또는 풀더 숨김)가 가능하지만 보다 강력한(?) 숨기기 기능을 원하다면 FilFullDirectoryInformation, FileNameInformation, FileDirectoryInfomation class도 대한 처리도 필요하지 않을까 싶다.

전처리

원하는 조건은 다 충족되었다.
이제 파일 또는 폴더 숨기는 작업을 수행하여야 하는데 그전에 알아두어야 할 것이있다.

조건이 만족된 지금 현재 상태는 File System Driver로 IRP를 넘겨 주기 전 이기 때문에 파일 및 폴더에 어떤 정보도 알지 못한다. 따라서 지금 처리할수 있는 작업은 폴더에 대한 접근 거부(STATUS_ACCESS_DENIED) 또는 폴더내 어떤 파일도 보여주지 않는 작업(STATUS_NO_SUCH_FILE)만이 가능하다.

아래 그림에서 1번을 참고하면 되겠다.

후처리

조건이 만족한 상태라면 파일 숨기는 기능을 처리해야 하지만 위의 전처리에서 설명했다시피 폴더 및 파일에 대한 정보를 아직 얻지 못한 상태이기때문에 어떠한 가공(?)도 할수 없다.
따라서 IoSetCompletionRoutine 을 통해 IRP가 완료한 시점에 다시 호출받도록 설정하여 File System Driver가 모든 작업을 완료하고 나서 다시 호출될수 있도록 해야 한다.
그래야만 File System Driver에서 얻어지 파일 또는 폴더에 대한 정보를 가공(?) 할수 있다.

위의 그림에서 2번을 참고.

완료루틴

IoSetCompletionRoutine 에서 설정한 대로 File System Driver에서 작업을 완료하고 완료루틴이 호출되면 원하는 파일 또는 폴더에 대한 작업을 수행한다.
파일 또는 폴더에 대한 정보는 Irp->UserBuffer 에 넘겨져 온다.
이 정보를 제대로 파악하기 위해서는 아래의 parameter를 참고해야한다.

IrpSp->Parameters.QueryDirectory.Length
버퍼의 길이 - METHOD_NEITHER를 사용하기 때문에 Irp->UserBuffer 의 크기
IrpSp->Parameters.QueryDirectory.FileName
파일 열거를 위한 매칭패턴을 위해 사용됨. 첫 호출에만 제공됨. 그 이후 NULL이면 *, *.* 패턴과 동일시 됨
IrpSp->Parameters.QueryDirectory.FileInformationClass
결과에 대한 데이타 구조체 형식, MSDN 참고
IrpSp->Parameters.QueryDirectory.FileIndex
열거가 발생할 시작 index

처음에 언급했던바처럼 FileBothDirectoryInformation 에 대한 class 만 참고하다면
pFileInfo = (PFILE_BOTH_DIR_INFORMATION) Irp->UserBuffer 와 같은 casting 을 통해 pFileInfo 를 통해 파일 정보를 구할수 있다.(PFILE_BOTH_DIR_INFORMATION 는 각각의 파일에 대한 정보를 담고 있으며 NextEntryOffset으로 다음 정보에 대한 offset값을 가지고 있다.)
파일정보에서 특정파일을 숨기기 위해서는 NextEntryOffset 값을 건너 뛰도록 offset 값을 조작하여 파일을 숨긴다.

주의해야 할점이라면 버퍼의 용량이 그다지 크지 않기 때문에 특정 폴더에 대한 query 시 폴더내 모든 파일(폴더)의 정보가 한번에 넘어오지 않는다. (경험상 약 30개 파일의 정보 단위로 넘어오는듯)
한 폴더에 약 100개의 파일이 존재한다면 30개씩 약 4번에 걸쳐 모든 정보가 넘어온다.

또한 Irp->Flags parameter도 참고하여야 한다.

SL_RESTART_SCAN 첫번째 부터 스캔
SL_RETURN_SINGLE_ENTRY 한개만 스캔
SL_INDEX_SPECIFIED FileIndex 에서 부터 스캔

FindFirst/FindNext 과 같은 win api에서는 flags가 SL_RETURN_SINGLE_ENTRY 가 설정되어 파일이 한개만 조사되기 때문에구조체에 한개 파일의 정보만 담겨진다.
따라서 NextEntryOffset 값을 조작하는데 유의해야한다. 이는 여러개의 파일정보가 있으나 숨기고자 하는 파일정보가 마지막에 위치하였을때도 마찬가지다.
(편법으로 파일이름을 . 으로 대체하기도 했음)

code snippet

FileInformationClass 에 따라 FileName 및 FileNameLength 얻기

switch(irpsp->Parameters.QueryDirectory.FileInformationClass)
{
case FileBothDirectoryInformation:
p = ((PFILE_BOTH_DIR_INFORMATION)buf)->FileName;
len = &(((PFILE_BOTH_DIR_INFORMATION)buf)->FileNameLength);
sp = ((PFILE_BOTH_DIR_INFORMATION)buf)->ShortName;
slen = ((PFILE_BOTH_DIR_INFORMATION)buf)->ShortNameLength;
break;
case FileFullDirectoryInformation:
p = ((PFILE_FULL_DIR_INFORMATION)buf)->FileName;
len = &(((PFILE_FULL_DIR_INFORMATION)buf)->FileNameLength);
break;
case FileDirectoryInformation:
p = ((PFILE_DIRECTORY_INFORMATION)buf)->FileName;
len = &(((PFILE_DIRECTORY_INFORMATION)buf)->FileNameLength);
break;
case FileIdBothDirectoryInformation:
p = ((PFILE_ID_BOTH_DIR_INFORMATION )buf)->FileName;
len = &(((PFILE_ID_BOTH_DIR_INFORMATION )buf)->FileNameLength);
sp = ((PFILE_BOTH_DIR_INFORMATION)buf)->ShortName;
slen = ((PFILE_BOTH_DIR_INFORMATION)buf)->ShortNameLength;
break;
...
}

STATUS_MEDIA_WRITE_PROTECTED

(hongyver) — Fri, 5 Dec 2008 09:29:53 +0900

파일 필터 드라이버 기능중에 이동저장장치(외장하드, USB저장장치등)에 쓰기금지기능이 있다.
이동저장장치에서 자유롭게 읽기는 가능해도 쓰기는 안되게 하는 기능인데...
이 기능이 다른 프로그램에서는 제대로 동작하는 한글2007에서는 원본파일을 강제로 2KB로 만들어 버린다.

코드를 살펴보니 IRP_MJ_WRITE시 STATUS_ACCESS_DENIED를 리턴하여 쓰기금지 기능을 수행하고 있다.
대체로 양호하게 동작을 수행하는데 유독 한글2007에서만 파일이 깨진다.

Filemon, Filespy로 IRP를 들여다 봐도 별반 차이가 없고 왜 그럴까 하던차에 SD 메모리카드에 lock기능이 있길래 lock으로 설정을 하고 쓰기기능을 수행한 결과.

눈에 띄는게 IRP_MJ_SET_INFORMATION의 FileEndOfFileInformation 일때STATUS_MEDIA_WRITE_PROTECTED 값을 리턴한다.

MSDN에 이런 내용이 있다.

FileEndOfFileInformation
This is called when someone is trying to change the logical size of the stream. Note that when the cache manager’s lazy writer thread attempts to set a new end of file no oplock check is made. This is because the check will have been made previously when the real write request came in.

결국 이동저장장치에 쓰기금지를 하려면
일반적으로 IRP_MJ_WRITE에서 막으면 되겠지만 프로그램에 따라(특히 한글2007 같이 cache를 사용한다면)...
IRP_MJ_SET_INFORMATION(FileEndOfFileInformation)에서도 알맞는 처리를 해줘야 한다.

NTSTATUS.H를 참조해서 STATUS_ACCESS_DENIED를 하던지...STATUS_MEDIA_WRITE_PROTECTED를 하던지 취향에 맞게 하면 되겠다.

비주얼스튜디오 단축키 - 정의바로가기를 되돌리기 CTRL+*

(hongyver) — Thu, 25 Sep 2008 08:39:52 +0900

코드를 분석하다가 보면...
특정 함수나 변수명의 선언이나 정의를 보고 싶을때...
무심코 F12(CTRL+F12) 또는 마우스 오른쪽을 눌러 "선언으로 이동" 또는 "정의로 이동"를 사용한다.
그런데 문제는 대충 함수(변수)의 정의나 선언을 살펴보고 바로 이전으로 되돌아 가고 싶은데 북마크나 보고있던 부분의 line의 줄수를 특별히 기억해 두고 있지 안았다면 낭패
늘 어디더라 하면서 찾기가 일쑤였는데...

그럴땐 CTRL+*(숫자패드의 *)를 눌러보자.
그럼 이전 코드부분으로 되돌려진다.
아마도 정의 또는 선언으로 이동할때 위치를 스택에 저장하는듯 하다.

나도 어디선가 주워들은 내용인데 MSDN이며 구글링을 해도 찾지를 못하겠다.
회사 동료가 보다가 신기해 하길래 포스팅.

더불어 가급적 마우스를 안쓰고 키보드로 해결하려고 노력중인 단축키들...

블럭 주석달기
CTRL+K, CTRL+C 주석 블럭 설정
CTRL+K, CTRL+U 주석 블럭 해제

마우스로 상단 파일이동이 아닌 키보드로 파일간 이동
CTRL+TAB, CTRL+SHIFT+TAB

중간중간 분석한 부분을 잊어버리지 않기 위해 북마크(가끔은 브레이크 포인터도 쓴다는...)
F2, CTRL+F2

창이동
ALT+0 소스코드창으로
ALT+2 출력창으로
가장 필요한 찾기창은 CTRL+TAB으로 대신....(이거 단축키는 없나?)

{ } 짝 찾기
CTRL+]

ps.
디버깅시 실시간으로 GetLastError 값알아내기(이것도 회사동료가 신기해 하던...Debugging Applications 책 참조)
조사식(watch)창의 이름(Name)에 @ERR 값 입력

Windbg에서 조건문 bp

(hongyver) — Wed, 18 Jun 2008 08:38:20 +0900

MSDN 블러그를 보다 보니...
Windgb로 조건문 bp 사용에 대해 자세한 설명을 해놓았다.
http://blogs.msdn.com/debuggingtoolbox/archive/2008/06/12/special-command-if-and-j-to-use-in-breakpoints-and-scripts.aspx

특정 지점에서 10번째 카운터에서 bp를 잡는 예제를 아래와 같이 써두었는데...

r @$t0 = 0
bp mtgdi!CBallThread::SingleStep "r @$t0 = @$t0 + 1;.if(@$t0 > 0n10){.echo More than 10 times...}.else{ gc }"

누군가 달아놓은 코멘트가 압권...

bp mtgdi!CBallThread::SingleStep 10

딸랑 이 한줄이면 된단다.
하아...

Crash Dump Analysis 책 발매

(hongyver) — Wed, 16 Apr 2008 09:25:43 +0900

언제가 회사에서 개발자 면접이 있을때 자리를 함께할 기회가 있었다.
이런 저런 이야기를 하다 디버깅에 대한 이야기가 나왔는데...
면접자가 말하기를...
Windbg며 Softice며 쓸 필요가 있냐....코딩을 잘하면 된지...
그자리에서는 그냥 웃고 말았는데...
개발자에 있어서 디버깅은 설계와 구현 못지 않은 내공에 대한 기준이다.
게다가 디버깅이란게 설계와 구현에 관한 만큼 정형화되어 있지도 않기 때문에...
디버깅의 지식 습득이란게 경험외에는 다른 대안이 없다.
디버깅은 그만큼 개발자의 경험을 반영한다고 하면 디버깅 능력을 무시 못하겠다.

그런 의미에서 지금 소개하려는 Dmitry Vostokov라는 개발자가 쓴 Crash Dump Analysis라는 책에 의미가 있다.
디버깅 전반적인 내용은 아니지만 "Crash Dump 파일 분석"에 대한 실예제 글인데 틈틈히 블러그에 올린 글을 모아놓은 책이다.
RSS로 구독하여 시간나면 읽어야지 하면서도 읽지 못했는데 책으로 나온다니 반가운 소식이다.

사실은 드라이버온라인에 drost라는 분이 이 내용을 번역해서 종종 올리기도 하였는데 어쩌면 한글판도 기대해도 좋을지 모르겠다.

CrashFinder

(hongyver) — Wed, 13 Feb 2008 10:10:08 +0900

회사동료가 help를 요청하길래 얼마전 이야기했던 MAP파일 생성으로 에러 발생한곳 찾기로 문제가 발생한곳을 찾으려고 했더니...
2005 프로젝트에서 아무리해도 map 파일을 제대로 생성할수 없었다.

포기할수 없어 구글링을 통해 알아보니...
CrashFinder 라는 프로그램을 사용하면 굳이 복잡한 과정을 거치지 않아도 쉽게 알수 있다.
에러가 발생한 곳의 주소를 입력하여 파일명와 에러난 줄번호를 바로 알수있다.
(초간단 사용예는 이곳 참조, 영문doc)

CrashFinder 다운받기

추가로 pdb 파일 생성에 관한 Bugs Layer 기사 참조
http://www.microsoft.com/msj/0498/bugslayer0498.aspx

글의 요지는...
1. 디버그 심볼은 디버그 빌드에서만 생성할수 있는게 아니다. Release 빌드시도 pdb 생성하여 에러 발생시 심신을 편하게 하자.

설정 방법은...
cl.exe, C++ tab에서
/Zi - Debug Info를 Program Database로 설정

Link.exe, link탭에서
/DEBUG - generate debuginfo 선택
/PDB:"파일명" - user program data base 체크 및 이름추가

2. reversing에 대한 염려도 없다. 프로그램은 약 1kb, pdb 파일이름만 기록

PDB 생성하면서 Release 빌드

PDB 생성하지 않고 Release 빌드

차이점은 NB10으로 시작하는 디버그헤더와 pdb path 만 추가되어있다.

3. dll의 경우 rebase를 통한 로드주소 정리
Debuggin Applications 책에서도 언급되었던 내용으로 상당수의 dll이 0x10000000에 로드되려하기 때문에 이로인한 부하를 줄이기 위해서 dll별 로드되는 주소를 설정.
빌드시 설정하여도 되고 rebase.exe라는 유틸을 사용하여도 무방

4. pdb와 exe 보관
각 버전에 맞는 pdb와 exe를 보관
소스관리툴을 사용하고 파일별 버전을 관리한다면 따로 보관하지 않아도 될듯하다.

결론은...
릴리즈 빌드시 pdb를 생성해서 배포하고(드라이버는 자동으로 pdb가 생성된다) dll은 시작주소를 기본값(0x10000000)이 아닌 다른 값(Debugging Application 책에 권장방법이 있다)으로 설정한다.
에러발생시 Windbg를 사용할 여건이 안된다면 CrashFinder로 분석하고 여건이 허락한다면 Windbg를 통해 분석하자.

Nt vs Zw - Clearing confusion on the Native API

(hongyver) — Tue, 16 Oct 2007 14:16:09 +0900

Preface

원문(OSR)의 글을 요약, 이해 정리한 글이다.

아래의 4가지 시나리오를 통해 NtXxx 함수와 ZwXxx함수에 대해 알아보자.
UserMode에서 NtXxx(NTDLL.DLL) 함수 호출하기
UserMode에서 ZwXxx(NTDLL.DLL) 함수 호출하기
KernelMode에서 NtXxx(NTOSKRNL.EXE) 함수 호출하기
KernelMode에서 ZwXxx(NTOSKRNL.EXE) 함수 호출하기

Calling From User Mode

NTDLL.DLL에서 NtXxx의 함수 NtReadFile을 Windbg에서 U 명령어를 통해 disassemble 한 결과는 아래와 같다.

0: kd> u ntdll!NtReadFile
ntdll!NtReadFile:
77f761e8 b8b7000000 mov eax,0xb7
77f761ed ba0003fe7f mov edx,0x7ffe0300
77f761f2 ffd2 call edx
77f761f4 c22400 ret 0x24

0: kd> u ntdll!ZwReadFile
ntdll!NtReadFile:
77f761e8 b8b7000000 mov eax,0xb7
77f761ed ba0003fe7f mov edx,0x7ffe0300
77f761f2 ffd2 call edx
77f761f4 c22400 ret 0x24

NtReadFile과 ZwReadFile은 0x77f761e8의 동일주소를 가르킨다.
CALL EDX의 0x7ffe0300의 주소를 ln(list nearest symblos) 명령을 통해 심볼을 본다.

0: kd> ln 0x7ffe0300(7ffe0300) SharedUserData!SystemCallStub
Exact matches:
SharedUserData!SystemCallStub

0: kd> u SharedUserData!SystemCallStub
SharedUserData!SystemCallStub:
7ffe0300 8bd4 mov edx,esp
7ffe0302 0f34 sysenter
7ffe0304 c3 ret

SystemCallStub이란 함수에서 SYSENTER(윈도우2000에서는 INT 2Eh)를 호출한다.

SYSENTER(INTEL document)란?

thread into Kernel Mode and executes the routine pointed to by the SYSENTER_EIP_MSR, which is MSR 0x176.

커널로 전환하며 SYSENTER_EIP_MSR 레지스터가 가르키는 포인터 번지를 실행한다.

rdmsr(read msr, msr은 model specific register) 명령어로 SYSENTER_EIP_MSR를 살펴보면

0: kd> rdmsr 176
msr[176] = 00000000:8053a270

0: kd> ln 8053a270
(8053a270) nt!KiFastCallEntry | (8053a2fb) nt!KiSystemService
Exact matches:
nt!KiFastCallEntry

결국 SYSENTER KiFastCallEntry를 호출한다는걸 알수있다.

053a2f9 eb5c jmp nt!KiSystemService+0x5c (8053a357)

KiFastCallEntry의 마지막(?)을 보면 KiSystemService를 호출한다.

아래는 OSR에서 제공한 windbg용 확장 DLL을 설치(windbg내 winext폴더에 복사)하여 !osrexts.sst를 사용하여 System Service Descriptor Table의 내용을 살펴보고 실제 주소를 disassemble한 예제이다.

0: kd> !osrexts.sst
0: 0x805912c2 (nt!NtAcceptConnectPort)
1: 0x805d87b0 (nt!NtAccessCheck)
2: 0x805dc3e4 (nt!NtAccessCheckAndAuditAlarm)
...
b7: 0x8056b2ec (nt!NtReadFile)
...

0: kd> u nt!NtReadFile
nt!NtReadFile:
8056b2ec 6a58 push    0x58
8056b2ee 6858044e80 push    0x804e0458
8056b2f3 e8e09ffcff call    nt!_SEH_prolog (805352d8)
8056b2f8 33ff xor edi,edi
8056b2fa 897de4 mov [ebp-0x1c],edi
8056b2fd 897de0 mov [ebp-0x20],edi
8056b300 897dd8 mov [ebp-0x28],edi

요약

User mode에서 NtXxx , ZwXxx 호출은 결국 같은 루틴이다.
EAX에 index, EDX에 argument pointer 설정
SystemCallStub 를 호출하여 SYSENTER 호출
SYSENTER 는 인터럽트 방지하고 커널모드로 thread를 변경 SYSENTER_EIP_MSR (XP SP1에서는 KiFastCallEntry)를 호출
KiFastCallEntry 는 새로운 trap frame 형성, 인터럽트 사용가능후 KiSystemService 호출
KiSystemService 는 EDX를 통해 파라미터를 전달받고 EAX의 인덱스에 따라 KiServiceTable[EAX] 함수 호출

Calling From Kernel Mode

NTOSKRNL.EXE에서 NtXxx의 함수 NtReadFile을 Windbg에서 U 명령어를 통해 disassemble 한 결과는 아래와 같다.
(NTOSKRNL.EXE 모듈의 심볼명은 nt 이다. 이는 CPU 에 따라 NTOSKRNL.EXE의 이름이 변경되지만 심볼명은 nt 하나로 통일하기 위한것이 아닐까 라고 추정 - 이재홍님)

0: kd> u nt!NtReadFile
nt!NtReadFile:
8056b2ec 6a58    push    0x58
8056b2ee 6858044e80 push    0x804e0458
8056b2f3 e8e09ffcff    call    nt!_SEH_prolog (805352d8)
8056b2f8 33ff xor edi,edi

NtReadFile은 원래 함수라고 보여진다.

0: kd> u nt!ZwReadFile
nt!ZwReadFile:
80504d4c b8b7000000 mov eax,0xb7
80504d51 8d542404 lea edx,[esp+0x4]
80504d55 9c    pushfd
80504d56 6a08 push    0x8
80504d58 e89e550300 call    nt!KiSystemService (8053a2fb)
80504d5d c22400 ret 0x24

ZwReadFile은 이전에 보았던 코드와 유사하다.
EAX에 index 번호 0xb7을 넣고 EDX에 argument pointer를 설정하고 PUSHFD(PUSH EFLAGS)후 KiSystemService 바로 호출

KernelMode이기 때문에 KernelMode로 전환하기 위한 SYSENTER와 KiFastCallEntry 생략되었다.

아래그림은 EFLAGS

요약

Case A:
Kernel Mode 에서 NtXxx 함수 호출
PreviousMode 변경이 없다.
Case B:
Kernel Mode 에서 ZwXxxx 함수 호출
EAX에 index 번호 0xb7을 넣고 EDX에 argument pointer를 설정하고 PUSHFD(PUSH EFLAGS)후 KiSystemService 바로 호출
PreviousMode KernelMode로 설정
CALL KiServiceTable[EAX]

중요한 차이는 KiSysstemService를 통한 과정은 previous mode가 커널모드로 설정하는것이다.
Nt를 바로 호출하는게 overhead가 없지만 Zw호출은 previousmode를 변경한다.

Previous Mode

Previous mode란 시스템이 시스템 서비스를 호출하는 곳의 모드를 결정하기 위한 indicator로 사용된다.
Previous mode가 User mode로 설정되면 시스템 서비스 처리 루틴은 호출은 User mode에서 호출되는것으로 인식하고 루틴으로 전달된 파라미터를 사용하기전에 유효성 검사를 필요로 한다.
하지만 커널모드는 그러한 세밀한 조사를 하지 않고 유효하다고 가정한다.

Previous Mode를 구하는 API

KPROCESSOR_MODE ExGetPreviousMode( VOID );

ZwXxx, NtXxx 호출시 실패하는 경우

NtXxx 함수를 직접 호출하면 previous mode를 변경되지 않기때문에 호출된 NtXxx 커널 시스템 서비스 루틴이 previous mode가 user mode로 설정된채 임의 user stack상에서 실행될수 있다. 이러한 호출은 Parameters의 유효성 확인 시도를 알지 못하기 때문에 호출실패가 발생할수 있다.
또다른 문제점은 ProbeForRead, ProbeForWrite를 통해 메모리가 Usermode의 메모리인지를 검사할때 Previous mode가 user mode로 설정된 상태에서 시스템 서비스 NtXxx 함수 호출시 커널모드 버퍼를 인자로 넘겨준다면 STATUS_ACCESS_VIOLATION이 발생할수 있다.

Sample Code

Sample code는 드라이버에서 c: 드라이버에 파일로 로그를 남기는 코드
InitializeObjectAttribute함수를 통해 c: 드라이버에 파일에 대한 핸들생성

(Language : c)

switch (operation)
{
case IOCTL_OSR_ENABLE_LOGGING:
if (!devExt->LoggingEnabled)
{
RtlInitUnicodeString(&logFileName, OSRNTAPI_LOGFILE);
#ifdef USER_HANDLE
InitializeObjectAttributes(&oa, &logFileName, OBJ_CASE_INSENSITIVE,
NULL, NULL);
#else
InitializeObjectAttributes(&oa, &logFileName,
OBJ_CASE_INSENSITIVE|OBJ_KERNEL_HANDLE, NULL, NULL);
#endif
code = ZwCreateFile(&devExt->LogFileHandle,
GENERIC_WRITE | SYNCHRONIZE,
&oa, &iosb, …

위의 예제에서 볼수 있듯이 핸들의 2가지가 생성될수 있다.

첫번째는 User mode 상에서 생성된 핸들(같은 프로세스의 context상에서만 접근가능, 다른 프로세스 접근 불가능)과 OBJ_KERNEL_HANDLE의 옵션을 주고 생성한 커널핸들(모든 프로세스, 드라이버에서 접근가능)이 있다.

응용프로그램에서 ReadFile 호출
드라이버 IRP_MJ_READ dispatch 함수, 드라이버에서 log write 시도

(Language : c)

PreviousMode = UserMode
code = NtWriteFile(devExt->LogFileHandle,
NULL,
NULL,
NULL,
&iosb,
(PVOID)"OsrRead: NtWriteFile\r\n",
strlen("OsrRead: NtWriteFile\r\n"),
NULL,
NULL);
#ifdef USER_HANDLE
ASSERT(code == STATUS_ACCESS_VIOLATION);
#else
// OBJ_KERNEL_HANDLE
ASSERT(code == STATUS_INVALID_HANDLE);
#endif

NtWriteFile 호출의 경우

#ifdef USER_HANDLE 정의시 (OBJ_KERNEL_HANDLE를 사용하지 않았을경우)STATUS_ACCESS_VIOLATION 에러발생
넘겨진 파라미터는 커널버퍼이지만 PreviousMode가 User 이므로 ProbeForRead/Write 를 통해 유효성 검사에서 실패하여 발생

#ifdef USER_HANDLE 미정의시(OBJ_KERNEL_HANDLE를 사용했을경우)STATUS_INVALID_HANDLE 에러발생
핸들생성시 커널핸들로 생성했지만 PreviousMode가 User 이므로 User모드 핸들에서는 커널핸들을 참조(찾을수 없다)할수없어 invalid 한 핸들에러 발생

(Language : c)

PreviousMode = KernelMode (KiSystemService에서 change)
code = ZwWriteFile(devExt->LogFileHandle,
NULL, NULL, NULL,
&iosb,
(PVOID)"OsrRead: ZwWriteFile\r\n",
strlen("OsrRead: ZwWriteFile\r\n"),
NULL, NULL);
ASSERT(code == STATUS_SUCCESS);

ZwWriteFile 호출의 경우
어떤 경우에서도 성공

Conclusion

User mode에서는 어떤것을 사용하여도 무방하나 kernel mode에서는 ZwXxx를 사용하여 previous mode가 커널로 설정되어 유효성 검사를 거쳐 시스템 서비스 함수들이 호출되도록 하여야 한다.

ETC

MSDN에 따르면 Zw로 시작하는 해당함수를 호출한 프로세스의 대한 접근권한 체크를 하지 않습니다.
http://msdn2.microsoft.com/en-us/library/ms804352.aspx

이 글은 스프링노트에서 작성되었습니다.

NativeAPI flowchart

(hongyver) — Wed, 10 Oct 2007 09:42:26 +0900

Doxygen 주석 작성을 위한 빠른보기

(hongyver) — Thu, 9 Aug 2007 11:31:48 +0900

MainPage

생성된 doc의 처음 화면이다.
보통 프로젝트 첫 화면이므로 전체 프로젝트에 한군데만 써 넣는다.

/// @mainpage doxygen 테스트 예제용 메인페이지
/// @section intro 소개
/// - 소개    : doxygen 을 사용하는 방법 설명
/// @section Program 프로그램명
/// - 프로그램명 : doxygen test sample
/// - 프로그램내용    : 화면에 Hello World!을 출력한다.
/// @section CREATEINFO 작성정보
/// - 작성자    : infiniterun
/// - 작성일    : 2005/04/18
/// @section MODIFYINFO 수정정보
/// - 수정자/수정일 : 수정내역
/// - infiniterun/2005.0418    : "Helo World"에 "!"추가

파일

파일에 대한 설명이므로 파일의 맨처음 부분에 넣는다.

/// @file doxygentest.c
/// @brief doxygentest 소스파일.

함수

함수의 기능과 리턴값을 설명하도록 한다.
보통 간단하게 아래와 같이 작성한다.

/// @brief string의 조사하여 babo라는 문구가 있는 찾는 함수
/// @param char* str char*형의 string을 입력한다.
/// @return boolean의 성공여부 , true이면 성공

필요에 따라 다음의 기능도 있다.

@author: 작성자 표시를 합니다.
@date: 작성일등의 날짜 표시를 합니다. 직접 기술 해야 합니다.
@see: 참고하는 함수/클래스등의 표시로 해당 항목(doxygen에서 존재하는)의 링크를 제공합니다.
@return: 함수의 리턴값에 대한 설명
@exception: exception처리에 대한 설명
@throw: throw하는 객체나 변수등에 대한 설명
@version; 버전설명
@warning: 경고
@bug: 버그에 대한 기술, 전체 항목의 @bug에 대해서 따로 리스트가 생성됩니다.
@todo: 해야할일들에 대한 기술, 전체 항목의 @todo에 대한 리스트가 생성됩니다.
@param: 함수의 파라미터 대한 정보를 기술 합니다.

파라미터에 대한 설명은 아래와 같이 입력할수도 있다.

int main( int argc, ///< 인자개수
char * argv[] ) ///< 인자

Class, 구조체, 변수

가급적 class, 구조체, 변수(global변수)의 상단에 설명을 작성한다.
/// 무엇을 하는 class, 구조체, 변수이다.

class와 구조체는 아래와 같이도 작성할수 있다.
/// @class 클래스 설명
/// @struct
/// 구조체 설명

@brief 를 사용하여 설명을 작성할수도 있다.
변수명의 경우 상단에 작성을 하지않고 변수명과 같은라인에서 작성하고 ///< 로도 설명을 작성할수 있다.
int a; ///< 임의의 값

단 함수내부에 있는 변수들에 대한 설명은 작성할수 없다.

태그사용

목록을 위한 점 표시
/// - 원하는 내용

강조를 위한 굵은글씨
/// <b> 원하는 내용</b>

원하는 내용, 코드를 그대로 출력
/// <pre>
/// 원하는 내용
/// </pre>

이 글은 스프링노트에서 작성되었습니다.

DDKBUILD.CMD로 DDK빌드시 SOURCES 옵션

(hongyver) — Thu, 21 Jun 2007 09:40:21 +0900

지난 포스팅에 DDKBUILD.CMD를 통해 비주얼 스튜디오에서 드라이버 빌드를 하고 있는데...
사용하다 불편한게 있어서 몇가지 알아내 SOURCES의 옵셥설정.

MAP파일 생성하고 싶을때

SOURCES 파일에 아래 삽입

(Language : text)

LINKER_FLAGS=/MAP

빌드후 추가작업을 하고 싶을때(예제는 Post-build step 기능)

SOURCES 파일아래에 아래 삽입

(Language : text)

NTTARGETFILES=postbuild

makefile.inc 파일아래에 아래코드 삽입(생성된 파일복사하는 예제)

(Language : text)

postbuild:
!if "$(DDKBUILDENV)" == "chk"
md ..\$(OUTDIR)
copy $(TARGET) ..\$(OUTDIR)\$(TARGETNAME).sys /Y /B
!else
set
md ..\$(OUTDIR)
copy $(TARGET) ..\$(OUTDIR)\$(TARGETNAME).sys /Y /B
!endif

Go To Definition 을 사용가능하게 하려면

(F12 또는 마우스 우클릭)

SOURCES 파일에 아래 코드 삽입

(Language : text)

BROWSER_INFO=1
BROWSERFILE=$(TARGETNAME).bsc -n

단 Project Setting에서 Browse info file name에 TARGETNAME과 확장자 .bsc가 있는지 확인하고 없으면 써준다.