Желающим поучавствовать в доработке нового релиза скрипта SFC

[Кирилл]

Всем привет!

Я подумал, что это может быть интересно и другим участникам форума.
Возможно, кто то предложит свои идей дополнитнльно.

Сейчас дорабатываю блок, который отрабатывает в случае, если защита ресурсов windows обнаружила поврежденные системные файлы, но не смогла восстановить их.
А так же дополнительные блоки - формирование лога с результатами для XP и монтаж с автоопределением wim для того, что бы дернуть оттуда файлы.

Итак, если sfc не справляется, то :

1) Проверяем доступность файла cbs.log
2) Парсим в вывод в лог строки с CSI
При этом повторяющиеся строки надо убрать.
Убираем
Ignoring duplicate ownership for directory

3) При обнаружении в конце строк записи file is missing проверяем каталоги в папке
C:\windows\WinSxS
Находим пустые каталоги и выводим их список в лог .
В идеале еще сопоставить связь с строкой с недостающим файлом.


Есть мысль выдергивать из wim образа поврежденные \ отсутствующие файлы в C:\windows\WinSxS
Но пока хз)

Пока так...

 

[Dragokas]

А детальное ТЗ будет или это всё на уровне обсуждений?
И как ты решаешь проблемы, озвученные в этой теме: https://safezone.cc/threads/avtomatizacija-chtenija-logov-sfc-scannow.30303/ на счёт версионности ?

Итак, если sfc не справляется, то :

Есть еще файлы, не защищённые SFC. Они тоже подвержены повреждению. Можешь выдернуть список через HiJackThis. Их можно тоже проверить, например, через валидность ЭЦП.

Ignoring duplicate ownership for directory

А решать эту проблему не пробовал?

Находим пустые каталоги и выводим их список в лог .

Что это за каталоги и на что влияют?

Есть мысль выдергивать из wim образа поврежденные \ отсутствующие файлы в C:\windows\WinSxS

Можно ещё выполнить команду отката обновления, если знать, какой файл в каком из них.

Есть мысль выдергивать из wim образа поврежденные \ отсутствующие файлы в C:\windows\WinSxS

Это если в образе есть соответствующая версия. А пропатченый обновлением файл ты откуда будешь дёргать?

 

[Кирилл]

А детальное ТЗ будет или это всё на уровне обсуждений?

Наверное обсуждение - важная часть, которой я ждал от тех, кто проявит желание.
У меня уже было несколько совершенно четких ТЗ, но все они оказались не годны.

Исходя из этого я и разместил общий план действий.

на счёт версионности ?

На счет версионности.

Те файлы, которые окажутся более старой модификации останутся работоспособными, так как в каталоге безопасности системы они должны все равно числиться.
Если что то потребуется очень уж сильно обновить до последней модификаций , например тот же DISM - можно либо накатить обновление заново, либо брать изначально актуальную версию файла.
Тут логика у меня такая: если в каталоге безопасности старая модификация должна числиться и быть работоспособной, то в обратном случае, когда файл не будет считаться родным мы получим как минимум "не удалось восстановить некоторые из них..."

Сразу предвижу вопрос: зачем, если результат не гарантирован?

Ответ: толк есть если покоцан файл, ссылка в реестре или файл в хранилище отсутствует.
Это наиболее распространенные варианты.
То есть если у человека проблемы в работе системы и ее эксплуатации - то до рабочего состояния система будет восстановлена.

Это на мой личный взгляд на сегодня самый лучший вариант, так как восхваляемые в сети патчи DISM для той же Win 7 вовсе не выполняет тех задач, о которых все под копирку пишут.
То есть он лишь сверяет имеются ли повреждения фалов в хранилище и выводит в лог.
Причем делает это не всегда корректно.

Самым лучшим информатором по прежнему остался CBS.log.
Причем общепринятый парсинг по строке [sr]

findstr/c:"[SR]" %windir%\Logs\CBS\CBS.log > %userprofile%\Desktop\sfcdetails.txt

оказался тоже малоинформативен на сегодня и почти всегда нужно просить все равно полный лог.

Тот вариант парсинга, что я предлагаю позволит собирать более полную информацию и статистику по улучшению качества удобочитаемости парасера.

