Can you do:

addrspace().base

in volshell?

if base is FileAddressSpace then its a raw file. If its
Elf/crash/hibernation/etc. then its not.

I am pretty sure pmem would default to ELF or similar. Not many tools do
raw files anymore because of how big 64 bit ones can get with gaps in
the physical address space.

Thanks,
Andrew (@attrc)

On 05/15/2015 11:23 AM, Gregory Pendergast wrote:
> So, I thought it was a raw image. Now, not so sure. It was created using
> the winpmem_1.6.2 defaults, with the simple command line:
> winpmem_1.6.2 <output_filename>.  The image is from a 64-bit system, so
> it would have defaulted (as I understand it) to using PTE Remapping.
>
> Here's the output of addrspace():
>>>>addrspace()
> <volatility.plugins.addrspaces.amd64.AMD64PagedMemory object
>
> Thanks,
> Greg
>
> On Fri, May 15, 2015 at 11:57 AM, Michael Ligh <michael.ligh@mnin.org
> <mailto:michael.ligh@mnin.org>> wrote:
>
> Hmm, that does not appear to sync up as expected. What format is your
> memory dump? Strings requires a "raw" memory dump. You can check by
> typing addrspace().base in volshell and if its a raw memory dump
> you'll see FileAddressSpace. If you don't have a raw memory image, use
> the imagecopy plugin to create a raw memory dump from whatever format
> you have and then translate the strings again.
>
> MHL
>
> On 5/15/15 11:48 AM, Gregory Pendergast wrote:
>> Thanks gentlemen. No worries there. I didn't take it badly. Sorry
>> for the oversight.
>
>> Correcting the command gives me output, but leaves me with a new
>> question. The string of interest seems nowhere to be found (maybe
>> it's unicode? I'm not sure how to tell...):
>
>>>>> db(0xf9805ba44800)
>> 0xf9805ba44800  00 00 00 00 00 00 00 00 1b 00 01 00 28 00 00 00
>> ............(... 0xf9805ba44810  28 00 00 00 18 00 00 00 00 00 00
>> 00 00 00 02 00 (............... 0xf9805ba44820  00 00 00 00 00 00
>> 00 00 48 a4 83 08 a0 f8 ff ff ........H....... 0xf9805ba44830  06
>> 09 65 f1 02 00 00 00 00 00 00 00 00 00 00 00 ..e.............
>> 0xf9805ba44840  00 00 00 00 00 00 00 00 a8 00 00 00 00 00 00 00
>> ................ 0xf9805ba44850  01 00 00 00 40 00 00 00 00 00 00
>> 00 00 00 00 00 ....@........... 0xf9805ba44860  07 00 07 00 28 00
>> 40 00 68 00 40 00 18 00 01 00 ....(.@.h.@..... 0xf9805ba44870  38
>> 00 20 00 04 00 02 00 0b 9e 00 00 00 00 00 00 8...............
>
>>>>> db(0xf9805ba44800,length=0xFF)
>> 0xf9805ba44800  00 00 00 00 00 00 00 00 1b 00 01 00 28 00 00 00
>> ............(... 0xf9805ba44810  28 00 00 00 18 00 00 00 00 00 00
>> 00 00 00 02 00 (............... 0xf9805ba44820  00 00 00 00 00 00
>> 00 00 48 a4 83 08 a0 f8 ff ff ........H....... 0xf9805ba44830  06
>> 09 65 f1 02 00 00 00 00 00 00 00 00 00 00 00 ..e.............
>> 0xf9805ba44840  00 00 00 00 00 00 00 00 a8 00 00 00 00 00 00 00
>> ................ 0xf9805ba44850  01 00 00 00 40 00 00 00 00 00 00
>> 00 00 00 00 00 ....@........... 0xf9805ba44860  07 00 07 00 28 00
>> 40 00 68 00 40 00 18 00 01 00 ....(.@.h.@..... 0xf9805ba44870  38
>> 00 20 00 04 00 02 00 0b 9e 00 00 00 00 00 00 8...............
>> 0xf9805ba44880  50 14 9e 00 00 00 00 00 03 ee e4 ad 6d 83 d0 01
>> P...........m... 0xf9805ba44890  03 ee e4 ad 6d 83 d0 01 18 24 3a
>> 05 d4 82 d0 01 ....m....$:..... 0xf9805ba448a0  26 20 00 00 00 00
>> 00 00 00 00 00 00 00 00 00 00 &............... 0xf9805ba448b0  00
>> 00 00 00 90 05 00 00 00 00 00 00 00 00 00 00 ................
>> 0xf9805ba448c0  a0 3f 54 90 00 00 00 00 f2 c6 e4 ad 6d 83 d0 01
>> .?T.........m... 0xf9805ba448d0  f2 c6 e4 ad 6d 83 d0 01 18 24 3a
>> 05 d4 82 d0 01 ....m....$:..... Here's the string I expect to see
>> based on the strings output: 4397692928 [kernel:f9805ba44800]
>> Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware,
>> Ltd. ALL RIGHTS RESERVED.
>
>> Thanks again for the help. Greg
>
>> On Fri, May 15, 2015 at 11:30 AM, Michael Ligh
>> <michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>
> <mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>>> wrote:
>
>> Hey Greg....Andrew just (to my surprise) asked me why I was being
>> "rough" on you, so I apologize if that's how it came across...the
>> goal was just to point out the issue as fast as possible.
>
>> MHL
>
>> On 5/15/15 11:15 AM, Michael Ligh wrote:
>>> My command:
>
>>> db(0xf9805ba44800)
>
>>> Your command:
>
>>> db(f9805ba44800)
>
>>> The missing 0x in front makes Python think f9805ba44800 is a
>>> variable name rather than a number.
>
>>> On 5/15/15 11:05 AM, Gregory Pendergast wrote:
>>>> Thanks Michael. I did try that, and received an error. That's
>>>> why I thought I must be doing/forgetting something stupid. Now
>>>> that I'm back at my analysis machine, here's the output:
>
>>>>>>> db(f9805ba44800)
>>>> Traceback (most recent call last): File "<console>", line 1,
>>>> in <module> NameError: name 'f9805ba44800' is not defined
>>>>>>> addrspace()
>>>> <volatility.plugins.addrspaces.amd64.AMD64PagedMemory object
>>>> at 0xbef520c>
>>>>>>>
>>>> Note that I'm using Volatilty through the VM provided for the
>>>> most recent class in Reston, in case the version is in
>>>> question. The profile for this sample is WIn7SP1x64.
>
>>>> Thanks, Greg
>
>
>
>>>> On Fri, May 15, 2015 at 10:49 AM, Michael Ligh
>>>> <michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>
> <mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>>
>> <mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>
> <mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>>>>
>> wrote:
>
>>>> You would just type db(0xf9805ba44800) in volshell (or
>>>> whatever other address you want to see).
>
>>>> https://github.com/volatilityfoundation/volatility/wiki/Command%20Re
> f
>
>>>>
> e
>
>>>>
>> re
>
>
>>> nce#volshell
>>>> <https://github.com/volatilityfoundation/volatility/wiki/Command%20R
> e
>
>>>>
> f
>
>>>>
>> erence#volshell>
>
>>>> I would also search an electronic copy of the AMF book for
>>>> "volshell" - there are lots of examples.
>
>
>>>> On 5/14/15 10:52 PM, Gregory Pendergast wrote:
>>>>> Thanks Michael. Regarding the latter part of inspecting the
>>>>> data around the strings, that's where I really need the help.
>>>>> I know I can accomplish that with volshell, but I'm not
>>>>> proficient enough yet to know how to get at it.
>
>>>>> If you could provide the necessary commands to get at the
>>>>> data around this hit [kernel:f9805ba44800] as an example,
>>>>> that would be most helpful.
>
>>>>> I'm sure I was doing something n00bishly wrong, but I could
>>>>> never get to the point of displaying the data around that
>>>>> location. I'd be more specific about my attempts, but I'm
>>>>> not in front of my analysis machine right now and don't
>>>>> recall exactly what I tried.
>
>>>>> thanks, greg
>
>>>>>> On May 14, 2015, at 9:39 PM, Michael Ligh
>>>>>> <michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>
> <mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>>
>>>> <mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>
> <mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>>>>
>>>>>> wrote:
>>>>>>
>>>>> I wouldn't think the module at 0x48706657040b0003 requires
>>>>> investigation. Not only bc its not in the 0xfffff8 range,
>>>>> but you might notice legitimate modules are typically loaded
>>>>> at page aligned base addresses (not XXX0003). Your result
>>>>> looks like a false positive and given the way modscan works
>>>>> (pool scanning) its probably a partially overwritten
>>>>> structure in free/deallocated memory. We *could* put a sanity
>>>>> check in the code to suppress entries that aren't loaded at
>>>>> page aligned addresses, but there are a few exceptions where
>>>>> you'll have modules loaded from non-page aligned addresses.
>>>>> For example, we just looked at a rootkit today in class that
>>>>> is loaded at 0x81b91b80 (on a 32-bit system). Jared's advice
>>>>> is also good - if you ever suspect something like this again,
>>>>> you can use volshell to display the data at the alleged base
>>>>> address and see what's there. If its not an MZ signature,
>>>>> then its probably not a currently loaded module (but keep in
>>>>> mind you can overwrite the MZ with 00 or anything else as a
>>>>> trick...but in that case you'll see real executable code not
>>>>> too far away).
>
>>>>> I would suggest trying to figure out what downloaded the EXE
>>>>> in the first place, so that you can determine what it does
>>>>> after the download finishes (drop to disk and run, drop to
>>>>> disk and run then delete, load directly into memory without
>>>>> touching disk, etc). I would also inspect the data around the
>>>>> strings you found in kernel and free memory - is it verbatim
>>>>> with what you see in the pcap (i.e. just a copy of the
>>>>> packet) or has it been altered (i.e. unpacked, executed,
>>>>> expanded).
>
>>>>>>>> On 5/14/15 4:31 PM, Gregory Pendergast wrote: Just as
>>>>>>>> a follow up to my last reply, the shimcache plugin
>>>>>>>> reported that there was no shimcache data, and the
>>>>>>>> timeliner plugin didn't reveal anything apparently
>>>>>>>> interesting except IE history related to the download.
>>>>>>>>
>>>>>>>> Thanks, Greg
>>>>>>>>
>>>>>>>>
>>>>>>>> On May 14, 2015, at 12:35 PM, Jared Greenhill
>>>>>>>> <jared703@gmail.com <mailto:jared703@gmail.com>
> <mailto:jared703@gmail.com <mailto:jared703@gmail.com>>
>> <mailto:jared703@gmail.com <mailto:jared703@gmail.com>
> <mailto:jared703@gmail.com <mailto:jared703@gmail.com>>>
>>>> <mailto:jared703@gmail.com <mailto:jared703@gmail.com>
> <mailto:jared703@gmail.com <mailto:jared703@gmail.com>>
>> <mailto:jared703@gmail.com <mailto:jared703@gmail.com>
> <mailto:jared703@gmail.com <mailto:jared703@gmail.com>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hey Greg,
>>>>>>>>>
>>>>>>>>> A couple thoughts/ideas:
>>>>>>>>>
>>>>>>>>> What was the initial reason for investigation- the
>>>>>>>>> suspect EXE? Do you have a timeframe of the suspect
>>>>>>>>> activity?
>>>>>>>>>
>>>>>>>>> What was the context around the suspect EXE
>>>>>>>>> download, just the PCAP or? If so, did the memory
>>>>>>>>> capture occur when there was still an active
>>>>>>>>> connection? Sometimes this can be a dealbreaker when
>>>>>>>>> the connection isn't there.
>>>>>>>>>
>>>>>>>>> Does moddump work on the module with that base
>>>>>>>>> address? If so, what type of strings are you seeing?
>>>>>>>>>
>>>>>>>>> As far as execution goes, does the shimcache plugin
>>>>>>>>> provide any results around the time of interest?
>>>>>>>>> Assuming you have a time of interest, you could also
>>>>>>>>> try the timeliner plugin to pull in other temporal
>>>>>>>>> artifacts to hone in around that suspect time.
>>>>>>>>>
>>>>>>>>> hope this helps, Jared - @jared703
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, May 12, 2015 at 3:36 PM, Gregory Pendergast
>>>>>>>>> <greg.pendergast@gmail.com <mailto:greg.pendergast@gmail.com>
>>>>>>>>> <mailto:greg.pendergast@gmail.com
> <mailto:greg.pendergast@gmail.com>>
>>>>>>>>> <mailto:greg.pendergast@gmail.com
> <mailto:greg.pendergast@gmail.com>
>> <mailto:greg.pendergast@gmail.com <mailto:greg.pendergast@gmail.com>>>
>>>>>>>>> <mailto:greg.pendergast@gmail.com
> <mailto:greg.pendergast@gmail.com>
>> <mailto:greg.pendergast@gmail.com <mailto:greg.pendergast@gmail.com>>
>>>> <mailto:greg.pendergast@gmail.com <mailto:greg.pendergast@gmail.com>
>> <mailto:greg.pendergast@gmail.com
> <mailto:greg.pendergast@gmail.com>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Greeting,
>>>>>>>>>
>>>>>>>>> I'm examining a memory sample (captured locally with
>>>>>>>>> winpmem_1.6.2) <yeah...i know...>
>>>>>>>>>
>>>>>>>>> Modscan shows one apparently strange module that has
>>>>>>>>> no name and no file listed. The base address space
>>>>>>>>> also seems way out of whack for the rest of the
>>>>>>>>> sample.
>>>>>>>>>
>>>>>>>>> So all i have are offset, base, and size:
>>>>>>>>> 0x000000023a80b540 0x48706657040b0003 0xf3a54f0
>>>>>>>>>
>>>>>>>>> In particular, that base address seems way out of
>>>>>>>>> range compared to everything else in 0xfffff8....
>>>>>>>>> space
>>>>>>>>>
>>>>>>>>> How can I tell if this is an error of some kind in
>>>>>>>>> the captured sample versus a legitimate anomaly that
>>>>>>>>> bears investigation?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Lastly, and pardon me if this is a n00b question,
>>>>>>>>> but how can I determine why specific strings appear
>>>>>>>>> in kernel memory (based on strings plugin output)?
>>>>>>>>> For context, I have a suspicious executable download,
>>>>>>>>> but there appears to be no evidence of the file in
>>>>>>>>> $MFT (I don't have access to UsnJrnl) and I'm trying
>>>>>>>>> to find out what happened to it and whether it ran.
>>>>>>>>> Strings from the executable (ontained from pcap) do
>>>>>>>>> appear in Free Memory and Kernel memory, but I'm not
>>>>>>>>> clear whether that's a symptom of the download or a
>>>>>>>>> sign of execution.
>>>>>>>>>
>>>>>>>>> Thanks, greg