KF

Предлагаю поделится своими соображениями и опытом по поводу ремонта установленных на компьютерах операционных систем, в частности Windows и его клонов. Классические варианты а-ля "снести-переустановить" не прокатывают, ибо снос операционки может породить еще большее количество проблем (а куда мои ярлычки с рабочего стола делись, а теперь кнопочки какие-то не такие...). Что и где можно смотреть, чистить, корректировать, и каким ПО кто пользуется. Ибо часто бывают такие ситуации, что попросят посмотреть компьютер, который стал вдруг медленно работать, вываливаться в синий экран, и пр., а ты сидишь и смотришь как баран на новые ворота. Вот и вопрос, с чего начать, когда все вроде-бы работает, да не так.

Есть старые утилитки, но я их очень люблю, так как действительно работают!
RegCleaner и NortonWinDoctor, наверняка знаете что к чему и зачем, так что долго описывать их предназначения не буду, но весчи полезные.

толку от них ровно ноль, все что они делают - можно и не делать, быстрее работать не будет, а автозагрузку можно и через msconfig чистить.

2 Diozan:  Вариантов из-за чего комп "вываливается в синий экран" бесчисленное множество и в каждой ситуации нужно конкретно разбирацца с причиной.

в логах смотри и всего делов то...
еси чессно не понял вопроса...

именно, логи, а тормоза могут по кучи причин...например был случай: тормозит ноут, смотрю - память забита безумно, процентов на 95, причем постоянно в таск менеджере светится svchost , смотрю кто именно на этом экземпляре сидит - нахожу ненужный процессы (не помню что именно), лезу в службы , вырубаю и все....
Другой пример: ставлю желео хитрое: 4х портовый IDC модем в старый комп, при попытке поставить дрова комп виснет, в логах только одна ошибка при загрузке - службы IRQARB (вроде так зовеется) типа траблы с ACPI, в итоге убрал в винде ACPI, прерывания назначил в биосе ручками, отключил ненужные порты, та же история, звоню в тех поддержку, описываю траблу, говорят, да бывает, меняйте мать, они несовместимы. И точно мать сменил - все ок, теперь вот думаю чего с лицензией на венту делать...
Это я к тому что причин ошибок может быть множество и в каждом конкретном случае их искать надо, есть спец форумы там и ищи, ну и microsoft.com тебе в помощь

хм... я вот чё подумал - не всяк захочет тебе за здорово  живёшь выложить все секреты как спасти винду без переустановки... некоторые этим живут, подрабатывают
народу с компами становиться все больше - а значит больше шансов заработать на них ;D

Честно говоря никагого другого способа, кроме как переустановки не знаю(самый надежный и эффективный). Разные утилитки здесь не помогут. Если винда вылетает в синий экран по-моему тут уже сложно что-то изменить и поправить. ИМХО.

последние года этаг четыре ставлю виндовс только один раз... при покупке нового системника

ващето можно рассмотреть синий экран повнимательнее, там указан код ошибки, далее загрузить комп в безопасном режиме (как правило всегда возможно) и устранить причину без всякого гемора; либо через консоль востановления хотябы тупо запустить проверку hdd
я переустанавливал винду из-за того что компас переставал работать, и ни как его не "починишь" кроме как переустановкой винды

Спрашивается зачем? Снес, поставил, опять снес и так до бесконечности. А полазить в чем причина не досуг? У меня винта стоит уже полтора года без каких-либо глюков, если они вылазят, то  разбираюсь в чем причина, а не переустанавливаю. Плюс всегда надо держать на готове архивную копию, чтоб все заново не переустанавливать.

ИМХО самый лучший способ восстановления, это иметь бекап. Вопрос чем делать, тонет в личных предпочтениях. Кому-то NtBackUp ( как бы его не ругали самые "крутые" админы, называя лоховским - слышал такое ), хорош Ghost2004, неплох Acronis 8.0-9.0. Кто при деньгах ( причем с Большой буквы ), кроме веритаса ни на что не смотрят. Респект им, не большой.
Кто имеет образы ( лучше не один, а начальный, далее со всеми дровами плюс софтом) , во многих вариантах защищены.
Кстати, winnt /e:fixmbr, если слетел раздел загрузки. Консоль помогла, но однажда и странно, что лишь в первый раз, потом не особенно.
Еще советую больше доверяить Process Explorer 10.04 от Автор: Mark Russinovich , чем taskmenager. Кстати, у этого автора немало прог, весьма полезных для развития этого топика.

