Hi guys,
I'm trying to recover a php script from a suspected system. The file was
stored in a tmpfs filesystem and i cannot recover it. In the php process
(running from cli) i can see references to the script but can't find the
code.
The suspected system in running Debian 8.9: Linux version 3.16.0-4-amd64
(gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.43-2+deb8u5
(2017-09-19).
I've tried to use linux_tempfs to recover /dev/shm from memory but got some
errors with volatility with no success:
# ~/bin/vol26 --plugins=profiles --profile=LinuxDebian89x64 -d -f
memory.dump linux_tmpfs -S 4 -D dump/
[...]
WARNING : volatility.debug : NoneObject as string: Invalid offset 0 for
dereferencing name as String WARNING : volatility.debug : NoneObject as
string: Invalid offset 0 for dereferencing name as String WARNING :
volatility.debug : NoneObject as string: Invalid offset 0 for dereferencing
name as String WARNING : volatility.debug : NoneObject as string: Invalid
offset 0 for dereferencing name as String WARNING : volatility.debug :
NoneObject as string: Invalid offset 0 for dereferencing name as String
The php process has pid 1234, using volatility linux_dump_map on that
process I see the following strings in dumped file
task.1234.0x7f003ddf3000.vma:
/dev/shm/script.php(1) : eval()'d code0x7f003ddf303f
/dev/shm/script.php(1) : eval()'d code0x7f003ddf8e2e
/dev/shm/script.php(1) : eval()'d code0x7f003ddf952a
/dev/shm/script.php(1) : eval()'d code0x7f003ddfa588
/dev/shm/script.php(1) : eval()'d code0x7f003ddfa7f3
I'm stuck now trying to recover the php eval'd code, any ideas?
Thanks
Valter
We are excited to announce that two of our public trainings for 2018
have now been scheduled!
The first will be in April in Herndon, VA:
https://www.memoryanalysis.net/single-post/2017/09/30/New-Event-in-Herndon-…
The second will be in Herndon in October:
https://www.memoryanalysis.net/single-post/2017/09/30/New-Event-in-Herndon-…
We are also in the process of scheduling public trainings in Australia
for Q1 2018 and Europe for Q3. We will send out an update when these are
confirmed, but please contact us if you would like to be placed on the
notification list for either course.
To see some of the recent updates to the course, be sure to check out
our blog post:
https://volatility-labs.blogspot.com/2017/06/our-newly-updated-memory-foren…
Also, we are continuing to have many repeat students - for which we are
very grateful! If you are a previous student and wish to attend again,
then please inquire with us about the repeat-student discount.
Finally, if you will be around during OSDFCON in a few weeks then let
us know if you would like to meet up as most of the team will be in town.
-- The Volatility Team
Hello vol-users!
I'm working on a forensics case where I have multiple memory scrapes with
strange volatility output. This has down some rabbit holes and I'm at the
point where signs are pointing to anti-forensics. This has led me to dig
into how pool tag scanning works and I've found several articles
referencing a apparently still yet unreleased (mentioned in 2014, and 2016)
Volatility plugin called TCPScan which uses an alternative method (which
uses methods that are not detailed).
You can find references to the plugin here:
https://scudette.blogspot.com/2014/02/anti-forensics-and-
memory-analysis.html
https://findingbad.blogspot.com/2016/09/forensic-analysis-
of-anti-forensic.html
Does anyone have access to or can anyone put me in touch with anyone who
has access to this plugin? Or can anyone talk to the methods that it uses
to scan for connections?
Thanks,
Nate Subra
Hi all,
Hoping somebody can provide some comments re ELF files in memory.
My ultimate question is: How can I find the .bss section of an ELF
file in memory?
But I have a more specific one. Consider the following output from a
Volatility plugin I wrote which aims to parse the segments:
Volatility Foundation Volatility Framework 2.6
# First we grab the proc_maps which are mapped to the process of
interest (in this case, Xorg)...
# This mimics the linux_proc_maps plugin
Parsing proc maps...
/usr/lib/xorg/Xorg r-x start=0x55d4ddda4000 end=0x55d4ddfe0000 length=0x23c000
/usr/lib/xorg/Xorg r-- start=0x55d4de1e0000 end=0x55d4de1e2000 length=0x2000
/usr/lib/xorg/Xorg rw- start=0x55d4de1e2000 end=0x55d4de1ef000 length=0xd000
# Not listing anonymous maps for now.
# The we parse the ELF header which is at the start of the first
proc_map shown above
Parsing elf_ehdr...
Container({'e_flags': 0, 'e_shoff': 2401000, 'e_phoff': 64, 'e_shnum':
30, 'e_entry': 270368, 'e_version': 'EV_CURRENT', 'e_machine':
'EM_X86_64', 'e_phnum': 9, 'e_shentsize': 64, 'e_ident':
Container({'EI_DATA': 'ELFDATA2LSB', 'EI_OSABI': 'ELFOSABI_SYSV',
'EI_VERSION': 'EV_CURRENT', 'EI_CLASS': 'ELFCLASS64', 'EI_ABIVERSION':
0, 'EI_MAG': [127, 69, 76, 70]}), 'e_type': 'ET_DYN', 'e_phentsize':
56, 'e_shstrndx': 29, 'e_ehsize': 64})
# This looks sane, so let's go to e_phoff (64) and read the program header
Parsing segments...
0x55d4ddda4040 Segment<p_memsz=0x1f8, p_flags=0x5, p_offset=0x40,
p_type=PT_PHDR, p_align=0x8, p_paddr=0x40, p_filesz=0x1f8,
p_vaddr=0x40>
0x55d4ddda4078 Segment<p_memsz=0x1c, p_flags=0x4, p_offset=0x238,
p_type=PT_INTERP, p_align=0x1, p_paddr=0x238, p_filesz=0x1c,
p_vaddr=0x238>
0x55d4ddda40b0 Segment<p_memsz=0x23bdd4, p_flags=0x5, p_offset=0x0,
p_type=PT_LOAD, p_align=0x200000, p_paddr=0x0, p_filesz=0x23bdd4,
p_vaddr=0x0>
0x55d4ddda40e8 Segment<p_memsz=0x1f8f0, p_flags=0x6,
p_offset=0x23c408, p_type=PT_LOAD, p_align=0x200000, p_paddr=0x43c408,
p_filesz=0xdd98, p_vaddr=0x43c408>
0x55d4ddda4120 Segment<p_memsz=0x2e0, p_flags=0x6, p_offset=0x23dc78,
p_type=PT_DYNAMIC, p_align=0x8, p_paddr=0x43dc78, p_filesz=0x2e0,
p_vaddr=0x43dc78>
0x55d4ddda4158 Segment<p_memsz=0x44, p_flags=0x4, p_offset=0x254,
p_type=PT_NOTE, p_align=0x4, p_paddr=0x254, p_filesz=0x44,
p_vaddr=0x254>
0x55d4ddda4190 Segment<p_memsz=0x9904, p_flags=0x4, p_offset=0x1f2b50,
p_type=PT_GNU_EH_FRAME, p_align=0x4, p_paddr=0x1f2b50,
p_filesz=0x9904, p_vaddr=0x1f2b50>
0x55d4ddda41c8 Segment<p_memsz=0x0, p_flags=0x6, p_offset=0x0,
p_type=PT_GNU_STACK, p_align=0x10, p_paddr=0x0, p_filesz=0x0,
p_vaddr=0x0>
0x55d4ddda4200 Segment<p_memsz=0x1bf8, p_flags=0x4, p_offset=0x23c408,
p_type=PT_GNU_RELRO, p_align=0x1, p_paddr=0x43c408, p_filesz=0x1bf8,
p_vaddr=0x43c408>
# These segments look sane, and in fact the values match what I see
from `readelf --segments` against the Xorg binary on disk.
# I ignore the first PT_LOAD segment because the p_flags and p_vaddr
tell me the .bss isn't going to be in there. (As does the output from
`readelf --segments`)
# And I try to read the data pointed to by the p_vaddr of the second PT_LOAD
Testing PT_LOAD at 0x55d4ddda40e8.
# Let's re-print the segment to remind ourselves:
0x55d4ddda40e8 Segment<p_memsz=0x1f8f0, p_flags=0x6,
p_offset=0x23c408, p_type=PT_LOAD, p_align=0x200000, p_paddr=0x43c408,
p_filesz=0xdd98, p_vaddr=0x43c408>
# So starting at the base address (0x55d4ddda4000) + p_vaddr
(0x43c408) =0x55d4de1e0408, I should be able to read p_memsz (0x1f8f0)
bytes, right?
# Wrong... I can only read 0xebf7 (60,407) bytes before volatility
reports an error
Failed to read offset 0xebf8==60408
Notably, the starting offset, 0x55d4de1e0408, is in:
/usr/lib/xorg/Xorg r-- start=0x55d4de1e0000 end=0x55d4de1e2000 length=0x2000
but of course is bigger than the size of the proc_map.
I really do appreciate any comments you might have as to where my
understanding is lacking!
Adam
Hello!
I posted this question already, but i could not find it on the
archive, so I am trying it again.
I am doing some research on RAM extraction and analysis in Android (6
Marshmallow). I succeeded in compiling my own Kernel with enabled
CONFIG_MODULE_LOAD and installing it onto my Nexus 5X. Creating the
LiME module to extract the RAM was also successful, I could get a
memory dump of the device on my computer. In a Hex-editor, I can see
content of the RAM (boot pictures, text messages,…).
I also asked this question at stackoverflow, it is better readable
there due to formatting reasons:
https://stackoverflow.com/questions/44807171/keyerror-int128-unsigned-in-dw…
But now I have problems using Volatility 2.6. My steps so far:
• get volatility
git clone https://github.com/volatilityfoundation/volatility.git
cd volatility/tools/linux
• Adjust Makefile (I also had to uncomment #define RADIX_TREE_MAX_TAGS
2 in the module.o, otherwise I got an error during make)
obj-m += module.o
KDIR := /root/compile/msm/
CCPATH := /root/compile/msm/aarch64-linux-android-4.9/bin
-include version.mk
all: dwarf
dwarf: module.c
$(MAKE) ARCH=arm64 CROSS_COMPILE=$(CCPATH)/aarch64-linux-android-
-C $(KDIR) \
CONFIG_DEBUG_INFO=y M=$(PWD) modules
dwarfdump -di module.ko > module.dwarf
make
• Combine System.map (created during kernel compilation) and
module.dwarf (created during make) and copy the .zip it into the
overlays directory
zip Nexus5X.zip module.dwarf ../../../System.map
cp Nexus5X.zip ../../volatility/plugins/overlays/linux/
• run volatility
python vol.py --profile=LinuxNexus5Xx64 -f
/root/Documents/nexus-ram.dump linux_pslist
The parameters are all correct - the profile exists, the file also and
linux_pslist is a valid command. But even with other commands such as
linux_cpuinfo, I get the following error:
root@kali:~/compile/msm/volatility-2.6# python vol.py
--profile=LinuxNexus5Xx64 -f /root/Documents/nexus-ram.dump linux_pslist
Volatility Foundation Volatility Framework 2.6
Traceback (most recent call last):
File "vol.py", line 192, in <module>
main()
File "vol.py", line 183, in main
command.execute()
File
"/root/compile/msm/volatility-2.6/volatility/plugins/linux/common.py",
line 64, in execute
commands.Command.execute(self, *args, **kwargs)
File "/root/compile/msm/volatility-2.6/volatility/commands.py",
line 116, in execute
if not self.is_valid_profile(profs[self._config.PROFILE]()):
File
"/root/compile/msm/volatility-2.6/volatility/plugins/overlays/linux/linux.py",
line 216, in __init__
obj.Profile.__init__(self, *args, **kwargs)
File "/root/compile/msm/volatility-2.6/volatility/obj.py", line
862, in __init__
self.reset()
File
"/root/compile/msm/volatility-2.6/volatility/plugins/overlays/linux/linux.py",
line 227, in reset
self.load_vtypes()
File
"/root/compile/msm/volatility-2.6/volatility/plugins/overlays/linux/linux.py",
line 264, in load_vtypes
vtypesvar = dwarf.DWARFParser(dwarfdata).finalize()
File "/root/compile/msm/volatility-2.6/volatility/dwarf.py", line
71, in __init__
self.feed_line(line)
File "/root/compile/msm/volatility-2.6/volatility/dwarf.py", line
162, in feed_line
self.process_statement(**parsed) #pylint: disable-msg=W0142
File "/root/compile/msm/volatility-2.6/volatility/dwarf.py", line
225, in process_statement
self.id_to_name[statement_id] = [self.base_type_name(data)]
File "/root/compile/msm/volatility-2.6/volatility/dwarf.py", line
125, in base_type_name
return self.tp2vol[data['DW_AT_name'].strip('"')]
KeyError: '__int128 unsigned'
Can you help me figuring out the error and how to solve it? Or any
related work which did RAM extraction from Android > 5.0 ?
The string "__int128 unsigned" is inside the module.dwarf two times. I
posted the Module.dwarf here as it would be too big for this mail (it
needs some time until the web page appears):
http://chopapp.com/#b27ludkk
Thanks in advance!
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
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)
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.
We are very excited to announce that our 5th annual Volatility Plugin
Contest is now live, and we are accepting submissions until October 1st,
2017. We are giving away over $2,000 in prizes and swag - so get coding!!!
Full details on our blog post:
https://volatility-labs.blogspot.com/2017/04/the-5th-annual-2017-volatility…
Please let us know if you have any questions and good luck to all!
