Disappointed with BOClean--Again

Just did a clean install of BOClean 4.20.001. I found:

* It still allows itself to be terminated easily. (I know there are excuses flying around as to why this doesn't matter.)

* It allows multiple copies of itself to run. You could say that this wouldn't normally be a problem, but come on, it's just good program design to handle that sort of thing, especially with this type of application.

* I hate the "Automatic cleanup" options, so I tried disabling them. BOClean would have none of it. I uncheck those options, but if I merely open the config window again, they're checked again. Annoying.

Personal attacks will be ignored. But by the way, to any SOAB who would accuse me of it, NO I did not obtain a warez copy of BOClean. I'm a paying customer.

 

A refund can be obtained for BOClean. You may want to try Ewido as you can download a trial.

 

Hi xxxxx,

I have not looked at termination yet, but i can confirm your other observations.

Nick

 

In fact, try terminating a few of those multiple instances and watch what happens in your task manager.

Nick

 

I use Sysinternals Process Explorer instead of Task Manager, but with it, I can kill any instance of BOClean.

 

Did you inform Kevin about your observations?

 

No, because with the potential exception of the problem with the "Automatic cleanup" options not working, it won't do any good. I'll just wait another three years and check back, just like last time.

 

I guess I'm just missing the point here. For this to be a real issue, a malware process has to be already running to kill BOClean (or anything else). That process should be dealt with prior to that event.

I don't see the issue aside from the nonpersistence of the automated cleanup selections (yea, that should be fixed assuming whether it is an operational problem and or a GUI state problem).

Blue

 

Apparently you are not interested in solving. In that case, I'm no longer interested in this thread. Goodbye.

 

try unchecking it, then shutdown BOCLean and then load it again...

 

My DEEPEST apologies for any unhappiness - despite the efforts of nearly 600 beta testers and our own folks, everyone (including myself) ran the code through its paces and pronounced it "soup."

I'm even sorrier to hear that you seem to have so little faith in us. Just to provide a bit of perspective, I'm 55 years old myself and have been at this "software" stuff since the 1970's. Nancy goes back even further to the 1960's with the IBM360 and the "PL/1" programming language. We've got a few other folks here who've been at it almost as long as we have and a few that have only been doing it for a couple of years. A rather nice bunch of folks here with one "prime directive" ... getting it right the FIRST time. Then again, when you have experience in coding, the other reality is "there's ALWAYS one MORE bug." That's why there was a BOClean 4.12.002 and a 4.11.003. However, unlike many other vendors, we actually CARE if things work and when there's a problem, we actually FIX them instead of saying, "we'll take care of that in the NEXT version." That's UNACCEPTABLE here.

Each of the things you spotted are actually REAL problems in the original build, and I've also verified them. It would have been REALLY helpful though if SOMEBODY had sent an email to support(at)nsclean.com and let us know, in order that this would have been solved ALREADY. As much as it's fun to hang out in various groups and see what various moderators will put up with, the only REAL solution to anything unfortunately rests with us. I have yet to see a group that's able to fix bugs in software when they don't have the source code to do it with, and we're so insanely busy that the various groups just ain't the right place to make us aware of a potential or actual problem.

Absolutely spot-on about those checkboxes. In fact, we found a couple of others that were spotty. FIXED. Wish I'd known about this prior since we already did a "fix build" and began distributing it as soon as we became aware of some problems you didn't manage to encounter that others did based on the severity of OTHER, more significant problems that some people ran into that never showed up here. And it's been an education for us as well into places we never wanted to be.

There were actually LARGER problems with the first build:

1. If you popped open the menu and didn't move it when the box suggesting moving it to the location you wanted it in, Windows returned incorrect sizing information that left folks with just the title bar and no buttons. And folks didn't realize that they could have resized it back and those would have stuck. OUR fault. We should have checked that. However, nobody managed to do the right sequence of events to make it obvious.

2. BIGGER problem! Those running NT 4.0 or Win2000 (which sadly *is* NT 4.0 with lipstick and not much more) never got BOClean 4.20 to run at all. As soon as they started it, it crashed, and crashed HARD. That problem turned out to be a bug in Microsoft's "dotNET studio 7" and the way the compiler works. If you try to create 'undecorated extern "C"' output, then the damned compiler generates bad pointers and bad packing which caused BOClean's DLL to point to outer space. Doctor Who's phonebooth magically turned into a telegraph pole. We had to rewrite both the DLL *and* the EXE to force use of some mighty clumsy export calls because the undecorated C exports caused the compiler to blow chunks. ("Chunks" is the dog next door, heh) ... THAT was a biggie.

3. Despite BOClean having been designed with both a MUTEX limit and a FindWindow code to check for additional instances, turns out that XP itself has a bug in that a startup for the local machine creates one layer of kernel space whereas any other startup starts in an isolated stack space. As a result, the separate "desktops" can't see one another and even with the protections we provided, more than one instance can start if the conditions are just right. When the kernel is "rootkitted" by other security software, then the proper pointers to such information is invalid. I'll say a bit more about this further down because the damned number of "legitimate rootkits" as a moron's solution to security software is TRULY getting out of hand and causing more HARM than good.

Then there were the things you noticed which I only WISH I'd known about when we did the rebuild while our telecomms were down. That in turn will incovenience everybody even more now because I've just rebuilt BOClean AGAIN as a result of what you reported and that will require everyone to go through all this again for an "002 build." Not that I'm scolding you or anything - seems the natural response these days where most vendors don't care is to come to the groups where you'll get an answer. Once again, I'm sorry for whatever happened three years ago where your email apparently got lost somehow or was never delivered, but we're the exception to that rule. We really *DO* care if things work, and it's our own "golden rule" here that nobody goes away unhappy. There were other less subtle things that never showed up in "beat-a-testing" which have also been resolved in the "002 build" which we will release in about 12 hours or so from my happy fingers now - once they've been tested against all combinations to ENSURE this will be the end of the madness for the few who have suffered any.

Now ... about those "legitimate rootkits" and an answer as to why we will *NOT* do "termination protection." There's a DAMNED good reason for it aside from the obvious "what if BOClean needs to die and it won't LET me stop it?" scenario ... a wee bit of "edumication" may be needed as to WHY it's a bad idea for US to pile onto the "sacred mantra" ... I wrote an article a LONG time ago about a particular trojan named "BioNet" ...

http://www.nsclean.com/psc-bionet.html

In that article, I placed the blame on Microsoft failing to provide a means to interrupt such a call. Another programmer wrote some demonstration code which called me wrong - that anyone who can hack and replace the kernel could intercept same and eliminate the problem. And while he was correct, it entirely missed the point - that the operating system SHOULD provide at least a notice similar to the system shutdown calls that would allow a program to kick back with "no, I know what you want to do and let's throw up a window asking the user if they REALLY want this proggie to die." The concept missed the point of my plaint entirely. If you can refuse a call to "system shutdown" then you should be able to refuse a call to "external killing." I'm sure if an end user wanted a program to die, one more click as protection wasn't too much to ask. Click YES, and the program dies. Not offering a choice though was always a bad design in Windows, and I *stand* by those words today as well.

THE SOLUTION? ANOTHER DAMNED ROOTKIT

And that IS the solution for so many. Process Guard IS A ROOTKIT! ZoneAlarm installs ANOTHER rootkit. Norton, McAfee, NOD32. Rootkit. MADSHI's code (as used by our competitors) is a ROOTKIT. So now folks are installing rootkits up the wazoo. Only problem is that aside from Process Guard, these rootkits ONLY protect the one program and nothing else. So my OWN advice is that if "termination protection" is SO important, then PAY for ProcessGuard. ONE rootkit that protects LOTS of programs is the sanest way to do this. And THERE is the reason why WE don't do it too. Each rootkit you ADD only makes things WORSE!

And that's ALSO the reason why all of the "big vendors" have gone to "suites" ... that way ONLY ONE ROOTKIT. That's also the reason why using multiple antiviruses and antitrojans can be a problem where they have rootkits. Here's why ...

Folks don't really understand what a "rootkit" is all about. Let's try to explain it so it makes some sense ... and why MULTIPLE rootkits is a really really bad idea. And the reason why we just don't.

The kernel has various functions which are made available to all software that runs on the computer. Things like OpenFile, WriteFile, WriteRegistryKey, and many other functions. The kernel exports and address in memory to be called in order to access these functions, often somewhere around 0x80000000 or higher in memory. When you call the function, you get instant gratification.

A ROOTKIT will "hook" these addresses and redirect the calls to their OWN code ... so now, the original function at say 0x83215362 is now being diverted to 0x32132132 or some such. Purpose of the hook is that when you call "OpenFile," some OTHER program points to itself and wants to see what you want "OpenFile" to do ... if the rootkit approves of what you do, it will eat CPU time to figure that out and then *IT* will call 0x83215362, examine what returns, and then decide whether or not it will let you see it. OH, the CPU cycles eaten with every disk access when you've been rooted by a "security program." We're talking taffy response already. Now add some MORE rootkits that snatch the 0x32132132 and point it at 0x56212312 and let yet ANOTHER rootkit have a sniff. Diminishing returns, SLOW computer.

But that's not the worst of it. When you have multiple rootkits, you also have a far easier ability to exploit a buffer overflow, smash the stack or any malfunction in any of those hooks will splash on others with the end result being the ability of something to smash the stack and sneak past all of it. Rootkitting as a solution to security ISN'T one. You'd be FAR better off watching the traybar icon go byebye than suffering the performance hits or conflicts of too many rootkits. And there's the reason why our "big customers" who pay for the general public to get free upgrades after nearly ten years now BEGGED us not to do it in BOClean. And from my own experience, I'm glad we never did.

I mean look at all the nonsense we've been blamed for between ProcessGuard and NOD32? The only MAJOR changes from BOClean 4.12 to 4.20 were in doing away with our old user-level hooks and just going to a kernel driver for system notifications. We got tired of ZoneAlarm and others claiming that we were secretly stealing "Windows messages" and that we MUST be a "keylogger" because their own cluess programmers did a barebones bogus hook detect without ever figuring out WHAT KIND of hooks they were detecting. Then the PG/NOD32 debacle and other reasons to just rewrite our deepest engine pieces to just plain get out of the way.

NOTHING changed (as folks might notice) in the "user level stuff" which is why we missed those details about the checkboxes in the config menu - apparently that wasn't right in 4.12 either, and nobody ever noticed.

But there's the reason why there's no termination protection in BOClean - for those to whom this is important, BUY ProcessGuard. It's about the best rootkit we've seen and no point in re-inventing the wheel. And I'm sure Wayne and Gavin will attest now that they've stabbed TDS that we're about as good as it gets and our stuff and their stuff makes a pretty good "team."

But no, we're *NOT* going to write yet another rootkit. Too damned many of them already, and sadly the "bigger names" have genuinely TWADDLED it.

So ... all said and done, I'm TERRIBLY sorry that the code *I* wrote disappointed you - now that I'm AWARE that there was a problem, I can assure you that all this disappoints ME even more. 4.20.002 has been written and all of the testing we're doing on it has been solid - once our office folks get in here in a few hours, Digital River will get the new code uploaded first for those with the "extended download" service so they can go and once again collect the new one - and it will be available to everyone else from the upgrade(at)nsclean.com site by this afternoon US Eastern time for emailing with my most STRENUOUS apologies to all. If ONLY someone had TOLD us there was a problem, we'd all be HOME by now.

But I offer this - if someone has a problem, we'll FIX it! It's not like I'm gonna find another gig at MY age, therefore ANYONE who is unhappy has my undivided attention ... as long as I actually RECEIVE their complaint.

 

Again I say:

WOW!

Regards

 

Thanks Kevin.

 

Well, if that doesn't demonstrate a level of customer service second to none among vendors in this market, I'm not quite sure what would...

Blue

 

You are assuming that only malware can kill BOClean. I'm also concerned about accidental termination, though. For example, I use a couple utilities that close and kill applications. One of them is the semi-well-known utility from PC Magazine, EndItAll.

If I run EndItAll with TrojanHunter Guard running, I have no worries. It can't kill TrojanHunter Guard. But if I run it with BOClean running, it kills it without a problem.

This is where someone screams at me that it's my fault if I do that. My response is that I shouldn't have to worry about it. KAV won't let me kill itself (accidentally or otherwise), and tries to prevent malware from doing it as well. Same with NOD32. Same with TH. Same with ... others.

I shouldn't have to worry about BOClean not running just because I forgot to exclude it from manual termination. This is my firm opinion.

Besides, even if you are talking about malware ... what if it is malware unknown to BOClean? BOClean could miss it. If the malware succeeded in killing BOClean, then even a database update (which would add detection) would do no good. But if BOClean didn't let itself be terminated, there is at least a fighting chance that a future database update would allow that malware to be caught. Unless I am missing something.

 

Who needs your sarcasm? Not me.

 

Thanks for the response, Kevin. I think you're using the term "rootkit" when you really mean "kernel-mode driver", but I guess that's for purposes of comprehension. I'm too tired to digest all that discussion at the moment. But I can appreciate the increased slowness and potential stability issues caused by adding another kernel-mode driver.

So was the multiple-instance issue a bug?

Sorry for not sending you an email about these issues.

P.S. It always makes me feel just a little bit assholish when I read a response from you that describes how overworked you are. I didn't mean to bother you.

 

I really don't think you're missing anything, it's probably more a question of personal preference of how things are handled and expectation.

For the record, I do use an application which will trap most/all efforts to kill an application, so I do have that basic functionality available, but it is through a separate application and I have seen some of the underlying conflicts mentioned by Kevin at work when the moons align and applications decide to fight it out within the OS, so I'm fine with the status quo here.

Blue

 

Heh. "Trojan Hunter" and "anonymous" in the same package ... heh.

No, I mean ROOTKIT ... a "kernel driver" does NOT redirect system calls to outer space, just to make that clear. I said "ROOTKIT" and I *meant* ROOTKIT ... EVERY rootkit diverts system calls to their own code and own purposes. I *really* want to make that point clear as it's ESSENTIAL for folks to understand the difference. WE do a "kernel driver" which asks for a "notification" but we do NOT modify function call addresses. Since you named a "competitor" who depends on Madshi's rootkit, it becomes all the more essential to indicate the difference, but that "competitor" is not alone. OTHER "competitors" mentioned also make use of "rootkits" that are also found in many trojans. Needed to get that out of the way.

"Multiple instances" a bug? Yes indeedy ... shipped "gold" with XPee ... each "user space" is its own "desktop" and one desktop cannot "see" other desktops in XPee ... it's all about "desktops" or what we refer to as "GUI versions of NT "consoles" ... if you open a bunch of "command prompt" windows ... does one show what's happening in the others? This is identical to the GUI "desktops" that using the Internet Explorer shell on your XPee desktop is like ... even if they DISPLAY on the same background, each invocation is another "desktop" in a common display. Did we work AROUND Microsoft's "bug?" Yes indeedy.

Forgive my flippance here - another 38 hour day.

But one of the amusing things about my near "geezerhood" is that I watched Neil Armstrong "do the moonwalk LIVE" on teevee, and I was around for the early days of "Winblows" ... and 2.0 was monochrome and about as stable as nitroglycerine, and I actually LIKED Windows 3.1 16 bit. It was pretty cool for its day. STILL use it, and the stuff we make STILL supports it for all five people still running it. Heh.

But I was ALSO around for the IBM/Microsoft project which became IBM's "OS/2" (both red and blue boxes) ... it was IBM's engineers who figured out how to create "protected memory" and if one application qwapped the bed, the machine didn't HAVE to reboot. OS/2, despite Microsoft's FUD campaign against it was MIGHTY robust for an early 16/32 bit OS ... and when Microsoft screwed IBM enough that a divorce was in order, turned out that IBM made the operating system that worked (it was HIGHLY hardware specific though, and each device required its own "kernel driver" and if you had hardware that DIDN'T have an OS/2 kernel driver, you were SOL) ... and when IBM and Microsoft went their separate ways, IBM took THEIR working code, and Microsoft got stuck with their broke-ass chit ... NT 3.0. Hahahahahah.

Fact is though, Microsoft's NT never was quite what it promised to be and all the way up to Win2000, NTee was a pathetic joke, right down to their Macintosh fork functions in NTFS otherwise known as ADS - a problem they have YET to fix.

But when Microsoft released XPee (Xtra Pain) they downright STOLE the OS/2 code and that's what y'all have now ... SEPARATED memory, SEPARATED processes and the ability to go through what you saw there. Maybe "Blista" will incorporate something new. Doubt it though. Heh. Sometimes having been around for the moonwalk and seeing all the "history" in between close up creates a bad attitude.

And hey, no problem about not sending an email - I'm saddened CONSTANLY by the way other vendors do things in a complete lack of "it's SUPPOSED to work" and even sadder, I've had to deal with "Bangalore Bob" and other clueless support folks who read what's in their five pages of rote "book response" which is neither helpful nor a solution. We're kinda different here. Those of us who WRITE the code are required to answer the PROBLEMS. A rather unique "tight loop of responsibility" here ... "don't wanna do support? Then don't PHUCK it up in the first place!" ... and by doing so here, if I write bad code, I have to explain myself. OH the incentives there are here to not phuck it up in the FIRST place! Heh.

But yeah, even though it wasn't *I* who caused that problem, it was STILL in my face and I found a way to make it go away. And in the end, ain't that what it's all about? Bury the bones at ANY cost! (grin)

So yeah, I screwed up. About 6 or 7 hours from now, 4.20.002 should be available ... give it a shot! Our folks are still using baseball bats on what I expect is what Regis Philbin on "Millionaire" here in the states would say ... "final answer?"

 

This looks like a classic calling convention problem rather than a problem with the compiler. You might want to carefully review your products code genaration settings especially if you upgraded your solution from a previous version of Visual Studio (C code should be compiled as such, for C++ code applies the same). In addition the compilers calling convention setting should be consistent with the one used in the code (the defines are adjusted automatically most of the time). Most important point is that the calling convention settings for the Exe and the Dll project should be consistent. The appropriate topic in the MSDN library covers this topic and the resulting problems pretty well so you may want to have a look at it. I shudder trying to imagine what "workaround" you may have implemented.

Congratulations, you apparently discovered WindowStations! Wouldn't call this a bug, though...

You apparently are some special kind of person, if things like this happen to me I always assume I goofed...

 

OH how I wish people were willing to buy software like they used to ... you sound like someone who'd be PERFECT working here - and the beauty is unlike MOST software companies, the vast majority of us work from home and all we gotta do is hit the server, do what is needed today and it's over. If "today" bites the bag, then it's a 40 hour DAY ... but if things is calm, we get chains of days with nothing better to do than surf porn, hoping to get us a fastclick.net "surprise" from IST or CWS. Heh.

But yeah, what truly saddens me is that it would seem that every "new" idea from Microsoft is 20 years old and bit the bag back then. Why can't they just LEAVE dem dry bones along and let 'em rot in peace?

But yeah ... TRY to find a windows station with an "EnumWindows" ... heh.

 

Well ... you're RIGHT in a way ... but here's what happened since you're into da geeky, I'll toss it out. First off, we've ALWAYS written our stuff in ANCI C and used Borland's CPP to do our magic. Beauty of Borland instead of Macrosquish is that you can write REGISTER based code (ASM's cool and all, but actual CPU rip is even BETTER since it allows you to get PAST the kernel right down to the CHIPSET, and that's always been our "big magic" here. How can USERMODE code outdo a rootkit? When the CPU dumps the OS to listen to *YOU!* Heh.

Sure you can root an OS, but isn't it better to just BYPASS the damned OS and avoid ALL the limitations?

What happened was nothing short of amusing. Seems that the CDECL vs FASTCALL for convention on a DLL export overrides reality. And the 'extern "C"' wrappers for JUST the exports don't work properly in dotNOT ... what we WANTED (and THOUGHT we'd gotten) was a CPP compile with extern "C" exports. Even an "alias table" ... nope - either you EAT the damned functions@QWGLYUIQGWYI and code that into your callers instead of "LoadLibrary("functions") or the compiler generates pointers to Satan that will NEVER call your code.

Yeah, I think Bill Gates is a pederast ... I'm no lover of the suckhole that stood up before MY Altair convention and scolded us for stealing the code HE stole from Stanford, but I digress. If *I* call for CPP modules to be compiled, I expect that the CODE will be compiled properly and the ONLY issue is the EXPORT tables. dotNOT phucked it up.

That all said, *I* shipped the bad code. *I* phucked it up as far as BOClean goes ... but I *do* insist upon an oatmeal cookie because HE pushed me into the mud. Moo.

 

Oh by the way Kevin I`m gonna get meself a program of yours in the near future...and thanks for the informative posts.

 

If you are implying that I am somehow associated with TrojanHunter... Please allow me to prove that I am not. In a recent flash of stupidity, I coughed up $50 for TH. I'm still kicking myself in the nuts for doing that, without running the trial long enough. TH's bugs seem to be ignored, and their support Sucks with a capital "S".

Will this be emailed to eligible customers, or will I have to request it again?

 

...I'm not looking to get any TH fans' panties in a wad, I am just pointing out the unassailable, obvious truth that TH support requests get ignored, or, at least, seriously delayed. You can see it in their own forum. (By contrast, Kevin replied here, which isn't even his own forum, multiple times.) And emails I've sent regarding TH were similarly ignored. So if someone wants to scream at me for pointing out the truth, and make me apologize... Ain't gonna happen.