Скачать Универсальные способы реанимации системыбесплатно

Начинаем мозговой штурм. Какие будут предложения? Думаем…

Что мы вообще делаем на ядерном уровне, когда можно просто совершить нуль-транспортировку на прикладном, на котором никакие BSOD'ы не возникают. Самое худшее, что может здесь случиться – это критическая ошибка, вызывающая аварийное завершение текущего приложения, но никак не падение всей системы целиком.

А что же ядро? Как там со стеком и прочими структурами данных? В каком состоянии мы их оставим? Ну, что касается ядра, то при вызове ядерных функций с прикладного уровня оно заново подготавливает регистровый контекст и все будет ОК. То же самое происходит и при генерации аппаратных прерываний, механизм диспетчеризации которых заслуживает отельной статьи. Самая большая опасность, которая нам грозит – это прерывание функции драйвера, оставляющей свои собственные данные в хаотичном состоянии (при последующем обращении к ним BSOD с высокой степенью вероятности вспыхнет вновь). Хм, а может быть и не вспыхнет. Это уж как повезет.

Ладно, рискнем (а что нам еще остается делать?) и воспользуемся легальной функций возвращения на прикладной уровень (которая, между прочим, недокументированна и варьируется от системы к системе). А других вариантов нет? Почему же? Ядро работает с кодовым селектором 08h, прикладной уровень — 1Bh, следовательно, для нуль -транспортировки нам достаточно изменить регистр CS с 08h на 1Bh. Но Syser отказывается воспринимать команду «r CS 1B», ругаясь на ошибку синтаксиса, хотя с синтаксисом все нормально. Syser определенно еще не доделан и, чтобы изменить CS, приходится щелкать мышью по окну с регистрами и модифицировать CS вручную, посредством графического интерфейса (хвост бы его побрал). После можно со спокойной совестью выйти из отладчика по и… тут же попасть под артобстрел голубых экранов смерти, падающих один за другим. Если не сдаваться и мужественно возвращаться каждый раз на прикладной режим путем модификации CS, то (при определенной степени везения) можно дождаться относительного затишья и продолжить работать на прикладном уровне, как ни в чем не бывало.

А вот другое решение. Вместо того, чтобы нуль транспортироваться на прикладной режим, оставляя ядро в аварийном состоянии, попробуем модифицировать функцию KeBugCheckEx, воткнув в ее начало машинную команду «RETN 14h», соответствующую машинному коду: C2h 14h 00h. Находясь в начале KeBugCheckEx, просто дадим команду «d eip» (отобразить в дампе памяти содержимое по адресу, на который указывает регистр EIP). Щелкнув мышью по верхнему окну, заменим три первых байта на «C2h 14h 00h». Поскольку, Syser – сырой продукт, синхронизация дампа памяти с окном кода отсутствует. Чтобы увидеть проделанные изменения, кликаем по кодовому окну, нажав /. Ага, теперь, команда «RETN 14h» появилась в самом начале функции KeBugCheckEx!

Ну и, чего мы добились? Достаточно многие виды исключений, при попытке игнорирования их таким варварским путем, будут вызывать BSOD вновь и вновь, пусть он уже не появится на экране (ведь своим RETN 14h мы фактически устроили короткое замыкание внутри функции-палача).
Однако на многопроцессорных системах (включая HT- и многоядерные процессоры) все будет работать, хоть и сильно тормозить, поскольку «зацикливание» одного ядерного «потока» практически никак не повлияет на все остальные. «Поток» взят в кавычки потому, что в ядре NT никаких потоков нет, но для объяснения происходящего такая трактовка вполне сойдет.

А вот еще один вариант. Вместо возврата из KeBugCheckEx, просто зациклим ее, воткнув в ее начало команду JMP SHORT $-2, которой соответствует следующий машинный код: EBh FEh, внедряемый по прежней схеме: «d eip», и дальше запись EBh FEh поверх существующего кода.

Зацикливая KeBugCheckEx на однопроцессорной машине, мы сильно рискуем получить глухой завис. Двухпроцессорные тачки какое-то время успеют проработать, прежде чем оба процессора вызовут KeBugCheckEx и войдут в бесконечный цикл, из которого их вывести может только аппаратное прерывание, сгенерированное таймером или иными внешними устройствами (правда, при этом существует реальная угроза переполнения стека). Если KeBugCheckEx многократно вызывается, выпадая в бесконечный цикл и оставляя переданные аргументы на вершине стека, то стеку рано или поздно наступит конец. Ловить исключение уже некому и система уйдет в перезагрузку безо всяких голубых экранов. Впрочем, это можно исправить путем изменения JMP SHORT $-2 на ADD ESP,14h/JMP SHORT $-2, что соответствует машинному коду: 83h C4h 14h/EBh FEh.

Вероятность выживания системы существенно повышается. Впрочем, все универсальные приемы преодоления BSOD далеки от совершенства, ведь если бы хоть одно надежное универсальное решение существовало, то его уже давно бы реализовали: если не сама Microsoft, то сторонние разработчики. Так что без изучения ассемблера и анатомических особенностей NT-подобных систем нам все равно далеко не уйти.