On 2 May 1998, Eric Smith wrote:
> James Youngman <[EMAIL PROTECTED]> wrote about recovering the
> executable for a running process after the file it was run from has
> been removed:
>
> > ls -l /proc/429/exe
> > might say:-
> > blah blah .... exe -> [0806]:100075
> > Where 0806 is the device (in this case /dev/sda6) and the 100075 is
> > the inode. You should be able to track down the file with
> > find /usr -inum 100075 -print
> ...
> > If there is no name referring to that inode (i.e. the name has been
> > deleted), then you will need to create a link to that inode.
> ...
> > Basically, you run debugfs and use
>
> You could avoid the need to muck about with debugfs by doing something
> simpler:
>
> cp /proc/429/exe nasty-executable
>
> However, thanks to James' posting, I've learned more about debugfs. :-)
This method, however, has a severe drawback. Consider the following.
1. mkdir /somewhere/hacker_dir
2. cd /somewhere
3. ls
hacker_dir
4. insmod hacker.o
5. ls
6. notice that hacker_dir is now missing (I've seen it done)
7. cd /proc/pid
8. cp exe /tmp/nasty_exe
9. now you have a copy of the nasty exe file, but you still don't know
where it came from nor if there is anything else there
10. debugfs
11. ncheck <exe inode>
12. Now you have the full path name of the exe file, so now you can cd
to the dir where the executeable file is and see if anything else is
there (been there, done that, worth the effort, along with the exe
file I found kernel modules, hacked binaries, logs, etc).
Note: In my case, the pid for the hacker binary was unknown. The hacker.o
module not only hid the directory from the ls output (by filtering the
return value of readdir(), but also filtered the output of ps and the list
of directories in /proc so you couldn't find the pid. We found out the
pid number by the use of the alt-scrolllock key combo (I think that's
right, been about a year ago). That wasn't filtered and showed all
processes, which made it easy to say "Hey, pid x isn't in the output of ps
axf so that must be one of the hacker pids". Even though the ls output
didn't show /proc/pidx, we could still cd into the directory even though
it had been filtered from the output of the readdir() syscall, it wasn't
actually missing.
--------------------------------------
Doug Ledford <[EMAIL PROTECTED]>
Opinions expressed are my own, but
they should be everybody's.
--------------------------------------
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
