Article View: comp.virus
Article #4702Re: How to measure polymorphism?
From: Eugene V. Kaspersky
Date: Mon, 18 Jan 1993 18:46
Date: Mon, 18 Jan 1993 18:46
90 lines
3939 bytes
3939 bytes
Hi all, Vesselin Vladimirov Bontchev writes: > There are already two polymorphic engines available (MtE and TPE) and > we are going to see more and more polymorphic viruses in the future. > An interesting question arises - how to determine how polymorphic a > virus is? How to determine which of two viruses is "more polymorphic"? > In other words - how to measure polymorphism in an objective way? [skipped] > This article is not meant to provide a solution of the problem. I am > trying just to explain the problem and am asking for solutions. Any > ideas are welcome - we really need an objective way to measure the > level of polymorphism... I see three ways to detect polymorphic and encrypted viruses. The first way consist of analysis of decryption routine. If opcodes of this routine is satisfied to the specific conditions the object is detected as infected. On the second way the analyzer try to decrypt the virus body and detects the virus by *decrypted* mask. The third way is to use reduced masks for virus detection. The polymorphic level for the same virus on the difference ways can be difference also. For example, the Phoenix virus is polymorphic, but the decryption routine has the constant length and the body of the virus is XORed with a key, so it's easy to decrypt this virus and it's difficult to analyze the decryptor opcodes. You can use not only the virus mask, but the reduced mask also for this and other viruses. The file infected by Phoenix virus contains the encrypted code (s[0], s[1], s[2], s[3], ... , s[l]). The mask reduced by XOR instruction contains the bytes that are *constant* for all the infections: ( s[0] XOR s[1] , s[1] XOR s[2] , ... , s[l-1] XOR s[l] ). On this way Phoenix virus is *not* polymorphic, because it has the constant reduced mask. You can use several reduced masks : XOR word, ADD word, ADD byte, ROL, etc. > 2) The second idea is to divide the polymorphism is classes. Class 0 > means no polymorphism, class 1 means variable encryption with constant It's a good idea, but we can set the virus to several classes by several criterion also. It will be a vector of classes: ( class on condition_1, class on condition_2, ... ). I see several conditions: 1) number of possible encryption algorithms: 0 - if the virus not encrypted (Commander Bomber), 1 - for Cascade and Phoenix, 4 - for Girafe (XOR word, XOR byte, ADD word, ADD byte), ? - for MtE. 2) the diapason of length of decryption routine; 3) the number of different decryption routines; 4) the number of different opcodes used by decryption routine, it doesn't matter if the number of different decryption routines is small (Whale); 5) the diapason of number of control transferring except decryption loop opcode (for Girafe and Bomber). So, the polymorphic vector for Cascade is (1,0,1,1,-,0), for MtE is (?,512,?,*,0), * means that I don't know, but it's easy to analyze. The polymorphism of virus can be defined as the vector length: 1) + 2) + 3) +4) +5). That's all. Note: > criterium, the MtE-based viruses have polymorphism 1 - because all > decryptors contain only a single constant byte (the JNZ instruction), > which does not appear at a constant place. MtE generator can produce decryption routine *without* decryption loop, i.e. the body of virus *not* encrypted and JNZ instruction not present. Best regards, Eugene - -- - -- Eugene Kaspersky, KAMI Group, Moscow, Russia - -- eugene@kamis.msk.su, +7 (095) 499-1500
Technical Details
Message-ID:
<0003.9301281842.AA17847@barnabas.cert.org>Path:
arc1-ca.pugleaf.net!sparky!uunet!ukma!cs.widener.edu!dsinc!netnews.upenn.edu!netnews.cc.lehigh.edu!newsShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!ukma!cs.widener.edu!dsinc!netnews.upenn.edu!netnews.cc.lehigh.edu!news From: eugene@kamis.msk.su (Eugene V. Kaspersky) Newsgroups: comp.virus Subject: Re: How to measure polymorphism? Message-ID: <0003.9301281842.AA17847@barnabas.cert.org> Date: 18 Jan 93 18:46:29 GMT Sender: virus-l@lehigh.edu Lines: 90 Approved: news@netnews.cc.lehigh.edu