Driver Verifier 와 STATUS_WAIT_n
2012/11/07 08:55
작성중인 드라이버에 딱히 원인을 알수 없는 문제가 생겨 Driver Verifier 옵션을 모두 on 시키고 디버깅 작업시도.
드라이버를 UpperFilter 에 등록하고 IRP_MJ_PNP/IRP_MN_START_DEVICE 에서 STATUS_UNSUCCESSFUL를 return 하도록 하는 부분에서 Driver Verifier 가 아래와 같이 에러를 발생시켰다.
***********************************************************************
* THIS VALIDATION BUG IS FATAL AND WILL CAUSE THE VERIFIER TO HALT    *
* WINDOWS (BUGCHECK) WHEN THE MACHINE IS NOT UNDER A KERNEL DEBUGGER! *
***********************************************************************

WDM DRIVER ERROR: [xxxxx.sys @ 0xF77F1FE0] An IRP dispatch handler (
                  F77F1FE0 ) has returned a status that is inconsistent with
                  the Irp's IoStatus.Status field. ( Irp = 8746AE90 -
                  Irp->IoStatus.Status = 00000003 - returned = 00000000 )
IRP_MJ_PNP.IRP_MN_REMOVE_DEVICE -
[ DevObj=86C043B8, FileObject=00000000, Parameters=00000000 00000000 00000000 00000000 ]
http://www.microsoft.com/hwdq/bc/default.asp?os=5.1.2600&major=0xc9&minor=0x224&lang=0x9

Break, Ignore, Zap, Remove, Disable all (bizrd)?

IRP_MJ_PNP/IRP_MN_START_DEVICE 에서 STATUS_UNSUCCESSFUL 을 return 하는건 장치를 start 할수 없는경우 당연한 리턴값이므로 전혀 문제될것이 없다.

!drvstack 을 통해 driver stack 을 살펴보니 작성중인 드라이버 아래위로 VERIFIER 드라이버 보이고
작성중인 드라이버 앞단에서 status 값이 STATUS_SUCCESS 값이 아닌 STATUS_WAIT_2 또는 STATUS_WAIT_3 이 넘어온다.
그 값을 작성중인 드라이버에서는 STATUS_UNSUCCESSFUL 로 변경시켜 다시 아래의 VERIFIER 드라이버로 넘긴다.
(STATUS_WAIT_n 에 대한 정의는 아래와 같이 되어 있는데 전혀 도움이 안된다.)
0x00000001 STATUS_WAIT_1 The caller specified WaitAny for WaitType and one of the dispatcher objects in the Object array has been set to the signaled state.
이 과정에서 Driver Verifier 는 앞뒤의 status 값이 다르기 때문에 에러는 발생시킨다.
(Driver Verifier 의 모든 옵션을 on 했지만 아마도 Enhanced I/O verification 으로 추정)

그러면 왜 STATUS_SUCCESS 를 return 하지 않고 STATUS_WAIT_n 와 같은 값을 return 하는걸까?

아래 코드를 보면 IoCallDriver() 호출이후 성공시 다음 처리를 하도록 되어 있다.

status = IoCallDriver(...);
if status == STATUS_SUCCESS

그러나 위와 같은 코드에서는 Driver Verifier 옵션을 on 시켰을 경우 원하는 대로 동작하지 않는 경우가 생긴다.
물론 Driver Verifier 를 on 하지 않는 경우에도 원하는 동작을 하지 않는 경우가 생긴다.
(아래의 NT_SUCCESS macro 정의를 보면 성공값은 0으로 정의된 STATUS_SUCCESS 만 있는 것이 아니다.)

따라서 if 문 에서 성공값을 검사할때 STATUS_SUCCESS 값을 검사하지 않고 NT_SUCCESS(...)와 같은 macro 사용하여야 한다.

NT_SUCCESS(status)
 status의 값이 성공 유형에 대한 값(0−0x3FFFFFFF) 또는 정보 유형에 대한 값(0x40000000-0x7FFFFFFF) 이면 TRUE.

