PDA

View Full Version : problema con NtQueryObject


GordonFreeman
05-10-2005, 03:31
rispondete in ita :)

after obtained all file handles open in the system,i have duplicated them in my
process,and i've queried them with NtQueryObject for
retrieving filenames...but with several handles my program goes in deadlock when it does the call , and i've also done checks for finding out what process those handles belong to,and these are some results

"C:\\WINDOWS\\system32\\ZoneLabs\\vsmon.exe"
"C:\WINDOWS\\system32\\services.exe"
"C:\\WINDOWS\\system32\\lsass.exe"
"C:\\WINDOWS\\system32\\svchost.exe"
...

but sincerely...i don't think that querying an handle that belongs to a system service (like all the processes listed above),makes a call to NtQueryObject to wait forever...however,this is the code


// some defines from ntddk

typedef struct _LSA_UNICODE_STRING {
USHORT Length;
USHORT MaximumLength;
PWSTR Buffer;
} LSA_UNICODE_STRING, *PLSA_UNICODE_STRING, UNICODE_STRING, *PUNICODE_STRING;

typedef struct _STRING {
USHORT Length;
USHORT MaximumLength;
PCHAR Buffer;
} ANSI_STRING, *PANSI_STRING;

typedef struct _OBJECT_ATTRIBUTES {
ULONG uLength;
HANDLE RootDirectory;
PUNICODE_STRING ObjectName;
ULONG Attributes;
PSECURITY_DESCRIPTOR SecurityDescriptor;
PVOID SecurityQualityOfService;
} OBJECT_ATTRIBUTES,*POBJECT_ATTRIBUTES;

typedef struct _CLIENT_ID {
DWORD UniqueProcess;
DWORD UniqueThread;
} CLIENT_ID, *PCLIENT_ID;

typedef struct _SYSTEM_HANDLE_INFORMATION {
USHORT ProcessId;
USHORT CreatorBackTraceIndex;
UCHAR ObjectTypeNumber;
UCHAR Flags;
USHORT Handle;
PVOID Object;
ACCESS_MASK GrantedAccess;
} SYSTEM_HANDLE_INFORMATION, *PSYSTEM_HANDLE_INFORMATION;

typedef struct _SYSTEM_HANDLE_INFORMATION_EX {
ULONG NumberOfHandles;
SYSTEM_HANDLE_INFORMATION Information[1];
} SYSTEM_HANDLE_INFORMATION_EX, *PSYSTEM_HANDLE_INFORMATION_EX;

typedef struct _OBJECT_NAME_INFORMATION {
UNICODE_STRING Name;
} OBJECT_NAME_INFORMATION, *POBJECT_NAME_INFORMATION;







// the code is incomplete,for readibility purpose

void GetFileHandles(){

HANDLE hThisProcess;
//.. initialize hThisProcess with GetCurrentProcess() and DuplicateHandle() ...

// ... use NtQueryObject for obtaining the "File" type index,to be compared
// with ObjectTypeNumber field of SYSTEM_HANDLE_INFORMATION ,because
// i'm interested in file handles only... that index will be hold in the
// uFileTypeIndex variable

// the pStruct variable points to the handle table ,it's a PSYSTEM_HANDLE_INFORMATION_EX
// obtained via NtQuerySystemInformation() with SystemHandleInformation parameter

ULONG uLen = sizeof(UNICODE_STRING) + (MAX_PATH + 1) * sizeof(WCHAR);

POBJECT_NAME_INFORMATION pNameInfo = (POBJECT_NAME_INFORMATION)malloc(uLen);

HANDLE hSourceProcess; // remote process
OBJECT_ATTRIBUTES oa;
CLIENT_ID ClientId;

for(ULONG u = 0;u < pStruct->NumberOfHandles;u++)

if(pStruct->Information[u].ObjectTypeNumber == uFileTypeIndex){ // check handle type,must be a file

HANDLE hSource = (HANDLE)pStruct->Information[u].Handle,hCopy;

memset(&oa,0,sizeof(oa));
ClientId.UniqueThread = 0;
ClientId.UniqueProcess = (DWORD)pStruct->Information[u].ProcessId;

if(NtOpenProcess(&hSourceProcess,PROCESS_ALL_ACCESS,&oa,&ClientId))
continue;

if(NtDuplicateObject(hSourceProcess,hSource,hThisProcess,&hCopy,PROCESS_QUERY_INFORMATION,0,0))
continue;

// with some file handles this call will not return...???

if(NtQueryObject(hCopy,ObjectNameInformation,pNameInfo,uLen,NULL)){
CloseHandle(hSourceProcess);
CloseHandle(hCopy);
continue;
}

//... do something with the filename,in pNameInfo->Name.Buffer

CloseHandle(hCopy);
CloseHandle(hSourceProcess);

}

CloseHandle(hThisProcess);
free(pNameInfo);
free(pStruct);

}

GordonFreeman
05-10-2005, 23:40
up

cionci
06-10-2005, 09:46
In generale questa procedura ti funziona con gli altri processi che non siano servizi ?

GordonFreeman
06-10-2005, 20:12
In generale questa procedura ti funziona con gli altri processi che non siano servizi ?

risposta mia in un altro forum:

someone told me:

--------------------------------------------------------------------------------

Your problem is this:

When you query for object name on a pipe handle (opened for synchronous io, and where there are pending read operations) then your thread will hang. Permanently. And attempts to terminate the thread will possibly end in a bluescreen.

There is no difference between system services and other applications, besides that services more often uses pipes.

I don't know of solutions around this problem. GetFileType(...) and other attempts to determine that is it a pipe object will deadlock aswell. Plain stupid.

- petter
-------------------------------------------------------------------------

allora,la mia procedura funziona solo con gli handle a file non sincronizzati,cioè che non siano pipes etc. , non c'entra niente se il processo a cui appartiene l'handle è di sistema o no...

secondo te come si può risolvere?

io proporrei di chiederlo al kernel il nome dell'handle,cioè interrogando il file system driver...ma come si fa??

oppure proponimi altre soluzioni