ntbackup нормальная штука - сам им пользуюсь.
Иногда не грузицца вааапче - ошибка устройства ввода-вывода Win 2000 Server.
Единственный случай когдая я не смог оживить тачку сразу и пишлось делать Server Update чтоб сохранить инфу.
В прочих случаях рецепт прост - safe mode - ставится Startup CPL и чистится автозагрузка. Обычно проблема не грузящейся машины так или иначе связана с последней установкой чегобытонибыло - это все удаляется и вычищается. Потом машина перезагружается и вуаля - все работает.

У меня 50 на 50 - это слетевшая партиция - гамесные дела. Что вреднее и круче не могу сказать. Но защищенный реж. вытягивал раз из десяти в этих даунах. Кроме того имидж полезно держать при замене винта, или переносе системы.

Могу упомянуть ( почти из рубрики "нарочно не придумаешь" ) еще один вариант, может для чей-то копилки будет интерес, но сам удивился, когда мне его предъявили. Хотя тут же стало ясно, что далеко не панацея. Вариант этот держать - две операционнки. Причем рабочая, младшая по рангу по отношению ко второй. Например, ХП - Винда2003. На хп вся работа или игры ( кому ближе ), серверная ось грузится ( понятно, что с другого раздела, на С:\ о ней помнит лишь boot.ini ) исключительно для полного копирования в папку бэкапа всего С:\ или Doc.Settings по полной + %SystemRoot\System32 или полный каталог \Wind.... Соответственно, при подозрении на приобретенный вирусняк или наоборот потерю чего-либо, все это с архива диска С:\ заливается обратно. Что-то похожее делает винда в защищенном режиме ( во всяком случае реестр ), но это имхо очень мягкий и даже теплый вариант падения. Но для не обременного этими заморочками с восстановлением, вполне понятный и рабочий вариант. Конечно, для любого использования в домене этот вариант наивно рассматривать. Понятно, надеюсь, что этот вариант ни кому не советую. Может он был интересен годах в 98-01. Тогда Ghost работал лишь под Досом, Акронис был достижим не лучше веритаса, вот и изощрялись.
Сам этим не пользовался, т.к. Ghost 2001 - 2004 у меня в нормальной работе. Acronis True Image также не плох.

Излишнее цитирование

Имиджи дело полезное и нужное, только когда весь винт забит, долгое. Да и как правило "пока гром не грянет..". Вообще лучше всего точки восстановления почаще ставить, не ленится. А так первое дело, F8 при загрузке, "восстановление последней удачной конфигурации" (так вроде?). Если не помогает, "безопасный режим", удалять всё из автозагрузки (msconfig), дрова последние переустановить. Антивирь обязательно, для страховки. Если ничего не помогает, LiveCD, и ручками реестр править или  NortonWinDoctor, винт просканить на ошибки и т.д. А вообще так в 2 строчках рассказать вряд ли можно, надо по месту тела смотреть.

если ушла ntfs партиция я использую test disk с Hiren's Boot CD.
Восстанавливает информацию даже о зашифрованных партициях и позволяет получить к ней доступ.

я так понял "партиция" - это раздел на диске?

DiskEditor.exe + F6. Хороший тон - скинуть на диск. При нескольких логический дисках и последующем восстановление - цена этого флоппика неизмерима.

Это основной раздел на диске

Интересная статейка от Криса Касперски
http://www.xakep.ru/magazine/xa/085/114/1.asp

Для жадных до трафика:):):)

Жизнь после BSOD

Крис Касперски и Жирный Хомяк




С помощью отладчика и ассемблера заставим систему пережить голубой экран смерти

Все прекрасно знают, что означает BSOD (Blue Screen Of Death). Это последний вздох операционной системы, после которого она сбрасывает дамп и уходит на перезагрузку, теряя все несохраненные данные. Однако на самом деле BSOD - еще не конец, и если перезагрузку заменить реанимацией, то в 9 из 10 случаев можно возвратиться в нормальный режим и успеть зашатдаунить систему перед тем, как она умрет окончательно.

Синий экран появляется всякий раз, когда ядро возбуждает необрабатываемое исключение (скажем, обращение по нулевому указателю) или отлавливает заведомо левую операцию (освобождение уже освобожденной памяти, например). Во всех этих случаях управление передается функции KeBugCheckEx, описание которой можно найти в NT DDK. Она завершает работу системы в аварийном режиме, при необходимости сбрасывая дамп памяти, поковырявшись в котором, можно определить причину сбоя.

Функция KeBugCheckEx принимает четыре аргумента, важнейшим из которых является BugCheckCode, определяющий причину сбоя. Всего существует свыше сотни кодов ошибок, документированных в DDK (ищи их в руководстве по отладчику Using Microsoft Debugger), однако в действительности их намного больше. Дизассемблирование ядра W2K SP2 показывает, что KeBugCheckEx вызывается из 387 мест (с различными параметрами).

