Some Superantispyware questions

Hi

Can I ask if anyone has noticed any system slow down running Superantispyware Pro?

Currently, my recommended security system is been Nod32 & AVG anti spyware. Since AVG has not updated their system to run with Vista, it has prompted me to look elsewere. I've noticed though that AVG AS (Plus) does seem to slow down lower spec computers

Also I'd like to check if there are any issues downloading updates through Microsoft ISA Firewall? Most of my customers run computers on an SBS2003 network & use ISA 2004 on the server & the ISA 2004 client on the desktops. It seems that AVG AS will sometimes connect to download updates, but will always have problems if there are more than 15 AVG AS computers on the network. Checking with AVG, they say that their product is not supposed to work at all with ISA. If I change products, I need to make sure that I won't get the same issue with SAS.

 

SAS shouldnt slow you down.
i dont have it active on my pc due to the fact i dont really need to with kis6.0
lodore

 

Hi Biscuit

I do not know the answers either but you could always ask at their support forums in the general questions part of the forum>>>
http://forums.superantispyware.com/
HTH

 

Thanks, I've asked there but I think manufacturer's forums are often going to be biased.

 

Actually I answer everything with complete honesty even if it is not the "best" answer for our product - as far as system slow down, you should not notice any impact while using your computer. If you watch the task manager, you may see our process using "slices" of time to perform real-time protection - you may not see this with other products as they do it at the kernel level (we use a combination of user/kernel) and thus those are not recorded by task manager.

If you (or any user) is running other products that use filter drivers (McAfee, Norton, CounterSpy, etc.) then when you scan it may appear "slower" as the other products are scanning everything we are scanning - this is an unfortunate side effect of having kernel filter drivers that perform scans - they always scan, so essentially you are "double" scanning. That is the only type of "slowdown" we have seen, or experienced, or recieved comments about in our forum and support system.

 

I've heard good things about SAS and I am currently trying it out. I've only had it on my machine for a day or two and so far, all I can relate right now are my first impressions. As to the effectiveness, I can't say, other than what I've read . I have not heard much about how good the realtime protection is, but for my likes SAS uses too much CPU. I continually see CPU spikes when in idle mode and this is annoying for me. I assume it has to do with the time slice processing you mentioned.

I also use Spyware Terminator which I find less disturbing with its realtime shield. I will probably turn off realtime protection for SAS and keep ST's shield unless someone can convince me that the SAS realtime protection is much better.

I also ran RkU and did not see any kernel hooks being used by SAS, which you seem to indicate that it does. ST uses a total of 11 hooks which is probably why it does not have to rely on so much CPU

Any plans on improving in this area?

Thanks, Al

 

The drivers(x3) are there

http://img294.imageshack.us/img294/2484/driversgg9.jpg

Maybe you are confusing hooking the SSDT

SAS is not HIBS type software so does not work in the same way

 

Hi fcukdat,

Thanks for the clarification. Yes, I was only looking at SSDT . I just wished that the CPU usage weren't so noticable. I guess I could remove my cpu monitor from my desktop

Al

 

The spikes are only noticable in task manager as it is taking a "snapshot" for a small slice of time - ANY APPLICATION, DRIVER, SERVICE, etc. that does ANYTHING on your system uses CPU time - you don't see the "spikes" are the kernel level - just because ST hooks the SDT (or other methods) does not mean it works better than SAS's real-time. It could be using lots more processing power and you would not know it. The "watching the task manager" method is really only good for seeing if a process is using the CPU at a high % for an extended period of time. The spikes really mean nothing in the overall performance of your system.

We have our own proprietary methods for direct kernel access that don't require filtering every function call, etc. such as drivers that hook the SDT, etc.

If you are running ST and SAS I would leave both real-time shields on, unless you see a big slow down, as ST will catch some things we won't and we will catch some things ST won't - that's just the reality in the spyware game.

 

I understand what you are saying about the CPU spikes, but it left a bad impression on me after seeing it. Even though the spikes mean nothing to the overall system performance, it would be neat if you could hide this small quirk from us dumb users. Then you wouldn't have to explain it so often

Is this asking too much?

BTW, not taskmanager, but this http://i17.tinypic.com/2drylft.jpg is what is distracting me .

Al

 

Users aren't "dumb" - I believe it's just a process of proper education. I would rather take the time to educate the users as to the what/why/when/how so that you, the user, can be learn and become educated and spread the correct word when you talk to other users and pass along the knowledge.

In my opinion, "hiding" things is not a proper solution - education is - that's why I take my time to respond to posts on the various security forums and write my blog which covers a wide set of topics - the CPU and Memory usage topics are forthcoming.

You, and other users, might find some interesting reading here:
http://superantispyware.blogspot.com

 

Ok, I don't want to beat this to death. I was just trying to relect my impressions as a first time user. Now that I've been educated, I still don't like what I'm seeing . Even though it is only a cosmetic issue, I would find your product more attractive if I did not see the spikes. Maybe others feel the same way, maybe not. Thanks for taking the time to listen to me moan .

