Page 1 of 1

Open handles of process and issue with handles

PostPosted: Tue Aug 04, 2009 9:17 am
by softtouch
Madkernel handle enumeration freeze identical to ntqueryobject with nameinfo.

The code below freeze at the same handle as NtQueryObject, when accessing the objname property.
Is there any way arounf, without using a driver to enumerate handles?

Code: Select all
   for i:=0 to processes.ItemCount-1 do
   begin
      p:=processes.items[i];
     if extractfiledir(p.ExeFile)='' then continue;
     for j:=0 to p.Handles.ItemCount-1 do
     begin
       with p do
       begin
           h:=handles.items[j];
          if not (h.ObjType in [otFile, otFileMapping]) then continue;
          if not h.IsValid then continue;
          if h.KernelObj.ObjName='' then continue;
          listbox1.items.add(h.KernelObj.ObjName);
         ListBox1.TopIndex:=ListBox1.count-1;
         application.ProcessMessages;
      end;
    end;
  end;

PostPosted: Thu Aug 13, 2009 4:51 pm
by madshi
First of all "Processes" is a function which internally enumerates all process. Everytime you call "Processes", a new enumeration is done. So basically you're enumerating processes a lot in that code. The same applies to "p.Handles". That's also a function, which enumerates handles everytime you call it.

You should work with "with" or you should do:

Code: Select all
var procs : IProcesses;
    hndls : IHandles;
begin
  procs := Processes;
  [...]
    hndls := procs[i].Handles;

But that has nothing to do with the real problem. I'm not sure where the freeze is coming from, but it seems to be caused by the win32 APIs, so there's not much I can do against it.

Maybe the problem only occurs with handles of some system processes? I've no idea, I'm just guessing...

PostPosted: Fri Aug 14, 2009 6:27 am
by softtouch
When filtering handles with a granted access of 0x0012019f, no freeze.
I then tried to figure out why, but nobody had an answer, and everybody tells me (on other forums too), that only a driver would be able to enumate all handles.

I then downloaded some example programs (c and delphi), and all freezing at that handle with that access.

I then checked what unlocker does, and indeed, it installs a driver for this purpose.

Seems to be a bug in the API and there is no way around it from userland.

PostPosted: Fri Aug 14, 2009 6:52 am
by softtouch
I found a solution.

I create a thread which will access the name object, with a timeout of 500ms.
When waitforsingleobject with a timeout of 1s returns with WAIT_OBJECT_0, I know the access was ok and I process the name.

Works just fine.

PostPosted: Fri Aug 14, 2009 6:57 am
by madshi
Check out madKernel.pas, it already does a similar thing.

PostPosted: Fri Aug 14, 2009 9:57 am
by softtouch
madshi wrote:Check out madKernel.pas, it already does a similar thing.


Seriously? Hell... but that code is almost 400kb, far too much to dig into.

PostPosted: Fri Aug 14, 2009 11:24 am
by madshi
You know, Delphi has a search function. NtQueryFileInformation. You could have thought of that yourself... :wink:

PostPosted: Fri Aug 14, 2009 11:29 am
by softtouch
madshi wrote:You know, Delphi has a search function. NtQueryFileInformation. You could have thought of that yourself... :wink:


Guess... I did that, but I could not find any NtQueryFileInformation inside madkernel.pas, but I found NtQueryObject which you used to get the name.
And yes, its similar to what I do. If you do it the same way, why does it hang when I access the objname property without doing the thread thing? The names should be all valid already when I access the structure...

PostPosted: Fri Aug 14, 2009 11:31 am
by madshi
Ok, so it's called NtQueryInformationFile.

PostPosted: Fri Aug 14, 2009 11:37 am
by softtouch
madshi wrote:Ok, so it's called NtQueryInformationFile.


Yes, I figured that out...
To my previous question, you get valid names, why does it freeze when reading the objname property with some handles? It should not because of your code in madkernel.pas.

PostPosted: Fri Aug 14, 2009 11:38 am
by madshi
I told you before: I don't know.