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.

Writing a Decent Application, Part 2

I'm back, on a different PC as the old one's mobo died. There's always hidden impact when one swaps PCs or "just" re-installs, such as lost passwords, bookmarks etc. that were scattered all over MS's messy user profile subtree. So it goes... also, this article is one I found tedious to write, having written the same sort of thing so often before. Once it's done and out of the way, I can get on to more interesting stuff that's come up since!

For software to be "safe", it must behave consistently with the level of risk that the user was expecting to have undertaken (or avoided). If software is not safe, then it no longer represents the will of the user, and therefore it's not secure - because even if you know who the user is, you are not getting the user behavior your organization expected.

Don't take risks on behalf of the user

Software that acts ahead of user intent, has to bear full responsibility for whatever follows as a result of that action. Examples abound; autorunning scripts in arbitrary "documents" or unsolicited email "messages", autorunning CDs as they are inserted, autorunning HTML scripts when "opening" a directory on the hard drive, exposing RPC services to the Internet, creating and exposing hidden "admin" network shares, "touching" arbitrary files on the hard drive as part of background services or persistent handlers, etc.

Display risk information in terms the user understands

Users understand data vs. program, view/read vs. run, Internet vs. my own computer files. Use this level of concept, with a "More information..." button leading to background and technical details.

Pitching this information in "your" language, such as corporate IT-speak of user accounts and so on, or raw tech detail such as file name extensions, helps some folks while alienating others.

Dumbing-down the language so that risk info is lost - hidden file name extensions, the generic "open" concept, blurring data vs. program behavior, displaying the local PC's content as if it were a seamless part of the internet - helps absolutely no-one. Stop doing that, please!

Be bound by the risk information you displayed

If a file is displayed to the user as "ReadMe.rtf" and it's internally a Word .doc with autorunning macros, do not assume an "honest mistake" and take the higher risk of running those macros.

If a file is displayed to the user as a safe-ish file type, but your generic "open" code sees an MZ marker hidden inside that indicates raw code, do not assume an "honest mistake" and run as raw code. The same goes for raw code within .pif and .bat files; if these are not truly .pif or .bat, then generate an appropriate error and abort. Yes, this will break those poorly-written apps, and force them to be fixed.

That is entirely appropriate Darwinian filtering - bad apps must die! We use settings like "Options Explicit" to trap bad code before it's released, while it is cheaper to fix; apply safety sanity checks to trap bad code after release, to limit its market success and spread.

Do not allow content to mis-represent itself

Once again, examples abound. For example, we are supposed to forget about file name extensions and trust icons instead - yet the most dangerous file types of all (.exe, .pif) can set whatever icon they like, and thus spoof any "safe" file type.

For another example, consider pop-ups spawned by web sites that look like internal system dialog boxes. Consider how the "cancel" or [X] UI elements can be coded to execute the material, contrary to user expectations.

Allowing arbitrary web sites to run code on visitors' PCs (and thus "own" them, in terms of Microsoft's "Rule #1" security mantra) is terminally stupid. It will be painful to stop doing that, because the Internet's web developers have grown to depend on the ability to poach user resources and interact deceptively or coercively with them. Pick that fight, and win it.

XP's SP2 was a step in the right direction in beating a retreat from "Ieeeee! Fore!!" stupidity ("all the world's a web page, and we are but icons in the clickstream" or "the network is the computer - so do you feel like troubleshooting a million-processor hydra you can't even access?"). If we can't get the wolves back into Pandora's Box, then (as an industry) at least have the decency to admit you screwed up big time, akin to the wasted years of trying to fly by flapping arms, or cure infectious diseases via leeches or holes drilled through the skull - and listen to what we are trying to tell you. Sometimes the answer is "nay"; don't shoot the messenger for saying so.