Re: [Vol-users] Sample error or real module? (and other questions)
by Gregory Pendergast
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(a)mnin.org>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> 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(a)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%20Ref
> e
> >
> >>
> re
> >
> >
> > nce#volshell
> >> <https://github.com/volatilityfoundation/volatility/wiki/Command%20Re
> 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(a)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(a)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(a)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
> >>>>>>>
> >>>>>>>
> >>>>>>>>> On May 11, 2015, at 11:30 AM, Torres, Geoff (Cyber
> >>>>>>>>> Security)
> >>>>>>>> <geoff.torres(a)hp.com <mailto:geoff.torres@hp.com>
> >> <mailto:geoff.torres@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
> >>>>>>>>
> >>>>>>>>> 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
> >> <mailto:vol-users-bounces@volatilityfoundation.org>
> >>>>>>> <mailto:vol-users-bounces@volatilityfoundation.org
> >> <mailto:vol-users-bounces@volatilityfoundation.org>>
> >>>>>>> [mailto:vol-users-bounces@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: Saturday, May 09, 2015 9:00 AM To:
> >>>>>>>> vol-users(a)volatilityfoundation.org
> >> <mailto:vol-users@volatilityfoundation.org>
> >>>>>>> <mailto:vol-users@volatilityfoundation.org
> >> <mailto:vol-users@volatilityfoundation.org>>
> >>>>>>>> Subject: Re: [Vol-users] Output of strings not found
> >>>>>>>> in memdump
> >>>>>>> output - QEMU/QEVM sample
> >>>>>> Hi Geoff,
> >>>>>>
> >>>>>> The key to get strings working is to make sure you have a
> >>>>>> raw
> >>>>>>>> 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>>
> >>>>>>>>>> [mailto:vol-users-bounces@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>
> >>>>>>>> <mailto:vol-users@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>>
> >>>>>>>>>>> <mailto:michael.ligh@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>>>
> >>>>>>>> <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
> >> <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>>>>
> >>>>>>>>>>> <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:
> >>>>>>>>>>
> >>>>>>>>>>>>> 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>>>>>
> >>>>>>>>>>>>>> <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 <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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> ***************************************************************
> *
> >
> >>>>>>>>
> *
> >
> >>>>>>>>
> > ***
> >
> >>>>>>>>
> >> *
> >>>>>>
> >>> *
> >>>>>> **
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>>> 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>>>>>
> >>>>>>>>>>>>> <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
> >> <mailto:Vol-users@volatilityfoundation.org>>>>>>
> >>>>>>>>>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-us
> e
> >
> >>>>>>>>>>>>>>>
> r
> >
> >>>>>>>>>>>>>>>
> > s
> >>>>>>>>
> >>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >> _______________________________________________
> >>>>>>>>>>>>> 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>>>>
> >>>>>>>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-user
> s
> >>>>>>>>
> >>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>>
> >
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> > _______________________________________________ Vol-users
> >>>>>>>>>> mailing list Vol-users(a)volatilityfoundation.org
> >> <mailto:Vol-users@volatilityfoundation.org>
> >>>>>>>> <mailto:Vol-users@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>
> >>>>>>>> <mailto:Vol-users@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>
> >>>>>>>> <mailto:Vol-users@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>
> >>>>>>>> <mailto:Vol-users@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>
> >>>>>>> <mailto:Vol-users@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
> >> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
> >
> > _______________________________________________ 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
>
> iF4EAREKAAYFAlVWETEACgkQXnt9v1O0LIuYZAD/UsDyJWzldfjbqoR8/me5CI6K
> Iy5l/cuykusKHuf+U7MA/2eSg10cTPB+HnPj9QO4GsFNAvUwzFo9aCh9CGudH3SK
> =2Ea+
> -----END PGP SIGNATURE-----
>
9 years, 11 months
- 3
- 9
OS X Yosemite profiles now in the repo, testing requested
by Andrew Case
I just pushed the profiles that we created for OS X Yosemite into the
'profiles' project:
https://github.com/volatilityfoundation/profiles/tree/master/Mac/10.10/x64
They should cover every version of 10.10.x officially released by Apple.
If there are any missing versions then please let me know.
We are requesting testing across the different versions since the
profiles are so new. If you find any issues then please report them at:
https://github.com/volatilityfoundation/volatility/issues
Thanks for any help!
--
Thanks,
Andrew (@attrc)
9 years, 11 months
- 1
- 0
Re: [Vol-users] Timeliner "-R" not parsing Registry in 2.4
by Jamie Levy
This is true. When we allowed an option to specify by types the short -R was removed. I think it was also due to a conflict in options.
--
Jamie Levy (@gleeda)
> On May 18, 2015, at 9:11 AM, Gregory Pendergast <greg.pendergast(a)gmail.com> wrote:
>
> "--type=Registry" works. -R appears to no longer be an option.
>
>> On May 18, 2015, at 11:30 AM, Jared Greenhill <jared703(a)gmail.com> wrote:
>>
>> Vol Team,
>>
>> II've been unable to parse the Registry of a Windows system with 2.4 like I could with 2.3 using the "-R" switch. Do you invoke Registry parsing the same with 2.4 and Timeliner? When I remove the "-R" flag timeliner runs as expected. Apologies if this has been discussed somewhere. I've tried with Vol.py (compiled from source) and the Windows binary flavor of 2.4.
>>
>> Here's the errors I am receiving:
>>
>> C:\Users\DFIR-PC\Desktop\Mem>vol.exe -f Bad.img timeliner --output=body > timeline.txt -R
>> Volatility Foundation Volatility Framework 2.4
>> Usage: Volatility - A memory forensics analysis platform.
>>
>> vol.exe: error: no such option: -R
>>
>> C:\Users\DFIR-PC\Desktop\Mem>vol.exe -f Bad.img timeliner --output=body --output-file=timeline.txt -R
>> Volatility Foundation Volatility Framework 2.4
>> Usage: Volatility - A memory forensics analysis platform.
>>
>> vol.exe: error: no such option: -R
>>
>> C:\Users\DFIR-PC\Desktop\Mem>c:\volatility-master\vol.py -f Bad.img timeliner --output=body --output-file=timeline.txt -R
>> Volatility Foundation Volatility Framework 2.4
>>
>> Usage: Volatility - A memory forensics analysis platform.
>>
>> vol.py: error: no such option: -R
>>
>> Thanks!
>> Jared
>> _______________________________________________
>> Vol-users mailing list
>> Vol-users(a)volatilityfoundation.org
>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
> _______________________________________________
> Vol-users mailing list
> Vol-users(a)volatilityfoundation.org
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
9 years, 12 months
- 2
- 1
Timeliner "-R" not parsing Registry in 2.4
by Jared Greenhill
Vol Team,
II've been unable to parse the Registry of a Windows system with 2.4 like I
could with 2.3 using the "-R" switch. Do you invoke Registry parsing the
same with 2.4 and Timeliner? When I remove the "-R" flag timeliner runs as
expected. Apologies if this has been discussed somewhere. I've tried with
Vol.py (compiled from source) and the Windows binary flavor of 2.4.
Here's the errors I am receiving:
C:\Users\DFIR-PC\Desktop\Mem>vol.exe -f Bad.img timeliner --output=body >
timeline.txt -R
Volatility Foundation Volatility Framework 2.4
Usage: Volatility - A memory forensics analysis platform.
vol.exe: error: no such option: -R
C:\Users\DFIR-PC\Desktop\Mem>vol.exe -f Bad.img timeliner --output=body
--output-file=timeline.txt -R
Volatility Foundation Volatility Framework 2.4
Usage: Volatility - A memory forensics analysis platform.
vol.exe: error: no such option: -R
C:\Users\DFIR-PC\Desktop\Mem>c:\volatility-master\vol.py -f Bad.img
timeliner --output=body --output-file=timeline.txt -R
Volatility Foundation Volatility Framework 2.4
Usage: Volatility - A memory forensics analysis platform.
vol.py: error: no such option: -R
Thanks!
Jared
9 years, 12 months
- 3
- 2
RE: [Vol-users] Output of strings not found in memdump output - QEMU/QEVM sample
by Torres, Geoff (Cyber Security)
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)volatilesystems.com [mailto:vol-users-bounces@volatilesystems.com] On Behalf Of Michael Ligh
Sent: Tuesday, March 24, 2015 6:49 AM
To: Bridgey theGeek
Cc: vol-users(a)volatilesystems.com
Subject: Re: [Vol-users] Output of strings not found in memdump output
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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>> 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>>> 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>>>> 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>>>>> 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
>>>>>
>>>>
>
>
> **********************************************************************
> **
>
>
>
>
>>>> 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)volatilesystems.com
> <mailto:Vol-users@volatilesystems.com>
>> <mailto:Vol-users@volatilesystems.com
> <mailto:Vol-users@volatilesystems.com>>
>>> <mailto:Vol-users@volatilesystems.com
> <mailto:Vol-users@volatilesystems.com>
>> <mailto:Vol-users@volatilesystems.com
> <mailto:Vol-users@volatilesystems.com>>>
>>> <mailto:Vol-users@volatilesystems.com
> <mailto:Vol-users@volatilesystems.com>
>> <mailto:Vol-users@volatilesystems.com
> <mailto:Vol-users@volatilesystems.com>>
>>> <mailto:Vol-users@volatilesystems.com
> <mailto:Vol-users@volatilesystems.com>
>>> <mailto:Vol-users@volatilesystems.com
> <mailto:Vol-users@volatilesystems.com>>>>
>>>>> http://lists.volatilesystems.com/mailman/listinfo/vol-users
>>>>>
>>>>
>>>>
>
>>>>>
>
>
>
>>> _______________________________________________ Vol-users mailing
>>> list Vol-users(a)volatilesystems.com
> <mailto:Vol-users@volatilesystems.com>
>>> <mailto:Vol-users@volatilesystems.com
> <mailto:Vol-users@volatilesystems.com>>
>>> http://lists.volatilesystems.com/mailman/listinfo/vol-users
>
>
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
iF4EAREKAAYFAlURazkACgkQXnt9v1O0LItfjAD/W7UeZMNiWVRMqeeJftNRaxG2
dpi/c755Qxc6X7PUKU8A/iREkToI9Ad0/GejtG32OpZMLjk0gjhj5XoMxAWuY69D
=JNEv
-----END PGP SIGNATURE-----
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilesystems.com
http://lists.volatilesystems.com/mailman/listinfo/vol-users
10 years
- 5
- 12
mac_psxview command problem on Yosemite
by Justin q. Case
Hey everyone, I recently built a 10.10.3 Yosemite profile for 10.10.3 image I have. When I try to run mac_psxview on the image, I’m getting a bunch of errors as shown below. Any ideas?
bash-3.2# python /usr/local/bin/vol.py -f /users/msquire/desktop/share/macloginELF.dump --profile MacYosemite10_10_3_64bitx64 mac_psxview
Volatility Foundation Volatility Framework 2.4
Traceback (most recent call last):
File "/usr/local/bin/vol.py", line 5, in <module>
pkg_resources.run_script('volatility==2.4', 'vol.py')
File "/Library/Python/2.7/site-packages/pkg_resources/__init__.py", line 729, in run_script
self.require(requires)[0].run_script(script_name, ns)
File "/Library/Python/2.7/site-packages/pkg_resources/__init__.py", line 1642, in run_script
exec(code, namespace, namespace)
File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/EGG-INFO/scripts/vol.py", line 192, in <module>
main()
File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/EGG-INFO/scripts/vol.py", line 183, in main
command.execute()
File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/plugins/mac/common.py", line 46, in execute
commands.Command.execute(self, *args, **kwargs)
File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/commands.py", line 99, in execute
if not self.is_valid_profile(profs[self._config.PROFILE]()):
File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/plugins/overlays/mac/mac.py", line 1098, in __init__
obj.Profile.__init__(self, *args, **kwargs)
File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 858, in __init__
self.reset()
File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/plugins/overlays/mac/mac.py", line 1117, in reset
self.load_modifications()
File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 940, in load_modifications
mod.modification(self)
File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/plugins/overlays/mac/mac.py", line 1367, in modification
profile.merge_overlay(mac_overlay)
File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 1031, in merge_overlay
self.vtypes[k] = self._apply_overlay(self.vtypes[k], v)
File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 1081, in _apply_overlay
result.append(self._apply_overlay(type_member[i], overlay[i]))
File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 1068, in _apply_overlay
result[k] = self._apply_overlay(type_member[k], v)
File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 1081, in _apply_overlay
result.append(self._apply_overlay(type_member[i], overlay[i]))
File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 1072, in _apply_overlay
if len(overlay) != len(type_member):
TypeError: object of type 'int' has no len()
Using OSXPmem to acquire the images, tried with RAW, ELF (as above), and MACHO types.
This has been killing me, any help would be greatly appreciated!
Thank you!
10 years
- 1
- 0
Calling memory analysis in NY, Reston, and Amsterdam
by Michael Ligh
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi folks,
If you're in the NY area next week, hook up with us and some other
@volatility users for a few drinks on Wednesday night (13th). Request
details off list.
Also just a heads up for the next Malware and Memory Forensics
training classes...we'll be in Amsterdam Aug 31 - Sept 4 and then back
in Reston, VA October 5 - 9. We hope to see some of you there!
MHL
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
iF4EAREKAAYFAlVOL/8ACgkQXnt9v1O0LIsTOAD/RAAqA2H0UHLht6daYd1LRVSg
5Wie9xEysWHJx5o42MgBAIrHRvTvUiGXWfBW9IdrDE522taJjmoxftRc6P1OpN8a
=SOEJ
-----END PGP SIGNATURE-----
10 years
- 1
- 0
BSidesNOLA is one month away!
by Andrew Case
Hello All,
We are writing as BSidesNOLA is roughly one month away, and we would
like to see everyone there.
We have put together our best speaker lineup yet, and we want to get as
big a crowd as possible for learning, networking, and a day of fun.
Registration is only $10, but you must pre-register through Eventbrite:
https://www.eventbrite.com/e/bsides-nola-2015-tickets-9621601469.
Full information on the conference, including the keynote and 18
technical presentations, can be found here:
http://www.securitybsides.com/w/page/91550808/BSidesNOLA%202015
We hope to see everyone there, and please don’t be shy of spreading the
word!
Thanks,
The BSidesNOLA Team
10 years
- 1
- 0