THE ART OF COMPUTER VIRUS RESEARCH AND DEFENSE [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

THE ART OF COMPUTER VIRUS RESEARCH AND DEFENSE [Electronic resources] - نسخه متنی

Peter Szor

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید











  • 2.5. Computer Malware Naming Scheme


    Back in 1991, founding members of CARO (Computer Antivirus Researchers Organization) designed a computer virus naming scheme15 for use in antivirus (AV) products. Today, the CARO naming scheme is slightly outdated compared to daily practice, but it remains the only standard that most antivirus companies ever attempted to adopt. An up-to-date version of the document is in the works and is expected to be published by CARO soon at 16, which greatly expands on further naming considerations. Furthermore, credit must be given to all the respected antivirus researchers of CARO.[View full width]

    <malware_type>://<platform>/<family_name>.<group_name>.<infective_length>
    .<variant><devolution><modifiers>

    In practice, very little, if any, malware requires all name components. Practically anything other than the family name is an optional field:

    [View full width]

    [<malware_type>://][<platform>/]<family_name>[.<group_name>][.<infective_length>][
    .<variant>[<devolution>]][<modifiers>]

    The following sections give a short description of each naming component.

    2.5.1. <family_name>


    This is the key component of any malware name. The basic rule set for the family name follows:

    • Do not use company names, brand names, or the names of living people.

    • Do not use an existing family name unless the virus belongs to the same family.

    • Do not use obscene or offensive names.

    • Do not use another name if a name already exists for the family. Use a tool, such as VGrep, to check name cross-references for older malware.

    • Do not use numeric family names.

    • Avoid the malware writer's suggested or intended name.

    • Avoid naming malware after a file that traditionally or conventionally contains the malware.

    • Avoid family names such as Friday_13th, particularly if the dates represent payload triggers.

    • Avoid geographic names that are based on the discovery site.

    • If multiple acceptable names exist, select the original one, the one used by the majority of existing antivirus programs, or the most descriptive one.


    2.5.2. <malware_type>://


    This part of the name indicates whether a malware type is a virus, Trojan, dropper, intended, kit, or garbage type (Virus://, Trojan://, .. ,Garbage://). Several products have extended this set slightly, and these are expected to become part of the standard malware naming in the future.

    2.5.3. <platform>/


    The platform prefix indicates the minimum native environment for the malware type that is required for it to function correctly. An annotated list of officially recognized platform names is listed in the next section.17. This name indicates a file-infecting virus called Beast that can infect on Win32 platforms and also is able to infect Word 97 documents.

    2.5.4. .<group_name>


    The group name represents a major family of computer viruses that are similar to each other. The group name is rarely used nowadays. It was mostly used to group DOS viruses.

    2.5.5. <infective_length>


    The infective length is used to distinguish parasitic viruses within a family or group based on their typical infective length in bytes.

    2.5.6. <variant>


    The subvariant represents minor variants of the same virus family with the same infective length.

    2.5.7. [<devolution>]


    The devolution identifier is used most commonly with the subvariant name in the case of macro viruses. Some macro viruses have a common ability (mostly related to programming mistakes) to create a subset of their original macro set during their natural replication cycle. Thus, the subset of macros cannot regenerate the original, complete macro set but is still able to recursively replicate from the partial set.

    2.5.8. <modifiers>


    The original intent of the modifier was to identify the polymorphic engine of a computer virus. However, most antivirus developers never used this modifier in practice. Nowadays, modifiers include the following optional components:


    [[:<locale_specifier>][#<packer>][@'m'|'mm'][!<vendor-specific_comment>]]

    2.5.9. :<locale_specifier>


    This specifier is used mostly for macro viruses that depend on a particular language version of their environment, such as Word. For example, virus://WM/Concept.B:Fr is a virus that affects only the French version of Microsoft Word.

    2.5.10. #<packer>


    The packer modifier is rarely used in practice. It can indicate that a computer malware was packed with a particular "on-the-fly" extractor unpacker, such as UPX.

    2.5.11. @m or @mm


    These symbols indicate self-mailer or mass-mailer computer viruses. Suggested by Bontchev, this is probably the most widely recognized modifier. This modifier highlights computer viruses that are more likely to be encountered by the general public because of the way the viruses use e-mail to propagate themselves.

    2.5.12. !<vendor-specific_comment>


    The vendor-specific modifier is a recent addition to the set of modifiers. Vendors are allowed to postfix any malware name with such a modifier. For example, a vendor might want to indicate that a virus is multipartite by using !mp in the name.


    • / 191