The Joy of NirSoft

The unfortunate thing about NirSoft is that whoever's sitting on the ".com" version of http://www.nirsoft.net is a tad creepy - something that I'm sure impacts adversely on NirSoft's rep. The "real" NirSoft is home to the most beautifully detailed integration management tools, which work well within the Bart environment (more on that later, heh).

Many of these tools not only list the integrations they watch, but allow reversable management of them as well. This is very useful when troubleshooting issues like "why does my PC dial out when I list files in My Computer?" or "why is it so slow to list files?".

Now there are tools that are great to have around, and then there are tools that you use so often they become as familiar as your favorite ballpoint. Then there are tools you've had for ages, but only recently started using, as you hadn't really thought of them before.

Some tools that I'm using a lot at the moment are:

NirSoft Registry Scanner, which searches the registry for something and then lists all the occurances, each of which jumps into RegEdit at that particular item. One gets so used to Start, Run, RegEdit and then search, that it's hard to switch that habit to running this instead, but it's worth it.

Sure, searching the registry takes the same time either way, but it's easier to double-track jobs if all that overhead is imposed in one go, rather than between each "next", and it's easier to keep track of what you're doing if you can quickly edit each occurrance one after the other. Also, seeing an overview of what's found can change your strategy; it's obvious when you've cross-searched something you didn't want to find, or when you're about to bite into the tiger's tail (say, "330 items found" - do you really want to eyeball them all?).

Paraglider's RegShot takes snapshots of the registry, compares them, and provides a .TXT log that can be trimmed into a .REG that will apply the differences. It's from http://www.paraglidernc.com/RegShot.html and is a modified continuation of the work of another (as credited on the page).

Now I've used this sort of tool long ago in the Win95 era, and didn't find it useful; I either got too much "noise" (fluff settings such as which desktop icon was moved 2 pixels to the left, etc.) or an incomplete result that left out half the changes I'd need to apply. But whether it's a better tool, or improved registry operations in XP, it's now an approach that works about 90% of the time, when you have an interactive setting that you wished you could automate via a .REG:

1. Undo the changes you want, Apply
2. Take the first registry snapshot
3. Make the changes you want, Apply
4. Take the second registry snapshot
5. Compare, Save, edit to commented .REG, Save As

If the OS had this feature, we'd have less need of tools like this; but, etc.

Dependency Walker tracks what a particular code file depends on, and is from http://www.dependencywalker.com/

You know the drill; you scrape over some program, run it, and it says "needs blahblah.dll", so you Find the latest copy of that on the source system and drop it into the program's directory. Then you run it and it says it "needs blah27.dll", so you etc. This can go on for n iterations, during which point you start to wonder whether the effort is worth it.

Dependency Walker would have been a better approach there, because you'd have a better idea of what you're up against. Sure, you may have to repeat the process when added code libraries reveal their own dependency fan-outs, but at least you are seeing one level at a time, and not one item at a time. After a while, you'll get a feel for the relationships between code libraries and the issues associated with them, and that's good knowledge to have.

Paraglider's RunScanner is a fundamental brick in the process of building a maintenance OS; it allows programs to run as if a different set of registry hives were in effect. The full ramifications of that are Beyond The Scope Of This Post (or "left as an exercise for the reader") but what it does is facilitate the formal use of tools that assume they are being run "live" from the installation you are trying to formally approach.

By "formal", I mean by not running any of the code under scrutiny; one of the most basic tenants of tackling malware, right up there with "don't write to the drive" for data recovery. Sure, most of today's approaches to malware are informal; they also don't always work (as in "Blah-Blah AntiVirus for Windows says it found XYZ, but can't clean it!"). The relationship between these two points is not coincidental.

NirSoft's Windows Update and JRE Listers fulfill a common need; to quickly assess the patch status of a system. This is particularly important with Sun's Java Runtime Engines, given that Sun doesn't remove old engines when installing new ones - and yes, the old dumb-ass exploitable engine is still left available to be (ab)used by malware.

Speaking of "code of the day", it seems as if Firefox is discovering the pain of patching isn't a Microsoft thing. There's been a new revision of Firefox most months, which looks a lot like Microsoft's monthly patch release cycle, until a longish spell between 1.0.4 and 1.0.5 - then 1.0.5 was almost immediately by "antidote" 1.0.6, all of which suggests that a certain degree of complexity plus edge expose will inevitably lead to code churnover and quality issues.