We are excited to announce that our memory forensics and malware
analysis training will be headed back to NYC in June:
http://www.memoryanalysis.net/#!memory-forensics-training/c1q3n
We have sold out rather quickly for both of our previous NYC courses, so
please let us know us ASAP if you are interested in attending.
--
Thanks,
Andrew (@attrc)
We are pleased to announce that BSidesNOLA 2016 will take place on
Saturday, April 16th in the heart of downtown New Orleans. Full details
can be found on the following page:
http://www.securitybsides.com/w/page/104051753/BSidesNOLA%202016
Our Call for Papers is currently open, and we will be accepting
submissions through February 16st. Please spend time on your CFP
submission(s) as we receive a large number each year and inevitably have
to reject some of them. You don't want to miss our speakers' party so
send us your best stuff! To see some of the accepted talks from previous
years, please see our past pages:
http://www.securitybsides.com/w/page/91550808/BSidesNOLA%202015http://www.securitybsides.com/w/page/71231585/BsidesNola2014
Please let us know if you have any questions, and if you plan to attend
you must register on the Event Brite page ($15)!
--
Thanks,
Andrew (@attrc)
vol-users,
As you know, one of the main goals of the Volatility Foundation is to
promote the use of memory analysis within the forensics community. If you
have been on this mailing list for a while or seen some of the recent
court cases, you know that one of the main challenges facing investigators
is the ability to reliably collect a sample of physical memory. The
increasing number of acquisition tools has given people a lot of options
but has also exacerbated the challenge of knowing which tool to use and
under what circumstances.
In order to address this and to reduce the amount of time we spend helping
investigators troubleshoot bad memory samples, we are working on
developing some memory acquisition guidelines for investigators. If you
have had experiences where you were unable to collect a valid sample from
a system, we would like to hear from you. This could mean that the system
crashed during collection or the collected sample couldn’t be analyzed.
In particular, we are interested in the details (hardware, software, etc)
about the system the memory was being acquired from and the version of the
tool you were using to perform the acquisition.
If you have this type of information and are able to share, please contact
me off list.
Happy holidays and hope we can catch up in the New Year!
AAron Walters
The Volatility Foundation
Hello list,
This is my first post to this list. My name is Rob, I'm located in the
Netherlands and am looking for some help in dumping the memory of an
Android phone so I can inspect it in Volatility. A bit of background as to
where I'm currently at with Volatility.
I've successfully compiled LiME against a standard linux kernel running on
Intel, created a profile with dwarfdump etc., dumped the memory and can use
the plugins successfully.
I've also installed Cyanogenmod 12.1 on a GalaxyS2 and can run LiMe on it
and dump the RAM. I have a problem with the profile not loading in
Volatility but that's for another post :-) I can run strings on the dump
and recover meaningful information though.
Cutting to the chase...
My target phone is a stock Samsung Galaxy S3. I've looked at the device
settings and have downloaded the matching kernel source code from Samsungs
opensource website, taking care to make sure the build versions string
matches. The phone has developer settings and usb debugging enabled. I have
also rooted the phone and the SuperSU binary is installed and configured to
grant root always without prompting.
I've tried using toolchain versions 4.9 and 4.8 but the Samsung source code
will not compile without modifications to the makefile relating to warnings
being interpreted as errors. I'm therefore using version 4.7.
I've compiled the kernel modules which generated a module.symvers:
***
0x82d9772c bcmsdh_remove drivers/net/wireless/bcmdhd/dhd
EXPORT_SYMBOL
0x9cad0f4b bcmsdh_probe drivers/net/wireless/bcmdhd/dhd
EXPORT_SYMBOL
***
I then compiled LiME with this make file...
***
obj-m := lime.o
lime-objs := tcp.o disk.o main.o
KDIR :=~/ANDROID/S3Kernel/Kernel
PWD := $(shell pwd)
CROSS_COMPILE :=
/home/dfir/ANDROID/android-ndk-r10e/toolchains/arm-linux-androideabi-4.7/bin/arm-linux-androideabi-
ARCH := arm
.PHONY: modules modules_install clean distclen help
default:
$(MAKE) ARCH=arm SUBARCH=arm -C $(KDIR) M=$(PWD)
CROSS_COMPILE=$(CROSS_COMPILE) EXTRA_CFLAGS=-fno-pic modules
mv lime.ko limeS3.ko
***
...and this generates the following output
***
dfir@ThinkPad-T420:~/ANDROID/S3Kernel/LiME/src$ make
make ARCH=arm SUBARCH=arm -C ~/ANDROID/S3Kernel/Kernel
M=/home/dfir/ANDROID/S3Kernel/LiME/src
CROSS_COMPILE=/home/dfir/ANDROID/android-ndk-r10e/toolchains/arm-linux-androideabi-4.7/bin/arm-linux-androideabi-
EXTRA_CFLAGS=-fno-pic modules
make[1]: Entering directory `/home/dfir/ANDROID/S3Kernel/Kernel'
CC [M] /home/dfir/ANDROID/S3Kernel/LiME/src/tcp.o
CC [M] /home/dfir/ANDROID/S3Kernel/LiME/src/disk.o
CC [M] /home/dfir/ANDROID/S3Kernel/LiME/src/main.o
LD [M] /home/dfir/ANDROID/S3Kernel/LiME/src/lime.o
Building modules, stage 2.
MODPOST 1 modules
CC /home/dfir/ANDROID/S3Kernel/LiME/src/lime.mod.o
LD [M] /home/dfir/ANDROID/S3Kernel/LiME/src/lime.ko
make[1]: Leaving directory `/home/dfir/ANDROID/S3Kernel/Kernel'
mv lime.ko limeS3.ko
***
After successfully compilation there is also a module.symvers file located
in LiME directory but it is empty. I wonder if this is indicative of my
problem?
I then move limeS3.ko to my phone and connect to it with adb
adb forward tcp:4444 tcp:4444
adb shell
su
this gets me to a root prompt on the device and I can move freely around
the file system.
I then move to the location where limeS3.ko is installed and enter the
command
root@m0:/storage/extSdCard # insmod ./limeS3.ko "path=tcp:4444
format=lime"
which gives the following error.
insmod: init_module './limeS3.ko' failed (Exec format error)
I've searched for this error and ensured the kernel version is correct.
Can anyone tell me what I'm doing wrong so I can get the driver loaded?
I realize that this was a long first post. Thank-you for taking the time to
read this far. I hope someone can point me in the right direction.
regards,
Rob
We are excited to announce that Volatility 2.5 and the results of the
2015 Volatility Plugin Contest are both now available.
Volatility 2.5 includes many new features including support for Windows
10, Mac OS X El Capitan, and Linux 4.2.3. There are also a number of new
plugins, features, and bug fixes.
On the contest side, we received some very strong submissions this year.
These included recovery of the fully update-to-date shim cache from
memory (no need to wait on a reboot), the Evole GUI, memory analysis of
VMotion VM transfers, and more.
Full information on the release and contest can be found at these links:
http://volatility-labs.blogspot.com/2015/11/plugx-memory-forensics-lifecycl…http://volatility-labs.blogspot.com/2015/10/results-from-2015-volatility-pl…http://www.volatilityfoundation.org/#!25/c1f29
Please let us know if you have any issues or questions and enjoy the new
memory forensics capabilities!
--
Thanks,
Andrew (@attrc)
Hi all,
I'm thinking I might have a fundamental misunderstanding here, so I'm
hoping someone can help me out.
I'm looking for remnants of a data structure in the memory of a specific
process.
Originally, the data would have been on a heap.
I notice that in '/volatility/plugins/overlays/windows/windows.py' there is
a function named:
search_process_memory
I thought this would do the trick, but examining the code I notice that it
searches each of the VADs.
Which leads me to my question: would data that was originally on a heap,
but is no longer needed by the process still be in the VAD? That is, should
I be able to find it using this method?
If not, "where" is the data now? And is there a way of searching wherever
that "where" is?
I hope that makes sense!
Bridgey
Hi all,
System is Win7SP1x86.
pagefile is OFF.
Consider this VAD node (from vadinfo):
VAD node @ 0x85e076d0 Start 0x76440000 End 0x764dffff Tag Vad
Flags: CommitCharge: 5, Protection: 7, VadType: 2
Protection: PAGE_EXECUTE_WRITECOPY
Vad Type: VadImageMap
ControlArea @853ab1e0 Segment 8f6eba98
NumberOfSectionReferences: 1 NumberOfPfnReferences: 120
NumberOfMappedViews: 32 NumberOfUserReferences: 33
Control Flags: Accessed: 1, File: 1, Image: 1
FileObject @853ab898, Name:
\Device\HarddiskVolume1\Windows\System32\advapi32.dll
First prototype PTE: 8f6ebac8 Last contiguous PTE: fffffffc
Flags2: Inherit: 1
My understanding is that this VAD node is tracking the pages from
0x76440000 through to 0x764dffff.
When I look at the output of memmap for this process and this range I see:
--SNIP--
0x76228000 0x1f04c000 0x1000 0x2c1000
0x76440000 0x20670000 0x1000 0x2c2000 <-- start
0x76441000 0x0b728000 0x1000 0x2c3000
0x76451000 0x233a8000 0x1000 0x2c4000
0x76454000 0x1f5ab000 0x1000 0x2c5000
0x76455000 0x2336c000 0x1000 0x2c6000
0x76456000 0x1f6ed000 0x1000 0x2c7000
0x76457000 0x1f6ae000 0x1000 0x2c8000
0x76458000 0x2346f000 0x1000 0x2c9000
0x76459000 0x1e48b000 0x1000 0x2ca000
0x7645a000 0x21fcc000 0x1000 0x2cb000
0x7645b000 0x223cd000 0x1000 0x2cc000
0x76460000 0x1e3d2000 0x1000 0x2cd000
0x76461000 0x1e103000 0x1000 0x2ce000
0x764af000 0x20636000 0x1000 0x2cf000
0x764b1000 0x23ef8000 0x1000 0x2d0000
0x764b3000 0x0bded000 0x1000 0x2d1000
0x764b7000 0x1f730000 0x1000 0x2d2000
0x764e0000 0x208e6000 0x1000 0x2d3000 <-- first byte after end
--SNIP--
The file itself, advapi32.dll, is 0xa0000 bytes (well, in memory).
dlllist shows:
Base Size LoadCount Path
---------- ---------- ---------- ----
0x76440000 0xa0000 0xffff C:\Windows\system32\ADVAPI32.dll
0x76440000 through to 0x764dffff is 0x9FFFF bytes long.
However, memmap is only showing 0x13000 bytes.
The 0x13000 isn't big enough to hold the 0xa0000 bytes of the file.
My question is, why isn't the whole range (0x76440000 through to
0x764dffff) shown in memmap?
Is it the case that the VAD node is responsible for the whole range, but
simply not all the pages in that range are in use which is why they're
missing from the memmap output?
Or is there something that I'm missing?
Any comments greatly appreciated!
Adam
Oh dear. I've just realised my mistake.
The memory address is of course the memory address on my system of the
object being returned.
Thank goodness I have a week off coming up...
Hi all,
I've come across a peculiarity that I'd really like someone to shed some
light on. Consider:
> python vol.py --profile Win7SP1x64 -f Windows7x64.vmem volshell
Volatility Foundation Volatility Framework 2.4
Current context: System @ 0xfffffa80018ae890, pid=4, ppid=0 DTB=0x187000
Welcome to volshell! Current memory image is:
file:///C:/Windows7x64.vmem
To get help, type 'hh()'
>>> for p in getprocs():
... my_proc = p
... break
...
>>> print my_proc.UniqueProcessId, my_proc.ImageFileName
4 System
>>> for i in range(10):
... my_proc.get_process_address_space()
...
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D76240>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D76470>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D762E8>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D76240>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D76470>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D762E8>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D76240>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D76470>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D762E8>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D76240>
There appears to be three different objects that are returned on a cycle.
Is this normal, expected behaviour? Why are there three?
Thank you!
