DalvikVM support for Volatility
by Holger Macht
Hi,
I've uploaded a tarball [1] containing a number of Volatility plugins which
provide support for the DalvikVM and Android. I didn't provide a
patch set, because there are only new files included. However, I can do
so or can open an issue, whatever would be most convenient.
The plugins are named:
- dalvik_find_gdvm_offset
- dalvik_vms
- dalvik_loaded_classes
- dalvik_class_information
- dalvik_find_class_instance
- dalvik_app_mirrored
Any comments would be appreciated. This is part of a research project I
need to have finished by the end of the year, so if someone suggests
fundamental changes, I most likely won't have the immediate time to look
at it. Just wanted to provide my code, because obviously there is some
interest (cf. vol-users@).
Ideally, I could get a branch in SVN to get this integrated into
upcoming Volatility releases.
I've attached a README.dalvik which gives some meta information about
the plugins and could become a corresponding wiki article.
Thanks to Joe Sylve and Andrew Case for providing me with some initial
guidelines.
Regards,
Holger
[1] http://www.homac.de/files/Volatility-Dalvik-support-v1.tar.bz2
11 years, 10 months
- 2
- 2
Windows 7 x64 _KTHREAD structure
by Cutter 409
I've noticed that on an unpatched Windows 7 x64 SP1 machine, the _KTHREAD
structure ends as follows:
+350 ThreadCounters : Ptr64 _KTHREAD_COUNTERS
+358 XSaveState : Ptr64 _XSAVE_STATE
On a version of the machine that is up to date on patches, I see _KTHREAD
ending like this:
+350 ThreadCounters : Ptr64 _KTHREAD_COUNTERS
+358 StateSaveArea : Ptr64 _XSAVE_FORMAT
+360 XSaveState : Ptr64 _XSAVE_STATE
The result is that fields in the _ETHREAD structure are shifted by 8 bytes.
on the patched machine.
I can't be certain that it was a Microsoft Update (I'm only assuming), but
does anyone know which patch causes the update?
At the very least, is there a good method for detecting if a memory image
uses one version of KTHREAD or the other?
Any information would be helpful.
Thanks!
11 years, 11 months
- 2
- 1
The Volatility Framework is now available in FreeBSD ports tree
by Sofian Brabez
Hi list,
I'm pleased to announce you the Volatility Framework is now available in FreeBSD
ports tree in security/py-volatility [1] since tonight.
It was possible with efforts of Antoine Brodin and Sofian Brabez.
Just make -C /usr/ports/security/py-volatility install clean, then try it with
vol.py and a random dump.
$ vol.py imageinfo -f /tmp/memory.dmp
Volatile Systems Volatility Framework 2.2
Determining profile based on KDBG search...
Suggested Profile(s) : Win7SP0x86, Win7SP1x86
AS Layer1 : JKIA32PagedMemoryPae (Kernel AS)
AS Layer2 : FileAddressSpace (/tmp/memory.dmp)
PAE type : PAE
DTB : 0x185000L
KDBG : 0x82948c28
Number of Processors : 1
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0x82949c00
KUSER_SHARED_DATA : 0xffdf0000
Image date and time : 2012-05-28 02:57:03 UTC+0000
Image local date and time : 2012-05-27 22:57:03 -0400
Regards
--
Sofian Brabez
11 years, 11 months
- 2
- 1