возможно. на раскопать все это надо время и желательно подопытная машина. Пока мало первого и нет второго.

Во-во :(

infern0 - vmware тебе поможет со вторым -)
А вообще, господа, мы ушли сооовсем не туда.
Т.к. если патчить CSP и т.д. - то не проще ли не заморачиваться, а пропатчить sfc.dll? Чтоб та защищала нужные файлы. И все ?
Т.к. с патчами мы прийдем к тому же, с чего и начали, только в профиль.

А вообще, господа, мы ушли сооовсем не туда

Ну разогнались , я ещё статью не дочитал :)
Повышение надежности Windows 2000
Русинович пишет !

Спасибо за линк, сходил посмотрел. Про утилиту написано, что она только отключает WFP, про список файлов не написано ничего (утилиту пока не запускал).

Статью прочитал, любопытно. Но, по-моему, человек подходит не с того конца. Любой патч от MS во время запуска самого себя на время отключает WFP. Значит, нужно реверсить не sfc, а какой-нибудь патч, желательно поменьше размером. Я смутно помню (возможно, это и неправда, а просто когда-то мне приснилось :), а может, и не приснилось, но просто меня переклинило и я принял желаемое за действительное), что я реверсил какую-то фиговину и наткнулся на любопытную вещь - изменение определенного байта в памяти какой-то из системных библиотек с целью временного отключения wfp.

Тогда я не запомнил, что это такое, сейчас постучал пару десятков раз головой в стену от злости на самого себя, порылся немного, и нашел нечто похожее. Посмотрите на svcpack1.dll, и скажите, что вы об этом думаете.

Ох-хохо. Ты имеешь в виду сие:

.text:0040108F                 push    offset aSfc_dll ; lpLibFileName
.text:00401094                 call    ds:LoadLibraryA
.text:0040109A                 test    eax, eax
.text:0040109C                 jz      short loc_4010AB
.text:0040109E                 add     eax, 10A50h
.text:004010A3                 cmp     byte ptr [eax], 1
.text:004010A6                 jnz     short loc_4010AB
.text:004010A8                 and     byte ptr [eax], 0

"WinVerifyTrust на основе открытого ключа от VeriSign расшифровывает цифровую «подпись» и получает хэш-код catalog-файла «подписи». Выполняется сравнение хэш-кодов, и если они совпадают, то WinVerifyTrust регистрирует этот факт."
Думаю длина ключа не меньше 1024 бит . Без секретного не финты не получиться . И свой ключ пихать смысла нет , иначе все остальные файлы будут "неправильные" .
Править сертификат из catalog-файла нельзя , он подписан .

Видимо остаёться только править байты (а это до первого апдейта) .
Тогда WinVerifyTrust ?

А не может оказаться так , что можно не ломать , а спокойно получить сертификат у VeriSign и подписать своё app ? :)

В принципе : делаверская оффшорка + USA-call forwarding + 450 баксов и у тебя сертификат в кармане.

bogrus
А не может оказаться так , что можно не ломать , а спокойно получить сертификат у VeriSign и подписать своё app ? :)

не может. т.к. в полученном сертификате будет _другой_ открытый ключ и проверка все равно нахипнется. Или открытый ключ лежит в каждой EXEшке ? Тогда в сертификате должен быть параметр который говорит о его принадлежности именно к M$ (достать сертификат и посмотреть надо). Так что не думаю что 450 баками дело обойдется - было бы слишком просто.

rst
infern0 - vmware тебе поможет со вторым -)

VPC использую, но под ним softice жутко тормозной...

and byte ptr [eax], 0

че-то я не понимаю. ну поправили байт, но ведь для остальных процессов DLL осталась неизмененной, т.к. copy-on-write сработал. Или это байт в shared memory области ?

В аттаче стандартная утилита для подписывания файлов .
Обязательно попробуйте что-то подписать . Сразу станет понятно :)
Я сертификат админа использовал .
Или взять сертификат WINNT\ServicePackFiles\i386\classes.cer , только ним подписать не даст (потребует секретный ключ) .

Потом смотрите в свойства подписаного файла .

_2090797314__signcode.zip

Насколько я знаю, драйверы, прошедшие WHQL сертификацию подписываются мелкософтом, и потом "защищаются" WFP.
Делайте выводы.

volodya
Ох-хохо. Ты имеешь в виду сие:

Да, я говорил именно об этом. Только вот говорил, не подумавши :) Скорее всего, я действительно принял желаемое за действительное - почему я тогда решил, что эта штука отключает WFP - сейчас я понять не могу :( .

Как и не могу понять, что эта штука делает.

почему я тогда решил, что эта штука отключает WFP

эта не отключает, но вообще есть функция экспортируемая из sfc_os.dll (или из sfc.dll не помню точно) с ординалом 2 называется StopWatchingThreads. Пример ее вызова можно найти в любом патче от M$, там даже комментарии сделаны. Там они ищут процесс winlogon, потом в нем загруженный модуль sfc.dll и через createremotethread вызывают эту функцию (ординал 2). Ее же можно найти в private в коде user logoff. Так что отключить WFP штатными средствами не проблема. А вод подписать свой файл - тут действительно облом.