The complexity of malware is causing new challenges for anti malware software every day. Randomized malware that has thousands of new variants out calls for loose heuristics, detection patterns need to be slightly adjusted all the time, and new technologies call for new methods of reaction.

The standard approach to store malware detection patterns has been databases for decades. We've been using databases ourselves for the past ten years, with just slight adjustments (like subfunctions,...

With the rising of rootkits and professional malware, cleaning those away got more and more important and should earn a more prominent position next to scanning.

The cleaning concept in Spybot-S&D 1.x is already doing a lot, like for example trying more than a dozen methods to get rid of files. It's a bit one-dimensional though, and one of its worst disadvantages is the need to do sometimes do a complete rescan on boot to cleanup some files. Cleaning in Spybot 2.0 will therefore...

I've read it mentioned as a request for 2.0, and it's been a controversial thing for a long time, so I thought this earns its own 2.0 blog entry.

The standard AV (antivirus) approach at scanning is filesystem based, iterating through all or selected file partitions or folders. Extend that to AS (antispyware), and you'll add a full registry iteration as well. Each file/registry entry will be compared to a set of detection rules.

Our "current" (1.x) approach is...

Updating is an area where we feel quite torn, because it just cannot be solved perfectly. On the one hand, privacy paranoia should require all Internet connections to be established on explicit user request and choice. Background downloads are often among malware criteria, and as such, we wanted to avoid them for a long time.

On the other hand, there's user comfort. The average user does not want to be disturbed by having to actively care about his security software too much, and we...

The next and probably last blog post about the user interface before getting to technical issues again is about the main windows, after we've already spend some time on information, confirmation and error dialogs.

Our starting point here was to look out for visual arrangements that would reflect systems standards, but are individual at the same time. Creating a GUI (graphical user interface) that follows standards is a basic requirement by anyone who believes in ergonomics. Using standard...