Результат интеллектуальной деятельности: СИСТЕМА И СПОСОБ СОХРАНЕНИЯ СОСТОЯНИЯ ЭМУЛЯТОРА И ЕГО ПОСЛЕДУЮЩЕГО ВОССТАНОВЛЕНИЯ

Область техники

Изобретение относится к антивирусным решениям, а более конкретно к способам сохранения состояния эмулятора и его последующего восстановления.

Уровень техники

Код современных программ, в том числе вредоносных, представляет собой сложный набор инструкций: переходов, вызовов, циклов и т.д. Стоит отметить, что сложность исполняемых файлов постоянно увеличивается, что связано с ростом популярности языков программирования высокого уровня, а также усложнением компьютерной техники и операционных систем. Это относится как к доверенным приложениям, так и к вредоносным. Вредоносные приложения могут совершать ряд характерных действий, таких как кража паролей и других конфиденциальных данных пользователя, включение компьютера в бот-сеть для проведения DDoS-атак или рассылки спама, блокирование корректного функционирования системы с целью вымогательства и другие отрицательные и нежелательные с точки зрения пользователя действия.

Одним из методов исследования потенциально вредоносной программы является использование эмулятора, который применяется в антивирусном приложении при анализе поведения приложения. Существуют различные способы эмуляции. Одним из них является программная имитация процессора, памяти и других устройств путем создания виртуальных копий регистров процессора, памяти и набора инструкций процессора. Таким образом, инструкции программы исполняются не на реальном процессоре, а на его виртуальной копии, а вызовы системных API-функций эмулируют и отправляют в ответ проэмулированный результат работы функции.

Стоит отметить, что процесс инициализации эмулятора может быть достаточно ресурсоемким. Инициализация эмулятора должна включать не только создание виртуальной копии необходимых аппаратных средств (процессор, оперативная память), но также и виртуальных копий ряда ключевых компонентов операционной системы (ОС), в рамках которой происходит эмуляция выполнения приложения. В качестве ключевых компонентов ОС можно привести, например, часть ядра операционной системы, отвечающей за необходимые механизмы ее работы, такие как обработка прерываний и исключений, драйверы необходимых устройств, управление памятью и т.д. Для корректного “воспроизведения” (эмуляции) работающей ОС необходимо повторить процесс ее загрузки, пусть и в достаточно упрощенном виде.

На Фиг.1 отображен процесс загрузки операционной системы Windows. На этапе 101 загружается Windows Boot Manager, который отвечает за поиск установленных ОС Windows и возможность выбора загрузки любой из найденных. Далее, на этапе 102, происходит загрузка базовых драйверов, которые отвечают, например, за возможность работы с разделом жесткого диска, на котором установлена выбранная ОС (т.е. загружается драйвер файловой системы). Далее с диска считывается и загружается в память часть ядра ОС на этапе 103, например Ntosrnl.exe и hal.dll, производится инициализация реестра, менеджера памяти, менеджера объектов и т.д. На этапе 104 происходит загрузка менеджера сессий (smss.exe), который отвечает за загрузку системных переменных, подсистемы Win32 и дальнейшую загрузку winlogon.exe на этапе 105. После того как пользователь успешно пройдет аутентификацию на этапе 106, произойдет загрузка приложений и служб, прописанных с ключом автозапуска, после чего ОС будет полностью готова к взаимодействию с пользователем, ожидая запуска приложений и ввода данных.

