Anyone expert in RootRepeal logs out there?

[Andy Spragg]

I hope it is OK to post about this in this forum. I posted about it on the Sysinternals site over two weeks ago and no-one has voiced an opinion. Rather than rehash the posting here's a link to the post at Sysinternals:

http://forum.sysinternals.com/rootrepeal-a...topic22880.html

What I'm trying to find out is what's causing all the problems RootRepeal is reporting. Is there anything different about external HDDs, for example, that might be responsible?

[AdvancedSetup]

My guess is that Avast and/or Online Armor are potentially to blame here. If it were me (just to satisfy curiosity if for nothing else) I would FULLY remove both of them and run a FULL disk check on the local drive that contains Windows.

Then download a fresh copy of GMER and do the scan again and see what you get this time.

As for the Flash Drive Disinfector the CF already does that on it's own if one is connected at the time.

[Andy Spragg]

My guess is that Avast and/or Online Armor are potentially to blame here. If it were me (just to satisfy curiosity if for nothing else) I would FULLY remove both of them and run a FULL disk check on the local drive that contains Windows.

Hi Ron,

Not sure about how to ensure the FULLness of the various actions, but anyway ...

OK, now I'm worried. I disabled the wireless connection and then uninstalled Online Armor rebooted and then uninstalled Avast and rebooted. Then I closed down MBAM and a couple of other system tray things, and tried to run chkdsk :c /r. This is what Windows said:

The type of the file system is NTFS.

Cannot lock current drive.

Chkdsk cannot run because the volume is in use by another process.

Would you like to schedule this volume to be checked next time the system restarts? Y/N

So (worried) I said Y and rebooted. I was keeping an eye on progress whilst doing other things. The first 3 stages were OK, stage 4 (file data) was 86% complete and then in the space of a few minutes while I was elsewhere, it finished, because I came back to find the logon screen. No log file. Seems odd that it doesn't create one? Bit of an oversight, that, unless there is supposed to be one.

So I don't know how far to trust that chkdsk run, because it seems to me there's no non-suspicious reason why it should not have run on demand the first time. What does that output indicate to you, and how should I proceed now?

[PedroHin]

chkdsk /r will never run from the system partition when windows gui is running (if windows is on C:, you cannot check C:), so that is normal.

for a log, look under 'event viewer' / 'application' / and an event under source 'winlogon'

[noknojon]

Hi Andy -

I use this code (cut and paste in Run box) and it has always run - (Given to me by exile360)

CMD /C ECHO Y|CHKDSK C: /R | SHUTDOWN /R /T 30

Other than that I would post it in HiJack This Area

Regards -

[DarkSnakeKobra]

The type of the file system is NTFS.

Cannot lock current drive.

Chkdsk cannot run because the volume is in use by another process.

Would you like to schedule this volume to be checked next time the system restarts? Y/N

Disk Check cannot run while windows is running. You have to schedule and reboot to run it.

[Andy Spragg]

Disk Check cannot run while windows is running. You have to schedule and reboot to run it.

Thanks Pedro (very disturbing avatar BTW), nokonjon and Buttons for putting me straight on chkdsk ...

Right, here's what I found:

chkdsk made minor corrections:

Event Type: Information

Event Source: Winlogon

Event Category: None

Event ID: 1001

Date: 29/05/2010

Time: 14:03:37

User: N/A

Computer: ANDY-32EC1AB179

Description:

Checking file system on C:

The type of the file system is NTFS.

A disk check has been scheduled.

Windows will now check the disk.

Cleaning up minor inconsistencies on the drive.

Cleaning up 2638 unused index entries from index $SII of file 0x9.

Cleaning up 2638 unused index entries from index $SDH of file 0x9.

Cleaning up 2638 unused security descriptors.

CHKDSK is verifying file data (stage 4 of 5)...

File data verification completed.

CHKDSK is verifying free space (stage 5 of 5)...

Free space verification is complete.

CHKDSK discovered free space marked as allocated in the

master file table (MFT) bitmap.

Windows has made corrections to the file system.

20482843 KB total disk space.

13807740 KB in 60455 files.

19664 KB in 8924 indexes.

20 KB in bad sectors.

176071 KB in use by the system.

65536 KB occupied by the log file.

6479348 KB available on disk.

4096 bytes in each allocation unit.

5120710 total allocation units on disk.

1619837 allocation units available on disk.

Internal Info:

c0 3e 01 00 0d 0f 01 00 48 67 01 00 00 00 00 00 .>......Hg......

ea 01 00 00 02 00 00 00 cb 10 00 00 00 00 00 00 ................

42 36 69 05 00 00 00 00 10 a4 22 24 00 00 00 00 B6i......."$....

88 d7 c6 1f 00 00 00 00 fe 1e f6 b3 01 00 00 00 ................

be f5 42 68 00 00 00 00 8e 44 8d 66 02 00 00 00 ..Bh.....D.f....