Разумеется, не все ошибки одинаковы по своей фатальности. В многоядерных осях это вообще не проблема. Падение одного ядра не затрагивает других. Все ядра работают в раздельных адресных пространствах и частично или полностью изолированы друг от друга. Разрушить такую систему очень трудно, многоядерная архитектура чрезвычайно устойчива к сбоям, но… как же при этом она тормозит! Межъядерный обмен съедает уйму процессорного времени. Если запихать все компоненты в одно ядро, то мы получим монолитное ядро по типу Linux (что, кстати говоря, явилось причиной яростной критики последнего со стороны многих теоретиков). В Linux, как и в BSD, все компоненты ядра (там они называются модулями) исполняются в едином адресном пространстве, и некорректно написанный модуль может непреднамеренно или умышленно надругаться над чужой собственностью (превратить данные в винегрет, например). Это факт! Однако при возникновении необрабатываемого исключения в ядре, Linux грохает только тот модуль, который это исключение и породил, не трогая все остальные. Аварийный останов системы происходит только по серьезному поводу, когда рушится что-то очень фундаментальное, делающее дальнейшую работу ядра действительно невозможной. Конечно, если полетел драйвер жесткого диска, - это кранты, но вот, например, без драйвера звуковой карты можно какое-то время и обойтись, сохранив все несохраненные данные, и только потом перезагрузиться.

Операционные системы семейства NT используют гибридную архитектуру, сочетающую сильные стороны монолитных и микроядер, что теоретически должно обеспечить превосходство над монолитным Linux'ом (кстати говоря, экспериментальное ядро GNU/HURD построено как раз по микроядерной архитектуре). Легендарно устойчивую NT/XP, которую, как говорят, можно уронить только вместе с сервером, на самом деле очень легко вогнать в голубой экран. Достаточно любому драйверу сделать что-то недозволенное, как система автоматически катапультирует пользователя. Хорошо, что Microsoft не строит авиалайнеры!

Если бы можно было пересесть на HURD! Но, увы, совместимость не дает. Вцепилась зубами и не пускает! Далеко не каждый может безболезненно отказаться от своей любимой NT. Так что не будем сетовать на неизбежность судьбы, а лучше возьмем в руки ассемблер и попытаемся что-нибудь такое написать. Что-нибудь такое, что решит все наши проблемы (закопать Билла Гейтса на 640 Кб ниже асфальта - не предлагать).

[чем мы будем заниматься]

Аварийно завершить работу системы, выбросив синий экран, - самое простое, что только можно сделать при крахе системы. Microsoft неспроста пошла по пути наименьшего сопротивления. Мы же покажем, как выйти из голубого экрана в нормальный режим, чтобы успеть сохранить все данные еще до того, как система рухнет окончательно. Это довольно рискованный трюк. В случае провала мы можем потерять все, даже наш дисковый том, который потом придется очень долго восстанавливать.

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

[что нам понадобится]

Все эксперименты мы будем проводить на девственной Windows 2000, без установленных пакетов обновления (остальные системы ведут себя точно так же, отличаются только адреса). Чтобы ненароком не угробить основную систему, всю работу лучше всего выполнять на эмуляторе типа VM Ware, хотя это и необязательно.

Еще нам потребуется SoftICE, NT DDK (eMule тебе в помощь) и комплект утилит Свена Шрайбера из его книги «Недокументированные возможности Windows 2000», который можно бесплатно скачать с сайта издательства «Питер» или вот тут: http://irazin.ru/Downloads/BookSamples/Schreiber.zip. Пиво и сушки выбираются по вкусу.

[преодоление голубого экрана с помощью SoftICE]

Дождавшись окончания загрузки Windows 2000, мы запускаем драйвер w2k_kill.sys, позаимствованный у Шрайбера, специально спроектированный так, чтобы вызывать голубой экран. Разумеется, из командной строки просто так драйвер не запустишь! Без загрузчика тут никак не обойтись (можно, конечно, прописать драйвер в реестре, но тогда система будет падать при каждом запуске, что в общем-то не входит в наши планы). Воспользуемся динамическим загрузчиком w2k_load.exe, разработанным все тем же Шрайбером - w2k_load.exe. NT поддерживает динамическую загрузку драйверов, но готовой утилиты в штатный комплект поставки не входит - все в духе Microsoft, а вот в Linux с этим проблем нет.

Набираем в командной строке "w2k_load.exe w2k_kill.sys" и система успешно клеит ласты и падает в синий экран.

