I am enumerating the loaded modules in a process address space by accessing PEB in
kernel mode. I am traversing InMemoryOrderModuleList member of PEB structure to
list the loaded modules.
But as I traversing the link list it is possible that it may not be in consistent state as
other thread in system may be adding or deleting a node in this list.
So I think it is not safe to traverse this list without synchronization. What do you think?
Also I want to know that is there any lock that is used to guard this list which we can
use to traverse it?
Accessing the PEB from the kernel is a bad idea period. You can get the
loaded modules by loading early and using the Ps callback, so why mess with
it?
wrote in message news:xxxxx@ntdev… > Hi All, > > I am enumerating the loaded modules in a process address space by > accessing PEB in > kernel mode. I am traversing InMemoryOrderModuleList member of PEB > structure to > list the loaded modules. > > But as I traversing the link list it is possible that it may not be in > consistent state as > other thread in system may be adding or deleting a node in this list. > > So I think it is not safe to traverse this list without synchronization. > What do you think? > > Also I want to know that is there any lock that is used to guard this list > which we can > use to traverse it? > > Thanks & Regards, > Amit. > > > Information from ESET NOD32 Antivirus, version of virus > signature database 4009 (20090415) > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > >
Information from ESET NOD32 Antivirus, version of virus signature database 4009 (20090415)
If you need to do this and can’t load early, perhaps doing this from user mode with the help of
toolhelp or whatever that library is now called or something along those lines?
mm
Don Burn wrote:
Accessing the PEB from the kernel is a bad idea period. You can get the
loaded modules by loading early and using the Ps callback, so why mess with
it?
> Hi All, > > I am enumerating the loaded modules in a process address space by accessing > PEB in > kernel mode. I am traversing InMemoryOrderModuleList member of PEB > structure to > list the loaded modules. >
Why are you accessing from kernel mode?
> > > But as I traversing the link list it is possible that it may not be in > consistent state as > other thread in system may be adding or deleting a node in this list. > > So I think it is not safe to traverse this list without synchronization. > What do you think? > > Also I want to know that is there any lock that is used to guard this list > which we can > use to traverse it? > > Thanks & Regards, > Amit. > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
This is wholly unsafe. There is no way to synchronize this, and you simply cannot follow unbounded user mode pointer chains.
The contents of the PEB may be tampered with anyway.
Bottom line: You cannot do this, in no uncertain terms. Any data you get back will be fakeable, not to mention the myriad bad things that will happen to you in the course of traversing user mode linked lists.
S
-----Original Message-----
From: xxxxx@yahoo.com Sent: Wednesday, April 15, 2009 01:56 To: Windows System Software Devs Interest List Subject: [ntdev] Enumerating loaded modules in a process
Hi All,
I am enumerating the loaded modules in a process address space by accessing PEB in kernel mode. I am traversing InMemoryOrderModuleList member of PEB structure to list the loaded modules.
But as I traversing the link list it is possible that it may not be in consistent state as other thread in system may be adding or deleting a node in this list.
So I think it is not safe to traverse this list without synchronization. What do you think?
Also I want to know that is there any lock that is used to guard this list which we can use to traverse it?
Actually there are APIs that operate in usermode such as tool help or PSAPI.
But I can not relay on the result of such APIs as they can be hooked and
result will be filtered to fool me.
I can take the risk to traverse the list as the software runs only on compramised
machines… But still we want to develope quality software by eliminating possibilities
of BSODs and Protection Folts.
Until the Loader-Lock is held, the list of loaded modules will not change (assumption). I don’t know exactly when windows acquires it, and maybe it’s too late (when the InMemoryOrderModuleList is synchronized by another primitive, not the loader lock).
If it is possible to acquire the loader-lock manually would this be a solution?
GP
powered by Exchange 2007 - hosted by a Microsoft Gold Partner - visit us www.world-direct.at
So can it be done in the case of what you’re trying to do, especially as your sample space consists
entirely of compromised machines. Also, in my opinion, it’s easier and more effective to mess with
the underlying system structures, because doing so will thwart those libraries, as well as anything
else that relies on the structures, as they are the ultimate source of information.
I hear what you are saying about the risk being ok because the machines is already trashed, but in
my opinion, that really misses the point - once a machine is compromised there is nothing that you
can do about other than reinstall, because you cannot make any guarantees about whatever you do to
‘fix’ the problem, because you have no idea of the state from which you started.
Now, certainly there are products which claim to be useful in this fashion, and if they sell, that’s
what matters to most people, so I’m not necessarily suggesting that proceeding is not an
unprofitable idea, just that it won’t work reliably in a general sense. If you don’t mind sharing,
what the purpose of this tool you’re developing? If you can survive a reboot, it seems like a
better option would be to install yourself early enough to use the Ps hooks before rebooting. It
would still be subject to the same invariant about once a machine is compromised, et. c, but it
would at least not cause BSOD’s, again assuming that the malware hasn’t truly damaged things. If
you can’t survive a reboot, then I have serious doubts that there is anything useful that can be
done in automated fashion.
Good luck,
mm
Amit Kulkarni wrote:
Hi All,
Actually there are APIs that operate in usermode such as tool help or PSAPI.
But I can not relay on the result of such APIs as they can be hooked and
result will be filtered to fool me.
I can take the risk to traverse the list as the software runs only on
compramised
machines. But still we want to develope quality software by eliminating
possibilities
of BSODs and Protection Folts.
Thanks & Regards,
Amit.
Add more friends to your messenger and enjoy! Invite them now. http:</http:>
Well please make sure you tell us your products name, so we can avoid it and
advise our customers to do the same. The definition of compromised is
always a fun one, OSR’s DeviceTree causes many pieces of software to issue
compromised alerts. Also, you have not stated how compromised, so what you
are saying is “because my software thinks something bad is happening then it
is ok for my software to do something that is likely to be bad”. Sorry
that is pretty much junk in my opinion.
“Amit Kulkarni” wrote in message news:xxxxx@ntdev… Hi All,
Actually there are APIs that operate in usermode such as tool help or PSAPI. But I can not relay on the result of such APIs as they can be hooked and result will be filtered to fool me.
I can take the risk to traverse the list as the software runs only on compramised machines… But still we want to develope quality software by eliminating possibilities of BSODs and Protection Folts.
This would allow user mode to deadlock your kernel mode code even if it were otherwise feasible.
You cannot grovel around in the user mode loader data structures from kernel mode. This is completely not the right solution to *any* problem.
I am unsure of how else to make that clear.
If you need to track loaded modules, use the PS callback. Be aware that just as with the loaded module list, there are a myriad of other ways for crafty code to load a blob of data and execute it.
S
From: G?nter Prossliner Sent: Thursday, April 16, 2009 01:01 To: Windows System Software Devs Interest List Subject: Re:[ntdev] Enumerating loaded modules in a process
Just a few thoughts:
Until the Loader-Lock is held, the list of loaded modules will not change (assumption). I don?t know exactly when windows acquires it, and maybe it?s too late (when the InMemoryOrderModuleList is synchronized by another primitive, not the loader lock).
If it is possible to acquire the loader-lock manually would this be a solution?
GP
________________________________ powered by Exchange 2007 - hosted by a Microsoft Gold Partner - visit us www.world-direct.at
Write a DLL which will traverse the list in its DllMain.
IIRC DllMain is called exactly with this lock held.
So you also think that holding the loader-lock will protect this linked list from modification? This was the thing I asked from my previous posting.
But AFAIK (I’m very new in the kernel-area), it’s not possible to load DLL dynamically from the Kernel. So a user-mode service would be required, which loaded a “dummy dll” when it is notified by the kernel code (maybe by an inverted call). Within the DllMain of the “dummy dll”, another IRP is send to the driver, which traverses the InMemoryOrderModuleList of the PEB, and then completes the IRP so that the DllMain exits and the “dummy dll” can be unloaded again.
Am I right so far?
But when I’m not completely wrong this way seems a little bit overcomplicated. So I would not recommend it. What do you think?
GP
powered by Exchange 2007 - hosted by a Microsoft Gold Partner - visit us www.world-direct.at
Please don’t be angry. My product will not harm you.
Please read my lines carefully.
I can take the risk to traverse the list as the software runs only
on compramisedmachines. But still we want to develope quality
software by eliminating possibilities of BSODs and
Protection Folts.
i.e. I have posted this problem because I know that it is bad
and I am seeking a solution to it. I think there is nothing
impossible if all you help me and that’s what you are doing
by communicating here freely.
Now comming to the point if I aquire loader lock?by traverse
list in driver entry, then it will protect the list for that perticular
process which loads my dll, as this lock is not system wide.
It is processwide lock as per microsoft documentation.
But I want to traverse lists of all processes running in the system.
I think it can be possible if…
I aquire lock protecting linklist(Which is probably loaderlock).
Anyhow processes is not allowed to be scheduled.
First is possible but for that I have to load my dll in all the
processes. Which is not possible for some processes.
Can I aquire loader lock of a process from another process/driver?
Can I disallow a process from scheduling?
Soory By mistake I have wirtten driver entry instead of DllMain.
Now comming to the point if I aquire loader lock?by traverse=0Alist in driver
entry, then it will protect the list for that perticular=0Aprocess which loads
my dll, as this lock is not system wide.
Suppose that someone hooked EnumProcessModules and filtered the result so that
I am not able to know which dlls are loaded in the process.
Now I just want to know that, What else I can do other than traversing the list in PEB.
If there is any safer way I will use it.
If you have a kernel-mode intruder that has compromised kernel-level
structures like this, then all is lost. The system is toast.
Seriously, there is no hope. You might be able to hack out some
information, but a sophisticated enough intruder is always one step
ahead of you, altering the data you are looking at.
Note that I’m not saying “difficult”. I’m saying “impossible”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> But I can not relay on the result of such APIs as they can be hooked and result will be filtered to fool me.
…and module may be unlinked from the list of loaded modules (you can take my words for granted because I tried it myself - Dll stays loaded because its refcount is nonzero, but PSAPI functions are unable to detect it)…
Don’t forget that PEB is accessible from the UM , and,hence, one does not even need admin privileges to hide a UM module. You are fighting a battle that you just cannot win, no matter how hard you try…
So the result of discussion is that traversing the list in PEB is not useful and reliable way to get loaded modules. Dll can be stays loaded in process address space even if it is not in link list. So traversing the list is really a bad idea.
But can we do one more thing that take a address in an address space and find out the region, then find out find out where or in which file this region is memory mapped or paged. Thus can we get the list of files mapped in process address space?
Is there any other way to list files mapped in process address space?