f0 23 30 a7 00 00 00 00 30 3b 07 00 27 ec 00 00 .#0.....0;..'...

00 00 00 00 00 f0 c1 4a 03 00 00 00 dc 22 00 00 .......J....."..

Windows has finished checking your disk.

Please wait while your computer restarts.

For more information, see Help and Support Center at

http://go.microsoft.com/fwlink/events.asp

.

GMER ran to completion after approximately 9 hours (I set it to check all local disks). At the time it finished, it was only showing two things: 1) that a section of a video driver was writable and 2) that an attached device was using FAT. So I would like to say it gave me a clean bill of health, but I can't, quite, because when I clicked Save to save the report, it hung and I had to reboot.

Furthermore, I ran RootRepeal again while Avast and Online Armor were both uninstalled. It now reports that both EHDDs have MBR rootkit, both have a few dozen sector mismatches, and one has loads of file issues. Basically the same report as before, in fact, except that last time (after running chkdsk on both) it only identified the MBR rootkit one on EHDD. So whatever is responsible for RootRepeal's output, it seems to be neither Avast nor Online Armor.

Finally, I checked in Event Viewer to see if I could find out any information about the hang. I discovered the following entry:

Event Type: Information

Event Source: Save Dump

Event Category: None

Event ID: 1000

Date: 30/05/2010

Time: 11:29:32

User: N/A

Computer: ANDY-32EC1AB179

Description:

The computer has rebooted from a bugcheck.

The bugcheck was: 0x000000f4 (0x00000003, 0x8a2ee398, 0x8a2ee50c, 0x8060577e).

A full dump was not saved.

There are 74 such events in the last 3 weeks, and the bugcheck information is exactly the same every time.

Incidentally, I have re-installed Avast, so (along with MBAM) I have some protection whilst I am online. I've deferred reinstalling Online Armor.

What do you think, folks?

[PedroHin]

Well that's a toughie. It is either a failing HDD, Motherboard, memory, rootkit, rootkit leftovers, or bad driver.

Have you had the BSODs since running chkdsk?

The hanging upon saving a logfile, and the bad sectors reported by chkdsk would cause me to check the harddrive first

I don't suppose you have the resources to copy the system to another drive? If you have another HDD of same or larger capacity you can do this -- http://www.todo-backup.com/products/featur...clone-guide.htm

Anyone else have anything to suggest?

[AdvancedSetup]

No its quite normal and I would say your system is clean if that is all it said.

Stop your AV and other programs, nothing else should be running. Then scan with RootRepeal again and I'm sure it too will come back okay now.

[Andy Spragg]

( ) @ Pedro ...

(BSODs) That's the weird thing, there haven't been any BSODs, just hangs. I'm not even getting any memory dumps. I have the machine set to produce a kernel dump, overwriting any previous one, and restart automatically. But the date of the memory dump currently in C:\windows is April 30, and that is before the earliest of the 74 events recorded in event viewer.

(chkdsk) I've had one hang since running chkdsk, the one when I tried to save the GMER log file. Any suggestions for what else can I do to check the HDD apart from running chkdsk?

@ Ron

The last Rootrepeal scan I did was with AV and HIPS firewall uninstalled (not just stopped), and no other programs running, after running chkdsk, just like you suggested. Happy to uninstall Avast again and run it again, but to do it differently I'd need to go into task manager and start shutting down all the non-essential processes that are running invisibly as well. Should I do this? Or is there any sense in running chkdsk in safe mode? Or GMER or Rootrepeal for that matter?

Incidentally, I emailed RootRepeal with cc to GMER yesterday. I would have done it sooner, except I only found the contact address for RootRepeal yesterday. Don't know how I managed to miss it before, I must have looked at that homepage half a dozen times without seeing it . I can only suppose it's because it's right at the bottom below all the version history stuff. Doh.

[AdvancedSetup]

Well unless I'm reading you wrong GMER no longer reports anything wrong. You also had RootRepeal showing something was wrong. Now that you've done CHKDSK I'm betting that neither of them are showing the same issues.

Normally you can set all the Anti-Virus services to DISABLED and reboot and they should no longer be an issue when using other tools for testing such as GMER or RR

All I'm getting at is that I'm guessing that you actually had disk errors that were preventing these other tools from reading it correctly and now that you've done the CHKDSK those errors are no longer present. But hey... I could be wrong.

[noknojon]

Disk Check cannot run while windows is running. You have to schedule and reboot to run it.

Hi Buttons -

The Check code I listed will restart your system automatically then run the full 5 stage check -

It does not require re-scheduling because it forces a reboot then scans -

Regards -

@ Andy - About the only thing you do not mention (as standard checks go) is sfc /scannow -----

[Andy Spragg]

Ron, I think you are reading me wrong but I'm not sure how. Going back to your original reply, you said:

