- Vol-users - volatilityfoundation.org

[Newbie] Searching for specific IP addresses in memory (Win2008 R2)

by tech＠nisteo.fr

Hello, I am starting to play with Volatility (2.5) and I am currently working on a Win2008R2 image (memory dump with winpmem). I would like to understand what is causing some network connections initiated by the "System" process. netscan shows those connections and I would like to be able to find references to the IP addresses in the memory dump. I have tried "yarascan -Y" plugin with the IP string, with the IP to integer value (converted to Hex) but no luck finding IPs that , however, I can see in the netscan result... Either I am wrong with the yarascan syntax or there is something I don't know regarding how Win2008 stores IP... Any hints ? Thanks, Laurent

8 years, 11 months

4
4
0 0

[PLUGIN] Invoking other plugins

by P1kachu

Hello again, I managed to get something that guess the OS of a memory dump. I was planning to call imageinfo from it in the case of a Windows dump or get_mac_profile in case of an OSX dump (will figure out Linux later). So my questions are: - Does this kind of feature fits into Volatility, or do you prefer that the plugins follow the Single Responsability Principle ? - If not, what is the cleanest way to call a plugin from another one ? Thank you ! -- Stanislas 'P1kachu' Lejay EPITA - LSE If you're sleeping, you're doing it wrong.

8 years, 11 months

2
1
0 0

[PLUGINS] Basic requirement for a plugin to be recognized

by P1kachu

Hello, I am having some trouble loading a simple plugin with the '--plugins=.' option. It seems to be loaded (there were some errors that were fixed thanks to volatility displaying them) but it doesn't appear in the --info list. If I try this option in one of the community folder, it works (the plugins appear). What is the basic requirement for a plugin to be recognized, and what could I miss ? I started mine based on one from the community folder (CsabaBarta/usnjrnl.py) Thank you, -- Stanislas 'P1kachu' Lejay EPITA - LSE If you're sleeping, you're doing it wrong.

8 years, 11 months

4
3
0 0

windows plugin - handles - what don't I know?

by Bridgey theGeek

Hi all, Doing some work with the windows plugin for VistaSP1x86. I have the following two fragments from the output: Window Handle: #20130 at 0xfe817078, Name: ClassAtom: 0xc052, Class: ConsoleProgmanHandle SuperClassAtom: 0xc018, SuperClass: Edit pti: 0xfde11e90, Tid: 3432 at 0x839714e0 ppi: 0xff54be50, Process: explorer.exe, Pid: 2528 Visible: Yes Left: 82, Top: 456, Bottom: 379, Right: 473 Style Flags: WS_CHILD,WS_OVERLAPPED,WS_VISIBLE ExStyle Flags: WS_EX_LTRREADING,WS_EX_RIGHTSCROLLBAR,WS_EX_LEFT Window procedure: 0x7520d0d4 Window Handle: #100bc at 0xfe807390, Name: ClassAtom: 0xc052, Class: ConsoleProgmanHandle SuperClassAtom: 0xc018, SuperClass: Edit pti: 0xfe44d660, Tid: 2552 at 0x837c8778 ppi: 0xff54be50, Process: explorer.exe, Pid: 2528 Visible: No Left: 11, Top: 542, Bottom: 229, Right: 559 Style Flags: WS_CHILD,WS_OVERLAPPED ExStyle Flags: WS_EX_CLIENTEDGE,WS_EX_LTRREADING,WS_EX_RIGHTSCROLLBAR,WS_EX_LEFT Window procedure: 0x751f01c6 Both are from the same instance of explorer.exe. Viewing windows.py, it shows that the "Window Handle" is simply the value of: wnd.head.h Now consider this from volshell: >>> o1 = obj.Object('tagWND', offset=0xfe817078, vm=proc().get_process_address_space()) >>> dd(o1.head.h, length=4) fe8172a0 00020130 This seems logical: head.h is a void pointer. If we follow the pointer we get the handle: 20130. If I do the same with the other one: >>> o2 = obj.Object('tagWND', offset=0xfe807390, vm=proc().get_process_address_space()) >>> dd(o2.head.h, length=4) 000100bc 00000000 In this example, the handle is the VALUE of head.h, that is, you shouldn't follow the pointer. Volatility seems to know this because it displays the handles as 100bc rather than 0. I searched the Volatility code to see if I could find how this is being done, but I couldn't. So, how?? What rule don't I know?? Thanks!

8 years, 11 months

2
4
0 0

Investigate around a memory area

by Massimo Canonico

Hi all, I'm quite sure that there is a "standard procedure" in order to investigate a specific area of the memory once you found something useful in a specific address, but my research on volatility doc does not help me much. Here the problem. I was able to find out with yarascan and -W option (Andrew and Michael, thanks again!), where the password of a specific app is stored (see after my signature for the complete yarascan output). From this output, I can see that the password is stored from address 0xb2f771f0. I would like to see: - what is stored before the password - if this memory area is related to a specific file In other words, I would like to investigate how the app stored the password hoping that the password is always store with some criteria. Of course, I have several memory dumps, with different passwords set. The yarascan outputs (that shows me only something *after *the password) do not help me. Thanks in advance for all your help, Massimo (Here is the yarascan output. The password set is "mypassword2016") Task: ject.otr.app.im pid 1691 rule r1 addr 0xb2f771f0 0xb2f771f0 6d 00 79 00 70 00 61 00 73 00 73 00 77 00 6f 00 m.y.p.a.s.s.w.o. 0xb2f77200 72 00 64 00 32 00 30 00 31 00 36 00 00 00 00 00 r.d.2.0.1.6..... 0xb2f77210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77220 00 00 00 00 43 04 00 00 f0 4a b5 b2 00 00 00 00 ....C....J...... 0xb2f77230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77260 08 ff f9 b2 00 00 00 00 00 00 00 00 78 df fa b2 ............x... 0xb2f77270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77280 38 47 ef b2 f0 e8 d8 b2 68 76 f7 b2 00 00 00 00 8G......hv...... 0xb2f77290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f772a0 00 00 00 00 00 ed f1 b2 68 9c f9 b2 00 00 00 00 ........h....... 0xb2f772b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f772c0 d8 e4 e2 b2 00 00 00 00 68 01 00 00 00 00 00 00 ........h....... 0xb2f772d0 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ................ 0xb2f772e0 ff ff ff ff ff ff ff ff a6 02 00 80 68 01 00 40 ............h..@

8 years, 11 months

4
4
0 0

Re: [Vol-users] Analyzing memory from a QEMU snapshot

by Thomas Hungenberg

On 04.05.2016 19:11, Torres, Geoff (Cyber Security) wrote: > Hmmm... What does 'lqs2mem -l <snapshot_memfile>' show? $ lqs2mem -l snapshot.img Invalid QEMU-savevm magic Unrecogized file format $ file snapshot.img snapshot.img: QEMU suspend to disk image > When I run the lqs2mem tool, I don't get an ELF image (i.e. 'file <raw_image>' returns 'data'). But the image runs through volatility just fine. I got the ELF file from running "dump-guest-memory" on the QEMU console after loading the snapshot. - Thomas

8 years, 11 months

2
1
0 0

Analyzing memory from a QEMU snapshot

by Thomas Hungenberg

Hi, I was provided a suspend-to-disk snapshot image along with a copy of the virtual harddisk file from a QEMU/KVM-based Linux server for analysis. Analysis of the harddisk is done. Now I'd like to dump running processes etc. from the server's memory image. I loaded the snapshot into QEMU and used the QEMU monitor to dump a memory image using the 'dump-guest-memory' command. So now I have this: memory.img: ELF 64-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style Then, I set up a fresh VM with Debian Linux in the same version the virtual server was running. Next, I installed the kernel image and related files extracted from the virtual harddisk on this new VM to get a Linux system running exactly the same kernel version. On this VM, I created a Volatility profile using the files provided in /tools/linux/. Unfortunately, Volatility crashes when running imageinfo on the dumped memory image file: ========================================================================= $ python vol.py imageinfo -f /path/to/memory.img Volatility Foundation Volatility Framework 2.5 INFO : volatility.debug : Determining profile based on KDBG search... Suggested Profile(s) : No suggestion (Instantiated with Server_x64) AS Layer1 : QemuCoreDumpElf (Unnamed AS) AS Layer2 : FileAddressSpace (/path/to/memory.img) PAE type : No PAE DTB : -0x1L Traceback (most recent call last): File "vol.py", line 192, in <module> main() File "vol.py", line 183, in main command.execute() File "/opt/tools/volatility-master/volatility/commands.py", line 145, in execute func(outfd, data) File "/opt/tools/volatility-master/volatility/plugins/imageinfo.py", line 45, in render_text for k, t, v in data: File "/opt/tools/volatility-master/volatility/plugins/imageinfo.py", line 103, in calculate kdbg = volmagic.KDBG.v() File "/opt/tools/volatility-master/volatility/obj.py", line 748, in __getattr__ return self.m(attr) File "/opt/tools/volatility-master/volatility/obj.py", line 730, in m raise AttributeError("Struct {0} has no member {1}".format(self.obj_name, attr)) AttributeError: Struct VOLATILITY_MAGIC has no member KDBG ========================================================================= When running other Volatility Plugins on the memory image with the created profile, it says "No suitable address space mapping found": ========================================================================= $ python vol.py linux_netstat -f /path/to/memory.img --profile=Server_x64 Volatility Foundation Volatility Framework 2.5 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 WindowsCrashDumpSpace64: No base Address Space HPAKAddressSpace: No base Address Space VirtualBoxCoreDumpElf64: No base Address Space VMWareMetaAddressSpace: No base Address Space QemuCoreDumpElf: No base Address Space [...] ========================================================================= Any suggestions? What am I missing? - Thomas

8 years, 11 months

6
12
0 0

Recover password from memory dump

by Massimo Canonico

Hi all, I'm new on volatility so sorry if this question does not fit the purpose of this mailing list. I was starting play with LiME (Linux Memory Extract)[1] and I was able to dump a memory image of an Android Emulator where ChatSecure[2] was running. ChatSecure asked a master password at the first run and this password is stored by using a library called CacheWord [3]. Here the question: in order to find out if ChatSecure stores this password in memory, how should I use volatility? A doc/tutorial link or any suggestion are more than welcome. Thanks, Massimo [1] https://github.com/504ensicsLabs/LiME [2] https://github.com/guardianproject/ChatSecureAndroid [3] https://github.com/guardianproject/cacheword

8 years, 11 months

3
4
0 0

trouble with .volatilityrc file

by James Kelly

1. I have a directory with a memory dump called memdum.bin 2. I run volatility image info against it and I get Air:ticket_number jamesk$ vol.py -f memdump.bin imageinfo Volatility Foundation Volatility Framework 2.5 INFO : volatility.debug : Determining profile based on KDBG search... Suggested Profile(s) : Win2003SP0x86, Win2003SP1x86, Win2003SP2x86 (Instantiated with Win2003SP0x86) AS Layer1 : IA32PagedMemory (Kernel AS) AS Layer2 : FileAddressSpace (/Users/jamesk/Desktop/jackcr-challenge/DC-USTXHOU/ticket_number/memdump.bin) PAE type : No PAE DTB : 0x39000L KDBG : 0x805583d0L Number of Processors : 1 Image Type (Service Pack) : 0 KPCR for CPU 0 : 0xffdff000L KUSER_SHARED_DATA : 0xffdf0000L Image date and time : 2012-11-27 02:01:57 UTC+0000 Image local date and time : 2012-11-26 20:01:57 -0600 3. I can run vol.py --profile=Win2003SP0x86 -f memdump.bin pslist and get process list just fine…but... In that same directory as the memdump.bin file I have a .volatilityrc file which contains [DEFAULT] PROFILE=Win2003SP2x86 LOCATION=file://memdump.bin <file:///memdump.bin> When I run vol.py pslist I get: No suitable address space mapping found Is my syntax incorrect somewhere? Jk

8 years, 11 months

2
1
0 0

[IMAGEINFO] Equivalent to imageinfo plugin on non-windows

by P1kachu

Hello, I was wondering if there was any plugin right now equivalent to 'imageinfo' but for Linux or Mac ? I was planning on give it a try if not, but didn't want to waste time if anybody had done it before. Thank you, -- Stanislas 'P1kachu' Lejay EPITA - LSE If you're sleeping, you're doing it wrong.

8 years, 11 months

3
3
0 0

Error extracting Truecrypt Master Keys

by Tony Balzanto

I am attempting to recover the Truecrypt Master Keys from a Win7SP1x64 memory image and getting the below errors. Using the Volatility 2.5 Windows stand-alone: C:\>vol2.5.exe -f Truecrypt_MountedContainer.bin --profile Win7SP1x64 truecryptmaster -T 7.1a Volatility Foundation Volatility Framework 2.5 Container: Hidden Volume: No Removable: No Read Only: No Disk Length: 0 (bytes) Host Length: 0 (bytes) Encryption Algorithm: - Mode: - Master Key Traceback (most recent call last): File "<string>", line 192, in <module> File "<string>", line 183, in main File "C:\Users\Jake\Documents\GitHub\volatility\build\pyinstaller\out00-PYZ.py z\volatility.commands", line 145, in execute File "C:\Users\Jake\Documents\GitHub\volatility\build\pyinstaller\out00-PYZ.py z\volatility.plugins.tcaudit", line 666, in render_text File "C:\Users\Jake\Documents\GitHub\volatility\build\pyinstaller\out00-PYZ.py z\volatility.utils", line 71, in Hexdump TypeError: object of type 'NoneType' has no len()

8 years, 12 months

2
1
0 0

Hibr2Bin Beta 1

by Matthieu Suiche

Hey guys, I'm back from the other side ! I started refreshing my tools to add Windows 8, 8.1 and 10 support. I'm looking for Beta Testers for Hibr2Bin: Here is the link: http://www.comae.io/ Thanks!

8 years, 12 months

3
2
0 0

How to access data normally exposed by plugin.calculate()?

by Bridgey theGeek

Hi all, I'm trying to access the data that's exposed by the messagehooks plugin, specifically: volatility.plugins.gui.messagehooks.MessageHooks().calculate() I want to be able to work with the window_stations and atom_tables that are yielded by the method. I tried making a new instance of the class and manually calling: mh = messagehooks.MessageHooks(atoms.Atoms, sessions.SessionsMixin) for x in mh.calculate(): print x However when run, I get an attribute error: File "plugin.py", line 81, in calculate() for x in mh.calculate(): File ".../messagehooks.py", line 68, in calculate in atoms.Atoms(self._config).calculate()) File ".../messagehooks.py", line 6, in <genexpr> atom_tables = dict((atom_table, winsta) File ".../atoms.py", line 153, in calculate for wndsta in windowstations.WndScan(self._config).calculate(): File ".../common.py", line 45, in __init__ config.add_option("VIRTUAL", short_option = "V", default = False, AttributeError: type object 'Atoms' has no attribute 'add_option' Is there a better/correct way of getting at the data normally yielded by a plugin's calculate method? Thank you, Adam

8 years, 12 months

2
2
0 0

Re: [Vol-users] Analyzing memory from a QEMU snapshot

by Thomas Hungenberg

On 04.05.2016 17:46, Torres, Geoff (Cyber Security) wrote: > When you say " Running lqs2mem on the original suspend to disk image does not work", do you mean that you're getting an error? Or that it's creating an image that doesn't work in volatility? > > I've ran lqs2mem literally on hundreds of QEMU images with no problems. > > Can you post the output of your run? > > If I recall correctly, Juerg had to pad a certain section of memory in order to get the structures to line up. It's possible that later versions of QEMU/KVM changed so that padding isn't necessary any more. Running lqs2mem on the original image returns "Invalid section type: 7" - Thomas

8 years, 12 months

1
0
0 0

segmentation fault

by Anna Giannakou

Hello, I am using volatility in order to do live introspection in a linux virtual machine (i m using libvmi and pyvmiaddresspace.py to access the vms memory). The problem that I am facing is that once i run a command for example linux_pslist I get a segmentation fault(core dumped) error with no further information about it. Some general information about the system: I have recompiled libvmi in order to work with the kvm-qemu patch and I have tried the process-list example for linux that is featured with libvmi and it works fine. I have also tried to manualy execute pyvmi.init("instance-name","partial") which is what pyvmiaddresspace.py is doing and this also works (along with all the pyvmi related commands like get_memsize(), get_vcpureg()). >From what I understand the problem should lie somewhere in volatility. Before the recompilation of libvmi everything was working fine (without the kvm patch). Any help would be greatly appreciated. Thanks Anna

9 years

1
0
0 0

Memory Forensics Training coming to NYC, Amsterdam, and Reston

by Andrew Case

Hello All, We are excited to announce that we now have public trainings scheduled in NYC, Amsterdam, and Reston, VA! This is your chance to learn memory forensics and malware analysis directly from the Volatility developers. These three locations sell out quickly so please contact us ASAP if you wish to attend: http://volatility-labs.blogspot.com/2016/04/windows-malware-and-memory-fore… -- Thanks, Andrew (@attrc)

9 years

1
0
0 0

Need a Redhat 7.1 profile

by Torres, Geoff (Cyber Security)

Hi, I usually roll my own profiles but I'm having a big problem getting one created for RedHat 7.1 (Linux version 3.10.0-229.el17.x86_64). I checked the github repository already and did a google search to no avail. Does anyone have one already created? Or can anyone help me figure out how to get around these compilation errors? include/linux/thread_info.h:24:4: error unknown type name 'u32' u32 __user *uaddr; ^ There are hundreds of them. As near as I've been able to determine, all the flags that would set it are 64 bit-centric so it never gets set. I have the full make output and the kernel RPMs if needed. Oh, and this is the first time I'm creating a profile using Volatility 2.5, but I'm getting the same errors on 2.4 where I've been successful in the past. Thanks, Geoff BTW - I'm a programmer by necessity, not profession. Feel free to point out the obvious.

9 years

2
2
0 0

OSDFCon CFP and Autopsy Module Competition

by Brian Carrier

It’s time to start getting ready for the 7th Annual OSDFCon by submitting your presentation idea, writing an Autopsy module, and saving the date on your calendar. OSDFCon is the 1-day event to attend each year to learn about the latest open source digital forensics and incident response tools with over 400 of your colleagues. THE ESSENTIALS Conference Date: October 26, 2016 Location: Herndon, VA CALL FOR PAPERS Each year, OSDFCon gives developers and users a platform to talk about the open source software they love. We want to hear your presentation and hands-on workshop ideas. Submissions are due by June 1. Past presentations have covered new software, new features in mature software, modules for plug-in frameworks, and use cases that integrate several pieces of software. A detailed list of topics and submission details can be found here: http://www.osdfcon.org/osdfcon-2016/2016-call-for-presentations/ AUTOPSY MODULE COMPETITION For the third year, Basis Technology is organizing an Autopsy module writing competition. The modules can be written in Python or Java and we have tutorials to help you get started. Learning to write Autopsy modules will make you more effecient because Autopsy takes care of providing access to files, user interface, and reporting. All you have to do is focus on some cool analytics. The winners will be chosen by the OSDFCon attendees and the top three will get cash prizes. If we get 12 or more submissions (the number that the Volatility project got last year), Basis Technology will double the prize amounts. Submissions are due by October 17 (6 months away!). Links to tutorials and submission details can be found here: http://www.osdfcon.org/osdfcon-2016/2016-module-development-contest/ ABOUT OSDFCON OSDFCon is the premier event focused exclusively on open source digital forensics tools, OSDFCon offers short talks over the course of a single day. These talks are packed with information and present a unique opportunity to learn about new (often free) tools and provide feedback directly to developers. Basis Technology is the organizing sponsor of the event and it is free for government employees to attend.

9 years

1
0
0 0

RE: Need a Redhat 7.1 profile

by Torres, Geoff (Cyber Security)

To answer my own question... My profile build system is Debian based. Even though I've successfully created Fedora and CentOS profiles on it, I needed to move to a Fedora system which had the proper definition files in its compiler environment. That got rid of all the 'u32' errors. But because the compiler was gcc 5.1, I needed to create a compiler-gcc5.h file in the include/Linux folder of the kernel files. I just linked to the gcc4 file and everything compiled fine. All the Linux Volatility commands appear to be working as expected. Geoff From: Torres, Geoff (Cyber Security) Sent: Thursday, April 07, 2016 11:37 AM To: 'vol-users(a)volatilityfoundation.org' <vol-users(a)volatilityfoundation.org> Subject: Need a Redhat 7.1 profile Hi, I usually roll my own profiles but I'm having a big problem getting one created for RedHat 7.1 (Linux version 3.10.0-229.el17.x86_64). I checked the github repository already and did a google search to no avail. Does anyone have one already created? Or can anyone help me figure out how to get around these compilation errors? include/linux/thread_info.h:24:4: error unknown type name 'u32' u32 __user *uaddr; ^ There are hundreds of them. As near as I've been able to determine, all the flags that would set it are 64 bit-centric so it never gets set. I have the full make output and the kernel RPMs if needed. Oh, and this is the first time I'm creating a profile using Volatility 2.5, but I'm getting the same errors on 2.4 where I've been successful in the past. Thanks, Geoff BTW - I'm a programmer by necessity, not profession. Feel free to point out the obvious.

9 years

1
0
0 0

Airbnb just donated $999 to the plugin contest!

by Andrew Case

We are very excited to announce that $999 in cash prizes was just added to the 2016 plugin contest thanks to Airbnb! The updated prize pools and full contest information can be found at the following link: http://volatility-labs.blogspot.com/2016/04/airbnb-donates-999-to-2016-vola… -- Thanks, Andrew (@attrc)

9 years

1
0
0 0

Something changed recently and now my Linux profiles don't work

by Jim Clausing

Gang, I've googled it and saw some other discussion of the dreaded ERROR : volatility.debug : Invalid profile <blah> selected error. I'm trying to figure out what changed recently so that profiles that used to work for me, no longer work. I just did a fresh Ubuntu 14.04.4 install and then installed volatility (and distorm3 via pip) from github and I'm getting the error above. Note, this is the current release version, though I also have the problem with the version from whatever repo SIFT uses. The profile actually came from SecondLook and worked just fine on a different Ubuntu system about 4 weeks ago, but today it fails (on the system where it used to run), so I decided to try on this virgin system and get the same error. I'm at a loss, since there are no other debugging messages to help me out with what might be the problem. I can provide the profile to anyone who needs it (and probably a memory image, too, but that needs to be a little more tightly controlled) if that would help. -- Jim Clausing GIAC GSE #26, CISSP GPG Fingerprint = A507 774A 39D6 A702 9F7C 8808 3D13 77B8 AACD 848D

9 years

2
6
0 0

Re: [Vol-users] Something changed recently and now my Linux profiles don't work

by Andrew Case

Ok, can you run: vol.py --info | grep Linux and see if the profile name shows up like you have it as --profile? Thanks, Andrew (@attrc) On 04/07/2016 02:26 PM, Jim Clausing wrote: > -dd doesn't give me anything more than that error. > > jac@ubuntu:~$ vol.py -dd --plugins=profiles > --profile=Linux3_13_0_79_generic__123_Ubuntu_SMP_Fri_Feb_19_14_27_58_UTC_2016_x86_64 > -m XUbuntu\ 64-bit-Snapshot3.vmem linux_pslist > Volatility Foundation Volatility Framework 2.5 > ERROR : volatility.debug : Invalid profile > Linux3_13_0_79_generic__123_Ubuntu_SMP_Fri_Feb_19_14_27_58_UTC_2016_x86_64 > selected > > -- > Jim Clausing > GIAC GSE #26, CISSP > GPG Fingerprint = A507 774A 39D6 A702 9F7C 8808 3D13 77B8 AACD 848D > > On or about Thu, 7 Apr 2016, Andrew Case pontificated thusly: > >> Hey, >> >> Can you run volatility with -dd set and send the output? If I can't >> figure out it from there I will take the memory sample and profile. Feel >> free to send debug output offline. >> >> Thanks, >> Andrew (@attrc) >> >> On 04/07/2016 12:27 PM, Jim Clausing wrote: >>> Gang, >>> I've googled it and saw some other discussion of the dreaded >>> >>> ERROR : volatility.debug : Invalid profile <blah> selected >>> >>> error. I'm trying to figure out what changed recently so that profiles >>> that used to work for me, no longer work. I just did a fresh Ubuntu >>> 14.04.4 install and then installed volatility (and distorm3 via pip) >>> from github and I'm getting the error above. Note, this is the current >>> release version, though I also have the problem with the version from >>> whatever repo SIFT uses. The profile actually came from SecondLook and >>> worked just fine on a different Ubuntu system about 4 weeks ago, but >>> today it fails (on the system where it used to run), so I decided to try >>> on this virgin system and get the same error. I'm at a loss, since >>> there are no other debugging messages to help me out with what might be >>> the problem. I can provide the profile to anyone who needs it (and >>> probably a memory image, too, but that needs to be a little more tightly >>> controlled) if that would help. >>> >>> -- >>> Jim Clausing >>> GIAC GSE #26, CISSP >>> GPG Fingerprint = A507 774A 39D6 A702 9F7C 8808 3D13 77B8 AACD 848D >>> _______________________________________________ >>> Vol-users mailing list >>> Vol-users(a)volatilityfoundation.org >>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users >>> >> >> >

9 years

1
0
0 0

The 2016 Volatility Plugin Contest is now live!

by Andrew Case

We are happy to announce that the 2016 Volatility Plugin Contest is now live: http://volatility-labs.blogspot.com/2016/04/the-2016-volatility-plugin-cont… This contest is modeled after the annual IDA Pro one, and its purpose is to encourage new research in the memory forensics field. Volatility is one of the most popular tools in digital forensics, incident response, and malware analysis, and by submitting to our contest your work will immediately gain visibility through all of these communities. Besides this recognition, we also award the top entries over $2,000 in cash prizes, swag (stickers, t-shirts, etc.), and blog entries on our Volatility Labs blog. This contest is a great opportunity to explore the open source Volatility Framework, add visibility to your career, and potentially develop a master's thesis or PhD project. -- Thanks, Andrew (@attrc)

9 years

1
0
0 0

list running process from a ram dump of MAC os x elcapitan

by Razeem Ahmad

Sir, I am doing my M.E in Cyber forensics and Information Security, currently doing my project work on MAC RAM dump analysis. I am using volafox-master for listing data from my dump collected from my lap. Can you please help me how we can find the list of running process. Currently i've found a symbol that volatility uses("_allproc") also ive found it from symutils file. But i don't know what to do with it. Thanks in advance, Razeem

9 years, 1 month

1
0
0 0

Linux profile

by Carlos Angeles

Hello, I am working on a homework assignment that involves IR on a Linux system. We were only given some of the log files and a memory dump. None of the profiles on Github work so I need to build a profile. Unfortunately, the memory dump comes from a very old version of RedHat. It's RedHat 7.2 (Enigma) not RHEL7. I found the Enigma ISOs, created a VM and downloaded the source, headers, libdwarf, dwarfdump, etc, installed but when I run make from the tools/linux folder, it doesn't create the module.ko file that dwarfdump uses. I ran the make manually and it finishes without any errors but no module.ko. Any ideas what I might be doing wrong? Thanks! Carlos

9 years, 1 month

2
2
0 0

Can't detect stealth LKM rootkit

by Smith Michael

Hi, I'm trying to detect LKM rootkit (https://github.com/ivyl/rootkit) which hides module and hooks fop. I use CentOS 6.5 (2.6.32-431.el6.x86_64), LiME 1.7.2 and latest Volatility git repo (52c9c40a273595ef0b088b75b396c3487cb1b27c) for both memory dump and analyse. Many plugin works fine, but it can't be detected by below plugin (same on Volatility 2.4). * linux_hidden_modules - nothing is detected $ python vol.py -f mem.img --profile=LinuxCentOS65x64 linux_hidden_modules Volatility Foundation Volatility Framework 2.5 Offset (V) Name ------------------ ---- * linux_check_fops - outputs error (no verbose output on --debug option) $ python vol.py -f mem.img --profile=LinuxCentOS65x64 linux_check_fops Volatility Foundation Volatility Framework 2.5 ERROR : volatility.debug : You must specify something to do (try -h) I would really appreciate any advice. Regards,

9 years, 1 month

3
2
0 0

Volatile registry keys

by Thomas Chopitea

Dear vol-users, I'm trying to get data from a volatile registry key using the regapi / rawreg classes in volatility. The key I'm looking for is under HKCU\Software\Classes\, and is called CLSID vol.py --plugins='/Users/tomchop/Infosec/Forensics-RE/volatility-plugins/volatility-autoruns' -f Windows\ 7\ x64-aa76b309.vmem --profile=Win7SP1x64 printkey -K "Software\\Classes\\CLSID" Volatility Foundation Volatility Framework 2.4 Legend: (S) = Stable (V) = Volatile The requested key could not be found in the hive(s) searched So I go up one level: vol.py --plugins='/Users/tomchop/Infosec/Forensics-RE/volatility-plugins/volatility-autoruns' -f Windows\ 7\ x64-aa76b309.vmem --profile=Win7SP1x64 printkey -K "Software\\Classes" Volatility Foundation Volatility Framework 2.4 Legend: (S) = Stable (V) = Volatile ---------------------------- Registry: \??\C:\Users\admin\ntuser.dat Key name: Classes (V) Last updated: 2015-04-11 18:04:18 UTC+0000 Subkeys: Values: REG_LINK SymbolicLinkValue : (V) \Registry \User\S-1-5-21-978483858-511166411-2750856381-1000_Classes ---------------------------- Registry: \SystemRoot\System32\Config\DEFAULT Key name: Classes (S) Last updated: 2009-07-14 04:48:57 UTC+0000 Subkeys: (S) Local Settings Values: How can I query this key and keep on drilling its subkeys ? Also, my plugin is making extensive use of rawreg because I try to get each individual NTUSER.dat hive, and I don't know which hive_name to pass on to regapi. Should I use the full hive name, as in self.hive_name(obj.Object("_CMHIVE", vm = addr_space, offset = hive_offset)), or is there a better way of doing it? Any help is greatly appreciated. Have a great day! -- Thomas Chopitea

9 years, 1 month

2
2
0 0

Having Trouble Running Vol

by Jason N.

Hello, I am not sure why I am having trouble running vol against a Win7 memory image: I ran the imageinfo plugin against the image and it suggests: Win2008R2SP0x64, Win7SP1x64, Win7SP0x64, Win2008R2SP1x64: But when I select Win7S1x64 profile for other plugins I get following error: Any suggestions on what I am missing? Thanks in advance.

9 years, 1 month

2
1
0 0

Announcing BSides New Orleans 2016!

by Andrew Case

We are very excited to announce that the lineup for BSidesNOLA 2016 is out! The day will start with a keynote presentation from Darren Van Booven. He is currently the CISO of Idaho National Laboratory and was previously the CISO of the US House of Representatives. It will then continue with three tracks of talks ranging from application security to memory forensics to malware analysis to law. Full information on the conference can be found at the following page: http://www.securitybsides.com/w/page/104051753/BSidesNOLA%202016 The cost to attend is $15, and you must register through the EventBrite link ( https://www.eventbrite.com/e/bsides-nola-2016-tickets-20569894107 ). Last year was our third year and we had 200 people attend. We are expecting even more this year. For those of you who attended last year, you know that beyond just great talks and networking, we also provide very good food and drinks. The close proximity to the French Quarter (5-10 minute walk) also means that after the conference there will be plenty of fun and interesting things to do for the rest of the night. We hope to see you there and if you have any questions please reply to this thread or email bsidesnola [@@] gmail.com. -- Thanks, Andrew (@attrc)

9 years, 2 months

1
0
0 0

Problems running standalone Windows version of Volatile

by Marian Kechlibar

Hello all, I am researching the behavior of the Galileo RCS, whose source codes leaked in July 2015. I am using volatility 2.5 on Windows 7 and the instructions given in the blog of Joe Greenwood on 4armed.com. I downloaded the standalone version for Windows and I run it from the command line, but it dies immediately complaining about a missing source file. volatility-2.5.standalone.exe --profile=Win7SP1x64 -f test.raw -v psxview Volatility Foundation Volatility Framework 2.5 ERROR : volatility.debug : The requested file doesn't exist The system is Windows 7 x64 with SP1, so the profile should be correct. Python 2.7 is installed in the system, but it should not be necessary for a standalone version anyway. Thank you in advance for help! Best regards Marian Kechlibar

9 years, 2 months

3
2
0 0

Memory forensics training coming to NYC!

by Andrew Case

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)

9 years, 2 months

1
0
0 0

The BSidesNOLA 2016 Call for Papers is open!

by Andrew Case

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%202015 http://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)

9 years, 3 months

1
0
0 0

RFI: Failed Memory Acquisitions

by AAron Walters

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

9 years, 4 months

1
0
0 0

Insmod lime.lo on stock Samsung Galaxy S3 results in Exec format error

by Rob Hunter

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

9 years, 4 months

2
1
0 0

Blog Post - Binary Zone Forensic Challenge #4

by Jared Greenhill

All, I recently wrote a blog post that outlines volatility usage related to an intrusion based scenario. The blog post can be found here: http://justanotherdfirblog.blogspot.com/2015/11/solving-binary-zone-forensi… The challenge can be found here: http://www.binary-zone.com/2015/09/16/digital-forensic-challenge-4/ Hopefully some of you will find it useful. Best, Jared

9 years, 4 months

1
0
0 0

Volatility 2.5 and the results of the Volatility Plugin Contest

by Andrew Case

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)