Al http://i17.tinypic.com/2drylft.jpg Adric

 

I understand your impressions - I completely explained the issue. If you really "became" educated by my post, then apply the new knowledge to the problem at hand

Is your desire to protect your system, or watch the CPU meter? Just curious?

 

I use a different approach. I have antivirus and antispyware set to run during a time when I'm not around the computer. The last thing I care about watching is either my antivirus or antispyware programs running.

 

Hey, be nice now; don't show disrespect for your customers

Al http://i17.tinypic.com/2drylft.jpg Adric

 

Nick, do you have samples of Unreal rootkit? If so, how SAS detects it?
Thanks for the feedback.

 

Yes we have samples and we have definitions to catch it on boot - the key is starting before it does we have not seen many "actual" infections using the exact techniques as of yet, there may be a few, but not hugely widespread (at this point).

 

Thanks Nick

 

I am not showing any disrespect - I am taking/took the time to completely explain, in detail, the answer to your question regarding the CPU usage, both here and on our SAS forums.

If your desire is to protect your system, then the explanation regarding the CPU usage should have alleviated your concern (I would have hoped) - but you are now posting the CPU usage meter with your posts, both here and on our SAS forum - which to me makes this seem as if it's a little bit of a "joke" to you rather than the serious issue for which you expressed concern, and I am offering an explanation.

If you look around the forums, and if you sample our customer service, you will see that I, and our staff, always treat our users, both paid and unpaid, with the utmost of respect, politeness and courtesy.

 

I think it's great Nick that you mix with the forum discussions and make explainations for just about every conceivable question posed so a hearty ty for that as always. Now this plz.

Not asking for any detailed revelations to give away the house but in your opinion is it to any detection program's advantage, a relatively good choice to filter so many function calls with that technique compared to SAS's own "proprietary" methods to gain the access needed to watch for possible discrepencies which identify malware nestings? And since SAS is formidable in it's own right for removals of some of the worse infections we're then to assume (correctly?), that the SAS method gives it more freedom to deal with those type threats compared to others that might merely make intercepts but needs be haves to pass the dealing with removals to the user?
Interesting topic.
Thanks

 

Nick,

You're not going to believe this, but the CPU spikes that were occurring all this time while the system was in idle state have disappeared for now. It looks like the spikes stopped after finishing a scheduled SAS scan. Task manager shows between zero and a max of one percent CPU for SAS. Real time protection is still enabled, so where have the spikes gone? Something made them go away and I have no idea what.

http://i9.tinypic.com/4ie2639.jpg

http://i11.tinypic.com/2ekq4vb.jpg

The question now, is whether SAS realtime is still running correctly since it is not showing any spikes and according to your explanation, spikes are normal. I will keep an eye on this and report back.

Al

 

The advantage of filtering the function calls (SDT Hooking) is that you do see what is coming through and you can process/take action at that time - the disadvantage is you may not know who else is hooking and what they are doing "above" you in the chain. It's also the "common" method to filter the functions. The disadvantage is that if someone loads after you they can "unhook" you from the chain or process the call upstream and then terminate the chain (depending on the function hooked, etc.).

The methods we use can "bypass" many hooks so other applications, both user and kernel side "typically" (I say this, because there ALWAYS is a way to get around anything) don't see our calls and filter us. We have several "modes" we use depending on system circumstances/infections, etc.

There are also ways to parse the disk/folder/file structure without using the Windows file system at all - and right now, "most" infections don't attempt to block that type of access (yet). When they do, we'll have to deal with that - it's a cat and mouse game.

 

I had determined as much but was looking for insight especially from someone like yourself who excells in an AS product who can clearly (and you have LoL) draw those distinctions, and also you've summed that up quite as expected.

That's likely a feature M$ has inherently left open if i read it right, that is the table can be easily unhooked or some security HIPS driver that stations itself within it for detection purposes might become easily displaced at some point, and was mostly what i was interested in finding out.

I suppose a driver legit or not could scan itself to ensure it's properly seated there or not, and if not take some action to alert the user/machine or re-invite itself to be seated again?

It's something thats rarely discussed but very noteworthy because some more aggresive type malware might could be drawed up to do exactly that. Just covering all possibilities in my own mind which you likely already have covered that ground, right?

Very Good Program you have and i venture to say the Best to surface in a long time that is as formidable in what it's designed to accomplish. Thanks

 

OK, I did some more playing around with SAS and determined the following:

If I open the main menu, the spikes disappear. If I close the main menu, the spikes return. Sometimes they do not return after closing the main menu, but I have not found out under which specific situation this happens.

How does this relate to the previous explanation of the spikes?

Al

 

When the menu is open and the scanner will be scanning, the real-time does not need to enumerate processes, thus you may not see the same spikes. I am not sure how much more detail I can go into about the "spikes" - as I have covered that in its entirety.