真是具有讽刺意味，昨天我才说完利用ext3grep工具来恢复删除的文件，结果今天我就很悲惨的删除了我两个OS的根文件系统加上最致命的HOME分区，我变得一无所有了。

故事是这样的：

我从solidot上看到了一篇文档（估计solidot自己也不知道），说是OpenSSH < 5.2版本的都有远程溢出的漏洞，而且网络提供了源代码，这太正常不过了，每次和Linux相关的漏洞，一般都能找到攻击的源代码，于是我就下载了下来，编译没有问题。

开始执行，第一次执行的时候，我用的普通账号，程序提示需要root权限。于是我再用root账号执行，结果死机了。

到这里，我也觉得正常，因为我的这台机器不是没有死机过，况且，有可能是这个程序触发的，于是我掉电重启，结果发现系统启动不了，说找不到/sbin/init了，也许是文件系统需要修复的原因吧。

我便重启到另外一个系统上，可惜这个系统不支持ext4文件系统，于是我边想办法找更新内核来支持，一边再尝试那个程序，看看这个系统上会不会死机，很幸运，没有死机。但是出了给出一个不怎么有用的信息外，nothing happend。
于是我习惯性的执行了ls命令，可怕的ls not found ,no such file or directory出现了，我立刻执行其他命令，发现都不翼而飞了。

难道。。。。文件系统被删除了？。。。。

重启，再进入另外一个系统（我机器上有5个系统），挂载刚才出问题的系统的根文件系统，结果发现里面什么都没有了，是的，删除的很干净，什么都没有了。

我这才意识到这次玩大了，我用普通账号执行过这个程序，是不是我的HOME也没有了。

于是开始分析那个程序的源代码，我把代码发给了@pczou，pczou告诉我，那不是真正的exploit代码，是一个木马程序，或者说是一个恶作剧，他唯一的功能就行执行rm -rf \~/\* 2\>/dev/null ，当然这段代码是shellcode的。

到这里，基本上没有什么想头了，我只能找恢复工具了，刚好昨天看到的ext3grep派上了用场，可惜它仅仅只能恢复ext3的文件系统，针对具有完整特性的ext4，它无能为力。

于是我又找到了一个extundelete的工具，它借鉴了ext3grep的代码，但是支持ext4。利用它，我恢复了部分数据，但是我几个最重要的目录不能恢复了。

接着我用photorec工具恢复出了14G的文件，可惜photorec恢复出来的文件都是以inode命名了，我看着那上百万个都是用数字命名的文件，头就大了，怎么会把inode转回去？我没有inode到filename的映射表，现在也不可能从当前的文件系统中找到了。

我现在唯一能做的，就是暂时保留这个文件系统不动，等到某一天又办法了，再恢复吧。

那个该死的exploit源代码名字是OpenOwn.c，为了不祸害大家，我就不给出链接了，当然如果你硬是要试试，不信邪，你可以googling，download,compile and execute，good luck! 这是日全食带来的霉运吗？