If it were me (just to satisfy curiosity if for nothing else) I would FULLY remove both of them and run a FULL disk check on the local drive that contains Windows. Then download a fresh copy of GMER and do the scan again and see what you get this time.

That's what I did. I fully removed both of them (Avast and Online Armor) and ran chkdsk. It corrected some errors. After this, while Avast and Online Armor were still uninstalled, I ran first GMER and then RootRepeal. GMER found nothing, RootRepeal found plenty. This is the same result as I got before I ran chkdsk, when I had Avast and Online Armor installed. This seems to me to say that i) the errors chkdsk found were not implicated in the substantial discrepancies between GMER and Root Repeal, and ii) neither were Avast or Online Armor.

So is there any sense in running chkdsk in safe mode? Or GMER or Rootrepeal for that matter?

Noknojon, I haven't done a sfc recently, I'll do that as well.

Does anyone see anything sinister in these frequent bugchecks not giving either a BSOD or a memory dump?

Andy

[AdvancedSetup]

Well as you've already emailed the author of RR I'd see what he has to say. There are some other tools that you can use for scanning that you may want to try if you still suspect something.

There are many times a program can or will crash that do not set off a bug check report from Microsoft or create a dump.

You can try to establish an internet connection & perform an online scan with Firefox or Internet Explorer at Kaspersky Online Scanner

You can use their Rootkit.Win32.TDSS scanner, or the following boot CDs to scan with.

LiveCD for Malware and Virus Removal

Here are links to Antivirus vendors that offer free LiveCD or Rescue CD files that are used to boot from for repair if needed.

All of them except Avira are in the ISO image file format. Avira uses an EXE that has built-in CD burning capability.

Avira AntiVir Rescue System

BitDefender LiveCD

Dr Web LiveCD

F-Secure Rescue CD

Kaspersky RescueDisk

For those users that need a FREE utility to properly burn the ISO image

ImgBurn

How to write an image file to a disc with ImgBurn

Edited June 2, 2010 by AdvancedSetup
Fixed link to Kaspersky TDSS scanner

[Andy Spragg]

Ron,

I would like to try Rootkit.Win32.TDSS but the link you provided is duff (it is just http:///). I tried Googling it but all the hits on the first couple of pages refer to it as a species of malware not an anti-malware app?

I feel paranoid just relating what I'm about to relate, but this is what happened last night. I had Firefox open with a few tabs. I was not actively browsing as such, I was spending most of my time on one site (an internet radio station with text-based chat facility) and tab-hopping from time to time. At some point I needed to send an email, so I minimized FF to get to my desktop, and discovered that the Start-Run window was open. The text in the input text box, instead of an app name, was this: "owned!" (without the ""). Obviously I hit Cancel.

The potential significance of the word is not lost on me. Now I suppose it's just about feasible that some random combination of mistyping could have done that - and I'd like to think so, because the alternative seems pretty grim. On the other hand, if the whole point of owning someone is to do so undetected, why send such an obvious signal?

[AdvancedSetup]

I've fixed the link to the Kaspersky TDSS scanner.

Well I find that difficult to believe you could have done that randomly.

At this point though I have to ask you to seek assistance in the HJT forum or FDISK, and FORMAT the computer and re-install from scratch. If you do decide to re-install Windows (the safest bet probably at this point) don't forget to FDISK and remove all current partitions of the drive and then install Windows.

This forum is no longer the appropriate place to seek assistance as it's for general PC Help and you appear to be infected so you need to post in the HJT forum here or on another forum if you like.

[Andy Spragg]

Thanks for fixing the link, Ron, and yes I understand it's time to change forum now if I want to pursue disinfection rather than backing-up-and-nuking. Thanks as always for your time and counsel.

[Andy Spragg]

For the record, I've had a reply from the RootRepeal guys now (which might be worth stickying somewhere?):

Yes, RootRepeal has occasional problems with external hard drives. In order to bypass rootkits, it reads data from the disk at a very low level. As a result, it can occasionally be incompatible with certain drives and chipsets. Since external drives are connected differently from local hard drives, they are usually not compatible.

In this case, GMER is correct and there is most likely no MBR rootkit. Even if there was, unless you boot from the infected external device, the MBR rootkit is harmless. By definition, you have to boot from the infected device for a MBR rootkit to do anything malicious.

And just to underline the first point, while I was waiting for a reply, I had formatted one of the EHDDs in question so I could backup all the data to it before proceeding to nuke and reinstall. I scanned the EHDD in question with RootRepeal again afterwards, and it still identified MBR rootkit and a load of sector mismatches. So I had pretty well concluded this was indeed FPness before I got the above reply.

Can I just ask about the process of saving data before nuke-and-reinstall, if that's what I end up doing? I am wondering the following things:

• If I format an EHDD using a rooted PC, can I trust the format?
  
• If I copy data from a rooted PC, can I trust the copy?
  
• And is it OK to copy to a freshly-formatted EHDD or do I have to use non-bootable and/or non-rewritable media?