On 2013-04-12 15:59, Michael Cohen wrote:
> you can try to install pytz :-)
>
> for example on ubuntu the package is called python-tz:
>
> apt-get install python-tz
>
> on windows you need to get pip or easy install then
>
> pip install pytz
>
> Or you can try the windows binary from the downloads section because
> it has no required dependencies.
>
> Michael.
Heh..always so easy :) Thanks...it's flying now. Last thing I think I
need is plugins...here's what the TP responds with:
subcommands:
The following plugins can be selected.
Plugin
dis Disassemble the given address space.
dt Print a symbol.
dump Hexdump an object or memory location.
grep Search an address space for keywords.
guess_profile Guess the exact windows profile using
heuristics.
imagecopy Copies a physical address space out as a raw DD
image
info Print information about various subsystems.
load_as Load address spaces into the session if its not
already loaded.
null This plugin does absolutely nothing.
peinfo Print information about a PE binary.
is there a different spot do snag the plugins, or am I barking up the
wrong tree? Thanks again for all your help on this.
James
On 2013-04-12 15:44, Michael Cohen wrote:
> Note that this actually is already available in the tech preview
> edition using a slightly different mechanism (Its specific to
> registry
> hives instead of for generally cached files):
>
>
> https://volatility.googlecode.com/svn/branches/scudette/docs/user_manual.ht…
> [3]
>
> YMMV
> Michael.
Thanks Michael...I did give that a go but got:
ImportError: No module named pytz
Betting I'm missing something. Thanks again.
James
On 2013-04-12 15:43, david nardoni wrote:
> Here is a blog post that may suit your needs
>
> http://mikemachnik.com/2013/02/16/memdumpcracking/ [3]
>
> Dave Nardoni
> dnardoni(a)gmail.com [4]
>
> On Fri, Apr 12, 2013 at 2:18 PM, James Lay <jlay(a)slave-tothe-box.net
> [5]> wrote:
>
>> Hey all,
>>
>> Topic says it...any way to dump a full registry hive to disk? My
>> plan is to import the SYSTEM and SECURITY into Cain ;) Thank you.
>>
>> James
Thank you for the info...very useful!
James
Topic says it...here's what I'm looking at:
Volatile Systems Volatility Framework 2.2
Traceback (most recent call last):
File "/usr/local/bin/vol.py", line 186, in <module>
main()
File "/usr/local/bin/vol.py", line 168, in main
command = cmds[module](config)
File "/opt/volatility-2.2/volatility/plugins/malware/malfind.py",
line 347, in __init__
help = 'Match wide (unicode) strings')
File "/opt/volatility-2.2/volatility/conf.py", line 364, in
add_option
self.optparser.add_option("-{0}".format(short_option),
"--{0}".format(option), **args)
File "/usr/lib/python2.7/optparse.py", line 1020, in add_option
self._check_conflict(option)
File "/usr/lib/python2.7/optparse.py", line 995, in _check_conflict
option)
optparse.OptionConflictError: option -W/--wide: conflicting option
string(s): -W
Any hints on how to get yarascan to run? Thank you.
James
Thanks,
looking forward for your reply :)
On Wed, Mar 20, 2013 at 3:18 PM, david nardoni <dnardoni(a)gmail.com> wrote:
> I will get you all those details today, except the full snapshot. I can
> not share that
>
> Happy to run whatever you need and provide output
>
> Sent from my iPhone
>
> On Mar 20, 2013, at 3:31 AM, nir izraeli <nirizr(a)gmail.com> wrote:
>
> Hi Dave,
>
> a few questions if you don't mind,
> what's the VM version (vmware has numbered versions for their file
> formats, you can usually look it up in the VM's properties)?
> could you share the output of psscan?
> what other plugins you've tried running? could you share the output?
> will it be possible to upload the VMware snapshot somewhere so i could
> look into it?
>
> Thanks,
> - Nir.
>
>
>
> On Tue, Mar 19, 2013 at 2:31 AM, david nardoni <dnardoni(a)gmail.com> wrote:
>
>> I think I have some issues with a 8+gb VMware snapshot. I can get
>> psscan and thrdscan output but no other output from other plugins.
>>
>> Any suggestions from the group on troubleshooting the image.
>>
>> Fyi I can see all the data when I view it in hbgary responder pro.
>>
>> Thanks
>>
>> Dave
>>
>> Sent from my iPhone
>> _______________________________________________
>> Vol-users mailing list
>> Vol-users(a)volatilityfoundation.org
>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>
>
>
Hello,
We wanted to take the opportunity to point you to a blog post which gives a
preview of some of the research we've been working on at 504ENSICS Labs in
the area of Android memory analysis. We think our results will be of great
interest to the DFIR community and look forward to your feed back.
The blog post can be found here:
http://www.504ensics.com/android-application-dalvik-memory-analysis-the-chu…
---
Joe T. Sylve, M.S.
Co-Founder
504ENSICS Labs
www.504ensics.com | (504) 210-8270
Hi,
I was wondering: did anyone ever managed to do an analysis with a real
device? I know the answer is Yes.
The thing is that I've seen around many nice examples and tutorials
working... but all of them with the emulator. The only real device sample
"in the wild" seems to be the Evo4GRodeo samples from DFWRS Challenge.
This time I'm pretty sure I did (almost?) everything right. Although if it
doesn't work, probably it's not.
I've tried also with another smartphone other than the HTC One X, the
Galaxy Nexus, getting the correct kernel version. No compilation errors, no
module errors, no lime module crashing on the phone, no volatility profiles
error, nothing. Everything (looks) right.
But still, when trying to run volatility I still keep getting empty results
like this:
hydra:volatility-read-only paco$ python vol.py
--profile=LinuxGalaxyNexus-3_0_1x86 -f ~/memdump/test-lime-4.7.lime
linux_pslist
Volatile Systems Volatility Framework 2.3_alpha
WARNING : volatility.obj : Overlay structure cpuinfo_x86 not present
in vtypes
Offset Name Pid Uid Gid DTB
Start Time
---------- -------------------- --------------- --------------- ------
---------- ----------
Now I start wondering two things:
- Is it my lime dump the issue? the header looks fine, if I look inside
with hexdump it seems reasonable, if I strings it I find my data.
- Is it the volatility profile? Maybe, because I've event tried to dump the
memory of my Galaxy Nexus with FROST (which uses LiME) and the result looks
the same. So I started believing my problem is in the profile, although I
cannot seem to find any other way to understand where the problem could be.
So if anyone who successfully analyzed Android memory dumps from any real
life device is willing to share his experience and/or Volatility profile,
it would be great.
Thanks
P.
--
Pasquale Stirparo, MEng
GCFA, OPST, OWSE, ECCE
Brian,
You must be talking about Jesse's rawmoddump plugin. Its interesting to see
how people go about solving problems. Rather than typing 3 lines into the
existing volshell plugin, he re-implemented the same functionality into a
70 line file and then blogged about it as if it was some ground breaking
new capability...lol.
Anyway, there are a few possible explanations for finding a legitimate
driver at an offset from the base address reported by modscan. One is that
modscan found an _LDR_DATA_TABLE_ENTRY structure in physical memory that
represents a driver that was once loaded at address XXXXXXXX but has since
moved or unloaded. In that case, the kernel would be allowed to map another
driver into that available space (starting at either the exact same or a
nearby address).
Another plausible scenario is that modscan found an _LDR_DATA_TABLE_ENTRY
for a module that is still loaded at its original address (check with
modlist which will show currently loaded modules). The driver has another
driver embedded in its resources section that it installed or planned to
install. In that case you would expect to find another PE file somewhere
near the base of the first one.
Hope this helps,
MHL
On Fri, Mar 22, 2013 at 12:28 AM, Brian Keefer <chort(a)effu.se> wrote:
> Michael,
>
> Yes, modscan showed the file as being
> from C:\Users\Bob\ApplicationData\dumpme.sys -like path. It's great to
> learn this can be done via volshell, which is not something I've explored
> yet. Someone else sent me a plugin off-list that essentially wraps that
> functionality.
>
> It looks like the legitimate driver is at an offset from the base address
> reported by modscan (is it typical for drivers to load from a user
> directory?). I'm not sure what the padding is before it. Could it perhaps
> be instructions, or maybe an XOR'd PE header? Not sure exactly.
>
> --
> chort
>
>
>
> On Mar 21, 2013, at 8:53 PM, Michael Hale Ligh wrote:
>
> Hey Brian,
>
> You can use volshell to extract an arbitrary region of memory from any
> address space (in this case kernel memory if you're trying to acquire a
> kernel module). However, what do you mean "reference a file in user's
> AppData"? Is that the driver's path on disk (i.e.
> C:\Users\Bob\ApplicationData\dumpme.sys)?
>
> You would use volshell like this:
>
> >>> data = self.addrspace.zread(assumed_base_address, assumed_module_size)
> >>> with open('file.dmp', 'wb') as f:
> ...... f.write(data)
> >>>
>
> Cheers,
> MHL
>
>
> On Thu, Mar 21, 2013 at 5:32 PM, Brian Keefer <chort(a)effu.se> wrote:
>
>> Working with a ransomware infection, trying to dump one of the modules
>> that looks suspicious (the only one to reference a file in user's AppData).
>> I'm trying to dump it via the base address found through modscan, but
>> getting:
>> moddump Error: e_magic 8D4C is not a valid DOS signature.
>>
>> I tried -u. Is there any other way to dump it?
>>
>> --
>> chort
>>
>>
>>
>> _______________________________________________
>> Vol-users mailing list
>> Vol-users(a)volatilityfoundation.org
>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>
>
>
>
My Malware Analysts Cookbook refers to this module and I found a couple
of videos on how to use it; I just can't seem to locate the module itself.
Has it perhaps been deprecated by some other plugin or process?
Thanks!
-=[ Steve ]=-