9 years, 5 months

1
0
0 0

Searching a Process's Memory

by Bridgey theGeek

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

9 years, 6 months

3
2
0 0

Why doesn't memmap tally with vadinfo?

by Bridgey theGeek

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

9 years, 6 months

2
1
0 0

Processes have more than one address space???

by Bridgey theGeek

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...

9 years, 6 months

1
0
0 0

Processes have more than one address space???

by Bridgey theGeek

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!

9 years, 6 months

1
0
0 0

Open Source Digital Forensics Conference & Upcoming Trainings

by Andrew Case

Hello All, I was writing a quick email to say that the entire Volatility team will be at OSDFC in a few weeks. MHL will be showing off some of our new capabilities, along with the results of the plugin contest, in the morning. After that, we will all be hanging around throughout the day. Please come say 'hi'! http://www.osdfcon.org/2015-event/2015-program/ Also, we have two public classes currently being offered for 2016. The first is in San Diego and the second is in Reston. Our classes have been selling out pretty consistently so contact us ASAP if you are interested in a seat: http://www.memoryanalysis.net/#!memory-forensics-training/c1q3n Hope to see many of you in a few weeks! -- Thanks, Andrew (@attrc)

9 years, 6 months

1
0
0 0

Shellcode use in memory - forensic challenge related

by Jared Greenhill

All, I've been messing around with this fun challenge as of late - http://www.binary-zone.com/2015/09/16/digital-forensic-challenge-4/ and have been struggling with question #5 (using memory forensics, can you identify the shellcode used?). My initial approach was starting with malfind and dumping malfind artifacts and reviewing. I also threw some shellcode based yara sigs together, but didn't have much luck there either. Anyways, any help or direction pointing is appreciated :) Best, -Jared

9 years, 7 months

1
0
0 0

Volatility 2015 Summer Updates

by Andrew Case

We put together a quick blog post of upcoming and recent conferences, research, analysis capabilities, and news related to Volatility. It has been a pretty crazy summer, and we thank you all for the continued support of the project! http://volatility-labs.blogspot.com/2015/08/volatility-updates-summer-2015.… If you will be at HTCIA next week, be sure to stop by the Volexity booth and say 'hi' to some of our team members. You will also get a chance to win a free spot to a future training! -- Thanks, Andrew (@attrc)

9 years, 8 months

1
0
0 0

Volatility at Black Hat!

by Andrew Case

The Volatility team will be participating in a number of events at Black Hat this year, and we hope to see many of you there. This includes a book signing, arsenal demo, and even a party! Full information can be found here: http://volatility-labs.blogspot.com/2015/07/volatility-at-black-hat-usa-dfr… Please let us know if you have any questions, and we look forward to seeing many of you in Vegas! -- Thanks, Andrew (@attrc)

9 years, 9 months

1
0
0 0

Integrating the libvmi with volatility problem

by Xianchun Guan

