- •Введение
- •Тема 1. Двухпросмотровый ассемблер
- •Тема 2. Com-сервер для обработки и хранения результатов тестирования.
- •Тема 3. Дисковая утилита для просмотра fat.
- •Тема 4. Сервер автоматизации ole.
- •Тема 5. Дефрагментатор файловой системы.
- •Элемент каталога для короткого имени
- •Тема 6. Монитор системных ресурсов для Windows 98/2000.
- •Тема 7. Менеджер процессов и потоков для Windows 98/2000.
- •Тема 8. Файловый менеджер для Windows 98/2000/nt.
- •Тема 9. Формат исполняемого pe-файле в Windows 98/nt.
- •Тема 10. Запуск в определенное время различных программ.
- •Тема 11. Утилита, сохраняющая в файле информацию из системного реестра о программах, установленных на компьтере.
- •Тема 12. Утилита для очистки системного реестра Windows.
- •Тема 13. Утилита, отслеживающая изменения в файловой системе Windows в заданных каталогах.
- •Тема 14. Просмотрщик таблицы разделов и fat.
- •Тема 15. Утилита MaxSplitter
- •Тема 16. Утилита удаленного администрирования.
- •Тема 17. Простая почтовая программа на основе протокола smtp.
- •Тема 18. Ftp - клиент.
- •Тема 19. Ftp - сервер.
- •Тема 20. Системные сервисы Windows nt/2000.
- •Литература
- •Приложение 1. Tcp/ip Программирование с использованием WinSock
- •Создание и использование сокетов
- •Закрытие сокета
- •Функция shutdown()
- •Методы прекращения работы гнезда
- •Функция bind()
- •Приложение может послать запрос на соединение с помощью функции
- •Отправка и прием данных через сокеты потоков
- •Ожидание и обработка событий
- •Использование функции wsaAsyncSelect()
- •Приложение 2. Команды ftp
- •Приложение 3. Команды smtp
- •Приложение 4. Заголовки почты smtp
Тема 16. Утилита удаленного администрирования.
Техническое задание.
Разработать утилиту для управления удаленным компьютером.
Методические указания.
Сервер удаленного доступа.
Необходимо построить внутрисистемный интерфейс сервера удаленного доступа, то есть определить способ взаимодействия потоков сервера с программой, производящей выполнение пользовательских запросов. Например, пользовательские запросы могут поступать в командный интерпретатор COMMAND.COM. Для организации взаимодействия с командным интерпретатором можно использовать механизм неименованных каналов (для Windows 95/98) или именованных каналов (Named Pipes) для Windows NT/2000.
Канал имеет два файловых идентификатора - один для записи данных, другой - для чтения имеющейся в канале информации. Порядок продвижения байтов в канале - FIFO (первый поступивший байт первым оказывается на выходе). С помощью API функции CreateProcess можно запустить командный процессор, но при этом стандартные ввод и вывод перенаправить на каналы.
Функция CreatePipe создает канал, предоставляемый программисту в виде "двух концов" - идентификаторов:
BOOL CreatePipe(
PHANDLE hReadPipe, // address of variable for read handle
PHANDLE hWritePipe, // address of variable for write handle
LPSECURITY_ATTRIBUTES lpPipeAttributes,//security attributes
DWORD nSize // number of bytes reserved for pipe
);
hReadPipe и hWritePipe - указатели на идентификаторы. Идентификаторы получают значение при выполнении этой функции.
lpPipeAttributes - в Win95/98 можно указать просто NULL.
nSize- предположительный размер буфера. Система опирается на это значение для вычисления реального размера буфера. Этот параметр может быть равным нулю. В этом случае система выберет размер буфера "по умолчанию".
Если канал создан, функция возвратит ненулевое значение, в случае ошибки - вернет нуль.
Для операций с каналами используются функции ReadFile и WriteFile. Причем операция чтения завершается только после того, как будет что-нибудь прочитано из канала, а операция записи завершается после помещения данных в собственную очередь канала. Если очередь пуста, ReadFile не завершиться, пока в трубку не поместит данные другой процесс или поток с помощью функции WriteFile. Если очередь заполнена то WriteFile не завершиться до тех пор, пока другой процесс или нить не прочитает данные из каала с использованием ReadFile.
Рассмотрим фрагмент программы на Object Pascal, в котором используются каналы и функция CreateProcess для обмена данными с COMMAND.COM.
var
stinfo: TStartupInfo;
prinfo: TProcessInformation;
ReadPipe,WriteToCommand,ReadFromCommand,WritePipe: integer;
// обнуляем поля структур для CreateProcess
FillChar(stinfo,sizeof(TStartupInfo),0);
FillChar(prinfo,sizeof(TProcessInformation),0);
// пытаемся выполнить CreatePipe для первого и второго канала
if (not CreatePipe(ReadPipe,WriteToCommand,nil,PipeSize)) or
(not CreatePipe(ReadFromCommand,WritePipe,nil,PipeSize)) then
ErrorCode:=1
else
begin
stinfo.cb:= sizeof(stinfo);
stinfo.lpReserved:= nil;
stinfo.lpDesktop:= nil;
stinfo.lpTitle:= nil;
stinfo.dwFlags:=STARTF_USESTDHANDLES or STARTF_USESHOWWINDOW;
stinfo.cbReserved2:= 0;
stinfo.lpReserved2:= nil;
stinfo.hStdInput:= ReadPipe;
stinfo.hStdOutput:= WritePipe;
stinfo.hStdError:= WritePipe;
stinfo.wShowWindow:= SW_HIDE;
// запускаем COMMAND.COM
CreateProcess(CommandPath,nil,nil,nil,true,
CREATE_DEFAULT_ERROR_MODE or NORMAL_PRIORITY_CLASS,
nil,CurrentDirectory, stinfo,prinfo)
Для реализации обмена данными с каналами удобно создать два потока, один из которых занимается считыванием символов и их постановкой в очередь на обработку, а другой - передачей символов из очереди в канал.
Другой вариант - вместо отдельных очередей реализовать механизм Callback – процедур по аналогии с оконными процедурами в Windows. В таком случае потоки будут вызывать указанную им процедуру по мере надобности, т.е. если из досовской сессии поступает какая-либо информация, то вызывается процедура обработки входящих символов, а если есть возможность для передачи информации в сеанс MS-DOS - вызывается процедура передачи символов. Причем в последнем случае, возможно, не будет подлежащих передаче данных, тогда вызванная процедура должна сообщить об этом вызывающему потоку специальным зарезервированным кодом. Таким образом, существует два основных способа обмена информацией с каналами - асинхронный, когда используются Callback- процедуры и синхронный - с использованием очередей ввода-вывода.
Следует учесть некоторые детали, касающиеся разделения потоками общих ресурсов. Необходимо гарантировать, что при обращении к очереди из основного потока программы мы не прервем операции с тои же очередью, производимые другими потоками, работающими с каналами. Для синхронизации доступа можно использовать механизм критических секций или мьютексов.
Обеспечение обслуживания клиентов - неотъемлемая функция любого сервера удаленного доступа. Обслуживание клиента состоит из четырех основных стадий:
Аутентификация при подключении клиента;
Подготовка рабочей среды, т.е. выделение ресурсов на обслуживание;
Собственно процесс обслуживания, состоящий в выполнении клиентских запросов и отсылке сообщений о результатах;
Отключение клиента и освобождение выделенных ресурсов;
Для осуществления многоканального обслуживания удобно использовать механизм сокетов.
В данном случае аутентификация заключается в запросе пароля у пользователя и проверке правильности введенного слова. Процесс аутентификации можно реализовать в виде отдельного потока, внутри которого происходит циклический опрос сокета пользователя на предмет наличия введенных символов. Время опроса и длина вводимой цепочки символов ограничена соответственно 30 секундами и 32 символами. Символы с кодом менее 32 (пробел) считаются признаком конца строки. После того, как пароль будет введен, выполняется проверка введенного слова на наличие в списке допустимых паролей. Если список не содержит такого слова, то пользователю отправляется сообщение о неудачной попытке и связь разрывается, после чего завершается и сам поток. В случае правильного ввода пароля происходит инициализация другого потока, производящего запуск ДОСовской сессии или подключение к уже запущенной сессии.
Для выделения ресурсов используется поток, внутри которого происходит запуск командного интерпретатора. Сразу же после запуска инициализируются потоки ввода-вывода данных, а управляющий поток переходит в режим ожидания завершения работы командного интерпретатора. Каждая сессия имеет специальную структуру-описатель, в которой хранится состояние соединения, ссылка на сокет клиента и ссылка на поток, запустивший командный интерпретатор. Указатель на эту структуру храниться в списке пользователей и паролей, который, в свою очередь, заполняется информацией при инициализации программы-сервера на основании файла PASSWORDS.LST. Сама структура формируется непосредственно перед активизацией сессии.
Обслуживание клиентов происходит следующим образом: обработчик события, возникающего при поступлении информации от клиента, направляет поступающие данные (символы, строки) на входную очередь потока который переносит данные через канал (pipe) в командный интерпретатор или в запущенную из него программу на стандартное устройство ввода (STDIN). Для того чтобы поступающие данные попадали в требуемый сеанс MS-DOS, сокет-источник данных сравнивается с сокетом в структуре-описателе сесии Когда командный интерпретатор или запущенная из него программа пытается осуществить вывод символов на стандартное устройство вывода (STDOUT) происходит передача символов через канал в поток, контролирующий выходящий из сеанса MS-DOS поток. Этот поток вызывает Callback функцию, которая на основании данных из структуры-описателя осуществляет передачу информации через требуемый сокет.
Отключение клиента осуществляется либо по инициативе клиента, либо по инициативе администратора, либо в результате сбоя в канале обмена данными. Если клиент завершил свою сессию командой EXIT, то ожидающий завершения командного интерпретатора поток сам инициализирует процесс завершения соединения. Во всех этих случаях механизм реализации отсоединения одинаков. Просто производится завершение соединения на требуемом сокете и изменение содержимого полей соответствующей структуры-описателя. Если же происходит завершение работы командного интерпретатора, то структура-описатель уничтожается, что свидетельствует о необходимости повторного создания сеанса MS-DOS при присоединении клиента. Если клиент отсоединился, не завершив работу своего командного интерпретатора, то вся обработка, инициированная отключившимся клиентом на сервере, продолжается без участия клиента. В таком случае, при повторной установке соединения, клиенту будет предоставлена та же сессия, которую он покинул, но, возможно, с продолжающимся или завершенным процессом выполнения ранее данного задания.
Сервер и клиент могут также использовать для работы протокол UDP. Можно поддерживать следующие возможности: перехват мышки, перехват клавиатуры, удалённое управление файлами, изменение разрешения дисплея. Также можно настроить передачу картинки и мышки с удалённого компьютера.