NT_INFORMATION(status)
 status의 값이 정보 유형에 대한 값(0x40000000-0x7FFFFFFF) 이면 TRUE.

NT_WARNING(status)
 status의 값이 경고 유형에 대한 값(0x80000000−0xBFFFFFFF) 이면 TRUE.

NT_ERROR(status)
 status의 값이 오류 유형에 대한 값(0xC0000000 - 0xFFFFFFFF) 이면 TRUE.


NTSTATUS 의 성공값 또는 기타 에러에 대한 검사는 NT_SUCCESS() 또는 NT_ERROR()를 사용해야 할듯.
2012/11/07 08:55 2012/11/07 08:55
Trackback Address :: 이 글에는 트랙백을 보낼 수 없습니다


inf 파일로 드라이버 설치시 경고창 없이 설치하기
2011/07/26 09:12
1. 64bit 에서 경고창 없이 설치

64bit OS에서 변경된 보안기능으로 서명되지 않은 장치 드라이버는 사용할수 없기 때문에 드라이버 파일에 모든 인증을 받아 사용해왔다.
XP 64bit에서는 NDIS 5.x 를 지원하는 Passthru를 기반으로 작성했고 64bit Win7에서는 NDIS 6.x 이상을 지원하는 filter를 기반으로 작성하였기 때문에 각각 inf 파일을 이용하여 설치해야 한다.
따라서 bindview 예제를 가지고 설치 테스트를 했는데 이 설치 과정에서 문제가 발생했다.분명 singtool로 드라이버 인증을 하였음에도 불구하고 서명되지 않은 어쩌구 저쩌구 설치하겠느냐? 설치하지 않겠느냐? 라는 대화창이 뜬다.
사용자에게 선택권을 주면 사용자가 설치하지 않는 경우가 있기 때문에 보안 프로그램 특성상 경고창 없이 설치를 해야만 하기때문에 이 과정을 강제로 skip을 해야한다.
사용자 삽입 이미지
서명 어쩌구 저쩌구 애매한 문구 때문에 다소 삽질(?)을 했으나 결국 inf파일로 설치하는 드라이버는 Windows Logo 관련 WHQL 인증을 받지 않으면 위와 같은 경고창이 뜨는걸 확인.
WHQL인증을 받아볼까 알아봤다가 .... 포기하고 ...결국 bindview 코드를 분석해서 수정하고 설치하는 몇차례 삽질을 거쳐 win7 64bit에서는 아래의 과정으로 경고창 없이 설치가 가능하다.

1. bindview 예제에 있는 SetupCopyOEMInf 를 생략하고 INetCfgClassSetup class의 Install 을 통해서 설치하도록 설치 프로그램 작성
2. SetupCopyOEMInf 를 삭제했기 때문에 수동으로 inf, sys 파일을 windows\inf 폴더에 복사2. 설치프로그램을 통해 inf 파일로 드라이버 설치
3. windows\system32\drivers 폴더에 드라이버가 복사가 되지 않으니 수동으로 sys 파일을 복사이렇게 하면 Win7에서 경고창없이 설치가 되고 동작도 문제가 없다.(vista에서는 테스트 해보지 않았지만 문제없이 될거라고 생각한다.)그런데 문제는 XP 64bit의 Passthru를 설치하려고 했더니 설치가 되지 않는다.
우선 inf 파일이 2개 인데다가 Win7에서 설치한 방법으로는 드라이버 파일을 찾는 대화창이 표시된다.또 삽집을 통해 방법이 다소 다르지만 XP 64bit에서도 경고창 없이 설치가 가능하다.

