[Vol-users] moddump Error: e_magic 8D4C is not a valid DOS
Michael Hale Ligh
michael.hale at gmail.com
Fri Mar 22 10:16:51 CDT 2013
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
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
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,
On Fri, Mar 22, 2013 at 12:28 AM, Brian Keefer <chort at effu.se> wrote:
> 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
> 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.
> 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.
> 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)
> On Thu, Mar 21, 2013 at 5:32 PM, Brian Keefer <chort at 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
>> moddump Error: e_magic 8D4C is not a valid DOS signature.
>> I tried -u. Is there any other way to dump it?
>> Vol-users mailing list
>> Vol-users at volatilityfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vol-users