наличие объекта на зависящем от мощности излучателя расстоянии. Ведущий микроконтроллер по окончании сканирования всех участков сцен (выполненных всеми микроконтроллерами) осуществляет композицию образцов, формируя тем самым общее изображение объекта.
В памяти ведущего МК находится подсистема распознавания объектов. Результат распознавания либо сообщение о несовпадении передаётся в систему верхнего уровня иерархии (инструментальную ЭВМ). Для отображения результатов работы микроконтроллерной системы используется программа авторской разработки 1гУшоп.
В обеих подсистемах САПР в качестве управляющего микроконтроллера применяется микроконтроллер МК С515 фирмы Infineon, обладающий архитектурой семейства MCS 51 и снабжённый обширным набором периферийных устройств.
По мнению авторов, описанный комплекс может быть применён как для исследования интеллектуальных алгоритмов обработки сложных категорий изображений, так и в учебном процессе при подготовке специалистов в области встраиваемых интеллектуальных систем управления.
СПИСОК ЛИТЕРАТУРЫ
1. Proceedings Embedded World 2004 Conference / Published by C. Grote, R. Ester. Germany: Design&Electro-nic, 2004. 825 p.
2. Рассел С., Норвиг П. Искусственный интеллект: Совремнный подход / 2-е изд. Пер. с англ. М.: Изд. дом «Вильямс», 2006. 1408 с.
3. Джонс М.Т. Программирование искусственного интеллекта в приложениях / Пер. с англ. А.И. Осипова. М.: ДМК Пресс, 2006. 312 с.
4. Борисов А.Н., Алексеев А.В., Меркурьева Г.В.
и др. Обработка нечёткой информации в системах принятия решений. М.: Радио и связь, 1989. 304 с.
5. Форсайт Дэвид А., Понс Ж. Компьютерное зрение. Современный подход / Пер. с англ. М.: Изд. дом «Вильямс», 2004. 928 с.
6. Васильев А.Е. Микроконтроллеры. Разработка встраиваемых приложений. СПб.: БХВ-Петербург, 2008. 304 с.
УДК 004.451.2
А.С. Шульмин
ФОРМАЛИЗОВАННОЕ ОПИСАНИЕ ПРОЦЕССА В ОПЕРАЦИОННОЙ СИСТЕМЕ И ЕГО ПРИМЕНЕНИЕ ПРИ ОБНАРУЖЕНИИ СКРЫТЫХ ПРОЦЕССОВ
В настоящее время является актуальной разработка формализованного описания процесса в операционной системе (ОС): его структуры и алгоритмической модели, исследование сцеплен-ности процессов в ОС и разработка способа обнаружения скрытых процессов в ОС.
В статье описан процесс в ОС с позиций общей теории процессов, выделены параметры, на которых развиваются процессы, атрибуты, используемые при генерации нового состояния процесса. Исследован процесс вызова системного сервиса режима ядра из процесса режима ядра, выделены параметры, по которым происходит сцепление процесса, вызвавшего сервис, с процессом ядра
ОС, показано, что сцепление произошло по параметру, хранящему стек адресов возврата, и предложен способ обнаружения скрытых процессов в ОС, основанный на анализе этого параметра при каждом вызове системного сервиса.
Используется понятийная база общей теории процессов (ОТП), предложенная в работе [5]. Для удобства читателя основные понятия ОТП, сведены в таблицу.
Рассмотрим один из основных компонентов ОС -процесс. Как указано в [9], в общем случае процесс в системе состоит из следующих компонентов:
исполняемый образ машинного кода данной программы;
Основные понятия общей теории процессов
Понятие Обозначение Описание
Параметрическое множество системы е=ад=1 Параметрическое множество системы - вся совокупность параметров системы, определяющих процесс функционирования или участвующих в нём; - некоторый параметр системы
Множество значений параметра Множество значений, которые может принимать параметр <7
Пространство состояний системы Декартово произведение множеств значений всех параметров системы
Состояние системы Любой элемент пространства , описывающий определённое состояние системы
Процесс Последовательность изменения состояний системы во времени. 5 - пространство состояний системы, в которой развивается процесс; Т— множество моментов времени изменения состояния системы; .Р - однозначное (функциональное) отображение Р —> 5
Интервал определения процесса ' ¿К ] Интервал, на котором определён процесс гн - 1шп{г}; - тах{т}
Объект системы осе Составная часть системы; определяется параметрическим множеством объекта, которое является подмножеством параметрического множества системы
Пространство состояний объекта 9/еО Декартово произведение множеств значений всех параметров объекта
Состояние объекта Любой элемент пространства , описывающий определённое состояние объекта
Процесс в объекте г0 = прге «о Определение процесса в объекте О по заданному процессу в системе
Элементарный оператор Ы Оператор, вычисляющий состояние системы я Е 5(2 только в одной точке i
Инициатор I Объект, перемещающийся от одного элементарного оператора к другому и вызывающий выполнение элементарного оператора при сцеплении с ним
Понятие Обозначение Описание
Оператор генерации состояния объекта s°=H0[A°,ti, со) Оператор, позволяющий рассчитать состояние объекта 5 € в некоторый момент времени Ц А0 - множество аргументов АР С (); Е [¿у; ^ ] - момент времени, принадлежащий интервалу, на котором уО определен процесс Z ; СО - некоторое случайное число (позволяет задавать случайные операторы)
Трек процесса 3 II зГ* Линейная последовательность элементарных операторов
Сцепленность объектов (процессов) Если в системе развиваются два процесса в объектах 0[ и От, для которых заданы операторы генерации состояния объекта, причём 0\ П А°т Ф 0, то говорим, что Ч объект 0[ сцеплен с объектом От. То же касается и их процессов
память (обычно - некоторые области виртуальной памяти), в которой содержатся исполняемый код, данные, специфичные для процесса (ввод и вывод), стек вызовов (для сохранения стека активных подпрограмм и/или других событий) и «куча» (содержащая объекты, созданные в процессе выполнения программы);
дескрипторы ресурсов ОС, связанные с процессом (файловые дескрипторы, источники данных и т. п.);
параметры системы безопасности (информация о владельце процесса, о множестве допустимых операций для процесса);
состояние процесса (контекст), содержащее информацию о значениях регистров, адресации физической памяти и т. п.
Таким образом, в общем случае процесс в ОС можно определить как шестерку:
P = {IMG, MEM, DESCR, LSA, CNTX, ALG), (1)
где IMG - исполняемый образ, из которого процесс был создан; MEM - память, принадлежащая процессу; DESCR - дескрипторы
ресурсов ОС, связанные с процессом; 1БА -параметры системы безопасности ОС для данного процесса; СИТХ - контекст процесса; ALG - алгоритмическая модель процесса.
Необходимо разделять понятия «процесс ОС» и «процесс в общей теории процессов». В первом случае речь идет об абстракции, представляющей работающую программу в ОС [4], во втором - о совокупности пространства состояний системы S, множества моментов изменения состояния системы Т и функционального отображения F ^ S (см. табл.). В дальнейшем, чтобы избежать двусмысленности, будем использовать термины «процесс ОС» и «процесс ОТП».
Рассмотрим составные элементы описания процесса ОС. В соответствии с ОТП, алгоритмическую модель процесса ОТП в [5] предложено определять как совокупность трека процесса ОТП и инициатора на данном треке:
ALG = (ТЯ, Л (2)
Исполняемым образом процесса ОС будем называть бинарный файл, оформленный в соответствии с внутренними правилами ОС, пригодный для порождения процесса ОС.
Память, принадлежащую процессу ОС, представим в виде тройки:
MEM = <MC, MD, MH>, (3)
где MC - память процесса ОС, содержащая исполняемый код (всё множество элементарных операторов процесса); MD - память процесса ОС, содержащая данные (множество параметров для элементарных операторов процесса); MH - память процесса ОС, содержащая созданные процессом объекты («куча»).
Дескрипторы ресурсов операционной системы, связанные с процессом ОС, представим следующим образом:
DSCR = (г, p)"w, (4)
где г - описатель конкретного ресурса ОС, предоставленного в пользование процессу ОС; p - права доступа к данному ресурсу, которыми наделён процесс ОС.
Параметры системы безопасности ОС для данного процесса - это множество разрешений, установленных для процесса, и описатель владельца процесса, т. е.:
LSA = ({ps}J=., OWNER), (5)
где {ps}m=. - множество прав данного процесса
J .
ОС; OWNER - описатель пользователя - владельца данного процесса ОС.
Блок состояния процесса ОС (контекст процесса ОС) может быть описан следующим образом:
CNTX = <PID, REGS, SP, PR> ,
где PID - идентификатор процесса ОС; REGS -значение регистров ЦП на момент последней команды, выполненной процессом; SP - указатель на вершину стека процесса ОС; PR - приоритет процесса ОС.
Будем рассматривать каждый процесс операционной системы с позиций ОТП как некоторый объект O Процесс ОТП, развивающийся в объекте Ol будем обозначать ZOl. Рассмотрим предложенное нами описание процесса ОС (!) и выявим параметры процесса ZO1.
Первый член в предложенном описании -IMG - исполняемый образ, из которого порожден процесс ОС. Данная характеристика процесса ОС является постоянной, её невозможно изменить, не завершив процесс ОС, следовательно, она не может выступать в роли параметра процесса ZO1.
MEM - память процесса ОС, представлена как тройка составных элементов (3). MD и MH - атрибуты с динамически изменяемым значением, выступают в роли параметров при описании процесса ZO'.
MC - память, содержащая основной алгоритм процесса ОС, по умолчанию недоступна для редактирования, однако в некоторых системах процессы ОС имеют право модифицировать этот вид памяти. Поскольку возможность изменения его исключена из современных ОС не полностью, будем считать данный атрибут параметром процесса ZOl.
С позиций ОТП параметром процесса ZO может считаться та характеристика соответствующего процесса в ОС, которую этот процесс ОС может изменить самостоятельно, не прибегая к передаче вызова в другие процессы. По этому признаку не являются параметрами процесса ZO следующие атрибуты и характеристики процесса:
ресурсы ОС, предоставленные в распоряжение процессу ОС (4);
параметры системы безопасности, установленные ОС для процесса ОС (5);
идентификатор процесса ОС (PID); приоритет процесса ОС (PR). Значения регистров и указателя на вершину стека (REGS и SP соответственно) - это параметры процесса ZOl, поскольку могут быть модифицированы процессом ОС.
Таким образом, для пользовательского процесса в ОС следующие элементы его описания являются элементами параметрического множества объекта ОТП, соответствующего рассматриваемому процессу в ОС.
ql = MC - память процесса ОС, занятая исполняемым кодом.
q2 = MD - память процесса ОС, занятая данными.
q3 = MH - память процесса ОС под «кучу» объектов.
q4 = SP - указатель на вершину стека процесса ОС. Весь стек вызовов, предшествующих данному этапу выполнения процесса ОС, может быть восстановлен из этого параметра. В общем случае является самостоятельным параметром и не входит в q5.
q5 = REGS - регистры ЦП, используемые данным процессом ОС.
Таким образом, процесс в объекте Ot в системе Q развивается на множестве параметров
[qv q2, q3, q4, q5}. Множество параметров, на которых определяется состояние объекта Ol с Q, и множество аргументов AO оператора генерации процесса HO' являются самостоятельными подмножествами Q.
Введём понятие множества возможных аргументов для генерации процесса и обозначим его a(AO') = {flO"}i=i. Данное множество будет включать в себя все те элементы, из которых может быть составлено множество аргументов AO' в конкретный момент времени t..
В общем случае развитие процесса зависит от следующего:
1. Памяти процесса, содержащей исполняемый код: a'O' = q1 = M
2. Памяти процесса, содержащей данные: a'O' =
= q2=MD'
3. «Кучи» процесса: a3O' = q3 = MH.
4. Указателя на вершину стека: a'O' = q4 = SP.
5. Значения регистров процессора: a'O' = q5 = = REGS = {regs}=v
6. Множества дескрипторов безопасности: a'O' = DESCR = {r, p}^.
7. Множества разрешений, установленных для процесса: aO' = ({ps}^ .
Очевидно, что a(A°') П O ф 0, но при этом a(AO') ф O,, т. е. множество возможных аргументов для генерации процесса в объекте O шире, чем множество параметров, на которых развивается процесс ZO'.
Если в системе существуют два объекта - Ol и O , и O, ^ O , это значит, что в некоторый мо-
m ' m 7 7 А
мент времени t. O tП AOmф 0, т. е. в момент времени t. параметры процесса в объекте O являются атрибутами генерации нового состояния объекта Om. Исследование пересечения множеств O 1 и AO позволит сделать вывод о том, по каким параметрам произошло сцепление объекта O 1 с объектом Om. То же верно для процессов ОТП, протекающих в этих объектах.
Применим предложенное формализованное описание процессов в ОС общего назначения Windows XP с целью исследования сцепленности процессов режима ядра с ядром ОС в момент вызова системных сервисов. По данным исследования компании w3schools (Норвегия) [8], на ноябрь 2009 Windows XP являлась самой распространённой ОС среди ОС общего назначения.
Как указано в [6], «руткиты» (вредоносные программы, скрывающие свое присутствие в системе) для ОС Windows XP являются суще-
ственной проблемой, т. к. архитектура данной ОС позволяет злоумышленнику легко осуществить доставку вредоносного кода на уровень максимальных привилегий (уровень ядра ОС). Аналитики «Лаборатории Касперского» отмечают [7] рост количества вредоносных программ, использующих руткит-технологии. На сегодняшний день авторами антивирусных продуктов предложен ряд методов для обнаружения скрытых процессов в системе (руткитов и защищаемых ими процессов), однако вирусные эпидемии последних лет [1, 2] показали необходимость совершенствования имеющихся методов.
ОС Windows XP содержит в себе специальный интерфейс системных вызовов, используя который, прикладные программы (через шлюз) и драйверы (напрямую) могут обратиться к ядру системы с запросом на выполнение привилегированных функций [3].
Рассмотрим систему, в которой развивается системный процесс ОС режима ядра (объект в терминах ОТП, соответствующий данному процессу, - OS ), а также процесс ядра ОС (OK). В дальнейшем для краткости, говоря о выполняющихся процессах в ОС, будем использовать обозначения соответствующих им объектов с позиций ОТП - OS и OK.
Системные сервисы режима ядра в ОС Windows XP размещены в ядре ОС. Следовательно, вызов системного сервиса из процесса OS вызовет смену выполняющегося процесса на OK. Большинство системных сервисов режима ядра имеют параметры - набор аргументов, передаваемых из вызывающих процессов. При вызове каждого системного сервиса в стеке сохраняется адрес возврата - он указывает внутрь MCOS. Системные сервисы возвращают значения тремя способами: через регистры ЦП, через рабочие параметры и через выходные параметры. Следовательно, процесс Oкразвивается на параметрах процесса OS, т. е.:
OS П А^ф 0,
где t. - момент смены выполняющегося процесса в системе при вызове системного сервиса.
Таким образом, процесс OK сцеплен с процессом OS, т. е. OS ^ OK .
Среди параметров процесса OK есть указатель на вершину стека aOK = SP, куда процесс OS помещает адрес возврата. Атрибут a4OK с позиций ОТП является локальной средой процесса OK , по данному значению процессы OS и OK сцеплены.
Таким образом, анализируя атрибут aOK, мы можем легко получить адрес возврата A Очевидно, что в рассматриваемом случае:
A е MOs
RET C
При наличии в системе процесса OH, скрывающего свое присутствие, он будет передавать ядру всякий раз, при вызове им системных сервисов, параметр aOH.
Один из системных сервисов (ZwQuerySystem Information) при запросе типа SystemModulelnfor-mation возвращает информацию о загруженных драйверах режима ядра с сообщением для каждого модуля данных:
SM = {BASE, SIZE),
где BASE - начальный адрес (база) загрузки модуля в память; SIZE - размер модуля.
Верно следующее: M°hс [BASEh, BASEh + + SIZEH], поскольку область памяти процесса OH не выходит за границы памяти, отведённой данному драйверу системой при его загрузке.
Соответственно, если ARETg [J [BASE., BASE. +
Vi
+ SIZE ], то мы можем утверждать, что вызов в системный сервис пришел из скрытого модуля.
Такой способ обнаружения скрытых процессов эффективен по следующим причинам: во-первых, практически все известные сегодня вредоносные программы, работающие в режиме ядра ОС, вызывают системные сервисы, во-вторых, при сокрытии процессов в системе они, как правило, исключаются из выдачи сервиса ZwQuerySystemlnformation. Таким образом, сравнительный анализ позволит легко выявить несоответствие.
Предложена практическая реализация указанного способа. Суть данной реализации сводится к перехвату управления контролирующим драйвером всякий раз при вызове системного сервиса с последующим анализом адреса возврата на стеке и сравнением его со списком загруженных в систему модулей (процессов режима ядра ОС).
Возможна ситуация, при которой вредоносный код, скрывающий свое присутствие в систе-
ме, для обеспечения своего функционала обращается к системным сервисам, минуя стандартный шлюз, или непосредственно к нижележащим функциям. К примеру, на рисунке представлен стек системных вызовов при выполнении АР1-функции ReadFile (запроса на чтение данных).
CLflSSP HP ÎClassRead Write
nttIopfCallDriuer+0x31
PartMgrîPmReadWrite+Bx2d
ntfIopfCallDriuer+0x31
ftdisk!FtDiskReadWrite+0x19ii
nttIopfCallDriuer+0x31
UolSnap'UolSnapRead+Bx26
ntfIopfCallDriuer+0x31
Ntfs!NtfsSingleAsync+0x6d
NtfstNtfsUolumeDasdIo+0x3d
Ntfs!NtfsCommonRead+0x23d
Ntfs!NtfsFsdRead+0x22d
nt!IopfCallDriuer+Bx31
sr!SrPassThrough+0x31
nt!IopfCallDriuer+0x31
nt ! IopSjinchronousSeruiceTail+0x6 0
nt?NtReadFile+0x580
nt!KiFastCallEntry+Bxf8
ntdll+0xeb94
kernel32fReadFile+0x67
test!main+0xce
Режим ядра ОС
Пользовательский режим
Передача API-запроса на чтение файла ReadFile
Роль шлюза исполняет функция KiFastCall Entry, которая передаёт запрос из API-функции ReadFile в режим ядра, в системный сервис NtRead-File. После системного сервиса вызов проходит ещё шестнадцать вызовов, прежде чем будет непосредственно исполнен. Соответственно, вредоносный код может инициировать запрос на чтение на любом из этих уровней. Предложенный выше способ обнаружения в этом случае требует модернизации: перехват с передачей управления в контролирующий драйвер следует производить как можно ниже по стеку вызовов (ближе к вершине рисунка), с последующим обратным анализом стека вызовов и поиском адреса возврата, не принадлежащего существующим в системе модулям.
В статье показано лишь одно из возможных применений теории процессов к описанию структуры процессов и их сцепленности в ОС. Выявить все множество задач, решаемых при помощи применения ОТП с целью описания структуры элементов ОС, - это задача будущих исследований.
СПИСОК ЛИТЕРАТУРЫ
1. Буткит 2009 [Электронный ресурс] // Лаборатория Касперского: [сайт]. [2009]. URL: http://www. securelist.com/ru/ analysis/204007655/Butkit_2009 (дата обращения 24.02.2010)
2. Буткит: вызов 2008 [Электронный ресурс] //Лаборатория Касперского: [сайт]. [2008]. URL: http://www. securelist.com/ru/analysis /204007635/Butkit_vyzov_2008 (дата обращения 24.02.2010)