USBC病毒修复方法
BY: walysclw
最近不幸本人的USB-IDE装接线挂载的伪移动硬盘感染了USBC病毒(名字是我自己起的)，在修复过程中积累了不少经验，有感于网上资料的谬误，发文分享之。不足之处望大家见谅。
注意：
1、本人移动硬盘为ntfs，故修复方法可能主要适用于ntfs，fat32用户也可做参考。
2、网上说的chkdsk不要用，可能会改写硬盘上的数据，那样数据就永远修复不回来了，我们要保持原样(保护案发现场)！！！
3、网上倾向于用EasyRecover修复数据，我告诉你那是不好的，因为USBC会使一些FILE RECORD移位，造成EasyRecover无法找到魔数 (magic number) [1]，于是可能就会有大量的数据找不到(以我的经验为例，13G只能找回7G)
4、不要用Explorer或winpm等分区软件或修复软件，会假死的，可能还会损害硬盘，winhex才是王道。
5、本文标准使用16进制，在不引起歧义的情况下有时用到10进制，地址/偏移统一用16进制。
[1]类似于特征码的东西，杀毒软件用特征码找到病毒，EasyRecover用魔数找文件，比如FILE为FILE RECORD，Rar!为rar文件，MZ为exe文件，(89h)PNG为png文件等等
首先，用winhex打开移动硬盘，MBR在0位置处：
首先检查一下前面的代码对不对(大致看下就行)，1FE-1FF是不是55AA(很重要，一定要是55AA，引导时会检查的)，像这个就错了：
如果错了，那就得重建分区表，不过也没关系，搜索每个柱面的第一个扇区，看是不是开头有FAT或NTFS的魔数(一般为一个jmp指令+字符串(FAT32可能为“FAT32”/“MSWIN4.1”等等，NTFS应该为“NTFS”，不过里面是什么无所谓，系统不会用它)，找到每个分区的起始地址+大小+文件系统类型后，就可以手动写分区表了，具体见下文。
下面我们来分析一下分区表的结构，上面一大堆是硬盘引导代码(加载到内存时偏移为7C00)，你可以反汇编看看，但我们这儿不用去管他。
我们需要注意的是1BE-1FD，图中用蓝框描出了四个主分区记录(注意右上和左下是连着的)，即1BE-1CD、1CE-1DD、1DE-1ED、1EE-1FD，对于每个分区记录，+0(1字节)可取两个值0和80h，其中80h表活动分区(启动分区)，+4(1字节)为文件系统类型，我喜欢用的NTFS为07，最重要的是红框里的，+8(4字节)为分区起始扇区，+12(4字节)为分区扇区数。
提示：硬盘的每个扇区为200h字节，其他介质可能不同，比如cd为400h字节，
好了，Ctrl+G打开“跳至扇区”
输入分区起始扇区来到NTFS分区的Boot sector
对我们有用的数据：NTFS分区的Boot Sector的+0D(1字节)为每族扇区数，+30(8字节)是$MFT的起始族，+38(8字节)是$MFTMirrir(只是$MFT开头最重要的四个记录的备份)的起始族，我们从这些数据中可计算出$MFT的地址(分区偏移量+MFT起始族*每族扇区数*200h)。
这是正常的$MFT(我台式机硬盘上的)：
而我们可以看到移动硬盘上三个分区的$MFT变成了这样：
Partition1：
Partition2：
Partition3：
嗯，为了安全，把MBR、boot sector、$MFT分别备份复制到新文件(选择区块后Ctrl+Shift+N)，这样就保留了案发现场
提示：可以用Alt+1、Alt+2来选择区块。
MFT的FILE RECORD是可以说是由header和一堆attribute组成的(attribute以FFFFFFFF结尾，每扇区最后为两字节的验证码)，每个MFT项为1K(标准情况下)，header的魔数为46 49 4C 45(即“FILE”)，这是找到FILE RECORD的办法，可能会用到的数据：
+04(2字节)验证码的位置，每扇区最后的两字节验证码得和这个偏移指向的两字节验证码一致，两字节验证码之后为被验证码覆盖的数据。如在我的台式机MFT图里，+04h为30h，+30h为4101，+1FE和+3FE也为4101。
+18(4字节) FILE RECORD的实际大小(当大于1FE时得注意验证码覆盖的问题)。
+1C(4字节) FILE RECORD分配的大小。
+14(2字节)第一个attribute的偏移。
好了，有了这些，很多FILE RECORD就可以修复了，因为USBC并不会改你的数据，只会移位。在Partition2中就整整移位了200h字节，把数据移回去后记得在最后加上验证码。
但可能很不幸的是，有些重要的数据由于在移位区域末尾被丢弃了，不过一般比较重要的是前面几个FILE RECORD(为元数据，存放着这个NTFS分区的信息)，这些元数据有一些规律可寻。
比如，我有一个$Volume的最后几个字节丢了，而$Volume的最后一般为80h属性(DATA)， 而其内容00001800000003000000000018000000，正好在开始丢弃，于是，我就把内容敲入扇区，记得最后加FFFFFFFF哦。
另一个分区的$Extend的90h属性(INDEX_ROOT)丢了一半，这个就不能直接copy了，因为这是一个目录，这个目录包含$ObjId、$Quota、$Reparse，自己重做一个目录属性就可以了。
我的结论：
1、USBC病毒不是什么autorun类型的低级弱智病毒，猜测是挂于usbstor驱动的upper filter driver，但目前未经证实,以下暂且基于这个假设。
2、由于挂于usbstor驱动，故只能对U盘或移动硬盘等造成危害，而对主机硬盘无影响。
3、工作原理应该是中间处理了发往usbstor的写缓冲区，故只有向USBstor写时才会危害，其他操作不会影响(注：你不写文件系统不意味着系统不写)。
4、它拦截了发往usbstor的IRP写请求，从中获知写缓冲区,将写缓冲区向后移位20h字节，而后在前面的20h字节里填上
55 53 42 43 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??(??表示不定)
其中55 53 42 43是确定无疑的，其ASCII为"USBC"(引号内)，然后再将IRP写请求继续发给usbstor，可见那次写的缓冲区有多大就有多大范围的数据被移位，缓冲区最后20h字节别问我去哪了，我也不知，很可能被丢弃。
关于walysclw
walysclw是我一高中朋友，兴趣广泛，多有涉猎，只是……很多时候让我很无语……
如果你觉得本文有仔细分析的价值，请选择PDF版本原文
目前已经有 24 条回复，欢迎继续就座
沙发
发在linxo(叫习惯了,现在叫zhcexo)上的第一篇原创,昨晚与cexo大大聊qq,准备发时他说要电信网络出问题了,传不上去,嗯,我这边也上不去,结果网络恢复的时候我已经闪人睡觉去了,今早发现文章已出现,还以为抢不到沙发,居然抢到了,嗯,linxo上的第一个沙发,不错不错
以后我会多发原创,多涉及偏底层的东西,欢迎大家拍砖.
呜….没人回….
看到图，我头都发麻了…
@leehow:的确，所以说那个人才让我很无语嘛，我看了半天才勉强看懂，可操作性不好
赞，技术贴。
会不会太长了 看了一半直接没兴趣了！难道昨天的就是这家伙搞鬼？
@Todd:可是这么强的技术帖不是出自我手，水平不行
@会律博客:不是这家伙，是我电脑自己不好……我真倒霉，手疼了，电扇，显卡坏了，系统声音播放又卡，一个都没解决
@ZH CEXO:哈哈,终于有人气了,好高兴
你不是说声音好了吗?难道又坏了!
显卡风扇可以让大林帮你换
在bbs上virus版一点人气都没有,就一人回赞
@leehow:@会律博客:以后我会发一些比较通俗易懂的,哎,文笔不好,不如cexo大大,请大家多多包涵
换硬盘的时候格错了盘 痛苦的回忆
@章鱼:可怜的孩子，看看这个有好处哦~
@bwskyer:那个……说了这个不是我写的嘛
好文章～ 虽然还没看懂、、、、
@Kars:我也只是勉强懂……
这截图还真多，欢迎新作者，哈哈
好久不来了，变成合写的博客啦。
@别用鼠标点我:不是啊，以前可以说是团队博客，后来成了我的个人博客，现在只不过是熟人的投稿
testdisk可管用？
好像这个病毒google一下，还不少结果
@古月天石页:testdisk是个gnu开源，这点不错，我喜欢
它功能很广，而且有其他同类工具没有的特色，极力推荐……
我一开始试的就是这个（我是个gnu fans），很可惜，它没能修复
其实我认为最好的工具就是winhex+人脑+白皮书（一般为E文，呵呵），比一切自动工具都强
@walysclw:
我还记得当年温寒就是用winhex修好的他的硬盘……不是你指点的吗？
@古月天石页:温寒是谁啊，你真会说笑