Brian, 

You must be talking about Jesse's rawmoddump plugin. Its interesting to see how people go about solving problems. Rather than typing 3 lines into the existing volshell plugin, he re-implemented the same functionality into a 70 line file and then blogged about it as if it was some ground breaking new capability...lol. 

Anyway, there are a few possible explanations for finding a legitimate driver at an offset from the base address reported by modscan. One is that modscan found an _LDR_DATA_TABLE_ENTRY structure in physical memory that represents a driver that was once loaded at address XXXXXXXX but has since moved or unloaded. In that case, the kernel would be allowed to map another driver into that available space (starting at either the exact same or a nearby address). 

Another plausible scenario is that modscan found an _LDR_DATA_TABLE_ENTRY for a module that is still loaded at its original address (check with modlist which will show currently loaded modules). The driver has another driver embedded in its resources section that it installed or planned to install. In that case you would expect to find another PE file somewhere near the base of the first one. 

Hope this helps,
MHL


On Fri, Mar 22, 2013 at 12:28 AM, Brian Keefer <chort@effu.se> wrote:
Michael,

Yes, modscan showed the file as being from C:\Users\Bob\ApplicationData\dumpme.sys -like path. It's great to learn this can be done via volshell, which is not something I've explored yet. Someone else sent me a plugin off-list that essentially wraps that functionality.

It looks like the legitimate driver is at an offset from the base address reported by modscan (is it typical for drivers to load from a user directory?). I'm not sure what the padding is before it. Could it perhaps be instructions, or maybe an XOR'd PE header? Not sure exactly.

--
chort

On Mar 21, 2013, at 8:53 PM, Michael Hale Ligh wrote:

Hey Brian, 

You can use volshell to extract an arbitrary region of memory from any address space (in this case kernel memory if you're trying to acquire a kernel module). However, what do you mean "reference a file in user's AppData"? Is that the driver's path on disk (i.e. C:\Users\Bob\ApplicationData\dumpme.sys)? 

You would use volshell like this:

>>> data = self.addrspace.zread(assumed_base_address, assumed_module_size)
>>> with open('file.dmp', 'wb') as f:
......        f.write(data)
>>>

Cheers, 
MHL


On Thu, Mar 21, 2013 at 5:32 PM, Brian Keefer <chort@effu.se> wrote:
Working with a ransomware infection, trying to dump one of the modules that looks suspicious (the only one to reference a file in user's AppData). I'm trying to dump it via the base address found through modscan, but getting:
moddump Error: e_magic 8D4C is not a valid DOS signature.

I tried -u. Is there any other way to dump it?

--
chort



_______________________________________________
Vol-users mailing list
Vol-users@volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users