Крис Касперский - ТЕХНИКА СЕТЕВЫХ АТАК

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

Разумеется, UWIN не единственное приложение в своем роде. Существует еще CYGWIN, NUTCRACKER и множество других аналогичных программ. Какую из них использовать - выбирать читателю, но в книге будут описаны лишь две - UWIN и CYGWIN. Для некоммерческого использования они бесплатны, остальные же требуют оплаты, зачастую превышающей стоимость фирменного диска UNIX и дополнительного винчестера!

Перед углублением в описание особенностей обоих программ полезно рассмотреть: в чем заключатся различия между Windows и UNIX, и какие существуют пути их преодоления. «С высоты птичьего полета» эти операционные системы практически идентичны друг другу, и если бы программисты не использовали особенностей реализации той или иной функции в переносе прикладных приложений никаких проблем не возникало [79].

Так, в UNIX каждый открытый файл ассоциирован с дескриптором, а Windows используют HANDLE [80]. В первом приближении одно идентично другому - это «магические» числа, интерпретировать которые может только операционная система, а для приложений они представляется «черными ящиками». Сказанное справедливо для Windows, но в UNIX [81]дескрипторы упорядочены и предсказуемы. Напротив, HANDLE представляют собой случайные 32-числа, поэтому программы, написанные с учетом особенностей представления дескрипторов UNIX, откажутся работать в Windows. Возможный выход из такой ситуации заключается в создании собственной таблицы обработчиков, идентичной для всех процессов и хранящей упорядоченный список дескрипторов (смотри рисунок 001.txt).

Причем, один и тот же дескриптор может ассоциироваться с несколькими HANDLE. Например, оба дескриптора консоли, одновременно открытой как на запись, так и на чтение должны управляться всего одним обработчиком. Это обстоятельство крайне важно, ибо в Windows не существует глобальной таблицы обработчиков общей для всех процессов [82]. Каждый процесс имеет собственную локальную таблицу, поэтому бессмысленно пытаться использовать HANDLE чужого процесса. Локализация манипуляторов значительно повышает надежность системы, но затрудняет межпроцессорные взаимодействия, и все UNIX приложения, не рассчитывающие на такой поворот событий, тут же откажут в работе. Поэтому, необходимо собрать все HANDLE в одну таблицу, общую для всех UNIX-процессов (смотри рисунок 002.txt).

Рисунок 002.txt (показаны локальные таблицы HANDLE для двух Windows-процессов, и их отображение в глобальную таблицу дескрипторов UNIX-эмулятора)

Намного более существенны различия реализаций процессов в UNIX и Windows. Поддержка многозадачности в UNIX реализована крайне убого (да не обидятся ее поклонники на это высказывание). Системный вызов exec, запуская новый процесс, «подминает» текущий, поэтому, до запуска exec обычно используется функция fork, расщепляющая один процесс на два - родительский и дочерний. Процесс-сын наследует все открытые файлы отца, сегмент данных и продолжает выполнение с той же самой точки, в которой завершился вызов fork. Отличие между ними заключается лишь в возвращаемом функцией fork значении. Родительский процесс получает идентификатор дочернего, а сам дочерний всегда ноль. Поэтому, код, поражающий новый процесс, в UNIX приложениях обычно выглядит так: “if (fork()-0) exec(“/bin/vi”,”/etc/passwd”,0);”.

В Windows все намного естественнее и элегантнее. Вызов CreateProcess действительно порождает новый процесс, не затирая текущий. При этом сохраняется возможность наследования всех обработчиков установкой флага bInheritHandles. Поэтому, функция CreateProcess практически эквивалентна последовательным вызовам fork + exec. Но аналога fork в Windows нет, как нет возможности расщепления процессов! По большому счету это просто не нужно современным программистам, но часто использовалось разработчиками UNIX-приложений.

Любой эмулятор UNIX должен уметь имитировать вызов fork, благо гибкая архитектура Windows это позволяет. Чаще всего создается приостановленный ( suspend ) процесс с той же самой стартовой информацией, что и текущий. До выполнения функции main() из родительского процесса в дочерний копируется сегмент данных, стек и дублируются все обработчики. В последнюю очередь модифицируется контекст процесса, хранящий значения регистров, в том числе и регистра указателя очередной выполняемой команды (в 386+ серии микропроцессоров он носит название EIP).

Гораздо проще имитировать exec, - достаточно вызвать CreateProcess и “прибить” текущий процесс, имитируя его замещение новым. Остается всего лишь переустановить идентификатор, сохраняя генеалогическую линию. Если этого не сделать, вновь порожденный процесс станет потомком процесса, вызвавшего exec, а в оригинальной системе UNIX функция.exec не создает дочернего процесса и сохраняет идентификатор текущего. Но идентификатор процесса выдается операционной системой и не может быть изменен по желанию приложения! Другими словами, если “Процесс 0” породил “Процесс 1” и запомнил его идентификатор, а “Процесс 1”, имитируя вызов exec, обратился к функции CreateProcess и вызвал exit для завершения своей работы, то “Процесс 0” будет по-прежнему ссылаться на уже несуществующий “Процесс 1”, ничего не зная о порожденном “Процессе 2”, обладающего иным идентификатором.

Ситуация разрешается созданием собственной таблицы идентификаторов эмулятором UNIX. Родительский процесс в качестве идентификатора получает индекс ячейки такой таблицы, содержащей настоящий идентификатор дочернего процесса. В результате появляется возможность «подменить» идентификатор «Процесса 1» на «Процесс 2» незаметно для родительского процесса. (Смотри рисунок 003.txt)

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