nt-kernel-hack

хак ядра NT

крис касперски ака мыщъх, no-emai

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

Прежде чем вторгаться в ядро, попробуем разобраться зачем это вообще нужно и нельзя ли обойтись «демократичным» прикладным уровнем с которым намного меньше конфликтов и прочих проблем?

Черви, вирусы и rootkit'ы стремятся в ядро затем, чтобы дотянуться до функций, работающих с памятью, файлами, сетевыми соединениями и процессами на самом низком уровне, перехватив которые, можно надежно замаскировать свое присутствие в системе. Аналогичными приемами пользуются протекторы исполняемых файлов типа Themida (бывший eXtremeProtector), защиты лазерных дисков от копирования (Star-Force, SONY и т. д.) Методика та же самая, что и в Stealth-вирусах 10-15 летней давности, только программные реализации другие. Кстати говоря, после громкого скандала и судебного разбирательства, SONY признала свою неправоту, отозвав свыше 30 наименований защищенных дисков. А ребята из Star-Force продолжают использовать вирусные методики и до сих пор, регулярно роняя пользовательские системы в голубой экран и отказываясь работать с новыми версиями Windows без обновления самой Star-Force.

Брандмауэры, файловые мониторы, антивирусы и прочие сторожа перехватывают ядерные функции, контролируя и пресекая всякую несанкционированную деятельность. Вообще-то, для брандмауэров предусмотрены специальные «затычки» типа «Filter-HookDriver» (Драйвер Фильтра-Ловушки) или Pseudo-Intermediate NDISDriver (псеводо-промежуточным NDIS драйвер), однако, все они, в силу стандартности своих интерфейсов, легко дезактивируются зловредными программами и надежность решений такого типа крайне невелика — одна лишь видимость защиты, а в действительности — сплошная дыра. Противостоять же грамотно выполненному перехвату ядерных функций очень-очень сложно, особенно, если перехватчик активно сопротивляется своему снятию.

