Киевской фирме требуюся системные программисты, имеющие опыт и высокие профессиональные знания в разработке проектов на уровне операционого ядра Windows9X,ME,NT3.51,NT4.0,2000,XP,2003 для выполнения проекта(см.Specifications) и анологичных проектов.

Валерий
[email protected]
======================================================
Requirements/Specifications for NT and 9x.

This project plan is based on the following requirements and specifications:

1. Process Control

-Notification of process creation, and the ability to prevent the process from starting up. Information included with this notification would include:

a. The filename of the image from which the process is created
b. MD5 checksum of the image, plus an indication of whether the checksum has changed since the last time the image was executed (this implies that SX keeps a protected checksum database, which is populated on access, or using a separate 'scan all files in this folder' function)
c. Module name (from the PE header)
d. Description string (from the image version resource)
e. Items a-d for the parent process (i.e. the process making the CreateProcess* or WinExec* call)

Note that b, c and d could be included independently of the SX driver; however since pretty much every SX client will require it, it would be good to implement this on as low a level as possible. -Notification of process termination; ability to mark certain processes as 2. Registry Access Control

Notification of access to registry keys and values, and the ability to prevent the access from succeeding. The SX client should be able to specify a filter of which keys it is interested in or not interested in. Information included with each notification would include:

a. The key name (ANSI or Unicode string)
b. The value name (if applicable; ANSI or Unicode string)
c. The type of operation (e.g. open, read, write)
d. The value data (if applicable)
e. The filename of the image from which the process making the call was created

Note that the SX driver is required to keep per-process state on which keys are open, as it will need to provide the full key name to the SX client on each access (because of process boundaries, simply reporting the handle argument as given to the Reg* API call is not useful)

3. File/Device Access Control

Notification of access to files, and the ability to prevent the access from succeeding. The SX clients should be able to specify, on a per-directory basis, whether it wants to see all accesses or only major events (open file, first read, first write). Information included with each notification should include:
a. The file name
b. The type of operation (e.g. open, read, write)
c. Any additional data (if applicable, for example, offset/data information)
d. The filename of the image from which the process making the call was created

4. Windows Hook Control (Code Injection Prevention etc.)

Notification of use of the SetWindowsHook* API call (which, amongst other things, can be used to inject code across process boundaries) and the ability to prevent the API call from succeeding. Information included with each notification would include:

a. The parameters of the API call (hook type, pointer to hook procedure, module handle and thread ID)
b. If the module handle in non-NULL, the following information on the DLL to which the handle refers:
i. The filename of the image from which the process is created
ii. MD5 checksum of the image, plus an indication of whether the checksum has changed since the last time the image was referenced
iii. Module name
iv. Description string
c. Items i-iv above for the process making the API call


Tasks

The following tasks are addressed under this plan.
Development effort required to deliver hooking code code in the form of a kernel mode driver to address requirements 1 through 4 as stated in the requirements section.