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

Автор книги: Крис Касперски

сообщить о нарушении

Текущая страница: 15 (всего у книги 26 страниц)

Полезные советы

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

□ Переместите $MFT подальше от начала раздела. Первые секторы раздела – это, как показала практика, самое небезопасное место (рис. 7.12). Во-первых, сюда стремятся попасть практически все вирусы. Невозможность прямого доступа к диску под управлением операционных систем из семейства Windows NT – это всего лишь миф. Если вам требуется аргументированное опровержение этого мифа, прочтите описание функции CreateFile и инструкцию к драйверу ASPI32. Во-вторых, некоторые утилиты (и в частности, Ahead Nero) при некоторых обстоятельствах путают жесткий диск с оптическим накопителем, записывая образ не "туда". Это значит, что в первых ~700 Мбайт физического диска (обратите внимание – физического диска, а не логического тома) не должно содержаться ничего ценного. В-третьих, если вы вдруг запустите WipeDisk или любую другую затирающую утилиту, первым погибнет именно $MFT, без которого весь дисковый том – это просто груда мусора. Можно привести и множество других, самых различных причин! Поэтому просто переместите $MFT, тем более, что это совсем несложно. Достаточно взять любой дефрагментатор, распространяющийся в исходных текстах (энтузиасты! ау! присоединяйтесь к проекту http://sourceforge.net/projects/opendefrag/), и слегка доработать его (рис. 7.13). Разумеется, резервная копия при этом всегда должна находиться под рукой.

Рис. 7.12. Нормальный дисковый том (MFT расположена в начале раздела)

Рис. 7.13. "Иммунизированный" дисковый том (MFT расположена в середине)

□ Не допускайте фрагментации файла $MFT! Не создавайте на диске огромного количества мелких файлов и не заполняйте его более чем на 90%. Стандартный дефрагментатор, входящий в комплект штатной поставки Windows 2000/XP, не позволяет дефрагментировать $MFT. Для этой цели приходится прибегать к сторонним средствам, лучшим из которых, на мой взгляд, является О&О Defrag Pro от одноименной компании (http://www.oo-software.com). Это – действительно профессиональный дефрагментатор, к тому же поддерживающий командную строку.

□ Периодически создавайте резервную копию файловой записи $MFT. Для этого достаточно сохранить один-единственный сектор – первый сектор MFT, номер которого содержится в загрузочном секторе. Только не забывайте его периодически обновлять, ведь при добавлении новых файлов и каталогов MFT планомерно расширяется, и старые списки отрезков становятся все менее и менее актуальны.

Глава 8
Восстановление данных под Linux/BSD

Главный недостаток UNIX-подобных систем – отсутствие нормальных драйверов под множество разнообразного оборудования, с которым Windows справляется без проблем. Несколько лет назад ситуация с драйверами под Linux и BSD была просто катастрофической. Поддерживалось лишь некоторое оборудование, и железо для UNIX-машин приходилось закупать отдельно. Тогда операционная система Linux еще не вышла из стадии "конструктора" для хакеров, a BSD в основном использовалась на серверах, все оборудование которых сводилось к сетевой карте и контроллеру SCSI. Поэтому основной массе пользователей жаловаться не приходилось.

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

Часто приходится слышать о большой армии энтузиастов, дизассемблирующих драйверы Windows и переписывающих их под Linux или BSD. Но, к сожалению, этих энтузиастов не так уж и много. Разнотипного оборудования гораздо больше, тем более что сплошь и рядом приходится сталкиваться с ситуацией, когда на компьютере энтузиаста драйвер работает, а на компьютере пользователя – нет, хотя аппаратные конфигурации этих компьютеров практически идентичны. Драйвер мало написать, его еще нужно отладить, протестировать на большом количестве конфигураций и сопровождать, иначе это будет не драйвер, а просто игрушка. Все это требует затрат времени, поэтому если драйвер создается не для коммерческой выгоды, а для личных нужд, то его надежность и совместимость оставляют желать лучшего.

Составители дистрибутивов проделывают огромную работу, собирая различные драйверы и включая их в свой комплект. Качество тестирования таких драйверов очень невысоко, и даже если в списке поддерживаемого оборудования значится конкретное устройство, никаких гарантий того, что оно заработает, у нас нет. Может быть, подойдет драйвер от другой модели, а может быть, и ничего не подойдет вообще! А ведь без драйверов сидеть скверно.

Виртуальные машины

Прежде чем ставить Linux/BSD задумайтесь – а зачем вам, собственно, все это нужно? Если просто хотите протестировать альтернативную систему, освоить средства разработки или компилировать исходные тексты, то наилучшим выбором будет виртуальная машина, например, VMWare (рис. 8.1). Fedora Core на ней, конечно, будет работать очень медленно (например, на P-III 733 работать вообще невозможно), но Debian с KDE будет "пахать" вполне нормально. Хочешь – разрабатывай программы, хочешь – читай руководства (man pages). Еще и в игры типа Star Wars можно поиграть. Никаких драйверов сверх того, что есть в любом "правильном" дистрибутиве, для этого не потребуется. Большинство разработчиков именно так и поступают. Как ни крути, а любой уважающий себя UNIX-программист вынужден держать на компьютере десяток различных операционных систем, чтобы тестировать свои программы на совместимость. На "живом" компьютере переключения между ними происходят только путем перезагрузки, что не слишком удобно. Виртуальные машины при этом можно переключать в любом порядке и с любой скоростью (главное – это иметь как можно больше памяти!).

Рис. 8.1. Виртуальная машина Linux, работающая в среде Windows

Можно поступить и наоборот. Установить Linux/BSD как базовую систему, a Windows водрузить на виртуальную машину (рис. 8.2). Так как VMWare дает прямой доступ к портам COM, LPT и USB, то подключение сканера, принтера или цифровой камеры к вашей машине перестанет быть проблемой. С этим оборудованием будет работать Windows! Базовая машина UNIX в этом случае получает в свое распоряжение все системные ресурсы, и падения производительности уже не происходит, но появляются другие проблемы. Приложения Windows (например, игры) будут либо сильно тормозить, либо откажутся запускаться совсем, к тому же со всеми остальными типами устройств, например, интегрированной платой WLAN или видеокартой, Windows работать не сможет. А все потому, что VMWare представляет собой "черный ящик", отгороженный от базовой операционной системы толстой стеной эмулятора. Вот если бы существовала возможность предоставить виртуальной машине полный доступ ко всему физическому оборудованию, вот тогда бы... Готовьтесь! Именно такой способ мы и собираемся описать!

Рис. 8.2. Виртуальная машина Windows в среде Linux

Перенос драйверов Windows в Linux/BSD

Начнем с простого, но до сих пор никем не решенного вопроса. Разумеется, на самом-то деле вопрос этот, конечно, уже давно решен, но совсем не так, как следовало бы. Известно, что поддержка разделов NTFS в Linux/BSD представляет собой сплошную проблему. Драйверы, способные осуществлять запись на разделы NTFS, появились совсем недавно, да и то лишь затем, чтобы покрасоваться на выставках. Для реальной работы они непригодны, потому что работают не очень стабильно и страдают множеством ограничений. Сжатые файлы, транзакции и множество других возможностей все еще не поддерживаются. Кроме того, NTFS не стоит на месте и хоть и медленно, но совершенствуется. Можно ли, хотя бы теоретически, написать стопроцентно совместимый драйвер, корректно работающий со всеми новыми версиями NTFS без участия программиста? Этот вопрос совсем не так глуп, как кажется. Для чего программистам тратить силы и время на собственный драйвер, когда под рукой есть уже готовый – NTFS.SYS. Если заставить его заработать под Linux, то все проблемы решатся сами собой.

Несмотря на то, что на уровне ядра между Linux/BSD и Windows существует большое количество различий, но и кое-что общее между ними все-таки имеется. И Windows, и Linux, и BSD работают на процессорах семейства x86 в защищенном режиме, используют страничную организацию виртуальной памяти и, наконец, все они взаимодействуют с оборудованием в строго установленном порядке (через иерархию физических и виртуальных шин). Высокоуровневые драйверы, такие, например, как NTFS.SYS, вообще не работают с оборудованием напрямую и содержат минимум системно-зависимого кода. Почему же тогда драйвер от одной системы не работает в другой? А потому, что интерфейс между ОС и драйвером в каждом случае различен, а также потому, что драйвер использует библиотеку функций, экспортируемых системой, и эти функции у каждой системы свои.

Перенести драйвер Windows в Linux/BSD вполне реально! Для этого даже не потребуется его исходный код. Достаточно лишь написать тонкий и несложный "переходник" между драйвером и операционной системой, принимающий запросы и транслирующий их по всем правилами "этикета", а также перенести библиотеку функций, необходимых драйверу для работы. Конечно, для этого необходимо уметь программировать! Для простых пользователей такой рецепт совершенно не годится, но тут уж ничего не поделаешь. Тем не менее, перенести готовый драйвер намного проще, чем переписать его с нуля. Нам не потребуется проводить кропотливую работу по дизассемблированию оригинального кода, заменяющую собой поиск технической документации (которая либо совсем отсутствует, либо отдается только под подписку о неразглашении, зачастую запрещающую открытое распространение исходных текстов). Наконец, при выходе новых версий драйвера Windows процедура его переноса в Linux/BSD проста до тривиальности – достаточно скопировать новый файл поверх старого файла. Однако все это лишь сухая теория. Перейдем к деталям.

Модель ядра Windows NT и всех производных от нее операционных систем (включая Windows 2000, XP, 2003, Longhorn) достаточно проста (рис. 8.3). С "внешним" миром ядро связывает диспетчер системных сервисов, "подключенный" к NTDLL.DLL, которая находится уже за "скорлупой" ядра и исполняется в режиме пользователя. Диспетчер системных сервисов, реализованный в NTOSKRNL.EXE, опирается на вызываемые интерфейсы ядра, часть которых реализована в самом файле NTOSKRNL.EXE, а часть – во внешних драйверах, к числу которых, в частности, принадлежит диспетчер питания. Определенный класс драйверов, называемый драйверами устройств и файловой системы, находится в своеобразной "скорлупе" и взаимодействует с диспетчером системных вызовов через диспетчер ввода-вывода, реализованный опять-таки в NTOSKRNL.EXE!

Рис. 8.3. Архитектура систем из семейства Windows NT

Ядро, на котором, как на фундаменте, держатся все вышеупомянутые компоненты, представляет собой просто совокупность низкоуровневых функций, сосредоточенных в NTOSKRNL.EXE. Ниже находится только уровень аппаратных абстракций (Hardware Abstraction Level, HAL). Когда-то у Microsoft была идея разделить ядро на системно-зависимую и системно-независимую части, чтобы упростить перенос Windows на другие платформы. Однако уже во времена Windows NT 4 все перемешалось, и большая часть системно-зависимых функций попала в NTOSKRNL.EXE. На сегодняшний день ситуация такова, что HAL медленно, но неотвратимо умирает. В нем осталось небольшое количество действительно низкоуровневых функций, непосредственно взаимодействующих с оборудованием, например, с портами и с DMA. Но в ядре Linux/BSD есть свои функции для работы с DMA, так что тащить за собой HAL нам совершенно необязательно, тем более что драйверы взаимодействуют с DMA не напрямую, а через диспетчер Plug and Play, который находится в NTOSKRNL.EXE.

Что же касается портов ввода-вывода, то, например, дизассемблированный текст функции 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

NTFS.gz – это "родной" драйвер NTFS.SYS, извлеченный из системного каталога Windows, и для экономии места упакованный архиватором gzip. Для распаковки нам потребуется либо Linux, либо pkzip для Windows/MS-DOS. Сравнив его с оригинальным файлом драйвера, мы не найдем никаких изменений! NTOSKRNL.gz – это ядро системы (NTOSKRNL.EXE), точно таким же образом извлеченное и упакованное. Никаких изменений в нем нет.

На другой дискете находятся файлы NTDLL.gz (о происхождении которого догадаться нетрудно) и ntfschk.exe. Последний представляет собой полностью переписанный вариант штатной утилиты chkdsk.exe, поскольку, чтобы заставить консольное приложение заработать в MS-DOS, пришлось бы эмулировать еще множество функций, что в планы Руссиновича, очевидно, не входило.

Примечание

Тем не менее, легендарный хакер Юрий Харон все-таки создал расширитель, способный запускать Windows-приложения из-под голого DOS, без обращения к Windows вообще! Все умещается на одну дискетку. Сам расширитель можно скачать с http://www.doswin32.com:8080/index_en.html. Для некоммерческого применения он бесплатен.

Еще на дискетах содержатся файлы C_866.gz, AUTOCHK.gz, C_437.gz, C_1252.gz, L_INTL.gz, содержащие языковые страницы и прочую служебную мишуру, без которой можно в принципе и обойтись.

Ядро проекта NTFS для MS-DOS составляют три файла: NTOSKRNL.EXE, NTDLL.DLL и NTFS.SYS, которые помещаются в своеобразную "скорлупу" файла NTFSPRO.EXE, переводящего процессор в защищенный режим и транслирующего запросы MS-DOS на "язык", понятный NTFS.SYS, и наоборот. Как видите, это работает. Разумеется, Linux/BSD – это совсем не чистая MS-DOS. Ядро по-своему распределяет прерывания и другие системные ресурсы, поэтому при написании "скорлупы-оболочки" возникает множество технических проблем, но все они решаемы. Пример аналогичного решения можно найти в другом проекте Марка Руссиновича – NTFS для Windows 9x. Здесь также используется "скорлупа", создающая адекватное окружение для NTOSKRNL.EXE и транслятор запросов. Однако в данном случае эта "обертка" уже работает совсем не в голой MS-DOS, а в агрессивной Windows 9x, которая отличается от NT ничуть не меньше, чем Linux/BSD.

Так что, написать драйверную "скорлупу" для Linux/BSD вполне реально, и ничего фантастичного в этом нет. Ее достаточно создать лишь однажды, после чего в ней будет можно запускать различные драйверы. Почему бы нам, хакерам, не скооперироваться и не заняться этим? Например, создать новый проект на http://www.sourceforge.net, набрать группу и оттянуться по полной программе.