Hi
Thank you Andrew and Tamas for your responses, yes I had a feeling xl dump
could not be analysed but I wanted to be sure in case it had a specially
command.
But i will try out Volatility 2.4 just to be sure
I am currently working on xenstore permissions.
Thank for the clarification
On Tue, Aug 12, 2014 at 5:18 PM, Tamas Lengyel <tamas.k.lengyel(a)gmail.com>
wrote:
Hi Tawfiq,
'xl dump-core' and 'xl save' format, to my knowledge, is not supported
by
Volatility.
If you can perform xl dump-core in a pv guest (I assume a secondary
control domain you setup with XSM), you should be able to use LibVMI in the
same domain, provided you forgo using Xenstore or set appropriate Xenstore
permissions. This is a topic however more suitable to the LibVMI
mailinglist..
Thanks,
Tamas
On Tue, Aug 12, 2014 at 10:07 PM, Andrew Case <atcuno(a)gmail.com> wrote:
Hello,
Could you try with the latest version of Volatility (2.4):
https://github.com/volatilityfoundation/volatility
There was quite a bit of new support for ELF files added.
Thanks,
Andrew (@attrc)
On 08/12/2014 12:20 PM, Tawfiq Shah wrote:
Hi all
I am wanting to perform memory introspection in my xen setup. I have
been using libvmi with volatility to analysis memory dumps of a domU. I
have done and tested it in Dom0 and it works.
I now want to create a similar setup in a pv domU but i am unable to get
libVMI working,.
Since i can use xl dump-core <domid> <filename> in my pv to extract any
hvm dump. I am using xsm and i have added all the necessary rules for
memory extraction.
This is the command i use to analysis the dump extracted using xl
dump-core
note: i created the Linuxkbeastx86 profile to
the kernel i have
infecting kbeast and this profile worked in dom0 when i used libVMI
dump memory but in the pv it does not, also tested xl dump with
volatility in dom0 and it did not work.
So can volatility process xl dump ?
below is the example out put i get
python /root/Volatility/vol.py -f /root/kbeastDump
--profile=Linuxkbeastx86 linux_check_modules
Volatility Foundation Volatility Framework 2.3.1
Module Name
-----------
No suitable address space mapping found
Tried to open image as:
MachOAddressSpace: mac: need base
LimeAddressSpace: lime: need base
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
HPAKAddressSpace: No base Address Space
VirtualBoxCoreDumpElf64: No base Address Space
VMWareSnapshotFile: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
AMD64PagedMemory: No base Address Space
IA32PagedMemoryPae: No base Address Space
IA32PagedMemory: No base Address Space
PyVmiAddressSpace: Location doesn't start with vmi://
MachOAddressSpace: MachO Header signature invalid
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile
WindowsCrashDumpSpace64: Header signature invalid
HPAKAddressSpace: Invalid magic found
VirtualBoxCoreDumpElf64: ELF error: did not find any PT_NOTE segment
with VBCORE
VMWareSnapshotFile: Invalid VMware signature: 0x464c457f
WindowsCrashDumpSpace32: Header signature invalid
AMD64PagedMemory: Incompatible profile Linuxkbeastx86 selected
IA32PagedMemoryPae: Failed valid Address Space check
IA32PagedMemory: Failed valid Address Space check
PyVmiAddressSpace: Must be first Address Space
FileAddressSpace: Must be first Address Space
ArmAddressSpace: Failed valid Address Space check
if anyone could give me some advice on this
Thank you
_______________________________________________
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