И завершу ответ обобщенным вариантом команды:

sfc /SCANFILE=*.* /OFFBOOTDIR=d:\    /OFFWINDIR=d:\windows

Это, если кто не помнит или не в курсе, как раз таки команда восстановления из автономного каталога, который, по моему мнению будет представлять из себя подключенный образ Wim.

Всю работу по сопоставлению легитимности файлов должна брать на себя утилита.
Мы лишь используем ее возможности.


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

Да, упустил - на время работы с хранилищем на каталог Log и WinSxS даем права админу.

Есть еще файлы, не защищённые SFC. Они тоже подвержены повреждению. Можешь выдернуть список через HiJackThis. Их можно тоже проверить, например, через валидность ЭЦП.

На счет этого были мысли, но абсолютно где то там на будущее))
Если и это будет в обсуждении - я за.

А решать эту проблему не пробовал?

Мне кажется эта проблема не имеет отношения к восстановлению файлов, поэтому выкидываю из лога.

Что это за каталоги и на что влияют?

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

Если какая то папка пуста, система никак не сможет восстановить файл.
Я пока еще определяюсь с принципом ссылок на них в реестре, поэтому пока только проверка на пустые при записи file missing

Можно ещё выполнить команду отката обновления, если знать, какой файл в каком из них.

Когда будет сопоставление строк по логу по части имени - мы это будем наглядно видеть, что сделает скрипт действительно сильным инструментом.

Это если в образе есть соответствующая версия. А пропатченый обновлением файл ты откуда будешь дёргать?

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

 

[Dragokas]

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

Каталоги безопасности тоже обновляются вместе с накатыванием обновления. Остаются ли там старые хеши, я не знаю. Думаю, что нет. Но, нужно проверять.
Для эксперимента, можешь взять ту же утилиту проверки ЭЦП HJT и посмотреть в отчёте поле "Catalog Path". Если оно есть, то файл числится в этом каталоге. Если нет, то файла нет ни в одном каталоге безопасности текущей системы.

P.S. Работоспособность конкретной версии системного файла только частично соотносится с необходимостью его наличия в каталоге безопасности:
1) Это больше актуально для Windows 8 и выше, где используются усиленные меры проверки подлинности файла, прежде чем система разрешит запуск такого файла на исполнение (механизм Signing Levels, детально описанный Алексом Ионеску). Другими словами, если файл не подписан, или не удаётся выполнить проверку подписи, то он не запустится.

2) Как я уже говорил в прошлой теме (может быть слишком кратко?), 1 обновление часто заменяет не один файл, а несколько файлов + записи реестра, при чём функции, которые вызываются из этих файлов + ссылки в реестре работают совместно. Так что если ты вручную заменишь 1 файл одной версии на более новую или более старую, это может привести к нестабильностям в работе системы, вплоть до BSOD. Иначе говоря, будь готов параллельно с подобным фиксом, создавать скрипт бекапа, который исправно сможет вернуть систему к прежнему состоянию из-под режима восстановления.

можно либо накатить обновление заново, либо брать изначально актуальную версию файла.

Всю работу по сопоставлению легитимности файлов должна брать на себя утилита.

утилита SFC? Тогда это не согласуется с первым утверждением.

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

Пока не понятно, как это будет выглядеть на стороне пользователя. Он скачивает оригинальный образ? В котором все равно нет новых версий файлов. Так то SFC никакой замены не произвёдет. А для Windows 10 будет ещё большая проблема найти подходящий образ в связи с выходом различных билдов вместо старой модели простых хотфиксов.

Я пока еще определяюсь с принципом ссылок на них в реестре, поэтому пока только проверка на пустые при записи file missing

А что за ссылки? Приведи одну. Я хотя бы посмотрю о чём речь.

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

Что именно не захватывается? Я честно, давно не смотрел никакие логи, так что трудно войти в курс.

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

Для этого нужно парсить базу, откуда SFC берёт инфу о каждом файле. Я пока даже не знаю, где эта база находится. Функции SFC недокументированны. Единственное, что я раскопал - список подзащитных файлов без какой-либо доп. инфы. Ну + из каталогов безопасности можно извлечь PE256 hash всех файлов, если тебе нужно для тестов.

 

