Hi,
I am trying to get the value of the symbol "bt_proto" using the member
function get_symbol, I checked using gdb that this symbol is a part of the
bluetooth kernel module. But, I get the following error message
"volatility.plugins.overlays.linux.linux: Requested symbol bt_proto not
found in module kernel". Any thoughts why this might be happening?
Thanks!
Regards
Pranjal Jumde
We are happy to announce that our memory forensics training course
will be going to the Netherlands in September:
http://volatility-labs.blogspot.com/2013/04/memory-forensics-training-nethe…
This course is taught directly by Volatility developers, and will
provide intense training in memory forensics for incident response,
malware analysis, and digital forensic investigation.
This will be our only course outside of the USA in 2013, and we have
already had a number of people inquire about attending, so please
contact us ASAP if you are interested in taking it.
Thanks,
Andrew (@attrc)
Hello all,
I have arrived at an implementation part of my research and I was
wondering if you have any advice or documentation on some "pythonisms"
and "volatility-isms" I could be using to do this implementation.
My question is two-fold:
1) I have acquired a small part of memory using read/zread and want to
match (not search) this part of memory to a specific pattern. Do you
know of any pythonisms I could be using, other than checking and
matching byte by byte? Is there some type pattern I could use? I
suspect I'll just have to evaluate a list of rules, but I figured I'd
ask anyway.
2) Some parts of memory I am interested in are originally (C) structs,
I'd like to map these to objects similar to the way this is done for
structs like 'task_struct' and 'mm_struct', is there any documentation
on the way this is done?
If it matters, this is all in process address space.
Cheers,
Edwin
Hello guys,
After several months I have the alpha version of my plugin.
Actaeon is a tool to perform memory forensics of virtualization
environments.
Starting from a physical memory dump, Actaeon can achieve three important
goals: 1) locate any Hypervisor (virtual machine monitor) that uses the
Intel VT-x technology, 2) detect and analyze nested virtualization and show
the relationships among different hypervisors running on the same machine,
and 3) provide a transparent mechanism to recognize and support the address
space of the virtual machines.
You can have more information by visiting the following site:
http://s3.eurecom.fr/tools/actaeon/
I would like to have feedback (positive or negative) and ideas from you.
Let's improve Actaeon and Volatility :)
--
/mariano
Hi,
Is it possible to get the symbol table of a module? The module structure
has a member called symtab but, is it possible to get the symbol names and
values from it.
Thanks!
Hi,
I'm currently attempting to get caching working with some library code that exists outside a plugin. The code is parsing debugging symbol tables and so some caching would be useful for performance purposes.
The use of caching is normally controlled at the command line via the --cache option. Within running library code, I'm using the following pattern to detect if the --cache option was specified:
import volatility.conf as conf
class Library(object):
def __init__(self, *args, **kwargs):
config = conf.ConfObject() # singleton object
if config.CACHE:
print "cache enabled"
else:
print "cache disabled"
BTW, I'm aware that one can use the --debug option to see if caching is enabled at the terminal.
If one now places this code within the volatility directory and then calls it via a plugin - for example with say:
import volatility.plugins.common as common
from volatility.library import Library
class TestPlugin(common.AbstractWindowsCommand):
def __init__(self, *args, **kwargs):
common.AbstractWindowsCommand.__init__(self, *args, **kwargs)
lib = Library()
and now if we run the plugin, I consistently observe that the --cache option is reported as disabled.
I've tried triggering cache enabling via a callback to cache.enable_caching with no joy.
Any help is greatly appreciated.
Many thanks,
Carl.
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