Для процесса эмуляции необязательно полностью эмулировать загрузку операционной системы. Например, этапы 101 и 102 можно убрать, оставив лишь этапы 103 и 104 в упрощенном виде. Т.е. достаточно будет проэмулировать самый необходимый для работы ОС функционал, который позволит провести эмуляцию приложения. Для Win32 приложений нужно будет проэмулировать запуск smss.exe с последующим запуском csrss.exe, что инициализирует Windows подсистему и позволит создавать процессы и потоки. Так как эмуляция потенциального вредоносного приложения требует создания более детальной работающей среды (например, эмуляции других запущенных процессов), то также потребуется проэмулировать запуск winlogon.exe с последующим “запуском” таких процессов как explorer.exe и services.ехе, при этом от последнего можно эмулировать “запуск” процессов svchost.exe. Под термином “запуск” в данном случае подразумевается воссоздание в эмуляторе тех же процессов, что протекают и при создании процессов в рамках реальной ОС, пусть и в сильно упрощенном виде. Подобный подход позволяет воссоздать реальную ОС в достаточной степени, чтобы можно было запустить практически любое приложение, предназначенное для работы в данной ОС. Для потенциально вредоносных приложений подобная детализация воссоздания окружения также необходима как для обхода возможных приемов для противодействия эмуляции (англ. anti-emulation tricks), которые могут включать как раз проверки наличия запущенных служб, установленных системных переменных и других элементов, присутствующих в реальной ОС, так и для возможности реализации вредоносного функционала, который может быть направлен на определенные приложения. В качестве примера можно привести процесс explorer.exe, который часто подвергается заражению, процессы веб-браузеров, для которых может быть использован соответствующий эксплойт и т.д.

Таким образом, проблема создания соответствующего окружения для эмуляции возможно вредоносного приложения требует воссоздания как можно более детального воссоздания реальной ОС и запущенных в ней приложений. Процесс инициализации подобного окружения может занимать достаточно много времени и ресурсов (запуск процесса эмуляции, загрузка с жесткого диска в память всех необходимых данных для инициализации таких виртуальных структур, как файловая система, реестр и т.д.), что сокращает время на собственно саму эмуляцию кода приложения.

В настоящий момент существуют подходы для сохранения состояния эмулируемой среды. Например, эмулятор QEMU поддерживает создание образов, в том числе и для исключения необходимости выполнять процесс загрузки ОС. Однако образ сохраняется на диск лишь по запросу пользователя, и не поддерживает какой-либо структуры сохранения ряда записанных образов. Данный подход полностью совпадает с режимом работы менеджера виртуальных машин. В заявке US 20060155525 рассматривается вариант создания образов состояния эмулируемой системы в файл при обнаружении особой инструкции (которая вставляется заранее пользователем). Стоит отметить, что в данной публикации идет речь о комбинировании программной эмуляции и симуляции некоторого связанного с программой аппаратного комплекса.

Однако в приведенных публикациях не рассматривается подходов для автоматического создания образов эмулируемой системы, а также состояния выполнения эмулируемого приложения, что позволило бы отследить все возможные ветвления выполнения программного кода. С точки зрения анализа вредоносных программ подобный подход позволил бы обойти приемы для противодействия эмуляции.

Для противодействия эмуляции программного кода создатели вредоносных программ используют различные уловки, которые могут базироваться на ограничениях, связанных с процессом эмуляции и реализацией эмулятора в антивирусных решениях. Эмулятор создает виртуальную копию процессора, компонентов компьютера и операционной системы (ОС) лишь в ограниченном объеме с усеченными возможностями, так как полное воссоздание всех возможностей того же процессора или системных API-функций невозможно по ряду причин: большие трудозатраты на подобную разработку, наличие недокументированных функций, большое падение производительности при работе подобного эмулятора. Таким образом, создатели вредоносных программ могут прибегать к следующим приемам, которые позволяют обнаружить факт выполнения в эмулируемой среде:

- Вызов недокументированной или редко используемой API-функции.

- Выполнение ряда инструкций центрального процессора с последующей проверкой, например, ряда установленных флагов. При недостаточно точной эмуляции команд процессора ряд флагов может иметь значения, отличные от тех, что были бы установлены при выполнении на процессоре.

- Проверка корректности выполнения API функции. Проверка может быть очень усложненной и включать анализ возвращаемых кодов ошибки при некорректном вызове или проверку установленных регистров процессора.

