I'm assuming you mean "fls" and not "fsd"?
fls checks the inode value though and won't print the name if the inode
is larger than the max inode, so I'm a little surprised in your case
that inode 14386 doesn't exist. What happens if you do an 'istat' on
it? What is the maximum inode for the file system (you can find out
using 'fsstat' if the other tools won't tell you)?
Just because different files are shown does not necessarily mean that it
is a problem since you are comparing code with different purposes.
readdir() is only supposed to show you allocated files. TSK wants to
show you everything that could be evidence and it is possible (and not
uncommon) to create directories with a name that is only a space or
control character and use it to hide files. There are also problems
sometimes when doing these types of things on a live system where some
data has not been flushed from the buffers.
Can you send me an example of the raw directory data and the 'fls'
output. For example, /etc/ntp. Find the inode for it and send me
(offline) the output of 'icat /dev/hda2 INUM > foo.dat' and 'fls
/dev/hda2 INUM'. No file content will be included in this data and I
can find out what a "(" name is being shown.
thanks,
brian
jisse wrote:
> Hi,
> I had the wonderful idea of cross-checking the files on a Ext2/Ext3
> filesystem seen by "fsd" with the files seen with a simple "readdir()"
> statement.
> The result was interesting: I found a lot of files that weren't supposed
> to be there.
>
> The command "fsd -rupfm / /dev/hda2" run on a default Fedora Core 5
> installation showed some weird entries that could not be seen by a
> "readdir()" in a Perl script. One of the entries was the following:
> 0|/etc/rc.d/init.d/^T|0|14386|0|-/----------|0|0|0|0|0|0|0|0|4096|0
> I had sent the output to a logfile, so I could determine that the
> filename was "/etc/rc.d/init.d/^T" were the "^T" was a control
> character. A simple "ls" of this file of course didn't show up.
>
> I opened up "debugfs" and did a "stat" on the file name: The file could
> not be found. Hmm, so 'fls' finds it and 'debugfs' does not? I checked
> the validity of the inode-number 14386 with "ncheck" and discovered
> "debugfs" could not find any inode with that number either. But still if
> I ran "fsd" again, the same file popped-up again.
>
> Other strange files included:
> /etc/pam.d/ (with a space as filename)
> /etc/ntp/(
>
> Any ideas?
>
> Regards,
>
> Jisse
>
> This mail signature is distributed under the GNU General Public License.
> For more information visit http://www.gnu.org/copyleft/gpl.html
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
|
