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
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
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)
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)
(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
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:)
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
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)
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)
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)