- Поиск в памяти определенных байт. Например, побайтовый поиск заголовка MZ в памяти после загрузки kemel32.dll при старте процесса. В ОС Vista 64 для kemel32.dll используется 64Кб выравнивание, и область между заголовком и первой секцией не будет отображена в адресное пространство процесса, и при попытке доступа к ней произойдет исключение. Если исключение не было зарегистрировано, то будет вызван стандартный обработчик исключений ОС, который завершит процесс.

Анализ предшествующего уровня техники и возможностей, которые появляются при комбинировании их в одной системе, позволяют получить новые результаты, а именно сокращение времени на эмуляцию файла путем загрузки необходимых образов состояния эмулятора, обход антиэмуляционных приемов при эмуляции файла путем загрузки необходимых образов состояния эмулятора для продолжения эмуляции в случае некорректного завершения эмуляции файла, загрузку необходимых образов состояния эмулятора для продолжения эмуляции в случае некорректного завершения эмуляции файла.

Раскрытие изобретения

Первый технический результат настоящего изобретения заключается в сокращении времени на эмуляцию файла путем загрузки необходимых образов состояния эмулятора.

Второй технический результат настоящего изобретения заключается в обходе антиэмуляционных приемов при эмуляции файла путем загрузки необходимых образов состояния эмулятора для продолжения эмуляции в случае некорректного завершения эмуляции файла.

Третий технический результат настоящего изобретения заключается в загрузке необходимых образов состояния эмулятора для продолжения эмуляции в случае некорректного завершения эмуляции файла.

Согласно одному из вариантов реализации, предлагается способ для эмуляции файлов, содержащий этапы на которых: получают файл на эмуляцию; проверяют, выполняется ли эмуляция в первый раз; определяют образ состояния эмулятора, который загружается в эмулятор для последующей эмуляции файла; производят эмуляцию файла; создают образы состояния эмулятора; проверяют некорректное завершение эмуляции файла; выбирают необходимый образ для продолжения эмуляции в случае некорректного завершения эмуляции файла; загружают выбранный образ для продолжения эмуляции файла.

В одном из частных вариантов реализации получают файл на эмуляцию по крайней мере в одном из следующих случаев: файл является неизвестным и требуется провести его эмуляцию для определения его возможной вредоносности; эмуляция необходима для определения всех возможных кодов ошибок; эмуляция необходима для исследования функционала приложения, когда необходимо определить какие используются системные вызовы, список необходимых сторонних библиотек.

В другом частном варианте реализации необходимым условием создания новых образов состояния эмулятора является, по меньшей мере, одно из следующих условий: ветвление в коде; применение антиэмуляционного приема; эмуляция определенного количества инструкций; периодическое создание образов через заданные промежутки времени.

В еще одном из частных вариантов реализации некорректное завершение эмуляции файла может быть, по меньшей мере, одним из: слишком быстрое завершение эмулируемого процесса; отсутствие необходимых библиотек; необработанное исключение.

В одном из частных вариантов реализации образы состояния эмулятора создаются в виде древовидной структуры, при этом переходы между образами строятся на основании условий созданий новых образов состояния эмулятора.

В другом частном варианте реализации загружают выбранный образ для продолжения эмуляции файла с изменениям состояния эмулятора.

В еще одном из частных вариантов реализации изменением состояния эмулятора может быть, по меньшей мере, одно из: переход в другую ветку кода при условном переходе; изменение статуса описателей ресурсов; откат сделанных ранее изменений; изменение значения выполненной функции.

Согласно одному из вариантов реализации, предлагается система для эмуляции файлов, содержащая средства: эмулятор, связанный со средство загрузки образов и средством создания образов, при этом эмулятор предназначен для получения файла, последующей эмуляции файла и проверки некорректного завершения эмуляции файла; средство загрузки образов, связанное с базой данных образов, при этом средство загрузки образов предназначено для определения и загрузки образа состояния эмулятора, который загружается в эмулятор для последующей эмуляции файла, в том числе и при некорректном завершении эмуляции файла; средство создания образов, связанное с базой данных образов, при этом средство создания образов предназначено для создания образов состояния эмулятора; база данных образов, предназначенная для хранения образов состояния эмулятора.

