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@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@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@volatilityfoundation.org
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>
_______________________________________________
Vol-users mailing list
Vol-users@volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users