1. bindview 예제에 있는 SetupCopyOEMInf 를 생략하고 INetCfgClassSetup class의 Install 을 통해서 설치하도록 설치 프로그램 작성(중요한건 2개의 inf 파일을 모두 같이 install 해야한다. 테스트해보니 미니포트용 inf (netsf_m.inf)를 설치하지 않아도 됨)
2. SetupCopyOEMInf 를 삭제했기 때문에 역시 마찬가지로 수동으로 2개의 inf, sys 파일을 windows\inf 폴더에 복사
3. inf 파일의 SourceDisksNames 섹션과 SourceDisksFiles 섹션의 항목을 주석처리하고 C:\WINDOWS\ServicePackFiles 에 sys 파일을 복사(sys 파일을 찾는 경로명을 생략하면 ServicePackFiles에서 드라이버를 찾기때문에)4. 설치프로그램을 통해 inf 파일로 드라이버 설치5. windows\system32\drivers 폴더에 드라이버가 복사가 되지 않으니 수동으로 sys 파일을 복사 Unintalll은 설치과정의 반대로만 하면된다.


2. 32bit에서 경고창없이 설치


win7에서는 64bit와 같은 과정을 통하면 경고창 없이 설치가능하였음.
혹시 그래도 경고창이 뜬다면 아래 링크참고.
테스트는 해보지 않았으니 참고할것.(disable하여 설치후 다시 enable하면 크게 문제 없을듯)
http://www.killertechtips.com/2009/05/05/disable-driver-signing-windows-7/
XP에서는 64bit에서 처럼 설치하였더니 실패.
레지스트리에 HKEY_LOCAL_MACHINE\Software\Microsoft\Driver Signing 를 0으로 설정하여야 함.
하지만 쉽게 변경이 되지 않으니 아래 링크를 참고
Osrloader.exe 로 서비스 생성(모든 옵션은 그냥 디폴트로 설정)후 테스트 해볼것.

gabriel 님 리플 정리(테스트 해보지 않았으니 실제 적용시 테스트 하셔야 합니다.)

1. xp 드라이버서명 무시는 아래의 코드를 참조하시고 예제 처럼 사용하시면 됩니다.

예제)
SetRegistyDriverInstall(0); //xp 드라이버설치 무시
...드라이버설치코드...
SetRegistyDriverInstall(1);//xp 드라이버설치 경고

서명무시하는 코드
void SetRegistyDriverInstall(BYTE ignoreOn)

{
HCRYPTPROV hCryptProv;
HCRYPTHASH hHash;
BYTE data[16];
DWORD len;
DWORD seed;
HKEY hkey;
char input[4];

// HKLM\System\WPA\PnP\seed
if(RegOpenKeyEx(HKEY_LOCAL_MACHINE, "System\\WPA\\PnP", 0, KEY_READ, &hkey)!=ERROR_SUCCESS)
{
return ;
}

len=sizeof(seed);
if(RegQueryValueEx(hkey, "seed", NULL, NULL, (BYTE*)&seed, &len)!=ERROR_SUCCESS)
{

}

if(hkey)
{
RegCloseKey(hkey);
}

if(CryptAcquireContext(&hCryptProv, NULL, NULL, PROV_RSA_FULL, 0)) // flag values
{

}
else
{
if (GetLastError() == NTE_BAD_KEYSET)
{  
if(CryptAcquireContext(&hCryptProv, NULL, NULL, PROV_RSA_FULL, CRYPT_NEWKEYSET))
{
}
}
} // End of else.

//--------------------------------------------------------------------
// Create a hash object.

if(!CryptCreateHash(hCryptProv,CALG_MD5,0,0,&hHash))
{
return ;
}
//--------------------------------------------------------------------
// Compute the cryptographic hash on the data.

input[0]=0;
input[1]=ignoreOn; // This is the Value!
input[2]=0;
input[3]=0;

if(!CryptHashData(hHash, (BYTE*)input, sizeof(input), 0))
{
return ;
}
//--------------------------------------------------------------------

if(!CryptHashData(hHash, (BYTE*)&seed, sizeof(seed), 0))
{
return ;
}

//--------------------------------------------------------------------
len=sizeof(data);
if(!CryptGetHashParam(hHash, HP_HASHVALUE, data, &len, 0))
{
return ;
}

//--------------------------------------------------------------------
// Clean up.

// Destroy the hash object.

if(hHash)
{
if(!(CryptDestroyHash(hHash)))
{
return ;
}
}

// Release the CSP.

if(hCryptProv)
{
if(!(CryptReleaseContext(hCryptProv,0)))
{
return ;
}
}

//--------------------------------------------------------------------
// HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\PrivateHash
if(!RegOpenKeyEx(HKEY_LOCAL_MACHINE, "Software\\Microsoft\\Windows\\CurrentVersion\\Setup", 0, KEY_WRITE, &hkey)!=ERROR_SUCCESS)
{
len=sizeof(seed);
if(RegSetValueEx(hkey, "PrivateHash", 0, REG_BINARY, data, sizeof(data))!=ERROR_SUCCESS)
{
}

if(hkey)
{
RegCloseKey(hkey);
}
}

//--------------------------------------------------------------------
// HKLM\Software\Microsoft\Driver Signing\Policy
if(!RegOpenKeyEx(HKEY_CURRENT_USER, "Software\\Microsoft\\Driver Signing", 0, KEY_WRITE, &hkey )!=ERROR_SUCCESS)
{
len=sizeof(seed);
if(RegSetValueEx(hkey, "Policy", 0, REG_BINARY, &ignoreOn, 1)!=ERROR_SUCCESS)
{
}

if(hkey)
{
RegCloseKey(hkey);
}
}
//--------------------------------------------------------------------
// HKLM\Software\Microsoft\Driver Signing\Policy
if(!RegOpenKeyEx(HKEY_LOCAL_MACHINE, "Software\\Microsoft\\Driver Signing", 0, KEY_WRITE, &hkey )!=ERROR_SUCCESS)
{
len=sizeof(seed);
if(RegSetValueEx(hkey, "Policy", 0, REG_BINARY, &ignoreOn, 1 )==ERROR_SUCCESS)
{
}

if(hkey)
{
RegCloseKey(hkey);
}
}
}

