Восстановление данных. Практическое руководство

Касперски Крис

Что же касается портов ввода-вывода, то, например, дизассемблированный текст функции

READ_PORT_UCHAR

, читающий из данного порта беззнаковый байт, выглядит, как показано в листинге 8.1.

Листинг 8.1. Дизассемблированный листинг функции

READ_PORT_UCHAR

, выдернутой из HAL

.text:80015A2C

.text:80015А2С public READ_PORT_UCHAR

.text:80015A2C READ_PORT_UCHAR proc near

; CODE XREF: HalGetEnvironmentVariable+2C↑p

.text:80015A2C ; HalSetEnvironmentVariable+3D↑p

.text:80015A2C

.text:80015A2C arg_0 = dword ptr 4

.text:80015A2C

.text:80015A2C xor eax, eax

.text:80015A2E mov edx, [esp+arg_0]

.text:80015A32 in al, dx

.text:80015A33 retn 4

.text:80015A33 READ_PORT_UCHAR endp

Иначе

говоря, если заставить NTOSKRNL.EXE работать в чужеродной среде Linux или BSD, мы получим возможность запускать любые драйверы Windows NT без какой-либо доработки их двоичного кода. Это не только упрощает задачу переноса, но и снимает проблему авторских прав. Любой обладатель лицензионной копии Windows (или другой программы) вправе вызывать готовый драйвер откуда угодно без каких бы то ни было разрешений и без выплаты дополнительного вознаграждения, но вот модифицировать двоичный код ему позволят едва ли.

Но мы ведь и не собираемся ничего модифицировать! Мы берем готовый NTOSKRNL.EXE. Работы предстоит не так уж и много. Достаточно просто спроецировать его по адресам, указанным в заголовке РЕ-файла (a NTOSKRNL.EXE это обычный РЕ-файл), и разобраться с таблицей экспорта, используемой драйверами. Короче говоря, мы должны реализовать свой собственный загрузчик РЕ и включить его в загружаемый модуль ядра или в само ядро. Чтобы не мучиться, можно взять готовый загрузчик Wine (Windows Emulator).

Взаимодействие NTOSKRNL.EXE с ядром Linux/BSD будет происходить через код, эмулирующий HAL. Этот код мы будем должны написать сами, однако ничего сложного в этом нет, и объем работы предстоит минимальный, поскольку HAL содержит совсем немного простых функций. Сложнее подружить диспетчер системных вызовов с внешним миром, т.е. с миром Linux/BSD. Основная проблема в том, что интерфейс диспетчера системных вызовов не документирован, и к тому же подвержен постоянным изменениям. В Windows 2000 он один, в Windows XP он уже другой, а потом Microsoft вновь внесет недокументированные изменения, и весь наш труд пойдет насмарку. Поэтому приходится хитрить и тащить за собой не только NTOSKRNL.EXE, но еще и NTDLL.DLL. Некоторые могут спросить: а зачем? Какое отношение NTDLL.DLL имеет к драйверам и ядру? Драйверы его не вызывают, да и сам NTDLL.DLL представляет собой всего лишь набор переходников к NTOSKRNL.EXE.

Дело в том, что по традиции интерфейс NTDLL.DLL худо-бедно документирован. Кроме того, он остается практически неизменным уже на протяжении многих лет, поэтому его смело можно брать за основу. После этого остается "всего лишь" связать NTDLL.DLL с миром Linux/BSD, т.е. написать транслятор запросов к драйверам. Это не так-то просто сделать, поскольку писать придется достаточно много, и работа отнимет не один день, и даже не одну неделю. С учетом отладки потребуется как минимум месяц. Но работа стоит того!

В результате в Linux/BSD наладится нормальная работа с NTFS и некоторыми другими драйверами

ввода-вывода. С видеокартами, правда, все значительно сложнее, поскольку они, как и следует из рис. 8.3, взаимодействуют отнюдь не с диспетчером ввода-вывода (который находятся внутри NTOSKRNL.EXE), а с подсистемой Win32. В Windows 2000 она реализована в файле win2k.sys. Как обстоят дела в других системах — точно не знаю, да это и не важно. Драйвер win2k.sys — лишь малая часть того, что ему нужно для работы, и просто так перетащить его в Linux/BSD не получится. За ним неизбежно потянется все его окружение, и написать столько "оберток" будет практически нереально. То есть теоретически-то, конечно, реально, но сколько это потребует времени и сил? Переписать видеодрайвер гораздо проще, не говоря уже о том, что в этом случае он будет намного более производителен. Кстати говоря, компании nVIDIA (рис. 8.4) и ATI (рис. 8.5) в последнее время наладили выпуск драйверов Linux/BSD под наиболее популярные чипсеты, так что проблема снимается сама собой.

Рис. 8.4. Видеодрайверы для Linux x86 и x86_64 от nVIDIA

Рис. 8.5. Видеодрайверы для Linux x86, x86_64, IA64, FreeBSD x86 и Solaris x86/x64 от ATI

Пример реализации

Конкретные случаи переноса драйверов из мира Windows в Linux/BSD мне неизвестны, однако под MS-DOS такие случаи имеются. Речь идет о проекте Марка Руссиновича "NTFS for MS-DOS. Бесплатная версия (http://www.sysinternals.com/Utilities/NtfsDosProfessional.html) может только читать. Специальный мастер установки просит указать путь к системному каталогу Windows и создает две дискеты. Содержимое этих дискет показано в листингах 8.2 и 8.3.

Листинг 8.2. Содержимое первой дискеты NTFS for MS-DOS

30.10.2005 19:01 904 414 NTOSKRNL.gz

11.02.2002 09:39 89 472 ntfspro.exe

30.10.2005 19:00 314 665 NTFS.gz

30.10.2005 19:01 1 403 C_866.gz

4 файлов 1 309 954 байт

0 папок 146 944 байт свободно

Листинг 8.3. Содержимое второй дискеты NTFS for MS-DOS

30.10.2005 19:03 212 681 AUTOCHK.gz

30.10.2005 19:04 219 099 NTDLL.gz

30.10.2005 19:04 1 633 C_437.gz

30.10.2005 19:04 1 467 C_1252.gz

30.10.2005 19:04 746 L_INTL.gz

08.02.2002 10:45 56 748 ntfschk.exe

6 файлов 492 374 байт

0 папок 964 096 байт свободно

Начнем с первой дискеты. Она обычно бывает системной, поскольку NTFS для MS-DOS работает только из-под "черного экрана", однако для наглядности все системные файлы удалены. Здесь находится только один исполняемый файл ntfspro.exe, представляющий собой транслятор запросов, слинкованный с расширением защищенного режима WDOSX 0.96 DOS extender от Michael Tippach