(趋势）2006题目

Trend Micro Programming Contest

2006

Preliminary Stage

(Version 1.1)

 

1.      Subject
Malicious Software Sample Collection System

 

2.      Overview

Nowadays, different types of malicious codes are emerging quickly around the world. These codes may damage the user’s computer or even worse, steal confidential data.  To help combat these malicious codes within the Internet, we first need get their samples in a timely manner. Once these samples are collected, we then can decide which appropriate countermeasure is needed in order to block the threat.

Since we need to gather up these malicious codes before they seep into the Intranet from the Internet, the best solution is to record the incoming packets in the gateway and assemble these packets into binaries. Once we have the binary, we can then send it to the sample collection server, where it will undergo further analysis. (Program should not use port number to assume the protocols go through it)

 

Internet

Switch

Gateway

Server/Desktop

Packet assembling application can be installed here in either sniff or inline mode

 

 

3.      Client: Packet Assembling

Since packets within the network can be found under various protocols, understanding these protocols and extracting the binary data poses a challenge. Therefore, the more protocols you support, the better your chances will be in scoring higher, in the Solutions Completeness category.

 *Legally using free libraries or source codes is allowed, but you must declare it explicitly in your design document.

 

4.      Server: Report

Based on the historical data received from our clients, the server should be able to show some sort of report to the administrator, such as protocol distribution, file type distribution and sample distribution by IP, etc. The following graphs below provide some examples of the report.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Samples Distribution by Host IP

 

Other useful pictures include “Hotspot graph” and “Attack graph”. The difference between these two graphs are; “Hotspot graph” shows hosts which contain widespread samples, while the “Attack graph” shows each widespread sample’s spreading route.

Hotspot Graph Example

 

Attack Diagram Example

 

.

5.      Testing Environments

Your submitted program will be tested in an environment using the following hardware, software and test data.

 

Hardware     

Pentium-IV class machines with 512MB RAM.  We may test on at least two machines.

Software

Windows® XP Professional SP2+ MSDE® + Sun JRE® 1_5_0_06 + .NET® 2.0

Or

Red Hat® 9.0 + MySQL® + Sun JRE® 1_5_0_06

 

Please choose the supported environment from above in your manual.

All OS and software will be installed with default settings and default components.

Please be advised that you can’t request us to install any other commercial software.  However, you are permitted to use other free software, but you must bundle it in your package and provide a detail document of its installation process.

 

For programmers using Microsoft® JVM, please note that, Microsoft® has declared that they’ll no longer support MSJVM after December 31, 2007 and that JVM® will not be included with Windows XP SP2, therefore our testing computers will only have the Sun JRE 1_5_0_06 version installed.

 

Network

Our testing will be conducted in a closed, pure LAN environment, in which each machine has an internal IP.  No firewalls or routers will be present in this environment. All operating systems are installed with default protocols.

 

 

6.      Requirement of Your Software Package

We will provide a FTP server for uploading your files. Every team has a home directory on the FTP server. Please carefully follow the rules below for it is critical to name and organize your directories and files.

 

a.       Directory structures

In the FTP server you must create three directories named “document”, “program” and “source” under your root directory, and classify all your files into them. You may create more sub-directories in any name under these three directories. But don’t create other directories under the root directory.

 

b.      Documents

Please put your document files in the directory named “document” and add proper extension filenames like .doc or .html according to the document format you choose. You must provide the following four documents with the given filenames, shown below highlighted in bold.  

Manual              

Is a document that is written in plain text, HTML, Word or PDF.
The first section must introduce the installation procedures clearly and correctly. You must write the software requirement and step-by-step installation procedures. You will no longer qualify in the contest if our testers can’t set up your programs and get them running. So please double check that all installation procedures are correct.

The latter sections must include the usage of your programs.  Again, we remind you to write a clean, concise document.

Design               

Is a document that is written in plain text, HTML, Word or PDF.
It describes the architecture of your design. If you borrow any public libraries or source codes, write all of them down explicitly. If we find that you’ve missed some pertinent piece of information, you will be disqualified from the competition.

Build

Is a document that is written in plain text, HTML, Word or PDF.
This document describes the detailed procedures of how to build executable programs from your source codes. In the building process, Windows® programmers may use Microsoft Visual Studio 6® “workspace” files, while Linux® programmers may provide “Makefile”. However, we encourage you to include necessary information in this document because it helps facilitate our testers to build your programs.

Filelist

   Is a document that is written only in plain text.

This document comprises of a complete listing of all files you have sent to our FTP server. You must list in full the pathname, file size, and last modified time in this list. We use this file to check if you uploaded all the files during this contest.

 

c.       Programs

Put all your binary programs and installer (if you have) in the directory named “program”. Our testers should be able to begin the installation from this directory.

 

d.      Source codes

Put all your source codes into the directory named “source”. Don’ forget to write procedures of how to build your codes into programs in the document named “build”.

 

e.       Installation

Your installer or installation procedures should put executable programs into the         following directory if there is no special assignment:
       For Windows®:
              C:/CCAMS
       For Unix®:
               /home/<current user>/CCAMS
After installation is completed, the executable programs should be put in the installation directory. Don’t forget to teach users how to use them in the document named “manual”.

 

f.        Test kit

You have to include all the information about how well your program will be working. This might include test programs, sample test data and test manuals with typical test scenarios your program has supported. If you need any additional configuring on OS to setup the test environment, please provide detail descriptions in your test manuals (for example, set HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/ Services/Tcpip/Parameters/IPEnableRouter to 1 to enable IPv4 routing on Windows® XP). With this kit, the user can follow the test, and he can know how well it is working.

 

7.      Other Requirements

a.       No restriction about programming languages.

b.      No explicit UI requirement about the client. You could design it in a hidden style or provide some controls. But your programs should not interact with the user at the client side too frequently.

c.       Naturally, the server UI could be a normal application. But we don’t stop you from using web UI or other ways if you can implement it ideally.

 

8.      Scoring: Your score will be comprised according to the following breakdown.

a.       Protocol support: (50) points

How many protocols have been supported?

Any good test kits are provided to prove how well they are working?

How much information can be collected in server side? (False alarm)

How to extend the protocol?

Are the samples associated with their information correctly collected in server side?

b.      Reporting: (50) points

Is History List and Reports precise and easy to understand? Does it provide valuable summary?

Is Hot Spot Graph precise and easy to understand?

Is Attack Diagram precise and easy to understand?

c.       Performance (40) points

Is the information collected quickly and precisely on the server?
How much resource do the client and server use?

d.      UI (20) points

Is the UI friendly and nice?
Is the whole system easy to use and stable enough?

e.       Installation (10) points
Is the installation process easy and smooth?

f.        Document (30) points

Is the description clear?
Is the design well described?

Does the manual cover all things users need to know?

 

9.      How We Test

Stage 1: We will conduct the test with the provided information in your test kits to validate the supported protocols and functions.

Stage 2: We will generate traffic by testing tools, and see if History List/Reports on the server UI show expected results with the samples correctly collected.