2. 윈도우 7 에서의 방법
저 같은 경우 display드라이버라서 INetCfgClassSetup 함수와는 매칭 이 되지 않았습니다.
그래서 안되는가 하고 고민하다가 우연찬게 알수없는 드라이버 상태에서 다시시작을 누르게 됐는데 그 순간 바로 설치가 되더라구요.
말이 길어 졌는데 짧게 말씀드리자면
1.windows/inf로 드라이버을 복사한다
2.UPDATEDRIVERFORPLUGANDPLAYDEVICES로 설치할때 실패하도록한다(성공하도록하면 경고창에 뜨기 때문에 실패할수 있는 옵션을 넣으면 됩니다)
3.드라이버을 다시시작한다.
이렇게 하면 경고창 없이 자동으로 설치가 됩니다.
그리고 저같은 경우 디지탈인증을 서명한 상태였습니다 서명이 안되면 3번에서 경고창이 뜹니다.
재생각에는 서명한 상태에서 저와 같은 방식을 사용하면 모든 드라이버가 자동으로 설치가 되지 않을까 생각합니다. 
2011/07/26 09:12 2011/07/26 09:12
Trackback Address :: 이 글에는 트랙백을 보낼 수 없습니다


이름변경을 위한 IRP_MJ_SET_INFORMATION IRP 생성
2011/06/21 09:58


기본적으로 ZwSetInformationFile 함수를 사용하나 rootkit등의 우회나 이름 변경시 추가 작업을 위한 hook등이 필요할때 드라이버에서 IRP_MJ_SET_INFORMATION IRP를 생성하여 파일의 이름을 변경한다.

파일명은 //device//harddiskvolume[n]//path를 포함한 file명 또는 //??//[drive]://path를 포함한 file명, //DosDevice//[drive]://path를 포함한 file명 와 같이 설정하는 점과 직접 생성한 IRP 이므로 완료루틴에서 pending 처리하지 않는다는 점을 고려한 대략의 코드는 아래와 같다.

IRP_MJ_SET_INFORMATION의 dispatch 루틴에서 특정 원본 파일의 이름을 강제로 a.ppt로 변경하는 코드이므로 원하는 파일명을 rename 하기 위해서는 추가적으로 FileObject를 구하여 한다.

