Spybot 2.0: Scripting

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, jump instructions and variables) to boost the performance.

While speaking about the evergrowing challenges, our team has come up with another idea - we reached the point where we decided that it would be a waste of time to add more and more features of a programming language, but, due to the database restriction, with assembly-like comfort only. So we went ahead and tried to opt for a high level language right away, adding all the comfort a codewriter is used too at once. Making it easier to avoid false positives by having much more control over heuristics in various situations.

On a very basic level, this is not unlike OpenSBI. Imagine the following OpenSBI command:

File:"<$FILE_EXE>","<$WINDIR>\malwar*.exe","filesize=4711"

You can do the same in SpybotScript in a very similar way:

sbiFile('<$FILE_EXE>', '<$WINDIR>\malwar*.exe', 'filesize=4711');

Do you recognize the language? Its Pascal (nowadays knows as Delphi mostly). And next to the simple conversion, it offers all the standard contructs of Delphi (like if...then, repeat...until, while...do, case...of and more), plus many useful functions for dealing with files and the registry directly (where the commands above would simply add items to the scan results):

var sFilename: string;
begin
   if sbiWindowsIsNTBased then begin
      sFilename := GetSystemServiceFilename('MalwareService');
      StopSystemService('MalwareService');
      sbiFile('<$FILE_EXE>', sFilename, '');
   end;
end.

This one might be a bit simple, since the cleaner might already be able to kill a system service, but it gives a first glimpse at the possibilities.


So where will we see this in action exactly? Well, in the first place, scripts will be enhancements to the main scanner, since the purpose is to aid in detecting thing. In the long run, as standalone fixes for threats maybe? The options available now are nearly endless.

 

[Korrel]

The only downside to this "new" method is that scanning your system will take longer than writing a novel about system security.

 

[PepiMK]

Wrong

Well, that depends on how it is used of course, but keep in mind that this is an optional feature for difficult or user-written cases - not many detection patterns really need the complexity, but those that do already use a logic interpreter.

And even currently with 1.6, OpenSBI already allows to create a very simple structure that gets interpreted, and in acceptable time. Scripting does even impove that situation by avoiding the need to parse the text each time.

Of course this needs a very high level of optimization and integration into the main engine (see this), but that already exists for OpenSBI and gets improved all the time. Granted, the worst case estimate is still bad (theory on the paper though, a good database will avoid that), but the average case estimates (and test experiences) are quite nice.