Так происходит потому, что в процессе инициализации драйвера-убийцы выполняются следующие строки, обращающиеся к нулевой ячейке памяти, что строго-настрого запрещено:

[фрагмент драйвера-убийцы, пытающийся прочитать двойное слово по нулевому указателю из режима ядра]

NTSTATUS DriverEntry (PDRIVER_OBJECT pDriverObject,

PUNICODE_STRING pusRegistryPath)

{

return *((NTSTATUS *) 0);

}

Ну и зачем было ронять систему из-за такой ерунды?! Кому наш страшный убийца реально мешает?! Ведь целостность системы ничуть не пострадала! Как объяснить этой тупой NT, что в Багдаде все спокойно? Пора бы вернуться в user mode и продолжить работу в штатном режиме.

Если SoftICE был заблаговременно запущен, он отловит это исключение и покажет свой экран, передавая нам все бразды правления.

Если нажать «x» (или <Ctrl-D>), то немедленно после выхода из SoftICE вспыхнет синий экран, и чинить тогда будет уже нечего. Но пока мы находимся в отладчике еще можно кое-что предпринять. А предпринять можно следующее:

1) Определить место сбоя (обращение по нулевому указателю), исправить ситуацию (установить валидный указатель), вручную выйти из обработчика исключения, вернув CS:EIP на прежнее место: способ хороший, но, увы, требующий определенного интеллекта, которого у машины нет.

2) Зациклить текущий поток, воткнув в свободное место jmp $ и выйти из отладчика, разрешив прерывания командной r fl=I (если они вдруг были запрещены). Все будет ужасно тормозить, но ось продолжит работать и мы по крайней мере сможем корректно завершить ее работу.

3) Дождаться вызова функции KeBugCheckEx и сразу же выйти из нее, проигнорировав сбой и продолжив нормальное выполнение, правда, никаких гарантий, что система не рухнет окончательно, у нас нет.

4) Способ, предложенный ms-rem, дикий, но иногда работающий: отдать команды r eip=0/r cs=1B, переключающие процессор на прикладной режим.

Короче, вариантов много. Попробуем для начала воспользоваться первым способом. Мы знаем, что в данном случае авария произошла из-за ошибки нарушения доступа. Следовательно, процессор возбудил исключение, забросил на вершину стека EIP/CS/FLAGS и передал управление обработчику исключений, внутри которого мы сейчас и находимся.

Даем команду "d esp" для отображения содержимого стека и видим (для удобства рекомендую переключить окно дампа в режим двойных слов, воспользовавшись командой "dd"):

:d esp

0010:F7443C88 BE67C000 00000008 00200202 804A4431 ..g....... .1DJ.

0010:F7443C98 81116AD0 8649D000 BE8F1D08 BE8F1D08 .j....I.........

