Why is this user-space data only in kernel space? #linux
by Bridgey theGeek
Hi all,
This is a "what don't I know?" question...
I have a very simple C program:
#include <gtk/gtk.h>
#include <stdio.h>
int main(int argc, char **argv)
{
GtkTextBuffer *buffer;
buffer = gtk_text_buffer_new(NULL);
gtk_text_buffer_set_text(buffer, "adam1adam2adam3", 15);
printf("buffer: %p\n", buffer);
getchar();
return 0;
}
Then the following to try and locate the strings in memory:
------------------------------------------------------------
$ strings --radix=d LinuxMint-17.3-Mate-x64-61951b91.vmem | fgrep
adam1adam2adam3 >/tmp/s
------------------------------------------------------------
$ cat /tmp/s
195393652 adam1adam2adam3
204175816 adam1adam2adam3
851998836 adam1adam2adam3
------------------------------------------------------------
$ ~/src/volatility/vol.py -f LinuxMint-17.3-Mate-x64-61951b91.vmem
--profile LinuxMint173x64 linux_strings -s /tmp/s
Volatility Foundation Volatility Framework 2.6
195393652 [kernel:88000ba57874] adam1adam2adam3
204175816 [kernel:88000c2b79c8] adam1adam2adam3
851998836 [kernel:880032c87874] adam1adam2adam3
------------------------------------------------------------
Why on earth would the string only be located in Kernel space??
I've been digging into Gtk for quite some time now to try and solve this
and think I understand that in Gtk, text is stored as GtkTextLineSegments.
The memory for a GtkTextLineSegment is allocated via g_slice_alloc and the
actual text copied to the allocated space via an ordinary memcpy (See:
https://github.com/GNOME/gtk/blob/406db15066f121c2b9910691f92e58
41b30e0311/gtk/gtktextsegment.c#L190-L210)
I've proved the text really is here by editing the text in the VMEM file in
a hex editor and then resuming the VM - sure enough the text is updated to
reflect the changes.
I could just about understand the text being in Kernel space AND user space
because perhaps its sent to the X server or something, but it appears to
ONLY be in Kernel space.
What don't I know??
Many thanks,
Adam
6 years, 10 months
- 2
- 3
Problem with Virtualbox Dumps
by Thomas
Hi,
using the current version from GitHub (-> git pull) I can’t analyze Virtualbox memory dump files anymore. I’m using Virtualbox v5.1.22 (current release).
I’m using Cuckoo Sandbox (v2.0 and cuckoo-modified) and vol.py doesn’t recognize the memory.dmp files anymore. Neither within Cuckoo processing nor manually from the command line. My Virtual machine contains Windows 7 SP1 x86 Pro and the memory dumps could be analyzed successfully in the past. This happens when using all Win7 profiles.
See some vol.py messages below. Taken from an older memory.dmp file which could be successfully analyzed by vol.py with cuckoo-modified when it was created in 2016. If needed I can share the memory dump (2,1 GB, zipped ~640 MB).
Thomas
1)
vol.py -f memory.dmp --profile=Win7SP1x86 pslist
Volatility Foundation Volatility Framework 2.6
No suitable address space mapping found
Tried to open image as:
MachOAddressSpace: mac: need base
LimeAddressSpace: lime: need base
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace64BitMap: No base Address Space
VMWareMetaAddressSpace: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
HPAKAddressSpace: No base Address Space
VirtualBoxCoreDumpElf64: No base Address Space
VMWareAddressSpace: No base Address Space
QemuCoreDumpElf: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
Win10AMD64PagedMemory: No base Address Space
WindowsAMD64PagedMemory: No base Address Space
LinuxAMD64PagedMemory: No base Address Space
AMD64PagedMemory: No base Address Space
IA32PagedMemoryPae: No base Address Space
IA32PagedMemory: No base Address Space
OSXPmemELF: No base Address Space
MachOAddressSpace: MachO Header signature invalid
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: No xpress signature found
WindowsCrashDumpSpace64BitMap: Header signature invalid
VMWareMetaAddressSpace: VMware metadata file is not available
WindowsCrashDumpSpace64: Header signature invalid
HPAKAddressSpace: Invalid magic found
VirtualBoxCoreDumpElf64: ELF error: did not find any PT_NOTE segment with VBCORE
VMWareAddressSpace: Invalid VMware signature: 0x464c457f
QemuCoreDumpElf: ELF error: did not find any PT_NOTE segment with CORE
WindowsCrashDumpSpace32: Header signature invalid
Win10AMD64PagedMemory: Incompatible profile Win7SP1x86 selected
WindowsAMD64PagedMemory: Incompatible profile Win7SP1x86 selected
LinuxAMD64PagedMemory: Incompatible profile Win7SP1x86 selected
AMD64PagedMemory: Incompatible profile Win7SP1x86 selected
IA32PagedMemoryPae: Failed valid Address Space check
IA32PagedMemory: Failed valid Address Space check
OSXPmemELF: No PT_LOAD segments found
FileAddressSpace: Must be first Address Space
ArmAddressSpace: Profile does not have valid Address Space check
2)
vol.py -f memory.dmp imageinfo
Volatility Foundation Volatility Framework 2.6
INFO : volatility.debug : Determining profile based on KDBG search...
Suggested Profile(s) : Win7SP1x86_23418, Win7SP0x86, Win7SP1x86 (Instantiated with Win7SP1x86)
AS Layer1 : FileAddressSpace (/daten/cuckoo-modified/storage/analyses/44/memory.dmp)
PAE type : No PAE
DTB : 0x185000L
KDBG : 0x293c504L
Number of Processors : 0
Image Type (Service Pack) : 0
KUSER_SHARED_DATA : 0xffdf0000L
3)
vol.py -f memory.dmp kdbgscan
Volatility Foundation Volatility Framework 2.6
**************************************************
Instantiating KDBG using: /daten/cuckoo-modified/storage/analyses/44/memory.dmp WinXPSP2x86 (5.1.0 32bit)
Offset (P) : 0x293c504
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win7SP1x86_23418
Version64 : 0x293c4dc (Major: 15, Minor: 7601)
PsActiveProcessHead : 0x8294fcb0
PsLoadedModuleList : 0x82956b90
KernelBase : 0x82813000
**************************************************
Instantiating KDBG using: /daten/cuckoo-modified/storage/analyses/44/memory.dmp WinXPSP2x86 (5.1.0 32bit)
Offset (P) : 0x293c504
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win7SP1x86
Version64 : 0x293c4dc (Major: 15, Minor: 7601)
PsActiveProcessHead : 0x8294fcb0
PsLoadedModuleList : 0x82956b90
KernelBase : 0x82813000
**************************************************
Instantiating KDBG using: /daten/cuckoo-modified/storage/analyses/44/memory.dmp WinXPSP2x86 (5.1.0 32bit)
Offset (P) : 0x293c504
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win7SP0x86
Version64 : 0x293c4dc (Major: 15, Minor: 7601)
PsActiveProcessHead : 0x8294fcb0
PsLoadedModuleList : 0x82956b90
KernelBase : 0x82813000
4)
vol.py -f memory.dmp --profile=Win7SP1x86 vboxinfo
Volatility Foundation Volatility Framework 2.6
ERROR : volatility.debug : Memory Image could not be identified as ['VirtualBoxCoreDumpElf64']
5)
file memory.dmp
memory.dmp: ELF 64-bit LSB core file x86-64, version 1 (SYSV)
6 years, 11 months
- 1
- 1
Our newly updated training is headed to Herndon and London!
by Andrew Case
As we enter summer, we wanted to let everyone know that we only have two
remaining public training classes for 2017. Full details of these
classes, including all the newly updated material, can be found on our
recent blog post:
https://volatility-labs.blogspot.com/2017/06/our-newly-updated-memory-foren…
Our classes have been selling out a good bit in advance so please let us
know ASAP if you wish to attend.
6 years, 11 months
- 1
- 0