search

pi-2r / volatility

Automatically exported from code.google.com/p/volatility
GNU General Public License v2.0
0 stars 0 forks source link

No output from linux_bash #447

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. python vol.py --profile=LinuxProfilex86 -f memory.img linux_bash -P -A

Have tried many permutations of the command, including using process ID and 
leaving out the -P and -A options 

What is the expected output? What do you see instead?

Expected output is bash process history.

Instead there is no output beyond:
WARNING : volatility.obj : Overlay structure tty_struct not present in vtypes
Pid      Name                 Command Time                   Command
-------- -------------------- ------------------------------ -------

What version of the product are you using? On what operating system?

Volatility Framework 2.3_beta.

Have tried on Windows 7 and various Linux distributions.

It is noted that other commands seem to work properly. Bash processes have not 
been renamed and can be seen by using linux_pslist and linux_pstree.

Original issue reported on code.google.com by freebs...@gmail.com on 20 Sep 2013 at 12:31

GoogleCodeExporter commented 9 years ago

Original comment by jamie.l...@gmail.com on 20 Sep 2013 at 2:21

GoogleCodeExporter commented 9 years ago 
I should have added the memory image was taken from the Linux BackTrack 4 R2 
distribution - the same distribution the profile was built on (obviously).

"uname -a" output:

Linux bt 2.6.35.8 #1 SMP Sun Nov 14 06:32:36 EST 2010 i686 GNU/Linux

I am currently trying to work through the bash.py file manually with volshell 
to see if I can find where my problem might lie. 

I can see the bash commands I am trying to find with linux_bash in the raw 
bytes when I search the memory image with a hexeditor.

Original comment by freebs...@gmail.com on 20 Sep 2013 at 6:08

GoogleCodeExporter commented 9 years ago 
Lets try to narrow it down to specifically the bash process. Can you run 
linux_proc_maps using the '-p' flag with the pid of one of the bash processes?

After doing that, do the following:

1) is the binary part /bin/bash or is it pointing at /bin/dash?

2) If it is pointing at /bin/bash can you then locate the starting address of 
the segment named "[heap]". This is the heap of the process and you can dump it 
to disk with "linux_dump_map -p <same pid as before> -s <starting address of 
heap> -D <output dir>". Then run strings/hexeditor on the resulting heap file 
and see if the commands appear. 

Please let us know if bash or dash and if bash what you see in the heap.

Thanks,
Andrew (@attrc)

Original comment by atc...@gmail.com on 20 Sep 2013 at 6:15

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
1) is the binary part /bin/bash or is it pointing at /bin/dash?

It is pointing at /bin/bash

2) ... dump it to disk with "linux_dump_map -p <same pid as before> -s 
<starting address of heap> -D <output dir>". Then run strings/hexeditor on the 
resulting heap file and see if the commands appear. 

I had already done this with each of the bash processes after reading the 
LinuxCommandReference23 page (which was very helpful and excellently described 
doing what you just said - thank you) and reading what bash.py was doing 
(scanning the heap of the processes). 

There is no output (all 0s).

Further investigation has shown me that yarascan was only finding the commands 
with the "--kernel" option set. I assume both this and the lack of heap data is 
telling me this dump is kernel memory only, or at least the bash sessions are 
only in kernel memory, not process memory.

(I did not make the memory image myself - it is part of an analysis for a 
professional Master's course.)

With all this in mind I am assuming linux_bash would obviously not work. IOW, 
my fault, not yours. Is this an accurate assessment?

Original comment by freebs...@gmail.com on 20 Sep 2013 at 8:14

GoogleCodeExporter commented 9 years ago 
You can consider this closed.

The fault was with me and (perhaps) the way the memory image was made (I think 
by using dd on /dev/mem).

All subsequent image captures made in other ways show that linux_bash is 
working properly.

I apologise for wasting your time. Next time I'll take it to the mailing list 
first .... however, I learned a massive amount.

Original comment by freebs...@gmail.com on 21 Sep 2013 at 9:26

GoogleCodeExporter commented 9 years ago

Original comment by michael.hale@gmail.com on 23 Sep 2013 at 4:33