Кроме того, в последних ядрах Windows появилось множество нехороших защит. Достаточно упомянуть систему активации и связанную с ней ядерную функцию NtLockProductActivationKeys, реализованную в системном вызове 065h в случае Windows XP или 6Ah в случае Windows Server 2003 (перечень системных вызовов в разных версиях Widnwos можно найти на сайте MetaExploitProject: http:www.metasploit.com/users/opcode/syscalls.html). А демонстрационные версии Windows, работающие, скажем, всего лишь 180 дней? А цифровая подпись драйверов? Кстати, в Longhorn (кодовое название системы, от упоминания официальной торговой марки которой меня сразу же блевать тянет) обещает обеспечить гораздо более радикальные изменения — никакой программный код не сможет войти в режим ядра (даже с правами администратора!), если только он не заверен цифровой подписью от единственного криптопровайдера VeriSign, начальный сертификат которого стоит 500$, при этом сертификаты выдаются только фирмам, зарегистрированным на территории США. Бедные разработчики драйверов! Вирусы, черви и прочая живность все равно пробьет к ядру прямой туннель (ну невозможно запретить захват нулевого кольца в системе изначально спроектированной без расчета на такие драконические запреты!), а вот легальным разработчикам придется либо выкладывать мешки с долларами на алтарь Microsoft, либо… пользоваться разными хакерскими трюками (как вариант, драйвер можно подписать «отладочной» подписью, входящей в состав DDK, однако, это несерьезно, несолидно и вообще в любой момент Microsoft может потребовать грузить такие драйвера только при нажатии F8 на стадии загрузки). Наконец, иногда хочется слегка усовершенствовать ядро, например, поменяв скучный загрузочный логотип на что-нибудь свое (например, сексапильную красотку или мрачный готический собор). ===== методы модификации ядра ===== Перехват системных функций, взлом защитных механизмов, перезапись логотипа — все эти действия требуют модификации ядра, сосредоточенного в файле ntoskrnl.exe. Модифицировать ядро можно как на диске (off-linepatch), так и в памяти (on-linepatch). Каждый способ имеет свои достоинства и недостатки, поэтому опытный хакер должен в равной мере владеть и тем, и другим. On-linepatch возможен только из драйвера или из прикладного режима через псевдоустройство \Device\PhysicalMemory, которое вплоть до Windows 2003 Server SP1 было доступно администратору, а после — закрыто даже для пользователя типа «system» (см. www.microsoft.com/technet/prodtechnol/windowsserver2003/library/BookofSP1/e0f862a3-cf16-4a48-bea5-f2004d12ce35.mspx, там будет заметка под именем «ChangestoFunctionalityinMicrosoftWindowsServer 2003 ServicePack 1 Device\PhysicalMemoryObject»). Драйвера (и тем более прикладные программы!) грузятся после ядра и грузятся самим ядром, которое их может вообще не грузить, если отсутствует цифровая подпись или ядру что-то «не нравится». Кроме того, любой успешно загруженный драйвер может заблокировать загрузку всех последующих или помешать им осуществить перехват системных функций, равно как и любую другую намеченную ими операцию. В борьбе с малварью и антивирусными сторожами очередность загрузки становится очень актуальной, но ни у одной из сторон нет 100% гарантии того, что ее драйвер загрузиться первым. К тому же, если ядро сообщает о завершении испытательного строка или отправляет систему в reboot еще до загрузки любых драйверов (что практиковалось в ранних версиях NT), то никакой on-linepatch тут не поможет! Кстати говоря, факт вмешательства в ядро легко обнаруживается тривиальным сравнением образа ntoskrnl.exe с дисковым файлом. Дезактивация перехвата осуществляется восстановлением «испорченных» байт, позаимствованных из оригинала. И хотя перехватчик, желающий остаться незамеченным, может (и должен!) отслеживать все обращения к ntoskrnl.exe – многие разработчики об этом забывают… Off-linepatchправит ядро (и, при необходимости, другие файлы) еще до его загрузки в память, что придает исправлениям этого типа наивысшей приоритет. Полномочия off-line патчера практически ничем не ограничены и для модификации ядра всего лишь требуется иметь права администратора на локальной машине. Доступ к файлу системой _не_ блокируется (!), а изменения вступают в силу сразу же после перезагрузки, которую с администраторскими правами устроить очень легко, хоть и не всегда удобно. В тех случаях, когда перезагрузка неуместна или нежелательна прибегают к on-linepatch'у с динамической загрузкой драйвера. Естественно, правка ntoskrnl.exe встречает сопротивление со стороны SFC, но эту проблему можно решить даже не отключая SFC (и чуть позже мы покажем как). Хуже другое — если несколько программ начинают править ядро, то образуется такая мешанина, что система впадает в синий экран или начинает вести себя совершенно неадекватно. Так же необходимо позаботиться о том, чтобы установка новых пакетов обновления (т. е. ServicePack'ов) не конфликтовала с хакнутым ядром. В общем, здесь есть о чем поговорить! ==== on-line patch ==== Даже находясь в нулевом кольце непосредственно модифицировать память, принадлежащую ядру нельзя. Дело в том, что все драйвера выполняются в едином адресном пространстве, общим с ядром, и без защиты от непредумышленной записи, система постоянно страдала бы от некорректно работающий драйверов, спроектированных непонятно кем. Как и любую другую защиту от непреднамеренно доступа, запрет на модификацию ядерной памяти можно отключить. Существует по меньше мере два документированных способа сделать это — статический и динамический. Статическоеотключение защиты сводится к созданию параметра EnforceWriteProtection типа REG_DWORD со значением 0h в следующем разделе системного реестра HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\MemoryManagement\ (cм. рис. 1), после чего ядро может модифицировать любой драйвер (но не прикладная программа!). Основной недостаток этого способа в том, что некоторые сторожа следят за этой веткой и стоит только тронуть ее, как они поднимают дикий визг, а то и просто молчаливо удаляют EnforceWriteProtection, возвращая защиту назад. С другой стороны, некоторые честные программы (например, тот же soft-ice, именно так и работают), поэтому слишком ретивые сторожа рискуют отправится в мусорную корзину, где им самое место. Правда, подавляющее большинство нормальных людей с soft-ice не работают и статическое отключение защиты им ни к чему. Да и не безопасно в плане стабильности системы это — оставлять ее незащищенной. Рисунок 1 статическое отключение защиты памяти ядра через реестр Динамическое отключение защиты осуществляется сбросом WP-бита в управляющем регистре CR0, который так и расшифровывается Write Protection. Соответственно, повторная установка бита обратно включает защиту. За этими махинациям не следят никакие известные мыщъху сторожа, их можно использовать во всех версиях Windows, включая еще не появившиеся на свет. Ниже приведен код псевдодрайвера (см. листинг 1), временно отключающего защиту памяти ядра от записи, а затем включающий ее назад. «Псевдо-» потому что настоящие драйвера (в подлинном смысле этого слова) используется для управления реальными (или виртуальными) устройствами, а нам драйвер понадобился только для того, чтобы дорваться до нулевого кольца, поэтому, мы используем одну лишь процедуру DriverEntry, отрабатывающую на стадии инициализации и тут же возвращаем STATUS_DEVICE_CONFIGURATION_ERROR, сообщая о фиктивной ошибке, заставляющую систему выгрузить драйвер, чтобы он понапрасну не болтался в памяти. Загрузить же драйвер можно либо обычным путем (через реестр), либо через динамический загрузчик Свена Шрайбера, прилагаемый к его книге «Недокументированные возможности Windows 2000» (сам загрузчик можно найти на WASM'е) .386 .model flat, stdcall .code DriverEntry proc moveax, cr0; грузим управляющий регистр cr0 в регистр eax mov ebx, eax; сохраняем бит WP в регистре ebx andeax, 0FFFEFFFFh; сбрасываем бит WP, запрещающий запись movcr0, eax; обновляем управляющий регистр cr0 ; # теперь защита отключена! ; # делаем все, что задумали сделать ; # модифицируя память ядра по своему усмотрению movcr0, ebx; восстанавливаембит WP ; # защита снова включена! mov eax, 0C0000182h; STATUS_DEVICE_CONFIGURATION_ERROR ret DriverEntry endp Листинг 1 код псевдодрайвера krnlWR.asm, временно отключающего защиту ядра от модификации, а затем включающего ее обратно Для компиляции драйвера потребуется DDK. Во время Windows 2000 он раздавался бесплатно всем желающим, но затем Microsoft сменила политику и теперь его могут получить только подписчики MSDN или почетные погонщики ослов. На самом деле все не так уж и печально. И полноценный DDK (вместе с частью SDK) входит теперь в объединенный пакет Kernel-Mode Driver Framework, который пока еще распространяется бесплатно, так что спешите качать: http://www.microsoft.com/whdc/driver/wdf/KMDF_pkg.mspx (см. рис. 2). Рисунок 2 бесплатно раздаваемый Kernel-ModeDriverFramework в состав которого входит DDK Сама компиляция осуществляется следующими ключами командной строки (см. листинг 2): ml /nologo /c /coff krnlWR.asm link /driver /base:0x10000 /align:32 /out:krnlWR.sys /subsystem:native krnlWR.obj Листинг 2 компиляция псевдодрайвера Модифицируя код или данные ядра, необходимо быть на 100% уверенным, что в данный момент времени их не использует никакой другой поток. Невыполнение этого условия приводит к непредсказуемому поведению системы. В лучшем случае – к голубому экрану, в худшем — к потери всего дискового тома (особенно, если мы вмешиваемся в файловые операции). Проблема возникает как на многопроцессорных, так и на однопроцессорных системах без поддержки HyperHeading, причем универсальных путей выхода из ситуации не существует. Каждый случай требует индивидуального подхода, описание которого тянет на целую статью, а поэтому здесь не рассматривается. Анализ исходных текстов (или драйверов) великих гуру далеко не всегда идет на пользу начинающим хакерам. На то они и гуру, чтобы знать, какими трюками когда можно пользоваться, а когда нет. Начинающие же обычно запоминают лишь сам трюк, а о границах его применимости зачастую даже не догадываются. В частности, в ранних версиях свой утилиты DbgView Марк Руссинович вставлял в начало ядерной функции DbgPring команду перехода на свой обработчик (см. листинг 3). .text:00010646 B8 D4 0A 01+moveax, offset loc_10AD4; jmp:DbgPrint .text:0001064B 8B 40 02moveax, [eax+2]; операнд jmp:[DbgPrint] .text:0001064E A3 A8 0B 01+mov_pDbgPrn, eax .text:00010653 8B 08movecx, [eax]; DbgPrint .text:00010655 89 0D A8 0B+mov_pDbgPrn, ecx .text:0001065B 8A 41 01moval, [ecx+1]; второйбайт DbgPrint .text:0001065E 3C 8Dcmpal, 8Dh; PUSH EBP/MOV EBP,ESP .text:00010660 75 04jnzshort loc_10666 Листинг 3 перехват отладочного вывода, осуществляемый «врезкой» jump'а поверх пролога системной функции Поскольку, функция DbgPrint не относится к числу интенсивно вызываемых, то вероятность, что какой-то поток вызовет ее одновременно с установкой перехватчика, достаточно невелика и все «как бы» работает. Однако, если один или несколько драйверов начнут злоупотреблять отладочным выводом, вероятность краха системы значительно возрастет, поэтому в последующих версиях Руссинович отказался от небезопасного способа перехвата и перешел на модификацию таблицы экспорта ntoskrnl.exe. Новичкам, похитившим этот примем и попытавшихся употребить его для перехвата функций ввода/вывода пришлось намного хуже и голубые экраны выпрыгивали только так! ==== off-linepatch ==== Кромсать ядро статическим способом очень просто. Открываем файл ntoskrnl.exe функций CreateFile, а затем действуем через ReadFile/WriteFile. Проблема синхронизации потоков отпадает сама собой, поскольку правка осуществляется еще до загрузки образа в память, однако, техника перехвата от этого ничуть не упрощается. Ведь чтобы записать jump поверх ядерной функции или подменить таблицу экспорта, необходимо явным образом указать адрес нашего обработчика (расположенного, как правило в драйвере), но на момент статической правки ядра местоположение драйвера в памяти еще неизвестно!!! Приходится шаманить. Например, можно поступить так: найти в ядре свободное место и внедрить туда крошечный перехватчик-диспетчер, определяющий был ли загружен «наш» драйвер? Если нет — управление возвращается оригинальным ядерным функциям, в противном случае — нашему драйверу. При перехвате нескольких функций, диспетчер должен смотреть откуда приходит вызова и какой процедуре драйвера их следует передавать. Вот почему вместо jmp'а программисты используют call. Диспетчер стягивает с вершины стека адрес возврата, смотрит откуда пришел вызов и все понимает. При желании, код перехватчика можно полностью реализовать в ядре (если, конечно, это не очень сложный перехватчик) — свободного места там предостаточно или загрузить свой собственный драйвер, однако, делать это можно лишь тогда, когда исполнительная система уже функционирует, дисковые тома смонтированы, файловые системы опознаны и соответствующие им драйвера готовы к работе. Другими словами, принудительная загрузка «своих» драйверов из ядра возможна только на поздних стадиях инициализации операционной системы (а к этому времени, вирусы, встроившие себя в ядро, могли давным-давно захватить управление, обламывая загрузку антивируса по полной программе). После любой модификации системных файлов необходимо пересчитать их контрольную сумму, иначе NT (в отличии от Windows 98) откажется их загружать (см. рис. 3), правда, в «безопасном режиме» по F8 они все-таки загружаются, но это все-таки не то. Рисунок 3 результат правки ntoskrnl.exe без пересчета контрольной суммы Для этих целей можно воспользоваться утилитой EDITBIN, входящей в состав Platform SDK и Microsoft Visual Studio. Командная строка выглядит так (см. листинг 4): editbin.exe /RELEASE filename.exe Листинг 4 пересчет контрольной суммы после модификации системного файла Естественно, не стоит забывать о такой штуке как SFC, норовящей автоматически (или вручную) восстановить измененные файлы. И хотя SFC легко усмирить (отключить или синхронизовать измененный системный файл с его «эталонным» оригиналом, хранящемся в кэше) это не решит всех проблем. При установке очередного пакета обновления, затрагивающего ядро, инсталлятор просто не поймет, что это за версия такая и откуда оно вообще взялось. В результате, установка прервется на середине. После перезагрузки система умрет и конечному пользователю придется, матерясь, заниматься ее реанимацией (подробнее об этом можно прочитать на блоге Раймонда Чена «OldNewThing»: http://blogs.msdn.com/oldnewthing/archive/2003/08/05/54603.aspx__). Для вирусов такой прием, быть может, и подходит, но для коммерческих программ он неприемлем в принципе! К счастью, существует одна интересная лазейка — возможность прописать в boot.ini файле альтернативное ядро, которое и будет загружаться, тогда оригинальный ntoskrnl.exe можно оставить в неприкосновенности. Ни SFC, ни инсталлятор пакетов обновления протестовать не будут, что есть гуд. А вот то, что обновление затронет «пассивное» оригинальное ядро — уже нехорошо. Может возникнуть конфликт старого ядра c новым окружением (тоже самое произойдет и при удалении пакета обновления), поэтому необходимо автоматически (или хотя бы вручную) отслеживать смену ядер, копировать ntoskrnl.exe поверх альтернативного ядра и заново его модифицировать. Довольно геморройный путь, но в некоторых случаях без него не обойтись, поэтому рассмотрим его во всех подробностях, тем более, что несмотря на кажущуюся простоту операции, подводных камней здесь предостаточно. Первым делом скопируем файл ntoskrnl.exe (он находится в папке System32) в… ну, например, в ntoskrnh.exe, затем найдем в корневом каталоге системного диска (которым, как правило, является диск C:) файл boot.ini и откроем его в FAR'е по <F4> или любом другом подходящем редакторе (см. листинг 5). [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINNT [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINNT=«W2K Pro RUS» /fastdetect Листинг 5 типичное содержимое файла boot.ini Продублируем (copy-n-paste) строку, находящуюся в секции [operatingsystem] и добавим к ней ключ «/kernel=ntoskrh.exe», где ntoskrh.exe — имя альтернативного ядра (см. листинг 6). Так же изменим текст, заключенный в кавычки, дописав сюда «hacked» или что-то свое. Главное — чтобы при загрузке можно было отличить основное ядро от альтернативного [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINNT [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINNT=«W2K Pro» /fastdetect multi(0)disk(0)rdisk(0)partition(1)\WINNT=«W2K hacked» /fastdetect /kernel=ntoskrh.exe Листинг 6 модифицированный boot.ini, предоставляющий возможность выбора ядер При загрузке системы возникнет меню, предлагающее нам одно из двух ядер на выбор (см. рис .4) Рисунок 4 загрузочное меню, отвечающее за выбор ядер Убедившись, что оба ядра исправно работают, удовлетворенные, мы начинаем хакерстовать. Открываем ntoskrnh.exe (альтернативное ядро) в hiew'е и вносим в него какие-нибудь несущественные изменения, например, находим последовательность 90h 90h (NOP/NOP) и меняем ее на 87h C9h (XCHG ECX,ECX), сохраняем изменения по <F9> и перезагружаемся… Рисунок 5 файл ntoskrnh.exe до хака Рисунок 6 файл ntoskrnh.exe после хака Опс! Альтернативное ядро больше не грузится! Что ж, загружаемся с основного, ругая себя всякими интересными словами, за то, что забыли пересчитать контрольную сумму. Даем команду «editbin /RELEASE ntoskrnh.exe» и перезагружаемся еще раз. Теперь альтернативное ядро работает как ни в чем не бывало и первую строчку (с оригинальным ядром) из boot.ini можно смело убирать, чтобы загрузочное меню не появлялось при каждом запуске системы. Правда, при этом станет невозможна загрузка в безопасном режиме, поскольку Windows не вполне корректно поддерживает недокументированный ключ /kernel и путается в ядрах во всех нештатных ситуациях. В данном случае, система упорно утверждает, что файл ntoskrnl.exe не найден, хотя он исправно присутствует на диске. Рисунок 7 попытка загрузки системы в «безопасном режиме» с альтернативным ядром приводит к краху! Ладно, проигрались и хватит! Попробуем ответить вот на какой вопрос — откуда драйвера узнают о факте переименования ядра? Ведь в их таблице импорта явно прописан ntoskrnl.exe, который (в случае альтернативного ядра) может вообще отсутствовать на диске, но тем не менее, функции экспортируются/импортируются и все работает как кремлевские часы после путча. Волшебство да и только! soft-ice по команде «map32» показывает «ntoskrnl» (без расширения), а не «ntoskrnH», как этого следовало бы ожидать с точки зрения здравого смысла, тем более, что в этом ntoskrnl присутствуют хакнутые нами байты 87h C9h. А вот PE-TOOLS с плагином ExtremeDumper «честно» сообщает полное имя файла ядра вместе с путем (см. рис. 8). Рисунок 8 при загрузке альтернативного ядра ntoskrnh.exe, soft-ice по команде map32 утверждает, что ядро зовется ntoskrnl, в то время как PE-TOOLS показывает его настоящее имя — ntoskrnh.exe Кому из них верить? Вопрос совсем не риторический! Если мы хотим сравнить образ ядра с его файлом на диске (для обнаружения on-linepatch'а, например), нам необходимо точно знать к чему обращаться иначе… можно совсем не в тот лес забрести. Ответ дает команда «mod» того же soft-ice, показывающая имя модуля ядра — ntoskenl.exe и соответствующий ему файл — ntoskrnH.exe (см. рис. 9). Весь фокус в том, что имена модулей не обязаны соответствовать именам файлов. И это относится не только к ядру, но и ко всем динамическим библиотекам вообще! При первой загрузке статической компоновкой или API-функцией LoadLibrary, система находит файл на диске по его имени, а при загрузке уже загруженных модулей поиск идет в памяти, где в таблице экспорта непосредственно прописано кто есть кто! Рисунок 9 команда soft-ice «mod» проясняет ситуацию ===== меняем загрузочный логотип ===== Напоследок, поменяем загрузочный логотип, отображающийся при каждой загрузке Windows (если логотип не отображается, значит, в boot.ini файле стоит ключ /noguiboot, который, в частности насильно прописывается soft-ice при его установке — дело в том, что при выборе типа загрузки boot – отладчик получает бразды правления до запуска видео драйверов, но уже после того, как система переведет экран в VGA режим, с которым soft-ice работать не хочет, вот и вставляет /noguiboot, чтобы система загружалась в текстовом режиме, при ручной загрузке отладчика командой «net start ntice» этот ключ можно убрать, вернув загрузочный логотип на его законное место. Стандартная картинка, отображающая при старте Window 2000 Professional (см. рис. 10, 11) выглядит достаточно скучно и уныло, провоцируя нас на замену. Как говориться, покажи мне свой загрузочный логотип и я скажу кто ты. Рисунок 10 стандартный загрузочный логотип Windows 2000 Professional Рисунок 11 стандартный загрузочный логотип Windows Server 2003 Лого храниться в ресурсах в секции bitmap'ов. В Windows 2000 и XP это первая же картинка с разрешением 640×480 точек и глубиной 16 цветов. В Windows Server 2003 в первой картинке хранится какая-то хрень, а сам логотип перемещен в 5'ю картинку с разрешением всего 215х147 точек и той же самой 16-цветовой глубиной. Для замены логотипа потребуется любой приличный редактор ресурсов, не уродующий файл, а корректно перестраивающий секцию ресурсов по всем правилам. Для этих целей неплохо подходит бесплатный ResourceHacker (http://www.littlewhitedog.com/downloadview-details-54-Resource_Hacker_3.4.0.html__), а саму картинку можно подготовить самостоятельно в Paint'е, Photoshop'е или поискать в сети по ключевым словам «bootlogocollection», «bootlogogallery». Неплохая подборка находится в хижине Маленькой Белой Собачки: http://www.littlewhitedog.com/content-17.html__. Запускаем ResourceHacker, открываем альтернативное ядро, щелкаем по 1'ой (Windows 2000, XP) или 5'ой (Windows Server 2003) картинке в bitmap'ах, щелкаем по раскрывшееся ветке еще раз и в контекстом меню выбираем пункт «ReplaceResource», далее указываем путь к новой картинке и сохраняется. Контрольную сумму ResourceHacker пересчитывает самостоятельно и после перезагрузки наша картинка появляется на экране (см. рис. 12): Рисунок 12 хакнутое лого, приветствующее нас при загрузке ===== заключение ===== Внедрясь в ядро мы вторгаемся в святую святых операционной системы и потому необходимо заблаговременно подготовить себя к возможным сбоям и падениям. Если диск размечен под FAT, то всегда есть возможность загрузиться с системной дискеты и вернуть все файлы с дистрибутивного CD-ROM. Правда, если до этого были установлены какие-то пакеты обновлений, то… святыня превращается в ад. Даже тотальная переустановка не помогает, Windows отказывается ставиться поверх более свежей версии. К счастью, пакет обновлений обычно представляет собой обыкновенный cab-файл с приклеенным к нему exe инсталлятором и необходимые файлы можно извлечь без установки! С NTFS все значительно хуже и чтобы дотянуться до нужных разделов необходимо либо подключить винчестер с упавшей системой, к компьютеры с живой NT, установив его вторым (впрочем, современные BIOS позволяют грузиться с любого жесткого диска). Как вариант, можно приобрести Windows PE — своеобразный LiveCD, загружающийся с CD-ROM и не требующий установки. Естественно, прежде чем вносить какие бы то ни было изменения в файлы и/или реестр необходимо создать резервную копию. Файлы копируются FAR'ом, а реестр — либо штатной утилитой MicrosoftBackup, либо путем загрузки с другого жесткого диска/LiveCD. ===== »> врезка интересные ссылки ===== - Window Hack's: - несколько интересных статей, посвященных играми с Windows и взлому системы активации ака WPA в том числе (на английском языке) http:www.governmentsecurity.org/archive/t3741.html; - Edit the boot logo and boot logo palette in Windows XP: - лучшая статья о замене загрузочных логотипов с подробным описанием техники создания различных спецэффектов (на английском языке): http://www.geocities.com/thejjoelc/XPbootcolors.html__; - Hack Your XP Boot Screen: - еще одна статья о подмене загрузочных логотипов, не такая подробная как предыдущая, но все равно полезная (на английском языке): http:sarahlane.typepad.com/sarahword/2004/06/hack_your_xp_bo.html; - How To Change The Windows 2000 Boot Logo: - статья о смене логотипов, написанная для «интеллектуального большинства», то есть с кучей скриншотов (на английском языке): ttp:www.littlewhitedog.com/content-9.html; - logo collections: - большая коллекция загрузочных логотипов — здесь есть все и обнаженные девушки, и мрачные готические руны, и анимэ, и еще много других вещей: http://www.littlewhitedog.com/modules.php?name=Content&pa=showpage&pid=17__;