Can't boot, nvatabus.sys infected, evid. of TDSS, MBR?

[davidi]

Windows XP system based on nforce chipset

Won't boot into Windows. Won't boot into safe mode.

Will boot off Eset SysRescue NOD32 and also UBCD 4.11 boot disks.

But does NOT appear to successfully boot a Win XP install disk (just to see if it boots to get to recovery console or other options). I get black screen after initial message of "inspecting hardware" and then the system eventually goes quiet with nothing going on (even after 10+ minutes).

Note - I use MBAM and recommend it to everyone as the number one 'heavy lifter' of cleaning/removing malware. But up to now that's all been on bootable systems that I can get MBAM on!

In this post I will mention a couple of tools I have used to understand what's going on here but my reason for posting in the Malwarebytes Forum (even though I have used these other tools to help learn of the problem) is that I'm curious how I might (if at all possible) still use MBAM or eventually get to where I can use MBAM to clean this system. OR - to gain help for manual intervention / advice.

What I've done and learned:

I've backed up the whole drive (MBR and partitions) using boot disk tools (Acronis) and so I can now work on either the real thing or a replicated drive. Media of Hard drives (original and the clone) appear to be sound (no bad sectors reported). I can 'see' the file system, files, and data when I inspect the 'archive' backup (I am avoiding having this system drive running live as a slave in another live system as I know this 'dead' system is infected - but if I must I can arrange to work that way and be prepared to clean or throwaway/restore the image of the system I would use to do that work.)

Putting the clone (or original) drive back in it's own box and booting and scanning with Eset SysRescue NOD32 found 16 infections. 14 cleaned or deleted (and quarantined).

TWO infections HOWEVER could NOT be removed automatically (even though using boot disk to access Hard Drive) and prompted me to manually either delete or ignore.

The one file of concern:

c:/windows/system32/drivers/nvatabus.sys (the other was in system restore so not such a big deal to delete.)

I submitted that nvatabus.sys file to virustotal last night and 8/41 came back with pretty similar sounding results for that file. Most said: Rootkit.Win32.TDDS; BackDoor.Tdss; and 1 said Win32/Olmarik.OF.

I found another copy of nvatabus.sys on the same drive as part of what looked like an unzipped set of nforce drivers for the board and buried in that collection in the IDE area was a clean version of nvatabus.sys (I submitted that exact file to virustotal and all 41 stated it as no result - aka OK).

I made use of a system I could blow-away and did a visual hex comparison of the two nvatabus.sys files and yep - they are different internally although the size is the same.

Now I'm not sure what to do.

My thought is that the nvatabus.sys (or maybe one of the other 14 'cleaned' files) are a critical first part to Windows booting (IDE / ATA disk driver capability I'm guessing).

For some reason (gut) I would not be surprised if the MBR or partition boot info is messed up but I don't have proof. I have some limited experience with Grenier (gsecurity) TestDisk application. TestDisk complains that the CHS architecture is 16 heads but probably should be 240. I've read that this in most situations this may not matter and I've had cases where everything is GOOD and this doesn't seem to matter. But TestDisk seems to complain more on this disk. Saying the disk is reported as smaller than it probably really is and it questions whether the BIOS or other settings may be correct. Besides the CHS addressing being different than expected ... TestDisk reports that it can't find or repair the second partition (the "C" drive partition of the disk) after it's done it's own 'search' for the partition. (It finds some sort of partition after the HP_Recovery partition but it must be unsure of it.) There are hints that perhaps changing the geometry to 240 from 16 heads/cylinders *might* be beneficial if it can't find or repair the partition (and that seems to be the case) but I haven't done so because I get the idea that there could be risks as well. To be honest - this whole TestDisk part is a bit fuzzy as I didn't take the best notes and I had it 'look' at both the original and the 'clone'. So my apologies that I may not have the best facts here.

I guess I'm pretty concerned that there may be something more than the nvatabus.sys and other 15 infections as I can't get a Windows XP CD to boot or the on disk Windows to boot even a tiny bit to recognize F8 or try and fail a regular boot. (Thus my wonders about the MBR or partition boot info.)

Help? Ideas?

I don't believe that I've done any changes to the original disk - only to the copy (meaning letting Eset SysRescue delete/clean infected files was done on the test copy disk.)

Thanks,

- David