В одном из частных вариантов реализации эмулятор получает файл на эмуляцию по крайней мере в одном из следующих случаев: файл является неизвестным и требуется провести его эмуляцию для определения его возможной вредоносности; эмуляция необходима для определения всех возможных кодов ошибок; эмуляция необходима для исследования функционала приложения, когда необходимо определить какие используются системные вызовы, список необходимых сторонних библиотек.

В другом частном варианте реализации необходимым условием создания новых образов состояния эмулятора является по меньшей мере одно из следующих условий: ветвление в коде; применение антиэмуляционного приема; эмуляция определенного количества инструкций; периодическое создание образов через заданные промежутки времени.

В еще одном из частных вариантов реализации некорректное завершение эмуляции файла может быть по меньшей мере одним из: слишком быстрое завершение эмулируемого процесса; отсутствие необходимых библиотек; необработанное исключение.

В одном из частных вариантов реализации образы состояния эмулятора создаются в виде древовидной структуры, при этом переходы между образами строятся на основании условий созданий новых образов состояния эмулятора.

В другом частном варианте реализации загружают выбранный образ для продолжения эмуляции файла с изменениям состояния эмулятора.

В еще одном из частных вариантов реализации изменением состояния эмулятора может быть по меньшей мере одно из: переход в другую ветку кода при условном переходе; изменение статуса описателей ресурсов; откат сделанных ранее изменений; изменение значения выполненной функции.

Краткое описание чертежей

Дополнительные цели, признаки и преимущества настоящего изобретения будут очевидными из прочтения последующего описания осуществления изобретения со ссылкой на прилагаемые чертежи, на которых:

Фиг.1 отображает процесс загрузки операционной системы Windows.

Фиг.2 иллюстрирует способ работы настоящего изобретения.

Фиг.3 показывает древовидное представление хранения образов состояния эмулятора.

Фиг.4 иллюстрирует возможные образы состояния эмулятора в зависимости от загруженных процессов.

Фиг.5 отображает работу системы настоящего изобретения.

Фиг.6 показывает компьютерную систему общего назначения, на которой может быть реализовано настоящее изобретение.

Описание вариантов осуществления изобретения

Объекты и признаки настоящего изобретения, способы для достижения этих объектов и признаков станут очевидными посредством отсылки к примерным вариантам осуществления. Однако настоящее изобретение не ограничивается примерными вариантами осуществления, раскрытыми ниже, оно может воплощаться в различных видах. Сущность, приведенная в описании, является ничем иным, как конкретными деталями, необходимыми для помощи специалисту в области техники в исчерпывающем понимании изобретения, и настоящее изобретение определяется в объеме приложенной формулы.

Фиг.2 иллюстрирует способ работы настоящего изобретения. На этапе 201 происходит начало эмуляции файла. Вариантов, когда файл необходимо эмулировать, может быть несколько:

- Файл является неизвестным и требуется провести его эмуляцию для определения его возможной вредоносности;

- Эмуляция необходима для определения всех возможных кодов ошибок при выполнении эмуляции, например, инсталлятора приложения;

- Эмуляция необходима для исследования функционала приложения, когда необходимо определить какие используются системные вызовы, список необходимых сторонних библиотек и т.д.

На этапе 202 определяется, выполняется ли эмуляция в первый раз или нет. В том случае, если эмуляция происходит в первый раз, то на этапе 203 создается первоначальный образ состояния эмулятора, который включает минимально необходимый функционал ОС, описанный в рамках Фиг.1. Помимо инициализации функционала ОС, в эмулятор может быть загружен модуль для обнаружения вредоносного кода, состояние виртуальной файловой системы, реестра, дерево объектов. Различные образы состояния эмулятора могут включать в себя также загруженные в память процессы (например, процессы важных служб), открытые описатели ресурсов (например, файлов), процессы с потоками (например, эмулируемый исполняемый файл). Следовательно, образ представляет собой копию всех перечисленных объектов в памяти, хранить который предпочтительно в оперативной памяти для ускорения процедур сохранения и восстановления.