Hi guys, who can help me to solve Volatility issues for linux(the vm is windows,it's works).as follow is the operation and running results. volatility version:2.4 libvmi version:v0.12.0-rc2 *1. kvm vm:* *--download lime resource code* root@ubuntu-gxc:/opt# git clone https://github.com/504ensicsLabs/LiME.git root@ubuntu-gxc:/opt# cd LiME root@ubuntu-gxc:/opt/LiME# git tag v1.4 root@ubuntu-gxc:/opt/LiME# git checkout -b v1.4 Switched to a new branch 'v1.4' root@ubuntu-gxc:/opt/LiME# cd src/ root@ubuntu-gxc:/opt/LiME/src# make make -C /lib/modules/2.6.32-21-generic/build M=/opt/LiME/src modules make[1]: Entering directory `/usr/src/linux-headers-2.6.32-21-generic' CC [M] /opt/LiME/src/tcp.o CC [M] /opt/LiME/src/disk.o CC [M] /opt/LiME/src/main.o LD [M] /opt/LiME/src/lime.o Building modules, stage 2. MODPOST 1 modules CC /opt/LiME/src/lime.mod.o LD [M] /opt/LiME/src/lime.ko make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-21-generic' strip --strip-unneeded lime.ko mv lime.ko lime-2.6.32-21-generic.ko root@ubuntu-gxc:/opt/LiME/src# insmod lime-2.6.32-21-generic.ko "path=/opt/ubuntu.lime format=lime" root@ubuntu-gxc:/opt/LiME/src# ls -alh /opt/ubuntu.lime -r--r--r-- 1 root root 1.0G 2015-06-05 14:24 /opt/ubuntu.lime *--copy ubuntu.lime to kvm host* root@ubuntu-gxc:/opt/LiME/src# scp /opt/ubuntu.lime root(a)172.19.106.245: /mnt/sdb1/forensics/images/ *2. kvm Host:* *--Making the profile* root@ubuntu:/mnt/sdb1/git/volatility/volatility# zip volatility/plugins/overlays/linux/ubuntu1004.zip tools/linux/module.dwarf ../../../sysmaps/System.map-2.6.32-21-generic adding: tools/linux/module.dwarf (deflated 90%) adding: ../../../sysmaps/System.map-2.6.32-21-generic (deflated 74%) *--using the profile* root@ubuntu:/mnt/sdb1/git/volatility/volatility# python vol.py --info |grep Linux Volatility Foundation Volatility Framework 2.4 Linuxubuntu1004i386x86 - A Profile for Linux ubuntu1004i386 x86 Linuxubuntu1004x86 - A Profile for Linux ubuntu1004 x86 linux_banner - Prints the Linux banner information linux_yarascan - A shell in the Linux memory image --using the plugin root@ubuntu:/mnt/sdb1/git/volatility/volatility# python vol.py --debug -f /mnt/sdb1/forensics/images/ubuntu.lime --profile=Linuxubuntu1004x86 linux_pslist Volatility Foundation Volatility Framework 2.4 DEBUG : volatility.plugins.overlays.linux.linux: ubuntu1004: Found dwarf file ../../../sysmaps/System.map-2.6.32-21-generic with 658 symbols DEBUG : volatility.plugins.overlays.linux.linux: ubuntu1004: Found system file ../../../sysmaps/System.map-2.6.32-21-generic with 1 symbols DEBUG : volatility.obj : Applying modification from BashHashTypes DEBUG : volatility.obj : Applying modification from BashTypes DEBUG : volatility.obj : Applying modification from BasicObjectClasses DEBUG : volatility.obj : Applying modification from ELF32Modification DEBUG : volatility.obj : Applying modification from ELF64Modification DEBUG : volatility.obj : Applying modification from ELFModification DEBUG : volatility.obj : Applying modification from HPAKVTypes DEBUG : volatility.obj : Applying modification from LimeTypes DEBUG : volatility.obj : Applying modification from LinuxTruecryptModification DEBUG : volatility.obj : Applying modification from MachoModification DEBUG : volatility.obj : Applying modification from MachoTypes DEBUG : volatility.obj : Applying modification from MbrObjectTypes DEBUG : volatility.obj : Applying modification from VMwareVTypesModification DEBUG : volatility.obj : Applying modification from VirtualBoxModification DEBUG : volatility.obj : Applying modification from LinuxIntelOverlay DEBUG : volatility.obj : Applying modification from LinuxKmemCacheOverlay DEBUG : volatility.plugins.overlays.linux.linux: Requested symbol cache_chain not found in module kernel DEBUG : volatility.obj : Applying modification from LinuxMountOverlay DEBUG : volatility.obj : Applying modification from LinuxObjectClasses DEBUG : volatility.obj : Applying modification from LinuxOverlay DEBUG : volatility.plugins.overlays.linux.linux: ubuntu1004: Found dwarf file ../../../sysmaps/System.map-2.6.32-21-generic with 658 symbols DEBUG : volatility.plugins.overlays.linux.linux: ubuntu1004: Found system file ../../../sysmaps/System.map-2.6.32-21-generic with 1 symbols DEBUG : volatility.obj : Applying modification from BashHashTypes DEBUG : volatility.obj : Applying modification from BashTypes DEBUG : volatility.obj : Applying modification from BasicObjectClasses DEBUG : volatility.obj : Applying modification from ELF32Modification DEBUG : volatility.obj : Applying modification from ELF64Modification DEBUG : volatility.obj : Applying modification from ELFModification DEBUG : volatility.obj : Applying modification from HPAKVTypes DEBUG : volatility.obj : Applying modification from LimeTypes DEBUG : volatility.obj : Applying modification from LinuxTruecryptModification DEBUG : volatility.obj : Applying modification from MachoModification DEBUG : volatility.obj : Applying modification from MachoTypes DEBUG : volatility.obj : Applying modification from MbrObjectTypes DEBUG : volatility.obj : Applying modification from VMwareVTypesModification DEBUG : volatility.obj : Applying modification from VirtualBoxModification DEBUG : volatility.obj : Applying modification from LinuxIntelOverlay DEBUG : volatility.obj : Applying modification from LinuxKmemCacheOverlay DEBUG : volatility.plugins.overlays.linux.linux: Requested symbol cache_chain not found in module kernel DEBUG : volatility.obj : Applying modification from LinuxMountOverlay DEBUG : volatility.obj : Applying modification from LinuxObjectClasses DEBUG : volatility.obj : Applying modification from LinuxOverlay Offset Name Pid Uid Gid DTB Start Time ---------- -------------------- --------------- --------------- ------ ---------- ---------- DEBUG : volatility.utils : Voting round DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crashbmp.WindowsCrashDumpSpace64BitMap'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmem.VMWareMetaAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.VirtualBoxCoreDumpElf64'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.QemuCoreDumpElf'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmware.VMWareAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemory'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.pyvmiaddressspace.PyVmiAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.osxpmemelf.OSXPmemELF'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.standard.FileAddressSpace'> DEBUG : volatility.utils : Succeeded instantiating <volatility.plugins.addrspaces.standard.FileAddressSpace object at 0x7505790> DEBUG : volatility.utils : Voting round DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'> DEBUG : volatility.utils : Succeeded instantiating <volatility.plugins.addrspaces.lime.LimeAddressSpace object at 0x7505750> DEBUG : volatility.utils : Voting round DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crashbmp.WindowsCrashDumpSpace64BitMap'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmem.VMWareMetaAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.VirtualBoxCoreDumpElf64'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.QemuCoreDumpElf'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmware.VMWareAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemory'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.pyvmiaddressspace.PyVmiAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.osxpmemelf.OSXPmemELF'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.standard.FileAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.arm.ArmAddressSpace'> DEBUG : volatility.plugins.addrspaces.arm: get_pte: invalid pde_value e82c4c4c 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 WindowsCrashDumpSpace64: No base Address Space HPAKAddressSpace: No base Address Space VMWareMetaAddressSpace: No base Address Space VirtualBoxCoreDumpElf64: No base Address Space QemuCoreDumpElf: No base Address Space VMWareAddressSpace: 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:// OSXPmemELF: No base Address Space MachOAddressSpace: MachO Header signature invalid MachOAddressSpace: MachO Header signature invalid LimeAddressSpace: Invalid Lime header signature WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile WindowsCrashDumpSpace64BitMap: Header signature invalid WindowsCrashDumpSpace64: Header signature invalid HPAKAddressSpace: Invalid magic found VMWareMetaAddressSpace: VMware metadata file is not available VirtualBoxCoreDumpElf64: ELF Header signature invalid QemuCoreDumpElf: ELF Header signature invalid VMWareAddressSpace: Invalid VMware signature: 0xf000ff53 WindowsCrashDumpSpace32: Header signature invalid AMD64PagedMemory: Incompatible profile Linuxubuntu1004x86 selected IA32PagedMemoryPae: Failed valid Address Space check IA32PagedMemory: Failed valid Address Space check PyVmiAddressSpace: Must be first Address Space OSXPmemELF: ELF Header signature invalid FileAddressSpace: Must be first Address Space ArmAddressSpace: Failed valid Address Space check

9 years, 10 months

2
1
0 0

testing requested on CentOS 2.6.18.x kernels

by Andrew Case

Hello All, I was writing to request testing from anyone who may be running or have access to a CentOS installation running a 2.6.18 series kernel. Even though that series of kernels is ancient, CentOS/RH backports years of patches into that series (for unknown reasons...), and then uses the kernels in production systems. I think we finally figured out the quirks related to this OS & kernel version, so if you have a system please test it. If you find bugs please either email them to me or file a bug on the Volatility tracker (https://github.com/volatilityfoundation/volatility/issues) -- Thanks, Andrew (@attrc)

9 years, 10 months

1
0
0 0

The 2015 Volatility Plugin Contest is now live!

by Andrew Case

We are happy to announce that the 2015 Volatility Plugin Contest is now live: http://www.volatilityfoundation.org/#!2015/c1qp0 This contest is modeled after the annual IDA Pro one, and its purpose is to encourage new research in the memory forensics field. Volatility is one of the most popular tools in digital forensics, incident response, and malware analysis, and by submitting to our contest your work will immediately gain visibility through all of these communities. Besides this recognition, we also award the top entries over $2,000 in cash prizes, swag (stickers, t-shirts, etc.), blog entries on our Volatility Labs blog, and an invitation to speak at our memory forensics workshop. The entries of last year's winners can be found here: http://www.volatilityfoundation.org/#!2014/cjpn This contest is a great opportunity to explore the open source Volatility Framework, add visibility to your career, and potentially develop a master's thesis or PhD project. -- Thanks, Andrew (@attrc)

9 years, 10 months

1
0
0 0

Re: [Vol-users] Sample error or real module? (and other questions)

by Gregory Pendergast

Thanks gentlemen. No worries there. I didn't take it badly. Sorry for the oversight. Correcting the command gives me output, but leaves me with a new question. The string of interest seems nowhere to be found (maybe it's unicode? I'm not sure how to tell...): >>> db(0xf9805ba44800) 0xf9805ba44800 00 00 00 00 00 00 00 00 1b 00 01 00 28 00 00 00 ............(... 0xf9805ba44810 28 00 00 00 18 00 00 00 00 00 00 00 00 00 02 00 (............... 0xf9805ba44820 00 00 00 00 00 00 00 00 48 a4 83 08 a0 f8 ff ff ........H....... 0xf9805ba44830 06 09 65 f1 02 00 00 00 00 00 00 00 00 00 00 00 ..e............. 0xf9805ba44840 00 00 00 00 00 00 00 00 a8 00 00 00 00 00 00 00 ................ 0xf9805ba44850 01 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 ....@........... 0xf9805ba44860 07 00 07 00 28 00 40 00 68 00 40 00 18 00 01 00 ....(.@.h.@..... 0xf9805ba44870 38 00 20 00 04 00 02 00 0b 9e 00 00 00 00 00 00 8............... >>> db(0xf9805ba44800,length=0xFF) 0xf9805ba44800 00 00 00 00 00 00 00 00 1b 00 01 00 28 00 00 00 ............(... 0xf9805ba44810 28 00 00 00 18 00 00 00 00 00 00 00 00 00 02 00 (............... 0xf9805ba44820 00 00 00 00 00 00 00 00 48 a4 83 08 a0 f8 ff ff ........H....... 0xf9805ba44830 06 09 65 f1 02 00 00 00 00 00 00 00 00 00 00 00 ..e............. 0xf9805ba44840 00 00 00 00 00 00 00 00 a8 00 00 00 00 00 00 00 ................ 0xf9805ba44850 01 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 ....@........... 0xf9805ba44860 07 00 07 00 28 00 40 00 68 00 40 00 18 00 01 00 ....(.@.h.@..... 0xf9805ba44870 38 00 20 00 04 00 02 00 0b 9e 00 00 00 00 00 00 8............... 0xf9805ba44880 50 14 9e 00 00 00 00 00 03 ee e4 ad 6d 83 d0 01 P...........m... 0xf9805ba44890 03 ee e4 ad 6d 83 d0 01 18 24 3a 05 d4 82 d0 01 ....m....$:..... 0xf9805ba448a0 26 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 &............... 0xf9805ba448b0 00 00 00 00 90 05 00 00 00 00 00 00 00 00 00 00 ................ 0xf9805ba448c0 a0 3f 54 90 00 00 00 00 f2 c6 e4 ad 6d 83 d0 01 .?T.........m... 0xf9805ba448d0 f2 c6 e4 ad 6d 83 d0 01 18 24 3a 05 d4 82 d0 01 ....m....$:..... Here's the string I expect to see based on the strings output: 4397692928 [kernel:f9805ba44800] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. Thanks again for the help. Greg On Fri, May 15, 2015 at 11:30 AM, Michael Ligh <michael.ligh(a)mnin.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hey Greg....Andrew just (to my surprise) asked me why I was being > "rough" on you, so I apologize if that's how it came across...the goal > was just to point out the issue as fast as possible. > > MHL > > On 5/15/15 11:15 AM, Michael Ligh wrote: > > My command: > > > > db(0xf9805ba44800) > > > > Your command: > > > > db(f9805ba44800) > > > > The missing 0x in front makes Python think f9805ba44800 is a > > variable name rather than a number. > > > > On 5/15/15 11:05 AM, Gregory Pendergast wrote: > >> Thanks Michael. I did try that, and received an error. That's > >> why I thought I must be doing/forgetting something stupid. Now > >> that I'm back at my analysis machine, here's the output: > > > >>>>> db(f9805ba44800) > >> Traceback (most recent call last): File "<console>", line 1, in > >> <module> NameError: name 'f9805ba44800' is not defined > >>>>> addrspace() > >> <volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at > >> 0xbef520c> > >>>>> > >> Note that I'm using Volatilty through the VM provided for the > >> most recent class in Reston, in case the version is in question. > >> The profile for this sample is WIn7SP1x64. > > > >> Thanks, Greg > > > > > > > >> On Fri, May 15, 2015 at 10:49 AM, Michael Ligh > >> <michael.ligh(a)mnin.org <mailto:michael.ligh@mnin.org>> wrote: > > > >> You would just type db(0xf9805ba44800) in volshell (or whatever > >> other address you want to see). > > > >> https://github.com/volatilityfoundation/volatility/wiki/Command%20Ref > e > > > >> > re > > > > > > nce#volshell > >> <https://github.com/volatilityfoundation/volatility/wiki/Command%20Re > f > > > >> > erence#volshell> > > > >> I would also search an electronic copy of the AMF book for > >> "volshell" - there are lots of examples. > > > > > >> On 5/14/15 10:52 PM, Gregory Pendergast wrote: > >>> Thanks Michael. Regarding the latter part of inspecting the > >>> data around the strings, that's where I really need the help. I > >>> know I can accomplish that with volshell, but I'm not > >>> proficient enough yet to know how to get at it. > > > >>> If you could provide the necessary commands to get at the data > >>> around this hit [kernel:f9805ba44800] as an example, that > >>> would be most helpful. > > > >>> I'm sure I was doing something n00bishly wrong, but I could > >>> never get to the point of displaying the data around that > >>> location. I'd be more specific about my attempts, but I'm not > >>> in front of my analysis machine right now and don't recall > >>> exactly what I tried. > > > >>> thanks, greg > > > >>>> On May 14, 2015, at 9:39 PM, Michael Ligh > >>>> <michael.ligh(a)mnin.org > >> <mailto:michael.ligh@mnin.org>> > >>>> wrote: > >>>> > >>> I wouldn't think the module at 0x48706657040b0003 requires > >>> investigation. Not only bc its not in the 0xfffff8 range, but > >>> you might notice legitimate modules are typically loaded at > >>> page aligned base addresses (not XXX0003). Your result looks > >>> like a false positive and given the way modscan works (pool > >>> scanning) its probably a partially overwritten structure in > >>> free/deallocated memory. We *could* put a sanity check in the > >>> code to suppress entries that aren't loaded at page aligned > >>> addresses, but there are a few exceptions where you'll have > >>> modules loaded from non-page aligned addresses. For example, > >>> we just looked at a rootkit today in class that is loaded at > >>> 0x81b91b80 (on a 32-bit system). Jared's advice is also good - > >>> if you ever suspect something like this again, you can use > >>> volshell to display the data at the alleged base address and > >>> see what's there. If its not an MZ signature, then its probably > >>> not a currently loaded module (but keep in mind you can > >>> overwrite the MZ with 00 or anything else as a trick...but in > >>> that case you'll see real executable code not too far away). > > > >>> I would suggest trying to figure out what downloaded the EXE in > >>> the first place, so that you can determine what it does after > >>> the download finishes (drop to disk and run, drop to disk and > >>> run then delete, load directly into memory without touching > >>> disk, etc). I would also inspect the data around the strings > >>> you found in kernel and free memory - is it verbatim with what > >>> you see in the pcap (i.e. just a copy of the packet) or has it > >>> been altered (i.e. unpacked, executed, expanded). > > > >>>>>> On 5/14/15 4:31 PM, Gregory Pendergast wrote: Just as a > >>>>>> follow up to my last reply, the shimcache plugin reported > >>>>>> that there was no shimcache data, and the timeliner > >>>>>> plugin didn't reveal anything apparently interesting > >>>>>> except IE history related to the download. > >>>>>> > >>>>>> Thanks, Greg > >>>>>> > >>>>>> > >>>>>> On May 14, 2015, at 12:35 PM, Jared Greenhill > >>>>>> <jared703(a)gmail.com <mailto:jared703@gmail.com> > >> <mailto:jared703@gmail.com <mailto:jared703@gmail.com>>> wrote: > >>>>>> > >>>>>>> Hey Greg, > >>>>>>> > >>>>>>> A couple thoughts/ideas: > >>>>>>> > >>>>>>> What was the initial reason for investigation- the > >>>>>>> suspect EXE? Do you have a timeframe of the suspect > >>>>>>> activity? > >>>>>>> > >>>>>>> What was the context around the suspect EXE download, > >>>>>>> just the PCAP or? If so, did the memory capture occur > >>>>>>> when there was still an active connection? Sometimes > >>>>>>> this can be a dealbreaker when the connection isn't > >>>>>>> there. > >>>>>>> > >>>>>>> Does moddump work on the module with that base > >>>>>>> address? If so, what type of strings are you seeing? > >>>>>>> > >>>>>>> As far as execution goes, does the shimcache plugin > >>>>>>> provide any results around the time of interest? > >>>>>>> Assuming you have a time of interest, you could also > >>>>>>> try the timeliner plugin to pull in other temporal > >>>>>>> artifacts to hone in around that suspect time. > >>>>>>> > >>>>>>> hope this helps, Jared - @jared703 > >>>>>>> > >>>>>>> > >>>>>>> On Tue, May 12, 2015 at 3:36 PM, Gregory Pendergast > >>>>>>> <greg.pendergast(a)gmail.com > >>>>>>> <mailto:greg.pendergast@gmail.com> > >>>>>>> <mailto:greg.pendergast@gmail.com > >> <mailto:greg.pendergast@gmail.com>>> wrote: > >>>>>>> > >>>>>>> Greeting, > >>>>>>> > >>>>>>> I'm examining a memory sample (captured locally with > >>>>>>> winpmem_1.6.2) <yeah...i know...> > >>>>>>> > >>>>>>> Modscan shows one apparently strange module that has no > >>>>>>> name and no file listed. The base address space also > >>>>>>> seems way out of whack for the rest of the sample. > >>>>>>> > >>>>>>> So all i have are offset, base, and size: > >>>>>>> 0x000000023a80b540 0x48706657040b0003 0xf3a54f0 > >>>>>>> > >>>>>>> In particular, that base address seems way out of range > >>>>>>> compared to everything else in 0xfffff8.... space > >>>>>>> > >>>>>>> How can I tell if this is an error of some kind in the > >>>>>>> captured sample versus a legitimate anomaly that bears > >>>>>>> investigation? > >>>>>>> > >>>>>>> > >>>>>>> Lastly, and pardon me if this is a n00b question, but > >>>>>>> how can I determine why specific strings appear in > >>>>>>> kernel memory (based on strings plugin output)? For > >>>>>>> context, I have a suspicious executable download, but > >>>>>>> there appears to be no evidence of the file in $MFT (I > >>>>>>> don't have access to UsnJrnl) and I'm trying to find > >>>>>>> out what happened to it and whether it ran. Strings > >>>>>>> from the executable (ontained from pcap) do appear in > >>>>>>> Free Memory and Kernel memory, but I'm not clear > >>>>>>> whether that's a symptom of the download or a sign of > >>>>>>> execution. > >>>>>>> > >>>>>>> Thanks, greg > >>>>>>> > >>>>>>> > >>>>>>>>> On May 11, 2015, at 11:30 AM, Torres, Geoff (Cyber > >>>>>>>>> Security) > >>>>>>>> <geoff.torres(a)hp.com <mailto:geoff.torres@hp.com> > >> <mailto:geoff.torres@hp.com <mailto:geoff.torres@hp.com>>> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>> Thanks Michael, > >>>>>>>> > >>>>>>>> I confirm that I now see what I was expecting. > >>>>>>>> Sorry for the > >>>>>>> rookie mistake. > >>>>>>>> > >>>>>>>> I *really* need to get to your class... > >>>>>>>> > >>>>>>>> Geoff > >>>>>>>> > >>>>>>>>> Don't be afraid to tell me I'm doing something > >>>>>>>>> stupid... :-) > >>>>>>>> > >>>>>>>> I only said that because I didn't think I was... > >>>>>>>> :-P > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -----Original Message----- From: > >>>>>>>> vol-users-bounces(a)volatilityfoundation.org > >> <mailto:vol-users-bounces@volatilityfoundation.org> > >>>>>>> <mailto:vol-users-bounces@volatilityfoundation.org > >> <mailto:vol-users-bounces@volatilityfoundation.org>> > >>>>>>> [mailto:vol-users-bounces@volatilityfoundation.org > >> <mailto:vol-users-bounces@volatilityfoundation.org> > >>>>>>> <mailto:vol-users-bounces@volatilityfoundation.org > >> <mailto:vol-users-bounces@volatilityfoundation.org>>] On Behalf > >>>>>>> Of Michael Ligh > >>>>>>>> Sent: Saturday, May 09, 2015 9:00 AM To: > >>>>>>>> vol-users(a)volatilityfoundation.org > >> <mailto:vol-users@volatilityfoundation.org> > >>>>>>> <mailto:vol-users@volatilityfoundation.org > >> <mailto:vol-users@volatilityfoundation.org>> > >>>>>>>> Subject: Re: [Vol-users] Output of strings not found > >>>>>>>> in memdump > >>>>>>> output - QEMU/QEVM sample > >>>>>> Hi Geoff, > >>>>>> > >>>>>> The key to get strings working is to make sure you have a > >>>>>> raw > >>>>>>>> memory dump. lqs2mem *should* give you that, however > >>>>>>>> I've not personally used it before. > >>>>>> > >>>>>> One discrepancy I see with your logic is regarding this > >>>>>> line: > >>>>>> > >>>>>> memory_dump.ram.vol.strings:183190042 [3156:0189321a] > >>>>>>>> <Search_String> > >>>>>> > >>>>>> It tells you the search string is at virtual address > >>>>>> 0189321a in > >>>>>>>> pid 3156. You then dumped the *executable* for pid > >>>>>>>> 3156 which gives you memory from the base of the exe > >>>>>>>> 400000 to its base + size (nowhere near 0189321a). > >>>>>> > >>>>>> Try using the memdump or vaddump plugins on 3156 instead. > >>>>>> That > >>>>>>>> will give you ALL of the process's addressable > >>>>>>>> memory, not just the range that contains the exe. > >>>>>> > >>>>>> MHL > >>>>>> > >>>>>>>>>> On 5/7/15 3:03 PM, Torres, Geoff (Cyber Security) > >>>>>>>>>> wrote: Hi, > >>>>>>>>>> > >>>>>>>>>> Sorry for the 'me too' response, but I'm having > >>>>>>>>>> this exact same problem. However, the main > >>>>>>>>>> difference is that I'm using a 'QEMU' memory > >>>>>>>>>> image (Hex dump sig is QEVM in the first 4 bytes) > >>>>>>>>>> from a > >>>>>>>> cloud > >>>>>>>>>> instance. > >>>>>>>>>> > >>>>>>>>>> I've converted these in the past using the > >>>>>>>>>> 'lqs2mem' tool > >>>>>>>> written by > >>>>>>>>>> Juerg Haefliger and Andrew Tappert and it's > >>>>>>>>>> worked perfectly > >>>>>>>> for the > >>>>>>>>>> 'netscan' and 'ps' type plugins. However, I > >>>>>>>>>> haven't needed to dump processes before and look > >>>>>>>>>> for specific strings. I can locate the strings > >>>>>>>>>> in the converted image, but it's not translating > >>>>>>>>>> to the processes that are identified by the > >>>>>>>>>> 'strings' plugin. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Here's the steps I've been taking - > >>>>>>>>>> > >>>>>>>>>> ## Memory dump info > >>>>>>>>>>> ll memory_dump > >>>>>>>>>> -rw------- 1 geoff citsirt 7579914273 Apr 27 > >>>>>>>>>> 13:36 memory_dump > >>>>>>>>>> > >>>>>>>>>>> file memory_dump > >>>>>>>>>> memory_dump: QEMU suspend to disk image > >>>>>>>>>> > >>>>>>>>>>> xxd memory_dump | head -n1 > >>>>>>>>>> 0000000: 5145 564d 0000 0003 0100 0000 0105 626c > >>>>>>>>>> QEVM..........bl > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ## Convert the dump > >>>>>>>>>>> lqs2mem -w pc.ram memory_dump memory_dump.ram > >>>>>>>>>> section = pc.ram size = > >>>>>>>>>> 8192 [MB] 8589934592 [bytes] section = pc.bios > >>>>>>>>>> size = 128 [KB] 131072 [bytes] section = > >>>>>>>>>> pc.rom size = 128 [KB] 131072 [bytes] > >>>>>>>>>> section = vga.vram size = 16 [MB] 16777216 > >>>>>>>>>> [bytes] section = 0000:00:02.0/cirrus_vga.rom > >>>>>>>>>> size = 64 [KB] 65536 [bytes] Wrote 8589934592 > >>>>>>>>>> bytes from section 'pc.ram' to file > >>>>>>>>>> memory_dump.ram > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ## Create the strings file > >>>>>>>>>>> strings -a -t d memory_dump.ram > > >>>>>>>>>>> memory_dump.ram.strings > >>>>>>>>>> > >>>>>>>>>>> strings -a -t d -el memory_dump.ram >> > >>>>>>>>>>> memory_dump.ram.strings > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ## Create the volatility strings file > >>>>>>>>>>> python > >>>>>>>>>>> /data/download/apps/forensic_tools/volatility/vol.py > >>>>>>>>>>> > >>>>>>>>>>> > > > >>>>>>>>>>> > - -f memory_dump.ram --profile=Win2008SP2x64 strings > >>>>>>>>>>> -s --output-file=memory_dump.ram.vol.strings > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> ll memory_dump.ram.strings > >>>>>>>>>>> memory_dump.ram.vol.strings > >>>>>>>>>> -rw-rw-r-- 1 geoff citsirt 2914258187 May 7 > >>>>>>>>>> 08:58 memory_dump.ram.strings -rw-rw-r-- 1 geoff > >>>>>>>>>> citsirt 4292775089 May 7 12:17 > >>>>>>>>>> memory_dump.ram.vol.strings > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ## '<Search_String>' is found in both string > >>>>>>>>>> files as expected > >>>>>>>>>>> fgrep <Search_String> memory_dump.ram.strings > >>>>>>>>>>> memory_dump.ram.vol.strings > >>>>>>>>>> memory_dump.ram.strings:183190042 <Search_String> > >>>>>>>>>> memory_dump.ram.vol.strings:183190042 > >>>>>>>>>> [3156:0189321a] > >>>>>>>> <Search_String> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ## Dump process 3156 as identified by volatility > >>>>>>>>>>> python > >>>>>>>>>>> /data/download/apps/forensic_tools/volatility/vol.py > >>>>>>>>>>> > >>>>>>>>>>> > > > >>>>>>>>>>> > - -f memory_dump.ram --profile=Win2008SP2x64 procdump > >>>>>>>>>>> -p 3156 -D processes -m > >>>>>>>>>> Volatility Foundation Volatility Framework 2.4 > >>>>>>>>>> Process(V) ImageBase Name Result > >>>>>>>>>> ------------------ ------------------ > >>>>>>>>>> -------------------- ------ 0xfffffa800a4e6370 > >>>>>>>>>> 0x0000000000400000 iwproxy.exe OK: > >>>>>>>>>> executable.3156.exe > >>>>>>>>>> > >>>>>>>>>>> ll processes/executable.3156.exe > >>>>>>>>>> -rw-rw-r-- 1 geoff citsirt 3248128 May 7 12:35 > >>>>>>>>>> processes/executable.3156.exe > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ## '<Search_String>' not found in the dumped > >>>>>>>>>> executable > >>>>>>>>>>> strings -a processes/executable.3156.exe | > >>>>>>>>>>> fgrep <Search_String> strings -a -el > >>>>>>>>>>> processes/executable.3156.exe | fgrep > >>>>>>>>>>> <Search_String> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I've tried many different variations of the above > >>>>>>>>>> steps and all have the same results. > >>>>>>>>>> > >>>>>>>>>> According to what I've read in this thread is > >>>>>>>>>> that the issue is to make sure the original dump > >>>>>>>>>> is properly converted. How can I do that? > >>>>>>>>>> 'lqs2mem' has limited options. > >>>>>>>>>> > >>>>>>>>>> Any ideas on what I can do differently to get > >>>>>>>>>> this to work? > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> > >>>>>>>>>> Geoff > >>>>>>>>>> > >>>>>>>>>> Don't be afraid to tell me I'm doing something > >>>>>>>>>> stupid... :-) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -----Original Message----- From: > >>>>>>>>>> vol-users-bounces(a)volatilityfoundation.org > >> <mailto:vol-users-bounces@volatilityfoundation.org> > >>>>>>>> <mailto:vol-users-bounces@volatilityfoundation.org > >> <mailto:vol-users-bounces@volatilityfoundation.org>> > >>>>>>>>>> [mailto:vol-users-bounces@volatilityfoundation.org > >> <mailto:vol-users-bounces@volatilityfoundation.org> > >>>>>>>> <mailto:vol-users-bounces@volatilityfoundation.org > >> <mailto:vol-users-bounces@volatilityfoundation.org>>] On Behalf > >>>>>>>> Of Michael > >>>>>>>>>> Ligh Sent: Tuesday, March 24, 2015 6:49 AM To: > >>>>>>>>>> Bridgey theGeek Cc: > >>>>>>>>>> vol-users(a)volatilityfoundation.org > >> <mailto:vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:vol-users@volatilityfoundation.org > >> <mailto:vol-users@volatilityfoundation.org>> Subject: Re: > >>>>>>>> [Vol-users] Output of > >>>>>>>>>> strings not found in memdump output > >>>>>>>>>> > >>>>>>>>>> Perfect! Glad to hear all is good in the world > >>>>>>>>>> ;-) > >>>>>>>>>> > >>>>>>>>>> MHL > >>>>>>>>>> > >>>>>>>>>>> On 3/24/15 5:05 AM, Bridgey theGeek wrote: > >>>>>>>>>>> Awesome, thanks Michael. > >>>>>>>>>> > >>>>>>>>>>> I generated a raw dump as follows, with the > >>>>>>>>>>> vmsn and vmem files in the same folder: $ > >>>>>>>>>>> python vol.py -f winxp.vmem > >>>>>>>>>>> --profile=WinXPSP2x86 imagecopy -O winxp.raw > >>>>>>>>>> > >>>>>>>>>>> Then ran strings again (having generated a new > >>>>>>>>>>> input text file because of course the offsets > >>>>>>>>>>> will be different): $ python vol.py -f > >>>>>>>>>>> winxp.raw --profile=WinXPSP2x86 strings -s > >>>>>>>>>>> pk.txt > >>>>>>>>>> > >>>>>>>>>>> I was then able to find the banner at the > >>>>>>>>>>> offsets reported by strings. And all was good > >>>>>>>>>>> in the world. > >>>>>>>>>> > >>>>>>>>>>> Thank you very much for the support. > >>>>>>>>>> > >>>>>>>>>>> Adam > >>>>>>>>>> > >>>>>>>>>>> On 23 March 2015 at 19:39, Michael Ligh > >>>>>>>>>>> <michael.ligh(a)mnin.org > >>>>>>>>>>> <mailto:michael.ligh@mnin.org> > >>>>>>>> <mailto:michael.ligh@mnin.org > >>>>>>>> <mailto:michael.ligh@mnin.org>> > >>>>>>>>>>> <mailto:michael.ligh@mnin.org > >>>>>>>>>>> <mailto:michael.ligh@mnin.org> > >>>>>>>>>>> <mailto:michael.ligh@mnin.org > >> <mailto:michael.ligh@mnin.org>>>> > >>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Hey Adam, > >>>>>>>>>> > >>>>>>>>>>> A few things: > >>>>>>>>>> > >>>>>>>>>>> * Yes, vmss2core creates a windows crash dump > >>>>>>>>>>> * You can use volatility on the original > >>>>>>>>>>> vmem/vmss by doing the following: > >>>>>>>>>> > >>>>>>>>>>> * make sure both vmem and vmss files are in the > >>>>>>>>>>> same dir * make sure they have the same base > >>>>>>>>>>> name (i.e. test.vmem and test.vmss) * run your > >>>>>>>>>>> volatility plugins against the vmem > >>>>>>>>>> > >>>>>>>>>>> In this case, it would also be required to > >>>>>>>>>>> generate a raw memory dump before running > >>>>>>>>>>> strings. So you would use imagecopy on the > >>>>>>>>>>> vmem. > >>>>>>>>>> > >>>>>>>>>>> LMK if that helps! Michael > >>>>>>>>>> > >>>>>>>>>>>> On 3/23/15 10:51 AM, Bridgey theGeek wrote: > >>>>>>>>>>>> Hi Michael, > >>>>>>>>>> > >>>>>>>>>>>> *sigh* When will I learn to check the origin > >>>>>>>>>>>> of my samples?! > >>>>>>>>>> > >>>>>>>>>>>> The guy who provided me with the sample > >>>>>>>>>>>> tells me that he took a snapshot of a VMWare > >>>>>>>>>>>> machine and then used vss2core to convert it. > >>>>>>>>>>>> I BELIEVE that makes it into a Windows Memory > >>>>>>>>>>>> Core Dump..? > >>>>>>>>>> > >>>>>>>>>>>> I got hold of the original vmem and vmsn > >>>>>>>>>>>> files. Trying to use imagecopy on the vmsn > >>>>>>>>>>>> just replicated the input file. I think the > >>>>>>>>>>>> header is not what Volatility would expect: > >>>>>>>>>>>> $ xxd Windows\ XP\ Pro\ SP2\ > >>>>>>>>>>>> $32-bit$-Snapshot49.vmsn |head 0000000: > >>>>>>>>>>>> d2be d2be 0800 0000 6300 0000 4368 6563 > >>>>>>>>>>>> ........c...Chec 0000010: 6b70 6f69 6e74 0000 > >>>>>>>>>>>> 0000 0000 0000 0000 kpoint.......... > >>>>>>>>>>>> 0000020: 0000 0000 0000 0000 0000 0000 0000 > >>>>>>>>>>>> 0000 ................ 0000030: 0000 0000 0000 > >>>>>>>>>>>> 0000 0000 0000 0000 0000 ................ > >>>>>>>>>>>> 0000040: 0000 0000 0000 0000 0000 0000 fc1e > >>>>>>>>>>>> 0000 ................ 0000050: 0000 0000 ab03 > >>>>>>>>>>>> 0000 0000 0000 4775 6573 ............Gues > >>>>>>>>>>>> 0000060: 7456 6172 7300 0000 0000 0000 0000 > >>>>>>>>>>>> 0000 tVars........... 0000070: 0000 0000 0000 > >>>>>>>>>>>> 0000 0000 0000 0000 0000 ................ > >>>>>>>>>>>> 0000080: 0000 0000 0000 0000 0000 0000 0000 > >>>>>>>>>>>> 0000 ................ 0000090: 0000 0000 0000 > >>>>>>>>>>>> 0000 0000 0000 a722 0000 .............".. > >>>>>>>>>> > >>>>>>>>>>>> Does that mean I can't use this with > >>>>>>>>>>>> Volatility? > >>>>>>>>>> > >>>>>>>>>>>> Thank you, Adam > >>>>>>>>>> > >>>>>>>>>>>> On 23 March 2015 at 14:57, Michael Ligh > >>>>>>>> <michael.ligh(a)mnin.org > >>>>>>>> <mailto:michael.ligh@mnin.org> > >> <mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>> > >>>>>>>>>>>> <mailto:michael.ligh@mnin.org > >>>>>>>>>>>> <mailto:michael.ligh@mnin.org> > >>>>>>>>>>>> <mailto:michael.ligh@mnin.org > >> <mailto:michael.ligh@mnin.org>>> > >>>>>>>> <mailto:michael.ligh@mnin.org > >>>>>>>> <mailto:michael.ligh@mnin.org> > >>>>>>>> <mailto:michael.ligh@mnin.org > >>>>>>>> <mailto:michael.ligh@mnin.org>> > >>>>>>>>>>>> <mailto:michael.ligh@mnin.org > >>>>>>>>>>>> <mailto:michael.ligh@mnin.org> > >>>>>>>> <mailto:michael.ligh@mnin.org > >> <mailto:michael.ligh@mnin.org>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>>> Hey Adam, > >>>>>>>>>> > >>>>>>>>>>>> We forgot to ask if the sample was a raw > >>>>>>>>>>>> memory dump. For example: > >>>>>>>>>> > >>>>>>>>>>>> $ xxd ~/Desktop/memory.dmp | less > >>>>>>>>>> > >>>>>>>>>>>> 0000000: 5041 4745 4455 4d50 0f00 0000 280a > >>>>>>>>>>>> 0000 PAGEDUMP....(... 0000010: 8001 6c07 > >>>>>>>>>>>> 00c0 e680 a031 5580 5892 5580 > >>>>>>>>>>>> ..l......1U.X.U. 0000020: 4c01 0000 0100 0000 > >>>>>>>>>>>> 8000 0000 5444 4f00 L...........TDO. 0000030: > >>>>>>>>>>>> 0000 0000 0000 0000 0000 0000 5041 4745 > >>>>>>>>>>>> ............PAGE 0000040: 5041 4745 5041 4745 > >>>>>>>>>>>> 5041 4745 5041 4745 PAGEPAGEPAGEPAGE > >>>>>>>>>> > >>>>>>>>>>>> If its something like a crash dump, > >>>>>>>>>>>> hibernation, etc then the file format > >>>>>>>>>>>> headers throw off the offsets. You can > >>>>>>>>>>>> convert those special file types into a raw > >>>>>>>>>>>> memory dump with the imagecopy plugin and > >>>>>>>>>>>> then your strings translations should be > >>>>>>>>>>>> accurate. > >>>>>>>>>> > >>>>>>>>>>>> Cheers! MHL > >>>>>>>>>> > >>>>>>>>>>>>> On 3/23/15 8:54 AM, Bridgey theGeek wrote: > >>>>>>>>>>>>> Hi Andrew, > >>>>>>>>>> > >>>>>>>>>>>>> I was certain I was running the latest > >>>>>>>>>>>>> version, but just to be sure I grabbed the > >>>>>>>>>>>>> latest version. Same result, same offsets. > >>>>>>>>>> > >>>>>>>>>>>>> I can make the sample available, but more > >>>>>>>>>>>>> than happy to do whatever debugging needs > >>>>>>>>>>>>> doing (if I can!) > >>>>>>>>>> > >>>>>>>>>>>>> Adam > >>>>>>>>>> > >>>>>>>>>>>>> On 23 March 2015 at 13:03, Andrew Case > >>>>>>>>>>>>> <atcuno(a)gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> > >>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com>>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> > >>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com>>>> > >>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>> <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>> > >>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>>>> > >>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>>>> Are you using the latest git checkout of > >>>>>>>>>>>>> Volatility or the 2.4 release? Can you try > >>>>>>>>>>>>> the latest checkout and re-run Volatility > >>>>>>>>>>>>> strings (you can run it on just the > >>>>>>>>>>>>> offsets from PID 123 to make it faster). > >>>>>>>>>> > >>>>>>>>>>>>> If you are already on the latest checkout > >>>>>>>>>>>>> then we will need to debug further. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>> Thanks, Andrew (@attrc) > >>>>>>>>>> > >>>>>>>>>>>>>> On 03/23/2015 04:38 AM, Bridgey theGeek > >>>>>>>>>>>>>> wrote: Thanks Andrew: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> python vol.py --profile=WinXPSP2x86 -f > >>>>>>>>>>>>>> memory.dmp volshell -p 123 Volatility > >>>>>>>>>>>>>> Foundation Volatility Framework 2.4 > >>>>>>>>>>>>>> Current context: myapp.exe @ 0x822042f8, > >>>>>>>>>>>>>> pid=123, ppid=392 > >>>>>>>>>>>>> DTB=0x76c0040 > >>>>>>>>>>>>>> Welcome to volshell! Current memory image > >>>>>>>>>>>>>> is: file:///home/memory.dmp To get > >>>>>>>>>>>>>> help, type 'hh()' > >>>>>>>>>>>>>>>>> db(0x75b6b4d8) > >>>>>>>>>>>>>> 0x75b6b4d8 c3 7c 15 c7 85 00 ff ff ff > >>>>>>>>>>>>>> 01 00 00 00 75 09 8d .|...........u.. > >>>>>>>>>>>>>> 0x75b6b4e8 85 0c ff ff ff 50 ff 17 39 9d > >>>>>>>>>>>>>> 00 ff ff ff 89 85 .....P..9....... > >>>>>>>>>>>>>> 0x75b6b4f8 30 ff ff ff 74 12 6a 0c 8d 85 > >>>>>>>>>>>>>> c4 fe ff ff 50 6a 0...t.j.......Pj > >>>>>>>>>>>>>> 0x75b6b508 07 6a fe e8 ea 92 ff ff 83 bd > >>>>>>>>>>>>>> 28 ff ff ff 0c 0f .j........(..... > >>>>>>>>>>>>>> 0x75b6b518 84 8c 59 00 00 e9 18 ff ff ff > >>>>>>>>>>>>>> 90 90 47 00 6c 00 ..Y.........G.l. > >>>>>>>>>>>>>> 0x75b6b528 6f 00 62 00 61 00 6c 00 5c 00 > >>>>>>>>>>>>>> 54 00 65 00 72 00 o.b.a.l.\.T.e.r. > >>>>>>>>>>>>>> 0x75b6b538 6d 00 53 00 72 00 76 00 52 00 > >>>>>>>>>>>>>> 65 00 61 00 64 00 m.S.r.v.R.e.a.d. > >>>>>>>>>>>>>> 0x75b6b548 79 00 45 00 76 00 65 00 6e 00 > >>>>>>>>>>>>>> 74 00 00 00 90 90 y.E.v.e.n.t..... > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Nope, still no banner. But it is > >>>>>>>>>>>>>> identical to what I find at > >>>>>>>>>>>>> 0x1a34d8 in > >>>>>>>>>>>>>> 123.dmp. (As you'd expect.) > >>>>>>>>>>>>>> Double-checked that I was searching > >>>>>>>>>>>>>> Unicode and ASCII - still no luck. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hmmm. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Adam > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 23 March 2015 at 04:02, Andrew Case > >>>>>>>>>>>>>> <atcuno(a)gmail.com > >>>>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> > >>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>> <mailto:atcuno@gmail.com>>> > >>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>> <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>> > >>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>> > >>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>> <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>>> > >>>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>>> <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>> > >>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>> <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>> > >>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>> <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>> > >>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>> <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>>>>> > >>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Can do you: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> vol.py ... volshell -p 123 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Then in volshell do: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> db(0x75b6b4d8) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> And see if you get the banner printed at > >>>>>>>>>>>>>> the beginning? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Also, how are you searching 123.dmp? Did > >>>>>>>>>>>>>> you search ascii & > >>>>>>>>>>>>> unicode > >>>>>>>>>>>>>> (most common error) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, Andrew (@attrc) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 03/20/2015 03:59 PM, Bridgey theGeek > >>>>>>>>>>>>>>> wrote: Hi all, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I can't quite see what's wrong with my > >>>>>>>>>>>>>>> logic here, but I must be > >>>>>>>>>>>>>> missing > >>>>>>>>>>>>>>> something. Hoping someone can help me > >>>>>>>>>>>>>>> out. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I'm looking for a private key in a > >>>>>>>>>>>>>>> memory sample (WinXPSP2x86). > >>>>>>>>>>>>>>> Specifically, to find out which > >>>>>>>>>>>>>>> process/es is/are accessing it. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I can find the key by searching the raw > >>>>>>>>>>>>>>> memory dump > >>>>>>>>>>>>> (memory.dmp). > >>>>>>>>>>>>>>> As you might expect it's between: > >>>>>>>>>>>>>>> -----BEGIN RSA PRIVATE KEY----- > >>>>>>>>>>>>>>> -----END RSA PRIVATE KEY----- > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I generated an offset:string file by > >>>>>>>>>>>>>>> using strings. Then, using the strings > >>>>>>>>>>>>>>> plugin I get this output: $ python > >>>>>>>>>>>>>>> vol.py -f memory.dmp > >>>>>>>>>>>>>>> --profile=WinXPSP2x86 strings > >>>>>>>>>>>>> -s pk.txt > >>>>>>>>>>>>>>> Volatility Foundation Volatility > >>>>>>>>>>>>>>> Framework 2.4 188435934 [FREE > >>>>>>>>>>>>>>> MEMORY:-1] -----BEGIN RSA PRIVATE > >>>>>>>>>>>>>>> KEY----- 188435968 [FREE MEMORY:-1] > >>>>>>>>>>>>>>> -----END RSA PRIVATE KEY----- 317375704 > >>>>>>>>>>>>>>> [kernel:d2ab24d8] -----BEGIN RSA > >>>>>>>>>>>>>>> PRIVATE KEY----- 317376575 > >>>>>>>>>>>>>>> [kernel:d2ab283f] -----END RSA PRIVATE > >>>>>>>>>>>>>>> KEY----- 417203416 [123:75b6b4d8] > >>>>>>>>>>>>>>> -----BEGIN RSA PRIVATE KEY----- > >>>>>>>>>>>>>>> 417204287 [123:75b6b83f] -----END RSA > >>>>>>>>>>>>>>> PRIVATE KEY----- 419888606 [FREE > >>>>>>>>>>>>>>> MEMORY:-1] -----BEGIN RSA PRIVATE > >>>>>>>>>>>>>>> KEY----- 419888640 [FREE MEMORY:-1] > >>>>>>>>>>>>>>> -----END RSA PRIVATE KEY----- > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Lovely. So I now do a memdump of > >>>>>>>>>>>>>>> process 123: $ python vol.py -f > >>>>>>>>>>>>>>> memory.dmp --profile=WinXPSP2x86 > >>>>>>>>>>>>>>> memdump > >>>>>>>>>>>>> --pid=123 > >>>>>>>>>>>>>>> --dump-dir=123 Volatility Foundation > >>>>>>>>>>>>>>> Volatility Framework 2.4 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> *************************************************************** > * > > > >>>>>>>> > * > > > >>>>>>>> > > *** > > > >>>>>>>> > >> * > >>>>>> > >>> * > >>>>>> ** > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>> Writing myapp.exe [ 123] to 123.dmp > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> However, if I search 123.dmp neither > >>>>>>>>>>>>>>> the BEGIN or END > >>>>>>>>>>>>> strings are > >>>>>>>>>>>>>> present. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> So I thought I'd try and find it via > >>>>>>>>>>>>>>> the virtual address give, > >>>>>>>>>>>>>> 0x75b6b4d8: > >>>>>>>>>>>>>>> $ python vol.py -f memory.dmp > >>>>>>>>>>>>>>> --profile=WinXPSP2x86 memmap > >>>>>>>>>>>>> --pid=123 > >>>>>>>>>>>>>>> Virtual Physical Size > >>>>>>>>>>>>>>> DumpFileOffset ---------- ---------- > >>>>>>>>>>>>>>> ---------- -------------- --SNIP-- > >>>>>>>>>>>>>>> 0x75b6b000 0x18de0000 0x1000 > >>>>>>>>>>>>>>> 0x1a3000 --SNIP-- > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The text is indeed at 0x18de04d8 in > >>>>>>>>>>>>>>> memory.dmp, but not at > >>>>>>>>>>>>> 0x1a34d8 in > >>>>>>>>>>>>>>> 123.dmp. Again, it's no where to be > >>>>>>>>>>>>>>> found in 123.dmp. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Any suggestions..?? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Many thanks, Adam > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > > Vol-users mailing list > >>>>>>>>>>>>>>> Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>> > >>>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>>> > >>>>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>> > >>>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>>>> > >>>>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>> > >>>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>>> > >>>>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>> > >>>>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>>>>> > >>>>>>>>>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-us > e > > > >>>>>>>>>>>>>>> > r > > > >>>>>>>>>>>>>>> > > s > >>>>>>>> > >>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >> _______________________________________________ > >>>>>>>>>>>>> Vol-users mailing list > >>>>>>>>>>>>> Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>> > >>>>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>>> > >>>>>>>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-user > s > >>>>>>>> > >>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> > >>>>>>>>>>>>> > > _______________________________________________ Vol-users > >>>>>>>>>> mailing list Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > >>>>>>>> > >>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > > > >>>>>>>>>> > >>>>>>>>>> > > _______________________________________________ Vol-users > >>>>>>>>>> mailing list Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > >>>>>>> > >>>>>> > >>>>>>>>>> > > > >>>>>>>>>> > >>>>>>>>>> > > _______________________________________________ > >>>>>>>> Vol-users mailing list Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > >>>>>>>> > >>>>>>>> > > > >>>>>>>> > >>>>>>>> > > _______________________________________________ Vol-users > >>>>>>>> mailing list Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > >>>>>>> > >>>>>>>> > > > >>>>>>>> > >>>>>>>> > > _______________________________________________ Vol-users mailing > >>>>>>> list Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > >>>>>> > >>>>>> > >>>>>> > >>>>>>> > > > >>>>>>> > >>>>>>> > > _______________________________________________ Vol-users mailing > >>>>>> list Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > >>> > >>>>>> > > > >>>>>> > _______________________________________________ Vol-users mailing > >>> list Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@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 > > > > _______________________________________________ Vol-users mailing > > list Vol-users(a)volatilityfoundation.org > > http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > > iF4EAREKAAYFAlVWETEACgkQXnt9v1O0LIuYZAD/UsDyJWzldfjbqoR8/me5CI6K > Iy5l/cuykusKHuf+U7MA/2eSg10cTPB+HnPj9QO4GsFNAvUwzFo9aCh9CGudH3SK > =2Ea+ > -----END PGP SIGNATURE----- >

9 years, 11 months

3
9
0 0

OS X Yosemite profiles now in the repo, testing requested

by Andrew Case

I just pushed the profiles that we created for OS X Yosemite into the 'profiles' project: https://github.com/volatilityfoundation/profiles/tree/master/Mac/10.10/x64 They should cover every version of 10.10.x officially released by Apple. If there are any missing versions then please let me know. We are requesting testing across the different versions since the profiles are so new. If you find any issues then please report them at: https://github.com/volatilityfoundation/volatility/issues Thanks for any help! -- Thanks, Andrew (@attrc)

9 years, 11 months

1
0
0 0

Re: [Vol-users] Timeliner "-R" not parsing Registry in 2.4

by Jamie Levy

This is true. When we allowed an option to specify by types the short -R was removed. I think it was also due to a conflict in options. -- Jamie Levy (@gleeda) > On May 18, 2015, at 9:11 AM, Gregory Pendergast <greg.pendergast(a)gmail.com> wrote: > > "--type=Registry" works. -R appears to no longer be an option. > >> On May 18, 2015, at 11:30 AM, Jared Greenhill <jared703(a)gmail.com> wrote: >> >> Vol Team, >> >> II've been unable to parse the Registry of a Windows system with 2.4 like I could with 2.3 using the "-R" switch. Do you invoke Registry parsing the same with 2.4 and Timeliner? When I remove the "-R" flag timeliner runs as expected. Apologies if this has been discussed somewhere. I've tried with Vol.py (compiled from source) and the Windows binary flavor of 2.4. >> >> Here's the errors I am receiving: >> >> C:\Users\DFIR-PC\Desktop\Mem>vol.exe -f Bad.img timeliner --output=body > timeline.txt -R >> Volatility Foundation Volatility Framework 2.4 >> Usage: Volatility - A memory forensics analysis platform. >> >> vol.exe: error: no such option: -R >> >> C:\Users\DFIR-PC\Desktop\Mem>vol.exe -f Bad.img timeliner --output=body --output-file=timeline.txt -R >> Volatility Foundation Volatility Framework 2.4 >> Usage: Volatility - A memory forensics analysis platform. >> >> vol.exe: error: no such option: -R >> >> C:\Users\DFIR-PC\Desktop\Mem>c:\volatility-master\vol.py -f Bad.img timeliner --output=body --output-file=timeline.txt -R >> Volatility Foundation Volatility Framework 2.4 >> >> Usage: Volatility - A memory forensics analysis platform. >> >> vol.py: error: no such option: -R >> >> Thanks! >> Jared >> _______________________________________________ >> 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

9 years, 11 months

2
1
0 0

Timeliner "-R" not parsing Registry in 2.4

by Jared Greenhill

Vol Team, II've been unable to parse the Registry of a Windows system with 2.4 like I could with 2.3 using the "-R" switch. Do you invoke Registry parsing the same with 2.4 and Timeliner? When I remove the "-R" flag timeliner runs as expected. Apologies if this has been discussed somewhere. I've tried with Vol.py (compiled from source) and the Windows binary flavor of 2.4. Here's the errors I am receiving: C:\Users\DFIR-PC\Desktop\Mem>vol.exe -f Bad.img timeliner --output=body > timeline.txt -R Volatility Foundation Volatility Framework 2.4 Usage: Volatility - A memory forensics analysis platform. vol.exe: error: no such option: -R C:\Users\DFIR-PC\Desktop\Mem>vol.exe -f Bad.img timeliner --output=body --output-file=timeline.txt -R Volatility Foundation Volatility Framework 2.4 Usage: Volatility - A memory forensics analysis platform. vol.exe: error: no such option: -R C:\Users\DFIR-PC\Desktop\Mem>c:\volatility-master\vol.py -f Bad.img timeliner --output=body --output-file=timeline.txt -R Volatility Foundation Volatility Framework 2.4 Usage: Volatility - A memory forensics analysis platform. vol.py: error: no such option: -R Thanks! Jared

9 years, 11 months

3
2
0 0

RE: [Vol-users] Output of strings not found in memdump output - QEMU/QEVM sample

by Torres, Geoff (Cyber Security)

Hi, Sorry for the 'me too' response, but I'm having this exact same problem. However, the main difference is that I'm using a 'QEMU' memory image (Hex dump sig is QEVM in the first 4 bytes) from a cloud instance. I've converted these in the past using the 'lqs2mem' tool written by Juerg Haefliger and Andrew Tappert and it's worked perfectly for the 'netscan' and 'ps' type plugins. However, I haven't needed to dump processes before and look for specific strings. I can locate the strings in the converted image, but it's not translating to the processes that are identified by the 'strings' plugin. Here's the steps I've been taking - ## Memory dump info > ll memory_dump -rw------- 1 geoff citsirt 7579914273 Apr 27 13:36 memory_dump > file memory_dump memory_dump: QEMU suspend to disk image > xxd memory_dump | head -n1 0000000: 5145 564d 0000 0003 0100 0000 0105 626c QEVM..........bl ## Convert the dump > lqs2mem -w pc.ram memory_dump memory_dump.ram section = pc.ram size = 8192 [MB] 8589934592 [bytes] section = pc.bios size = 128 [KB] 131072 [bytes] section = pc.rom size = 128 [KB] 131072 [bytes] section = vga.vram size = 16 [MB] 16777216 [bytes] section = 0000:00:02.0/cirrus_vga.rom size = 64 [KB] 65536 [bytes] Wrote 8589934592 bytes from section 'pc.ram' to file memory_dump.ram ## Create the strings file > strings -a -t d memory_dump.ram > memory_dump.ram.strings > strings -a -t d -el memory_dump.ram >> memory_dump.ram.strings ## Create the volatility strings file > python /data/download/apps/forensic_tools/volatility/vol.py -f memory_dump.ram --profile=Win2008SP2x64 strings -s --output-file=memory_dump.ram.vol.strings > ll memory_dump.ram.strings memory_dump.ram.vol.strings -rw-rw-r-- 1 geoff citsirt 2914258187 May 7 08:58 memory_dump.ram.strings -rw-rw-r-- 1 geoff citsirt 4292775089 May 7 12:17 memory_dump.ram.vol.strings ## '<Search_String>' is found in both string files as expected > fgrep <Search_String> memory_dump.ram.strings memory_dump.ram.vol.strings memory_dump.ram.strings:183190042 <Search_String> memory_dump.ram.vol.strings:183190042 [3156:0189321a] <Search_String> ## Dump process 3156 as identified by volatility > python /data/download/apps/forensic_tools/volatility/vol.py -f memory_dump.ram --profile=Win2008SP2x64 procdump -p 3156 -D processes -m Volatility Foundation Volatility Framework 2.4 Process(V) ImageBase Name Result ------------------ ------------------ -------------------- ------ 0xfffffa800a4e6370 0x0000000000400000 iwproxy.exe OK: executable.3156.exe >ll processes/executable.3156.exe -rw-rw-r-- 1 geoff citsirt 3248128 May 7 12:35 processes/executable.3156.exe ## '<Search_String>' not found in the dumped executable > strings -a processes/executable.3156.exe | fgrep <Search_String> > strings -a -el processes/executable.3156.exe | fgrep <Search_String> I've tried many different variations of the above steps and all have the same results. According to what I've read in this thread is that the issue is to make sure the original dump is properly converted. How can I do that? 'lqs2mem' has limited options. Any ideas on what I can do differently to get this to work? Thanks, Geoff Don't be afraid to tell me I'm doing something stupid... :-) -----Original Message----- From: vol-users-bounces(a)volatilesystems.com [mailto:vol-users-bounces@volatilesystems.com] On Behalf Of Michael Ligh Sent: Tuesday, March 24, 2015 6:49 AM To: Bridgey theGeek Cc: vol-users(a)volatilesystems.com Subject: Re: [Vol-users] Output of strings not found in memdump output -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Perfect! Glad to hear all is good in the world ;-) MHL On 3/24/15 5:05 AM, Bridgey theGeek wrote: > Awesome, thanks Michael. > > I generated a raw dump as follows, with the vmsn and vmem files in the > same folder: $ python vol.py -f winxp.vmem > --profile=WinXPSP2x86 imagecopy -O winxp.raw > > Then ran strings again (having generated a new input text file because > of course the offsets will be different): $ python vol.py -f winxp.raw > --profile=WinXPSP2x86 strings -s pk.txt > > I was then able to find the banner at the offsets reported by strings. > And all was good in the world. > > Thank you very much for the support. > > Adam > > On 23 March 2015 at 19:39, Michael Ligh <michael.ligh(a)mnin.org > <mailto:michael.ligh@mnin.org>> wrote: > > Hey Adam, > > A few things: > > * Yes, vmss2core creates a windows crash dump * You can use volatility > on the original vmem/vmss by doing the following: > > * make sure both vmem and vmss files are in the same dir * make sure > they have the same base name (i.e. test.vmem and test.vmss) * run your > volatility plugins against the vmem > > In this case, it would also be required to generate a raw memory dump > before running strings. So you would use imagecopy on the vmem. > > LMK if that helps! Michael > > On 3/23/15 10:51 AM, Bridgey theGeek wrote: >> Hi Michael, > >> *sigh* When will I learn to check the origin of my samples?! > >> The guy who provided me with the sample tells me that he took a >> snapshot of a VMWare machine and then used vss2core to convert it. I >> BELIEVE that makes it into a Windows Memory Core Dump..? > >> I got hold of the original vmem and vmsn files. Trying to use >> imagecopy on the vmsn just replicated the input file. I think the >> header is not what Volatility would expect: $ xxd Windows\ XP\ Pro\ >> SP2\ $32-bit$-Snapshot49.vmsn |head 0000000: d2be d2be >> 0800 0000 6300 0000 4368 6563 ........c...Chec 0000010: 6b70 >> 6f69 6e74 0000 0000 0000 0000 0000 kpoint.......... 0000020: >> 0000 0000 0000 0000 0000 0000 0000 0000 ................ >> 0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ >> 0000040: 0000 0000 0000 0000 0000 0000 fc1e 0000 ................ >> 0000050: 0000 0000 ab03 0000 0000 0000 4775 6573 ............Gues >> 0000060: 7456 6172 7300 0000 0000 0000 0000 0000 tVars........... >> 0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ >> 0000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ >> 0000090: 0000 0000 0000 0000 0000 0000 a722 0000 .............".. > >> Does that mean I can't use this with Volatility? > >> Thank you, Adam > >> On 23 March 2015 at 14:57, Michael Ligh <michael.ligh(a)mnin.org >> <mailto:michael.ligh@mnin.org> <mailto:michael.ligh@mnin.org >> <mailto:michael.ligh@mnin.org>>> wrote: > >> Hey Adam, > >> We forgot to ask if the sample was a raw memory dump. For >> example: > >> $ xxd ~/Desktop/memory.dmp | less > >> 0000000: 5041 4745 4455 4d50 0f00 0000 280a 0000 PAGEDUMP....(... >> 0000010: 8001 6c07 00c0 e680 a031 5580 5892 5580 ..l......1U.X.U. >> 0000020: 4c01 0000 0100 0000 8000 0000 5444 4f00 L...........TDO. >> 0000030: 0000 0000 0000 0000 0000 0000 5041 4745 ............PAGE >> 0000040: 5041 4745 5041 4745 5041 4745 5041 4745 PAGEPAGEPAGEPAGE > >> If its something like a crash dump, hibernation, etc then the file >> format headers throw off the offsets. You can convert those special >> file types into a raw memory dump with the imagecopy plugin and then >> your strings translations should be accurate. > >> Cheers! MHL > >> On 3/23/15 8:54 AM, Bridgey theGeek wrote: >>> Hi Andrew, > >>> I was certain I was running the latest version, but just to be sure >>> I grabbed the latest version. Same result, same offsets. > >>> I can make the sample available, but more than happy to do whatever >>> debugging needs doing (if I can!) > >>> Adam > >>> On 23 March 2015 at 13:03, Andrew Case <atcuno(a)gmail.com >>> <mailto:atcuno@gmail.com> <mailto:atcuno@gmail.com >>> <mailto:atcuno@gmail.com>> > <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> >>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>> wrote: > >>> Are you using the latest git checkout of Volatility or the 2.4 >>> release? Can you try the latest checkout and re-run Volatility >>> strings (you can run it on just the offsets from PID 123 to make it >>> faster). > >>> If you are already on the latest checkout then we will need to debug >>> further. > > > > >>> Thanks, Andrew (@attrc) > >>> On 03/23/2015 04:38 AM, Bridgey theGeek wrote: >>>> Thanks Andrew: >>>> >>>> python vol.py --profile=WinXPSP2x86 -f memory.dmp volshell -p 123 >>>> Volatility Foundation Volatility Framework 2.4 Current context: >>>> myapp.exe @ 0x822042f8, pid=123, ppid=392 >>> DTB=0x76c0040 >>>> Welcome to volshell! Current memory image is: >>>> file:///home/memory.dmp To get help, type 'hh()' >>>>>>> db(0x75b6b4d8) >>>> 0x75b6b4d8 c3 7c 15 c7 85 00 ff ff ff 01 00 00 00 75 09 8d >>>> .|...........u.. 0x75b6b4e8 85 0c ff ff ff 50 ff 17 39 9d >>>> 00 ff ff ff 89 85 .....P..9....... 0x75b6b4f8 30 ff ff ff 74 >>>> 12 6a 0c 8d 85 c4 fe ff ff 50 6a 0...t.j.......Pj 0x75b6b508 >>>> 07 6a fe e8 ea 92 ff ff 83 bd 28 ff ff ff 0c 0f .j........(..... >>>> 0x75b6b518 84 8c 59 00 00 e9 18 ff ff ff 90 >>>> 90 47 00 6c 00 ..Y.........G.l. 0x75b6b528 6f 00 62 00 61 00 6c 00 >>>> 5c 00 54 00 65 00 72 00 o.b.a.l.\.T.e.r. 0x75b6b538 6d >>>> 00 53 00 72 00 76 00 52 00 65 00 61 00 64 00 m.S.r.v.R.e.a.d. >>>> 0x75b6b548 79 00 45 00 76 00 65 00 6e 00 74 00 00 00 90 90 >>>> y.E.v.e.n.t..... >>>> >>>> Nope, still no banner. But it is identical to what I find at >>> 0x1a34d8 in >>>> 123.dmp. (As you'd expect.) Double-checked that I was searching >>>> Unicode and ASCII - still no luck. >>>> >>>> Hmmm. >>>> >>>> Adam >>>> >>>> On 23 March 2015 at 04:02, Andrew Case <atcuno(a)gmail.com > <mailto:atcuno@gmail.com> >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> >>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>> >>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>>> wrote: >>>> >>>> Can do you: >>>> >>>> vol.py ... volshell -p 123 >>>> >>>> Then in volshell do: >>>> >>>> db(0x75b6b4d8) >>>> >>>> And see if you get the banner printed at the beginning? >>>> >>>> Also, how are you searching 123.dmp? Did you search ascii & >>> unicode >>>> (most common error) >>>> >>>> Thanks, Andrew (@attrc) >>>> >>>> On 03/20/2015 03:59 PM, Bridgey theGeek wrote: >>>>> Hi all, >>>>> >>>>> I can't quite see what's wrong with my logic here, but I must be >>>> missing >>>>> something. Hoping someone can help me out. >>>>> >>>>> I'm looking for a private key in a memory sample (WinXPSP2x86). >>>>> Specifically, to find out which process/es is/are accessing it. >>>>> >>>>> I can find the key by searching the raw memory dump >>> (memory.dmp). >>>>> As you might expect it's between: -----BEGIN RSA PRIVATE >>>>> KEY----- -----END RSA PRIVATE KEY----- >>>>> >>>>> I generated an offset:string file by using strings. Then, using >>>>> the strings plugin I get this output: $ python vol.py -f >>>>> memory.dmp --profile=WinXPSP2x86 strings >>> -s pk.txt >>>>> Volatility Foundation Volatility Framework 2.4 188435934 [FREE >>>>> MEMORY:-1] -----BEGIN RSA PRIVATE KEY----- 188435968 [FREE >>>>> MEMORY:-1] -----END RSA PRIVATE KEY----- 317375704 >>>>> [kernel:d2ab24d8] -----BEGIN RSA PRIVATE KEY----- >>>>> 317376575 [kernel:d2ab283f] -----END RSA PRIVATE KEY----- >>>>> 417203416 [123:75b6b4d8] -----BEGIN RSA PRIVATE KEY----- >>>>> 417204287 [123:75b6b83f] -----END RSA PRIVATE KEY----- >>>>> 419888606 [FREE MEMORY:-1] -----BEGIN RSA PRIVATE KEY----- >>>>> 419888640 [FREE MEMORY:-1] -----END RSA PRIVATE KEY----- >>>>> >>>>> Lovely. So I now do a memdump of process 123: $ python vol.py -f >>>>> memory.dmp --profile=WinXPSP2x86 memdump >>> --pid=123 >>>>> --dump-dir=123 Volatility Foundation Volatility Framework >>>>> 2.4 >>>>> >>>> > > > ********************************************************************** > ** > > > > >>>> Writing myapp.exe [ 123] to 123.dmp >>>>> >>>>> However, if I search 123.dmp neither the BEGIN or END >>> strings are >>>> present. >>>>> >>>>> So I thought I'd try and find it via the virtual address give, >>>> 0x75b6b4d8: >>>>> $ python vol.py -f memory.dmp --profile=WinXPSP2x86 memmap >>> --pid=123 >>>>> Virtual Physical Size DumpFileOffset ---------- >>>>> ---------- ---------- -------------- --SNIP-- 0x75b6b000 >>>>> 0x18de0000 0x1000 0x1a3000 --SNIP-- >>>>> >>>>> The text is indeed at 0x18de04d8 in memory.dmp, but not at >>> 0x1a34d8 in >>>>> 123.dmp. Again, it's no where to be found in 123.dmp. >>>>> >>>>> Any suggestions..?? >>>>> >>>>> Many thanks, Adam >>>>> >>>>> >>>>> _______________________________________________ Vol-users mailing >>>>> list Vol-users(a)volatilesystems.com > <mailto:Vol-users@volatilesystems.com> >> <mailto:Vol-users@volatilesystems.com > <mailto:Vol-users@volatilesystems.com>> >>> <mailto:Vol-users@volatilesystems.com > <mailto:Vol-users@volatilesystems.com> >> <mailto:Vol-users@volatilesystems.com > <mailto:Vol-users@volatilesystems.com>>> >>> <mailto:Vol-users@volatilesystems.com > <mailto:Vol-users@volatilesystems.com> >> <mailto:Vol-users@volatilesystems.com > <mailto:Vol-users@volatilesystems.com>> >>> <mailto:Vol-users@volatilesystems.com > <mailto:Vol-users@volatilesystems.com> >>> <mailto:Vol-users@volatilesystems.com > <mailto:Vol-users@volatilesystems.com>>>> >>>>> http://lists.volatilesystems.com/mailman/listinfo/vol-users >>>>> >>>> >>>> > >>>>> > > > >>> _______________________________________________ Vol-users mailing >>> list Vol-users(a)volatilesystems.com > <mailto:Vol-users@volatilesystems.com> >>> <mailto:Vol-users@volatilesystems.com > <mailto:Vol-users@volatilesystems.com>> >>> http://lists.volatilesystems.com/mailman/listinfo/vol-users > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iF4EAREKAAYFAlURazkACgkQXnt9v1O0LItfjAD/W7UeZMNiWVRMqeeJftNRaxG2 dpi/c755Qxc6X7PUKU8A/iREkToI9Ad0/GejtG32OpZMLjk0gjhj5XoMxAWuY69D =JNEv -----END PGP SIGNATURE----- _______________________________________________ Vol-users mailing list Vol-users(a)volatilesystems.com http://lists.volatilesystems.com/mailman/listinfo/vol-users

9 years, 11 months

5
12
0 0

mac_psxview command problem on Yosemite

by Justin q. Case

Hey everyone, I recently built a 10.10.3 Yosemite profile for 10.10.3 image I have. When I try to run mac_psxview on the image, I’m getting a bunch of errors as shown below. Any ideas? bash-3.2# python /usr/local/bin/vol.py -f /users/msquire/desktop/share/macloginELF.dump --profile MacYosemite10_10_3_64bitx64 mac_psxview Volatility Foundation Volatility Framework 2.4 Traceback (most recent call last): File "/usr/local/bin/vol.py", line 5, in <module> pkg_resources.run_script('volatility==2.4', 'vol.py') File "/Library/Python/2.7/site-packages/pkg_resources/__init__.py", line 729, in run_script self.require(requires)[0].run_script(script_name, ns) File "/Library/Python/2.7/site-packages/pkg_resources/__init__.py", line 1642, in run_script exec(code, namespace, namespace) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/EGG-INFO/scripts/vol.py", line 192, in <module> main() File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/EGG-INFO/scripts/vol.py", line 183, in main command.execute() File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/plugins/mac/common.py", line 46, in execute commands.Command.execute(self, *args, **kwargs) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/commands.py", line 99, in execute if not self.is_valid_profile(profs[self._config.PROFILE]()): File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/plugins/overlays/mac/mac.py", line 1098, in __init__ obj.Profile.__init__(self, *args, **kwargs) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 858, in __init__ self.reset() File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/plugins/overlays/mac/mac.py", line 1117, in reset self.load_modifications() File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 940, in load_modifications mod.modification(self) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/plugins/overlays/mac/mac.py", line 1367, in modification profile.merge_overlay(mac_overlay) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 1031, in merge_overlay self.vtypes[k] = self._apply_overlay(self.vtypes[k], v) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 1081, in _apply_overlay result.append(self._apply_overlay(type_member[i], overlay[i])) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 1068, in _apply_overlay result[k] = self._apply_overlay(type_member[k], v) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 1081, in _apply_overlay result.append(self._apply_overlay(type_member[i], overlay[i])) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 1072, in _apply_overlay if len(overlay) != len(type_member): TypeError: object of type 'int' has no len() Using OSXPmem to acquire the images, tried with RAW, ELF (as above), and MACHO types. This has been killing me, any help would be greatly appreciated! Thank you!

9 years, 11 months

1
0
0 0

Calling memory analysis in NY, Reston, and Amsterdam

by Michael Ligh

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi folks, If you're in the NY area next week, hook up with us and some other @volatility users for a few drinks on Wednesday night (13th). Request details off list. Also just a heads up for the next Malware and Memory Forensics training classes...we'll be in Amsterdam Aug 31 - Sept 4 and then back in Reston, VA October 5 - 9. We hope to see some of you there! MHL -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iF4EAREKAAYFAlVOL/8ACgkQXnt9v1O0LIsTOAD/RAAqA2H0UHLht6daYd1LRVSg 5Wie9xEysWHJx5o42MgBAIrHRvTvUiGXWfBW9IdrDE522taJjmoxftRc6P1OpN8a =SOEJ -----END PGP SIGNATURE-----

9 years, 11 months

1
0
0 0

BSidesNOLA is one month away!

by Andrew Case

Hello All, We are writing as BSidesNOLA is roughly one month away, and we would like to see everyone there. We have put together our best speaker lineup yet, and we want to get as big a crowd as possible for learning, networking, and a day of fun. Registration is only $10, but you must pre-register through Eventbrite: https://www.eventbrite.com/e/bsides-nola-2015-tickets-9621601469. Full information on the conference, including the keynote and 18 technical presentations, can be found here: http://www.securitybsides.com/w/page/91550808/BSidesNOLA%202015 We hope to see everyone there, and please don’t be shy of spreading the word! Thanks, The BSidesNOLA Team

9 years, 12 months

1
0
0 0

OSDFCon CFP

by Brian Carrier

Open Source Digital Forensics Conference - Call For Presentations and Workshops The 6th Annual Open Source Digital Forensics Conference (OSDFCon) will be held on October 28, 2015 in Herndon, VA. All users and developers are invited to submit a presentation or workshop topic by June 1, 2015. This is a unique opportunity to present your work and experiences to over 400 people. The conference will be attended by both digital forensic investigators and developers. This event is a great opportunity to make investigators aware of your tools, get feedback from users, meet fellow developers and users, and help direct the future of open source digital forensics software. To receive updates about the conference, sign up for e-mail updates (http://www.osdfcon.org) or watch #osdfcon on twitter. TOPICS We are looking for 35-minute talks on a variety of topics about using open source tools, including: * New tools and analysis techniques * New features to mature tools * Open, plug-in analysis framework designs and experiences * Automated analysis * Hard drive analysis and triage * Memory and network forensics * Mobile device forensics * Analyzing application-level artifacts * Cyber incident response * User experiences * Case studies We also have openings for half-day workshops on the day before the conference (October 27, 2015). The workshops should teach people how to use or develop open source tools by providing hands-on guidance. SUBMISSION INSTRUCTIONS Topics can be submitted using an online form: http://www.osdfcon.org Submissions are due June 1, 2015. Our plan this year is to do an initial pass of the submissions and then use crowd sourcing to choose the final set of topics. E-mail submissions2015 [at] osdfcon [dot] org with any questions.

10 years

1
0
0 0

Few training class updates and "night out" notice

by Michael Ligh

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi folks, There's one week left to register for the upcoming Reston class (April 13-17). If you're from Reston or will be there working during the time, drop us a note and we'll include you in the "night out" announcement so you can come have some drinks with other Volatility users. Same applies to the New York class during the week of May 11-15, UK June 1-5 and Amsterdam August 31-September 4. We hope to see some of guys there! MHL -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iF4EAREKAAYFAlUb84YACgkQXnt9v1O0LIv08gEAlz1YdHOV2NfMQzOzDegIguFI EkVTkFR6kFSDo2z1oRgBAJWc+SJyUJ+wP93ULd8pFw9d97QqCr8y+aQnEsKlVn3A =W35+ -----END PGP SIGNATURE-----

10 years, 1 month

1
0
0 0

Re: [Vol-users] Output of strings not found in memdump output

by Michael Ligh

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Perfect! Glad to hear all is good in the world ;-) MHL On 3/24/15 5:05 AM, Bridgey theGeek wrote: > Awesome, thanks Michael. > > I generated a raw dump as follows, with the vmsn and vmem files in > the same folder: $ python vol.py -f winxp.vmem > --profile=WinXPSP2x86 imagecopy -O winxp.raw > > Then ran strings again (having generated a new input text file > because of course the offsets will be different): $ python vol.py > -f winxp.raw --profile=WinXPSP2x86 strings -s pk.txt > > I was then able to find the banner at the offsets reported by > strings. And all was good in the world. > > Thank you very much for the support. > > Adam > > On 23 March 2015 at 19:39, Michael Ligh <michael.ligh(a)mnin.org > <mailto:michael.ligh@mnin.org>> wrote: > > Hey Adam, > > A few things: > > * Yes, vmss2core creates a windows crash dump * You can use > volatility on the original vmem/vmss by doing the following: > > * make sure both vmem and vmss files are in the same dir * make > sure they have the same base name (i.e. test.vmem and test.vmss) * > run your volatility plugins against the vmem > > In this case, it would also be required to generate a raw memory > dump before running strings. So you would use imagecopy on the > vmem. > > LMK if that helps! Michael > > On 3/23/15 10:51 AM, Bridgey theGeek wrote: >> Hi Michael, > >> *sigh* When will I learn to check the origin of my samples?! > >> The guy who provided me with the sample tells me that he took a >> snapshot of a VMWare machine and then used vss2core to convert >> it. I BELIEVE that makes it into a Windows Memory Core Dump..? > >> I got hold of the original vmem and vmsn files. Trying to use >> imagecopy on the vmsn just replicated the input file. I think >> the header is not what Volatility would expect: $ xxd Windows\ >> XP\ Pro\ SP2\ $32-bit$-Snapshot49.vmsn |head 0000000: d2be d2be >> 0800 0000 6300 0000 4368 6563 ........c...Chec 0000010: 6b70 >> 6f69 6e74 0000 0000 0000 0000 0000 kpoint.......... 0000020: >> 0000 0000 0000 0000 0000 0000 0000 0000 ................ >> 0000030: 0000 0000 0000 0000 0000 0000 0000 0000 >> ................ 0000040: 0000 0000 0000 0000 0000 0000 fc1e 0000 >> ................ 0000050: 0000 0000 ab03 0000 0000 0000 4775 6573 >> ............Gues 0000060: 7456 6172 7300 0000 0000 0000 0000 0000 >> tVars........... 0000070: 0000 0000 0000 0000 0000 0000 0000 0000 >> ................ 0000080: 0000 0000 0000 0000 0000 0000 0000 0000 >> ................ 0000090: 0000 0000 0000 0000 0000 0000 a722 0000 >> .............".. > >> Does that mean I can't use this with Volatility? > >> Thank you, Adam > >> On 23 March 2015 at 14:57, Michael Ligh <michael.ligh(a)mnin.org >> <mailto:michael.ligh@mnin.org> <mailto:michael.ligh@mnin.org >> <mailto:michael.ligh@mnin.org>>> wrote: > >> Hey Adam, > >> We forgot to ask if the sample was a raw memory dump. For >> example: > >> $ xxd ~/Desktop/memory.dmp | less > >> 0000000: 5041 4745 4455 4d50 0f00 0000 280a 0000 >> PAGEDUMP....(... 0000010: 8001 6c07 00c0 e680 a031 5580 5892 5580 >> ..l......1U.X.U. 0000020: 4c01 0000 0100 0000 8000 0000 5444 4f00 >> L...........TDO. 0000030: 0000 0000 0000 0000 0000 0000 5041 4745 >> ............PAGE 0000040: 5041 4745 5041 4745 5041 4745 5041 4745 >> PAGEPAGEPAGEPAGE > >> If its something like a crash dump, hibernation, etc then the >> file format headers throw off the offsets. You can convert those >> special file types into a raw memory dump with the imagecopy >> plugin and then your strings translations should be accurate. > >> Cheers! MHL > >> On 3/23/15 8:54 AM, Bridgey theGeek wrote: >>> Hi Andrew, > >>> I was certain I was running the latest version, but just to be >>> sure I grabbed the latest version. Same result, same offsets. > >>> I can make the sample available, but more than happy to do >>> whatever debugging needs doing (if I can!) > >>> Adam > >>> On 23 March 2015 at 13:03, Andrew Case <atcuno(a)gmail.com >>> <mailto:atcuno@gmail.com> <mailto:atcuno@gmail.com >>> <mailto:atcuno@gmail.com>> > <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> >>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>> wrote: > >>> Are you using the latest git checkout of Volatility or the 2.4 >>> release? Can you try the latest checkout and re-run Volatility >>> strings (you can run it on just the offsets from PID 123 to >>> make it faster). > >>> If you are already on the latest checkout then we will need to >>> debug further. > > > > >>> Thanks, Andrew (@attrc) > >>> On 03/23/2015 04:38 AM, Bridgey theGeek wrote: >>>> Thanks Andrew: >>>> >>>> python vol.py --profile=WinXPSP2x86 -f memory.dmp volshell >>>> -p 123 Volatility Foundation Volatility Framework 2.4 >>>> Current context: myapp.exe @ 0x822042f8, pid=123, ppid=392 >>> DTB=0x76c0040 >>>> Welcome to volshell! Current memory image is: >>>> file:///home/memory.dmp To get help, type 'hh()' >>>>>>> db(0x75b6b4d8) >>>> 0x75b6b4d8 c3 7c 15 c7 85 00 ff ff ff 01 00 00 00 75 09 8d >>>> .|...........u.. 0x75b6b4e8 85 0c ff ff ff 50 ff 17 39 9d >>>> 00 ff ff ff 89 85 .....P..9....... 0x75b6b4f8 30 ff ff ff 74 >>>> 12 6a 0c 8d 85 c4 fe ff ff 50 6a 0...t.j.......Pj 0x75b6b508 >>>> 07 6a fe e8 ea 92 ff ff 83 bd 28 ff ff ff 0c 0f >>>> .j........(..... 0x75b6b518 84 8c 59 00 00 e9 18 ff ff ff 90 >>>> 90 47 00 6c 00 ..Y.........G.l. 0x75b6b528 6f 00 62 00 61 00 >>>> 6c 00 5c 00 54 00 65 00 72 00 o.b.a.l.\.T.e.r. 0x75b6b538 6d >>>> 00 53 00 72 00 76 00 52 00 65 00 61 00 64 00 m.S.r.v.R.e.a.d. >>>> 0x75b6b548 79 00 45 00 76 00 65 00 6e 00 74 00 00 00 90 90 >>>> y.E.v.e.n.t..... >>>> >>>> Nope, still no banner. But it is identical to what I find at >>> 0x1a34d8 in >>>> 123.dmp. (As you'd expect.) Double-checked that I was >>>> searching Unicode and ASCII - still no luck. >>>> >>>> Hmmm. >>>> >>>> Adam >>>> >>>> On 23 March 2015 at 04:02, Andrew Case <atcuno(a)gmail.com > <mailto:atcuno@gmail.com> >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> >>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>> >>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>>> wrote: >>>> >>>> Can do you: >>>> >>>> vol.py ... volshell -p 123 >>>> >>>> Then in volshell do: >>>> >>>> db(0x75b6b4d8) >>>> >>>> And see if you get the banner printed at the beginning? >>>> >>>> Also, how are you searching 123.dmp? Did you search ascii & >>> unicode >>>> (most common error) >>>> >>>> Thanks, Andrew (@attrc) >>>> >>>> On 03/20/2015 03:59 PM, Bridgey theGeek wrote: >>>>> Hi all, >>>>> >>>>> I can't quite see what's wrong with my logic here, but I >>>>> must be >>>> missing >>>>> something. Hoping someone can help me out. >>>>> >>>>> I'm looking for a private key in a memory sample >>>>> (WinXPSP2x86). Specifically, to find out which process/es >>>>> is/are accessing it. >>>>> >>>>> I can find the key by searching the raw memory dump >>> (memory.dmp). >>>>> As you might expect it's between: -----BEGIN RSA PRIVATE >>>>> KEY----- -----END RSA PRIVATE KEY----- >>>>> >>>>> I generated an offset:string file by using strings. Then, >>>>> using the strings plugin I get this output: $ python >>>>> vol.py -f memory.dmp --profile=WinXPSP2x86 strings >>> -s pk.txt >>>>> Volatility Foundation Volatility Framework 2.4 188435934 >>>>> [FREE MEMORY:-1] -----BEGIN RSA PRIVATE KEY----- 188435968 >>>>> [FREE MEMORY:-1] -----END RSA PRIVATE KEY----- 317375704 >>>>> [kernel:d2ab24d8] -----BEGIN RSA PRIVATE KEY----- >>>>> 317376575 [kernel:d2ab283f] -----END RSA PRIVATE KEY----- >>>>> 417203416 [123:75b6b4d8] -----BEGIN RSA PRIVATE KEY----- >>>>> 417204287 [123:75b6b83f] -----END RSA PRIVATE KEY----- >>>>> 419888606 [FREE MEMORY:-1] -----BEGIN RSA PRIVATE KEY----- >>>>> 419888640 [FREE MEMORY:-1] -----END RSA PRIVATE KEY----- >>>>> >>>>> Lovely. So I now do a memdump of process 123: $ python >>>>> vol.py -f memory.dmp --profile=WinXPSP2x86 memdump >>> --pid=123 >>>>> --dump-dir=123 Volatility Foundation Volatility Framework >>>>> 2.4 >>>>> >>>> > > > ************************************************************************ > > > > >>>> Writing myapp.exe [ 123] to 123.dmp >>>>> >>>>> However, if I search 123.dmp neither the BEGIN or END >>> strings are >>>> present. >>>>> >>>>> So I thought I'd try and find it via the virtual address >>>>> give, >>>> 0x75b6b4d8: >>>>> $ python vol.py -f memory.dmp --profile=WinXPSP2x86 memmap >>> --pid=123 >>>>> Virtual Physical Size DumpFileOffset ---------- >>>>> ---------- ---------- -------------- --SNIP-- 0x75b6b000 >>>>> 0x18de0000 0x1000 0x1a3000 --SNIP-- >>>>> >>>>> The text is indeed at 0x18de04d8 in memory.dmp, but not at >>> 0x1a34d8 in >>>>> 123.dmp. Again, it's no where to be found in 123.dmp. >>>>> >>>>> Any suggestions..?? >>>>> >>>>> Many thanks, Adam >>>>> >>>>> >>>>> _______________________________________________ Vol-users >>>>> mailing list Vol-users(a)volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org> >> <mailto:Vol-users@volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org>> >>> <mailto:Vol-users@volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org> >> <mailto:Vol-users@volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org>>> >>> <mailto:Vol-users@volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org> >> <mailto:Vol-users@volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org>> >>> <mailto:Vol-users@volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org> >>> <mailto:Vol-users@volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org>>>> >>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users >>>>> >>>> >>>> > >>>>> > > > >>> _______________________________________________ Vol-users >>> mailing list Vol-users(a)volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org> >>> <mailto:Vol-users@volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org>> >>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iF4EAREKAAYFAlURazkACgkQXnt9v1O0LItfjAD/W7UeZMNiWVRMqeeJftNRaxG2 dpi/c755Qxc6X7PUKU8A/iREkToI9Ad0/GejtG32OpZMLjk0gjhj5XoMxAWuY69D =JNEv -----END PGP SIGNATURE-----

10 years, 1 month

1
0
0 0

Linux profile w/LiME not working

by Brian Keefer

I built LiME from the tarball on the project site (not latest svn) and was able to dump memory successfully (type=lime). After many trials and tribulations I was able to get the Volatility profile built for CentOS 5.3x64 (had to remove pmem from the Makefile). I put the profile in the correct directory, and vol.py --info lists it as expected, however when I try to use the profile with the memory image I get an error. chort@hydra:~/code/profiles-volatility/CentOS_5.3_x64$ vol.py --profile=LinuxCentOS_5_3x64 -f /fun/ir/geriatrix.lime linux_lsmod Volatile Systems Volatility Framework 2.3_alpha WARNING : volatility.obj : Overlay structure cpuinfo_x86 not present in vtypes 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 JKIA32PagedMemoryPae: No base Address Space AMD64PagedMemory: No base Address Space JKIA32PagedMemory: No base Address Space IA32PagedMemoryPae: Module disabled IA32PagedMemory: Module disabled MachOAddressSpace: MachO Header signature invalid 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: ELF64 Header signature invalid VMWareSnapshotFile: Invalid VMware signature: 0xf000ff53 WindowsCrashDumpSpace32: Header signature invalid JKIA32PagedMemoryPae: Incompatible profile LinuxCentOS_5_3x64 selected AMD64PagedMemory: Failed valid Address Space check JKIA32PagedMemory: Incompatible profile LinuxCentOS_5_3x64 selected IA32PagedMemoryPae: Module disabled IA32PagedMemory: Module disabled FileAddressSpace: Must be first Address Space ArmAddressSpace: Incompatible profile LinuxCentOS_5_3x64 selected On a hunch I checked the directory I built the profile in (copied headers & source from the target system): chort@hydra:~/code/profiles-volatility/CentOS_5.3_x64$ grep cpuinfo * System.map-2.6.18-128.el5:ffffffff8006f328 t show_cpuinfo System.map-2.6.18-128.el5:ffffffff80103251 t cpuinfo_open System.map-2.6.18-128.el5:ffffffff8020eadb t show_cpuinfo_max_freq System.map-2.6.18-128.el5:ffffffff8020eafa t show_cpuinfo_min_freq System.map-2.6.18-128.el5:ffffffff8020f759 t show_cpuinfo_cur_freq System.map-2.6.18-128.el5:ffffffff802f0bc0 D cpuinfo_op System.map-2.6.18-128.el5:ffffffff80308420 d proc_cpuinfo_operations System.map-2.6.18-128.el5:ffffffff803319a0 d cpuinfo_cur_freq System.map-2.6.18-128.el5:ffffffff80331b20 d cpuinfo_min_freq System.map-2.6.18-128.el5:ffffffff80331b60 d cpuinfo_max_freq Platform running Volatility (2.3_alpha, latest from svn): Linux hydra 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Source of memory image: Linux geriatrix.smtps.net 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux What am I missing? -- chort

10 years, 1 month

3
6
0 0

Profile build on CentOS 5.8 fails

by Brian Keefer

I noticed there’s a special ifdef for 2.6.18 kernels, which this is. The alleged redefinitions also appear to be inside of a struct, in which case is that really an error? This compiler (gcc-4.1.2) evidently thinks it is. make -C //lib/modules/2.6.18-308.4.1.el5.P1/build CONFIG_DEBUG_INFO=y M="/root/scratch/vol-linux" modules make[1]: Entering directory `/usr/src/kernels/2.6.18-308.4.1.el5.P1-x86_64' CC [M] /root/scratch/vol-linux/module.o /root/scratch/vol-linux/module.c:204: error: redefinition of ‘struct module_sect_attr’ /root/scratch/vol-linux/module.c:211: error: redefinition of ‘struct module_sect_attrs’ /root/scratch/vol-linux/module.c:353:5: warning: "STATS" is not defined /root/scratch/vol-linux/module.c:369:5: warning: "DEBUG" is not defined make[2]: *** [/root/scratch/vol-linux/module.o] Error 1 make[1]: *** [_module_/root/scratch/vol-linux] Error 2 make[1]: Leaving directory `/usr/src/kernels/2.6.18-308.4.1.el5.P1-x86_64' make: *** [dwarf] Error 2 -- bk

10 years, 1 month

2
2
0 0

Output of strings not found in memdump output

by Bridgey theGeek

Hi all, I can't quite see what's wrong with my logic here, but I must be missing something. Hoping someone can help me out. I'm looking for a private key in a memory sample (WinXPSP2x86). Specifically, to find out which process/es is/are accessing it. I can find the key by searching the raw memory dump (memory.dmp). As you might expect it's between: -----BEGIN RSA PRIVATE KEY----- -----END RSA PRIVATE KEY----- I generated an offset:string file by using strings. Then, using the strings plugin I get this output: $ python vol.py -f memory.dmp --profile=WinXPSP2x86 strings -s pk.txt Volatility Foundation Volatility Framework 2.4 188435934 [FREE MEMORY:-1] -----BEGIN RSA PRIVATE KEY----- 188435968 [FREE MEMORY:-1] -----END RSA PRIVATE KEY----- 317375704 [kernel:d2ab24d8] -----BEGIN RSA PRIVATE KEY----- 317376575 [kernel:d2ab283f] -----END RSA PRIVATE KEY----- 417203416 [123:75b6b4d8] -----BEGIN RSA PRIVATE KEY----- 417204287 [123:75b6b83f] -----END RSA PRIVATE KEY----- 419888606 [FREE MEMORY:-1] -----BEGIN RSA PRIVATE KEY----- 419888640 [FREE MEMORY:-1] -----END RSA PRIVATE KEY----- Lovely. So I now do a memdump of process 123: $ python vol.py -f memory.dmp --profile=WinXPSP2x86 memdump --pid=123 --dump-dir=123 Volatility Foundation Volatility Framework 2.4 ************************************************************************ Writing myapp.exe [ 123] to 123.dmp However, if I search 123.dmp neither the BEGIN or END strings are present. So I thought I'd try and find it via the virtual address give, 0x75b6b4d8: $ python vol.py -f memory.dmp --profile=WinXPSP2x86 memmap --pid=123 Virtual Physical Size DumpFileOffset ---------- ---------- ---------- -------------- --SNIP-- 0x75b6b000 0x18de0000 0x1000 0x1a3000 --SNIP-- The text is indeed at 0x18de04d8 in memory.dmp, but not at 0x1a34d8 in 123.dmp. Again, it's no where to be found in 123.dmp. Any suggestions..?? Many thanks, Adam

10 years, 1 month

3
7
0 0

The 2015 BSides New Orleans speaker lineup is out!

by Andrew Case

We are very excited to announce that the lineup for BSidesNOLA 2015 is out! The day will start with a keynote presentation from Chris Rohlf of Yahoo. It will then continue with three tracks of talks ranging from application security to memory forensics to malware analysis. These talks will be given by some of the best researchers in the forensics, incident response, and security fields. Full information on the conference can be found at the following page: http://www.securitybsides.com/w/page/91550808/BSidesNOLA%202015 The cost to attend is $10, and you must register through the EventBrite link ( https://www.eventbrite.com/e/bsides-nola-2015-tickets-9621601469 ). Last year was our second year and we had over 150 people attend. We are expecting closer to 200 this year. For those of you who attended last year, you know that beyond just great talks and networking, we also provide very good food and drinks. The close proximity to the French Quarter (5-10 minute walk) also means that after the conference there will be plenty of fun and interesting things to do for the rest of the night. We hope to see you there and if you have any questions please reply to this thread or email bsidesnola [@@] gmail.com. -- Thanks, Andrew (@attrc)

10 years, 1 month

1
0
0 0

Reston and NYC Volatility classes filling fast

by Andrew Case

Our public five day Windows memory forensic classes in Reston in April and NYC in May are filling fast. If you are looking to take the course in the US before winter then please contact us ASAP: http://www.memoryanalysis.net/#!memory-forensics-training/c1q3n -- Thanks, Andrew (@attrc)

10 years, 2 months

1
0
0 0

Blog post on using Volatility to find a keylogger (again)

by Bridgey theGeek

(Argh, sorry if you just received a messed email. Darn keyboard shortcuts. Anyway...) Hi all, CORPORATE BLOG WARNING! In case you were dozing and missed it, I posted a blog entry today on using Volatility in anger. I used it to analyse a hiberfil.sys and identify a few things about a keylogger that was running on a client's system. I tried to make it as detailed as possible, specifically around the Volatility commands I was using and why I chose them. http://ctx.is/thank-malware-T Andrew Case has already been kind enough to provide me with some feedback, which I shall take the liberty of sharing below: "When you ran dlldump to grab the WinInstall.dll you could have used '-b 0x000007fef5930000' to only get the DLL you wanted instead of all of them. That address comes from dlllist output and its where the DLL is loaded into memory." "For finding the service you could have tried the 'svcscan' plugin and if you do 'svcscan -v', it will list the path of the DLL or driver used to start the service. That is easier than searching through the registry." Thanks Andrew! Regards, Adam

10 years, 2 months

1
0
0 0

Re: [Vol-users] Problems with Win7SP1x64 hiberfil.sys

by Mike Auty

Also, Imageinfo correctly identified it as IA32PagedMemoryPae, and suggested Win7SP1x86, but it's easy to miss, just like everyone reading this thread (myself included). 5:) Mike 5:)

10 years, 2 months

2
1
0 0

Problems with Win7SP1x64 hiberfil.sys

by Bridgey theGeek

Hi all, Just trying to figure out where I'm going wrong. I have a hiberfil.sys file from a Win7SP1x64 system. The first 6 pages are full of 0x00 which I believe means the hiberfil was wiped as part of a resume. Having read the AOMF, specifically p98, I expected Volatility to brute force the header and, voila, magic happens. However, Volatility just reports that it wasn't able to find a matching address space: $ python vol.py -f /tmp/hiberfil.sys imageinfo Volatility Foundation Volatility Framework 2.4 Determining profile based on KDBG search... Suggested Profile(s) : No suggestion (Instantiated with Win7SP1x86) AS Layer1 : IA32PagedMemoryPae (Kernel AS) AS Layer2 : WindowsHiberFileSpace32 (Unnamed AS) AS Layer3 : FileAddressSpace (/tmp/hiberfil.sys) PAE type : PAE DTB : 0x185000L KDBG : 0x82d3ac28 Number of Processors : 4 Image Type (Service Pack) : 1 KPCR for CPU 0 : 0x82d3bc00 KPCR for CPU 1 : 0x807c6000 KPCR for CPU 2 : 0x8d300000 KPCR for CPU 3 : 0x8d336000 KUSER_SHARED_DATA : 0xffdf0000 Image date and time : 2014-05-09 15:26:28 UTC+0000 Image local date and time : 2014-05-09 17:26:28 +0200 $ python vol.py -f /tmp/hiberfil.sys --profile=Win7SP1x64 pslist Volatility Foundation Volatility Framework 2.4 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 WindowsCrashDumpSpace64: No base Address Space ... ... If I try an imagecopy, the output file is identical to the original: $ python vol.py -f /tmp/hiberfil.sys --profile=Win7SP1x64 imagecopy -O /tmp/hiberfil.bin Volatility Foundation Volatility Framework 2.4 Writing data (5.00 MB chunks): |.................................................................................................................................................................................................................................................................................................................................................................................................................................................................| bridgey@aspire:~/dev/volatility$ md5sum /tmp/hiberfil.* fee8a1c6924b871477434a678adb4483 /tmp/hiberfil.bin fee8a1c6924b871477434a678adb4483 /tmp/hiberfil.sys And finally, I couldn't find a class for 64-bit hiberfil... $ find -type f -name '*iber*' -exec grep -H ^class.WindowsHi {} \; ./volatility/plugins/addrspaces/hibernate.py:class WindowsHiberFileSpace32(addrspace.BaseAddressSpace): Am I leaping to conclusions, or is a hiberfil from a 64-bit system simply not supported? Would love any comments! Thanks, Adam

10 years, 2 months

3
3
0 0

New blog post on using bulk_extractor with memory forensics

by Andrew Case

Yesterday we published a new blog post on using bulk_extractor during memory forensics investigations. The writeup focused on the ability to create PCAP files of resident network data inside a memory capture. If you are not using this capability in your investigations then you are definitely missing out! http://volatility-labs.blogspot.com/2015/01/incorporating-disk-forensics-wi… -- Thanks, Andrew (@attrc)

10 years, 3 months

2
1
0 0

Announcing BSidesNOLA 2015!

by Andrew Case

We are pleased to announce that BSidesNOLA 2015 will take place on Saturday, May 30th in the heart of downtown New Orleans. Full details can be found on the following page: http://www.securitybsides.com/w/page/91550808/BSidesNOLA Our call for papers is currently open and we will be accepting submissions through March 1st. Please spend time on your CFP submission(s) as we receive a large number each year and inevitably have to reject some of them. If you look at our lineup from last year (http://www.securitybsides.com/w/page/71231585/BsidesNola2014) and the year before (http://www.securitybsides.com/w/page/62741761/BsidesNola) you will see that we attract some of the best speakers and researchers in the industry. You don't want to miss our speakers' party so send us your best stuff! Also, we are very excited to announce that Chris Rohlf will be keynoting this year. He has many years experience in the industry and is currently in charge of all penetration testing efforts inside of Yahoo. He will be speaking on performing offensive computer operations at scale. Please let us know if you have any questions, and if you plan to attend you must register on the Eventbrite page! -- Thanks, Andrew (@attrc)

10 years, 3 months

1
0
0 0

2015 DFRWS GPU memory challenge

by Andrew Case

Was writing to let everyone know that the DFRWS challenge is out for this year and it involves analyzing both a usual linux memory sample as well as analyzing GPU memory from a nvidia device. The challenge's creator worked with nvidia to have an acquisition tool capable of getting the memory off the devices. The latest git version of Volatility can analyze the Linux side, but the real purpose of the challenge is to encourage memory forensics research against the GPU. Hoping for some exciting results from it! http://www.cs.uno.edu/~golden/gpu-malware-research.html -- Thanks, Andrew (@attrc)

10 years, 3 months

1
0
0 0

ShmooCon

by AAron Walters

vol-users, If anyone is planning to attend ShmooCon today and wants to meet up, please send me a note offlist. We can discuss features you would like to see integrated into future releases, the benefits of Volatility training, half-baked anti-forensics schemes, why Andrew only drinks Champagne, and where we are headed with Volatility 3.0! AAron Walters The Volatility Foundation

10 years, 3 months

1
0
0 0

Memory Forensics Training in Ottawa, Canada

by Michael Ligh

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi folks, Sorry for the short notice. We have 4 seats available for our Malware and Memory Forensics Training class in Ottawa in February. Send me a note if you're interested. It will probably be the only time we're in Canada in 2015. Cheers! MHL -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iF4EAREKAAYFAlS0MwUACgkQXnt9v1O0LItfcAD+O6PZ8v4/nowcwbW3z8SCNMf1 KUXdE4fFu5jEUivfJYIA/0DzpkzsaViQ//bwuRse3kKGnrAmTwKVFpfZMJiAWO8j =N5qi -----END PGP SIGNATURE-----

10 years, 3 months

1
0
0 0

Getting Error on Ubuntu 14.04 when I attempt Netscan

by Gibson, Ryan

WARNING : volatility.obj : NoneObject as string: Pointer Owner invalid I saw some people also having the same issues, but I am not seeing the fix anywhere. Suggestions?

10 years, 3 months

3
2
0 0

Re: Centos 6.5 2.6.32-431.17.1 64 bit linux profile?

by Jesse Bowling

Imagine my chagrin to find that the new volatility site contains exactly what I proposed below. Mea culpa for referencing old directions and code... :-/ For those that come after me, take a look at https://github.com/volatilityfoundation/volatility/wiki/Linux and specifically: "You can find a repository of pre-built profiles at the volatilityfoundation/profiles Github.” Cheers, Jesse On Dec 29, 2014, at 7:32 PM, Jesse Bowling <jessebowling(a)gmail.com> wrote: > Hello, > > Hoping someone on the list has a profile for Centos 6.5 running a 2.6.32-431.17.1.el6.x86_64 kernel they wouldn’t mind sharing...It’s a non-standard thing for my environment, so I don’t have a similar box to build from (and am hoping to save the time of building a machine just for this)... > > Tangential to this, are there any repositories of Volatility profiles for Linux? I noticed Ken Pryor’s Github repo which seems like a great idea (and platform) for this, however he only has a few Ubuntu versions and it doesn’t look like it’s been updated in a while...Any interest from the Volatility team in starting something similar (if it’s not already happening and I just don’t know about it)? > > Cheers, > > Jesse

10 years, 4 months

1
0
0 0

Re: [Vol-users] Trick to getting xlsx output

by Jamie Levy

Hi James, I have updated timeliner to work with the new OpenPyxl API. Just for reference, my install is from [1]. In addition to this, I have also added xlsx output as a renderer for the unified output [2]. So you should be able to get xlsx output from any plugin that has already been converted. You can see which plugins have this support by using the --help/-h switch. For example: $ python vol.py -f mem.img pslist --help [snip] Module Output Options: dot, html, json, quicktext, sqlite, text, xlsx [snip] $ python vol.py -f mem.img pslist --output=xlsx --output-file=pslist.xlsx All the best, -Jamie [1] https://pypi.python.org/pypi/openpyxl [2] https://github.com/volatilityfoundation/volatility/commit/c4a9a732c9411e7b0… On 12/19/14 7:40 AM, James Lay wrote: > On Fri, 2014-12-19 at 03:01 +0000, Jamie Levy wrote: >> OpenPyxl just changed their API and it is no longer compatible. I am in the process of fixing the timeliner plugin to use the new API. >> >> Also, the excel output for psxview has already been converted to the new API. >> >> All the best, >> >> -Jamie >> >> >> >> ------Original Message------ >> From: James Lay >> Sender: vol-users-bounces(a)volatilityfoundation.org <mailto:vol-users-bounces@volatilityfoundation.org> >> To: Volatility >> ReplyTo: jlay(a)slave-tothe-box.net <mailto:jlay@slave-tothe-box.net> >> Subject: [Vol-users] Trick to getting xlsx output >> Sent: Dec 18, 2014 6:27 PM >> >> Hey all, >> >> Using 2.4...not able to get xlsx output...greeted with: >> >> Volatility Foundation Volatility Framework 2.4 >> ERROR : volatility.plugins.timeliner: You must install OpenPyxl for >> xlsx format: >> https://bitbucket.org/ericgazoni/openpyxl/wiki/Home >> >> My install method for volatility was download, extract, move to >> /opt/volatility, and python vol.py from there. >> My install method for openpyxl was: >> >> hg clone https://bitbucket.org/openpyxl/openpyxl >> cd openpyxl >> python setup.py build >> sudo python setup.py install >> >> Is there anything else I need to check? I see a slew of items in: >> >> /usr/local/lib/python2.7/dist-packages/openpyxl-2.1.4-py2.7.egg/ >> >> Thank you. >> >> James >> _______________________________________________ >> Vol-users mailing list >> Vol-users(a)volatilityfoundation.org <mailto:Vol-users@volatilityfoundation.org> >> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users >> > > Awesome....looking forward to it...thank you. > > James -- Jamie Levy (@gleeda) Blog: http://volatility-labs.blogspot.com/ GPG: http://pgp.mit.edu/pks/lookup?op=get&search=0x196B2AB527A4AC92 Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92

10 years, 4 months

1
0
0 0

31C3

by Philip Huppert

Hi, are there any Volatility users attending 31C3? How about a meetup? Regards, Philip

10 years, 4 months

3
3
0 0

Re: [Vol-users] Trick to getting xlsx output

by Jamie Levy

OpenPyxl just changed their API and it is no longer compatible. I am in the process of fixing the timeliner plugin to use the new API. Also, the excel output for psxview has already been converted to the new API. All the best, -Jamie ------Original Message------ From: James Lay Sender: vol-users-bounces(a)volatilesystems.com To: Volatility ReplyTo: jlay(a)slave-tothe-box.net Subject: [Vol-users] Trick to getting xlsx output Sent: Dec 18, 2014 6:27 PM Hey all, Using 2.4...not able to get xlsx output...greeted with: Volatility Foundation Volatility Framework 2.4 ERROR : volatility.plugins.timeliner: You must install OpenPyxl for xlsx format: https://bitbucket.org/ericgazoni/openpyxl/wiki/Home My install method for volatility was download, extract, move to /opt/volatility, and python vol.py from there. My install method for openpyxl was: hg clone https://bitbucket.org/openpyxl/openpyxl cd openpyxl python setup.py build sudo python setup.py install Is there anything else I need to check? I see a slew of items in: /usr/local/lib/python2.7/dist-packages/openpyxl-2.1.4-py2.7.egg/ Thank you. James _______________________________________________ Vol-users mailing list Vol-users(a)volatilesystems.com http://lists.volatilesystems.com/mailman/listinfo/vol-users

10 years, 4 months

1
0
0 0

Trick to getting xlsx output

by James Lay

Hey all, Using 2.4...not able to get xlsx output...greeted with: Volatility Foundation Volatility Framework 2.4 ERROR : volatility.plugins.timeliner: You must install OpenPyxl for xlsx format: https://bitbucket.org/ericgazoni/openpyxl/wiki/Home My install method for volatility was download, extract, move to /opt/volatility, and python vol.py from there. My install method for openpyxl was: hg clone https://bitbucket.org/openpyxl/openpyxl cd openpyxl python setup.py build sudo python setup.py install Is there anything else I need to check? I see a slew of items in: /usr/local/lib/python2.7/dist-packages/openpyxl-2.1.4-py2.7.egg/ Thank you. James

10 years, 4 months

1
0
0 0

Process unable to be extracted

by Dave Nardoni

I have some processes listed in pslist and psscan that are unable to be dumped using procdump by either the pid or the offset. Are there other approaches that can be used to dump these processes? Not in front of computer right now but error was something like unable to parse the peb. I can get the exact error message later if it helps. All other plugins work just find so memory image is not in question. Sent from my iPhone Dnardoni(a)gmail.com

10 years, 4 months

2
1
0 0

Problem regarding running volatility

by Mohammad-Reza Memarian

Ciao Guys I want to use from volatility to analyze a linux memory data. So I created a profile of that kernel, transfered it to volatility directory on my computer, now I want to run the plugins but I can not run any of the plugins as It throughs various errors in one case pslist there is no output, other cases it says the command is not suppoerted for this profile, did anyone had the same experience? Regards Reza

10 years, 4 months

3
2
0 0

Join us on Monday for an Art of Memory Forensics Reddit AMA

by Andrew Case

We are excited to announce that on next Monday, December 15th, from 9AM-11AM PST, the Art of Memory Forensics authors will be doing an AMA (Ask Me Anything) on Reddit's netsec. This is a chance to ask us non-technical questions, comment on or ask about the book, or anything else related to Volatility and memory forensics. The last book AMA on Reddit was for the Android Hacker's Handbook and it will really well with over 300 comments ( https://www.reddit.com/r/netsec/comments/27zdxc/android_hackers_handbook_ama ) . We are hoping to have ours be big as well so please try to attend and spread the word! -- Thanks, Andrew (@attrc)

10 years, 4 months

1
0
0 0

Strange results

by James Lay

So here's what I got all...an image of a laptop running Windows 7 64 bit...image was captured using DumpIt in an admin console: Determining profile based on KDBG search... Suggested Profile(s) : Win7SP0x64, Win7SP1x64, Win2008R2SP0x64, Win2008R2SP1x64 AS Layer1 : AMD64PagedMemory (Kernel AS) AS Layer2 : FileAddressSpace (/home/jlay/Forensics/FMCCOMBS-20141203-153133.raw) PAE type : No PAE DTB : 0x187000L KDBG : 0x1b430010a0 Number of Processors : 1 Image Type (Service Pack) : 1 KPCR for CPU 0 : 0xfffff80003002d00L KUSER_SHARED_DATA : 0xfffff78000000000L Image date and time : 2014-12-03 15:31:47 UTC+0000 Image local date and time : 2014-12-03 08:31:47 -0700 Running "python vol.py -f ~/Forensics/FMCCOMBS-20141203-153133.raw --profile Win7SP1x64 pslist" gets me: Offset(V) Name PID PPID Thds Hnds Sess Wow64 Start Exit 0xfffffa800694ab30 System 4 0 141 -1 1191132111 0 2014-12-01 15:40:49 UTC+0000 0xfffffa800ae934f0 ?b?_?b?_?b?_?b?_ 1606836934 1606836934 1606836934 -1 -1 1 - And that's it. Any hints on just why this isn't showing any processes? Volatility version is 2.4 running on Ubuntu 14 64 bit. Thank you. James

10 years, 4 months

3
2
0 0

Upcoming memory forensics trainings in SF, Reston, NY, and Amsterdam

by Andrew Case

We are happy to announce that we now have several 2015 public trainings scheduled across the USA as well as in Europe. Full details can be found at the following link: http://www.memoryanalysis.net/#!memory-forensics-training/c1q3n Our schedule for next year is getting pretty full so please contact ASAP if you are interested in a private training or us hosting a public training in your area. -- Thanks, Andrew (@attrc)

10 years, 5 months

1
0
0 0

My presentation on analyzing Careto with Volatility is now online

by Andrew Case

Link: http://2014.video.sector.ca/video/110388398 In the presentation I give an introduction to memory forensics and then spend the rest of the time looking at Careto through the eyes of memory forensics. Careto went undetected for over 7 years by the AV industry, but in the talk you can see that memory forensics finds it over and over again in only a few minutes. PS: I gave a focused and more in-depth version of this talk at OMFW (without the intro and hunting parts) -- Thanks, Andrew (@attrc)

10 years, 5 months

1
0
0 0

The results of the 2014 Volatility plugin contest are now available!

by Andrew Case

We are happy to announce that the results of the 2014 Volatility plugin contest are now available: http://volatility-labs.blogspot.com/2014/10/announcing-2014-volatility-plug… Congrats to the winners and we would like to again thank Facebook for their donation that doubled the contest's prize money! -- Thanks, Andrew (@attrc)

10 years, 6 months

1
0
0 0

RE: [Detailed analysis of Kaspersky hooks including analysis....

by Michael Chaves

I've used malfind and memscan on a suspected POS infected system and I get a ton of false positive hits on AV processes. Any way to white list some of these or use --silent to filter out some of these false positives? On the other side, is it likely malware is using AV processes to do their deed? Mike Det. Michael Chaves Monroe Police Department 7 Fan Hill Road Monroe, CT 06468 203.452.2831 x1307 (desk) 203.261.3622 (w) 203.650.7997 (c) *** NOTE: If you are sending me an attachment, rename the extension to .txt or .jpg, otherwise, due to filters, I will not get it *** -----Original Message----- From: vol-users-bounces(a)volatilityfoundation.org [mailto:vol-users-bounces@volatilityfoundation.org] On Behalf Of vol-users-request(a)volatilityfoundation.org Sent: Tuesday, October 28, 2014 1:00 PM To: vol-users(a)volatilityfoundation.org Subject: [BULK] Vol-users Digest, Vol 76, Issue 6 Send Vol-users mailing list submissions to vol-users(a)volatilityfoundation.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.volatilityfoundation.org/mailman/listinfo/vol-users or, via email, send a message with subject or body 'help' to vol-users-request(a)volatilityfoundation.org You can reach the person managing the list at vol-users-owner(a)volatilityfoundation.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Vol-users digest..." Today's Topics: 1. Detailed analysis of Kaspersky hooks including analysis with Volatility (Andrew Case) ---------------------------------------------------------------------- Message: 1 Date: Tue, 28 Oct 2014 02:16:58 -0500 From: Andrew Case <atcuno(a)gmail.com> Subject: [Vol-users] Detailed analysis of Kaspersky hooks including analysis with Volatility To: "'vol-users(a)volatilityfoundation.org'" <vol-users(a)volatilityfoundation.org> Message-ID: <544F42EA.9020500(a)gmail.com> Content-Type: text/plain; charset=ISO-8859-1 A really well done writeup & analysis: https://quequero.org/2014/10/kaspersky-hooking-engine-analysis/ -- Thanks, Andrew (@attrc) ------------------------------ _______________________________________________ Vol-users mailing list Vol-users(a)volatilityfoundation.org http://lists.volatilityfoundation.org/mailman/listinfo/vol-users End of Vol-users Digest, Vol 76, Issue 6 ****************************************

10 years, 6 months

2
1
0 0

LiME and Intel Atom (x86) AVD

by masdif

Hi, I'm trying to compile LiME for a given Android Virtual Device (AVD) Platform 4.4.2 API Level 19 CPU Intel Atom (x86) I have no information about how the AVD was created. Does in this case investigation with LiME/Volatility make sense at all? Should LiME be able to handle the Atom-Processor? If yes: Should Volatility be able to handle the LiME dump? If any answer up to now was no: No further reading necessary. :-( But please enlighten me. ;-) If this in principle is not an impossible plan then how do I have to handle the following warnings/errors? (a) LiME compiles but gives me a WARNING: Symbol version dump ~/android/kernel/goldfish/Module.symvers is missing; modules will have no dependencies and modversions. (b) insmod fails insmod: init_module '/sdcard/lime.ko' failed (No such file or directory) (but of course there is a '/sdcard/lime.ko') (c) dmesg reports lime: Unknown symbol _GLOBAL_OFFSET_TABLE_ (err 0) lime: Unknown symbol kmap (err 0) lime: Unknown symbol kunmap (err 0) Is it correct to expect, that (b) and (c) are a result from (a)? What is to be done? Compiling the kernel and hope the Module.symvers fits to the AVD symbols? The LiME documentation does not mention a need for compiling the Android kernel. Or do I have to work on the kernel's .config? As always there is no /proc/config.gz on the phone/AVD. (At least I have not seen any /proc/config.gz on my devices so far.) Instead in this case I worked on the goldfish/arch/x86/configs/i386_defconfig until the AVD accepted the version magic. Just in case it is useful, here is in detail what I did so far: ________________________________________ ### the AVD ### cat /proc/version Linux version 3.4.0+ (nnk(a)nnk.mtv.corp.google.com) (gcc version 4.7 (GCC) ) #1 PREEMPT Wed Jul 10 09:55:37 PDT 2013 ________________________________________ ### Goldfish kernel 3.4.0+ for LiME compilation ### $ mkdir -p ~/android/kernel && cd $_ $ git clone https://android.googlesource.com/kernel/goldfish.git $ cd goldfish $ git branch -a $ git checkout origin/android-goldfish-3.4 -b goldfish-3.4 $ git log --pretty=oneline | grep -i 'linux 3.4$' $ git checkout 76e10d1 -b goldfish-3.4-76e10d1 $ cp arch/x86/configs/i386_defconfig .config ________________________________________ ### modify .config in order to get correct version ### ### magic: '3.4.0+ preempt mod_unload CORE2 ' ### $ diff arch/x86/configs/i386_defconfig .config 39c39,41 < CONFIG_SMP=y --- > CONFIG_SMP=n > CONFIG_MCORE2=y > CONFIG_PREEMPT=y 43c45 < CONFIG_PREEMPT_VOLUNTARY=y --- > CONFIG_PREEMPT_VOLUNTARY=n ________________________________________ ### prepare kernel for module compilation ### $ make ARCH=x86 CROSS_COMPILE=~/android/ndk/toolchains/ x86-4.9/prebuilt/linux-x86_64/bin/i686-linux-android- modules_prepare ________________________________________ ### LiME Makefile ### obj-m := lime.o lime-objs := tcp.o disk.o main.o KDIR_GOLD := ~/android/kernel/goldfish/ CCPATH := ~/android/ndk/toolchains/x86-4.9/prebuilt/linux-x86_64/bin PWD := $(shell pwd) default: # cross-compile for Android emulator $(MAKE) ARCH=x86 CROSS_COMPILE=$(CCPATH)/i686-linux-android- -C $(KDIR_GOLD) M=$(PWD) modules $(CCPATH)/i686-linux-android-strip --strip-unneeded lime.ko mv lime.ko lime-goldfish.ko $(MAKE) tidy tidy: rm -f *.o *.mod.c Module.symvers Module.markers modules.order \.*.o.cmd \.*.ko.cmd \.*.o.d rm -rf \.tmp_versions clean: $(MAKE) tidy rm -f *.ko ________________________________________ Thanks, Philipp

10 years, 6 months

1
0
0 0

Detailed analysis of Kaspersky hooks including analysis with Volatility

by Andrew Case

A really well done writeup & analysis: https://quequero.org/2014/10/kaspersky-hooking-engine-analysis/ -- Thanks, Andrew (@attrc)

10 years, 6 months

1
0
0 0

Working of ldrmodules ?

by Jamison Bosco

Hello Group, So am not sure, if I understood, the working of ldrmodules correctly, but in short, for each process, I imagine it looks at the VAD; and for each dll found there compares it with the 3 lists in the process PEB and reports back on any discrepancy. A snippet, from vadinfo for a process with pid 12128, I can see a dll mapped VAD node @ 0xfffffa80088378c0 Start 0x0000000000040000 End 0x0000000000040fff Tag Vad Flags: Protection: 7, VadType: 2 Protection: PAGE_EXECUTE_WRITECOPY Vad Type: VadImageMap ControlArea @fffffa8006a86c40 Segment fffff8a00021d4e0 Dereference list: Flink 00000000, Blink 00000000 NumberOfSectionReferences: 1 NumberOfPfnReferences: 1 NumberOfMappedViews: 119 NumberOfUserReferences: 120 WaitingForDeletion Event: 00000000 Control Flags: File: 1, Image: 1 FileObject @fffffa80069c5250, Name: \Windows\System32\apisetschema.dll First prototype PTE: fffff8a00021d5a8 Last contiguous PTE: fffffffffffffffc Flags2: Inherit: 1 But ldrmodules (or dlllist) over the image, does not show that dll. cat ldrmodules.txt | grep -i apiset cat dlllist.txt | grep -i apiset The process in question has a pid of 12128, so on a frequency count, there is a large discrepancy, that I don't understand why. cat ldrmodules.txt | grep 12128 | wc -l 54 cat vadinfo-12128.txt | grep dll | wc -l 130 Any pointers to a link I should read up on to understand the concepts here. Should not have ldrmodules, reported on all the dlls that were found as mapped files in the VAD ? Thanks, JB

10 years, 6 months

1
0
0 0

Mac sleepimage

by Jarle Thorsen

Does Volatility support the analysis of Mac /var/vm/sleepimage? I did not see it mentioned in "The Art of Memory Forensics", and I seem to have trouble even doing a simple mac_pslist against it... -- Jarle Thorsen

10 years, 6 months

1
0
0 0

Reminder: OMFW 2014 Registration Closes Oct 24

by AAron Walters

vol-users, The registration for the Open Memory Forensics Workshop (OMFW) 2014 closes on Oct 24. If you are still planning to attend, I recommend sending a request as soon as possible. There are less than 10 open seats remaining! For those who have already requested an invitation, please let us know if you have not received your registration details. Reserve your seat by sending an email to info [at] volatilityfoundation.org or using the contact form on the Foundation's website. Thanks, The Volatility Foundation www.volatilityfoundation.org

10 years, 6 months

1
0
0 0

AttributeError: 'linux_mount' object has no attribute 'parse_mnt' error when trying to list tmpfs in Linux/Windows using Volatility 2.4

by Srinivasan J

Hi, I am trying to recover tmpfs from a RAM lime dump using volatility 2.4 in Linux/Windows, but I hit the "AttributeError: 'linux_mount' object has no attribute 'parse_mnt'". Is this a known issue? Thanks, Srini [srini@localhost volatility-2.4]$ python /home/srini/vola/setup/volatility-2.4/vol.py --plugins=/mnt/data/home/srini/ovf --profile=Linuxcentos7x64 -f /mnt/data/home/srini/ovf/ramtmpfs.lime linux_tmpfs -L Volatility Foundation Volatility Framework 2.4 Traceback (most recent call last): File "/home/srini/vola/setup/volatility-2.4/vol.py", line 192, in <module> main() File "/home/srini/vola/setup/volatility-2.4/vol.py", line 183, in main command.execute() File "/home/srini/vola/setup/volatility-2.4/volatility/plugins/linux/common.py", line 62, in execute commands.Command.execute(self, *args, **kwargs) File "/home/srini/vola/setup/volatility-2.4/volatility/commands.py", line 127, in execute func(outfd, data) File "/home/srini/vola/setup/volatility-2.4/volatility/plugins/linux/tmpfs.py", line 157, in render_text for (i, path) in data: File "/home/srini/vola/setup/volatility-2.4/volatility/plugins/linux/tmpfs.py", line 148, in calculate tmpfs_sbs = self.get_tmpfs_sbs() File "/home/srini/vola/setup/volatility-2.4/volatility/plugins/linux/tmpfs.py", line 120, in get_tmpfs_sbs for (sb, _dev_name, path, fstype, _rr, _mnt_string) in linux_mount.linux_mount(self._config).parse_mnt(mnts): AttributeError: 'linux_mount' object has no attribute 'parse_mnt' C:\Users\sjayarajan\Downloads\volatility_2.4.win.standalone\volatility_2.4.win.s tandalone> C:\Users\sjayarajan\Downloads\volatility_2.4.win.standalone\volatility_2.4.win.s tandalone>volatility-2.4.standalone.exe --plugins=profile --profile=Linuxcentos7 x64 -f D:\volat\ramtmpfs.lime linux_tmpfs -L Volatility Foundation Volatility Framework 2.4 Traceback (most recent call last): File "<string>", line 192, in <module> File "<string>", line 183, in main File "C:\volatility\build\pyinstaller\out00-PYZ.pyz\volatility.plugins.linux.c ommon", line 62, in execute File "C:\volatility\build\pyinstaller\out00-PYZ.pyz\volatility.commands", line 127, in execute File "C:\volatility\build\pyinstaller\out00-PYZ.pyz\volatility.plugins.linux.t mpfs", line 157, in render_text File "C:\volatility\build\pyinstaller\out00-PYZ.pyz\volatility.plugins.linux.t mpfs", line 148, in calculate File "C:\volatility\build\pyinstaller\out00-PYZ.pyz\volatility.plugins.linux.t mpfs", line 120, in get_tmpfs_sbs AttributeError: 'linux_mount' object has no attribute 'parse_mnt' C:\Users\sjayarajan\Downloads\volatility_2.4.win.standalone\volatility_2.4.win.s tandalone>volatility-2.4.standalone.exe --plugins=profile --profile=Linuxcentos7 x64 -f D:\volat\ramtmpfs.lime linux_cpuinfo Volatility Foundation Volatility Framework 2.4 Processor Vendor Model ------------ ---------------- ----- 0 GenuineIntel Intel(R) Xeon(R) CPU E5-2609 v2 @ 2.50GHz C:\Users\sjayarajan\Downloads\volatility_2.4.win.standalone\volatility_2.4.win.s tandalone> [srini@localhost volatility-2.4]$ python /home/srini/vola/setup/volatility-2.4/vol.py --plugins=/mnt/data/home/srini/ovf --profile=Linuxcent os7x64 --info | more Volatility Foundation Volatility Framework 2.4 Profiles -------- Linuxcentos7x64 - A Profile for Linux centos7 x64 VistaSP0x64 - A Profile for Windows Vista SP0 x64 VistaSP0x86 - A Profile for Windows Vista SP0 x86 VistaSP1x64 - A Profile for Windows Vista SP1 x64 VistaSP1x86 - A Profile for Windows Vista SP1 x86 VistaSP2x64 - A Profile for Windows Vista SP2 x64 VistaSP2x86 - A Profile for Windows Vista SP2 x86 [srini@localhost volatility-2.4]$ python /home/srini/vola/setup/volatility-2.4/vol.py --plugins=/mnt/data/home/srini/ovf --profile=Linuxcentos7x64 -f /mnt/data/home/srini/ovf/ramtmpfs.lime linux_cpuinfo Volatility Foundation Volatility Framework 2.4 Processor Vendor Model ------------ ---------------- ----- 0 GenuineIntel Intel(R) Xeon(R) CPU E5-2609 v2 @ 2.50GHz [srini@localhost volatility-2.4]$ python /home/srini/vola/setup/volatility-2.4/vol.py --plugins=/mnt/data/home/srini/ovf --profile=Linuxcentos7x64 -f /mnt/data/home/srini/ovf/ramtmpfs.lime linux_mount Volatility Foundation Volatility Framework 2.4 hugetlbfs /dev/hugepages hugetlbfs rw,relatime devtmpfs /dev devtmpfs rw,nosuid tmpfs /dev/shm tmpfs rw,nosuid,nodev devpts /dev/pts devpts rw,relatime,nosuid,noexec cgroup /sys/fs/cgroup/memory cgroup rw,relatime,nosuid,nodev,noexec tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec proc /proc proc rw,relatime,nosuid,nodev,noexec /dev/mapper/centos-root / xfs rw,relatime tmpfs /run tmpfs rw,nosuid,nodev sysfs /sys sysfs rw,relatime,nosuid,nodev,noexec sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime mqueue /dev/mqueue mqueue rw,relatime debugfs /sys/kernel/debug debugfs rw,relatime selinuxfs /sys/fs/selinux selinuxfs rw,relatime securityfs /sys/kernel/security securityfs rw,relatime,nosuid,nodev,noexec cgroup /sys/fs/cgroup/systemd cgroup rw,relatime,nosuid,nodev,noexec pstore /sys/fs/pstore pstore rw,relatime,nosuid,nodev,noexec cgroup /sys/fs/cgroup/cpuset cgroup rw,relatime,nosuid,nodev,noexec sunrpc /proc/fs/nfsd nfsd rw,relatime tmpfs /mnt/ramdisk tmpfs rw,relatime cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,relatime,nosuid,nodev,noexec configfs /sys/kernel/config configfs rw,relatime cgroup /sys/fs/cgroup/devices cgroup rw,relatime,nosuid,nodev,noexec systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime cgroup /sys/fs/cgroup/freezer cgroup rw,relatime,nosuid,nodev,noexec cgroup /sys/fs/cgroup/net_cls cgroup rw,relatime,nosuid,nodev,noexec cgroup /sys/fs/cgroup/blkio cgroup rw,relatime,nosuid,nodev,noexec /dev/sda1 /boot xfs rw,relatime cgroup /sys/fs/cgroup/perf_event cgroup rw,relatime,nosuid,nodev,noexec cgroup /sys/fs/cgroup/hugetlb cgroup rw,relatime,nosuid,nodev,noexec [srini@localhost volatility-2.4]$ python /home/srini/vola/setup/volatility-2.4/vol.py --plugins=/mnt/data/home/srini/ovf --profile=Linuxcent os7x64 -f /mnt/data/home/srini/ovf/ramtmpfs.lime linux_bash Volatility Foundation Volatility Framework 2.4 Pid Name Command Time Command -------- -------------------- ------------------------------ ------- 15151 bash 2014-10-12 01:35:58 UTC+0000 ./configure 15151 bash 2014-10-12 01:35:58 UTC+0000 yum provides tcpsic 15151 bash 2014-10-12 01:35:58 UTC+0000 ls -ltrh 15151 bash 2014-10-12 01:35:58 UTC+0000 mv lmbench3 lmbench3-3.10 15151 bash 2014-10-12 01:35:58 UTC+0000 ls 15151 bash 2014-10-12 01:35:58 UTC+0000 cd linux/ 15151 bash 2014-10-12 01:35:58 UTC+0000 yum intall isic 15151 bash 2014-10-12 01:35:58 UTC+0000 ls 15151 bash 2014-10-12 01:35:58 UTC+0000 yum provides dwarfdump 15151 bash 2014-10-12 01:35:58 UTC+0000 ls 15151 bash 2014-10-12 01:35:58 UTC+0000 ls 15151 bash 2014-10-12 01:35:58 UTC+0000 cd 3.10.0-123.el7.x86_64/ 15151 bash 2014-10-12 01:35:58 UTC+0000 uname -a 15151 bash 2014-10-12 01:35:58 UTC+0000 ls 15151 bash 2014-10-12 01:35:58 UTC+0000 yum install isic 15151 bash 2014-10-12 01:35:58 UTC+0000 cd linux/ 15151 bash 2014-10-12 01:35:58 UTC+0000 ls 15151 bash 2014-10-12 01:35:58 UTC+0000 ls 15151 bash 2014-10-12 01:35:58 UTC+0000 make 15151 bash 2014-10-12 01:35:58 UTC+0000 ifconfig 15151 bash 2014-10-12 01:35:58 UTC+0000 cd lmbench3-3.10

10 years, 6 months

2
2
0 0

New Memory Forensics & Malware Analysis trainings scheduled!

by Andrew Case

We are excited to announce that we now have public trainings scheduled through May of next year. Between now and then we will be visiting Austin (Dec.), San Francisco (Jan.), Brazil (Feb.), Reston, VA (April), and New York (May). A complete listing of course offerings and details can be found at: http://www.memoryanalysis.net/#!memory-forensics-training/c1q3n and: http://volatility-labs.blogspot.com/2014/10/windows-malware-and-memory-fore… Classes fill quickly so please contact us ASAP if you would like to attend! We offer discounts for LEO, government, and full time students as well as group rates for companies. -- Thanks, Andrew (@attrc)

10 years, 6 months

1
0
0 0

Android Analysis

by felipecboeira .

Hi all, I have acquired an android RAM image by using Lime and now I am using volatility to analyze it. I have created a profile and can now list processes, etc. What I need to do is inspect an integer array of a kernel module, which I have the address. I tried using volshell's dd() but I believe it is not showing the correct values. How can I certify that the virtual address is being calculated correctly by volatility? Thanks in advance, Felipe

10 years, 6 months

2
1
0 0

Error in mac_netstat & mac_arp

by Andre DiMino

I have a .vmem file from a Mac OS virtual machine. I'm using profile "MacMountainLion_10_8_2_AMDx64" Using Volatility 2.4, I'm able to run a few mac commands against this image, however I get traceback errors in the 'netstat' and 'arp' commands. I paste below: +++++++++++++++++++++++++++++++++++++++++ forensics@saturn:~/workspace/iworm/memory$ vol -f iworm_run1.vmem --profile=MacMountainLion_10_8_2_AMDx64 mac_ifconfig Volatility Foundation Volatility Framework 2.4 Interface Address ---------- ------- lo0 fe80:1::1 lo0 127.0.0.1 lo0 ::1 gif0 stf0 en0 00:0c:29:ea:9a:27 en0 fe80:4::20c:29ff:feea:9a27 en0 172.16.253.140 +++++++++++++++++++++++++++++++++++++++++ forensics@saturn:~/workspace/iworm/memory$ vol -f iworm_run1.vmem --profile=MacMountainLion_10_8_2_AMDx64 mac_version Volatility Foundation Volatility Framework 2.4 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 +++++++++++++++++++++++++++++++++++++++++ forensics@saturn:~/workspace/iworm/memory$ vol -f iworm_run1.vmem --profile=MacMountainLion_10_8_2_AMDx64 mac_netstat Volatility Foundation Volatility Framework 2.4 Proto Local IP Local Port Remote IP Remote Port State Process ------ -------------------- ---------- -------------------- ----------- -------------------- ------------------------ UNIX - UNIX /var/tmp/launchd/sock UNIX - UNIX /var/run/com.apple.ActivityMonitor.socket UNIX /var/run/mDNSResponder UNIX /var/rpc/ncacn_np/lsarpc UNIX /var/rpc/ncalrpc/lsarpc UNIX /var/rpc/ncacn_np/mdssvc UNIX /var/rpc/ncalrpc/NETLOGON UNIX /var/rpc/ncacn_np/srvsvc UNIX /var/rpc/ncalrpc/srvsvc UNIX /var/rpc/ncacn_np/wkssvc UNIX /var/rpc/ncalrpc/wkssvc Traceback (most recent call last): File "/home/forensics/programs/volatility-2.4/vol.py", line 192, in <module> main() File "/home/forensics/programs/volatility-2.4/vol.py", line 183, in main command.execute() File "/home/forensics/programs/volatility-2.4/volatility/plugins/mac/common.py", line 46, in execute commands.Command.execute(self, *args, **kwargs) File "/home/forensics/programs/volatility-2.4/volatility/commands.py", line 127, in execute func(outfd, data) File "/home/forensics/programs/volatility-2.4/volatility/plugins/mac/netstat.py", line 58, in render_text self.table_row(outfd, proto, lip, lport, rip, rport, state, "{}/{}".format(proc.p_comm, proc.p_pid)) ValueError: zero length field name in format +++++++++++++++++++++++++++++++++++++++++ forensics@saturn:~/workspace/iworm/memory$ vol -f iworm_run1.vmem --profile=MacMountainLion_10_8_2_AMDx64 mac_arp Volatility Foundation Volatility Framework 2.4 Source IP Dest. IP Name Sent Recv Time Exp. Delta ------------------------ ------------------------ ---------- ------------------ ------------------ ------------------------------ ---------- ----- Traceback (most recent call last): File "/home/forensics/programs/volatility-2.4/vol.py", line 192, in <module> main() File "/home/forensics/programs/volatility-2.4/vol.py", line 183, in main command.execute() File "/home/forensics/programs/volatility-2.4/volatility/plugins/mac/common.py", line 46, in execute commands.Command.execute(self, *args, **kwargs) File "/home/forensics/programs/volatility-2.4/volatility/commands.py", line 127, in execute func(outfd, data) File "/home/forensics/programs/volatility-2.4/volatility/plugins/mac/route.py", line 104, in render_text rt.name, File "/home/forensics/programs/volatility-2.4/volatility/obj.py", line 537, in __getattr__ return getattr(result, attr) File "/home/forensics/programs/volatility-2.4/volatility/plugins/overlays/mac/mac.py", line 562, in name return "{}{}".format(self.rt_ifp.if_name.dereference(), self.rt_ifp.if_unit) ValueError: zero length field name in format ++++++++++++++++++++++++++++++ Any thoughts or ideas are very appreciated! -- Andre' M. DiMino DeepEnd Research http://deependresearch.org http://sempersecurus.org "Make sure that nobody pays back wrong for wrong, but always try to be kind to each other and to everyone else" - 1 Thess 5:15 (NIV)

10 years, 6 months

2
2
0 0

Error with 2.4 Debian Wheezy

by Sean McLinden

I just build a VM with Debian (I needed to install other packages) and when I run this on a memory image I get the following (after about 10 minutes). The pslist.txt file is partially populated though how far it gets differs with each run. The box is Windows 7 Enterprise SP 1. The image was acquired using FTK. The box is believed to be infected with malware. user@host:/mnt/hgfs/288A-LV-2810395/Workspace/QJK1/memory# vol.py pslist > pslist.txt Volatility Foundation Volatility Framework 2.4 Traceback (most recent call last): File "/usr/local/bin/vol.py", line 192, in <module> main() File "/usr/local/bin/vol.py", line 183, in main command.execute() File "/usr/local/lib/python2.7/dist-packages/volatility/commands.py", line 127, in execute func(outfd, data) File "/usr/local/lib/python2.7/dist-packages/volatility/plugins/taskmods.py", line 178, in render_text str(task.ExitTime or ''), File "/usr/local/lib/python2.7/dist-packages/volatility/commands.py", line 219, in table_row outfd.write(self.tablesep.join(reslist) + "\n") IOError: [Errno 22] Invalid argument Thanks for any help. Sean McLinden

10 years, 7 months

2
2
0 0

conflicting argument

by A Musavi

Hi, I think there is still conflicting problem in vol 2.4: optparse.OptionConflictError: option -F/--filter: conflicting option string(s): -F

10 years, 7 months

2
1
0 0

failing to map address space for a dump/snapshot file created by libvirt command

by 谢志宇

Hi, everybody, I'm a new comer to volatility framework. At the same time, I am getting to work with libvirt library. I created a dump file named 'vm1_snapshot' by using libvirt command like 'virsh save domain'. In the domain ran the WinXPSP3x86. However, when I used 'python vol.py -f ~/vm1_snapshot --profile=WinXPSP3x86 pslist', the result showed as 'No suitable address space mapping found‍'. How could this happen? Is there anything wrong with the way the snapshot file was created? I hope some guy can do me a favor. ‍

10 years, 7 months

1
0
0 0

zeusscan2

by Bill Moylan

Testing zeusscan against a known zeus vmem sample, I am getting a segmentation fault. Other vol commands run and return results properly, and zeuscan appears to have compiled OK. No errors output except for the segmentation fault. Host OS is CentOS Linux 2.6, Volatility is 2.4. Zeus.vmem is WinXPSP2x86 Any ideas on troubleshooting? Bill

10 years, 7 months

2
1
0 0

OMFW 2014 Update & Dr. Brendan Dolan-Gavitt

by AAron Walters

vol-users, We are excited to announce that over half the seats for the Open Memory Forensics Workshop (OMFW) 2014 have already been reserved. It’s also great to see a large number of first time attendees from across government, academic, and commercial institutions. This is your one chance a year to hear about the latest research in memory forensics from the people who are pioneering the field. If you are still planning to attend, we suggest you register as soon as possible to make sure you have a seat. We are also excited to announce that Dr. Brendan Dolan Gavitt (moyix) will be speaking at the workshop. As many of you know, Brendan has been a member of the Volatility family since the very beginning and recently earned his PhD from the Georgia Institute of Technology. If you have followed Brendan’s work throughout the years and his new research with PANDA, I’m sure you will not be disappointed. In the upcoming weeks, we will continue finalizing and announcing the exciting roster of speakers. http://volatility.tumblr.com/post/97219909222/omfw-2014-update-dr-brendan-d… AW

10 years, 7 months

1
0
0 0

Having issues with linux profile -- please help

by Josh Horowitz

Dear Vol-users: First and foremost thanks to the creators of volatility for this amazing tool. I've been struggling to create a proper linux profile to analyze a memory dump from an Ubuntu 12.04.3 LTS machine created with fmem. The dump was split into several files which I combined using cat. I don't have access to the physical machine just some snapshot info, and have been trying to gather all the information I need in order to create the proper profile as follows: I grepped through /var/log/kern.log to find the kernel version that was running and got this: Linux version 3.2.0-53-generic (buildd@allspice) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #81-Ubuntu SMP Thu Aug 22 21:01:03 UTC 2013 (Ubuntu 3.2.0-53.81-generic 3.2.50) Also grep through kern.log for CPU and get: CPU0: Intel(R) Core(TM) i7-2675QM CPU @ 2.20GHz stepping 07 -- which I know to utilize 64-bit architecture. So to create the profile, I've installed a virtual machine running Ubuntu 12.04.3X64 and the identical kernel version: 3.2.0-53-generic. I have a different processor core on the virtual machine Im using to build the profile (Intel i5-4288U @ 2.60 GHZ, perhaps this is part of the problem?) I followed the instructions to a T on generating modules.dwarf using the included volatility toolset, copying the Systems.map file, zipping them together, etc. Run the required python vol.py --info | grep Linux Volatility Foundation Volatility Framework 2.4 Linux3_2_0-52-genericX_64x64 - A Profile for Linux 3.2.0-52-genericX_64 x64 Linux4cpuprofilex64 - A Profile for Linux 4cpuprofile x64 LinuxUbuntu12_04_3x86 - A Profile for Linux Ubuntu12_04_3 x86 LinuxUbuntu_12_04_3_X64x64 - A Profile for Linux Ubuntu_12_04_3_X64 x64 Linuxkernel-3_2_0-52-genericx86 - A Profile for Linux kernel-3.2.0-52-generic x86 and all seems well. (The LinuxUbuntu_12_04_3_X64x64 is for kernel 3.2.0-53-generic) Now when I run the following with -dd flag for debug I get the following (Sorry for length of debug msg) python vol.py -f memdump.dd --profile=LinuxUbuntu_12_04_3_X64x64 -dd linux_pslist Volatility Foundation Volatility Framework 2.4 DEBUG : volatility.plugins.overlays.linux.linux: Ubuntu_12_04_3_X64: Found dwarf file System.map-3.2.0-53-generic with 573 symbols DEBUG : volatility.plugins.overlays.linux.linux: Ubuntu_12_04_3_X64: Found system file System.map-3.2.0-53-generic with 1 symbols DEBUG : volatility.obj : Applying modification from BashHashTypes DEBUG : volatility.obj : Applying modification from BashTypes DEBUG : volatility.obj : Applying modification from BasicObjectClasses DEBUG : volatility.obj : Applying modification from ELF32Modification DEBUG : volatility.obj : Applying modification from ELF64Modification DEBUG : volatility.obj : Applying modification from ELFModification DEBUG : volatility.obj : Applying modification from HPAKVTypes DEBUG : volatility.obj : Applying modification from LimeTypes DEBUG : volatility.obj : Applying modification from LinuxTruecryptModification DEBUG : volatility.obj : Applying modification from MachoModification DEBUG : volatility.obj : Applying modification from MachoTypes DEBUG : volatility.obj : Applying modification from MbrObjectTypes DEBUG : volatility.obj : Applying modification from VMwareVTypesModification DEBUG : volatility.obj : Applying modification from VirtualBoxModification DEBUG : volatility.obj : Applying modification from LinuxIntelOverlay DEBUG : volatility.obj : Applying modification from LinuxKmemCacheOverlay DEBUG : volatility.plugins.overlays.linux.linux: Requested symbol cache_chain not found in module kernel DEBUG : volatility.obj : Applying modification from LinuxMountOverlay DEBUG : volatility.obj : Applying modification from LinuxObjectClasses DEBUG : volatility.obj : Applying modification from LinuxOverlay DEBUG : volatility.plugins.overlays.linux.linux: Ubuntu_12_04_3_X64: Found dwarf file System.map-3.2.0-53-generic with 573 symbols DEBUG : volatility.plugins.overlays.linux.linux: Ubuntu_12_04_3_X64: Found system file System.map-3.2.0-53-generic with 1 symbols DEBUG : volatility.obj : Applying modification from BashHashTypes DEBUG : volatility.obj : Applying modification from BashTypes DEBUG : volatility.obj : Applying modification from BasicObjectClasses DEBUG : volatility.obj : Applying modification from ELF32Modification DEBUG : volatility.obj : Applying modification from ELF64Modification DEBUG : volatility.obj : Applying modification from ELFModification DEBUG : volatility.obj : Applying modification from HPAKVTypes DEBUG : volatility.obj : Applying modification from LimeTypes DEBUG : volatility.obj : Applying modification from LinuxTruecryptModification DEBUG : volatility.obj : Applying modification from MachoModification DEBUG : volatility.obj : Applying modification from MachoTypes DEBUG : volatility.obj : Applying modification from MbrObjectTypes DEBUG : volatility.obj : Applying modification from VMwareVTypesModification DEBUG : volatility.obj : Applying modification from VirtualBoxModification DEBUG : volatility.obj : Applying modification from LinuxIntelOverlay DEBUG : volatility.obj : Applying modification from LinuxKmemCacheOverlay DEBUG : volatility.plugins.overlays.linux.linux: Requested symbol cache_chain not found in module kernel DEBUG : volatility.obj : Applying modification from LinuxMountOverlay DEBUG : volatility.obj : Applying modification from LinuxObjectClasses DEBUG : volatility.obj : Applying modification from LinuxOverlay Offset Name Pid Uid Gid DTB Start Time ------------------ -------------------- --------------- --------------- ------ ------------------ ---------- DEBUG : volatility.utils : Voting round DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating MachOAddressSpace: mac: need base DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating LimeAddressSpace: lime: need base DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'> DEBUG1 : volatility.utils : Failed instantiating WindowsHiberFileSpace32: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crashbmp.WindowsCrashDumpSpace64BitMap'> DEBUG1 : volatility.utils : Failed instantiating WindowsCrashDumpSpace64BitMap: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmem.VMWareMetaAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating VMWareMetaAddressSpace: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'> DEBUG1 : volatility.utils : Failed instantiating WindowsCrashDumpSpace64: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating HPAKAddressSpace: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.VirtualBoxCoreDumpElf64'> DEBUG1 : volatility.utils : Failed instantiating VirtualBoxCoreDumpElf64: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmware.VMWareAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating VMWareAddressSpace: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.QemuCoreDumpElf'> DEBUG1 : volatility.utils : Failed instantiating QemuCoreDumpElf: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'> DEBUG1 : volatility.utils : Failed instantiating WindowsCrashDumpSpace32: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'> DEBUG1 : volatility.utils : Failed instantiating AMD64PagedMemory: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'> DEBUG1 : volatility.utils : Failed instantiating IA32PagedMemoryPae: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemory'> DEBUG1 : volatility.utils : Failed instantiating IA32PagedMemory: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.osxpmemelf.OSXPmemELF'> DEBUG1 : volatility.utils : Failed instantiating OSXPmemELF: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.standard.FileAddressSpace'> DEBUG : volatility.utils : Succeeded instantiating <volatility.plugins.addrspaces.standard.FileAddressSpace object at 0x7fe1d90> DEBUG : volatility.utils : Voting round DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating MachOAddressSpace: MachO Header signature invalid DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating LimeAddressSpace: Invalid Lime header signature DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'> DEBUG1 : volatility.utils : Failed instantiating WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crashbmp.WindowsCrashDumpSpace64BitMap'> DEBUG1 : volatility.utils : Failed instantiating WindowsCrashDumpSpace64BitMap: Header signature invalid DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmem.VMWareMetaAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating VMWareMetaAddressSpace: VMware metadata file is not available DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'> DEBUG1 : volatility.utils : Failed instantiating WindowsCrashDumpSpace64: Header signature invalid DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating HPAKAddressSpace: Invalid magic found DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.VirtualBoxCoreDumpElf64'> DEBUG1 : volatility.utils : Failed instantiating VirtualBoxCoreDumpElf64: ELF Header signature invalid DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmware.VMWareAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating VMWareAddressSpace: Invalid VMware signature: 0xffffffff DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.QemuCoreDumpElf'> DEBUG1 : volatility.utils : Failed instantiating QemuCoreDumpElf: ELF Header signature invalid DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'> DEBUG1 : volatility.utils : Failed instantiating WindowsCrashDumpSpace32: Header signature invalid DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'> DEBUG1 : volatility.obj : None object instantiated: Unable to read_long_long_phys at 0xfffff8104eff0L DEBUG1 : volatility.utils : Failed instantiating AMD64PagedMemory: Failed valid Address Space check DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'> DEBUG1 : volatility.utils : Failed instantiating IA32PagedMemoryPae: Incompatible profile LinuxUbuntu_12_04_3_X64x64 selected DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemory'> DEBUG1 : volatility.utils : Failed instantiating IA32PagedMemory: Incompatible profile LinuxUbuntu_12_04_3_X64x64 selected DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.osxpmemelf.OSXPmemELF'> DEBUG1 : volatility.utils : Failed instantiating OSXPmemELF: ELF Header signature invalid DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.standard.FileAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating FileAddressSpace: Must be first Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.arm.ArmAddressSpace'> DEBUG1 : volatility.obj : None object instantiated: Could not read_long_phys at offset 0x3ffffffff070L DEBUG1 : volatility.obj : None object instantiated: Could not read_long_phys at offset 0x3ffffffff040L DEBUG1 : volatility.obj : None object instantiated: No suggestions available DEBUG1 : volatility.utils : Failed instantiating ArmAddressSpace: Failed valid Address Space check 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 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: PO_MEMORY_IMAGE is not available in profile WindowsCrashDumpSpace64BitMap: Header signature invalid VMWareMetaAddressSpace: VMware metadata file is not available WindowsCrashDumpSpace64: Header signature invalid HPAKAddressSpace: Invalid magic found VirtualBoxCoreDumpElf64: ELF Header signature invalid VMWareAddressSpace: Invalid VMware signature: 0xffffffff QemuCoreDumpElf: ELF Header signature invalid WindowsCrashDumpSpace32: Header signature invalid AMD64PagedMemory: Failed valid Address Space check IA32PagedMemoryPae: Incompatible profile LinuxUbuntu_12_04_3_X64x64 selected IA32PagedMemory: Incompatible profile LinuxUbuntu_12_04_3_X64x64 selected OSXPmemELF: ELF Header signature invalid FileAddressSpace: Must be first Address Space ArmAddressSpace: Failed valid Address Space check The error must have something to do with the way that I'm generating the profile (at least I think something is off) but I can't for the life of me figure out what the problem is. I truly appreciate any light that a vol expert out there may able to shed on what I need to do differently. Thanks very much.

10 years, 7 months

2
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Vol-users