9:39 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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(a)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(a)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
Hi Geoff,
The key to get strings working is to make sure you have a raw
On May 11, 2015, at 11:30 AM, Torres, Geoff
(Cyber Security)
<geoff.torres(a)hp.com <mailto:geoff.torres@hp.com>>
wrote:
Thanks Michael,
I confirm that I now see what I was expecting. Sorry for the
rookie mistake.
I *really* need to get to your class...
Geoff
<mailto:vol-users-bounces@volatilityfoundation.org>
[mailto:vol-users-bounces@volatilityfoundation.org
<mailto:vol-users-bounces@volatilityfoundation.org>] On Behalf Of
Michael Ligh
Don't be afraid to tell me I'm doing
something stupid...
:-)
I only said that because I didn't think I was... :-P
-----Original Message----- From:
vol-users-bounces(a)volatilityfoundation.org Sent: Saturday, May 09, 2015 9:00 AM To:
vol-users(a)volatilityfoundation.org
<mailto:vol-users@volatilityfoundation.org>
Subject: Re: [Vol-users] Output of strings not
found in
memdump
output - QEMU/QEVM sample
> > memory dump. lqs2mem *should* give you that,
however I've not
> personally used it before.
One discrepancy I see with your logic is regarding this line:
memory_dump.ram.vol.strings:183190042 [3156:0189321a]
> <Search_String>
It tells you the search string is at virtual address 0189321a in
> pid 3156. You then dumped the *executable*
for pid 3156 which
> gives you memory from the base of the exe 400000 to its base +
> size (nowhere near 0189321a).
Try using the memdump or vaddump plugins on 3156 instead. That
> will give you ALL of the process's
addressable memory, not
> just the range that contains the exe.
MHL
>>>> On 5/7/15 3:03 PM, Torres, Geoff (Cyber Security) wrote:
>>>> Hi,
>>>>
>>>> Sorry for the 'me too' response, but I'm having this exact
>>>> same problem. However, the main difference is that I'm
>>>> using a 'QEMU' memory image (Hex dump sig is QEVM in the
>>>> first 4 bytes) from a
>> cloud
>>>> instance.
>>>>
>>>> I've converted these in the past using the 'lqs2mem' tool
>> written by
>>>> Juerg Haefliger and Andrew Tappert and it's worked
>>>> perfectly
>> for the
>>>> 'netscan' and 'ps' type plugins. However, I haven't
needed
>>>> to dump processes before and look for specific strings. I
>>>> can locate the strings in the converted image, but it's not
>>>> translating to the processes that are identified by the
>>>> 'strings' plugin.
>>>>
>>>>
>>>> Here's the steps I've been taking -
>>>>
>>>> ## Memory dump info
>>>>> ll memory_dump
>>>> -rw------- 1 geoff citsirt 7579914273 Apr 27 13:36
>>>> memory_dump
>>>>
>>>>> file memory_dump
>>>> memory_dump: QEMU suspend to disk image
>>>>
>>>>> xxd memory_dump | head -n1
>>>> 0000000: 5145 564d 0000 0003 0100 0000 0105 626c
>>>> QEVM..........bl
>>>>
>>>>
>>>> ## Convert the dump
>>>>> lqs2mem -w pc.ram memory_dump memory_dump.ram
>>>> section = pc.ram size = 8192
>>>> [MB] 8589934592 [bytes] section = pc.bios
>>>> size = 128 [KB] 131072 [bytes] section = pc.rom
>>>> size = 128 [KB] 131072 [bytes] section = vga.vram
>>>> size = 16 [MB] 16777216 [bytes] section =
>>>> 0000:00:02.0/cirrus_vga.rom size = 64 [KB]
>>>> 65536 [bytes] Wrote 8589934592 bytes from section 'pc.ram'
>>>> to file memory_dump.ram
>>>>
>>>>
>>>> ## Create the strings file
>>>>> strings -a -t d memory_dump.ram >
>>>>> memory_dump.ram.strings
>>>>
>>>>> strings -a -t d -el memory_dump.ram >>
>>>>> memory_dump.ram.strings
>>>>
>>>>
>>>> ## Create the volatility strings file
>>>>> python
>>>>> /data/download/apps/forensic_tools/volatility/vol.py -f
>>>>> memory_dump.ram --profile=Win2008SP2x64 strings -s
>>>>> --output-file=memory_dump.ram.vol.strings
>>>>
>>>>
>>>>> ll memory_dump.ram.strings memory_dump.ram.vol.strings
>>>> -rw-rw-r-- 1 geoff citsirt 2914258187 May 7 08:58
>>>> memory_dump.ram.strings -rw-rw-r-- 1 geoff citsirt
>>>> 4292775089 May 7 12:17 memory_dump.ram.vol.strings
>>>>
>>>>
>>>> ## '<Search_String>' is found in both string files as
>>>> expected
>>>>> fgrep <Search_String> memory_dump.ram.strings
>>>>> memory_dump.ram.vol.strings
>>>> memory_dump.ram.strings:183190042 <Search_String>
>>>> memory_dump.ram.vol.strings:183190042 [3156:0189321a]
> <Search_String>
>>>>
>>>>
>>>> ## Dump process 3156 as identified by volatility
>>>>> python
>>>>> /data/download/apps/forensic_tools/volatility/vol.py -f
>>>>> memory_dump.ram --profile=Win2008SP2x64 procdump -p 3156
>>>>> -D processes -m
>>>> Volatility Foundation Volatility Framework 2.4 Process(V)
>>>> ImageBase Name Result
>>>> ------------------ ------------------ --------------------
>>>> ------ 0xfffffa800a4e6370 0x0000000000400000 iwproxy.exe
>>>> OK: executable.3156.exe
>>>>
>>>>> ll processes/executable.3156.exe
>>>> -rw-rw-r-- 1 geoff citsirt 3248128 May 7 12:35
>>>> processes/executable.3156.exe
>>>>
>>>>
>>>> ## '<Search_String>' not found in the dumped executable
>>>>> strings -a processes/executable.3156.exe | fgrep
>>>>> <Search_String> strings -a -el
>>>>> processes/executable.3156.exe | fgrep <Search_String>
>>>>
>>>>
>>>> I've tried many different variations of the above steps and
>>>> all have the same results.
>>>>
>>>> According to what I've read in this thread is that the
>>>> issue is to make sure the original dump is properly
>>>> converted. How can I do that? 'lqs2mem' has limited
>>>> options.
>>>>
>>>> Any ideas on what I can do differently to get this to
>>>> work?
>>>>
>>>> Thanks,
>>>>
>>>> Geoff
>>>>
>>>> Don't be afraid to tell me I'm doing something stupid...
>>>> :-)
>>>>
>>>>
>>>> -----Original Message----- From:
>>>> vol-users-bounces(a)volatilityfoundation.org
>> <mailto:vol-users-bounces@volatilityfoundation.org>
>>>> [mailto:vol-users-bounces@volatilityfoundation.org
>> <mailto:vol-users-bounces@volatilityfoundation.org>] On Behalf Of
>> Michael
>>>> Ligh Sent: Tuesday, March 24, 2015 6:49 AM To: Bridgey
>>>> theGeek Cc: vol-users(a)volatilityfoundation.org
>> <mailto:vol-users@volatilityfoundation.org> Subject: Re:
>> [Vol-users] Output of
>>>> strings not found in memdump output
>>>>
>>>> Perfect! Glad to hear all is good in the world ;-)
>>>>
>>>> MHL
>>>>
>>>>> On 3/24/15 5:05 AM, Bridgey theGeek wrote: Awesome,
>>>>> thanks Michael.
>>>>
>>>>> I generated a raw dump as follows, with the vmsn and vmem
>>>>> files in the same folder: $ python vol.py -f winxp.vmem
>>>>> --profile=WinXPSP2x86 imagecopy -O winxp.raw
>>>>
>>>>> Then ran strings again (having generated a new input text
>>>>> file because of course the offsets will be different): $
>>>>> python vol.py -f winxp.raw --profile=WinXPSP2x86 strings
>>>>> -s pk.txt
>>>>
>>>>> I was then able to find the banner at the offsets
>>>>> reported by strings. And all was good in the world.
>>>>
>>>>> Thank you very much for the support.
>>>>
>>>>> Adam
>>>>
>>>>> On 23 March 2015 at 19:39, Michael Ligh
>>>>> <michael.ligh(a)mnin.org
>> <mailto:michael.ligh@mnin.org>
>>>>> <mailto:michael.ligh@mnin.org
>>>>> <mailto:michael.ligh@mnin.org>>>
>> wrote:
>>>>
>>>>> Hey Adam,
>>>>
>>>>> A few things:
>>>>
>>>>> * Yes, vmss2core creates a windows crash dump * You can
>>>>> use volatility on the original vmem/vmss by doing the
>>>>> following:
>>>>
>>>>> * make sure both vmem and vmss files are in the same dir
>>>>> * make sure they have the same base name (i.e. test.vmem
>>>>> and test.vmss) * run your volatility plugins against the
>>>>> vmem
>>>>
>>>>> In this case, it would also be required to generate a raw
>>>>> memory dump before running strings. So you would use
>>>>> imagecopy on the vmem.
>>>>
>>>>> LMK if that helps! Michael
>>>>
>>>>>> On 3/23/15 10:51 AM, Bridgey theGeek wrote: Hi
>>>>>> Michael,
>>>>
>>>>>> *sigh* When will I learn to check the origin of my
>>>>>> samples?!
>>>>
>>>>>> The guy who provided me with the sample tells me that
>>>>>> he took a snapshot of a VMWare machine and then used
>>>>>> vss2core to convert it. I BELIEVE that makes it into a
>>>>>> Windows Memory Core Dump..?
>>>>
>>>>>> I got hold of the original vmem and vmsn files. Trying
>>>>>> to use imagecopy on the vmsn just replicated the input
>>>>>> file. I think the header is not what Volatility would
>>>>>> expect: $ xxd Windows\ XP\ Pro\ SP2\
>>>>>> \(32-bit\)-Snapshot49.vmsn |head 0000000: d2be d2be
>>>>>> 0800 0000 6300 0000 4368 6563 ........c...Chec
>>>>>> 0000010: 6b70 6f69 6e74 0000 0000 0000 0000 0000
>>>>>> kpoint.......... 0000020: 0000 0000 0000 0000 0000 0000
>>>>>> 0000 0000 ................ 0000030: 0000 0000 0000 0000
>>>>>> 0000 0000 0000 0000 ................ 0000040: 0000 0000
>>>>>> 0000 0000 0000 0000 fc1e 0000 ................ 0000050:
>>>>>> 0000 0000 ab03 0000 0000 0000 4775 6573
>>>>>> ............Gues 0000060: 7456 6172 7300 0000 0000 0000
>>>>>> 0000 0000 tVars........... 0000070: 0000 0000 0000 0000
>>>>>> 0000 0000 0000 0000 ................ 0000080: 0000
>>>>>> 0000 0000 0000 0000 0000 0000 0000 ................
>>>>>> 0000090: 0000 0000 0000 0000 0000 0000 a722 0000
>>>>>> ............."..
>>>>
>>>>>> Does that mean I can't use this with Volatility?
>>>>
>>>>>> Thank you, Adam
>>>>
>>>>>> On 23 March 2015 at 14:57, Michael Ligh
>> <michael.ligh(a)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:
>>>>
>>>>>> Hey Adam,
>>>>
>>>>>> We forgot to ask if the sample was a raw memory dump.
>>>>>> For example:
>>>>
>>>>>> $ xxd ~/Desktop/memory.dmp | less
>>>>
>>>>>> 0000000: 5041 4745 4455 4d50 0f00 0000 280a 0000
>>>>>> PAGEDUMP....(... 0000010: 8001 6c07 00c0 e680 a031 5580
>>>>>> 5892 5580 ..l......1U.X.U. 0000020: 4c01 0000 0100 0000
>>>>>> 8000 0000 5444 4f00 L...........TDO. 0000030: 0000 0000
>>>>>> 0000 0000 0000 0000 5041 4745 ............PAGE 0000040:
>>>>>> 5041 4745 5041 4745 5041 4745 5041 4745
>>>>>> PAGEPAGEPAGEPAGE
>>>>
>>>>>> If its something like a crash dump, hibernation, etc
>>>>>> then the file format headers throw off the offsets. You
>>>>>> can convert those special file types into a raw memory
>>>>>> dump with the imagecopy plugin and then your strings
>>>>>> translations should be accurate.
>>>>
>>>>>> Cheers! MHL
>>>>
>>>>>>> On 3/23/15 8:54 AM, Bridgey theGeek wrote: Hi
>>>>>>> Andrew,
>>>>
>>>>>>> I was certain I was running the latest version, but
>>>>>>> just to be sure I grabbed the latest version. Same
>>>>>>> result, same offsets.
>>>>
>>>>>>> I can make the sample available, but more than happy
>>>>>>> to do whatever debugging needs doing (if I can!)
>>>>
>>>>>>> Adam
>>>>
>>>>>>> On 23 March 2015 at 13:03, Andrew Case
>>>>>>> <atcuno(a)gmail.com
>> <mailto:atcuno@gmail.com>
>>>>>>> <mailto:atcuno@gmail.com
<mailto:atcuno@gmail.com>>
>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>
>>>>>>> <mailto:atcuno@gmail.com
<mailto:atcuno@gmail.com>>>
>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>
>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>
>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>
>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>>>
wrote:
>>>>
>>>>>>> Are you using the latest git checkout of Volatility
>>>>>>> or the 2.4 release? Can you try the latest checkout
>>>>>>> and re-run Volatility strings (you can run it on just
>>>>>>> the offsets from PID 123 to make it faster).
>>>>
>>>>>>> If you are already on the latest checkout then we
>>>>>>> will need to debug further.
>>>>
>>>>
>>>>
>>>>
>>>>>>> Thanks, Andrew (@attrc)
>>>>
>>>>>>>> On 03/23/2015 04:38 AM, Bridgey theGeek wrote:
>>>>>>>> Thanks Andrew:
>>>>>>>>
>>>>>>>> python vol.py --profile=WinXPSP2x86 -f memory.dmp
>>>>>>>> volshell -p 123 Volatility Foundation Volatility
>>>>>>>> Framework 2.4 Current context: myapp.exe @
>>>>>>>> 0x822042f8, pid=123, ppid=392
>>>>>>> DTB=0x76c0040
>>>>>>>> Welcome to volshell! Current memory image is:
>>>>>>>> file:///home/memory.dmp To get help, type 'hh()'
>>>>>>>>>>> db(0x75b6b4d8)
>>>>>>>> 0x75b6b4d8 c3 7c 15 c7 85 00 ff ff ff 01 00 00 00
>>>>>>>> 75 09 8d .|...........u.. 0x75b6b4e8 85 0c ff ff
>>>>>>>> ff 50 ff 17 39 9d 00 ff ff ff 89 85
>>>>>>>> .....P..9....... 0x75b6b4f8 30 ff ff ff 74 12 6a
>>>>>>>> 0c 8d 85 c4 fe ff ff 50 6a 0...t.j.......Pj
>>>>>>>> 0x75b6b508 07 6a fe e8 ea 92 ff ff 83 bd 28 ff ff
>>>>>>>> ff 0c 0f .j........(..... 0x75b6b518 84 8c 59 00 00
>>>>>>>> e9 18 ff ff ff 90 90 47 00 6c 00 ..Y.........G.l.
>>>>>>>> 0x75b6b528 6f 00 62 00 61 00 6c 00 5c 00 54 00 65
>>>>>>>> 00 72 00 o.b.a.l.\.T.e.r. 0x75b6b538 6d 00 53 00
>>>>>>>> 72 00 76 00 52 00 65 00 61 00 64 00
>>>>>>>> m.S.r.v.R.e.a.d. 0x75b6b548 79 00 45 00 76 00 65
>>>>>>>> 00 6e 00 74 00 00 00 90 90 y.E.v.e.n.t.....
>>>>>>>>
>>>>>>>> Nope, still no banner. But it is identical to what
>>>>>>>> I find at
>>>>>>> 0x1a34d8 in
>>>>>>>> 123.dmp. (As you'd expect.) Double-checked that I
>>>>>>>> was searching Unicode and ASCII - still no luck.
>>>>>>>>
>>>>>>>> Hmmm.
>>>>>>>>
>>>>>>>> Adam
>>>>>>>>
>>>>>>>> On 23 March 2015 at 04:02, Andrew Case
>>>>>>>> <atcuno(a)gmail.com
>> <mailto:atcuno@gmail.com>
>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>
>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>
>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>
>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>
>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>
>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>
>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>>
>>>>>>>> <mailto:atcuno@gmail.com
<mailto:atcuno@gmail.com>
>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>
>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>
>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>
>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>
>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>
>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>
>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>>>>
wrote:
>>>>>>>>
>>>>>>>> Can do you:
>>>>>>>>
>>>>>>>> vol.py ... volshell -p 123
>>>>>>>>
>>>>>>>> Then in volshell do:
>>>>>>>>
>>>>>>>> db(0x75b6b4d8)
>>>>>>>>
>>>>>>>> And see if you get the banner printed at the
>>>>>>>> beginning?
>>>>>>>>
>>>>>>>> Also, how are you searching 123.dmp? Did you search
>>>>>>>> ascii &
>>>>>>> unicode
>>>>>>>> (most common error)
>>>>>>>>
>>>>>>>> Thanks, Andrew (@attrc)
>>>>>>>>
>>>>>>>>> On 03/20/2015 03:59 PM, Bridgey theGeek wrote: Hi
>>>>>>>>> all,
>>>>>>>>>
>>>>>>>>> I can't quite see what's wrong with my logic
>>>>>>>>> here, but I must be
>>>>>>>> missing
>>>>>>>>> something. Hoping someone can help me out.
>>>>>>>>>
>>>>>>>>> I'm looking for a private key in a memory sample
>>>>>>>>> (WinXPSP2x86). Specifically, to find out which
>>>>>>>>> process/es is/are accessing it.
>>>>>>>>>
>>>>>>>>> I can find the key by searching the raw memory
>>>>>>>>> dump
>>>>>>> (memory.dmp).
>>>>>>>>> As you might expect it's between: -----BEGIN RSA
>>>>>>>>> PRIVATE KEY----- -----END RSA PRIVATE KEY-----
>>>>>>>>>
>>>>>>>>> I generated an offset:string file by using
>>>>>>>>> strings. Then, using the strings plugin I get
>>>>>>>>> this output: $ python vol.py -f memory.dmp
>>>>>>>>> --profile=WinXPSP2x86 strings
>>>>>>> -s pk.txt
>>>>>>>>> Volatility Foundation Volatility Framework 2.4
>>>>>>>>> 188435934 [FREE MEMORY:-1] -----BEGIN RSA PRIVATE
>>>>>>>>> KEY----- 188435968 [FREE MEMORY:-1] -----END RSA
>>>>>>>>> PRIVATE KEY----- 317375704 [kernel:d2ab24d8]
>>>>>>>>> -----BEGIN RSA PRIVATE KEY----- 317376575
>>>>>>>>> [kernel:d2ab283f] -----END RSA PRIVATE KEY-----
>>>>>>>>> 417203416 [123:75b6b4d8] -----BEGIN RSA PRIVATE
>>>>>>>>> KEY----- 417204287 [123:75b6b83f] -----END RSA
>>>>>>>>> PRIVATE KEY----- 419888606 [FREE MEMORY:-1]
>>>>>>>>> -----BEGIN RSA PRIVATE KEY----- 419888640 [FREE
>>>>>>>>> MEMORY:-1] -----END RSA PRIVATE KEY-----
>>>>>>>>>
>>>>>>>>> Lovely. So I now do a memdump of process 123: $
>>>>>>>>> python vol.py -f memory.dmp --profile=WinXPSP2x86
>>>>>>>>> memdump
>>>>>>> --pid=123
>>>>>>>>> --dump-dir=123 Volatility Foundation Volatility
>>>>>>>>> Framework 2.4
>>>>
>>>>
>>>>>
>> ********************************************************************
>>
*
**
>>> _______________________________________________
_______________________________________________ Vol-users mailing
list Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
iF4EAREKAAYFAlVVTmUACgkQXnt9v1O0LIvejgEApMBrANtkLgHAOVx2CIGMMk4A
vX4Ru0Gh4kRiKkc+kygA/jLog41xy61WpoOuS9TwvIdNe0FqvgoOACkh/4vB5Ru4
=VDRK
-----END PGP SIGNATURE-----
>
>
>
>
>>>>> Writing myapp.exe [ 123] to 123.dmp
>>>>>>
>>>>>> However, if I search 123.dmp neither the BEGIN or
>>>>>> END
>>>> strings are
>>>>> present.
>>>>>>
>>>>>> So I thought I'd try and find it via the virtual
>>>>>> address give,
>>>>> 0x75b6b4d8:
>>>>>> $ python vol.py -f memory.dmp
>>>>>> --profile=WinXPSP2x86 memmap
>>>> --pid=123
>>>>>> Virtual Physical Size DumpFileOffset
>>>>>> ---------- ---------- ---------- --------------
>>>>>> --SNIP-- 0x75b6b000 0x18de0000 0x1000
>>>>>> 0x1a3000 --SNIP--
>>>>>>
>>>>>> The text is indeed at 0x18de04d8 in memory.dmp,
>>>>>> but not at
>>>> 0x1a34d8 in
>>>>>> 123.dmp. Again, it's no where to be found in
>>>>>> 123.dmp.
>>>>>>
>>>>>> Any suggestions..??
>>>>>>
>>>>>> Many thanks, Adam
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Vol-users mailing list
>>>>>> Vol-users(a)volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>
>>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>>
> >>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>
>>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>>>
>> >>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>
>>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>>
> >>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>
>>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>>>>
>> >>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>
>>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>>
> >>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>
>>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>>>
>> >>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>
>>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>>
>> >>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>
>>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>>>>>
>>>>>>> >
>
>
>>>> _______________________________________________
>>>> Vol-users mailing list Vol-users(a)volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>
>>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>>
>> >>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>
>>
<mailto:Vol-users@volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>>>
>>>>> >
>
>
>
> _______________________________________________ Vol-users
> mailing list Vol-users(a)volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>
>> >
>
> _______________________________________________ Vol-users
> mailing list Vol-users(a)volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>
>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users Vol-users
mailing list Vol-users(a)volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
_______________________________________________ Vol-users
mailing list Vol-users(a)volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
_______________________________________________ Vol-users mailing
list Vol-users(a)volatilityfoundation.org
<mailto:Vol-users@volatilityfoundation.org>
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users