Saturday, April 08, 2006

lspd posted

I've posted lspd (for "list process details") to the SourceForge site this morning.

First, I want to say that this is a tool written in Perl. The archive I posted includes the Perl source, as well as an executable compiled from the script using Perl2Exe (note: if you use this executable, you need to keep p2x587.dll with the exe at all times). If you don't want to use this executable, or want to modify the source and recompile it, take a look at the PAR module, which is available for Perl. PAR can produce either a portable package that you can run on other platforms (though this script does not use any additional modules), or an executable that is simply more portable.

I wanted to mention this up front, as you don't have to have just Windows to run the can run it on any system that runs Perl. Well, take that with a caveat...I haven't actually tested this on some of the other platforms that run Perl, such as the Tivo.

So...on to the show.

lspd dumps the details of a process from a dd.exe-style dump file, such as those provided with the DFRWS 2005 Memory Challenge. The first thing you have to do is run the lsproc tool against the dump, and get the value of the offset for the process you're interested in.

For example, I ran lsproc against the first memory dump from the Memory Challenge, and found this:

Proc 1112 284 dd.exe 0x0414dd60 0x8046b980 0xff1190c0

From there, I ran the script against the dump file using he following command line:

C:\Perl> d:\hacking\dfrws-mem1.dmp 0x0414dd60

As you can see, lspd takes 2 arguements...the dump file, followed by the hex offset of the process you're interested in.

lspd ran very quickly, and dumped out process details, such as details from the EPROCESS block and process environment block (PEB), the command line used to launch the process, the Desktop name, the Window title, etc. lspd also extracts the modules and handles, if available.

Here's an example of the handles extracted for this process:

Type : File
Name = \Shells
Type : WindowStation
Type : WindowStation
Type : Desktop
Type : File
Name = \intrusion2005\audit.log
Type : File
Name = \intrusion2005\audit.log

lspd was also able to determine that the page located at the Image Base Address (from the PEB) contains a PE header. This will be addressed with another tool (tentative name: lspi, for "list process image").

One thing to keep in mind while using this tool...not all of the information that we're trying to extract is present in the physical memory dump file. When a virtual address is translated into a physical offset within the dump file, flags need to be checked to see if the 4K page is "present" (I put that in quotes b/c that's the name of the flag). Andreas Schuster has a very good tutorial about how this works, but I'm considering writing something specific to these tools, should I find the time to do so.

As always, if you have any comments or questions, please feel free to contact me.


Anonymous said...

lsproc appears to work on Mac OS X. Nice job!

Anonymous said...

lspd works on OS X too! Thanks!

You may want to try using the -w flag in your scripts. It generates several warning messages you may be interested in.

H. Carvey said...

Hey, Jesse, thanks for trying it out and posting it.

And I will take a look at the -w switch. The messages are nothing fatal. I'll definitely include some changes in the next version.