СПОСОБ СОЗДАНИЯ ОБРАБОТЧИКА СИСТЕМНЫХ ВЫЗОВОВ
METHOD OF CREATING A SYSTEM CALL HANDLER

Область техники
Изобретение относится к антивирусным технологиям, а более конкретно, к способу создания обработчика системных вызовов.
Уровень техники
В настоящее время современные антивирусные продукты используют перехват системных вызовов для того, чтобы можно обнаруживать вредоносные программы, например, уже на стадии их выполнения. Например, на использовании подобных перехватов построена технология System Watcher (1). Перехватывая системные вызовы, которые ведут к подозрительным действиям (например, запись исполняемого файла в папку Windows), можно блокировать даже пока еще неизвестные вредоносные программы, что является одним из ключевых достоинств современных антивирусов.
Однако возможность перехвата вызовов системных сервисов в 64-разрядных версиях операционной системы (ОС) Windows ограничивается реализованной Microsoft системой защиты Patch Guard (http://msdn.microsoft.com/en-us/library/windows/hardware/dn613955(v=vs.85).aspx), препятствующей применению классических методов перехвата. Patch Guard отслеживает изменения в ряде важных объектов ядра ОС (как вредоносных изменений вследствие работы руткитов или же из-за модификаций сторонним программным обеспечением, таким как антивирусы) - например, таблицу системных вызовов или таблицу векторов прерываний (англ. Interrupt Descriptor Table, IDT) - и при обнаружении изменений в них вызывает крах системы.
В настоящий момент описаны технологии, которые позволяют обойти защиту, аналогичную PatchGuard. Например, патент US 7996836 описывает подход к использованию гипервизора для обхода Patchguard. При использовании гипервизора появляется возможность создания перехватчиков упомянутых объектов ядра без краха системы.
Таким образом, обход защиты PatchGuard возможен при помощи аппаратной виртуализации. Однако создание перехватчиков для объектов ядра (например, для контроля SSDT) требует знания их внутренней структуры, которая меняется в зависимости от версии ОС Windows, что требует выпуска адаптированной версии перехватчика для поддержки очередной версии ОС.
Анализ предшествующего уровня техники позволяет сделать вывод о неэффективности и в некоторых случаях о невозможности применения предшествующих технологий, недостатки которых решаются настоящим изобретением, а именно способом создания перехватчика системных вызовов, который можно использовать на различных версиях операционных систем.
Раскрытие изобретения
Технический результат настоящего изобретения заключается в обеспечении возможности обработки системных вызовов.
Согласно одному из вариантов реализации, предлагается способ вызова обработчика системных вызовов, содержащий этапы на которых: локализуют код оригинального обработчика системных вызовов; создают модифицированный обработчик системных вызовов, путем выделения памяти и копирования туда кода оригинального обработчика, при этом дополнительно выполняют следующие шаги: а) модифицируют относительные ссылки в коде модифицированного обработчика; б) заменяют адреса сервисных таблиц в коде модифицированного обработчика; перехватывают вызов инструкций процессора, связанных с системным вызовом; вызывают модифицированный обработчик системных вызовов.
В одном из частных вариантов реализации при локализации кода оригинального обработчика системных вызовов определяют местоположение и размер кода.
В еще одном частном варианте реализации инструкциями процессора, связанными с системным вызовом, являются RDMSR и WRMSR.
В другом частном варианте реализации перехват осуществляется с помощью гипервизора.
В одном из частных вариантов реализации при создании модифицированного обработчика дополнительно изменяют таблицу исключений.
Краткое описание чертежей
Дополнительные цели, признаки и преимущества настоящего изобретения будут очевидными из прочтения последующего описания осуществления изобретения со ссылкой на прилагаемые чертежи, на которых:
Фиг. 1 приводит пример модификации системного вызова;
Фиг. 2 иллюстрирует пример загрузки обработчика;
Фиг. 3 приводит способ использования гипервизора для обхода Patch Guard;
Фиг. 4 иллюстрирует способ обработки системных вызовов;
Фиг. 5 иллюстрирует пример реализации компьютерной системы, на которой может быть реализовано настоящее изобретение;
Фиг. 6 показывает пример выполнения API-функции в операционной системе Windows;
Фиг. 7 приводит пример вызова системной службы.
Описание вариантов осуществления изобретения
Объекты и признаки настоящего изобретения, способы для достижения этих объектов и признаков станут очевидными посредством отсылки к примерным вариантам осуществления. Однако настоящее изобретение не ограничивается примерными вариантами осуществления, раскрытыми ниже, оно может воплощаться в различных видах. Сущность, приведенная в описании, является ничем иным, как конкретными деталями, необходимыми для помощи специалисту в области техники в исчерпывающем понимании изобретения, и настоящее изобретение определяется в объеме приложенной формулы.
Для лучшего понимания настоящего изобретения, в первую очередь будет приведено описание работы механизмов вызова системных функций в ОС Windows.
Фиг. 6 показывает пример выполнения API-функции в операционной системе Windows. В качестве примера API-функции была выбрана WriteFile. На этапе 610 Windows приложение (например, Microsoft Word или Notepad) пытается записать данные в файл путем вызова соответствующей Win32 API функции WriteFile в Kerael32.dll. Затем на этапе 620 происходит вызов NtWriteFile в Ntdll.dll (т.е. происходит последовательный вызов всех связанных системных функций), что в свою очередь приводит к вызову системного прерывания на этапе 630 и поиску соответствующего обработчика (что делает функция KiSystemService в Ntoskrnl.exe) при вызове NtWriteFile. Отметим, что данный процесс происходит в режиме пользователя, а после вызова прерывания происходит переход в режим ядра. На этапе 640 происходит вызов NtWriteFile уже непосредственно в Ntoskrnl.exe и непосредственно выполнение записи в файл на этапе 650 (здесь также скрыты детали, связанные с работой драйвера файловой системы).
Разберем более подробно этап 630, связанный с вызовом инструкции SYSCALL. В настоящий момент в современных процессорах архитектуры х86 для перехода из режима пользователя (англ. user mode) в режим ядра (англ. kernel mode) требуется вызвать инструкцию SYSCALL/SYSENTER (далее будем использовать только SYSCALL). На архитектуре х64 адрес данного обработчика хранится в регистре LSTAR (Long System Target-Address Register), который относится к регистрам MSR (Machine Specific Registers).
На Фиг. 7 приведен пример вызова системной службы. При переходе в режим ядра диспетчер системных служб 710 (в ОС Windows это KiSystemService) копирует аргументы системного вызова из стека потока пользовательского режима в свой стек режима ядра (чтобы пользователь не смог изменить аргументы при обращении к ним ядра), а затем выполняет системную службу 720 из таблицы системных служб 730 (в ОС Windows это System Service Dispatch Table, SSDT).
Таким образом, в рамках работающих таких методов защиты как Patch Guard для модификации системной службы 720 потребуется модифицировать саму таблицу 730, что приведет к краху системы. Для того чтобы можно было обойти подобное ограничение, требуется создать собственную копию таблицы 730, но кроме того - использовать собственный обработчик вызова SYSCALL (далее для упрощения будем использовать сокращение обработчик) с целью использования собственной таблицы системных служб (будем считать это структурами операционной системы, связанные с вызовами системных функций). Далее на Фиг. 2 и 3 будет рассмотрен пример создания и использования обработчика вызова SYSCALL.
На Фиг. 1 приведен пример модификации системного вызова (например, обработчика определенной файловой операции). В адресном пространстве ядра 100 по определенному адресу загружен оригинальный обработчик 110, который необходимо модифицировать под свои нужды. Модификация кода может быть основана на использования ряда таких приемов, как подмена адреса (например, с помощью модификации SSDT/IDT таблиц), непосредственное изменение обработчика (например, с помощью сплайсинга) или модификация тела самой системной функции. Подменив адрес обработчика 110 на адрес другого обработчика 120 можно реализовать необходимый функционал - например, включив антивирусную проверку ряда файловых или реестровых операций. Однако отметим, что, так как Patch Guard проверяет значения регистра MSR, то подменить значение данного регистра (более подробно про этот регистр описано ниже) с использованием вышеописанных техник невозможно.
Для обхода Patch Guard можно использовать виртуализацию, используя гипервизор. На Фиг. 3 приведен пример использования гипервизора для обхода Patch Guard. Гипервизор 300 имеет более высокую привилегию для выполнения (уровень - 1, в то время как у ядра 0, а уровень пользовательских приложений 3), может быть загружен в любой момент, как при старте ОС, так и во время ее работы. При инициализации гипервизора 300 задается список инструкций, который можно перехватывать с его помощью. Для перехвата инструкции SYSCALL достаточно указать перехват инструкций RDMSR (чтение MSR) и WRMSR (запись в MSR).
Таким образом, используя гипервизор 300 можно контролировать регистр MSR (в частности, LSTAR, далее для обобщения будем использовать лишь MSR), записывая необходимое значение 320а и сохраняя оригинальное значение 3206. Это дает возможность подставлять оригинальное значение 3206 для считывания такими средствами защиты как Patch Guard (и не вызывая краха системы), но в то же время использовать необходимый адрес 320а для использования измененного обработчика.
Пример загрузки обработчика приведен на Фиг. 2. На этапе 210 происходит определение адреса в памяти кода оригинального обработчика 110 - определяется размер и положение в памяти загруженного образа. Затем на этапе 220 создается копия обработчика 110 в виде образа 120. Размер памяти под копию должен быть выделен с учетом возможных изменений. Предпочтительным вариантом является выделение памяти в памяти уже загруженного драйвера 130, что облегчит модификацию кода обработчика. Подобными изменениями являются - модификация относительных ссылок на этапе 230, замена в коде обработчика 120 адресов сервисных таблиц (например, SSDT) на этапе 240 и инициализация таблицы исключений на этапе 250. Последнее необходимо для того, что корректно обрабатывать исключения, связанные с выполнением кода обработчика 120. Все вышеперечисленные изменения возможно сделать с применением дизассемблера, который необходим для разбора команд обработчика 110 и их последующей модификации (этапы 230-250). Данные изменения являются необходимыми для того, чтобы можно было корректно заменить обработчик 110. Другие изменения могут относиться к различным областям компьютерной безопасности, связанной с анализом перехваченных вызовов.
После того, как обработчик 120 был инициализирован, его можно использовать для перехвата системных вызовов. В качестве интересующих вызовов можно рассматривать файловые и реестровые операции, операции, связанные со снятием снимков экрана. Можно отметить, что в последних версиях ОС Windows можно использовать перехваты файловых и реестровых операций, используя сам API ОС.
В рамках ОС Windows для борьбы с определенным классом вредоносных программ, которые делают снимки экрана (скриншоты, англ. screenshots) с целью выделения в них важной пользовательской информации (например, пароли), требуется обеспечить контроль перехватов функций, связанных со снятием снимков экрана. Существует ряд техник, которые позволяют получить описатель (дескриптор) окна необходимого приложения и скопировать растр (англ. bitmap) с него или же использовать поверхности Direct3D (Direct3D surface) для их преобразования в растр прямо в памяти и последующим сохранением на диск для анализа. Для того, чтобы можно было отследить вредоносные приложения, которые используют подобные техники, требуется не только обеспечить перехват вызова SYSCALL, но также модифицировать SSDT таблицу для перехвата необходимых вызовов.
Надо отметить, что гипервизор 300 не обязательно загружать всегда и держать его в памяти во время работы ОС. Гипервизор 300 может быть загружен и во время работы ОС при выполнения одного из следующих условий:
- Загрузка критичного приложения (например, банковского приложения), для которого необходимо обеспечить защиту от снятия снимков экрана
- Пользователь зашел на сайт банка или платежной системы (например, PayPal), в рамках которого также требуется обеспечить защиту от снятия снимков экрана
- Антивирусное приложение требует наличия самозащиты (т.е. защита от попыток закончить процесс антивирусного приложения или остановить работу антивирусного драйвера), что приводит к необходимости отслеживания соответствующих системных вызовов
- Более гибкое управление системой контроля приложений (англ. application control) с помощью подмены системных вызовов, реализация изолированной среды (англ. sandbox)
- Осуществление глубокой проверки подозрительного приложения в рамках эмуляции его поведения. В этом случае вызываются не настоящие обработчики сервисных функций ядра, а вызываются специальные функции эмулятора поведения ОС. При этом никаких изменений в настоящей ОС не проводится, однако приложение считает, что выполняется на реальной системе. На основе протоколов эмулятора определяется степень опасности приложения. Данная проверка может осуществляться как на машине пользователя, так и на выделенном облачном сервисе.
При выполнении одного из подобных условий на этапе 410 на Фиг. 4 (которая иллюстрирует способ обработки системных вызовов) будет загружен гипервизор. Таблица SSDT будет модифицирована на этапе 420. Обработчик функции SYSCALL будет загружен на этапе 430 (загрузка проиллюстрирована на Фиг. 2). На этапе 440 происходит перехват вызова, с помощью модифицированной таблицы SSDT контекст вызова (например, какой процесс произвел вызов) передается на этапе 450 на антивирусный анализ, в рамках которого, например, может быть определено, является ли вредоносным процесс, который осуществил вызов. Таким образом, в рамках этапа 450 вызывается модифицированный обработчик, чей адрес указан модифицированной таблицы SSDT.
Также стоит отметить, что в ряде случаев может потребоваться синхронизация оригинальной и модифицированной таблицы SSDT. Оригинальная таблица SSDT может быть обновлена в рамках процедуры hot patching.
Кроме того, предложенная схема перехвата с использованием гипервизора может быть реализована таким образом, чтобы не снижать уровень защиты ОС, обеспечиваемый технологией PatchGuard, так как все загружаемые модули на х64 системах проходят проверку подписи, и с помощью гипервизора может быть реализована защита копии перехватчика и копии сервисных таблиц от изменения, обеспечивая даже более надежный эквивалент защиты PatchGuard.
Фиг. 5 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 20, содержащий центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) 26, содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.
Персональный компьютер 20 в свою очередь содержит жесткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20.
Настоящее описание раскрывает реализацию системы, которая использует жесткий диск 27, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации 56, которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине 23 через контроллер 55.
Компьютер 20 имеет файловую систему 36, где хранится записанная операционная система 35, а также дополнительные программные приложения 37, другие программные модули 38 и данные программ 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатуры 40, манипулятора «мышь» 42). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканнер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе 20 через последовательный порт 46, который в свою очередь подсоединен к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 47 или иной тип устройства отображения также подсоединен к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47, персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например, колонками, принтером и т.п.
Персональный компьютер 20 способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удаленными компьютерами 49. Удаленный компьютер (или компьютеры) 49 являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера 20, представленного на Фиг. 5. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.
Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 50 и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях, внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключен к локальной сети 50 через сетевой адаптер или сетевой интерфейс 51. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключен к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.
В заключение следует отметить, что приведенные в описании сведения являются примерами, которые не ограничивают объем настоящего изобретения, определенного формулой.