XP에서 간단한 테스트는 문제없었으나 실제 사용을 위해서는 OSR의 Cracking Rename Operations 참고하여 수정하여 사용할것.(책임회피)
http://www.osronline.com/article.cfm?article=85
{
	...

	PIO_STACK_LOCATION pIrpSp;
	KEVENT event;
	NTSTATUS status;
	PIRP pNewIrp = NULL;
	PFILE_RENAME_INFORMATION pNewRename = NULL;
	ULONG NewRenameLen =  wcslen(L"\\??\\c:\\a.ppt") * 2;
	ULONG NewRenameSize = sizeof(FILE_RENAME_INFORMATION) + NewRenameLen;

	KeInitializeEvent(&event, SynchronizationEvent, FALSE);

	pNewRename = ExAllocatePoolWithTag(PagedPool, NewRenameSize, 'hong');
	if(pNewRename == NULL)
	   /// return 리소스부족;

	memcpy(pNewRename, pRenameInfo, sizeof(FILE_RENAME_INFORMATION));
	pNewRename->FileNameLength = NewRenameLen;
	wcsncpy(pNewRename->FileName, L"\\??\\c:\\a.ppt", NewRenameLen/2);

	pNewIrp = IoAllocateIrp(DeviceObject->StackSize, FALSE);
	if(pNewIrp == NULL)
	   /// return 리소스부족;

	pNewIrp->Flags |= IRP_BUFFERED_IO;
	pNewIrp->RequestorMode = KernelMode;
	pNewIrp->UserIosb = &pIrp->IoStatus;
	pNewIrp->UserEvent = &event;
	pNewIrp->Tail.Overlay.OriginalFileObject = currentIrpStack->FileObject; // 원본 File Object
	pNewIrp->Tail.Overlay.Thread = PsGetCurrentThread();
	pNewIrp->AssociatedIrp.SystemBuffer = (PVOID)&pNewRename;

	pIrpSp = IoGetNextIrpStackLocation(pNewIrp);
	pIrpSp->MajorFunction = IRP_MJ_SET_INFORMATION;
	pIrpSp->FileObject = currentIrpStack->FileObject; 
	pIrpSp->DeviceObject = DeviceObject;
	pIrpSp->Parameters.SetFile.Length = NewRenameSize;
	pIrpSp->Parameters.SetFile.FileInformationClass = FileRenameInformation;
	pIrpSp->Parameters.SetFile.FileObject = currentIrpStack->FileObject;
	pIrpSp->Parameters.SetFile.ReplaceIfExists = pNewRename->ReplaceIfExists;

	IoSetCompletionRoutine(pNewIrp, CompleteRoutine, 0, TRUE, TRUE, TRUE);
	IoCallDriver( devExt->NLExtHeader.AttachedToDeviceObject, pNewIrp );
	KeWaitForSingleObject( &event, Executive, KernelMode, TRUE, 0);
	ExFreePoolWithTag(pNewRename, 'hong');

        ...
}
/// 직접만든 IRP는 pending을 하지 않음
NTSTATUS CompleteRoutine(PDEVICE_OBJECT DeviceObject, PIRP Irp,PVOID Context)
{
	*Irp->UserIosb = Irp->IoStatus;
	KeSetEvent(Irp->UserEvent, 0, FALSE);
	IoFreeIrp(Irp);

	return STATUS_MORE_PROCESSING_REQUIRED;
}
2011/06/21 09:58 2011/06/21 09:58
Trackback Address :: 이 글에는 트랙백을 보낼 수 없습니다


FileSystemFilterDriver 파일숨기기
2009/06/14 13:19

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->FileInformationClassFileBothDirectoryInformation

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

전처리

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

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

후처리

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

완료루틴

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;
...
}

2009/06/14 13:19 2009/06/14 13:19
Trackback Address :: 이 글에는 트랙백을 보낼 수 없습니다


