runtime compression programs compress an executable file and prepend or *append a stub to the file containing the code to decompress it at runtime...
malware authors (or even just people deploying malware) use this functionality as a cheap and easy way to turn a known piece of malware into something 'new' that no one has ever seen before and that known-malware scanners can't detect... this is one of the many possible ways to implement the transformation function of server-side polymorphism...
although the malware is transformed in a manner similar to how conventional polymorphic viruses transformed themselves, the generic solution that worked so well for polymorphism doesn't necessarily work as well for packed malware because the size of todays malware combined with the potential to chain multiple packing transformations together make the amount of work necessary to emulate the full unpacking operation much more expensive and time consuming in comparison... that said, dynamic translation promises speed improvements over conventional emulation so that generic unpacking may still be workable...
*a less general approach, but one with a little more heuristic value is to identify those packers used primarily/exclusively for obfuscating malware and alert on any file packed by such a packer...
*the most straightforward approach, is of course to have a library of unpacking algorithms for known packers and use those to unpack the malware - however this packer-specific approach has many of the same (or at least analogous) limitations that known-malware scanning itself has as even minor variations in the packing/unpacking algorithm (which can easily be made for malicious purposes) can potentially result in a failure to detect which packer was used and/or unpack the malware properly...
[* corrections/clarifications prompted by vesselin bontchev]
back to index
2 comments:
The unpacking stub is not always prepended - in fact, most of the time it is appended.
Another approach the scanners use to deal with packed malware is to recognize the packer and then apply an unpacking algorithm hard-coded in the scanner, instead of emulating the unpacking stub. This is much faster than emulation and much more precise than labeling something as malicious just because it is packed with a particular packer.
y'know, i kinda thought the packer-specific approach went without saying, but now that you mention it it is an odd omission to make...
Post a Comment