0010:F7443CA8 81480020 F7443D34 745FFFFF 83A49E60 .H.4=D..._t`...

Адрес инструкции, возбудившей исключение, лежит в первом двойном слове - BE67C000h (у тебя это значение наверняка будет другим). Селектор CS идет следом. Он должен быть равен 08h. Третье двойное слово хранит содержимое регистра флагов - EFLAGS.

Теперь мы знаем место сбоя и можем вывести дизассемблерный листинг на экран. В этом нам поможет команда "u *esp" (дизассемблировать содержимое памяти по адресу, который содержится в регистре esp) или "u be67c000":

[определение реального места сбоя]

:u *esp

0023:BE67C000 MOV EAX,[00000000]

0023:BE67C005 RET 0008

0023:BE67C008 NOP

0023:BE67C009 NOP

0023:BE67C00A NOP

0023:BE67C00B NOP

Вот она! Инструкция, вызвавшая сбой! А давай ее перепрыгнем, продолжив выполнение с RET 08h? Сказано - сделано. Но для начала нужно выйти из обработчика исключения. Для этого в SoftICE необходимо выполнить следующие команды:

1) r eip = *esp + sizeof(mov eax,[0]); // устанавливаем регистр EIP на RET

2) r cs = *(esp + 4); // устанавливаем селектор CS (не обязательно)

3) r FL = I; // разрешаем прерывания;

4) r esp = esp + C // снимаем со стека 3 двойных слова, заброшенные туда CPU

5) x // выходим из отладчика

После выполнения этой магической последовательности команд, система продолжит свою нормальную работу, и синий экран уже не появится. Фантастика! Невероятно! Мы только что избежали гибели, которая казалась неотвратимой!

Один маленький нюанс. Моя (и, возможно, твоя) версия SoftICE не умеет восстанавливать регистр ESP в обработчике исключения. Отладчик игнорирует команду r esp=esp +C, на самом деле только имитируя ее выполнение! А это значит, что стек остается несбалансированным, и, несмотря ни на какие усилия медиков, система все-таки грохается. Приходится хитрить. Мы видим, что за RET 08h расположена длинная цепочка NOP'ов. А что если воткнуть сюда команду "ADD ESP,0Ch", чтобы стек сбалансировал сам процессор?

Говорим отладчику 'A BE67C008' (ассемблировать, начиная с адреса BE67C008) и вводим следующее: ADD ESP,0C<ENTER>JMP BE67C005<ENTER> и еще один <ENTER> для завершения ввода. Переустанавливаем EIP на начало нашей заплатки - r eip = BE67C008 и выходим из SoftICE. На этот раз у нас все получается!

Вот последовательность команд по реанимации системы. Напоминаю, что она применима только в этом случае:

[реанимация системы в условиях, приближенных к боевым]

u *esp

r eip = *esp

r eip = eip + 9

a eip

add esp,0c

jmp BE67C005h ; адрес команды RET 8, в твоем случае будет другим

<ENTER>

r fl=I

x

[автоматизируем нашу работу]

Способ ручного восстановления, только что описанный выше, хорошо сочетается с духом системных программистов, постоянно пасущих SoftICE и умеющих фехтовать регистрами, как рапирой. А вот простым юзерам такой подход смерти подобен. Но почему бы нам не написать для них утилиту, зацикливающую сбойный поток или замыкающую KeBugCheckEx?

Написать такую штуку несложно (и мы действительно напишем ее), но это все равно, что подложить полено под аварийный клапан. Если система пойдет вразнос, ее уже ничего не остановит. Может пострадать даже файловая система (пусть это будет хоть NTFS). Конечно, вероятность такой трагедии крайне мала, но она все-таки возможна - имей это в виду. Тем не менее, рискнуть все-таки стоит, особенно в тех случаях, когда ты уверен, что это можно сделать.

Вот, например, возник у меня как-то конфликт между криво написанным драйвером DSL-модема и драйвером видеокарты, а из-за этого при просмотре видео иногда выскакивал BSOD. Поскольку нормальных дров найти не удалось, я временно ограничился тем, что закоротил KeBugCheckEx перемычкой, изготовленной из команды JMP и, ты не поверишь, это прижилось!

Проведем следующий эксперимент. Нажмем <Ctrl-D> для вызова SoftICE, установим точку останова на KeBugCheckEx и запустим наш драйвер-убийцу. Причем точка останова обязательно должна быть аппаратной ("bpm KeBugCheckEx X"), а не программной (bpх KeBugCheckEx), иначе ничего не получится.

На этот раз вместо сообщения об ошибке страничного доступа, SoftICE всплывает по срабатыванию точки останова, высвечивая курсором первую команду функции KeBugCheckEx, которая в нашем случае располагается по адресу 8042BF14h.

Прокручивая окно дизассемблера вниз, находим первую инструкцию "RET 14h" (в нашем случае она располагается по адресу 8042C1E9h). Это и есть команда выхода из функции, на которую нужно сделать jmp. Для быстрого поиска можно попросить SoftICE сделать search ("s eip l -1 C2,14,00").

Говорим отладчику "r eip = 8042C1E9" (у тебя адрес, скорее всего, будет другим) и давим на <Ctrl-D> для выхода. Отладчик всплывает повторно в той же самой функции. У нас ничего не получилось?! Не торопимся с выводами! Все идет по плану! Игнорирование критических ошибок вызывает целый каскад вторичных исключений, что в данном случае и происходит. Повторяем нашу команду "r eip = 8042C1E9" (для этого достаточно нажать стрелку вверх/<ENTER>) и система возвращается в нормальный режим! Третий раз отладчик уже не всплывает. Мышь немного тормозит, однако гонять ее по коврику вполне реально.

Приступаем к созданию драйвера, который будет все это делать за нас. Для начала нам понадобится скелет. Выглядит он так:

[скелет псевдодрайвера, не управляющий никакими устройствами, но позволяющий нам выполнять код на уровне ядра]

.386 ; использовать команды .386 ЦП

.model flat, stdcall ; плоская модель памяти, stdcall-вызовы по умолчанию

.code ; секция кода

DriverEntry proc ; точка входа в драйвер

; код «драйвера»

;

…

…

…

; возвращаем ошибку конфигурации

mov eax, 0C0000182h; STATUS_DEVICE_CONFIGURATION_ERROR

ret ; выходим

DriverEntry endp

end DriverEntry

На самом деле это не совсем драйвер. Он не принимает никаких IRP-пакетов, не обслуживает никаких устройств и, вообще, не делает ничего, только загружается и выгружается. Но для нашей затеи этого будет вполне достаточно!

Весь код сосредоточен внутри процедуры DriverEntry (своеобразном аналоге функции main языка Си), которая выполняется при попытке загрузки драйвера, инициализируя все, что необходимо. Отсюда можно дотянуться до функции KeBugCheckEx и модифицировать ее по своему усмотрению.

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

Путь первый - через реестр. Создаем в разделе HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\Memory Management значение типа REG_DWORD с именем EnforceWriteProtection и значением 0 (это можно делать и с прикладного уровня). Все! Запись в ядро открыта! Кстати говоря, SoftICE именно так и работает.

Путь второй - репаминг страниц. Отображаем физический адрес страницы, в которой лежит KeBugCheckEx, на виртуальное адресное пространство своего процесса посредством вызова функции NtMapViewOfSection, назначая все необходимые нам права. Репаминг осуществляется исключительно на уровне ядра, но к отображенной странице можно обращаться даже из прикладного уровня. Красота! По этой схеме работают многие брандмауэры и другие программы, нуждающиеся в перехвате ядерных функций, например, rootkit'ы. Подробности здесь: http://www.stanford.edu/~stinson/misc/curr_res/nt_hooking.txt.

Путь третий - сброс флага WP в регистре cr0. Это достаточно грязный трюк с целой свитой противопоказаний и рекламаций, однако для наших целей он вполне подходит. Используем его как самый простой и быстрый вариант, умещающийся всего в 3-х (!) машинных командах:

[код, отключающий защиту ядра от записи]

mov eax, cr0 ; грузим управляющий регистр cr0 в регистр eax

and eax, 0FFFEFFFFh; сбрасываем бит WP, запрещающий запись

mov cr0, eax ; обновляем управляющий регистр cr0

Соответственно, чтобы включить защиту, этот самый бит WP нужно установить, что и делают следующие машинные команды:

[код, включающий защиту ядра]

mov eax, cr0 ; грузим управляющий регистр cr0 в регистр eax

or eax, 10000h ; сбрасываем бит WP, запрещающий запись

mov cr0, eax ; обновляем управляющий регистр cr0

Политически корректная программа должна не просто отключать/включать защиту от записи, а запоминать текущее состояние бита WP перед его изменением, а затем восстанавливать его обратно, иначе можно непроизвольно включить защиту в самый неподходящий момент, серьезно навредив вирусу или rootkit'у.

Закоротить функцию KeBugCheckEx можно разными путями. Самое правильное (и надежное!) - определить ее адрес путем разбора таблицы импорта, но это слишком долго, муторно, нудно и утомительно. Гораздо проще подставить готовые адреса, жестко прописав их в своей программе. Минус этого решения в том, что на других компьютерах она работать не будет. Стоит установить (или удалить) какой-то ServicePack, перейти на другую версию системы, как все адреса тут же изменятся, и произойдет сплошной завис. Тем не менее, имея исходные тексты драйвера под рукой, его всегда можно исправить и перекомпилировать. Так что для домашнего использования такое решение вполне допустимо.

Главная тонкость в том, что мы не должны трогать первый байт функции KeBugChekEx, поскольку его уже потрогал SoftICE и весь вытрогал. Так же поступают и другие хакерские программы (например, API-шпионы), помещая сюда команду INT 03 (опкод CCh), предварительно сохранив прежнее содержимое где-то в другом месте.

ОК, пропустим первую команду (PUSH EBP) и начнем внедрение со второй. Чтобы сбалансировать стек в противовес PUSH EBP, говорим POP EAX, а затем либо jmp на RET 14h, либо сам RET 14h. Последний вариант короче и элегантнее. Реализуется он так:

[код, закорачивающий KeBugCheckEx]

mov dword ptr DS:[8042BF14h+1], 14C258h

Здесь: 8042BF14h - адрес начала функции KeBugCheckEx (на всех машинах разный), 1 - длина инструкции PUSH EBP, а 14C258h - машинный код, представляющий собой последовательность двух команд: POP EAX (58h)/RET 14h (C2h 14h 00h).

Объединив все компоненты воедино, мы получаем следующий папелац:

[средство против BSOD, перед употреблением встряхнуть]

.386

.model flat, stdcall

.code

DriverEntry proc

Mov eax, cr0 ; грузим управляющий регистр cr0 в регистр eax

mov ebx, eax ; сохраняем бит WP в регистре ebx

and eax, 0FFFEFFFFh ; сбрасываем бит WP, запрещающий запись

mov cr0, eax ; обновляем управляющий регистр cr0

mov dword ptr DS:[8042BF14h+1], 14C258h 14C258

; «закорачиваем» KeBugCheckEx

mov cr0, ebx ; восстанавливаем бит WP

mov eax, 0C0000182h ; STATUS_DEVICE_CONFIGURATION_ERROR

ret

DriverEntry endp

end DriverEntry

Вот такой маленький драйвер, а сколько данных он может спасти! Остается только откомпилировать его.

[ключи ассемблирования и линковки (используется пакет MASM из NT DDK)]

ml /nologo /c /coff nobsod.asm

link /driver /base:0x10000 /align:32 /out:nobsod.sys /subsystem:native nobsod.obj

Если все было сделано правильно, то на диске образуется файл nobsod.sys, который мы загрузим с помощью динамического загрузчика w2k_load. Загрузчик, конечно, заругается матом, что, мол, ERROR и драйвер вообще не грузятся, но так и должно быть. Все нормально! Мы же возвратили код STATUS_DEVICE_CONFIGURATION_ERROR!

Но, внимание! Под VM Ware такой трюк не срабатывает, поскольку она не полностью эмулирует регистр cr0 и таких шуток в упор не понимает, вызывая завис гостевой оси. В этом случае можно закомментировать все строки, относящиеся к регистру cr0 и отключить защиту через реестр, создав соответствующий ключ редактором. Кстати говоря, если на целевой машине установлен SoftICE, то такой ключ уже создан, и ничего делать не надо.

Загрузим драйвер-убийцу, чтобы проверить справиться ли с ним наше средство против BSOD или нет. SoftICE (если он установлен) несколько раз всплывает. Вот зануда! Гони его прочь, нажимая «x» или <Ctrl-D>. Все равно голубой экран уже не появляется! Система жутко тормозит, но работает. Плохо то, что теперь NT никак не может сигнализировать, что произошел системный сбой и что нужно побыстрее сматывать ласты, совершая shutdown. Кстати, почему это не может сигнализировать?! Самое простое - добавить в нашу заплатку на KeBugCheckEx несколько ассемблерных строк, которые «бибикнут» спикером или сыграют семь-сорок на динамике. В принципе, можно даже разделить BugCheck-коды на категории, каждой из которой будет соответствовать свое число гудков. За примерами далеко ходить не надо. Их можно выдрать из любого DOS-вируса. Техника программирования спикера на уровне ядра та же самая, и она ничуть не изменилась.

Да много что можно сделать! Главное - фантазию иметь!

[жизнь после BSOD]

Мы пережили самую страшную катастрофу - BSOD, после которой нам все по плечу! Конечно, неразумно практиковать такой подход на сервере, но для рабочих станций он вполне приемлем. Проверено на мыщъх'иной шкуре! Кстати говоря, некоторые вирусы, черви и rootkit'ы используют схожую технику для маскировки своего присутствия в системе. Некорректно написанный вирус может вызвать синий экран, и в системном журнале появится соответствующая запись, помогающая администратору разобраться с проблемой. Если же перемкнуть KeBugCheckEx, то компьютер будет просто беспричинно тормозить (или виснуть), но в журнале ничего не появится!

[чего не умеет NTFS]

Для минимализации последствий краха системы, NT поддерживает специальные call-back'и. Всякий драйвер может вызывать функцию KeRegisterBugCheckCallback и зарегистрировать специальный обработчик, который будет получать управление в момент возникновения голубого экрана. Это позволяет корректно останавливать оборудование, например, парковать головки жесткого диска. Шутка! А вот драйверу файловой системы сбросить свои буфера ничуть не помешало бы, тем более что он может проверить их целостность по CRC или любым другим путем. Ходят устойчивые слухи, что NTFS именно так и поступает. Как бы не так! Мыщъх дизассемблировал NTFS.SYS и не нашел там никаких признаков вызова KeRegisterBugCheckCallback! В момент аварии буфера NTFS остаются не сброшенными, и она выживает только благодаря поддержке транзакций, при которых гарантируется атомарность всех операций, то есть операция либо выполняется, либо - нет. Обновление файловой записи не может произойти наполовину, и потому, в отличие от FAT, потерянные кластеры на ней не образуются. Ну, практически не образуются.

[не в шутку, не всерьез]

Рискну предположить, что на английский «ядрена вошь» переводится, как kernel bug. Нет, вы только представьте себе, что ещё наши прадеды, испытывая недостаток словарного запаса для излияния переполнявших их эмоций, пускались в нетривиальное обсуждение недостатков программных комплексов! Это ли не наглядное свидетельство генетической предрасположенности русского народа к высоким технологиям?!

(с) Leonid Loiterstein

[исключение и наказание]

Всегда ли помогает шунтирование KeBugCheckEx? Насколько это безопасно? Это очень опасно, тем более далеко не всегда помогает. Вот, например, рассмотрим следующий пример кода, позаимствованный из ядра:

[фрагмент кода, при котором шунтирование KeBugCheckEx заканчивается очень печально]

00565201 call ExAllocatePoolWithTag ; выделение памяти из лужи

00565206 cmp eax, ebx ; проверка успешности выделения памяти

00565208 mov ds:dword_56BA84, eax

0056520D jnz short loc_56521C ; -> нам дали память! живем, мужики!

0056520F push ebx ;

00565210 push ebx ;

00565211 push 6 ; с памятью вышел облом

00565213 push 5 ; отправляемся на небеса

00565215 push 67h ;

00565217 call KeBugCheckEx ;

0056521C loc_56521C: ; CODE XREF: sub_5651C1+4Cj

0056521C lea eax, [ebp+var_C] ; продолжаем нормальное выполнение

0056521F push ebx

00565220 push eax

Система выделяет память из общего пула, и если с памятью не облом, то происходит нормальное продолжение, в противном случае вспыхивает голубой экран. Допустим, мы закоротили KeBugCheckEx, что тогда? Нас обломали на память, а мы продолжаем нормальное выполнение, как ни в чем не бывало, обращаясь по указателю, который указывает в никуда. Возникает целый каскад вторичных исключений, а все структуры данных превращаются в труху, и система рушится окончательно. Вот так.

WWW

Большую коллекцию голубых экранов можно найти на сайте: http://www.dognoodle99.cjb.net/bsod/, после просмотра которого становится очень грустно, так грустно, что даже жить не хочется, даже после BSOD.

INFO

Иногда SoftICE останавливается не на первой команде обработчика исключений, а непосредственно на месте самого сбоя. Под VM Ware первый раз SoftICE 2.6 всегда останавливается в обработчике, а во всех последующих случаях - на месте сбоя. Эффект сохраняется вплоть до перезапуска VM Ware.

Эх... девяностые-нач двухтысячные.... Soft-Ice.... Поиск Serial кеу.... Обленился... Грустно....

че цитировать касперски то, - давайте дамп - не хуже будет исследование

Все это хорошо :) Даже круто.
Не совсем понятно, это речь о том, как обрушить ( многие ли будут ассмом пользоваться для борьбы с бсодом, вот в чем вопрос??? ) или отремонтировать ось? ИМХо для мэна, жонглирующим в легкую ассмом, бсод не страшен
Странно, а код BSOD типа 0*00000000ХХ здесь не причем?

Меня это всё умиляет, вы начало темы все читали?

Как обычно, в начале было слово, дальше пошли "стихи".
Если о нашем начале, то более размытого и неопределенного трудно представить.
Что за клоны винды? Это, поверь умиляет не меньше ;)
Имхо к восстановлению обращаемся, когда уже не до ярлыков.
По бсоду: смотри код, он вверху, таблиц по его разшифровке куча. Хотя б на www.OsZone.net.

Блин, и здесь Евангелия, одна религия на этом форуме...

это во многом зависит от пользователя и его действий. После выхода в Интернет с отключенной защитой, особенно на порносайты Российские будешь постоянно переустанавливать систему. Вообще нормальные люди ставят систему, программы, настраивают все и делают копию для восстановления (желательно на другом винте или сменном носителе) и восставливай ее моментально хоть каждый день бесплатно.

ИМХО! Самый действенный и надежный способ - это иметь копию всех доков и дистрибов на другом винте! Более ничо не могу посоветовать, проблема только в наличии второго винта и сё!

я тоже согласен с тем мнением, что лучше или заново ставить, или иметь образ для восстановления, чем штопать глючную винду - все равно сколько ее не "ремонтируй" - результат будет или не надолго, или вместо одних глюков появятся другие 8)

Увы, так не всегда получается. Когда к тебе прилетает чья-то мама с мольбами "помоги, комп уже три дня не работает, у чада без игрушек ломка началась"... Понятно, что там ни о каких резервных копиях и речи быть не может. А сносить систему и переустанавливать, так потом наслушаешься про то, что было то-то, а потом не стало. Кнопочки съехали... В общем не благородное это дело - лечить Windows. Особенно чужой.

Всё дело в волшебных пузырьках....

Святая правда !

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

Клиент ВСЕГДА прав, даже тогда когда он просто глуп
Если это твой клиент :) .
Однако, если б все были такими умными, как сами продовцы компов, то это едва ли их самих обрадовало :)