Here's a preview...

[PepiMK]

Updated the link in the first post; now points to version 0.1.2 instead of 0.1.1. Most important change is that it will no longer show entries identified through MaxSubKeyLen only (since the Win32 registry API can deal with that, it cannot really be used as a rootkit exploit anyway).

[SpeeDemon]

Microsoft has a tool called Rootkit Revealer that seems pretty solid.

Any differences in their program vs yours?

I'll say that yours LOOKS nicer, at least in a few of the screens

[129260]

@129260: Spybot-S&D always had some basic rootkit detection mechanisms, but the latest updates improved on three important fronts there.

Spybot-S&D usually detects threats in our database only; RootAlyzer just shows any things it identified as hidden, without relating them to known malware. So you could use RootAlyzer to detect even rootkits that are not known yet; but one of the new plugins for Spybot-S&D includes kind of a rootkit heuristics (which is not as generic though).

In summary: use RootAlyzer if Spybot-S&D hasn't found the culprit and you're suspecting an unlisted malware.

I gotcha

[PepiMK]

Zero-char detection has been added to 0.1.3.

Pre-selecting the system drive instead of always C: has been added to 0.1.3.

The "Invisible processes from handles" is indeed a bit slow - reading the list of all system handles isn't a standard Windows operation and takes a few seconds, depending on the number of applications running. Unless we would check the process list for each handle while it is checked, which would not be performant at all, there's always the chance for a small out-of-sync effect.
Maybe we should add a message box telling the user to not open or close any application until the results appear.

As for the "odd commas" (if you refer to these between rootkey and keypath, and between keypath and value name), that's SBI format, and expected.

An exported reg file might indeed help, please send to , using "RootAlyzer; for PepiMK, see forum" as subject

[ddcc_7]

I've sent the email.

Would you consider adding an option to select which registry hive to scan, like the file scanning, so not only is there precise control over individual hives, but also the ability to turn off registry scanning if needed.

[PepiMK]

Just to keep everyone up-to-date, I think I've finally been able to reproduce the problems for example ddcc_7 reported - on Windows 2000 (the same registry keys do not cause any trouble on XP), and fixed them.
It was kind of similar to the problem with detecting registry keys: in rare cases, RegQueryInfoKey returns "0" as the maximum length for the name of any values inside a key (lpcMaxValueNameLen). While I see this as a possible trouble cause, since even regedit is able to ignore it, it shouldn't be mentioned here though.

I've also added that missing feature request to the bugtracker:
Select list of reg hives to scan

As for interpreting the results, only 0.1.3 will start having the "Details" column filled, and then we will have to add a helpfile providing more details on what these short "details" mean