Если эмуляция производится уже не в первый раз (например, была произведена эмуляция другого файла ранее), то на этапе 204 происходит определение нужного образа состояния эмулятора, который загружается в эмулятор для последующей эмуляции файла на этапе 205. Определение нужного образа состояния эмулятора будет описано ниже.

При проведении эмуляции на этапе 206 определяется выполнение необходимых условий для создания новых образов состояния эмулятора. В качестве примеров подобных условий можно привести следующие события:

- Ветвления в коде (условные переходы).

- Определение с помощью сигнатуры применение возможного антиэмуляционного приема (например, это может быть вызов редко используемых API функций с последующей проверкой результата их исполнения).

- Эмуляция определенного количества инструкций.

- Периодическое создание образов через заранее заданные промежутки времени.

В дальнейшем на этапе 207 определяется, что завершилась ли эмуляция успешно или нет. Успешный результат на этапе 208 предполагает либо обнаружение вредоносного поведения при эмуляции исполняемого файла, либо завершение по истечению времени (или после выполнения определенного количества инструкций). Некорректное завершение процесса эмуляции предполагает слишком быстрое завершение эмулируемого процесса (возможное срабатывание одного из антиэмуляционных приемов), отсутствие необходимых библиотек, необработанное исключение, которое приводит к завершению процесса (это может быть связано с ошибками в программном коде). При некорректном завершении процесса эмуляции на этапе 209 происходит выбор необходимого образа для продолжения эмуляции (более подробно это раскрывается в рамках описания Фиг.3). На этапе 210 в эмулятор загружается необходимый образ и эмуляция заново продолжается на этапе 211, который переходит заново к этапу 206. Таким образом, подобный подход позволит корректно завершить эмуляцию даже тех исполняемых файлов, эмуляция которых при использовании стандартных методов эмуляции завершалась бы некорректно.

Фиг.3 показывает древовидное представление хранения образов состояния эмулятора. Подобная древовидная структура позволяет сохранять образы состояния эмулятора в зависимости от одного из условий:

- Загрузка в память образа исполняемого файла, который требуется проэмулировать. Откат к подобному образу позволяет начать заново эмуляцию исполняемого файла, по сути, “с чистого листа”.

- Загрузка в память необходимого процесса, например Internet Explorer. Использование данного образа позволит проводить эмуляцию возможных вредоносных файлов, которые требует для своего выполнения наличие запущенного процесса Internet Explorer (в адресное пространство которого возможно будет записан некоторый вредоносный код).

- Выполнение определенных действий при эмуляции кода исполняемого файла. Во время эмуляции могут происходить условные переходы, которые могут быть частью проверок для противодействия эмуляции (например, при неудачном выполнении определенных проверок эмулируемая программа просто завершит свое выполнение).

Рассмотрим, для примера, следующий вариант сохранения и загрузки образов состояния эмулятора. Например, образ №1 - это первоначальный образ Windows, который включает состояние системы сразу после загрузки. Условием №1 является загрузка в эмулятор исполняемого файла, который требуется проэмулировать на предмет наличия вредоносного кода. Таким образом, образ №2 отличается от образа №1 тем, что в память уже загружен эмулируемый процесс. Следовательно, условие создания образа определяет также определяет различие между образами (с учетом информации о количестве проэмулированных инструкций, вызванных функций, изменения описателей ресурсов и т.д.). В дальнейшем выполнение новых условий приводит к созданию новых образов. Например, ветвление в коде является условием №3 и приводит к созданию образа №4, который соответствует состоянию эмулятора до выполнения условного перехода в коде. Условием №4 может являться срабатывание антивирусной сигнатуры, которая указывает на возможное использование приемов антиэмуляции, что приведет к созданию образа №5. В дальнейшем, если на этапе 207 эмуляция исполняемого файла будет завершена некорректно, то обход по древовидной структуре сохраненных образов эмулятора позволит загрузить образ состояния эмулятора, который предшествовал некорректному завершению процесса эмуляции. При обходе такого дерева в поисках образа в первую очередь спускаются до того образа, в котором записано состояние эмулятора, предшествовавшее некорректному завершению процесса эмуляции. В случае если процесс эмуляции вновь завершается некорректно, то возможна загрузка изменения образа состояния эмулятора уровнем выше (т.е. еще более ранняя версия состояния эмулятора) вплоть до того состояния, когда в эмулятор был загружен эмулируемый файл. При этом если условия создания образов включали, например, условный переход, то при загрузке образа на соответствующем условии, переход будет осуществлен в другую ветку кода. Примером изменения состояния эмулятора могут быть:

