Maximize
Bookmark

VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

About AV-Checker

pr0mix
Inception #1 (EN)
2013

[Back to index] [Comments]

Hello!

The topic of AV-checkers has been raised on numerous occasions: there are concepts, raw and ready realizations, thoughts and other bullshit. That's why I decided to dump here everything related to the checker's working scheme. I did however add something new and left the unnecessary parts out.

An Av-checker is an online-service, checking files/data for viruses/trojans/worms/etc with the help of (prepared in advance) different Anti-Virus (AV) scanners. For starters, we will need a powerful multi-core dedicated server (the more cores, frequency, cache - the better), with a big RAM and supporting hardware virtualization for hypervisor). In addition, we will need wide network channels and unlimited traffic (specific technical characteristics are not provided because it all depends on what you want and can get). A "simple" PC with installed Virtual Machine (VM) could do, but it would directly influence the working speed of AV-checker. After all, the good performance depends directly on the equipment's capacity and its configuration.

As for the programming languages, you can write in any of them and in the way you prefer. For example, C++ (for the system's engine) and php + html (for web-design).

Later, you can add the following (popular) features aka verifications for your online-scanner:

Let's take a closer look at each one of those points.

Checking files - statics

A checker is a web admin panel + system engine "communicating" using a database (DB) and located on a badass hardware, so to speak.

Implementation technology:

Points [2], [3] and [5] take most of the work, because every AV requires its own algorithm. That's why we can factor out all these point into a single module (handler_n), with a uni-interface (task-manager), while realization will be different for every type of AV.

Here is how the checker works schematically:

                                 ******************************<-***********************************
                                 *                                                                 *
                                 *                           SERVER                                *
                                 *                                                                 *
                                 *                                                                 *
                                 *                                                                 *
                                 *      ************                                               *
                                 *      *          *                                               *
          *         5. profit    *      *          *             4. result                         *
         * *<---------------------------* web-site *<----------------------------------+           *
        *   *                    *      *          *                                   |           *
       *     *      1. file      *      *          *                                   |           *
      *  user *------------------------>*          *                                   |           *
     *         *                 *      ************                                   |           *
    *************                *        |                                            |           *
                                 *        |  2. file\task                              |           *
                                 *        +---------------->********                **********     *
                                 *                          *      *  3. file\task  *        *     *
                                 *                          *  DB  *--------------->* engine *     *
                                 *                          *      *                *        *     *
                                 *                          ********                **********     *
                                 *                                                                 *
                                 *                                                                 *
                                 *                                                                 *
                                 ******************************->***********************************





                                 ******************************<-***********************************
                                 *                                                                 *
                                 *                           ENGINE                                *
                                 *                                                                 *
                                 *                                                                 *
                                 *                                                                 *
                                 *                           *************              ********   *
                                 *                           *           *   <-report   *      *   *
                                 *                   +------>* handler_1 *<------------>* AV_1 *   *
                                 *                   |       *           *     file->   *      *   *
                                 *   ***********     |       *************              ********   *
                                 *   *         *     |                                             *
             3.2 result          *   *         *     |                                             *
    <--------------------------------*         *     |       *************              ********   *
                                 *   *  task   *  <-report   *           *   <-report   *      *   *
             3.1 file/task       *   * manager *<----------->* handler_2 *<------------>* AV_2 *   *
    -------------------------------->*         *    file->   *           *     file->   *      *   *
                                 *   *         *     |       *************              ********   *
                                 *   *         *     |                                             *
                                 *   *         *     |                                             *
                                 *   ***********     |       *************              ********   *
                                 *                   |       *           *   <-report   *      *   *
                                 *                   +------>* handler_n *<------------>* AV_n *   *
                                 *                           *           *     file->   *      *   *
                                 *                           *************              ********   *
                                 *                                                                 *
                                 *                                                                 *
                                 *                                                                 *
                                 ******************************->***********************************

It would be even better if we could add:

Checking packs

In a nutshell, a pack is an exploit pack returned by a rotator (+ there is an admin panel with statistics and lots of other stuff). A rotator is a script that determines a variety of the machine's characteristics (OS, browser and its version, etc.) and returns a suitable script. A pack (bond) is used for testing software for penetrability, likelihood of vulnerable machines being infected with subsequent expansion of its own software etc.

For AV-checker's engine, checking bonds equals to checking files, the differences will be visible only in the admin panel. This is how it works:

You can also think in advance about the kinds of protocols the bond checking will work with, as well as what can be done if an IP block after every entrance is enabled for the pack (however, that's not the checker's problem anymore). That's all there is to it.

Checking Domains

DNSBL (DNS BlockList/BlackList - previously RBL - RealTime Blackhole List) is a blacklist of IP/domains that send spam and are stored using the system with a DNS architecture. There are also tons of different DNSBL-servers offering their services (lists) to deal with useless information. It means that everything is already built, all we need to do is add the required services to our checker and automate the checks (yeah, right, just fucking add them, it's that simple =)). The truth is, the task itself is kinda easy, and in my opinion, it's even easier to realize it using scripts on just one VM.

System frame is going to be almost the same as that of the file checker (with task manager, handlers and etc), but with changes, namely (in order of the previously mentioned points):

  1. instead of the file, the IP/domain is checked (it's crystal clear anyway);
  2. ip/domain checking is executed DNSBL-services selected in admin panel. Besides, we have 3 types of checks:
    1. checking web databases through parsing of the downloaded result page. For example, for google, it's done in the following way:
      • create full web-address (google safebrowsing);
      • download content by that url;
      • on the page received look for specific text (if we find a "NO", the domain is clear);
    2. downloading (in simplest cases - a text version) a database of 'dirty' ips/domains with subsequent search for required IP (spyeyetracker blocklist etc);
    3. resolving IP -> writing IP in DNS PTR notation -> including the DNSBL server name into the tail -> receiving (not receiving) the answer. I should also add that there are 2 types of DNSBL: LHSBL (Left Hand Side Blacklist) and RHSBL (Right Hand Side BlackList). The main difference is that LHSBL is used for checking IPs and RHSBL for checking domains.

      Example for LHSBL:

      We have an address: eof-project.net. We get its IP, let's say it's 12.34.56.78. Then, we write the digits it reversed order: 78.56.34.12. Then we add the name of any list host: 78.56.34.12.cbl.abuseat.org. In C, the checking can be done using the gethostbyname(char *name)) function. If you receive an answer (for this host, it's IP 127.0.0.2), then the address being checked is locked (is on the list).

      You can receive any IP address, what matters is the fact of its presence or absence in the query answer.

      The example for RHSBL is similar, but there will be a domain instead of an IP (eof-project.host_name);

    4. checks of other types realized in compliance with the task assigned (for example, for Internet Explorer, we can create an additional VM in which we can emulate a user entering the website etc).

Checking files - dynamics

This category includes:

Just like in other cases, there are several ways to create this kind of check (the points listed above can be used separately, combined into one big point or mixed, whatever rocks your socks =)):

0x

You get the picture now. In general, everything is pretty straightforward. It's just too much donkey work, both obvious and no so much, some of which will come up in the process. But it's nothing to beat your brains about. The most important thing is to find a powerful server :P. If you do need it - go for it and you will make it work no doubt.

See also:

m1x
http://lj.rossia.org/users/pr0mix/
2013
Inception E-Zine
[Back to index] [Comments]
By accessing, viewing, downloading or otherwise using this content you agree to be bound by the Terms of Use! vxer.org aka vx.netlux.org
deenesitfrplruua