[Кирилл]

1) Это больше актуально для Windows 8 и выше, где используются усиленные меры проверки подлинности файла, прежде чем система разрешит запуск такого файла на исполнение (механизм Signing Levels, детально описанный Алексом Ионеску). Другими словами, если файл не подписан, или не удаётся выполнить проверку подписи, то он не запустится.

На сейчас речь идет о костыле для 7 и виста по большей части, ведь 8 и 10 умеют восстанавливать хранилище.
Ок, пробую смоделировать ситуацию, а точнее уже накатываю максимум обновлений.
Уже интересно насчет списка файлов в хранилище, они ведь восстанавливаются с разных дистрибутивов.

 

[Dragokas]

По DISM ты вроде делал тестовый скрипт с установкой хотфикса для добавления в 7 функционала, только он у тебя почему то не сработал.
Откуда брал инфу об этом способе?

 

[Кирилл]

По DISM ты вроде делал тестовый скрипт с установкой хотфикса для добавления в 7 функционала, только он у тебя почему то не сработал.
Откуда брал инфу об этом способе?

Вообще изначально знакомый сисадмин сказал, я не поверил.
Загуглил.
Все кричат что теперь так можно)0
Я собрал тест-скрипт.
Параллельно начал изучать новые возможности и оказалось, что в реальности поддерживается только проверка целостности хранилища.
И то не все показывает, как оказалось.
Так же читал про умозаключения и о том, что некоторые патчи призваны восстановить файлы при установке себя.
Тоже не работает.

А что за ссылки? Приведи одну. Я хотя бы посмотрю о чём речь.

Ссылки на реестр - под рукой такого лога нет сейчас.
А,например, тот же file missing говорит об отсутствии исходного файла в одном из каталогов хранилища.
И если смотреть только [sr] строки, то мы не увидим в каком именно каталоге.
Это я уже сам смотрел, проверял.
Поэтому и хочу начать иначе парсить cbs, "общевойсковая" инструкция устарела.

А хр будем парсить по событиям.

 

[Dragokas]

А,например, тот же file missing говорит об отсутствии исходного файла в одном из каталогов хранилища.
И если смотреть только [sr] строки, то мы не увидим в каком именно каталоге.
Это я уже сам смотрел, проверял.

Давай подтягивай логи. Можно для начала хотя бы подредактировать скрипт Фильтрация лога SFC /scannow

А хр будем парсить по событиям.

Можно по событиям через мониторинг файловой системы, запущенный на время проверки. Вот асинхронная следилка.
Правда, он тебе покажет только факт замены, но не случай, когда файл повреждён, но отсутствует на дистрибутиве / в хранилище.

 

[Dragokas]

А на счёт полу-ручного фильтра может к нему прикрутить отдельным логом фильтрацию по чёрному списку (вместо белого как сейчас)? Типа такого:

@echo off
del cbs3.log
<cbs.log findstr /vi /c:"owned" /C:"duplicate" /C:"primitive" /C:"Verify complete" /C:"Verifying 100" /c:"Beginning Verify" /C:"SysprepPI Commit" /c:"FilePI Commit" /C:"FileMapsCreated" /C:"FilePI Queue" /C:"Original owner" /C:"New owner" > cbs2.log
::удаление пустых строк
for /f "delims=" %%a in (cbs2.log) do echo.%%a>>cbs3.log
pause

 

[Кирилл]

Dragokas, что то строки "обкусывает"
Но это ладно, сама идея ясна, можно и доработать потом.
Пошел систему гробить...или теория подтвердится.

 

[Кирилл]

Каталоги безопасности тоже обновляются вместе с накатыванием обновления. Остаются ли там старые хеши, я не знаю. Думаю, что нет. Но, нужно проверять.

Что я сделал.
Накатывал несколько дней все обновления.
Далее поубивал несколько файлов и заменил их файлами с дистрибутива - все исключительно в хранилище.

