引
那日，我拾起散落一地的泛黄笔记，未曾想到会从一个尘封已久的盒子里翻出锈迹斑斑的硬盘。我只记得，当时，夕阳满满的打在脸颊上，而眼前的硬盘还在闪闪发光，似乎在述说着一个不可告人的秘密。
连上旁边废置的老旧电脑，硬盘转动的声音吱吱作响，终端的绿色光点在不急不慢的闪烁。然而，里面空无一物，什么都没有。不对，我好像发现了什么......
Clue 1
那个硬盘并不是空无一物，至少我看到了一个名为.clue1的隐藏文件，好像是一个文本文件，打开一看，里面只有一行文字：
軟盤中，殘留著妳該尋找的下個條件
什么软盘？就在我疑惑的片刻，我看到桌子右下角掉落着一个盖满厚厚灰尘的方形软盘，应该就是它了。
缓缓的拾起它，吹落上面的积灰，插入破旧的电脑。听到电脑读取软盘的兹兹声，心里默默窃幸，看来还能用。
看这软盘的古老程度，也许不能再被我们这样折腾了，为了后面不直接对其操作，先创建一个镜像备份吧：
root@toor:~# mkdir evid && cd evid
root@toor:~/evid # dd if=/dev/fd0 of=floppy.dd bs=512
root@toor:~/evid # chmod 444 floppy.dd
弹出软盘后，记录下镜像的hash，便开始挂载咯(记得任何时候都要只读模式挂载)：
root@toor:~/evid # sha1sum floppy.dd > sha.floppy
root@toor:~/evid # mkdir /mnt/analysis
root@toor:~/evid # mount -t vfat -o ro,noexec,loop floppy.dd /mnt/analysis
root@toor:~/evid # cd /mnt/analysis
root@toor:/mnt/analysis #
当我ls出目录下的文件的那一刻，心里咯噔一下，时间仿佛停滞在2000年，这么多年间，到底发生了什么？
root@toor:/mnt/analysis # ls -al
total 118
drwxr--r-- 4 root root 7168 Dec 31 1969 .
drwxr-xr-x 13 root root 4096 Dec 21 14:20 ..
drwxr--r-- 3 root root 512 Sep 23 2000 Docs
drwxr--r-- 2 root root 512 Sep 23 2000 Pics
-rwxr--r-- 1 root root 19536 Aug 24 1996 arp.exe
-rwxr--r-- 1 root root 37520 Aug 24 1996 ftp.exe
-r-xr--r-- 1 root root 16161 Sep 21 2000 loveletter.virus
-rwxr--r-- 1 root root 21271 Mar 19 2000 ouch.dat
-rwxr--r-- 1 root root 12384 Aug 2 2000 snoof.gz
树形结构列出所有文件看看：
root@toor:/mnt/analysis # tree
|-- Docs
| |-- Benchmarks.xls
| |-- Computer_Build.xml
| |-- Law.doc
| |-- Private
| `-- why hack
|-- Pics
| |-- C800x600.jpg
| |-- Stoppie.gif
| |-- bike2.jpg
| |-- bike3.jpg
| |-- matrixs3.jpg
| `-- mulewheelie.gif
|-- arp.exe
|-- ftp.exe
|-- loveletter.virus
|-- ouch.dat
`-- snoof.gz
3 directories, 15 files
里面好像没有我感兴趣的线索。
例行公事，先对每个文件进行hash并保存到sha.filelist文件中。
root@toor:/mnt/analysis # find . -type f -exec sha1sum {} \; > ~/evid/sha.filelist
以便以后检查文件是否有改动：
root@toor:/mnt/analysis # sha1sum -c ~/evid/sha.filelist
当然，每个文件的文件类型信息也保存一份：
root@toor:/mnt/analysis # find . -type f -exec file {} \; > ~/evid/filetype.list
可恶，他把证据藏在了哪里？难道这里没有吗？不行，我要再仔细找找。
那就对整个镜像来个搜索吧，先把下面的关键字保存到一个文件里。
$50,000
ransom
unleash a virus
哟，有了！
root@toor:~/evid # grep -abif searchlist.txt floppy.dd
75441:you and your entire business ransom.
75500:I have had enough of your mindless corporate piracy and will nolonger stand for it. You will receive another letter next week. Itwill have a single bank account number and bank name. I want you todeposit $50,000 in the account the day you receive the letter.
75767:Don't try anything, and don't contact the cops. If you do, Iwill unleash a virus that will bring down your whole network anddestroy your consumer's confidence.
再用xxd直接查看偏移75441处看16进制数据：
root@toor:~/evid # xxd -s 75441 floppy.dd | less
00126b1: 796f 7520 616e 6420 796f 7572 2065 6e74 you and your end
00126c1: 6972 6520 6275 7369 6e65 7373 2072 616e ire business ran
00126d1: 736f 6d2e 0a0a 5468 6973 2069 7320 6e6f som...This is no
00126e1: 7420 6120 6a6f 6b65 2e0a 0a49 2068 6176 t a joke...I hav
00126f1: 6520 6861 6420 656e 6f75 6768 206f 6620 e had enough of
0012701: 796f 7572 206d 696e 646c 6573 7320 636f your mindless co
0012711: 7270 6f72 6174 6520 7069 7261 6379 2061 rporate piracy a
0012721: 6e64 2077 696c 6c20 6e6f 206c 6f6e 6765 nd will no longe
0012731: 7220 7374 616e 6420 666f 7220 6974 2e20 r stand for it.
虽然找到了证据，可是背后还是阵阵发冷。我抬头，窗外的风吹不进来，四周一片寂静，总感觉，事情没有那么简单......
Clue 2
顺着刚才证据一路看下去，一直到偏移0x0012e1a处，第二条线索映入眼帘，果然，这里面还有问题！
圖片，將會邁向下一個開端
图片？我翻遍挂载镜像里面的所有的图片，可是没有一个是可疑的，难道，是我打开的方式不对？这时，一个名叫image_carve.raw的文件引起了我的注意。我的直觉告诉我，因该是这个错不了。
root@toor:~# file image_carve.raw
image_carve.raw: data
root@toor:~# xxd image_carve.raw | less
0000000: 776a 176b 5fd3 9eae 247f 33b3 efbe 8d6a wj.k_...$.3....j
0000010: d3a9 daa0 8eef c199 102f 7eaa 0c68 a908 ........./~..h..
0000020: fca4 7e13 dc6b 17a9 e973 35a0 cfc3 9360 ..~..k...s5....`
0000030: f9c0 a6b9 1476 b268 de0f 94fa a2f4 4705 .....v.h......G.
0000040: 452d 7691 eb4f 2fa7 b31f 328b c07a ce3d E-v..O/...2..z.=
奇怪，我只看到一堆杂乱随机的字符数据，这看上去不像是图片数据。
让我再想想，我记得每种文件都有相应的magic number来标记其格式，而JPEG图片文件则是以偏移JFIF六个字节的十六进制ffd8开始，ffd9结束。
这次，结合xxd和grep来搜搜试试看：
root@toor:~# xxd image_carve.raw | grep ffd8
00052a0: b4f1 559c ffd8 ffe0 0010 4a46 4946 0001 ..U.......JFIF..
咦，还真有，我感觉有戏！记下ffd8的位置0x00052a4，转换成十进制为21156：
root@toor:~# echo "ibase=16;00052A4" | bc
21156
然后在从偏移21156后面找ffd9：
root@toor:~# xxd -s 21156 image_carve.raw | grep ffd9
0006c74: ffd9 d175 650b ce68 4543 0bf5 6705 a73c ...ue..hEC..g..<
因为图片文件包含ffd9，所以结尾的地址0x0006c76。两者相减，得到图片大小：
root@toor:~# echo "ibase=16;0006C76 - 00052A4" | bc
6610
最后就是把图片提取出来惹，这里用的是dd命令，skip为偏移，bs(block size)设置为1字节，然后count就是图片的大小：
root@toor:~# dd if=image_carve.raw of=carv.jpg skip=21156 bs=1 count=6610
6610+0 records in
6610+0 records out
Clue 3
不出意外的话，第三条线索就是这张图片了，上面刻画着一些奇怪的符号，不过我还是能辨认出一些金文，这是一种大篆体。
监听，注视周围发生的一切
我竖起耳朵，眼睛向四周扫视，没有人，这里只有我一个。我开始感到疑惑，直到我看到了图片右下角一行极小的字，这是什么！
root@able2: ~ # dd if=/dev/sda | nc 192.168.55.20 2525
192.168.55.20，这不是这台电脑的ip吗，难道说，还有另外一台电脑正在向我传送什么数据吗？/dev/sda这不是硬盘数据吗，到底是什么呢？不管怎么说，这里面肯定有我想要找的的答案，先保存下来看看。
root@toor: ~ # nc -l -p 2525 | dd of=~/able2/able2.dd
由于able2.dd是整个sda硬盘的镜像，不能直接挂载，所以先看看其分区结构：
root@toor:~/able2 # sfdisk -l -uS able2.dd
Disk able2.dd: cannot get geometry
...
Units = sectors of 512 bytes, counting from 0
Device Boot Start End #sectors Id System
able2.dd1 57 10259 10203 83 Linux
able2.dd2 10260 112859 102600 83 Linux
able2.dd3 112860 178694 65835 82 Linux swap / Solaris
able2.dd4 178695 675449 496755 83 Linux
able2.dd5 675450 676690 10240 83 Linux
五个分区，好吧，那就依次提取出来：
root@toor:~/able2 # dd if=able2.dd of=able2.part1.dd bs=512 skip=57 count=10203
10203+0 records in
10203+0 records out
root@toor:~/able2 # dd if=able2.dd of=able2.part2.dd bs=512 skip=10260 count=102600
102600+0 records in
102600+0 records out
root@toor:~/able2 # dd if=able2.dd of=able2.part3.dd bs=512 skip=112860 count=65835
65835+0 records in
65835+0 records out
root@toor:~/able2 # dd if=able2.dd of=able2.part4.dd bs=512 skip=178695 count=496755
496755+0 records in
496755+0 records out
root@toor:~/able2 # dd if=able2.dd of=able2.part5.dd bs=512 skip=675450 count=10240
10240+0 records in
10240+0 records out
接下来就是要根据这五个分区来还原文件系统了。我不厌其烦的开始依次挂载每个分区观察其文件目录结构：
root@toor:~/able2 # mount -t ext2 -o ro,loop able2.part1.dd /mnt/analysis/
我偷了个懒，当挂载able2.part2.dd的时候，直接查看fstab文件就知道了。
root@toor:~/able2 # cat /mnt/analysis/etc/fstab
/dev/hda2 / ext2 defaults 1 1
/dev/hda1 /boot ext2 defaults 1 2
/dev/hda4 /usr ext2 defaults 1 2
/dev/hda5 /clue ext2 defaults 1 2
/dev/hda3 swap swap defaults 0 0
根据fstab挂载相应的分区到对应的路径下：
root@toor:~/able2 # mount -t ext2 -o ro,loop able2.part2.dd /mnt/analysis/
root@toor:~/able2 # mount -t ext2 -o ro,loop able2.part1.dd /mnt/analysis/boot
root@toor:~/able2 # mount -t ext2 -o ro,loop able2.part4.dd /mnt/analysis/usr
root@toor:~/able2 # mount -t ext2 -o ro,loop able2.part5.dd /mnt/analysis/clue
clue分区已解锁，我cd进去，我知道里面会有什么等着我，这就像是一场噩梦，可我还是必须直面，哪怕头破血流。
Clue 4
没有，什么都没有，一片空白！
clue目录下什么都没有，连隐藏文件的气味都没有，就像虚无一样完全看不到希望，怎么办！
我的第六感告诉我，这里一定哪里不对劲。看来，是时候使用Sleuthkit了，最重要的是，这台古老的电脑居然也安了Sleuthkit。
先试了下mmls，这个命令跟之前的sfdisk的作用类似，也能给出镜像的分区信息，只不过更加好用。
root@toor:~/able2 # mmls -t dos able2.dd
DOS Partition Table
Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000001 0000000056 0000000056 Unallocated
02: 00:00 0000000057 0000010259 0000010203 Linux (0x83)
03: 00:01 0000010260 0000112859 0000102600 Linux (0x83)
04: 00:02 0000112860 0000178694 0000065835 Linux Swap / Solaris
05: 00:03 0000178695 0000675449 0000496755 Linux (0x83)
从之前就已经知道根目录/文件系统在第二分区，从上面可知偏移为000010260，用fsstat查看详细信息：
root@toor:~/able2 # fsstat -o 10260 able2.dd
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: Ext2
Volume Name:
Volume ID: 906e777080e09488d0116064da18c0c4
Last Written at: Sun Aug 10 14:50:03 2003
Last Checked at: Tue Feb 11 00:20:09 1997
Last Mounted at: Thu Feb 13 02:33:02 1997
Unmounted Improperly
Last mounted on:
Source OS: Linux
Dynamic Structure
InCompat Features: Filetype,
Read Only Compat Features: Sparse Super,
METADATA INFORMATION
--------------------------------------------
Inode Range: 1 - 12881
Root Directory: 2
Free Inodes: 5807
CONTENT INFORMATION
--------------------------------------------
Block Range: 0 - 51299
Block Size: 1024
Reserved Blocks Before Block Groups: 1
别浪费时间了，快看看clue文件夹到底怎么了，我心里告诉自己。
事不宜迟，拿出利器fls，fls可以列出文件系统上所有的文件和目录：
root@toor:~/able2 # fls -o 10260 able2.dd
d/d 11: lost+found
d/d 3681: boot
d/d 7361: usr
d/d 3682: proc
d/d 7362: var
d/d 5521: tmp
d/d 7363: dev
d/d 9201: etc
d/d 1843: bin
d/d 1844: home
d/d 7368: lib
d/d 7369: met
d/d 7370: opt
d/d 1848: root
d/d 1849: sbin
d/d 8243: clue
r/r 1042: .bash_history
d/d 11105: .001
d/d 12881: $OrphanFiles
用-d选项列出文件系统上所有被删掉的文件（已删除的文件会用*标记）：
root@toor:~/able2 # fls -o 10260 -Frd able2.dd
r/r * 11120(realloc): var/lib/slocate/slocate.db.tmp
r/r * 10063: var/log/xferlog.5
r/r * 10063: var/lock/makewhatis.lock
r/r * 6613: var/run/shutdown.pid
r/r * 1046: var/tmp/rpm-tmp.64655
r/r * 6609(realloc): var/catman/cat1/rdate.1.gz
r/r * 6613: var/catman/cat1/rdate.1.gz
r/r * 6616: tmp/logrot2V6Q1J
r/r * 2139: dev/ttYZ0/lrkn.tgz
d/r * 10071(realloc): dev/ttYZ0/lrk3
r/r * 6572(realloc): etc/X11/fs/config-
l/r * 1041(realloc): etc/rc.d/rc0.d/K83ypbind
l/r * 1042(realloc): etc/rc.d/rc1.d/K83ypbind
l/r * 6583(realloc): etc/rc.d/rc2.d/K83ypbind
l/r * 6584(realloc): etc/rc.d/rc4.d/K83ypbind
l/r * 1044: etc/rc.d/rc5.d/K83ypbind
l/r * 6585(realloc): etc/rc.d/rc6.d/K83ypbind
r/r * 1044: etc/rc.d/rc.firewall~
r/r * 6544(realloc): etc/pam.d/passwd-
r/r * 10055(realloc): etc/mtab.tmp
r/r * 10047(realloc): etc/mtab~
r/- * 0: etc/.inetd.conf.swx
r/r * 2138(realloc): root/lolit_pics.tar.gz
r/r * 2139: clue/lrkn.tgz
r/r * 1055: $OrphanFiles/OrphanFile-1055
r/r * 1056: $OrphanFiles/OrphanFile-1056
r/r * 1057: $OrphanFiles/OrphanFile-1057
r/r * 2141: $OrphanFiles/OrphanFile-2141
r/r * 2142: $OrphanFiles/OrphanFile-2142
r/r * 2143: $OrphanFiles/OrphanFile-2143
果然，clue文件下有一个被删除的文件。不管是什么，看来，我得想办法把它复原出来。
r/r * 2139: clue/lrkn.tgz
clue/lrkn.tgz的inode是2139，于是用istat查看的该inode的详细信息：
root@toor:~/able2 # istat -o 10260 able2.dd 2139
inode: 2139
Not Allocated
Group: 1
Generation Id: 3534950564
uid / gid: 0 / 0
mode: rrw-r--r--
size: 3639016
num of links: 0
Inode Times:
Accessed: Sun Aug 10 00:18:38 2003
File Modified: Sun Aug 10 00:08:32 2003
Inode Modified: Sun Aug 10 00:29:58 2003
Deleted: Sun Aug 10 00:29:58 2003
Direct Blocks:
22811 22812 22813 22814 22815 22816 22817 22818
22819 22820 22821 22822 22824 22825 22826 22827
...
32233 32234
接下来就是保存该inode指向的block数据，即被删除的文件：
root@toor:~/able2 # icat -o 10260 able2.dd 2139 > lrkn.tgz.2139
root@toor:~/able2 # file lrkn.tgz.2139
lrkn.tgz.2139: gzip compressed data, was "lrkn.tar", from Unix
嗯，没错，是一个gzip的压缩文件。
现在我已非常谨慎，这是种不好的预感。先不解压，看看里面有什么：
root@toor:~/able2 # tar tzvf lrkn.tgz.2139 | less
drwxr-xr-x lp/lp 0 1998-10-01 18:48:18 lrk3/
-rwxr-xr-x lp/lp 742 1998-06-27 11:30:45 lrk3/1
-rw-r--r-- lp/lp 716 1996-11-02 16:38:43 lrk3/MCONFIG
-rw-r--r-- lp/lp 6833 1998-10-03 05:02:15 lrk3/Makefile
-rw-r--r-- lp/lp 6364 1996-12-27 22:01:43 lrk3/README
-rw-r--r-- lp/lp 1732 1995-11-10 23:59:59 lrk3/CLUE5
-rwxr-xr-x lp/lp 90 1998-06-27 12:53:45 lrk3/RUN
drwxr-xr-x lp/lp 0 1998-10-01 18:08:50 lrk3/bin/
这是什么鬼，lrk3是一个非常古老的rootkit，我表示对rootkit完全不了解。可是，里面的CLUE5却血腥的刺眼，又是一条可怕的提示，想想就让人不禁寒颤。
root@toor:~/able2 # tar xzvfO lrkn.tgz.2139 lrk3/CLUE5 > CLUE5
lrk3/CLUE5
Clue 5
线索5的陈述依然是那么简单有力让人摸不着头脑。
CYBERNETIK，找尋它身處何處
我默默的想，也许这是在提示我，找到含有关键字CYBERNETIK的文件所在。一想到这里，身体就不由自主的不受控制，开始在终端前机械的操作起来。
第一步对整个镜像文件来个搜索：
root@toor:~/able2 # grep -abi CYBERNETIK able2.dd
10561603: * updated by Cybernetik for linux rootlet
55306929:Cybernetik proudly presents...
55312943:Email: [email protected]
55312975:Finger: [email protected]
root@toor:~/able2 # xxd -s 10561603 able2.dd | head -n 5
0a12843: 202a 0975 7064 6174 6564 2062 7920 4379 *.updated by Cy
0a12853: 6265 726e 6574 696b 2066 6f72 206c 696e bernetik for lin
0a12863: 7578 2072 6f6f 746b 6974 0a20 2a2f 0a0a ux rootkit. */..
0a12873: 2369 6e63 6c75 6465 203c 7379 732f 7479 #include .#include
有这个关键字，一种不好的预感涌上心头，我知道，接下来就是找到这个文件并把它提取出来。
根据上面的结果，关键字CYBERNETIK第一次出现在镜像偏移10561603处，之前用fsstat知道了每个扇区的大小是512字节，所以可以计算出位于哪个扇区：
root@toor:~/able2 # echo "10561603/512" | bc
20628
之前用mmls得到该文件所在的分区起始于扇区10260：
root@toor:~/able2 # mmls -t dos able2.dd
DOS Partition Table
Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000001 0000000056 0000000056 Unallocated
02: 00:00 0000000057 0000010259 0000010203 Linux (0x83)
03: 00:01 0000010260 0000112859 0000102600 Linux (0x83)
04: 00:02 0000112860 0000178694 0000065835 Linux Swap / Solaris
05: 00:03 0000178695 0000675449 0000496755 Linux (0x83)
知道关键字在物理硬盘镜像偏移并不能帮我们定位文件，所以两者相减，就得到卷偏移：
通过fsstat知道了Block大小是1024字节，因此，可以计算出关键字位于哪个block：
总体来说，通过以上步骤我们得到了block偏移。
知道了位于哪个块，我不由得舒了一口气，我知道，接下来的就容易的很多了。先用ifind找到哪个inode指向的是数据块5148：
root@toor:~/able2 # ifind -o 10260 -f ext -d 5184 able2.dd
10090
欧耶，乘胜追击，直接将该inode指向的文件数据输出出来：
root@toor:~/able2 # icat -r -o 10260 -f ext able2.dd 10090 | less
/*
* fixer.c
* by Idefix
* inspired on sum.c and SaintStat 2.0
* updated by Cybernetik for linux rootlet
*/
#include
#include
#include
#include
#include
/*
C.L.U.E.6:
答案，遺失在交換數據流裡
*/
main (argc,argue)
int argh;
char **argv;
回过头来再看看，我怎么没想到，不需要这么麻烦，还有更简单的方法，只需用到blkls和blkcalc就可以轻松得到block位置了。
Clue 6
相必已看到，第六条线索不出意料的就在刚才文件的注释里：
答案，遺失在交換數據流裡
交换数据流，我想，应该指的是NTFS文件系统里的ADS特性。可当前的明明是EXT2文件系统，咦，不对，我好像看见了一个ntfs.dd的文件！难道是这个？也没有其它办法了，姑且一试吧。
二话不说先挂载，列出所有文件：
root@toor:~/ntfs_pract # mount -t ntfs -o ro,loop,offset=30208 ntfs.dd /mnt/analysis/
root@toor:~/ntfs_pract # cd /mnt/analysis/
root@toor:~/analysis # find . -type f
./Cookies/[email protected][2].txt./Cookies/buckyball@2o7[1].txt
./Cookies/[email protected][1].txt
./Cookies/buckyball@specificclick[1].txt
./Cookies/[email protected][1].txt
./Cookies/[email protected][2].txt
... [content removed]
./Favorites/2600 The Hacker Quarterly.url
... [content removed]
./My Documents/My Pictures/Tails/GemoTailG4.jpg
./My Documents/signatures.pdf
./My Documents/ULTIMATEJOURNEYDK.wmv
./My Documents/Webstuff/bandit2.jpg
./My Documents/Webstuff/m2_flat_CF.jpg
./My Documents/Webstuff/service1.jpg
./My Documents/Webstuff/Thumbs.db
./NTUSER.DAT
./SVstunts.avi
貌似没有什么异常，可以我心里总觉得这个avi文件十分可疑，可能是男人的直觉吧。线索提示既然是ADS，那这回换个方式查看，直接看镜像文件。
首先查看分区：
root@toor:~/ntfs_pract # mmls ntfs.dd
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000001 0000000058 0000000058 Unallocated
02: 00:00 0000000059 0001023059 0001023001 NTFS (0x07)
03: ----- 0001023060 0001023999 0000000940 Unallocated
得知NTFS分区的偏移是59，然后用fls列出所有文件：
root@toor:~/ntfs_pract # fls -Fr -o 59 -f ntfs ntfs.dd
r/r 4-128-4: $AttrDef
r/r 8-128-2: $BadClus
r/r 8-128-1: $BadClus:$Bad
r/r 6-128-1: $Bitmap
...
r/r 0-128-1: $MFT
r/r 1-128-1: $MFTMirr
r/r 9-128-8: $Secure:$SDS
...
r/r * 42-128-1: Cookies/buckyball@revsci[2].txt
r/r * 43-128-1: Cookies/[email protected][1].txt
r/r * 44-128-1: Cookies/buckyball@slashdot[1].txt
...
r/r 128-128-3: My Documents/My Pictures/Thumbs.db
r/r 128-128-4: My Documents/My Pictures/Thumbs.db:encrypt able
r/r * 112-128-4: My Documents/My Pictures/bandit-streetortrack2005056.jpg
r/r * 116-128-4: My Documents/My Pictures/fighterama2005-ban4.jpg
r/r 129-128-4: My Documents/Osuny Articles courtesy of BIOC Agent.doc
r/r 130-128-4: My Documents/signatures.pdf
r/r 131-128-4: My Documents/ULTIMATEJOURNEYDK.wmv
r/r 133-128-3: My Documents/Webstuff/bandit2.jpg
r/r 134-128-4: My Documents/Webstuff/m2_flat_CF.jpg
r/r 135-128-3: My Documents/Webstuff/service1.jpg
r/r 136-128-3: My Documents/Webstuff/Thumbs.db
r/r * 81-128-4: My Documents/direct_attacks.doc
r/r 138-128-3: NTUSER.DAT
r/r 137-128-3: SVstunts.avi
r/r 137-128-4: SVstunts.avi:walkingdead.txt
可以看到，这个avi文件有两个入口，第二个就是隐藏在ADS里的文本文件。
明明知道等待着我的会是什么，可我还是忍不住打开这个文件：
root@toor:~/ntfs_pract # icat -o 59 -f ntfs ntfs.dd 137-128-4
___ _,.---,---.,_
| ,;~' '~;,
| ,; ;,
Frontal | ; ; ,--- Supraorbital Foramen
Bone | ,' /'
| ,; /' ;,
| ; ; . . <-' ; |
|__ | ; ______ ______ ;<----- Coronal Suture
___ | '/~" ~" . "~ "~\' |
| | ~ ,-~~~^~, | ,~^~~~-, ~ |
Maxilla, | | | }:{ | <------ Orbit
Nasal and | | l / | \ ! |
Zygomatic | .~ (__,.--" .^. "--.,__) ~.
Bones | | ----;' / | \ `;-<--------- Infraorbital Foramen
|__ \__. \/^\/ .__/
___ V| \ / |V <--- Mastoid Process
| | |T~\___!___!___/~T| |
| | |`IIII_I_I_I_IIII'| |
Mandible | | \,III I I I III,/ |
| \ `~~~~~~~~~~' /
| \ . . <-x---- Mental Foramen
|__ \. ^ ./
^~~~^~~~^ -dcau (4/15/95)
>
De profundis clamo ad te domine.
...
I see dead people.
De profundis clamo ad te domine，我疑惑地呢喃着。突然，眼前一黑，好像有什么硬物砸在了我的头上，我重重的倒在地上。意识在渐渐失去，可我貌似看到了什么......
尾
月光诡异的从窗外倾洒进来，我缓缓地睁开眼，头疼的几乎将要炸裂。电脑屏幕上的绿色字符冷冷的闪烁跳动，我吃力的站起来。不行，我要赶快删掉这个文件，不能再被人发现它的存在，我知道它的可怕。
直接删掉这个镜像文件，我要抹去它的存在。幸好，我手上现在掌握着几种这台老式电脑上能用的删除文件的法术。
rm -rf /
find / -type f -delete
rsync -a –delete empty/ /
我知道，不能用rm，rm太危险，一旦被复原，后果不堪设想。find也一样，至于rsync，这个不熟悉，我不能冒着这样的风险。
直接格盘吧，不行，不能搞这么大的动静，我只想静静的删除文件。
dd if=/dev/zero of=/dev/hd*
shred，没错，我怎么没想到这个，还有这个可以用。shred会用随机内容覆盖文件所在的节点和数据块，并删除文件，就是它了。
root@toor:~/ntfs_pract # shred -u ntfs.dd
用fls检查下，并没有出现，至少，现在可以舒一口气了。此时，乌云遮住了月亮，我知道，故事到这里就结束了。
跋
本文为阅书有感而作，一本是来自LinuxLeo网站提供的Linux取证入门的书；一本是来自Brain Carrier的经典的File System Forensic Analysis；一本是CFTT项目测试各种取证工具并总结的取证工具handbook大全(2015版)。你可以在这里获取这三本书。
其中示例及所用镜像文件均来自书中，愿各位亲自尝试体验其中的乐趣。
本人已整理打包，下载地址：http://pan.baidu.com/s/1ogLXW
成文仓促，文辞粗浅，仅资一娱，诸君见谅。
微信公共号：urinx，望关注。