STATUS_MEDIA_WRITE_PROTECTED
2008/12/05 09:29
파일 필터 드라이버 기능중에 이동저장장치(외장하드, 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를 하던지 취향에 맞게 하면 되겠다.
2008/12/05 09:29 2008/12/05 09:29
Trackback Address :: 이 글에는 트랙백을 보낼 수 없습니다


비주얼스튜디오 단축키 - 정의바로가기를 되돌리기 CTRL+*
2008/09/25 08:39
코드를 분석하다가 보면...
특정 함수나 변수명의 선언이나 정의를 보고 싶을때...
무심코 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 값 입력
2008/09/25 08:39 2008/09/25 08:39
Trackback Address :: 이 글에는 트랙백을 보낼 수 없습니다


Windbg에서 조건문 bp
2008/06/18 08:38

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

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


2008/06/18 08:38 2008/06/18 08:38
Trackback Address :: 이 글에는 트랙백을 보낼 수 없습니다


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

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

사실은 드라이버온라인에 drost라는 분이 이 내용을 번역해서 종종 올리기도 하였는데 어쩌면 한글판도 기대해도 좋을지 모르겠다.
2008/04/16 09:25 2008/04/16 09:25
Trackback Address :: 이 글에는 트랙백을 보낼 수 없습니다


CrashFinder
2008/02/13 10:10
회사동료가 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를 통해 분석하자.
2008/02/13 10:10 2008/02/13 10:10
Trackback Address :: 이 글에는 트랙백을 보낼 수 없습니다

  1. Subject: CrashFinder 사용법

    Tracked from 잡동사니 2008/05/05 06:33  삭제

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


Nt vs Zw - Clearing confusion on the Native API
2007/10/16 14:16

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 생략되었다.

아래그림은 EFLAGSeflags.jpg

요약

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)
  1. switch (operation)
  2. {
  3.    case IOCTL_OSR_ENABLE_LOGGING:
  4.       if (!devExt->LoggingEnabled)
  5.       {
  6.          RtlInitUnicodeString(&logFileName, OSRNTAPI_LOGFILE);
  7. #ifdef USER_HANDLE
  8.          InitializeObjectAttributes(&oa, &logFileName, OBJ_CASE_INSENSITIVE,
  9.                       NULL, NULL);
  10. #else
  11.          InitializeObjectAttributes(&oa, &logFileName,
  12.             OBJ_CASE_INSENSITIVE|OBJ_KERNEL_HANDLE, NULL, NULL);
  13. #endif
  14.          code = ZwCreateFile(&devExt->LogFileHandle,
  15.             GENERIC_WRITE | SYNCHRONIZE,
  16.             &oa, &iosb, …

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

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

응용프로그램에서 ReadFile 호출

드라이버 IRP_MJ_READ dispatch 함수, 드라이버에서 log write 시도

(Language : c)
  1. PreviousMode = UserMode
  2. code = NtWriteFile(devExt->LogFileHandle,
  3.       NULL,
  4.       NULL,
  5.       NULL,
  6.       &iosb,
  7.       (PVOID)"OsrRead: NtWriteFile\r\n",
  8.       strlen("OsrRead: NtWriteFile\r\n"),
  9.       NULL,
  10.       NULL);
  11. #ifdef USER_HANDLE
  12.    ASSERT(code == STATUS_ACCESS_VIOLATION);
  13. #else
  14. // OBJ_KERNEL_HANDLE
  15.    ASSERT(code == STATUS_INVALID_HANDLE);
  16. #endif
  17.  

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)
  1. PreviousMode = KernelMode (KiSystemService에서 change)
  2. code = ZwWriteFile(devExt->LogFileHandle,
  3.          NULL, NULL, NULL,
  4.          &iosb,
  5.          (PVOID)"OsrRead: ZwWriteFile\r\n",
  6.          strlen("OsrRead: ZwWriteFile\r\n"),
  7.          NULL, NULL);
  8. 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 

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

2007/10/16 14:16 2007/10/16 14:16
Trackback Address :: 이 글에는 트랙백을 보낼 수 없습니다