- Переход в другую ветку кода при условном переходе.

- Изменение статуса описателей ресурсов (например, файлов). В таком случае возможно принудительно не закрывать открытые файлы или соединения.

- Откат сделанных ранее изменений. Примером может служить очистка буфера передачи данных или изменение ветки реестра.

- Изменение значения выполненной функции. Например, если при выполнении в результате эмуляции функции она возвращала значение FALSE, то можно принудительно изменить значение на TRUE.

Стоит отметить, что хранить образы состояния эмулятора целесообразнее всего в оперативной памяти для ускорения процедур сохранения и восстановления загруженных образов. Размер образа может варьироваться от нескольких десятков мегабайт (загруженная ОС) до нескольких сотен мегабайт или даже гигабайт в зависимости от загруженных процессов. Для экономии оперативной памяти часть образов можно хранить на диске или же использовать разницу (diff) между образами, которая может быть минимальной, если условия создания образов выполняются достаточно часто во время эмуляции.

Фиг.4 иллюстрирует возможные образы состояния эмулятора в зависимости от загруженных процессов. Например, в качестве образа №1 можно принять загруженную ОС, а последующие образы содержат различные загруженные процессы, например, процессы Java, .NET, Explorer, Outlook и т.д. Образы могут содержать и определенные наборы запущенных процессов, что может потребоваться для успешной эмуляции определенных файлов, имеющих ряд зависимостей. Например, для эмуляции неизвестного файла потребуется процесс виртуальной машины Java, в который будет загружен вредоносный код (эксплойт) с дальнейшим использованием уязвимости (возможно, неизвестной), при этом для дальнейшего выполнения вредоносного функционала могут требоваться сетевые службы Windows.

Фиг.5 отображает работу системы настоящего изобретения. При необходимости эмуляции неизвестного файла 501 используется эмулятор 503, который загружает необходимый образ с помощью средства 502 загрузки образов в эмулятор. Средство 502 определяет необходимый образ в базе данных образов 504 по критериям, описанным в рамках Фиг.3. В то же время эмулятор 503 может отправлять запрос на создание образа в средство 505 создания образов на основании одного из условий необходимости создания образов (также рассмотрено выше). В частном случае реализации, средство 505 хранит древовидную структуру образов состояния эмулятора, где переходы от одних узлов дерева к другим основаны на указанных условиях. Сама база данных 504 хранится в оперативной памяти компьютера, что является наиболее предпочтительным вариантом реализации.

Использование системы, приведенной на Фиг.5, позволяет решать ряд задач:

- Ускорять загрузку состояния эмулятора при эмуляции исполняемых файлов, так как загрузка образа в предпочтительном варианте реализации является операцией копирования в оперативной памяти;

- Определять возможные коды ошибок при последующем выполнении приложения (например, при запуске инсталлятора);

- Обходить возможные приемы антиэмуляции с целью выявления вредоносного функционала.

Фиг.6 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 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, представленного на Фиг.6. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 50 и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях, внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключен к локальной сети 50 через сетевой адаптер или сетевой интерфейс 51. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключен к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.

В заключение следует отметить, что приведенные в описании сведения являются примерами, которые не ограничивают объем настоящего изобретения, определенного формулой.