If we have a kernel dump then what would be the best way to find out the set of services being hosted in a particular svchost.exe ? As of now, I dump the svchost’s vad root (available from “!process 5” output) and then try to make a good guess based on the list of loaded dlls that I get back in the vad tree dump. Is there a better way to do this ?
You might be able to use ‘!reg’ to inspect the services keys and make some
sort of guess based on that. Not great, to be sure, but I don’t know of any
good way to what you seek from a crash dump.
Something like:
!reg findkcb \REGISTRY\MACHINE\SYSTEM\CONTROLSET001\SERVICES
Found KCB = fffff8a00009e008 ::
\REGISTRY\MACHINE\SYSTEM\CONTROLSET001\SERVICES
Good luck,
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Tuesday, March 08, 2011 5:49 AM
To: Kernel Debugging Interest List
Subject: [windbg] finding the set of services hosted in a shared svchost
while inside a kernel dump
If we have a kernel dump then what would be the best way to find out the set
of services being hosted in a particular svchost.exe ? As of now, I dump the
svchost’s vad root (available from “!process 5” output) and
then try to make a good guess based on the list of loaded dlls that I get
back in the vad tree dump. Is there a better way to do this ?
—
WINDBG 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
It might not be 100% accurate but if you know the service you are
after (e.g. its dll name) you could switch to particular svchost.exe
process (e.g. “.process /P /r ”) and then list all user mode
modules (e.g. “lmu”) and finally check whether service you are looking
for is on the module list.
You could probably combine this method with Martin’s suggestion about
getting information about all (loaded and unloaded) services from the
registry (via “!reg”).
Kris
You can find a linked list of service structures in the memory of
services.exe. The structs contain the status of each service (stopped,
running, etc) along with the service name, process or driver file, and
process id. Malware Analyst’s Cookbook describes how to find and parse the
structs in raw memory dumps with Volatility (which also supports reading
from crash dumps and hibernation files). For more information, see
http://code.google.com/p/volatility/wiki/CommandReference#svcscan. It should
work for 32-bits XP, 2008, Vista, and 7.
Also, as of this week, there is a Windbg script that does the same thing:
http://www.moonsols.com/2011/03/06/retrieving-windows-services-via-windbg/
MHL
On Tue, Mar 8, 2011 at 8:48 AM, Krzysztof Uchronski wrote:
> It might not be 100% accurate but if you know the service you are
> after (e.g. its dll name) you could switch to particular svchost.exe
> process (e.g. “.process /P /r ”) and then list all user mode
> modules (e.g. “lmu”) and finally check whether service you are looking
> for is on the module list.
>
> You could probably combine this method with Martin’s suggestion about
> getting information about all (loaded and unloaded) services from the
> registry (via “!reg”).
>
> Kris
>
> —
> WINDBG 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
>
ok… the dump is a kernel memory dump and not a complete memory dump or a minidump. “.process /P /r ” followed by “lmu” should work well with a complete memory dump. Thats why to get functionally equivalent info(i.e. lmu) from inside a kernel dump, !vad was what I could think of…
michael hale –> Thanks let me have a look at these links
Michael, not sure about volatility but as far as the methods captured in moonsols.com are concerned i.e scanning the PE image, service records etc. all these again require a complete memory dump that has the lower half of the address space. I guess they wont work with a kernel dump.