Monday, February 28, 2005
Friday, February 25, 2005
Portait of an Asshole: those that add the same shit over and over just to keep their blog near the top
Man talk about abuse! Here's what I don't get: who in their right mind would buy anything from someone who behaves as though s/he doesn't give a fuck about anything other than making $20 here and there? Someone who replicates the same ad every 5-10 minutes is, by definition, an asshole! He's wasting storage, bandwidth, server capacity, probably 20x what normal users consume, but does he give a rat's ass about any problems he causes? Hell no! He'll send 1,000,000 annoying spams to make one sale, why? Because it costs him nothing. It costs others dearly, but that's not his concern. Only a real moron would send money to someone that abusive.
Thursday, February 24, 2005
[this is a logical continuation or my last post, berating MS Anti-Spyware...] There is a tool/technology that's sorely needed by spyware/virus removal tools, but is conspicuously missing from anti-malware offerings, mostly due to licensing issues, it would seem. The technology is called a Pre-installation Environment (PE) that boots a functional O/S exclusively from read-only media (such as a CD/DVD.) Happily there is a tool that makes it reasonably easy to build such a boot disk, called Bart PE, it's free, I highly recommend it. It took me about 40 minutes to build my first Bart PE CD. I've since gone on to make several other bootable CDs and DVDs... can't imagine having to do without it now. The reason it's so necessary for effective spyware removal is simple: it's very difficult (perhaps even impossible) to completely remove a malintended process once it's running, it's just way too easy to dump another executable from a resource or create a copy of itself and spawn it before being forcibly shut down. It's even possible to attach a thread to another process. Plus the number of registry locations that can be used to facilitate activation of code is severe. Who would be in a better position to succeed at this than Microsoft? Maybe they haven't really even tried yet, but I can tell you for sure, their current anti-malware product is inadequate. So, you may be asking, what have I done about this besides bitch and moan? For one thing I've created a BartPE disk, that has an Undelete program, the original RegEdt32.EXE, Nero 5.0, Partition Edit and a few other essential utilities. It makes clean-up and/or recovery a much simpler prospect. I've also had some success with some AV software, but the glitch is getting current AV definitions on the fly in a place they can be used. I've also written a couple of partner utilities, that make removal of spyware somewhat painless, and genuinely successful, from within PE. One of them loads (and unloads) the software and user hives under specifically named keys, allowing access to an infected system's registry from within a PE session. (The PE has it's own registry, of course.) This makes it possible to change the registry used by one system, from within another, without the infected system running. Its partner (which has carnal knowledge of those specifically named keys) allows me to recursively deletes registry keys from those loaded hives, by passing the original keynames to it on the command line. For example, let's say you want to remove the key: HKEY_LOCAL_MACHINE\ Software\ Classes\ DyFuCA_BH.BHObj, (which is used by some filthy malware crap) and all of it's subkeys from an infected system's registry. The loader tool loads your infected software hive under the key: HKEY_LOCAL_MACHINE\ offline_HKEY_LOCAL_MACHINE_software Which means the path to the [temporarily] physical key location is: HKEY_LOCAL_MACHINE\ offline_HKEY_LOCAL_MACHINE_software\ Classes\ DyFuCA_BH.BHObj The remover tool accepts the original keyname, but removes it from the loaded hive: DELOFFLINEKEY "HKEY_LOCAL_MACHINE\ Software\ Classes\ DyFuCA_BH.BHObj" The remover tool adjusts the key that's passed to it, which makes it much easier to turn the output of a spyware removal tool into a batch file. (You can see why I won't be going public with these tools any time soon.) [to be continued, if interest exists...] -MM
In the immortal words of James Hetfield, from the rock group Metallica, "it's so useless, heh hyeah." This, I believe, is axiomatic: if spywarexyz is detected, and then "removed" by an anti-malware tool, but on the very next boot it is detected again, then it wasn't really removed, was it? Claiming to remove the same [n] threats time after time is just plain dumb. Counting them incrementally -- claiming to have removed hundreds of threats, when in real life, it hasn't removed any -- now that's downright asinine! It just refinds the same infestations, pretends it has mitigated the threats, and assumes success. And then it wants credit for a job well done, riiighht. Process integrity? I think not! How hard would the tiniest bit of heuristics have been? A little internal effectiveness check? Some reason to believe you're doing absolutely anything more than putting the user on a treadmill? Maybe keep some stats on in-the-trenches workability? Wouldn't a level of tracking capable of detecting false success be both relatively easy and very important? How else would you know if/when it became appropriate -- call me crazy for this one -- to perhaps regroup and change your attack posture, because it has become overwhelmingly clear that you have FAILED, Microsoft, Giant... who-the-hell-ever, you have failed, most miserably and horribly... it's like a bad joke. Notice my expectations above made no mention of actually delivering an effective tool -- that seems way too much to expect at this point. Possibilities:
- Why couldn't there be a special system mode, entered when shutdown is initiated (and invoked prior to shutdown as a user option) that locks the startup areas of the registry from updates and inserts? Allow read and delete so tools or techs can remove unwanted crap, and that's it, until the system restarts. What legitimate reasons could there be to alter such things as the system is shutting down?
- How about a way to block/prompt for any process that performs i/o in response to shutdown, giving the user a chance to allow or ignore the i/o?
- How about a log of all processes that either abort or initiate shutdown? Or better yet, give the user the final say, "Process xyz.exe has returned FALSE to WM_QUERYENDSESSION, do you wish to allow this, or should it be killed now without further notice?"
- How about a special kill function, that neither gives the condemned app an indication of what's about to happen nor ample time to react. Unconditional full disclosure may be in the apps' best interest, but it isn't always in my best interest. I'm the user, it's my hardware, doesn't that count for anything?