Hi,
I've been unable to create a working Linux profile for any version of CentOS. It compiles fine but gives a 'No suitable address space mapping found' error when ran against the memory image.
I've been successful creating various Debian and Ubuntu profiles, but CentOS has yet to work. I'm sure it's something simple but I can't figure it out. I'm certain that I'm matching kernel versions correctly and that the build process is the same as I use for the Ubuntu versions.
I've attached the details of my most recent attempt. It's a vanilla CentOS 5.10 install on VmWare. The memory image is available (250Mb zip) if necessary.
Any ideas? None of the solutions I found in Google seem to address my issue.
Thanks,
Geoff
BTW - I'm not a kernel programmer so please be detailed if there's something you'd like me to try.
Hello list!
I'm currently looking into the way in which _FILE_OBJECTS are created and handled by Windows 7, and I'm a little bit confused over something I've observed.
When using notepad.exe to open a file, a file handle to the opened file never seems to get added to the object table within the _EPROCESS structure (monitored using SystemInternal's ProcExplorer). I believe this is because notepad does not leave the handle open, it simply opens the file, reads in the data, and then closes the file, without adding the file object to the handle table.
However, after opening the file, if I dump the memory of the system (this is being performed on a VM), and use Volaility's filescan to scan for all _FILE_OBJECTS, I see that there is indeed still a _FILE_OBJECT associated with the file I opened. However it's handle count is zero.
This makes sense, as with a handle count of zero, it shouldn't be listed in any of the handle tables for any processes. However, it's pointer, or reference count is still valid, often having 16 pointers.
My question is this, if the handle count is zero, but the pointer/reference count is still valid, where is this _FILE_OBJECT actually being stored? Is there some kind of kernel-based list/table that holds these open references? Or is this _FILE_OBJECT just floating around in some kind of cache, waiting to be destroyed?
Any input or advice would be greatly appreciated.
Thanks
Hi everyone,
I've got a snapshot from a Red Hat VM that I'd like to analyze. I've noticed that imagecopy is in the Windows section of the documentation. Is imagecopy supported for Linux snapshots?
Thanks,
Kasia Olejnik
I case anyone is interested I wrote a blog post of the memory analysis I
did on Jake Williams ADD tool he presented at Shmoocon. It can be found
here http://blog.handlerdiaries.com/?p=363
Thanks,
Jack Crook
Hello All,
I was poking around the reddits the other day and to my shock and utter dismay, I found no memory forensics subreddit. Soooooooo, I took it upon myself to create one. Volatility all the thingz!
http://www.reddit.com/r/memoryforensics/
Ryan Gibson
GCFA, GCIH, Security +
Office: 858-651-1689
Mobile: 619-804-8736
Senior IT Security Engineer
I'm dealing with what appears to be a new Zeus variant and on a whim I
tried to run zeusscan2 under a copy of Volatility 2.0 I still hang onto.
Perhaps not surprisingly, it ends unhappily
Volatile Systems Volatility Framework 2.0
Traceback (most recent call last):
File "vol.py", line 135, in <module>
main()
File "vol.py", line 126, in main
command.execute()
File "/home/a05p8zz/VolInstall/volatility-2.0/volatility/commands.py",
line 101, in execute
func(outfd, data)
File
"/home/a05p8zz/VolInstall/volatility-2.0/volatility/plugins/zeusscan2.py",
line 330, in render_text
for p, start, url, config_key, creds_key, decoded_config,
decoded_magic in data:
File
"/home/a05p8zz/VolInstall/volatility-2.0/volatility/plugins/zeusscan2.py",
line 221, in calculate
data = malware.get_vad_data(ps_ad, start, end)
File
"/home/a05p8zz/VolInstall/volatility-2.0/volatility/plugins/malware.py",
line 856, in get_vad_data
return ''.join(pages_one)
OverflowError: join() result is too long for a Python string
Now I strongly suspect that the new variant is just enough different that
it messes with the parsing and results in a runaway, but I just wanted to
make sure I'm not leaving something on the table here...
Should this work?
-=[ Steve ]=-
Stefan;
Soon as I get my hands on the disk image I will gladly do so.
-=[ Steve ]=-
>> Are you willing/able to share the md5 of that Zeus variant, please?
>> Cheers,
>> Stefan.
I have a memory dump of a Windows XP box with a piece of malware running in
it. In the course of running malfind on the image, there are eight
responses, two of which are below (A and B).
After the malfind command, I run the impscan command to look at the imports:
python vol.py impscan -p 820 -b 0x1f00000
python vol.py impscan -p 820 -b 0x01f50010
The response to the first impscan command is what I expected (see C
below). The response to the second impscan command (see D below) is not
what I expected at all - no imports?
I also ran impscan on the address 0x01f50012 based on the results from the
malfind command (see D below) as I figured that I wanted to dump the dll
starting on the beginning of the MZ header. But neither address produced
any imports - I'm not sure where to go from here.
I'm very new at this; any help would be greatly appreciated. My end goal
is to take this piece of malware, which looks to have injected several
dll's into a process, dump out each dll, then have them reverse engineered.
Thanks-
A.
Process: xxxxxx.exe Pid: 820 Address: 0x1f00000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 9, PrivateMemory: 1, Protection: 6
0x01f00000 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00
MZ..............
0x01f00010 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00
........@.......
0x01f00020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
0x01f00030 00 00 00 00 00 00 00 00 00 00 00 00 c8 00 00 00
................
0x1f00000 4d DEC EBP
0x1f00001 5a POP EDX
0x1f00002 90 NOP
0x1f00003 0003 ADD [EBX], AL
0x1f00005 0000 ADD [EAX], AL
0x1f00007 000400 ADD [EAX+EAX], AL
0x1f0000a 0000 ADD [EAX], AL
0x1f0000c ff DB 0xff
0x1f0000d ff00 INC DWORD [EAX]
0x1f0000f 00b800000000 ADD [EAX+0x0], BH
0x1f00015 0000 ADD [EAX], AL
0x1f00017 004000 ADD [EAX+0x0], AL
0x1f0001a 0000 ADD [EAX], AL
0x1f0001c 0000 ADD [EAX], AL
0x1f0001e 0000 ADD [EAX], AL
0x1f00020 0000 ADD [EAX], AL
0x1f00022 0000 ADD [EAX], AL
0x1f00024 0000 ADD [EAX], AL
0x1f00026 0000 ADD [EAX], AL
0x1f00028 0000 ADD [EAX], AL
0x1f0002a 0000 ADD [EAX], AL
0x1f0002c 0000 ADD [EAX], AL
0x1f0002e 0000 ADD [EAX], AL
0x1f00030 0000 ADD [EAX], AL
0x1f00032 0000 ADD [EAX], AL
0x1f00034 0000 ADD [EAX], AL
0x1f00036 0000 ADD [EAX], AL
0x1f00038 0000 ADD [EAX], AL
0x1f0003a 0000 ADD [EAX], AL
0x1f0003c c8000000 ENTER 0x0, 0x0
B.
Process: XXXXXX.exe Pid: 820 Address: 0x1f50000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 59, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01f50000 4c 1b cd 25 00 00 09 e8 16 4f 9e 7e cd 25 00 00
L..%.....O.~.%..
0x01f50010 00 00 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff
..MZ............
0x01f50020 00 00 b8 00 00 00 00 00 00 00 40 00 00 00 00 00
..........@.....
0x01f50030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
0x1f50000 4c DEC ESP
0x1f50001 1bcd SBB ECX, EBP
0x1f50003 25000009e8 AND EAX, 0xe8090000
0x1f50008 16 PUSH SS
0x1f50009 4f DEC EDI
0x1f5000a 9e SAHF
0x1f5000b 7ecd JLE 0x1f4ffda
0x1f5000d 2500000000 AND EAX, 0x0
*0x1f50012 4d DEC EBP0x1f50013 5a POP EDX*
0x1f50014 90 NOP
0x1f50015 0003 ADD [EBX], AL
0x1f50017 0000 ADD [EAX], AL
0x1f50019 000400 ADD [EAX+EAX], AL
0x1f5001c 0000 ADD [EAX], AL
0x1f5001e ff DB 0xff
0x1f5001f ff00 INC DWORD [EAX]
0x1f50021 00b800000000 ADD [EAX+0x0], BH
0x1f50027 0000 ADD [EAX], AL
0x1f50029 004000 ADD [EAX+0x0], AL
0x1f5002c 0000 ADD [EAX], AL
.................
................
C.
python vol.py impscan -p 9820 -b 0x01f00000
Volatility Foundation Volatility Framework 2.3.1
IAT Call Module Function
------------------ ------------------ -------------------- --------
0x0000000001f07d10 0x0000000076cf2c70 kernel32.dll HeapFree
0x0000000001f07d18 0x0000000076cf2d60 kernel32.dll GetProcessHeap
0x0000000001f07d20 0x0000000076e41b70 kernel32.dll HeapAlloc
D.
python vol.py impscan -p 820 -b 0x01f50010
Volatility Foundation Volatility Framework 2.3.1
IAT Call Module Function
------------------ ------------------ -------------------- --------
E.
python vol.py impscan -p 820 -b 0x01f50012
Volatility Foundation Volatility Framework 2.3.1
IAT Call Module Function
------------------ ------------------ -------------------- --------
Hi,
Happy New Year! :)
I tried to explore the contest plugin ethscan (latest release) on a few
different memory samples containing Mac OSX and Linux OS without success. Each
time I got an error message like:
ERROR : volatility.commands : This command does not support the profile
MacMountainLion_10_8_3_AMDx64
I'm using the correct OS profile, downloaded from the Volatility site
(MacProfilesAll.zip) and https://github.com/KDPryor/LinuxVolProfiles.
Other Volatility commands like mac_dmesg or linux_netstat does work correctly,
so the Profile should really match.
Volatility: current SVN revision 3573.
Memory samples from:
Mac OSX 10.8.3 x64 from Volatility download page
OSX 10.7.5 (not 10.7.3) from osxreverser, found on Twitter:
https://twitter.com/osxreverser/status/344521006288891905
Ubuntu 10.04
http://files.sempersecurus.org/dumps/memory/pexit.zip
found on this interesting blog:
http://sempersecurus.blogspot.de/2013/12/a-forensic-overview-of-linux-
perlbot.html
ethscan does work correctly when using different Windows dumps.
How can I fix this problem and get ethscan work also on OSX and Linux dumps?
Thanks!
Thomas
