About AV-CheckerHello! 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 - staticsA 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 packsIn 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 DomainsDNSBL (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):
Checking files - dynamicsThis 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 =)):
0xYou 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:
|