Unpacker

Hey,

I have seen posts over at DSLR about unpackers and how KAV has such a really good one. And how NOD has come a long way but still has far to go.

Just curious what the unpacker is/does and what it looks for.

Thanks
Logan

 

Hi Logan5,

an unpacker is basically a component of the scanning engine, which lets the engine "see through" packed files. Executables can be packed and/or encrypted, but still run like normal. If an AV has no or bad unpacker support, it might just not detect packed malware, because it cannot unpack the outer layer of the packer itself. Some av scanners deal with this problem by generating signatures of the original malware, then of all packed variants, like TrojanA, TrojanA.UPX etc. Some have a more generic approach, which is where the unpacker comes into the game: These av try to unpack the packed file and then scan the malware hidden inside.
This is less relevant vor viruses, but a very hot topic for trojans and other malware. One can create countless modifications of a trojan by simply crypting/packing it with different packers.

Well, just a quick overview...if you need more tchnical background...let me know .

 

It is irrelavant for file infector viruses but not for the HLLx series such as HLLW, HLLP, HLLO for instance. Most of the Win32 Destructive Kamikaze "Viruses" are programmed in a highter level language (such as delphi, VB) and runtimepacked.

As you already said it is a main issue for trojans and backdoors.

Michael

 

XOR: yes, of course you are right, but I was just trying to outline afew general ideas...no intentions to open a discussion on virus families .

 

Hi all,
Over at the a² board, Andreas Haak has posted an explanation of several unpacking strategies and opened a discussion about which way a² should go. Except for the usual TDS-bashing I think it is a rather worthwile read.
Here's the url:
http://a-2.org/forum/viewtopic.php?t=8

I hope you don't mind me linking to it here.
CU,
Andreas

 

You can disassemble a unpacker Stub and add the (verified and virus free) code to the unpack engine.
Then you patch some things after loading the sample via CreateFileMapping and adding the own unpacker Stub. Then you run the own engine unpacker stub with the combined unpack data from the unknown sample and your own unpack stub.

You need a lot of knownledge there for the polymorph sections but nothing is impossible

 

XOR: Well, I am sure there a lots of ways to counter-attack malware...and we hope, that your gladiator project will find some of the best .

 

Thanks to all for your info and help.

Logan

 

Hi,

here is what our expert says (if you are interested - its a bit longer ):

As viruses and Trojan horses written in HLL usually exist as “standalone” applications (i.e. do not need a host to run), they are often processed by one of the many compression and encryption tools (CET for short) easily available on Internet. These utilities compress and/or encrypt the code and data of the target application, append their own decompression routine and set the entry-point to it. When the application is run this routine restores the application’s code and data “on-the-fly” and jumps to the original entry-point thus the application runs as before. The goal of doing so is to make application’s executable files smaller, to complicate the code analysis or even to prevent detection in case of malicious software. For example if a known virus variant (already detected by a particular AV scanner) is processed this way by a tool, which the AV scanner is unable to handle, it is bound to miss it.

Just like in the case of archives (ZIP, ARJ etc.) it is possible to write dedicated algorithms that remove such protections and restore the application to its more or less original state. However, there are several difficulties associated with this:

·   Unlike standard archives, decryption and decompression algorithms for CET are usually not available and need to be “reverse engineered”.
·   There are many different PE CET, often in several versions. Many of them support several methods of compression and/or encryption, which leads to even higher number of necessary decryption and decompression algorithms we need to implement to handle all variants.
·   New CET types and versions appear all the time.
·   We need precise identification for individual compression and encryption method so that correct reverse algorithm can be applied. In some cases this is problematic.
·   We need to make the reverse algorithms error-proof to ensure they do not crash when faced with intentionally or unintentionally corrupted data.

There is also other important point when we talk about heuristic detection for malware protected this way. If a virus author wants to avoid heuristic detection of his new creation by our AV system he will surely search and opt for CET, which our current engine does not handle. If he is more competent he can even modify the resulting file of a well-known CET in a way it is still functional but the compression/encryption method cannot be recognised.

Having this on our mind we decided for the following solution: we implemented specific algorithms for the most common CET like UPX or ASPack and designed a special generic algorithm called Generic Unpacker (GU) to handle the rest. Using heuristic rules GU decides if the analysed file is processed by a CET and if it is then the decompression routine attached by CET is emulated until the original entry-point is reached.

Although it is not trivial to recognise when the original entry-point has been reached (especially in case the file in question has been processed by more then one CET), there are several possible ways, which in combination bring good results. Other problem is that some CET use sophisticated “anti-debug” techniques. These are not specifically targeted at emulators but some cause problems. This can be solved by appropriate virtual environment enhancements.

The main disadvantage of GU against dedicated algorithms is its relative slowness. This is, however, well compensated by its robustness and universality if used properly.

Thx.,

jan

 

However, i stand on my point that the main issue is to detect what is what. Once you know this, you can unpack _ALL_ if you know how.

But you can not process _ALL_ files through a virtual emulator, this would slow down the scan speed to zero even if you test only executables. Because what are you doing then in Realtime Scan ? Emulating all on-access files ? Well you will die of oldness....

So you need a OP-Code Filter as well for detecting inserted "NOP"s operations and a JMP/JSR Filter to stripe out the "antidebuging" things for instance.

 

xor, please read the text more carefully - there are answers to most of your comments.

No one doubts it is a welcome feature to support as many CETs as possible... it is not sufficient, however. Recent Win32/Bugbear.B is a good example of that.

 

Ok just to boil it down.

Will Nod32 V2 engine protect against CET packed malware or in order to get a full protection against it we will have to run some different tools?

 

Hi testg,

>Will Nod32 V2 engine protect against CET packed malware or in order to get a full protection against it we will have to run some different tools?

Yes, NOD32 protects against CET packed malware.

Rgds.,

jan

 

I agree with what everyone said!