Bolzano.4096.a,b,c,d,e,f

• Начиная с версии 'b' вирусы "Bolzano" патчат код файлов \NTLDR\WINNT\SYSTEM32\NTOSKRNL.EXE (системные файлы WinNT). Патч NTLDR отключает проверку целостности (контрольная сумма) модуля NTOSKRNL при его загрузке. Патч NTOSKRNL производится таким образом, что процедуры проверки прав доступа пользователей всегда возвращают значение "полный доступ". В результате вирус отключает на зараженных машинах разграничение доступа к ресурсам WinNT, что позволяет вирусу заражать все EXE-файлы на WinNT вне зависимости от прав доступа текущего пользователя.

Bolzano.3628,3904

• Помимо перечисленного выше данные вирусы патчат еще две процедуры с системных файлах WinNT. Новый патч NTOSKRNL разрешает запись во все файлы системы вне зависимости от прав доступа к файлам. Второй патч производится в файле MSV1_0.DLL и отключает проверку паролей, в результате чего любая введенная строка воспринимается системой как пароль, необходимый для доступа к системным ресурсам.

Нехило ... интересно как это он патчит в обход защиты файлов .

Пардон , я уже отыскал сорс

Ну так фрагменты и зааттачил бы сюда! Это ж как можно падч сделать если WFP есть? Или он и ее падчит?

bolzano.asm

Функцией _lwrite из kernel32.dll патчит сначала NTLDR , потом патчит ntoskrnl.exe . Эти файлы , я так понял WFP не проверяеться (я их по крайней мере не нашёл в sfcfiles.dll) . И вторым патчем видимо как раз и отключает WFP (хотя тут я сомневаюсь , и должно подействовать только после перезагрузки) . А уж тогда видимо можна патчить MSV1_0.DLL (он проверяеться) , но как если файл занят . В общем я только начал смотреть , сам повторять такое пока не собирался .

Эти файлы , я так понял WFP не проверяеться

Еще и как проверяются :) Я как раз и столкнулся с WFP когда хотел PEB.BeingDebugged ВООБЩЕ на всю систему вырубить :)

Ага , а я когда-то ламерски оптимизировал размер винды и стёр NTLDR (прям под NT) за не надобностью , потом фиг что загрузилось . Надо проверить будет :)

там комментарии есть :)

; this patch can only be implemented in administrator mode

Я говорю об NTOSKRNL.exe :)

Да , NTOSKRNL.exe точно защищён , но не занят .
В принципе если шустро и много менять , удалять , патчить файлы которые защищены , то у WFP(SFC) переполняеться буфер и он сбрасываеться , об этом MS сами говорят , но тут не это .

Если в системной директории происходит какое-то изменение , то WFP(SFC) от "ядра" получает т.н. directory change notification , после чего запускаеться проверка и восстановление . Было бы глупо полагать , что на _lwrite это не срабатывает , но тогда этот вирь сможет пропатчить NTOSKRNL.exe только если ему не будет замены (dllcache пуст например , cachesize=0 или SFCDisable выставлен в "ffffff9d") .

В общем если удасться , то после перезагрузки "делай что хочу" .

SFCDisable выставленного в твое число мало. Надо еще падч самой dll делать, а она ведь тоже SFC защищена... Словом, я не вижу способа этому вирю выжить :)

SFCDisable выставленного в твое число мало

Если до win2ksp2 включительно , то достаточно :)

Словом, я не вижу способа этому вирю выжить :)

Да , клиентов у него будет не много , но многие чтоб винда может не притармаживала или мало места занимала , отключают всё , что можна , особенно если это расписано в факе :)