Универсального выхода из этой ситуации не существует, но посредственных решений проблемы можно предложить сколько угодно. Чаще всего эмуляторы при открытии файла в текстовом режиме самостоятельно обрабатывают символы перевода строки, следуя UNIX-соглашению. Файл, открытый в двоичном режиме читается «как есть», поскольку невозможно различить действительный перевод строки от совпадения последовательности символов. К сожалению, многие приложения обрабатывают текстовые файлы, открывая их в бинарном режиме. Поэтому, лучше всего переносить файлы данных вручную, при необходимости заменяя символы переноса строки.
Точно так, в MS-DOS и UNIX не совпадают наименования устройств. Например, для подавления вывода сообщений на экран в MS-DOS используется конструкция “»nul” (“echo Это сообщение никогда не появится на экране»nul”), а в UNIX - “»/dev/null” (“echo Это сообщение никогда не появится на экране» /dev/null”). Другие примеры различий показаны в таблице 1
– Устройство Название в UNIX Название в MS-DOS
– Консоль /dev/tty Con
– Стандартный ввод /dev/stdin Con
– Стандартный вывод /dev/stdout Con
– Черная дыра /dev/null Nul
– Привод гибких дисков /dev/fd А: (B:)
– Параллельный порт /dev/lp Com
– Последовательный порт /dev/mod lpt
Таблица 1 Различия наименования устройств в UNIX и MS-DOS
Поэтому, любой эмулятор должен предоставлять собственную библиотеку функций для работы с файлами, имитирующую наличие указанных устройств. Это реализуется простым преобразованием имен и контролем доступа операций записи и чтения (например, в стандартный ввод нельзя записывать, хотя MS-DOS это позволяет, совмещая и ввод, и вывод в одном устройстве под названием ‘con’ - сокращение от console).
К сожалению, существуют и такие различия, сгладить которые невероятно трудно. Так, например, система UNIX чувствительна к регистру в именах файлов и допускает мирное сосуществование “myfile” и “MyFile” в одном каталоге. Кажется, единственный способ приучить к этому Windows, - реализовать собственную файловую систему, но существуют более простые, хотя и менее элегантные решения. Некоторые эмуляторы ассоциируют файлы с таблицами виртуальных имен, обрабатываемых по правилам UNIX. (Смотри рисунок 005.txt)
Создание эмулятором таблицы виртуальных имен, чувствительных к регистру
Намного хуже дело обстоит с поддержкой сырых гнезд (SOCK_RAW). Если говорить просто, сырые гнезда позволяют прикладной программе самостоятельно сформировать заголовок IP пакета, - действие редко используемое в нормальной жизни, но необходимое для множества атак.
Спецификация WINSOCK 2.x как будто бы подтверждает их наличие в Windows, но на самом деле, соответствующие функции реализованы неправильно и посылают подложный пакет, помещая пользовательский заголовок в область данных. Не то чтобы ситуация была полностью безнадежна, но написание собственных драйверов TCP/IP требует надлежащей квалификации разработчиков, и ни один из известных автору эмуляторов сырых гнезд не поддерживает.
К слову сказать, помимо гнезд семейства AF_INET, в UNIX существуют и гнезда используемые для межпроцессорного взаимодействия, не поддерживаемые WINSOCK, но реализуемые подавляющим большинством эмуляторов.
Рассмотрев теоретические различия между UNIX и Windows, перейдем к сравнению конкретных реализаций эмуляторов. Для этого возьмем двух ярких представителей, UWIN от компании AT amp;T (кто знает UNIX лучше AT amp;T?) и CYGWIN, поддерживаемый в рамках проекта GNU [83].
Логотип эмулятора UWIN
Для некоммерческого использования полноценную копию UWIN можно получить бесплатно, посетив сайт автора - http://www.research.att.com/sw/tools/uwin/. Установленный UWIN предоставляет следующие возможности: “UWIN has a set of popular shells like ksh (Kornshell) amp; tcsh (C shell) and more than 300 utilities like vi, ls, ps, grep, tail, uudecode/uuendecode, mailx, find, perl, awk, etc along with a vt100 terminal emulation. It also provides a Telnet server along with other inet daemons and utilities like telnet, ftp, rsh, rlogin, and their corresponding servers for Windows NT, enabling a user to remotely access the system over the network. Optional tools include the Apache Web-server and bind DNS server. [84]”
Врезка «Системные требования UWIN»*
· Software requirements Software requirements
· UWIN Base toolkit + UWIN SDK
· Microsoft Visual C/C++ 4.0 or higher or GNU C/C++ compiler
· Microsoft Windows NT 4.0 or higher (Workstation or Server) or
· Microsoft Windows 95/98
· Hardware requirements Hardware requirements
· Intel x86, Pentium, Pentium Pro and compatible systems
· 30-100MB of available hard-disk space
UWIN содержит множество популярных командных оболочек, свыше 300 необходимых для работы утилит и даже позволяет запускать Apache WEB сервер и DNS сервер. Администраторов Windows NT не может не порадовать наличие полноценного telnetd -демона (как известно в штатную поставку Windows NT не входит никаких средств удаленного управления компьютером) [85].
Рисунок 048 Демонстрация наличия telnet-сервера в эмуляторе UWIN
Разработчикам пригодится компилятор GNU C/C++ и отладчик gdb, или любой другой инструментарий - по выбору. Например, perl, awk, tcl… да всего не перечислишь! Кстати, в UWIN входит «обертка» (wrapper) для Microsoft Visual C++, дополняющая его возможностью обработки исходных текстов UNIX-приложений. Разумеется, откомпилированный текст можно отлаживать чем угодно, в том числе и Soft-Ice, не имеющим аналогов в среде UNIX.
Наконец, даже никого не собирающиеся атаковать пользователи, со временем обнаружат - пользоваться командными оболочками UNIX, намного удобнее, чем елозить мышью. Благо, UWIN позволяет запускать не только UNIX, но и Windows-приложения, умело обращаясь не только с дисками, но и с реестром.
Отныне ветви реестра будут представлены каталогами, а ключи - файлами. Корневой раздел реестра монтируется в каталог “/reg” На рисунке 049 показано, как вывести на экран содержимое ветви реестра “HKEY_CURRENT_USERNetworkPersistentH”. Но этим возможности UWIN не ограничиваются. В реестре становится возможным хранить и обрабатывать файлы, точь-в-точь как на обычном жестком диске!
Эмулятор UWIN позволяет обращаться с реестром Windows точно так, как с файлом
Выше был употреблен термин “монтируется” - UWIN эмулирует монтируемую файловую систему, то есть позволяет произвольным образом объединять в одну логическую структуру, файлы и каталоги физически расположенные на разных дисках и даже компьютерах. По умолчанию корневым каталогом назначается директория, в которую инсталлирован UWIN. Корень диска «С» становится каталогом “/C/”, и соответственно “/A/”, “/B/”, “/D/”, “/E” для остальных дисков (если они есть). Каталог Windows доступен как “/C/Windows”, так и через короткий псевдоним “/Win”. Сетевые компьютеры автоматически монтируются так же, как и в Windows, но с наклоном черты в обратную сторону, т.е. “\SERVERC” станет называться “//SERVER/C”. Вообще же узнать, как смонтирован тот или иной ресурс можно с помощью команды mount. Например, на компьютере автора результат ее работы выглядел так:
· C:Program FilesUWIN on / type FAT32 (ic,text,grpid,suid,rw)
· C:Program FilesMicrosoft Visual Studiovc98 on /msdev type FAT32 (ic,text,grpid,suid,rw)
· A: on /A type FAT (ic,text,grpid,suid,rw)
· C: on /C type FAT32 (ic,text,grpid,suid,rw)
· D: on /D type FAT32 (ic,text,grpid,suid,rw)
· E: on /E type FAT32 (ic,text,grpid,suid,rw)
· F: on /F type FAT32 (ic,text,grpid,suid,rw)
· //SERVER/C on /H type FAT ()
· /usr/bin on /bin type LOFS (ic,text,grpid,suid,rw)
· /usr/lib on /lib type LOFS (ic,text,grpid,suid,rw)
· /usr/etc on /etc type LOFS (ic,text,grpid,suid,rw)
· /usr/dev on /dev type LOFS (ic,text,grpid,suid,rw)
· /C/WINDOWS on /win type FAT32 (ic,text,grpid,suid,rw)
· /C/WINDOWS/SYSTEM on /sys type FAT32 (ic,text,grpid,suid,rw)
· /usr/proc on /proc type PROC (ic,text,grpid,suid,rw)
· /usr/reg on /reg type REG (ic,text,grpid,suid,noexec,rw)
Однако, монтируемая файловая система видна только из-под UWIN, а Windows-приложения даже и не подозревают о ней. Поэтому, попытка вызвать notepad для просмотра фала /win/readme.txt провалится, а правильный вариант должен выглядеть так: “/win/notepad C:\windows\readme.txt”. Дублирование косой черты обязательно, в противном случае Windows сообщит: “Не удается найти файл C:windowsreadme.txt” (такая ситуация показана на рисунке 050):
Рисунок 050 Демонстрация вызова приложений Windows из эмулятора UNIX
Так происходит потому, что в UNIX (и UWIN), косая черта “” зарезервирована за управляющими символами (например, “t” обозначает знак табуляции, а “n” - перенос строки), а когда требуется отобразить сам символ обратной черты, прибегают к его дублированию.
Каталог “/dev” предназначен для управления устройствами. Его содержимое может быть следующим:
· $ ls /dev
· clipboard ptyp0 ptyq7 tty06 tty29 ttypb
· fd ptyp1 ptyq8 tty07 tty30 ttypc
· fd0 ptyp2 ptyq9 tty08 tty31 ttypd
· fd1 ptyp3 ptyqa tty09 tty32 ttype
· lp ptyp4 ptyqb tty10 tty33 ttypf
· lp0 ptyp5 ptyqc tty11 tty34 ttyq0
· lp1 ptyp6 ptyqd tty12 tty35 ttyq1
· lp2 ptyp7 ptyqe tty13 tty36 ttyq2
· mod0 ptyp8 ptyqf tty14 tty37 ttyq3
· mod1 ptyp9 rmt0 tty15 tty38 ttyq4
· mod2 ptypa rmt0n tty16 tty39 ttyq5
· mod3 ptypb rmt1 tty17 tty40 ttyq6
· mod4 ptypc rmt1n tty18 ttyp0 ttyq7
· mod5 ptypd stderr tty19 ttyp1 ttyq8
· mod6 ptype stdin tty20 ttyp2 ttyq9
· mod7 ptypf stdout tty21 ttyp3 ttyqa
· mt0 ptyq0 tty tty22 ttyp4 ttyqb
· mt0n ptyq1 tty00 tty23 ttyp5 ttyqc
· mt1 ptyq2 tty01 tty24 ttyp6 ttyqd
· mt1n ptyq3 tty02 tty25 ttyp7 ttyqe
· null ptyq4 tty03 tty26 ttyp8 ttyqf