Из особенностей, что я заметил:
1) дата изменения папки с файлом в хранилище была свежая
2) дата изменения файла в папке - почему то 12 года.
3) дата изменения на дистрибутиве - 09 года.
4) при проверке sfc - ни один замененный файл в лог не попал, то есть все чисто и система "проглотила" файлы с дистрибутива даже после обновлений.
5) я точно помню, где то была тема, когда обновление закатывало новый файл и он считался системой поврежденным, все решилось только после многократного восстановления файла и наката обновления.
6) надо наверное сделать некоторый скрипт, который в каталогах хранилища переименует\удалит все (кроме определенных каталогов) и попробовать залить все файлы с дистрибутива
7) я умышленно не восстановил Microsoft.Build.Engine.resources.dll - если у кого есть ( win 7 ultimatum 86 ) скиньте,хочу попробовать с другого дистрибутива.

 

[Кирилл]

Кажется разобрался.

В кратце, дела обстоят так:
Если файл, который оказался поврежден и прилетел с обновлением не совпадает с версией в образе - то система указывает, что файл версии такой то поставляется с обновлением таким то, смотрите там то.
Если - скорее всего - на дистрибутиве такого обновления нет, то нужно его просто переустановить.
Либо найти такой же файл версии.

Если произвести грубую замену - а при этом данные о файле в хранилище уже обновлены - то мы тоже видим все записи, благодаря которым можно даже сказать где именно затык.
Таким образом функция sfc сводится к восстановлению из хранилища, а если указать путь к дистрибутиву - только тех файлов, которые имеются в базе данных хранилища.

Следовательно, концепция скрипта может немного измениться - парсить cbs нужно немного иначе.
Если система сама не в состоянии восстановить файлы то мы по логу должны просто сказать откуда и что с серверов ms надо скачать и все должно нормализоваться.

Сильно сомневаюсь, что научу скрипт самостоятельно в удобочитаемый вид переводить для чайников что откуда скачать ... ну посмотрим, что выйдет.

 

[Dragokas]

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

Ты сможешь это сделать без поиска в интернете?

 

[Кирилл]

Ты сможешь это сделать без поиска в интернете

Пока что нет.
Точнее, пока не придумать систему какую нибудь.
Напирмер
Package_40_for_KB3159398~31bf3856ad364e35~x86~~6.1.1.1.3159398-40_neutral_LDR
Речь идет о патче KB3159398
(у каждого будет под свою систему)
Download Обновление для системы безопасности Windows 8.1 (KB3159398) from Official Microsoft Download Center

Версия файла - смотрим бюллетень
Gpscript.exe 6.1.7601.23452 24,576 12-May-2016 14:57 x86

Потом смотрим свойства файла:

Все как в аптеке.
Ну а это оригинал с образа, если кому интересно

 

[Dragokas]

Точнее, пока не придумать систему какую нибудь.

Типа парсим эту страницу, распаковываем все архивы, парсим манифест, вытягиваем имя файла, создаём базу привязок KB <-> имена файлов / версия. (?)

 

[Кирилл]

Кирилл, прочитав пост, поперхнулся спросонья.
Вся его сущность съежилась, а сознание покраснело от перенапряжения - осмысливание того, что предложил Dragokas все больше приобретало форму выражения мысли, в словах которую можно было бы материализовать как:
-Че??

Но как то так, да.
Я пока еще тоже соображаю, можно ли здесь сделать какую то полуавтоматику.

 

[Dragokas]

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

 

[Dragokas]

Часть постов перенесена в тему: SFC: повреждён файл UserInit.exe

 

[Кирилл]

Смотрел еще файлы с win 8 -10
Всплывают периодически новые моменты, которые я раньше и не видел и не знал.
Дается мне что лучше всего сделать так:
1) Для обычного юзера упрощенный лог и экспресс проверка
2) Некий экспертный режим, когда собирается разная нужная информация о системе, которая может помочь в диагностике + сам файл cbs.log
На самом деле читать его не так и сложно, даже если вовсе не парсить.

Все вместе упаковываем в cab архив и юзер дает нам все это посмотреть.
Параллельно этому сделать мануал как можно, по возможности, самому разбирать лог.

 

[Dragokas]

На самом деле читать его не так и сложно, даже если вовсе не парсить.

Особенно, если отдать на растерзание Кириллу

Параллельно этому сделать мануал как можно, по возможности, самому разбирать лог.

Да, это будет актуальней.