引
那日,我拾起散落一地的泛黄笔记,未曾想到会从一个尘封已久的盒子里翻出锈迹斑斑的硬盘。我只记得,当时,夕阳满满的打在脸颊上,而眼前的硬盘还在闪闪发光,似乎在述说着一个不可告人的秘密。
连上旁边废置的老旧电脑,硬盘转动的声音吱吱作响,终端的绿色光点在不急不慢的闪烁。然而,里面空无一物,什么都没有。不对,我好像发现了什么……
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.
<continues>
虽然找到了证据,可是背后还是阵阵发冷。我抬头,窗外的风吹不进来,四周一片寂静,总感觉,事情没有那么简单……
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.=
<continues>
奇怪,我只看到一堆杂乱随机的字符数据,这看上去不像是图片数据。
让我再想想,我记得每种文件都有相应的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
...<error messages>
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
<continues>
别浪费时间了,快看看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
<continues>
果然,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
<snip>...
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/
<continues>
这是什么鬼,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: cybernetik@nym.alias.net
55312975:Finger: cybernetik@nym.alias.net
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 <sys/ty
0a12883: 7065 732e 683e 0a23 696e 636c 7564 6520 pes.h>.#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 <sys/types.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <stdio.h>
#include <clue6.h>
/*
C.L.U.E.6:
答案,遺失在交換數據流裡
*/
main (argc,argue)
int argh;
char **argv;
<continues>
回过头来再看看,我怎么没想到,不需要这么麻烦,还有更简单的方法,只需用到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/buckyball@as-eu.falkag[2].txt./Cookies/buckyball@2o7[1].txt
./Cookies/buckyball@ad.yieldmanager[1].txt
./Cookies/buckyball@specificclick[1].txt
./Cookies/buckyball@store.makezine[1].txt
./Cookies/buckyball@store.yahoo[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/buckyball@search.msn[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,望关注。
原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/54211.html